Herramienta de automatización, pruebas automáticas.
En este artículo quisiera compartir la experiencia de desarrollo de una pequeña aplicación web realizada para una asignatura llamada «Pruebas automáticas» de la maestría en Ingeniería de Software que estoy cursando.
El código del proyecto puede encontrase en el siguiente enlace: https://github.com/Jorger/herramienta_pruebas_atomaticas
En esta asignatura aprendimos acerca de diferentes técnicas de pruebas automáticas, tanto para aplicaciones web, como para aplicaciones móviles, puntualmente Android.
Algunas de las técnicas vistas fueron:
- E2E Testing.
- Headless Testing
- Random testing en Aplicaciones Web y Móviles
- BDD (Behavior Driver Development) utilizando Cucumber (web) y Calabash (móvil Android)
- ADB Input, Telnet y Espresso
- Netflix Simian Army
- Mutation Testing
- Entre otras.
Herramienta de automatización.
El reto planteado para la entrega final de la asignatura, una vez visto, aprendido y puesta en práctica las técnicas anteriormente mencionadas, era el desarrollo de una herramienta que realizará pruebas automáticas, bien sea de aplicaciones web o de aplicaciones móviles, en este caso era posible extender las existentes, lo que el usuario debía entregar era el denominado SUT (Software under test) como podía ser la URL de una aplicación web o el empaquetado de una aplicación nativa, en este caso Android (APK).
Desarrollo Herramienta Web.
De las técnicas anteriormente descritas me llamaron atención Monkey testing, ADB Input y BDD, estas tres técnicas se ejecutan a través de la terminal con comandos de tipo adb shell en el caso de la primera y la segunda, la tercera a hace uso de la gema (ruby) android-calabash, lo que buscaba con la herramienta es ofrecer una experiencia similar (guardando las proporciones) de lo que ofrece servicios como firabase test Lab y AWS Device Farm, la cual consiste en pedir la APK y seleccionar los dispositivos a probar.
Tipos de técnicas seleccionadas.
Como lo comenté anteriormente se seleccionaron tres tipos de técnicas de pruebas para aplicaciones móviles, como son:
- ADB Input: El Android Debugging Bridge (adb) permite lanzar eventos de interacción sobre los dispositivos Android desde el terminal, eventos como:
- TAP
- TEXT
- SWIPE
- Keyevent
2. Monkey Testing: Haciendo uso del comando entregado por ADB se hace la ejecución de modo Monkey testing, teniendo opciones como establecimiento de la semilla y establecer el porcentaje de ejecución de evento como:
- Touch.
- Motion.
- Trackball.
- Navigation.
- KeyEvents
3. Behavior Driven Development (Calabash): Haciendo uso del lenguaje común como es Gherkin, se hace este tipo de pruebas, en este caso se solicita el archivo .features que contiene los pasos a seguir.
Proceso de ejecución.
En el siguiente vídeo se muestra el proceso de ejecución de las tres técnicas desarrolladas.
Tecnología utilizada.
Front end
- HTML5.
- CSS3.
- Bootstrap.
- Javascript/Jquery
- Socket.io
Back — end
- NodeJS Versión 9.0
- NPM 5.0
- Express 4.16
- Ruby 2.3.1
- Gema calabash-android.
Base de datos.
- Mysql 5.6.35
Preguntas acerca de la arquitectura.
- ¿Cómo es realizado el proceso de ejecución de las pruebas en los dispositivos?
Para realizar la prueba en diferentes dispositivos se ha hecho uso de Genymotion, el cual permite la ejecución de varios emuladores con diferentes versiones de Android.
- ¿Cómo es realizada la grabación de vídeo de las pruebas?
Para lograr este punto se ha utilizado el paquete screen-recorder, el cual permite grabar una región de pantalla, para este fin se disponen los emuladores en posiciones fijas, las cuales son almacenadas en la base de datos.
- ¿Como se evita la colisión de nombres de los archivos, si es que se hacen varias pruebas con la misma APK?
Para cada proyecto se crea una carpeta identificada por el id que tiene asignada en la base de datos, además de eso las APKs se han renombrado estableciendo el nombre con un hash, esto ayuda además a evitar problemas relacionados con APK’s que tengan espacios en nombre.
- ¿Cómo se sabe que equipos están disponibles/encendidos para las pruebas?
A través del módulo device.js desarrollado para el proyecto, se invoca el comando adb devices, el cual entrega el listado de equipos encendidos, éstos son almacenados en la base de datos (si es que no existen ya), además de ello se obtiene la información de los mismos, como nombre del equipo, identificador y dimensiones, que para el caso de acciones de tipo tap para ADB Input son necesarias, para así delimitar el rango en el cual se puede hacer la acción.
- ¿Es posible ejecutar pruebas en paralelo?
Es posible ejecutar varias pruebas dependiendo del número de dispositivos que estén encendidos, no es posible ejecutar varias pruebas a la vez en el mismo equipo, cuando un dispositivo es seleccionado éste pasa a un estado de “ocupado”, el cual sólo es liberado una vez la prueba haya culminado.
- ¿Como se ejecutan las pruebas de tipo adb input y monkey testing, ya que estas depende de ejecución de comandos en la consola?
ADB Input y Monkey testing depende del comando adb shell, para acceder a este comando se ha hecho uso del paquete child-process-promise, el cual permite la ejecución de comandos en consola, además de esto realiza el proceso a través de promesas, permitiendo aprovechar las nuevas funcionalidades de ES7 como es el manejo de async/await
- ¿Como se ejecutan las pruebas de tipo BDD — Calabash?
Para la ejecución de este tipo de pruebas fue necesario la instalación de la gema calabash-android, la cual expone una serie de comandos para la creación de la prueba, estos comandos se establecieron en una archivo .sh (Shell Command Language), el cual contiene los pasos necesarios para la creación del proyecto.
Fue necesario el uso del archivo .sh, debido a que algunos comandos como es el caso de calabash-android gen, exigen una segunda acción como es el <enter> para aceptar la creación del proyecto, una vez ejecutado el comando se utiliza el archivo .features solicitado al usuario para ejecutar la prueba, esto es almacenado en un directorio con el nombre del id que identifica la prueba en la base de datos.
- ¿Como se elige el emulador para hacer las pruebas?
Para las pruebas de tipo ADB Input y testing monkey existe el comando adb -s <id_dispositivo>
Ejemplo:
adb -s 192.168.56.101:5555 shell input tap 547 49
El cual es establecido en cada ejecución de los comandos adb shell, si no se establece este flag y existen varios emuladores disponibles saldrá un error indicando el problema.
Para el caso de las pruebas de tipo BDD — Calabash, en el comando calabash-android run se establece la variable de entorno ADB_DEVICE_ARG, la cual al igual que el comando anterior espera el id del dispositivo.
Ejemplo:
calabash-android run apk ADB_DEVICE_ARG=192.168.56.101:5555
- ¿Como se muestran la salidas de la consola en la aplicación?
Para mostrar los procesos que se están llevando a cabo en la ejecución de la prueba en tiempo real (para el caso de ADB Input) se hace uso de WebSockets a través de la librería Socket.io cada vez que sucede un cambio en el servidor, es informado al cliente, al mismo tiempo se está almacenando dicha salida en la base de datos, para la generación del log de eventos (figura 16)
- ¿Cómo se obtiene el nombre del paquete de la APK?
El nombre del paquete es necesario para indicar que la aplicación se ejecute, así como en el comando de adb shell monkey, para esto una vez se ha subido la apk a la aplicación, se hace uso de la herramienta aapt (Android Asset Packaging Tool) a través del comando:
aapt nombre_de_la.apk | grep ‘pack’
Este entrega el nombre del paquete, el cual es almacenado para la ejecución de los demás comandos que lo requieran.
- ¿Si la prueba en modo ADB Input se sale de la aplicación a probar, la prueba se detiene?
La prueba no se detiene, pero se ha realizado un proceso que cada 10 ejecuciones revise si la aplicación que se está probando está en primer plano, esto se logra con el comando:
dumpsys window windows | grep -E ‘mFocusedApp’| cut -d / -f 1 | cut -d
Este comando regresa el nombre del paquete que está en primer plano, si no es el mismo que está bajo pruebas, se ejecuta una función que contiene el comando para abrir la aplicación.
- ¿Cuánto es el tiempo de duración de una prueba?
Esto depende del tipo de prueba, para las pruebas de tipo ADB y monkey testing depende del número de eventos a realizar, para el caso de las pruebas de de tipo BDD — Calabash la configuración del proyecto toma algunos segundos, luego depende del número de pasos que contenga el archivo .features, además Calabash tiene una serie de timers, los cuales esperan hasta que se cumpla una condición.
- ¿Es posible seleccionar una apk que se haya subido antes para realizar una prueba?
No, la aplicación sólo permite la subida de una APK para realizar una nueva prueba, cada APK es almacenada en el directorio correspondiente al id que representa la prueba en la base de datos, además que el nombre de la misma es renombrado.
- ¿Cuántas tablas se manejan en el proyecto?
Por ser una prueba de concepto, el proyecto sólo maneja dos tablas como son:
- Tabla dispositivos: Guardará los dispositivos que existen, se utiliza está tabla demás para establecer el estado de uso de un dispositivo, para evitar que se envíen varias pruebas al mismo tiempo al mismo emulador.
- Tabla Test: Tabla contiene la configuración necesaria para la ejecución de la prueba.
Conclusiones.
- El desarrollo de está herramienta buscaba poner en práctica los temas aprendidos en la asignatura, seleccioné las pruebas de tipo móvil ya que no he profundizado en el desarrollo de aplicaciones móviles, me parece un tema muy interesante.
- Haciendo uso de NodeJS y las nuevas funcionalidades que nos trae sus últimas versiones (9.0 al momento del desarrollo) como async/await resultó muy fácil el manejo de los comandos de las pruebas, además la gran variedad de paquetes que nos ofrece NPM fue de gran ayuda.
- Las pruebas automáticas, es una herramienta de gran ayuda al momento de desarrollar una aplicación, tanto móvil como web, técnicas como monkey testing ayudan a encontrar problemas que un set de pruebas de tipo E2E tal vez no se evidencian.
- Me pareció interesante mucho de los temas vistos de pruebas automáticas, un ejemplo de ello es Mutation Testing, BDD, entre otros.
- Deseaba compartir este pequeño artículo, no por que sea un experto en el tema (que no lo soy), sino por mostrar la forma en que logré el desarrollo de esta pequeña aplicación, tal vez sea de ayuda para alguien, o tal vez me ayude a mi en el futuro.
Gracias por la atención prestada.
