协作是持续测试的关键推动力

关键要点

• 敏捷团队负责测试工件的创建和版本控制。
• 合约测试可防止团队偏离接口定义。
• 通过让敏捷团队参与后期测试阶段，实现“超越团队边界的思考”。
• 测试工件是可交付成果，并且应在测试阶段中重复使用。
• 各种测试工具需要无缝交互和集成。



新一轮保护主义的兴起

在今年瑞士达沃斯世界经济论坛上，中心主题是新一轮保护主义的兴起及其对世界经济的负面影响。德国联邦总理 Angela Merkel 发出警告，明确说明在这个全球互联和快速发展的世界中，繁荣和增长的最重要先决条件是合作。

协作以及 DevOps、敏捷和持续测试的世界

合作正在成为商业最重要的方面，而不仅仅是在政治和经济环境中。协作也是技术领域领导者的取得成功的关键因素——使用敏捷方法为客户更快地交付软件和价值。

通过敏捷方法，我们开始将旧有的阶段门控软件交付模式转变为以团队和价值为中心的方法，减少交付 / 批量大小，并自动化手动交互以降低交易成本，同时提高交付成果的质量和交付速度（见图 1）。通常，昂贵的手动交互包括两个方面——一方面是安装、部署和配置应用程序，另一方面是验证应用程序功能——从开发、测试到生产（持续测试）。我们提供更多、更小的软件包，并持续测试我们提供的软件包。



图 1：

左侧：用于开发、测试和运营的传统分层团队模式——这通常会导致出现孤岛、由于移交导致的处理时间延长、交付延迟和大批量。

右侧：敏捷团队模式——最大限度地减少移交，允许信息共享并改善跨阶段协作。

底部：业务流程示例（价值流）——基于组件的团队通常只关注一个组件，其中更成熟的敏捷团队是基于功能的，负责组合组件和价值流。

团队内部、团队之间以及跨阶段的协作

有三种类型的协作被证明可以让企业走向成功，它们反映了企业在持续测试战略中所经历的典型的成熟度步骤：团队内部协作、团队间协作以及跨阶段协作。

I：团队内部的协作

验收测试驱动、行为驱动和测试驱动开发都被证明是质量和效率的重要驱动因素。所有可能的初始情况、条件和预期结果都会暴露出来，通过对整个过程进行思考，整个团队可以真正了解某个用户故事的预期结果。

理想情况下，敏捷团队的测试（参见图 2）遵循的是结对编程的模式。像结对程序员互相评审代码一样，在协作测试中，开发人员和测试人员在各自的用户故事上并行工作，相互支持，在第一天就能提供测试工件，这就是所谓的“测试自助服务模型“。一旦开发人员开始编译代码，测试驱动程序就也跟着启动了。根据检查和平衡原则，这种方法设定了很高的质量标准，并且还可以释放掉一些开发者资源。



图 2：敏捷团队是跨职能的，测试人员是团队的一部分。敏捷团队可以自我组织，自我管理，并在每个 sprint 中提供经过充分测试的工作增量。敏捷团队基于愿景、架构和用户体验指南运作。这种团队运作模式最小化了交接，实现信息共享，并改善了跨阶段协作。

像配对编程一样设置测试套件和环境

随着敏捷团队趋于成熟，他们通过基于模型和面向对象的测试方法提升了效率。就像标准的开发范式已演变为面向对象的原则一样，基于模型的测试是一个进化步骤，让我们能够将业务层从技术层中抽离出来。通过这种方式，我们可以向每个团队成员——技术人员或非技术人员——提供最佳视图，让具有不同技能的人员能够为测试项目的成功共同出力。

使用测试工件作为协作工具

测试工件（参见图 3）用于表示引导应用程序测试所需的信息——例如，UI 表单及其字段、接口定义或文件格式——以无冗余和可重用的方式，可以显著减少在创建和维护方面的工作量，让这些模型成为整个业务流程中不可或缺的一部分。

这些测试工件不仅限于 UI 或 API 测试驱动程序，它们还包括：

• 测试数据管理例程，用于生成合成测试数据，搜索现有测试数据或快照并屏蔽数据。
• 测试设计存储库，包含：
  • 所需的测试变体，并为每个测试变体验证其输入数据、条件和预期结果；
  • 非功能性测试驱动程序和参数，例如响应时间、预期最大负载能力或各种网络条件；
  • 每个变体的业务风险——了解每个测试用例的含义，并对其进行多个级联测试，如冒烟测试、sanity 测试或回归测试。



