PROGRAMUL DE STUDIU: AUTOMATICĂ ȘI INFORMATICĂ APLICATĂ FORMA DE ÎNVĂȚĂMÂNT: IF PROIECT DE DIPLOMĂ Coordonator științific: Prof.univ.dr.ing. HELGA… [612154]

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
DOMENIUL: INGINERIA SISTEMELOR
PROGRAMUL DE STUDIU: AUTOMATICĂ ȘI
INFORMATICĂ APLICATĂ
FORMA DE ÎNVĂȚĂMÂNT: IF

PROIECT DE DIPLOMĂ

Coordonator științific:
Prof.univ.dr.ing. HELGA SILAGHI
Absolvent: [anonimizat]
2018

1

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
DOMENIUL: INGINERIA SISTEMELOR
PROGRAMUL DE STUDIU: AUTOMATICĂ ȘI
INFORMATICĂ APLICATĂ
FORMA DE ÎNVĂȚĂMÂNT: IF

TESTAREA SOFTWARE –
TESTAREA AUTOMAT Ă

Coordonator ști ințific:
Prof.univ.dr.ing. HELGA SILAGHI
Absolvent: [anonimizat]
2018

2
UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA INFORMAȚIEI
DEPARTAMENTUL DE INGINERIA SISTEMELOR AUTOMATE ȘI MANAGEMENT

TESTAREA SOFTWARE – TESTAREA AUTOMAT Ă

Lucrare de Finalizare a studiilor a student: [anonimizat]
1). Tema lucrării de finalizare a studiilor: ___________________________________________
________________________________________________________________________________
_____________________________________________ ___________________________________
2). Termenul pentru predarea lucrării _______________________________________________
3). Elemente inițiale pentru elaborarea lucrării de finalizare a studiilor ___________________
______________________________________ __________________________________________
________________________________________________________________________________
4). Conținutul lucrării de finalizare a studiilor :_______________________________________
_________________________________________ _______________________________________
________________________________________________________________________________
________________________________________________________________________________
______________________________________________________ __________________________
5). Material grafic:________________________________________________________________
________________________________________________________________________________
_______________________________________________________________ _________________
6). Locul de documentare pentru elaborarea lucrării:
________________________________________________________________________________
________________________________________________________________________________
7). Data emiterii temei_____________________________________________________________

Coordonator științific
Prof.univ.dr.ing. HELGA SILAGHI

3
Cuprins
Introducere ………………………….. ………………………….. ………………………….. ………………………….. ………………. 5
Capitolul 1 : Considerații teoretice ………………………….. ………………………….. ………………………….. …………… 7
1.1. Informații și concepte generale despre testare ………………………….. ………………………….. …………….. 7
1.2. De ce test ăm? ………………………….. ………………………….. ………………………….. ………………………….. …. 8
1.3. Cauzele defectelor și “dificult ăți” în fixarea lor ………………………….. ………………………….. …………….. 8
1.4. Testerul ………………………….. ………………………….. ………………………….. ………………………….. ………….. 9
1.5. Fazele procesului de testare ………………………….. ………………………….. ………………………….. ………….. 9
1.6. Tipuri de testare și metodologii de testare ………………………….. ………………………….. …………………. 13
1.6.1. Testarea white box ………………………….. ………………………….. ………………………….. ……………….. 13
1.6.2. Testarea black box ………………………….. ………………………….. ………………………….. ……………….. 18
1.6.3. Testarea de module ………………………….. ………………………….. ………………………….. ……………… 19
1.6.4. Testarea de integrare ………………………….. ………………………….. ………………………….. ……………. 20
1.6.5. Teste de regresie ………………………….. ………………………….. ………………………….. ………………….. 21
1.6.6. Teste de validare ………………………….. ………………………….. ………………………….. ………………….. 22
1.6.7. Teste de performanță ………………………….. ………………………….. ………………………….. …………… 22
1.6.8. Testarea de compatibilitate ………………………….. ………………………….. ………………………….. …… 23
1.6.9. Testarea de a ccesibilitate ………………………….. ………………………….. ………………………….. ……… 23
1.6.10. Testarea automată ………………………….. ………………………….. ………………………….. ……………… 24
Capitolul 2 : Testarea automat ă de interfață cu ajutorul Selenium Webdriver – Prezentarea Selenium
Framework ………………………….. ………………………….. ………………………….. ………………………….. ……………… 26
2.1. Introducere – Descrierea Selenium Framework ………………………….. ………………………….. …………… 26
2.2. Opțiunile puse la dispoziție de Selenium ………………………….. ………………………….. ……………………. 26
2.3. Identificarea elementelor din pagină ………………………….. ………………………….. …………………………. 27
2.4. Acțiuni asupra elementelor din pagină ………………………….. ………………………….. ………………………. 30
2.5. Assert și Verify ………………………….. ………………………….. ………………………….. ………………………….. .. 30
Capitolul 3: Prezentarea și exe cutarea soluției de teste automate ………………………….. ……………………. 31
3.1. Introducere ………………………….. ………………………….. ………………………….. ………………………….. …… 31
3.2. Prezentarea proiectului de teste automate la nivelul Programării orientate pe Obiecte ……….. 36
3.2.1. Structura soluției de teste automate ………………………….. ………………………….. …………………… 38
3.2.2. Clasa Browser ………………………….. ………………………….. ………………………….. ………………………. 40
3.2.3. Clasa BaseElement ………………………….. ………………………….. ………………………….. ……………….. 42

4
3.2.4. Clasa Pages ………………………….. ………………………….. ………………………….. ………………………….. 43
3.3. Prezentarea unui test “end to end” ………………………….. ………………………….. ………………………….. . 44
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. …………………. 51
Bibliog rafie ………………………….. ………………………….. ………………………….. ………………………….. …………….. 53

5

Introducere

Tema aleasă de mine pentru această lucrare este din domeniul testării automate , deoarece
este unul din ce în ce mai important, în orice domeniu de activitate , nu doar cel ingineresc. Am
dorit sa pun accentul pe testarea automată, deoarece este o metodologie tot ma i cautată de către
companiile producătoare de software și hardware, deoarece testarea automată le oferă siguranța
necesară vânzării produselor dezvoltate. Ca și inginer al calității (Quality engineer – QE) într-o
companie de IT și participând la dezvoltarea unei aplcații multinaționale cu milioane de utilizatori
din toate parțile lumii , întâmpin zilnic diferite probleme apărute din lipsa unei testări adecvate.
De reținut este faptul că automatizarea testelor nu este mereu potrivită, există situații în care
auotmatizarea nu își are sensul și devine o pierdere de buget și timp. De asemenea testele automate
sunt dezvolate în urma testării manuale pentru asigurarea faptului că acestea au un scop valid și
ulterior vor aduce un beneficu proiectului.
Scopul lucrării mele este de a prezenta testarea in general, importanța pe care o are,
diferitele metode de testare și când trebuiesc folosite, dar și pentru a evidenția beneficiile testării
automate, față de testarea manuală.
Importanța pe care o are testarea este imensă , o aplicație care nu a fost testă poate cauza
uriașe pierderi financiare, materiale sau chiar omenești (în cazul aplicațiilor medicale sau în
sistemul medical) . Testarea automată a fost concepută din cauza necesității de dezvoltare a
aplicațiilor web la o viteză mult mai mare decât viteza și timpul necesar testării acestora pentru a
se asigura livrarea unui produs de calitate atât clienților care au nevoie de aplicațiile respective,
cât și utilizatorilor finali care vor folosi aplicația dezvoltata.
Pentru a se asigura că produsele dezvoltate îndeplinesc criteriile de calitate cerute, atât din
partea clienților cât și din partea utilizatorilor, echipele de dezvoltare au ajuns la utilizarea
soluțiilor de teste aut omate care acoperă parte din necesarul de timp alocat de un om pentru a
executa anumite teste. Prin această practică se asigură că bucăți de funcționalitate adăugate în

6
trecut, pe care s-a petrecut timp pentru a fi testate odată cu integrarea lor la funcționalită țile
existente deja în aplicația web dezvoltată, încă îndeplinesc standardele de calitate cerute.

Pentru partea practic ă a lucrării de licență am implementat personal o suită de teste
automate (un s et de teste automate), prin crea rea u nui framework personalizat nevoi lor mele,
acesta fiind rezlizat cu ajutorul Selenium F ramework, într-un capitol ulterior voi prezenta
beneficiile acestei metode de testare, cât și folosirea ei la scară largă.

7
Capitolul 1 : Considerații teoretice

1.1. Informații ș i concepte generale despre testare
Testarea poate fi considerat ă o investigație realizată cu scopul de a oferi informații
referitoare la calitatea produsului sau serviciului supus testării, luând în considerare contextul
operațional în care acesta din urma va fi folosit. Testarea software oferă o viziune obiectivă și
independentă asupra produsului în dezvoltare, of erind astfel businessului posibilitatea de a înțelege
și evalua riscurile asociate cu implementarea produsului soft ware . Tehnicile de testare includ, dar
nu sunt limitate la, procesul de execuție a programului sau aplicației în scopul identificării
defecte lor/erorilor de software. Testarea software mai poate fi definită ca un proces de validare și
verificare a faptului că un program/aplicație/produs software corespunde cu regulile de business și
cerințelor tehnice care au modelat proiectarea și implementare a acestuia, rulează și se comportă
corespunzător așteptărilor. În funcție de metodologia de testare aleasă, testarea software poate fi
implementată în oricare etapă din cadrul procesului de dezvoltare, deși partea considerabilă a
efortului de testare este aplicată de obicei la etapa de după definitvarea cerințelor și finisarea
implementării/ dezvoltării/ codării propriu -zise.
Nu există un proces concret de testare ce ar permite identificarea tuturor defectelor posibile
pe care le poate conține un produs software. Există totuși proces e care pot furniza o viziune critic ă
sau comparativă, care prezint ă unele aspecte ale produsului și metricile și constrângerile care
servesc drept criterii de acceptanță. Aceste criterii pot fi derivate din specificații tehnice, produse
asemănătoare comparabile, versiuni anterioare ale aceluiași produs sau proiecții , așteptari față de
produs enunțate de către utilizator sau client, standarde relevante, legi în vigoare, etc.
Fiecare produs software are o audiență țintă diferită, de expemplu pentru un produs din
sistemul de învațământ sau cel financiar este complet diferită de audiența unui prod us din industria
jocurilor video . De aceea, când o organizație dezvoltă sau investește în dezvoltarea unui produs
software, ea trebuie să fie capabilă să evalueze acceptabilitatea produsului din perspectiva
utilizatorilor finali, audienței țintă, cumpărătorilor , finanțatorilor și altor părți interesate. Testarea
software este procesul care vine sa facă această evaluare posibil ă într -un mod cât mai obiectiv.
Pentru acest lucru există inclusiv echipe dedicate de testare externe (care nu au nimic de caștigat
sau pierdut din softwareul testat), aceste echipe sunt contractate pentru a crește obiectivitatea

