Vadnica za testiranje mobilnega uporabniškega vmesnika (testiranje uporabniškega vmesnika za iOS in Android)

mobile ui testing tutorial gui testing ios

Vodič za testiranje uporabniškega vmesnika za mobilne aplikacije: Naučite se izvajati preskušanje uporabniškega vmesnika za iOS in Android

Z cvetočim trgom mobilnih telefonov je testiranje mobilnih aplikacij postajalo iz dneva v dan vznemirljivo.

kako napisati testne primere v

Z izvajanjem funkcionalnih testov v mobilni aplikaciji se ne morete odjaviti iz aplikacije. Obstaja malo drugih vrst preskušanja, kot so terensko testiranje, testiranje omrežja, testiranje uporabniškega vmesnika, življenjska doba baterije itd., Ki jih je treba opraviti.

Testiranje uporabniškega vmesnika je eden pomembnih testov pri testiranju mobilnih aplikacij in ga ne smemo jemati zlahka.

Grafični uporabniški vmesnik ustvarja veliko razlike v tem, kako zanimiv in interaktiven uporabnik najde vašo aplikacijo. Pomembnost dostojnega in privlačnega grafičnega uporabniškega vmesnika je mogoče občutneje občutiti v okolju pametnih naprav, kjer je velikost zaslona veliko manjša kot pri prenosnem ali namiznem zaslonu.

Kaj se boste naučili:

• Pomembnost testiranja uporabniškega vmesnika za mobilne aplikacije
• Kako se odločiti, koliko preizkušanja uporabniškega vmesnika je potrebno?
• Smernice: Kaj preizkusiti pri testiranju uporabniškega vmesnika za mobilne aplikacije
  • # 1) Ločljivost zaslona
  • # 2) Velikost zaslona
  • # 3) Različni elementi uporabniškega vmesnika
  • # 4) Slog: barvna in tematska shema naprave
  • # 5) Multi-touch ali One Touch
  • # 6) Dolg ali kratek pritisk
  • # 7) Lokacija
• Kako preizkusiti različice uporabniškega vmesnika v različnih različicah OS?
• Resnične naprave ali emulatorji: Kaj izbrati za testiranje uporabniškega vmesnika?
  • Prednosti
  • Slabosti
• Ročno ali avtomatizirano testiranje uporabniškega vmesnika?
• Orodja za testiranje uporabniškega vmesnika za mobilne aplikacije
• Kontrolni seznam za testiranje uporabniškega vmesnika za mobilne aplikacije
• 5 mitov o avtomatiziranem testiranju uporabniškega vmesnika
  • Mit 1: Hitrost
  • Mit 2: Pokritost
  • Mit 3: Stroški
  • Mit 4: Doslednost
  • 5. mit: Nenaklonjenost
• Mit in resničnost
• Zaključek
• Priporočeno branje

Pomembnost testiranja uporabniškega vmesnika za mobilne aplikacije

Se boste kot uporabnik počutili, kot da uporabljate aplikacijo, ki nima uporabniške interakcije in otežuje razumevanje, kako jo uporabljati?

Ko uporabniki prvič uporabljajo mobilno aplikacijo, pozornost ne krade le zmogljivost, temveč tudi privlačen uporabniški vmesnik. UI prijazna aplikacija proda več v primerjavi z aplikacijo, ki je najbolje razvita, a z neprijetnim uporabniškim vmesnikom.

Če ima aplikacija na eni napravi popoln in čudovit uporabniški vmesnik, na drugi pa je popolnoma zvita samo zato, ker ima drugačno velikost ali drugačen OS, potem bo pustila zelo slab vtis. Komercialni uspeh aplikacije bo močno ogrožen.

Ali boste promovirali aplikacijo, pri kateri je gumb premajhen, da bi lahko blokiral celoten nabor funkcij?

Ali niso to neprijetne izkušnje za uporabnike? Zaradi zgoraj omenjenih primerov postane zelo pomembno preizkusiti uporabniški vmesnik aplikacije. Dve glavni verifikaciji, ki jo je treba opraviti za mobilne aplikacije, je prijaznost do uporabnika in videz v različnih modelih in različicah OS.

Sledi primer, kako naj bo uporabniški vmesnik popoln za različne velikosti zaslona:

Kako se odločiti, koliko preizkušanja uporabniškega vmesnika je potrebno?

Naslednji grafikon označuje različne vertikale, v katere je mogoče razvrstiti mobilne aplikacije:

(slika vir )

Iz zgornjega grafikona lahko razberete, da aplikacije za igre na srečo zavzemajo večino tržnega deleža, ki znaša približno 24,43%, nato pa sledijo poslovne in izobraževalne aplikacije.

