Tutorial de prueba de estabilidad de la aplicación: el más completo de toda la red (prueba del hombre de madera)

Proceso de prueba y análisis ultra detallados: ninguno


  1. Introducción a las pruebas de estabilidad de aplicaciones

La prueba de rendimiento de la aplicación incluye principalmente siete indicadores: respuesta, memoria, CPU, FPS, procesamiento excesivo de GPU, consumo de energía y consumo de corriente. Además de estas pruebas de rendimiento, la aplicación también incluye: compatibilidad con el número de versión del teléfono móvil, pantalla compatibilidad de resolución y pruebas de estabilidad, pruebas de seguridad, etc., no se explican aquí.

  1. Introducción a las pruebas con monos

La herramienta Monkey es un tipo de herramienta de prueba automatizada de Android, que realiza principalmente pruebas de estrés en Android y APP.

Monkey es una herramienta de línea de comandos en Android que puede ejecutarse en un emulador o en un dispositivo real. Envía flujos de eventos de usuario pseudoaleatorios (como entrada de teclas, entrada de pantalla táctil, entrada de gestos, etc.) al sistema para implementar pruebas de estrés de la aplicación que se está desarrollando. Monkey testing es un método rápido y efectivo para probar la estabilidad y robustez del software.

  1. caracteristicas del mono

  1. El objeto de la prueba es únicamente el paquete de aplicación, el cual tiene ciertas limitaciones

  1. El flujo de datos del flujo de eventos utilizado por la prueba Monkey es aleatorio y no se puede personalizar

  1. Puede configurar el objeto MonkeyTest, la cantidad de eventos, el tipo, la frecuencia, etc.

  1. Introducción a la herramienta de prueba de rendimiento de la aplicación

SoloPi y GT: es una herramienta de automatización de Android inalámbrica y no intrusiva con funciones como reproducción de grabación y pruebas de rendimiento.

El efecto es el siguiente:

  • Prueba de rendimiento básica: puede registrar varios indicadores de la aplicación que se va a probar, observar los datos actualizados en tiempo real en la ventana flotante, registrar los datos de rendimiento y ver el gráfico después de la grabación; al mismo tiempo, también admite presión de rendimiento, que puede La CPU, la memoria y el entorno de red están restringidos para reproducir el rendimiento de la aplicación en un rendimiento deficiente y un entorno de red deficiente.

  • Grabación y reproducción: la ejecución de los pasos del caso de uso a través de SoloPi puede grabar las operaciones del usuario y admitir la reproducción en varios dispositivos, todo lo cual se puede hacer de forma independiente en el teléfono móvil.

  • Un dispositivo con múltiples controles: admite el control de múltiples dispositivos esclavos mediante la operación de un dispositivo maestro, sin repetir complicadas pruebas de compatibilidad en cada dispositivo, lo que puede mejorar en gran medida la eficiencia de las pruebas de compatibilidad.

Instalación de SoloPi y GT:

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

Código de extracción: 1111

  1. prueba de respuesta

El tiempo de respuesta y la velocidad del software afectan directamente la experiencia del usuario.Si un software no se puede cargar durante mucho tiempo, afectará directamente la actividad diaria y la retención del software. Por lo tanto, para un software, es fundamental probar la velocidad de respuesta.

Principales puntos de prueba:

  • Inicio en frío: el intervalo de tiempo entre los inicios de la aplicación por primera vez (solo el tiempo de inicio, excluyendo las cargas de página)

  • Hot start: el intervalo de tiempo para no iniciar la aplicación por primera vez (solo el tiempo de inicio, excluyendo la carga de la página)

Métodos de prueba:

  1. Después de asegurarnos de que el teléfono esté conectado a la computadora con un cable de datos, debemos activar el modo de desarrollador

  1. Luego abra el teléfono para probar la aplicación, use el comando adb en la computadora para verificar el nombre del paquete

命令:ventana de dumpsys de shell adb | findstr mCurrentFocus

La posición azul es el nombre del paquete de la aplicación abierta por el teléfono móvil actual , y la parte verde es el nombre de la actividad de la aplicación.

  1. Inicio fresco:

Primero cierre el comando de la aplicación: adb shell am force-stop package name

Luego ejecute el comando de inicio de la aplicación: adb shell am start -W appActivity name

  1. Arranque en caliente :

El teléfono vuelve al escritorio sin salir de la aplicación

Ejecute el comando para iniciar la aplicación: adb shell am start -W appActivity name

  1. significado:

ThisTime: la hora de inicio de la aplicación;

TotalTime: el tiempo de inicio de la aplicación, ThisTime+ el tiempo de inicio del recurso, como la aplicación;

WaitTime: el tiempo que tarda el sistema en iniciar la aplicación, TotalTime+ tiempo de inicio de recursos del sistema (principalmente vea esta unidad como milisegundos)

测试标准:冷启动时间不超过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. 结语:

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

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

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

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

Supongo que te gusta

Origin blog.csdn.net/qq_59344199/article/details/129750147
Recomendado
Clasificación