4. 回归工程基础
在三电系统（电池、电机、电控）的自动化测试体系中，回归测试是保障“改动不破坏既有功能”的核心防线。三电软件具有控制逻辑复杂、状态耦合强、安全等级高等特点，任何一次标定参数调整、控制算法优化或通信协议变更，都可能引发连锁反应。回归工程的目标，就是用可控的成本，在有限时间内验证“该测的都测了、该稳的没退化”。
一、回归测试的核心概念
回归测试并非“把用例再跑一遍”，而是一套以风险为驱动的验证策略。它回答三个问题：改了什么、可能影响什么、必须验证什么。在三电场景中，回归对象通常包括：BMS 的 SOC/SOH 估算逻辑、电机控制器的 FOC 电流环与扭矩响应、VCU 的上下电时序与故障降级策略，以及 CAN 通信矩阵与诊断服务。
二、触发条件：什么时候必须回归
回归不能凭感觉启动，需要明确的触发条件。常见触发源可分为四类：
- 代码变更触发：控制算法、状态机、故障诊断逻辑的提交，尤其是涉及安全相关的分支。
- 参数与标定触发：扭矩MAP、PID 参数、SOC 修正系数、保护阈值等标定数据更新。
- 接口与协议触发：CAN 报文、DBC 矩阵、UDS 诊断服务、OTA 升级包格式变化。
- 环境与依赖触发：底层驱动、RTOS、编译工具链、HIL 台架模型或测试脚本框架升级。
实践中可用变更影响矩阵快速判断触发等级，例如“安全相关代码 + 接口变更”应触发全量回归，“注释与日志修改”可仅做冒烟验证。
三、范围选择与优先级策略
范围选择的核心是“变更影响分析 + 用例关联”。建议建立需求—用例—代码/参数的追溯关系，当某模块变更时，自动圈定关联用例集。优先级通常按 P0～P3 划分：
| 优先级 | 判定标准 | 典型用例 | 执行策略 |
|---|---|---|---|
| P0 | 安全相关、法规强制、核心功能 | 高压上下电、过流保护、绝缘检测 | 每次回归必跑 |
| P1 | 主功能路径、高频用户场景 | 扭矩响应、SOC 估算、充电流程 | 变更影响域内必跑 |
| P2 | 边界与异常场景 | 通信超时、传感器漂移 | 按版本节奏抽跑 |
| P3 | 低频、冗余、体验类 | 日志上报、界面提示 | 大版本或专项回归 |
优先级不是固定标签，而应随版本风险动态调整。例如临近量产阶段，P1 用例可能被临时提升为 P0。
四、成本控制：让回归“跑得起、跑得准”
回归成本主要来自台架占用、执行时长和人力分析。控制手段包括：
- 分层回归：MIL/SIL 跑逻辑，HIL 跑集成，实车只跑关键场景，避免高成本资源被低价值用例占用。
- 用例精简与去重：合并等价用例，剔除长期无失败记录的冗余项，但需保留安全底线。
- 失败聚类与根因归并：同一根因导致的多个失败合并分析，减少重复定位。
- 自动化与并行：利用多台 HIL 台架并行执行，夜间批量跑回归，白天做结果分析。
五、典型场景与误区复盘
某车型在 OTA 升级 VCU 故障降级逻辑后，仅回归了故障注入用例，未回归正常上下电时序，导致量产车出现偶发无法上高压。复盘发现：变更点虽在故障分支，但状态机入口条件被修改，影响域覆盖了正常路径。这说明范围选择不能只看变更函数，还要看状态迁移路径。
常见误区还包括：把回归当“全量重跑”导致资源挤兑；只统计通过率不看失败根因；P0 用例长期不更新，无法覆盖新增安全需求。回归工程需要与需求管理、版本管理、缺陷管理联动，形成闭环。
# 回归触发判定伪代码示例
if change.type in ["safety_code", "can_matrix", "calibration"]:
scope = impact_analysis(change)
priority = "P0" if change.safety else "P1"
run_regression(scope, priority, parallel=True)
else:
run_smoke_test()
回归工程不是测试团队的独角戏，而是研发、标定、测试、质量共同参与的变更治理机制。把触发条件写进流程、把影响分析做成工具、把优先级与成本放在同一张决策表上，才能让三电系统的每次迭代既跑得快，又退得少。