AI生成或改写的测试用例，看起来格式完整，却可能在需求对应、前置条件和预期结果上留下不易察觉的缺口。本文给出一套可直接执行的审核规则：明确审核对象与边界，按五步流程完成从入库到判定，用分类检查项统一判定口径，落实角色分工，并通过试点指标验证规则是否有效。
要点总览（TL;DR）
- 规则对象限定为AI生成、改写或补全的测试用例，与常规用例共用评审流程，额外增加来源标注与覆盖假设核验。
- 审核按五步执行：入库与来源标注、准入字段自检、风险分级、人工复核判定、结论回写留痕，每步都有输入、输出和完成标志。
- 检查项分五类：需求覆盖、步骤可执行性、预期结果、数据与边界、重复与冲突，每类给出通过口径与常见驳回原因。
- 判定结论收敛为通过、修改后通过、驳回三档，高等级用例要求初审与终审分离，审核记录包含规则版本以便回溯。
- 规则先在单个团队或迭代试点两到三个周期，用驳回率、修改后通过率和上线后缺陷回流验证有效性，并设定迭代触发条件。
AI用例审核规则要解决什么问题
这套规则的对象是AI生成、AI改写或AI补全的测试用例，包括由AI从需求文档批量产出的新用例、对已有用例的补充与改写，以及根据缺陷记录反推的回归用例。规则要回答的是：这些用例在进入测试资产库之前，经过哪些检查、由谁判定、留下什么记录。测试执行脚本的编写与维护、模型训练与选型不在本规则范围内。
AI用例与人工编写的用例共用同一套评审流程，但需要额外关注三类风险。第一是来源可信度：用例由哪条需求、哪次对话或哪份文档生成，需要可追溯，否则后续无法判断覆盖是否完整。第二是覆盖假设：AI容易根据常见模式补全场景，可能把“通常如此”写成确定步骤，遗漏项目特有的业务约束。第三是可执行性：表述通顺不等于步骤可复现，前置条件缺失、测试数据未定义、预期结果模糊是用例被驳回的高频原因。
规则的目标可以归纳为三条：可追溯，每条AI用例能对应到明确的需求或缺陷来源；可判定，审核结论依据检查项得出，不同审核人面对同一用例能给出相近判断；可复用，检查项、判定口径和审核记录能够沉淀下来，供后续批次和新人使用。规则写成检查项和判定结论，避免停留在“加强审核”这类无法执行的要求上。
核心答案：一套可落地的审核流程与判定标准
审核流程按五个步骤组织，每一步都有明确的输入、动作、输出和完成标志。流程适用于单个迭代内的用例批次，也适用于跨团队的统一审核。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、用例入库与来源标注 | AI产出的用例文本、生成时使用的需求或缺陷编号 | 提交者将用例录入测试用例库，标注来源类型（生成/改写/补全）、来源需求或缺陷、生成批次 | 带来源标记的待审条目 | 每条用例都有来源标记，无来源的条目退回补充 |
| 二、准入字段自检 | 带来源标记的待审条目 | 提交者按准入字段逐项核对：需求关联、前置条件、操作步骤、预期结果、优先级 | 字段完整的待审清单 | 五个准入字段全部填写，缺项条目在提交前补齐 |
| 三、风险分级 | 字段完整的待审清单 | 按业务影响与改动范围划分复核深度：核心交易与安全相关为高，主要业务流程为中，展示与辅助功能为低 | 带风险等级的待审清单 | 每条用例标注风险等级，高等级用例进入全量复核 |
| 四、人工复核与判定 | 带风险等级的待审清单 | 审核人按检查项逐项核对，给出通过、修改后通过、驳回三档结论并写明理由 | 判定结论与审核意见 | 每条用例有结论、有理由、有审核人 |
| 五、结论回写与留痕 | 判定结论与审核意见 | 将结论回写到用例状态，记录审核时间、审核人、规则版本；驳回条目退回提交者修改后重新提交 | 可查询的审核记录 | 用例状态与审核记录一致，驳回条目有重新提交记录 |
风险分级决定复核深度，是控制审核成本的关键。高等级用例逐条全量复核，中等级用例按批次抽检并覆盖全部新增场景类型，低等级用例可采用批量复核加事后抽样的方式。分级标准由团队在规则中预先写定，避免审核人临场判断导致松紧不一。
三档结论的判定口径需要相邻说明：通过指检查项全部满足，可直接进入测试资产库；修改后通过指存在表述、数据或补充说明类问题，修改后无需再次完整复核，由提交者修改并经审核人确认即可；驳回指需求对应错误、步骤不可复现或预期结果无法判定，需重新生成或重写后走完整审核。结论回写时同步记录规则版本，便于后续分析某版本规则下的驳回分布。
审核检查项与判定口径
检查项按五类组织，每类给出通过口径和常见驳回原因。审核人逐项勾选，任一项不满足即不能判为通过。
| 检查类别 | 检查内容 | 通过口径 | 常见驳回原因 |
|---|---|---|---|
| 需求覆盖 | 用例是否对应明确的需求、用户故事或缺陷编号 | 能指出具体来源条目，且用例验证点与来源描述一致 | 来源缺失；用例验证的是来源中未提及的行为 |
| 步骤可执行性 | 前置条件、操作步骤是否可复现 | 具备权限与数据的测试人员按步骤操作能得到相同中间状态 | 前置条件缺失；步骤依赖未说明的环境或账号 |
| 预期结果 | 结果是否可观察、可判定 | 预期结果指向具体界面元素、数据值或状态变化，能明确判断通过与否 | 写成“正常显示”“符合预期”等无法判定的表述 |
| 数据与边界 | 是否覆盖异常输入、边界值和业务规则例外 | 正常场景之外，至少覆盖规则中列明的异常与边界类型 | 只覆盖主流程；边界值取自猜测而非需求定义 |
| 重复与冲突 | 是否与已有用例重复或结论矛盾 | 与已有用例的验证点不重复，或明确标注为补充与替代关系 | 与存量用例步骤高度重合；同一场景预期结果相互矛盾 |
需求覆盖检查是驳回率最高的一类，原因多集中在AI根据通用经验补充了来源中不存在的验证点。处理方式是要求提交者在来源标注中写明具体条目，审核人对照来源逐条确认，超出来源的验证点要么补充需求依据，要么移出本批用例。
数据与边界检查需要团队预先给出边界类型清单，例如金额上下限、字符长度、状态流转的非法跳转、并发与超时。清单之外的场景由审核人按业务影响判断是否要求补充。重复与冲突检查依赖用例库的检索能力，提交前先按需求编号和关键词检索存量用例，把重复条目合并或标注替代关系。
角色分工与交付物
审核规则需要四类角色，职责与交付物对应如下。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 用例提交者（AI产出责任人） | 发起AI生成或改写，完成来源标注与准入字段自检，按审核意见修改 | 带来源标记的待审条目、字段自检记录、修改后的用例 |
| 初审人 | 核对准入字段与来源标注，执行需求覆盖、重复与冲突检查 | 初审意见、退回补充清单 |
| 终审人 | 对高等级用例执行完整检查，给出三档判定结论 | 判定结论、审核理由、审核记录 |
| 规则维护者 | 维护检查项、判定口径与风险分级标准，组织规则版本更新 | 规则文档及版本记录、规则变更说明 |
初审与终审可以由同一人在低风险批次中兼任，高等级用例要求初审与终审分离，避免同一人既确认来源又给出最终结论。规则维护者通常由测试负责人或质量负责人承担，规则变更的触发条件包括：连续两个观察周期驳回率异常升高、上线后出现审核通过的用例未覆盖的缺陷、业务或系统架构发生较大调整。每次变更形成新版本，旧版本记录保留，便于回溯某批用例依据的是哪版规则。
当用例数量较大、状态流转和评审记录需要集中管理时，可以在 ONES 中承载相关管理动作。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并基于相关项目数据和团队知识回答问题、执行后续操作。用例的来源需求、审核状态与判定记录可以在同一套项目数据中关联，AI 能力的输出过程可追踪、结果可审计，便于规则维护者按批次统计驳回与修改情况。
示例：一条AI生成用例的审核过程
以下为演示情景，用于说明规则如何运行。某团队为“订单取消”需求生成回归用例，AI产出一条用例：验证已支付订单在发货前取消后，订单状态变为“已取消”，支付金额原路退回。
第一步入库标注。提交者标注来源为需求编号 REQ-218“订单取消规则”，来源类型为生成，生成批次为 2024-06 第 2 批。第二步准入字段自检。需求关联、前置条件（存在一笔已支付且未发货的订单）、操作步骤、预期结果、优先级均已填写，进入待审清单。第三步风险分级。订单与支付属于核心交易，定为高风险，进入全量复核。
第四步逐项核对。需求覆盖：REQ-218 明确写了发货前取消与退款规则，验证点与来源一致，通过。步骤可执行性：前置条件写明订单状态与支付渠道，步骤可复现，通过。预期结果：订单状态与退款均为可观察结果，通过。数据与边界：来源中列明“部分退款”和“优惠券分摊退款”两种例外，本条用例未覆盖，判为不满足。重复与冲突：检索存量用例，发现一条人工编写的取消用例仅覆盖未支付订单，本条为补充而非重复，通过。
第五步判定与回写。综合检查结果，判定为修改后通过：补充部分退款与优惠券分摊两个场景的步骤与预期结果，修改后由终审人确认，无需重新走完整审核。结论回写到用例状态，记录审核人、审核时间与规则版本，并在来源需求下关联该用例，便于后续缺陷回流时定位覆盖情况。
规则落地与完成检查
规则先在单个团队或单个迭代试点，观察周期建议覆盖两到三个完整迭代，确保包含需求变更和缺陷修复的完整循环。试点期间记录每条用例的审核结论、驳回原因分类和修改耗时，作为后续调整检查项和分级标准的依据。
有效性验证看三类指标。驳回率反映AI产出与规则要求的差距，按检查类别拆分可以看出问题集中在需求覆盖还是可执行性。修改后通过率反映表述与补充类问题的比例，比例过高说明准入字段自检没有起到过滤作用。上线后缺陷回流指审核通过的用例所覆盖的功能在线上出现缺陷，需要回查该用例是否遗漏了场景，这类回流是规则迭代最直接的输入。
规则迭代的触发条件建议写进规则文档：某类驳回原因连续两个周期占比超过设定阈值、出现审核通过但线上暴露的覆盖缺口、需求模板或系统架构调整导致检查项不再适用。每次迭代只调整触发问题对应的检查项或分级标准，保持规则版本可对比。
规则上线前用以下清单逐项核对：
- 审核对象与排除范围已写明，团队对哪些用例需要审核有统一理解。
- 五个准入字段已定义，提交前自检有记录可查。
- 风险分级标准已写定，高等级用例的全量复核要求明确。
- 五类检查项各有通过口径和常见驳回原因，审核人可逐项勾选。
- 三档判定结论的定义与后续处理方式已明确。
- 提交者、初审、终审、规则维护者的职责与交付物已落实到人。
- 审核记录包含结论、理由、审核人、时间与规则版本，可查询可回溯。
- 试点范围、观察周期与验证指标已确定，迭代触发条件已写入规则文档。
常见问题
AI生成的用例和人工编写的用例，审核流程需要分开吗？
可以共用同一套评审流程，但AI用例需要额外增加两个环节：来源标注和覆盖假设核验。来源标注要求写明用例由哪条需求、哪份文档或哪次生成批次产出，便于后续判断覆盖是否完整；覆盖假设核验针对AI容易按常见模式补全场景的特点，审核人需要对照来源确认验证点是否超出原始需求。人工用例通常不需要逐条标注生成来源，这是两者在流程上的主要差异。
低风险用例采用批量复核加事后抽样，抽样比例怎么定？
抽样比例属于团队管理决策，没有统一标准。建议先按批次确定一个初始比例，例如每批抽取一定数量的用例做完整检查，观察两个周期内抽样发现的问题类型和数量，再据此调整。如果抽样中反复出现同类问题，说明批量复核的过滤效果不足，应提高比例或收紧低风险的划分标准。抽样记录需要保留，作为调整依据。
审核通过的用例上线后仍然暴露缺陷，规则应该怎么改？
先回查该用例的审核记录，定位缺陷对应的是哪类检查项没有拦住：是需求覆盖遗漏了场景、边界清单缺少该类输入，还是预期结果写得过于笼统。定位后只调整对应的检查项或边界类型清单，形成新版本规则，旧版本记录保留。如果同类回流连续出现，说明问题不在单条用例，需要重新评估风险分级标准，把相关功能模块的复核深度提高。
用例数量大、审核记录分散时，用什么方式承载状态流转和留痕？
当用例数量较大、需要集中管理审核状态与记录时，可以在 ONES 中承载相关管理动作。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并基于相关项目数据和团队知识回答问题、执行后续操作。用例的来源需求、审核状态与判定记录可以在同一套项目数据中关联，AI 能力的输出过程可追踪、结果可审计，便于规则维护者按批次统计驳回与修改情况。
规则维护者的变更权限需要限制吗？
建议把规则变更做成有记录的动作：每次调整检查项、判定口径或分级标准都形成新版本，写明触发原因和影响范围，旧版本保留可查。变更权限集中在规则维护者手中，其他角色通过触发条件提出变更建议，例如连续两个周期某类驳回占比异常、出现审核通过但线上暴露的覆盖缺口。这样既能保证规则稳定，也能让一线审核人把发现的问题反馈进来。
