Pruebas de rendimiento con Digital.ai Continuous Testing

Antecedentes

En el mundo de las pruebas de software, las pruebas de rendimiento pueden significar diferentes cosas para varios equipos e individuos, según lo que estén probando. Por ejemplo, las pruebas de carga y las pruebas de estrés que usan herramientas como JMeter o SoapUI se asocian más comúnmente con las pruebas de rendimiento para validar el servidor back-end de una aplicación cuando varios usuarios interactúan con la aplicación simultáneamente.

Sin embargo, las pruebas de rendimiento para la web móvil de iOS o Android y las aplicaciones nativas son un área que no han explorado muchas organizaciones, en parte porque pocas herramientas de mercado brindan una solución de pruebas de rendimiento decente para dispositivos móviles.

Las organizaciones con aplicaciones orientadas al cliente han priorizado las pruebas de automatización para dispositivos móviles en los últimos años. Sin embargo, a medida que crecen las aplicaciones, también lo hace la demanda de los clientes de aplicaciones que funcionen de manera óptima sin interrupciones. Por ejemplo, suponga que un usuario descarga una aplicación de AppStore y experimenta problemas como carga lenta o bloqueos. En ese caso, es probable que cambien a otra aplicación que satisfaga sus necesidades.

Si bien los scripts de automatización tradicionales se centran en gran medida en el aspecto funcional de la aplicación, no validan otros elementos críticos del rendimiento de la aplicación. Por ejemplo, no validan el tiempo necesario para navegar y aterrizar en una nueva página, los picos en el uso de la CPU, la memoria y la batería, o cualquier llamada de red innecesaria realizada durante los flujos de usuarios. Estos son desafíos diarios que enfrentan los usuarios, pero las organizaciones no enfatizan las pruebas en estas áreas de las aplicaciones móviles.

¿Cómo Digital.ai ¿Desafío de acercamiento?

El verdadero valor de las pruebas de rendimiento en dispositivos móviles se puede medir cuando puede ejecutar una gran cantidad de pruebas de rendimiento en varios modelos de dispositivos y versiones del sistema operativo.

Es posible que la prueba de rendimiento para un solo dispositivo no refleje con precisión lo que los usuarios realmente enfrentan, pero el uso de tendencias y la comprensión de cómo se comportó una sola transacción en una variedad de modelos de dispositivos y versiones del sistema operativo brindarán una mejor imagen.

Pero, ¿cómo se escalan las pruebas de rendimiento en dispositivos móviles para medir esos datos?

Digital.ai presenta comandos que se pueden implementar dentro de un script funcional de Appium; esto significa que podemos combinar un script de automatización funcional con pruebas de rendimiento.

Si observamos un script de Appium funcional simplificado para un escenario en el que estamos probando la funcionalidad de inicio de sesión de una aplicación, podemos ver que la prueba es sencilla. Primero, completamos el campo de nombre de usuario y contraseña, haciendo clic en el botón Iniciar sesión hasta que finalmente llegamos a la siguiente página:

Si tuviéramos que implementar pruebas de rendimiento en este script funcional de Appium, se vería así:

Antes de que el script haga clic en el botón de inicio de sesión, comenzamos una transacción de rendimiento y, tan pronto como llegamos a la página siguiente, finalizamos la transacción de rendimiento.

Capturar la transacción de rendimiento para completar el campo de nombre de usuario y contraseña es menos importante, ya que ingresar el texto de un script de automatización puede no representar con precisión cuánto tiempo le toma al usuario ingresar sus credenciales.

Podemos medir cuánto tiempo llevó navegar desde la página de inicio de sesión a la página siguiente o si hubo picos en el consumo de CPU, memoria o batería cuando hacemos clic en el botón Iniciar sesión.

También podemos simular una condición de red diferente para ver cómo el usuario final experimenta la aplicación cuando se encuentra en diferentes condiciones de red, y el perfil de red se pasa como el primer parámetro:

driver.executeScript(“seetest:client.startPerformanceTransaction(\”Promedio 4G\”)”);

