28、WebRTC 测试：自动化测试框架、模拟网络环境（Clumsy、NetEm）、QoS 压力测试
聊到 WebRTC 的测试，很多人第一反应是「写个 demo 跑一跑，能通就行」。嗯，我刚开始也是这么想的。直到有一次线上会议，用户反馈视频卡成幻灯片，我本地怎么复现都正常——后来才发现，用户用的是 4G 网络，丢包率 5%，而我测试环境是千兆光纤。
从那天起，我彻底明白了：不做网络模拟的 WebRTC 测试，等于没测。今天我们就来聊聊，怎么搭建一套靠谱的 WebRTC 自动化测试体系，把那些「偶发」的卡顿、花屏、断流，变成可复现、可定位、可量化的指标。
28.1 自动化测试框架：从手动到自动
WebRTC 的自动化测试，说白了就是让机器代替人，反复执行「建连→通话→挂断」这个流程，同时采集各种指标。我个人习惯用 Kite 或 Selenium WebDriver 来驱动浏览器，配合 pytest 做断言。
一个典型的自动化测试用例长这样：
def test_webrtc_connection():
# 启动两个浏览器实例
caller = Browser('chrome')
callee = Browser('chrome')
# 打开房间页面
caller.open('https://meeting.example.com/room/123')
callee.open('https://meeting.example.com/room/123')
# 等待 ICE 连接建立
assert caller.wait_for_ice_state('connected', timeout=10)
assert callee.wait_for_ice_state('connected', timeout=10)
# 验证音视频流
assert caller.has_remote_video()
assert callee.has_remote_audio()
# 采集统计信息
stats = caller.get_rtc_stats()
assert stats['packetsLost'] < 50 # 丢包数小于50
这里有个坑——浏览器自动化工具默认不暴露 WebRTC 内部统计。我曾经花了一整天，才发现需要注入一段 JavaScript 来调用 RTCPeerConnection.getStats()。所以，建议你在测试框架里封装一个 get_rtc_stats() 方法，把原始数据解析成可读的 JSON。
28.2 模拟网络环境：Clumsy 和 NetEm
为什么需要模拟网络环境？你想想看，WebRTC 的 QoS 机制（比如 FEC、NACK、码率自适应）都是在网络变差时才触发的。如果测试环境永远是「完美网络」，这些代码路径根本跑不到。
我常用的两个工具：Clumsy（Windows）和 NetEm（Linux）。
28.2.1 Clumsy：Windows 上的网络捣蛋鬼
Clumsy 是一个轻量级的网络模拟工具，可以拦截本机的网络流量，人为引入延迟、丢包、重排、带宽限制等。它的界面很直观，勾选对应的选项，拖动滑块就能生效。
举个例子，模拟 3% 丢包 + 100ms 延迟：
# 启动 Clumsy 的命令行模式
clumsy.exe --filter "udp and port 5000-6000" --drop 3 --lag 100
注意：Clumsy 默认拦截所有流量。我在项目中遇到过，开着 Clumsy 忘了关，结果整个系统的网络都变慢了。建议用 --filter 参数只拦截 WebRTC 的 UDP 端口范围，避免影响其他进程。
28.2.2 NetEm：Linux 上的网络模拟利器
NetEm 是 Linux 内核自带的网络延迟/丢包模拟工具，通过 tc 命令配置。它的精度比 Clumsy 更高，适合做精细化的 QoS 测试。
常用配置示例：
# 添加 100ms 延迟，±20ms 抖动
tc qdisc add dev eth0 root netem delay 100ms 20ms
# 添加 5% 丢包
tc qdisc change dev eth0 root netem loss 5%
# 限制带宽为 1Mbps
tc qdisc change dev eth0 root netem rate 1mbit
# 清除所有规则
tc qdisc del dev eth0 root
loss gemodel 参数。我曾经踩过这个坑，用默认的随机丢包测 FEC 效果，结果发现 FEC 根本没用——因为随机丢包太分散了，FEC 的冗余包全浪费了。
28.3 QoS 压力测试：让 WebRTC 在极限中跳舞
QoS 压力测试的目标很简单：把网络搞烂，看 WebRTC 还能不能撑住。我一般会设计以下几个场景：
| 测试场景 | 网络参数 | 预期行为 |
|---|---|---|
| 轻度劣化 | 丢包 1%，延迟 50ms | 视频流畅，偶有轻微马赛克 |
| 中度劣化 | 丢包 5%，延迟 150ms | 视频分辨率下降，音频仍清晰 |
| 重度劣化 | 丢包 15%，延迟 300ms | 视频卡顿明显，音频断续但不中断 |
| 突发丢包 | 每 5 秒连续丢 5 个包 | FEC 应能恢复大部分丢包 |
| 带宽限制 | 下行 500kbps | 码率自适应降至 300kbps 以下 |
每个场景跑 3 分钟，采集以下指标：
- 丢包率（packetsLost / packetsReceived）
- 往返时延 RTT（正常应 < 300ms）
- 视频码率（看是否自适应下降）
- 帧率（低于 15fps 算卡顿）
- 音频 MOS 分（可用
visqol工具评估）
我习惯把这些指标画成时间序列图，一眼就能看出哪个时间点出了问题。比如丢包率突然飙升时，码率是否及时下降——如果没下降，说明码率自适应算法有 bug。
28.4 知识体系总览
下面这张图，概括了 WebRTC 测试的完整链路：
28.5 实战：一次完整的 QoS 压力测试
假设我们要测试一个 WebRTC 视频通话应用，在 5% 丢包下的表现。我会这样做：
- 启动 NetEm：在服务端或中间路由器上设置 5% 丢包。
- 运行自动化脚本：两个浏览器建立连接，开始 3 分钟的视频通话。
- 采集统计：每 5 秒调用一次
getStats()，记录丢包、码率、帧率。 - 分析结果：看视频码率是否从 1Mbps 降到 500kbps 左右，帧率是否稳定在 20fps 以上。
- 对比基线：和 0% 丢包的结果对比，看 QoS 机制是否生效。
如果发现码率没有下降，但丢包率很高——那说明码率自适应算法没触发。我遇到过这种情况，最后发现是 RTCRtpSender.setParameters() 里的 degradationPreference 设置成了 maintain-framerate，导致编码器宁愿丢帧也不降码率。改成 balanced 就好了。
好了，这一章的内容就到这里。记住：没有经过网络模拟测试的 WebRTC 应用，上线就是赌博。下一章我们会深入 WebRTC 的拥塞控制算法，看看 GCC 和 NADA 到底是怎么工作的。