Structura capitolului “Prezentarea Aplicatiei”

1. Informatii generale
2. Componente folosite
3. Prezentarea aplicatiei
3.1 Crearea proiectului
3.2 Primul Test
3.3 TestNG – Test Suite
3.4 TestNG - Adnotari
3.5 Creare Test LogIn folosind Page-Object-Model si Selenium Assertions
3.6 Primul test negativ
3.7 Al doilea test negativ folosind TestNG – Data Provider
3.8 Adaugarea si rularea testelor in Google Chrome folosind TestNG - Parameter
3.9 Teste paralele
3.10 Vizualizarea rezultatelor folosind Apache Log4j
3.11 TestNG – Test Listeners

Total pagini: 20

Total imagini: 22

Total tabele: 2

Font: Times New Roman

Font Size: 11

Line and Paragraph Spacing: 1.5

Prezentarea temei : Aplicatii pentru implementarea calitatii software

Informatii generale

Acest capitol contine informatii privind tehnologiile folosite in realizarea unui framework de testare
automata, detalii si informatii legate de construirea si implementarea codului, pentru aplicarea unor teste
asupra unei anumite pagini web, cu scopul de a obtine rezultate favorabile.

Pentru crearea unui set de teste automate, am folosit mediul de dezvoltare integrat “Eclipse”,
versiunea Java Photon 2018, limbajul de programare Java si de asemenea, Selenium WebDriver, un set de
libarrii pentru automatizarea browserelor, pentru o buna comunicare cu acestea: Mozilla Firefox si Google
Chrome. Pe langa tehnologiile de baza, am folosit: TestNG (Test Next Generation), pentru o scriere mai
rapida de test case-uri si pentru a putea rula testele in paralel, si Apache Maven pentru o varietate de librarii
si date, usor de prelucrat si pus in practica.

Framework-ul realizat cuprinde un set de teste, atat positive, cat si negative, care au ca scop
obtinerea unor rezultate favorabile in urma rularii, pentru a verifica mici parti ale unei pagini web. In urma
rularii testelor, rezultatele acestora pot fi verificate in Consola aplicatiei (Eclipse) pentru o buna observare
a pasilor urmati, cat si pentru o comparare efectiva a timpilor de rulare a testelor in doua browsere diferite,
atat consecutive cat si in paralel.

Componentele folosite

In aceasta sectiune sunt enumerate componentele de care am avut nevoie inca de la primul pas,
pentru a realiza cu success testele automate. Fiecare componenta a jucat un rol mai mult sau mai putin
important, vital sau pentru facilitarea proceselor. In ordinea instalarii si utilizarii, urmeaza:

Java Development Kit (JDK) este o implementare a unor platforme: Java Edition, Standard
Edition, Java Platform, Enterprise Edition, etc. lansate de Oracle Corporation sub forma unui produs binar
destinat dezvoltatorilor Java pe platforme Solaris, Linux, macOS sau Windows. JDK include o JVM (Java
Virtual Machine) privata și alte câteva resurse necesare pentru a finaliza dezvoltarea unei aplicații Java. De
la lansarea acestei platforme, a fost de departe cel mai utilizat kit pentru dezvoltarea de aplicatii software.
Pe 17 noiembrie 2006, Sun (Sun Mycrosystems) a anunțat că il va lansa sub licența GNU General Public
License (GPL) făcându-l astfel un software liber. Acest lucru s-a întâmplat în mare parte la 8 mai 2007,
când Sun a contribuit cu codul sursă pentru OpenJDK. JDK are ca si componente primare o colectie de
tool-uri de programare ce il fac usor de folosit si inteles de catre programatori.
 Java Runtime Environment (JRE) este un set de tool-uri software pentru dezvoltarea de aplicatii
Java. Acesta combina Java Virtual Machine (JVM), clasele principale ale platformei si lubrarii pentru
suport. JRE este parte a JDK-ului, ce poate fi folosit atat integrat in acesta cat si separate. JRE a fost
dezvoltat initial de catre Sun Microsystems Inc, detinuta de Oracle Corporation.

Java Platform Standard Edition (Java SE) este o platformă de calcul pentru dezvoltarea și
implementarea unui cod portabil pentru medii desktop și server. Java SE era cunoscut anterior ca platforma
Java 2, Standard Edition (J2SE). Platforma utilizează limbajul de programare Java și face parte din familia
de platforme software cu acelasi nume. Java SE definește o gamă de API-uri (Application Programming
Interface) de uz general, cum ar fi Java API pentru clasa Java, și include, de asemenea, specificațiile
limbajului Java și Java Machine Virtual. Una dintre cele mai cunoscute implementări ale Java SE este Java
Development Kit (JDK) de la Oracle Corporation.

