候选人面试分析：车身-小鹏-亿达信息

来源

• 转写文件：车身-小鹏-亿达信息.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：无特别备注。

岗位方向

• 主要匹配：车身域/座舱域功能测试（执行向）。
• 次要匹配：OBC/DCDC充电测试、基础诊断测试。
• 岗位适配判断：更适合按既定用例执行的实车功能测试岗位，不适合需要独立设计测试方案、深入分析信号与定位问题的系统级测试或开发岗位。

整体结论

候选人具备2-3年传统主机厂（东风、上汽、北汽）的实车功能测试经验，主要涉及OBC/DCDC充电、车身背光、雨刮、底盘AVH/HDC等基础功能的用例执行与问题提交。工具链上，对CANoe/CANalyzer有基本操作能力（录制、简单发送），了解UDS诊断基础服务（10/14/22/27/2E/19），对Linux命令和ADB有浅层了解。整体能力停留在“执行已有用例、记录现象、提交问题”的层面，技术深度明显不足：无法独立设计测试场景，对信号分析、校验机制（E2E/CRC）、故障定位逻辑、刷写流程细节、底盘功能测试方法等均缺乏深入理解。回答多为功能原理描述，而非测试方法论或问题闭环细节。优势在于有实车测试经验和基本的工具操作，态度积极；主要风险是技术深度与独立工作能力较弱，难以胜任需要自主分析、设计或复杂问题定位的岗位。建议作为初级执行岗备选，需在复试中重点验证其学习能力和逻辑思维。

答得好的点

• 对UDS诊断服务有基本了解，能准确说出10、14、22、27、2E、19、11等服务及用途，并能描述刷写流程的大致步骤（10/11/28/85/36/37/31/14）。
• 对CANoe的基本操作有实际经验，能描述创建工程、导入DBC、配置通道、录制报文的步骤，并知道CAN标准帧与FD帧的字节数差异。
• 能清晰描述一个具体的Bug发现与闭环过程（自动雨刮偶发失效），体现了基本的测试流程意识（复测、提交、闭环）。
• 对AVH/HDC等底盘功能的工作原理有概念性理解，能描述其激活与退出条件。
• 具备基本的进制转换能力，能正确计算十六进制0C对应的十进制值。
• 了解Linux基础命令（pwd, cd）和ADB基础命令（devices, version, logcat），表明有基本的工具接触。

薄弱风险

• 技术深度严重不足，仅停留在执行层：在OBC/DCDC测试中明确表示“我设计这一块比较少，一般大部分是一个动态的……我大部分是执行一些用例”，表明其不参与测试设计，仅为用例执行者。
• 缺乏信号分析与问题定位能力：在雨刮Bug案例中，当被问及如何定位到电压不稳时，回答是“提交完以后，然后眼镜件这块是不对的嘛，配电这块”，承认是研发定位，自己只做现象判断。对E2E/CRC校验机制仅“大概有一个了解”，无法说明具体标定方法。
• 底盘功能测试方法缺失：当被要求详述AVH/HDC的测试场景和方法时，候选人只能复述功能原理，无法说出具体测试场景（如坡度、动态/静态、扭矩输出等），面试官直接指出“可能其实测试的场景还是比较少的，大概只是了解一些基本功能”。
• 工具使用停留在表面，缺乏深度分析能力：对CANoe的Graph分析功能不熟悉，无法描述如何通过时间轴分析报文帧数和信号交互细节。对刷写流程的回答是“用工具然后去让他升级”，不了解中间环节的定位方法。
• 用例编写能力弱：承认“公司一般都有完整的它这个用例库……自己也会写，但是会比较少”，表明其工作高度依赖现有用例库，独立设计能力未经验证。
• 知识体系碎片化，缺乏系统性：对CAN FD波特率、故障码分类、DTC快照解析等问题的回答不准确或不清楚，显示知识多为零散记忆，未形成体系。
• OTA/以太网等新技术接触少：明确表示OTA“不太有，还没怎么接触过”，以太网仅“简单了解”，技术栈偏传统。

面试官考察点

