进阶方法论：四大用例设计技法
各位好，我是老赵。今天咱们聊聊用例设计的进阶玩法。
说实话，光靠等价类和边界值，很多场景根本覆盖不全。我见过太多测试同学，拿着基础方法硬怼复杂业务，结果漏测率居高不下。为什么会这样？因为真实业务里，条件之间是有逻辑关系的，不是简单分个类就能搞定。
这一章，我把自己多年实战中沉淀的四种核心方法——判定表、因果图、正交实验、场景法，掰开揉碎了讲给你听。
核心观点：这四种方法不是互相替代的关系，而是互补的。判定表适合条件组合，因果图适合逻辑推导，正交实验适合参数爆炸，场景法适合业务流程。你想想看，一个复杂系统往往需要组合使用。
一、判定表法：条件组合的终极武器
判定表法，说白了就是穷举所有条件组合。我最早接触它是在做支付系统测试的时候，那会儿被各种优惠叠加逻辑搞得头大。后来发现，一张判定表就能把问题理得清清楚楚。
核心结构：
- 条件桩：列出所有输入条件
- 动作桩：列出所有可能的输出
- 条件项：每个条件的具体取值（Y/N）
- 动作项：对应组合下的预期结果
我的习惯：先画条件桩和动作桩，再填条件项。条件超过4个时，建议先合并等价类，否则表格会爆炸。我曾经见过有人把8个条件全列进去，结果生成了256条用例——其实很多是冗余的。
举个实际例子：电商订单取消规则
| 条件/动作 | 规则1 | 规则2 | 规则3 | 规则4 |
|---|---|---|---|---|
| 已付款？ | N | Y | Y | Y |
| 已发货？ | N | N | Y | Y |
| 已签收？ | N | N | N | Y |
| 允许取消 | ✅ | ✅ | ❌ | ❌ |
| 需退款 | ❌ | ✅ | ❌ | ❌ |
避坑指南：我曾经遇到过判定表里出现「不可能组合」的情况。比如「已签收=Y」但「已发货=N」，这在逻辑上不可能。一定要先做逻辑校验，剔除无效组合，否则用例会误导开发。
二、因果图法：从原因推导结果
因果图法和判定表法其实是孪生兄弟。区别在于：判定表直接列组合，因果图先画逻辑关系图，再转成判定表。
我个人习惯用因果图来处理那些「条件之间有依赖关系」的场景。比如：A成立时B必须成立，或者A和C不能同时为真。
基本符号：
- 恒等：原因出现，结果就出现
- 非：原因出现，结果不出现
- 或：多个原因中任意一个出现，结果就出现
- 与：多个原因同时出现，结果才出现
约束关系：
- E（互斥）：两个原因不能同时为真
- I（包含）：至少一个原因必须为真
- O（唯一）：有且仅有一个原因为真
- R（要求）：一个原因出现时，另一个必须出现
实战经验：我在做金融系统测试时，用因果图梳理过「风控规则引擎」。那里面有几十条规则互相嵌套，光看代码根本理不清。画完因果图后，发现有三条规则其实是冲突的——开发自己都没意识到。嗯，这就是因果图的价值。
三、正交实验法：用最少用例覆盖最多组合
正交实验法，说白了就是「用数学方法偷懒」。当参数太多，全组合测试不现实时，正交表能帮你用最少的用例覆盖最主要的组合。
核心概念：
- 因素：输入参数
- 水平：每个参数的取值个数
- 正交表：Ln(mk)，n=行数，m=水平数，k=因素数
举个例子：浏览器兼容性测试
- 因素：浏览器（Chrome/Firefox/Safari）、操作系统（Win/Mac/Linux）、分辨率（1080p/2K/4K）
- 全组合：3×3×3 = 27种
- 正交表L9(33)：只需9种
我的建议：别自己造正交表，直接用现成的。网上有正交表生成器，输入因素和水平数就能自动生成。我一般先用全组合算一下总数，如果超过20种，就考虑用正交法。
使用步骤：
- 确定因素和水平
- 选择合适的正交表
- 将因素映射到正交表列
- 生成测试用例
- 补充关键边界值
注意：正交实验法只能保证「两两组合」全覆盖，不能保证「三三组合」。如果业务逻辑涉及三个以上条件的强关联，建议改用判定表法。我曾经在接口测试中吃过这个亏——正交表跑过了，但三个参数同时取特定值时出了bug。
四、场景法：从用户视角出发
场景法，是我个人最喜欢的方法。因为它最贴近真实用户的使用习惯。你想想看，用户不会按照「先测等价类再测边界值」的顺序来操作，他们只会按照自己的业务流程走。
核心思路：
- 基本流：用户最常用的「happy path」
- 备选流：用户可能走的其他路径
- 异常流：出错、中断、异常情况
以电商下单为例：
| 场景类型 | 具体描述 | 覆盖要点 |
|---|---|---|
| 基本流 | 搜索→加购→下单→支付→收货 | 正常流程 |
| 备选流1 | 搜索→加购→下单→取消订单 | 中途取消 |
| 备选流2 | 搜索→加购→下单→支付失败→重试 | 支付异常 |
| 异常流 | 搜索→加购→下单→网络中断→恢复 | 网络异常 |
核心原则：场景法不是让你把所有路径都测一遍，而是让你识别出「用户最常走的路径」和「最容易出问题的路径」。我一般会先和产品经理聊，问清楚用户画像和使用场景，再画场景图。
五、四种方法的选型指南
说了这么多，你可能会问：到底什么时候用哪种方法？
我总结了一个简单的判断标准：
- 条件少（≤4个）且逻辑简单 → 判定表法
- 条件之间有复杂依赖关系 → 因果图法
- 参数多（≥5个）且水平数多 → 正交实验法
- 业务流程复杂，涉及多个步骤 → 场景法
最后说一句：别死磕方法论。我见过有人为了用正交法而用正交法，明明只有3个参数也要套正交表，结果用例反而少了。工具是为人服务的，不是反过来。灵活组合，才是高手之道。
好了，这四种方法就讲到这里。下一章咱们聊聊如何把这些方法落地到实际项目中，我会分享一些模板和工具。
可可精品资料库