什么是左移测试？

您是否参与过超出预算并错过每个截止日期的软件项目？您参与过，我们都参与过。事实上，如果还没有遇到，您就是幸运儿，我想听听您的意见。

在我软件开发生涯的早期阶段，我了解到从截止日期倒推的重要性。如果项目有特定的截止日期而测试需要一定时间，那么我们可以利用这些信息来倒推并为项目选择截止日期。很完美，对吧？

也不尽然。虽然及时构建以进行手动测试可以减轻项目最后几天的一些压力，但仍然有太多的意外。

及时构建 QA 测试在理论上很好，但在实践中发现第一个错误或缺陷时，很快就会崩溃。

修复此缺陷需要多长时间？对时间安排有多大影响？是否会引入新的错误？我们如何确保每次修复都能经得起时间的验证，并在修复第一个问题时就解决我们破坏的所有问题？

最终，我一直无法确定分配给 QA 的正确时间。不可避免地，匆忙的修复会在最后一刻进行合并。我学会了在大型发布后的几周内预留出时间。此方法可让我对我们在匆忙中遗漏（或引入）的所有问题进行分类。

归根结底，问题不在于可用于测试的时间，而在于测试的时机。我需要更早、更频繁地进行测试。我需要左移测试。

如果我们将软件开发过程想象成一条从左到右流动的时间线，那么“左移测试”就变得不言自明了。简而言之，就是在早期阶段进行测试，以便让测试人员、开发者和利益相关者等团队成员都参与到测试战略中来。此外，它还涉及在开发生命周期中更频繁地集成针对现有功能和新功能的测试。

V 模型是一种概念化软件开发周期的有用方法。如果我们采用传统的瀑布流程并在实施阶段“翻转”Y 轴，我们便可实现 V 模型。

开发周期从高层需求开始。这些要求随着“V”的每个连续步骤而详细，直到我们到达代码级实现本身。然后，我们验证实施情况，从最精细的单元测试开始，按“V”顺序向上直至更抽象的用户验收测试。

在瀑布式流程中，整个项目由单个“V”组成。作为一个行业，我们已经了解到，当您将所有验证工作留到复杂项目的最后时，您基本上就是在迎接失败。

在迭代过程中，我们可以将每次冲刺或迭代视为一个较小的“V”形。理论上，我们已经实现了左移的目标：更快、更频繁地进行测试。问题解决了，对吗？也不尽然。

您可能已经注意到，V 模型内置的反馈渠道上有两个标签：验证和确认。这些标签都很重要。

我们需要确认我们的用户需求解决了我们想要解决的问题。我们还需要验证我们的实施符合我们从这些用户需求中获得的规范。

自动测试既可用于确认，也可用于验证。BDD（行为驱动设计）导致了 Cucumber 等可以自动完成确认流程某些部分的技术的诞生。在本文中，我们将重点介绍用于验证的自动化测试。

单元测试会验证大型应用程序中特定模块的功能。该模块是孤立测试的，与其他外部进程的任何通信都是模拟的。单元测试和 TDD 代表左移测试的第一个开发阶段。

集成测试会尝试验证服务或应用程序的整体功能，包括副作用。此过程是一种反模式，原因我们稍后会讨论。

API 测试会验证单个服务的外部端点。API 测试的范围与集成测试的范围类似；但是，在 SOA 或微服务环境中，我们可以将 API 测试视为新的单元测试。

用户界面测试会从用户界面层验证应用程序的完整功能。Selenium 等工具使自动化用户界面测试得到了广泛的应用。

左移不仅仅是自动化的问题。更早、更频繁地进行测试的另一种方法是确保您的 QA 专家参与流程的每一步，从发现和需求收集开始。当测试工程师对整体实施有更好的了解时，他们可以做得更好；他们的见解可以帮助架构更加透明和有弹性。

当我们想到“更快、更频繁”地进行测试时，会想到一个词：连续的。许多（大多数）软件开发团队正在实践某种形式的持续集成和持续交付。持续测试是此开发运维周期中的重要反馈回路。

如果我们将 TDD 视为“单体架构的左移”，那么持续测试就是“分布式架构的左移”。

TDD 让我们专注于单元测试。对于持续测试，我们应该关注 API 和契约测试。API 测试有以下几个优点：

• API 测试可防止在微服务应用程序中引入错误的最常见方法之一：更改与其上游或下游服务不同步的依赖项。
  

• API 测试可以由拥有该服务的同一团队负责。
  

• API 测试避免了测试副作用和实施细节的脆弱性。

理想情况下，这些 API 测试将针对生产与预生产环境持续运行。契约测试工具可帮助自动完成此流程，但这需要更多的基础设施。

