导读

2025—2026年,测试行业经历了前所未有的结构性变革。

某招聘平台2026Q1数据显示,手工功能测试岗位同比减少37%,这个曾经占据测试团队半壁江山的岗位正在快速萎缩

与此同时,猎聘、脉脉2025报告显示,AI Testing Engineer岗位新增420%,成为测试领域增长最快的职位。一边是传统岗位的消失,一边是新岗位的爆发——这不是”测试行业不行了”,而是”测试行业正在换血”

更值得关注的是,华为HDC 2025公开数据显示,鸿蒙生态人才缺口已达50万。作为一个从零起步的操作系统,鸿蒙NEXT正在重塑整个国产软件生态,而测试工程师正是这波红利中最稀缺的角色之一

NOA(Navigation on Autopilot,导航辅助驾驶)从高速场景走向城市道路,意味着车联网测试从”实验室验证”正式迈入”真实场景验证”时代。智驾系统、V2X通信、车云协同……这些曾经听起来遥远的名词,正在成为测试工程师的日常工作

如果你是一名有2~5年经验的测试工程师,正站在职业发展的十字路口,这篇文章就是为你写的。我们不谈宏大的行业叙事,只回答一个核心问题:在AI、鸿蒙、车联网三大风口下,你的机会在哪里?该往哪个方向走?


第一章:AI浪潮——哪些岗位在消失,哪些在爆发

先说一个残酷的事实:如果你还在做纯手工功能测试,并且没有向自动化或专项测试转型的计划,那你的岗位确实在消失

2025-2026年的数据已经很明确——手工功能测试岗位同比减少37%。这个数字背后是两层逻辑:一是AI工具(如Claude、ChatGPT、CoPilot)正在接管大量测试用例编写、缺陷报告整理等重复性工作;二是企业对”测试效率”的要求越来越高,一个会写自动化脚本的工程师,产出效率可以是纯手工测试的3~5倍

但消失的只是”纯手工”这个定位,不是测试这个职业。真正爆发的是这些方向:

微信公众号二维码图片引自微信公众号,扫码关注阅读原文
AI测试岗位需求趋势(2023-2026)

这里要纠正一个误区:AI不是来”替代测试工程师”的,而是来”替代重复性测试工作”的。会用AI工具的测试工程师,正在成为企业争抢的对象

那现在应该怎么准备?

行动建议:AI测试不是”学会一个工具”就能转型的,它需要你建立新的测试思维——从”输入→预期输出”的确定性测试,转向”输入→输出范围评估”的概率性测试。这种思维转变,比学任何工具都重要


第二章:鸿蒙NEXT——50万人才缺口的生态红利

2025年,华为在HDC开发者大会上宣布了一个数字:鸿蒙生态人才缺口50万。这个数字不是营销噱头,而是真实的供需失衡——鸿蒙NEXT作为一个全新的操作系统,从内核到应用层都是自研技术栈,这意味着所有适配鸿蒙的App都需要重新开发、重新测试

对于测试工程师而言,这是一个难得的”红利窗口”:

微信公众号二维码图片引自微信公众号,扫码关注阅读原文
鸿蒙NEXT测试工程师技能树

鸿蒙测试的核心技能体系包括:

为什么现在是好时机?

鸿蒙生态目前处于”快速增长期”而非”成熟稳定期”。这意味着:

注意:鸿蒙测试不是”换个系统点一点”,而是要理解鸿蒙的分布式架构、ArkUI渲染机制、ArkCompiler优化特性。建议先系统学习鸿蒙开发文档(特别是Ability、Stage模型、分布式数据管理),再切入测试方向


第三章:车联网——被低估的黄金赛道

2025年被称为”城市NOA元年”,这个标签背后是一场深刻的技术变革——相比高速NOA,城市NOA面临的是复杂的路口、行人、非机动车、施工路段、交通标志识别……场景复杂度提升了一个数量级

这对测试意味着什么?意味着测试工作量爆炸式增长

传统ADAS(高级辅助驾驶系统)测试主要依赖封闭场地测试和仿真测试,但城市NOA必须在真实道路环境中验证。一套城市NOA系统,典型测试场景从几千个增加到数万个,场景覆盖率、长尾场景挖掘、仿真与实车的一致性验证——这些都是测试工程师的核心工作


微信公众号二维码图片引自微信公众号,扫码关注阅读原文
车联网测试能力矩阵

