Vodič za testiranje mobilnog korisničkog sučelja (GUI testiranje iOS i Android aplikacija)

mobile ui testing tutorial gui testing ios

Vodič za testiranje korisničkog sučelja za mobilne aplikacije: naučite kako izvesti testiranje korisničkog sučelja za iOS i Android

S procvatu tržišta mobitela, testiranje mobilnih aplikacija postalo je uzbudljivo iz dana u dan.

osiguranje kvalitete nasuprot kontroli kvalitete

Samo pokretanjem funkcionalnih testova na mobilnoj aplikaciji ne možete se odjaviti iz aplikacije. Postoji nekoliko drugih vrsta ispitivanja, poput terenskog, mrežnog testiranja, testiranja korisničkog sučelja, trajanja baterije itd., Koje treba obaviti.

Testiranje korisničkog sučelja jedno je od važnih ispitivanja u testiranju mobilnih aplikacija i ne bi ga trebalo shvatiti olako.

Grafičko korisničko sučelje stvara veliku razliku u tome koliko korisnik zanimljiv i interaktivan nalazi vašu aplikaciju. Važnost pristojnog i atraktivnog grafičkog korisničkog sučelja može se značajnije osjetiti u okruženju pametnih uređaja gdje je veličina zaslona daleko manja u odnosu na zaslon laptopa ili radne površine.

Što ćete naučiti:

• Važnost testiranja korisničkog sučelja mobilne aplikacije
• Kako odlučiti koliko je potrebno testiranje korisničkog sučelja?
• Smjernice: Što testirati u testiranju korisničkog sučelja za mobilne aplikacije
  • # 1) Razlučivost zaslona
  • # 2) Veličina zaslona
  • # 3) Različiti elementi korisničkog sučelja
  • # 4) Stil: Boja i shema sheme uređaja
  • # 5) Multi-touch ili Single touch
  • # 6) Dugi ili kratki pritisak
  • # 7) Mjesto
• Kako testirati varijacije korisničkog sučelja u različitim verzijama OS-a?
• Stvarni uređaji ili emulatori: što odabrati za testiranje korisničkog sučelja?
  • Pros
  • Protiv
• Ručno ili automatizirano testiranje korisničkog sučelja?
• Alati za testiranje korisničkog sučelja mobilne aplikacije
• Kontrolni popis za testiranje korisničkog sučelja za mobilne aplikacije
• 5 mitova o automatiziranom testiranju korisničkog sučelja za mobilne uređaje
  • Mit 1: Brzina
  • Mit 2: Pokrivenost
  • Mit 3: Trošak
  • Mit 4: Dosljednost
  • Mit 5: Nevoljkost
• Mit i stvarnost
• Zaključak
• Preporučena literatura

Važnost testiranja korisničkog sučelja mobilne aplikacije

Da li ćete se kao korisnik osjećati kao da koristite aplikaciju kojoj nedostaje korisnička interakcija i otežava razumijevanje kako je koristiti?

Kad korisnici prvi put koriste mobilnu aplikaciju, pozornost ne krade samo izvedba već i privlačno korisničko sučelje. UI prijateljska aplikacija prodaje se više u usporedbi s aplikacijom koja je najbolje razvijena, ali s gadnim korisničkim sučeljem.

Ako aplikacija na jednom uređaju ima savršeno i sjajno korisničko sučelje, ali na drugom je potpuno uvrnuta samo zato što ima drugačiju veličinu ili drugačiji OS, tada će ostaviti vrlo loš dojam. To će teško utjecati na komercijalni uspjeh aplikacije.

Hoćete li promovirati aplikaciju u kojoj je gumb premalen da bi klik blokirao čitav niz funkcionalnosti?

Nisu li to neugodna iskustva za korisnike? Zbog gore spomenutih slučajeva postaje vrlo važno testirati korisničko sučelje aplikacije. Dvije glavne provjere koje je potrebno obaviti za mobilne aplikacije jesu jednostavnost i izgled različitih modela i verzija OS-a.

Slijedi primjer kako korisničko sučelje treba biti savršeno za različite veličine zaslona:

Kako odlučiti koliko je potrebno testiranje korisničkog sučelja?

Sljedeći grafikon označava različite vertikale u koje se mogu kategorizirati mobilne aplikacije:

(slika izvor )

Iz gornjeg grafikona možete razabrati da Gaming aplikacije zauzimaju većinu tržišnog udjela od oko 24,43%, a zatim slijede poslovne i obrazovne aplikacije.