• Aplikacije, razvite kot igralne, potrebujejo temeljito preizkušanje v vseh pogledih, saj uporabniški vmesnik največ prispeva k uspehu, ne glede na to, ali gre za izvorno ali hibridno aplikacijo.
• Poslovna aplikacija se za svoj uspeh morda ne bo popolnoma zanašala na uporabniški vmesnik, ker je v večini primerov ciljna skupina usposobljena za uporabo aplikacije. Zato imajo take aplikacije lahko preprost uporabniški vmesnik.
• Aplikacije, razvite za izobraževalne namene, potrebujejo temeljito testiranje uporabniškega vmesnika.
• Komercialne aplikacije, kot so nakupovanje, potovanja itd., Prav tako potrebujejo popolno testiranje uporabniškega vmesnika v različnih napravah in različnih različicah OS.

Skratka, glede na namen aplikacije je mogoče določiti globino testiranja uporabniškega vmesnika, vendar je treba testiranje uporabniškega vmesnika vedno opraviti na vsaj 3 različnih različicah OS.

Smernice: Kaj preizkusiti pri testiranju uporabniškega vmesnika za mobilne aplikacije

Med testiranjem uporabniškega vmesnika v mobilni aplikaciji je treba preveriti različne značilnosti.

Sledi nekaj značilnosti, ki jih je treba preizkusiti za vsako aplikacijo:

# 1) Ločljivost zaslona

Sledi nekaj pogostih ločljivosti zaslona, ​​ki jih upoštevamo pri ustvarjanju preizkusnih plošč:

• 640 × 480
• 800 × 600
• 1024 × 768
• 1280 × 800
• 1366 × 768
• 1400 × 900
• 1680 × 1050

Vse te ločljivosti je treba preskusiti, če imate v aplikaciji postavitev z več stolpci.

Zato je treba preverjanje opraviti od najmanjše do največje ločljivosti. Poleg tega, če ima vaša aplikacija dolg seznam kartic z informacijami, jih je treba zaviti tudi v drugačni ločljivosti.

( vir slike )

# 2) Velikost zaslona

Obstaja preveč različic velikosti zaslona in razpoložljivih ločljivosti. Še posebej v pametnih napravah velikosti kontrolnikov niso statične, temveč so odvisne od razpoložljive velikosti zaslona.

Med preskušanjem poskrbite, da bo velikost kontrolnikov videti estetsko dobro in da bo nadzor popolnoma viden na zaslonu brez drsenja. Preizkusite GUI na različnih napravah z različnimi velikostmi in ločljivostmi zaslona.

V ta namen so primerni emulatorji, vendar se nič ne ujema z resnično napravo. Prepričajte se, da preizkusite vsaj dve ali tri prave naprave. Ne pozabite preizkusiti tudi ležeče in pokončne usmerjenosti, če jo naprava podpira.

Aplikacijo morate preizkusiti v pogostih ločljivostih, da zagotovite njeno uporabnost.

Tu morate razumeti nekaj stvari:

Razlika med velikostjo zaslona in ločljivostjo: Velikost zaslona je dolžina zaslona v palcih, merjena diagonalno ali od enega kota do drugega kota zaslona. Ločljivost zaslona je širina in višina, Primer 640w × 480h, ki predstavlja število slikovnih pik po zaslonu, pomnoženo z več slikovnimi pikami, ki se spuščajo.

# 3) Različni elementi uporabniškega vmesnika

Elementi uporabniškega vmesnika, kot so gumbi, naslovi, ikone, slike, izbirna polja, besedilna polja, potrditvena polja itd., So nekateri izmed različnih elementov, ki jih je treba preveriti glede njihovega videza in velikosti na zaslonu.

Natančneje za besedilna polja, če je v besedilnem polju prikazana mehka tipkovnica, jo je treba preizkusiti in preveriti.

Najpomembnejše je temeljito testiranje velikosti gumbov, ker se spomnim, da smo v naši aplikaciji med testiranjem na telefonu Galaxy S našli blokator, kjer je gumb blokiral celotno aplikacijo, samo zato, ker je bil gumb videti premajhen, da bi ga lahko kliknili.

Položaj elementov uporabniškega vmesnika je treba preveriti tudi glede na zahtevo, tj. Če naj bodo vsi poravnani na sredino ali levo itd.

# 4) Slog: barvna in tematska shema naprave

Uporabniški vmesnik in barvna shema aplikacije morata biti skladna z različnimi barvnimi in tematskimi shemami telefona. Barva in tema telefona Samsung se zelo razlikujeta od barve Nokia ali telefona MI .

Zato morate preveriti, ali je aplikacija na takšnih telefonih videti skladna.

Vaša aplikacija ima poseben dizajn. In slog kontrolnikov se mora ujemati s to zasnovo. Morda ste že videli veliko aplikacij, kjer so nekatere kontrole npr. plošče imajo okrogle robove in druge kontrole npr. polja z besedilom imajo ostre robove.

Čeprav tovrstne težave ne vplivajo na uporabnost ali funkcionalnost aplikacije, še vedno dosleden videz aplikacije pomaga vzpostaviti prijateljski odnos med aplikacijo in uporabnikom.

