Sunteți pe pagina 1din 15

1

TESTAREA TESTAREA TESTAREA TESTAREA SISTEMELOR SOFTWARE SISTEMELOR SOFTWARE SISTEMELOR SOFTWARE SISTEMELOR SOFTWARE
Testarea software determin dac un sistem software este gata de livrare i estimeaz nivelul
de performan al acestuia. Testarea furnizeaz o baz pentru interaciunea cu persoanele implicate
n proiect. Creterea complexitii sistemelor software a dus la o cretere a bugetului alocat acestei
faze din procesul de dezvoltare al unui proiect (ntre 30 i 50%). O mare parte a efortului necesar
realizrii sistemelor software este alocat dezvoltrii modelelor de testare i a aplicaiilor de testare
automat.
Testarea este procesul execuiei programului cu scopul de a pune n eviden erorile.
Detectarea erorilor este scopul principal al testrii. n acelai timp, prezint interes att dezvoltarea
unor seturi de date de test adecvate care s conduc la activarea erorilor precum i modalitile de
alocare a timpului necesar testrii, n special n sistemele de mare complexitate.
n mod obinuit, spunem c un sistem software eueaz atunci cnd nu ndeplinete cerinele
impuse. Funcionarea defectuoas poate fi rezultatul unuia dintre urmtoarele motivele:
Specificaiile sunt greite sau unele cerine ale clienilor nu sunt specificate;
Specificaiile pot conine cerine care nu pot fi implementate cu softul disponibil;
Proiectarea sistemului poate fi greit.
Implementarea codului are defecte; unii algoritmi sunt greit sau incomplet implementai.
Experiena acumulat de-a lungul timpului n domeniul testrii software a dus la elaborarea
unor politici de testare. Spre exemplu, Myers (1976) a propus urmtoarele reguli de baz pentru
realizarea testrii sistemelor software:
Se determin momentul n care se oprete testarea;
Responsabilitatea testrii programului revine unui tester, nu celui ce realizat programul;
Se descriu rezultatele ateptate pentru fiecare caz de test;
Se scriu cazuri de test pentru condiii de intrare valide i nevalide;
Se verific rezultatele fiecrui test.
Testarea se atribuie celor mai creative persoane din echip
Pentru proiectele complexe, specificaiile de test pentru sistem i pentru acceptarea acestuia
nu trebuie scrise de ctre analiti, proiectani i programatori care au lucrat la proiectul respectiv
(pentru sistemele mici i medii e acceptabil ca aceste specificaii s fie scrise de ctre cei ce
dezvolt sistemul) ci de ctre utilizatorii sistemului.
Testarea software cuprinde o multitudine de strategii de testare. n general, metodele de
testare sunt specializate, n sensul c cele mai multe proiecte creeaz propriile metode de testare
depinznd de produsul respectiv.
Metodele de testare dinamic presupun executarea programului folosind aa numitele date
de test. Datele de test se construiesc conform cerinelor funcionale specificate iar rezultatele
furnizate de program se compar cu cele prezentate n specificaii.
Metodele de testare static cuprind verificarea programului, analiza anomaliilor, inspecia
codului. Verificarea programului necesit specificarea precondiiilor la intrare i a postcondiiilor la
ieire. Analiza anomaliilor caut eventuale comportri anormale ale programului (spre exemplu,
poriuni de cod care nu sunt executate niciodat). Scopul testrii statice este de a analiza sistemul
software i de a deduce operaiile sale curente ca o consecin logic a deciziilor de proiectare.
Aceast modalitate de testare nu necesit execuia programului.
1. Clasificarea metodelor de testare
Metodele de testare pot fi clasificate n dou mari categorii:
Testarea black box (cutie neagr). Aceast abordare se concentreaz asupra intrrilor,
ieirilor i funcionalitii modulelor software.
2
Testarea white box (cutie alb). Aceast abordare presupune inspectarea structurii
codului modulelor software.
Testarea black box se mai numete testare funcional. Punctul de plecare este fie o
specificaie, fie codul. n cazul codului, datele de test trebuie s permit verificarea funcionalitii
programului. Testerul nu este interesat de modul n care este implementat programul respectiv, ci de
modul n care acesta furnizeaz rspunsul dorit.
Testarea white box, cunoscut i sub numele de testare structural, presupune analizarea
implementrii programului (modulului). Se verific executarea corect a tuturor cilor i ramurilor
codului programului testat. n tabelul 1 se prezint cteva metode de testare ce fac parte din cele
dou mari categorii prezentate mai sus, metode ce vor fi prezentate pe larg n seciunile ulterioare.
Tabelul 1 Clasificarea formelor de testare
Testare funcional Testare structural
Dinamic Testare aleatoare
Testare pe domenii
Graf cauz-efect
Testare computaional
Testare pe domenii
Testare ci
Generare date
Analiza schimbrilor
Static Verificare specificaii Inspectare cod
Verificare program
Execuie simbolic
Analiz anomalii
n cazul testrii sistemelor software exist i probleme ce nu in de tehnic. Spre exemplu, se
pot pune urmtoarele ntrebri: Cine face testarea? Testarea poate fi realizat de un programator
care a fost implicat n scrierea codului? Se apeleaz la un tester independent, se schimb poriuni
de cod ntre membrii aceleiai echipe sau se las testarea n seama utilizatorului final? Fiecare
dintre alternativele propuse are argumente pro i contra.
O alt problem fundamental este legat de durata activitilor de testare, cnd apar dou
puncte de vedere cel puin contradictorii care trebuie luate n considerare. Primul este al
proiectanilor care fac tot posibilul pentru a realiza un produs fr defecte. Cel de-al doilea este al
managerilor de proiect care iau n considerare constrngerile de timp impuse proiectului.
nainte de a intra ntr-o prezentare mai detaliat a diferitelor variante de testare, este
important precizarea pailor principali care intervin n orice schem de testare.
Etapele principale ale unei scheme de testare
Selectai ce trebuie msurat (cuantificat) de testul respectiv. nainte de realizarea testului,
trebuie identificate scopurile acestuia. Scopurile pot fi diferite (spre exemplu, testarea fiabilitii,
testarea completitudinii cerinelor).
Decidei cum facei testarea a ceea ce trebuie testat. Dup ce ai stabilit ce este de testat, trebuie
s decidei cum realizai testele relevante.
Dezvoltai cazurile de test. Pentru tipurile de testare deja acceptate, trebuie creat o colecie de
cazuri de test (situaii de test) pentru antrenarea sistemului supus testrii.
Determinai rezultatele ateptate ale testului respectiv.
Executai cazurile de test.
Comparai rezultatele obinute cu cele ateptate.
2. Niveluri ale testrii software
Testarea software se realizeaz la diferite nivele de-a lungul ntregului ciclu de via al
produsului. Testarea ncepe la nivel de componente software individuale. Se verific
funcionalitatea i structura fiecrei componente, dup care se face testarea la integrare a
componentelor. Standardul IEEE de verificare i validare software (IEEE Std. 1059-1993) identific
patru nivele de testare, dup cum se poate observa n tabelul 2. Corespondena ntre nivelele de
testare i etapele ciclului de via a sistemului este prezentat n figura 1.
3
Tabel 2
Testare Definiie Scop
Component Se verific implementarea elementelor
software (ex. Funcii, module).
Logica programului este complet i corect.
Componentele funcioneaz conform proiectrii.
Integrare Componentele software i hardware sunt
combinate i testate pn la integrarea
ntregului sistem
Obiectivele proiectrii sunt satisfcute
Sistem Se testeaz sistemul integrat Proiectul software este o entitate complet n
concordan cu cerinele operaionale.
Acceptare Se verific dac rezultatele testelor
satisfac criteriile de acceptare ale
clienilor
Obiectivele clienilor sunt satisfcute


