自动化测试与手工测试的区别是什么？

什么是自动化测试?

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

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

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

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

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

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

1．测试目的不同

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

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

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

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

2．覆盖范围不同

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

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

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

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

3．智能判断不同

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

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

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

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

自动化测试的困境

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

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

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

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

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

?

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取?