Specializaea: Automatică și Informatică Aplicată LUCRARE DE LICENȚĂ Coordonator Absolvent Sef lucr. univ. dr. ing. Andrei – Alexandru Bucă Oana… [606346]

Universitatea Tehnică de Construcții București
Facultatea de Hidrotehnică
Domeniul: Ingineria Sistemelor
Specializaea: Automatică și Informatică Aplicată

LUCRARE DE LICENȚĂ

Coordonator Absolvent: [anonimizat] – Faida

2019

Universitatea Tehnică de Construcții București
Facultatea de Hidrotehnică
Domeniul: Ingineria Sistemelor
Specializaea: Automatică și Informatică Aplicată

LUCRARE DE LICENȚĂ

SISTEM SOFTWARE PENTRU VALIDAREA UNEI PLATFORME
WEB CARE OFERTĂ SERVICII TELECOM

Coordonator Absolvent: [anonimizat] – Faida

2019

Cuprins
Introducere ………………………….. ………………………….. ………………………….. ………………………….. . 3
Importanța temei selectate și motivarea lucrării ………………………….. ………………………….. ….. 3
CAPITOLUL 1 ………………………….. ………………………….. ………………………….. ……………………… 5
Obiectivul lucrării ………………………….. ………………………….. ………………………….. …………………. 5
1. Prezentarea domeniului din care face parte lucrarea ………………………….. …………………….. 6
1.1. Procesul de dezvoltare al unei aplicații software și rolul testării ………………………….. . 6
1.2. Standardul testării software: ISO/IEC/IEEE 29119 ………………………….. ……………….. 9
1.3. Detalierea etapelor în procesul de testare ………………………….. ………………………….. .. 12
1.4. Cauzele apariției erorilor în procesul de testare ………………………….. …………………… 15
1.5. Clasificarea testelor ………………………….. ………………………….. ………………………….. … 17
1.6. Metode de testare ………………………….. ………………………….. ………………………….. ……. 23
1.7. Testarea automată ………………………….. ………………………….. ………………………….. …… 27
1.8. Instrumente pentru automatizarea testării ………………………….. ………………………….. .. 29
1.9. Raportarea defectelor identificate ………………………….. ………………………….. ………….. 32
CAPITOLUL 2 ………………………….. ………………………….. ………………………….. ……………………. 34
2.1. Prezentarea soluț iei ………………………….. ………………………….. ………………………….. …. 34
2.2. Prezentarea produsului ce urmează a fi testat ………………………….. ………………………. 38
2.3. Managmentul procesului de testare ………………………….. ………………………….. ……….. 41
2.3.1. HP ALM ………………………….. ………………………….. ………………………….. …………. 41
2.3.2. Cerințele clientului ………………………….. ………………………….. ……………………….. 42
2.3.3. Crearea cazurilor de testare și maparea lor ………………………….. …………………… 49
2.3.4. Metoda abordată ………………………….. ………………………….. ………………………….. . 55
2.4. Dezvo ltarea scripturilor de testare automată ………………………….. ……………………….. 56
2.5. Execuția scripturilor de automatizare ………………………….. ………………………….. …….. 56
2.6. Raportul de execuție după finalizarea testelor ………………………….. ……………………… 56
2.7. Paralelism între testarea automată și testarea manuală ………………………….. ………….. 56
CAPITOLUL 3 ………………………….. ………………………….. ………………………….. ……………………. 56
Concluzie ………………………….. ………………………….. ………………………….. ………………………… 56
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. …………………. 56
ANEXE ………………………….. ………………………….. ………………………….. ………………………….. …. 58
Anexa 1: Glosar de termeni ………………………….. ………………………….. ………………………….. . 58
Anexa 2: Lista tabelelor din lucrare ………………………….. ………………………….. ………………… 58
Anexa 3: Lista figurilor din lucrare ………………………….. ………………………….. …………………. 58
Anexa 4: Cod sursă ………………………….. ………………………….. ………………………….. …………… 58

Anexa 5: Cazuri de testare ………………………….. ………………………….. ………………………….. …. 59

3
Introducere
Importanța temei selectate și motivarea lucrării
Încă de la dezvoltarea primului browser web, în anul 1990 Tim Berners -Lee, inginer și
om de știință , a dezvoltat primul browser web, pe care l -a denumit inițial WorldWideWeb,
ulterior trecând la numele Nexus . Până în prezent , tendinț a de dezvoltare în acest domeniu s-a
menținut într -o creștere continua . În primii ani de la lansarea primului browser aces ta era
dedicat utilizatorilor tehnici, întrucât paginile web conțineau doar scris, fara grafică. Ulterior,
în septembrie 1993 a fost dezvoltat primul browser grafic de către NCSA Mosaic și a rulat pe
mai multe calculatoare de birou și de acasă. Acest nou b rowser având conținul multimedia a
fost dezvoltat și pentru utilizatorii non -tehnici. Un an mai târziu, Marc Andreessen a creat
browser -ul denumit: Netscape Navigator, iar odată cu dezvoltarea acestui produs a dat startul
competiției. Concomitent cu acest „boom” în domeniul browserelor s-a optat pentru
dezvoltarea aplicațiilor web care totodată au atras un num ăr mare de utilizatori, aceștia
crescând în același ritm alert cu care s -a dezvoltat internetul. Cu cât numărul utilizatorilor era
în creștere, cu atât standardele aplicațiilor web creșteau, iar din acest motiv, în marile
companii, au fost înființate departamente de testare care se ocupau cu validarea aplicațiilor
dezvoltate de programatori.
Consider că , această temă este importantă deoarece î n prezent, o mare parte din
companii optează pentru dezvoltarea aplicațiilor pe metoda agile , dezvolt ând astfel un nou tip
de testare, denumit ă testare automată de regresie . Din punctul m eu de vedere, testarea
reprezintă ultimul pas și cel mai important, din dezvoltarea unui software, întrucât produsul
testat în această fază reprezintă livrabilul pe care clientul î l primește. Dezvoltarea de noi
funcționalit ăți poate afecta funcțiile deja e xistente , iar p rin testarea automată se realizează
partea de regresie a software -ului, validând astfel func ționalitatea în parametri optimi a
aplicației, fără ca noile funcții sa afecteze aplicația existentă . Produsul trimis către client
trebuie să fie lip sit de bug -uri, dar totodat ă trebuie să conțină și noile funcționalit ăți dorite de
către acesta.
Am ales o platformă web din domeniul telecom pentru a fi validată, întrucât acest tip
de website înglobează multiple funcționalități, de la cele mai complexe precum: plați online,
generare contracte, până la cele mai simple: afișarea balanței, afișarea produselor instalate,
etc. Complexitatea unei platforme nu poate fi considerată ca fiind un impediment în testarea
automată, iar acesta este motivul selecției un ei platforme web din acest domeniu.
În prezent, realizând o analiză a cererii și a ofertei pe piața de muncă din domeniul IT,
în sectorul de testar e, am constatat că numărul cererilor de specialiști se află pe un trend
ascendent, în comparație cu numărul specialiștilor din întregul domeniu IT, care este
insuficient pentru a acoperi cererile venite de pe piața muncii. În ceea ce privește domeiul
testării, am observa t că există o tendință de creștere de specialiști în testare automată, fiind în
detrimentul testării manuale.

În primul capitol [de completat dupa ce termin capitolul 1]
În al doilea capitol [de completat după ce termin capitolul 2]

4

Text[Text][Text]

5
CAPITOLUL 1

Obiectivul lucrării
Principalul obiectiv al lucrării este reprezentat de automatizarea validării unei
plaforme web din domeniul telecomunicațiilor. Acest domeniul fiind car acterizat ca unul
dintre cele mai inovatoare , iar acest fapt determină o evoluție accentuată a software -ului în
această direcție. Odată cu acest progres , prin care trec companiile din piața telecom, se caută
modalități de realizare a produ selor care să fie actualizat e la cerințele consumatorilor.
Totodată livrabilul trebuie să fie lipsit de bug-uri și perfect funcțional pentru a putea să
satisfacă nevoile clientilor și pentru a certifica calitatea produsului dezvoltat . Companiile
pentru a se asigura de acest lucru , au optat pentru completarea procesului de dezvoltare a
aplicațiilor, adăugând faza de testare.
În această fază de validare a aplicației, componenta umană, testerul, trebuie să se
asigure că produsul dezvoltat îndeplinește următoarele criterii:
• Cerințel e și funcționalitățile dorite de către client trebuie să se regăsească în interiorul
aplicației, acestea mai purtând denumirea și de Business Requirements (BR) – testerul
are obligația de a urmări fiecare cerință în parte pentru a o putea valida sau invali da în
situația în care aceasta nu se ragăsește în produsul dezvoltat;
• Realizarea conexiunilor, a comunicării, dintre sistemele implicate în acest proces –
testerul are obligația de a validare comunicarea sau schimbul de date dintre mai multe
sisteme, dacă este cazul;
• Limitările sistemului dezvoltat trebuie să corespundă documentației aferente, testărul
are datoria de a observa dacă limitările sistemului corespund celor agreate.
• Interfața cu utilizatorul (GUI) este prietenoasă și este ușor de utilizat pentr u grupul
țintă, acesția fiind considerați utilizatori non -tehnici, tersterul are sarcina de a valida
aplicația din punctul de vedere al utilizatorilor tință.
Pentru a se putea ține pasul cu evoluția ascendență a aplicațiilor web, dezvoltatorii au
apelat l a metoda Agile. Aceasta este cunoscută ca fiind o abordare de managment care
favorizeaza schimbarea și totodată menținerea produsul dezvoltat la cerințele pieței cu un
maxim de eficieță și rapiditate. Metoda Agile constă în primă fază în planificarea pe te rmen
scurt a task -urilor pentru a putea realiza o eficiență și rapiditate a produsul dezvoltat, iar în ce –
a de-a doua fază, adaptarea cerințelor la nevoile utilizatorilor pentru a le putea oferi acestora
experiența dorită. Întrucât ritmul de dezvoltare est e unul alert, iar adăugarea unor noi
funcționalități necesită o nouă fază de testare a îmbunatățirilor aduse, dar totodată este
necesară realizarea unei testări de regresie care să valideze funcționalitățile deja existente. În
această fază de regresie , testerul trebuie să se asigure că odată cu proiectarea și dezvoltarea
noilor funcții, cele existente nu au suferit nicio modificare. Prin intermediul acestui proces de
validare se asigura că aplicația livrată corespunde standardelor de calitate ale companiei și v-a
fi lipsită de incidentele care pot fi considerate blocante în realizarea unei acțiuni pe care
utilizatorul dorește să o realizeze.
Numărul ridicat de actualizări care sunt aduse unei aplicații conduce automat și la
creșterea numărului de faze de testare prin care aplicația trebuie să treacă pentru a corespunde
standardelor de calitate. Deoarece atât costul, cât și timpul petrecut pentru testarea aplicației
sunt considerate elemente importante în implementarea aplicației, s -a optat pentru
automatiz area procesului de testare a funcționalităților existente, unele dintre acestea fiind

6
considerate funcții de baza. Această etapă prin care se valideaza funcționalitățile de bază mai
poate fi denumită și testare de regresie. Pentru implementarea testării au tomate, testărul are
nevoie de un timp mult mai mare decât cel de testare propriu -zisă, întrucât acesta este nevoie
să creeze scripturi care să apeleze metodele dezvoltate de programatori. Odată cu dezvoltarea
acestor scripturi, partea de regresie poate fi realizată într -un timp considerabil mai mic, decât
cel pe care îl petrecea un testăr în aceiași etapă, dar folosind un alt tip de testare, denumit ă
testare manuală.