Maven este un instrument de automatizare a construcțiilor, utilizat în principal pentru proiecte Java.
Maven abordează două aspecte legate de construirea unui software: în primul rând, descrie modul în care
este construit software-ul, (cerințele de clarificare) și, în al doilea rând, descrie dependențele acestuia. Spre
deosebire de instrumente anterioare, cum ar fi Apache Ant, utilizează convențiile pentru procedura de
construire, avand nevoie in scris numai de excepții. Un fișier XML descrie proiectul software construit,
dependențele acestuia de alte module și componente externe, ordinea de construire, directoarele și plug-in-
urile necesare. Dispune de obiective predefinite pentru efectuarea unor sarcini bine definite, cum ar fi
compilarea codului și a ambalajului acestuia. Maven descarcă în mod dinamic bibliotecile Java și plug-in-
urile Maven de la unul sau mai multe depozite, cum ar fi “Maven 2 Central Repository” stocandu-ke într-
un cache local. Acest cache local, de artefacte descărcate, poate fi actualizat și cu artefacte create de
proiectele locale. Depozitele publice pot fi, de asemenea, actualizate. Maven poate fi, de asemenea, utilizat
pentru a construi și gestiona proiecte scrise în C #, Ruby, Scala și alte limbaje de programare. Proiectul
Maven este găzduit de Fundația Software Apache, unde a făcut parte din Proiectul Jakarta.

Maven este construit folosind o arhitectură bazată pe pluginuri care îi permite să utilizeze orice
aplicație controlată prin intrarea standard. Teoretic, acest lucru ar permite oricui să scrie pluginuri pentru a
interfața cu instrumente de construire (compilatoare, unelte de testare a unității etc.) pentru orice altă limbă.
În realitate, suportul și utilizarea pentru alte limbi decât Java au fost minime. În prezent există un plugin
pentru cadrul .NET și este menținut, iar un plugin nativ C / C ++ este menținut pentru Maven 2.

Eclipse Java Photon (June, 2018) este un mediu integrat de dezvoltare (IDE) utilizat în
programarea pe calculator și este cel mai utilizat, la nivel mondial, Java IDE (Integrated Development
Environment). Acesta conține un spațiu de lucru de bază și un sistem plug-in extensibil pentru
personalizarea mediului. Eclipse este scris în mare parte in Java și utilizarea sa principală este pentru
dezvoltarea de aplicații Java, dar poate fi de asemenea folosită pentru a dezvolta aplicații în alte limbaje de
programare prin plug-in-uri, inclusive: C, C++, C#, Ruby, JavaScript, ADA, PHP, Perl, NATURAL, Lasso,
Julia, Haskell, Fortran, etc. Codul inițial a provenit de la IBM VisualAge. Kitul pentru dezvoltarea software-
ului Eclipse (SDK – Software Development Kit), care include instrumentele de dezvoltare necesare Java,
este destinat dezvoltatorilor Java. Utilizatorii își pot extinde abilitățile prin instalarea pluginurilor scrise
pentru platforma Eclipse, cum ar fi seturile de instrumente de dezvoltare pentru alte limbaje de programare
și pot scrie și contribui cu propriile lor module de tip plug-in. De la introducerea implementării OSGi (Open
Service Gateway initiative) Equinox în versiunea 3 a Eclipse, plug-in-urile pot fi conectate și oprite în mod
dinamic și sunt denumite pachete (OSGI). Kitul de dezvoltare software (SDK) Eclipse este un software
liber open-source.

Selenium este o combinație de instrumente și un Limbaj de Domeniu Specific (DSL), totul pentru
a construi și a opera teste funcționale, teste de tip ‘smoke’ (simple teste preliminare pentru dezvaluirea unor
probleme severe) și teste de integrare a aplicațiilor Web, inclusiv aplicații Rich Internet (RIA, utilizând
Ajax.) Selenium comunica cu o varietate larga de browsere: Internet Explorer, Mozilla Firefox, Opera,
Safari, Chrome. Selenium Grid facilitează executarea acestor teste într-o rețea de mașini de testare.
Selenium implementează un limbaj specific domeniului (DSL) pentru testarea aplicațiilor Web. De
exemplu, DSL implementează comenzi pentru a face click pe un buton, introduce caractere într-un câmp
de testare și asteapta până când textul apare pe pagină. Selenium implementează DSL ca bibliotecă de clasă
în Java, pachet în Python și Ruby, Groovy, C #, Perl și PHP. DSL are aproximativ 200 de comenzi.
PushToTest.