8
testării. În prezent, pentru a asigura calitatea unui pro dus informatic, inginerii calității care s e
ocupă de controlul calității produsului, folosesc metode de testare avansate pentru a determina
fiabilitatea și corectitudinea aplicației dezvoltate, precum și accesibilitatea și ușurința de folosire
a aplicației de către utilizatorii finali .
Prinicipalele metodologii moderne Agile, Scrum dar și altele pun un accent deosebit pe
procesul de testare pe care îl integrează în profunzime cu celelalte activități care țin de dezvoltarea
programelor informatice: planific are, proiectare, programare, evaluare și control.

1.2. De ce test ăm?
Principalul scop al procesului de testare este identificarea erorilor software sau
neconcordanță față de specificațiile originale , izolarea și fixarea defectelor care au cauzat aceste
erori. T estarea nu asigură faptul că produsul funționează %100 corect în orice condiții, testarea
doar poate demonstra că produsul nu funcționează corect sau la anumiți parametrii în anumite
condiții. În scopul testării deseori se include atât examinarea s tatică a codului sursă, cât și
examinarea codului în execuție în diferite împrejurări și sub diferite condiții. Aspectele de cod ce
rămân sub atenția inginerului software în timpul acestei execu ții sunt: codul face lucrul care este
presupus sa -l facă și co dul face lucrul care trebuie sa -l facă. Informația obținută în urma procesului
de testare poate fi folosită pentru corectarea și îmbunătățirea procesului conform căruia se dezvoltă
produsul software.
1.3. Cauzele defectelor și “dificult ăți” în fixarea lor
Nu toate defectele software sunt cauzate de greșeli în cod. O sursă răspândită de defecte
costisitoare sunt neclaritățile la nivel de cerințe, de exemplu, cerințele “ascunse ” sau incomplete
pot să rezulte într -un set de erori introduse încă în faza de proi ectare de către designerul
programului, acest lucru înseamnă faptul că programul software a luat -o pe căi greșite înca de la
începutul codării, iar corectarea acestor “deviații ” necesit ă un timp îndelungat . Cerințele non –
funcționale cum ar fi testabilitate a, scalabilitatea, mentenabilitatea, usabilitatea, performanța și
securitatea, sunt o sursă raspândită de astfel de erori.
Defectele software se manifestă de obicei ca rezultat al unor erori/gre șeli introduse
programator, care la rândul ei rezultă într -un defect (bug) la nivel de cod sursă al programului;
dacă acest defect este executat, în anumite condiții sistemul va produce un rezultat greșit, ceea ce

9
ulterior va duce la o eșuare a programului. Nu toate defectele pot duce la eșuarea programului, d e
exemp lu, defectele ce se conțin într -o secțiune de cod “mort” (zonă care nu este accesată indiferent
de datele de intrare) niciodată nu vor duce la eșuarea programului. Defectele se pot manifesta ca
eșuări la schimbarea împrejurimii în care rulează programul. E xemplele de astfel de modificări
includ: trecerea pe o platformă hardware nouă, alterări în sursa de date sau interacțiunea cu
software diferit . Acestea sunt așa numitele probleme de compatibilititate, ultima versiune a
programului poate să nu mai fie comp atibilă cu acea combinație de software/hardware folosită mai
devreme, sau poate să nu mai fie compatibilă cu un alt sistem . Rezultă faptul că testarea de
compatibilitate este o importantă strategie de prevenire, pentru că u n singur defect poate rezulta
într-un spectru larg de simptome prin care se manifestă căderile.
Una din problemele fundamentale ale testării software este imposibilitatea de a testa un
produs utilizând toate combinațiile posibile de date de intrare și precondiții (starea inițială), a ceast a
se aplică chiar și în cazul unor produse simple.
1.4. Testerul
Testerii sunt priviți de multe ori cu un fel de ură de către inginerii software și de multe ori
acuzați de faptul că procesul testării unui produs este unul distructiv, chiar ofensator către cei care
au dezvoltat programul software. Testerul trebuie sa fie capabil să “se țină de capul ”
dezvoltatorului până când acesta acționează pe baza rezultatelor testării și programul soft poate fi
declarat gata de lansare.
Testarea este o activitate constr uctivă din punct de vedere managerial și al analizei
riscurilor. Pentru a căuta defecte și potențiale erori într -un sistem, este nevoie de multă curiozitate,
pesimism, mare atenție la detalii, spirit critic și analitic și o fire comunicativă, în special cu
dezvoltatorii.
Testerul trebuie să poată prezenta rezultatele testării fără ca dezvoltatorul să se simtă atacat, să nu
uităm că interesul comun trebuie să fie întotdeauna calitatea și eficiența produsului oferit, iar
sentimentul efortului colectiv trebuie să se regăsească în fiecare.
Tester -ul nu este ultima linie de apărare a clientului , nu are rolul de a ține prod usul departe
de client și nici rolul d e a găsi probleme la nesfârșit.
1.5. Fazele procesului de testare
“Fazele procesului de testare sunt: planificarea, analiza și proiectarea, implementarea și
execuția și evaluarea testelor.

10
Planificarea testelor se rea lizează în strânsă legătură cu planificarea derulării proiectului.
În faza de planificare a proiectului pentru testare se alocă resurse, specificându -se bugetul și
perioada de timp în care se va derula testarea. Pe baza acestora se realizează planificarea detaliată
a procesului de testare. Planificarea testării are scopul de a determina ce să testeze și cât să testeze,
astfel încât procesul de testare să se încadreze în limitele resurselor alocate. În urma planificării
testării rezultă planul de test, un do cument pe baza căruia se desfășoară celelalte faze ale testării.
În această fază se identifică și obiectivele testării. Planul de test este un document important, fiind
utilizat ca bază pentru desfășurarea întregului proces de testare. În plus, trebuie ide ntificate și
sursele de risc în testare. Planificarea testării poate să înceapă din momentul în care au fost
elaborate cerințele aplicației software.
În planul de test sunt descrise: aria de cuprindere, responsabilitățile fiecărui membru al
echipei de test are, resursele umane necesare, desfășurarea în timp a testelor, descrierea și
configurarea mediului specific aplicației, lista echipamentelor care trebuie achiziționate, crearea și
managementul datelor de test și criteriile de acceptare a testelor.
Deoarec e este foarte dificil să se stabilească momentul în care se va încheia testarea, în
planul de test se specifică o serie de criterii care constituie o bază pentru determinarea finalizării
testării. Analiza testelor rafinează metodele prezentate în planul de test. Astfel, în etapa de analiză
se identifică următorii pași: identificarea scopurilor, obiectivelor și a strategiilor testării de către
echipa de testare, metodele de verificare sunt asociate cerințelor sistemului sau cazurilor de
utilizare și sunt doc umentate în cadrul unei matrici de urmărire a cerințelor, analiza cerințelor
testelor, construirea matricei cerințelor testelor, în care declarațiile cerințelor testelor sunt asociate
cerințelor sistemului sau a cazurilor de utilizare și asocierea tehnicil or de testare cu declarațiile
cerințelor testelor.
În faza de analiză a procesului de testare, un aspect important îl ocupă analiza cerințelor
pentru testare. Cerințele testării trebuie să fie identificate și documentate astfel încât toate
persoanele impli cate în procesul de testare să fie conștiente de scopul acestuia. Analiza se
desfășoară din mai multe puncte de vedere, depinzând de faza de testare. Astfel se identifică o
abordare structurală și o abordare bazată pe comportament.
Faza de proiectare a tes telor urmează după încheierea analizei. În faza de proiectare, apar
următorii pași: definirea modelului programului de test astfel încât acesta să reflecte tehnicile de
testare utilizate, definirea arhitecturii de test, definirea procedurilor de test, luar ea deciziei de

11
automatizare a anumitor teste și de testare manuală a altor componente, asocierea datelor de test
astfel încât fiecare cerință pentru datele de test să se reflecte pentru fiecare procedură de test.
Programul de test se elaborează fie la nive lul proiectării, fie la nivelul tehnicilor de testare.
În primul caz, procedurile de test sunt asociate componentelor hardware și software ale aplicației,
iar în al doilea caz procedurile de testare sunt văzute la nivelul tehnicilor de testare.
Proiectarea procedurilor de test începe după determinarea cerințelor testării. Proiectarea
procedurilor de test constă în: analiza arhitecturii de test pentru determinarea tehnicilor de testare
relevante, definirea procedurilor de test atât la nivelul sistemului cât și la nivelul de implementare,
elaborarea sau preluarea de standarde de utilizare a procedurilor de test, identificarea procedurilor
de test care vor fi efectuate manual și a celor care vor fi efectuate automat, identificarea
procedurilor de test complexe, pentru a fi proiectate în continuare în faza de proiectare detaliată și
proiectarea detaliată.
În etapa de implementare a testelor sunt construite cazurile de test și procedurile de test, pe
baza rezultatelor fazei de proiectare. Cazurile de test descriu atât parametrii de intrare cât și
rezultatele așteptate după execuție utilizând acei parametri. Realizarea de cazuri de test cât mai
complete duce la descoperirea unui număr mai mare de erori. Procedurile de test identifică toți
pașii necesari pentru execu tarea cazurilor de test specifice. Primul pas în faza de implementare
este inițializarea mediului de implementare prin punerea la punct a arhitecturii dezvoltării testelor.
Un alt aspect important este identificarea standardelor pe care se bazează elaborar ea secvențelor
de test. Dacă au fost definite astfel de standarde de implementare, atunci implementarea se
realizează pe baza acestora. Dacă nu există standarde, în cadrul acestei faze, la început, se stabilesc
convenții de scriere a programelor de test (a linieri, comentarii, prefixe pentru date). Implementarea
secvențelor de test se realizează în limbaje specifice mediilor de testare (asemănătoare Visual
Basic) sau se utilizează limbaje de programare evoluate (C++, Java). Prin reutilizare se folosesc
proce duri de test din proiectele anterioare sau din cadrul aceluiași proiect pentru module care au
părți comune.
Faza de rulare a testelor are ca intrări planul de test și orarul execuției procedurilor de test,
mediul de test fiind pregătit corespunzător. Ieșir ile fazei de execuție a testelor sunt rezultatele
testelor, lecțiile învățate și orarul modificat al testelor. Execuția modulelor se realizează în
conformitate cu planul de test. Procedurile de test descriu intrările și ieșirile așteptate după
execuție. În această etapă din cadrul procesului de testare sunt rulate secvențele de test. Execuția

