候选人面试分析：岚图～动力底盘

来源

• 转写文件：岚图～动力底盘.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：转写存在少量语音识别错误和口语重复，但不影响整体理解。候选人自述为郑州人，2021年毕业，曾就职于重庆长安汽车股份有限公司，2025年2月离职。

岗位方向

• 主要匹配：动力底盘域实车功能测试。
• 次要匹配：充电功能测试、诊断测试（基础）。
• 岗位适配判断：更适合按测试用例执行的实车功能测试岗位，不适合需要独立设计测试方案、搭建台架或深度使用CAPL/Python脚本的HIL测试或自动化测试岗位。

整体结论

候选人具备约3-4年整车厂（长安）实车功能测试经验，主要集中在动力底盘域，对自动驻车（AVH）、能量回收等功能逻辑有一定理解，能够描述功能触发条件、交互逻辑和基本的问题排查思路。在故障注入和问题分析环节，候选人表现出对CAN工具（如CANoe/CANalyzer）和诊断服务（2F、31）的基础操作能力，但回答较为模糊，尤其在故障注入的具体实现方式上，经过面试官多次追问才勉强给出“屏蔽正常信号再仿真”的思路，且明确表示CAPL脚本由他人编写、自己仅使用，暴露出工具链深度不足和独立设计能力欠缺的短板。

整体来看，候选人属于“执行型”测试人员，能够按照既定用例完成实车测试、记录Bug并提交日志，但在测试设计、复杂问题定位、自动化脚本开发等方面能力有限。优势在于对动力底盘功能逻辑有实际项目积累，沟通表达基本清晰；主要风险是技术深度不足、工具链依赖他人、缺乏台架测试经验。如果岗位需求是实车功能测试执行，可考虑作为初级或中级人选推进；若岗位要求独立设计测试方案或HIL台架测试，则匹配度较低。

答得好的点

• 对自动驻车（AVH）的功能逻辑描述较完整，能清晰说明触发条件（车速为零、D/R档、主驾门关闭）、激活方式（深踩刹车/按键）、退出方式（踩油门/再踩刹车）以及与EPB的交互（超时或开门自动转交EPB），体现了实际测试经验。
• 在充电预约失败的问题排查中，能按信号链路顺序梳理出T-Box、TSP平台、网关、VCU、OBC、BMS等关键控制器，思路基本正确。
• 能量回收失效的Bug案例描述具体，包含现象（SOC<90%、车速60km/h、无回收感、仪表功率显示0）、原因（齿圈导致轮速传感器短时无效脉冲）、VCU策略（禁用回收以避免顿挫）和解决方案（优化车速有效性判断逻辑），展示了问题闭环能力。
• 对Bug提交流程和所需数据（标题、前置条件、复现步骤、严重程度、版本时间、日志/截图/视频附件）的回答符合行业规范，说明有实际提票经验。
• 能说出诊断服务2F和31用于屏蔽控制器，表明对UDS诊断有基础了解。

薄弱风险

• 故障注入操作描述模糊，面试官多次追问“如何屏蔽正常信号”后，候选人才勉强给出“设置CAN过滤器禁用控制器发送权限”的思路，且最初误以为直接发送故障信号即可，暴露了对CAN总线仲裁机制和仿真原理理解不深。
• 明确表示“CAPL脚本都是他们写的，我直接用就行”，说明不具备自动化测试脚本开发能力，工具链使用停留在手动操作层面。
• 台架测试经验薄弱，自述“HIL上寥寥草草的知道”、“没设计过台架”，仅接触过VT台架，无法独立承担台架测试任务。
• 在充电预约问题排查中，回答偏理论化，未提及具体使用的工具（如CANoe trace、log分析）或实际排查步骤，缺乏实操细节支撑。
• 能量回收案例中，候选人声称“我发的”Bug，但后续描述偏重现象和原因，未清晰说明个人在定位分析中的具体贡献（如是否独立抓取数据、分析信号、定位到齿圈问题），存在“团队成果个人化”的风险。
• 对轮速传感器信号走CAN总线的理解可能存在偏差（部分车型轮速传感器信号通过私有协议或硬线传输），但面试中未深入验证，存在知识盲区。

面试官考察点

