说下我的做法：

1. 记录每个接口上次正常运行的结果（主要是入参和出参的数据结构）
2. 定期自动回放接口，对比返回的结果，如果报错或者返回的数据结构不对应，则告警；
3. 更新测试用例 以上步骤做成接口测试平台中的一个功能点。对于新增的接口，如果没有提测，可以不需要关注。

常规方案一般是根据接口文档去做 diff 判断
但是接口内部逻辑的变更没办法获取

我们现在的方案是代码调用链路分析 +git diff
（1）首先采用静态 + 动态调用链路分析获取 服务间的调用链路以及接口内部方法的调用链路
（2）服务部署后 自动获取当前部署代码和上次部署代码的差异 git diff
（3）根据代码差异中变更的内部方法 获取影响本服务的哪些接口
（4）根据服务间的接口调用关系 获取其他服务受影响的接口
（5）打通接口自动化平台，根据影响到的接口 获取涉及的接口自动化用例 推荐对应的接口自动化用例进行执行
（6）接口自动化用例执行后，获取涉及服务的代码覆盖率
（7）生成影响范围、接口自动化测试报告以及代码覆盖率报告

我发现就算是能生成 swagger 文档，有一些语言框架的实现，也是靠开发同事手动在代码里写注释的 (比如我遇到的 go 语言 gin 框架)。

我感觉最好的方法就是拿到代码库权限，看开发代码 commit 记录 (走读基本的业务代码不难的)。

不知道大佬们有没有其他更好的方法。

不知道你们公司开发测试比例是多少。。。我们 10：1，如果 10 个开发每人提交多个 commit，1 个测试 看的话有点困难，而且不够直观

刚做完，通知效果有水印，就不放了，这个是流程

swagger 或 yapi 文档可以有一个版本的概念，两个版本可以做一下 diff，以自己需要的方式展示出差异，以此来确定哪些测试需要调整

就问题本身而言，目前并没有很好的高效的方法。
1、3 楼 接口文档 diff 的强依赖开发提供的接口文档，一个文字的修改都可能产生消息通知，实际执行中效果并不好。
2、8 楼 @Chenkl 的方法只对出参有效，无法对入参变更进行检测

如果问题的出发点是为了获得变更，精准有效的测试：
1、开发主动 announce 告知
每个人在工作中都是一个节点，要做到 “服务好你的下游，对接好你的上游”。
一个接口无论是入参或出参有变更，或者该接口背后对应的程序代码、实现逻辑有变更，一个职业的开发 应有义务通知相关干系人；靠测试自身去 diff，去挖掘是不可取的。

2、使用发布系统
任何模块/组件的上线都需提交到发布系统（发布内容&影响范围&风险等需要有较详细说明），测试只对发布系统中提交的项目进行评估和测试。前提是公司有一套好的发布系统和流程

你这个核心还是 接口文档的 diff

有一个工具····叫 Apifox（https://www.apifox.cn/）
,它等于 postman+swagger+Mock+Jmeter，就你们整个团队的人都能用，一组人都是用的一套接口数据，开发在上面设计和修改接口数据，测试会收到系统通知，然后点下同步就数据同步过来了······比起一大堆技术实现方案，用现成的工具真的是最简单的······最难的部分在于····你们团队能协调沟通决定用这个工具。小兵说是没用的，至少得研发组长拍板。

正准备试试这个，感谢

改接口几种情况：
1.加必传参数，自动化脚本构建的报错就知道了
2.删除无用参数，脚本跑不出来，你多传了也不影响，不影响业务
3.逻辑变更，脚本报错 -> 排查问题 -> 发现问题 -> 修复脚本