第2章测试环境搭建

第2章：测试环境搭建

做语音系统稳定性测试，环境搭建是第一步，也是最容易踩坑的一步。我见过太多团队，测试还没跑起来，先被硬件驱动搞崩溃了。这一章，咱们就聊聊怎么把环境搭得既稳又准。

2.1 硬件环境：麦克风阵列与开发板

硬件选型，说白了就是选「耳朵」和「大脑」。麦克风阵列是耳朵，开发板是大脑。这两样东西没选对，后面的测试全是白费。

2.1.1 麦克风阵列选型

我个人习惯，先看麦克风的数量和布局。常见的阵列有：

2麦阵列：适合简单降噪，波束成形能力弱。我早期做智能音箱项目时用过，效果只能说「凑合能用」。
4麦环形阵列：360度拾音，家用设备标配。嗯，这个比较稳。
6麦或8麦线性阵列：远场拾音能力强，适合会议系统。我记得有一次测试8麦阵列，5米外轻声说话都能清晰捕捉，确实厉害。

选型时要注意一个关键参数：麦克风间距。间距太小，低频响应差；间距太大，高频空间混叠。一般4麦环形阵列的间距在30-50mm之间比较合理。

重要提示：麦克风阵列的同步性至关重要。如果各麦克风采样时钟不同步，波束成形算法会直接崩溃。我建议用硬件同步方案，别依赖软件同步。

2.1.2 开发板选择

开发板是算法的载体。常见的几款：

开发板	算力	内存	适用场景
树莓派4B	中等	2-8GB	原型验证、轻量测试
RK3588	强	8-16GB	复杂算法、多通道处理
XMOS XU316	专用DSP	1-2MB	低延迟、实时处理

我个人建议，做稳定性测试至少选RK3588级别。树莓派跑跑功能还行，一上压力测试就容易崩。我曾经用树莓派跑7x24小时测试，第三天就死机了，查了半天发现是内存泄漏。

避坑指南：开发板的供电一定要稳。我曾经遇到过，用USB供电跑测试，电压波动导致麦克风阵列间歇性丢数据。后来换了独立5V/3A电源，问题才解决。别小看供电，它往往是稳定性测试的隐形杀手。

2.2 软件环境：操作系统、驱动与SDK

硬件搭好了，接下来是软件。这部分我踩过的坑最多，咱们一个一个说。

2.2.1 操作系统选择

语音系统对实时性有要求。我推荐：

Linux (Ubuntu 20.04/22.04)：最常用，驱动支持好。我90%的测试都在Ubuntu上跑。
RT-Linux：对延迟敏感的场景，比如车载语音。普通Linux的调度延迟可能到10ms以上，RT-Linux能压到1ms以内。
Android：如果测试的是手机或智能音箱，Android也是常见选择。但要注意，Android的音频框架比较复杂，容易出问题。

嗯，这里要注意：内核版本。有些麦克风阵列的驱动只支持特定内核。我遇到过，5.10内核能正常工作的驱动，升级到5.15就报错了。所以，定好内核版本后，别轻易升级。

2.2.2 驱动安装与调试

驱动是硬件和软件的桥梁。安装驱动时，我习惯按这个步骤来：

确认硬件ID：用lsusb或dmesg查看设备是否被识别。
安装驱动源码：从厂商获取驱动，或者用ALSA（Advanced Linux Sound Architecture）通用驱动。
编译并加载：make && sudo insmod，然后检查/proc/asound/cards。
测试录音：用arecord -d 5 test.wav录一段，再用aplay test.wav播放。

如果录音没声音，别慌。先检查麦克风是否静音：amixer scontrols查看控制项，amixer sset 'Mic' 80%调音量。我遇到过最奇葩的一次，驱动加载成功，但录音全是静音，查了两小时发现是麦克风阵列的偏置电压没开。

小技巧：驱动装好后，用speaker-test -t sine -f 1000播放1kHz正弦波，同时用arecord录音。如果录到的波形是干净的，说明驱动没问题。如果波形有毛刺或削顶，检查增益设置。

2.2.3 SDK集成与验证

SDK是算法厂商提供的开发包。集成SDK时，我建议：

