2026年自动驾驶测试工程师高频面试题包含详细解答

自动驾驶测试工程师高频面试题

【精选近三年60道高频面试题】

【题目来源：学员面试分享复盘及网络真题整理】

【注：每道题含高分回答示例+避坑指南】

1.什么是自动驾驶的ODD（设计运行域），在设计NOA（领航辅助驾驶）测试用例时如何

界定ODD边界？（基本必考|重点准备）

2.简述激光雷达（LiDAR）和毫米波雷达（Radar）在雨雪天气下的性能差异及测试关注

点。（极高频|需深度思考）

3.介绍一下自动驾驶测试体系中的MIL、SIL、HIL和VIL，以及它们各自的优缺点和适用阶

段。（基本必考|背诵即可）

4.在HIL（硬件在环）测试中，如何保证注入的传感器信号（如摄像头视频流或激光雷达点

云）的实时性与同步性？（常问|考察实操）

5.ISO26262中的ASIL等级是如何划分的？请举例说明自动驾驶系统中哪个模块通常需要达

到ASILD级别。（基本必考|背诵即可）

6.什么是SOTIF（预期功能安全，ISO21448），它与ISO26262有什么区别？在路测和仿

真测试中如何覆盖SOTIF场景？（常问|需深度思考）

7.简述CANFD与传统CAN总线的区别，以及车载以太网（AutomotiveEthernet）在自动驾

驶系统中的应用优势。（极高频|背诵即可）

8.解释一下ROS（或ROS2）中的Topic、Service和Action的区别，测试时如何抓取和分析

rosbag数据？（基本必考|考察实操）

9.在自动驾驶车辆的坐标系转换中，从车辆坐标系（VehicleFrame）转换到世界坐标系

（WorldFrame）通常需要获取哪些参数？（常问|重点准备）

10.请详细描述一下AEB（自动紧急制动）功能的测试用例设计思路，根据E-NCAP等标准，

需要覆盖哪些典型的测试场景？（极高频|考察实操）

11.在进行ACC（自适应巡航）路测时，如果前车突然切出（Cut-out），暴露出前方静止车

辆，测试工程师应重点记录系统的哪些响应指标？（基本必考|重点准备）

12.针对LCC（车道居中控制）功能，遇到曲率极大的弯道或者车道线磨损严重的场景，测

试时如何评估系统的接管请求（ToR）机制？（常问|需深度思考）

13.什么是OpenSCENARIO和OpenDRIVE标准？在仿真软件中如何利用它们自动化生成和搭

建测试场景？（常问|考察实操）

14.描述一次你参与过的最复杂的自动驾驶功能测试项目，你在其中承担了什么角色，为什么

当时的测试策略是这样设计的？（基本必考|重点准备）

15.在搭建自动化测试流水线（CI/CD）时，你是如何将代码提交、每日构建（Nightly

Build）与自动化仿真测试结合起来的？（学员真题|考察实操）

16.针对BEV（鸟瞰图）+Transformer架构的感知算法，测试方法与传统的分块感知（如2D

检测+测距）算法测试有何不同？（极高频|需深度思考）

17.请举例说明如何利用真实路测数据（Log）通过数据挖掘技术，批量生成或提取仿真测试

的CornerCase（长尾场景）？（学员真题|需深度思考）

18.在设计自动泊车（APA/AVP）的测试用例时，如何全面覆盖各种非标车位、地锁、以及

光线突变（如进出地库）的情况？（极高频|重点准备）

19.针对自动驾驶系统中的“幽灵刹车”（PhantomBraking）问题，如果你在路测中遇到了，

会如何收集数据并协助研发排查深层原因？（极高频|需深度思考）

20.在路测过程中，安全员突然紧急接管了车辆，作为测试工程师，你需要立刻记录和排查哪

些软硬件维度的关键信息？（基本必考|考察实操）

21.当发现一版新的感知模型在雨天场景下漏检率异常升高，你会如何设计对照实验来定位是

算法Regression（退化）还是数据集分布问题？（学员真题|需深度思考）

22.HIL台架测试中发现CAN报文丢失或延迟，导致控制器进入降级模式，你通常的排查思路

和验证方法是什么？（常问|考察实操）

23.路测时发现车辆在经过特定高楼林立的路口时总会发生定位漂移或短暂丢失，你认为可能

的原因有哪些？如何复现并验证修复结果？（极高频|重点准备）

24.遇到过最难推进的Bug是什么？如果开发人员认为你提的Bug是“偶现问题无法复现，不予

修复”，作为测试工程师你该如何处理？（常问|考察软实力）

25.在进行传感器外参标定（Calibration）验收测试时，如果发现激光雷达和摄像头的融合点

云存在明显偏差，如何排查是外参计算问题还是硬件时间同步问题？（学员真题|需深度

思考）

26.测试车辆在执行NOA自动变道时，对侧后方高速接近的车辆未能做出正确响应，请分析

从感知、预测到规控链路中可能存在的失效节点。（基本必考|重点准备）

27.如果要求你用Python或C++编写一个脚本，批量解析数GB的ROSbag数据并提取触发急

刹的事件帧，你会如何优化代码以提升解析速度？（学员真题|考察实操）

28.在封闭场地做VUT（被测车辆）与GVT（全球车辆目标，即假车）碰撞测试预演时，测试

设备通讯突然中断，你如何快速诊断并恢复测试环境？（常问|考察抗压）

29.请分享一个你在实际测试中发现的，开发人员起初完全没有预料到，但极其危险的自动驾

驶EdgeCase（边界场景）。（极高频|需深度思考）

30.针对高精地图（HDMap）的鲜度与误差问题，测试团队如何验证系统在遇到地图数据与

实际物理道路不符（如临时修路改道）时的接管和降级策略？（常问|重点准备）

31.端到端（End-to-End）自动驾驶大模型类似于一个黑盒，如果它在仿真测试中发生了碰撞

事故，测试应该如何为这种黑盒模型提供有效的Bug分析和复现依据？（极高频|需深度

思考）

32.自动驾驶系统在高温环境下运行2小时后，算力平台出现降频导致感知帧率下降并触发系

统异常，如何针对此类问题设计系统级的极限工况测试？（学员真题|考察实操）

33.简述CAPL语言在自动驾驶CAN/LIN网络测试中的应用，你会如何编写脚本模拟一个雷达

节点宕机或发送错误CRC的报文？（常问|考察实操）

34.在进行多车协同或V2X功能测试时，如何解决路端（RSU）设备与车端（OBU）之间的

时间戳对齐和通信延迟抖动问题？（常问|需深度思考）

35.对于高度依赖云端和网络的远程代客泊车（AVP）功能，在网络信号弱或完全中断（如地

下车库无覆盖）的场景下，应如何测试车辆的底线安全性？（基本必考|重点准备）

36.如果发现路测车辆的车机系统时间与GPS硬件时间存在几十毫秒的随机跳变跳变差异，

这会对多传感器融合造成什么致命影响？你如何用数据证明这种影响？（学员真题|需深

度思考）

37.测试过程中，如果当前的自动化仿真回归集运行时间过长（例如超过12小时），严重阻

塞了算法的发版节奏，你会采取哪些技术手段进行优化？（常问|重点准备）

38.简述功能安全中FMEA（失效模式与影响分析）和FTA（故障树分析）在逻辑分析上的主

要区别，并举例说明如何基于FMEA报告提取对应的故障注入测试用例。（常问|背诵即

可）

39.在评价一次NOA领航辅助驾驶的体感舒适性时，除了加速度和加加速度（Jerk），你还会

提取并分析哪些客观数据指标来量化评估？（基本必考|重点准备）

40.当遇到上下游模块为了一个接管事件推诿定责（例如规控认为是感知的误检导致急刹，感

知认为是规控的置信度阈值标定不合理）时，测试如何用客观数据还原真相并定责？

（极高频|考察软实力）

41.介绍一种你熟悉的自动驾驶仿真评测指标体系（KPIMetrics），如何科学衡量自动驾驶

算法在一个复杂拥堵的仿真路口中的表现是“通过”还是“不通过”？（常问|需深度思考）

42.在城市NOA（城市领航）实车测试中，面对复杂的“中国式过马路”（行人、非机动车混行

