AI测试用例草稿是进入正式用例库前的中间产物：它把需求条目拆成可逐条核对的步骤、预期结果和待确认项，供测试人员评审后再决定采纳或退回。下面用一份演示情景中的完整样例，说明草稿包含哪些字段、每个字段为什么这样填，以及换一个需求时如何套用。示例不指向真实客户或实测结果；草稿评审与用例状态流转可借助ONES的需求、测试用例与工作项管理来承载。
要点总览（TL;DR）
- AI测试用例草稿是评审前的中间产物，按固定字段写出编号、关联需求、前置条件、步骤、预期结果、优先级、AI生成依据、待确认项和人工复核结论。
- 可评审的关键在于：步骤与预期结果编号一一对应，前置条件写到可复现，AI推断的内容单独标为待确认项，不写成确定规则。
- 换一个需求时，先拆需求条款，再填固定字段，标记生成依据，提交评审给出采纳或退回结论，补充后复审再进入正式用例库。
- 复杂跨系统场景、安全合规高风险用例、需求本身有歧义时，草稿只能作为讨论材料，需要人工补充设计和更高层级复核。
- 示例展示填写结构与评审方式，不构成生成速度、缺陷发现率或覆盖率的承诺。
示例目标：这份草稿要解决什么问题
这份示例设定的场景是：产品经理提交了一条需求条目，测试人员用AI生成一组用例草稿，交给另一位测试同事评审。草稿的任务是让评审者在不追问背景的情况下，判断每条用例是否覆盖了需求、步骤是否可执行、预期结果是否可验证，并给出采纳、修改或退回的结论。
为了让示例具备可评审性，草稿需要满足四个标准：字段齐全，评审者能独立读懂；每条用例都能追溯到需求中的具体条款；AI自行补充的内容被明确标为待确认，不与需求原文混在一起；每条用例都留有复核结论的位置，评审动作有记录。
需要说明的是，以下需求背景、用例内容和复核意见均为演示情景编写，用于展示填写方式，不代表任何真实项目、客户或工具实测效果。
完整示例：一份AI测试用例草稿
示例需求背景与输入提示
示例需求条目（演示用）：用户登录页支持“连续输错密码5次后锁定账号30分钟”，锁定期间正确密码也无法登录，锁定到期后自动解锁；管理员可在后台手动解锁单个账号。
输入给AI的提示大致为：请依据上述需求生成测试用例草稿，覆盖正常登录、错误次数累计、锁定触发、锁定期间登录、自动解锁、管理员手动解锁六类场景；每条用例标注对应的需求条款和你不确定的地方；不要补充需求未提及的规则。
用例草稿表格
| 编号 | 关联需求 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | AI生成依据 | 待确认项 | 人工复核结论 |
|---|---|---|---|---|---|---|---|---|
| TC-LOGIN-001 | 需求第1条：连续输错5次锁定 | 账号A状态正常，未处于锁定中 | 1. 输入账号A与错误密码，点击登录；2. 重复第1步共5次 | 1. 前4次提示“账号或密码错误”；2. 第5次后提示“账号已锁定，请30分钟后重试” | 高 | 由“连续输错密码5次后锁定”直接拆出 | 第5次失败时是否同时提示剩余锁定时间，需求未写明 | 采纳，待确认项转产品确认 |
| TC-LOGIN-002 | 需求第1条：锁定期间正确密码也无法登录 | 账号A已因连续5次错误被锁定 | 1. 在锁定期间输入账号A与正确密码，点击登录 | 1. 登录失败；2. 提示账号处于锁定状态 | 高 | 由“锁定期间正确密码也无法登录”拆出 | 提示文案是否与TC-LOGIN-001一致 | 采纳，文案统一由产品确认 |
| TC-LOGIN-003 | 需求第1条：锁定30分钟后自动解锁 | 账号A已被锁定，锁定开始时间已知 | 1. 等待锁定满30分钟；2. 输入账号A与正确密码登录 | 1. 登录成功；2. 错误次数计数清零 | 高 | 由“锁定30分钟后自动解锁”拆出；计数清零为AI补充 | 解锁后错误次数是否清零，需求未明确 | 退回补充：需产品确认计数规则后重写预期结果 |
| TC-LOGIN-004 | 需求第2条：管理员手动解锁 | 账号A处于锁定中；存在管理员账号B | 1. 管理员B登录后台；2. 对账号A执行手动解锁；3. 账号A使用正确密码登录 | 1. 解锁操作成功；2. 账号A可正常登录 | 中 | 由“管理员可在后台手动解锁”拆出 | 手动解锁是否也清零错误次数；是否有操作日志要求 | 采纳，日志要求另立需求确认 |
| TC-LOGIN-005 | 需求第1条：错误次数累计口径 | 账号A状态正常 | 1. 输错密码3次；2. 间隔一段时间后使用正确密码登录成功；3. 再次输错密码2次 | 1. 第3步后账号被锁定 | 中 | AI根据“连续”一词推断计数不因成功登录而保留，属推断 | “连续”是否指不因成功登录清零，需产品确认 | 退回补充：确认计数口径后再定预期结果 |
表格中“AI生成依据”一列区分了两类内容：直接由需求条款拆出的用例，和AI自行推断补充的内容。后者在“待确认项”中单独列出，评审时优先处理。人工复核结论使用“采纳”“退回补充”两种状态，退回的用例保留在原表中，补充后再次评审，不直接删除。
逐项解释：每个字段为什么这样填
步骤与预期结果一一对应
示例中每条用例的操作步骤都编号，预期结果按相同编号对应。TC-LOGIN-001的第1步对应第1条预期，第2步（累计到第5次）对应第2条预期。这样评审者可以逐步核对，执行时也能在任一步骤失败后定位问题。预期结果写成可观察的界面提示或登录结果，避免“系统正常处理”这类无法判定的表述。
前置条件与测试数据写到可复现
前置条件写的是执行前必须成立的状态，例如“账号A已因连续5次错误被锁定”，而不是重复操作步骤。测试数据用账号A、管理员账号B这类占位标识，并说明其状态，评审者据此判断用例能否独立执行。涉及时间的用例（TC-LOGIN-003）写明“锁定开始时间已知”，为等待30分钟提供起点。
待确认项标注而非直接下结论
需求没有写明的规则，示例统一放进“待确认项”，并在“AI生成依据”中说明这是推断。例如TC-LOGIN-003中“错误次数计数清零”是AI补充的行为，草稿没有把它写成确定预期，而是标为待确认并退回。这样处理的好处是：评审者看到的是“这里需要产品决定”，而不是一条看似完整、实际包含未确认规则的用例。
优先级与覆盖范围的判断依据
示例把锁定触发、锁定期间登录、自动解锁设为高优先级，因为它们直接对应需求的核心规则，失败会影响账号安全；管理员手动解锁和计数口径设为中优先级，属于辅助路径和规则细节。覆盖范围按需求条款逐条对照：需求第1条拆出多条用例，第2条单独一条，确保每条需求都有对应用例，同时在表格中能看出哪条需求覆盖较薄。
可迁移规律：换一个需求怎么套用
把这份样例迁移到其他需求，可以按以下顺序操作：
- 先拆需求条款。把需求拆成一条条可判断真假的规则，每条规则至少对应一条用例；规则中的条件分支单独成条。
- 为每条用例填固定字段。编号、关联需求、前置条件、步骤、预期结果、优先级先写全，再让AI补充边界和异常场景。
- 标记生成依据。区分“需求原文拆出”和“AI推断补充”，后者一律进入待确认项。
- 提交评审并给出结论。评审者对每条用例给出采纳或退回补充，退回的写明缺什么信息、由谁确认。
- 补充后复审。退回的用例补充待确认项后再次评审，通过后进入正式用例库，状态从“草稿”变为“已评审”。
团队内可以统一三件事：字段顺序和必填项、待确认项的写法（写清“哪个规则未明确、需要谁确认”）、复核结论的取值（采纳、退回补充、合并到其他用例）。统一之后，不同人提交的草稿可以直接横向对照，评审时不必反复询问格式问题。草稿的评审状态和用例归属可以放在ONES的测试用例与工作项中管理，需求条目、用例草稿和复核结论保持关联，退回补充时在原条目上更新，评审记录随用例保留。
适用边界：哪些情况不适合直接套用
这份示例适合规则相对清晰、以单系统交互为主的需求，例如登录锁定、表单校验、状态切换。遇到以下情况，需要在草稿之外补充人工设计：
- 复杂业务规则与跨系统场景。多个系统之间的数据一致性、异步时序、第三方回调等场景，AI草稿容易漏掉系统间的依赖，需要测试人员补充场景设计和数据准备方案。
- 涉及安全、合规的高风险用例。权限越权、敏感数据展示、审计留痕等用例，复核要求应高于普通用例，通常需要安全或合规角色参与确认，不能只由一名测试人员采纳。
- 需求本身存在歧义。示例中TC-LOGIN-003和TC-LOGIN-005的退回说明，需求未明确的规则应先由产品确认，再定预期结果；在规则确认前，草稿只能作为讨论材料。
示例展示的是草稿的填写结构和评审方式，不构成对生成速度、缺陷发现率或覆盖率的承诺。测试执行脚本的编写、自动化框架选型以及模型训练与调优不在本文范围内，草稿评审通过后如何转化为执行资产，需按团队既有流程处理。
常见问题
AI生成的用例草稿里，哪些内容必须标为待确认项？
凡是需求原文没有写明、由AI根据上下文推断出来的规则，都应进入待确认项。常见的有：提示文案的具体措辞、计数是否清零、操作是否留日志、多个条件同时满足时的优先级。示例中TC-LOGIN-003的“错误次数计数清零”和TC-LOGIN-005的“连续”口径都属于这类内容。标注时写清“哪个规则未明确、需要谁确认”，评审者才能直接推进。
退回补充的用例应该删除还是保留？
建议保留在原草稿表中，把复核结论标为“退回补充”，并写明缺什么信息、由谁确认。保留的好处是评审记录完整，补充后可以在原条目上更新并再次评审，避免同一规则被重复生成或遗漏。删除退回条目会让后续评审者看不到已经识别出的规则缺口。
草稿评审通过后，如何进入正式用例库？
评审通过的用例从“草稿”状态转为“已评审”，连同关联需求、复核结论一起进入正式用例库。团队可以约定：只有已评审状态的用例才纳入测试计划，退回补充的用例不进入执行范围。草稿、需求条目和复核记录保持关联，后续需求变更时能追溯到受影响的用例。这类状态流转可以放在ONES的测试用例与工作项中管理。
需求本身写得模糊时，还能先让AI生成草稿吗？
可以生成，但草稿的定位是讨论材料，不能直接作为执行依据。做法是把模糊点逐条列进待确认项，先由产品确认规则，再据此改写预期结果。示例中TC-LOGIN-003和TC-LOGIN-005就是先退回、待产品确认计数口径后再定预期结果。规则确认前，草稿帮助团队看清需求缺口，评审结论以“退回补充”为主。
团队统一草稿格式时，最少要约定哪几项？
至少约定三件事：字段顺序和必填项，确保不同人提交的草稿可以横向对照；待确认项的写法，统一为“未明确的规则＋确认人”；复核结论的取值，例如采纳、退回补充、合并到其他用例。约定之后，评审时不必反复询问格式问题，可以把注意力放在覆盖范围和预期结果是否可验证上。