Selenium WebDriver este o bibliotecă de automatizare a browserului. Cel mai adesea folosit
pentru testarea aplicațiilor web, Selenium poate fi folosit pentru orice activitate care necesită automatizarea
interacțiunii cu browserul. Acesta este succesorul Selenium RC (Remote Control). Selenium WebDriver
acceptă comenzi (trimise în Selenese sau prin intermediul unui Client API) și le trimite într-un browser.
Selenium este implementat printr-un driver specific browserului, care trimite comenzi către un browser și
preia rezultatele. Majoritatea driverelor de browser lansează și accesează de fapt o aplicație (cum ar fi
Firefox, Chrome, Internet Explorer, Safari sau Microsoft Edge); există, de asemenea, un driver HtmlUnit,
care simulează un browser. Spre deosebire de Selenium 1, unde un server specific era necesar pentru a rula
testele, Selenium WebDriver nu are nevoie de un server special pentru a executa teste dorite. În schimb,
WebDriver pornește direct o instanță a browserului și o controlează. Cu toate acestea, Selenium Grid poate
fi utilizat cu WebDriver pentru a executa teste pe sisteme la distanță .Unde este posibil, WebDriver folosește
mai degrabă funcționalitatea nivelului sistemului de operare nativ decât comenzile JavaScript bazate pe
browser pentru a conduce browserul. Acest lucru ocolește problemele cu diferențe subtile dintre comenzile
native și JavaScript, inclusiv restricțiile de securitate.

În practică, acest lucru înseamnă că Selenium 2.0 API are apeluri semnificativ mai mici decât
Selenium 1.0 API. În cazul în care Selenium 1.0 a încercat să ofere o interfață bogată pentru multe operații
de browser diferite, Selenium 2.0 își propune să furnizeze un set de bază de blocuri de construcție din care
dezvoltatorii își pot crea propriul limbaj specific domeniului. Un astfel de DSL există deja: proiectul Watir
în limbajul Ruby are o istorie bogată de design de calitate. Watir-webdriver implementează Watir API ca
un înveliș pentru Selenium-Webdriver în Ruby. Watir-webdriver este creat în întregime automat, pe baza
specificațiilor WebDriver și a specificatilor HTML

Încă de la începutul anului 2012, Simon Stewart (inventatorul WebDriver), care era atunci la
Google și acum la Facebook, și David Burns de la Mozilla negociau cu W3C (World Wide Web
Consortium) pentru a face WebDriver un standard pe internet. În iunie 2012, proiectul de lucru a fost lansat.
Selenium-Webdriver (Selenium 2.0) este implementat pe deplin în Python, Ruby, Java și C #.

TestNG (Test. Next Generation) este un framework de testare inspirat de JUnit și NUnit, cu mai
multe funcționalități adăugate pentru a face execuția mai eficientă și mai puternică. Este un framework
automat open source. Este similar cu JUnit, dar este mai bogat decât acesta. TestNG elimină cele mai multe
limitări ale frameworkului anterior și oferă dezvoltatorului posibilitatea de a scrie teste mai flexibile și mai
eficiente, cu ajutorul adnotărilor, grupării, secvențierii și parametrizării ușoare. Acesta este dedicate
limbajului de programare Java si a fost creat de catre Cedric Beust. Principalul scop al lui TestNG este de
a acoperi o gama mai larga de categorii de test: unitare, functionale, end-to-end, integrare, etc. cu mai multe
si usoare functionalitati integrate.

Pentru o mai buna intelegere a celor doua componente, Selenium si TestNG, trebuie explicata si
functionalitatea acestora combinate.

Selenium este tool-ul care interactioneaza cu browser-ul si transmite actiuni acestuia precum:
apasarea unui buton, derularea in pagina, etc. Selenium automatizeaza browserele si cu ajutorul codului
scris utilizatorul poate interactiona cu acestea. Cu alte cuvinte, Selenium copiaza actiunile umane exercitate
asupra browser-ului si este capabil sa se foloseasca de acestea pentru a crea teste functionale sau de regresie.

In paralel, TestNG este framework-ul de testare care ofera o varietate de caracteristici pentru a
executa un test, precum @Test sau multe alte adnotari. TestNG oferă posibilitatea de a efectua testul în
diverse moduri, cum ar fi executarea în grupuri, în paralel, secvențial etc. Deci, practic TestNG este cadrul
de execuție a testului și utilizatorul il poate folosi pentru orice tip de testare, cum ar fi: Functional Tests,
Unit Tests, Regression Tests, Database and API Tests.

Prin combinarea utilizării TestNG și Selenium, putem face diverse sarcini în testarea funcțională.
Precum in metoda BeforeClass sau BeforeTest, putem adauga cod de tip Selenium pentru a deschide un
browser iar in metoda AfterClass sau AfterTestMethod folosim cod de tip Selenium pentru a inchide
browser-ul.

Exista o multitudine de framework-uri de testare precum Cucumber, Calatest, etc. disponibile, pe

care utilizatorul le poate folosi in combinatie cu Selenium. Datorita acestui fapt, Selenium este placut si
utilizat in intreaba lume, oferind usurinta si rapiditate pentru dezvoltarea testelor automate.

Beneficiile si marile avantaje in utilizarea TestNG, din punct de vedere al Selenium-ului, sunt:

