Tutorial UI Mobile Testing (Testarea GUI a aplicațiilor iOS și Android)

mobile ui testing tutorial gui testing ios

Ghid de testare a interfeței de utilizare a aplicației mobile: aflați cum să efectuați testarea interfeței de utilizare iOS și Android

Odată cu înflorirea pieței pentru telefoane mobile, testarea aplicațiilor mobile a devenit zi de zi interesantă.

întrebări de bază despre interviu c ++

Doar executând teste funcționale pe o aplicație mobilă, nu puteți deconecta aplicația. Există câteva alte tipuri de testare, cum ar fi testarea pe teren, testarea rețelei, testarea UI, testarea duratei de viață a bateriei etc., care trebuie făcute.

Testarea interfeței de utilizare este unul dintre testele importante în testarea aplicațiilor mobile și nu trebuie luată cu ușurință.

Interfața grafică a utilizatorului creează o mare diferență în ceea ce privește interesul și interactivitatea pentru care un utilizator găsește aplicația dvs. Importanța unei interfețe grafice decente și atractive poate fi simțită mai semnificativ într-un mediu inteligent al dispozitivului, unde dimensiunea ecranului este mult mai mică în comparație cu un ecran de laptop sau desktop.

Ce veți învăța:

• Importanța testării interfeței de utilizare a aplicației mobile
• Cum să decideți cât de mult este necesar testul UI?
• Instrucțiuni: Ce să testați în testarea interfeței de utilizare a aplicației mobile
  • # 1) Rezoluția ecranului
  • # 2) Dimensiunea ecranului
  • # 3) Diferite elemente de interfață
  • # 4) Stil: Schema de culoare și temă a dispozitivului
  • # 5) Multi-touch sau Single touch
  • # 6) Apăsați lung sau scurt
  • # 7) Locație
• Cum se testează variațiile UI în diferite versiuni ale sistemului de operare?
• Dispozitive reale sau emulatoare: ce să alegeți pentru testarea interfeței de utilizare?
  • Pro
  • Contra
• Testarea manuală sau automatizată a interfeței de utilizare?
• Instrumente de testare a interfeței pentru aplicația mobilă
• Listă de verificare pentru testarea interfeței aplicației mobile
• 5 mituri despre testarea automată a interfeței mobile
  • Mitul 1: Viteza
  • Mitul 2: Acoperire
  • Mitul 3: Cost
  • Mitul 4: Coerența
  • Mitul 5: reticența
• Mitul și realitatea
• Concluzie
• Lectură recomandată

Importanța testării interfeței de utilizare a aplicației mobile

În calitate de utilizator, vrei să folosești o aplicație care nu are interacțiunea cu utilizatorul și îngreunează înțelegerea modului de utilizare?

Când utilizatorii folosesc o aplicație mobilă pentru prima dată, nu doar performanța atrage atenția, ci și interfața de utilizare atrăgătoare. O aplicație prietenoasă cu interfața de utilizare vinde mai mult în comparație cu o aplicație care este cel mai bine dezvoltată, dar cu o interfață de utilizare neplăcută.

Dacă o aplicație are o interfață de utilizare perfectă și splendidă pe un dispozitiv, dar pe celălalt dispozitiv este complet răsucită doar pentru că are o dimensiune diferită sau un sistem de operare diferit, atunci va lăsa o impresie foarte proastă. Succesul comercial al aplicației va fi grav afectat.

Veți promova o aplicație în care butonul este prea mic pentru a face clic, blocând întregul set de funcționalități?

Nu sunt aceste experiențe neplăcute pentru utilizatori? Datorită cazurilor menționate mai sus, devine foarte important să testați interfața de utilizare a unei aplicații. Cele două verificări majore care trebuie făcute pentru aplicațiile mobile sunt ușurința utilizatorului și aspectul diferitelor modele și versiuni ale sistemului de operare.

Următorul este un exemplu de modul în care interfața de utilizare ar trebui să fie perfectă pentru diferite dimensiuni de ecran:

Cum să decideți cât de mult este necesar testul UI?

Următorul grafic indică diferitele verticale în care pot fi clasificate aplicațiile mobile:

(imagine sursă )

Din graficul de mai sus, puteți constata că aplicațiile pentru jocuri iau cea mai mare parte a cotei de piață de aproximativ 24,43%, apoi sunt urmate de aplicațiile pentru afaceri și educație.

