¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
dev
Santiago López 02/02/2022 Cargando comentarios…
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.
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.
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.
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:
Apptim | Firebase Test Lab | AWS Device Farm |
---|---|---|
Se puede usar en tiempo de desarrollo de una forma fácil. | Es necesario subir la app y las pruebas a la plataforma. | Es necesario subir la app y las pruebas a la plataforma. |
Se puede usar de forma local. | Su uso es cloud. | Su uso es cloud. |
No requiere una modificación en el código de la app | No requiere una modificación en el código de la app. Dentro de la app se pueden integrar las librerías de Firebase Crashlytics y Firebase Performance. Estas librerías remiten datos de todos los dispositivos de los usuarios que ejecuten la app. | No requiere una modificación en el código de la app. |
Curva de aprendizaje baja. | Curva de aprendizaje media. | Curva de aprendizaje media. |
Se realizan las pruebas en dispositivos físicos o emuladores. | Se realizan las pruebas en dispositivos virtuales o físicos de Google. | Se realizan las pruebas en dispositivos físicos o virtuales de Amazon. |
Se pueden realizar las pruebas sin test automáticos. | Se pueden seleccionar el conjunto de pruebas desde la consola. | Requiere de la codificación de pruebas automáticas que se han de subir a la plataforma. |
Plataforma: Windows, Mac, SaaS. | Plataforma: SaaS. | Plataforma: SaaS. |
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.
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.
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.
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.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Estamos comprometidos.
Tecnología, personas e impacto positivo.
Cuéntanos qué te parece.