写点什么

优酷如何构建覆盖全网的播放白盒测试体系

  • 2020-02-18
  • 本文字数:3409 字

    阅读完需:约 11 分钟

优酷如何构建覆盖全网的播放白盒测试体系

一、背景

随着移动端业务的持续发展,移动测试技术也从最初偏黑盒的手工测试转变为基于各类 UI 自动化测试框架,开发适合自身业务特点的自动化 case,一定程度解放了测试人力。


播放器作为优酷的核心基础模块,为点播、直播、短视频等业务提供基础播放能力,播放质量保障过程涉及到众多业务方和大量回归适配工作,因此迫切需要自动化能力。经过一系列调研,我们认为传统的 UI 自动化方案在播放场景下存在一系列弊端:


无法有效覆盖各类播放策略的正确性和有效性;依赖相对固化的 UI 元素层级,与优酷快速迭代的节奏不 match;case 开发维护成本高,投入产出低;播放场景强依赖网络环境,UI 自动化在可控网络方面不够灵活。


为解决以上问题,优酷测试团队自研出一套基于 AFrame 的白盒自动化测试方案,并在此基础上构建出基于实验室环境的播测验证体系和基于外网环境的动态拨测体系。

二、工欲善则利其器,移动端白盒自动化方案

基于 AFrame 的白盒自动化测试框架由 5 个核心模块组成:AFrameSDK、AFrameServer、CaseClient、PKAT 和 AFrameService;其中 AFrameSDK 作为移动端侧模块,已集成到优酷 app,其余 4 个模块均可脱离移动端,支持单独部署,各模块通过 WebSocket 或者 Http 进行交互,整体交互关系如下:



  1. AFrameSDK:自动化测试的移动端入口模块,该模块包含与 AFrameServer 长连的 WebSocket Client,用于接收和解析 AFrameServer 下发的测试指令、调度执行、过程同步、数据收集和转发;

  2. CaseClient:通过改造 JUnit 测试框架为每个用例创建一个 WebSocket Client,向 AFrameServer 发送执行指令,并接收其中转的测试结果,完成行为分析和数据判断;

  3. AFrameServer:框架的数据“中转站”,监听来自 CaseClient 和 AFrameSDK 的连接请求,为 CaseClient 和 AFrameSDK 建立一对一的连接通道;

  4. AFrameService:用于用例管理、执行管理、设备管理、结果管理、配置和任务下发等;

  5. PKAT:播放测试结果校验和分析中心,是播放业务的“问诊台”,多端播放测试用例执行后,由其根据实际场景对 Log、VPM 埋点、接口数据等关键信息进行分析校验。

移动端自动化调度员:AFrameSDK

作为整个测试框架的入口模块,也是 5 个模块中唯一嵌入移动端的模块,AFrameSDK 承担着接口自动化调度员的角色。AFrameSDK 的主要工作流程如下:


  1. 与 AFrameServer 建立连接,等待 AFrameServer 下发执行指令;

  2. 接收执行指令、解析指令、驱动执行;

  3. 执行数据反馈,并发送回 AFrameServer。


AFrameSDK 接收到 AFrameServer 下发的指令后,通过对应的规则完成对指令的解析并驱动 app 执行。AFrameSDK 内置了若干通用的基础工具库供业务方使用,业务方也可以根据自身测试需求,定制化基于业务的测试驱动接口,目前已接入并具备定制化场景测试能力的业务方包括播放器、缓存、来疯等。


数据中转服务:AFrameServer

指令和数据是自动化测试的核心物料,AFrameServer 作为指令下发和数据传输的中心节点,承担着“搬运工”的角色,AFrameServer 将接其收到的连接请求分成如下几类:


  1. 移动设备端连接;

  2. 用例端连接;

  3. AFrameService 连接,用于设备同步、任务同步等;

  4. 功能扩展连接,如内外网穿透需求等。


AFrameServer 接收到上述连接请求后,根据分类和连接标识管理所有连接,当连接请求 A 需要和连接请求 B 进行通信时,需指定 B 的连接标识信息,AFrameServer 通过该连接标识为 A、B 提供数据转发服务。


基于 JUnit 的用例设计:CaseClient

