还在背面试题?自动化测试与手工测试优、劣势(面试经常问)看看大厂软件测试总监怎么说！

既然现在有了自动化测试，甚至现在许多团队在使用人工智能的方法，逐渐让机器来取代人的测试。那么作为测试工程师的人未来会不会消失?

回答这个问题前，先来看一下自动化测试优势和劣势。

一、自动化测试的优势

1.1 自动化测试可以执行手工测试相当困难或根本做不到的测试

对于软件性能测试中的并发测试、疲劳性测试和强度测试，如果单纯使用人工测试是不可能完成的。

1.2 自动化测试具有一致性和可重复性

在手工测试的时候，往往会出现测试人员在测试时候发现了缺陷，可是由于时间过得太长，或者缺陷报告中操作步骤描述不清楚，或者其他因素，在给开发人员定位问题的时候不能重现。在排除一些偶发性问题的情况下，采用自动化测试可以有效地防止此类问题的发生。

1.3 自动化脚本完全可复用

初期采用录制回放的工具进行自动化测试，比如早起的QTP、基于Firefox的Selenium1插件。最主要的原因是由于这些工具对于一些公用的模块难于复用。比如对于登录才可以使用的功能每次开始的时候都要执行登录操作，测试完毕为了让其他测试用例可以继续执行必须执行登出操作。由于早期的工具不具有复用性，相同的操作集中在各个不同的地方，这给软件测试脚本的维护带来的麻烦，而现在的自动化测试脚本均采用类似JAVA、Python这些面向对象的语言来完成，代码的复用发生了很大的改善。

1.4 自动化测试使软件更有信任度

由于自动化测试具有一致性和可重复性，所以自动化测试一旦发现问题，在排除测试代码、测试数据、对需求误解的错误外，其结果还是可以信任的，因为它里面没有人的主观意识的参与。

1.5 自动化测试适合做兼容性测试

如果没有自动化测试，比如做基于WEB软件兼容性测试往往采用每个测试工程师的机器上安装不同的操作系统和浏览器，运行同一版本。这样操作，如果测试工程师比较多的情况下可能还可行，但是一旦测试工程师比较少的情况下可能就将成为问题。如果有了自动化测试，只要把测试环境搭建起来，使用同一脚本在不同环境下自动运行，就可以做到有效的兼容性测试了。

1.6 自动化测试使回归测试更方便、可靠

现在移动互联网时代，讲究的一个字“快”。国内外许多大型的互联网公司平均一天发布的软件发布版本的次数高达2到4次。特别现在兴起的Agile、DevOps中特别关注自动化测试。因为自动化测试使回归测试变得更方便、更可靠。

软件测试，与你同行！我们有一个软件测试，Python自动化学习和解决问题的群，（1079636098）每天都有直播公开课，时间自由安排，有录播。群是免费的，但是谢绝广告。公众号：测试人追风

---

那么自动化测试的劣势又有哪些呢?

二、自动化测试的劣势

2.1 手工发现的缺陷远远比自动化测试得多

在目前如果不采用基于AI的自动化测试下，有机构做过统计，估计80%的缺陷是由人工测试发现的，自动化测试发现的缺陷仅占20%。在ISTQB初级大纲中，软件测试目的被概括为四点，其两点为“发现程序缺陷”和“对程序树立质量信心”。所以手工测试主要针对于新开发出来的特性，其目的主要在于“发现程序缺陷”;而自动化测试化测试主要在于对老特性的回归测试，其目的主要在于“对程序树立质量信心”。

2.2 自动化测试对测试人员的技术要求较高

自动化测试工程师首先要会使用自动化测试工具，其次由于现在基于脚本开发的自动化测试越来越受到了青睐，所以要求自动化测试工程师需要掌握至少一门编程语言，且对应这门语言的测试架构框架、对数据库操作能力等有一定的要求。所以采用自动化测试技术对人的要求是非常高的。这也使进入软件测试的门槛变高了。

2.3 自动化测试成本投入高、风险大

使用自动化测试工具是否可以提高研发本产品的质量?现有的工程师是否具有使用自动化测试的能力?公司是否有能力去购买一些商用的自动化工具?培养工程师学习自动化是否可行?是否被培养起来的工程师存在离职，另求高薪的可能?这些问题都是作为决策层应该考虑的问题。事实也很多次的证明，自动化测试是个好东西，但不是银弹，关键看企业的产品是否适用以及企业如何去使用。

2.4 自动化测试是死的，不具有情感

计算机毕竟是机器，不具有人的抽象能力、想象能力等情感，所以类似于一些UI/UX、需要具有发散式思维的测试是不能完全依赖自动化测试。即使是同一份基于文字的自动化测试用例，让多个人去执行，或者让同一个人在不同时刻去执行，往往会发现不同的缺陷。另外在自动化测试优势中提到的兼容性测试，对于产品的分辨率适应性，文字会不会超出控件等问题，自动化测试可能也是无能为力的。

2.5 自动化测试完全不可能取代手工测试

如上所述，自动化测试完全不可能取代手工测试。现在有些书籍、论坛、社群把自动化测试谈得神乎其神，无所不能、无所不可，这是对自动化测试的曲解，是一种不负责任的表现。正如敏捷、DevOps一样，是否适用，要根据自身产品特性、组织架构能力等各个方面来考虑。