Show page

Differences

This shows you the differences between two versions of the page.

--- tsc:laboratoare:laborator-08 [2025/04/23 00:25]
ionut_vladut.pasat
+++ tsc:laboratoare:laborator-08 [2025/05/05 12:04] (current)
giorgiana.vlasceanu [Exerciții]
@@ Line 11: / Line 11: @@
 Piramida de Testare este un framework popular care ilustrează proporția diferitelor tipuri de teste într-o strategie de testare software. Ideea este să se concentreze resursele pe automatizarea testelor la niveluri inferioare (teste unitare și de integrare) și să se minimizeze testele E2E (end-to-end), care sunt mai costisitoare.
-{{:tsc:laboratoare:it2.png?600|}}
+{{:tsc:laboratoare:it2.png?599|}}
 Cele 3 niveluri ale piramidei sunt:
-  *
   * Testarea Unitară: Baza piramidei. Se concentrează pe componente individuale. Sunt rapide și de obicei automatizate.
-  *
   * Testarea de Integrare: Nivelul intermediar. Verifică interacțiunile dintre componentele integrate.
-  *
   * Testarea E2E: Vârful piramidei. Verifică întregul sistem din perspectiva utilizatorului. Sunt mai puține la număr, mai lente și mai fragile.
@@ Line 27: / Line 24: @@
   - Abordarea Incrementală
-**1. Testarea de Integrare Big Bang**
+=== 1. Testarea de Integrare Big Bang ===
-{{:tsc:laboratoare:it3.png?600|}}
+{{:tsc:laboratoare:itbigbang.png?300|}}
 În această abordare, toate modulele sunt integrate și testate simultan, ca un întreg.
@@ Line 53: / Line 50: @@
   *     Util pentru aplicații simple
-** 2. Testarea de Integrare Incrementală**
+=== 2. Testarea de Integrare Incrementală ===
-{{:tsc:laboratoare:it4.png?600|}}
+{{:tsc:laboratoare:itincremental.png?500|}}
 Modulele cu logică apropiată sunt grupate și testate treptat, nu toate simultan. Procesul continuă până când toate modulele sunt integrate și testate.
@@ Line 71: / Line 68: @@
 ==== Testare de Integrare Top-down vs. Bottom-up ====
+{{:tsc:laboratoare:ithierarchy.png?600|}}
 Testarea incrementală poate fi împărțită în:
-  -     Bottom-up: Se testează mai întâi componentele de jos (fundamentale), apoi cele de sus
+  -     Bottom-up: Se testează mai întâi componentele low-level (fundamentale), apoi cele high-level
-  -     Top-down: Se începe cu componentele de sus (complexe), apoi cele de jos
+  -     Top-down: Se începe cu componentele high-level (complexe), apoi cele low-level
   -     Hibrid: Se combină cele două abordări
-Componente de nivel scăzut: funcții simple, structuri de date.
+  * Componente low-level: funcții simple, structuri de date
-Componente de nivel înalt: management utilizatori, procesare comenzi, mecanisme de securitate.
+  * Componente de high-level: management utilizatori, procesare comenzi, mecanisme de securitate
 Exemplu comparativ (site eCommerce):
