方案
- ①分别记录老接口或者线上接口的接口返回数据（本地文件或者数据库）：其中老代码为线上稳定版本
- ②构造测试数据：我们可以手工构造测试数据，也可以对线上的数据进行抽样，用于diff测试
- ③运行测试：使用测试数据分别在新、老接口代码中运行，并捕获测试结果
- ④结果对比：对比新、老接口结果，相同接口下的输出，如果出现差异，则可以通过接口反向定位问题
注意：
- 1.接口覆盖：为了更全面对接口进行diff回归，每次接口增加/修改后，都要及时添加到diff项目中；
- 2.接口diff目前更多针对的是读数据的请求，也可以根据具体情况做写数据的diff，但要注意写数据会在线上产生脏数据（目前只有读，上传文件或新增无删除的接口都没有录入）
局限性
- 1.不能对新增接口检查。
- 2.接口覆盖度有限。如果一个接口有A,B两个参数，你只用了A，B分别做diff,没有使用A,B组合做diff,而bug正好出现在A,B组合的点，此时的对比是发现不了问题的。
「例如，项目中一个接口的参数在40+的时候，可能bug隐藏更深了。」
- 3.被当做标准的接口本身就有点问题时，可能diff就变得“将错就错”了。其实diff测试时，无论如何，都要防止此类情况的发生。所以，就diff测试本身来说，还需要其他的手工测试/自动化测试来辅助。（不可当做基本的接口测试，放在稳定版本的接口测试通过后的流程后使用最佳）
- 4."写"接口diff时，存在漏洞，当测试代码写入的数据，不能及时被读出时，此时可能会遗漏掉这个检查.
框架思路
diff模块思路
下集预告
- 接口diff测试的局限性
- 接口diff测试的代码实现
