APP性能测试——基于手机的专项测试

转载自http://bbs.51testing.com/thread-1199231-1-2.html
我之前的APP性能测试是基于服务端的，这里收藏一个基于手机的专项测试。

Android篇

性能测试
Android性能测试分为两类：1、一类为rom版本（系统）的性能测试
2、一类为应用app的性能测试
Android的app性能测试包括的测试项比如：
1、资源消耗
2、内存泄露
3、电量功耗
4、耗时
5、网络流量消耗
6、移动终端相关资源利用率
7、帧率
8、渲染等等…

工具：
（工具的原理都是基于调用android底层的一些api来获取到测试所用到的值）GT等

测试方法：
1、设计场景：手工或自动化场景
2、获取数据：可获取的数据包括：内存、cpu、电量功耗、hprof（内存泄露分析文件）、响应时间等等。。。。配合手工或自动化场景来获取数据（最好多取几次而且每次配合不同的设备看平均值）作为最后的对比分析
3、结果分析：拿到数据后分析哪些模块的数据异常再去Check code定位问题的原因

Android系统的几种场景状态：
1、空闲状态：指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲
2、中等规格和满规格状态：中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短

1.1 内存篇
背景知识：
C/C++申请的内存空间在native heap中，而java申请的内存空间则在dalvik heap中。这个是因为Android系统对dalvik的vmheapsize作了硬性限制，当java进程申请的java空间超过阈值时，就会抛出OOM异常（这个阈值可以是48M、24M、16M等，视机型而定），可以通过adb shell getprop | grep dalvik.vm.heapgrowthlimit查看此值。也就是说，程序发生OMM并不表示RAM不足，而是因为程序申请的java heap对象超过了dalvik vmheapgrowthlimit。也就是说，在RAM充足的情况下，也可能发生OOM。

这样的设计似乎有些不合理，但是Google为什么这样做呢？这样设计的目的是为了让Android系统能同时让比较多的进程常驻内存，这样程序启动时就不用每次都重新加载到内存，能够给用户更快的响应。迫使每个应用程序使用较小的内存，移动设备非常有限的RAM就能使比较多的app常驻其中。但是有一些大型应用程序是无法忍受vmheapgrowthlimit的限制的

实际上dalvik.vm.heapgrowthlimit和dalvik.vm.heapsize都是java虚拟机的最大内存限制，应用如果不想在dalvikheap达到heapgrowthlimit限制的时候出现OOM，需要在Manifest中的application标签中声明android：largeHeap=“true”，声明后应用dalvik heap达到heapsize的时候才会出现OOM

内存测试中的测试子项：
1）空闲状态下的应用内存消耗情况
2）中等规格状态下的应用内存消耗情况
3）满规格状态下的应用内存消耗情况
4）应用内存峰值情况
5）应用内存泄露情况
6）应用是否常驻内存
7）压力测试后的内存使用情况

内存问题现象：
1）内存抖动
2）大内存对象被分配
3）内存不断增长
4）频繁GC

内存数据获取：
1、各种linux命令（top、free、meminfo…）
2、通过dumpsys
adb shell dumpsys meminfo [pakagename | pid]
3、通过/system/xbin/procrank工具

adb shell procrank
说明：
VSS – Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS – Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS – Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS – Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存） USS 是针对某个进程开始有可疑内存泄露的情况，是一个程序启动了会产生的虚拟内存，一旦这个程序进程杀掉就会释放。不过USS需要通过root的手机。一般没有root的手机我们可以获取PSS。而PSS通过如下命令来获取：adb shell dumpsys meminfo |grep TOTAL

4、通过android提供的procrank
1）首先去google获取procrank、procmem、libpagemap.so三个文件
2）然后push文件，执行 adb push procrank /system/xbin adb push procmem
/system/xbin adb push libpagemap.so /system/lib
3）赋权 adb shell chmod 6755 /system/xbin/procrank adb shell chmod 6755 /system/xbin/procmem adb shell chmod 6755 /system/lib/libpagemap.so ,
4）在开启工具记录 adb shell procrank |grep packagename >/address/procrank.txt

