Differences
This shows you the differences between two versions of the page.
|
icalc:laboratoare:laborator-08 [2023/05/05 14:52] ruxandra.grigorie |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Laborator 08 ===== | ||
| - | ==== Testarea de integrare ==== | ||
| - | |||
| - | Testarea de integrare este un tip de testare în care două sau mai multe componente diferite ale unei aplicații software sunt testate împreună pentru a valida corectitudinea interacțiunii dintre acestea. Testarea de integrare este realizată de obicei după testarea unitară și ajută la identificarea timpurie a defectelor aplicației pe parcursul ciclului de dezvoltare. | ||
| - | |||
| - | ==== Strategii de testare de integrare ==== | ||
| - | |||
| - | Există 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" constă în testarea simultană a tuturor componentelor aplicației, astfel încât sa se obțină un sistem complet. Scopul acestei strategii este de a verifica funcționarea aplicației ca întreg și de a identifica defecte apărute din interacțiunea tuturor modulelor. Aceasta abordare prezintă un efort mai redus de planificare, dar este practică doar pentru sisteme de dimensiuni si complexitate mică, fiind dificilă izolarea și diagnosticarea tuturor tipurilor de erori. | ||
| - | |||
| - | |||
| - | === Bottom-Up === | ||
| - | |||
| - | Strategia "Bottom-Up" constă în testarea incrementală a aplicației, astfel încât testarea modulelor de nivel inferior precede testarea modulelor de nivel superior. În acest tip de abordare se testează interacțiunea dintre module ale aplicației, grupate în clustere, pornind de la modulele cele mai de jos, peste care se adaugă incremental module de la nivele superioare, până ce se obține o testare completă a sistemului. | ||
| - | Strategia "Bottom Up" necesită ca modulele inferioare să fie complete înainte de a se începe testarea de integrare, ceea ce întârzie testarea sistemului in procesul de dezvoltare, dar aduce o eficacitate sporită a detectării defectelor. | ||
| - | |||
| - | === Top-Down === | ||
| - | |||
| - | Strategia "Top-Down" constă în testarea incrementală a aplicației, astfel încât testarea modulelor de nivel superior precede testarea modulelor de nivel inferior. Modulele aplicației sunt grupate și testate de sus in jos, până ce se obține o testare completă a sistemului. Aceasta abordare nu necesită ca modulele inferioare să fie complete, funcționalitatea acestora fiind imitată de module stub, ceea ce permite ca testarea să poată începe devreme ân ciclul de dezvoltare, însă vine cu dezavantajul că trebuiesc create un număr 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 (//content//) si status de finalizare (//is_done//). | ||
| - | |||
| - | 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 descrise 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> | ||
| - | <note tip>**Verificare**: validati ca request-urile intorc codurile de status **HTTP** corecte (**200** in cazul lui **PUT** si **GET**) si ca body-ul raspunsului primit este cel asteptat (in cazul lui **GET**, json-ul din body-ul primit ca raspuns trebuie sa contina task-ul introdus prin actiunea **PUT**: //content//, //user_id//, //is_done//). </note> | ||
| - | <note tip> **Atentie**: task_id-ul este generat random server-side, astfel ca task-id-ul trimis prin operatiunea de **PUT** este irelevant, iar raspunsul request-ului **GET** va contine task-id-ul generat.</note> | ||
| - | |||
| - | * Implementati un test de integrare pentru operatia de modificare a unui task. | ||
| - | |||
| - | * Implementati un test de integrare pentru operatia de listare a 3 task-uri. | ||
| - | <note tip>**Hint**: Creati 3 task-uri sub acelasi user_id, apoi validati ca operatia de listare intoarce 3 task-uri.</note> | ||
| - | <note tip>**Sugestie**: Incercati sa generati user_id-uri unice, altfel exista sansa ca operatia de listare sa va intoarca task-uri create de colegii vostrii. Pentru a genera id-uri unice, puteti folosi modulul de python **uuid**. </note> | ||
| - | |||
| - | * Implementati un test de integrare pentru operatia de stergere a unui task. | ||
| - | <note tip>**Hint**: Trebuie sa validati ca dupa operatia de stergere, un task nu poate fi obtinut prin **GET**.</note> | ||
