Sunteți pe pagina 1din 96

Ingineria programrii

12. Faza de testare (I)

Florin Leon
Universitatea Tehnic Gheorghe Asachi din Iai
Facultatea de Automatic i Calculatoare
http://florinleon.byethost24.com/curs_ip.htm
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Make it idiot-proof and


someone will make a better idiot.

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (I)


1. Introducere
2. Tipuri de testare
3. Inspeciile codului
4. Testarea de tip cutie neagr
5. Testarea de tip cutie alb
6. Testarea incremental i neincremental
7. Testarea top-down i bottom-up
8. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (I)


1. Introducere
2. Tipuri de testare
3. Inspeciile codului
4. Testarea de tip cutie neagr
5. Testarea de tip cutie alb
6. Testarea incremental i neincremental
7. Testarea top-down i bottom-up
8. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Verificare i Validare

Verificare

Construim corect produsul?


Se refer la dezvoltarea produsului

Validare

Construim produsul corect?


Se refer la respectarea specificaiilor, la utilitatea
produsului

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Scopurile V & V

Verificarea i validarea trebuie s stabileasc


ncrederea c produsul este potrivit pentru
scopul su
Aceasta nu nseamn c produsul este lipsit de
defecte
Doar c produsul trebuie s fie suficient de bun
pentru utilizare

Suficient de bun poate nsemna... (slide-ul urmtor)

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Evaluarea unui produs


software

Depinde de scopul produsului, de ateptrile


utilizatorilor i factorii de pia

Funcionalitatea programului
Nivelul de ncredere depinde de ct de critic este sistemul
pentru utilizatori
Ateptrile utilizatorilor
Utilizatorii pot avea grade diferite de ateptri pentru
anumite tipuri de produse software
Mediul de afaceri
Lansarea rapid pe pia a unui produs poate fi uneori mai
important dect gsirea defectelor n program
7

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea unui program

Evideniaz prezena erorilor i nu absena lor

Este singura tehnic de validare pentru cerine


non-funcionale, deoarece programul trebuie
lansat n execuie pentru a i se analiza
comportamentul

Este utilizat de obicei alturi de verificarea


static pentru o siguran ct mai mare

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Terminologie (IEEE)

Eroare
O aciune uman care are ca rezultat un defect n produsul
software
Defect (engl. fault)
Consecina unei erori n produsul software
Un defect poate fi latent: nu cauzeaz probleme ct timp nu apar
condiiile care determin execuia anumitor linii de cod
Defeciune (engl. failure)
Manifestarea unui defect: cnd execuia programului ntlnete
un defect, acesta provoac o defeciune
Abaterea programului de la comportamentul ateptat
Bug: termen colocvial utilizat deseori ca sinonim pentru defect
9

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea defectelor i
testarea de validare

Testarea defectelor

Teste proiectate s descopere prezena defectelor n


sistem
Un test de succes este cel care descoper un defect

Testarea de validare

Intenioneaz s arate c produsul nu ndeplinete


cerinele
Un test de succes este cel care arat c o cerin nu
a fost implementat adecvat

10

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea i depanarea

Testarea defectelor i depanarea (engl. debugging)


sunt procese distincte
Testarea are ca scop stabilirea existenei defectelor
ntr-un program
Depanarea are ca scop localizarea i repararea
erorilor corespunztoare
Depanarea implic formularea unor ipoteze asupra
comportamentului programului, corectarea defectelor
i apoi re-testarea programului
11

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Asigurarea calitii

Testarea se refer la detectarea defectelor


Asigurarea calitii se refer la prevenirea lor

Trateaz procesele de dezvoltare menite s


conduc la producerea unui software de calitate
Include procesul de testare a produsului

Procesul de asigurare a calitii este mai


general dect procesul de testare

12

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (I)


1. Introducere
2. Tipuri de testare
3. Inspeciile codului
4. Testarea de tip cutie neagr
5. Testarea de tip cutie alb
6. Testarea incremental i neincremental
7. Testarea top-down i bottom-up
8. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea unitilor

O unitate (sau un modul) se refer de obicei


la un element atomic (clas sau funcie), dar
poate nsemna i un element de nivel mai
nalt: bibliotec, driver etc.
Testarea unei uniti se face n izolare

