软件测试用例模板怎么写：从用例设计到执行记录的全套指南
关键词：测试用例模板、用例设计、软件测试、测试计划、缺陷管理
测试用例写得怎么样，直接决定项目的质量底线。
一个写得好的测试用例，应该让任何一个拿到它的人------不管是不是原本人------都能按照步骤执行，得出明确的是否通过的结论。如果执行结果有歧义，说明用例本身写得不够清楚。
一、测试用例的标准结构
每个测试用例包含以下字段，缺一不可。
| 字段 | 说明 | 示例 |
|---|---|---|
| 用例编号 | 唯一标识，便于追溯 | TC-ORDER-001 |
| 所属模块 | 功能模块名称 | 订单模块 |
| 用例标题 | 一句话描述测试目标 | 正常下单流程验证 |
| 预置条件 | 执行前的系统状态 | 用户已登录，商品库存充足 |
| 测试步骤 | 逐步操作描述，每步独立可执行 | 见下方 |
| 预期结果 | 每步对应的正确输出 | 见下方 |
| 优先级 | P0/P1/P2 | P0 |
| 测试类型 | 功能/性能/安全/兼容 | 功能 |
| 用例属性 | 正向/逆向 | 正向 |
| 创建人/日期 | 追溯责任 | 张三 / 2026-11-06 |
| 执行结果 | 通过/失败/阻塞 | --- |
| 缺陷编号 | 失败时关联的 Bug ID | --- |
二、测试步骤和预期结果的写法
这是用例最核心的部分，也是最容易写模糊的部分。
错误写法：
步骤：输入用户名和密码，点击登录
预期：登录成功问题在哪？用户名是什么密码是什么？登录成功后跳到哪？这些都没有说清楚。执行的人只能凭自己的理解做，得出的结论不一定对。
正确写法：
步骤：
1. 打开登录页面 https://xxx.com/login
2. 在用户名输入框输入 "test_user_001"
3. 在密码输入框输入 "Test@1234"
4. 点击"登录"按钮
预期结果：
- 页面跳转至 https://xxx.com/dashboard
- 右上角显示用户名 "test_user_001"
- Cookie 中写入 session_id，有效期 2 小时
- 日志中出现 "User login success, user_id=test_user_001"每条预期结果都是可验证的。执行的人知道看哪个页面、找哪个元素、检查哪个日志。
三、用例设计方法
3.1 等价类划分
把输入数据分成若干等价类，每个等价类选一个代表值进行测试。
以"密码输入"为例：
- 有效等价类：8-20位，含大小写字母和数字 → 代表值：
Abc12345 - 无效等价类1：少于8位 → 代表值：
Ab123 - 无效等价类2：超过20位 → 代表值：
Abcdefghij12345678901 - 无效等价类3：不含数字 → 代表值：
Abcdefgh - 无效等价类4：含空格 → 代表值：
Abc 12345
每个等价类至少一个用例，无效等价类至少一个用例。这样覆盖最全面，用例数最少。
3.2 边界值分析
边界值是错误高发区，必须单独测试。
以"数量输入框（1-999）"为例：
- 边界值：0、1、2、998、999、1000
- 有效边界：1、999
- 无效边界：0、1000
边界值用例通常和等价类用例合并，不需要单独列出。
3.3 判定表
多条件组合的场景，用判定表梳理所有组合，避免遗漏。
以"优惠券使用条件"为例：
| 条件 | 是 | 否 |
|---|---|---|
| 用户等级 ≥ VIP3 | A | B |
| 订单金额 ≥ 100 | C | D |
| 商品参与满减 | E | F |
判定表：
| 用例 | A | B | C | D | E | F | 预期结果 |
|---|---|---|---|---|---|---|---|
| TC-001 | ✓ | --- | ✓ | --- | ✓ | --- | 优惠生效，减 20 元 |
| TC-002 | ✓ | --- | ✗ | --- | ✓ | --- | 优惠不生效，提示"金额不足" |
| TC-003 | ✗ | --- | ✓ | --- | ✓ | --- | 优惠不生效，提示"等级不足" |
| TC-004 | ✓ | --- | ✓ | --- | ✗ | --- | 优惠不生效，提示"商品不参与" |
| TC-005 | ✗ | --- | ✗ | --- | ✗ | --- | 优惠不生效，提示不满足任何条件 |
判定表的行数 = 条件数的 2 的 N 次方。条件多的时候会产生很多组合，实际应用中可以只覆盖"有意义"的组合，跳过明显不可能发生的组合。
3.4 状态迁移测试
涉及状态变化的功能，必须画出状态迁移图，覆盖所有合法迁移路径。
以订单状态为例：
pending_payment → paid → shipped → completed
↓ ↓ ↓
cancelled cancelled refunded
↓
refunded需要覆盖的用例：
- pending_payment → paid（正常支付）
- pending_payment → cancelled（超时未支付自动取消）
- pending_payment → cancelled（用户主动取消）
- paid → shipped（商家发货）
- paid → refunded（支付后退款）
- shipped → completed（确认收货）
- shipped → refunded（退货退款）
- completed → refunded（售后退款）
每个迁移路径至少一个用例。非法迁移也要覆盖------比如从 pending_payment 直接到 completed，系统应该拒绝并给出错误提示。
四、测试用例范例
以下以"用户注册功能"为例，展示完整的一套测试用例。
【模块：用户注册】
【测试范围：注册流程功能测试 + 性能测试 + 安全测试】
TC-USER-001 正常注册流程（P0）
预置条件：无
步骤：
1. 打开注册页面
2. 输入手机号 "13800138000"
3. 点击"获取验证码"
4. 输入验证码 "123456"
5. 输入密码 "Abc12345"
6. 输入确认密码 "Abc12345"
7. 勾选"同意用户协议"
8. 点击"注册"
预期结果：
- 注册成功，页面跳转至"完善信息"页
- 数据库新增一条用户记录，status="inactive"
- 发送激活邮件至绑定的邮箱（如有）
- 日志记录 "User registered, phone=138****8000"
TC-USER-002 手机号已注册（P0）
预置条件：手机号 "13800138000" 已注册
步骤：同 TC-USER-001
预期结果：
- 注册失败，返回错误码 E3001
- 页面提示"该手机号已注册，请直接登录"
- 数据库无新增记录
TC-USER-003 验证码错误（P0）
预置条件：手机号未注册
步骤：同 TC-USER-001，第 4 步输入验证码 "000000"
预期结果：
- 注册失败，返回错误码 E3002
- 页面提示"验证码错误，请重新输入"
TC-USER-004 验证码过期（P1）
预置条件：已获取验证码，等待 6 分钟后
步骤：同 TC-USER-001，第 4 步输入之前获取的验证码
预期结果：
- 注册失败，返回错误码 E3003
- 页面提示"验证码已过期，请重新获取"
TC-USER-005 密码强度不足（P1）
预置条件：手机号未注册
步骤：同 TC-USER-001，第 5 步输入密码 "12345678"
预期结果：
- 注册失败，返回错误码 E3004
- 页面提示"密码需含大小写字母和数字，至少 8 位"
TC-USER-006 两次密码不一致（P1）
预置条件：手机号未注册
步骤：同 TC-USER-001，第 5 步输入 "Abc12345"，第 6 步输入 "Abc12346"
预期结果：
- 注册失败，返回错误码 E3005
- 页面提示"两次输入的密码不一致"
TC-USER-007 手机号格式错误（P1）
预置条件：无
步骤：第 2 步输入 "1380013800"（10 位）
预期结果：
- 点击"获取验证码"时即时校验
- 返回错误码 E3006
- 页面提示"手机号格式不正确"
TC-USER-008 并发注册同一手机号（P0）
预置条件：手机号未注册
步骤：同时发起 10 次注册请求（相同手机号、不同验证码）
预期结果：
- 仅 1 次注册成功，其余 9 次返回 E3001
- 数据库仅有 1 条用户记录
- 不产生重复的激活邮件
TC-USER-009 SQL 注入攻击（P0）
预置条件：无
步骤：第 2 步输入手机号 "' OR '1'='1"
预期结果：
- 注册失败，返回错误码 E3006
- 页面提示"手机号格式不正确"
- 数据库无注入执行记录
- 安全日志记录攻击特征
TC-USER-010 注册接口性能测试（P1）
预置条件：压测环境，500 个未注册手机号
步骤：使用 JMeter 并发 100 个注册请求，持续 60 秒
预期结果：
- 成功率 ≥ 99%
- P99 响应时间 < 500ms
- 服务器 CPU 使用率 < 70%
- 内存使用无持续增长（无内存泄漏）这套用例覆盖了：正常流程、常见异常、边界值、并发场景、安全攻击、性能指标。每一个测试类型都有对应的用例。
五、测试用例的优先级划分
不是所有用例都一样重要。按优先级分组，可以合理安排测试资源。
| 优先级 | 定义 | 覆盖范围 | 执行时机 |
|---|---|---|---|
| P0 | 核心功能，阻断性缺陷 | 主流程、关键异常、安全 | 每次发布必测 |
| P1 | 重要功能，非阻断性 | 次流程、边界条件、兼容性 | 每个版本至少一轮 |
| P2 | 边缘场景，低概率 | 异常组合、极端边界 | 回归测试时覆盖 |
优先级的设定不是拍脑袋，而是基于：业务影响程度、缺陷发生概率、历史缺陷分布。P0 用例应该是那些"出了问题会导致用户无法使用核心功能"或者"会导致数据错误"的场景。
六、测试执行记录
用例写好了只是第一步，执行记录才是真正产出的质量保证。
执行记录包含以下字段：
| 字段 | 说明 |
|---|---|
| 执行日期 | 用例执行的具体日期 |
| 执行人 | 负责执行的测试人员 |
| 执行环境 | 测试环境 / 预发布环境 / 生产环境 |
| 执行结果 | Pass / Fail / Block / Skip |
| 缺陷编号 | 失败时关联的 Bug ID（如有） |
| 备注 | 补充说明，如环境异常、数据问题 |
执行结果的判定标准必须明确：
- Pass：所有预期结果均满足
- Fail：至少一项预期结果未满足
- Block：因环境问题无法执行（如测试账号不可用）
- Skip：因前置条件不满足跳过（不适用于当前版本）
七、测试用例设计的高频遗漏点
下面五个遗漏，每一个都造成过线上事故。
遗漏一：只测正常路径，不测异常路径。这是最常见的遗漏。用例写了一堆"输入正确的手机号、正确的密码、点击登录"，但没有"输入错误的手机号"、"输入错误的密码"、"网络中断时点击登录"。异常路径的覆盖度直接决定系统的健壮性。
遗漏二：不测并发场景。单用户操作没问题，一百个用户同时操作就出问题了。并发场景包括：并发注册同一手机号、并发下单同一商品、并发修改同一数据。这些场景在单线程测试中永远发现不了。
遗漏三：不测数据一致性。功能通过了，但数据不对。比如订单创建了但库存没有预占、支付成功了但订单状态没有更新。这类缺陷需要专门设计数据一致性验证用例。
遗漏四：不测性能场景。功能没问题，但慢了。性能用例不一定要每次都跑，但 P0 功能的性能基线必须建立。至少要知道"正常情况下的响应时间是多少"，否则出了问题不知道是变慢了还是本来就这么慢。
遗漏五：不测安全场景。SQL 注入、XSS、越权访问、敏感信息泄露------这些不是功能测试能发现的。安全用例需要专门设计，或者通过自动化安全扫描工具补充。
八、测试用例管理建议
第一，用例和缺陷联动。每个失败用例必须关联一个缺陷编号，每个缺陷必须有对应的用例来验证修复。没有用例关联的缺陷是"野缺陷"，修了等于没修。
第二，用例和版本联动。每次发版前，明确这个版本需要执行哪些用例。不要"全部重跑一遍"，那是不负责任的做法。要根据变更范围，精准选择需要回归的用例。
第三，用例持续迭代。用例不是一次写好的，是越用越完善的。每次发现新缺陷，回头检查是否有对应用例；没有的话，补上。用例库的完善是一个持续的过程。
第四，用例评审不能省。用例写完必须经过评审，评审人包括开发、产品、测试。评审的目的是发现遗漏和歧义。开发能发现"这个场景不会发生"，产品能发现"这个预期结果不对"，这些都是单靠测试人员想不到的。
九、自查清单
测试用例定稿前逐条对照：
覆盖度
- 每个功能需求条目至少有一个正向用例
- 每个功能需求条目至少有一个逆向用例
- 边界值场景已覆盖（最大、最小、略超范围）
- 并发场景已覆盖（如有必要）
- 数据一致性场景已覆盖
- 性能基线已建立（P0 功能）
- 安全场景已覆盖（注入、越权、敏感信息）
质量
- 每条用例的预置条件明确，执行前可以验证
- 每条用例的步骤清晰，任何人都能按步骤执行
- 每条用例的预期结果具体可验证，不是"应该成功"这种模糊描述
- 用例编号唯一，没有重复
- 用例优先级已标注，P0 用例数量合理（不应超过总数的 30%）
可追溯
- 每个用例可以追溯到对应的需求条目
- 每个缺陷可以追溯到对应的用例
- 用例变更记录完整，版本迭代有迹可循
测试用例是质量保障的第一道防线。防线筑得牢，上线后的心安程度就差很多。
如果你需要一份完整的测试用例模板（含用例设计方法和执行记录表），我整理成了标准文档，在文末的推广位可以取到，配合本文对照填会快很多。