1、*性能测试*
（1）结论：
关于推流丢包率，我们上次就发现了这个问题，几乎没有丢包，也就意味着每次传输都保证了传输数据到达率，但是这个在弱网下就是一个好的表现吗？没有主动丢包的策略每帧数据都传输是否加剧了网了拥堵程度？所以这部分是否我们可以主动控制键丢包.这点不知道我理解得对不对（参考声网丢包xx %突然能够听清楚对方的话）或者（低端设备播放高清视频时有跳帧的说法）所以我们可以定制下自己的丢包策略 2.极限测试，主要是比较的舍我们sdk和行业水准。所以我们对sdk的测试过程提出了高的要求 连麦数（友商基本上号称十多路）分辨率，尤其在教育领域 共享屏幕的分辨率几乎远超360*640，其他帧率，码率也是同理。
（2）解释：
上行无丢包，说明推流到服务端是没问题的，只有一路上行，所以上行数据会好一些。下行有丢包，是因为下行拉4路流，平均码率600k，4路就是2.4M，加上重传等其他冗余包等，应该会比这个2.4M更大，下行拉流越多，带宽不够的情况下，丢包可能会更严重。这个的确也会是以后一个长期优化的方向点。
9连麦拉9路流，分辨率是144x192，大部分码率只有50K，9路加起来才450K，有一部分9连麦是250k码率，9路流加起来也才2.25M。所以今天的这个测试数据量应该是已经超过了APP 9连麦的场景。SDK会陆续支持大小流模式或者SVC去支持更多的并发拉流，能一定程度上更好地支持教育模式或者会议模式。
2、内存、cpu获取工具
3、多家RTC服务的MOS评测方法
（1）科普：影响音视频质量和稳定性的因素
- 网络
音视频对网络传输的依赖性越来越显而易见。网络状况对于音视频质量的影响是很直观的，如果音视频包在网络传输的过程中丢失，晚到，或者不均匀的到，就会造成我们常说的丢包，延时和抖动。随着网络上主机数量的不断增加，网络服务的需求将超过网络提供的能力，从而造成传输时延变化(抖动)、传输时延过大甚至引起分组丢失，也就是说出现了大塞车(网络拥塞)，这将对传输时延要求比较苛刻的实时音视频传输造成很大影响，从主观听感或视觉感受上造成声音或视频画面的卡顿和滞后，严重影响通话的质量和可懂度。在公共互联网上，特别是在远距离通信的情况下，如果缺乏足够的网络部署和丢包对抗技术，这种情况就会变得尤为明显。
此外，除了在传输层引起的丢包抖动，路由器，移动数据网络等问题也会引起丢包抖动。网络中存在很多的节点，如路由器、网关等。这些节点采用排队机制决定数据发放的顺序。如果在瞬间某节点数据排队较长，该节点就会采取丢弃数据包的方式保证节点的正常工作。即使没有被丢弃，经过较长的排队之后，这些数据包往往要花很长的时间才能到达目的地，由此就产生了网络的时延以及时延抖动。
- 设备
设备对于音视频质量的影响是相对隐性的，但是往往会起着决定性的作用。相较于苹果机，安卓机的问题就非常碎片化了。由于安卓机型太多，适配对和安卓机打交道的开发者来说往往司空见惯，比如受一些中低端机型性能影响，音视频在苹果机上测试觉得不错，但是到一些中低端的安卓机器上就问题百出。这类问题无论网络好坏都会产生，这时候就必须有音视频引擎的算法模块来做对应的算法适应和适配了，解决这类问题的技术门槛一般都是很高的。
- 物理环境
物理环境对音视频通话的影响不易察觉，但又不可忽视。例如，近场时候的尖锐杂音（啸叫）就是由于设备A的麦克风会直接收录到设备B的扬声器播放的声音，然后又会传回设备B播放出来，形成了一个正反馈回环导致的。只要分开一定距离通话或者静音掉其中一方就会消失。而本地身处嘈杂的环境下的听对方会更困难，对方听自己也会有受到噪声的干扰。
一、设置参数
在测试以前，要设置音视频参数:分辨率、码率、和帧率。设置好音视频参数以后，在测试过程中，参数要保持不变。
推荐使用下面两组参数分别进行测试：
| 参数设置 |
分辨率 |
帧率(fps) |
码率(kbps) |
| Profile1 |
640*360 |
15 | 800 |
| Profile2 | 540*960 | 20 | 1200 |
| Profile3 |
1280*720 |
25 | 2000 |
| Profile4（PC） | 1920*1080 | 25 | 4000 |
二、测试报告的设置条件如下:
| 测试对象 | XXX- SDK |
| 参数设置 | Profile1 |
| 测试设备 | iPhone6 |
三、评估指标
我们使用音视频技术方案的三个关键指标来评估其表现：延迟时间、流畅度、和清晰度。
| 延迟时间 |
采用客观的评估方法。以毫秒为单位，测量单向通讯的延迟时间。 |
| 流畅度 |
采用主观的评估方法，MOS 评分法，分数范围为 1 分至 5 分。 |
| 清晰度 |
采用主观的评估方法，MOS 评分法，分数范围为 1 分至 5 分。 |
延迟时间比较适合采用客观的评估方法，单位为毫秒，只需要测量单向音视频数据流从推流 端到拉流端所耗费的时间即可。这个方法十分直观，也广为接受。
流畅度和清晰度完全是用户体验的主观反馈，而且不流畅或者不清晰的技术原因有多源性的 特点，无法简单地通过技术指标来衡量。因此流畅度和清晰度比较适合采用主观的评估方法， 这里推荐用 MOS 评分法来评估。
MOS (Mean Opinion Score)是一种在通讯工程中用来评估 QoE(Quality of Experience)的 方法。它是一个有统计意义的数量样本空间的算术平均值。需要组建一个人数有统计意义的 测试团队，对测试对象的质量根据主观体验进行打分，分数范围为 1 分至 5 分，1 分最差， 5 分最好。建立打分结果的数量样本空间以后，计算其算数平均值，就可以得到 MOS 值。
MOS 作为一种主观的质量评估方法，被广泛的应用于音频、视频、和音视频的质量评估中。 对于 MOS 的评分梯度和标准，ITU-T 在 P.800.1 中有详细的方法建议。
MOS分采用人工评分的评估方法。主观MOS分采用ITU-T P.800和P.830建议书，由不同的人分别对原始语料和经过系统处理后有衰退的语料进行主观感觉对比，得出MOS分，最后求平均值。
MOS值=测试视频值+(5-视频源值)
(例如：评分人A给测试视频序号为1的视频评分为3分，同时给视频源的评分为4.5分，那么A实际最终给1号测试视频的分值应该是3.5分 。)
进行人工评分时打分可以打到小数点1位（例如4.6分）
为了简单和可操作期间，下面采用 ACR(Absolute Category Rating)来为 MOS 定义评分梯度:
| MOS 评分 |
描述 |
| 5 | Excellent，十分流畅，或者十分清晰 |
| 4 | Good，十分偶然有卡顿或者花屏，但不影响整体体验。 |
| 3 | Fair，偶有卡顿，或者偶有花屏/马赛克，但是还能接受 |
| 2 | Poor，卡顿，或者花屏/马赛克出现的频率较多，但是还算可用。 |
| 1 | Bad，完全卡住，或者画面不可辨，完全不可用。 |
在测试某个指标表现的时候，请保持其它方面的条件不变。
四、现网测试
- 为纯粹测试技术方案的真实表现，而不受其他因素干扰测试效果，因而没有使用专线， 不加任何外部辅助，在公共互联网上进行真实的测试。
- 建议测试区分开互联网使用的低高峰时段，有些测试时段和高峰时段分别测试。
- 流畅度和清晰度的评估采用主观的评估方法：MOS 评分法，最低 1 分，最高 5 分。
1. 跨运营商网络测试(中国国内)
不同的运营商网络之间是存在带宽瓶颈的。本测试的目的是评估RTC服务商在跨运营商网络情况下的表现。
| 跨网组合 |
延迟时间(ms) |
流畅度(MOS) |
清晰度(MOS) |
| 电信-联通 |
|||
| 电信-移动 |
|||
| 移动-联通 |
2. 跨国网络测试(全球)
在不同的国家之间的进出口光纤是存在带宽瓶颈的。本测试的目的是评估RTC服务商在跨国跨洋网络情况下的表现。(下图内容为示意数据)
| 用户A |
用 户 B( 国 外 |
国外省市 |
网络类型 |
分辨率/码 率/机型 |
流畅度 (MOS |
延迟 (ms) |
| 中国北京 |
美国 |
纽约 |
||||
| 中国北京 |
加拿大 |
蒙特利尔 |
||||
| 中国北京 |
阿联酋 |
迪拜 |
||||
| 中国北京 |
日本 | 东京 |
五、模拟测试
根据现网测试的结果和客户运营的反馈，添加了模拟测试的设计。模拟测试是通过网损设备模拟各种网络损伤的情形，在公司8点之前和23点之后进行测试。
1. 上行网络丢包测试
| 上行丢包率 |
延迟时间(ms) |
流畅度(MOS) |
清晰度(MOS) |
| 5% | |||
| 10% | |||
| 20% | |||
| 30% | |||
| 50% |
2. 下行网络丢包测试
| 下行丢包率 |
延迟时间(ms) |
流畅度(MOS) |
清晰度(MOS) |
| 5% | |||
| 10% | |||
| 20% | |||
| 30% | |||
| 50% |
3. 网络抖动测试
| 网络抖动 |
延迟时间(ms) |
流畅度(MOS) |
清晰度(MOS) |
| 50 毫秒 |
|||
| 100 毫秒 |
|||
| 200 毫秒 |
4. 带宽限制测试
假设当前推流的码率是 800k bps，对上行带宽进行限制到 500k bps，期望的结果是RTC服务商SDK 会自动调节码率来适应网络情况，码率会被调整到 500kbps 或以下。
| 限制带宽 |
码率 |
延迟时间(ms) |
流畅度(MOS) |
清晰度(MOS) |
| 不限制带宽 |
800 kbps -2000 kbps |
|||
| 限制带宽到 500k bps |
5. 如何观察延迟时间
1)登录https://miaobiao.51240.com，即可看到以毫秒为单位计时的时钟。这是为了 方便客户测试，注意:时钟页面经过调整，和下文截图不完全一致。
2)具体方案举例：准备两个 iPhone6 手机，在每个手机上都安装demo app。然后让两个个手机处于 连麦状态。在每个手机的 APP 界面上都可以看到当前的时间。 3)使用第三个手机拍摄这两个手机上的即构 demo app 的界面,捕捉连麦状态下的瞬间镜 头，即可看到音视频连麦双方的 demo app 界面上的时间差距。这个时间差距就是延迟时间。
