app稳定性测试教程——全网最全(测试木头人)

超详细测试流程及分析 ——没有之一


  1. App稳定性测试简介

App的性能测试主要有响应、内存、cpu、FPS、GPU过度渲染、耗电、耗流七个指标,app除了这些性能测试,还有:手机版本号兼容性,屏幕分辨率兼容性,稳定性测试,安全测试等,这里就不在说明了。

  1. monkey测试简介

Monkey工具是Android自动化测试工具的一种,主要对Android,APP可进行压力测试。

Monkey是Android中的一个命令行工具,可以运行在模拟器里或实际设备中。它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等),实现对正在开发的应用程序进行压力测试。Monkey测试是一种为了测试软件的稳定性、健壮性的快速有效的方法。

  1. monkey特征

  1. 测试的对象仅为应用程序包,有一定的局限性

  1. Monkey测试使用的事件流数据流是随机的,不能进行自定义

  1. 可对MonkeyTest的对象,事件数量,类型,频率等进行设置

  1. APP性能测试工具介绍

SoloPi和GT:是一个无线化、非侵入式的Android 自动化工具, 具备录制回放、 性能测试等功能。

作用如下:

  • 基础性能测试: 能够记录待测应用的各项指标,可以在悬浮窗中观察实时更新的数据,也可以对性能数据进行录制,在录制结束后查看图表;同时,还支持性能加压,能够对CPU、 内存与网络环境进行限制, 复现应用在性能较差、 网络环境不佳场景下的表现。

  • 录制回放: 通过SoloPi执行用例步骤, 能够将用户的操作记录下来, 支持在各个设备上进行回放, 这一切都能够在手机上独立完成。

  • 一机多控:支持通过操作一台主机设备来控制多台从机设备,不需要在各个设备上分别进行重复冗杂的兼容性测试,能够极大提升兼容性测试的效率。

SoloPi和GT安装:

链接:https://pan.baidu.com/s/1i0fKgEfa5soiuhWOzC-zlQ

提取码:1111

  1. 响应测试

软件的响应时间和响应速度直接影响到用户的体验度,如果一个软件,迟迟加载不出来,会直接影响到软件的日活、留存。因此对于一个软件,对响应速度测试是必不可少的。

主要测试点:

  • 冷启动:首次启动app的时间间隔(只是启动时间,不包括页面加载)

  • 热启动:非首次启动app的时间间隔(只是启动时间,不包括页面加载)

测试方法:

  1. 确保手机用数据线连接电脑后,我们要打开开发者模式

  1. 然后手机打开要测试app,在电脑上使用adb命令查一下包名

命令:adb shell dumpsys window | findstr mCurrentFocus

蓝色位置是当前手机打开app的包名,绿色部分是app的appActivity名

  1. 冷启动:

首先关闭app命令:adb shell am force-stop 包名

然后执行启动app命令:adb shell am start -W appActivity名

  1. 热启动

手机返回到桌面,不需要退出app

执行启动app命令:adb shell am start -W appActivity名

  1. 含义:

ThisTime: 该app的启动耗时;

TotalTime: 该app的启动耗时, ThisTime+应用application等资源启动时间;

WaitTime: 系统启动该app的耗时, TotalTime+系统资源启动时间(主要看这个单位为毫秒)

测试标准:冷启动时间不超过1.5s, 热启动不超过1s.

当测试数据超出标准值时,优化建议:

  • UI布局:应⽤⼀般都有闪屏页,优化闪屏页的UI布局,可以通过Profile GPU Rendering检测丢帧情况。

  • 启动加载逻辑优化:可以采⽤分布加载、异步加载、延期加载策略来提⾼应⽤启动速度。

  • 数据准备:数据初始化分析,加载数据可以考虑⽤线程初始化等策略。

  1. APP性能测试工具 —— SoloPi使用

  1. 打开SoloPi——选择性能测试——同意授权——选择要测试的app——选择要监控的数据——勾选后悬浮窗会出现在手机屏幕上

  1. 全屏设置:

设置全屏:adb shell settings put global policy_control immersive.full=*

取消全屏:adb shell settings put global policy_control null

  1. 准备好后开始录制(上图第三步)并且在电脑上执行monkey命令:

常规monkey命令:

adb shell monkey -p com.clx.collections --throttle 100 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 1000000>D:\Log\01291048.log

命令解析:指定一个应用,延时时间为200毫秒,忽略程序崩溃,忽略ANR错误,忽略许可错误,监视并报告应用程序发生崩溃的本地代码,日志级别Level2,随机种子数10000。

