6.3.

Tehnici de testare white-box

- baza pentru tehnici WB = codul sursa al programului => tehnici de

testare bazate pe cod sau tehnici structurale
- codul sursa trebuie sa fie disponibil (posibila adaugare de cod)

- ideea generica: executia fiecarei parti a codului, cel putin o data.

- identificarea cazurilor de test orientate pe flux, prin analiza
logicii (diagramei) programului, urmata de executia lor.
- rezultatele asteptate ar trebui determinate folosind specificatiile
si nu codul.
- tehnicile wb - concentrare pe declaratiile programului.
obiectiv primar realizarea acoperirii declaratiilor in timpul
testarii (executarea tuturor declaratiilor in program)
 Caracteristici

- Structura programului este examinata

in detaliu la nivelul codului - caz de
test
- in timpul executiei cazurilor de test,
este analizata executia interna a
programului si iesirea (PoO in
interior)
- posibila interventia in program dar
in situatii speciale (teste negative
daca interfetele modulului nu sunt
capabile sa initieze defecte
provocate) PoC in interior
PoO- punct de observare - Testare structurala structura
PoC punct de control programului (ierarhia
componentelor, flux de control si flux
de date)
Tehnici de proiectare a cazurilor de test wb:

- testarea si acoperirea declaratiilor

- testarea si acoperirea deciziilor/ramificatiilor
- testarea conditiilor
- acoperirea conditiilor
- testarea si acoperirea conditiilor multiple
- testarea determinarii conditiilor
- testarea si acoperirea cailor
6.3.1. Testarea si acoperirea declaratiilor

- analiza se refera la fiecare declaratie a programului

- cazul de test poate executa o parte minima predefinita din declaratii sau
toate declaratiile obiectului.
- primul pas: translatarea codului in graf de flux de control (specificarea
mai usoara a elementelor de control care trebuie acoperite).
- in graf, declaratiile - reprezentate ca noduri , iar fluxul de control
dintre declaratii conexiuni
- declaratiile fara ramificatii (neconditionale) sunt ilustrate ca un singur
nod
- declaratiile conditionale (IF, CASE) si buclele (WHILE, FOR) au mai
multe ramificatii care ies din nod
- dupa executia cazurilor de test trebuie verificat ce declaratii au fost
executate.
- Dupa ce nivelul de acoperire a fost realizat, testul este considerat
suficient si se va termina
- Toate instructiunile trebuie executate dificil de declarat ca
instructiunile neexecutate sunt corecte
Cazuri de test
- toate nodurile pot fi acoperite de un
singur caz de test
- ordinea in care caile grafului
trebuie parcurse : a,b,f,g,h,d,e=>
toate declaratiile au fost executate o
data
- exista si alte combinatii => cost
minimizat (nr minim de cazuri)
- Rezultatele asteptate si
comportamentul asteptat al
programului trebuie stabilit din
specificatii
- dupa executie, se compara
rezultatele asteptate cu cele actuale
si cu comportamentul programului
in vederea detectarii defectelor
 Criteriul de terminare a testului
Acoperirea declaratiilor (C0) = (nr de declaratii executate/nr de
declaratii totale ) *100%
Criteriu foarte slab
Totusi, acoperirea totala 100% este dificil de realizat (daca apar
conditii de exceptie in program si care nu pot fi declansate in
timpul executiei testului)
 6.3.2. Testarea si acoperirea deciziilor/ramificatie

Criteriu mai avansat pentru testare wb - acoperirea ramificata a grafului

fluxului de control
- considerarea ramificatiilor in graf => executia deciziilor (nu a fiecarei
declaratii)
- Rezultatul deciziei => ce declaratie este executata la pasul urmator
- Testarea trebuie sa asigure ca fiecare decizie este executata cu 2
rezultate posibile: adevarat, fals
- Nu este important daca o declaratie IF nu are partea de ELSE; ea
trebuie executata oricum
- Acoperirea ramificata necesita testarea fiecarui rezultat al deciziei:
- In declaratii IF, se testeaza ambele THEN si ELSE
- In declaratii CASE, se testeaza toate posibilitatile si variantele de test
(cazuri)
- Pentru bucle: se testeaza executia corpului buclei, dar si neefectuarea
buclei si revenirea la inceputul buclei
 Cazuri de test
Teste aditionale necesare daca toate ramurile fluxului de control
trebuie executate in timpul testarii
Pentru acoperire 100% a declaratiilor este suficient un caz de test
care cuprinde urmatoarea ordine a ramurilor: a,b,f,g,h,d,e
Ramurile c,i,k nu au fost executate in acest test.
c, k sunt ramurile goale ale unei conditii (IF), iar i reprezinta
intoarcerea catre inceputul buclei. Sunt necesare 3 cazuri de test:
a,b,c,d,e
a,b,f,g,i,g,h,d,e
a,k,e
- Cele 3 cazuri => acoperirea totala a conexiunilor din graful de control
au fost testate toate fluxurile de control din codul sursa