• Aplikacije razvijene kao aplikacije za igre trebaju temeljito testiranje u svakom aspektu, jer korisničko sučelje najviše doprinosi postizanju uspjeha, bez obzira radi li se o izvornoj ili hibridnoj aplikaciji
• Poslovna se aplikacija možda neće u potpunosti osloniti na korisničko sučelje za svoj uspjeh, jer je u većini slučajeva ciljana publika osposobljena za upotrebu aplikacije. Stoga takve aplikacije mogu imati jednostavno korisničko sučelje.
• Aplikacije razvijene u obrazovne svrhe trebaju temeljito testiranje korisničkog sučelja.
• Komercijalne aplikacije poput kupovine, putovanja itd. Također trebaju cjelovito testiranje korisničkog sučelja na različitim uređajima i različitim verzijama OS-a.

Ukratko, ovisno o namjeni aplikacije, može se odrediti dubina testiranja korisničkog sučelja, ali testiranje korisničkog sučelja uvijek treba provoditi na najmanje 3 različite verzije OS-a.

Smjernice: Što testirati u testiranju korisničkog sučelja za mobilne aplikacije

Tijekom testiranja korisničkog sučelja na mobilnoj aplikaciji potrebno je provjeriti razne karakteristike.

Slijede neke od karakteristika koje treba testirati za svaku aplikaciju:

# 1) Razlučivost zaslona

Slijede neke od uobičajenih rezolucija zaslona koje se uzimaju u obzir prilikom stvaranja testnih staza:

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

Sve ove rezolucije potrebne su za testiranje kada u aplikaciji imate raspored s više stupaca.

Stoga provjeru treba obaviti počevši od najmanje do najveće razlučivosti. Osim toga, ako vaša aplikacija ima dugački popis kartica s informacijama, one također treba testirati na drugoj razlučivosti radi umotavanja podataka.

( izvor slike )

# 2) Veličina zaslona

Previše je varijacija u veličinama zaslona i dostupnim razlučivostima. Pogotovo u pametnim uređajima, veličine kontrola nisu statične, već imaju odnos s dostupnom veličinom zaslona.

Tijekom testiranja, pobrinite se da veličina kontrola izgleda estetski dobro i da je kontrola u potpunosti vidljiva na zaslonu bez pomicanja. Testirajte GUI na različitim uređajima s različitim veličinama i rezolucijama zaslona.

U tu svrhu su dobri emulatori, ali ništa se ne podudara sa stvarnim uređajem. Pazite da testirate na barem dva ili tri stvarna uređaja. Također, ne zaboravite testirati pejzažne i portretne orijentacije podržava li ga uređaj.

Morate testirati aplikaciju u uobičajenim rezolucijama kako biste osigurali njezinu iskoristivost.

Nekoliko stvari koje ovdje morate razumjeti su:

Razlika između veličine zaslona i razlučivosti: Veličina zaslona je duljina zaslona u inčima izmjerena dijagonalno ili od jednog do drugog kuta zaslona. Rezolucija zaslona je širina i visina, Primjer 640w × 480h koji predstavlja broj piksela koji prelaze zaslon pomnožen s nekoliko piksela koji se spuštaju.

# 3) Različiti elementi korisničkog sučelja

Elementi korisničkog sučelja poput gumba, zaglavlja, ikona, slika, polja za odabir, tekstualnih polja, potvrdnih okvira itd., Neki su od različitih elemenata koje treba provjeriti zbog izgleda i veličine na zaslonu.

Točnije za tekstna polja, ako se meka tipkovnica pojavi na dodir u tekstnom polju, treba ih testirati i provjeriti.

Ono što je najvažnije potrebno je temeljito testiranje veličina gumba, jer se sjećam da smo u našoj aplikaciji tijekom testiranja na Galaxy S telefonu pronašli blokator u kojem je gumb blokirao cijelu aplikaciju samo zato što je gumb izgledao previše sićušan za klikanje.

Položaj elemenata korisničkog sučelja također treba provjeriti prema zahtjevu, tj. Ako svi trebaju biti centrirani ili lijevo poravnati itd.

# 4) Stil: Boja i shema sheme uređaja

Korisničko sučelje aplikacije i shema boja trebali bi biti u skladu s različitim shemama boja i tema telefona. Boja i tema Samsung telefona uvelike se razlikuju od Nokia ili MI telefona .

Stoga morate provjeriti izgleda li aplikacija dosljedna na takvim telefonima.

Vaša aplikacija ima specifičan dizajn. I stil kontrola trebao bi se podudarati s tim dizajnom. Možda ste vidjeli mnogo aplikacija u kojima neke kontrole npr. ploče imaju okrugle rubove i druge kontrole npr. okviri za tekst imaju oštre rubove.

Iako ova vrsta problema ne utječe na upotrebljivost ili funkcionalnost aplikacije, ipak dosljedan izgled aplikacije pomaže u stvaranju prijateljskog odnosa između aplikacije i korisnika.

