候选人面试分析：麦吉客～总线测试

来源

• 转写文件：麦吉客～总线测试.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：转写文本存在较多语音识别错误、口语重复和断句不清，部分技术术语识别有误（如“二期服务”应为“27服务”，“鸡爪”应为“Jira”），但不影响对核心能力的整体判断。面试官提问声音较小，部分问题听不清，导致候选人回答存在猜测性。

岗位方向

• 主要匹配：总线与诊断测试（CAN/LIN、UDS、DBC）、整车功能测试（偏向充电与高压相关）。
• 次要匹配：BMS HIL/台架测试（有故障注入与高压互锁测试经验）、供应商驻场测试。
• 岗位适配判断：候选人更适合偏执行层的总线诊断测试或整车充电功能测试岗位，不适合需要独立设计测试策略、搭建复杂HIL模型或主导测试架构的岗位。

整体结论

候选人具备1-3年左右的总线、诊断及新能源相关测试经验，对UDS诊断服务（10/11/27/28/31/34/36/37/85服务）、刷写流程、DTC读取（19服务）以及DC充电国标流程（GB/T 27930）有基本的操作层理解。能够使用CANoe/CANalyzer进行报文抓取、日志分析和简单CAPL脚本编写，熟悉示波器、万用表等基础工具。回答内容偏向于流程复述和常规操作，能说出“是什么”和“怎么做”，但在“为什么”和“如何独立设计”上表现不足。从“甲方提供用例库，组长分配，我们执行”的表述来看，候选人目前处于测试执行角色，缺乏独立设计测试策略和用例的经验。主要优势在于对诊断和充电流程的熟悉度，以及工具的基本使用能力；主要风险在于技术深度不足、缺乏独立设计能力，且对底层通信原理（如仲裁段与数据段测试）的理解停留在概念层面，无法落地到具体测试方法。整体属于可培养的初级+测试执行人员，建议作为备选或初级岗位推进。

答得好的点

• 对UDS刷写流程的复述较为完整，能按顺序说出10、28、85、31、27、34、36、37、11、14等服务的作用，体现了基本的诊断测试操作经验。
• 对19服务（读取DTC）的子功能有清晰区分，能准确说出19 02 01（当前故障）、19 02 08（历史故障）、19 02 09（当前和历史故障）以及19 04（快照）、19 06（偶发DTC），说明有实际读码和清码经验。
• 对DC充电测试流程能结合国标GB/T 27930，说出物理连接、低压辅助上电、充电参数配置、充电握手等阶段，并列举了单体欠压、绝缘阻值低、高压互锁等故障注入场景，展示了充电功能测试的实操经验。
• 能正确解释CAN仲裁机制（ID越低优先级越高，显性0隐性1），并提到用模拟报文观察仲裁失败或停发的方法，说明对总线基础有一定认知。
• 对Bug提交流程描述具体，提到使用Jira系统，包含截图、日志、视频附件，并指派给对应开发人员，体现了基本的缺陷管理习惯。
• 能说出CANoe/CANalyzer的常用功能，如抓取报文、录制日志（logging）、回放、图形界面（Graphics）和Trace窗口分析，工具使用经验真实。

薄弱风险

• 测试设计能力明显不足：明确表示测试用例由甲方或组长提供，自己主要负责执行，缺乏独立设计测试策略和用例的经验，难以胜任需要从需求分析到用例编写的岗位。
• 技术深度停留在操作层：对UDS刷写失败的排查思路仅停留在“看NRC码”，未深入分析常见失败原因（如安全访问被拒、下载地址无效、内存擦除失败等），缺乏系统性的诊断排查逻辑。
• 底层通信测试理解模糊：当被问及“仲裁段与数据段的区别及如何测试”时，回答仅复述了仲裁机制概念，未能给出具体的测试方法（如使用干扰仪、Bus-off测试、采样点测试等），暴露了物理层与数据链路层测试经验的缺失。
• 工具能力偏向基础应用：虽能使用CANoe，但CAPL脚本能力仅停留在“简单编写”和“修改用例库”，未展示独立开发复杂测试节点或自动化脚本的能力；对DBC文件仅“看得懂会”，未体现独立制作或修改DBC的经验。
• 问题闭环能力存疑：在回答“发现Bug后如何排查”时，首先强调“检查自己操作和环境”，但后续未展示如何通过日志、报文、信号分析定位根因，更多是流程性提交，缺乏深度分析案例。
• 回答存在猜测与不连贯：因面试官部分问题听不清，候选人多次出现“嗯”、“我看一下”、“是是这个吗”等犹豫性表述，且部分回答（如对“数据场与仲裁场区别”的回应）未能准确命中问题核心，沟通与临场应变能力需进一步观察。