Figura 1. Nivele de observabilitate a testrii
3. Activiti de test
n cadrul testrii software se pot delimita urmtoarele activiti cheie:
Elaborarea planului de testare
Proiectarea testului
Stabilirea cazurilor de test
Determinarea procedurii de testare
Executarea testului
Realizarea raportului de testare
Planul de testare trebuie s precizeze scopul, tipul abordrii, resursele necesare i un orar al
activitii de testare. Este necesar de asemenea identificarea surselor i nivelelor de risc i stabilirea
persoanele ce realizeaz testarea. Planificarea testrii poate ncepe din momentul n care cerinele
sistemului sunt complete. Este dificil determinarea momentului n care se oprete testarea. Din
acest motiv trebuie introduse criterii pentru a stabili dac un test este complet sau nu.
Proiectarea testului rafineaz abordarea propus n planul de testare. n aceast etap se
identific principalele caracteristici ce trebuie testate i se definesc cazurile de test asociate. Este
recomandat ca proiectarea testelor s se fac pentru o testare de regresiune (testele executate
anterior s poat fi repetate la un punct ulterior n procesul de dezvoltare i ntreinere).
Cazurile i procedurile de test se construiesc n faza de implementare. Se urmrete
realizarea unei colecii de cazuri de test ct mai redus care s poat duce la ndeplinirea scopurilor
propuse. Cazurile de test bine realizate au o mare probabilitate de a detecta erorile. Procedura de
testare identific toi paii necesari operrii sistemului i rulrii cazurilor de test ce implementeaz
proiectul de test obinut n etapa anterioar.
Executarea testului ncepe la nivel de componente i continu cu testarea la integrare,
testarea sistemului i testarea de acceptare.
Raportul de testare rezum toate ieirile testului i subliniaz discrepanele detectate.
Activitile de testare se distribuie de-a lungul ntregului ciclu de via al produsului.
4. Tipuri de teste software
innd cont de multitudinea metodelor de testare existente este avantajoas luarea n
4
considerare a testelor n funcie de modalitatea n care acestea devin accesibile proiectantului.
Testele funcionale sunt utilizate pentru a rula codul cu intrri nominale pentru care valorile
ateptate sunt disponibile. Pentru aceste intrri sunt cunoscute de asemenea condiiile la limit. Spre
exemplu, pentru a testa funcional nmulirea matricelor se vor lua n considerare matrice al cror
produs este dinainte cunoscut.
Testele de performan ajut la determinarea unor performane ale sistemului cum ar fi
timpul de execuie al unor pri de cod i timpul de rspuns (n cazul sistemelor ncorporate). Scopul
acestui tip de testare const n identificarea punctelor slabe ale sistemului software, cuantificarea
neajunsurilor n scopul unei viitoare mbuntiri.
Testele la stres sunt proiectate pentru a urmri comportarea sistemului atunci cnd acesta
cedeaz. Acest tip de testare evalueaz limitrile sistemului software.
Testele structurale sunt folosite pentru a verifica logica intern a sistemului.
Testele pe componente se efectueaz asupra modulelor individuale, proceduri i funcii.
Testele la integrare sunt proiectate pentru a testa comportarea sistemului pe msur ce se
adaug modulele componente.
Testarea interfeelor are ca obiectiv detectarea erorilor cauzate de interfeele dintre obiecte.
Pot aprea urmtoarele tipuri de erori: utilizare greit a interfeei (parametri cu un alt tip sau ntr-o
alt ordine dect sunt specificai n interfa), nelegerea greit a interfeei (presupuneri greite
legate de ce ar trebui s fac o component), erori de timing (au loc n sistemele n timp real care
folosesc memorie partajat sau transmitere de mesaje).
5. Testarea funcionala (black box)
Dup cum am precizat anterior, testarea de tip black box nu necesit cunoaterea codului
pentru realizarea unor teste semnificative. n continuare vom discuta despre cteva categorii
reprezentative ale acestei metode de testare cum ar fi testarea derivat din sintax, testarea bazat pe
tabele de decizie i abordarea bazat pe grafuri cauz efect.
T5.1 Testarea derivat din sintax
Aceast clas de teste funcionale se aplic sistemelor ale cror specificaii sunt descrise de o
anumit gramatic. Aceast const, spre exemplu, n compilatoare i clasificatori sintactici.
Deoarece specificarea formal a unor astfel de sisteme se exprim prin reguli de producie,
generarea cazurilor de test urmrete un ca fiecare regul de producie s fie aplicat (testat) cel
puin o dat.
Exemplu. S considerm o clas de expresii aritmetice descris de urmtoarele reguli de producie:
<expresie>::=<expresie>+<termen>|<expresie>-<termen>|<termen>
<termen>::=<termen>+<factor>|<termen>-<factor>|<factor>
<factor>::=<identificator>|(<expresie>)
<identificator>::=a|b|c|d|e|...|z
Un set de cazuri de test pentru testarea derivat din sintax conine expresii ce verific
regulile de mai sus. Un exemplu de expresie mpreun cu regula corespunztoare este dat n figura
urmtoare.