Pentru simularea apelurilor externe se pot utiliza


funcii externe fictive (engl. stubs)

14

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Programe schel

De multe ori sunt necesare aa-numitele schele,


adic programe special construite pentru stabilirea
mediului de test

Numai cnd mediul este realizat se poate executa o


evaluare corect
Programul schel stabilete stri i valori pentru structurile
de date i asigur funcii externe fictive
De obicei, programul schel nu are aceeai calitate ca
produsul software testat i adesea este destul de fragil
O schimbare mic n modulul testat poate determina
schimbri importante n programul schel
15

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea componentelor

Testeaz interaciunea mai multor uniti


Testarea este determinat de arhitectur

16

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea sistemului

Testarea sistemului testeaz aplicaia ca ntreg i este


determinat de scenariile de analiz
Aplicaia trebuie s execute cu succes toate scenariile pentru
a putea fi pus la dispoziia clientului
Spre deosebire de testarea intern i a componentelor, care
se face prin program, testarea aplicaiei se face de obicei cu
scripturi care ruleaz sistemul cu o serie de parametri i
colecteaz rezultatele
Testarea aplicaiei trebuie s fie realizat de o echip
independent de echipa de implementare
Testele se bazeaz pe specificaiile sistemului
17

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Cine face testarea?

Exist diferite preri privind rolurile n testare

Testarea unei componente cade n sarcina


programatorului acesteia i doar testarea
sistemului se face de o echip diferit
Testele sunt concepute pe baza experienei
programatorului
Testarea unei componente se face de ctre o
persoan diferit, iar depanarea se face de ctre
programatorul iniial
18

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testele de regresiune

engl. regression tests


Un test valid genereaz un set de rezultate verificate, numit
standardul de aur
Testele de regresiune sunt utilizate la re-testare, dup realizarea
unor modificri, pentru a asigura faptul c modificrile nu au introdus
noi defecte n codul care funciona bine anterior
Pe msur ce dezvoltarea continu, sunt adugate mai multe teste
noi, iar testele vechi pot rmne valide sau nu
Dac un test vechi nu mai este valid, rezultatele sale sunt modificate
n standardul de aur, pentru a se potrivi situaiei curente
Acest mecanism previne regresiunea sistemului ntr-o stare de
eroare anterioar
19

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea performanelor

O parte din testare se poate concentra pe


evaluarea proprietilor emergente ale
sistemului, cum ar fi:

ncrederea (meninerea unui nivel specificat de


performan)
Securitatea (persoanele neautorizate s nu aib
acces iar celor autorizate s nu le fie refuzat accesul)
Utilizabilitatea (capacitatea de a fi neles, nvat i
utilizat)

20

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea la ncrcare

Asigur faptul c sistemul poate gestiona un


volum ateptat de date, similar cu acela din
locaia destinaie (de exemplu la client)
Verific eficiena sistemului i modul n care
scaleaz acesta pentru un mediu real de
execuie

21

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea la stres

Solicit sistemul dincolo de ncrcarea maxim proiectat


Suprancrcarea testeaz modul n care cade sistemul

Deseori apar aici conflicte ntre teste. Fiecare test funcioneaz


corect atunci cnd este fcut separat. Cnd dou teste sunt rulate n
paralel, unul sau ambele teste pot eua

Sistemele nu trebuie s eueze catastrofal


Testarea la stres verific pierderile inacceptabile de date sau funcionaliti

Cauza este de obicei managementul incorect al accesului la resurse critice


(de exemplu memoria)

O alt variant, soak testing, presupune rularea sistemului pentru


o perioad lung de timp (zile, sptmni, luni)

n acest caz, de exemplu scurgerile nesemnificative de memorie se pot


acumula i pot provoca cderea sistemului
22

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea interfeei cu
utilizatorul

Majoritatea aplicaiilor din zilele noastre au interfee grafice cu


utilizatorul (GUI)

Testarea interfeei grafice poate pune anumite probleme

Cele mai multe interfee, dac nu chiar toate, au bucle de


evenimente, care conin cozi de mesaje de la mouse, tastatur,
ferestre etc.

Asociate cu fiecare eveniment sunt coordonatele ecran

Testarea interfeei cu utilizatorul presupune memorarea tuturor


