Gotta Test 'em All: Sådan testes OutSystems mobile apps

For et stykke tid siden skrev jeg en artikel, hvor jeg drøftede den centrale rolle, som mobilapptest spiller i appens kvalitet og indvirkningen på brugernes vedtagelse og brugertilfredshed. Jeg gik over kompleksiteten i test af mobile apper på grund af det enorme udvalg af forskellige mobile enheder, operativsystemversioner og netværksforhold. I dag vil jeg lede dig gennem test af mobile apps med OutSystems og AWS Device Farm.

Antallet af variabler, når man tester OutSystems mobile apps, ligesom med enhver anden mobilteknologi, er enormt, selv på overfladeniveau. Når det er sagt, skal du altid overveje at se dybere. Når alt kommer til alt beder en app, der fungerer korrekt, bare om at blive afinstalleret på stedet.

Der er kun så meget, du kan teste uden at nå frem til den frygtede ting, der kan ødelægge et perfekt bygget scenario: en rigtig enhed. Testning på rigtige enheder er en Pandoras boks logistisk og er noget, der hjemsøger drømme for enhver mobiludvikler. Mit team og jeg har mistet en god del søvn over det. Vi måtte finde en løsning, en måde at teste uden at blive begravet under et bjerg af mobiltelefoner.

Der er mange løsninger derude, såsom Visual Studio App Center, Perfecto eller Saucelabs. Men Amazon Device Farm har vist sig at være modgift for vores mareridt. En AWS-testramme, der giver udviklere mulighed for at uploade og køre test på rigtige Android- og iOS-enheder i AWS-skyen, Device Farm giver dig mulighed for at udføre automatiserede test og have fjernadgangssessioner på specifikke enheder med deres egne konfigurationer, hvilket betyder, at før du opretter forbindelse til enheden, kan vi konfigurere dens tilstand.

AWS leverer også en SDK, der kan bruges til at interagere med alle AWS-tjenester. På denne måde kan vi forbinde Device Farm (eller enhver anden service) med vores interne dashboards.

AWS har også lanceret direkte enhedsadgang til private enheder. Med denne nye funktion kan udviklere bruge individuelle enheder i deres private testsæt, som om de var direkte tilsluttet deres lokale maskine via USB.

Device Farm understøtter også en lang række testning af automatiseringsrammer som Appium, Calabash, XCTest og mange andre, hvor du kan skrive dine egne test.

Så ja, det er et ret imponerende værktøj, især når du ser det fungere.

At få dine hænder beskidte: Amazon Device Farm og OutSystems

Så nu vil jeg lede dig gennem at bruge AWS Device Farm til at teste OutSystems-apps. For at se det i handling, er vi selvfølgelig nødt til at oprette testene! Vi bruger en simpel OutSystems-applikation, og vi tester login-siden på en Android-enhed. For de tekniske detaljer om, hvordan du konfigurerer dine test, skal du se på disse testprøver på GitHub; Du kan også følge andre testtutorials.

1. Maskinopsætning

Installer den automatiseringstestramme, der bedst passer til dig. Til denne artikel holder vi os med Appium. Ligesom Appium understøtter nogle rammer mere end et programmeringssprog. Så sørg for at installere alt. Vi valgte Python som vores programmeringssprog.

2. Testopsætning

Start med at oprette dit testprojekt. Inden du sender alle dine test til Enhedsgården, anbefaler jeg stærkt, at du først kører de nøjagtige tests i dit lokale testmiljø. Det er lettere at finde den grundlæggende årsag til et problem lokalt. Det er også billigere. Så i din vigtigste testfil skal du tilføje følgende ønskede funktioner til din test.

ønsket_caps ['platformName'] = 'Android'
ønsket_caps ['deviceName'] = 'aPhone'
ønsket_caps ['appPackage'] = ''
wanted_caps ['appActivity'] = ".MainActivity"

3. Testplanlægning og fasning

Du opretter typisk ikke en test for alt. Ideelt set isolerer du hver del af den app, du vil teste. Så inden du begynder at kode din test, skal du komme med en plan. Sæt dig ned, slap af og prøv din applikation ved at søge efter de vigtigste funktioner, du vil teste.

4. Testoprettelse

Nu hvor du har en plan, er du klar til at begynde at oprette dine test. Lad os begynde med at oprette en testfil i testmappen og kode en testkase. Når du koder din test, skal du præfikse din testmetode med ordet "test"; dette hjælper testrammerne med at identificere, hvilken metode vores test indeholder.

Vi implementerer interaktionstests, så alt er i rækkefølge. Først starter vi testen. Dernæst venter vi på, at en begivenhed / enhed vises på skærmen. Når den, vi forventede, vises, klikker vi på den, og venter derefter igen til den næste vises på skærmen. Du får ideen: start testen, vent, klik, vent. Nogle gange er vi muligvis nødt til at bruge en søvntilstand bare for at sikre os, at der sker en bestemt begivenhed, eller at der vises et bestemt emne på skærmen Ellers bemærker vi det muligvis ikke.

import os
import unestest
fra appium import-webdriver
fra selen.webdriver.common.by import af
fra selen.webdriver.support.ui importer WebDriverWait
fra selen.webdriver.support import forventede_betingelser som EF
klasse TestClass (unittest.TestCase):
  
  def setUp (selv):
   self.driver = webdriver.Remote ('http://127.0.0.1:4723/wd/hub', {})
  def test_case (selv):
   ...
  def tearDown (selv):
   self.driver.quit ()
       
  hvis __name__ == '__main__':
   unittest.main ()