• Aplicațiile dezvoltate ca aplicații de jocuri au nevoie de teste amănunțite la fiecare aspect, întrucât interfața de utilizare este cel mai mare contribuitor la succes, indiferent dacă este o aplicație nativă sau hibridă
• Este posibil ca o aplicație de afaceri să nu se bazeze complet pe interfața de utilizare pentru succesul ei, deoarece în majoritatea cazurilor publicul țintă este instruit să folosească aplicația. Prin urmare, astfel de aplicații pot avea o interfață de utilizare simplă.
• Aplicațiile dezvoltate în scopuri educaționale necesită teste aprofundate ale interfeței de utilizare.
• Aplicațiile comerciale precum cumpărăturile, călătoriile etc. necesită, de asemenea, testarea completă a interfeței de utilizare a dispozitivelor și a diferitelor versiuni ale sistemului de operare.

Pe scurt, în funcție de scopul aplicației, se poate decide profunzimea testării UI, dar testarea UI ar trebui să se facă întotdeauna pe cel puțin 3 versiuni diferite ale sistemului de operare.

Instrucțiuni: Ce să testați în testarea interfeței de utilizare a aplicației mobile

În timp ce testați interfața de utilizare pe o aplicație mobilă, trebuie verificate diferite caracteristici.

Următoarele sunt câteva dintre caracteristicile care ar trebui testate pentru fiecare aplicație:

# 1) Rezolutia ecranului

Următoarele sunt câteva dintre rezoluțiile obișnuite ale ecranului care sunt luate în considerare la crearea de teste:

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

Toate aceste rezoluții sunt obligatorii pentru testare atunci când aveți un aspect cu mai multe coloane în aplicație.

Prin urmare, verificarea trebuie făcută începând de la cea mai mică până la cea mai mare rezoluție. În afară de aceasta, dacă aplicația dvs. are o listă lungă de carduri cu informații, atunci acestea trebuie, de asemenea, testate pe o altă rezoluție pentru împachetarea informațiilor.

( sursa imaginii )

# 2) Dimensiunea ecranului

Există prea multe variante în dimensiunile ecranului și rezoluțiile disponibile. În special pe dispozitivele inteligente, dimensiunile comenzilor nu sunt statice, ele au legătură cu dimensiunea ecranului disponibilă.

În timpul testării, asigurați-vă că dimensiunea comenzilor arată bine din punct de vedere estetic și că controlul este complet vizibil pe ecran, fără niciun fel de derulare. Testați interfața grafică pe diferite dispozitive cu dimensiuni și rezoluții diferite ale ecranului.

Emulatoarele sunt bune în acest scop, dar nimic nu se potrivește cu dispozitivul real. Deci, asigurați-vă că testați pe cel puțin două sau trei dispozitive reale. De asemenea, nu uitați să testați orientările peisaj și portret dacă dispozitivul îl acceptă.

Trebuie să testați aplicația conform rezoluțiilor utilizate în mod obișnuit pentru a asigura utilizarea sa.

Puține lucruri pe care trebuie să le înțelegeți aici sunt:

Diferența dintre dimensiunea ecranului și rezoluție: Dimensiunea ecranului este lungimea ecranului în inci măsurată în diagonală sau de la un colț la alt colț al ecranului. Rezoluția ecranului este lățimea și înălțimea, Exemplu 640w × 480h care reprezintă numărul de pixeli care traversează ecranul înmulțit cu mai mulți pixeli în jos.

# 3) Diferite elemente de interfață

Elementele UI, cum ar fi butoanele, titlurile, pictogramele, imaginile, câmpurile de selecție, câmpurile de text, casetele de selectare etc., sunt câteva dintre diferitele elemente care trebuie verificate pentru aspectul și dimensiunea lor pe ecran.

În special pentru câmpurile de text, dacă tastatura soft apare la atingere în câmpul de text ar trebui să fie testată și verificată.

Cel mai important, este necesară testarea amănunțită a dimensiunilor butoanelor, deoarece îmi amintesc în aplicația noastră în timp ce testam pe telefonul Galaxy S, am găsit un blocant în care un buton blocase întreaga aplicație doar pentru că butonul părea prea mic pentru a face clic.

Poziția elementelor de interfață ar trebui, de asemenea, verificată în raport cu cerința, adică dacă toate urmează să fie aliniate la centru sau la stânga etc.

# 4) Stil: Schema de culoare și temă a dispozitivului

Interfața de utilizare a aplicației și schema de culori trebuie să fie în concordanță cu diferite culori și scheme tematice ale telefonului. Culoarea și tema unui telefon Samsung sunt foarte diferite de cea a telefonului Nokia sau a telefonului MI .

Prin urmare, trebuie să verificați dacă aplicația arată constant pe astfel de telefoane.

Aplicația dvs. are un design specific. Și stilul comenzilor ar trebui să se potrivească cu acel design. Este posibil să fi văzut multe aplicații în care unele controale, de ex. panourile au margini rotunde și alte comenzi de ex. casetele de text au margini ascuțite.

Deși acest tip de probleme nu afectează utilizabilitatea sau funcționalitatea aplicației, totuși un aspect consistent al aplicației ajută la construirea unei relații prietenoase între aplicație și utilizator.