acestor informaii i elaborarea unei modaliti prin care mesajele
s fie trimise din nou aplicaiei, la un moment ulterior

De obicei se folosesc scripturi pentru testare


23

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea utilizabilitii

Testeaz ct de uor de folosit este sistemul


Se poate face n laboratoare sau pe teren
cu utilizatori din lumea real

24

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (I)


1. Introducere
2. Tipuri de testare
3. Inspeciile codului
4. Testarea de tip cutie neagr
5. Testarea de tip cutie alb
6. Testarea incremental i neincremental
7. Testarea top-down i bottom-up
8. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Inspeciile codului

engl. code inspections, code reviews


Presupun citirea codului pentru a detecta erori
Echipa de inspecie are n general 4 persoane:

Moderatorul un programator competent


Programatorul cel care a scris codul inspectat
Designer-ul, dac este o persoan diferit de
programator
Un specialist n testare

26

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Activiti

Programatorul citete, instruciune cu


instruciune, logica programului

Ceilali participani pun ntrebri


Programatorul nsui poate descoperi cele mai
multe erori

Se caut n program cele mai ntlnite tipuri


de erori

O list de erori comune este prezentat n slide-ul urmtor

27

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

28

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Caracteristici (I)

Inspectorii detecteaz erorile, programatorul trebuie s


le corecteze
Dac sunt descoperite multe erori sau unele erori
necesit corecii substaniale, moderatorul stabilete o
nou inspecie dup corectarea lor
Erorile determinate pot conduce la modificarea
design-ului
De obicei, durata unei sesiuni de inspecie este de
90-120 de minute, cu o rat de 150 de instruciuni pe or

Dac programul este mai mare, se stabilesc mai multe sesiuni de


inspecie, organizate pe module
29

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Caracteristici (II)

Programatorul nu trebuie s fie defensiv, ci constructiv

Nu trebuie s vad inspecia ca pe un atac personal, ci ca pe o


modalitate de a crete calitatea muncii sale

Rezultatele inspeciei sunt confideniale


Programatorul primete reacii privind stilul de
programare, tehnicile i algoritmii folosii
Ceilali participani beneficiaz de pe urma expunerii la
un alt stil de programare
Identificarea timpurie a seciunilor celor mai predispuse
la erori ajut la sporirea ateniei acordate acestora n
faza de testare
30

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (I)


1. Introducere
2. Tipuri de testare
3. Inspeciile codului
4. Testarea de tip cutie neagr
5. Testarea de tip cutie alb
6. Testarea incremental i neincremental
7. Testarea top-down i bottom-up
8. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea cutie neagr

Se mai numete testare funcional


Se iau n considerare numai intrrile ntr-un
modul i ieirile dorite, conform specificaiilor
Structura intern a modulului este ignorat
Testarea exhaustiv nu este fezabil
Generarea aleatorie a cazurilor de test nu este
eficient
Optimul: detectarea unui numr maxim de
defecte cu un numr minim de cazuri de test
32

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Partiionarea claselor de
echivalen

O clas de echivalen (CE) este format din


intrrile pentru care comportamentul sistemului
este similar

De exemplu: lucrul cu ntregi o clas cu ntregi


pozitivi, alta cu ntregi negativi, eventual una cu 0

Divizarea domeniului de intrare n clase de


echivalen, astfel nct dac programul ruleaz
corect pentru o valoare din clas, va rula corect
i pentru celelalte valori din clas
33

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Clase de echivalen invalide

De obicei, pentru fiecare condiie a unei


intrri, se consider o clas de echivalen
valid i mai multe clase de echivalen
invalide

De exemplu: 0 < x < max

CE valid: o valoare n intervalul (0, max)


CE invalide: o valoare 0, respectiv o valoare max

34

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Clase de echivalen
pentru ieiri

Pentru fiecare tip de ieire, se estimeaz ce


intrri pot provoca situaiile respective

De exemplu rata dobnzii pentru care profitul unei


investiii este pozitiv, negativ sau 0

Dei sunt mai greu de identificat, cazurile de test


pentru clasele de ieire pot indica defecte
suplimentare fa de clasele de intrare

35

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Selecia cazurilor de test

Strategia 1

Fiecare test s acopere ct mai multe CE valide


Cte un test pentru fiecare CE invalid

Strategia 2

Un test s acopere cel mult o CE valid pentru


fiecare intrare
Cte un test separat pentru fiecare CE invalid
Necesit mai multe cazuri de test
36

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu

Un program cu 2 intrri: un ir de caractere s de


lungime N i un ntreg n
Ieirea: cele mai dese n apariii ale caracterelor lui s

37

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu

Strategia 1: un s cu lungimea mai mic dect N, coninnd litere


mari, litere mici, cifre i caractere speciale i n = 5 (EQ1 EQ6),
apoi cte un caz pentru IEQ1, IEQ2 i IEQ3

Strategia 2: cte un caz pentru fiecare clas de echivalen, de


exemplu un s cu cifre i n = 5 (EQ1, EQ6), apoi alte cazuri pentru
EQ2,... , EQ5 i cazuri separate pentru IEQ1, IEQ2 i IEQ3
38

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Analiza valorilor limit

De multe ori programele care funcioneaz corect pentru valorile


unei CE eueaz pentru valorile de la limita CE
Intrarea pentru un caz de test se alege dintr-o CE la limita
acesteia
Cazuri extreme
Cazurile pentru CE invalide se aleg tot n apropierea limitei
De exemplu: 0.0 x 1.0
Cazuri de test valide: 0.0 i 1.0
Cazuri de test invalide: -0.1 i 1.1
Pentru o list, trebuie testate primul i ultimul element
Pentru CE de ieire, se aleg intrri care determin o ieire la
limita CE, respectiv n afara sa
39

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Selecia cazurilor de test

Pentru n intrri, fiecare cu un domeniu de


definiie
Strategia 1

Se selecteaz valori limit diferite pentru o


variabil iar celelalte sunt meninute la valoarea
nominal

min-1, min, min+1, max-1, max, max+1

Plus un caz n care toate n intrri sunt la valoarea


nominal

6n + 1 cazuri de test
40

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu

Pentru 2 intrri X i Y sunt necesare 13 cazuri


de test

41

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Selecia cazurilor de test

Strategia 2

Se ncearc toate combinaiile posibile

6 valori de limit
1 valoare nominal
7n cazuri de test

42

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Graful cauz-efect

Tehnicile anterioare nu ajut la construirea


combinaiilor de teste

Considernd toate combinaiile valide, pentru n condiii de


intrare vom avea 2n cazuri de test

Graful cauz-efect determin selectarea


combinaiilor de intrare ntr-un mod sistematic
Cauz = o condiie distinct de intrare
Efect = o condiie distinct de ieire
Condiiile sunt binare (A/F) i pot fi combinate cu
operatorii: I, SAU, NOT
43

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu
negaie

44

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Tabelul de decizie

45

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Tipuri de defecte

Defecte uni-modale (engl. single-mode faults)

Implic o singur condiie

Program care nu tiprete corect pentru un anumit tip de imprimant


Program care nu calculeaz bine tarifele cnd cltorul e minor
Program de taxare pentru telefoane care nu calculeaz corect pentru
apelurile spre o anumit ar

Defecte multi-modale (engl. multi-mode faults)

Implic mai multe condiii

Program care nu calculeaz bine tarifele cnd cltorul e minor i


cltorete la business class i nu st un weekend la destinaie
Program de taxare pentru telefoane care nu calculeaz corect pentru
apelurile spre o anumit ar n timpul nopii
46

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea perechilor

Pentru defecte uni-modale

Se folosesc strategiile din partiionarea claselor de echivalent


Pentru n parametri cu m valori, numrul de teste n cazul cel mai
favorabil este m (putem testa toi parametrii ntr-un test, fiecare
cu valori diferite)

Pentru defecte multi-modale

Testarea tuturor combinaiilor nu este fezabil (nm cazuri de test)


Studiile au artat c majoritatea defectelor sunt indicate de
testarea perechilor de valori (majoritatea defectelor sunt
uni-modale sau bi-modale)
Pentru n parametri cu m valori, numrul total de perechi este
m m n (n - 1) / 2
Numrul de teste n cazul cel mai favorabil este ns m2
47

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu

9 3 = 27 combinaii
9 cazuri de test
se evit acoperirea unei
perechi de mai multe ori
48

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Cazuri speciale

Numite i error guessing