Ena najpomembnejših stvari v slogu je pisava različnih strani. Pisavo je treba dobro preizkusiti, da se izognete neskladju v videzu in občutku aplikacije.

Največkrat se osredotočimo na besedilo, ki je vidno v običajnih situacijah, in ignoriramo besedilo, ki se pojavi v določenih situacijah. Sporočila o uspehu in neuspehu so primer take vrste besedila.

Drug dejavnik, ki je v slogu pomemben, je razmerje med barvo pisave in situacijo, v kateri je besedilo prikazano.

Na primer, Rdeča barva se uporablja za sporočila o napakah, zelena za uspeh, rumena za opozorila in modra za hiperpovezave.

# 5) Multi-touch ali One Touch

Če vaša aplikacija podpira funkcijo več dotikov, kot je stiskanje za povečavo ali stiskanje za krčenje itd., Morate to funkcijo temeljito preizkusiti in za to ustvariti veliko testnih primerov za vse ustrezne zaslone.

# 6) Dolg ali kratek pritisk

Dolg pritisk na ikono prikaže kontekstni meni, medtem ko kratek dotik izvede prvo dejanje v meniju. Če je ta funkcija na voljo v vaši aplikaciji, morate preveriti to funkcionalnost in vse funkcije okoli nje.

# 7) Lokacija

Lokacija in položaj sta dve besedi, ki se uporabljata alternativno in, zanimivo, se uporabljata tudi za prenos dveh različnih konceptov, ki sta pojasnjena spodaj:

1) Včasih se na zaslonu prikaže kontrolnik.

Na primer, Glava se nahaja na vrh strani, Oznake so Levo poravnano , Besedila pa so Desno poravnano, itd. Tu so 'zgoraj', 'levo poravnano' in 'desno poravnano' relativni položaji kontrolnikov.

2) Včasih je vrstni red nadzora med drugimi kontrolami.

Na primer, med pridobivanjem osebnih podatkov je Ime sledila s priimkom. Ali pa mora biti oblika kontrolnikov, ki zahtevajo naslov v ZDA naročilo - ZIP, mesto, država.

V obeh primerih govorimo o lokaciji kontrol.

Med preskušanjem lokacije in položaja upravljalnih elementov poskrbite, da je vse logično postavljeno na zaslon in kaže dober estetski občutek.

V nekaterih primerih se en ali več kontrolnikov prikaže na več zaslonih. V tem primeru se prepričajte, da so prikazani na istem mestu in v enakem relativnem vrstnem redu na vseh straneh.

Kako preizkusiti različice uporabniškega vmesnika v različnih različicah OS?

Uporabniški vmesnik se razlikuje glede na različico operacijskega sistema, z uvedbo nove različice pa se uporabniški vmesnik izboljša.

Oglejmo si uporabniški vmesnik 3 najnovejših OS, ki je trenutno na voljo, in razumemo, kako te spremembe vplivajo na mobilno aplikacijo.

To so:

1. Lizika
2. Marshmallow
3. Nougat

Če pogledamo zgornji seznam novih funkcij uporabniškega vmesnika ali funkcionalnosti, kot QA morate okoli tega oblikovati testne primere.

1) lizika:

• Ustvarite testne primere za učinek novega dizajna na vašo aplikacijo.
• Ni nujno za vse zaslone, vendar ustvarite testne primere za dostop do novih bližnjic v vaši aplikaciji.

2) Marshmallow:

• Če se vaša aplikacija ukvarja z emojiji, ustvarite testne primere, da preverite nove emojije. Aplikacije, ki uporabnikom omogočajo pisanje mnenj ali klepet, pogosto uporabljajo emojije.
• Ko je vaša aplikacija prvič objavljena in nameščena, bo morda moral zaprositi za dovoljenje, zato je treba opraviti preizkus uporabniškega vmesnika novega zaslona z dovoljenji. In ustvarite testne primere za iste.
• Če vaša aplikacija uporablja Asistenta Google, morate ustvariti testne primere, da preizkusite uporabniški vmesnik posodobljene funkcije Asistenta Google.

3) Nougat:

najboljši nadzornik temperature CPU in GPU

• Za resnični način sanjarjenja je treba opraviti temeljito testiranje aplikacije in tako ustrezno ustvariti testne primere.
• Ustvarite testne primere, da preverite možnosti menija za svojo aplikacijo.
• Če se vaša aplikacija ukvarja z emojiji in GIF-ji, ustvarite testne primere, da preverite nove emojije in možnost pošiljanja GIF-jev.

Resnične naprave ali emulatorji: Kaj izbrati za testiranje uporabniškega vmesnika?

Ko boste morali preizkusiti mobilno aplikacijo, boste morda pomislili, kakšna naj bo preizkusna postaja?