<expresie>::=<expresie>+<termen>
|
<expresie>-<termen>|
<termen>
<termen>::=<termen>+<factor>|
<termen>/<factor>|
<factor>
<factor>::=<identificator>|
(<expresie>)
<identificator>::=a|b\c|d|e|...|
z

Figura 2. Caz de test i regul de producie (subliniat)
5
5.2 Testarea bazat pe tabele de decizie
Aceast form de testare prezint interes atunci cnd cerinele produsului software sunt
formulate cu ajutorul regulilor de decizie de tipul if-then. Exemplele care se preteaz la acest tip
de testare sunt sistemele bazate pe reguli. O regul este de forma:
If cond
1
and cond
2
and cond
3
and ... cond
n
then actiune
Un tabel de decizie este compus dintr-un numr de coloane ce conin toate situaiile de test.
Partea superioar a coloanei conine condiiile ce trebuie satisfcute. Partea de jos a tabelului
specific aciunile care au loc dac sunt satisfcute condiiile din regul. Un exemplu de tabel de
decizie este prezentat n figura 3.
Condiii
... 1
Condiia i 1
... 0
Aciuni
... 0
Aciunea j 1
... 0
Figura 3. Exemplu de tabel de decizie
Exemplu: Controlul nivelului de lichid. S considerm o problem simpl de control care are
specificaiile exprimate sub forma unor tabele de decizie. Se consider un rezervor de lichid cu doi senzori i
dou valve (figura 4). Senzorul 1 detecteaz un nivel maxim acceptabil al lichidului iar senzorul 2 detecteaz
un nivel minim acceptabil al lichidului. Fiecare senzor genereaz valoarea 1 logic dac lichidul depete
nivelul corespunztor. Altfel, senzorii genereaz 0 logic. Valva de intrare se deschide doar dac nivelul scade
sub limita minim (senzorul 2 devine activ) iar valva de ieire se deschide dac senzorul 1 se activeaz. sunt
urmtoarele:

