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

导语

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

简述

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

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

目标与战法

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

提供给开发的信息具有精准性（必备）；

测试方法高效，测试数据稳定可靠（必备）；

使用的分析方法具有高可信度（必备）；

测试熟练使用工具帮助开发定位性能问题（可选）。

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

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

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

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

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

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

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

图一 流畅度样本

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

性能测试框架设计

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