12
secvențelor de test se realizează pe cât posibil în mediul specific aplicației iar dacă nu este posibil,
acest mediu este simulat.
Rezultatele execuției secvențelor de test sunt evaluate pentru a determina dacă produsul a
trecut testul cu succes. Evaluarea rezultatelor testelor se face de către un oracol. Oracolul este o
persoană sau un instrument automat, care pe baza specificațiilor determină dacă rezultatele
execuție i testelor sunt corecte sau nu.
În figura 1.1 este prezentat fluxul procesului de execuție și evaluare a testelor pentru
testarea la nivel de modul, bazată pe specificații. Rezultatele testelor arată dacă programul a trecut
sau nu testul.

Figura 1.1

Rezultatele execuției testelor se vor memora într -o bază de date care conține și alte
informații referitoare la aplicația software realizată. Execuția și evaluarea testării de integrare
necesită noi secvențe de test pe măsură ce se adaugă module în cadrul structurii programului care
se stează. Aprobarea de către beneficiar a rapoartelor testării de modul și ale testării de integrare
constituie încheierea acestor faze.
În execuția și evaluarea testării de sistem, beneficiarul aplicației se implică mai mult decât
în celelalte faze. În mod asemănător, acesta trebuie să semneze raportul de test pentru a considera
încheiată această fază de testare.”

13
1.6. Tipuri de testare și metodologii de testare
1.6.1. Testarea white box
“Testarea white box (testarea structurală) este o strategie de testare care necesită accesul la
codul sursă și la structura programului și pune accentul pe acoperirea prin teste a căilor,
ramificațiilor și fluxurilor programului. Principalele metode de testare structurală au în vedere
gradul în care cazurile de test acoperă sau execută codul sursă al programului.
Strategiile de testare bazate pe căi utilizează fluxul de control al programului. Acestea
reprezintă o familie de tehnici de testare bazate pe selectarea cu atenție a unei mulț imi de căi din
program. Dacă mulțimea căilor este aleasă corespunzător, atunci se va atinge o anumită măsură a
profunzimii testului. Pentru utilizarea acestor tehnici este necesară cunoașterea completă a
structurii programului și accesul la codul sursă. Te hnicile sunt utilizate cel mai des de către
programatori pentru testarea propriului cod. Cu ajutorul acestei tehnici se detectează erorile care
cauzează execuția unei alte căi a programului decât ac eea care trebuia să se execute.
Graful asociat programului este o reprezentare grafică a structurii de control al
programului, care utilizează elemente ca proces, decizie și joncțiune.
Un bloc de bază este o secvență de instrucțiuni ale programului, neîntrerupte de decizii sau
de joncțiuni.
Un proces are o sing ură intrare și o singură ieșire și constă dintr -o singură
declarație/instrucțiune, dintr -o secvență de declarații/instrucțiuni, un singur apel de subrutină sau
o secvență din acestea.
O decizie este un punct al programului în care fluxul de control contin uă pe una din
alternativele oferite. Construcțiile if -then-else și switch -case sunt exemple de decizii cu două
ramuri, respectiv cu n ramuri, n≥2.
Joncțiunile sunt punctele din program în care fluxul de control se unește, care pot fi
etichetele țintă ale u nui salt, punctele în care se unesc ramurile unei instrucțiuni if -then-else etc.
O cale într -un program este o secvență de instrucțiuni care începe cu o intrare, joncțiune
sau decizie și se termină la altă (sau aceeași) joncțiune, decizie sau ieșire. O ca le poate să treacă
prin câteva joncțiuni, procese sau decizii o dată sau de mai multe ori. Un segment constă dintr -o
succesiune de legături consecutive care aparțin aceleiași căi.
Lungimea unei căi este dată de numărul de legături și nu de numărul de decla rații sau
instrucțiuni executate de -a lungul căii. O metodă alternativă de măsurare a lungimii unei căi este

14
numărul de noduri traversate. Dacă programul are un singur nod de intrare și un singur nod de
ieșire, numărul de legături traversate este mai mic c u unu decât numărul nodurilor traversate.
Numele căii este dat de numele nodurilor de -a lungul căii. De exemplu în cadrul unei
aplicații, diverse secvențe de program au graful asoci at asemănător celui din figura 1.2 . Nodurile
sunt numerotate corespunzător fluxului secvenței de program. O cale de la punctul de intrare până
la ieșire se notează de exemplu cu 1 -2-3-5-6-7-9-10. În mod asemănător, dacă se notează legăturile,
numele căii este dat de succesiunea numelor legăturilor de -a lungul căii. Pentru aceeași cale,
numele ei este abcfghk. În practică , o cale de test este o cale care începe în punctul de intrare în
program și se termină la ieșirea din program.

Figura 1.2 – Nodurile și legăturile grafului asociat unei secvențe de program.

Tehnicile de testare bazate pe căile programului au la bază o serie de criterii de acoperire
a codului care se testează precum: acoperirea instrucțiunilor, acoperirea ramificațiilor, acoperirea
condițiilor, acoperirea ramificațiilor și a condițiilor, acoperirea condiți ilor multiple și acoperirea
tuturor căilor programului. Pe baza acestor criterii de acoperire a codului se determină seturile de
date de test care se utilizează în testările structurale corespunzătoare: testarea instrucțiunilor,
testarea ramificațiilor, te starea căilor etc.
Criteriul pentru acoperirea instrucțiunilor este ca fiecare instrucțiune să fie executată cel
puțin o dată în cadrul unor teste. Dacă se realizează acest obiectiv, atunci declarațiile sunt acoperite

15
în proporție de 100%. Acest lucru este echivalent cu o acoperire a nodurilor fluxului de control
asociat programului în proporție de 100%. Criteriul de acoperire a instrucțiunilor este criteriul cel
mai slab, deoarece cazurile de test identificate astfel încât să fie acoperite toate instrucțiu nile iau
în calcul doar acest criteriu, nefiind tratate toate situațiile posibile. Acest criteriu de acoperire se
mai numește și criteriul C1.
Acoperirea ramificațiilor are drept criteriu ca fiecare ramură a unei decizii să fie executată
cel puțin o dată. Se rulează un număr suficient de teste pentru a se executa toate ramificațiile din
program cel puțin o dată. În cazul în care s -a realizat acest lucru, se atinge un procent de 100% a
acoperirii ramificațiilor sau echivalent de acoperire a legăturilor dintr e nodurile grafului asociat
programului. Pentru software -ul structurat testarea tuturor ramificațiilor include și acoperirea
tuturor declarațiilor. Criteriul de acoperire a ramificațiilor se notează cu C2.
Acoperirea condițiilor are ca obiectiv identificar ea de date de test astfel încât fiecare
condiție cu rezultat logic să ia valorile posibile (adevărat sau fals).
În secvența: "if(criteriu!=null && !criteriu.equals(""))" , pentru acoperirea ramificațiilor
sunt necesare două cazuri de test corespunzătoare ce lor două ramuri, iar pentru acoperirea
condițiilor sunt necesare patru cazuri de test corespunzătoare combinațiilor adevărat sau fals pentru
cele două condiții.
Pentru acoperirea ramificațiilor și condițiilor criteriul de parcurgere a codului sursă este o
combinație a criteriilor de la acoperirea ramificațiilor și acoperirea condițiilor. Criteriul de
acoperire a condițiilor multiple are ca scop execuția cel puțin o dată a fiecărei combinații de stări
posibile ale condițiilor.
Acoperirea tuturor căilor progr amului are ca obiectiv execuția tuturor căilor fluxului de
control din program, care încep la intrarea în program și se termină la ieșirea din program. Dacă
se reușește să se îndeplinească acest criteriu, atunci se acoperă căile în proporție de 100%. Acest a
este cel mai puternic criteriu din familia de strategii de testare bazate pe căi și este, în general,
imposibil de atins deoarece numărul de căi poate ajunge foarte mare, mai ales prin existența
structurilor repetitive.
Acoperirea declarațiilor și a rami ficațiilor sunt cerințe minime obligatorii pentru testarea
structurală. Pentru programele care conțin bucle, acoperirea marginilor interioare (boundary –
interior cover) este deseori utilizată pentru a executa bucla cel puțin de două ori. În primul caz se

16
execută bucla fără iterații, iar în al doilea caz se execută bucla cu una sau mai multe iterații. Dacă
testarea se realizează utilizând doar analiza căilor sunt detectate circa 25% din erori.
Testarea fluxului datelor utilizează graful fluxului de control p entru a studia anomaliile
fluxului de date. Acest tip de testare formează o familie de strategii de test bazate pe selecția unei
căi din fluxul de control al programului în scopul cercetării secvențelor de evenimente referitoare
la starea datelor.
Testarea fluxului de date se bazează pe faptul că cel puțin jumătate din codul sursă constă
în declarații de date, declarații care definesc structuri de date, obiecte individuale, valori inițiale
(sau implicite) și atribuite. Graful fluxului datelor este alcătuit din noduri și legături direcționate.
Obiectivul său este acela de a prezenta deviațiile de la fluxul de date implementat față de ceea ce
s-a dorit la proiectare. Acțiunile posibil de efectuat asupra datelor sunt:
● definire (d); este explicită, când variabil a apare într -o declarație de date și implicită, când
variabila este într -o instrucțiune de atribuire;
● nedefinire (k); atunci când data nu mai este disponibilă sau când conținutul ei nu este cu
certitudine cunoscut;
● utilizare (u):
○ în calcule (c); variabila apare în partea dreaptă a unei atribuiri, într -o expresie de
calcul;
○ într-un predicat (p); când apare direct, de exemplu if (a<b), sau în condiția de ciclare
a unei bucle.
Anomaliile sunt reprezentate prin secvențe de două acțiuni:
● dd – variabilă definită, dar nereferită;
● ku – variabilă nedefinită, dar referită;
● dk – variabilă definită, dar nereferită.
Situațiile normale sunt du, kd, ud, uk, uu. La un moment dat, în cadrul unei căi pot exista situațiile
din tabelul 1.3 .

