自动化测试的作用常常是被夸大的，尤其是现阶段敏捷开发过程被许多公司大量推广，增量开发和自动化测试成了相依为命的兄弟。测试的case24小时不停地运转，仿佛只有这样，才能让管理者放心，认为我们的软件已经经过了地毯式的轰炸，所有的bug都没有被放过。

　　可是相对应的事实是，自动化测试没有发现几个bug，而我们在客户那里的bug却成指数级增长，客户的满意度急剧下降。

　　管理人员将这个现象解释为，自动化测试的覆盖面还不够广，没有达到100%的覆盖，要求所有的case全都自动化。这就往错误的方向越走越远了。

　　我希望那些领导者能不能停下脚步，哪怕用一天的时间好好想一想，自动化测试究竟是什么？它能达到什么目的？它带来的好处和坏处究竟有哪些？

　　首先，我们要思考，什么事情可以自动化？很多事情是无法自动化的。比如家务劳动，洗碗洗衣服可以自动化，洗菜烧菜却不能自动化。为什么？因为洗碗洗衣服是简单劳动，变数少，可以重复。洗菜烧菜是复杂的劳动，可变因素很多，很难重复。其实洗衣服如果完全靠洗衣机，也洗不干净，还需要中间加入人的劳动来把特别脏的地方洗掉。洗碗靠洗碗机也洗不干净，因为碗的形状也是多变的。如果有人妄想把所有的家务劳动都交给机器，结果可想而知，就是一句歌词，“付出太多，得到太少”。绝对是得不偿失的。

　　测试也是一样。软件的需求、行为和架构都是很复杂的，出的问题也是多种多样。软件测试对于测试人员的要求很高，他们不仅要发现软件实现本身可能带来的问题，比如变量初始化，数组越界，内存泄漏，边界值保护，死循环，等等；还要发现软件实现的功能是否符合需求，以及软件的稳定性、兼容性、效率、系统占用、容量、性能、容错性是否符合客户对产品要求；还要看新功能和原有功能互斥还是共存，输入参数的变化，用户界面的影响，日志和告警的合理性以及用户的使用体验，等等。需求不同，功能不同，架构不同，软件的可变因素太多太多，测试人员能设计出最合理的case已属不易，要将这些测试全都自动化，我看这应该是天方夜谭了吧。

　　所以要想明白，什么样的case是必须自动化的，什么样的case是可以自动化的，什么样的case是不能自动化的。

　　首先，我们什么时候才渴望自动化？那就是我们需要不停地重复的时候。

　　比如，在软件从软件人员手里交付到测试人员手里的时候，必须保证，第一，软件是编译成功的；第二，软件是可以启动的；第三，软件基本可运行。所以，这些行为必须自动化。例如，有的公司要求每天都必须有新版本交付到软件人员手里，那么这些测试每天都要重复，这就是每日构建。有的公司要求一周交付2个新版本，那么这些测试每周执行2遍，也必须自动化。如果不自动化，完成这些测试的人早晚也会变成机器的，呵呵。

　　还有接收测试。比如说，我们的软件是分层的，我们的应用软件下面有中间件，中间件下面有平台，平台下面还有操作系统。当这些平台每周或者每个月交付给我们的时候，都必须执行基本功能、压力和稳定性测试。这些测试都是可重复的。

　　当然最难说清楚的，就是回归测试。回归测试当然是要重复的，所以最好能自动化。但是如何界定哪些case属于回归测试，哪些case属于功能测试，则不大容易。有些人认为，凡是老的功能，都应属于回归测试。因为我们不能保证新的功能实现以及对原有bug的修复不会影响老的功能，多做一次测试，就多一份把握。所以很多人在设计新case的时候，就同时完成了这个case的自动化，指望着在将来不断地重测时能幸运地撞到一个bug。结果事与愿违，啥bug也找不到。

　　这就是一个好的测试人员和一个差的测试人员的区别。好的测试人员会在有限的时间内找到尽可能多的、重要的bug。而差的测试人员则寄希望于用机器重复来“撞”bug。bug在哪里？在好的测试设计里，在对需求的理解里，在对软件的了解里，在对错误的嗅觉里，不在重复里。