如何针对海外不同地区进行音视频自动化测试？丨Dev for Dev 专栏

近年来由于全球性的新冠疫情，世界各地对实时音视频的需求猛增。不同国家和地区由于经济发展、国家政策等原因，网络环境有很大不同，如果要做好音视频体验，就需要分地域进行音视频指标测试。但是不论是外包，还是云测，都无法满足我们对质量的要求。

本文将介绍在当前新冠疫情下，声网是如何对海外不同地区进行音视频自动化测试，并获得可靠的指标结果。

本文为「Dev for Dev 专栏」系列内容，作者为声网音视频实验室 Android 开发工程师胡大化。

01 传统音视频测试方法已不适用

以测视频延时为例，以前我们通常的做法是：首先找一个网络时钟，然后让发送端、接收端两台手机进行视频通话，并且用发送端手机拍摄这个时钟，然后接收端就看到网络时钟的画面。我们将网络时钟的时间，减去接收端手机显示的时钟时间，就是这一帧视频的延时。如图 1.1 所示：

■图1.1 当前帧延时为315ms

这种测试方法需要测试人员到现场去布置测试设备。然而在当前疫情环境下，很难派员工去海外出差进行实地场测。

02 为何不外包给海外测试团队？

你可能会想到既然不能派员工去海外出差，可不可找当地人帮忙，或者外包给当地专业的测试团队？

这种策略我们也考虑过。但音视频测试不同于一般的软件黑盒测试，在测试过程中实测用例很多，每个用例都要调不同的参数，外部测试团队很难达到我们平时测试时关注细节的程度，另外他们也不具备测试音视频所需要的专业知识。无法保证测试结果准确可靠。再者不同国家和地区由于语言时区等原因，协调的成本极高。

03 借助云测进行自动化测试

我们尝试使用云测供应商在海外不同地区部署的手机做测试，在这些手机安装测试程序，在国内通过远程桌面或自动化脚本控制手机进行音视频通话。

大的云测厂商如 Headspin 在国外几十个国家地区都有部署云测手机，但云测手机与真机不同，有很多限制：比如摄像头被遮住，就无法使用那些通过摄像头采集进行视频传输的测试用例了。因此我们需要设计一套不使用摄像头测音视频指标的方案。我们想到了通过自采集 YUV 视频的方式测试视频指标。

采用自采集 YUV 的方式，实现了两个云测手机之间视频传输，那怎么才能得到视频传输的性能指标呢？如延时、卡顿、码率、帧率等。使用 YUV 自采集的方式，没有独立的时钟源可以参考，测延时必须要解决两个手机对时问题。我们尝试通过 NTP 服务器或局域网对时两种方案。如果两个手机都在一个局域网下，通过局域网对时会非常精准，我们在本地实测两个手机之间交换数据包往返延时 rtt<10ms，而且在同一个局域网内上行和下行链路速度一样，那么实际对时偏差应该<2ms。这符合我们对精度的要求。

但是有的云测供应商两个手机之间无法通过局域网通信，比如 Headspin 就不可以。这时我们考虑用 NTP 方式对时。NTP 对时误差在几十毫秒，相比局域网大很多，如果超过 50ms，就会对我们测延时影响很大，我们希望对时偏差<50ms。如何做到这一点？通过查阅 NTP 官方文档得知，只要对时时 rtt 足够小，就可以实现。rtt 与对时偏差的关系如下图 1.2 所示（来源于 NTP 官网）:

■图1.2 NTP 对时中 rtt 与对时偏差的关系

从上面可以看出，只要往返延时 rtt 控制 100ms 以内，对时偏差-10ms<offset<10ms，这样两个手机的对时偏差不会超过 20ms，符合我们的要求。实际环境下能否做到 rtt<100ms 呢？通过实测我们发现完全可以做到。在上海通过阿里云的 NT P服务器（ntp.aliyun.com）对时，rtt 在 30ms 左右，很少超过 60ms。

在海外，以印度新德里为例，使用当地的 NTP 服务器（time.nplindia.org）rtt 也容易在 30ms 以下。因此我们只要使用当地或距离比较近的 NTP 服务器对时，精度都可以满足要求。在程序实现时我们可以多次对时，取 rtt<100ms 时的最小值。

解决了对时问题后，需要知道视频帧的发送时间和接收到的时间。我们可以在发送端把发送时间画在视频帧上，接收端把当前时间以浮窗形式盖在接收到的视频帧上，对接收端录屏，录像后的每一帧都有发送时间和接收时间，通过AI识别出来后，就可以计算出这一帧的延时。如图 1.3 所示：

■图1.3 打上时间戳的视频传输

除了延时外，接下来要计算帧率、码率和卡顿率。

帧率的计算比较简单，对接收端录屏后的视频取每一帧，如果这一帧上的数字相比上一帧有变化，我们就认为是不同帧，计算出帧数除以时间就是帧率,码率的计算我们可以通过抓包使用 Wireshark 分析，在音视频通话中视频数据都是以 UDP 协议传输，通过 Wireshark 可以很明显的区分出来。

卡顿率与时间相关,通常我们计算 200ms、300ms、600ms 这几种情况下的卡顿率，计算也比较简单，以 200ms 为例，只要前后不同帧的间隔超过了 200ms，就认为是卡顿，卡顿数除以总帧数就是卡顿率。

04 其他测试方法

相比云测，是否有更简单的测试方案呢? 我们想到了想到借助 SDK 自身的统计信息，RTC 方案提供商都会在给外部使用的 SDK 中集成详细且全面的统计信息，我们可以通过回调形式拿到。例如，通过声网的onRtcStats(IRtcEngineEventHandler.RtcStats stats)回调可以实现获取当前通话的音视频指标信息，更详细信息，可访问声网文档中心(docs.agora.io/cn）搜索了解。当然这种方式在别的方案不可用时不失为一种参考。

以上仅是一家之言，音视频测试有很多种方案，说不定你已有更加准确高效的方法。欢迎在声网开发者社区 rtcdeveloper.agora.io 分享出来，我们一起交流，共同进步！

关于 Dev for Dev

Dev for Dev 专栏全称为 Developer for Developer，该专栏是声网与 RTC 开发者社区共同发起的开发者互动创新实践活动。

透过工程师视角的技术分享、交流碰撞、项目共建等多种形式，汇聚开发者的力量，挖掘和传递最具价值的技术内容和项目，全面释放技术的创造力。