|
今天刚看到这篇关于一个微软员工测试自动化的经验之谈和各高手关于这篇文章的一些精彩争论,这篇文章有些长,大家需要有些耐心才能看完,希望无论
是新手还是高手都能各述己见,可能这篇已经被原创发帖过或有前辈已经把这篇文章转载过,如果已经发过了,给那些没有看到的人看看也好啊!文章出处:http://www.cnblogs.com/qiubole/archive/2007/07/24/829395.html
今天七月四号美国国庆节,有时间坐下来总结一下过去几年在微软的测试经验,谈谈对测试自动化的看法。
先说说为什么做测试的人喜欢搞自动化。
第一,自尊心。计算机科班出身的人都喜欢作开发(Dev)。做测试工作经常是身不由己,可是测试工作很多时间不需要编程,于是做测试的人想方设法写些程序,以显示自己也会编程。结果往往是欲罢不能,测试自动化程序越写越多,越写越复杂。后面我会谈谈测试自动化框架复杂的代价。
第二,为了出成绩。很多测试组为了向管理层展示成绩,往往要拿出例如测试自动化达到80%,程序覆盖率达到90%。要我说,这些都是Bull Shit. 就象小平同志说的“实践是检验真理的唯一标准”,我认为在测试中“用户不出问题是检验质量的唯一标准”。自动化做的再多,用户出了问题,也是白搭。另外,一个人就可以做的测试,自动化往往需要两个,三个。倒是解决就业的好方法。
我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化,想方设法写一些从头到尾自动化的框架,觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想,用自动测试发现的问题基本上可以一个人用手工测试完成,最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时,所有户界面完全变了,80%以上的自动测试程序都需要改动。做完第一个版本,我们三个人全都走掉了。后面来的人往往宁可自己再写一套,也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的,所有人都想另搞一套。
下面分几点讲讲为什么要放弃对测试自动化的幻想,和怎样进行低成本的有效测试。如果你还不能同意我对测试自动化的看法,可以去这个微软员工的Blog http://minimsft.blogspot.com/2006/08/dev-vs-test-vs-pm.html 去看看为什么Windows测试组用的WTT测试框架被称作“Waste of Tester Time". 我最基本的观点不是说测试自动化不能测出bug,而是想问: 一个比较复杂的测试自动化框架所造成的人力浪费,值不值得最终的结果?如果不做测试自动化,能不能达到同样的效果。以我的亲身经历,去年我的测试组两个人对应开发组五个人,项目经理三个人的工作量,去年做了好几个Release,Hotfix只有两三个。我们旁边的测试组七八个人对应五六个Dev. 他们又是自动化,又是搞程序覆盖率,好不热闹,Hotfix 也不少。按一个人的人工成本12万美元,我们组省至少三个人的成本36万美元。
第一,不要指望自动化能帮你找bug. 软件bug和生物的bug很像,测试的规律是bug少的地方bug越少,bug多地方越找越多。做测试自动化,往往在开发自动化的时候,该发现的bug就发现了。自动化开发完成,再想发现更多bug就很难了。这是无论你怎样跑你的自动化,也不会发现新的bug.
第二,不要指望自动化对Regression Test的测试的贡献。软件的特点是如果一次做对了,以后永远不会出错。当程序出现变动时,只要针对变动的部分测试就可以了,以前测过的东西,如果和变动没有关联就不会出错。相反如果,程序出现很大变化,自动化可能完全不能用了。
第三,自动化不如测试工具加手工测试。我不建议测试人员作全面自动化,相反我建议测试人员多做小巧灵活的测试工具。自动化往往需要自动判Pass或Fail. 想想你如果测试用于生成www.microsoft.com的页面的产品,你如何判断页面框架生成的正确?很多东西是动态产生的,你很难确认所有的内容的正确性。如果你自己用这个产品手工做个页面,用肉眼很容易判断所有相关和不相关的内容生成的正确性。我就是用这个方法在工作中发现了网页上谁也想不到的bug, 如果用自动化很难在测试阶段发现这个bug.
第四,软件项目的生命周期就定了自动化的无用。现在很多网络应用项目的生命周期都很短,一个项目从生到死不过两三年。死的定义是项目进入Sustain Engineering维持状态。自动化原来的一个主要目的是使软件测试的未来阶段越来越容易,成本越来越低。可是当一个项目死掉了,自动化还有什么用。而且最新的敏捷开发,软件的要求,程序,接口,界面在不断变化,自动化怎么可能跟得上变化。与其去搞自动化,不如多理解变化,直接测试变化的东西。
如何进行有效测试?
第一,测试人员的自信心可以建立在读程序的能力上。在一个项目中,开发人员的工作是研究新技术,写出最好的程序。测试人员应该在开发人员研究的基础之上,更好的理解新技术,读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人,可能会设计三十个test cases, 才能找到一个bug. 懂程序的人每个test case都可能发现一个或多个bug. 我有30%的bug都是读程序读出来的。由于对开发人员的程序有很深的理解,即使release后出了问题,也能很快理解问题出在什么地方,是否是bug.
第二,测试人员写测试程序的时间应该尽量最小化。测试人员测试的时间分配应该是, 30%读程序,20%写测试程序,50%写Test Cases和运行Test Cases. 好的测试员的工作重点应该放在理解要求,理解客户需要,思考在什么条件下程序会出错,而不是思考如何去自动化。如果时间都放在设计自动化上了,必然会影响测试,分散测试资源。测试人员应该边读程序边测试,读程序帮助找到好的Test Case,测试帮助验证理解和猜测。
第三,测试人员要学会讨价还价。很多时候项目经理,开发人员搞得东西不是客户马上需要的,或许是永远用不到的。测试人员可以和项目经理研究先测什么,后测什么,那些不测。比如,我做的一个项目,我发现30%的功能是现在用处不大,所以我直接告诉项目经理那些东西我不会去测的。事实证明,这样做节省了很多人力。
第四,测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中,去比较当前版本和以前版本的所有程序变化。重点测试变化。
总之,少做自动化,多写小工具,读懂程序,是高效省钱的测试方法,除非你钱多得没地方花。下次有谁建议搞什么测试自动化构架,告诉他"That is bullshit".
omomo
有需求才会有程序.测试自动化也是. 楼主是一个很有分析能力的测试人员,而且编程能力也不弱,所以才说出读程序+测试小工具+测试的经验.但你这样的牛人仍然只能保证你的模块的质量,如果我们需要让你保证更多的人的模块的质量,总归要从自动化测试上面来打主意了.否则你的这种测试经验没有办法容易的被人拷贝学习.而你的测试代码是很容易被人拷贝学习的.呵呵
所以一种情况是,你想出来的测试用例,可以利用自动化测试框架自动运用到各个模块中去.比如,你想出来界面上不能有重复的hotkey,那么一个好的自动化测试框架应该允许你迅速把这类测试用例运用到各个UI上去测试.
另外一种情况是,人没有办法做的,比如并发的压力测试,像gamerrob提到的那种.
其次说到,regression test,我觉得也是有用处的:"软件做对了一次,以后就永远不会错?", 这话说得太离谱,很多看似没有关联的改动,往往会导致隐藏的bug的出现,有一个完整的自动化测试集的好处是,至少当你的开发人员改动了基类或者基本底层API的时候,可以通过运行上层功能的自动化测试集保证改动没有破坏功能.否则,难道他的改动要求所有测试人员把所有功能手工的全部跑一便?光协调通知各个测试组,恐怕就得花一周时间.
自动化测试的分工本来就是慢慢将写自动化测试工具的人和手工测试的人分开,难道楼主以为写VS里面的webtest工具和code coverage不需要时间,不值得做?手工测试将慢慢外包,而公司培养的自动化测试工程师将通过积累和筛选,最终有些人会去主导那些重量级测试工具的开发. 这和程序员也没有什么区别. 微软的程序员,也有写简单的代码,基本属于把人家基类的接口实现一下的. 也有真正牛比的大师.只不过在不同的职业阶段.
楼主有一个观点,我非常认同:理解产品,找到缺陷才是测试人员的本质.任何时候,沉浸在自动化测试中的人,都不是合格的测试人员.所以在我的团队里,我把理解产品功能放在编程能力之上.只有一个非常理解产品功能知道用户会怎么用这个产品的人,才能写出有效的测试用例.楼主说的很好:不懂内部程序的人,可能会设计三十个test cases, 才能找到一个bug. 懂程序的人每个test case都可能发现一个或多个bug.
发表时间:2007-07-17 16:46:29 4 楼:peking2toronto 驳斥)迷信自动化是测试人员的误区 (1)
今天七月四号美国国庆节,有时间坐下来总结一下过去几年在微软的测试经验,谈谈对测试自动化的看法。
[comments]今天看到这篇关于自动化测试的文章,有很大的误导作用,我也谈一下对自动化测试的看法。首先,作者是一个在微软工作了几年的一个测试人员,总结的是在微软的测试经验。可是他总结的并不是典型的微软公司的测试观点,而是自己个人的测试观点。因此,他的观点实际上是与微软公司没有太大关系的。这点,大家还是不要被误导。众所周知,微软在几年前对测试有一个大的改变。以前微软有两种职位,STE和SDET,前者是手工测试,后者是自动化测试。微软把STE基本cut掉了,因此STE要不走人,要不转SDET。转过来的,因为以前主要是手工测试,因此就对自动化测试产生很大的抵抗情绪。这种情绪是team lead很不愿意看到的。因此,STE的困境是比较大的。还有就是在微软里做几年如一日的测试人员大有人在,因为能力问题,级别得不到提升。因此,几年还是junior。所以,在微软做几年测试,也不代表就是一个级别很高的人。
另外要说明一点,从文章的title里可以看到,这篇文章是说给迷信自动化测试人员的。作者以前本身就是一个迷信自动化测试的人,可是后来从迷信变得不相信自动化测试了。可见作者是一个很容易走极端的人,从头到尾都没有用一个公平理性的态度去面对自动化测试。还有就是,这个文章如果给迷信自动化测试的人看,还是有一定意义的。可是,我们当中有几个人像作者以前那样迷信自动化呢?大部分看了可能会觉得是针对整个自动化来讲的,而且作者确实也偏离了他的title,因此我也需要澄清一下。 |
|