候选人面试分析：底盘测试-上汽-上海翼锐

来源

• 转写文件：底盘测试-上汽-上海翼锐.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：无特别备注。

岗位方向

• 主要匹配：底盘功能测试、整车功能测试。
• 次要匹配：诊断测试、基础自动化测试（CAPL）。
• 岗位适配判断：更适合执行层面的底盘或整车功能测试岗位，不适合需要独立设计测试架构、主导自动化测试框架开发或深度诊断开发的岗位。

整体结论

候选人具备1-3年左右的汽车电子测试经验，以外派或驻场形式在主机厂工作。其核心能力集中在诊断服务（UDS）的基础指令流程和底盘功能的测试用例执行上，对刷写流程、故障码读取等有较清晰的记忆。回答以复述流程和用例为主，表现出良好的执行力和记忆力。

主要优势在于对诊断基础指令（10, 27, 31, 36, 37等）和自动驻车（Auto Hold）功能的测试逻辑有可落地的理解，且具备驾照和实车驾驶经验，对实车测试环境熟悉。主要风险在于技术深度不足，工具链（CAPL）掌握停留在“修改”和“使用”层面，缺乏独立开发能力；测试用例设计多为“补充”而非主导，且问题闭环管理描述较为基础。整体看，候选人是一名合格的初级至中级测试执行人员，可快速上手已有用例的测试任务，但暂不具备独立承担复杂系统测试设计或自动化开发的能力。

答得好的点

• 诊断指令流程清晰：能完整、流畅地复述ECU刷写流程，从会话切换（10服务）、安全访问（27服务）到编程会话（31服务）、数据传输（36服务）和校验（37服务），指令顺序和响应码（如50 02, 67 02, 71 01）描述准确，表明其具备真实的诊断测试执行经验。
• 功能测试逻辑完整：以自动驻车（Auto Hold）功能为例，清晰地描述了测试用例的关键要素，包括前置条件（ESC无失效、车门关闭、安全带系好）、测试步骤（大屏开启功能、踩刹车）和预期结果（仪表指示灯状态变化），体现了对功能测试流程的理解。
• 工具使用经验真实：提及使用“极软件”（应为Jira）进行问题管理，并能描述bug提交的基本要素（概述、测试ID、等级、经办人、附件、预期/实际结果），符合常规测试工作流。
• 驾驶经验匹配岗位：明确表示有三年以上驾照，驾驶技术熟练，能应对乡村、高速等多种路况，这对需要执行实车动态测试的底盘岗位是直接加分项。
• 工作意愿明确：对工作地点（上海）和驻场模式（外派至上汽）接受度高，且能在一周内到岗，入职意愿较强。

薄弱风险

• CAPL能力仅限修改，非独立开发：当被问及CAPL脚本案例时，候选人先表示“开头用的比较少，我基本上都是他们给我的”，后虽描述了一个简单的报文发送脚本结构，但整体回答偏向基础语法复述，缺乏解决具体测试问题的项目细节，表明其不具备独立编写复杂测试脚本的能力。
• 测试用例设计能力为“补充”级别：在追问测试用例来源时，候选人承认“有用力库的”、“给的给的自己，有时候我也会写一个”、“就是补充一点”。这表明其工作模式高度依赖甲方或领导的用例库，缺乏从需求文档独立设计和构建完整测试用例的经验。
• 问题闭环管理描述基础：对bug管理流程的描述停留在“记录、截屏、提交”的操作层面，未提及bug的根因分析、与开发人员的交互、回归测试等闭环环节，显示出其在问题深度处理上的经验有限。
• 技术广度有限，回答被动：面试全程均为面试官主动提问，候选人被动回答。当被问及除19服务外的其他诊断服务（如14, 22, 23, 31）时，回答简略，仅能说出服务名称，未能展开其应用场景或测试细节，知识体系不够系统。
• 项目细节缺失：在描述CAPL脚本和功能测试时，未能结合具体的项目背景、遇到的挑战或解决的问题，回答偏向教科书式或通用流程，难以验证其解决复杂问题的能力。

