Upload
enrollinfo
View
231
Download
3
Tags:
Embed Size (px)
DESCRIPTION
Ingineria programarii: Faza de testare Software Engineering: Testing Phase
Citation preview
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.
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
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
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)
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
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 de afaceri
Lansarea rapidă pe piaţă a unui produs poate fi uneori mai
importantă decât găsirea defectelor în program
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
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”
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
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
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
14
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”)
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
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ă
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
16
Testarea componentelor
Testează interacţiunea mai multor unităţi
Testarea este determinată de arhitectură
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
17
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
18
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
19
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ă
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
20
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)
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
21
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
22
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
23
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
24
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ă
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
32
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
33
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ă
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
34
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
35
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
36
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
37
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
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
39
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
40
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
41
Exemplu
Pentru 2 intrări X şi Y sunt necesare 13 cazuri de test
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
42
Selecţia cazurilor de test
Strategia 2
Se încearcă toate combinaţiile posibile
6 valori de limită
1 valoare nominală
7n cazuri de test
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
43
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
44
Exemplu
negaţie
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
45
Tabelul de decizie
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
47
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
48
Exemplu
9 ∙ 3 = 27 combinaţii
9 cazuri de test
se evită acoperirea unei
perechi de mai multe ori
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
49
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
50
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
51
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)
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
52
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”
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
53
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
54
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ă
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
55
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
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
57
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ă”
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
58
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)
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
59
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ă
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
60
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
61
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
62
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
63
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) …
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
64
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
65
Exemplu
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
66
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}
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
67
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}
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
68
Relaţiile dintre criterii
criteriu mai
puternic
criteriu mai
slab
de exemplu all-paths all-uses
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
69
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
70
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
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
73
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
74
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
75
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
76
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
77
Comparaţie (II)
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
78
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
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
80
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
81
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
82
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
83
Pasul al doilea în testarea
top-down
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
84
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:
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
85
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
86
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
87
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
88
Exemplu
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
89
Problemă
Programul funcţional nu există decât după
integrarea ultimului modul
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
90
Comparaţie
Testarea top-down
Testarea bottom-up
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
91
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
92
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
Recomandări (I)
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
93
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
94
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ă
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
95
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
96
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
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm