这是鼎叔的第三十二篇原创文章。

行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。

你越早发现代码中的问题，它们的影响就越小，处理这些问题的成本也更低。本文翻译自 Arthur Hicken 的博客，我们将探讨测试左移方法以及如何在你的组织中实现左移。

作者：Arthur Hicken
翻译：鼎叔

测试左移方法
“左移” 是指将关键测试实践转移到开发生命周期的早期。这个术语尤其适用于敏捷、持续工程和 DevOps 项目。那么，为什么需要执行早期软件测试呢？
许多测试活动发生在周期的后期，需要我们花费更长的时间来找出哪里出了问题，修复成本也更高。向左移动是指将缺陷的识别和预防转移到更早的位置。如果你不这样做，并等到研发周期的后期才执行测试实践，你的非功能性业务需求（比如安全测试和性能测试）在代码中早已根深蒂固，因此你真正能做的只是给它们打补丁，而不是正确地修复它们。

bug 什么时候进入代码的？
Capers-Jones 的著名图表很好地说明了测试左移策略，该图表显示了在软件开发的每个阶段引入软件的错误/缺陷的成本不断增加。图的第一部分显示了绝大多数错误是在编码阶段出现的，这也是意料之中的。

无论开发人员是否犯了实际的错误，或者误解了需求，又或者没有考虑到特定代码段的后果，他们都会在生成代码时制造缺陷。
当我们需要将各个部分组合在一起形成应用程序时，缺陷就会引入其中，特别是涉及多个团队开发时（并且随着微服务等现代架构的发展而变得更加复杂）。

何时发现这些 BUG？
当我们将显示缺陷所在位置的线叠加在何时引入的缺陷图上时，它开始变得有趣。
请注意，它基本上是第一行的倒数：

当然，这并不奇怪，因为通常情况下，您在开始测试时就会发现 bug。如果没有适当的基础设施，在一切准备就绪之前就很难开始测试（稍后将详细介绍）。我们在这里看到的是，这些错误大多是在编码过程中引入的，但在这个阶段几乎没有 BUG 能被发现。

修复 bug 需要多少成本？
由于大多数错误都是在编码过程中引入的，但直到稍后阶段才被发现，因此了解在每个开发阶段修复缺陷的成本差异变得非常重要。这表示如下：

现在它开始变得非常有趣，因为我们看到了成本的急剧增长，发现缺陷的时间越晚，成本就会显著增加。让一个 bug 潜入系统测试的成本是在编码期间发现它的 40 倍，或者比在单元测试期间发现同一个 bug 的成本高 10 倍。当你看到让 bug 溜进实际部署的成本时，它会变得昂贵得不可思议。

成本上升的原因包括：
追踪问题所需的时间和精力。测试用例越复杂（越大），就越难找出其中哪一部分是真正的麻烦制造者。
随着数据库或第三方 API 等依赖系统的引入，在开发人员的桌面上重现缺陷是一个挑战。（在这些情况下，组织通常会在缺陷检测和缺陷修复之间经历数周的延迟。）
修复缺陷所需变更带来的各种影响。如果它是一个简单的 bug，那就没那么重要了。但是，如果你在许多地方都做变更了，或者你使用了错误的框架，或者你构建的代码没有足够的可扩展性来满足预期的负载，或者无法确保安全性，那么……

尽早测试，经常测试（左移方式）
现在看下图中添加的橙色线，它说明了基于早期测试（即左移测试）的缺陷检测预估周期：

你可以看到橙色的检测曲线在成本便宜的一侧变大，在成本昂贵的一侧变小，这让我们大大降低了成本。
左移依赖于更成熟的开发实践，例如基于软件测试金字塔的开发实践（开发人员创建了一组单元测试，很合理地覆盖了代码；而且功能测试人员和 API 测试人员尽其所能，最大限度地减少对后期测试的依赖，这样你有足够的手动测试/UI 测试来证明一切正常）。这样，研发周期中的后期测试就是为了证明功能，而不是为了发现 bug。
尽早测试，经常测试，是左移者的口头禅。

进一步向左移动
一些测试左移的组织在目前这点（单元测试）上停止了。但是，当你进一步向左推进编码本身时，你会得到更多的价值。毕竟，这是引入 bug 的地方 - 所以让我们在编码仍在进行时就开始寻找它们。这就是我们从静态代码分析中受益的地方 - 通过找到更左边的缺陷，在那里修复缺陷最便宜：

