Sunteți pe pagina 1din 10

Ministerul Educaţiei, Culturii și Cercetării al Republicii Moldova

Universitatea Tehnică a Moldovei


Departamentul Ingineria Software și Automatică

REFERAT
Disciplina: Testare Software
Tema: Nivele de Testare

A efectuat: st.gr. TI
192,
Mereuță Ana, Ciobanu Ecaterina

A verificat:
asist.univ.
Cazac Daniela
Chișinău 2022
Introducere
Scopul nivelelor de testare este de a face testarea software sistematică și de a
indetifica cu ușurință toate cazurile posibile la un anumit nivel. Nivelele de testare ajută la
verificarea comportamentului și performanței pentru testarea software-ului. Aceste nivele de
testare sunt concepute pentru a recunoaște zonele lipsă și a crea legătura între stările ciclului
de viață de dezvoltare (SLDC). În modelele SDLC există etape, cum ar fi colectarea
cerințelor, analiza, proiectarea, codificarea sau execuția, testarea și implementarea. Toate
aceste faze trec prin nivelele de testare.

Nivele de testare
În Testarea Software cele mai des întâlnite și populare la rândul său nivele de testare
sunt:
1. Teste Unitare
2. Testarea de integrare
3. Testele de sistem
4. Testarea acceptării
Fig 1. Nivele de Testare după V-model

1. Testarea unitară
Testarea unitară se referă la testarea individuală a unor unități separate dintr-un sistem
software. În sistemele orientate pe obiecte, aceste unități sunt de obicei clase și metode.
Uneltele de testare unitară pot înregistra testele pentru ca ele să poată fi repetate ușor mai
târziu ( de obicei când se schimbă o parte din sistem ), astfel încât dezvoltatorul să fie
convins că noile modificări nu au influențat negativ la funcționalitatea anterioară.
Testarea unitară este importantă, deoarece dezvoltatorii de software încearcă uneori să
economisească timp făcând teste unitare minime și acest lucru este mit deoarece testarea
unitară necorespunzătoare duce la costuri ridicate. Dacă se efectuează testarea
corespunzătoare a unităților în dezvoltarea timpurie, atunci se economisește timp și bani
în cele din urmă. Testarea unității este întotdeauna necesară la un anumit nivel. Aceasta
este o certitudine.
Motivele utilizării nivelului de testare unitară:
 Testele unitare ajută la remedierea erorilor la începutul ciclului de dezvoltare și la
reducerea costurilor;
 Ajută dezvoltatorii să înțeleagă baza codului de testare și le permite să facă modificări
rapid;
 Testele unitare bune servesc drept documentație a proiectului;
 Testele unitare ajută la reutilizarea codului. Migrați atât codul cât și testele către noul
dvs. proiect. Modificați codul până când testele rulează din nou;
Cum se realizează testarea unitară?
Pentru a face testarea unitară , dezvoltatorii scriu o secțiune de cod pentru a testa o
anumită funcție în aplicația software. Dezvoltatorii pot, de asemenea, să izoleze această
funcție pentru a testa mai riguros, ceea ce relevă dependențe inutile între funcția testată și alte
unități, astfel încât dependențele să poată fi eliminate. Dezvoltatorii folosesc în general cadrul
UnitTest pentru a dezvolta cazuri de testare automate pentru testarea unitară.
Testare unitară este de 2 tipuri:
a) Manuală
b) Automată
Testarea unitară de obicei este automatizată, dar poate fi efectuată în continuare manual.
În cadrul testării automate:
 Un dezvoltator scrie o secțiune de cod în aplicație doar pentru a testa funcția.
Ulterior vor comenta și vor elimina în cele din urmă codul de testare atunci când
aplicația este implementată.
 Un dezvoltator ar putea, de asemenea, să izoleze funcția pentru a o testa mai
riguros. Aceasta este o practică de testare unitară mai detaliată care implică
copierea și lipirea codului în propriul mediu de testare decât mediul său natural.
Izolarea codului ajută la relevarea dependențelor inutile între codul testat și alte
unități sau spații de date din produs. Aceste dependențe pot fi apoi eliminate.
 Un programator utilizează în general un cadru UnitTest pentru a dezvolta cazuri
