编写AI测试用例草稿，关键在三个环节：先把需求拆成可验证的测试点，再用固定字段模板约束AI输出，最后由测试人员逐条评审覆盖度与可执行性。本文按输入准备、模板约束、草稿评审、角色分工、完整示例和入库检查的顺序展开，给出可直接套用的清单与模板。草稿评审、缺陷登记和用例状态流转，可以放在ONES的需求、测试与缺陷管理流程中承载。
要点总览（TL;DR）
- 先把需求拆成可验证的测试点，再交给AI生成草稿；输入材料包括需求条目、验收标准、界面或接口说明和已有用例。
- 用固定字段模板约束输出，草稿必须包含编号、标题、前置条件、操作步骤、预期结果、优先级和数据依赖，并要求AI标注【待确认】项。
- 草稿评审围绕覆盖度、可执行性和缺陷线索三项展开，需求矛盾与实现偏差应登记为缺陷并关联用例。
- 测试负责人定模板与评审标准，测试工程师准备输入并评审，产品确认验收标准，开发确认实现行为并处理缺陷。
- 入库前检查字段完整性、格式一致性、覆盖度、可执行性、待确认项清零和缺陷登记，全部通过才转为正式用例。
AI测试用例草稿的输入准备与拆解步骤
AI生成草稿的质量，很大程度上取决于输入是否具体。把一整篇需求文档直接丢给模型，得到的往往是笼统的步骤描述；把需求拆成一条条可验证的测试点再输入，输出才具备评审价值。准备阶段的目标是产出一份测试点清单，每个测试点对应一个明确的验证意图。
输入材料清单
生成草稿前，建议准备以下四类材料，缺项时在清单中标注，避免AI用假设填补空白：
- 需求条目：每条需求有唯一编号和一句话描述，便于草稿回溯来源。
- 验收标准：产品与需求方确认过的通过条件，包括数值范围、状态变化和提示文案。
- 界面或接口说明：页面字段、按钮行为、接口入参出参和错误码，决定步骤能否写到可操作的程度。
- 已有用例：同模块的历史用例，用于识别重复覆盖和保持命名、步骤风格一致。
把需求拆成可验证测试点的做法
拆解按“需求条目→业务规则→测试点”三层推进。先确认这条需求包含几条独立规则，再对每条规则问三个问题：正常输入下系统应做什么、输入处于边界时行为是否明确、输入非法或权限不足时系统如何响应。每个回答形成一个测试点，并写明验证对象和判定依据。
拆解粒度的控制标准是：一个测试点对应一个可独立判定的结果。例如“订单金额满200元免运费”可以拆成“金额199.99元收取运费”“金额200元免运费”“金额200.01元免运费”三个测试点，而不是笼统写一条“验证免运费规则”。粒度过粗会导致AI生成的步骤无法判定通过与否，过细则会让用例数量膨胀、维护成本上升，通常以一条测试点对应一到三条操作步骤为宜。
每步的输入、动作、输出与完成标志
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 收集材料 | 需求文档、验收标准、界面说明、历史用例 | 按四类材料归档，标注缺失项 | 材料清单 | 每条需求都能对应到验收标准 |
| 识别规则 | 单条需求条目 | 拆出独立业务规则并编号 | 规则列表 | 规则之间无重叠、无遗漏 |
| 生成测试点 | 规则列表 | 对每条规则写出正常、边界、异常测试点 | 测试点清单 | 每个测试点有明确判定依据 |
| 控制粒度 | 测试点清单 | 合并重复点、拆分复合点 | 定稿测试点清单 | 一个测试点对应一个可判定结果 |
完成以上四步后，测试点清单就是喂给AI的直接输入。清单中建议保留需求编号字段，后续草稿评审时可以直接核对覆盖情况。
用固定模板约束AI生成用例草稿
没有格式约束时，AI每次输出的结构都会变化，评审者需要反复适应，也难以批量比对。用固定字段模板加明确的提示结构，可以让草稿在生成阶段就具备统一形态，评审工作集中在内容判断上。
用例草稿必填字段
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 用例编号 | 模块前缀加序号，与需求编号建立对应 | ORDER-012 |
| 用例标题 | 一句话说明验证对象和条件 | 订单金额满200元时免运费 |
| 前置条件 | 执行前必须满足的账号、数据、配置状态 | 已登录普通用户，购物车含一件150元商品 |
| 操作步骤 | 编号步骤，每步一个动作，写清操作对象 | 1. 进入购物车 2. 将商品数量改为2 3. 提交订单 |
| 预期结果 | 可观察、可判定的系统表现 | 订单应付金额为300元，运费显示0元 |
| 优先级 | 按业务影响和发生频率分级 | 高 |
| 数据依赖 | 需要的测试数据及其来源 | 商品单价150元，库存充足 |
提示词中如何限定范围与输出格式
提示结构建议包含四段：角色与任务、输入材料、输出格式、限制条件。角色与任务说明“根据以下测试点生成测试用例草稿”；输入材料粘贴定稿测试点清单和相关验收标准；输出格式直接给出上表字段，并要求以表格或固定分隔格式返回；限制条件写明不扩展测试点之外的功能、不虚构接口和字段名、步骤不超过五步。
把“不虚构”写成可执行的要求更有效，例如：“界面字段名只能使用输入材料中出现的名称；材料未覆盖的判断逻辑，在对应字段后标注【待确认】并说明原因。”这样AI的不确定项会显式暴露，评审者不必逐字猜测哪些内容是模型补的。
生成结果的初步筛选
草稿生成后先做一轮快速筛选，处理三类问题：与测试点清单对不上号的用例直接退回；步骤中出现材料里没有的页面或字段，标记为待核实；同一测试点生成多条高度相似用例的，保留判定依据最清晰的一条。筛选后的草稿再进入正式评审，可以显著减少评审工作量。
草稿评审：覆盖度、可执行性与缺陷线索
AI生成的草稿只是候选材料，是否可用取决于人工评审。评审围绕三个维度展开：覆盖是否完整、步骤是否可执行、过程中是否暴露出需求或实现的问题。
覆盖度检查
对照测试点清单逐项核对，重点看四类场景是否都有对应用例：正常流程、边界值、异常输入、权限与数据状态差异。边界值要检查是否覆盖了等于、略小于、略大于临界点的取值；异常场景要检查网络中断、重复提交、必填项为空等常见情况；权限场景要区分不同角色能看到和能操作的范围。发现缺口时，补充测试点后重新生成，而不是在草稿上随意增删步骤。
可执行性检查
逐条读操作步骤，确认每一步都有明确的操作对象和入口，预期结果是可以观察和判定的具体表现。常见问题是预期结果写成“系统正常处理”“提示成功”这类无法判定的表述，应改为具体的金额、状态、文案或数据变化。数据依赖不明确的用例，补齐数据来源后再进入用例库。
缺陷线索登记与关联
评审过程中如果发现需求描述矛盾、验收标准缺失或实现行为与预期不符，应当作为缺陷线索登记，而不是在用例里含糊带过。登记时记录缺陷标题、复现步骤、关联的需求编号和用例编号，指定处理人。缺陷修复后，回填对应用例的预期结果，保持用例与实现一致。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 正常流程覆盖 | 每条业务规则至少一条正常用例 | 补充测试点后重新生成 |
| 边界与异常覆盖 | 临界值、非法输入、重复操作均有对应用例 | 补充测试点 |
| 权限与数据场景 | 涉及角色的需求区分了不同权限的可见与可操作范围 | 补充角色测试点 |
| 步骤可操作 | 每步有明确入口和操作对象 | 退回修改或标注待确认 |
| 预期结果可判定 | 结果为具体数值、状态或文案 | 改写预期结果 |
| 缺陷线索 | 需求矛盾与实现偏差已登记并关联用例 | 登记缺陷并指定处理人 |
评审结论需要留痕：通过的草稿转入正式用例库并标记状态，退回的草稿记录原因和补充要求。缺陷线索登记为缺陷后，与对应用例建立关联，修复完成后同步更新用例状态。在ONES中，这类工作可以依托需求、测试与缺陷管理的贯通流程完成；ONES Assistant可将自然语言指令转化为具体操作，例如创建一个缺陷、将状态更新为“进行中”并通知项目负责人，使评审中发现的线索直接进入可追踪的工作项。
角色分工与交付物
AI测试用例草稿的编写涉及多个角色，职责不清时容易出现输入材料不全、评审无人拍板、用例库长期不更新的问题。下表按环节列出主要职责与交付物，团队可根据规模合并角色，但交接物应保留。
| 角色 | 主要职责 | 交付物 | 交接方式 |
|---|---|---|---|
| 测试负责人 | 确定模板与评审标准，分配模块负责人，裁定争议项 | 用例模板、评审检查表、评审结论 | 在测试计划中发布，评审记录归档 |
| 测试工程师 | 准备输入材料，拆解测试点，生成并评审草稿，登记缺陷线索 | 测试点清单、用例草稿、评审记录、缺陷单 | 草稿提交评审，缺陷指派给开发 |
| 产品/需求方 | 确认验收标准，澄清需求矛盾，确认边界行为 | 验收标准、需求澄清结论 | 在需求条目下回复确认 |
| 开发 | 确认实现行为，处理缺陷，反馈接口与字段说明 | 接口说明、缺陷修复结果 | 缺陷状态更新后通知测试 |
用例库维护建议指定模块负责人：需求变更时由负责人评估受影响用例，更新预期结果和步骤，并在用例上记录变更原因和版本。评审通过的用例才进入正式库，草稿状态与正式状态分开管理，避免未评审内容被误用。
示例：一条需求如何变成可评审用例草稿
以下为演示情景，用于说明流程，不代表真实项目数据。
需求与验收标准：需求编号 PROMO-07，用户使用优惠券下单时，订单金额满200元可用10元券，不满200元不可用；同一订单只能使用一张券。验收标准写明：可用时订单应付金额减10元，不可用时提交订单提示“订单金额未满200元，无法使用该优惠券”。
拆出的测试点：金额199.99元使用券被拒绝；金额200元使用券成功；金额200.01元使用券成功；已使用一张券后再次选择第二张券被拒绝；无券用户下单流程不受影响。
AI生成的草稿片段（经模板约束后）：用例编号 PROMO-07-02，标题“订单金额满200元使用10元优惠券”，前置条件“已登录用户，账户内有一张满200减10优惠券”，步骤“1. 加入单价100元商品2件 2. 进入结算页 3. 选择该优惠券 4. 提交订单”，预期结果“订单应付金额为190元，优惠明细显示优惠10元”，优先级“高”，数据依赖“商品单价100元，库存充足”。
评审与修改：评审发现草稿未覆盖“同一订单只能使用一张券”的规则，补充测试点后重新生成对应用例；另一条用例的预期结果原为“提示优惠券不可用”，改为验收标准中的完整提示文案。评审中还发现验收标准未说明优惠券与积分抵扣同时使用时的计算顺序，登记为缺陷线索，关联 PROMO-07 与相关用例，指派给产品确认。修改后的草稿通过评审转入用例库，缺陷确认结论回填到用例的前置条件中。
完成检查：草稿可入库的判断标准
草稿进入正式用例库前，按以下清单逐项确认。全部通过方可入库，任一项不满足则退回补充。
- 字段完整性：编号、标题、前置条件、步骤、预期结果、优先级、数据依赖七项齐全，无空字段。
- 格式一致性：编号规则、步骤编号方式、预期结果表述风格与同模块已有用例一致。
- 覆盖度达标：对应测试点清单中的正常、边界、异常、权限场景均有用例，无未说明的缺口。
- 可执行性达标：步骤有明确入口和操作对象，预期结果为可判定的数值、状态或文案。
- 待确认项清零：草稿中的【待确认】标注已由产品或开发给出结论，并回填到用例。
- 缺陷线索已登记：评审中发现的缺陷均已登记并关联用例，处理人明确。
- 证据留存：评审记录、修改说明和确认人可查，用例状态从草稿变更为正式。
不满足时的退回条件也应明确：字段缺失退回生成环节补充；覆盖缺口退回测试点拆解环节；需求本身存在矛盾则挂起该用例，待需求澄清后再评审。负责人确认是用例入库的最后一步，确认动作与用例状态变更同时完成，保证库内用例都经过评审。
常见问题
需求文档写得很粗，还能用AI生成测试用例草稿吗？
可以生成，但草稿质量会受输入限制。建议先做一轮需求澄清：把每条需求拆成独立业务规则，对每条规则确认正常行为、边界取值和异常响应，形成测试点清单后再输入AI。验收标准缺失的部分，在测试点清单中标注待确认，并请产品补充；不要让AI用假设填补空白，否则草稿中的预期结果无法判定，评审时仍需返工。
AI生成的用例草稿里出现材料中没有的字段名或页面，怎么处理？
这类内容属于模型补充，不能直接采信。处理方式是：在提示词中限定字段名只能使用输入材料中出现的名称；生成后逐条核对，出现材料外内容的用例标记为待核实，退回修改或请开发确认接口与页面说明。若确认该字段真实存在，再补充到输入材料中重新生成，保持草稿与需求、实现一致。
评审时发现需求本身有矛盾，用例应该怎么处理？
把矛盾点登记为缺陷线索，记录缺陷标题、涉及的需求编号和用例编号，指派给产品或需求方确认，相关用例暂时挂起，不进入正式用例库。确认结论出来后，回填到用例的前置条件或预期结果中，再重新评审。这样处理可以避免把不确定的判断固化进用例库，也便于后续追溯这条用例为什么这样写。
用例草稿评审通过后，缺陷线索怎么跟进到关闭？
缺陷登记时关联对应用例和需求编号，指定处理人并设定状态。开发修复后更新缺陷状态并通知测试，测试按用例步骤回归，确认实现行为与预期结果一致后关闭缺陷，同时检查用例是否需要调整。在ONES中，这类操作可以借助ONES Assistant执行，例如创建缺陷、将状态更新为“进行中”并通知项目负责人，使评审发现的线索进入可追踪的工作项。
团队规模小，角色分工可以合并吗？
可以合并角色，但交接物应保留。例如测试工程师同时承担测试负责人的模板制定职责时，仍需保留测试点清单、评审记录和缺陷单，保证每个环节有据可查。产品确认验收标准、开发确认实现行为这两项职责建议由对应角色承担，避免测试人员自行假设业务规则。合并后要在测试计划中写明谁对哪类结论负责。
