FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT IOAN [607527]
FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN
SLAVICI” TIMIȘOARA
UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA
FACULTATEA DE INGINERIE
DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT – ZI
PROIECT DE DIPLOMĂ
COORDONATOR ȘTIINȚIFIC
Prof. Univ. Dr. Ing. Ec. Titus Slavici
ABSOLVENT: [anonimizat]
2019
FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN
SLAVICI” TIMIȘOARA
UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA
FACULTATEA DE INGINERIE
DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT – ZI
TESTAREA APLICAȚIILOR
SOFTWARE
COORDONA TOR ȘTIINȚIFIC
Prof. Univ. Dr. Ing. Ec. Titus Slavici
ABSOLVENT: [anonimizat]
2019
Cuprins
Introducere ………………………….. ………………………….. ………………………….. ………………………….. ……. 1
Capitolul 1. Principii Fundamentale ………………………….. ………………………….. ………………………….. … 2
1.1 Erori in software ………………………….. ………………………….. ………………………….. …………………. 2
1.2. Cauzele erorilor ………………………….. ………………………….. ………………………….. …………………. 3
1.3. Ce este si ce face testarea ………………………….. ………………………….. ………………………….. ……. 6
1.4. Principiile testării ………………………….. ………………………….. ………………………….. ……………….. 8
1.5. Procesul fundamental de testare: ………………………….. ………………………….. ……………………. 10
1.6. Psihologia Testării ………………………….. ………………………….. ………………………….. …………….. 12
Capitolul 2. Testarea și maturitatea aplicațiilor ………………………….. ………………………….. ……………. 13
2.1. Modele de dezvoltare a aplicațiilor ………………………….. ………………………….. ………………….. 13
2.1.1. Modelul Waterfall ………………………….. ………………………….. ………………………….. ………. 14
2.1.2. Modelul V ………………………….. ………………………….. ………………………….. …………………. 15
2.1.3. Modelul iterativ ………………………….. ………………………….. ………………………….. …………. 17
2.2. Niveluri de testare ………………………….. ………………………….. ………………………….. ……………. 18
Capitolul 3 – Testarea Automatizată (White box) ………………………….. ………………………….. …………. 18
3.1. Alegerea unui program de testare automatizată ………………………….. ………………………….. … 20
3.2. Realizarea aplicației în Angular ………………………….. ………………………….. ………………………… 23
3.2.1. Automatizarea testelor ………………………….. ………………………….. ………………………….. .. 27
3.3.Teste unitare ………………………….. ………………………….. ………………………….. ……………………. 29
3.4. Teste de in tegrare ………………………….. ………………………….. ………………………….. …………….. 31
3.5. Teste de sistem End to End ………………………….. ………………………….. ………………………….. … 37
3.5.1. Realizarea unui test End to End ………………………….. ………………………….. …………………. 39
3.6. Teste de acceptare ………………………….. ………………………….. ………………………….. ……………. 43
3.7. Testarea exploratorie ………………………….. ………………………….. ………………………….. ………… 44
Capito lul 4 – Black -box ………………………….. ………………………….. ………………………….. ………………… 45
4.1. Equivalence partitioning ………………………….. ………………………….. ………………………….. …. 45
4.2. Boundary value analysis ………………………….. ………………………….. ………………………….. …. 47
4.3. Decision table testing ………………………….. ………………………….. ………………………….. …….. 48
4.4. State transition testing ………………………….. ………………………….. ………………………….. …… 49
4.5. Use case testing ………………………….. ………………………….. ………………………….. ……………. 50
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………. 51
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. …… 52
Anexe ………………………….. ………………………….. ………………………….. ………………………….. ………….. 53
UNIVERSITATEA DIN ORADEA
FACU LTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
TEMA Testarea Aplicaț iilor Software
Proiectul de Finalizare a studiilor a studentului Costea (Nițu) Claudia
1). Tema proiectului de finalizare a studiilor : Testarea Aplicațiilor Software
2). Termenul pentru predarea proiectului de diplomă ____ _________________________
3). Elemente inițiale pentru elaborarea proiectului de finalizare a studiilor
________________________________________________________________________ ___
___________________________________________________________________________
4). Conținutul proiectului de finalizare a studiilor :_________________________ _______
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
5). Material grafic:________ _____________________ _____________________________
___________________________________________________________________________
___________________________________________________________________________
6). Locul de do cumentare pentru elaborarea proiectului de diplomă :
___________________________________________________________________________
___________________________________________________________________________
7). Data emiterii temei_____________________________ ___________________________
Coordonatori științifici
(titlul științific și numele) ,
UNIVERSITATEA DIN OR ADEA
FACULTATEA DE INGINERIE ELECTRICĂ
ȘI TEHNOLOGIA INFORMAȚIEI
Adresa Oradea, Cod 410087, Bihor, Romania, Strada Universit ății, nr. 1 ,
Tel/Fax :+40 259/408412, Tel:+40 259/408104; +40 259/408204
REFERAT
PRIVIND PROIECTUL DE DIPLOMĂ
A
ABSOLVENTULUI / ABSOLVENTEI : ……………………………………….
DOMENIUL Calculatoare și tehnologia informației
SPECIALIZAREA Tehnologia informației
PROMOȚIA 2019
1. Titlul proiectului ………………………………………………………………… ..
…..………………………………………………………………………………………… …….. .
2. Structura proiectului ………………………………………………………. ……….
…………………………………………………………………………………………… ………………………………………
………………………………………………………………………………………………………………….. ……………….
…………………………………………………………………………………………… ………………………………………
…………………………………………………………………………………………… ………………………………………
………………………………………………………….. ……………………………………………………………………….
…………………………………………………………………………………………… ………………………………………
…………………… …………………………………………………………………………………………………………….. .
…………………………………………………………………………………………… ……………………. ………………..
……………………………………………………………………………………………… ……
……………………………………………… …… ………………………………………………………
3. Apreci eri asupra conținutului proiectului de DIPLOMĂ (finalizare a
studiilor ), mod de abordare, complexitate, actua litate, deficiențe
…………………………………………………………………………………………… ………………………………………
…………………………………………………………………………… ………………………………………………………
…………………………………………………………………………………………… ……………… ………………………
…….. …………………………….. ……………………………………………………………………………………………. .
…………………………………………………………………………………………… …………………………………….. .
…………………………………………………………………………………………… ………………………………………
…………………………………………………………………………………………… ………………………………………
…………………………………………………………………………………………… ………………………………………
……………………………………………………. ……………………………………………………………………………..
4. Aprecieri asupra proiectului (se va menționa: numărul titlurilor bibliografice
consultate, frecvența notelor de subsol, calitatea și diversitatea surselor
consultate; modul în care absolventul a prelucrat informațiile din surse
teoretice)
…………………………………………………………………………………………… ………………………………………
…………………………… ………………………………………………………………………………………………………
…………………………………………………………………………………………… ……………………………. ………..
…………………………………………………………………………………………… ………………………………………
………………………………………………………………………………….. ……………………………………………….
…………………………………………………………………………………………… ………………………………………
…………………………………………… ………………………………………………………………………………………
…………………………………………………………………………………………… ………………………………………
(se va menționa: opțional locul de documentare și modul în care absolventul a realizat
cercetarea menționându -se contribuția autorului)
………. …………………………………………………………………………………………………….. ……………………
…………………………………………………………………………………………… ………………………………………
………………………………………………………………………. …………………………………………………………..
…………………………………………………………………………………………… …………………………… …………
5. Concluzii (coordonatorul proiectului trebui e să aprecieze valoarea
proiectului întocmit , relevanța studiului întreprins, competențele
absolventului, rigurozitatea pe parcursul elaborării proiectului , consecvența
și seriozitatea de care a dat dovadă absolventul pe parcurs)
……………….. …………………………………………………………………………………………………………….. …..
…………………………………………………………………………………………… ………………… ……………………
…………………………………………………………………………………………… ………………………………………
………………………… ……………………………………………. …………………………………………………………..
…………………………………………………………………………………………… ………………………………………
………………………………. …………………………………………………………………………………………………..
……………….. …………………………………………………………………………………………………………… …….
6. Redactarea proiectului respectă …………………………………………………. cerințele
academice de redactare (părți, capitole, subcapitole, note de subsol și
bibliografie).
7. Consider că proiectul îndeplinește/ nu îndeplinește condiții le pentru susținere
în sesiunea de Examen de LICENȚĂ (finalizare a studiilor ) din IULIE 2019 și
propun acordarea notei ………………
Oradea,
Data Coordonator științific
1
Introducere
Testarea software nu este altceva decât o artă de investigare a software -ului pentru a se
asigura că calitatea sa de testare este în conformitate cu cerința clientului. Testarea software
este efectuată într -o manieră sistematică, cu intenția de a găsi defecte într -un sistem. Este
necesar p entru evaluarea sistemului. Pe măsură ce tehnologia avansează, vedem că totul se
digitizează. Putem accesa banca noastra online, putem cumpăra din confortul casei noastre,
iar opțiunile sunt nelimitate. Un mic defect poate provoca o mulțime de pierderi fin anciare.
Din acest motiv, testarea software se dezvoltă acum ca un domeniu foarte puternic în IT.
Deși, ca și alte produse, software -ul nu suferă niciodată nici un fel de uzură sau coroziune,
dar da, erorile de proiectare vă pot face cu siguranță dificilă viața dacă nu sunt detectate.
Testarea periodică asigură că software -ul este dezvoltat conform cerințelor clientului. Cu
toate acestea, în cazul în care software -ul este livrat cu bug -uri încorporate în el, nu știți
niciodată când acestea pot crea o proble mă și apoi va fi foarte greu pentru a rectifica defect,
deoarece scanarea sute și mii de linii de cod și de stabilire a un ui bug nu este o sarcină ușoară .
Niciodată nu știți că, în timp ce remediați o eroare, ați putea introduce un alt bug în mod
neștiut î n sistem.
Testarea este procesul de evaluare a unui sistem sau a componentelor acestuia cu intenția de a
constata dacă acesta îndeplinește sau nu cerințele specificate. Cu alte cuvinte, testarea este
executarea unui sistem pentru a identifica eventualele l acune, erori sau cerințe lipsă, contrar
cerințelor actuale.
Persoanele care testeaza un software depind de proces și de părțile interesate asociate ale
proiectului (proiectelor). În industria IT, companiile mari au o echipă cu responsabilități de a
evalua software -ul dezvoltat în contextul cerințelor date. Mai mult, dezvoltatorii efectuează,
de asemenea, teste care se numesc teste unitare. În majoritatea cazurilor, următorii
profesioniști sunt implicați în testarea unui sistem în cadrul capacităților lor –
Software Tester
Dezvoltator de software
Proiect de conducere / Manager
Utilizator final
Diferitele companii au desemnări diferite pentru persoanele care testează software -ul pe baza
experienței și cunoștințelor lor, cum ar fi Software Tester, Software Quality Assurance
2
Engineer , Analist QA etc.
Testarea software -ului este acum o parte foarte importantă și integrată în dezvoltarea de
software. În mod ideal, este mai bine să introducem testarea software -ului în fiecare fază a
ciclului de viață al dezvoltării software -ului. De fapt, majoritatea timpului de dezvoltare a
software -ului este acum cheltuit pentru testare.
Capitolul 1. Principii Fundamentale
1.1 Erori in software
1. In ianuarie 2016, termostatul ‘Nest’ de la Google a avut o problema de soft ware, din
cauza că reia nu mai putea controla temperatura.1 Problema a apărut după un software
update care a dus la consumarea foarte rapidă a bateriei. Utilizatorii aces tui termostat
au ramas fara incălzire și apă caldă . Toate acestea s -au intamplat in cea mai friguroasă
saptamană a anului.
2. Website -ul pentru imigrare in Canada nu a fost accesibil in 8 noiembrie, data la care
au fost anuntate rezultatele alegerilor prezidenț iale din SUA (dintre Hillary Clinton si
Donald Trump).2 Timp de cateva luni inainte, cetățeni ai SUA au afirmat în glumă
cum că, in funcț ie de rezultatul alegerilor, este posibil sa emigreze in Canada.
Ministerul nu a oferit nicio explicaț ie pentru inacesibilitatea site -ului, deș i problema s –
a accentuat rapid pe site -urile de socializare.
3. Perioada de achiziț ionare a biletelor pentru Jocurile Olimpice de la Londra (2012) a
trebuit sa fie extinsă, dupa ce, datorită cererii ridicate, au fost probleme cu site -ul
oficial de ticketing. Pe langă faptul că site-ul de ticketing nu a fost accesibil ,
aproximativ 700 de clienți au plă tit biletele de 2 ori. Doi ani mai tarziu, la Glasgow
2014 Commonwealth Games, s -au inregistrat probleme similare.
4. In 2014, Toyota a rechemat in service 1.9 milioane de au tomobile Prius (mai mult de
jumătate din unitaț ile vândute de la lansarea modelului) pentru a repara o eroare de
1 Nick Bilton , Nest Thermostat Glitch Leaves Users in the Cold ,
https://www.nytimes.com/2016/01/14/fashion/nest -thermostat -glitch -battery -dies-software -freeze.html
2 Canada's immigration website crashes during US vote , https://www.bbc.com/news/technology -37921376
3
software care putea deter mina incetinirea sau oprirea maș inii. 3
De remarcat este faptul ca, in toa te aceste cazuri, functionalitaț i vitale, evidente au fost omi se
la testare. Este vorba de niște aplicaț ii costisi toare care au intrat in folosinț a inainte de a fi
“gata de livrare”, inainte de a se ști cu siguranta că toate functionalitățile vitale respectă
cerinț ele de functionare. Aceste aplicaț ii nu au fost testate in mod adecvat, iar astfel de erori
se gă sesc zilnic in multe alte aplica ții.
1.2. Cauzele erorilor
Pentru a ințelege ce se intamplă de fapt î n timpul procesu lui de dezvoltare a unei aplicații,
trebuie sa î ncep em cu oamenii care sunt implicați î n acest proces.
Oamenii nu sunt infailibili, însa nu reprezinta singura cauză ce trebuie luată î n calcul:
▪ Complexitatea sistemului
▪ Termenele limită / de liv rare care pun presiune pe echipă
▪ Schimbarea technologiei
▪ Erori în specificaț ii
Defectele pot apărea î n urma oricareia dintre cauze le de mai sus. Dacă un do cument cu o
eroare in specificaț ii este folosit pentru a descrie comportamentul unei c omponente,
componenta respectivă va conține cel mai probabil aceeași greseală / eroare de funcționare.
Dacă acea componentă este ulterior folosit ă intr-un sistem, es te posibil ca intreg sistemul să
aibă aceeași eroare sau chiar să nu poată functiona.
Diferenta d intre Eroare – Defect – Disfuncț ionalitate:
Def: O eroare (sau greșeală ) duce la un def ect, care poate cauza o disfuncț ionalitate.4
Figura 1.1: Disfuncț ionalitatea
Dacă dorim să evitam disfuncționalitățile, trebuie fie să evită m erorile si defectele, fie sa le
3 Chang -Ran Kim; Editing by Dominic Lau , Toyota to recal l 1.9 million Prius cars for software defect in hybrid
system , https://www.reuters.com/article/us -toyota -recall -idUSBREA1B1B920140212
4 Citat tradus “An error (or mistake) leads to a defect, which can cause an observed failure” din Brian Hambling
(editor) (2010) SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 10)
4
rectific ăm. Testarea poate contribui la ambele. Dacă dorim să influentă m erorile prin testare,
aceasta trebuie începută in acelaș i moment în care începem sa facem și greșeli – adică la
începutul procesu lui de dezvoltare a unei aplicații. Testarea trebuie să continue pană cand
suntem siguri că nu mai sunt disfuncționalități serioase în aplicație, adică pană câ nd procesul
de dezvoltare a aplicaț iei este complet.
Inainte să trecem mai departe, trebuie să înțelegem importanța unui software care
funcț ioneaza adecvat. Pentru aceasta, este de ajuns să ne gandim la pierderile pe care le po ate
cauza un software care funcționează neadecvat si efectele acestora:
▪ Pierderi financiare
▪ Pierdere de timp
▪ Pierderea afacerii si a reputaț iei
▪ Pierderi umane (cum era in cazul automobilelor Toyota)
Cu toate că defecte majore pot aparea datoritată testă rii insuficiente sau neadecvate,
urmatoarele a specte tre buie î ntelese:
1. Testarea exhaustiva este imposibila (cazul Google Nest):
▪ Defecț iunea ar fi fost descoperita daca s -ar fi ef ectuat toate testele posibile.
Însă dacă s -ar fi efectuat toate testele posibile, aceste teste n u ar fi fost
incheiate nici pană î n ziua de azi.
▪ Practic vorbind, este imposibilă testarea exhaustivă până și în cazul aplicaț iilor
de dimensiune / complexitate redusa.
2. Legă tura dintre testare si riscuri
▪ Riscul este un lucru pe rmanent in cazul tuturor aplicațiilor dezvoltate. Exis tă
riscul ca aplicația să nu indeplinească toate funcțiile necesare sau să nu fie
gata la timp. Relevanța acestor incertitudini creș te odata cu co mplexitatea
sistemului / aplicației și cu implicațiile unei disfuncționalitați. In mod intuitiv,
ne aș teptăm ca un software p entru managementul zborurilor să fie mai bine
testat decâ t un joc video, deoarece riscurile în cazul unei erori î n primul caz
sunt mai mari. Este o pro babilitate mai mare ca o aplicație complexa să
conțină defecte ș i, de asemenea, ca efectel e acestor defecte să aibe implicaț ii
mai mari.
▪ Ce și câ t testam trebuie sa fie direct legat de riscurile asociate cu aplicația
dezvoltată .
5
3. Legă tura dintre testare și calitatea aplicaț iei:
▪ Un punct de plecare în definirea calitații unei aplicații î l reprez inta cerin țele:
îndeplinește aplicația toate funcț iile cerute?
▪ Un alt criteriu de calitate este comporta mentul non -functional (cum
reacționează aplicația daca este accesată de un numar foarte mare de
utilizatori?)
▪ Un alt aspect ce trebuie luat î n calcul es te necesit atea alocă rii simul tane a mai
multor resurse; cu cât o funcționalitate trebuie livrată mai repede, cu atâ t
costurile vor fi mai ridicate.
▪ Rolul testarii este să se asigure că cerintele funcționale si non -funcționale sunt
testate înainte ca aplic ația să intre în producție. Testarea nu poate nici să
înlăture în mod direct defectele, nici să îmbunătățească calitatea. Prin
descoperirea si inregis trarea defectelor se facilitează corectarea lor si, deci,
îmbunătățirea calitaț ii.
4. Cum știm că am testat destul?
▪ Cel mai important aspect in obț inerea unui rezul tat acceptabil in urma unui
numă r fini t de teste este prioritizarea. Întotdeauna î ncepem testarea cu cele
mai importante teste, care validează atât aspectele funcționale, cât si cele non –
funcționale ale aplica ției (acestea sunt aspectele cu cele mai mari riscuri).
▪ Un alt aspect care ne ajută să ne dăm seama când putem opri testarea îl
reprezintă criteriile de finalizare / calitate a aplicaț iei. Aceste c riterii seteaza
standardul testă rii prin definirea aspectelo r precum: ce procent din aplicaț ie
trebuie testat, ce fel de defecte sunt acceptabile intr -un produs livrabil.
Un studiu efectuat în anul 2002 de către NIST a arătat că pierderile anuale pentru economia
S.U.A. cauzate de defecte de software se estimează la 59.5 miliarde de dolari. Mai mult de o
treime din aceste pierderi ar putea fi evitate dacă s -ar face investiții mai serioase în
implementarea procesului de testare .5
5 Gregory Tassey, Ph.D., The Economic Impacts of Inadequate Infrastructure for Software Testing ,
https://www.nist.gov/sites/default/files/documents/director/planning/report0 2-3.pdf
6
1.3. Ce este si ce face testarea
Până aici, am vorbit despre te stare l a modul intuitiv. Am stabilit că este o activitate menită să
reducă riscurile și să îmbunătățească calitatea aplicațiilor, prin găsirea defectelor. Însă pentru
a putea realiza o t estare eficienta, este nevoie să o î ntelegem mai in detaliu.
▪ Testare a și debugging -ul:
▪ Debugging este procesul p e care programatorii î l parcurg pe ntru a identifica
cauza disfuncționalităților ș i a corecta / elimina erorile.
▪ Testarea , pe de alta par te, este o explorare sistematică a unei aplicaț ii, cu
scopul de a identifica erorile / defecț iunile. Testarea nu implica corectarea
problemelor identificate; acestea sunt trimise programatorilor pentru a fi
corectate.
Figura 1.2: Testare si Debugging
▪ Testarea statică si testarea dinamică :
▪ Testarea statică este acel tip de tes tare care nu executa codul, majoritatea
eroril or introduse în cod având la bază cerinț e ambigue sau incomplete. Prin
analiza documentelor de specificaț ii, verificarea logicii descrise și clarificarea
situațiilor ambigue, se evită sau cel puț in se reduce pr ogramarea eronata.
▪ Testarea dinamică este testarea care executa codul. Pentru aceasta, un tester
trebuie sa creeze date de test, sa pregateasca scenarii de test, du pa care
testeaza efectiv aplicaț ia.
7
Figura 1.3: Testarea static ă si Testarea dinamică
▪ Testarea ca proces:
▪ Deși cea mai vizibila parte a rolului de tester este rularea efectivă a testelor,
testarea implică mult mai mult decât atât. Înainte ca testarea efectivă să
înceapă, trebuie definit scopul testării și specificat modul în care plănuim să
atingem acest scop.
▪ Tehnici de testare:
▪ O ultima provocare pentru un t ester este asigurarea unei testă ri eficiente. Un
test bun este acela care identifică o disfuncț ionalit ate, acolo unde este ea
prezentă. Un test sau o suită de teste care nu identifică problemele de
funcț ionalitate, nu aduc valoare produsului final.
▪ O condiție de testare este un element sau eveniment al unei
componente sau al unui sistem care ar putea fi verificat de unul sau mai multe
cazuri de testare, de ex. o funcție, o tranzacție, o caracteristică, un atribut de
calitate sau un element structural .6
Majoritatea oamenilor devin confuzi atunci când vine vorba de identificarea diferențelor
dintre Quality Assuran ce, Quality Control, și testarea. Deși ele sunt interdependente și într -o
anumită măsură, ele pot fi considerate aceleași activități, dar există puncte distinctive care le
separă.
Quality Assuran ce include activități care asigură implementarea proceselor, procedurilor și
standardelor în contextul verificării software -ului dezvoltat și a cerințelor prevăzute. Se
concentrează mai degrabă pe procese și proceduri decât pe testarea reală a sistemului.
6 Brian Hambling (editor), Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 77)
8
Quality Co ntrol include activități care asigură verificarea unui software dezvoltat în ceea ce
privește cerințele documentate . Se concentrează pe testarea reală prin executarea software –
ului cu scopul de a identifica bug-urile / defectele prin implementarea procedur ilor și
proceselor. Quality Control poate fi considerat ca fiind subsetul Quality Assuran ce-ului.
Testarea include activități care asigură identificarea bug-urilor / erorilor / defectelor într -un
software. Se concentrează pe testarea reală. Testarea este s ubsetul Quality Control -ului.
1.4. Principiile testă rii
Testarea arată prezența disfuncționalităț ilor:
▪ Testarea unei aplicații poate arăta că există una sau mai multe disfuncționalităț i.
▪ Testarea, în schimb, nu poate arăta că într -o aplicaț ie nu mai sunt disfu ncționalităț i.
▪ În mod ideal, testele sunt specifice, pentru a descoperi cât mai multe dintre
disfuncționalităț ile existente.
Testarea exhaustivă este imposibilă :
▪ Testarea identifică disfuncționalităț i.
▪ Dacă mă rim numarul d e teste, nu inseamna ca putem găsi toate disfuncționalităț ile.
▪ Evaluarea riscurilor ș i prioritizare a testelor trebuie făcute pentru a ne asigura că cele
mai importante teste au fost efectuate primele.
Testarea timpurie:
▪ Testarea î ncepe odata cu definirea specificațiilor. Acestea conț in criteriile de
acceptare / validare a aplicaț iei. “Acceptance tests” s unt scrise conform cu
specificaț iile.
▪ Un a lt aspect al testarii timpurii î l reprezinta costurile aso ciate cu descoperirea unui
bug într -o aplicaț ie matura.
▪ Cu câ t un bug este descoperit mai tarziu în dezvoltarea unei aplicații, cu atâ t costurile
asociate cu repararea acestuia sunt mai mari.
Analiza cost -beneficiu este o metodă utilizată pentru evaluarea unei politici care cuantifică în
termeni monetari valoarea a tuturor consecințelor ac estei politici asupra tuturor membrilor
societății.7
7 Citat tradus “Cost -benefit analysis is a method used for evaluating a policy which quantifies in monetary terms
the value of all the consequences of this policy on all society members. “ Titus Slavici, Dumitru Mnerie, Liviu
Herman, Gheorghe Catalin Crisan , Using cost -benefit analysis in project assessment , (2011)
http://www.wseas.us/e -library/conferences/2011/Meloneras/SOMMEM/SOMMEM -30.pdf
9
Figura 1.4: Diagrama costurilor
Gruparea disfunctionalităț ilor:
▪ Răspândirea defectelor în aplicații nu este uniformă .
▪ Principiul Pareto spune că 80% dintre disfuncționalități se regasesc în 20% din
aplicaț ie.
▪ Testare a nu trebuie să fie concentrată exclusiv pe modulele cu cea mai mare pondere a
defectelor.
Paradoxul pesticidelor:
▪ Rularea acelorași teste în mod repetat nu va rezulta în descoperirea de noi
disfuncționalităț i.
▪ Alternarea tehnicilor de te stare duce la gă sirea diferitelor bug -uri.
▪ Testele trebuie updatate pentru a reflecta cele mai noi specificaț ii.
Testarea e dependentă de context:
▪ În funcție de tipul aplicaț iei, diferit e tipuri de teste trebuie desfăș urate.
▪ Pentru a înțelege diferenț a dintre testele conduse pentru fiecare tip de aplica ție în
parte, put em compara testarea unei aplicaț ii de internet banking cu o aplicaț ie de e –
learning.
10
Figura 1.5: Diferenț a dintre un defect pe platfome diferite
Absenț a erorilor:
▪ Aplicațiile despre care nu știm că au di sfuncționalităț i nu sunt in mod necesar
“livrabil e” (eg. se poate livra o aplicație dupa testarea statică ?)
▪ Trebuie să verific ăm întotdeauna că aplicația îndeplinește toate criteriile funcționale și
non-funcț ionale.
1.5. Procesul fundamental de testare:
O parte necesară a unui caz de test este o definiție a rezultatului așteptat.8
1. Planificare ș i control:
▪ Planificarea î nseamna stabilirea obiectivelor de testare, a funcționalităților
care urmează să fie testate și a modului î n care pot fi atinse obiectivele
stabilite.
▪ În pla nificare, trebuie stabilite urmă toarele detalii:
▪ Cum vor fi conduse anumite activitati
▪ Cine este responsabil pentru ele
▪ Care sunt criteriile de finalizare a testelor
▪ Partea de Control – reprezintă acț iunile pe car e le putem realiza în cazul î n
care rezultatele testelor nu sunt conforme cu rezultatele aș teptate.
2. Anali ză si design:
▪ Se ocupă de detalii le procesului de testare: condiț iile de testare si modalitate a
8 Glenford J. Myers, (2004) The Art of Software Testing, Second Edition , John Wiley & Sons, Inc., Hoboken,
New Jersey
11
de creare de teste eficiente în condițiile de testare, astfel încat să se acopere cât
mai multe cazuri / condiții, prin efectuarea a câtor mai puț ine teste.
▪ Odata ce condi țiile si scenariile de test sunt definite, trebuie create datele de
test.
▪ Implică recapitularea funcționalităț ilor planificate pentru testare în etapa
“Planificare și control” și anticiparea testă rii propriu -zise.
Ca puncte cheie ale analizei și designului, putem defini:
▪ Revizuirea specificaț iilor, a arhitecturii sistemului, a design -ului
▪ Analiza elementelor ce tr ebuie testate, comportam entul aș teptat, pentru
identificarea condițiilor ce trebuie incluse î n scenariile de test
▪ Scrierea efectivă a testelor (este recomandată și alocarea priorităț ilor)
▪ Definirea med iului de testare: cum trebuie să arate, dacă este nevoie de tool –
uri ajutatoare
▪ Definirea datelor de test necesare pentru a putea executa testele
▪ Legarea testelor de specifica ții și date de test
3. Implementare și execuție – implică urmatoarele acț iuni:
▪ Verificarea mediului de testare
▪ Gruparea testelor în proceduri de testare, astfel încât să se eficientizeze
procesul
▪ Ordonarea testelor în ordine logica, astfel î ncat rezultatul de la un test sa fie
folos it ca preconditie la testul urmă tor
▪ Crearea datelor de test
▪ Rulare a testelor / executarea efectivă
▪ Logarea rezultatelor – este rezult atul testelor același cu rezultatul aș teptat?
▪ Diferenț ele dintre rezultatele preconizate ș i rezultatele efec tive se noteaza atât
la nivelul testelor, cât și î ntr-un incident.
▪ Dacă î n tim pul procesului de implementare și execuție, este disponibilă o noua
versiune de cod, trebuie conduse 2 tipuri de teste:
▪ Retestarea funcționalităț ii reparate prin noua versiune de cod
▪ Verificarea faptului că alte funcționalităț i nu au fost afectate de noua
versiune de cod – test de regresie
4. Evalu area criteriilor de finaliza re și raportarea:
12
▪ Odata ce testele au fost finalizate, trebuie verificat ce procent din teste este
conform cu rezultatele aș teptate.
▪ Se stabilește totodată dacă trebuie implementate teste adiționale sau dacă
criteriile de finalizare a testelor au fost core ct definite.
▪ Rezultatul ana lizelor de mai sus se trimite părț ilor implicate.
5. Finalizarea testarii
▪ În acest m oment, testarea efectivă a fost finalizată .
▪ Următoarea etapă este:
▪ Verificarea documentației pentru aplicație – este documentația exactă,
conține toate detaliile necesare?
▪ Închiderea ticketelor deschise și retestate î ntre timp
▪ Evaluarea punctelor forte ș i a celor slabe, care vor servi ca puncte de
invatare pentru proiectele ulterioare
1.6. Psihologia Testă rii
Testarea este procesul de executare a un ui program cu intenția de a găsi erori.
Deși acest lucru poate părea un joc de semantică subtilă, este cu adevărat o distincție
importantă. Înțelegerea adevărată definiție a testelor software poate face o diferență profundă
în succesul eforturilor dvs.9
Testarea poate fi mai eficientă dacă nu este efectuată de că tre persoana care a scris codul, din
simplul mo tiv că acea persoana are o relaț ie mai s pecială cu codul creat (așa cum un pictor
are o relație mai specială cu pictura creată de el ). Din pricina atas amentului față de codul
creat, este dificil pentru un programator să își identifice propriile greș eli. Pentru a beneficia
de o testare obiectivă , este recomandat ca o persoană care nu a lucrat efectiv la cod să îl
testeze. Cu câ t o persoana este mai detasa ta de programa torul care a scris codul, cu atât
testarea este mai obiectivă . Acest pr incipiu este denumit independența testă rii.
Avem urmatoarel e niveluri de independență a testă rii:
▪ Programatorul care a scris codul
▪ Membrii aceleiaș i echipe de programatori
9 Glenford J. Myers, (2004) The Art of Software Testing, Second Edition , John Wiley & Sons, Inc., Hoboken,
New Jersey
13
▪ Echipa de testare independentă – din aceeaș i companie
▪ Echipa de testare externă
Figura 1.6: Diagrama defectelor găsite în funcț ie de cine o te stează
Avantajele și dezavantajele testă rii independente:
Figura 1.7: Avantajele și dezavantajele testă rii independente
Capitolul 2. Testarea și maturitatea aplicaț iilor
2.1. Modele de dezvoltare a aplicaț iilor
Proce sul de dezvoltare a unei aplicaț ii imp lică:
– Colectarea cerinț elor
– Elaborarea specificaț iilor
– Scrierea codului
– Testarea produsului
14
Exista mai multe mod ele de dezvoltare a unei aplicaț ii:
– Waterfall
– V-model
– Iterativ / Incremental
2.1.1. Modelul Waterfall
Este un model tradițional și are urmă torii paș i:
Figura 2.8: Paș ii modelului Waterfall
Modelul Waterfall arată pașii în ordinea în care ei se desfășoară, de la colectarea cerințelor
inițiale pană la momentul în care se î ncheie testarea. 10
Acest tip de model este cunoscut sub numele de model liniar sau secvenț ial. Fiecare etapă
este finalizată înainte de î nceperea unei eta pe noi.
În Wate rfall, testarea are loc la finalul procesului de dezvoltare, odată ce codarea efectivă este
completă. Odată cu încheierea activitaț ii de testare, se ia o decizie cu p rivire la calitatea
produsului și implementarea sa în producț ie.
Principa lul deficit al acestui mo del de dezvoltare este faptul că testarea este condusă la finalul
procesului de dezvoltare, ceea ce face ca eventualele disfuncționalități să fie descoperite
foarte tarziu.
Pentru a atenua acest deficit, se poate i mplementa o verif icare a calității în fiecare etapă de
dezvoltare. Verificările sunt desfăș urate de persoana care a implemen tat / lucrat la etapa
10 Brian Hambling (editor), Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB Found ation Guide Second Edition
15
respectivă. Începerea etapei urmă toare poate fi f acută doar dupa ce verificarea a fost
finalizată .
În timpul dezvol tării unei aplicații, sunt vizate urmă toarele aspecte calitative:
– Verificarea: est e produsul conform cu specificaț iile?
– Validarea: se comportă produsul așa cum se așteaptă utilizatorul?
Sunt două tipuri de modele care facilitează validarea timpurie a calității aplicaț iei:
– Modelul Iterativ / Incremental
– V-model, care este o extensie a modelului Waterfall
2.1.2. Modelul V
V-Model , sau model secvenț ial:
Figura 2.9: Modelul secvenț ial
La fel ca în modelul Waterfall, partea stangă a diagramei se referă la elaborare a succesivă a
specificaț iilor:11
– Colectarea cerinț elor – Specificațiile iniț iale. D e cele mai multe ori, specificațiile
sunt înregistrate fie î ntr-un d ocument care este semnat de parț ile implicate, fie
direct î n tick ete. Modul de colectare a cerințelor iniț iale depinde de riscul
11 Brian Hambling (editor), Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 39)
16
aplicației și de nivelul de audit al schimbărilor și al funcționalităț ilor
implementate.
– Specificațiile funcț ionale – Funcționalităț ile necesare pentru a acoperi c erințele
utilizatorului. De exemplu: dacă în specificațiile inițiale se cere o aplicaț ie cu
modul de login, în specificațiile funcționale se detaliază funcț ionalitatea acestui
modul. Trebuie definite urmatoarele aspecte:
▪ Câmpurile care sunt disponibile pe pagina de login (user, parola, login
button, reset password button / link)
▪ Caracteristicile / limitările care trebuie asociate fiecă rui ca mp. Exemple:
user – ar trebui să fie unic; parola – numă rul de caractere, tipul acestora,
lungimea minima
▪ Funcț ionalitatea care este î n spatele butoanelor / a linkului de reset
password: se face resetarea prin trimiterea unui email cu link de resetare
sau se deschide un tab nou cu o intrebare de securitate, iar in u rma unui
raspuns corect, apar câ mpurile de New Password / Confirm Password.
– Specificaț iile tehnice – Designul tehnic al funcționalităților identificate în pasul
anterior. Aici se împarte aplicația în module / componente și se stabilește legătura
dintre acestea. Dacă pastrăm exemplul anterior, odată ce un cont a fos t creat ș i
utilizatorul s -a logat, utilizatorul ar trebui afișat în interfață. Ajuns în aplicaț ie,
utilizatorul se află în alt modul, astfel încât trebuie definită legatura dintre acestea.
– Specificaț ii de programare – Design -ul detaliat al fiecă rui modul sau al fie cărei
unități ce trebuie pro gramat(ă) pentru a îndeplini funcționalităț ile cerute.
Specificaț iile pot fi revizuite pentru a se verifica:
– Conformitatea cu pasul anterior
– Dacă sunt suficien te detalii pentru a elabora urmă torul pas
– Dacă sunt suficiente detal ii pentru a putea î ntelege / testa produsul
Partea centrală a modelului V ne arată că planificarea testelor trebuie începută odată cu
dezvoltarea fiecărui pas (work -product). Așa cum am stabilit în p rocesul fundamental de
testare, trebuie definite câ teva a cțiuni premergatoare testări i, și anume:
17
– Task -urile asociate fiecărei funcționalităț i
– Persoanele responsabile pentru fiecare task
– Timeline -uri
– Mediul de testare
– Datele de test
Partea dreaptă a modelului se concentrează pe testarea efectivă. Fiecărui pas î i este asociat un
anumit tip de teste:
– Teste de acceptare – Au la baza cerințele definite și sunt desfăsurate de că tre
client.
– Teste de sistem – Se focusează pe specificațiile funcț ionale. Acest e teste sunt
conduse de o echipă de testare, fie ea internă sau externă .
– Teste de integrare – Conduse după specificaț iile tehnice. Testarea este executată
de că tre programato rul care a scris codul sau de că tre un alt membru al echipei de
dezvoltare.
– Teste unitare – Se bazează pe specificațiile de programare ș i sunt executate de
programatorul car e a scris codul.
De retinut : Fiecare etapă trebuie finalizată inaintea începerii unei noi etape. Această
abordare favorizează validarea aplicației de că tre client / u tilizator .
2.1.3. Modelul iterativ
În acest model, nu este necesară definirea completă a specificațiilor pentru a î ncepe
programarea. În schimb, o versiune funcțională a aplicației este construită în etape succesive.
În fiecare etapă avem: colectarea de specificații, design, programare ș i testare.
Figura 2.10: Modelul iterativ
18
Ciclurile d e dezvoltare / testare a aplicaț iei sunt constant e ca lungime (de ex. o săptamână,
doua săptamâni). La sfarșitul fiecărui ciclu (iteraț ie), se ia o decizie cu privire la
funcționalitățile adiț ionale. Acest proces este repetat până când toate cerințele clientu lui sunt
îndeplinite. Principalul avantaj al acestui mo del este implicarea clientului î n proces ul de
validare / testare a fiecărei iterații. Prin implicarea clientul î n mod frecvent, riscurile de a
dezvolta o a plicație neconformă este redus semnificativ.
Cu toate acestea, această abordare a dezvoltării software poate pune probleme.12
Deficienț ele modelului sunt:
– Documentația este vaga, fapt care î ngreuneaza testarea.
– Schimbă rile minore nu sunt documentate deloc.
– Este necesară o testare elaborată, pentru a se asigura că funcționalităț ile noi
introduse nu au e fecte adverse (regresie pe funcționalităț i interconectate).
2.2. Niveluri de testare
Focusul testă rii este direct legat de stadiul de dezvoltare a aplicației. Aș a cum am precizat la
V-model, avem urmato arele niveluri de teste:
– Teste uni tare – Se bazează pe specificaț iile de programare.
– Teste de integrar e – Efectuate pe baza specificaț iilor tehnice.
– Teste de sistem – Se bazează pe specificațiile funcț ionale.
– Teste de acceptare – Au la bază cerințele definite / specificaț iile.
Testele sunt sc rise pentru a descoperi disfuncționalitățile ce pot apărea î n fiecare dintre
etapele respective. Aceste niv eluri de testare se pot aplica ș i modelului iterativ.
Capitolul 3 – Testarea Automatizată (White box)
Tehnicile de testare structurală sunt folosite pentru a explora sistemul / componentele la toate
12 Brian Hambling (editor), Peter Morgan, Angelina Sa maroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 40)
19
nivelurile.13 La nivelul componentei, structurile de interes sunt structurile progra mului,
precum deciziile / condițiile. La nivelul integrării, testarea se focuse ază pe interacț iunile
dintre componente. În cadrul testelor de sistem, este testată interacț iunea utilizatorului cu un
anumit meniu, de exemplu. Toate aceste exemple de structuri pot fi testate prin tehnici white –
box.
Tehnica de testare white b ox are scopu l de a se asigura că elementele individu ale ale
structurii functionează corect. Testarea structurală este folosită , cel mai frecvent, la nivelul
componentelor, un de testele sunt generate pe baza codului. Deș i aceste teste sunt, de cele mai
multe ori, autom ate sau executate de tool -uri, este foarte util pentru un tester (fie el si manual)
să înteleagă tehnica. Dacă aplica ția dezvoltată foloseș te metodologia Ag ile, este posibil ca un
tester ș i un p rogramator sa analizeze impreună structurile de cod.
Software -ul a devenit o parte esențială a lumii în care trăim. Acesta a depășit primul său scop
unic de a face mai eficiente întreprinderile. Companiile de astăzi încearcă să găsească
modalități de a deveni companii digitale de primă clasă. În calitate de utilizato ri, fiecare
dintre noi interacționează cu o cantitate din ce în ce mai mare de software în fiecare zi.
Dacă dorim să păstram ritmul, va trebui să căutam modalități de a livra software -ul mai
repede, fără a sacrifica calitatea acestuia. Livrarea continuă, o practică în care ne asiguram în
mod automat că software -ul poate fi lansat în producție în orice moment, vă poate ajuta cu
asta. Cu livrare continuă, utilizam o conductă de construire pentru a testa automat software -ul
și pentru a -l implementa în mediile de testare și de producție.
Crearea, testarea și implementarea manuală a unei cantități tot mai mari de sof tware devin în
curând imposibile – cu excepția cazului în care dorim să ne petrecem tot timpul cu o muncă
manuală, repetată , în loc să furnizam software de lucru. Automatizarea – de la construire , la
teste, implementare și infrastructură – este singura cale de urmat.
În mod tradițional, testarea software -ului a fost extrem de manuală, prin implementarea
aplicației într -un mediu de testare și apoi efec tuarea unor teste de tip black -box, de ex. făcând
clic pe interfața dvs. de utilizator pentru a vedea dacă ceva este rupt. Adesea, aceste teste ar fi
specificate de scripturile de testare pentru a se asigura că testerele ar face o verificare
consecventă.
Este evident că testarea tuturor modificărilor manual este consumatoare de timp, repetitivă și
plictisitoare. Repetitiv este plictisit or, iar plictisitor duce la greșeli.
13 Brian Hambling (editor), Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB F oundation Guide Second Edition (pagina 97)
20
Din fericire există un remediu pentru sarcini repetitive: automatizarea.
3.1. Alegerea unui program de testare automatizată
Pentru a facilita efectuarea și gestionarea procesului de testare, au fost dezvoltate și utilizate
numeroase tipuri de instrumente de testare pentru o gamă largă de sarcini de testare. Unele
dintre ele au fost dezvoltate in -house de departamentul de dezvoltare sau de testare al unei
organizatii. Altele au fost dezvoltate de case de software (cunoscute și ca furnizori de
instrumente de testare) pentru a le vinde organizațiilor care efectuează teste. Chiar și în cadrul
aceluiași tip de instrument, unele vor fi dezvoltate acasă, iar altele vor fi dezvoltate de
furnizori de instrumente de testare .
Instrumentul de testare este u n produs software care suport ă una sau mai multe activități de
testare, cum ar fi planific area și controlul, specificarea, construirea fișierelor și datelor
inițiale, executarea testelor și analiza testelor. Prin urmare, un instrument de testare poate fi
considerat ca o bucată de software care este folosit pentru a face procesul de testare mai rapid
sau mai eficient. Cu alte cuvinte, orice face testul mai ușor, mai rapid, mai precis, etc.
Principalul avantaj al utilizării instrumentelor de testare este similar cu beneficiul principal al
automatizării oricărui proces. Adică, cantitatea de timp și efort petrecute în îndeplinirea
sarcinilor de rutină, mundane și repetitive este mult redusă.
Acest timp salvat poate fi folosit pentru a reduce costurile de testare sau poate fi f olosit
pentru a permite testerilor să-și petreacă mai mult timp pe mai mul te sarcini intelectuale de
planificare a testelor , analiză și design. La rândul său, acest lucru poate face posibilă o testare
mai concentrată și mai adecvată – mai degrabă decât dacă mulți testeri lucrează ore
îndelungate, executând sute de teste.
În legă tură cu acest lucru este faptul că automatizarea oricărui proces are de obicei rezultate
mai previzibile și mai consecvente. În mod similar, utilizarea instrumentelor de testare oferă
rezultate mai previzibile și mai consecvente, deoarece eșecurile umane, cum ar fi erorile de
manevră, neînțelegerile, ipotezele incorecte, uitarea, etc., sunt eliminate. De asemenea,
înseamnă că orice rapoarte sau constatări tind să fie mai degrabă obiective, decât subiective.
De exemplu, oamenii presupun adesea că ceva care p are rezonabil este corect, când, de fapt,
poate nu este ceea ce ar trebui să facă sistemul.
Majoritatea riscurilor asociate cu utilizarea instrumentelor de testare se referă la așteptările
21
prea optimiste privind ceea ce poate face instrumentul și la o lips ă de apreciere a efortului
necesar pentru a pune în aplicare și pentru a obține beneficiile pe care le poate aduce
instrumentul.
De exemplu, luați în considerare mediile de producție ale majorității organizațiilor care iau în
considerare utilizarea instrum entelor de testare. Este puțin probabil ca acestea să fi fost
proiectate și construite cu instrumentele de testare în minte. Prin urmare, presupunând că
doriți ca un mediu de testare să fie o copie a producției (sau cel puțin cât mai aproape
posibil), veți avea și un mediu de testare care nu este conceput și construit cu instrumentele
de testare în minte.
După ce a fost implementat un instrument de testare și au fost obținute beneficii măsurabile,
este important să se depună eforturi suficiente pentru a menține instrumentul, procesele care
îl înconjoară și mediul de testare în care este folosit. În caz contrar, ex istă riscul ca beneficiile
obținute să scadă și instrumentul să devină redundant. În plus, oportunitățile de îmbunătățire
a modului în care este folosit instrumentul ar putea fi, de asemenea, ratate.
Protractor: framework -ul de automatizare a test elor pen tru aplicațiile Angular
În timp ce React nu pare să aibă un campion UI de testare, situația este diferită în domeniul
angular. Când vine vorba de testar ea automată a aplicațiilor web Angular , Protracto r se
bucură de statutul go-to solution . 14
Protractorul este un cadru de testare end -to-end pentru aplicațiile AngularJS și funcționează
ca un integrator de soluții care combină instrumente și tehnologii puternice, cum ar fi
NodeJS, Selenium WebDriver, Jasmine, Cucumber și Mocha. A fost inițial dez voltat de
dezvoltatorii Google pentru a sprijini aplicațiile Angular și ulterior este lansată ca un
framework open source. Acum Protractor suporta atât aplicaț ii Angular cât și non -Angular.
Protractor este scris pe partea superioară a Webdriver.js, toate caracte risticile care sunt
suportate în Selenium Webdriver sunt suportate de acesta, în plus față de caracteristicile
specific Angular .
Selenium este un set de instrumente software diferite, fiecare având o abordare diferită în
sprijinul automatizării testării.15 Cei mai mulți Ingineri QA din cadrul Selenium se
concentrează asupra uneia sau a două instrumente care îndeplinesc cel mai mult necesitățile
proiectului, cu toate acestea, învățarea tuturor instrumentelor vă va oferi numeroase opțiuni
14 Protractor Testing – https://www.guru99.com/protractor -testing.html
15 Selenium Documentation – https://www.seleniumhq.org/docs/01_introducing_selenium.jsp
22
diferite pentru abor darea diferitelor probleme de automatizare a testelor. Întreaga suită de
instrumente generează un set bogat de funcții de testare adaptate în mod special nevoilor de
testare a aplicațiilor web de toate tipurile. Aceste operațiuni sunt foarte flexibile, per mițând
multe opțiuni pentru localizarea elementelor UI și compararea rezultatelor așteptate ale
testelor cu comportamentul real al aplicațiilor. Una dintre caracteristicile cheie ale Selenium
este suportul pentru efectuarea testelor pe mai multe platforme de browser.
Cucumber este un instrument care sprijină dezvoltarea comportamentului (BDD). Acesta
oferă o modalitate de a scrie teste pe care oricine le poate înțelege, indiferent de cunoștințele
tehnice.
În BDD, utilizatorii (analiștii de afaceri, proprie tarii de produse) scriu mai întâi scenarii sau
teste de acceptare care descriu comportamentul sistemului din perspectiva clientului, pentru
examinare și semnare de către proprietarii de produse înainte ca dezvoltatorii să -și scrie
codurile.
Cucumber folose sc limbajul de programare Ruby.16
JUnit este un cadru de testare a unităților pentru limbajul de programare Java. Acesta joacă
un rol esențial în dezvoltarea bazată pe testare și este o familie de cadre de testare a unităților,
denumite colectiv xUnit.
JUnit promovează ideea de "testare și codificare", care pune accentul pe stabilirea datelor de
testare pentru o bucată de cod care poate fi testată mai întâi și apoi implementată.17 Această
abordare este asemănătoare cu "testați puțin, codificați puțin, testaț i puțin, codificați puțin".
Aceasta crește productivitatea programatorului și stabilitatea codului de program, ceea ce, la
rândul său, reduce stresul asupra programatorului și timpul petrecut pentru depanare.
Deoarece am realizat aplicația care urmeaza sa fie testata î n AngulaJS, testele autmatizate vor
fi realizate tot in Angular in limbajul Typescript.
TypeScript pornește de la aceeași sintaxă și semantică pe care le cunosc astăzi milioane de
dezvoltatori de JavaScript. Utilizați codul JavaScript existen t, încorporați bibliotecile
JavaScript populare și tastați codul TypeScript din JavaScript.
TypeScript compilează codul JavaScript simplu și curat, care rulează pe orice browser, în
Node.js sau în orice motor JavaScript care acceptă ECMAScript 3 (sau mai n ou).
16 Cucumber Testing Tool – https://www.guru99.com/introduction -to-cucumber.html
17 Junit – Quick Guide – https://www.tutorialspoint.com/junit/junit_quick_guide.htm
23
Tipurile permit programatorilor JavaScript să utilizeze instrumente și practici de dezvoltare
extrem de productive, cum ar fi verificarea statică și refacerea codurilor atunci când
elaborează aplicații JavaScript.
Tipurile sunt opționale, iar tipul de inferențe permite câteva adnotări de tip să facă o mare
diferență în verificarea statică a codului. Tipurile vă permit să definiți interfețele dintre
componentele software și să obțineți informații despre comportamentul bibliotecilor
JavaScript existente.
TypeScript oferă suport pentru cele mai recente și evolutive caracteristici JavaScript, inclusiv
cele din ECMAScript 2015 și propuneri viitoare, cum ar fi funcțiile asincron și decoratorii,
pentru a ajuta la construirea de componente robuste.18
Aceste cara cteristici sunt disponibile la dezvoltarea timpului pentru dezvoltarea aplicațiilor cu
înaltă încredere, dar sunt compilate în JavaScript simplu care vizează mediile ECMAScript 3
(sau mai noi).
3.2. Realizarea aplicaț iei în Angular
După instalarea programe lor Node.js si Visu al Studio Code, se va realiza câ te un folder
pentru fiecare component a aplicatiei . În acest caz primul component este Dashboard.
Se gaseste implementarea shell AppComponentului distribuit în trei fișiere:
app.component.ts – codul de clasă componentă, scris în TypeScript.
Figura 3.11: Componenta .ts a aplicaț iei
18 Typescript – https://www.typescriptlang.org/
24
app.component.html – șablonul de componentă, scris în HTML.
Figura 3.12: Componenta .html a aplicaț iei
app.component.css – stilurile CSS private ale componentei.
Figura 3.13: Componenta .css a aplica ției
Cel mai simplu mod de a genera fiș ierele necesare pentru un component este acel a de a face
25
click dreapta pe fișierul aplicaț iei Angular Generator Component
Generatorul generează fișiere de pornire pentru toate cele trei părți ale componentei:
dashboard.component.ts
dashboard.component.html
dashboard.component.css
Aplicația are ca pagină de pornire un dashboard care conț ine Topul unor elemente
Figura 3.14: Pagina de pornire
Se poate face click pe cele două linkuri de deasupra dashboard -ului ("Dashboard" și "Dogs")
pentru a naviga între aceaste vizualizari.
Dacă se face click pe cainele de bord "Geat Dane", routerul deschide o vizualizare "Dog
Details" unde se poate schimba numele cainelui.
26
Figura 3.15: Pagina de detaliu
Dacă se face click pe butonul "Back ", se revine la tablo ul de bord. Legăturile de sus duc la
oricare di n vederile principale. Dacă se da click pe "Dogs ", aplicația afișează vizualizarea
listei " Dogs ".
27
Figura 3.16: Pagina Dogs din aplicaț ie
Când se face click pe un tip de câ ine diferit, se deschide pagina de detaliu care reflectă noua
alegere.
3.2.1. Automatizarea testelor
Pentru automatizarea testelor există numeroase programe care ajută la realizarea acestor
teste.
Angular CLI preia și instalează tot ceea ce este nevoie pentru a testa o aplicație Angular cu
cadrul de testare Jasmine.
Proiectul creat cu CLI este imediat pregătit pentru testare , daca se ruleaza comada “ ng test ”:
28
Figura 3.17: Comanda de testare
Comanda de testare “ng test ” construiește aplicația în modul de vizionare ș i lansează alerta
de test Karma:
Figura 3.18: Rezultatul testului
Ultimul rând al jurnalului este cel mai important. Arată că Karma a făcut trei teste care au
trecut.
De asemene a, se deschide un browser -u chrome și afișează ieșirea de tes tare în "Jasmine
HTML Reporter":
29
Figura 3.19: Rezultatele testului î n browser
Majoritatea oameni lor găsesc această ieșire a browserului mai ușor de citi t decât jurnalul
consolei. Putem face clic k pe un rând de test pentru a relua doar acel test sau facem click pe o
descriere pentru a relua testele din grupul de testare selectat ("test suite").
Între timp, comanda ng test urmărește modificările.
Pentru a vede a acest lucru în acțiune, se face o mică schimbare in app.component.ts și se
salveaza . Testele rulează din nou, browserul se reîmprospătează și apar noi rezultate de
testare.
Denumirea fisierelor de test se face in interiorul folderului src / app. CLI a generat un fișier
de testare pe ntru AppComponent numit app.component.spec.ts.
Extensia fișierului de test trebuie să fie .spec.ts, astfel încât uneltele să o poată identifica ca
un fișier cu teste (AKA, un fișier spec).
Fișierele app.component.ts și app.component.spec.ts sunt frați în a celași folder. Numele de
fișiere rădăcină (app.component) sunt aceleași pentru ambele fișiere.
3.3.Teste unitare
În general, codul este scris în componente sau unități. Unităț ile sunt programate izolat, fiind
ulterior integrate.
Testarea pe module (sau testare a unitara ) este un proces de testare a subprogramelor
individuale, subrutine sau proceduri într -un program. Aceasta înseamnă că, mai degrabă decât
testarea inițială a programului în ansamblu, testarea se concentrează mai întâi pe construcțiile
mai m ici ale programului. Motivațiile pentru a face acest lucru sunt trei. În primul rând,
testarea modulelor este o modalitate de gestionare a elementelor combinate de testare,
deoarece atenția se concentrează inițial asupra unor unități mai mici ale programul ui. În al
doilea rând, testarea modulelor facilitează sarcina de depanare (procesul de identificare și
corectare a unei erori descoperite), deoarece, atunci când se găsește o eroare, se știe că există
într-un anumit modul. În cele din urmă, testarea module lor introduce paralelismul în procesul
de testare a programului, prezentându -ne posibilitatea de a testa simultan mai multe module.19
Testele unitare au scopul de a se asig ura că codul scris intr -un modul este conform cu
specificațiile, î nainte ca modulul r espectiv sa fie integrat. Cu ajuto rul testelor unitare se
19 Glenford J. Myers, (2004) The Art of Software Testing, Second Edition , John Wiley & Sons, Inc., Hoboken,
New Jersey (pagina 70)
30
verifică și dacă î ntregul cod scris pentru modulul respectiv este executat.
De obicei, acest tip de testare est e desfășurat de că tre programatorul care a scri s codul. Bug –
urile descoperite î n test area unitara sunt rezo lvate, de cele mai multe ori, fără a fi î nregistrate.
În testele unitare se verifica, de exmplu titlul paginii:
Figura 3.20: Teste unitare
Titlul p aginii este “Tour of Dogs”, dacă adăugăm accelaș i test, dar cu alt titlu, acesta nu ar fi
cu succes.
Figura 3.21: Test care va eș ua
Dacă lucram într -un limbaj funcțional , un test unitar va fi cel mai probabil o singură funcție.
Analizele unității vor apela o funcție cu parametri diferiți și vor asigura că returnează valorile
preconiz ate. Într -un limbaj orientat pe obiecte, o unitate poate varia de la o singură metodă la
o clasă întreagă.
Lucrul bun cu privire la testele unitare este că se pot scrie pentru toate clasele de cod de
producție, indiferent de funcționalitatea lor sau de str atul din structura lor internă de care
aparțin.
31
Se pot controla unitățile de testare la fel cum se pot arhiva unitățile de testare, clasele de
domenii sau cititoarele de fișiere. Pur și simplu se lipeste de o clasă de testare pentru fiecare
regulă de clasă de producție.
O clasă de test unitara ar trebui să testeze cel puțin interfața publică a clasei. Metodele private
nu pot fi testate oricum, deoarece pur și simplu nu se pot apela dintr -o altă clasă de t estare.
Protejate sau private -pachete sunt accesibile dintr -o clasă de testare (dat fiind structura
pachetului de c lasă de test este aceeași cu clasa de producție), dar testarea acestor metode ar
putea merge deja prea departe.
Există o linie fină atunci câ nd vine vorba de scrierea testelor unitare: Ele trebuie să se asigure
că toate căile de cod non -trivial sunt testate . În același timp, acestea nu ar trebui să fie legate
prea mult de implementare.
O structură bună pentru toate testele (acest lucru nu se li mitează la teste unitare) este acesta:
Se configureaza datele de testare
Se apeleaza metoda care este sub test
Asigurarea că rezultatele așteptate sunt returnate
Acest model poate fi aplicat și altor teste de nivel înalt. În fiecare caz, a cestea asigură că
testele rămân ușor și consecvent de citit. În plus, testele scrise cu această structură în minte
tind să fie mai scurte și mai expresive.
3.4. Teste de integrare
Odata ce modulele / unităț ile au fost programate individua l, ele trebuie să fie integrate, pentru
a crea un sistem.
Scopul testelor de integrar e este descoperirea bug -urilor în interacțiunile dintre componente
și, de asemenea, în interfață. Î nainte de a planifica testel e de integrare, trebuie definită
strategia de integrare a componentelor.
1. Integrarea Big -Bang:
– Toate modulele sunt integrate simultan.
– In cazul unei a stfel de integrari este dificilă izolarea erorilor, pentru ca nu se pun e
32
accent pe verificarea interfeț elor pentru module individuale.
– Introduce ris cul ca disfuncționalitățile să f ie descoperite ulterior, câ nd costurile de
remediere a bug -urile sunt mai ridicate.20
2. Integrarea Top -Down:
– Sistemul este construit în etape, începâ nd cu componentele care cheama alte
componente.
– Componentele care cheama alte componente sunt puse, de obicei , deasupra
componentelor chemate.
– Acest tip de integrare permite testerului să evalueze componentele de la nivel
“superior” (cele care cheama alte componente).
– Testarea s e face prin verificarea interacț iunilor fiecarei componente.
– Pentru a testa interacțiu nea dintre componente, se î nlocuiesc componentele
neimplementate cu “stub” -uri.
– Stub-urile au rolul de a simula comportamentul unui cod existent.
Exemplu:
Figura 3.22: Integrarea Top -Down
3. Integrarea Bottom -Up:
– Acest tip de integrare este opusul integră rii Top -Down.
20 Brian Hambling (editor), Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 43)
33
– Componentele care nu sunt înca integrate în momentul testă rii sunt componentele
care cheama alte componente.
– Componentele lipsa se î nlocuiesc cu alte componente, numite “drivers”.
– Denumirea de “drivers” este data acesto r componente deo arece ele cheamă î n mod
activ componentele deja integrate.
Exemplu:
Figura 3.23: Integrarea Bottom down
Toate aplicațiile non -triviale se vor integra cu alte părți (baze de date, sisteme de fișiere,
apeluri de rețea către alte aplicații). Când se testează unitățile de testare, acestea sunt, de
obicei, părțile pe care le lasam deoparte pentru a obține o izolare mai bună și teste mai rapide.
Cu toate acestea, aplicația va interacționa cu alte părți și ac est lucru trebuie să fie testat . Ele
testează integrarea aplicației cu toate părțile care sunt în afara aplicației.
Pentru testele automate, aceasta înseamnă că nu trebuie doar să rulați propria aplicație, ci și
componenta cu care integrați. Dacă se testeaza integrarea cu o bază de date, trebuie r ulata o
bază de date atunci când se executa testele. Pentru a testa că se poate citi fi șiere de pe un disc,
trebuie salvat un fișier pe disc și să încărcat în testul de integrare.
"Testele unitare" sunt un termen vag, acest lucru fiind și mai adevărat pent ru "testele de
integrare". Pentru unii utilizatori, testarea de integrare înseamnă testarea întregului set de
aplicații conectate la alte apl icații din cadrul sistemului . Împreună cu testarea contractului și
testele contractuale care rulează pe dublurile d e testare, precum și cu implementări le reale,
34
putem găsi teste de integrare care sunt mai rapide, mai independente și de obicei mai ușor de
explicat.
Configurarea integrarii continue
Una dintre cele mai bune modalități de a menține proiectul fara bug -uri este printr -o suită de
testare, dar este ușor să uitați să efectuați teste tot timpul. Serverele de integrare continuă (CI)
permit configurarea magaziei de proiecte, astfel încât testele să funcționeze la fiecare
solicitare de comitere.
Există servicii plă tite de CI, cum ar fi C ircle CI și Travis CI, și se poate, de asemenea, să
găzdui m gratuit folosind Jenkins și altele . Deși Circle CI și Travis CI sunt servicii plătite, ele
sunt oferite gratuit pentru pr oiecte cu sursă deschisă. Se poate crea un proiect public pe
GitHub și se pot adăuga aceste servicii fără să plătim . Contribuțiile la Repo Angular sunt
rulate automat printr -o întreagă suită de teste Circle CI.
Configurarea proiectului pentru Circle CI
Pasul 1: Se creaza un director numit .circleci la răd ăcina proiectului.
Pasul 2: În noul dosar, se creaza un fișier numit config.yml cu următorul conținut:
35
Figura 3.24: Configurarea CI
Această configurație cache -uie node_modules / și folosește npm run pentru a executa
comenzile CLI, deoarece @ angular / cli nu este instalat la nivel global. Cele doua liniuțe ( –)
sunt necesare pentru a transmite argumente în scriptul npm.
Pasul 3: Se comuta modificările și se împing în depozit.
Pasul 4: Este necesara inscrierea pentru Circle CI și se adauga proiectul. Proiectul ar trebui să
înceapă să construiască.
Configurarea proiectului pentru Travis CI
Pasul 1: Creați un fișier numit .travis.yml la root, cu următorul conținut:
36
Acest lucru face aceleași lucruri ca și configurația Circle CI, cu excepția faptului că Travis nu
vine cu Chrome, deci se foloseste în schimb Chromium.
Pasul 2: Se comuta schimbările și se împing în depozit.
Pasul 3: Este necesara inscrierea pentru Travis CI și se adăuga proiectul. Trebuie impu sa o
nouă angajare pentru a declanșa o construcție.
37
Configurarea CLI pentru testarea CI în Chrome
Atunci când comenzile CLI ng test și ng e2e rulează, în general, testele CI, este posibil să fie
necesa r să se ajusteze configurația pentru a rula testele browserului Chrome.
Există fișiere de configurare atât pentru testul de testare Karma JavaScript, cât și pentru
instrumentul de testare end -to-end de la Protractor, care trebuie ajustat pentru a porni Chr ome
fără sandboxing.
În fișierul de configurare Karma, karma.conf.js, se adăuga un lansator personalizat numit
ChromeHeadlessCI de mai jos:
browsers : ['Chrome' ],
customLaunchers : {
ChromeHeadlessCI : {
base: 'ChromeHeadless' ,
flags: ['–no-sandbox' ]
}
},
În directorul rădăcină al proiectului testelor e2e, se creaza un nou fișier numit protractor –
ci.conf.js. Acest nou fișier extinde originalul protractor.conf.js.
const config = require('. /protractor.conf').config;
config.capabilities = {
browserName: 'chrome',
chromeOptions: {
args: [' –headless', ' –no-sandbox']
}
};
exports.config = config;
3.5. Teste de sistem End to End
Testele de sistem sunt necesare deoa rece testele conduse pe module ș i testele de integrare nu
sunt reprezentative pent ru condiț iile de opera re in uz real. Prin testele inițiale nu se verifica
funcționarea întregului sistem sau a interacț iunilor dintre toate componentele.
38
Testarea sistemului este necesa ră deoarece multe dintre criteriile de selecție a testelor la
unitatea și testarea integrării conduc la producerea unui set de cazuri de testare care nu sunt
reprezentative pentru condițiile de funcționare din mediul viu. În consecință, este puțin
probabil ca testele la aceste niveluri să dezvăluie erori datorate interacțiunilor din întregul
sistem sau din cauza problemelor legate de mediu.21
Testele de sistem s e concentreaza pe modul de funcționare a aplicaț iei, intr -un mediu similar
cu cel în care urmeaza sa fie folosită .
De obicei, aceste teste sunt conduse de către o echipă externă echipei de dezvoltare. Astf el,
are loc o evaluare obiectivă a aplicaț iei.
In modelul -V, aceste teste sunt documentate în specificațiile funcț ionale. Specifi cațiile
funcțional e descriu atât comportamentul așteptat cât ș i comportamentul nedorit.
Specificațiile funcț ionale : Descriu funcțiile pe care trebuie să le realizeze sistemul,
independent de modul de implementare. Aceste specificaț ii sunt strict legate de aplicația
dezvolt ată; ele nu sunt gener al valabile pentru orice aplicație. (eg. ne așteptă m ca pe site -ul
unei c ompanii de zboruri comerciale să putem obține informații despre zboruri, să avem
posibilitatea să rezervăm bilete; aceste opț iuni nu sunt dispo nibile pe un site de homebank,
însă).
Specificațiile non -funcț ionale : se referă la caracteristicile sistemului car e nu sunt direct
legate de funcțiile pe care acesta le îndeplinește. Aceste specificații sunt generice (se aplică la
o multitudine de aplicații, cu mici variați i) și se refera atât la condițiile normale de operare,
cât și la cazurile excepț ionale.
Exemple de specificații non -funcț ionale:
– Performață – În cate milisecunde raspunde o pagina web.
– Fiabilitate – Abilitatea aplicației să î ndeplineas că cerințele / func țiile pe o
perioadă indelungată de timp.
– Întreț inere – Care sunt costurile reparării unei disfuncționalități; câ t de complex
este codul.
– Portabilitate – Poate fi folosită aplicația în condiț ii optime pe diferite sisteme de
operare, browsere, device -uri?
– Instalabilitate – Cât de usor poate fi instalată aplicaț ia pe diferite sisteme de
21 Brian Hambling (edit or), Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 46)
39
operare.
– Securitate – Ce criterii de securitate sunt folosite? Transferului de date se face
criptat? Daca da, se folosesc chei unice de decriptare sau o cheie generala?
Cele mai multe aplicații au un fel de interfață de utilizator. De obicei vorbim despre o
interfață web în contextul aplicațiilor web.
Testele UI testează faptul că interfața de utilizator a aplicației dvs. funcționează corect.
Introducerea utilizatorilor ar tre bui să declanșeze acțiunile corecte, datele ar trebui prezentate
utilizatorului, starea UI ar trebui să se schimbe așa cum era de așteptat.
Din fericire, testarea comportamentului interfeței cu utilizatorul este destul de simplă. Se face
clic aici, se introduc dat ele acolo și dorim ca starea interfeței de utilizator să se modifice în
consecință. Cadrele moderne de aplicare a unei singure pagini (reacție, vue.js, Angular și
altele) vin adesea cu propriile instrumente și ajutoare care permit testarea cu atenție a aceste i
interacțiuni într -o manieră destul de scăzută.
Testele end -to-end au propriile lor probleme. Acestea deseori eșuează din motive neașteptate
și imprevizibile. Destul de des eșecul lor este fals pozitiv. Cu cât este mai sofisticată interfa ța
cu utilizatorul, cu atât testele mai tari au tendința sa esueze . Ciudatenii ale browserului,
probleme de sincronizare, animații și dialoguri pop -up neașteptate sunt doar câteva dintre
motivele care permit programatorului să -si petre aca mai mult timp cu depanare decât si-ar
dori să recunosc a.
Desigur parerile sunt imparț ite, unii considera ca testele end to end ar trebui realizate in mod
functional, alț ii considera va riant automatizata mai eficientă .
3.5.1. Realizarea unui test End to E nd
TestBed este ce l mai important dintre utilitarele de testare Angular. TestBed creează un
modul de testare angular construit dinamic care emulează un Angular @NgModule.
Metoda TestBed.configureTestingModule () ia un obiect de metadate care poate avea
majoritatea proprietă ților unui @NgModule.
Pentru a testa un serviciu, se setează proprietatea metadatelor furnizorilor cu o serie de
servicii pe care se vor testa sau simula.
40
Figura 3.25: Metoda TestBed.configureTestingModule
Apoi, injectați -l într -un test, apelând TestBed.get () l a clasa de servicii ca argument sau în
interiorul before Each () dacă preferați să injectați serviciul ca parte a setării.
Figura 3.26: Comanda TestBed
Se dau comenzile de testare (in cazul aplicaț iei create, se va adă uga un input nou) :
Figura 3.27: Coma nda de testare/navigare automată
Aceasta comandă caută butonul 'Dogs' din meniul principal după clasa css (nav a) si textul
butonului 'Dogs' și dă click pe el.
Figura 3.28: Comanda care caută butonul
Asteapta 1 secunda. În teste reale vrem să ruleze cât mai repede deci evită m sleep -uri. Pentru
prezentare vrem să se vadă cum dă singur cli ck deci la fiecare pas se adaugă comanda pentru
41
sleep.
Figura 3.29: Comanda sleep
De pe pagina 'Dogs' caută după input fiel d și setează valoarea lui
Figura 3.30: Comanda care caută câ mpul dorit
Se caută elem entul 'button' cu textul 'add' și dă click pe el. Aici dacă folosim inspect din
browser e buton si are textul 'add'
Figura 3.31: Comanda care caută butonul 'add'
Scroll in jos (din nou doar pentru prezenta re, intr -un test real nu vrem să vedem pas cu pas
cum se întamplă. Vrem ca testele să se execute câ t mai rapid)
Figura 3.32: Comanda care face scroll in jos
Caută ultimul e lement din lista '.dogs' (dacă se f oloseș te develo per tool inspect e un element
părinte cu atributul class="dogs" ). Fiecare copil e de tipul li ș i fiecare ar e în interiorul sau un
link a . Textul lui t rebuie să contină 'New Dog', cel adăugat mai devreme.
42
Figura 3.33: Comanda care verific ă elementul adăugat
Prin pași similari se poate ș terge un input din aplicaț ia creata:
Figura 3.34: Comanda de testare pentru ș tergere
Această comandă caută butonul 'Dogs' din meniul principal după clasa css(na v a) ș i textul
butonului 'Dogs' și dă click pe el.
Figura 3.35: Comanda de click pe butonul Dogs
Se adaugă comanda sleep, pentru a vedea mai bine cum se executa testul
Figura 3.36: Comanda sleep
Caută primul eleme nt din lista '.dogs', apoi caută butonul de delete și dă click pe el.
Figura 3.37: Comada ca re caută butonul delete ș i face click pe el
43
Verifică că primul element a devenit ' Shepherd '.
Figura 3.38: Comanda care verifică primul element după ș tergere
3.6. Teste de acceptare
Testarea î n vederea validării programului, numită ș i testare de acceptare, are d rept scop
stabilirea faptului că programul satisface cerinț ele viitoril or utilizatori. Ea se efectuează într –
un mediu similar cu mediul î n car e urmează sa funcționeze aplicaț ia, folosindu -se date reale
(migrate din medi ul real). Dacă facem referire la modelul V, testele de ac ceptare se bazeaza
pe specificațiile aplicaț iei.
Spre deosebire de testarea sistemului, totuși, testarea efectuată aici trebuie să fie independentă
de orice alte teste efectuate. Scopul său principal este de a demonstra conformitatea
sistemelor cu cerințele clienților și cu procesele operaționale și de întreținere . De exemplu,
testarea de acceptare poate evalua gradul de pregătire al sistemului pentru desfășurare și
utilizare.22
Testele de acceptare sunt, de obicei, efectuate de că tre client / viitori utilizatori. Î n urma
testelor de acceptare, se ia o hotărâre cu privire la intrarea în producț ie a aplica ției.
Există mai multe tipuri de teste de acceptare:
– Validarea din punctul de vedere al utilizatori lor – Îndeplinește aplicația toate
cerinț ele definite?
– Validarea din punctul de vedere al operabilității – Există proceduri / procese prin
care odată pusă aplicația în producție, ea poate fi utilizată și menținută? În această
categorie avem:
▪ Training pentr u utilizatori
▪ Migrarea datelor : cum sunt introduse datele inițiale în sistem / aplicaț ie
▪ Proceduri de securitate
▪ Sistem de back -up
– Validarea contractuală a aplicaț iei – Au fost dezvoltate toate functionalitațile
22 Brian Hambling (editor), Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 48)
44
definite în contract aș a cum au fost specificate? Suportă aplicaț ia numarul de
utilizatori estimat în contract fară ca acest lucru să afecteze
– Validarea A lpha – Teste conduse de o echipă de testare l a locația unde a fost
dezvoltată aplicaț ia.
– Validarea Beta – Teste conduse de către reprezent ații viitorilor utilizatori la
locaț ia clientului.
3.7. Testarea exploratorie
Testarea exploratorie se desfasoară în mediul de test ș i are o structura foarte bine definită.
Gradul de success al testării exploratorii este strâ ns legat de fami liaritatea te sterului cu
aplicația testata, experiența ș i creativitatea acestuia.
Testarea exploratorie este o tehnică ca re combină experiența testerilor cu o abordare
structurată a testării în care specificațiile lipsesc sau sunt inadecvate și unde există o presiune
de timp severă .23
Etapele testă rii exploratorii sunt:
– Stabilirea u nui obiectiv – Ce modul se doreș te a fi testat , ce funcționalități î n mod
special
– Stabilirea unui time -frame – De obicei, intre 1 si 2 ore
– Recitirea specificaț iilor pentru modulul respectiv
– Testarea efectivă – Diferența dintre testarea funcțională ș i testarea exploratorie
este dată de modul î n care su nt conduse testele. În testarea funcțională, testele și
ordinea lor sunt stabilite în avans, pe când î n testarea exploratorie, rezultatele
testelor determina urmatoarele teste.
– Înregistrarea rezultatelor – Pașii desfășurați sunt notați, astfel încât, î n cazul în
care se descoperă o disfuncț ionalitate sau o eroare de logică, să se poată crea un
ticket. Tool -urile de inregistrare a ecranului (eg. Ji ng) sunt foarte utile in testarea
exploratorie.
23 Citat tradus: “Exploratory testing is a technique that combines the experience of testers with a structured
approach to testing where specifications are either missing or inadequ ate and where there is severe time
pressure .” Brian Hambling (editor), Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter Williams,
(2010) SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 119)
45
Capitolul 4 – Black -box
În Black -box, testele derivă direct din specificaț ii. Cel mai important aspect este faptul că
specificațiile ar trebui să definească nu modul în care este dezvoltată o funcț ionalita te, ci doar
aspecte le dorite / nedorite ale aplicației. Este foarte importantă diferențierea între ce
funcț ionalități trebuie să aibă un sistem (o specificație / caracteristică) ș i cum trebuie
implementată funcționalitatea respectivă (design).
O altă caracteristică o reprezintă faptul că testele trebuie scrise strict pe baza specificațiilor,
fără ca programatorii să fie implicați. Acest lucru ne oferă posibilitatea de a descoperi bug-
urile de programare (aplicaț ia este testata conform cu cerințele cli entului, și nu conform cu
întelegerea programatorilor) și ambiguitățile din specificaț ii.
Cele mai importante tehnici black -box sunt:
– Equivalence part itioning (Partajarea echivalentă )
– Boundary value an alysis (Analiza valorilor limită )
– Decision table testi ng (Testarea folosind tabele de decizie)
– State transition te sting (Testarea folosind tranziția stă rilor)
– Use case testing (Testarea folosind cazuri de utilizare)
4.1. Equivalence partitioning
Ideea de bază a tehnicii Equivalence partitioning este urmatoare a: valorile introduse într -un
câmp pot fi împărțite î n grupuri de valori similare sau avâ nd un comportament similar.
Partiț iile echivalente sunt folosite la toate nivelurile de tes tare. Se pot aplica pentru intrările
în aplicație, ieșirile din aplicație ș i pentru valori cu re ferire la timp (care se modifică în
funcț ie de o data / un eveniment).24
Principalul avantaj al tehnicii equival ence partitioning este faptul că numarul de teste
executate pentru a testa o funcț ionalitate este redus considerabil. Odata ce clasele de valori au
fost stabilite, indiferent de valoarea care este folosita pentru un test, rezultatul va fi vali d
pentru toate valorile aceleiași clase. Î n cazul valorilor numerice, se testeaza , de obicei, cu o
valoare aflată aproximativ la mijlocul clasei.
24 Brian Hambling (editor), Peter Mo rgan, Angelina Samaroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 84)
46
Exemplu:
– La o aplicaț ie de e -learning, campul Valoare accepta doar numere intregi, cuprinse
intre -10.000 si 10.000
– Cum am putea împărți valorile de intrare astfel î ncât să avem o testare eficienta?
Figura 4.39: Clasele echivalente valide si invalide
Clasele de echivalență valide sunt:
– Valori intre -10.000 si -1
– Valori intre 1 si 10.000
– 0
Clasele de e chivalență invalide sunt toate tipurile de astfel de input:
– Valori mai mici decâ t -10.000
– Valori mai mari decâ t 10.000
– Valori fracț ionare (eg . -1,75, 179,93)
– Valori alfabetice
– Caractere speciale ( @ # % ^ & * \ | / spatiu liber)
– Semne de punctuaț ie ( ! ? , . : ; “” ‘’)
Valorile de test ar fi:
– Valide: -5.000, 0, 5.000
– Invalide: -5.000,27, 5.000,35, abc, #, !
Observație: În general, numărul de partiții / clase de echivalență invalide este mai mare decât
numărul de partiț ii valide. Aceste p artiții trebuie identificate și testate pentru a ne asigura că
funcționalitatea este implementată conform specificaț iilor.
47
4.2. Boundary value analysis
Tehnica Bound ary value analysis este folosită pentru a testa eficient limitele unui interval. In
cazul câmpurilor numerice sau cu limită ri de caractere, majoritatea greș elilor se regasesc la
limita admisă sau respinsă .
De obicei, această tehnica este folosită împreună cu Equivalence Partitioning (partițiile au
limite) și poate fi aplicată la toate nivelurile de testare.
Exista 2 metode de aplicare a metodei:
– Cu 2 valori: se iau valoarea valida de la limită ș i prima valoare invalida
– Cu 3 valori: se iau valoarea limită și cele mai apropiate valori, atât din interiorul
limitei, cât ș i din afara ei.
Exemplu:
– Câmpul “Vârstă” acceptă doar valori numerice cuprinse î ntre 18 si 64.
– Care sunt partiț iile valide si invalide pe ntru tes tarea acestei specificaț ii?
– Care sunt boundary values, dacă ar fi să aplicăm atât tehnica cu 2 valori, cât ș i cea cu
3 valori?
Figur a 4.40: Analiza valorilor limită
Clasele valide sunt: 18 -64 (inclusiv)
Clasele invalide sunt:
– Valori mai mici decâ t 18
– Valori mai mari decâ t 64
– Valori fracț ionare (eg. -1,75, 179,93)
– Valori alfabetice / alfanumerice
– Caractere speciale ( @ # % ^ & * \ | / spatiu liber)
48
– Semne de punctuaț ie ( ! ? , . : ; “” ‘’)
Boundary values:
– 2 valori: 17, 18 si 64, 65
– 3 valori: 17, 18, 19 si 63, 64, 65
4.3. Decision table testing
Specificațiile conț in, de cele mai multe ori, reguli de business care define sc funcțiile unui
sistem și condițiile în care acesta operează. Testarea unei condiții independențe este relativ
simplă. Testarea integrală a unui sistem care conț ine mai multe condi ții logice este destul de
complexă . Pentru a facilita testarea condiț iilor logice, putem apela la Tabele de decizie .
Un tabel de decizie cuprinde:
– Reguli de business – combinații de condiț ii care a u atasate o valoare de intrare și o
acțiune; scrise pe coloana.
– Toate valorile de intrareale condiț iilor – scrise pe linii.
– Toate acțiunele care rezulta in funcț ie de valorile de intrare – scrise pe linii.
Exemplu:
Figura 4.41: Tabel de decizie
Regula 1:
– Dacă toate Condițiile (de la 1 la 3) sunt î ndeplinite (adevarate), atun ci Actiunea 1
poate fi efectuată .
– Dacă toate Condiț iile (de la 1 la 3) sunt indeplinite (adevarate), atunci Actiunea 2 nu
poate fi generată .
49
Regula 2:
– Dacă Condiția 1 este f alsă și Condiția 2 este adevarată , atunci Acțiunea 1 nu poate fi
generată / efectuată .
– Daca Condiția 1 este falsă și Condiț ia 2 este ad evatată, atunci Acțiunea 2 poate fi
efectuată .
– În acest caz, valoarea Condiției 3 nu este relevantă pentru definirea acți unilor
(indiferent dacă Condiția 3 este adevarată sau falsă, pot fi generate aceleași acț iuni).
Regula 3:
– Daca Condiț iile 1 si 2 sunt adevarate, iar Condiția 3 este falsă, atunci, atât Acțiunea 1,
cât și Acț iunea 2, pot fi generate.
Fiecare coloană dintr-un tabel de decizie reprezintă un test case , deoarece sunt identificate
atât datele de intrare, cât ș i cele de iesire.
Numă rul de con diții și acț iuni po ate fi destul de ridicat, dar, în general, combinațiile î n urma
carora se poate efectua o acț iune sunt destul de restrictive. Î n tabelele de decizi e nu sunt
trecute toate combinațiile posibile de condiții și acț iuni, ci doar acelea care corespund unei
reguli de business.25
4.4. State transition testing
Tehnic a State transition este folosită în sistemele î n care comportamentul / rezultatul este
determinat de schimbarea condițiilor de intrare sau de schimbările de “stare”. Acț iunile care
pot fi ef ectuate depind de starea curentă și de cea anterioară a sistemului.
Tranziț iile sunt determinate de evenimente ș i pot genera un comporta ment vizibil diferit sau
schimbă starea internă a sistemului.
Starile sistemului și tranziț ia dintre acestea s unt reprezentate î ntr-o diagrama, cu ajutorul
simbolurilor:
– Cerc – Reprezintă o stare a sistemului.
– Sageata – Reprezintă tra nziția de la o stare la alta.
Exemplu:
25 Brian Hambling (editor), Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter Williams, (2010)
SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition (pagina 89)
50
Un p osesor al unui card bancar dorește să retragă bani. La bancomat, pentru a putea retrage
bani, primul pas este in troducerea pin -ului corect. Dacă pin-ul este introdus corect,
utilizatorul poate accesa contul și, deci, retrage bani. Dacă pin -ul este introdus greșit de 3 ori
la rând, cardul este blocat.
Diagrama stărilor sistemului până la mome ntul în care fie clientul îș i poate acces a contul, fie
cardul ii este reținut de că tre bancomat, este:
Figura 4.42: Diagrama stă rilor unui sistem
4.5. Use case testing
Cazu rile de utilizare a unei aplicații sunt o formă de a specifica funcționalităț ile ca scenarii de
busine ss. Scenariile surprind interacț iunile individuale dintre un “actor” și sistem. Actorul
reprezin tă un tip de user (dacă sunt mai multe tipuri de user într -o aplicație, vor fi folosiț i mai
mulți actori î n definirea scenariilor).
Testel e care au la bază procesele de business sunt foarte eficiente î n descoperirea lacunelor de
logică . Aceste tipuri de er ori nu pot fi gasite prin testarea izolată a unei componente. De
foarte multe ori, cazurile de utilizare sunt folosite ca bază pentru test ele de acceptare. Î n
definirea cazurilor de test, se ține cont de acț iunile efectuate de catre actor (ce acț iune
efect ueaza actorul, ce vede actorul) și nu de valorile așteptate de către aplicație (valorile care
rezulta în urma acț iunilor efectuate de acto r). Aceste teste sunt scrise î n limbaj non -tehnic.
Scenariile de test au ben eficiul major de a accesa același modul / aceleași funcționalităț i pe
care le -ar executa un utilizator real. Scenariil e descriu cele mai frecvente acțiuni efectuate de
către un ac tor, identificând astfel disfuncționalităț i care risca să apară în producț ie.
51
Concluzii
În lumea de afaceri de astăzi , software -ul este peste tot. În întregul proces de dezvoltare de
software, testarea este o fază care este adesea uitată. Toată lumea presupune că odată ce
software -ul este dezvoltat, acesta va funcționa perfect. Cu toate acestea, se întâmplă adesea să
nu fie așa. Mai mult, atunci când nu functioneaza , suntem cu toții nesatisfăcuți și frustrați.
Problemele cu software -ul sunt o întâlnire frecventă, dar numai câteva persoane le abordează
în produsul lor. Recunoscând importanța și beneficiile testelor softwar e și făcându -l unul
dintre primii pași în procesul de implementare, software -ul va fi eficient și fără erori.
Proiectul mediu are câteva săptămâni de testare înainte de lansare și, adesea, se elimină
complet. Acest lucru nu ar trebui să fie așa, deoarece t estarea software -ului a venit să joace
un rol vital în succesul afacerii.
Testarea este o metodă de verificare extrem de importantă care ocupă o parte foarte mare din
resursele unui proiect, inclusiv programul, bugetul, personalul și facilitățile. Spre deo sebire
de numeroasele activități constructive ale ingineriei sistemelor, testarea este relativ unică
deoarece este inerent distructivă. Scopul său principal este de a forța sistemul sau
componentele acestuia să eșueze, astfel încât defectele care au cauzat defecțiunea să poată fi
descoperite și apoi fixate. Pe lângă detectarea defectelor, se efectuează de asemenea teste
pentru a furniza suficiente dovezi obiective pentru a justifica încrederea în calitatea
sistemului .
Găsirea de erori într -un software este sarcina testerilor, dar, în același timp, aceștia sunt
experți de domeniu ai software -ului respectiv . Dezvoltatorii sunt responsabili numai pentru
componenta sau zona specifică care îi este atribuită, dar tester ii înțeleg funcționarea generală
a software -ului, ce sunt dependențele și impactul unui modul asupra unui alt modul.
Testarea software -ului este o parte importantă a procesului de dezvoltare software. Nu este o
singură activitate care are loc după implementa rea codului, ci face parte din fiecare etapă a
ciclului de viață. O strategie de succes a testului va începe cu considerare în timpul
specificării cerințelor. Detaliile de testare vor fi elaborate prin designul sistemelor de nivel
înalt și de nivel scăzut, iar testarea va fi efectuată de dezvoltatori și grupuri de testare separate
după implementarea codului.
Ca și în cazul celorlalte activități din ciclul de viață al software -ului, testarea are propriile sale
provocări unice. Pe măsură ce sistemele software devin din ce în ce mai complexe,
importanța testării eficiente și bine planificate, va crește eforturile.
52
Bibliografie
[1] Brian Hambling (editor) , Peter Morgan, Angelina Samaroo, Geoff Thompson și Peter
Williams , (2010) SOFTWARE TESTING An ISTQB –ISEB Foundation Guide Second Edition
[2] Glenford J. Myers, (2004 ) The Art of Software Testing, Second Edition , John Wiley &
Sons, Inc., Hoboken, New Jersey
[3] Gregory Tassey, Ph.D., The Economic Impacts of Inadequate Infrastructure for Software
Testing , https://www.nist.gov/sites/default/files/documents/director/planning/report02 -3.pdf
[4] Titus Slavici, Dumitru Mnerie, Liviu Herman, Gheorghe Catalin Crisan, Using cost –
benefit analysis in project assessment , (2011) http://www.wseas.us/e –
library/conferences /2011/Meloneras/SOMMEM/SOMMEM -30.pdf
[5] Martin Flower, The Practical Test Pyramid , https://martinfowler.com/articles/practical –
test-pyramid.html
[6] Nick Bilton , Nest Thermostat Glitch Leaves Users in the Cold ,
https://www.nytimes.com/2016/01/14/fashion/nest -thermostat -glitch -battery -dies-software –
freeze.html
[7] Chang -Ran Kim; Editing by Dominic Lau , Toyota to recall 1.9 million Prius cars for
software defect in hybrid system , https://www.reuters.com/article/us -toyota -recall –
idUSBREA1B1B920140212
[8] Canada's immigration website crashes during US vote ,
https://www.bbc.com/news/technology -37921376
[9] Protractor Testing – https://www.guru99.com/protractor -testing.html
[10] Selenium Document – https://www.selen iumhq.org/docs/01_introducing_selenium.jsp
[11] Cucumber Testing Tool – https://www.guru99.com/introduction -to-cucumber.html
[12] Junit – Quick Guide – https://www.tutorialspoint.com/junit/junit_quick_guide.htm
[13] Typescript – https://www.typescriptlang.org/
53
Anex e
54
55
56
57
58
59
60
61
62
DECLARAȚIE DE AUTENTICITATE
A
PROIECTULUI DE FINALIZARE A STUDIILOR
Titlul proiectului _____________________________________________________
___________________________________________________________________
___________________________________________________________________
Autorul proiectului _____________________________________________
Proiectul de finalizare a studiilor este elaborat în vederea susținerii examenului de
finalizare a studiilor organizat de către Facultatea
_______________I.E.T.I._________________________ din cadrul Universității din Oradea,
sesiunea________iulie_______ __ a anului universitar __2019 ___________.
Prin prezenta, subsemnatul (nume, prenume, CNP)_____________________
___________________________________________________________________
___________________________________________________________________,
declar pe proprie răspundere că aceast proiect a f ost scris de către mine, fără nici un ajutor
neautorizat și că nici o parte a proiectului nu conține aplicații sau studii de caz publicate de
alți autori.
Declar, de asemenea, că în proiect 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 drepturile de
autor.
Oradea,
Data Semnătura
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT IOAN [607527] (ID: 607527)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.