Depind de structurile de date i de experiena
testerului, pentru a detecta presupunerile
incorecte ale programatorului, cauzate n
general de specificaiile incomplete
Exemple:

La o mprire, numitorul este 0


Un fiier care trebuie citit este gol sau nu exist
Fiierul ncepe cu linii albe
Vectorul este deja sortat
49

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea bazat pe stri

Pentru aceleai intrri, sistemele cu stare produc ieiri


diferite la momente de timp diferite

Ieirile depind i de starea intern, nu numai de intrri

Starea depinde de intrrile anterioare

De exemplu sistemele secveniale

Modelul de stare conine:

Stri: impactul cumulat al tuturor intrrilor anterioare

Tranziii: schimbrile strilor ca rspuns la evenimente

Evenimente: intrrile sistemului

Aciuni: ieirile sistemului


50

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Selecia cazurilor de test

Testarea bazat pe stare este o testare de tip


cutie gri (engl. gray box)
Criterii:

Testele trebuie s acopere toate tranziiile din graf


Trebuie s execute toate perechile de tranziii
adiacente (intrarea ntr-o stare i ieirea din acea
stare)
Trebuie s execute toate cile simple (care nu conin
noduri repetate)

51

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu
Exemplu
Sistem de
sondaj pentru
studeni

Un student
rspunde la
ntrebri i apoi
vede rezultatele
sondajului
Rezultatele se
actualizeaz doar
dup 5 rspunsuri
Baza de date poate
cdea
52

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea claselor

Acoperirea complet a testului unei clase implic:

Testarea tuturor operaiilor asociate cu un obiect


Setarea i interogarea tuturor atributelor (cmpurilor)
unui obiect
Trecerea unui obiect prin toate strile posibile
Presupune testarea tuturor combinaiilor de valori
pentru cmpuri
Problem asemntoare cu testarea perechilor

Motenirea ngreuneaz proiectarea testelor de


clas, ntruct entitile care trebuie testate nu sunt
localizate
53

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea MM

Testare metod-mesaj
n fiecare metod, fiecare apel ctre alt metod
trebuie testat cel puin o dat
Dac o metod apeleaz alt metod de mai
multe ori, fiecare apel trebuie testat o singur
dat

54

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea perechilor de funcii

engl. function pair

Pentru toate secvenele posibile de execuii ale metodelor,


trebuie testate cele de lungime 2

Acest lucru se face de obicei pe baza unei diagrame de stri


a unui automat, care precizeaz succesiunile posibile de
apeluri

Pentru un program cu operaii grafice, exemple de perechi de


funcii pentru testare sunt:

Crearea unui dreptunghi i apoi calcularea ariei

Crearea a dou sau mai multe dreptunghiuri i apoi calcularea ariei

Crearea unui cerc i apoi crearea unui dreptunghi


55

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (I)


1. Introducere
2. Tipuri de testare
3. Inspeciile codului
4. Testarea de tip cutie neagr
5. Testarea de tip cutie alb
6. Testarea incremental i neincremental
7. Testarea top-down i bottom-up
8. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea cutie alb

Testarea cutie neagr trateaz funcionalitatea unui


modul

Testarea cutie alb trateaz funciile sau metodele la


un nivel sczut: fiecare funcie este testat

Aceste teste se mai numesc teste clear-box deoarece toate


detaliile sunt vizibile pentru test

Testarea cutie alb vizeaz acoperirea diferitelor


structuri ale programului

Se mai numete testare structural

57

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea fluxului de control

Graful fluxului de control: G

Noduri: blocuri de instruciuni executate mpreun


Arce: posibile transferuri de control
Cale: secven finit de noduri (n1, n2, ..., nk),
k > 1, astfel nct exist un arc (ni, ni+1) oricare ar
fi ni, cu excepia lui nk
Cale complet: o cale din nodul iniial (start) n
nodul final (exit)

58

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Acoperirea instruciunilor

Necesit ca fiecare instruciune s fie


executat cel puin o dat

Se mai numete criteriul tuturor nodurilor (all-nodes)


Nu este un criteriu foarte puternic

pentru cazul de
test {x=0}, eroarea
rmne nedetectat

59

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Acoperirea ramurilor

