Dispozitivele iOS încă revendică o parte semnificativă a pieței mobile, ocupând până la 22% din vânzări la nivel global. Pe măsură ce mulți clienți devotați se întorc pentru noi produse Apple, există, de asemenea, o cerere mare de aplicații iOS. În acest articol, ne vom ocupa de asigurarea calității aplicațiilor iOS, străduindu-ne să folosim cele mai bune practici folosind instrumentele Appium, Cucumber și Serenity.

Structura

Modelul obiectului de pagină este una dintre cele mai bune abordări de testare pe care inginerii de asigurare a calității o pot aplica unui proiect de automatizare a testelor. Este un astfel de mod de structurare a codului într-un proiect de automatizare care îmbunătățește calitatea și lizibilitatea codului, întreținerea testelor și, pe deasupra, este o modalitate excelentă de a evita haosul. Ideea de bază din spatele ei vine din păstrarea tuturor referințelor la elementele mobile și a metodelor care efectuează operații asupra acestora într-un singur fișier de clasă pentru fiecare pagină sau ecran al aplicației (sau pagină web pentru aplicațiile web non-native).

Ce beneficii are această abordare, vă veți întreba? În primul rând, ea face ca automatizarea să fie foarte simplă. Practic, înseamnă să găsim elemente în aplicația noastră iOS prin intermediul inspectorului și apoi să efectuăm operațiuni asupra lor. Un alt avantaj principal este structura coerentă a proiectului, care permite oricui să navigheze rapid prin el.

Să luăm exemplul unei aplicații care conține rețete. Aceasta afișează cartea de bucate implicită cu rețete de bază la pornire, care va fi prima noastră pagină. De acolo, un utilizator poate naviga către orice rețetă disponibilă, marcând astfel o a doua pagină. În plus, aplicația permite, de asemenea, să navigheze în alte cărți de bucate sau să le achiziționeze pe cele premium, ceea ce face ca aceasta să fie a treia pagină și, în consecință – un fișier obiect de pagină.

În mod similar, ar trebui să creăm fișiere de definire a pașilor corespunzători. Aceasta nu este o practică obligatorie, dar păstrarea tuturor definițiilor pașilor într-un singur loc provoacă un haos inutil.

În timp ce creați paginile și fișierele de clasă de definiție a pașilor este recomandat să alegeți nume care să aibă legătură cu pagina (ecranul aplicației) al cărei conținut veți lucra. Denumirea acestor fișiere după o caracteristică sau un scenariu poate părea corectă la prima vedere, dar, pe măsură ce proiectul se extinde, veți observa din ce în ce mai multă dezordine în structura sa. Adoptarea convenției de denumire a paginilor asigură faptul că oricine este implicat în proiect se poate familiariza imediat cu acesta și poate începe să colaboreze la el în cel mai scurt timp. O astfel de practică contribuie, de asemenea, la reutilizarea codului – fie că este vorba de definiții ale pașilor sau de metode/funcții.
În mod contrar fișierelor de definire a pașilor și etapelor menționate, fișierele de caracteristici Cucumber ar trebui să fie denumite după o caracteristică pe care o verifică. Inteligent, nu-i așa? Și, din nou, structurarea lor în directoare denumite în legătură cu un anumit domeniu al aplicației testate va face ca structura să fie mai semnificativă.
Conceptul de bază al Serenity este acela de a fi o „documentație vie”. Prin urmare, dând scenarii de testare și fișiere de caracteristici cu nume corespunzătoare ajută echipa și părțile interesate să înțeleagă mai bine rapoartele și întregul proiect.

Un alt ingredient care extinde beneficiile modelului Page Object Model în proiectul de automatizare a testelor este PageFactory. Acesta este un instrument care vă ajută să reduceți munca de codificare și să puneți cu ușurință localizatori MobileElements în cod, folosind notația @FindBy. De acolo, găsirea elementelor pentru ca Appium să interacționeze cu ele în teste este mult mai simplă.

Assertion

Executarea testelor prin Appium poate consuma foarte multe resurse. Pentru a face lucrurile mai ușoare pentru mașina MacOS care execută teste pe dispozitivul iOS, asigurați-vă că nu afirmați în mod constant vizibilitatea tuturor obiectelor de pe o pagină. Această practică mărește semnificativ timpul de execuție a testelor, ceea ce, de obicei, nu este cel mai de dorit lucru.