Unul dintre cele mai importante lucruri în stil este fontul diferitelor pagini. Fontul trebuie testat bine pentru a evita orice inconsecvență în aspectul aplicației.

De cele mai multe ori, ne concentrăm pe textul care este vizibil în situații normale și ignorăm textul care apare în situații specifice. Mesajele de succes și eșec sunt un exemplu de astfel de tip de text.

Un alt factor important în stil este relația dintre culoarea fontului și situația în care este afișat textul.

De exemplu, Culoarea roșie este utilizată pentru mesajele de eroare, verde pentru succes, galben pentru avertismente și albastru pentru hyperlinkuri.

# 5) Multi-touch sau Single touch

Dacă aplicația dvs. acceptă funcția multi-touch, cum ar fi pinch to zoom sau pinch to shr etc., atunci trebuie să testați temeinic această caracteristică și să creați o mulțime de cazuri de testare pentru toate ecranele aplicabile.

# 6) Apăsați lung sau scurt

O apăsare lungă pe o pictogramă afișează meniul contextual, în timp ce o atingere scurtă efectuează prima acțiune a meniului. Dacă această caracteristică este furnizată în aplicația dvs., atunci trebuie să verificați această funcționalitate și toate funcționalitățile din jurul acesteia.

# 7) Locație

Locația și poziția sunt cele două cuvinte care sunt utilizate alternativ și, în mod interesant, ele sunt folosite în continuare pentru a transmite două concepte diferite care sunt explicate mai jos:

1) Uneori este zona de pe ecran unde apare un control.

De exemplu, Antetul se află pe top din pagină, etichetele sunt Stânga aliniată și Casetele text sunt Drept aliniat, etc. Aici, „sus”, „aliniat la stânga” și „aliniat la dreapta” sunt poziții relative ale comenzilor.

Două) Uneori este ordinea controlului printre celelalte controale.

De exemplu, în timp ce primiți informații personale, prenumele este a urmat după numele de familie. Sau, formatul comenzilor pentru a solicita o adresă din SUA ar trebui să fie în Ordin - Cod poștal, oraș, stat.

conversia char în int c ++

Pentru ambele situații, vorbim despre locația comenzilor.

În timp ce testați locația și poziția comenzilor, asigurați-vă că totul este așezat logic pe ecran și prezintă un bun simț estetic.

Există situații în care unul sau mai multe comenzi apar pe mai multe ecrane. În această situație, trebuie să vă asigurați că acestea apar în aceeași locație și aceeași ordine relativă pe toate paginile.

Cum se testează variațiile UI în diferite versiuni ale sistemului de operare?

UI variază în funcție de versiunea sistemului de operare și odată cu lansarea unei noi versiuni, îmbunătățirile sunt făcute în UI.

Să observăm interfața de utilizare a celui mai recent 3 sistem de operare disponibil în prezent și să înțelegem cum afectează aceste variații o aplicație mobilă.

Sunt:

1. Acadea
2. Bezea
3. Nuga

Privind lista de mai sus a noilor interfețe UI sau funcționalități, ca un QA, trebuie să proiectați cazuri de testare în acest sens.

1) Lollipop:

• Creați cazuri de testare pentru efectul noului design asupra aplicației dvs.
• Nu neapărat pentru toate ecranele, dar creați cazuri de testare pentru accesarea noilor comenzi rapide din aplicația dvs.

2) Marshmallow:

• Dacă aplicația dvs. se ocupă de emoji-uri, creați cazuri de testare pentru a verifica noile emoji-uri. Aplicațiile care permit utilizatorilor să scrie recenzii sau să converseze prin chat sunt cele care folosesc frecvent emojis.
• Când aplicația dvs. este publicată și instalată pentru prima dată, este posibil să fie nevoie să solicite permisiunea, de aceea trebuie să se facă testarea interfeței pentru noul ecran de permisiune. Și creați cazuri de testare pentru același lucru.
• Dacă aplicația dvs. folosește Google Now, atunci trebuie să creați cazuri de testare pentru a testa interfața de utilizare actualizată a funcției Google Now.

3) Nougat:

• Testarea amănunțită a aplicației dvs. trebuie făcută pentru modul de realitate dreamdream și, prin urmare, creați cazuri de testare în consecință.
• Creați cazuri de testare pentru a verifica opțiunile de meniu pentru aplicația dvs.
• Dacă aplicația dvs. se ocupă de emoji-uri și GIF-uri, creați cazuri de testare pentru a verifica noile emoji-uri și opțiunea de a trimite GIF-uri.

Dispozitive reale sau emulatoare: ce să alegeți pentru testarea interfeței de utilizare?

Când trebuie să testați o aplicație mobilă, vă puteți gândi la ce ar trebui să fie testul?

