候选人面试分析：同舟科技-德赛西威-总线测试

来源

• 转写文件：同舟科技-德赛西威-总线测试.txt
• 候选人姓名：转写中无法确认真实姓名；不编造姓名。
• 备注：无特别备注。

岗位方向

• 主要匹配：总线测试（CAN/LIN，侧重UDS诊断、刷写、物理层/数据链路层测试）。
• 次要匹配：HIL台架测试、车身域/控制器功能测试。
• 岗位适配判断：更适合按既定用例和流程执行的总线测试执行岗，不适合需要独立设计诊断协议栈测试策略或主导自动化框架搭建的岗位。

整体结论

候选人具备约3年汽车电子测试经验，主要接触过HIL台架搭建与维护、CAN总线报文分析、UDS诊断服务测试及ECU刷写流程验证。从回答看，其工作模式以执行为主：用例设计遵循需求文档和常规方法（等价类、边界值），台架搭建依赖供应商提供主体，CAPL脚本仅做简单修改而非独立开发。候选人对UDS常见服务（10/11/14/19/22/2E/27/31/34/36/37/85）的功能和刷写流程记忆清晰，能流畅复述，显示出较好的记忆力和基础认知。但深入追问诊断需求来源（如诊断调查表）和CAPL开发能力时，回答停留在“了解”层面，缺乏独立设计、问题闭环和自动化落地的项目细节。整体属于“有执行经验但技术深度不足”的类型。主要优势是基础扎实、沟通坦诚、对加班和地点接受度高；主要风险是技术深度有限、缺乏独立设计与自动化开发能力，与岗位要求的以太网、网络管理、Python自动化等存在明显差距。建议作为总线测试执行岗的备选，需在复试中重点补问自动化能力和网络管理基础。

答得好的点

• UDS诊断服务功能记忆清晰：能准确列举10、11、14、19、22、2E、27、31、34、36、37、85等服务及子功能（如190201/190208/190209），并说明其用途，表明有实际使用经验。
• ECU刷写流程描述完整：能按顺序复述从1003进入扩展会话、85关闭DTC、31例程控制、1002进入编程会话、34/36/37数据传输到11复位、14清除故障的完整刷写流程，逻辑正确。
• 测试用例设计方法掌握基础：提到根据需求文档提取测试点，结合等价类、边界值、场景法编写用例，并参与跨部门（开发、产品、测试组内）评审，流程认知清晰。
• HIL台架搭建有基本认知：能说明台架主体由供应商提供，内部负责搭建子功能控制器、上位机连接、备车件及仿真环境，角色定位明确。
• CANoe工具基础使用熟悉：提到使用CDB++制作DBC文件、IG模块模拟发送报文、Trace窗口观测报文、Graphics窗口分析信号，具备日常测试操作能力。
• 沟通坦诚，意愿明确：对离职原因（项目减少、奖金取消）、加班接受度、工作地点（惠州）均直接正面回应，无回避或修饰。

薄弱风险

• 缺乏独立的诊断测试设计经验：当被问及“是否根据UDS需求写测试用例”时，明确回答“没有接触过”，表明其诊断测试工作是基于现有用例或随功能测试顺带执行，而非专门设计。
• 自动化开发能力弱：承认CAPL脚本“接触比较少”，主要是“开发那边给了大体脚本，我们进行内部修改”，无独立编写或框架搭建能力，与岗位要求的CAPL/Python自动化存在差距。
• 诊断需求来源理解停留在表面：虽能说出CDD文件和诊断调查表，但当面试官追问“CDD的制作来源需求是哪里”时，仅能回答“诊断调查表”，未能深入说明OEM诊断规范、ODX/PDX等源头，显示需求分析能力不足。
• 网络管理经验缺失：直接承认网络管理“接触的稍微有点少”，仅提及休眠唤醒，与岗位明确要求的网络管理测试存在明显短板。
• 以太网测试经验未体现：面试官明确岗位涉及以太网相关测试，但候选人全程未提及相关经验或知识，匹配度存疑。
• 项目细节和问题闭环案例缺失：所有回答均为流程性描述或知识复述，未主动提及任何具体项目中的测试难点、发现的Bug、定位过程或改进措施，难以验证真实问题解决能力。

面试官考察点