Jedna od najvažnijih stvari u stilu je font različitih stranica. Font treba dobro testirati kako bi se izbjegla neskladnost u izgledu i stilu aplikacije.

Većinu vremena usredotočujemo se na tekst koji je vidljiv u normalnim situacijama i zanemarujemo tekst koji se pojavljuje u određenim situacijama. Poruke o uspjehu i neuspjehu primjer su takve vrste teksta.

Još jedan faktor koji je važan u stilu je veza između boje fonta i situacije u kojoj se tekst prikazuje.

Na primjer, Crvena boja koristi se za poruke o pogreškama, zelena za uspjeh, žuta za upozorenja i plava za hiperveze.

# 5) Multi-touch ili Single touch

Ako vaša aplikacija podržava značajku dodira, poput prstohvata za zumiranje ili umanjivanja za smanjivanje itd., Tada morate temeljito testirati ovu značajku i stvoriti puno primjera za to za sve primjenjive zaslone.

# 6) Dugi ili kratki pritisak

Dugim pritiskom na ikonu prikazuje se kontekstni izbornik, dok kratkim dodirom izvršavate prvu radnju izbornika. Ako je ova značajka dostupna u vašoj aplikaciji, tada morate potvrditi ovu funkciju i sve funkcije oko nje.

# 7) Mjesto

Mjesto i položaj dvije su riječi koje se koriste alternativno, a što je zanimljivo, dalje se koriste za prenošenje dva različita koncepta koji su objašnjeni u nastavku:

1) Ponekad se na području zaslona pojavi kontrola.

Na primjer, Zaglavlje se nalazi na vrh stranice, Oznake su Lijevo poravnato i Tekstualni okviri su Desno poravnato, itd. Ovdje su 'gore', 'lijevo poravnato' i 'desno poravnato' relativni položaji kontrola.

dva) Ponekad je to redoslijed kontrole među ostalim kontrolama.

Na primjer, dok dobivate osobne podatke, Ime je slijedio po prezimenu. Ili bi trebao biti format kontrola za traženje adrese u SAD-u narudžba - ZIP, grad, država.

U obje ove situacije govorimo o mjestu kontrola.

Tijekom testiranja položaja i položaja kontrola, pobrinite se da je sve logično postavljeno na zaslon i da pokazuje dobar estetski osjećaj.

Postoje situacije u kojima se jedna ili više kontrola pojavljuju na više zaslona. U ovoj situaciji morate biti sigurni da se pojavljuju na istom mjestu i u istom relativnom redoslijedu na svim stranicama.

Kako testirati varijacije korisničkog sučelja u različitim verzijama OS-a?

Korisničko sučelje razlikuje se od verzije OS-a, a lansiranjem nove verzije poboljšavaju se u korisničkom sučelju.

Promotrimo korisničko sučelje 3 najnovijeg OS-a koji je trenutno dostupan i shvatimo kako ove varijacije utječu na mobilnu aplikaciju.

Oni su:

1. Lizalica
2. Bijeli slez
3. Nugat

Gledajući gornji popis novih korisničkih sučelja ili značajki funkcionalnosti, kao QA morate oko toga dizajnirati test slučajeve.

1) Lizalica:

• Stvorite test slučajeve za učinak novog dizajna na vašu aplikaciju.
• Ne nužno za sve zaslone, ali stvorite test slučajeve za pristup novim prečacima u svojoj aplikaciji.

2) Sljez:

• Ako se vaša aplikacija bavi emojijima, stvorite test slučajeve kako biste provjerili nove emojije. Aplikacije koje omogućuju korisnicima pisanje recenzija ili razgovor su one koje često koriste emojije.
• Kada se vaša aplikacija prvi put objavi i instalira, možda će trebati zatražiti dopuštenje, stoga treba obaviti potrebu za testiranjem korisničkog sučelja novog zaslona s dopuštenjima. I stvorite test slučajeve za iste.
• Ako vaša aplikacija koristi Google Now, trebate stvoriti test slučajeve kako biste testirali korisničko sučelje ažurirane značajke Google Now.

3) Nougat:

• Potrebno je izvršiti temeljito testiranje vaše aplikacije za režim stvarnosti u snu i stoga stvoriti test slučajeve u skladu s tim.
• Stvorite test slučajeve da biste provjerili opcije izbornika za svoju aplikaciju.
• Ako se vaša aplikacija bavi emojijima i GIF-ovima, stvorite test slučajeve kako biste provjerili nove emojije i opciju slanja GIF-ova.

Stvarni uređaji ili emulatori: što odabrati za testiranje korisničkog sučelja?

Kad morate testirati mobilnu aplikaciju, možda ćete razmisliti o tome što bi testna ploča trebala biti?

