TESTAREA 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.

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
Dinamic Testare funcional Testare aleatoare Testare pe domenii Graf cauz-efect Testare structural Testare computaional Testare pe domenii Testare ci Generare date Analiza schimbrilor Inspectare cod Verificare program Execuie simbolic Analiz anomalii

Static

Verificare specificaii

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.
2

Tabel 2
Testare Component Integrare Definiie Se verific implementarea elementelor software (ex. Funcii, module). Componentele software i hardware sunt combinate i testate pn la integrarea ntregului sistem Se testeaz sistemul integrat Se verific dac rezultatele testelor satisfac criteriile de acceptare ale clienilor Scop Logica programului este complet i corect. Componentele funcioneaz conform proiectrii. Obiectivele proiectrii sunt satisfcute

Sistem Acceptare

Proiectul software este o entitate complet n concordan cu cerinele operaionale. 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
3

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)

4

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 cond1 and cond2 and cond3 and ... condn 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 ... Condiia i ... Aciuni ... Aciunea j ... 1 1 0 0 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: 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.

Figura 4. Rezervor de lichid n plus, se adaug o aciune de avertizare n momentul n care senzorul 2 furnizeaz rezultate eronate. Tabelul de decizie complet are 22 = 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 2n combinaii, deoarece fiecare coloan a tabelului trebuie folosit cel puin o dat. Prin urmare vor exista 2n 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.

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.
S1 S2 Deschide valv ieire Deschide valv intrare Trimite mesaj eroare 0 0 1 0 1 0 0 0 0 1 0 0 0 1 0 1 1 1 0 0 Condiii S1 S2 Deschide valv ieire Deschide valv intrare Trimite mesaj eroare 0 0 0 1 1 0 0 0 1 Condiii 1 1 0 Aciuni

Aciuni

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 E3 se urmrete poriunea de graf prezentat n figura 7.

Figura 6. Graf cauz-efect

Figura 7. Determinarea efectului E3

cauzelor

Se observ c C2, C3 i C4 determin E3, n timp ce cauza C1 nu influeneaz E3. Cauza C1 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

Dac nu se iau n considerare condiiile de tip nu conteaz, poriunea rezultat din tabelul de decizie va conine 21 = 2 coloane ce implic o enumerare a valorilor cauzei C1. 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 24 = 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 S1 else S2. 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 S1 i S2. Condiia x>y determin dou clase de echivalen: E1 clasa de echivalen a valorilor lui x i y pentru care x > y E2 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
7

provenind din E1 i cealalt din E2 (vezi figura 9). Se testeaz cile x > y i x < y . Cazul x = y , care este parte a clasei de echivalen E2, 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 ax 2 + 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 (r1, r2). Testarea exhaustiv pleac de la reprezentarea intern a parametrilor. Dac presupunem c reprezentarea intern este pe 16 bii, pentru fiecare intrare vom avea 216 cazuri de test. Considernd toate cele trei intrri, vom avea n final 248 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
8

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 2n 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.
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 10. Exemplu de schem logic

Figura 11. Testarea la nivel de ramur

9

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 2n ci posibile. Numrul maxim de ci dintr-un graf este deci 2n . n cazul n care nu se face unirea ramurilor exist n + 1 ci posibile (vezi figura 12b), deci: n + 1 numr de ci 2n 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) .

10

(b) ramuri neunite (a) ramuri unite 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:

11

FGC = aFGCh = 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
12

 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>

13

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 Figura 17. Strategia bottom-up de testare a sistemului 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 topdown.

14

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 Figura 18. Ierarhie de module exemplul anterior. software

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

15