Ihmisen keskimääräinen keskittymiskyky on alle 9 sekuntia! Oletko koskaan miettinyt, miksi? Useimmat viime aikoina ilmestyneet mobiilisovellukset edellyttävät, että vierität syötettä alaspäin, jolloin aivot on hienosäädetty olemaan katsomatta mitään muutamaa sekuntia pidempään. Tämä on johtanut keskivertokäyttäjän keskittymiskyvyn merkittävään lyhenemiseen.
Sovelluskaupassa saatavilla olevien mobiilisovellusten runsauden myötä mobiilisovellusten testauksesta ja regressiotestaustoimien skaalaamisesta on tullut suuri vastuu. Tässä mobiilitestaustyökalut ovat hyödyksi.
Olen kuulunut mobiilitestauskehysten varhaisiin omaksujiin, ja kokemukseni mukaan automaatioon, laitemuotoihin ja suorituskykytestaukseen keskittyminen on ollut yhtä tärkeässä roolissa mobiilimaailman skaalaamisessa ja vaikutuksen lisäämisessä. Tässä artikkelissa jaan tehokkaimmat tekniikat mobiilisovellustestien automatisointiin.
Mobiilisovellusten testaus: huomioon otettavat osa-alueet
Testauksella millä tahansa tietyllä alustalla on omat haasteensa, mutta mobiililaitteissa on lisäksi huomioitava seuraavat parametrit. Teitpä manuaalista testausta tai testiautomaatiota, testitapausten on toiminnallisen testauksen lisäksi keskityttävä seuraaviin:
Yhteydet
On tärkeää selvittää, mitä tapahtuu, jos käyttäjä käyttää mobiililaitettaan lentotilassa tai offline-tilassa, mitä tapahtuu kaistanleveyden vaihdellessa ja niin edelleen, jotta sovellus toimii.
Have an account? Log In
Sijainti
Erityisesti GPS:stä tai sijaintiin perustuvista palveluista riippuvien mobiilisovellusten testaus on suoritettava simuloimalla sijaintia MobileSpyn, Location Spooferin ja muiden vastaavien työkalujen avulla. Muuten testaaminen olisi vaikeaa – esimerkiksi jos haluat simuloida kyytipalvelusovelluksen testiskenaarion, jossa joku pyytää kyytiä New Yorkista ja taustajärjestelmän mikropalveluihin on tehty muutoksia, jotka liittyvät kuljettajan löytämiseen kyseisestä sijainnista. Ilman simulointia testit eivät antaisi tarkkoja tuloksia.
Käyttöjärjestelmä
Erityisesti markkinoilla nykyään olevien Android-puhelinten määrän vuoksi testaaminen kaikilla saatavilla olevilla käyttöjärjestelmäversioilla on lähes mahdotonta – miten siis priorisoit? iOS:n kohdalla Apple tuo lisähaasteita, jotka liittyvät käyttöjärjestelmäversioiden muutoksiin yhdistettyihin Xcode-versioihin.
Nykyään yritykset turvautuvat kolmannen osapuolen palveluntarjoajiin, kuten BrowserStackiin, jotka tarjoavat simulaattoreita/emulaattoreita eri käyttöjärjestelmille, laitetestausta ja eri selainten välistä testausta.
Käyttöliittymän kuvakkeet vaihtelevat käyttöjärjestelmien välillä: Windowsissa, iOS:ssä ja Androidissa. Testiautomaation yhteydessä useimmat meistä päätyvät käyttämään simulaattoreita – Android-simulaattorien lataaminen kestää huomattavasti kauemmin, kun taas iOS-laitteet ovat nopeampia.
Erilaiset mobiililaitteiden näppäinyhdistelmät, joita käytetään eri käyttöjärjestelmätyypeissä näyttökuvien ottamiseen ongelmien virheenkorjausta varten, ovat kriittinen tieto kaikille, jotka testaavat mobiilisovelluksia.
Laitemuoto
Mobiilisovelluksia kehitettäessä on eri käyttöjärjestelmäversioiden lisäksi huomioitava viisi pääasiallista laitemuotoa sekä pysty- tai vaakasuunta jokaisessa näistä laitetyypeistä:
| Laite | Näytön koko |
| Pienet mobiililaitteet | 3,5 tuumaa tai pienempi |
| Keskikokoiset mobiililaitteet | 3,5–5 tuumaa |
| Tabletit | 5–7 tuumaa |
| Pienet tabletit | 7–8,5 tuumaa |
| Täysikokoiset tabletit | 8,5 tuumaa tai suurempi |
Kuinka valita oikea kehys mobiiliautomaatiota varten
Laitemuotojen huomioiminen mobiilisovelluksia rakennettaessa tarkoittaa sen varmistamista, että sama sovellus toimii responsiivisesti eri mobiililaitteissa ja käyttöjärjestelmätyypeissä. Kun sovellusta käytetään maailmanlaajuisesti ja yritykset haluavat kasvattaa käyttäjäkuntaansa, niiden on tehtävä tämä päätös joko varhaisessa vaiheessa kehitysprosessia ja turvauduttava React Native -kehyksiin natiivin Android- tai iOS-kehityksen sijaan.
Muussa tapauksessa yritykset käyttävät myöhemmin aikaa ja vaivaa sovellusten uudelleenrakentamiseen ja uudelleensuunnitteluun vaihtaakseen React Native -kehyksiin. Tämä vaikuttaa suoraan tarvittavien tiimien määrään ja ylläpidon työmäärään, sillä React Native -kehykset tukevat sekä iOS- että Android-sovellusten kehittämistä.
Kun mobiilisovellukset kehitetään React Native -kehyksillä, se vähentää myös testiautomaation taakkaa, koska sinun tarvitsee ylläpitää vain yhtä testiautomaatiokehystä sekä iOS:lle että Androidille.
Mobiilisovelluksia voidaan kehittää eri tavoin. Jotkin yritykset turvautuvat natiivien ohjelmointikielten, kuten Javan ja Objective C:n, käyttöön Android- ja iOS-sovelluksissa. Natiivikielten käytön etuna on, että niiden avulla sovelluksiin voidaan tarjota monipuoliset toiminnot.
Toisaalta elementtien tunnisteet ovat eri alustoilla erilaiset, mikä tarkoittaa, että saman asian testaamiseen tarvitaan erilliset natiivien testikehykset, kuten Espresso Androidille ja XCUITest iOS:lle.
React Native on toinen yleisesti käytetty ohjelmointikieli responsiivisten mobiilisovellusten kehittämiseen, ja Facebook julkaisi sen avoimen lähdekoodin projektina. Tavoitteena oli yhdistää mobiilikehitystyö molemmilla alustoilla, jotta käytössä voisi olla yksi tiimi ja molempien sovellusten elementtien tunnisteet olisivat samat. Tällöin mobiilisovellusten testaamiseen tarvitaan vain yksi testikehys, kuten Appium.
Kun mobiilisovellusten testejä automatisoidaan, oikeiden laadunvarmistuksen automaatiotyökalujen valinnalla voi olla merkittävä vaikutus testauksen tehokkuuteen.
Kuinka iOS-mobiilisovellusten testaus automatisoidaan
Manuaalisessa testauksessa on noudatettava useita kriteerejä: useimmat iOS-sovelluksia kehittävät yritykset määrittelevät selkeästi tuetut käyttöjärjestelmät ja SDK-versiot. Tämä auttaa rajaamaan testaukseen tarvittavia resursseja.
Ohjelmistotestauksen laajentamiseksi meidän on investoitava automaatioon. Monet suositut kehykset tukevat iOS-mobiilisovellusten automatisoitua testausta. Rajataan keskustelumme seuraaviin kahteen automaatiotyökaluun:
- XCUITest
- Appium
| XCUITest | Appium |
| Natiivisovellusten kehys, joka voi sijaita iOS:n lähdekoodikannassa. | Erillinen testikehys, joka on rakennettu lähdekoodikannan ulkopuolelle. |
| Kirjoitettu Objective C:llä tai Swiftillä | Kirjoitettu Javalla, Pythonilla ja niin edelleen |
| Eksplisiittiset odotukset, jotka soveltavat ehtoa. | Implisiittiset odotukset, joissa käytetään sleep()-funktiota, mikä tekee testeistä epävakaita. |
| Taustajärjestelmän ohjelmointirajapinnan vastausten jäljittely avoimen lähdekoodin kirjastoilla, kuten Mockingjaylla | Tukee valetestauspalvelimen käyttöä. |
| Koska kyseessä on natiivisovellusten kehys, sitä voidaan käyttää vain iOS-sovellusten testaamiseen. | Koska testit sijaitsevat lähdekoodikannan ulkopuolella ja ne voidaan kirjoittaa esimerkiksi Javalla tai Pythonilla, sitä voidaan käyttää alustojen välisten sovellusten, kuten Windows-, iOS- ja Android-sovellusten, testaamiseen, kunhan elementtien tunnisteet ovat samat molemmilla alustoilla. |
Olen hyödyntänyt valetestauspalvelimia taustajärjestelmän kutsujen jäljittelyyn ja käyttöliittymän yksinomaiseen testaamiseen luomalla perusluokan seuraavasti:
Kun perusluokka on valmis, lisään varsinaisen testin hyödyntämällä sivuobjektisuunnittelumallia seuraavasti:
Kuinka Android-mobiilisovellusten testaus automatisoidaan
Maailmassa on yli 2 miljardia aktiivista Android-laitetta. Android-sovelluksen testaaminen eri laite- ja käyttöjärjestelmätyypeillä on lähes mahdotonta! Siksi yritykset ilmoittavat tarkasti tukemansa versiot. Tämä varmistaa myös paremman käyttökokemuksen.
Androidin automaatiokehykset, kuten Robotium ja Selendroid, auttavat ehdottomasti nopeuttamaan testausprosesseja. Keskitytään keskustelumme osalta seuraaviin automaatiotyökaluihin: Espressoon ja Appiumiin:
| Espresso | Appium |
| Natiivi testikehys, joka voi sijaita Androidin lähdekoodikannassa. | Erillinen testikehys, joka on rakennettu lähdekoodikannan ulkopuolelle. |
| Kirjoitettu Javalla ja Kotlinilla | Kirjoitettu Javalla, Pythonilla jne. |
| Eksplisiittiset odotukset, asynkronisia toimintoja tuetaan joutoresurssiominaisuuden avulla | Implisiittiset odotukset, joissa käytetään sleep()-funktiota, mikä tekee testeistä epävakaita. |
| Taustajärjestelmän vastausten simulointi avoimen lähdekoodin kirjastoilla, kuten Mockitolla ja Retrofit-rakentajalla | Tukee simuloidun palvelimen käyttöä. |
| Koska kyseessä on natiivi testikehys, sitä voidaan käyttää vain Android-sovellusten testaamiseen. | Koska testit sijaitsevat lähdekoodikannan ulkopuolella ja ne voidaan kirjoittaa esimerkiksi Javalla tai Pythonilla, sitä voidaan käyttää eri alustojen sovellusten testaamiseen sekä iOS- että Android-sovelluksissa, kunhan elementtien tunnisteet ovat samat molemmilla alustoilla. |
Yksi natiivien sovelluskehysten käytön eduista on mahdollisuus käyttää simuloituja palvelimia taustajärjestelmän API-kutsujen simulointiin ja siten käyttöliittymän testaamiseen erikseen. Tässä on esimerkki koodikatkelmasta siitä, miten olen toteuttanut tämän:
Sen mukaan, miten mikropalveluarkkitehtuurisi on kehitetty, voit joko hakea vastauksen selaimesi verkkovälilehdeltä tai suoraan kehittäjiltä ja viitata siihen testissäsi seuraavasti:
Kuten yllä olevasta esimerkistä näet, HomeTabPage-kutsua käytetään testissä sen sijaan, että jokainen elementti pitäisi tarkistaa erikseen. Olen hyödyntänyt testikehyksessä sivuobjektimallia seuraavasti:
More Articles
Mobiilisovellusten testaustyökalut
Alalla on useita testaustyökaluja, ja valinta riippuu monista tekijöistä:
- Tiimin osaaminen
- Automaation tarkoitus
- Automaation kohderyhmä: tuotejohtajat/myynti/insinöörit/testaajat
- Testikehyksen ja natiivin lähdekoodin yhteensopivuus
- Hybridisovellusten määrä
Alalla yleisesti käytettyjä työkaluja ovat muun muassa:
- Selendroid
- Robotium
- Appium
- Testdroid
- UiAutomator
Etkö halua tehdä testausta itse yrityksesi sisällä? Voit myös palkata mobiilisovellusten testauspalveluita tekemään sen puolestasi.
Mobiilisovellusten suorituskyvyn testaus
Mobiilisovelluksia testattaessa meidän tulisi testauksen skaalaamiseen keskittymisen lisäksi priorisoida myös suorituskyvyn testaus, koska sillä on ratkaiseva merkitys määritettäessä, jatkaako käyttäjä sovelluksemme käyttöä.
Jos näytön latautuminen kestää yli 2 sekuntia, ihmiset tulevat levottomiksi – tämä liittyy tarkkaavaisuutemme kestoa koskevaan tutkimukseen. Käyttäjien säilyttämiseksi meidän on siksi panostettava suorituskyvyn testaukseen.
Sovelluksen suorituskykyä testattaessa meidän on tunnistettava KPI-mittarit ja verrattava tuloksia niihin:
- Vasteajan enimmäisarvo
- Keskimääräinen vasteaika
- Keskimääräinen läpimenonopeus
- Aktiivisten käyttäjien huippumäärä kullekin käyttöjärjestelmälle ja laitteelle
Mobiilisovellusten testaustyökalun käyttö voi yksinkertaistaa suorituskyvyn testausta. Esimerkiksi Apptim voi seurata loppukäyttäjien suorituskykymittareita – se tarjoaa kattavat suorituskykyraportit kaikista keskeisistä suorituskykyparametreista.
Matkapuhelinsovelluksen suorituskyvyn valvontaan voimme käyttää Firebase Performance -suorituskyvyn valvontaa, joka tarjoaa hallinnan suorituskykytietoihin jakamalla tietoja siitä, miten sovelluksesi toimii. Jäljitys- ja verkkotiedot voidaan eritellä ulottuvuuksiin, kuten sovellusversioon, maahan, laitteeseen ja verkkotyyppiin.
On olemassa myös muita työkaluja, kuten Appium Studio, Sauce Labs, Testdroid ja niin edelleen, jotka tarjoavat vastaavia suorituskyvyn valvontaominaisuuksia.
Toivottavasti tämä artikkeli antoi sinulle johdannon matkapuhelinsovellusten testaukseen ja siihen liittyviin kriittisiin tekijöihin!
Lisää parhaita käytäntöjä ja vinkkejä kehitysprosessisi muotoiluun saat tilaamalla The QA Lead -uutiskirjeen.
Aiheeseen liittyvää:
Katso myös:
- MIKÄ ON TESTGEAR? OMINAISUUKSIEN YLEISKATSAUS & ESITTELY
- PALVELIMEN VALVONTAMITTARIT, JOITA SEURATA JÄRJESTELMÄN TERVEYDEN JA SUORITUSKYVYN VUOKSI
Aiheeseen liittyvä työkaluluettelo:
