测试用例编写模板至少要覆盖用例编号、用例标题、所属模块或需求、优先级、用例类型、前置条件、操作步骤、预期结果、测试数据、实际结果与执行状态、备注这些字段。前置条件写清执行前必须成立的环境、数据和权限状态；步骤按单步单动作编号，动作与输入明确；预期结果与步骤逐条对应，写成可观察、可判定的界面或数据结果。下面给出一份可直接复制的空白表格，并说明每个字段的填写口径、必填取舍和一条完整示例。
要点总览（TL;DR）
- 测试用例编写模板的最小可用字段集为：用例编号、用例标题、前置条件、操作步骤、预期结果、优先级；所属模块/需求、用例类型、测试数据、实际结果、执行状态、备注按项目阶段补充。
- 前置条件写成可核对的状态，例如账号已登录、库存为10、购物车已有1件，避免“系统正常”这类无法验证的描述。
- 操作步骤单步单动作并编号，步骤数量与预期结果条数一致，失败时才能定位到具体环节。
- 预期结果写成可观察、可判定的界面提示、状态值或数据变化，与步骤逐条对应。
- 模板先小范围试用一个迭代，按评审中暴露的问题增删字段，并记录版本与变更点。
可复制空白模板：测试用例编写表
模板分两种粒度使用：单条用例表用于记录一条可独立执行的测试用例；用例集清单用于汇总一个模块或一个迭代内的多条用例，便于排期、分配和统计执行进度。两者字段有交集，但清单不承载步骤细节，避免同一份表既当明细又当索引。
单条用例表（空白，可直接复制到表格工具）
| 用例编号 | 用例标题 | 所属模块/需求 | 优先级 | 用例类型 | 前置条件 | 操作步骤 | 测试数据 | 预期结果 | 实际结果 | 执行状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
步骤与预期结果在表格单元格内按编号分行填写，例如“1. …… 2. ……”与“1. …… 2. ……”上下对齐。若表格工具支持子表，也可把步骤拆成独立子表，列为“步骤序号、操作动作、输入数据、预期结果”，主表只保留汇总信息。
用例集清单（空白，用于汇总与跟踪）
| 用例编号 | 用例标题 | 所属模块/需求 | 优先级 | 用例类型 | 负责人 | 执行状态 | 最近执行日期 | 关联缺陷 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
清单中的“执行状态”建议限定为固定选项，如未执行、通过、失败、阻塞、跳过，便于统计通过率；“关联缺陷”填写缺陷编号，保持用例与问题记录可追溯。
字段说明：每个字段填什么、怎么判定合格
字段能否用起来，取决于填写口径是否统一。下面按标识类、执行类、管理类三组说明，每个字段给出含义与合格标准，团队可据此做填写检查。
| 分组 | 字段 | 填什么 | 合格口径 |
|---|---|---|---|
| 标识类 | 用例编号 | 团队内唯一的编号，可按“模块缩写-序号”生成 | 全局不重复，编号不随标题修改而变化，便于引用和关联缺陷 |
| 标识类 | 用例标题 | 一句话说明验证什么对象、在什么条件下、得到什么结果 | 不看步骤也能判断测试意图；避免“测试登录”“功能验证”这类无法区分的标题 |
| 标识类 | 所属模块/需求 | 功能模块名称，或需求、用户故事编号 | 能定位到具体需求条目或模块，便于按范围筛选和统计覆盖率 |
| 执行类 | 前置条件 | 执行前必须成立的环境、数据、账号权限、系统状态 | 每条都可验证，例如“已存在一个状态为待审核的订单”；不写“系统正常”这类无法判定的描述 |
| 执行类 | 操作步骤 | 按顺序编号的操作动作，含必要输入 | 单步单动作，执行人按步骤操作无需猜测；步骤数量与预期结果条数一致 |
| 执行类 | 测试数据 | 步骤中使用的具体数据，如账号、金额、文件名、边界值 | 数据可直接取用或明确生成方式；敏感数据用占位符并注明来源 |
| 执行类 | 预期结果 | 每步操作后应出现的界面、提示或数据变化 | 可观察、可判定，写明具体文案、状态值或数量；避免“显示正常”“操作成功”这类模糊表述 |
| 管理类 | 优先级 | 高、中、低，或 P0–P3 | 有统一判定规则，例如核心主流程为高，异常分支为中低；同一模块内优先级分布合理 |
| 管理类 | 用例类型 | 功能、界面、兼容性、性能、安全、异常等 | 取自固定枚举值，便于按类型筛选和安排执行人 |
| 管理类 | 实际结果 | 执行时实际观察到的结果 | 与预期结果逐条对照记录；失败时写清差异点，便于提单 |
| 管理类 | 执行状态 | 未执行、通过、失败、阻塞、跳过 | 使用固定选项；阻塞和跳过需在备注写明原因 |
| 管理类 | 备注 | 依赖关系、环境限制、历史变更说明等 | 只写对执行或维护有用的信息，不堆叠无关描述 |
前置条件、步骤、预期结果三者构成一条用例的执行链：前置条件保证起点一致，步骤描述动作，预期结果给出判定标准。三者中任何一项含糊，执行人都会凭经验补全，导致同一用例在不同人手里得出不同结论。
必填与选填：哪些字段不能空
模板字段越多，填写成本越高，遗漏也越容易发生。建议先确定最小可用字段集，保证一条用例能被独立执行和判定，再按项目阶段补充管理类字段。
| 类别 | 字段 | 理由与适用场景 |
|---|---|---|
| 必填 | 用例编号 | 唯一标识，缺陷关联、评审引用都依赖它 |
| 必填 | 用例标题 | 决定用例能否被检索和区分 |
| 必填 | 前置条件 | 没有它，执行起点不一致，结果无法复现 |
| 必填 | 操作步骤 | 用例的核心内容，缺失则无法执行 |
| 必填 | 预期结果 | 判定通过与否的唯一依据 |
| 必填 | 优先级 | 决定回归范围和执行顺序，缺省会导致执行无重点 |
| 建议必填 | 所属模块/需求 | 需要按需求统计覆盖情况时必填；早期探索阶段可先记模块名 |
| 建议必填 | 用例类型 | 需要按类型分配执行人或做专项测试时必填 |
| 选填 | 测试数据 | 数据简单且已写在步骤中时可省略；涉及边界值、多组数据时建议单列 |
| 选填 | 实际结果、执行状态 | 用例首次编写时为空，执行阶段填写；若模板同时承担执行记录，则执行时必填 |
| 选填 | 备注 | 按需填写，不强制 |
取舍建议：小团队或项目早期，先用“编号、标题、前置条件、步骤、预期结果、优先级”六项跑通，执行记录放在单独的测试执行表中；当用例数量增长、需要按需求统计覆盖率和回归范围时，再补所属模块/需求、用例类型、测试数据。中大型项目或多人协作场景，建议把执行状态和实际结果纳入同一张表，减少用例与执行记录对不上的情况。
填写示例：一条完整用例的前置条件、步骤与预期结果
下面以“提交订单后库存扣减”为例填写一条完整用例，重点看前置条件、步骤、预期结果如何一一对应。示例为演示情景，数据为虚构。
| 字段 | 填写内容 |
|---|---|
| 用例编号 | ORDER-012 |
| 用例标题 | 库存充足时提交订单，订单状态变为待发货且商品库存减1 |
| 所属模块/需求 | 订单模块 / 需求 REQ-208 下单流程 |
| 优先级 | 高 |
| 用例类型 | 功能 |
| 前置条件 | 1. 测试账号 buyer01 已登录且收货地址已完善；2. 商品 SKU-A 当前库存为 10；3. 购物车中已有 1 件 SKU-A，未提交过订单 |
| 操作步骤 | 1. 进入购物车页面，勾选 SKU-A；2. 点击“去结算”；3. 确认收货地址后点击“提交订单” |
| 测试数据 | 账号 buyer01；商品 SKU-A；购买数量 1；库存初始值 10 |
| 预期结果 | 1. 购物车中 SKU-A 显示为已勾选，合计金额为 1 件价格；2. 进入结算页，收货地址显示为默认地址；3. 页面提示“订单提交成功”，跳转订单详情，订单状态为“待发货”，SKU-A 库存变为 9 |
| 实际结果 | （执行时填写） |
| 执行状态 | 未执行 |
| 备注 | 库存校验依赖订单服务与库存服务联调完成 |
这条用例的可执行性来自三点：前置条件写成了可核对的状态（库存为 10、购物车已有 1 件），步骤每步只有一个动作，预期结果与三个步骤逐条对应，且第 3 条同时给出提示文案、订单状态和库存数值三个可观察点。
常见写法错误对照
| 位置 | 不合格写法 | 问题 | 改写方向 |
|---|---|---|---|
| 前置条件 | 系统正常运行，有商品数据 | 无法验证，执行人不知道库存多少、账号是否登录 | 写明具体账号、库存数值、购物车状态 |
| 操作步骤 | 登录后下单并检查库存 | 多动作合并，无法定位失败发生在哪一步 | 拆成勾选、结算、提交三个编号步骤 |
| 预期结果 | 下单成功，库存正确 | “成功”“正确”没有判定标准 | 写明提示文案、订单状态值、库存前后数值 |
| 步骤与预期 | 三步操作只写一条预期结果 | 中间步骤的结果无人判定，失败时难以定位 | 预期结果按步骤编号逐条对应 |
调整与维护方法：模板落地后的增删与版本管理
模板不是一次定稿的文档。字段增删应依据实际使用中的问题判断：如果评审中反复出现“执行人不知道从哪开始”，优先补强前置条件；如果失败用例难以定位，检查步骤是否拆分到位、预期结果是否逐条对应；如果统计覆盖率困难，再补所属模块/需求字段。新增字段前先确认它会被谁使用、产生什么记录，避免为完整性堆字段。
模板评审与试用可按以下步骤推进：
- 由测试负责人起草模板，写明每个字段的填写口径和必填规则。
- 选取一个迭代或一个模块试用，用真实需求编写 10–20 条用例。
- 组织一次用例评审，检查字段是否够用、是否有字段长期为空、执行人是否产生歧义。
- 根据评审结论调整字段和口径，形成模板 v1.0 并记录变更点。
- 在团队内同步填写规范，新成员入职时按同一份口径培训。
版本管理建议把模板本身也纳入变更记录：记录版本号、变更日期、变更人、增删了哪些字段、为什么改。字段口径变化时，已有用例不强制批量返工，可在下次评审该用例时顺带补齐；影响执行判定的变更（如执行状态选项调整）需要同步通知执行人。
模板还要与用例评审、执行记录衔接。评审时按字段逐项检查，重点看前置条件是否可验证、步骤是否单步单动作、预期结果是否与步骤一一对应；执行时实际结果和状态回填到同一张表或关联的执行记录中，失败用例直接关联缺陷编号。这样用例从编写、评审到执行形成一条可追溯的记录链。
当用例数量增长到需要多人协作维护时，可以把模板字段落到统一的工作项或文档结构中：用例作为工作项承载编号、标题、优先级、状态等字段，步骤与预期结果放在描述或子项中，评审意见和执行结果留在同一条记录上。ONES 的测试管理支持用例的编写、评审与执行状态跟踪，并可与需求、缺陷关联，适合把上述字段和流程固定下来；具体配置方式按团队现有流程调整。
常见问题
用例标题和操作步骤都写清楚了，标题还需要单独规范吗？
需要。标题承担的是检索和区分职责，步骤承担执行职责。评审或回归时，执行人通常先按标题筛选用例，标题写不清会导致重复编写或漏测。合格标题应包含验证对象、条件和结果，例如“库存充足时提交订单，订单状态变为待发货且库存减1”，不看步骤也能判断测试意图。
前置条件里能不能写“已登录系统”这种通用描述？
可以写，但要补足可核对的信息。只写“已登录系统”时，执行人不知道用哪个账号、该账号有什么权限、是否已有业务数据。建议写成“测试账号 buyer01 已登录，收货地址已完善”，把账号、权限和必要数据状态一起交代，执行起点才能保持一致。
一条用例有多个检查点时，预期结果必须和步骤一一对应吗？
建议逐条对应。步骤与预期结果条数一致，失败时能直接定位到哪一步的判定不通过。若某一步操作产生多个观察点，可在该条预期结果内用分号并列写明，例如同时给出提示文案、订单状态和库存数值，但仍归在该步骤编号下，避免多条步骤共用一条笼统的预期结果。
小团队字段少，执行状态和实际结果放在哪里记录？
可以放在单独的测试执行表中，用例表只保留编号、标题、前置条件、步骤、预期结果和优先级。执行时按用例编号关联执行记录，填写实际结果和状态。当用例数量增长、需要按需求统计通过率时，再把执行状态纳入同一张表，减少用例与执行记录对不上的情况。
模板字段调整后，已有用例需要批量返工吗？
通常不需要。字段口径变化时，可在下次评审或执行该用例时顺带补齐；影响执行判定的变更，例如执行状态选项调整，需要同步通知执行人并更新填写说明。模板本身记录版本号、变更日期和增删字段原因，便于追溯口径变化。
