候选人面试分析：adas-武汉极目智能科技

来源

转写文件：adas-武汉极目智能科技.txt
候选人姓名：转写中无法确认真实姓名；不编造姓名。
备注：转写文本存在较多口语化、重复、语句断裂和可能的语音识别错误（如“科科中学过”可能为“课课中学过”或“可曾写过”，“幺三幺”可能为“UDS”或“131”协议，“type”可能为“台架”等），部分技术细节表达不清。对话为单人面试，但候选人回答较为零散，逻辑连贯性较弱。

岗位方向

主要匹配：车身域/整车功能测试（手工执行方向）。
次要匹配：供应商驻场测试、台架测试（提及但经验极少）。
岗位适配判断：更适合按用例库执行的手工功能测试岗位，不适合需要独立设计测试方案、自动化脚本开发或深入诊断分析的岗位。

整体结论

候选人具备约2年的车身域功能测试经验，主要在外包驻场环境下工作，负责车窗、雨刮、座椅、门锁等功能的测试执行。其工作模式高度依赖已有的用例库和测试组长的任务分配，独立编写用例的经验较少且集中在简单功能点（如雨刮、车窗防夹）。技术深度有限，对自动化测试、诊断协议（如UDS）、台架测试仅停留在概念了解层面，无法展开细节。问题分析能力停留在初步排查（如用翻译工具看信号），缺乏系统性的根因分析逻辑。优势在于熟悉车身域常见功能的测试点和执行流程，能完成大批量用例的执行工作。主要风险是技术栈偏浅、缺乏独立设计和自动化能力、项目细节描述模糊，可能仅为被动执行者。整体适合初级手工测试岗位，不建议作为中高级或需要技术深度的岗位人选。

答得好的点

能描述基本的测试流程：从任务分配、用例评审、执行到bug提交和测试报告输出，流程认知完整。
对车窗防夹功能的测试点有一定理解，提到了力矩阈值、不同刚度物体（橡胶棒、矿泉水瓶）对防夹触发的影响，说明对具体功能逻辑有观察。
能举例说明雨刮自动挡故障的初步排查过程：通过查看信号是否“来回发送”，定位到雨量传感器配件问题，体现了基本的信号查看和问题定位意识。
提及了开关信号做反的案例（左边开关控制右边座椅），说明在实际执行中能发现明显的功能逻辑错误。
对测试用例的构成有基本概念，能区分功能点测试、交互测试和异常测试的占比。
了解大屏压力测试的基本方法，如使用adb命令进行随机点击。

薄弱风险

用例设计能力弱：明确表示“用例其实这个方面的话写的比较少，主要是那个公司里有那个用例库”，仅补充写过雨刮和日常变更的用例，缺乏独立、系统的测试设计经验。
自动化能力缺失：提及“快捷脚本”和“type（台架）私有测试”时，表示“接接接触到的有点少，因为我这边主要做的是一个贴身的（车身？）”，对CAPL、Python等自动化工具链无实际掌握。
技术深度不足：对诊断协议（可能提到的“幺三幺”即UDS）仅表示“没有测过这个这个不是我们那个”，无法展开任何技术细节；对硬件信号的描述停留在“开关的这种信号”、“电机的一个控制这种信号”，非常笼统。
问题分析逻辑不系统：在雨刮案例中，排查逻辑是“分析它是不是电路，应该是没有问题”然后“涉及到这个流量传感器”，最后提交开发，缺乏标准化的排查步骤（如从传感器、线束、控制器信号逐层分析）和独立定位能力。
项目细节模糊：当被问及3000多条用例的具体构成时，回答“功能点的占比大概是八百分之八十左右。交付的大概就百分之十吧”，数据前后矛盾（80%+10%≠100%），且对“长期稳定性测试”如何执行，回答为“有那个快捷脚本，然后内存那个内存上面”，表述不清，无法确认其真实性。
工作模式被动：整个对话中反复出现“测试组长分配任务”、“公司里有用例库”、“提交给开发”等表述，显示出强执行属性，缺乏主动优化或主导测试策略的案例。
沟通与逻辑表达较弱：转写中大量语句断裂、重复，对技术问题的描述不够清晰，可能影响团队协作中的信息传递效率。