Figura 4. Rezervor de lichid
Reguli:
Dac senzorul 1 este activ (prea
mult lichid n rezervor), atunci se
deschide valva de ieire.
Dac senzorul 2 este activ ( prea
puin nivel n rezervor) atunci se
deschide valva de intrare.

n plus, se adaug o aciune de avertizare n momentul n care senzorul 2 furnizeaz rezultate
eronate. Tabelul de decizie complet are
2
2 4 = coloane (figura 5A). Dac nu intereseaz mesajele
de avertizare n caz de eroare, se poate reduce dimensiunea tabelului de decizie aa cum se poate
observa n figura 5B.
n general, pentru n condiii se va ajunge la 2
n
combinaii, deoarece fiecare coloan a
tabelului trebuie folosit cel puin o dat. Prin urmare vor exista 2
n
cazuri de test. Se observ c i
pentru valori mici ale lui n, tabelul de decizie ajunge la dimensiuni mari. Aceast cretere
exponenial se explic prin faptul c nu au fost luate n considerare constrngerile ntre variabilele
din condiii, constrngeri ce presupun limitri fizice i conceptuale ntre variabile. A treia coloan
din tabelul de decizie din figura 5B poate fi astfel eliminat.
6
n seciunea urmtoare vom prezenta metoda de testare bazat pe grafuri cauz efect care
elimin neajunsul major al metodei bazate pe tabele de decizie, i anume creterea exponenial a
dimensiunii tabelelor odat cu creterea numrului de reguli.


S 1 0 0 1 1 Condiii S 1 0 1 1 Condiii
S 2 0 1 0 1 S 2 0 0 1
Deschide
valv ieire
0 0 0 1 Deschide
valv ieire
0 0 1
Deschide
valv intrare
1 0 0 0 Aciuni Deschide
valv intrare
1 0 0 Aciuni
Trimite
mesaj eroare
0 1 0 0 Trimite
mesaj eroare

Figura 5A. Tabel de decizie complet Figura 5B. Tabel de decizie redus
5.3 Testarea funcional bazat pe grafuri cauz-efect
Principalul dezavantaj al metodei bazate pe tabele de decizii este c intrrile sunt luate n
considerare separat chiar dac problema necesit o alt abordare. Garfurile cauz-efect iau n
considerare relaiile dintre combinaii specifice de intrri (cauze) i ieiri (efecte). Se evit n acest
mod creterea exponenial a dimensiunii tabelelor de decizie. Cauzele i efectele sunt reprezentate
ca noduri ale grafului. Un astfel de graf include un numr de noduri intermediare care leag cauzele
i efectele prin expresii logice.
Exemplu. Se consider un bancomat (ATM) simplu. Lista cauzelor i efectelor este urmtoarea:
Cauze
C1: comanda este creditare
C2: comanda este debitare
C3: numrul de cont este valid
C4: tranzacia este valid

Efecte
E1: tiprete comand nevalid
E2: tiprete numr cont nevalid
E3: tiprete sum debit nevalid
E4: cont debit
E5: cont credit
Graful cauz-efect este prezentat n figura 6.
Nodurile intermediare realizeaz operatorii logici and i or. Simbolul de negare stabilete
faptul c efectul are valoarea de adevr true doar dac nodul asociat este false.
Graful cauz-efect ajut la determinarea cazurilor de test corespunztoare. Aceste cazuri de test se
obin parcurgnd n sens invers (de la efect la cauz) poriuni din graful prezentat n figura 6. dac spre
exemplu suntem interesai n determinarea cauzelor efectului E
3
se urmrete poriunea de graf prezentat n
figura 7.


Figura 6. Graf cauz-efect









Figura 7. Determinarea cauzelor
efectului E
3


7
Se observ c C
2
, C
3
i C
4
determin E
3
, n timp ce cauza C
1
nu influeneaz E
3
. Cauza C
1
poate fi
privit drept o condiie de tip nu conteaz, ce va fi notat cu x. Aceast observaie reduce dimensiunea
tabelului de decizie corespunztor. Coloana din tabelul de decizie care va fi folosit la generarea cazurilor de
test este:
C
1

C
2

C
3

C
4

X 1 1 0
Dac nu se iau n considerare condiiile de tip nu conteaz, poriunea rezultat din tabelul de
decizie va conine
1
2 2 = coloane ce implic o enumerare a valorilor cauzei C
1
.
Tabelul de decizie corespunztor grafului cauz-efect al unui ATM const n cinci coloane cu un
numr substanial de condiii de tip nu conteaz (figura 8). Dac nu ignorm aceste condiii, va rezulta un
tabel cu
4
2 16 = coloane.

