填写测试用例模板，关键是把一条用例写成可执行、可判断、可追溯的记录：先写清用例编号、标题、所属模块与优先级，再补前置条件、测试数据、操作步骤和预期结果，最后记录用例类型、关联需求与维护信息。本文提供可直接复制的空白表格与单条用例骨架，逐字段说明填写口径，并给出必填选填取舍和一条完整示例，方便你按团队情况调整使用。
要点总览（TL;DR）
- 填写测试用例模板的核心是让一条用例可执行、可判断、可追溯：编号、标题、模块、优先级、前置条件、测试数据、操作步骤、预期结果缺一不可。
- 最小可用字段集建议保留编号、标题、模块、前置条件、操作步骤、预期结果和优先级七项；关联需求、测试数据、维护人按团队规模与需求变更频率增补。
- 操作步骤与预期结果按序号一一对应，测试数据单独成字段，预期结果写成可观察的事实，例如页面跳转和显示内容。
- 模板需要维护版本、定期评审字段一致性，并对过期用例归档清理，避免字段膨胀和旧用例误用。
可直接复制的测试用例空白模板
下面这张表可以直接复制到电子表格中，一行对应一条用例。列的顺序按“先识别、再执行、后管理”排列，填写时从左往右推进，评审时也按这个顺序检查。
| 用例编号 | 用例标题 | 所属模块 | 关联需求 | 优先级 | 用例类型 | 前置条件 | 测试数据 | 操作步骤 | 预期结果 | 设计方法 | 维护人 | 版本 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果团队使用文档而不是表格，可以用下面的单条用例骨架。它把表格中的列转成纵向字段，适合在需求文档或测试计划中直接嵌入一条用例。
用例编号： 用例标题： 所属模块： 关联需求： 优先级： 用例类型： 前置条件： 测试数据： 操作步骤： 1. 2. 3. 预期结果： 1. 2. 3. 设计方法： 维护人： 版本： 备注：
这套模板适用于功能测试的手工用例编写，覆盖 Web、App 和后端接口的功能验证场景。使用时注意两点：操作步骤与预期结果按序号一一对应，第 1 步操作对应第 1 条预期；测试数据写在独立字段里，避免散落在步骤描述中，方便回归时替换数据复用。
每个字段写什么：字段说明与填写口径
字段填写的共同标准是：执行人只看这条用例，不需要再问设计者就能操作并判断通过与否。下表按标识、执行、管理三类说明每个字段的含义、填写口径和常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 用例编号 | 用例的唯一标识 | 采用“模块缩写-序号”格式，如 LOGIN-001，全库不重复 | 编号重复或随手填写，导致追溯和引用困难 |
| 用例标题 | 一句话说明验证什么 | 写“场景+动作+预期”，如“正确账号密码登录成功” | 只写“登录测试”，无法区分多条同类用例 |
| 所属模块 | 用例归属的功能范围 | 与产品功能结构或需求模块保持一致 | 模块名随意起，与需求文档对不上 |
| 关联需求 | 用例对应的需求条目 | 填写需求编号或需求标题，便于需求变更时定位受影响用例 | 留空，需求变更后无法判断哪些用例要改 |
| 优先级 | 执行和回归的先后顺序 | 按业务影响划分高、中、低；核心主流程为高 | 全部标为高，优先级失去筛选作用 |
| 用例类型 | 用例验证的性质 | 标注功能、边界、异常、权限、兼容等类别 | 只写“功能”，异常和边界场景难以统计覆盖 |
| 前置条件 | 执行前必须满足的状态 | 写清账号状态、数据准备、环境配置，如“已注册且未锁定的账号” | 把操作步骤写进前置条件，边界模糊 |
| 测试数据 | 本用例使用的具体输入 | 给出可直接使用的值，如账号 test01、密码 Abc12345 | 写“输入正确密码”这类描述，执行人仍需自行构造数据 |
| 操作步骤 | 执行人需要做的动作序列 | 每步一个动作，按顺序编号，动词开头 | 一步包含多个动作，失败时无法定位问题环节 |
| 预期结果 | 每步操作后应出现的可观察结果 | 与步骤序号对应，写页面提示、状态变化、数据结果 | 写“正常显示”“符合预期”等无法判断的表述 |
| 设计方法 | 用例采用的设计思路 | 标注等价类、边界值、场景法等，便于评审覆盖度 | 留空，评审时难以判断是否遗漏场景 |
| 维护人 | 负责该用例更新的人 | 填写具体责任人，而非团队名称 | 写“测试组”，出问题时无人认领 |
| 版本 | 用例内容的修订记录 | 每次实质修改递增版本号，并在备注中说明改动 | 改了内容不更新版本，回归时用了旧用例 |
填写时有两个容易忽略的口径。第一，预期结果要写成可观察的事实，例如“页面跳转到首页，右上角显示用户名 test01”，而不是“登录成功”。第二，测试数据与前置条件分开：前置条件描述状态，测试数据给出具体值，两者混写会让用例在换数据复用时失效。
必填与选填：最小可用字段集怎么定
模板字段越多，单条用例的编写和后续维护成本越高。最小可用字段集应保证一条用例能被独立执行、被评审、被追溯，其余字段按项目需要增补。
| 字段 | 建议 | 理由 |
|---|---|---|
| 用例编号 | 必填 | 唯一标识，支撑引用、追溯和缺陷关联 |
| 用例标题 | 必填 | 评审和回归时快速识别用例内容 |
| 所属模块 | 必填 | 支撑按模块分配执行任务和统计覆盖 |
| 前置条件 | 必填 | 缺少前置状态，执行结果不可复现 |
| 操作步骤 | 必填 | 用例可执行的核心 |
| 预期结果 | 必填 | 判断通过与否的依据 |
| 优先级 | 必填 | 决定冒烟和回归的执行范围 |
| 关联需求 | 建议必填 | 需求变更时定位受影响用例；需求管理规范的团队应填 |
| 测试数据 | 按需 | 涉及具体输入值的用例填写，纯界面检查可省略 |
| 用例类型 | 按需 | 需要统计异常、边界覆盖比例时填写 |
| 设计方法 | 按需 | 评审覆盖度要求高的项目填写 |
| 维护人 | 按需 | 多人协作或长期维护的项目建议填写 |
| 版本 | 按需 | 用例频繁变更或需要审计时填写 |
| 备注 | 选填 | 记录特殊说明、已知限制 |
团队规模不同，取舍可以不同。三到五人的小团队，保留编号、标题、模块、前置条件、步骤、预期结果和优先级七个字段即可运转，测试数据直接写在步骤里也能接受。十人以上或需求变更频繁的团队，建议把关联需求、测试数据和维护人纳入必填，否则需求调整后很难快速圈出要改的用例。字段过多的代价体现在日常：每新增一个必填字段，每条用例都要多填一次，评审也要多检查一项，长期看会拖慢用例更新速度，最终导致模板被绕过。
完整填写示例：一条登录用例从空白到可用
下面用一条登录用例演示各字段的填写结果，内容与前面的空白模板逐项对应。
| 字段 | 填写内容 |
|---|---|
| 用例编号 | LOGIN-003 |
| 用例标题 | 已注册账号使用正确密码登录成功 |
| 所属模块 | 用户登录 |
| 关联需求 | REQ-102 账号登录功能 |
| 优先级 | 高 |
| 用例类型 | 功能（主流程） |
| 前置条件 | 系统中存在已注册且状态正常的账号 test01；登录页可正常访问 |
| 测试数据 | 账号：test01；密码：Abc12345 |
| 操作步骤 | 1. 打开登录页 2. 在账号输入框输入 test01 3. 在密码输入框输入 Abc12345 4. 点击“登录”按钮 |
| 预期结果 | 1. 登录页正常加载，显示账号、密码输入框和登录按钮 2. 账号输入框显示 test01 3. 密码输入框以掩码显示输入内容 4. 页面跳转到首页，右上角显示用户名 test01 |
| 设计方法 | 场景法（主流程） |
| 维护人 | 张明 |
| 版本 | V1.0 |
| 备注 | 密码错误、账号锁定等异常场景见 LOGIN-004 至 LOGIN-006 |
这条示例体现了三个填写要点。步骤与预期结果严格按序号对应，第 4 步点击登录对应第 4 条跳转结果，执行人逐步核对即可判断。测试数据单独列出，回归时替换账号密码就能复用步骤。备注中指向异常场景用例，说明主流程用例只验证正常路径，边界和异常由独立用例承担，避免一条用例塞入过多分支。
如果要补充异常场景，可以按同样结构再写一条：前置条件改为“账号 test01 已连续输错密码 4 次”，测试数据使用错误密码，预期结果写“提示密码错误，剩余尝试次数 1 次”。这样每条用例只验证一个判断点，失败时定位更直接。
模板的调整与长期维护方法
模板需要随项目演进调整，但调整应有触发条件和记录，避免每个项目各用一套、字段逐渐失控。以下检查清单可用于定期维护。
- 触发调整的条件：新增业务线导致模块划分变化、需求管理方式变更、评审中发现同类填写错误反复出现、团队规模明显变化。
- 版本记录：模板本身维护版本号和变更说明，写明改了哪个字段、为什么改、从哪个项目或时间点生效。
- 评审检查：用例评审时同步检查字段一致性，重点看标题是否可区分、步骤与预期是否对应、关联需求是否填写。
- 归档清理：需求下线或功能重构后，将对应用例标记为过期并归档，保留编号避免复用，定期清理长期未执行的用例。
模板落地到团队协作时，用例的编写、评审和执行往往分散在表格、文档和缺陷系统之间。ONES 支持以工作项承载测试用例，把用例编号、优先级、关联需求作为字段管理，评审意见和修改记录跟随用例留存，需求变更时也能从关联关系定位受影响用例。这样模板中的字段不必靠人工在多份文件间同步，评审通过的用例状态和版本有据可查。团队可以先用本文的空白表统一填写口径，再按协作需要把字段迁移到管理工具中。
常见问题
用例标题和操作步骤有什么区别，标题是不是可以随便写？
标题承担的是“快速识别”的作用，操作步骤承担的是“照着执行”的作用，两者不能互相替代。标题建议写成“场景+动作+预期”的一句话，例如“已注册账号使用正确密码登录成功”，让评审人和回归执行人扫一眼就能区分这条用例与同类用例的差别。操作步骤则要拆成逐步动作，每步一个动作、动词开头。如果标题只写“登录测试”，同一模块下多条登录用例就无法区分，评审时也难以判断覆盖了哪些场景。
测试数据一定要单独列一个字段吗，直接写在操作步骤里行不行？
两种做法都能执行，取舍取决于回归时是否需要换数据复用。测试数据单独成字段的好处是步骤保持稳定，回归时只替换账号、密码、金额等具体值，步骤描述不用改；数据散落在步骤里，换一组数据就要改多处文字，容易漏改。三到五人的小团队把测试数据写在步骤里可以接受，涉及多组输入值、需要反复回归的用例，建议单独列出。前置条件与测试数据也要分开：前置条件描述状态，例如账号已注册且未锁定；测试数据给出具体值，例如账号 test01、密码 Abc12345。
一条用例里能不能同时验证正常登录和密码错误两种情况？
不建议合并。一条用例只验证一个判断点，失败时才能直接定位是哪个环节出了问题。正常路径和异常路径的前置条件、测试数据、预期结果都不同，合并后步骤与预期结果的对应关系会变得混乱，执行人难以判断某一步失败究竟属于哪类缺陷。常见做法是主流程用例单独一条，异常场景按类型拆成独立用例，并在备注中互相指向，例如主流程用例备注“密码错误、账号锁定等异常场景见 LOGIN-004 至 LOGIN-006”。这样覆盖统计时也能按用例类型区分正常、边界和异常场景。
模板字段加得越多越规范吗，字段太多会有什么问题？
字段数量要跟使用成本平衡。每新增一个必填字段，每条用例都要多填一次，评审也要多检查一项；字段过多时，编写人容易敷衍填写或绕过模板，反而降低用例质量。建议先确定支撑执行、评审和追溯的最小字段集，再按项目需要增补：需求变更频繁的团队把关联需求纳入必填，需要统计异常和边界覆盖比例的项目填写用例类型和设计方法，多人长期维护的项目填写维护人和版本。字段取舍可以随团队规模调整，调整时同步更新模板版本和填写说明。
需求下线或功能重构后，原来的用例应该删除还是保留？
建议标记为过期并归档，保留用例编号，避免编号被复用造成追溯混乱。归档前确认关联需求已经下线或功能已经重构，并在备注中写明归档原因和替代用例的编号。定期清理长期未执行的用例，可以让用例库保持可读，回归时也不会误用旧用例。如果团队把用例放在管理工具中，归档状态和关联关系可以随用例一起留存，需求变更时更容易定位受影响的用例范围。