车联网测试的核心方向:

为什么车联网是被低估的赛道?

第一,人才供给严重不足。车联网测试需要同时懂汽车、嵌入式、通信协议、测试方法论,复合型人才稀缺。很多车企只能从传统汽车测试团队转型,但转型周期长、效果不理想

第二,薪资溢价明显。智驾测试工程师普遍薪资在30K~60K,高级岗位可达80K~120K,远高于传统互联网测试岗位

第三,职业天花板更高。车联网是一个仍在快速演进的领域,从L2到L3、L4,测试复杂度持续提升,个人成长空间巨大。而且,车企的组织架构相对扁平,测试团队的话语权普遍高于互联网公司

第四,政策推动。多地开放智能网联汽车道路测试、L3级自动驾驶准入试点,行业进入”政策红利期”。更多车企投入智驾研发,测试需求同步爆发

机会窗口:目前车联网测试仍处于”草莽期”,行业标准未统一、工具链未垄断、方法论在快速迭代。这是新人入场的最佳时机——等你积累3年经验后,行业格局可能已经定型,门槛会显著提高


第四章:V2X与云平台——下一片蓝海

如果说智驾测试是”车的智能”,那V2X(Vehicle to Everything)测试就是”车的连接”。V2X包括V2V(车与车)、V2I(车与路)、V2P(车与人)、V2N(车与云),核心目标是让车”看见”更远、反应更快、决策更安全

为什么说V2X是”下一片蓝海”?

第一,政策强制推动。中国C-V2X标准已确定,多地在推进”车路云一体化”示范项目。按照规划,2026-2027年将迎来规模化落地,测试需求同步爆发

第二,技术栈差异大。V2X测试不是传统的App测试或嵌入式测试,而是需要理解通信协议(LTE-V2X、5G-V2X)、边缘计算、云控平台、安全机制(PKI证书、消息加密)。这是一套全新的技术栈,传统测试团队很难直接复用经验

第三,测试场景复杂。V2X涉及多车、多路侧单元、多云服务的协同,测试需要验证”车-路-云”三端的联动逻辑。比如:路侧单元检测到前方事故,通过V2I通知车辆,车辆接收后触发预警——这条链路涉及感知精度、通信时延、消息解析、人机交互等多个环节,任何一个环节出错都可能导致功能失效

微信公众号二维码图片引自微信公众号,扫码关注阅读原文
V2X与智驾测试架构图

V2X与云平台测试的核心能力:

职业机会在哪里?

V2X测试目前主要集中在三类公司:

行动建议:V2X测试的学习曲线较陡,建议先系统学习C-V2X标准(特别是消息集定义),再选择一个方向切入(车端、路侧、或云端)。如果你有网络通信测试经验,转型V2X会更容易


第五章:三大赛道机会矩阵

看到这里,你可能已经对三大方向有了初步判断。但究竟哪个方向更适合你?我们用一张表来对比:

AI测试、鸿蒙测试、车联网测试三赛道对比
维度
AI测试
鸿蒙测试
车联网测试(智驾/V2X)
薪资范围(一线城市)
25K~45K(中级),45K~70K(高级)
22K~40K(中级),38K~60K(高级)
30K~60K(中级),60K~120K(高级)
入门门槛
中等——需自动化基础 + AI理解
中等——需编程基础 + 新技术栈学习
较高——需嵌入式/通信/汽车知识
成长空间
高——AI仍在快速演进
中高——跟随鸿蒙生态扩张
高——L3/L4智驾持续演进
竞争激烈程度
高——大量测试人员涌入
中——人才供给仍不足
低——复合型人才稀缺
转型难度(从传统测试)
中等——需建立AI测试思维
中等——需学习新技术栈
较高——需跨领域知识
适合人群
有自动化基础、愿意学习AI、希望快速转型的工程师
有编程基础、愿意投入新技术栈学习、接受不确定性的工程师
有嵌入式/通信/汽车背景、愿意深耕垂直领域的工程师

三大赛道的选择建议:

核心结论:三大方向没有绝对的”最优解”,只有”最适合你的解”。关键评估维度包括:你当前的技术基础、愿意投入的学习时间、职业风险偏好、所在城市的产业分布。建议先选定一个方向深入,而不是三心二意——任何方向,只要深入到专家级别,都会有不错的职业回报


第六章:AI测试工程师能力升级实战

