Pruebas de reconocimiento
Llevar a cabo pruebas de reconocimiento es crucial para garantizar el buen desempeño y calidad de las aplicaciones móviles. En este ámbito, Monkey es una herramienta que genera eventos aleatorios simulando el uso de un usuario real, lo que permite evaluar la estabilidad de la aplicación. Por otra parte, Firebase Test Lab es una plataforma de Google que posibilita ejecutar pruebas automatizadas en diversos dispositivos y configuraciones, verificando que la aplicación funcione correctamente en diferentes entornos. La combinación de Monkey y Firebase Test Lab permite a los desarrolladores identificar y solucionar errores de manera más eficaz, fortaleciendo la robustez de la aplicación y mejorando la experiencia del usuario.
Monkeys
Las pruebas con Monkeys fueron realizadas tres iteraciones con diferentes equipos a través de la herramienta ADB. Para todas las iteraciones, se realizaron un total de 100,000 eventos a través del comando adb shell monkey -p com.miso.vinilos -v -v 100000
También, los porcentajes de eventos fueron modificados por cada iteración, tratando de encontrar posibles errores o series de eventos que puedan afectar la aplicación.
En la primera iteración se utilizaron los porcentajes predeterminados, estos fueron los siguientes:
// 0: 15.0%
// 1: 10.0%
// 2: 2.0%
// 3: 15.0%
// 4: -0.0%
// 5: -0.0%
// 6: 25.0%
// 7: 15.0%
// 8: 2.0%
// 9: 2.0%
// 10: 1.0%
// 11: 13.0%
El seed generado fue el siguiente: 1716331134485 y el tiempo aproximado de ejecución de la prueba fue de 4.6 minutos (279523 ms). Los resultados de esta iteración no arrojaron ningún error, lo que demuestra una notable estabilidad de la aplicación bajo prueba. Esta ausencia de errores refuerza la confiabilidad del sistema frente a eventos aleatorios generados durante la prueba, lo que sugiere que la aplicación puede manejar con éxito una carga considerable de eventos sin presentar fallos.
En esta iteración, los eventos de táctil y navegación fueron modificados, asignándoles mayor valor respecto a los demás, por otro lado, eventos como syskeys, rotation y flip fueron asignados a valores de 0.
// Event percentages:
// 0: 34.0% (touch)
// 1: 5.0%
// 2: 5.0%
// 3: 5.0%
// 4: -0.0%
// 5: -0.0%
// 6: 10.0% (nav)
// 7: 30.0% (majornav)
// 8: -0.0%
// 9: 5.0%
// 10: -0.0%
// 11: 6.0%
El seed generado fue el siguiente: 1716212865510 y el tiempo aproximado de ejecución de la prueba fue de 3.9 minutos (234579 ms), menor al de la primera iteración. Así mismo, los resultados de esta son los mismos a los presentados en la primera iteración.
Para la tercera iteración la distribución de los eventos fue modificada, a través del siguiente comando: adb shell monkey -p com.miso.vinilos -v --pct-touch 32 --pct-motion 5 --pct-pinchzoom 5 --pct-trackball 5 --pct-rotation 0 --pct-nav 15 --pct-majornav 25 --pct-syskeys 5 --pct-appswitch 2 --pct-flip 0 --pct-anyevent 6 -v -v 100000
En este caso, los eventos táctiles y navegación fueron quienes tuvieron mayores valores respecto a los otros y que en comparacion a la iteracion dos, hubo una modificación en la distribución de porcentajes en los eventos, nav, majornav y touch, enfocándose en la navegación para detectar posibles errores en esta dada la cantidad de eventos que va a recibir generando casi que una prueba de estrés a esta característica, por lo tanto, la carga de porcentajes por evento sería la siguiente:
// Event percentages:
// 0: 32.0% (touch)
// 1: 5.0%
// 2: 5.0%
// 3: 5.0%
// 4: -0.0%
// 5: -0.0%
// 6: 15.0% (nav)
// 7: 25.0% (majornav)
// 8: 5.0%
// 9: 2.0%
// 10: -0.0%
// 11: 6.0%
El seed generado fue 1716374812669 y el tiempo aproximado de ejecución de la prueba fue de 5.8 minutos (311009 ms), mayor al de la primera iteración. La iteración no reportó ningún error.
Para la realización de esta prueba, se utilizaron los valores predeterminados por la plataforma, y se seleccionaron tres tipos de dispositivos, lo que significa la realización de tres pruebas. Adicionalmente, la versión de la API en cada uno de los dispositivos varía.
Como se puede evidenciar, tres dispositivos fueron seleccionados, Pixel 5, Galaxy S23 Ultra y Moto G Play, además, de establecer un time out de 5 minutos.
En términos generales, los resultados de las pruebas realizadas en Firebase Test Lab fueron positivos en todos los dispositivos. Los tres tests ejecutados pasaron exitosamente y no se registraron fallos en ninguna de las pruebas.
Moto G Play
Esta prueba tuvo un tiempo de ejecución de 5 minutos y 8 segundos, durante el cual se llevaron a cabo 122 acciones, se renderizaron 21 pantallas y se ejecutó 1 actividad. El tiempo de lanzamiento de la aplicación fue de 1 segundo y 25 milisegundos.
En cuanto a accesibilidad, se encontraron 3 problemas menores y se proporcionó 1 sugerencia.
Como se puede observar, estos problemas están relacionados con el etiquetado de contenido. Fueron reportados porque varios ítems en la base de datos tienen el mismo nombre, como se muestra en la siguiente imagen:
Cabe mencionar que esta prueba no presento análisis de consumo de CPU y RAM, posiblemente por el nivel de la API.
Galaxy S23 Ultra
A diferencia de la primera prueba con el Moto G Play, esta presentó un mayor número de acciones y pantallas renderizadas, con 147 acciones y 45 pantallas renderizadas. El tiempo de ejecución de la prueba fue de 5 minutos y 7 segundos, un segundo menos que la prueba anterior.
El consumo de CPU se mantuvo estable, aunque presentó un pico en el segundo 17 debido a la renderización de la lista de álbumes en ese momento. Por otro lado, el uso de memoria también se mantuvo estable, manteniéndose en valores consistentes a lo largo de toda la prueba.
En cuanto a accesibilidad, se encontraron 4 problemas menores, se proporcionó 1 sugerencia y una advertencia.
Esta advertencia se debe a un bajo contraste detectado en la lista de álbumes por parte de la herramienta. Por lo tanto, se recomienda utilizar una serie diferente de colores para incrementar el contraste.
Los 4 problemas menores se basan en el mismo factor explicado en la prueba con el Moto G Play, respecto a ítems con el mismo nombre.
Adicionalmente, la advertencia se basa en un ítem que no posee un label legible para los lectores de pantalla.
Pixel 5
A diferencia de la anterior, esta presentó un menor número de acciones y pantallas renderizadas, con 137 acciones y 44 pantallas renderizadas, es decir, 10 acciones menos y 1 pantalla renderizada menos. El tiempo de ejecución de la prueba fue de 5 minutos y 8 segundos, exactamente el mismo a la prueba anterior con el Galaxy S23 Ultra.
El consumo de CPU se mantuvo estable, aunque presentó un pico en el segundo 10 debido a la renderización de la lista de álbumes, principalmente por la carga de las imágenes. Por otro lado, el uso de memoria también fue estable, pero mostró un comportamiento similar al de la CPU. En el segundo 52, al cargar la pantalla de detalle de un álbum, se evidenció un incremento en el consumo de memoria.
En cuanto a accesibilidad, se encontraron 3 problemas menores y se proporcionó 1 sugerencia. Tanto los problemas menores como la sugerencia fueron exactamente los mismos a los presentados en la prueba con el dispositivo Moto G Play.
