模块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之前车要处在什么状态) │ │ 例KL15ON在扩展会话软件版本IPC_V2.3.1_RC3 │ │ │ │ 【复现步骤】(Step by Step编号每一步只做一个动作) │ │ 步骤1CANoe加载Test.dbc连接IPC台架 │ │ 步骤2发0x100报文 EngMsg.VehSpeed 198 km/h 周期100ms │ │ 步骤3持续发送20秒观察仪表指针 │ │ │ │ 【实际结果】(Actual Result越详细越好配截图/录屏/Trace) │ │ 指针指向 188 km/h 位置视觉拍照 CANoe Trace │ │ 截图: IPC_Speed_198.pngTrace: 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通不通 (CtrlC停) netstat -anp | grep 8888 # 看8888端口被谁占了 wget http://x.x/ota.bin # 下载文件 scp local.bin root10.0.0.5:/tmp # 本地/远端互传文件 (SSH) curl http://tsp.example.com/ping # ✨ 发HTTP请求测TSP接口 # 5. 进程/权限类 kill 1234 / kill -9 1234 # 干掉PID1234的进程 (-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 root192.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不好插 方法1USB直连(调试口) 1. 用USB线连电脑和座舱调试口 2. 座舱里开发者选项 → 打开USB调试 3. 电脑cmdadb devices → 看到设备号OK 方法2Wi-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 deviceOK 方法3ADB 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 # 实时看安卓日志 (CtrlC停) 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 HelloNavigation # 输文字 (空格用代替) # 性能类 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会自动帮你们合并。为什么测试也要会自动化代码(CAPL/Python/脚本) 要放Git测试用例(Excel/MD) / 测试配置 (DBC/CDD) 要放Git开发改完一个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 z3auto.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 ScopeASPICE 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、结论(通过有条件通过不通过) 证据6Bug生命周期记录 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【智能驾驶测试】 车载测试_车载测试工程基础教程
模块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之前车要处在什么状态) │ │ 例KL15ON在扩展会话软件版本IPC_V2.3.1_RC3 │ │ │ │ 【复现步骤】(Step by Step编号每一步只做一个动作) │ │ 步骤1CANoe加载Test.dbc连接IPC台架 │ │ 步骤2发0x100报文 EngMsg.VehSpeed 198 km/h 周期100ms │ │ 步骤3持续发送20秒观察仪表指针 │ │ │ │ 【实际结果】(Actual Result越详细越好配截图/录屏/Trace) │ │ 指针指向 188 km/h 位置视觉拍照 CANoe Trace │ │ 截图: IPC_Speed_198.pngTrace: 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通不通 (CtrlC停) netstat -anp | grep 8888 # 看8888端口被谁占了 wget http://x.x/ota.bin # 下载文件 scp local.bin root10.0.0.5:/tmp # 本地/远端互传文件 (SSH) curl http://tsp.example.com/ping # ✨ 发HTTP请求测TSP接口 # 5. 进程/权限类 kill 1234 / kill -9 1234 # 干掉PID1234的进程 (-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 root192.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不好插 方法1USB直连(调试口) 1. 用USB线连电脑和座舱调试口 2. 座舱里开发者选项 → 打开USB调试 3. 电脑cmdadb devices → 看到设备号OK 方法2Wi-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 deviceOK 方法3ADB 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 # 实时看安卓日志 (CtrlC停) 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 HelloNavigation # 输文字 (空格用代替) # 性能类 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会自动帮你们合并。为什么测试也要会自动化代码(CAPL/Python/脚本) 要放Git测试用例(Excel/MD) / 测试配置 (DBC/CDD) 要放Git开发改完一个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 z3auto.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 ScopeASPICE 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、结论(通过有条件通过不通过) 证据6Bug生命周期记录 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【智能驾驶测试】