候选人面试分析：车身域-吉利骏玖

来源

• 转写文件：车身域-吉利骏玖.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：转写文本存在较多语音识别错误、口语重复和断句不清，部分技术术语可能被误识别（如“康逸了”应为“CANoe”，“红星”可能为“红盒”或“宏信”等），但不影响对候选人整体能力的判断。

岗位方向

• 主要匹配：车身域测试（灯光、车窗、门锁等）、整车功能测试。
• 次要匹配：诊断测试（UDS刷写）、座舱域测试。
• 岗位适配判断：候选人更适合车身域或整车集成的测试执行岗位，不适合需要独立设计测试策略、搭建台架或主导复杂问题分析的岗位。

整体结论

候选人具备1-3年左右的车身域及整车功能测试经验，熟悉常见的车身控制器（BCM）相关功能（灯光、车窗、门锁、雨刮）的测试逻辑，了解UDS诊断服务和刷写流程，并能使用CANoe等工具进行测试。从回答来看，候选人的经验主要集中在测试执行层面，能够按照既定的测试用例进行操作、提交Bug并进行回归测试。对整车开发流程（PP、TT、PP、SOP）有基本认知。

主要优势在于有实际的项目落地经验（长城项目），对车身域常见功能的测试逻辑和诊断负响应码有一定了解。主要风险在于技术深度不足，回答多为功能逻辑描述而非测试设计思路，缺乏独立搭建台架、设计测试策略或深入分析问题的证据。工具使用停留在“了解”和“常用”层面，未展现出深度应用能力。整体来看，候选人是一个合格的初级到中级测试执行人员，可以推进，但需在复试中重点考察其测试设计能力和问题闭环能力。

答得好的点

• 对车身域常见功能（灯光、车窗防夹、门锁）的测试逻辑有清晰描述，例如车窗防夹的力矩触发和下降距离，门锁的多种解锁方式（钥匙、APP、卡片、物理）。
• 对UDS诊断服务（10, 14, 19, 22, 2E, 11, 27, 28, 31）及常见负响应码（NRC 0x22, 0x31, 0x33, 0x35）有基本了解，并能解释刷写流程中的正负响应判断。
• 对整车开发测试流程（PP1-3, TT1-3, SOP, OTA）有基本认知，能说出各阶段的主要测试目标（工艺验证、软硬件集成、异常场景/可靠性、全功能）。
• 有实际项目经验，明确提到当前在做长城项目，地点在保定，增加了经历的真实性。
• 能够列举常用的测试工具（CANoe、万用表、示波器、金卡），并提及使用Jira提交Bug。

薄弱风险

• 技术深度不足：对UDS的回答停留在“发一个请求，看正负响应”的层面，未涉及具体诊断报文分析、DID数据解析或刷写流程的安全访问（27服务）细节。当面试官追问“怎么判断被锁了”时，候选人回答的是通用的负响应码，而非结合具体故障场景的分析。
• 测试设计能力存疑：所有回答都是对已有功能逻辑的描述，而非“如何测试它”。例如，门锁部分只讲了功能逻辑（怎么解锁/闭锁），未提及如何设计测试用例去覆盖异常场景、边界条件或性能压力。
• 工具链掌握较浅：提及CANoe、示波器等工具，但未结合任何具体项目说明如何使用（如用CANoe发什么报文、监控什么信号、如何用示波器抓取车窗防夹的电流波形）。回答停留在“常用”层面。
• 缺乏独立主导经验：当面试官询问是否做过台架搭建、电路沟通、电阻测试时，候选人仅表示“知道一些”，明确了自己是“软件负责”，暗示其工作主要是软件功能测试，缺乏硬件集成和台架搭建能力。
• 问题闭环能力未体现：提到了提交Bug和回归测试，但未举出任何一个具体的问题分析、定位和闭环的案例，无法评估其问题解决深度。
• 回答被动且模糊：多次出现“不好意思，没有听到”、“您说的意思是...”，且对面试官关于“节点”、“交付报告”等项目管理类问题的理解有偏差，沟通和归纳能力有待观察。

面试官考察点

