Gotta Test 'Em All: Kuinka testata OutSystems-mobiilisovelluksia

Jonkin aikaa sitten kirjoitin artikkelin, jossa keskustelin mobiilisovellusten testauksen keskeisestä roolista sovelluksen laadun parantamisessa sekä vaikutuksista käyttäjän omaksumiseen ja käyttäjien tyytyväisyyteen. Menin mobiilisovellusten testauksen monimutkaisuuden vuoksi valtavan määrän erilaisia ​​mobiililaitteita, käyttöjärjestelmäversioita ja verkkoolosuhteita vuoksi. Tänään haluan opastaa sinua testaamaan mobiilisovelluksia OutSystemsin ja AWS Device Farmin kanssa.

Muuttujien lukumäärä testattaessa OutSystems-mobiilisovelluksia, kuten mitä tahansa muuta mobiilitekniikkaa, on valtava, jopa pinnan tasolla. Tästä huolimatta sinun tulisi aina harkita syventämistä. Loppujen lopuksi virheellisesti toimiva sovellus vaatii vain asennuksen poistamista paikan päällä.

On vain niin paljon, mitä voit testata etsimättä pelättävää asiaa, joka voi tuhota täydellisesti rakennetun skenaarion: todellisen laitteen. Testaaminen oikeilla laitteilla on Pandoran laatikko logistisesti ja se häiritsee minkä tahansa matkaviestinnän kehittäjän unelmia. Ryhmäni ja minä olemme menettäneet melko paljon unta sen yli. Meidän piti löytää ratkaisu, tapa testata olematta haudattu matkapuhelinten vuoren alle.

Siellä on monia ratkaisuja, kuten Visual Studio App Center, Perfecto tai Saucelabs. Mutta Amazon Device Farm on osoittautunut antidoteksi painajaisillemme. Device Farm tarjoaa AWS-testauskehyksen, jonka avulla kehittäjät voivat ladata ja suorittaa testejä oikeilla Android- ja iOS-laitteilla AWS-pilvessä. Device Farm antaa sinun suorittaa automatisoituja testejä ja pitää etäkäyttöistuntoja tietyissä laitteissa omilla kokoonpanoillaan, mikä tarkoittaa, että ennen yhteyden muodostamista laitteen, voimme määrittää sen tilan.

AWS tarjoaa myös SDK: n, jota voidaan käyttää vuorovaikutuksessa kaikkien AWS-palveluiden kanssa. Tällä tavalla voimme yhdistää laitetilan (tai minkä tahansa muun palvelun) sisäisiin kojetauluihimme.

Lisäksi AWS on käynnistänyt yksityisten laitteiden suoran pääsyn laitteisiin. Tämän uuden ominaisuuden avulla kehittäjät voivat käyttää yksittäisiä laitteita yksityisessä testijoukossaan ikään kuin ne olisivat suoraan yhteydessä paikallisiin koneisiin USB: n kautta.

Device Farm tukee myös laajaa valikoimaa testausautomaatiokehyksiä, kuten Appium, Calabash, XCTest ja monet muut, joissa voit kirjoittaa omia testejä.

Joten joo, se on aika vaikuttava työkalu, varsinkin kun näet sen toimivan.

Käsien likaantuminen: Amazon Device Farm ja OutSystems

Joten, aion nyt käydä läpi AWS Device Farmin testataksesi OutSystems-sovelluksia. Jotta näemme sen toiminnassa, meidän on tietysti luotava testit ensin! Käytämme yksinkertaista OutSystems-sovellusta ja testaamme sisäänkirjautumissivua Android-laitteella. Katso testien asettamista koskevat tekniset yksityiskohdat näistä näytteistä GitHubissa; voit myös seurata muita testausohjeita.

1. Koneen asetukset

Asenna sinulle parhaiten sopiva automaatiotestausjärjestelmä. Tätä artikkelia varten pidämme kiinni Appiumista. Kuten Appium, jotkin puitteet tukevat useampaa kuin yhtä ohjelmointikieltä. Joten varmista, että olet asentanut kaiken. Valitsimme ohjelmointikieleksi Python.

2. Testaa asennus

Aloita luomalla testausprojekti. Ennen kuin lähetät kaikki testit laitetilalle, suosittelen ensin suorittamaan tarkat testit paikallisessa testiympäristössä. On helpompaa löytää ongelman perimmäinen syy paikallisesti. Se on myös halvempaa. Joten lisää testitiedostoosi seuraavat haluamasi ominaisuudet testiisi.