Dacă doriți să testați pe un dispozitiv sau emulator real sau pe ambele? Nu există un răspuns ferm la acest lucru, deoarece alegerea depinde de ceea ce doriți să testați.

Pentru a testa funcționalitatea, performanța, răspunsul la rețea, testarea pe teren etc., ar trebui să preferați întotdeauna un dispozitiv real. Dar pentru lucruri precum interfața de utilizare ar trebui să alegeți emulatoare împreună cu unele dispozitive reale.

Pro

Avantajele utilizării emulatoarelor pentru testarea UI sunt:

1) Nu este practic posibil să colectați dispozitivele tuturor rezoluțiilor și acest lucru ar costa, de asemenea, o sumă enormă de bani. Dar emulatoarele nu costă nimic.
Două) Cu un emulator, puteți crea toate rezoluțiile ecranului și combinațiile de sisteme de operare.
3) Dacă aveți un singur set de dispozitive reale, dar echipa QA este mai mare de 1 persoană, atunci toate QA-urile nu pot testa același banc de test în paralel. Cu un emulator, fiecare QA poate crea aceeași combinație pe mașina lor și poate testa în paralel.
4) Testarea pe un emulator consumă mai puțin timp și este mai rapidă în comparație cu un dispozitiv real.
5) Erorile obișnuite legate de interfața de utilizare, cum ar fi alinierea etc., pot fi ușor surprinse de emulatoare.

Contra

Dezavantajele includ:

1) Gesturile nu pot fi testate pe emulatoare. Un singur gest poate fi imitat la un moment dat.
Două) De asemenea, nu pot fi testate intrările fizice ale GPS-ului, a rețelei de cădere sau slabe etc.
3) Nu puteți crea un emulator pentru telefoanele Sony, LG, Nexus etc.
4) Nu este posibil să creați un mediu real cu o baterie slabă sau cu memorie redusă etc., pe emulator.

Prin urmare, decizia ar trebui luată în funcție de aplicația dvs. și de cerințele de testare.

Testarea manuală sau automatizată a interfeței de utilizare?

Niciun produs, indiferent dacă este o aplicație desktop, o aplicație web sau o aplicație mobilă, nu poate fi lansat fără testare. În calitate de QA ne străduim să găsim și să raportăm fiecare defect, dar totuși, acestea sunt raportate de clienți.

Stii de ce?

Deoarece testele lungi care sunt adesea evitate sau ratate, lăsând astfel bug-uri nedetectate. De asemenea, acoperirea 100%, executarea în profunzime nu este posibilă cu testarea manuală.

Testarea interfeței de utilizare este destul de simplă și simplă și trebuie doar să te uiți la modul în care îți apare în ochi. Acum, dacă acest lucru se face manual, consumă mult timp. De asemenea, de cele mai multe ori trebuie să creăm date imense pentru testarea interfeței de utilizare, cum ar fi un scroll, vor apărea numai dacă rândurile de cărți traversează un anumit număr.

Crearea de date mari consumă mult timp. Dacă aveți o suită automată puteți rezolva ambele probleme.

Dimpotrivă, dacă funcționalitățile sau interfața de utilizare a aplicației sunt încă într-o fază în schimbare, atunci nu are sens să investim în automatizare. În mod similar, dacă funcționalitățile aplicației sunt vitale, atunci este mai bine să testați manual.

Prin urmare, în funcție de următorii indicatori, ar trebui să decideți dacă testați manual sau automatizați:

• Natura aplicației dvs.
• Stabilitatea aplicației dvs.
• Resursele disponibile, cum ar fi forța de muncă pentru a studia instrumentele și a le compara.
• Cât timp este investit studiul și extinderea unui instrument de automatizare care este necesar?
• Este clientul gata să investească timp în amplificare și să studieze?

Instrumente de testare a interfeței pentru aplicația mobilă

Urmează o listă cu 5 instrumente care pot fi utilizate pentru testarea interfeței de utilizare a unei aplicații mobile pentru Android și / sau iOS.

(Pentru instrumentele de testare a funcționalității y Puteți consulta lista de instrumente de automatizare din automatizarea noastră instrumente pentru testarea aplicațiilor Android pagină).

# 1) Selendroid

Selendroid este unul dintre cele mai bune și mai recomandate instrumente pentru automatizarea aplicațiilor mobile pentru testarea interfeței de utilizare.

Poate fi folosit atât pentru aplicații native, cât și pentru aplicații hibride. Poate fi utilizat numai pentru aplicațiile Android, iar testele API ale clientului sunt scrise folosind Selendroid 2. Poate fi utilizat și cu mai multe dispozitive și este pe deplin compatibil cu JSON.

# 2) Testdroid

