2年接口自动化的总结

这篇文章用来对自己做接口自动化用例过程中遇到的经验作以总结，主要是用例编写和执行过程中的难点：

1. 用例编写要考虑稳定性，解决用例耦合

导致此类问题的原因有：

①    用例编写问题：

a.大部分业务接口对参数比如name有唯一性校验，所以参数需要进行随机生成；

b.对结果校验不通用，指定数组序列：返回体是JSONArray，校验数组中有一个元素的name为abc，校验中直接制定元素位置：array[0].name==’abc’，这种校验当用例一直到B环境执行时会有可能时array[1].name为abc,校验会不通过，需要修改校验为contains

c.用例编写对依赖上一步骤返回的id没有指定，导致引用错乱，对非期望数据进行操作，导致校验不通过：用例传参对参数id指定要操作的id

②不同环境对参数规则要求不一、返回属性不一致：如果使用同一份用例，迁移至B环境，会导致此类用例不通用，当前我们的机制是：规范不一致的用例用不同标签标识，选择用例时选择对应环境标签执行

1. 执行时间

自动化要求能较快时间完成用例的执行，现我们项目要求30min内完成全量用例执行。

所以用例要考虑用例间是否能并发，不能并发执行的用例耗时情况。有的依赖验证码的接口，两次获取验证码的时间有30s时间间隔，所以对此类场景，能预置的数据提前预置，能合并验证的合并一个用例验证，减少验证环节前面的数据构造过程。

接口的参数合法性校验可以合并一个用例写，减少用例前面的执行时间，减少过多的非关键用例。

当前我们项目接口自动化用例数多达3000多条，其中正常场景的用例可能不到1/3，其余都是异常场景，有些单接口参数验证是可以合并的，但是到后期意识到这个问题整改成本很大

1. 执行策略 

我们可以按照测试目的选择用例执行，而不是每次都全量执行，这样有效提升大家的验证时间效率

1. 验证DB读写一致性情况，可以勾选部分读写用例执行
2. 用例按照微服务接口添加微服务标签，对应服务升级流水线可挂在对应服务标签的用例，同时搭配用例优先级，双重层级选择用例
3. 新需求用例增加新需求用例标签，验证时单独执行，不添加至日常任务中，保证日常任务执行稳定性，待需求上线后更新标签为微服务标签、设定优先级
4. 预置变量的规范性和必要性

用例中我们不可避免的要预置变量，变量不能设置id值，且对变量的预置要知会全组告知变量用途，要有一个变量维护表格，不能任意增加预置变量，预置变量要精简

1. 制定统一的编码和用例编写规范

考虑到自动化工程的维护性，要统一规定自动化代码规范，细化到元模型的命名、代码结构

对于返回值首先要将接口原生返回的内容返回出去，保证在外部能看到接口原生返回的东西，这样断言出错我们能明确知道接口返回的数据是啥，而不用查看自动化日志。对于需要进行处理的内容在做单独处理返回。

1. 残留数据的清理

要做好创建数据的清理

1. 问题定位日志

在调用接口前将接口名、请求方法、元模型函数名、请求数据、（用例名）进行日志打印

接口调用后将接口返回结果进行日志打印，将数据处理结果也进行打印

用于后续用例出错的问题定位

后续日渐更新，希望自己通过不断地总结思考提升自己的测试领悟