5、通过android提供的ActivityManager的getMemoryInfo(ActivityManager.MemoryInfo outInfo)（这个方法是写一个简单的app去监控的时候用到的，轻便简单）

private void GetMemory()
{
final ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
ActivityManager.MemoryInfo info = new ActivityManager.MemoryInfo();
activityManager.getMemoryInfo(info);
Log.i(tag,“系统剩余内存:”+(info.availMem >> 10)+“k”);
Log.i(tag,“系统是否处于低内存运行：”+info.lowMemory);
Log.i(tag,“当系统剩余内存低于”+info.threshold+“时就看成低内存运行”);
}
MemTotal: 所有可用RAM大小。 MemFree: LowFree与HighFree的总和，被系统留着未使用的内存。
Buffers: 用来给文件做缓冲大小。 Cached: 被高速缓冲存储器（cache memory）用的内存的大小（等于diskcache
minus SwapCache）。 SwapCached:被高速缓冲存储器（cache
memory）用的交换空间的大小。已经被交换出来的内存，仍然被存放在swapfile中，用来在需要的时候很快的被替换而不需要再次打开I/O端口。
Active: 在活跃使用中的缓冲或高速缓冲存储器页面文件的大小，除非非常必要，否则不会被移作他用。 Inactive:

在不经常使用中的缓冲或高速缓冲存储器页面文件的大小，可能被用于其他途径。 SwapTotal: 交换空间的总大小。 SwapFree:

未被使用交换空间的大小。 Dirty: 等待被写回到磁盘的内存大小。 Writeback: 正在被写回到磁盘的内存大小。
AnonPages：未映射页的内存大小。 Mapped: 设备和文件等映射的大小。 Slab:

内核数据结构缓存的大小，可以减少申请和释放内存带来的消耗。 SReclaimable:可收回Slab的大小。
SUnreclaim：不可收回Slab的大小（SUnreclaim+SReclaimable＝Slab）。
PageTables：管理内存分页页面的索引表的大小。 NFS_Unstable:不稳定页表的大小。

1、运行Monkey进行压力测试：
adb shell monkey -p cn.microinvestment.weitou --pct-touch 100 --ingore-crashes --throttle 1000 -s 100 -v -v 50

2、监控内存值，如果出现过大等递增异常则保存HPROF文件（hprof文件是Java 虚拟机的Heap快照）用于分析查看应用内存的命令：
adb shell dumpsys meminfo cn.microinvestment.weitou(进程名)
如果发现内存过大，则保存HPROF文件：adb shell am dumpheap <进程名> <保存路径>

3、分析hprof文件
用工具MAT来查看，首先还要这个HPROF文件转换成MAT可读的文件
在Android SDK tool里面有个hprof-conv命令：
hprof-conv <原HPROF文件路径> <转换后的HPROF路径>
hprof-conv a.hprof b.hprof

4、用MAT工具打开转换后的HPROF文件
一般选择Leak Suspects Report（通过SQL语句来查询对象有没有被释放掉，如果有多个相同的对象，则会存在内存泄露的问题）

1.2 CPU篇
CPU测试中的测试子项：
1）空闲状态下的应用CPU消耗情况
2）中等规格状态下的应用CPU消耗情况
3）满规格状态下的应用CPU消耗情况
4）应用CPU峰值情况
CPU数据获取：
1）adb shell dumpsys cpuinfo | grep packagename
2)top命令
adb shell top -m 10 -s cpu #查看占用cpu最高的前10个程序（-t 显示进程名称，-s 按指定行排序，-n 在退出前刷新几次，-d 刷新间隔，-m 显示最大数量）
adb shell top | grep PackageName > /address/cpu.txt

