La automatización de pruebas ayuda a resolver varios problemas a la vez, incluso cuando se trata de aplicaciones móviles. En lugar de realizar manualmente procedimientos rutinarios intensivos en mano de obra, los especialistas pueden delegar una parte importante de ellos en los marcos. La automatización simplifica las pruebas y ayuda a acelerar las pruebas de regresión, y también hace posible el uso de tipos de pruebas previamente inaccesibles.
Compararemos varias herramientas que se han establecido en el mercado y continúan desarrollándose. Este conocimiento lo ayudará a elegir qué solución usar para probar una aplicación móvil en particular.
Es poco probable que este artículo abra nuevos horizontes para los profesionales, pero puede ser útil para los principiantes que han decidido aprender los conceptos básicos de las pruebas móviles y, en cierta medida, los especialistas de nivel medio.
Clasificación de herramientas
Lo primero que debe construir es la plataforma en la que se ejecuta la aplicación. En base a esto, clasificamos la lista de herramientas de la siguiente manera:
AndroidiOSUniversal- Desintoxicación
- Appium
- Ranorex
- TestComplete Mobile
Automatización de pruebas de aplicaciones de Android
UI Automator
Potente herramienta de prueba con integración externa avanzada. Esto significa que este marco no solo le permite probar la aplicación en sí, sino que también puede "comunicarse" con el sistema operativo y otras aplicaciones, por ejemplo, activar y desactivar Wi-Fi, GPS, abrir el menú de configuración durante la prueba y realizar otras interacciones externas.
El propósito de UI Automator es la prueba de caja negra. Esto significa que el análisis se realiza desde la posición de un usuario externo sin acceso al código.
Las características clave incluyen:
- UI Automator Viewer para rastrear y analizar componentes que se muestran en la pantalla durante la prueba. Proporciona información sobre los elementos y sus propiedades, lo que facilita la creación de pruebas más relevantes.
- API para obtener información sobre el estado del dispositivo y ejecutar procesos en él.
- API de UI Automator para pruebas multiplataforma.
Enlace a la documentación .
Expreso
Una herramienta más ligera que UI Automator, no adecuada para interactuar con aplicaciones externas, pero conveniente para probar una caja blanca con acceso al código fuente de una aplicación en particular o probar una caja gris, que tiene acceso a algunos procesos y estructura internos.
Sin embargo, Espresso se destaca con su potente API
https://github.com/hamcrest . La interfaz agrega métodos convenientes para las comprobaciones en pruebas automáticas, por ejemplo:
afirmar_que (1, menos_o_equal (2)). Para probar webview, se utilizan métodos
especiales .
UI Automator y Espresso son mutuamente complementarios y se pueden usar en combinación dentro del mismo proyecto.
Enlace a la documentación .
Prueba de automatización para aplicaciones iOS
XCUITest
Una herramienta para pruebas de caja negra sin acceder al código de la aplicación. Solo funciona con productos nativos; desafortunadamente, las pruebas entre aplicaciones no funcionarán.
Por otro lado, la naturaleza nativa del marco es una ventaja desde el punto de vista de que cuando se usa XCUITest, el grado de comprensión mutua de los desarrolladores y probadores está en un nivel mucho más alto que en los casos en que uno y el otro usan idiomas diferentes.
Una adición útil es el grabador de pruebas, que hace posible escribir pruebas al registrar acciones en la aplicación incluso para aquellos que no trabajan con el código.
La herramienta le permite evitar errores comunes y manipulaciones innecesarias, inaccesibles para el usuario, con el código. Sin embargo, XCUITest también tiene algunas desventajas.
XCUITest, a diferencia de Espresso, funciona en un hilo separado, durante las pruebas debe esperar la aparición de ciertos elementos y parámetros. El estado actual de la aplicación no se lee y los retrasos en la actualización de los datos pueden provocar la incapacidad de detectar los elementos solicitados.
Documentación XCTest y XCUITest .
Earlgrey
El énfasis de EarlGrey está en reproducir la experiencia del usuario. Mientras los elementos en la pantalla no se presenten visualmente, la simulación de trabajar con la aplicación no se inicia.
Al mismo tiempo, se observan una serie de comodidades y ventajas. En primer lugar, a los expertos les gusta la forma en que el marco sincroniza solicitudes, interfaces de usuario y subprocesos. No se necesitan waitforview y wait.
En segundo lugar, como ya se mencionó, se presta especial atención al seguimiento de la visibilidad de los elementos. La herramienta tiene una capa adicional para verificar la carga de la interfaz y reproduce los gestos del usuario (deslizamiento, clics) directamente en el nivel de evento de la aplicación.
Enlaces al repositorio:
github.com/google/EarlGrey y
google.imtqy.com/EarlGrey .
Herramientas universales
Las herramientas universales (o "combina") le permiten no limitar su elección solo a Android o iOS, sino trabajar con ambas plataformas.
Dichas herramientas son aplicables para probar aplicaciones de los siguientes tipos:
- Aplicaciones nativas (aplicaciones nativas): escritas directamente bajo el SDK de Android, iOS y Windows.
- Aplicaciones web móviles: disponibles a través de un navegador móvil, como Safari o Chrome.
- Aplicaciones híbridas (aplicaciones híbridas): el usuario trabaja con el shell de la aplicación web, es decir, interactúa con el contenido web a través de la interfaz de la aplicación nativa.
Desintoxicación
En nuestra opinión, Detox es conveniente para aplicaciones escritas en React Native. Las pruebas están escritas en JavaScript, mientras que las aplicaciones iOS y Android se generan a partir del mismo código JavaScript y son lo más similares posible. Esto le permite utilizar las mismas pruebas para ambas plataformas.
Una característica clave de Detox es la prueba de caja gris. En este caso, el marco tiene cierto acceso a mecanismos internos, lo que le permite correlacionar el comportamiento externo de la aplicación con lo que sucede a un nivel más profundo.
Detox puede acceder a la memoria y rastrear los procesos en ejecución. El principio de la caja gris ayuda a combatir la inestabilidad, que se refleja en el hecho de que durante las pruebas de extremo a extremo:
- La prueba puede bloquearse aleatoriamente incluso sin cambios en el código;
- Los resultados no son deterministas: debido a la gran cantidad de funcionalidades y procesos heterogéneos dentro de la aplicación, los resultados de cada lanzamiento pueden diferir impredeciblemente entre sí.
- Los probadores se ven obligados a sincronizar manualmente, lo que implica una disminución en la confiabilidad y calidad de los resultados.
Curiosamente, la "caja gris" muestra no solo una mejor estabilidad, sino también una mayor velocidad en comparación con la "caja negra". Evitando todo tipo de pausas, espere Hasta que la caja gris puede ser 5-10 veces más rápida.
Detox no necesita WebDriver, trabajando con el controlador nativo a través de JSON. Utiliza métodos nativos directamente en el dispositivo. Dentro de este marco, se utilizan EarlGrey para iOS y Espresso para Android.
El marco funciona con emuladores y dispositivos físicos.
Enlace a la documentación .
Appium
La ventaja de Appium es que es posible escribir pruebas para cada plataforma utilizando una única API, sin recurrir a convertir la aplicación en ninguna forma especial compatible con el marco.
Al realizar la prueba, se utilizan marcos de proveedores, es decir, está trabajando con la aplicación original. Para Android 4.2+, respectivamente, se usa UiAutomator / UiAutomator2, y para iOS 9.3+ - XCUITest. WebDriver (también conocido como Selenium WebDriver) se utiliza como marco de trabajo.
Principios de Appium:
- No es necesario volver a compilar la aplicación o modificarla para automatizar las pruebas.
- No es necesario estar conectado a un idioma o marco.
- No es necesario reinventar la rueda cuando se trata de API de automatización.
El uso de Appium está justificado cuando necesita una herramienta para automatizar las pruebas en múltiples plataformas a la vez. Es útil si tiene especialistas con experiencia en pruebas de aplicaciones web, pero sin experiencia en la automatización de pruebas de aplicaciones móviles.
En general, esta es una herramienta flexible que puede modificarse para adaptarse a las necesidades del proyecto sin la necesidad de adaptarse a un conjunto limitado de lenguajes de desarrollo.
Enlace a la documentación .
Ranorex
Herramienta integral de pago para probar aplicaciones de escritorio, móviles y web. Permite probar usando programación y sin usar scripts. Proporciona la capacidad de probar no solo a través de emuladores, sino también en dispositivos en vivo.
La herramienta le permite crear y configurar pruebas, así como administrarlas centralmente. Puede crear una prueba en el centro de control y ejecutarla en varios entornos externos y en cualquier dispositivo.
Se integra fácilmente con su entorno de CI existente: con sistemas de gestión de aplicaciones como Jira y TFS, así como con sistemas de control de versiones como Git y SVN.
Ranorex tiene pruebas basadas en datos con carga de datos desde SQL, CSV y Excel.
La herramienta es adecuada para absolutamente cualquier dispositivo, admite pruebas paralelas en cada uno de ellos.
Combina los tres enfoques de prueba: caja negra, caja blanca y caja gris.
Enlace a la documentación .
Prueba completa
Entorno pagado para probar la automatización de aplicaciones móviles, web y de escritorio. Es compatible con Android e iOS, y en el contexto de los tipos de aplicaciones: nativas, aplicaciones web e híbridas.
Centrada principalmente en pruebas funcionales y unitarias, la herramienta también proporciona la capacidad de realizar muchos otros tipos de pruebas:
- Regresión;
- Pruebas basadas en datos;
- Pruebas distribuidas y más.
Hay un grabador en TestComplete; en él, las pruebas se crean registrando acciones y configurando comandos en el editor. Luego pueden iniciarse directamente en la herramienta o exportarse a aplicaciones de terceros.
Esta herramienta reconoce objetos y controles al ofrecer comandos especiales para emular la interacción del usuario con ellos. Se integra con Jenkins, Git y Jira, lo que le permite ejecutar pruebas continuas sin interrupciones.
Enlace a la documentación .
Para resumir
Cuando planee probar esta o aquella aplicación móvil, preste atención a las herramientas enumeradas anteriormente. Cada uno de ellos tiene sus propias características y, a veces, limitaciones.
Veamos un ejemplo. Si se enfrenta a la tarea de probar una aplicación pequeña en poco tiempo, primero debe tener en cuenta factores como el tipo de aplicación que se está probando y la experiencia de sus especialistas. Si un desarrollador escribe pruebas, es mejor elegir un idioma nativo y una herramienta para su plataforma (consulte la tabla a continuación). Si las pruebas son realizadas por especialistas de SDET que están familiarizados con otros lenguajes (Java, JavaScript, Python, etc.) y han trabajado con Selenium, es conveniente usar Appium. Si no hay un SDET experimentado en el equipo, y los expertos en control de calidad escribirán pruebas, es mejor elegir marcos pagados, ya que tienen utilidades para registrar pruebas y un soporte técnico más estable que los marcos de código abierto.
De nuestra práctica:
Trabajamos con una tienda en línea, que tenía dos aplicaciones móviles, en iOS y Android. Para probar los principales escenarios de usuario con pruebas, elegimos Appium por varias razones:
- multiplataforma, la capacidad de reutilizar parcialmente el código
- adecuado para pruebas de extremo a extremo, puede funcionar con web
- La presencia en el equipo de especialistas que conocen bien Selenium, que sirve como la cáscara de este marco.
Como resultado, Appium cumplió completamente con las expectativas, realizamos con éxito pruebas para iOS y Android. Debe tenerse en cuenta que tales pruebas de extremo a extremo con Appium no se llevan a cabo en cada solicitud de fusión, ya que lleva mucho tiempo.En conclusión, le presentamos una tabla que lo ayudará a elegir la herramienta para su proyecto. Cabe señalar que en algunos casos, la división en la tabla es condicional. En algún lugar para simplificar, se realiza una generalización y solo se proporcionan los parámetros más básicos. Las herramientas de prueba están en constante evolución, por lo que al elegir un marco es importante verificar la documentación actual.
Gracias por su atencion!