Situație Descriere
-k anomalie
-d situație normală

17
-u anomalie, dacă variabila nu este globală
k- situație normală
d- posibilă eroare
u- utilizată fără a fi dostrusă
Tabelul 1.3 – Situațiile posibile ale datelor

O variabilă se află într -una din următoarele stări:
● K – nedefinită, inexistentă;
● D – definită, dar neutilizată;
● U – utilizată;
● A – anomalie.

În figura 1.4 sunt prezentate secvențele de acțiuni prin care o variabilă trece dintr –
o stare în alta.

Figura 1.4 – Graful stărilor unei variabile

Strategiile de test are pe baza fluxurilor datelor sunt:
● all-use: se consideră o cale care începe cu definirea unei variabile și se încheie la prima
utilizare a acesteia;
● c-use: căile încep cu definirea variabilelor și se încheie cu instrucțiunea în care variabilele
sunt folo site în calcule;
● p-use: o cale începe cu definirea unei variabile și se termină la instrucțiunea în care
variabila este utilizată într -o condiție logică;
● du-use: constă în parcurgerea tuturor fluxurilor de forma definire -utilizare pentru fiecare
dată care apare în program.

18
Strategia de testare pe baza fluxurilor datelor utilizată cel mai des este strategia du -use.”
1.6.2. Testarea black box
“Testarea black box sau testarea funcțională este o strategie de testare care necesită
cunoașterea comportamentului extern al programului pe baza specificațiilor. Testarea funcțională
nu necesită cunoașterea structurii interne a programului sau cunoștințe despre modul în care este
implementat programul sau modulul.
Principalele tehnici de testare funcțională sunt testar ea cu intrări aleatoare, partiționarea pe
clase de echivalențe, analiza valorilor limită, graful cauză -efect și ghicirea erorilor.
Testarea cu intrări aleatoare pornește de la domeniul datelor de intrare și constă în
generarea de date de test în mod aleato r, în cadrul domeniului acestora. Este o tehnică slabă de
testare, cu cel mai mic procent de descoperire a erorilor. Această tehnică de testare a fost
dezvoltată, astfel încât datele de test sunt alese aleatoriu din domeniu și sunt filtrate astfel încât să
îndeplinească anumite condiții, ca de exemplu producerea unui rezultat dintr -o clasă de ieșiri
posibile.
Partiționarea pe clase de echivalențe constă în împărțirea domeniului datelor de intrare în
subdomenii, astfel încât comportamentul programului să fie același, cel puțin teoretic, pentru orice
dată de intrare din subdomeniul corespunzător. De exemplu, pentru funcția care returnează valoare
absolută a unui număr întreg, un subdomeniu ar fi intervalul numerelor strict negative, iar un alt
subdomeniu ar fi cel al numerelor pozitive. Dintr -un număr ridicat de cazuri de test posibile se
ajunge la două cazuri de test.
Caracteristicile partiționării pe clase de echivalențe sunt:
● domeniul datelor de intrare este împărțit în clase de echivalențe;
● elementele din aceeași clasă sunt tratate în mod asemănător;
● de asemenea se are în vedere partiționarea ieșirilor;
● se consideră atât clasele valide cât și cele invalide;
● pentru testare se alege cel puțin un element din fiecare clasă de echivalență.
Prin utilizarea analizei valorilor limită pentru realizarea cazurilor de test, pentru fiecare
parametru al funcției se determină un set de valori aflate la limita domeniul de validitate. Analiza
valorilor limită se concentrează asupra valorilor de la limita claselor de ec hivalențe și sunt avute
în vedere limitele atât în spațiul intrărilor cât și în spațiul ieșirilor. Dacă l i este limita inferioară și

19
ls este limita superioară a domeniului unei date de intrare de tip numeric, pentru aceasta se vor
construi următoarele cazu ri de test: l i-1, li, li+1, ls-1, ls și ls+1.
Pentru parametrii de tip șir de caractere de lungime maximă L se aleg ca exemple de test:
● șirul vid;
● șirul având un caracter;
● șirul de lungime L -1;
● șirul de lungime L;
● șirul de lungime L+1.
Graful cauză -efect este o tehnică pentru alegerea cazurilor de test într -un mod sistematic și
are la bază un limbaj formal în care sunt translatate specificațiile bazate pe limbajul natural. Cauza
este o condiție distinctă de intrare sau o clasă de echivalență iar efectul este o condiție de ieșire sau
o transformare a sistemului.”
1.6.3. Testarea de module
“În cadrul testării de module se realizează verificarea celor mai mici unități software care
pot fi compilate și link -editate independent. În programarea clasică un mod ul este un subprogram
(funcție sau procedură). În cadrul programelor orientate obiect, cea mai mică unitate testabilă este
clasa.
Testarea de module se concentrează asupra verificării interfețelor modulelor, structurilor
de date locale, condițiilor de la l imite, căilor independente și căilor de tratare a erorilor. Deoarece
modulele nu sunt programe de sine stătătoare, este necesar să se construiască programe sau funcții
care să ajute la testarea de module.
O primă categorie o reprezintă programele conducăto are (drivers) care apelează modulele supuse
testării cu datele de test construite și preiau rezultatele execuției.
O altă categorie este reprezentată de funcțiile sau procedurile apelate de către modulul de
testat. Acestea sunt substituite cu subprograme c are au același prototip, însă cu funcționalitate
redusă la minim, denumite module vide (stubs). Modulele vide sunt funcții sau proceduri simple
care nu fac nimic în afara returnării controlului, sau sunt funcț ii sau proceduri complexe, care
simulează efec tul apelării modulelor reale. În cele mai multe cazuri, modulele vide simple sunt
nepotrivite. Un efort considerabil este necesar pentru implementarea de module vide complexe.”

20
1.6.4. Testarea de integrare
“Testarea de integrare este o tehnică sistematică de construire a structurii programului prin
gruparea componentelor în paralel cu testarea aspectelor legate de interfața dintre componente.
Testarea de integrare se realizează într -o manieră neincrementală sau incrementală.
Testarea neincrementală (big -bang testing) constă în integrarea componentelor prin
gruparea tuturor modulelor dintr -o dată, urmată de testarea întregului ansamblu. Acest tip de
integrare nu este recomandată, deoarece corectarea erorilor va fi foarte greu de realizat.
Testarea incrementa lă presupune construirea structurii programului pas cu pas și testarea
ansamblului obținut. Un element important în execuția testului este secvența în care modulele
trebuie să fie testate. Astfel, testarea de integrare se realizează ascendent (bottom -up), descendent
(top-down) sau mixt.
Metoda de testare ascendentă (bottom -up testing) presupune testarea mai întâi a modulelor
de pe cel mai de jos nivel al ierarhiei programului, apoi se continuă în sus cu testarea celorlalte
module. Metoda de testare ascenden tă necesită construcția de programe conducătoare pentru a
inițializa mediul și pentru a apela modulele. Programele de pe nivelul de sus, care de obicei sunt
critice, sunt testate ultimele. În timp sunt descoperite erori care pot influența multe module care au
fost deja testate. După corecția erorilor este necesar ca toate modulele de pe nivelurile de jos să fie
testate regresiv.

Figura 1.5 – Testarea de integrare ascendentă

În figura 1.5 este prezentat un exemplu de testare de integrare ascendentă. În c adrul unei
aplicații, modulele Adaugă, Caută, Modifică și Edit sunt integrate și testate, modulul ”Agenda
mea” fiind înlocuit cu un modul conducător, care le apelează.

21
În metoda testării descendente (top -down testing), modulul din vârful ierarhiei de programe
este testat primul, procesul de testare continuând cu modulele de pe nivelurile inferioare. Metoda
de testare descendentă necesită construcția de module vide asociate subprogramelor care nu sunt
disponibile. Avantajul acestei metode este că dacă e ste descoperită o eroare în modulele de pe
nivelurile înalte, impactul va fi asupra modulelor de pe nivelurile de jos care nu au fost încă
implementate, deci refacerea modulelor de pe nivelurile inferioare poate fi evitată.
În figura 1.6 de mai jos se prez intă un exemplu al testării de integrare descendentă.
Modulele ”Agenda mea”, Adaugă și Caută sunt deja integrate și testate, modulele Modifică și Edit
fiind înlocuite cu module vide.

Figura 1.6 – Testarea de integrare descendentă
În cadrul metodei mixte, testarea urmează mai întâi metoda descendentă. Modulele
selectate de pe nivelurile inferioare sunt testate utilizând metoda ascendentă. Această flexibilitate
permite preluarea avantajelor metodelor de ascendență și descendență. În cele mai multe aplicații ,
metoda mixtă este cea mai potrivită modalitate de abordare.
Pe măsură ce sunt adăugate noi module în cadrul testării de integrare, apar schimbări în
aplicatie, care pot să modifice comportamentul structurii obținute anterior. În acest context este
execut ată testarea de regresie, prin care se re -testează noua structură obținută, utilizând o parte din
testele utilizate în etapa precedentă de integrare.”
1.6.5. Teste de regresie
Testarea de regresie este retestare a funcționalităților existente după ce a fos t adăugată
funcționalitate nouă în aplicație sau anumite p ărti ale codului au fost schimbate . Pentru testarea de
regresie se refolosesc testele cu impactul cel mai mare, acestea fiind cele mai importante, și cele

