候选人面试分析：智驾-轻舟

来源

• 转写文件：智驾-轻舟.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：无特别备注。

岗位方向

• 主要匹配：ADAS/智驾整车功能测试（实车路测为主）。
• 次要匹配：动力底盘测试（候选人自述后期经历）。
• 岗位适配判断：更适合按测试用例执行的智驾实车路测岗位，不适合需要独立设计测试方案、搭建仿真环境或进行复杂诊断/刷写的岗位。

整体结论

候选人具备约一年多的智驾实车道路测试经验（2022.04-2023.06），主要接触过ACC、LCC、NOA、AEB等主流L2/L2+功能的测试执行与问题提交。回答以功能逻辑描述和常规测试场景列举为主，能讲清ACC的纵向控制链路和基本退出条件，也展示了使用CANoe抓取报文、通过Jira提交Bug的常规工作流。但整体表现偏向“测试执行者”角色，缺乏测试策略设计、场景库构建、性能指标量化、问题深度闭环等体现技术深度的内容。对边界场景、仿真测试、工具链的理解停留在表层，Linux能力薄弱。主要优势在于有真实路测经验和安全意识；主要风险是技术深度不足、独立设计能力存疑、工具链单一且不深入。建议作为智驾初级路测岗位的备选，需补问测试设计能力和工具实操细节。

答得好的点

• 能清晰描述ACC功能的基本控制逻辑，包括ADCC、VCU仲裁、驾驶员优先级等，说明对功能链路有基本认知。
• 能列举ACC的常规测试场景，如跟车启停、目标类型（移动/静止）、退出条件（制动、车门、安全带）、速度调节步长等，体现了一定的测试执行经验。
• 在描述一次ACC未减速的严重Bug时，展示了从自检、抓取报文、小组讨论、Jira提Bug到附日志/视频的完整问题处理流程，具备基本的问题闭环意识。
• 对仿真测试的理解有一定合理性，提到可规避实车风险、硬件未齐时可先行验证、能覆盖极限场景，说明对仿真价值有概念。
• 对CANoe的使用描述涉及Trace面板、Graphics面板、CANdb++ Editor修改信号定义表进行故障注入，说明具备基本的工具操作经验。
• 对偶发Bug的复现策略提到压力测试（复测30次左右）和跨版本跟踪（2-3个版本），体现了基本的测试耐心和流程意识。

薄弱风险

• 技术深度不足：对ACC性能测试的回答停留在“符合需求就是好，有Bug就是差”的层面，未提及任何量化性能指标（如跟车时距、减速度、稳态误差、切入响应时间等），缺乏性能评价能力。
• 测试设计能力存疑：当被问及“如何测性能”和“边界场景”时，回答以功能逻辑和常规场景罗列为主，未能展现出独立设计测试用例、构建场景矩阵或定义通过标准的能力。
• 工具链单一且不深入：主要工具仅为CANoe，且对Linux仅“知道一些简单的”“用的不多”，缺乏自动化测试、数据回灌、仿真软件（如VTD/CarMaker）等工具经验，工具栈较窄。
• 对复杂场景的分析能力弱：在回答“压线车辆识别的负面影响”时，经面试官多次追问才勉强给出“可能把邻车道当本车道导致突然减速”的答案，且对“转向延迟”“转向力不足”等表述不准确，分析逻辑不够清晰。
• 回答模式偏“背诵式”：多处回答如“根据车企定义”“需求定义”等，缺乏结合自身项目实例的深入展开，容易让人质疑其经验是否主要来自用例执行而非深度参与。
• 冒烟测试回答空洞：当被问及拿到新版本如何开展冒烟测试时，回答仅停留在“保证ACC/LCC能正常开启”等泛泛之谈，未体现版本验证策略、关键KPI检查、快速问题定位等思路。
• 项目经验连贯性风险：智驾测试经验仅一年且距今已有一段时间，后期转向动力底盘，智驾技能的持续性和深度可能不足。

面试官考察点

• 验证智驾项目经验的真实性和时长，确认候选人是否具备实际路测经历。
• 考察对ACC等核心智驾功能逻辑的理解深度，判断是仅会执行用例还是理解系统原理。
• 考察性能测试思维，验证候选人是否能从“测功能”上升到“评性能”，是否具备量化测试能力。
• 考察边界场景和异常场景的分析能力，验证候选人是否具备测试设计思维和风险预判能力。
• 验证工具链的真实使用深度，特别是CANoe的实际操作模块和脚本/仿真能力。
• 考察问题发现与闭环能力，验证候选人是否能独立定位问题、推动解决并跟踪闭环。
• 考察对新项目、新版本的快速上手能力和测试策略制定能力。
• 了解候选人对仿真测试的理解，判断其是否具备台架/仿真测试的潜力。

证据摘录

• “a c c的话它主要就是一个呃纵向逻辑嘛。然后a c c模块a d c c采集到相关的信号之后，会向这个车辆v c u发送呃加速或者减速的信号，让v c u去仲裁。”
• “像比较好的话，就比如你呃前车匀速行驶的话，然后你就测他那个能不能正常行驶，包括前车加塞，呃，像这种他那个a a c c它会呃自己进行减速。”
• “有一次我测了a c c的时候那个。呃，前车前车突然变道加塞，加塞之后我这个车辆没有进行这个减速，没有进行减速，差点呃造成这个追尾。……后来发现他确实是一个那个呃软件问呃呃阮他这个功能逻辑的问题。”
• “像工具化软件的话，就是运动运用到那个看后羿。呃，像提bug的话，那个就是运用的就是结尾。”
• “像看i g的话，它会进行测一个仿真。然后垂直面板的话，对于这一个发现bug的时候，它那个呃报文的跟踪，包括图形面板……像呃看d b加加呃看。也会那一个进行一些信号定义表的修改啊啊改写，这样应用的话，这还是比较多的。”
• “像偶像的bug的话，我们一般会进行这个压力测试，呃，复现多次。像基本上的话偶像的话就是复测个三十次左右。……跟踪多个版本，大概的话就是两到三个版本。”

评级建议

• 建议评级：C+
• 推荐方向：ADAS实车路测执行岗位（按用例执行、问题复现与提交），或动力底盘测试岗位。
• 谨慎方向：需要独立设计测试方案、性能评价、仿真建模、自动化测试开发、诊断/刷写等岗位。
• 面试推进建议：不建议作为优先推进人选。若岗位急招初级路测执行人员，可作为备选，但需在复试中重点补问测试设计能力、CANoe实操深度及性能测试理解。若岗位要求较高独立性或工具链广度，建议淘汰。

可补问问题

• 请结合你测过的ACC项目，具体说明你是如何设计一个“前车切入”场景的测试用例的？包括初始条件、车速、距离、通过标准等。
• 在CANoe中，你是否有写过CAPL脚本用于自动化测试或仿真？如果没有，请描述你通过CANoe做故障注入的具体操作步骤。
• 你提到ACC性能“符合需求就是好”，那在你测过的项目中，ACC跟车时距的规格是多少？你如何验证实车表现是否达标？
• 请举一个你独立发现并推动解决的、非安全类的偶发Bug案例，说明你是如何设计复现方案并最终定位根因的。
• 如果让你从零开始负责一个新车型的ACC功能测试，你会如何规划测试阶段、场景优先级和资源需求？