穿插），你会重点设计哪些博弈（GameTheory）与防御性驾驶测试场景？（极高频|重

点准备）

43.请说明基于规则（Rule-based）的规控算法测试与基于强化学习（RL）或神经网络的规

控算法测试，在测试用例设计思路上有哪些本质区别？（常问|需深度思考）

44.针对车路云一体化方案，如果云端下发的全局路径指令与车端本地规控计算出的局部路径

产生严重冲突时，测试用例应当如何验证系统的决策仲裁机制？（学员真题|需深度思

考）

45.介绍一下你在排查路测问题时常用的数据可视化工具（如Foxglove、Rviz、PlotJuggler

等），以及你如何利用它们高效回放、对齐和定位感知与规控的异常帧。（基本必考|考

察实操）

46.当自动驾驶车辆的某个超声波雷达在行驶中被泥浆或者冰雪完全遮挡致盲，测试如何有效

验证系统的故障自诊断（DTC）及相应的HMI声光报警降级机制？（极高频|考察实操）

47.在编写自动化仿真脚本时，如何实现场景内交通参与者（NPC车辆/行人）的高级动态行

为逻辑（如逼停、加塞、变道让行），以增加测试场景的博弈逼真度？（常问|考察实

操）

48.对比基于真实数据驱动（Data-Driven）的闭环仿真测试与传统的主观设计的场景库

（Scenario-Based）测试，两者的核心难点和测试价值分别在哪里？（常问|需深度思

考）

49.假设距离项目SOP（量产发车）只有两周，但在高强度的压力测试中发现了极低概率导

致智驾域控制器重启的内核级Bug，你作为测试Leader该如何评估风险并做决策？（学

员真题|考察抗压）

50.简述在Linux或QNX车载操作系统环境下，如何通过命令行监控自动驾驶相关进程的

CPU、内存、GPU占用率，以及遇到内存泄漏（MemoryLeak）时的常规排查步骤。

（基本必考|考察实操）

51.请分享一个由于底层硬件性能瓶颈（如ISP图像处理延迟过高或总线带宽负载占满）导致

自动驾驶功能突然失效，并被你成功通过极端测试场景挖掘出来的实战案例。（网友分

享|需深度思考）

52.测试中发现车辆对前方异形障碍物（如侧翻的特种车辆、散落的纸箱等）不识别或识别过

晚，从占据网格网络（OccupancyNetwork）等前沿感知算法角度，测试该如何提供有效

的高质量错例反馈？（极高频|重点准备）

53.面对行业内普遍存在的“堆路测里程数”现象，你如何看待自动驾驶的“长尾效应”（Long

TailEffect），并阐述如何通过影子模式（ShadowMode）等机制更高效地进行系统验

证。（常问|需深度思考）

54.自动驾驶系统从L2向L3演进的过程中，出险的接管责任由人转移到了车厂。从测试的严

谨性来看，针对L3级系统除了验证原有功能本身的上限，还需要重点增加哪些安全冗余

（Redundancy）机制的专项测试？（极高频|需深度思考）

55.近期各大车企都在加速落地“无图NOA”（不依赖高精地图的城市领航辅助），针对这种重

感知轻地图的技术路线，你认为路测和仿真测试的重心和痛点应该发生怎样的转变？

（极高频|需深度思考）

56.简述大语言模型（LLM）或多模态视觉大模型（VLM）在自动驾驶测试领域（例如自动化

场景生成、自动真值标注或自动解析Log问答）可能的应用前景及当前落地存在的局限

性。（常问|需深度思考）

57.如果赋予你充分的资源，让你从0到1组建一个完整的自动驾驶系统测试团队（涵盖封闭

场地测试、开放道路测试和海量仿真测试），你会如何规划第一年的软硬件基础设施建

设、工具链开发和测试人员结构配置？（学员真题|重点准备）

58.在长途高速NOA的耐久性测试（EnduranceTesting）中，测试安全员和工程师极易产生

驾驶疲劳导致漏记问题，如何通过自动化打点工具或车内监控辅助开发来降低人力成本并

提高异常数据的捕捉召回率？（网友分享|考察实操）

59.结合你过往填过无数个“坑”的经验，自动驾驶测试工程师的核心业务护城河究竟是什么？

在AI算法一日千里、端到端大模型飞速迭代的今天，你如何保持自己在测试领域的不可替

代性？（极高频|考察软实力）

60.我问完了，你有什么想问我的吗？（面试收尾）

【自动驾驶测试工程师】高频面试题深度解答

Q1：什么是自动驾驶的ODD（设计运行域），在设计NOA（领航辅助驾驶）测

试用例时如何界定ODD边界？

❌不好的回答示例：

ODD就是自动驾驶能开启的条件，比如天气好不好、是不是在高速上。设计NOA测

试用例的时候，我们主要就是看车能不能在高速上跑，能不能识别车道线。如果下

大雨或者没有车道线了，那就超出了ODD，车就应该退出了。所以测试用例主要覆

盖正常天气和标准的道路情况就行了，稍微加一点晚上的场景。

为什么这么回答不好：

1、认知过于浅薄：将ODD简单等同于“天气和道路”，忽略了交通参与者、自车状

态、速度限制等多维度的参数定义，缺乏系统性思维。

2、逻辑结构缺失：没有给出如何界定边界的具体实操步骤，完全停留在泛泛而谈

的概念层面。

3、错失展示价值的机会：完全没有提到边界条件（CornerCase）的测试，而

ODD的边界测试正是测试工程师体现专业度的核心地带。

高分回答示例：

我通常的逻辑是，ODD不仅是系统的“保护伞”，更是测试用例设计的“说明书”。在

界定NOA的ODD边界时，我会严格从五个维度进行降维拆解：环境（天气/光

照）、道路（高速/高架/匝道/曲率）、交通参与者（车流量/异形车）、自车状态

（速度范围/载重）以及依赖条件（高精地图覆盖率/GPS信号）。

具体实操分为三步：1、提炼静态与动态边界。静态边界例如NOA仅限结构化道

路，我会通过地图API获取非结构化道路交界点，设计“高速下匝道至城市道路”的平

滑退出用例；动态边界例如最大运行速度120km/h，我会设计125km/h下开启被拒

的用例。2、设计跨边界的降级测试（GracefulDegradation）。在NOA运行中，

如果突然遭遇暴雨导致传感器被遮挡（脱离ODD），最核心的风险点是系统能否及

时发出接管请求（ToR）并留出足够的安全接管时间。我会注入传感器失效故障，

测试系统是否能在规定秒数内完成最小风险策略（MRM）。3、组合边界参数。

将“大曲率弯道”与“黄昏逆光”组合，测试感知算法的鲁棒性。

每次大版本测试后，我会将实车接管数据与ODD定义库进行对比复盘，如果发现大

量接管发生在所谓的“ODD内”，说明我们的边界定义过宽或算法不达标，必须倒逼

研发修改系统规范，防止伪需求上线。

Q2：简述激光雷达（LiDAR）和毫米波雷达（Radar）在雨雪天气下的性能差

异及测试关注点。

❌不好的回答示例：

激光雷达发的是激光，雨雪天水滴会把光挡住或者反射，所以它在雨雪天效果很

差，可能会看不清东西。毫米波雷达穿透力很强，不怕雨雪，所以这种天气下主要

靠毫米波雷达。测试的时候，我们就找个下雨天，把车开出去，看看激光雷达的点

云是不是变少了，然后看看毫米波雷达能不能正常测距，有没有撞到前面的车就行

了。

为什么这么回答不好：

1、原理理解粗糙：只说出了表面现象，没有点出激光的散射吸收机制以及毫米波

雷达的多径效应带来的具体业务痛点（如幽灵刹车）。

2、测试手段原始：“找个下雨天开出去”这种靠天吃饭的测试方法完全不符合工程

化、自动化的测试标准。

3、缺乏度量指标：回答中没有任何量化指标，无法体现对感知模块评测的专业

度。

高分回答示例：

在雨雪这种典型的恶劣工况下，两类传感器的失效模式截然不同。激光雷达的波长

较短（通常为905nm或1550nm），极易被雨滴和雪花发生米氏散射和吸收，导致

点云稀疏、有效探测距离锐减，甚至将密集的雨雪误判为噪点墙（NoiseWall）。