如果我们能在可观测性工具中内置持续的 API 测试，情况会是怎样？Instana 即将推出的合成 API 测试功能将允许您轻松地针对所有环境持续运行 API 测试。

左移涉及将测试活动移至更接近软件开发生命周期的开始阶段，以便更快地获得反馈并减少修复错误所需的时间和精力。以下是敏捷开发中左移测试的部分最佳实践：

1. 早期参与：测试活动应在开发过程中尽早开始。测试人员应从需求收集阶段就参与进来，以了解项目范围、目标和用户期望。
    

2. 协作与沟通：促进开发者、测试人员和其他利益相关者之间的密切协作与沟通。鼓励每天召开站立会议、冲刺计划会议和定期回顾，以确保共识和一致。
   

3. 测试自动化：投资于测试自动化，以实现频繁、高效的测试。自动化测试应与开发流程一起创建，并集成到持续集成和部署管道中。这有助于及早发现缺陷，从而减少回归问题并加快反馈周期。
   

4. 测试驱动开发 (TDD)：鼓励 TDD 实践，即开发者在编写实际代码前先编写测试用例。此左移测试方法有助于事先定义期望行为和预期结果，从而生成更稳健、更易测试的代码。
   

5. 持续集成和持续交付 (CI/CD)：实施 CI/CD 管道以自动执行构建、测试和部署过程。此做法可确保每项代码更改都经过全面测试，并快速、频繁地部署到生产环境，从而降低出现集成问题的风险。
   

6. 左移安全测试：考虑在开发流程的早期阶段整合安全测试实践。执行安全代码审查、静态代码分析和以安全为中心的测试，以识别漏洞并主动修补它们。
   

7. 探索性测试：除了自动化测试外，我们还鼓励探索性测试，从用户的角度探索应用程序。熟练的测试人员可以识别潜在的可用性问题、边缘案例和自动化测试可能遗漏的场景。
   

8. 性能测试：尽早进行性能测试，以识别潜在的瓶颈和可扩展性问题。这有助于优化应用程序的性能，并确保其满足所需的性能标准。
   

9. 测试环境和数据：提供与生产环境非常相似的测试环境，以确保真实的软件测试。此外，请确保有充足且有代表性的测试数据，用以模拟真实场景。
   

10. 持续学习和改进：培养持续学习和改进的文化。鼓励定期进行回顾，以反思测试过程，识别瓶颈并实施更改，以提高左移测试的有效性。

通过实施这些最佳实践，敏捷团队可通过左移测试实现更好的协作、更快的反馈和更高质量的软件产品。

左移流程中内置的更短反馈回路会以多种方式为我们赋能。您可以更快地发现缺陷，更有效地应用修复，而在一次迭代中吸取的经验教训也可应用于下一次迭代，仅举几例。

无论您的团队采用什么项目管理方法或发布节奏，都可以从左移测试缩短的验证反馈回路中受益。

通过在开发者的本地计算机上进行自动化单元测试发现的缺陷的识别和修复成本更低。但是，当缺陷已经进入面向客户的环境时，修复该缺陷的成本就会增加。

如果操作得当，自动化测试和 CI 可以为软件工程师提供经常部署所需的信心，即使在周五也是如此。尽早发现缺陷意味着更少出现全员惊慌失措地赶工的情况。由于发布过程非常轻松，因此修复出现的少数错误也变得更快、更容易。

随着更易访问的软件对我们所有人来说更容易使用，更可测试的软件也更容易进行推理和维护。尽早考虑测试可以更好地分离关注点，并增强整体架构的弹性。

改善客户体验是我们的目标。左移可以消除用户可能会遇到的某些事件，并减少其他事件的影响。我们可以利用可观测性来完成此反馈回路，并改善我们的整体软件运行状况。

借助我们可用的强大自动化工具，对每一行代码实施各种测试可能很诱人。这是一条危险的道路。

测试副作用（该记录是否已保存到数据库中？）是一个有吸引力的想法。但是测试实现细节是一种反模式，因为这些类型的测试很脆弱。每次应用程序发生更改时，它们可能都需要更改。用户界面也是一个实现细节，因此用户界面测试也处于相同的情况。

验证测试只关心“是什么”，而不关心“如何”或“为什么”。理想情况下，用户需求旨在确认“为什么”。要回答“如何”，我们可以依靠更强大的自动化，即可观测性平台。

右移测试是开发流程晚期的测试实践，通常在生产环境中执行。虽然看起来很奇怪，但左移测试和右移测试存在互补关系。

右移测试使我们能够在客户之前识别生产问题。左移测试产生的反馈回路较短，使我们能够快速响应和修复这些生产问题。

合成 API 测试作为可观测性平台的一部分，是结合左移与右移实践优点的理想方式。