Îmi imaginez că este posibil să scriu scripturi care interacționează automat cu aplicația dvs. iOS și să poată verifica rezultatele. Cu automatizarea UI puteți. UI Automation este un instrument oferit de Apple pentru a efectua un nivel mai ridicat de testare în aplicația dvs. iOS dincolo de ceea ce se poate realiza cu XCTEST.
1. Cutie albă față de testarea casetei neagră
Este posibil să fi auzit comparația testelor cu casetă albă împotriva testelor cutiei negre față de modul în care ar putea fi testat o bucată de software. Dacă nu sunteți familiarizați cu aceste concepte, permiteți-mi să vă explic cum funcționează.
Testarea pe caseta albă
Imaginați-vă că există o bucată de software care rulează în interiorul unei casete. Cu teste cu cutie albă, puteți vedea în interiorul casetei și vedeți toate piesele despre modul în care funcționează software-ul și apoi luați decizii informate cu privire la modul de testare a software-ului. De asemenea, puteți avea cârlige de nivel mai profund în software-ul de testare pe care îl scrieți.
Testarea unității este un test albă. La scrierea testelor unității, testerul are acces detaliat la codul testat. Verificatorul poate scrie într-adevăr teste care profită de software-ul testat în metodă sau unitate, nivel.
În dezvoltarea software-ului iOS, folosim cel mai XCTER cadru pentru a efectua acest tip de testare. Uitați-vă la un alt tutorial pe care l-am scris despre cum să începem cu XCTEST.
Testul Black Box
în testele cutiei negre, caseta este opacă. Testerul nu se poate vedea în interiorul casetei. Testerul nu poate accesa și nu știe despre implementarea codului de bază pentru a scrie teste. În schimb, testerul este forțat să utilizeze aplicația ca utilizator final ar interacționa cu aplicația și așteaptă răspunsul său, verificând rezultatele.
Există cel puțin două moduri de a executa acest tip de testare.
- un tester care efectuează în mod repetat și manual o serie de pași predefiniți și verifică vizual rezultatele.
- Utilizați unelte specializate pentru a testa aplicația cu API care se comportă de formă similară cu privire la modul în care se comportă O ființă umană interacționează.
În dezvoltarea aplicațiilor iOS, Apple oferă un instrument numit Automatizare UI pentru a efectua teste pe caseta neagră.
2. Care este UI-ul Automatizare?
UI Automation este un instrument pe care Apple oferă și menține pentru un nivel mai ridicat al aplicațiilor IOS automatizate. Testele sunt scrise în JavaScript, aderarea la un API definit de Apple.
Scrierea testelor pot fi simplificate atunci când se bazează pe etichetele de accesibilitate pentru elementele de interfață utilizator în aplicația lor. Nu vă faceți griji, dacă nu aveți aceste definiți, există alternative disponibile.
API de automatizare UI nu are formatul tipic bazat pe xunit pentru a scrie teste. O diferență cu testele unității este că testerul trebuie să înregistreze manual succesul și eșecurile. Testele de automatizare UI sunt rulate de la instrumentul de automatizare din cadrul instrumentului Instrumente care vine cu instrumentele de dezvoltatoare ale Apple. Testele pot fi executate în simulatorul iOS sau pe un dispozitiv fizic.
3. Scrieți UI Teste de automatizare
Pasul 1: Deschideți proiectul de exemplu
Am actualizat proiectul de exemplu utilizat în tutorialul anterior privind testele IOS cu câteva elemente suplimentare ale interfeței de utilizator care oferă câteva cârlige utile pentru a adăuga teste de automatizare UI. Descărcați proiectul GitHub. Deschideți proiectul și executați aplicația pentru a vă asigura că totul funcționează conform așteptărilor. Ar trebui să vedeți o interfață de utilizator similară celei de mai jos.
Înainte de a scrie orice Testați, nu ezitați să încercați cererea de eșantionare pentru a se familiariza cu funcționalitatea acestuia. În calitate de utilizator, puteți introduce textul în câmpul de text și apăsați butonul pentru a vizualiza o etichetă de pe ecran care afișează lanțul inversat introdus.
Pasul 2: Creați o automatizare UI
Acum că sunteți familiarizați cu aplicația de probă, este timpul să adăugați un test de automatizare UI. Automatizarea UI este un instrument care poate fi găsit la instrumente. Pentru a rula aplicația de probă a instrumentului, selectați produsul > Profil în meniul XCODE. Selectați Automation din lista de instrumente.
Fereastra principală a instrumentului se va deschide cu un singur instrument gata de rulare, Instrumentul de automatizare (instrumentul de automatizare execută cazurile de testare de automatizare UI). Veți vedea, de asemenea, o zonă în jumătatea inferioară a ferestrei care arată ca un editor de text. Acesta este editorul de script. Aici veți scrie testele de automatizare a UI. Pentru acest prim test, urmați instrucțiunile de mai jos, adăugând fiecare linie la script din editorul de script.
Începeți prin stocarea unei referințe la câmpul de text într-o variabilă.
DIV id = ” 8E33129345 „>
setați valoarea câmpului de text.
inputField.setValue("hi”);
Verificați dacă valoarea a fost setată corect și, dacă A fost, treceți testul. Nu reușiți testul dacă nu a fost așa.
if (inputField.value() != "hi") UIALogger.logFail("The Input Field was NOT able to be set with the string!");else UIALogger.logPass("The Input Field was able to be set with the string!");
În timp ce acest test este destul de trivial, are valoare. Tocmai am scris un test care dovedește prezența unui câmp de text atunci când aplicația este aruncată și testați dacă un șir aleatoriu poate fi stabilit ca valoare a câmpului de text. Dacă nu mă credeți, ștergeți câmpul de text Storyboard și executați testul. Veți vedea că nu reușește.
Acest test demonstrează trei un sistem important de scriere a testelor de automatizare ale interfeței cu utilizatorul. În primul rând, vă arată cum să accesați un element simplu de interfață utilizator, câmpul de text. În mod specific, accesăm un dicționar al tuturor câmpurilor de text din vizualizarea de bază a aplicației prin target.frontMostApp().mainWindow().textFields() și apoi căutăm câmpul de text care ne interesează atunci când căutăm cea care are cheia Input Field. Această cheie este de fapt eticheta de accesibilitate a câmpului de text. În acest caz, acesta este definit în scriptul grafic. De asemenea, putem seta eticheta de accesibilitate în cod utilizând proprietatea în iv id = „F9F4159974” .
acces la principalul ferestrei a aplicației, aplicația cea mai frontală și obiectivul sunt frecvente atunci când lucrează cu automatizarea interfeței cu utilizatorul. Vă voi arăta cum să faceți acest lucru mai ușor și mai puțin detaliat mai târziu în acest tutorial.
În al doilea rând, acest lucru vă arată că puteți interacționa cu elementele interfeței de utilizator de pe ecran. În acest caz, stabilim valoarea câmpului de text, imităm utilizatorul care interacționează cu aplicația la introducerea textului în câmpul de text.
și al treilea, exemplul arată, de asemenea, o tehnică pentru a verifica ce se întâmplă în aplicația. Dacă valoarea este stabilită cu succes, testul trece. Dacă valoarea nu este setată, testul nu reușește.
Pasul 3: Salvați testele
În timp ce testele de scriere în editorul de script este convenabil, devine rapid greoaie și greu de greu menţine. Dacă lăsați instrumente, orice schimbare nesalvată este aruncată. Trebuie să păstrăm testele pe care le scriem. Pur și simplu copiați și lipiți testul într-un document nou în editorul de text preferat și salvați-l. Puteți găsi testele create în acest tutorial în proiectul de exemplu în Jumblify / JumblifyTS / Automations.js.
Pentru a rula testul, selectați fila Medium din panoul din dreapta, lângă editorul scripturilor, și selectați Adăugați > Import. > Vi se va cere să selectați scriptul la import. Navigați la scriptul salvat și imprimați-l. Puteți schimba în continuare scriptul în editorul de script. Orice modificare va fi salvată automat în fișierul extern pe care l-ați creat.
Pasul 4: Atingând un buton
, ne actualizăm testul pentru a testa interacțiunea cu butonul. Testul nostru adaugă deja text în câmpul de text, deci trebuie doar să adăugăm codul pentru a atinge butonul. Luați în considerare mai întâi cum să găsiți butonul din vedere, astfel încât să puteți atinge. Există cel puțin trei moduri de a realiza acest lucru și fiecare abordare are compensația sa.
Focus 1
Putem programa prin programarea unei coordonate (x, y) pe ecran . Facem acest lucru cu următoarea linie de cod:
divid id = „46585DD4dd”>
Desigur, nu am nicio idee dacă acestea sunt chiar coordonatele butonului Ecran și nu mă voi face griji pentru asta, deoarece această abordare nu este instrumentul potrivit pentru această lucrare. Menționez doar că știi că există. Utilizați metoda în target Pentru a atinge un buton este predispus la erori, deoarece acest buton nu este întotdeauna găsit în acea coordonate specifice.
Focus 2
Este, de asemenea, posibilă găsirea butonului care caută pe matricea butonului din fereastra principală, în mod similar cu modul în care accesați câmpul de text în primul test.În loc să acceseze direct butonul utilizând o tastă, putem recupera o matrice de buton în fereastra principală și codifică un indice matrice pentru a obține o referință la buton.
target.frontMostApp().mainWindow().buttons().tap();
Această abordare este puțin mai bună. Nu codificăm o coordonată, dar codificăm un index de matrice pentru a găsi butonul. Dacă adăugăm un alt buton pe pagină, puteți rupe accidental acest test.
Focus 3
Acest lucru mă duce la a treia modalitate de a găsi butonul de pe pagină, folosind etichete de accesibilitate Folosind o etichetă de accesibilitate, putem accesa direct butonul, mi-a plăcut pur și simplu să găsesc un obiect într-un dicționar cu o cheie.
target.frontMostApp().mainWindow().buttons().tap();
Totuși, totuși, totuși, Dacă adăugați linia anterioară la script și executați-o, veți obține o eroare.
Aceasta trebuie de ce nu am definit eticheta de accesibilitate pentru buton. Pentru a face acest lucru, mergeți la Xcode și deschideți povestea proiectului. Căutați butonul din vedere și deschideți Inspectorul de identitate din dreapta (Vizualizați > Utilități >
pentru rulare Testarea din nou, trebuie să rulați aplicația de la Xcode selectând produsul > și apoi evidențiați aplicația din nou prin selectarea produsului > Profil. Acest lucru execută testele și fiecare încercare trebuie să se întâmple acum.
Pasul 5: Verificați șirul jumbled (lanțul murdar)
Așa cum am menționat mai devreme, aplicația noastră ia un șir ca intrare și, când Utilizatorul atinge butonul, acesta arată șirul inversat. Trebuie să adăugăm încă un test pentru a verifica dacă lanțul de intrare a fost inversat corect. Pentru a verifica dacă UILabel este plin de lanțul corect, trebuie să ne dăm seama cum să se refere la UILabel și verificați afișarea lanțului. Aceasta este o problemă comună atunci când scrieți teste de automatizare, adică să dau seama cum să se refere la un element din aplicație pentru a face o afirmare despre aceasta.
Există o metodă în aproape toate obiectele din API Automatizarea interfeței cu utilizatorul, logElementTree. Această metodă înregistrează elementele imbricate ale unui element dat. Acest lucru este foarte util să înțelegem ierarhia elementelor din aplicație și să ajute la determinarea modului de orientare a unui element specific.
Să vedem cum funcționează acest lucru prin înregistrarea arborelui element din fereastra principală. Uitați-vă la următoarea linie de cod.
target.frontMostApp().mainWindow().logElementTree();
Adăugați această linie la rezultatele scriptului de testare:
Cum puteți vedea, există un sub-element UIAStaticText al al și puteți vedea și că aveți un nume de ih, Care este și șirul inversat pe care trebuie să-l verificăm. Acum, pentru a finaliza testul nostru, trebuie doar să adăugăm codul pentru a accesa acest element și pentru a verifica dacă este prezent.
De ce trebuie doar să verificăm dacă elementul IV id = „4eACF40267” este prezent? Deoarece numele elementului este lanțul inversat al lanțului de intrare, verificarea prezenței sale confirmă faptul că secvența a fost investit corect. Dacă elementul nu există atunci când referința se face după nume, șirul inversat, înseamnă că șirul nu a fost inversat corect.
DIV id = „EA137EB515”>
4. Scratarea Suprafață
Există multe alte modalități în care un utilizator final poate interacționa cu un dispozitiv iOS în timp ce utilizează aplicația sa. Aceasta înseamnă că există multe alte modalități pe care le puteți utiliza UI UI pentru a simula aceste interacțiuni. În loc să încerce să surprindă o listă completă a acestor interacțiuni, voi merge la documentația de referință a automatizării UI.
Pentru fiecare tip de obiect cu care puteți interacționa, puteți vedea lista metodelor disponibile în acest sens obiect. Unele metode sunt de a recupera atributele despre obiect, în timp ce altele sunt de a simula interacțiunea tactilă, cum ar fi flickInsideWithOptions în UIAWindow.
Înregistrarea unei sesiuni
În timp ce încercați să încercați aplicații din ce în ce mai complicate cu automatizarea UI, veți vedea că uneori este destul de plictisitor să utilizați în mod repetat logElementTree Pentru găsirea elementului pe care îl căutați.Acest lucru devine, de asemenea, plictisitor și complex pentru aplicații cu o ierarhie complexă de vizualizare sau navigație. În aceste cazuri, puteți utiliza o altă funcție a instrumentului pentru a înregistra un set de interacțiuni de utilizator. Ceea ce este și mai mare este că instrumentele generează codul JavaScript de automatizare a interfeței cu utilizatorul necesar pentru a reproduce interacțiunile înregistrate. Acesta este modul în care îl puteți încerca singur.
în instrumente și cu instrumentul de automatizare selectat, căutați butonul de înregistrare din partea de jos a ferestrei.
P > 
Dacă faceți clic pe butonul de înregistrare, instrumentele vor porni o sesiune de înregistrare așa cum se arată în ecranul următor.
Instrumentele vor lansa aplicația dvs. în simulatorul iOS și pot interacționa cu acesta. Instrumentele vor genera un script pe baza interacțiunilor lor în timp real. Incearca. Întoarceți simulatorul iOS, atingeți locațiile aleatorii, faceți un gest glisant etc. Este un mod foarte util de a ajuta la explorarea posibilităților de automatizare a UI.
Evitați codul monolit
După cum puteți prevedea, dacă vom continua să adăugăm mai multe teste la testare Fișierul pe care l-am creat cu aceeași metodă, va fi dificil de întreținut. Ce putem face pentru a preveni să se întâmple asta? În testele mele, fac două lucruri pentru a rezolva această problemă:
- Un test pentru o funcție: aceasta implică faptul că testele pe care le scriem ar trebui să se concentreze pe o anumită funcție de funcționalitate. Vă voi da chiar un nume adecvat, cum ar fi
testEmptyInputField. - Gruparea testelor asociate dintr-un fișier: De asemenea, gruparea testelor legate de același fișier. Acest lucru păstrează codul într-un fișier ușor de gestionat. Acest lucru facilitează, de asemenea, să se testeze separat părțile funcționalității prin executarea testelor într-un anumit fișier. În plus, puteți crea un script principal în care numiți funcțiile sau testarea pe care ați grupat-o în alte fișiere de testare.
În următorul fragment de cod, importăm un fișier JavaScript și acest lucru Funcții în acest fișier JavaScript sunt disponibile pentru noi.
#import "OtherTests.js”
Concluzie
În acest tutorial, ați învățat valoarea lui Teste de nivel superior și modul în care automatizarea UI poate ajuta la umplerea acelui vid. Este un alt instrument din caseta dvs. de instrumente pentru a vă asigura că trimiteți aplicații fiabile și robuste.