1. Prezentarea domeniului din care face parte lucrarea
1.1. Procesul de dezvoltare al unei aplic ații software și rolul testării
Faza de testare software face parte dintr -un proces mai amplu de dezvoltare a unei
aplicații. Acest proces de dezvoltare a unei aplicații software poate fi adaptat în funcție de
nevoi, dar și de complexitatea sarcinilor sau a proiectului. Cu toate că procesul poate fi
modelat sau reconstruit în funcție de nevoile fiecărei companii , acesta trebuie să respecte
principiile de bază și anume imposibilitatea de a elimina unul dintre pașii de bază ce trebuiesc
urmați:
• Construirea cerințelor de către client;
• Realizarea design -ului funcțional pentru aplicația ce urmează a fi dezvoltată – acest
pas fiind considerat necesar în realizarea unui produs complex;
• Dezvoltarea aplicației conform cerințelor clientului, dar și a de sign-ului creat;
• Realizarea integrării dintre aplicații – acest pas fiind considerat necesar în situația în
care aplicația dezvoltată realizeaza schimburi de date cu alte aplicații de sine
stătătoare;
• Testarea aplicației cu scopul de a descoperi defectele existente;
• Implementarea produsul dezvoltat în mediul pentru care a fost dezvoltat;
• Validarea aplicației după implementare – acest pas fiind considerat necesat in
contextul unei aplicații complexe care este considerată cu impact major.
Pentru a înțelege ma i bine întreg procesul de dezvoltare, mai jos vor fi prezentate diverse
modetele care au fost adaptate nevoilor unei companii:

Figura 1.1-1 Proces ul de dezvoltare al unei fun cționalități, sursă: Documentație testare UPC România
Procesul din Figura 1 .1-1 poate fi considerat simplist, întrucât acesta înglobează
principiile de bază ce sunt necesare a fi respectată în construirea unui flux de dezvoltare. În

7
figura prezentată mai sus putem observa că p rima fază este denumită ”Open”, iar in aceasta se
conturează cerințele funcționalitații ce urmează a fi dezvoltate . În următoare fază, denumite
generic ” In assesment”, beneficiarul împreună cu echipa de dezvoltare evaluează cerințele si
dezvoltă design -ul funcțional care ajută la implementarea aplicației. Din această fază procesul
poate urma două flux -uri și anume, anularea acestuia din motive de rentabilitate, costuri sau
imposibilitate de dezvoltare, iar acest lucru ducând la stoparea procesului și autom at anularea
fazei de testare, sau procesul poate urma fluxul normal, intrând in faza de dezvoltare. Toate
aceste decizii fiind luate în etapa de evaluare. După finalizarea etapei de dezvoltare, aplicația
își urmeaza cursul normal trecând în faza de testar e, unde produsul este validat la finalizarea
testelor. Decizia de implementare a funcționalității este luată în faza de testare. Daca se
optează pentru invalidarea funcționalității, aceasta este trimisă din nou catre echipa de
dezvoltare, iar în caz contra r produsul este implementat și trece în următoarea etapă denumită:
”Waiting Implementation”. După etapa de implementare, se trece în următoarea etapă,
denumită: ”Waiting BV” care poate fi considerat ultimul pas, întrucât în această etapă se
așteapă val idarea business -ului și anume a departalemtului sau a persoanei care a cerut această
funcționalitate. După validarea funcționalității întreg procesul se finalizează, urmând ca task –
ul să se închidă.

Figura 1.1-2 Procesul de dezvoltare a unei funcționalități – 2, sursa: Documentație testare UPC România
În Figura 1.1 -2 este schematizat un proces de dezvoltare a unei aplicații sau a unei
funcționalități. Realizând o comparație dintre p rocesul exemplificat în Figura1.1 -1 și fluxul de
lucru exemplificat mai sus, putem concluziona că cel din urmă poate fi catalogat ca fiind
complex , datorită numărului mare de posibilități care pot fi urmate în întreg procesul. În

8
continuare, comparând cel e doua s cheme, putem observa că în procesul descris î n Figura 1.1 –
2 s-a optat pentru eliminarea fazei de evaluare, iar totodată în pasul d e realizare a cerintelor s –
a adă ugat posibilitatea de anulare a proiectului, acest lucru putând fi determinat de
renta bilitate, costul prea mare necesar pentru dezvoltarea produsului sau de imposibilitatea de
dezvoltare. După crearea cerințelor, aplicația trece în pasul următor, ”In development” , de
unde se poate lua decizia de anulare a proiectului, de renunțare la dezvo ltarea funcționalității
sau de trimiterea acestuia în etapa de așteptare. În această etapă, denumită ”On hold”,
aplicația se poate întoarce din nou către echipa de dezvoltare, unde se poate continua procesul
sau dacă aceas ta a îndeplinit toate condițiile d e ieșire din etapa de dezvoltare să trimite catre
echipa de testare și anume în etapa: ”Deliver ed to UAT” . În etapa menționată anterior echipa
de testare realizează planul de testare al aplicației sau a funcționalității, urmat de alocarea
resurselor necesa re pentru a realiza efectiv validarea produsului. După finalizarea pașilor
descriși mai sus se trece în statusul ”In testing”, unde se realizează testarea propriu -zisă a
aplicației. În urma executării scenariilor de test ce au fost create special pentru ac est proiect,
echipa de testare valideaza sau invalideaza produsul dezvoltat. În situația invalidării aplicației
sau a funcționalității, aceasta este trimisă către echipa de dezvoltare, de unde membrii acestei
echipe vor continua dezvoltarea pentru remedier ea defectelor gasite în etapa anterioară. După
finalizarea dezvoltării se urmeaza procesul descris mai sus, urmând o nouă validare din partea
echipei de testare. În cazul în care testarea este finalizată cu statusul ”Uat OK” și echipa de
testare iși exprim ă acordul pentru trimiterea aplicației sau a funcționalității în etapa de
implementare, statusul se schimbă în: „Waiting Implementation”. La finalizarea
implementării se trece în statusul următor, denumit „Waiting BV”, de unde se așteaptă
validarea aplicaț iei sau a funcționalității din partea business -ului, adică a departamentului sau
a persoanei care a cerut dezvoltarea și astfel existând două flux -uri care pot fi urmate. Dacă
validarea este acordată, atunci procesul de inchide automat, iar în situația în care produsul este
invalidat, acesta ajunge din nou la echipa de dezvoltare unde urmează să fie dezvoltat
conform cerintelor agreate inițial și urmându -și fluxul descris anterior.
Conform procesului descris în Figura 1.1 -2 statusurile din care aplicația poate fi anulat
sunt următoarele:
• „Open”;
• „In development”;
• „Delivered to UAT”;
• „In testing”;
• „Uat nok”;
• „Uat ok”;
• „Waiting implementation”;
• „Waiting BV”;
• „BV nok”.
Testarea are rolul de a valida sau de a descoperi lagunele din produsul dezvoltat, acest
lucru fiind susținut și de Glenford J. Myers „Testarea este procesul prin care se execută un
program cu intenția de a găsi erori.1” (Myers J. , 1979) în prima sa carte publicată în anul
1979 , aceasta fiind dedicată testării software, după cum putem deduce din titlu: ”Arta testarii
software”. Încă de atunci, G. Myers, susținea importanța testării în procesul de dezvoltarea a

1 Glenford J. Myers, 1979, The Art of Software Testing – First Edition

9
unei aplicații, e xprimând acest lucru prin intermediul unei reguli pe care a definit -o în prima
carte. Prin intermediul acestei reguli, acesta dorea să transmită că într -un proces de
dezvoltarea tipic, aproximativ 50% din timp este petrecut în faza de dezvoltare și
impleme ntare a cerintelor, iar un procent de 50% din costul total este cheltuit pentru testarea
programului sau a sistemului dezvoltat. După 25 de ani de la lansarea primei carti, Glenford J.
Myers lanseaz ă ce-a de-a doua ediție în care susține că: ” Astăzi, un s fert de secol mai târziu,
același lucru este încă adevărat. Există noi sisteme de dezvoltare, limbaje cu instrumente
încorporate și programatori care sunt obișnuiți să dezvolte produse software într -un ritm alert.
Dar testarea joacă încă un rol important î n orice proiect de dezvoltare software. ”2 (Myers G.
J., 2004) .
Pentru a înțelege mai bine termenul de testare software îl putem defini ca fiind o
investigație empirică care poate fi realizată în scopul de validare, de indeplin ire a cerințele de
calitate, dar totodata și de a oferi părților interesate informații despre calitatea produsului sau
a funcțiilor supuse testării. Din punctul de vedere al business -ului, a persoanelor care au oferit
spre dezvoltare cerințele programului, prin intermediul testării acestia au posbilitatea de a
avea o viziune obiectivă, de ansamblu și aceasta poate fi considerată independentă, astfel
scoțând în evidență riscurile care pot apărea odată cu implementarea software -ului dezvoltat.
În multe metodo logii ale ingineriei programării, etapa de testare poate fi considerată, de cele
mai multe ori, o etapă separată care se realizează de către o echipă complet diferită față de cea
care a dezvoltat produsul. Motivul pentru care se optează pentru această var iantă este că un
programator priveste cu subiectivitate munca sa, iar acest lucru este considerat un impediment
în descoperirea propriilor greseli. O persoană care nu a fost implicată în procesul de
dezvoltare a software -ului poate descoperi greșeli eviden te pe care un dezvoltator al
proiectului le poate trece cu vederea, iar acesta poate fi considerat un motiv pentru care echipa
de dezvoltare trebuie să fie diferită față de echipa de testare pentru a obține rezultate de înaltă
calitate.
În cadrul procesul ui de testare , în funcție de metodologia aleasă, testarea software se
poate implementa la orice fază, dar totodată efortul considerabil este efectuat dupa ce
programatorii realizează formalizarea cerințelor și reușesc finalizarea implementării acestora.
Odată cu finalizarea fazei de dezvoltare se trece la modul de abordare, iar proponderent este
realizat din perspectiva producătorului sistemului. Unul dintre actorii importanți din această
fază este clientul, întrucât acesta poate veni cu sugesții pentru a putea clarifica modul în care
va fi utilizată aplicația.

1.2. Standardul testării software: ISO/IEC/IEEE 29119
ISO/IEC/IEEE 29119 reprezintă o serie de cinci standarde internaționale , schematizate
în Figura 1.1 -3, care au fost create special pentru testarea s oftware. Dezvoltat pentru prima
dată in anul 2007 și lansat 6 ani mai târziu, în 2013, aceste standarde definesc vocabularul
specific, procesele, documentația , tehnicile și descri u un proces prin intermediul că ruia se
poate realiza evaluarea proceselor ce pot fi folosite în cadrul oricărui ciclu de dezvoltare
software.

2 Glenford J. Myers, 2004, The Art of Software Testing – Second Edition, Word Association

10

Figura 1.2-1 Structura standardului ISO / IEC 29119, sursa: Europe ’s No.1 Software Testing Conference
(eurostarsoftwaretestin g.com )
La început, Organizația Internațională pentru Standardizare(IOS) nu dispunea de un
grup de lucru cu experiență semnificativă în testare software și astfel a fost creat WG26, care
până în anul 2011 a fost reprezentat de mai mult de 20 de țări . Pentru început au fost definite
patru secțiuni denumite astfel: „Concepte și definiții”(1), „Procese de testare”(2),
„Documentație de testare”(3) și „Tehnici de testare”(4). Cea de -a cincea secțiune care privește
conceptul de testare bazată pe cuvinte cheie a f ost adaugată în noiembrie 2016.
Până în prezent nu au apărut modificări majore în ceea ce privește standardele de
testare , iar acestea sunt definite conform catalogului de standarde internaționale3 (Organizația
Internațională pentru Standardizare, 2016) , precum urmează :
• ISO / IEC / IEEE 29119 -1: 2013, Partea 1: Concepte și definiții – facilitează utilizarea
celorlalte părți ale standardului prin introducerea vocabularului pe care este construit
standardul și oferă exemple de aplicare a acestuia. Prima parte oferă definiții, o
descrierea a conceptului de testare software, dar și modalități de aplicare a acestor
definiții și concepte;
• ISO / IEC / IEEE 29119 -2: 2013, Partea 2: Procese de încercare – este un standard
normativ care definește un model de proces generic pentru testare software care poate
fi utilizat în cadrul oricărui ciclu de viață al dezvoltării software -ului și în oirce
organizație. Modelul specifică procesele de testare pentru: admi nistrarea, gestionarea
și implementarea testelor software;
• ISO / IEC / IEEE 29119 -3: 2013, Partea 3: Documentație de testare – furnizează
șabloane standard pentru documentația de testare care acoperă întregul ciclu de viață
al testelor software. Fiecare șa blon poate fi adaptat pentru a satisface nevoile unice ale
fiecărie organizații și a modelului ciclului de viață. Toate șabloanele se aliniază
procesului de testare definit în partea a2 -a și pot fi produse prin aplicarea proceselor