C1 0 1 x x 1
C2 0 x 1 1 x
C3 x 0 1 1 1
C4 x x 0 1 1
E1 1 0 0 0 0
E2 0 1 0 0 0
E3 0 0 1 0 0
E4 0 0 0 1 0
E5 0 0 0 0 1
Figura 8. Tabel de decizie ATM

n general, dac se dorete generarea unui tabel de decizie redus, se va adopta un mecanism
de tip backtracking pentru traversarea unui graf de la efecte spre cauze (Ghezzi et al., 1991):
La parcurgerea invers a unui nod or a crui ieire este true se vor utiliza doar combinaii de
intrri care au valoarea de adevr true. Dac, spre exemplu, avem trei cauze (a, b, c) ce
afecteaz un nod de tip or a crui ieire este true, se vor considera doar combinaiile
<a=true, b=false, c=false>, <a=false, b=true, c=false>, <a=false, b=false, c=true>.
La parcurgerea invers a unui nod and a crui ieire este false se vor utiliza doar combinaii
de intrri care au doar o singur valoare false. Pentru exemplul precedent, se vor considera
combinaiile <a=false, b=true, c=true>, <a=true, b=false, c=true>, <a=true, b=true, c=false>.
n grafurile cauz-efect pot fi introduse constrngeri suplimentare ntre intrri, cum ar fi cele
de tipul a implic b. Acestea reduc numrul cazurilor de test deoarece unele combinaii de intrri
nu vor mai fi luate n considerare n procedura de testare.
6. Condiii de testare la limit
Testarea de tip white box, care necesit cunoaterea codului, nu se poate face pentru cazurile
care nu sunt vizibile n mod explicit, sau care nu sunt suficient reliefate. S considerm spre
exemplu o instruciune de tipul if (x>y) then S
1
else S
2
. Aceast form a unei instruciuni
condiionale este generic i se ntlnete n multe tipuri de probleme. S considerm spre exemplu
doi senzori ale cror citiri (x i y) sunt folosite pentru luarea unor decizii, notate S
1
i S
2
. Condiia
x>y determin dou clase de echivalen:
E
1
clasa de echivalen a valorilor lui x i y pentru care x y >
E
2
clasa de echivalen a valorilor lui x i y pentru care x y
Cele dou clase de echivalen sunt formate din perechi de valori citite (x,y) care determin
valoarea de adevr a condiiei relaionale asociate. Criteriul de acoperire a ramurilor (care presupune
testarea tuturor ramurilor din program) duce la selectarea a dou combinaii de intrri: una
8
provenind din E
1
i cealalt din E
2
(vezi figura 9). Se testeaz cile x y > i x y < . Cazul x y = ,
care este parte a clasei de echivalen E
2
, are o probabilitate nul de a fi testat, deci nu va fi selectat
niciodat pentru testare. Cu toate acestea, cazul la limit x y = prezint interes i din acest motiv, se
poate prevedea o cale de realizare.



