候选人面试分析：蔚来底盘 hil

来源

• 转写文件：蔚来底盘 hil.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：转写文本存在较多语音识别错误、口语重复和断句问题，部分技术术语识别不准确（如“工艺红星”应为“CANoe”，“接管”应为“诊断”），但不影响对候选人核心能力的整体判断。

岗位方向

• 主要匹配：底盘域 HIL 台架测试执行。
• 次要匹配：车身域台架测试。
• 岗位适配判断：候选人更适合按既定用例和脚本执行的台架测试岗位，不适合需要独立设计测试用例、开发自动化脚本或深入分析控制逻辑的岗位。

整体结论

候选人拥有约两年底盘 HIL 台架测试经验，参与过包含 EPS、ESC、EPB 等控制器的大台架集成测试项目，对台架测试的基本流程、工具（CANoe、诊断软件）和自动化执行（VT System）有一定了解。然而，面试中暴露出候选人的工作模式高度依赖甲方提供的现成用例库和自动化脚本，自身缺乏测试用例设计、脚本开发和问题深度分析的实战经验。在回答 EPS 主动回正等具体功能测试时，候选人无法清晰阐述台架测试的完整操作逻辑（如机器人控制、信号设置与读取），对测试原理和评判标准理解模糊，且以“记不清”回避多个技术追问。整体判断为一名执行型测试人员，技术深度和独立工作能力存在明显短板，不建议作为核心测试岗位的优先人选。

答得好的点

• 项目经历真实：能清晰说出底盘 HIL 台架集成了 EPS、ESC、EPB 等控制器，并提及使用 VT System 进行自动化测试，与主流 HIL 方案吻合。
• 工具链认知基本正确：提到使用 CANoe、诊断软件、VT System 和自动化脚本执行，工具栈符合行业实际。
• 对台架测试基本流程有概念：能描述出“上电、设置档位/驾驶模式、设置车速、控制机器人、读取信号”的测试步骤框架。
• 了解部分 EPS 功能：能列举出助力特性曲线、主动回正、随速助力、阻力补偿等测试项，表明接触过相关测试内容。
• 沟通态度良好：面试全程配合回答问题，对到岗时间和地点持开放态度。

薄弱风险

• 高度依赖甲方，缺乏独立设计能力：明确表示自动化脚本由主机厂开发，自己仅做简单修改；测试用例主要沿用用例库，自己只写少量变更部分。这反映出候选人缺乏从零设计测试用例和开发脚本的能力。
• 对台架测试操作逻辑理解模糊：在解释 EPS 主动回正测试时，最初用实车逻辑（“松开方向盘”）描述，经面试官纠正后才意识到台架是通过控制机器人电机卸力来实现。这表明其对 HIL 测试的物理仿真层理解不深。
• 技术深度不足，无法解释测试原理：当被问及如何判断不同车速下的回正速率差异时，候选人无法清晰说明是通过读取转角变化率还是分析 CAN 信号曲线，仅模糊回答“有对应的那个值”。对“重力补偿”的测试方法和评判标准也以“记不太清”回避。
• 问题闭环能力存疑：虽然提到“提 bug 单，等开发修复后回归验证”，但在具体功能测试的追问中，未能展现出对测试失败场景、根因分析或问题定位的深入思考。
• 工具链掌握停留在执行层面：未接触过 CANoe 的替代工具 CANalyzer，对 CANoe 的使用也仅限于诊断模块和基本信号读取，未体现出 CAPL 编程或复杂仿真建模能力。
• 记忆模糊，项目细节掌握不牢：多次以“时间有些长了”、“记不太清了”回应技术细节追问，这降低了对项目参与深度和真实技术掌握程度的可信度。

面试官考察点

• 项目真实性验证：通过追问台架构成（几个台架、包含哪些控制器）、测试对象（总成还是控制器）来确认候选人是否真实参与过该项目。
• 工具链熟练度：询问 CANoe 使用细节（如加载 DBC/CDD 文件）、自动化工具（VT System）和脚本编写能力，以区分工具使用者与工具执行者。
• 测试设计能力：通过 EPS 主动回正测试的详细追问，考察候选人是否理解测试步骤、信号设置、机器人控制逻辑和评判标准，而非仅会执行脚本。
• 技术深度与原理理解：追问回正速率在不同车速下的差异判断、重力补偿的测试方法，旨在探测候选人对控制逻辑和测试原理的理解深度。
• 独立工作与问题解决能力：通过询问用例和脚本的来源，判断候选人是独立开发还是依赖甲方交付，从而评估其独立承担任务的能力。
• 岗位意愿与稳定性：确认驾照情况、到岗时间和工作地点，评估其与岗位实际需求的匹配度。

证据摘录

• “自动化脚本的话是这边是直接有开发给到我们，然后我们的话就是可能会进行一些修改，简单的修改。”
• “用力我们也是，主要是沿用我们用力库。然后就是有需要变更的话，然后自己会写一点。”
• “我们主要是通过呃we呃we test still这个进行自动化的那个操作，修改它那个呃设定吧算什么？设定上面是有个机器人吗？还是什么？嗯，不是，是那个。额外的一个电梯。”
• “那你说的松开这个词它是十分的用法，而不是对台架的用法。抬架的一定是让这个机器人。去把这个自己的这个力卸掉。嗯，明白，我们就是透露信号嘛，然后修改一些变量，包括车速，然后转向角度，助力电流就行了。”
• “你你如果只看电流的话，你肯定是看不出来它回升速率的。你只能说啊他有这个回正的动作。嗯，然后看他的那个残余的那个转角，它一般是呃有那个记录嘛，就是小于等于呃正负三度这样子。”
• “那个补偿的话，我们做的时候是。嗯，叠加补偿那个电影吧。……这个有点记不太清了这个。”

评级建议

• 建议评级：C+
• 推荐方向：可考虑作为供应商驻场测试执行岗位的备选，负责按既定用例和脚本执行台架测试、记录结果和提交 Bug。
• 谨慎方向：不建议直接承担需要独立设计测试用例、开发自动化脚本、深入分析控制策略或主导问题排查的岗位。
• 面试推进建议：不建议作为优先复试人选。如岗位紧急且仅需执行型人员，可安排二面由技术专家进一步复核其学习能力和基础知识的扎实程度；否则建议淘汰，寻找更具独立工作能力的候选人。

可补问问题

1. 请详细描述一个你独立编写（非修改）的自动化测试用例或脚本，包括测试目的、实现逻辑和最终效果。
2. 在底盘 HIL 台架上，如果 EPS 助力特性曲线测试结果与预期不符，你的排查思路和步骤是什么？请举例说明。
3. 请解释一下你在台架上测试“随速助力”功能时，如何模拟不同车速信号，以及如何验证助力大小随车速变化的逻辑是否正确。
4. 你提到使用 CANoe 进行诊断，请具体说明你使用过哪些诊断服务（如 10, 22, 2E, 19 服务），以及你在测试中是如何应用它们的。
5. 如果让你从零开始为一个新的底盘控制器搭建 HIL 测试环境，你会考虑哪些关键步骤和组件？