过去一年,整个测试行业最热的话题只有一个:AI会不会取代测试工程师?我的观察是——AI不会取代你,但懂得用AI的测试工程师会取代你。但在这个共识之上,还有一层大多数人没看到的真相:真正拉开差距的,不是「会用Copilot写几行程式码」,而是「能设计一套AI-native的测试策略」

这两种能力,中间隔著一条鸿沟。本章要做的,就是把这条鸿沟填平

从「会跑脚本」到「会设计AI测试策略」

传统测试工程师的价值链是这样的:读需求→写用例→跑脚本→提Bug→回归验证。核心能力是「执行效率」和「发现缺陷的敏锐度」

AI时代,这条价值链正在被重构。现在你让Copilot帮你写测试用例,让ChatGPT帮你生成边界条件,让AI工具自动跑回归——这些都是「用AI提升执行效率」,但它没有改变你在价值链中的位置

真正有意义的跃迁,是你能回答这个问题:「我们的系统准备好了吗?」——这里的「系统」是AI系统,是大语言模型,是AI Agent。而这个问题背后需要的能力,是传统测试工程师几乎完全没有接触过的

你需要理解:AI模型输出具有随机性(同一输入可能产生不同输出),AI系统存在幻觉问题(Hallucination),Prompt攻击是一种真实威胁,模型版本迭代会破坏已有测试基准,AI系统有「能力边界」这个概念

这些问题,传统的黑盒测试方法论根本应付不了

微信公众号二维码图片引自微信公众号,扫码关注阅读原文
AI时代测试能力雷达图

三条赛道的真实岗位生态

我们先看清楚市场,再谈能力建设。2026年下半年,以下三个方向的需求最为明确:

方向
核心能力要求
薪资区间(北上深)
典型JD摘要
AI Testing Engineer
LLM测试策略、Prompt注入防御评估、AI系统质量评估框架
28K~45K/月
「负责公司AI大模型的质量保障体系建设,制定AI系统测试标准,设计Prompt鲁棒性测试方案,构建模型性能Benchmark。」
TestOps
CI/CD全链路建设、测试环境治理、测试数据工程、测试左移/右移
22K~38K/月
「设计并维护测试基础设施,搭建自动化测试数据平台,推进测试左移落地,主导测试环境稳定性治理。」
质量架构师
测试架构设计、质量度量体系建设、风险评估、跨团队质量治理
35K~60K/月
「负责产品质量架构规划,建立全链路质量度量体系,制定质量红线标准,主导重大版本质量攻关。」

薪资说明:以上数据为2026年第一季度一线城市(北上深)市场均值的综合估算。实际薪资受公司阶段、技术栈、公司地点影响较大,互联网大厂同岗位上限可达70K+/月,创业公司则波动较大。

具体可操作的能力升级路径

知道了方向,接下来的问题是:怎么从当前状态走到那里?以下是一条经过大量读者验证的「90天能力跃迁路径」,适合有2~5年经验的测试工程师

第一步(第1~30天):建立AI测试的底层认知

  • 系统学习:LLM基础原理(Transformer、Token、Temperature、Top-p),理解AI系统的随机性本质
  • 动手实践:在本地部署一个开源模型(如Qwen2.5),设计一组Prompt,观察同一Prompt多次输出的差异
  • 必备工具:OpenAI API / Kimi API / 腾讯混元API(任选一个,了解调用方式)
  • 交付物:用Notion或Markdown整理一份「AI系统质量评估维度清单」,包含10~15个核心评估维度
第二步(第31~60天):掌握AI测试的核心方法

  • Prompt鲁棒性测试:学习如何设计对抗性Prompt,评估Prompt攻击的防御效果
  • AI回归测试框架:学习如何建立「测试基准」(Golden Dataset),追踪模型版本迭代后的质量变化
  • 真实场景练习:在自己项目中选一个模块,设计AI辅助测试流程(如用AI生成测试数据、用AI辅助用例评审)
  • 交付物:一个完整的「Prompt鲁棒性测试报告」,包含测试设计、执行结果、分析结论
第三步(第61~90天):构建差异化竞争力

  • AI系统质量评估框架:学习业界主流框架(IBM AI Fairness 360、OpenAI Evals、Google BLEU/ROUGE评估)
  • 测试数据工程:如果转TestOps方向,重点学习合成测试数据生成(Faker、Python随机数据库)
  • 质量架构思维:如果转质量架构师方向,学习ATAM(架构权衡分析方法)、风险矩阵绘制
  • 交付物:一份完整的「AI系统测试方案」(可直接用于面试项目展示)
