最近总有准备转行做车载测试的朋友问我网上资料那么杂到底先学什么、再学什么是不是必须花一两万报个培训班才能入行说实话两年前我也踩过类似的坑。当时看招聘网站上“车载测试工程师”薪资给得高又听说缺口大一冲动就交了两万块报了个线下班。结果课程前两周在讲 CAN 收发原理第三周开始念 PPT真正动手写 CAPL 脚本和 Python 自动化的时间少得可怜。后来入职后发现项目中真正能用到的能力几乎全是自己啃协议栈、翻 GitHub、看官方文档练出来的。这篇文章就是把我踩坑后总结的完整学习资料路线整理出来免费分享。内容覆盖 ADAS、座舱测试、CAPL、Python 自动化、整车台架、仪表盘中控、OTA 导航和 UDS 诊断。不是列一堆网盘链接让你自己猜而是按真实岗位要求把每个方向要学什么、怎么练、有哪些坑全部串成一条能落地的学习路径。无论你是零基础想转行还是已经在测试行业想转汽车方向这篇文章都值得先收藏再按章节慢慢啃。1. 车载测试到底在测什么先建立完整认知不知道你有没有这种感觉刷招聘软件搜“车载测试”岗位描述写得五花八门有的要求会 CAPL有的要求懂 UDS有的要会 Python有的要熟悉 ADAS 场景。看起来像好几个不同职业实际上它们都属于车载测试体系中的不同分支。先花五分钟搞清楚车载测试的整体地图后面学起来才不会迷路。1.1 车载测试不是只点屏幕很多新人以为车载测试就是反复操作车机屏幕、看看 UI 有没有 bug。这是天大的误解。车载测试本质上是“软件 硬件 网络通信 安全机制”的综合测试。一辆车上有几十个甚至上百个 ECU电子控制单元它们通过 CAN、CAN FD、LIN、FlexRay、车载以太网等总线通信。测试工程师不仅要验证功能是否正常还要验证ECU 之间的信号通信是否正确、时序是否合理诊断服务能不能正常读写数据、刷写程序异常情况下比如总线断线、信号超时、电压突变系统能否安全降级OTA 升级过程中如果断电、断网能不能恢复或回滚智能驾驶系统在特殊场景下会不会误判、漏判。换句话说车载测试更接近“系统级测试”不光要看“点了有没有反应”还要看“整个系统在复杂环境下稳不稳定”。1.2 车载测试的主要分类按我自己的理解车载测试可以从三个维度分类这也是学习路线的参考依据分类维度包含内容典型职责按测试对象车机/座舱测试、仪表测试、ADAS 测试、域控制器测试、T-Box 测试、电机控制器测试功能验证、性能验证、稳定性验证按测试层级单元测试、集成测试、系统测试、整车测试从软件模块到整车级联调按工具链CANoe 脚本测试、Python 自动化、台架 HIL 测试、实车路测搭建测试环境、执行测试、分析结果所以你看到的 ADAS、座舱测试、UDS 诊断、OTA 导航测试、整车台架测试并不是五个并列岗位而是“不同的测试对象”和“不同的测试手段”组合出来的岗位分工。学习的时候最好先掌握共性的“总线通信 诊断协议 自动化脚本”再根据目标岗位补专项。2. 全套自学路线从零开始怎么走结合我自己的学习过程以及后来带新人总结的经验我建议你把学习分成五个阶段。每个阶段都有明确目标不要跳步。2.1 第一阶段汽车电子基础与 CAN 通信这个阶段解决的是“车上的设备怎么互相说话”的问题。必学内容汽车电子电气架构常识ECU、传感器、执行器、总线拓扑CAN 总线协议显性隐性电平、帧格式、仲裁机制、位填充、错误处理CAN FD 与经典 CAN 的区别LIN、FlexRay、车载以太网的适用场景DBC 文件的基本结构报文、信号、值域、缩放因子、偏移量。学习资源不用买课推荐三个免费渠道B 站搜索“CAN总线协议讲解”找播放量高的那几套先看帧结构知乎搜索“DBC 文件怎么解析”配合 CANdb 软件边看边操作买一块几十块钱的 USB-CAN 分析仪比如周立功、创芯科技配合 CANTest 软件抓真实报文。这个阶段最重要的事情是理解 CAN 报文不是“发一句话”那么简单它有 ID、DLC、Data、周期有大小端有 bit 位偏移。后面写 CAPL、Python 自动化本质上都是在操作这些底层数据。2.2 第二阶段UDS 诊断测试诊断测试是车载测试里岗位最多、最缺人的方向之一也是新手最容易通过短期学习拿到 offer 的方向。必学内容UDSISO 14229协议分层应用层、会话层、传输层诊断会话控制、安全访问、读写数据、例程控制、故障码读写常用服务 ID 和 NRC 码诊断刷写流程Bootloader、应用区、回滚机制诊断测试用例设计思路。这一阶段的实操最好能配合 CANoe 的 DiVa 或免费的 Python 诊断库。后面第 3 章会专门展开这里先不写太多。2.3 第三阶段CAPL 脚本与自动化CAPLCommunication Access Programming Language是 Vector CANoe 内置的类 C 脚本语言用来模拟节点、发送报文、自动执行测试。车载测试岗位里很大的工作量都靠它完成。必学内容CAPL 程序结构和事件模型on message、on key、on timer、on start定时器、消息对象、信号访问系统变量与环境变量在 CAPL 中发送诊断请求结合 Test Module 写自动化用例。学习 CAPL 最大的门槛是没有 CANoe 授权。我的建议是先安装 CANoe 的 Demo 版或试用版配合 Vector 官方自带的 Virtual CAN Bus 模拟通道一样能练习大部分语法特性。2.4 第四阶段Python 自动化与数据解析Python 在车载测试里主要用来做三件事通过 PCAN、CANoe、周立功等硬件接口读写 CAN 报文解析 DBC、ARXML、诊断 ODX 文件自动生成测试用例或测试报告搭建自动化测试框架比如用 pytest 组织用例、用 unittest 做断言、用 PyQt 写测试工具界面。学习资源可以直接看 Python 官方教程入门然后重点掌握几个关键库python-can跨平台 CAN 收发库cantools解析 DBC 文件udsoncan如果你熟悉 ISO-TP 和 UDS这个库可以直接封装诊断请求pytest自动化用例组织。这一阶段的目标是能用 Python 自己写一个小工具自动发送 CAN 报文并校验回复。能达到这个水平面试时能讲清楚项目上岸概率就很高了。2.5 第五阶段专项领域ADAS/座舱/OTA/整车台架前三四个阶段属于“车载测试通用能力”到了第五阶段才分方向。你可以根据自己的兴趣和城市岗位情况选择想做智能驾驶方向重点学 ADAS 场景库设计、传感器原理、仿真工具Prescan、CarSim、VTD想做座舱方向重点学 Android 系统测试、仪表显示逻辑、语音交互、多屏互动、性能稳定性想做整车 OTA 方向重点学升级包制作、A/B 分区、断点续传、失败回滚想做台架方向重点学 HIL硬件在环原理、实时仿真机、IO 信号模拟、故障注入。第五阶段不建议一上来猛学先了解岗位要求再定向补。下面几章会分别拆解。3. UDS 诊断测试入门必学的核心方向如果你时间有限只够学一个方向我建议优先学 UDS 诊断。原因是入行门槛相对低、岗位需求大、学习链路清晰而且几乎所有整车厂和 Tier1 都在用。3.1 UDS 协议基础UDSUnified Diagnostic Services是 ISO 14229 定义的一套诊断服务规范。它运行在 CAN 总线之上通过一组标准化的“请求-响应”机制让外部诊断仪或测试设备读取车辆内部 ECU 的信息。通俗地理解UDS 就是“医生和病人之间的问诊协议”。诊断仪发出一个请求帧RequestECU 收到后返回一个响应帧Response。根据请求的服务 ID 不同可以读取故障码、读取版本号、读取数据、执行某项操作、甚至刷写程序。UDS 通常是“单帧请求 单帧响应”但当数据超过单帧容量时会走传输层拆包、组包流程。所以学 UDS 时除了 ISO 14229还要了解 ISO 15765-2CAN 上的传输层协议也叫 ISO-TP。3.2 常用服务与 NRC按功能分类UDS 服务可以分为六大类功能分类服务 ID服务名称用途诊断会话管理0x10DiagnosticSessionControl切换默认会话、扩展会话、编程会话安全访问0x27SecurityAccess解锁 security level才能执行写操作数据读取0x22ReadDataByIdentifier按 DID 读取数据数据写入0x2EWriteDataByIdentifier按 DID 写入数据例程控制0x31RoutineControl执行/停止例程常用于测试和标定故障码管理0x19ReadDTCInformation读取故障码故障码清除0x14ClearDiagnosticInformation清除故障码下载请求0x34RequestDownload开始刷写流程数据传输0x36TransferData传输刷写数据传输结束0x37RequestTransferExit结束刷写传输链路控制0x87LinkControl波特率切换等链路控制操作每次响应如果执行失败ECU 会返回一个 NRCNegative Response Code比如 0x22 表示条件不满足、0x31 表示请求超出范围、0x33 表示安全访问被拒绝、0x78 表示请求已收到正在处理。写测试用例时重点关注三件事正向用例正常请求是否返回正确正响应负向用例非法请求、未登录就写数据、DID 不存在时NRC 是否正确时序用例请求和响应之间不能超时连续请求间隔是否符合规范。3.3 诊断测试用例怎么设计实际项目中诊断测试用例一般包括服务层冒烟测试每个服务发一次正常请求确认 ECU 能正常响应会话切换测试默认会话 - 扩展会话 - 编程会话切换是否符合规范安全访问测试Seed 和 Key 算法是否正确、连续失败锁定时间是否正确数据读写测试遍历所有 DID读取并校验值域、步长、单位故障码注入测试模拟传感器故障确认 DTC 置位、状态位变化刷写测试核心流程、中断恢复、无效包重传、超时处理。如果你在项目里可以直接用诊断仪 CANoe 手动执行如果是自动化测试则用 Python 封装诊断请求再由 pytest 组织用例和断言。3.4 用 Python 发起一次诊断请求下面给一个最简单的 Python 示例演示通过 python-can can-isotp 发送 UDS 请求并读取响应。注意这个代码需要在有 CAN 硬件或虚拟通道的电脑上运行。# 文件路径uds_demo/read_did.py # 依赖安装pip install python-can can-isotp import can import isotp # 1. 配置 CAN 总线pcan 换成你的硬件类型 bus can.Bus(interfacepcan, channelPCAN_USBBUS1, bitrate500000) # 2. 配置 ISO-TP 层 tp_params { stmin: 0x00, blocksize: 8, wftmax: 0, padding: True, } stack isotp.CanStack( bus, local_address0x0F, # 诊断仪地址 remote_address0x10, # ECU 地址 paramstp_params, ) # 3. 发送 0x22 读取 DID 0xF190 request bytes([0x22, 0xF1, 0x90]) stack.send(request) # 4. 接收响应 try: response stack.recv(timeout2) print(响应字节, response.hex()) if response[0] 0x62: print(读取成功数据区, response[1:].hex()) elif response[0] 0x7F: print(负响应NRC, hex(response[2])) except Exception as e: print(接收超时或异常, e) finally: bus.shutdown()这段代码的核心逻辑先用can.Bus建立总线连接再用isotp.CanStack把 UDS 请求封装成 ISO-TP 帧发送后recv等待 ECU 响应。如果你没有 CAN 硬件也可以用 CANoe 的虚拟通道配合can库的socketcan接口前提是电脑上装了 SocketCAN 驱动的虚拟设备。Windows 下最省事的方案是装一个 PCAN 虚拟驱动或者用周立功的硬件。4. CAPL 编程CANoe 环境下的测试脚本CAPL 是车载测试里绕不开的坎。虽然它不像 Python 那样通用但大多数整车厂和 Tier1 的台架测试、诊断测试、总线测试脚本都是用 CAPL 写的。而且很多岗位 JD 里明确写了“熟悉 CAPL 优先”。4.1 CAPL 是什么CAPL 是 Vector 开发的一种类 C 的脚本语言运行在 CANoe 的仿真节点里。它的语法和 C 很像但针对总线仿真做了大量扩展核心优势是可以直接定义 CAN 报文和信号调用output()发送可以使用事件函数event procedure响应对应总线事件可以操作定时器精确控制发送周期与 CANoe 的 Test Module 结合能写自动化测试序列。CAPL 的代码不是从 main 函数开始的而是由多个“事件函数”组成。每个事件函数在指定条件触发时执行。比如on message在收到某条报文时触发on key在按下键盘按键时触发。4.2 最小示例下面是一个最基础的 CAPL 示例定时发送一条自定义报文并在收到指定报文时打印信号值。/* 文件路径CAPL_Demo/demo.can */ variables { message 0x123 g_msg; // 声明一条 CAN 报文ID 为 0x123 msTimer g_timer; // 声明一个毫秒定时器 } on start { // 初始化报文数据 g_msg.dlc 8; g_msg.byte(0) 0x11; g_msg.byte(1) 0x22; setTimer(g_timer, 100); // 启动 100ms 周期定时器 } on timer g_timer { g_msg.byte(2) g_msg.byte(2) 1; output(g_msg); // 发送报文 setTimer(g_timer, 100); // 重新启动定时器形成周期发送 } on message 0x456 { // 收到 0x456 报文时打印第一个字节 write(Recv 0x456, byte0 0x%02x, this.byte(0)); }逐行解释variables块里声明报文对象和定时器on start中初始化报文内容并启动定时器on timer g_timer中修改数据并发送报文同时重新设置定时器实现周期发送on message 0x456是接收事件收到对应 ID 的报文后自动执行。这个例子虽然短但已经覆盖了 CAPL 最常用的三种事件启动事件、定时器事件、报文接收事件。4.3 常见应用场景CAPL 在实际项目中主要用于模拟一个仿真节点比如模拟 BMS、模拟雷达按照真实周期发送报文总线监控和自动化测试收到故障码信号时自动记录日志、发送诊断请求结合 Test Module 写自动化用例调用TestWaitForMessage、TestWaitForTimeout、TestReportAddMisc等函数完成断言和报告做故障注入在特定时刻停止发送某条报文模拟总线丢帧。学习 CAPL 时如果你没有 CANoe 完整版权限我建议先用 CANoe 的 Demo 模式。Demo 模式自带示例工程和虚拟总线你可以直接打开 Vector 官方自带的CANoeDemo.cfg在里面新建 CAPL 节点练习。5. Python 自动化测试搭建自己的测试框架Python 在车载测试中的地位越来越重要。原因很简单测试工程师需要快速解析数据、快速写脚本、快速沉淀工具Python 的生态最合适。5.1 为什么用 Python入门快语法简单写测试脚本成本低python-can、cantools、udsoncan等库能让我们绕过复杂的协议细节直接聚焦测试逻辑和 pytest 结合测试报告、断言、夹具管理都很成熟数据分析和可视化能力强大特别适合处理台架日志和路测数据。5.2 环境准备最简单的开发环境组合Windows 10/11 或 Ubuntu 20.04Python 3.8 及以上安装依赖pip install python-can cantools pytest根据你的 USB-CAN 硬件安装对应驱动如果你用的是周立功、PCAN、Kvaser 等设备python-can 已经内置了对应接口只需要指定interface参数即可。比如pip install python-can cantools pytest5.3 读取 DBC 与发送 CAN 报文实际测试时我们很少用手写信号值而是通过 DBC 文件解析信号然后由工具自动计算字节。下面这个示例演示加载一个 DBC 文件创建消息填充信号值然后通过 CAN 总线发送。# 文件路径can_demo/send_signal.py import can import cantools # 1. 加载 DBC db cantools.database.load_file(demo.dbc) # 2. 创建消息 message db.get_message_by_name(BMS_Status) data message.encode({ BMS_SOC: 80.5, BMS_Voltage: 400.2, BMS_Current: 12.3, }) # 3. 发送 CAN 报文 bus can.Bus(interfacepcan, channelPCAN_USBBUS1, bitrate500000) msg can.Message( arbitration_idmessage.frame_id, datadata, is_extended_idFalse, ) bus.send(msg) print(已发送, msg)DBC 文件的解析逻辑是根据协议文件里定义的排列方式把物理值换算成原始值再填充到数据字节里。cantools帮我们处理了大小端、缩放因子、偏移量、值域限制所以代码非常简洁。如果你没有 DBC 文件只想手动拼报文也可以直接用can.Message(data[0x00, 0x01, ...])。但正式项目中强烈建议维护好 DBC 或 ARXML 文件否则信号一旦变动代码全得重写。5.4 自动化用例工程化建议一个能落地的 Python 自动化测试工程建议这样组织auto_test/ ├── config/ # 存放 DBC、CAN 通道配置、诊断请求配置 ├── common/ # 公共方法CAN 连接、ISO-TP 封装、日志 ├── testcases/ # pytest 测试用例 ├── reports/ # 测试报告输出 ├── requirements.txt └── conftest.py # pytest 夹具简单写一个测试用例示例# 文件路径auto_test/testcases/test_bms.py import pytest import can from common.can_helper import get_bus pytest.fixture(scopemodule) def bus(): b get_bus() yield b b.shutdown() def test_send_bms_status(bus): 验证发送 BMS_Status 报文后总线无异常 msg can.Message( arbitration_id0x123, data[0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08], is_extended_idFalse, ) bus.send(msg) assert True在实际项目中你还可以把测试结果写入 SQLite、生成 HTML 报告甚至接入 CI 系统做到每次合入代码都自动触发总线级回归测试。6. ADAS、座舱、OTA、整车台架专项测试扫盲前面几章写的是“所有车载测试都有用的公共能力”这一章快速扫盲四个专项方向帮助你看清每个方向做什么、需要什么技能。6.1 ADAS 测试ADAS高级驾驶辅助系统测试的核心目标是验证车辆对周边环境的感知、决策和控制是否安全可靠。主要测试内容传感器测试摄像头、毫米波雷达、激光雷达的标定、失效模式、信号质量功能测试ACC自适应巡航、AEB自动紧急制动、LKA车道保持、BSD盲区监测等场景测试根据真实路况建立场景库比如前车切出、行人横穿、雨雾天气、隧道明暗变化仿真测试用 Prescan、CarSim、VTD 等工具搭建虚拟场景完成批量回归实车路测在测试场或公开道路验证极端场景。如果你想做 ADAS 方向只学测试方法论不够还要理解传感器基本原理、坐标变换、目标融合、AEB 标定逻辑。没有实车资源时可以先学仿真工具这是一个相对低成本的入门途径。6.2 座舱测试仪表盘中控座舱测试主要围绕车机系统、液晶仪表、HUD、后排娱乐屏展开。和传统手机 App 测试相比座舱测试多了几个关键点车机与整车的信号交互仪表上的车速、转速、油量必须和总线上的真实信号一致多屏互动仪表、中控、HUD 同步显示不能有延迟语音交互在噪音环境下唤醒率、识别率、误唤醒率是否达标性能稳定性冷启动时间、导航流畅度、长时运行内存是否泄漏系统升级后的兼容性OTA 升级后原有功能是否回归正常。座舱测试常用工具包括ADB、UIAutomator2、Appium、QNX 调试工具、性能分析工具等。如果你有 Android 测试经验转座舱会相对快一些。6.3 OTA 导航测试OTAOver-The-Air指的是通过无线网络完成软件升级。车端 OTA 已经成为智能汽车的标配测试重点包括升级包完整性验签、校验失败时是否阻止升级下载流程弱网、断网、切换网络时能否暂停、续传升级流程升级过程中断电、低电量、用户强行重启系统能否自动恢复A/B 分区或备份回滚升级失败后能否回滚到原版本版本管理升级前后软件版本、配置信息是否一致导航专项导航数据增量更新、地图版本兼容、路径计算是否正常。OTA 测试和后台服务端关系很大需要了解 HTTP/HTTPS 下载、差分包、签名校验、车端升级管理器状态机等知识。如果你熟悉服务端接口测试再补一些车端状态机知识会很容易上手。6.4 整车台架测试整车台架测试是把整车或关键子系统放在实验室台架上通过仿真设备模拟真实运行环境完成功能验证和故障模拟。常见台架包括整车电子电气台架模拟所有 ECU 信号验证整车功能逻辑硬件在环 HIL 台架把真实 ECU 接入实时仿真机模拟传感器和执行器信号动力总成台架测试发动机/电机控制器的性能和可靠性热管理台架模拟高低温环境验证冷却系统、空调策略。做台架测试核心技能是熟悉台架搭建原理信号调理、负载模拟、故障注入、数据采集会用 CANoe、INCA、标定工具和实时仿真机能看懂电气原理图知道哪些信号要模拟、哪些要真实接入会设计测试工况比如极限电压、低温启动、总线断线。台架测试比纯软件测试更有“工程感”适合喜欢硬件、动手能力强的人。7. 常见问题与避坑7.1 没有硬件环境怎么练很多人自学卡在第一步没有 CANoe没有总线工具怎么动手我的回答是先别急着买硬件用软件环境把语法和思路练熟。以下几个方案从便宜到贵CANoe Demo 模式访问 Vector 官网申请试用自带示例工程和虚拟总线Python 虚拟 socket在 Linux 下用 vcan 创建虚拟 CAN 接口python-can直接读写二手 USB-CAN 分析仪一两百块配周立功测试软件足够学习PCAN 虚拟驱动Windows 下安装 PCAN 驱动后可以创建虚拟 PCAN 通道配合 Python 练习。等你真正拿到面试或者入职后再根据公司实际设备快速切换。7.2 培训班的常见套路不是所有培训班都不好但市面上确实存在一些坑课程大纲看着很全实际只讲概念不教动手所谓“项目实战”其实是照着 PPT 敲代码没有真实总线环境承诺推荐就业结果推荐的是外包初级岗要求特别低价格昂贵从 1 万到 2 万多不等但内容在网上都能免费找到。如果你预算有限完全可以按照本文的路线自学。我的实践经验是车载测试入门的核心是 CAN 原理 UDS 诊断 一种脚本语言这三块都能通过免费资料和低成本的硬件搞定。7.3 投简历没回应怎么办很多自学者担心“没有项目经验简历过不了”。化解思路是这样的把自学过程做成作品比如自己用 Python 写了一个 DBC 解析器和 CAN 报文发送小工具传到 GitHub 上在简历里写清楚你掌握的协议、工具链和脚本能力不要只写“了解”通过外包岗位切入积累真实项目经验后再跳甲方面试时重点展示学习能力和踩坑经验比背概念更容易打动面试官。8. 最佳实践与测试思维8.1 测试用例设计的核心思路写车载测试用例永远记住“正常 异常 边界”三个维度正常正常情况下功能是否正确异常总线断线、信号无效、超时、重复请求、非法参数边界最小/最大值、空数据、高频率、长时间运行。比如测试 UDS 读取数据不只要测 DID 存在时能否返回还要测 DID 不存在时 NRC 是否正确、会话不满足时是否拒绝、连续发送时是否卡死。这些边界组合才是车载测试面试官真正想听到的东西。8.2 日志和可复现性车载测试在台架或实车环境下执行问题复现成本很高。因此日志记录非常关键。强烈建议你做这几件事测试脚本里统一记录时间戳、报文 ID、通道号、关键信号值保存原始总线日志BLF、ASC、pcap 等格式不要只截图问题定位时先看时间线从日志里还原现象发生前的总线状态自动化用例执行失败时自动把相关报文片段导出到报告附件。日志越完整定位问题越快这也是“测试工程师”和“只会点按钮”的人最大的区别。8.3 脚本工程化意识很多自学者写的测试脚本都是“一次性脚本”能用就行。但真正到了项目中这样会吃大亏。建议你从第一天开始就养成工程化习惯常量、配置和测试逻辑分离不把波特率、CAN 通道 ID 写死在代码里写函数注释哪怕只有三行也说明输入输出异常处理不能空pass至少要打印堆栈或写入日志命名规范统一比如send_xxx、check_xxx、wait_xxx代码提交到 Git 里每次改动都要有记录。这些习惯在面试时聊项目就能体现出来比堆技术名词有用得多。9. 总结与下一步这篇文章从车载测试的完整地图讲起串起了一条从 CAN 通信、UDS 诊断、CAPL 脚本到 Python 自动化的学习路线也把 ADAS、座舱、OTA、整车台架这几个专项方向做了扫盲。核心想表达的是车载测试并不神秘它有一套清晰的协议标准和测试方法论完全可以通过自学掌握。不要再迷信“两万块的培训班”也不要觉得没有资源就没法学。先搞定 CAN 和 UDS再选一个脚本方向深入下去配合低成本 CAN 工具反复练习完全可以实现入行。下一步建议你这样做花一周时间精读 CAN 协议帧格式并用 CAN Test 软件抓一些真实报文再花两周时间学 UDS 常用服务和 NRC用 Python 写一个诊断请求小工具接着用 CANoe Demo 练习 CAPL 基本语法写一个周期发送报文的仿真节点最后把代码整理到 GitHub形成自己的项目案例。如果你在自学过程中遇到什么报错或概念理解不了欢迎在评论区留言我看到后会尽量帮你分析。这篇文章整理的路线和资料也可以转发给准备入行的朋友大家一起少走弯路才是最有价值的免费分享。