22
care acopera cazuri folosite des de către utilizatorul final, și se retestează pentru a se asigura ca
funcțional itatea veche nu a fost afectată de noile schimbări.
Testarea de regresie poate fi funcți onală sau non funcțională, atât timp cât aduce valoare si
îmbunatățiri aplicației și asigurarea fa ptului că a rămas cel putin la același standard de calitate ,
dacă nu chiar mai bun în cazul în care, prin modificarea codului s -a ajuns la o performanță mai
bună a aplicației .
Testarea regresivă este recomandabil să fie și automatizată p entru a fi mai efic ientă și
pentru a economisi resurse (în speță timpul testerului) , astfel reducând costurile . Deoarece aceste
teste pot fi rulate de foarte multe ori pe parcursul ciclului de viață al programuli software.
1.6.6. Teste de validare
“Testarea de validare are loc după ce toate erorile de interfață descoperite în cadrul testării
de integrare au fost corectate. Testarea de validare se încheie cu succes atunci când funcționalitatea
aplicației este în conformitate cu cerințele beneficiarului. Pentru testarea de val idare se utilizează
o serie de teste funcționale pentru a confirma faptul că aplicația software se comportă conform
cerințelor.
În cadrul testării de validare se regăsesc testările alfa și beta. Testarea alfa este realizată la
firma care produce aplicația, beneficiarul fiind acela care conduce testele. Testarea beta este
realizată la beneficiari și utilizatori finali. Aceștia primesc o versiune a aplicației, versiune
apropiată de cea finală și o utilizează în scopul descoperirii erorilor și a problemelor de
performanță și funcționalitate. Problemele apărute în cadrul acestei testări sunt raportate firmei
care a realizat aplicația. După ce perioada acordată pentru testarea beta s -a terminat, toate erorile
apărute sunt corectate, urmând să se realizeze versiun ea finală a aplicației.”
1.6.7. Teste de performanță
“Testarea de performanță are ca scop măsurarea performanțelor reale ale unui sistem sau a
unei aplicații, comparativ cu cele teoretice. Metrica de performanță ce trebuie măsurată variază de
la o aplicaț ie la alta. Pentru a stabili performanțele unei aplicații, avem nevoie de urmatoarele
masurători: timp de răspuns, ieșirile sistemului si utilizarea resurselor. Dacă rezultatele
masurătorilor de performanță sunt nemulțumitoare, atunci se vor lua măsuri spe cifice pentru
îmbunătățirea aplicației. Pentru a atinge nivelul de performanță dorit se va rescrie sau îmbunătăți
zone de cod, se vor aloca mai multe resurse sau se va restructura sistemul pe baza căruia
funcționează aplicația.“

23

1.6.8. Testarea de compati bilitate
Testele de compatibilitate au fost create datorită problemelor întalnite pe parcursul anilor
din ciclul de viață al produsului , cauzate de interacțiunea aplicației software cu o alta aplicație sau
cu sisteme le de operare pe care acestea rulează , dar și datorită non -conformităților apărute de la o
versiune la alta a programului, pe parcursul procesului de dezvoltare incrementală a unei aplicații.
Incompatibilitățile apărute de la o versiune la alta , de cele mai multe ori sunt datorate faptului că
la momentul codării , aplicația a fost verificată sau testată de programator doar pe un singur sistem
de operare, fără a lua în considerare faptul că pot apărea probleme la schimbarea contextului de
execuție.
O altă cauză care poate provoca incompatibilitat ea programului soft este incompatibilitatea
hardware, o aplicație poate funcționa perfect la momentul lansării acesteia, dar după ani de
îmbunătățiri și adăugarea de noi funcții aceasta se poate să nu mai functioneze în parametrii sau
chiar deloc pe siste mele cu hardware vechi, care nu mai fac față noilor tehnologii.

1.6.9. Testarea de a ccesibilitate
Testele de accesibilitate a u apărut pentru c ă scopul unei aplicații software este să poată fi
folosită de cât mai mulți utilizatori. Nu toți utilizatorii au aceleași abilități când vine vorba de
utilizarea unui computer sau a unei aplicații. Din această cauză se impune utilizarea standardelor
de accesi bilitate în momentul în care se dezvoltă o aplicație software.
Design -ul unei aplicații trebuie să ia în considerare faptul că unii utilizatori pot suferi de
anumite dizabilități de auz, vedere, scriere, utilizare a tastaturii și mouse -ului sau chiar fapt ul că
anumite abilități se estompează în timp (persoanele vârstnice). Dincolo de aceste probleme există
impedimente de alt tip, cum ar fi analfabetism funcțional, necunoașterea jargonului tehnic sau chiar
a limbii în care este realizată aplicația.
Există o suită de dizabilități și handicapuri care pot prezenta impedimente în utilizarea unui
computer. Aceste dizabilități, care pot fi dobândite în urma unor boli, traume sau pot fi congenitale,
includ, dar nu sunt limitate de:
 Dizabilități cognitive (apărute d in cauza unor lovituri la cap, autism sau
dizabilități de dezvoltare) și dizabilități de învățare cum sunt dislexia,
discalculia sau ADHD,

24
 Handicapuri de vedere cum ar fi vedere slabă, daltonism, orbire parțială sau
totală,
 Handicapuri legate de auz cum ar fi surzenie, auz parțial sau hiperacuzie,
 Deficiențe motrice sau de dexteritate cum sunt paralizia, paralizie cerebrală,
dispraxie, sindrom de tunel carpian sau accidentări repetate din cauza efortului.
În cazul în care aplicația web promite că va fi acce sibilă pentru dizabilitățile menționate mai sus,
aceasta va trebui testată pentru asigurarea faptului că atinge un anumit standard/grad de
accesibilitate.

1.6.10. Testarea automată
“În noua economie, producătorii de soluții IT sunt confruntați cu o nouă cerință care îi
obligă să schimbe total modul de construcție a unui produs, fără a face compromisuri de calitate.
A fi primul pe piață cu ultimele tehnologii este mai important ca oric ând. Lucrând cu o
infrastructura software și hardware din ce în ce mai complexă, confruntați cu creșterea continuă a
cerințelor de calitate și cu necesitatea reducerii costurilor, firmele de software încep să prețuiască
tot mai mult soluții solide, inginer ești, de dezvoltare de software.
Testarea produsului este în software o componentă majoră în procesul de dezvoltare. În
limbaj de specialitate se discută despre asigurarea calității (Quality Assurance). Firmele din
industria tradițională – de ex. industri a de mașini, de construcții, de produse electronice sau
alimentare au de zeci de ani departamente de testare și verificare a calității. În materie de software,
organizarea și automatizarea muncii de testare și verificare a produselor a început din motive
istorice evidente abia în anii '80.
Testarea manuală, mult timp văzută ca singura soluție de a descoperi eventualele defecte,
întârzie foarte mult lansarea pe piață a produsului și induce cheltuieli semnificative mai ales în
cazul descoperirii efectelor la terale – atât în procesul dezvoltării unei aplicații cât și în cazul de
schimbări ulterioare. Totodată procedurile de testare manuală, prin natura lor limitată, nu reușesc
să descopere toate defectele și nu au nici o șansă să simuleze condiții de utilizare simultană,
intensivă, a unei aplicații. Există numeroase căi de a îmbunătăți procesul de testare, una dintre cele
mai eficiente fiind testarea automată.
Testele automate execută o secvență de acțiuni fără intervenție umană și pot simula
utilizarea unei a plicații în condiții de simultaneitate ridicată. În general, majoritatea produselor

25
necesită să fie testate de mai multe ori, pe mai multe platforme software și hardware, ca și după
schimbările ulterioare sau la lansarea unei noi versiuni de produs. Prin f olosirea testării automate,
costurile testărilor repetate se reduc aproape la zero.
Cele mai importante beneficii sunt:
● acoperirea tuturor etapelor de testare de la concepție până la lansare
● posibilitatea simulării testării cu mai mulți utilizatori
● posibilitatea repetării testelor
● creșterea siguranței în produs
Un sistem de testare automată trebuie să aibă la bază două caracteristici principale:
● module reutilizabile
● întreținerea și urmărirea activității dintr -un singur punct de control
De aceea una din calitățile care trebuie să le aibă un astfel de sistem este capabilitatea de a
fi ușor configurat și adaptat în același ritm cu software -ul ce se testează . Sistemele de testare
automată sunt o tehnologie în plină dezvoltare care au ca scop descope rirea și raportarea
eventualelor defecte, mărirea longevității produsului și reducerea procesului de întreținere.
Testarea automată înseamnă mai mult decât o simplă captură de ecran și răspunsul la câteva
scripturi : ea trebuie să înceapă cu planificarea ș i design -ul procedurii de testare, să conțină o serie
de teste repetabile, o interfață de management al scenariilor de test și un mecanism de raportare și
gestionare a bug -urilor descoperite în urma testării. Un sistem de test evoluat sprijină utilizatorii
printr -un sistem de documentare pe tot parcursul acestui proces.“

26
Capitolul 2 : T estarea automat ă de interfață cu ajutorul Selenium Webdriver –
Prezentarea Selenium Framework
2.1. Introducere – Descrierea Selenium F ramework
Selenium este un framework de testare pentru pagini și soluții web. Acesta oferă o gamă
destul de largă de opțiuni pe care inginerii calității sau de testare (Quality Engineer pe scurt QE )
le utilizează pentru a dezvolta soluții de testare automată asupr a aplicațiilor web pe care aceștia
doresc să o testeze automat , astfel încât să se asigure menținerea și îmbunătățirea consitenței din
punct de vedere a calității aplicației .

2.2. Opțiunile puse la dispoziție de Selenium
Frameworkul Selenium este av antajos în mod special datorită rapidității cu care poate fi
utilizat deoarece poate fi folosit și de către persoane care nu au abilități avansate de programare.
De exemplu, cu ajutorul Selenium IDE (o extensie creată de echipa de dezvoltare Selenium)
utilizatorii pot folosi opțiunea de înregistrare a testelor , după care aceștia au posibilitatea să ruleze
programul de câte ori este nevoie din cadrul Selenium IDE . Acest mod de “creare” a testelor
automate , prin Selenium IDE , chiar dacă este una din cel e mai rapide opțiuni de creare de teste
automate suportată de Selenium, nu este și cea mai bună din punct de vedere al eficienței și
consistenței deoarece la orice schimbare, c ât de mică a structurii sau organizării elementelor pe
pagină, probabilitatea ca un test să cadă e foarte mare – mai bine zis poate să indice faptul că testul
nu și -a atins scopul final, rezultând astfel un timp mare necesar întreținerii și verificării suitei de
teste automate .
O altă foarte importantă opțiune pusă la dispoziție de Selenium este aceea de a genera un
așa-zis “domainspecific language ” care poate fi integrat în mai multe limbaje de programare
precum: C#, Java, PHP, Python, Ruby etc., pentru a putea apela și utiliza mai multe metode din
Selenium Client API. Utilizând opțiunea de mai sus, Selenium pune la dispoziție așa numit ul
Selenium Remote Control cu ajutorul căruia utilizatorii acestui framework vor putea scrie teste
automate în orice limbaj de programare vor dori, fiind mai ușor ca Sele nium să fie introdus mai
apoi în soluția de teste automate.
Opțiunea folosită pentru dezvoltarea suitei de teste care va fi prezentată în capitolul ce
urmează, pusă la dispoziție de Selenium este Selenium WebDriver, va fi detaliată în urmatoarele
paragraf e și ulterior pe parcursul prezentării proiectului . Cu ajutorul Selenium WebDriver putem