Acesta este un instrument bazat pe cloud și poate fi utilizat pentru o varietate de dispozitive, rezoluții diferite de ecran și versiuni de sistem de operare atât pentru Android cât și pentru iOS. Testarea dispozitivelor în paralel este un mare avantaj al acestui instrument și este un instrument bun pentru testarea interfeței de utilizare. Ajută dezvoltatorii să îmbunătățească timpul de lansare pe piață.

# 3) SeeTest

Este un instrument plătit și poate fi utilizat pentru Android, iOS, Windows, Symbian etc.

Este un instrument multi-platformă și, prin urmare, avantajul este că același test poate fi rulat pe toate platformele. Poate fi utilizat pentru toate aplicațiile mobile, iar testele pot fi rulate în paralel pe mai multe dispozitive.

# 4) Automatizare UI

Acesta este instrumentul oficial de testare a UI pentru Apple și este cel mai bun instrument pentru automatizarea aplicațiilor iOS. Deși este greu de învățat, oferă un mare avantaj cu biblioteci, performanță, testare UI etc.

# 5) Calabash

Poate fi folosit atât pentru testarea Android, cât și pentru iOS pentru aplicații native sau hibride. Este un instrument multi-platformă și este cel mai bine utilizat pentru automatizarea gesturilor, capturilor de ecran, afirmații etc. Poate fi utilizat pe dispozitive cu ecran tactil real. Are și suport pentru castraveți.

Când dezvoltatorii testează aplicația, pot efectua teste de interfață utilizând Android Studio, dar aceasta poate fi utilizată numai pentru aplicații Android.

Lectură recomandată => Automatizează testele interfeței utilizatorului

Listă de verificare pentru testarea interfeței aplicației mobile

Mai jos este lista de verificare pentru testeri pentru a vă asigura că GUI este testat complet bine pe dispozitive inteligente:

5 mituri despre testarea automată a interfeței mobile

Testarea automată a interfeței de utilizare mobile este considerată crucială atunci când apare problema succesului aplicației. Dar există câteva mituri legate de testarea automată.

Este posibil ca astfel de mituri să nu fie adevărate, deoarece pot fi superficiale. Adâncirea în procesul de testare automată îl face să dispară. Să săpăm mai adânc în ele.

Mitul 1: Viteza

Acest mit este foarte comun. Majoritatea persoanelor legate de industriile IT au mitul că efectuarea „testării automatizării” necesită mai mult timp în comparație cu „testarea manuală”. Acest fapt este adevărat într-o oarecare măsură în câteva scenarii.

Motivul este că testarea manuală produce rezultate rapide în comparație cu testarea automată a interfeței mobile. Dar acesta este cazul doar în etapele preliminare și inițiale.

Cu testarea repetată, aveți nevoie fie de adăugarea a mult mai multe caracteristici de testare, fie de calitățile de testare diminuate. În timp ce cu testarea automată, rulați întotdeauna niveluri de testare similare de fiecare dată, rezultând astfel economisirea timpului pe termen lung.

Mitul 2: Acoperire

În scenariul actual, noile dispozitive Android sunt lansate în mod regulat pe piețe. Și numărul de aplicații ale unor astfel de sisteme de operare (SO) este în creștere. Apoi, există sisteme de operare precum iOS care au și mai multe aplicații destinate utilizării zilnice.

Testarea manuală pentru atâtea aplicații devine foarte dificilă. Dar, în cazurile de testare automată, este suficientă întreținerea serverelor cloud. Cu ajutorul testării automate, este posibilă acoperirea totală și completă a aplicațiilor.

Mitul 3: Cost

Este un fapt că testarea automată a aplicațiilor costă mai mult în comparație cu costurile testării manuale. Cu toate acestea, acest lucru este adevărat numai dacă se fac teste pentru elementele esențiale ale aplicației. Pe măsură ce mediul aplicației și software-ul se complică, testarea manuală devine mai costisitoare.

Acest lucru se datorează faptului că sunt necesare instrumente mai sofisticate pentru rezultate optime de testare. Împreună cu aceste instrumente de testare sofisticate, este nevoie de personal cu înaltă pregătire care să poată gestiona astfel de instrumente. Acest lucru va necesita formarea acestora.

Așadar, testarea manuală devine mai costisitoare în comparație cu una automată.

Mitul 4: Coerența

În cazul testării manuale, există întotdeauna loc pentru percepții diferite care variază de la un tester la altul. Acest lucru depinde, de asemenea, de testele luate în considerare, de medii și de aplicații împreună cu sistemul de operare (SO).

Când aplicați testarea manuală software-ului, există găuri prin care ar putea trece câteva bug-uri. Prin urmare, testarea manuală este bună numai pentru detectarea erorilor de bază. Testarea automată rulează pe scripturi, fără spațiu pentru percepții variate, ceea ce îl face infailibil.

Mitul 5: reticența

