一, 客户端性能测试的需求和重要性
客户端性能的重要性不言而喻, 一方面影响着客户端整体质量稳定性, 任何性能指标的越界都可能造成整个 App 的崩溃, 例如 CPU 使用过高导致应用 hang 住, 内存占用过多导致 OOM 等等; 另一方面, 性能影响用户体验, 例如页面加载的速度, 划动浏览的流畅度等等, 对于用户的使用和留存意愿有直接的影响. 本文将详细介绍优酷通用性能测试解决方案的落地情况.
二, 通用性能测试解决方案的建设
常见的性能数据采集方式是通过应用内置的接口进行数据上报, 整体获取线上存量 App 的数据, 如启动时间, 页面加载时间, 页面 FPS 等等. 但是以此作为版本发布的质量指标并指导性能优化的动作还不够细致. 大盘数据更适合给出如 90% 区间值等指标来指导整体性和方向性的调整动作, 但是每个版本迭代中的微小变化, 很难反映出来. 同时对于有竞品及行业数据对比的情况, 大盘数据也不适用. 为此优酷技术质量部着手建设了性能测试解决方案.
第一步是确定需要满足哪些测试场景的性能测试需求. 性能测试通常覆盖两种测试场景:
获取时间维度的数据, 如启动时间, 页面加载时间, 播放起播时间等等;
获取基础性能数据, 如 FPS,CPU, 内存, IO 等等指标.
作为以视频播放为主的应用, 优酷的性能测试还需要关注播放场景下的特定数据采集, 例如卡顿次数和播放时长等.
基础性能数据通常可以直接从手机中获取, Android 及 iOS 均提供了一些命令行工具或者系统接口帮助获取这类信息. 对于基础性能数据的采集, 只需把自动化执行过程和数据采集过程有机的整合起来, 做好数据同步的同时减少数据采集对性能的影响即可.
加载时间维度数据的获取要相对复杂一些. 业界比较通行的做法是利用视频分帧和图像分析相结合的方式计算时间维度的数据. 相较于通过应用内置接口上报数据或者分析日志的方式获取时间信息来说, 这种方案更加复杂, 但是更加接近真实用户的实际使用场景, 因此数据更加准确. 为了最大限度的保证用户体验, 优酷的性能测试方案从一开始就确定使用视频分帧分析的方案.
实现视频采集分帧的自动化性能测试, 需要具备 3 个条件:
稳定的自动化驱动能力;
准确的图像识别和强大的分析能力;
确保整个流程可以自动化运转的平台调度和服务能力.
除此之外, 性能测试的能力若想真正发挥作用, 被开发和测试团队所接纳, 还需要制定一套切实可行的性能测试标准和执行流程.
在优酷技术质量部, 客户端测试平台负责测试设备和自动化测试任务的管理和调度; 魔镜服务负责视频的解析和图像计算. 在性能测试早期的实现方式中, 移动架构团队和研发效能团队配合来全权负责性能测试的需求, 根据测试设备保有情况随机选择测试设备, 覆盖少量加载时间验证场景, 形成了如下的一种耦合方式.
很快我们发现这种配合方式并不理想. 首先, 整个流程没有业务方参与, 测试效果和测试场景与业务需求脱节; 其次, 优酷客户端测试平台与魔镜服务耦合过深, 双方在进一步建设过程中束手束脚, 难以发挥各自特长; 第三, 缺少业务方的主导, 整体能力缺少落地的保障, 技术团队维护测试能力成本非常高. 为此, 我们特地协同业务需求方梳理了整体需求, 重新制定了参与的各方和任务排布, 形成了一套非常明确的配合机制(如下图所示).
在这个配合模式中, 业务方, 客户端测试平台和魔镜服务各司其职, 各自专注在自己擅长的领域, 形成了 1+1+1>3 的协同发展模式.
基于这种模式, 我们开启了通用性能测试的建设. 这包括几部分内容:
测试驱动方法标准化, 提供双端 (Android 及 iOS) 一致的自动化执行方案;
测试环境标准化, 为保证性能测试的准确性, 全部辅助测试手段采取外置化(例如视频采集不通过录屏而通过外部拍摄的方式), 同时对测试环境温度, 网络环境, 以及视频拍摄所需的亮度, 拍摄可控性等提出了严格的要求;
测试方案标准化, 选用什么样的设备, 测试哪些场景, 以及执行过程和结果采集点的制定均实现标准化规范化;
测试流程服务化, 整个测试的执行环节通过平台化的能力以服务的方式提供出来, 可以和其他平台和流程服务对接, 以便快速在业务平台和版本发布流程中落地.
不同业务方原本具有不同的自动化能力选择, 整体驱动模式不统一, 测试用例管理和适配比较困难, 复用性非常不理想. 推动测试驱动方式标准化, 各方统一基于一套方案进行开发是推动整体性能测试标准化的基础. 基于对测试需求的分析, 我们选择了蚂蚁集团基于 Appium 改良而来的测试框架 Totoro, 并对 Totoro 的接口按照优酷的测试需求进行了二次封装, 实现了自己的自动化测试驱动框架.
在测试方案标准化上, 我们优先确定了测试设备的配置. 为了更好的量化不同机型上的性能表现, 我们基于优酷在线上占比 TOP30 以内的机型, 按照其性能打分的情况进行筛选, 最终确定高, 中, 低端 3 款机型作为测试承载机; 测试场景的选择和建设则参考用户核心使用场景进行筛选, 确保用户体验得到最大化的保障.
测试环境标准化建设是通用性能测试方案投入较多的部分. 我们知道温度对手机的性能影响比较大, 有些机型甚至会在高温下出现降频保护以及充电保护等情况. 测试温度的处理极大的影响着测试的可重入性, 决定了一种测试方案是否可以被接受. 考虑到外部拍摄的需求, 测试环境需要是一个相对密闭的环境以确保环境亮度等符合拍摄需要, 这就对散热控温提出了更高的要求.
在拍摄设备的选择上, 需要同时考虑拍摄质量, 拍摄的可控性及软硬件成本. 拍摄质量不用赘述. 拍摄的可控性是指拍摄设备可配置和调试的程度, 因为被拍摄的场景和被摄机的型号众多, 拍摄设备必须具备强大的灵活性并保持高质量的拍摄效果, 例如:
最基本的拍摄参数例如分辨率, 码率, 比特率, 编码格式等等需要可调;
高级设置如景别设置, 曝光参数调整, 对焦能力调整, 曝光和对焦的锁定能力等;
合理的软硬件成本.
也许有读者会觉得这么复杂和麻烦, 为什么不用录屏的方式, 岂不方便. 经我们测试, 录屏方案在低端机型上会对性能数据带来 10% 甚至更多的影响, 而且这个偏差会跟着测试场景的变化出现浮动. 这对于准确度要求较高的性能测试来说几乎是不可接受的. 因此, 优酷的通用性能测试从起步阶段就选择了外部拍摄的方案.
经过对测试环境和拍摄方案的调研, 首批的通用性能测试环境基于硬板纸盒和千元级别的安卓手机搭建起来了, 效果如下.
选用纸盒的原因是纸盒可以快速的完成测试环境的组装, 并且可塑性非常好. 选用安卓手机作为拍摄装置是在比较了多个摄像头, 专业拍摄装置以及多款安卓手机的拍摄效果和可控性之后做出的选择. 利用上面的这套环境, 在实验室全程空调 + 风扇的照顾下, 短时间内通用性能测试基本满足了业务测试的需求. 然而, 这套环境的缺点也非常明显: 不够标准化, 对外部环境依赖较高. 为此, 我们又开发并搭建了新的测试环境, 提供了一套可插件化扩展的标准化测试支持装置.
测试设备和拍摄设备的部署在这套环境中均是标准化的, 在环境装置内部散热组件的加持下, 即便在外部环境温度 30 度以上的情况下, 测试环境中的环境温度和被测设备的电池温度均保持在 30 度左右并且非常平稳. 启动或停止散热装置情况下被测设备电池温度的变化情况可以参考下图, 整套环境在温度保持方面的效果是非常明显的.
整个通用性能测试方案基于优酷客户端测试平台得到了比较好的平台服务化; 魔镜也完成了从本地化工具到线上服务化的转化. 通用性能测试解决方案以服务化的形态整体提供出来, 非常易于被业务方的测试平台所调度.
通用性能测试可以实现的测试场景较多. 加载时间类的测试可以按阶段细分. 例如一次启动, 从应用首页框架开始加载, 到部分组件加载完成, 到整体加载完成, 把这个过程分阶段展示出来, 可以有效帮助开发团队分析性能瓶颈问题. 某个场景测试结果的效果样式如下:
对于基础数据相关的测试, 优酷客户端测试平台提供了完善的图形化的展示形式, 在数值维度提供了均值和标准差, 便于业务方对结果进行综合判断. 一个 DEMO 场景下 FPS 及丢帧率采集的示意结果如下图:
一个多次采样场景下明显出现内存泄露的内存采集效果如下图:
三, 总结
目前优酷移动架构团队在建设性能测试和性能问题分析整合的项目, 其目的是在完成性能测试的同时, 给出潜在的性能问题建议, 帮助开发快速定位和解决性能问题. 同时我们在进一步完善平台化建设, 争取提供更多维度的结果聚合, 分析和展示. 在标准化环境建设方面, 我们还在进一步完善配套的插件环境与模型, 争取让测试环境更加齐备, 配置型更高, 成本更低.
利用通用性能测试, 开发和测试团队可以非常方便了解到性能验证的结果以问题. 基于这套解决方案, 优酷技术质量部支持了绝大多数业务的性能测试需求, 包括优酷主客户端在双 11 前的性能专项优化和直播及各项配套业务的性能验证, 发挥了巨大的作用. 这套测试方案不仅仅适用于优酷, 对各种客户端的性能验证均可以发挥作用.
作者简介:
翀宸, 阿里文娱技术专家.
来源: http://www.tuicool.com/articles/rmAz6zR