候选人面试分析：大屏功能测试-奇瑞

来源

• 转写文件：大屏功能测试-奇瑞.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：转写文本存在较多口语化重复、卡顿和语音识别错误（如“抗疫”应为“CANoe”，“张报文”应为“抓报文”，“o d b口”应为“OBD口”），但不影响对核心能力的判断。无特别备注。

岗位方向

• 主要匹配：车身域/座舱域功能测试（偏执行）。
• 次要匹配：整车集成测试、诊断测试（UDS刷写流程）。
• 岗位适配判断：更适合按既定用例执行的车身/座舱功能测试岗位，不适合需要独立设计测试策略、深入分析复杂网络或诊断问题的岗位。

整体结论

候选人具备1-3年左右的车身域和座舱域功能测试经验，熟悉车窗、灯光、门锁等常规车身功能的测试点，并对UDS诊断刷写流程有基本的记忆性描述。其工具使用能力停留在基础操作层面，能够使用CANoe进行简单的报文抓取和信号查看，但缺乏对网络拓扑、诊断逻辑和问题分析的深度理解。回答多为记忆性、列举性内容，缺乏项目细节、问题闭环和独立设计测试用例的证据。整体表现出较强的执行属性，更像是在既定用例和指导下完成测试任务。主要优势在于对常规功能测试点有基本认知，且岗位意愿匹配；主要风险在于技术深度不足、缺乏独立分析和设计能力。考虑到岗位为座舱大屏功能测试，其基础能力可覆盖部分执行工作，但需在高级问题上进行补问验证。

答得好的点

• 对车身域常规功能测试点有基本认知，能列举车窗初始化、防夹、行车落锁、雨天自动升窗等测试项，说明有实际执行经验。
• 能够描述使用CANoe抓取报文的基本流程，包括连接OBD口、使用Trace和Graphics面板监控信号、Logging记录数据，证明具备基础工具操作能力。
• 对UDS诊断服务（10, 11, 14, 27, 28, 2E, 22, 19等）和刷写流程（1003扩展会话-85关闭DTC-28禁用通讯-27安全访问-2E写入数据-34/36/37下载-11复位-14清码）有清晰的记忆性复述，说明接触过诊断测试。
• 在面试官介绍岗位内容后，能快速理解座舱测试主要涉及IVI大屏、仪表、后排屏、HUD、DMS/OMS摄像头等部件，表现出良好的沟通和岗位意愿。
• 对日志抓取方式（工程U盘录日志）有提及，说明了解基本的测试数据收集手段。

薄弱风险

• 技术深度不足：当被问及如何确认连接哪个OBD口时，回答仅为“看拓扑图”和“看诊断插口对应表”，未提及网络分段、网关路由、终端电阻等原理，暴露了对整车网络架构理解的欠缺。
• 工具使用停留在表面：描述CANoe抓报文时，仅提到Trace、Graphics面板和Logging，未涉及CAPL编程、过滤条件设置、离线分析、DBC信号解析等进阶应用，工具链能力偏基础。
• 回答缺乏项目细节：所有回答均为通用流程和测试点列举，未结合任何具体项目背景、车型、遇到的问题或解决过程，难以验证经验的真实深度和问题闭环能力。
• 测试设计能力未体现：对于车窗测试，仅列举了功能点，未说明如何设计测试用例、如何构造边界条件、如何判断结果，表现出执行而非设计的思维模式。
• 诊断理解偏记忆性：UDS刷写流程的描述非常流畅，但更像是背诵的标准步骤，未涉及刷写过程中的异常处理、安全访问算法、刷写失败原因分析等实际工程问题，深度存疑。
• 主动分析能力弱：在描述抓取报文后，仅说“简单分析一下看看是哪的问题，然后提交给开发”，未展现独立定位问题、分析信号交互逻辑的能力，更像一个测试执行和问题转发者。
• 薪资期望与能力可能不匹配：当前薪资9K，若期望涨幅较大，其展现的基础执行能力可能难以支撑更高层级的岗位要求。

面试官考察点

