1.3 自动化测试

1.3.1 什么是自动化测试

自动化测试是指利用软件测试工具自动实现全部或部分测试，它是软件测试的一个重要组成部分，能完成许多手工测试无法实现或难以实现的测试。能够正确、合理地实施自动测试，可以快速、全面地对软件进行测试，从而提高软件质量，节省经费，缩短软件发布周期。

自动化测试一般分为UI 自动化测试和接口自动化测试。

UI自动化测试是指基于界面元素的自动化测试。需要先定位界面元素的路径，然后通过脚本实现自动化。这种方法因为界面需求的变更频繁，脚本更新频繁，不利于后期的维护工作，造成自动化工作的成本巨大，已经慢慢被各大公司所淘汰。

随即演变出的就是接口自动化了。接口自动化是指模拟程序接口层面的自动化，由于接口不易变更维护成本小，所以它深受各大公司喜爱。接口自动化也是本书的重点。它包含两个部分，功能性的接口自动化测试和并发接口自动化测试。

1.3.2 与手工测试的区别

自动化测试和手工测试并没有高低贵贱之分，虽然划分在不同的阶层，但只是出于对测试人员个人的价值评判而已。以下详细解析这两者的区别。

1.测试目的不同

虽然都是测试，但这2种测试的目的却是截然相反的。

手工测试的目的在于通过“破坏”发现系统有bug。

自动化测试的目的在于“验证”系统没有bug。

当测试系统处于前期不稳定的时候，做自动化测试将毫无意义，因为程序运行到一半就会因为某个bug而停止的，而当这个bug未被修复之前所有的自动化测试都会卡在这里无法往下执行。而当测试系统处于稳定的时候，通过手工测试重复着一样的操作也会变得烦琐和枯燥，所以这两者在不同的测试阶段都有着不可替代的作用。

2.覆盖范围不同

除了目的的不同，覆盖范围也是不同的。

手工测试可以尽可能地覆盖测试系统的各个角落。

自动化测试只能覆盖测试系统的主要功能。

试想把所有的测试用例都弄成自动化是一件多么美好的事情，但代价实在太大了，投入的时间和产出完全不成正比，不夸张地说如果要做到完全自动化测试，所需要的代码量会远远超过开发编写程序的代码量。所以自动化测试只能挑一些重要和稳定的功能来做，而更多的一些细节的测试还需要手工测试来完成。

3.智能判断不同

自动化和手工测试还有一个最大的区别是智能判断方面。

计算机程序对于人而言是绝对的服从和诚实的。

举个浪漫的例子，用计算机程序去计算1+1，结果必然等于2（除非你的程序本身写的有bug，这不是计算机程序的问题），而如果问一个人1+1等于几，可能会有一个浪漫答案“1+1等于我们”，那这个结果是对还是错呢？如果交给程序判断必然是错的。因此智能判断是自动化测试的瓶颈，一个操作出现多种结果可能都是对的，但又可能都是错的。

再举个电商的例子，比如有个特价产品只有一份，需要秒杀，有可能抢到，也有可能抢不到。对于能抢到来说，只有“他”1 个人抢到是对的，如果多个人都能抢到那就是错的。对于不能抢到来说，已经有1个人抢到就是对的，如果没有一个人抢到的话就是错的，这个时候自动化测试程序该如何判断结果的对错呢？这样的情况比比皆是，虽然有办法通过程序去预置各种条件让结果唯一化，但需要花大量的时间和精力去优化自动化测试代码，并且还需要分多个自动化测试程序完成，这个时候还不如人工介入测试进行判断来得方便。

这样看来其实自动化测试能做的还是非常有限的，而更多的时候还是需要手工测试，利用工具也好，逻辑判断也好，又或者让开发修改程序来配合测试也好，总之能达到测试的最终目的就好，从这个意义上来说手工测试也并非没有技术含量，而自动化测试也没有那么无所不能。

1.3.3 自动化测试的困境

自动化测试具有很大的优势，一劳永逸地用程序代替人力，人力干活8小时，而程序可以24小时不停止地干活。但是自动化测试还有一个很大的困境，即由于自动化测试很难持续维护，导致在大多数公司无法普及这种测试方式。

IT行业的竞争日益激烈，产品要保持自身的竞争力就需要不断高速迭代新版本、新功能。这就意味了原来写的自动化测试程序变得不可用了（其中的部分程序），而留给测试人员的时间又往往是很少的，于是只能手工测试保证按时上线，等上完线之后可能过几天又有新的功能要测试。留给测试的时间不够完成自动化测试程序的维护更新，周而复始，久而久之，原来的自动化测试程序已经和当前版本相去甚远了，最后自动化测试就不了了之了。我想这就是人们常说的“愿望是美好的，但现实总是残酷的”。

既然知道是困境，必然就是很难解决的，那有没有折中的办法来减少一定的维护成本，又可以达到一定的自动化测试的目的呢？回答这个问题之前先要看透自动化测试的核心本质，就是元素识别+元素操作+验证结果，大多数自动化测试工具都会提供元素识别和元素操作（鼠标点击、键盘输入、屏幕 touch 等），只有在验证结果的时候需要写代码提取实际结果，然后和预期结果进行比较，最后得出测试通过或者不通过的结论。

其实对于写代码的部分来说都是通用的，不同的地方在于获取实际结果的方式变更或者预期结果的变更，工作量并不多。真正烦琐之处在于元素的识别，每个元素其实都由唯一标识来识别，这样才能保证不会操作错元素，好处在于如果元素不变，那唯一的标识也永远不会识别错，这是自动化测试可以实施的基础。但有利自然有弊，一旦元素变了，原来的标识就不可用了，那自动化测试就无法实施了。说到这里如果可以绕过元素识别这一步，将元素操作以接口的形式通过脚本完成，就可以抛弃重量级的自动化测试工具，而通过测试脚本直接实现接口自动化测试。

正是因为这样的想法，然后通过大量的实践，发现这条路虽然不能完全解决困境，但能达到一定的平衡，让自动化测试有一条新的出口，就像鲁迅先生所说的那样“世界上本没有路，走的人多了，也便成了路”，于是才有了这本书。