作者：TMQ melodyliu
转载自 ：https://testerhome.com/topics/5546
APP要做性能测试，什么样的数据能反应应用的性能情况，如何评估应用的性能状态？ 不知道该如何入手？一起来分析下如何给APP做性能测试。
性能测试三要素：性能指标、测试场景、测试工具。
首先要思考选哪些指标来评估性能：内存、cpu、电量还是什么？接着，选择你需要测试的场景，测试场景描述了你需要在何种场景下取性能数据，要测试APP何种功能等等。最后，根据你的指标和场景选择适合你的测试工具。
下面就从这三方面来具体分析。
性能指标
常见的性能指标有：内存、CPU、电量、流量、速度/耗时。这里从2个角度分析：
1）为什么选这个指标？
2）指标常用单位有哪些？
着重讲下关注最多的：内存、CPU。
1. 内存
为什么要选内存呢？需要知道Android的OOM和Low Memory Killer。
OOM：Out Of Memory，顾名思义是说内存不够用或者耗尽了，进程会被强制终止。安卓框架限制了每个应用进程所占用的最大内存值。关注内存的一个目的就是避免内存使用过大，出现OOM。主要关注内存使用较多时的场景，例如游戏app正在游戏中。
Low Memory Killer：Low Memory Killer在用户空间中指定了一组内存临界值，当其中的某个值与进程描述中的oom_adj值在同一范围时，该进程将被Kill掉。如果你的APP某个进程需要一直保存存活，你需要保持你的进程优先级足够高，并且占用比较小，因为Low Memory Killer在工作时，同一优先级的进程会先kill那个占用最大的。性能测试时主要关注待机时的内存是不是够小。
这里再补充一点：Low Memory Killer的工作可能致系统变卡。为什么呢？因为它kill了一些进程，然而现在市面的很多APP为了保活都会自启，刚刚被kill，立刻又起来。启动占用大量内存（还有CPU），又触发Low Memory Killer。频繁的被kill和启动形成了恶性循环，so…系统变的很卡。
内存指标有VSS、RSS、PSS、USS。差别如下：
VSS- Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS- Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS- Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS- Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS。
测试中比较常见的的选择是PSS total，这种算法共享库内存按比例分配，对APP来说比较公平。依据APP关注点，也可选择其他指标例如USS，或者将其他指标也一起统计，用于分析。
例如用dumpsys meminfo命令看到，手机管家进程的pss total = 16708 kb。
2. CPU
为什么要关注CPU？
（1）CPU使用率
想必你肯定有这样的经历：玩某个游戏或者APP的时候，手机发热发烫。是的，CPU的频繁使用，会让你的手机发烫，让你的手机变卡（CPU资源不足）。如果让用户发现你的APP用起来发烫，那就等着他的吐槽和卸载吧。
也就是说CPU性能，我们需要关注APP使用中CPU消耗情况，通常会使用CPU使用率这个指标。
（2）CPU jiffies
如果APP在退出界面后还有进程长期运行，那你需要关注下待机场景的CPU。待机场景下CPU的消耗一般不会很大，例如手机管家，可能消耗经常是0%，1%，长时间平均下，可能只有0.1%、0.2%，看看竞品，也是差不多，好像没有太大区别。
那么CPU消耗这么少是不是就不用管CPU了呢，然而即使是平均值很小，但是长时间待机，例如安全类工具，CPU的消耗还是不容忽视。那么这种情况如何评估CPU呢，这里引入一个更精确的指标：CPU时间片： jiffies！
Jiffies：为Linux核心变数(unsigned long)，它被用来记录系统自开机以来，已经过了多少tick。一定时间占用的jiffies可以反映出此进程的CPU消耗。
Android系统可以获取到APP进程当前的CPU jiffies（这个数值不断累加）。我们测试时常用的单位有：消耗XX jiffies/分钟；半/1小时共增加XX jiffies。
Tips :Jiffies与变频
Linux 内核中提供了 performance 、powersave 、userspace、conservative 和 ondemand 五种变频模式供用户选择使用，它们在选择 CPU 合适的运行频率时使用的是各自不同的标准并分别适用于不同的应用场景。那么，测试CPU jiffies的时候是否需要固定CPU频率呢？理论来讲，固定CPU 频率肯定是可以的，那么不固定会怎样呢？
经测试数据验证，保持手机同环境情况下，不固定CPU频率对于测试无太大影响。
这组测试数据是没有固定CPU频率情况下测试了5次的jiffies数据（每次30min），可以看出，标准差为1.56，波动并不大，基本可以排除变频的影响。
3. 电量
手机电池资源有限，电量的重要性就不必说了。现在很多手机都有电量排行，如果你的APP总是排在前面，小心被卸载哦。电量通常的单位是：mAs或者mAh。
4. 流量
手机的一个特点就是有移动网络。移动网络下的流量消耗需要特别关注，wifi下的流量优先级略低。流量单位：kb，M。
5. 速度/耗时
可用性原则里面有个2秒原则：一个松散的原则，即用户没有必要对某些系统响应等待2秒以上的时间，比如应用程序转换和开始的响应时间。对于启动APP，进入某页面，这些操作时间都应不超过2秒，且越短用户体验越好。
当然，2秒并不是绝对的，对于一些用户感知明显的功能，例如垃圾扫描，病毒查杀，可能需要更多的时间，但是操作进行期间，需要给用户适当的感知和预期，避免用户因等待过久而离开。当然，用户是期望能够又准又快。
测试场景
性能要测哪些场景呢？用户实际使用中，场景是多种多样的。拿手机管家来说，有的用户每天喜欢拉拉小火箭；有的用户经常安装卸载app；有的用户喜欢用它清理垃圾；又有的用户有很多骚扰电话和短信；还有用户喜欢用它连免费wifi；另一些用户安装后不怎么使用。用户多种多样，功能多种多样，场景多种多样。要测试性能，这么多场景全部覆盖是不太可能的，要选择什么场景比较合适呢？
选择性能测试场景前，我们可以先将上述说的这些场景来分分类。
从用户使用APP时APP的activity是否在最前端，可将APP的使用场景分为：前台、后台。
在后台时根据APP只是保持心跳等最基础功能，还是一些场景触发了相关功能，可分为：后台待机和后台使用场景。
于是我们有了下面三个层次的场景：后台待机、后台使用、前台使用，场景模型如下：
1. 场景与性能指标
先说说这些场景要关注些哪些性能指标。
（1）后台待机
指标：重点关注待机内存和待机耗电情况。流量有需要则关注。
内存和耗电可取实际测试值作为数据。例如待机内存19M；24h待机电量3mAh。如果你的APP的耗电模块主要是CPU，你可以考虑使用CPU 时间片（jiffies）来评估。
测试时长：这个场景的耗电和CPU消耗会比较小，测试时需要考虑较长时间的测试数据以便反应APP的性能情况。
（2）后台使用
指标：重点关注一个场景触发APP功能时的内存、CPU使用率或电量。
内存通常会取增量，即：触发功能后的内存-触发前的待机内存，作为某功能消耗的内存。
（3）前台使用
常关注使用时的内存、CPU使用率、流量。如果是某个操作需要一些时间，需要关注速度和耗时。
2. 场景与用户感知
（1）后台待机
这个场景下用户的感知是：我没有使用这个APP，因此这种场景如果有性能消耗的情况下，一定是非常小的，否则用户会认为：我没用都占这么大内存！耗这么多电！让用户有这种感受是非常危险的。
例如：手机管家只在通知栏有个小图标，用户没有感觉自己在使用。
（2）后台使用
这个场景下APP确实进行了一些工作，但是用户对于自己使用了APP并不会有特别明显的感知。例如来电话时手机管家会进行电话的识别以判断是不是骚扰电话等，用户看到的是一个来去电悬浮窗，但是用户并没有主动使用，因此这种情况下性能消耗也不可以过高。
（3）前台使用
这个场景是用户打开了APP进行使用，此时的性能消耗也是比较大的，但是用户的容忍度也会相对比较大。但是OOM导致闪退、手机发烫这些现象是绝对不允许的。性能消耗当然是越小用户越喜欢。
3. 场景与测试优先级
场景分层图中，三个层次场景成金字塔形状，他们的占用面积同时反映了他们在用户侧使用时占用的时长。
这么多场景，时间有限，哪个场景更重要，我应该先测哪个呢？下面说说如何评估这些场景的重要程度和优先级。
原则：用户在该场景停留越久，该场景越重要；场景被用户使用到的频率越高，该场景优先级越高。评估方法有：
（1）运营数据评估
对于后台待机场景，我们使用时长来评估优先级。重要程度=时长（数值越高越重要）。从运营数据中我们可以得到场景1、2、3在用户侧使用的时长T1、T2、T3。例如用户平均每天亮屏5小时，灭屏19小时，那么灭屏待机场景重要程度=19，高于亮屏的5。
对于后台使用和前台使用场景，我们用使用频率来评估，优先级=N，N=几天1次（数值越小优先级越高）。例如：收短信场景，这个场景每个用户每天都会遇到；而安装/卸载APP这个场景，用户可能平均5天操作一次。那么收短信场景的优先级=1，安装卸载app场景优先级=5。
（2）ACC测试建模
当我们没有获得运营数据时，可以考虑使用ACC建模思路来帮助区分性能场景优先级：分析产品的核心价值；分析产品的主要模块、系统；FENIX每个系统提供何种能力实现产品价值；区分优先级。
测试工具
测试工具的本质是获取性能数据，当然一些工具在使用和观察数据上有差别。工具分2类：现有工具，其他获取方案。这里列举下目前我们常用的工具共选择和参考：
手工和自动化测试
如果是新手或者只需测试几次，可考虑手工进行性能测试，建议选择方便直观易用的工具。测试内存和CPU使用率，推荐使用APT（http://code.tencent.com/apt.htmleclipse插件，可实时监控Android手机上多个应用的CPU、内存数据曲线，直观方便。），它最为
如果是需要长期测试的内容，需要考虑自动化测试。自动化测试方案我们常用UIAutomator来实现，其中获取性能数据的方案，可查看上表。
这里需要特别提下，在获取CPU 时间片（jiffies）数据时需要注意，测试工具应该做尽量少的事情（不要同时用dumpsys meminfo获取内存会增加该进程的CPU消耗），减少对被测app性能的影响，选择性能消耗小的方式。建议：工具获取方式从系统文件/proc/(pid)/stat读取CPU jiffies，不做其他测试内存等等事情。
性能测试构建
到这里为止，对于APP性能测试的指标选择，场景选择，用什么工具有了一定了解。我们可以构建性能测试了。
例如，手机管家需要长期关注一些重点性能指标，指标则选取了：内存和耗电，启动速度。由于用户在使用管家过程中，大部分时间都是处于“后台待机”场景，故我们选择测试的场景是：灭屏待机，亮屏待机。
内存使用PSS total，耗电由于主要耗电模块是CPU，因此我们选择使用CPU来评估耗电，待机CPU消耗小，故使用了CPU时间片 jiffies。
基础指标性能测试构建如下：
当然，除了这些基础指标，我们还需要测试其他场景，但可能不是每个版本都测。对于手机管家，三个层次的场景测试频率如下：
具体每个场景的分析，测试频率参考：
最后，测试数据如果是单次、单个是没意义的，我们通常用两种方法做对比：历史版本对比、竞品对比。
当你要着手给APP做性能测试时，记得分析APP性能测试的三要素：性能指标、测试场景、测试工具，体系化构建你的性能测试任务，让APP性能保持优秀，运行更顺畅。
本章完~
原文连接：http://tmq.qq.com/2016/07/triangle-explaining-app-performance/
TMQ（腾讯移动品质中心）是腾讯最早专注在移动APP测试的团队
我们专注于移动测试技术精华，饱含腾讯多款亿级APP的品质秘密，文章皆独家原创，我们不谈虚的，只谈干货！