Testarea embedded în domeniul automotive [608319]

ACP 3

Testarea embedded în domeniul automotive
Master – TSAeA

Profesor îndrumător: Student: [anonimizat].dr.ing. Lăcrămioara GRAMA Rus Bogdan Io an

Cuprins

1. Testarea produselor software ………………………….. ………………………….. ………………………….. ……………. 3
1.1 Ciclul de viață al unui produs software ………………………….. ………………………….. …………………….. 3
1.2 Dezvoltarea clasică a programelor ………………………….. ………………………….. ………………………….. . 5
1.3 Testarea soft ware ………………………….. ………………………….. ………………………….. ……………………… 6
2. Modele de testare ………………………….. ………………………….. ………………………….. ………………………….. .. 7
2.1 Unit testing ………………………….. ………………………….. ………………………….. ………………………….. ….. 7
2.2 Testul de integrare ………………………….. ………………………….. ………………………….. ……………………. 8
2.3 Testul de validitate ………………………….. ………………………….. ………………………….. ……………………. 8
2.4 Testul de acceptare ………………………….. ………………………….. ………………………….. ……………………. 8
3. Tehnici de testare ………………………….. ………………………….. ………………………….. ………………………….. .. 9
3.1 Modelul de testare clasic ………………………….. ………………………….. ………………………….. ……………. 9
3.2 Black Box testing ………………………….. ………………………….. ………………………….. ……………………… 9
3.3 White box testing ………………………….. ………………………….. ………………………….. ……………………. 10
3.4 Grey Box ………………………….. ………………………….. ………………………….. ………………………….. …… 10
3.5 Testarea software orientata pe obiecte ………………………….. ………………………….. ……………………. 10
4.5.1 JUnit ………………………….. ………………………….. ………………………….. ………………………….. ……… 10
4.5.2 Unit Test Cases ………………………….. ………………………….. ………………………….. ……………………. 11
4. Concluzii ………………………….. ………………………….. ………………………….. ………………………….. …………. 12

1. Testarea produselor software

În zilele noastre , majoritatea produselor electronice sunt compuse dintr -o parte hardware și o parte
software.
Hardware -ul este pa rtea fizic ă a unui sistem informatic, constituit ă din ansamblul de componente electrice,
electronice și mecanice care împreun ă pot primi, prelucra, stoca și reda informa ții, sub diverse forme de
semnale electrice, acustice sau optice, spre deosebire de sof tware, care este partea logic ă — cea care
comand ă hardware -ul prin intermediul unor programe (aplica ții, sisteme de operare și drivere) — și de
datele asupra c ărora opereaz ă respectivul sistem de calcul.

Termenul este un cuvânt englez ce se traduce uzual cu echipament solid sau și cu articole de fier ărie (de
menaj). Hardware este ansamblul elementelor fizice și tehnice cu ajutorul c ărora datele se pot culege,
verifica, prelucra, transmite, afi șa și stoca, apoi suporturile de memorare (dispozitivele de sto care) a
datelor, precum și echipamentele de calcu lator auxiliare practic, toate componentele de calculatoare și
rețele de calculatoare concrete, tangibile.

Software -ul este ansamblul programelor, procedurilor, rutinelor care controleaz ă funcționarea core cta și
eficient ă a elementelor hardware. Component a software poate include toat ă gama de produse de
programare, uzual format ă din sistem de operare, drivere și programe de aplica ție. În anumite cazuri
speciale, p ărți din software se înglobeaz ă din construc ție în hardware – prin folosirea de circuite integ rate
preprogramate.

În unele domenii, prin software se în țeleg în primul rând datele cu care lucreaz ă aparatele sau
calculatoarele, cum ar fi imaginile digitalizate, sunete și piese muzicale, jocurile pen tru calculator, filme
digitalizate, clipuri video și multe alte date asem ănătoare. În caz extrem, pân ă și purt ătorii fizici de date
sau "mediile" sunt considerate a fi "software", ca de exemplu discurile optice de tip CD și DVD, casetele
video VHS și miniD V, casetele audio etc.

Pentru ca un produs s ă fie de succes acesta are nevoie ca ambele p ărți sa fie bine conturate și să poată
împlini dorin țele utilizatorului.

