Sunteți pe pagina 1din 247

Cuprins

1. Introducere

4

2. Tehnici de testare software

10

2.1. Testarea – etapă a ciclului de dezvoltare software

10

2.2. Fazele procesului de testare software

18

2.3. Testarea structurală

21

2.4. Testarea funcţională

28

2.5. Testarea software orientată obiect

30

2.6. Testarea sistemelor distribuite bazate pe tehnologia Internet

35

2.7. Testarea sistemelor distribuite bazate pe componente

39

3.

Factori de influenţă a testării

46

3.1. Criterii de clasificare a factorilor

46

3.2. Complexitatea produselor software

47

3.3. Dimensiunea aplicaţiei

55

3.4. Gradul de omogenitate a echipei de realizare software

58

3.5. Tehnici de dezvoltare a produsului program

59

3.6. Stadiul de certificare a firmei

64

3.7. Numărul şi diversitatea utilizatorilor

69

3.8. Factori secundari de influenţă

71

3.9. Interdependenţe de acţiune a factorilor

74

4.

Cheltuieli aferente procesului de testare

76

4.1. Costurile dezvoltării software

76

4.2. Costurile calităţii produselor program

79

4.3. Cheltuieli cu personalul

84

4.4. Cheltuieli pentru instrumente de asistare

88

4.5. Cheltuieli pentru echipamente

91

4.6. Cheltuieli indirecte

92

4.7. Repartizarea cheltuielilor pe nivelurile testării

93

4.8. Repartizarea cheltuielilor pe fazele procesului de testare

96

4.9. Căi de reducere a cheltuielilor de testare

99

5.

Modele liniare de evaluare a costului testării software (CTS)

104

5.1. Estimări şi ipoteze în elaborarea modelelor liniare de evaluare a CTS

104

5.2. Dependenţe liniare unifactoriale identificate în testarea software

108

5.3. Structuri de modele liniare multifactoriale pentru evaluarea CTS

111

5.4. Analiza calităţii modelelor liniare de evaluare a CTS

118

5.5. Rafinarea modelelor liniare de evaluare a CTS

120

5.6. Stabilitatea modelelor liniare de evaluare a CTS

124

6.

Modele neliniare ale costului procesului de testare software

126

6.2.

Modelul polinomial al evaluării costului testării

127

6.3. Modelul produs de evaluare a CTS

6.4. Modelul exponenţial de evaluare a CTS

6.5. Modelul logaritmic de evaluare a CTS

6.6. Modelul hiperbolic de evaluare a CTS

6.7. Alte modele neliniare de evalare a CTS

6.8. Analiza comparată a modelelor neliniare

6.9. Rafinarea modelelor neliniare de evaluare a CTS

7. Tehnologie de ierarhizare a modelelor pentru evaluarea CTS

7.1. Criterii de ierarhizare a modelelor de evaluare a CTS

7.2. Validarea modelelor de evaluare a CTS

7.3. Analiza comparată a modelelor de evaluare a CTS

7.4. Ierarhizarea modelelor pe baza sumei pătratelor de erori

7.5. Ierarhizarea după ponderi a modelelor de evaluare a CTS

7.6. Ierarhizarea bazată pe complexitate a modelelor de evaluare a CTS

7.7. Evaluarea modelelor de evaluare a CTS

8. Probleme ale modelelor de evaluare a CTS în testarea orientată pe

structuri de control şi structuri de date

8.1. Costul testării pentru proceduri care includ structuri de control liniare

8.2. Testarea procedurilor alternative

8.3. Cerinţe ale testării procedurilor repetitive

8.4. Aspecte ale testării procedurilor cu apeluri

8.5. Testarea programelor cu structuri statice

8.6. Particularităţi ale testării programelor cu structuri dinamice

8.7. Procese de testare pentru programele cu structuri agregate

9. Testarea aplicaţiei e-DSI

9.1. Aplicaţia e-DSI

9.2. Aparate foto

9.3. Bugetul meu

9.4. Biblioteca mea

9.5. Agenda mea

9.6. Reţetele mele

9.7. Jurnalul meu

10. Utilizarea modelelor de evaluare a costurilor în testarea aplicaţiei e-DSI

10.1. Particularităţile gestiunii electronice a serviciilor casnice

10.2. Aplicaţia e-DSI utilizată în analiza modelelor de evaluare a CTS

10.3. Structuri de modele pentru evaluarea costurilor testării aplicaţiei

10.4. Analiza comparată a rezultatelor experimentale obţinute

10.5. Ierarhizarea modelelor de evaluare a CTS

11. Concluzii

Anexa 1 – Lista acronimelor utilizate Anexa 2 – Notaţii utilizate Anexa 3 – Instrumente pentru automatizarea testării Bibliografie

128

130

131

133

134

137

138

140

140

142

143

146

148

149

151

156

156

161

166

171

173

176

178

182

182

186

190

197

200

202

206

210

210

211

214

222

224

226

228

230

232

236

1

INTRODUCERE

Perioada actuală pe care o traversează informatica românească impune o nouă abordare a realizării de software, întrucât societatea informaţională înseamnă dezvoltarea de aplicaţii cu grad de complexitate deosebit de ridicat, caracterizate prin fiabilitate şi mentenanţă. Obiectivul acestei lucrări îl reprezintă identificarea costurilor aferente testării software precum şi definirea de modele liniare şi modele neliniare pentru evaluarea costului testării software. Testarea reprezintă o etapă importantă în procesul de realizare a produselor software. În [PETE00], [VLIE00] se specifică faptul că ponderea cheltuielilor cu testarea reprezintă între 30% şi 50% din totalul cheltuielilor pentru dezvoltarea unei aplicaţii software. Tehnicile şi metodele moderne de elaborare a produselor software acordă o importanţă deosebită efortului de înlăturare a erorilor de analiză, proiectare şi programare prin folosirea unor mijloace evoluate de testare. Există numeroase modalităţi de a realiza testarea aplicaţiilor software, dar în toate cazurile se porneşte de la obiectivele specifice şi de la resursele disponibile. Pentru a optimiza procesul de testare se impune evaluarea costurilor pe care le generează această etapă. Din analiza definiţiilor din dicţionarele explicative române şi străine rezultă că estimarea presupune determinarea subiectivă şi aproximativă a valorii unui obiect sau a unei activităţi, înainte ca obiectul sau activitatea să existe în momentul procesului de calcul. Spre deosebire de aceasta, evaluarea este definită ca acţiunea de determinare a valorii unui obiect prin examinarea acestuia, a cărui existenţă este dovedită. Rezultă că în activitatea de modelare tehnicile de estimare sunt folosite pentru construirea modelelor, iar tehnicile şi metodele de evaluare vizează procese de diferenţiere, de analiză, de ierarhizare a unor modele existente în vederea extragerii dintr-o bază de modele a celor mai potrivite în raport cu un context dat.

