在开发周期的早期进行自动化测试可以改善质量保证并减少延迟。

试应用程序过去是一项技术挑战性的，时间紧迫的活动，计划在应用程序发布前几天或几周进行。开发团队在第11个小时之前就有了编码的余地，而手动完成大部分工作的测试人员别无选择，只能花些时间给他们。结果是许多应用程序经受了不合格的测试，技术团队被迫应对最终用户和应用程序监视系统升级的生产问题和缺陷。

Devops持续集成实践，单元测试框架和测试自动化实践颠覆了这种范例。现在，许多测试实践不再在开发过程的最后进行质量保证，而是在编码，集成和部署期间开始并完全执行。Devops和敏捷团队会自动执行测试脚本，并且CI / CD管道会在其代码集成或交付阶段调出运行测试的权限。最终结果是，当开发人员的代码更改中断构建时，他们会得到警告，并可以立即采取措施解决所报告的问题。

自动化测试并将测试脚本集成到CI / CD管道中被称为左移测试。这意味着可以在开发阶段进行更多质量保证实践，以在发布时间表的早期发现问题。对于想要增加部署频率的敏捷团队和开发团队来说，自动化测试是部署前的优先事项之一。

在引入新功能时，构建的测试脚本会验证新功能。然后可以将这些测试自动化并包括在构建或部署步骤中。您可以在开发过程中运行和验证许多测试，而不必让质量检查工程师在发布过程结束时运行回归测试。这些测试从发布过程的结束向左移，进入较早的开发和编码阶段。

左移测试使敏捷团队对质量的承诺

左移测试不仅可以提高效率并提高质量，还可以在敏捷开发过程中带来重大的文化变革。

一些开发团队将质量保证和测试视为将代码交付生产的障碍。在满足敏捷产品所有者和完成代码的所有艰苦工作之后，质量保证团队成员确定了需要修复的错误列表。如果质量检查人员发现许多错误，则可能会影响发布时间表以修复它们。更糟糕的是，由于缺陷暴露了逻辑，安全性或性能问题，因此需要重新设计代码的重要部分。在这种情况下，开发人员和QA工程师可能在同一个敏捷团队中，但没有作为一个团队来工作。

左移测试使敏捷团队能够将质量责任转移到整个开发人员和测试人员团队。当测试作为CI / CD管道的一部分运行时，它为开发人员提供了一个更好的机会，可以在他们处理相关代码时及时解决质量问题。CI / CD管道会向开发人员发出构建失败的警报，并且大多数自组织的开发团队都需要立即解决这些问题。

左移测试还为开发人员和质量检查工程师提供了使更多测试自动化的机会。最佳实践是团队根据开发的功能所需的测试类型来决定由谁来实施自动化。例如，开发人员通常负责自动化单元和API测试，但是QA自动化工程师经常开发端到端用户体验测试和事务测试，以模拟对多个服务的多步API调用。

何时应用左移测试

左移测试最适合执行时间较短的单元级原子测试。在CI / CD管道中自动化测试是至关重要的，并且在开发人员触发构建时运行，并且要快速执行而又不减慢构建过程。

端到端用户体验测试，事务测试，静态代码分析和安全性测试等更复杂，更耗时的测试通常在CI / CD管道之外并按每日或更频繁的计划运行得更好。这些测试仍可为开发人员提供有关质量问题的早期反馈，但它们在CI / CD之外是自动化的，以避免构建速度变慢或出现瓶颈。

通用金融公司IT服务副总裁Thomas J. Sweet与我分享了他对左移测试策略的局限性的个人见解。他建议：“向左移动始终是一种策略，除非在第三方供应商交付上执行集成测试时，因为您通常无法访问其源代码。即使您的内部应用程序具有旧式整体架构，也可以从强制执行需要代码审查和安全扫描的基本签入策略开始。如果扫描中包含重要的警告和故障，则应拒绝签入。”

与集成合作伙伴进行下游测试的一种潜在解决方案是实施服务虚拟化。该技术使开发团队可以模拟下游系统对不同输入的响应。当下游系统定义明确时，它可以很好地工作。从工具微焦点，Tricentis和其他启用此功能。

经验丰富的质量保证经理Rob Pociluk强烈支持敏捷开发中的左移测试。“准备好并能够测试一小段代码，可以使质量保证（QA）保持灵活，并在冲刺过程中保持循环。团队仍应避免过多使用左移，因为您可能会失去代码本身的目的。”

因此，即使团队完全接受左移测试，也有充分的理由仍要在针对要发布的代码完整版本上安排测试窗口。它可以确保在最终版本上执行所有自动化测试，而且还可以安排需要功能齐全的系统的其他测试。

这些测试之一是UAT（用户接受测试），其中选定的最终用户和主题专家进行验证并提供反馈。在开发过程中可以完成一些UAT，但是要使人们经常执行此测试或在功能尚未完全就绪时可能并不容易。

左移测试策略的前提条件

左移测试是越来越多的devop实践，但它具有先决条件和前期投资。需要一些基本功能和实践。

需要足够的测试能力和环境来支持同时运行的构建和测试数量。

敏捷团队需要一个测试产品工具箱，该工具箱必须易于集成到CI / CD管道和作业计划工具中，并且可以验证功能，代码质量，安全性和性能。

架构师，信息安全专家，质量保证主管和组织的其他高级成员应建立测试标准和服务水平目标，以形成默认的接受标准。

当应用程序需要用户输入时，测试团队需要足够的测试数据和模式来验证足够的角色，用例和输入模式。

在冲刺承诺或更早的时候，包括QA测试自动化工程师在内的Scrum团队应制定测试策略，以测试要测试的功能，实现的测试类型，更新的自动化流程以及开发测试的人员。

Devops团队应测量CI / CD管道运行的持续时间，并在自动测试步骤影响生产率时做出标记。Devops团队通常需要CI / CD管道之外的其他测试计划，以执行运行时间更长的测试。

团队应定期讨论自动化测试中的空白，尤其是需要主题专家，UAT或与合作伙伴进行测试的验证。如果敏捷团队无法通过自动化解决这些差距，那么发布周期应考虑开销，以降低风险并完成这些测试。

最后，敏捷团队和开发人员组织应定期衡量和讨论其测试范围。如果开发团队和质量自动化工程师实际上没有实施，自动化和集成足够的测试来发现问题和解决风险，那么采用左移测试策略将行不通。

在没有足够的测试自动化的情况下加快发布周期或实现连续交付会导致严重的质量问题，从而降低最终用户的体验。敏捷开发团队过于频繁地发布版本，然后发现自己要解决生产问题和缺陷，而不是投资于更多更好的自动化。

龙测科技，您身边的自动化测试专家。