• 项目经历真实性验证：通过询问公司、车型、具体测试领域，确认候选人实际参与的项目范围。
• UDS诊断服务掌握程度：通过询问常用服务（10/14/22/27/2E/19/11/31）、刷写流程、故障码分类与解析，考察其诊断测试的实操能力。
• CANoe/CANalyzer工具实操能力：通过询问版本、License、通道配置、报文发送步骤、E2E/CRC校验、Graph分析，验证其是否真正独立使用过工具进行数据采集与分析。
• 测试设计能力与场景覆盖度：通过要求详述AVH/HDC的测试方法、场景和输出，判断其是仅执行用例还是具备测试设计思维。
• 问题定位与闭环能力：通过追问Bug定位过程，区分候选人是仅记录现象还是能深入分析根因。
• 技术广度与学习意愿：通过询问以太网、Linux、ADB、OTA等，了解其知识边界和未来可塑性。
• 岗位匹配度与意愿：通过询问对功能的了解是来自测试还是个人用车，以及最后的学习建议，评估其与岗位的契合度及发展潜力。

证据摘录

• “嗯，因为当时有两个人嘛，我设计这一块比较少，一般大部分是一个动态的啊，不是一个静态的动态的，主要有另外一个东西嘛。有时候就我们d c充电的时候，只是执行一些用例吗？……嗯，我大部分是执行一些用力。”
• “嗯，第一步我肯定是进行一个，在呃我我发现完这个bug，我会进行一个就是说我再去测一下，看是不是自己误操作，或者一些比如说其他的原因。然后后来就后来提交完以后，然后眼镜件这块是不对的嘛，配电这块。哦，就相当于你们这边只是根据这些表现上判断，并不是会实时性的一些看位置，看它的一些信号的输出出，然后去定位的是吧？就相当于里边可能只是执行一下结果，然后分析逻辑的话可能还需要研发同学去看，是吧？”
• “嗯，像这个陡坡的话，就测试它这个呃待激活，就要到那个激活的一个状态嘛。然后你包括一些车辆的一些其他模式，运输啊运输模式这个功能是没有办法去开启的。……可能其实测试的场景还是比较少的，大概只是了解一些基本功能，只是测试的一些基础。”
• “c r c校验的话，它大概是怎么样的一个校验方式，你知道吗？这个我大概有一个了解，但是主要是这个功能功能方面的一个测试嘛还是不错。……嗯，没做这些方面的是吧？对对，就是简单有一些就是了解平时跟别人聊天什么的，看没关系没关系。”
• “这个公司一般都有完整的它这个用例库。然后自己的话可能说车辆的每个阶段不同，可能需要就是说。自己写自己写一些，就是说用力嘛，自己也也会写，但是会比较少，因为都有完整的那个用力库嘛。”
• “o t a这个在线升级这个这块儿是吧？这个。不太有。还没怎么接触过，在传统设计比较多一点是吧？就是传统有看工具一点设计嗯，大部分都是自自研的嘛。”

评级建议

• 建议评级：C+
• 推荐方向：车身域/座舱域实车功能测试执行、供应商驻场测试执行、按用例库进行的回归测试。
• 谨慎方向：BMS HIL测试、诊断/刷写专项测试、底盘性能测试、OTA测试、需要独立设计测试方案或深入分析信号的岗位。
• 面试推进建议：可作为初级执行岗备选，不建议直接淘汰。若推进复试，需重点补问：1）让其现场设计一个简单功能的测试用例；2）给一段CAN报文让其解析信号值；3）询问一个复杂Bug的完整定位过程，以验证其学习能力和逻辑思维潜力。若复试仍无深度，则淘汰。

可补问问题

• 请现场设计一个“自动大灯”功能的测试用例，至少包含5个不同的测试场景，并说明每个场景的预期结果。
• 给你一段包含8个字节的CAN报文（如0x123: 8, 01 02 03 04 05 06 07 08），其中第7字节是CRC校验，前7字节求和后与0xFF异或，请计算正确的CRC值。
• 描述一个你遇到的最复杂的Bug，从发现现象、分析日志/报文、定位根因到最终解决的全过程，越详细越好。
• 如果让你独立负责一个全新ECU的测试，没有现成用例库，你会如何开展测试工作？请描述你的思路和步骤。
• 在CANoe中，如何同时监控10个信号，并分析它们在一个特定事件发生前后500ms内的变化趋势？请描述具体操作。
• 你对未来1-2年的技术发展方向有什么规划？是否有计划深入学习诊断、自动化测试或某项工具？