第27章车载稳定性测试

课程目录第27章车载稳定性测试

第27章车载稳定性测试：Monkey测试与CTS/VTS测试、稳定性监控（ANR/Crash）、日志分析与BugReport、压力测试与长稳测试

车载系统的稳定性，说白了就是「别死机、别卡顿、别出幺蛾子」。我在车厂干了这么多年，见过太多因为稳定性翻车的案例——导航卡死、倒车影像黑屏、语音唤醒没反应……这些问题在手机上将就一下还行，在车上可是要出大事的。

今天咱们就聊聊车载Android的稳定性测试。嗯，这部分内容比较杂，但每一条都是血泪教训换来的。

核心观点：车载稳定性测试不是「测完了事」，而是一个持续监控、持续改进的过程。你想想看，车机系统一旦交付，OTA升级可不像手机那么频繁，所以出厂前的测试必须做到位。

27.1 Monkey测试：暴力测试的艺术

Monkey测试，说白了就是让系统「随机乱点」。我刚开始做车载时觉得这玩意儿太low了，不就是个自动化乱点工具吗？后来发现，很多偶现的ANR和Crash，还真就得靠Monkey才能复现。

车载Monkey和手机Monkey不太一样。手机可以随便点，但车载有些区域是不能乱点的——比如你在导航界面乱点「恢复出厂设置」，那可就麻烦了。所以，车载Monkey测试需要做「安全区域屏蔽」。

# 车载Monkey测试常用命令
# 1. 基本Monkey测试（100万次事件）
adb shell monkey -p com.android.car --throttle 200 -s 12345 1000000

# 2. 带安全区域屏蔽的Monkey
adb shell monkey -p com.android.car \
  --pct-touch 50 \
  --pct-motion 20 \
  --pct-trackball 0 \
  --pct-nav 5 \
  --pct-majornav 5 \
  --pct-syskeys 0 \
  --pct-appswitch 10 \
  --pct-flip 0 \
  --pct-anyevent 10 \
  --ignore-crashes \
  --ignore-timeouts \
  --throttle 300 \
  -s 12345 500000

我的经验：Monkey测试一定要跑至少24小时，最好是72小时。我曾经遇到过一个问题，Monkey跑了48小时都没事，第49小时突然崩了——后来发现是内存泄漏累积到一定程度才触发的。

27.2 CTS/VTS测试：兼容性的硬门槛

CTS（Compatibility Test Suite）和VTS（Vendor Test Suite）是Google官方的兼容性测试套件。说白了，就是检查你的系统是不是「正经Android」。我见过一些车厂为了赶工期，偷偷跳过一些CTS测试项，结果后续OTA升级时各种兼容性问题冒出来，最后还得回头补课。

测试类型	测试范围	测试周期	通过率要求
CTS	Android Framework API、权限、多媒体等	约8-12小时	≥99.9%
VTS	HAL层、内核、Vendor接口	约4-6小时	≥99.5%
CTS-on-gsi	GSI镜像兼容性	约6-8小时	≥99.9%

CTS/VTS测试有个坑——它不能完全覆盖车载场景。比如车载特有的HUD显示、方向盘控制、空调控制等，CTS里根本没有。所以，我建议在CTS/VTS之外，还要补充「车载扩展兼容性测试」。

注意：CTS/VTS测试必须在「用户版本」上跑，不能用eng版本或userdebug版本。否则测试结果无效。我曾经见过有人用eng版本跑CTS，全绿通过，结果用户版本上各种问题——因为eng版本关闭了很多安全校验。

27.3 稳定性监控：ANR与Crash的捕获

稳定性监控，说白了就是「抓坏人」。ANR（Application Not Responding）和Crash是车载系统最常见的稳定性问题。我个人的习惯是，在系统里埋三个层次的监控：

应用层：通过UncaughtExceptionHandler捕获Java层Crash
框架层：通过Watchdog监控系统服务ANR
内核层：通过panic日志捕获内核Crash

// 车载稳定性监控核心代码片段
public class CarStabilityMonitor {
    private static final String TAG = "CarStability";
    