• 项目真实性验证：通过询问项目地点（保定）、具体ECU名称（车门ECU叫什么）来验证候选人是否真的在长城项目上工作过。
• 测试边界与深度：追问“除了功能测试，还出过其他吗？比如台架、电路、电阻”，意在考察候选人是否具备硬件在环或台架测试能力，而不仅仅是软件功能执行。
• 技术原理理解：通过追问UDS“怎么判断被锁了”，考察候选人对诊断负响应机制的理解深度，而非仅背诵NRC码。
• 功能逻辑掌握度：通过门锁逻辑的提问，考察候选人对车身域功能需求的熟悉程度和系统性。
• 开发流程与节点意识：询问项目节点、交付报告，考察候选人对整车开发流程（V模型）和测试交付物的理解。
• 工具链熟练度：通过询问灯光是“立件”还是“看件”（可能为“硬件在环”或“实车”的误识别），以及雨刮的测试方式，侧面验证其对不同测试环境和工具的熟悉程度。
• 岗位意愿与稳定性：候选人主动询问工作内容和二面时间，表现出一定的积极性。

证据摘录

• “是灯光、车窗、门锁、双光电g d c和h s c的一个测试。也做过这个座舱域的一个测试。”
• “车窗防夹的话，相当于我们当时然后在上面放一个这个水平，然后放一个水瓶之后，然后嗯然后让车窗开始往上上升。上升的过程中的话，然后它会它会它会到达一百米的扭矩，然后的话会开始往下下降，下降大概十五厘米左右。”
• “u d s的话像我们平常用的都是诊断和嗯诊断和刷写吧。我们u盘常用的那些嗯服务的话，幺零幺零的服务，幺四幺九二二嗯，还有这个嗯二一吧。然后包括这个二二八的服务。”
• “如果要出现负响应，负响应码的话，就是n r c的，n r c的这个负响应码嘛。如果要发送n r c负响应维码的话，是像这个嗯零x二这样条件不满足。然后零x三一嗯他的请求的话会退退出范围，零x三三的话会拒绝访拒绝拒绝访问，然后零x三五的话是像嗯嗯无效的无效的一个钥匙嘛等等等等。”
• “嗯，像嗯嗯像我们经常经常用到的话，像我们这个。嗯，解锁吧，然后解锁的话，我们车辆的话，你像我们假如说车辆车辆靠近这个解锁之后，然后我们就无钥匙开始进入，无钥匙进入。然后如果我们钥匙的话闭锁键嗯钥匙的闭锁键的话，然后所有的车门的话全同时闭锁。我们转转转向灯的话会闪闪一次。然后这个嗯钥匙的这个解锁键的话，然后所有车门解锁，然后嗯转转向的话会进行闪两次。”
• “嗯，然后我们这个嗯p p一杠三阶段嘛，p p一杠三阶段的话，我们这个然后发现工装工艺的问题，然后大概有个三个月左右。然后这个是验证生产，验证工艺的可行性，然后嗯进行再进入t t t t一杠三阶段。进入进入之后，然后我们主要是这个验证软硬件的这个集成吧，然后嗯实现基本的功能以及相关功能的一个模块。”

评级建议

• 建议评级：C+
• 推荐方向：车身域或整车功能的测试执行岗位，在已有测试用例和明确流程的团队中工作。
• 谨慎方向：需要独立设计测试方案、搭建测试台架、进行复杂问题定位或主导技术攻关的岗位。
• 面试推进建议：可作为备选进入复试。复试需重点补问测试用例设计、工具深度使用、问题分析闭环案例，以确认其潜力是否被低估。若急需能独立上手的高级人员，则不建议推进。

可补问问题

• 请举一个你最近提交的、印象最深刻的Bug，说明你是如何发现它的，如何定位根本原因，以及最终是如何被修复的？
• 在CANoe中，你具体使用过哪些功能？请描述一个你用CANoe创建面板、发送报文或进行信号监控来辅助测试的实际案例。
• 针对车窗防夹功能，除了放水瓶，你还会设计哪些测试用例来验证其在不同电压、温度或障碍物下的表现？
• 你提到做过座舱域测试，具体负责哪些功能？和车身域测试相比，你觉得座舱域测试的难点或不同点在哪里？
• 在长城项目中，你们的测试用例是从哪里来的？是完全自己写，还是基于需求文档或已有的用例库进行修改？请举例说明你曾补充或优化过的一个测试用例。