测试人员会像恐龙一样从地球上消失吗？--论敏捷开发对测试的影响

http://blog.sina.com.cn/s/blog_8f58d8050102v75h.html

随着敏捷开发的迅速推广与普及，敏捷软件开发是否还需要测试工程师的问题被越来越多的人提及，业界对此也持有两种截然不同的观点。

本人觉得：随着敏捷开发的进一步推广，从未来趋势的来看，测试人员的作用与地位正在被边缘化，甚至在将来测试人员可能会像恐龙一样从地球上消失。

(先别喷，看完下文再说哈^_^)

我们先来看测试人员与开发人员比例问题

微软公司的测试人员与开发人员比例一般为1:1，谷歌公司的测试人员与开发人员比例则为1:10。

为什么两家公司的差异如此巨大呢。最主要的原因是两家公司对测试人员与开发人员工作范围的定义不同。在微软，单元测试由测试人员做(SDET)，相当于SDET再写一套代码来测试开发人员写的产品代码，其工作量不比开发人员低。而Google的单元测试和功能测试一般都是由开发人员自己来完成，测试人员主要提供自动化测试工具的支持，主要进行性能测试、负载测试、安全性测试等，而这些都是自动化工具来完成的，自然需要较少的测试人员。

再来看软件测试的发展历程

软件测试的先驱Bill Hetzel博士（代表论著《The Complete Guide to SoftwareTesting》）给软件测试一个这样的定义：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。”他的核心观点是：测试方法是试图验证软件的功能是按照预先的设计执行的，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。软件测试业界把这种方法看作是的软件测试的第一类方法（测试是验证软件是可以工作的）。

后来这一方法受到Glenford J. Myers（代表论著《The Art of SoftwareTesting》）的质疑和挑战。Myers认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后用逆向思维去发现尽可能多的错误。他还从人的心理学的角度论证，如果将“验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：“测试是为发现错误而执行的一个程序或者系统的过程。”的定义。Myers认为，一个成功的测试必须是发现Bug的测试，不然就没有价值，还给出了与测试相关的三个重要观点，那就是：

测试是为了证明程序有错，而不是证明程序无错误；

一个好的测试用例是在于它能发现至今未发现的错误；

一个成功的测试是发现了至今未发现的错误的测试；

这就是软件测试的第二类方法（测试是验证软件是有错误的）。

Myers提出的“测试的目的是证伪”这一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得到了长足的发展。

然而，“测试的目的是证伪”很容易导致很多测试人员认为“测试的目的是寻找错误，并且是尽最大可能找出最多的错误”，并以BUG数作为测试人员的绩效考核。当测试人员以发现缺陷为唯一目标，而很少去关注系统对需求的实现时，测试人员会更多的用逆向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统各种的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。这种方法虽然能够发现系统中存在的更多缺陷，但这种方法很容易偏离用户需求与实际情况，测试人员往往跨越系统边界(如作了很多异常操作，但很多操作在用户处是不太可能出现的)，最终导致测试周期与测试成本的不合理增长，项目交付的延迟等。

1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。这一定义将测试从开发的对立面（给开发找BUG），转为对软件质量的度量。

上述的三个定义对应Boris Beizer对测试者的认知划分的5个阶段的阶段1到3。

阶段1：测试的目的是现实软件是可工作的

阶段2：测试的目的是为了显示软件是不能

阶段3：测试的目的不是去证明任何东西，而是把软件可能不工作的预知风险制约到一个可接受的阈值下。

即测试的目的从找BUG到控制质量风险。因为测试是没有办法提高质量的，只能反应软件的质量，而软件的质量更多的需要靠前期的设计与预防，测试发现的BUG越多，说明质量越差，项目按期交付的风险就越高。此外，测试也不是发现越多的BUG越好，如果这个BUG不会在客户的场景中遇到，那这个BUG就没有太大意义。

瀑布开发到敏捷开发的转变

瀑布模型开发严格把软件项目的开发分隔成各个开发阶段：需求分析，概要设计，详细设计，编码，单无测试，集成测试，系统测试等。使用里程碑的方式，严格定义了各个开发阶段的输入和输出。瀑布模型更像是开发流水线，如果上一阶段达不到要求的输出，下一阶段的工作就不展开。在瀑布开发模型中开发人员与测试人员工作相互独立，测试只有在开发交付可测试的版本后才会启动，整个项目的周期就很长。

敏捷开发的思想是适应客户需求的快速变化。因为只有快才可以适应目前社会的快节奏，主动接受需求变更，使设计出来的软件有灵活性，可扩展性，让客户满意，才能获得成功。敏捷开发是一种新的开发方式，更好地满足了客户的需求，应该说是未来的一个发展趋势。