而毫米波雷达波长较长，能穿透雨雪，但路面积水会导致严重的电磁波多径反射，

产生大量虚假目标。

针对这种特性，我的测试策略是：1、构建标准化的降雨/降雪环境。通过气象模拟

舱或在仿真软件（如VTD/CARLA）中注入雨滴粒子和水面材质反射参数，而非单

纯依靠自然天气，以保证测试用例的可重复性。2、设定严格的感知KPI指标。对激

光雷达，重点监控“漏检率（FalseNegative）”和“最大稳定追踪距离”的衰减曲

线；对毫米波雷达，最核心的风险点是“误检率（FalsePositive）”，我会重点抓

取因水面反射导致的“幽灵障碍物”是否会触发下游的非预期急刹（AEB/ACC错

开）。3、验证异构传感器融合策略。在雨雪模式下，测试规控逻辑是否能动态调

低激光雷达的置信度权重，并平滑拉升雷达和摄像头的权重。

这套逻辑能够有效拦截感知退化带来的危险工况。发现问题后，我会将特定雨雪强

度的点云录包作为回归测试集（GoldenDataset），固化到CI流水线中，防止后续

感知模型更新时出现性能倒退。

Q3：介绍一下自动驾驶测试体系中的MIL、SIL、HIL和VIL，以及它们各自的优

缺点和适用阶段。

❌不好的回答示例：

MIL是模型在环，就是测Simulink模型；SIL是软件在环，测C代码；HIL是硬件在

环，把代码刷到真实控制器里测；VIL是整车在环，就是拿真车去测。MIL和SIL比

较便宜，跑得快，但是不真实。HIL和VIL很真实，能发现真正的问题，但是太贵了

而且很花时间。我们一般都是最后用车测一下，没问题就交付了。

为什么这么回答不好：

1、解释像背书：只是机械地翻译了缩写，没有说透它们在整个自动驾驶V模型开发

周期中的上下游依赖关系。

2、优缺点太笼统：“真实/不真实”、“贵/便宜”是非常业余的表达，缺少对底层算

力、操作系统差异、总线延迟等工程细节的剖析。

3、暴露出流程缺陷：“最后用车测一下”这种作坊式的回答，严重违背了现代车

企“测试左移”和“持续集成”的核心理念。

高分回答示例：

这四个环节构成了自动驾驶V字开发模型的完整闭环，我通常的逻辑是坚决推行“测

试左移”，在不同阶段利用不同工具的特性来降本增效。

1、MIL（模型在环）处于算法设计极早期。验证的是控制逻辑（如纯数学公式和状

态机）的正确性。优点是无需编译，迭代极快；缺点是脱离了具体的硬件算力约

束。2、SIL（软件在环）是将模型生成C/C++代码并在PC或云端服务器上运行。

在这一阶段，最核心的风险点是数据类型的截断误差。我会利用云端算力进行海量

Scenario的并发泛化测试，它的产出是拦截掉90%的规控逻辑Bug。3、HIL（硬件

在环）是自动驾驶落地的分水岭。此时软件运行在真实的域控制器（如OrinX）

上。其不可替代的价值在于能暴露操作系统的调度延迟、CAN/以太网总线负载过高

以及硬件热降频等隐性问题。4、VIL（整车在环）一般在台架或封闭场地进行，通

过给真车注入虚拟传感器信号。它的优势在于能结合真实的底盘执行器（如真实卡

钳的液压响应），验证系统闭环的控制体感。

实践中，任何在VIL阶段发现的Bug，我都会强制要求团队在SIL或HIL中搭建对应

的复现用例。如果不能在前端拦截，说明我们的虚拟测试链条存在断层，必须补

齐。

Q4：在HIL（硬件在环）测试中，如何保证注入的传感器信号（如摄像头视频流

或激光雷达点云）的实时性与同步性？

❌不好的回答示例：

为了保证实时性，我们会用配置很高的电脑来跑仿真软件，用千兆网线连接HIL机

柜，这样数据传输就会很快。至于同步性，我们就在仿真软件里把摄像头和激光雷

达的帧率设置好，比如摄像头30帧，雷达10帧，然后一起点开始播放。如果发现不

同步了，就重启一下设备，或者让开发查一下是不是代码卡了。

为什么这么回答不好：

1、技术选型错误：用千兆网线（以太网协议栈）传输视频流会带来不可控的协议

栈延迟，这在真实的自动驾驶HIL台架中是绝对不被允许的。

2、同步概念混乱：仅仅设置帧率并不是时间同步，完全没有提及PTP、PPS、时

间戳对齐等行业标准协议。

3、排查思路业余：“重启一下”毫无工程素养，没有给出监控和量化延迟偏差的具体

手段。

高分回答示例：

在HIL环境中，高带宽传感器信号的注入延迟和相位偏差是导致规控算法崩溃的致命

元凶。解决这个痛点，我通常从物理链路与时间同步协议两个维度下手。

1、在实时性保障上，坚决摒弃标准的TCP/IP网络栈注入。对于摄像头视频流，我

会采用专用的视频注入板卡，将仿真软件渲染的画面直接转换为GMSL或FPD-Link

等车载串行物理协议，直接绕过域控的以太网MAC层，将注入延迟严格控制在几毫

秒的系统级硬实时范围内。2、在同步性保障上，核心是统一“上帝时钟”。我会在

HIL台架中配置专门的硬件时间同步服务器，通过PTP/gPTP（精确时间协议）或硬

件PPS（秒脉冲）+NMEA报文，将仿真主机、注入板卡和被测域控制器的系统时

间强行对齐。3、具体产出与效果监控。在测试执行时，我会在报文层面抓取传感

器数据的HeaderTimestamp（生成时间）与域控接收到的时间差。

如果多传感器的时间戳偏差超过设定的阈值（例如超过1/2个感知周期，即

50ms），我会判定该帧数据为“脏数据”并截断测试。完成测试后，分析掉帧率和延

迟抖动（Jitter）分布图，这是评估HIL台架本身置信度的关键指标。

Q5：ISO26262中的ASIL等级是如何划分的？请举例说明自动驾驶系统中哪个

模块通常需要达到ASILD级别。

❌不好的回答示例：

ASIL分为A、B、C、D四个等级，D级是要求最高的，A级是最低的。划分的标准

主要是看如果坏了会不会死人，发生概率大不大。在自动驾驶里，我觉得刹车和方

向盘肯定是要达到ASILD的，因为如果刹车坏了或者方向盘自己乱转，车肯定会

撞，人就会有危险。其他像屏幕什么的可能要求就低一点。

为什么这么回答不好：

1、术语不规范：用“会不会死人”、“发生概率大不大”等口语化表达代替了严重度、

暴露率和可控性三大核心参数。

2、系统边界不清：面试官问的是“自动驾驶系统中的模块”，而回答的“刹车和方向

盘”属于底盘执行器，没有点出自动驾驶域控制器内部的模块划分。

3、缺乏工程深度：没有阐述为了达到ASILD级别，测试层面需要做哪些冗余验证

或故障注入工作。

高分回答示例：

ASIL（汽车安全完整性等级）的评定并不是拍脑袋，而是基于HARA（危害分析与

风险评估）体系，严格通过三个维度的乘积来推导：严重度（Severity，S1-

S3）、暴露率（Exposure，E1-E4）和可控性（Controllability，C1-C3）。只有

当三者同时达到较高危险级别（如S3+E4+C3）时，才会被定为ASILD。

在自动驾驶域控制器中，主干的轨迹规划（Planning）模块以及与底盘交互的车辆

控制（Control）模块必须达到ASILD。在XX这种高速行驶的工况下，如果规划模

块输出一个满偏的转向指令，最核心的风险点是驾驶员根本无法在极短时间内拉回

方向盘（可控性极低）。针对此类ASILD模块，我通常的测试抓手是：1、基于

FTA（故障树分析）生成测试矩阵。不测正常功能，专测异常注入，如篡改CAN总

线的扭矩请求报文（注入AliveCounter错误或Checksum校验错误）。2、验证安

全冗余机制。测试监控节点（SafetyMonitor）能否在规定的故障容错时间

（FNTI，如低于10毫秒）内切断主控输出，并将车辆控制权安全地交给降级备份模