Necesit ca fiecare arc din graf s fie traversat cel puin o dat
Fiecare decizie trebuie evaluat ca A sau F
Criteriul acoperirii ramurilor 100% se mai numete criteriul tuturor
arcelor (all-edges)
Cramuri Cinstruciuni (all-edges all-nodes)

decizia poate fi
evaluat A sau F fr
a detecta eroarea

Funcia ar trebui s testeze c x este n [0,100].


Cazurile de test {x = 5, x = -5} evalueaz decizia la A sau F
60

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Acoperirea cilor

Un test mai general este acoperirea tuturor cilor


(all-paths)
Presupune executarea tuturor cilor posibile din graful
de control

Dificulti:

Cci Cramuri (all-paths all-edges)


Programele care conin bucle au un numr infinit de ci
Pot exista ci n graf pentru care s nu existe intrri
corespunztoare astfel nct cile respective s fie executate

Pentru un modul cu complexitatea ciclomatic M, se


recomand testarea a cel puin M ci distincte
61

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea fluxului de control

Niciuna din aceste metode nu este suficient


pentru detectarea tuturor erorilor

Dac din program lipsete o cale necesar pentru


testarea unei condiii, chiar dac sunt testate
toate cile existente, defectul nu va fi descoperit

62

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea fluxului de date

Graful def/use (definiie / utilizare)


def: definirea unei variabile

c-use: utilizarea computaional

x = 5;
a = x; read(x); write(x);

p-use: utilizarea predicativ (ntr-o decizie)

if (x > 0)

63

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea fluxului de date

Criterii:

all-defs: pentru fiecare definiie trebuie s existe un


c-use sau un p-use
all-p-uses: trebuie testate toate utilizrile predicative
ale unei definiii
all-c-uses: trebuie testate toate utilizrile
computaionale ale unei definiii
all-p-uses, some-c-uses
all-c-uses, some-p-uses
all-uses = all-p-uses + all-c-uses
64

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu

65

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu

all-edges:

(1, 2, 4, 5, 6, 7, 8, 9):
y negativ
(1, 3, 4, 5, 7, 9): y pozitiv
Calea (1, 2, 4, 5, 6, 7, 9)
este nefezabil: 1-2
nseamn c y este negativ,
deci din 7 nu se poate
merge n 9
Cazuri de test:

{x = 3, y = 1}
{x = 3, y = -1}
66

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu

all-defs:

Presupune cel puin


un c-use sau un p-use
(1, 2, 4, 5, 6, 5, 6, 7, 8, 9)
(1, 3, 4, 5, 6, 7, 9)
Cazuri de test:
{x = 3, y = 4}
{x = 3, y = -2}

67

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Relaiile dintre criterii


criteriu mai
puternic
de exemplu all-paths all-uses

criteriu mai
slab
68

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Acoperirea testului

Acoperirea testului este procentajul din produs verificat prin testare


n mod ideal, o acoperire de 100% ar fi excelent, ns este rareori
ndeplinit
De obicei, un test cu o acoperire de 90% este simpl, ns ultimele
10% necesit o perioad de timp semnificativ
Exemplu: testarea BIOS-ului IBM n anii 80

Pentru creterea performanelor, a fost plasat ntr-un ROM i deci


patch-urile pentru eventuale defecte erau imposibile
A necesitat testarea cu acoperire 100%
S-a creat un mediu de test, mult mai mare dect BIOS-ul
A aprut necesitatea testrii mediului de test!
A fost atins o acoperire de 100%, cu un cost foarte ridicat
Alternativa: ROM + EPROM pentru patch-uri
69

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Instrumente de acoperire

engl. coverage tools


Analizeaz codul surs i genereaz un test pentru fiecare
alternativ a firelor de execuie
Depinde de programator combinarea acestor teste n cazuri
semnificative care s valideze rezultatele fiecrui fir de execuie
De obicei, instrumentul de acoperire este utilizat ntr-un mod
oarecum diferit: el urmrete liniile de cod executate ntr-un test
i apoi raporteaz procentul din cod executat n cadrul testului
Dac acoperirea este mare i liniile surs netestate nu prezint
mare importan pentru calitatea general a sistemului, atunci nu
mai sunt necesare teste suplimentare
Exemple pentru programe .NET: NCover, PartCover .NET
70

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

NCover

71

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (I)