图 3：测试工件包含一个测试用例存储库，按每个测试用例附带的风险进行优先级排序。存储库定义输入参数、条件和预期结果——与测试数据管理相结合——提供测试执行的记录，创建合成测试数据或快照，并屏蔽应用程序数据库。存储库由基于模型和面向对象的测试工件组成，用于进行 UI 测试、API 测试或其他非 UI 测试驱动程序，如文件测试触发器数据库，非功能测试驱动程序，如负载或网络模拟条件。服务虚拟化用于模拟应用程序依赖项，并使用相同的测试数据存储库。

将进度测试（Progression Test）转换为回归测试

我们常常看到敏捷团队使用某种测试工具为新功能创建进度测试，另一方面，开发团队却在创建回归测试——这些工作是冗余的，会导致额外的工作量和延迟。通过基于模型的方法，每个最初用于验证新功能的进度测试用例都可以被重用，并转换为完整的回归测试组合（见图 4）。

通过将进度测试转换为回归测试，我们可以达到新的测试准确度，而这些是黑盒测试永远无法提供的。

这种方法的另一个优势是，敏捷团队是知识的中心，并且能够以最少的工作量和最好的知识来实时地创建、维护和版本化测试工件。这种方法可以提高测试的准确性，这种准确性是黑盒测试永远无法提供的。



图 4：为了实现高效准确的测试策略，需要在增量交付后的下一个 sprint 中重复使用进度测试工件（在 sprint 期间验证新功能），将其作为回归测试（验证完整的现有系统功能）

团队真的需要专门的测试人员吗？

你是否仍然在犹豫要不要在你的团队中设置专门的测试员角色？大约 200 年前，刑事司法系统引入了权力分立和制衡制度。因为检察官、辩护人和法官不再属于同一角色，所以我们再也看不到任何让人匪夷所思的女巫审判。专门的测试人员可以消除开发人员的盲目性——回想一下结对编程是如何消除错误的。

II：跨团队协作

我的几何老师告诉我说，“两个平行线在无穷远处交叉！”。在我十七岁的时候，他的这番话打破了我对科学的信心，当时我正尝试着如何绘制中心透视球的阴影。但有趣的是，对我来说，似乎在软件科学中它却恰恰相反：两个并行的团队——服务提供者和服务使用者——在完成一到两个 sprint 后，他们会在相同的接口描述上出现融合。在某种程度上，你永远不会相信他们可以理解同一种（定义）语言。

解决方案：合约测试在发生偏差之前证明接口的兼容性

组件通过接口进行交互，这些接口是团队协作的关键因素。我们应该通过合约测试让每个团队从一开始在不依赖其他相关组件的情况下就对他们的组件进行正确性验证，而不是等待以后通过集成测试来证明存在任何偏差（参见图 5）。

合约测试将每个组件与其依赖项分离开来，并将服务客户端和服务消费者之间的接口定义解释为“合约”。通过这些合约，我们针对服务提供者创建 API 测试驱动程序，并为服务使用者创建镜像的服务虚拟化测试。通过这种方法，这些合约测试可以确保在任何时候都能够匹配接口交互。



图 5：(1)“合约”是服务客户端和服务提供者之间接口定义的同义词。通过早期的接口定义，(2) 可以为敏捷团队的测试创建和提供 API 测试驱动程序及服务虚拟化工件。合约测试是高效系统集成测试的基础。

服务虚拟化支持完全沙盒化的业务流程测试

服务虚拟化是一种模拟技术，可让你在不使用待测试应用程序（AUT）的依赖系统组件的情况下执行测试。服务虚拟化可确保你的测试在每次执行时都会得到相应的依赖行为和数据（参见图 6）。

在验证了 AUT 的模式和请求数据之后，就可以存储、重用或修改数据，用于后续的服务虚拟化。你可以嵌入字符串、数学或外部函数，让测试场景变得更加真实。此外，你可以利用动态模式匹配系统来提供不同的响应方案、结构或模拟故障。服务虚拟化支持完全沙盒化的业务流程测试——在软件生命周期中实现全面和早期的质量反馈。[另请参阅测试驱动的服务虚拟化]。



图 6：服务虚拟化（“沙盒测试”）允许采购订单服务团队每天检索完整的集成测试结果，包括完整的业务场景。待测试的应用程序（采购订单服务）通过测试驱动的方式进行封装，其中使用了测试驱动程序和用于模拟依赖项的服务虚拟化工件，它们都使用相同的测试数据存储库。

合约测试（反向 API）是协作的关键

在服务提供者方面，API 是快速解决 Gordian Knot 质量的关键。通过将服务虚拟化方案转换为 API 测试驱动程序，它就像同一个硬币的两面：服务使用者的服务虚拟化和服务提供者的 API 测试驱动程序。