Ali preizkusiti na pravi napravi ali emulatorju ali obojem? Na to ni nobenega trdnega odgovora, ker je izbira odvisna od tega, kaj želite preizkusiti.

Za preizkušanje funkcionalnosti, zmogljivosti, odziva omrežja, preskusa na terenu itd. Bi morali vedno dati prednost pravi napravi. Toda za stvari, kot je uporabniški vmesnik, izberite emulatorje skupaj z nekaterimi resničnimi napravami.

Prednosti

Prednosti uporabe emulatorjev za testiranje uporabniškega vmesnika so:

1) Praktično ni mogoče zbrati naprav vseh ločljivosti, kar bi stalo tudi ogromno denarja. Toda emulatorji nič ne stanejo.
2) Z emulatorjem lahko ustvarite vse ločljivosti zaslona in kombinacije OS.
3) Če imate samo en nabor resničnih naprav, vendar je ekipa za preverjanje kakovosti več kot ena oseba, potem vsi nadzorniki kakovosti ne morejo vzporedno testirati iste preizkusne točke. Z emulatorjem lahko vsak QA na svojem računalniku ustvari isto kombinacijo in vzporedno preskusi.
4) Testiranje na emulatorju je manj zamudno in hitrejše v primerjavi z resnično napravo.
5) Pogoste napake, povezane z uporabniškim vmesnikom, kot je poravnava itd., Je mogoče enostavno ujeti na emulatorjih.

Slabosti

Slabosti vključujejo:

1) Gesta ni mogoče preizkusiti na emulatorjih. Naenkrat je mogoče posnemati samo eno gesto.
2) Fizičnih vhodov GPS, padajočega ali šibkega omrežja itd. Tudi ni mogoče preizkusiti.
3) Nikakor ne morete ustvariti emulatorja za telefone Sony, LG, Nexus itd.
4) Na emulatorju ni mogoče ustvariti resničnega okolja z nizko baterijo ali pomanjkanjem pomnilnika itd.

Odločitev je torej treba sprejeti glede na vašo aplikacijo in zahteve po testiranju.

Ročno ali avtomatizirano testiranje uporabniškega vmesnika?

Nobenega izdelka, ne glede na to, ali gre za namizno ali spletno ali mobilno aplikacijo, ni mogoče izdati brez testiranja. Kot QA se trudimo najti in prijaviti vsako napako, vendar vseeno o njih poročajo stranke.

Ali veš zakaj?

Ker dolgotrajni testi, ki se jim pogosto izognemo ali jih zamudimo, tako puščajo neodkrite napake. Tudi 100% pokritost, poglobljena izvedba pri ročnem testiranju ni mogoča.

Testiranje uporabniškega vmesnika je precej preprosto in enostavno in samo pogledati morate, kako je videti na vaše oko. Če je to narejeno ročno, je zelo zamudno. Tudi večina primerov, ko moramo za testiranje uporabniškega vmesnika ustvariti ogromne podatke, kot je drsnik, se prikaže le, če vrstice kart prečkajo določeno število.

Ustvarjanje velikih podatkov je zelo dolgotrajno. Če imate avtomatizirano zbirko, lahko rešite obe težavi.

Nasprotno, če se funkcionalnosti ali uporabniški vmesnik aplikacije še vedno spreminjajo, potem ni smiselno vlagati v avtomatizacijo. Podobno je, če so funkcije aplikacije življenjskega pomena, potem je bolje, da preizkusite ročno.

Odvisno od naslednjih kazalcev se torej odločite, ali želite ročno preskusiti ali avtomatizirati:

• Narava vaše aplikacije.
• Stabilnost vaše aplikacije.
• Razpoložljivi viri, kot je delovna sila, za preučevanje orodij in njihovo primerjavo.
• Koliko časa je vloženo v študijo in razširitev potrebnega orodja za avtomatizacijo?
• Ali je stranka pripravljena vložiti čas v ramp-up in študij?

Orodja za testiranje uporabniškega vmesnika za mobilne aplikacije

Sledi seznam 5 orodij, ki jih lahko uporabimo za testiranje uporabniškega vmesnika mobilne aplikacije za Android in / ali iOS.

(Za orodja za preizkušanje funkcionalnosti y Lahko se sklicujete na seznam orodij za avtomatizacijo naše avtomatizacije orodja za preizkušanje aplikacij Android strani).

# 1) Selendroid

Selendroid je eno najboljših in najbolj priporočljivih orodij za avtomatizacijo mobilnih aplikacij za testiranje uporabniškega vmesnika.

Uporablja se lahko za izvorne in hibridne aplikacije. Uporablja se lahko samo za aplikacije za Android, testi odjemalskega API-ja pa so napisani s programom Selendroid 2. Uporablja se lahko tudi z več napravami in je popolnoma združljiv z JSON.

# 2) Testdroid

