音视频测试实战——记音视频测试那些事

2020年一开年，疫情打乱了人们的节奏。买东西不能出门了，学校也不开学了，上班也home office了，在这种情况下，直播带货、在线教学、视频会议都被推上了风口浪尖。但是假如直播过程中突然听不到主播声音或者画面，抑或者声音和画面效果很差，这肯定是影响体验的。那么一款产品怎么才能在测试阶段尽可能发现问题和解决问题呢？通过这篇文章，期望让大家了解到音视频关注的指标，对音视频的评测过程有一个基本的了解。

本文主要从三个方面展开，一是音视频测试的目的，主要说音视频测试能解决的问题，比较通用；二是从音视频的角度介绍怎么做测试，包括测试维度、评价框架、整体结构和每一部分的具体内容；三是介绍这个框架的组成和实施过程中遇到的问题。

在内容展开之前，先简要介绍一下音视频通话的基本流程：

从这个简图中可以看出，整个流程分为三部分：发送、网络、接收。

发送端各个模块的功能分别是：采集，对应麦克风和摄像头硬件，也有可能是多媒体混音或者屏幕录制的内容；前处理，美颜大家都知道，3A可能不太熟悉，这里是针对音视频效果做处理的模块。

编码和解码是一对逆过程：编码完成后，打包发送到网络上进行传输，到接收端进行后处理和解码播放。

音视频测试的目的

对音视频通话的流程有了基本了解后，我们说回为什么要做测试。

这部分其实关系着我们为什么要做音视频评测以及做了评测后能回答什么问题。大家可能都会收到来自老板的拷问，你觉得这个特性的质量怎么样？能具备上线的条件吗？相信QA同学都碰到过，你可能不是音视频相关的质量保障同学，但是你肯定也或多或少遇到过类似的问题。

总的说来是四方面的问题，做的怎么样？有没有提高？提高多少？和竞品差距多少？总结起来是四个字——“知己知彼”，前面三项主要是回答“知己”的问题，最后一项“知彼”，其实也是建立在“知己”的基础之上。

“知己”主要是获取到基线数据，了解当前现状，这块是基础。在版本迭代过程中，基于这个数据来纵向比较版本间是提高了还是恶化了，提高或恶化了多少，是版本优化的参考。这些是对自己能力的了解，孙子兵法说，知己知彼百战百胜，我们不光要埋头干，还要抬头看看路，看看别人做的怎么样，因为最终体现竞争力的还是和竞品之间的差距。当然这里差距包含两层意思，正向的差距是优势，如果是负向的就是要改进了。

对应这些问题，我们分别需要提供哪些维度的数据作为辅助佐证呢？

要回答这4个问题，对于视频会议，我们列出了多个维度的评价指标，如上表所示。

会议效果主要从基础效果和其他增强效果两方面来展开，这也是视频会议底层能力的集中体现。基础效果包括稳定性（卡顿，闪退）、清晰度（音画清晰，可懂）和流畅度（入会时间过长，延迟大，卡顿）等；其他效果主要包括美颜和镜像、背景虚化等，还有像实用性、易用性、功能完备度等都是直接影响用户体验的点。

除此之外，还有一些影响性能和稳定性的特性如可靠性、安全性、可维护性、可移植性、运行效率、功能的适合性等，也都对用户体验有着不可忽视的影响，也值得关注。

本文主要针对音视频的效果展开。

如何进行音视频测试

评价维度已经定好了，那么这些维度的指标怎么去衡量呢？说到评价框架，包含了评测的数据分类和汇总，最终从这些数据的归纳和总结去回答前面的问题。

从对应不同的专项来区分，包括了音频测试、视频测试、QoS测试、性能和兼容性测试。基于这些维度适时地开展竞品对比测试，则可以比较全面的回答前述4个问题。

音频测试主要分为3块，主观测试、客观测试和POLQA测试。

主观测试主要是主观听，针对音频算法的优化调整，关注单讲、双讲场景下的回声、音量大小以及啸叫等异常现象，还有时延情况，音画同步状况；客观测试和POLQA主要测试记录一些客观指标，如音频参数（码率，时延，音量大小和POLQA分值等），这些维度通常要覆盖不同的网络和业务场景，针对不同的算法调整情况，还要考虑对不同设备的覆盖测试。

视频的评估大体也是分为3块，和音频测试类似，主要包括主观测试、客观测试和vMOS，另外针对CoDEC还增加了离线测试。

