1. Stateflow控制软件CI与回归测试工程导入
在汽车电子、航空航天、工业控制等领域，Stateflow 常被用于描述模式切换、故障降级、状态机仲裁、使能条件与安全监控等控制逻辑。与纯 Simulink 数据流模型不同，Stateflow 的核心语义是状态、迁移、事件、条件动作与并行层次，因此它的缺陷往往不是“算错了某个数”，而是“在某个事件顺序下进入了不该进入的状态”或“该退出的状态没有退出”。这类缺陷用一次性手工仿真很难覆盖，必须依靠持续集成（CI）与回归测试工程来稳定拦截。
本课程的目标不是单独讲 Stateflow 语法，也不是单独讲 Jenkins 或 GitLab CI，而是把两者接起来：让 Stateflow 控制软件从“本地能跑”走向“每次提交都能自动验证、可追溯、可回归、可度量”。学完本课程，你应当能够独立搭建一条面向 Stateflow 模型的 CI 流水线，并设计一套能真正发现状态机回归缺陷的测试集。
核心概念：四个必须分清的对象
在进入工具链之前，先明确四个概念，它们贯穿全课程：
- 模型单元（Model Under Test）：被验证的 Stateflow 图表及其宿主 Simulink 模型，通常以
.slx形式纳入版本管理。它是 CI 的“被测对象”。 - 测试用例（Test Case）：一组输入信号序列、事件触发序列、初始状态与期望输出/期望状态。对 Stateflow 而言，事件顺序本身就是测试数据的一部分。
- 回归基线（Baseline）：一组被认可的历史结果，包括输出信号、状态活跃序列、迁移覆盖记录等。回归测试的本质是“当前结果与基线的一致性判定”。
- CI 流水线（Pipeline）：从代码/模型提交触发，到检出、编译、仿真、判定、报告归档的自动化链路。它决定验证能否“每次提交都发生”。
整体框架：从模型到流水线的五层结构
本课程按“模型—测试—自动化—回归—度量”五层展开。下图给出整体框架与学习路径，它同时说明了各层之间的依赖方向：测试层依赖模型层的接口与状态可观测性，自动化层依赖测试层的可执行入口，回归层依赖自动化层产出的结果，度量层则反向驱动前三层持续改进。
学习路径：先建立可观测性，再谈自动化
很多团队一上来就搭 Jenkins，结果发现模型没有稳定的测试入口、状态无法观测、结果无法判定，流水线只能“跑通但没结论”。正确的顺序是：
- 先做模型可测性改造：把需要观测的状态、迁移、事件响应暴露为输出信号或日志，明确输入激励接口。没有可观测性，回归比对就无从谈起。
- 再设计测试用例：围绕状态迁移路径、事件优先级、并行状态冲突、超时与复位等场景构造用例，而不是只跑几条正常曲线。
- 然后接入 CI：把“批量仿真 + 结果判定”封装成可重复执行的脚本，由提交触发。
- 最后建立回归基线与度量：用基线锁定已认可行为，用覆盖率与通过率驱动测试集补强。
一个最小可运行的示例：从模型到判定
下面给出一个教学示例，用于说明本课程后续会反复使用的对象与参数。假设有一个 Stateflow 图表控制“电机使能”逻辑，包含 Idle、Ready、Running、Fault 四个状态，输入事件为 Enable、Start、Stop、FaultTrig，输出为 motorOn 与 stateCode。测试用例可以写成事件序列与期望状态序列：
用例 TC-001：正常启动
事件序列：Enable → Start
期望状态序列：Idle → Ready → Running
期望输出：motorOn 在 Running 后为 1，stateCode = 3
用例 TC-002：运行中故障
事件序列：Enable → Start → FaultTrig
期望状态序列：Idle → Ready → Running → Fault
期望输出：motorOn 在 Fault 后为 0，stateCode = 4
用例 TC-003：故障后复位
事件序列：Enable → Start → FaultTrig → Stop
期望状态序列：Idle → Ready → Running → Fault → Idle
期望输出：motorOn 保持 0，stateCode = 0在 CI 中，这些用例被批量执行，每条用例产出实际状态序列与输出序列，再与基线比对。判定规则示例：状态序列必须完全一致；motorOn 的跳变时刻允许 ±1 个仿真步长的容差；stateCode 必须精确一致。若某条用例失败，流水线立即标记为失败并归档差异报告。