Hoćete li testirati na stvarnom uređaju ili emulatoru ili oboje? Na to nema čvrstog odgovora, jer izbor ovisi o tome što želite testirati.

Za testiranje funkcionalnosti, performansi, mrežne reakcije, terenskog ispitivanja itd. Uvijek biste trebali preferirati pravi uređaj. Ali za stvari poput korisničkog sučelja trebali biste odabrati emulatore zajedno s nekim stvarnim uređajima.

Pros

Prednosti upotrebe emulatora za testiranje korisničkog sučelja su:

1) Praktički nije moguće prikupiti uređaje svih rezolucija, a to bi također koštalo ogroman novac. Ali emulatori ne koštaju ništa.
dva) S emulatorom možete stvoriti sve razlučivosti zaslona i kombinacije OS-a.
3) Ako imate samo jedan set stvarnih uređaja, ali QA tim broji više od 1 osobe, tada svi QA-i ne mogu paralelno testirati isti pokusni prostor. Uz emulator, svaki QA može stvoriti istu kombinaciju na svom stroju i paralelno testirati.
4) Testiranje na emulatoru oduzima manje vremena i brže je u usporedbi sa stvarnim uređajem.
5) Uobičajene greške povezane s korisničkim sučeljem poput poravnavanja itd. Mogu se lako uhvatiti na emulatorima.

Protiv

Protiv uključuju:

1) Geste se ne mogu testirati na emulatorima. Istodobno se može oponašati samo jedna gesta.
dva) Fizički ulazi GPS-a, padajuća ili slaba mreža itd. Također se ne mogu testirati.
3) Ni na koji način ne možete stvoriti emulator za telefone Sony, LG, Nexus itd.
4) Na emulatoru nije moguće stvoriti stvarno okruženje s istrošenom baterijom ili s malo memorije itd.

Stoga bi odluku trebalo donijeti ovisno o vašoj aplikaciji i zahtjevu za testiranje.

Ručno ili automatizirano testiranje korisničkog sučelja?

Nijedan proizvod, bilo da se radi o desktop aplikaciji ili web aplikaciji ili mobilnoj aplikaciji, ne može se objaviti bez testiranja. Kao QA borimo se kako bismo pronašli i prijavili svaki nedostatak, ali svejedno ih prijavljuju kupci.

Znaš li zašto?

Budući da dugotrajni testovi koje se često izbjegavaju ili propuštaju ostavljajući neotkrivene bugove. Također 100% pokrivenost, dubinsko izvršavanje nije moguće ručnim testiranjem.

Testiranje korisničkog sučelja prilično je jednostavno i jednostavno, a vi jednostavno morate pogledati kako vam izgleda. Ako se to radi ručno, to oduzima puno vremena. Također, u većini slučajeva trebamo stvoriti ogromne podatke za testiranje korisničkog sučelja poput pomicanja, pojavit će se samo ako redovi karata prelaze određeni broj.

Stvaranje velikih podataka vrlo je dugotrajno. Imati automatizirani paket može riješiti oba problema.

Suprotno tome, ako su funkcionalnosti ili korisničko sučelje aplikacije još uvijek u fazi promjene, onda nema smisla ulagati u automatizaciju. Slično tome, ako su funkcije aplikacije vitalne, tada je bolje testirati ručno.

Stoga, ovisno o sljedećim uputama, trebali biste odlučiti hoćete li testirati ručno ili automatizirati:

• Priroda vaše aplikacije.
• Stabilnost vaše aplikacije.
• Dostupni resursi poput radne snage za proučavanje alata i njihovu usporedbu.
• Koliko je vremena uloženo u proučavanje i pojačanje potrebnog alata za automatizaciju?
• Je li klijent spreman uložiti vrijeme u dodavanje i proučavanje?

Alati za testiranje korisničkog sučelja mobilne aplikacije

Slijedi popis 5 alata koji se mogu koristiti za testiranje korisničkog sučelja mobilne aplikacije za Android i / ili iOS.

(Za alate za ispitivanje funkcionalnosti y Možete se pozvati na popis alata za automatizaciju u našoj automatizaciji alati za testiranje Android aplikacija stranica).

# 1) Selendroid

Selendroid je jedan od najboljih i najčešće preporučenih alata za automatizaciju mobilnih aplikacija za testiranje korisničkog sučelja.

kako pokrenuti .bin datoteku

Može se koristiti i za izvorne i za hibridne aplikacije. Može se koristiti samo za Android aplikacije, a testovi API-ja klijenta napisani su pomoću programa Selendroid 2. Također se može koristiti s više uređaja i u potpunosti je kompatibilan s JSON-om.

# 2) Testdroid

Ovo je alat zasnovan na oblaku i može se koristiti za razne uređaje, različite razlučivosti zaslona i OS verzije Androida i iOS-a. Paralelno testiranje uređaja velika je prednost ovog alata i dobar je alat za testiranje korisničkog sučelja. Pomaže programerima da poboljšaju vrijeme izlaska na tržište.

