大家好,我还是那个不怎么会带娃,不怎么会测试的伪测试
之前做工作的时候，项目的接口基本都是单接口，做的都是一些简单的接口自动化，比如用soupui工具来做，根据接口的各种入参和接口的业务逻辑设计测试用例，在没有考虑维护性，可扩展性以及复用性的情况下作了一些简单的自动化，比如当我们对接口进行校验的时候，需要我们对每一个接口都手工的编写测试用例，测试步骤，而且不断的复制，修改，复制，修改，还有，当我们验证某个接口的时候过于死板，有的参数可能不需要我们进行过多的异常验证，比如，接口传入的用户ID，系统里面，每个用户都有一个唯一的id，所以，用户是不可能修改这个id的，那么接口也不需要传错误的id进行验证。
这些就说完了么？当然没有。
这里有些新思路
-
首先我们说说接口自动化的使用。
（1）测试环境、现网环境的巡检，后者更重要，巡检其实做的就是通过接口请求返回的code，判断接口服务器是否work well，这就够了，如果异常，就报警，发邮件给运维人员
（2）参数完整性校验，这个是在开发阶段比较有用，就是当服务端接口开发完成时，可以用这个校验，通过后，再交给客户端开发联调；
（3）回归测试，这个其实现在更多的是依赖于手工测试，并不能完全依赖于接口或UI级的自动化测试 -
如果只是为了1中提到的（1）和（2），那么我们对接口进行半分离的测试，也就是接口自动化测试的需求定位到参数校验中，当然这个思路也是大婶的那个思路了。
-
如果我们还希望达到将接口自动化测试工具使用到回归测试里面，那么我们就需要将逻辑验证的需求加入接口自动化工具中。
-
如果将业务做进接口自动化，怎么做？如果不出意外，我们要为每一个接口测试测试用例，不过对于联系比较紧密的接口，我们可以在一个文件中进行处理，比如购买的时候必须填写验证码一样，就要调用验证码的接口，如果我们将几个联系紧密的接口一起测试，那么久可以减少文件很多重复的地方。
-
在做接口的业务测试的时候，我们要考虑覆盖率。如果只是做参数校验，不做业务校验，其实对于回归测试意义没有很大。
-
对接口测试本身来说，参数完整性，接口返回码，业务逻辑正确性这三类校验都做完，才能说这个接口测试完成了，没有问题了（这里暂时不涉及接口的性能和安全）。
-
自动化工具的开发和维护要考虑性价比，也就是投入产出比
最后： 为了回馈铁杆粉丝们，我给大家整理了完整的软件测试视频学习教程，朋友们如果需要可以自行免费领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