Evaluarea este asociată unor activităţi, obiecte, sisteme sau fenomene existente pentru care se doreşte obţinerea unui indicator agregat de referinţă care poziţionează respectivul element existent între celelalte de acelaşi fel, în raport cu o scală definită. Estimarea este folosită pentru componente, sisteme sau fenomene care se vor realiza sau se vor derula şi are ca obiectiv, de asemenea, obţinerea unui indicator sau a unor coeficienţi, numiţi estimatori, cu ajutorul cărora se va obţine o valoare privind poziţia, comportamentul sau o calificare a dinamicii produselor software. Tehnicile de evaluare presupun studierea unui proces sau fenomen prin extragerea factorilor de influenţă. Factorii sunt puşi în corespondenţă cu variabilele a căror dinamică este înregistrată sub forma unor serii de date. Tabelul obţinut conţine un număr de coloane egal cu numărul variabilelor independente la care se adaugă seria de date a variabilei dependente. Folosind o metodă de evaluare pentru fiecare variantă de model construită se obţin forme uzuale ale modelelor. Calitatea estimărilor se analizează pentru a avea certitudinea utilizabilităţii modelelor. În lucrare sunt traversaţi aceşti paşi atât pentru modelele liniare cât şi pentru cele neliniare, extrăgându-se din mulţimea de modele unele care se doresc a fi eficiente în raport cu un criteriu specificat. Există produse software realizate care trebuie testate. Pentru a stabili nivelul resurselor necesare se fac determinări sub formă de măsurători ale produselor privind:

numărul de linii sursă;

numărul de module;

complexitatea software;

diversitatea datelor de intrare;

calitatea utilizatorilor.

Pentru produsul existent se obţin date certe privind structura, comportamentul şi se stabilesc obiective clare pe care testarea trebuie să le ofere. Modelul de evaluare a costului testării vizează o expresie analitică obţinută pe baza datelor privind produsele software existente şi conduce la obţinerea unei informaţii agregate privind efortul pe care trebuie să-l facă echipa de testare. Coeficienţii modelului se estimează cu una dintre metodele cunoscute din econometrie. În cazul estimării, produsul software este definit numai în plan conceptual, se vorbeşte de o structură modulară, se stabilesc clasele, interdependenţele, fluxurile, interfeţele şi tipologiile, precum şi nivelurile planificate ale caracteristicilor de calitate.

Pentru fiecare etapă de dezvoltare a produsului software se identifică nivelurile planificate ale resurselor necesare şi duratele planificate. Acestea sunt estimări având la bază experimente, coeficienţi de siguranţă sau coeficienţi de risc cu care sunt ponderate valorile tabelare. În acest context, pentru etapa de testare se construiesc modele de estimare a costurilor. Produsul software este numai o definire conceptuală, toate informaţiile fiind niveluri planificate: durate, resurse, termene. Din punct de vedere structural, între modele de estimare şi cele de evaluare există diferenţe majore. Modelele de estimare sunt expresii analitice care conduc la obţinerea nivelului estimat al costului testării pe baza datelor de intrare, care la rândul lor sunt niveluri estimate ale necesarului de resurse sau ale caracteristicilor de calitate cu care este înzestrat produsul. Diferenţa între cele două tipuri de modele constă în faptul că rezultatul obţinut prin modelul de evaluare comparat cu costul efectiv nu trebuie să difere foarte mult, în timp ce între nivelul estimat al costului testării şi nivelul efectiv al costului, diferenţele pot fi foarte mari, pentru că apar abateri în procesul de dezvoltare. În cazul în care (1) se creează o bază de date puternică în care sunt stocate informaţii suficiente privind grupe omogene de produse software, (2) înregistrările sunt în paralel pentru proiect şi pentru produsul existent, (3) se vor efectua estimări suficient de fine ale coeficienţilor şi (4) se vor găsi modele comune, costul testării estimat şi cel evaluat nu vor mai diferi semnificativ. Lucrarea prezintă tehnici şi metode de testare software şi identifică factorii care influenţează nivelul costurilor testării. După realizarea acestor etape se procedează la construirea de modele destinate evaluării costului testării. Sunt prezentate modele liniare şi modele neliniare de evaluare a costului testării, precum şi o tehnologie de ierarhizare a modelelor. Diversitatea modelelor impune selectarea unor proceduri de validare care permit punerea în corespondenţă a modelelor cu tipuri de produse software aparţinând unor clase de complexitate distincte. Abordarea de faţă se bazează pe cercetări întreprinse pe parcursul a mai multor ani şi include rezultate pe care autorul le-a prezentat în articole publicate în reviste de specialitate şi la conferinţe şi simpozioane naţionale şi internaţionale. Pentru modelele prezentate au fost utilizate instrumente de evaluare a coeficienţilor şi s-a procedat la efectuarea de experimente, măsurându-se acurateţea acestora.

Cercetările întreprinse în domeniul testării software şi în domeniul modelării costurilor acestui proces au impus verificarea tuturor ipotezelor folosind mai multe aplicaţii informatice, dintre care în lucrarea de faţă se includ rezultate obţinute referitoare la aplicaţia de servicii casnice electronice, căreia i s-a asociat acronimul e-DSI (electronic Domestic Services Integration), la care se fac referiri în această lucrare. Aplicaţia are peste 4000 linii sursă şi a fost scrisă utilizând limbajul de programare Java. La realizarea aplicaţiei au fost folosite principii de design specifice utilizatorilor neomogeni din punct de vedere al nivelului de instruire. S-a urmărit trecerea printr-o succesiune de iteraţii la un stadiu rafinat care să conducă la maximizarea ratei de acces cu finalitate din punct de vedere al oricărui utilizator. Vocabularul utilizat este accesibil membrilor colectivităţii neomogene şi de asemenea, sunt utilizate formule imperative. Alegerea aplicaţiei pentru care se experimentează ipotezele avansate în capitolele 5, 6 şi 7 are la bază necesitatea dezvoltării de software pentru accesul unor tipologii neomogene de utilizatori, cu maximizarea ratei de succes a finalizării actului de referire lanţ de proceduri. Lucrarea este structurată pe mai multe capitole şi abordează gradat problematica modelării costurilor determinate de efortul necesar testării software. Capitolul ”Tehnici de testare software” prezintă procesul de testare, tehnicile şi metodele de testare specifice aplicaţiilor software. Sunt avute în vedere aplicaţiile clasice, aplicaţiile realizate utilizând tehnologii orientate obiect şi aplicaţiile distribuite. În capitol sunt făcute referiri la utilizarea tehnicilor de testare pentru aplicaţia e-DSI. În capitolul ”Factori de influenţă a testării” sunt dezvoltate aspectele care permit identificarea factorilor de influenţă a costurilor testării, dintre care complexitatea produselor software şi apartenenţa la o clasă de utilizare reprezintă elementele de bază. Este descris fiecare factor în parte şi se prezintă modul de influenţă a acestora asupra efortului de testare. Capitolul ”Cheltuielile aferente procesului de testare” prezintă diversitatea cheltuielilor care apar în procesul de testare, precum şi repartizarea acestora de-a lungul acestui proces. Este descrisă fiecare categorie de cheltuieli identificată şi sunt prezentate căi de reducere a cheltuielilor care apar în procesul de testare. ”Utilizarea modelelor liniare în evaluarea costului testării software (CTS)” este capitolul în care se propune o serie de modele liniare pentru evaluarea costului testării. În funcţie de factorii care influenţează costul testării identificaţi sunt construite modelele liniare pentru evaluarea costului testării. Este propusă o modalitate de analiză a modelelor liniare obţinute. De asemenea, sunt identificate căi de rafinare a modelelor liniare şi se