    // 监控ANR
    public void monitorANR() {
        // 注册ANR回调
        ApplicationThread.sANRCallback = new ANRCallback() {
            @Override
            public void onANR(String processName, String reason) {
                // 记录ANR日志
                Log.e(TAG, "ANR detected in " + processName + ": " + reason);
                // 触发BugReport
                dumpBugReport(processName, "ANR");
            }
        };
    }
    
    // 监控Crash
    public void monitorCrash() {
        Thread.setDefaultUncaughtExceptionHandler(
            new Thread.UncaughtExceptionHandler() {
                @Override
                public void uncaughtException(Thread t, Throwable e) {
                    // 记录Crash堆栈
                    String stackTrace = Log.getStackTraceString(e);
                    Log.e(TAG, "Crash in " + t.getName() + ": " + stackTrace);
                    // 保存Crash信息到本地
                    saveCrashReport(t.getName(), stackTrace);
                }
            }
        );
    }
}

避坑指南：我曾经在监控Crash时犯过一个错误——在UncaughtExceptionHandler里做了太多耗时操作，导致系统无法正常重启。后来我改成「先保存关键信息，再立即重启」，问题就解决了。记住，Crash处理要快，别拖泥带水。

27.4 日志分析与BugReport

日志分析是稳定性测试的重头戏。BugReport是Android系统提供的「全量日志」工具，包含了dmesg、logcat、kernel trace、进程状态等所有信息。我见过很多工程师拿到BugReport后一脸懵，不知道从哪看起。

我的习惯是「三步走」：

先看时间线：找到ANR/Crash发生的时间点，缩小范围
再看关键日志：重点关注「FATAL EXCEPTION」、「ANR in」、「Watchdog」等关键字
最后看堆栈：分析调用链，找到根因

# 常用日志分析命令
# 1. 生成BugReport
adb bugreport bugreport_$(date +%Y%m%d_%H%M%S).zip

# 2. 提取ANR日志
grep -r "ANR in" bugreport_*.txt

# 3. 提取Crash日志
grep -r "FATAL EXCEPTION" bugreport_*.txt

# 4. 查看系统服务状态
grep -r "ServiceManager" bugreport_*.txt

# 5. 查看内存使用
grep -r "MemTotal\|MemFree\|Cached" bugreport_*.txt

我的经验：车载系统的BugReport比手机大得多，因为车载有多个ECU、多个域控制器。我建议在BugReport里增加「车载专属标签」，比如空调状态、导航状态、车速信息等。这样分析问题时能更快定位到「当时发生了什么」。

27.5 压力测试与长稳测试

压力测试和长稳测试，是车载稳定性测试的「终极考验」。压力测试是「短时间内给系统最大负载」，长稳测试是「长时间运行看系统会不会老化」。

我参与过一个项目，压力测试时系统表现很好，但长稳测试跑到第7天时，导航应用突然卡死了。后来发现是某个后台服务的内存泄漏，7天才累积到临界点。这种问题，短时间压力测试根本发现不了。

测试类型	测试时长	测试场景	通过标准
压力测试	2-4小时	高负载并发（导航+音乐+空调+语音）	无ANR/Crash，响应时间≤500ms
长稳测试	7-14天	模拟用户日常使用	无ANR/Crash，内存无泄漏
冷热启动测试	1000次	反复开关机	启动时间≤30s，无异常
休眠唤醒测试	500次	模拟车辆休眠/唤醒	唤醒后功能正常

注意：长稳测试一定要在「真实温度环境」下跑。车载系统的工作温度范围是-40°C到85°C，我在实验室里跑长稳测试一切正常，结果夏天在新疆路测时，系统因为高温降频导致卡顿。后来我们增加了「温度监控」和「降级策略」，才算彻底解决。

27.6 知识体系总览

为了让你更直观地理解本章的知识结构，我画了一张图：

这张图把本章的核心内容串起来了。你可以看到，稳定性测试不是孤立的，Monkey测试、CTS/VTS、稳定性监控、日志分析、压力测试和长稳测试，它们之间是相互关联的。比如，Monkey测试跑出来的问题，需要通过日志分析来定位；而稳定性监控的数据，又能反过来指导压力测试的用例设计。

好了，关于车载稳定性测试，今天就聊这么多。记住一句话：稳定性不是测出来的，是设计出来的。测试只是帮你发现问题，真正解决问题还得靠扎实的代码功底和系统架构能力。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录