|
|
图片引自微信公众号，扫码关注阅读原文一、需求阶段:测试左移到评审桌前
需求评审,很多测试同学把它当成”听会”
领导讲,开发记,测试坐角落刷手机。等散会了才发现:咦,这条需求到底怎么测?没人说得清
我给你的建议很直接:需求评审不是听会,是提问会。你坐在那张桌子前,手里得攥着三类必问的问题
功能边界类问题
边界不清,是车载座舱需求里最要命的一类问题
举个真实例子。语音唤醒需求只写了一句:”在音乐播放时可正常唤醒”。我问了三个字:降多少?
具体来说–音乐播到 80 分贝时,唤醒词要降到多少分贝才触发?是固定阈值,还是动态调整?需求文档一个字没提
|
· 语音唤醒在音乐播放时,输入音要降多少 dB 才触发? · 双屏异显时,副驾操作会不会干扰主驾显示? · 蓝牙电话接入时,导航播报是否压低?压到几成? |
异常处理类问题
车是个移动环境,断连、掉电、信号弱是常态。需求往往只写”正常流程”,不写”异常流程”
我印象深的一次:CAN 总线断连后,仪表该显示什么?是保持上一帧、显示”信号丢失”、还是直接黑屏?需求没定义,开发按自己理解做了黑屏。结果评审时安全员差点拍桌子
性能指标类问题
“车机要快”–这是句废话。快到什么程度,才是可测的指标。
我们团队要求每条性能需求都要带数字:冷启动几秒?应用切换响应多少毫秒?语音识别端到端延迟上限是多少?没有数字的指标,测试无法验收,等于没写。
可测性与验收标准类问题
这一条是很多老手也容易漏的。需求写得再漂亮,测不了也白搭。
比如”系统稳定”–怎么算稳定?连续运行多久不出错算稳定?再比如”界面流畅”–掉帧到什么程度算不流畅?我会把这类模糊词,逼着产品给出可观测、可量化的验收口径。测不了的需求,在项目早期就该打回重写。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
图片引自微信公众号，扫码关注阅读原文|
|
二、测试计划阶段:策略 + 资源 + 里程碑
需求摸清了,下一步是写测试计划。很多人把计划写成流水账,这是不对的。
一份能落地的测试策略文档,至少要有四块:目标、范围、准入准出、风险。少一块,后面执行就会乱。
测试策略文档结构
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
测试环境规划
座舱测试离不开三类环境,各有用途,别混着用。
|
· HIL 台架:信号可重复、可注入故障,适合功能与边界测试。 · 软件在环(SIL):纯软件仿真,早期无硬件时先验证逻辑。 · 实车:真实路况、真实噪声、真实用户,适合系统级与体验验证。 |
|
|
图片引自微信公众号，扫码关注阅读原文里程碑对齐
测试计划必须和项目的 DV / PV / SOP 三个大节点对齐。你的每一轮测试,都要卡在对应的里程碑前完成。
我习惯在计划里画一张资源甘特:哪几个人,哪几周,在哪台架上,跑哪批用例。人不是无限的,排期是测试经理的基本功。
|
|
风险登记表示例
策略里光列风险不够,要跟踪。我给每个高风险模块标严重度(S)和发生概率(P),乘出来排优先级。
|
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
三、测试设计阶段:用例设计方法论
到了设计阶段,才是测试真正的”手艺活”。
我的方法论是两路并进:基于需求的正向用例 + 基于风险的逆向用例。正向保证”该有的都有”,逆向保证”不该崩的不崩”。
正向用例:从需求到用例
把 RTM 里每条需求,翻译成可执行的步骤。这是基本功,不多说。
逆向用例:FMEA 驱动
逆向用例最有价值。怎么找”该测什么异常”?靠 FMEA(失效模式与影响分析)。
我带团队时,会拉一份 FMEA 表:哪个部件失效、后果是什么、严重度几分、发生概率几分。严重度高、概率中等的,优先补逆向用例。
|
|
|
|
状态机测试法
车机不是单一状态,它是状态组合。开机、熄屏、通话中、导航中、倒车中……这些状态两两叠加,组合爆炸。
我会画一张状态迁移图,把高频状态组合挑出来做用例。不追求全组合(那测不完),但核心路径和危险组合必测。
边界值与等价类
这两招在车机场景依然好使,只是要”翻译”成车载语境。
|
· 音量 0 到 30 级,重点测 0、1、29、30 四档。 · 车速 0、120、121(超速提示阈值)附近。 · 蓝牙连接数上限,测”上限”和”上限+1″。 · 隧道 GPS 丢失时长,测 1s、5s、30s 三档表现。 |
等价类划分与判定表
边界值管”点”,等价类管”面”。比如账号登录态,可分成”已登录/未登录/登录过期”三个有效等价类,再加”token 损坏”一个无效类。每类抽一个代表值即可,不必穷举。
当多个条件组合影响结果时,我用判定表。例如”倒车中 + 音乐播放 + 来电”三个条件,输出应该是”导航静音 + 音乐压低 + 来电全屏”,这种组合逻辑用判定表一眼看全,不容易漏分支。
用例评审 checklist
用例写完别急着跑,先过评审。我给团队的评审清单就几条:
-
每条用例有没有明确的预期结果? -
前置条件写全了吗(信号状态、账号登录、网络)? -
有没有覆盖异常分支? -
步骤能复现吗,别人照着做能跑通吗? -
和 RTM 对得上吗,有没有需求没挂用例?
|
|
测试用例模板(表格示例)
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
四、测试开发阶段:台架搭建与脚本准备
设计定稿,进入开发阶段。这阶段测试同学不”等人”,要自己把武器造好。
HIL 台架搭建
座舱 HIL 台架,核心是三件事:把车上的信号”搬”进实验室。
第一步,CANoe 配置：建工程、建仿真节点、配通道。这一步配错了,后面全白搭。
第二步,导入信号 DBC：DBC 是信号的”字典”。没有它,你发的每帧报文都是天书。导入后核对信号名、精度、偏移,别信自动映射。
第三步,故障注入模块：这玩意儿是逆向用例的命根子–断线、短路、位错误、延时,全靠它模拟。
|
|
图片引自微信公众号，扫码关注阅读原文自动化脚本框架
不是所有用例都值得自动化。我的判断标准:跑得多、稳定的、跨版本要回归的,才自动化。
框架我们用 Python + CANoe COM 接口,把”发信号-等响应-断言”封装成公共函数。新人只要填参数,不用碰底层。
我们团队习惯把框架分成三层:底层是总线驱动(发帧、收帧、故障注入),中层是业务关键字(如 wake_up、play_music),上层是用例脚本。分层后,DBC 换版本只动底层,上层用例不用改。
测试数据准备
三类数据最容易被忽略,却最影响真实性:
|
· 信号序列:典型工况的报文回放(城市、高速、隧道)。 · 用户画像:不同口音、不同使用习惯,喂给语音模块。 · 地图数据:复杂路口、高架、隧道,导航模块离不开。 |
|
|
五、测试执行阶段:三轮测试的节奏
执行阶段,座舱项目一般走三轮大测试:DV、PV、SV。节奏不同,侧重点也不同。
图片引自微信公众号，扫码关注阅读原文|
|
DV:设计验证
DV 看的是”功能对不对”。这个时候软件还糙,目标是把需求遗漏和逻辑错误尽早揪出来。
DV 阶段我特别在意一件事:发现需求里的坑。因为越往后改,成本越高。
|
|
PV:产品验证
PV 是主战场。全场景、性能、可靠性,一个都不能少。
性能上,我会盯冷启动、应用切换、语音延迟这三项硬指标。可靠性上,做长稳–连续跑 72 小时不关机,看有没有内存泄漏、有没有偶发卡死。
|
|
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SV:系统验证
SV 上实车,看的是”系统在真实世界里好不好用”。
这一步测试用例写得再漂亮,也不如真实用户的一通操作。我会安排内部同事当”小白用户”,不教他用,看他卡在哪。
每轮准入准出标准
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
六、缺陷管理:从发现到闭环
测试执行会产生大量 bug。管不好 bug,等于白测。
Bug 分级
分级不是为了好看,是为了排优先级。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bug 模板
一个 bug 写得清不清楚,直接决定开发能不能复现。我的模板强制包含这几项:
// Bug 模板(JSON 示例,字段带注释){"bug_id": "BUG-2024-0831", // 唯一编号"title": "音乐80dB时语音唤醒失败", // 一句话摘要"severity": "Critical", // Blocker/Critical/Major/Minor/Trivial"priority": "P1", // 处理优先级"module": "Voice/ASR", // 所属模块"precondition": { // 前置条件"sw_version": "IVI-2.3.1","hw_config": "HIL-Bench-A03","music_vol": 80 // 音乐音量 dB},"steps": [ // 复现步骤,有序"启动音乐播放,音量设为80dB","对着麦克风说唤醒词'你好小舱'","观察3秒内是否唤醒"],"expected": "3秒内唤醒,音乐压至30dB", // 预期结果"actual": "无响应,音乐持续播放", // 实际结果"evidence": { // 证据链"can_log": "attach://can_0831.blf", // CAN 日志"trace": "attach://trace_0831.log", // 系统 trace"screenshot": "attach://shot_0831.png"},"repro_rate": 0.9, // 复现率 0~1,偶发要标注"status": "Open" // 新建→分派→修复→验证→关闭}
缺陷跟踪流程
流程别搞太复杂,五步足够:新建 → 分派 → 修复 → 验证 → 关闭。
我特别强调”验证”这一步。开发说修好了,不算修好,测试复现不了才算。这一步卡不住,bug 会反复回潮。
Bug 趋势分析与燃尽图
每周我们都会拉一张趋势图,看三件事:新发现数、已关闭数、遗留数。
图片引自微信公众号，扫码关注阅读原文|
|
怎么读这张图？盯三条线：新发现数应在中后期明显收窄（说明测试在收口）；已关闭数要跟上新发现数（修复产能够）；遗留数要单调向下（没有积压）。三者里任意一条背离，我们就开专项会。
还有个细节：修复引入的新 bug 数。如果开发为了赶工狂修，结果每修一个带出半个新的，遗留曲线会”锯齿”上扬。这种时候我会叫停，要求开发先稳住质量再继续。
|
|
七、版本交付与回归:上线前的最后一道关
测试和开发拉扯到尾声,进入交付环节。这一步最考验定力。
回归策略
回归不是无脑全量跑
怎么选档？给团队一条简单规则：动了底层驱动或中间件，走全量；只改某个应用层逻辑，走选择性；每周例行版本，能用自动化的就自动化跑。选错档的代价，要么是漏测，要么是白白耗掉两天台架。
|
· 全量回归:大版本、架构改动后,所有 P0/P1 用例重跑。 · 选择性回归:局部修改,只跑受影响模块及关联路径。 · 自动化回归:稳定用例脚本化,夜里跑,早上看报告。 |
发布前 checklist(20 项)
交付前,有一张必过的 20 项清单。少一项都不建议发版。
// 座舱版本发布前 Checklist(20 项,逐项打勾)// 状态:✅ 通过 / ❌ 不通过 / N/A 不适用// -- 功能完整性 --[ ] 1. 所有 P0/P1 用例执行完毕且通过[ ] 2. 遗留 Critical 及以上缺陷数为 0[ ] 3. 遗留 Major 缺陷已评审并签字接受[ ] 4. 需求追溯矩阵覆盖率为 100%(无未覆盖需求)[ ] 5. 上一轮回归发现的回归问题全部关闭// -- 性能与稳定性 --[ ] 6. 冷启动时间达标(≤ 指标值)[ ] 7. 应用切换响应时间达标[ ] 8. 语音端到端延迟达标[ ] 9. 72 小时长稳无重启/无内存泄漏[ ] 10. 高低温箱内功能正常(温度边界)// -- 兼容与集成 --[ ] 11. 与仪表/网关信号交互验证通过[ ] 12. 蓝牙/CarPlay/HiCar 连接稳定[ ] 13. OTA 升级路径验证通过[ ] 14. 多账号切换数据隔离正确// -- 安全与合规 --[ ] 15. 驾驶中禁用手控的法规项已校验[ ] 16. 隐私数据脱敏与权限弹窗合规[ ] 17. 紧急呼叫/安全相关功能可用// -- 交付物与版本 --[ ] 18. 软件版本号、DBC 版本号一致且归档[ ] 19. 测试报告、缺陷清单、用例报告齐全[ ] 20. 已知问题清单已同步给售后与工厂
OTA 包验证流程
座舱现在基本都走 OTA。OTA 包验证,主要盯着三件事:
|
· 签名校验:包被篡改必须拒绝升级。 · 回滚测试:升级失败能否回退到上一稳定版。 · 增量更新:差分包能否在老版本上正确生效。 |
|
|
|
|
交付物清单
交付不是把软件丢出去就完事。我们归档四样东西:测试报告、缺陷清单(含已知问题)、用例执行报告、版本与配置说明。少一样,后面复盘没法做。
八、复盘与持续改进 + 行动清单
车交付SOP 了,测试的工作还没完。复盘,是把个人经验变成团队资产的关键一步。
项目复盘三个维度
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
三个要沉淀的库: |
最后说一句实在的。座舱测试没有银弹，这套链路也不是非得一字不差照抄。但你只要记住核心——早进场、问清楚、写明白、不放水，项目就不会太差。剩下的，是在一个个台架前、一台台实车里，慢慢磨出来的手感。
测试不是项目的守门员,是全程的陪跑者。从需求桌前,到交付关后,你的每一个问题、每一条用例、每一次不放行,都是在帮这台车,更稳地走到用户手里
