关于自动化测试的一些思考 推荐

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

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

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

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

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

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

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

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

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

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

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

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

要知道，测试自动化所花费的时间是测试本身的3到10倍，如果再加上测试自动化本身的实现带来的bug，自动化花费的时间是测试本身的5到10倍。而我们现实的情况是，我们本来就没有足够的时间完成测试。所以现在如果把大量的精力和时间用在测试自动化上，那就会大量挤压本身应该完成的测试。而测试自动化能够找到的问题远远少于测试本身。想想这个投入和产出，就知道寄希望于重复来发现问题，是多么的愚蠢了。

所以必须清楚地界定回归测试的范畴，那就是，基本功能测试，基本的！

还有什么case渴望自动化呢？

- 必须执行多次的测试。比如，要开关1000次的测试，不可能要一个人对着开关真的摁上1000次，那太残忍了。

- 要24小时运行的测试。比如，稳定性测试，需要连续24小时甚至72小时运行某些行为。要人来操作也不大现实。

- 还有呢，就是只有机器能完成的测试，比如1秒内开关20次，人的反应不够快。

下面说说哪些测试是不适合自动化的。

和其他自动化一样，我们需要分清楚人和机器的区别。有些事情是机器擅长的，人不擅长的，可以考虑自动化。而有些事情是人擅长的，机器不擅长的，则不考虑自动化。

就软件测试而言，大部分的工作都是需要人的全力参与的。因为软件测试不仅仅是执行测试，而理解需求、设计测试、总结测试结果、软件质量评估，占了更多的测试时间，这些我们当然是不可能实现自动化的，因为这需要大量的智慧，且无法重复。

那么就仅仅针对执行测试来说吧。机器是没有感觉的，也不会总结经验。只有人亲自参与测试，执行case，才能体会到当用户来使用这个软件产品的时候，会是什么感觉。他们也将体会到这个软件最大的问题在哪里，系统的软肋在哪里，需要如何改进测试计划，以便能发现更多的问题。

就拿我最熟悉的动态路由来说吧。这些软件代码都已经很成熟了，执行买来的路由协议测试套件，一个bug也找不出来。因为这些协议已经很成熟了，移植过来的代码也被广泛地使用过，其稳定性和可靠性无需我们一测再测。可是我们依然发现了很多其他的问题。

为什么呢？因为移植本身会带来问题，与操作系统和协议栈的接口变了，配置方式也变了，配置文件改了，和其他相关模块的接口也不一样了，甚至还增加了新的接口。测试人员本来并不知道这些问题，是在测试过程中，逐渐发现并了解的。所以就增加了配置，路由模块与协议栈，路由模块与其他模块交互方面的测试case，而对协议本身的测试就不再需要了。这些问题和改进，都是测试人员手工测试的结果。是需要靠人的智慧来感受和总结的。

所以，新的功能测试必须由人来执行测试，并且在执行过程中逐步修改测试计划，同时给出对软件的质量评估。我认识几个非常资深的测试人员，他们总是能发现比别人更多的bug，他们有很好的测试习惯。这些好的测试习惯使得他们对软件出现的问题更加敏锐。

我曾经参加过一个很精彩的测试技巧和自动化培训，那个培训老师有一句话给我留下了深刻的印象，就是“要尽量不用自动化测试”。我想，在这个动辄谈“自动化”的年代，这句话是在告诉我们，只有清楚地知道自动化测试的作用和局限性，聪明地使用自动化测试，而不是为自动化所累，才是智慧的行为。