În plus, atunci când trebuie să verificați dacă un element este vizibil, activat, pe care se poate face clic sau orice altceva între acestea – încercați să evitați să localizați elementele mobile utilizând Xpath. Sfatul inspectorului Appium are un punct de vedere valabil! Ar trebui să faceți tot ce puteți pentru a convinge echipa de dezvoltare să facă un efort suplimentar și să atribuie ID-uri și nume unice elementelor din aplicație. Acest lucru nu numai că va face testele de automatizare mai ușoare și mai rapide, dar, în consecință, va face ca munca dvs. ca tester să fie mai eficientă, ceea ce va duce în cele din urmă la creșterea calității generale a produsului. Și acesta este motivul pentru care suntem aici. Ca să nu mai vorbim de faptul că întreținerea testelor (de exemplu, trecerea la diferiți localizatori atunci când este necesar) va deveni mult mai plăcută.

Înțelegerea pașilor

Un alt aspect al configurării acestui tip de proiect se reduce la a profita de Cucumber și la utilizarea limbajului Gherkin.

Gherkin implementează o abordare directă cu notația Given, When, Then cu ajutorul adiționalelor And și But care pare destul de ușor de utilizat. Ați putea scrie cam tot ce doriți în etapele de testare din fișierele de caracteristici. În cele din urmă, metodele apelate vor efectua acțiuni.

Dar motivul pentru care se folosește abordarea Behavior Driven Development și Cucumber în sine este acela de a permite persoanelor non-tehnice implicate în proiect să înțeleagă ce se întâmplă în domeniul testelor. Nu numai atât, scrierea scenariilor de testare în maniera Given/When/Then poate, de asemenea, acționa în avantajul dumneavoastră. Astfel de descrieri de test de nivel înalt furnizate de client sau de analistul de afaceri vă vor face să codificați în cel mai scurt timp, cu condiția ca acestea să fie scrise corect. Iată câteva sfaturi utile:
Scenariile de testare scrise în Gherkin ar trebui să se concentreze pe comportamentul aplicației (de aici Behavior Driven Development).
Iată un exemplu despre cum să NU scrieți scenarii de testare în Gherkin, explorând în continuare tema aplicației cookbook:

Exemplul de mai sus ilustrează două practici proaste pe care ar trebui să le evităm: Se concentrează pe implementare în loc de comportament și folosește valori codificate în mod dur în loc să scrie pașii de testare în așa fel încât să permită reutilizarea prin schimbarea valorilor în cadrul unui pas.

Din acest motiv, un scenariu adecvat privind achiziționarea unei cărți de bucate în aplicația noastră de exemplu ar trebui să arate astfel:

Un alt exemplu:

Adoptarea acestei abordări înseamnă mai puțină muncă de creare și codificare a pașilor de testare ori de câte ori se schimbă implementarea unei anumite caracteristici.

În afară de notația principală de Given/When/Then, Cucumber suportă utilizarea pașilor de conjuncție. Utilizarea notațiilor pașilor And și But va face ca pașii de testare să fie mai generali și reutilizabili, ceea ce duce la scrierea mai puțin cod și la menținerea ordinii în cadrul proiectului. Iată un exemplu de bază:

În acest fel, dacă codificați pasul „Given” de mai sus pentru a localiza elementul nostru de rețetă prin căutarea numelui său, îl puteți reutiliza de mai multe ori doar schimbând valoarea șirului de caractere în pas (cu condiția să codificați corect definiția pasului ulterior). În plus, pasul ‘And’ poate face parte din orice scenariu de testare care implică o astfel de acțiune.

Punând totul laolaltă

După ce ați configurat un proiect utilizând practicile descrise mai sus, cele mai vizibile părți ale utilizării Serenity sunt rapoartele de testare generate. După adoptarea tag-ului @RunWith(CucumberWithSerenity.class) în fișierul dvs. de clasă TestRunner, rularea suitei de teste va avea ca rezultat generarea de către Serenity a unui raport agregat cu rezultatele testelor, care poate fi util în evaluarea calității aplicației testate și în prezentarea stării produsului către părțile interesate sau către echipa de dezvoltare.

Appium, Cucumber, Serenity – Rezumat

După cum puteți vedea, conceptul de bune practici în testarea automatizării poate fi rezumat în trei cuvinte: reutilizabilitate, lizibilitate și performanță. Reutilizabilitatea înseamnă mai puține codificări, diminuând, în consecință, timpul necesar pentru finalizarea lucrării. Lizibilitatea îmbunătățește înțelegerea, ceea ce este crucial pentru a ne asigura că produsul face ceea ce trebuie să facă. În cele din urmă, performanța economisește timp de execuție și îmbunătățește stabilitatea. Toate trei contribuie nu numai la calitatea proiectului de automatizare a testelor, ci au un rol semnificativ în creșterea calității generale a aplicației livrate.

.