3、测试用例设计误区：过度依赖边界值、忽略时序场景、等价类划分不完整
做MIL测试这些年，我见过最多的翻车现场，就是测试用例设计出了问题。说白了，很多人把MIL测试当成普通的单元测试来写，结果模型跑得挺欢，一集成到真实环境就崩。今天咱们就聊聊三个最常见的坑：边界值依赖症、时序场景失明症、等价类划分漏风症。
3.1 过度依赖边界值：你以为的边界，可能根本不是边界
我个人习惯，每次评审测试用例时，先看边界值覆盖得怎么样。但这里有个误区——很多人觉得只要把边界值测全了，测试就到位了。其实不然。
为什么边界值会失效？
你想想看，MIL测试的对象是模型，不是代码。模型里的逻辑往往有非线性特性，比如查表、插值、状态机跳转。边界值在代码里可能是个简单的if-else，但在模型里可能是个复杂的曲线拟合。我遇到过这样一个案例：一个油门控制模型，边界值设在了0%和100%，结果实际运行时，模型在85%附近出现了振荡——因为那个点刚好是查表插值的转折点。
核心问题：边界值测试假设系统在边界处行为突变，但模型中的非线性环节可能让突变发生在任意位置。
怎么破？
- 别只盯着输入边界，还要关注模型内部的“隐性边界”——比如查表节点、状态切换点、饱和限幅点
- 用等价类划分先圈定有效区域，再在区域内随机采样，而不是死磕边界
- 我建议：每个边界值至少配一个“边界附近”的测试点，比如边界值的±1%、±5%
避坑指南：我曾经在一个制动控制项目中，只测了0%和100%的制动踏板开度，结果模型在62%开度时因为查表插值算法导致输出跳变。后来我养成了习惯：每个查表节点都作为一个“伪边界”来测试。
3.2 忽略时序场景：模型跑得通，不代表时序没问题
这是MIL测试里最容易被忽视的坑。很多人写测试用例时，只关注“输入A -> 输出B”这种静态映射，完全不管时间维度。但模型是动态系统啊，时序错了，什么都白搭。
典型时序场景有哪些？
- 信号延迟：比如传感器信号经过滤波后，输出比输入晚了几个周期。你测稳态没问题，但瞬态响应就露馅了
- 状态机时序：状态切换需要满足时间条件，比如“保持3秒以上才切换”。你只测了状态值，没测时间条件
- 多速率系统：不同模块运行在不同周期下，比如10ms和100ms的模块交互。时序错位会导致数据不同步
我记得有一次，测试一个电池管理系统（BMS）的模型。所有静态测试都过了，边界值也覆盖了，结果一跑动态工况，SOC（荷电状态）估算值直接飞了。查了半天，发现是电流采样模块的滤波时间常数和SOC估算模块的更新周期不匹配——滤波后的电流信号滞后了3个周期，导致SOC估算用了过时的数据。
警告：时序场景不是“可选项”，而是MIL测试的必选项。如果你只做静态测试，那跟没测差不多。
怎么设计时序测试用例？
- 每个输入信号都要考虑“变化速率”——从0到1是瞬间跳变，还是斜坡上升？
- 状态机测试必须包含“时间条件”的验证，比如“保持状态X至少Y秒”
- 多速率系统要专门设计“跨速率交互”的测试用例，比如一个10ms的信号被100ms的模块读取
避坑指南：我曾经在测试一个电机控制模型时，忽略了PWM占空比更新时刻与电流采样时刻的时序关系。结果模型在仿真里一切正常，但实际硬件上电机抖动得厉害。后来我加了一条测试用例：在PWM更新前后各采样一次电流，对比差异。嗯，这个习惯我一直保留到现在。
3.3 等价类划分不完整：漏掉一个类，可能漏掉一个bug
等价类划分是测试设计的基础，但很多人划分得过于粗糙。比如一个输入范围是0~100，就简单分成[0,50]和[50,100]两个类。你想想看，这能覆盖什么？
等价类划分的常见遗漏：
- 遗漏无效等价类：比如输入范围是0~100，但模型可能对负值或大于100的值有默认处理。你不测，就不知道模型会不会崩溃
- 遗漏边界等价类：边界值本身就是一个独立的等价类，不能和内部区域混在一起
- 遗漏组合等价类：多个输入之间可能有耦合关系。比如油门和刹车同时踩，模型应该怎么处理？
- 遗漏时序等价类：同一个输入值，在不同时间点输入，结果可能不同。比如“急加速”和“缓加速”虽然最终油门开度一样，但中间过程完全不同
我个人的做法是：先列出所有输入变量，然后对每个变量做“三维划分”——数值维度、时间维度、组合维度。数值维度就是常规的等价类，时间维度考虑变化速率和持续时间，组合维度考虑多输入交互。
一个完整的等价类划分示例（以温度传感器输入为例）：
| 维度 | 等价类 | 说明 |
|---|---|---|
| 数值 | [-40, -20), [-20, 0), [0, 50], (50, 85], (85, 125] | 覆盖传感器量程及分段线性区间 |
| 数值 | <-40, >125 | 无效输入，测试模型鲁棒性 |
| 时间 | 阶跃变化、斜坡变化（1s内变化10°C）、缓慢变化（10s内变化1°C） | 覆盖不同动态响应 |
| 组合 | 温度+湿度同时变化、温度+压力同时变化 | 覆盖多输入耦合场景 |
怎么避免等价类遗漏？
- 先画输入变量的“全范围”，包括有效和无效区间
- 再根据模型逻辑，找出所有“行为分界点”——比如查表节点、阈值、饱和点
- 最后，每个分界点两侧各取一个值，再加上分界点本身
- 别忘了“空值”和“异常值”——比如信号丢失、通信超时
避坑指南：我曾经在一个ADAS（高级驾驶辅助系统）项目中，只划分了目标距离的等价类（远、中、近），完全没考虑目标类型（车辆、行人、自行车）和相对速度的组合。结果模型在“近距离+高相对速度+行人”的场景下直接误判。从那以后，我每次做等价类划分都会问自己一句：还有没有其他维度没考虑到？
小结
测试用例设计这事儿，说白了就是“想全了”。边界值要测，但不能只测边界值；时序场景要测，不能只做静态测试；等价类要分，但不能分得太粗。我见过太多项目，测试用例写得漂漂亮亮，覆盖率报告也好看，结果一上实车就出问题。为什么？因为测试用例根本没打到模型的痛点上。
嗯，记住这三条：别迷信边界值，别忽略时序，别漏掉等价类。下次写测试用例时，多问自己一句：这个场景，我是不是漏了什么？