1.3 流量篇
概念：
中等负荷：应用正常操作
高负荷：应用极限操作
流量测试中的测试子项：
1、应用首次启动流量值
2、应用后台连续运行 2 小时的流量值
3、应用高负荷运行的流量峰值
4、应用中等负荷运行时的流量均值

获取流量数据：
1、tcpdump＋wireshark
2、/proc/net/目录下相关文件
cat /proc/net/dev 获取系统的流量信息
3、查询应用的pid： adb shell ps | grep tataufo #如：31002
通过PID获取该应用的流量数据： adb shell cat /proc/31002/net/dev
（wlan0代表wifi上传下载量标识, 单位是字节可以/1024换算成KB, 打开手机飞行模式再关掉就可以将wlan0中的值初始化0）
4、查询应用的pid： adb shell ps | grep tataufo #如：31002
通过PID获取UID：adb shell cat /proc//status
通过UID获取：adb shell cat /proc/net/xt_qtaguid/stats | grep 31002
5、通过adb shell dumpsys package来获取应用的uid信息，然后在未操作应用之前，通过查看：
adb shell cat /proc/uid_stat/uid/tcp_rcv
adb shell cat /proc/uid_stat/uid/tcp_snd
获取到应用的起始的接收及发送的流量，然后我们再操作应用，再次通过上述2条命令可以获取到应用的结束的接收及发送的流量，通过相减及得到应用的整体流量消耗
6、Android代码：Android的TrafficStats类

1.4 功耗篇
功耗测试中的测试子项：
1、手机安装目标APK前后待机功耗无明显差异
2、常见使用场景中能够正常进入待机，待机电流在正常范围内
3、长时间连续使用应用无异常耗电现象

功耗测试方法：
方法一：软件
1、采用市场上提供的第三方工具，如金山电池管家之类的。
2、就是自写工具进行，这里一般会使用3种方法：
1）基于android提供的PowerManager.WakeLock来进行
2）比较复杂一点，功耗的计算=CPU消耗+Wake lock消耗+数据传输消耗+GPS消耗+Wi-Fi连接消耗
3）通过 adb shell dumpsys battery来获取
3、battery-historian（google开源工具）

方法二：硬件
一般使用万用表或者功耗仪安捷伦进行测试，使用功耗仪测试的时候，需要制作假电池来进行的，有些不能拔插电池的手机还需要焊接才能进行功耗测试

1.5 GPU篇（FPS）
概念：
过度绘制：界面显示的activity套接了多层而导致
帧率：屏幕滑动帧速率
帧方差：屏幕滑动平滑度
**FPS：**Frames Per Second 每秒显示的帧数根据人眼的生理结构，帧率高于24时就被认为是连贯的。对于游戏画面30fps是最低能接受的，60fps逼真感，如果帧率高于屏幕刷新频率就是浪费。要达到30fps，每帧所占用的时间要小于33毫秒

GPU测试中的测试子项：
1、界面过度绘制
2、屏幕滑动帧速率
3、屏幕滑动平滑度
过度绘制测试：（人工进行测试）
打开开发者选项中的显示GPU过度绘制（Debug GPU overdraw）

验收的标准:
1、不允许出现黑色像素
2、不允许存在4x过度绘制
3、不允许存在面积超过屏幕1/4区域的3x过度绘制（淡红色区域）

屏幕滑动帧速率测试：
方法一：
1.手机端打开开发者选项中的启用跟踪后勾选Graphics和View
2.启动SDK工具Systrace，勾选被测应用，点击Systrace，在弹出的对话框中设置持续抓取时间，在trace taps下面勾选gfx及view选项
3.手工滑动界面可以通过节拍来进行滑动或者扫动，帧率数据会保存到默认路径下，默认名称为trace.html
4.将trace.html文件拷贝到linux系统下通过命令进行转换，生成trace.csv文件
grep ‘postFramebuffer’ trace.html | sed -e ‘s/.]\W//g’ -e ‘s/:.*$//g’ -e ‘s/.//g’ > trace.csv
5.用excel打开文件计算得到帧率

