AI生成了100条测试用例，我是如何人工审核并筛出有效用例的

AI 可以提高候选用例的产出速度，但只有经过证据核对、机器 Check、人工裁决和回归回流，候选内容才会成为正式测试资产。

先说明：这不是把 100 条用例逐条贴出来

这次实验的输入是一份脱敏后的登录与会话需求，AI 一次生成了 100 条候选用例。本文不会假装在正文里逐条展示全部 100 条，而是提供三份可以复核的汇总账：模块分布、初始优先级分布、最终处置分布；再挑 10 条具有代表性的候选，逐条展示 Before、问题、After 和审核结论。

完整审核台账在真实团队中应保存在用例平台或版本库，至少包含 batch_id、case_id、prompt_version、model_version、requirement_version、reviewer、reviewed_at 和 disposition。文章里的数字来自同一批 batch-2026-08-login-01，三个分布表的总数都必须等于 100。

---

一、审核对象与规则基线

需求范围包括账号密码登录、图形验证码、连续失败锁定、找回密码、会话管理以及安全审计。审核前先冻结六类证据：

• 当前版本需求与产品确认记录。
• 接口契约中的状态码、业务码和字段枚举。
• 已评审的测试点清单与 rule_id。
• 允许复用的历史缺陷模式。
• 用例输出 Schema 与标题、步骤、预期规范。
• 本轮 Prompt、模型和生成参数版本。

如果数值、时限、状态或权限在权威证据里没有定义，审核人不能替业务补一个“合理值”，而应把它标为待确认。

100 条候选的模块分布

测试点桶	候选数	最低审核重点
LOGIN-01 账号密码	20	正常、错误、空值、枚举与错误提示
LOGIN-02 验证码	16	正确、错误、过期、刷新、一次性
LOGIN-03 失败锁定	18	阈值、时间窗、锁定、解锁、并发
LOGIN-04 找回密码	18	链接有效期、重复使用、账号探测
LOGIN-05 会话管理	20	刷新、超时、退出、跨端、Token 失效
LOGIN-06 安全与审计	8	越权、注入、日志脱敏与速率限制
合计	100	与 batch 候选总数一致

AI 初始优先级分布

优先级	候选数	占比	审核信号
P0	38	38%	明显偏高，AI 把大量表单校验误判为核心阻断
P1	44	44%	需要结合真实用户影响重新裁决
P2	18	18%	体验与低频兼容场景偏少
合计	100	100%	分布只用于告警，不机械凑比例

---

二、先建立互斥的最终处置账

每条候选只能有一个最终 disposition，避免同一条既算“重复删除”又算“虚构删除”，导致总数对不上。错误标签可以多选，但最终处置必须互斥。

最终处置	数量	是否进入正式库	审核含义
直接接受	25	是	业务正确、可执行、可追溯
修改后接受	35	是	主体方向正确，补证据或改写后通过
重复删除	18	否	与已有候选验证同一条件和结果
虚构删除	8	否	引入需求中不存在的功能、数值或状态
错误/不可执行删除	14	否	预期错误、步骤不可复现或没有观察结果
合计	100	60 条 AI 候选保留	25 + 35 + 18 + 8 + 14 = 100

人工随后补充 8 条 AI 漏掉的高风险场景，因此正式库最终为 68 条：60 条由候选接受或修改后接受，8 条由审核人新增。被删除的 40 条不进入正式库，但审核原因仍保存在台账中，供 Prompt 与规则回归使用。

---

三、错误分类体系：处置互斥，原因可以多标签