面试官考察点

• 验证UDS诊断服务的实际操作经验与协议理解深度（27服务、刷写流程、19服务）。
• 考察DC充电测试的流程熟悉度与故障注入场景覆盖度。
• 试探CAN总线底层原理的理解（仲裁机制、显隐性电平、仲裁段与数据段测试方法）。
• 确认工具链的真实使用程度（CANoe/CANalyzer、示波器、DBC、CAPL）。
• 了解测试角色定位：是独立设计还是纯执行。
• 评估Bug提交与问题闭环的流程规范性。
• 核实项目测试环境（实车 vs 台架）与日志抓取方法。
• 确认候选人当前状态与入职时间。

证据摘录

• “我们平时用u d s刷写的时候，会用到二期这个服务。就是呃它首先它是进入一个那个扩展规划，就是幺零零三。然后呢，进去之后它会就是首先我们用那个二八零幺零幺，然后呃关闭那个与诊断无关的信号。然后然后再是八五零二，就是关闭那个诊断的一些就是信息。然后再用那个三幺三幺四零幺f f f零三，就是那个编程的一个那个。”
• “幺九首先它是读取故障码，首先幺九零二零幺它是当前故障，然后幺九零二零八是历史故障，幺九零二零九是当前和历史故障。嗯。然后还有一个幺九零四的服务，它就是读取快照。嗯，还有一个幺九零六零六的话就是。他的。一般事故方。嗯，偶发的d t c是吧？”
• “d c充电嗯，它首先d c充电的话，它首先有四应该是四个步骤。然后根据需求逻辑来嘛，它首先有一个那个呃上电握手，还有一个那个充电的一个配置，就是参数配置，还有一个那个呃充电的一个。呃，我看一下充电的一个时间配置，然后充电握手后面就是开始充电，然后是不是就是用力的话，是不是符合这个国标来的？就是二七九三零。”
• “测试用例的话随着做，一般是甲方甲方请我们这个或者说是以组长来。然后我们来执行做。哦，就是你们这边只管执行是吧？就具体的策略就是策略策策略说的是是由上方，然后。对，是吧嗯。”
• “我们平时如果说测试当中发现bug了，我们说首先先检查一下自己呃是不是操作失误。如还有环境的一些搭建限速是不是就是有没有接好。如果都没有的话，我们就开始就是确认一下bug。确认bug之后呢，我们就是之前公司是用的是机软系统。然后呢，我们把这个bug就是提交上去。”
• “仲裁段跟数据段一般怎么测？就管谁先发。对呀，他就是管谁先发的呀。然后一个优先等级，根据i d号组建竞争的，然后发送对应的i d报文来来进行的。比如说那种。嗯，显性的一个输出电压呀，或者是呃的数据中开场，或者是显性输入电压。”

评级建议

• 建议评级：C+
• 推荐方向：总线诊断测试执行、整车充电功能测试、台架测试操作员、供应商驻场测试（偏执行）。
• 谨慎方向：测试策略设计、HIL模型搭建、自动化测试框架开发、独立带项目或主导技术方案。
• 面试推进建议：可作为初级测试执行岗位的备选，不建议直接淘汰。若岗位要求独立设计用例或深度排查复杂问题，需谨慎。建议复试中补问测试设计、CAPL脚本能力和复杂问题排查案例，以进一步确认潜力。

可补问问题

• 请举一个你独立编写的CAPL脚本例子，实现了什么功能？代码结构是怎样的？遇到过什么编译或运行问题，如何解决的？
• 在UDS刷写失败时，除了看NRC码，你还会从哪些维度排查？请结合一个实际案例，说明你的完整排查路径和最终根因。
• 如果让你设计一套DC充电的完整测试用例，你会从哪些维度展开？如何覆盖正常流程、异常流程和边界条件？请画出你的用例设计框架。
• 你提到用过示波器，请具体说明在测试中用它测量过什么信号？如何通过波形判断总线通信是否正常？遇到过什么典型的异常波形？
• 在仲裁段与数据段的测试中，如果要求你验证一个节点的仲裁丢失后能否正确重发，你会设计怎样的测试步骤？需要用到哪些工具或仪器？
• 请描述一个你发现的最复杂或最隐蔽的Bug，你是如何从现象一步步定位到根因的？最终推动了怎样的修复或设计变更？