一张图搞懂 7 种测试用例设计方法（建议收藏）

作者：楠风测开 | 5 年测试工程师 | 上海 本文 3000 字 | 阅读 8 分钟 | 建议收藏 ⭐

---

先说为什么

Day 1 我讲了测试工程师的 4 个阶段。今天落到第一个阶段——功能测试。

功能测试的核心基本功是什么？测试用例设计。

但很多测试工程师写用例时，凭感觉写。要么覆盖率不够，要么冗余用例一堆。

我自己也是从"凭感觉写"过来的。后来花了 3 个月，把 7 种测试用例设计方法系统学了一遍，再用这套方法重新设计用例，覆盖率从 60% 提升到 95%+。

今天这篇文章，把 7 种方法完整讲透。看完你会发现，写用例是有套路的。

---

一、写测试用例的 3 个常见误区

学方法之前，先看 3 个常见误区。我和很多测试工程师聊过，几乎都踩过。

误区 1：用例太多，效率太低

新人最常见的错误：把每个输入都写成一条用例。

举例：登录用户名长度限制 6-20 位，写 15 条（6、7、9、...、20）。

其实用等价类 + 边界值，3-5 条就够了。

误区 2：覆盖率不够，漏掉重要 bug

只测正常流程，忽略异常流程。

举例：电商下单只测成功路径，不测库存不足、支付失败、重复提交。

结果：上线后用户碰到异常场景，bug 频发。

误区 3：写完不复用，维护成本高

每次写一遍，没有沉淀成模板。

结果：同样的功能，下次又重新写一遍。

---

二、基础篇：最常用的 2 种

方法 1：等价类划分

原理：把输入域划分成若干等价类，从每个类中选少量代表性数据测试。

适用场景：输入数据有明确范围。

实战案例 1：登录用户名输入

有效等价类：
- 长度 6-20 位
- 字符：字母 + 数字 + 下划线
- 首字符必须是字母

无效等价类：
- 长度 < 6 或 > 20
- 包含特殊字符（@、#、! 等）
- 首字符是数字或下划线
- 为空 / 全空格

实战案例 2：登录密码输入

有效等价类：
- 长度 8-20 位
- 至少包含字母和数字

无效等价类：
- 长度不够
- 只有字母或只有数字
- 包含特殊字符（一般允许）

实战案例 3：年龄字段

有效等价类：1-150 之间的整数
无效等价类：0、负数、> 150、非整数、为空

总结：每类选 1-2 个数据，就能覆盖整类场景。新人最容易掌握的 1 种方法。

---

方法 2：边界值分析

原理：边界最容易出 bug，重点测试边界。

适用场景：输入有数值边界。

实战案例 1：年龄输入框

边界点：0、1、17、18、150、151
- 0：刚出生（无效）
- 1：1 岁
- 17：未成年（无效）
- 18：成年（有效）
- 150：极值（无效）
- 151：超过最大值（无效）

实战案例 2：订单金额

边界点：0.01、0.1、1、9999.99、10000、10000.01
- 0.01：最小有效金额
- 10000：满减门槛
- 10000.01：刚过满减

3 个核心概念：

上点：边界上的点（如 6、20）
离点：离边界最近的点（如 5、21）
内点：边界内的点（如 10）

3 个点都测，bug 基本跑不掉。

总结：和等价类经常搭配用，先等价类划分，再边界值细化。

---

三、进阶篇：实战最常用的 3 种

方法 3：场景法

原理：模拟用户真实使用场景。

适用场景：业务流程复杂。

实战案例：电商下单完整流程

主场景：登录 → 选商品 → 加购物车 → 支付 → 完成
支场景：
- 未登录状态点支付 → 跳转登录页
- 库存不足 → 提示并阻止下单
- 支付失败 → 订单保留，可重新支付
- 支付超时 → 订单自动取消
- 重复提交 → 防重机制
- 退款流程

4 个关键技巧：

