第三章 需求分析与用例设计：需求可测性分析、等价类划分法、边界值分析法、决策表与因果图
好，咱们进入第三章。这一章，说白了就是教你「怎么把需求翻译成能测的用例」。
我见过太多测试新手，拿到需求文档就懵了。要么是需求写得像天书，要么是写出来的用例跑一遍就废。嗯，这里面的门道，我今天一次性给你讲透。
3.1 需求可测性分析：先别急着写用例
你想想看，如果需求本身就不清不楚，你写出来的用例能靠谱吗？
我个人习惯，拿到需求第一件事不是打开Excel，而是先做「可测性分析」。说白了，就是判断这个需求能不能被验证。
可测性三要素：
- 明确性：需求描述是否无歧义？比如「系统响应要快」——多快？3秒？1秒？
- 可观测性：测试结果能否被明确判断？比如「界面美观」——这个没法量化。
- 可控制性：测试环境能否复现需求场景？比如「当网络延迟超过500ms时」——你得能模拟这个延迟。
我在项目中遇到过最典型的反面教材：需求写着「系统应能处理大量并发用户」。大量是多少？100？1000？10000？后来我们拉着产品经理硬是把这个「大量」拆成了「1000用户同时在线，响应时间不超过2秒」。这才算可测。
避坑指南：
我曾经因为跳过可测性分析，直接写用例，结果发现需求里有个「自动适配」的模糊描述。测了三天，产品经理说「不是这个意思」。从那以后，我养成了习惯：先花30分钟和产品经理过一遍需求的可测性，再动笔。
3.2 等价类划分法：用最少的用例覆盖最多的场景
等价类划分，说白了就是「把输入数据分成几堆，每堆里挑一个代表测就行」。
为什么能这么干？因为同一堆里的数据，程序处理逻辑是一样的。你测了1和测了100，如果逻辑相同，那就是浪费时间。
我举个例子：一个年龄输入框，要求是18到60岁。
| 等价类 | 有效/无效 | 示例值 |
|---|---|---|
| 18-60之间的整数 | 有效 | 25, 30, 45 |
| 小于18的整数 | 无效 | 10, 17 |
| 大于60的整数 | 无效 | 61, 100 |
| 非整数（小数、字符、空值） | 无效 | 25.5, "abc", 空 |
你看，原本可能要测几十个值，现在4个等价类就搞定了。我个人习惯，每个等价类至少选一个代表值，但别只选一个——万一那个值恰好是边界呢？所以我会在等价类里再挑2-3个值，确保覆盖。
注意：
等价类划分不是万能的。如果输入之间有依赖关系（比如A和B必须同时满足某个条件），那就得用后面的决策表了。
3.3 边界值分析法：Bug最喜欢藏在边界上
你想想看，为什么边界值这么重要？因为程序员写代码时，最容易在「等于」「大于」「小于」这些判断条件上犯错。
我记得有一次，一个支付系统的折扣规则是「满100减10」。我测了99、100、101，结果发现100元时没触发折扣——代码里写的是「>100」而不是「>=100」。这就是典型的边界Bug。
边界值分析法的核心原则：
- 取上点（边界值本身）：比如18和60
- 取离点（紧邻边界的值）：比如17和19，59和61
- 取内点（边界范围内的任意值）：比如30
还是那个年龄输入框的例子，18-60岁：
| 边界 | 上点 | 离点 | 内点 |
|---|---|---|---|
| 下边界18 | 18 | 17, 19 | 30 |
| 上边界60 | 60 | 59, 61 | 30 |
这样一共只需要测7个值（17,18,19,30,59,60,61），就能覆盖所有边界场景。效率很高，对吧？
我的经验：
边界值分析一定要和等价类划分配合使用。先划等价类，再在等价类的边界上做文章。我曾经只做等价类没做边界值，结果漏了一个「等于0」的边界Bug，被客户投诉了。从那以后，这两个方法我从来都是一起用。
3.4 决策表与因果图：处理复杂逻辑的利器
当输入条件之间有逻辑关系时（比如「如果A且B，则C；如果A或B，则D」），等价类和边界值就不够用了。这时候需要决策表。
决策表的结构很简单：左边是条件桩和动作桩，右边是条件项和动作项。每个列代表一条测试规则。
举个例子：一个登录系统，规则是「如果用户名正确且密码正确，则登录成功；否则提示错误」。
| 条件/动作 | 规则1 | 规则2 | 规则3 | 规则4 |
|---|---|---|---|---|
| 用户名正确？ | Y | Y | N | N |
| 密码正确？ | Y | N | Y | N |
| 登录成功 | ✓ | |||
| 提示错误 | ✓ | ✓ | ✓ |
你看，4条规则就覆盖了所有组合。如果条件更多，规则数会指数增长（2的n次方）。这时候就需要因果图来帮忙了。
因果图，说白了就是决策表的图形化版本。它用「与」「或」「非」这些逻辑门把条件和结果连起来。我个人习惯，先画因果图理清逻辑关系，再转成决策表生成用例。
因果图的核心步骤：
- 列出所有输入条件（因）和输出结果（果）
- 用逻辑门连接条件和结果
- 标注约束关系（比如「互斥」「包含」）
- 根据因果图生成决策表
- 从决策表提取测试用例
我在项目中遇到过最复杂的因果图，是一个贷款审批系统，有8个条件、5个结果。画完因果图后，我生成了256条规则，但通过合并等价规则，最终只用了32条用例。这就是因果图的威力——帮你从逻辑上保证覆盖，同时还能优化用例数量。
注意：
因果图不是万能的。如果条件超过10个，建议先做条件筛选，把不重要的条件去掉。否则画出来的图连你自己都看不懂。
3.5 实战：把这些方法串起来
好，理论讲完了，咱们来点实际的。假设你要测试一个「订单折扣计算」功能：
- 订单金额在100-500元之间，打9折
- 订单金额在500元以上，打8折
- 会员额外享受9.5折（可叠加）
- 折扣后金额不能低于0元
我的做法是这样的：
- 先做可测性分析：确认「会员」的定义是否明确（比如是否区分等级），「可叠加」是否意味着先打折再会员折扣？
- 再用等价类划分：金额分成3个等价类（0-100, 100-500, 500以上），会员分成2个（是/否）
- 接着做边界值分析：取100和500这两个边界，加上它们的离点（99,101,499,501）
- 最后用决策表：处理金额和会员的组合逻辑
你看，这些方法不是孤立的，而是层层递进、互相补充的。我个人习惯，每个项目都按这个流程走一遍，基本不会漏测。
避坑指南：
我曾经在一个项目中，只用了等价类划分，没做边界值分析，结果漏掉了「金额刚好等于100元」的边界场景。那个Bug在生产环境被用户发现了，导致我们紧急发版修复。从那以后，我给自己定了个规矩：等价类和边界值，必须一起用。
好了，这一章的内容就到这里。下一章我们会讲测试用例的编写规范和评审流程。记住，用例设计不是一蹴而就的，需要反复迭代和优化。你想想看，如果一开始就设计出完美的用例，那还要测试执行干什么？