Tengo que probarlos a todos: cómo probar las aplicaciones móviles de OutSystems

Hace un tiempo escribí un artículo en el que discutía el papel fundamental de las pruebas de aplicaciones móviles para impulsar la calidad de la aplicación y el impacto en la adopción y la satisfacción del usuario. Revisé la complejidad de las pruebas de aplicaciones móviles debido a la enorme variedad de diferentes dispositivos móviles, versiones de sistemas operativos y condiciones de red. Hoy quiero guiarlo a través de la prueba de aplicaciones móviles con OutSystems y AWS Device Farm.

El número de variables al probar las aplicaciones móviles de OutSystems, como con cualquier otra tecnología móvil, es enorme, incluso a nivel superficial. Dicho esto, siempre debes considerar mirar más profundo. Después de todo, una aplicación que no funciona correctamente solo pide que la desinstalen en el acto.

Solo hay una cantidad que puede probar sin alcanzar lo temido que puede destruir un escenario perfectamente construido: un dispositivo real. Las pruebas en dispositivos reales son logísticamente una caja de Pandora y es algo que atormenta los sueños de cualquier desarrollador móvil. Mi equipo y yo hemos perdido una buena cantidad de sueño por eso. Teníamos que encontrar una solución, una forma de probar sin estar enterrados debajo de una montaña de teléfonos móviles.

Existen muchas soluciones, como Visual Studio App Center, Perfecto o Saucelabs. Pero Amazon Device Farm ha resultado ser el antídoto para nuestras pesadillas. Device Farm, un marco de prueba de AWS que permite a los desarrolladores cargar y ejecutar pruebas en dispositivos reales de Android e iOS en la nube de AWS, le permite realizar pruebas automatizadas y tener sesiones de acceso remoto en dispositivos específicos con sus propias configuraciones, lo que significa que antes de conectarse a el dispositivo, podemos configurar su estado.

AWS también proporciona un SDK que se puede usar para interactuar con todos los servicios de AWS. De esta manera, podemos conectar Device Farm (o cualquier otro servicio) con nuestros paneles internos.

Además, AWS lanzó el Acceso directo a dispositivos para dispositivos privados. Con esta nueva característica, los desarrolladores pueden usar dispositivos individuales en su conjunto de prueba privado como si estuvieran conectados directamente a su máquina local a través de USB.

Device Farm también admite una amplia gama de marcos de automatización de pruebas como Appium, Calabash, XCTest y muchos otros, donde puede escribir sus propias pruebas.

Así que sí, es una herramienta bastante impresionante, especialmente cuando la ves funcionando.

Ensuciarse las manos: Amazon Device Farm y OutSystems

Entonces, ahora lo guiaré a través del uso de AWS Device Farm para probar las aplicaciones de OutSystems. Para verlo en acción, primero debemos crear las pruebas, por supuesto. Utilizaremos una aplicación simple de OutSystems, y vamos a probar la página de inicio de sesión en un dispositivo Android. Para obtener detalles técnicos sobre cómo configurar sus pruebas, eche un vistazo a estas muestras de prueba en GitHub; También puede seguir otros tutoriales de prueba.

1. Configuración de la máquina

Instale el marco de prueba de automatización que mejor se adapte a usted. Para este artículo, nos quedaremos con Appium. Al igual que Appium, algunos marcos soportan más de un lenguaje de programación. Así que asegúrese de instalar todo. Elegimos Python como nuestro lenguaje de programación.

2. Configuración de prueba

Comience creando su proyecto de prueba. Antes de enviar todas sus pruebas a Device Farm, le recomiendo ejecutar primero las pruebas exactas en su entorno de prueba local. Es más fácil encontrar la causa raíz de un problema localmente. También es menos costoso. Entonces, en su archivo de prueba principal, agregue las siguientes capacidades deseadas a su prueba.

desired_caps ['platformName'] = 'Android'
desired_caps ['deviceName'] = 'aPhone'
desired_caps ['appPackage'] = ''
desired_caps ['appActivity'] = ".MainActivity"

3. Planificación de pruebas y fases

Por lo general, no se crea una prueba para todo. Idealmente, aislarás cada parte de la aplicación que quieras probar. Por lo tanto, antes de comenzar a codificar su prueba, debe idear un plan. Siéntese, relájese y pruebe su aplicación, buscando las funciones principales que desea probar.

4. Creación de prueba

Ahora que tiene un plan, está listo para comenzar a configurar sus pruebas. Comencemos creando un archivo de prueba en la carpeta de pruebas y codificando un caso de prueba. Al codificar su prueba, prefija su método de prueba con la palabra "prueba"; Esto ayuda al marco de prueba a identificar qué método contiene nuestra prueba.

Estamos implementando pruebas de interacción, por lo que todo es secuencial. Primero, comenzaremos la prueba. A continuación, esperaremos a que se muestre un evento / elemento en la pantalla. Cuando se muestre el que esperábamos, haremos clic en él y luego esperaremos nuevamente a que aparezca el siguiente en la pantalla. Tienes la idea: comienza la prueba, espera, haz clic, espera. A veces, es posible que necesitemos usar una condición de sueño solo para asegurarnos de que ocurra un evento específico o que aparezca un elemento específico en la pantalla; de lo contrario, es posible que no lo notemos.

