候选人面试分析：东风～猛士

来源

• 转写文件：东风～猛士.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：转写文本存在较多口语化表达、重复和少量语音识别错误（如“康毅”可能为“康宇”或“CANoe”，“最大系统”可能为“Jira系统”），但不影响对候选人能力的整体判断。对话中存在面试官与候选人、以及另一位面试官（李工）的多方对话。

岗位方向

• 主要匹配：整车功能测试（偏动力底盘、充电系统、VCU）。
• 次要匹配：诊断测试（UDS）。
• 岗位适配判断：候选人更适合执行层面的整车功能测试或诊断测试岗位，不适合需要独立设计测试架构或主导自动化测试框架开发的岗位。

整体结论

候选人拥有约两年多的汽车电子测试外包经验，主要涉及动力底盘功能测试和BMS/充电系统测试，分别在吉利和奇瑞的项目中驻场工作。其测试执行能力基本合格，能够按照用例库完成测试任务，并对测试中遇到的问题进行初步排查与定位。对UDS诊断服务有一定了解，能列举常见服务ID和基本流程。工具方面，接触过CANoe、周立功、示波器等，但对CAPL脚本的掌握仅停留在简单修改层面，缺乏独立编写能力。

主要优势在于有实车测试经验、工作态度严谨、对加班和驻场模式接受度高。主要风险在于技术深度不足，所有项目经验均为外包驻场执行，缺乏独立设计测试用例和自动化测试开发的能力，回答多停留在操作层面，缺乏对测试逻辑、系统原理和问题闭环的深入阐述。整体属于初级偏上的执行型测试人员，可考虑作为基础测试岗位的备选。

答得好的点

• 对预约充电功能的测试流程描述清晰，涵盖了时间设置、插枪、自动启动、手动控制、SOC限制及异常打断等场景，体现了基本的测试执行思路。
• 对UDS诊断服务有一定知识储备，能准确列举10、11、14、19、22、2E、27等服务及其功能，并提到了安全访问的流程。
• 表现出良好的问题排查意识，提到在提交Bug前会先自查操作和前提条件，避免无效流转，体现了基本的责任心。
• 对自身能力有较客观的认知，坦诚CAPL脚本能力仅限于简单修改，未过度包装。
• 对驻场外包的工作模式非常适应，对加班和接触新模块（如VCU）持积极学习态度，岗位匹配意愿强。
• 有实车测试经验，而非纯台架或HIL测试，这对整车功能测试岗位是加分项。

薄弱风险

• 技术深度严重不足：对UDS的回答仅停留在服务ID的罗列，当被问及安全访问的具体过程（如请求种子、发送密钥）时，回答模糊，未能展开说明任何诊断指令的交互细节或测试方法。
• CAPL/自动化能力薄弱：明确表示脚本“一般都是开发给我们”，自己只做“简单的修改”，虽有C语言基础但无实际编写经验，无法承担自动化测试开发或复杂脚本维护工作。
• 用例设计能力缺失：测试用例主要来自“公司用例库”，自己仅在用例“不符合”时修改，未展现出独立设计测试用例、构建测试场景的能力，属于纯执行角色。
• 项目经验均为外包执行：两段经历都是作为外包人员驻场，项目结束后即离职，缺乏从0到1的测试体系构建经验，对测试流程的整体把控能力存疑。
• 回答缺乏系统性与深度：对测试内容的描述多为操作步骤，缺乏对测试逻辑、系统交互、边界条件、问题闭环分析的深入阐述，例如未提及充电测试中与BMS、VCU、车联网的交互逻辑。
• 工具链使用停留在基础层面：虽提及CANoe、周立功等工具，但未说明具体使用场景（如报文分析、信号监控、仿真），仅作为名词带过，工具应用能力无法验证。
• 职业稳定性风险：因项目结束、无新增项目而离职，未来在项目间歇期可能存在类似稳定性问题。

面试官考察点

• 项目真实性验证：通过询问具体测试功能（预约充电）和项目地点（吉利、奇瑞），验证候选人经历的真实性。
• 测试执行细节：深挖预约充电的测试流程，考察候选人是否真正动手测过，以及测试的颗粒度。
• 问题分析与闭环能力：询问测试不符合预期时的处理方式，验证其是否具备初步的排查定位能力，还是直接流转给研发。
• 用例设计能力：直接询问是否自己写用例，判断其是纯执行者还是具备一定设计能力。
• UDS诊断技术深度：从服务ID列举深入到安全访问的具体过程，考察其对诊断协议的理解是停留在表面还是能落地测试。
• 自动化测试能力：追问CAPL脚本的编写和维护情况，判断其是否具备自动化测试开发潜力。
• 岗位意愿与稳定性：通过询问离职原因、对驻场外包的接受度、对加班的看法，评估其入职意愿和团队匹配度。

证据摘录

• “我们预约充电主要是一个预约的时间啊，然后还有嗯像本地预约，还有呃远远程预约。像嗯本地预约的话，我们就是测试它的一个呃逻辑……比如说我们测试嗯六点钟，我想六点钟充电，然后我们一般测试流程就是呃设置好了时间，然后去把枪插上，然后看它到了时间它有没有充电，然后或者用其他的那个行为去打断它的这种充电。”
• “一般是我们是用的公司那个用例库，那自己写也可以。比如说那种有的用例它就不符合，然后我们就可以自己写。”
• “会分析的。我们先看一下这种不符合是而不是我们自己操作原因，还是说嗯条件没有符合呀。比如说他不是有前提条件嘛，如果条件条前提条件他不符合的话，那就是我们自己原因嘛。到时候推到开发那边去，人家还是说我们呃干活不行了。”
• “u d s它主要就是那个诊断服务嘛，像呃我们一般的那个绘画呀，幺零服务就是三个户啊，幺零零二幺零二、幺零三，然后还有幺幺服务啊。呃幺幺零幺它的硬复位，幺幺零三它的软复位，还有幺四呃诊断故障码呃，清除诊断故障码，然后还有幺九呃查询故障码。”
• “但其实这个开户脚本一般都是开发给我们，呃，我也其实也只是做一个简单的修改。”
• “呃离职就是因为我们之前那家公司他项目结束了，然后挺长时间没有接到那个新增项目，每每个月就只发底薪吗？”

评级建议

• 建议评级：C+
• 推荐方向：可考虑作为整车功能测试（充电/动力底盘）或诊断测试的执行岗位备选，适合有明确用例库、需要大量重复性测试执行和问题初步排查的任务。
• 谨慎方向：不建议直接承担需要独立设计测试方案、搭建自动化测试框架、或主导复杂问题分析定位的岗位。
• 面试推进建议：可作为初级岗位的备选人才。若团队急需能快速上手、接受加班的执行层，可安排复试，重点补问CAPL实操和诊断测试细节。若对技术深度和自动化能力有硬性要求，建议淘汰。

可补问问题

• 请具体描述一个你用CANoe分析过的报文问题，比如看到了什么异常信号，如何定位到是哪个控制器或哪段逻辑出的问题？
• 在UDS安全访问（27服务）测试中，你是如何手动或自动构造请求种子和发送密钥的？请具体说明测试步骤和用到的工具命令。
• 你提到可以修改CAPL脚本，请举一个你实际修改过的例子，修改了哪部分逻辑，解决了什么问题？
• 在预约充电测试中，如果充电未按预约时间启动，你会从哪几个方面去排查？请列出你的分析路径和可能涉及的系统（如T-Box、BMS、VCU、充电桩）。
• 除了执行用例，你有没有发现过用例库之外的Bug？请分享一个你独立发现的、最有价值的缺陷及其闭环过程。