# 3) SeeTest

To je plaćeni alat i može se koristiti za Android, iOS, Windows, Symbian itd.

To je alat za više platformi i stoga je prednost što se isti test može izvoditi na svim platformama. Može se koristiti za sve mobilne aplikacije, a testovi se mogu paralelno izvoditi na više uređaja.

# 4) Automatizacija korisničkog sučelja

Ovo je službeni alat za testiranje korisničkog sučelja za Apple i najbolji je alat za automatizaciju iOS aplikacija. Iako je teško naučiti, nudi veliku prednost s knjižnicama, performansama, testiranjem korisničkog sučelja itd.

# 5) Calabash

Može se koristiti za testiranje Androida i iOS-a za izvorne ili hibridne aplikacije. To je alat za više platformi i najbolje se koristi za automatizaciju gesta, snimki zaslona, ​​tvrdnji itd. Može se koristiti na stvarnim dodirnim zaslonima. Ima i podršku za krastavac.

Kada programeri jedinstveno testiraju aplikaciju, mogu izvršiti i testiranje korisničkog sučelja pomoću Android Studija, ali može se koristiti samo za Android aplikacije.

Preporučena literatura => Automatizirajte testove korisničkog sučelja

Kontrolni popis za testiranje korisničkog sučelja za mobilne aplikacije

Ispod je popis za ispitivače kako bi se osiguralo da se GUI potpuno dobro testira na pametnim uređajima:

5 mitova o automatiziranom testiranju korisničkog sučelja za mobilne uređaje

Automatizirano testiranje korisničkog sučelja za mobilne uređaje smatra se presudnim kada se postavi pitanje uspješnosti aplikacije. Ali postoje neki mitovi vezani uz automatizirano testiranje.

Takvi mitovi možda nisu istiniti jer su površni. Duboko ulazeći u proces automatiziranog testiranja, on nestaje. Kopajmo dublje u njih.

Mit 1: Brzina

Ovaj je mit vrlo čest. Većina ljudi povezanih s IT industrijom ima mit da izvođenje 'automatiziranog testiranja' oduzima više vremena u usporedbi s 'ručnim testiranjem'. Ta je činjenica donekle istinita u nekoliko scenarija.

Razlog je taj što ručno testiranje daje brze rezultate u usporedbi s automatskim testiranjem korisničkog sučelja za mobilne uređaje. Ali to je slučaj samo u preliminarnoj i početnoj fazi.

Uz ponovljeno testiranje, potrebno vam je dodati puno više značajki testiranja ili smanjiti kvalitete testiranja. Dok kod automatiziranog testiranja uvijek izvodite slične razine testiranja, što dugoročno štedi vrijeme.

Mit 2: Pokrivenost

U današnjem scenariju, novi Android uređaji redovito se pojavljuju na tržištima. I broj aplikacija takvih operativnih sustava (OS) raste. Zatim postoje operativni sustavi poput iOS-a koji imaju još više aplikacija izrađenih za svakodnevnu upotrebu.

Ručno testiranje za toliko aplikacija postaje vrlo teško. Ali u slučajevima automatiziranog testiranja bit će dovoljno održavanje poslužitelja u oblaku. Uz pomoć automatiziranog testiranja moguće je potpuno i potpuno pokrivanje aplikacija aplikacijama.

Mit 3: Trošak

Činjenica je da automatizirano testiranje aplikacija košta više u usporedbi s troškovima ručnog testiranja. Međutim, to vrijedi samo ako se provode testovi za najvažnije osnove aplikacije. Kako se okruženje aplikacije i softver usložnjavaju, ručno testiranje postaje sve skuplje.

To je zato što su za postizanje optimalnih rezultata ispitivanja potrebni sofisticiraniji alati. Uz te sofisticirane alate za testiranje, postoji potreba za visoko obučenim osobljem koje bi moglo upravljati takvim alatima. To će zahtijevati njihovo osposobljavanje.

Dakle, ručno testiranje postaje skuplje u usporedbi s automatiziranim.

Mit 4: Dosljednost

U slučaju ručnog ispitivanja, uvijek postoji prostor za različite percepcije koje se razlikuju od jednog ispitivača do drugog. To također ovisi o razmatranim testovima, okruženjima i aplikacijama, zajedno s operativnim sustavom (OS).

Kada primijenite ručno testiranje na softver, postoje rupe kroz koje bi moglo proći nekoliko bugova. Stoga je ručno testiranje dobro samo za otkrivanje osnovnih grešaka. Automatizirano testiranje radi na skriptama bez prostora za različitu percepciju što ga čini sigurnim.

