引子
场景不是"想到了就算"——它需要被管理起来。
在一线汽车大厂的座舱测试团队，最常见的一幕：十几个测试工程师各自维护用例，同一个多媒体场景三个人写了三个版本——测试步骤略有差异、前置条件互相矛盾、预期结果各说各话。回归测试时没人知道哪个是"最新的正确版本"。
这是座舱测试场景管理的真实写照。场景，是自动化测试的上游资产——场景库乱，自动化再先进也只是"用高级手段执行错误用例"。
一、场景的结构化定义：先统一语言
场景管理的第一步不是选工具，而是统一"场景的语法"。我推动团队定义了六字段场景模板：
| 字段 | 说明 | 示例 |
|---|---|---|
| 场景ID | 全局唯一，含领域前缀 | CABIN-MEDIA-001 |
| 触发条件 | 场景进入的前置状态序列 | 车辆IGN ON → 中控启动完成 → 媒体应用在前台 |
| 操作序列 | 按时间序的原子操作列表 | 1. 点击USB音乐 2. 选择播放列表 3. 切换下一曲×3 |
| 验证点 | 可机器判读的断言 | cover_art ROI 非空；artist/title 字段匹配播放列表第4项 |
| 清理动作 | 场景退出后的环境还原 | 停止音乐播放 → 返回首页 → 清除播放队列 |
| 元数据 | 版本号、作者、关联需求ID、标签 | v1.2; REQ-MEDIA-023; 域：媒体/音频/USB |
核心设计原则：验证点必须可自动化判读。"显示正常"、"功能符合预期"这类模糊断言直接驳回——每个验证点必须对应一个具体的、可脚本化的检查动作。
同时，验证点的颗粒度也做了约束：一个场景最多 5 个核心验证点。超过 5 个的必须拆成子场景。这条规则挡住了一大票 "把所有验证写进一个场景" 的冲动。
二、版本管理：场景跟代码一样，需要 Git
场景会演进——需求变更了、UI 改了、功能砍了。我们踩过的坑：一个蓝牙配对场景，在三次 OTA 后有了三个不同的"正确版本"，分别适用不同车型年款，但没有任何版本标注。
解法不复杂：场景文件用 YAML 格式存入库，和自动化脚本放在同一个 Git 仓库。关键规则两条：
- 一个场景一个 YAML 文件，文件路径 = 场景 ID
- 场景字段变更走 MR 评审，变更说明写清关联的需求变更单号
这样做的直接收益：当某个版本的自动化用例执行失败时，我们能立刻追溯——是场景定义变了，还是代码实现变了，还是产品行为真的出了问题。三方对账不超过 5 分钟。
三、复用机制：场景不是越多越好
刚开始搭建场景库时团队热情很高，两周写了 200 多个场景。Review 时发现：约 40% 是重复或高相似场景——"空调温度调节 24 度"和"空调温度调节 26 度"是两个场景，除了温度值不同，其余完全一致。
我们引入场景参数化：
scene_id: CABIN-CLIMATE-001
template: climate_temp_adjust
parameters:
- name: target_temp
values: [18, 22, 26, 30]
- name: fan_speed
values: [auto, low, high]
一个参数化模板，通过参数组合展开为 12 个具体场景。场景数量从 200+ 精简到 120 个参数化模板，维护成本对半砍。
更关键的复用维度是跨车型复用。同一家车企的不同车型——中控尺寸、分辨率、OS 版本不同——场景操作序列的逻辑层应该共享，适配层做差异化。我们设计了"逻辑场景层 + 平台适配层"两层架构：
- 逻辑层：描述"点击媒体应用 → 选择 USB 音源"
- 适配层：将逻辑操作翻译成具体车型的坐标/元素定位/图像匹配模板
新增一款车型时，只需补充该车型的适配层配置，逻辑场景零改动。
四、覆盖率统计：从"感觉够"到"数据说话"
场景库建起来之后，第二个常见问题：怎么证明覆盖率够了？
我们定义三个维度的覆盖率：
| 覆盖率维度 | 计算方式 | 目标 |
|---|---|---|
| 需求覆盖率 | 有场景覆盖的需求数 / 总需求数 | ≥95% |
| 功能域覆盖率 | 座舱功能分解树中已覆盖的叶子节点比例 | ≥90% |
| 风险覆盖率 | 基于 FMEA 的高风险项中已覆盖比例 | 100% |
实现上不复杂：场景 YAML 的 metadata 里挂了 requirement_id 和 function_domain，需求覆盖率用脚本做两表 join 即可出报告。需求基线变更（新增、删除、修改）时自动标出"未覆盖"新需求，驱动场景更新。
五、场景驱动自动化生成：理想与现实的折中
最理想的状态——定义一个场景模板，自动化脚本自动生成。目前团队的部分实践：
- 简单 UI 操作（点击、滑动、文本输入）：场景模板 → 代码生成器 → 可执行脚本，覆盖率约 70%
- 复杂交互（多模态、时序敏感、跨进程验证）：仍需人工编写
生成器本质上是一个模板引擎：场景 YAML 中的 tap: media_app_icon 映射到 Page Object 的方法调用。当 UI 改版时，改 Page Object 而非改几百个场景文件。
但实话实说——代码生成这条路在座舱领域比互联网 App 难走得多。座舱 UI 的控件树结构远不如移动端规范，图像识别的定位逻辑又高度依赖界面状态，自动生成的代码鲁棒性远不如手工调试过的。所以现在策略是生成骨架 + 人工补逻辑：生成器产出 80% 的代码（操作序列、断言、清理），剩下 20%（匹配阈值调优、异常分支、时序等待）由工程师补充。
六、落地的正确节奏
场景库最容易犯的错是一上来就想建"万全之库"——定义完备的场景模型、覆盖所有功能域、打通全自动化链路。我们第一次推就栽在这个坑里——规划了两个月，评审了一轮又一轮，最后连第一版场景模板都没定下来。
第二次推换了策略：
- 第 1-2 周：选一个域（我们选了媒体播放），用六字段模板写 15-20 个场景，跑通"定义→自动化→回归"的完整链路
- 第 3-4 周：媒体域跑通后逐域推广（空调→导航→语音），每个新域复用已有的模板和脚本框架
- 第 2 个月：建覆盖率看板 + 参数化模板引入 + 代码生成器接入，场景库从"文档资产"升级为"工程资产"
一句话总结教训：先跑通一个垂直域的全链路，再横向扩展。 不要先横向铺场景模板定义再纵向接自动化——两者必须紧密咬合。
总结
场景库不是什么新鲜概念，互联网测试团队也在做。但座舱测试场景库有它的特殊性——功能域繁多（媒体/导航/空调/语音/ADAS 显示/车身控制，每个域的交互模式都不同）、跨车型适配复杂度高、图像识别带来的场景定义挑战远超传统的元素定位。
把场景库当成工程资产而非"测试文档"——版本管理保证可追溯、参数化控制数量膨胀、覆盖率做量化度量、代码生成降低维护成本——这才是值得投入的方向。
标签： [座舱质量] #自动化测试 #场景管理 #测试工程化
下一篇预告： 智能座舱系列至此收官。下期进入系列四——手机 APP 自动化测试，首篇「蓝牙 BLE 自动化深入：从 GATT Profile 到数字钥匙」。通信协议层到应用层的端到端自动化方案，含 Python bleak 实战。
