背景
接口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测试的代码实现