de testare automate. Folosind un cadru de automatizare, dezvoltatorul codifică
criteriile în test pentru a verifica corectitudinea codului. În timpul execuției
cazurilor de test, cadrul înregistrează cazurile de test nereușite. Multe cadre vor
semnaliza și raporta automat, pe scurt, aceste cazuri de test nereușite. În funcție de
gravitatea unui eșec, cadrul poate opri testarea ulterioară.
 Fluxul de lucru al testării unitare este
1) Crearea cazurilor de testare;
2) Revizuirea / reluarea;
3) Linia de bază;
4) Executarea cazurilor de testare.
Exemplu de testare unitară: obiecte simulate
Testarea unității se bazează pe crearea de obiecte simulate pentru a testa secțiuni de
cod care nu fac încă parte dintr-o aplicație completă. Obiectele simulate se completează
pentru părțile lipsă ale programului. De exemplu, este posibil să aveți o funcție care are
nevoie de variabile sau obiecte care nu sunt încă create. În testarea unitară, acestea vor fi
contabilizate sub formă de obiecte simulate create exclusiv în scopul testării unitare efectuate
în acea secțiune de cod.
Instrumente de testare unitară
Există mai multe software-uri automatizate de testare a unității disponibile pentru a
ajuta la testarea unității. Vă vom oferi câteva exemple mai jos:
 Junit: Junit este un instrument de testare gratuit utilizat pentru limbajul de programare
Java. Oferă afirmații pentru identificarea metodei de testare. Acest instrument testează
mai întâi datele și apoi se introduce în bucata de cod.
 NUnit: NUnit este utilizat pe scară largă pentru utilizarea cadrului de testare a
unităților pentru toate limbile .net. Este un instrument open source care permite
scrierea manuală a scripturilor. Suportă teste bazate pe date care pot rula în paralel.
 JMockit: JMockit este un instrument open source de testare a unității. Este un
instrument de acoperire a codului cu valori de linie și cale. Permite batjocorirea API
cu sintaxă de înregistrare și verificare. Acest instrument oferă acoperire de linie,
acoperire de cale și acoperire de date.
 EMMA: EMMA este un set de instrumente open-source pentru analiza și raportarea
codului scris în limbaj Java. Tipuri de acoperire de asistență Emma, cum ar fi metoda,
linia, blocul de bază. Este bazat pe Java, deci este fără dependențe de bibliotecă
externe și poate accesa codul sursă.
 PHPUnit: PHPUnit este un instrument de testare unitară pentru programatorul PHP.
Este nevoie de porțiuni mici de cod care se numesc unități și testează fiecare dintre ele
separat. Instrumentul permite, de asemenea, dezvoltatorilor să utilizeze metode de
afirmare pre-definite pentru a afirma că un sistem se comportă într-un anumit mod.
Avantajul testării unitare
 Dezvoltatorii care doresc să afle ce funcționalitate oferă o unitate și cum să o
folosească pot examina testele unitare pentru a obține o înțelegere de bază a API-
ului unității.
 Testarea unității permite programatorului să refactorizeze codul la o dată
ulterioară și să se asigure că modulul funcționează în continuare corect (adică
testarea de regresie). Procedura constă în scrierea cazurilor de test pentru toate
funcțiile și metodele, astfel încât ori de câte ori o modificare provoacă o eroare,
aceasta poate fi identificată și remediată rapid.
 Datorită naturii modulare a testării unitare, putem testa părți ale proiectului fără a
aștepta finalizarea altora.
Dezavantajele testării unitare
 Nu se poate aștepta ca testarea unității să surprindă fiecare eroare dintr-un
program. Nu este posibil să se evalueze toate căile de execuție chiar și în cele mai
banale programe
 Testarea unitară prin natura sa se concentrează pe o unitate de cod. Prin urmare,
nu poate detecta erori de integrare sau erori la nivel de sistem.
Se recomandă utilizarea testelor unitare împreună cu alte activități de testare.
2. Testarea integrării
După executarea testării unitare pentru fiecare unitate/componentă din cod, acestea
vor fi conectate împreună. Deci, scopul testării integrării, este de a testa interacțiunea
dintre componente.
De ce se folosește testarea integrării?
 Să se verifice dacă componentele funcționează corect odată ce au fost
conectate;
 Să se verifice dacă sunt respectate requirement-urile care privesc interacțiunea,
interfața sau comunicația dintre componente (requirement-urile pot fi legate de
funcționalitate, performanță, securitate, etc);
 Să se găsească defectele cât mai devreme în procesul de testare.