Nu este adevărat că testarea automată a înlocuit ființele umane, mai degrabă este pentru îmbunătățirea testerului manual. Testele automate oferă rezultate automatizate în mod repetat, de mai multe ori cu precizie maximă. Deci apare întrebarea, de ce este nevoie de oameni?

Testarea automată necesită scrierea de scripturi și planificarea întregii proceduri de testare. Această sarcină necesită efort uman. Procedura de testare automată vă ajută să economisiți timp și bani, astfel încât să utilizați astfel de resurse pentru îmbunătățirea procedurilor de testare manuală. Dezvoltarea unor instrumente mai bune va contribui, la rândul său, la avansarea procedurilor deja existente de testare automată.

Mai sus menționate sunt câteva dintre cele mai populare mituri existente care prevalează în industria testării automate. Acest lucru trebuie eliminat pentru îmbunătățirea testării automate a interfeței mobile.

Mitul și realitatea

Faptul este că chiar și cele mai sofisticate companii de dezvoltare folosesc teste manuale pentru telefoane mobile sau nu efectuează teste complete. Conform sondajelor Xamarin din 2014, 13,2% dintre dezvoltatorii de telefoane mobile efectuează teste fiind UI automatizate. Conform studiilor Forrester Research, doar 53% dintre dezvoltatori efectuează teste cursive pe dispozitive individuale.

Cinci factori cei mai comuni cu privire la motivele pentru care echipele de telefoane mobile nu au calități automatizate ale aplicațiilor mobile și cinci motive pentru care acestea nu au doar un sens real sunt următoarele:

a) Viteza este primul mit.

O persoană nu poate lua timp pentru automatizare. În anul 2014, furnizorii au introdus 7000 de noi tipuri de dispozitive Android. Apoi au existat 10000 API-uri care au fost specifice pentru telefoane mobile. Aplicația mobilelor se expediază mai repede și se modifică rapid. Cu asigurarea calității (QA) în moduri de crunching constante, nu există timp pentru crearea de scripturi de testare, la rândul lor, menținându-le în sincronizare cu caracteristicile care se schimbă în mod regulat.

Scenariul practic al primului mit:

În prezent, unul pierde timp prețios. Este foarte adevărat. Testarea manuală este mai rapidă decât testarea automatizată. Dar aceasta este pentru prima rundă de testare. În cursele ulterioare, orice beneficii marginale aduc testele manuale către eroziuni. Acest lucru este aproape imediat. Împreună cu toate testele repetate sau completările de funcții, dezvoltatorii de aplicații ar trebui fie să redimensioneze domeniul de testare, fie resursele de testare suplimentare.

Împreună cu bugetarea finită, acest lucru duce în cele din urmă la ciclurile vicioase ale acelor calități care se diminuează. Ca răspuns la angajamentele de date și recenziile negative ale utilizatorilor de pe dispozitive care nu sunt testate, echipele doresc o extindere a acoperirii dispozitivului. Acestea sporesc în continuare stresul asupra departamentelor de asigurare a calității deja ca capacități.

Este faptul că afacerea se luptă pentru întreținerea, cercetarea și procurarea dispozitivelor în timp ce efectuează execuții de testare. Chiar și cele mai bine finanțate programe manuale de testare a UI se scurtează până la acoperirea finalizată.

În SUA, echipele de dispozitive mobile necesită testarea pe 188 de dispozitive pentru a acoperi 100% din acțiunile de marketing. Conform cercetării Xamarin din 2014, majoritatea echipelor de dezvoltare testează frecvent pe 25 sau mai puține dispozitive.

Mai mult de un sfert din aceste comunități de dezvoltatori vizează cinci sau mai puține dispozitive. În situațiile de testare din lumea reală, automatizarea se plătește aproape instantaneu și imediat. La prima testare, se constată că consumatorii accelerează termenele de testare de 4 ori. Este peste o întreagă testare manuală atunci când alergă pe cincizeci sau mai multe dispozitive decât atât.

Rulările care se află în subsecvență au fost mult mai rapide. Cu toate acestea, există o scurtare pentru o săptămână de testare aproape completă la doar utilizări de câteva ore.

b) Acoperirea este al doilea mit.

Fragmentarea este cauza nicio posibilitate de a obține o acoperire extinsă a dispozitivului. Împreună cu mai mult de 19000 de dispozitive Android unice și permutarea a zeci pentru formarea sistemelor de operare și a factorilor pentru iOS, o mulțime de echipe cred că nu este posibilă acoperirea majorității dispozitivelor pe piețele furnizate.

Deci, există o testare implicită pe o mână de dispozitive destul de bune.

Realitatea celui de-al doilea mit:

S-ar fi putut finaliza acoperirea dispozitivului. În cazul în care oamenii întrețin dispozitivele în casă în mână, atunci fac multe. Achiziționarea dispozitivelor este dificilă.

