Pruebas de rendimiento con Digital.ai Continuous Testing

Fondo

En el mundo de las pruebas de software, las pruebas de rendimiento pueden tener diferentes significados para diversos equipos e individuos, dependiendo de lo que estén probando. Por ejemplo, las pruebas de carga y las pruebas de estrés, que utilizan herramientas como JMeter o SoapUI, se asocian comúnmente con las pruebas de rendimiento para validar el servidor backend de una aplicación cuando varios usuarios interactúan con ella simultáneamente.

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

En los últimos años, las organizaciones con aplicaciones de cara al cliente han priorizado las pruebas de automatización para móviles. Sin embargo, a medida que las aplicaciones crecen, también lo hace la demanda de los clientes de aplicaciones que funcionen de forma óptima y sin interrupciones. Por ejemplo, supongamos que un usuario descarga una aplicación de la App Store y experimenta problemas como carga lenta o fallos. En ese caso, probablemente cambiará a otra aplicación que satisfaga sus necesidades.

Si bien los scripts de automatización tradicionales se centran principalmente en el aspecto funcional de la aplicación, no validan otros elementos críticos de su rendimiento. Por ejemplo, no validan el tiempo de navegación ni el tiempo de acceso a una nueva página, los picos de uso de CPU, memoria y batería, ni las llamadas de red innecesarias durante la interacción del usuario. Estos son desafíos cotidianos a los que se enfrentan los usuarios, pero las organizaciones no suelen priorizar las pruebas en estas áreas de las aplicaciones móviles.

¿Cómo Digital.ai ¿Abordar el desafío?

El verdadero valor de las pruebas de rendimiento en dispositivos móviles se puede medir cuando se puede ejecutar una gran cantidad de pruebas de rendimiento en diversos modelos de dispositivos y versiones de sistemas operativos.

Probar el rendimiento en un solo dispositivo puede no reflejar con precisión lo que realmente enfrentan los usuarios, pero usar las tendencias y comprender cómo se comportó una sola transacción en una variedad de modelos de dispositivos y versiones de sistemas operativos proporcionará una imagen más clara.

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

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

Si analizamos un script funcional simplificado de Appium para un escenario donde probamos la funcionalidad de inicio de sesión de una aplicación, podemos ver que la prueba es sencilla. Primero, completamos los campos de nombre de usuario y contraseña, haciendo clic en el botón Iniciar sesión hasta llegar a la página siguiente:

Si implementáramos pruebas de rendimiento en este script funcional de Appium, se vería algo así:

Antes de que el script haga clic en el botón de inicio de sesión, iniciamos 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 rellenar los campos de nombre de usuario y contraseña es menos importante, ya que introducir el texto desde un script de automatización puede no representar con precisión el tiempo que realmente tarda el usuario en introducir sus credenciales.

Podemos medir cuánto tiempo tardó en navegar desde la página de inicio de sesión a la página siguiente o si se produjeron picos en el consumo de CPU, memoria o batería al hacer clic en el botón de inicio de 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 bajo diferentes condiciones de red, y el perfil de red se pasa como primer parámetro:

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

Analicemos el tipo de métricas que recopilamos y cómo pueden ayudarnos a comprender cómo se desarrolló la transacción de rendimiento.

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

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

• Duración: Duración de la transacción completa, desde el inicio hasta el final
• Índice de velocidad: Puntuación global calculada de la rapidez con que se pintó el contenido final
• UPC: Gráfico con el consumo de CPU, los valores promedio y máximos para la transacción.
• Memoria: Gráfico con la memoria consumida, los valores promedio y máximos para la transacción.
• Batería: Gráfico con el consumo de batería, valores promedio y máximos para la transacción.
• Red: Total de KB subidos/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 única transacción de rendimiento que se ejecutó en un iPhone 13 Pro. Podemos reproducir el vídeo que se capturó como parte de la transacción de rendimiento y, en relación con el vídeo, podemos seguir el consumo de CPU, memoria y batería.

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

El informe que acabamos de ver se centra en una transacción de rendimiento individual. Pero imaginemos que ahora ejecutamos la misma transacción de rendimiento a gran escala en muchos modelos de dispositivos y versiones de sistemas operativos; podemos aprovechar nuestras capacidades de informes integradas para empezar a analizar las tendencias.

