什么是测试左移（What Is Shift-Left Testing?）

      测试左移是将关键的测试实践移至开发生命周期的早期。这个术语尤其在敏捷，持续和DevOps计划中找到。那么，为什么需要执行早期软件测试？

许多测试活动发生在周期的后期，需要花费更长的时间找出问题所在，并花费更多的修复成本。左移是关于将缺陷的识别和预防转移到较早的阶段。如果不这样做，并在开发周期的稍后阶段等待执行测试实践，则特别是非功能性业务需求（即安全性和性能测试）在代码中已根深蒂固，以至于只能打补丁而不是正确地修复它们。

    测试左移策略在Capers Jones的一些著名图表中得到了很好的说明，该图表显示了在软件开发的每个阶段，引入到软件中的错误/缺陷的成本不断增加。图表的第一部分显示了预计大多数错误会在编码阶段进入。

无论他们是犯了实际的错误，还是误解了需求，还是不考虑特定代码的后果，开发人员都会在代码生成时引入缺陷。

当需要将各个部分组合在一起时，缺陷也会引入到应用程序中，尤其是在涉及多个团队的情况下（以及随着微服务等现代体系结构变得更加复杂）。

何时发现这些错误？

如上图，因为通常在开始测试时会发现错误，并且如果没有适当的基础架构就很难在一切准备就绪之前就开始进行测试。我们在这里看到的是，大多数错误是在编码期间引入的，但在该阶段几乎没有发现。

各阶段修复bug成本

由于大多数错误是在编码期间引入的，但直到下一个阶段才被发现，因此了解在开发的每个阶段修复缺陷所花费的差异就变得很重要。如下所示：

如上图，越往后发现缺陷，成本就会急剧增加。让错误潜入系统测试的成本是在编码过程中发现该错误的成本的40倍，或比在单元测试期间发现该错误的成本高10倍。

成本上升的原因包括：

• 跟踪问题所需的时间和精力。测试用例越复杂（越大），则更难定位具体问题的所在

• 由于引入了诸如数据库或第三方API之类的相关系统，沟通成本较大。（在这种情况下，组织在缺陷检测和缺陷修复之间通常要经历数周的延迟，这是很常见的。）

• 修复缺陷所需的更改的影响。如果这是一个简单的错误，那就没关系了。但是，如果在很多地方都做过，或者使用了错误的框架，或者所构建的代码的可伸缩性不足以承受预期的负载，或者无法确保安全性……

尽早测试、频繁测试（测试左移）

现在，观看下图中添加的橙色线，它说明了基于较早测试（左移）的缺陷检测周期：

可以看到橙色检测曲线在越早发现，修复成本越低，这大大降低了我们的成本。

左移依赖于更成熟的开发实践，例如基于软件测试金字塔的开发实践（开发人员创建了一组可以很好地覆盖代码的单元测试，而功能测试人员和API测试人员则尽其所能并最小化依靠后期测试，因此您只有足够的手动/ UI测试来证明一切正常。这样，后期测试就可以证明其功能，而不是发现错误。尽早测试，频繁测试是左移的口头禅。

测试左移

当进一步向左推动编码本身时，将获得更多价值。毕竟，这是引入错误的地方-因此，让我们在开发仍在进行的同时开始介入测试。这是我们从静态代码分析中受益的地方-通过查找最左端的缺陷来修复缺陷，其中修复成本最低的缺陷是：

通过静态分析，可以在实际的编码阶段开始寻找错误，这时发现错误的成本会尽可能地降低。

如上图，在“测试”开始之前先找到缺陷是最划算的。它也是最省时的，因为它不会给开发人员带来尝试重现错误或理解故障的任何问题。能够将缺陷修复周期从数天或数周缩短到数小时或数分钟，这是非常有用的。

测试左移不是增加开发工作量

测试左移偶然地给软件开发人员带来了过多的测试负担。查看图表时要记住的重要一点是，尽管随着正确的选择缺陷修复的成本急剧增加，但是左侧的资源可能是软件生命周期中成本最高的–这可能是使他开发人员不再专注于开发功能。

更早的发现问题是一方面，更重要的减少问题的数量，提升研发工程质量意识。

如何左移

• 静态代码扫描，单元测试，发现问题不是关键，关联是在质量意识的生态闭环中，不断减少存量问题，进而不断减少问题的发生。

• 规范：编码规范，数据规范、发布规范等

• mock、第三方服务隔离

原文参考：https://www./what-is-shift-left-testing/