原文地址:http://www.chinatesting.cn/h/2792/357525-19700.html
大部分搞软件测试的人都比较喜欢自动化测试,因为可以一边测试一边看动画片,当然这些是玩笑话,那为什么测试人员非常喜欢自动化测试呢?
第一,自尊心。计算机科班出身的人都喜欢作开发(Dev)。做测试工作经常是身不由己,可是测试工作很多时间不需要编程,于是做测试的人想方设法写些程序,以显示自己也会编程。结果往往是欲罢不能,测试自动化程序越写越多,越写越复杂。后面我会谈谈测试自动化框架复杂的代价。
第二,为了出成绩。很多测试组为了向管理层展示成绩,往往要拿出例如测试自动化达到80%,程序覆盖率达到90%。要我说,这些都是Bull Shit。就象小平同志说的“实践是检验真理的唯一标准”,我认为在测试中“用户不出问题是检验质量的唯一标准”。自动化做的再多,用户出了问题,也是白搭。另外,一个人就可以做的测试,自动化往往需要两个,三个。倒是解决就业的好方法。
我对测试自动化的认识也有一个变化的过程。刚刚入行时也是很相信自动化,想方设法写一些从头到尾自动化的框架,觉得自动测试很过瘾。到微软的Portal Media Center组后也是和另外两个人做了一个相当复杂的用户界面的自动测试。其实现在想想,用自动测试发现的问题基本上可以一个人用手工测试完成,最多写些简单的测试辅助工具就可以完成。有些人可能会说自动化可以为产品的下一个版本节省测试时间。其实Portal Media Center 下一个版本出来时,所有户界面完全变了,80%以上的自动测试程序都需要改动。做完第一个版本,我们三个人全都走掉了。后面来的人往往宁可自己再写一套,也懒得改以前人的程序。自动化的浪费就是这样造成的。想说服别人用你开发的自动测试框架是很难的,所有人都想另搞一套。
下面分几点讲讲为什么要放弃对测试自动化的幻想,和怎样进行低成本的有效测试。如果你还不能同意我对测试自动化的看法,可以去微软员工的Blog看看为什么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。 很多东西是动态产生的,你很难确认所有的内容的正确性。如果你自己用这个产品手工做个页面,用肉眼很容易判断所有相关和不相关的内容生成的正确性。我就是用这个方法在工作中发现了网页上谁也想不到的bug, 如果用自动化很难在测试阶段发现这个bug。
第四,软件项目的生命周期就定了自动化的无用。现在很多网络应用项目的生命周期都很短,一个项目从生到死不过两三年。死的定义是项目进入Sustain Engineering维持状态。自动化原来的一个主要目的是使软件测试的未来阶段越来越容易,成本越来越低。可是当一个项目死掉了,自动化还有什么用。而且最新的敏捷开发,软件的要求,程序,接口,界面在不断变化,自动化怎么可能跟得上变化。与其去搞自动化,不如多理解变化,直接测试变化的东西。