studiază stabilitatea modelelor. Prin utilizarea seturilor de date ale aplicaţiei e-DSI se estimează coeficienţii modelelor şi se selectează modelele eficiente. În capitolul ”Modele neliniare ale costului procesului de testare software” se dezvoltă aspectele de bază care conduc la elaborarea de modele neliniare ale costului testării software. Sunt descrise o serie de modele care au la bază funcţii neliniare şi sunt prezentate curbele de evoluţie ale costului în funcţie de factorii luaţi în considerare şi modalităţile de estimare a parametrilor. De asemenea, se identifică posibilităţi de rafinare ale modelelor neliniare. În capitolul ”Tehnologie de ierarhizare a modelelor pentru evaluarea CTS” sunt prezentate mai multe metode pentru ierarhizarea modelelor de evaluare a costurilor testării. Se obţin diferite structuri arborescente de ierarhizare corespunzătoare abordărilor specifice domeniilor de aplicabilitate ale produselor software. Pentru fiecare metodă de ierarhizare propusă sunt prezentate elementele necesare implementării unei aplicaţii care să realizeze ierarhizarea modelelor de evaluare a costului testării software în conformitate cu criteriul de ierarhizare luat în considerare. Capitolul ”Probleme ale modelelor de evaluare a CTS în testarea orientată pe structuri de control şi structuri de date” analizează testarea software şi costurile asociate acesteia prin prisma structurilor de program existente în cadrul procedurilor aplicaţiei. Se are în vedere testarea software diferenţiată a programelor pentru structurile liniare, structurile decizionale, structurile repetitive, structurile de date statice şi structurile de date dinamice. În capitolul ”Testarea aplicaţiei e-DSI” este descrisă aplicaţia e-DSI şi procesul de testare aferent acesteia, fiind prezentate cazurile de test elaborate pentru testarea acesteia. În capitolul ”Utilizarea modelelor de evaluare a CTS în testarea aplicaţiei e-DSI” sunt puse în aplicare modelele de evaluare a costurilor luate în considerare. Au fost parcurse toate etapele în dezvoltarea aplicaţiei şi au fost strânse informaţii privind efortul de testare indus. Sunt analizate comparativ rezultatele obţinute pe cale experimentală. La sfârşitul lucrării sunt incluse trei anexe. În lucrare au fost utilizate o serie de acronime a căror semnificaţie este dată în anexa ”Lista acronimelor utilizate ”. Anexa ”Notaţii utilizate” conţine semnificaţia celor mai importante variabile utilizate în lucrare.

În anexa ”Instrumente pentru asistarea procesului de testare” sunt prezentaţi principalii producători de produse pentru asistarea testării software şi sunt descrise instrumentele utilizate în testarea automată care există pe piaţa mondială la ora actuală. Pentru majoritatea produselor sunt date şi preţurile acestora. În ideea realizării unei aplicaţii denumită e-DSIEX, care să extindă aplicaţia e-DSI, se fac estimări cu privire la caracteristicile noii aplicaţii (număr de linii sursă, complexitate, productivitatea muncii) astfel încât pe baza acestora să se estimeze costul testării aplicaţiei extinse. Complexitatea procesului de testare presupune antrenarea unui volum important de resurse şi o gestionare adecvată a riscului persistenţei diferenţelor între specificaţii şi produsul program. În aceste condiţii apare necesară definirea unei concepţii unitare privind managementul activităţii de testare şi în mod corespunzător includerea sa ca etapă distinctă în managementul proiectelor software. Este propusă o tehnică de rafinare a modelelor de evaluare a costurilor testării pentru a mări gradul de operaţionalitate a acestora. Lucrarea se încheie cu concluzii, în care se stabilesc direcţii pentru adoptarea modelelor construite de către noile aplicaţii specifice procesului de globalizare, aplicaţii care trebuie să funcţioneze fără incidente şi care trebuie să fie înzestrate cu caracteristici precum robusteţe, accesibilitate, fiabilitate etc., pentru a face faţă tuturor categoriilor de utilizatori. Pentru realizarea acestei cercetări au fost parcurse peste treizeci de cărţi şi tratate fundamentale din domeniul economiei aplicaţiilor şi din domeniul ingineriei software, dintre care [MYER79], [BEIZ90], [PRESS00], [SOME01], [BOEH00] sunt esenţiale. De asemenea au fost studiate peste cincizeci de articole din reviste de specialitate şi au fost vizitate peste treizeci de site-uri Internet ale unor firme producătoare de software. Lucrarea este rezultatul unei activităţi de documentare sistematică şi a unei cercetări desfăşurată pe parcursul a mai multor ani, concretizată prin elaborarea de studii privind tehnicile de software, în special pentru software orientat obiect. De asemenea, anumite studii s-au bazat pe necesitatea identificării tehnicilor eficiente de testare. Toate aceste cercetări au impus abordarea problematicii costului procesului de testare pentru a fundamenta o nouă orientare, aceea de a dezvolta software pentru utilizatori neomogeni, direct accesibil, fiabil şi cu proprietăţi de maximă continuitate în mentenanţă. Lucrarea de faţă vizează latura economică a procesului de testare software. Lucrarea a fost editată şi finanţată cu sprijinul proiectului de cercetare CNCSIS AT 687 – Modele de estimare a costurilor aplicaţiilor de e-business.

2

TEHNICI DE TESTARE SOFTWARE

2.1 Testarea – etapă a ciclului de dezvoltare software

Proiectarea aplicaţiilor software de dimensiuni mari, dezvoltată în cadrul unei echipe, nu se face trecând direct la implementarea programului, ci urmează etape bine stabilite. Procesul de dezvoltare al aplicaţiilor software este alcătuit din următoarele etape: specificarea cerinţelor, analiză, proiectare, implementare, testare şi întreţinere. În figura 2.1 este prezentat grafic modelul clasic de dezvoltare software [PETE00].

Specificarea cerinţelor Analiză Proiectare Implementare Testare Întreţinere
Specificarea
cerinţelor
Analiză
Proiectare
Implementare
Testare
Întreţinere

