¿Cómo hacer pruebas de performance en mobile usando Apptim?

Generalmente cuando se plantean pruebas de rendimiento todas las miradas se centran en cómo de bien van a funcionar nuestros servicios bajo unos determinados parámetros de concurrencia, usuarios, etc, pero, ¿nos acordamos a la hora de lanzar una app nativa de cómo será la experiencia de usuario? No hablamos de la funcionalidad, sino de cómo de rápida será, si se quedará colgada, si la renderización será óptima, si gastará mucha batería. Pues bien, en este post nos centraremos en el proceso de prueba desde su definición hasta identificar los parámetros que miden el rendimiento y, por último, ejecutar la prueba en tiempo de desarrollo con una de las herramientas que hay en el mercado para este tipo de testing: Apptim.

¿Qué tenemos que medir?

A la hora de abordar un proceso de pruebas uno de los primeros elementos que tenemos que tener claro son los aspectos que queremos medir. De esto dependerá el tipo de pruebas que hay que llevar a cabo, la base de prueba, la estrategia y los KPI’s que nos permitan establecer el objetivo de todo este proceso.

En el siguiente gráfico se aprecian un conjunto de elementos medibles dentro de una app que permiten conocer el estado de diferentes áreas.

Dentro del conjunto de indicadores que se han definido, en el caso de este post, nos centraremos en los indicadores de rendimiento cuyos valores se proporcionan por la herramienta que se usará para su medición Apptim). Los otros conjuntos de indicadores que se muestran en la imagen están ligados a los de rendimiento ya que un mal funcionamiento implica una mala experiencia de usuario (UX/UI), poca confiabilidad y baja rentabilidad a causa del abandono.

¿Cómo voy a medir el rendimiento? Estrategia de pruebas.

El objetivo de la estrategia es establecer las actividades de prueba que han de ser cubiertas con el fin de asegurar el correcto funcionamiento de un sistema. En el caso que nos afecta, hablamos de una app nativa.

La estrategia tiene que abordar puntos tales como el entorno de ejecución de las pruebas, las actividades de prueba a realizar, el uso de herramientas y gestión de las mismas, definición de los escenarios y criterios de aceptación.

Tal y como hemos definido al inicio del post de todas las posibles actividades de pruebas nos vamos a centrar en las pruebas de rendimiento. Estas pruebas indican cómo se comporta un sistema ante unas determinadas condiciones de trabajo. Siguiendo la definición del párrafo anterior vamos a definir la estrategia de la prueba que se describe en la siguiente imagen:

En el caso que nos ocupa, se ha instalado en el dispositivo móvil una app de retail y la prueba consistirá en navegar por la misma a través de los productos ofertados, así como usar algunos recursos como buscadores, lupa de las imágenes y botones de navegación.

¿Qué es Apptim?

Es una herramienta que permite realizar un análisis de rendimiento de las app nativas tanto Android como iOS. Este análisis permite conocer en tiempo real el estado de las apps y refactorizar las mismas antes de que se promocionen a entornos en los que su modificación es más costosa. No requiere de la modificación del código para disponer de los valores de las métricas.

Existen en el mercado actualmente varias herramientas que nos permiten medir los KPI’s mencionados, como es el caso de Firebase Test Labs o como es el caso de AWS Device Farm. A continuación se establece una comparativa con algunas de estas herramientas:

Preparación, ejecución y análisis de la prueba con Apptim.

Preparación de la prueba.

• Descargamos e instalamos la aplicación desde la web.
• Ejecutamos la aplicación Apptim en local y nos logamos.
• Apptim valida que el entorno disponga de todo lo necesario para las pruebas. Es aconsejable disponer de Android Studio o XCode.
• Conectamos el dispositivo móvil al equipo en modo debug o abrimos un emulador.
• Definimos un caso de prueba con los datos necesarios para la prueba. En nuestro caso se trata de una app de retail y realizaremos una navegación buscando artículos.

A la hora de preparar la prueba es aconsejable acceder a la documentación de la aplicación aquí, donde se puede encontrar una información bien estructurada y bastante completa sobre todos los aspectos del ciclo de testing que se pueden abordar con Apptim.

Ejecución de la prueba manual.

• Durante la preparación de la prueba se ha abierto la aplicación. La prueba se ejecuta de forma manual.
• Apptim muestra dos opciones inicialmente:
  • Start a new test: con esta opción podemos crear una sesión de pruebas.
  • Test Session: nos permite recuperar sesiones anteriores y establecer comparativas.
• En Apptim, seleccionar “start a new test” , un dispositivo para la prueba y la app que se va a testear(SUT). Por último, muestra dos opciones para seleccionar el tiempo de grabación.
• En la siguiente pantalla nos solicita el nombre que se le va a dar a la sesión de testing que vamos a iniciar y nos da la opción de abrir la app (SUT) en el dispositivo seleccionado de forma automática.
  • Dentro de esta misma pantalla nos permite definir una serie de umbrales o KPI’s que se hayan podido establecer en los requerimientos, para ello hemos de seguir las indicaciones que se establecen en “You can define custom thresholds”. Esta operativa se podrá hacer después de lanzar por primera vez la prueba.
• Una vez que se comienza la prueba, en la app (SUT) se comienza a ejecutar los casos de prueba definidos.
• Finalizar la sesión de pruebas sin cerrar la app que está siendo validada. Tras lo cual se muestra una pantalla en la se muestra el resultado de la prueba.