面试官考察点

• 诊断协议基础：通过询问19, 14, 22, 23, 31等服务，验证候选人对UDS协议的掌握广度和深度。
• 诊断流程实操：要求完整讲述一个刷写流程，考察其对诊断指令的实际应用能力和执行细节的准确性。
• 自动化测试能力：通过询问CAPL脚本编写案例，判断其是具备独立开发能力还是仅能执行/修改现有脚本。
• 功能测试设计能力：通过追问测试用例来源和具体功能（Auto Hold）的用例设计，区分候选人是测试设计者还是单纯的执行者。
• 问题管理流程：询问bug管理工具和流程，评估其测试素养和问题闭环意识。
• 岗位匹配度与意愿：确认驾照、驾驶经验、工作地点接受度和到岗时间，评估其与实车测试岗位的匹配度和稳定性。
• 工作模式与经验：通过了解上家公司的性质（三方测试/外派），判断其过往的工作模式和自主性。

证据摘录

• “刷写流程就是先建立那个诊断连接嘛，就是幺零嘛，然后进入呃呃幺零零那个幺零零二幺零先进入幺零零一嘛默认，然后再用幺零三扩展，然后进幺零零二编程，然后会一直会响应个五零零二对吧？然后然后解开那个安全访问锁，然后就打开二七服务，然后就二七零幺请求密钥，然后把那个请求那个总值值嘛，把那个总值值计算出来，把密钥发给那个二七零二。”
• “开头用的比较少，我基本上都是他们给我的。”
• “测试用例可以自己写。……我们也会写一部分，就是有用力库的。……给的给的自己，有时候我也会写一个。……就是补充一点。”
• “假如底盘的吧，底盘的那个old hold自动驻车这个功能激活退出吧。……前面条件的话就是三模式，然后那个e p p释放状态，然后p档或者n档，然后那个呃e s c就是那个车手的系统功能呃无失效，然后通讯正常。然后第四个条件的话就是那个车门关闭，然后呃驾驶测安全带。”
• “今晚就是用的极软件。……假如说遇到bug呃，判断不是自己误触的话，是根据那个测试用例上来的。然后我们会那个呃记录一下这个或者截屏，然后或者是录制那个logo，还有那个录屏。”
• “驾照三年以上的开车技术还可以是吧？呃，可以的。乡村高速还有那个民营路况都有都有都有过，没问题。”

评级建议

• 建议评级：C+
• 推荐方向：在有用例库和明确需求指导下的底盘或整车功能测试执行岗位；诊断测试执行岗位。
• 谨慎方向：需要独立设计测试方案、编写自动化测试脚本（CAPL/Python）或主导复杂问题攻关的岗位。
• 面试推进建议：可作为初级/中级测试执行岗位的备选候选人。若岗位急招且对独立设计能力要求不高，可考虑推进复试或直接录用。建议在录用前，通过实际的上机测试或更深入的用例设计问题，进一步验证其CAPL修改能力和测试设计潜力。

可补问问题

• 你提到CAPL脚本“基本上都是他们给我的”，请举一个你最近修改过的脚本例子，说明你修改了哪部分逻辑，是为了解决一个什么样的测试问题？
• 在Auto Hold功能测试中，如果遇到一个偶发性的“功能激活失败”问题，且无明确故障码，你会如何设计测试步骤来复现和定位问题？
• 除了Jira，你使用过CANoe或类似工具进行过日志分析和问题定位吗？请举一个具体的例子。
• 你提到会“补充”一些测试用例，请分享一个你完全从0到1编写的、最复杂的测试用例，并说明你是如何从需求文档中提取测试点的？
• 在刷写流程中，如果ECU在安全访问（27服务）阶段反复返回否定响应码（如35），你会如何排查是密钥计算错误、权限问题还是其他原因？