回归测试基础理论：为什么ADAS需要它？

大家好，我是你们的老朋友。今天咱们聊聊回归测试——这个听起来有点枯燥，但实际做起来能让你又爱又恨的话题。

先说说我的亲身经历。几年前我参与一个L2+级别的ADAS项目，团队花了三个月开发了一套新的车道保持算法。测试通过，顺利上车。结果呢？原来好好的自动紧急制动（AEB）功能，在新版本里居然在高速上误刹车了。嗯，这就是典型的「改了一个地方，坏了另一个地方」。回归测试，就是为了抓这种鬼。

回归测试的定义与目的

回归测试，说白了就是：每次代码或系统有变更，重新跑一遍已有的测试用例，确保旧功能没被新改动搞坏。

它的核心目的有三个：

• 验证缺陷修复是否有效——你修了一个bug，得确认它真的被修好了。
• 检查新代码是否引入副作用——改A坏B，这是ADAS开发里最常见的坑。
• 保证系统整体稳定性——尤其是ADAS这种安全关键系统，任何功能退化都可能要命。

回归测试的三种策略

你可能会问：每次改完都全量跑一遍，项目周期受得了吗？问得好。所以业界总结了三种策略，我一个个说。

1. 完全回归

顾名思义，所有测试用例全部执行一遍。优点是覆盖率100%，缺点嘛——时间成本爆炸。我在一个L3项目中试过，全量回归一次要跑72小时。你想想看，如果每天都有代码合入，根本跑不过来。

适用场景：

• 核心模块的重大重构
• 发布前的最终验证
• 测试用例总数较少（比如早期原型阶段）

2. 选择性回归

只跑「受影响」的测试用例。怎么判断受影响？靠代码变更分析、依赖关系图、或者——靠经验。

我记得有一次，团队改了一个感知模块的配置文件，按理说只影响目标检测。但选择性回归只跑了感知相关的用例，结果漏掉了规划模块的一个边界条件。嗯，那次教训挺深刻的。

关键点：

• 需要精准的变更影响分析
• 依赖良好的模块解耦设计
• 风险在于「你以为没影响，其实有」

3. 基于风险的回归

这是我最推荐的一种策略。说白了：把测试资源优先分配给高风险区域。

怎么定义风险？我一般看三个维度：

维度	评估标准	举例
功能安全等级	ASIL等级越高，风险越高	AEB（ASIL-D）> 车道保持（ASIL-B）
历史缺陷密度	之前bug多的模块，风险高	感知模块经常出问题，优先测
变更影响范围	改动波及的模块越多，风险越高	改了底层通信协议，所有上层都得测

ADAS回归测试的三大痛点

好了，理论讲完了。咱们聊聊现实。ADAS回归测试，真的很难。为什么？三个字：大、长、赖。

痛点一：数据量大

一个典型的ADAS系统，每天产生的路测数据可能是TB级别的。你想想看，光是存储这些数据，就得烧掉多少预算？更别提还要回放、标注、比对。

我见过一个团队，为了做一次回归测试，需要从30TB的原始数据中提取有效场景。光数据预处理就花了三天。嗯，这还没开始跑测试呢。

怎么办？

• 建立场景库，只保留「有价值」的数据（比如极端工况、边缘场景）
• 使用数据压缩和索引技术，加速检索
• 考虑合成数据补充（但要注意泛化性）

痛点二：周期长

ADAS回归测试不是跑个单元测试就完事的。它涉及：

• 软件在环（SIL）仿真
• 硬件在环（HIL）测试
• 车辆在环（VIL）甚至实车路测

每个环节都要时间。我参与的一个L3项目，一次完整的回归测试周期是两周。两周啊！如果中间发现bug，修完再回归，一个月就过去了。

痛点三：环境依赖

ADAS测试对环境极其敏感。同样的算法，晴天和雨天表现可能天差地别。同样的场景，白天和晚上结果完全不同。

我记得有一次，我们在仿真环境里跑了一百遍都没问题，结果实车测试时，因为路边一棵树的阴影，系统直接误判了。嗯，这就是环境依赖的可怕之处。

环境依赖具体表现在：

• 光照条件——强光、逆光、黄昏、夜晚
• 天气条件——雨、雪、雾、霾
• 道路条件——车道线磨损、施工区域、乡间小路
• 交通参与者——行人、自行车、动物、异形车辆

你想想看，要覆盖所有这些组合，测试用例数量会爆炸式增长。所以，环境依赖是ADAS回归测试最难啃的骨头。

小结

今天咱们聊了回归测试的定义、三种策略，以及ADAS特有的三大痛点。说实话，这些痛点没有银弹。但理解了它们，你就能在设计自动化框架时，有针对性地做取舍。

下一章，我会带大家看看如何用自动化手段，解决「数据量大」和「周期长」这两个问题。至于「环境依赖」——嗯，那是个大话题，咱们后面专门用一章来讲。

我是你们的ADAS测试老司机，咱们下章见。