背景

音视频做为天猫精灵的重要业务，可支持多态终端的爱家看护监控、音视频通话等场景，志在打造陪伴类心智，为用户生活增添便捷和美好。近一年业务经历了手机/音箱/云端/服务商等整体换血，在维持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文件至稳定性平台形成基线。