-Aspect	Module Low-level	Module High-level
-Complexitate	Funcționalități simple	Multifuncționale
-Scop	Sarcini specifice	Funcționalități complexe
-Granularitate	Mici, modulare	Mari, integrate
-Exemple	Validare input, conexiune DB, cereri HTTP	Catalog produse, coș cumpărături, procesare plăți
-. Testarea Bottom-up
-Se începe cu modulele de jos și se urcă treptat. De exemplu: de la „tricouri” → „haine bărbați” → „îmbrăcăminte”.
+{{:tsc:laboratoare:ittabel1.png?600|}}
-Când să o folosești:
+== 1. Testarea Bottom-up ==
-    Complexitatea este în componentele de jos
+{{:tsc:laboratoare:itbottomup.png?600|}}
-    Se dezvoltă incremental
+Se începe cu modulele low-level și se urcă treptat. De exemplu: de la „tricouri” → „haine bărbați” → „îmbrăcăminte”.
-    Localizarea defecțiunilor este esențială
+Când să o folosești:
+  *     Complexitatea este în componentele low-level
+  *     Se dezvoltă incremental
+  *     Localizarea defecțiunilor este esențială
+  *     Componentele high-level nu sunt încă dezvoltate
-    Componentele superioare nu sunt încă dezvoltate
+== 2. Testarea Top-down ==
-. Testarea Top-down
+{{:tsc:laboratoare:ittopdown.png?600|}}
-Se pornește de la modulele de sus către cele de jos. Oferă o imagine de ansamblu devreme în proiect.
+Se pornește de la modulele high-level către cele low-level. Oferă o imagine de ansamblu devreme în proiect.
 Când să o folosești:
+  *     Funcționalitățile critice sunt în componentele high-level
+  *     Se dorește simularea interacțiunii utilizatorului
+  *     Modulele low-level sunt stabile
+  *     Se dorește validarea rapidă a funcționalităților vizibile
-    Funcționalitățile critice sunt în componentele de sus
+== 3. Testarea Hibridă (Sandwich) ==
-    Se dorește simularea interacțiunii utilizatorului
-    Modulele de jos sunt stabile
-    Se dorește validarea rapidă a funcționalităților vizibile
-. Testarea Hibridă (Sandwich)
 Se combină top-down și bottom-up.
 Avantaje:
+  * Flexibilitate în funcție de proiect
-    Flexibilitate în funcție de proiect
+  * Verificarea simultană a componentelor high și low level
-    Verificarea simultană a componentelor de sus și jos
 Dezavantaje:
+  *     Planificare și coordonare complexă
+  *     Necesită comunicare eficientă în echipă
+  *     Dificultate în schimbarea între metodele de integrare
+==== Exerciții ====
-    Planificare și coordonare complexă
+Pentru a clona [[https://github.com/cs-pub-ro/systems-testing | repo-ul]] și a accesa resursele aferente laboratorului:
-    Necesită comunicare eficientă în echipă
+<code bash>
+student@tsc:~$ git clone git@github.com:cs-pub-ro/systems-testing.git
+student@tsc:~$ cd systems-testing/laboratories
+student@tsc:~/laboratories$ cd integration-testing
+</code>
-    Dificultate în schimbarea între metodele de integrare
+Dacă aveți local [[https://github.com/cs-pub-ro/systems-testing | repo-ul]], asigurați-vă că aveți ultima versiune.
-==== Strategii de testare de integrare ====
+<code bash>
+student@tsc:~$ cd systems-testing
+student@tsc:~$ git pull
+</code>
-Există 4 strategii principale de testare de integrare:
+Dacă folosiți un fork al repo-ului, asigurați-vă că este sincronizat cu repo-ul principal.
-   - Big-Bang
-   - Bottom-Up
-   - Top-Down
-   - Mixed
-{{:tsc:laboratoare:ic-lab8-testing-approaches.png?600|}}
-=== Big-Bang ===
-Strategia "Big Bang" constă în testarea simultană a tuturor componentelor aplicației, astfel încât să 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. Această abordare prezintă un efort mai redus de planificare, dar este practică doar pentru sisteme de dimensiuni și 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 în 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 combinație a abordărilor "Top-Down" și "Bottom-Up". În această abordare, focusul este axat pe testarea unui layer al aplicației, integrând atât module de nivel superior, cât și module de nivel inferior.
-==== Exerciții ====
 <note warning>
@@ Line 167: / Line 146: @@
 <code>
+pip install pytest
 pip install requests
 </code>
@@ Line 183: / Line 163: @@
 După ce a fost realizată testarea unitara a modulelor aplicației (endpoints, baze de date, s.a.), trebuie să fie validată interacțiunea dintre acestea. Astfel, se dorește să se testeze ca operațiile pe task-uri descrise mai sus se execută cu succes.
-  * Implementați un test de integrare pentru operația de creare a unui task.
+  * 1. Implementați un test de integrare pentru operația de creare a unui task.
-<note tip>**Hint**: validarea creării unui task presupune 2 request-uri, unul de **PUT** și altul de **GET**, testând interacțiunea dintre clientul web, endpoint-ul web și baza de date în care se stochează task-urile.</note>
+<note tip>**Hint**: Validarea creării unui task presupune 2 request-uri, unul de **PUT** și altul de **GET**.
-<note tip>**Verificare**: validați că request-urile întorc codurile de status **HTTP** corecte (**200** în cazul lui **PUT** și **GET**) și că body-ul răspunsului primit este cel așteptat (în cazul lui **GET**, json-ul din body-ul primit ca răspuns trebuie să conțină task-ul introdus prin acțiunea **PUT**: //content//, //user_id//, //is_done//). </note>
-<note tip> **Atenție**: task_id-ul este generat random server-side, astfel că task-id-ul trimis prin operația de **PUT** in create_task este irelevant, iar răspunsul request-ului create_task va conține task-id-ul generat.</note>
-  *  Implementați un test de integrare pentru operația de modificare a unui task.
+Validați că request-urile întorc codurile de status **HTTP** corecte (**200** în cazul lui **PUT** și **GET**) și că body-ul răspunsului primit este cel așteptat (în cazul lui **GET**, json-ul din body-ul primit ca răspuns trebuie să conțină task-ul introdus prin acțiunea **PUT**: //content//, //user_id//, //is_done//).
-  * Implementați un test de integrare pentru operația de listare a 3 task-uri.
+Task_id-ul este generat random server-side, astfel că task-id-ul trimis prin operația de **PUT** in create_task este irelevant, iar răspunsul request-ului create_task va conține task-id-ul generat.</note>
-<note tip>**Hint**: Creați 3 task-uri sub același user_id, apoi validați că operația de listare întoarce 3 task-uri.</note>
+  * 2. Implementați un test de integrare pentru operația de modificare a unui task.
-<note tip>**Sugestie**: Încercați să generați user_id-uri unice, altfel există șansa ca operația de listare să vă întoarcă task-uri create de colegii voștri. Pentru a genera id-uri unice, puteți folosi modulul de python **uuid**. </note>
+  * 3. Implementați un test de integrare pentru operația de listare a 3 task-uri.
+<note tip>**Hint**: Creați 3 task-uri sub același user_id, apoi validați că operația de listare întoarce 3 task-uri.
+Încercați să generați user_id-uri unice, altfel există șansa ca operația de listare să vă întoarcă task-uri.</note>
+  * 4. Implementați un test de integrare pentru operația de ștergere a unui task
-  * Implementați un test de integrare pentru operația de ștergere a unui task.
 <note tip>**Hint**: Trebuie să validați că după operația de ștergere, un task nu poate fi obținut prin **GET**.</note>
+  * 5. Implementați câte un test care verifică comportamentul API-ului atunci când se încearcă accesarea (**GET**), modificarea (**UPDATE**) sau ștergerea (**DELETE**) unui task inexistent.
+<note tip>**Hint**: Pentru fiecare operație folosiți un task id generat unic pentru a simula un task inexistent.
+Pentru **UPDATE** API-ul răspunde cu 200 și creează task-ul dacă nu există deja, puteți verifica ulterior cu **GET**.</note>
+  * 6. Implementați un test care verifică comportamentul API-ului **create_task** cu date invalide.
+<note tip>**Hint**: Puteți folosi un string pentru completarea câmpului is_done. Folosiți-vă de documentație pentru a valida codul de eroare.</note>

Informații

Teme

Proiect 2025

Cursuri

Laboratoare

Arhiva

Arhivă Laboratoare

tsc/laboratoare/laborator-08.1745357138.txt.gz · Last modified: 2025/04/23 00:25 by ionut_vladut.pasat

Show page Old revisions

Media Manager Back to top