K4-08 控制软件回归验证：基线与激励库、回归范围裁剪、自动执行与失败分诊
课程代码 K4-08 · 板块 K 控制、软件与标定 / 嵌入式软件与开发 时长 约 3.5~4.0 小时（5 讲）＋ 1 次实操 适合对象 热管理控制／嵌入式软件工程师、软件测试与验证工程师、HIL 台架责任人、标定工程师中负责回归排期的那一位；以及要在变更请求上签「需回归范围」那一栏的系统工程师。前提是你手上已经有一套在跑的 SIL/HIL 环境，问题不是「怎么搭」而是「每次改动之后跑多少、怎么判、失败了归谁」。 前置 K4-02 基于模型开发（MBD）：Simulink 建模与代码生成 基于模型开发（MBD）：Simulink 建模与代码生成；K4-03 MIL/SIL/HIL 验证流程 MIL/SIL/HIL 验证流程；K4-04 软件版本、配置与变量管理 软件版本、配置与变量管理；体系外前置（需自备）：版本控制与持续集成的基本概念——提交、分支、构建任务、流水线阶段、构建产物 本讲义定位 讲师授课蓝本 / 学员自学讲义，是本课题的完整展开版
按任务导航
| 你手上的事 | 直接看 | 还要配 |
|---|---|---|
| 要在变更请求上填「需回归范围」那一栏，没有依据 | 第 2 讲：三档裁剪表，逐格填「该档跑什么」 | 第 3 讲（台架时间预算反过来卡裁剪力度）· K4-04 软件版本、配置与变量管理（变更请求流程本体） |
| 手上一堆用例，说不清哪些算「基线」 | 第 1 讲：五件套一起定版，缺一件就判不了谁对 | 第 4 讲（模型漂移会触发基线重定版）· K4-04 软件版本、配置与变量管理（配置项纳管规则） |
| 夜间批越排越满，已经跑不完了 | 第 3 讲：台架时间预算式，先算上限再反推裁剪 | 第 5 讲（资产要能减，只加不减必然撑爆）· 第 2 讲（裁剪档位） |
| 早上拿到 40 条失败，不知道从哪儿看起 | 第 4 讲：三分类的判别证据、去向与超时升级 | 第 1 讲（模型漂移的正确出口是重定版，不是挂账） |
| 要写一份「过了才准放行」的出口清单 | 第 3 讲：四条合取式，逐条可自动核对 | K4-03 MIL/SIL/HIL 验证流程（覆盖率与 back-to-back 判定式本体） |
| 手上有一堆路试与车队回流数据，想变成用例 | 第 5 讲：五步加工链、入库门槛、回放三类判据 | K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算（车端采什么、怎么采）· 第 3 讲（场景覆盖率进哪一栏） |
| 需求改了，不知道哪些用例作废 | 第 5 讲：双向门闩与三类清理 | M1-04 需求管理与追溯（DOORS 等）（追溯矩阵工具与做法本体） |
⛔ 本课不覆盖：变更请求的提出—影响分析—评审—实施—验证—关闭流程本体，以及基线与配置项的纳管规则 → K4-04 软件版本、配置与变量管理（本课只出「需回归范围」那一栏的填写判据）；在环阶梯（RCP/MIL/SIL/PIL/HIL）各测什么、HIL 台架架构、用例设计三类方法与取点法、四类覆盖率的定义与分档、未覆盖项四条分流、back-to-back 判定式本体 → K4-03 MIL/SIL/HIL 验证流程（本课全程引用、⛔ 一条不重推）；模式状态机的静态完备性核对 → K4-05 模式状态机的完备性核对与可验证性设计；标定值本身的版本与追溯 → K6-05 标定数据管理与版本控制；HIL/SIL 台架当标定台架用（回归标定、自动寻优）→ K6-13 虚拟标定：把标定动作前移到 MIL/SIL/HIL、自动寻优与回归标定；建模、代码生成与定标 → K4-02 基于模型开发（MBD）：Simulink 建模与代码生成；诊断服务、故障码机制与描述文件内容 → K5-01 OBD/UDS 诊断与故障码（DTC）设计；需求条目化与规格交接 → K4-07 热管理控制功能规格（软件需求）的编写、评审与向 Tier1 交接；追溯矩阵的工具与通用做法 → M1-04 需求管理与追溯（DOORS 等）；「谁判影响面、判到什么粒度」这一层管理原则 → B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件 B1-05 基于 V 模型的热管理正向开发流程；仿真模型作为设计资产的建库、版本与不确定度量化 → J7-06 仿真不确定度量化（UQ）与稳健/可靠性设计：从确定性单点到带分布的裕度；台架工况序列与数采信号链的自动化 → L7-02 数据采集、台架搭建与自动化测试；车端采什么信号、多高频率、什么事件抓帧、上行带宽与存储预算 → K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算；发布门禁之后的一切——灰度放量比例、回滚门限、车队样本量与统计显著性、影子模式、孪生结果推送 → K7-02 软件定义热管理与 OTA 迭代 K7-03 数据驱动的能效自学习控制 N6-02 整车热管理数字孪生与在线优化。
引言：回归验证是一条以「一次变更」为被测对象的动态机制
K4-03 MIL/SIL/HIL 验证流程 交出的是一张静态的排布表：MIL 测什么、SIL 测什么、PIL 与 HIL 各能抓到哪一类问题，出口判据各是什么。那门课的被测对象是各关本身——它回答「这一关做完，你能说什么」。
本课的被测对象换了一样东西：一次变更。同一套在环设施，同一批用例，问题变成——有人改了一行代码、或者改了一个标定量、或者动了一个信号的数据类型，接下来这一次要跑什么、跑多久、谁来判、判不了怎么办。这是一条动态机制，它每天要被触发很多次，因此它的每一格都必须能被自动执行、能被机器核对，否则它撑不过第三周。
钉子①：回归报告与首次验证报告的唯一实质区别，是那份「与上一版的差异清单」
一份回归报告如果只写了「跑了多少条、过了多少条、覆盖率多少」，它和一份首次验证报告长得一模一样，而它回答不了回归真正被问的那个问题：这一版相对上一版，行为变了哪些、变的是不是我们打算变的那些。
⇒ 差异清单不是报告的附录，它是回归报告的主体。本课第 3 讲会把它写进报告的最小内容集；第 1 讲之所以要死死钉住「基线要定版」，正是因为没有可比对的前一版，差异清单根本写不出来。
钉子②：回归自动化的真瓶颈不是「跑多少」，是「判多少」
把用例跑起来这件事，机器可以线性扩张——加机器就能多跑。但失败清单是人在读的：跑得越多，失败越多，而人一个早上能分诊的条数是个常数量级。
⇒ 于是有一条反直觉的结论：无限制地扩大自动执行规模，会让整条回归线失效，因为它产出的失败清单超过了分诊能力，人就开始批量标「已知失败」——那一刻这条线就变成了摆设。本课第 2 讲的裁剪、第 3 讲的时间预算、第 4 讲的超时升级、第 5 讲的资产清理，四件事服务的是同一个目标：把失败清单压在人能判完的量级内。
钉子③：动态回归对「这条规则从来没被写进表」是原理性无能
这一条是从 K4-03 MIL/SIL/HIL 验证流程 那条上限直接继承下来的，本课再钉一次，因为它决定了本课的射程上限：一条从没被写下来的规则，不会在任何一条用例上失败——它不产生失败，它产生沉默。⇒ 无论你把回归范围裁得多准、跑得多全，这类问题都不会被它抓到，它必须由 K4-05 模式状态机的完备性核对与可验证性设计 的静态完备性核对前置拦截。两者双管齐下、⛔ 互不替代。
本课的符号约定：与 K4-03 MIL/SIL/HIL 验证流程 完全对齐，只新增台架排期这一族
本课涉及的量分两族。第一族全部沿用 K4-03 MIL/SIL/HIL 验证流程 的约定，⛔ 本课不改一个字母：
| 符号 | 含义 | 本课怎么用 |
|---|---|---|
| Δ | back-to-back 偏差，＝ |y_code − y_model| | 只在出口判据里引用，⛔ 判定式本身不重推 |
| ε_cont / ε_disc / ε_time | 按信号类别分的三档通过阈值 | 本课补的是「回归里这三档分别放进哪一栏」 |
| Δt_HIL | HIL 被控对象模型的仿真步长 | ⛔ 不简写成 Δt，它与本课的时长量量纲不同 |
| C_req | 需求覆盖率，＝ N_req,cov / N_req | 出口判据第一条的左半 |
| C_struct（带档位下标 stmt / branch / mcdc） | 结构覆盖率 | 出口判据第一条的右半，⛔ 报数必带档位 |
| C_scen | 场景覆盖率 | 第 5 讲的回放用例算进它的分子 |
第二族是本课首次定义的，全是台架排期侧的时间与比例量——K4-03 MIL/SIL/HIL 验证流程 与 K4-04 软件版本、配置与变量管理 都没有定义过它们，本课首定并把口径写足：
| 符号 | 含义 | 单位 | 口径要点 |
|---|---|---|---|
| t_win | 一个夜间批可用的窗口时长 | h | 从最后一个人离开台架到第二天第一个人要用台架之间的那一段，⛔ 不是 24 h 减去白班 |
| A_bench | 台架可用率 | 无量纲 | 分子＝台架实际产出有效用例结果的时长，分母＝t_win。⛔ 分母不含白班占用，⛔ 与设备综合效率不是同一个量 |
| t_run | 单条用例的平均在环时长 | min | 只含用例本体，⛔ 不含前后回稳 |
| t_settle | 单条用例前后的回稳与复位时长 | min | 热管理特有的那一项，含把水温与电池温度拉回起点 |
| N_night | 一晚能跑的条数上限 | 条 | 由上面四个量算出来，是上限不是计划值 |
⚠ 单位在本课统一：时长量一律用小写 t 或 T 开头并写明单位，⛔ 不与 K4-03 MIL/SIL/HIL 验证流程 的 T_task（控制任务周期，ECU 侧）混用——那是 ECU 时钟域的量，本课的 t_win / t_run / t_settle 全是挂钟时间（台架排期侧），两族⛔ 不得相加、⛔ 不得直接比大小。
本课的量该怎么取：三类量三种给法，先在这里说清
本课出现的数字只有三类，读到任何一个数之前先认清它属于哪一类：
- 结构与判据本身（五件套是哪五件、三档裁剪是哪三档、分诊是哪三类、加工链是哪五步）——这一类与平台无关，可以直接照抄去用，本课把它写足；
- K4-03 MIL/SIL/HIL 验证流程 已声明不给数的那一族（ε 的取值、覆盖率的出口目标档位、RTF 工程裕量、Δt_HIL 取值）——⛔ 本课同样一个数都不给，理由与那门课一致：它们由本项目的验证策略与你手上那版标准给出。本课给的是它们在回归出口清单里占哪一栏、要带哪些声明；
- 台架排期侧的平台相关量（t_win、A_bench、t_run、t_settle、冒烟批总时长上限、全量周期、分诊时限）——这一类本课给典型参考区间与常见值锚点，并在每处附免责说明与获取路径。⚠ 一律是典型值，⛔ 不是验收依据，须以你自己台架的实测为准。
第 1 讲 回归基线与激励库：先定「拿什么跑」，再谈跑多少
绝大多数「回归跑不起来」的项目，卡的不是自动化工具，是说不清基线是什么。表现是这样一句对话：同一份用例，昨天在 A 台架过了，今天在 B 台架挂了，两边各执一词，最后谁也证明不了自己那边是对的。⇒ 这不是台架问题，是基线没有定形——被比较的那两次，有一件以上的东西不一样，而没有人记录它。
1.1 一次回归的基线是五件套一起定版，⛔ 不是「一堆用例」
是什么。一次回归基线的完整交付物有五件，缺任何一件，两次执行结果不一致时都无法判定谁对：
| # | 件 | 具体内容 | 缺了它会怎样 |
|---|---|---|---|
| ① | 激励库 | 输入时序与场景序列本体：各路信号的时间序列、场景之间的衔接与驻留 | 两次跑的输入不同，比出来的差异毫无意义 |
| ② | 期望输出或判据阈值 | 每条用例判「过没过」的那个东西：期望曲线、门限、迟滞带、判定表 | 「过了」这个结论没有依据，靠人看曲线 |
| ③ | 被控对象实时模型及其参数集 | 模型版本 + 那一套参数值 + Δt_HIL（取值口径见 K4-03 MIL/SIL/HIL 验证流程） | 两台台架跑出两种动态，第 4 讲的「模型漂移」根本分不出来 |
| ④ | 工具链与台架配置版本 | 代码生成器、编译器、静态分析工具、台架板卡与固件、实时机镜像 | 换了编译器之后出现的新失败，会被误判成软件缺陷 |
| ⑤ | 用例到需求条目的追溯链 | 每条用例指向哪一条（或哪几条）需求条目，且是双向的 | C_req 的分子算不出来；需求改了也不知道哪些用例作废 |
⚠ 这五件套本身属于 K4-04 软件版本、配置与变量管理 的配置项——它们怎么纳管、怎么进基线、基线怎么冻结，那门课已经讲透，⛔ 本课不重讲。本课只定「回归专用的那一份」的内容与粒度，也就是上面这张表本身。
为什么必须五件一起定版，⛔ 不能只定用例。因为回归的结论形式是一个比较句：「相对上一版，行为变了 / 没变」。比较句要成立，两次执行之间只允许有一个变量——被测软件。剩下四件只要有一件悄悄变了，那个「变了」的结论就同时有两种解释，而报告上它们长得一模一样。
⇒ 一个可以今天就用的判据：拿起一份回归报告，问它「这次跑的五件套各是哪一版」。答不全的那一份，它的结论不能当放行依据用。
1.2 激励库按 K4-03 MIL/SIL/HIL 验证流程 的用例四类分层建，分层是为了第 3 讲能从这里抽子集
是什么。激励库不是一个平铺的用例列表，它必须按层组织。层的划分直接沿用 K4-03 MIL/SIL/HIL 验证流程 的用例四类，⛔ 本课不另立分类：
| 层 | 内容 | 热管理里的典型样子 |
|---|---|---|
| L1 正常工况 | 典型循环下的常规动作 | 制冷模式下压缩机启停、多通阀在常见模式之间切换、水泵按需求调速 |
| L2 边界工况 | 门限附近、迟滞带内、驻留时间恰差一拍 | 电池请求冷却的门限 ± 一个传感器分辨率；恰好落在迟滞带内的温度；模式驻留时间比最小驻留少一个控制周期 |
| L3 故障注入 | 传感器与执行器失效 | 水温传感器开路 / 短路 / 卡值；多通阀反馈丢失；压缩机通信超时 |
| L4 无故障的纯资源竞争 | 没有任何部件坏，但多个请求同时到 | 快充请求电池冷却的同时座舱请求最大制冷，压缩机能力不够分 |
⚠ L4 是 K4-03 MIL/SIL/HIL 验证流程 已经并列出来的第四类，本课特别提一句是因为它最容易在回归里被漏掉：它不像 L3 那样有明确的注入动作，它要求把两条请求在时间上对齐，构造成本高，于是第一版激励库常常只有 L1~L3。
为什么分层不是分类癖。分层的用途在第 3 讲兑现：冒烟子集从哪一层抽、夜间全量跑到哪一层，是按层裁的。如果激励库是平铺的，裁剪时就只能按「感觉哪些重要」挑，而那个判据写不进流水线的配置文件。
1.3 「黄金数据集」指的是期望输出，来源只有三条且可信度差着量级
是什么。日常说的「黄金数据集」，指的是五件套里的第 ② 件——那份被认定为正确的期望输出。它的来源只有三条：
| 来源 | 强度 | 它能证明什么 | 它证明不了什么 |
|---|---|---|---|
| ① 需求条目直接给出的判据 | 最强 | 「行为符合需求」 | 需求本身对不对（那是评审与 K4-07 热管理控制功能规格（软件需求）的编写、评审与向 Tier1 交接 的事） |
| ② 上一版已放行基线的实测输出 | 次之 | 「相对上一版没变坏」 | ⛔ 证不了「本来就是对的」——上一版若有缺陷，它把缺陷一起固化了 |
| ③ 模型侧 MIL 输出 | 最弱 | 「代码没有偏离模型」 | ⛔ 证不了模型对不对；仅适用于 back-to-back 类比较 |
为什么必须逐条标来源。三种混用而不标来源，是「回归全绿但功能是错的」这个现象最常见的成因。机制是这样：一条用例的期望输出来自来源 ②，而上一版在那一处本来就有缺陷 ⇒ 这条用例把缺陷写成了期望 ⇒ 以后任何一次把它改对的修复，都会让这条用例失败，于是修复被判成「引入了回归」而退回。⚠ 这个方向的错最难被发现，因为它在报告上表现为「回归拦住了一个缺陷」，看起来是这条线在正常工作。
⇒ 落地做法：期望输出这一列，旁边永远配一列「来源」，取值只有上面三档。凡是来源为 ② 或 ③ 的条目，其失败在第 4 讲分诊时不得直接判为真缺陷，必须先回到需求确认期望本身对不对。
1.4 组合场景必须显式枚举进基线，⛔ 不能靠随机工况碰上
是什么。K4-03 MIL/SIL/HIL 验证流程 点名过一类场景：快充 + 严寒 + 除霜三者叠加。这类组合的特点是——单看每一项都在正常范围内，叠加之后能力才不够分，而它们在真实路谱上出现的频次很低。
为什么不能靠随机工况碰。组合空间是乘法增长的：若有 6 个维度、每个维度 3 档，全组合是 729 种，而一晚能跑的条数（第 3 讲会算）是两位数量级。⇒ 靠随机采样命中一个特定三元组合的概率低到不能作为机制依赖。
正确做法：先用等价类划分把每个维度落成有限几档，再用成对（两两）覆盖把组合空间压成一份清单，然后把清单里被判为必须常驻的那些显式写进基线。⚠ 组合空间的取点方法本身归 K4-03 MIL/SIL/HIL 验证流程（那门课的用例设计一节讲了等价类、边界值与判定表压缩），⛔ 本课不重讲；本课只判一件事：哪些组合必须常驻回归基线。判据三条，满足任一条即入：
- ① 该组合曾经暴露过一个真缺陷（第 4 讲分诊结论为真缺陷的，其用例永久进基线，这是缺陷回归位）；
- ② 该组合是某条安全相关需求的唯一验证场景；
- ③ 该组合处在两条控制逻辑的仲裁边界上——也就是两个子系统争同一个能力的那些点。
1.5 定版时点与需求冻结点绑定，变更评审通过即进入「待更新」
是什么。回归基线的生命周期与需求基线是咬合的，共三个状态：
| 状态 | 触发 | 这个状态下能不能当放行依据 |
|---|---|---|
| 已冻结 | 需求基线冻结 ⇒ 回归基线随之冻结，打同一个标识 | 能 |
| 待更新 | 变更评审通过 ⇒ 立即进入此状态 | ⛔ 不能——它已经与现行需求不一致了 |
| 已更新并重新冻结 | 五件套按变更结论改完、复核完 | 能 |
⚠ 中间那个「待更新」状态是本课要求显式建立的：没有它，基线在「需求已改、用例还没改」的那段窗口里看起来仍然有效，而这段窗口恰恰是最容易出事的时候——那时跑出来的绿灯，证明的是「符合旧需求」。
本讲不重讲的那一层。「谁判影响面、判到什么粒度、不漏不滥」是管理层原则，B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件 与 B1-05 基于 V 模型的热管理正向开发流程 已经讲透，⛔ 本课不重讲。本课把它的判定结论当输入——影响分析说「这次变更影响 A、B 两个功能」，本课回答的是「那么 A、B 两个功能的软件侧这批债，怎么高效、可重复地还」。
1.6 允许重定版的情形恰好三种，每次都要留下「哪些期望输出变了、依据是什么」
是什么。基线不是永久不变的，但能改它的理由只有三条：
| # | 情形 | 触发点 | 要改的是五件套里的第几件 |
|---|---|---|---|
| ① | 需求变更 | 变更评审通过 | ①②⑤（激励、期望、追溯链） |
| ② | 被控对象模型保真度修正 | 来自第 4 讲的模型漂移分诊结论 | ③，并连带 ② 中那些依赖模型动态的期望输出 |
| ③ | 台架硬件或工具链升级 | 换编译器、换板卡、升实时机镜像 | ④，并连带全量重跑一次以重建对比底 |
⛔ 三条之外的任何理由都不许改基线——尤其是「这条用例老是挂，把期望放宽一点」。那个动作把测量结果变成了判据，K4-03 MIL/SIL/HIL 验证流程 已经点破过它在 ε 上的形态（先跑一遍看 Δ 有多大再据此定 ε），这里是它在期望输出上的同型：这样定出来的判据永远通过，而且每跑一轮自动放宽一次。
重定版必须留下的那一条记录：哪些用例的期望输出因此变了、依据是什么。⇒ 缺了它，下一次回归的差异报告没有可比对的前一版——你会看到一堆差异，而分不清是软件变了还是期望变了。
本讲不交付
配置项的纳管判据、基线冻结的流程与审批（→ K4-04 软件版本、配置与变量管理）；用例设计的方法本体——等价类、边界值三点取法、判定表压缩（→ K4-03 MIL/SIL/HIL 验证流程）；需求怎么条目化、每条带什么字段（→ K4-07 热管理控制功能规格（软件需求）的编写、评审与向 Tier1 交接）；追溯矩阵的工具选型与建库（→ M1-04 需求管理与追溯（DOORS 等））；「谁判影响面、判到什么粒度」（→ B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件 B1-05 基于 V 模型的热管理正向开发流程）；Δt_HIL 与 ε 的取值（→ K4-03 MIL/SIL/HIL 验证流程，本课一个数不给）。
后面还有 4 讲正文 · 关键公式 · 案例拆解 · 常见误区 · 动手做