4. 测试用例设计方法论：等价类划分、边界值分析、状态转换测试、场景法在嵌入式中的应用
做嵌入式测试这些年，我最大的体会是：测试用例设计不是拍脑袋。你想想看，一个嵌入式系统可能有几十个输入参数、上百种状态组合，靠穷举法去测，项目周期根本不允许。
所以，我们需要一套系统化的方法。今天这章，我就把四种最实用的测试设计方法掰开揉碎了讲。它们分别是：等价类划分、边界值分析、状态转换测试和场景法。
核心观点： 嵌入式测试的用例设计，本质是用最少的用例覆盖最多的风险。这四种方法不是互斥的，实际项目中往往是组合使用。
4.1 等价类划分：把无限输入变成有限集合
等价类划分，说白了就是分组。把输入域分成若干组，每组里挑一个代表值来测。因为我们认为，同一组内的数据，程序处理逻辑是一样的。
举个例子。一个温度采集模块，要求输入范围是 -40°C 到 125°C。按照等价类划分，我们可以分成三组：
- 有效等价类： -40 到 125 之间的值（比如 25°C）
- 无效等价类（下限）： 小于 -40 的值（比如 -50°C）
- 无效等价类（上限）： 大于 125 的值（比如 150°C）
每组选一个值，三个用例就覆盖了所有可能性。我在项目中遇到过有人把每个整数都测一遍，结果测了 166 个用例，浪费了大量时间。其实没必要。
我的习惯： 做等价类划分时，先列所有输入条件，再画一张等价类表。有效类写左边，无效类写右边。这样一目了然。
4.2 边界值分析：Bug 最喜欢藏在边界上
等价类划分有个弱点——它不关注边界。而经验告诉我，80% 的嵌入式软件缺陷都发生在边界附近。为什么？因为程序员写条件判断时，最容易在 <= 和 < 之间犯错。
边界值分析就是专门对付这个的。它要求我们测试每个等价类的边界值，以及紧邻边界的值。
还是那个温度采集的例子。边界值分析要测的值是：
| 边界类型 | 测试值 | 说明 |
|---|---|---|
| 下边界 | -40 | 有效类的最小值 |
| 下边界-1 | -41 | 无效类，略低于下限 |
| 上边界 | 125 | 有效类的最大值 |
| 上边界+1 | 126 | 无效类，略高于上限 |
| 内点 | 0 | 有效类中间值（可选） |
我曾经在一个电机控制项目里，就因为没测边界值，导致电机在 0° 位置附近来回震荡。后来加上边界测试，问题立刻暴露了。
注意： 边界值分析不只看输入，还要看输出边界、存储边界、时间边界。比如定时器溢出、缓冲区满、队列空，这些都是边界。
4.3 状态转换测试：嵌入式系统的灵魂
嵌入式系统本质上是状态机。按键按下、传感器触发、通信超时……每个事件都会导致状态变化。状态转换测试就是专门验证这些状态跳转是否正确。
我习惯用状态转换图来设计用例。先画出所有状态，再标出触发事件和动作。然后，每个合法转换写一个用例，每个非法转换也写一个用例。
下面是一个简单的嵌入式系统状态转换图，我用 SVG 画出来，方便你理解。
从这张图里，我们可以提取出这些测试用例：
- 正常转换： 空闲→运行（启动指令）、运行→告警（超阈值）、告警→故障（持续超时）、故障→空闲（复位）
- 异常转换： 空闲→故障（看门狗超时）、运行→空闲（停止指令）
- 非法转换： 空闲→告警（不允许直接跳转）、故障→运行（不允许直接跳转）
我记得有一次做通信协议测试，状态转换图画了 12 个状态、30 多条转换线。按图索骥写用例，覆盖率直接拉到 95% 以上。没有这张图，根本理不清。
4.4 场景法：从用户视角出发
前面三种方法都是从技术角度出发。但嵌入式系统最终是要被人用的。场景法，就是模拟真实用户的操作流程。
我通常这样用场景法：
- 列出典型场景： 比如“正常开机→设置参数→启动运行→停止→关机”
- 列出异常场景： 比如“运行中突然断电→重新上电→系统恢复”
- 列出边界场景： 比如“连续运行 72 小时→观察内存泄漏”
- 列出并发场景： 比如“通信中断的同时传感器触发告警”
场景法的好处是贴近真实。等价类和边界值可能漏掉一些组合情况，但场景法能把这些组合串起来。
实战建议： 我一般先用等价类和边界值覆盖单点输入，再用状态转换覆盖状态跳转，最后用场景法覆盖完整业务流程。四者结合，基本没有死角。
4.5 四种方法的对比与选择
为了让你更清楚什么时候用哪种方法，我整理了一张对比表：
| 方法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 等价类划分 | 输入参数多、取值范围明确 | 用例数量少，效率高 | 不关注边界和组合 |
| 边界值分析 | 数值型输入、数组索引、时间参数 | 发现边界缺陷能力强 | 只关注边界，忽略内部逻辑 |
| 状态转换测试 | 状态机、协议栈、工作流 | 覆盖状态跳转完整 | 状态多时用例爆炸 |
| 场景法 | 用户操作流程、端到端测试 | 贴近真实使用，发现集成问题 | 场景设计依赖经验 |
避坑指南： 我曾经在一个项目里只用了等价类划分，结果漏掉了边界值问题，导致产品在高温环境下频繁重启。从那以后，我要求团队必须把等价类和边界值捆绑使用，缺一不可。
4.6 嵌入式环境下的特殊考虑
嵌入式测试和纯软件测试不一样。有几个点你要特别注意：
- 硬件依赖： 有些边界值在仿真环境里测不出来，必须上真实硬件。比如 ADC 采样值的边界抖动。
- 实时性： 状态转换测试要考虑时间因素。比如“5 秒内无响应则超时”，这个 5 秒就是边界。
- 资源限制： 等价类划分时，要考虑 RAM/ROM 的边界。比如缓冲区大小是 256 字节，那 255、256、257 就是边界值。
- 中断干扰： 场景法里要加入中断场景。比如“主循环正在处理数据，突然来了一个外部中断”。
嗯，这里要注意。嵌入式系统的测试用例，不能只看功能正确性，还要看时序正确性和资源正确性。这是很多新手容易忽略的。
我的习惯： 每设计完一组用例，我会问自己三个问题：
- 这个用例能跑在真实硬件上吗？
- 这个用例覆盖了最坏情况吗？
- 这个用例能重复执行且结果一致吗？
三个问题都回答“是”，我才放心把用例加到测试套件里。