Menținerea banilor, a costurilor și a timpului, la rândul lor, asigurarea disponibilității testerilor acolo unde și când este resimțită nevoia acestuia creează logjamuri logistice. Gartner afirmase că dezvoltatorii de dispozitive mobile ar trebui să găsească modalități de a obține rate de automatizare ridicate pentru a ține pasul cu ritmul și răspândirea schimbării platformei. Acest lucru fusese în găzduire. Diferite funcții au folosit managementul intern.

cum se scriu cazuri de testare manuale cu un exemplu

Calea către o astfel de automatizare este prin serviciile cloud ale terților. Serviciile cloud terțe ajută la automatizarea proceselor de încărcare a aplicațiilor, testarea executării scriptului, raportarea rezultatelor și restabilirea siguranței dispozitivelor pentru standardele fabricilor. Subseturile de teste ale aplicațiilor rulează în paralel, accelerând astfel rezultatele.

În timp ce testează pe o gamă largă de dispozitive reale, norii de testare permit tuturor echipelor să știe exact cum funcționează aplicația, la rândul său, eliminând presupunerile tipice ale dezvoltărilor mobile.

Exemplu: Managerii de produs stabilesc mai puține cerințe de sistem împreună cu confidențiale care se justifică în performanțele dispozitivelor. Dezvoltatorii primesc confirmări obiective vizuale ale remedierii erorilor înainte de angajamentul unor versiuni mai noi. Acest lucru este indiferent de locul și momentul în care operează.

c) Costul este al treilea mit.

Persoanele fizice își pot permite doar testarea manuală. Testarea automatizării necesită crearea de scripturi de testare, curbe de învățare pentru personalul QA și infrastructură. Multe echipe s-au luptat deja pentru a respecta termenele limită. Sunt deja peste buget. Deci, testarea automatizării pare a fi la distanță mare.

Scenariul practic pentru al treilea mit:

Testarea manuală economisește bani numai în cazul în care oamenii sacrifică acoperiri. Testarea manuală pare mai puțin costisitoare doar în majoritatea mediilor care sunt goale.

În cazul testării include „verificarea rapidă” a funcționalităților de bază ale mai puține dispozitive, atunci testarea manuală pare a fi chilipiruri. Dar orice asemănări cu acoperirea testului și dispozitivul cuprinzător vor face testarea manuală mult mai costisitoare decât testarea automatizată. Acest lucru ar putea fi rapid chiar.

Testarea manuală se mărește numai prin adăugarea mai multor persoane și mase. Costurile nu au nicio linearitate adevărată. Extinderea personalului pentru îndeplinirea cerințelor aduce cheltuieli extraordinare în ceea ce privește formele de coordonare și formare. Împărțirea cazurilor de testare reduce astfel eficiența tuturor testerilor prin eliminarea perspectivelor.

În plus, testerii care au suficientă sofisticare pentru a explora dincolo de comportamentele utilizatorilor, explorând și anticipând astfel motivele pentru care aplicațiile pot eșua, nu ar putea fi nici abundente, nici ieftine. Testarea automatizării necesită întotdeauna ceva mai multe cheltuieli generale în momentul configurării inițiale.

Dar, după cum sa menționat mai sus, poate produce câștiguri și profituri dramatic în ceea ce privește viteza de testare. De asemenea, produce reduceri corespunzătoare de personal în câteva zile. Mediile de testare bazate pe cloud au redus costurile în continuare. Acest lucru se întâmplă prin eliminarea infrastructurii de testare premise subutilizate și costisitoare.

d) Coerența va fi al patrulea mit.

Este suficient de bun pentru a fi condus, executat și operat. Pentru diferite echipe de testare, implementările gata sunt decizii subiective, bazate pe percepțiile multor testere manuale variate. Ei știu că sensul este că bug-urile cad prin crăpături.

Acoperirile de testare suprapuse trebuie să surprindă cele mai frecvente și critice probleme înainte de lansări. Restul erorilor așteaptă versiunile de întreținere.

Scenariul real al celui de-al patrulea mit:

Calitățile nu sunt calitative. Disponibilitatea producțiilor nu trebuie să fie factori și aspecte de opinie. Într-un mediu pur de testare manuală, percepțiile variază de la un test la altul și de la un tester la altul. Acest lucru duce la rezultate neregulate ale testelor și documentații incoerente.

Deciziile devin complicate atunci când sunt prezente considerații privind disponibilitatea produselor. Aceasta duce la eșecuri de conformitate, dezamăgirea maselor și pierderea veniturilor. În plus, există crearea unor buzunare de înțelegeri tribale necapturate care se pierd atunci când oamenii și angajații ies din ușă.

