候选人面试分析：OTA-奇瑞智界

来源

转写文件：OTA-奇瑞智界.txt
候选人姓名：转写中无法确认真实姓名；不编造姓名。
备注：转写文本存在较严重的语音识别错误、口语重复和语句断裂，部分技术术语可能识别不准，但不影响对候选人整体能力的判断。对话为两人，面试官与候选人。

岗位方向

主要匹配：诊断测试（UDS）、OTA/远程升级测试。
次要匹配：基础的车身域或零部件测试（基于其提及的过往项目）。
岗位适配判断：候选人更适合诊断测试执行或OTA测试执行岗位，不适合需要独立设计整车OTA测试策略或主导复杂问题攻关的岗位。

整体结论

候选人具备1-2年左右的汽车电子测试经验，以外包身份参与过上汽和长安的项目。其对UDS诊断服务（如10, 11, 14, 19, 22, 27, 28, 31, 34, 36, 37等服务）和NRC码有基础记忆，能说出OTA升级的大致流程和回滚机制（AB分区）。回答整体偏向概念性复述，而非基于个人深度实践的细节阐述。主要优势在于对诊断和OTA有基本认知框架，能快速上手执行类工作。主要风险在于技术深度不足，回答停留在“了解”层面，缺乏独立设计、问题分析和闭环验证的实例，且项目经历碎片化，稳定性存疑。整体看，候选人可作为初级执行岗位的备选，但需通过进一步面试验证其动手能力和问题解决能力。

答得好的点

对UDS诊断服务的列举较为全面，能说出10, 11, 14, 19, 22, 27等服务及其基本功能，展现了基础知识储备。
能正确描述OTA升级的基本流程：从云端任务发布、车端下载、安装、校验、激活到回滚和状态上报。
对OTA升级的前置条件有基本认识，能列举出电源ON档、车辆静止、非充电状态、P档、无车速、电量大于20%等条件。
对OTA回滚机制有概念性理解，能说出AB双分区系统的基本原理：一个区运行旧版本，另一个区安装新版本，失败后回退。
能列举出多个常见的NRC（否定响应码），如0x12（不支持子功能）、0x13（长度错误）、0x22（条件不满足）、0x33（安全访问拒绝）、0x35（密钥无效）等。

薄弱风险

技术深度严重不足：当面试官追问“默认会话下收到31服务会怎么回复”时，候选人回答混乱，未能清晰区分不同会话（默认、扩展、编程）下的服务支持情况，暴露出对会话状态机理解不深。
缺乏独立设计与主导经验：候选人明确表示“我们公司有自研的那些发件软件，我们只需要推进发件”，说明其工作主要是按工具和流程执行，而非设计测试用例或策略。
项目细节模糊，真实性存疑：在回答“升级有多少个ECU”时，仅含糊回答“十多个”，无法给出具体车型、具体ECU数量和名称，缺乏项目代入感。
回答多为概念复述，缺乏个人实践闭环：例如在描述OTA流程和回滚机制时，像是在背诵定义，没有结合自己测试中遇到的失败案例、日志分析或问题定位经历。
职业稳定性风险：自述为外包员工，因“部门没项目派给我”而离职，项目经历碎片化（上汽、长安），可能缺乏在一个平台上深入积累的机会。
工具链能力未体现：整个面试未提及CANoe、CANalyzer、示波器、任何脚本编写（如CAPL）或测试管理工具的使用，无法评估其实际动手能力。

面试官考察点

UDS诊断服务熟练度：通过询问“有哪些服务”和“默认会话下31服务的回复”，验证候选人对诊断协议的理解深度。
NRC码的掌握程度：要求列举常见NRC码，考察其是否具备通过否定响应分析问题的能力。
OTA升级前置条件：验证候选人是否理解实车升级的安全边界和必要条件。
OTA端到端流程理解：从云端到车端再到执行、验证、回滚、上报，考察其对OTA业务全链路的宏观认知。
OTA回滚机制原理：通过AB双分区问题，考察其对OTA核心可靠性设计的理解深度。
项目经验真实性：通过追问具体车型、ECU升级数量、工作模式，验证候选人所述经历是否属实。
岗位意愿与稳定性：通过询问外包经历、薪资和离职原因，评估其求职动机和潜在稳定性风险。

证据摘录

“我们公司有自研的那些发件软件，我们只需要推进发件，但是手动的我也会。”
“如果说那个默认规划是默默认规划说呢？接到编程规划。那如果说上位机一次发送。三十三年后。呃，他们分别是会怎么。他分别会怎么去回复他？对。就你什么是幺零幺幺零零幺幺零零。它这个它的也分它这个正响应和负响应嘛。”
“因为幺零零二必须得先经过幺零零三才能他先然后才能变成，然后才能规划到幺零零二嘛。如果直接发幺零二的话，就会用一个复权。”
“它升级的条件，它有那个车辆自动触发它这个o t a的一个升级版本。然后或者是我这个车主，他通过嗯。呃。哦，这些条件它是。因为我。记错了，刚刚说的还是那个他设计的一些场景，它条件是。电源状态它处于一个o n档嘛，然后它那个车辆在静止状态下呢？”
“它会进行一个a b双分区嘛，就双系统一个区分。他a b a b就就是。嗯，车载那个e c u把把那个储存，他给它分为那个独立的一个分区，一个a区一个b区。a区是当前正在呃进行的一个。嗯。一个一个旧版本嘛，地区它是。因为它是一个。备用的一个社区嘛，专门用来下载的地区，然后就是嗯必须然后用来安装新的一些部件的。”
“我们。因为整车的话。嗯，我们会有。十多个依旧进行它的一个升级。”

评级建议

建议评级：C+
推荐方向：诊断测试执行、OTA测试执行，在明确的测试用例和流程指导下工作。
谨慎方向：OTA测试策略设计、复杂诊断问题攻关、独立带项目。
面试推进建议：不建议直接录用。可作为初级岗位备选，如需推进，必须进行复试，重点补问动手能力和问题分析能力。

可补问问题

请具体描述一个你测试中遇到的OTA升级失败案例。你是如何通过日志或诊断服务定位到是哪个ECU、哪个步骤失败的？最终根因是什么？
你提到用过自研的发件软件，也做过手动。请详细说明手动发送UDS报文时，你用什么工具（如CANoe）？如何建立一个编程会话并完成一次软件刷写？请说出关键的步骤和对应的服务。
在OTA升级过程中，如果升级到一半车辆意外下电了，再次上电后系统会如何表现？你如何设计测试用例来覆盖这种异常场景？
你提到了AB双分区，那么升级成功后，新旧分区是如何切换的？切换的触发条件是什么？如果新版本有问题，回滚是如何触发的，是自动的还是需要诊断指令？
你之前测试的“十多个ECU”升级，是并行升级还是串行升级？升级顺序是如何定义的？如果其中一个ECU升级失败，整个OTA任务会如何处理？
请写出一个你印象最深的NRC码，并说明当时是在什么测试场景下收到的，你据此做了什么判断？