第三章 测试用例设计原则：等价类划分、边界值分析、正交实验法、场景法
好，咱们进入第三章。这一章聊的是测试用例设计，说白了就是「怎么用最少的测试，发现最多的 bug」。
我见过不少工程师，一上来就拍脑袋写用例。结果呢？要么测了一堆重复的，要么漏掉了关键场景。量产阶段最怕这个——漏测一个边界条件，可能就是几千台产品返工。
所以，今天我把四个最实用的方法掰开揉碎了讲。每个方法我都会结合自己的踩坑经历，帮你避开那些「看起来简单、实际上容易翻车」的地方。
3.1 等价类划分：别做无用功
先问个问题：一个输入框接受 1-100 的整数，你要测多少个值？
有人会说「测 100 个」。没必要。你想想看，输入 5 和输入 6，程序走的是同一段逻辑。测一个就够了。
等价类划分的核心思想：把输入数据分成若干「等价类」，每个类里挑一个代表值来测。
我个人的习惯是，先画一张表：
| 输入条件 | 有效等价类 | 无效等价类 |
|---|---|---|
| 年龄（1-120） | 1 ≤ 年龄 ≤ 120 | 年龄 < 1，年龄 > 120 |
| 手机号（11位数字） | 11位纯数字 | 非数字、少于11位、多于11位 |
我在项目中遇到过一件事：一个温度传感器模块，设计范围是 -20°C 到 85°C。测试同事只测了 0°C、25°C、50°C，全是有效等价类。结果呢？产品在东北冬天直接死机。为什么？因为没测无效等价类——低于 -20°C 时，程序没有做异常处理。
3.2 边界值分析：bug 最爱藏在边缘
等价类划分解决了「测哪些类」的问题。但还不够。经验告诉我，程序在边界处最容易出问题。
为什么会这样？因为开发写代码时，经常用 if (x >= 1 && x <= 100) 这种判断。边界上的 >= 和 > 写错，是家常便饭。
边界值分析的原则：取每个等价类的边界值，以及边界两侧的值。
举个例子，输入范围 1-100：
- 上点：1 和 100（边界本身）
- 离点：0 和 101（边界两侧）
- 内点：50（中间随便一个值）
一共 5 个值，就能覆盖大部分边界问题。
我曾经吃过一次大亏。一个电源管理芯片，输出电压范围是 3.0V 到 5.5V。测试用例只测了 3.0V、4.2V、5.5V。结果量产时发现，3.0V 输出时纹波超标。为什么？因为代码里写的是 if (voltage > 3.0)，等于 3.0V 时走了另一条分支，那条分支根本没做滤波处理。
3.3 正交实验法：组合爆炸的克星
好，现在问题升级了。假设你的产品有 4 个参数，每个参数有 3 种取值。全组合测试需要 3^4 = 81 个用例。量产阶段哪有这个时间？
正交实验法就是用来解决这个问题的。它用最少的组合，覆盖最多的「两两组合」情况。
我拿一个实际案例来说。一个智能插座，需要测试：
- 电压：110V / 220V / 240V
- 频率：50Hz / 60Hz
- 负载类型：阻性 / 感性 / 容性
- 功率：100W / 500W / 1000W
全组合是 3×2×3×3 = 54 种。用正交表 L9(3^4)，只需要 9 个用例：
| 用例 | 电压 | 频率 | 负载类型 | 功率 |
|---|---|---|---|---|
| 1 | 110V | 50Hz | 阻性 | 100W |
| 2 | 110V | 60Hz | 感性 | 500W |
| 3 | 110V | 50Hz | 容性 | 1000W |
| 4 | 220V | 60Hz | 阻性 | 500W |
| 5 | 220V | 50Hz | 感性 | 1000W |
| 6 | 220V | 60Hz | 容性 | 100W |
| 7 | 240V | 50Hz | 阻性 | 1000W |
| 8 | 240V | 60Hz | 感性 | 100W |
| 9 | 240V | 50Hz | 容性 | 500W |
你看，54 个用例压缩到 9 个。而且任意两个参数的所有组合都覆盖到了。这就是正交实验法的威力。
3.4 场景法：从用户视角出发
前面三种方法，都是从「输入」角度出发。但用户不是这么用的。用户是按照「场景」来操作的。
场景法的核心：模拟用户真实的使用流程，从开始到结束，覆盖所有可能的路径。
我举个例子。一个智能门锁，用户的使用场景可能是：
- 正常场景：指纹开锁 → 开门 → 关门 → 自动上锁
- 异常场景：指纹识别失败 → 密码开锁 → 开门 → 关门
- 边界场景：连续 5 次指纹失败 → 锁定 3 分钟 → 等待后重试
- 并发场景：门锁正在开锁时，电量突然耗尽
每个场景，都要画出「基本流」和「备选流」。基本流是用户最常用的路径，备选流是各种异常和分支。
我记得有一次测试一款蓝牙耳机。功能测试全过了，但用户反馈说「打电话时经常断连」。后来用场景法一分析，发现问题出在「来电场景」——耳机在播放音乐时接到电话，蓝牙协议栈的优先级处理有 bug。这个场景在功能测试里根本没覆盖到。
3.5 四种方法的组合策略
好了，四种方法都讲完了。你可能会问：实际项目中怎么用？
我的做法是分三步：
- 先用场景法：梳理出用户的核心使用流程，确定「测什么」
- 再用等价类 + 边界值：对每个输入参数，划分等价类，提取边界值
- 最后用正交实验法：对多参数组合场景，用正交表压缩用例数量
举个例子。测试一个充电器：
- 场景法：正常充电、快充协议握手、过流保护、短路保护
- 等价类：输入电压（100-240V）、输出电流（0-3A）
- 边界值：输入 100V、240V、99V、241V；输出 0A、3A、-0.1A、3.1A
- 正交实验：输入电压 × 输出电流 × 负载类型 × 温度，用 L9 正交表
这样一套组合拳下来，测试覆盖率能到 95% 以上，用例数量却只有全组合的 1/10。