超级详实的优酷质量保障秘籍

1播放专项3基于AFrame框架的播测和拨测系统4如何构建大一统的播放测试体系112大剧保障专项17优酷大剧全链路技术保障探索和实践183搜索算法专项24三层架构下的优酷视频搜索测试体系25人工智能的基石—算法数据质量344客户端50客户端质量评估体系51客户端打包构建阶段的质量评估解决方案——PreMTL55客户端性能评估解决方案——通用性能测试62优酷客户端埋点质量保障三步曲695服务端76基于热度链路推荐的引流对比测试776优酷研发效能83优酷研发效能新实践84视频算法如何为质量服务89序序优酷技术质量部负责优酷所有业务的质量保障工作，我们不仅需要面对快速的产品交付节奏，还要面对优酷特有的播放场景线下验证的复杂性以及设备碎片化带来的高昂适配成本。面对诸多挑战，我们构建起了覆盖线上线下全方位的质量保障体系，通过平台化服务化的方式来为研发过程赋能，提升整体研发效能，确保产品需求的快速交付，从而在激烈的行业竞争中为用户提供质量有保障并且用户体验好的产品，助力优酷业务快速奔跑。服务端客户端发布保障稳定性效能度量服务端客户端发布保障稳定性效能度量线上质量大剧保障专项用户体验专项播放专项搜索专项专项建设保障能力基础设施持续集成在这个系列中，我们将质量体系建设方面的经验和大家进行分享，不仅包括具有文娱业务特色的播放质量专项&大剧保障专项，还有客户端交付和服务端持续交付上的最佳实践，也包括研发效能平台和智能图像识别能力上的思考和建设。面对文娱技术质量，我们还在路上，新的一年我们希望在数据化、智能化方向上有更多的探索，感谢大家的关注。阿里文娱技术质量部高级技术专家平次2020.01.08播放专项基于AFrame框架的播测和拨测系统作者|阿里文娱资深测试开发工程师默研一、背景随着移动端业务的持续发展，移动测试技术也从最初偏黑盒的手工测试转变为基于各类UI自动化测试框架，开发适合自身业务特点的自动化case，一定程度解放了测试人力。播放器作为优酷的核心基础模块，为点播、直播、短视频等业务提供基础播放能力，播放质量保障过程涉及到众多业务方和大量回归适配工作，因此迫切需要自动化能力。经过一系列调研，我们认为传统的UI自动化方案在播放场景下存在一系列弊端：无法有效覆盖各类播放策略的正确性和有效性；依赖相对固化的UI元素层级，与优酷快速迭代的节奏不match；case开发维护成本高，投入产出低；播放场景强依赖网络环境，UI自动化在可控网络方面不够灵活。为解决以上问题，优酷测试团队自研出一套基于AFrame的白盒自动化测试方案，并在此基础上构建出基于实验室环境的播测验证体系和基于外网环境的动态拨测体系。二、工欲善则利其器-移动端白盒自动化方案基于AFrame的白盒自动化测试框架由5个核心模块组成：AFrameSDK、AFrameServer、CaseClient、PKAT和AFrameService；其中AFrameSDK作为移动端侧模块，已集成到优酷APP，其余4个模块均可脱离移动端，支持单独部署，各模块通过WebSocket或者Http进行交互，整体交互关系如下：1）AFrameSDK：自动化测试的移动端入口模块，该模块包含与AFrameServer长连的WebSocketClient，用于接收和解析AFrameServer下发的测试指令、调度执行、过程同步、数据收集和转发；2）CaseClient：通过改造JUnit测试框架为每个用例创建一个WebSocketClient，向AFrameServer发送执行指令，并接收其中转的测试结果，完成行为分析和数据判断；3）AFrameServer：框架的数据“中转站”，监听来自CaseClient和AFrameSD为CaseClient和AFrameSDK建立一对一的连接通道；4）AFrameService：用于用例管理、执行管理、设备管理、结果管理、配置和任务下发等；5）PKAT：播放测试结果校验和分析中心，是播放业务的“问诊台”，多端播放测试用例执行后，由其根据实际场景对Log、VPM埋点、接口数据等关键信息进行分析校验。1.移动端自动化调度员-AFrameSDK作为整个测试框架的入口模块，也是5个模块中唯一嵌入移动端的模块，AFrameSDK承担着接口自动化调度员的角色。AFrameSDK的主要工作流程如下：1）与AFrameServer建立连接，等待AFrameServer下发执行指令；2）接收执行指令、解析指令、驱动执行；3）执行数据反馈，并发送回AFrameServer。AFrameSDK接收到AFrameServer下发的指令后，通过对应的规则完成对指令的解析并驱动APP执行。AFrameSDK内置了若干通用的基础工具库供业务方使用，业务方也可以根据自身测试需求，定制化基于业务的测试驱动接口，目前已接入并具备定制化场景测试能力的业务方包括播放器、缓存、来疯等。2.数据中转服务-AFrameServer指令和数据是自动化测试的核心物料，AFrameServer作为指令下发和数据传输的中心节点，承担着“搬运工”的角色，AFrameServer将接其收到的连接请求分成如下几类：1）移动设备端连接；2）用例端连接；3）AFrameService连接，用于设备同步、任务同步等；4）功能扩展连接，如内外网穿透需求等。AFrameServer接收到上述连接请求后，根据分类和连接标识管理所有连接，当连接请求A需要和连接请求B进行通信时，需指定B的连接标识信息，AFrameServer通过该连接标识为A、B提供数据转发服务。3.基于JUnit的用例设计-CaseClient用例设计是最重要的测试环节之一，用例设计的好坏和覆盖度直接决定了测试效果，为了提高用例设计和开发效率，对JUnit框架进行二次改造，封装改造后的用例设计CaseClient主要具备以下优势：1）支持多用例实例执行隔离，尤其当用例与移动设备存在一对一关联关系时，可做到互不干扰；2）支持根据执行过程动态控制用例执行，如播放失败后处理、Crash后优雅终止；3）支持可控化参数输入，如用于打通限速服务的可控网络输入、测试数据输入、执行参数控制等；4）面向接口编程，无需要关注与AFrameServer间的交互逻辑。4.结果管理与任务下发-AFrameServiceAFrameService作为测试启动入口，承担着“大管家”的角色，该模块提供了一系列接口供用户使用或测试平台调用，核心工作流程如下：1）接收AFrameServer同步端设备信息；2）向CaseClient发起测试用例任务执行命令；3）执行完成后，CaseClient将执行基础数据、执行过程数据回传至该模块，同时异步调用PKAT对结果进行分析和校验；4）PKAT分析完成后将结果上传至该模块存档。三、既要“播测”也要“拨测”1.基于实验室环境的播测能力基于实验室环境的播测能力主要包括，播放核心topic自动化&常态化测试能力和播放器基础质量评估能力（包含：线下稳定性评估、基础性能评估、VPM基础校验）。下面以智能档为例，简要介绍播测系统在实际业务中的落地实践情况：1）常规测试方法：播放上层业务可以通过播放控制面板的UI交互获得视觉上的反馈，智能档区别于上层业务，它是基于多种算法去决策视频流中每个分片的清晰度档位，即使能够通过肉眼看出播放过程中的清晰度变化，也无法直观的确定该清晰度变化是否合理；所以我们通常通过智能档相关内核日志，确定每个分片的档位清晰度及其决策依据；测试时需要从日志中获取大量信息来判断整体决策过程是否正确，测试非常低效，同时大量的上下文信息切换，疏漏无法避免，智能档测试挑战重重；2）测试痛点&难点：智能档涉及算法众多，算法参数配置复杂（常用算法参数配置超过20余种网络环境模拟难（限速、丢包、延时、网络秒级控制校验标准量化难（算法逻辑复杂，每一次决策都有多种因素影响日志量庞大（一集40分钟的视频需要关注上千个关键）；3）智能档播测解决方案：第一步，用户行为模拟：AFrame作为一个独立模块打包到被测APP，通过获取当前播放实例，以白盒方式调用播放器内部的各种API，模拟用户对播放器的各种操作；第二步，测试环境模拟：对于网络环境模拟，将路由器与一台主机A的网卡连接，通过网卡命令控制连接到路由器的移动设备网速、丢包、延迟。将TCPServer搭建到主机A，任意一台PC/MAC均可通过限速TCPClient对网络进行秒级控制。限速网络json配置以{"50":[1500,0,0]}为例，含义为50秒时，限速为1500kbps，丢包为0%，延迟为0毫秒；99测试配置方面，优酷APP使用APS和Orange进行线上配置下发，常规测试方法中，我们通过扫码方式手动拉取配置且在APP重启后反复操作拉取。在播测方案中，通过AFrame提供的APS和OrangeHook能力，直接通过API接口完成对APS和Orange的配置，例如配置智能档使用特定的决策策略，只需在测试用例中加上APSConfig.setAPSConfig(commandSender,"adaptive_bitrate","["source_adaptive_mode=5"]")即可；第三步，全流程自动化：目前基于AFrame测试框架和限速网络，已实现一键式执行智能档日常回归测试，用例执行结束后在播放器统一测试平台上生成测试报告。智能档播测流程如2.基于外网环境的拨测能力实验室网络和外部网络的最大区别是网络环境的复杂性和透明度，在实验室环境下通过网络控制来模拟各类场景，在确定的环境下执行播放测试任务，由于清楚的知道实验室网络各项指标，测试的预期结果相对比较明确；但由于播放链路的复杂性和多样性，仅在实验室环境无法有效覆盖真实情况，因此基于外网环境的拨测能力是对实验室播测方案的有效补充，在外部网络中，我们无法准确获取网络状态，因此我们结合自研的网络探测能力，获取不同域名下的网络带宽、时延、丢包率、连接速度等信息，通过计算其平均值、标准差、变异系数进行动态的case评估校验。从技术上来讲，外网拨测也是基于AFrame框架来实现的，通过AFrameServer外网部署，支持外部设备数据的接收和中转，结合网络探测能力，实现基于网络场景的动态拨测验证，外网拨测针对网络调度、播放链路相关的潜在问题具备较好的发现能力，由于篇幅有限并且核心链路和播测方案类似，这里不再展开赘述。四、总结&展望优酷测试团队始终关注质量基本盘的有效性和完备性，在持续深化核心topic线下测试评估能力、守住质量基本盘的同时，形成了涵盖线下测试、冒烟播测、外网拨测的三级漏斗用例模型，测试同学为此持续提供逻辑自洽、基于用户和业务的思考过程，将三级漏斗用例模型间的联动共生通过平台化能力表达出来。如何构建大一统的播放测试体系作者|阿里文娱测试开发专家昙鸾、阿里文娱测试开发工程师庭婳一、背景从去年开始，为了提升播放业务的测试效率、完备性和有效性，优酷技术质量团队对播放测试方案进行了一系列的优化改造，自研出一套白盒自动化测试框架，并在此基础上构建出基于实验室环境的播测验证体系和基于外网环境的动态拨测体系，在测试提效方面已初见成效，但新的挑战也随之出现，具体为：1）随着播放测试能力的持续沉淀，各业务已形成了一套行之有效的topic维度的测试方案，播放测试能力急需流程化；2）除移动端外，播放在多端场景下的测试覆盖度较低，播放测试能力急需多端化；3）测试过程对于合作方不够透明，各方对测试标准和测试卡口理解存在不一致的问题，播放测试能力急需透明化。综上，针对流程化、多端化和透明化三大诉求，优酷播放测试提效进入了大一统阶段，包括三个统一：大一统的内核自动化测试框架、大一统的内核自动化测试服务和大一统的平台体系。二、大一统之内核自动化测试框架要实现大一统的播放自动化测试体系，首先要实现统一的自动化测试框架，主要面临以下几个问题：1）如何快速高效的支持各topic自动化case开发和执行；2）如何将内核自动化测试能力赋能到多端多场景（直播、OTT、IKU3）如何使内核自动化框架具备更好的扩展性，以支持流程化和平台化。为了实现播放各topic以及播放基础质量测试能力的全面拉通，以统一的方式支持播放业务测试用例的快速开发，最终实现统一地平台化收口，我们首先对各topic的通用测试场景、测试方案、个性化能力、通用工具集进行全面梳理，对相关API进行分层抽取，将新内核测试框架划分为4大模块：api、core、toolkit、testcase，整体结构设计如下所示：1.共性&个性化测试方案智能档的测试方法不再赘述，下面主要介绍一下PCDN以及卡顿topic的基础测试方法。1）PCDNtopicPCDN核心目标是缩减成本，减少CDN的流量峰值，在保证分片下载功能正确的前提上，PCDN重点关注覆盖率、分享率、浪费率、重复率等指标，因此测试需要重点关注PCDN在各种网络环境和用户播放行为下核心指标的正确性和合理性，PCDN核心测试数据可以结合VPM埋点以及PCDN接口数据获取。2）卡顿topic卡顿topic的主要关注点是各项卡顿优化的策略是否生效以及对播放体验的影响，如智能调度、慢切逻辑、网络探测等，卡顿核心测试数据可以通过VPM埋点、策略执行log以及ODPS历史埋点获取，除此之外，卡顿topic需要针对不同的网络场景和不同的用户播放行为进行组合验证。3）API抽取&工具集构建我们将网络控制、数据收集、数据分析、case校验作为核心，抽象出三大核心模块（case_checker、log_processor、network_controller将模拟用户行为、hookVPM埋点的AFrame客户端加入到工具集中，同样还将PCDN接口数据获取、ODPS查询、热剧查询、OSS上传等方法加入其中。三、大一统之播放测试服务为了让播放器自动化测试服务更好的赋能给OTT、IKU、直播等多端多场景业务，也为了更好的支持流程化和平台化测试，我们把本地的内核自动化测试框架演变为平台服务（PKAT并和播测&拨测体系结合起来，形成了一套完备的内核自动化测试新框架，并作为一套服务添加到播放测试平台链路中。整体链路包含以下四个部分：一是播放测试调度服务：包含二方平台打通、设备管理、任务分发、结果管理等；二是部署在外部网络的AFrameServer：数据“中转站”，监听各类连接请求并建立通道；三是与任务调度平台联动的CaseClient：用例执行入口；四是内核自动化测试服务：提供播放内核以及多端场景的验证服务。整体的技术细节如下图所示：四、大一统之平台收口优酷技术质量团队始终关注测试基本盘的有效性和完备性，在持续深化核心topic线下测试评估能力、守住质量基本盘的同时，形成了涵盖线下测试、冒烟播测、外网拨测的三级漏斗用例模型，测试同学为此持续提供逻辑自洽、基于用户和业务的思考过程，并且最终将三级漏斗用例模型间的联动通过平台化能力表达出来。播放测试平台为播放业务提供一站式标准化测试能力，包括用例管理、测试计划、功能测试、冒烟播测、外网拨测、大剧保障、多端赋能等能力，支持用例的可视化开发，支持用例完整生命周期的实时监控，并提供详细和专业的结果分析和测试报告，通过播放测试平台实现了本地测试、冒烟播测、外网拨测用例的打通，用例流转示意如下：播放器统一测试平台人工执行的功能测试用例本地自动化的功能测试用例家庭网络设备海川设备池+网络环境模拟家庭网络设备平台功能测试用例平台冒烟测试用例平台外网拨测用例1.系统设计播放测试平台采用分层设计结构，以增强平台的水平扩展能力，基础服务层由设备资源管理、用例管理、用例模板管理、测试计划管理、运行管理、报告管理等模块组成：1）设备资源管理：同步实验室以及外网测试设备资源信息，用例执行时指定相应测试设备；2）用例管理：提供用例信息的维护及权限管理，除传统的代码开发模式外，支持可视化的组件开发模式；3）用例模板管理：为每个topic通过用例模板，进一步减少用例开发的工作量；4）测试计划管理：测试计划类似于测试套件，包含多个测试用例，测试计划有效覆盖各类测试场景；5）运行管理：当某个测试用例在某台测试设备上执行时，平台均会创建唯一的运行实例，通过运行实例可以监控相应用例运行的整个生命周期；6）报告管理：提供用例运行的详细信息，包括运行过程数据以及执行结果分析。2.执行流程1）用户可以在用例管理模块直接执行用例，执行用例后首先会调用AFrameService，AFrameService负责与任务调度平台通信，并发送用例执行信息，任务调度平台接受后转发至AFrameServer，最后由AFrameServer驱动执行测试用例；2）AFrameServer会将用例的实时执行状态回流至报告管理模块，用例执行结束后会把详细的执行结果回流至报告管理模块；3）用户可以在用例管理模块创建测试计划，在测试计划管理模块执行测试计划，执行流程与在用例管理模块直接执行相同；4）报告管理模块支持查询测试用例的运行过程数据以及测试结果分析。五、总结&展望优酷播放测试平台实现了标准化的播放测试流程，有效降低了业务测试用例的开发复杂度，提高了用例的开发效率，规范了用例的管理和执行过程，实现了测试用例在不同环节的合理性流转，以及用例执行生命周期的实时监控和执行结果的可视化、透明化。后续我们将在基于播放体验的策略质量洞察分析、动态的校验能力、智能化的用例推荐、用例膨胀等方面继续努力。大剧保障专项优酷大剧全链路技术保障探索和实践作者|阿里文娱高级测试开发工程师党高锋优酷大剧保障主要是对大剧、大综等节目视频上线前和上线后进行质量保障。大剧视频上线所涉及方很多：比如播放（类似报错、卡住、黑屏、声音等问题）、付费权益、运营配置、用户舆情反馈是否正常等。总的来说，优酷大剧保障主要是在大剧大综开播前、开播后对视频进行质量保障，及时发现问题并解决，避免资损和客诉，使用户有更好的观影体验。大剧保障基本涵盖了大剧生命周期的全链路各个阶段保障，其中核心环节包括以下方面：针对图中的各阶段，我们建设了大剧上线流程中需要保障的环节以及能力：1.视频生产视频生产环节保障包括片源质量、上传转码质量等维度，主要以视频质量检测为主：1）介质到位时间，在上线前24小时检查介质是否到位；2）介质质量，采用机检和人工检查两种方式进行，保证片源正常；3）上传转码耗时评估，重点关注开播前转码完成情况；4）转码完成的流会自动进入视频质量检测，检测其声音、画质、数据等；5）直播流生产场景，主要检测源流规格、流稳定性等源流质量，录制过程中关注负载、排队、耗时、画质等。2.运营管理1）视频、节目播控策略检测及实时监控；2）媒资数据检查，如广告点位、编目、其他重要字段，实时变化通知。3.权益管理付费会员是视频网站的重要上帝用户，保证会员权益重中之重：1）会员可看视频的会员权益正确；2）付费点播的交易、权益正确；3）视频相关付费属性的校验和实时监控。4.播放环节播放环节是最主要的环节。以前有个痛点：视频在开播前是屏蔽状态，无法提前通过前端播放，只能等开播后到线上观看，如果有问题则为时已晚。为了解决这个问题，我们建设了播放预览能力：1）播放提供预览环境，可以播放未上线的视频，同时与线上真实场景保持一致的会员权益、广告、播放策略等，保证上线前可以模拟上线后的真实数据；2）同时优酷提供APP、PC等客户端预览环境，得以在各端验证播放效果。另外，我们也将播放自动化测试能力赋能在播放环节，比如接口自动化测试、播放器自动化测试。5.线上监控1）上线之后，除了有全量的播放监控，也有针对大剧建立了相应指标监控和报警，如播放成功率、卡顿率等；2）对弹幕评论、客诉反馈、社会舆情中的信息，建立了实时监控，发现问题及时响应排查。三、大剧保障平台围绕以上各环节，我们建立了大剧保障平台，提供自动或人工的检测机制，并有相关变更和事件的通知触达能力。下图是我们覆盖到的业务以及相关的功能。1.大剧管理我们会将重要级别的剧集自动或手动方式录入到大剧保障平台，平台将自动拉取节目下的正片视频、介质，上线时间等信息，大剧保障将围绕上线时间展开一系列的保障。2.服务管控大剧上线期间，相关信息第一时间同步给各环节服务方，核心应用避免在大剧上线期间发布，如有服务发布或变更出现问题，第一时间回滚，避免问题扩大化。为了避免大剧上线期间因服务发布产生的问题，我们制定了服务管控规则：1）大剧上线期间禁止相关业务发布变更，会在开播前机器人通知所有人；2）热度比较高的剧，实施封网管控。3.问题触达建立大剧保障钉钉群，将所有相关业务方技术、产品、运营等同学集中到一起，并配置机器人用于发送报警通知。系统支持订阅大剧重要字段的变更通知，实时监听正片的各个字段变化，有异常则报警通知。同时将各个业务方已有的保障和报警能力接入进来。检测预警消息接入后，各环节消息非常多，重要消息有可能会被忽略，那如何优化消息触达，不错过重要异常信息呢？通过持续建立和优化机器判断的能力，重要异常情况发送报警并精准触达到指定人。同时我们会存储以上所有操作变更记录和时间点，用于快速排查问题。4.机器和人工保障1）系统自动执行各个环节的机器检测，并提供人工check机制，双重保障；2）上线前实时的检测以及结果直观的展示；3）上线前24小时播报检测情况，比如在上线前的12小时、4小时、1小时播报当前检测状态。这样不仅让各方知晓即将上线剧集，也了解各个业务的检查状况。5.线上监控1）上线后的实时弹幕评论预警，客诉预警。其中我们在弹幕评论这块做到了自动化过滤关键字来实时报警，这也是比较准确和及时的舆情来源；2）上线后的播放质量监控。监控各端播放卡顿、成功率、错误数等情况，及时关注各端播放情况。6.应急预案大剧建设了发现问题的能力，也要有应对快速止血的机制。我们确定了出现问题时的预案项以及相关人员，保证问题第一时间准确的传达和快速止血，保证及时止损和问题快速修复，减少对用户的影响。四、总结通过以上大剧保障能力的建设，我们在一个平台上可以直观的看到每部大剧在上线前各个环节的健康状态，异常变动有预警通知，有线上的稳定性监控以及舆情监控，线上问题有相对应的快速止血策略，整个保障链路形成闭环。目前平台相关能力仍在持续建设中，横向我们将覆盖更多的相关联业务方，纵向将持续细化和加强每个业务方的保障能力。我们的目标是向着自动化、智能化发展，无人值守，做到上线前“心里有底”，上线后“心里不慌”。搜索算法专项三层架构下的优酷视频搜索测试体系作者|阿里文娱测试开发专家熙闫一、简介优酷搜索承担着内容分发场的头部兵的重任，海量的视频内容都要依赖搜索触达和呈现给用户，而且逐渐扩大范围，开始向阿里文娱全系产品提供搜索服务和能力。面对如此复杂且对稳定性、精准性要求极高的系统，质量保障工作显得尤为重要和极具挑战性。本文将为大家介绍视频搜索的质量体系是如何构建和发挥作用的。二、业务特点1.视频搜索架构特点●支持复杂多样的上层业务场景，业务逻辑复杂；●从搜索开始到结果返回的整个业务链路长，涉及的模块及外部依赖多；●算法依赖数据，底层数据变更会引起上层算法结果变化。2.测试难点●业务链路长且复杂，用例覆盖率等难以进行有效度量；●离线和实时数据变更如何影响业务，数据质量的监控如何和业务紧密结合；●算法模块存在复杂性及不可解释性，算法效果难以进行有效评估；●海量数据中单个badcase无法说明问题，如何有效发掘共性的badcase。3．质量保障方案三、工程质量回归测试主要是上线发布前的测试，目的在于提前发现bug，保证发布质量。目前各模块的回归测试均已作为研发流程的一环，交由研发自行进行冒烟，不管是否走提测流程，均能在一定程度上把控业务质量。我们根据链路的分层，针对各层模块进行了各模块自身的功能回归建设。各模块测试用例的自动化回归依托于冒烟平台，其可实现任意环境的快速回归，目前已积累回归用例5000+，定时线上巡检，分钟级发现问题。2．监控仍然是根据链路的模块划分，进行分层监控。监控仍依托于冒烟平台。并存储各模块日常冒烟监控数据以及真实bug数据。目前通过巡检已累计发现线上bug50+。具体冒烟监控数据大盘如下图所示。2）效果监控线上效果监控的目的在于快速发现线上效果问题，保证线上质量；此外通过固化每次效果监控数据，监控线上效果问题的长期变化趋势，以辅助研发进行算法迭代优化，最大化利用人工评测数据。已经形成了生成监控集合->定时监控->发现问题->解决问题闭环的处理机制。四、算法质量借助集团已有平台的监控能力，定制业务细则，监控流程基本分为几个阶段：存在原始表，创建对应表的分区及监控规则，订阅分区规则，原始表周期任务执行结束自动触发dqc上对应表的对应分区的规则，如果异常会根据订阅内容报警。step1:确定监控哪些表。比如我们监控A表，该节点监控规则一旦失败是否要中断后续的生产流程，如果需要中止后续的生产流程，那stepn配置强规则即可,此时要保证监控规则是业务合理的，当然一旦中止数据生产流程，我们要承受住多方的考验，节点多次失败账号健康分会受影响，任务的执行也会受影响；如果不需要中止后续的生产流程，有两种方案，一是创建影子表，监控影子表(浪费一个存储周期的空间)；二是所有规则置为弱规则(短信告警无法判断报警的严重程度)。实践中，重要的宽表数据我们采用了监控影子表方案，次重要的表采用了对原始表全部配置弱规则的方案。step2：在监控平台创建分区，用来指定是要监控哪天的数据。step3:配置规则，规则可分为通用规则和特性规则。数据量重要度属于P0级，采用数据量绝对值>阈值；同时采用了7天趋势绝对值变动在预警值在10%，20%(不同业务阈值根据业务需要设定)。表数据量突增和突降在优酷场都不合理，所以采用了7天平均值波动+绝对值模式。通用规则是各字段通用的规则，基本包含是否非空，是否为0等等，体现在数据监控上面就是非空的数据量|数据占比变化趋势是否符合预期，值域非0的的数据量|数据占比变化趋势是否符合预期。特性规则需要视业务特性而定，采取单字段max、min、均值、总量，组合特征数量、变化率、空置率等个性化定制规则。step4：订阅，支持短信、钉钉机器人、邮件等等。2）实时把握整个实时流式计算的业务系统有几个关键点：流式计算、数据服务、全链路、数据业务（包括索引和摘要）。结合质量保障体系的线上、线下全链路闭环的理论体系去设计我们的整体质量保障方案，如下图所示：2．算法1）特征算子组件单测UDF在算法数据特征计算过程中是特别普遍的开发组件单元，实时和离线都有自己的UDF定义，UDF也支持多种语言，UDF本质上是一个函数，它以不同的工程资源形式附加到各个平台的项目中使用，UDF的测试就可以简化成函数的测试，归结为输入输出的类函数单测的模式。我们复用统一框架的执行能力设计UDF单测模式如下：UDF从功能输出来说分为三类：第一类是有固定规则和处理逻辑的，这种可以通过输入输出来构建case，判断时候则判断固定的输入是否等于输出就行；第二类则是一些通用的规则类或者一下非固定业务含义输出的，这一类我们则通过正则匹配或者通用规则来去校验结果；第三类则是算法模型类，这种我们通过构建算法的评测集合，去执行评测集，获得recall&accuracy指标阈值来进行是是否通过校验。2）feature列级测试列级特征则是将整个列的计算逻辑以UDF算子为单元组件进行DAG逻辑编排，然后通过编译生成图化逻辑来流式构建特征列。计算引擎原理如图：列级特征本质上就是一个图化的UDF组合逻辑，可以看做是一个复杂图化的计算函数，包含了很多子UDF的图化遍历的逻辑。构建编译器在列级图化逻辑编排完成之后进行编译会得到该列的DAG信息。这个DAG信息就会作为列级的图化逻辑属性。当列级feature进行逻辑执行的时候会解析该DAG信息进行图的遍历依次执行UDF算子。同样的原理，我们在测试构建时候我们构造列级特征检测的case集合。特征既有数据含义，同时也具备部分业务应用上的含义，特征检测我们可以结合数据规则和业务含义内容共同制定特征检测机制。通过构建特征输入集来进行图化逻辑执行得到特征值，通过特征值的检测、特征分布、特征业务属性检测几个维度去完成特征检测。这个时候我们会通过统一的trace策略机制去记录每个UDF的调用执行情况，以供追查UDF执行错误和异常情况。3）全图化索引测试前面UDF是算子组件维度的，而特征feature是列维度的，索引全列则是以行为维度的，每行综合多列。而全列索引特征构建是综合多列feature的图化逻辑形成的一个pipline。pipline以引擎索引分类为一个完整的Pipline，比如OCG就是一个全列的完整Pipline。所以Pipline级别的数据测试则是以行维度的数据。3．效果对搜索整条链路以及链路上影响算法的重要模块如意图分析模块都建设了效果基线。a）搜索链路效果基线建设。效果测试集必须是动态的，这里采用case放在云文件或者数据平台，当流量出现新词的时候随时添加。要作为效果基线，必须保证测试集对应的预期结果必须是准确的，这里采用的机制是评测同学维护。总体流程是评测同学在数据平台维护效果基线query、预期结果，代码加载数据进行规则判断，噪音消除，失败报警。●规则：检测TOPn召回某种类型卡片，TOPn只能召回某些showids，聚合卡片中TOPN只能召回某些showids，n可配、showids可配、卡片类型可配等等；●噪音消除：失败重试、运营数据剔除、showid可能出现在多种卡片，每种都需要相应业务逻辑。使用场景：●搜索链路所有模块发布卡口；●被列为ABtest期间关注的指标之一，指标一旦失败，实验回滚；●大流量桶的日常监控，成功率要求100%，一旦失败必须及时修正。b）意图模块QP的效果基线建设。方案：方案主要涉及意图类型、测试集构建、验证规则。效果基线要check那些意图呢，主要是从产品形态和算法使用情况来确定，每个意图都涉及正样本和负样本；样本数据取自线上已经识别出的意图数据然后人工审核后分别放在对应的正样本和负样本，负样本还有一部分数据来自互斥意图的正样本数据；规则：同一个意图对于不同的算法使用意图不同，比如人物，“郭德纲于谦”切词后这个词属于人物，但是不应该出人物卡。使用场景：●线上定时监控：对于意图模块数据回流、代码发布都会影响效果，数据回流是自动触发，数据是否正确未知，也就说明线上定时监控的必要性。2）搜索效果影响面自动评估●测试集构建：线上真实流量按照SQV进行分层、采样(越偏头部采样密度越大)，线上流量映射到测试集；●评测规则：分析用户使用搜索的习惯，对用户经常点击的位置分别进行比对；●影响面计算：异常请求的sqv总和/所有sqv总和；●噪音消除：异常重试、去掉算法无关卡片，来保证影响面评测的准确度。3）指标看板将评测能力集成到监控中，分钟级运行，产出效果指标大盘，及时发现算法问题并能指导算法优化。五、用户体验1．badcase分类和挖掘分析线上流量，badcase挖掘主要集中在腰尾部高跳词。除了流量分层还有一个重要的流量就是实效性极高的热点。1）高跳badcase挖掘：通过竞品对比等手段检测出多种类型的badcase，badcase会映射到具体原因上，直接进行专项优化，优化后的case会放入每次迭代，未优化的case以badcase形式存在badcase库，后续效果迭代会运行这些数据，以检测badcase的效果；2）时效性分析：分析各大平台的热点内容，与自身做对比，并加入了相关性过滤逻辑。运行机制：一天两次，研发会及时处理报警内容，同时会进行长期优化，现在badcase比例已明显下降。2．舆情处理闭环依托优酷舆情发现和处理平台优酷声音，聚合用户观点，针对搜不到、搜不好等问题，做专项优化，已解决5大类badcase。人工智能的基石—算法数据质量作者|阿里文娱测试开发专家熙闫一、背景优酷视频搜索是文娱分发场的最核心入口之一，数据源多、业务逻辑复杂，尤其是实时系统的质量保障是一个巨大挑战。如何保障数据质量，如何衡量数据变化对业务的影响？本文会做详细解答。二、现状分析搜索数据流程如下图所示，从内容生产到生成索引经历了复杂的数据处理流程，中间表多达千余张，实时数据消费即消失，难以追踪和复现。从上图可以看出，整个系统以实时流模式为数据流通主体，业务层面按实体类型打平，入口统一分层解耦，极大的增加了业务的实时性和稳定性。但是另一方面，这种庞大的流式计算和数据业务系统给质量保障带来了巨大的挑战。如何从0开始，建设实时数据的质量保障体系，同时保证数据对搜索引擎业务的平滑过渡？这是我们面临的挑战。三、实时数据质量保障体系方案质量保障需要透过现象看本质。通过对架构和业务的分析，可以发现整个流式计算的业务系统有几个关键点：流式计算、数据服务、全链路、数据业务（包括搜索引擎的索引和摘要）。整体的质量诉求可以归类为：1）基础数据内容质量的保障2）流式链路的数据正确性和及时性保障3）数据变化对业务效果的非负向的保障结合线上、线下、全链路闭环的理论体系去设计我们的整体质量保障方案，如下图所示：四、线下质量1．实时dump数据测试包含链路节点比对、时效性、正确性、一致性、可用性等方面，依托于阿里技术资源设计实时dump的方案如图：2．数据一致性一致性主要是指每个链路节点消费的一致性，重点在于整体链路的各个节点的数据处理消费情况保持一致，通过对数据消费的分时分频率的比对完成一致性验证。方案如下图我们采取不同的数据流频率输送给实时链路进行消费，利用各层的dump机制进行数据dump，然后取不同的抽样间隔对dump数据计算分析，分为三种不同的数据频率模式：●natural-flow：自然消费的数据流，是源于线上真实的数据消息通道，即自然频率的数据消费，以该模式进行测试更贴合实际业务情景；●high-frequency：高频数据流，采用超出真实峰值或者其他设定值的数据频次输送给实时消费链路，在压测或者检测链路稳定性中是一个常用的测试策略；●low-frequency：低频数据流，采用明显低于真实值或者特定的低频次数据输送给实时消费链路。如果数据链路中有基于数据量的批量处理策略会暴露的比较明显，比如批量处理的阈值是100，那么在业务低峰时很有可能达不到策略阈值，这批数据就会迟迟不更新，这个批量处理策略可能不是合理。同时低频次的消费对于实时链路处理的一些资源、链接的最低可用度这些层面的检查也是有意义的。3．数据正确性数据正确性是对于数据内容的具体值的检查，总体原则是：首先，高优保障影响用户体验的数据；其次，保障业务层直接使用的核心业务相关的数据内容；再次，中间层的核心业务相关数据由于不对外露出，会转换成业务引擎需要的最终层的业务数据。所以中间层我们采用通用的规则和业务规则来做基础数据质量保障，同时对上下游数据内容变化进行diff对比，保障整个流程处理的准确性。4．数据可用性数据可用性指的是数据链路生产的最终数据是能够安全合理使用的，包括存储、查询的读写效率、数据安全读写、对不同的使用方提供的数据使用保持一致性等。可用性保障主要关注数据的存储、查询、数据协议（数据结构）三个大的维度，衡量的标准重点关注三个方面：●易读写：数据的结构化存储和写入必须是高效合理的；●服务一致：数据在结构化存储后，对外提供的服务有很多种，比如PB协议、API、SDK等，需要根据业务去考量。比如SDK、PB等对外提供使用的方式会涉及协议版本，不同的版本可能数据结构不一致导致对外使用的数据不一致性；●安全可靠：重点关注存储稳定、可靠、高效，兼顾效率和稳定性，同时更要关注安全性，防范随意改写数据、恶意dump等严重影响线上数据使用安全的风险。5．时效性由于实时链路的流式特性和多实体多次更新的特性，在测试时效性时核心问题有两点：●如何去跟踪确定一条唯一的消息在整个链路的消费情况；●如何低成本获取每个节点过程的数据链路时间。我们抽象出一个trace+wraper的流式trace模型如下图：获取链路过程的每个节点的时间，包括传输时间和处理时间。对于track-wraper需要约定统一的track规范和格式，并且保证这部分的信息对业务数据没有影响，没有增加大的性能开销。如下图，我们最终的信息中经过trace&track-wraper带出来的trak-info，采用json格式方便track-info的扩展性。这样就很容易去获取到任意信息，计算每个节点的时间。我们也可以通过抽样计算一些统计指标衡量时效：对于时效性有明显异常的数据可以筛选出来，进行持续优化。6．性能测试实时数据链路本质是一套全链路数据计算服务，所以我们也需要测试它的性能情况。第一步，我们先具体化全链路的待测系统服务包括两部分的性能，Bigku的反查服务，即HSF服务，再就是blink的计算链路节点。第二步，准备数据和工具压测需要的业务数据就是消息。数据准备有两种方式，一种是尽可能模拟真实的消息数据，我们只要获取消息内容进行程序自动模拟即可；另外一种会采用更真实的业务数据dump引流，进行流量回放。由于数据链路的特性，对压测链路施压就是转成发送消息数据，那么如何控制数据发送呢？有两种方式：第一种我们开发一个发送消息的服务接口，转变成常规的接口服务压测，然后可以采用阿里的任何压测工具，整个测试就变成常规的性能测试；第二种我们可以利用blink消息回追的机制，重复消费历史消息进行压测，不过这种方法有弊端，无法控制消息的频率。7．压测和指标收集根据业务情况来收集指标，指标包括服务本身的指标和资源指标，可以参考我们的部分性能测试报告示例（数据有截断）：五、线上质量1．服务稳定性保障稳定性包括两个层面，一是实时计算任务链路的每个节点的稳定性，二是内置服务的稳定2．实时计算由于实时计算采用全blink的计算方式，我们可以利用blink系统本身的特性来做任务的监控。每个节点的任务都需要配置稳定性指标的监控，包括rps、delay、failover等。效果示例如下：3．实体服务实体服务是HSF服务，采用阿里统一的监控平台来完成整体服务能力的监控，示例如图：整体指标包含以下内容：4．数据消费保障在数据消费层面，重点关注每个链路层级的消费能力和异常情况。基于积累的track-report能力进行数据统计，结合平台完备的基础能力来完成消费保障。分为两层：核心层：消息出口的实体消息统计监控，包括整体数量和消息内容分类统计监控。如图示例：中间层：包括每个实体消息处理的accept，处理逻辑层的success、fail、skip指标，便于我们实时知晓每个链路层收到的消息、成功处理、错误和合理异常等消费能力情况。如图示例：5．数据内容保障数据内容层，建设综合数据更新、数据内容检查、业务效果三位一体的精准数据检查，达到数据生产、消费、可用性的闭环检测，如图所示：从图中可以看出，我们数据内容保障分为三部分：1）sampler：抽样器，通过blink实时消费消息在链路中抽取待测数据，通常是只抽取数据ID；抽样策略分间隔和随机两种。间隔策略就是取固定时间间隔的特定数据进行检查；随机则根据一定的随机算法策略来抽样数据进行检查。2）data-monitor：是做数据内容检查，包括更新时效性和数据特征属性检查。3）effect-monitor：数据正常更新之后，对在线业务实时产生的效果影响进行检查，检查的核心点包括搜索的两大基本效果——召回和排序，以及用户体验相关的数据属性的检查。部分数据实时效果示例图：6．实时干预与自动修复实时干预通道，如下图：实时干预系统会根据不同的干预需求，对消息内容和干预机制进行消息组装和通道分发。1）当主通道业务链路正常时，若需要强制更新一个ID维度的数据，只需要输入ID走正常主链路更新即可。2）当需要强制干预某些具体的数据内容到指定的消息通道时，则可进行数据内容级别的更详细的精准干预。3）紧急强制干预，是指当主链路中间层处理有较大延迟或者完全阻塞时，会造成下游业务层数据无法正常获取输入。通过主逻辑全copy的机制建立了一个VIP的消息通道，通过VIP通道去直接干预出口消息，保证业务数据正常能进行优先更新。六、质量效能效能层面主要指：研发能快速自测上线，线上问题能高效排查定位这两个维度，以期达到保证快速迭代、节省人力投入的目标。所以我们提供了实时debug和实时全链路trace透视两大提效体系。1．实时debug实时debug是基于实时消息通道能力和debug机制建立的一套服务，在研发自测、问题复现等场景有很大用途，可以通过debug模式详细了解链路的业务层处理细节，业务层只需要按数据需求自主定制debug内容，无需其他接入成本，具备很强的通用性和扩展性。平台效果图：填入节目ID，发送消息就会自动进入实时debug模式。同时还配备了指定消息内容的专家模式，方便研发进行单独的消息内容制定化测试和干预。2．全链路trace我们提炼了一个全链路实时trace的通用模型，同时做更精细定制化的trace机制。结合实时业务链路逻辑视图，来看下trace的系统实现：链路层视角，目前整体分为4个业务块，数据流按顺序进行展示：1）bigku_service展示了当时消息的镜像数据2）mid_show_f为算法层面的基础特征，即一级特征，包含了业务信息和系统信息（工程关注的指标数据，主要用来指导优化）。3）sum_video_f和ogc属于搜索链路上的数据，一般在节目里面会有一些较为复杂的截断逻辑，通过字典表的形式提供数据层的透视视角，可以看到链路的全部信息。七、产品体验实时自动化保障我们在实时数据内容质量方面做了融合效果监控的质量方案，建立了实时发现问题、实时定位、实时修复的闭环链路效果保障体系，起到了很好的效果。体系方案如下图：客户端客户端质量评估体系作者|阿里文娱技术专家翀宸一、客户端质量评估体系的需求移动客户端的质量包括功能和体验两方面。在不同阶段，客户端质量保障能力建设的粒度和广度的需求并不相同。早期可能快速试错是一种更为高性价比且有效的手段，但是随着应用的规模和用户体量逐渐增加，合理的质量保障投入就成为了一个必需品。明确质量保障的需求和范围，找到质量保障的成本和质量出现问题的修复成本的有机结合点，实现质量和成本收益最大化，是在设计和实施质量保障工作前务必要考虑清楚的事情。体系化建设主要包括两个维度的实践：通过评估手段和方法的建设实现“有法可依”，通过流程和监督体系的建设实现“有法必依”。本文将介绍优酷技术质量部在“有法可依”维度进行的一系列建设，希望能给读者提供一些参考。二、客户端质量评估体系的建设根据优酷质量保障的需求和业务特点，我们重点在如下图示的几个重要阶段进行了投入，并且在构建打包阶段、整包验证阶段和线上验证阶段进行了重点建设。1.需求评审阶段需求评审是整个开发测试流程的起点，占据非常重要的位置。质量控制团队在需求制定和评审阶段有效介入，确认需求的合理性以及质量的可评估性，在需求中强调对质量风险的处理能力以及对测试支持的友善性，将会对后期软件质量的可控起到非常重要的作用。我们在每个版本启动阶段进行需求评审，除了明确需求细节之外，会对新需求潜在的质量和用户体验影响、以及可测试性进行讨论，最大限度的暴露问题并寻求解解方案，极大的节省了后续定位问题和返工的成本。2.编码开发阶段我们通过推动CodeReview以及单元测试来评估这一阶段的质量情况，主要扮演了协调者和监督者的角色，编码开发阶段的规范化也是我们在加大力度进行建设的部分。3.构建打包阶段构建打包阶段相对整个应用版本的生命周期来说仍然处于一个较早期的阶段，适合的能力针对性的投放在这个阶段可以做到以小博大，投入少，产出明显，例如静态代码扫描、包大小健康度检查等等。优酷技术质量部也是优先在这个环节发力，解决了较多相对埋藏较深的历史遗留隐患。4.整包验证阶段通过测试分层、分类，加强自动化能力建设以及拓展新的测试能力这几个手段，我们在整包测试环节取得了不错的进展，提升了测试能力和测试效果。针对优酷客户端测试的需求和组织形式，我们优先根据测试的目的从两个维度对测试内容进行分层操作：服务端+客户端，白盒+黑盒。常规的端上黑盒验证存在一些固有弊端：场景多、链路长、执行过程复杂，难以维护和提效。通过服务端和客户端的测试分层，在服务端的接口处设置一道验证屏障，保证服务端的逻辑正确，可以有效减少测试验证的链路长度和复杂度，简化客户端的测试场景，从而减小客户端的测试压力。服务端的自动化验证是相对容易实现和部署的，执行效率高，成本低；经过简化的客户端验证因为少了很多待验证场景，去掉了相当多的pre-condition设置和环境/场景切换动作，自动化可行性也大大提高。在此基础上，我们又对客户端侧的测试进一步进行细化。部分可以通过白盒测试解决的场景，可自动化程度极高，维护成本非常低，例如通过白盒直接控制播放器接口的方式对播放器进行操作，比UI操作的准确性和稳定性都要高很多。设想一个拖拽快进播放的场景，通过UI自动化实现几乎是一场噩梦，多机适配更是一个不可能的任务，但是白盒化测试来实现却易如反掌。但确实有些测试确实需要走到UI层用黑盒的方式操作才能实现，或者在UI层的操作才能触及到验证点，测试团队只有在这种情况下测试团队会选择黑盒方式完成测试。通过两次分层，各层测试场景的数量和复杂度均比较可控，可自动化程度极大提高，需要人工投入的成本和压力减少。为了最大化的提效，我们对端上测试又进行了分类，如：回归测试、遍历测试、兼容性测试和适配测试等等，其目的是为了进一步提升测试的针对性，减少测试外延，降低测试复杂度。通过测试分类，不同的测试类型关注不同的验证点，进一步拆分了测试场景，降低了每一种类型的测试复杂度，从而使得回归、遍历和兼容性测试可以更好的进行自动化转化，快速高效的完成核心场景的检查，并通过适配测试补齐自动化测试在覆盖面上的短板。对几种测试类型的选择使用和组合使用，将使得测试策略更加灵活，测试效率和效果大大提高。除了功能验证外，客户端性能测试不可或缺。优酷在性能测试上投入了较多的精力进行建设，取得了不错的成绩。5.线上验证阶段经过编码开发阶段、打包构建阶段和整包阶段三个阶段不同维度的验证，可以最大限度的减少问题上线。但是线上用户的使用设备和使用环境千差万别，使用场景也很随机，线下测试基本无法做到对线上场景进行穷举验证。因此应用发布上线后，很大概率还是带着这样那样的问题的，仍然需要有效的质量保障手段支持。减少线上用户影响的一个有效方法是控制用户范围，发布灰度版（beta版、试用版）或分批发布都是比较可行的办法。灰度发布不是简单的随机圈一波用户进行测试版推送，推送的策略非常重要。我们分析了线上用户的各项特征指标，建设了用户分布模型，并基于此实现了可控的灰度推送策略，帮助优酷在灰度发布的效果和效率上取得到了较大的提升。减少线上用户影响的另一个方法是快速止血，这需要建设完备的线上监控体系：首先，要求有一个可靠的数据平台，有效的收集和回流线上的特征数据信息；其次，需要根据自身业务的特点，针对性的制定监控策略，有效的利用数据平台的数据。无论是在灰度期间还是应用正式上线全量之后发现的问题，都是对线下测试的有益补充，应该有效的加以利用。我们建设了从灰度发布到线上全量的自动化体系，串联起了灰度发布、正式发布、线上监控等环节，并对监控发现的问题自动进行分发并回收结果。基于这套自动化的流程，不仅可以确保线上问题得以及时发现，还可以加强线上问题的处理效果，目前已经成为了优酷版本发布流程中的必备环节。另外，线上问题尤其是影响面比较大的，应该进行深入分析，对可以提炼出问题路径或者验证方法的问题转化为线下验证用例。当前优酷在构建打包阶段的静态代码扫描和整包验证阶段的BadCase回归，都有基于线上问题转化而来的用例，来补充线下测试在测试设计阶段难以预估的测试场景。6.平台服务化从需求评审到线上验证，质量保障工作贯穿于每一个需求的整个生命周期，涉及的验证环节众多且分散。我们是通过提供统一的、标准化、规范化的测试平台服务来串联各个环节的测试能力，由平台负责实现、管理、调度各种客户端测试手段，并对接各个业务团队的测试需求，提供各业务一致的解决方案。另外，测试平台利用流程服务的驱动在优酷版本发布的过程中实现关键节点的测试验证和结果展示，帮助业务方、PMO等核心角色确认当前集成版本的质量。通过平台化建设，整合客户端的各种测试能力实现的这一套测试体系，真正构成了优酷的客户端质量评估体系。客户端打包构建阶段的质量评估解决方案——PreMTL作者|阿里文娱技术专家翀宸一、PreMTL的由来阿里巴巴各BU的客户端打包构建通常是基于摩天轮（MTL）平台来完成的，它可以满足大部分的通用性需求，但对部分个性化需求难以及时响应。因此，优酷技术质量团队建设了PreMTL体系——意在摩天轮（MTL）打包之前的检查，快速服务优酷在打包构建环节的验证需求。二、PreMTL核心能力简介在PreMTL体系中，我们重点建设了三个能力：静态代码扫描、包大小健康度检查、苹果审核预查。1.静态代码扫描如果CodeReview做的足够到位可以解决大部分编码问题的。但考虑到效率和覆盖范围，需要引入高自动化程度的静态代码扫描。优酷线上有相当一部分问题是由空指针引起的，如果通过客户端整包验证来发掘这类问题，好比大海捞针，即使是出现频度较高的NPE问题也难以发掘。静态扫描可以发挥巨大的功效，但也存在挑战：第一是直接应用服务端扫描的工具和模式，未必适合客户端的情况；第二是如何长效化的落地静态扫描的能力，避免短期的战役形式的推进。为有效的应对上述挑战，我们明确了静态扫描方案的具体要求：1）准确度高，保证扫描结果和效率的最基本的要求；2）执行效率高，以满足高执行频度下快速获取结果的需求；3）配置简单、灵活，支持自定义规则，以满足不同业务个性化的需求；4）持续集成友好度高，与测试平台和流程集成成本低；5）最好提供双端（Android/IOS）一致的体验和方案。基于这几个维度的筛选，我们最终选定了Facebook开源的静扫工具Infer作为主力工具进行接入。同时利用客户端测试平台的服务化能力，将用户的上手成本降到最低。经过平台化建设的静态扫描的配置界面如上图所示，需要用户输入和选择的信息非常少，需要的内容也非常明确，上手成本比较低。一旦用户实际触发了静态扫描，平台会有机整合结果以及附加的操作，方便用户对结果进行筛选和处理。客户端测试平台静态扫描的综述结果页和详情结果页如下图所示：客户端测试平台除了提供非常详尽的结果指示、查询和操作能力，还提供了对比扫描、自定义规则录入等能力，大大降低了使用成本并方便用户实现个性化测试需求。基于平台服务化，静态扫描具备了被其他平台和系统调用的能力，可以很好的集成到任何业务或团队的平台或流程中，快速发挥作用。经优酷技术质量团队牵头，优酷在2019年对历史存留的空指针问题进行了集中治理，达到了Android端核心模块90%+零存量NPE，iPhone端核心模块80%+零存量NPE的成果，极大的解除了版本质量隐患。同时，通过多平台有效对接和联动，静态扫描已经变成了优酷客户端版本发布过程中的必经环节，实现了版本质量的常态化保障。2.包大小健康度检查包大小健康度是一项比较重要但是可能被忽略的质量指标。臃肿繁杂的应用安装包不光存在更高的质量和稳定性隐患，使得问题排查的复杂度相对更大、成本更大；另一方面，安装包大小直接影响着用户的下载或保留应用的意愿。单纯的关注整包大小并不能解决实际问题。很多版本发布流程或平台对应用整包大小都会有一些限制，从实际情况看发挥的效果非常有限，即便超过阈值也常常会因为业务需求开绿灯。如果没有一个有效的方案对应用包中存留以及新增的代码和资源的合理性进行检查和评估，并给出准确的判断结果指导业务方进行优化，应用包体积控制就会变成一个痛苦的反复讨论、对比的过程，甚至会常态化的挣扎在包体积大小的阈值线上面。为此优酷技术质量部推出了包大小检查能力，取得了不错的效果。所谓包大小检查，是根据影响包体积大小的现实问题分别列出对应的指标，例如资源文件的大小和引用情况，PNG图片的使用情况，代码混淆情况，或者各个模块在线上被访问的热度等等。优酷通过这种检查方式避免了对应用体积简单粗暴的一刀切式管理方法，转为数据驱动、以事实说话的方式，让新的需求可以合理的集成进来，同时又最大限度的保持了应用体积处在一个健康的状态。下图展示了客户端测试平台进行一次包大小健康度检查的结果界面，读者可以参考。通过以上多维度的数据展示，开发团队可以有效的对存在问题的部分进行优化，决策方可以快速的判断体积增加的合理性。经过一段时间的集中推广，包大小健康度检查也已经成为了优酷客户端版本发布过程中的一个必须的检查项目，安装包的体积大小得到了较大的优化并有效控制在了一定的浮动范围内，整体效果符合项目建设的预期。优酷多个版本的包体积大小走势示意（安卓端）如下图所示。3.苹果审核预检查苹果对于在应用商店发布的应用都有详细的上线前审核，优酷在应对苹果审核的检查保障手段上积累了一些经验并沉淀了一些方法：1）苹果的审核分为自动审核和人工审核两部分，人工审核阶段更多是关注基础功能、展示和内容方面的合规情况，对应的保障工作主要在整包验证阶段进行；2）自动审核部分更多的是关注应用本身的合规情况，主要是在构建打包阶段通过自动化能力来保障的。例如，如果应用代码中，诸如类名、方法名或者全局变量等关键位置有类似于“Alipay”这样的敏感字眼，苹果是非常容易怀疑提审的应用中支付方式没有符合苹果的要求，从而大概率会造成拒审。所以对于某些敏感关键字在符号级别、甚至是字符串级别的扫描是非常必要的。通过客户端测试平台的IOS审核检查能力，进行关键符号检查的一个结果DEMO如下图所示。检查逻辑的实现机制并不复杂，但是执行的效果比较理想，配合类别同名查找等扫描能力，利用平台化的支持，优酷在2019年的苹果审核过程中整体顺利，一次通过率相比2018年上升了50%+。三、构建打包阶段验证能力的拓展和规划在构建打包阶段，通过合理的能力调整和部署、针对性的解决执行环节和实现常态化的痛点，可以实现质量控制能力的有效落实。基于已经完成的能力，我们正在开展更进一步的建设，例如：1）依赖关系检查，优化多模块集成效果；2）拓展静态扫描能力，覆盖跨模块检查；3）强化包大小健康度检查，发掘影响包体积大小的更多因素。PreMTL的建设对提升优酷客户端版本质量起到了很大的作用，希望对读者有所启发。客户端性能评估解决方案——通用性能测试作者|阿里文娱技术专家翀宸一、客户端性能测试的需求和重要性客户端性能的重要性不言而喻，一方面影响着客户端整体质量稳定性，任何性能指标的越界都可能造成整个APP的崩溃，例如CPU使用过高导致应用hang住，内存占用过多导致OOM等等；另一方面，性能影响用户体验，例如页面加载的速度、划动浏览的流畅度等等，对于用户的使用和留存意愿有直接的影响。本文将详细介绍优酷通用性能测试解决方案的落地情况。二、通用性能测试解决方案的建设常见的性能数据采集方式是通过应用内置的接口进行数据上报，整体获取线上存量APP的数据，如启动时间、页面加载时间、页面FPS等等。但是以此作为版本发布的质量指标并指导性能优化的动作还不够细致。大盘数据更适合给出如90%区间值等指标来指导整体性和方向性的调整动作，但是每个版本迭代中的微小变化，很难反映出来。同时对于有竞品及行业数据对比的情况，大盘数据也不适用。为此优酷技术质量部着手建设了性能测试解决方案。第一步是确定需要满足哪些测试场景的性能测试需求。性能测试通常覆盖两种测试场景：1.获取时间维度的数据，如启动时间、页面加载时间、播放起播时间等等；2.获取基础性能数据，如FPS、CPU、内存、IO等等指标。作为以视频播放为主的应用，优酷的性能测试还需要关注播放场景下的特定数据采集，例如卡顿次数和播放时长等。基础性能数据通常可以直接从手机中获取，Android及IOS均提供了一些命令行工具或者系统接口帮助获取这类信息。对于基础性能数据的采集，只需把自动化执行过程和数据采集过程有机的整合起来，做好数据同步的同时减少数据采集对性能的影响即可。加载时间维度数据的获取要相对复杂一些。业界比较通行的做法是利用视频分帧和图像分析相结合的方式计算时间维度的数据。相较于通过应用内置接口上报数据或者分析日志的方式获取时间信息来说，这种方案更加复杂，但是更加接近真实用户的实际使用场景，因此数据更加准确。为了最大限度的保证用户体验，优酷的性能测试方案从一开始就确定使用视频分帧分析的方案。实现视频采集分帧的自动化性能测试，需要具备3个条件：1.稳定的自动化驱动能力；2.准确的图像识别和强大的分析能力；3.确保整个流程可以自动化运转的平台调度和服务能力。除此之外，性能测试的能力若想真正发挥作用，被开发和测试团队所接纳，还需要制定一套切实可行的性能测试标准和执行流程。在优酷技术质量部，客户端测试平台负责测试设备和自动化测试任务的管理和调度；魔镜服务负责视频的解析和图像计算。在性能测试早期的实现方式中，移动架构团队和研发效能团队配合来全权负责性能测试的需求，根据测试设备保有情况随机选择测试设备，覆盖少量加载时间验证场景，形成了如下的一种耦合方式。很快我们发现这种配合方式并不理想。首先，整个流程没有业务方参与，测试效果和测试场景与业务需求脱节；其次，优酷客户端测试平台与魔镜服务耦合过深，双方在进一步建设过程中束手束脚，难以发挥各自特长；再次，缺少业务方的主导，整体能力缺少落地的保障，技术团队维护测试能力成本非常高。为此，我们特地协同业务需求方梳理了整体需求，重新制定了参与的各方和任务排布，形成了一套非常明确的配合机制（如下图所示）。在这个配合模式中，业务方、客户端测试平台和魔镜服务各司其职，各自专注在自己擅长的领域，形成了1+1+1>3的协同发展模式。基于这种模式，我们开启了通用性能测试的建设。这包括几部分内容：1.测试驱动方法标准化，提供双端（Android及iOS）一致的自动化执行方案；2.测试环境标准化，为保证性能测试的准确性，全部辅助测试手段采取外置化（例如视频采集不通过录屏而通过外部拍摄的方式），同时对测试环境温度、网络环境，以及视频拍摄所需的亮度、拍摄可控性等提出了严格的要求；3.测试方案标准化，选用什么样的设备，测试哪些场景，以及执行过程和结果采集点的制定均实现标准化规范化；4.测试流程服务化，整个测试的执行环节通过平台化的能力以服务的方式提供出来，可以和其他平台和流程服务对接，以便快速在业务平台和版本发布流程中落地。不同业务方原本具有不同的自动化能力选择，整体驱动模式不统一，测试用例管理和适配比较困难，复用性非常不理想。推动测试驱动方式标准化，各方统一基于一套方案进行开发是推动整体性能测试标准化的基础。基于对测试需求的分析，我们选择了蚂蚁集团基于Appium改良而来的测试框架Totoro，并对Totoro的接口按照优酷的测试需求进行了二次封装，实现了自己的自动化测试驱动框架。在测试方案标准化上，我们优先确定了测试设备的配置。为了更好的量化不同机型上的性能表现，我们基于优酷在线上占比TOP30以内的机型，按照其性能打分的情况进行筛选，最终确定高、中、低端3款机型作为测试承载机；测试场景的选择和建设则参考用户核心使用场景进行筛选，确保用户体验得到最大化的保障。测试环境标准化建设是通用性能测试方案投入较多的部分。我们知道温度对手机的性能影响比较大，有些机型甚至会在高温下出现降频保护以及充电保护等情况。测试温度的处理极大的影响着测试的可重入性，决定了一种测试方案是否可以被接受。考虑到外部拍摄的需求，测试环境需要是一个相对密闭的环境以确保环境亮度等符合拍摄需要，这就对散热控温提出了更高的要求。在拍摄设备的选择上，需要同时考虑拍摄质量、拍摄的可控性及软硬件成本。拍摄质量不用赘述。拍摄的可控性是指拍摄设备可配置和调试的程度，因为被拍摄的场景和被摄机的型号众多，拍摄设备必须具备强大的灵活性并保持高质量的拍摄效果，例如：1.最基本的拍摄参数例如分辨率、码率、比特率、编码格式等等需要可调；2.高级设置如景别设置、曝光参数调整、对焦能力调整、曝光和对焦的锁定能力等；3.合理的软硬件成本。也许有读者会觉得这么复杂和麻烦，为什么不用录屏的方式，岂不方便。经我们测试，录屏方案在低端机型上会对性能数据带来10%甚至更多的影响，而且这个偏差会跟着测试场景的变化出现浮动。这对于准确度要求较高的性能测试来说几乎是不可接受的。因此，优酷的通用性能测试从起步阶段就选择了外部拍摄的方案。经过对测试环境和拍摄方案的调研，首批的通用性能测试环境基于硬板纸盒和千元级别的安卓手机搭建起来了，效果如下。选用纸盒的原因是纸盒可以快速的完成测试环境的组装，并且可塑性非常好。选用安卓手机作为拍摄装置是在比较了多个摄像头、专业拍摄装置以及多款安卓手机的拍摄效果和可控性之后做出的选择。利用上面的这套环境，在实验室全程空调+风扇的照顾下，短时间内通用性能测试基本满足了业务测试的需求。然而，这套环境的缺点也非常明显：不够标准化，对外部环境依赖较高。为此，我们又开发并搭建了新的测试环境，提供了一套可插件化扩展的标准化测试支持装置。测试设备和拍摄设备的部署在这套环境中均是标准化的，在环境装置内部散热组件的加持下，即便在外部环境温度30度以上的情况下，测试环境中的环境温度和被测设备的电池温度均保持在30度左右并且非常平稳。启动或停止散热装置情况下被测设备电池温度的变化情况可以参考下图，整套环境在温度保持方面的效果是非常明显的。整个通用性能测试方案基