性能测试，在通信设备测试界，是一个非常成熟的领域，IETF 组织在这个范畴制定了诸多 RFC 以规范测试行为。但在笔者接触移动测试领域的四年里，性能测试仿佛是一个可有可无的专项。性能问题，在各个项目中，总是停留在 “用户报障-> 开发关注 -> 测试复现”。
显然，性能问题，如果也能最大限度的按照 “测试发现 -> 问题定位-> 开发修改” 的正常流程来走，对产品质量是有非常大贡献的。下文的介绍，目标就在于此：测试过程中，测试工程师识别更多的产品关键场景，通过场景化、工程化、自动化的测试手段，发现更多的性能问题，使得性能 BUG 收敛于产品发布前。
尝试概括下性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。成功的性能测试，会具备以下几个特点：
（1）提供给开发的信息具有精准性 (必备)；
（2）测试方法高效，测试数据稳定可靠 (必备)；
（3）使用的分析方法具有高可信度 (必备)；
（4）测试熟练使用工具帮助开发定位性能问题 (可选)。
提供给开发的信息具有精准性。
如果测试或用户告诉开发同学：
“你们这个版本性能很差！”
“我们 APP 用着用着手机就开始发烫了，你搞定一下！”
开发同学内心肯定是迷茫的。
如果测试将自己的措辞换成：“我们 APP 资讯页面，观看视频过程耗电量高，这个版本比上个版本 jiffs 高了 30%。” 这样开发团队可以根据模块指定跟进人，知道具体的路径，知道耗电量的优化目标（这个版本多出的这 30%），那问题的推进必然会更加顺利。
测试方法高效，测试数据稳定可靠。
在设计本框架前，团队执行性能测试，包括长板性能测试（亮屏后台耗电及内存）、手工驱动的场景性能测试、基于页面驱动的流畅度测试。
（1）长板性能，场景过于单一，基本只校验了管家后台进程无任何操作下的性能表现；
（2）相比于 UI 自动化驱动，手工测试无法保证收集到大样本数据（让人反复做一个操作 30 分钟，这种任务毫无疑问是对员工的摧残）；
（3）页面驱动的流畅度测试，经常出现两次对同一版本的测试得出截然不同的测试结果，测试数据不稳定，难以向开发证明其代码有问题。后文介绍流畅度测试时再详述优劣。
使用的分析方法具有高可信度。
传统的分析方案中，往往简单地采用均值来评估性能项。笔者认为，合理的选用评估算法，也能让你的测试报告更有说服力。一个存在少量毛刺的数据序列，如下图，由于毛刺偏离严重，将严重拉低平均值。多一个毛刺，少一个毛刺，均值都会有很大不一样，在样本量较少时，往往会出现两次测试获得的性能数据差异大的问题。（流畅度数据具体如何解决将在后续流畅度篇中详述）。
图一流畅度样本
测试熟练使用工具帮助开发定位性能问题。
测试左移一点，多做一点，开发就可以少花一点精力在缩小问题访问上。在功能测试中，一个 BUG 从偶然复现到找到必现路径，会让开发减少大量定位问题时间。同样，在性能测试中，如果测试能指明哪个线程是功率消耗大户，哪个对象是内存泄漏祸首，那么开发也能更加迅速地修复问题。同时，测试在定位过程中，不仅仅提升了自身能力，也建立起了自己的技术形象。
如下图，本次设计的性能测试框架，包含有数据收集、数据分析、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 的驱动部分
而用例中包含的这些方法，主要作用是：
（1）suite_up() : 用于执行初始化环境；
（2）set_up() : 主要用于拉起相应的性能数据收集线程、使用 UI 自动化初始化应用到被测场景，如闪屏滑动，进入主页等；
（3）test() : UI 自动化执行场景的关键逻辑，如：测试 “连续播放不同视频” 场景的内存泄漏。则用例需要在 test() 方法中，使用 uiautomator 实现循环点击不同视频播放的逻辑；
（4）tear_down() : 该方法主要用于通知数据收集线程停止数据收集，进行数据归档；
（5）suite_down() : 该方法将清空环境，将所有数据汇总到报告中，并使用数据分析算法得到可以直接用于报告的内容。
图四执行逻辑
如图四，UI 自动化在 test() 中执行相应场景时，性能数据收集线程会持续收集性能数据。
注明：上述的五个步骤并不需要在每个 case 中实现，对应同一专项，除了 test()，其他四个方法，都具有相同的逻辑，抽象到父类中实现即可，这样可以做到同一个专项下的不同场景用例，只需要写一个 test 方法。
拿到数据后，想要最大化数据的价值。合理合适的数据分析方案显得尤为重要。笔者一开始做性能测试，所能想到的也就是拿到一大堆样本数据，取平均值，再做对比分析。
本框架试图提供除了平均值外，提供其他更为丰富的数据来评估各类性能指标。包括：
中位数：以它在所有标志值中所处的位置确定的全体单位标志值的代表值，不受分布数列的极大或极小值影响，从而在一定程度上提高了中位数对分布数列的代表性。中位数用于评估网络延迟样本，效果明显优于平均值。原因在于，如大部分延迟在 20ms 时，其中有几个异常样本值 2000ms 以上，它们会严重拉高均值，导致均值不能完全代表该延迟数据序列。
方差与标准差：结合均值来评估数据序列，可以评估到数据序列的离散程度。
分布图或分布表：分布图或分布表也能比较好的评估一个数据序列的好坏，用它来做流畅度、网络带宽、网络延迟等性能评估，能够比较直观、详细地给出对比结果。
图五流畅度优化效果示意
曲线图：内存性能的评估，最优解莫过于占用曲线 + 平均值了。
图六占用内存曲线
平均值：最传统的均值，依然是一柄利器。
极大值、极小值。
框架使用了开源代码：
https://github.com/xiaocong/uiautomator
https://testerhome.com/topics/6938
以上对具体代码的介绍比较少，后续几篇继续阐述下具体逻辑是怎么实现的。
关注微信公众号：腾讯移动品质中心 TMQ，获取更多测试干货！
