模块2 · 车载测试工程基础教程（从入门到精通）

通俗话一句话：本模块是"测试工程师的工具箱+基本功"——测试怎么分类、用例怎么写、Bug怎么管理、Linux命令/ADB怎么用、Git怎么存代码、Jenkins怎么自动跑、ASPICE流程怎么跟。这些是做任何一个域的测试，都必须会的"通用技能"。

第1章 · 车载测试理论基础

1.1 什么是"测试"？（7个经典原则）

通俗话：测试 = "找Bug + 证明软件符合需求 + 评估质量"三不误。不是等开发写完了才开始测，而是从需求阶段就要介入。

软件测试的7大经典原则（面试常问）： ┌───────────────────────────────────────────────────────────────┐ │ ① 测试能证明缺陷存在，但不能证明没有缺陷 │ │ 人话：你测了1000条用例全过，也不能说"这软件100%没Bug" │ │ 只能说"在我们测过的场景里没发现Bug" │ │ │ │ ② 穷尽测试不可能（穷举不完） │ │ 人话：用户使用场景千千万，不可能全测，必须"选重点" │ │ 靠风险分析、等价类、边界值来缩小范围 │ │ │ │ ③ 测试要尽早介入（测试左移 Shift Left） │ │ 人话：别等代码写好才开始测，需求评审/设计评审就要开始挑错 │ │ 需求里的一个Bug = 线上100个Bug的修复成本 │ │ │ │ ④ 缺陷具有"集群效应"（80/20原则） │ │ 人话：80%的Bug集中在20%的模块里 │ │ 某个模块测出来Bug多，就重点往死里测它 │ │ │ │ ⑤ 杀虫剂悖论（同样的用例反复用会失效） │ │ 人话：一套用例跑100次全过，不代表真的没问题 │ │ 要不断补充新用例、新角度 │ │ │ │ ⑥ 测试依赖上下文（不同车/不同模块测法不同） │ │ 人话：智驾的L3测法和座舱的CarPlay测法完全不同 │ │ ASIL-D的BMS测试标准要比氛围灯严格100倍 │ │ │ │ ⑦ 没有缺陷 ≠ 有用（Absence-of-errors fallacy） │ │ 人话：软件没Bug但完全不符合用户需求 = 垃圾 │ │ 必须对其需求 + 用户体验来测 │ └───────────────────────────────────────────────────────────────┘

1.2 车载测试的分类（金字塔模型+扩展）

车载测试"金字塔 + 环"模型（每层测试目的+占比）： /─────────\ / 用户验收 \ ← 5% 客户角度体验验收 / (UAT/SAT) \ /───────────────────\ / 整车/标定/路试 \ ← 10% 真车实车测 / (EVT/DVT/PVT) \ /─────────────────────────\ / 系统测试(全ECU/全域) \ ← 20% 集成完的ECU/域 / (SIT/SYSTEST) \ /─────────────────────────────────\ / 集成测试(多个模块拼一起测) \ ← 20% 模块间接口 / (Integration Test) \ /─────────────────────────────────────────\ / 单元测试(单个函数/模块) \ ← 40% 代码级 / (Unit Test / MC/DC) \ /─────────────────────────────────────────────────\ ← 越靠底，Bug修复成本越低；越靠顶，越接近真实用户 ┌─────────────────────────────────────────────────────┐ │ 加上"仿真环" MIL/SIL/PIL/HIL（车载行业特有） │ │ MIL Model-in-Loop 模型级仿真 (Simulink模型) │ │ SIL Software-in-Loop 纯PC跑模型+代码 │ │ PIL Processor-in-Loop 代码灌进MCU芯片跑模型 │ │ HIL Hardware-in-Loop 真实ECU接仿真器跑 │ └─────────────────────────────────────────────────────┘

1.3 黑盒/白盒/灰盒测试的区别