To je orodje v oblaku in se lahko uporablja za različne naprave, različne ločljivosti zaslona in različice operacijskega sistema Android in iOS. Vzporedno testiranje naprav je velika prednost tega orodja in je dobro orodje za testiranje uporabniškega vmesnika. Razvijalcem pomaga izboljšati čas do prodaje.

# 3) SeeTest

Je plačljivo orodje in se lahko uporablja za Android, iOS, Windows, Symbian itd.

Je orodje med različnimi platformami, zato je prednost ta, da se lahko isti test izvede na vseh platformah. Uporablja se lahko za vse mobilne aplikacije, preskuse pa lahko izvajate vzporedno na več napravah.

# 4) Avtomatizacija uporabniškega vmesnika

To je uradno orodje za testiranje uporabniškega vmesnika za Apple in je najboljše orodje za avtomatizacijo aplikacij iOS. Čeprav se je težko naučiti, ponuja veliko prednost s knjižnicami, zmogljivostjo, testiranjem uporabniškega vmesnika itd.

# 5) Kalabaš

Uporablja se lahko za testiranje za Android in iOS za izvorne ali hibridne aplikacije. Je orodje med različnimi platformami in je najbolje uporabiti za avtomatizacijo kretenj, posnetkov zaslona, ​​trditev itd. Uporablja se lahko na resničnih napravah z zaslonom na dotik. Ima tudi podporo za kumare.

Ko razvijalci enotno preizkušajo aplikacijo, lahko opravijo tudi testiranje uporabniškega vmesnika s pomočjo Android Studio, vendar se lahko uporablja samo za aplikacije Android.

Priporočeno branje => Avtomatizirajte teste uporabniškega vmesnika

Kontrolni seznam za testiranje uporabniškega vmesnika za mobilne aplikacije

Spodaj je seznam za preizkuševalce, ki zagotavljajo, da je GUI popolnoma dobro preizkušen na pametnih napravah:

5 mitov o avtomatiziranem testiranju uporabniškega vmesnika

Avtomatizirano testiranje uporabniškega vmesnika je zelo pomembno, ko se pojavi vprašanje uspešnosti aplikacije. Toda z avtomatiziranim testiranjem je nekaj mitov.

Takšni miti morda ne držijo, ker so lahko površni. Poglobitev v postopek avtomatiziranega testiranja izgine. Poglobimo se vanje.

Mit 1: Hitrost

Ta mit je zelo pogost. Večina ljudi, povezanih z IT-panogami, ima mit, da 'avtomatizirano testiranje' zahteva več časa v primerjavi z 'ročnim testiranjem'. To dejstvo do neke mere drži v nekaj scenarijih.

Razlog je v tem, da ročno testiranje daje hitre rezultate v primerjavi s samodejnim testiranjem uporabniškega vmesnika. Toda to velja le v predhodni in začetni fazi.

Pri ponavljajočih se vrstah testiranja potrebujete dodajanje veliko več funkcij testiranja ali zmanjšanje lastnosti testiranja. Medtem ko pri samodejnem testiranju vedno izvajate podobne ravni testiranja, s čimer dolgoročno prihranite čas.

Mit 2: Pokritost

V današnjem scenariju se nove naprave Android redno izdajajo na trgih. Število aplikacij takšnih operacijskih sistemov (OS) narašča. Potem obstajajo operacijski sistemi, kot je iOS, ki imajo še več aplikacij za vsakodnevno uporabo.

Ročno testiranje za toliko aplikacij je zelo težko. Toda v primeru avtomatiziranega testiranja zadostuje vzdrževanje strežnikov v oblaku. S pomočjo avtomatiziranega testiranja je možno popolno in popolno pokrivanje aplikacij s preizkusi.

Mit 3: Stroški

Dejstvo je, da avtomatizirano testiranje aplikacij stane več kot stroški ročnega testiranja. Vendar to velja le, če se izvajajo testi za najnujnejše podatke aplikacije. Ko se okolje aplikacije in programska oprema zapleteta, se ročno preskušanje draži.

To je zato, ker so za optimalne rezultate testov potrebna bolj dovršena orodja. Skupaj s tistimi dovršenimi orodji za testiranje obstaja potreba po visoko usposobljenem osebju, ki bi lahko upravljalo takšna orodja. To bo zahtevalo njihovo usposabljanje.

Ročno testiranje je zato dražje v primerjavi z avtomatiziranim.

Mit 4: Doslednost

V primeru ročnega testiranja je vedno prostora za različno dojemanje, ki se razlikuje od enega testerja do drugega. To je odvisno tudi od obravnavanih testov, okolij in aplikacij ter operacijskega sistema (OS).

Ko uporabljate ročno testiranje programske opreme, se pojavijo luknje, skozi katere lahko preide nekaj napak. Zato je ročno testiranje dobro le za odkrivanje osnovnih napak. Avtomatizirano testiranje se izvaja na skriptih in nima prostora za različno zaznavanje, zato je varno.