Tehnicile testării de integrare
 White-Box (persoana care testează are acces la cod);
Abordând tehnica white-box, developer-ul sau un tester cu cunoștințe de programare
va crea niște teste automate care vor verifica interacțiunea dintre componente.
 Black-box (persoana care testează nu are acces la codul sursă și nu cunoaște structura
internă a software-ului).
Folosind tehnica black-box, testerul va verifica că un anumit modul este integrat
corespunzător.
Cum efectuăm testele de integrare?
Indiferent de strategiile de testare software, procesul de testare arată astfel:
 Efectuarea planului de testare a integrării.
 Proiectarea scenariilor de testare, cazuri de testare și scripturi de testare.
 Efectuarea cazurilor de testare.
 Oferirea feedback-urilor prin raportarea defectelor găsite.
 Verificarea din nou a defectelor reparate.
 Repetarea pașilor 3, 4 și 5 până când integrarea este complet stabilită.

3. Testarea Sistemului
Testarea sistemului se efectuează pe un sistem complet integrat. Permite verificarea
conformității sistemului conform cerințelor. Testează interacțiunea globală a componentelor.
Implica încărcare, performanță, fiabilitate și testare de securitate. Testarea sistemului cel mai
adesea este testul final pentru a verifica dacă sistemul respectă specificațiile. Evaluează atât
nevoia funcțională, cât și nefuncțională pentru testare. Testarea sistemului se încadrează în
categoria de testare black-box și white-box.

De ce folosim testarea sistemului?


Testarea sistemului implică testarea codului software pentru urmărire
 Testarea aplicațiilor complet integrate, inclusiv periferice externe, pentru a verifica
modul în care componentele interacționează între ele și cu sistemul în ansamblu.
Aceasta se mai numește scenariu de testare End to End.
 Verificarea testării amănunțite a fiecărei intrări din aplicație pentru a verifica ieșirile
dorite.
 Testarea experienței utilizatorului cu aplicația.

Următoarea este o listă a categoriilor de testare software aranjate în ordine cronologică.


Iată pașii parcurși pentru a testa complet software-ul nou în pregătirea pentru comercializarea
acestuia:
 Testarea unității efectuată pe fiecare modul sau bloc de cod în timpul dezvoltării.
Testarea unitară se face în mod normal de către programatorul care scrie codul.
 Testarea integrării efectuată înainte, în timpul și după integrarea unui nou modul în
pachetul software principal. Aceasta implică testarea fiecărui modul de cod
individual. Un software poate conține mai multe module care sunt adesea create de
mai mulți programatori diferiți. Este crucial să testați efectul fiecărui modul asupra
întregului model de program.
 Testarea sistemului efectuată de un agent de testare profesional pe produsul software
completat înainte de a fi introdus pe piață.
 Testarea acceptării - testarea beta a produsului realizată de utilizatorii finali efectivi.

Diferite tipuri de testare a sistemului:
Există mai mult de 50 de tipuri de testare a sistemului. Mai jos sunt enumerate tipuri
de teste de sistem pe care o mare companie de dezvoltare software le-ar folosi de obicei:
 Testarea utilizabilității - se concentrează în principal pe ușurința utilizatorului de a
utiliza aplicația, flexibilitatea în gestionarea controalelor și capacitatea sistemului de
a-și îndeplini obiectivele
 Testarea sarcinii - este necesar pentru a ști că o soluție software va funcționa sub
sarcini reale.
 Testarea de regresie - implică testarea efectuată pentru a vă asigura că niciuna dintre
modificările făcute pe parcursul procesului de dezvoltare nu a provocat noi erori. De
asemenea, se asigură că nu apar erori vechi din adăugarea de noi module software în
timp.
 Testarea recuperării - se face pentru a demonstra că o soluție software este fiabilă,
demnă de încredere și poate recupera cu succes eventualele blocări.
 Testarea migrației - se face pentru a se asigura că software-ul poate fi mutat de la
infrastructuri de sistem mai vechi la infrastructuri de sistem actuale fără probleme.
 Testarea funcțională - Cunoscută și sub denumirea de testare completă funcțională,
testarea funcțională implică încercarea de a vă gândi la eventualele funcții lipsă.
Testerii ar putea face o listă de funcționalități suplimentare pe care un produs le-ar
putea avea pentru a le îmbunătăți în timpul testării funcționale.
 Testare hardware / software - IBM se referă la testarea hardware / software ca