Veamos el tipo de métricas que capturamos y cómo pueden ayudarnos a comprender cómo fue la transacción de rendimiento.

¿Qué tipos de métricas se capturan como parte de una transacción de rendimiento?

Para cada transacción de rendimiento, capturamos las siguientes métricas:

• Duración: Duración de toda la transacción, de principio a fin
• Índice de velocidad: Puntuación general calculada de la rapidez con la que se pintó el contenido final
• UPC: Gráfico con la CPU consumida, valores promedio y máximo para la transacción
• Memoria: Gráfico con la memoria consumida, valores medios y máximos para la transacción
• Batería: Gráfico con la batería consumida, valores medios y máximos para la transacción
• Red: Total de KB cargados/descargados durante la transacción según el perfil de red aplicado
• Llamadas de red: Todas las llamadas de red realizadas durante la transacción.

Lo que estamos viendo es una transacción de rendimiento única que se ejecutó en un iPhone 13 Pro. Podemos reproducir el video que se capturó como parte de la transacción de rendimiento y, en relación con el video, podemos seguir el consumo de CPU, memoria y batería.

¿Cómo me ayuda este informe a comprender las tendencias y los cuellos de botella potenciales?

El informe que acabamos de ver se centra en una transacción de rendimiento individual. Pero imagine que ahora hemos ejecutado la misma Transacción de rendimiento a escala en muchos modelos de dispositivos y versiones de SO, podemos aprovechar nuestras capacidades de informes integradas para comenzar a observar tendencias.

Aquí hay un informe de ejemplo que se filtra para mostrar todas las transacciones que ejecuté bajo una compilación específica y una transacción en particular (p. ej., buscar un elemento desde el campo de búsqueda en una aplicación nativa y comprender cuánto tiempo tardó en cargar el siguiente página en el contexto de una aplicación minorista):

Este informe me dice que el índice de velocidad fue significativamente más alto en la versión 13.2 de iOS en comparación con otras versiones de iOS.

Del mismo modo, también podemos ver las tendencias de otras métricas, como CPU, memoria y batería:

Este nivel de información permite a los evaluadores y desarrolladores de control de calidad investigar modelos de dispositivos y versiones del sistema operativo específicos en busca de posibles cuellos de botella e identificar áreas de mejora en la aplicación móvil que se está probando.

Es importante tener en cuenta que puede haber diferencias de rendimiento entre diferentes dispositivos o redes. Es común ver hasta un 30 % de variación entre dispositivos, lo que no necesariamente indica un problema grave de rendimiento. Sin embargo, los problemas de rendimiento pueden causar diferencias de 10 a 100 veces las mediciones de referencia.

¿Necesito implementar pruebas de rendimiento en scripts de automatización funcional existentes?

Si tiene sentido implementar pruebas de rendimiento en secuencias de comandos funcionales existentes o crear nuevas secuencias de comandos independientes para pruebas de rendimiento dependerá de la flexibilidad y la complejidad del marco de automatización actual.

En el ejemplo que di antes, el código está demasiado simplificado. Aún así, pensemos en el mismo enfoque en el contexto de un marco de automatización existente. Muchas más dependencias y capas pueden estar involucradas cuando se llama a un método para realizar operaciones como Hacer clic o Enviar teclas.

Veamos un ejemplo:

Agregar más lógica al marco de automatización existente podría aumentar el tiempo total requerido para ejecutar el script automatizado, lo que puede afectar negativamente las pruebas de rendimiento y no proporcionar métricas valiosas.

Si la complejidad del marco de automatización existente dificulta las pruebas de rendimiento, se recomienda escribir scripts de automatización separados exclusivamente para capturar métricas de rendimiento.

Esto nos permite simplificar la lógica del código hasta cierto punto, lo que nos permite capturar las métricas adecuadas para las pruebas de rendimiento con precisión.

¿Qué tipo de números de referencia debo establecer para garantizar que los datos capturados sean medibles?