5. mit: Nenaklonjenost

Ni res, da je avtomatizirano testiranje nadomestilo človeka, temveč za izboljšanje ročnega preizkuševalca. Avtomatizirani testi zagotavljajo avtomatizirane rezultate večkrat, večkrat z največjo natančnostjo. Pojavi se vprašanje, zakaj obstajajo ljudje?

Avtomatizirano testiranje zahteva pisanje scenarijev in načrtovanje celotnega postopka testiranja. Ta naloga zahteva človeški napor. Postopek avtomatiziranega testiranja pomaga prihraniti čas in denar, tako da takšna sredstva porabite za izboljšanje postopkov ročnega testiranja. Razvoj boljših orodij bo nato pomagal pri napredku že obstoječih postopkov avtomatiziranega testiranja.

Zgoraj omenjeno je nekaj najbolj priljubljenih mitov, ki prevladujejo v industriji avtomatiziranega testiranja. To je treba izkoreniniti za izboljšanje avtomatiziranega testiranja uporabniškega vmesnika.

Mit in resničnost

Dejstvo je, da tudi najsodobnejša razvojna podjetja uporabljajo ročno testiranje mobilnih telefonov ali pa sploh ne izvajajo celotnih testiranj. Glede na raziskave Xamarin 2014 13,2% razvijalcev mobilnih naprav izvaja testiranje z avtomatiziranim uporabniškim vmesnikom. Glede na študije Forrester Research samo 53% razvijalcev izvaja le površinske teste na posameznih napravah.

Pet najpogostejših dejavnikov, zakaj ekipe mobilnih telefonov nimajo avtomatiziranih lastnosti mobilnih aplikacij, in pet razlogov, zakaj te niso samo resnično smiselne, je naslednjih:

a) Hitrost je prvi mit.

Človek si ne more vzeti časa za avtomatizacijo. V letu 2014 so prodajalci predstavili 7000 novih vrst naprav Android. Potem je bilo 10000 API-jev, ki so bili specifični za mobilne telefone. Uporaba mobilnih telefonov se pošilja hitreje in hitro spreminja. Z zagotavljanjem kakovosti (QA) v stalnih načinih drobljenja ni časa za ustvarjanje testnih skriptov, ki bi jih usklajevali z redno spreminjajočimi se funkcijami.

Praktični scenarij prvega mita:

Trenutno nekdo zapravlja dragocen čas. Res je res. Testiranje ročno je hitrejše kot samodejno testiranje. Ampak to je za prvo preizkusno vožnjo. Pri nadaljnjih vožnjah, kakršne koli mejne koristi ročno testiranje prinese proti erozijam. To je skoraj takoj. Skupaj z vsemi ponovljenimi preizkusi ali dodatki funkcij bi morali razvijalci aplikacij zmanjšati obseg testiranja ali dodatne vire za testiranje.

Skupaj z omejenim proračunom to na koncu pripelje do začaranih krogov tistih lastnosti, ki se zmanjšujejo. Kot odgovor na podatke in negativne preglede uporabnikov iz nepreizkušenih naprav si skupine želijo razširiti pokritost naprave. To še poveča stres na oddelke za zagotavljanje kakovosti, ki so že kot zmogljivosti.

To je, da se podjetje bori za vzdrževanje, raziskovanje in nabavo naprav med izvajanjem preizkusov. Tudi najbolj financirani ročni programi testiranja uporabniškega vmesnika se zmanjšajo na zaključeno pokritost.

V ZDA ekipe mobilnih naprav zahtevajo testiranje 188 naprav, da pokrijejo 100 odstotkov tržnih deležev. Glede na raziskavo Xamarin iz leta 2014 večina razvojnih skupin pogosto testira na 25 ali manj napravah.

Več kot četrtina teh skupnosti razvijalcev cilja na pet ali manj naprav. V resničnih situacijah testiranja se avtomatizacija izplača skoraj v trenutku in takoj. Že na prvi preizkusni vožnji je priča, da potrošniki časovne roke testiranja pospešijo za 4-krat. To je čez celotno ročno testiranje, ko se izvaja proti petdesetim ali napravam več kot to.

Potekajoče postopke so bile veliko hitrejše. Kljub temu se skrajša skoraj polni preizkusni teden na nekaj ur.

b) Pokritost je drugi mit.

Razdrobljenost je vzrok, da ni mogoče razširiti pokritosti naprave. Skupaj z več kot 19000 napravami edinstvenih Androidov in desetimi permutacijami za oblikovanje operacijskih sistemov in dejavnikov za iOS veliko ekip verjame, da ni mogoče zajeti večine naprav na zagotovljenih trgih.

Torej obstaja privzeto testiranje peščice teh naprav, ki je dovolj dobro.

Resničnost drugega mita:

Lahko bi izpolnili pokritost naprave. Če ljudje hranijo naprave v hiši v pesti, potem naredijo veliko. Nabava naprav je težka.