错误代码	类型	识别标准	主要处理
E01	需求外虚构	功能、页面、角色、字段或状态没有来源	删除并加入防编造评估集
E02	数值臆造	自行补出阈值、时限、次数或长度	改为待确认或删除断言
E03	重复/同义	条件、动作和可观察结果与另一条等价	保留证据更完整的一条
E04	不可执行	前置、步骤、数据或观察面缺失	补齐后重审，无法补齐则删除
E05	预期错误	与当前规则、接口契约或状态机冲突	删除或按证据重写
E06	优先级误判	复杂度被当成业务影响，或忽略资金/权限风险	人工重新定级
E07	追溯断裂	没有 rule_id，或 source_id 已过期	补来源后才能接受
E08	覆盖偏斜	同一测试点过度展开，关键分支却遗漏	合并并人工补高风险场景
E09	敏感/危险	使用真实隐私数据或建议生产副作用操作	立即退回，执行安全复盘

一个候选可以同时带 E04、E06 和 E07，但最终只能落在“修改后接受”或“错误/不可执行删除”中的一个。这样既保留原因细节，又保证 100 条账目能对齐。

---

四、10 条代表性样例逐条审核

下面 10 条不是“全部 100 条”的替代品，而是覆盖五种最终处置与主要错误类型的审计样本。

样例 01｜TC-006｜模糊标题与不可观察预期

Before： 验证用户登录功能正常。

问题： 没有账号状态、输入、操作和可观察结果，命中 E04；执行人无法判断“正常”指跳转、Token 还是用户信息。

After： 当正常账号提交正确密码时，接口返回成功业务码，页面进入个人中心并展示当前账号昵称。

结论： 修改后接受，P0，关联 LOGIN-01 与 RULE-AUTH-001。

样例 02｜TC-013｜数值有证据但步骤不完整

Before： 当用户多次输错密码时，系统锁定账号。

问题： 需求已定义“10 分钟内连续 5 次、锁定 30 分钟”，候选却没有阈值、时间窗、锁定后正确密码行为和审计日志，命中 E04、E07。

After： 当正常账号在 10 分钟内连续 5 次提交错误密码时，第 5 次提示账号锁定；锁定后提交正确密码仍被拒绝；30 分钟后可再次登录；审计日志记录锁定事件且不记录明文密码。

结论： 修改后接受，P0，关联 LOGIN-03 与 RULE-AUTH-017。

样例 03｜TC-021｜需求外指纹登录

Before： 当用户使用指纹时，应成功登录并进入首页。

问题： 当前产品没有生物识别能力，命中 E01；不能因为常见 App 有该功能就扩展需求。

After： 无。将“是否规划生物识别登录”作为产品建议单独记录，不生成测试断言。

结论： 虚构删除，不进入正式库，并加入 no-extra-feature 回归样本。

样例 04｜TC-028｜与另一候选同义重复

Before： 当密码框不填写时提示密码不能为空。

问题： 与 TC-027“密码为空时阻止提交并提示必填”条件、动作、结果相同，命中 E03；仅换词不构成新场景。

After： 合并到 TC-027，在其测试数据中保留空字符串与仅空格两个参数。

结论： 重复删除；TC-027 保留并从 P0 调整为 P1。

样例 05｜TC-034｜验证码过期场景可直接使用

Before： 当用户提交已过期验证码和正确账号密码时，登录被拒绝，页面提示验证码已失效，并允许刷新获取新验证码。

问题： rule_id、前置数据、动作与预期齐全；提示内容与接口契约一致，没有发现错误标签。

After： 不修改正文，仅补充 source_id 和测试数据生成器 ID。

结论： 直接接受，P1，关联 LOGIN-02 与 RULE-CAPTCHA-006。

样例 06｜TC-047｜自行臆造验证码有效期

Before： 当验证码生成超过 60 秒后提交时，系统提示验证码已过期。

问题： 当前需求只说明“按服务端配置过期”，没有 60 秒，命中 E02；具体数值看似合理但没有证据。

After： 当验证码超过当前环境配置的有效期后提交时，系统拒绝登录并返回 CAPTCHA_EXPIRED；测试运行时读取测试环境配置值，不在用例硬编码秒数。

结论： 修改后接受，P1；另建待确认项确认各环境是否应统一有效期。

样例 07｜TC-058｜错误地暴露账号是否存在

