先确认测试是不是只证明代码能跑
AI 写测试很快，但测试都通过不等于真实风险已经被覆盖。它可能只是把当前实现复述了一遍，或者只验证函数会返回某个值，没有验证业务结果是否正确。
先从失败信号判断这篇测试值不值得信任：
| 检查项 | 你要看到什么 |
|---|---|
| 断言 | 不只断言非空、长度、状态码，还断言业务结果 |
| 输入 | 不只测正常参数，也测边界、异常和重复操作 |
| 失败能力 | 改错一行关键逻辑时，测试会失败 |
| 业务风险 | 测试覆盖支付、权限、库存、额度、状态流转等高影响路径 |
如果一套 AI 测试只能提高覆盖率数字，却不能在关键逻辑被改坏时失败，先不要把它当成回归保护。
断言有没有真的卡住业务结果
很多 AI 生成测试看起来很完整，但断言很浅。它会检查函数是否被调用、返回值是否存在、数组长度是否大于 0，却没有检查真正的业务结果。
先打开每个测试，看断言是不是落在这些位置：
- 金额、币种、折扣、手续费、库存等计算结果。
- 状态机的前后状态，例如
pending -> paid -> fulfilled。 - 权限边界，例如普通用户不能执行管理员动作。
- 幂等结果，例如重复回调不会生成第二笔订单。
- 错误分支，例如第三方接口失败后是否进入补偿逻辑。
浅断言常见长这样：
expect(result).toBeDefined()
expect(items.length).toBeGreaterThan(0)
expect(service.create).toHaveBeenCalled()更有价值的断言要卡住业务事实：
expect(order.status).toBe('paid')
expect(order.payments).toHaveLength(1)
expect(order.discountAmount).toBe(300)
expect(refundJob).not.toHaveBeenCalled()有没有只测 happy path
AI 很容易沿着最顺的路径写测试：输入合法、依赖正常、接口成功、用户只点一次按钮。真实 bug 往往出在反方向。
优先补这几类路径：
| 路径 | 要补的测试 |
|---|---|
| 重复操作 | 重复提交、重复回调、重复扣减 |
| 外部失败 | 支付超时、库存服务失败、消息队列延迟 |
| 中断恢复 | 页面关闭、请求重试、任务重跑 |
| 权限变化 | 用户角色被降级、token 过期、组织权限变更 |
| 状态冲突 | 订单取消后收到支付成功回调 |
如果 AI 只生成“成功创建订单”“成功支付”“成功发送通知”，下一步不是继续让它多写几条同类测试，而是让它按失败路径补用例。
业务边界有没有单独列出来
通用边界不等于业务边界。空值、负数、超长字符串当然要测，但很多线上问题来自业务组合。
先把业务边界写成清单，再让 AI 对着清单补测试：
请基于下面业务边界补测试，不要只追求覆盖率：
1. 订单取消后又收到支付成功回调
2. 同一个支付回调重复到达
3. 优惠券和会员折扣同时生效
4. 库存扣减成功但发货任务创建失败
5. 第三方接口超时后用户再次提交
6. 金额、币种、手续费和汇率同时参与计算这类输入比“给这个函数写测试”更有效，因为它把测试目标从代码结构拉回业务风险。
覆盖率有没有制造错觉
覆盖率只能说明代码被执行过，不能说明测试验证了正确行为。AI 很擅长快速跑到更多分支，所以覆盖率可能上升很快，但缺陷发现能力没有同步上升。
看覆盖率时至少再问三件事：
- 覆盖的是核心业务路径，还是低风险工具函数。
- 每条路径有没有关键断言，还是只跑过代码。
- 改坏关键逻辑时，测试是否真的变红。
可以用一个很小的反向检查：临时把核心计算、权限判断或状态流转改错，运行 AI 生成的测试。如果测试仍然通过，这套测试对当前风险没有保护力。
跨系统状态有没有被验证
AI 在单个函数里表现通常更好，但真实项目常常坏在系统边界。订单、支付、库存、消息、搜索索引、邮件通知和数据统计之间只要有一个状态没对齐，单测就可能全绿，用户仍然遇到错误。
跨系统路径至少要检查：
| 风险点 | 验证标准 |
|---|---|
| 事务边界 | 主流程失败后是否回滚或补偿 |
| 消息队列 | 重试、乱序、重复消息是否安全 |
| 第三方接口 | 超时、限流、部分成功是否有分支 |
| 数据一致性 | 前台状态、后台记录和审计日志是否一致 |
| 权限传播 | 角色变化后缓存和下游服务是否同步 |
如果 AI 只看当前文件，它通常不会主动补这些测试。需要把调用链、外部依赖和失败后果一起给它。
历史线上问题有没有变成回归用例
线上 bug 是最有价值的测试素材。每次修复后都要反向补一条能复现旧问题的测试，否则 AI 后续很可能继续生成“看起来合理但避开真实风险”的测试。
记录模板可以这样写：
incident: 订单取消后收到支付成功回调，订单被错误改回 paid
rootCause: 回调处理没有检查 canceled 状态
expectedRegressionTest:
setup: 创建 canceled 订单
action: 模拟支付成功回调
assertion:
- 订单状态仍为 canceled
- 不创建发货任务
- 记录异常回调日志把这个模板交给 AI，比让它重新猜“还要写哪些测试”更稳定。
让 AI 重写测试时怎么下指令
不要只要求“补充测试”“提高覆盖率”。直接给它风险清单、失败标准和审查要求。
可以复制这个提示词：
请审查当前测试是否真的能发现业务 bug。
重点检查：
1. 断言是否只验证非空、长度、调用次数或快照
2. 是否只覆盖 happy path
3. 是否遗漏边界条件、异常路径、重复提交和第三方失败
4. 是否覆盖历史线上问题和高风险业务规则
5. 改坏核心逻辑时，哪些测试会失败
输出：
- 先列出低价值测试
- 再列出缺失的高风险测试
- 最后给出可直接运行的测试代码如果 AI 不能指出哪些测试低价值，只是继续追加更多类似用例，先停下来人工补业务规则。
修完后怎么确认测试更可靠
补完测试后不要只看全绿。至少做一次小型验证：
- 临时改坏一个核心业务判断，测试应该失败。
- 删除一个异常分支处理，测试应该失败。
- 把第三方接口响应改成超时或失败，测试应该覆盖对应分支。
- 运行同一组测试两次，结果应该稳定。
- 新测试名称应该能说明业务风险，而不是只描述函数名。
成功标准不是“AI 又生成了更多测试”，而是这组测试能在关键逻辑被改坏时把问题拦下来。
FAQ：AI 写测试常见误区
AI 写的测试都通过了，还需要人工看吗？
需要。测试通过只代表已覆盖的断言成立。断言浅、路径窄、业务规则缺失时，全绿反而会制造错觉。
覆盖率已经很高，还要补测试吗？
要看覆盖的是不是风险。核心支付、权限、数据删除、计费、库存、合规流程，比低风险工具函数更值得优先补测试。
AI 最适合写哪类测试？
适合先生成基础单测、重复性接口测试和回归测试草稿。复杂业务边界、跨系统状态和线上事故回归，需要开发者先给出清楚的风险输入。
怎么判断一条 AI 测试是不是低价值？
看它改坏核心逻辑时会不会失败。如果不会失败，或者只断言非空、长度、调用次数，它更像覆盖率填充，不像质量保护。
要不要让 AI 自动修测试直到全绿？
不要直接放任它改到全绿。先固定业务期望，再让它修测试或修代码。否则它可能把断言改松，甚至把真正暴露问题的测试删掉。