候选人面试分析：bms- 国轩高科

来源

• 转写文件：bms- 国轩高科.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：转写文本存在较多语音识别错误、口语重复、语句断裂及信号中断导致的对话不连贯，部分技术细节可能因此缺失或失真。

岗位方向

• 主要匹配：BMS 台架测试（HIL 测试执行方向）。
• 次要匹配：供应商驻场测试、基础的动力底盘测试执行。
• 岗位适配判断：更适合按既定用例执行的测试岗位，不适合需要独立设计测试方案、搭建复杂台架或主导问题深入分析的岗位。

整体结论

候选人具备 BMS 台架测试的执行经验，熟悉基本的测试流程，如用例执行、Bug 记录与提报、使用 CANoe 查看报文等。对 BMS 的基础功能（如热管理、唤醒、故障诊断）有概念性了解，能描述大致的工作流程。回答风格偏向于“知道是什么”和“按流程怎么做”，但在“为什么这么测”和“遇到复杂问题如何独立分析”上表现薄弱。

主要优势在于有真实的台架测试执行经历，熟悉测试执行环节。主要风险在于技术深度不足，对工具链（如 CANoe 面板、CAPL 脚本）的掌握停留在查看和简单修改层面，缺乏独立设计用例、搭建台架和深入排查复杂问题的能力。整体上，候选人是一名合格的初级测试执行人员，但距离能独立承担项目的中高级工程师尚有差距。是否继续推进取决于岗位对独立性和技术深度的要求。

答得好的点

• 对 BMS 热管理功能有基本理解，能描述出温度传感器检测、冷却/加热处理、档位切换（如一档、二档、三档）及对应温度阈值（如 40-43 度）的工作流程。
• 了解测试用例的基本要素，能列举出测试 ID、测试内容、前提条件、测试步骤、预期结果、实际结果等。
• 清楚台架测试中硬件接口信息的获取方式，提到通过“营销分配图”和“拓扑图”来了解接口与信号对应关系。
• 对 UDS 诊断的否定响应码（NRC）有基础认知，能说出 0x11（服务不支持）、0x13（长度不正确）、0x33（安全访问拒绝）等常见 NRC 的含义。
• 了解 Bug 管理的基本流程，能说明发现问题后通过 Jira 等系统记录并传递给开发人员。

薄弱风险

• 技术深度与问题排查能力不足：当被要求举例说明“不好排查的问题”时，仅描述了单体电压阈值与预期值比较的常规过程，未能体现复杂问题（如偶发故障、时序问题、系统级交互异常）的分析思路和闭环过程，回答较为浅显。
• 工具链掌握程度有限：承认 CAPL 脚本能力仅限于“简单的修改”，无法独立编写。对 CANoe 的 Trace 面板和 Graphics 面板理解停留在“看报文”和“看信息”的层面，缺乏深入应用。
• 缺乏独立设计能力：明确表示用例主要来自甲方提供的用例库，新项目自己写用例的情况“特别特别的少”，表明其工作模式高度依赖现有资源，缺乏独立设计测试用例的经验。
• 台架搭建经验缺失：承认台架搭建主要由“电器工程师”完成，自己仅负责“线束连接”，未独立主导或深度参与过台架集成与调试工作。
• 知识体系存在盲区：对网络管理（如 OSEK/AUTOSAR NM）的唤醒方式（如网络管理唤醒）表示“没有负责这一块”、“不大清楚”，知识面存在明显缺口。
• 回答被动且缺乏细节：多数回答是面试官问一点答一点，缺乏主动展开和系统性阐述。例如在描述休眠唤醒测试时，仅简单提及“发送报文唤醒 BMS”，未涉及唤醒条件、时序、状态跳转、结果校验等关键测试细节。

面试官考察点

• 项目真实性与角色定位：通过询问台架搭建、用例来源、是否为外包等，验证候选人经历的真实性及其在项目中的实际角色（主导者还是执行者）。
• 工具熟练度：考察对 CANoe（Trace、Graphics 面板）、CAPL 脚本、测试用例管理工具的实际操作能力。
• 测试设计能力：通过询问用例编写方法（等价类、边界值、场景法）和具体功能的测试细节，评估其测试设计思维。
• 问题闭环能力：通过要求举例说明“不好排查的问题”及 Bug 管理流程，考察其问题分析深度和从发现到解决的闭环能力。
• 技术知识广度与深度：通过提问 NRC、唤醒方式、网络管理、Bootloader 刷写等，探测候选人的知识边界和理解深度。
• 岗位意愿与沟通能力：通过询问对岗位工作内容的疑问，了解其求职动机和沟通表达清晰度。

证据摘录

• “那个是应该是一个嗯导图吧……就是现在用的没结果是吧？……因为基本要素就是。呃，测试i d啊，还有测试内容、前提条件、测试步骤、预期结果、实际结果吧。”
• “这个我一般我当时想跟你姐说一下，就是线束连接的话是我来连接的，一般都是他那个电梯工程师人人家来搭建的。”
• “哦，他只我只是简单的就是去修改，写的话，现在正在努力。反正就是也没有写过一些脚本是吧，就是自己去写一些，对吧？嗯，行。”
• “就是通过他那个温度传感器检测它那个电压温度。然后检测完之后看它的温度过高还是过低。如果过高的话，就是你那个冷却处理嘛……当它那个电池温度大于四十三时会进入一个三档的冷却模式。”
• “这个的话就是嗯。就是一个那个叫就那个单压就单体电压跟那个阈值嘛，然后就排查他那个连线啊，还会检测他那个s c c c s正常不正常啊，以及它那个单体电压等不等。”
• “如果出现了bug的话，就记录bug从g r传到上面，传输到咱们那个开发那边。就是七万的话，你也不用是吧？嗯，是的。”

评级建议

• 建议评级：C+
• 推荐方向：在有用例库和完善流程支持下的 BMS 台架测试执行、回归测试执行等初级岗位。
• 谨慎方向：需要独立设计测试方案、编写自动化脚本、搭建或深度调试 HIL 台架、主导复杂问题攻关的岗位。
• 面试推进建议：若岗位为初级执行岗且有人带教，可作为备选；若岗位要求独立工作能力，建议淘汰。如需进一步判断，建议补问 CAPL 脚本修改的具体实例、休眠唤醒测试的完整时序和判断逻辑。

可补问问题

• 请具体描述一次你修改 CAPL 脚本的经历：是为了实现什么功能，修改了哪些部分，遇到了什么问题，最终如何验证修改正确？
• 在休眠唤醒测试中，除了发送网络管理报文，你还会监控哪些信号或状态来判断唤醒是否成功？唤醒流程的完整时序是怎样的？
• 你提到通过 Jira 提 Bug，请举例说明一个你提交的、最终被开发确认并修复的 Bug，从发现现象、定位过程到根因是什么？
• 如果台架上出现一个偶发的通信丢失故障，你会如何设计测试方案来复现和排查这个问题？
• 你对 Bootloader 刷写流程了解多少？测试时会关注哪些关键点和异常情况？