Figura 2.1 – Modelul clasic de dezvoltare software

În etapa de specificare a cerinţelor se determină necesităţile pentru toate elementele sistemului, atât hardware cât şi software. Cerinţele privind aplicaţia e-DSI au fost analizate împreună cu beneficiarul. Pornind de la

cerinţa unei aplicaţii accesibile într-o manieră simplă, s-au stabilit variantele posibile de realizare şi cerinţele globale. S-a convenit cu privire la detaliile validării sistemului de către beneficiar. Testarea specificaţiilor se realizează prin metode de analiză statică: inspecţii, parcurgeri şi analize tehnice. Etapa de analiză continuă procesul de stabilire a cerinţelor. Analistul trebuie să înţeleagă domeniul informaţiilor pentru software, funcţiile necesare, performanţele şi interfeţele. Se documentează cerinţele, iar acestea sunt revăzute împreună cu beneficiarul. În această etapă este descris ceea ce trebuie să facă aplicaţia informatică şi nu modul în care se realizează. Pentru

aplicaţia e-DSI sunt definite principalele caracteristici ale

compon ente: magazin electronic, gestiunea bibliotecii, bugetul personal, agenda telefonică, reţete culinare şi jurnalul personal. Sunt descrise cazurile de test pentru fiecare componentă în parte.

În etapa de proiectare accentul se pune pe structurile de date, arhitectura sistemului, detaliile procedurale şi cara cterizarea interfeţelor. În

etapă sunt identificate structurile de date, interfeţele, modulele şi

sunt descrişi algoritmii. Pentru fiecare modul în parte sunt definite specificaţiile de realizare. Pentru aplicaţia e-DSI s-a stabilit structura fiecărei aplicaţii componente, arhitectura de bază, tabele din baza de date, modalităţile de regăsire şi actualizare a datelor. Cazurile de test sunt rafinate

şi sunt adăugate noi cazuri de test corespunzătoare detaliilor introduse. În [PRES 00] se arată că peste 35% din erorile software îşi au originea în fazele de analiză şi proiectare. Prin implementare se face trecerea de la proiect la o formă specifică maşinii de calcul. Implementarea este cu atât mai uşor de realizat cu cât proiectarea se realizează mai în detaliu. Testarea în etapa de implementare are rolul de a evidenţia diferenţele dintre comportamentul produsului din specificaţii şi cel dat la nivelul utilizatorilor. Aplicaţia e-DSI s-a implem entat în limbajul de programare corespunzător cerinţelor. Testarea se concentrează atât asupra logicii interne a programului, avându-se în vedere ca anumite elem ente ale acestuia să fie parcurse, cât şi pe fun cţionalitatea externă a sa, pe baza specificaţiilor. Se compară rezultatele efective obţinute după rularea programului cu seturi de date de test cu rezultatele scontate pe baza specificaţiilor. În timp, după livrarea la beneficiar , aplicaţiile software suferă schimb ări care se datorează erorilor descoperite pe parcursul funcţionării aplicaţiei, modificărilor mediului în care rulează aplicaţia (software, hardware) precum şi noilor cerinţe de performanţă şi funcţionalitate dorite

această

aplicaţiilor

de beneficiar. Întreţinerea aplicaţiilor software se aplică tuturor fazelor ciclului de viaţă. În cadrul ciclului de dezvoltare software, un rol important îl au verificarea şi validarea (V & V). Verificarea şi validarea reprezintă un proces prin care se determină dacă cerinţele unui sistem sau componentă sunt complete şi corecte, dacă rezultatul fiecărei faze de dezvoltare îndeplineşte cerinţele sau condiţiile impuse în faza anterioară şi dacă sistemul sau componenta finală este în concordanţă cu cerinţele specificate

[PRES00].

Verificarea este mulţimea activităţilor care asigură că o aplicaţie softwar e implementează corect o anumită funcţie. Testarea software este o componentă a procesului de V & V. Validarea este mulţimea activităţilor care asigură că o aplicaţie software realizată este în concordanţă cu cerinţele beneficiarului. Pe măsura dezvoltării incrementale a aplicaţiei e-DSI rezultatele din fazele intermediare sunt validate de către beneficiar. Testarea sau analiza statică are ca scop examinarea aplicaţiilor software fără a fi executate şi cuprinde activităţi precum inspecţiile, ex ecuţia simbol ică şi verificarea. Aceste activităţi fac parte din categoria evaluările tehnice [MYER79]. Inspecţiile codului presupun citirea sau inspecţia vizuală a codului sursă de către un grup de persoane. Având la dispoziţie codul su rsă şi specific aţiile de proiectare, grupul de persoane din echipa de inspecţie urmăreşte explicaţiile programatorului legate de logica programului, instrucţiune cu instrucţiune. În acest mod se descoperă o serie de erori specifice acestei metode cum ar fi: declararea datelor, referirea datelor, erorile de calcul, erorile de comparare, erorile de logică, erorile de intrare/ieşire, erorile de interfaţă etc. Parcurgerile constau în citirea sau inspecţia vizuală a codului sursă de către un grup de persoane, însă procedura de lucru este diferită având ca scop execuţia logică a fiecărei secvenţe de cod de testat pe baza unor seturi de test pregătite anterior. Prin urmărirea programului pas cu pas sunt identificate erori care apar la acest nivel. Rezultatele acestei activităţi de verificare depind, ca şi în cazul inspecţiilo r codului, de atitudinea echipei faţă de persoana care a scris programul, având în vedere faptul că atenţia trebuie acordată programului care se verifică şi nu celui care l-a scris. Verificarea de birou este o tehnică de analiză statică în care listingurile codurilor sau rezultatele testelor sau alte documente sunt examinate vizual, de obicei de persoana care le-a realizat, pentru a identifica erorile sau abaterile de la standardele de dezvoltare sau alte probleme.

Proiectare teste

Ex

ecuţie teste

Testarea dinamică presupune examinarea aplicaţiilor software în scopul generării datelor de test cu care acestea vor fi executate şi rularea aplicaţiilor cu seturile de date de test obţinute. Se observă că spre deosebire de testarea statică, testarea dinamică presupune execuţia aplicaţiei care se testează. Există două strategii de dezvoltare a cazurilor de test: o strategie bazată pe structura programelor şi o alta, bazată pe funcţionalitatea acestora. În dezvoltarea unui produs software testarea se realizează pe mai multe niveluri: testarea de module, testarea de integrare, testarea de sistem şi testarea de acceptare (validare). În figura 2.2 este prezentat procesul de verificare şi validare în cadrul ciclului de dezvoltare a unui produs software [TEST90]. Se identifică etapele de realizare a aplicaţiei precum şi etapele şi nivelurile procesului de testare software.

Beneficiar

Dezvoltare

Cerinţe:

aplicaţie de