27
trimite comenzi specifice pentru fiecare browser cu ajutorul unui Driver special (diferit pentru
fiecare browser) pentru mai multe browsere, printre care se numară: Google Chrome, Firefox,
Internet Exprorer, Microsoft Edge etc.. De asemenea , Selenium WebDriver poate primi la rândul
lui răspunsuri , detalii și validări în legătură cu elementele accesate de către driver . Odată cu
folosirea Selenium WebDriver avem acces și la o nouă opțiune pe care Selenium ne -o pune la
dispoziție, și anume Selenium Grid. Prin intermediul Selenium Grid putem accesa mai multe stații
simultan pentru a ne rula testele automate în mai multe browsere, versiuni de browsere diferite ,
versiuni de s isteme de operare etc. în același timp, reducând semnificativ timpul necesar rulării
suitei de teste , chiar dacă setarea inițială durează ceva mai mult decat la testele automate clasice .

2.3. Ident ificarea elementelor din pagină
În generarea testelor automate de interfață principalul scop este operarea asupra
elementelor aflate în interiorul paginii pe baza căreia vom scrie funcțiile și metodele necesare
automatizării.
Este foarte important și de bază să putem identifica elementele în mod unic , astfe l încât
apelarea metodelor care indică elementul asupra căruia vrem să acționăm să nu poată indica și un
alt element situat în aceeași pagină , acest lucru putând cauza ma ri probleme și confuzie la rularea
testelor automate, reducând astefel productivitatea din cauza nevoii de a reface testele ulterior .
Pentru ca aspectul menționat mai de vreme să fie accesibil utilizatorului de rând , WebDriverul
oferit de Selenium ne pune la dispoziție o varietate destul de mare de moduri prin care putem
identifica, verific a și accesa elementele din pagină dorite, printre care se enumeră și:
 ClassName
 CssSelector
 Id
 LinkText
 Name
 PartialLinkText
 TagName
 Xpath etc.

28
Din punct de vedere al eficienței și consitenței în generarea testelor automate este
recomandabilă utilizarea Id -urilor deoarece acestea pot fi atribuite în mod unic și este foarte rară
modificarea lor în timp. Dar, pentru a ne putea folosi de Id -urile el ementelor, ca bun ă practică,
aplicația web trebuie construită cu Id -uri de la începutul proiectului, astfel încât să se poată integra
cât mai ușor o soluție de teste automate care va fi construită și dezvoltată odată cu aplicația web.
Altfel, o adăugare ul terioară a Id -urilor pe fiecare element din pagină poate fi considerat neviabil
și ineficient din punct de vedere al timpului.
Chiar dacă utilizarea Id -urilor reprezintă cel mai eficient și sigur mod de identificare a
elementelor din pagină din punct de vedere al standardelor de generare ale testelor automate, și
celelalte atribute reprezintă o variantă convenabilă în anumite situații . Singurul minus îl reprezintă
faptul că, cel puțin pentru unele cazuri, structura și conținutul paginii utilizat e se poate modifica
în timp. Acest lucru va duce la un timp puțin mai mare acordat mentenanței testelor automate , fiind
necesara reidentificarea elementelor necesare pentru test . Cu toate acestea, utilizarea Xpath -urilor
poate fi considerată o variantă aproape la fe l de bună ca cea a utilizării Id -urilor asignate /asociate
elementelor, deoarece Xpath este generat automat și este un element principal al standardului W3C
WSLT. Xpath -ul poate fi identificat utilizând diferite AddOn -uri și extensii pentru browsere , dar
și cu ajutorul funcționalit ății de “developer tools” nativă fiecărui browser, prin apasarea tastei F12 ,
putem genera automat XPath -ul unui element , uneori acesta nu este generat in forma sa ideală așa
că dezvoltatorul testelor trebuie să aibe cunoștințe de bază legate de HTML .
În imaginea (Figura 2.1) de mai jos se poate vedea cum putem genera Xpath -ul butonului
de meniu din pagina de start a paginii web ce urmează a fi prezentată ulterior. Accesând browser –
ul Google Chrome și utilizând intrumentele de dezvoltator (developer tools) , prin apăsarea tastei
F12, se dă click dreapta pe element, se alege funcția “inspect element”, dup ă care se dă click
dreapta pe codul corespunzător elementului și se selectează optiunea “copy Xpath”, odat ă ce
Xpath -ul este co piat se poate folosi în codul testului pentru identificarea elementului paginii web.

29

Figura 2.1 – Copierea XP ath-ului corespunz ător unui element din pagină

Figura 2.2 – Forma XPath -ului pentru elementul prezentat

30
2.4. Acțiuni asupra element elor din pagină
WebDriver -ul de Selenium ne pune la dispoziție o serie de metode predefinite în interiorul
acestuia prin care putem realiza diferite acțiuni asupra elementelor fără ca noi să fim nevoiți să
creăm sau să redefinim aceste metode.
Printre metodele puse la dispoziție de WebDriver putem regăsi atât metode care ne
returnează una sau mai multe valori:
 FindEle ment
 FindElements
 GetAtribute
cât și metode care ne ajută la utilizarea , accesarea și modificarea elementelor din pagină:
 Clear
 Click
 Displayed
 Enabled
 Location
 Selected
 Sendkeys
 TagName
 Text etc.

2.5. Assert și Verify
Selenium WebDriver are în compoziția sa două mari modalități prin care putem să
verificăm că datele prezente de aplicație în urma rulării unui test sau unei su ite de teste sunt cele
asteptate de către tester , aceste verificări facându -se în interiorul testelor automate. Cele două
modalități sunt definite cu ajutorul comenzilor Assert și Verify. Singurul impediment este
reprezentat de faptul că în momentul în care testul , cu ajutorul unui Assert , va găsi o diferență între
datele prezente în pagină si rezultatul asteptat și definit în construcția Assert -ului, testul va cădea,
adică t estul se va o pri fără a continua mai departe.
Dar dacă se va folosi metoda de V erify, testul va identifica o diferență, iar testul își va
continua rularea mai departe.

31
WebDriver ul Selenium ne pune la dispoziție, prin intermediul celor două metode ,
posibilitatea de a ne asigura că rezultatul obținut de comandă este: fals, adevărat, n ul, nu este nul
etc.

Capitolul 3: Prezentarea și executarea soluției de teste automate
3.1. Introducere
Scopul acestei prezentări este punerea în evidență a beneficiilor aduse proiectului de către
testarea automată, în cazul de față aceasta a fost concepută pentru a reduce semnificativ timpul de
retestare al aplicației după eventualele schimbări de cod făcu te de către dezvoltatori asupra
aplicației, astfel asigurându -se că programul software (pagina web în cazul nostru) existent rămâne
neschimbat din punct de vedere al calității și funcționalității.
Aplicația ce urmează să fie testată automat este o aplicaț ie reală, aflată înca în stadiul de
dezvoltare și îmbunătățire, dar care are deja și o versiune accesibilă de către publicul larg.
Această aplicație este RAM – Reasearch Activity Managment , o aplicație concepută pentru
Universitatea din Oradea pentru gest ionarea lucrărilor publicate de către profesorii acesteia. În
primă fază s-a dorit elaborar ea unor formulare necesare fiecă rui cadru didact ic pentr u adăugarea
informațiilor lucră rilor pe care aceștia doresc să le publice.
Accesul în aplicație se face pe b aza unui nume de u tilizator și a unei parole, la momentul
scrierii acestei lucrări numele de utilizator și parola pot fi dobândite la cerere, aplicația find încă
în stadiul incipient.
Așadar, proiectul conț ine 3 tipuri de formulare:
 Publicaț ii
 Proiecte
 Brevete
 etc. (ulterior se vor adăuga și alte tipuri de formulare)
fiecare dintre acestea fiind structurate după nevoia cadrelor didactice.

32

Figura 3.1 .1 – Pagina principală RAM

Figura 3. 1.2 – Formularul de adăugare publicație

33

Figura 3 .1.3 – Formularul de adăugare proiect

Figura 3 .1.4 – Formularul de adăugare brevet

34
Cu toate acestea, in forma prezentă a aplicației, veți observa că există si un al 4 -lea tip de formular
și acesta e : Autori Externi.

Figura 3 .1.5 – Formularul de adăugare autor extern

Intr-o primă fază, aplicația a fost gândită să gestioneze lucră rile publicate strict de caderele
didactice a Univer sității din Oradea urmând a fi extinsă ulterior la nivel de țară . Cu toate acestea ,
o lucrare publicata are unul și/sau mai mul ți autori, acești autori pot fi cu siguranță cadre didactice
ale altor universități din țară, însă aceștia neavând posibilitatea creării unui cont în aplicație, vor fi
introduș i manu al de autorii interni ai aplicației(toți profesorii Universităț ii din Orad ea care au cont )
în secț iunea formularului de Autori Extern i, mai apoi aceștia fiind “legaț i” de entitățile(Proiecte,
Pulicații, Brevete) de care aparțin.

Figura 3. 1.6 – Autor extern adăugat la o publicație

35
Fiecare nouă funcționalitate sau element al aplicației trece prin câteva etape. Pentru început
el este descris în detaliu de către partea interesată, după care el ajunge într -o listă (cu priorități)
alcătuită din alte funcționalități și elemente ce trebuie sc introduse în aplicație, dar și defecte/buguri
găsite de către tester.
Inginerul calității se asigură că acea nouă parte a aplicației să aiba cât mai puține probleme,
înainte de a o accepta și de a ajunge în producție și mai apoi la utilizatori. Dacă o rice problemă a
fost găsită, testerul poate să reîntoarcă elementul din starea de testare în starea de dezvoltare , pentru
ca dezvoltatorul să îmbunătățească funcționalitatea.
Când noua zonă a fost reparat ă și retestat ă, inginerul calității va inițializa p rocesul de testare
de regresie, pentru a se asigura că alte zone deja existente și funcționale ale aplicației nu au fost
modificate fără a se vrea acest lucru. Aici se poate observa beneficiul unei suite de teste automate,
care poate fi rulată dupa fiecare iterație nouă de cod. După această testare elementele vor fi
adăugate aplicației existente și utilizatorii vor putea beneficia de noile funcționalități și
îmbunătățiri aduse aplicației .

Figura 3 .1.7 – Stările ș i etapele elementare ale noului element într-un ciclu de dezvoltare