wanted_caps ['platformName'] = 'Android'
haluamasi kappaleet ['deviceName'] = 'aPhone'
haluamasi kapselit ['appPackage'] = ''
toivottu_kapselit ['appActivity'] = ".MainActivity"

3. Testisuunnittelu ja vaiheistus

Yleensä et luota testiä kaikelle. Ihannetapauksessa eristät jokaisen sovelluksen osan, jonka haluat testata. Joten ennen testin koodaamisen aloittamista sinun täytyy laatia suunnitelma. Istu alas, rentoudu ja kokeile sovellustasi etsimällä päätoimintoja, jotka haluat testata.

4. Testin luominen

Nyt kun sinulla on suunnitelma, olet valmis aloittamaan testien asettamisen. Aloitetaan luomalla testitiedosto testikansioon ja koodaamalla testitapaus. Kun koodaat testiä, etuliittele testimenetelmäsi sanalla ”testi”; tämä auttaa testikehystä tunnistamaan, mitä menetelmää testi sisältää.

Toteutamme vuorovaikutustestejä, joten kaikki on peräkkäistä. Ensin aloitamme testin. Seuraavaksi odotamme tapahtuman / kohteen näkymistä näytöllä. Kun odotettu näkyy näytöllä, napsautamme sitä ja odotamme sitten taas seuraavan ilmestymistä näytölle. Saat idean: aloita testi, odota, napsauta, odota. Joskus meidän on ehkä käytettävä nukkumisolosuhteita vain varmistaaksemme, että tietty tapahtuma tapahtuu tai tietty esine näkyy näytöllä; muuten emme ehkä huomaa sitä.

tuonti os
tuoda yksin
Appium-tuontisivustosta
alkaen selenium.webdriver.common.by tuonti
sivustosta selenium.webdriver.support.ui tuo WebDriverWait
sivustosta selenium.webdriver.support tuo odotetut ehdot EC: ksi
luokka TestClass (unittest.TestCase):
  
  def setUp (itse):
   self.driver = webdriver.Remote ('http://127.0.0.1:4723/wd/hub', {})
  def test_case (itse):
   ...
  def tearDown (itse):
   self.driver.quit ()
       
  jos __name__ == '__main__':
   unittest.main ()

Kuinka tiedän, että jotain on näytöllä? Kuinka napsauttaa sitä? Okei, tämä on hankala osa. Muistatko artikkelin, jonka kirjoitin alkuperäisten sovellusten rakentamisesta OutSystems MABS: n kanssa jonkin aikaa sitten? Jos kyllä, tiedät jo, että OutSystems-sovellukset ovat hybridiä. Tämä tarkoittaa, että jotkut muutokset, joita teemme OutSystems-sovelluksia luotaessa, yhdistetään HTML-muotoon. Joten jos määrität tietoominaisuuden aina tunnisteella, se auttaa tunnistamaan sovelluselementtejä testitapauksessa, ja elementin löytäminen on helpompaa XPATH: n avulla.