┌───────────────────────────────────────────────────────────────┐ │ 黑盒测试 Black-box（车载80%工作都是这个） │ │ ├── 不管代码怎么写的，只看"输入→输出"对不对 │ │ ├── 输入：发CAN信号/按屏幕/说语音/踩刹车 │ │ ├── 输出：看灯亮不亮/仪表走不走/车减不减速 │ │ ├── 设计方法：等价类、边界值、判定表、正交实验、场景法 │ │ └── 适合：系统测试/整车测试/功能测试 │ │ │ │ 白盒测试 White-box（开发或SDET做，测代码结构） │ │ ├── 看源代码，测"每一行代码/每个分支/每个条件"有没有走到 │ │ ├── 指标：语句覆盖/分支覆盖/MC/DC覆盖(ASPICE功能安全必备) │ │ ├── 工具：VectorCAST/IBM Rational Test RealTime/gcov │ │ └── 适合：单元测试(UT)/安全相关ASIL-B以上模块 │ │ │ │ 灰盒测试 Gray-box（车载最实用的混合） │ │ ├── 接口级测试：知道模块内部接口，但不纠结每行代码 │ │ ├── 例子：测BCM→车窗ECU的LIN信号时序；用CANoe看中间信号 │ │ └── 适合：集成测试IT/跨ECU功能联调 │ └───────────────────────────────────────────────────────────────┘

1.4 测试用例设计方法（车载常用的5个）

车载最常用的5种用例设计方法（每个都给实例）： 方法1：等价类划分法 例：车速显示范围 0~250 km/h (要求精度±1km/h) ├── 有效等价： 0, 100, 250 └── 无效等价：-1, 251, 9999, 空值, 负数 方法2：边界值分析法（等价类的边界最容易出Bug） 例：燃油报警阈值 ≤5% 时亮灯 ├── 边界点： 4%, 5%, 6% └── 重点测： 4%亮→5%亮→6%灭 是否正确（滞回区间别搞错） 方法3：判定表法（多条件组合） 例：远光灯开启条件 ├── 条件C1：点火ON (Y/N) ├── 条件C2：小灯ON (Y/N) ├── 条件C3：远光开关拨到开 (Y/N) └── 结果：8种组合全测，Y-Y-Y才开，其他都关 方法4：场景法（端到端，用户视角） 例："自动泊车"完整场景 ├── 基本流：找车位 → 选车位 → 按开始 → 泊入 → 停好 ├── 异常流1：泊车中途有人按暂停 ├── 异常流2：泊车中途有障碍物冲出来 └── 异常流3：泊车中途刹车被人为踩下 方法5：错误推测法（经验法，老司机最爱） 例：靠经验想"用户最容易造坏的操作" ├── 点火瞬间疯狂按屏幕 ├── 升级OTA中途拔U盘 ├── 连续100次开/关后备箱 └── -30℃冷启动第一秒语音喊"打开车窗"

1.5 Bug报告怎么写（车载版·合格的Bug开发不敢怼你）

通俗话：一个合格的Bug报告 = “开发看了不用问你，马上能复现，复现完能定位”。不要只写"仪表显示异常"，写清楚在什么条件下、显示成了啥、应该是啥。

车载Bug报告的标准模板（复制这个填）： ┌───────────────────────────────────────────────────────────────┐ │ 【标题】（一句话，说清楚"哪里×什么情况×实际结果×期望结果"） │ │ 例：[IPC] 车速=0xC6(198km/h)报文，仪表指针打到 188km/h │ │ │ │ 【严重程度】(S0~S4，每个公司定义不同，大致如下) │ │ S0 Blocker 车坏了/有安全风险：比如AEB不刹车/气囊误爆 │ │ S1 Critical 功能失效：比如仪表黑屏/语音完全没反应 │ │ S2 Major 主要功能部分不对：车速差10km/h │ │ S3 Minor 小功能/UI问题：比如字有一个像素歪了 │ │ S4 Trivial 建议/体验优化：比如字体可以再大一点 │ │ │ │ 【优先级】(P0~P3) 什么时候必须修 │ │ P0 今天必须修 (发版本前发现的致命Bug) │ │ P1 本周必须修 (S1/S2正常都是P1) │ │ P2 这个迭代内修 (体验类) │ │ P3 有空再修 (建议类) │ │ │ │ 【前置条件】(复现这个Bug之前，车要处在什么状态) │ │ 例：KL15=ON；在扩展会话；软件版本IPC_V2.3.1_RC3 │ │ │ │ 【复现步骤】(Step by Step，编号，每一步只做一个动作) │ │ 步骤1：CANoe加载Test.dbc，连接IPC台架 │ │ 步骤2：发0x100报文 EngMsg.VehSpeed = 198 km/h 周期100ms │ │ 步骤3：持续发送20秒，观察仪表指针 │ │ │ │ 【实际结果】(Actual Result，越详细越好，配截图/录屏/Trace) │ │ 指针指向 188 km/h 位置（视觉拍照 + CANoe Trace） │ │ 截图: IPC_Speed_198.png；Trace: IPC_198km.blf │ │ │ │ 【期望结果】(Expected Result，严格按需求文档写) │ │ 仪表指针应指向 197~199 km/h (需求: ±1km/h误差) │ │ │ │ 【版本信息】（Bug出在哪个版本） │ │ 软件: IPC_v2.3.1_RC3_20260801 硬件: V1.2 │ │ DBC: Test_20260730.dbc │ │ │ │ 【附件】（必加！一个顶1000句文字） │ │ ├── CANoe BLF / ASC Trace文件 (完整抓包) │ │ ├── 台架/实车照片/视频 │ │ ├── 诊断导出的DTC快照 │ │ └── 日志文件(logcat / dmesg / plog) │ └───────────────────────────────────────────────────────────────┘

