Ingineria programării

12. Faza de testare (I)

Florin Leon
Universitatea Tehnică „Gheorghe Asachi” din Iaşi
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.

2

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

Faza de testare (I)
1. Introducere
2. Tipuri de testare
3. Inspecţiile 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. Inspecţiile 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 specificaţiilor, la utilitatea
produsului

5

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 său
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 următor)

6

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

Evaluarea unui produs
software

Depinde de scopul produsului, de aşteptările
utilizatorilor şi factorii de piaţă

Funcţionalitatea programului
 Nivelul de încredere depinde de cât de critic este sistemul
pentru utilizatori
Aşteptările utilizatorilor
 Utilizatorii pot avea grade diferite de aşteptări pentru
anumite tipuri de produse software
Mediul de afaceri
 Lansarea rapidă pe piaţă a unui produs poate fi uneori mai
importantă decât găsirea defectelor în program
7

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

Testarea unui program

Evidenţiază prezenţa erorilor şi nu absenţa lor

Este singura tehnică de validare pentru cerinţe
non-funcţionale, deoarece programul trebuie
lansat în execuţie pentru a i se analiza
comportamentul

Este utilizată de obicei alături de verificarea
statică pentru o siguranţă cât mai mare

8

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

Terminologie (IEEE)

Eroare
 O acţiune umană care are ca rezultat un defect în produsul
software
Defect (engl. “fault”)
 Consecinţa unei erori în produsul software
 Un defect poate fi latent: nu cauzează probleme cât timp nu apar
condiţiile care determină execuţia anumitor linii de cod
Defecţiune (engl. “failure”)
 Manifestarea unui defect: când execuţia programului întâlneşte
un defect, acesta provoacă o defecţiune
 Abaterea programului de la comportamentul aşteptat
“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 prezenţa defectelor în
sistem
Un test de succes este cel care descoperă un defect

Testarea de validare

Intenţionează să arate că produsul nu îndeplineşte
cerinţele
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 existenţei defectelor
într-un program
Depanarea are ca scop localizarea şi repararea
erorilor corespunzătoare
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 calităţii

Testarea se referă la detectarea defectelor
Asigurarea calităţii 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 calităţii este mai
general decât 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. Inspecţiile 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 unităţilor

O unitate (sau un modul) se referă de obicei
la un element atomic (clasă sau funcţie), dar
poate însemna şi un element de nivel mai
înalt: bibliotecă, driver etc.
Testarea unei unităţi se face în izolare

Pentru simularea apelurilor externe se pot utiliza
funcţii externe fictive (engl. “stubs”)

14

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

Programe „schelă”

De multe ori sunt necesare aşa-numitele „schele”,
adică programe special construite pentru stabilirea
mediului de test

Numai când mediul este realizat se poate executa o
evaluare corectă
Programul schelă stabileşte stări şi valori pentru structurile
de date şi asigură funcţii externe fictive
De obicei, programul schelă nu are aceeaşi calitate ca
produsul software testat şi adesea este destul de fragil
O schimbare mică în modulul testat poate determina
schimbări importante în programul schelă
15

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

Testarea componentelor

Testează interacţiunea mai multor unităţi
Testarea este determinată de arhitectură

16

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

Testarea sistemului

Testarea sistemului testează aplicaţia ca întreg şi este
determinată de scenariile de analiză
Aplicaţia trebuie să execute cu succes toate scenariile pentru
a putea fi pusă la dispoziţia clientului
Spre deosebire de testarea internă şi a componentelor, care
se face prin program, testarea aplicaţiei se face de obicei cu
scripturi care rulează sistemul cu o serie de parametri şi
colectează rezultatele
Testarea aplicaţiei trebuie să fie realizată de o echipă
independentă de echipa de implementare
Testele se bazează pe specificaţiile sistemului
17

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

Cine face testarea?

Există diferite păreri 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 experienţei
programatorului

Testarea unei componente se face de către o
persoană diferită, iar depanarea se face de către
programatorul iniţial
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 modificări, pentru a asigura faptul că modificările nu au introdus
noi defecte în codul care funcţiona bine anterior

Pe măsură ce dezvoltarea continuă, sunt adăugate mai multe teste
noi, iar testele vechi pot rămâne valide sau nu

