用 AI 做变更影响分析与回归用例补齐：从改动清单到可执行测试的三步方法

每次改动一行代码，回归测试却要跑一整套用例，是很多团队的常态。问题不在测试太少，而在不知道这次改动到底影响了谁。用 AI 做变更影响分析，不是让它直接替你写全部用例，而是先把改动清单变成一张可核对的影响地图，再按风险补齐真正需要跑的用例。

一、先给 AI 一份干净的改动清单

不要只把 diff 扔给模型。先整理三类信息：改动的文件与函数、改动的接口与数据字段、改动背后的业务意图。

例如：订单金额计算函数改了折扣规则，接口返回新增了一个字段，数据库中订单状态枚举多了一个值。把这三点写清楚，模型才能沿着调用链往外扩，而不是凭空猜测。

一个可直接用的提示模板是：

请根据以下改动清单，列出直接调用方、间接调用方和受影响的接口，区分确定影响、可能影响和无影响，并说明判断依据。

如果模型给出的影响面没有依据，就要求它逐条标注来源文件和函数名，删掉无法溯源的条目。

二、按风险分层，而不是按数量补用例

影响分析完成后，把用例分成三层：

1. 必跑层：直接改动点、金额计算、状态流转、权限校验，这类用例一个都不能省。
2. 抽查层：间接调用方和边界条件，例如折扣为零、满减叠加、订单取消后退款，挑代表性组合覆盖。
3. 观察层：低频分支和报表统计，先记录为回归清单，上线后用日志和监控验证。

这样做的好处是回归范围可解释：产品问为什么只跑这些用例，你能拿出影响链，而不是说模型就是这么建议的。

三、把补齐的用例写成可执行，而不是可阅读

让 AI 输出用例时，要求固定格式：前置数据、操作步骤、预期结果、清理动作。

示例：

• 前置数据：创建一个待支付订单，商品单价 100 元，优惠券满 100 减 20。
• 操作步骤：应用优惠券后提交订单，再取消订单。
• 预期结果：应付金额为 80 元；取消后优惠券状态恢复为未使用，退款金额与实付一致。
• 清理动作：删除测试订单，归还优惠券。

如果预期结果里出现模型自己编造的字段或状态，先停下来核对接口文档和代码，再写入用例库。AI 可以帮你想到边界，但不能替你定义正确性。

四、落地时的三条检查清单

1. 每条补齐用例都能追溯到一次具体改动，而不是通用模板。
2. 高风险用例先人工跑通一次，再进入自动化回归集。
3. 上线后对照影响地图复盘：如果线上问题出在未覆盖分支，就把它补进下一次的影响模板，而不是只补一个用例。

变更影响分析的价值不在一次跑得多全，而在每一次改动都有据可查：改了什么、影响了谁、跑了哪些用例、还剩哪些风险。把这个闭环做稳，回归测试才会越跑越轻，而不是越补越重。