第2章 · Linux 命令（车载常用30个）

2.1 为什么测试要懂Linux？

因为99%的智能座舱/智驾/T-BOX ECU，底层跑的都是Linux （Android = Linux内核改装版，QNX是微内核，但命令也差不多） 测试工程师用Linux干什么： ├── 1. SSH/Telnet进ECU，看系统状态/日志 ├── 2. 抓日志/导日志 (logcat/dmesg/coredump) ├── 3. 推/pull文件 (把测试文件塞进ECU，把log拿出来) ├── 4. 模拟故障：kill进程/拔模块/改环境 └── 5. 自动化脚本 (Python/Bash) 都跑在Linux服务器

2.2 基础命令（第一梯队，必须背下来）

# ============== 1. 文件/目录类 ============== pwd # 看当前在哪个目录 ls / ls -l / ls -la # 列文件/带详情/含隐藏 cd /home/ / cd .. / cd ~ # 切目录/上一级/家目录 mkdir test_dir # 新建目录 rm -rf old_logs/ # 强制递归删除 ⚠️别随便rm -rf / cp a.log b.log # 拷贝 mv a.log ../b/ # 移动/改名 touch test.txt # 新建空文件 find / -name "*.log" 2>/dev/null # 全盘搜.log # ============== 2. 看文件内容类 ============== cat info.txt # 打印整个文件(小文件用) head -20 info.txt # 看前20行 tail -20 info.txt # 看后20行 tail -f running.log # ✨ 实时追踪日志 (最常用) grep "ERROR" run.log # ✨ 搜索含ERROR的行 grep -rn "VehicleSpeed" ./ # 递归当前目录下搜VehicleSpeed less /var/log/syslog # 大文件分页看 (q退出) # ============== 3. 系统状态类 ============== ps -ef | grep "navi" # 看导航进程在不在 top / htop # 看CPU/内存占用(实时) free -m # 看内存使用(MB) df -h # 看磁盘/分区剩余容量 du -sh /var/log/* # 看每个log目录多大 uname -a # 看内核版本/架构 uptime # 看系统跑了多久，负载 # ============== 4. 网络类 ============== ifconfig / ip a # 看网卡IP ping 192.168.1.10 # ping通不通 (Ctrl+C停) netstat -anp | grep 8888 # 看8888端口被谁占了 wget http://x.x/ota.bin # 下载文件 scp local.bin root@10.0.0.5:/tmp # 本地/远端互传文件 (SSH) curl http://tsp.example.com/ping # ✨ 发HTTP请求测TSP接口 # ============== 5. 进程/权限类 ============== kill 1234 / kill -9 1234 # 干掉PID=1234的进程 (-9=强制) chmod 755 test.sh # 加执行权限 chown user:user a.txt # 改属主 sudo reboot # 重启(要root) su root # 切root用户 # ============== 6. 其他神器 ============== tar -xzvf fw_1.0.tar.gz # 解压 .tar.gz tar -czvf log.tar.gz /var/log # 打包/压缩 date # 当前时间 history | grep grep # 看历史命令 echo "Hi" > a.txt # 覆盖写 echo "Hi" >> a.txt # 追加写

2.3 车载测试专用的几个Linux操作技巧

