制定AI用例审核规则，核心是把“AI草拟的测试用例能否进入用例库”拆成可逐项判定的检查项：先界定适用范围并按风险分级，再为覆盖追溯、步骤可执行性、预期结果、数据与前置条件、异常场景、AI生成标注设定通过标准，接着明确提交人、评审人与测试负责人的交接节点，最后用驳回统计和漏测回溯校准规则。规则以清单形式嵌入评审环节，配套角色职责与验收条件，才能稳定执行。
要点总览（TL;DR）
- 先界定AI参与用例生产的三类情形（全新生成、改写补全、批量扩充），再按风险与业务重要性分级，用级别决定全量审核还是抽检。
- 审核检查项固定为六个维度：需求覆盖与追溯、步骤可执行性、预期结果可验证、测试数据与前置条件、边界与异常场景、AI生成标注与来源记录，每项给出通过、驳回、待补充三种判定口径。
- 角色按用例作者、评审人、测试负责人划分，流程走提交—初审—复核—入库四个节点，驳回后只复核原驳回项，避免整篇重审。
- 规则上线后按月统计驳回原因、回溯漏测用例，据此修订检查项与抽检比例，并维护规则版本与修订记录。
- 发布前用验收清单确认判定口径、角色到人、审核记录可检索、试点范围与观察周期已确定。
先划范围：哪些AI生成用例要纳入审核
审核规则的第一步是确定对象边界。AI参与用例生产的形态不同，审核强度也应不同。建议在规则开篇列明纳入范围，避免执行时对“这条算不算AI生成”产生争议。
纳入审核的典型情形包括三类：一是全新生成，即由AI根据需求文档、验收标准或用户故事直接产出用例；二是改写补全，即人工已有草稿，由AI补充步骤、数据或异常分支；三是批量扩充，即按模块或场景批量生成用例集。三类情形都应进入审核，但批量扩充需要额外检查重复率与场景同质化问题。
规则还需写明不纳入本文的对象：测试执行脚本的编写与维护、模型训练与调优、常规自动化测试框架与流水线管理。这些工作有各自的质量控制方式，混入用例审核规则会让检查项失焦。
在范围明确后，按风险与业务重要性对用例分级，用级别决定审核强度。分级条件应可判定，例如是否涉及资金交易、权限控制、核心链路或对外接口。
| 级别 | 判定条件（示例） | 审核强度 |
|---|---|---|
| 高 | 涉及资金、权限、核心交易链路、对外承诺功能 | 全量审核，评审人逐条确认，测试负责人复核 |
| 中 | 一般业务功能、内部管理模块、非关键路径 | 全量初审，按比例抽检复核 |
| 低 | 展示类、文案类、低频辅助功能 | 初审通过即可入库，按周抽检 |
分级表应作为规则附件固定下来，新增模块时由测试负责人补充判定条件，避免每次评审临时讨论级别。
审核检查项怎么定：六个必查维度与通过标准
检查项的质量决定规则能否执行。每个维度都要给出通过、驳回、待补充三种判定口径，并配一条正例和一条反例，让评审人不必凭经验发挥。以下六个维度可作为基础清单，团队可按业务补充，但不宜随意删减。
需求覆盖与追溯
通过标准：每条用例能对应到具体需求条目、验收点或缺陷单号，来源字段填写完整。驳回标准：无法回溯来源，或覆盖的是需求中不存在的功能。待补充：来源存在但表述模糊，需提交人补充需求编号与对应段落。
步骤可执行性
通过标准：操作步骤写明角色、入口、操作动作和输入值，另一名测试人员按步骤可独立执行。驳回标准：出现“进行相关操作”“验证功能正常”等无法定位动作的表述。待补充：步骤基本可执行，但缺少登录角色或测试环境说明。
预期结果可验证
通过标准：结果可观察、可判定，例如页面提示文案、状态变化、数据值、接口返回码。驳回标准：预期结果为“符合预期”“显示正确”等无法判定的描述。待补充：结果方向正确但缺少具体判定值。
测试数据与前置条件
通过标准：列出执行所需的账号、数据状态、环境配置和依赖服务。驳回标准：前置条件缺失导致用例无法执行。待补充：数据可构造但未写明构造方式。
边界与异常场景
通过标准：对涉及输入范围、状态转换、并发或异常中断的功能，至少覆盖一个边界值和一个异常分支。驳回标准：仅覆盖正常路径且需求明确要求异常处理。待补充：异常场景方向合理但缺少具体触发条件。
AI生成标注与来源记录
通过标准：用例中标注生成方式（全新生成、改写补全、批量扩充）、使用的需求来源和生成时间，提交人对内容负责。驳回标准：未标注且无法判断是否由AI参与。待补充：标注了生成方式但来源记录不完整。
| 检查维度 | 通过要点 | 常见驳回原因 |
|---|---|---|
| 需求覆盖与追溯 | 来源字段完整、可回溯 | 无需求编号、覆盖不存在功能 |
| 步骤可执行性 | 角色、入口、输入值齐全 | 步骤笼统、无法独立执行 |
| 预期结果 | 可观察、可判定 | “显示正确”类模糊表述 |
| 数据与前置条件 | 账号、数据、环境明确 | 缺前置条件导致无法执行 |
| 边界与异常 | 至少一个边界值和一个异常分支 | 只覆盖正常路径 |
| AI标注与来源 | 生成方式、来源、时间齐全 | 未标注生成痕迹 |
检查项清单建议做成评审时的勾选表，每项记录判定结果和备注。判定为驳回或待补充时，必须写明具体原因，这些原因后续会成为校准规则的原始数据。
角色分工与评审流程：谁审、审到哪一步
规则要落到人。建议设置三类角色：用例作者（AI草拟后的提交人）、评审人、测试负责人。作者对提交内容的准确性和标注完整性负责；评审人按检查项逐条判定；测试负责人负责分级确认、抽检安排和争议裁决。
流程按“提交—初审—复核—入库”四个节点流转，每个节点有明确的交接物和状态。
| 节点 | 责任人 | 动作与交接物 | 状态 |
|---|---|---|---|
| 提交 | 用例作者 | 提交用例及来源、生成标注，填写分级建议 | 待初审 |
| 初审 | 评审人 | 按六项检查清单逐条判定，记录驳回原因 | 初审通过 / 待补充 / 驳回 |
| 复核 | 测试负责人或指定复核人 | 高风险用例全量复核，中低风险按比例抽检 | 复核通过 / 退回修改 |
| 入库 | 用例作者 | 确认修改完成，用例进入用例库并保留审核记录 | 已入库 |
抽检比例与全量审核的适用条件要写进规则：高风险用例全量审核；中风险用例初审全量、复核抽检，比例可按团队实际设定并在规则中写明；低风险用例初审通过即可入库，按周抽检。比例调整属于规则修订，需记录版本。
驳回后的路径同样要明确：作者根据驳回原因修改，重新提交后进入初审，评审人重点核对原驳回项，避免整篇重审造成重复劳动。同一用例连续两次因同一原因被驳回时，应升级到测试负责人判断是规则表述不清还是作者理解偏差。
审核记录、用例状态和规则版本需要有承载位置。ONES 的 AI 能力基于其权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，并将执行结果保存为工作项或 Wiki 页面。对于需要把审核判定、驳回原因和状态流转留痕的团队，可以在实际版本中核验用例字段与评审流程的配置方式，把检查清单对应到评审记录上。
示例：一条AI草拟用例的审核判定过程
以下为演示情景，用于说明检查项如何逐条使用，不代表真实项目数据。
原始用例由AI根据需求“优惠券领取后7天内未使用自动失效”生成，内容为：用户登录后进入优惠券页面，点击领取，验证优惠券状态正确；等待过期后查看优惠券，确认已失效。
逐项检查记录如下：需求覆盖与追溯——来源填写了需求编号，通过；步骤可执行性——未写明测试账号、领取入口和过期时间的构造方式，判定待补充；预期结果可验证——“状态正确”“已失效”缺少具体状态值和页面提示，判定待补充；测试数据与前置条件——缺少可调整有效期的测试环境说明，待补充；边界与异常——未覆盖第7天临界时刻和已使用优惠券不失效的场景，驳回；AI标注与来源——标注了“全新生成”和生成时间，通过。
最终结论为驳回并补充。修改要求：补充测试账号与过期时间构造方式；把预期结果改为具体状态值和提示文案；增加临界时间点用例和已使用优惠券的对照用例。修改后重新提交，评审人只需核对上述驳回项即可完成复审。
这个例子体现的判定规律是：来源与标注类问题通常可直接判定，步骤、数据和预期结果类问题多为待补充，场景缺失类问题按需求要求判定驳回。评审人按同一口径处理，可以减少同类用例的判定分歧。
规则上线后的校准：驳回统计与漏测回溯
规则上线后需要用运行数据检验其有效性。建议按月统计驳回原因，按六个检查维度归类，识别高频问题类型。如果某一维度持续占驳回总量的大头，先判断是AI生成内容的普遍弱点，还是检查项表述不够具体，再决定补充示例还是调整判定口径。
漏测回溯是另一条校准线索。当线上或验收阶段发现漏测时，回溯该场景是否曾有用例、是否在审核中被驳回或未被生成。若属于检查项缺失，补充维度或判定条件；若属于执行不到位，检查评审记录是否流于形式，必要时提高该级别用例的审核强度。
规则本身要版本化管理。每次修订记录修订日期、修订内容、触发原因和生效范围，旧版本保留可查。抽检比例与审核强度的调整应设定触发条件，例如连续两个统计周期某类驳回集中出现、发生一次与审核环节相关的漏测、或团队引入新的AI生成方式。触发后由测试负责人发起修订，评审人参与确认。
| 校准信号 | 判断方向 | 处理动作 |
|---|---|---|
| 某维度驳回占比持续偏高 | 检查项口径不清或AI生成薄弱环节 | 补充示例或细化判定标准 |
| 出现漏测且回溯到审核环节 | 检查项缺失或执行不到位 | 补充维度或提高审核强度 |
| 抽检发现驳回率异常升高 | 生成质量下降或提交前自检不足 | 加强提交前自检，调整抽检比例 |
| 引入新的AI生成方式 | 现有范围未覆盖 | 修订适用范围与标注要求 |
完成检查：规则可用的验收清单
规则发布前，用以下清单逐项确认，全部满足才具备执行条件。
- 适用范围说明已写明三类AI参与情形，并列出不纳入的对象。
- 用例分级表包含级别、判定条件和对应审核强度，新增模块有补充路径。
- 六个检查维度均有通过、驳回、待补充三种判定口径，并各配至少一条示例。
- 角色职责表已确认到具体岗位或人员，提交、初审、复核、入库四个节点的交接物明确。
- 抽检比例与全量审核的适用条件已写入规则，驳回后的修改与再提交路径清晰。
- 审核记录可留存、可检索，能按驳回原因和检查维度统计。
- 规则版本号与修订记录机制已建立，校准触发条件已约定。
- 试点范围与观察周期已确定，试点结束后有明确的复盘安排。
清单中的每一项都对应一个可核验的产物：范围说明、分级表、检查项清单、角色职责表、审核记录模板和修订记录表。规则以这些产物为载体进入评审环节，后续的驳回统计和漏测回溯才有稳定的数据来源。
常见问题
团队刚开始用AI草拟用例，审核规则可以先简化到什么程度？
可以先保留六个检查维度，但把判定口径压缩为“通过/驳回”两档，暂不设待补充状态，减少评审人的判断负担。分级表也可以先只分高风险与一般两档，高风险全量审核，其余按周抽检。
简化的是判定档位和分级粒度，检查维度本身不建议删减，尤其是需求追溯和AI生成标注两项，它们决定了后续驳回统计能否按维度归类。运行一个统计周期后，再根据驳回分布决定是否恢复三档判定和更细的分级。
AI生成的用例被驳回后，应该由谁修改，能否让AI直接重写？
修改责任在提交人，也就是把AI草拟内容提交评审的用例作者。可以让AI根据驳回原因重新生成或补全步骤、数据和预期结果，但重新提交前必须由提交人逐条核对驳回项是否真正解决，并在审核记录中注明修改方式。
如果同一用例连续两次因同一原因被驳回，建议升级到测试负责人，判断是检查项表述不清还是提交人对标准的理解有偏差，再决定修订规则还是补充说明。让AI直接重写并自动入库会绕过审核环节，不符合规则留痕的要求。
抽检比例定多少合适，什么情况下需要改成全量审核？
抽检比例没有统一数值，取决于团队对漏测的容忍度和AI生成内容的稳定程度。常见做法是高风险用例全量审核，中风险用例初审全量、复核抽检，低风险用例初审通过即可入库并按周抽检，具体比例写进规则并在修订时记录。
出现以下情况时建议提高审核强度甚至改为全量：发生一次可回溯到审核环节的漏测；某类驳回原因连续两个统计周期集中出现；团队引入新的AI生成方式或更换需求来源。调整由测试负责人发起，评审人参与确认后生效。
审核记录需要保留哪些内容，才能支撑后续的驳回统计和漏测回溯？
每条用例的审核记录至少包含：提交时间与提交人、分级结果、六个检查维度各自的判定结果与备注、驳回或待补充的具体原因、复核人与复核结论、最终状态和入库时间。驳回原因要按检查维度归类，而不是只写一句自由文本，否则后续统计无法聚合。
漏测回溯时，需要能按需求编号或场景反查该场景是否曾有用例、是否在审核中被驳回。因此审核记录与用例、需求之间的关联字段要完整。ONES 的 AI 能力基于其权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，审核记录与状态流转的承载方式可在实际版本中核验配置。
规则运行一段时间后，怎么判断是检查项有问题还是评审执行不到位？
看两个信号。一是驳回原因的分布：如果某维度驳回占比持续偏高，且驳回备注具体、指向明确，更可能是AI生成内容的普遍薄弱环节，可通过补充示例或细化判定标准解决；如果驳回备注笼统、同类问题反复出现却描述不一，更可能是检查项表述不清。
二是漏测回溯：漏测场景曾有用例但在审核中被驳回，说明判定口径过严或评审人理解有偏差；漏测场景从未生成用例，说明检查项或生成范围存在缺失。两类信号指向不同处理动作，修订时记录触发原因，便于下一周期对比效果。