3 (Organizația Internațională pentru Standardizare, 2016)

11
definite în standardul r espectiv. Standardul IEEE 829 de testare , bine cunoscut și
utilizat pe scară largă, a fost folosit ca bază pentru acest standard, fiind înlocuit de ISO
/ IEC /IEEE 29119 -3;
• ISO / IEC / IEEE 29119 -4: 2015, Partea 4: Tehnici de încercare – oferă definiții
standard ale tehnicilor de proiectare a testelor software (cunoscute și ca tehnici de
testare a cazurilor de testare sau metode de încercare) și măsurilor de acoperire
corespunzătoare care pot fi utilizate în timpul proceselor de proiec tare și de
implementare a încercărilor definite în partea 2. Tehnicile din partea 4 sunt destinate
să susțină sau să fie utilizate separat în partea 2. Tehnicile de proiectare a standardelor
de încercare sunt clasificate în trei categorii principale: tehni ci de proiectare a
încercărilor cu specificație, structură și experiență ;
• ISO / IEC / IEEE 29119 -5: 2016, Partea 5: Testarea bazată pe cuvinte cheie – oferă un
standard internațional pentru sprijinirea testelor bazate pe cuvinte cheie. Testarea
bazată pe c uvinte cheie este o modalitate de a descrie cazurile de testare utilizând un
set predefinit de cuvinte cheie. Aceste cuvinte cheie reprezintă nume care sunt asociate
cu un set de acțiuni care sunt necesare pentru a efectua un anumit pas într -un test.
Folos ind cuvinte cheie pentru a descrie pașii de testare în locul limbajului natural,
cazurile de testare pot fi mai usor de înteles și de automatizat.
Realizarea standardului descris mai sus , ISO / IEC / IEEE 29119, are drept motivație :
nevoie și cererea tot m ai accentuată de realizare a unui standard în domeniul testării, apariția
tot mai repetată a conflictelor ce apart cu privire la definiții și procesele de testare, lecunele
din standard, care nu prevedeau toate situațiile intâlnite de testări, dorința real izării unei baze
pentru domeniul testării, lipsa practicilor din industia de testare fiind scăzută, iar unul dintre
cele mai importante motive este reprezentat de imposibilitatea cumpăratorilor de a hotărî dacă
metoda de testare aplicată software -ului ce u rmează a fi cumpărat este una de încredere și
validarea a fost realizată corespunzător. Toate aceste motive fiind susținute și de Stuard Reid
(Testing Solutions Group) în articolul tau4. (Reid, 2013)

Figura 1-4 Graficul evoluției standardului de testare , sursa: Stuard Reid, 2013, The New International Software
Testing Standards

4 Stuard Reid, 2013, The New International Software Testing Standards

12
În Figura 1.1 -4 se poate observa evoluția standardizării pe o durată de 25 de ani, de la
publicarea primei carți c are descria procesul de testare și menționa importanța acestuia, scrisă
de catre Glenford J. Myers până la realizarea unui standard internațional care realizeaza
bazele teoretice ale testării. Culoarea albastră reprezintă menținerea principiilor dezvoltate în
acea perioada, pe când culoarea roșie sugerează publicarea unor noi principii în ceea ce
privește testarea software. Din graficul de mai sus se poate observa că între anii 1987 și 1994
se distinge o creștere lină care se referă la menținerea principiil or deja existente în sfera
testării și o lipsă acută referitoare la publicarea de noi principii .
Începând cu anul 1995 până în 2012 se poate observa o creștere accentuată în ceea ce
priveste menținerea principiilor de testare, acest trend așcendent poate fi influențat și de
creșterea treptată a numărului de software -uri dezvoltate. În privința publicării de noi principii
în domeniul testării se poate observa o fluctuație începând din anul 1995 până în anul 2012.
Ca în orice domeniu există principii care a r trebui respectate pentru o funcționare
corespunzatoare. În domeniul testării există următoarele principia5:
• Un caz de test trebuie sa definească neapărat ieșirea sau rezultatul dorit;
• Un programator ar trebui să evite să -și testeze propriul cod;
• Companii le de programare nu ar trebui să -și testeze produsele proprii;
• Fiecare rezultat al testului trebuie examinat foarte minuțios;
• Cazurile de test trebuie să fie scrise atât pentru condiții de intrare valide, cât și pentru
cele invalide și neașteptate;
• Trebuie testat faptul că produsul execute sarcinile conform cerințelor și nu există
anomalii;
• Cazurile de testare trebuie să fie pastrate și refolosite când acest lucru este necesar;
• Procesul de testare nu trebuie planificat presupunând ca nu vor exista erori;
• Probabilitatea de a găsi erori într -un fragment de cod este proportional cu numărul de
erori deja găsite;
• Testarea este un lucru extreme de creativ și intelectual.

1.3. Detalierea etapelor în procesul de testare
Pentru o eficiență ridica tă procesul de testare a fost îm părțit în mai multe faze, precum:
planificare și control , analiză și design , implementare și execuție , evaluarea criteriilor de
ieșire , raportare și încheierea testării . Din punct de vedere practic, activitățile menționate
mai sus pot fi considerate secvențiale, iar în anumite situații se pot suprapune, pot fi
concurente sau repetitive.

5 Prezentarea în cadrul Institutului de Dezvoltare a Societății Informationale – www.idsi.md

13

Figura 1-5 Planificarea procesului de testare, sursa: Stuard Reid, 2013, The New International Software Testing
Standard
Figura 1.1 -5 prezintă planificare unui proces de testare, încă de la începutul acestuia,
până la finalizarea lui. Acest proces de planificare pornește cu înțelegerea contextului în care
acesta trebuie realizat și care este scopul pentru care se realizează. După depistarea acestor
idei se trece la dezvoltarea efectivă a planului de testare. Pentru a realiza acest plan este
necesar să se realizeze o identificare și o estimare cât mai exactă și apropiată de realitate în
ceea ce privește riscurile din timpul pr ocesului de testare. La finalizarea identificării și
estimării riscurilor ce pot apărea, se trece la tratarea și modul de abordare al acestora, urmând
ca în următorul pas să se realizeze design -ul strategiei de testare abordate .
După completarea design -ului se poate trece la programarea procesului de testare,
estimând astfel durata acestuia, iar tot aici, trebuie realizată o alocare a resurselor umane ce
urmează să realizeze faza de testare. După ce se realizeaza programarea testării și se alocă
resurse se finalizeaza prima schiță a test planului, acesta fiind sumarizat într -un document și
primind pe parcursul procesului de planificare viitoare actualizări. Mai departe se realizeaza
un consens pe planul de testare și documentul este actualizat cu ultimele i nformații, urmând
ca varianta finală se fie supusă unui proces de aprobare. După aprobarea planului de testare,
acesta este publicat pentru a putea fi accesat de persoanele implicate în procesul de dezvoltare
al unei aplicații. Urmând ca după publicare pla nului de testare, acest proces de planificare sa
fie finalizat.
Pentru început este necesar ca echipa de testare să se asigure că întelege care sunt
scopul și obiecivele, atât ale clientului cât și ale proiectului, dar totodată trebuie înțeles și
riscul pe care îl adresează prin testare. Luând în considere faptul că se întelege care sunt
scopurile și obiectivele, se trece la elaborarea strategiei de testare. Principalele activități
marcate cu o importanță ridicată în această fază de planificare si control s unt: stabilirea
modului de abordare a testării (tehnicile abordate, acoperirea, echipamentele de testare, etc),

14
alocarea resurselor ce urmează să realizeze testarea, realizarea estimărilor pentru sarcinile ce
urmează a fi executate și stabilirea unor crite ria pentru finalizarea etapei de testare și
inchiderea acestui proces. Sumarizând toate aceste procese se realizeaza documentul denumit
”Plan de testare”.
Formatul planului de testare poate varia în funcție de produsul și compania în care se
aplică, dar cu toate acestea, există trei elemente care ar trebui să se regăsească într -un plan de
testare:
• Acoperirea testelor – descrie cerințele ce trebuie testate. Această acoperire provinde
din specificațiile menționate în design și cerințe secundare. Fiecare cerin ță v-a avea
unul sau mai mulți corespondenți pentru a putea fi testată;
• Metodele de testare – se referă la modul în care se v -a aborda testare și modul de
acoperire al acestora. Totodată se vor specifica: echipamentele ce vor face parte din
testare, intrum entele de testare ce vor fi folosite,cât și criteriile de validare ale unui
test;
• Responsabilitățile de testare – stabilesc alocarea resurselor ce vor executa metodele de
testare și momentul în care acestea vor fi realizate. Astfel companiile pot realiza
planificări, achiziții și dezvoltări de echipamente de testare, dar și alte resurse necesare
pentru a putea implementa metodele amintite anterior.
În faza de analiză se efectuează o centralizare a cerințelor de către echipa de testare în
scopul de a înte lege noul proces dezvoltat. În această etapă, în funcție de cazurile de testare se
ia decizia dacă procesul de testare v -a fi automatizat în întregime, parțial sau v -a fi testat
manual de către echipa de testare. Matricea funcțională de validare este bazat ă pe cerințele
create de către client. Este normal ca matricea să fie bazată pe unul sau mai multe cazuri de
testare, întrucât cu ajutorul acesteia se analizează dacă cazurile de testare vor fi automatizate
sau vor fi testate manual.
În testarea software, etapa de proiectare joacă un rol important, deoarece planul de
testare, cazurile de testare (testcases) și matricea funcțională de validare sunt revizuite în
varianta lor finală, iar acest lucru ajută la eliminarea posibilității de apariție a problemelor. În
situația în care se optează pentru automatizare, se realizează scenariile corespunzator. Tot în
această etapă se generează și date de testare pentru cazurile de testare manuală, cât și pentru
cele automate.
Pe baza planului și a cazurilor de testare, în faza de implementare , dacă se optează
pentru o automatizare a procesului de testare, în această etapă se dezvoltă scripturile necesare
pentru a se putea execută mai departe testele agreate în etapa anterioară.
În etapa de execuție se începe executarea tes telor. Da că s-a optat pentru o testare
manuală, echipa de testare execută rând pe rând testele agreate pană la finalizarea acestora cu
scopul de a putea valida produsul aflat în testare. În situația testării automate, testărul are
obligația de a executa sc ripturile dezvoltate în etapa anterioară, pentru a determina dacă
aplicația prezintă bug -uri.
La final, în etapa de evaluare a criteriilor de ieșire , indiferent dacă s -a optat pentru
testarea manuală sau testarea automată, în această fază se analizează rez ultatele de ieșire și se
compară cu rezultatele așteptate. Dacă cele două rezultate coincid, cazul de testare este

