候选人面试分析：龙创～整车

来源

• 转写文件：龙创～整车.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：转写文本存在较严重的语音识别错误、口语重复和断句不清，部分技术术语可能识别有误（如“发帖流程”疑为“刷写流程”，“幺九服务”疑为“19服务”，“e b s”疑为“EPB”），需结合上下文理解。对话中面试官与候选人声音混杂，部分问题与回答的对应关系不够清晰。

岗位方向

• 主要匹配：整车功能测试（底盘域/车身域/动力域集成测试）。
• 次要匹配：供应商驻场测试、台架测试。
• 岗位适配判断：候选人更适合按测试用例执行的整车集成测试岗位，不适合需要独立设计测试策略或深度工具链开发的岗位。

整体结论

候选人具备整车道路功能测试的实际经验，主要集中在底盘域（如EPB、AH自动驻车）的实车验证，能够描述测试场景、发现的问题以及与开发人员的协作闭环。回答中提到了CANoe工具的基本使用（查看信号、发送报文），但对脚本编写（如CAPL）明确表示不熟悉。整体技术深度停留在“用例执行与问题上报”层面，缺乏测试用例设计、自动化测试开发、诊断协议深入应用等证据。优势在于有真实的整车测试项目经历，对实车测试风险有认知，且对加班和出差接受度高。主要风险是技术能力较为单一，工具链掌握偏浅，独立设计和深度排查能力未验证。适合作为整车功能测试执行岗位的候选人，可谨慎推进。

答得好的点

• 真实项目经历描述具体：能清晰回忆出AH（自动驻车）在15度坡道上的测试场景，包括车辆后溜的风险和与开发反馈优化的闭环，体现了实车测试经验。
• 问题闭环意识：在EPB信号与仪表显示不一致的例子中，描述了与开发一起抓取报文、对比工况、定位逻辑错误、重新刷写并回归测试的完整流程。
• 工具基础使用：确认使用过CANoe进行信号查看和报文发送，具备基本的总线监控能力。
• 诊断协议有基础认知：能说出19服务（读取故障码）、27服务（安全访问）等UDS诊断服务，表明接触过诊断测试。
• 工作态度务实：对加班和出差表示理解和接受，并主动询问入职后的职责范围和个人成长机会，表现出一定的稳定性。
• 风险意识强：在描述AH测试问题时，特别提到测试车碰撞的风险和后果，显示出对实车测试安全性的重视。

薄弱风险

• 测试用例设计能力未体现：明确表示测试用例主要来自“天津的用例库”，工作是根据需求进行优化，当被问及是否能自己实际编写时，回答模糊，未展示独立设计用例的能力。
• 工具链掌握偏浅：虽然使用CANoe，但仅限于查看信号和发送报文，明确表示“脚本没怎么做过”，缺乏CAPL或自动化测试脚本开发能力。
• 诊断测试深度不足：仅能列举UDS服务名称，当被要求举例说明诊断测试的具体运用和问题定位时，未能给出实际案例，回答停留在概念层面。
• 问题定位依赖开发：在EPB和AH的两个问题例子中，定位工作主要由开发人员完成，候选人角色偏向“发现问题、上报问题、配合验证”，缺乏独立根因分析的证据。
• 问题管理工具模糊：当被问及使用什么工具管理问题（Excel、邮件还是系统）时，回答含糊，仅说“通过计划上传问题”，未体现出对专业缺陷管理工具（如Jira）的熟练使用。
• 技术广度有限：经历集中在底盘域功能测试，对车身域、动力域、座舱域等其他整车域的了解未在对话中体现，能力相对单一。

面试官考察点

• 项目真实性验证：通过要求举例具体测试场景和问题，验证候选人是否真正参与过实车测试。
• 测试执行能力：考察候选人是否理解测试用例来源，以及能否根据需求进行用例优化。
• 诊断测试基础：验证候选人对UDS诊断服务的了解程度和实际运用经验。
• 问题定位与闭环能力：通过追问bug发现后的定位、分析、上报、修复、回归全流程，判断候选人独立解决问题的能力。
• 工具链熟练度：考察CANoe的实际使用深度，以及是否具备脚本编写和自动化测试能力。
• 问题管理流程：了解候选人所在团队的问题管理方式和工具，判断其流程规范性。
• 工作意愿与稳定性：通过询问加班、出差接受度，以及候选人对入职后职责和成长的关注，评估其匹配度和稳定性。

证据摘录

• “我们就是天津会有一个用力库，然后根据这个用据库的拿来就根据需求如果是不相符的进行一些优优化。”
• “我当时那个他都做了一个那个a h的一个测试。我们记得当时带的是一个坡度十五度的左右一个场景。然后当时我踩下它那个刹车之后，它那个仪表就是显示这个a p p已经激活了。然后我那个松开刹车，他那车就突然间往后溜了。”
• “通过那个开发一起抓人，来帮我们跟他一个呃实时的工况做一个对比，然后去做一个排查嘛，就是发现他那个是应该是开发把那个a p p的他那个新装线上那个逻辑的做法吧。”
• “那个脚本那个自自自己编写还是什么啊？这个倒是没怎么用做过。”
• “咱们那个有那个他他那个幺九服务，它这个读取一个读取故障码，或者说咱们是那个幺那个幺幺零二七那个读一个那个编程规划，或者说那个二七的行政手册之类。”
• “我们有可能就是一个人。就是根据测试用例，就是从上往下走，就是可能车身也得有，然后底盘，然后动力就。”

评级建议

• 建议评级：C+
• 推荐方向：整车功能测试执行（按用例进行实车或台架测试）、供应商驻场测试（偏执行）。
• 谨慎方向：测试用例设计、自动化测试开发、诊断专项测试、需要独立定位复杂问题的系统级测试岗位。
• 面试推进建议：可作为整车集成测试执行岗位的备选候选人，不建议直接淘汰。若推进复试，需重点补问用例设计能力、CANoe实际使用深度（如DBC文件、数据分析）、以及是否独立完成过任何一项测试的闭环定位。

可补问问题

• 请举一个你完全独立设计测试用例的例子，说明你是如何分析需求、确定测试条件和预期结果的？
• 在CANoe中，你使用过哪些具体功能？是否自己创建过Panel或配置过DBC文件来分析报文？
• 你提到诊断服务，请具体描述一次你使用诊断仪或CANoe发送诊断请求，并成功定位到ECU故障的完整过程。
• 除了底盘域功能，你是否测试过车身域（如灯光、门锁）或动力域（如上下电、扭矩控制）？请举例说明。
• 在之前的问题管理流程中，你具体使用什么系统（如Jira、禅道）提交bug？bug单中通常包含哪些必要信息？
• 如果给你一个全新的ECU功能，没有现成用例，你会如何着手开展测试？请描述你的思路和步骤。