1. 课程导入与测试思维建立

在开始学习 Simulink 控制模型测试之前，需要先建立一个基本认识：模型测试不是仿真跑通后的附加动作，而是贯穿模型开发全过程的验证活动。很多初学者习惯先建模、再仿真、最后看波形是否合理，这种方式只能算"观察"，不能算"测试"。真正的测试需要回答三个问题：被测对象是什么？期望行为是什么？实际行为与期望行为的偏差在哪里、有多大？

一、Simulink 控制模型测试的目标

Simulink 控制模型通常包含被控对象、控制器、传感器与执行机构接口、信号调理与调度逻辑等部分。测试的目标不是"证明模型没有错误"，而是以可重复、可追溯的方式暴露模型与需求之间的偏差。具体来说，测试要覆盖以下几类目标：

• 功能正确性：给定输入，模型输出是否符合控制需求，例如阶跃响应超调量、稳态误差、限幅逻辑是否生效。
• 接口一致性：模型端口的数据类型、采样时间、单位、量纲是否与上下游一致，避免出现单位混用或采样率不匹配。
• 边界与异常行为：输入饱和、除零、状态初值异常、模式切换抖动等情况下模型是否仍保持安全输出。
• 结构覆盖率：模型中的判断分支、状态机路径、查表区间是否被测试用例真正执行到。
• 需求可追溯性：每条测试用例对应哪条需求，测试结果能否反向支撑需求验证。

需要强调的是，覆盖率是手段而不是目的。达到 100% 判定覆盖率并不等于模型正确，但覆盖率低一定意味着存在未被验证的逻辑路径。测试思维的核心是：先明确"什么算通过"，再设计"如何触发"，最后判断"是否通过"。

二、V 模型中的验证位置

在典型的 V 模型开发流程中，左侧是设计分解，右侧是集成与验证。Simulink 控制模型测试并不是只在最右侧出现，而是分布在多个层级：

• 单元级（模型级）：对单个子系统或原子子系统做功能测试与覆盖率采集，验证其是否满足详细设计。
• 集成级：将控制器与被控对象、调度逻辑组合，验证接口与交互时序。
• 系统级：在完整闭环或硬件在环环境下验证整体控制性能与安全逻辑。
• 回归级：模型修改后重新执行已有测试集，确认没有引入新的偏差。

越早发现缺陷，修复成本越低。因此模型级测试应当在模型冻结前完成，而不是等到代码生成或台架试验阶段才补测。

三、测试与覆盖率验证的整体框架

一个可落地的 Simulink 模型测试框架通常包含五个环节：需求与测试意图 → 测试用例设计 → 测试执行与信号采集 → 覆盖率度量 → 结果判定与回归。下图给出了这一框架与 V 模型验证位置的对应关系，以及各环节之间的数据流。

图中左侧是设计分解，右侧是验证层级，中间是测试流程。可以看到，模型级测试对应详细设计与 Simulink 模型实现，是覆盖率验证的主战场；集成级和系统级测试则更关注接口与整体性能。测试用例设计不是凭空写输入，而是从需求中提取"可判定的期望行为"，再反推需要什么样的激励信号。

四、一个最小可执行的测试思维示例

假设有一个简单的 PI 控制器模型，需求为：给定阶跃参考 r=1，在 2 秒内稳态误差小于 2%，超调量不超过 10%。测试思维要求我们先把需求转成可判定的指标：

这四条用例分别对应功能正确性、边界行为和状态切换。执行后，除了看波形，还要打开覆盖率报告，确认限幅判断的"真/假"两个分支是否都被执行到。如果只测了 r=1，限幅分支可能永远为假，覆盖率报告会提示该判定未完全覆盖，这时就需要补充 r=5 的用例。

五、常见误区与纠正

• 误区一：仿真波形好看就算通过。纠正：波形只能说明某一次输入下输出合理，不能说明边界、异常和分支都被覆盖。
• 误区二：覆盖率越高越好，直接冲 100%。纠正：覆盖率要结合需求判断，未覆盖的分支如果确实不可达，应记录原因而不是强行构造无意义用例。
• 误区三：测试只在模型完成后做。纠正：模型级测试应与建模同步推进，需求变更时同步更新用例，避免回归时才发现用例失效。
• 误区四：只测控制器，不测被控对象接口。纠正：采样时间、数据类型、单位不一致往往在集成时才暴露，模型级就应检查端口属性。