No existen métricas universales o estandarizadas para aplicar al medir el desempeño, ya que cada organización y sus equipos definen la experiencia del usuario para su propia aplicación. Además, según la complejidad de la aplicación, los números de referencia pueden variar de una página a otra o de una aplicación a otra.

Un ejemplo de una métrica que se puede utilizar es TTI (tiempo de interactividad), que mide el tiempo que tarda una aplicación en volverse utilizable después de que el usuario la haya iniciado.

Se han realizado investigaciones al respecto, y algunas reglas generales útiles basadas en la investigación de HCI (interacción humano-computadora) nos dicen:

• Cualquier retraso de más de 500 ms se convierte en un evento "cognitivo", lo que significa que el usuario sabe que ha pasado el tiempo.
• Cualquier retraso de más de 3 segundos se convierte en un evento "reflexivo", lo que significa que el usuario tiene tiempo para reflexionar sobre el hecho de que ha pasado el tiempo. Pueden distraerse o elegir hacer otra cosa.

Pero también hay otras métricas que se consideran métricas clave de rendimiento, como:

• Tiempo de respuesta más alto
• Tiempo promedio de respuesta
• Número máximo de solicitudes

Si el tiempo de respuesta de su servidor es lento, puede dañar la experiencia del usuario. Google PageSpeed ​​Insights recomienda un tiempo de respuesta del servidor de menos de 200 ms. Un rango de 300-500 ms se considera estándar, mientras que cualquier valor superior a 500 ms está por debajo de un estándar aceptable.

Es importante tener en cuenta que no existe una respuesta única para estas métricas, y determinar la línea de base puede variar de un caso a otro. Por lo tanto, es crucial comprender qué es aceptable dentro del contexto de la aplicación que se está probando. Esto puede implicar colaborar con los desarrolladores de aplicaciones para obtener información sobre el backend de la aplicación, como la cantidad de llamadas de red realizadas durante un flujo de usuario en particular, las operaciones pesadas que ocurren en el backend al interactuar con ciertos componentes de la aplicación y otros factores relacionados.

También puede ser útil ejecutar un puñado de pruebas de rendimiento para luego usarlas como referencia.

¿Debo ejecutar mis pruebas de rendimiento en todas las combinaciones de dispositivos disponibles?

Al decidir qué dispositivos probar para las Pruebas de rendimiento, es importante considerar los que generan la mayor cantidad de ingresos. Determinar esto requiere una comprensión clara de la base de usuarios y los tipos de dispositivos que se usan con más frecuencia para la Aplicación que se está probando.

A partir de ahí, se recomienda seleccionar los mejores 5 a 10 dispositivos para realizar pruebas de manera consistente (el número exacto puede variar según la escala del proyecto y la base de usuarios). Este enfoque ayuda a establecer una línea de base para los dispositivos probados, lo que permite mediciones de rendimiento más precisas.

Resumen

Las pruebas de rendimiento son fundamentales para garantizar que el software, las aplicaciones y los sistemas puedan manejar las cargas y el tráfico esperados. Ayuda a identificar y abordar cuellos de botella de rendimiento y fallas potenciales antes deployment, asegurando que los usuarios finales tengan una experiencia perfecta.

A diferencia de los scripts de automatización tradicionales, las pruebas de rendimiento tienen como objetivo medir el tiempo que tarda un usuario en navegar entre páginas, identificar picos en el consumo de CPU, memoria y batería, y señalar llamadas de red innecesarias.

El valor de las pruebas de rendimiento radica en la capacidad de identificar problemas al principio del proceso de desarrollo, lo que reduce los costos asociados con solucionarlos más adelante. Además, ayuda a establecer una línea de base para las métricas de rendimiento que se pueden monitorear y comparar a lo largo del tiempo, proporcionando información sobre cómo los cambios en el sistema afectan el rendimiento. Las pruebas de rendimiento son esenciales para cualquier ciclo de desarrollo de software, desde el desarrollo hasta deployy más allá.

 

¿Listo para comenzar las pruebas de rendimiento para dispositivos móviles? Contáctenos hoy en https://digital.ai/why-digital-ai/contact/