软件测试的左移方法

概括：

越早发现代码中的问题，影响就越小，修复成本也越低。因此，将测试活动提前到软件开发生命周期的早期阶段（在流程时间轴中将其左移）是有帮助的。本文探讨了左移方法以及如何在组织中实现左移。

敏捷和 DevOps 团队向左转的活动是为了将关键测试实践转移到开发生命周期的早期。 

许多测试活动都发生在开发周期的后期，因此需要更长的时间才能找出问题，解决问题的成本也更高。如果你等到开发周期的后期才进行测试，你的非功能性业务需求（例如安全性和性能测试）已经深深植根于你的代码中，你真正能做的就是修补它们，而不是妥善修复它们。

左移是为了尽早识别和预防缺陷。

检测并修复软件缺陷

下面的 Capers Jones 的著名图表很好地说明了左移测试策略，该图表显示了在软件开发的每个阶段引入错误和缺陷时，软件的成本不断增加。

图表的第一部分显示绝大多数错误都是在编码阶段出现的，这是可以预料到的。

无论是犯错、误解要求，还是没有考虑好某段代码的后果，开发人员在编写代码时都会引入缺陷。在将各个部分组合在一起时，也会将缺陷引入到应用程序中，尤其是当涉及多个团队时（并且随着微服务等现代架构变得越来越复杂）。 

现在让我们将发现缺陷的线条叠加到同一张图上。请注意，它基本上是第一条线的逆线：

这也不足为奇，因为通常你会在开始测试时发现错误，并且如果没有适当的基础设施，在一切准备就绪之前开始测试可能会很困难。

但我们在这里也看到，虽然错误大多是在编码过程中引入的，但它们几乎从未在编码阶段被发现。修复这些错误需要花费多少钱？ 

了解在开发的每个阶段修复缺陷所需的成本差异非常重要。这由第三行表示：

现在事情开始变得非常有趣，因为我们看到成本急剧上升，缺陷发现得越晚，成本就越高。让错误潜入系统测试的成本是编码期间发现它的成本的 40 倍，或者比在单元测试期间发现同一个错误的成本高出 10 倍。当你看到让错误潜入实际部署的成本时，它的成本就变得高得离谱。

成本上涨有以下几个原因：

• 追踪问题所花费的时间和精力。测试用例越复杂，就越难找出哪个部分才是真正的问题所在
• 由于引入了数据库或第三方 API 等依赖系统，因此在开发人员的桌面上重现缺陷是一项挑战（在这种情况下，组织通常会在缺陷检测和缺陷修复之间经历数周的滞后）
• 修复缺陷所需更改的影响。如果是一个简单的错误，则影响不大，但如果你在很多地方都遇到此问题，你使用了错误的框架，或者你构建的代码无法扩展以应对预期负载或无法保证安全，则问题就大了

左移背后的原因

现在看看下图中的橙色线，它说明了基于早期测试的建议缺陷检测周期。你可以看到橙色检测曲线在便宜的一侧变大，在昂贵的一侧变小，这为我们带来了相当显着的成本降低：

这种左移依赖于更成熟的开发实践，例如基于软件测试金字塔的实践——开发人员创建一组单元测试，这些测试可以很好地覆盖代码，功能测试人员和 API 测试人员会尽其所能，尽量减少对后期测试的依赖，这样你就有足够的手动和 UI 测试来证明一切都正常。这样，后期测试就是为了证明功能，而不是为了发现错误。“尽早测试，经常测试”是团队左移的口头禅。

有些组织就此止步。但是，如果你进一步深入编码本身，你将获得更多价值。毕竟，这就是引入错误的地方，所以让我们在开发仍在进行时开始寻找它们。

这就是静态代码分析的好处。你可以在实际编码阶段开始查找错误，此时查找错误的成本最低。

在测试开始前发现缺陷不仅最具成本效益，而且最节省时间，因为它不会给开发人员带来任何试图重现错误或了解故障的问题。能够将缺陷修复周期从几天或几周缩短到几小时或几分钟是非常有帮助的。 

应用左移方法

那么，如何左移呢？为了简洁起见，左移测试方法分为两个主要活动：应用开发和测试最佳实践，以及利用服务虚拟化实现持续测试。

执行早期开发实践（例如静态代码分析和单元测试）可帮助你在流程早期识别和预防缺陷。重要的是要记住，目标不是发现错误，而是减少错误数量，尤其是那些在发布时出现的错误。最终，从一开始就减少错误比发现更多错误更有价值——而且成本要低得多。请参见下面的图表，左侧有一个可爱的缩小气泡。

编码标准相当于软件工程标准，它们是减少错误数量（以及尽早发现错误）和从左移计划中获得最大价值的关键。编码标准可帮助你通过静态代码分析避免糟糕、危险或不安全的代码。 

对于软件安全而言，强化软件尤为重要。你需要将安全性融入代码中，而不是对其进行测试。编码标准让你从一开始就构建更安全的应用程序（即通过设计使其安全），如果你受到GDPR 等法规的约束，这既是一个好主意，也是一项要求。

接下来，你必须采用在开发过程的所有阶段（包括后期阶段）创建的测试，并持续执行它们。对于采用敏捷开发实践的团队来说，在整个开发过程中提供持续反馈至关重要。单元测试可以轻松地持续执行，但由于外部系统依赖性，后期功能测试的执行通常很难提前。这时你可以利用服务虚拟化来实现持续测试。

服务虚拟化使你能够模拟可用性可能有限的依赖系统，例如大型机、第三方服务或尚未准备就绪的系统。通过模拟它们，你可以在整个系统可用的情况下执行功能测试，并且可以将测试执行一直转移到开发桌面。

在性能测试方面，服务虚拟化使你能够在一切准备就绪之前进行测试，而无需在系统中拥有完整的实验室。你甚至可以运行各种假设场景，例如，如果应用服务器运行速度很快而数据库运行速度很慢（这在现实世界中很难发生）会怎样？或者，如果我的服务器开始抛出奇怪的错误，例如 500 错误，这会如何影响系统性能？你可以尽早尽可能多地推动系统。 

同样，你可以更早开始进行安全测试。与物理系统分离可以让你做一些更有趣的事情：让模拟系统以邪恶的方式运行。你不仅可以让系统向你发送数据包、发送格式错误的数据或攻击者常用的许多其他漏洞，而不仅仅是对你的系统进行污染数据和分布式拒绝服务 (DDoS) 攻击。因此，你不仅可以更早地进行测试，还可以比测试实验室或生产系统进行更深入的测试。 

避免错误和陷阱

将缺陷检测转移到编码阶段的一个危险是意外地将过多的测试负担放在软件开发人员身上。查看图表时要记住的重要一点是，虽然缺陷修复的成本随着向右急剧增加，但左侧的资源可能是软件生命周期中成本最高的资源——更不用说你正在将它们从开发功能中转移开。

你不只是想尽早发现缺陷；你首先要减少应用程序中的缺陷数量。

还有另一个陷阱：如果你奖励人们发现并修复错误，现在他们发现的错误会更少——这实际上是你想要的，但前提是你确实减少了你引入的错误数量。衡量进入现场的缺陷数量可能是一个更有用的指标。

改进你的流程和产品

通过利用现代软件测试技术，你可以实现安全、可靠且有保障的软件。通过在软件开发生命周期中将测试移至左侧，你可以尽早发现错误，从而降低测试成本，因为这样成本更低，同时还可以减少你最初在代码中发现的错误数量。尝试这种方法可以节省时间、金钱和麻烦。

欢迎扫码关注公号，讨论交流~