面试官考察点

测试流程规范性：验证候选人是否了解从需求到报告的完整测试流程。
用例设计能力：通过询问“你写的用例”和用例数量构成，判断其是独立设计还是仅执行。
功能逻辑理解深度：以车窗防夹、雨刮自动挡为例，考察对被测对象工作原理和测试要点的理解。
自动化与工具链掌握：询问“快捷脚本”、“type（台架）”、“adb命令”，验证其是否具备自动化测试或台架测试能力。
问题分析与排查能力：通过雨刮故障案例，考察其问题定位的逻辑、方法和工具使用（如查看信号）。
项目经验真实性：通过追问用例数量、项目人数、车型数量、每日执行量等细节，交叉验证项目经验的真实性。
工作模式与主动性：通过了解任务分配方式、用例来源，判断候选人是主导者还是被动执行者。
岗位意愿与稳定性：询问外包性质、合同期限，侧面了解候选人的职业稳定性和对岗位的期望。

证据摘录

“用例其实这个方面的话写的比较少，主要是那个公司里有那个用例库，大部分都是用力库提取的，就是偶尔一些嗯就是。不全的，我们会编写一些，就是科科中学过一些雨雨刮雨刮方面的。”
“那个就是type据我了解啊，就是那个type就是那个台架上的一些那种私有测试。但是我这方面的话是接接接触到的有点少，因为我这边主要做的是一个贴身的。”
“当时雨刮自动挡一调到那个雨刮一调到那个自动挡，它就是。一直来回的动，一直来回左右的改动，然后就是就嗯就是分析他这个问题嘛，然后他是在正常情况下手动手动。送送多了，他说送了就送，然后他就就分析它是不是电路，应该是没有问题。但是自动挡那些关键的部件是比如涉及到这个流量传感器是吧？然后这边这方面提交给开发。”
“就比如用到翻译，看看它那个，因为一旦它就会发送信号嘛，然后用翻译软件就是查看这个信号是不是来回的，就是发送嘛。然后他确实是在来回的发现。”
“一天的话大概是四十左右吧。一天四十个吗？哦，对对，那对，那个总共总共因为这个他那个基本上都比较少的。一共四十多。”
“我们那边是分组的，大概是。呃，十多个吧。手术的人就专门去了这个附近医院吗？嗯。那就是这个。嗯嗯，因为他有好几个车型在同时在做嘛。”

评级建议

建议评级：C+
推荐方向：车身域/整车功能手工测试执行岗位，严格遵循已有用例库进行测试，适合外包驻场或项目周期短、需求明确的执行类工作。
谨慎方向：BMS、ADAS、OBC/DCDC等需要强技术背景的领域；任何需要独立设计测试方案、搭建自动化测试框架、深入诊断分析或主导测试策略的岗位。
面试推进建议：不建议作为中高级岗位复试人选。若团队急需初级手工测试执行人员，可作为备选，但需在复试中重点补问其独立工作能力和学习潜力。目前信息下，直接淘汰风险较低，但价值有限。

可补问问题

请详细描述一个你从零开始独立编写测试用例的功能，包括你是如何分析需求、识别测试点、设计用例步骤和预期结果的？不要用雨刮或车窗的例子。
你提到用“翻译软件”查看信号，具体是什么工具？是CANoe、周立功还是其他？你如何配置和过滤报文来定位问题？
在雨刮自动挡故障中，你如何排除是开关、线束还是控制器的问题？请画出简单的信号流并说明你的排查顺序。
你提到“快捷脚本”做反复操作，这个脚本是你写的还是别人提供的？用什么语言写的？能否现场写一个简单的循环操作逻辑？
如果让你负责一个全新车型车门模块的测试，没有现成用例库，你会如何规划测试范围、设计测试用例并安排测试执行？
你对UDS诊断协议了解多少？比如10、22、2E、19服务，有没有在实际工作中用过或见过？