测试如何左移

原创 adoudou 小船哥说敏捷

之前一直听人提起“测试左移”这个概念，不过我对这个词的理解一直停留在字面意思：早一点介入测试。但是我的这个理解对不对，为什么要“测试左移”，测试如何左移，我一直没有搞明白。

最近业余时间比较多，所以今天打算彻底搞清楚这个概念。本文从以下3个方面尝试阐述这个问题：

什么是测试左移？
为什么要测试左移？
测试如何左移？

如果你对这三个问题比较感兴趣，可以继续往下看：

什么是测试左移‍

传统的软件开发方法（又称瀑布式）是一种阶段门限式的开发流程，测试一般都是靠近流程的右侧，下面的2张图是我在网上随便找的，测试都在倒数第二个阶段：

测试左移顾名思义，就是将测试实践向左移至软件开发生命周期的早期，尽早测试。

为什么要测试左移？

1、绝大部分缺陷都是在编码阶段引入的

《Applied Software Measurement》一书曾经做过统计，编码阶段大概会引入85%的缺陷：

编码阶段引入缺陷的原因可能是代码问题，需求理解问题，异常处理cover不到，集成问题，多团队合作对接问题等。

2、传统的开发方式，缺陷要等到测试阶段才能被发现

传统的瀑布式的开发方式，测试一般都是在软件开发流程靠后的位置才开始的，所以在编码阶段引入的问题，几乎很少在编码阶段发现，大部分都是在测试阶段才被发现：

3、缺陷发现时间越晚，修复成本越高

《Applied Software Measurement》一书指出，在系统测试和发布阶段出现的缺陷，修复成本是编码阶段的40和640倍：

Ponemon Institute 2017年的一份研究报告也指出，在测试和生产阶段发现问题的修复成本是编码阶段修复成本的12和95倍：

虽然这两份资料给出的数据有一些差别，但是我们依然可以看到，越靠近流程的右侧，修复成本就越高。造成越往右侧修复成本越高的的原因有这么几种：

定位困难（尤其是需要多团队配合的问题）。
复现困难（模拟真实环境，多线程场景等）。
修复困难（谁来修，使用临时还是长久方案，修复会不会引入其他问题）。
等等……

题外话：虽然越靠近右侧修复成本越高，但是出于某些原因（如获取真实用户反馈、在真实环境中测试稳定性和性能等），我们也还是需要刻意在生产环境做一些测试的，这可以通过A/B测试、在线监控、数据埋点、流量回放、全链路压测等方式来实现。

既然越往后修复成本越高，那我们要怎样让我们的测试左移，尽早地发现缺陷呢？

测试如何左移？

关于测试如何左移，我们可以通过以下4种方式来实现：

1、改串行工作方式为并行工作方式

1986年竹内弘高、野中郁次郎发表了一篇论文《The New New Product Development Game（新新产品开发游戏）》，这篇文章第一次提到了Scrum这种管理方法，后续的Scrum敏捷方法借鉴了这个名词，但是这篇文章中的Scrum，和后续Scrum敏捷方法的Scrum还不是一个概念，这里需要注意下。

下面是论文节选：

旧的开发方式中，产品开发过程如同接力赛一样，一组功能开发专家将接力棒传给下一组。项目从一个阶段到另一个阶段一次完成：概念开发、可行性测试、产品设计、开发过程、试生产和最终生产。在这种方法下，职能是专业化和分阶段的：营销人员在开发产品概念时审查顾客的需要和看法；研发工程师选择合适的设计方案；生产工程师实现这个设计；其他专家会在比赛的不同阶段，传递这个接力棒。

在Scrum方法下，产品开发过程中多学科团队不断互动，从始至终一直在一起工作。该过程不是在定义好的、高度结构化的阶段中进行的，而是在团队成员的相互作用下产生的（如上图）。例如，一组工程师可能会在可行性评估（阶段2）的所有结果出现之前就开始设计产品（阶段3）；或者团队可能会因为后续阶段的因素而被迫重新考虑某个决定。然而，团队的工作并未停滞，而是会持续进行迭代实验。这个过程甚至会持续到开发过程的最终阶段。

所以要想把测试左移，一个简单的方法是把瀑布式的、串行的工作，改为并行的、交叠的过程，这样测试人员就可以更早的介入测试工作了。

2、增加单元测试的投入

相信大家都看过类似这样的“测试金字塔”：