候选人面试分析:车身 hil-北汽
来源
- 转写文件:
车身 hil-北汽.txt - 候选人姓名:转写中无法确认真实姓名;不编造姓名。
- 备注:转写文本存在较多口语化、重复和语音识别错误(如“剥脱率”应为“波特率”,“充矿店”应为“充放电”,“三年的话,四年”应为“三年还是四年”),但不影响对候选人核心能力的整体判断。对话为单人与面试官交流,无多人对话不清晰问题。
岗位方向
- 主要匹配:BMS HIL 测试、新能源汽车三电系统测试。
- 次要匹配:整车集成测试、车身域测试。
- 岗位适配判断:候选人更适合 BMS/三电 HIL 测试执行与台架维护岗位,不适合需要独立设计复杂测试用例、从零搭建自动化框架或深度模型开发的岗位。
整体结论
候选人具备约 3-4 年新能源汽车电子测试经验,主要集中在 BMS HIL 台架测试、诊断刷写流程执行以及充放电相关测试。其回答展现出对 UDS 诊断服务、CC/CP 信号逻辑、HIL 台架硬件接线和测试执行流程的熟悉,属于典型的“执行层”测试工程师。优势在于动手能力强,对台架搭建的物理连接、板卡选型、故障注入等有实操经验,且对 BMS 和整车集成方向有明确意愿。主要风险在于技术深度不足:测试用例多为更新而非从零设计,自动化脚本(Python/CAPL)仅停留在使用和自学阶段,无法独立编写,模型工作也仅限于使用甲方提供的模型进行观测,缺乏开发能力。整体来看,候选人是一个合格的 HIL 测试执行者,但尚未达到能独立主导测试设计或自动化开发的高级工程师水平。
答得好的点
- 对 UDS 诊断刷写流程描述清晰,能准确说出服务 ID(如 10, 27, 31, 34, 36, 37, 22, 14)及其作用,体现了扎实的诊断测试执行经验。
- 对交流充电 CC/CP 信号原理和测试方法理解正确,能描述电阻值、电压变化和 PWM 波输出的逻辑,并给出了从插枪到充电的测试步骤。
- 对 BMS HIL 台架搭建有实操经验,能详细说明从电芯串数确定、CMC 板卡选型、菊花链连接到高压电源模拟的完整物理搭建过程。
- 了解故障注入的基本方法,明确提到使用 BOB 进行开路/短路测试,并能结合线束定义图来定位故障。
- 对自身能力边界有清晰认知,坦诚说明模型只能使用不能编写,Python 脚本独立编写有困难,态度务实。
- 岗位意愿灵活且务实,对 BMS 和整车集成测试均表示接受,并表达了在相关领域深入发展的意愿。
薄弱风险
- 测试用例设计能力偏弱,自述“从零到一的编写要少一点,更多是……根据项目需求去制定自己动能模块的一个测试用例更新”,表明其工作多为修改和执行,而非独立设计。
- 自动化开发能力不足,Python 仅能使用现成脚本,CAPL 脚本编写处于自学阶段,无法独立承担自动化测试开发任务。
- 模型开发能力缺失,明确表示“模型是真写不了,因为那边都是由甲方提供的”,仅能看懂和使用模型进行观测,缺乏基于模型的测试设计能力。
- 回答中缺少问题闭环和数据分析的细节,例如在描述刷写或充电测试时,未提及遇到过的具体问题、如何定位根因及最终解决方案。
- 对车身域测试的熟悉度有限,承认“没有这个 BMS VCU 这个交互逻辑那么熟悉”,需要时间熟悉传感器交互逻辑和信号时序,表明其跨域能力尚浅。
- 项目经验描述偏重执行和硬件连接,较少涉及测试策略制定、需求分析或与开发团队的深度交互。
面试官考察点
- 验证诊断刷写流程的真实执行经验,考察对 UDS 服务的熟悉程度。
- 考察对交流充电控制逻辑(CC/CP)的理解深度,以及是否能将其转化为测试用例。
- 评估测试用例设计能力,通过要求候选人现场设计一个采集或唤醒用例,判断其测试思维。
- 确认 HIL 台架搭建的实操能力,从零到一的参与程度,以及是否理解各硬件模块的作用。
- 考察对仿真模型的使用和理解程度,判断其是否具备模型开发或深度调试能力。
- 摸底自动化测试能力,直接询问 Python 和 CAPL 的掌握水平。
- 了解候选人的职业规划与岗位意愿,判断其稳定性和与现有岗位的匹配度。
证据摘录
- “用这个 o b d 的一个连接这个 o b d 的接口与电脑,然后打开这个 t s 八,选择这个相应的通道啊,然后去给它设置它的一个剥脱率。然后二 f 一 a e 去读它的一个软件版本,然后在幺四六个 f 清除故障码,然后就呃进入安全访问,然后幺零零幺幺零零三幺零零二进入编程规划,然后在二七零幺的一个请求一个总值值。”
- “c c 的话,它就是插枪状态的一个连接嘛,根据它的一个组织嘛。一点五千欧、六百八十欧、二百二十欧、一百欧去判断它这个电电缆的一个容量嘛,然后它这个电压也会有相应的一个一个变化。”
- “测试用例写过写过,就是说基本上从零到一的编写要少一点,可能更多于就是说嗯根据项目需求去制定自己动能模块的一个测试用例更新,然后再评审。”
- “我们之前用是 link 然后去有模型,我们主要的被测件就是就是这个 b m m s,或者是它会连接其他的一些,比如说嗯像 v c u 啊、d c d c o b c 啊这些模型去进行测试。”
- “模型这一块……模型是真写不了,因为那边都是由甲方提供的那个。”
- “python. 能能用。就是如果基于这个基于这个 python 这个呃做的这个自动化,我使用是没问题的。使用,然后就没写的话,应该写不了是吧?嗯,独立写的话,目前我很很努力的在往这方面靠。”
- “b o b 肯定要用啊。b o b 它这个也是算比如说故障注入硬件的一个就最简单粗暴的方法就是通过这个呃这个定义图去找到它这个每根每根线的一个定义,就可以直接知道开路短路的一些故障。”
评级建议
- 建议评级:C+
- 推荐方向:BMS HIL 测试执行、台架搭建与维护、整车集成测试执行、供应商驻场测试。
- 谨慎方向:测试用例架构设计、自动化测试框架开发、仿真模型开发、需要独立主导复杂测试策略的岗位。
- 面试推进建议:可作为 BMS 或整车集成测试执行岗位的备选候选人。不建议直接淘汰,但需在复试或试用期重点考察其测试用例设计能力和自动化脚本学习的实际进展。若团队急需能立即上手执行测试的人员,该候选人可考虑;若需要能独立设计测试方案的高级工程师,则不匹配。
可补问问题
- 请举一个你印象最深的测试中发现的 Bug,详细说明你是如何从现象定位到根因的,以及最终是如何推动解决的?
- 在 BMS HIL 测试中,你提到使用 Link 模型,如果模型输出的某个信号与预期不符,你会如何排查是模型问题、硬件问题还是被测件问题?
- 你提到在自学 Python/CAPL 脚本,能否展示一个你最近编写或修改过的最复杂的脚本,并解释其逻辑?
- 如果让你从零为一款新的 BMS 设计 HIL 测试用例,你会如何分析需求并规划你的用例结构?请以绝缘电阻检测功能为例说明。
- 在整车集成测试中,当动力域、车身域和底盘域的交互出现偶发性故障时,你通常采用什么策略来复现和定位问题?