1. 主流程必测，覆盖 80% 用户路径
2. 每个支流程写 1-2 个用例
3. 异常流程不能漏
4. 端到端测一遍，确保流程通畅

实战案例 2：ATM 取款

主场景：插卡 → 输入密码 → 选择取款 → 输入金额 → 取款 → 退卡
支场景：
- 密码输错 3 次 → 吞卡
- 余额不足 → 提示
- 金额超限 → 提示
- 取款机没钱 → 提示
- 操作超时 → 自动退卡

总结：业务流程类需求，场景法是首选。

---

方法 4：错误猜测法

原理：凭经验猜哪里会出 bug。

适用场景：补充测试。

8 个常见猜测点：

1. 输入为空 / 全空格
2. 输入超长（超过字段限制）
3. 输入特殊字符（@、#、%、SQL 注入字符）
4. 输入特殊值（负数、0、极值）
5. 网络中断 / 超时
6. 重复提交 / 重复点击
7. 并发操作（多人同时操作）
8. 异常数据（脏数据、测试数据残留）

核心心得：错误猜测不是瞎猜，是基于经验的"重点怀疑"。

新人怎么练：

1. 先做完正常用例
2. 回头看每个输入，列出可能的"恶意输入"
3. 用错误猜测法补充异常用例

总结：错误猜测是最难量化、最依赖经验的一种，但威力巨大。

---

方法 5：判定表法

原理：多条件组合时，用表格列出所有组合。

适用场景：输入条件多，且相互组合。

实战案例 1：保险理赔规则

条件：
- 是 VIP 客户
- 是工作日出险
- 损失金额 > 5000

动作：
- 优先理赔（VIP 优先）
- 24h 内处理（工作日 + VIP）
- 简化流程（损失大 + VIP）

条件组合（共 8 种）：

1. VIP + 工作日 + 大额 → 全部生效
2. VIP + 工作日 + 小额 → 优先 + 简化
3. VIP + 节假日 + 大额 → 优先
4. VIP + 节假日 + 小额 → 优先
5. 普通 + 工作日 + 大额 → 24h
6. 普通 + 工作日 + 小额 → 标准
7. 普通 + 节假日 + 大额 → 标准
8. 普通 + 节假日 + 小额 → 标准

实战案例 2：登录失败提示

条件：
- 用户名错
- 密码错
- 验证码错

动作：
- "用户名不存在"
- "密码错误"
- "验证码错误"

4 个条件就有 16 种情况。判定表能保证每种都覆盖。

总结：条件组合多的场景，判定表是必备工具。

---

四、高阶篇：复杂业务才用的 2 种

方法 6：因果图法

原理：把输入条件（因）和输出结果（果）画成图，找出依赖关系。

适用场景：复杂的输入输出关系。

实战案例：登录失败提示

因：
- 用户名错误
- 密码错误
- 验证码错误

果：
- "用户名不存在"
- "密码错误"
- "验证码错误"

因果图示例：

用户名错 → "用户名不存在"
密码错 → "密码错误"
验证码错 → "验证码错误"
（用户名错 + 密码错 → 只提示用户名错，因为先校验用户名）

总结：因果图适合排查"输入和输出有多重依赖"的场景。

---

方法 7：正交实验法

原理：从所有组合中挑有代表性的，用最少的用例覆盖最多的场景。

适用场景：参数配置类（多因素多水平）。

实战案例：浏览器兼容性

因素：浏览器（Chrome、Firefox、Safari）
水平：操作系统（Windows、Mac、iOS）

用正交表挑出代表性组合：
- Chrome + Windows
- Firefox + Mac
- Safari + iOS

3 个用例覆盖 9 种情况。

实战案例 2：APP 兼容性测试

因素：手机品牌（华为、小米、OPPO）
水平：系统版本（Android 10、11、12、13）

用正交表选 4 个组合，覆盖 12 种情况。

总结：因素多时，用正交实验能省一半以上用例。

