Nivele de testare

Test design
INDRECAN SORINA
AGENDA
NIVELURI DE TESTARE
TEST DESIGN
 NIVELURI DE TESTARE
Component Testing Integration Testing System Testing
 Niveluri de testare
Component Testing (Unit Testing)
Este prima ramura a procesului de testare
Se face de catre programatori deoarece presupune cunoasterea logicii interne si a codului aplicatiei
Are ca obiectiv depistarea existentei unor defecte la nivel de unitate functionala(functie,metoda)

Avantaje
Dimensiunea componentelor este suficient de mica pentru a permite ulterior localizarea si eliminarea intr-un
timp acceptabil bugurile care au fost gasite
Dimensiunea mica a componentelor permite generarea sistematica a unor cazuri de testare care sa acopere
principalele buguri care ar putea sa apara
 Niveluri de testare
Dezavantaje
Utilizarea gresita a parantezelor
Nume gresite ale obiectelor programului
Compararea unor date de tipuri necompatibile
Lipsa initializarii sau initializare gresita
Utilizarea unei precizii insuficiente
Utilizarea gresita a unor operatori
 Niveluri de testare
Integration Testing
Testeaza interfata intre componente pentru a pune in evidenta defecte in transferul de informatie intre
componentele aplicatiei

Abordari ale testarii de integrare:

Incremental integration
Top-down integration
Bottom-up integration
Regression testing
Smoke testing
Sandwich integration

or more info: https://www.softwaretestingmaterial.com/integration-testing/#How-To-Write-Integration-Test-Cases

 Niveluri de testare
Incremental integration
 Fiecare modul, adică M1, M2, M3, etc. sunt testate individual ca
parte a unit testing-ului;

 Modulele sunt combinate treptat, adică unul câte unul și testate

pentru o interacțiune de succes În Fig2, modulul M1 și modulul
M2 sunt combinate și testate;

 În Fig3, modulul M3 este adăugat și testat;

 În Fig4, Modulul M4 este adăugat și testarea se face pentru a vă

asigura că totul funcționează împreună cu success;

Restul modulelor sunt, de asemenea, adăugate incremental la fiecare

etapă și testate pentru o integrare reușită
 Obiective

Asigurarea că diferitele module funcționează împreună cu succes după integrare.

Identificarea defectele mai devreme și în fiecare fază. Acest lucru oferă dezvoltatorilor un avantaj pentru a identifica unde
se află problema. Chiar dacă integration testing al M1 și M2 este integrată cu succes, dar când se adaugă M3, testul
eșuează acest lucru îl va ajuta pe dezvoltator în rezolvarea problemei.

Problemele pot fi rezolvate în faza timpurie, fără o reelaborare prea mare și cu costuri mai mici.
 Niveluri de testare
Top-down integration

Este o varianta a integrarii

incrementale in care se
porneste de la programul
principal si se adauga mereu
componente de pe nivelele
imediat inferioare pana cand
tot programul este testat.
Se pot deriva urmatoarele scenario de testare:

Test Case 1:
 Modulul L și modulul O vor fi integrate și testate

Test Case 2:
 Module L, O and P will be integrated and tested

Test Case 3:
 Module L, O, P and R will be integrated and tested.
Sa intelegem schema de mai sus:

Module: Website Login aka L

Module: Order aka O
Module Order Summary aka OS (Not yet developed)
Module: Payment aka P
Module Cash Payment aka CP
Module Debit/Credit Payment aka DP (Not yet developed)
Module Wallet Payment aka WP (Not yet developed)
Module: Reporting aka R (Not yet developed)
Expunerea timpurie a defectelor de Modulele semnificative sunt testate târziu
arhitectură. în ciclu.

Prezintă funcționarea unei aplicații în Este foarte dificil să scrieți condițiile de

ansamblu în fazele incipiente și ajută la testare.
dezvăluirea timpurie a defectelor de
proiectare.

Principalele puncte de control sunt testate

din timp.
 Niveluri de testare
Bottom-up integration

Este o varianta a integrarii

incrementale in care se
porneste de la componentele
situate pe cele mai de jos
nivele in structura programului

For more info:

https://www.professionalqa.com/bottom-up-approach
Se pot deriva urmatoarele scenarii de testare:

Test Case 1:
Ø Unit testing pentru modulele Practical si Theory

Test Case 2:
Ø Integration testing pentru mărcile Marks-Practical-
Theory

Test Case 3:
Ø Integration testing pentru modulele Percentage-
Marks-Practical-Theory

Test Case 4:
Ø Unit testing pentru modulul Sports Grade

Test Case 5:
Ø Integration testing pentru modulele Rank-Sports
Grade-Percentage-Marks-Practical-Theory
Această metodologie este foarte utilă pentru
aplicațiile în care se folosește modelul de proiectare
de bottom-up;
Este mai ușor să creezi condiții de testare în
abordarea bottom-up;
Defectele de proiectare sunt surprinse în etapa
ulterioară;
În această abordare, nu avem aplicație funcțională
până la crearea ultimului modul;

A începe testarea la nivelul inferior al ierarhiei

înseamnă testarea modulelor critice sau a
funcționalității la o etapă timpurie. Acest lucru ajută
la descoperirea timpurie a erorilor;

Defectele de interfață sunt detectate în stadiu

incipient
 Niveluri de testare
Sandwich integration

Este o varianta a integrarii incrementale in care se combina cele doua metode de integrare prezentate
anterior pentru a mari eficienta testarii prin cresterea paralelismului in operatiile de testare.
Se pot deriva urmatoarele scenarii de testare:

Test Case 1:
Ø Testare A, X, Y și Z individual - în cazul în care testul
A se află sub testul stratului superior și testul X, Y
și Z se află sub teste strat inferior

Test Case 2:
Ø Testare A, G, H si I

Test Case 3:
Ø Testare G, X si Y

Test Case 4:
Ø Testare Z

Test Case 5:
Ø Testare A, G, H, I, X, Y, si Z

More info: https://www.professionalqa.com/sandwich-testing

Este foarte benefic pentru un proiect mare care are Înainte de unificarea modulelor, subsistemele și
diverse subproiecte; interfețele lor nu sunt testate în detaliu ;

Metodologia de testare top-down și bottom-up se Cost mai mare datorită implicării atât a metodologiei
poate derula cot la cot; de testare top-down cât și bottom-up ;

Acest tip de testare nu este recomandat pentru un

sistem în care modulele sunt extrem de inter-
dependente;
 Niveluri de testare
Regression Testing
Este un proces prin care se verifica daca o modificare introdusa intr-o componenta, indiferent de cauza,
nu afecteaza functionalitatea acesteia sau a intregului program.
Setul de teste de regresie contine trei clase de teste:
Teste aditionale orientate pe anumite functii realizate de program
Teste care sa verifice toate functiile realizate de program
Teste concentrate pe componentele modificate
 Niveluri de testare
Smoke Testing

Acest tip de test are ca scop sa puna in evidenta daca un produs este functional inainte de a trece la
realizarea unor teste detaliate
In hardware testul consta in a pune sub tensiune un circuit nou sau in care tocmai s-a inlocuit sau
reparat o componenta
In software termenul descrie procesul de validare a modificarilor de cod inainte de a trece la
executarea setului de teste propuse pentru programul respectiv.
 Test Design
Un test case este un set care contine urmatoarele:
Valori de intrare
Executarea unor preconditii
Pasi
Expected results general sau pentru fiecare pas in parte

Test Design – reprezinta o colectie de test cases care sunt special scrise pentru o functionalitate a
programului
Un test design nu are un numar minim sau maxim pentru cate teste ar trebui sau trebuie sa contina
Test Design vs Test
Case
Test Design
Exemplu test design:

◦ Registration flow.doc
◦ Login flow.doc
 Test Design
Exercitiu:

Alege un obiect pentru care trainerul tau sa se gandeasca la 3 test cases si mai departe sa le scrie
dupa structura unui test case
Test Design
Exercitiu:

Obiect pentru test design: ROBINET

 Test Design
Exercitiu:

Fiecare persoana din sala isi alege un obiect

Il noteaza in caiet
Se gandeste la 5 test cases
Scrie 2 test cases dupa structura unui test case

TEMA: RAMAN DE FACUT RESTUL TEST CASES + ALEGEREA UNUI ALT OBIECT SI SCRIEREA A 3 TEST
CASES PENTRU OBIECTUL NOU ALES