一、背景
随着移动端业务的持续发展，移动测试技术也从最初偏黑盒的手工测试转变为基于各类 UI 自动化测试框架，开发适合自身业务特点的自动化 case，一定程度解放了测试人力。
播放器作为优酷的核心基础模块，为点播、直播、短视频等业务提供基础播放能力，播放质量保障过程涉及到众多业务方和大量回归适配工作，因此迫切需要自动化能力。经过一系列调研，我们认为传统的 UI 自动化方案在播放场景下存在一系列弊端：
无法有效覆盖各类播放策略的正确性和有效性；依赖相对固化的 UI 元素层级，与优酷快速迭代的节奏不 match；case 开发维护成本高，投入产出低；播放场景强依赖网络环境，UI 自动化在可控网络方面不够灵活。
为解决以上问题，优酷测试团队自研出一套基于 AFrame 的白盒自动化测试方案，并在此基础上构建出基于实验室环境的播测验证体系和基于外网环境的动态拨测体系。
二、工欲善则利其器，移动端白盒自动化方案
基于 AFrame 的白盒自动化测试框架由 5 个核心模块组成：AFrameSDK、AFrameServer、CaseClient、PKAT 和 AFrameService；其中 AFrameSDK 作为移动端侧模块，已集成到优酷 app，其余 4 个模块均可脱离移动端，支持单独部署，各模块通过 WebSocket 或者 Http 进行交互，整体交互关系如下：
AFrameSDK：自动化测试的移动端入口模块，该模块包含与 AFrameServer 长连的 WebSocket Client，用于接收和解析 AFrameServer 下发的测试指令、调度执行、过程同步、数据收集和转发；
CaseClient：通过改造 JUnit 测试框架为每个用例创建一个 WebSocket Client，向 AFrameServer 发送执行指令，并接收其中转的测试结果，完成行为分析和数据判断；
AFrameServer：框架的数据“中转站”，监听来自 CaseClient 和 AFrameSDK 的连接请求，为 CaseClient 和 AFrameSDK 建立一对一的连接通道；
AFrameService：用于用例管理、执行管理、设备管理、结果管理、配置和任务下发等；
PKAT：播放测试结果校验和分析中心，是播放业务的“问诊台”，多端播放测试用例执行后，由其根据实际场景对 Log、VPM 埋点、接口数据等关键信息进行分析校验。
移动端自动化调度员：AFrameSDK
作为整个测试框架的入口模块，也是 5 个模块中唯一嵌入移动端的模块，AFrameSDK 承担着接口自动化调度员的角色。AFrameSDK 的主要工作流程如下：
与 AFrameServer 建立连接，等待 AFrameServer 下发执行指令；
接收执行指令、解析指令、驱动执行；
执行数据反馈，并发送回 AFrameServer。
AFrameSDK 接收到 AFrameServer 下发的指令后，通过对应的规则完成对指令的解析并驱动 app 执行。AFrameSDK 内置了若干通用的基础工具库供业务方使用，业务方也可以根据自身测试需求，定制化基于业务的测试驱动接口，目前已接入并具备定制化场景测试能力的业务方包括播放器、缓存、来疯等。
数据中转服务：AFrameServer
指令和数据是自动化测试的核心物料，AFrameServer 作为指令下发和数据传输的中心节点，承担着“搬运工”的角色，AFrameServer 将接其收到的连接请求分成如下几类：
移动设备端连接；
用例端连接；
AFrameService 连接，用于设备同步、任务同步等；
功能扩展连接，如内外网穿透需求等。
AFrameServer 接收到上述连接请求后，根据分类和连接标识管理所有连接，当连接请求 A 需要和连接请求 B 进行通信时，需指定 B 的连接标识信息，AFrameServer 通过该连接标识为 A、B 提供数据转发服务。
基于 JUnit 的用例设计：CaseClient
用例设计是最重要的测试环节之一，用例设计的好坏和覆盖度直接决定了测试效果，为了提高用例设计和开发效率，对 JUnit 框架进行二次改造，封装改造后的用例设计 CaseClient 主要具备以下优势：
支持多用例实例执行隔离，尤其当用例与移动设备存在一对一关联关系时，可做到互不干扰；
支持根据执行过程动态控制用例执行，如播放失败后处理、Crash 后优雅终止；
支持可控化参数输入，如用于打通限速服务的可控网络输入、测试数据输入、执行参数控制等；
面向接口编程，无需要关注与 AFrameServer 间的交互逻辑。
结果管理与任务下发：AFrameService
AFrameService 作为测试启动入口，承担着“大管家”的角色，该模块提供了一系列接口供用户使用或测试平台调用，核心工作流程如下：
接收 AFrameServer 同步端设备信息；
向 CaseClient 发起测试用例任务执行命令；
执行完成后，CaseClient 将执行基础数据、执行过程数据回传至该模块，同时异步调用 PKAT 对结果进行分析和校验；
PKAT 分析完成后将结果上传至该模块存档。
三、既要“播测”也要“拨测”
基于实验室环境的播测能力
基于实验室环境的播测能力主要包括，播放核心 topic 自动化 &常态化测试能力和播放器基础质量评估能力（包含：线下稳定性评估、基础性能评估、VPM 基础校验）。下面以智能档为例，简要介绍播测系统在实际业务中的落地实践情况：
常规测试方法：播放上层业务可以通过播放控制面板的 UI 交互获得视觉上的反馈，智能档区别于上层业务，它是基于多种算法去决策视频流中每个分片的清晰度档位，即使能够通过肉眼看出播放过程中的清晰度变化，也无法直观的确定该清晰度变化是否合理；所以我们通常通过智能档相关内核日志，确定每个分片的档位清晰度及其决策依据；测试时需要从日志中获取大量信息来判断整体决策过程是否正确，测试非常低效，同时大量的上下文信息切换，疏漏无法避免，智能档测试挑战重重；
测试痛点 &难点：智能档涉及算法众多，算法参数配置复杂（常用算法参数配置超过 20 余种）；网络环境模拟难（限速、丢包、延时、网络秒级控制）；校验标准量化难（算法逻辑复杂，每一次决策都有多种因素影响）；日志量庞大（一集 40 分钟的视频需要关注上千个关键信息）；
智能档播测解决方案：
第一步，用户行为模拟： AFrame 作为一个独立模块打包到被测 app，通过获取当前播放实例，以白盒方式调用播放器内部的各种 API，模拟用户对播放器的各种操作；
第二步，测试环境模拟：对于网络环境模拟，将路由器与一台主机 A 的网卡连接，通过网卡命令控制连接到路由器的移动设备网速、丢包、延迟。将 TCP Server 搭建到主机 A，任意一台 PC/MAC 均可通过限速 TCP Client 对网络进行秒级控制。限速网络 json 配置以_{“50”: [1500, 0, 0]}_为例，含义为 50 秒时，限速为 1500kbps，丢包为 0%，延迟为 0 毫秒；
测试配置方面，优酷 app 使用 APS 和 Orange 进行线上配置下发，常规测试方法中，我们通过扫码方式手动拉取配置 且在 app 重启后反复操作拉取。在播测方案中，通过 AFrame 提供的 APS 和 Orange Hook 能力，直接通过 API 接口完成对 APS 和 Orange 的配置，例如配置智能档使用特定的决策策略，只需在测试用例中加上_APSConfig.setAPSConfig(commandSender, “adaptive_bitrate”, “[“source_adaptive_mode=5”]”)_ 即可；
第三步，全流程自动化：目前基于 AFrame 测试框架和限速网络，已实现一键式执行智能档日常回归测试，用例执行结束后在播放器统一测试平台上生成测试报告。智能档播测流程如下所示：
基于外网环境的拨测能力
实验室网络和外部网络的最大区别是网络环境的复杂性和透明度，在实验室环境下通过网络控制来模拟各类场景，在确定的环境下执行播放测试任务，由于清楚的知道实验室网络各项指标，测试的预期结果相对比较明确；但由于播放链路的复杂性和多样性，仅在实验室环境无法有效覆盖真实情况，因此基于外网环境的拨测能力是对实验室播测方案的有效补充，在外部网络中，我们无法准确获取网络状态，因此我们结合自研的网络探测能力，获取不同域名下的网络带宽、时延、丢包率、连接速度等信息，通过计算其平均值、标准差、变异系数进行动态的 case 评估校验。从技术上来讲，外网拨测也是基于 AFrame 框架来实现的，通过 AFrameServer 外网部署，支持外部设备数据的接收和中转，结合网络探测能力，实现基于网络场景的动态拨测验证，外网拨测针对网络调度、播放链路相关的潜在问题具备较好的发现能力，由于篇幅有限并且核心链路和播测方案类似，这里不再展开赘述。
四、总结 &展望
优酷测试团队始终关注质量基本盘的有效性和完备性，在持续深化核心 topic 线下测试评估能力、守住质量基本盘的同时，形成了涵盖线下测试、冒烟播测、外网拨测的三级漏斗用例模型，测试同学为此持续提供逻辑自洽、基于用户和业务的思考过程，将三级漏斗用例模型间的联动共生通过平台化能力表达出来。
作者介绍：
默研，阿里文娱资深测试开发工程师。
相关阅读：
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论