2. 测试环境搭建：Simulink/Stateflow环境配置、测试工具链选择、模型编译与部署

好，咱们进入正题。测试环境搭建这件事，说简单也简单，说复杂能让你折腾一整天。我刚开始做MIL测试那会儿，光配环境就花了两天——后来发现是版本不匹配。嗯，这里头有不少坑，我一个个给你说清楚。

2.1 Simulink/Stateflow环境配置

先说说Simulink和Stateflow的环境配置。说白了，就是让你的电脑能跑模型、能仿真、能看结果。

第一步：版本选择

我个人习惯用MATLAB R2020b以上的版本。为什么？因为从R2020b开始，Simulink Test和Simulink Coverage这两个工具箱集成得特别好。你想想看，如果版本太老，很多新功能用不了，还得自己写脚本，多麻烦。

这里有个避坑指南：千万不要用MATLAB R2018a之前的版本做MIL测试。我曾经在R2017b上折腾了一周，发现覆盖率分析功能缺失严重，最后不得不重装系统。血的教训啊。

第二步：必备工具箱

你需要安装以下工具箱：

• Simulink —— 核心环境，不用多说
• Stateflow —— 状态机建模必备
• Simulink Test —— 测试用例管理和执行
• Simulink Coverage —— 覆盖率分析
• Simulink Design Verifier —— 形式化验证（可选，但强烈推荐）
• Embedded Coder —— 代码生成（如果后续要做SIL/HIL）

第三步：环境变量设置

安装完成后，记得检查环境变量。我遇到过好几次，明明装好了工具箱，但Simulink就是找不到。后来发现是MATLABPATH没设置对。

2.2 测试工具链选择

工具链的选择，说白了就是选一个趁手的兵器。市面上主流的工具有TPT、Simulink Test，还有一些开源方案。我一个个给你分析。

方案一：Simulink Test（官方推荐）

这是MathWorks自家的测试工具，和Simulink无缝集成。我个人比较推荐这个，尤其是团队里大家都用MATLAB的情况下。

• 优点： 集成度高，不需要额外学习新工具；支持测试用例管理、自动执行、覆盖率分析一条龙
• 缺点： 需要额外购买license；对于复杂场景，脚本编写有点繁琐

方案二：TPT（专业测试工具）

TPT是PikeTec公司的产品，在汽车行业用得很多。我记得有一次做ADAS项目的MIL测试，客户指定要用TPT。说实话，上手有点难度，但用熟了之后确实强大。

• 优点： 支持多种测试类型（MIL/SIL/HIL）；测试用例设计灵活；报告生成功能强大
• 缺点： 价格不便宜；学习曲线陡峭；和Simulink的集成偶尔会有版本兼容问题

方案三：开源方案（MATLAB脚本 + Python）

如果你预算有限，或者团队规模小，可以考虑用MATLAB脚本配合Python做自动化测试。我曾经在一个小项目里这么干过，效果还不错。

% 一个简单的MIL测试脚本示例
% 加载模型
load_system('myModel');

% 设置输入信号
inputSignal = timeseries([0 1 0 1], [0 1 2 3]);

% 运行仿真
simOut = sim('myModel', 'SimulationMode', 'normal');

% 获取输出
outputSignal = simOut.get('output');

% 检查结果
if max(outputSignal.Data) > 0.5
    disp('测试通过');
else
    disp('测试失败');
end

工具链对比表

工具	集成度	学习成本	价格	适用场景
Simulink Test	高	低	中	中小型项目，团队统一使用MATLAB
TPT	中	高	高	大型项目，客户指定，复杂测试场景
开源方案	低	中	低	预算有限，团队有脚本开发能力

2.3 模型编译与部署

模型编译，说白了就是把你的Simulink模型变成可执行代码。这一步在MIL测试中其实不是必须的，但如果你后续要做SIL（软件在环）测试，那就绕不开。

编译流程

1. 检查模型配置： 打开Model Settings，确认求解器类型（固定步长还是变步长）、步长大小、仿真时间等参数
2. 生成代码： 使用Embedded Coder生成C代码。我个人习惯用slbuild命令，比图形界面快多了
3. 编译验证： 检查生成的代码是否能通过编译。我遇到过好几次，模型里用了不支持代码生成的模块，结果编译报错

% 模型编译命令示例
% 生成代码
slbuild('myModel');

% 如果只需要生成代码而不编译，可以用
slbuild('myModel', 'GenerateCodeOnly', true);

部署注意事项

部署到目标硬件时，有几个坑你得注意：

• 数据类型匹配： 模型里的double类型，到了嵌入式环境可能得改成single或者fixed-point。我曾经因为数据类型不匹配，导致仿真结果和实际运行结果差了十万八千里
• 内存限制： 嵌入式系统的内存通常很小。生成代码前，记得检查代码大小。我有个项目，生成的代码超过了目标芯片的Flash容量，最后不得不手动优化
• 实时性要求： MIL测试时我们通常不关心实时性，但部署到硬件后，代码的执行时间必须满足任务周期要求

部署后的验证

部署完成后，一定要做一次回归测试。我的做法是：

1. 把MIL测试的输入信号保存下来
2. 在目标硬件上运行同样的输入
3. 对比MIL测试结果和硬件运行结果

如果两者差异在允许范围内（通常1e-6以内），那说明部署成功。否则，就得回头检查模型或者代码生成配置了。

好了，测试环境搭建这部分就讲到这里。下一章我们聊聊测试用例设计——那才是MIL测试的重头戏。