4、回归测试基础：回归测试目标、策略、用例选择与自动化回归测试的收益
TinyML 硬件在环（Hardware-in-the-Loop, HIL）测试的核心挑战在于：每一次固件更新、模型量化参数调整或驱动库升级，都可能引入难以察觉的时序漂移、数值精度退化或外设通信异常。回归测试正是为了应对这一风险而存在的系统性工程活动。它并非简单地“重跑一遍旧用例”，而是围绕“变更影响分析”建立的一套有目标、有策略、有取舍的质量保障机制。本章将深入剖析回归测试在 TinyML HIL 场景下的目标定义、策略选择、用例筛选方法以及自动化带来的实际收益，帮助测试团队从“被动验证”转向“主动防御”。
上图展示了 TinyML HIL 回归测试的整体策略框架。从变更源出发，经过影响分析、用例选择到执行反馈，形成闭环。策略分层确保不同粒度的变更都能得到适当程度的验证，避免“一刀切”带来的效率或覆盖不足问题。下面将逐一展开各模块的详细内容。
4.1 回归测试的核心目标：不止于“没有新Bug”
在 TinyML HIL 场景中，回归测试的首要目标是验证变更未对既有功能造成破坏，但这只是最低要求。更深层次的目标包括：确保模型精度退化在可接受范围内（例如 Top-1 准确率下降不超过 0.5%）、保证实时性指标不恶化（如推理延迟抖动不超过 5%）、确认外设通信协议兼容性（I2C/SPI/UART 时序不漂移）。这些目标需要转化为可量化的指标，并嵌入到自动化断言中。
值得注意的是，回归测试目标应区分“必须达标”与“趋势监控”两类。前者是硬性门槛，后者用于发现潜在劣化趋势。例如，Flash 占用率每次增加 0.5% 可能不触发失败，但连续 5 次提交持续增长，则需告警。
4.2 回归测试策略：分层分级与风险驱动
TinyML 项目通常资源受限（硬件数量少、编译时间长、HIL 执行慢），因此不能对所有变更都执行全量回归。推荐采用风险驱动的分层策略，将测试用例分为四个层级，根据变更影响范围动态组合。
| 层级 | 执行时机 | 覆盖范围 | 典型耗时 | 通过标准 |
|---|---|---|---|---|
| 冒烟层 | 每次代码提交（CI 触发） | 上电自检、主循环启动、调试串口输出、基本传感器读取 | 5-10 min | 无致命错误，关键日志正常 |
| 核心层 | 每次代码提交（合并前） | 模型推理精度（代表性数据集）、主要外设读写、电源电压监测 | 30-60 min | 精度指标在阈值内，外设无超时 |
| 深度层 | 每日夜间构建 | 边界值输入、长时间压力运行（2h+）、异常恢复、多外设并发 | 2-4 h | 无内存泄漏、无死锁、性能退化 < 5% |
| 全量层 | 发布候选版本 | 全部用例 + 组合场景 + 硬件兼容矩阵 | 6-12 h | 所有用例通过，无已知严重缺陷 |
策略选择的关键在于变更影响分析。例如，仅修改了某个 GPIO 的初始化顺序，影响范围可能仅限于该外设及其依赖模块，此时执行冒烟层+核心层中与该 GPIO 相关的用例即可。而如果修改了 RTOS 调度策略或中断优先级，则必须执行深度层以验证时序稳定性。
4.3 用例选择与优先级：从全量到精准
用例选择是回归测试效率的核心。在 TinyML HIL 中，由于硬件资源有限，无法无限并行执行，因此必须建立科学的筛选机制。推荐采用“三因素加权法”：
- 变更关联度（权重 50%）：用例覆盖的代码/模块与本次变更的关联程度，通过静态调用图或 git diff 分析获得。
- 历史缺陷密度（权重 30%）：该用例在过去 N 次执行中发现的缺陷数量，缺陷多的用例优先保留。
- 业务关键度（权重 20%）：用例对应的功能对产品核心价值的贡献度，如唤醒率测试高于 LED 闪烁测试。
计算每个用例的加权得分后，按从高到低排序，结合时间预算（例如核心层限时 60 分钟）截取用例集。同时保留“必选用例”清单，这些用例无论得分如何都必须执行，通常是安全相关或客户明确要求的场景。
// 用例选择伪代码示例
def select_test_cases(changed_files, time_budget):
candidates = get_all_hil_cases()
scored = []
for case in candidates:
relevance = calc_relevance(case, changed_files) # 0~1
defect_density = case.historical_defects / case.executions
business_value = case.business_score # 1~5
score = 0.5 * relevance + 0.3 * defect_density + 0.2 * business_value
scored.append((score, case))
scored.sort(reverse=True)
selected = []
total_time = 0
for score, case in scored:
if case.must_run or total_time + case.estimated_time <= time_budget:
selected.append(case)
total_time += case.estimated_time
return selected4.4 自动化回归测试的收益：效率、质量与可追溯性
自动化回归测试在 TinyML HIL 中的收益并非“省人工”这么简单，它带来了三个维度的质变：
- 效率维度：手动执行一轮核心层测试约需 2 小时（含搭建环境、烧录、观察日志、记录结果），自动化后压缩至 40 分钟，且可并行执行多块开发板。按每日 5 次提交计算，每天节省 6.7 小时。
- 质量维度：自动化脚本可以精确采集传感器数据、时序戳、功耗曲线，避免人工读数的误差。更重要的是，自动化能发现“间歇性失败”——例如每 100 次运行出现 1 次 I2C 应答超时，这种问题人工很难捕捉。
- 可追溯性维度：每次回归测试自动生成 JSON 格式报告，包含硬件版本、固件哈希、测试环境参数、通过/失败断言详情。当客户反馈问题时，可快速回溯到具体固件版本对应的测试结果。
4.5 案例拆解：一次典型的固件升级回归实战
背景与约束：某智能音箱产品采用 Cortex-M4 内核 MCU，运行 KWS 模型。开发团队优化了音频前端算法（新增回声消除模块），涉及约 1200 行 C 代码变更。硬件在环测试台架包含 3 块开发板，每块板子执行一轮全量测试需 8 小时。项目要求 2 天内完成回归并给出发布结论。
初始现象与目标：开发自测阶段发现，在特定噪声环境下唤醒率下降 3%。团队需要确认这是算法优化带来的必然代价，还是引入的回归缺陷。目标：① 确认回声消除模块是否影响其他音频路径；② 验证优化后整体唤醒率是否仍满足 ≥95% 的规格；③ 检查内存占用是否超限。
关键输入数据：变更文件列表（audio_frontend.c, echo_cancel.c, 新增 3 个头文件）、基线测试报告（唤醒率 96.2%，内存峰值 46.2KB）、HIL 台架日志（包含 200 条音频测试样本的推理结果）。
分析判断过程：通过 git diff 发现变更涉及 DMA 缓冲区配置和中断优先级调整。根据影响标签，这些变更可能影响 I2S 音频采集和 SPI Flash 读取。因此，用例选择策略为：冒烟层全选（10 个用例），核心层选择与音频、DMA、中断相关的 15 个用例（排除与 LED、按键无关的 8 个用例），深度层选择 2 小时压力测试（重点监控内存和时序抖动）。
实际操作步骤：
- 在 CI 服务器上触发自动化回归脚本，自动烧录新固件到 3 块开发板。
- 冒烟层执行：检查上电日志、主循环周期、调试串口输出，全部通过（5 分钟）。
- 核心层执行：播放 200 条标准测试音频，采集唤醒率数据。结果：唤醒率 95.8%，略低于基线但高于 95% 阈值。同时发现 2 次 I2S 数据丢失警告。
- 深度层执行：持续运行 2 小时，监控内存峰值 47.1KB（超基线 0.9KB，但未超 48KB 限制）。时序抖动分析显示，中断响应时间最大偏差 12μs（基线 8μs），仍在可接受范围。
结果对比与风险：唤醒率下降 0.4% 被判定为算法优化引入的合理代价，但 I2S 数据丢失警告需要进一步调查。团队决定增加 5 个针对 I2S 时序的专项用例，并安排开发人员检查 DMA 描述符配置。最终结论：有条件通过，需在下一个迭代修复 I2S 警告后发布。
复盘经验：① 影响标签机制有效缩小了用例范围，节省了约 3 小时执行时间；② 自动化脚本成功捕获了人工难以察觉的间歇性 I2S 警告；③ 内存增长 0.9KB 虽未超限，但应建立趋势监控，防止连续累积。
4.6 常见误区与总结复盘
在实施回归测试过程中，团队常陷入以下误区：
- 误区一：回归测试 = 重跑所有用例。这会导致测试周期过长，且大量与变更无关的用例浪费硬件资源。正确做法是采用分层策略和影响分析。
- 误区二：只关注功能正确性，忽略性能指标。TinyML 对实时性和功耗极其敏感，回归测试必须包含时序、内存、功耗等非功能断言。
- 误区三：自动化脚本“写一次，用永远”。硬件平台升级、编译器版本变化、模型结构更新都可能使脚本失效，需要定期维护。
- 误区四：忽视“测试的测试”。没有验证自动化脚本本身是否能正确捕获缺陷，导致脚本出现误判时无人察觉。