TESTAREA SISTEMELOR SOFTWARE

Testarea estimeaz nivelul de performan al unui sistem software i determin dac acesta este gata de livrare. 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 mod obinuit, spunem c un sistem software eueaz atunci cnd nu ndeplinete cerinele impuse. Funcionarea defectuoas poate fi rezultatul unuia dintre urmtoarele motive: - 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.

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 - specificarea precondiiilor i a postcondiiilor; analiza anomaliilor se caut eventuale comportri anormale ale programului (spre exemplu, poriuni de cod care nu sunt executate niciodat); inspecia codului. 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.

Clasificarea metodelor de testare

Testarea black box (cutie neagr) - se concentreaz asupra intrrilor, ieirilor i funcionalitii modulelor software. - 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 (cutie alb) - presupune inspectarea structurii codului modulelor software. - cunoscut i sub numele de testare structural; - se verific executarea corect a tuturor cilor i ramurilor codului testat.

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: punctul de vedere al proiectanilor - care fac tot posibilul pentru a realiza un produs fr defecte. punctul de vedere al managerilor de proiect care iau n considerare constrngerile de timp impuse proiectului.

Etapele principale ale unei scheme de testare: Selectarea a ceea ce trebuie msurat (cuantificat) de testul respectiv. o nainte de realizarea testului, trebuie identificate scopurile acestuia. o Scopurile pot fi diferite (spre exemplu, testarea fiabilitii, testarea completitudinii cerinelor). Stabilirea modului cum se face testarea a ceea ce trebuie testat. o Dup ce se stabilete ce este de testat, se stabilete modalitatea de realizare a testelor relevante. Dezvoltarea cazurilor de test. o Pentru tipurile de testare deja acceptate, trebuie creat o colecie de cazuri de test (situaii de test) pentru antrenarea sistemului supus testrii. Determinarea rezultatelor ateptate ale testului respectiv. Executarea cazurilor de test. Compararea rezultatele obinute cu cele ateptate.

Niveluri ale testrii software Testarea software se realizeaz la diferite niveluri de-a lungul ntregului ciclu de via al produsului. Tabelul 2. Niveluri ale testrii conform standardului IEEE 1059-1993 Testare Definiie Scop Component Se verific implementarea Logica programului este complet i elementelor software (ex. corect. funcii, module). Componentele funcioneaz conform proiectrii. Integrare Componentele software i Obiectivele proiectrii sunt satisfcute hardware sunt combinate i testate pn la integrarea ntregului sistem Sistem Se testeaz sistemul integrat Proiectul software este o entitate complet n concordan cu cerinele operaionale. Acceptare Se verific dac rezultatele Obiectivele clienilor sunt satisfcute testelor satisfac criteriile de acceptare ale clienilor

Activitile fazei de testare 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 identificarea surselor i nivelurilor de risc i stabilirea persoanelor 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; 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. Generare plan testare

Ingineria cerinelor

Generare proiect testare

Proiectare Implementare Testare

Generare cazuri testare

Generare procedur testare

Execuie testare

Tipuri de teste software innd cont de multitudinea metodelor de testare existente este avantajoas luarea n 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 i 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, procedurilor i funciilor. 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: - utilizarea 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 temporizare (au loc n sistemele n timp real care folosesc memorie partajat sau transmitere de mesaje).

Testarea funcional
Testarea derivat din sintax se aplic sistemelor ale cror specificaii sunt descrise de o anumit gramatic; deoarece specificarea formal a unor astfel de sisteme se exprim prin reguli de producie, generarea cazurilor de test urmrete ca fiecare regul de producie s fie aplicat (testat) cel puin o dat. Exemplu. Se consider 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 <expresie>::=<expresie>+<termen>| <expresie>-<termen>| <termen> <termen>::=<termen>*<factor>| <termen>/<factor>| <factor> <factor>::=<identificator>|(<expresie>) <identificator>::=a|b|c|d|e|...|z

Testarea bazat pe tabele de decizie prezint interes atunci cnd cerinele produsului software sunt formulate cu ajutorul regulilor de decizie de tipul if-then; sistemele 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. Condiii ... 1 Condiia i 1 ... 0 Aciuni ... 0 Aciunea j 1 ... 0 Exemplu: Controlul nivelului de lichid.

 Se consider un rezervor de lichid cu doi senzori i dou valve. 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.

Regulile de producie sunt urmtoarele:: Dac senzorul 1 este activ atunci se deschide valva de ieire. Dac senzorul 2 este activ atunci se deschide valva de intrare. Se adaug o aciune de avertizare n momentul n care senzorii furnizeaz 0 logic. Tabelul de decizie complet are 22 = 4 coloane (figura a). Dac nu intereseaz mesajul de avertizare, se poate reduce dimensiunea tabelului de decizie aa cum se poate observa n figura b. S1 S2 Deschide valv ieire Deschide valv intrare Trimite mesaj 0 0 1 1 0 1 0 1 0 0 1 1 0 1 0 1 1 0 0 0 Figura a. Tabel de decizie complet 0 1 0 1 1 0 1 0 1 1 1 1 Condiii