1. Introducere
2. Tipuri de testare
3. Inspeciile codului
4. Testarea de tip cutie neagr
5. Testarea de tip cutie alb
6. Testarea incremental i neincremental
7. Testarea top-down i bottom-up
8. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Ordinea modulelor

Ordinea n care sunt combinate modulele pentru


a rezulta programul complet afecteaz:

Forma cazurilor de test

Tipurile de instrumente de testare utilizate

Ordinea n care modulele sunt implementate i testate

Costul generrii cazurilor de test

Costul depanrii

73

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Tipuri de integrare

Integrarea neincremental

Abordarea clasic
Modulele sunt testate separat i apoi integrate
simultan, continundu-se cu testarea sistemului
Numit i model big-bang deoarece timpul de
testare crete mult

Integrarea incremental

Urmtorul modul care trebuie testat este combinat cu


modulele testate pn la acel moment
Poate fi top-down sau bottom-up
74

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Module driver i stub

Ambele tipuri de integrare


necesit pentru testare
module driver, care
simuleaz intrrile i/sau
module stub (din care se
pot apela funcii)
De exemplu: pentru B

Modul driver: A
Modul stub: E

A apeleaz funcii din B, C, D


B apeleaz funcii din E
D apeleaz funcii din F
75

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Comparaie (I)

Integrarea neincremental
necesit 5 module driver i
5 module stub
Integrarea incremental
necesit:

5 module driver i niciun


modul stub pentru abordarea
bottom-up
5 module stub i niciun modul
driver pentru abordarea
top-down
76

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Comparaie (II)

Testarea incremental detecteaz mai devreme incompatibilitatea interfeelor sau alte presupuneri incorecte din module

Depanarea este mai uoar n abordarea incremental

n testarea neincremental modulele nu se vd dect la sfrit


Un defect detectat la un moment dat este cauzat de adugarea
ultimului modul
n abordarea neincremental defectul ar putea fi oriunde (n orice
modul)

Testarea incremental este mai complet

Modulele sunt testate nu numai izolat, ci i n combinaie cu altele


De exemplu, la testarea incremental a lui B, dei modulele A sau E
au fost deja testate, prin evaluarea unor condiii din B pot aprea
erori nedetectate din A sau E
77

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Comparaie (III)

Abordarea neincremental consum mai puin timp de


calcul (aparent...)

Execuia unui modul nu mai implic rularea altora

Totui, este nevoie de mai mult timp de dezvoltare pentru


construirea modulelor driver i stub

Abordarea incremental permite testarea n paralel a


unor module, la nceputul activitii

Ctigurile pot fi semnificative pentru proiecte mari

78

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (I)


1. Introducere
2. Tipuri de testare
3. Inspeciile codului
4. Testarea de tip cutie neagr
5. Testarea de tip cutie alb
6. Testarea incremental i neincremental
7. Testarea top-down i bottom-up
8. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea top-down

ncepe cu modulul de pe nivelul cel mai nalt


Modulul urmtor trebuie s fie unul din modulele
subordonate unui modul deja testat

Modulul B este subordonat lui A dac A apeleaz


funcii din B

80

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu

Modulul A este modulul


iniial
Trebuie mai nti scrise
module stub pentru B, C
i D
Scrierea modulelor stub
nu este banal
Dac rezultatele
returnate de acestea nu
au sens, modulul A poate
s eueze chiar i fr
s aib vreun defect
Se pot dezvolta mai
multe versiuni diferite ale
stub-urilor, fiecare cu
date de test fixe
81

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Ordinea de testare

Dup testarea lui A, un modul real nlocuiete


un stub
Dup testarea modulului iniial, sunt posibile
mai multe secvene de testare, de exemplu:

unele module se pot testa i n paralel


82

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Pasul al doilea n testarea


top-down

83

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Recomandri

Modulele critice ale programului trebuie testate ct


mai devreme
Modulele cu funcii de intrare-ieire (I/O) trebuie
testate ct mai devreme

Dup adugarea unui modul de I/O, reprezentarea


cazurilor de test pentru modulul testat devine identic cu
aceea a programului final

De exemplu, dac modulul G conine funcii critice


iar modulele I i J conin funcii de I/O, o secven
posibil este:

84

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Probleme