Mit 5: Nevoljkost

Nije istina da je automatizirano testiranje zamijenilo ljude, nego za poboljšanje ručnog ispitivača. Automatizirani testovi daju automatizirane rezultate više puta, više puta s maksimalnom točnošću. Stoga se postavlja pitanje zašto postoji potreba za ljudima?

Automatizirano testiranje treba pisanje scenarija i planiranje cijelog postupka testiranja. Ovaj zadatak zahtijeva ljudski napor. Postupak automatiziranog testiranja pomaže uštedjeti vrijeme i novac tako da takve resurse koristite za poboljšanje postupaka ručnog testiranja. Razvoj boljih alata zauzvrat će pomoći u unapređenju već postojećih postupaka automatiziranog testiranja.

Iznad je spomenuto nekoliko najpopularnijih mitova koji prevladavaju u industriji automatiziranih ispitivanja. To treba iskorijeniti za poboljšanje automatiziranog testiranja korisničkog sučelja za mobilne uređaje.

Mit i stvarnost

Činjenica je da čak i najsofisticiranije razvojne tvrtke koriste ručno testiranje mobitela ili uopće ne provode cjelovita ispitivanja. Prema anketama Xamarin 2014, 13,2% programera mobilnih uređaja provodi testiranje pomoću automatiziranog korisničkog sučelja. Prema studijama Forrester Research-a, samo 53% programera provodi letimična ispitivanja na pojedinačnim uređajima.

Pet najčešćih čimbenika zašto timovi mobilnih uređaja nisu automatizirali kvalitete mobilnih aplikacija, a pet razloga zašto to nemaju samo stvarni smisao su sljedeći:

a) Brzina je prvi mit.

Osoba ne može uzeti vrijeme za automatizaciju. 2014. godine dobavljači su predstavili 7000 novih tipova Android uređaja. Tada je bilo 10000 API-ja koji su specifični za mobitele. Primjena mobilnih uređaja isporučuje se brže i brzo se mijenja. Uz osiguranje kvalitete (QA) u stalnim načinima drobljenja, nema vremena za stvaranje testnih skripti, zauzvrat, održavajući ih u sinkronizaciji s redovito mijenjanim značajkama.

Praktični scenarij prvog mita:

Trenutno se troši dragocjeno vrijeme. To je vrlo točno. Testiranje ručno brže je od automatskog testiranja. Ali ovo je za prvo testiranje. U sljedećim ciklusima, kakve god ručne koristi ručno testiranje dovelo do erozije. Ovo je gotovo odmah. Zajedno sa svim ponovljenim probama ili dodavanjima značajki, programeri aplikacija trebaju ili smanjiti opseg testiranja ili dodatne resurse za testiranje.

Zajedno s konačnim proračunom, ovo u konačnici dovodi do začaranih ciklusa onih svojstava koja se smanjuju. Kao odgovor na angažiranje podataka i negativne preglede korisnika s neprovjerenih uređaja, timovi žele proširiti pokrivenost uređaja. To dodatno povećava stres na odjele za osiguranje kvalitete već kao kapacitete.

To je ono što se posao bori za održavanje, istraživanje i nabavu uređaja tijekom izvođenja testova. Čak i najbolje financirani ručni programi testiranja korisničkog sučelja padaju prema skraćenom pokrivanju.

U SAD-u timovi mobilnih uređaja trebaju testiranje na 188 uređaja kako bi pokrili 100 posto marketinških udjela. Prema istraživanju Xamarin iz 2014. godine, većina razvojnih timova često testira na 25 ili manje uređaja.

Više od jedne četvrtine ovih zajednica programera cilja pet ili manje uređaja. U stvarnim situacijama testiranja, automatizacija se isplati gotovo trenutno i odmah. Već na prvom testiranju svjedoči da potrošači ubrzavaju rokove testiranja za 4 puta. Gotovo je s čitavim ručnim testiranjem kada se trči protiv pedeset ili više uređaja.

Pokreti koji su u slijedu bili su puno brži. Ipak postoji skraćenje za gotovo cijeli tjedan testiranja na samo nekoliko sati upotrebe.

b) Pokrivenost je drugi mit.

Fragmentacija je uzrok nemogućnosti širenja pokrivenosti uređaja. Zajedno s više od 19000 uređaja jedinstvenih Androida i permutacijom desetaka za oblikovanje operativnih sustava i čimbenika za iOS, mnogi timovi vjeruju da nije moguće pokriti većinu uređaja na osiguranim tržištima.

Dakle, postoji zadano testiranje na nekolicini ovih uređaja kao dovoljno dobro.

Stvarnost drugog mita:

Moglo se završiti pokrivanje uređaja. U slučaju da ljudi drže uređaje u kući u pregrštima, tada rade puno. Nabavka uređaja je teška.