• 测试用例设计能力与独立性：通过追问用例设计方式、评审参与人员，验证候选人是独立设计还是依赖模板/领导分配。
• HIL台架搭建的参与深度：区分是主导搭建、辅助搭建还是仅使用现成台架，判断动手能力和系统集成理解。
• UDS诊断协议的真实掌握程度：通过列举服务、追问否定响应码、需求来源，区分“用过”和“专门测过/设计过”。
• 诊断需求工程的理解：从CDD文件追问到诊断调查表，考察候选人对诊断开发V流程上游输入的认知。
• CANoe工具链的实操深度：从Trace分析到CAPL脚本开发，验证是仅会基础操作还是具备自动化测试能力。
• ECU刷写流程的完整性：通过让候选人复述刷写步骤，验证其是否真正执行过刷写测试而非仅了解概念。
• 网络管理与物理层测试经验：直接询问以匹配岗位需求，判断技能覆盖度。
• 工作稳定性与团队适配性：通过离职原因、加班接受度、地点意愿、职业规划等问题，评估入职意愿和长期留任可能性。

证据摘录

• “我们一个测试用测试用例就根据我们一个需求嘛，然后比如说里面的一些功能点啊……前期我们比如说开一个就是需求下发下来之后，我们就会跟开发那边进行一个会议嘛……然后我们就结合然后我们就会提取一些测试点呀，然后结合一些等价类，然后边界值，然后场景法这些进行一个测试用例的一个编写嘛。”
• “q台架这边一边一般都是一一个供应商给我们一个提供的啊……我们内部比如说我们需要搭一些呃控制器啊，还有比如说我们一个上位机跟我们一个机位连接嘛，还有一些我们一些备车件嘛，还有一些模拟模拟的一个就是仿真嘛这些。”
• “呃，这个就根据u d s的话，这个是。没有接触过这个。”（针对是否根据UDS需求写测试用例）
• “开口的话我们这边接触的比较少，我们主要是根据开发那边给给了我们一个大体的一个呃一个开口脚本嘛，然后我们进行一些内部的一些修改嘛。”
• “网络管理的话，这这一块就接触的稍微有点少就。嗯，比如说我们一个整个休眠只接触过这些啊，接触的较少一点。”
• “刷写这一块的话，呃，我们公司会有一个自研的操作软件。然后如果说就是比如说我们也会用我们一个u d s去进行一些刷写吗……就比如说我们一个刷写，然后我们先用一个功能寻址的啊发送一个幺零零三进入我们一个。进入一个拓展绘画嘛这些，然后再用我们的一个八五服务啊去关闭一些d d c的一些记录……”
• “之前的话我是在上海，然后因为比如说就是我们公司估计有点缩水了吧，就是接的那个项目确实说实话这两年越来越少了。然后就因为我们公司还是以一个比如说项项目奖金为大头嘛……如果说没有项目的话，就是呃要降薪啊这些。”

评级建议

• 建议评级：C+
• 推荐方向：总线测试执行岗（按既定用例执行UDS诊断、刷写、物理层测试，使用CANoe进行手动报文分析）；供应商驻场测试（在明确流程指导下工作）。
• 谨慎方向：需要独立设计诊断测试策略、开发CAPL/Python自动化脚本、或主导网络管理/以太网测试的岗位。
• 面试推进建议：可作为总线测试执行岗的备选进入复试，但需由技术专家重点补问自动化能力（现场写简单CAPL或Python脚本）、网络管理基础（OSEK/AUTOSAR NM状态机）及以太网基础（SOME/IP、DoIP概念）。若补问结果不理想，建议淘汰。

可补问问题

• 请现场编写一段简单的CAPL脚本，实现周期发送一条CAN报文并在接收到特定报文时触发一个诊断请求（如1001）。
• 请画出AUTOSAR网络管理的状态机简图，并解释Repeat Message状态的作用和进入条件。
• 在以往的测试中，你发现过最隐蔽的总线Bug是什么？你是如何定位并最终确认根因的？
• 如果给你一份全新的OEM诊断规范（如某车企的Diagnostic Specification），你会如何着手设计诊断测试用例？请描述你的思路和步骤。
• 你了解SOME/IP协议吗？如果要在台架上测试一个基于SOME/IP的服务调用，你会关注哪些测试点？
• 请解释一下DoIP（Diagnostics over IP）与CAN诊断在物理层和传输层上的主要区别。