Dacă un test vechi nu mai este valid, rezultatele sale sunt modificate
în standardul de aur, pentru a se potrivi situaţiei 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 performanţelor

O parte din testare se concentrează pe
evaluarea proprietăţilor emergente ale
sistemului, cum ar fi:

Încrederea (menţinerea 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 înţeles, învăţat şi
utilizat)

20

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

Testarea la încărcare

Asigură faptul că sistemul poate gestiona un
volum aşteptat de date, similar cu acela din
locaţia destinaţie (de exemplu la client)

Verifică eficienţa sistemului şi modul în care
scalează acesta pentru un mediu real de
execuţie

21

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

Testarea la stres

Solicită sistemul dincolo de încărcarea maximă proiectată
Supraîncărcarea testează modul în care „cade” sistemul

Sistemele nu trebuie să eşueze catastrofal

Testarea la stres verifică pierderile inacceptabile de date sau funcţionalităţi

Deseori apar aici conflicte între teste. Fiecare test funcţionează
corect atunci când este făcut separat. Când două teste sunt rulate în
paralel, unul sau ambele teste pot eşua

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, săptămâni, luni)

În acest caz, de exemplu scurgerile nesemnificative de memorie se pot
acumula şi pot provoca căderea sistemului
22

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

Testarea interfeţei cu
utilizatorul

Majoritatea aplicaţiilor din zilele noastre au interfeţe grafice cu
utilizatorul (GUI)

Testarea interfeţei grafice poate pune anumite probleme

Cele mai multe interfeţe, dacă nu chiar toate, au bucle de
evenimente care conţin cozi de mesaje de la mouse, tastatură,
ferestre etc.

Asociate cu fiecare eveniment sunt coordonatele ecran

Testarea interfeţei cu utilizatorul presupune memorarea tuturor
acestor informaţii şi elaborarea unei modalităţi prin care mesajele
să fie trimise din nou aplicaţiei, la un moment ulterior

De obicei se folosesc scripturi pentru testare
23

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

Testarea utilizabilităţii

Testează cât de uşor 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. Inspecţiile 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

Inspecţiile codului


engl. “code inspections”, “code reviews”
Presupun citirea codului pentru a detecta erori
Echipa de inspecţie are în general 4 persoane:


Moderatorul – un programator competent
Programatorul – cel care a scris codul inspectat
Proiectantul (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

Activităţi

Programatorul citeşte, instrucţiune cu
instrucţiune, logica programului

Ceilalţi participanţi pun întrebări
Programatorul însuşi poate descoperi cele mai
multe erori

Se caută în program cele mai întâlnite tipuri de
erori

O listă de erori comune este prezentată în slide-ul următor

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ă corecţii substanţiale, moderatorul stabileşte o
nouă inspecţie după corectarea lor
Erorile determinate pot conduce la modificarea
proiectării (design-ului)
De obicei, durata unei sesiuni de inspecţie este de
90-120 de minute, cu o rată de 150 de instrucţiuni pe oră

Dacă programul este mai mare, se stabilesc mai multe sesiuni de
inspecţie, 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ă inspecţia ca pe un atac personal, ci ca pe o
modalitate de a creşte calitatea muncii sale

Rezultatele inspecţiei sunt confidenţiale
Programatorul primeşte reacţii privind stilul de
programare, tehnicile şi algoritmii folosiţi
Ceilalţi participanţi beneficiază de pe urma expunerii la
un alt stil de programare
Identificarea timpurie a secţiunilor celor mai predispuse
la erori ajută la sporirea atenţiei 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. Inspecţiile 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 numeşte testare funcţională
Se iau în considerare numai intrările într-un
modul şi ieşirile dorite, conform specificaţiilor
Structura internă a modulului este ignorată
Testarea exhaustivă nu este fezabilă
Generarea aleatorie a cazurilor de test nu este
eficientă
Optimul: detectarea unui număr maxim de
defecte cu un număr minim de cazuri de test
32

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

Partiţionarea claselor de
echivalenţă

O clasă de echivalenţă (CE) este formată din
intrările 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ţă

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 condiţie a unei
intrări, 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 ieşiri

Pentru fiecare tip de ieşire, se estimează ce
intrări pot provoca situaţiile respective

De exemplu rata dobânzii pentru care profitul unei
investiţii este pozitiv, negativ sau 0

Deşi sunt mai greu de identificat, cazurile de test
pentru clasele de ieşire pot indica defecte
suplimentare faţă de clasele de intrare

35

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

Selecţia cazurilor de test

Strategia 1

Fiecare test să acopere cât mai multe CE valide
Câte un test pentru fiecare CE invalidă

Strategia 2


Un test să acopere cel mult o CE validă pentru
fiecare intrare
Câte 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 intrări: un şir de caractere s de
lungime ≤ N şi un întreg n
Ieşirea: cele mai dese n apariţii 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ă decât N, conţinând litere
mari, litere mici, cifre şi caractere speciale şi n = 5 (EQ1 – EQ6),
apoi câte un caz pentru IEQ1, IEQ2 şi IEQ3

Strategia 2: câte 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 funcţionează corect pentru valorile
unei CE eşuează 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 ieşire, se aleg intrări care determină o ieşire la
limita CE, respectiv în afara sa
39

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

Selecţia cazurilor de test

Pentru n intrări, fiecare cu un domeniu de
definiţie
Strategia 1

Se selectează valori limită diferite pentru o variabilă
iar celelalte sunt menţinute la valoarea nominală

min – 1, min, min + 1, max – 1, max, max + 1

Plus un caz în care toate n intrări sunt la valoarea
nominală

 6n + 1 cazuri de test

40

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

Exemplu

Pentru 2 intrări X şi Y sunt necesare 13 cazuri
de test

41

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

Selecţia cazurilor de test

Strategia 2

Se încearcă toate combinaţiile 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
combinaţiilor de teste


Considerând toate combinaţiile valide, pentru n condiţii de
intrare vom avea 2n cazuri de test

Graful cauză-efect determină selectarea
combinaţiilor de intrare într-un mod sistematic
Cauză = o condiţie distinctă de intrare
Efect = o condiţie distinctă de ieşire
Condiţiile sunt binare (A / F) şi pot fi combinate cu
operatorii ŞI, SAU, NEGAŢIE
43

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

Exemplu
negaţie

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ă condiţie


Program care nu tipăreşte corect pentru un anumit tip de imprimantă
Program care nu calculează bine tarifele când călătorul 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 condiţii

Program care nu calculează bine tarifele când călătorul e minor şi
călătoreşte la business class şi nu stă un weekend la destinaţie
Program de taxare pentru telefoane care nu calculează corect pentru
apelurile spre o anumită ţară în timpul nopţii
46

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

Testarea perechilor

Pentru defecte uni-modale

Se folosesc strategiile de partiţionare a claselor de echivalentă
Pentru n parametri cu m valori, numărul de teste în cazul cel mai
favorabil este m (putem testa toţi parametrii într-un test, fiecare
cu valori diferite)

Pentru defecte multi-modale

Testarea tuturor combinaţiilor nu este fezabilă (nm cazuri de test)
Studiile au arătat că majoritatea defectelor sunt indicate de
testarea perechilor de valori (majoritatea defectelor sunt
uni-modale sau bi-modale)
Pentru n parametri cu m valori, numărul total de perechi este
m ∙ m ∙ n ∙ (n – 1) / 2
Numărul 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 combinaţii
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 experienţa
testerului, pentru a detecta presupunerile
incorecte ale programatorului, cauzate în
general de specificaţiile incomplete
Exemple:



La o împărţire, numitorul este 0
Un fişier care trebuie citit este gol sau nu există
Fişierul începe cu linii albe
Vectorul este deja sortat
49

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

Testarea bazată pe stări

Pentru aceleaşi intrări, sistemele cu stare produc
ieşiri diferite la momente de timp diferite

Ieşirile depind şi de starea internă, nu numai de intrări

Starea depinde de intrările anterioare

Modelul de stare conţine:

Stări: impactul cumulat al tuturor intrărilor anterioare

Tranziţii: schimbările stărilor ca răspuns la evenimente

Evenimente: intrările sistemului

Acţiuni: ieşirile sistemului
50

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

Selecţia cazurilor de test

Testarea bazată pe stări este o testare de tip
„cutie gri” (engl. “gray box”)
Criterii:

Testele trebuie să acopere toate tranziţiile din graf

Trebuie să execute toate perechile de tranziţii
adiacente (intrarea într-o stare şi ieşirea din acea
stare)

Trebuie să execute toate căile simple (care nu conţin
noduri repetate)
51

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

Exemplu
Exemplu
Sistem de
sondaj pentru
studenţi


Un student
răspunde la
întrebări şi apoi
vede rezultatele
sondajului
Rezultatele se
actualizează doar
după 5 răspunsuri
Baza de date poate
„cădea”
52

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

Testarea claselor

Acoperirea completă a testelor unei clase implică:

Testarea tuturor operaţiilor asociate cu un obiect
Setarea şi interogarea tuturor atributelor (câmpurilor)
unui obiect
Trecerea unui obiect prin toate stările posibile
 Presupune testarea tuturor combinaţiilor de valori
pentru câmpuri
 Problemă asemănătoare cu testarea perechilor

Moştenirea îngreunează proiectarea testelor de
clasă, întrucât entităţile 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 către altă metodă
trebuie testat cel puţin 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 funcţii

engl. “function pair”

Pentru toate secvenţele posibile de execuţii ale metodelor,
trebuie testate cele de lungime 2

Acest lucru se face de obicei pe baza unei diagrame de stări,
care precizează succesiunile posibile de apeluri

Pentru un program cu operaţii grafice, exemple de perechi de
funcţii 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. Inspecţiile 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ă funcţionalitatea unui
modul

Testarea „cutie albă” tratează funcţiile sau metodele la
un nivel scăzut: fiecare funcţie 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 numeşte „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 instrucţiuni executate împreună

Arce: posibile transferuri de control

Cale: secvenţă finită de noduri (n1, n2, ..., nk),
k > 1, astfel încât există un arc (ni, ni+1) oricare ar
fi ni, cu excepţia lui nk

Cale completă: o cale din nodul iniţial (start) în
nodul final (exit)

58

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

Acoperirea instrucţiunilor

Necesită ca fiecare instrucţiune să fie
executată cel puţin o dată

Se mai numeşte criteriul tuturor nodurilor (all-nodes)
Nu este un criteriu foarte puternic

pentru cazul de
test {x = 0}, eroarea
rămâne 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 puţin o dată
Fiecare decizie trebuie evaluată ca A sau F
Criteriul acoperirii ramurilor 100% se mai numeşte criteriul tuturor
arcelor (all-edges)
Cramuri  Cinstrucţiuni (all-edges  all-nodes)

decizia poate fi
evaluată A sau F fără
a detecta eroarea

Funcţia ar trebui să testeze că x este în intervalul [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 căilor

Un test mai general este acoperirea tuturor căilor
(all-paths)
Presupune executarea tuturor căilor posibile din graful
de control

Dificultăţi:

Ccăi  Cramuri (all-paths  all-edges)
Programele care conţin bucle au un număr infinit de căi
Pot exista căi în graf pentru care să nu existe intrări
corespunzătoare astfel încât căile respective să fie executate

Pentru un modul având complexitatea ciclomatică M,
se recomandă testarea a cel puţin M căi 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 lipseşte o cale necesară pentru
testarea unei condiţii, chiar dacă sunt testate
toate căile 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 (definiţie / utilizare)
def: definirea unei variabile

c-use: utilizarea computaţională

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 definiţie trebuie să existe un
c-use sau un p-use
all-p-uses: trebuie testate toate utilizările predicative
ale unei definiţii
all-c-uses: trebuie testate toate utilizările
computaţionale ale unei definiţii
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 puţin
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

Relaţiile 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 creşterea performanţelor, 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 decât BIOS-ul
A apărut necesitatea testării 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 execuţie
Depinde de programator combinarea acestor teste în cazuri
semnificative care să valideze rezultatele fiecărui fir de execuţie
De obicei, instrumentul de acoperire este utilizat într-un mod
oarecum diferit: el urmăreşte 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. Inspecţiile 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 generării cazurilor de test

Costul depanării

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, continuându-se cu testarea sistemului
Numită şi model “big-bang” deoarece timpul de
testare creşte mult

Integrarea incrementală

Următorul modul care trebuie testat este combinat cu
modulele testate până 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ă intrările şi/sau
module stub (din care se
pot apela funcţii)
De exemplu: pentru B

Modul driver: A
Modul stub: E

A apelează funcţii din B, C, D
B apelează funcţii din E
D apelează funcţii din F
75

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

Comparaţie (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

Comparaţie (II)

Testarea incrementală detectează mai devreme incompatibilitatea interfeţelor sau alte presupuneri incorecte din module

Depanarea este mai uşoară în abordarea incrementală

În testarea neincrementală modulele nu se „văd” decât la sfârşit
Un defect detectat la un moment dat este cauzat de adăugarea
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 combinaţie cu altele
De exemplu, la testarea incrementală a lui B, deşi modulele A sau E
au fost deja testate, prin evaluarea unor condiţii din B pot apărea
erori nedetectate din A sau E
77

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

Comparaţie (III)

Abordarea neincrementală consumă mai puţin timp de
calcul (aparent...)

Execuţia unui modul nu mai implică rularea altora

Totuşi, 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 activităţii

Câştigurile 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. Inspecţiile 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 următor trebuie să fie unul din modulele
subordonate unui modul deja testat

Modulul B este subordonat lui A dacă A apelează
funcţii din B

80

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

Exemplu

Modulul A este modulul iniţial
Trebuie mai întâi 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ă eşueze chiar şi
fără 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 înlocuieşte
un stub
După testarea modulului iniţial, sunt posibile
mai multe secvenţe 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

Recomandări

Modulele critice ale programului trebuie testate cât
mai devreme
Modulele cu funcţii de intrare-ieşire (I/O) trebuie
testate cât mai devreme

După adăugarea unui modul de I/O, reprezentarea
cazurilor de test pentru modulul testat devine identică cu
aceea a programului final

De exemplu, dacă modulul G conţine funcţii critice
iar modulele I şi J conţin funcţii de I/O, o secvenţă
posibilă este:

84

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

Probleme



Să presupunem că adăugăm modulul H
Acesta este foarte „depărtat” de modulul de intrare J
Analog, modulul E este foarte „depărtat” de modulul de ieşire I
Este dificilă selectarea cazurilor de test pentru aceste module doar pe baza
intrărilor şi ieşirilor 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 parţial la început, urmând ca
restul de teste să fie făcut la adăugarea modulului B real
Se poate întâmpla 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 fişier pentru K, dar până când K nu este
testat, nu se poate spune dacă fişierul 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 următor 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 funcţiilor
Este necesar un singur modul driver pentru un modul anume,
care va apela iterativ funcţiile testate
În general, crearea modulelor driver este mai uşoară decât
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 funcţional nu există decât după
integrarea ultimului modul

89

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

Comparaţie
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 vârf maxim la
finalul implementării şi testării iar apoi scade

91

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

Recomandări (I)


Doar testarea exhaustivă poate arăta că un
program nu are defecte
Totuşi, pentru programe de dimensiuni medii sau
mari, testarea exhaustivă este imposibilă
Pentru selectarea testelor se recomandă
următoarele:


Testarea tuturor funcţiilor accesate prin meniuri
Testarea combinaţiilor de funcţii accesate prin acelaşi
meniu
Când utilizatorul trebuie să introducă date, testarea
tuturor funcţiilor implicate, cu intrări corecte şi incorecte
92

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

Recomandări (II)


Alegerea intrărilor care forţează sistemul să
genereze toate mesajele de eroare
Alegerea intrărilor care pot cauza supraîncărcarea
zonelor de memorie alocate (engl. “buffer
overflow”)
Repetarea de mai multe ori a testelor cu aceleaşi
intrări sau serii de intrări
Forţarea generării de rezultate invalide
Forţarea rezultatelor calculelor să fie prea mari sau
prea mici
93

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

Recomandări (III)

Proiectarea de teste în care parametrii unei metode
apelate sunt situaţi la extremele domeniilor lor de
definiţie
Testarea întotdeauna a parametrilor de tip pointer
cu valoarea nulă
Folosirea testării 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 testării

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 interfeţei cu utilizatorul se
recomandă utilizarea de scripturi
Datele de test pot fi generate după anumite modele
sau distribuţii 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 specificaţii
Validarea arată că produsul îndeplineşte cerinţele clientului

Testarea poate indica prezenţa erorilor în sistem, nu
poate garanta lipsa erorilor
Testarea unităţilor cade de obice în sarcina
dezvoltatorilor, dar testarea sistemului trebuie să fie
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

Sign up to vote on this title
UsefulNot useful