Održavajući svoj novac, troškove i vrijeme, zauzvrat, čineći svoje testere dostupnima tamo i kada se osjeti njegova potreba stvara logističke logjame. Gartner je izjavio da bi programeri mobilnih uređaja trebali pronaći načine za postizanje visokih stopa automatizacije kako bi išli u korak s tempom platforme i širenjem promjena. Ovo je bilo u hostingu. Različite funkcije koje se koriste unutarnjim upravljanjem.

Put do takve automatizacije je putem usluga u oblaku trećih strana. Usluge u oblaku treće strane pomažu u automatizaciji procesa učitavanja aplikacija, testiranju izvršavanja skripti, izvještavanju o rezultatima i sigurnom ponovnom postavljanju stražnjih dijelova uređaja za standarde tvornica. Podskupovi testova aplikacija rade paralelno, a time i ubrzavaju rezultate.

Tijekom testiranja na širokom rasponu stvarnih uređaja, testni oblaci omogućavaju timovima svima da precizno znaju kako aplikacija funkcionira, eliminirajući tipično nagađanje mobilnog razvoja.

Primjer: Menadžeri proizvoda postavljaju manje sistemskih zahtjeva zajedno s povjerljivostima koje su opravdane u izvedbama uređaja. Programeri dobivaju vizualne potvrde cilja popravljanja programskih pogrešaka prije nego što se posvete novijim verzijama. To je bez obzira na to gdje i kada djeluju.

c) Trošak je treći mit.

Pojedinci si mogu priuštiti samo ručno testiranje. Automatsko testiranje treba stvaranje testnih skripti, krivulja učenja za osoblje osiguranja kvalitete i infrastrukture. Mnogo timova već se bori za ispunjenje rokova. Već su premašili proračun. Dakle, čini se da je automatsko testiranje na dalekoj udaljenosti.

Praktični scenarij za treći mit:

Ručno testiranje štedi novac samo u slučaju da ljudi žrtvuju pokrivenost. Ručno testiranje čini se jeftinijim samo u većini golih kostiju.

U slučaju da testiranje uključuje brzu 'provjeru crijeva' osnovnih funkcionalnosti manje uređaja, ručno testiranje izgleda kao povoljne cijene. No, svaka sličnost s pokrivenošću ispitivanja i sveobuhvatnim uređajem ručno će testiranje učiniti skupljim od automatskog testiranja. Ovo bi moglo biti čak i brzo.

Ručno testiranje mjeri se samo dodavanjem više ljudi i masa. Troškovi nemaju pravu linearnost. Povećavanje broja osoblja radi ispunjavanja zahtjeva donosi ogromne opće troškove u obliku koordinacije i obuke. Podjela testnih slučajeva smanjuje učinkovitost svih ispitivača uklanjanjem perspektiva.

Uz to, testeri koji imaju dovoljno sofisticiranosti za iskakanje izvan ponašanja korisnika, istražujući i predviđajući razloge zbog kojih aplikacije mogu propasti, možda neće biti ni izdašni ni jeftini. Ispitivanje automatizacije uvijek zahtijeva nešto više općih troškova u vrijeme početnog postavljanja.

No, kao što je gore rečeno, to može dramatično donijeti dobitak i dobit na test brzinama. Također donosi odgovarajuće smanjenje broja osoblja u roku od nekoliko dana. Testna okruženja u oblaku dodatno su smanjila troškove. To je eliminacijom premalo iskorištene i skupe infrastrukture za lokalno testiranje.

d) Dosljednost će biti četvrti mit.

Dovoljno dobro treba biti provedeno, izvršeno i upravljano. Za različite timove za testiranje, spremne implementacije su subjektivne odluke koje se temelje na percepciji mnogih različitih ručnih testera. Oni znaju da je značenje da bube prolaze kroz pukotine.

Prekrivajući testni pokrivači moraju uhvatiti najčešće i najvažnije probleme prije objavljivanja. Ostali bugovi čekaju izdanja za održavanje.

Pravi scenarij četvrtog mita:

Kvalitete nisu kvalitativne. Spremnost produkcija ne smije biti čimbenik i pitanje mišljenja. U čistom okruženju ručnog testiranja percepcija se razlikuje od jednog testa do drugog testa, a jedan tester do drugog testa. To dovodi do nestalnih rezultata ispitivanja i dosljednih dokumentacija.

Odluke se kompliciraju kada su prisutna razmatranja o spremnosti proizvoda. To dovodi do neuspjeha usklađenosti, masovnog razočaranja i gubitka prihoda. Uz to, postoji i stvaranje džepova plemenskih neshvaćenih shvaćanja koja se gube kad ljudi i zaposlenici izađu van.