15
considerat trecut și validat, dar în cazul în care rezultatele nu sunt cele așteptate, cazul de
testare este invalidat.
În Figura 1.1 -6 est e schematizat procesul de testare dinamic pentru a putea fi înțeles
mai bine.

Figura 1-6 Procesul de testare dinamic, sursa: Stuard Reid, 2013, The New International Software Testing
Standard
În testarea dinamică se pornește de la test design, după ce se realizează implementarea
aplicației în mediul de testare. Design -ul de testare are rolul de a ajuta testărul să poate valida
veridicitatea unui scenariu de testare. Înainte de a se începe testarea propriu -zisă, echipa de
testare are obligația de a verifică dacă mediul de test este funcțional și dacă aceste a fost
configurat conform nevoilor acestora. La finalizarea cerificărilor ce țin de mediul de testare,
se poate da startul la executarea cazurilor de testare. În situația în care r ezultatul testului este
cel așteptat, atunci putem consi dera testul ca fiind unul valid, iar dacă rezultatul obținut este
diferit de cel așteptat, atunci cazul de testare este invalid, ulterior, acestuia i se asociază un
incident. Dacă scenariul de test es te declarat invalid, echipa de testare are obligația de a
notifica și documenta această problemă. La finalizarea documentației incidentului, acesta este
inaintat către echipa de dezvoltare, urmând ca aceștia să livreze o rezolvare pentru incidentul
detalia t. După ce bug -ul a fost rezolvat, testărul realizeaza o retestare a scenariului, iar dacă
acesta este validat, incidentul se inchide și procesul se finalizează.

1.4. Cauzele apariției erorilor în procesul de testare
Erorile pot apărea în orice etapă prin care trece un produs în p arcusul său spre a fi
dezvoltat, i ndiferent dacă vorbim de faza de : analiză a cerințelor, proiectarea conceptu ală,
proiectarea detaliată sau implementare. Cu toate că erorile pot apărea în orice etapă este

16
important ca acestea să fie d epistate cât mai rapid pentru a minimiza costurile aferente
reparării acestor erori.

Figura 1-7 Efectele acumulării erorilor în etapele ciclului de realizare a produsului program, sursa: Conf. dr. ing.
Ioana Fagarasan, Testarea Software și asigurarea calității – curs 2
În Figura 1.1 -7 se poate observa efectele acumulării erorilor, pornind încă de l a faza de
analiză a cerințelor. Se poate distinge că odată cu apariția erorilor erorilor în faza de început,
acestea se propagă în cascadă incepând cu prima fază până la ultima. Pe prima coloană se
poate observa că atât timp cât fazele au fost realizate c orect și fără erori, rezultatul final este
unul pozitiv, astfel aplicația putând fi validate conform cerintelor. În cea de -a doua coloană se
pot distinge erori atât în faza de analiză, proiectare, cât și de definire a specificațiilor. Toate
aceste erori di n etapele menționate mai sus pot fi remediate, dacă acestea sunt descoperite în
timp util sau pot fi considerate erori cunoscute fără o posibilitate reală de rezolvare din cauza
identificării acestora într -o etapă avansată.
În medie apariția erorilor este cauzată în proporție de 60% de lagunele din specificații,
în timp ce erorile apărute din cauza proiectării sunt în procent de 30. Putem considera că
apariția erorilor din cauza greșelilor de programare sunt cele mai puțin răspândite, în
proportșie de 10%, intrucât și programatorii, la dezvoltarea produsului își testează codul.6
(Fagarasan, 2017)

6 Ioana Fa garasan, 2017, Testarea Software și asigurarea calității – curs 2

17
Figura 1-8 Evoluția costului în raport cu avansarea procesului de dezolvarea al produsului program, sursa: Conf.
dr. ing. Ioana Fagarasan, Testarea Software și asigurarea calității – curs 2
În Figura 1.1 -8 se poate observa impactul, din punct de vedere al costurilor, pe care -l
are descoperirea erorilor în procesul de dezvoltarea al produsului. Această creștere a costurilor
este direct proporțională cu evoluția întregului proces. Cu cât descoperirea erorilor este
realizată mai aproape de faza incipientă, cu atât costurile pentru eliminarea erorii sunt mai
mici, tinzând spre 0. Dacă identificare erorii se realizea ză într -o fază avansată, atunci
costurile sunt mai mari, acestea crescând progresiv de la o etapă la alta.

1.5. Clasificarea testelor
Teste de sistem pot fi împărțite în mai multe categorii precum este prezentat și în
cursul 3 7 :
• Teste de baza;
• Teste funcțio nale, aceste sunt împărțile la rândul lor în mai multe categorii:
▪ Teste de interoperabilitate;
▪ Teste de securitate;
▪ Teste de conformitate;
• Teste nefuncționale, acestea la rândul lor sunt compuse din mai multe categorii
precum:
▪ Teste de performanță;
▪ Teste de scalabilitate;
▪ Teste de stres;
▪ Teste de încărcare și stabilitate;
▪ Teste de fiabilitate
▪ Teste de documentație;
• Teste de regresie;
• Teste de confirmare.
Prin intermediul testelor de bază se asigură ca sistemul ce urmează a fi testat este instalat
corect, poate fi configurat conform cerințelor echipei de testare, iar acesta este într -o stare
funcțională pentru a se putea începe procesul de testare.
În cadrul execuției testelor funcționale acestea au rolul de a acoperi în întregime toate
cerințele venite din partea clientului, acestea fiind documentate în partea de design, dar și a
specificațiilor de de utilizare. Fiecare cerință sau specificație trebuie să fie mapată cu cel puțin
un test. De regulă, o cerință trebuie să fie corelată cu cel puțin un test, iar un test poate fi
mapat, la rândul său, cu mai multe cerințe. Situația în care un test este corelat cu mai multe
cerințe este una mai puțin întâlnită, iar acest lucru nu este recomandat pentru realizarea unei
validări corecte a aplicație i8. În practică, corelarea se realizează la nivel de cerințe sau
specificații și anume, o cerinț ă poate avea cel puțin un test pe care să o valideze.

7 Cursul de ”Testarea Software și asigurarea calității” din anul 2017, regașit pe website -ul: http://shiva.pub.ro
8 Pentru a realiza o validare corespunzătoare este important ca fiecare cerință sau specificație să fie testată separa
cu scopul de a evita apariția erorilor care pot apărea în urma testării.

18
Testele de interoperabilitate realizează o combinație între diferite elemente ale
sistemului într -un singu r mediu de testare, cu scopul de a realiza funcționarea corectă
împreună. Aceste tipuri de teste sunt create pentru a asigura ca sistemul poate fi interconectat
cu alte sisteme fără a avea un impact negativ și a putea fi folosit în continuare fără probleme .
Verificare sistemului în cadrul unei platforme invechi face parte tot din testarea de
interoperabilitate.
Testele de securitate are scopul de a asigura utilizatorul că aplicația este lipsită de orice
vulnerabilitate, amenințare sau riscuri ce pot cauza pierderi. Acest tip de testare visează
gășirea tuturor lagunelor și a punctelor slabe ale sistemului care ar putea duce la pierder ea de
informații, venituri, reputație, etc. În situația în care testarea de securitate este amânată acest
lucru atrage după șine costuri uroașe dacă lagunele sunt frunctificate de către hakeri.
Totodată, costul este ridicat și în situația în care această o perațiune este amânată după faza de
implementare sau după implementare. Pentru a reduce costurile este necesar ca acest tip de
testare să facă parte din ciclul de viață al dezvoltării unui produs, precum este prezentat în
Figura 1.1 -9.

Figura 1-9 Etapele între care trebuie introdusă testare de securitate

Testele de conformitate , cunoscute și sub denumirea de testare a conformității,
testarea reglementărilor este un tip de testare pentru a determina conformitatea unui sistem cu
standard ele interne sau externe. Standardele interne ar putea fi stabilite de companie în sine.
Spre exemplu, o companie de dezvoltare de aplicații web ar putea seta standardul că toate
paginile web să fie receptive. Standardele externe ar putea fi stabilite în af ara companiei. De
exemplu, Consiliul Uniunii Europene a stabilit reglementări în ceea ce priveste acordul pentru
procesarea datelor cu caracter personal.
Testele de performanță au scopul de a realiza o măsurare a performanțelor reale ale
sistemului, cumpa rându -le astfel cu cele teoretice. Metricile performanțelor ce trebuie
măsurate variază de la aplicație la aplicație. Spre a înțelege mai bine acest aspect este
necesarară elaborarea unui exemplu: timpul de raspuns al unei aplicații trebuie să fie de mai
puțin de o secundă în 90% dintre cazuri la o aplicație de genul ”Calculator matematic
simplu”. În urma testelor de performanță se urmăresc aspectele: timpul de răspuns, ieșirile
sistemului și utilizarea răspunsurilor. În urma executării testelor, dacă acest ea nu sunt
satisfăcătoare, atunci se iau măsuri pentru îmbunătățiri, precum: rescrierea codului, alocarea

19
de mai multe resurse, redesign de sistem, etc. Cea mai importantă condiție pentru realizarea
testelor de performanță este ca mediul de test, pe care s e execută testele, trebuie să fie identic
cu cele de producție. În funcție de procentul pe care îl opține aplicația la testarea de
performanță se poate concluziona dacă produsul dezvoltat este considerat performant sau nu.

Figura 1-10 Rentabilitatea testelor de performantă, sursa: http://toolsqa.com

Scalabilitatea unui produs software poate fi defintit ca și capacitatea acestuia de a
putea fi mărit pentru a face față unei încărcări mărite. Scopul testelor de sca labilitate este de
a verifica dacă sistemul își atinge limitele sale tehnologice. Un sistem poate funcțio na într -un
scenariu cu utilizare limitată, dar nu poate fi extins uneori. Odată cu adăugarea unor noi
funcționalități timpul de rulare al unui sistem p oate crește exponețial sau poate ceda după o
anumită limită. O aplicație poate fi considerată scalabilă dacă după o mărire a încărcării
sistemului este necesar doar resurse adiționale, fără modificări extensive ale aplicației. Ca în
orice domeniu, limitele aplicațiilor pot fi definite de:
• Limitări de stocare a datelor;
• Limitări de bandwidth;
• Limitări de viteză – CPU9.
Testele de stres sunt definite ca un tip de testare software care trebuie să verifice
stabilitatea și fiabilitatea sistemului. Acest tip de t este determină în principal sistemul de
robustețe și de manipulare a erorilor în condițiile de încărcare extre m de grele. Acest tip de
testare se execută pentru a se asigura ca sistemul nu se va prăbuși în situații de criză. În
ingineria testării software, testele de stres sunt cunoscute sub denumirea de Endurance
Testing. În timpul testelor de stres, aplicația este supusă unei încărcături foarte mari de date
pentru o perioadă scurtă de timp, cu scopul de a cunoaște capacitatea sa de a rezista. Scopul
utilizării frecvente a testelor de stres este de a determina limita la care software -ul nu mai

9 Central Processing unit – Unitatea centrală de procesare.

20
funcționează corespunzator. De asemenea, prin intermediul testării de stres se verifică daca
sistemul gestionează eficient erorile în condișii extreme.

Figura 1-11 Raportul dintre supunerea aplicației la testele de stres și încarcarea aplicației , sursa:
http://guru99.com

