如果你是一位测试人员 ，在你的测试生涯中 ，你几乎绕不过的必备技术包:自动化测试 。 为什么这么说？ 因为如果你是一位功能测试人员 ，你可能有过这样的经历 ，应聘的是功能测试岗位 ，但是好多问题都是在问自动化相关的技术 。哪怕这家企业它不做自动化测试 ，但是你如果会一些 ，你的薪资也会比完全不会的高一些 。
1.为什么要做自动化？你可能会问 ，自动化测试就这么有用吗 ？其实也不一定 ，我们都知道，做自动化测试是为了提效 ，换句话说就是只有做到了提高效率，才算是体现出它真正的价值 ，但很多公司提效没有做到 ，反倒投入了很多 ，最后发现没什么卵用，就会中途放弃，不了了之。
所以 ，你想要你的自动化有用 ，必须从根上去探究 ，做它的意义是什么 ？ 如何去量化它 ？ 把这两句话翻译过来就是 ，我们必须能通过一个指标知道它是否做到了提效 。那怎么才算是提升效率呢 ？你可以按照如下这个公式来计算 ：
那么对于做自动化测试来说 ，回报的收益是什么 ？ 投入的成本又是什么呢 ？若想要搞清楚这两个概念 ，必须要从自动化是为了解决什么问题？从问题的初衷上来思考 。比如做自动化测试是为了代替人工去做回归测试 ，解放人力 。
比如 ：一个产品，测试人员3人 ，一次迭代时间7天 ，回归测试人员1天 ，那么意味着每次迭代花在回归上的成本就是 ：1天 * 3人 = 3人天 ，那如果这个时间用自动化代替的话 ，那就相当于一个迭代在效率上提高了3人天的时效 。
但是 ，既然在自动化有投入 ，那么 ，你也得算出投入在自动化上面的成本 。它的算法就是 ：投入在这个迭代上的编写脚本时间 * 人员 。比如在这个迭代中 ，我只投入了1人1天 ，那么我的投入成本则是1人天 。无论如何，最后计算的结果肯定会有三种情况 ：
- 如果 回报的收益 > 投入的成本 ，说明你的自动化测试产生了价值 ，产生了收益 。
- 如果 回报的收益 < 投入的成本 ，说明你的自动化还属于投入阶段 ，投资阶段 。当然，很多公司都是属于这种情况 。
- 如果 回报的收益 = 投入的成本 ，说明你的自动化已经进入到平衡期了 ，这种情况下很快就能产生收益 。
实际工作中 ，我们可能不会纠结每天投入了多少成本 ，产生了多少收益 。而更多想的是如何让收益最大化 ，减少投入等 。
2.提效的影响因素于是 ，我们必须思考一个问题，就是什么因素决定了收益 ？ 什么因素决定了投入 ？
个人认为 ，以下三个因素对自动化的效率提升非常关键，具体是 ：
- 自动化框架编写效率 ，即提高业务测试人员编写用例的效率 ，缩短调试时间 。
- 自动化框架运行的稳定性 ，稳定的框架是测试用例能正常运行的前提 。
- 自动化用例的覆盖率 ，保证主要测试用例尽可能多的覆盖 。
为了充分的说明以上三点 ，我们可以先看下一家公司要开展自动化测试 ，他们的人员结构是怎样的 ？招一名经验丰富的自动化测试人员专门来搭建框架及维护框架 ，其他的业务测试人员来去添加用例 。
- 自动化测试人员 ： 搭建框架 ，维护框架 ，解决框架中存在的问题 ，确保框架稳定性 ，提升框架编写效率 。
- 业务测试人员 ：添加用例 ，维护用例 ，即把他们编写好的功能测试用例添加到框架中，后由框架帮其回归测试 ，提升测试用例覆盖率 。
如果是这样的结构去维护代码 ，那么 ，自动化测试人员的主要职责就是保证框架稳定性和提升编写用例效率 。而测试人员就是添加测试用例 ，提升用例覆盖率 。
我们先来讨论第一个问题， 如何提升框架的编写用例效率呢 ？ 这就的需要知道测试人员把编写脚本的时间都花在哪里了 ？ 很明显作为一名业务测试人员，在自动化上花费时间最多的就是编写测试用例脚本 和 调试脚本 ，这可能占他们总时间的90%以上。 所以 ，自动化框架提效的本质就是降低他们在这两项上所花的时间 。
2.1.如何减少测试人员的编写用例时间呢 ？比如 ，一个普通的自动化框架最主要的是三层结构：用例层 、数据层 以及接口层(以接口为例) ，也就是说你要编写一条测试用例 ，至少需要维护三个脚本 ，即编写一条测试用例 ，添加该用例的数据 ，再实现对应的接口 。
而如果你把它换成基于配置的自动化 ，那对测试人员来说 ，就只需要维护数据层就行了 ，而如果你把他换成基于流量回访的自动化 ，那么你只需做关联上的修改即可 。这样就大大的提高人效 ，缩短了测试人员编写脚本的时间。
其实测试人员调试时间长，很重要的原因，就是不好排错 ，日志看不懂 。所以 ，解决这个问题就需要按照如下思路去解决 ：
- 加入单文件调试模式 ，可以单独运行一条测试用例 。
- 支持错误后断点调试 ，若某条测试用例运行失败 ，可以加入断点调试 。
- 编写的日志更易读 ，能直接从日志中就看出错误 ，比如
这个其实没啥可说的，除了自动化测试人员本身需要有强的代码能力外 ，还有很重要的一个因素就是要拿大量的测试用例喂框架，让测试框架能适应大量级的用例 ，你可以想象一下 ，如果一个框架本身能支持2000 以上的测试用例同时运行 ，那么本身就说明它的稳定性 。但如果你的框架到了200条就各种报错 ，同样说明框架的不稳定性 。
2.4 提升测试用例的覆盖率这个也无需多说 ，做过测试的都知道 ，你只需要和业务测试人员沟通好添加机制就行 ，让他们负责不断的往进加用例 ，要形成习惯 ，形成制度 。
因为：
- 用例添加越多 ，提效的效果越好 ；
- 用例执行次数越多 ，提效的效果越好 ；
- 用例执行时间越多 ，提效的效果越好 ；
大家可能见过这个图 ，自动化测试中的经典模型 ，金字塔模型 。在这个模型中需要说明以下3点 ：
- 越底层的自动化效果越好 、覆盖率越高 ，也就越稳定 ，同时它的要求也就越高 。这也是为啥很多公司要求必须会白盒测试 。
- 虽然白盒测试效果好 ，但是很多公司都是开发再做 ，因为它要求你必须会明确的语言 ，比如公司产品是Java开发，那必须懂Java才行 ，你用python就不能搞 ，而且它必须开发项目紧密合作才行 。所以很多白盒测试在测试部门推广不起来 。
- 接下来就是接口自动化，而接口自动化是除了单元自动化外唯一能全覆盖的情况 ，像UI全覆盖几乎无可能 ，所以 ，从需求和推广上来说 ，接口自动化更容易在公司开展 ，需求也就更大。
以下我重点说明接口自动化的情况 ，相比UI自动化 ，接口自动化：能做到更高的覆盖率、执行效率高 、稳定性强等优点 ，所以，企业也更愿意去做接口自动化 。
3.2 接口自动化介绍目前市面上 ，本人见过的三种自动化框架 ，分别是 ：
- 普通的自动化框架 ：这是一种最常见的自动化框架 ，主要就是将接口层、用例层、数据层彼此分离 ，每添加用例一条，都需要对着三层中的文件做相应的修改 。它的工作量方法是最大的 ，但同时它也是最简单的 。
- 基于模板配置的自动化 ：去掉接口层和用例层 ，只保留数据层 ，每添加一条用例 ，都相当于是添加对应的测试数据 ，一般只需要管理测试数据即可 ，相比上一种而言 ，编写效率大大提升 ，但同时框架难度变的更大。
- 基于流量回放的自动化 ：测试数据也将通过抓取的数据自动生成 ，测试人员在上面做简单的修改即可 ，效率值最高 ，当然实现它的框架难度也就更大。
它们各有优缺点 ，适合人群也不同 ，可参考如下：
自动化分类 | 优点 | 缺点 |
普通的自动化框架 | 比较简单，容易上手。 | 编写测试用例的时间更长 |
基于模板配置的自动化 | 提高了效率，缩短了编写用例时间 | 框架本身维护变难。 |
基于流量回放的自动化 | 效率值最高，编写用例时间最短 | 框架代码量更大 ，维护难度更大。 |
以下我拿其中的两套做个比较 ，可以看看两者的区别 ：
测试用例层 ：
测试接口层
测试数据层：
所以 ，通过以上三层的比对 ，你可以看到两者区别 ，框架B比A效率更高 ，但是本身编写框架的人需要有一定的基本功 。
