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

梦幻小丑灯

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

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

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

xjw123456

不错，看完后我有学到东西。谢谢！