自动驾驶感知测试工程师面试宝典 - 第2节
第二章 自动驾驶感知测试基础常识
本章定位:面试官最常考察的基础知识集中区,包含传感器物理原理、感知算法核心指标、测试流程三块。这三块是后续所有高阶问题的地基,答错一题直接扣分 50% 以上。
知识结构速览:
| 模块 | 核心内容 | 高频考点 |
|---|---|---|
| 传感器原理 | 激光雷达、摄像头、毫米波雷达、超声波、IMU | 工作原理、点云特性、FOV、帧率、分辨率 |
| 感知算法指标 | mAP、Recall、Precision、IoU、FPS、延迟 | mAP计算方式、IoU阈值影响、实时性指标 |
| 测试流程要点 | 数据采集→标注→闭环仿真→实车路测→回归 | 测试用例设计、场景覆盖、评价标准 |
使用说明:回答任何基础问题时,先判断面试官在考哪个分支(原理/指标/流程),然后按 STRA 顺序组织语言。示例参考下方问答卡片。
📌 问答卡片 1:传感器原理
面试问题:请对比激光雷达和毫米波雷达在自动驾驶感知中的优缺点,以及各自的失效场景。
面试官考察点:① 是否理解两种传感器物理原理;② 能否说出典型失效工况(雨雾、黑夜、静态目标等);③ 是否有工程选型经验。
回答框架:原理简述 → 优点 3 点 → 缺点 2 点 → 各举 1 个典型失效场景 → 实际项目中的选型思路。
示例回答:激光雷达基于 TOF 原理,精度高但受雨雾散射严重;毫米波雷达利用多普勒频移,测速准且全天候好。我在项目中用激光雷达做目标分类,毫米波雷达做远距离检测,雨雾天以毫米波为主。
可能追问:① 激光雷达点云稀疏时如何提升检测效果?② 毫米波雷达对静态目标不敏感怎么办?③ 激光雷达线束从 64 线降为 16 线,任务指标会掉多少?
避坑提醒:不要只说术语不举例;不要贬低某种传感器(“激光雷达最垃圾”);失效场景一定要结合物理原理推导,不能死背。
📌 问答卡片 2:感知算法指标
面试问题:mAP 是怎么计算的?IoU 阈值设置 0.5 和 0.7 对评测结果有什么影响?
面试官考察点:① 是否真正理解 mAP 的 recall-precision 曲线积分;② 是否关注过业务场景和评测标准之间的匹配;③ 能否说出实际调阈值时的 trade-off。
回答框架:先给出 mAP 定义(AP 是 PR 曲线下面积,mAP 是各类别 AP 均值)→ 分 IoU=0.5 和 0.7 两种情况分析召回率和精确率的变化趋势 → 结合应用场景说明如何选择。
示例回答:IoU=0.5 更关注检测能力,适合远距离小目标场景;IoU=0.7 要求定位精度,适合近距离避障。我在 AEB 项目中使用 0.7,把误检从 5% 降到 1.2%,但 recall 下降了 3%。
可能追问:① 如果三类目标 mAP 差异很大,如何处理?② 模型推理 FPS 与 mAP 的 Pareto 曲线怎么分析?③ 标注质量差会导致 mAP 偏高还是偏低?
避坑提醒:不要只说公式不说实际案例;避免说“IoU 越大越好”——要看业务容忍度;忘记提 NMS 导致重复框会挨批。
📌 问答卡片 3:测试流程要点
面试问题:你负责一个感知模块的回归测试,如何设计测试用例来覆盖 corner case?
面试官考察点:① 是否有系统化的测试思维;② 能否区分仿真测试和实车测试的侧重点;③ 是否理解 corner case 的定义和挖掘方法。
回答框架:总述测试金字塔(数据→仿真→回放→实车)→ 给出 corner case 的分类标准(光照/天气/遮挡/特殊交通参与者)→ 举例说明 2-3 个典型用例 → 说明如何自动化回归。
示例回答:我按“场景要素正交表”生成用例,例如逆光+低头行人+雨天。仿真先过 1000 种组合,然后用路采数据回放。发现冲突时自动提交 Jira,标注“感知置信度 < 0.3”的帧。
可能追问:① 实车路试发现 corner case 后,如何快速反哺到仿真库?② 如何评估测试用例集的充分性?③ 多传感器时间不同步导致的测试缺陷你有方案吗?
避坑提醒:不要只说“多测就行”,要量化用例数量与覆盖度指标;不要混用“测试用例”和“测试场景”;忘记提自动化回归会被认为效率低。
📁 项目案例模板
说明:面试中遇到“你做过什么感知测试项目”时,直接套用此模板结构,STAR 输出。
| 项目名称 | 城市 NOA 感知模块性能评测与回归体系搭建 |
| 业务背景 | 某 L2+ 车型需在 10 个城市开放 NOA,感知模块需通过严格的安全性评测,同时支持每两周一次的模型迭代回归。 |
| 规模指标 | 标注数据 5000 帧 / 版本;仿真场景库 20000+;实车路测 3000 km / 月;全链路回归耗时从 48h 压缩到 6h。 |
| 技术栈 | ROS2 / CyberRT、Python、C++、Docker、Jenkins、PyTorch(仅推理)、PointPillars + YOLOX |
| 核心难点 | ① 多传感器时间戳对齐偏差导致评测结果波动;② 实车 corner case 无法快速注入仿真;③ 回归测试 case 增长导致人力资源瓶颈。 |
| 面试高频追问 | ① 你们用什么指标衡量“充分性”?答:场景正交覆盖率 + 随机扰动混入比例。② 时间同步问题怎么解决的?答:硬件 PTP 同步 + 软件双缓冲补偿。③ 如何防止过拟合到仿真场景?答:定期用真实路采盲测对照。 |
| 可迁移回答话术 | “在该项目中我负责搭建从数据标注到实车路测的完整评测流水线,核心思路是‘仿真快速验证 + 实车精准回放’相结合。针对时间同步问题,我推动硬件 PTP 同步方案,并在评测脚本中加入了抖动容忍逻辑。最终将版本迭代周期从 2 周缩短至 4 天,并在后续三个城市顺利落地。” |
👆 直接套用技巧:替换项目名称、规模数字、技术栈和对应困难,保持“技术方案 + 量化成果”的句式,面试官会觉得你项目经验真实且可迁移。