不测试是假的，但测试左移是真的（实践篇）

摘要：

        测试左移本质上是要尽早的发现，预防问题，使用必要的测试手段在软件开发生命周期的早些阶段发现问题。

正文：

       《代码大全》很早就从软件工程实践角度说明了一个bug产生的不同阶段，修复一个bug的成本从需求阶段，设计阶段，测试阶段有着天壤之别。不仅从成本上，从修复难度，引入新问题的可能性，沟通成本，团队状态也会有很大的影响。 可见没有问题比“引入问题然后发现问题最终再修复问题”要重要得多。

        上图中表现了传统瀑布式的开发模型中缺陷、测试、修复成本的变化曲线，蓝色代表缺陷引入的阶段分布，黄色代表了缺陷发现的时间分布，红色代表了缺陷修复的成本，可以明显看出，缺陷越晚发现修复成本越高。

        没有问题比“出现问题然后发现问题再解决问题”当然好得多，可是我们做不到没有问题，但如果能够在尽量早期的时候发现问题或者预防问题，那么我们花费的时间成本、资源成本也将小的多。

        近几年呼吁做测试左移的咨询机构以及相关的文章也越来越多，普遍认可了测试左移的重要作用，对于测试左移的具体实施也有很多“最佳实践”以及指导。

        普遍认为测试左移需要做的事有以下几项：

1、代码扫描；

2、开发标准定义；

3、测试分层（单元测试、接口测试、UI自动化测试、手工测试）；

4、验收测试

        目前有一种通用的解法是提高研发质量，即在交付测试前发现更多的缺陷，通过代码扫描、单元测试的方法进行实施。同时配合测试分层，更早的开始测试执行，同样是为了更早的发现缺陷。

        通过以上实践之后，我们会发现产品质量以及成本付出有了很明显改善，缺陷将在更早期被发现，也将在更早期被修复。

        以上的图形并不是我们最终要的结果，我们要的是预防缺陷，尽可能的做测试左移，移到什么地方才是合理的呢？

        我们首先需要看看生命周期有哪些活动，生命周期中包含了需求、设计、编码、测试、验收几个过程。

        那如果把测试放在和编码同时开始是否合适呢？其实很多企业已经在这么做了，即测试开发并行，这算不上什么左移。那如果测试和设计并行开始呢？好像是迁移了一点点，那就是要对设计做要求，从设计阶段减少问题，或者发现问题。既然都到设计阶段了，那我们就干脆考虑是不是还可以再向前一点点，那就让测试和需求并行吧，测试和需求同时开始，这样子够靠前了吧。

        把测试提到如此靠前的位置该怎么开展落地呢？我做了以下设想，准备在未来的项目中试验一下。

        首先，测试左移的字面意思就是把测试向左移动，那么如果我把开发右移了，是不是就相当于测试左移了，那么之前开发要在需求结束之后开始工作，现在是不是可以在测试之后开始工作呢。将测试工作进行分层，分为需求分析阶段、开发编码阶段、动态测试阶段、测试结果分析阶段。

        需求分析阶段，测试对用户、产品、环境、需求等进行通用问题和专项问题的分析，将分析结果汇聚成文档（需求分析结果），作为开发输入的一部分，即开发需要按照需求文档以及需求分析结果进行开发，需求及需求分析结果作为开发交付测试的标准。此方法作为缺陷预防的手段。

        其次，引入代码扫描、单元测试等方式，在开发阶段消除缺陷。

        最后，在动态测试阶段，也是我们口中的手工测试/功能测试阶段，进行测试执行，运行系统发现缺陷，在此处需要配合精准测试工具，利用精准测试工具进行“测试的质量评估”，此时需要做减少冗余案例、评估“测试的质量”、给提高测试案例质量提供指导的工作。

        最最后，对以上所有测试相关及缺陷相关事项做事后分析，在下一次的实施中做指导和优化，不断地提升规范水平和人员能力。最终可以达到下图中的效果，总缺陷数减少了。产品质量越来越好。

谢谢您的关注，祝您工作顺利，天天开心！！！

谢谢您的关注，祝您工作顺利，天天开心！！！

谢谢您的关注，祝您工作顺利，天天开心！！！