转篇文章给大家消遣一下-《测试人员的误区:迷信自动化》

liweiah

终于有时间总结一下过去几年在微软的测试经验，谈谈对测试自动化的看法。
　　先说说为什么做测试的人喜欢搞自动化。
　　第一，自尊心。计算机科班出身的人都喜欢作开发(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。 想想你如果测试用于生成http://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”。

rting

不太同意上面的观点。

yaohuangongzuo

bs一下这篇文章的作者
自己做的不好不找自己的原因，赖什么自动化！

red_tea1980

LZ的文章说的有一定的道理，不过有点以偏概全了。
LZ的说法只是基于某一中应用而已。
我没有做过应用程序的测试，基本上都是在做车载系统的测试工作。
从嵌入式开发的角度来说，自动化测试比人工测试无论是在效率还是Cost方面都有很大的优势。
嵌入式开发尤其是车载系统这种比较大型的开发，不是每次发布新机型都是全新的，至少有80%是基于母体代码改造的，甚至于除了新增的部分（每个机种变更不会超过10%），其余的都是利用原有的接口和函数进行“旧瓶装新酒”的开发的。
在这种情况下，自动化测试的好处是显而易见的，在最初的母体上将自动化测试的框架构建好之后，至少在2，3年之内是不需要改变的，在新机型开发中，只需要修改20%的旧有代码，新增10%的测试代码，这样的话，比起全人工测试，在Cost上节省的不要太多啊。
再说准确性，嵌入式开发基本上没有什么界面之类的（有也不是很重视），因此功能性测试是最重要，像LZ举例说网站的内容测试，在嵌入式开发中基本上不会有这种结果不定的测试内容。

LZ说的只是针对某些应用程序的测试，不能一棍子把自动化测试全打死啊。