Deci pentru îmbunătățirea calității produsului, dar și pentru reducerea timpului necesar
testării de regresie manuală, am dezvoltat o suită de teste automate, care va rula de fiecare dată
când dezvoltatorul va termina de implementat o funcționalitate nouă. Testele automate sunt de
obicei împartite pe trei categorii: teste de integrare, teste funcționalte și teste Unit (white box).

36
Testele de integrare și cele funcționale (care urmează să fie prezentate mai î n detaliu) sunt
dezvoltate de către testerii care se ocupă de calitatea aplicației, deoarece cunosc cel mai bine modul
de folosire al aplicației, si unde pot apărea probleme. Testele Unit sunt dezvoltate de către
dezvoltator, el cunoscând cel mai bine codu l din spatele aplicației .
După dezvoltarea tipurilor de teste menționate mai sus, diagrama anterioară se modifica
astfel:

Figura 3. 1.8 – Stările și etapele noului element într -un ciclu de dezvoltare (cu testare automat ă)

3.2. Prezentarea proiectului de teste automate la nivelul Programării orientate pe Obiecte
Framework -ul prezentat este construit pe baza framework -ului de la Selenium, deci acesta
va conține toate metodele si funcțiile Selenium plus cele caracteristice acestui proiect de teste.
Dupa cu m se poate observa în figura 3.2.1 acest proiect pune accent pe o structura bine definită și
cu un grad de simplitate al citirii foarte mare, astfel încâ t orice începător pe proiect să înțeleagă ce
zone ale aplicație sunt acoperite de framework până la mom entul acela.
Structura framework -ului de testare trebuie să îndepline ască următoarele specificații:
 Utilizarea standard -ului Page Object Model în organizarea și declararea claselor folosite
mai apoi în generarea testelor.

37

Figura 3. 2.1 – Privire de ansamblu a pr oiectului de teste automate

 Punerea în evidență atât a elementelor din interiorul fiecărei pagini, dar mai ales modul de
identificare și definire al acestora.
 WebDriver -ului Selenium să fie integrat în construcția claselor astfel încât Selenium
WebDriver să fie folosit doar în interiorul claselor din framework și nu în interiorul testelor
automate propriu -zise astfel încât acestea să fie independente de Selenium.

38
 Construirea unei suite de test și org anizarea acesteia pe zone funcționale , în cazul unei suite
mai mari, pentru a oferi o claritate mai mare celor care vor utiliza soluția de teste automate
în viitor și pentru a limita redundanța în generarea testelor.
 Folosirea metodelor și elementelor specifice Selenium WebDriver în construirea testelor
automate de interfață, exemplificarea și utilizarea funcției Assert.

3.2.1 . Structura soluției de teste automate
După cum se poate observa și în figura 3.2.1 soluția de teste automate este împarțită în
două proiecte :
1 – Automation_Edu care reprezint ă framework -ul nostru de teste automate, acesta
folosindu -se în mod direct de framework -ul de la Selenium , și pe baza cărui a putem crea teste în
cadrul celui de al doilea proiect
2 – Edu_Tests este al doilea proiect din cadrul soluției de automatizare, acesta nu intră în
contact direct cu fr amework -ul Selenium, dar foloseș te funcții si metode din primul proiect

În momentul de față pr oiectul Automation_Edu este împă rțit la rândul sau în clasele
generale și două mari zone :
 PageHelpers
 PageObjects.
PageHelpers după cum sugerează și numele acestuia conține clase care ajută la scrierea testelor,
aceste ajutoare sunt organizate mai apoi pe paginile de care aparțin, conținând metode și funcții
specifice pentru pagina respectivă .

Figura 3.2.2 – Structura folderului de PageHelpers
Fișierul PageObjects conține clase în interiorul cărora se găsesc elemente si obiecte de pe
paginile corespunzătoare, elemente precum : câmpuri de date, butoane, dropdown -uri , check
box-uri etc.

39

Figura 3.2.3 – Structura folderului de PageObjects

Proiectul Edu_Tests este un proiect de tip Unit Test în care vom avea folderul Tests ce
conține teste automate, în cazul în care proiectul t estat devine mai mare si mai copmplex, acest
folder poate fi împărțit pe zone funcționale, însă în stadiul actual nu este nevoie.

Figura 3.2.4 – Structura proiectului Edu_Tests
În interiorul folderului Tests se află testele generate pe zone funcționale, care la rândul lor conțin
teste pentru anumite funcționalități ca de exemplu în cazul testului paginii de proiecte se va testa
adăugarea, editarea și ștergerea proiectelor.
Tot în cadrul proiectului Edu_Tests se află ș i clasa TestBase, această clasă va fi moștenită
de fiecare test din proiect, iar în interiorul ei se află funcția de inițializare a testelor, care constă
in deschiderea unui nou browser la începutul fiecărui test, astefel încât testele sa nu se afecteze
reciproc.
Clasa TestBase conține și u n TestCleanup() , funcție care asigură curațarea memoriei și
închiderea browser -ului la sfârșitul fiecărui test.

40

Figura 3.2.5 – Clasa TestBase

3.2.2. Clasa Browser
Proiectată la un nivel mare de abstractizare, clasa Browser.cs are ca rol, pe lângă păstrarea
modelului Page Object, acela de a integra funcțiile puse la dispoziție de Selenium valabile în
majoritatea claselor ce alcătuiesc framework -ul de t este automate. Clasa Browser.cs reunește s trict
metodele și proprietățile metodelor folosite de mai multe clase integrate în framework -ul de test
făcând astfel codul mult mai ușor de înțeles și de urmărit.

41

Figura 3.2.4 – Componența clasei Browser.cs
Unde:
 public static IWe bDriver Driver; poate îndeplini mai multe funcții, dar în cadrul aplicației
noastre rolul acestuia este de a declara driver -ul necesar conexiunii la browser -ul Chrome ,
folosit în cadrul unei alte metode, acest driver este pus la dispoziție de către Selenium și
poate fi ac cesat utilizând librăria “using OpenQA.Selenium. Chrome”.
 public static string Title; returnează titlul paginii regăsit în heade r-ul aplicației , proprieta te
utilizată la formarea metodelor care verifică titlul paginii din browser
 public static string Url; returnează url-ul paginii regăsit în bara de adresă a browserului,
proprieta te utilizată la formarea metodelor de tip IsAt() care verifică dacă url -ul paginii din
browser coincide cu cel asteptat
 public static void Close Browser (); metodă utilizată în struc tura de cleanup a fiecărui test.
Acesta are ca rol închiderea entității de browser folosită în rularea testului automat atât
atunci când testul returnează un rezultat pozitiv, cât și atunci când acesta returnează un
rezultat negativ (execuția se termină în tâmpinând o eroare).
 public static void Navigate(string url); metoda Navigate situată în clasa Browser.cs are ca
rol transmiterea apelului mai departe către metodele Navigate din fiecare clase. Astfel, în
funcție de zona funcțională din care se face apelul metodei Navigate, url -ul va fi diferit si
vom fi redirectaț i pe pagina dorită.

42

3.2.3 . Clasa BaseElement
Aceast ă clasă a fost creată din necesitatea de a adăuga noi funcționalități peste cele oferite
de Selenium .

Figura 3.2.5 – Interfața IBaseElement
După cum se vede în imaginea de mai sus, interfața clasei BaseElement , numită
IBaseEmelent moștenește din IWebElement interfață oferită de Selenuim, deci IBaseElement
conține toate elementele IWebElement plus cele adaugate de noi.
Funcția WaitUntilExists( ); a fost creată din cauza faptului că uneori pagina web nu se
încarcă pe atâ t de repede pe cât se rulează testul, astfel există șansa ca testele să cadă pe motiv că
elementul căutat pentru test nu există , deși acesta doar nu era încărcat încă .

Figura 3 .2.6 – Funcția WaitUntilExists() ;
Această funcție va aștepta elementul respectiv pană când acesta se va incărca și va fi găsit, testul
mergând mai departe, sau până când timpul setat în TimeSpan.FromSeconds(timeout) va expira,
caz în care testul va cădea, afișând mesajul de la Console.WriteLine.
Funcția ClickAndWait() a fost creată cu rol asemănător celei de WaitUntilExists(), doar
că aceasta adaugă un timp de aș teptare după transmiterea come nzii de Click().

43

Figura 3.2.7 – Funcția ClickAndWait();
3.2.4. Clasa Pages
Clasa Pages are rolul interpretării valorilor transmise de celelalte clase și transpunerea lor
prin ajutorul proprietăților definite în interiorul clasei Pags.cs într -un format ușor de urmărit în
testele automate de interfață făcându -l mai intuitiv și ușor de parcurs chiar și de către o persoană
care nu a mai lucrat în aceasta soluție de teste. Fiecare clasă care reprezintă o nouă pagină în
aplicația care urmează să fie testată sau o mai mică zonă funcțională este identificată în interiorul
clasei Pages.cs cu ajutorul unei proprietăți care are drept scop înglobarea tuturor identificărilor de
elemente din clasa mamă și transpunerea lor prin intermediul unei proprietăți definite la nivel
general astfel încât apelarea și identificarea elementelo r din pagina dorită să fie mai intuitivă.

Figura 3.2.8 – Clasa Pages

44
3.3. Prezentarea unui test “end to end ”
Prin p rezentarea unui test “end to end” doresc să prezint modul cum un test rulează de la
inițializarea sa până la partea de cleanup, adică în termeni uzuali rularea “cap coad ă”, așa că am
ales să prezint testul pentru pagina de autori exter ni , acest test fiind relativ simplu față de celelalte
teste din soluție și poate fi urmarit cu ușurință chiar și de persoane care nu cunosc foarte bine
limbajul de programare.
Pe scurt, ce urmează să fie prezentate sunt adăugarea, verificarea, editarea ,verificarea după
editare și ștergerea autorilor extern i. Metodele și funcțiile vor fi luate din PageHelper -ul aferent
paginii de care aparțin, iar obiectele asupra cărora se efectuează come nzi sunt luate din
PageObejct -urile corespunzătoare.
Dar pentru a putea executa cele menționate mai întâi va trebui să deschidem browserul,
acest lucru este asigurat de [TestInitialize] din cadrul TestBase prezentat anterior. Pe urm ă trebuie
navigat către pagina de login unde este efectuată autentificarea prin introducerea user -ului și a
parolei.
Navigarea se face prin ap elarea funcției Navigate () folosind url -ul paginii de login stocat
în interiorul acesteia, iar autentificarea prin funcția LogUser() , completând câmpurile cu datele
necesare și transmițând comanda de Click către butonul de login.

