背景
接口Diff测试,简单来说就是比对相同接口在不同版本/不同环境下面的返回内容是否符合预期。
对于日常迭代的接口来说,Diff测试是我们接口基本功能测试的有效补充,因为采用的是自动化的手段,它可以利用线上大量的请求日志在新旧两个版本中进行回放,而我们手工/自动化的接口回归往往只局限于少量的测试数据和一些特定的参数,很难覆盖到大量的、在生产环境真实会发生的异常请求数据。
单纯的依靠有限的CASE进行接口功能覆盖,上线后或多或少还是会发现一些异常,在此背景下开发了接口diff框架。
接口diff的用途
1)高效率进行接口的回归
尤其当接口众多时,接口的返回字段众多时,此时[人工]检查接口,效率太低了。例如,项目中已经发现的问题包括:
- 某个接口比之前少了一个关键字段(该字段在页面需要展示的);
- 某个接口中的字段值错误(字段值计算的内部逻辑被改错了);
2)快速发现接口修改前和修改后的差异
因为大部分代码的修改体现在接口返回的变化上,因而使用接口的变化来反向验证 代码的修改影响。通过diff测试。
- 可以发现相同接口下内部代码逻辑变更对其输出的影响,测试人员只需要对比diff接口的差异之处(或自动对比),从而大幅减少人工作业的工作量。
- 2. 筛选自动化用例:当RD提测时,可以根据接口diff筛选出相关联自动化用例,与CI相结合,达到精简用例,减少执行时间,同时减少不必要的用例执行,进而提升CI稳定性,减少CI维护排查代价。
3)快速验证某些场景下的测试
- 例如,曾经一个项目,变更了DB中的几张表,但要求接口返回的字段只多不少(就是原来接口中含有的字段,修改使用表后一定要有,可以有多余的字段)。此时使用 两个版本代码中的接口 直接diff 是不是很easy了。
- 2. 服务端语言由PHP语言改成GO了,原来的接口逻辑我又不了解,不知如何测试。
- 3. 接口迁移或者服务器迁移,但是呢又需要保证迁移前后返回的数据是一致的,这时候就需要做diff测试
下集预告
- 接口diff测试的方案
- 接口diff测试的局限性
- 接口diff测试的代码实现