Hvordan ved jeg, at der er noget på skærmen? Hvordan klikker jeg på det? Okay, dette er den vanskelige del. Kan du huske den artikel, som jeg skrev om at bygge native apps med OutSystems MABS for et stykke tid tilbage? Hvis ja, ved du allerede, at OutSystems-applikationer er hybrid. Dette betyder, at nogle ændringer, vi foretager, når vi opretter vores OutSystems-applikationer, kortlægges til HTML. Så hvis du altid indstiller en dataattribut med en etiket, hjælper det dig med at identificere dine applikationselementer i testtilfældet, og det er lettere at finde elementet med XPATH.

I det første scenarie, som det ses i de følgende eksempler, forsøger vi at finde et billede. Vi tilføjede en attribut med en værdi, der repræsenterer billedet (i dette tilfælde er det "SuccessImg"), og vi søgte efter det med XPATH (// img [@ data-test-id = "SuccessImg"]). Når vi behandler en liste, er vi nødt til at være ekstra omhyggelige. For at finde et specifikt element på en liste, for eksempel det tredje, er vi nødt til at sikre, at vi har indeks for værdien. Her skal vi kigge efter attributten "datatest-id" med værdien "MyAttrId-2".

Jeg ved, jeg ved; der er nogle specifikke scenarier, hvor vi ikke kan teste en bestemt funktion af vores OutSystems-mobilapplikation i en Chrome-webbrowser. De fleste af disse tilfælde sker, fordi der er en direkte afhængighed af noget indbygget plugin, som skal installeres i applikationen. I det specifikke scenarie er vi nødt til at forbinde vores mobile enhed til vores computer, åbne Chrome og skrive chrome: // inspect / # enheder i URL'en. Dette åbner en side, der viser alle de enheder, der er tilsluttet din computer.

Nu skal du inspicere din enhed og begynde at grave i din HTML. Søg efter de knapper, ankre eller links, du har brug for for at navigere i din app. En god måde at identificere dine app-knapper er at bruge feltet HTML-id, men hvis den specifikke knap af en eller anden grund ikke har en id, kan du i stedet bruge XPATH.

Glem ikke: iOS-enheder kan kun inspiceres ved hjælp af Safari på Macs og ved at aktivere webinspektøren på enheden. Android kan inspiceres af både pc'er og Mac'er ved hjælp af Chrome og aktivere udviklerværktøjerne på enheden.

5. Testbundling

Vi har oprettet vores test, og nu er vi klar til at sende den til Amazon Device Farm. Hvordan kan vi gøre dette? Det er ligetil: at køre en kommando, vi kan oprette en zip-fil, der indeholder vores testbundt. Dette testbundt er vigtigt, fordi det indeholder testen og bibliotekerne, der vil blive udført af AWS Device Farm. For at indsende prøverne:

1. Opret i projektet AWS-konsollen, hvor du vil udføre dine test og en ny kørsel. En kørsel repræsenterer en bestemt app med et specifikt sæt tests på et specifikt sæt enheder. Grundlæggende arbejde er færdig.

2. Herefter skal du uploade din app-pakke og dine test. Hvis du ikke har nogen, har AWS du dækket med to indbyggede tests. I dette eksempel bruger vi vores egne.

3. Nu begynder det sjove: vælg de enheder, du vil teste, og specificer enhedstilstanden (WiFi, NFC, GPS, Bluetooth). I øjeblikket har AWS Device Farm 178 Android- og 162 iOS-enheder. Til Android er der 139 forskellige enheder (Motorola, Samsung, Wiko og så videre), der fungerer med 23 forskellige Android-versioner. For iOS er der 26 forskellige enheder (iPad 2, iPhone 8, iPod Touch 6th Gen osv.), Der fungerer med 26 forskellige iOS-versioner.

4. Gå tid! Gennemgå, kør og se resultaterne! Hver kørsel producerer en rapport med enhedslogfiler, testlogfiler, skærmbilleder, videoer med mere.

Pak ind

Device Farm er så hjælpsom. Vi kan nu kontinuerligt levere nye funktioner, forbedringer og fejlrettelser med et højt tillidsniveau. Vores udviklere udvikler nu nye funktioner og test dem med det samme.

Dette værktøj hjalp os også med vores support-sager. Som du måske ved, er det umuligt at have alle de forskellige enheder og forskellige OS-versioner. Med dette værktøj behøver vi ikke at miste en nattesøvn over dette; hvert år tilføjer AWS Device Farm nye enheder til deres service. Så hver gang vi modtager en support-sag for noget, der ikke fungerer som forventet på en Lava Iris-, Ulefone- eller Mlais-enhed, kan vi anmode om fjernadgang til Device Farm, og vi kan få adgang til og teste appen på enheden i realtid .

Jeg udfordrer dig til at prøve det, og nu er det op til dig! Dette er ikke så ligetil som lav-kode, men det er heller ikke så kompliceret som det kan se ud. Afkastet på din indsats vil være det værd. Og glem ikke, at vi brugte AWS Device Farm med Appium, men du kan bruge andre enhedsfarme. Som jeg nævnte tidligere, har du også alt forklaret her, her og her. Fortæl os, hvordan denne løsning fungerede for dig!