块。

通过这种极限的硬件在环故障注入测试，我们不仅能验证功能逻辑，更能输出符合

合规审查的ASILD级别的量产测试验证报告。

Q6：什么是SOTIF（预期功能安全，ISO21448），它与ISO26262有什么区

别？在路测和仿真测试中如何覆盖SOTIF场景？

❌不好的回答示例：

ISO26262主要是管系统硬件坏了怎么办，比如线断了或者芯片烧了。SOTIF是说

东西都没坏，但是因为设计得不好导致出了车祸。比如下大雨看不见路就是

SOTIF。我们在路测的时候多跑跑不同的天气，遇到问题就记下来。仿真测试就是

多建一些不同的模型去跑，尽量多覆盖一些不常见的情况，这样就能解决SOTIF的

问题了。

为什么这么回答不好：

1、定义解释不精确：SOTIF的核心是“性能局限性”或“合理可预见的误用”，不仅仅

是“设计不好”，回答没有触及四区模型（已知安全、已知不安全等）。

2、测试策略太水：“多跑跑”、“多建模型”毫无指导意义，缺乏穷举和收敛的方法

论。

3、未突出两者协作：没有说明在实际测试体系中，功能安全与预期功能安全是如

何交叉验证的。

高分回答示例：

我通常用“有病治病”和“没病防灾”来区分这两者。ISO26262解决的是因电子电气

系统故障（软硬件系统性或随机性失效）引发的风险；而SOTIF（预期功能安全）

解决的是系统完全无故障运转，但因传感器物理局限性、算法性能不足或用户的可

预见误用而导致的风险。

在SOTIF的理论中，测试的核心目标是不断缩小“未知且不安全”的区域（Area

3），并穷尽“已知且不安全”的区域（Area2）。我的具体执行路径是：1、仿真环

境下的参数泛化搜索。针对摄像头被强光致盲这一典型SOTIF场景，我会利用自动

化脚本，对太阳的高度角、自车速度、前车距离等参数进行正交组合与蒙特卡洛随

机采样，通过上万次仿真精准界定触发AEB漏触发的临界阈值。2、路测环境下的

长尾数据挖掘。部署影子模式（ShadowMode），当人类驾驶员的操作与自动驾

驶后台计算的轨迹产生严重分歧时，自动截取该段Log。3、人机交互（HMI）误用

测试。比如测试驾驶员在NOA状态下长时间脱手甚至使用欺骗环，系统是否具备分

级的驾驶员疲劳监控（DMS）惩罚机制。

这类测试的产出会直接反哺给系统工程团队，通过增加ODD限制或调整传感器布置

来达成SOTIF的风险闭环，防止同类盲区在SOP后引发大规模召回。

Q7：简述CANFD与传统CAN总线的区别，以及车载以太网（Automotive

Ethernet）在自动驾驶系统中的应用优势。

❌不好的回答示例：

CAN总线是以前车上用的，速度很慢，只有1兆。CANFD是升级版，速度快一

点，能传更多的数据。现在自动驾驶数据太多了，这俩都不够用，所以要用车载以

太网。以太网就像我们家里的网线一样，速度特别快，能传摄像头的高清视频和激

光雷达的数据，所以现在新车都在用以太网。

为什么这么回答不好：

1、数据指标不准：没有明确说出CANFD的具体波特率上限和数据载荷长度的变

化，显得基础不扎实。

2、技术细节缺失：对车载以太网的描述过于生活化，没有点出100BASE-T1等车

载专用物理层标准，也未提及SOME/IP等面向服务的通信协议。

3、缺乏业务场景：没有将这些总线协议与具体的自动驾驶测试排查场景（如网络

负载率监控）结合起来。

高分回答示例：

在进行整车网络架构验证时，理清这三者的边界是排查通信丢包和延迟问题的基

础。传统CAN总线最大波特率受限于1Mbps，且每帧有效载荷仅8字节，这在传输

ADAS大量的雷达目标物（ObjectList）时会导致总线负载率极高，引发报文延

迟。

CANFD（可变数据速率CAN）的核心突破在于“可变”。它的仲裁段保持标准速

率，但在数据段可提升至5Mbps甚至8Mbps，并且数据载荷扩大至64字节。这极大

地提升了打包效率。在XX项目中，我曾通过把多雷达节点的通信切换为CANFD，

将原本达到85%的危险负载率成功降至40%以下。

而面对自动驾驶域控中动辄百兆级别的激光雷达点云，车载以太网（如

100/1000BASE-T1，采用单对非屏蔽双绞线以减轻线束重量）成为刚需。它的应

用优势不仅在于高带宽，更在于支持SOA（面向服务的架构）。在测试端，这彻底

改变了我们的测试逻辑。我们不再是去死磕底层的信号矩阵，而是利用SOME/IP协

议，通过服务订阅和发布（Pub/Sub）机制来动态监控系统状态。这不仅提高了诊

断刷写的效率，也使得通过以太网向域控直接注入高保真度的仿真传感器数据成为

可能。

Q8：解释一下ROS（或ROS2）中的Topic、Service和Action的区别，测试时

如何抓取和分析rosbag数据？

❌不好的回答示例：

Topic就是主题，一个发一个收，适合一直发的数据。Service是服务，发个请求必

须等回复才能继续。Action也是服务，但是它能看到进度条，适合执行比较久的动

作。测试的时候，我就在终端输入rosbagrecord-a，把所有数据录下来。然后用

rosbagplay回放，盯着屏幕看车是怎么走的，如果走偏了就说明有Bug，把包发给

开发去查。

为什么这么回答不好：

1、对Action理解太俗：“进度条”是极其外行的比喻，没有点出Action的异步反馈和

可抢占/可取消特性。

2、录包操作极其危险：rosbagrecord-a在自动驾驶实车上是灾难性操作，会瞬

间占满磁盘I/O导致系统卡死崩溃。

3、分析手段落后：靠“盯着屏幕看回放”来找Bug是纯手工黑盒测试，没有体现数据

脚本分析的自动化能力。

高分回答示例：

这三种通信机制在自动驾驶架构中承担着截然不同的任务，弄混它们会导致系统出

现严重的阻塞或时序混乱。

1、Topic是异步单向的发布/订阅模型，用于高频、连续的数据流（如10Hz的激光

雷达点云或车辆底盘状态）。2、Service是同步阻塞的请求/响应模型，适合低频、

要求即时结果的逻辑触发（如向地图模块请求某一路口的拓扑结构）。3、Action

是带有状态反馈的异步请求模型。在全局路径规划（如自动泊车驶入车位）这种耗

时较长的任务中，最核心的风险点是任务卡死。Action不仅能持续反馈

（Feedback）行驶进度，更允许规控节点在遇到紧急障碍物时随时下发Cancel指

令中断任务。

在测试实操中，我绝不会使用record-a，而是编写launch文件精准录制所需的

Topic列表，并严格限制单包大小（如2GB）以防止I/O阻塞。抓取到rosbag后，我

通常的分析逻辑是：拒绝肉眼看回放，而是使用Python的rosbagAPI或rclpy解

析脚本。比如遇到急刹问题，我会写脚本自动提取/control_cmd话题的加速度跳变

点，反向对齐同一时间戳的/perception_obstacles话题，判断是否出现了“幽灵障

碍物”。最后通过Foxglove等工具进行数据可视化展示，拿着确凿的延时或丢帧数

据去找开发定责，避免无谓的推诿。

Q9：在自动驾驶车辆的坐标系转换中，从车辆坐标系（VehicleFrame）转换

到世界坐标系（WorldFrame）通常需要获取哪些参数？

❌不好的回答示例：

要把车辆坐标系转到世界坐标系，首先要知道车在世界上的经纬度，这个可以通过

GPS获取。然后还要知道车头的方向，就是航向角。拿到这两个数据后，用一个旋

转平移矩阵算一下，就能把车上雷达看到的障碍物坐标，转换到地图上的世界坐标

了。如果GPS信号不好，转出来的坐标就会不准，地图上车的位置就会飘。

为什么这么回答不好：

1、参数遗漏严重：只提了经纬度和航向角，完全忽略了高程（海拔）、俯仰角

（Pitch）和横滚角（Roll），在坡道上会导致严重的投影误差。