1. Ofera abilitatea de a produce Rapoarte HTML ale executiei

2. Adnotarile ce faciliteaza munca depusa de utilizator
3. Test Case-urile pot fi grupate cu mare usurinta
4. Face posibila rularea testelor in paralel
5. Genereaza Log-uri
6. Parametrizarea datelor este posibila
7. Poate include/exclude metode de testare
8. Ofera optiuni de prioritizare a testelor
9. Genereaza rapoarte eficiente folosind ReportNG
10. Suporta integrarea cu diferite tool-uri si plug-inuri precum tool-uri de construire (Ant, Maven, etc.),
IDE (Eclipse)

Prezentarea Aplicatiei

1. Crearea proiectului

La baza testelor create cu ajutorul Eclipse-ului, sta un prim proiect de tip Maven creat, numit
Automation. Proiectul este de tip Maven deoarece acest tip de proiect scuteste utilizatorul de descarcarea
arhivelor Java pentru fiecare obiect in parte si faciliteaza procesul de creare. In schimbul arhivelor Java,
acest tip de proiect foloseste asa numitele “Maven dependencies” (dependente) ce contin toate arhivele si
plug-in-urile necesare.

Un prim set de “dependente” folosit este TestNG Dependencies, pentru a stabili “conexiunea” intre
cele trei componente de baza: TestNG, Selenium WebDriver si Eclipse.
<dependencies>
<!-- https://mvnrepository.com/artifact/org.testng/testng -->
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.14.3</version>
<scope>test</scope>
</dependency>
</dependencies>

Urmatorul set de “dependente” adaugat in proiect, reprezinta dependentele pentru primul browser
folosit in cadrul testelor, si anume Mozilla Firefox.
<dependencies>
<!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-firefox-driver -->
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-firefox-driver</artifactId>
<version>3.14.0</version>
</dependency>
</dependencies>

In continuare, pentru o buna functionare a tuturor componentelor de tip Maven, proiectul are nevoie
de doua plug-in-uri: Maven Compiler plug-in si Maven Surfire plug-in. Maven Compiler este folosit pentru
compilarea sursei unui proiect iar Surfire se utilizeaza in timpul fazei de testare a ciclului pentru executarea
testelor de tip unit-test, a aplicatiei.

<build>
<plugins>
<plugin>
<groupId>org.apachse.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
</plugin>

<plugin>
<groupId>org.apachse.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
</plugin>
</plugins>
</build>

In finalul pregatirilor pentru a crea primul test automat, proiectul are nevoie de un mod de a
comunica cu browser-ul (Mozilla Firefox in cazul de fata). Pentru asta este folosit “geckodriver”, acesta
stabilind canalul de interactiune dintre Eclipse si Mozilla.
 2. Primul Test

Pentru crearea unui prim test simplu, am adaugat o noua Clasa Java, numita ‘FirstTest’, apartinand
unui nou pachet ‘com.dice’.

In interiorul clasei, a fost creata o metoda (firstTestMethod()) care apeleaza consecutiv

urmatoarele actiuni:

1. Foloseste calea oferita pentru a deschide ‘geckodriver.exe’ care, odata actionat, deschide la
randul sau Mozilla Firefox browser.
2. Este incarcata pagina ce se gaseste la adresa oferita “www.dice.com”.
3. Odata deschisa pagina, operatia System.out.println afiseaza in consola Eclipse mesajul
introdus.
 4. Ultimul pas este de a inchide browser-ul.

De asemenea, acest simplu test poate fi rulat cu ajutorul Command Processor-ului. Introducand calea
corecta, pentru a ajunge la workspace-ul in care Eclipse isi salveaza pachetele, si o comanda de actiune,
testele pot fi rulate iar rezultatele vizualizate in CMD.

3. TestNG - Test Suite

Un Test Suite este o colecție de Test Case-uri destinate testarii unui comportament sau un set de
comportamente ale unui program software. În TestNG, nu putem defini un Test Suite în testarea codului
sursă, dar este reprezentat de un fișier XML. De asemenea, permite configurarea flexibilă a testelor. O suită
poate conține unul sau mai multe teste și este definită de eticheta <suite>. <suite> este eticheta “radacina”
a testng.xml. Acesta descrie un Test Suite, care, la rândul său, este alcatuit din mai multe secțiuni <test>.

Următorul tabel enumeră toate atributele juridice acceptate de <suite>.

 Atribut si descriere
1 Name – Numele Test Suite-ului. Este un atribut obligatoriu.
2 Verbose – Nivelul de date pentru rulare.
3 Parallel – In cazul in care TestNG trebuie sa ruleze alte thread-uri pentru a rula un Test Suite.
4 Thread-Count – Nr. thread-uri necesare atunci cand modul Paralel este activ (altfel este ignorat).
5 Annotations – Tipul de adnotari folosite in test.
6 Time-out – Pauza implicit ace va fi folosita in toate metodele gasite in test.

