这份示例把一条登录需求拆成可评审的测试用例草稿，完整展示前置条件、操作步骤、预期结果、优先级与追溯来源的填写方式，并逐项说明取值理由和需要人工补充的部分。示例为演示情景，用于说明写法，不代表真实项目记录或实测结果。
要点总览（TL;DR）
- AI测试用例草稿的可评审标准是：前置条件、操作步骤、预期结果、优先级与追溯来源齐全，他人能独立复现并判定结果。
- 示例把一条登录需求拆成9条用例，覆盖正常路径、长度边界、凭证错误和锁定机制，需求每句话都能在追溯列找到对应用例。
- 拆解顺序固定为五步：标注需求句子、列场景清单、补前置条件与测试数据、写步骤与预期结果、回填优先级与追溯来源。
- 提示文案、锁定计时起点、解锁方式等需求未明确的内容，AI只能给出候选写法，必须与产品负责人确认后定稿。
- 草稿直接入库、跳过评审是主要误用，会导致执行结果与产品实际行为不符，产生大量无效缺陷记录。
这份示例要解决什么问题
示例选取的需求是“用户使用手机号和密码登录，连续输错密码达到阈值后锁定账号”。这条需求包含正常路径、边界条件和异常处理，适合演示从需求条目到用例条目的拆解过程。需求本身写得比较简略，正好能说明AI草稿在哪些地方需要补全，哪些地方必须由测试人员判断。
草稿要达到的可评审标准有四条：他人能按前置条件和步骤独立复现；每一步都有可观察的预期结果；优先级有明确依据；每条用例能追溯到需求条目或需求中的具体句子。满足这四条，用例才具备进入评审会的基础，评审者可以把精力放在覆盖是否完整、判定口径是否合理上，而不是先猜用例想测什么。
需要说明的是，下文的需求原文、用例编号、测试数据和判定阈值均为演示设定。示例不涉及具体客户、真实系统或实测数据，也不代表任何产品的实际表现。读者对照时，应把注意力放在字段结构和拆解顺序上，而不是照搬示例中的具体数值。
完整示例：一条登录需求生成的用例草稿
需求原文（演示）：用户使用手机号和密码登录。手机号为11位数字，密码为8至20位字符。连续输错密码5次后，账号锁定30分钟。锁定期间正确密码也无法登录。登录成功后进入首页。
拆解后的用例清单如下，覆盖正常路径、边界与异常路径：
| 用例编号 | 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 追溯来源 |
|---|---|---|---|---|---|---|
| TC-LOGIN-001 | 正确手机号与密码登录成功 | 账号已注册且未锁定；密码为正确密码 | 1. 打开登录页 2. 输入已注册手机号 3. 输入正确密码 4. 点击登录 |
登录成功，页面跳转至首页，顶部显示当前登录手机号 | P0 | 需求句1、句5 |
| TC-LOGIN-002 | 手机号长度为10位时提示格式错误 | 登录页可正常打开 | 1. 输入10位数字手机号 2. 输入合法密码 3. 点击登录 |
登录不提交，手机号输入框下方提示“请输入11位手机号” | P1 | 需求句2 |
| TC-LOGIN-003 | 手机号长度为12位时提示格式错误 | 登录页可正常打开 | 1. 输入12位数字手机号 2. 输入合法密码 3. 点击登录 |
登录不提交，手机号输入框下方提示“请输入11位手机号” | P1 | 需求句2 |
| TC-LOGIN-004 | 密码为7位时提示长度不符 | 已注册手机号可用 | 1. 输入已注册手机号 2. 输入7位密码 3. 点击登录 |
登录不提交，密码输入框下方提示密码长度要求 | P1 | 需求句2 |
| TC-LOGIN-005 | 密码为21位时提示长度不符 | 已注册手机号可用 | 1. 输入已注册手机号 2. 输入21位密码 3. 点击登录 |
登录不提交，密码输入框下方提示密码长度要求 | P1 | 需求句2 |
| TC-LOGIN-006 | 密码错误时提示登录失败 | 账号已注册且未锁定 | 1. 输入已注册手机号 2. 输入错误密码 3. 点击登录 |
登录失败，提示“手机号或密码错误”，不透露具体哪项错误 | P0 | 需求句3 |
| TC-LOGIN-007 | 连续输错5次后账号锁定 | 账号已注册且当前未锁定，错误次数为0 | 1. 连续5次输入错误密码并提交 2. 第6次输入正确密码并提交 |
第5次失败后提示账号已锁定；第6次即使密码正确也登录失败，提示锁定剩余时间 | P0 | 需求句3、句4 |
| TC-LOGIN-008 | 锁定30分钟后可重新登录 | 账号处于锁定状态，锁定开始时间已知 | 1. 等待锁定时间结束 2. 输入正确手机号与密码 3. 点击登录 |
锁定解除，登录成功并进入首页 | P1 | 需求句3、句4 |
| TC-LOGIN-009 | 未注册手机号登录 | 该手机号未注册 | 1. 输入未注册手机号 2. 输入任意合法密码 3. 点击登录 |
登录失败，提示“手机号或密码错误”，与密码错误提示一致 | P1 | 需求句1、句3 |
这份草稿的覆盖结构可以这样看：TC-LOGIN-001覆盖正常路径；002至005覆盖手机号和密码的长度边界，分别取阈值的两侧；006、009覆盖凭证错误的异常路径；007、008覆盖锁定机制及其解除。需求中的每一句都能在追溯列找到对应用例，没有出现需求写了但无用例覆盖的句子。
逐项解释：每个字段为什么这样填
前置条件写的是执行这条用例之前系统必须处于的状态，以及测试数据的准备情况。TC-LOGIN-007写“错误次数为0”，是因为锁定逻辑依赖累计次数，如果前置状态不明，第5次失败后是否锁定就无法判定。前置条件里不放操作动作，动作归入步骤列，这样评审者能一眼分清“准备什么”和“做什么”。测试数据尽量写具体，例如“11位数字手机号”，而不是“合法手机号”，避免执行时各自理解不同。
步骤的颗粒度以“每一步产生一个可观察的状态变化”为准。输入手机号、输入密码、点击登录拆成三步，是因为点击登录之后才触发校验，前两步只是数据录入。如果把三步合成一句“输入账号密码登录”，执行者无法判断失败发生在哪一步。预期结果要写到可判定的程度：TC-LOGIN-002写“提示‘请输入11位手机号’”，给出了提示文案和出现位置；如果只写“提示格式错误”，不同人可能对提示形式有不同预期，评审时就容易产生分歧。
优先级依据业务影响和失败概率综合判断。登录成功、密码错误提示、账号锁定这三类直接阻断用户使用，定为P0；长度边界和未注册手机号属于校验类场景，失败影响有限，定为P1。追溯来源写到需求的具体句子，而不是只写需求编号，这样需求变更时能快速定位受影响的用例。示例中的“需求句1”至“句5”对应前文需求原文的五句话。
AI生成的草稿中，以下几类内容需要人工重点复核：提示文案的具体措辞，需求往往没写，示例中的文案是演示设定；锁定时间的计时起点，是从第5次失败开始算还是从首次失败开始算，需求未明确；锁定期间是否允许通过其他方式解锁；错误提示是否应统一措辞以防账号枚举。这些点示例给出了一种合理填法，但真实项目中必须与产品负责人确认后再定稿。
可迁移规律：换一条需求怎么照着写
拆解顺序可以固定为五步。第一步通读需求，把每句话标上序号，找出其中的名词（对象）、动词（动作）和数量条件（长度、次数、时长）。第二步按“正常路径—边界—异常”三类列出场景清单，数量条件的两侧各取一个值。第三步为每个场景补齐前置条件和测试数据，明确执行起点。第四步写步骤和预期结果，逐步对应，预期结果落到文案、页面状态或数据变化。第五步回填优先级和追溯来源，检查每句需求是否都有用例对应。
覆盖维度可以用下面的清单自查：
- 需求中的每个数量条件，是否都有等于阈值、小于阈值、大于阈值的用例；
- 每个输入项是否覆盖空值、格式错误、超长三类情况；
- 状态类需求是否覆盖状态进入、状态维持和状态解除；
- 异常提示是否覆盖措辞一致性和信息泄露风险；
- 每条用例的追溯来源是否指向具体需求句子；
- 是否存在两条用例步骤相同、仅预期结果不同的重复项。
草稿进入评审前，建议做三项自检：请一位未参与编写的同事按步骤默读，看能否说出预期结果；检查前置条件中是否混入了操作动作；确认所有演示性数值都已替换为需求确认过的真实口径。自检通过后再提交评审，评审会的讨论就能集中在判定口径和覆盖缺口上。
当草稿需要进入团队协作流程时，可以把用例条目挂到需求工作项下，让追溯关系在系统里保持可查。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项和 Wiki 页面等工作上下文，并基于相关数据回答问题、执行后续操作。在这一流程中，需求澄清阶段可以用它提炼待澄清问题，用例评审后发现的缺口可以通过创建缺陷、更新缺陷状态并通知项目负责人来跟进，使草稿、评审意见和缺陷记录留在同一条追溯链上。具体入口和字段配置以团队实际部署为准。
适用边界与常见误用
适合用AI起草的需求通常具备这些特征：需求文本可读、包含明确的输入输出或状态变化；业务规则以条件句形式写出，例如长度、次数、时限；团队已有统一的用例字段模板。这类需求拆解规律清晰，AI草稿的初稿质量较高，人工主要做核对和补全。需求本身模糊、涉及跨系统交互或强依赖历史数据时，AI草稿只能作为讨论素材，场景清单需要测试人员主导梳理。
需要人工主导的情形还包括：判定口径涉及业务方主观标准，例如“提示是否友好”；需求存在未决的产品决策，例如锁定计时起点；涉及权限、资金或隐私的校验逻辑，错误代价高，必须由熟悉业务的人逐条确认。这些内容AI可以给出候选写法，但定稿责任在测试人员和产品负责人。
最常见的误用是把草稿直接入库、跳过评审。草稿中的提示文案、阈值口径和前置状态都是推定值，未经确认就作为执行依据，会导致执行结果与产品实际行为不符，缺陷单里出现大量“预期结果写错”的无效记录。另一种误用是把AI生成的多条用例当作覆盖完整的证明，实际上数量多不等于覆盖全，仍要按覆盖清单逐项核对。草稿的价值在于缩短初稿时间，评审和确认环节不能省。
常见问题
AI生成的用例草稿里，哪些字段可以直接用，哪些必须人工改写？
结构类字段可以直接沿用，包括用例编号规则、步骤的拆分方式、追溯来源指向的需求句子。这些内容由拆解方法决定，只要需求句子标注准确，AI给出的结构通常可以直接进入评审。
判定类字段需要人工确认，重点是预期结果中的提示文案、锁定计时起点、错误提示是否统一措辞。需求原文往往只写“提示格式错误”，具体文案是AI的推定值。示例中的“请输入11位手机号”就是演示设定，真实项目中要按产品确认的口径替换后再定稿。
需求写得很简略，AI草稿会不会漏掉关键场景？
简略需求恰恰是AI草稿容易漏场景的地方。示例需求只有五句话，锁定计时起点、锁定期间能否通过其他方式解锁、错误提示是否防账号枚举，这些都没有写明。草稿能按条件句拆出长度边界和次数阈值，但对需求未提及的规则只能给出一种合理填法。
处理办法是在评审前补一轮需求澄清，把草稿中标注为推定的内容列成问题清单，与产品负责人逐条确认。确认后的结论回填到用例，再进入正式评审。这样草稿承担的是初稿工作量，场景完整性仍由测试人员把关。
用例草稿和缺陷记录怎么衔接，避免追溯断链？
衔接的关键是让用例条目和需求工作项保持可查的关联。用例评审后发现的覆盖缺口，应当以缺陷形式记录，并关联到对应的需求或用例，而不是散落在聊天记录里。
在ONES中，可以把用例条目挂到需求工作项下，ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项和 Wiki 页面等工作上下文，并基于相关数据回答问题、执行后续操作；评审后发现的缺口可以通过创建缺陷、更新缺陷状态并通知项目负责人来跟进。具体入口和字段配置以团队实际部署为准。
哪些需求类型不适合直接用AI起草用例？
需求文本模糊、缺少明确输入输出或状态变化时，AI草稿只能作为讨论素材。涉及跨系统交互、强依赖历史数据、权限或资金校验的需求，错误代价高，场景清单需要熟悉业务的人主导梳理。
判定口径带主观标准的需求同样需要人工介入，例如“提示是否友好”这类描述无法直接转成可判定的预期结果。这类需求可以借助AI列出候选场景，但定稿责任在测试人员和产品负责人。
照着示例写自己的用例，最容易在哪一步出错？
最容易出错的是前置条件列。示例中TC-LOGIN-007写“错误次数为0”，是因为锁定逻辑依赖累计次数；如果前置状态写成“账号正常”，第5次失败后是否锁定就无法判定。前置条件里混入操作动作也是常见问题，会让评审者分不清准备状态和执行动作。
其次是预期结果写得过粗，只写“提示错误”而不给文案和出现位置，执行时各自理解不同。建议提交评审前请一位未参与编写的同事按步骤默读，确认能说出预期结果，再检查演示性数值是否都已替换为确认过的口径。
