自动化测试（一）What is Test Automation？



本文翻译于James Bach的文章《What is Test Automation?》。

测试自动化就是任何利用工具来辅助的测试，几乎在计算机工业产生的第一天，这种测试就出现了。而且历史上从来没有出现过“测试自动化取代测试工程师工作”这种事情发生，除非你完全忽略测试人员们的真正工作。

基于同样的原因，自动空间探测器从来都不是用来“取代太空科学家的工作”，他们只是拓展了科学家的探索范围。自动化测试也是意味着拓展了测试者的探索范围。

测试自动化根本就不是新生事物，独立测试工程师的理念都要比它新。在很久以前，大约在上世纪40年代末期，独立测试工程师根本没有出现。开发人员自己测试程序。到了六十年代，关于测试的论文（比如IFIPS会议中的那些）都是在论述开发人员如何测试他们自己的程序。测试（test）和调试（debug）这两个概念也没有被区分开。随着软件系统的规模越来越大，独立测试的理念还是变得时髦起来。在1972年的Chapel Hill，关于软件测试的第一次会议召开，这次会议推动了软件测试开始作为独立于开发的技术被讨论。

不过在这个会议上，我想他们把一件事情搞错了。就是他们对测试自动化寄予了很多期望和热情。这种期望最后没有成功实现，不过不是因为缺少实践，而是缺乏足够好的理解。

他们没有理解的，同时也是许多同时代程序员没有理解的是：好的软件测试，天然的，必然的是一种人类活动，必然的，而不是偶然的。测试是一种社会活动，一种心理活动。软件越复杂，人在使用和识别软件问题上的作用就越大。但是Chapel Hill会议被那些受训练为程序员和电子工程师的人占据了，这个会上缺乏那些懂得如何去思考的人。

（谁是这种会思考的人？ Jerry Weinberg. 他的论文1965 Ph.D. thesis on problem solving简直太棒了。他在1970年写了计算机编程心理学，包含了一系列关于60年代的软件测试的论文。在他1961年的书，软件开发基础中，他专门用一章讨论软件测试。很遗憾Jerry没有参加Chapel Hill会议，但是他参加了在多伦多的CAST会议）

受训的独立测试人员的理念要比自动化测试的理念还要新，但是和测试自动化比起来，这个理念的接受程度还不够，因为对测试人员的培训实在是太糟糕了！

所以有人理解测试是一种简单的技术，测试就是保证对API的调用不会让程序像个不受控的野兽一样滚到不知哪里去。这种理念还在那，我是说微软。我老婆到现在还得让我来帮她做微软Office软件的问题定位。我被告知，Microsoft Office，一个仍然在膨胀中的软件，是由那些没有系统学习过软件测试的开发人员，在那些“自动化测试工具”的支持下写出来的。（好在我的同事，Michael Bolton——这哥们是不是唱歌也不错？译者Orz——最近在微软开了一堂测试课，所以，也许，还有希望）

测试自动化无法再现测试工程师构想测试、控制测试、修改测试、观察和评估产品时的那些创造性思维。测试自动化不能完成那些高质量的测试。所以，测试自动化从来就不意味着：把那些测试工程师提供的服务自动化。

总之一句话，测试自动化意味着使用测试工具。测试自动化是个古老的理念，独立测试工程师的理念比这个要新。业界现在还没有尝试过（除了在很小的内部范围）系统的培训测试人员，他们仅仅把职位命名为“测试工程师”或者“开发测试工程师”，然后把一些他们都不熟悉的测试工具丢给他们，然后一厢情愿的希望他们可以努力！Fighting！

接下来，说下我对什么是自动化测试的理解。

首先说明一下什么是自动化测试， 它主要完成2个方面的工作：

● 把手动的测试用例自动化，手动的测试用例可以自动执行

● 把没有办法手动的测试用例自动化，比如让你测试光驱可以打开几次，做个压力测试，人工测试显然不可行。

然后再说明一下为什么要自动化，ROI如何；

● 研发要解决的问题是，一个是效果问题，一个是效率问题， 自动化可以提高效率，所以自动化有利于提高效率

● 这是一种工程师的态度，或者是套用一下流行的词，叫做Facebook的文化，Hacker的文化；因为不喜欢重复的做一个事情，把它自动化，看上去是很Cool的事情

所以自动化最重要的事情就是提高效率以及实现手动无法完成的事情。