Before： 当找回密码输入未注册邮箱时，提示“该邮箱未注册”。

问题： 与安全规则“无论账号是否存在都返回统一提示”冲突，命中 E05；原预期会造成账号枚举风险。

After： 当找回密码提交未注册邮箱时，页面返回与已注册邮箱相同的通用提示，不泄露账号存在性，也不创建重置令牌。

结论： 修改后接受，P0，关联 LOGIN-04 与 RULE-RESET-009。

样例 08｜TC-071｜退出只看页面，没有验证 Token

Before： 当用户点击退出后，应跳转到登录页。

问题： 页面跳转不能证明服务端会话已失效，命中 E04、E08；历史上出现过旧 Token 仍可调用接口的缺陷。

After： 当已登录用户退出后，页面跳转登录页；使用退出前的访问 Token 调用个人资料接口返回未认证；浏览器返回受保护页面时不能恢复旧会话。

结论： 修改后接受，P0，关联 LOGIN-05 与历史缺陷 DEFECT-231。

样例 09｜TC-084｜把文案问题误标为 P0

Before： 当密码错误时提示文案末尾缺少句号，优先级 P0。

问题： 场景有效但不会阻断核心链路，也不涉及安全、资金或数据，命中 E06。

After： 当密码错误时，页面错误提示与设计规范一致且不暴露账号存在性。

结论： 修改后接受，优先级调整为 P2；安全提示内容仍单独由 P0/P1 场景覆盖。

样例 10｜TC-096｜建议直接使用生产账号验证锁定

Before： 使用线上真实 VIP 账号连续输入错误密码，验证生产锁定策略。

问题： 会影响真实用户并使用生产敏感身份，命中 E09；这不是测试步骤优化能解决的问题，而是执行边界错误。

After： 在隔离测试环境创建专用账号，通过受控数据工厂设置初始状态；测试后按 run_id 清理或归档，禁止访问生产凭据。

结论： 错误/不可执行删除；安全边界加入生成 Prompt、机器 Check 和评审清单。

---

五、机器 Check：只拦稳定规则，不替人判断业务

机器 Check 应在人工评审前运行，并在修改后再运行一次。每个 finding 都要包含 case_id、rule_id、severity、evidence 和 message，而不是只返回“失败”。

检查器	确定性规则	输出
Schema	必填字段、枚举、长度、未知字段	schema_errors
Traceability	rule_id/source_id 存在且版本有效	orphan_cases、stale_sources
Numeric evidence	用例中的阈值与时限可在证据中定位	unsupported_numbers
Duplicate	条件、动作、预期三元组相似度与规则 ID	duplicate_candidates，仅提示
Coverage	每条确定规则至少有候选；P0 规则有高优先级候选	uncovered_rules
Priority distribution	P0/P1/P2 异常偏斜	warning，不自动改级
Sensitive action	生产、真实账号、明文密钥、删除/支付动作	blocked_findings

最小检查结果模板：

{

"batch_id": "batch-2026-08-login-01",

"case_id": "TC-047",

"check_version": "case-check@1.4.0",

"status": "needs_review",

"findings": [

{

"code": "E02",

"field": "precondition",

"message": "数值 60 无当前需求证据",

"evidence_ids": []

}

]

}

相似度、优先级比例和覆盖率都是信号，不应直接删除、改级或宣称“质量 100%”。机器擅长保持一致，人工负责理解业务损失。

---

六、人工审核：按证据做四类裁决

审核人不需要重新写 100 条，而是集中处理机器无法裁决的内容：

• 业务正确性：预期是否符合当前规则、状态机与接口契约。
• 真实风险：失败是否影响资金、权限、隐私、核心数据或主链路。
• 可执行性：前置、数据、步骤和观察面是否可以复现。
• 覆盖完整性：角色、状态、边界、并发、跨端和历史高风险是否遗漏。