servicii

casnice

electronice

Validare

aplica ţ ie de servicii casnice electronice Validare Specificare cerin ţ e Analiz ă Proiectare Implementare
aplica ţ ie de servicii casnice electronice Validare Specificare cerin ţ e Analiz ă Proiectare Implementare

Specificare

cerinţe

Analiză

Proiectare

Implementare

Integrare

Recepţie Testare de e-DSI acceptare
Recepţie
Testare de
e-DSI
acceptare

Sistem

Testare

Recepţie Testare de e-DSI acceptare Sistem Testare Verificare Testare de module Testare de integrare Testare de

Verificare

Testare de
Testare de

module

Testare de

Sistem Testare Verificare Testare de module Testare de integrare Testare de sistem Figura 2.2 – Testarea

integrare

Testare de

Verificare Testare de module Testare de integrare Testare de sistem Figura 2.2 – Testarea software în

sistem

Figura 2.2 – Testarea software în ciclul de dezvoltare

În cadrul testării de module se realizează verificarea celor mai mici

unităţi software care pot fi compilate şi link-editate independent. În programarea clasică un modul este un subprogram (funcţie sau procedură). În cadrul programelor orientate obiect, cea mai mică unitate testabilă este clasa.

Testarea de module se concentrează asupra verificării interfeţelor modulelor, structurilor de date locale, condiţiilor de la limite, căilor independente şi căilor de tratare a erorilor. [PRES00] Deoarece modulele nu sunt programe de sine stătătoare, este necesar

să se construiască programe sau funcţii care să ajute la testarea de module.

O primă categorie o reprezintă programele conducătoare (drivers)

care apelează modulele supuse testării cu datele de test construite şi preiau

rezulta tele execuţiei.

O altă categorie este reprezentată de funcţiile sau procedurile apelate

de către modulul de testat. Acestea sunt substituite cu subprograme care au

denumite module

vide (s tubs). Modulele vide sunt funcţii sau proceduri simple care nu fac nimic în afara returnării controlului, sau sunt funcţii sau proceduri complexe, care simulează efectul apelării modulelor reale. În cele mai multe cazuri, modulele vide simple sunt nepotrivite. Un efort considerabil este necesa r pentru implementarea de module vide complexe.

Testarea de integrare este o tehnică sistematică de construire a structurii programului prin gruparea componentelor în paralel cu testarea aspectelor legate de interfaţa dintre componente. Testarea de integrare se realizează într-o manieră neincrementală sau incrementală. Testarea neincrementală (big-bang testing) constă în integrarea componentelor prin gruparea tuturor modulelor dintr-o dată, urmată de testarea întregului ansamblu. Acest tip de integrare nu este recomandată, deoarece corectarea erorilor va fi foarte greu de realizat. Testarea incrementală presupune construirea structurii programului

pas cu pas şi testarea ansamblului obţinut. Un element important în execuţia

stfel, testarea

testului este se

d e integrare se realizează ascendent (bottom-up), descendent (top-down) sau mixt.

Metoda de testare ascendentă (bottom-up testing) presupune testarea mai întâi a modulelor de pe cel mai de jos nivel al ierarhiei programului,

apoi se continuă în sus cu testarea

celorlalte module. Metoda de testare

ascend entă necesită construcţia de programe conducătoare pentru a iniţializa mediul şi pentru a apela modulele. Programele de pe nivelul de sus, care de obicei sunt critice, sunt testate ultimele. În timp sunt descoperite erori care

acelaşi prototip, însă cu funcţionalitate redusă la minim,

cvenţa în care modulele trebuie să fie testate. A

pot influenţa multe module care au fost deja testate. După corecţia erorilor este necesar ca toate modulele de pe nivelurile de jos să fie testate regresiv.

Agenda mea Adaugă Caută Modifică Edit
Agenda
mea
Adaugă
Caută
Modifică
Edit

Figura 2.3 – Testarea de integrare ascendentă

În figura 2.3 este prezentat un exemplu de testare de integrare ascendentă. În cadrul aplicaţiei e-DSI, modulele Adaugă, Caută Modifică şi Edit sunt integrate şi testate, modulul ”Agenda mea” fiind înlocuit cu un modul conduc ător, care le apelează.

modulul din

ierarhiei de programe este testat primul, procesul de testare

continuând cu modulele de pe nivelurile inferioare. Metoda de testare descendentă necesită construcţia de module vide asociate subprogramelor care nu sunt disponibile. Avantajul acestei metode este că dacă este descoperită o eroare în modulele de pe nivelurile înalte, impactul va fi asupra modulelor de pe nivelurile de jos care nu au fost încă implementate, deci refacerea modulelor de pe nivelurile inferioare poate fi evitată. În figura 2.4 se prezintă un exemplu al testării de integrare descendentă. Modulele ”Agenda mea”, Adaugă şi Caută sunt deja integrate şi testate, modulele Modifică şi Edit fiind înlocuite cu module vide.

v ârful

,

În me

toda testării descendente (top-down testing),

Agenda mea Adaugă Caută Modifică Edit
Agenda
mea
Adaugă
Caută
Modifică
Edit

Figura 2.4 – Testarea de integrare descendentă

În cadrul metodei mixte, testarea urmează mai întâi metoda descendentă. Modulele selectate de pe nivelurile inferioare sunt testate utilizând metoda ascendentă. Această flexibilitate permite preluare a avantaj elor metodelor de ascendentă şi descendentă. În cele mai multe aplicaţii, metoda mixtă este cea mai potrivită modalitate de abordare. Aplicaţia e-DSI a fost testată utilizând această metodă de integrare. Pe măsură ce sunt adăugate noi module în cadrul testării de integrare, apar schimbări în software, care pot să modifice comportamentul structur ii obţinute anterior. În acest context este executată testarea de regresie, prin care se re-testează noua structură obţinută, utilizând o parte din testele utilizate în etapa precedentă de integrare. Testarea de validare are loc după ce toate erorile de i nterfaţă descoperite în cadrul testării de integrare au fost corectate. Testarea de validare se încheie cu succes atunci când funcţionalitatea aplicaţiei software este în conformitate cu cerinţele beneficiaru lui. Pentru testarea de validare se utiliz ează o serie de teste funcţionale pentru a confirma faptul că aplicaţia software se comportă conform cerinţelor. În cadrul testării de validare se regăsesc testările alfa şi beta. Testarea alfa este realizată la firma care produce aplicaţia software, beneficiarul fiind acela care conduce testele. Testarea beta este realizată la beneficiari şi utilizatori finali. Aceştia primesc o versiune a aplicaţiei software, versiune apropiată de cea finală şi o utilizează în scopul descoperirii erorilor şi a problemelor de performanţă şi funcţionalitate. Problemele apărute în cadrul acestei testări sunt raportate firmei care a realizat aplicaţia. După ce perioada acordată pentru testarea b eta s-a termina t, toate erorile apărute sunt corectate, urmând să se realizeze versiunea finală a aplicaţiei software.

