Differences
This shows you the differences between two versions of the page.
|
icalc:laboratoare:laborator-08 [2023/05/05 12:53] ruxandra.grigorie |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Laborator 08 ===== | ||
| - | ==== Testarea de integrare ==== | ||
| - | |||
| - | Testarea de integrare este un tip de testare in care doua sau mai multe componente diferite ale unei aplicatii software sunt testate impreuna pentru a valida corectitudinea interactiunii dintre acestea. Testarea de integrare este realizata de obicei dupa testarea unitara si ajuta la identificarea timpurie a defectelor aplicatiei pe parcursul ciclului de dezvoltare. | ||
| - | |||
| - | ==== Strategii de testare de integrare ==== | ||
| - | |||
| - | Exista 4 strategii principale de testare de integrare: | ||
| - | - Big-Bang | ||
| - | - Bottom-Up | ||
| - | - Top-Down | ||
| - | - Mixed | ||
| - | |||
| - | {{:icalc:laboratoare:ic-lab8-testing-approaches.png?600|}} | ||
| - | |||
| - | === Big-Bang === | ||
| - | |||
| - | Strategia "Big Bang" consta in testarea simultana a tuturor componentelor aplicatiei, astfel incat sa se obtina un sistem complet. Scopul acestei strategii este de a verifica functionarea aplicatiei ca intreg si de a identifica defecte aparute din interactiunea tuturor modulelor. Aceasta abordare prezinta un efort mai redus de planificare, dar este practica doar pentru sisteme de dimensiuni si complexitate mica, fiind dificila izolarea si diagnosticarea tuturor tipurilor de erori. | ||
| - | |||
| - | |||
| - | === Bottom-Up === | ||
| - | |||
| - | Strategia "Bottom-Up" consta in testarea incrementala a aplicatiei, astfel incat testarea modulelor de nivel inferior precede testarea modulelor de nivel superior. In acest tip de abordare se testeaza interactiunea dintre module ale aplicatiei, grupate in clustere, pornind de la modulele cele mai de jos, peste care se adauga incremental module de la nivele superioare, pana ce se obtine o testare completa a sistemului. | ||
| - | Strategia "Bottom Up" necesita ca modulele inferioare sa fie complete inainte de a se incepe testarea, ceea ce intarzie testarea sistemului in procesul de dezvoltare, dar aduce o eficacitate sporita a detectarii defectelor. | ||
| - | |||
| - | === Top-Down === | ||
| - | |||
| - | Strategia "Top-Down" consta in testarea incrementala a aplicatiei, astfel incat testarea modulelor de nivel superior precede testarea modulelor de nivel inferior. Modulele aplicatiei sunt grupate si testate de sus in jos, pana ce se obtine o testare completa a sistemului. Aceasta abordare nu necesita ca modulele inferioare sa fie complete, functionalitatea acestora fiind imitata de module stub, ceea ce permite ca testarea sa poata incepe devreme in ciclul de dezvoltare, insa vine cu dezavantajul ca trebuiesc create un numar mare de module stub. | ||
| - | |||
| - | === Mixed === | ||
| - | |||
| - | Strategia "Mixed", sau "Sandwiched" este o combinatie a abordarilor "Top-Down" si "Bottom-Up". In aceasta abordare, focusul este axat pe testarea unui layer al aplicatiei, integrand atat modulele de nivel superior, cat si cele de nivel inferior. | ||
| - | | ||
| - | ==== Exercitii ==== | ||
| - | |||
| - | <note warning> | ||
| - | **Setup** | ||
| - | |||
| - | <code> | ||
| - | pip install requests | ||
| - | </code> | ||
| - | |||
| - | </note> | ||
| - | |||
| - | In partea practica vom realiza teste de integrare pentru o aplicatie web de tip REST API care permite gestionarea task-urilor personale, fiind disponibila aici: https://todo.pixegami.io/. Un task este caracterizat de un user id, task id, descriere si status de finalizare. | ||
| - | |||
| - | In documentatia aplicatiei (https://todo.pixegami.io/docs) sunt descrise operatiile expuse, si anume: | ||
| - | * crearea unui task | ||
| - | * obtinerea unui task | ||
| - | * listarea task-urilor | ||
| - | * modificarea unui task | ||
| - | * stergerea unui task | ||
| - | |||
| - | Dupa ce a fost realizata testarea unitara a modulelor aplicatiei (endpoints, baze de date, s.a.), trebuie sa fie validata interactiunea dintre acestea. Astfel, se doreste sa se testeze ca operatiile pe task-uri desrise mai sus se executa cu succes. | ||
| - | |||
| - | - Implementati un test de integrare pentru operatia de creare a unui task. | ||
| - | <note tip>Hint: validarea crearii unui task presupune 2 request-uri, unul de PUT si altul de GET, testand interactiunea dintre clientul web, endpoint-ul web si baza de date in care se stocheaza task-urile.</note> | ||
| - | - Implementati un test de integrare pentru operatia de obtinere a unui task. | ||
| - | - Implementati un test de integrare pentru operatia de listare a unui task. | ||
| - | - Implementati un test de integrare pentru operatia de modificare a unui task. | ||
| - | - Implementati un test de integrare pentru operatia de stergere unui task. | ||
