第1章 软件测试新理念

1.1 测试左移

1.1.1 传统瀑布模型下软件测试的挑战

在早期传统的软件开发流程中，很多项目都是参考瀑布模型来进行开发的。瀑布模型的主要实践是将软件研发全生命周期中的各个阶段——需求分析、架构设计、实现设计、代码开发、单元测试、集成测试、系统测试、上线发布、生产运维，依次排列（如图1-1所示），按顺序执行，即大规模集中的测试工作在软件功能设计与开发完成后才开始。

图1-1 瀑布模型下的软件研发全生命周期

这种模型最大的问题在于，很多软件缺陷其实是在研发早期就引入的，但是发现缺陷的时机往往会大幅度延后。缺陷发现得越晚，定位和修复缺陷的成本就越高。在系统测试阶段发现缺陷后修复的成本，大约是在代码开发阶段发现该缺陷后修复成本的40倍，或大约是在单元测试阶段发现该缺陷后修复成本的数倍，Capers Jones关于效能与质量的全局分析（如图1-2所示）直观地表明了这个观点。

图1-2 Capers Jones关于效能与质量的全局分析

根据Capers Jones的统计，大约85%的缺陷是在代码开发阶段引入的，但是因为这个阶段缺乏测试活动，所以发现的缺陷数量几乎为零。而到了软件研发的中后期，由于测试活动的集中开展，缺陷才被大范围发现，但此时的修复成本已变得非常高。

比如，在代码开发阶段引入的缺陷，以及影响接口的缺陷，要等到集成测试阶段才有可能被发现，影响用户界面和用户体验的缺陷要等到系统测试阶段才能被发现，这时返工（rework）的闭环周期被拉得特别长，这样定位问题（缺陷）、修复问题、回归测试的成本就会很高。

让情况变得更糟糕的是，Capers Jones的统计还是基于比较乐观情况的分析，因为其假定软件在研发过程中总是被严格开展单元测试和集成测试，但实际情况是，很多团队寄希望于通过最后的系统测试来发现所有问题，单元测试和集成测试往往会被“偷工减料”，这进一步产生了缺陷发现滞后的问题。