K4-08 · 控制、软件与标定 / 嵌入式软件与开发
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能列出一次回归基线的五件套构成(激励库、期望输出/判据阈值、被控对象实时模型及参数集、工具链与台架配置版本、用例到需求条目的追溯链),并说清它与需求冻结点绑定定版、以及允许重定版的三种情形
- 能按「改标定量/改一行逻辑/改接口」三档给出各自的回归用例集范围(跑哪一测试层级 × 哪种在环形态),并用该判据直接填出 K4-04 exercise 里「需回归范围」那一栏,不自造判据
- 能设计提交冒烟(SIL)与夜间全量(HIL)的两层编排,并在 HIL 台架为独占串行资源、热惯性还要吃掉用例前后回稳时间的约束下算出一晚可跑条数上限,据此反推裁剪力度
- 能写出一次回归的出口判据清单并落成可自动核对的合取式:需求覆盖率与结构覆盖率双条、back-to-back 差异阈值及其按信号类别的取法、未覆盖项处置、未分诊失败数为零
- 能把失败用例分诊成真缺陷/模型漂移/台架问题三类,逐类给出判别证据、处置去向与超时升级规则,并说清为什么「模型漂移」不许标成已知失败挂账
- 能说清被控对象实时模型的保真度本身是回归对象,并设计一组常驻夜间批的模型保真度基准用例与其偏差判据
- 能把实车路试与车队回流数据加工成回归激励与判据基线(口径对齐、场景切分、入库门槛、回放三类判据),并设计测试资产随需求变更同步演进与定期清理的双向机制
内容大纲
- 回归基线与激励库:「拿什么跑」的定版
- 交付物先定形:一次回归的基线不是「一堆用例」,而是五件套一起定版——激励库(输入时序与场景序列)、期望输出或判据阈值、被控对象实时模型及其参数集、工具链与台架配置版本、每条用例到需求条目的追溯链。缺任一件,同一份用例在两台台架上跑出两种结论时无法判谁对。这五件套本身属 K4-04 的配置项,进基线的规则不在本课重讲,本课只定「回归专用的那一份」的内容与粒度
- 激励库按 K4-03 的用例三类分层建:正常(典型循环下的压缩机启停、多通阀切换)、边界(门限 ± 一个分辨率、恰落在迟滞带内、驻留时间恰差一个周期)、故障注入(传感器/执行器失效),再加 K4-03 已并列的第四类——无故障的纯资源竞争激励。分层不是分类癖:冒烟子集从哪一层抽、全量跑到哪一层,第 3 讲要按这个分层裁
- 「黄金数据集」指的是被认定为正确的那一份**期望输出**,来源只有三条且可信度不同:需求条目直接给出的判据(最强)、上一版已放行基线的实测输出(次之,只能证「没变坏」、证不了「本来就对」)、模型侧 MIL 输出(最弱,仅适用于 back-to-back 类比较)。三种混用而不标来源,是「回归全绿但功能是错的」最常见的成因
- 组合场景基线必须显式枚举、不能靠随机工况碰:K4-03 点名的「快充 + 严寒 + 除霜三者叠加」这类组合,要先用等价类划分与成对(两两)覆盖把组合空间落成清单再进基线。组合空间的取点方法本身归 K4-03,本课只判「哪些组合必须常驻回归基线」
- 定版时点与需求冻结点绑定:需求基线冻结→回归基线随之冻结并打同一个标识;变更评审通过→回归基线进入待更新状态,未更新完不得作为放行依据。「谁判影响面、判到什么粒度、不漏不滥」是管理层原则,B1-02 与 B1-05 已讲透,本课不重讲那一层,只把它的判定结论当本课的输入
- 基线不等于永久不变,允许重定版的情形恰好三种:需求变更、被控对象模型保真度修正(来自第 4 讲的模型漂移分诊结论)、台架硬件或工具链升级。每次重定版都要记录「哪些用例的期望输出因此变了、依据是什么」,否则下一次回归的差异报告没有可比对的前一版
- 回归范围裁剪:改标定量/改一行逻辑/改接口三档
- 裁剪表的纵轴直接沿用 K4-04 影响分析的两条维度:测试层级(单元/集成/合格性)× 在环形态(MIL/SIL/PIL/HIL)。本课不自造维度,只把每一格填上「该档跑什么」——K4-04 正文只到「是否需重新做 SIL/HIL 回归」一行提问,本课交付的是那行提问的答案表
- 第一档「改标定量」以 K6-05 已给的判据为样板、不另立一套:仲裁表/优先级权重这类规则型标定量改一条,不按标定量个数估范围,而是从需求—场景矩阵反查该条规则参与过哪些冲突场景,据此圈定 HIL 回归子集;安全相关标定量另走额外评审。分工写死——K6-05 管标定值本身的版本与追溯,本课只管由该变更触发的回归范围与执行
- 第二档「改一行逻辑」(功能内实现变更、不改接口):范围=被改单元的单元用例全集 + 该单元所在功能链的集成用例 + 与被改需求条目有追溯关系的合格性用例。被改单元的结构覆盖率必须重新达档(档位由该功能的 ASIL 定,分档依据见 K4-03),不许拿上一版的覆盖率报告顶替
- 第三档「改接口」(信号语义、数据类型、报文、RTE 端口、NVM 布局任一变化):默认全量且必须含 PIL 与 HIL——目标编译器优化引入的行为差异、定点/浮点位精确性、实测执行时间正是 SIL 测不出而 PIL 才能抓的三类(论证见 K4-02/K4-03)。降档要论证、要签字,不能因工期压力默认降
- 接口档还含一条常被漏掉的分支:本次变更若新增/删除 DTC 或改变其触发条件与语义,诊断侧用例与「车上的码 ↔ 诊断仪库」一致性核对一并进本档回归范围;DTC 与 UDS 机制本体见 K5-01,本课只把它列进裁剪表
- 三档之外必须有一条「无条件全量」触发线:工具链版本变更(代码生成器、编译器、静态分析工具)、被控对象模型或台架配置变更、距上次全量超过约定周期。三者共同点是「被测对象没变、测量系统变了」,增量裁剪判据对它原理性失效
- 裁剪判据的落地口是 K4-04 的 CR 单:CR 的「需回归范围」一栏按本表填。本课只出判据,CR 的提出—影响分析—评审—实施—验证—关闭流程本身不重讲(见 K4-04)。校准方式是拿 K4-04 exercise 那两个算例回读——「V2.3.1 新增电池预热策略、不改接口」落第二档,「修多通阀切换缺陷」也落第二档但须按被改需求条目扩到合格性层;两条读不出来就说明表没填够
- 裁剪只回答「哪些必须跑」,回答不了「这个组合规则本来就没写进表」——遗漏的规则不会在任何一条用例上失败,动态回归对它是原理性无能,那类问题由 K4-05 的静态完备性核对前置拦截,两者双管齐下、互不替代
- 分层编排、门禁链与出口判据
- 两层编排的分界由资源属性决定而非习惯:SIL 跑在非实时 PC 上、可横向并行、单位成本低(K4-03 已论证),适合提交即跑的冒烟子集;HIL 带真实 ECU,台架是**独占串行**资源,一轮降温类工况在环就要真占几十分钟,且带真实 ECU 的台架做不了时间缩放(ECU 跑自己的晶振时钟,缩时会把任务周期与滤波器时基一起缩掉),所以只能排夜间批次
- 由此推出台架时间预算这条硬约束:夜间可用时长 × 台架可用率 ÷(单条平均在环时长 + 前后回稳复位时长)=一晚能跑的条数上限。热管理的特殊之处是回稳项常与在环项同量级——每条用例后要把水温与电池温度拉回起点,漏算这一项会把可跑条数高估到不可实现。这个上限反过来决定第 2 讲的裁剪必须有多狠
- 台架排期还要与虚拟标定的回归标定作业抢同一台设备:K4-03 已划死「HIL/SIL 台架当标定台架用这条线归 K6-13,两者出口判据别混在一张表里」,本课照此办——按作业类型分时段排,不混排、不共用出口表
- 冒烟子集的选取判据要写死、不能凭感觉:覆盖全部模式与主要迁移各至少一条;覆盖上一次分诊出真缺陷的那些用例(缺陷回归位);覆盖本次变更直接触及的需求条目。单批总时长设上限,超了就往夜间批推
- 出口判据第一条是双覆盖率:需求覆盖率答「该测的测了没」、结构覆盖率答「代码里还有没有从没跑到的地方」,两类互不替代、缺任一类都不算过出口(K4-03 已立此判据,本课把它写进回归的出口清单)。结构覆盖档位按被测功能的 ASIL 取,不是越高越好。需求覆盖率的分母只有在需求已条目化、每条带验证方法与验证层时才成立,上游修法在 K4-07
- 出口判据第二条是差异阈值:back-to-back 类比较按 Δ = |y_code − y_model| < ε 判定,该式与语义见 K4-03/K4-02、本课不重推;本课要补的是 **ε 怎么定、怎么按信号类别分栏**——温度类按传感器分辨率与控制阈值迟滞带的量级取,开关/模式类按「不允许出现任何一步不一致」的零容忍口径取。两类混用一个阈值,必然要么漏判要么天天误报
- 出口判据第三条是未覆盖项与失败项的处置状态:K4-03 已给未覆盖项四条分流(补用例/故障注入激活后仍不可达则书面论证豁免/代码生成器工具产物随版本说明/真死代码删除并回溯),本课加的是回归特有的一条——所有失败用例必须完成第 4 讲的分诊并有明确去向,「未分诊的失败」不得计入放行统计,也不得记为「已知失败」长期挂账
- 门禁链的构成(这正是 K7-02 那句「回归未过的包根本进不了下发队列」的实现侧):构建 → 静态检查 → SIL 冒烟 → 打包与签名 → HIL 全量回归 → 出口判据自动核对 → 打「可发布」标记。下游取包只认这个标记、不认人工通知;标记之后的事(灰度节奏、回滚门限、车队评估、孪生推送)归 K7-02/K7-03/N6-02,发布门禁的内/外分界就在这一格
- 回归报告的最小内容集:本次跑的基线版本、裁剪档位与依据、通过/失败/未跑各多少、两类覆盖率数值与所取档位、失败用例的分诊去向、以及与上一次基线的差异清单。差异清单是回归报告与首次验证报告的唯一实质区别——没有它,这份报告只是又一份测试记录
- 失败分诊三分类与「模型保真度本身是回归对象」
- 分诊是回归自动化的真瓶颈:跑得越自动,失败清单越长,人能承受的上限不是「跑多少」而是「判多少」。分诊的目标不是当场找到根因,而是在最短时间内把每条失败**定向**到正确的责任方并给出下一步动作
- 第一类真缺陷(被测软件错):判别证据=同一基线上一版通过、本版失败,且失败可在 SIL 上稳定复现,与本次变更的追溯链能对上。去向=按 K4-04 的 CR/缺陷流程建单,并把该用例登记为缺陷回归位、永久进冒烟子集
- 第二类模型漂移(被控对象实时模型错、软件是对的):判别证据=SIL 全过而 HIL 抖动或不过、失败集中在某一物理子系统的动态段、把该环节参数还原后现象消失。⚠ 这一类的正确处置是改模型并触发第 1 讲的基线重定版,**不是**把用例标成「已知失败」挂账——挂账等于把一个真实存在的系统滞后一路藏到整车上
- 由此确立本课的热管理特异条款:**被控对象实时模型的保真度本身是回归对象,不是回归的背景**。模型或其参数每次变更都要跑一组固定的保真度基准用例——典型降温/升温瞬态的时间常数、换热器出口温度的稳态偏差、压缩机与多通阀模式切换的过渡段形态;偏差超限即判回归失败,与软件失败同等对待。缺了这一条,本课就退化成通用软件工程课,这是本课唯一的落地风险
- 与仿真资产侧的归属划清:仿真模型作为**设计资产**的建库、版本与不确定度量化不在本课;本课只管该模型被拿去当回归判据基准时的保真度回归。同一份模型、两种身份,两边的验收表不许混成一张(归属见 J7-06,本课不重讲)
- 第三类台架问题(软硬件都对、测量系统错):判别证据=失败随台架/机位/批次变化而不随软件版本变化、同一用例换台架即通过、伴随 I/O 通道或总线板卡的异常计数。去向=台架维护后复跑,并必须计入台架可用率统计——台架问题占比长期偏高时,第 3 讲那条夜间排期假设已经不成立了
- 分诊必须有超时与升级规则:单条失败在约定时限内分不出类,就按最严一档(真缺陷)处置并阻断门禁,而不是默认放行。「先记为待查、等有空再看」是把回归退化成摆设的最短路径
- 分诊结论要回写成资产:每条失败的分类、证据、处置与结论挂在用例上形成该用例的历史。两类用例由此浮出水面——长期被判为台架问题的高频误报用例、以及从不失败也从不覆盖新需求的僵尸用例,它们是第 5 讲清理测试资产的两条输入
- 数据回灌与测试资产的演进
- 回灌的定位先写死:把实车路试与车队回流的真实信号流加工成回归激励与判据基线,用途是**发布门禁前**的激励库补强,不是门禁后的效果评估。灰度放量、回滚门限、车队样本量与统计显著性归 K7-02,自学习与影子模式归 K7-03,孪生推送归 N6-02——门禁内/外这条线在此第二次出现,与第 3 讲的「可发布标记」是同一格
- 回灌的加工链有五步:原始记录 → 信号口径对齐 → 场景切分与打标 → 去重与代表性抽样 → 进库定版。口径对齐这一步必须按 K7-04 定义的信号表与语义版本做,DBC 改版会造成历史数据口径断层,口径没对齐的旧数据回放出来的是**假差异**。数据从车端怎么采(采什么信号、多高频率、什么事件触发抓帧、上行带宽与存储预算)不在本课,见 K7-04
- 入库门槛要成条,否则激励库会被真实数据淹掉:每条候选回放用例必须能指回一条需求条目或一个已发生的故障现象;同一场景的重复片段只留代表;工况参数(环境温度、SOC、车速段)要落在已声明的覆盖表上。不满足的进「素材池」,不进回归基线
- 回放用例的判据与台架用例不同、必须单列:真实数据没有设计好的期望输出,只能用三类判据——不变式(温度/压力不得越限、模式不得出现非法迁移)、与录制时车端实际行为的一致性比对(带容差)、场景判定正确率。K4-03 已把「场景覆盖率」立为需求/结构覆盖率之外的第三栏,本课把回放用例算进这一栏的分子
- 测试资产随需求变更同步演进,正面回应 K4-03 自列却无对策的那条误区(用例长期不随需求更新、覆盖率数字失真):机制是双向门闩——需求条目变更时,其追溯到的用例自动进入「待复核」状态并阻断该条需求的覆盖率计数;用例新增或修改时,指不回任何需求条目的判为无源用例、评审打回。追溯矩阵本身的工具与做法见 M1-04/K4-04,本课只定回归侧这两条闩
- 资产要能减、不能只加:定期清理三类——长期判为台架问题的高频误报用例、需求已作废而用例还在的孤儿用例、与已有用例等价类完全重合的冗余用例。只加不减的激励库最终会把夜间窗口撑爆,逼着人偷偷降档,这比一开始就少跑更危险
- 与试验侧自动化的措辞必须刻意区分:本课的「自动化」对象是软件构建与测试流水线(提交、构建、跑用例、判出口、打标记),L7-02 的自动化对象是台架工况序列与数采信号链。两者常共用同一台 HIL 设备,但被自动化的东西不是一件事——写方案时把「软件流水线」与「试验序列」混成一个词,排期与责任都会跟着混
关键公式
N_夜间上限 = T_窗口 × η_可用 / (t̄_在环 + t̄_复位)
把「裁剪要多狠」从主观判断变成可算的约束:先算出一晚的条数上限,再回到第 2 讲决定哪一档必须进夜间批、哪些拆成多夜滚动
放行 = (C_需求 ≥ C_需求,目标) ∧ (C_结构 ≥ C_结构,ASIL档) ∧ (max|Δ| < ε_信号类) ∧ (N_未分诊失败 = 0) ∧ (未覆盖项均已按四条分流处置完毕)
把 B1-05 明问的「跑完按什么判过不过」落成一条可被门禁链最后一格自动核对的判据,也是 K7-02「回归未过的包进不了下发队列」判「过没过」的那一格
关键概念
回归基线(五件套定版)黄金数据集(期望输出基线)激励库分层回归范围裁剪三档表缺陷回归位冒烟子集与夜间全量台架时间预算门禁链与「可发布」标记出口判据合取式差异阈值 ε 的信号分类取法失败分诊三分类模型漂移被控对象模型保真度回归数据回灌回放判据(不变式/一致性/场景判定正确率)无源用例孤儿用例台架可用率
推荐工具与标准
CI 流水线工具(Jenkins / GitLab CI 一类,把构建—静态检查—SIL 冒烟—打包签名—HIL 全量—出口核对—打标记串成一条链) HIL 自动化执行与报告工具链(dSPACE / NI / ETAS 各家台架自带的序列执行与报告生成) Simulink Test 一类的测试管理平台(用例、执行结果与需求追溯的登记载体) 覆盖率度量工具(模型侧 Simulink Coverage、代码侧结构覆盖率工具;两者不可互相顶替,见 K4-02/K4-03) 需求管理与追溯工具(DOORS / Polarion,供第 5 讲的双向门闩落地,衔接 K4-04 / M1-04) 数据回放与信号口径对齐工具(DBC / A2L 版本管理与信号语义比对,衔接 K7-04) 缺陷与变更流程系统(Jira / 禅道,分诊结论按 K4-04 的 CR/缺陷流程落单)
ISO 26262-6(软件层面的产品开发:软件测试层级划分与按 ASIL 分档的结构覆盖率类型;本课用到其再验证/回归相关要求,具体条款须查原文落条,版本按现行版本确认) ISO 26262-8(支持流程:配置管理与变更管理,含变更后再验证范围的要求;具体条款须查原文落条,版本按现行版本确认) Automotive SPICE(SWE.4~SWE.6 软件测试过程域、SUP.8 配置管理中「测试件一并进基线」的要求、SUP.10 变更请求管理;⚠ 3.1 与 4.0 两版并行流通,4.0 调整过过程域名称与工作产物编号,引用时必须显式声明所依版本、不得混引) ISO/IEC/IEEE 29119(软件测试体系:测试过程、测试文档与测试资产维护;本课只用其体系划分,落到哪一部次与具体要求须查原文确认)
工程案例
某电池热管理控制器的一次夜间全量回归:SIL 冒烟与 SIL 全量全部通过,HIL 批次里冷却模式切换的几条用例偶发失败,复跑时通过时不通过。按三分类分诊——失败不随软件版本变化、换一台台架仍能复现,先排除台架问题;失败集中在 Chiller 投入的那一段动态而非全程,且本次变更的追溯链与该段无关,指向模型侧而非软件侧。根因是 HIL 被控对象实时模型里 Chiller 的动态响应被过度简化降阶,掩盖了实际系统里的一个滞后环节,于是 SIL 全过、只有接了真实 ECU 的 HIL 才把它抖出来。整改分三步:补上滞后环节;把该模型作为回归基线的一部分重新定版,并逐条记录「哪些用例的期望输出因此变了、依据是什么」;把「典型降温瞬态的时间常数」与「换热器出口温度稳态偏差」固化成模型保真度基准用例,常驻夜间批。此后 HIL 稳定复现出原问题,装车前被拦截。(现象与根因取自 K4-03 的案例,本课接手的是它之后的分诊定向与基线处置——这也正是「模型漂移不许标成已知失败挂账」的现场形态。)
动手做
交付物 · 给定同一软件基线上的两次变更:(a) 把电池冷却启停的仲裁优先级权重改一条(规则型标定量微调);(b) 修一个多通阀模式切换缺陷(改逻辑、不改接口,即 K4-04 exercise 里 V2.3.1 的那个场景)。① 按第 2 讲的三档表各出一份**回归范围裁剪单**,逐条写明「跑哪一测试层级 × 哪种在环形态、依据是本表的哪一条判据」——(a) 的标定量档必须按 K6-05 的需求—场景矩阵反查法圈定 HIL 子集,不自造判据;② 各出一份**出口判据清单**(双覆盖率的目标值与所取档位、差异阈值 ε 及其信号分类、未覆盖项的处置口径、放行前对失败分诊的要求),并按合取式写成可自动核对的形式;③ 用第 3 讲的台架时间预算式核算 (b) 的夜间批一晚跑不跑得完(台架时长、可用率、单条在环与复位时长可自行假设并标注为假设值),跑不完则给出拆批或降档方案,并写明降档的论证要点与签字人;④ 把 ① 的结果直接填回 K4-04 exercise 的 CR 单「需回归范围」一栏,验证两课能对上。交付:两份裁剪单 + 两份出口判据清单 + 一份台架时间预算核算表 + 回填后的 CR 单。
常见误区
- 以为「回归就是把上次那批用例再跑一遍」,其实没有定版的基线(激励库 + 期望输出 + 被控对象模型 + 工具链 + 追溯链)就没有可比对的「上次」——同一份用例换台架、换模型版本跑出两种结论,谁也判不了谁对
- 以为上一版通过的输出就是「黄金」,其实它只能证「没变坏」、证不了「本来就对」;把继承来的错误期望输出当判据,回归越绿错得越稳
- 以为改一个标定量是小改、可以按标定量个数估回归范围,其实仲裁表/优先级权重这类规则型标定量改一条会波及它参与过的全部冲突场景,必须从需求—场景矩阵反查圈定 HIL 子集(判据 K6-05 已给,本课照用、不另立一套)
- 以为接口变更在 SIL 上跑通就够了,其实目标编译器优化引入的行为差异、定点/浮点位精确性与实测执行时间只有 PIL/HIL 能抓;接口档默认全量,降档要论证并签字,不是工期紧就默认降
- 以为工具链升级不算软件变更、不必回归,其实这类变更是「被测对象没变、测量系统变了」,增量裁剪判据对它原理性失效,必须走无条件全量
- 以为把夜间全量的条数堆满就是充分,其实 HIL 台架是独占串行资源、热惯性还要在每条用例前后吃掉一段回稳时间;排期算不过来时人只会偷偷降档,不如一开始就按可跑上限做裁剪
- 以为 SIL 全过而 HIL 抖动是台架不稳,其实第一嫌疑是被控对象模型被过度降阶掉了某个动态环节;把它标成「已知失败」挂账,等于把一个真实的系统滞后一直藏到整车上才第一次暴露
- 以为分诊不出来的失败可以先记为待查,其实未分诊的失败必须按最严一档阻断门禁——一旦允许挂账,「已知失败」清单会稳定增长到没人再看,回归就此退化成摆设
- 以为把车队真实数据大量回灌进回归库就更真实,其实信号口径没对齐(DBC/信号语义改版造成的历史数据断层)回放出来的是假差异;且不设入库门槛,真实数据会把夜间窗口直接淹掉
- 以为需求覆盖率与结构覆盖率都达标、差异阈值也没超就等于验证充分,其实这三类指标都答不了「这条组合规则从来没被写进表」——遗漏的规则不会在任何一条用例上失败,只能靠 K4-05 的静态完备性核对前置拦截
- 以为温度信号与模式/开关信号可以共用一个 back-to-back 差异阈值 ε,其实前者要按传感器分辨率与迟滞带量级取、后者是「不许有任何一步不一致」的零容忍;混用一个阈值,不是漏判就是天天误报到没人再看报告
- 以为回归报告和首次验证报告是一回事,其实回归报告的实质内容是**与上一次基线的差异清单**;没有差异清单,它只是又一份测试记录,回答不了「这次改动到底动了什么」
相关课题