技巧1：导出诊断崩溃的coredump（定位死机神器） find /var/lib/systemd/coredump -name "core*" -newer /tmp/mark # 然后gdb分析core（或把core发给开发） 技巧2：实时过滤"有ERROR同时带IPC"的日志 tail -f /var/log/ivi.log | grep --line-buffered -E "ERROR|FATAL" | grep "IPC" 技巧3：测CPU/内存压力（稳定性/性能回归） stress --cpu 4 --io 2 --vm 1 --vm-bytes 256M --timeout 60s # 然后看仪表/导航会不会卡死 技巧4：把ECU里的全量日志拉回本地分析 scp -r root@192.168.1.100:/data/log/* ./ecu_logs/20260815/

第3章 · ADB 命令（安卓座舱测试必备）

3.1 什么是ADB？怎么连？

通俗话：ADB (Android Debug Bridge) = 电脑和安卓座舱(一般是IVI中控/副驾屏，跑Android Automotive OS)之间的"数据线+命令行通道"，就像给安卓装了个SSH。

连接ADB的3种方法（车载最常用网络ADB，因为车屁股USB不好插）： 方法1：USB直连(调试口) 1. 用USB线连电脑和座舱调试口 2. 座舱里开发者选项 → 打开USB调试 3. 电脑cmd：adb devices → 看到设备号=OK 方法2：Wi-Fi/以太网 ADB over TCP/IP（推荐！） 1. 让电脑和座舱在同一网段 (比如座舱IP 192.168.1.50) 2. adb connect 192.168.1.50:5555 3. adb devices → 看到192.168.1.50:5555 device=OK 方法3：ADB WiFi (安卓11+) 座舱开发者选项 → Wireless debugging → 配对码连

3.2 车载测试必背的20个ADB命令

# ============== 基础类 ============== adb devices # 看已连接设备 adb connect 192.168.1.50:5555 # 连网络ADB adb disconnect # 全断开 adb root # 切到root权限(必须debug版固件) adb remount # 把/system等分区改成可读写 adb reboot # 重启座舱 adb reboot recovery # 重启到recovery模式 (刷机用) # ============== 日志类（最常用） ============== adb logcat # 实时看安卓日志 (Ctrl+C停) adb logcat -c # 清空之前的logcat缓存 adb logcat -v time > log_815.log # ✨ 带时间戳存到文件(抓Bug专用) adb logcat -b crash # 看native崩溃栈 (crash必抓) adb logcat ActivityManager:I *:S # 只看ActivityManager的Info以上 # ============== 文件推送/拉取 ============== adb push C:\test\video.mp4 /sdcard/Movies/ # 把电脑文件塞座舱 adb pull /data/anr/traces.txt C:\bug_001\ # 把座舱ANR拉回电脑 # ============== 安装/卸载APP ============== adb install test_carplay.apk # 装一个APK adb install -r test_v2.apk # 覆盖升级装 adb uninstall com.fc.navi # 卸载导航 adb shell pm list packages | grep tencent # 列出所有应用(含车载) # ============== 进设备里操作 ============== adb shell # 进入座舱内部的Linux shell # 进去后就能跑上一章所有Linux命令 # ============== 事件模拟类（UI自动化基础） ============== adb shell input tap 500 1200 # 点屏幕坐标(500,1200) adb shell input swipe 200 600 800 600 300 # 左→右滑动300ms adb shell input keyevent 4 # 按返回键(keycode 4) adb shell input text "Hello+Navigation" # 输文字 (空格用+代替) # ============== 性能类 ============== adb shell dumpsys meminfo com.fc.navi # 看导航APP内存 adb shell dumpsys cpuinfo | head -10 # 看CPU占用 adb shell dumpsys batterystats # 耗电详情 adb shell top -m 10 # 前10高CPU进程 # ============== 抓崩溃/ANR ============== adb shell ls /data/anr/ # 看ANR文件(应用无响应) adb pull /data/tombstones/ ./tombstones # 看tombstones(native崩溃) # ============== 车载特有 ============== adb shell dumpsys car # 看汽车服务状态(AAOS特有) adb shell dumpsys power # 看电源/休眠状态 adb shell cmd car_service check-canbus # 检查CAN总线(AAOS)

第4章 · Jira 项目管理工具（Bug/需求/用例追踪）