Automatizacija, pak, stvara mjerljive mjerne podatke. Ovo služi kao objektivni izvor istine za informiranje o odlukama u vezi s opravdanošću poslovne odluke, spremnošću proizvoda i napredovanjem timova.

e) Nerad je peti mit.

Ručno ispitivanje zamijenjeno je automatskim ispitivanjem. Mnogo različitih programera ima pristup automatizaciji ispitivanja jer očekuju da će testere koji su ručni zamijeniti strojevima.

U slučaju da automatizacija testova ponovi slična ispitivanja 1000 puta sa 100-postotnom točnošću, tada se postavljaju pitanja zašto postoje potrebe ljudi za svrhe testiranja. Automatizaciju test skripti mogu izvršiti i strojevi.

Slika petog mita u stvarnom vremenu:

Ručni testeri postaju bolji s automatskim ispitivanjem. Strojevi i ljudi imaju dobre scenarije za puno različitih stvari i čimbenika. Ispitivači koji rade ručno testiranje uvijek mogu testirati kreativnije.

Automatsko testiranje ih oslobađa od toga. Iako se ljudi raduju novijim načinima razbijanja aplikacija, automatizacija osigurava usklađenost na širokom spektru uređaja. To je od jediničnih testova do potpunih regresivnih testova. Dva pristupa ne trebaju raditi izolirano.

Izvođenje testova je istraživačko ručno, dok zaostali sustavi nisu bili pod opterećenjem automatiziranih ispitivanja. Ovo su izvrsni načini za otkrivanje pogrešaka koje se pojavljuju u produkcijskim okruženjima. Ispitivanje automatizacijom ne zamjenjuje testere koji su ljudi. To im omogućuje provođenje korisnog i zanimljivog posla.

Bolja dosljednost, pokrivenost, trošak i brzina dodaju se onim osobinama koje se poboljšavaju. Ušteda novca i vremena znači da se može više testirati, a ne manje. To je slučaj kada se dosegnu prekretnice koje su kritične. To omogućuje testiranje da ide u korak s timovima agilnih dostignuća, umjesto da stoje na putu.

Stoga organizacije puno češće objavljuju kod. To smanjuje utjecaje i daju se građe nedostataka. To znači da programeri rade s čistim kodovima. Ispravljanje programskih pogrešaka dramatično je manje komplicirano. To oslobađa testere kroz potplat koji djeluje kao vratari koji se usredotočuju na kreativnost. Istraživačko ispitivanje time poboljšava kvalitete proizvoda.

Automatsko testiranje mobilnih korisničkih sučelja nudi prednosti u pogledu vremena i kvaliteta. Alati koji su automatizirani i olakšavaju testerima procjenu korisničkog sučelja aplikacija kroz prošireni raspon mobilnih uređaja, zajedno s izmjenama radi lakog poticanja korisničkog iskustva.

Zaključak

Loš GUI neugodno je iskustvo za korisnika. Testiranje grafičkog korisničkog sučelja je vrlo preporučljivo i važno, posebno kada je riječ o pametnim uređajima, jer je ovdje veličina zaslona relativno mala i na tržištu je dostupno puno varijacija uređaja.

Vaša aplikacija može izgledati i ponašati se drugačije na različitim uređajima. Dakle, važno je testirati aplikaciju na barem nekim standardnim veličinama i varijacijama uređaja.

koju web stranicu mogu gledati anime

Sve mobilne aplikacije trebaju testiranje korisničkog sučelja, ali dubina potrebnog testiranja definira se kategorijom ili svrhom aplikacije. Trebali biste napraviti cjelovitu analizu značajki korisničkog sučelja aplikacije u odnosu na model telefona ili verzije OS-a prije nego što finalizirate testni prostor.

Na temelju ove analize trebali biste stvoriti svoje test slučajeve za testiranje. Upotrijebite automatizaciju gdje god je to moguće kako biste uštedjeli vrijeme.

Držite otvoreno oko tijekom testiranja korisničkog sučelja jer je jednostavno, ali ima velik utjecaj na prodaju vaše aplikacije.

Pogledajte detaljne informacije o našem predstojećem vodiču Mobilni reaktivni test .

Preporučena literatura

• Vodič za testiranje aplikacija za Android i iOS za mobilne uređaje
• TOP 15 najboljih alata za mobilno testiranje 2021. za Android i iOS
• Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
• Usluge beta testiranja mobilne aplikacije (iOS i Android beta alati)
• Zašto je mobilno testiranje teško?
• Početak rada s Robotiumom - najpopularnijim alatom za testiranje korisničkog sučelja za Android aplikaciju
• Preuzimanje e-knjige za testiranje primera
• 11 najboljih alata za automatizaciju za testiranje Android aplikacija (Android Tools Testing Tools)