25、测试框架：CTS/VTS 测试、车载专项测试、模拟器测试、自动化测试框架
测试这件事，说实话，在车载开发里经常被低估。
很多人觉得功能跑通了就行，但Android Automotive OS不一样。你想想看，车机一旦出问题，不是闪退那么简单，可能影响安全。我见过不少项目，开发阶段风风火火，一到测试就卡壳，最后交付延期。
这一章，我就把车载测试的几大块给你捋清楚。CTS、VTS、车载专项、模拟器、自动化框架，咱们一个一个说。
核心观点：车载测试不是「补丁」，而是质量防线。CTS/VTS保兼容，专项测试保体验，自动化保效率。
25.1 CTS：兼容性的底线
CTS，全称Compatibility Test Suite。说白了，就是Google用来检查你的设备「够不够Android」的一套测试。
为什么重要？因为车机上的App很多是从手机生态来的。如果CTS过不了，第三方App可能闪退、界面错乱。我遇到过一家Tier1，CTS跑了一周没过，最后发现是某个系统服务改了返回值格式——这种坑，防不胜防。
我的习惯：每次修改framework层代码后，先跑CTS中对应的模块测试，不要等全部改完再跑。否则问题堆在一起，定位成本翻倍。
CTS的核心测试项包括：
- App兼容性：检查系统API是否完整、行为是否一致
- 权限模型：运行时权限、后台位置等是否合规
- 多窗口：车载场景下分屏、画中画是否正常
- 输入法：旋钮、触摸、语音输入是否兼容
跑CTS的命令其实很简单：
# 在车机上执行
adb shell am instrument -w com.android.cts/.runner.CtsTestRunner
# 或者用Tradefed统一调度
tradefed.sh run cts --plan CTS注意：CTS版本必须与Android版本匹配。Android 14的CTS不能在13上跑，反之亦然。我曾经因为版本不对，白跑了两天。
25.2 VTS：供应商的「体检报告」
VTS，Vendor Test Suite。这是Google为了推进Project Treble搞的。它主要测的是HAL层、内核、驱动这些底层东西。
你想想看，车机芯片五花八门——高通、瑞萨、恩智浦、TI。每家BSP都不一样。VTS就是确保不管底层怎么换，上层Android都能正常跑。
VTS测试的几个关键模块：
| 测试模块 | 测试内容 | 常见失败原因 |
|---|---|---|
| HAL测试 | Audio、Camera、GPS、Sensors等HAL接口 | HAL实现未完全遵循AIDL接口定义 |
| 内核测试 | SELinux策略、内核配置、设备节点 | SELinux规则过于宽松或缺失 |
| Treble测试 | 系统分区与供应商分区隔离性 | vendor分区引用了system分区的私有库 |
| 性能测试 | 启动时间、内存占用、中断延迟 | BSP优化不足，中断响应慢 |
跑VTS的命令类似：
tradefed.sh run vts --plan VTS避坑指南：我曾经遇到一个项目，VTS的SELinux测试一直不过。查了三天，发现是某个vendor进程的context写错了。记住：SELinux策略文件一定要和实际进程一一对应，别偷懒用通配符。
25.3 车载专项测试：手机没有的坑
CTS和VTS是Google要求的，但车载场景有很多Google没覆盖到的地方。这部分，就得我们自己来。
我把它分成几个维度：
25.3.1 多屏交互测试
车机至少两个屏——中控和仪表。高端车型还有HUD、后排娱乐屏。每个屏的分辨率、刷新率、触控方式都可能不同。
- 跨屏拖拽：导航从中控拖到仪表是否流畅
- 焦点管理：旋钮操作时，焦点在哪个屏上
- 显示同步：仪表和中控显示的时间、车速是否一致
25.3.2 音频通路测试
车载音频比手机复杂得多。导航、电话、媒体、语音助手，各有各的通路。
- 混音策略：导航播报时音乐是否自动降低音量
- 延迟测试：语音助手的「听到」到「回应」延迟
- 多区音频：前排听音乐，后排看视频互不干扰
25.3.3 CAN总线与车辆信号测试
车机要和车辆通信——车速、车门、空调、方向盘按键。这些走CAN总线。
- 信号映射：CAN信号是否正确映射到Android的Vehicle HAL
- 延迟测试：从按下方向盘按键到屏幕响应，要求<100ms
- 异常处理：CAN总线断开时，车机不能死机
25.3.4 稳定性与压力测试
车机不能像手机一样动不动重启。我见过一个项目，连续播放音乐12小时后，音频服务挂了。
- Monkey测试：随机事件注入，跑24小时以上
- 冷热启动：反复开关机，检查系统是否正常恢复
- 内存泄漏：用dumpsys meminfo监控长期运行后的内存变化
我的经验：车载专项测试最好在实车上跑，模拟器很多场景模拟不了。比如GPS信号、CAN总线、真实音频延迟。至少留两周的实车测试时间。
25.4 模拟器测试：开发者的「快车道」
实车资源有限，不可能每个开发者都配一台车。模拟器就是用来解决这个问题的。
Android Automotive OS的模拟器有几个特点：
- 多屏模拟：可以配置中控+仪表双屏
- 车辆信号模拟：通过VHAL模拟车速、车门等信号
- GPS模拟：设置虚拟位置，测试导航
- 音频模拟：模拟多通路音频输出
启动模拟器的命令：
# 使用Android Studio AVD Manager创建Automotive设备
# 或者命令行启动
emulator -avd Automotive_AVD -gpu host -memory 2048注意：模拟器不能替代实车测试。尤其是音频延迟、触控响应、CAN信号实时性，模拟器和实车差距很大。我建议：功能开发用模拟器，集成测试用实车。
25.5 自动化测试框架：解放双手
手动测试一次两次还行，但车机要跑几百个测试用例，手动搞不现实。自动化是必须的。
Android官方推荐的是Tradefed。它是一个测试调度框架，支持CTS、VTS、GTS等所有Google测试套件。
Tradefed的基本用法：
# 运行自定义测试
tradefed.sh run commandAndExit \
--template:template_name \
--primary-abi-only
# 查看测试结果
tradefed.sh run cts --plan CTS --skip-system-status-check除了Tradefed，还有一些第三方框架：
| 框架 | 特点 | 适用场景 |
|---|---|---|
| Tradefed | 官方、稳定、支持多设备 | CTS/VTS/集成测试 |
| ATX (Android TestX) | 开源、支持UI自动化、截图对比 | UI回归测试 |
| 自研框架 | 灵活、可定制、对接CI/CD | 车载专项测试 |
我个人的建议是：
- CTS/VTS用Tradefed，别折腾
- UI自动化用ATX或Espresso，写起来快
- 车载专项测试（多屏、音频、CAN）自研框架，因为场景太特殊
避坑指南：我曾经在一个项目里，用Tradefed跑车载专项测试，结果发现它不支持多屏截图对比。后来我们基于Python+ADB自研了一套框架，专门用来测多屏交互。记住：工具是死的，场景是活的。
25.6 测试流程：从开发到交付
最后，我分享一下我常用的测试流程：
- 开发阶段：模拟器+单元测试，快速验证功能
- 集成阶段：Tradefed跑CTS/VTS，确保兼容性
- 专项阶段：实车跑车载专项测试，覆盖多屏、音频、CAN
- 压力阶段：Monkey+稳定性测试，跑24-48小时
- 回归阶段：自动化框架跑全量用例，确保没有引入新问题
这个流程，我用了好几个项目，效果不错。你可以根据自己的项目节奏调整，但核心逻辑不变：先保兼容，再保体验，最后保稳定。
最后说一句：测试不是测试团队的事，是每个开发者的责任。你写的每一行代码，都可能影响车机的稳定性和安全性。跑一遍测试，花不了多少时间，但能省下后面几天的排查时间。
公众号:蓝海资料掘金营，微信deep3321