3. HIL自动化回归测试需求分析

回归测试最容易犯的错误，是把“所有已有用例都跑一遍”当成回归策略。在 HIL 台架上，一次完整回归可能占用数小时甚至数天机时，无差别全量执行既浪费资源，又会让真正需要关注的变更点淹没在噪声里。回归测试需求分析要解决的核心问题是：本次迭代到底有哪些行为可能被破坏，哪些必须验证，哪些可以暂缓。它的输入不是测试用例库，而是三类上游信息——功能规范、变更影响、缺陷历史。

三类需求来源及其提取方式

功能规范提供的是“系统应该做什么”的基线。从规范中提取回归需求时，不要按章节顺序抄条目，而应按可观测行为切分：每条需求应能对应到 HIL 台架上可采集的信号或可判定的状态。例如规范写“车速超过 30 km/h 时自动落锁”，提取出的回归需求应包含：车速信号注入方式（CAN 报文或硬线 PWM）、触发阈值、落锁执行器反馈（门锁状态回读）、以及边界条件（29/30/31 km/h）。规范中标注为安全相关（如 ASIL 等级）或与法规强相关的条目，应默认进入必测集合。

变更影响决定本次回归的优先级排序。拿到一份代码或模型变更清单后，需要做影响传播分析：变更模块的直接接口、共享资源（如共用 CAN 报文、共用传感器信号）、以及时序耦合（如变更引入了新的任务周期）。在 HIL 场景中，特别要关注变更是否影响总线通信矩阵、IO 映射或标定量。一个实用的做法是维护“变更—信号—用例”的映射：某次变更修改了制动灯控制逻辑，那么凡是注入制动踏板信号并观测制动灯输出的用例都应被标记为高优先级。

缺陷历史是最容易被忽视但价值极高的来源。历史缺陷往往集中在特定模块、特定工况或特定边界条件上。对每个已关闭缺陷，应回溯其触发条件与修复方式，并判断：该缺陷是否可能因本次变更而复发？如果缺陷根因位于本次变更影响范围内，则对应的回归用例必须执行。缺陷历史还能暴露规范中未明确写出的隐含需求，例如“低温下首次上电时 CAN 通信延迟不得超过 200 ms”这类经验性约束。

需求追踪矩阵的建立与使用

三类来源提取出的回归需求，最终要落到一张需求追踪矩阵（RTM）上。矩阵的纵向是回归需求条目，横向至少包含：需求来源、关联变更、关联缺陷、对应 HIL 用例、优先级、执行状态。矩阵的作用不是存档，而是支撑三个判断：某条需求是否已被用例覆盖、某个用例是否还有存在必要、本次回归是否遗漏了高风险区域。

建立矩阵时，建议给每条回归需求一个稳定编号，例如 RR-001，并记录其来源类型。用例与需求可以是多对多关系：一条需求可能由多个用例覆盖（正常、边界、故障注入），一个用例也可能同时覆盖多条需求。矩阵中应显式标出未被任何用例覆盖的需求和不覆盖任何需求的用例，前者是覆盖缺口，后者是冗余候选。

从矩阵到执行：优先级与覆盖判断

矩阵建好后，回归执行顺序由优先级驱动。一个可操作的优先级规则是：变更直接影响 + 安全相关 + 历史缺陷复发风险三者取并集为高优先级；仅涉及规范基线且本次无变更的条目为中优先级；长期稳定且无缺陷记录的条目可降为低优先级，在机时紧张时延后。需要强调的是，优先级不是永久标签，每次迭代都应重新评估。

覆盖判断要避免“用例存在即覆盖”的假象。一条回归需求可能被用例“名义覆盖”但实际未验证关键判定点。例如需求要求“制动灯在踏板开度大于 5% 时点亮”，若用例只注入了 50% 开度并检查灯亮，则边界 5% 并未验证。矩阵中应记录每条需求的判定条件，并在评审时抽查用例的断言是否与判定条件一致。

一个简化的提取示例

假设本次迭代变更了车窗防夹控制模块，变更单 CHG-047 显示修改了防夹力阈值计算逻辑。从功能规范中提取：防夹触发后车窗应反向下降至少 100 mm（RR-001）。从变更影响分析：该模块与车门控制模块共享 LIN 报文，需回归车门锁状态（RR-002）。从缺陷历史中查到 BUG-112：低温下防夹误触发，修复方式是增加温度补偿，需回归 -20°C 工况（RR-003）。三条需求分别对应已有用例 TC-012、TC-021、TC-035，矩阵中标记为已覆盖；同时发现变更还影响了防夹力标定参数的写入流程，但无用例覆盖，标记为 RR-004 覆盖缺口，需补充脚本。

回归需求分析的质量，最终体现在矩阵能否回答两个问题：本次变更可能破坏什么，我们是否都验证了；哪些验证是多余的，可以安全省略。前者靠三类来源的交叉提取，后者靠矩阵的覆盖状态与优先级排序。把这两件事做扎实，HIL 回归才能从“跑一遍求安心”变成“有依据、可解释、可优化”的工程活动。