4.1 Jira是什么？和测试工程师的关系？

通俗话：Jira = “大家用来记录需求/Bug/任务的共享表格+流程机”。每个Bug/需求/用例对应一张Jira卡片，卡片会在"待开发→开发中→待测试→测试中→已关闭"之间流转。

车载项目里Jira常见的Issue类型（每家公司名字略有不同）： ┌───────────────────────────────────────────────────────────────┐ │ Epic 大史诗 例："2026款 座舱域软件v3.0 全部功能" │ │ Feature 功能需求 例："支持CarPlay 车机屏全屏显示" │ │ Story 用户故事 例："用户点CarPlay图标能在3s内进入" │ │ Task 开发/测试任务 │ │ Sub-Task 子任务 │ │ Bug 缺陷 （测试工程师天天建的就是这种） │ │ TestCase 用例 (如果装了Zephyr/Xray等测试插件) │ └───────────────────────────────────────────────────────────────┘

4.2 车载Bug在Jira里的完整生命周期

一个Bug的"一生"（测试工程师每个状态都要会操作）： 测试发现Bug │ ▼ ┌────────┐ 开发说"不是Bug/复现不了" ┌──────────┐ │ NEW 新建 │ ──────────────────────────→ │ REJECTED │ └───┬────┘ └──────────┘ │ 开发确认/分给对应开发 ▼ ┌──────────┐ │ ASSIGNED │ 分给张三开发 └───┬──────┘ │ 开发改完了 ▼ ┌──────────┐ │ IN PROG. │ 开发中 └───┬──────┘ │ 开发提交代码/出软件包 ▼ ┌───────────┐ 测出来还是坏的 ┌───────────┐ │ RESOLVED │ ──────────────────→ │ REOPENED │ (回退) │ (FIXED) │ ←────────────────── │ 重开 │ └─────┬─────┘ 开发再次修完 └─────┬─────┘ │ 测试回归，果然修好了 │ ▼ │ ┌────────┐ │ │VERIFIED│ │ └───┬────┘ │ │ 版本正式发布了 │ ▼ │ ┌────────┐ │ │ CLOSED │ ←────────────────────────────┘ └────────┘ 测试工程师的关键动作： ├── 新建Bug (NEW→ASSIGNED要填好信息) ├── 回归验证 (RESOLVED→VERIFIED 或 REOPENED) └── 发布后关闭 (VERIFIED→CLOSED)

第5章 · Git 版本控制（管代码/管用例/管配置文件）

5.1 什么是Git？为什么测试要会？

通俗话：Git = “代码/文件的时光机+多人协作工具”，你和10个同事可以同时改同一个项目，Git会自动帮你们合并。

• 为什么测试也要会？
  1. 自动化代码(CAPL/Python/脚本) 要放Git
  2. 测试用例(Excel/MD) / 测试配置 (DBC/CDD) 要放Git
  3. 开发改完一个Bug，你要能git diff看他改了啥，针对性测

5.2 Git核心概念（5个就够）

┌───────────────────────────────────────────────────────────────┐ │ Working Dir 工作区 你电脑上能看到/编辑的文件夹 │ │ │ │ │ git add │ │ ▼ │ │ Staging Area 暂存区 存"我这次要提交的文件" │ │ │ │ │ git commit │ │ ▼ │ │ Local Repo 本地仓库 在你电脑的.git里，存历史版本 │ │ │ │ │ git push │ │ ▼ │ │ Remote Repo 远程仓库 公司的GitLab/GitHub/Gitee服务器 │ └──────────────────────────────────────────────────────────────┘ 分支 Branch： main/master 主分支，永远是可发布的稳定版本 develop 开发分支，大家合最新代码 feature/xxx 功能分支，张三开发CarPlay bugfix/IPC_123 修复Bug分支，修复IPC Bug 123 release/v3.0 版本分支，要发v3.0前封板

5.3 测试工程师日常Git命令（背这20个足够）

