自动化横行的今天，手工测试如何杀出一条血路？值得深思

本文链接：https://blog.csdn.net/weixin_57805858/article/details/125560508

自动化测试是每个软件公司反复提及的，放眼望去，测试岗位的招聘要求里十有八九都会有一条“掌握自动化测试技巧”，甚至有的公司把用例自动化率（实现自动化的用例数/总用例数*100%）当作考核测试人员工作质量的指标之一。

那么，对此，想必大多测试人员会发出灵魂一问：难道手工测试就必须消亡了吗？自动化用例真的那么重要吗？是不是所有用例都需要实现自动化呢？自动化测试是不是就是所向披靡，无敌的呢？

在回答这几个问题之前，我们先来简单了解下自动化测试的特点。谈及自动化测试，就不得不把手工测试拉出来一较高下了，它们各自的定义就毋庸赘言了。

自动化测试的特点

相较手工测试，自动化测试最大的优势就在于：

能够快速测试（快速检测代码变更引入的错误）；
可以重复测试（反复执行成本低）。

但是，自动化测试也有自己的缺点：

如果软件系统体量比较大，那么自动化测试脚本也会比较复杂。自动化测试脚本的复杂度与系统的复杂程度是成正相关的；
如果软件系统迭代快、周期短、变动多，那么脚本维护将需要较大成本；
随着软件系统的不断迭代，功能的不断增加或细节的变更，会出现大量冗余的自动化测试脚本，这类冗余的脚本会直接影响测试脚本执行的效率；
自动化测试脚本的质量直接影响测试执行成功率（执行成功通过的次数/总的执行次数*100%）。只要是代码都会有故障，测试代码也不例外。低质量的自动化测试脚本有可能导致测试执行时的不稳定性（例如：反复失败）；
对于测试人员而言，自动化测试，脚本准备时间（如自动化测试工具选取、脚本编写等）大于测试设计时间；
对于迭代较快的产品，需要测试人员快速地完成测试，在此种情况下，留给测试人员实现用例自动化的时间不会很多，自动化测试在新功能周期内往往很难快速实现；
对于业务量大、业务复杂的系统（如经济类系统，银行等），用例自动化率难以保证。且如前端GUI自动化测试，100%用例自动化率本身就是一个几乎难以实现的愿景。

说了那么多，到底是想证明个什么事儿呢？其实，上面的阐述无非是想问答几个问题：

手工测试会消亡吗？

个人觉得，答案肯定是不会。为什么呢？自动化测试有其优点，可以帮助测试人员快速完成回归测试。但其缺点也依然存在：测试代码冗余、测试代码维护成本大、部分产品的复杂功能难以自动化等等。

是不是所有自动化用例

都需要实现自动化呢？

答案当然是否定的。理想很丰满，现实很骨感。且不说产品本身特点是否能满足完全自动化测试，从自动化成本（维护成本，时间成本，人力成本等）而言完全自动化就是值得思考的问题。再者，对于前端GUI自动化测试而言，完全自动化本身就很难。

自动化测试是不是

所向披靡、无敌的？

答案当然也是否定的。毕竟自动化测试的根本目的主要在于快速地回归测试，在回归测试的过程中对于环境的需求、场景的设置都是具有限定性的，且自动化测试代码也会存在故障。如果切换场景进行自动化测试，不见得能百分百通过。

那么，再进一步想想，如果自动化测试很重要，但又不是百分百完美的，如果想要借助自动化的便利提升测试效率，那么应该针对怎样的用例实现自动化呢？自动化用例应该用在什么样的测试活动中呢？

选择需要实现自动化的用例

其实在上述章节已经揭晓了如何选择需要实现自动化用例的部分原则。