1.1 Ciclul de via ță al unui produs software

Ciclul de via ță al produsului se r eferă la dura ta medie de via ță a unui produs: se face o analogie (cu
produsele se nasc, se dezvolt ă, ajung la maturitate și apoi îmb ătrânesc); în func ție de perioada din via ță în
care se afl ă produsul, sunt influen țate și vânz ările acestuia.

Întregul cicl u de via ță al produsului, de la concep ția și dezvoltarea sa pân ă la dispari ția sa definitiv ă din
arena schimburilor de m ărfuri, include urm ătoarele faze : achizi ția materiilor prime, produc ția, ambalarea,
distribu ția, utilizarea, reciclarea și retragerea p rodusului de pe pia ță. O defini ție a ciclului de via ță care
descrie detaliat toate fazele succesive ale "vie ții" produsului este urm ătoarea: "Ciclul de via ță include
fazele: conceptualizare, dezvoltarea ideilor proiectului, studiul de inginerie, planificar ea proceselo r,
fabrica ție, operare, între ținere (reparare) și retragere".

Ciclul de realizare este o no țiune derivat ă din cea de ciclu de via ță acoperind intervalul dintre momentul
deciziei ini țiale de realizare și pân ă la punerea în func țiune a produsulu i software. Acest interval, împr țit
în general în etape, presupune analiza problemei, proiectarea produsului software, implementarea de cod,
testarea și experimentarea acestuia, deci reprezint ă o parte a ciclului de via ță și anume cea care are ca scop
dezv oltarea pro dusului.

Dezvoltarea de software de înalt ă calitate necesit ă procese de produc ție software, utilizate pentru a dezvolta
aceste produse, principii de inginerie software pe care s ă se bazeze aceste procese și care încorporeaz ă
practici ale ingine riei softw are.

Procesele de creare software sunt complexe și se bazeaz ă pe deciziile și judecata unor
dezvoltatori/developeri. Datorit ă necesit ății de originalitate, luare de decizii, modelare pe anumite modele,
automatizarea acestor procese este foarte l imitat ă. Nu exista un proces ideal, tot mai multe companii î și
dezvolt ă singuri procese automate de dezvoltare software. Aceste procese au evoluat până la punctul în
care exploateaz ă capabilit ățile oamenilor dintr -o companie și caracteristicile specifice ale produs elor ce se
dezvolta în acea companie.

În proiectele software din zilele noastre sunt implicate echipe mari de dezvoltatori, anali ști, arhitec ți
software, designeri, manageri, în multe cazuri distribui ți în țări sau pe continente diferite, pe per ioade de
timp de ordinul lunilor sau anilor, acest model teoretic începe s ă aibă utilitate.

Ciclul de via ță al unui produs software este reprezentat în figura de mai jos. O dat ă dezvoltat, produsul
intră într-un ciclu de utilizare și modificare, care continu ă pe toata durata sa de via ță. Tiparul nu este
specific produselor software, el putând fi generalizat pentru majoritatea produselor industriale, cu diferen ța
ca în cazul acestora din urm ă etapa de modificare se nume ște etapa de re parare sau de între ținere
(ment enan ță).

Produsele software nu se uzeaz ă, în schimb, ele trec prin faza de modificare din alte motive: corectarea
erorilor care nu au fost detectate în faza de dezvoltare, schimb ări în contextul în care sunt utilizate,
schim bări efectuate modific ări anterioare care au avut efecte nedorite în alte puncte ale programului. De
exemplu, modificarea legii impozitului necesita corectarea programelor pentru salarii, iar adesea aceste
modific ări au efecte adverse în alte zone ale prog ramului efecte care sunt ob servate ulterior.