大家可以自行根据情况去写命令执行,也可以百度查找其他命令。命令执行完成后停止录制,会自动进行保存,点击查看。

  1. 数据分析

  1. CPU:

介绍:

CPU测试,主要关注的是cpu的占用率。很多时候,我们玩手机时,会出现发热发烫,那是因为CPU使用率过高,CPU过于繁忙,会使整个手机无法响应用户,整体性能降低,用户体验就会很差,也容易引起ANR(application not responding, 主线程(UI线程)如果在规定时内没有处理完相应工作,就会出现ANR)等等一系列问题。

测试点:

  • 在空闲时间(切换至后台)的消耗,基本没大应用使用cpu

  • 在运行一些应用的情况下,cpu已占50%的情况下,观察应用程序占用cpu的情况

  • 在高负荷的情况下看CPU的表现(cpu占用应是在80%以上)

具体场景:

  • 应用空闲状态运行监测CPU占用率

空闲状态:应用按Home键退到后台,不再占用系统的状态(通常是灭屏半分钟后)

CPU占用率=0%

  • 应用中等规格运行监测CPU占用率

中等规格:模拟用户最常见的使用场景

CPU占用率≤30%

  • 应用满规格长时间正常运行监测CPU占用率

Monkey测试

CPU占用率≤30%

  • 应用正常运行期间监测CPU占用率峰值

应用正常运行:打开应用进行基本操作

CPU占用率≤50%

方法一:

基线:如果有基线要求,CPU曲线图是否存在长期超过基线的现象(min),如果没有基线,行业默认80%。

CPU占用过高时可能出现的问题:

  • 手机发烫

  • 页面卡顿

  • 电量消耗严重

快速恢复:清空后台运行的进程

测试数据结果分析:本次测试结果显示CPU占用率平均值为44.04%,未超过行业标准值80%,测试通过。

方法二:

使用AndroidStudio 自带 CPU 和内存检测功能

首先要下载并安装好Android Studio——使用数据线连接电脑,打开要检测的app——在Android Studio确认app——配合monkey命令

Android Monitor 可以检测CPU 和内存,能够绘制出变化图,可以直观明了的看出内存和cpu的变化曲线。

  1. 内存

介绍:

在Android系统中,每个APP进程除了同其他进程共享内存(shared dirty)外,还独用私有内存(private dirty),通常我们使用PSS(私有内存+比例分配共享内存)来衡量一个APP的内存开销。由于一个移动设备的内存是固定的,如果内存消耗过大就会造成应用卡顿或者闪退,需要对内存进行测试。正常情况下,应用不应占用过多的内存资源,且能够及时释放内存,保证整个应用内的稳定性和流畅性。

测试点:

  • 空闲状态:切换至后台或者启动后不做任何操作,消耗内存最少。

  • 中强度状态:时间偏长的操作应用。

  • 高强度状态:高强度使用应用,可以跑monkey来测试(通常用来测试内存泄漏)。

  • 内存泄漏:指应用里的内存一直没有释放,内存一直增加,系统内存一直减少

方法一:

异常曲线图: 正常曲线图:

分析:

测试数据结果分析:本次测试结果显示内存占用率平均值为55.35%,未超过行业标准值80%。通过对数据图分析,存在内存泄漏及内存溢出的问题,建议优化。

优化建议:

  • 尽量少使用枚举

  • 尽量使用静态内部类而不是内部类

  • 尽量使用轻量级的数据结构

  • 谨慎使用static关键字

  • 谨慎使用单例模式

方法二:

测试关注点:

  • Native heap alloc

  • Dalvik heap alloc

  • PSS

  1. 流量

上行的均值加下行的均值得kb值:((上行+下行)/1000) /(网络带宽(1000Mb)/8) = 网络带宽的利用率(百分比)

阈值:70%,大于是潜在的瓶颈小于就没有

测试怎么测: 例如: 1小时持续刷新,查看流量消耗,使用了多长时间,消耗了多少流量。

流量优化方法:

  • 数据的压缩

  • 不同数据格式的采用

  • 控制访问的频次

  • 只获取必要的数据

  • 缓存机制

  • 针对不同的网络类型设置不同的访问策略

{[(8854.40+13965.92)/1000]/(1000/8)}*100%=18.25%

测试数据结果分析:本次测试结果显示调度中心上报端app网络宽带的利用率为18.25%,未超过阈值70%,测试通过。

  1. FPS