importar os
prueba de unidad de importación
desde appium import webdriver
de selenium.webdriver.common.by import By
desde selenium.webdriver.support.ui import WebDriverWait
desde selenium.webdriver.support import unknown_conditions como EC
clase TestClass (unittest.TestCase):
  
  def setUp (self):
   self.driver = webdriver.Remote ('http://127.0.0.1:4723/wd/hub', {})
  def test_case (self):
   ...
  def tearDown (auto):
   self.driver.quit ()
       
  if __name__ == '__main__':
   unittest.main ()

¿Cómo sé que hay algo en la pantalla? ¿Cómo hago clic en él? De acuerdo, esta es la parte difícil. ¿Recuerdas el artículo que escribí sobre la creación de aplicaciones nativas con OutSystems MABS hace un tiempo? En caso afirmativo, ya sabe que las aplicaciones de OutSystems son híbridas. Esto significa que algunos cambios que hacemos al crear nuestras aplicaciones OutSystems se asignan a HTML. Entonces, si siempre establece un atributo de datos con una etiqueta, le ayuda a identificar los elementos de su aplicación en el caso de prueba, y es más fácil encontrar el elemento con XPATH.

En el primer escenario, como se ve en los siguientes ejemplos, estamos tratando de encontrar una imagen. Agregamos un atributo con un valor que representa la imagen (en este caso, es "SuccessImg"), y lo buscamos con XPATH (// img [@ data-test-id = "SuccessImg"]). Cuando se trata de una lista, debemos tener mucho cuidado. Para encontrar un elemento específico en una lista, por ejemplo, el tercero, debemos asegurarnos de tener el índice del valor. Aquí, debemos buscar el atributo "data-test-id" con el valor "MyAttrId-2".

Sé que sé; Existen algunos escenarios específicos en los que no podemos probar una función específica de nuestra aplicación móvil OutSystems en un navegador web Chrome. La mayoría de estos casos suceden porque existe una dependencia directa de algún complemento nativo, que debe instalarse en la aplicación. Para ese escenario específico, tenemos que conectar nuestro dispositivo móvil a nuestra computadora, abrir Chrome y escribir chrome: // inspeccionar / # dispositivos en la URL. Esto abrirá una página que muestra todos los dispositivos que están conectados a su computadora.

Ahora, inspeccione su dispositivo y comience a buscar en su HTML. Busque los botones, anclas o enlaces que necesitará para navegar por su aplicación. Una buena forma de identificar los botones de su aplicación es usar el campo Id de HTML, pero, si por algún motivo ese botón específico no tiene un Id, puede usar XPATH en su lugar.

No olvide: los dispositivos iOS solo se pueden inspeccionar utilizando Safari en Mac y habilitando el inspector web en el dispositivo. Android puede ser inspeccionado por PC y Mac utilizando Chrome y habilitando las herramientas de desarrollador en el dispositivo.

5. Paquete de prueba

Hemos creado nuestra prueba y ahora estamos listos para enviarla a Amazon Device Farm. ¿Cómo podemos hacer esto? Es sencillo: ejecutando un comando podemos crear un archivo zip que contenga nuestro paquete de prueba. Este paquete de prueba es importante porque contiene la prueba y las bibliotecas que ejecutará AWS Device Farm. Para enviar las pruebas:

1. En la consola de AWS, cree el proyecto donde realizará sus pruebas y una nueva ejecución. Una ejecución representa una aplicación específica con un conjunto específico de pruebas en un conjunto específico de dispositivos. El trabajo preliminar está hecho.

2. Después de esto, debe cargar su paquete de aplicaciones y sus pruebas. Si no tiene ninguno, AWS lo cubre con dos pruebas integradas. En este ejemplo, usaremos el nuestro.

3. Ahora comienza la diversión: seleccione los dispositivos que desea probar y especifique el estado del dispositivo (WiFi, NFC, GPS, Bluetooth). Actualmente, AWS Device Farm tiene 178 dispositivos Android y 162 dispositivos iOS. Para Android, hay 139 dispositivos distintos (Motorola, Samsung, Wiko, etc.) que funcionan con 23 versiones diferentes de Android. Para iOS, hay 26 dispositivos distintos (iPad 2, iPhone 8, iPod Touch 6th Gen, etc.) que funcionan con 26 versiones diferentes de iOS.

4. ¡Vete a tiempo! ¡Revise, ejecute y vea los resultados! Cada ejecución produce un informe con los registros del dispositivo, registros de prueba, capturas de pantalla, videos y más.

Envolver

Device Farm es muy útil. Ahora podemos ofrecer continuamente nuevas características, mejoras y correcciones de errores con un alto nivel de confianza. Nuestros desarrolladores ahora desarrollan nuevas funciones y las prueban de inmediato.

Esta herramienta también nos ayudó con nuestros casos de soporte. Como sabrás, no es factible tener todos los dispositivos y versiones de sistema operativo diferentes. Con esta herramienta, no tenemos que perder una noche de sueño por esto; cada año, AWS Device Farm agrega nuevos dispositivos a su servicio. Por lo tanto, cada vez que recibimos un caso de soporte para algo que no funciona como se esperaba en un dispositivo Lava Iris, Ulefone o Mlais, podemos solicitar acceso remoto a Device Farm, y podemos acceder y probar la aplicación en el dispositivo en tiempo real .

¡Te reto a que lo pruebes, y ahora depende de ti! Esto no es tan sencillo como el código bajo, pero tampoco es tan complicado como parece. El retorno de su esfuerzo valdrá la pena. Y no olvide que usamos AWS Device Farm con Appium, pero puede usar otras granjas de dispositivos. Además, como mencioné anteriormente, tiene todo explicado aquí, aquí y aquí. ¡Háganos saber cómo le funcionó esta solución!