Vzdrževanje njihovega denarja, stroškov in časa pa omogoči razpoložljivost njihovih preizkuševalcev, kjer in ko se začutijo njihove potrebe, ustvari logistične logjame. Gartner je izjavil, da bi morali razvijalci mobilnih naprav najti načine za doseganje visokih stopenj avtomatizacije, da bi sledili tempu platforme in širjenju sprememb. To je bilo pri gostovanju. Različne funkcije, ki se uporabljajo za notranje upravljanje.

Pot do takšne avtomatizacije vodi prek storitev v oblaku tretjih oseb. Neodvisne storitve v oblaku pomagajo pri avtomatizaciji postopkov nalaganja aplikacij, izvajanju preizkusnih skriptov, poročanju o rezultatih in varni ponovni nastavitvi hrbtnih strani naprav za tovarniške standarde. Podnabori testov aplikacij se izvajajo vzporedno, s čimer pospešujejo rezultate.

Medtem ko preizkušajo široko paleto resničnih naprav, testni oblaki omogočajo vsem in vsem skupinam, da natančno vedo, kako aplikacija deluje, nato pa odpravljajo tipična ugibanja o razvoju v mobilnih napravah.

Primer: Upravitelji izdelkov postavljajo manj sistemskih zahtev skupaj z zaupnostmi, ki so upravičene pri delovanju naprav. Razvijalci prejmejo vizualna potrdila o odpravljanju napak, preden se zavežejo novejšim gradnjam. To je ne glede na to, kje in kdaj delujejo.

c) Stroški so tretji mit.

Posamezniki si lahko privoščijo le ročno testiranje. Za avtomatizacijsko testiranje je treba ustvariti testne skripte, učne krivulje za osebje za zagotavljanje kakovosti in infrastrukturo. Veliko ekip se že bori za doseganje rokov. So že čez proračun. Zdi se, da je avtomatizirano testiranje na daleč.

Praktični scenarij za tretji mit:

Ročno testiranje prihrani denar le, če ljudje žrtvujejo kritja. Ročno testiranje se zdi cenejše le v večini golih kosti.

Če testiranje vključuje hitro 'preverjanje črevesja' osnovnih funkcij manj naprav, se zdi ročno testiranje ugodno. Toda kakršne koli podobnosti s pokritostjo s preizkusi in celovito napravo bodo ročno testiranje precej dražje kot samodejno testiranje. To je lahko celo hitro.

Ročno testiranje meri le z dodajanjem več ljudi in množic. Stroški nimajo prave linearnosti. Povečanje števila zaposlenih za izpolnjevanje zahtev prinaša izjemne splošne stroške v obliki usklajevanja in usposabljanja. Delitev testnih primerov s tem zmanjša učinkovitost vseh preizkuševalcev z odstranjevanjem perspektiv.

Poleg tega preizkuševalci, ki imajo dovolj izpopolnjenosti, da bi lahko presegli vedenja uporabnikov in s tem raziskovali in predvidevali razloge, zakaj lahko aplikacije odpovedo, morda ne bodo niti izdatni niti poceni. Preskus avtomatizacije vedno zahteva nekaj več splošnih stroškov v času začetne nastavitve.

A kot je navedeno zgoraj, lahko s preskusnimi hitrostmi dramatično prinese dobiček in dobiček. V nekaj dneh povzroči tudi ustrezno zmanjšanje števila zaposlenih. Testna okolja v oblaku so dodatno znižala stroške. To je z odpravo premalo izkoriščene in drage infrastrukture za testiranje na terenu.

ponudniki računalništva v oblaku ponujajo svoje storitve kot

d) Doslednost naj bi bil četrti mit.

Dovolj dobro je treba voditi, izvajati in upravljati. Za različne preskusne skupine so pripravljene razmestitve subjektivne odločitve, ki temeljijo na dojemanju številnih različnih ročnih preizkuševalcev. Vedo, da je pomen hroščev, ki padejo skozi razpoke.

Prekrivajoča se testna pokrivanja morajo ujeti najpogostejša in kritična vprašanja pred izdajami. Preostale napake čakajo na izdaje vzdrževanja.

Pravi scenarij četrtega mita:

Kakovosti niso kvalitativne. Pripravljenost produkcij ne sme biti dejavnik in vprašanje mnenja. V povsem ročnem preskusnem okolju se zaznavanje razlikuje od enega testa do drugega in od enega testerja do drugega. To vodi do neenakomernih rezultatov testov in neskladne dokumentacije.

Odločitve se zapletejo, ko so prisotni razlogi za pripravljenost izdelkov. To vodi do neuspešnih skladnosti, množičnega razočaranja in izgubljenih prihodkov. Poleg tega se ustvarijo žepi plemenskih zajetih razumevanj, ki se izgubijo, ko ljudje in zaposleni gredo ven.