每条候选必须选择一个处置：直接接受、修改后接受、重复删除、虚构删除、错误/不可执行删除。待确认项不应混进正式断言；它需要 owner、due_date 和关闭证据。

单条审核记录模板

batch_id: batch-2026-08-login-01

case_id: TC-071

prompt_version: test-case-gen@2.3.0

requirement_version: auth-srs@5.1

machine_findings: [E04, E08]

disposition: accept_after_edit

before: 当用户点击退出后，应跳转到登录页

after: 退出后页面跳转且旧 Token 调用受保护接口返回未认证

evidence_ids: [RULE-SESSION-012, DEFECT-231]

reviewer: qa-reviewer-02

reviewed_at: 2026-08-09T15:30:00+08:00

---

七、从审核差异回流，而不是只改这一批文字

一次审核结束后，差异应进入三个不同的回流通道：

差异	回流位置	例子
稳定格式错误	机器 Check / Schema	缺 rule_id、非法优先级、空预期
反复出现的语义错误	Prompt 规则与 few-shot 反例	未定义数值、需求外功能、历史规则污染
新发现的业务风险	测试点库/风险库	退出后旧 Token 仍有效
需求本身不清楚	待确认清单	验证码有效期由配置还是统一常量决定
安全越界	工具权限与审核门	生产账号、真实隐私数据、外部副作用

回流顺序是：记录原始候选与证据 → 分类错误 → 修订规则/示例/检查器 → 冻结新版本 → 用原 100 条和独立保留集回归 → 指标无关键退化后发布。不要在原始候选上直接覆盖，否则无法证明新版本真的改好了。

---

八、用哪些指标判断流程真的提效

这批数据的首轮结果是：

指标	计算	本批结果
直接接受率	25 / 100	25%
AI 候选有效率	(25 + 35) / 100	60%
修改率	35 / 100	35%
拒绝率	(18 + 8 + 14) / 100	40%
虚构率	8 / 100	8%
人工补充率	8 / 68	11.8%
正式库规模	60 条候选保留 + 8 条人工新增	68 条

长期还要跟踪：关键规则召回率、重复率、每条有效用例的人工分钟数、机器 Check 拦截率、审核后一致率、用例发现有效缺陷的比例、Prompt/模型升级后的回归退化数。

不要只优化“直接接受率”。如果模型为了提高接受率而减少边界与安全场景，数字会变好，风险却会变大。核心门槛应是 P0 规则无遗漏、虚构受控、正式用例可执行且可追溯。

---

九、团队可以直接采用的双门禁流程

• 需求先拆成带 rule_id 的测试点与待确认项。
• 冻结需求、Prompt、模型、Schema 和生成批次版本。
• AI 只生成候选用例，不直接写入正式库。
• 机器 Check 格式、追溯、数值证据、重复、覆盖、敏感动作与分布。
• 测试工程师审核业务正确性、真实风险、可执行性与覆盖缺口。
• 修改后的候选再次运行相同版本的 Check。
• 审核通过的 60 条进入暂存区，人工补齐 8 条高风险遗漏。
• 对 68 条正式用例做规则覆盖与优先级复核后入库。
• 错误样本按 E01 至 E09 回流 Prompt、检查器、风险库和评估集。
• 新版本必须回放原批次与独立保留集，关键样本退化就回滚。

AI 负责扩大候选面，确定性脚本负责机械约束，测试工程师负责业务裁决。三者都有清晰边界，100 条候选才不会变成 100 段待清理的文字。

---

写在最后

这次审核最有价值的结果不是“最终留下 68 条”，而是建立了一条能复查的生产链：每条候选有来源，每个删除有原因，每次修改保留 Before/After，每个新规则都有回归样本，每次发布都能用指标比较。

当团队开始保存这些差异，AI 用例生成才从一次性对话变成可持续改进的测试资产系统。

下一篇：RAG 知识库测试实战教程

---

本文是“肖恩的博客”系列文章之一，记录 AI 在真实测试工作流中的落地实践。