我们还突破了敏捷团队的障碍——让服务提供者和服务客户端​​团队能够在早期开发阶段执行和覆盖模拟集成测试，而这些通常只能在后续的集成测试环境中实现。

服务虚拟化例程是测试工件

合约测试被视为测试工件，以与 UI 测试相同的方式进行创建、维护和版本化，可以让现场、离岸甚至外部供应商执行（模拟）集成测试。

API 先行

API 先行——首先关注 API 测试不仅是这种更有效的设置和降低维护成本的愿望的产物，它也主要来自我们在团队之间实现渐进式合约测试。

这些步骤与一级方程式模拟器中使用的步骤基本相同。他们模拟了数百个组件的配置和交互（你是否知道 F1 团队只允许使用最多 25 Teraflops 进行模拟？），并且在识别出合适的设置后，赛车手就会在真实赛车道上使用真实的赛车以超狗 200 英里的时速进行快速验证并做出精确调整。或者用在飞行员训练计划中呢？你认为他们在第一次飞行时会让新手撞到真正的 A380 吗？可能代价有点太高了。

III：跨阶段协作

随着公司的第一批团队转向敏捷，重复的模式显示出保护主义的再次兴起。

“有超过 50％的组织在实施 DevOps”(8)，我们可以看到一个类似且重复的模式——只要有一些团队甚至整个业务线转型，就会遇到我们所熟知的问题：保护主义。

我们如何防止保护主义越过团队边界并形成壁垒？这个不是开发、测试、运营和业务之间的问题，而是敏捷团队和业务线之间的问题。那么，我们该如何将协作融入到整个公司的持续测试战略实施的过程中，让 CEO 和董事会成员不会面临大规模产品计划的大规模延迟？

一旦敏捷团队数量开始增加，就会形成敏捷团队的组合：部落、敏捷发布培训或业务线——你可能已将在应用 Spotify 模型或在使用可伸缩敏捷框架（参见图7），但分阶段测试的机制仍然存在。它假设你的测试过程已经很成熟，并且在团队中进行了全面的质量验证，然后通过了合约测试的覆盖。



图 7：左边——可伸缩敏捷框架 (2)。右边——Spotify 模型 (3)。

企业敏捷框架描述了成功将 Agile 扩展到企业所需的层次和结构、如何对敏捷团队进行分组、如何跨团队交付软件以及如何构建和管理团队组合（“敏捷发布列车”、“部落”） 。

尽管如此，我们仍然需要在测试阶段执行有效的测试——以排除未知或未识别的行为——特别是对于存在高业务风险的场景。在第一阶段，通常需要验证组件的交互，在第二阶段，需要进行完整的端到端用例和最终业务验收测试。

现在想象一下，如果你要为这些测试阶段重新创建测试工件（通常由专门的实施团队创建），除了需要敏捷团队成员的努力之外，还需要额外的资源、时间，而且还会造成延迟。为了不重建另一面墙，可以使用一个简单但可以改变游戏规则的方法：

测试工件是可交付成果

测试工件是可交付成果。变更发生得越晚，通常会导致越脆弱的测试自动化，但测试工件的可重用性保证了知识的转移和协作。

持续测试需要在敏捷团队和开发（系统）团队之间取得平衡。

在一些企业中，在实现了从分层到敏捷团队结构的转变之后，敏捷团队可能需要对应用程序从开发到进入生产环境的整个过程负责，但大多数团队都有单独的开发（系统）团队来部署、维护和测试所有应用程序的组合。

可伸缩敏捷框架声称它“需要敏捷团队和开发（系统）团队之间的平衡”，这就要求这些团队紧密协作，共享知识和测试工件。



图 8：最佳速度（和努力）是敏捷团队和开发（系统）团队之间的共同（测试）责任。

持续管道如何运作？

工件、版本控制系统和发布自动化这三个要素与持续测试平台相结合，形成了一个持续交付管道。它将应用程序安装、配置和部署到各个测试和生产环境，观察决策规则、质量阈值、应用程序依赖项，并在必要时执行回滚方案。它根据应用程序和部署的版本触发执行每个测试阶段的测试用例。



图 9：测试阶段（从左到右）：(1)Dev：通常，在本地机器上进行，同构结对编程的方式进行测试。(2)QA——通过 CI 触发构建和测试，仅关注团队的组件（沙盒测试）。(3) 敏捷团队组件组成的集成测试（部落、业务、敏捷发布培训）。