• 验证候选人实车测试经验的真实性，通过AVH功能逻辑细节判断是否真正参与测试。
• 考察功能逻辑理解深度，要求说明AVH的前置条件、触发条件、极端表现和配置条件。
• 考察问题排查思路和系统链路理解，通过充电预约失败场景验证信号流和控制器交互掌握程度。
• 验证故障注入测试的实际操作能力，追问实车模拟轮速传感器故障的具体方法和工具使用。
• 深挖工具链熟练度，通过追问“如何屏蔽正常信号”、“用诊断哪个服务”判断候选人对CAN工具和UDS的掌握程度。
• 考察问题闭环和Bug提交规范，要求描述经典Bug案例的发现、分析、定位和提交数据。
• 评估候选人独立分析和定位问题的能力，通过能量回收案例追问个人贡献和数据抓取细节。
• 了解候选人岗位意愿和加班接受度，询问项目周期紧张时的排班安排。

证据摘录

• “首先它那个触发的前提条件，你车速必须要呃当车辆必须要静止嘛，然后车速必须必须呃为零嘛，然后呃它的前提条件就是然后整车供电一个正常，然后无电源故障。呃，当然他那个驾驶员侧门是必须要关闭的，然后档位处于一个d档或者r r档。”
• “呃，首先它会涉及到一个嗯t box吧，呃然后t s t远控平台，然后网关呃呃v c o啊o b c d c d c，然后b m s这些都会涉及到。”
• “呃，屏蔽的话就是那个呃是可以设置那个看总线的一个过滤器，然后对相应的呃禁用它那个控制器，然后发送权限就这样。”
• “屏蔽的话用呃，二那个二f和三幺。”
• “我当然你说的这个开头也可以的，但是我开头当然之前呃涉及的比较少，然后开头都是他们写写的，然后我那个用我直接用就行。”
• “当时那个能量回收它失效，然后特定工况然后特定工况下它是没有回收。呃，当然它这个现象就是电池的s o c然后低于百分之九十，然后车速呃车速呃车速六十千米每小时，然后松开这个加速踏板的时候，它是没有一个呃没有一个回收感。然后当然它这个仪表呃回收功率显示为零。”
• “当时通过那个。分析分析数据嘛，然后抓取数据发现呃他那个车速上的一个传感器。然后因为它那个齿圈呃齿圈的问题嘛，然后呃产生了一个短短时的无线脉冲。然后呃当时那个v c o判定他那个车速的车速不稳定，呃，呃为了避免他那个回为了避免回收，然后导致车辆一个顿挫。然后他他当时就是禁用了嗯回收的回收的一个时间。”

评级建议

• 建议评级：C+
• 推荐方向：动力底盘域实车功能测试执行、供应商驻场测试（按用例执行）、OTA升级后的实车验证测试。
• 谨慎方向：HIL台架测试、测试方案设计、自动化脚本开发（CAPL/Python）、需要独立定位复杂系统问题的岗位。
• 面试推进建议：可作为初级或中级实车测试执行岗位的备选，不建议直接淘汰。若推进复试，需重点补问其独立分析定位问题的能力、CANoe/CANalyzer的实际操作熟练度（如trace分析、信号过滤、Graphic窗口使用），以及是否具备基本的CAPL脚本阅读或修改能力。

可补问问题

• 在能量回收失效的案例中，你具体是如何抓取数据的？使用了CANoe的哪个功能？你个人独立分析了哪些信号才定位到齿圈和轮速传感器的问题？
• 如果让你独立设计一个AVH功能的实车测试用例，你会考虑哪些正常场景和异常场景？请列举至少5个测试用例。
• 你提到用诊断服务2F和31屏蔽控制器，请具体说明操作步骤：在CANoe的诊断控制台中，你如何输入请求、如何确认控制器已成功静默？
• 如果给你一个DBC文件和一个CAPL脚本模板，你能独立修改脚本实现一个简单的故障注入（如周期性修改一个信号值）吗？你目前能读懂CAPL脚本的基本结构吗？
• 在充电预约失败的排查中，你提到要“看远程有没有接收”，具体在CANoe上你会看哪条报文的哪个信号？如何判断是T-Box没收到指令还是VCU没执行？
• 你简历中提到“模拟轮速传感器故障”，除了通过CAN总线修改信号外，你知道还有哪些硬件注入故障的方式吗？