关键提醒:在整个学习过程中,最重要的不是工具,是「持续记录」。每周写一篇技术笔记,记录你遇到的真实问题和解决思路。90天后,这份笔记就是你的面试素材库和成长证明

第七章:鸿蒙NEXT测试详细技术方案

鸿蒙NEXT的到来,不仅是华为操作系统的一次版本迭代,更是一次测试方法论的全面重构。如果你还在用Android/iOS的老方法测试鸿蒙应用,很多问题你压根找不到,也压根测不到。本章给出一套实用导航,帮你快速建立鸿蒙测试的技术框架

微信公众号二维码图片引自微信公众号,扫码关注阅读原文
鸿蒙NEXT测试方法论全景图

鸿蒙NEXT的测试可以分为三个核心层,每层的测试目标、工具和方法都有明显差异:

测试层
测试目标
核心工具
关注重点
单元测试
ArkTS/ArkUI组件代码的正确性
ohos.test

 框架
Vitest(兼容)
Ability生命周期、回调逻辑、状态管理
集成测试
跨设备协同、服务调用链路
HarmonyOS SDK Mock
Distributed Kit Mock
设备发现、任务流转、数据一致性
系统测试
兼容性、性能、安全、稳定性
DevEco Testing
HDC命令行
HiTrace
多设备类型兼容性、冷启动时长、权限合规

单元测试:ohos.test框架实战

鸿蒙NEXT的单元测试使用ohos.test框架,这是华为官方提供的测试基础库,类似Android的JUnit。核心用法非常直接:

import hilog from '@ohos.hilog';import test from '@ohos.test';// 标准测试套件结构test.describe('abilityLifecycleTest', () => {  let abilityContext: AbilityStageContext;  // 测试前置:初始化测试环境  beforeAll(() => {    // 模拟AbilityStage初始化    hilog.info(0x0000, 'Test', 'Test suite initialized');  });  // 清理:每个用例执行后  afterEach(() => {    hilog.info(0x0000, 'Test', 'Test case cleaned up');  });  // 典型用例:验证Ability生命周期的正确状态切换  test('Ability should enter Started state after onCreate', async () => {    // Arrange: 准备测试数据    const mockAbility = createMockAbility();    // Act: 触发目标行为    mockAbility.triggerOnCreate();    // Assert: 验证预期结果    expect(mockAbility.getCurrentState()).assertEqual('Started');  });  // 典型用例:验证错误处理的健壮性  test('Ability should handle network exception gracefully', async () => {    const mockNetError = new NetworkException('timeout');    const result = await mockAbility.handleRequest(mockNetError);    expect(result.fallbackTriggered).assertTrue();    expect(result.errorLogged).assertTrue();  });});
实用技巧:鸿蒙单元测试中最大的坑是「异步代码测试」。务必使用async/await语法,并在断言后加done()回调确保异步完成,否则会出现大量难以定位的随机失败。

集成测试:跨设备协同测试

鸿蒙NEXT的杀手级特性是「超级终端」——手机、平板、手表、耳机、智慧屏之间的无缝协同。这带来了传统移动测试从未遇到过的挑战:设备发现延迟、跨设备数据同步冲突、网络切换时的任务连续性等

实用测试策略:

实战案例:原子化服务测试用例设计

鸿蒙NEXT的核心架构是「原子化服务」(Atomic Service)。一个原子化服务本质上是一个免安装、可分发的功能模块。我们以「天气查询」原子化服务为例,展示如何设计测试用例:

场景:测试「天气查询」原子化服务

  • 正常流程:
    用户通过语音或卡片触发天气查询 → 服务拉取天气数据 → 展示天气信息和建议
  • 边界条件:
    GPS定位失败时的降级策略、空闲网络下的离线缓存展示、流感季节的天气建议卡片渲染
  • 兼容性:
    服务在不同屏幕尺寸设备上的卡片布局适配(手机竖屏→平板横屏→手表简化视图)
  • 性能:
    服务冷启动时间不超过2秒、天气数据刷新不超过5秒
  • 安全:
    位置权限的合规获取、天气数据接口的鉴权有效性