În Figura 1.1 -11 se poate observa că odată ce aplicația este supusă unui volum foarte
mare de date care necesită a fi proce sate, crește și timpul de încarcare al aplicației.
Testele de încărcare și stabilitate au scopul de a se asigura de stabilitatea sistemului
pe o perioadă lungă de timp cu încărcare completă. Un si stem poate funcționa excelent atunci
când acesta este tes tat de ingineri, care îl folosesc în mod corect. Atunci când intervine un
număr semnificativ mai mare de utilizatori și acestia nu cunosc sistemul, iar aplicația rulează
luni de zile fără a fi repornită, pot interveni diverse probleme:
• Sistemul încetinește ;
• Probleme de funcționare;
• Sistemul de oprește treptat;
• Sistemul cedează complet;
Datorită acestui tip de teste putem înțelege cum se va comporta aplicația în viața reală,
iar pentru a obține rezultate realiste este necesar ca scenariile să fie cât mai rea liste, mai
apropiate de modul în care ut ilizatorii vor folosi aplicația.
Întrucât de cele mai multe ori se crează o confuzie între testele de stres și testele de
încarcare, în Tabelul 1.1 -1 se poate observa diferențele dintre cele două tipuri de teste.

21
Tabelul 1-1 Diferențe dintre testele de încărcare și testele de stres

Scopul testelor de fiabilitate este acela de a realiza o măsurare a capacității sistemului
de a rămâne funcțional pentru o perioadă lungă de timp într -un mediu specific. Fiabilitatea
unui sistem se poate exprima în termeni de timp mediu până la cedarea acestuia ( mean time to
failure – MTTF10). Pentru realizarea testării de fiabilitate este necesară folosirea unui efort
suplimentar, întrucât acest tip de testare este considerat costisitor în comparație cu alte tipuri
de testare. Drept urmare este necesară o planificare și o gestionare ade cvată în timpul
executării testelor de fiabilitate.
Testarea pentru fiabilitate se referă la exercitarea unei aplicații, astfel încât eșecurile să
fie descoperite și eliminate înainte ca sistemul să fie implementat. Există în principal trei
abordări util izate pentru testarea fiabilității:
• Testarea -retestarea fiabilității;
• Fiabilitatea formelor paralele;
• Coerența deciziei.
Documentația de testare face parte din testarea nefuncțională a unui produs. Aceasta
poate fi considerată un tip de testare blackbox11, care asigură că documentația ofertă
informații precise despre modul în care funcționează aplicația, astfel furnizând dovada că
schimbările de sistem și îmbunătățirile au fost documentate. (What is documentation testing?,
2011) .
Testarea de confirmare este folosită atunci când un scenariu de test este considerat eșuat
și se stabilește faptul că un defect a cauzat acest lucru. După raportarea defectului, acesta este
fixat și se întoarce la echipa de t estare, aici este re-executat cazul de testare, pentru a confirma
faptul că defectul a fost într -adevăr reparat, acest proces fiind denumit și test de confirmare.
Pentru realizarea corectă testului de confirmare este necesar ca acesta să fie re -executat in
aceleași condiții , cu aceleași date de test, ca atunci când s -a executat prima dată. Pentru
asigurarea funcționalității corecte a aplicației, nu este suficientă doar retestarea, trebuie
verificate și posibile ”efecte se cundare” introduse prin fixare, astfel s e rulează și t este de
regresie.
Testarea de regresie este considerată una dintre cele mai importante teste în procesul de
testare, atunci când unui software deja dezvoltat i se adaugă noi funcționalități. Acest teste se
execută cu scopul de a ne asigura că funțiionalită țile anterioare nu au fost afectate. Se poate
considera că testarea de regresie este o re -rulare a testelor funcționale și a celor non –
funcționale. Modificările care pot necesita efectuarea unei testări de regresie sunt: remedierea
unei erori, îmbunătățiri le aduse software -ului, modificări de configurație și chiar înlocuirea
componentelor electronice. În situațai în care testele de regresie tind să crească cu fiecare
defect găsit, atunci se apelează la automatizarea testării. (Basu, 2015)
Întreținerea software -ului este o activitate care include îmbunătățiri, corecții de eroare,
optimizări și stergeri de caracteristici existente. Aceste modificări pot cauza funcționarea

10 Mean time to failure – timpul până când sistemul o să vedeze.
11 Cutia neagră – este o metodă de testare care v -a fi descrisă în paginile următoare.

22
incorectă a sistemului, dar drept urmare este necesară execu tarea testării de regresie. Acest tip
de tetare poate fi efectuată utilizând tehnicile precizate în Figura 1.1 -12.

Figura 1-12 Tehnici de testare pentru testarea de gresie
1. Retestare totală , după cum sugerează și numele, toate cazurile de testare din suita de
testare trebuie să fie re -executate pentru a se asigura ca nu există erori care au apărut
din cauza unei modificări a codului. Aceasta este o metodă costisitoare deoarece
necesită mai mult timp și resurse în comparație cu celelalte tehnici.
2. Selectarea testelor de regresie , în această metodă, cazurile de testare sunt selectate
din setul inițial de teste, urmând ca doar cele considerate redundante să fie re –
executate. Selectarea cazurilor de testare se face pe baza modificării codului în modul.
Cazurile de testare sunt împărțite in două categori: cazurile de testare reutilizabile și
cazurile de testare învechite. Cazurile de testare reutilizabile pot fi utilizate în ciclurile
de regresie viitoare, în timp ce cele învechite nu sunt util izate în viitoarele cicluri de
regresie.
3. Prioritizarea cazurilor de testare , cazurile de testare cu prioritate sunt executate mai
întâi decât cele cu prioritate medie și joasă. Prioritizarea cazurilor de testare depinde
de criteriile sale și de impactul acestora asupra produsului, precum și de
funcționalitatea produsului utilizat mai des.
4. Hybrid , această tehnică este o combinație de selecție a testelor de regresie și de
prioritizare a cazurilor de testare. În loc să se selecteze întreaga suită de testare, se
selectează numai cazurile care sunt re -executate în funcție de prioritatea lor.
În selecțai cazurilor de testare pentru procesul de regresie, trebuie să ținem cont de:
• Funcționalitățile utilizate frecvent;
• Cazurile de testare care acoperă modulul în care s -au efectuat modificările;
• Cazurile complexe de testare;
• Cazurile de integrare care includ toate componentele majore;
• Cazurile de testare pentru funcționalitatea sau caracteristica de bază a produslui;
• Cazurile de testare care sunt marcate cu prioritate 1 sau 2 trebuie incluse;
• Cazurile de testare care au fost testate cu eșec în mod frecvent.
Pentru a se întelege mai bine diferența dintre testarea de regresie și testarea de confirmare,
în Tabelul 1.1 -2 sunt detaliate diferențele din tre cele doua tipuri de testare.

23

Tabelul 1-2 Diferențe dintre testarea de regresie și testarea de validare

1.6. Metode de testare
Testarea software este împărțită în mai multe metode, iar fiecare metodă fii nd
corecpunzatoare unui tip de soft dezvoltat. Echipa de testare are obligația de a selecta metoda
prin care produsul v -a fi testat. Aceste metode sunt:
• Testare Black Box12;
• Testare White Box13;

12 Cutia neagră
13 Cutia albă

24
• Testare Gray Box14;
• Testare Agile15;
• Testare Ad hoc.

Testarea Black Box este cunoscută și sub denumirea de testare de comportament.
Acest tip de testare este o metodă în care structura internă/ proiectarea/ implementarea
produsul testat nu este cunoscută de tester sau echipa de testare , așa cum este prezentat î n
Figura 1.1 -13. Aceste teste pot fi funcționale sau nefuncționale, iar întreaga concentrare
trebuie să fie pe intrările și ieșirile sistemului software fără a cunoaște strunctura internă a
sistemului.

Figura 1-13 Structura m etodei de testare Black box, sursa: http://softwaretestingfundamentals.com
Această metodă este denumită astfel, întrucât programul software, în ochii testărului este
ca o cutie neagră, în care nu se poate vedea. Această metodă încearcă să gasească erori în
următoarele categorii:
• Funcții incorecte sau lips ă;
• Erori de interfețe;
• Erori în structurile de date sau în accesarea bazei de date externe;
• Comportament sau erori de performanță;
• Eroare de inițializare și terminare.
La abordarea acestei metode, testărul este conștient de modul în care ar trebui să
funcț ioneze software -ul, însă acesta nu știe modul în care sunt realizate acțiunile. Spre
exemplu, testărul este conștient de faptul ca o anumită intrare returnează o anumită ieșire, insă
nu este conștient de procesele care se execută pentru a ajunge la rezultatul așteptat . (Patton,
2005)
Avantajele metodei de testare Black Box sunt:
• Testele se realizează din punctul de vedere al utilizatorului și vor ajuta la
expunerea discrepanțelor din specificații;
• Testărul nu trebuie să știe limbaje de programare sau modul în care a fost
implementat software -ul;

14 Cutia gri
15 O practică de testare software care respectă principiile dezvoltării software Agile.

25
• Testele pot fi efectuate de persoane independente de dezvoltatori , astfel per mițând
o perspectivă obiectivă;
• Cazurile de testare pot fi p roiectate odată ce specificațiile sunt complete.
Dezavantajele metodei de testare Black Box :
• Numai un număr mic de intrări posibile pot fi testate și multe căi de program vor
rămâne netestate;
• Fără specificații clare cazurile de testare vor fi dificil de proiectat;
• Testele pot fi redundante dacă proiectantul/dezvoltatorul a executat deja teste;

Testarea White Box este cunoscută și sub denumirea de cutia curată . Acest tip de
testare este o metodă în care structura internă / proiectarea / implementarea îi este cunoscută
testărului. Testărul are posibilitatea de a -și alege intrările pentru a putea executa flux -ul dorit
și astfel determinând ieșirea dorită. Cunoștințele de programare și implementare sunt necesare
pentru această metodă. Testarea cutiei albe este testarea dincolo de interfața cu utilizatorul,
testărul având posibilitatea de a testa fiecare acțiune în parte. Denumirea metodei este
sugestivă, întrucât din perspectiva testărului interiorul produsului program este tran sparent.
Metoda de testare White Box este aplicabilă următoarelor niveluri de testare software:
• Unit testing16;
• Integration testing17;
• System testing18.
Prin testarea unității se asigură despre codul dezvoltat că acesta funcționează
corespunzător. Prin interm ediul acestui tip de testare se captează orice defecțiune, urmând să
fie reparată imediat, fără a se trece la următoarea fază. Nu se trece la testarea integrării până
ce defectul nu este fixat.
Testarea de integrare se realizează pentru a observa modul în care interactionează
interfețele între ele. Etapa precedentă a asigurat funcționarea corectă a codului dezvoltat într –
un mediu izolat, urmând ca în etapa de intregare să se asigure funcționarea într -un mediu
deschis, siste mele fiind interconectate.
În eta pa de testare a sistemului se realizează testarea efectivă a întregului sistem.
Avatajele testării While Box sunt:
• Testarea poate fi începută într -o etapă anterioară. Nu trebuie să se aștepte
implementarea GUI -ului19;
• Testarea este aprofundată, cu posibili tatea de a acoperi majoritatea fluxurilor;
Dezavantajele testării Whide Box sunt:

16 Testarea unităților – testarea căilor dintr -o unitate
17 Testarea de integrare cu alte sisteme sau a căilor între unități
18 Testarea sistemului – testarea căilor între subsisteme
19 Guide User Interface – interfața cu utilizatorul

26
• Testarea poate fi complexă, iar acest lucru necesită resurse calificate cu cunoștințe
aprofundate în programare și implementare;
• Mentenanța scriptului de testare poate fi con siderată o povară din cauza schimbărilor
frecvente;
Diferențele dintre metodele de testare a cutiei albe și a cutiei negre sunt ilustrate în
Tabelul 1.1 -3:

