测试人员会像恐龙一样从地球上消失吗？--论敏捷开发对测试的影响
随着敏捷开发的迅速推广与普及，敏捷软件开发是否还需要测试工程师的问题被越来越多的人提及，业界对此也持有两种截然不同的观点。本人觉得：随着敏捷开发的进一步推广，从未来趋势的来看，测试人员的作用与地位正在被边缘化，甚至在将来测试人员可能会像恐龙一样从地球上消失。
(先别喷，看完下文再说哈^_^)
我们先来看测试人员与开发人员比例问题
微软公司的测试人员与开发人员比例一般为1:1，谷歌公司的测试人员与开发人员比例则为1:10。
为什么两家公司的差异如此巨大呢。最主要的原因是两家公司对测试人员与开发人员工作范围的定义不同。在微软，单元测试由测试人员做(SDET)，相当于SDET再写一套代码来测试开发人员写的产品代码，其工作量不比开发人员低。而Google的单元测试和功能测试一般都是由开发人员自己来完成，测试人员主要提供自动化测试工具的支持，主要进行性能测试、负载测试、安全性测试等，而这些都是自动化工具来完成的，自然需要较少的测试人员。
再来看软件测试的发展历程
软件测试的先驱Bill Hetzel博士（代表论著《The Complete Guide to Software Testing》）给软件测试一个这样的定义：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。”他的核心观点是：测试方法是试图验证软件的功能是按照预先的设计执行的，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。软件测试业界把这种方法看作是的软件测试的第一类方法（测试是验证软件是可以工作的）。
后来这一方法受到Glenford J. Myers（代表论著《The Art of Software Testing》）的质疑和挑战。Myers认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后用逆向思维去发现尽可能多的错误。他还从人的心理学的角度论证，如果将 “验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：“测试是为发现错误而执行的一个程序或者系统的过程。”的定义。Myers认为，一个成功的测试必须是发现Bug的测试，不然就没有价值，还给出了与测试相关的三个重要观点，那就是：
测试是为了证明程序有错，而不是证明程序无错误；
一个好的测试用例是在于它能发现至今未发现的错误；
一个成功的测试是发现了至今未发现的错误的测试； 这就是软件测试的第二类方法（测试是验证软件是有错误的）。
Myers提出的“测试的目的是证伪”这一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得到了长足的发展。
然而，“测试的目的是证伪”很容易导致很多测试人员认为“测试的目的是寻找错误，并且是尽最大可能找出最多的错误”，并以BUG数作为测试人员的绩效考核。当测试人员以发现缺陷为唯一目标，而很少去关注系统对需求的实现时，测试人员会更多的用逆向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统各种的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。这种方法虽然能够发现系统中存在的更多缺陷，但这种方法很容易偏离用户需求与实际情况，测试人员往往跨越系统边界(如作了很多异常操作，但很多操作在用户处是不太可能出现的)，最终导致测试周期与测试成本的不合理增长，项目交付的延迟等。
1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。这一定义将测试从开发的对立面（给开发找BUG），转为对软件质量的度量。上述的三个定义对应Boris Beizer对测试者的认知划分的5个阶段的阶段1到3。 阶段1：测试的目的是现实软件是可工作的 阶段2：测试的目的是为了显示软件是不能 阶段3：测试的目的不是去证明任何东西，而是把软件可能不工作的预知风险制约到一个可接受的阈值下。即测试的目的从找BUG到控制质量风险。因为测试是没有办法提高质量的，只能反应软件的质量，而软件的质量更多的需要靠前期的设计与预防，测试发现的BUG越多，说明质量越差，项目按期交付的风险就越高。此外，测试也不是发现越多的BUG越好，如果这个BUG不会在客户的场景中遇到，那这个BUG就没有太大意义。
瀑布开发到敏捷开发的转变瀑布模型开发严格把软件项目的开发分隔成各个开发阶段：需求分析，概要设计，详细设计，编码，单无测试，集成测试，系统测试等。使用里程碑的方式，严格定义了各个开发阶段的输入和输出。瀑布模型更像是开发流水线，如果上一阶段达不到要求的输出，下一阶段的工作就不展开。在瀑布开发模型中开发人员与测试人员工作相互独立，测试只有在开发交付可测试的版本后才会启动，整个项目的周期就很长。敏捷开发的思想是适应客户需求的快速变化。因为只有快才可以适应目前社会的快节奏，主动接受需求变更，使设计出来的软件有灵活性，可扩展性，让客户满意，才能获得成功。敏捷开发是一种新的开发方式，更好地满足了客户的需求，应该说是未来的一个发展趋势。
对于有能力的人做什么都不会差，像测试这种如果只做一些简单手工的，下岗就下岗了，换个其他行业，也是这么混着，一些代码能力强的人可以去转开发，测试应该不会消失，因为即使你能用很强的额编码能力来开发一整套自动化测试框架，那也不可能代替新版本第一次的手工测试，所以在现阶段手工测试还是不可或缺的，如果哪一天自动化测试已经 到了可以取代手工测试的时候，那才是真正大批测试人员下岗的日子，现在根本不必担心 敏捷开发对测试的影响
敏捷联盟定义的敏捷的4个价值声明以及12条支持原则中都没有单独提到测试。传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。开发人员负责编码，测试人员负责质量验收，测试人员是软件质量的守护神，是质量的最后一道防线。在敏捷方法中，开发人员的主导作用则更加明显，系统设计、编码、单元测试、重构等看似关键的一些任务都落在开发人员身上。在敏捷开发中，强调整个团队对测试负责，可以没有专职的测试人员，通过全民测试，通过测试驱动开发，由跨功能的敏捷团队的所有人员参与以保证持续的、快速的业务价值交付。测试驱动开发的思想是敏捷测试的核心，单元测试是敏捷测试的基础。在敏捷开发中，测试被整合到整个开发的生命周期中，开发人员承担了更多的测试。
虽然测试与开发的思维方式不同，测试更注重全面的验证和检查一个系统，而开发工程师往往很难在大的范围内建立这样的思维方式。从专业化的角度来讲，专职的测试工程师更有效，所以当前敏捷开发中还会有独立的测试人员负责测试工作。但敏捷开发中的测试工作已不再是一个单独的、和开发独立的过程，而是通过驱动开发跟软件开发过程整合到一起。敏捷过程中的测试更注重开发测试与自动化测试，更多的由开发工程师自己搞定与测试相关的工作。如，Google公司的测试工作就是由开发工程师来完成的。
随着敏捷开发的进一步发展，传统的瀑布式开发模式必然逐渐退出历史舞台，敏捷开发、敏捷测试将在新的开发环境中进一步融合。
敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续的响应客户的频繁反馈。要做好敏捷测试，就需要转变测试等待开发的思想，测试人员需要了解开发过程，需要读懂代码，才能够更好的帮助开发人员分析和分离复杂问题。作为一名敏捷测试人员，需要在有限的时间内完成更多的测试的准备和执行。由于频繁的版本迭代，敏捷团队的步伐很快，黑盒测试人员们仅仅通过写测试计划，通过手工测试完成所有的测试内容已经不可能追得上在短时间内就要发布新功能的团队的进度。所以敏捷开发中的测试非常注重开发测试与自动化测试，通过大量的开发自动化测试(特别是单元测试)来应付将来需求的快速变化，实现版本的持续交付。QA则更多的扮演“用户代表”角色，负责新特性的手工测试，用户验收测试等。
测试的未来发展
好吧，我承认我有点标题党了。
正如管理大师彼得·德鲁克在《巨变时代的管理》一书中描述的蓝领工人的快速崛起和没落一样（1900年，制造业中的蓝领工人发展成为一个新的阶级-无产阶级，并成为社会的主导力量。 到20世纪50年代，蓝领产业工人在每一个发达国家都已经是人数最多的群体。他们受到了不同寻常的尊重。在所有实行自由市场制度的发达国家，他们在经济上已经成为“中产阶级”。然而，在1990年，随着知识工作者的崛起，蓝领工人及其工会出现了全面和不可逆转的倒退），测试人员的发展趋势跟这个也将类似。
测试价值在于提前预防缺陷，降低缺陷修复的成本。而缺陷发现的越早修复成本越低，通过尽早地进行开发测试，能够提前发现大部分问题。由于缺陷修复成本不同对产品质量要求也会有所差异，如，像航空航天类的产品对质量的要求非常高，那必然要求作很多的测试，这时专业的测试人员的价值就可以得到最大化的体现。但像互联网提供的WEB服务，大部分布署在数据中心的服务器上，一旦发现问题可以快速修复缺陷或直接回退版本，BUG的修复成本就明显降低，此外随着新的测试方法的产生，如在线测试方法，众包测试，可以让用户帮助作更多的测试。
雷军说“站在风口，猪都能飞起来”。周鸿祎说“任何企业 都可以找最强的竞争对手打，但有一个对手你是打不过的，那就是趋势。”当前一个明显的趋势就是：随着敏捷开发的进一步推广，测试人员与开发人员的界限将会越来越模糊，专职的测试人员虽然不会一下子消失，但将会越来越少。测试将集成到开发的每个过程中，手工测试的生存空间将会越来越小，大部分简单的重复的测试工作将会由自动化测试来代替，单纯的功能测试将会被开发测试所代替。
专职的测试人员如何体现其价值呢？“专业化”也许是一个很好的答案。对于少量的高杂性领域，测试是需要长时间积累才能精通，才能在短时间内达到高质量的要求，所以测试人员要向专家发展，提供其特殊的价值。敏捷测试人员需要在敏捷开发过程中关注产品需求，在有限的时间内完成更多的测试，指导开发人员作好开发测试，还需要能够扩展开来做更多的与测试或许无关，但与团队共同目标直接相关的工作。 写的不错，赞一个 理想很丰满，现实很骨感。。。如果存在完人，也许测试人员确实没有存在的必要。。。。试问，有多少人能做到全能型呢？？从小白到全能需要多少精力呢？你能精通所有呢？？？ 有全栈工程师，其他的IT人员全部都失业了。 说的是趋势，就像《巨变时代的管理》中描述的蓝领工人的崛起和没落一样，蓝领在未来应该还是会长期存在，但已经被边缘化了。不过测试还没有崛起就可能会快速没落了:( 开发思维与测试思维有本质的不同，测试永不会被替代。
认同：不同的项目，需要的测试人员数量与技术有所不同。 真好，支持支持楼主 这个要看趋势，如果中国发展的好，不是不可能，那时候现在大部分的测试人员需要转换工作，转型，但目前这种情况不会大面积发生，原因有一些，比如楼主提到的开发替代测试，那么开发人员在测试自身的开发代码的时候能否那么客观，人总是会对自己的产品有维护心态的，这一点还无法改变，那么如果让开发人员互相测试彼此的代码，就可以解决这问题，但在中国又有了新的问题，即测试代码的代码量往往比开发本身的代码量还要大，在一个急功近利的组织里面，没有充分的时间去编写和维护测试代码，那么怎么算？现实的情况是，开发人员往往自身开发代码编写完还来不及，根本没有时间对测试代码完成编写和测试，那么这一套理论就无法进行下去，要推广需要先决条件，不解决就难以真正推广 从几个方面看，测试应该还是要保留的
1，国内很多还是做项目为主，项目有成本和工期，质量的关系，在项目非常赶的情况下，往往是很难把控质量的，开发人员根本没时间投入
2，还是有很多公司实行目标考核，开发人员按任务量完成工作，把功能实现了就算完成了，至少什么边界，异常情况，友好提示，用户体验方面还是有很大的提升空间
3，不能说全部，但很大一部分开发人员，只管编码，而不是想着把产品或项目做好。把负责的模块写好了就行，至于项目或产品最终如何并不是很关心，好象不关自己事一样
4，还有很多公司是没有条件做单元测试的
5，系统出现问题，各个环节先是扯皮，推责任，然后再考虑解决问题。推到最后谁也没有责任，最后就大家才想起把问题解决了吧 理论归理论。但是真是做起来。你需要考虑的一样就是，怎么做才是最省成本的。
google,微软等大公司，有财力，也有这个技术去做到很极致。
google的程序员什么水平？一般公司的程序员又是什么水平？
微软就有这个能力做到测试开发1：1，而你想想他们的测试团队的技术水平有多高？如果是他们的测试开发工程师，其技术能力就不比开发差。
但是一般的小公司，或者技术能力没他们好的公司呢？
能测试去替开发做测试这个繁琐的工作，那其效率可能是更高的。所以测试也不那么容易就失业吧。 很好，看了之后解决了很多很久以来心中的疑惑。 以后的事，谁知道呢，过好现在就行了 如果测试能够技术升级，就不会问题，仅仅是手工，很可能被互联网模式取代。现在原生数字化软件测试已经在成为第2代的测试技术了。 danran_9966 发表于 2015-6-30 12:54
如果测试能够技术升级，就不会问题，仅仅是手工，很可能被互联网模式取代。现在原生数字化软件测试已经在成 ...
什么是原生数字化软件测试
页:
[1]
