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

AlexQin

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

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

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



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

AlexQin

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

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

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

AlexQin

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

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

AlexQin

API先行

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

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

AlexQin

III：跨阶段协作

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

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

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

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



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

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

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

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

AlexQin

测试工件是可交付成果

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

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

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

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



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

AlexQin

持续管道如何运作？

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



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

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

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

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

AlexQin

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

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

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



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

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

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

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

AlexQin

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

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

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

超越团队边界

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

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

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

AlexQin

附录

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