3、模型在环（MIL）原理：MIL测试目的、开环与闭环测试、测试用例设计方法

3.1 为什么需要MIL？——测试的“第一道防线”

模型在环，简称MIL。说白了，就是在你还没写一行代码、没焊一块板子之前，先用模型把算法跑一遍。

我刚开始做项目时，有个同事直接跳过MIL，从算法文档直接跳到代码实现。结果呢？集成测试时发现控制逻辑根本不对，回头改模型、改代码、重新验证，前后折腾了三周。嗯，从那以后，我们团队就把MIL当成了铁律。

MIL的核心目的其实就三个：

• 验证算法正确性——你的控制逻辑在数学上对不对？
• 发现早期缺陷——越早发现问题，修复成本越低。这个道理你想想看，跟盖房子一样，地基歪了，后面全白搭。
• 建立测试基准——MIL通过的结果，就是后续SIL、HIL的“参考答案”。

3.2 开环测试 vs 闭环测试

这两个概念，我见过不少新手搞混。其实区分起来很简单。

3.2.1 开环测试

开环测试，就是不给模型反馈。你给一个输入，看输出对不对。

举个例子：你测试一个PID控制器，开环测试就是给一个固定的目标值，看控制器输出的控制量是不是按照预期在变化。这时候，被控对象的模型是不参与反馈的。

开环测试适合什么场景？

• 测试单个模块的功能
• 验证信号处理逻辑
• 检查边界条件

3.2.2 闭环测试

闭环测试，就是把控制器模型和被控对象模型连起来，形成一个完整的反馈回路。

这才是MIL的精髓。你想想看，实际系统中控制器和物理对象是互相影响的。控制器输出控制量，被控对象状态变化，传感器反馈回来，控制器再调整输出。闭环测试就是模拟这个过程。

闭环测试能发现什么问题？

• 系统稳定性问题
• 响应速度是否达标
• 抗干扰能力
• 多变量耦合带来的异常

对比项	开环测试	闭环测试
测试对象	单个模块	完整系统
反馈路径	无	有
主要目的	功能验证	系统验证
测试效率	高	相对低
发现问题类型	逻辑错误、边界问题	稳定性、耦合问题

我的建议是：先开环，后闭环。开环把每个模块的“单兵作战能力”验证清楚，闭环再检验“团队配合”。

3.3 测试用例设计方法——实战经验分享

测试用例设计，说白了就是“怎么测才能把问题找出来”。我总结了四种最实用的方法。

3.3.1 等价类划分法

把输入域分成若干等价类，每个类里选一个代表值测试。

比如你测试一个车速信号处理模块，输入范围是0-200 km/h。你可以分成：

• 有效等价类：0-200
• 无效等价类：小于0，大于200
• 边界等价类：0，200

每个类选一个值测试就够了。为什么？因为同一个类里的值，模型处理逻辑是一样的。

3.3.2 边界值分析法

这个我特别强调。很多bug都出在边界上。

我记得有一次测试一个温度控制模型，正常工作范围是-40°C到125°C。边界值测试时，我特意测了-40.1°C和125.1°C。结果发现模型在-40.1°C时直接输出了NaN。嗯，这就是边界没处理好。

边界值分析的原则：

• 取边界值本身
• 取边界值+最小步长
• 取边界值-最小步长

3.3.3 场景法

场景法就是模拟真实工况。这个我最喜欢用，因为它最贴近实际。

比如测试一个自适应巡航控制模型，我会设计这些场景：

• 前车匀速行驶，自车跟随
• 前车急刹车
• 旁车突然切入
• 弯道中目标丢失

每个场景都是一个完整的故事线。你想想看，这种测试比单纯给几个固定输入值要有效得多。

3.3.4 随机测试法

这个作为补充手段。用随机生成的输入信号去跑模型，看会不会出现异常。

我一般会在模型开发后期做一轮随机测试，跑个几万步。有时候能发现一些意想不到的问题，比如某个状态组合下模型会卡死。

3.4 一个完整的MIL测试流程示例

说了这么多，我拿一个实际项目来串一下。

假设我们要测试一个电池管理系统（BMS）的SOC估算模型。

第一步：开环测试

给模型输入固定的电流值和电压值，检查SOC输出是否在合理范围内。比如输入10A放电电流，看SOC是否按预期下降。

第二步：边界测试

测试SOC接近0%和100%时的行为。我记得有一次测试发现，SOC到0%时模型没有触发低电量报警，这就是边界测试发现的。

第三步：闭环测试

把SOC估算模型和电池电化学模型连起来，跑一个完整的充放电循环。看SOC估算值和真实值之间的误差是否在允许范围内。

第四步：场景测试

模拟各种驾驶工况：城市拥堵、高速巡航、急加速急减速。看SOC估算在不同工况下的表现。

整个流程走下来，基本能保证模型的质量。后续的SIL和HIL，主要就是验证代码实现和硬件接口了。