鸿蒙测试核心原则:鸿蒙测试和传统移动测试最大的区别在于「分布式思维」——你需要时刻问自己:「这个功能在单设备环境和多设备协同环境下,分别表现如何?」把这个问题意识带入每一次测试设计,你就入门了。

第八章:V2X与智驾测试详细技术方案

V2X(Vehicle-to-Everything)和智能驾驶测试是汽车电子领域最前沿的测试方向,技术壁垒高、入行门檲高,但对应的薪资回报和职业天花板也远超普通软件测试。

微信公众号二维码图片引自微信公众号,扫码关注阅读原文
V2X与智驾安全测试流程图

V2X协议一致性测试:TC8/Opendaylight

V2X通信的核心协议栈是IEEE 802.11p(DSRC)和3GPP C-V2X。目前国内主流是C-V2X,基于LTE-V或5G NR。测试工程师需要掌握的是「协议一致性测试」,即验证车载设备(OBU)和路侧设备(RSU)的通信是否符合标准规范。

业界最权威的测试规范是:

测试工具链通常包括:Vector CANoe(场景仿真+协议分析)、Keysight综测仪、高通/华为C-V2X测试平台。

初学者切入点

不必一上来就搞懂整个协议栈。从CANoe的V2X测试场景库入手——CANoe自带了常见的V2V(前车碰撞预警、紧急制动预警)和V2I(闯红灯预警、弯道速度提示)测试场景,先学会跑标准场景,再逐步理解背后的协议逻辑。

HIL台架测试:CANoe + 场景仿真

硬件在环(Hardware-in-the-Loop,HIL)测试是智驾测试的核心手段。为什么需要HIL?因为不可能为了一个软件Bug在开放道路上反复测试——危险不说,效率也太低。HIL台架用实时仿真器模拟真实交通场景,让待测ECU(电子控制单元)在实验室环境中「以为自己在开车」。

典型CANoe+HIL测试流程:

Step 1:场景建模

使用CANoe的场景编辑器(Scenario Editor)或CarMaker/vVDS建立交通场景——包括道路拓扑结构、周边车辆运动轨迹、交通参与者行为(如行人突然穿越)。

Step 2:总线仿真

CANoe通过CAN/CAN FD/Ethernet介面连接真实ECU,仿真其他ECU的CAN报文信号——如模拟雷达感知的障碍物信息、模拟车速感知的轮速信号。

Step 3:测试执行

在CANoe中运行测试框架(CAPL脚本或Test Module),驱动场景自动执行,收集ECU的诊断数据和总线通信记录。

Step 4:结果分析

用CANoe的Trace窗口和测试报告,分析ECU响应是否符合预期——例如AEB(自动紧急制动)是否在TTC(碰撞时间)低于阈值时正确触发。

ISO 21448 SOTIF测试流程

SOTIF(Safety of the Intended Functionality)是ISO 21448标准的全称,专门解决一个核心问题:「即使系统没有故障,功能本身是否仍然会导致危险?」这个问题传统功能安全标准(ISO 26262)无法回答,因为SOTIF处理的是「预期功能不足」和「误用」导致的安全风险。

SOTIF测试流程分为四个阶段,测试工程师需要理解每个阶段的目标:

阶段
目标
测试工程师的切入点
1. 系统分析
识别预期功能不足和可预见误用
参与危害分析会议,记录系统边界条件
2. 触发条件分析
识别导致危险行为的触发条件(性能限制、环境因素)
设计边界条件测试用例——如极端天气(暴雨、大雾)、特殊路况(施工锥桶、阴影遮挡)
3. 功能改进
通过设计变更降低已知风险
执行回归测试,验证功能改进后系统在新场景下的行为
4. 残余风险评估
确认剩余风险已降至可接受水平
参与Safety Case编写,整理测试证据链

常见误区:很多测试工程师以为SOTIF测试就是「跑一堆特殊场景」,这是对SOTIF的极大误解。SOTIF的核心是系统分析和迭代改进,测试只是最后一环。如果不参与前面的危害分析和触发条件识别,你只是在「跑场景」,而不是在做SOTIF。


第九章:60天升级行动计划

知道方向和会做项目之间,隔著一条叫「执行」的天堑。以下三条路径,是根据读者的背景差异设计的,核心原则只有一个:每个里程碑都有可交付的产出物,90天后你手上要有一个完整的项目作品。

路径A:面向AI测试赛道

