AI用例审核规则示例，是把“什么样的AI生成用例可以通过”写成一张可逐条判定的规则表：每条规则明确检查对象、判定条件、结论档位和证据要求，再用一条完整用例走一遍判定过程。下面给出一份可直接参照填写的规则表，并说明每条规则的设计依据、迁移到其他模块时的改造方法，以及这份示例在哪些条件下需要调整。文中用例与判定记录均为演示情景，不代表真实客户案例或实测效果。
要点总览（TL;DR）
- 规则表用六个固定字段承载每条规则：规则编号、检查对象、判定条件、结论档位、证据要求、责任人，结论统一为通过、退回修改、转人工复核三档。
- 示例覆盖需求覆盖、步骤可执行、预期可验证、数据与前置条件、风险与合规五类规则，并用一条密码修改用例演示逐条判定，最终结论为退回修改。
- 判定条件要写成可观察的事实，证据要求主要服务于退回和转复核环节，规则重叠时约定判定优先级，条目过多时按风险取舍。
- 迁移到其他模块时保留字段结构、三档结论和责任人分工，替换检查对象、判定阈值和风险条目，并记录规则版本与变更说明。
- 示例为演示情景，强监管场景、AI批量生成用例和长期未更新的规则表都需要补充专门规则或抽样复核。
示例目标：这份规则表要解决什么判定问题
这份示例要回答一个具体问题：一条由AI生成的测试用例，能否从“待评审”进入“评审通过”状态。规则表把评审人凭经验做出的判断，拆成若干条可逐项检查的条目，让不同评审人对同一条用例能得出相近结论，也让编写人知道退回后该改哪里。
规则表服务三类角色。测试负责人维护规则条目和阈值，决定规则在哪个评审节点生效；用例评审人按规则逐条判定并填写证据；用例编写人（包括使用AI生成初稿的人）根据退回意见修改后提交复判。三类角色对应规则表中的“责任人”字段，避免出现规则写了却无人执行的情况。
规则表在流程中的位置是“用例进入正式评审之后、进入测试执行之前”。它检查的是用例文本本身：需求是否覆盖、步骤能否执行、预期能否验证、数据与前置条件是否交代清楚、风险与合规是否处理。测试执行脚本的编写、自动化脚本的调试、模型训练与提示词调优，都不在这份规则表的判定范围内；这些工作发生在用例通过之后，或属于AI工具侧的优化，规则表不对其做结论。
需要说明的是，以下规则条目、阈值和判定记录均为演示情景，用于展示规则表的结构和填写方式，不构成行业标准，也不含真实客户数据。
完整示例：一份AI用例审核规则表与一条用例的判定过程
先看规则表的字段结构。每条规则占一行，六个字段固定：规则编号、检查对象、判定条件、结论档位、证据要求、责任人。结论档位统一为三档：通过、退回修改、转人工复核。判定条件尽量写成可观察的事实，例如“预期结果包含具体数值或状态描述”，而不是“预期结果写得清楚”。
| 规则编号 | 检查对象 | 判定条件 | 结论档位 | 证据要求 | 责任人 |
|---|---|---|---|---|---|
| R1 需求覆盖 | 用例与需求条目的对应关系 | 用例标题或备注中标注了所覆盖的需求编号；该需求的主要功能点至少被一条用例覆盖 | 有对应且覆盖主要功能点→通过；无对应→退回；需求本身描述不清→转人工复核 | 需求编号、需求条目截图或链接 | 用例评审人 |
| R2 步骤可执行 | 操作步骤 | 每一步包含动作对象和操作方式；步骤之间无跳步；不出现“进行相关操作”这类无法执行的表述 | 全部步骤可执行→通过；存在跳步或模糊步骤→退回 | 步骤原文摘录，标注问题步骤序号 | 用例评审人 |
| R3 预期可验证 | 预期结果 | 每条预期结果包含可观察的数值、状态、提示文案或界面变化；能与步骤一一对应 | 可逐条验证→通过；预期缺失或只有“正常”“成功”等笼统描述→退回 | 预期结果原文，标注不可验证的条目 | 用例评审人 |
| R4 数据与前置条件 | 测试数据、账号、环境 | 用例写明所需数据形态、账号权限和环境要求；数据涉及个人信息时说明脱敏方式 | 交代完整→通过；缺失关键前置条件→退回；涉及敏感数据但无脱敏说明→转人工复核 | 前置条件段落、数据说明 | 用例编写人提供，评审人核对 |
| R5 风险与合规 | 涉及资金、权限、隐私、对外接口的用例 | 高风险操作有异常分支和回退步骤；涉及权限的用例区分不同角色；涉及隐私的数据有使用范围说明 | 风险分支齐全→通过；缺少异常分支→退回；合规判断超出评审人职责→转人工复核 | 异常分支步骤、角色清单、数据使用说明 | 测试负责人复核 |
下面用一条演示用例走一遍判定。用例原文摘要：“验证用户修改登录密码后，旧密码失效。前置条件：已注册账号。步骤：1. 登录；2. 进入安全设置；3. 输入新密码并保存；4. 退出后使用旧密码登录。预期：旧密码登录失败。”
| 规则 | 判定结果 | 依据 |
|---|---|---|
| R1 需求覆盖 | 通过 | 用例备注标注了需求编号“账号安全-密码修改”，该需求的主要功能点已被覆盖 |
| R2 步骤可执行 | 退回修改 | 步骤3“输入新密码并保存”未说明新密码需满足的复杂度要求，执行人无法判断输入什么值；步骤2未说明从哪个入口进入安全设置 |
| R3 预期可验证 | 退回修改 | “旧密码登录失败”未写明失败的具体表现，是提示文案、错误码还是停留在登录页 |
| R4 数据与前置条件 | 退回修改 | 前置条件只写“已注册账号”，未说明账号的密码状态、是否需要绑定手机号；未说明测试环境 |
| R5 风险与合规 | 转人工复核 | 密码属于敏感信息，用例未说明测试过程中新密码的记录与清理方式，需测试负责人确认 |
最终结论：退回修改。退回意见可以这样写：“R2：请补充步骤2的入口路径，并在步骤3注明新密码需满足的复杂度规则及示例值；R3：请把预期改为具体提示文案或页面状态；R4：请补充账号初始状态和测试环境；R5：请说明测试密码的记录与清理方式，提交后由测试负责人复核。”编写人按意见修改后重新提交，评审人只需复判被退回的条目，已通过的R1不重复判定。
规则表落地时需要承载“待评审、退回、复判”这些状态和退回意见。ONES 的用例管理与评审能力可以把规则条目作为评审检查项，把退回意见记录在用例上，复判时保留历史记录，便于测试负责人查看某条规则反复被退回的情况。
逐项解释：每条规则为什么这样写
判定条件写成可观察事实，是整张规则表能否复用的关键。“预期结果包含具体数值、状态或提示文案”这类表述，两个评审人看同一条用例会得出相同结论；“预期结果清晰完整”则依赖个人经验，换一个人就可能判得不一样。规则表的价值在于把判断依据外化，让结论可以被第三人复核。
三档结论的划分依据是处理路径不同。通过表示无需改动，进入下一环节；退回修改表示问题在编写人职责范围内，改完复判即可；转人工复核表示问题超出评审人的判断权限，例如合规判断、需求本身有歧义、涉及敏感数据处理方式。升级条件要写清楚，否则评审人容易把该复核的条目直接退回，或把该退回的条目推给负责人。
证据要求的作用是让判定可追溯。截图、需求条目编号、数据说明这些材料，一方面让编写人明白问题出在哪，另一方面在复判或争议时提供依据。证据要求不宜过重，要求每条规则都附截图会让评审成本过高；通常只在退回和转复核时要求补充证据。
规则之间会有重叠。例如R2步骤可执行和R3预期可验证都可能涉及“步骤与预期不对应”。处理方式是约定优先级：先判R2，步骤本身不可执行时，预期是否可验证暂不判定，避免同一条用例被重复退回多次。规则条目过多时，按风险取舍：涉及资金、权限、隐私的规则保留，纯格式类要求可以合并为一条，或放到用例模板里约束，不占用评审规则的名额。
可迁移规律：换一个业务模块怎么改这份示例
迁移时保留骨架，替换内容。骨架包括六个字段的结构、三档结论、证据要求和责任人分工，这部分在不同模块之间基本不变。需要替换的是检查对象、判定阈值和风险条目：支付模块的R4要写明金额边界和账户状态，内容模块的R5要写明审核口径和敏感词处理，接口模块的R2要写明请求参数和返回码。
按业务风险调整规则权重，是迁移中最需要判断的部分。高风险模块可以把某条规则设为“一票退回”，例如涉及资金变动的用例缺少异常分支时直接退回，不进入后续条目判定；低风险模块可以合并条目、放宽证据要求，把评审重点放在需求覆盖上。权重调整应记录在规则表的版本说明里，说明调整原因和生效范围。
规则需要版本管理。建议在规则表头部记录版本号、生效日期、修改人和修改说明；每次调整保留旧版本，便于回溯某条用例当时按哪版规则判定。规则变更后，已通过的历史用例不强制重判，但新提交的用例按新版本执行。
- 保留：六字段结构、三档结论、证据要求、责任人分工
- 替换：检查对象的具体描述、判定阈值、风险条目清单
- 调整：高风险规则是否设为一票退回、证据要求的轻重
- 记录：版本号、生效日期、修改说明、历史版本留存
适用边界：示例不能直接照搬的情形
这份示例是演示情景，不含真实客户数据，也没有经过实际项目验证的量化效果。直接照搬条目和阈值之前，需要确认它是否匹配你的业务风险等级和团队评审习惯。
强监管或安全关键场景需要补充专门规则。金融、医疗、涉及人身安全的系统，合规判断往往需要法务或安全团队参与，示例中的R5只提供了框架，具体条目应由相应专业角色补充，不能由测试评审人独自判定。
AI生成用例的质量波动较大时，规则表要配合抽样复核。规则能拦住明显缺项，但无法保证通过规则表的用例一定有效；对AI批量生成的用例，建议按比例抽样由资深测试人员复核，观察规则表的漏判情况，再决定是否补充条目。
规则表无法替代评审人的专业判断。它把常见检查点固化下来，降低遗漏，但需求理解、业务场景取舍仍依赖评审人的经验。规则长期不更新也会失效：业务变化后，旧的判定条件可能不再对应实际风险，建议按固定周期回顾规则表，结合退回记录调整条目。
常见问题
规则表里的判定条件和用例模板里的填写要求，应该怎么分工？
两者约束的对象不同。用例模板规定“必须填哪些字段”，例如前置条件、步骤、预期结果各写几段；规则表判断“填进去的内容是否达到通过标准”。纯格式类要求，比如标题命名规范、字段是否为空，适合放进模板或提交校验，不占用评审规则的名额。规则表集中处理需要人判断的条目，例如步骤是否可执行、预期是否可验证、风险分支是否齐全。这样评审人不必逐条核对格式，规则条目数量也能控制在可执行的范围内。
一条用例同时触发多条退回规则时，退回意见怎么写才便于复判？
建议按规则编号逐条列出问题，每条写清三件事：问题出在哪个步骤或字段、为什么不满足判定条件、改成什么样算通过。例如“R2：步骤3未注明新密码复杂度要求，请补充规则说明和示例值”。同一处内容被多条规则涉及的情况，按约定的优先级只判一次，避免编写人收到重复意见。复判时只核对被退回的条目，已通过的规则不重复判定，并在用例上保留上一轮意见，便于查看反复退回的条目。
AI批量生成的用例数量很大，逐条走规则表评审成本太高，有什么折中做法？
可以分层处理。先用可自动检查的条目做初筛，例如需求编号是否标注、必填字段是否为空、步骤是否包含无法执行的模糊表述，把明显不合格的用例直接退回，不进入人工评审。剩余用例按风险分层：涉及资金、权限、隐私的逐条评审，普通功能用例按比例抽样评审。抽样中发现的漏判类型，反过来补充到规则表或初筛条件里。需要提醒的是，规则表和初筛只能降低遗漏，通过检查的用例仍需评审人对业务场景做判断。
规则表应该由谁维护，多久回顾一次比较合适？
维护责任通常落在测试负责人身上，规则条目的增删和阈值调整由其确认，评审人负责执行并反馈判定中遇到的歧义。回顾周期可以跟业务节奏挂钩：需求结构或风险等级发生明显变化时及时调整，平稳阶段按固定周期回顾。回顾时重点看两类记录：反复被退回的规则条目，可能说明判定条件写得不够清楚；长期没有触发过的条目，可能已经不对应实际风险。每次调整记录版本号、生效日期和修改说明，历史版本留存备查。
涉及合规判断的用例，评审人应该判到什么程度？
评审人的职责是识别并升级，做出最终合规结论。示例中R5的处理方式是：评审人检查高风险操作是否有异常分支和回退步骤、权限用例是否区分角色、隐私数据是否有使用范围说明；一旦问题超出测试评审职责，例如数据处理方式是否合规、需求本身是否存在合规歧义，就转人工复核，由测试负责人协调法务或安全角色确认。规则表可以把“什么情况下必须转复核”写清楚，减少评审人自行判断的空间。