---

五、一张图总结（决策树）

写测试用例的决策树：

有输入数据？
  ├─ 有范围 → 等价类 + 边界值 ⭐⭐⭐
  ├─ 无范围 → 错误猜测
  └─ 多条件 → 判定表 / 因果图

有业务流程？
  ├─ 简单流程 → 场景法 ⭐⭐⭐
  └─ 复杂流程 → 场景法 + 判定表

多参数组合？
  └─ 参数配置类 → 正交实验法

优先级：场景法 + 等价类 + 边界值，覆盖 80% 场景。

---

六、实战：登录功能完整用例设计

功能：用户登录系统

用 7 种方法设计用例：

① 等价类（用户名/密码长度、字符）
② 边界值（长度边界：0/6/20/21）
③ 场景法（正常登录、忘记密码、连续输错）
④ 错误猜测（SQL 注入、XSS、特殊字符）
⑤ 判定表（用户名错/密码错/验证码错 的组合）
⑥ 因果图（登录失败的提示原因）
⑦ 正交实验（浏览器+操作系统的组合）

结果展示（部分用例）：

用例编号	测试场景	预期结果
TC001	用户名密码正确	登录成功
TC002	用户名为空	提示"用户名不能为空"
TC003	密码为空	提示"密码不能为空"
TC004	用户名长度 5	提示"长度不够"
TC005	密码连续错 3 次	锁定账号
TC006	SQL 注入	系统安全
TC007	验证码错误	提示"验证码错误"
TC008	浏览器 Chrome	兼容
TC009	浏览器 Safari	兼容

结果：1 个登录功能，能写出 50+ 个高质量用例。

---

七、楠风的踩坑经验

我一开始写用例也是凭感觉。

3 个核心改变：

改变 1：写用例前先画流程图

拿到需求不直接写用例，先画业务流程图。

好处：流程清晰后，用例自然就全了。

改变 2：用 7 种方法交叉验证

写完用例后，用 7 种方法对照检查一遍。

好处：能发现自己没想到的场景。

改变 3：维护一份"用例模板库"

把每个高频功能的用例模板沉淀下来。

好处：下次类似功能直接复用，效率提升 3 倍。

我的真实数据：

学 7 种方法前：用例覆盖率 60%，漏测率 30%
学 7 种方法后：用例覆盖率 95%+，漏测率 < 5%

---

八、3 个月行动清单

如果你也想把用例写扎实，可以这样行动：

今天

□ 把当前负责的 1 个功能用 7 种方法重新设计用例
□ 对比你之前写的用例，看差距在哪
□ 列出至少 3 个你之前漏掉的场景

本周

□ 学 1 个测试用例设计方法（深度）
□ 在工作中找 1 个复杂功能练手
□ 整理 1 份你团队的"用例模板库"

90 天后

□ 能用 7 种方法应对任何功能
□ 写出的用例覆盖率达到 95%+
□ 成为团队用例评审的核心成员
□ 写一份"测试用例设计指南"分享给团队

---

九、写在最后

测试用例设计不是艺术，是工程。

7 种方法看似多，常用的就 3 种：场景法 + 等价类 + 边界值。

把基础打扎实，再学高阶，事半功倍。

希望这篇文章能帮你把用例写得更扎实。

---

评论区聊聊

你现在写用例用哪种方法最多？

有没有觉得不好用的场景？

我会尽量回复。

---

关于作者

楠风测开 | 5 年测试工程师 | 测试开发
做测试平台、写技术博客、分享成长路径

如果你想看更多我的内容，可以搜索楠风测开
或者关注我的同名账号

---

如果这篇文章对你有帮助：

1. 点赞 + 收藏（建议收藏，因为是工具型）
2. 评论区告诉我你常用哪种方法
3. 转发给同样写用例的同行

---

全文 3000 字 | 阅读 8 分钟 | 建议收藏

【原创声明】本文为楠风测开原创，转载请联系作者授权。