AI生成测试用例要真正进入研发流程，关键在生成前后的三件事：把需求、验收标准和历史缺陷整理成可追溯的输入，让AI产出带来源标注的用例草案，再由测试负责人按风险分级评审，并把用例与缺陷记录关联起来。落地时建议先选一条业务线小范围试点，用覆盖率、评审通过率和缺陷回溯命中率验证效果，再逐步扩大。用例、需求与缺陷的关联和评审记录，可以放在ONES这类研发管理平台中承载。
要点总览（TL;DR）
- AI生成测试用例按五步执行：确定试点范围与用例粒度、整理需求与历史缺陷、设计提示词与生成约束、人工评审与风险分级、入库并与缺陷关联。
- 输入整理和缺陷关联是最容易被跳过的两步，前者决定生成结果是否贴合验收标准，后者决定用例库能否持续反映真实质量问题。
- 评审按需求风险分级：高风险需求逐条评审并补充边界用例，低风险需求抽检，评审意见记录在用例条目上。
- 用需求覆盖率、评审通过率、缺陷回溯命中率三项指标判断试点效果，连续两个迭代达标再扩大范围。
- 用例、需求、缺陷放在同一工作项体系中关联，评审状态与版本变更才有据可查，ONES 可承载这类关联与记录。
核心答案：AI生成测试用例的完整操作步骤
AI生成测试用例可以拆成五步执行。每一步都有明确的输入、动作、输出和完成标志，做完一步再进入下一步，避免生成结果无法评审、无法追溯。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：确定试点范围与用例粒度 | 业务线清单、现有需求池、历史缺陷分布 | 选一条需求相对稳定、缺陷记录较完整的业务线；约定用例粒度，例如一个功能点拆到“操作步骤＋预期结果”一级，接口类需求拆到参数组合一级 | 试点范围说明、用例粒度约定 | 试点业务线与粒度规则经测试负责人确认，团队对“一条用例”指什么有统一理解 |
| 第二步：整理需求、验收标准与历史缺陷 | 需求文档、验收标准、历史缺陷记录、相关变更说明 | 为每条需求编号，把验收标准拆成可验证的条件；从历史缺陷中提取高频失效场景，作为生成时的补充输入 | 带编号的需求条目、验收条件清单、历史缺陷场景清单 | 每条需求都能对应到至少一条验收条件，历史缺陷场景完成归类 |
| 第三步：设计提示词与生成约束 | 第二步整理好的输入、用例模板 | 在提示词中固定角色、输出格式和覆盖维度：正常流、边界值、异常输入、权限、数据一致性；要求每条用例标注来源需求编号和覆盖的验收条件 | 可复用的提示词模板、输出格式规范 | 用同一模板对两条不同需求生成，输出结构一致、来源标注齐全 |
| 第四步：人工评审与风险分级 | AI生成的用例草案、需求风险等级 | 按需求风险分级评审：高风险需求逐条评审并补充边界用例，低风险需求抽检；评审意见直接写在用例条目上 | 评审通过的用例、评审意见记录、补充用例 | 高风险需求的用例全部完成评审，评审意见有明确处理结论 |
| 第五步：入库并与缺陷记录关联 | 评审通过的用例、缺陷记录 | 用例入库并保留来源需求编号；建立用例与缺陷的关联，线上缺陷修复后回填对应用例或标记用例缺口 | 用例库、用例与缺陷的关联记录 | 新入库用例可追溯到需求，已修复缺陷能对应到用例或缺口记录 |
五步中最容易被跳过的是第二步和第五步。输入整理不充分，生成结果会大量重复或偏离验收标准；缺少缺陷关联，用例库会逐渐与真实质量问题脱节，后续也就无法判断这套流程是否有效。
角色分工与各环节交付物
流程空转通常不是步骤设计的问题，而是每个环节没有明确的责任人和交接时点。下面按角色列出交付物和交接节点，团队可以据此对照现有分工做调整。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 产品/需求方 | 提供需求与验收标准，确认验收条件可验证 | 带编号的需求条目、验收条件清单 | 需求评审通过后、进入生成前 |
| 测试负责人 | 设计生成约束与提示词模板，组织评审，制定风险分级规则 | 提示词模板、输出格式规范、评审规则 | 试点启动前；每轮生成前确认模板版本 |
| 测试工程师 | 执行评审，补充边界与异常用例，维护用例库 | 评审意见、补充用例、入库用例 | 生成完成后一个工作周期内完成评审；缺陷修复后回填关联 |
| 开发 | 提供缺陷信息与变更说明，确认缺陷与用例的对应关系 | 缺陷记录、变更说明、缺陷根因描述 | 缺陷提交时；需求变更发生时 |
交接时点需要写进团队约定，而不是靠临时沟通。例如需求评审通过后由需求方在需求条目上补齐验收条件，测试负责人在生成前检查输入是否齐全，缺项退回补充。评审意见记录在用例条目上，便于后续追溯是谁在什么依据下做了修改。
示例：一条需求如何生成并评审用例
以下示例为演示情景，用于说明流程如何走通，不代表真实项目数据。
示例需求与验收标准。需求编号 REQ-102：用户登录支持手机号加验证码登录。验收标准包括：验证码有效期为5分钟；同一手机号60秒内只能获取一次验证码；验证码连续输错5次锁定10分钟；未注册手机号提示引导注册。
生成约束的写法。提示词中明确角色为“资深测试工程师”，输出为表格，每条用例包含用例编号、来源需求编号、覆盖验收条件、前置条件、操作步骤、预期结果、覆盖维度。覆盖维度要求包含正常流、边界值、异常输入、权限与安全、数据一致性，并要求对每条验收标准至少生成一条对应用例。
AI产出的用例草案样例。草案可能包含：正常获取验证码并登录成功；验证码第5分01秒提交应失效；60秒内重复获取应被拒绝；连续输错5次后正确验证码也应被锁定；未注册手机号提交后跳转注册引导。草案通常覆盖验收标准的正向路径，边界和异常场景需要评审时核对是否完整。
评审中补充与删改的内容。评审时测试工程师补充了几类草案未覆盖的场景：验证码短信通道异常时的用户提示；同一账号在多设备同时登录的会话处理；手机号格式非法时的前端与后端双重校验。同时删除了一条与验收标准无关的“记住密码”用例，因为它属于另一条需求。评审意见逐条记录在用例条目上，注明补充原因。
最终入库与缺陷关联方式。评审通过的用例入库，保留来源需求编号 REQ-102。上线后若出现“验证码锁定期间更换设备仍可登录”的缺陷，修复后将该缺陷关联到锁定相关用例，并补充一条跨设备场景用例，形成从缺陷回到用例的闭环。
完成检查：判断流程是否可用的检查项
试点运行一段时间后，用下面的清单逐项核对。全部通过再考虑扩大范围，部分通过则先补齐薄弱环节。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 输入完整性 | 试点范围内的需求是否都有编号和可验证的验收条件；历史缺陷场景是否完成归类 | 抽查的需求条目全部具备验收条件，缺项有补充记录 |
| 用例可追溯性 | 每条入库用例是否标注来源需求编号和覆盖的验收条件 | 抽查用例均可回溯到需求，无法回溯的用例为零或有明确说明 |
| 评审记录 | 高风险需求是否逐条评审；评审意见是否记录在用例条目上 | 高风险用例评审覆盖率达标，评审意见有处理结论 |
| 缺陷回溯命中 | 试点期间发现的缺陷能否对应到已有用例，或识别为用例缺口 | 缺陷均有对应用例或缺口记录，缺口已转化为补充用例 |
| 试点扩大条件 | 需求覆盖率、评审通过率、缺陷回溯命中率是否达到团队约定阈值 | 三项指标连续两个迭代达到约定值，且评审工作量在团队可承受范围内 |
三个指标的口径需要提前约定。需求覆盖率指有用例覆盖的验收条件占全部验收条件的比例；评审通过率指一次评审即通过的用例占比，过低说明输入或提示词需要调整；缺陷回溯命中率指线上缺陷中能对应到已有用例或明确识别为缺口的比例。阈值由团队根据业务风险设定，高风险业务线可以要求更高。
把生成用例接入研发管理流程
用例只有和需求、缺陷放在同一套工作项体系中，评审状态、版本变更和缺陷回溯才有据可查。落地时可以按三条关联关系组织：用例关联来源需求，需求变更时触发用例复查；用例关联缺陷，缺陷修复后回填对应用例或标记缺口；评审状态记录在用例条目上，随版本变更保留历史。
状态流转建议保持简单：用例从“草案”进入“评审中”，评审通过后转为“已确认”，需求变更或缺陷回溯触发时回到“待复查”。每次状态变化记录操作人和依据，避免评审意见只留在聊天记录里。
在ONES中，需求、用例和缺陷可以作为工作项在同一项目空间内管理，评审记录和变更历史随工作项留存。ONES Assistant智能助手连接ONES Project、ONES Wiki与ONES TestCase，能够理解项目、工作项、迭代和Wiki页面等工作上下文，并把自然语言指令转化为可追踪的工作，例如创建缺陷、更新缺陷状态并通知项目负责人，结果保存为工作项或Wiki页面，减少页面切换和重复录入。基于ONES权限体系执行的知识问答和任务操作，输出过程可追踪、结果可审计。涉及AI能力的具体可用范围以实际产品配置为准。
接入时可以先从一个项目的需求、用例、缺陷关联做起，确认关联字段和状态流转符合团队习惯，再推广到其他业务线。这样生成用例的流程与研发管理流程同步演进，评审和回溯不会成为额外负担。
常见问题
试点阶段选哪条业务线比较合适？
优先选需求相对稳定、历史缺陷记录较完整的业务线。缺陷记录完整，才能提取高频失效场景作为生成输入，也才能在试点结束时计算缺陷回溯命中率。需求频繁大幅变更的业务线不适合作为第一条试点，输入整理成本会明显偏高。
如果团队只有一条业务线，可以缩小到其中一个功能模块，先跑通五步流程再横向扩展。
AI生成的用例和人工写的用例在评审上有什么区别？
评审重点不同。人工用例评审主要看覆盖是否完整、步骤是否可执行；AI生成的用例草案通常能覆盖验收标准的正向路径，评审时要重点核对边界值、异常输入、权限与数据一致性这几类场景是否齐全，并检查每条用例的来源需求编号和覆盖验收条件标注是否准确。
草案中偏离验收标准或属于其他需求的用例应直接删除，评审意见写明原因，便于后续调整提示词模板。
评审通过率偏低时应该先改哪里？
先看输入，再看提示词。验收条件写得不可验证，生成结果就会偏离；提示词中角色、输出格式和覆盖维度不固定，输出结构就会不一致。这两项调整后再看评审规则是否过严。
如果只是个别维度反复缺失，例如异常输入场景总是覆盖不足，可以在提示词的覆盖维度中单独强调，并在评审时对照检查。
缺陷回溯命中率怎么统计，需要覆盖全部线上缺陷吗？
统计口径建议限定在试点业务线、试点期间发现的缺陷范围内，逐条判断能否对应到已有用例，或识别为用例缺口。缺口要转化为补充用例，否则命中率只是一个数字，无法推动用例库改进。
阈值由团队按业务风险设定，高风险业务线可以要求更高。指标连续两个迭代达到约定值，再考虑扩大试点范围。
用例、需求和缺陷的关联在ONES中怎么落地？
ONES 中需求、用例和缺陷可以作为工作项在同一项目空间内管理，评审记录和变更历史随工作项留存。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把自然语言指令转化为可追踪的工作，例如创建缺陷、更新缺陷状态并通知项目负责人，结果保存为工作项或 Wiki 页面。基于 ONES 权限体系执行的知识问答和任务操作，输出过程可追踪、结果可审计。
接入时建议先从一个项目的关联字段和状态流转做起，确认符合团队习惯后再推广。涉及 AI 能力的具体可用范围以实际产品配置为准。
