Lanzamiento de la cobertura de llamadas de UI para las pruebas de seguridad dinámicas

Este verano, el equipo de Ostorlab ha trabajado a pleno rendimiento y nos complace iniciar una serie de anuncios sobre diversas capacidades y funcionalidades nuevas en las próximas semanas. La primera es el lanzamiento de la UI call coverage y una nueva versión mejorada de nuestro Monkey Tester.

La nueva funcionalidad muestra el flujo de interfaz ejercitado durante el análisis dinámico y ofrece además una forma sencilla de validar la cobertura de la aplicación y de asegurarse de que se cubren los casos de uso críticos.

La nueva versión incorpora numerosas mejoras en la lógica del monkey tester, que permiten comprender mejor los componentes de la UI y generar eventos significativos que ofrecen una alta cobertura de la lógica de la aplicación.

Monkey testing y automatización de la interacción con la UI

El monkey testing es una técnica de pruebas automatizadas en la que un ejecutor de pruebas inyecta entradas y ejecuta clics o eventos en distintas partes de la aplicación para probar varios aspectos de esta, como la detección de fallos o errores, el seguimiento del rendimiento o los problemas de seguridad.

Durante el análisis dinámico, el escáner de Ostorlab utiliza dispositivos reales en los que el monkey tester genera una serie de eventos para interactuar con la aplicación. Las entradas pueden ser interacciones directas del usuario, como deslizar, pulsar un botón o rellenar un campo de texto, o interacciones con el sistema, como activar o desactivar la conexión Wifi, el Bluetooth o el GPS, o enviar un IPC.

Nuestra tecnología es compatible con las plataformas Android e iOS y cubre tanto las aplicaciones nativas como los frameworks multiplataforma como Xamarin, Cordova, Ionic y Flutter.

Aunque existen pocas herramientas de código abierto para automatizar las pruebas de UI, estas presentaban varios problemas:

• Se centran en una sola plataforma y carecen de una forma común de ejecutar o expresar las pruebas
• Ofrecen poco soporte para varias plataformas y frameworks habituales. Algunos frameworks, en particular, tienen enfoques muy peculiares para crear componentes de UI, como Xamarin y Flutter.
• Cubren mal los patrones de uso clave, como el registro con aceptación de políticas o el relleno de un menú de pago.

Para superar estos problemas y maximizar la cobertura de la aplicación en todas las plataformas, nos basamos en tres estrategias de exploración:

• Estrategia aleatoria
• Estrategia basada en reglas
• Estrategia evolutiva

Estrategias de exploración

El uso de estrategias similares no es exclusivo de Ostorlab. Varios proyectos de código abierto y artículos de investigación han implementado estrategias parecidas. La más destacada es Sapienz, de Facebook. La versión de código abierto no se mantiene, pero Facebook ha realizado varias presentaciones sobre las mejoras introducidas en la versión interna.

Una diferencia de diseño clave con la mayoría de estas implementaciones es que estas estrategias no se ejecutan por separado, sino que forman parte de una estrategia de conjunto que las combina. Esto permite transformar varias estrategias de bajo rendimiento en una sola estrategia sólida.

La segunda diferencia clave es que estas estrategias no generan casos de prueba rígidos que pueden aplicarse o no, ya que la reproducibilidad de las pruebas a menudo no está garantizada. En su lugar, estas estrategias generan test minions que tienen un conjunto de parámetros que modifican cómo interactuaría el minion con la aplicación y qué tipo de acción o sucesión de acciones debe privilegiar.

Estrategia aleatoria

La Random-based strategy es la técnica más básica para interactuar con la aplicación. Genera una serie aleatoria de eventos y resulta adecuada para vistas con componentes múltiples e independientes. Por ejemplo, una vista con distintos elementos pulsables, artículos de texto y vídeos.

Para ilustrar cómo funciona la estrategia aleatoria y medir su eficacia, esta es una vista sencilla con 6 componentes de UI. En este vídeo podemos ver los distintos eventos generados por el monkey tester y cómo los ejercita:

Con una estrategia aleatoria con 4 tipos de eventos (deslizar, clic, toque y marcar), se necesitan de media 30 eventos para interactuar con los 6 componentes de UI distintos. Para interactuar en una secuencia concreta, como Fill Textbox + Enable Checkbox + Click button 2, se necesitan de media 95 eventos.

Las estrategias aleatorias son simples, pero pueden tardar muchísimo (o no lograrlo nunca) en cubrir patrones lógicos complejos.

Estrategia basada en reglas

La Rule-based strategy correlaciona la interacción del usuario con el componente de UI de la aplicación. Utiliza mecanismos de búsqueda para identificar tipologías de componentes específicas y puede aplicar lógica avanzada a esos componentes. Esta técnica resulta adecuada para vistas con acciones predecibles según la tipología de los componentes. Por ejemplo, una vista de formulario con campos de texto que rellenar, varias casillas de verificación y un botón pulsable.

A continuación se muestra un ejemplo de una vista de inicio de sesión sencilla con un nombre de usuario, una contraseña y un botón de inicio de sesión.

En este ejemplo, una regla comprueba si hay un campo de contraseña en la vista actual, o realiza una comprobación más sofisticada para identificar una tarjeta de crédito o un componente de mapa

El monkey tester primero recorre todas las reglas para determinar cuáles coinciden con la vista actual y selecciona una al azar. En el ejemplo anterior, el monkey tester identificó primero que había varios campos de texto y empezó a rellenarlos todos con valores ficticios como parte de la interacción de la estrategia aleatoria; después aplicó una regla de inicio de sesión inyectando el nombre de usuario y la contraseña y haciendo clic en el botón de inicio de sesión.

Estrategia evolutiva

La Search-based strategy utiliza algoritmos de búsqueda metaheurísticos impulsados por algoritmos genéticos.

Los algoritmos genéticos se utilizan para optimizar los ajustes de los test minions con el fin de maximizar la cobertura. La estrategia realiza un seguimiento de las entradas y de la cobertura de la aplicación. En cada iteración, los ajustes se mutan para aumentar esa cobertura y descartar los minions de bajo rendimiento.

Esta estrategia es adecuada para aplicaciones con vistas de distintos recorridos que pueden variar según las entradas del usuario. Por ejemplo, un cuestionario en el que las respuestas pueden conducir a vistas diferentes según lo que se responda.

Resumen

Aunque cada estrategia mostró una buena cobertura en tipos de vistas específicos, la cobertura total de cada estrategia por separado, probada en más de 1000 aplicaciones móviles, fue relativamente baja.

La cobertura media más alta alcanzada fue del 35% para la estrategia aleatoria, del 27% para la estrategia basada en reglas y del 38% para la estrategia basada en búsqueda. Sin embargo, al combinar estas estrategias en una estrategia de conjunto que reúne todas las anteriores, se obtuvo una cobertura significativamente mayor, del 52%, en menos tiempo.

En conjunto, el monkey tester renovado y la nueva visibilidad de la cobertura de los casos de prueba ofrecerán una mayor cobertura y facilitarán visualizar y comprender lo que se ha hecho entre bastidores.