Pentru testarea aplicaţiei e-DSI au fost înregistrate observaţiile primite de la o serie de utilizatori care au folosit aplicaţia în diverse stadii

ale ace steia în scopul identificării problemelor şi neajunsurilor din utilizare. Utilizatorii care au testat aplicaţia au niveluri de pregătire şi experienţă în lucrul cu calculatorul diferite. După ce a avut loc testarea aplicaţiei software, intervine testarea de sistem, prin care se testează întregul sistem în care produsul software este o

parte componentă a

teste di ferite, astfel încât să fie examinate toate caracteristicile sistemului. În literatura de specialitate, [PRESS00], [PETE00], [MYER79] sunt

prezentate câteva tehnici specifice pentru testarea de sistem. Astfel, se identifică testarea pentru determina rea capacităţii de recuperare (recovery

te sting), testarea securităţii, testarea de solicitare (stress testing), testarea de

încărca

Testarea pentru determinarea capacităţii de recuperare este un test de siste m care, printr-o multitudine de căi, forţează aplicaţia software să îşi încheie execuţia în mod necorespunzător. Prin acestea se testează capacitatea aplicaţiei de revenire dintr-o situaţie necorespunzătoare. Testarea securităţii se realizează pentru a verifica eficienţa

mecanismelor de protecţie dintr-un sistem software şi dacă acesta se comportă corespunzător la atacurile externe. Testarea de solicitare se execută astfel încât sistemul să funcţioneze cu un volum mai mare de resurse decât cel normal, cu scopul de a determina fiabilitatea aplicaţiei şi momentul în care funcţionarea aplicaţiei devine critică şi pentru a lua măsurile corespunzătoare, astfel încât să nu se ajungă în exploatarea de zi cu zi a sistemului informatic la astfel de situaţii. Utilizând instrumente care simulează existenţa mai multor utilizatori simultan, precum JMeter şi Rational SiteCheck, pentru aplicaţia e-DSI s-au descoperit cazuri în care serverul devine inaccesibil. Acest lucru impune verificarea configurării serverului de Web sau a procesorului JSP, prin modificarea numărului de clienţi care accesează aplicaţia simultan.

Testarea de încărcare constă în rularea sistemului software în condiţiile în care resursele (me morie, microprocesor, reţea) sunt încărcate la

surse nu

mai su

funcţio

întrerupe

maxim as tf el încât se ajunge la situaţii critice, în care o parte din re

acestuia. Testarea de sistem presupune rularea unor

re (load testing) şi testarea performanţelor (performance te

sting).

nt

d

isponibile. Se urmăreşte capacitatea sistemului de a-şi

atelor.

nar e a fără pierderea sau coruperea d

Testarea performanţelor se realizează pentru determ inarea

exemplu

conform it ă ţii sistemului cu cerinţele de performanţă impuse. De

sistemu

l este încărcat într-un interval de timp pornind

de la capacitatea

minimă

până la capacitatea maximă şi se verifică d

acă resursele sistemului

în limitele corespunzătoare şi nu sunt întârzieri în executarea

funcţiilor aplicaţiei. Prin folosirea de instrumente pentru măsura rea performanţelor aplicaţi ei e-DSI (precum JMeter) s-a constat că aplicaţia răspunde în limite acceptabile, cu excepţia primei cereri efectuate, datorită particularităţilor

serverului Web şi a motorului JSP.

se află

2.2 Fazele procesului de testare software

Fazele procesului de testare sunt: planificarea, analiza şi proiectarea, implementarea şi execuţia şi evaluarea testelor. Planificarea testelor se realizează în strânsă legătură cu planificarea derulării proiectului. În faza de planificare a proiectului pentru testare se alocă resurse, specificându-se bugetul şi perioada de timp în care se va derula testarea. Pe baza acestora se realizează planificarea detaliată a procesului de testare. Planificarea testării are scopul de a determina ce să testeze şi cât să testeze, astfel încât procesul de testare să se încadreze în limitele resurselor alocate. În urma planificării testării rezultă planul de test, un document pe baza căruia se desfăşoară celelalte faze ale testării. În această fază se identifică şi obiectivele testării. Planul de test este un document important, fiind utilizat ca bază pentru desfăşurarea întregului proces de testare. În plus, trebuie identificate şi sursele de risc în testare. Planificarea testării poate să înceapă din momentul în care au fost elaborate cerinţele aplicaţiei software [PETE00]. În planul de test sunt descrise:

aria de cuprindere;

responsabilităţile fiecărui membru al echipei de testare;

resursele umane necesare;

desfăşurarea în timp a testelor;

descrierea şi configurarea mediului specific aplicaţiei;

lista echipamentelor care trebuie achiziţionate;

crearea şi managementul datelor de test;

criteriile de acceptare a testelor.

Deoarece este foarte dificil să se stabilească momentul în care se va încheia testarea, în planul de test se specifică o serie de criterii care constituie o bază pentru determinarea finalizării testării. Analiza testelor rafinează metodele prezentate în planul de test. În [DUST99] sunt prezentate etapele fazelor de analiză şi proiectare a testelor.

Astfel, în etapa de analiză se identifică următorii paşi:

identificarea scopurilor, obiectivelor şi a strategilor testării de către echipa de testare;

metodele de verificare sunt asociate cerinţelor sistemului sau cazurilor de utilizare şi sunt documentate în cadrul unei matrice de urmărire a cerinţelor;

analiza cerinţelor testelor;

construirea matricei cerinţelor testelor, în care declaraţiile cerinţelor testelor sunt asociate cerinţelor sistemului sau a cazurilor de utilizare;

asocierea tehnicilor de testare cu declaraţiile cerinţelor testelor.

În faza de analiză a procesului de testare, un aspect important îl ocupă analiza cerinţelor pentru testare. Cerinţele testării trebuie să fie

identificate şi documentate astfel încât toate persoanele implicate în procesul de testare să fie conştiente de scopul acestuia. Analiza se desfăşoară din mai multe puncte de vedere, depinzând de faza de testare. Astfel se identifică o abordare structurală şi o abordare bazată pe comportament. Faza de proiectare a testelor urmează după încheierea analizei. În faza de proiectare, apar următorii paşi:

definirea modelului programului de test astfel încât acesta să reflecte tehnicile de testare utilizate;

definirea arhitecturii de test;

definirea procedurilor de test;

luarea deciziei de automatizare a anumitor teste şi de testare manuală a altor componente;

asocierea datelor de test astfel încât fiecare cerinţă pentru datele de test să se reflecte pentru fiecare procedură de test. Programul de test se elaborează fie la nivelul proiectării, fie la nivelul tehnicilor de testare. În primul caz, procedurile de test sunt asociate componentelor hardware şi software ale aplicaţiei, iar în al doilea caz procedurile de testare sunt văzute la nivelul tehnicilor de testare. Proiectarea procedurilor de test începe după determinarea cerinţelor testării. Proiectarea procedurilor de test constă în:

analiza arhitecturii de test pentru determinarea tehnicilor de testare relevante;

definirea procedurilor de test atât la nivelul sistemului cât şi la nivelul de implementare;

elaborarea sau preluarea de standarde de utilizare a procedurilor de test;

identificarea procedurilor de test care vor fi efectuate manual şi a celor care vor fi efectuate automat;

identificarea procedurilor de test complexe, pentru a fi proiectate în continuare în faza de proiectare detaliată;

proiectarea detaliată.

În etapa de implementare a testelor sunt construite cazurile de test şi procedurile de test, pe baza rezultatelor fazei de proiectare. Cazurile de test descriu atât parametrii de intrare cât şi rezultatele aşteptate după execuţie utilizând acei parametri. Realizarea de cazuri de test cât mai complete duce la descoperirea unui număr mai mare de erori. Procedurile de test identifică toţi paşii necesari pentru executarea cazurilor de test specifice. Primul pas în faza de implementare este iniţializarea mediului de implementare prin punerea la punct a arhitecturii dezvoltării testelor. Un alt aspect important este identificarea standardelor pe care se bazează elaborarea secvenţelor de test. Dacă au fost definite astfel de standarde de implementare, atunci implementarea se realizează pe baza acestora. Dacă nu există standarde, în cadrul acestei faze, la început, se stabilesc convenţii de scriere a programelor de test (alinieri, comentarii, prefixe pentru date). Implementarea secvenţelor de test se realizează în limbaje specifice mediilor de testare (asemănătoare Visual Basic) sau se utilizează limbaje de programare evoluate (C++, Java). Prin reutilizare se folosesc proceduri de test din proiectele anterioare sau din cadrul aceluiaşi proiect pentru module care au părţi comune. În [McGR97c], [McGR97d] este prezentată o arhitectură paralelă de testare a claselor, în care clasele de test sunt derivate în paralel cu dezvoltarea ierarhiei claselor care se testează. Faza de rulare a testelor are ca intrări planul de test şi orarul execuţiei procedurilor de test, mediul de test fiind pregătit corespunzător. Ieşirile fazei de execuţie a testelor sunt rezultatele testelor, lecţiile învăţate şi orarul modificat al testelor. Execuţia modulelor se realizează în conformitate cu planul de test. Procedurile de test descriu intrările şi ieşirile aşteptate după execuţie. În această etapă din cadrul procesului de testare sunt rulate secvenţele de test. Execuţia secvenţelor de test se realizează pe cât posibil în mediul specific aplicaţiei iar dacă nu este posibil, acest mediu este simulat. Rezultatele execuţiei secvenţelor de test sunt evaluate pentru a determina dacă produsul a trecut testul cu succes. Evaluarea rezultatelor testelor se face de către un oracol. Oracolul este o persoană sau un

instrument automat, care pe baza specificaţiilor determină dacă rezultatele execuţiei testelor sunt corecte sau nu. În figura 2.5 este prezentat fluxul procesului de execuţie şi evaluare a testelor pentru testarea la nivel de modul, bazată pe specificaţii. Rezultatele testelor arată dacă programul a trecut sau nu testul.

Program de

testat

Execuţie
Execuţie
Ieşiri Evaluare Rezultate teste Ieşiri aşteptate
Ieşiri
Evaluare
Rezultate
teste
Ieşiri
aşteptate

Date de

intrare

Figura 2.5 – Fazele de execuţie şi evaluare pentru testarea de module

Rezultatele execuţiei testelor se vor memora într-o bază de date care

conţine şi alte informaţii referitoare la aplicaţia software realizată. Execuţia şi evaluarea testării de integrare necesită noi secvenţe de

test pe

te stează. Aprobarea de către beneficiar a rapoartelor testării de modul şi ale

test ării

În execuţia şi evaluarea testării de sistem, beneficiarul aplicaţiei se implică mai mult decât în celelalte faze. În mod asemănător, acesta trebuie

să semneze raportul de test pentru a considera încheiată această fază de testare.

Procesul de testare pentru aplicaţia e-DSI a urmat aceleaşi etape, gradul de aprofundare fiind diferit.

rul structurii programului care se

măsură ce se adaugă module în cad

de integrare constituie încheierea acestor faze.

2.3 Testarea structurală

Testarea structurală (white box testing) este o strategie de testare care necesită accesul la codul sursă şi la structura programului şi pune accentul pe acoperirea prin teste a căilor, ramificaţiilor şi fluxurilor programului. Principalele metode de testare structurală au în vedere gradul în care cazurile de test acoperă sau execută codul sursă al programului.

Strategiile de testare bazate pe căi utilizează fluxul de control al programului. Acestea reprezintă o familie de tehnici de testare bazate pe selectarea cu atenţie a unei mulţimi de căi din program. Dacă mulţimea căilor e ste aleasă corespunzător, atunci se va atinge o anumită măsură a

acestor tehnici este necesară

cunoaş terea completă a structurii programului şi accesul la codul sursă.

Tehnicile sunt utilizate cel mai des de către programatori pentru testarea

detectează erorile care

cauzea ză execuţia unei alte căi a programului decât aceea care trebuia să se execute. Graful asociat programului este o reprezentare grafică a structurii de

al programului, care utilizează elemente ca proces, decizie şi

joncţiune. Un bloc de bază este o secvenţă

de instrucţiuni ale programului,

neîntre rupte de decizii sau de joncţiuni. Un proces are o singură intrare şi o singură ieşire şi constă dintr-o singură declaraţie/instrucţiune, dintr-o secvenţă de declaraţii/instrucţiuni, un singur apel de subrutină sau o secvenţă din acestea.

O decizie este un punct al programul ui în care fluxul de control continu ă pe una din alternativele oferite. Construcţiile if-then-else şi switch- case sunt exemple de decizii cu două ramuri, respectiv cu n ramuri, n2. Joncţiunile sunt punctele din program în care fluxul de control se uneşte, care pot fi etichetele ţintă ale unui salt, punctele în care se unesc ramurile unei instrucţiuni if-then-else etc. O ca le într-un program este o secvenţă de instrucţiuni care începe cu o intrar e, joncţiune sau decizie şi se termină la altă (sau aceeaşi) joncţiune, decizie sau ieşire. O cale poate să treacă prin câteva joncţiuni, procese sau decizii o dată sau de mai multe ori. Un segment constă dintr-o succesiune de legături consecutive care aparţin aceleiaşi căi. Lungimea unei căi este dată de numărul de legături şi nu de numărul de declaraţii sau instrucţiuni executate de-a lungul căii. O metodă alternativă de măsurare a lungimii unei căi este numărul de noduri traversate. Dacă programul are un singur nod de intrare şi un singur nod de ieşire, numărul