# ============ 第一次用：初始化 ============ git clone http://git.auto/test_scripts.git # 克隆远程仓库到本地 git config --global user.name "张三" # 设置名字 git config --global user.email "z3@auto.cn" # 设置邮箱 # ============ 日常工作流 ============ git checkout develop # 切到develop分支 git pull # 拉最新代码 (开始写代码前先拉!) # ← 然后你改了 a.capl b.py git status # ✨ 看改了哪些文件(红色=改了没加) git diff a.capl # 看a.capl具体改了啥行 git add a.capl b.py # 把这两个文件加进暂存 git commit -m "feat: 新增车窗防夹自动化 #123" # 提交到本地，写清楚 git push origin develop # 推送到远程develop分支 # ============ 分支操作 ============ git branch # 看本地有哪些分支 git branch new_feature # 建一个新分支 git checkout new_feature # 切到新分支 git checkout -b fix_123 # 建+切分支 (一步到位) git merge new_feature # 把new_feature合并回当前分支 # ============ 出问题的时候 ============ git log --oneline -10 # 看最近10条提交历史 (一行一条) git reset --hard HEAD~1 # 回退1个版本(⚠️没提交的修改会丢!) git stash # 临时存起当前修改 (去切分支救急) git stash pop # 把刚才存的修改放回来 # ============ 冲突解决 ============ # git pull冲突了，打开文件找到: <<<<<< HEAD 你的代码 ======= 别人的代码 >>>>>>> abc123 # 手动选留谁/合并，保存后： git add conflict_file.capl git commit -m "resolve conflict"

第6章 · CI/CD 持续集成/持续交付（Jenkins 入门）

6.1 CI/CD是什么？为什么车载也开始用？

通俗话：CI = “开发一改代码，机器自动拉下来编译+跑单元测试+出安装包”；CD = “出完包自动刷进台架跑自动化测试+出报告”。以前车载是"一周打一个包，测试跑一周"，现在SDV趋势是"一天打N个包，自动跑完给报告"。

典型的车载CI/CD流水线(Pipeline)长啥样： 开发Push代码到 feature 分支 │ ▼ ┌─────────────────────┐ │ ① Checkout Code │ Jenkins拉最新代码 └──────────┬──────────┘ ▼ ┌─────────────────────┐ │ ② Build/编译 │ 编译AUTOSAR/Android/Linux │ 出.a2l/apk/hex/bin固件 └──────────┬──────────┘ ▼ ┌─────────────────────┐ │ ③ UT单元测试 │ VectorCAST跑MC/DC覆盖率 └──────────┬──────────┘ ▼ ┌─────────────────────┐ │ ④ 静态扫描/Sonar │ MISRA规则检查/GAP └──────────┬──────────┘ ▼ ┌─────────────────────┐ │ ⑤ HIL自动化 │ CANoe/ETAS/dSPACE跑自动化 │ TestModule │ 发邮件"这个包通过率93%，3个失败" └──────────┬──────────┘ ▼ ┌─────────────────────┐ │ ⑥ 归档报告+固件 │ 放到制品库Artifactory └─────────────────────┘

6.2 测试工程师在CI/CD里做什么？

┌───────────────────────────────────────────────────────────────┐ │ 1. 写自动化用例 (CAPL/Pytest/Appium) │ │ 这些是流水线的核心资产，越多越快越稳，CI价值越大 │ │ │ │ 2. 维护TestModule / TestSuite │ │ 分好：冒烟套件(5分钟，每个包必跑) │ │ 核心套件(30分钟，每天包跑) │ │ 全量套件(2小时，每周跑一次) │ │ │ │ 3. 看CI报告定位失败 │ │ 每天早上第一件事：看昨天夜间构建失败的3个用例 │ │ 分类：环境问题 / 用例过期 / 真的Bug → Jira单 │ │ │ │ 4. 协助Jenkins Pipeline调试 │ │ 比如：加一个步骤 → "跑完自动化后把BLF/报告上传到网页" │ └───────────────────────────────────────────────────────────────┘

第7章 · ASPICE（车载软件过程标准）与测试

7.1 ASPICE最关心测试的3个过程（VDA Scope）