Tabel 1-3 Diferențe dintre testarea Black Box și testarea White Box
Testarea Gray Box este o metodă de testare care combină testarea Black Box cu
testarea White Box. La această metodă de testare structura internă a produsul dezvoltat este
parțial cunoscută. Testărul are acces la structura de date internă și la algoritmi cu scopul de a
realiza cazurile de testare. Testarea putând fi realizată atât din perspectiva cutiei negre, cât și
din cea a cutiei albe.
Testarea Agile este un proces de testare a software -ului care urmărește principiile
dezvoltării software Agile. Acest ti p de testare se aliniază cu metodologia de testare iterativă
în care cerințele se dezvoltă treptat de la clienți și echipele de testare. Dezvoltarea fiind
aliniată cu cerințele clienților. Testarea Agile este considerat un proces continuu în
detrimentul ce lui secvențial. Testarea este pornită la începutul proiectului și pe parcurs este
realizată o continuă integrare între dezvoltare și testare. Obiectivul comun al dezvoltării și
testării Agile este obținerea unui produs de calitate ridicată.
Testarea Ad -hoc este un termen folosit frecvent în testarea software -ului efectuat fără
planificare și documentare. La această metodă de testare, testele se execută o singură dată, cu
excepția cazurilor în care se constată un defect. Acestă metodă a fost criticată întru cât nu este
structurată și drept urmare defectele identificate prin această metodă pot fi greu de reprodus.
Cu toate acestea, scopul testelor Ad -hoc este ca defectele importante să fie identificate rapid.
Testarea Ad -hoc se realizează prin improvizație, te stărul caută să identifice defecte prin orice
mijloace adecvate.

27

1.7. Testarea automată
În testarea software, automatizarea testării se realizează cu ajutorul unui software
separat pentru a controla și executa cazurile de testare. După executarea testelor, rez ultatele
obținute sunt comparate cu rezultatele așteptate în scopul de a valida scenariul de test20
(Kolawa & Huizinga, 2007) . După executarea testelor se poate genera un raport detaliat de
testare în care sunt speculate rezultatele. Prin intermediul acestui proces de automatizare se
pot automatiza sarcinile considerate repetitive, dar necesare pentru procesul de testare.
Totodat ă automatizare procesului de testare poate fi folosit și la executarea testelor
suplimentare considerate greu de realizat de câtre resursa umană. Odată cu ce dorește
implementarea testării automate, trebuie să se țină cont că acest lucru necesită investiți i
considerabile de bani, dar și resurse.
Ciclcul de dezvoltare succesivă v -a necesita executarea aceleiași suite de teste în mod
repetat. Utilizând uneltele de testare automată este posibil ca suita inițială de teste să fie
executată de un număr ridicat de ori. Odată cu automatizarea testelor, intervenția umană nu
este necesară. Scopul automatizării este de reduce numărul de teste executate manual, care ar
însemna un timp ridicat de execuțiie, dar acest lucru nu înseamnă eliminarea completă a
testării manu ale.
Motivele pentru care testarea automată este importantă sunt:
• Testarea manuală a tuturor fluxurilor de lucru, câmpurilor și scenariilor negative
este comsumatoare de timp și bani;
• Este dificilă testarea manuală a website -urilor multilingviste;
• Automati zare nu necesită intervenția umană în timpul executării scenariilor de test.
Scripturile de testare pot fi rulate peste noapte;
• Automatizarea înseamnă execuția rapidă a scenariilor de test;
• Automatizarea ajută la acoperirea unui număr mare de teste;
• Testar ea manuală poate fi considerată plictisitoare, iar din acest motiv pot apărea
erori.
Pentru selecția cazurilor de testare ce trebuie a fi automatizate este necesar să se
urmărească următoarele criterii:
• Cazurile de testare care sunt marcate cu risc ridicat ;
• Cazurile de testare care sunt necesare să se execute în mod repetat;
• Cazurile de testare considerate obositoare și greu de executat manual;
• Cazurile de testare care necesită un timp îndelungat pentru executarea lor;
• Cazurile de testare care sunt executat e în etapa de regresie.
În domeniul testării, automatizarea nu se poate realiză în totalitate, întrucât anumite
scenarii de test necesită intervenția umană, drept urmare, următoarele cazuri de testare nu pot
fi automatizare:

20 Kolawa, Adam; Huizinga, Dorota, 2007, Automated Defect Prevention: Best Practice in Software
Management

28
• Cazurile de testare care sunt nou proiectate și nu au fost executate manual cel
puțin odată;
• Cazurile de testare pentru care cerințele sunt frecvent schimbate;
• Cazurile de testare care sunt executate cu ajutorul metodei ad -hoc.
În Figura 1.1 -14 sunt prezentate etapele procesului de automatizare.

Figura 1-14 Procesul de testare automată, sursa: http://guru99.com
O etapă importanță în procesul de automatizare reprezintă selectarea software -ului în
care se vor dezvolta re scripturile. Acest etapă este importantă pentru a se realiza
compatibilitatea dintre aplicația ce trebuie testată și software -ul în care se vor dezvolta
scripturile.
Domeniul de aplicare al automatizării este chiar domeniul aplicației ce trebuie testa te.
Următoarele puncte ajută la determinarea scopului automatizării :
• Funcționalitățile considerate importante de către client;
• Scenariile care au un conținut mare de date;
• Fezabilitatea tehnică;
• Complexitatea cazurilor de testare;
• Posibilitatea de a utiliza aceleasi cazuri de testare si pentru alte browsere.
În etapa de planificare, proiectare si dezvoltare se crează o strategie de testare
automată care trebuie să conțină următoarele detalii:
• Software -ul ales pentru dezvoltarea scri pturilor de testare;
• Selectarea testelor care sunt considerate în scop sau în afara scopului pentru
procesul de automatizare;
• Pregatirea procesului de automatizare;
• Realizarea programării pentru executarea scripturilor;
• Rezultatele testării automate.
În et apa de execuție a testelor scripturile dezvoltate sunt rulate. Pentru a se porni
executarea testelor este necesar să se întroducă inițial date de intrare. După introducerea
datelor de intrare scripturile vor fi pornite, urmând ca la finalizarea acestora se v-a genera un
raport despre testele executate, oferind informații despre testele eșuate și cele validate.

29
Pe măsură ce noi funcționalități sunt adăugate aplicației, în etapa de mentenantă ,
scripturile de automatizare trebuie actualizare, rezivuite și într eținute pentru a oferi în
continuare rezultate redundante și a menține calitatea produsului la un nivel ridicat.
Odată cu trecerea la testarea automată se pot observa următoarele beneficii:
• Rapiditatea testării crește cu 70% în detrimentul testării manuale;
• Acoperirea unui număr mai mare de teste;
• Asigurarea consistenței;
• Economisirea timpului și a costurilor;
• Îmbunătățirea preciziei;
• Intervenția umană nu este necesară;
• Creșterea eficienței;
• Rapiditate în executarea testelor;
• Scripturi de te stare reutilizabile;
• Executarea frecventă a testelor;

Automatizarea poate fi realizată doar pe anumite tipuri de teste precum: smoke
testing21, unit testing22, integration testing23, functional testing24, regression testing25, black
box testing26.
1.8. Instrumente p entru automatizarea testării
În domeniul testării automate, un software folosit din ce în ce mai des de către marile
companii este Selenium. Acest software este folosit pentru testarea aplicațiilor web, cu
ajutorul căruia procesul de testare poate fi autom atizat, întrucât cazurile de testare pot fi scrise
în multiple limbaje de programare. Limbajele cu ajutorul cărora se pot dezvolta scripturi de
testare automată sunt: Java, C#, Ruby, Python, Perl, Php și JavaScript. (Selenium Projec t, fără
an). Cazurile de testare care au fost transpuse în scripturi pot fi rulate pe cele mai moderne
browsere web. Selenium este disponibil pe mai toate platformele sistemelor de operare
precum: Windows, Linux și macOS. Acest software este o aplicaț ie ”open -source”27, rulând
sub licența Apache 2.0.
Pentru început Selenium a fost dezvoltat de către Jason Huggins în anul 2004 ca o
aplicația internă folosită în compania ThoughtWorks. În același an, Jason Huggins alături de
mai multi programatori și testă ri au lansat cel de -al doilea model denumit ”Selenium Remote
Control” (RC). Un an mai târziu, Dan Fubulich și Nelson Sproul au acceptat oferta de a -și
aduce contribuția la ceea ce urma să devină Selenium, alaturi de Jason Huggins și Paul
Hammant, acestia f iind în continuare reprezentanți ai companiei ThoughtWords

21 Testare rapidă
22 Testare de unităță
23 Testare de integrare
24 Testare funcțională
25 Testare de regresie
26 Testare prin utilizarea metodei cutiei negre
27 Cu sursă deschisă, însemnând că un produs include permisiunea de a utiliza codul sursă, documentația de
proiectare sau conținutul.

30
În 2007, după ce Jason Huggins s -a alăturat companiei Google, împreună cu alți colegi
au continuat să dezvolte și să stabilizeze Selenium RC. În paralel, Simon Steward din cadrul
ThoughWords a dezv oltat un produs de automatizare a aplicațiilor web, pe aceleași principii
ca și Selenium RC, denumindu -l WebDriver. După conferința din 2009 ”Google Test
Automation” la care au participat programatorii celor două aplicații, acestia au dechis alipirea
celor două proiecte sub denumirea: Selenium WebDriver sau Selenium 2.0.
Selenium este format din mai multe componente, fiecare având propriul rol în
automatizarea testării aplicațiilor web:
• Selenium IDE28 – este implementat ca un Add -on în Firefoxm sau ca o
extensie în Chrome și poate fi utilizată numai pentru a crea cazuri de testare
relativ simple . Aceasta permite înregistrarea, editarea și depanarea testelor
funcționale, putând astfel să fie urmărit în regul proces de testare automat .
Selenium IDE a f ost donat proiectului Selenium în anul 2006 și a fost ulterior
menținut pentru scurt timp (Evans, 2016) , urmând să fie întreținut în mod activ
în anul 2018 (Ensminger, 2018) ;
• Selenium Remote Control – cunoscut și sub denumirea de Selenium 1 este
un server, scris în java, care acceptă comenzi pentru browsere prin intermediul
http. RC permite utilizatărilor să se folosească de limbaje de programare pentru
a crea teste complexe;
• Selenium client API – este o alternatică de a scrie cazurile de testare în
Selenese, iar testele pot fi scrise in diverse limbaje de programare. În prezent
Selenium oferă clienți API pentru Java , C#, Ruby, JavaScrip și Python;
• Selenium WebDriver este succesorul aplicației Selen ium RC și este cea mai
nouă descoperire care permite scripturilor să comunice direct cu browserul,
putând astfel să fie controlat de la nivelul sistemului de operare. După
executarea comenzii, browserul trimite înapoi rezultatul obținut, precum este
schema tizat în Figura 1.1 -15;
• Selenium Grid – este un server care permite cazurilor de testare să utilizeze
instanțele browserelor pe mașini la distanță (remote machines). Cu Selenium
Grid un server se comportă precum un hub29. Este folosit împreună cu
Selenium RC pentru a efectua teste paralele pe diferite browsere și sisteme de
operare.

28 IDE = Integrated Development Environment
29 Poate fi consi derat o listă de servere care permite accesul la instanțele browserelor și lasă să execute cazurile
de testare în acele instanțe.

31

Figura 1-15 Procesul de execuție al testelor rulate cu ajutorul Selenium WebDirver, sursa:
http://softwaretestingtalk.com
Întrucât Selenium nu este singurul software folosită pentru dezvoltarea scripturilor de
testare automată, în Tabelul 1.1 -4 se prezintă diferențele dintre aplicațiile similare precum:
HP QTP30 și IBM RFT31.

Tabel 1-4 Comparație între software -urile utilizate pentru dezvoltarea scripturilor de testare automată, sursa:
https://www.edureka.co/

30 HP Quick Test Professional, dezvoltat de Micro Focus
31 IBM Rational Functional Tester, dezvoltat de Rational Software

