关于接口自动化测试，我有话想说

大家好，我还是那个不怎么会带娃，不怎么会测试的伪测试

之前做工作的时候，项目的接口基本都是单接口，做的都是一些简单的接口自动化，比如用soupui工具来做，根据接口的各种入参和接口的业务逻辑设计测试用例，在没有考虑维护性，可扩展性以及复用性的情况下作了一些简单的自动化，比如当我们对接口进行校验的时候，需要我们对每一个接口都手工的编写测试用例，测试步骤，而且不断的复制，修改，复制，修改，还有，当我们验证某个接口的时候过于死板，有的参数可能不需要我们进行过多的异常验证，比如，接口传入的用户ID，系统里面，每个用户都有一个唯一的id，所以，用户是不可能修改这个id的，那么接口也不需要传错误的id进行验证。

这些就说完了么，当然没有。

这里有些新思路

1. 首先我们说说接口自动化的使用
   （1）测试环境、现网环境的巡检，后者更重要，巡检其实做的就是通过接口请求返回的code，判断接口服务器是否work well，这就够了，如果异常，就报警，发邮件给运维人员
   （2）就是参数完整性校验，这个是在开发阶段比较有用，就是当服务端接口开发完成时，可以用这个校验，通过后，再交给客户端开发联调；
   （3）回归测试，这个其实现在更多的是依赖于手工测试，并不能完全依赖于接口或UI级的自动化测试
2. 如果只是为了1中提到的（1）和（2），那么我们对接口进行半分离的测试，也就是接口自动化测试的需求定位到参数校验中，当然这个思路也是大婶的那个思路了。
3. 如果我们还希望达到将接口自动化测试工具使用到回归测试里面，那么我们就需要将逻辑验证的需求加入接口自动化工具中。
4. 如果将业务做进接口自动化，怎么做？如果不出意外，我们要为每一个接口测试测试用例，不过对于联系比较紧密的接口，我们可以在一个文件中进行处理，比如购买的时候必须填写验证码一样，就要调用验证码的接口，如果我们将几个联系紧密的接口一起测试，那么久可以减少文件很多重复的地方。
5. 在做接口的业务测试的时候，我们要考虑覆盖率。如果只是做参数校验，不做业务校验，其实对于回归测试意义没有很大。
6. 对接口测试本身来说，参数完整性，接口返回码，业务逻辑正确性这三类校验都昨晚，才能说这个接口测试完成了，没有问题了（这里暂时不涉及接口的性能和安全）
7. 自动化工具的开发和维护要考虑性价比，也就是投入产出比

写在后面的话

感谢tina，感谢老川