Ensimmäisessä tilanteessa, kuten seuraavista esimerkeistä käy ilmi, yritämme löytää kuvan. Lisäsimme attribuutin, jolla on arvo, joka kuvaa kuvaa (tässä tapauksessa se on SuccessImg), ja etsimme sitä XPATH: lla (// img [@ data-test-id = ”SuccessImg”]). Kun käsittelemme luetteloa, meidän on oltava erityisen varovaisia. Jos haluat löytää tietyn elementin luettelosta, esimerkiksi kolmannen, meidän on varmistettava, että meillä on arvon indeksi. Täältä meidän on etsittävä määrite “data-test-id”, jonka arvo on “MyAttrId-2”.

Tiedän tiedän; on joitain erityisiä tilanteita, joissa emme voi testata tiettyä OutSystems-mobiilisovelluksemme toimintoa Chrome-selaimella. Suurin osa näistä tapauksista tapahtuu, koska siellä on suora riippuvuus jostakin natiivista laajennuksesta, joka on asennettava sovellukseen. Tätä erityistä tilannetta varten meidän on kytkettävä mobiililaitteemme tietokoneeseemme, avattava Chrome ja kirjoitettava chrome: // inspect / # devices URL-osoitteeseen. Tämä avaa sivun, joka näyttää kaikki tietokoneeseen kytketyt laitteet.

Nyt tarkista laitteesi ja ala tutkia HTML-koodiasi. Etsi painikkeita, ankkureita tai linkkejä, jotka tarvitset navigoidaksesi sovelluksessa. Hyvä tapa tunnistaa sovelluspainikkeesi on käyttää HTML-tunnuskenttää, mutta jos jostain syystä kyseisellä painikkeella ei ole tunnusta, voit käyttää sen sijaan XPATH: ta.

Älä unohda: iOS-laitteita voidaan tarkastaa vain käyttämällä Safaria Macissa ja ottamalla käyttöön laitteen web-tarkastaja. Sekä tietokoneet että Mac-tietokoneet voivat tarkistaa Androidin käyttämällä Chromea ja mahdollistamalla laitteen kehittäjätyökalujen käyttö.

5. Testaa niputtaminen

Olemme luoneet testin, ja nyt olemme valmiit lähettämään sen Amazon Device Farm -tilalle. Kuinka voimme tehdä tämän? Se on suoraviivaista: komennon suorittaminen voi luoda ZIP-tiedoston, joka sisältää testipaketin. Tämä testipaketti on tärkeä, koska se sisältää testin ja kirjastot, jotka AWS Device Farm suorittaa. Testien lähettäminen:

1. Luo AWS-konsolissa projekti, jossa suoritat testit ja uusi ajo. Ajo edustaa tiettyä sovellusta, jolla on tietty testijoukko tietyllä laitejoukolla. Pohjatyöt on tehty.

2. Tämän jälkeen sinun tulee ladata sovelluspaketti ja testisi. Jos sinulla ei ole, AWS on peittänyt sinut kahdella sisäänrakennetulla testillä. Tässä esimerkissä käytämme omaa.

3. Nyt hauska alkaa: valitse testattavat laitteet ja määritä laitteen tila (WiFi, NFC, GPS, Bluetooth). Tällä hetkellä AWS Device Farmissä on 178 Android- ja 162 iOS-laitetta. Androidille on 139 erillistä laitetta (Motorola, Samsung, Wiko ja niin edelleen), jotka toimivat 23 eri Android-version kanssa. IOS: ssä on 26 erillistä laitetta (iPad 2, iPhone 8, iPod Touch 6th Gen ja niin edelleen), jotka toimivat 26 eri iOS-version kanssa.

4. Mene aika! Tarkista, suorita ja katsele tuloksia! Jokainen ajo tuottaa raportin, joka sisältää laitelokit, testilokit, kuvakaappaukset, videot ja paljon muuta.

Paketoida

Device Farm on niin hyödyllinen. Voimme nyt toimittaa jatkuvasti uusia ominaisuuksia, parannuksia ja virhekorjauksia korkealla luotettavuustasolla. Kehittäjämme kehittävät nyt uusia ominaisuuksia ja testaavat niitä heti.

Tämä työkalu auttoi meitä myös tukitapauksissa. Kuten ehkä tiedät, kaikkien erilaisten laitteiden ja eri käyttöjärjestelmän versioiden käyttäminen on mahdotonta. Tämän työkalun avulla meidän ei tarvitse hävittää yön yli tätä; Joka vuosi AWS Device Farm lisää uusia laitteita palveluunsa. Joten joka kerta, kun saamme tukitapauksen jostakin, joka ei toimi odotetulla tavalla Lava Iris-, Ulefone- tai Mlais-laitteella, voimme pyytää etäkäyttöä Device Farmille, ja voimme käyttää ja testata laitteen sovelluksen reaaliajassa .

Haastan sinua kokeilemaan sitä, ja nyt se on sinun tehtäväsi! Tämä ei ole yhtä suoraviivainen kuin matala koodi, mutta se ei ole myöskään niin monimutkainen kuin miltä näyttää. Ponnisteluidesi tuotto on sen arvoista. Ja älä unohda, että käytimme AWS-laitetilaa Appiumin kanssa, mutta voit käyttää muita laitetiloja. Lisäksi, kuten aiemmin mainitsin, sinulla on kaikki selitetty täällä, täällä ja täällä. Kerro meille, kuinka tämä ratkaisu toimi sinulle!