de legături traversate este mai mic cu unu decât

numărul nodurilor

propriului cod. Cu ajutorul acestei tehnici se

profunzimii testului. Pentru utilizarea

control

travers ate. Numele căii este dat de numele nodurilor de-a lungul căii. De exemplu în cadrul aplicaţiei e-DSI diverse secvenţe de program au graful asociat asemănător celui din figura 2.6. Nodurile sunt numerotate corespunzător fluxului secvenţei de program. O cale de la punctul de intrare

până la ieşire se notează de exemplu cu 1-2-3-5-6-7-9-10. În mod asemănător, dacă se notează legăturile, numele căii este dat de succesiunea

numelor legăturilor de-a lungul căii. Pentru aceeaşi cale, numele ei este abcfghk. În practică, o cale de test este o cale care începe în punctul de intrare în program şi se termină la ieşirea din program.

4

8

1 a 2 b d e c 5 f 6 g i j h 9
1
a
2
b
d
e
c
5
f
6
g
i
j h
9
k
10

3

7

Figura 2.6 – Nodurile şi legăturile grafului asociat unei secvenţe de program

Tehnicile de testare bazate pe căile programului au la bază o serie de criterii de acoperire a codului care se testează precum: acoperirea instrucţiunilor, acoperirea ramificaţiilor, acoperirea condiţiilor, acoperirea ramificaţiil or şi a condiţiilor, acoperirea condiţiilor multiple şi acoperirea tuturor căilor programului. Pe baza acestor criterii de acoperire a codului se determină seturile de date de test care se utilizează în testările structurale corespunzătoare: testarea instrucţiunilor, testarea ramificaţiilor, testarea căilor etc. Criteriul pentru acoperirea instrucţiunilor este ca fiecare instrucţiune să fie executată cel puţin o dată în cadrul unor teste. Dacă se realizează acest obiectiv, atunci declaraţiile sunt acoperite în proporţie de 100%. Acest lucru este echivalent cu o acoperire a nodurilor fluxului de control asociat programului în proporţie de 100%. Criteriul de acoperire a instruc ţiunilor este criteriul cel mai slab, deoarece cazurile de test identificate astfel încât să fie acoperite toate instrucţiunile iau în calcul doar

acest criteriu, nefiind tratate toate situaţiile posibile. Acest criteriu de acoperire se mai numeşte şi criteriul C1. Acoperirea ramificaţiilor are drept criteriu ca fiecare ramură a unei decizii să fie executată cel puţin odată. Se rulează un număr suficient de teste pentru a se executa toate ramificaţiile din program cel puţin o dată. În cazul î n care s-a realizat acest lucru, se atinge un procent de 100% a acoperirii ramificaţiilor sau echivalent de acoperire a legăturilor dintre nodurile g rafului asociat programului. Pentru software-ul structurat testarea

tuturor ramificaţiilor

include şi acoperirea tuturor declaraţiilor. Criteriul de

acoperi re

date de test

a stfel încât fiecare condiţie cu rezultat logic să ia valorile posibile (adevărat sau fals).

a ramificaţiilor se notează cu C2. Acoperirea condiţiilor are ca obiectiv identificarea de

În secvenţa:

if(criteriu!=nul l && !criteriu.equals(""))

pentru acoperirea ramificaţiilor sunt necesare două cazuri de test corespunzătoare celor do uă ramuri, iar pentru acoperirea condiţiilor sunt necesar e patru cazuri de test corespunzătoare combinaţiilor adevărat sau fals pentru cele două condiţii.

Pentru acoperirea ramificaţiilor şi condiţiilor criteriul de parcurgere a codului sursă este o combinaţie a criteriilor de la acoperirea ramificaţiilor şi acoperirea condiţiilor. Criteriul de acoperire a condiţiilor multiple are ca scop execuţia cel puţin o dată a fiecărei combinaţii de stări posibile ale condiţiilor. Acoperirea tuturor căilor programului are ca obiectiv execuţia

tuturor căilor fluxului de control din program, care încep la

intrarea în

program

acoperă căile în proporţie de 100%.

Acesta este cel mai puternic criteriu din familia de strategii de testare bazate

pe căi şi este, în general, imposibil de atins deoarece numărul de căi poate ajunge foarte mare, mai ales prin existenţa structurilor repetitive. Acoperirea declaraţiilor şi a ramificaţiilor sunt cerinţe minime obligatorii pentru testarea structurală. Pentru pro gramele care conţin bucle, acoperirea marginilor interioare (bound ary-interior cover) este deseori utilizată pentru a executa bucla cel

îndeplinească acest criteriu, atunci se

şi se termină la ieşirea din program. Dacă se reuşeşte să se

puţin de două ori. În primul caz se execută bucla fără iteraţii, iar în al doilea

caz se execută bucla cu una

sau mai multe iteraţii. Dacă testarea se

realizea ză utilizând doar analiza căilor sunt detectate circa 25% din

erori.[MYER79]

În capitolul 8 sunt tratate distinct problemele legate de testarea structurală şi sunt făcute aprecieri în legătură cu costul asociat diferitelor tipuri de teste la nivel structural. Testarea fluxului datelor utilizează graful fluxului de control pentru a studia anomaliile fluxului de date. Acest tip de testare formează o familie de strategii de test bazate pe selecţia unei căi din fluxul de control al

programului în scopul

cercetării secvenţelor de evenimente referitoare la

starea d atelor. Testarea fluxului de date se bazează pe faptul că cel puţin jumătate

din codul sursă constă în declaraţii de date, declaraţii car e definesc structuri

) şi atribuite

de dat

, Gra ful fluxului datelor este alcătuit din noduri şi legături direcţionate. Obiectivul său este acela de a prezenta deviaţiile de la fluxul de date im plementat faţă de ceea ce s-a dorit la proiectare. Acţ iunile posibil de efectuat asupra datelor sunt:

definire (d); e ste explicită, când variabila apare într-o declaraţie

şi implicită, când variabila este într-o instrucţiune de

e, obiecte individuale, valori iniţiale (sau implicite 0] [PETE00].

[BEIZ9

de

dat

e

atri

bu

ir

e;

ned

efi n ire (k); atunci când data nu mai este disponibilă sau când

con ţinutul ei nu este cu certitudine cunoscut;

utilizare (u):

o

în calcule (c); variabila apare în atribuiri, într-o expresie de calcul;

partea dreaptă a unei

o

într-un predicat (p); când apare

direct, de exemplu if

(a<b), sau în condiţia de ciclare a unei bucle.

Anomaliile sunt reprezentate prin secvenţe de două acţiuni:

dd – variabilă definită, dar nereferită;

ku – v

tă;

ariabilă nedefinită

, dar referi

 

d k – va

riabilă defi

nită, dar nereferită.

Situ

aţ<