ingineria programarii: faza de testare 1

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 de afaceri

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


Faza de testare (I)

1. Introducere







8. Concluzii


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


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

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


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


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ă


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)


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


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


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


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ă


Faza de testare (I)

1. Introducere







8. Concluzii


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


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


28


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


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


Faza de testare (I)

1. Introducere







8. Concluzii


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


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ă


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


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


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


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


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


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


40


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


41

Exemplu

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


42


Strategia 2

Se încearcă toate combinaţiile posibile

6 valori de limită

1 valoare nominală

7n cazuri de test


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


44

Exemplu

negaţie


45

Tabelul de decizie


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


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


48

Exemplu

9 ∙ 3 = 27 combinaţii

9 cazuri de test

se evită acoperirea unei

perechi de mai multe ori


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


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


51


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)


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”


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


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ă


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


Faza de testare (I)

1. Introducere







8. Concluzii


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


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)


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ă


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


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


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


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


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


65

Exemplu


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}


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}


68

Relaţiile dintre criterii

criteriu mai

puternic

criteriu mai

slab

de exemplu all-paths all-uses


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


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


NCover

71


Faza de testare (I)

1. Introducere







8. Concluzii


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


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


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


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


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


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


Faza de testare (I)

1. Introducere







8. Concluzii


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


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


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


83

Pasul al doilea în testarea

top-down


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:


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


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


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


88

Exemplu


89

Problemă

Programul funcţional nu există decât după

integrarea ultimului modul


90

Comparaţie

Testarea top-down

Testarea bottom-up


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


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)


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


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ă


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


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


ingineria programarii: faza de testare 1

Documents

defect testarea

ingineria programarii

testare florin leon

htm11 testarea

depanarea testarea defectelor

concluzii florin leon

htm10 testarea defectelor

stubs florin leon