La rândul său, automatizarea creează valori cuantificabile. Acest lucru servește drept surse obiective ale adevărului pentru informarea deciziilor cu privire la justificarea deciziei de afaceri, disponibilitatea produsului și progresul echipelor grafice.

e) Reticența este al cincilea mit.

Testarea manuală a fost înlocuită de testarea automatizată. Mulți dezvoltatori diferiți au acces la automatizarea testelor, deoarece se așteaptă să înlocuiască testerii manuali cu mașini.

În cazul în care automatizarea testelor repetă teste similare de 1000 de ori cu precizie de 100%, atunci apar întrebări cu privire la motivul pentru care există necesități ale oamenilor în scopul testării. Automatizarea scripturilor de testare poate fi făcută și de mașini.

Imaginea în timp real a celui de-al cincilea mit:

Testerele manuale devin mai bune odată cu testarea automatizată. Mașinile și oamenii posedă scenarii bune cu multe lucruri și factori diferiți. Testerii, care fac testări manuale, pot testa întotdeauna mai creativ.

Testarea automatizării îi eliberează de acest lucru. În timp ce oamenii așteaptă cu nerăbdare modalități mai noi de a sparge aplicațiile, automatizarea asigură conformitatea pe o gamă largă de dispozitive. Aceasta este de la teste unitare până la teste complete de regresie. 2 abordări nu trebuie să funcționeze izolat.

Efectuarea testelor fiind manual exploratoriu, în timp ce sistemele back-end nu au fost supuse sarcinilor testelor automate. Acestea sunt modalități excelente de descoperire a erorilor care apar în medii de producție. Testarea automată nu înlocuiește testerii care sunt oameni. Acest lucru le permite să desfășoare o muncă plină de satisfacții și interesantă.

O mai bună consistență, acoperire, cost și viteză se adaugă acelor calități îmbunătățite. Economisind bani și timp înseamnă că poți face mai multe teste și nu mai puține. Acesta este cazul când se atinge repere fiind critici. Acest lucru permite testarea să țină pasul împreună cu echipe de dezvoltări agile în loc să stea în moduri.

Deci, organizațiile eliberează codul mult mai frecvent. Acest lucru reduce impactul și cantitățile de defecte sunt date construcții. Aceasta înseamnă că dezvoltatorii lucrează cu coduri curate. Remedierea erorilor a fost mai puțin complicată dramatic. Acest lucru eliberează testerii prin acțiunea exclusivă, întrucât gardienii se concentrează asupra creativității. Testarea exploratorie îmbunătățește astfel calitățile produselor.

Testarea automatizată a interfețelor mobile oferă avantaje în ceea ce privește timpii și calitățile. Instrumente care sunt automatizate, facilitând testerilor evaluarea interfețelor utilizatorilor aplicațiilor prin game extinse de dispozitive mobile, împreună cu modificări pentru îmbunătățirea ușoară a experiențelor utilizatorilor.

Concluzie

Un GUI Bad este o experiență neplăcută pentru utilizator. Testarea GUI este extrem de recomandată și importantă mai ales atunci când vine vorba de dispozitive inteligente, deoarece aici dimensiunea ecranului este relativ mică și o mulțime de variații ale dispozitivelor sunt disponibile pe piață.

Aplicația dvs. poate arăta și se comportă diferit pe diferite dispozitive. Deci, este important să testați aplicația pe cel puțin unele dimensiuni și variații standard ale dispozitivelor.

Toate aplicațiile mobile necesită testare UI, dar profunzimea testării necesare este definită de categoria sau scopul aplicației. Ar trebui să faceți o analiză completă a caracteristicilor UI ale aplicației în raport cu modelul telefonului sau cu versiunile de sistem de operare înainte de a vă finaliza bancul de testare.

Pe baza acestei analize, ar trebui să creați cazurile de testare pentru testare. Folosiți automatizarea ori de câte ori este posibil pentru a economisi timp.

Păstrați un ochi deschis în timp ce testați interfața de utilizare, deoarece este simplă, dar are un efect mare asupra vânzării aplicației dvs.

Aruncați o privire la viitorul nostru tutorial pentru informații detaliate despre Test de răspuns mobil .

Lectură recomandată

• Tutorial Appium pentru testarea aplicațiilor mobile Android și iOS
• TOP 15 Cele mai bune instrumente de testare mobilă în 2021 pentru Android și iOS
• Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
• Servicii de testare beta pentru aplicații mobile (instrumente de testare beta pentru iOS și Android)
• De ce testarea pe mobil este dificilă?
• Noțiuni introductive despre Robotium - Cel mai popular instrument de testare a aplicației UI pentru Android
• Descărcare eBook Descărcare Primer
• Cele mai bune 11 instrumente de automatizare pentru testarea aplicațiilor Android (instrumente de testare a aplicațiilor Android)