用例设计是最重要的测试环节之一,用例设计的好坏和覆盖度直接决定了测试效果,为了提高用例设计和开发效率,对 JUnit 框架进行二次改造,封装改造后的用例设计 CaseClient 主要具备以下优势:


  1. 支持多用例实例执行隔离,尤其当用例与移动设备存在一对一关联关系时,可做到互不干扰;

  2. 支持根据执行过程动态控制用例执行,如播放失败后处理、Crash 后优雅终止;

  3. 支持可控化参数输入,如用于打通限速服务的可控网络输入、测试数据输入、执行参数控制等;

  4. 面向接口编程,无需要关注与 AFrameServer 间的交互逻辑。

结果管理与任务下发:AFrameService

AFrameService 作为测试启动入口,承担着“大管家”的角色,该模块提供了一系列接口供用户使用或测试平台调用,核心工作流程如下:


  1. 接收 AFrameServer 同步端设备信息;

  2. 向 CaseClient 发起测试用例任务执行命令;

  3. 执行完成后,CaseClient 将执行基础数据、执行过程数据回传至该模块,同时异步调用 PKAT 对结果进行分析和校验;

  4. PKAT 分析完成后将结果上传至该模块存档。

三、既要“播测”也要“拨测”

基于实验室环境的播测能力


基于实验室环境的播测能力主要包括,播放核心 topic 自动化 &常态化测试能力和播放器基础质量评估能力(包含:线下稳定性评估、基础性能评估、VPM 基础校验)。下面以智能档为例,简要介绍播测系统在实际业务中的落地实践情况:


  1. 常规测试方法:播放上层业务可以通过播放控制面板的 UI 交互获得视觉上的反馈,智能档区别于上层业务,它是基于多种算法去决策视频流中每个分片的清晰度档位,即使能够通过肉眼看出播放过程中的清晰度变化,也无法直观的确定该清晰度变化是否合理;所以我们通常通过智能档相关内核日志,确定每个分片的档位清晰度及其决策依据;测试时需要从日志中获取大量信息来判断整体决策过程是否正确,测试非常低效,同时大量的上下文信息切换,疏漏无法避免,智能档测试挑战重重;

  2. 测试痛点 &难点:智能档涉及算法众多,算法参数配置复杂(常用算法参数配置超过 20 余种);网络环境模拟难(限速、丢包、延时、网络秒级控制);校验标准量化难(算法逻辑复杂,每一次决策都有多种因素影响);日志量庞大(一集 40 分钟的视频需要关注上千个关键信息);

  3. 智能档播测解决方案:

  4. 第一步,用户行为模拟: AFrame 作为一个独立模块打包到被测 app,通过获取当前播放实例,以白盒方式调用播放器内部的各种 API,模拟用户对播放器的各种操作;


  5. 第二步,测试环境模拟:对于网络环境模拟,将路由器与一台主机 A 的网卡连接,通过网卡命令控制连接到路由器的移动设备网速、丢包、延迟。将 TCP Server 搭建到主机 A,任意一台 PC/MAC 均可通过限速 TCP Client 对网络进行秒级控制。限速网络 json 配置以_{“50”: [1500, 0, 0]}_为例,含义为 50 秒时,限速为 1500kbps,丢包为 0%,延迟为 0 毫秒;

  6. 测试配置方面,优酷 app 使用 APS 和 Orange 进行线上配置下发,常规测试方法中,我们通过扫码方式手动拉取配置 且在 app 重启后反复操作拉取。在播测方案中,通过 AFrame 提供的 APS 和 Orange Hook 能力,直接通过 API 接口完成对 APS 和 Orange 的配置,例如配置智能档使用特定的决策策略,只需在测试用例中加上_APSConfig.setAPSConfig(commandSender, “adaptive_bitrate”, “[“source_adaptive_mode=5”]”)_ 即可;

  7. 第三步,全流程自动化:目前基于 AFrame 测试框架和限速网络,已实现一键式执行智能档日常回归测试,用例执行结束后在播放器统一测试平台上生成测试报告。智能档播测流程如下所示:


基于外网环境的拨测能力

实验室网络和外部网络的最大区别是网络环境的复杂性和透明度,在实验室环境下通过网络控制来模拟各类场景,在确定的环境下执行播放测试任务,由于清楚的知道实验室网络各项指标,测试的预期结果相对比较明确;但由于播放链路的复杂性和多样性,仅在实验室环境无法有效覆盖真实情况,因此基于外网环境的拨测能力是对实验室播测方案的有效补充,在外部网络中,我们无法准确获取网络状态,因此我们结合自研的网络探测能力,获取不同域名下的网络带宽、时延、丢包率、连接速度等信息,通过计算其平均值、标准差、变异系数进行动态的 case 评估校验。从技术上来讲,外网拨测也是基于 AFrame 框架来实现的,通过 AFrameServer 外网部署,支持外部设备数据的接收和中转,结合网络探测能力,实现基于网络场景的动态拨测验证,外网拨测针对网络调度、播放链路相关的潜在问题具备较好的发现能力,由于篇幅有限并且核心链路和播测方案类似,这里不再展开赘述。

