软件测试已死?
作者:网络转载 发布时间:[ 2013/1/28 11:04:20 ] 推荐标签:
问题:
keynote里面作者说满足了三个条件之后,tester这个工作基本是多余的。
1、所有关于checking的工作(validation跟verification)都可以自动化之后。
2、可以让部分用户在cloud上面对开发的版本做测试。
3、开发者必须自己做测试,而且团队里面没有测试人员。
在测试领域里面,现在也着重于说testing只是提供Information,而且是一说明testing不是checking(http://www.developsense.com/blog/2009/08/testing-vs-checking/),所以Alberto Savoia说的test is dead到底是不是只是指checking?那测试以后的发展到底该如何呢?大家是不是也是觉得test is dead呢?
精彩回答:
在2012年的Agile Testing Days大会上,Lisa Crispin和Janet Gregory他们的演讲《Debunk Agile Testing Myths》里面的第一条myth是“test is dead”,当然不是啦,只是换了context而已。
其实,test到底有没有死,完全看我们对这个test的定义是什么。
- 如果我们认为,做测试的,还是那些人、还是那些事、还是那些方法,那么,当然,它已死。
- 但是,如果我们能够意识到,同一个“test”单词,从它诞生以来,它的含义和实现方法一直在变化,只要能够迎合乃至拥抱这些变化,我们能永存。
其实,不管是Alberto Savoia说的Test is Dead,还是Michael Bolton所说的Checking vs Testing,说的都是一件事情:“是否把事做对了”如今已经不如“是否做对了事”那么重要。更因为,由于高速发展的各种技术,“是否把事做对了”这件事情可以做到高度自动化、不需要测试人员的人工参与。
传统方式里,针对需求针对规格说明书等等各种文档设计出测试用例进行测试的方式,这些功能一定程度上可以说其结果完全是可预期的,因而也完全可以做到在写代码之前,或写代码的同时,已经把测试写出来了。由于这样的测试,本质上来说是验证代码是否能够实现预期中的功能,也即代码是否会出错,那么,又有谁能够比代码实现者本人更了解这些可能出错的地方呢?
当然,很多人会说,包括我自己也认同,测试、开发两种人群,做测试的一大区别在于“test mindset”,但是回过头想想,又有哪个测试人员是从一开始有test mindset的呢,不也是在不断测试的过程中培养起来的吗?既然测试人员可以,开发人员为什么不可以呢?而且,即使是传统的测试方式中,测试组织想做的事情也是希望开发人员能够从源头遏制住各种bug。而且,更早发现bug意味着修复的成本也越低,一定程度上可以说,只要“开发人员也做测试”这件事情可以发生,那么它不会以我们这些不情愿的测试人员的意志而转移,它会是一个必然的潮流。
那么测试人员到底能做些什么呢?我认为是要做哪些无法被自动化的事情,虽然被称为Checking的那部分内容可以被自动化,但是,机器却很难替代测试设计的过程,以及从测试中学习被测系统并思考下一步的这些活动。而同时进行学习、设计、执行和分析这四个步骤的这种测试方式,也是探索式测试的主张。其实,从某个角度来讲,如果我们拉长这四个步骤,到每个步骤的长度都以“月”为单位计算的时候,我们可以说,这是传统的测试方式;当我们缩短这四个步骤,到每个步骤都以“分钟”来计算长度的时候,我们可以说,这是……呃,探索式测试?
但是,如果所有的测试都可以通过分析需求、说明书等方式预先知道的话,还有什么是需要探索的呢?答案是复杂系统中,被遗漏的那些角落;以及随着系统不断变复杂,可能出现的各种复杂叠加效应的地方。当然,系统越复杂越容易出问题,所以,都想要把系统设计的简单些,或者是做到复杂但可控或行为可预测,因而,从某种程度上来讲,这一块的工作量也在萎缩,或者说,应该会萎缩。而且,如果我们仔细地去追究,会发现,系统的复杂度本质上来自于系统架构和设计的复杂度,这又把我们带回到了前面的那段推论,这是开发人员容易着力的地方,如果他们可以做出一个架构和设计更为灵活和稳固的系统,那么这样的系统对于“专职测试人员”(传统测试人员,或只做探索式测试的测试人员,在此都一样)的需求会更弱。
所以,在Alberto Savoia看来,验证系统是否运作正常,远不如验证“系统这个想法”是否有价值,来得重要。而传统的测试理论中,对这个部分则很少涉及。但软件测试不只是测试软件本身,这样的说法,温伯格早在他的完美软件一书中说过。而Gojko Adzic在Agile Testing Dasy 2012大会上更是提出了Agile Testing Days 2013 – Program “Reinventing software quality”,他认为我们并未把握关键——产品面市后到底能否得到认可,感兴趣的话可以看他的博客Redefining software quality和视频Reinventing software quality: video,不是这次大会上的视频,但也可以参考。至于,验证想法是否可行,大家可以看看这个来自于国内实践者的视频分享,【一席】任鑫《我的精益创业》。
当然,还有另一个原因在于,说出这些话的人,他们所处行业中软件产品出差错之后的影响到底如何,如今消费级的软件已经越来越普及化越来越多,从软件厂商的角度来看,快速地捕捉用户稍纵即逝的需求,迅速抢占市场地位,这个优先级远远高于推出一款不出问题的产品,因为,在这样的市场上,时间是金钱。而软件错误,对于消费级软件来说,则并不像以往对于企业级系统甚至更关键系统而言的那么值钱。
如果要做一个总结陈词的话,我会说:有的测试虽然活着,但却已经死了;有的测试虽然死了,但却已然还活着。
你愿意做僵尸,还是做死而复生的新生儿?
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11