通过静态分析，你可以在实际的编码阶段开始查找错误，此时查找错误的成本尽可能低。
正如你可以清楚地看到的，在 “测试” 开始之前找到东西是最具成本效益的。这也是最有效的，因为它不会让开发人员在尝试复制错误或理解软件故障时遇到任何问题。能够将缺陷修复周期从几天或几周缩短到几小时或几分钟是有非常显著帮助的。

小心不要将负担转嫁给开发人员
但是在这个左移步骤有一个危险，那就是不小心给软件开发人员带来了太多的测试负担。当你查看图表时，有重要的一点需要谨记。当你向右看时，缺陷修复的成本会急剧升高，然而左边投入的资源也可能是软件生命周期中成本最高的资源——更不用说你正在打扰他们专注于开发功能的状态。

所以你必须做正确的事情，把这一切提升到一个新的水平。你不只是想更早地发现缺陷，实际上你首先要降低应用程序中的缺陷数量。见下图，最左边是可爱的正在缩小的气泡。

但是等等，有个陷阱！如果你奖励发现和修复错误的人，现在他们就会发现更少的错误，这实际上也是你想要的，但前提是你一开始就真的减少了你引入错误的数量。度量进入线上的缺陷数量可能是一个更有用的指标。

那你怎么左移呢？

好的，这是我们在 Parasoft 公司所做的一切的核心。为了简洁起见，测试左移方法分为两个主要活动。

一 应用开发和测试最佳实践
在开发早期进行实践，如静态代码分析和单元测试，有助于在研发流程的早期识别和预防缺陷。
重要的是，要记住我们的目标不是找到 bug，而是减少 bug 的数量（尤其是那些进入版本发布的 bug）。最终目标是，创建更少的 bug 要比找到更多的 bug 更有价值，而且要便宜得多。这就是为什么安全编码关键标准要采用主动预防方法，标记出可能 “有效” 但仍然不安全的代码。

编码标准是工程标准的软件等价物，它们是减少错误数量（以及更早发现错误）的关键，能支持你的左移项目并从中获得最大价值。编码标准是软件工程知识的体现，可以帮助你避免坏味道的/危险的/不安全的代码。要使用它们，可以利用静态代码分析。
软件安全性，这对于成功地强化你的软件尤其重要。你要在编码中构建安全性，而不是在测试中进行。编码标准帮助你从一开始就构建一个更安全的应用程序（即基于安全的设计），如果你必须遵守 GDPR 等法规，这既是一个好主意，也是一项要求。

二 利用服务虚拟化实现持续测试
接下来，你必须汇总在开发过程的所有阶段（包括后期阶段）创建的测试，并持续执行这些测试。这对于采用敏捷开发实践的团队在整个开发过程中提供持续反馈至关重要。单元测试可以很容易地持续执行，但由于外部系统依赖性，将后期功能测试的执行向左移动通常很困难，这就是你可以利用服务虚拟化实现持续测试的地方。

服务虚拟化使你能够模拟有限可用性的依赖系统，例如大型机、接入方、第三方服务，或者可能是尚未准备好的系统。通过模拟它们，你可以在没有整个系统可用的情况下执行功能测试，并且你可以将测试执行一直左移到开发编码阶段。

就性能测试中的服务虚拟化而言，服务虚拟化帮助你在一切就绪之前进行测试，而无需拥有所有内容完整的系统的实验室。你甚至可以运行各种假设场景，例如，如果应用程序服务器速度快而数据库速度慢（在现实世界中很难做到这一点）。或者，如果我的服务器开始抛出有趣的错误，比如 500 错误码，会如何影响系统性能？
你可以随心所欲地推动这个系统，并且越早越好。

类似地，你可以更早地开始进行安全测试。与物理系统的解耦可以让你做一些更有趣的事情，那就是让模拟系统以一种邪恶的方式运行。现在，你可以真正进入安全测试……你可以让系统向你发送大量数据包，或发送格式错误的数据，或攻击者通常使用的任何其他漏洞攻击，而不仅仅是戳破你的系统以查找受污染的数据和 DDoS。因此，不仅可以更早地进行测试（更左移），还可以比使用测试实验室或生产系统进行更深入的测试。

总结
几十年来证明行之有效的质量保证流程可用于大幅提高质量，同时节省时间和资金。
当你利用现代软件测试技术向左移动时，你可以交付安全、可靠和安全的软件。通过将测试转移到左边，你可以在更便宜的时候更早地发现错误，从而降低测试成本，同时还可以第一时间减少你引入代码中的错误数量。

原作者简介：
Arthur Hicken
Arthur 在 Parasoft 从事软件安全和测试自动化超过 25 年，帮助研究新方法和技术（包括 5 项专利），同时帮助客户改进软件实践。