(4)E2E- 测试总体解决方案（部落 / 业务线组合 / 解决方案培训的组合）。

应用程序发布自动化工具是持续交付的基础——在每个测试阶段和生产环境中安装、部署和配置应用程序，基于底层组件版本控制，防止代码重新编译的工件，单独触发每个阶段的测试执行，根据预定义的决策标准进入下一阶段，并在必要时执行回滚方案。

由于这些阶段最初是在团队中动态创建的（创建、版本化和维护），因此测试工件最适合用于满足速度和质量方面的要求。

将测试自动化提升为真正的验证流程，而不是下游的变更活动

系统测试通常具有不同的方向，在关注业务流程的同时，仍然可以将测试工件（如 UI 测试驱动程序、接口测试、测试数据例程和测试存储库）应用在端到端测试上。

基于模型的一次性端到端测试案例由来自各个团队的各个部分组成。由敏捷团队稍后做出的底层组件及其测试驱动程序的变更将被继承并合并到端到端测试流程中。基于模型的测试可以实现全价值流的垂直测试，为每个测试阶段使用正确的版本，并将自动化测试执行提升为真正的验证流程，而不是下游的变更活动。



图 10：通常，专门的系统团队在企业层面验证应用程序的功能。当测试工件从团队移交给业务部门，再到系统团队时，可以获得最理想的速度、工作量和质量。

功能开关或生产环境测试等方法是否会改变执行关键端到端业务案例测试的方式？生产环境测试通常用于低风险场景，提供给小客户群，使用绿蓝部署，并在发生错误时自动回滚。功能开关呢？在客户可能获得其他客户的信用卡数据视图之前，仍然可以对关键流程（例如购物车支付流程的变更）进行有效的测试。

你是否仍然认为，敏捷团队应该是完全自组织的（并且只专注于他们自己的组件）？永远不要忘记 W. Edwards Deming 说过的话：

“系统必须是可管理的。它不会自我管理。如果放纵它们，组件就会变得自私，成为带有竞争性的独立利益中心，从而破坏整个系统。通过组件之间的合作来实现组织的目标才是秘密所在。“

结论——过去、现在和未来

在过去的二十年中，专注于验证完整端到端业务流程的集中式测试中心的日子很不好过。在外部、近岸或内部的 50 多个不同的供应商之间存在着十分紧张的局面，主要问题如下：延迟交付，劣质的输入、未遵循开发者验收测试协议、过晚才进行质量检查、在维护不良的测试环境中进行质量检查或者用在质量检查上的时间太短。这是一个功能失调的表现。

我们现在看到钟摆摆向市场的最左边，现在他们期望开发人员能够解决所有的质量问题。

超越团队边界

通常情况下需要做出折中——需要敏捷团队和开发团队之间从文化、流程以及测试工件的移交方面取得平衡和协作。

根据上面提到的三个阶段，团队最初只关注他们的组件，一旦企业在敏捷转型中发展成熟，就需要进行整体思考。

要将敏捷扩展到整个企业，需要的不仅仅是每个敏捷团队的自我组织——它要求团队将跨团队协作视为敏捷范式的关键部分。通过让传统上独立的团队参与到其中，可以很好地实现“超越团队边界的思考”，这些测试活动是在各种连续测试阶段进行的，而不仅仅是在开发阶段。通过让每个团队中自由选择工具，测试只有在选定的工具既能实现团队目标又能在后续的测试阶段被各种不同的角色无缝集成和使用时才能发挥作用。

附录

1. 标题：来源：683014141/Shutterstock.com；世界经济论坛
2. 图7：© The 可伸缩敏捷框架
3. 图7：© Spotify
4. 图8：共同责任
5. W.Edwards Deming：可伸缩敏捷框架——原则#2 应用系统思考
6. 基于模型的测试自动化
7. 图9：应用程序发布自动化
8. Forrester：2018——企业 DevOps 年

关于作者

Alexander Mohr 正在为 Tricentis 开发并提供围绕企业持续测试的战略、最佳实践和思想领导力，为敏捷转型、CI/CT/CD 设置路线图，并在整个转型过程中监督企业。Alexander 拥有超过 19 年的 IT 经验，于 2000 年初开始作为信用卡公司的开发人员，创建了一个发行和收购系统。在接下来的 15 年中，Alexander 担任过开发人员、产品经理、业务分析师、测试经理、架构师和项目经理等多种角色，在中型企业和企业级公司的瀑布式和敏捷项目中积累了很多经验，知道哪些事情可以做，哪些事情不可以做。

查看英文原文： How to Achieve Collaboration as a Key Driver for Continuous Testing