本来想吐槽一波的，听取前辈们的建议，还是算了。
现在先讲讲我在接口自动化测试的落地方案，如下图

看到这个图，可能大神们都会来质疑，首先一定会质疑数据备份还原这种方法，比如说数据库数据有几个、几十个 G 甚至几 T 时，这种方法还是否适合……

说起来惭愧，方案还是有点 low，有些还是需要手动去做。

首先，我们会从 git 上面去拉代码，打包并上传部署，这部分是由 CI/CD 来完成，当然我们这边的的 CI/CD 并没有做得特别的好，而且连产品都没有成型的状态，于是我先用 jenkins 的 PipeLine 来完成前面这一套的工作流，再增加数据准备与执行测试两个节点（如果有个像样的 CI/CD 平台后再做迁移）。
数据准备是用数据库备份还原的方法来做，而接口测试这个是由我们自研的 seiya 接口平台承担这部分的工作。
特别强调 jacoco 做统计的做法很 low，是用手动去修改 catalina.sh。
正常来说这个 Jacoco 统计的应该由 CI/CD 来统一操作的。

对于前面 CI/CD 这一块我就不多说，每个公司都有一样或者不一样的做法。
这里就只讲一下怎么做接口自动化测试。
从数据库备份还原这种方法说起吧。为什么要使用这种方法？
举个实际的测试例子来说就一目了然了。
例子：一个注册用户的接口测试用例
如果是我来写这个 case，我会这样来设计
一般注册帐号需要输入用户名、中文名、手机号码、性别、邮箱等等，当然也会分有效注册和无效注册
---有效注册
必须是一个数据库不存在的新用户，比如输入的数据是：zhangsan,张三,139xxxxxxxx,male,zhangsan@163.com
---无效注册
无效也分各种场景：
1、 注册已经存在的用户
2、 手机号码校验
3、 邮箱校验
4、 验证码校验
……..
根据以上场景我们就可以开始做接口测试了。
其它的 CASE 就不说了，我们用 jmeter 写第一条有效测试的 case（post 一段 Form 表单），一开始我们会这样写（就用比较通用的 jmeter 来作为例子讲吧），如下图：

这样写有没有问题呢？
第一次执行时，当然是没问题，但下一次呢？
下一次执行就不可以用相同的数据了，又得去造一堆数据。为了让数据可以复用，所以我这里选择了数据备份还原的方法。
还有没有更好的方法？
答案是有的。
我列一下我想到的几种方法：
1、 调用删除的注册接口
2、 调用 sql 语句去删除数据
3、 写一套自动生成数据的方法
4、 数据库备份还原的方法
5、 …….
前面几种方法一开始我也是做过的，但都遇到各种问题。
1、 调用删除注册的接口。当然得找开发要接口。
开发大大：我们不提供这种接口，因为这种接口不能合到主干，如果强行加上，难以管理代码。
2、 调用 sql 语句去删除数据。我想这种可以了吧，于是提出这种方案。
开发大大：“我们不允许使用 sql 语句去删除数据，我们不信任你们测试写的 sql 脚本，sql 脚本需要 DBA 去评审。再说你们这种 sql 语法会导致我们有脏数据。”

此时此刻的心里：一群草泥马在奔腾着。
3、 写一套自动化生成数据的方法。我发现这种方法我不会写，于是放弃了。
4、 最终只能选择数据库备份还原的方法。这种方法是不是最好的呢？我觉得并不是最好的，但是是目前情况下最适合项目的。
以下几个项目特点决定了我使用这种方法：
a.项目测试环境数据其实真的不大
b.操作简单，就一条 sql 命令解决的事情（source xxx.sql）
c.生产/线上环境不允许操作数据库，只能在测试环境做这个事情
d.基础建设没达到一定的高度，提供不了更好的方法。

可能数据库还原不是最好的，但在目前状态下是最合适项目的方法。在不同场景下采用不同的测试方法不也是我们作为测试应该去做的事情吗？

数据这一块还只是一个需要注意的地方，另外在实际做接口测试还需要注意一些细节。

1、 CASE 依赖。CASE 依赖分前置依赖与后置依赖，依赖方式这也分并行依赖与串行依赖。
如下图：

2、 数据对应关系。数据对应关系可以是一条数据对应一个接口，或者是一条数据对应多个接口，也可以是多个数据对于一个接口，这样就会形成多个不同的 Case。我这里就只拿多个数据对应一个接口来举个例子：

如果是一个注册接口，我们得考虑是注册能不能有特殊字符，电话号码是不是 11 位 (国内)，邮件格式等等。这样一个接口其实我们可以写 N 条测试 case，而不是仅仅一条接口 case 就完事。
当然数据有各式各样，需要我们去造，比如空格，特殊字符等等。
3、 case 排序
为什么要讲 case 排序呢？还是举个例子来说会比较实在一点。
就用网站登录功能来说吧。
设计一个登录 case，一般来说要测试有效登录和无效登录，如果没有帐号就行得先注册，这样我们又得依赖注册接口去注册一个帐号。多麻烦呀。如果我们先执行注册接口，这样我们就可以使用同一套数据，不用再造一个登录数据，这样整个 case 集就可以这样排列。
1、 注册 (帐号名:张三;密码:123456)
2、 无效登录 (帐号名:李四;密码:123456)
3、 有效登录 (帐号名:张三;密码:123456)
4、 其它功能

另外一个比较经典的例子就是功能启用和禁用接口测试，启用接口需要依赖此功能已经禁用的状态，禁用接口依赖此功能启用，如果我们写接口依赖的的就是启动依赖于禁用，禁用依赖与启用，这样就会导致死循环。如果采用 case 排序，那么我们就不需要依赖，禁用后调启用，两条 CASE 解决问题，也不需要做前后置依赖。

在接口自动化测试的过程中涉及状态的尽量采用 case 排序，不要使用 case 依赖。

讲完接口自动化测试的经验，讲一讲怎么去衡量接口测试的有效率。
在我们这边是这样来衡量的：
1、 接口数覆盖率：指的是接口文档中接口数与 Case 数的百分比
2、 Case 通过率
3、 接口测试代码覆盖率：就是使用 jacoco 统计的行为覆盖和分支覆盖率。Jacoco 统计 tomcat 的覆盖率百度一下一般都能查到。
把这些事情都做了，那么下一步就是不断的提升这三个指标。

对于自动化测试，我现在更加倾向于落地，而不是做一些高大上的东西结果什么价值都产生不了的项目。有一些自动化哪怕方法很 low，但是能落地能产生价值，并且需要在这种 low 的方法上不断的去提升。一味追求自动化测试的团队最终都会放弃自动化测试, 真正的自动化测试还是要从基本的业务测试做起，只有贴近业务测试需求的自动化测试才能产生价值！！！