背景
音视频做为天猫精灵的重要业务，可支持多态终端的爱家看护监控、音视频通话等场景，志在打造陪伴类心智，为用户生活增添便捷和美好。近一年业务经历了手机/音箱/云端/服务商等整体换血，在维持40万日活访问的基础上，打造新品卖点，提升性能耗时。音视频业务的质量保证，除了要考虑通用音视频指标，还要结合业务架构实际，从功能/稳定/性能/QoS等方面提升用户体验，了解行业位置。现将质保框架总结如下，希望能抛砖引玉，共同进步。
业务架构
猫精音视频的业务架构，主要分云端和客户端两部分：云端主要建立媒体流会话和会话推拉流；客户端分带屏/无屏音箱、手机app等，主要在各终端适配sdk，协调硬件资源，承载用户交互。
-
云端：
主叫发起呼叫时，ai-iot-vision-platform开始对接RTC媒体服务商，注册媒体流会话通道：先获取本轮中的会话id/token等鉴权信息，再推送呼叫指令给被叫设备（单台或多台）；某台被叫接听后，vision先推送接听指令到主叫，告知通道建立成功，再发送主被叫信息至RTC server，完成会话通道建立；
通道建立后，主/被叫端直接和下游RTC Server通信，RTC根据各端携带的会话id/token等，对比之前保存的主被叫信息，进行鉴权；鉴权通过后，端侧开始媒体帧的推/拉流，进行监控/音频/视频通话操作；通话挂断后，vision关闭本轮会话，同时向RTC发送指令关闭本轮通道，释放资源；
-
客户端：
包括主叫和被叫方，按业务调用顺序从上至下，可分为3块：
-
按键/屏幕/语音/摄像头 App：最上层应用，控制各终端硬件操作，资源调配。根据业务优先级，需考虑各资源抢占的场景，避免异常；需考虑资源调用时序，避免无效调用，影响业务耗时；
-
GenieRTC App：核心业务应用，按照业务时序分别和云端通信，调用上层硬件资源，启动下层sdk逻辑。因为逻辑复杂且需在各态终端兼容，容易出现状态机时序异常或者终端不匹配问题；
-
RTC sdk：最下层的sdk，负责和RTC server通信进行媒体帧的推拉流，初期较多推拉流失败导致的黑屏或卡死。因为历史原因，要同时集成AliRtc和ARtc双sdk，和各自的server端通信，提供媒体流服务；
业务难点
综合业务特征和用户反馈，猫精音视频质保主要难点如下：
-
设备版本多 ：业务承载的端较多，底层系统或业务线各不相同，GenieRtc无法通用，需根据各端形态分别开发验证。主要设备版本如上图，可分为：
-
手机：Android；Ios；
-
带屏：公版；运营商；
-
无屏：Linux；RTOS；
各端升级更新均要做回归验证，由于业务发展更新版本多，财年三端共迭代近百次，需自动化手段解决大量的回归需求；
-
组合搭配多 ：需考虑主被叫中形态/系统/sdk/新老链路等组合，优化整合后涉及链路60+条；每个链路需考虑监控/视频/音频场景；各场景需考虑语音/屏幕/手势/按键等操作；再加上单用户多设备/摄像头占用/音视频焦点抢占等异常场景，组合后场景总量1000+；
-
异常时序场景 ：云端链路上vision应用和端上主叫/被叫共有3个状态机，有各自的时序定义且互相依赖，容易出现某状态机异常导致整条会话链路堵死，甚至会话无法消亡，资源占用无法再打，造成规模性故障。常见异常原因有：硬件性能/软件bug/网络状态等，均会导致端侧时序错误，云端会话建立困难。该类问题一般为偶现不好排查，需分析多端日志定位问题；
-
弱网问题多 ：根据2021.10～2022.1业务数据，平均弱网uv占比为36.81%（UV占比 = 统计触发弱网埋点设备数量 / 总设备数量），约1/3用户上行网络表现不佳，易出现监控或视频场景中的黑屏/挂断/卡顿/无声音等情况，工单数据中该类占比87%；弱网场景在持续优化中，QA也需要搭建高效的弱网测试环境，验证提升效果；
质量策略
音视频质量涵盖面广内容多，需根据业务实际明确质保范围，再选择适合的测试手段和标准。猫精音视频业务，用户主要使用场景为监控和通话，讲究互动的实时性，对时延/卡顿/黑屏等容错率较低；该场景同时使用上下行网络，对网络环境要求较高。所以在保留核心功能/性能/QoS的前提下，增加了不同网络的稳定性指标，保证业务稳定提升。
业务功能
业务场景相对确定，但主被叫因素变化多会导致分支较多。故使用单因素分析法，先只变化主被叫的形态/SDK/系统中单个因素，确定分支链路，再根据业务遍历每条分支的测试场景。列出核心功能测试矩阵如下：
此外，每条链路还需考虑的业务异常场景，包括但不限于：
-
单人多设备；
-
摄像头抢占；
-
进程非前台时表现异常；
-
会话通道占用；
-
断电/断网状态机时序异常；
-
音箱按键交互；
-
音箱资源抢占（内存/音视频焦点）；
所以功能验证场景达1000+，且涉及的端多，各端升级均需进行必要的回归，工作量较大。采用音视频回归实验室，自动化部分场景，减轻人工负担。
音视频回归实验室
appium是移动应用测试框架，可支持android/ios等系统，实验室中用来做音箱端（同为android系统）/手机端的控件操作和校验。参考功能矩阵，页面类测试场景（如监控类和视频/音频屏幕类）主要通过appium触发控件操作，再进行页面上的控件断言，当控件不可见时（如判断新老链路/画面全屏等），通过端侧的日志关键字断言；语音类测试场景（如视频和音频语音类）可通过网关层接口灌入，模拟用户语音发起通话，再进行页面的控件断言和端侧的日志断言。
实验室运行在已有的天梯平台，上传好测试脚本，平台启动任务后，云端下发任务至树莓派实验室，再分别控制主叫/被叫方操作和断言，最后平台化展示结果。
由于无屏音箱底层系统差异，实验室暂未涵盖无屏音箱场景。如下，实验室中主叫/被叫分别对应一台手机和一台带屏音箱，保证核心的功能场景。
当前app和带屏交互链路中，所有屏幕类正常场景均实现自动化，占核心场景60%。天梯平台中测试结果展示如下，
兼容性验证
不同设备的编解码能力会影响通话表现，该能力由于底层系统/资源配置不同，差异较大。实际场景中，音箱配置相对固定，手机机型更多变，工单中也更多会报出不同手机的异常表现（如手机画面颠倒；app未启动/手机黑屏时，手机推送异常等），所以参考线上手机使用量选择10款机型，基于云真机平台，验证在同样网络环境下，不同机型通话表现。
兼容性场景除覆盖主链路外，还需考虑app推送，摄像头抢占，进程非前台等场景。如下为云真机平台执行截图：
业务稳定
分析线上工单数据，通话超时/挂断/黑屏/卡断等问题约占87%，分析问题主要为不同网络下，通话表现较竞品有一定差距，所以优先从网络环境出发，逐步提升弱网稳定性；同时由于偶现问题日志不全不好复现，故建立日志排查工具提升效率：
-
接通成功率和耗时较竞品有一定差距，需模拟用户操作，建立各网络环境下的基线指标，提升稳定性效率。故采用软件方式模拟弱网环境，在不同弱网级别上进行接通率和耗时监控，建立基线指标；
-
日志抓取过程较复杂（有6步骤），部分sdk底层日志需单独打包才能抓取，若有遗漏得再次复现偶现问题；同时排查线上问题时，需要从多平台获取各端日志且时间不同步，存在学习成本。所以在雮尘珠平台上，增加性能基线平台和链路排查工具，提升测试和排查效率。
弱网模拟
参考业内指标和用户真实网络数据，制定网络分级策略如下。主要为网络带宽，丢包率，延时3个指标的设置。
为了具备通用性及成本控制，采用软件方式模拟弱网3个指标的设置。经过选型比较，采用树莓派+linuxTC方式来模拟网络损耗，可任一网络环境中配置，增加通用性。主要架构如下：
业务中用户网络为POOR及以下的约占1/3，所以弱网测试范围主要考虑正常/Poor/Bad三个网络级别，各自比较猫精和竞品在不同网络下的性能指标。如下在linuxTC中，配置poor网络。
LinuxTC中配置丢包和延时：
路由器中配置上行网络流量：
配置后，检查各配置参数是否生效：
稳定性基线平台
项目初期稳定性指标为人工测试，百次重复量大且计时有误差，所以基于totoro完成稳定性脚本，用户先本地配置网络环境和安装各端待测版本，再本地启动脚本开始监控/视频/音频多轮执行，监控屏端控件展示并拆解每轮端侧日志，得出耗时和通过率数据，保存数据和日志供后续排查，最后上传json文件至稳定性平台形成基线。
使用自动化脚本，指定测试类型和次数，运行后获取每轮端侧日志，整体运行结果和json文件，其中通话成功率主要从屏幕控件分析；通话耗时主要从日志关键字获取。
稳定性基线为前几次指标值均值，若测试数据低于基线则不满足发布标准，需分析日志排查定位。
链路排查工具
工具主要是从sls中获取云端/主叫/被叫的埋点日志，根据关键字整合，链路化展示状态机时序，便于快速定位偶现问题，避免无效的问题复现。平台输入账号信息，可查询用户下所有通话列表，进入会话详情，可查看云/主/被通话时序，高效定位问题原因。
各状态机正常通话时序参考如下。其中主叫无answer类应答时序，云端根据用户接听/拒绝操作，时序不同。
查询用户会话列表如下：
对比云端和端侧状态，定位通话中问题原因：
业务性能
基于业务现状，性能指标主要考虑核心业务场景下的cpu/mem/电量等资源消耗情况，建立性能基线和发布卡口。其中cpu和mem主要基于组内自研工具mobilePerf，电量基于Power Monitor。后续计划引入流量消耗，设备温度等指标保证音视频的用户体验。
QoS
当前监控的QoS指标包括：音频质量（MOS分），音视频延时，音画同步，视频清晰度，视频流畅度等。主要基于阿里云自动化评测平台实现，每个sdk大版本会有测试数据产出，以保证流媒体推送服务的质量推进。
后续规划
随着猫精音视频业务逐步发展、竞品差距逐步减小，质保逐渐从手工到半自动化，从功能扩展到性能稳定QoS等，但音视频内容多涉及广，测试指标/工具/策略都需要进一步优化和改进，以提升行业位置和用户体验：
-
测试指标：功能上增加异常场景，提升自动化率；性能上增加流量、电量、温度等测评指标和手段；硬件上增加设备编码、解码能力测评；
-
测试工具：加强网络测评，对不同运营商/wifi/地域的信号分级，为弱网指标提供参考；参考优秀经验，优化首帧时长计算方法从日志分析变为图像分析，更真实地反映端侧耗时；
-
测试策略：搭建音频质量和视频质量QoS体系：
-
视频质量：图像编解码时延方式测试画面延时；音画同步检测；基于ITU标准，搭建清晰度mos分平台；流畅度校验；
-
音频质量：实时音频3A处理校验；音频延时校验；基于有/无参考语音质量评估模型，搭建音频mos分平台；
