Faza de testare (I)

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

2
Make it idiot-proof and
someone will make a better idiot.

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

5
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

6
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)

7
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 comercial
 Lansarea rapidă pe piață a unui produs poate fi uneori mai
importantă decât găsirea defectelor în program

8
 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
Testarea unui program

9
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”

10
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

11
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

12
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

14
Testarea unităților
 O unitate (sau un modul) se referă de obicei
la un element atomic (clasă sau metodă), 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”)

15
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ă

16
Testarea componentelor
 Testează interacțiunea mai multor unități
 Testarea este determinată de arhitectură

17
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
Testele de regresiune
 engl. “regression tests”
 Testele valide generează un set de rezultate verificate, numit
standard 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
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

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
21

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
22

23

Caracteristici
 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
24

Caracteristici
 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
25

27
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

28
Clase 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ă

29
Clase de echivalență pentru intrări
 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

30
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

31
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

32
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

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 valid (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 valid (EQ1, EQ6), apoi alte cazuri pentru
EQ2, ..., EQ5 și cazuri separate pentru IEQ1, IEQ2 și IEQ3
33

34
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 ≤ x ≤ 1
 Cazuri de test valide: 0 și 1
 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

35
 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 cele n intrări sunt la valoarea
nominală
  6n + 1 cazuri de test

36
Exemplu
 Pentru 2 intrări X și Y sunt necesare 13 cazuri
de test

37
 Strategia 2
 Se încearcă toate combinațiile posibile
 6 valori de limită
 1 valoare nominală
  7n cazuri de test

38
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

39
Exemplu
negație

40
Tabelul de decizie

Tipuri de defecte
 Defecte unimodale (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 este minor
 Program de taxare pentru telefoane care nu calculează corect pentru
apelurile spre o anumită țară
 Defecte multimodale (engl. “multi-mode faults”)
 Implică mai multe condiții
 Program care nu calculează bine tarifele când călătorul este 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
41

42
Testarea perechilor
 Pentru defecte unimodale
 Se folosesc strategiile de partiționare a claselor de echivalență
 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 multimodale
 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
unimodale sau bimodale)
 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

43
Exemplu
9 ∙ 3 = 27 combinații
9 cazuri de test
se evită acoperirea unei
perechi de mai multe ori

44
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

45
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

46
 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)

47
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”

48
Testarea claselor
 Acoperirea completă a testelor unei clase implică:
 Testarea tuturor operațiilor (metodelor) unui 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

49
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ă

50
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 unui graf, 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

52
Testarea „cutie albă”
 Testarea „cutie neagră” tratează funcționalitatea unui
modul
 Testarea „cutie albă” (engl. “white box”) tratează funcțiile
sau metodele la un nivel scăzut: este testată fiecare
funcție
 Aceste teste se mai numesc teste “clear box” deoarece
toate detaliile sunt vizibile pentru test
 Testarea „cutie albă” vizează acoperirea diferitelor
structuri ale programului, de aceea se mai numește
„testare structurală”

53
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)

54
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ă

55
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

56
Acoperirea căilor
 Un test mai general este acoperirea tuturor căilor
(all-paths)
 Presupune executarea tuturor căilor posibile din graful
de control
 Ccăi  Cramuri (all-paths  all-edges)
 Dificultăți:
 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

57
Testarea fluxului de control
 Niciuna din aceste metode nu este suficientă
pentru detectarea tuturor defectelor
 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

58
Testarea fluxului de date
 Graful def/use (definiție / utilizare)
 def: definirea unei variabile
 x = 5;
 c-use: utilizarea computațională
 a = x; read(x); write(x);
 p-use: utilizarea predicativă (într-o decizie)
 if (x > 0) …

59
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

60
Exemplu p-use se
reprezintă
pe arc

61
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}

62
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, 5, 6, 7, 9)
 Repetarea 5, 6 asigură
faptul că definițiile din
nodul 6 sunt și folosite
 Cazuri de test:
 {x = 3, y = 2}
 {x = 3, y = -2}

63
Relațiile dintre criterii
criteriu mai
puternic
criteriu mai
slab
de exemplu, all-paths  all-uses

64
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

65
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: Visual Studio (Test → Analyse
Code Coverage), NCover, PartCover, dotCover

Visual Studio: testarea unităților
66

Visual Studio: acoperirea codului
67
Nu sunt testate toate condițiile

69
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

70
Tipuri de integrare
 Integrarea neincrementală
 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

71
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

72
Comparație
 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

73
Comparație
 Testarea incrementală detectează mai devreme incompatibili-
tatea interfețelor sau alte presupuneri incorecte din module
 În testarea neincrementală, modulele nu se „văd” decât la sfârșit
 Depanarea este mai ușoară în abordarea incrementală
 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

74
Comparație
 Abordarea neincrementală poate necesita aparent mai
puțin timp de calcul
 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

76
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

77
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

78
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

79
Pasul al doilea în testarea
top-down

80
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:

81
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

82
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 (această situație trebuie evitată)
 Deoarece nivelurile superioare trimit de obicei resurse pentru
utilizare pe nivelurile inferioare, este 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

83
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

84
Exemplu

85
Problemă
 Programul funcțional nu există decât după
integrarea ultimului modul

86
Comparație
Testarea top-down
Testarea bottom-up

87
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

88
 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ă:
(slide-ul următor)
Recomandări

Recomandări
 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
 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
 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ă
 Varierea ordinii în care sunt activate
componentele în sistemele cu
memorie comună
89

90
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
 De exemplu, testele de tip Coded UI în Visual Studio,
care înregistrează o succesiune de acțiuni
 Datele de test pot fi generate după anumite modele
sau distribuții de probabilitate

91
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 obicei în sarcina
dezvoltatorilor, dar testarea sistemului trebuie să fie
responsabilitatea unei echipe diferite
 Instrumentele automate reduc timpul și costul fazei
de testare

Faza de testare (I)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Faza de testare (I)

Similar to Faza de testare (I) (11)

More from Florin Leon

More from Florin Leon (20)

Faza de testare (I)