候选人面试分析：中科创达～江淮

来源

• 转写文件：中科创达～江淮.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：转写文本存在较多口语重复、语句断裂和少量语音识别错误（如“e p d”应为“EPB”、“i v h”应为“AVH”、“blank”应为“平台”或类似车型代号），但不影响对候选人核心能力的整体判断。对话为单人面试，结构清晰。

岗位方向

• 主要匹配：车身域/底盘域功能测试（偏执行与基础分析）
• 次要匹配：整车功能测试、供应商驻场测试
• 岗位适配判断：候选人更适合按用例库执行的测试岗位，不适合需要独立设计功能规范、定义信号需求或主导跨域复杂功能开发的岗位。

整体结论

候选人具备约2年左右的整车功能测试经验，主要经历集中在车身域（车窗、车门、灯光）和底盘域基础功能（EPB、AVH、驾驶模式切换）的测试执行。其工作模式以拉取现有用例库并执行测试为主，具备一定的测试用例编写和评审经验，但技术深度有限。在项目细节上，候选人能清晰描述一个车窗防夹功能的Bug分析过程，体现了基本的测试执行和问题定位能力。然而，当面试官深入追问控制逻辑、信号定义、能量回收策略及复杂跨域功能时，候选人的回答多为浅层、模糊或直接表示“了解不多”、“没怎么接触过”，暴露出在系统级理解、通信协议设计和复杂问题闭环能力上的明显短板。整体来看，候选人是一名合格的初级测试执行人员，但距离能够独立承担功能开发、信号定义和跨域问题推进的岗位要求尚有较大差距。

答得好的点

• 车窗防夹Bug分析有细节：能清晰复述一个具体的车窗防夹功能失效案例，包括测试手法（用塑料瓶模拟障碍物）、失效现象、根因分析（电流传感器灵敏度阈值过低，约23）及解决方案（重新校准灵敏度参数），体现了基本的测试执行和问题定位闭环能力。
• 基础功能交互逻辑清晰：在描述车窗控制时，能准确说出信号链路“车机大屏 -> GW -> BCM -> 驱动电机 -> 反馈给AVI”，表明其对车身域基础网络拓扑和信号流有正确认知。
• 高压上电流程描述基本正确：能大致复述交流充电唤醒流程（OBC唤醒BMS -> BMS初始化 -> VCU确认 -> 闭合继电器）和钥匙上电流程，说明其对高压安全流程有基础了解。
• 工具链基础认知存在：确认能看懂网络拓扑图、DBC文件、CAN通信矩阵，并提及使用Trace面板、Graphs和DBC文件进行信号解析，工具能力描述与岗位要求部分匹配。
• 驾驶模式切换测试点列举具体：能列举出驾驶模式切换的测试点，如模式切换是否正常、记忆功能（不同账号登录）、语音切换等，表明其具备基础的测试设计思路。

薄弱风险

• 技术深度严重不足，止步于表面：当被追问驾驶模式的具体控制逻辑（如扭矩控制、能量回收策略、与悬架联动）时，候选人回答模糊，仅能说出“VCU计算扭矩发给MCU”，无法解释VCU下发何种控制信号、电机如何响应，对能量回收的策略描述也停留在“制动踏板->传感器->VCU”的浅层，缺乏对控制闭环的理解。
• 信号定义与设计能力缺失：面试官直接考察“新增一个温度信号如何定义（占多少位、放哪个报文ID）”，候选人明确表示“有点难度”、“不是很了解”，仅猜测温度信号“占8位左右”，并依赖通信矩阵被动解析，不具备独立定义信号需求的能力，这是岗位核心要求的重大短板。
• 复杂跨域功能经验匮乏：当被问及EPB在复杂场景（如维修模式、拖车模式）下的关联控制时，候选人直接表示“没怎么接触过”、“测试过程中也没有碰到过”，对多控制器联动的复杂功能（如跨域功能）也坦言“接触的很少”，经验局限于单一控制器的基础功能。
• 工作模式偏被动执行：候选人描述其测试用例来源为“有个云库，直接去拉取”，虽提及会自己编写用例并评审，但整体工作模式更偏向于依据现有规范执行，而非从功能规范出发进行独立设计和主导推进。
• 问题定位能力偏重表层信号解析：在描述问题定位时，仅提及使用Trace和Graphs看波形、解析信号，未展现出结合日志、代码或更深层次诊断工具进行根因分析的能力，分析手段相对单一。
• 对岗位职责理解有偏差：当面试官介绍岗位是“功能开发+测试”的侧开性质时，候选人仅以“可以理解为侧开是吧”回应，未展现出对开发职责的深入理解或相关经验，与其被动执行的经验背景一致。

面试官考察点

• 项目真实性验证：通过追问具体车型、负责功能（EPB/AVH/充放电）及测试内容，验证候选人简历经历的真实性。
• 测试设计能力：询问是“有限评估”还是“解读规范编写用例”，考察候选人是否具备独立设计测试用例的能力。
• 技术深度与系统理解：连续追问驾驶模式的控制逻辑、能量回收策略、EPB的复杂关联场景，旨在探测候选人对控制原理和系统交互的理解深度。
• 通信与信号设计能力：直接要求候选人定义一个新信号（如温度信号），考察其是否具备岗位所需的信号需求定义和通信矩阵设计能力。
• 问题闭环与分析能力：通过车窗防夹案例，考察候选人是否能独立进行问题分析、定位根因并提出解决方案，而不仅仅是上报Bug。
• 复杂功能与跨域经验：询问涉及多个控制器的复杂功能，评估候选人处理跨域、系统性问题的能力边界。
• 工具链真实熟练度：通过询问拓扑图、DBC、ARXML、信号解析工具的使用，验证其工具能力是否可落地。
• 岗位意愿与匹配度：介绍岗位的“功能开发+测试”性质，观察候选人的反应和理解，判断其与岗位的匹配程度。

证据摘录

• “测试测测试这块的话，我们就是平常的话，我们是有个云库的，然后我们直接去拉取。然后平常的话也会使用呃那个呃去自己去编写一个测试用例。然后然后编写过之后呢，你会经过一个小组的一个评审吗。”
• “当时我们就是进行了一个分析嘛。然后车窗框架它是通过一个呃，它通过一个检测电机的一个电流变化来判断的他是否遇到了一个障碍物。就当时我们检查之后呢，就是说它的一个电流传感器的一个灵敏度设计的比较过低……当时记得是这个阈值的话好像是二十三或者是然后当时它是没有触发到吧。”
• “嗯，驾驶模式就比如说一个驾驶模式的切换嘛，就说验证不同的一个驾驶模式，就看他会感觉是否正常。然后就不同驾驶的一个正常，以及它的一个驾驶模式一个记忆。”
• “这个这个当时我我嗯这个不是说很了解，因为当时我们也是通过那个嗯什么通讯矩阵来去就是说制造一个就是就是直接是直接去调动d b c就是就是解析了是吧？对，没有去自己去很详细的。”
• “嗯，这个涉及到关联的e d d的控制，之前有了解过这个这个没怎么接触过。……没有就测试过程中也没有也没有碰到过是吧？好的。”
• “因为当时我在未来那边做的主要是东一盘车身那块儿的话，主要做的有点久了哦，应该也不是说接触的很多。”

评级建议

• 建议评级：C+
• 推荐方向：车身域/底盘域基础功能的测试执行岗位，严格遵循现有测试用例库进行工作，或在有明确规范指导下的供应商驻场测试任务。
• 谨慎方向：功能开发/侧开岗位、需要独立设计功能规范或信号定义的岗位、涉及复杂跨域功能或多控制器联调的系统级测试岗位。
• 面试推进建议：不建议作为当前“功能开发+测试”岗位的候选人继续推进。若公司有初级测试执行岗位空缺，可作为备选，但需在复试中重点补问其独立学习能力和系统思维潜力。

可补问问题

• 请举一个你独立编写的、且被评审通过的测试用例，说明你是依据哪份功能规范设计的，覆盖了哪些边界条件和异常场景？
• 在车窗防夹案例中，你提到重新校准了电流传感器灵敏度参数。请问这个参数是在哪个控制器（BCM/门窗模块）的哪个软件组件中？你是通过什么工具或流程完成校准的？
• 如果现在让你负责“舒适进入”这个跨域功能（涉及BCM、PEPS、座椅、网关等）的测试，你会从哪几个维度去设计测试用例？第一步会做什么？
• 你提到能看懂DBC文件，请解释一下DBC中一个信号的“Factor”和“Offset”是做什么用的？如果实际收到的信号值与物理值对不上，你会如何排查？
• 在你过去的工作中，有没有遇到过需要推动其他团队（如软件开发、系统工程师）解决一个你发现的复杂Bug的经历？你是如何推动并最终闭环的？