Aquí tenéis un ejemplo de informe filtrado para mostrar todas las transacciones que he ejecutado bajo una compilación específica y una transacción en particular (por ejemplo, buscar un artículo en el campo de búsqueda de una aplicación nativa y comprender cuánto tiempo tardó en cargar la página siguiente en el contexto de una aplicación de venta minorista):

Este informe me indica que el Índice de Velocidad fue significativamente mayor en la versión 13.2 de iOS en comparación con otras versiones de iOS.

De igual forma, podemos analizar las tendencias de otras métricas, como CPU, memoria y batería:

Este nivel de información permite a los evaluadores de control de calidad y a los desarrolladores investigar modelos de dispositivos y versiones de sistemas operativos específicos para detectar 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 distintos dispositivos o redes. Es común observar una variación de hasta un 30 % entre dispositivos, lo que no necesariamente indica un problema grave de rendimiento. Sin embargo, los problemas de rendimiento pueden causar diferencias de entre 10 y 100 veces las mediciones de referencia.

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

La conveniencia de implementar pruebas de rendimiento en scripts funcionales existentes o de crear nuevos scripts independientes para pruebas de rendimiento dependerá de la flexibilidad y la complejidad del marco de automatización actual.

En el ejemplo anterior, el código está muy simplificado. Aun así, analicemos este mismo enfoque en el contexto de un marco de automatización existente. Al llamar a un método para realizar operaciones como hacer clic o enviar teclas, pueden intervenir muchas más dependencias y capas.

Veamos un ejemplo:

Agregar más lógica al marco de automatización existente podría aumentar el tiempo total necesario para ejecutar el script automatizado, lo que podría 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 las métricas de rendimiento.

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

¿Qué tipo de valores de referencia debo establecer para asegurar que los datos recopilados sean medibles?

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

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

Se han realizado investigaciones al respecto, y algunas reglas prácticas útiles basadas en la investigación en IHC (Interacción Persona-Ordenador) nos dicen:

• Cualquier retraso superior a 500 ms se convierte en un evento “cognitivo”, lo que significa que el usuario sabe que ha transcurrido tiempo.
• Cualquier retraso superior a 3 segundos se convierte en un evento «reflexivo», lo que significa que el usuario tiene tiempo para reflexionar sobre el hecho de que ha transcurrido tiempo. Puede distraerse o decidir hacer otra cosa.

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

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

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

Es importante destacar que no existe una solución universal para estas métricas, y la determinación del valor de referencia puede variar según el caso. Por lo tanto, es fundamental comprender qué se considera aceptable en el contexto de la aplicación que se está probando. Esto puede implicar colaborar con los desarrolladores de la aplicación para obtener información sobre el backend, como la cantidad de llamadas de red realizadas durante un flujo de usuario específico, las operaciones intensivas que se producen en el backend al interactuar con ciertos componentes de la aplicación y otros factores relacionados.

También puede resultar útil ejecutar algunas pruebas de rendimiento para luego utilizarlas como base.

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

Al decidir qué dispositivos probar en las pruebas de rendimiento, es importante considerar aquellos que generan mayores ingresos. Para determinar esto, se requiere un conocimiento profundo de la base de usuarios y de los tipos de dispositivos que se utilizan con mayor frecuencia para la aplicación que se está probando.

A partir de ahí, se recomienda seleccionar los 5-10 dispositivos principales para realizar pruebas de forma consistente (el número exacto puede variar según la escala del proyecto y la base de usuarios). Este enfoque ayuda a establecer una base de referencia 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 soportar las cargas y el tráfico previstos. Ayudan a identificar y solucionar los cuellos de botella de rendimiento y los posibles fallos antes de la puesta en marcha, lo que garantiza una experiencia fluida para los usuarios finales.

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 detectar llamadas de red innecesarias.

El valor de las pruebas de rendimiento radica en la capacidad de identificar problemas en las primeras etapas del desarrollo, reduciendo así los costes asociados a su corrección posterior. Además, ayudan a establecer una base de referencia para las métricas de rendimiento, que pueden monitorizarse y compararse a lo largo del tiempo, proporcionando información valiosa sobre cómo los cambios en el sistema afectan al rendimiento. Las pruebas de rendimiento son esenciales en cualquier ciclo de desarrollo de software, desde el desarrollo hasta la implementación y más allá.

 

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