Figura 9. Condiia de testare la limit x = y
7. Testarea exhaustiv
Testarea exhaustiv face parte din metoda de testare black box. Cu toate c este
impracticabil, ea furnizeaz o imagine asupra complexitii procesului de testare. Un test exhaustiv
trebuie s arate c programul funcioneaz corect pentru toate intrrile posibile. Cnd ne referim la
intrri trebuie s avem n vedere i aspectele hardware ale realizrii codului.
Exemplu. Se consider ecuaia de gradul doi de forma
2
ax bx c 0 + + = , unde a, b, c sunt
parametrii ecuaiei. Din punct de vedere funcional, programul transform spaiul tridimensional al
parametrilor (a, b, c) ntr-un spaiu bidimensional al rdcinilor ecuaiei (r
1
, r
2
). Testarea exhaustiv pleac de
la reprezentarea intern a parametrilor. Dac presupunem c reprezentarea intern este pe 16 bii, pentru
fiecare intrare vom avea
16
2 cazuri de test. Considernd toate cele trei intrri, vom avea n final
48
2 cazuri
de test ce trebuie executate, ceea ce este nefezabil.
8. Testarea structural
Testarea structural presupune dezvoltarea de cazuri de test ce iau n considerare structura
codului (logica intern). Exist mai multe categorii de testarea structural, funcie de ct de complet
trebuie s fie procesul de testare i de restriciile de timp.
Testarea la nivel de instruciune este o form de testare primar, care necesit executarea
fiecrei instruciuni cel puin o dat.
Exemplu. Se consider urmtoarea poriune de cod care se presupune c determin modulul lui y.
begin
if (y 0) then y = 0-y; abs = y;
end;
Cazul de test y 0 = este suficient pentru a testa toate instruciunile din poriunea de cod prezentat.
Este evident faptul c aceast form de testare nu detecteaz o eroare evident a codului i anume aceea c nu
se calculeaz de fapt modulul numrului y.
Testarea la nivel de ramur. Cazurile de test sunt alese astfel nct fiecare ramificaie a
codului s fie executat cel puin o dat.
Exemplu. Dac ne referim la instruciunea anterioar, cazurile de test y 0 = i y 4 = sunt
suficiente pentru a executa ambele variante ale blocului de decizie. Pentru y 0 abs 0 = = . Pentru
9
y 4 abs 4 = = , ceea ce indic o eroare. Indiscutabil, aceast metod de testare conduce la detectarea
erorilor.
Testarea la nivel de ramur/condiie. Fiecare ramur trebuie parcurs cel puin o dat i
toate combinaiile posibile ale condiiilor de decizie trebuie executate.
Exemplu. Se consider instruciunea:
if ((x<val_1) && (y>val_2)){z=calculeaza_1(x,y);
else z= calculeaza_2(x,y);}
S considerm cazurile de test x 4, y 10 = = , x 6, y 12 = = . n primul caz, blocul de decizie
returneaz false i atunci se execut o ramur a codului, iar n cel de-al doilea caz, blocul de decizie
returneaz true i atunci se execut cealalt ramur a codului. Se observ faptul c, dac o eroare este
asociat cu o condiie compus dintr-un bloc de decizie, ea rmne nedetectat. Din acest motiv, testarea
trebuie completat cu verificarea tuturor subcondiiilor ce apar n blocul de decizie. Deoarece n exemplul
prezentat avem dou subcondiii n blocul de decizie, trebuie adugate dou perechi suplimentare de teste i
anume (true, false) respectiv (false, true).
Observaie. Dac fiecare subcondiie este privit ca o intrare singular, atunci acest tip de
testare este analog testrii exhaustive, n condiii necesitnd
n
2 cazuri de test. n cazul n care
n crete, testarea poate deveni nefezabil.
Testarea la nivel de cale. Criteriul de acoperire a cilor consider toate cile logice dintr-un
program i duce la cazuri de test care verific programul de-a lungul fiecrei astfel de ci. Acest
criteriu poate deveni impracticabil, mai ales n situaiile n care programul are un numr mare de
ci. Cu toate acestea, este o metod de testare folosit, mai ales pentru c permite detectarea
defectelor nedescoperite prin testarea la nivel de ramur.
Exemplu. Se consider schema logic din figura 10.

Figura 10. Exemplu de schem logic
Dac se urmrete o testare la nivel de ramur se
pot alege urmtoarele cazuri de test:
x 1, y 5 = = , x 0, y 12 = =
Aceste dou cazuri de test acoper toate ramurile
schemei logice (vezi figura 11), dar execuia lor corect
nu garanteaz lipsa erorilor.
S considerm situaia n care la un anumit moment
x 0 = . n acest moment raportul y / x eueaz. Acest
scenariu nu a fost luat n considerare prin cazurile de
test anterioare.


Figura 11. Testarea la nivel de ramur
10
Testarea la nivel de cale evit situaia prezentat anterior. Se pot considera urmtoarele cazuri de
test:
x 1, y 5 = = ; x 2, y 15 = = ; x 0, y 7 = = ; x 0, y 13 = = .


Figura 11. Testarea la nivel de cale

Observaie. Se observ c i n cazul unui exemplu relativ simplu, numrul de ci ce trebuie
parcurse este mai mare dect numrul ramurilor.
Din cauza complexitii principiului acoperirii cilor este esenial numrarea cilor dintr-un
program.
n cazul lipsei buclelor, numrul cilor este determinat de numrul de noduri de decizie i
de distribuia lor. Cele dou extreme ale numrului de ci dintr-un graf se pot observa n exemplul
din figura 12. n cazul n care se unesc ramurile, blocurile de decizie sunt stivuite unele peste
altele (figura 12a). Unirea ramurilor poate duce la
n
2 ci posibile. Numrul maxim de ci dintr-un
graf este deci
n
2 . n cazul n care nu se face unirea ramurilor exist n 1 + ci posibile (vezi figura
12b), deci:
n 1 + numr de ci
n
2
Este de remarcat faptul c i n cazul valorilor mici pentru n, ntre cele dou limite exist o
diferen semnificativ. Pentru a micora aceast diferen se poate face o descompunere a grafului
original n pri mai mici i se determin extremele separat. S considerm spre exemplu un graf cu
6 noduri de decizie. n acest caz limitele ar fi 7 i 64. Dac se mparte graful original n trei pri,
fiecare coninnd 2 noduri, limitele pentru fiecare parte ar fi 3 i 4. Numrul de ci de testat n
graful original este cuprins ntre 27( 3*3*3) = i 64( 4*4*4) = .
11

(a) ramuri unite