FPS是图像领域中的定义,是指画面每秒传输帧数,通俗来讲就是指动画或视频的画面数。FPS是测量用于保存、显示动态视频的信息数量。每秒钟帧数愈多,所显示的动作就会愈流畅。

一般来说,Android设备的屏幕刷新率为60帧/s,要保持画面流畅不卡顿,要求每一帧的时间不超过1000/60=16.6ms,这就是16ms的黄金准则,如果中间的某些帧的渲染时间超过16ms,就会导致这段时间的画面发生了跳帧,因此原本流畅的画面变发生了卡顿。

帧率(FPS): 每秒切换多少帧,60fps为最佳

测试数据结果分析:本次测试结果显示FPS平均值为113.39帧/s,超过行业标准值最佳60帧/s。测试不通过,建议优化。

FPS优化建议:

  • 减少页面层级,防止过度绘制

  • 优化组件延迟加载

  • 资源预加载,减小资源尺寸

  1. 电量

测试应用对电量的消耗前需要对手机本身的电量消耗有个大概了解,测试前先看规定时间内手机正常待机下(重启后待机)电量消耗为多少。然后再启动待测试APP看看消耗的电量增加了多少取差值。

测试点:

  • 测试手机安装目标APK前后待机功耗无明显差异;

  • 常见使用场景中能够正常进入待机,待机电流在正常范围内;

  • 长时间连续使用应用无异常耗电现象。

  • 使用了多长时间,消耗了多少电量

测试怎么测: 例如: 1小时持续刷新,查看电量消耗

常见的电量消耗较大的场景:

  • 定位,尤其是调用GPS 定位。

  • 网络传输,尤其是非Wi-Fi 环境。

  • 屏幕亮度

  • CPU 运算:复杂的运算逻辑、死循环等会直接导致CPU负载过高,会导致耗电;

  • wake_locker(锁屏-解锁)时间和次数

注意: 公司是否有基线要求,如果有要求,那么我们需要去检验产品是否达标;如果没有基线,可以和竞品对比测试。

测试方法:

  1. 重启adb

adb kill-server

adb start-server

adb devices

  1. 重置电池数据

adb shell dumpsys batterystats --enable full-wake-history

adb shell dumpsys batterystats --reset

  1. 拔掉数据线,测试完成后使用数据线连接电脑,收集电量数据

adb shell dumpsys batterystats > D:/batterinfo.txt

  1. 根据包名找到对应的UID

  1. 根据UID查询电量消耗

  1. 用这个数值乘以电池用容量然后再除以使用时间就等于每分钟耗电量

  • 测试数据结果分析:本次测试结果显示调度中心上报端每分钟耗电量=4500*12.2%/26=21.12mAh,正常操作手机每分钟的耗电量=4500*12%/26=20.76mAh。经过数据对比,长时间连续使用无异常耗电现象,测试通过。

  1. GPU

GPU渲染是指在一个像素点上绘制多次(超过一次):显示一个什么都没有做的activity界面算作画了1层,给activity加一个背景是第2层,在上面放了一个Text View(有背景的Text View)是第3层,Text View显示文本就是第4层仅仅只是为了显示一个文本,却在同一个像素点绘制了四次,这是一定要优化的。过度绘制对动画性能的影响是极其严重的,如果你想要流畅的动画效果,那么一定不能忽视过度绘制。

测试方法:手机自动的Debug GPU overdraw

测试步骤:

  1. 打开手机—>设置—>开发者选项—>Debug GPU overdraw—>show overdraw areas

  1. 打开被测的应用

GPU过渡渲染不同的颜色代表不同的绘制程度

  • 原色:无过渡绘制

  • 蓝色:绘制一次(理想状态)

  • 绿色:绘制二次

  • 浅红:绘制三次(可以优化)

  • 深红:绘制四次(必须优化)

测试指标:

  • 控制过渡绘制为2x

  • 不允许存在4x过渡绘制

  • 不允许存在面积超过屏幕1/4的3x过渡绘制

  1. 查询无响应

  1. 查询闪退崩溃

  1. 查询错误

  1. 查询异常

Got IOException performing flipjava.io.FileNotFoundException: /dev/input/event0: open failed: EACCES (Permission denied)

测试数据结果分析:本次稳定性测试查询出现异常。

  1. 结语:

编写不易,大家多多支持。

最后祝大家在计算机道路上一路长虹!!!

最后祝大家在计算机道路上一路长虹!!!

最后祝大家在计算机道路上一路长虹!!!

  • 14
    点赞
  • 96
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 6
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

测试木头人

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值