第28章集成测试

课程目录第28章集成测试

集成测试：端到端测试方案、自动化测试框架

说实话，做音频回声消除最怕什么？不是算法调不好，而是你辛辛苦苦调完的参数，一上真机就翻车。我见过太多团队，算法在PC上跑得漂漂亮亮，一集成到手机里，回声反而更大了。为什么？因为集成测试没做到位。

今天我们就来聊聊，怎么把AEC的集成测试做成一个靠谱的闭环。我个人习惯把测试分成三层：单元测试、集成测试、端到端测试。但今天重点讲后面两层——说白了，就是让整个音频链路在真实设备上跑起来，看看到底行不行。

端到端测试，我理解就是模拟用户真实使用场景。你想想看，用户打电话时，声音从扬声器出来，被麦克风重新采集，然后经过AEC模块处理——这个链路里任何一个环节出问题，回声就压不住。

我在项目中遇到过最典型的问题：AEC算法本身没问题，但音频驱动层的延迟抖动太大，导致自适应滤波器根本来不及收敛。所以端到端测试必须覆盖整个音频管道。

核心测试场景

嗯，这里要注意：端到端测试不能只在实验室做。我建议至少准备3-5台不同型号的真机，覆盖低端到高端。为什么？因为不同设备的声学结构差异太大了——麦克风位置、扬声器功率、机身共振频率，这些都会影响回声路径。

手动测试一次AEC效果，至少需要两个人配合：一个人说话，一个人监听。测完一轮下来，嗓子都哑了。所以自动化测试框架是必须的。

我常用的方案是这样的：

# 测试框架核心流程
1. 播放参考信号（远端音频）
2. 通过扬声器播放
3. 麦克风采集近端信号（包含回声）
4. AEC模块处理
5. 对比输出信号与期望信号
6. 计算ERLE、PESQ等指标

说白了，就是让机器代替人工去听、去判断。我早期做这个框架时，踩过一个坑：直接用音频文件做参考信号，但忽略了扬声器到麦克风的物理延迟。结果ERLE算出来特别高，一上真机就露馅了。

我的经验：自动化测试一定要包含延迟校准环节。先发一个脉冲信号，测量从扬声器到麦克风的实际延迟，把这个延迟补偿到参考信号里，再计算回声消除效果。否则你测出来的数据全是假的。

光说「听起来不错」不行，得有量化指标。我一般用这几个：

我曾经遇到过一个项目，ERLE测出来28dB，大家都觉得稳了。结果双讲场景下一测，近端语音被削掉了6dB——说白了就是AEC把说话人的声音也当回声给消了。所以单看ERLE是不够的，必须综合评估。

下面这张图是我个人比较推荐的测试框架结构：

这个框架的核心思路是：测试控制器统一调度，信号发生器产生标准测试信号，设备控制模块操作真机，数据采集模块抓取音频流，最后统一分析。我建议用Python写这个框架，因为音频处理库丰富，而且跨平台支持好。

坑一：测试信号太理想

我曾经用纯正弦波做测试信号，结果AEC表现完美。一换成人声，直接崩了。为什么？因为人声的频谱分布和正弦波完全不同，自适应滤波器对非平稳信号的跟踪能力才是关键。所以测试信号一定要用真实语音，最好包含不同性别、不同语速的样本。

坑二：忽略非线性失真

扬声器在大音量下会产生非线性失真，这些失真成分AEC是消不掉的。我遇到过测试时音量开50%，效果很好；音量开到80%，回声反而变大了。后来才发现是扬声器失真导致的。所以测试一定要覆盖不同音量等级。

我的建议：在自动化测试框架中加入「压力测试」模式。连续跑100次通话场景，每次随机改变音量、环境噪声、说话人，看看AEC会不会在某些极端情况下崩溃。我团队现在每次发版前都要跑一轮压力测试，至少能发现3-5个边界问题。

最后说一句：集成测试不是一次性的。每次修改AEC算法、调整参数、更新音频驱动，都要跑一遍完整的测试套件。我习惯把测试框架集成到CI/CD流水线里，每次提交代码自动触发测试。

嗯，这里有个小技巧：测试用例要分优先级。核心用例（双讲、单讲、噪声环境）每次必跑；扩展用例（特殊设备、极端场景）可以定时跑。这样既保证了质量，又不会让CI等待太久。

好了，集成测试这块就聊这么多。说白了，测试框架搭好了，后面调参、优化才有底气。不然你改了一行代码，都不知道是变好了还是变坏了——那才是最可怕的。

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