32
1.9. Raportarea defectelor identificate
Raportul defectelor este un document în care sunt contorizate și descrise defectele
descoperite de câtre echipa de testare. Scopul unui raport de defecte este de a preciza într -un
mod cât mai clar și concis împrejurimile în care se sunt identificate acest defect. Detalierea
clară a defectelor are un rol important, întrucât aceasta ajută la replicarea defectelor de către
dezvoltatori și fixarea lor.
Un raport de defecte are următoarele componente: numărul unic de identificare,
denumirea proiectului testat, denumirea produsului, versiunea testată, modul în care a fost
identificat defectul, rezumatul, descrierea, pașii pentru replicare, rezultatul actual, rezultatul
așteptat, fișier atașat pentru evid ențierea defectului, prioritatea defectului, numele persoanei
care a raportat defectul, statusul defectului și versiunea fixului, acest câmp urmând să fie
completat ulterior, după ce defectul a fost fixat.
La identificarea unui defect, acesta este compus d intr-o combinație de doi factori care
pot influența progresul testării , precum (Testing Strategy, 2015) :
• Impactul – Întreruperea serviciilor față de client, impactul asupra veniturilor,
potențialul cost pe care l -ar avea defect ul în caz de non -rezoluție;
• Urgența – Timpul care poate fi tolerat până la rezolvarea defectului, dar și
rapiditatea cu care ar trebui că defectul să fie fixat. În stabilirea urgenței trebuie
luat în calcul și existenț a unei soluții de moment cu scopul de a se continua cu
testarea.
În Tabelul 1.1 -5 este descris nivelul de urgentare a defectului și totodată acest indice
sugerează rapiditate cu care defectul trebuie rezolvat:

Tabel 1-5 Descrierea urgenței unui proiect, sursă: documentație internă UPC România
În Tabelul 1.1 -6 este detaliat impactul pe care un defect îl poate avea asupra unui
proiect în procesul de testare:

33

Tabel 1-6 Descrierea impactului asupra unui proiect în procesul de testare, sura: docu mentație internă UPC
România
Realizând o combinație între cei doi factori care influențează un defect rezultă
prioritatea defectului, aceastea fiind exemplicate de cifra de la 1 până la 4, iar 1 însemnând că
prioritatea defectului este maximă, iar 4, prio ritatea defectului este minimă. Tabelul 1.1 -7
exemplifică modul în care se selectează prioritatea defectelor:

Tabel 1-7 Selectarea priorității defecetelor, sursa: documentație internă UPC România
Pentru ca procesul de testare să nu fie impactat, iar termenul setat inițial pentru
finalizarea testării să nu fie amânat este necesar ca să se definească timpul în care echipa de
dezvoltare trebuie să revină cu un răspuns la defectul ridicat, urmat de o r ezoluție. În Tabelul
1.1-8 este descrisă standardizarea timpului de răspuns la defectele măsurată în ore:

Tabel 1-8 Timpul de răspuns pentru rezolvarea defectelor, sursa: documentație internă UPC România

34
CAPITOLUL 2

2.1. Prezentarea soluți ei
Pănă la automatizarea procesului de testare trebuie să se ia în calcul tehnologiile ce
urmează a fi folosite în scopul de realizare a automatizării. Pentru reali zarea acestui proiect s –
a optat pentru folosirea mediului de dezvoltare Eclipse , urmând ca dezvoltarea scripturilor de
testare automată să fie scrise în limbajul de programare Java . Pentru realizarea conexiunii și
transmiterea comenzilor de la scripturil e dezvoltate la browser s -a utilizat framework -ul
Selenium WebDriver , acesta tehnologie fiind detaliată în capitolul 1.8. . Pentru gestionarea
și vizualizarea cât mai detaliată a pașilor parcurși, dar și a rezultatelor obținute din urma
automatizării proce sului de testare s -a folosit framework -ul extent reporting . Pentru
generarea rapoartelor, gestionarea eficientă a cerințelor venite din partea clientului, a cazurilor
de testare create special pentru fiecare cerință s -a utilizat HP ALM , acest tehnologie fi ind
descrisă la capitolul 2.3.1. .
Eclipse este un mediu de dezvoltare integrat (IDE32), utilizat în programarea
calculatoarelor, iar în anul 2014 a fost cel mai folosit mediu de dezvoltare Java (White, 2014) .
Acest mediu de dez voltare are un spațiu de lucru și un număr mare de extensii plug -in care
pot ajuta utilizatorul să -și personalizele mediul de dezvoltare așa cum doresc. Eclipse este
scris în java , iar aces mediu este utilizat cel mai des în dezvoltarea de aplicații java, dar
totodată poate fi folosit și pentru dezvoltarea de aplicații în alte limbaje de programare. Kit -ul
de dezvoltare software Eclipse (SDK33) este gratuit și are o dezvoltare de tipul open -source34,
lansat în termenii Eclipse Public License, dar este incomp atibil cu GNU General Public
License. (Free Software Foundation, Inc., 2012)
Java este un limbaj de programare care este bazat pe clase, orientat pe obiecte și proiectat
ca să aibă cât mai puține dependințe de implementare. Este destinat să permită dezvoltatorilor
de aplicații să dezvolte o singură dată codul și să poate fi rulat oriunde (WORA35) (Computer
Weekly, 2002) ceea se înseamnă, codul java compilat poate rula pe toate platformele care
suportă j ava fără să mai fie nevoie de recomplilare.
Extent reporting este un framework folosit pentru a crea un raport interactiv și detaliat
despre procesul de testare automată, acesta fiind generat la finalizarea rulării scripturilor de
automatizare. Cu ajutorul acestui framework se pot adăuga evenimente, capturi de ecran, tag –
uri, detaliile dispozitivului de pe care au fost executate testele, autorul executării testelor, dar
și alte informații relevante pentru procesul de testare.
Pentru a putea începe dezvoltar ea scripturilor de testare automată a fost necesar pentru
început instalarea mediului de dezvoltare și apoi adăugarea framework -urilor în Eclipse, iar
pentru realizarea acestora trebuie urmați pașii :
• Pasul 1: Descărcarea și instalarea mediului de dezvolta re integrat Eclipse;

32 Integrated Develpment Environment
33 Software Development Kit
34 Sursa deschisă
35 Write once, run anywhere – este un slogan creat de compania Sun Microsystem pentru a ilustra avantajele
limbajului de programare java.

35

Figura 2.1-1 Panou de instalare Eclipse
După descărcarea aplicație și executarea acesteia se ajunge în panoul de instalarea al
mediului Eclipse și se selecteaza ”Eclipse IDE for java Developers” pentru instalare, așa cum
este prezentat în Figura 2.1 -1, iar după finalizarea instalării se trece la pasul următor.
• Pasul 2: Descărcarea și instalarea kit -ului de dezvoltarea java
Kit-ul de dezvoltare este o implementare a unei platforme Java lansată de către
compania Oracle sub forma unui produs binar cu scopul de dezvoltarea a unor produse java
pentru sistemele de operare precum: Solaris, Linux, macOS sau Windows. Kit -ul include
mașini virtuale și alte resurse care ajută la fin alizarea dezvoltării aplicației.
• Pasul 3: Descărcarea și instalarea versiunii dorite de Selenium WebDriver, precum
și descărcarea Ge ckoDriver
După selectarea și descărcarea framework -ului pentru limbajul de programare java și
pentru browser -ul pe care dori m să facem test, trebuie încărcate în mediul de dezvoltarea
produsele Selenium. În continuare se selectează spațiul de lucru în care se vor salva scipturile
dezvoltate, urmând ca pentru integrarea framework -urilor este necesat să creăm un nou
proiect, iar după crearea proiectului vom crea un nou pachet, precum și o nouă clasă, precum
este ilustrat în Figura 2.1 -2.

Figura 2.1-2 Crearea unui proiect Java

36
În continuare pentru a putea adăuga librăriile de Selenium WebDriver mergem pe
proiectul nou creat, dăm click dreapta și accesăm butonul ”Properties”. După ce o nouă
fereastră se deschide mergem la tab -ul ”Java Build Path” și selectăm ”Libraries” . În această
fereastă trebuie adăugate librăr iile dorite cu ajutorul butonului ”Add External JARs”, iar după
adăugarea continutului necesar, conținutul ferestrei trebuie să se populeze conform Fugura
2.1-3.

Figura 2.1-3 Adăugare librării Selenium WebD irver
Pentru o funcționare corespunzătoare a întregului ansamblu este necesar descărcarea și
menționarea locației executabilului GeckoDriver în corpul de lucru, precum exemplul
următor: System.setProperty(”webdriver.gecko.driver”,” <locația_ executabilului> ”);.
Gecko Driver este considerat a fi elementul de legătură dintre testele dezvoltate în
Selenium și browser -ul pe care urmează să se execute testele. Acest driver este un proxy
pentru utilizarea clienților compatibili W3C WebDriver pentru a putea interacționa cu
browser -ele bazate pe gecko, iar în cazul de față este vorba despre Mozila Firefox.
GeckoDriver este un fișier executabil care trebuie menționat într -una din căile sistemului
înainte de a începe testele. Browser -ul Firefox implementează pro tocolul WebDriver utilizând
executabilul geckodriver. Acest executabil pornește un server pe sistemul de operare. Toate
testele sunt comunicate serverului pentru a putea fi rulate. Testele sunt transformate din
apeluri în protocolul de automatizare al mari onetelor, acționând ca un proxy între cele capete:
capătul local și capătul de la distanță. Acest proces fiind similat atât pentru Internet Explorer,
cât și pentru Chrome.

37
În Figura 2.1 -4 sunt exemplificate apelurile care trebuie realizate cu scopul de a se putea
executa corect scriptul de testare automată.

Figura 2.1-4 Apelurile ce trebuie realizate pentru executarea corectă a testelor , sursa:
https://www.journaldev.com
În situațai în care scriptul de te stare este executat fără a se menționa calea fișierul
executabil, atunci excepția din Figura 2.1 -5 v-a fi returnată.

Figura 2.1-5 Excepție returnată în situația în care calea executabilului geckodriver nu este menționată
• Pasul 4: Instalarea framework -ului TestNG
Pentru realizarea acestui pas este necesar să se acceseze Eclipse Marketplace , ilustrat în
Figura 2.1 -6, de unde se poate descă rca acest framework . TestNG este un cadru de testare
pentru limbajul de programare java creat de Cedric Beust, iar scopul acestuia este de a acoperi
o gamă largă de categorii de teste, precum: teste funcționale, teste end -to-end, teste de
integrare, e tc. Acest lucru fiind realizat cu funcții puternice și ușor de utilizat. (Cedric & Hani,
2007)

38

Figura 2.1-6 Fereastra Marketplace din Eclipse
După finalizarea celor patru pași enumerați și explicați mai sus se poate începe
dezvoltarea scripturilor de testare automată pentru produsul testat.

2.2. Prezentarea produsului ce urmează a fi testat
Pentru a putea automatiza procesul de testare, am ales drept software ce urmează să fie
testat, o platformă web din domeniul telecomunicațiilor. Întrucât această platformă conține
atât procese complexe, precum realizarea de plăți către furnizorul de servicii, în speță UPC
România, cât și procese simple, precum verificarea apariției unui mesaj după generarea unei
acțiuni prin intermediul portalului.
Pentru a organiza cât mai bine acest proces de testare, am înpărțit testarea în 4 faze. Prima
fază fiind etapa de logare, în care utilizatorul se poate loga cu un cont unic, cea de -a doua fază
fiind verificarea elementelor GUI36. În cea de -a treia fază se vor verifica mesajele apărute în
diferite situații, iar în ultima etapă, se vor realiza plăți online pentru a ne asigura că această
funcționalitate poate fi validată.
În partea de logare pot fi întâl nite mai multe situații, iar aceste situații au fost descrise în
Figura 2.2 -1.

36 Guide User Interface – interfața cu utiliza torul.

39