四、总结 &展望

优酷测试团队始终关注质量基本盘的有效性和完备性,在持续深化核心 topic 线下测试评估能力、守住质量基本盘的同时,形成了涵盖线下测试、冒烟播测、外网拨测的三级漏斗用例模型,测试同学为此持续提供逻辑自洽、基于用户和业务的思考过程,将三级漏斗用例模型间的联动共生通过平台化能力表达出来。


作者介绍


默研,阿里文娱资深测试开发工程师。


相关阅读


优酷播放测试体系构建及平台化整合方案


2020-02-18 10:301571

评论

发布
暂无评论
发现更多内容

分布式事务内存数据库--MemDB

hanaper

自定义View笔记

Changing Lin

9月日更

译介:《组装一台电脑9:精简》

姬翔

9月日更

复盘上次Redis缓存雪崩事故,中级Java工程师面试题

Java 程序员 后端

人类视觉神经科学助力音视频产业革命 - 弱网下的极限实时通信

声网

音视频 弱网下的极限实时视频通信

Nacos 开源、自研、商业化三位一体战略解读

阿里巴巴中间件

云计算 阿里云 微服务 云原生 nacos

一年数十万次实验背后的架构与数据科学

百度开发者中心

人工智能 架构 最佳实践 方法论 数据科学

如何让项目准时上线 - 续篇

石云升

项目管理 管理 引航计划 内容合集 9月日更

要不要换种方式开发软件?

鲸品堂

软件开发

上云迁移之路,如何选择适合方式?

浪潮云

云计算

中国移动5G消息开发者社区第三期直播课堂圆满结束,直播回放已上线社区!

5G消息

和腾讯大佬的技术面谈,BTAJ面试有关散列(哈希)表的面试题详解

Java 程序员 后端

什么?分布式事务现在不是都在用么?你还不会?

Java 架构 分布式 后端 计算机

和腾讯大牛的技术面谈,分布式系统中ACID和CAP有什么区别

Java 程序员 后端

OceanBase 源码解读(四):事务的一生

OceanBase 数据库

数据开发 oceanbase OceanBase 开源 OceanBase 社区版 OceanBase 数据库大赛

FLV格式解析

轻口味

android 音视频 RTMP 9月日更

为抢人才,字节架构师竟将42W字「2021大厂真题集」,上传GitHub

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

非科班杀进字节跳动,全靠GitHub公认最强的数据结构与算法笔记

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

MDEX市值机器人系统开发功能介绍

量化系统19942438797

交易所 市值机器人 MDEX

和阿里大牛的技术面谈,金三银四旗开得胜

Java 程序员 后端

读完这份阿里高质量性能优化全解,我的系统终于不再频繁瘫痪了

Java 阿里巴巴 编程 面试 金九银十

JavaScript进阶(上)

Augus

JavaScript 9月日更

堪比狗血剧!18名Java程序员凭阿里P8笔记,同时斩获大厂offer

Java 编程 面试 阿里 大厂

NoSQL数据库——Cassandra

hanaper

和阿里大牛的技术面谈,springcloud面试题汇集与答案

Java 程序员 后端

突击 22 天面进腾讯,给到 32K*14 薪!全靠这份阿里面试参考指南了

Java 程序员 架构 面试 计算机

基础+缓存雪崩+哨兵+集群+Reids场景设计,经验分享

Java 程序员 后端

Alibaba最新发布:2021最符合Java程序员的“学习路线”

Java架构师迁哥

和阿里大牛的技术面谈,字节跳动Java实习面试凉凉经

Java 程序员 后端

想要掌握未来嘛?这份腾讯高工撰写的Redis实战笔记就告诉你什么是未来!

Java 腾讯 面试 大厂 金九银十

关系型数据库如何存储树形结构?

王博

优酷如何构建覆盖全网的播放白盒测试体系_测试_阿里巴巴文娱技术_InfoQ精选文章