AI 一次生成几十条测试用例，容易让人误以为覆盖已经足够；但数量本身说明不了关键风险是否被覆盖，更不能证明每条预期都有依据。
评审时要从用例追到需求和风险，再确认步骤与断言能否真正揭示错误。
先建立可追溯关系
把登录需求中的确认规则编成标识，后续每条用例都引用相应规则或风险：
| 规则 | 对应的测试关注点 |
|---|---|
| R-01：验证码有效期为 5 分钟 | 有效期内、过期后，以及边界规则待确认 |
| R-02：每个手机号每天最多发送 20 次 | 达到限制后的行为、计数窗口待确认 |
| R-03：连续输错 5 次后锁定 15 分钟 | 第五次错误、锁定期间以及解除条件 |
| R-04：首次成功验证后创建账号 | 成功后创建；失败路径是否留下账号或其他状态，需按需求确认 |
这些规则仍是系列的练习设定。真实用例要引用实际需求编号、接口契约或确认记录；找不到依据的预期结果应标成待确认，不能当作产品事实。
新手入门：从一条已确认的需求开始
第一次审查 AI 生成用例，不用先追求数量。选一条短而明确的需求，按下面的步骤走一遍：
- 先找依据。 找到需求、验收标准或接口契约，标出规则编号和版本；规则有空白时先记下来，不让 AI 替你补产品决策。
- 给 AI 足够上下文。 提供需求原文、已知限制、测试对象和输出格式，并要求它把未知项单独列为“待确认”。
- 先生成一小组场景。 要求覆盖主路径、失败路径、边界和状态变化；每条用例标注对应规则、前置条件、输入、预期结果与观察点。
- 人工逐条追溯。 用本节的审查清单检查遗漏、无依据预期、断言强度和可执行性。
- 挑代表性用例验证。 在获准的测试环境准备数据并执行；记录实际结果。没有执行的用例仍是“未验证”。
- 把发现带回下一轮。 记录问题类型和最终确认，不只保留修订后的用例，还要保留能复现问题的样本。
可以这样开始：
请仅根据下面的需求生成 5 条代表性测试用例，不要补造未说明的产品行为。
需求原文和版本：[粘贴或填写]
已确认规则编号：[填写]
测试范围和已知限制：[填写]
请用表格输出：用例 ID、规则依据、风险、前置条件、输入、步骤、预期结果、观察点。
把缺失的规则和无法确定的预期标成“待确认”，并说明还需要谁确认。常见问题不只在“漏测”
| 问题 | 例子 | 为什么值得拦下 |
|---|---|---|
| 覆盖遗漏 | 没有检查验证码过期，也没有覆盖锁定解除 | 关键状态可能从未验证 |
| 无依据假设 | 自行规定接口返回 400 或提示“验证码错误” | 实际契约可能不同 |
| 断言太弱 | 只验证响应成功，没有确认用户账号状态 | 接口表面成功不等于业务结果正确 |
| 步骤不可执行 | 没有说明如何准备过期验证码或触发限流 | 测试人员无法稳定复现 |
| 虚假通过 | 用例被跳过、异常被吞掉、断言恒真 | 测试结果不能支持质量结论 |
也要检查失败场景的副作用。例如错误验证码被拒绝后，系统是否仍创建了账号？只验证页面出现一条错误消息，可能漏掉数据状态已经改变的问题。
一份实际可用的审查清单
逐条检查时，可以问：
- 预期结果能否追溯到需求、接口约定或已确认行为？
- 是否覆盖正常、异常、边界、状态变化、权限和关键依赖？
- 前置条件和测试数据能否稳定准备，执行步骤能否重复？
- 断言是否检查业务结果及必要的数据副作用，而不只是页面或状态码？
- 是否存在跳过测试、捕获异常后继续、空断言或依赖偶然环境的情况？
如果有重要测试被判为通过，最好再确认一次：故意让对应行为失败时，这条测试是否也会失败？可以用受控的测试替身或局部变异验证断言是否真的有效，不要在共享或生产环境中随意破坏功能。
示例：从需求规则追到断言
下面沿用本节的练习规则 R-03“连续输错 5 次后锁定 15 分钟”，只演示审查方法，不代表任何实际产品规则或运行结果。
| 审查项 | 需要核对的内容 | 结果如何解释 |
|---|---|---|
| 需求依据 | 用例是否引用 R-03 及其版本，而不是凭经验补规则？ | 没有版本或来源时，预期结果待确认 |
| 边界输入 | 前 4 次错误、触发锁定的第 5 次、锁定期间的请求分别是什么？ | 若用例只测“输错后出现提示”，还没有覆盖锁定阈值 |
| 观察点 | 是否能检查认证状态或服务端锁定状态，而不只看页面文案？ | 只观察到提示时，不能据此确认服务端状态已改变 |
| 时间条件 | 15 分钟从何时开始计算，期满边界如何处理？ | 规则没有说明边界包含关系时，先记录为待确认 |
| 执行证据 | 记录用例 ID、环境、测试数据编号、运行时间、断言结果和原始报告位置 | 未运行的用例保持未验证；不能按设计内容标为通过 |
如果 AI 生成的用例没有区分第 4 次与第 5 次尝试，评审发现应指出缺失的边界场景，并要求补上有来源的预期结果。若规则没有说明锁定期间的返回内容，就只把该字段列为问题，不替产品定义响应码或文案。
把模糊描述改成可评审条件时，可以先补足“依据、数据、观察点”，再核对预期结果是否真有来源：
| 写法 | 审查判断 |
|---|---|
| 弱用例：“连续输错验证码，页面提示错误。” | 没有规则编号、尝试次数、锁定状态观察点，也没有说明失败时是否产生副作用，无法证明 R-03 已验证。 |
| 可评审用例：“依据 R-03，在隔离环境用可重置的合成手机号，先连续提交 4 次错误验证码并记录状态；确认重置计数后，再连续提交 5 次错误验证码并观察第 5 次后的状态。按接口契约检查响应和获准的锁定状态查询，并记录账号副作用与清理结果。” | 场景和观察点已清楚；具体响应码、提示文案、测试钩子及边界包含规则仍须引用项目契约，未定义的项目继续标“待确认”。 |
这个改写只补足观察步骤，没有替产品增加规则。它把需要确认的行为显出来，也要求检查账号副作用，不能只凭“页面出现提示”就认定 R-03 已验证。
让 AI 帮忙找问题，但不让它自我盖章
可以用下面的指令对 AI 生成的用例做第二轮检查：
请审查以下测试用例，不要继续增加用例数量。 对每条用例检查：
- 是否有需求依据，是否把未知规则写成事实；
- 是否遗漏重要状态、边界、失败路径或副作用；
- 前置条件和步骤能否稳定执行；
- 断言是否足以发现目标问题；
- 是否可能在功能错误时仍然通过。 请引用需求内容作为证据。无法确认的地方标记“待确认”。
这轮审查仍可能沿用同一个模型的盲点，只能辅助筛查，不能视为独立认证。风险较高的功能仍需要测试人员、产品或研发确认，并通过真实环境执行和证据记录。
AI Test Auditor 可以作为静态源码审查的补充参考：它只检查受支持的 JavaScript 和 TypeScript 测试源码，报告少数可能让测试失效的模式；不会运行测试或计算覆盖率。没有告警也不能证明用例有效。使用前应核对项目文档，确认它支持的测试框架和源码范围适合你的例子。
AI Test Auditor: https://github.com/AI-Native-QA-Lab/ai-test-auditor
做一次小练习：从已有结果中挑几条用例，给它们补上需求依据，检查边界和断言，再记录发现的问题类型。比起把用例数量继续翻倍，这样更容易看出生成内容离“可信测试”还差什么。
最佳实践：让评审结论能被重复使用
- 每条预期都保留需求、接口契约或决策记录的出处；来源不明时标“待确认”。
- 按风险审查覆盖，优先看边界、状态转换、权限、失败路径和副作用，不用用例总数代替覆盖判断。
- 把“已设计”“已执行”“已验证”分开记录。未运行、跳过、执行失败和通过不能混成一种状态。
- 用受控变异或测试替身检查关键断言能否识别错误；只在安全、隔离的测试环境进行。
- 把已确认的规则、反例和评审标准纳入小型回归样本；规则或生成方式变化时复查，不把旧结果当永久保证。
常见问题（FAQ）
AI 生成的测试用例可以直接使用吗？
不建议。先核对每个预期结果的来源、风险覆盖、数据准备、断言和副作用，再在合适环境执行。AI 输出是待审查的草稿，不是质量证明。
新手应该从哪里开始？
从一条已确认的需求开始，要求 AI 生成少量可追溯场景，逐条对照需求评审，再执行一条代表性用例。按本文“新手入门”中的步骤和 Prompt 完成第一轮即可。
怎样发现 AI 漏掉的场景？
先把需求拆成规则和风险，再检查正常、失败、边界、状态变化、权限和副作用。用例没有对应需求或风险时，覆盖缺口仍可能存在。
让同一个 AI 再审一次，算独立复核吗？
不算。第二轮可以筛出明显问题，但模型可能重复同一盲点；高风险场景还需熟悉业务的人确认，并以测试执行证据支撑结论。
需求没有说明响应码或错误文案怎么办？
不要猜。把缺失的行为标为“待确认”，向需求或接口负责人确认后再写预期结果。否则自动化可能把未经批准的假设固化下来。
评审后如何持续改进？
把遗漏、弱断言和无依据假设归类，修订需求上下文、生成 Prompt 或评审规则，再用同一批代表性样本复核。具体步骤见下方独立的质量循环。
重点：把用例评审放进日常质量循环
质量循环不是一次性评审，也不是单纯让 AI 反复生成更多用例。 每次故事或需求变化，都要把真实发现反馈给下一轮；同时用固定样本确认调整是否真的减少遗漏，而不是只让输出看起来更完整。
在日常测试里，每条新需求至少留下一组代表性样本；评审或执行发现的问题进入缺陷/改进记录，并注明根因和证据。调整生成上下文或评审规则后，重跑同一批样本，检查旧问题是否消失、新问题是否出现。只有确认过的业务结论才沉淀为规则，未决项继续保持未决。需求、模型或 Agent 改变时，也重新跑这组样本。
这样，AI 生成的测试会随着真实评审与执行结果逐轮改进；质量提升来自可追踪的反馈和复查，而不是单轮输出的数量。