Article / 文章中心

天猫精灵音视频质保框架介绍

发布时间:2022-03-02 点击数:328
简介: 背景音视频做为天猫精灵的重要业务,可支持多态终端的爱家看护监控、音视频通话等场景,志在打造陪伴类心智,为用户生活增添便捷和美好。近一年业务经历了手机/音箱/云端/服务商等整体换血,在维持40万日活访问的基础上,打造新品卖点,提升性能耗时。音视频业务的质量保证,除了要考虑通用音视频指标,还要结合业务架构实际,从功能/稳定/性能/QoS等方面提升用户体验,了解行业位置。现将质保框架总结如下,希望能抛砖

背景

音视频做为天猫精灵的重要业务,可支持多态终端的爱家看护监控、音视频通话等场景,志在打造陪伴类心智,为用户生活增添便捷和美好。近一年业务经历了手机/音箱/云端/服务商等整体换血,在维持40万日活访问的基础上,打造新品卖点,提升性能耗时。音视频业务的质量保证,除了要考虑通用音视频指标,还要结合业务架构实际,从功能/稳定/性能/QoS等方面提升用户体验,了解行业位置。现将质保框架总结如下,希望能抛砖引玉,共同进步。

业务架构

猫精音视频的业务架构,主要分云端和客户端两部分:云端主要建立媒体流会话和会话推拉流;客户端分带屏/无屏音箱、手机app等,主要在各终端适配sdk,协调硬件资源,承载用户交互。

  • 云端:

主叫发起呼叫时,ai-iot-vision-platform开始对接RTC媒体服务商,注册媒体流会话通道:先获取本轮中的会话id/token等鉴权信息,再推送呼叫指令给被叫设备(单台或多台);某台被叫接听后,vision先推送接听指令到主叫,告知通道建立成功,再发送主被叫信息至RTC server,完成会话通道建立;

通道建立后,主/被叫端直接和下游RTC Server通信,RTC根据各端携带的会话id/token等,对比之前保存的主被叫信息,进行鉴权;鉴权通过后,端侧开始媒体帧的推/拉流,进行监控/音频/视频通话操作;通话挂断后,vision关闭本轮会话,同时向RTC发送指令关闭本轮通道,释放资源;


  • 客户端:

包括主叫和被叫方,按业务调用顺序从上至下,可分为3块:

  1. 按键/屏幕/语音/摄像头 App:最上层应用,控制各终端硬件操作,资源调配。根据业务优先级,需考虑各资源抢占的场景,避免异常;需考虑资源调用时序,避免无效调用,影响业务耗时;
  2. GenieRTC App:核心业务应用,按照业务时序分别和云端通信,调用上层硬件资源,启动下层sdk逻辑。因为逻辑复杂且需在各态终端兼容,容易出现状态机时序异常或者终端不匹配问题;
  3. 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%,分析问题主要为不同网络下,通话表现较竞品有一定差距,所以优先从网络环境出发,逐步提升弱网稳定性;同时由于偶现问题日志不全不好复现,故建立日志排查工具提升效率:

  1. 接通成功率和耗时较竞品有一定差距,需模拟用户操作,建立各网络环境下的基线指标,提升稳定性效率。故采用软件方式模拟弱网环境,在不同弱网级别上进行接通率和耗时监控,建立基线指标;
  2. 日志抓取过程较复杂(有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分平台;