适用读者:有2~5年功能/自动化测试经验,目前在互联网或软件公司工作,希望转型AI测试。

里程碑
时间
交付物
核心动作
Day 30
第1个月
「AI系统质量评估维度清单」一份(10~15个维度)
  • 学完LLM基础原理(吴恩达《Prompt Engineering》课程,约3小时)
  • 本地部署一个开源模型,跑通基本API调用
  • 整理出AI系统质量的核心评估维度清单
Day 60
第2个月
「Prompt鲁棒性测试报告」一份(含测试设计+执行结果)
  • 设计一组对抗性Prompt,系统测试LLM的鲁棒性
  • 学会用Python+pytest搭建AI测试框架
  • 建立一个小型Golden Dataset(20~30条测试用例)
Day 90
第3个月
一个完整的「AI系统测试方案」(可直接用于面试项目展示)
  • 选定一个具体场景(推荐:AI客服对话质量评估),完成端到端测试方案设计
  • 掌握至少一个业界AI测试工具(OpenAI Evals、LangChain Test等)
  • 将前两个月的成果整合为一个完整项目作品
  • 更新LinkedIn/Boss直聘简历,突出AI测试相关关键词

路径B:面向鸿蒙测试赛道

适用读者:有移动端测试经验(Android/iOS),希望切入鸿蒙生态,目前在或目标进入华为系、智能终端厂商。

里程碑
时间
交付物
核心动作
Day 30
第1个月
DevEco Studio环境搭建成功,跑通第一个ohos.test用例
  • 安装DevEco Studio,下载HarmonyOS SDK
  • 学习ArkTS基础语法(与TypeScript高度相似,有JS基础者3天可入门)
  • 搭建第一个含单元测试的鸿蒙应用项目
Day 60
第2个月
一个原子化服务的完整测试用例集(含单元+集成+系统测试)
  • 选定一个鸿蒙应用(建议用开源的HarmonyOS示例应用),设计完整测试方案
  • 重点掌握:Ability生命周期测试、跨设备协同Mock测试、DevEco Testing工具使用
  • 撰写测试用例文档,覆盖正常流程、边界条件、异常场景
Day 90
一个可展示的鸿蒙测试项目作品(代码+文档+测试报告)
  • 完成一个原子化服务的端到端测试项目,含CI/CD集成(GitHub Actions配置鸿蒙测试流水线)
  • 在Gitee或GitHub上建立鸿蒙测试项目仓库
  • 投递华为外包/合作伙伴岗位(最快切入鸿蒙生态的方式),或直接投递鸿蒙应用厂商

路径C:面向车联网测试赛道

适用读者:有汽车电子、嵌入式或相关测试背景(CAN总线、AutoSAR等),希望转型V2X或智驾测试。

里程碑
时间
交付物
核心动作
Day 30
第1个月
CANoe基本操作手册(个人整理的,不低于10页)
  • 安装Vector CANoe试用版(免费评估期30天),跑通CANoe标准备例工程
  • 学习CAN/CAN FD协议基础(对有汽车电子背景的人,这个应该有基础)
  • 了解V2X通信协议栈(C-V2X架构、LTE-V和5G NR的区别)
  • 整理CANoe常用操作和测试命令速查表
Day 60
第2个月
一个V2X场景测试用例集(至少5个完整测试用例,含场景设计+预期结果)
  • 在CANoe中建立一个V2V场景(推荐:前车紧急制动预警FCW场景)
  • 学会使用CANoe的V2X测试场景库
  • 设计并执行至少5个完整的V2X测试用例
  • 学习ISO 21448 SOTIF的基本框架,完成一个简单的触发条件分析案例
Day 90
一个完整的智驾功能测试方案(含HIL测试流程+SOTIF分析框架)
  • 选定一个具体智驾功能(AEB或LKA),完成从需求分析→危害识别→触发条件分析→测试用例设计的全流程
  • 用CANoe CAPL脚本实现一个简化的HIL测试场景
  • 整理面试作品集,重点突出:CANoe使用经验、V2X测试理解、SOTIF框架认知
  • 目标岗位:主机厂智驾测试工程师、Tier1供应商V2X测试工程师


关于「90天」

90天不是魔法,不是90天后你就成了专家。但90天足以让你从「完全不懂」到「能独立完成一个项目」。这个项目作品,就是你敲开新赛道大门的最硬通货。很多时候,HR看你的项目代码,比看你的工作年限更靠谱。