3. CI与回归测试工程基础

在Stateflow控制软件的开发中，模型既是设计产物，也是可执行代码的来源。一个控制器模型可能包含几十个状态、上百条转移和大量嵌入式MATLAB函数，任何一次修改都可能影响换挡逻辑、故障降级或模式切换行为。如果没有一套自动化的集成与回归机制，团队很快会陷入“改一处、坏三处”的困境。本章围绕持续集成、持续交付、回归测试、测试金字塔和质量门禁五个基础概念展开，重点说明它们在Stateflow工程中的具体落地方式。

持续集成：每次提交都验证模型可构建、可测试

持续集成（Continuous Integration，CI）的核心不是“频繁提交”这个动作本身，而是每次提交后自动完成一次完整的构建与验证。在Stateflow项目中，一次典型的CI流水线包含以下环节：拉取模型与脚本、检查模型能否正常加载、执行模型编译（Update Diagram）、运行静态检查、执行单元级测试、生成覆盖率报告。只有这些环节全部通过，提交才被视为“可集成”。

实际工程中，CI通常由版本控制系统（如Git）的提交事件触发。以GitLab CI为例，可以在仓库根目录放置 .gitlab-ci.yml，用一段脚本调用MATLAB批处理模式：

stages:
  - build
  - test

model_check:
  stage: build
  script:
    - matlab -batch "cd('models'); load_system('ShiftController'); set_param('ShiftController','SimulationCommand','update'); save_system('ShiftController');"

unit_test:
  stage: test
  script:
    - matlab -batch "results = runtests('tests/unit'); assertSuccess(results);"

这段配置的含义是：第一阶段加载模型并执行一次Update Diagram，确认模型结构没有语法或连线错误；第二阶段运行单元测试目录下的所有测试用例，任何失败都会让流水线中断。需要注意的是，CI环境中的MATLAB版本、依赖工具箱和模型引用路径必须与开发环境一致，否则会出现“本地能跑、CI报错”的典型问题。

持续交付：从“能集成”到“可发布”

持续交付（Continuous Delivery）在CI的基础上增加了一层要求：每次通过验证的构建产物都应当处于可发布状态。对Stateflow控制软件而言，构建产物通常包括：生成的C代码、编译后的目标文件、标定数据文件（如A2L）、测试报告和覆盖率报告。持续交付并不等于每次提交都自动发布到整车，而是保证“如果需要，可以随时发布”。

实现持续交付的关键是产物版本化与可追溯。每次流水线运行都应记录：提交哈希、模型版本、MATLAB版本、测试通过率、覆盖率数值。这样当某个版本在台架或实车上出现问题时，可以快速定位到对应的模型状态和测试结果。在工程实践中，常用制品仓库（如Artifactory或GitLab Package Registry）保存这些产物，并在流水线中自动打标签。

回归测试：防止修改引入非预期行为

回归测试是CI中最核心的质量保障手段。它的目标不是验证新功能是否正确，而是确认原有功能没有被破坏。在Stateflow控制软件中，回归测试通常覆盖以下几类内容：状态迁移路径、转移条件优先级、默认转移与历史节点行为、嵌入式函数的数值输出、故障注入后的降级逻辑。

一个可执行的回归测试用例应当包含明确的输入、预期输出和判断依据。例如，针对换挡控制模型中的“升挡请求”逻辑，可以构造如下测试：

回归测试的基线可以来自需求文档、早期版本的手工验证结果，或经过评审确认的仿真数据。每次模型修改后，CI自动运行全部回归用例，并将结果与基线比对。如果某个用例的输出偏离基线，流水线应标记为失败，并输出差异详情，供开发者判断是“预期变更”还是“引入缺陷”。

测试金字塔：不同层级的测试如何分工

测试金字塔描述的是测试在不同粒度上的分布关系。在Stateflow控制软件中，可以将其映射为以下层级：

• 单元测试：针对单个状态、单条转移或单个嵌入式函数，验证其输入输出关系。数量最多，运行最快。
• 集成测试：验证多个状态或子状态机之间的交互，例如模式切换与故障降级之间的协同。
• 系统测试：在完整控制器模型或生成的代码上运行，验证端到端行为，如换挡全过程。
• 验收测试：在台架或实车环境验证，数量最少，成本最高。

金字塔的意义在于：越底层的测试应当越多、越快、越自动化。如果大量问题只能在系统测试或实车阶段发现，说明单元和集成测试覆盖不足，CI的反馈周期会变得很长。在Stateflow项目中，单元测试可以通过MATLAB Unit Test框架直接调用模型接口，集成测试则常借助Simulink Test或自定义脚本驱动多个模型实例。

质量门禁：让“通过”有明确标准

质量门禁（Quality Gate）是CI流水线中的判断条件。只有当所有门禁条件都满足时，代码或模型才允许合并到主干分支。在Stateflow控制软件中，常见的门禁条件包括：

• 模型编译通过：Update Diagram无错误，无未解析的引用。
• 回归测试通过率100%：所有基线用例输出与预期一致。
• 覆盖率达标：状态覆盖率和转移覆盖率不低于设定阈值，例如状态覆盖率≥90%，转移覆盖率≥85%。
• 静态检查无新增违规：MAAB或MISRA检查结果中，新增违规数为零。
• 基线比对通过：关键输出信号与基线数据的偏差在允许范围内。

门禁阈值不是一成不变的。在项目初期，覆盖率阈值可以适当降低，随着模型成熟逐步提高。重要的是，阈值必须写入流水线配置，而不是靠人工判断。例如，可以在CI脚本中读取覆盖率报告，用脚本判断是否达标：

cov = cvload('coverage/shift_controller.cvt');
stateCov = cov.stateCoverage;
if stateCov < 0.90
    error('状态覆盖率 %.1f%% 低于门禁阈值 90%%', stateCov*100);
end

当门禁失败时，流水线应输出明确的失败原因和定位信息，而不是只给出“失败”二字。开发者需要知道是哪个用例失败、哪个状态未覆盖、哪条静态检查违规，才能快速修复。

五个概念之间的关系

持续集成是机制，持续交付是目标，回归测试是手段，测试金字塔是策略，质量门禁是标准。五者共同构成一个闭环：每次提交触发CI，CI按照测试金字塔组织回归测试，测试结果与质量门禁比对，通过则进入可交付状态，不通过则阻断合并并反馈问题。对于Stateflow控制软件，这个闭环的价值在于：把模型行为的一致性从“人工确认”转变为“自动验证”，从而在频繁迭代中保持控制逻辑的可靠性与可追溯性。