2、忽视硬件杆臂误差：没有提及GNSS天线、IMU中心与车辆后轴中心（通常为

VehicleFrame原点）之间的外部标定参数。

3、缺乏动态时间对齐意识：坐标转换不是静态的几何题，在高速运动中，时间戳

不严格对齐会导致转换结果出现巨大偏差，这是测试中极易踩坑的点。

高分回答示例：

在自动驾驶中，坐标系的链式转换是整个感知融合与高精地图匹配的基石。从车辆

坐标系（原点通常定义在车辆后轴中心点，X向右，Y向前，Z向上）转换到世界坐

标系（如UTM或ENU坐标系），我通常的排查逻辑会聚焦在两个维度的参数输入

上。

1、绝对位姿参数（Translation&Rotation）。必须依赖高精度的GNSS+IMU组

合导航系统（RTK）。我们需要获取车辆在世界坐标系下的三维平移量（经度、纬

度、高程转换为X,Y,Z坐标），以及三维旋转量，即偏航角（Yaw）、俯仰角

（Pitch）和横滚角（Roll）。如果缺失Pitch和Roll，车辆在上下坡或颠簸路面时，

投影到世界坐标系中的障碍物距离会出现几十米的巨大误差。2、标定与杆臂参数

（LeverArm）。IMU的安装位置绝大多数不在后轴中心，因此必须引入两者之间

的固定平移外参矩阵进行补偿计算。

在XX项目的实测中，最容易踩坑的根本不是公式写错，而是动态时延。如果传感器

数据（10Hz）和位姿数据（100Hz）的时间戳对齐出现10毫秒的误差，在

120km/h的车速下就会产生约0.3米的坐标偏移。因此，在分析坐标漂移Bug时，我

的首要动作是抓取底层的PTP时钟同步Log，排除时间域的错位后，再去验证空间

域的矩阵运算。

Q10：请详细描述一下AEB（自动紧急制动）功能的测试用例设计思路，根据

E-NCAP等标准，需要覆盖哪些典型的测试场景？

❌不好的回答示例：

测AEB就是看快撞上的时候车能不能自己刹住。根据标准的规定，我们会设计几种

场景，比如前面放一个假车，我们开着车去撞它，看它能不能停下来。还有就是放

个假人走过去，看车能不能识别并刹车。白天要测，晚上也要测。速度的话就从20

码开始，一直测到60码。如果都能刹住没有撞到，那我们的AEB测试就通过了。

为什么这么回答不好：

1、场景刻画太糙：没有运用E-NCAP的专业术语（如CCR、VRU），也没有说明

静止、运动、减速等不同的目标行为。

2、缺失关键边界条件：完全没有提到碰撞重叠率（OverlapRatio），而重叠率是

考验感知系统盲区和规控决策的重中之重。

3、评价标准单一：只以“撞没撞到”为标准，忽略了TTC（碰撞时间）、减速度曲

线、报警时机（FCW）等核心工程指标。

高分回答示例：

AEB是自动驾驶最后一道保命的底线，其测试极其强调整体性和标准化。我通常会

以E-NCAP/C-NCAP的最新评价规程为基准，将测试用例拆解为纵向车辆

（CCR）和弱势交通参与者（VRU）两大核心矩阵。

1、在CCR（Car-to-CarRear）场景中，我会严格覆盖CCRs（前车静止）、

CCRm（前车匀速运动）和CCRb（前车紧急制动）三种工况。最核心的风险点在

于目标重叠率，我会通过驾驶机器人（DrivingRobot）精确控制自车，分别测试

100%、50%以及边缘的25%重叠率。重叠率越小，对雷达和摄像头的横向视野分

辨率要求越苛刻，极易出现漏检。2、在VRU场景中，重点测试CPFA（儿童从障碍

物后跑出穿行）和CBLA（自行车纵向行驶）。尤其是夜间弱光工况下横穿的黑色

衣服行人，这是考验摄像头动态感光的极限CornerCase。

执行这类高危测试时，评价体系不仅是“是否发生碰撞”。我会提取车载数据采集器

上的报文，量化分析三个指标：FCW（前向碰撞预警）触发时的TTC（碰撞时间）

是否留够了驾驶员反应时间；AEB触发瞬间的Jerk（加加速度）是否平顺；以及最

大制动减速度是否达到0.8g以上。测试复盘时，任何不满足指标的录包都会被清洗

出来，用于下一版感知算法的针对性强化。

Q11：在进行ACC（自适应巡航）路测时，如果前车突然切出（Cut-out），暴

露出前方静止车辆，测试工程师应重点记录系统的哪些响应指标？

❌不好的回答示例：

遇到前面车突然变道走掉，露出一个停着的车，这时候很危险。我会赶紧看我们的

车有没有自动刹车，如果没有我就自己踩刹车接管。然后我会记录下发生这件事的

地点、时间和当时的车速。回去以后告诉开发，说我们车在Cut-out场景下没认出前

面的静止车，差点撞了，让他们查一下是不是雷达或者摄像头没看到。

为什么这么回答不好：

1、操作极其被动：作为测试工程师，只承担了“安全员”的角色，没有在测试发生时

抓取客观数据的意识。

2、反馈信息无效：“差点撞了”、“查一下雷达”这种口语化的描述对开发复现和解决

问题毫无帮助。

3、遗漏核心逻辑：Cut-out场景的核心难点是“目标ID的快速切换与静止目标的剔除

策略”，回答中完全没有触及这一底层机制。

高分回答示例：

Cut-out（前车切出暴露静止目标）是ACC/NOA在高速场景下致死率极高的危险工

况。当雷达和视觉在持续追踪的动态目标突然消失，瞬间面对一个强回波的静止目

标时，极易因“静止目标滤除机制”导致漏检。在遇到这种情况时，我的记录和排查

逻辑会聚焦在三个维度的客观指标上。

1、感知目标ID切换的延迟（Latency）。我会第一时间通过数据总线抓取前车偏离

本车道中心线（例如跨过车道线30%）的瞬间时间戳，与本车感知融合模块实际上

报“前方静止障碍物ID”的时间戳进行相减。如果这个响应时间超过了300毫秒，说明

感知追踪队列存在严重的更新滞后。2、规控模块的决策介入点（TTC阈值）。记录

系统下发减速扭矩请求时的TTC（TimetoCollision）。在XX这种突发场景下，

系统是否跳过了平缓减速阶段，直接触发了硬制动（AEB级别干预）。3、纵向加

速度控制梯度（Jerk）。记录制动压力建立的曲线，分析减速度是否达到了系统标

定的最大负加速度（如-0.4g左右），以及体感是否突兀。

在复盘阶段，我会把这段Log拖入仿真平台，针对这辆暴漏出来的静止车，进行距

离、光照、自车速度的参数泛化遍历。以此逼研发团队去优化融合算法，确保不再

一刀切地过滤掉所有静止雷达点云，而是与视觉特征做强绑定。

Q12：针对LCC（车道居中控制）功能，遇到曲率极大的弯道或者车道线磨损严

重的场景，测试时如何评估系统的接管请求（ToR）机制？

❌不好的回答示例：

过大弯道或者没线的地方，车肯定会跑偏。测试的时候，我就双手虚握方向盘，看

车跑到什么时候会响报警声音。如果车快撞到马路牙子了才报警，那肯定是不行

的，说明它反应太慢了。我会把报警太晚的情况记录下来提Bug。比较好的表现应

该是提前发出声音，然后方向盘震动提醒我接管，这样我才有足够的时间去转方向

盘。

为什么这么回答不好：

1、评估体系主观且缺乏标准：“快撞到马路牙子才报警”是感性描述，没有引入横向

偏移量和预留接管时间等客观工程参数。

2、忽略了控制上限：大曲率弯道不仅考验视觉感知，更考验底盘EPS（电子转向

助力）的最大扭矩限制，答案未能触及执行器瓶颈。

3、没提到降级策略：未能阐述当驾驶员对ToR无响应时，系统理应采取的后续安全

保底措施。

高分回答示例：

大曲率弯道和斑驳车道线是导致LCC频繁退出的典型边界工况。在这种情况下，系

统不仅要“认怂”，更要“安全地认怂”。我通常的逻辑是建立一套量化的ToR（Take-

