1. 测试用例设计方法论：从需求到用例的完整链路
大家好，我是这次课程的主讲。在测试这个行当摸爬滚打了十几年，我见过太多「用例写了几百条，上线还是出问题」的案例。说白了，测试用例不是凑数量，而是用最少最精的用例，覆盖住最可能出问题的区域。
这一章，我们就把测试用例设计的几大核心方法掰开揉碎。你想想看，如果连用例都设计不好，后面的问题闭环根本无从谈起。
1.1 等价类划分：别在同一个坑里反复测试
等价类划分，是我个人习惯用的第一招。它的核心思想很简单：把输入数据分成若干「等价类」，每个类里挑一个代表测就行。
为什么能这么干？ 因为同一类里的数据，程序处理逻辑是一样的。你测了 18 岁，就没必要再测 19 岁——除非边界上有特殊逻辑。
- 有效等价类：符合需求、程序能正常处理的数据
- 无效等价类：不符合需求、程序应该拒绝或报错的数据
举个例子，一个年龄输入框，要求 1-120 岁整数：
| 类型 | 等价类 | 代表值 |
|---|---|---|
| 有效 | 1-120 之间的整数 | 25、60、1、120 |
| 无效 | 小于 1 的整数 | 0、-5 |
| 无效 | 大于 120 的整数 | 121、200 |
| 无效 | 非整数 | 3.14、abc、空 |
1.2 边界值分析：bug 最爱藏在边界上
边界值分析，说白了就是等价类划分的「黄金搭档」。为什么？因为程序员写代码时，最容易在边界条件上犯错——比如 if (age >= 18) 写成了 if (age > 18)，那 18 岁的人就被拒了。
边界值分析的核心： 取每个等价类的边界值及其相邻值。
还是年龄 1-120 的例子：
- 上点：1、120（边界本身）
- 离点：0、2、119、121（边界两侧最近的值）
- 内点：60（边界内的任意值）
1.3 因果图法：当多个条件互相影响时
因果图法，适合处理「多个输入条件组合决定一个输出结果」的场景。比如登录功能：用户名正确、密码正确、验证码正确，三个条件同时满足才能登录成功。
我个人习惯先画因果图，再转成判定表。步骤很简单：
- 列出所有输入条件（因）
- 列出所有输出结果（果）
- 画出条件之间的逻辑关系（与、或、非）
- 转成判定表，覆盖所有组合
举个例子，一个简单的登录判定：
| 用户名正确 | 密码正确 | 验证码正确 | 登录结果 |
|---|---|---|---|
| Y | Y | Y | 成功 |
| Y | Y | N | 失败 |
| Y | N | Y | 失败 |
| N | Y | Y | 失败 |
| ……（其余组合均为失败） | |||
1.4 正交实验法：用最少的组合覆盖最多的场景
正交实验法，说白了就是「用数学方法帮你偷懒」。当条件太多、组合爆炸时，正交表可以用最少的测试用例，覆盖两两组合之间的所有情况。
比如一个搜索功能，有 4 个条件，每个条件 3 个取值：
- 关键词：有、无、空
- 分类：全部、图书、电子
- 排序：相关、销量、价格
- 价格区间：0-50、50-100、100+
全组合要测 3⁴ = 81 种。用正交表 L9(3⁴)，9 条用例就够了。
- 条件数量 ≥ 3
- 每个条件的取值数量 ≥ 2
- 你不想测全组合（太费时间）
- 你也不确定哪些组合更重要
1.5 场景法：从用户视角出发
场景法，是我最推荐新手优先掌握的方法。因为它最贴近真实用户的使用方式。
核心思路： 模拟用户从开始到结束的完整操作流程。比如网购：搜索商品 → 加入购物车 → 下单 → 支付 → 查看订单状态。
场景法通常分两种：
- 基本流： 用户正常操作，一切顺利
- 备选流： 用户操作出错、中断、异常退出
举个例子，支付场景：
| 场景类型 | 操作路径 | 预期结果 |
|---|---|---|
| 基本流 | 余额充足 → 输入密码 → 支付成功 | 订单状态变为「已支付」 |
| 备选流 1 | 余额不足 → 提示充值 → 取消支付 | 订单状态不变 |
| 备选流 2 | 密码错误 3 次 → 锁定账户 | 提示账户已锁定 |
| 备选流 3 | 支付中网络中断 → 重试 → 支付成功 | 最终状态一致 |
1.6 如何从需求文档提取测试点
这是很多新人的痛点。拿到一份几十页的需求文档，不知道从哪里下手。我分享一个自己用了多年的「四步法」：
- 通读需求，标记功能点 —— 先别想测试，只搞清楚「系统要做什么」
- 识别输入输出 —— 每个功能点，输入是什么？输出是什么？
- 找出约束条件 —— 有没有限制？比如金额不能为负、时间不能早于今天
- 画出业务流程图 —— 把功能点串起来，看看数据怎么流转
举个例子，一个注册功能的需求文档：
- 功能点：用户注册
- 输入：手机号、验证码、密码、确认密码
- 输出：注册成功 / 失败提示
- 约束：手机号 11 位、密码 6-16 位、验证码 6 位数字、密码与确认密码一致
从这些信息里，你就能提取出测试点：
- 手机号：空、非 11 位、非数字、已注册、正确
- 验证码：空、错误、过期、正确
- 密码：空、小于 6 位、大于 16 位、特殊字符、正确
- 确认密码：与密码不一致、一致
- 组合场景：全部正确 → 成功；任一错误 → 失败
1.7 本章知识体系总览
下面这张图，把本章的核心方法、适用场景和它们之间的关系串起来了。你可以把它当作一张「测试用例设计方法速查表」。
1.8 本章小结
这一章我们讲了 5 种核心的测试用例设计方法，以及如何从需求文档提取测试点。你可能会问：「这么多方法，我到底该用哪个？」
我的建议是：别纠结，先用场景法把流程跑通，再用等价类 + 边界值把细节补全。 如果遇到多条件组合，再考虑因果图或正交法。方法是为目的服务的，不是用来炫技的。