对测试自动化的看法－来自微软讨论组的争论
转载：http://www.ltesting.net/ceshi/ceshijishu/zdcs/2007/0719/139415.html
说明：我没有百分百的转载该文件，部分摘要和重点标注
**************************
首先是一个人的吐槽，以下是详细内容
先说说为什么测试的人喜欢搞自动化。
1、自尊心。计算机科班出身的人都喜欢做开发（DEV）。做测试工作经常身不由己，于是做测试的人想方设法写些程序，以显示自己也会编程。结果往往是欲罢不能，测试自动化程序越写越多，越写越复杂。
2、为了出成绩。比如说测试自动化达到多少，程序覆盖率达到多少。觉得“用户不出问题是检验质量的唯一标准”，如果一个人可以做的测试，自动化却需要两个，或者三个，这是有待考量的
他对测试自动化的认识也是个渐变的过程。刚开始想方设法自动化，后来到微软的Portal Media Center组后做了一个相当复杂的用户界面的自动测试。现在想想，用自动测试发现的问题基本上可以一个人用手工测试完成，最多再写些简单的测试辅助工具就可以完成。并且，Portal Media Center下一个版本出来后，用户界面完全改变，80%的自动测试程序都要改动。维护的人走掉后，后面的人又宁可自己再写一套，这样就造成浪费。
后面提到了为什么放弃对测试自动化的幻想，和怎么进行低成本的有效测试（这个我感兴趣）。他的一个基本观点，不是说测试自动化不能测出bug，而是想问：一个比较复杂的测试自动化框架所造成的人力浪费，到底值不值得？如果不做测试自动化，是否能达到同样的结果。后面有提到和另一个完全自动化的小组的对比，提到自己组节省了人力成本。
最后他提了四个观点：
1、不要指望自动化帮忙找bug。做测试自动化，往往在开发自动化的时候，该发现的bug就发现了。自动化开发完成后，想发现更多的bug就很难。
2、不要指望自动化对回归测试的测试贡献。因为，软件的特点是如果一次作对了，以后永远不会出错。当程序出现变动时，只要针对变动的部分测试就可以（这个我不能苟同）；如果程序出现很大变化，自动化可能完全不能用了。
3、自动化不如测试工具加手工测试。不建议全面自动化，建议多做小巧灵活的测试工具。因为自动化往往需要自动判pass或fail，想想你如果测试用于生成www.microsoft.com的页面的产品，你如何判断页面框架生成的正确？很多东西是动态生成的，你很难确认所有的内容的正确性。
4、如果一个项目生命周期很短，自动化还有用么？与其去搞自动化，不如多理解变化，直接测试变化的东西。（有点绝对化了）
他提了有效测试的4个方法：
1、测试人员的自信心可以建立在读程序的能力上。看懂程序可以是测试工作非常高效，设计有效地test case，有30%的bug是读程序读出来的，而且relase后出问题，可以很快确认是否是bug，和问题出在什么地方
2、测试人员写测试程序的时间应该尽量最小化。30%读程序，20%写测试程序，50%写test case和运行case。工作重点在理解要求和客户需要，思考什么条件下会出错。
3、测试人员要确认先测什么，后侧什么，哪些不测。
4、测试人员要多花时间参与设计。理解每个要求的影响。
总之，多写小工具，读懂程序是高效的测试方法
**************************
后面是批驳的观点
1、测试自动化，有利于被人拷贝学习；适于压力测试；
2、测试自动化对回归测试，可以提供一个完整的自动化测试集，可以保证修改基类或底层API等，没有破坏功能，也不需要人手工跑完所有的功能
3、自动化可以解决我们的测试问题：一个是自动化可以完成手工不能完成的任务，二是自动化可以替代手工重复的劳动。
4、自动化测试可以节省人力
5、功能测试根据被测对象主要分为三种类型：UI测试，command line测试和API测试。后两部分非常适合自动化来作为主要方法进行测试。
6、需要思考什么应该自动化，什么不应该自动化，这都是有一定学问的。
7、做相对简单的自动化，合理的自动化
8、自动化测试的非常重要的一个目的就是保证没有回归问题
9、测试方法有很多，读程序是一个非常好的测试方法，但是我们需要更多地方法来对软件全面测试
10、搞自动化大多数是从黑盒测试的角度出发的。
********************
后来作者又做了一些补充
什么是自动化
我定义的自动化是指较大的框架。举例说，如果你要测一个API，这个API的其中一个参数是C# String，如果有必要测很多不同的Unicode值，当然写个程序测最快，最可靠。另外Stree/Performance测试都要写程序。我觉得这个不叫自动化，这是SDET的基本功。我也反对没有必要的自动化。比如，有些测试要检验Event Log的内容，有些人把.NET中读Event Log的库函数再打包写个自动化库，认为这样把原来需要五行完成的动作一行完成很酷。其实，你想想自动化库带来的维护问题比解决的问题还多。本来，.NET的文档很清楚，你的自动化库文档又不全，出了问题还得找源程序，还得有人改自动化库。麻烦不知道是少了还是多了。另外，我所说的手工测试包括写测试程序，但测试程序侧重的不是自动化，而是探索测试Exploratory Test.
自动化在测试中的地位下降
另外我观察自动化在测试中的地位下降。测试人员的大忌就是在测试开始把自动化作为首要目标。一般来讲，过去我们把测试自动化作为目标之一，总是想完成手工测试后，在有时间要做自动化。可是实际情况是，项目进度太快，根本没有时间做自动化。一般手工测试完成后，产品就发布了。
测什么不测什么
和PM讨价还价不是偷工减料。一般讲，在项目开始阶段，测试人员的发言权最低。很多东西测试人员是没法控制的。PM总想多加功能，即使现在没用，想着将来会有用。有的项目，Dev有很大的支配权，Dev可以加入很多他喜欢的东西。（很吃惊吗，现实就是这样）。测试人员只有在测试阶段讨价还价的份儿。
有人认为我说“软件的特点是如果一次做对了，以后永远不会出错。”很荒谬。我承认有点极端。我的意思是，你在测试时肯定要假设有些东西是对的，不用测的。比如.NET的库。测试完成了投入使用了一段时间后，就可以假定当前的软件基本符合要求，不需要进一步测试了。必须学会画一条测与不测的线，否则测试会无休无止。我们大多数人接受的项目肯定是前人基础之上的项目，新的版本出来了，我们肯定要假定没有变动的，没有涉及程序不会出错，重点测试变动的部分，分析可能会涉及的部分。具体讲可以用Beyond Compare比较程序的变化。
当然，这个假定在一定程度上是错的。前人做得程序可能会出错，.NET库函数也有错，如果不在当前测试人员的工作范围，这种错误是可以接受的。如果你能找出前人的错误，发现.NET库函数的错，说明你确实出色。但从往往时间上讲，你能做到这步的机会有限。当然，我发现的最得意的bug就是在产品中隐藏了五年之久，我讲出来都替微软丢人的安全漏洞。我发现这个bug就是读程序偶然读出来的。读的时候，脑子里多打了几个问号，然后动手一测，果然如我所料。
WhiteBox Test + Exploratory Test
我的测试哲学是WhiteBox + Exploratory Test。测试开始阶段要读懂要求，理解设计。然后是读懂程序，在程序中找问题。这就是WhiteBox Test。然后动手写一些测试程序，测试程序的原则一定要简单灵活但自动化程度不高。测试程序的主要目的是探索，手工探索，目测探索软件那里会出错。之所以要做探索测试，就是因为自动化要求对输入输出都要很准确的定义。输入好控制，可是没有探索测试，很难准确知道输出是否正确。自动化必须建立在探索测试的基础之上。就像用一只单发的步枪，一发一发精确打击敌人防御的弱点，不是用机关枪盲目扫射。单发的好处是，每打一枪你都要目测效果，然后调整子弹大小，射击的远近。如果像机关枪打出一百多发子弹，你会视觉疲劳，无所适从。自动化就像一只机关枪。
我的观点只是一家经验之谈，不是理论，大家可以借鉴，不要照搬。
关于，美国软件业大公司的人工成本是公开的，新闻里可以查到，平均大概是十一到十五万，当然包括各种福利，和管理成本。
本回复于：
2007-07-18 14:35:26 被【dlele】修改
发表时间：2007-07-18 14:12:09 9 楼：dlele
自动化是理想，手工测试是现实，我讲的是理想与现实的差距。这个差距不是我个人能力的差距，而是敏捷开发，产品周期加速，复杂度增加，相对人力资源有限所带来的现实造成的差距。
发表时间：2007-07-18 15:34:38 10 楼：dlele
说个具体的实例，最近在工作中遇到一个很头疼的bug。我们有个API，GetXXXURL(xxx, string locale, yyy)，locale 是语言的字符串代码，Dev搞成了GetXXXURL(xxx, int lcid, yyy).。Lcid 是语言的整数代码。比如，中文的字符串代码是 "zh-CN"，整数代码是2025。Web Service端只认字符串代码，结果2025被解释成为不支持的语言，URL返回默认英文1033. 由于系统设计是三层，每层都要改，很头疼。
这个测试是我们一个新来的员工测得，他是用VSTS写了一个自动测试，每次运行都通过了。原因就是他可能花太多时间搞自动化，没有认真理解要求，对要验证的返回值也不了解。自动化自然发现不了问题。如果他当初写了一个很简单灵活web based的测试工具，多做探索测试，我也可以很容易的帮他作些探索测试，问题可能早就发现了