overRequest）评估基线。

1、评估ToR触发的时序逻辑与提前量。在XX大曲率测试场，我会抓取摄像头丢失

车道线置信度（降至阈值以下）或规划计算出的方向盘转角需求大于EPS最大扭矩

限值（如大于3N·m）的瞬间。从这个节点到车辆轮胎真正压线，系统必须为驾驶员

预留出符合人机工程学（ISO21448推荐）的接管时间，通常至少是2-4秒。如果

时间不足，定为P0级Bug。2、评估多模态HMI交互的合理性。记录系统是否严格执

行了“视觉预警->听觉高频蜂鸣->触觉（方向盘高频震动或安全带预紧）”的逐级

升级策略，绝不能允许静默退出导致驾驶员猝不及防。3、评估极限情况下的MRM

（最小风险策略）。我会故意对ToR不予理睬，测试车辆是否能在偏离车道前，平

滑地启动减速动作，并在本车道内刹停及打开双闪。

后期我会联合规控团队复盘，分析导致降级的根本原因是感知置信度掉底，还是转

向系统的物理硬件瓶颈，从而制定是从算法侧优化模型，还是在ODD说明书中明确

弯道半径限制的对策。

Q13：什么是OpenSCENARIO和OpenDRIVE标准？在仿真软件中如何利用它

们自动化生成和搭建测试场景？

❌不好的回答示例：

这两个都是自动驾驶仿真里常用的文件格式。OpenDRIVE是用来画地图的，比如

哪有十字路口，哪有红绿灯。OpenSCENARIO是用来写剧本的，比如让NPC车在

什么时间点变道，或者行人什么时候过马路。在仿真软件里，我们要自己写代码去

改这些文件里的参数，然后扔进去跑。这样可以做出很多不一样的场景，比在路上

瞎跑效率高多了。

为什么这么回答不好：

1、描述过于白话：“画地图”、“写剧本”虽然通俗，但在技术面试中显得缺乏专业

度，未能准确说出“静态路网拓扑”和“动态场景行为”等专业词汇。

2、自动化闭环不清晰：只提到“自己写代码改参数”，没有描述清楚具体的参数泛化

原理和自动化流水线（CI）执行流程。

3、缺乏结果校验：仿真不仅要“跑起来”，更要自动化判定“过没过”，答案缺失了评

测指标（KPI）的植入环节。

高分回答示例：

这两者是当前主流的自动驾驶仿真通用标准，共同构成了逻辑场景向具体场景衍生

的基石。OpenDRIVE（xodr文件）定义了高保真的静态路网拓扑结构，包括车道

线方程、道路坡度及交通标志属性；而OpenSCENARIO（xosc文件）则负责描述

动态实体的行为流（Maneuvers），包含触发条件（Triggers）和动作

（Actions）。

我通常的自动化场景生成逻辑分为三环：1、参数空间定义与降维。我会解析基础

的OpenSCENARIO模板文件，提取核心动态参数（如切入NPC的初速度、纵向距

离、横向加速度）。利用Python编写泛化脚本，采用正交试验设计或拉丁超立方抽

样，将这些参数展开生成数千个具体的XML测试实例。2、无头模式并发执行

（HeadlessExecution）。将生成的路网地图与场景实例自动分发至部署在

Docker容器内的仿真引擎（如CARLA或VTD）。抛弃消耗GPU资源的渲染界面，

仅计算感知真值和物理动力学，实现每日上万公里的高并发回归测试。3、注入KPI

裁判器断言。在场景配置中植入碰撞检测、最小安全距离（TTC）和舒适度

（Jerk）等指标探针。

每天早晨，CI流水线会自动把不满足KPI探针的Failed场景拎出来，附带数据Log直

接挂载到开发人员的Jira看板下，坚决堵住人工复现的漏洞。

Q14：描述一次你参与过的最复杂的自动驾驶功能测试项目，你在其中承担了什

么角色，为什么当时的测试策略是这样设计的？

❌不好的回答示例：

我做过最复杂的项目就是高速NOA的量产前测试。我是核心测试人员。因为高速上

车很多，情况很复杂，我们领导让我们主要在上海周围的高速上跑。我就天天跟着

安全员在车上，遇到了被别的车加塞或者高架桥下没信号的时候，我就赶紧记录。

发现了很多问题，整理成表格发给开发。经过大半年的反复跑，最后我们的NOA顺

利上线了，提升了整体价值。

为什么这么回答不好：

1、违背“去AI化”红线：出现了“提升了整体价值”这种假大空的总结语，毫无工程意

义。

2、角色定位极低：“天天跟着安全员记录”，听起来像个数据标注员，没有体现主导

测试策略、用例设计和排查分析的高阶能力。

3、策略毫无章法：纯粹的“堆里程数”人力拉锯战，没有展现出仿真到实车、从模块

到系统的递进式（V模型）科学测试策略。

高分回答示例：

我印象最深的是某车型城区NOA无保护左转功能的SOP攻坚战。在这个项目中，我

担任测试策略主导者。无保护左转是业内公认的鬼门关，路权极其复杂，仅靠堆路

测里程根本抓不到极端的博弈场景。

因此，我当时制定的测试逻辑是坚决推行“虚实结合、双线闭环”。1、在仿真层，我

通过挖掘车队的历史数据，提取了100个极具代表性的“中国式过马路”以及对面来车

抢行的Log包。利用Log2Sim技术，将其转化为强交互的SIL仿真场景矩阵。在这

个环节，我拦截了算法在频繁启停时产生的路线震荡Bug。2、在封闭场地层，我搭

建了软目标假车矩阵，验证在规控规划出左转轨迹后，底盘线控转向系统是否能以

0误差跟踪执行，排除了因方向盘迟滞导致的路线偏离。3、在开放道路层，针对重

度拥堵路口，我重点关注规控的“博弈试探”策略是否拟人化。最核心的风险点是车

辆在马路中央卡死。我在路测中实时抓取规划的Trajectory数据，分析是因为预测

模块（Prediction）将对向慢速车误判为加速车，导致本车过于保守。

最后复盘时，我们将一套包含高频痛点的路口测试集沉淀为自动化基线，彻底摆脱

了以前那种盲目上路撞运气的低效模式。

Q15：在搭建自动化测试流水线（CI/CD）时，你是如何将代码提交、每日构建

（NightlyBuild）与自动化仿真测试结合起来的？

❌不好的回答示例：

我们用的是Jenkins和Git代码库。流程就是开发写完代码后，提交到Git上。然后

Jenkins监听到有新代码了，就会自动开始打包编译。编译成功以后，会自动拉起

仿真软件，跑一些基础的测试用例。如果用例全部通过了，界面上就会显示绿灯，

代码就可以合进去。如果有报错红灯了，开发就自己去看日志修Bug。这样就实现

了自动化。

为什么这么回答不好：

1、深度严重不足：这就是一套最烂大街的软件工程基础流程背诵，完全没有结合

自动驾驶算法编译时间长、算力消耗大、场景数量庞大等行业痛点。

2、缺少测试分级策略：将所有仿真测试混为一谈，没有区分冒烟测试（Smoke

Test）、回归测试和压力测试的不同触发时机。

3、没有闭环机制：“开发自己去看日志”是非常低效的，没有说出测试报告自动化提

取和指标量化的手段。

高分回答示例：

我通常的逻辑是，自动驾驶的CI/CD流水线绝不能做成大锅饭，必须针对高算力消

耗和复杂的软件栈设计分层拦截机制，兼顾开发敏捷度与代码防呆。

1、配置准入级冒烟测试（MRTriggered）。当算法工程师发起MergeRequest

时，我设定只触发耗时低于15分钟的核心场景集（如直道AEB、无车道线LCC维持

等50个用例）。最核心的风险点是如果拉起全量测试会导致流水线严重拥堵。这一

层的目的是快速暴露最低级的代码编译错误和基础逻辑崩溃。2、执行重量级的每

日构建（NightlyBuild）。每天凌晨，Jenkins会自动拉取Master主分支的最新镜

像，向云端仿真集群分发上万个涵盖各类CornerCase的回归场景集

（OpenSCENARIO格式）。这部分利用Kubernetes进行容器化分布式调度，确保