Pentru a folosi TestNG Test Suite am creat un al 2-lea test, care ruleaza aceiasi pasi ca si primul
dar deschide o alta pagina web.

Odata creat un Test Suite ce actioneaza asupra a cel putin doua teste (cazul de fata), utilizatorul
poate folosi doua noi comenzi de includere sau excludere a anumitor teste ce fac parte din Test Suite.

In cazul de fata, Test Suite-ul creat se numeste First Test Suite, contine doua metode ce vor rula pe
rand, in acelasi browser, prima deschizand pagina web “www.dice.com” iar urmatoarea o alta pagina,
“www.likedin.com”. Test Suite-ul a fost creat intr-un document de tip XML (testng.xml) in care a fost
adaugata o secventa de cod incorporata in tag-ul <suite>.
 Odata cu noul Test Suite, am folosit si doua noi metode de includere sau excludere a anumitor
teste sau metode pe care Test Suite-ul meu le actioneaza. In cazul de fata, am exclus al 2-lea test, astfel
dupa rulare, o singura metoda a fost actionata si anume deschiderea paginii dice.com.

4. TestNG – Adnotari

Deoarece ambele metode contin pasi similari, am exportat pasii pentru al 2-lea test intr-o noua clasa
si am folosit Adnotarile TestNG pentru a stabili ierarhia rularii a doua noi metode.

TestNG suporta o multitudine de adnotari si logica din spatele acestora este de a aduce metodele
de testare cat mai aproape posibil de orice metoda normala de tip Java. Folosirea adnotarilor TestNG, aduce
cateva avantaje in construirea testelor automate:

 Metodele nu necesita nicio conventie de numire

 Au permisiunea sa accepte parametri ca orice alta metoda java
 Adnotarile permit configurarea ulterioara utilizand atributele sale
 Clasele de test nu sunt obligate sa extinda nicio alta clasa de baza
 Adnotarile sunt puternic tiparite, astfel incat compilatorul v-a anunta orice greseala imediat
 Se pot transmite parametri suplimentari adnotarilor

In continuare este prezentata lista tuturor adnotarilor pe care TestNG le suporta:

 Adnotari si descrieri
1 @BeforeSuite-se va executa inaintea oricarui test declarat in interiorul unui TestSuite
2 @AfterSuite-se va executa dupa toate testele declarate in interiorul unui TestSuite
3 @BeforeClass-se va executa inaintea oricarei metode declarata intr-o Clasa de Test
4 @AfterClass-se va executa dupa executia fiecarei metode declarata intr-o Clasa de Test
5 @BeforeTest-se va executa inaintea fiecarei sectiuni de testare declarata intr-un TestSuite
6 @AfterTest-se va executa dupa executia fiecarei sectiuni de testare declara intr-un TestSuite
7 @BeforeGroups-va rula inainte de executarea oricarei metode a unui grup specificat. Atributul
‘groups’ trebuie sa contina lista grupurilor de care apartine aceasta metoda
8 @AfterGroups- va fi executat după fiecare secțiune de testare declarată într-un TestSuite
9 @BeforeMethod-va rula inaintea rularii fiecarei metode de test
10 @AfterMethod-va rula dupa rualrea fiecarei metode de test
11 @DataProvider-metoda furnizeaza datele pentru o metoda de tetstare si trebuie sa returneze o
matrice-obiect bidimensionala ca date
12 @Factory-metoda returneaza o serie de obiecte de clasa. Acesta este folosit pentru a rula un set
de test case-uri cu diferite valori furnizate clasei de test in timpul initierii
13 @Listeners-este definit la nivel de clasa pentru a specifica o serie de clase de tip ‘test listeners’.
Este folosita cu ajutorul ‘org.testng.TestNgListener’
14 @Parameters-este folosit pentru a transmite parametrii unei metode de testare. Aceste valori ale
parametrilor sunt furnizate in fisierul de configuratie testng.xml la rulare
15 @Test-marcheaza o clasa ca metoda de testare. Daca se utilizeaza la nivel de clasa, toate
metodele publice ale acestei clase vor fi considerate metode de testare

Pentru testele initiale, am creat doua noi metode publice (methodSetUp si methodTearDown)
fiecare preluand cate un rol, de deschidere si de inchidere a browser-ului, evitand astfel scrierea repetata a
metodelor in viitor. Pentru a comunica TestNG-ului modificarile facute si ordinea dorita a executarii
metodelor in toate testele viitoare, ce o sa foloseasca cele doua metode methodSetUp si methodTearDown,
am folosit doua dintre Adnotarile TestNG, si anume @BeforeMethod si @AfterMethod.
Cele doua adnotari ii comunica compilatorului faptul ca methodSetUp trebuie intotdeauna executata
inaintea tuturor metodelor prezente in testul respectiv, iar methodTearDown trebuie intotdeauna rulata dupa
executarea fiecarei metode prezenta in test.