Figura 3.3.1 – Funcția Navigate()

Figura 3.3.2 Funcția LogUser()

45
Obiectele din pagină folosite în aceste teste sunt identificate în pagină de către Selenium
WebDriver prin diferitele metode prezentate în capitolul anterior, ca de exemplu, elementele de pe
pagina de login precum câmpurile pentru datele de utilizator sunt localizate prin intermediul Id-
urilor și al ClassName -ului în cazul butonului de conectare .

Figura 3.3 – Elementele paginii de login
După ce utilizatorul este autentificat putem începe adăugarea autorul ui extern prin folosirea
metodei AddExternalAuthor() , în interiorul acesteia se află mai multe funcții, care înlănțuite
realizează adăugarea, mai exact pașii fiind :
1. de pe pagina principală se accesează butonul de meniu din care se selectează opțiunea de
“Autori externi”
2. după navigarea la pagina de autori externi se va da click cu ajutorul funcției oferite de
Selenium, și anume Click (), pe bu ton de adăugare autori externi
3. vom popula câmpurile de date prezente pe pagină cu datele necesare prin interediul funcției
de SendKeys() , care va trimite date de tip string catre acele elemente din pagină
4. iar în final vom transmite click către butonul de salvare autor extern

46

Figura 3. 3.4 – Metoda de adăugare autor extern, AddExternalAuthor()
După ce autorul extern a fost adăugat acesta trebuie verificat, pentru a ne asigura că
datele salvate coincid cu ele aș teptate de către tester, această verificare este realizată de metoda
CheckExt ernalAuthor() , aceasta navighează către pagina de autori externi și accesează autorul
extern. Metoda va fi folosită din nou după ce autorul extern va fi editat, prin adăugarea unui
parametru de tip string, care dacă este transmi să către metodă la apel, aceasta va ve rifica datele
prezente pe pagină cu un alt set de valori așteptate.
În această metodă cu ajutorul Assert -urilor se compară datele asteptate (stânga în cadrul
assert-ului) cu datele de tip text venite de pe interfață pri n intermediul WebDriver -ului (dreapta).

Figura 3.3.5 – Metoda de verificare pentru autor extern nou
Editarea autorilor externi este foarte asemănătoare cu adăugarea, diferența fiind că datele
transmise sunt diferite , câmpurile vor fi golite, iar apoi completate cu alte date care urmând să fie
verificate din nou după salvare, pentru a ne asigura că acestea au fost într -adevăr schimbate.
Editarea se realizează prin metoda EditExternalAuthor() și verificarea cu același
CheckExternalAuthor( “Edited ”) cu par ametrul “Edited”, astfel schimb ând setul de date pentru
verificare.

47

Figura 3.3.6 – Metoda EditExternalAuthor()
Ultima etapă din acest test este ștergerea autorului extern realizată de metoda
DeleteExternalAuthor() , care navighează către pagina de autori externi, apasă butonul de editare
al autorului extern, după care apasă butonul de ștergere și în cele din urmă confirmă ștergerea când
dialogul de confirmare apare pe ecran.

Figura 3.3.7 – Metoda DeleteExternalAuthor
După cum se poate observa toate ace ste metode și funcții sunt ușor de citit și sunt intuitive,
acest lucru este datorat structurării foarte bune a proiectului cu ajutorul OOP, astfel avem
posibilitatea de a “ascunde” componentele complicate ale proiectului precum identificarea
elementelor d in pagină care ar putea părea foarte complicată și intimidantă pentru un începător.

48

Figura 3.3.8 – Elementele paginii de autori externi din cadrul PageObjects
În final, după rularea ultimei funcții din metoda de test se apelează automat
[TestCleanup ] din cadrul clasei TestBase, realiz ând închiderea browserlui și terminarea
proceselor aferente testului.

Rezultatul final al tuturor acestor metode și funcții este rezumat într -un test scurt și la
obiect, în limbaj aproape uzual și intuitiv, care poate fi înțeles de oricine. El arată astfel:

Figura 3.3.9 – Testul paginii de autori externi

49
Testul se poate rula d ând click dreapta în interiorul metodei de test (figura 3.3.9) și
selectând opțiunea “Run Tests ” sau din cadrul tab -ului numit “ Test Explorer ” din componența
Visual Studio.
După ce testul a terminat rularea, acesta va apărea in Test Explorer având în fața numelui
o bulină verde cu o bifă în cazul în care testul a trecut cu succes sau o bulină roșie cu un X dacă
acesta a căzut din diverse motive.

Figura 3.3.10 – Test trecut cu succes

Figura 3.3.11 – Test căzut
Pentru priectul acesta este îndeajuns să vedem că un te st a cazut în felul acesta și avem o
idee în ce zonă și de ce acesta a căzut, dar în proiectele mai mari este nevoie de funcții spec iale
care să logheze momentul exact când un tes t a căzut, să facă captură ecran dacă este nevoie și tot
felul de alte statistici astfel încât depistarea problemei să fie cât mai rapidă și eficientă.

50
În final suita noastră de teste arată astfel:

Figura 3.3.12 – Suita de teste văzută în Test Explorer

51
Concluzii
Sunt de părere că Selenium WebDriver reprezintă o parte importantă a viitorul ui testării software
(web), am considerat util să prezint acest concept prin intermediul lucrării de față. De asemenea,
un alt motiv care stă la baza alegerii acestei teme este dat și de faptul că nu foarte multe persoane
sunt familiarizate cu modul de testare abordat, iar pentru moment, în cadrul Universității nu este
predată nici o materie care să facă referire la acest subiect , testarea fiind ceva abstract pentru
foarte multe persoane, așa că am decis să încerc a intriga lumea în legătură cu acest domeniu .
Experiența în domeniu dobândită la locul de muncă și p osibilitatea practicării mi-au fost călăuze
în înțelegerea mai profundă a ceea ce înseamnă Selenium WebDriver , avantajele și posibilitățile
create . Această lucrare este destinată construirii și configurării testelor automate de interfață.
Utilizarea concep tului oferă dezvoltatorilor posibilitatea de a crea teste care să fie funcționale pe
mai multe sisteme de operare și mai multe tipuri de browsere.
Punctul forte al acestui mod de testare este dat de faptul că acest concept este ușor de utilizat,
facilitâ nd efortul pe care developer -ul (dezvoltatorul) trebuie să îl depună, fiind o unealtă ușor de
accesat chiar și de către persoanele care nu s -au mai întâlnit cu acest concept.
Testarea manuală și cea automată nu trebuie să se excludă reciproc, ba chiar din contră,
ele trebuie să se completeze.
Chiar dacă pe termen lung testarea manuală este mai costisitoare necesitând mult timp
sau un număr mare de resurse, aceasta are avantajele ei, cum ar fi rapiditatea cu care se poate
testa un caz particular, sau când se vrea ca timpul de feedback să fie cât mai scurt, iar costurile să
rămână relativ mici. Nu totul se poate automatiza, unele teste vor fi mereu manuale.
Testarea automată chiar dacă necesită un efort inițial mai mare pentru realizarea
testului, are avant aje pe termen lung . Testarea automată într-un caz ideal reduce timpul de
dezvoltare și costurile . Un tester poate să pornească suita de testare automată, să o lase să ruleze
testele fără prezența sa și în final să colecteze și analizeze rezultatele. Timpul economisit astfel
poate fi folosit pentru izolarea și raportarea bug -urilor.
Avantajele tes tării automate percepute de mine sunt:
a) din perspectiva eficienței și a costurilor
● detecția rapidă a noilor defecte introduse
● poate preveni erori din cauza necesității de abordare structurată a proiectului

52
● posibilitatea de a reutiliza informația
● reducerea necesității de noi scripturi, se pot adapta cele vechi
● efort minim odată ce framework -ul ajunge la maturitate
b) privind economia de timp
● condițiile de testare se pot genera rapid, acestea fiind scriptate
● în cazul schimbării parametrilor de testare aceștia se pot adapta rapid
● posibilitatea rulării mai multor teste pe difeite dispozitive
● posibilitatea r uluării testelor fără a necesita un operator
c) din punct de vedere al calității
● obținerea de rezultat e mai consistente
● compararea rapidă a rezultatelor
● o bună viziune a scopului testului
● o acoperire mai largă a elementelor de testat

Personal, cred că testarea automată este un mod distractiv de a testa care m -a ajutat la înțelegerea
conceptelor OOP (object oriented programming), deschizându -mi noi orizonturi spre programare.

53
Bibliografie

1. Wikipedia – Testarea Software – https://ro.wikipedia.org/wiki/T estare_software
2. Metode de testare –
http://www.softwaretesting.ro/Romana/Files/TestMethods/Software%20Testing%20Meth
ods.html
3. Testarea și asigurarea calității –
http://www.shiva.pub.ro/PDF/TEST/Teste_functionale_curs_6.pdf
4. Testare – http://wiki.lug.ro/Testa re#Cauzele_defectelor
5. Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black – Foundations of
Software Testing, 2006
6. Procesul de integrare continuă – http://www.agora.ro/stire/p rocesul -de-integrare -continua
7. www.pluralsight.com – Automated Web Testing With Selenium
8. https://en.wikipedia.org/wiki/Selenium_(software)
9. www.seleniumhq.org

54

DECLARAȚIE DE AUTENTICITATE A
LUCRĂRII DE FINALIZARE A STUDIILOR

Titlul lucrării ________________________________________________________
___________________________________________________________________
___________________________________________________________________
Autorul lucrării _____________________________________________
Lucrarea de finalizare a studiilor este elaborată în vederea susținerii examenului de finalizare a
studiilor organizat de căt re Facultatea _________________________________________ din
cadrul Universității din Oradea, sesiunea_______________________ a anului universitar
______________.
Prin prezenta, subsemnatul (nume, prenume, CNP) _____________________
___________________________________________________________________
___________________________________________________________________,
declar pe proprie răspundere că această lucrare a fost scrisă de către mine, fără nici un ajutor
neautorizat și că nici o parte a lucrării nu conține aplicații sau studii de caz publicate de alți autori.
Declar, de asemenea, că în lucrare nu există idei, tabele, grafice, hărți sau alte surse folosite
fără respectarea legii române și a convențiilor internaționale privind dr epturile de autor.

Oradea,
Semnătura