未透露姓名候选人 - 吉利 HIL / 三电软件测试面试分析

来源

• 输入文件：E:\OPROJECT\Vtest\results\audio\吉利HIL.txt
• 场次判断：单独一场完整技术面试记录。
• 姓名说明：转写中未出现可可靠确认的候选人姓名，文档不编造姓名。

岗位方向

• 目标方向：吉利外包岗位，偏三电 / 底盘 / 动力域测试，面试官重点强调更接近 BMS HIL、充电产品、软件测试方向。
• 候选人自述经历：约 3 年测试经历，外派广汽，涉及 ADAS 实车测试与 BMS HIL 测试；候选人自评更偏软件测试。
• 相关产品/系统：BMS、充放电、热管理、OBC、DCDC、充电桩、预控制器等方向具有一定迁移相关性。

整体结论

候选人具备较扎实的测试执行、工具使用和基础诊断知识，能较完整描述 CANoe、TSMaster、INCA、UDS、缺陷流转和用例评审流程，适合中初级到中级的 HIL/三电软件测试执行岗位。主要短板在于自动化脚本开发、VT 台架搭建、仿真建模和从 0 到 1 测试设计深度不足；如岗位以手工/半自动测试执行、问题复现、基础标定和诊断配合为主，匹配度较高；若要求独立搭建 HIL 环境或主导自动化开发，则存在明显风险。

答得好的点

1. 工具使用描述较具体
   - 能说明 CANoe 中 DBC、Signal、Message、Node、Network、Simulation、IG、Trace、Graphics 等使用场景。
   - 能描述 TSMaster 的报文发送、诊断分析、Trace、总线记录等常用窗口。
   - 能讲出 INCA 从新建数据库、导入 A2L/HEX、创建工作区、配置硬件、进入标定界面、下载到 ECU、回读验证的基本流程。

2. UDS 基础知识覆盖面较全
   - 能列举 0x10 会话控制、0x11 ECU 复位、0x14 清除诊断信息、0x19 读 DTC、0x22 读数据、0x2E 写数据、0x27 安全访问、0x3E TesterPresent。
   - 能列举部分 NRC，如 0x12、0x13、0x22、0x31、0x33，说明有实际接触或系统学习基础。

3. 测试流程意识较完整
   - 能描述发现问题后先排查自身误操作、软硬件问题，再提交缺陷，附截图、log、测试步骤、结果、优先级等信息。
   - 对回归测试、关闭 bug、需求不清时找需求方确认等流程有认识。

4. 项目稳定性和到岗条件较好
   - 自述毕业后主要一段外派经历，约 3 年，离职状态，到岗较快。
   - 可接受外包性质和一定加班，对工作地点、租房、生活环境接受度较高。

5. 沟通表达较主动
   - 面试中能较自然地补充自己的经历、迁移原因、职业规划和生活安排。
   - 对平台、学习自动化/侧开方向有明确诉求。

薄弱风险

1. 自动化脚本能力偏基础
   - 候选人提到 CAPL 中 on key、on message、timer、setTimer 等基础事件和函数，但未体现独立设计自动化判断逻辑或自动化框架能力。
   - 明确表示未参与自动化测试工作，更多是按测试用例执行。

2. VT 台架搭建能力不足
   - 对“VT 测试台架能到什么程度”明确回答不能独立搭台架，只能进行简单连线、根据 pin 脚图处理基础硬件连接。
   - 对仿真能力回答“不太能”，更偏测试执行。

3. 测试设计深度一般
   - 自述用例多基于已有用例库和需求 ID 增删修改，评审通过率约六七成。
   - 能做用例维护，但从完整需求出发独立设计复杂测试体系的能力尚未充分证明。

4. 项目/产品归属和深度存在不确定性
   - BMS 项目中部分小项目不清楚车型或具体型号，说明对产品级上下文掌握可能有限。
   - ADAS 与 BMS 两类经历跨度较大，BMS/HIL 是否为长期主责需要结合简历进一步核验。

5. 专业背景非汽车/电子/软件科班
   - 酒店管理专业转行，虽然已有实践经验，但底层理论、电子电气、控制和软件开发基础可能相对薄弱。

面试官考察点

1. 岗位与外包性质接受度
   - 是否接受外包、地点、加班、薪资区间和生活环境。

2. 三电/HIL 方向匹配度
   - 面试官明确说明岗位不做 ADAS，而偏三电、底盘、动力域，重点看 BMS HIL 经验可迁移性。

3. 工具链熟练度
   - CANoe、TSMaster、INCA、万用表、示波器、VT 台架等是否日常使用且能说出实际操作流程。

4. UDS 诊断和刷写基础
   - 常用诊断服务、正负响应、NRC、刷写/故障排查场景中的应用。

5. 脚本与自动化能力
   - CAPL 基础语法、事件、定时器、函数，以及是否参与自动化测试。

6. 测试用例与缺陷管理能力
   - 用例编写数量、评审流程、缺陷提交、问题推动和回归闭环。

7. 硬件与仿真能力边界
   - 是否能读电气原理图、pin 脚图，是否能独立搭建 VT 台架，是否能做仿真。

证据摘录

“先做过 ADS 和 BMS HIL 的测试。ADS 我主要负责的是实车测试……BMS HIL 的话我做过 ACD 在充放电，然后 BMS 热管理故障注入。”

“工具的话，那最常用的肯定是 CANoe……DBC 文件的话它主要架构就是 signal、message、node、network……”

“INCA 这边……创建一个新的数据库……把 A2L 还有 HEX 文件导进去……配置硬件……选择需要修改的标定量进行修改……再将修改后的数据下载到 ECU 里面。”

“常用的一些服务……10 服务……11 电控单元复位……14 清除诊断信息……19 服务……22 读数据，2E 写数据，27 安全访问……3E。”

“自动化测试不是我负责的……我这边只是按照测试用例进行执行。”

“VT 测试台架这个到什么程度呢？这里可以搭？……不行，这个我不行，还没有到可以搭那个台架的。”

“问题推动……谁的 bug 就是谁来推……提交到质量系统里面……截图、log、概述 ID、优先级、报告人、经办人、测试步骤、测试结果……”

评级建议

• 建议评级：中级偏下 / 初中级之间，倾向中级入门。
• 推荐结论：有条件通过。
• 适配岗位： HIL/三电软件测试执行、基础诊断测试、标定数据测量、缺陷复现与回归、用例维护。
• 不建议直接承担： 独立搭建 VT/HIL 环境、复杂 CAPL 自动化开发、从 0 到 1 主导测试方案设计、以太网/高级诊断专项负责人。
• 入职后培养重点： CAPL 自动判定脚本、VT/通道配置和台架故障排查、充电产品业务知识、以太网/CAN FD、完整测试方案设计能力。