5. Creare Test LogIn folosind Page-Object-Model si Selenium Assertions

In continuare am construit un test pozitiv de logare (cu email si parola) pe site-ul folosit anterior
(www.dice.com). Testul consta in executarea catorva pasi simpli: deschidere browser, incarcare pagina
web, introducere email si parola in campurile respective, apasarea butonului de Sign In si verificarile finale:
numele paginii LogIn si numele profilului pe care s-a logat.
 Pentru cele doua verificari, a fost nevoie de construirea unei noi clase java (Base Page Object) in
care au fost adaugate toate metodele si variabilele folosite pentru Page Objects (LogInPage si ProfilePage).
Acest lucru faciliteaza procesul de creare a fiecarui Page Object in viitor.

Tot aici, a fost folosit conceptul de “wait” (asteptare) pe care Selenium il pune la dispozitie, si
anume, asteptarea incarcarii unei pagini sau asteptarea aparitiei unui obiect. In cazul testului nostru,
asteptarea pentru Pagina de Profil se face dupa “vizibilitatea” a doua elemente din pagina, pentru a asigura
succesul testului. Cele doua obiecte reprezinta doua butoane, alese la intamplare, ‘Edit Profile’ si
“Advanced Search”. Acestea sunt cautate si recunoscute dupa identificatori unici preluati prin inspectarea
sursei paginii respective (www.dice.com/dashboard/profiles/).

In continuare vom vorbi despre asa numitele “Selense”, comenzi folosite pentru a comunica cu
Selenium si care sunt de trei feluri: Actions, Accessors si Assertions.

Actions – reprezinta partea de Actiuni care manipuleaza in general starea testului, cum ar fi “Dati
Click pe acest link” si “Selectati optiunea respective”. Daca o actiune nu reuseste sau are o eroare,
executarea testului current se opreste.

Accessors – reprezitnta partea de Accesorii care examineaza stearea aplicatiei si stocheaza

rezultatele in diferite variabile, de exemplu “Titlu”.

Assertions – reprezinta partea de Asertiuni care verifica daca starea aplicatiei este identica cu ceea
ce este asteptat in urma rularii. Selenium Assertions pot fi de trei feluri: “assert” (afirma), “verify” (verifica)
si “waitFor” (asteapta pentru). Atunci cand un “assert” esueaza, testul este anulat. Cand un “verify” esueaza,
testul va continua executarea, inregistrand esecul. O comanda “waitFor” asteapta ca o anumita conditie sa
devina adevarata. Aceasta va esua si va opri testul daca conditia nu devine reala in timpul alocat. Este
posibil ca aceasta sa reuseasca imediat daca conditia este deja adevarata.

Cand vorbim despre afirmatiile utilizate in WebDriver folosind framework-ul TestNG, avem doua
tipuri de afirmatii: Hard Assertion si Soft Assertion.
 Hard Assertion in WebDriver folosind TestNG

O afirmatie de tip Hard Assertion arunca un AssertException imediat dupa ce un test nu reuseste si
este marcat ca esuat. Test Suite-ul poate continua folosind adnotatia @Test. Afirmatiile de tip Hard pot fi:
assertEquals, assertNotEquals, assertTrue, assertFalse, assertNull si assertNotNull.

AssertTrue este folosita in cazul conditiilor de tip Boolean. Aceasta asertiune returneaza “true” in
cazul in care conditia aplicata reuseste sa treaca cu success. Daca aceasta conditie este falsa/esueaza,
asertiunea omite executarea metodei curente (Assert.assertTrue(condition);).

In testul curent a fost folosita de doua ori afirmatia de tip Hard, assertTrue. Prima oara pentru a
verifica daca titlul paginii incarcate este identic cu cel asteptat (expectedPageTitle = “Seeker Dashboard –
Profile”;). In cazul in care titlul nu este cel cautat, TestNG v-a returna un mesaj de eroare (“Page title is not
expected.”). A doua oara este verificat daca numele contului logat este identic cu cel asteptat
(correctProfileName = “Mirica Marius”;). In cazul in care numele nu este cel cautat, din nou, TestNG v-a
returna un mesaj de eroare (“Profile name is not expected”).

6. Primul Test negativ

Pentru aceasta categorie am creat un test negativ cu ajutorul metodei de LogIn pe pagina web
dice.com. Am folosit practic acelasi tip de test ca pentru cele anterioare insa de data aceasta mesajul asteptat
este unul negativ “Incorrect email or password”. Astfel incat, atunci cand se incearca logarea cu o adresa
de email gresita (prima oara) si cu o parola gresita (a doua oara), rezulta doua teste negative de verificare a
credentialelor.