S presupunem c adugm modulul H


Acesta este foarte deprtat de modulul de intrare J
Analog, modulul E este foarte deprtat de modulul de ieire I
Este dificil selectarea cazurilor de test pentru aceste module doar pe
baza intrrilor i ieirilor sistemului
85

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Probleme

Pentru testarea unui modul (de exemplu A) pot fi necesare


mai multe versiuni ale stub-ului B

Se poate decide ca A s fie testat parial la nceput, urmnd ca


restul de teste s fie fcute la adugarea modulului B real
Se poate ntmpla ca A s nu mai fie testat complet la momentul
respectiv

Deoarece nivelurile superioare trimit de obicei resurse pentru


utilizare n nivelurile inferioare, e greu de testat la nceput
dac aceste resurse sunt corecte

De exemplu A trimite un fiier pentru K, dar pn cnd K nu este


testat, nu se poate spune dac fiierul a fost deschis cu atributele
corecte
86

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea bottom-up

ncepe cu modulele terminale (care nu apeleaz alte module)


Modulul urmtor trebuie s fie unul pentru care toate
modulele subordonate au fost deja testate
Pentru exemplul anterior, se ncepe cu E, J, G, K, L, I, serial
sau n paralel
Se creeaz module driver pentru testarea funciilor
Este necesar un singur modul driver pentru un modul anume,
care va apela iterativ funciile testate
n general, crearea modulelor driver este mai uoar dect
crearea modulelor stub

87

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu

88

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Problem

Programul funcional nu exist dect dup


integrarea ultimului modul

89

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Comparaie
Testarea top-down

Testarea bottom-up

90

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Metrici

Efortul de testare

Este un indicator al volumului de teste


Un efort prea mic nseamn evaluarea insuficient a
produsului i deci o probabilitate mare ca produsul s fie
lansat cu defecte nedetectate

Timpul calculator

n general, la dezvoltarea unui produs software, timpul


calculator este mic la nceput, atinge un vrf maxim la
finalul implementrii i testrii iar apoi scade

91

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Recomandri (I)

Doar testarea exhaustiv poate arta c un


program nu are defecte
Totui, pentru programe de dimensiuni medii sau
mari, testarea exhaustiv este imposibil
Pentru selectarea testelor se recomand
urmtoarele:

Testarea tuturor funciilor accesate prin meniuri


Testarea combinaiilor de funcii accesate prin acelai
meniu
Cnd utilizatorul trebuie s introduc date, testarea
tuturor funciilor implicate, cu intrri corecte i incorecte
92

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Recomandri (II)

Alegerea intrrilor care foreaz sistemul s


genereze toate mesajele de eroare
Alegerea intrrilor care pot cauza suprancrcarea
zonelor de memorie alocate (engl. buffer
overflow)
Repetarea de mai multe ori a testelor cu aceleai
intrri sau serii de intrri
Forarea generrii de rezultate invalide
Forarea rezultatelor calculelor s fie prea mari sau
prea mici
93

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Recomandri (III)

Proiectarea de teste n care parametrii unei metode


apelate sunt situai la extremele domeniilor lor de
definiie
Testarea ntotdeauna a parametrilor de tip pointer
cu valoarea nul
Folosirea testrii la stres n sistemele de trimitere
de mesaje
Varierea ordinii n care sunt activate componentele
n sistemele cu memorie comun
94

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Automatizarea testrii

Testarea este o faz costisitoare. Mediile automate


de testare asigur o serie de instrumente care
reduc timpul necesar i costurile de testare
Aceste instrumente pot fi uneori dificil de integrat n
sistemele testate
Pentru testarea interfeei cu utilizatorul se
recomand utilizarea de scripturi
Datele de test pot fi generate dup anumite modele
sau distribuii de probabilitate
95

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Concluzii

Verificarea i validarea sunt dou lucruri diferite

Verificarea arat conformarea produsului la specificaii


Validarea arat c produsul ndeplinete cerinele clientului

Testarea poate indica prezena erorilor n sistem, nu


poate garanta lipsa erorilor
Testarea unitilor cade n sarcina dezvoltatorilor,
testarea sistemului este responsabilitatea unei
echipe diferite
Instrumentele automate reduc timpul i costul fazei
de testare
96

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

S-ar putea să vă placă și