(b) ramuri neunite
Figura 12. Cazuri de acoperire a cilor
n cazul grafurilor ce conin bucle, acoperirea cilor va fi restricionat la bucle ce sunt
traversate doar o singur dat. Utiliznd aceast abordare, se poate transforma orice graf cu o bucl
la unul fr nici o bucl. Ideea este de a mpri orice nod, s zicem A, care este nod terminal al unei
ci cu reacie n A i A. Noul nod este conectat cu nodul final sau cu orice alt nod de mai jos.
Construciile de baz ale programrii structurate pot fi transformate n grafuri fr bucle (figura 13).
Enumerarea cilor va fi dat de sumele produselor limitelor grafului fr bucle.
Exemplu. S considerm graful din figura 14. Se pornete cu frontierele care fac parte din toate
cile posibile. Acestea sunt, evident, a i h. Atunci:
FGC aFGC h

= ,
unde FGC este funcia de generare a cii iar este funcia de generare a cii pentru sub-graful dintre B i E.
n continuare se construiete funcia de generare a cii pentru , FGC

:



Figura 13. Transformarea schemei logice n grafuri fr bucle
FGC de bFGC

= + ,
unde semnul + se folosete pentru operaia sau. Pentru sub-graful cu nodurile C, B, E i E se
obine:
FGC f cbf

= + .
Revenind la expresia original se obine:
12
FGC aFGC h a(de bFGC )h a(de b(f cbf ))h adeh abfh abcbfh

= = + = + + = + +

Figura 14. Conversia unui graf ntr-un graf echivalent fr bucle

Se poate observa c numrul de ci poate crete foarte mult, mai ales pentru poriunile de
cod cu fluxuri de control semnificative. Acest fapt limiteaz aplicabilitatea acestei metode de
testare.
Criteriul de testare a cilor nu poate detecta toate defectele, deoarece se bazeaz pe faptul c
specificaiile software sunt transformate cu exactitate n cod. Lipsa unor elemente ngreuneaz
semnificativ testarea.
9. Testarea regresiv
Scopul acestei metode de testare este de crea posibilitatea repetrii testelor n momentul n
care apare o modificare a produsului software. Exist dou activiti principale ale testrii regresive:
Stabilirea unui test (sau a unei serii de teste) pentru reluare. Regula este s se mearg pe
teste puternice (i anume acele teste cu nivel mare de acoperire).
Compararea ieirilor noi cu cele vechi (de baz) pentru a fi siguri c nu exist schimbri
nedorite.
Pentru testarea regresiv efectiv, trebuie realizate prelucrri suplimentare ale seriilor de
test.
Eficacitatea testrii regresive se exprim n termenii urmtoarelor condiii: (a) ct de grea
este construirea i meninerea seriilor de test i (b) ct de fezabil este sistemul de testare regresiv.
10. Testarea software static
Testarea static, spre deosebire de cea dinamic, nu se concentreaz asupra execuiei
codului. Exist dou variante de tehnici de testare static:
tehnici informale care includ trecerile rapide prin cod i inspectarea propriu zis a
codului;
tehnici formale ce cuprind demonstraii de corectitudine i execuia simbolic.
10.1 Tehnici informale
Tehnicile informale au fost introduse la sfritul anilor 70 i difer prin faptul c, dac
inspectrile softului sunt orientate pe reacie, trecerile prin cod se bazeaz pe interaciunea dintre
testeri, membrii echipei proiectului i alte persoane implicate n proiect.
Inspectrile sunt activiti realizate de o echip experi care verific proiectul sau codul cu
scopul de a identifica erorile. Au fost propuse n 1976 de Fagan i au fost dezvoltate de IBM. O
inspectare conine cinci pai principali:
Privirea de ansamblu asupra documentelor ce trebuie inspectate
Pregtirea. Participanii ncearc s neleag documentul n detaliu. Tipurile de erori i
frecvena acestora gsite n inspeciile recente sunt utile pentru ca atenia s se concentreze asupra
ariilor predispuse n msur mai mare la erori
13
Inspectarea. Pentru nceput, un participant parcurge codul mpreun cu echipa de
inspecie, asigurndu-se c fiecare problem este acoperit i c fiecare ramur e parcurs cel puin
o dat. Fiecare participant continu cu propria list de verificare. Scopul este de a gsi i documenta
erorile, nu de a le nltura. Liderul echipei de inspecie (moderatorul) are ca sarcini pregtirea
raportului scris i asigurarea unei rezolvri potrivite
Refacerea. Erorile i problemele din raportul scris sunt rezolvate
Continuarea. Moderatorul se asigur c toate problemele ridicate au fost rezolvate. Toate
rezolvrile trebuie verificate pentru a fi siguri c nu au fost introduse noi erori. n cazul n care mai
mult de 5% din materialul inspectat a fost refcut, echipa se reunete pentru o nou inspectare.

