🍅 点击文末小卡片，免费获取软件测试全套资料，资料在手，涨薪更快    

什么是自动化测试?

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

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

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

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

自动化测试与手工测试的区别

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

1．测试目的不同

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

• 手工测试的目的在于通过“破坏”发现系统有bug。
• 自动化测试的目的在于“验证”系统没有bug。

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

2．覆盖范围不同

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

• 手工测试可以尽可能地覆盖测试系统的各个角落。
• 自动化测试只能覆盖测试系统的主要功能。

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

3．智能判断不同

自动化和手工测试还有一个最大的区别是智能判断方面。 计算机程序对于人而言是绝对的服从和诚实的。

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

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

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

自动化测试的困境

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

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

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

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

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。