Aciuni

S1 S2 Deschide valv ieire Deschide valv intrare Trimite mesaj

Condiii

Aciuni

Figura b. Tabel de decizie redus

 n general, pentru n condiii se va ajunge la 2n combinaii, deoarece fiecare coloan a tabelului trebuie folosit cel puin o dat vor exista 2n cazuri de test. Se observ c i pentru valori mici ale lui n, tabelul de decizie ajunge la dimensiuni mari. o 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. innd cont de faptul c, din punct de vedere fizic, senzorii nu pot furniza 1 logic n acelai timp, a treia coloan din tabelul de decizie din figura b poate fi eliminat.

Testarea funcional bazat pe grafuri cauz-efect Principalul dezavantaj al metodei bazate pe tabele de decizie 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.

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: debitare cont E5: creditare cont

C1 or

E1

E2 C2

and E3

C3

and

E4
and

C4 E5
and

Graf cauz-efect

Tabelul de decizie corespunztor grafului cauz-efect al unui ATM const n cinci coloane cu un numr substanial de condiii de tip nu conteaz - notate cu x. Dac nu ignorm aceste condiii, va rezulta un tabel cu 24 = 16 coloane. C1 C2 C3 C4 E1 E2 E3 E4 E5 0 0 x x 1 0 0 0 0 1 x 0 x 0 1 0 0 0 x 1 1 0 0 0 1 0 0 x 1 1 1 0 0 0 1 0 1 x 1 1 0 0 0 0 1

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

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. 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 provenind din E1 i cealalt din E2. Se testeaz cile x > y i x < y . Cazul x = y , care este parte a clasei de echivalen E2, are o probabilitate mic de a fi testat, deci probabil 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.

Testarea exhaustiv Testarea exhaustiv face parte din metoda de testare black box. Aceast metod este impracticabil dar 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, evident, nefezabil.

Testarea structural
Testarea structural presupune dezvoltarea de cazuri de test ce iau n considerare structura codului (logica intern). Exist mai multe categorii de testare 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. 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; 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 y = 4 abs = 4 , ceea ce indic o eroare. Indiscutabil, acest caz de test 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 = 6, y = 12 , respectiv x = 8, y = 14 . S presupunem c 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.

Exemplu de schem logic

Testarea la nivel de ramur. Cazuri de test: x = 1, y = 5 ; x = 0, y = 15

Testarea la nivel de cale. Cazuri de test:

x = 1, y = 5 ; x = 2, y = 11; x = 0, y = 3 ; x = 0, y = 15

Se observ c numrul de ci ce trebuie parcurse este mai mare dect numrul ramurilor. n cazul lipsei buclelor, numrul cilor este determinat de numrul de noduri de decizie i de distribuia lor. n cazul n care se unesc ramurile, blocurile de decizie sunt stivuite unele peste altele (figura a). 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 b), deci: (a) (b) Cazuri de acoperire a cilor

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. Exemplu: fie 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) . n cazul grafurilor ce conin bucle, acoperirea cilor va fi restricionat la buclele 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. Numrul cilor va fi dat de sumele produselor limitelor grafului fr bucle.

Transformarea schemei logice n grafuri fr bucle

Exemplu. S considerm graful din figur:

Se pornete cu frontierele care fac parte din toate cile posibile, adic 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:

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:

FGC = aFGC h = a(de + bFGC )h = a(de + b(f + cbf ))h = = adeh + abfh + abcbfh
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.

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 (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; (b) ct de fezabil este sistemul de testare regresiv.

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 - includ trecerile rapide prin cod i inspectarea propriu zis a codului; tehnici formale - cuprind demonstraii de corectitudine i execuia simbolic.

Tehnici informale Inspeciile 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.

 Inspecia. - 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 inspecie.

 Echipa responsabil cu inspecia 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 trebuie 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. Un aspect important al fiecrei inspecii este reacia. 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 o 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; - persoan responsabil cu ndeplinirea standardelor interne; - un reprezentant al clientului.

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. Plecnd de la strategiile de proiectare se pot defini urmtoarele strategii de testare la integrare: Testarea top-down - pornete de la modulul de pe cel mai nalt nivel i necesit substitute. Testarea bottom-up pleac de la module detaliate i se extinde spre niveluri mai nalte ale ierarhiei; aceast testare necesit drivere. 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.

n cazul strategiei de proiectare top-down (care presupune o serie de rafinri succesive) se utilizeaz module nlocuitoare sau substitute (engl., stubs) care au rolul de a emula modulele ce nu au fost dezvoltate nc.

Strategia top-down de testare a sistemului

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.

Strategia bottom-up de testare a sistemului

Exemplu. Se consider urmtoarea ierarhie simpl de module:

Testare bottom-up:

Testare top-down:

Testare big-bang:

Testare n straturi. Stratul de test este situat ntre A i (B, C, D):