主观测试包括清晰度和流畅度，以及时延和音画同步测试。客观参数主要包括视频相关的参数（分辨率、码率、帧率、卡顿统计）以及MOS情况，CODEC离线测试中涵盖了PSNR和SSIM以及现今比较火热的VMAF指标。

QoS测试，并非一个单独的评测维度，更多的可以说是一个用户场景的覆盖测试。网络是业务的承载，然而实际用户的网络不可能完全理想，也没那么坏，最终的测试抓手其实还是音视频的评测指标，以此为基础，覆盖不同的弱网和极端网络，关注音视频效果的同时，关注拥塞控制、带宽探测、以及视频模型之间的配合和调整速度。这一部分输出网络相关的基线和极限能力。

前面提到的音视频评估及QoS评估，最终效果都体现在QoE上。什么叫QoE？说白了就是用耳朵听、用眼看。这部分直接体现在用户体验上，对于实时音视频场景来说，主要包括沟通的实时性也就是端到端时延（端到端时延，首帧时间）、视频的清晰度和流畅度、音频的清晰度和流畅度（对音频的可懂度直接相关）。

人不能总是低头走路，也要抬头看看天，产品也是一样。我们不光要实现自己的特性功能，也要看看对手们做得怎么样。因为最终决定产品好不好卖，客户买不买账，竞争力才最关键。

很多时候，如果明确的验收标准不太容易给出，同指标和竞品的对比结论是个不错的选择。如果能战胜对手，还是相对成功的。如果是落了下风，那要考虑一下如何优化了。事情到这里，看起来都很顺利了，测试的框架都齐备了，直接补充数据不就可以了吗？但是实际上还有一些问题需要解决。

评测的维度有了，数据指标也齐备了，接下来就是收集数据了，要收集数据就要准备一套稳定的测试环境。测试环境其实就是模拟了一套端到端的实时音视频通信系统，包含采集，包含网络，包含渲染和显示，也包含观察者（其实就是测试者），这其中的模块都会引入测试误差，这就是测试过程中的坑。

先说采集。同款摄像头几种不同摆放位置的视频画面无法相同，这只是采集引入误差的一种，其他如摄像头采集卡顿也会对最终的用户体验评价造成较大影响，导致无法确认是因为网络导致的卡顿还是采集的原因。

摄像头的不同摆放位置，对焦状态以及光线情况，摄像头的视角和景深对画面的范围和渲染表现影响最大。

采集带来的体验效果方面的恶化包括如下：

1采集卡顿；

2采集变色和模糊；

3过曝等现象导致的图像突变。

上图所示是不同型号摄像头接近相同的摆放位置的画面视角差异。

网络损伤后的视频和摄像头采集稳定的画面对比，说明卡顿不是因为摄像头引入，而是网络抗性不足导致。提到网络抗性，网络的不同拓扑结构和波动都会影响测试结果。网络自身的丢包和抖动都会引入额外的体验回退，也不利于问题的跟踪和复现，所以稳定统一的弱网模拟环境尤为重要。

基于此，引入了基于TC的弱网模拟方案（如下图所示）。

显示引入的误差主要由于显示设备的差异导致，从这个图中可以明显的看出不同显示器上同一幅图像的色温差别很大。

音视频最终的效果体现在端到端的体验上，端到端的体验最终肯定是体现在人的主观感受上，一千个读者心中有一千个哈姆雷特。观测者的个人视角，当时所处的环境以及个人的心情波动都会影响到主观效果的评判。

基于此，我们考虑把涉及到主观评价的场景都录一份对比（新老版本/竞品对比）的音视频数据，留待主观评测打分用，基于自验的打分平台，方便的进行线上打分。

基于以上测试框架以及问题，我们搭建了以下评测框架，消除了可能引入误差的一些模块。

1第一部分，摄像头（麦克风）+复用器，实现了同一路摄像头（麦克风）采集内容被多个PC设备复用的功能，这样每个PC上输入的摄像头内容完全一样，也完全同步；

2接收端的显示通过4K视频合路设备投射到一台大屏4K电视上，同时可以通过外部存储保存一份以供备份和后续的主观MoS环节；

3中间的网络和媒体服务器，把他们搭成私有的环境，单独一套测试环境使用，不受出口网络的影响，不受实验室到媒体服务器路径情况的影响，这套框架成本低廉，性价比较高。

相信这些工作做下来，从评测的维度出发，已经能够很好地回答老板们提出来的问题了。