He de provar-los tots: com provar les aplicacions mòbils OutSystems

Fa un temps vaig escriure un article sobre el paper central de les proves d'aplicacions mòbils per augmentar la qualitat de l'aplicació i l'impacte que té en l'adopció i satisfacció dels usuaris. He explorat la complexitat de provar aplicacions mòbils a causa de la gran varietat de dispositius mòbils, versions del sistema operatiu i condicions de xarxa. Avui us vull fer una prova d’aplicacions mòbils amb OutSystems i AWS Device Farm.

El nombre de variables en provar les aplicacions mòbils d’OutSystems, com qualsevol altra tecnologia mòbil, és enorme, fins i tot a nivell superficial. Dit això, sempre hauríeu de plantejar-vos mirar més a fons. Al cap i a la fi, una aplicació defectuosa només us demana que la desinstal·leu immediatament.

Només podeu provar tantes coses sense arribar a l’element temible que pugui destruir un escenari perfectament construït: un dispositiu real. Fer proves en dispositius reals és un repte logístic per a Pandora i deixa enrere els somnis de qualsevol desenvolupador de mòbils. El meu equip i jo vam perdre força son. Vam haver de trobar una solució, una manera de provar sense ser enterrats sota una muntanya de telèfons mòbils.

Hi ha moltes solucions com Visual Studio App Center, Perfecto o Saucelabs. Però Amazon Device Farm ha demostrat ser un antídot contra els nostres malsons. Device Farm és un marc de proves AWS que permet als desenvolupadors carregar i executar proves en dispositius Android i iOS reals al núvol AWS. Podeu executar proves automatitzades i executar sessions d'accés remot en dispositius específics amb les seves pròpies configuracions, abans de connectar el dispositiu podem configurar-ne l'estat.

AWS també ofereix un SDK que podeu utilitzar per interactuar amb tots els serveis d’AWS. D’aquesta manera, podem connectar la granja de dispositius (o qualsevol altre servei) als nostres taulers de comandament interns.

AWS també va llançar accés directe al dispositiu per a dispositius privats. Amb aquesta nova característica, els desenvolupadors poden utilitzar dispositius individuals en el seu conjunt de proves privades com si estiguessin connectats directament al seu ordinador local mitjançant USB.

Device Farm també admet una gran varietat de marcs d'automatització de proves, com Appium, Calabash, XCTest i molts altres en què podeu escriure les vostres pròpies proves.

Així que sí, és una eina bastant impressionant, sobretot quan ho veieu com funciona.

Embrutar-se les mans: Amazon Device Farm i OutSystems

Ara us faré un recorregut mitjançant AWS Device Farm per provar les aplicacions d’OutSystems. Per descomptat, per veure-ho en acció, primer hem de crear les proves. Utilitzarem una senzilla aplicació OutSystems i provarem la pàgina d'inici de sessió en un dispositiu Android. Els detalls tècnics sobre la configuració de les proves es poden trobar en aquests exemples de proves a GitHub. També podeu seguir altres tutorials de proves.

1. Configureu la màquina

Instal·leu el marc de proves d'automatització que us funcioni millor. Per a aquest article, ens quedarem amb Appium. Igual que Appium, alguns frameworks admeten més d’un llenguatge de programació. Així que assegureu-vos d’instal·lar-ho tot. Vam triar Python com a llenguatge de programació.

2. Configureu la prova

Comenceu a crear el vostre projecte de prova. Abans d’enviar totes les proves a la granja d’equips, us recomanem que feu primer les proves exactes al vostre entorn de proves local. És més fàcil trobar la causa principal d’un problema a nivell local. També és més barat. Afegiu les següents funcions desitjades a la prova al fitxer de prova principal.

desitjats_caps ['platformName'] = 'Android' desitjats_caps ['deviceName'] = 'unPhone' desitjats_caps ['appPackage'] = ' 'desitjat_caps [' appActivity '] = ".Activitat principal"

3. Planificació i fases de proves

No sol crear una prova per a tot. Idealment, aïllareu totes les parts de l’aplicació que vulgueu provar. Abans de començar a codificar la prova, heu de crear un pla. Seieu, relaxeu-vos i proveu la vostra aplicació. Cerqueu les funcions principals que voleu provar.

4. Creació de proves

Ara que heu creat un pla, és hora de començar a configurar les proves. Comencem creant un fitxer de prova a la carpeta de prova i codificant un cas de prova. Quan codifiqueu el mètode de prova, heu de posar prèviament la paraula "prova". D'aquesta manera, el marc de prova pot determinar quin mètode conté la nostra prova.

Fem proves d’interacció perquè tot passi de manera seqüencial. Primer comencem la prova. A continuació, esperem que aparegui un esdeveniment / element a la pantalla. Quan aparegui l'esperat, hi fem clic i tornem a esperar que aparegui el següent a la pantalla. La vostra idea és: iniciar la prova, esperar, fer clic, esperar. De vegades és possible que hàgim d’utilitzar una condició de son per assegurar-nos que es produeixi un esdeveniment determinat o que aparegui un determinat element a la pantalla. En cas contrari, no ens adonarem.

import unittest import from appium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC
Class 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 () si __name__ == '__main__': unittest.main ()

