Android 性能测试之方向与框架篇

导语

借项目的开发周期,把思考了一段时间的场景化性能测试框架搭建起来,包括 耗电性能测试、内存泄漏测试、UI流畅度性能测试、后台接口性能测试、app启动速度测试等。方案应用于项目的测试,也发现了产品中的不少问题。 接下来将用七八个篇幅详细记录一下心路历程。为分享轮子或为回忆总结。

简述

性能测试,在通信设备测试界,是一个非常成熟的领域,IETF组织在这个范畴制定了诸多RFC以规范测试行为。但在笔者接触移动测试领域的四年里,性能测试仿佛是一个可有可无的专项;性能问题,在各个项目中,总是停留在“用户报障->开发关注 -> 测试复现”。

显然,如果性能问题,如果也能最大限度的按照“测试发现->问题定位 ->开发修改”的正常流程来走,对产品质量是有非常大贡献的。下文的介绍,目标就在于此:测试过程中,测试工程师识别更多的产品关键场景,通过场景化、工程化、自动化的测试手段,发现更多的性能问题,使得性能BUG收敛于产品发布前。

目标与战法

尝试概括下性能测试:通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。成功的性能测试,会具备以下几个特点:

  1. 提供给开发的信息具有精准性(必备);
  2. 测试方法高效,测试数据稳定可靠(必备);
  3. 使用的分析方法具有高可信度(必备);
  4. 测试熟练使用工具帮助开发定位性能问题(可选)。

提供给开发的信息具有精准性。如果测试或用户告诉开发同学:“你们这个版本性能很差!”、“用着用着手机就开始发烫了,你搞定一下!”开发同学内心肯定是迷茫的。

如果测试将自己的措辞换成:“资讯页面,观看视频过程耗电量高,这个版本比上个版本jiffs高了30%。”,这样开发团队可以根据模块指定跟进人,知道具体的路径,知道耗电量的优化目标(这个版本多出的这30%),那问题的推进必然会更加顺利。

测试方法高效,测试数据稳定可靠。在设计本框架前,团队执行性能测试,包括长板性能测试(亮屏后台耗电及内存)、手工驱动的场景性能测试、基于页面驱动的流畅度测试。

1、 长板性能,场景过于单一,基本只校验了管家后台进程无任何操作下的性能表现;

2、 相比于UI自动化驱动,手工测试无法保证收集到大样本数据(让人反复做一个操作30分钟,这种任务毫无疑问是对员工的摧残);

3、 页面驱动的流畅度测试,经常出现两次对同一版本的测试得出截然不同的测试结果,测试数据不稳定,难以向开发证明其代码有问题。后文介绍流畅度测试时再详述优劣。

使用的分析方法具有高可信度。传统的分析方案中,往往简单地采用均值来评估性能项。笔者认为,合理的选用评估算法,也能让你的测试报告更有说服力。一个存在少量毛刺的数据序列,如下图,由于毛刺偏离严重,将严重拉低平均值。多一个毛刺,少一个毛刺,均值都会有很大不一样,在样本量较少时,往往会出现两次测试获得的性能数据差异大的问题。(如何解决后面详述)。

图一 流畅度样本

测试熟练使用工具帮助开发定位性能问题。测试左移一点,多做一点,开发就可以少花一点精力在缩小问题访问上。在功能测试中,一个BUG从偶然复现到找到必现路径,会让开发减少大量定位问题时间。同样,在性能测试中,如果测试能指明哪个线程是功率消耗大户,哪个对象是内存泄漏祸首,那么开发也能更加迅速地修复问题。同时,测试在定位过程中,不仅仅提升了自身能力,也建立起了自己的技术形象。

性能测试框架设计

如下图,本次设计的性能测试框架,包含有数据收集、数据分析、UI自动化、驱动框架四个模块,各自独立解耦。这样设计能够降低用例接入成本,可扩展性好。

图二 框架设计原理图

数据收集方案

我们需要通过一种或多种数据,直接反应一项性能的好坏。所以如何收集数据样本?收集那些数据样本,是性能测试框架必备的一个模块。

UI驱动方案

移动客户端的性能测试,主要是模拟用户操作来创造类用户使用场景,获取使用过程中的CPU、mem、流畅度等数据,以衡量该使用场景下,被测应用的性能指标。

本框架的UI自动化框架,选择了python 版的uiautomator(GitHub开源代码)。主要有如下几点原因:

  1. 数据收集模块需要使用adb工具,做adb输出结果处理、文本分析,python在这方面有较大优势,代码量低;
  2. Xiaocong封装的开源python版uiautomator,非常轻量级,功能全面,直接使用开源项目,能够节省非常多的框架开发时间;

驱动框架介绍

在本框架中,测试人员能够用如下的命令行直接驱动一个或多个用例的执行,所以设计了类testng逻辑的方案。

  • Python startTest.py -t 3 -c SwitchTabTest
  • Python startTest.py -t 3 -m SwitchTabTest,swipeDownTest

如下图,CaseExecutor类用来驱动和组织各个用例的suite_up(),set_up(),test(),tear_donw(),suite_down()等方法。

