接口测试那些事儿
什么是接口？
首先，在讲接口测试之前，我们先要搞清楚接口类型的概念。
接口：可能是系统与系统（包括服务与服务）之间的调用，像A系统（服务）给B系统（服务）提供的服务，通过比如常见的dubbo接口来实现；也有可能是上层服务对下层服务的调用，比如service层会调用DAO层的接口。目前在我司，主流的接口自动化测试涵盖rpc和http两个协议类型。
测试接口的原则是什么？
- 自动化测试脚本互不影响的，隔离的（解耦）
- 自动化测试中被测功能是互不影响的
- 自动化测试能够快速定位bug位置
- 自动化测试脚本是易于阅读的，能帮助我们理解产品的
- 自动化测试脚本是易于编写的，易于维护的以及易于扩展的
- 脚本间没有联系，保持原子性
- 数据与脚本尽量分离，脚本执行不影响基础数据（还原数据）
- 脚本可重复执行，不依赖执行顺序
测试接口的策略有哪些？
- 接口功能测试：接口测试本质上也是为了实现业务功能，所以最核心的当然是是否符合业务的需求，因此需要测试接口的功能是否满足业务要求，这是最重要的。
- 接口异常测试：你无法保证入参的正确性，所以需要对所有可能的入参进行测试校验，比如入参为null等异常情况，接口的异常是否有处理等。另外接口的健壮性也是需要考虑的，在高并发下是否有性能问题，内存泄漏问题等等。
- 接口白盒测试：你在测试接口的同时，通常需要review开发的代码实现，这个时候其实已经在做接口的白盒测试。
测试接口的工具有哪些？
- Jmter
- HttpClient
- postman
- 公司内部网关的中间件测试工具
- 等等
接口测试的效率怎么衡量？
测试覆盖率：现在市面上主流公司都会有自研的代码覆盖率统计工具，其原理基本都是基于JaCoCo的二次开发来实现代码的行覆盖率、方法覆盖率、类覆盖率统计。有了覆盖率的数据支撑，我们对脚本就可以进行查漏补缺，心里也有了底。
测试回归时间上：如果脚本数量比较多（数千以上），那么每次如果都是全量回归的话时间持续比较久，那么我们就要考虑一方面脚本是否需要多线程执行（testng可以提供这样的功能，parallel+thread-count），另一方面我们就要考虑精准回归。（对脚本用例进行分层执行）
接口的流量回放
接口测试因为各种问题，其实并不能100%覆盖线上。因此，诞生了一种更加全面的测试手段，就是流量回放。
核心：基于阿里开源工具——jvm-sandbox-repeater （github 地址）
原理在这里就不多做解释了，可以参考：流量回放框架 jvm-sandbox-repeater 的实践
总结
最后说一句，最重要的，衡量脚本回归是否有效的指标，就是通过持续集成，在平时最终能发现多少问题，这才是接口测试持续集成的价值。