Echipa responsabil cu inspectarea este format n general din 3-6 persoane. Spre exemplu,
dac se inspecteaz proiectul, echipa va conine un moderator, un proiectant, un dezvoltator i un
tester. Fiecare inspecie trebui s utilizeze o list de verificare a defectelor poteniale (cum ar fi
corespondena ntre specificaii i proiectare, ntre parametrii actuali i cei formali ai interfeelor,
compatibilitatea softului cu hardware-ul disponibil etc.). Rezultatele inspeciei sunt nregistrate
funcie de nivelul de severitate i tip. Pentru ca inspecia s aib succes ea trebuie s aib un caracter
iterativ. n cazul inspectrii codului activitile au scopul de a descoperi erorile obinuite sau pe cele
provenind din clase specifice cum ar fi:
Variabile neiniializate;
Salturile n interiorul buclelor;
Bucle fr condiie de terminare;
Indexarea vectorilor n afara limitelor;
Nepotriviri ntre parametrii actuali i cei formali.
Trecerea rapid prin cod presupune organizarea unor ntlniri de lucru pentru analizarea
unui produs software, unui modul de cod, unui plan de testare etc. Aciunea este condus de un
persoan ce face o prezentare a produsului ce trebuie analizat. Erorile sunt nregistrate de un
coordonator. Grupul de lucru se concentreaz pe detecia erorilor, nu pe corecia lor. n general, o
astfel de echip este format din urmtorii membri: un prezentator al problemelor ce trebuie
revzute, un coordonator al echipei de lucru, un secretar ce se ocup cu pregtirea tuturor
materialelor necesare, un reprezentant al persoanelor ce se ocup cu ntreinerea produsului, o
persoan responsabil cu ndeplinirea standardelor interne i un reprezentant al clientului.
10.2 Tehnici formale
Tehnicile formale constau n demonstraii de corectitudine i execuie simbolic.
Demonstraiile de corectitudine se bazeaz pe observaia c orice poriune de cod (program)
este un obiect formal, n timp ce orice specificaie poate fi realizat printr-o metod formal.
Aceasta nseamn c se pune accentul pe echivalena dintre program i specificaii. Echivalena
poate fi pus n eviden printr-o demonstraie matematic.
Execuia simbolic utilizeaz simboluri n locul valorilor numerice, adic se bazeaz pe
clase de date. Pentru a ilustra esena acestei idei s considerm urmtorul exemplu:
x = 7*y;
if (x>a) then a = a+x-3 else y = sin(x/2);
b = x+a*y;
n figura 15 literele mari cum ar fi X sau Y semnific valori simbolice, acestea corespunznd
variabilelor originale utilizate n cod). S presupunem c la nceputul execuiei simbolice, x X = i a A = .
Prima instruciune duce la X 7*Y = . Celelalte variabile rmn neschimbate. Blocul de decizie poate fi
activat pe oricare din cele dou direcii (comparaia 7*Y A > poate fi adevrat sau fals). Vom selecta
unul din cele dou fire de execuie ca un triplu de forma:
<valori variabile simbolice, cale de execuie, condiie>
14
Cele dou ci de execuie sunt asociate grafului de control al fluxului.

Figura 15 Exemplu de execuie simbolic
11. Testarea la integrare
Componentele majore rezultate din scrierea codului se integreaz formnd sistemul final.
Stilul de testare ales depinde de strategia aleas pentru proiectarea sistemului software. n
cazul strategiei de proiectare top-down (care presupune o serie de rafinri succesive) se utilizeaz
module nlocuitoare sau substitute (stubs) care au rolul de a emula modulele ce nu au fost dezvoltate
nc (vezi figura 16). n cazul strategiei de proiectare bottom-up sistemul se dezvolt plecnd de la
module detaliate, implementnd funcii din ce n ce mai complexe. Se utilizeaz modulele driver
pentru reprezentarea modulelor de nivel mai nalt ale cror nume le poart (vezi figura 17).

Figura 16. Strategia top-down de
testare a sistemului

Figura 17. Strategia bottom-up de
testare a sistemului
Plecnd de la strategiile de proiectare se pot defini urmtoarele strategii de testare la
integrare:
Testarea bottom-up pleac de la module detaliate i se extinde spre nivele mai nalte
ale ierahiei; aceast testarea necesit drivere.
Testarea top-down - pornete de la modulul de pe cel mai nalt nivel i necesit
substitute.
Testarea big-bang - modulele se integreaz ntr-un singur pas iar testarea se face asupra
ntregului sistem.
Testarea n straturi suprapuse - combin testarea bottom-up i top-down definind un
anumit strat int n ierarhia modulelor; modulele inferioare stratului int se testeaz printr-o
abordare bottom-up iar cele superioare printr-o metod top-down.
Observaie. Exist situaii n care unele module nu sunt testate separat la testrile bottom-up i top-
down.
15

Figura 18. Ierarhie de module
software
Exemplu. Pentru a ilustra aceste
idei de testare, s considerm o
ierarhie simpl de module ca n figura
18.
n figura 19 sunt prezentate
clasele de testare la integrare pentru
exemplul anterior.






Testare bottom-up

Testare top-down




Testare big-bang

Testare n straturi
Stratul de test este situat ntre
A i (B, C, D)
Figura 19. Exemple de testri la integrare