图三 类junit的驱动部分

而用例中包含的这些方法,主要作用是:

a) suite_up() : 用于执行初始化环境

b) set_up() : 主要用于拉起相应的性能数据收集线程、使用UI自动化初始化应用到被测场景,如闪屏滑动,进入主页等。

c) test() : UI自动化执行场景的关键逻辑,如:测试“连续播放不同视频”场景的内存泄漏。则用例需要在test()方法中,使用uiautomator实现循环点击不同视频播放的逻辑。

d) tear_down() : 该方法主要用于通知数据收集线程停止数据收集,进行数据归档;

e) suite_down() : 该方法将清空环境,将所有数据汇总到报告中,并使用数据分析算法得到可以直接用于报告的内容。

图四 执行逻辑

如图四,UI自动化在test()中执行相应场景时,性能数据收集线程会持续收集性能数据

注明:上述的五个步骤并不需要在每个case中实现,对应同一专项,除了test(),其他四个方法,都具有相同的逻辑,抽象到父类中实现即可,这样可以做到同一个专项下的不同场景用例,只需要写一个test方法。

数据分析方案

拿到数据后,想要最大化数据的价值。合理合适的数据分析方案显得尤为重要。笔者一开始做性能测试,所能想到的也就是拿到一大堆样本数据,取平均值,再做对比分析。

本框架试图提供除了平均值外,提供其他更为丰富的数据来评估各类性能指标。包括:

a) 中位数:以它在所有标志值中所处的位置确定的全体单位标志值的代表值,不受分布数列的极大或极小值影响,从而在一定程度上提高了中位数对分布数列的代表性。中位数用于评估网络延迟样本,效果明显优于平均值。原因在于,如大部分延迟在20ms时,其中有几个异常样本值2000ms以上,它们会严重拉高均值,导致均值不能完全代表该延迟数据序列。

b) 方差与标准差:结合均值来评估数据序列,可以评估到数据序列的离散程度。

c) 分布图或分布表:分布图或分布表也能比较好的评估一个数据序列的好坏,用它来做流畅度、网络带宽、网络延迟等性能评估,能够比较直观、详细地给出对比结果。

图五 流畅度优化效果示意

d) 曲线图:内存性能的评估,最优解莫过于占用曲线+ 平均值了。

图六 占用内存曲线

f) 平均值:最传统的均值,依然是一柄利器。

g) 极大值、极小值。

必要的说明

框架使用了开源代码:

  1. https://github.com/xiaocong/uiautomator
  2. https://testerhome.com/topics/6938

以上对具体代码的介绍比较少,后续几篇继续阐述下具体逻辑是怎么实现的。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏linux驱动个人学习

Cache 和 Buffer 都是缓存,主要区别是什么?【转】

1014
来自专栏Java架构

互联网一线大厂都在用的Java架构师知识体系

一、源码分析源码分析是一种临界知识,掌握了这种临界知识,能不变应万变,源码分析对于很多人来说很枯燥,生涩难懂。源码阅读,我觉得最核心有三点:技术基础+强烈的求知...

842
来自专栏程序工场

阿里巴巴、百度、腾讯都在用的Java架构师知识体系

源码分析是一种临界知识,掌握了这种临界知识,能不变应万变,源码分析对于很多人来说很枯燥,生涩难懂。

702
来自专栏服务端思维

深入架构,送你一份「Java架构师知识体系」

源码分析是一种临界知识,掌握了这种临界知识,能不变应万变,源码分析对于很多人来说很枯燥,生涩难懂。

802
来自专栏钱塘大数据

“别再问我什么是大数据了”一个单身程序汪的自白

N次聚会,N种人问我:“哎!你们做大数据的到底是做什么的呀?”每每到此,我都会回答他们:大数据只是一种工具,没有那么神秘,和一支铅笔,一双筷子,一把钥匙的原理是...

3019
来自专栏斑斓

结束语与参考文献

四. 结束语 遗留系统的技术栈迁移可能是一个漫长艰苦的过程,它的难度甚至要高于新开发一个系统,这是因为我们常常会挣扎在新旧系统之间,并在不断的妥协、权衡中缓步前...

3487
来自专栏架构师之路

58同城推荐系统架构设计与实现

主题 58同城推荐系统架构设计与实现 一、推荐系统架构介绍 推荐系统是一个微庞大的工程、算法与业务综合的系统,其主要分为三大子系统: 1)线下推荐子系统; 2...

3988
来自专栏性能与架构

网站性能指标 - Apdex指数

假设有两个架构设计方案:方案A 和 方案B 方案A 并发请求 < 200 时,响应时间为 0.5秒 并发请求 > 1000 时,响应时间为 10秒 方案...

3017
来自专栏SDNLAB

DPDK加速FPGA支持,强强联手助力数据中心网络加速

DPDK在专注数据面报文处理的同时,一直紧跟着网络发展的脉搏以开放的姿态融合不断涌现的各种新的网络设备。从最初的普通网卡,到集成虚拟化和交换功能的高级网卡,再到...

983
来自专栏Spark学习技巧

入门大数据必读

956

扫码关注云+社区