Indiferent de motivul pentru care un produs informatic intra în faza de modificare, acest stadiu presupune
ca o persoan ă (adesea alta decât autorul programului s ă studieze programul și documenta ția aferent ă până
când ajunge la un grad d e înțelegere care sa îi permit ă efectuarea modific ărilor. În caz contrar, este posibil
ca modific ările efectuate s ă cauzeze mai multe probleme decât rezolv ă. Înțelegerea unui program este
adesea o sarcin ă foarte dificil ă, chiar î n condi țiile în care acesta a fost bine proiectat și documentat. Nu
sunt deloc rare cazurile în care în aceast ă fază renun ță complet la un anumit program component,
considerându -se (și nu f ără temei) c ă este mai u șor să se dezvolte de la zero un sistem nou , decât s ă se
modifice cu b une rezultate sistemul existent.

Experien ța arat ă că un minim de efort în timpul dezvolt ării unui produs informatic poate s ă ușureze mult
sarcina modific ării produsului, atunci când acest lucru devine necesar. Majoritatea cercet ărilor în domeniul
inginer iei software se concentreaz ă pe faza de dezvoltare a produselor; eforturile investite în aceast ă fază
aduc cele mai înalte beneficii pentru toate fazele ulterioare de via ță.

1.2 Dezvoltarea clasic ă a programelor

Vom analiza acum mai îndeaproape etapele care intră în componen ța primei faze din ciclul de via ță al
produselor informatice: dezvoltarea. Aceste etape sunt analiza, proiectarea, implementarea și testarea.

Analiza

Aceasta este etapa în care se constat ă că ar fi util ă o aplica ție informatic ă și se ia decizia dezvolt ării unui
sistem software. Fie c ă se constat ă existen ța unei pie țe pentru un produs de uz general, fie c ă o anumit ă
organiza ție are nevoie de o aplic ație specializat ă, în mare m ăsură aceast ă prim ă etapă presupune mai
degrab ă luarea uno r decizii de management și marketing decât abordarea unor probleme legate de studiul
algoritmilor. Dup ă luarea deciziei de dezvoltare a unui sistem informatic începe adev ărata analiz ă, al c ărei
scop principal este identificarea necesit ăților utilizatorului poten țial al sistemului.

Proiectarea

În faza de proiectare sunt dezvoltate detaliile tehnice ale sistemului. În aceasta etapa, sistemul este
descompus în componente m ai ușor de controlat, numite module. Implementarea sistemelor complexe
devine posibil ă tocmai prin aceast ă descompunere modular ă. Altfel, mul țimea detaliilor tehnice care
trebuie luate în considerare ar fi imposibil de st ăpânit; prin proiectarea modular ă, este suficient s ă avem în
vedere pentru fiecare modul doar detaliile corespunz ătoare acestuia. Proiectarea modular ă ajută și la
întreținerea sistemului. O structur ă modular ă bine proiectat ă este important ă atât pentru implementarea
sistemului, cât și pent ru modificarea sa ulterioara. Acesta este unul dintre principalele motive pentru care

paradigma orientat ă spre obiecte câ știgă teren: un sistem proiectat orientat spre obiecte este prin defini ție
un sistem modular.

Implementarea

Aceasta faza se refera l a scrierea efectiv ă a programelor, crearea fi șierelor de date și dezvoltarea bazelor
de date.

Testarea

Această fază este strâns legată de faza anterioară, deoarece în normal fiecare modul al sistemului este testat
în timpul implementării, într -un siste m bine proiectat, fiecare modul poate fi testat în mod independent,
utilizându -se ve rsiuni simplificate ale celorlalte module pentru a se simula interacțiunile din modulul țintă
și restul sistemului. Desigur, pe măsură ce diferite module sunt analizate și combinate, testarea individuală
trebuie continuată cu testarea generală a întregului sistem.

1.3 Testarea software

Testarea joaca un rol foarte important in procesul de dezvoltare/produc ție al unui produs de tipul soft.
Noile cerin țe ale pie ței au for țat produc ătorii de solu ții IT sa fie nevoi ți sa î și schimbe in întregime modul
de construc ție a unui produs, dar f ără a face compromisuri de calitate. Testarea sistemelor informatice
complexe presupune testarea pe componente si p ărți ale c omponentelor (func ții sau clase), urmând un plan
de test care trebuie sa con țină toate cazurile de test.

Testarea manuala :Procedurile de testare manuala, prin natura lor limitata, nu asigura g ăsirea tuturor
defectelor si nu au nicio șansa sa simuleze con diții de utilizare simultana, intensive ale unei aplica ții.

Testarea automata executa o secven ța de ac țiuni f ără a fi nevoie de interven ția umana si pot simula
utilizarea unei aplica ții ce presupune o simultaneitate ridicata. In mare parte, majoritatea pr oduselor trebuie
sa fie testate de mai multe ori, pe mai multe platforme software si hardware, ca si dup ă schimb ările
ulterioare sau lansarea unei noi versiuni. Un avantaj considerabil al acestei modalit ăți de testare este acela
ca in urma testarilor repet ate, costurile se reduc aproape la zero.

Testarea software este o investiga ție realizat ă pentru a oferi clien ților informa ții despre calitatea
produsului sau a serviciului software testat. Testarea software poate oferi, de asemenea, o vedere obiectiv ă
și independent ă asupra impactului implement ării softwarelui testat. Tehnicile de testare includ procesul de
executare a unui program sau a unei aplica ții cu inten ția de a g ăsi bug -uri software (erori sau alte defecte)
și verificarea dac ă produsul software est e potrivit pentru utilizare.

Testarea reprezint ă procesul, ce con ține toate activit ățile din timpul ciclului de viat ă al unui produs, fiind
ele statice cat si dinamice. Acest lucru presupune planificarea, preg ătirea si evaluarea produselor software
pentru a determina daca satisfac cerin țele specificate, daca îndeplinesc scopul propus si a detecta defecte
O activitate statica reprezint ă analiza componentelor soft, care nu implica urm ărirea efectiva a execu ției
acestora (spre exemplu scrierea cerin țelor, sc rierea codului, etc.) iar o activitate dinamica reprezint ă analiza
componentelor soft, care implica urm ărirea efectiva a execu ției lor (rularea softului).
Principii de testare :
• In urma test ării se g ăsesc defecte, dar nu exista siguran ța ca nu mai exista si altele; testarea poate
numai sa reduc ă numărul de defecte nesesizate.
• Testarea completa este imposibila, de a ceea cea mai buna solu ție este sa se aplice o strategie si un
management al riscului de calitate.
• Testarea din timp a produsului – testarea trebuie inclusa înc ă de la începutul proiectului – fazele de
planificare, proiectare si review.
• Paradoxul Pest icid – daca acela și set de teste repetat de mai multe ori nu pune in evidenta noi
defecte atunci testele trebuie regândite si eventual sa fie modificate corespunz ător.

Documente necesare test ării

Documentele necesare test ării sunt: catalog cu cerin țe(requirements catalogue),un document in care sunt
descrise scopul, strategia, resursele si programul activit ăților de testare, care poarta numele de Test Plan,
cazurile de testare (teste), care poarta numele de Test Case, un documen t care sa descrie rezultatele test ării
si construie ște o vedere de ansamblu asupra nivelului de calitate al produsului, care poarta numele de Test
Report.

2. Modele de testare

2.1 Unit testing

Termenul de testare unitara se refera la testarea individuala a unor unități separate dintr -un sistem software.
In timpul proiectării si codificării s e comit erori care sunt grupate in următoarele categorii:

o erori legate de alegerea si descrierea algoritmului: algoritm incorect, sau corect dar inadecvat
problemei;
o erori in definirea si utilizarea datelor ce provin din variabile neinițializate, nev erificarea datelor de
intrare, utilizarea unor cuvinte cheie ca variabile, variabile ilegale ;
o erori produse in tehnica de programare cum sunt variabile si structuri de date globale, acces
necontrolat la zone de memorie partajate, interfețe program – subprogram nerespectate;
o erori in contextul execuției, datorate memoriei dinamice insuficiente sau nealocata, periferice
neoperaționale, comunicare defectuoasa cu sistemul de operare.

2.2 Testul de integrare

Are ca obiectiv testarea pe diverse niveluri de integrare a modulelor. Se pune accentul pe func ționarea
corecta a ansamblului, pe compatibilitatea dintre componente, de asemenea se pune accent pe depistarea
erorilor de interfa ță intre module, elimin area conflictelor privind accesul la resursele de calcul.
Este indicat ca testele sa fie desf ășurate intra -un mediu cat mai apropiat de cel in care sistemul va func ționa
ulterior.

Sunt practicate trei tipuri de modalit ăți ale test ării:
• Testarea de sus in jos, top -down – folosita numai in cazul unei conceperi descendente a sistemului.
Se porne ște cu modulul r ădăcina si cu unul sau mai multe niveluri de ordin imediat inferior; dup ă
testarea acestui schelet care probeaz ă toate posibilit ățile se adaug ă un alt nivel inferior. Când s -au
adăugat modulele ultimului nivel testarea este terminata.
• Testarea de jos in sus, bottom -up – o metoda clasica de testare si consta in testarea individuala a
modulelor urmata de testarea ansamblului de module ca un tot un itar. Presupune verificarea sistemului
din punct de vedere al specifica țiilor sale, dar si al performantelor: timp de r ăspuns, capacitate de lucru
etc. Un dezavantaj al metodei este dificultatea in stabilirea datelor de test pentru sistemul final.
• Testa rea mixta – presupune aplicarea simultana a celor doua metode precedente, r ămânând
predominanta testarea descendenta. Prin urmare se începe elaborarea proiectului într -o maniera
descendenta, dar simultan se realizeaz ă module din nivelul de baza al ierarhie i. In acest caz testarea
descendenta se desf ășoară paralel cu cea ascendenta. Acest procedeu de concepere si testare s -a dovedit
eficient in elaborarea multor produse program.

2.3 Testul de validitate

Validitatea este definita in diferite mo duri dar o defini ție simpla spune ca validarea este terminata când
aplica ția software func ționeaz ă într-o maniera rezonabila acceptata de client. Accept ările rezonabile sunt
definite in documentul ce cuprinde specifica ția cerin țelor si care descrie toate a tributele cerute de client.

Un element important al procesului de validare este revederea configura ției – configuration review. Se
verifica daca toate elementele necesare pentru configurare au fost dezvoltate si func ționeaz ă la parametri
stabili ți. Este i mposibil de imaginat cum clientul va folosi in realitate produsul realizat de o companie de
software, chiar daca acesta cuprinde un manual de utilizare.

2.4 Testul de acceptare

Tipul de testare formala, având la baza cerin țele utilizatorului, cerin țele si procesele impuse de client, astfel
încât, sa se determine daca un sistem sau componenta satisface aceste criterii, pentru a fi acceptat sistemul sau
componenta de clientul . Se efectueaz ă cu scopul de a valida func țional produsul din perspect iva utilizatorului
final. Se apreciaz ă ca acest tip de testare, care implica si participarea viitorilor beneficiari, este pentru
dezvoltator o importanta sursa de informa ții privind contextul in care va fi utilizat sistemul.

Un test de acceptare, in gener al, are urm ătorul format:
• Verificam ca aplica ția se instaleaz ă corect folosind valorile implicite (defulat)
• Verificam ca aplica ția porne ște folosind un cod valid

• Verificam ca aplica ția se dezinstaleaz ă corect (nu r ămân fi șiere in directorul de in stalare, este stres
directorul de instalare) .

3. Tehnici de testare

3.1 Modelul de testare clasic

Testarea specifica țiilor se realizeaz ă prin metode de analiza statica: inspec ții, parcurgeri si analize tehnice.
Se testeaz ă aplica ția, in faza de proiectare, prin în țelegerea domeniului si a scopului aplica ției.

Testarea in etapa de implementare are rolul de a eviden ția diferen țele dintre comportamentul produsului
din specifica ții si cel dat la nivelul utilizatorilor. Un rol important il au verificarea si validarea, prin care
se determina daca cerin țele unui sistem sau componenta sunt complete si corecte, daca rezultatul fiec ărei
faze de dezvoltare îndepline ște cerin țele, sau condi țiile impuse in faza anterioara si daca sistemul sau
componenta finala este in concordanta cu cerin țele specificate.

Verificarea este mul țimea activit ăților care asigura o aplica ție software, implementeaz ă corect o anumita
funcție, iar Validarea este mul țimea activit ăților care asigura ca o aplica ție software realizata este in
concordanta cu cerin țele beneficiarului.

Testarea dinamica presupune examinarea aplica țiilor software, in scopul gener ării datelor de test cu care
acestea vor fi executate si rularea ap licațiilor cu seturile de date de test ob ținute. Se observa ca spre
deosebire de testarea statica, testarea dinamica presupune execu ția aplica ției care se testeaz ă.

3.2 Black Box testing

Testarea func ționala (black -box testing) este o strateg ie de testare care necesita cunoa șterea
comportamentului extern al programului pe baza specifica țiilor, nu necesita cunoa șterea structurii interne
a programului sau cuno ștințe despre modul in care este implementat programul sau modulul.

Testarea cu intr ări aleatoare – generarea de date de test in mod aleator, in cadrul domeniului acestora.
Aceasta tehnica de testare a fost dezvoltata, astfel încât datele de test sunt alese aleatoriu din domeniu si
sunt filtrate astfel încât sa îndeplineasc ă anumite condi ții, ca de exemplu producerea unui rezultat dintr -o
clasa de ie șiri posibile.

Parti ționarea pe clase echivalente – consta in împ ărțirea domeniului datelor de intrare in subdomenii, astfel
incat comportamentul programului sa fie acela și, cel pu țin teoretic, pentru orice data de intrare din
subdomeniul corespunz ător.

3.3 White box testing

Testarea structurata (white box testing) este o strategie de testare care necesita accesul la codul sursa si la
structura programului si pune accentul pe acoper irea prin teste a cailor, ramifica țiilor si fluxurilor
programului.

Strategiile de testare bazate pe cai utilizeaz ă fluxul de control al programului. Acestea reprezint ă o familie
de tehnici de testare bazate pe selectarea cu aten ție a unei mul țimi de cai din program. Cu ajutorul acestor
tehnici se detecteaz ă erorile care cauzeaz ă execu ția unei alte cai a programului decât aceea care trebuia sa
se execute.

Criteriul pentru acoperirea instruc țiunilor este ca fiecare instruc țiune sa fie executata cel pu țin o data in
cadrul unor teste. Daca se realizeaz ă acest obiectiv, atunci declara țiile sunt acoperite in propor ție de 100%.
Acest lucru este echivalent cu o acoperire a nodurilor fluxului de control asociat programului in propor ții
de 100%.

Acoperirea ramifica țiilor are drept criteriu ca fiecare ramura a unei decizii sa fie executata cel pu țin odat ă.
Se ruleaz ă un num ăr suficient de teste pentru a se executa toate ramifica țiile din program cel pu țin o data.

3.4 Grey Box

Grey Box Testing este o tehnic ă de testare a unui produs sau aplica ție software in care testerul are
cuno ștințe par țiale legate de func ționalitatea interna a produsului/aplica ției În acest proces, sunt
identificate în mod frecvent erorile specifice de sistemele we b Aceasta metoda creste capabilitatea de
testare a unui produs indiferent de complexitatea acestuia. Grey Box Testing este o metod ă de testare
software, care este o combina ție metodelor de testare White Box și Black Box Testing.

3.5 Testarea software orientat a pe obiecte

Programarea orientata pe obiecte presupune definirea de clase si obiecte, construirea de ierarhii, precum si
referirea obiectelor create. Testarea claselor eviden țiază gradul de mo ștenire si de acoperire probabila a
tipologiilor de clase de probleme prin constructori/ destructori defini ți.

Testarea software orientata pe obiecte are pe lâng ă obiectivul general al stabilirii m ăsurii in care produsul
software realizeaz ă sarcinile prezentate in specifica ții, obiective specifice legate de testarea: metodelor
membre ale fiec ărei clase; gradului de încapsulare si a efectelor acestuia; testarea efectelor induse de
nivelurile de mo ștenire/derivare; testarea efectelor induse de polimorfismul metodelor membre; testarea
interac țiunilor dintre clase.

4.5.1 JUnit

JUnit este cel mai folosit utilitar pentru testarea unitara a claselor Java. La realizarea unui proiect software
complex codul sursa al aplica ției este foarte important.

Calitatea codului sursa al unei aplica ții software este data de corectitudinea sintaxei codului surs a. Pentru
asigurarea acestei corectitudini este responsabil compilatorul de Java si a comportamentului, adic ă daca
fiecare metoda realizeaz ă ceea ce s -a specificat in documenta ția proiectului. Pentru asigurarea unui
comportament corespunz ător se vor utiliz a teste unitare realizate cu ajutorul utilitarului JUnit.

Avantajele utiliz ării JUnit:
• Este îmbun ătățita viteza de scriere a codului, si in acela și timp, creste si calitatea acestuia, deoarece
prin scrierea testelor unitare se mic șoreaz ă timpul de depa nare, permi țând depistarea imediata a
eventualelor erori inserate in codul modificat
• Clasele de test sunt u șor de scris si de modificat, pe m ăsura ce codul sursa se m ărește, putând fi
compilate împreuna cu codul sursa al proiectului. Compilatorul testea ză sintaxa codului sursa, in timp
ce clasele de test valideaz ă integritatea codului
• Clasele de test JUnit pot fi rulate automat, rezultatele fiind vizibile imediat, putând astfel crea ierarhii
de suite de test, care pot fi testate împreuna sau separat, in func ție de cerin țele proiectului
• Clasele de test m ăresc încrederea programatorului in codul sursa scris si ii permit sa urm ăreasc ă mai
ușor cerin țele de implementare ale proiectului, putând constitui si o parte a documenta ției finale, care
trebuie tr ansmisa clientului.

4.5.2 Unit Test Cases

Testarea unitar ă se refer ă la scrierea unor buc ăți de cod, denumite cod de testare, care valideaz ă
codul de produc ție. Testarea majorit ății aplica ției devine a șadar automat ă.

Caracteristicile princ ipale ale test ării unitare:
• fiecare test valideaz ă un comportament din aplica ție;
• ruleaz ă foarte repede, maxim în câteva minute;
• sunt foarte scurte și ușor de citit;
• ruleaz ă la ap ăsarea unui buton, f ără configur ări suplimentare.

Pentru a fi r apide, testele unitare folosesc adesea a șa-numitele "duble de testare". Un stub este o dubl ă de
testare care întoarce valori. Stub -ul este similar cu o simulare foarte simpl ă: atunci când ape și un buton,
apare o valoare. Un mock este o dubl ă de testare car e valideaz ă colaborarea între clase. Mock -ul valideaz ă
apeluri de metode, cu anumi ți parametri, de un anumit num ăr de ori. Din aceast ă cauză, un mock poate fi
folosit și la validarea apelurilor de metode care nu întorc valori.

Inițial dublele de testare e rau folosite doar în locurile unde era foarte greu s ă controlezi sistemul sau unde
testele erau încetinite de apeluri la sisteme externe. În timp, dublele de testare au ajuns s ă fie folosite în
toate testele unitare, dând na ștere metodei "mockiste" de test are unitar ă. Testele unitare sunt scrise de
programator, în timp ce implementeaz ă o func ționalitate.

Din p ăcate, cel mai întâlnit mod de a scrie teste este cândva dup ă ce a fost terminat ă implementarea.
Rezultatul este c ă testele sunt scrise având în mint e cum ar trebui s ă funcționeze codul și nu testarea lui.

4. Concluzii

Ființele umane sunt predispuse la gre șeli din cauza ne -atenției, a presupunerilor incorecte, a nep ăsării sau
a cunoa șterii inadecvate a sistemului. Aceast ă natur ă a oamenilor face ca softwar eul sa devina vulnerabil
la defecte si erori. Pentru a preveni și corecta aceste probleme este necesar ă testarea.

În mod tradi țional, testarea software a fost f ăcută într-o singur ă faza si aceasta fiind f ăcută după
implementare si codare, la finalizarea p rodusului. Dar din cauza cre șterii complexit ății a aplica țiilor si
produselor software a crescut, evoluat si testarea software.
Astfel, au ap ărut tehnici evoluate de testare și activit ățile de testare nu s -au limitat la o singur ă fază, în schimb
acestea au fost integrate cu diferitele modele ale ciclului de via ță al dezvolt ării software.