Avtomatizacija pa ustvarja merljive meritve. To služi resničnim objektivnim virom za obveščanje o odločitvah glede upravičenosti poslovne odločitve, pripravljenosti izdelka in napredovanju skupin grafikonov.

e) Nenaklonjenost je peti mit.

Ročno testiranje je nadomestilo avtomatizirano testiranje. Veliko različnih razvijalcev je vstopilo v avtomatizacijo preskusov, ker pričakujejo, da bodo preizkuševalce, ki so ročni, zamenjali s stroji.

V primeru, da avtomatizacija testov podobne teste ponovi 1000-krat s 100-odstotno natančnostjo, se pojavijo vprašanja, zakaj ljudje potrebujejo ljudi za namene testiranja. Avtomatizacijo testnih skriptov lahko opravijo tudi stroji.

Slika petega mita v realnem času:

Ročni preizkuševalci postanejo boljši s preizkusi avtomatizacije. Stroji in ljudje imajo dobre scenarije za različne stvari in dejavnike. Preizkuševalci, ki izvajajo ročno testiranje, lahko vedno preizkusijo bolj kreativno.

Preizkus avtomatizacije jih tega osvobaja. Medtem ko se ljudje veselimo novejših načinov razbijanja aplikacij, avtomatizacija zagotavlja skladnost med različnimi napravami. To je od enotnih testov do popolnih regresijskih testov. Ni treba, da dva pristopa delujeta ločeno.

Za izvajanje preskusov je to raziskovalno ročno, medtem ko zapleteni sistemi niso bili obremenjeni z avtomatiziranimi testi. To so odlični načini za odkrivanje napak, ki se pojavljajo v produkcijskih okoljih. Preizkušanje z avtomatizacijo ne nadomešča preizkuševalcev, ki so ljudje. To jim omogoča, da opravljajo koristno in zanimivo delo.

Boljša skladnost, pokritost, stroški in hitrost prispevajo k izboljšavam. Prihranek denarja in časa pomeni, da lahko opravite več preizkusov in ne manj. To je primer, ko dosežemo mejnike, ki so kritični. To omogoča testiranje, da bi sledili skupinam gibčnega razvoja, namesto da bi bili na poti.

Organizacije zato veliko pogosteje izdajajo kodo. To zmanjšuje vplive in količine napak, ki jih dobimo. To pomeni, da razvijalci delajo s čistimi kodami. Odpravljanje napak je bilo dramatično manj zapleteno. To preskuševalce osvobaja s podplatom, ki deluje kot vratarji, ki se osredotočajo na ustvarjalnost. Raziskovalno preskušanje s tem izboljša kakovost izdelkov.

Avtomatizirano testiranje mobilnih uporabniških vmesnikov ponuja prednosti glede časa in kakovosti. Orodja, ki so avtomatizirana in testerjem olajšajo ocenjevanje uporabniških vmesnikov aplikacij prek razširjenega obsega mobilnih naprav, skupaj s spremembami za enostavno povečanje uporabniške izkušnje.

Zaključek

Slab GUI je za uporabnika neprijetna izkušnja. Testiranje grafičnega uporabniškega vmesnika je zelo priporočljivo in pomembno, zlasti ko gre za pametne naprave, ker je tukaj velikost zaslona razmeroma majhna in je na trgu na voljo veliko različic naprav.

Vaša aplikacija se lahko v različnih napravah razlikuje in obnaša. Pomembno je torej, da aplikacijo preizkusite na vsaj nekaterih standardnih velikostih in različicah naprav.

Vse mobilne aplikacije potrebujejo testiranje uporabniškega vmesnika, vendar je globina zahtevanega testiranja odvisna od kategorije ali namena aplikacije. Preden dokončate preizkusno ploščo, morate narediti popolno analizo funkcij uporabniškega vmesnika aplikacije glede na model telefona ali različice operacijskega sistema.

Na podlagi te analize bi morali ustvariti svoje testne primere za testiranje. Uporabite avtomatizacijo, kjer koli je mogoče, da prihranite čas.

Med testiranjem uporabniškega vmesnika bodite odprti, ker je preprost, vendar močno vpliva na prodajo vaše aplikacije.

Za podrobne informacije si oglejte našo prihajajočo vadnico Mobilni odzivni test .

Priporočeno branje

• Appium Vadnica za testiranje mobilnih aplikacij za Android in iOS
• 15 najboljših orodij za mobilno testiranje v letu 2021 za Android in iOS
• Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
• Storitve beta testiranja mobilnih aplikacij (iOS in Android beta različici)
• Zakaj je mobilno testiranje težko?
• Uvod v Robotium - najbolj priljubljeno orodje za testiranje uporabniškega vmesnika za Android
• Preizkus eBook Prenos knjige
• 11 najboljših orodij za avtomatizacijo za testiranje aplikacij za Android (orodja za testiranje aplikacij za Android)