26、音频测试框架：CTS/VTS音频测试、自动化测试框架、性能基准测试、稳定性测试方法

音频系统开发完了，怎么证明它没问题？

说实话，这个问题我早年吃过不少亏。代码写得再漂亮，跑不过测试就是零。Android的音频测试体系，说白了就是一套「质量门禁」。你写的AudioFlinger代码能不能进AOSP主线，得看CTS/VTS过不过。你做的手机能不能上市，也得看这些测试。

今天我就把这块的底牌翻给你看。

CTS音频测试：兼容性的硬门槛

CTS，全称Compatibility Test Suite。它是Google用来保证所有Android设备行为一致的「铁律」。

音频相关的CTS测试，主要覆盖这几个方面：

• AudioRecord/AudioTrack基础API：采样率、通道数、格式是否支持
• 音频路由：插拔耳机时，音频输出是否自动切换
• 音量控制：音量曲线是否符合规范
• 延迟指标：低延迟音频路径是否达标
• 多声道支持：5.1/7.1通道映射是否正确

我遇到过最坑的一次，是某个平台的音频HAL层在返回采样率时，把48000写成了48001。CTS一跑，所有音频录制测试全挂。查了两天才发现是驱动层一个宏定义写错了。你想想看，就一个数字的偏差，整台机器就废了。

VTS音频测试：HAL层的质量守门员

VTS是Vendor Test Suite，专门用来验证HAL层实现的正确性。它比CTS更底层，直接跟硬件驱动打交道。

音频VTS测试的核心模块包括：

测试模块	测试内容	常见失败原因
Audio HAL VTS	openInputStream/openOutputStream等接口	返回值错误、参数校验不严
Effect HAL VTS	音频效果器（EQ、混响等）的创建与配置	效果器ID不匹配、参数范围越界
Policy HAL VTS	音频策略的查询与配置	设备描述符格式错误

自动化测试框架：让机器替你干活

手动测试？不存在的。现代Android音频测试几乎全是自动化。

常用的自动化测试框架有：

• Trade Federation (TF)：Google官方测试框架，CTS/VTS都跑在它上面
• Android Test Station (ATS)：面向OEM的测试管理平台
• 自研脚本框架：很多大厂会自己写Python/Shell脚本做定制化测试

举个例子，一个典型的自动化音频测试流程是这样的：

# 伪代码：自动化音频录制回放测试
def test_audio_loopback():
    # 1. 启动录制
    recorder = AudioRecord(...)
    recorder.startRecording()
    
    # 2. 启动播放
    player = AudioTrack(...)
    player.write(test_sine_wave)
    player.play()
    
    # 3. 等待一段时间
    sleep(2)
    
    # 4. 分析录制数据
    recorded_data = recorder.read()
    snr = calculate_snr(test_sine_wave, recorded_data)
    
    # 5. 判断结果
    assert snr > 20, f"SNR太低: {snr}dB"

嗯，这里要注意：自动化测试的难点不在写脚本，而在「怎么判断结果对」。音频是模拟信号，录出来的数据跟原始数据不可能完全一样。你得定义好阈值——SNR多少算合格？THD+N多少算超标？这些参数我建议根据实际硬件能力来定，别照搬Google的默认值。

性能基准测试：量化你的音频系统

性能测试，说白了就是「跑分」。但音频系统的跑分跟CPU跑分不一样，它关注的是这些指标：

指标	含义	合格线（参考）
录制延迟	从麦克风采集到数据到达应用层的时间	< 30ms
播放延迟	从应用层写入数据到扬声器发声的时间	< 40ms
回环延迟	录制+播放的总延迟	< 60ms
CPU占用率	音频处理线程占用的CPU百分比	< 5%
内存占用	音频缓冲区占用的内存	< 10MB

我常用的性能测试工具是AudioFlinger自带的dumpsys：

adb shell dumpsys media.audio_flinger

这个命令会输出AudioFlinger内部所有线程的状态、缓冲区大小、延迟数据。我曾经靠这个命令定位过一个「播放卡顿」的问题——发现某个线程的缓冲区配置错了，导致每500ms就丢一次数据。

稳定性测试方法：让系统跑不崩

稳定性测试，我的理解就是「暴力测试」。你得想办法让音频系统在各种极端情况下不崩溃、不卡顿、不出杂音。

常用的稳定性测试方法：

• 长时间压力测试：连续播放/录制24小时以上
• 并发测试：同时打开多个音频流，反复切换
• 异常场景测试：插拔耳机、来电打断、低电量、内存不足
• 边界值测试：采样率设到最高/最低、缓冲区设到最小

我印象最深的一次，是测试「连续插拔耳机1000次」。跑到第873次时，系统突然静音了。查log发现是AudioPolicyService里一个引用计数溢出了。这种bug，正常使用根本碰不到，但稳定性测试就能把它揪出来。

知识体系总览

下面这张图，我把整个音频测试框架的脉络梳理了一下：

你看这张图就明白了：CTS、VTS、自动化测试、性能测试，最终都指向同一个目标——稳定性。它们不是孤立的，而是层层递进的关系。

好了，音频测试这块的内容就这些。记住一句话：测试不是为了证明代码没问题，而是为了发现代码有问题。心态摆正了，测试就不再是负担，而是你的安全网。

---

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