软件测试的左移方法(译）

Posted 2020-11-13 fengye151

摘要：

你越早发现你代码里的问题，它们的影响越小并且花越低的成本去修复它们。因此，它有助于更早地在软件开发生命周期中推动测试活动——在流程时间轴上左移。这篇文章探索了左移方法，并告诉你在你的组织中如何着手左移。

敏捷和开发运营团队对左移的混战是关于更早地在开发生命周期里移动关键的测试活动。

很多测试活动在周期里发生得晚，它花费了更多的时间去定位问题，更多的成本去修复它们。当你在开发周期之后等待实施测试活动，特别你的非功能业务需求，比如安全和性能测试，如此基本地根深蒂固在你的代码里，以至于你实际能做的是给它们打补丁而不是恰当地修复它们。

左移是关于更快地做这种识别和预防缺陷。

发现并修复软件缺陷

左移的测试策略可以很好地以卡柏斯•琼斯的有点出名的图表表格做阐释，下面展示了当问题和缺陷被引入到软件开发每个阶段的软件中，它们的增加成本。

 

图表显示的第一部分指明了绝大部分代码缺陷在编码周期引进的，可以是预料之中的。

他们是否犯错误、误解需求，或者没有通过特别的代码块的分支去考虑，当代码被生成时开发引入缺陷。当一起结合代码块的时候，缺陷也被引进应用程序，特别是如果涉及多个团队成员（并且就像现代架构比如微服务变得更复杂时）。

现在让我们叠加上相同的图，顺着线，展示出被发现的缺陷。注意从根本上它是第一条线的倒转：

 

这也不奇怪，因为典型地当你开始测试时你发现了bug，并且在一切准备就绪前没有一个合适的基础结构开始测试，结果会是不同的。

但是我们在这里也能看到当问题大多数在编码过程中被引进，它们几乎没有在那个阶段被发现。它需要什么成本去修复这些问题呢？

理解在每一个开发阶段去修复缺陷的成本的不同变得重要。这以第三条线为代表：

 

现在它开始变得真正地有意思，当我们看到一个令人不快的回归成本在缺陷被发现之后急剧地增加。让一个问题通过系统测试遗漏会是在编码期间找到它们的成本的40倍，或者在单元测试期间找到相同问题的10倍多。而且当你看到让问题在真正的部署中滑走的数目时它会变得荒唐的昂贵。

成本的逐步上升有一些原因：

• ·花费在查到问题的时间和努力。测试用例越复杂，查找出它真正的问题捣乱者在哪个部分就越困难。
• ·在开发的桌面重新产生缺陷的挑战被引进如独立的系统，像数据库或者第三方的应用程序接口。（对组织来讲，这些情况下在缺陷探测和缺陷修复之间经历滞后几个星期是常见的。）
• ·变化的影响是需要修复一个缺陷。如果它是一个简单的问题，那不会关系很大，但是如果在很多地方有它，你使用了错误的架构，或者你构建了对期望的压力或者不能够保证安全性的不可扩展的代码，它会是一个更大的问题。

左移背后的原因

现在看着以下图表上橙色的线，因为它解释了一个推迟的缺陷探测循环是在早期的测试基础上。你可以看到橙色的缺陷在低廉的一边增长地更快而且在昂贵的一边增长地更慢些，这给我们一个很重要的成本降低情况：

 

这个左移依赖于更多成熟的开发实践，比如一个基于软件测试金字塔 ——开发们创建了一系列的很好地合理覆盖代码的单元测试，并且功能测试者们和应用程序接口测试者们尽他们所能而且最小化地依赖于晚循环测试，所以你正好有足够的人工和用户界面测试去改善每一个正在运行的东西。这种方式，晚循环测试是为了改善功能性，不是去发现问题。“早测试，常测试”是这个左移团队的口头禅。

一些组织在这一点上停止了。但是当你更深入地推进左移、融入编码本身时，你会得到更多的价值。毕竟这是代码被引进的地方，所以让我们开始在开发仍然工作时候查找它们。

这就是我们从静态的代码分析中获益的地方。当找问题的成本尽可能的低时，你可以在实际的编码阶段开始找问题。

在测试开始前找问题不仅是成本上最有效的，而且也是时间上最有效的，因为它并没有以任何一件尝试重现产生问题或者理解失败的事离开开发。有能力从数天或数周到数小时或数分钟缩小缺陷修复循环是非常巨大的帮助。 

分析左移方法

这样，你如何左移呢？为了简洁起见，左移测试方法分解成两个主要的活动：提供开发和测试最佳实践，借力服务虚拟化以确保持续性测试。

做更早阶段的开发实践，比如静态代码分析和单元测试，有助于你在这个流程中更早地识别和防止缺陷。重要的是记住找问题不是目标，而是减少问题的数量，尤其是那些赶上发布的。最后，首先制造更少的问题比找更多的问题还有价值得多——并且它更低廉得多。看以下的图表，在左边有个可爱的减少的泡泡。

 

   编码标准是软件工程标准的等价物，而且它们是减少问题容量（除更早地找到问题外）的钥匙，并且从你的左移活动中获得更多的价值。编码标准帮助你避免坏的、危险的或者是不安全的通过静态代码分析的代码。

为了软件的安全性，尤其重要的是加强你的软件。你想要在你的代码里创建安全性，而不是测试它。代码标准让你从开始去构建一个更安全的应用（比如通过设计使它安全），这既是一个好的想法也是一个需求，如果你服从于比如通用数据保护条例的规则。

接下来，你必须执行在所有开发流程阶段的测试，包括晚期，并持续向前地执行它们。对团队来讲重要的是在开发流程的自始至终采取敏捷开发实践去提供持续的反馈。单元测试能简单地被持续执行但是晚期功能测试执行的左移通常很困难，因为外部系统独立性。这就是你能借力服务虚拟化使能够持续测试的地方。

服务虚拟化使你能够模拟可能有限能力的独立系统，比如主机、第三方服务，或者可能还没有准备好的系统。通过模拟它们，你可以在还没有完整系统可用时执行功能测试，并且你能一直在桌面端开发中左移测试执行。

在性能测试的术语里，服务虚拟化使你能够在每件事都准备好之前测试，并且不用有一个每一东西都在系统里的完整的实验室。你甚至可以运行所有种类的“什么——假如”场景，就像假如智慧云快而数据库慢（在真实世界里很难发生的一些事）运行什么？或者我的服务器开始抛出可笑的错误，就像500错误——那将会如何影响系统的性能？你可以随你喜欢并超越地推动你的系统坚固，而且尽可能早地做这个。

类似地，你可以更早地开始你的安全测试。从物理系统中去耦合允许你做甚至更有趣的一些事：使仿真的系统以一个恶魔的方式行动。代替只为污染的数据捅你的系统和分布式拒绝服务攻击，你可以有一个充满包、发送有缺陷的数据的系统，或者很多其他普遍被攻击者使用的漏洞。所以你不仅可以测试地更早，你还能测试地可能比一个测试实验或产品系统更深入。

避免错误和陷阱

在转移到代码阶段进行缺陷检查的一个危险是意外地在软件开发者们身上放太多测试负担。当你看图表时需要记住的重要的事情是当你向右去时缺陷修复的成本变得大幅高，在左边的资源可能在任一软件生命周期里有最高的成本——更不用说你正在把他们从专注于开发功能性中抽走。

你不仅想要更早地找到问题，你想要减少你首先放进程序里的缺陷的数量。

而且那有另一个陷阱：假如你正在奖励找到和修复问题的人们，现在他们将找到更少的——这是你真正想要的，但是仅仅假如你确实减少了你正在制造的问题数量。度量缺陷数量使它赶上场可能是更有用得多的测量。

改进你的流程和产品

通过借力于现代软件测试技术，你能获得安全的、可靠的和保密的软件。通过在软件开发生命周期里左移测试，你能通过更早地找到问题而减少测试的成本，当它低廉时，同时当你首先放进代码的问题的数量减少时。尝试这个方法去节省时间、金钱和头痛之事。