AI测试用例评审把大模型放进用例评审环节，用统一维度快速找出覆盖缺口、前置条件缺失和预期结果模糊等问题，再由测试负责人逐条判定采纳或驳回。它适合已有基本用例规范和缺陷记录、希望提高评审一致性的团队；本文给出可执行的流程、角色分工、演示示例和完成检查清单，并说明评审结论如何回写到用例与缺陷记录中。
要点总览（TL;DR）
- AI测试用例评审按“限定范围—准备材料—固定维度—生成问题清单—人工判定—回写留痕”六步执行，每步都有明确的输入、输出和完成标志。
- 测试负责人对AI问题清单做最终判定，用例作者负责材料准备与修复，产品与开发角色澄清需求和技术边界，质量或流程角色维护指标与规则。
- AI问题清单必须逐条判定为采纳、驳回或待澄清，驳回理由和待澄清结论要回流到提示词或需求文档，不能直接作为评审通过结论。
- 每轮评审用漏检率、误报率和评审耗时做抽样复核，规则与提示词按迭代周期集中调整，避免频繁改动导致结果不可比。
- 评审记录需包含问题清单、判定结论、修改前后对比和关联缺陷，ONES可将评审结论作为工作项更新和评论留存，便于追溯。
AI测试用例评审的核心流程与操作步骤
AI评审的价值在于把“凭经验看用例”变成“按维度查用例”。要让结果可用，流程需要先限定范围，再准备输入，然后由AI按固定维度输出问题清单，人工逐条判定，最后回写并留痕。下面六个步骤可以直接作为团队的操作顺序。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确定评审范围与准入条件 | 本轮迭代的用例清单、需求变更记录 | 筛出新增和修改的用例；排除尚未定稿的需求对应用例；标记涉及资金、权限、数据删除等高影响场景的用例 | 本轮AI评审用例清单，标注优先级 | 清单经测试负责人确认，数量与迭代计划一致 |
| 2. 准备输入材料 | 需求描述、设计说明、历史缺陷记录、用例原文 | 把材料整理到同一评审任务下，确保需求版本与用例版本对应；历史缺陷优先选取同类模块近几个版本的记录 | 结构化的评审输入包 | 每条用例都能追溯到对应需求条目，材料无缺页 |
| 3. 设定评审维度 | 团队用例规范、过往评审问题类型 | 固定覆盖度、可执行性、前置条件、预期结果、数据边界五个维度，并为每个维度写明判定标准 | 评审维度说明与提示词模板 | 维度说明经团队评审通过，提示词版本记录在案 |
| 4. 执行AI评审并生成问题清单 | 评审输入包、维度说明与提示词 | 按用例批次提交，要求AI逐条输出问题位置、问题类型、理由和建议修改方向 | 带定位信息的问题清单 | 每条问题都能对应到具体用例和具体字段 |
| 5. 分级处理与人工判定 | 问题清单、用例原文 | 按阻断、重要、建议三级分类；测试负责人逐条判定采纳、驳回或待澄清，驳回需写明理由 | 带判定结论的评审记录 | 所有问题均有判定人、判定结论和理由 |
| 6. 结论回写与留痕 | 判定结论 | 采纳项修改用例并更新版本；需求歧义转为澄清任务；确认的用例缺陷登记为缺陷记录；评审记录归档 | 更新后的用例、缺陷记录、评审归档 | 用例状态更新完成，评审记录可检索 |
范围与准入条件决定了AI评审的投入产出。建议优先纳入新增用例、需求变更影响的用例和高影响业务场景用例；对描述尚不完整、需求仍在讨论中的用例，先完成需求澄清再进入评审，否则AI会把需求本身的不确定当成用例问题，产生大量无效条目。
输入材料的质量直接影响问题清单的针对性。需求描述用于判断覆盖度，设计说明用于核对前置条件和数据准备，历史缺陷用于识别同类模块反复出错的场景，用例原文则是AI定位问题的依据。材料准备阶段值得多花时间，把需求编号、模块、版本对应关系标注清楚，后续判定会省力很多。
评审维度要写成可判定的标准，而不是笼统的“检查完整性”。例如覆盖度看每条需求是否有对应用例、异常分支是否覆盖；可执行性看步骤是否包含具体操作对象和操作值；前置条件看环境、账号、数据状态是否说明；预期结果看是否可观察、可比对；数据边界看是否包含空值、超长、越界和并发等情形。维度固定后，不同批次的评审结果才具备可比性。
AI输出的问题清单必须经过人工判定才能生效。分级处理的目的是把有限精力放在阻断项上：影响用例能否执行的缺失前置条件、无法判断对错的预期结果，应优先处理；措辞和格式类建议可以批量处理或延后。驳回的问题要记录理由，这些理由本身就是下一轮提示词优化的素材。
结论回写是流程闭环的关键。采纳的修改要体现在用例版本中，需求歧义要转为澄清任务并指定负责人，确认的用例缺陷要登记为缺陷记录并关联原用例。评审记录应包含评审时间、参与人、AI问题清单、判定结论和修改前后对比，便于后续追溯和指标统计。在ONES中，用例与缺陷以工作项形式管理，评审结论可以作为工作项更新和评论留存，ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项和Wiki页面等上下文，并把自然语言指令转化为创建缺陷、更新状态、通知负责人等操作，减少评审结论回写时的页面切换和重复录入。
评审角色分工与各环节交付物
AI评审最容易出问题的地方是责任悬空：AI给了问题清单，但没人对“采纳哪些、修改到什么程度、谁来确认”负责。把角色和交付物定清楚，流程才能稳定运行。
| 角色 | 主要职责 | 关键交付物 | 参与环节 |
|---|---|---|---|
| 测试负责人 | 制定评审维度与准入条件，对AI问题清单做最终判定，确认用例是否可以进入执行 | 评审维度说明、判定结论、评审通过记录 | 步骤1、3、5、6 |
| 用例作者 | 准备用例原文和对应需求材料，按采纳结论修改用例，补充缺失的前置条件和预期结果 | 评审输入包、修改后的用例版本 | 步骤2、6 |
| 产品/需求角色 | 澄清需求歧义，确认AI提出的覆盖缺口是否属于真实遗漏 | 需求澄清结论、需求补充说明 | 步骤5、6 |
| 开发角色 | 确认技术实现相关的边界条件，如并发、超时、数据状态变化 | 技术边界说明、缺陷确认意见 | 步骤5 |
| 质量或流程角色 | 统计漏检率、误报率和评审耗时，维护提示词与维度规则，组织定期校准 | 评审指标报表、规则迭代记录、归档检查结果 | 步骤3、6及后续校准 |
测试负责人是判定责任的落点。AI可以生成问题清单，但不能替代“这条用例能否通过评审”的决定。负责人需要在判定时区分三类情况：问题成立且需修改、问题不成立需驳回、问题指向需求本身需澄清。三类结论对应不同的后续动作，混在一起会导致修改责任不清。
用例作者承担材料准备和修复两项工作。材料准备不足会让AI问题清单偏离重点，修复不及时则会让评审结论停留在记录层面。建议在迭代计划中为用例修改预留时间，并把“采纳问题是否全部关闭”作为用例完成的条件之一。
产品与开发角色的参与集中在澄清环节。AI提出的覆盖缺口有时反映的是需求描述不完整，而不是用例写漏了；技术边界类问题则需要开发确认实际约束。让这两个角色在澄清任务中被明确点名，可以避免问题在测试团队内部反复流转。
质量或流程角色负责让评审机制持续可用。其交付物包括每轮评审的指标统计、提示词和维度规则的变更记录、归档完整性检查结果。这个角色不需要参与每条用例的判定，但需要保证判定过程有记录、可抽样、可比较。
一个完整的AI用例评审示例
以下为演示情景，用于说明问题清单如何被判定和回写，不代表真实项目数据。
示例用例原文：标题为“优惠券叠加使用校验”，前置条件写“用户已登录”，步骤为“1. 进入结算页；2. 选择两张优惠券；3. 提交订单”，预期结果为“系统提示不能叠加使用”。输入材料包括需求描述“同一订单最多使用一张优惠券，不可叠加”、设计说明中关于优惠券互斥规则的段落，以及历史缺陷记录中一条“叠加校验在部分品类商品上未生效”的问题。
AI按五个维度给出的问题条目示例：覆盖度方面，指出需求中的“同一订单最多一张”未覆盖跨品类商品组合场景；可执行性方面，指出步骤未说明如何获取两张可用优惠券；前置条件方面，指出未说明用户账号的优惠券持有状态；预期结果方面，指出“提示不能叠加使用”未说明提示位置和文案，无法比对；数据边界方面，指出未覆盖一张已过期、一张有效的组合。
| 问题条目 | 人工判定 | 判定理由 | 后续动作 |
|---|---|---|---|
| 未覆盖跨品类商品组合 | 采纳 | 历史缺陷正出现在品类组合场景，属于真实遗漏 | 新增一条用例，覆盖不同品类商品各一件 |
| 步骤未说明如何获取两张可用优惠券 | 采纳 | 缺少数据准备步骤，用例无法独立执行 | 补充领券路径和账号准备说明 |
| 未说明优惠券持有状态 | 采纳 | 前置条件不完整 | 前置条件补充“账号已领取两张未使用优惠券” |
| 预期结果未说明提示位置和文案 | 待澄清 | 提示文案由产品确定，当前需求未写明 | 转产品澄清任务，确认后回填预期结果 |
| 未覆盖过期券与有效券组合 | 驳回 | 过期券在选券环节已被过滤，不属于本用例校验范围 | 记录驳回理由，作为提示词优化参考 |
修改后的用例补充了前置条件中的券状态、步骤中的数据准备路径，并新增跨品类组合用例；待澄清项转为产品任务，确认提示文案后回填；驳回项在评审记录中保留理由。确认的覆盖缺口同时登记为用例缺陷，关联原用例和对应需求条目，便于后续统计该类问题的出现频率。
这个示例可迁移的规律有三点：AI问题清单要落到具体字段才有判定价值；判定结论必须区分采纳、驳回和待澄清，三类走向不同；驳回理由和待澄清结论都应回流到规则或需求文档，而不是停留在本次评审中。
评审质量校准与完成检查
判断一次AI用例评审是否做到位，可以看三件事：问题是否都被判定、修改是否落到用例版本、记录是否可追溯。以下检查项建议在每轮评审结束时逐条核对。
| 检查项 | 核验方式 | 通过标准 |
|---|---|---|
| 评审范围与准入条件已确认 | 对照迭代用例清单 | 纳入和排除的用例均有说明 |
| 输入材料完整且版本对应 | 抽查用例与需求条目映射 | 每条用例可追溯到需求版本 |
| AI问题清单全部有判定 | 统计问题条目与判定记录数量 | 无未判定条目 |
| 采纳项已修改并复核 | 对比修改前后用例版本 | 采纳问题全部关闭，修改经负责人确认 |
| 待澄清项已转任务并指定负责人 | 查看澄清任务列表 | 每项有负责人和期望完成时间 |
| 评审记录已归档 | 检索归档目录 | 包含问题清单、判定结论、修改对比 |
漏检和误报需要通过抽样复核来度量。建议每轮随机抽取一定比例的已判定用例，由未参与本轮评审的测试人员按同一维度重新检查，统计AI未发现但人工发现的问题（漏检）和AI提出但被驳回的问题（误报）。抽样比例可根据迭代规模和风险等级调整，高影响场景用例应全部纳入复核。指标按模块和维度分别统计，才能看出问题集中在覆盖度还是可执行性。
规则与提示词的迭代节奏建议跟随迭代周期，而不是每次评审后立即修改。每个迭代收集驳回理由和漏检案例，归类后集中调整维度说明或提示词，并记录变更内容和生效版本。调整后对比前后两轮的误报率和漏检率，确认改动有效再固化。频繁改动会让不同批次结果失去可比性。
评审记录归档应包含评审时间、参与角色、输入材料版本、AI问题清单原文、判定结论与理由、修改前后用例对比、关联缺陷和澄清任务编号。归档位置要统一，便于后续审计和新人学习。ONES的AI能力基于ONES权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，评审结论和修改记录可以在同一工作项体系内留存，减少跨工具整理归档的工作。
有两类情况应作为阻断项处理：一是AI问题清单未经人工判定就直接作为评审通过结论，这会让错误进入测试执行阶段；二是评审过程没有留痕，导致后续无法追溯判定依据和修改原因。出现任一情况，本轮评审应退回重做，并在流程记录中注明原因。
常见问题
AI测试用例评审能直接替代人工评审吗？
不能。AI负责按固定维度生成问题清单，但“这条用例能否通过评审”需要由测试负责人逐条判定。AI输出未经人工判定就直接作为通过结论，属于应退回重做的阻断项。人工判定的价值在于区分问题成立、问题不成立和问题指向需求本身三种情况，并决定后续修改、驳回或澄清动作。
需求还没定稿的用例要不要先送AI评审？
建议先完成需求澄清再进入AI评审。需求描述不完整时，AI容易把需求本身的不确定当成用例问题，产生大量无效条目，增加判定负担。可以把这类用例标记为待澄清，等需求条目明确后再纳入下一轮评审范围。
评审维度固定后，不同模块的用例能共用同一套提示词吗？
可以共用基础维度，但需要按模块特点补充判定标准。覆盖度、可执行性、前置条件、预期结果、数据边界五个维度适用于多数功能用例；涉及并发、权限、资金等场景时，应在维度说明中增加对应的边界条件描述。提示词调整后要记录版本，并对比调整前后的误报率和漏检率，确认有效再固化。
评审记录归档具体要保留哪些内容？
归档内容建议包括评审时间、参与角色、输入材料版本、AI问题清单原文、每条问题的判定结论与理由、修改前后用例对比、关联的缺陷和澄清任务编号。归档位置要统一，便于后续审计和新人学习。在ONES中，评审结论可以作为工作项更新和评论留存，ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，把自然语言指令转化为创建缺陷、更新状态、通知负责人等操作，减少跨工具整理归档的工作。
抽样复核的样本量怎么定？
抽样比例可根据迭代规模和风险等级调整，高影响场景用例应全部纳入复核。复核由未参与本轮评审的测试人员按同一维度重新检查，分别统计AI未发现但人工发现的问题（漏检）和AI提出但被驳回的问题（误报）。指标按模块和维度分开统计，才能看出问题集中在覆盖度还是可执行性。