• 项目真实性验证：通过询问具体测试内容（车窗怎么测）和工具使用（CANoe怎么抓报文），验证候选人是否真实参与过相关工作。
• 工具熟练度：考察CANoe的实际操作能力，是否仅限于录制回放，还是能进行信号监控和分析。
• 网络诊断理解深度：通过追问OBD口选择依据，考察候选人对整车网络拓扑和诊断路由的理解，区分执行者和思考者。
• 测试设计能力：通过开放性问题（车窗有哪些测试点），观察候选人是仅能罗列功能点，还是能展现系统化的测试设计思路。
• 问题闭环能力：通过询问抓取报文后的处理流程，判断候选人是否具备初步的分析定位能力，还是单纯的数据搬运工。
• 岗位意愿与匹配度：通过介绍座舱测试内容，观察候选人的理解和兴趣，评估其稳定性。
• 基础素质与沟通：通过整体对话流畅度、逻辑性，评估其沟通表达和基本职业素养。

证据摘录

• “我们是用那个工程u盘，就是直接就是录录一下哦，找找到u盘是吧？对，哎，那抗疫这种抓豹纹这种怎么抓呢？……然后在那个o b d口嘛，然后连接上这个对应的d b d b九，然后……在c o e里面，然后用那个呃在那个trace面板，然后就是实时监控它一个数据。还有那个格瑞face面板，我们就是看他一个那个信号嘛，然后就是用那个log再再把录把那个那个数据录下来。”
• “这个是通过那个嗯，我们肯定要呃，首先我们要明白那个top图嘛，看那个top图嘛，看那个top图，看看那里面他走的是哪条线嘛。看那个插口也有一个诊断的诊断的插口也有有有一个那种对应的那个表，然后我们就看那个表。”
• “车窗这一块的话，就主要是测一些那个。车窗的那种初始化呀，还有就是说他这种防夹呀之类的，还有那个就是说行车过程中行车行车自动落锁这些功能。还有锁车自动升窗呀这些，比如说雨天它自动升窗呀这些功能，车窗的防夹啊之类的，还有防玩儿啊之类的。”
• “u d s诊断的话，我们一般用的是那个，比如说幺零规划嘛，幺幺e c u复位，幺四这个清除故障码，那个三e的话是单机握手嘛，还有二七的安全访问，还有二八的通讯控制，二二的一些写入数读取数据，二一的写入数据，还有幺九的读取故障码。”
• “刷写之前呢刷新的一个流程是那个先进入幺零零三嘛扩展规划，然后用然后用那个八五零二那个关闭故障故障码记录，然后发送那个二八零零零幺，然后颈断呃，禁用于那个诊断无关的那些通讯。还有就说进入那个在使用这个二期嘛，进入安全访问……主要的一个刷新流程就是这样啊。”
• “我们座舱这块主要负责的测试的东西就是那个呃那几个屏。比如说i v i大屏啊、附加屏，还有那个包括仪表啊，那个什么后排屏、吸顶屏这些。然后还有包括那几个就是摄像头软件嘛，就比如说d m s摄像头、c m s、o m s呃h u d，还包括e t c。”

评级建议

• 建议评级：C+
• 推荐方向：车身域/座舱域功能测试执行岗位，在有用例库和明确指导的环境下工作；供应商驻场测试（偏执行）。
• 谨慎方向：需要独立设计测试方案、深入分析网络/诊断问题、或涉及HIL台架搭建与自动化测试开发的岗位。
• 面试推进建议：可作为座舱功能测试执行岗位的备选候选人。若推进复试，必须补问座舱大屏的具体交互逻辑测试、复杂场景设计、以及对CAN信号的实际分析案例，以进一步验证其能力边界。若急需能独立上手的高级或系统级测试人员，建议淘汰。

可补问问题

• 你提到用CANoe抓取信号后“简单分析”，能否举一个你实际分析过的座舱或车身问题案例？具体是什么现象，你抓到了哪个关键信号的变化，最终如何定位到问题根因的？
• 针对IVI大屏的测试，比如导航和音乐同时运行并切换时出现卡顿或黑屏，你会设计哪些测试场景来复现和验证这个问题？
• 你提到UDS刷写流程，如果在刷写过程中“34请求下载”服务返回了否定响应（比如0x22条件不正确），你会怎么排查和处理？
• 在座舱测试中，如果遇到一个偶现的、难以复现的仪表显示异常问题，你的排查思路和测试策略是什么？
• 你了解CANoe的CAPL编程吗？有没有用CAPL写过简单的测试脚本或面板，来实现自动化测试或模拟信号？请举例说明。