In clasa creata anterior, LogInTest, am introdus o noua secventa de pasi (deschidere pagina,
introducere email si parola, apasa butonul de SignIn) sub denumirea de negativeLogInTest().
 Pentru a verifica testul negativ este nevoie de o noua metoda care sa extraga mesajul de eroare
primit dupa fiecare incercare de logare (logInPage.getLogInErrorMessage();). Pana la mesajul de logare,
este nevoie de un ‘wait’ deoarece mesajul nu apare instant, lasand timp de “gandire” motorului care ruleaza
in spatele paginii. Metoda folosita pentru acest ‘wait’ este ‘waitforVisibilityOf()’. Aceasta metoda foloseste
doi parametrii, un parametru numit ‘timeout’ ce este setat la valoarea dorita (10 secunde in cazul de fata) si
un al doilea parametru numit ‘locator’ ce reprezinta identificatorul unic din pagina al mesajului de eroare
afisat. Identificatorul unic a fost obtinut prin inspectarea mesajului respective direct din pagina web.

In continuare, verificarea mesajului primit in momentul introducerii gresite a email-ului sau a

parolei, se face printr-o asertiune de tip True, insa de data aceasta, mesajul de eroare asteptat nu trebuie sa
fie identic cu mesajul de eroare primit, deoarece mesajul de eroare poate varia de la caz la caz.

In aceasta situatie, asertiunea verifica daca mesajul asteptat este cuprins in mesajul primit.

In screenshot-ul urmator este prezentata starea finala a metodei de test negativa. Introducand un
email gresit “miricamariusmiric2 @gmail.com”, mesajul de eroare va fi afisat in browser si comparat cu
mesajul asteptat “Email and/or password incorrect.”. Mesajul de eroare asteptat va fi identificat ca o parte
din mesajul afisat, astfel testul va rula cu succes.

7. Al doilea Test negativ folosind TestNG Data Provider

In continuare am adaugat un nou Test negativ, de data aceasta pentru parola incorecta. In loc de a
crea o metoda separata pentru acest test, am folosit o noua functionalitate a TestNG-ului, numita Data
Provider, care ajuta utilizatorul sa ruleze aceeasi metoda de test negativ folosind doua input-uri diferite.
 Pentru a avea acces la TestNG Data Provider, un nou set de “dependente” a fost adaugat in fisierul
principal ‘pom.xml’.

<dependencies>
<!-- https://mvnrepository.com/artifact/net.sf.opencsv/opencsv -->
<dependency>
<groupId>net.sf.opencsv</groupId>
<artifactId>opencsv</artifactId>
<version>2.3</version>
</dependency>
</dependencies>

Acest set ofera posibilitatea compilatorului de a accesa un fisier extern de tip .csv, in care sunt
stocate doua secvente de test, ambele negative.

Pentru accesarea acestui fisier a fost creata o noua clasa ‘CsvDataProvider.java’ ce contine o
metoda prin care compilatorul este trimis la path-ul fisierului extern .csv. Acesta citeste datele introduse de
catre utilizator, in cazul de fata doua teste, 1-invalid email si 2-invalid password. In acest mod, compilatorul
ruleaza aceeasi metoda de test de doua ori, insa, introducand date diferite la fiecare secventa. Fisierul poate
oferi o multitudine de astfel de linii pentru verificarea mai multor campuri, in diferite cazuri.

8. Adaugarea si rularea testelor in Google Chrome folosind TestNG Parameter

Pentru adaugarea unui browser nou in proiectul curent, cu scopul de a rula si compara teste in doua
medii diferite, avem nevoie de ChromeDriver. Acesta va fi adaugat in folderul cu resurse al proiectului.
Odata adaugat, compilatorul va putea comunica cu browser-ul.
 Pentru diferentierea actiunilor similare de testare in cele doua browsere (Mozilla Firefox si Google
Chrome) am folosit un parametru oferit de catre TestNG care specifica compilatorului numele si valoarea
browser-ului in fiecare test in parte.

9. Teste paralele

In cazul testelor rulate in paralel este nevoie de modificarea unui parametru in sintaxa Test Suite-
ului folosit in fisierul testng.xml. Parametrul folosit este denumit ‘parallel’ caruia I se atribuie o valoare.
Tot odata se adauga parametrul ‘thread-count’ care specifica compilatorului numarul testelor pe care dorim
sa le rulam in acelasi timp (in cazul de fata, 2).
 10. Vizualizarea rezultatelor folosind Apache Log4j

Vizualizarea rezultatelor se poate face cu ajutorul Consolei cu care Eclipse vine echipata.
Rezultatele pot fi vizulizate pas cu pas, de la inceperea testului, setarea metodelor, deschiderea browser-
ului (unul sau mai multe, depinde de caz) si rularea fiecarul test in parte. La final, Consola specifica
finalizarea testelor, inchiderea mediului de lucru (browser) si specifica daca testele au rulat cu success sau
au esuat.

