测试用例模板的核心是一张可直接复制的字段表，包含用例编号、所属模块、用例标题、前置条件、操作步骤、预期结果、优先级、用例类型、设计方法、关联需求、执行结果和备注。其中前六项加优先级为必填，其余按团队需要选填。本文先给出空白表，再逐字段说明写法、划分必填与选填，并用一条登录用例示范完整填写，最后说明模板如何随项目调整。
要点总览（TL;DR）
- 测试用例模板的核心是一张可复制的字段表，包含用例编号、所属模块、用例标题、前置条件、操作步骤、预期结果、优先级、用例类型、设计方法、关联需求、执行结果和备注十二个字段。
- 用例编号、用例标题、前置条件、操作步骤、预期结果、优先级为必填；所属模块和关联需求建议必填；用例类型、设计方法、备注为选填；执行结果在设计阶段可留空，进入测试计划后必填。
- 填写时一条用例只验证一个明确目标，标题按“场景+动作+预期”组织，操作步骤与预期结果逐条编号对应，避免把多个验证点塞进同一行。
- 探索期团队可先保留六项必填字段，进入规范期后再补齐所属模块、关联需求，并启用用例类型和设计方法用于覆盖度分析。
- 模板需要版本与变更记录，并在用例评审中固定检查字段一致性；迁移到协作工具时，字段可对应到自定义用例属性、用例模块树和需求关联。
可复制的测试用例空白模板
下面这张表可以直接复制到 Excel、在线表格或需求管理工具的表格视图中使用。列顺序按填写时的思考顺序排列：先定位用例（编号、模块、标题），再写执行条件（前置条件），然后写操作与判断（步骤、预期结果），最后补充管理属性（优先级、类型、设计方法、关联需求、执行结果、备注）。
| 用例编号 | 所属模块 | 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 用例类型 | 设计方法 | 关联需求 | 执行结果 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| TC-模块-001 | 1. 2. 3. |
1. 2. 3. |
P0/P1/P2/P3 | 功能/边界/异常/兼容/性能 | 等价类/边界值/场景法/判定表 | 需求编号 | 未执行/通过/失败/阻塞 | ||||
| TC-模块-002 | 1. 2. |
1. 2. |
多行步骤的写法有两种常见处理。第一种是在单元格内换行，步骤编号与预期结果编号一一对应，如上表第一行示例；第二种是拆成“步骤表”，每条步骤单独占一行，用同一个用例编号关联。步骤超过五步、或需要多人分别执行时，拆行更清晰；步骤少、以阅读为主时，单元格内换行更紧凑。
如果团队习惯用文档而不是表格，可以把同一组字段写成条目式空白模板：
- 用例编号：
- 所属模块：
- 用例标题：
- 前置条件：
- 操作步骤：1. 2. 3.
- 预期结果：1. 2. 3.
- 优先级：
- 用例类型：
- 设计方法：
- 关联需求：
- 执行结果：
- 备注：
表格版适合批量维护、筛选和统计，字段横向对齐，便于对比同类用例；文档版适合单条用例展开说明，能容纳较长的前置条件和业务背景。多数团队以表格版为主库，文档版用于复杂业务规则的补充说明。两种形式共用同一套字段名，避免同一份用例在两处出现不同叫法。
每个字段填什么：字段说明
字段说明的作用是让不同的人填出来的用例可以互相对照。下表逐项给出含义、写法要求和常见错误。
| 字段 | 含义 | 写法要求 | 常见错误 |
|---|---|---|---|
| 用例编号 | 用例的唯一标识 | 采用“模块缩写-序号”格式，如 TC-LOGIN-001，编号一经分配不再复用 | 删除用例后编号被新用例占用，导致历史记录对不上 |
| 所属模块 | 用例归属的功能范围 | 与产品功能结构或需求模块保持一致，写到可定位的层级 | 写成“登录相关”这类模糊分类，后续无法按模块筛选 |
| 用例标题 | 一句话说明这条用例验证什么 | 按“场景+动作+预期”组织，如“已注册用户使用正确密码登录，进入首页” | 只写“登录测试”，看不出验证点和预期 |
| 前置条件 | 执行前必须满足的环境、数据、账号状态 | 写可验证的状态，如“账号已注册且状态正常”“浏览器已清除缓存” | 把操作步骤写进前置条件，或写“系统正常”这类无法核对的描述 |
| 操作步骤 | 执行者需要做的动作序列 | 按顺序编号，每步一个动作，包含必要的输入数据 | 一步里塞入多个动作，或省略输入值导致无法复现 |
| 预期结果 | 每步或整体应出现的可观察现象 | 与步骤编号对应，写页面变化、提示文案、数据状态等可核对内容 | 写“正常显示”“符合预期”，执行时无法判断通过与否 |
| 优先级 | 执行与回归的先后顺序 | 用 P0–P3 或高/中/低，P0 为核心主流程，P3 为低频边缘场景 | 全部标为高优先级，失去排序意义 |
| 用例类型 | 用例所属的验证类别 | 从团队约定的枚举值中选择，如功能、边界、异常、兼容、性能 | 同一类用例在不同人手里写成不同名称 |
| 设计方法 | 该用例采用的设计依据 | 标注等价类、边界值、场景法、判定表等，便于评审覆盖是否合理 | 留空或全部写“经验”，无法判断覆盖思路 |
| 关联需求 | 用例对应的需求或用户故事编号 | 填写需求编号，一条用例对应一个主要需求 | 关联多个不相关需求，需求变更时无法定位受影响用例 |
| 执行结果 | 最近一次执行的状态 | 使用未执行、通过、失败、阻塞等固定状态值 | 用自由文本描述，无法统计通过率 |
| 备注 | 补充说明 | 记录测试数据来源、环境差异、已知缺陷编号等 | 把失败原因和复现步骤混写，与缺陷记录重复 |
标题和步骤是填写中最容易走样的两处。标题写清“场景+动作+预期”，评审时不用打开正文就能判断用例意图；步骤按动作拆分，每一步都能独立执行。预期结果与步骤一一对应，是保证用例可判定的关键：三步操作就应有三条对应的预期，或明确说明整体结果在第几步之后出现。只写整体预期、不写中间校验点，失败时很难定位是哪一步出了问题。
一条用例只验证一个明确目标。把“登录成功”“密码错误提示”“账号锁定”塞进同一条用例，执行时一旦前一步失败，后面的验证点全部无法判断，缺陷记录也会混在一起。遇到多个验证点，拆成多条用例，用编号区分。
必填与选填：按团队阶段取舍
字段并非越多越好。必填项保证用例可执行、可追溯，选填项服务于统计、评审和长期维护。下表给出划分建议。
| 字段 | 建议 | 缺失后果 |
|---|---|---|
| 用例编号 | 必填 | 无法引用、无法关联缺陷与执行记录 |
| 用例标题 | 必填 | 无法快速识别用例意图，评审和检索效率下降 |
| 前置条件 | 必填 | 执行者不知道从什么状态开始，结果不可复现 |
| 操作步骤 | 必填 | 用例不可执行 |
| 预期结果 | 必填 | 无法判断通过与否，用例失去判定标准 |
| 优先级 | 必填 | 回归时无法确定执行顺序，核心流程可能被漏测 |
| 所属模块 | 建议必填 | 用例多时难以按功能范围筛选和分配 |
| 关联需求 | 建议必填 | 需求变更时无法定位受影响用例，追溯链断裂 |
| 用例类型 | 选填 | 影响覆盖度统计，不影响单条用例执行 |
| 设计方法 | 选填 | 影响评审时判断覆盖思路，不影响执行 |
| 执行结果 | 执行阶段必填 | 设计阶段可留空，进入测试计划后必须有状态 |
| 备注 | 选填 | 仅影响补充信息的完整度 |
探索期团队，例如刚组建测试职能、需求变化快的小团队，可以先保留编号、标题、前置条件、步骤、预期结果、优先级六项，模块用命名前缀体现，关联需求暂不强制。这样填一条用例的时间可控，先让用例写起来。进入规范期后，需求评审和变更流程稳定，再把所属模块、关联需求转为必填，并启用用例类型和设计方法，用于覆盖度分析和评审。执行结果在设计阶段留空，用例进入测试计划后由执行人更新。
需要提醒的是，前置条件、步骤、预期结果三项缺失会直接导致用例不可执行；编号和关联需求缺失则导致不可追溯。裁剪字段时优先保住这五类信息，其余字段可以按阶段逐步补齐。
完整填写示例：一条登录用例
下面用一条登录用例示范全部字段如何协同填写。
| 字段 | 填写内容 |
|---|---|
| 用例编号 | TC-LOGIN-001 |
| 所属模块 | 用户中心 / 登录 |
| 用例标题 | 已注册用户使用正确账号密码登录，进入工作台首页 |
| 前置条件 | 账号 test_user 已注册且状态正常；系统可正常访问 |
| 操作步骤 | 1. 打开登录页 2. 输入账号 test_user 和正确密码 3. 点击“登录”按钮 |
| 预期结果 | 1. 登录页正常展示账号、密码输入框和登录按钮 2. 输入框正确显示所填内容，密码以掩码显示 3. 跳转至工作台首页，页面右上角显示当前用户名 |
| 优先级 | P0 |
| 用例类型 | 功能 |
| 设计方法 | 场景法 |
| 关联需求 | REQ-1024 用户登录 |
| 执行结果 | 未执行 |
| 备注 | 测试账号由测试环境统一维护，密码见环境配置说明 |
逐字段看这条示例的填写依据。标题包含场景（已注册用户）、动作（使用正确账号密码登录）和预期（进入工作台首页），评审时无需展开正文即可判断意图。前置条件只写执行前必须成立的状态，不掺入操作动作。三步操作对应三条预期，第 2 步的预期特意写明密码掩码显示，这是一个容易被忽略但可观察的校验点。优先级定为 P0，因为登录是进入系统的主流程。关联需求填单一需求编号，需求变更时可以顺向找到这条用例。执行结果在设计阶段保持“未执行”，进入测试计划后由执行人更新。
如果这条用例要覆盖密码错误的情况，应另建 TC-LOGIN-002，标题写“已注册用户输入错误密码登录，提示密码错误且停留在登录页”，步骤与预期单独对应，而不是在 001 的备注里补一句。
模板的调整与维护方法
模板落地后需要一套轻量的维护机制，否则字段会随人员更替逐渐走样。调整字段的判断依据可以归结为三个问题：这个字段是否影响用例执行或追溯？是否有人真正使用它做筛选、统计或评审？维护它的成本是否低于它带来的信息价值？影响执行与追溯的字段保持必填；连续几个迭代无人使用的选填字段，可以合并或删除；新增字段先在少量用例中试用，再决定是否推广。
模板本身应有版本和变更记录。建议在模板文件或工具说明中维护一张变更记录表：
| 版本号 | 变更日期 | 变更内容 | 变更原因 | 影响范围 | 确认人 |
|---|---|---|---|---|---|
| V1.0 | 初始字段表 | 全部用例 | |||
| V1.1 |
用例评审时同步检查字段一致性：必填项是否齐全，标题是否写清场景、动作和预期，步骤与预期是否逐条对应，优先级分布是否合理，关联需求是否指向正确的需求编号。可以把这几项做成评审检查清单，评审人逐项勾选。字段名称一旦确定，在表格、文档和工具中保持同一叫法，避免“模块”和“功能点”混用。
团队统一使用时，落地动作包括：把模板放到团队共享位置并标注当前版本；在新人上手材料中附一条完整示例；在用例评审中固定检查字段；模板变更时通知全员并说明旧用例是否需要回填。字段调整涉及历史用例时，明确是只对新用例生效，还是批量补齐，避免新旧数据口径不一致。
当用例从个人表格迁移到协作工具时，字段需要找到对应的承载位置。ONES TestCase 支持自定义用例属性，可以把模板中的用例类型、设计方法等字段配置为属性；用例模块支持树状结构，对应“所属模块”的层级组织；用例可与需求、任务关联，测试计划与迭代关联，使“关联需求”和“执行结果”在流程中持续更新，而不是停留在静态表格里。用例库中的属性支持筛选，便于按模块、优先级或执行状态查找用例；已有 Excel 用例表可以批量导入，减少迁移时的重复录入。字段的具体配置方式以团队实际使用的版本为准。
常见问题
团队刚开始写用例，字段太多填不过来，先保留哪些？
先保留用例编号、用例标题、前置条件、操作步骤、预期结果、优先级六项，这六项直接决定用例能否执行、能否排序。所属模块可以先用编号前缀体现，例如 TC-LOGIN-001 中的 LOGIN；关联需求暂不强制。等需求评审和变更流程稳定后，再把所属模块、关联需求转为必填，并启用用例类型和设计方法。裁剪时优先保住前置条件、步骤、预期结果三项，缺失会直接导致用例不可执行。
操作步骤和预期结果一定要逐条编号对应吗？整体写一段预期行不行？
建议逐条对应。三步操作就写三条预期，或明确说明整体结果在第几步之后出现。只写整体预期，执行失败时很难判断是哪一步出的问题，缺陷记录也会缺少定位信息。如果某一步没有独立的可观察结果，可以写“无页面变化，进入下一步”，保持编号连续，便于对照。
一条用例里能不能同时验证登录成功和密码错误提示？
不建议。一条用例只验证一个明确目标。把“登录成功”“密码错误提示”“账号锁定”放进同一条用例，前一步失败后后面的验证点都无法判断，执行结果和缺陷记录会混在一起。遇到多个验证点应拆成多条用例，用编号区分，例如 TC-LOGIN-001 验证登录成功，TC-LOGIN-002 验证密码错误提示。拆分后回归时也能按优先级单独选取。
用例从 Excel 迁移到协作工具时，模板字段怎么对应？
先确认工具是否支持自定义用例属性，把用例类型、设计方法等字段配置为属性；所属模块对应用例模块的层级结构；关联需求对应需求关联字段；执行结果对应执行状态。ONES TestCase 支持自定义用例属性、用例模块树状组织，并支持从 Excel 表批量导入用例，已有表格可以较少重复录入地迁入。导入前先统一字段名称和枚举值，避免同一类用例出现多种叫法。具体配置方式以团队实际使用的版本为准。
模板字段定下来之后，多久检查一次是否需要调整？
可以按迭代节奏检查，不必设固定周期。判断依据是三个问题：字段是否影响用例执行或追溯，是否有人真正用它做筛选、统计或评审，维护成本是否低于信息价值。连续几个迭代无人使用的选填字段可以合并或删除；新增字段先在少量用例中试用再推广。每次调整记录版本号、变更日期、变更内容、原因和影响范围，并明确旧用例是只对新用例生效还是批量回填。
