★ FEATURED ARTICLE 1. 这个岗位到底在做什么职责边界与工作全景干汽车测试这些年我被人问过最多的一句话是你们测试工程师是不是就是开车出去兜风顺便踩踩油门刹刹车每次听到这种话我都很无奈但仔细想想也不怪外行因为测试工程师的工作成果本身就是隐性的——你把问题找出来了项目按计划走了这是理所当然你漏掉了一个问题车上市了被用户骂这就是你的锅。说白了这是一个做好了没人夸出了事全背锅的岗位。这行当和互联网软件测试有很大区别。手机App测试挂了发个补丁第二天就能更新汽车不一样一台车从研发到量产动辄三五年控制器软件出了问题轻则召回重则出人命。所以汽车测试工程师手里握着的不仅是测试报告更是一条条关于生命的安全底线。入行第一天老师傅就跟我说过一句话我到现在都记得你要做的不是证明这车能用而是证明这车哪儿不能用。在整车厂或零部件供应商的研发体系里测试工程师的职责边界大致可以这样划分需求分析阶段的测试可行性评审、测试计划制定、测试用例设计与评审、台架测试或实车测试执行、缺陷上报与跟踪、回归测试确认、测试报告输出以及DVPDesign Verification Plan设计验证计划的全程跟踪与交付。听起来好像就是按流程走但真正干起来你会发现每一步都有让人抓狂的细节。1.1 测试工程师的核心职责与产出物测试岗位的日常工作可以压缩成一句话在正确的环境里用正确的方法让被测对象暴露出它的问题并对这些问题进行严谨的记录、定位和追踪。这里的被测对象可能是单一的控制器如BCM车身控制器、一个域控制器如智驾域控、座舱域控、一套子系统如热管理系统、转向系统甚至是一辆完整的整车。每个测试项目的产出物通常包括几大类测试计划与测试方案文档明确测什么、怎么测、用什么测、测到什么程度算通过测试用例集及评审记录这是测试工作的核心资产测试执行记录与原始数据包括日志、截图、CAN报文、视频录像等一切能证明你确实测过的材料缺陷报告也就是俗称的Bug单这里的Bug不只是软件缺陷也包括硬件问题、装配问题、线束问题、用户体验问题测试报告和DVP交付状态标注每一条测试项的通过、失败或阻塞状态。很多新人容易忽视测试用例集和原始数据的价值觉得我把问题报上去不就行了等你遇到那种偶发性问题开发工程师说复现不了你提供数据而你手里啥也没有的时候就知道什么叫叫天天不应了。1.2 七大类测试工作场景从工作场景来分汽车测试大致有七块每个方向的技能树侧重都不一样台架测试Bench Test在实验室里搭台子用电机模拟发动机或轮端负载用程控电源模拟整车的电环境主要做控制器功能验证、耐久测试、极限工况测试。好处是可重复性强、边界条件容易构造、不受天气和场地限制。HILHardware-in-the-Loop硬件在环测试把真实控制器接上实时仿真系统用模型模拟车辆和道路环境主要用在智能驾驶、底盘电控这类对安全要求极高的系统上一些极端工况在实车上根本不敢做HIL里可以随便造。整车道路测试Road Test把车开到试验场或公共道路上验证整车的实际表现涵盖动力性、经济性、制动、操控、NVH噪声振动平顺性、热管理等多个维度。这是最能发现真实问题的环节因为很多问题是台架永远模拟不出来的。三电系统测试针对于新能源车的电池、电机、电控进行专项测试比如电池的充放电性能、热失控试验、电机的扭矩响应、电控的标定策略等。智能驾驶与ADAS测试包括场地测试、道路测试、仿真测试三块涉及传感器的感知性能验证、决策规划逻辑验证、执行机构的响应验证。软件测试与网络测试包括车载总线通信测试CAN、LIN、FlexRay、以太网、诊断协议测试UDS、DoIP、OTA升级测试、车机功能测试与自动化测试。法规与认证测试国标、行标、企标强制要求的安全、环保、电磁兼容等项目像GB/T、ISO 26262功能安全、ECE法规等这类测试不过关车就没法上市。1.3 为什么需要一套工作准则我见过不同类型的测试工程师有的人特别勤奋天天在试验室加班测到半夜但问他今天测了哪些用例、覆盖了哪些需求他说差不多都跑了也有的人特别会写报告PPT做得精美无比但现场一问他某个信号异常时车辆的具体表现他支支吾吾答不上来。这两种人都不合格。汽车测试工程师的工作准则本质上是一套可追溯、可复现、可闭环的行为规范。它不是为了限制你的自由发挥而是确保你手上的任何一个测试动作、任何一条测试结果在三个月后、一年后、甚至车辆量产后被追查时仍然能够完整还原当时的场景和依据。这套准则是我在实际项目里被无数个加班夜和惨痛教训打磨出来的下面我一个一个拆给你看。2. 测试前的准备需求、计划与用例设计很多人觉得测试的价值在执行但以我十年的经验来看测试的价值60%在准备阶段就已经决定了。准备做得好执行就是按图索骥准备做得稀烂执行就是瞎忙活。2.1 需求文档怎么读才不算白读测试工程师拿到SRSSoftware Requirements Specification软件需求规格说明书或功能规范文档后最常见的错误就是通读一遍就开干。实际上读需求文档是有讲究的。我拿到一份需求文档后通常先做三件事第一画需求清单。把文档里所有的功能需求逐条摘出来给每一个功能点编号形成一份需求追踪矩阵RTMRequirements Traceability Matrix。后面设计用例时每一条用例都要能追溯到某一条需求反之每条需求也至少对应一条用例这样测试覆盖率才有据可依。第二找隐含需求。需求文档里写了当车速大于100km/h时系统应发出超速报警这算显性需求但背后至少有三个隐含需求报警的阈值能不能配置车速信号源断了怎么办多次进入超速状态时报警会不会重复触发好的测试工程师的价值就是把别人没写出来的需求也测到。第三对标历史问题。我每接手一个新项目第一件事就是找上一个项目或同平台车型的问题库翻看已知缺陷分布在哪里。比如上一代车型的倒车影像在黑天时噪点大那新项目的摄像头验证就要重点加测低照度场景。这是企业级的经验传承也是避免重复踩坑最有效的办法。2.2 测试计划里必须写清楚的五件事测试计划不是写给领导看的PPT而是给你自己搭的工作框架。我习惯在测试计划里至少把下面五件事写明白测试范围与边界这个阶段测什么、不测什么哪部分由供应商自测哪部分由整车厂测必须先界定清楚。不然做到后面就是扯皮。测试环境与资源用什么台架、什么车型、什么软件版本、什么工具链。写清楚的好处是出问题时可以快速排查是不是环境差异导致的。测试时间节点每一轮测试的开始时间、结束时间、里程碑节点要预留缓冲。现实中计划赶不上变化是常态但没计划的团队一定是一团乱麻。准入准出标准什么条件可以开始测比如软件刷写完成、台架校准合格、无已知阻塞性问题测到什么时候算结束比如严重缺陷全部关闭、剩余缺陷有明确解决方案和计划。没有准出标准的测试就是无底洞。风险评估哪些环节容易延期、哪些测试项可能无法执行、哪些供应商的交付件可能存在风险。提前把风险摆到桌面上比到时候甩锅强一百倍。2.3 测试用例设计的核心方法论用例设计的方法论听着玄乎实际就那几招等价类划分、边界值分析、场景法、判定表法、因果图法、正交实验法。在汽车领域用最多、最好用的就是前三种。等价类划分把输入域划分成若干个子集在每个子集里取一个代表性值就行。比如某控制器的工作电压范围是9V到16V那9V以下、9V到16V之间、16V以上各取一个值就是三个典型的等价类。边界值分析大量的缺陷集中在边界条件上。电压在8.9V、9.0V、15.9V、16.0V、16.1V这几个值附近的行为往往最能暴露问题。这招在标定类测试里尤其管用。场景法从用户实际使用场景出发串联一系列操作步骤。比如用户半夜下班用手机远程开启空调走到车边解锁上车启动车辆此时中控屏应该怎样显示。场景法的最大价值是能覆盖到单个功能点之外的系统联动问题。一条优秀的测试用例至少要包含以下要素用例编号、所属需求编号、前置条件、测试步骤、输入数据、预期结果、优先级、测试类型。预期结果必须写得具体可验证比如仪表报警灯在2秒内点亮就比系统正常报警要合格得多。2.4 测试数据采集方案怎么搭准备工作中最容易被忽略的就是数据采集方案。我见过太多测试兄弟试车试了一天发现车载数据记录仪没开或者存储卡满了一天白干。做数据采集方案时我会在测试开始前确认几个问题采集哪些总线信号CAN、CANFD、LIN、FlexRay还是车载以太网对应的通道配置、波特率、报文格式是否已确认。用什么工具采集Vector的CANoe/CANalyzer是行业标配车上放一台VN1610加一台笔记本是最常见的组合也可以用车载的Datalogger设备通电自动记录。INCA主要用来标定和采集内部变量配合ES581等硬件使用。采样精度够不够总线报文的时间戳精度要小于1ms视频数据要带时间同步否则后期分析时对不上时间轴会很难受。存储空间够不够按8路CAN、500kbps的总线负载来算一小时大概产生1.8GB左右的数据如果还要录视频最好单独用一路视频记录仪存储卡至少128GB起而且要支持循环覆盖。好的数据采集方案核心目标只有一个确保问题发生后你能拿出证据链完整的第一手数据。3. 测试执行中的核心准则环境、动作与记录准备做得再好执行环节才是真正考验一个测试工程师职业素养的地方。有很多测试工程师在这个环节翻车倒不是能力不行而是没有一套刻进骨子里的执行准则。3.1 测试环境确认开始前必做的五个检查台架测试也好实车测试也好开始前花10分钟做环境确认能帮你省下后面几小时的返工时间。第一检查被测对象的软硬件版本。控制器硬件版本号、Bootloader版本号、应用程序软件版本号一个都不能错。我用过一个笨办法但在团队里很有效测试起跑前拍照留存把版本号和实车铭牌一起拍进一张照片里后面整理数据时一翻就有。第二检查测试设备状态。CANoe的连接状态是否正常、通道映射是否和DBC文件一致、电源电压是否稳定、传感器是否校准、VBOX的GPS信号是否锁定。第三检查外围环境条件。实车测试要记录环境温度、湿度、风速、路面状况台架测试要确认实验室空调温度因为控制器在不同温度下的行为是完全不一样的。第四检查测试车辆状态。SOC电量多少、燃油余量多少、仪表是否存在故障灯、轮胎胎压是否正常、是否有DTCDiagnostic Trouble Code诊断故障码未清除。第五确认安全措施。高压测试时是否戴绝缘手套、车辆是否可靠接地、安全员是否到位、逃生通道是否畅通。这一条在整车测试中永远放在第一位。3.2 执行测试时的标准动作测试执行不是照着用例点一遍操作就完事而是在执行过程中保持侦探式的好奇心。我总结的执行标准动作是这样严格按用例步骤操作但也记录脱稿行为。用例是死的车是活的。我在执行过程中如果发现某个看似无关的现象比如按雨刮开关时大灯闪了一下一定会停下来深挖这类现象通常就是新缺陷的线索。边测边记录绝不留到晚上补写。人的记忆是不可靠的尤其是连续测了几十台车之后你根本想不起来这个异响是哪个工况出现的。我现在随身带个小本子和录音笔发现问题马上记哪怕字写得潦草、语音说得口语化都行关键是记录原始事实。每个步骤都要有证据。说仪表故障灯点亮就要有仪表照片说发出报警音就要有录音或视频。口头描述在缺陷处理时是最没说服力的。异常发生后先冻结现场再尝试复现。有些偶发问题稍纵即逝如果发现不对头就马上重启或者继续操作第一现场就丢了。正确做法是异常出现后保持当前操作状态先记录所有屏幕显示、指示灯状态、声音、温度、电压等信息再做后续处理。注意阴影测试思维。就是在正常测试路径之外额外做一些探索性测试。比如在倒车过程中快速挂D挡、在车机开机过程中反复插拔U盘。这种测试很容易被发现不了的缺陷也最能体现一个测试工程师的经验。3.3 数据记录与日志管理比你的记忆可靠一万倍关于日志管理我有几条硬规矩每轮测试建立一个独立文件夹命名格式统一为项目名_车型_测试日期_测试阶段_负责人缩写。不要用最终版改改改这种命名方式。每轮测试的原始数据、截图、视频、日志、DTC快照必须按照用例编号归档。也就是说看到哪个用例编号就应该能瞬间找到对应的所有原始材料。重要的控制器一定要同时抓三份数据总线报文CANoe、控制器内部变量INCA、故障码快照诊断仪。光有CAN报文有时候根本定位不到问题因为问题可能出在控制器内部逻辑上而你看不到内部变量就是瞎猜。数据文件的命名要带时间戳和工况标识比如20240521_103255_急加速超速_v1.2.can这样筛选数据时就不用一个个打开看。不要觉得这些记录工作琐碎没用。我现在做问题分析时最怕的就是拿到的数据不完整、命名混乱。而凡是数据完整、记录规范的测试定位问题效率至少提高一倍。3.4 缺陷管理从发现到闭环的完整链路一个缺陷的生命周期大致是发现 → 上报 → 分派 → 修复 → 验证 → 关闭。看着简单但每个环节都有坑。发现缺陷后我建议先做一次自查这个缺陷能不能稳定复现如果能记录下来复现步骤如果不能记录全部尝试过的触发条件和环境信息并标记为疑似偶发。然后在缺陷单里写清楚缺陷的环境信息整车/台架的VIN号或编号、软硬件版本、测试时间地点、环境温度和湿度复现步骤每一步操作都要详细到按下哪个按钮、持续几秒、看到什么现象预期结果与实际结果对比这是缺陷单的核心明确说明预期应该是什么实际又是什么影响评估不影响功能的轻微问题、影响体验的中等问题、可能导致安全风险的重大问题附件视频、截图、日志文件、CAN数据的路径或链接。缺陷上报后不要以为就完事了。开发改完软件你要做的不是他改了什么我就测什么而是不仅要验证缺陷本身是否修复还要做一遍关联回归。比如开发为了修转向灯报警的问题改了信号处理逻辑那你不仅要测转向灯报警还要测所有用到这个信号的功能比如自动大灯、变道辅助、紧急制动等。4. 问题定位与数据分析从现象到根因的打通如果说测试执行考验的是细心那问题定位考验的就是一个工程师的逻辑推断能力和对工具链的熟练度。这一环节是区分测试员和测试工程师的分水岭。4.1 把现象说清楚是一件很难的事做测试越久我越发现一个残酷的事实90%的沟通混乱都源于现象描述不清楚。我举个例子一个人报缺陷说车辆在行驶过程中有顿挫感——这个描述基本等于没说。顿挫发生在加速还是减速车速在哪个范围油门开度多大发动机转速怎样是不是偶发持续多久有没有故障灯每问一个问题信息熵就减少一点。我的习惯是描述现象时套用四要素框架操作动作、车辆响应、异常表现、持续时间。比如这样写在D挡慢速跟车车速约15km/h时轻踩加速踏板约10%开度车辆出现明显的连续闯动持续约3秒后恢复正常仪表无故障灯共复现2次。这样的描述开发工程师看了以后可以直接锁定排查方向而不是反复打电话和你拉扯。把现象说清楚是对团队时间的尊重也是测试工程师最基本的职业素养。4.2 日志分析CAN报文是你最强的破案工具拿到CAN日志后怎么分析我用的套路是这样的第一步先看整体。用CANalyzer打开日志文件先概览所有报文的总览状态看看有没有异常报文、错误帧、总线负载异常。首先排除总线通信问题因为通信故障很容易被误判为功能故障。第二步从时间维度切片。在问题发生的时间点前后各取30秒到1分钟的数据重点看信号的变化趋势。比如某控制器没有按预期发送某条报文或者某个信号值出现跳变一下子就能看穿问题的大致区域。第三步结合内部变量定位。如果总线数据不足以说明问题连接INCA或同类的ECU标定和测量工具抓取控制器内部变量观察关键状态机的跳转是否正常。打个比方总线报文是你在门外听到的对话内部变量就是对方脑子里的真实想法两者结合才能还原全貌。第四步用CAPL脚本加速分析。如果你的日志有几G大小靠人工翻找信号波形会崩溃。这时候用CAPL写一个小脚本自动扫描设定阈值之外的信号跳变把异常点全部筛选出来。Vector的CANoe里还支持用CANoe.DiVa、CANape等工具做更复杂的分析但核心思路都一样——让工具做重复劳动让人做判断。4.3 从根因分类看问题归属定位问题的过程中我习惯把问题的根因快速归入几个大方向这样就能少走弯路软件逻辑问题功能逻辑与时序的错误、状态机跳转异常、标定参数不合理。多半出现在控制器内部。信号质量问题CAN信号精度不够、信号长度定义错误、物理值换算错误、信号超时未更新、信号跨网段转发延迟。这类问题在车身电子和网关通信中非常常见。硬线电路问题某个引脚虚接、搭铁不良、电源波动、CAN收发器故障。这类问题在实车上尤其难查需要借助示波器和万用表配合排查。机械装配问题零部件安装不到位、线束被挤压或摩擦、结构件干涉。这类问题往往表现为偶发功能异常而且和环境温度、湿度强相关。系统间匹配问题两个控制器之间的握手协议不一致、调用逻辑矛盾单独测A没问题单独测B也没问题联起来就有问题。4.4 写出让开发没法拒绝的问题报告我常说一份好的问题报告应该让开发工程师读完以后,没法不看一眼。这不靠态度强硬而靠信息完整度。问题报告的格式可以参考我的习惯标题用功能模块现象关键词概括例如FCW前碰撞预警功能在雨天高速场景下无报警输出。环境信息软件版本、硬件版本、车型、测试场地、环境温度、时间。复现步骤编号列出每一步都要精确到操作对象和等待时间。实际结果写清楚系统当时的表现。预期结果写明需求/规范里定义的正确表现。影响分析影响哪些功能、是否涉及安全、影响多少用户。附件清单日志文件名、截图编号、视频时间段必须一一对应。这种报告写出来开发打开邮件就知道该怎么入手问题流转速度能快上一倍。我之前带过一个新人一开始写缺陷报告从来只有一句话某某功能不工作被我打回去改了三次就学会了后来他成了团队里报告写得最规范的人。5. 跨部门协作与沟通准则测试工程师在项目里是夹心层——上面有项目经理催进度中间有开发工程师等你提报缺陷下面还有供应商、试制车间、试验场要协调。不会沟通的人在这个岗位上是寸步难行的。5.1 与开发工程师高效协作的三个共识我在团队里一直推动一件事测试和开发不要做甲方乙方而是要建立共同解决一个问题的立场。建立这种关系有三个很实用的原则第一先给数据再给结论。你跟开发说我认为你这个逻辑有bug他会本能地防御你直接把日志和分析截图甩过去说你看这个信号在这个时间点出现了异常跳变是不是状态机的问题他会默认你是来帮忙的。第二尊重开发的时间。不要在对方凌晨刚刷完版的时候连环夺命call除非是影响安全的高危问题。重要且紧急的问题用电话说明常规问题用缺陷单和邮件流转。沟通要有优先级意识这也是一种职业素养。第三主动参与评审。测试工程师别只等着开发给东西测试用例评审、需求变更评审、技术方案评审只要能去就尽量去。提前理解开发的设计意图测起来不仅更有针对性还能提前发现需求中的漏洞这也是提高测试地位的方式。5.2 与项目管理层的博弈测试不是梗概不能无底线压缩这个行业里有个普遍的现象项目周期一紧第一个被压缩的就是测试时间。我在项目会上说过最多的话就是质量不是测出来的但没有充分测试就没有质量。面对项目管理层的时间压力我的应对策略是数据说话。当PM项目经理说测试时间要砍半时我不会只说不行而是把测试项按风险等级列出来用清单回答三个问题砍掉哪些测试项这些测试项对应的风险是什么如果车量产后再发现这些问题维修成本和品牌损失会是多少大多数时候把账算清楚对方自然就不会硬压了。还有一条我始终坚守的底线影响安全类的测试项比如制动系统、转向系统、气囊、高压系统一分钟都不能压缩。人这一辈子总得有些东西是说不就不能变的。5.3 与供应商的对接把标准讲在前面整车厂的测试工程师经常会跟供应商打交道。很多时候供应商提供的零部件或软件已经过他们自测但装到整车上还是会出问题这里面的原因很多供应商的测试环境与整车环境不一致、供应商对系统集成需求理解有偏差、或者供应商的测试覆盖度不足。我的经验是跟供应商合作时要把测试标准讲在前面在SORStatement of Requirements需求说明书阶段就要明确你们在什么环境下测、用什么标准判定通过、交付出哪些测试报告和原始数据。很多质量问题就出在供应商说测了但测的方法跟整车不一致这种情况下。测试工程师要做的就是把这个不一致提前暴露出来这也是DVP评审会存在的价值。6. 常见问题与实战避坑讲了这么多理论和流程最后落地还得靠实操。下面这些坑我在这些年基本都踩过一遍希望后来的人能少走些弯路。6.1 偶发性问题怎么追偶发性问题是最让测试工程师头疼的。我遇到过一个大灯闪烁的问题试了一整天没复现正要放弃了它又来了一次。对付这类问题我的办法是把能记录的东西都打开。当时我在车里装了三路摄像头、一个CAN记录仪、一个语音记录仪虽然大部分时间是垃圾数据但偶发问题出现时你才会庆幸幸好开着记录。每次触发后立刻做环境快照当时的车速、转速、电量、天气、温度、海拔、路面情况全部记录下来。多抓几次后做交叉比对你会发现其中一两个变量和问题的相关性极高。多车同步测试。如果条件允许借三到五辆同一批次的试制车制定相同的测试场景同时跑。偶发问题往往是概率题测试样本越多复现概率越大。千万别在偶发问题出现两次以上后还不上报。哪怕你还没找到规律也要先让开发知道这个问题的存在并提供你手上所有的原始数据。你捂着不说到时候项目量产了问题爆发责任全在你。6.2 台架和实车结果不一致怎么办这种情况太常见了。同一个控制器台架上测了三天全部通过装到试制车上第一天就报故障。我先说结论两个结果不一样的时候优先信实车因为用户最终使用的是实车而不是台架。排查思路是这样先比环境——台架的供电电压质量和实车是不是一致台架的CAN通信总线拓扑和实车是不是一致台架的负载模拟精度够不够再比信号——实车上的传感器信号值是不是和台架上设置的模拟值不一样比如台架上模拟的挡位是靠IO电平直接给的而实车上的挡位信号是经过换挡器ECU处理后CAN发出来的发送延时和信号抖动都会导致行为差异。还有一点经常被忽略实车上的地电位漂移和电磁干扰是台架模拟不出来的。所以遇到台架实车不一致的问题不要急着怀疑某个环节坏了先系统地做一次台架-实车信号对比矩阵把每个关键信号的量值、相位、时序都拉出来对一遍差异一目了然。6.3 怎么判断一个问题是不是真问题测试过程中你会遇到大量看着像问题但又不确定算不算问题的情况。我的判断标准有三个查需求规范规范里有没有定义这种情况定义了就按规范执行没定义就上报让产品经理和系统工程师做裁决。评估安全影响如果这个问题不影响安全那它可以按优先级排期解决如果影响安全就算需求文档里没写也必须按问题上报。站在用户角度看你测试时是工程师视角但用户不是。一个看似正常的行为在用户眼里可能就是异常。典型例子是空调的自动风量切换——工程师知道那是控制策略但用户会觉得空调是不是疯了一会儿大风一会儿小风。凡是影响用户体验的我都建议至少提一个问题单让产品团队决策要不要优化而不是自己判断不是问题就吞掉。6.4 时间不够时怎么守住底线每个项目走到后期都会面临时间不够的情况。这时候我的排序原则是安全项 法规项 核心功能项 体验项 边缘项。时间紧的时候我会在大框架里做减法但减掉的每一项都要有记录、有决策、有签字绝不口头说了算。还有一个实用的技巧善用交叉复用。上一轮测试已经覆盖高的功能下一轮可以适当减量把时间集中在变更点和风险点上。这也是我在测试计划阶段就做好测试矩阵的原因——有了矩阵你随时可以回答这个用例上次是什么时候测的、结果如何、这次还需要重测吗。7. 职业成长路径从执行者到把关人写到最后聊聊这个岗位的成长。很多刚入行的测试工程师都会有困惑天天跑用例、写报告好像谁都能干职业价值在哪里我的回答是如果你只把自己定位成执行测试的人那确实谁都能替代你但如果你能把自己升级成保证产品不出事的人那你就是整个项目里不可替代的角色。7.1 测试工程师的阶段式成长我大致把测试工程师的成长分为三个阶段第一阶段1-3年熟练执行者。能独立完成测试用例的执行、数据采集、缺陷上报熟悉至少一种主流的测试工具链。这个阶段的核心任务是量的积累多跑用例、多接触不同车型的功能把基本功打扎实。第二阶段3-5年方案设计者。能从项目需求出发独立设计测试方案、搭建测试环境、制定测试计划。能判断哪些测试项有优先级、哪些风险需要重点关注能跟开发团队平等对话。这个阶段的核心任务是质的提升要从会测走向懂测。第三阶段5年以上测试架构师/技术专家。能规划整个项目或整个平台的测试战略搭建自动化测试体系沉淀测试方法和工具能力甚至参与功能安全ISO 26262和预期功能安全ISO 21448相关的工作。这个阶段的核心任务已经从做事变成了建立标准、培养人。7.2 建立一套属于自己的工作准则我经常会推荐新人做一件事写一本属于自己的测试工作准则手册。把踩过的坑、总结的经验、反思的教训都记录下来定期整理成文档。这本手册不用给谁看纯粹是给自己用的但它会在你下一次遇到类似问题时直接给你答案或者至少给你一盏灯。我的手册里有一个板块是车感记录专门记每一台测试车的性格。比如某台试制车在低温启动时仪表偶尔会黑屏1秒然后恢复另一台车的转向机在特定转角时有轻微咯登声。这些记录看起来很琐碎但往往在后续问题追查时它们就是那个关键拼图。7.3 做一个不好糊弄的测试工程师最后给所有在这个行业里摸爬滚打的同行一句忠告做测试工程师最重要的是让自己成为一个不好糊弄的人。对需求的模糊之处要追根究底对测试用例的边界条件要锱铢必较对开发说没问题要亲自验证后才敢相信对项目管理层的压缩要有理有据说不。我记得刚入行的时候带我的老师傅在一次测试结束后说了一句让我记到现在的话这车是你测的你签字出了问题你负责。所以你最好确保你签的每一个字都对得起你的专业判断。这句话听起来有一点沉重但它就是汽车测试工程师这份职业的分量——我们的准则最终不只是写在纸上的流程而是刻在每一个测试动作里的本能。
阅读完成 · 觉得有帮助？
