开头
很多团队尝试用 AI 做测试推荐时，都会这样问：
这个需求是优化订单取消逻辑，请帮我生成测试用例。
AI 通常会给出一堆看起来正确的建议：
- 正常取消订单。
- 重复取消订单。
- 订单不存在。
- 权限校验。
- 并发取消。
- 异常场景。
这些建议不能说错，但问题是太通用。
它没有回答一次真实发版最关键的问题：
这次代码改动到底影响了哪里，哪些场景必须优先回归？
要让 AI 推荐真正有用，必须先给它足够的工程上下文。
1. 上下文 1：需求背景
需求背景告诉 AI 业务目标。
示例：
本次需求：优化订单取消逻辑。
当用户取消未支付订单时，需要释放库存、回滚优惠券，并记录取消原因。
只有需求背景，AI 可以生成通用测试点，但不能判断代码影响面。
所以需求背景只是第一层。
2. 上下文 2：代码 Diff
Diff 告诉 AI 真实改动。
建议至少提供：
变更文件：OrderCancelService.java, InventoryService.java
变更方法：
- OrderCancelService#cancelOrder
- InventoryService#releaseStock
- CouponService#rollbackCoupon
变更类型：修改
如果能提供方法级摘要更好：
OrderCancelService#cancelOrder：新增取消原因校验，调整库存释放顺序。
InventoryService#releaseStock：新增幂等判断。
AI 需要基于真实改动推荐，而不是基于需求标题想象。
3. 上下文 3：历史调用链
调用链告诉 AI 变更方法被哪些入口使用。
示例：
入口 1：POST /order/cancel
链路：OrderController#cancel → OrderCancelService#cancelOrder → InventoryService#releaseStock → CouponService#rollbackCoupon
入口 2：Job: close-timeout-order
链路：TimeoutOrderJob#close → OrderCancelService#cancelOrder → InventoryService#releaseStock
如果没有调用链，AI 不知道定时任务也会影响订单取消逻辑，就可能漏掉超时关闭订单场景。
4. 上下文 4：本次覆盖率
覆盖率告诉 AI 当前测试执行情况。
示例：
已覆盖：POST /order/cancel 正常取消订单
未覆盖：Job: close-timeout-order 超时关闭订单
未覆盖分支：重复取消订单、库存释放失败
这时 AI 就不只是生成测试点，而是能判断：哪些已经测过，哪些还要补。
5. 上下文 5：历史缺陷
历史缺陷告诉 AI 哪些地方曾经出过问题。
示例：
历史缺陷：
1. 重复取消订单导致库存重复释放。
2. 优惠券回滚失败但订单状态已取消。
3. 超时关闭订单时未记录取消原因。
这些信息能帮助 AI 提高风险优先级。
同样是未覆盖场景，关联历史缺陷的场景应该优先补测。
6. 上下文 6：业务约束
业务约束能减少 AI 胡说。
示例：
业务约束：
- 已支付订单不允许用户主动取消。
- 未支付订单取消后必须释放库存。
- 优惠券回滚失败时需要告警，不阻断订单取消。
- 取消接口需要幂等。
如果不告诉 AI 这些规则，它可能输出不符合业务的建议。
7. 推荐 Prompt 模板
可以直接使用下面这个结构：
你是一名资深测试架构师。请基于以下工程上下文，推荐本次发版的回归范围。
需求背景：{{需求背景}}
代码变更：{{变更文件、类、方法、摘要}}
历史调用链：{{入口、链路、资源访问}}
本次覆盖率：{{已覆盖、未覆盖、未覆盖分支}}
历史缺陷：{{缺陷摘要}}
业务约束：{{核心业务规则}}
请输出：
1. 变更摘要。
2. 风险等级：高/中/低，并说明原因。
3. 影响入口：接口、RPC、MQ、定时任务。
4. 必测场景：按优先级排序。
5. 当前已覆盖场景。
6. 当前未覆盖风险。
7. 建议补测场景。
8. 需要研发确认的问题。
要求：
- 不要输出泛泛测试类型。
- 每条建议必须能追溯到输入上下文。
- 如果信息不足，明确列出缺失信息。
8. 示例输出
风险等级：高
原因：本次修改订单取消与库存释放逻辑，影响用户主动取消和超时关闭两条入口；历史上出现过库存重复释放缺陷。
必测场景：
1. 未支付订单用户主动取消，验证订单状态、库存释放、优惠券回滚。
2. 重复取消同一订单，验证接口幂等。
3. 超时关闭订单任务执行，验证库存释放和取消原因记录。
4. 库存释放失败时，验证订单状态和告警逻辑。
未覆盖风险：
- 超时关闭订单链路未覆盖。
- 重复取消分支未覆盖。
需要研发确认：
- 库存释放失败时是否允许订单状态变为已取消？
这个输出比泛泛测试点更接近真实可执行的回归清单。
9. 总结
AI 推荐回归范围，不是靠一句需求描述完成的。
你至少要给它：
- 需求背景。
- 代码 Diff。
- 历史调用链。
- 本次覆盖率。
- 历史缺陷。
- 业务约束。
AI 的价值不是替代测试判断，而是基于工程事实帮助测试人员整理风险、排序场景、发现遗漏。
如果前面的数据链路不完整，AI 越强，输出也越像“高级废话”。