方法二：
硬件的方法，打开高速相机，开启摄像模式，录制手工滑动或者扫动被测应用的视频，再通过人工或者程序数帧的方法对结果进行计算得到帧率
屏幕滑动平滑度的测试：
方法如同帧率测试，唯一的差异就是最后的结果计算公式的差异

捕获app帧率（android流畅度FPS测试）：
1、打开手机开发者选项，勾选GPU显示配置文件（系统会记录保留每个界面最后128帧图像绘制的相关时间信息）
2、adb shell dumpsys gfxinfo com.xxx.xxx > zinfo.txt

3、结果数据分析
Profile data in ms部分：
Draw：创建显示列表的时间（DisplayList），所有View对象OnDraw方法占用的时间
Process： Android 2D渲染引擎执行显示列表所花的时间，View越多时间越长
Execute：将一帧图像交给合成器（compsitor）的时间，较小

其他工具：
GameBench 测试android app的FPS工具
Gfxinfo 查看app绘制性能工具

APP性能测试——基于手机的专项测试相关推荐

摄像头防水性能测试软件,手机摄像头防水测试/手机摄像头气密性检测方法分享...
原标题:手机摄像头防水测试/手机摄像头气密性检测方法分享手机作为通讯消费产品,已成为了人们日常生活的必须品,伴随着光电及科学技术的发展,手机在原有通讯功能的基础上又新增多种功能,例如数码照相.看电视 ...
android下的app性能测试应主要针对那些方面，如何开展?
如何开展安卓手机下的App性能测试,对于优秀的测试人员而言,除了要懂得性能测试的步骤流程外,还应该懂的性能测试的一些其他知识,比如性能测试指标.各指标的意义,常用的性能测试工具.如何查看结果分析等等知 ...
Android app 性能测试以及专项测试
1. 性能测试 Android性能测试分为两类: 1.一类为rom版本(系统)的性能测试 2.一类为应用app的性能测试 Android的app性能测试包括的测试项比如: 1.资源消耗 2.内存泄露 ...
功能测试（八）—— APP之专项测试、性能测试、性能测试工具SoloPi
目录 APP测试要点目标一.APP专项测试 1.1 兼容性 1.2 安装 1.3 卸载 1.4 升级 1.5 干扰测试(交叉事件测试) 1.6 Push推送 1.7 用户体验二. 性能测试工具 ...
手机APP测试之专项测试
前言说到专项测试,大家的第一反应可能是流量测试.电量测试.弱网络测试等及其对应的专项测试工具.除了以上,关于专项测试我们还要知道: 1) 我应该在什么阶段去做专项测试. 2) 每个阶段做什么. 3) ...
app常见的专项测试以及面试题
1.为什么进行专项测试? 手工测试之后,自动化测试之后,接口测试,性能测试之后,线下环境.预发布环境都没有问题了,测试工作看似完整,但是到了用户生产环境,安装使用过程中还是有很多之前没有预料的问题被反 ...
移动App测试实战—专项测试
转自:http://www.51testing.com/html/58/n-3713758.html 我们在进行了手工的功能测试之后,也开发了一些自动化测试用例,并且做了性能测试之后,测试工作看似比较 ...
APP性能测试的6项关键指标及测试获取手段
如何把rom测试和手机预装APP测试得更好,用户体验.流畅度.功耗.启动时长等指标是中兴努比亚手机产品线最关注的层面.本文将从APP性能维度.性能测试平台等维度全面讲解中兴努比亚APP专项性能测试和监 ...
python自动化（四）app自动化：7.专项测试讲解
一.常见的测试手段二.专项测试的种类三.APP的启动性能 1.启动性能介绍启动分为冷启动和热启动,首页启动. 冷启动:应用程序首次启动,进程首次创建并加载资源的过程: 热启动:应用程序启动后点& ...

APP性能测试——基于手机的专项测试

APP性能测试——基于手机的专项测试相关推荐

最新文章

热门文章