- unele conexiuni au fost executate de mai multe ori => desi pare
redundant, nu pot fi evitate intotdeuna executiile multiple

- ramurile a si e executate in fiecare test (nu exista alta alternativa)

- Pentru fiecare caz de test - trebuie determinate in plus fata de
preconditii si post-conditii, rezultate asteptate si comportament
asteptat si comparate cu rezultatele si comportamentul actual.
- Este de dorit sa se retina ce ramura a fost testata in fiecare caz de test
=> util in gasirea defectelor (ex, cod lipsa in ramuri vide)
 Definirea criteriului de terminare a testarii

Acoperirea ramificatiilor (acoperirea C1) =

= (nr de ramuri executate/nr total de ramuri)*100%
- calculul se aplica doar cand o ramura este executata
- frecventa executiei nu este relevanta (ramurile a si e sunt executate
de 3 ori, cate o data pentru fiecare caz)
- daca se executa doar primele 3 teste, ramura k nu este testata=> din
10 ramuri, doar 9 sunt executate 9*100/10 = 90%
- comparatie cu acoperirea declaratiilor: acoperire declarativa 100%
dupa primul caz de test
- in functie de importanta programului si de riscul de defect asteptat,
criteriul de terminare a testelor poate fi definit diferit (ex, acoperirea
de 85% poate fi suficienta pentru o componenta a unui proiect, in timp
ce pentru un alt proiect ar fi necesara o acoperire de 100%)=> costul
testarii este mai mare pentru necesitati de acoperire mai mari.
 Valoarea tehnicii

- testarea necesita executia mai multor teste decat in cazul

declaratiilor
- permite detectia codului lipsa in ramuri vide
- acoperire a ramurilor 100% => acoperire declarativa 100% (nu si
invers) => criteriu mai puternic
- cele 2 tehnici de acoperire sunt inadecvate pentru sisteme orientate
pe obiecte , deoarece fluxul de control al functiilor in clase este de
regula redus si nu foarte complex
- complexitatea in sisteme OO - relatii intre clase => criterii de
acoperire suplimentare - date de acoperire utilizate pentru detectia
metodelor sau programelor neapelate.
6.3.3.Testarea si acoperirea conditiilor

- acoperirea ramificatiilor considera doar valorile logice ale rezultatelor

unei conditii (adev, fals)
- pe baza acestei valori se decide care ramura este aleasa si care declaratie
urmeaza sa se execute in program.
- Daca decizia este bazata pe mai multe conditii conectate prin operatori
logici => complexitatea conditiei trebuie sa fie considerata in testare
- Scopul testarii bazate pe conditii: determinarea unei conditii partiale
(atomice) din test sa adopte atat o valoare adevarata cat si falsa.
- o parte atomica a unei conditii: conditie care nu contine operatori
logici (AND, OR, NOT) , ci cel mult simbolurile relationale > sau =.
- o conditie din codul sursa al programului de testat poate cuprinde mai
multe conditii partial atomice
 Exemple de conditii combinate:

X>3 OR y<5
Scop: fiecare parte atomica a conditiilor este evaluata o data pentru
fiecare valoare logica.
Testul x=6 si y=8 => adevarat pentru prima parte a conditiei (x>3)
si valoarea fals pentru a doua parte a conditiei (y<5).=> Valoarea
logica a conditiei complete este adevarat
Testul x=2 si y=3 => fals pentru prima si adevarat pentru a doua
=> Valoarea logica a conditiei complete este adevarat
Desi ambele parti ale conditiei au avut valori diferite=> rezultatul
este acelasi pentru ambele combinatii
=> Criteriul bazat pe conditii este mai slab decat criteriile anterioare
pentru ca nu este necesar ca valorile logice diferite ale rezultatelor
conditiilor complete sa fie incluse in test
 Testarea si acoperirea conditiilor multiple
Necesita ca toate combinatiile adevarat-fals ale conditiilor atomice
sa fie aplicate cel putin o data.
Trebuie construite toate variantele, daca este posibil
Exemplu (continuare): 4 combinatii de cazuri de test sunt posibile
cu datele alese pentru cele doua parti atomice ale conditiilor (x>3,
y<5)
X=6(A), y=3(A), x>3 OR y<5 (A)
X=6(A), y=8(F), x>3 OR y<5 (A)
X=2(F), y=3(A), x>3 OR y<5 (A)
X=2(F), y=8(F), x>3 OR y<5 (F)
Conditia completa => ambele valori logice => testarea cu
conditii multiple indeplineste criteriile acoperirii declaratiilor
si ramurilor
- Accesibil, dar foarte costisitoare datorita numarului mare de
conditii atomice => crestere exponentiala a combinatiilor
posibile
Problema ! Nu toate combinatiile dec conditii sunt intotdeauna
implementatbile prin date de test