„Testare HW / SW”. Acesta este momentul în care testerul își concentrează atenția
asupra interacțiunilor dintre hardware și software în timpul testării sistemului.

Ce tipuri de testare a sistemului ar trebui să utilizeze testerii?


Există peste 50 de tipuri diferite de testare a sistemului. Tipurile specifice utilizate de
un tester depind de mai multe variabile. Aceste variabile includ:
 Pentru cine lucrează testerul - Acesta este un factor major în determinarea tipurilor de
testare a sistemului pe care le va folosi un tester. Metodele utilizate de companiile
mari sunt diferite de cele utilizate de companiile mijlocii și mici.
 Timp disponibil pentru testare - În cele din urmă, ar putea fi utilizate toate cele 50 de
tipuri de testare. Timpul este adesea ceea ce ne limitează să folosim doar tipurile cele
mai relevante pentru proiectul software.
 Resurse disponibile testerului - Desigur, unii testeri nu vor avea resursele necesare
pentru a efectua un tip de testare. De exemplu, dacă sunteți un tester care lucrează
pentru o firmă mare de dezvoltare de software, este probabil să aveți un software de
testare automată scump, care nu este disponibil pentru alții.
 Educația Software Tester - Există o anumită curbă de învățare pentru fiecare tip de
testare software disponibilă. Pentru a utiliza o parte din software-ul implicat, un tester
trebuie să învețe cum să-l folosească.
 Testarea bugetului - Banii devin un factor nu doar pentru companiile mai mici și
dezvoltatorii individuali de software, ci și pentru companiile mari.
4. Testarea Acceptării
Prin testarea acceptării se verifică dacă software-ul este pregătit pentru a fi lansat pe
producție și pentru a fi folosit de end - users (utilizatorii finali). Acest tip de testare urmează
după testarea sistemului și este ultimul nivel de testare.
Care sunt obiectivele?
 Produsul software funcționează conform requirementurilor – în special business
requirements;
 Se determină dacă produsul satisface nevoile clientului sau/și a utilizatorilor finali;
Cine și cum testează?
 Pentru testarea acceptării se abordează tehnica de testare black-box;
 Persoanele care testează pot să fie testerii, o altă persoană din echipă sau chiar clientul
pentru care se dezvoltă software-ul.
Testarea acceptării se împarte în mai multe categorii:
1. User Acceptance Testing (UAT)
Scopul UAT este să se verifice dacă produsul îndeplinește funcțiile pentru care a fost
creat și dacă este ușor de folosit de către utilizatorii finali (end users). De obicei este executat
de către client sau de utilizatorii finali, însă mai sunt situații în care testarea se face de către o
persoană din echipa care a dezvoltat produsul cum ar fi product owner sau chiar de către
testeri. De obicei se folosește testarea funcțională și se verifică funcționalitățile de bază.

2. UAT ar putea răspunde la întrebări precum:


 Acest produs este ușor de utilizat de către end users?
 Produsul satisface nevoile end userilor?
 Produsul funcționează conform cerințelor de business?

3. Operational Acceptance Testing (OAT)


OAT este un tip de testare non-funcțională și se verifică aspecte precum performanță,
backup/recovery, compatibilitate cu diverse device-uri sau sisteme de operare,
mentenabilitate, etc.

4. Alpha testing
Testarea Alpha este organizată în cadrul companiei care a creat produsul, iar testarea
efectivă este realizată de către persoane care ar putea fi potențiali utilizatori ai software-ului,
fie că sunt angajați sau din exterior. Este indicat ca acele persoane să nu fi fost direct
implicate în crearea produsului (programatori, testeri).

5. Beta testing
Testarea Beta se face de către utilizatori reali care folosesc software-ul pe device-urile
personale. Ei vor raporta companiei eventualele bug-uri și care a fost experiența lor ca și
utilizatori.

Concluzie
Testarea este principalul proces fără de care nu se poate de realizat un produs software
de calitate, care ocupă cel mai mult timp din dezvoltarea produsului. Scopul nivelelor de
testare este de a face testarea software sistematică și de a indetifica cu ușurință toate cazurile
posibile la un anumit nivel. Nivelele de testare ajută la verificarea comportamentului și
performanței pentru testarea software-ului.

S-ar putea să vă placă și