Com puc saber que hi ha alguna cosa a la pantalla? Com puc fer-hi clic? D’acord, això és el més difícil. Recordeu l'article que vaig escriure fa un temps sobre la creació d'aplicacions natives amb OutSystems MABS? Si és així, ja sabeu que les aplicacions OutSystems són aplicacions híbrides. Això significa que alguns dels canvis que fem quan construïm les nostres aplicacions OutSystems es mapen a HTML. Si sempre definiu un atribut de dades amb un nom, podeu identificar els elements de l'aplicació més fàcilment en el cas de prova i trobar-lo més fàcilment amb XPATH.

El primer escenari intenta trobar una imatge com es mostra als exemples següents. Hem afegit un atribut amb un valor que representa la imatge (en aquest cas "SuccessImg") i el hem cercat amb XPATH (// img [@ data-test-id = "SuccessImg"]). Hem de tenir molta precaució a l’hora de tractar una llista. Per trobar un element específic en una llista, per exemple el tercer, hem d'assegurar-nos que tenim l'índex del valor. Aquí hem de buscar l'atribut "data-test-id" amb el valor "MyAttrId-2".

Ho sé, ho sé; En determinats casos, no podem provar una determinada funció de la nostra aplicació mòbil OutSystems en un navegador web Chrome. La majoria d'aquests casos es produeixen perquè hi ha una dependència directa d'un connector natiu que cal instal·lar a l'aplicació. Per a aquest escenari en concret, hem de connectar el nostre dispositiu mòbil a l'ordinador, obrir Chrome i introduir chrome: // inspect / # dispositius a l'URL. Això mostrarà una pàgina que llista tots els dispositius connectats a l'ordinador.

Ara, examineu el dispositiu i comenceu a aprofundir en HTML. Cerqueu els botons, les àncores o els enllaços que necessiteu per navegar per la vostra aplicació. Una bona manera d’identificar els botons de l’aplicació és fer servir el camp d’identificació HTML. Tanmateix, si per alguna raó aquest botó en particular no té cap identificador, podeu utilitzar XPATH.

No ho oblideu: els dispositius iOS només es poden escanejar mitjançant Safari en Mac i habilitant l’inspector web al dispositiu. Tant els ordinadors com els Mac poden comprovar Android mitjançant Chrome i habilitar les eines per a desenvolupadors del dispositiu.

5. Agrupació de proves

Hem creat la nostra prova i ara la podem enviar a Amazon Device Farm. Com ho podem fer? És molt senzill: quan executeu una ordre podeu crear un fitxer zip que contingui el nostre paquet de prova. Aquest paquet de prova és important perquè conté la prova i les biblioteques que executarà AWS Device Farm. Com enviar les proves:

1. A la consola AWS, creeu el projecte en què executareu les proves i en feu una nova. Una execució representa una aplicació específica amb un conjunt específic de proves en un conjunt específic de dispositius. S’ha realitzat el treball previ.

2. A continuació, haureu de penjar el paquet de l'aplicació i fer proves. Si no en teniu cap, AWS va realitzar dues proves integrades. En aquest exemple estem utilitzant el nostre.

3. Ara comença la diversió: seleccioneu els dispositius que voleu provar i indiqueu l'estat del dispositiu (WiFi, NFC, GPS, Bluetooth). Actualment, AWS Device Farm té 178 dispositius Android i 162 iOS. Hi ha 139 dispositius diferents per a Android (Motorola, Samsung, Wiko, etc.) que funcionen amb 23 versions diferents d'Android. Hi ha 26 dispositius diferents per a iOS (iPad 2, iPhone 8, iPod Touch de 6a generació, etc.) que es poden utilitzar amb 26 versions diferents d’IOS.

4. Vés! Comproveu, executeu i visualitzeu els resultats. Es crea un informe amb cada execució amb els registres de dispositius, registres de proves, captures de pantalla, vídeos i molt més.

Embolicar

La granja de dispositius és molt útil. Ara podem oferir contínuament noves funcions, millores i correccions d’errors amb un alt nivell de confiança. Els nostres desenvolupadors estan desenvolupant noves funcions i provant-les immediatament.

Aquesta eina també ens va ajudar amb els nostres casos de suport. Com ja sabreu, és impossible tenir tots els dispositius i versions del sistema operatiu diferents. Amb aquesta eina no hem de perdre la son. Cada any AWS Device Farm afegeix dispositius nous al seu servei. Sempre que rebem un cas d'assistència per a alguna cosa que no funcioni com s'esperava en un dispositiu Lava Iris, Ulefone o Mlais, podem sol·licitar accés remot a la granja de dispositius i mostrar i provar l'aplicació en temps real al dispositiu .

Us insto a provar-ho i ara us toca a vosaltres! Això no és tan senzill com el codi baix, però tampoc és tan complicat com sembla. El retorn del vostre esforç valdrà la pena. No oblideu que hem utilitzat la granja de dispositius AWS amb Appium. Tanmateix, també podeu utilitzar altres granges de dispositius. Com he esmentat anteriorment, ho heu explicat tot aquí, aquí i aquí. Feu-nos saber com us ha funcionat aquesta solució.