在第二天上班前跑完。3、自动化KPI萃取与断言。由于仿真结果不是简单的

Pass/Fail，我编写了Python脚本，自动解析跑完后的日志，提取出碰撞率、急刹

率、舒适度超标率等量化指标，生成数据图表（Grafana仪表盘）。

如果NightlyBuild中发现某一项指标相较昨天出现了明显衰退（Regression），我

会立刻冻结代码合库，并拿着自动截取的出错场景3D回放录包直接要求对应模块的

负责人复盘，彻底杜绝了带着暗伤发版的情况。

Q16：针对BEV（鸟瞰图）+Transformer架构的感知算法，测试方法与传统的

分块感知（如2D检测+测距）算法测试有何不同？

❌不好的回答示例：

传统的2D算法就是在摄像头画面里画框框，测起来比较简单，看看框画得准不准就

行了。但是现在的BEV+Transformer是把几个摄像头的画面拼接起来，直接在上帝

视角下看车在哪。测试这种新算法，我们就不能只看单个摄像头了，得在车上放个

大屏幕看它拼接出来的俯视图。如果有车在盲区或者画面接缝的地方变了形，那就

是出问题了，要重点测这些地方。

为什么这么回答不好：

1、没有触及模型本质：Transformer不仅有空间融合（BEV），更重要的是时间序

列特征（时序记忆），回答完全没提到时间维度上的测试挑战。

2、缺乏评测体系的变化：从评价2DIoU（交并比）转变为评估3D真值匹配和拓扑

结构，这一点没有说透。

3、测试手段太土：“放个大屏幕看俯视图”显得极不专业，没有涉及自动化真值对比

和时序扰动注入等测试手法。

高分回答示例：

我通常的逻辑是，从2D切换到BEV+Transformer，意味着感知模块从一个“管线分

明的工厂”变成了一个“巨大的黑盒”。测试的重心必须从单帧的目标检测，向时空一

致性与特征级融合的鲁棒性偏移。

1、重点打击时序灾难（TemporalInconsistency）。Transformer极度依赖历史帧

的记忆来推断当前帧（比如对被大货车短暂遮挡的车辆进行脑补）。我会在仿真中

注入“时序扰动”，如故意丢弃连续5帧的侧前摄像头数据，测试模型是否会发生“目

标物突然消失又闪现”的灾难性断崖。2、挖掘重叠FOV的拼接畸变。在多摄画面交

界的区域（比如车前向和侧前向），由于外参标定极易在颠簸路面发生微小形变，

我会通过微调测试车传感器的Pitch/Yaw角度，验证BEV模型空间转换矩阵的容错

率，防止出现“一辆车被切成两半并识别为两个目标”的致命错误。3、评价指标的三

维化革新。抛弃传统的2D框交并比，我会引入NuScenes等数据集常用的NDS

（NuScenesDetectionScore），综合量化目标在三维空间中的平移、尺度、朝

向以及速度预估误差。

针对发现的时序不稳定或脑补错误（幻觉），单纯提Bug没有用。我必须截取这段

带有多视角Video和精准自车位姿（Odometry）的连续序列帧，打回给算法做数据

闭环重新训练。

Q17：请举例说明如何利用真实路测数据（Log）通过数据挖掘技术，批量生成

或提取仿真测试的CornerCase（长尾场景）？

❌不好的回答示例：

我们会让路测车队每天在外面跑，存下很多硬盘的数据。然后测试人员就打开回放

软件，快进看视频。如果看到有人突然冲出来或者有事故，我们就把那一段视频切

下来。然后把里面的车和人的轨迹手动照着画到仿真软件里去，做成一个新的测试

场景。这样慢慢积累，我们的CornerCase库就会越来越大，能测的东西也就越

多。

为什么这么回答不好：

1、严重的人力浪费：“人工看视频切视频”、“手动照着画”，这种石器时代的操作效

率极低，根本称不上“数据挖掘技术”。

2、没有数据驱动意识：未提及如何利用车辆CAN总线报文、触发规则和AI算法进

行自动化筛选。

3、忽略了从Log到仿真的自动化转换链路：现代自动驾驶公司都具备Log2Sim的

能力，手工作坊的做法在面试中会被秒杀。

高分回答示例：

海量路测数据的真正价值在于自动化的清洗和提纯，绝不能靠人工筛选。我通常的

逻辑是建立一条端到端的“数据挖掘与场景泛化流水线”。

1、确立多维度的事件触发探针（TriggerRules）。在云端数据湖中，我会写脚本

遍历所有路测Log的CAN信号与规划数据。比如筛选出“横向加速度变化率（Jerk）

突变”、“AEB制动压力>50Bar”、“人类驾驶员在1秒内急打方向盘接管”等片段。这

些标签背后，往往隐藏着感知漏检或规控死锁的CornerCase。2、实施自动化场

景重建（Log2Sim）。将命中探针的15秒切片数据导入解析工具，自动抽取本车

GPS轨迹、感知模块输出的目标物BoundingBox以及高精地图底座，转换生成

OpenSCENARIO格式的结构化场景，完全省去人工复刻的环节。3、通过泛化放大

价值。真实的事故边缘数据是很匮乏的。针对提取出的“鬼探头”场景，我会编写扰

动脚本，对遮挡物（如大巴车）的体积、行人的出场速度和初始距离进行±20%的

蒙特卡洛矩阵泛化，瞬间将1个真实案例裂变成100个极具压力的衍生场景集。

通过这套机制，我们将原来按“月”更新的仿真测试库缩短到了“天”级别，且每一次回

归测试都能直击算法的真实短板。

Q18：在设计自动泊车（APA/AVP）的测试用例时，如何全面覆盖各种非标车

位、地锁、以及光线突变（如进出地库）的情况？

❌不好的回答示例：

测自动泊车不能只在划线很清楚的停车场测。我们要去找那种没有线的野车位，或

者地上长草的车位去测。对于地锁，看看升起来和降下去的时候车能不能认出来。

至于光线突变，我们就在大晴天把车开进黑黑的地下车库，看看摄像头会不会因为

太暗导致找不到车位。遇到车停不进去的，就把图截下来发给算法团队优化。

为什么这么回答不好：

1、分类不严谨：只罗列了表象，没有从传感器感知特性的角度（如视觉依赖线、

超声波依赖实体）进行系统化的场景拆解。

2、缺少动态博弈测试：泊车不仅是静态的车位识别，更包含了与移动行人、其他

抢位车辆的动态博弈，答案完全缺失这部分。

3、缺少度量闭环：仅说明去测试，但没有给出评估泊车成功与否的具体指标（如

揉库次数、停车姿态误差）。

高分回答示例：

APA/AVP测试的深水区在于传感器局限性带来的物理盲区。我通常的逻辑是构建一

套交叉维度的测试矩阵，穷尽视觉和超声波雷达的边界。

1、构造刁钻的非标物理边界。针对视觉，我会设计车道线单边磨损、地面有强烈

反光水渍、甚至是由减速带伪装的车位线用例；针对超声波，最核心的风险点是探

头存在高度盲区。我会专门摆放斜拉索、悬空消防栓、细铁丝网以及半升起状态的

地锁。验证融合感知是否能有效互补，即视觉能看清细线，超声波能防住死角。

2、设计高动态光影瞬变工况。进出地库瞬间，摄像头的ISP曝光调节存在延迟（白

平衡失调）。我会重点测试在此时段内（通常几百毫秒），系统如果突然面对地库

通道内的静止车辆，能否单纯依靠毫米波或激光雷达兜底完成AEB急刹。3、引入

重度干扰的博弈场景。在AVP漫游寻位时，刻意安排多辆NPC车辆交汇拥堵、行人

穿插，甚至有车辆突然倒车抢位。测试规控算法的死锁判定和脱困规划能力。

每次测试执行后，我不看主观感受，只抓客观数据：记录平均泊车时长、揉库次数

（Gearshifts）、以及最终停入姿态（与边线平行度的偏角和厘米级距离差）。超

出KPI基线的用例强制打回重调。

Q19：针对自动驾驶系统中的“幽灵刹车”（PhantomBraking）问题，如果你

在路测中遇到了，会如何收集数据并协助研发排查深层原因？

❌不好的回答示例：

幽灵刹车就是前面明明什么都没有，车却突然猛踩刹车。遇到这种情况，我会先安

