自动化测试是每个软件公司反复提及的，放眼望去，测试岗位的招聘要求里十有八九都会有一条“掌握自动化测试技巧”，甚至有的公司把用例自动化率（实现自动化的用例数/总用例数*100%）当作考核测试人员工作质量的指标之一。
那么，对此，想必大多测试人员会发出灵魂一问：难道手工测试就必须消亡了吗？自动化用例真的那么重要吗？是不是所有用例都需要实现自动化呢？自动化测试是不是就是所向披靡，无敌的呢？
在回答这几个问题之前，我们先来简单了解下自动化测试的特点。谈及自动化测试，就不得不把手工测试拉出来一较高下了，它们各自的定义就毋庸赘言了。
自动化测试的特点
相较手工测试，自动化测试最大的优势就在于：
能够快速测试（快速检测代码变更引入的错误）；
可以重复测试（反复执行成本低）。
但是，自动化测试也有自己的缺点：
如果软件系统体量比较大，那么自动化测试脚本也会比较复杂。自动化测试脚本的复杂度与系统的复杂程度是成正相关的；
如果软件系统迭代快、周期短、变动多，那么脚本维护将需要较大成本；
随着软件系统的不断迭代，功能的不断增加或细节的变更，会出现大量冗余的自动化测试脚本，这类冗余的脚本会直接影响测试脚本执行的效率；
自动化测试脚本的质量直接影响测试执行成功率（执行成功通过的次数/总的执行次数*100%）。只要是代码都会有故障，测试代码也不例外。低质量的自动化测试脚本有可能导致测试执行时的不稳定性（例如：反复失败）；
对于测试人员而言，自动化测试，脚本准备时间（如自动化测试工具选取、脚本编写等）大于测试设计时间；
对于迭代较快的产品，需要测试人员快速地完成测试，在此种情况下，留给测试人员实现用例自动化的时间不会很多，自动化测试在新功能周期内往往很难快速实现；
对于业务量大、业务复杂的系统（如经济类系统，银行等），用例自动化率难以保证。且如前端GUI自动化测试，100%用例自动化率本身就是一个几乎难以实现的愿景。
说了那么多，到底是想证明个什么事儿呢？其实，上面的阐述无非是想问答几个问题：
○
手工测试会消亡吗？
个人觉得，答案肯定是不会。为什么呢？自动化测试有其优点，可以帮助测试人员快速完成回归测试。但其缺点也依然存在：测试代码冗余、测试代码维护成本大、部分产品的复杂功能难以自动化等等。
○
是不是所有自动化用例
都需要实现自动化呢？
答案当然是否定的。理想很丰满，现实很骨感。且不说产品本身特点是否能满足完全自动化测试，从自动化成本（维护成本，时间成本，人力成本等）而言完全自动化就是值得思考的问题。再者，对于前端GUI自动化测试而言，完全自动化本身就很难。
○
自动化测试是不是
所向披靡、无敌的？
答案当然也是否定的。毕竟自动化测试的根本目的主要在于快速地回归测试，在回归测试的过程中对于环境的需求、场景的设置都是具有限定性的，且自动化测试代码也会存在故障。如果切换场景进行自动化测试，不见得能百分百通过。
那么，再进一步想想，如果自动化测试很重要，但又不是百分百完美的，如果想要借助自动化的便利提升测试效率，那么应该针对怎样的用例实现自动化呢？自动化用例应该用在什么样的测试活动中呢？
选择需要实现自动化的用例
其实在上述章节已经揭晓了如何选择需要实现自动化用例的部分原则。
○
选择执行结果稳定的用例
实现自动化
试想如果一个用例执行结果不够问题，那么将手工测试步骤自动化有什么意义呢？这个时候需要的是去重新审视测试步骤是否准确或者代码是否有隐藏问题吧？！
○
选择功能稳定的用例
实现自动化
试想如果一个模块或者一个功能频繁变更，那么用例实现自动化有什么意义呢？如果将此类用例实现自动化，反而会加重测试人员对自动化脚本的维护成本。
○
首先选择接口用例自动化
那是因为接口自动化学习成本低，几乎是每个测试人员接触自动化测试的第一步。而且接口是每个模块衔接之处，保障系统运行的重中之重。
○
如果要求前端GUI自动化
要慎重
前端GUI本身就是一个属于频繁变动的部分，如果实现自动化，对自动化脚本的维护就是一个不得不思考的问题。
也许你会说，我用录屏啊。录屏虽然学习成本低、操作简单，但是对于测试步骤的断言、测试结果的判定大多还需人工干预。
如何在自动化响亮的口号下
发展手工测试
百分百自动化测试是每个测试人员的追求，每个公司的终极梦想，但这本身就意味着实现的困难和不可能。
自动化测试很重要，但手工测试仍然不可或缺。
测试人员担心自己会被各种不断进步的自动化测试工具替代的时候，可以想想如何在包围圈中拼杀出一条血路：我想，测试设计应该是一条可选之路。
好的测试设计能够节省测试成本（如测试资源的投入）、提高测试效率、提升测试结果稳定性。同样，优秀的测试设计能够指引测试人员挖掘一些深层故障，提高产品质量。
常有人说：测试是一门简单的工作，测试岗位可以被取消，不需要专职测试人员。但是如果不需要专职测试人员，让开发人员兼职测试工作，岂不是开发人员既当选手又当裁判？如何能够公正地评判。
再试想：如果开发人员能够知道自己代码中的故障，那为什么不在编写代码的时候就避免了呢？
