一、app性能测试
提到APP的性能测试这个概念比较笼统,因为APP的性能测试分为服务端的性能和手机端的性能测试
1.1、app服务端性能测试
app服务端的性能测试,利用jmeter等工具模拟并发,压测服务器系统,服务端性能测试,一般可以通过接口来测,关注的指标主要包括以下几个:
- 平均响应时间
- 错误率
- 吞吐量
- CPU/内存占用率
- 网络/硬盘的读写速度
1.2、app客户端性能测试
app客户端的性能测试,主要是指app运行操作过程当中,监测当前手机系统的一些性能指标,以此来确定app的性能是否会影响到用户的体验。app的性能指标主要包括以下几个:
- 启动速度
- CPU占用率
- 内存占用率
- 电量消耗
- 流量消耗
- 流畅度
2 测试方案及工具选择
2.1 perfdog
官网:https://perfdog.qq.com/
介绍:腾讯出品的移动全平台iOS/Android性能测试、分析工具平台。
特点:
- 无需ROOT/越狱
- 支持移动全平台
- 数据准确,工具本身对测试设备CPU的性能影响<1%,帧率无影响
- 应用广泛支持所有APP应用、游戏、小程序、小游戏、H5、web等
- 云端数据在线分析
- 支持团队合作
2.2 测试方案
2.2.1 启动时间
手机APP的启动时长是一个很容易被用户感知的性能指标,启动时长过长会让用户极不愿意继续等待。
因此启动时长是一项比较靠前的性能指标。APP的启时长分为两种情况,一种是冷启动时间,另一种是热启动。
- 冷启动:应用序首次启动,进程首次创建并加载资源的过程
- 热启动:指app没有被后台杀死,仍然在后台运行,通常我们再次去打开这个app,这种启动方式叫热启动
1)场景设计
冷启动
场景设计:清除后台所有应用,等待数秒 ,启动软件
热启动
场景设计:切换到桌面,等待数秒 ,重新切换回应用
2)测试方法
- 使用adb命令进行测试
冷启动:应用进程首次启动
- adb shell am start -W 包名/界面名
热启动:切换到主页后再启动应用
- adb shell input keyevent 3
- adb shell am start -W 包名/界面名
3)结果分析:
通过adb命令可获取的时间如下:
- ThisTime :该界面 ( activity ) 启动耗时(毫秒)
- TotalTime :应用自身启动耗时 = ThisTime + 应用 application 等资源启动时间(毫秒)
- WaitTime :系统启动应用耗时 = TotalTime + 系统资源启动时间(毫秒)
如何确定启动时间是否符合标准?
- 根据用户体验
- 和以往版本进行对比
- 横向对比,和同类产品一起测试,不超过同类产品的1倍
2.2.2 流畅度(FPS)
FPS是图像领域中的定义,是指画面每秒传输帧数,通俗来讲就是指动画或视频的画面数。FPS是测量用于保存、显示动态视频的信息数量。每秒钟帧数愈多,所显示的动作就会愈流畅。
FPS(1s内游戏画面或者应用界面真实平均刷新次数,俗称帧率/FPS)
- AVG(FPS):平均帧率(一段时间内的平均FPS)
- Var(FPS):帧率方差(一段时间内FPS方差)
- Drop(FPS):降帧次数(平均每小时相邻的个FPS点下降大于8帧的次数)
Jank(1s内卡顿次数)
- BigJank:1s内严重卡顿次数
- Jank(/10分钟):平均每十分钟卡顿次数
- BigJank(/10分钟):平均每十分钟严重卡顿次数
FTime(上下两帧画面显示时间间隔,即认定为帧耗时)
- AVG(FTime):平均帧耗时
- Delta(FTime):增量耗时(平均每小时两帧之间时间差>100ms的次数)
PerfDog-Stutter(卡顿率)
- PerfDog Stutter 定义:测试过程中,卡顿时长的占比。即Stutter(卡顿率)=卡顿时长/总时长
1)场景设计
打开被测软件的每一个页面进行测试
2)测试方法
在app上进行操作,使用perfdog工具采集数据
3)结果分析:
游戏方面
游戏流畅度是最影响用户体验的,所以需要重点关注FPS、Jank及卡顿率
APP方面
APP也需要关注FPS、Jank及卡顿率。只是需要区分使用场景,具体的数据对比可以和以往版本进行对比,也可和竞品横向对比。
- 静态页面窗
只需关注FPS,理论FPS应该为0,否则,说明有冗余刷新,容易引起手机发热及耗电。 - 有滚动动画页面窗口
只需关注FPS,FPS处于合适值即可,无需高频刷新。 - 快速滑动页面窗口
需要关注FPS、Jank及卡顿率。一般滑动状态下,帧率越高越好,Jank越小越好。 - 播放视频页面窗口
需要关注FPS、Jank及卡顿率,视频卡顿直接影响用户。视频一般帧率18-24帧,Jank=0。比如微信播放视频、视频播放器等。
2.2.3 CPU利用率
某些场景下我们去使用App,可能会碰到手机会出现发热发烫的现象。这是因为CPU使用率过高、CPU过于繁忙,会使得整个系统无法响应用户,整体性能降低,用户体验变得相当差,主要关注的是cpu的占用率
- CPU Usage:传统cpu利用率,也叫未规范化cpu利用率
计算方法:当前时刻cpu频率下,CPU Usage = CPU执行时间/CPU总时间,一般adb等获取的都是未规范化的cpu利用率 - CPU Usage(Normalized):规范化cpu利用率
由于移动设备CPU频率时刻变化,用传统CPU利用率计算方法,假定在低频率时刻计算出CPU利用率=30%,和在CPU高频时刻计算出CPU利用率=30%。同样都是30%但性能消耗是完全不样的,明显高频消耗更高。传统CPU利用率已无法真实反映性能消耗。
所以我们需要一种规范化(可量化)的统计方式。将频率因素考虑进去。
CPU Usage(Normalized)= (CPU执行时间/CPU总时间) * (当前时刻所有CPU频率之和/所有CPU频率最大值之和)。
1)CPU 测试场景设计
测试点:
- 空闲时间(切换至后台)的消耗,基本没大应用使用cpu
- 在运行一些应用的情况下,cpu已占50%的情况下,观察应用程序占用cpu的情况
- 在高负荷的情况下看CPU的表现(cpu占用应是在80%以上)
具体场景: - 应用空闲状态运行监测CPU占用率,空闲状态:应用按Home键退到后台,不再占用系统的状态(通常是灭屏半分钟后),CPU占用率=0%
- 应用中等规格运行监测CPU占用率,中等规格:模拟用户最常见的使用场景,CPU占用率≤30%
- 应用满规格长时间正常运行监测CPU占用率,CPU占用率≤30%
- 应用正常运行期间监测CPU占用率峰值,应用正常运行:打开应用进行基本操作,CPU占用率≤50%
2)测试方法
使用perfdog采集不同场景数据
结果分析: - 和自身app的上个版本对比
- 和竞品对比
- 自身app各个界面对比
2.2.4 内存
在Android系统中,每个APP进程除了同其他进程共享内存(shared dirty)外,还独用私有内存(private dirty),通常我们使用PSS(私有内存+比例分配共享内存)来衡量一个APP的内存开销
app内存有以下几个:
- VSS- Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)
- RSS- Resident Set Size 实际使用物理内存(包含共享库占用的内存)
- PSS- Proportional Set Size 实际使用的物理内存(比例分配共享库占用的内存)
- USS- Unique Set Size 进程独自占用的物理内存(不包含共享库占用的内存)
- 一般来说内存占用大小有如下规律:VSS >= RSS >= PSS >= USS。
- 而perfdog的Memory也就是Android PSS Memory,也是我们通常用作代表内存的数据,是实际使用内存的物理内存大小
1)内存测试场景设计 - 空闲状态:切换至后台或者启动后不做任何操作,消耗内存最少
- 中强度状态:时间偏长的操作应用
- 强度状态:高强度使用应用,可以跑monkey来测试(通常用来测内存泄漏)
- 内存泄漏:指应用里的内存一直没有释放,内存一直增加 ,系统内存一直减少
- 测试方法
使用perfdog采集不同场景数据 - 结果分析:
退出某个页面后,内存是否有回落
进行某个操作后,内存是否增长过快
旧版本和新版本比较
新版本和竞品比较
2.2.5 流量
目前的网络类型包含2G\3G\4G\wifi,其中还有不同运营商的区分,我们在APP的使用中经常遇到大资源,重复请求,调用响应慢,调用失败等各种情况。在不同的网络类型之下,我们不仅要控制流量使用,还需要加快请求的响应。
1)流量测试场景设计
- 安装后首次启动到全部加载完成的所有耗流
- 非首次启动到全部加载完成的所有耗流
- 后台运行耗流
- 运行某个业务场景消耗的总流量
2)测试方法
使用 perfdog 测试工具采集流量数据
注意! perfdog流量测试仅支持wifi连接状态
3)测试结果与分析 - 旧版本和新版本比较
- 新版本和竞品比较
-
场景 耗流 是否通过
2.2.6 电量
对于PC来说,移动设备的电池电量是非常有限的,保持持久的续航能力尤为重要。我们必须要慎重检查APP的电量使用,以免导致用户手机耗电发热,带来不良体验
1)耗电量测试场景设计
GPS定位,比如:导航类软件需要获取实时位置的时候
- 场景设计:打开xx导航软件,开启GPS定位,保持在导航页面中运行十分钟后,关闭GPS定位
- 原因:开启GPS定位会使用到手机的传感器,所以需要测试开启该功能后的电量消耗
屏幕亮度,比如:用户站在太阳地下看不清屏幕时会调亮手机亮度 - 场景设计:手机亮度设置为100%的亮度,打开xx软件运行十分钟后退出软件,关闭后台
- 原因:测试不同屏幕亮度时软件的耗电量
网络传输,比如:即时类聊天软件需要时刻保持网络畅通,或者是一些类似于播放视频软件需要大量使用到网络的软件 - 场景设计:打开xx视频软件,观看视频十分钟后退出软件,关闭后台
- 原因:使用网络时会调用到手机的信号接收、发送模块,这个情况下如果程序没有进行合理的调用,会导致这些模块一直在被使用,导致电量消耗大
cpu频率,需要大量运算的页面,比如:页面中有大量动图、视频需要处理,或者大量图表需要绘制 - 场景设计:打开xx炒股软件的股票走势页面,停留十分钟后退出软件,关闭后台;
- 原因:在需要动态加载图表的页面时会使用到CPU进行运算绘制,如果程序中出现冗余的循环逻辑时会使CPU进行不必要的负载,导致耗电量剧增
内存调度,比如:每次加载页面都需要加载图像的页面
- 场景设计:打开xx电商软件商品浏览页,向下浏览页面五分钟后退出软件,关闭后台
- 原因:该场景需要大量加载图像,频繁调用运行内存,如果每次都需要重新加载的话会大量消耗运行内存,导致电量消耗大,所以需要测试电量消耗
长时间连续使用 / 后台运行状态下应用无异常耗电现象 - 场景设计:打开xx软件,连续使用一个小时
-
原因:长时间连续使用过程中电量消耗应该处于一个较为平缓正常的耗电,而不应该在使用一段时间以后出现耗电量剧增的情况;同时软件在后台运行(不进行联网操作、GPS定位等功能)时,电量消耗应该极低
测的是整机,不是单个APP,测试时要尽量减少系统本身和其他app的干扰,同时无法得知app具体哪方面的耗电量高。
2)测试方法
使用 perfdog 采集手机耗电量
注意! perfdog电量测试仅支持wifi连接状态
根据测试后拿取的结果,与同类产品进行对比,或者与本产品的其他页面进行对比,分析是否有异常耗电的情况。
3 参考资料
3.1 VSS、RSS、PSS、USS内存
VSS:Virtual Set Size,虚拟耗用内存。它是一个进程能访问的所有内存空间地址的大小。这个大小包含了
一些没有驻留在RAM中的内存,就像mallocs已经被分配,但还没有写入。VSS很少用来测量程序的实际使
用内存。
RSS:Resident Set Size,实际使用物理内存。RSS是一个进程在RAM中实际持有的内存大小。RSS可能会
产生误导,因为它包含了所有该进程使用的共享库所占用的内存,一个被加载到内存中的共享库可能有很
多进程会使用它。RSS不是单个进程使用内存量的精确表示。
PSS:Proportional Set Size,实际使用的物理内存,它与RSS不同,它会按比例分配共享库所占用的内存。
例如,如果有三个进程共享一个占30页内存控件的共享库,每个进程在计算PSS的时候,只会计算10页。
PSS是一个非常有用的数值,如果系统中所有的进程的PSS相加,所得和即为系统占用内存的总和。当一个
进程被杀死后,它所占用的共享库内存将会被其他仍然使用该共享库的进程所分担。在这种方式下,PSS
也会带来误导,因为当一个进程被杀后,PSS并不代表系统回收的内存大小。
USS:Unique Set Size,进程独自占用的物理内存。这部分内存完全是该进程独享的。USS是一个非常有用
的数值,因为它表明了运行一个特定进程所需的真正内存成本。当一个进程被杀死,USS就是所有系统回
收的内存。USS是用来检查进程中是否有内存泄露的最好选择。
共享库,每个进程在计算PSS的时候,只会计算10页。
PSS是一个非常有用的数值,如果系统中所有的进程的PSS相加,所得和即为系统占用内存的总和。当一个
进程被杀死后,它所占用的共享库内存将会被其他仍然使用该共享库的进程所分担。在这种方式下,PSS
也会带来误导,因为当一个进程被杀后,PSS并不代表系统回收的内存大小。
USS:Unique Set Size,进程独自占用的物理内存。这部分内存完全是该进程独享的。USS是一个非常有用
的数值,因为它表明了运行一个特定进程所需的真正内存成本。当一个进程被杀死,USS就是所有系统回
收的内存。USS是用来检查进程中是否有内存泄露的最好选择。
转载原文链接:https://blog.csdn.net/manbskjabgkb/article/details/132008403