• Acceder a “Session Report” donde se podrá analizar el resultado de la prueba. Dentro de este reporte se puede ver el video con el desarrollo de la misma. Este reporte está formado por cuatro partes:
  • “Summary”, donde se pueden ver el video de la prueba y una descripción detallada del resultado de la misma.
  • “Environment”, donde se hace una descripción detallada del entorno en el que se ha desarrollado.
  • “Correctness”, en la que se analiza el Layout de la app.
  • “Errors”, donde se analizan las faltas de respuesta durante la prueba, cerrándose la aplicación (ANR), y cuando hay un problema con el sistema operativo (Crash)
  • “Logs”: muestra de forma pormenorizada información del transcurso de la prueba.

Análisis de la prueba.

En este apartado del post se hace una análisis de los resultados obtenidos de cara a validar los KPI’s que se habían fijado al principio de la prueba. Dentro del reporte de Apptim (Summary) nos encontramos con 4 indicadores:

Como se puede observar en la imagen, el uso medio de memoria y de CPU se encuentran en unos valores aceptables aunque más adelante se analizan más detenidamente en la gráfica. Sin embargo, el tiempo de renderización tiene un valor que aunque no es muy negativo conviene tener en cuenta ya que puede provocar un problema de bloqueo.

El otro parámetro, “errors/exception”, indica que se han encontrado tres errores que no son bugs y que tendrían que ser analizados junto con el equipo de desarrollo. Se puede acceder desde el menú de la izquierda, dentro de Errores, a la descripción de los mismos. En el caso que nos ocupa se muestran las siguientes trazas.

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details

java.lang.InterruptedException
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java)
at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java)
at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java)
at c.m.y2$c.run(OneSignalSyncServiceUtils.java:13)
at java.lang.Thread.run(Thread.java)<br>

Continuando con la información que devuelve el reporte, podemos ver valores máximos de algunos de los KPI’s.

Siguiendo con el análisis del reporte, se ve una información muy completa de cómo ha sido la evolución de los tiempos y tasas de uso de diferentes indicadores a través de las siguientes gráficas.

En la gráfica de la figura 7 se puede visualizar toda la información de forma simultánea.

Apptim ofrece la posibilidad de mostrar cada una de estas informaciónes de forma individual:

De los indicadores que se han mostrado en las diferentes gráficas, podemos apreciar que aunque se han producido picos que tendrán que ser analizados la aplicación (SUT) presenta unos indicadores, que sin ser los mejores, arrojan unos valores aceptables.

Apptim proporciona un completo log de las elementos de código que han sido accedidos a lo largo de la prueba por lo que para interpretar esos picos que se han producido podremos ver esos mismos logs que junto con el video de la prueba dará la pista de qué elementos provoca esos picos con valores anómalos.

Otra de las informaciones que se pueden ver son las conexiones y el número de estas que se han producido durante la prueba.

En el caso de que se hubieran detectado errores importantes se podría ver una pantalla como la siguiente:

Una de las actividades que permite Apptim es, desde el menú principal, acceder a las diferentes sesiones que se han llegado a ejecutar y podemos compararlas para ver la evolución que se ha producido. Esta funcionalidad deja ver la evolución de la aplicación en cuanto a los KPI’s identificados se refiere.

Aparte de las prestaciones ya mencionadas, esta aplicación nos permite crear workspaces donde guardar las sesiones que hemos ido ejecutando para su posterior comparativa y disponer una trazabilidad de los tests que se han ejecutado.

Integración con otros sistemas.

A la hora de llevar a cabo las pruebas se puede realizar, como se ha visto a lo largo del post, de una manera local, pero cabe la posibilidad de integrar los resultados en otras aplicaciones como Jira. Se puede ver aquí cómo realizar esta integración y qué elementos se pueden visualizar dentro de Jira que permitan ver el resultado de las pruebas efectuadas.

Igualmente, se puede integrar dentro de un flujo de CI/CD, tal y como se puede ver en la documentación, aquí, a través de Apptim CLI.

Una de las posibilidades que ofrece Apptim es integrar dentro del código que se desarrolla en la app la siguiente línea de código en el caso de Android Log.i("{Apptim_EVENT}", "event-name") con la que definimos un evento cuyo resultado se ve en las gráficas permitiendo controlar de forma visual al evolución de una parte del código especifica.

Conclusiones.

A la hora de afrontar un proceso de QA & testing en una app nativa tanto Android como iOS no se debe de pensar únicamente en la validación de los servicios que soportan las diferentes funcionalidades, ni en las pruebas funcionales que garanticen el correcto funcionamiento de la app. Es preciso ir más allá y validar en etapas tempranas del SLDC los parámetros de rendimiento de la app sobre un dispositivo. El uso de CPU, de Memoria, FPS y otros factores influyen en las posibilidades de éxito de una app en el mercado. Una buena funcionalidad, lenta, deja de ser buena.

La herramienta que se ha presentado en este post, Apptim, permite realizar este tipo de tests de una manera sencilla. Proporciona información suficiente para abordar el proceso de mejora de las apps en cuanto a rendimiento se refiere desde un primer momento.

A la hora de abordar un proceso de testing, el hacerlo de una manera estructurada (tal y como se ha sugerido en el artículo) ayuda a identificar las actividades de prueba que harán que la validación sea más eficaz.