先跑官方demo：别急着改代码，先确保demo能跑通。我见过有人一上来就改参数，结果跑不起来，还以为是SDK有问题。
检查API调用链：初始化→配置参数→启动处理→获取结果→停止处理→释放资源。每一步都要确认返回值。
关注日志输出：SDK一般都有日志等级设置。调试时开到DEBUG级别，正式测试时降到INFO或WARN。

举个例子，某厂商的SDK初始化代码：

// 初始化SDK
int ret = sdk_init(&handle, config);
if (ret != SDK_OK) {
    printf("初始化失败，错误码：%d\n", ret);
    // 根据错误码查手册，别瞎猜
    return -1;
}
// 启动处理
ret = sdk_start(handle);
if (ret != SDK_OK) {
    printf("启动失败\n");
    sdk_deinit(handle);
    return -1;
}

你看，每一步都检查返回值，这是基本功。我见过太多人忽略返回值，结果程序跑着跑着就崩了，还找不到原因。

2.3 模拟用户场景的工装搭建

环境搭好了，怎么模拟真实用户场景？这是稳定性测试的核心。你不能指望人工对着麦克风喊7x24小时吧？

2.3.1 工装的基本组成

一套标准的工装包括：

音源播放设备：比如高保真音箱，用来播放测试语音。别用手机外放，音质太差，影响测试结果。
机械臂或转台：模拟用户移动。比如测试远场唤醒，需要让音源在不同角度、不同距离下播放。
环境噪声模拟：用另一套音箱播放噪声，比如空调声、电视声、人声嘈杂。我习惯用NOISEX-92数据库里的噪声样本。
自动化控制软件：用Python或LabVIEW控制整个流程。我一般用Python，灵活且好调试。

2.3.2 搭建步骤

我分享一下我的搭建流程：

固定测试设备：把开发板和麦克风阵列固定在消音室或半消音室。如果没有消音室，找个安静的房间也行，但要注意背景噪声。
布置音源位置：根据测试需求，在0度、45度、90度等角度放置音箱。距离从0.5米到5米不等。
配置自动化脚本：写一个Python脚本，循环播放测试语音，同时记录SDK的输出结果。比如：

import subprocess
import time

# 播放测试语音
def play_audio(file_path):
    subprocess.run(['aplay', file_path])

# 记录SDK输出
def record_result():
    # 这里调用SDK的接口获取结果
    pass

# 主循环
for i in range(10000):  # 跑10000次
    play_audio('test_voice.wav')
    time.sleep(0.5)  # 等待处理完成
    result = record_result()
    if result != 'expected':
        print(f'第{i}次测试异常：{result}')
        # 记录日志，方便后续分析

你看，代码很简单，但能跑出很多问题。我遇到过，跑到第500次时，SDK突然返回空结果，查了半天发现是内存碎片导致的内存分配失败。

关键点：工装搭建时，一定要考虑时序同步。音源播放和SDK处理之间要有明确的同步机制。我习惯用GPIO触发，或者用网络时间同步。否则，你录到的数据可能对不上时间戳，分析起来很麻烦。

2.3.3 常见问题与解决

工装搭建过程中，我遇到过不少问题：

音源播放延迟：用aplay播放时，有时会有几百毫秒的延迟。我改用gstreamer的低延迟模式，延迟降到10ms以内。
机械臂定位不准：转台用久了，步进电机丢步。我加了限位开关和校准流程，每次测试前先归零。
噪声样本循环播放：长时间循环播放同一段噪声，会产生听觉疲劳。我准备了10段不同的噪声，随机切换播放。

嗯，这里要提醒一下：工装的稳定性也需要测试。我曾经搭建了一套工装，跑了三天后，音箱突然不出声了。检查发现是功放过热保护了。后来加了散热风扇，问题才解决。

避坑指南：工装搭建完成后，先跑一轮冒烟测试。比如连续跑100次，看看有没有异常。如果100次都正常，再开始正式测试。别一上来就跑7x24小时，万一工装本身有问题，你浪费的是时间。

小结

环境搭建这件事，看似简单，实则细节很多。硬件选型要匹配场景，软件环境要稳定可靠，工装搭建要模拟真实用户。每一步都马虎不得。我见过太多团队，环境没搭好就开始跑测试，结果数据全是废的。所以，花点时间把环境搭扎实，后面会省很多事。

下一章，咱们聊聊测试用例的设计。怎么设计用例才能覆盖各种异常场景？到时候再细说。

📚 课程目录