Exemplu: conditia combinata x>=3 AND x<5

- nu toate combinatiile cu valori corespunzatoare ale lui x pot fi realizate
deoarece partile conditiei sunt dependente
X=4: x>=3(A), x<5(A), x>=3 AND x<5 (A)
X=8: x>=3(A), x<5(F), x>=3 AND x<5 (F)
X=1: x>=3(F), x<5(A), x>=3 AND x<5 (F)
X=?: x>=3(F), x<5(F), imposibil pentru ca x ar trebui sa fie mai mic
decat 3 si mai mare decat 5, simultan

Testarea determinarii conditiilor elimina problema de mai sus => nu

toate combinatiile trebuie considerate
- totusi, trebuie considerate toate combinatiile posibile de valori logice
cand modificarea valorii logice a unei conditii atom duce la
modificarea valorii logice a intregii conditii
- cazurile de test in care rezultatul nu depinde de schimbarea unei conditii
atomice nu trebuie proiectat
 Ex (continuare) - cazuri:
1) x=6 (A), y=3(A), x>3 OR y<5 (A)
2) X=6(A), y=8(F), x>3 OR y<5 (A)
3) x=2 (F), y=3(A), x>3 OR y<5 (A)
4) x=2 (F), y=8(F), x>3 OR y<5 (F)
Caz 1 - daca valoarea logica este calculata gresit pentru prima parte
de conditie (este implementata o conditie incorecta), atunci
defectul poate schimba valoarea logica a primei conditii atom
din A in F. => rezultatul conditiei complete nu se modifica
- la fel pentru a doua parte de conditie
Pentru prima combinatie rezultatele incorecte ale fiecarei parti
de conditie sunt mascate din cauza ca ele nu au efect asupra
rezultatului conditiei complete => defectele nu devin vizibile =>
se renunta la cazul 1.
Caz 2. daca valoarea logica a primei conditii este calculata gresit ca
F => rezultatul total se schimba din A in F => defect vizibil
deoarece valoarea conditiei complete s-a schimbat
Caz 3 la fel ca la caz 2 pentru a doua conditie
Caz 4 detectia unei implementari incorecte pentru ca valoarea
conditiei totale se modifica
 Numar mic de cazuri de test :
pentru fiecare combinatie logica a conditiilor trebuie sa se decida
care teste trebuie considerate (sunt sensibile la defecte) si pentru ce
combinatie defectele sunt mascate.
Nu se considera combinatiile care mascheaza defecte=> numar
mai mic de teste

Proiectarea cazurilor de test:

- realizarea unei conexiuni intre datele de intrare si rezultatele
unei conditii partiale sau totale (care date conduc la anumite
tipuri de rezultate)
- Ce parti ale programului trebuie executate dupa decizie.
- Trebuie definite in avans rezultatele asteptate si
comportamentul asteptat al programului (pentru a vedea daca
programul se comporta corect sau nu)
Criteriul de terminare a testelor :
- raportul dintre valorile logice ale conditiilor executate si al celor
necesare
- complexitatea conditiei in codul sursa => incercarea unei verificari
complete (100%)
- daca nu exista expresii cu conditii complexe
Valoarea tehnicii:
- daca in codul sursa apar conditii complexe => trebuie testate intensiv
(teste complexe) pentru a descoperi erori posibile => tehnica
costisitoare
- solutie: se pot imparti conditiile combinate complexe intr-o structura
arborescenta de conditii simple incuibate si apoi sa se execute un test
de acoperire a ramificatiilor pentru aceste secvente de conditii
Dezavantaj al tehnicii bazate pe conditii: trebuie verificate expresii
booleene doar in cadrul declaratiilor (ex, IF).
6.3.4. Testarea si acoperirea cailor
Pana acum: determinarea cazurilor de test a implicat declaratiile si
ramificatiile fluxului de control si complexitatea conditiilor.
Daca obiectul de test contine bucle sau repetitii => executia tuturor
cailor diferite prin program
Exemplu: bucla DO-WHILE este executata
cel putin o data.
Conditia WHILE se decide daca
bucla trebuie repetata
In testul de ramificatie - 2 cazuri
(unul fara intoarcere a,b,f,g,h,d,e
Unul cu bucla a,b,f,g,i,g,h,d,e)
De regula, o bucla este repetata de mai multe ori. Secvente posibile de
ramificatii prin graf :
A,b,f,g,i,g,ig,h,d,e
A,b,f,g,i,g,i,g,i,g,h,d,e
A,b,f,g,i,g,i,g,i,g,i,g,h,d,e
Exista un numar indefinit de cai in graf
O cale - descrie ordinea posibila a partilor unui program
Ramurile vazute ca independente unele de altele
Caile considera dependente intre ramuri (ex, bucle)
Exemplu functia calculate_price() -sistemul VSR
- cazuri de test abilitatea de acoperire a codului sursa => executia
partilor de program
- acoperire 100%=> in timpul executiei toate ramurile au fost
executate cel putin o data
 Testele => executia urmatoarelor