Pentru vizualizarea rezultatelor intr-un mod mai placut si usor de inteles, oferind informatii
aditionale legate de testul rulat, data (optionala), timp si pasul rulat, am inlocuit afisarea mesajelor in
consola folosind metoda clasica ‘System.out.println(“text”)’ cu Log4j.

Log4j este un pachet de logare popular exclusiv pentru Java. Acest pachet este distribuit sub licenta
software Apache si este de asemenea Open Source.

Introducerea instrucțiunilor de jurnal (statements log) în cod reprezinta o metodă low-tech pentru
depanarea (debugging) acestuia. De asemenea, poate fi singura cale, deoarece depanartorul nu este
întotdeauna disponibil sau aplicabil. Acest lucru este adesea cazul aplicațiilor distribuite. Pe de altă parte,
unii oameni susțin că log statements-urile poluează codul sursă și scad lizibilitatea. În limbajul Java în care
un preprocesor nu este disponibil, instrucțiunile din jurnal măresc dimensiunea codului și reduc viteza
acestuia chiar și atunci când logarea este dezactivată. Dat fiind că o aplicație de dimensiuni rezonabile poate
conține mii de log statements-uri, viteza fiind de o importanță deosebită.

Cu log4j este posibilă activarea înregistrării în timpul executării fără modificarea aplicației.
Pachetul log4j este conceput astfel încât aceste declarații să rămână în codul expediat fără a suferi costuri
de performanta. Logarea comportamentului poate fi controlată prin editarea unui fișier de configurare, fără
a atinge aplicația.

Logging-ul furnizează dezvoltatorului un context detaliat pentru eșecurile aplicațiilor. Pe de altă

parte, testarea asigură calitatea și încrederea în aplicație. Logarea și testarea nu trebuie confundate. Ele sunt
complementare. Atunci când logarea este folosită cu înțelepciune, se poate dovedi a fi un instrument
esențial.

Una dintre trăsăturile distinctive ale log4j este noțiunea de ‘moștenire’ în logger. Folosind o ierarhie
logger este posibil să se controleze care declarații log sunt extrase dar și o mare ușurință. Acest lucru ajută
la reducerea volumului datelor de iesire și a costului înregistrării.
 Log Output-ul poate fi un fișier, un OutputStream, un java.io.Writer, un server log4j la distanță, un
daemon de la Unix Syslog la distanță sau multe alte ținte de ieșire.

Pentru folosirea acestui pachet este nevoie de o noua serie de ‘dependente’ introduse in proiect:

<dependencies>
<!-- https://mvnrepository.com/artifact/log4j/log4j -->
<dependency>
<groupId>log4j </groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
</dependencies>

Dupa cum se poate observa in imagina anterioara, Consola indica pasii urmati de testul current, LogInTest.
Testul reprezinta o secventa de pasi dupa cum urmeaza:

- Testul incepe sa ruleze

- Se infiinteaza metoda
- Este accesat Testul cu numarul #1, test ce implica un scenario negativ
- Programul extrage datele Email: invalidemail@gmail.com si Parola: Mariusmirica20
- Introduce datele extrase dintr-un fisier xml intern in campurile “Username” si “Password”
- Apasa butonul SignIn
- Testul a fost realizat cu success si acest lucru este specificat “LogInTest-FF Test Success”
- Metoda se intrerupe
- Testul este finalizat
- Totalitatea testelor rulate: 6
 - Teste esuate: 0
- Teste omise: 0

Pentru afisarea anterioara, a fost creat fisierul urmator ce contine proprietatile afisarii. Aceste
proprietati sunt editabile, oferind astfel o multime de posibilati pentru afisaj, dupa bunul plac.

11. TestNG - Test Listeners

Listener este definit ca o interfață care modifică comportamentul implicit al TestNG. După cum
sugerează numele, Listeners "ascultă" evenimentul definit în scriptul seleniului și se comportă în
consecință. Se utilizează în seleniu prin implementarea interfeței Listeners. Permite personalizarea
rapoartelor sau jurnalelor TestNG. Există mai multe tipuri de Listeners TestNG disponibile.

Test Listener-ul folosit in aplicatie printeaza si returneaza mesaje atunci cand un test incepe, se
incheie, ruleaza cu success sau esueaza. Pentru asta am folosit patru tipuri de Test Listeners disponibil pe
internet:

onTestSuccess – invocata de fiecare data cand un test ruleaza cu succes

onTestFailure – invocata de fiecare data cand un test esueaza sau este omis

onStart – invocata dupa instantierea Test Class si inaintea apelarii configuratiei oricarei metode

onFinish – invocata dup ace toate teste au rulat si toate configuratiile acestor metode au fost apelate

Formula afisarii fiind “Numele Testului curent” + “Test Start/Finish/Failure/Succes”.