抚一下车里的人，然后马上记下发生的时间和地点，看看当时的天气和路况，是不

是旁边有个大牌子反光。回去以后把数据包导出来，提交一个严重的Bug单给开

发，告诉他们在这个地方发生了误刹车，让他们去查底层的代码，把这个反光过滤

掉。

为什么这么回答不好：

1、排查浮于表面：完全凭借肉眼猜测“牌子反光”，没有通过专业的数据回放工具深

入到算法各模块（感知、融合、规控）内部寻找证据。

2、动作指导性差：“让他们去查底层代码”相当于把皮球踢给开发，没有体现测试工

程师缩小问题范围（IsolateProblem）的核心价值。

3、缺乏系统验证思维：改掉一个幽灵刹车很容易引发漏检的致命问题，没有提到

回归验证的平衡策略。

高分回答示例：

“幽灵刹车”是极其折损用户信任度的顽疾。在路测触发该问题瞬间，我的第一反应

是打点记录（Voicetag），随后进入硬核的数据回剥与链路排查阶段。

1、剥离规控与感知的责任。我会把路测rosbag倒入Foxglove或可视化平台，首先

检查规控下发减速指令瞬间的障碍物列表（ObjectList）。如果列表中并没有高置

信度目标，说明是规控自身的逻辑误判或地图限速突变；如果列表中出现了一个寿

命极短的“幻觉目标”，则锁定为感知模块的锅。2、深挖感知异常源头。如果是感知

问题，我会进一步拆解是哪一路传感器在“捣鬼”。重点核对毫米波雷达的点云，看

是否是将路面的减速带、井盖多径反射成了动态车辆（此时速度向量会剧烈跳

变）；或者检查视觉识别的BoundingBox，看是否把桥梁阴影或前车喷绘的图案

误识别为了障碍物。3、警惕高精地图的高程误差。有时候雷达是正常的，但地图Z

轴数据偏移，导致系统认为高架桥是横在路中间的一堵墙。

拿着精准切中痛点的数据链路图去找开发，定位效率会呈指数级提升。在开发修复

后，最核心的风险点是“为了消灭误检而拉高置信度阈值，导致真的障碍物漏检”。

因此，我会在CI流水线中强制拉起一次包含50个真障碍物测试工况的回归测试，确

保召回率不掉底。

Q20：在路测过程中，安全员突然紧急接管了车辆，作为测试工程师，你需要立

刻记录和排查哪些软硬件维度的关键信息？

❌不好的回答示例：

接管发生后，我得赶紧问安全员为什么要接管，是因为车快撞了，还是他觉得车开

得不舒服。然后我要在本子上记下时间和具体的路口名字。接下来我会把车上的录

像存下来，还有当时系统的各种日志都打包带走。回去之后，再把这些东西发给算

法组，让他们看看是不是什么地方识别错了，或者方向盘没有转过来。

为什么这么回答不好：

1、过于依赖主观回忆：问安全员的主观感受在事后分析时极易产生偏差，忽略了

底层客观数据的不可篡改性。

2、排查颗粒度太大：“各种日志都打包”是毫无专业焦点的做法，没有说出到底要看

哪一层的数据（如Planning轨迹、CAN底盘指令等）。

3、对车辆状态关注不足：未提到分析规控下发指令与底盘实际执行之间是否存在

响应延迟。

高分回答示例：

安全员的紧急接管是最高优的现场异常案卷。我通常的逻辑是抛弃主观叙述，用客

观数据锚定事发瞬间的系统快照。

1、捕捉人机冲突的瞬间状态。我会立即提取底盘CAN网络中的状态报文，对比在

接管发生前2秒内，自动驾驶规控下发的方向盘转角/制动请求，与安全员实际施加

的人工扭矩/刹车踏板深度。这个差值就是人车博弈的证据。2、向上逆推模块链

路。拿着时间戳回溯：如果是规划轨迹本身就指向了隔离带，那就是Planning或

Prediction模块的崩溃；如果规划轨迹非常平滑，但底层执行器的实际轨迹却发生

了偏移，那就是底盘线控响应延迟或者车辆控制（Control）模型中的侧偏刚度参数

失真。3、排查硬件偶发瓶颈。不可忽视的一点是，很多极其诡异的接管是因为底

层算力平台的GPU瞬时满载掉帧，或者摄像头在剧烈颠簸时发生了毫秒级的数据线

接触不良（FPD-Link丢锁）。我会同步检查内核级的dmesg系统日志。

随后，我会将截取出的30秒高价值数据包（包含前置上下文和后置接管轨迹）上传

至数据湖，并标注上确切的失效标签分类。这种精细化的排查能够防止将硬件隐患

误报为算法Bug，大幅削减跨部门的沟通损耗。

Q21：当发现一版新的感知模型在雨天场景下漏检率异常升高，你会如何设计对

照实验来定位是算法Regression（退化）还是数据集分布问题？

❌不好的回答示例：

遇到新模型下雨天漏检变多的情况，这通常是因为训练数据里雨天的图片太少了。

我会让车队多去下雨的地方跑一跑，多录一些雨天的数据。把这些数据重新标好，

丢给算法团队让他们加进去重新训练。训练完我们再上车跑看看，如果不再漏检

了，就说明问题解决了，如果是算法本身写错了，那就让开发查代码。

为什么这么回答不好：

1、归因极其武断：没有做任何变量控制就断定是数据集分布问题，掩盖了可能是

算子优化或特征提取网络修改导致的性能倒退。

2、操作成本极高：直接呼叫路测采数据周期长且不可控，完全背离了测试工程师

利用现有数据进行剥离排查的职责。

3、缺乏量化对比：毫无基线（Baseline）概念，没有提及使用黄金测试集

（GoldenDataset）进行背靠背（Back-to-Back）的离线跑包比对。

高分回答示例：

我通常的逻辑是“绝不能靠猜”，必须通过控制变量的A/B测试来锁定是“模型结构变

异”还是“数据营养不良”。在这个场景下，最核心的风险点是算法团队以“长尾场景数

据不足”为由掩盖了底层代码合库引入的破坏性修改。

我的实操步骤如下：1、提取基线回归测试集。我会从CI仓库中拉取一个固定的“雨

天专属黄金测试集（GoldenDataset）”，这个数据集必须是上一版（基准版）模

型能跑到90%以上召回率的已知样本。2、进行背靠背离线推演（Back-to-Back

Testing）。将新老两版模型模型分别在同一个推理计算卡上，对该黄金数据集重新

跑一遍离线评测。3、分析对比差异。如果新模型在这个固定数据集上的mAP（平

均精度均值）大幅掉点，直接实锤是算法Regression（比如前向网络砍了某层卷积

参数导致感受野变小）；如果新老模型在黄金集上表现都很好，但在新增的路测雨

天数据上新模型表现极差，则说明是新数据触发了当前模型架构的特征泛化瓶颈

（即数据集分布漂移）。

拿着这份控制变量的数据对比看板去和感知团队对线，他们将无法推诿。复盘时，

我会强制要求将这类引发过大面积漏检的雨天长尾数据永久固化到发版前的必须回

归链路中，不达标直接阻断发版。

Q22：HIL台架测试中发现CAN报文丢失或延迟，导致控制器进入降级模式，你

通常的排查思路和验证方法是什么？

❌不好的回答示例：

如果在台架上发现CAN报文丢了，导致系统降级，我会先看看是不是线缆没接好，

重新插拔一下HIL机柜到控制器的线束。如果线没问题，我就重启一下仿真软件。要

是还有延迟，可能是电脑卡了或者仿真软件跑慢了。我会把抓下来的报文发给开

发，说这一秒钟丢了几个包，让他们去排查是不是底层的代码卡死或者发包频率不

对。

为什么这么回答不好：

1、排查动作毫无技术含量：“重新插拔”、“重启软件”是典型的网管思维，没有任何

针对总线时序分析的专业动作。

2、缺失关键度量指标：完全没有提及CAN总线负载率（BusLoad）、错误帧

（ErrorFrame）和CPU中断等深层诊断指标。

3、没有形成逻辑闭环：直接把现象扔给开发，没有通过注入手段去隔离是HIL台架

自身的注入瓶颈还是