muchii in graf:
Test 01: a,b,c,j,k,l,n
Test 02: a,b,c,j,k,l,n
Celelalte muchii nu au fost
executate => acoperirea celor
2 teste 43% (6/14)
Test 02 nu aduce nicio
imbunatatire acoperirii nu
este necesar pentru
acoperirea ramificatiilor
Pentru a creste acoperirea=>
teste aditionale
 Test03 - ramurile : a,d,g, h, i,j,m,n
Test 04 ramurile : a,b,c,j,m,n
=> creste acoperirea ramurilor 12 /14 = 86%
Inainte de a acoperi muchiile neluate in considerare prin teste
aditionale, conditiile declaratiilor IF trebuie analizate in detaliu (codul
sursa).
Executia muchiei e => (extras >=3) falsa si (extras>=5) adevarata =>
niciodata nu este indeplinita => defect in codul sursa
 Relatii intre masuri
Relatii intre acoperirea cu declaratii, ramuri si cai
Programul 3 declaratii IF 2 incuibate, 1 separata
Toate declaratiile (nodurile) sunt parcurse de secventele de
muchii:
A,b,c,j,k,l,n
A,d,e,f,i,j,k,l,n
A,d,g,h,i,j,k,l,n
- Acoperire 100% dar nu toate ramurile au fost acoperite (ex,
m) secventa a,b,c,j,m,n => ar trebui utilizata pentru a inlocui
primul caz de test => acoperire 100%
- Exista posibilitatea de a parcurge graful diferit => cai in graf
=> cai neparcurse : a,d,e,f,i,j,m,n si a,d,g,h,i,j,m,n
- Total : 6 cai in graf (3 inainte de nodul j combinate cu 2 dupa
nodul j) combinate arbitrar
 Concluzie
Baza pentru tehnici wb = codul sursa
Teste alese in functie de complexitatea structurii codului
Testare de nivel scazut
Suprapunerea testelor - aplicata testelor de nivel superior (in
timpul testelor de integrare se poate evalua procentul de module ,
componente sau clase care sunt testate => suprapunere
Absenta codului sursa=> alte strategii de testare
6.4. Testare bazata pe experienta

- In plus fata de abordarea sistematica => poate fi utila pentru detectarea

defectelor care nu pot fi depistate prin teste sistematice
- Abilitati, experienta, cunostinte se bazeaza pe "ghicirea" erorilor
des utilizata in practica
- Teste de explorare - cand documentele sunt slab specificate sau nu
exista (eventual doar programul exista) - cand timpul este limitat
- Activitatile de test executate aproape in paralel
- Nu se face o planificare a activitatilor de test
- Explorarea unor functii ale unui program => executia si analiza
rezultatelor catorva (putine) cazuri de test => determinarea
comportamentului (necunoscut)
- Alte informatii => determinarea unui alt caz de test pas cu pas
colectarea cunostintelor despre programul in curs de testare =>
informatii despre modul de functionare a programului, ce
probleme pot aparea, ce cerinte ar trebui indeplinite
- => ce tehnici ar putea fi aplicate in timpul ramas
 Teste rapide - restrictionarea testarii exploratorii la anumite elemente
ale unui program => elementele sunt mai departe impartite in parti
mici
Intrebari care pot aparea: De ce? Care este scopul testarii?Ce
urmeaza sa fie testat?Cum? Care metoda de testare trebuie utilizata?
Care problema ar trebui depistata?
Ideile generale ale testelor de explorare:
rezultatele unui test influenteaza proiectarea si executia testelor
urmatoare
in timpul testarii se creaza un model "mental" al programului
testat cum lucreaza programul, cum se comporta sau cum ar
trebui sa se comporte
testul este rulat conform acestui model=> gasirea unor aspecte
suplimentare despre program
Teste intuitive - nu folosesc metoda BB sau WB - nu se bazeaza
exclusiv nici pe cerinte, nici pe codul sursa
- pentru testarea de nivel inalt