Figura 2.2-1 Diagrama de logare, sursă proprie
În faza de validare a elementelor din interfața cu utilizatorul, scriptul dezvoltat trebuie să
valideze prezența tuturor meniurilor, cât și funcționalitatea acestora. Design -ul meniului
principal este ilustrat în Figura 2.2 -2, iar componența completă a men iului este prezentată în
Figura 2.2 -3.

40
Figura 2.2-2 Design -ul meniului principal, sursă: http://my.upc.ro

Figura 2.2-3 Structută meniu și sub -meniu, sursă proprie
În etapa de realizare plați, pentru a se întelege mai bine flux -ul procesului de testare a fost
realizată o dragramă care descrie situațiile întălnite cel mai des în randul utilizatorilor, iar
acestea vor fi tes tate cu ajutorul scriptului de automatizare. Această diagramă este schițată în
Figura 2.2 -4.

41

Figura 2.2-4 Diagrama de realiziare plăți, sursă proprie

2.3. Managmentul procesului de testare
2.3.1. HP ALM

Application Lifecycle Management (ALM) este un set de instrumente software de
dezvoltare care ajută la managmentul întregulu proces. Acest software este comercializat de
compania Micro Focus cu scopul de a fi utilizat în dezvoltarea și testarea aplicațiil or. În
Figura 2.3 -1 sunt prezentate instrumentele care pot fi folosite la procesul de dezvoltare și
testare.

Figura 2.3-1 Instrumentele software -ului HP Application Lifecycle Management (ALM), sursa: docume ntație
internă UPC România

42
În partea de Release Specifications se pot realiza planuri de management și se poate
urmări eficiența ciclurilor aflate în progres. În partea de Requirement Specifications se
definesc cerințele venite din partea clientului, dar totodată și cele venite din partea ehip ei de
testare. Tot aici pot fi urmărite: cerințele, testele și defectele pe diferite cicluri. Totodată HP
ALM poate furniza în timp real o imagine de ansamblu a acoperirii scenariilor și a defectelor
asociate testelor . În partea de Test Planning pot fi realizare planuri de testare, dar se poate
realiza și design -ul testelor. În Test Execution se pot crea subseturi de teste și se realizeaza
testarea efectivă. Software -ul suportă următoarele tipuri de teste: teste de ve rificare, teste de
funcționalitate, teste de regresie și teste avansate. În partea de Defect Tracking se realizează
urmărirea defectelor deschide de către echipa de testare. Aici se pot analiza defectele și
tendința lor, astfel se poate lua decizia de impl ementare sau de amânare a proiectului. În
partea de Analysis se realizeaza monitorizarea și controlul, putând să se genereze rapoarte și
grafice. (MicroFocus Corporate, 2018)
2.3.2. Cerințele clientului
Cerințele clientului, cunoscute și sub denumirea de cerințe a părților implicate
(StRS37) descriu caracteristicile unui sistem propus spre dezvoltare din punct de vedere al
utilizatorului final al sistemului. În consecință, cerințele pentru dezvoltarea software -ului sunt
discuta te în prealabil, înaintea începerii procesului de dezvoltare. (Wikipedia, 2019) În
procesul de testare aceste cerințe sunt necesare cu scopul de a putea valida funcționalitățile
implementate. În situația în care produsul implem entat nu corespunde cu cerințele elaborate
de client, atunci acea funcționalitate reprezintă un defect. Urmând ca acest defect să fie trimit
către echipa de dezvoltare cu scopul de a dezvolta produsul sub forma dorită de client.
În procesul de testare est e necesar ca echipei de testare să i se furnizeze documentul de
cerințe din partea clientului pentru a putea crea cazurile de testare și a realiza validarea
software -ului testat. În situația în care produsul dezvoltat nu corespunde cu cerințele
clientului , atunci pentru funcționalitățile depistate sunt deschide defecte către echipa de
dezvoltare cu scopul ca acestea să fie dezvolta te conform cerințelor.
Încă de la început, întreg procesul a fos t fragmentat în patru etape , enumerate mai jos,
iar cerințele c lientului sunt structurate sub aceiași formă. Mai jos sunt detaliate cerințele de
implementare, iar totodată acestea vor fi folosite pen tru scrierea cazurilor de testare .
• Logare;
• GUI;
• Verificare mesaj;
• Realizare plăți.

37 Stakeholder Requirements Specifications

43
Figura 2.3-2 Cerința numărul 1, sursă proprie

44

45

46

47

48

49

Cerințele pentru faza de GUI se regăsesc în Anexa 6.

2.3.3. Crearea cazurilor de testare și maparea lor

Pentru realizarea cazurilor de testare, a fost necesar să se creeze un format bine stabilit
cu toate informațiile necesare pentru a se putea începe executarea testelor. În acest format se
regăsesc următoarele detalii: versiunea cazului de testare, acesta p oate fi modificat în funcție
de modificare unor cerințe, data la care cazul de testare v -a fi executat, denumirea proiectului,

50
autotrul cazurilor de testare, cel care le -a dezvoltat, tipul în care se v -a executa testarea, cât și
statusul în care se află ca zul de testare. Primul status care se trece în documentul cazurilor de
testare este ”Nerulat”, urmând ca după rularea scipturilor de testare automată, statusul să fie
schimbat în ”Executat”.
În ceea ce priveste detaliile din partea secundară a testului, ac estea oferă informații
referitoare la : descrierea testului ce urmează să fie executat, etapa din care face parte cazul de
testare, pre -condițiile pe care testărul trebuie să se îndeplinească pentru a putea începe
executarea testului, pașii ce trebuie urma ți pentru a realiza validarea, dar și post -condițiile pe
care testărul trebuie să le indeplinească după executarea testului pentru a se putea realiza
validarea scenariului de test.
Una dintre cele mai importante informații trecute în fișierul de teste este reprezentată
de regula de business. Prin intermediul acesteia se realizeaza maparea cerințelor venite din
partea clientului cu scenariile de testare care au fost create pentru validarea software -ului aflat
în testare. Fiecare cerință trebuie să aibă cel p uțin un corespondent în cazurile de testare , spre
exemplu, scenariul de test T01 este mapat cu cerința BR01 . Există și situații în care mai multe
scenarii de test au un singur corespondent din partea cerințelor, spre exemplu: cazurile de
testate numerotate cu: T30,T31,T32,T33 sunt mapate cu cerința BR30.
În figurile de mai jos sunt prezentate cazurile de testare din etapa de ”Logare”, cât și
din etapa de ”Realizare plăți”. Scenariile de test pentru etapele de: ”GUI” și ”Verificare
mesaj” se regăsesc în Ane xa 5.

51

52

53

54

55

2.3.4. Metoda abordată
Pentru realizarea testării automate s -a optat pentru metoda Black Box, descrisă în
capitolul 1.6. . Folosind această metodă, testarea este realizată din perspectiva utilizatorului
final, întrucât testărul nu are acces la procesele pe care aplicația le realizează pentru a returna
rezultatul așteptat. Pentru a avea o continuitate s -a optat pentru menținerea ace lorași etape,
drept urmare, scripturile de dezvoltare au fost realizate în patru etape: log are, gui, realizare
plăți și verificare mesaj .
Scenariile de testare au fost construite pe principiul testelor de regresie . Aces tip de teste
sunt folosite pentru a valida că noul cod ce a fost dezvoltat, respectiv noile funcționalități ale
aplicației, nu au niciun impact asupra codului implementat inițial, respectiv asupra
funcționalităților deja existente. Testarea de regresie nu este nimic altceva decât o testare
totală sau parțială a testelor deja executate anterior, dar care sunt re -executate cu scopul de a
se asigura că funcționează conform cerințelor.
Cazurile de testare au fost selectate special pentru automatizarea testării de regresie,
iar condițiile după care au fost selectate testele sunt:
• Funcționalitățile de bază;
• Funcționalitățile utilizate frecvent de către utilizatori;
• Funcționalitățile cu risc ridicat de apariție a defectelor, acest lucru fiind bazat pe
istoricul defectelor anterioare;
• Funcționalități complexe care necesită o atenție sporită.

56
Pentru dezvoltarea scripturilor de testare automată s -au folosit : limbajul de programare
Java, mediul de dezvoltare Eclipse, adăugând framework -ul Selenium WebDriver pentru a se
finaliza dezvoltarea scipturilor și framework -ul de raportare pentru a centraliza rezultatelor
opținute.

2.4. Dezvoltarea scripturilor de testare automată

2.5. Execuția scripturilor de automatizare

2.6. Raportul de execuție după finalizarea testelor

2.7. Paralelism între testarea automată și testarea manuală

CAPITOLUL 3
Concluzie

BIBLIOGRAFIE

1. Basu, A. (2015). Software Quality Assurance, Testing and Metrics. PHI Learning.
2. Cedric, B., & Hani, S. (2007). Next Generation: Java testing TestNG and Advanced
Concepts. Addison -Wesley Professional.
3. Computer Weekly. (2002, Mai 2). Writ e one, run anywhere.
4. Dorothy, G., Erik, V. v., Isabel, E., & Rex, B. (fără an). Foundations of Software Testing –
ISTQB Certification. Thomson.

57
5. Ensminger, M. (2018, Decembrie 24). It's back! Selenium IDE Reborn with Dave Haeffner.
6. Evans, J. (2016, Februarie 7). Selenium Users – Selenium IDE seems dated and lacks
features.
7. Fagarasan, I. (2017). Testarea Software și asigurarea calității. Testarea Software și
asigurarea calității – curs 2 .
8. Free Software Foundation, Inc. (2012, Noiembrie 5). Vari ous Licenses and Comments
about them.
9. Jeff, T. (2005). Software Quality Engineering – Testing, Quality Assurance and Quantifiable
Improvement. Wiley -Interscience.
10. Kolawa, A., & Huizinga, D. (2007). Automated Defect Prevention: Best Practices in
Softw are Managment. Wiley -IEEE Computer Society Press.
11. Krill, P. (2011). Open source Selenium web app test suite to support Iphone and Android.
12. MicroFocus Corporate. (2018, August). HP ALM – Software Version:12.60. US.
13. Myers, G. J. (2004). The Art of Software Testin – Second Edition (Vol. Second Edition).
Hoboken, New Jersey: Word Association.
14. Myers, J. (1979). The Art of Software Testing, first editon.
15. Organizația Internațională pentru Standardizare. (2016). Catalog de standarde.
16. Patt on, R. (2005). Software Testing (2nd edition). Sams Publishing.
17. Priyadarshi, T., & Kshirasagar, N. (2008). Software Testing and Quality Assurance:
Theory and Practice. Willy.
18. Reid, S. (2013). The New Internetional Software Testing Standards. 9.
19. Selenium Project . (fără an). Preluat pe Mai 2019, de pe SeleniumHQ:
https://www.seleniumhq.org/
20. Testarea produselor informatice, asigurarea calității . (2017). Preluat de pe Shiva:
https://shiva.pub.ro/
21. Testing Strategy. (2015, Octombrie). UAT Test ing Strategy . București.
22. What is documentation testing? (2011). QATestLab .
23. White, O. (2014, Octombrie 14). IDEs vs. Build Tools: How Eclipse, IntelliJ IDEA &
NetBeans users work with Maven, Ant, SBT & Gradle.
24. Wikipedia . (2019, Iunie 10). Preluat de pe Business Requirements:
https://en.wikipedia.org/wiki/Business_requirements

58
ANEXE

Anexa 1: Glosar de termeni

Anexa 2: Lista tabelelor din lucrare

Anexa 3: Lista figurilor din lucrare

Anexa 4: Cod sursă

59
Anexa 5: Cazuri de testare

60

61

62

63

64

65

66

67

68

69
Anexa 6: Cerințe

70

71

72

73

74

https://www.tutorialspoint.com/software_testing/software_testing_iso_standards.htm

https://www.w3schools.in/software -testing/documentation/