左移测试是软件开发的一种方法，强调转移测试活动到开发过程的早期，以提高软件质量、扩大测试覆盖范围、提供持续反馈并缩短上市时间。
您是否参与过超出预算并错过每个截止日期的软件项目？当然，您参与过，我们都参与过。事实上，如果还没有遇到，您就是幸运儿，我想听听您的意见。
在我软件开发生涯的早期阶段，我了解到从截止日期倒推的重要性。如果一个项目必须在某个日期之前完成，而且测试需要一定的时间，那么我们可以利用这些信息来逆向推导，为我们的这个项目选择一个截止日期。很完美，对吧？
也不尽然。虽然及时构建以进行手动测试可以减轻项目最后几天的一些压力，但仍然有太多的意外。
及时构建 QA 测试在理论上很好，但在实践中一旦发现第一个错误或缺陷，很快就会崩溃。
修复这个缺陷需要多长时间？对时间安排有多大影响？是否会引入新的错误？我们如何确保每次修复都经得起时间验证，在修复第一个问题时切实修复破坏的任何东西？
最终，我一直无法确定分配给 QA 的正确时间。不可避免地，匆忙的修复在最后一刻被合并；我学会了在大型发布后的几周内预留出时间，这样我就可以对我们在疯狂的冲刺中错过（或引入）的所有问题进行分类。
归根结底，问题不在于可用于测试的时间，而在于测试的时机。我需要更早、更频繁地进行测试。我需要左移测试。
如果我们将软件开发过程想象成一条从左到右流动的时间线，那么“左移测试”就变得不言自明了。简单地说，就是在早期阶段进行测试，让团队成员（包括测试人员、开发人员和利益相关者）参与测试策略制定，并在开发生命周期中更频繁地整合针对现有功能和新功能的测试。
V 模型是一种概念化软件开发周期的有用方法。如果我们采用传统的瀑布流程并在实施阶段“翻转”Y 轴，我们就得到了 V 模型。
开发周期从高层需求开始。这些要求随着“V”的每个连续步骤而详细，直到我们到达代码级实现本身。然后，我们验证实施情况，从最精细的单元测试开始，按“V”顺序向上直至更抽象的用户验收测试。
在瀑布式流程中，整个项目由单个“V”组成。作为一个行业，我们已经了解到，当您将所有验证工作留到复杂项目的最后时，您基本上就是在迎接失败。
在迭代流程中，我们可以将每次冲刺或迭代视为一个较小的“V”形。理论上，我们已经实现了左移的目标：更快、更频繁地进行测试。问题解决了，对吗？也不尽然。
您可能已经注意到，V 模型内置的反馈渠道有两个标签：验证和确认。两者都很重要。
我们需要确认我们的用户需求真正解决了我们想要解决的问题。我们还需要验证我们的实施符合我们从这些用户需求中获得的规范。
自动测试既可用于确认，也可用于验证。BDD（行为驱动设计）导致了 Cucumber 等可以自动化确认过程某些部分的技术的诞生。在本文中，我们将重点介绍用于验证的自动化测试。
单元测试
单元测试验证大型应用程序中特定模块的功能。该模块是孤立测试的，与其他外部进程的任何通信都是模拟的。单元测试和 TDD 代表左移测试的第一个开发阶段。
集成测试
集成测试尝试验证服务或应用程序的整体功能，包括副作用。这个过程是一种反模式，原因我们稍后会讨论。
API 测试和契约测试
API 测试验证单个服务的外部端点。API 测试的范围与集成测试的范围类似；但是，在 SOA 或微服务环境中，我们可以将 API 测试视为新的单元测试。
UI 测试
UI 测试从用户界面层验证应用程序的完整功能。Selenium 等工具使自动化 UI 测试得到了广泛的应用。
不仅仅是自动化
左移不仅仅是自动化的问题。更早、更频繁地进行测试的另一种方法是确保您的 QA 专家参与流程的每一步，从发现和需求收集开始。当测试工程师对整体实施有更好的了解时，他们可以做得更好；他们的见解可以帮助架构更加透明和有弹性。
当我们想到“更快、更频繁”地进行测试时，会想到一个词：连续的。许多（大多数）软件开发团队正在实践某种形式的持续集成和持续交付。持续测试是此开发运维周期中的重要反馈循环。
连续性测试
如果我们将 TDD 视为“单体架构的左移”，那么持续测试就是“分布式架构的左移”。
TDD 让我们专注于单元测试。对于持续测试，我们应该关注 API 和契约测试。API 测试具有许多优点：
API 测试可以防止在微服务 应用程序中引入错误的最常见方法之一：更改与其上游或下游服务不同步的依赖项。
API 测试可以由拥有该服务的同一团队负责。
API 测试避免了测试副作用和实施细节的脆弱性。
理想情况下，这些 API 测试将针对生产和预生产环境持续运行。合同测试工具可以帮助实现这一过程的自动化，但这需要额外的基础设施。
如果我们能在可观察性工具中内置持续的 API 测试，会怎么样呢？Instana 即将推出的合成 API 测试功能将允许您轻松地针对所有环境持续运行 API 测试。
左移涉及将测试活动移至更接近软件开发生命周期的开始阶段，以便更快地获得反馈并减少修复错误所需的时间和精力。以下是敏捷开发中左移测试的一些最佳实践：
早期参与：测试活动应在开发过程中尽早开始。测试人员应从需求收集阶段就参与进来，以了解项目范围、目标和用户期望。
协作与沟通：促进开发人员、测试人员和其他利益相关者之间的密切协作与沟通。鼓励每天召开站立会议、冲刺计划会议和定期回顾，以确保共识和一致。
测试自动化：投资于测试自动化，以实现频繁、高效的测试。自动化测试应与开发流程一起创建，并集成到持续集成和部署管道中。这有助于及早发现缺陷，减少回归问题并加快反馈周期。
测试驱动开发 (TDD)：鼓励 TDD 实践，即开发人员在编写实际代码前编写测试用例。这种左移测试方法有助于预先定义所需的行为和预期结果，从而产生更为健壮和可测试的代码。
持续集成和持续交付 (CI/CD)：实施 CI/CD 管道以自动执行构建、测试和部署过程。这种做法可确保每项代码更改都经过全面测试，并快速、频繁地部署到生产环境，从而降低出现集成问题的风险。
左移安全测试：考虑在开发流程的早期阶段整合安全测试实践。执行安全代码审查、静态代码分析和以安全为中心的测试，以识别漏洞并主动修补它们。
探索性测试：除了自动化测试外，还鼓励探索性测试，从用户的角度探索应用程序。熟练的测试人员可以识别潜在的可用性问题、边缘案例和自动化测试可能遗漏的场景。
性能测试：尽早进行性能测试，以识别潜在的瓶颈和可扩展性问题。这有助于优化应用程序的性能，并确保其满足所需的性能标准。
测试环境和数据：提供与生产环境非常相似的测试环境，以确保真实的软件测试。此外，请确保有充足且有代表性的测试数据，用以模拟真实场景。
持续学习和改进：培养持续学习和改进的文化。鼓励定期进行回顾，以反思测试过程，识别瓶颈并实施更改，以提高左移测试的有效性。
通过实施这些最佳实践，敏捷团队可以通过左移测试实现更好的协作、更快的反馈和更高质量的软件产品。
左移流程中内置的更短反馈循环以多种方式赋予我们力量。可以更快地发现缺陷，可以更有效地应用修复，并且在一次迭代中吸取的经验教训可以应用于下一次迭代，仅举几例。
无论您的团队采用什么项目管理方法或发布节奏，都可以从左移测试缩短的验证反馈循环中受益。
成本节省
通过在开发人员的本地计算机上进行自动化单元测试发现的缺陷的识别和修复成本更低。但是，当缺陷一直延伸到面向客户的环境时，修复该缺陷的成本就会增加。
开发人员福祉
如果操作得当，自动化测试和 CI 可以为软件工程师提供经常部署所需的信心，即使在周五也是如此。尽早发现缺陷意味着更少出现全员惊慌失措地赶工的情况。由于发布过程非常轻松，因此修复出现的少数错误也变得更快、更容易。
弹性架构
正如更易于访问的软件通常对我们所有人来说更容易使用一样，更可测试的软件也更容易推理和维护。尽早考虑测试可以更好地分离关注点，并增强整体架构的弹性。
更高的整体质量
改善客户体验是我们的最终目标。左移可以消除最终用户可能会遇到的一些事件，并减少其他事件的影响。我们可以利用可观察性来完成这个反馈循环并改善我们的整体软件健康状况。
借助我们可用的强大自动化工具，对每一行代码实施各种测试可能很诱人。这是一条危险的道路。
测试副作用（该记录是否真的保存到了数据库？）是一个有吸引力的想法。但是测试实现细节是一种反模式，因为这些类型的测试非常脆弱。每次应用程序发生更改时，它们可能都需要更改。用户界面也是一个实现细节，因此 UI 测试的处境也相同。
验证测试只关心“是什么”，而不关心“如何”或“为什么”。理想情况下，用户需求旨在确认“为什么”。要回答“如何”，我们可以依靠更强大的自动化，即可观测性平台。
右移测试是开发流程晚期的测试实践，通常在生产环境中执行。虽然看起来很奇怪，但左移测试和右移测试存在互补关系。
右移测试使我们能够在客户之前识别生产问题。左移测试产生的反馈回路较短，使我们能够快速响应和修复这些生产问题。
综合 API 测试作为可观测性平台的一部分，是结合左移和右移实践优点的完美方式。
增强企业 APM 的功能和可观测性；无论应用程序驻留在何处，都可以改善应用性能管理并加速 CI/CD 管道流程。
深入了解可观测性如何为现代分布式应用程序提供深入的可见性，以便更快地自动识别和解决问题。
了解持续测试在加速软件开发、提高代码质量和避免代价高昂的瓶颈方面如何发挥至关重要的作用。
深入了解 DevOps 如何通过将软件开发和 IT 运营团队的工作相结合并实现自动化，加快交付更高质量的软件。
了解所需的全部合成监控信息，包括其定义、使用方法、面临的挑战等等。
了解如何应用技术、程序、机器人或流程，以最少的人工投入实现成果。
通过应用性能管理，预测性能问题，避免它们影响业务。