ASPICE VDA Scope = 6个过程组，3~9个基础PA (过程属性) 测试工程师会参与的3个关键PA： ┌───────────────────────────────────────────────────────────────┐ │ │ │ 1. SUP.1 质量保证 (QA) │ │ 你要做的： │ │ ├── 测试活动要有计划有记录 (测试计划、测试报告) │ │ ├── Bug要闭环：发现→修→验证→关闭 │ │ ├── 所有产出物要评审（评审记录要有签字/结论） │ │ └── 不符合项要做CAR (Corrective Action Request) 并跟踪关闭 │ │ │ │ 2. MAN.3 项目管理 (PM) │ │ 你要做的： │ │ ├── 每周给PM报：测试进度、剩余工作量、风险/阻塞 │ │ ├── 估算工作量：这100个用例预计要几人天 │ │ └── 变更走流程：需求加一条 → 走变更单CCB │ │ │ │ 3. SYS.2 系统需求测试 (核心！评估时必查) │ │ 你要做的： │ │ ├── 🗂️ 需求跟踪矩阵 RTM (Req Trace Matrix) │ │ 需求ID ←→ 用例ID ←→ 结果 ←→ BugID │ │ 每条系统需求，必须至少有1条用例覆盖 │ │ ├── 测试规范 (Test Specification) 要签字 │ │ ├── 测试记录 (Test Log) 每步都要有截图/BLF证据 │ │ └── 测试报告 (Test Report) 要有版本/结论/通过率/覆盖率 │ │ │ │ 4. SWE.4 软件单元验证 (UT) │ │ 5. SWE.6 软件集成验证 (IT) │ │ （这两个一般开发/专门验证团队做，测工程师了解即可） │ │ │ └───────────────────────────────────────────────────────────────┘

7.2 ASPICE评估时，测试工程师要准备什么？

ASPICE评审员来"审核你有没有按流程做"，你要拿出的"证据链"： 证据1：需求跟踪矩阵 (RTM) Excel Req_1234 | "车速0~250" | TC_IPC_001~015 | 全部PASS | Bug_99已关 | 证据2：测试计划 (Test Plan) 测试范围/人员/时间/环境/风险/策略 签字版 证据3：测试规范 (Test Spec) 每个用例有前置条件/步骤/预期结果，有需求ID，评审签字 证据4：测试记录 (Test Log) 每个用例执行的截图/BLF/结果，谁在什么时间测的 证据5：测试报告 (Test Report) 版本号、环境、执行数、通过/失败、遗留Bug、结论(通过？有条件通过？不通过？) 证据6：Bug生命周期记录 Bug从New→Fixed→Verified每个状态人/时间/附件全齐 一句话："做你所写，写你所做，留好证据"

第8章 · 附录

附录A：测试工程师自检清单（每周过一遍）

□ 本周测的用例，需求ID都填了吗？ (RTM要能追到) □ 发现的12个Bug，每个都附Trace/截图了吗？ □ RESOLVED状态的8个Bug，都回归了吗？ □ 跑失败的3个自动化用例，都分析原因登记了吗？ □ 本周的版本测试报告，按时发了吗？ □ 测试DBC/脚本，同步推到Git了吗？ □ 下周计划/风险，给PM/Leader同步过了吗？

附录B：常用工具速查

┌───────────────────┬──────────────────────────────────┐ │ 工具 │ 用在什么场景 │ ├───────────────────┼──────────────────────────────────┤ │ CANoe / CANalyzer │ 测CAN/CANFD/UDS (模块4/5必备) │ │ Vector VT System │ HIL台架接硬线信号 │ │ dSPACE / ETAS │ 高阶HIL(尤其智驾/动力域) │ │ TSMaster │ 国产廉价替代CANoe (新手友好) │ │ Wireshark │ 车载以太网/SOME/IP/DoIP抓包 │ │ Jira / Polarion │ 需求/Bug/用例管理 (ASPICE常用) │ │ Git / GitLab │ 代码/脚本/DBC版本控制 │ │ Jenkins │ CI/CD 自动编译+自动测试 │ │ Confluence │ 文档/测试报告/知识库 │ │ Python + Pytest │ 自动化脚本/工具脚本 │ │ Appium / uiautomator2 │ 座舱安卓UI自动化 │ │ PUTTY / MobaXterm │ SSH串口/远程登录ECU │ │ Beyond Compare │ 比较两份DBC/Bin/报告差异 │ └───────────────────┴──────────────────────────────────┘

🎉 恭喜！你已经看完【模块2 车载测试工程基础】

下一步建议：挑一个你感兴趣的域继续深入——

• 喜欢软件/交互 → 模块3【智能座舱域测试】
• 喜欢网络/底层 → 模块4【车载网络通信与诊断】
• 喜欢算法/场景 → 模块8【智能驾驶测试】