Cuprins

1. Introducere ..................................................................................................... 2. Tehnici de testare software .......................................................................

2.1. Testarea etap a ciclului de dezvoltare software ..................................................... 2.2. Fazele procesului de testare software ........................................................................... 2.3. Testarea structural ........................................................................................................... 2.4. Testarea funcional ........................................................................................................... 2.5. Testarea software orientat obiect ............................................................................... 2.6. Testarea sistemelor distribuite bazate pe tehnologia Internet ............................. 2.7. Testarea sistemelor distribuite bazate pe componente ............................................

3. Factori de influen a testrii ....................................................................

3.1. Criterii de clasificare a factorilor ................................................................................... 3.2. Complexitatea produselor software ................................................................................ 3.3. Dimensiunea aplicaiei ......................................................................................................... 3.4. Gradul de omogenitate a echipei de realizare software ............................................ 3.5. Tehnici de dezvoltare a produsului program ................................................................. 3.6. Stadiul de certificare a firmei ......................................................................................... 3.7. Numrul i diversitatea utilizatorilor ............................................................................. 3.8. Factori secundari de influen .......................................................................................... 3.9. Interdependene de aciune a factorilor .......................................................................

4. Cheltuieli aferente procesului de testare ...............................................

4.1. Costurile dezvoltrii software ........................................................................................... 4.2. Costurile calitii produselor program ............................................................................ 4.3. Cheltuieli cu personalul ....................................................................................................... 4.4. Cheltuieli pentru instrumente de asistare ..................................................................... 4.5. Cheltuieli pentru echipamente .......................................................................................... 4.6. Cheltuieli indirecte .............................................................................................................. 4.7. Repartizarea cheltuielilor pe nivelurile testrii ........................................................... 4.8. Repartizarea cheltuielilor pe fazele procesului de testare ....................................... 4.9. Ci de reducere a cheltuielilor de testare .....................................................................

5. Modele liniare de evaluare a costului testrii software (CTS) ..........

5.1. Estimri i ipoteze n elaborarea modelelor liniare de evaluare a CTS ................... 5.2. Dependene liniare unifactoriale identificate n testarea software ....................... 5.3. Structuri de modele liniare multifactoriale pentru evaluarea CTS ......................... 5.4. Analiza calitii modelelor liniare de evaluare a CTS .................................................. 5.5. Rafinarea modelelor liniare de evaluare a CTS ............................................................. 5.6. Stabilitatea modelelor liniare de evaluare a CTS ........................................................

6. Modele neliniare ale costului procesului de testare software ...........

6.1. Condiii specifice pentru elaborarea modelelor neliniare de evaluare a CTS ........

4 10 10 18 21 28 30 35 39 46 46 47 55 58 59 64 69 71 74 76 76 79 84 88 91 92 93 96 99 104 104 108 111 118 120 124 126 126

6.2. Modelul polinomial al evalurii costului testrii ............................................................ 6.3. Modelul produs de evaluare a CTS ................................................................................... 6.4. Modelul exponenial 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 ptratelor 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 ..........................................................................

127 128 130 131 133 134 137 138 140 140 142 143 146 148 149 151 156

8. Probleme ale modelelor de evaluare a CTS n testarea orientat pe structuri de control i structuri de date .....................................................
8.1. Costul testrii pentru proceduri care includ structuri de control liniare ..............

156 8.2. Testarea procedurilor alternative ................................................................................... 161 8.3. Cerine ale testrii procedurilor repetitive .................................................................. 166 8.4. Aspecte ale testrii procedurilor cu apeluri ................................................................. 171 8.5. Testarea programelor cu structuri statice ................................................................... 173 8.6. Particulariti ale testrii programelor cu structuri dinamice ................................. 176 8.7. Procese de testare pentru programele cu structuri agregate ................................. 178 9. Testarea aplicaiei e-DSI ........................................................................... 182 9.1. Aplicaia e-DSI ..................................................................................................................... 182 9.2. Aparate foto ......................................................................................................................... 186 9.3. Bugetul meu ........................................................................................................................... 190 9.4. Biblioteca mea ....................................................................................................................... 197 9.5. Agenda mea ............................................................................................................................ 200 9.6. Reetele mele ........................................................................................................................ 202 9.7. Jurnalul meu .......................................................................................................................... 206 10. Utilizarea modelelor de evaluare a costurilor n testarea aplicaiei 210 e-DSI .................................................................................................................... 10.1. Particularitile gestiunii electronice a serviciilor casnice ...................................... 210 10.2. Aplicaia e-DSI utilizat n analiza modelelor de evaluare a CTS ......................... 211 10.3. Structuri de modele pentru evaluarea costurilor testrii aplicaiei ..................... 214 10.4. Analiza comparat a rezultatelor experimentale obinute ...................................... 222 10.5. Ierarhizarea modelelor de evaluare a CTS .................................................................. 224 11. Concluzii .......................................................................................................... 226 Anexa 1 Lista acronimelor utilizate ..................................................................................... 228 Anexa 2 Notaii utilizate ........................................................................................................ 230 Anexa 3 Instrumente pentru automatizarea testrii ...................................................... 232 Bibliografie .................................................................................................................................... 236

1
INTRODUCERE
Perioada actual pe care o traverseaz informatica romneasc impune o nou abordare a realizrii de software, ntruct societatea informaional nseamn dezvoltarea de aplicaii cu grad de complexitate deosebit de ridicat, caracterizate prin fiabilitate i mentenan. Obiectivul acestei lucrri l reprezint identificarea costurilor aferente testrii software precum i definirea de modele liniare i modele neliniare pentru evaluarea costului testrii 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 aplicaii software. Tehnicile i metodele moderne de elaborare a produselor software acord o importan deosebit efortului de nlturare a erorilor de analiz, proiectare i programare prin folosirea unor mijloace evoluate de testare. Exist numeroase modaliti de a realiza testarea aplicaiilor software, dar n toate cazurile se pornete 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 definiiilor din dicionarele explicative romne i strine rezult c estimarea presupune determinarea subiectiv i aproximativ a valorii unui obiect sau a unei activiti, nainte ca obiectul sau activitatea s existe n momentul procesului de calcul. Spre deosebire de aceasta, evaluarea este definit ca aciunea de determinare a valorii unui obiect prin examinarea acestuia, a crui 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 difereniere, 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 activiti, obiecte, sisteme sau fenomene existente pentru care se dorete obinerea unui indicator agregat de referin care poziioneaz respectivul element existent ntre celelalte de acelai 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, obinerea unui indicator sau a unor coeficieni, numii estimatori, cu ajutorul crora se va obine o valoare privind poziia, comportamentul sau o calificare a dinamicii produselor software. Tehnicile de evaluare presupun studierea unui proces sau fenomen prin extragerea factorilor de influen. Factorii sunt pui n coresponden cu variabilele a cror dinamic este nregistrat sub forma unor serii de date. Tabelul obinut conine un numr de coloane egal cu numrul variabilelor independente la care se adaug seria de date a variabilei dependente. Folosind o metod de evaluare pentru fiecare variant de model construit se obin forme uzuale ale modelelor. Calitatea estimrilor se analizeaz pentru a avea certitudinea utilizabilitii modelelor. n lucrare sunt traversai aceti pai att pentru modelele liniare ct i pentru cele neliniare, extrgndu-se din mulimea 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 determinri sub form de msurtori ale produselor privind: numrul de linii surs; numrul de module; complexitatea software; diversitatea datelor de intrare; calitatea utilizatorilor. Pentru produsul existent se obin date certe privind structura, comportamentul i se stabilesc obiective clare pe care testarea trebuie s le ofere. Modelul de evaluare a costului testrii vizeaz o expresie analitic obinut pe baza datelor privind produsele software existente i conduce la obinerea unei informaii agregate privind efortul pe care trebuie s-l fac echipa de testare. Coeficienii modelului se estimeaz cu una dintre metodele cunoscute din econometrie. n cazul estimrii, produsul software este definit numai n plan conceptual, se vorbete de o structur modular, se stabilesc clasele, interdependenele, fluxurile, interfeele 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 estimri avnd la baz experimente, coeficieni de siguran sau coeficieni 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 informaiile fiind niveluri planificate: durate, resurse, termene. Din punct de vedere structural, ntre modele de estimare i cele de evaluare exist diferene majore. Modelele de estimare sunt expresii analitice care conduc la obinerea nivelului estimat al costului testrii pe baza datelor de intrare, care la rndul lor sunt niveluri estimate ale necesarului de resurse sau ale caracteristicilor de calitate cu care este nzestrat produsul. Diferena ntre cele dou tipuri de modele const n faptul c rezultatul obinut prin modelul de evaluare comparat cu costul efectiv nu trebuie s difere foarte mult, n timp ce ntre nivelul estimat al costului testrii i nivelul efectiv al costului, diferenele 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 informaii suficiente privind grupe omogene de produse software, (2) nregistrrile sunt n paralel pentru proiect i pentru produsul existent, (3) se vor efectua estimri suficient de fine ale coeficienilor i (4) se vor gsi modele comune, costul testrii estimat i cel evaluat nu vor mai diferi semnificativ. Lucrarea prezint tehnici i metode de testare software i identific factorii care influeneaz nivelul costurilor testrii. Dup realizarea acestor etape se procedeaz la construirea de modele destinate evalurii costului testrii. Sunt prezentate modele liniare i modele neliniare de evaluare a costului testrii, 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 aparinnd unor clase de complexitate distincte. Abordarea de fa se bazeaz pe cercetri 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 conferine i simpozioane naionale i internaionale. Pentru modelele prezentate au fost utilizate instrumente de evaluare a coeficienilor i s-a procedat la efectuarea de experimente, msurndu-se acurateea acestora.

Cercetrile ntreprinse n domeniul testrii software i n domeniul modelrii costurilor acestui proces au impus verificarea tuturor ipotezelor folosind mai multe aplicaii informatice, dintre care n lucrarea de fa se includ rezultate obinute referitoare la aplicaia de servicii casnice electronice, creia i s-a asociat acronimul e-DSI (electronic Domestic Services Integration), la care se fac referiri n aceast lucrare. Aplicaia are peste 4000 linii surs i a fost scris utiliznd limbajul de programare Java. La realizarea aplicaiei au fost folosite principii de design specifice utilizatorilor neomogeni din punct de vedere al nivelului de instruire. S-a urmrit trecerea printr-o succesiune de iteraii la un stadiu rafinat care s conduc la maximizarea ratei de acces cu finalitate din punct de vedere al oricrui utilizator. Vocabularul utilizat este accesibil membrilor colectivitii neomogene i de asemenea, sunt utilizate formule imperative. Alegerea aplicaiei pentru care se experimenteaz ipotezele avansate n capitolele 5, 6 i 7 are la baz necesitatea dezvoltrii de software pentru accesul unor tipologii neomogene de utilizatori, cu maximizarea ratei de succes a finalizrii actului de referire lan de proceduri. Lucrarea este structurat pe mai multe capitole i abordeaz gradat problematica modelrii costurilor determinate de efortul necesar testrii software. Capitolul Tehnici de testare software prezint procesul de testare, tehnicile i metodele de testare specifice aplicaiilor software. Sunt avute n vedere aplicaiile clasice, aplicaiile realizate utiliznd tehnologii orientate obiect i aplicaiile distribuite. n capitol sunt fcute referiri la utilizarea tehnicilor de testare pentru aplicaia e-DSI. n capitolul Factori de influen a testrii sunt dezvoltate aspectele care permit identificarea factorilor de influen a costurilor testrii, dintre care complexitatea produselor software i apartenena 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 ci de reducere a cheltuielilor care apar n procesul de testare. Utilizarea modelelor liniare n evaluarea costului testrii software (CTS) este capitolul n care se propune o serie de modele liniare pentru evaluarea costului testrii. n funcie de factorii care influeneaz costul testrii identificai sunt construite modelele liniare pentru evaluarea costului testrii. Este propus o modalitate de analiz a modelelor liniare obinute. De asemenea, sunt identificate ci de rafinare a modelelor liniare i se 7

studiaz stabilitatea modelelor. Prin utilizarea seturilor de date ale aplicaiei e-DSI se estimeaz coeficienii 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 testrii software. Sunt descrise o serie de modele care au la baz funcii neliniare i sunt prezentate curbele de evoluie ale costului n funcie de factorii luai n considerare i modalitile de estimare a parametrilor. De asemenea, se identific posibiliti 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 testrii. Se obin diferite structuri arborescente de ierarhizare corespunztoare abordrilor specifice domeniilor de aplicabilitate ale produselor software. Pentru fiecare metod de ierarhizare propus sunt prezentate elementele necesare implementrii unei aplicaii care s realizeze ierarhizarea modelelor de evaluare a costului testrii 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 aplicaiei. Se are n vedere testarea software difereniat a programelor pentru structurile liniare, structurile decizionale, structurile repetitive, structurile de date statice i structurile de date dinamice. n capitolul Testarea aplicaiei e-DSI este descris aplicaia 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 aplicaiei e-DSI sunt puse n aplicare modelele de evaluare a costurilor luate n considerare. Au fost parcurse toate etapele n dezvoltarea aplicaiei i au fost strnse informaii privind efortul de testare indus. Sunt analizate comparativ rezultatele obinute pe cale experimental. La sfritul lucrrii sunt incluse trei anexe. n lucrare au fost utilizate o serie de acronime a cror semnificaie este dat n anexa Lista acronimelor utilizate . Anexa Notaii utilizate conine semnificaia celor mai importante variabile utilizate n lucrare.

n anexa Instrumente pentru asistarea procesului de testare sunt prezentai principalii productori de produse pentru asistarea testrii software i sunt descrise instrumentele utilizate n testarea automat care exist pe piaa mondial la ora actual. Pentru majoritatea produselor sunt date i preurile acestora. n ideea realizrii unei aplicaii denumit e-DSIEX, care s extind aplicaia e-DSI, se fac estimri cu privire la caracteristicile noii aplicaii (numr de linii surs, complexitate, productivitatea muncii) astfel nct pe baza acestora s se estimeze costul testrii aplicaiei extinse. Complexitatea procesului de testare presupune antrenarea unui volum important de resurse i o gestionare adecvat a riscului persistenei diferenelor ntre specificaii i produsul program. n aceste condiii apare necesar definirea unei concepii unitare privind managementul activitii de testare i n mod corespunztor includerea sa ca etap distinct n managementul proiectelor software. Este propus o tehnic de rafinare a modelelor de evaluare a costurilor testrii pentru a mri gradul de operaionalitate a acestora. Lucrarea se ncheie cu concluzii, n care se stabilesc direcii pentru adoptarea modelelor construite de ctre noile aplicaii specifice procesului de globalizare, aplicaii care trebuie s funcioneze fr incidente i care trebuie s fie nzestrate cu caracteristici precum robustee, accesibilitate, fiabilitate etc., pentru a face fa tuturor categoriilor de utilizatori. Pentru realizarea acestei cercetri au fost parcurse peste treizeci de cri i tratate fundamentale din domeniul economiei aplicaiilor i din domeniul ingineriei software, dintre care [MYER79], [BEIZ90], [PRESS00], [SOME01], [BOEH00] sunt eseniale. 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 productoare de software. Lucrarea este rezultatul unei activiti de documentare sistematic i a unei cercetri desfurat 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 identificrii tehnicilor eficiente de testare. Toate aceste cercetri 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 proprieti de maxim continuitate n mentenan. Lucrarea de fa vizeaz latura economic a procesului de testare software. Lucrarea a fost editat i finanat cu sprijinul proiectului de cercetare CNCSIS AT 687 Modele de estimare a costurilor aplicaiilor de e-business. 9

2
TEHNICI DE TESTARE SOFTWARE
2.1 Testarea etap a ciclului de dezvoltare software
Proiectarea aplicaiilor software de dimensiuni mari, dezvoltat n cadrul unei echipe, nu se face trecnd direct la implementarea programului, ci urmeaz etape bine stabilite. Procesul de dezvoltare al aplicaiilor software este alctuit din urmtoarele etape: specificarea cerinelor, analiz, proiectare, implementare, testare i ntreinere. n figura 2.1 este prezentat grafic modelul clasic de dezvoltare software [PETE00].
Specificarea cerinelor Analiz Proiectare Implementare Testare ntreinere

Figura 2.1 Modelul clasic de dezvoltare software

10

n etapa de specificare a cerinelor se determin necesitile pentru toate elementele sistemului, att hardware ct i software. Cerinele privind aplicaia e-DSI au fost analizate mpreun cu beneficiarul. Pornind de la cerina unei aplicaii accesibile ntr-o manier simpl, s-au stabilit variantele posibile de realizare i cerinele globale. S-a convenit cu privire la detaliile validrii sistemului de ctre beneficiar. Testarea specificaiilor se realizeaz prin metode de analiz static: inspecii, parcurgeri i analize tehnice. Etapa de analiz continu procesul de stabilire a cerinelor. Analistul trebuie s neleag domeniul informaiilor pentru software, funciile necesare, performanele i interfeele. Se documenteaz cerinele, iar acestea sunt revzute mpreun cu beneficiarul. n aceast etap este descris ceea ce trebuie s fac aplicaia informatic i nu modul n care se realizeaz. Pentru aplicaia e-DSI sunt definite principalele caracteristici ale aplicaiilor componente: magazin electronic, gestiunea bibliotecii, bugetul personal, agenda telefonic, reete 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 caracterizarea interfeelor. n aceast etap sunt identificate structurile de date, interfeele, modulele i sunt descrii algoritmii. Pentru fiecare modul n parte sunt definite specificaiile de realizare. Pentru aplicaia e-DSI s-a stabilit structura fiecrei aplicaii componente, arhitectura de baz, tabele din baza de date, modalitile de regsire i actualizare a datelor. Cazurile de test sunt rafinate i sunt adugate noi cazuri de test corespunztoare detaliilor introduse. n [PRES00] 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 mainii de calcul. Implementarea este cu att mai uor de realizat cu ct proiectarea se realizeaz mai n detaliu. Testarea n etapa de implementare are rolul de a evidenia diferenele dintre comportamentul produsului din specificaii i cel dat la nivelul utilizatorilor. Aplicaia e-DSI s-a implementat n limbajul de programare corespunztor cerinelor. Testarea se concentreaz att asupra logicii interne a programului, avndu-se n vedere ca anumite elemente ale acestuia s fie parcurse, ct i pe funcionalitatea extern a sa, pe baza specificaiilor. Se compar rezultatele efective obinute dup rularea programului cu seturi de date de test cu rezultatele scontate pe baza specificaiilor. n timp, dup livrarea la beneficiar, aplicaiile software sufer schimbri care se datoreaz erorilor descoperite pe parcursul funcionrii aplicaiei, modificrilor mediului n care ruleaz aplicaia (software, hardware) precum i noilor cerine de performan i funcionalitate dorite 11

de beneficiar. ntreinerea aplicaiilor 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 cerinele unui sistem sau component sunt complete i corecte, dac rezultatul fiecrei faze de dezvoltare ndeplinete cerinele sau condiiile impuse n faza anterioar i dac sistemul sau componenta final este n concordan cu cerinele specificate [PRES00]. Verificarea este mulimea activitilor care asigur c o aplicaie software implementeaz corect o anumit funcie. Testarea software este o component a procesului de V & V. Validarea este mulimea activitilor care asigur c o aplicaie software realizat este n concordan cu cerinele beneficiarului. Pe msura dezvoltrii incrementale a aplicaiei e-DSI rezultatele din fazele intermediare sunt validate de ctre beneficiar. Testarea sau analiza static are ca scop examinarea aplicaiilor software fr a fi executate i cuprinde activiti precum inspeciile, execuia simbolic i verificarea. Aceste activiti fac parte din categoria evalurile tehnice [MYER79]. Inspeciile codului presupun citirea sau inspecia vizual a codului surs de ctre un grup de persoane. Avnd la dispoziie codul surs i specificaiile de proiectare, grupul de persoane din echipa de inspecie urmrete explicaiile programatorului legate de logica programului, instruciune cu instruciune. 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/ieire, erorile de interfa etc. Parcurgerile constau n citirea sau inspecia vizual a codului surs de ctre un grup de persoane, ns procedura de lucru este diferit avnd ca scop execuia logic a fiecrei secvene de cod de testat pe baza unor seturi de test pregtite anterior. Prin urmrirea programului pas cu pas sunt identificate erori care apar la acest nivel. Rezultatele acestei activiti de verificare depind, ca i n cazul inspeciilor codului, de atitudinea echipei fa de persoana care a scris programul, avnd n vedere faptul c atenia 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. 12

Testarea dinamic presupune examinarea aplicaiilor software n scopul generrii datelor de test cu care acestea vor fi executate i rularea aplicaiilor cu seturile de date de test obinute. Se observ c spre deosebire de testarea static, testarea dinamic presupune execuia aplicaiei care se testeaz. Exist dou strategii de dezvoltare a cazurilor de test: o strategie bazat pe structura programelor i o alta, bazat pe funcionalitatea 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 aplicaiei precum i etapele i nivelurile procesului de testare software.
Beneficiar Cerine: aplicaie de servicii casnice electronice Validare Dezvoltare Specificare cerine Proiectare teste Analiz Testare

Verificare

Proiectare

Implementare

Testare de module Testare de integrare Testare de sistem

Execuie teste

Integrare

Recepie e-DSI

Testare de acceptare

Sistem

Figura 2.2 Testarea software n ciclul de dezvoltare

13

n cadrul testrii de module se realizeaz verificarea celor mai mici uniti software care pot fi compilate i link-editate independent. n programarea clasic un modul este un subprogram (funcie sau procedur). n cadrul programelor orientate obiect, cea mai mic unitate testabil este clasa. Testarea de module se concentreaz asupra verificrii interfeelor modulelor, structurilor de date locale, condiiilor de la limite, cilor independente i cilor de tratare a erorilor. [PRES00] Deoarece modulele nu sunt programe de sine stttoare, este necesar s se construiasc programe sau funcii care s ajute la testarea de module. O prim categorie o reprezint programele conductoare (drivers) care apeleaz modulele supuse testrii cu datele de test construite i preiau rezultatele execuiei. O alt categorie este reprezentat de funciile sau procedurile apelate de ctre modulul de testat. Acestea sunt substituite cu subprograme care au acelai prototip, ns cu funcionalitate redus la minim, denumite module vide (stubs). Modulele vide sunt funcii sau proceduri simple care nu fac nimic n afara returnrii controlului, sau sunt funcii sau proceduri complexe, care simuleaz efectul apelrii modulelor reale. n cele mai multe cazuri, modulele vide simple sunt nepotrivite. Un efort considerabil este necesar 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 interfaa 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 obinut. Un element important n execuia testului este secvena n care modulele trebuie s fie testate. Astfel, testarea de integrare se realizeaz ascendent (bottom-up), descendent (top-down) sau mixt. Metoda de testare ascendent (bottom-up testing) presupune testarea mai nti a modulelor de pe cel mai de jos nivel al ierarhiei programului, apoi se continu n sus cu testarea celorlalte module. Metoda de testare ascendent necesit construcia de programe conductoare pentru a iniializa 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 14

pot influena multe module care au fost deja testate. Dup corecia erorilor este necesar ca toate modulele de pe nivelurile de jos s fie testate regresiv.
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 aplicaiei e-DSI, modulele Adaug, Caut, Modific i Edit sunt integrate i testate, modulul Agenda mea fiind nlocuit cu un modul conductor, care le apeleaz. n metoda testrii descendente (top-down testing), modulul din vrful ierarhiei de programe este testat primul, procesul de testare continund cu modulele de pe nivelurile inferioare. Metoda de testare descendent necesit construcia 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 testrii de integrare descendent. Modulele Agenda mea, Adaug i Caut sunt deja integrate i testate, modulele Modific i Edit fiind nlocuite cu module vide.

15

Agenda mea

Adaug

Caut

Modific

Edit

Figura 2.4 Testarea de integrare descendent n cadrul metodei mixte, testarea urmeaz mai nti metoda descendent. Modulele selectate de pe nivelurile inferioare sunt testate utiliznd metoda ascendent. Aceast flexibilitate permite preluarea avantajelor metodelor de ascendent i descendent. n cele mai multe aplicaii, metoda mixt este cea mai potrivit modalitate de abordare. Aplicaia e-DSI a fost testat utiliznd aceast metod de integrare. Pe msur ce sunt adugate noi module n cadrul testrii de integrare, apar schimbri n software, care pot s modifice comportamentul structurii obinute anterior. n acest context este executat testarea de regresie, prin care se re-testeaz noua structur obinut, utiliznd o parte din testele utilizate n etapa precedent de integrare. Testarea de validare are loc dup ce toate erorile de interfa descoperite n cadrul testrii de integrare au fost corectate. Testarea de validare se ncheie cu succes atunci cnd funcionalitatea aplicaiei software este n conformitate cu cerinele beneficiarului. Pentru testarea de validare se utilizeaz o serie de teste funcionale pentru a confirma faptul c aplicaia software se comport conform cerinelor. n cadrul testrii de validare se regsesc testrile alfa i beta. Testarea alfa este realizat la firma care produce aplicaia software, beneficiarul fiind acela care conduce testele. Testarea beta este realizat la beneficiari i utilizatori finali. Acetia primesc o versiune a aplicaiei software, versiune apropiat de cea final i o utilizeaz n scopul descoperirii erorilor i a problemelor de performan i funcionalitate. Problemele aprute n cadrul acestei testri sunt raportate firmei care a realizat aplicaia. Dup ce perioada acordat pentru testarea beta s-a terminat, toate erorile aprute sunt corectate, urmnd s se realizeze versiunea final a aplicaiei software. 16

Pentru testarea aplicaiei e-DSI au fost nregistrate observaiile primite de la o serie de utilizatori care au folosit aplicaia n diverse stadii ale acesteia n scopul identificrii problemelor i neajunsurilor din utilizare. Utilizatorii care au testat aplicaia au niveluri de pregtire i experien n lucrul cu calculatorul diferite. Dup ce a avut loc testarea aplicaiei software, intervine testarea de sistem, prin care se testeaz ntregul sistem n care produsul software este o parte component a acestuia. Testarea de sistem presupune rularea unor teste diferite, astfel nct s fie examinate toate caracteristicile sistemului. n literatura de specialitate, [PRESS00], [PETE00], [MYER79] sunt prezentate cteva tehnici specifice pentru testarea de sistem. Astfel, se identific testarea pentru determinarea capacitii de recuperare (recovery testing), testarea securitii, testarea de solicitare (stress testing), testarea de ncrcare (load testing) i testarea performanelor (performance testing). Testarea pentru determinarea capacitii de recuperare este un test de sistem care, printr-o multitudine de ci, foreaz aplicaia software s i ncheie execuia n mod necorespunztor. Prin acestea se testeaz capacitatea aplicaiei de revenire dintr-o situaie necorespunztoare. Testarea securitii se realizeaz pentru a verifica eficiena mecanismelor de protecie dintr-un sistem software i dac acesta se comport corespunztor la atacurile externe. Testarea de solicitare se execut astfel nct sistemul s funcioneze cu un volum mai mare de resurse dect cel normal, cu scopul de a determina fiabilitatea aplicaiei i momentul n care funcionarea aplicaiei devine critic i pentru a lua msurile corespunztoare, astfel nct s nu se ajung n exploatarea de zi cu zi a sistemului informatic la astfel de situaii. Utiliznd instrumente care simuleaz existena mai multor utilizatori simultan, precum JMeter i Rational SiteCheck, pentru aplicaia e-DSI s-au descoperit cazuri n care serverul devine inaccesibil. Acest lucru impune verificarea configurrii serverului de Web sau a procesorului JSP, prin modificarea numrului de clieni care acceseaz aplicaia simultan. Testarea de ncrcare const n rularea sistemului software n condiiile n care resursele (memorie, microprocesor, reea) sunt ncrcate la maxim astfel nct se ajunge la situaii critice, n care o parte din resurse nu mai sunt disponibile. Se urmrete capacitatea sistemului de a-i ntrerupe funcionarea fr pierderea sau coruperea datelor. Testarea performanelor se realizeaz pentru determinarea conformitii sistemului cu cerinele de performan impuse. De exemplu sistemul este ncrcat ntr-un interval de timp pornind de la capacitatea minim pn la capacitatea maxim i se verific dac resursele sistemului 17

se afl n limitele corespunztoare i nu sunt ntrzieri n executarea funciilor aplicaiei. Prin folosirea de instrumente pentru msurarea performanelor aplicaiei e-DSI (precum JMeter) s-a constat c aplicaia rspunde n limite acceptabile, cu excepia primei cereri efectuate, datorit particularitilor serverului Web i a motorului JSP.

2.2 Fazele procesului de testare software

Fazele procesului de testare sunt: planificarea, analiza i proiectarea, implementarea i execuia i evaluarea testelor. Planificarea testelor se realizeaz n strns legtur cu planificarea derulrii proiectului. n faza de planificare a proiectului pentru testare se aloc resurse, specificndu-se bugetul i perioada de timp n care se va derula testarea. Pe baza acestora se realizeaz planificarea detaliat a procesului de testare. Planificarea testrii are scopul de a determina ce s testeze i ct s testeze, astfel nct procesul de testare s se ncadreze n limitele resurselor alocate. n urma planificrii testrii rezult planul de test, un document pe baza cruia se desfoar celelalte faze ale testrii. n aceast faz se identific i obiectivele testrii. Planul de test este un document important, fiind utilizat ca baz pentru desfurarea ntregului proces de testare. n plus, trebuie identificate i sursele de risc n testare. Planificarea testrii poate s nceap din momentul n care au fost elaborate cerinele aplicaiei software [PETE00]. n planul de test sunt descrise: aria de cuprindere; responsabilitile fiecrui membru al echipei de testare; resursele umane necesare; desfurarea n timp a testelor; descrierea i configurarea mediului specific aplicaiei; lista echipamentelor care trebuie achiziionate; 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 finalizrii testrii. Analiza testelor rafineaz metodele prezentate n planul de test. n [DUST99] sunt prezentate etapele fazelor de analiz i proiectare a testelor. 18

Astfel, n etapa de analiz se identific urmtorii pai: identificarea scopurilor, obiectivelor i a strategilor testrii de ctre echipa de testare; metodele de verificare sunt asociate cerinelor sistemului sau cazurilor de utilizare i sunt documentate n cadrul unei matrice de urmrire a cerinelor; analiza cerinelor testelor; construirea matricei cerinelor testelor, n care declaraiile cerinelor testelor sunt asociate cerinelor sistemului sau a cazurilor de utilizare; asocierea tehnicilor de testare cu declaraiile cerinelor testelor. n faza de analiz a procesului de testare, un aspect important l ocup analiza cerinelor pentru testare. Cerinele testrii trebuie s fie identificate i documentate astfel nct toate persoanele implicate n procesul de testare s fie contiente de scopul acestuia. Analiza se desfoar din mai multe puncte de vedere, depinznd 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 urmtorii pai: definirea modelului programului de test astfel nct 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 nct fiecare cerin pentru datele de test s se reflecte pentru fiecare procedur de test. Programul de test se elaboreaz fie la nivelul proiectrii, fie la nivelul tehnicilor de testare. n primul caz, procedurile de test sunt asociate componentelor hardware i software ale aplicaiei, iar n al doilea caz procedurile de testare sunt vzute la nivelul tehnicilor de testare. Proiectarea procedurilor de test ncepe dup determinarea cerinelor testrii. Proiectarea procedurilor de test const n: analiza arhitecturii de test pentru determinarea tehnicilor de testare relevante; definirea procedurilor de test att la nivelul sistemului ct i la nivelul de implementare; elaborarea sau preluarea de standarde de utilizare a procedurilor de test; 19

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 att parametrii de intrare ct i rezultatele ateptate dup execuie utiliznd acei parametri. Realizarea de cazuri de test ct mai complete duce la descoperirea unui numr mai mare de erori. Procedurile de test identific toi paii necesari pentru executarea cazurilor de test specifice. Primul pas n faza de implementare este iniializarea mediului de implementare prin punerea la punct a arhitecturii dezvoltrii testelor. Un alt aspect important este identificarea standardelor pe care se bazeaz elaborarea secvenelor 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 convenii de scriere a programelor de test (alinieri, comentarii, prefixe pentru date). Implementarea secvenelor de test se realizeaz n limbaje specifice mediilor de testare (asemntoare Visual Basic) sau se utilizeaz limbaje de programare evoluate (C++, Java). Prin reutilizare se folosesc proceduri de test din proiectele anterioare sau din cadrul aceluiai proiect pentru module care au pri 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 intrri planul de test i orarul execuiei procedurilor de test, mediul de test fiind pregtit corespunztor. Ieirile fazei de execuie a testelor sunt rezultatele testelor, leciile nvate i orarul modificat al testelor. Execuia modulelor se realizeaz n conformitate cu planul de test. Procedurile de test descriu intrrile i ieirile ateptate dup execuie. n aceast etap din cadrul procesului de testare sunt rulate secvenele de test. Execuia secvenelor de test se realizeaz pe ct posibil n mediul specific aplicaiei iar dac nu este posibil, acest mediu este simulat. Rezultatele execuiei secvenelor de test sunt evaluate pentru a determina dac produsul a trecut testul cu succes. Evaluarea rezultatelor testelor se face de ctre un oracol. Oracolul este o persoan sau un

20

instrument automat, care pe baza specificaiilor determin dac rezultatele execuiei testelor sunt corecte sau nu. n figura 2.5 este prezentat fluxul procesului de execuie i evaluare a testelor pentru testarea la nivel de modul, bazat pe specificaii. Rezultatele testelor arat dac programul a trecut sau nu testul.
Program de testat Execuie Date de intrare Ieiri Evaluare Rezultate teste

Ieiri ateptate

Figura 2.5 Fazele de execuie i evaluare pentru testarea de module Rezultatele execuiei testelor se vor memora ntr-o baz de date care conine i alte informaii referitoare la aplicaia software realizat. Execuia i evaluarea testrii de integrare necesit noi secvene de test pe msur ce se adaug module n cadrul structurii programului care se testeaz. Aprobarea de ctre beneficiar a rapoartelor testrii de modul i ale testrii de integrare constituie ncheierea acestor faze. n execuia i evaluarea testrii de sistem, beneficiarul aplicaiei se implic mai mult dect n celelalte faze. n mod asemntor, acesta trebuie s semneze raportul de test pentru a considera ncheiat aceast faz de testare. Procesul de testare pentru aplicaia e-DSI a urmat aceleai etape, gradul de aprofundare fiind diferit.

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 cilor, ramificaiilor i fluxurilor programului. Principalele metode de testare structural au n vedere gradul n care cazurile de test acoper sau execut codul surs al programului.

21

Strategiile de testare bazate pe ci utilizeaz fluxul de control al programului. Acestea reprezint o familie de tehnici de testare bazate pe selectarea cu atenie a unei mulimi de ci din program. Dac mulimea cilor este aleas corespunztor, atunci se va atinge o anumit msur a profunzimii testului. Pentru utilizarea acestor tehnici este necesar cunoaterea complet a structurii programului i accesul la codul surs. Tehnicile sunt utilizate cel mai des de ctre programatori pentru testarea propriului cod. Cu ajutorul acestei tehnici se detecteaz erorile care cauzeaz execuia unei alte ci a programului dect aceea care trebuia s se execute. Graful asociat programului este o reprezentare grafic a structurii de control al programului, care utilizeaz elemente ca proces, decizie i jonciune. Un bloc de baz este o secven de instruciuni ale programului, nentrerupte de decizii sau de jonciuni. Un proces are o singur intrare i o singur ieire i const dintr-o singur declaraie/instruciune, dintr-o secven de declaraii/instruciuni, un singur apel de subrutin sau o secven din acestea. O decizie este un punct al programului n care fluxul de control continu pe una din alternativele oferite. Construciile if-then-else i switchcase sunt exemple de decizii cu dou ramuri, respectiv cu n ramuri, n2. Jonciunile sunt punctele din program n care fluxul de control se unete, care pot fi etichetele int ale unui salt, punctele n care se unesc ramurile unei instruciuni if-then-else etc. O cale ntr-un program este o secven de instruciuni care ncepe cu o intrare, jonciune sau decizie i se termin la alt (sau aceeai) jonciune, decizie sau ieire. O cale poate s treac prin cteva jonciuni, procese sau decizii o dat sau de mai multe ori. Un segment const dintr-o succesiune de legturi consecutive care aparin aceleiai ci. Lungimea unei ci este dat de numrul de legturi i nu de numrul de declaraii sau instruciuni executate de-a lungul cii. O metod alternativ de msurare a lungimii unei ci este numrul de noduri traversate. Dac programul are un singur nod de intrare i un singur nod de ieire, numrul de legturi traversate este mai mic cu unu dect numrul nodurilor traversate. Numele cii este dat de numele nodurilor de-a lungul cii. De exemplu n cadrul aplicaiei e-DSI diverse secvene de program au graful asociat asemntor celui din figura 2.6. Nodurile sunt numerotate corespunztor fluxului secvenei de program. O cale de la punctul de intrare pn la ieire se noteaz de exemplu cu 1-2-3-5-6-7-9-10. n mod asemntor, dac se noteaz legturile, numele cii este dat de succesiunea 22

numelor legturilor de-a lungul cii. Pentru aceeai 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 ieirea din program.

1 a 2 4 d e f 8 j k i 5 6

b 3 c

g 7 h

9 10

Figura 2.6 Nodurile i legturile grafului asociat unei secvene de program Tehnicile de testare bazate pe cile programului au la baz o serie de criterii de acoperire a codului care se testeaz precum: acoperirea instruciunilor, acoperirea ramificaiilor, acoperirea condiiilor, acoperirea ramificaiilor i a condiiilor, acoperirea condiiilor multiple i acoperirea tuturor cilor programului. Pe baza acestor criterii de acoperire a codului se determin seturile de date de test care se utilizeaz n testrile structurale corespunztoare: testarea instruciunilor, testarea ramificaiilor, testarea cilor etc. Criteriul pentru acoperirea instruciunilor este ca fiecare instruciune s fie executat cel puin o dat n cadrul unor teste. Dac se realizeaz acest obiectiv, atunci declaraiile sunt acoperite n proporie de 100%. Acest lucru este echivalent cu o acoperire a nodurilor fluxului de control asociat programului n proporie de 100%. Criteriul de acoperire a instruciunilor este criteriul cel mai slab, deoarece cazurile de test identificate astfel nct s fie acoperite toate instruciunile iau n calcul doar

23

acest criteriu, nefiind tratate toate situaiile posibile. Acest criteriu de acoperire se mai numete i criteriul C1. Acoperirea ramificaiilor are drept criteriu ca fiecare ramur a unei decizii s fie executat cel puin odat. Se ruleaz un numr suficient de teste pentru a se executa toate ramificaiile din program cel puin o dat. n cazul n care s-a realizat acest lucru, se atinge un procent de 100% a acoperirii ramificaiilor sau echivalent de acoperire a legturilor dintre nodurile grafului asociat programului. Pentru software-ul structurat testarea tuturor ramificaiilor include i acoperirea tuturor declaraiilor. Criteriul de acoperire a ramificaiilor se noteaz cu C2. Acoperirea condiiilor are ca obiectiv identificarea de date de test astfel nct fiecare condiie cu rezultat logic s ia valorile posibile (adevrat sau fals). n secvena:
if(criteriu!=null && !criteriu.equals(""))

pentru acoperirea ramificaiilor sunt necesare dou cazuri de test corespunztoare celor dou ramuri, iar pentru acoperirea condiiilor sunt necesare patru cazuri de test corespunztoare combinaiilor adevrat sau fals pentru cele dou condiii. Pentru acoperirea ramificaiilor i condiiilor criteriul de parcurgere a codului surs este o combinaie a criteriilor de la acoperirea ramificaiilor i acoperirea condiiilor. Criteriul de acoperire a condiiilor multiple are ca scop execuia cel puin o dat a fiecrei combinaii de stri posibile ale condiiilor. Acoperirea tuturor cilor programului are ca obiectiv execuia tuturor cilor fluxului de control din program, care ncep la intrarea n program i se termin la ieirea din program. Dac se reuete s se ndeplineasc acest criteriu, atunci se acoper cile n proporie de 100%. Acesta este cel mai puternic criteriu din familia de strategii de testare bazate pe ci i este, n general, imposibil de atins deoarece numrul de ci poate ajunge foarte mare, mai ales prin existena structurilor repetitive. Acoperirea declaraiilor i a ramificaiilor sunt cerine minime obligatorii pentru testarea structural. Pentru programele care conin bucle, acoperirea marginilor interioare (boundary-interior cover) este deseori utilizat pentru a executa bucla cel puin de dou ori. n primul caz se execut bucla fr iteraii, iar n al doilea caz se execut bucla cu una sau mai multe iteraii. Dac testarea se realizeaz utiliznd doar analiza cilor sunt detectate circa 25% din erori.[MYER79] 24

n capitolul 8 sunt tratate distinct problemele legate de testarea structural i sunt fcute aprecieri n legtur 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 selecia unei ci din fluxul de control al programului n scopul cercetrii secvenelor de evenimente referitoare la starea datelor. Testarea fluxului de date se bazeaz pe faptul c cel puin jumtate din codul surs const n declaraii de date, declaraii care definesc structuri de date, obiecte individuale, valori iniiale (sau implicite) i atribuite [BEIZ90], [PETE00]. Graful fluxului datelor este alctuit din noduri i legturi direcionate. Obiectivul su este acela de a prezenta deviaiile de la fluxul de date implementat fa de ceea ce s-a dorit la proiectare. Aciunile posibil de efectuat asupra datelor sunt: definire (d); este explicit, cnd variabila apare ntr-o declaraie de date i implicit, cnd variabila este ntr-o instruciune de atribuire; nedefinire (k); atunci cnd data nu mai este disponibil sau cnd coninutul ei nu este cu certitudine cunoscut; utilizare (u): o n calcule (c); variabila apare n partea dreapt a unei atribuiri, ntr-o expresie de calcul; o ntr-un predicat (p); cnd apare direct, de exemplu if (a<b), sau n condiia de ciclare a unei bucle. Anomaliile sunt reprezentate prin secvene de dou aciuni: dd variabil definit, dar nereferit; ku variabil nedefinit, dar referit; dk variabil definit, dar nereferit. Situaiile normale sunt du, kd, ud, uk, uu. La un moment dat, n cadrul unei ci pot exista situaiile din tabelul 2.1. Tabelul 2.1 Situaiile posibile ale datelor Descriere Situaie -k anomalie -d situaie normal -u anomalie, dac variabila nu este global ksituaie normal dposibil eroare uutilizat fr a fi distrus 25

O variabil se afl ntr-una din urmtoarele stri: K nedefinit, inexistent; D definit, dar neutilizat; U utilizat; A anomalie. n figura 2.7 sunt prezentate secvenele de aciuni prin care o variabil trece dintr-o stare n alta.

Figura 2.7 Graful strilor unei variabile Strategiile de testare pe baza fluxurilor datelor sunt: all-use: se consider o cale care ncepe cu definirea unei variabile i se ncheie la prima utilizare a acesteia; c-use: cile ncep cu definirea variabilelor i se ncheie cu instruciunea n care variabilele sunt folosite n calcule; p-use: o cale ncepe cu definirea unei variabile i se termin la instruciunea n care variabila este utilizat ntr-o condiie logic; du-use: const n parcurgerea tuturor fluxurilor de forma definire-utilizare pentru fiecare dat care apare n program. Strategia de testare pe baza fluxurilor datelor utilizat cel mai des este strategia du-use.

26

1 int n=0; 2 Produs produse[]; 3 public boolean AdaugaProdus(Produs p) 4 { 5 if(n<PMAX) 6 { 7 produse[n] = p; 8 n++; 9 return true; 10 } 11 return false; 12 }

Figura 2.8 Fluxurile de date pentru funcia AdaugaProdus n figura 2.8 sunt identificate cile du-use 1,7 pentru variabila n i 3,7 pentru variabila p, precum i cile c-use 1,8 pentru variabila n i 2,7 pentru variabila produse. Cile all-use ncep cu definirea unei date i se ncheie la prima utilizare. De exemplu pentru variabila n o cale este 1,5. Testarea bazat pe fluxul datelor nu este eficient n cazurile: determinrii strii unei variabile ntr-un punct al programului; masivelor; structurilor i listelor; numelor de funcii care sunt i ele variabile. n metoda de testare bazat pe mutaii, selectarea datelor de test se face pornind de la dou ipoteze: 1. programatorii realizeaz programe "aproape corecte"; 2. datele de test care detecteaz erori simple sunt de asemenea eficiente n detectarea erorilor complexe. [BEIZ90] Se realizeaz mutaii ale programelor prin modificarea unei singure declaraii n programul original. Apoi se aleg datele pentru a distinge toate mutaiile fa de programul original verificndu-se astfel capacitatea cazurilor de test alese de a descoperi erorile introduse n program prin mutaii.

27

2.4 Testarea funcional

Testarea funcional (black-box testing) este o strategie de testare care necesit cunoaterea comportamentului extern al programului pe baza specificaiilor. Testarea funcional nu necesit cunoaterea structurii interne a programului sau cunotine despre modul n care este implementat programul sau modulul. Principalele tehnici de testare funcional sunt testarea cu intrri aleatoare, partiionarea pe clase de echivalene, analiza valorilor limit, graful cauz-efect i ghicirea erorilor. Testarea cu intrri aleatoare pornete de la domeniul datelor de intrare i const n generarea de date de test n mod aleator, n cadrul domeniului acestora. Este o tehnic slab de testare, cu cel mai mic procent de descoperire a erorilor. Aceast tehnic de testare a fost dezvoltat, astfel nct datele de test sunt alese aleatoriu din domeniu i sunt filtrate astfel nct s ndeplineasc anumite condiii, ca de exemplu producerea unui rezultat dintr-o clas de ieiri posibile. Partiionarea pe clase de echivalene const n mprirea domeniului datelor de intrare n subdomenii, astfel nct comportamentul programului s fie acelai, cel puin teoretic, pentru orice dat de intrare din subdomeniul corespunztor. De exemplu, pentru funcia care returneaz valoare absolut a unui numr ntreg, un subdomeniu ar fi intervalul numerelor strict negative, iar un alt subdomeniu ar fi cel al numerelor pozitive. Dintr-un numr ridicat de cazuri de test posibile se ajunge la dou cazuri de test. Caracteristicile partiionrii pe clase de echivalene sunt: domeniul datelor de intrare este mprit n clase de echivalene; elementele din aceeai clas sunt tratate n mod asemntor; de asemenea se are n vedere partiionarea ieirilor; se consider att clasele valide ct i cele invalide; pentru testare se alege cel puin un element din fiecare clas de echivalen. Prin utilizarea analizei valorilor limit pentru realizarea cazurilor de test, pentru fiecare parametru al funciei se determin un set de valori aflate la limita domeniul de validitate. Analiza valorilor limit se concentreaz asupra valorilor de la limita claselor de echivalene i sunt avute n vedere limitele att n spaiul intrrilor ct i n spaiul ieirilor. Dac li este limita inferioar i ls este limita superioar a domeniului unei date de intrare de tip numeric, pentru aceasta se vor construi urmtoarele cazuri de test: li-1, li, li+1, ls-1, ls i ls+1 (figura 2.9). 28

li-1

li l i+1

ls-1

ls

ls+1

Figura 2.9 Valorile limit pentru date numerice n cazul aplicaiei e-DSI, validarea sumelor introduse ca venit impune teste pentru valori mai mici dect zero, egale cu zero i valori peste zero. Avnd n vedere faptul c n baza de date venitul se memoreaz ca long, valori posibile pentru teste sunt de exemplu -1, 0, 1, MAX_LONG-1, MAX_LONG i MAX_LONG+1, unde MAX_LONG reprezint o constant egal cu valoarea maxim care se poate reprezenta pe formatul long int. Pentru parametrii de tip ir de caractere de lungime maxim L se aleg ca exemple de test: irul vid,; irul avnd un caracter; irul de lungime L-1; irul de lungime L; irul de lungime L+1. n cadrul aplicaiei e-DSI exist o serie de date de intrare de tip ir de caractere. De exemplu, pentru numele unei persoane care se introduce n agend, valorile posibile de test sunt irul vid, un caracter, un nume format din patru caractere, un nume alctuit din numrul maxim de caractere rezervate n baza de date (50) i un ir de caractere care depete acest numr maxim. De asemenea, n cazul irurilor de caractere, pentru teste se utilizeaz i caractere speciale, avnd n vedere faptul c exist prelucrri care se efectueaz asupra irurilor de caractere n cadrul sistemului de gestiune a bazelor de date. La aceste toate aceste cazuri de test se adaug valori din interiorul domeniului variabilelor. Graful cauz-efect este o tehnic pentru alegerea cazurilor de test ntr-un mod sistematic i are la baz un limbaj formal n care sunt translatate specificaiile bazate pe limbajul natural. Cauza este o condiie distinct de intrare sau o clas de echivalen iar efectul este o condiie de ieire sau o transformare a sistemului.

29

n [MYER79] este prezentat o metod de testare de ghicire a erorilor, metod care nu presupune utilizarea unei metodologii anume, ci se bazeaz pe intuiia anumitor persoane i capacitatea acestora de a descoperi erori.

2.5 Testarea software orientat obiect

Programarea orientat obiect presupune definirea de clase i obiecte, construirea de ierarhii, precum i referirea obiectelor create. n cazul n care clasele sunt bine definite, reutilizarea genereaz efecte pozitive. Cnd clasele sunt subdefinite este necesar construirea de clase derivate de completare. Cnd clasele sunt supradefinite apar restricii de referire i de reutilizare. Testarea complet a claselor este premisa reutilizrii. Testarea claselor evideniaz gradul de motenire i de acoperire probabil a tipologiilor de clase de probleme prin constructori/destructori definii. Sistemul orientat obiect este caracterizat printr-un nivel foarte ridicat al reutilizrii software. De aceea el a ctigat teren n faa metodologiilor clasice, tocmai datorit acestui aspect al reutilizrii. Dac nu ar fi reutilizarea, tehnologia orientat obiect ar fi la fel ca celelalte, doar puin mai rapid. Construirea clasei CosCumparaturi n cadrul aplicaiei e-DSI este echilibrat, nefiind necesar obinerea de clase derivate. Mai mult, definirea de metode de tipul get, face ca referirea membrilor s se fac fr utilizarea de parametri: getNumarProduse(); Numeroase aplicaii complexe se prezint sub forma unor programe apelatoare, corespunztor limbajului C++ funcia principal main(), care conin secvene lungi de directive #include iar ca instruciuni executabile, n general structuri liniare de expresii de definire de obiecte i referire a funciilor membre ale obiectelor definite [IVAN99]. Testarea software orientat obiect presupune dou planuri: testarea construciilor proprii; testarea construciilor incluse pentru reutilizare. Metodele orientate obiect utilizeaz strategii diferite de ncapsulare fa de metodele convenionale, acest lucru avnd un dublu impact asupra testrii software [BERA90]: cea mai mic unitate testabil nu mai este modulul; strategia pentru testarea de integrare trebuie modificat. n mediile neorientate obiect, unitatea testabil are o interfa bine definit i realizeaz o singur funcie specific. ntr-un mediu orientat 30

obiect se utilizeaz clasele, care sunt uniti de program mari datorit faptului c acestea includ metode i date membre. Metodele unei clase nu mai pot fi testate izolat, ci n contextul clasei creia aparin. Testarea software orientat obiect are pe lng obiectivul general al stabilirii msurii n care produsul software realizeaz sarcinile prezentate n specificaii, obiective specifice legate de: testarea funciilor membre ale fiecrei clase; testarea gradului de ncapsulare i a efectelor acestuia; testarea efectelor induse de nivelurile de motenire i de derivare; testarea efectelor induse de polimorfismul funciilor membre; testarea interaciunilor dintre clase. Spre deosebire de aplicaiile software dezvoltate prin alte metode, n cazul programrii orientate obiect testarea vizeaz i msura n care clasele sunt proiectate n vederea reutilizrii. Astfel, se evideniaz gradul de generalitate i, mai ales, concordana ntre specificaiile fiecrei funcii i ceea ce funcia realizeaz efectiv. Rezultatul testrii vizeaz dou aspecte: secvena referirilor determin pentru exemplele de test rezultate acceptabile sau nu, ceea ce se rsfrnge asupra produsului ca atare; rezultate privind msura n care clasele definite sau referite acoper cerinele unei reutilizri confortabile, fr nevoia de a construi interfee sau de a realiza derivri n obinerea de clase noi cu un nivel de saturare redus, create n mod special i destinate unor utilizri cu totul particulare. Dac produsul este acceptat pentru calitile lui n raport cu problema de rezolvat, nu este obligatorie i acceptarea claselor definite. n acelai fel, clasele definite pot ndeplini condiiile de reutilizare, fr ca programul s fie acceptat n urma testrii. n ciuda avantajelor pe care limbajele i metodologiile orientate obiect le ofer, testarea rmne necesar. Destul de des sistemele complexe produc rezultate neanticipate. Rolul testrii n domeniul orientat obiect deriv din mai multe lucruri, dar n principal din faptul c acele componente realizate pentru reutilizare trebuie s fie de nalt fiabilitate. O testare extensiv trebuie asigurat atunci cnd este destinat reutilizrii. Testarea este necesar pentru a obine o nalt fiabilitate n sistemele orientate obiect. Paradigmele ingineriei software orientate obiect sunt ascunderea informaiei, motenirea i polimorfismul. Acestea influeneaz modul n care se testeaz aplicaiile orientate obiect fa de aplicaiile clasice. 31

Ascunderea informaiei presupune c sunt vizibile doar acele informaii care sunt necesare la un moment dat n scopul atingerii unor obiective specifice. Dac sunt accesibile mai multe informaii dect este necesar, crete posibilitatea apariiei erorilor. n msura n care limiteaz domeniul de accesibilitate, ncapsularea cu ascunderea informaiei este un obstacol pentru testare, innd cont de faptul c strile implementate nu mai sunt controlabile i observabile. Pentru clasa CosCumparaturi, accesul la data membr n ar fi imposibil dintr-o funcie de test dac n clas nu ar exista metoda care returneaz valoarea acestui membru. Motenirea se definete ca fiind o relaie ntre clase n cadrul creia o clas partajeaz structura sau comportamentul definite ntr-o alt clas (motenire simpl) sau n mai multe clase (motenire multipl) [BOOC91]. Noi oportuniti de eroare vin odat cu puterea crescut a limbajelor orientate obiect. Fiecare nivel nou n ierarhia de moteniri este un nou context pentru caracteristicile motenite. Comportamentul corect la un nivel superior al ierarhiei nu garanteaz n nici un fel comportamentul corect la un nivel inferior. Polimorfismul este exemplul cel mai practic al reutilizrii, fiind prin definiie capacitatea unei entiti de a lua mai multe forme. Legarea dinamic joac un rol n determinarea cerinelor testrii, dar numai n contextul testrii de integrare. Legarea dinamic creeaz posibilitatea unui set de mesaje (combinaii de obiecte emitoare i receptoare de mesaje), ceea ce nseamn c va fi nevoie de mai multe teste (n locul unuia singur) pentru a testa un mesaj specific. Polimorfismul i legarea dinamic cresc foarte mult numrul cilor posibile de execuie. Analiza static a codului surs pentru identificarea cilor nu mai este de mare ajutor n acest nou context. n [CHAN02] sunt prezentate nivelurile la care sunt testate programele orientate obiect: nivel algoritmic; metodele claselor sunt tratate independent; aplicarea tehnicilor de testare clasice se realizeaz fr probleme; nivelul clasei; clasa este testat ca o entitate de sine stttoare; sunt integrate metodele care au fost testate la nivelul anterior; nivel de grup (cluster); testarea se concentreaz asupra integrrii claselor; se au n vedere apelurile de metode efectuate ntre clase i sincronizrile dintre obiectele concurente; nivel de sistem; sunt testate interaciunile dintre grupurile de clase. n [SIEG96] este prezentat o metod de testare ierarhic a aplicaiilor software orientate obiect. Aceast metod de testare se utilizeaz 32

i se construiete pe baza unor tehnici de testare cunoscute, legate mpreun ntr-un sistem de testare corespunztor. Metoda definete i aplic standarde de testare pentru cteva niveluri ale componentelor software: obiecte, clase, componente de baz i sisteme. Metoda de testare ierarhic const n desemnarea ca fiind corespunztoare acele componente care ndeplinesc standardele de testare pentru tipul respectiv de component. Odat ce o component a fost calificat drept corespunztoare prin testare, aceasta va fi integrat cu alte componente care au fost desemnate ca fiind corespunztoare, pentru a realiza mpreun componentele de pe nivelul urmtor. Starea de a fi corespunztor pentru o component este relativ i depinde foarte mult de standardele utilizate pentru realizarea aplicaiei, de atitudinea fa de risc, de riscurile specifice i de practicile de management al riscului adoptate n cadrul proiectului. Metoda ierarhic elimin obligativitatea testrii tuturor combinaiilor de stri n timpul testrii de integrare, ceea ce duce la creterea productivitii prin accesarea doar a interconexiunilor dintre componentele de baz i orice funcionalitate complex nou. Metoda de testare ierarhic este reprezentat grafic n figura 2.10.

Figura 2.10 Metoda de testare ierarhic [SIEG96] Testarea ierarhic este utilizat pentru software cu grad de complexitate ridicat. Aplicaiile distribuite dezvoltate folosind tehnologii orientate obiect intr n aceast categorie.

33

n cadrul testrii ierarhice, sunt utilizate urmtoarele suite de teste: suita de teste condiionale care const din testarea claselor utiliznd modelul de testare condiional i aseriunile, excepiile, operaiile de testare concurente adiionale; suita de teste ierarhice incrementale utilizat pentru testarea componentelor de baz prin diverse modele de testare i scenarii; suita de teste de integrare pentru testarea combinaiilor de componente de baz utiliznd modelul ierarhic incremental cu scenarii care utilizeaz toate componentele, nu doar module vide; suita de teste de sistem care are ca scop testarea sistemelor componentelor de baz utiliznd modele de testare de sisteme; suita de teste de regresie pentru a testa componentele de baz i sistemul. La baza metodei ierarhice i incrementale de testare st ansamblul de relaii dintre clase. n mediul orientat obiect, ntr-o ierarhie de clase, cnd se testeaz o clas se testeaz n acelai timp i clasele printe i, construind teste, acestea pot fi reutilizate ulterior i pentru testarea subclaselor. Fiecare subclas este rezultatul combinrii structurii i comportamentului claselor prini cu atribute i metode noi. n figura 2.11 se observ cum, prin motenire, clasa derivat CosCumparaturi se obine prin combinarea clasei de baz Object cu un modificator, care cuprinde metodele i proprietile specifice clasei derivate. Dac se noteaz cu D clasa derivat, cu B clasa de baz i cu M modificatorul, se poate scrie c D = B M, conform [HARR92].
CosCumparaturi Object

Modificator

Figura 2.11 Modificarea incremental prin motenire

34

De exemplu, se consider o metod care aparine unei clase, aceasta fiind testat n contextul clasei sale. Se creeaz o nou clas din aceasta prin derivare, clas care va moteni i metoda testat anterior. Chiar dac metoda a fost testat n contextul superclasei, nu se poate garanta corectitudinea metodei n contextul subclasei pn cnd aceasta nu se testeaz n noul context creat. Cazurile de test bazate pe funcionalitate create pentru metodele din superclas nu sunt n ntregime adecvate acelorai metode din clasa derivat. De asemenea, vor trebui modificate i cazurile de test bazate pe structur n cadrul unei clase derivate au fost distinse trei metode: metode noi metode definite n subclase, incluzndu-le pe acelea cu acelai nume ca metoda din superclas dar cu parametri diferii; necesit o testare complet; metode recursive metode definite ntr-o superclas i care nu sunt supradefinite sau suprancrcate n subclas; necesit o retestare limitat dac metoda interacioneaz cu funcii membre noi sau redefinite; este nevoie doar s fie retestat obiectul care interacioneaz, nu toate obiectele; metode redefinite metode definite ntr-o superclas i supradefinit sau suprancrcat ntr-o subclas; se retesteaz prin reutilizarea modelelor de teste i obiecte dezvoltate din specificaii i mai puin pe baza logicii interne. De aici rezult c pentru un obiect va fi nevoie s se testeze doar prile care sunt noi. Acest lucru crete semnificativ productivitatea testrii, precum i productivitatea programrii i proiectrii. Motenirea multipl conduce la clasificri mai dificile, dar nu afecteaz categoriile n sine. Anumite modele de motenire multipl, din limbajul C++, determin existena aceleiai superclase n dou sau mai multe instane, n obiect, crend astfel mai mult dect o metod recursiv.

2.6 Testarea sistemelor distribuite bazate pe tehnologia Internet

Reelele de calculatoare au o extindere rapid ntr-o multitudine de domenii cum ar fi sistemul bancar, administraia public, alocarea temporar de resurse n hoteluri, rezervarea biletelor de avion, rezervarea biletelor de tren etc. Aplicaiile moderne iau n considerare accesul unui numr ct mai mare de utilizatori, mai ales de cnd se prevede extinderea folosirii cardurilor i crete numrul acelora care utilizeaz Internetul. 35

Aplicaiile distribuite constau n mai multe componente care ruleaz pe maini diferite, acestea aplicaii integrnd aciunile componentelor lor. Proiectarea aplicaiilor distribuite se axeaz nu numai pe detaliile prilor individuale, ci i pe realizarea unei integrri a componentelor distribuite, astfel nct acestea s coopereze foarte bine ntre ele. Principalele cerine pentru aplicaiile distribuite sunt: interfee puternice; fiabilitate foarte mare; securitate ridicat; vitez ridicat de prelucrare i transmitere a datelor. n mod tradiional, aplicaiile software distribuite se bazeaz pe arhitectura client/server sau pe arhitectura multistrat (n-tier). n contextul aplicaiilor client/server care utilizeaz baze de date, arhitectura client/server presupune existena unui server de baze de date (denumit server) i a unui modul software specific aplicaiei (denumit client) care prelucreaz datele i prezint rezultatele, deci conine logica aplicaiei i logica prezentrii. n acest sistem nu exist noiunea de obiecte, partea client lucreaz direct cu tabelele de date i procedurile stocate din baza de date. n cadrul arhitecturii multistrat, un server de aplicaii se interpune ntre aplicaia client i serverul de baze de date. Serverul de aplicaii implementeaz logica aplicaiei iar clientul implementeaz logica de prezentare a sistemului. Avantajul major al arhitecturii multistrat fa de arhitectura client/server l reprezint creterea flexibilitii. Arhitectura Web confer acestora fiabilitate, scalabilitate i flexibilitate ridicat. Arhitectura Web difer fa de arhitectura multistrat prin dou aspecte (figura 2.12): aplicaia client are o complexitate redus, fiind un navigator Web; nivelul regulilor aplicaiei este bazat pe componente i nu este un singur sistem ce implementeaz ntreaga construcie.

36

Baz de date A Naviga tor Server Web Server de aplicaii

Baz de date B

Figura 2.12 Arhitectura sistemelor bazate pe Internet Componentele client sunt interfeele grafice utilizator i ruleaz n navigatoare Web precum Netscape Navigator sau Internet Explorer. Componentele server care ruleaz ntr-un server de aplicaii, furnizeaz logica procesului de afaceri. Pentru testarea aplicaiilor distribuite bazate pe Internet, trebuie luate n considerare urmtoarele aspecte: capacitatea de utilizare; uurina n utilizare i nelegerea elementelor interfeei constituie elemente importante n acceptarea aplicaiei de ctre clieni; funcionalitatea; faptul c aplicaia realizeaz ceea ce i propune prin specificaii conduce la creterea ncrederii utilizatorilor n aceasta i n firma productoare; compatibilitatea; avnd n vedere faptul c exist o multitudine de combinaii ntre sisteme de operare, navigatoare i aplicaiile care ruleaz n navigatoare, asigurarea compatibilitii aplicaiei este o problem important, deoarece exist riscul ca o parte important dintre potenialii utilizatori s nu poat utiliza aplicaia datorit incompatibilitilor i astfel sunt pierdui o serie de clieni. performana; timpul de rspuns i resursele ocupate reprezint un aspect important pentru utilizatorii aplicaiei. n cazul aplicaiilor Internet care acceseaz baze de date exist o multitudine de cauze care duc la funcionarea incorect a acestora. De exemplu testul euat al unei tranzacii ntr-o baz de date poate avea mai multe cauze: logica bazei de date; procedurile stocate, interogrile sau comenzile de actualizare, inserare sau tergere conin erori; 37

logica serverului de aplicaii; exist erori de proiectare sau de programare n cadrul funciilor implementate n serverul de aplicaii; logica procesrii tranzaciilor; ordinea eronat a efecturii unor operaii conduce la euarea ntregii tranzacii; comunicaia; n cazul unor probleme de comunicaie la diverse niveluri, tranzaciile fie nu au loc, fie se realizeaz incomplet sau incorect. Testarea aplicaiilor bazate pe arhitectura Web, n plus fa de testarea aplicaiilor clasice, necesit o serie de teste specifice cum ar fi: testarea funcional, testarea de compatibilitate, testarea coninutului, testarea performanelor, testarea de ncrcare, testarea securitii, testarea serverului Web, testarea serverului de aplicaii i testarea bazelor de date. Testarea funcional se realizeaz pentru a constata dac site-ul se comport conform cu specificaiile sale. Detaliile acestui tip de testare depind de natura site-ului Web i, n general, const n verificarea legturile paginilor, testarea formularelor, verificarea tranzaciilor pentru comerul electronic i pentru baze de date, testarea applet-urilor Java. Prin testarea de compatibilitate se urmrete aspectul i comportamentul site-ului Web n raport cu o varietate de sisteme de operare i de navigatoare Internet. Aceast testare scoate n eviden problemele cu controalele ActiveX, applet-urile Java, funciile JavaScript sau VBScript i formulare din pagini. La ora actual exist peste 100 de combinaii posibile ntre diverse sisteme de operare Windows i diverse versiuni ale navigatoarelor Netscape i Internet Explorer. Pentru testarea coninutului se urmrete corectitudinea i aezarea n pagin a textelor, imaginilor i fiierelor de animaie i video din cadrul site-ului. Prin testarea performanelor se msoar comportamentul site-ului Web n diverse condiii de trafic. Testarea de ncrcare se utilizeaz pentru a verifica dac site-ul Web poate gestiona un anumit numr de utilizatori care l acceseaz concurent, n limite acceptabile ca timp de rspuns. Testarea securitii tranzaciilor efectuate este foarte important pentru aplicaiile de comer electronic avnd n vedere faptul c sunt vehiculate date confideniale, la care dac au acces persoane neautorizate sau ruvoitoare se pot produce pierderi materiale importante.

38

Testarea serverului Web are n vedere testarea interaciunilor dintre serverul Web i serverul de aplicaii, verificarea integritii bazei de date n cadrul serverului de baze de date, verificarea faptului c scripturile ASP, PHP sau JSP se execut corect pe server. Testarea serverului de aplicaii se realizeaz inndu-se seama de caracteristicile funcionale i structurale ale acestuia. Se testeaz componentele serverului, folosind metode clasice de testare, precum i metode de testare care iau n considerare tranzaciile i comunicaiile asincrone dintre aceste componente. Testarea bazelor de date presupune verificarea executrii corecte a interogrilor i operaiilor de adugare i actualizare a datelor, precum i verificarea conexiunilor dintre site-ul Web i baza de date. Testarea aplicaiilor distribuite bazate pe arhitectura Web este realizat fie de ctre echipe de specialitate din cadrul departamentului de asigurare a calitii al firmei, fie de ctre o firm specializat n testare (outsourcing). n Capitolul 10 sunt prezentate aspectele legate de testarea aplicaiei e-DSI bazat pe arhitectura Internet.

2.7 Testarea sistemelor distribuite bazate pe componente

Cele mai cunoscute tehnologii pentru dezvoltarea sistemelor distribuite bazate pe componente sunt CORBA, standardizat de Object Management Group, DCOM(COM+) dezvoltat de Microsoft i RMI dezvoltat de firma Sun. Aceste tehnologii presupun existena unor componente (denumite server) care, prin intermediul unor interfee, pun la dispoziie funcii, care sunt apelate de componente client aflate pe un alt sistem. Transferul n cadrul sistemului distribuit se realizeaz prin intermediul unui protocol bine definit.

39

Descriere IDL

Compilator IDL

Stub

Proxy

Server/Client

Compilator

CLIENT/ SERVER

STUB

PROXY

Figura 2.13 Generarea componentelor

n CORBA i DCOM interfeele sunt specificate utiliznd un limbaj de definire a interfeelor (IDL). Interfeele n CORBA i DCOM sunt compilate de ctre compilatorul IDL, respectiv MIDL, acesta genernd un proxy i un stub. Proxy-ul i stub-ul conin codul pentru declararea claselor la nivelul modulelor, interfeelor i excepiilor definite cu (M)IDL. De asemenea este generat cod pentru ncapsularea parametrilor metodelor (marshalling/unmarshalling). Codul stub-ului i al proxy-ului sunt compilate mpreun cu implementrile clientului i ale serverului pentru a obine codul executabil al aplicaiei (figura 2.13).

40

Cererile clientului sunt transmise ctre server prin intermediul stubului, ORB-ului i al proxy-ului (figura 2.14).

CLIENT

SERVER

PROXY

STUB

ORB (COM)

Figura 2.14 Execuia cererilor clienilor Componentele unui sistem distribuit opereaz deseori pe platforme i arhitecturi eterogene i, de aceea, este necesar ca instrumentele de testare s opereze i ele pe platforme i cu arhitecturi eterogene. Complexitatea aplicaiilor distribuite crete pe msur ce componentele din aplicaia software devin complicate. Testarea aplicaiilor distribuite bazate pe componente este vzut la nivel de: micro-model la acest nivel se descriu paii fiecrui test, pentru fiecare component n parte. Fiecare test conine cazuri de test, pentru fiecare caz de test n parte fiind definite driverul de test, datele de test, pre-condiiile i post-condiiile specifice fiecrei componente testate. macro-model n acest nivel se definete contextul n care fiecare test va fi rulat. Se are n vedere locul fizic n care se afl componentele. Acest nivel este orientat pe proces i are n vedere fazele de analiz, proiectare, implementare i livrare. Tolerana la erori este evaluat prin injectarea de erori n scopul determinrii posibilitii serverului de a trata aceste situaii excepionale. Pentru aceasta, trebuie determinate posibilele surse i tipuri de erori, utilizate pentru injectarea cu erori a interfeei serverului [GHOS00]. n cazul aplicaiilor bazate pe componente distribuite, erorile din fazele de proiectare i implementare apar la definirea interfeei, implementarea serverului i n codul client. 41

Cele mai frecvente erori apar n descrierea interfeei. O greeal des ntlnit este specificarea incorect a direciei parametrilor, astfel c un parametru de ieire este definit ca parametru de intrare sau invers. De exemplu se consider o metod ntr-o interfa care are ca scop adunarea a dou numere. Parametrii metodei sunt a i b de intrare i r de ieire, declaraia interfeei fiind:
interface ICalcule : IUnknown { // HRESULT Suma([in] double a, [in] double b, [out] double *r); // };

Dac pentru parametrul de ieire r nu se specific atributul out, atunci dei la compilarea interfeei cu compilatorul MIDL nu se va constata nici o eroare, la utilizarea metodei se va constata c r nu reprezint suma lui a i b. Majoritatea erorilor de programare apar n implementarea serverului. Codul client poate conine de asemenea erori de programare. Deseori apar erori n apelurile metodelor serverului, fie prin specificarea ordinii incorecte a parametrilor, fie prin utilizarea incorect a parametrilor. De exemplu, corespunztor interfeei de mai sus n codul client, n care se dorete efectuarea calculului z=x+y prin apelul metodei Suma a interfeei ICalcul, exist secvena:
double x=30.00993, y=88.49494, z=0.0; ICalcul *pIC; // pIC->Suma(x,z,&y); //

execuia metodei Suma va avea va efect y=x+z.

42

n aplicaiile distribuite exist diferite surse i tipuri de ncheieri nereuite a execuiei. Aceste nereuite sunt datorate unor cauze diverse, cum ar fi: probleme n cadrul componentelor (de exemplu blocarea serverului); probleme de comunicare n reea (ntrzieri, congestionarea reelei); probleme la nivelului ORB (de exemplu zona tampon a acestuia este plin); probleme legate de securitate i autentificare; probleme de sincronizare. n [McGR00c] este prezentat un model de testare distribuit (figura 2.15), precum i un limbaj ablon pentru testarea sistemelor distribuite.
Colaborator Driver de test

Interfaa obiectului de testat

Interfaa de test

Metod releu

Interfaa obiectului de test Obiect de testat (OUT)

Jurnal de urmrire

Figura 2.15 Elementele modelului de testare a sistemelor distribuite

43

Limbajul ablon pentru testarea sistemelor distribuite prezint urmtoarele caracteristici: izolarea obiectului de testat (OUT), care ajut la testarea implementrilor pariale i este util la testele unde colaboratorii sunt pariali; ncapsularea obiectului de testat pentru ca ncapsulatorul s aib aceeai interfa ca i clasa de testat (CUT) i metodele ncapsulatorului s poat modifica mesajele nainte de retransmitere; utilizarea metodelor ncapsulate pentru control; mesajele clienilor sunt redirecionate ctre ncapsulator; ncapsulatorul poate ntrzia i chiar poate reordona mesajele nainte de retransmitere ctre obiectul de testat; utilizarea unui jurnal de urmrire sincronizat; prin utilizarea jurnalelor de urmrire fiecare mesaj va avea asociat un astfel de jurnal, iar la analiza ulterioar se pot identifica secvenele testate; se vor testa toate mesajele posibile; utilizarea unui client substituit pentru c acetia pot ncapsula cazuri de test ca metode i, de asemenea, clientul poate fi un server; testarea complet a protocolului este necesar deoarece execuia corect a unei singure metode nu este de ajuns i, de aceea, se impune testarea secvenelor de mesaje care nsoesc o operaie; verificarea local a rezultatelor testelor; trimiterea fiecrui rezultat napoi ctre driverul de test este costisitoare iar distribuirea cunotinelor despre teste duce la o mbuntire a performanelor; testarea tuturor secvenelor posibile; utilizarea de ntrzieri ntre metode pentru a controla secvena execuiilor i acordarea unei atenii speciale ordinii n care se execut testele; utilizarea unui jurnal de urmrire distribuit; mbuntirea performanelor se poate face prin distribuirea jurnalului de urmrire; un dezavantaj l prezint necesitatea sincronizrii ceasurilor mainilor pentru acurateea jurnalelor;

44

captarea tuturor excepiilor la distan; trebuie acordat atenie excepiilor definite de infrastructur, avndu-se n vedere generarea de cazuri de test pentru activarea fiecrei excepii.

n momentul de fa se constat o scdere a duratei de proiectare i implementare ale aplicaiilor distribuite, n special ale aplicaiilor de afaceri electronice, datorat n principal necesitaii oportunitilor de afaceri de a ptrunde ct mai rapid pe pia. Scderea duratei ciclului de dezvoltare are consecine negative asupra procesului de realizare a aplicaiilor n cazul n care nu se acord o atenie sporit procesului de asigurare a calitii.

45

3
FACTORI DE INFLUEN A TESTRII
3.1 Criterii de clasificare a factorilor
Testarea software este influenat de numeroi factori. Varietatea acestora impune existena unor criterii de clasificare a lor, precum i luarea n considerare a acelora care influeneaz n mod semnificativ procesul de testare. Exist numeroase criterii de clasificare a factorilor. Astfel, se identific clasificri dup modul de aciune a factorilor, dup raportul dintre factori i procesul de dezvoltare software, dup posibilitatea de cuantificare a acestora (tabelul 3.1). Dup modul de aciune se identific factori cu aciune direct i factori cu aciune indirect. Astfel, factori cu aciune direct sunt: complexitatea produsului software; gradul de omogenitate a echipei de realizare software; tehnicile de dezvoltare utilizate; stadiul de certificare a firmei; numrul de utilizatori; specificul aplicaiei software. Aceti factori sunt analizai distinct n subcapitolele urmtoare. Principalii factori cu aciune indirect sunt existena de produse similare pe pia i gradul de noutate software i hardware. Testarea software este influenat att de factori externi ct i factori interni. n cadrul acestui criteriu de clasificare se are n vedere locul factorilor de influen n raport cu procesul de dezvoltare software. Un alt criteriu de clasificare a factorilor l constituie posibilitatea de cuantificare a acestora. Astfel, exist factori cuantificabili i factori necuantificabili. Factorii care influeneaz procesul de testare software sunt att de natur obiectiv, ct i de natur subiectiv.

46

Tabelul 3.1 Clasificarea factorilor de influen a testrii software Factor Tip Complexitatea produselor software Intern, Direct Dimensiunea aplicaiei Intern, Direct Gradul de omogenitate a echipei de Intern, Direct realizare software Tehnicile de dezvoltare utilizate n Intern, Direct realizarea produsului Stadiul de certificare a firmei Intern, Direct Numrul utilizatorilor Extern, Direct Existena de produse similare pe pia Extern, Indirect Gradul de noutate software i hardware Extern, Indirect Specificul aplicaiei software Intern, Direct Dup valorile pe care le pot lua factorii care influeneaz testarea se identific factori cu valori discrete, factori cu valori continue i factori cu valori logice corespunztoare prezenei caracteristicii de calitate, cu valoarea asociat 1 i, respectiv, absenei caracteristicii, cu valoarea asociat 0.

3.2 Complexitatea produselor software

Complexitatea software este unul dintre cei mai importani factori care influeneaz testarea software. S-a constatat faptul c pe msur ce crete complexitatea unui program, crete i probabilitatea ca programul s conin mai multe erori. Un concept general al noiunii de complexitate software este dat n [HEND96], care consider c aceasta este o funcie (X) care depinde de urmtorii factori: H cunoaterea uman; P complexitatea problemei; S mrimea programului; D structura datelor; L structura logic; Ch coeziunea intern; Cs coeziunea semantic; C gradul de cuplare.

47

Astfel, complexitatea software, , se exprim prin relaia: i = X i ( H , P, S , D, L, C h , C s , C ) unde i reprezint etapele ciclului de via software. n tabelul 3.2 este prezentat complexitatea software pentru fiecare etap a ciclului de via software: analiz, proiectare de ansamblu, proiectare de detaliu, codificare, testare i mentenan. Tabelul 3.2 Complexitatea software n ciclul de via software Etapa Complexitatea software 1 = X1 (H,P,Cs,C) Analiz Proiectare de ansamblu 2 = X2 (H,P,D,L,Ch,Cs,C) Proiectare de detaliu 3 = X3 (H,P,S,D,L,Ch,Cs,C) 4 = X4 (S,D,L,Ch,Cs,C) Codificare Testare 5 = X5 (H,S,D,L,Ch,Cs,C) Mentenan 6 = X6 (H,P,S,D,L,Ch,Cs,C) Din tabelul 3.2 se observ urmtoarele: n faza de analiz nu se pot evalua direct variabilele mrime, structura datelor, structura logic i coeziunea intern; n fazele de codificare i testare, complexitatea problemei nu mai are relevan pentru complexitatea software; n faza de mentenan, care presupune detectarea i corecia erorilor, toate variabilele care influeneaz complexitatea software sunt importante pentru nivelul complexitii software. Pe baza grafului asociat programului sunt construite msuri de complexitate structurale. Orice program poate fi reprezentat sub forma unui graf G = (V, E), unde V reprezint mulimea nodurilor din graf, iar E reprezint mulimea arcelor. Nodurile grafului reprezint blocuri de instruciuni (sau blocuri de baz), iar arcele reprezint fluxul controlului ntre diferitele blocuri de baz. Fiecare bloc de baz este format din instruciuni n secven fix ori de cte ori este lansat n execuie prima instruciune a blocului. Graful asociat unui program are n componen: un nod iniial, care se execut ntotdeauna primul; un nod final, care se execut ultimul; noduri intermediare, care se gsesc pe drumurile formate ntre nodul iniial i nodul final;

48

arce care unesc nodurile i care dau sensul execuiei programului sau secvenei de instruciuni. Structurii secveniale I1, I2, I3, , In-1, In i se asociaz graful din figura 3.1.
I1 I2 I3 In-1 In Figura 3.1 Graful asociat structurii liniare Structura decizional de tipul if-then-else are graful asociat din figura 3.2.

expr S2 S1

Figura 3.2 Graful asociat structurii alternative Structura decizional multipl de tipul switch-case, are graful asociat prezentat n figura 3.3.
expr S1 S2 Sk Sn

Figura 3.3 Graful asociat structurii decizionale multiple 49

Structurile repetitive condiionate anterior for, while au graful asociat din figura 3.4 a), iar structura repetitiv condiionat posterior graful asociat prezentat n figura 3.4 b). Structurile repetitive sunt combinaii de structuri de tipul if-then-else i goto.
if

S if

a) for, while

b) dowhile

Figura 3.4 Graful asociat structurilor repetitive Exist trei tipuri de structuri de programe: liniar, arborescent i de tip reea. Structura liniar presupune c modulele A1, A2, ...An se apeleaz unele dup celelalte, secvenial (figura 3.5).

A1

A2

A3

An-1 An

Figura 3.5 Structur liniar de program Structura arborescent este aceea n care modulele sunt apelate relativ unele de altele (figura 3.6). Structura arborescent corespunde situaiei n care o problem se descompune n subprobleme care sunt n raporturi de subordonare fa de aceasta, iar ntre ele fie se identific raportul de subordonare, fie coexist.

Figura 3.6 Structur arborescent de program 50

n structura de tip reea problema referirii modulelor este oarecare (figura 3.7). Apar elemente de ciclicitate i structurii i se asociaz un graf orientat.

Figura 3.7 Structur de tip reea McCabe [MCCA76] a calculat complexitatea ciclomatic, sau numrul ciclomatic, indicator care are la baz graful asociat programului. Numrul ciclomatic reprezint complexitatea structurilor de decizie alternative i repetitive dintr-un program i se calculeaz utiliznd formula:
CV (G ) = e n + 2 p

unde e numrul de arce; n numrul de noduri; p numrul de componente conexe (pentru care se identific perechi de noduri distincte legate printr-un lan). Deoarece programele au o singur intrare i o singur ieire, ele au o singur component conex i deci p = 1, caz n care formula numrului ciclomatic este:
CV (G ) = e n + 2

Numrul ciclomatic se calculeaz i dup formula:

CV (G ) = D + 1

unde D reprezint numrul de blocuri de decizie din program. n cazul n care condiiile din blocurile de decizie sunt compuse, fiecare condiie se consider a fi un bloc de decizie separat. 51

Numrul ciclomatic este pus n legtur cu numrul minim de exemple de test, astfel nct numrul cilor independente executate s fie egal sau foarte aproape de valoarea complexitii ciclomatice. Obiectivul testrii este de a rula testele astfel nct numrul cilor independente executate s fie egal sau foarte aproape de valoarea complexitii ciclomatice. Pentru funcia de adugare a unui produs ntr-o list de produse, definit n aplicaia e-DSI, avnd textul surs:
public boolean AdaugaProdus(Produs p) { if(n<PMAX) { produse[n] = p; n++; return true; } return false; }

i structura arborescent asociat din figura 3.8, complexitatea ciclomatic este CV=1+1=2. Rezult un numr minim de dou cazuri de test pentru parcurgerea cilor independente.

n<PMAX produse[n]=p n++

return false

return true

Figura 3.8 Structura arborescent asociat funciei AdaugaProdus Cea mai important msur de complexitate la nivel de text surs este metrica Halstead. Halstead consider c elementele primare ale oricrui program sunt operatorii i operanzii [HALS77]. Operanzii sunt constante, variabile i referine. Operatorii sunt coduri de operaii, delimitatori, simboluri aritmetice, sisteme de punctuaie care acioneaz pe operanzi sau 52

cu operanzii. n categoria operatorilor intr i structurile de control fundamentale din limbajele de programare: for, while, do-while, if-then-else i switch. Se fac urmtoarele notaii pentru elementele obinute din analiza textului surs a programului: n1 numrul de operatori distinci; n2 numrul de operanzi distinci; N1 numrul total de apariii ale operatorilor; N2 numrul total de apariii ale operanzilor. Se definesc urmtoarele msuri: vocabularul programului (n) care constituie o msur a repertoriului de elemente pe care le utilizeaz programatorul pentru a codifica programele: n = n1+n2 lungimea observat a programului (N) este o msur a dimensiunii programului: N = N1 + N 2 Halstead a construit un estimator al lungimii observate N, notat cu , pe baza elementelor vocabularului n. Astfel, lungimea estimat, este dat de relaia: = n1 log2 n1 + n2 log2 n2 Pe baza lungimii estimate a programului se calculeaz complexitatea relativ:

C=

n 1log 2 n 1 + n 2 log 2 n 2 = N N

53

Pentru funcia prezentat anterior, AdaugaProdus(), n scopul calculului complexitii Halstead se identific: Operatori
public boolean () {} [] return ++ < = if ;

n1=11

Apariii 1 1 2 2 1 2 1 1 1 1 4 N1=17

Operanzi
AdaugaProdus Produs p n PMAX produse true false

Apariii 1 1 2 2 1 1 1 1

n2=8

N2=10

Pe baza msurtorilor efectuate se determin lungimea estimat: = 11log 2 11 + 8 log 2 8 = 62.05 i lungimea observat:

N = N1 + N2 = 17 + 10 = 27

de unde rezult complexitatea relativ:

C=

62.05 = = 2.29 N 27

Msurile de complexitate de comportament se bazeaz pe caracteristicile de comportament ale aplicaiei: viteza de rulare, viteza de tranzacionare, dimensiunea memoriei ocupate. Sunt supuse msurrii programe aflate exclusiv n faza de execuie. n timpul testrii se contorizeaz pentru fiecare exemplu de test n parte: numrul de rulri; se nregistreaz fiecare rulare cu datele de test alese utiliznd diverse strategii de testare; n cazul n care nu exist un sistem integrat de management al testelor, rulrile se nregistreaz pentru fiecare tip de test n parte i se centralizeaz; numrul de erori de execuie depistate; n momentul apariiei unei erori de execuie, aceasta este nregistrat; de cele mai multe 54

ori erorile de execuie conduc la ntreruperea execuiei programului; numrul de erori n rezultate; erorile n rezultate se determin prin compararea ieirilor ateptate cu ieirile efective; pentru determinarea erorilor de acest tip se utilizeaz instrumente de asistare a procesului de testare; specificarea rezultatului ateptat se face de ctre tester; numrul de erori n datele de intrare; aceste erori conduc fie la rezultate nedorite fie la ncheierea execuiei programului; este necesar existena de rutine de validare n scopul evitrii acestor situaii; numrul de modificri care se efectueaz n program; exist instrumente specializate care nregistreaz automat toate versiunile fiierelor surs pentru fiecare membru al echipei de dezvoltare; n lipsa acestor instrumente, nregistrarea modificrilor este destul de dificil. Pentru aplicaia e-DSI s-au efectuat o serie de msurtori, prezentate n capitolele 9 i 10. Complexitatea aplicaiilor distribuite este determinat lund n considerare aspecte legate de caracterul distribuit al acestora: arhitectura aplicaiei, tehnologia utilizat i protocoalele de transfer. n cazul aplicaiilor Internet, pe lng msurarea complexitii utiliznd metodele cunoscute pentru aplicaiile clasice, apar noi mrimi care iau n calcul caracteristicile specifice acestor tip de aplicaii, cum ar fi utilizarea de scripturi client i server; utilizarea de controale ActiveX i applet-uri Java; accesul la baze de date. Toate acestea conduc la o complexitate mai ridicat a aplicaiilor Internet i un proces de testare mai costisitor.

3.3 Dimensiunea aplicaiei

Principalii indicatori de msurare a dimensiunii unei aplicaii sunt numrul de linii de cod surs (LOC) i puncte funcionale (PF). LOC reprezint numrul de linii surs ale unui program, fr includerea comentariilor sau a elementelor de documentare. n mod frecvent se utilizeaz sub forma KLOC (mii de linii surs). 55

Dac pentru fiecare proiect n parte se nregistreaz: costul efectiv; numrul de linii surs; numrul de pagini de documentaie; numrul de persoane implicate; numrul de erori descoperite, cu ajutorul numrului de linii surs se calculeaz urmtorii indicatori: KLOC Productivitate = Persoane
Calitate = 1 Defecte KLOC

Cost =

Costul efectiv KLOC

Pagini documentatie KLOC Msurarea pe baza liniilor de cod surs LOC (KLOC) este dependent de limbajul de programare. n [PRES00] este prezentat echivalena dintre numrul de linii surs pentru o serie de limbaje de programare, tabelul 3.3. Documentatie =

Tabelul 3.3 Echivalena LOC pentru diverse limbaje de programare Limbajul de programare Linii surs Limbaj de asamblare 320 C 128 COBOL 106 Pascal 90 C++ 64 Visual Basic 32 SQL 12 Dac se utilizeaz k limbaje de programare L1, L2, , Lk, i numrul de linii surs echivalente este LSE1, LSE2, , LSEk, pentru exprimarea omogen a numrului de linii surs, se alege limbajul de programare cel mai des folosit sau unul din limbajele n care au fost scrise programele care are numrul de linii surs echivalente (LSE) i se calculeaz dimensiunea 56

echivalent (DE) utiliznd formula:

DE =
i =1

LSE LS i LSEi

unde LSi reprezint numrul de linii surs scrise utiliznd limbajul Li. Punctele funcionale msoar indirect software-ul i procesul prin care acesta este dezvoltat. Punctele funcionale se axeaz asupra funcionalitii sau utilitii programului. Punctele funcionale sunt derivate utiliznd o relaie empiric dintre domeniul informaional al programului i evaluarea complexitii software. Punctele funcionale sunt independente de limbajul de programare n care s-a realizat aplicaia software. A fost determinat un numr de cinci caracteristici ale domeniul informaional. Valorile domeniului informaional sunt definite astfel: numrul de intrri de la utilizator; numrul de ieiri ctre utilizator; numrul de cereri ale utilizatorului; numrul de fiiere; numrul de interfee externe. Dup ce aceste date au fost culese, o anumit valoare a complexitii este asociat cu fiecare factor n parte. Pe baza unor criterii specifice, se determin dac sunt simple, medii sau complexe. Tabelul 3.4 Utilizarea punctelor funcionale Pondere Parametru de msurare Contor Simplu Mediu Complex Numrul de intrri de la utilizator 3 4 6 Numrul de ieiri ctre utilizator 4 5 7 Numrul de interogri utilizator 3 4 6 Numrul de fiiere 7 10 15 Numrul de interfee externe 5 7 10 Total T otal

NNPF

Totalul obinut (NNPF) se numete numr neajustat de puncte funcionale i el indic mrimea programului. Se calculeaz gradul total de influen (GTI) folosind 14 caracteristici generale de ordin tehnic cum ar fi: comunicaia de date, performanele, reutilizabilitatea, uurina de instalare etc. 57

Mrimea programului sub form de puncte funcionale se obine prin ajustare pe baza relaiei [DIAC99], [APRE00]:
DFP = NNPF (0.65 + 0.01 GTI )

n mod asemntor se calculeaz indicatorii Productivitate, Calitate, Cost, i Documentaie prezentai anterior, prin nlocuirea mrimii programului exprimat in KLOC cu mrimea exprimat n FP.

3.4 Gradul de omogenitate a echipei de realizare software

Producia de software este o activitate de echip. Personalul este nzestrat cu caliti individuale, dar un rol esenial l are capacitatea fiecrui specialist certificat de a se integra n echip, de a produce componente care prin asamblare s conduc la obinerea produsului finit ca ntreg. Un rol esenial l are comunicarea n cadrul echipei precum i cunoaterea de ctre coordonatorul acesteia a potenialului fiecrui membru. n acest fel are loc distribuirea de sarcini care corespunde acestui potenial, ceea ce conduce la ncadrarea n grafice a consumurilor de resurse i la asigurarea parcurgerii etapelor n termenele planificate. Personalul specializat n testarea de software orientat obiect trebuie s cunoasc tehnicile de analiz, proiectare i programare orientate obiect, s neleag problema pe care programul o rezolv i s aib capacitatea de a distinge diferenele care apar ntre rezultatele oferite de program i cele obinute prin specificaii sau rezultate proprii. Testerul elaboreaz totalitatea rapoartelor privind rezultatele testrilor cu indicarea tipurilor de erori identificate. De asemenea, testerul colecteaz date despre erori ale programului la utilizatori, reproduce condiiile de obinere a lor i confirm n rapoarte noi tipuri de erori neidentificate n procesul de testare curent. Testerul clasific erorile, le stabilete frecvenele i cuantific efectele pe care acestea le genereaz la utilizatori. Rapoartele finale sunt cele care direcioneaz dezvoltarea de versiuni beta de lucru. Variantele beta sunt specifice perioadei de colectare de date privind comportamentul software direct de la utilizatori. Aplicaiile informatice complexe sunt testate n cadrul echipei de testeri. Organizarea echipei de testare vizeaz specializare pe tipuri de aplicaii, iar n cadrul tipurilor de aplicaii pe tipuri de funcii de prelucrare. 58

Modalitatea de selecie a personalului care s lucreze n cadrul unui proiect are o importan deosebit asupra desfurrii viitoare a proiectului. Neomogenitatea echipei de dezvoltare are repercusiuni negative asupra procesului de testare. Din cauza neomogenitii membrilor echipei apar incompatibiliti ntre secvenele realizate, se utilizeaz standarde diferite de scriere a codului, se produc ntrzieri i tensiuni n cadrul echipei, ceea ce conduce la costuri ridicate pentru testare.

3.5 Tehnici de dezvoltare a produsului program

Tehnicile de dezvoltare utilizate n realizarea produsului au n vedere etapele de analiz i proiectare a acestuia. Exist mai multe metode de analiz i proiectare, clasificate dup modul n care este realizat proiectul aplicaiei. Astfel, exist metode care au la baz: structura funcional; n cadrul acestor metode sistemul este mprit n subsisteme pe baza funcionalitii componentelor; structura datelor; proiectarea sistemului se bazeaz pe datele care sunt prelucrate; fluxul datelor; n proiectare se pornete de la fluxurile datelor din cadrul sistemului. Metodele care au la baz structura funcional a produsului sunt: metoda Top-Down; are la baz principiul modularitii i presupune descompunerea sistemului de sus n jos pn la obinerea de module elementare; metoda Bottom-Up; la baza metodei st principiul agregrii i presupune identificarea de jos n sus a componentelor sistemului; metoda HIPO; metoda se bazeaz pe descrierea intrrilor, prelucrrilor i ieirilor ntr-o manier ierarhic; sunt construite diagramele de coninut H i diagramele IPO, pentru intrri/prelucrri/ieiri; metoda de analiz i proiectare structural SADT; la baza metodei st descompunerea descendent pe baze funcionale a sistemului; metoda presupune elaborarea a dou modele: modelul activitilor i modelul datelor. Metodele care pornesc de la structura datelor sunt: metoda de realizare a sistemelor LCS i metoda de realizare a programelor LCP; au la baz structurarea sistemului n funcie de datele de ieire; metoda Jackson; sistemul este structurat pornind de la analiza datelor problemei; se creeaz o structur ierarhic a sistemului. 59

Metodele care au n vedere fluxul datelor sunt: metoda lui DeMarco; este o metod de analiz structurat; metoda lui Yourdon i Constantine; se obine diagrama de flux a datelor (DFD) i pe baza acesteia se realizeaz o descompunere funcional a sistemului; metoda lui Myers; se mai numete i proiectarea compozit; obiectivul metodei este acela de a minimiza relaiile din interiorul modulelor i de a maximiza relaiile dintre module. Metodele de analiz i proiectare orientate obiect pun accentul n primul rnd pe reutilizare. Principalele metode de analiz i proiectare orientate obiect sunt OOA (Object Oriented Analysis), OOD (Object Oriented Design), OOSE (Object Oriented Software Engineering), OMT (Object Modeling Technique) i RUP (Rational Unified Process). OOA este o metod de analiz orientat obiect dezvoltat de Shlaer & Mellor care se bazeaz pe o multitudine de reguli, analistul avnd destul de puine posibiliti de reprezentare a problemei sau a lumii reale. Analistul partiioneaz sistemul n domenii, construindu-se diagrame ale domeniile. Fiecare domeniu este analizat separat, acestea fiind interconectate n timpul proiectrii i implementrii. Modelele cu care lucreaz metoda sunt: modelul informaional; sunt descrise entitile conceptuale i relaiile dintre acestea; modelele strilor; conine ciclurile de via a obiectelor i relaiile dintre obiecte; modelul de comunicaie a obiectelor; este redat comunicaia asincron dintre obiectele din sistem; modelul de acces al obiectelor; descrie comunicaia sincron dintre obiectele sistemului. Metoda de analiz orientat obiect ia n considerare i posibilitatea c proiectarea orientat obiect nu poate fi aplicat pentru problem i las la latitudinea analistului sau proiectantului aceast alegere. OOA lucreaz cu diagrama claselor, diagrama de structur a claselor, diagrama dependenelor i diagrama motenirii [SHLA92]. OOD a fost descris pentru prima dat de ctre G. Booch n [BOOC91]. Metoda subliniaz rolul esenial jucat n proiectarea orientatobiect de aspectul iterativ al dezvoltrii i importana creativitii dezvoltatorului. Metoda este mai mult dect un set de reguli euristice i sfaturi referitoare la procesul realizrii unei aplicaii. Dei nu sunt prezentate reguli stricte i succesiune riguroas n timp, ordinea operaiilor care trebuie

60

efectuate n OOD este urmtoarea: identificarea claselor i obiectelor la un anumit nivel de abstractizare; identificarea semanticii claselor i obiectelor; identificarea relaiilor ntre clase i obiecte; implementarea claselor i obiectelor. Metoda se concentreaz asupra fazei de proiectare, pentru care ofer un set bogat de concepte i notaii. Prezentarea modelului de dezvoltare din diferite perspective permite ilustrarea clar a unor aspecte diferite ale modelului. OOD separ structura logic de cea fizic. Vederea logic conine structura claselor, n timp ce vederea fizic se refer la structura modulelor i a proceselor. Diagramele detaliate pentru module i procese constituie una din caracteristicile OOD. Pe lng diagramele statice, Booch utilizeaz i dou diagrame dinamice. Prima este o diagram de tranziie a strilor iar a doua, o diagram de timp care descrie succesiunea evenimentelor ntre obiecte. OMT acoper fazele de analiz, proiectare i implementare. Spre deosebire de OOD, OMT se concentreaz asupra analizei. Metoda, conceput de Rumbaugh, este descris n [MIHA98] i const din patru etape: analiza; const n definirea domeniului aplicaiei fr a lua n considerare aspecte legate de implementare; rezultatele etapei sunt modelele obiectual, dinamic i funcional; proiectarea sistemului; modelele obinute n faza de analiz sunt rafinate, extinse i detaliate astfel nct pe baza lor s se implementeze; ca rezultat al fazei de proiectare se obine arhitectura sistemului; proiectarea orientat obiect; n aceast etap sunt proiectai algoritmii, asocierile i se creeaz ierarhiile de clase; rezultatele acestei etape sunt cele trei modele detaliate; implementarea; pe baza modelelor detaliate este scris codul aplicaiei utiliznd un limbaj de programare orientat obiect. Iniial sunt dezvoltate trei modele ale sistemului, care ulterior sunt rafinate n toate etapele ciclului de via. Aceste modele sunt: modelul obiect (static) care descrie structura static a sistemului lund n considerare clasele i relaiile dintre ele; modelul dinamic, construit pentru a surprinde aspectele temporale ale modelului obiect;

61

modelul funcional care descrie n principiu, n termenii operaiilor dintre obiecte, modul n care plecnd de la informaiile iniiale sunt obinute informaiile finale. OOSE (Ivar Jacobson) este o metodologie orientat obiect bazat pe idei noi privind procesul de realizare a software-ului. Etapele acestei metodologii sunt [JACO96]: analiza; sunt identificate clasele sistemului; din etapa de analiz rezult modelul cerinelor i modelul de analiz; construcia; etapa const din proiectare i implementare; clasele obinute n etapa de analiz sunt rafinate; sistemul este adaptat mediului real n care acesta opereaz, fiind luate n considerare limbajul de programare, bazele de date cu care acesta lucreaz; rezultatele etapei sunt modelul de proiectare i modelul de implementare; testarea; fiecare clas sau grup de clase este testat n parte att din punct de vedere funcional ct i structural; instane ale claselor sunt integrate continuu pe parcursul realizrii sistemului i testate; dup integrarea ntregului sistem, acesta este testat; pentru testarea de integrare i testarea de sistem sunt utilizate cazurile de utilizare; mentenana; dup acceptarea sistemului de ctre beneficiar, acesta intr n exploatare curent; n msura n care apar erori pe parcursul utilizrii, acestea sunt corectate. Metoda utilizeaz cinci modele corespunztoare etapelor de dezvoltare: modelul cerinelor, de analiz, de proiectare, de implementare i de testare. Fiecare model ia n considerare o anumit parte sau anumite aspecte ale sistemului care se realizeaz. Un concept nou al metodei este cel al cazurilor de utilizare (Use Cases), concept care face parte din modelul cerinelor, acesta fcnd posibil legtura dintre cerine, dezvoltare, testare i acceptare de ctre utilizatorul final [MIHA98], [BODE01]. are la baz metodele OOD (Booch), OMT Metoda RUP (Rumbaugh) i OOSE (Jacobson). Pe lng aceste metode, au mai fost folosite i FUSION (Coleman), OOA (Shlaer & Mellor) i alte metode. Metoda unificat se bazeaz pe cazurile de utilizare, este centrat pe arhitectur i este interactiv i incremental. UML st la baza reprezentrilor grafice utilizate n aceast metod. Principiile reunificrii [RUMB96], sunt: simplitatea metoda trebuie s foloseasc un numr redus de concepte; 62

aplicabilitatea metoda trebuie s poat fi aplicabil la construirea unui numr ct mai mare de sisteme diferite; utilitatea metoda trebuie s se concentreze asupra acelor elemente care sunt semnificative pentru un sistem practic i pentru tehnicile de ingineria programrii; atenia special acordat problemelor frecvent ntlnite problemele frecvent ntlnite trebuie s fie simplu de modelat iar problemele limit pot s necesite o complexitate oarecare, msurat prin frecvena de utilizare; auto-consistena acelai concept i simbol trebuie s fie aplicat n aceeai manier n cadrul metodei; ortogonalitatea conceptele independente trebuie s fie modelate independent; structurarea pe niveluri conceptele avansate trebuie tratate ca extensii ale conceptelor de baz ale metodei; stabilitatea s adopte concepte i simboluri care sunt larg cunoscute i folosite; posibilitatea de tiprire diagramele folosite trebuie s poat fi uor desenate cu mna sau cu editoarele grafice; extensibilitatea att utilizatorii ct i constructorii trebuie s aib un anume grad de libertate care s le permit s extind i s adapteze metoda. S-au dezvoltat o serie de metodologii de analiz i proiectare pentru proiecte de dimensiuni reduse, precum [DIAS00]: ASD; se bazeaz pe teoria sistemelor complexe adaptive, utiliznd trei concepte importante pentru a descrie lumea extern: ageni, medii i rezultate; XP; la baza metodei st satisfacia clientului i lucrul n echip; metoda se utilizeaz pentru proiecte la care lucreaz ntre 2 i 10 oameni; n echip sunt inclui i managerii i clienii; o cerin important este testabilitatea i se are n vedere posibilitatea automatizrii testelor de modul i funcionale; obiectivul principal este livrarea de software de calitate la timp; n privina testrii se scriu mai nti cazurile de test i dup aceea programele care urmeaz a fi testate; SCRUM; obiectivul metodei este de a furniza software de calitate ntr-o serie de trei pn la opt intervale de timp care dureaz cel mult o lun; etapele metodei, stabilirea cerinelor, analiza, proiectarea, evoluia i livrarea sunt grupate ntr-un 63

stagiu; aceste stagii de deruleaz pn la finalizarea produsului software; Crystal Clear; se adreseaz proiectelor la care lucreaz echipe ntre 4 i 6 oameni; se bazeaz pe elementele de succes ale proiectelor precedente, iar accentul este pus pe comunicaia continu n cadrul echipei. Toate aceste metodologii pun un accent important pe calitate i pe testarea rezultatelor obinute. Utilizarea instrumentelor CASE n analiza i proiectarea aplicaiilor software utiliznd anumite tehnici i metode de dezvoltare conduce la: creterea productivitii n activitatea de analiz i proiectare; avnd la dispoziie o multitudine de posibiliti de descriere grafic a modelelor i faciliti de verificare a consistenei acestora, efortul necesar analizei i proiectrii se reduce; obinerea de documente unitare n fiecare etap de dezvoltare; dup fiecare etap sunt generate automat documente specifice pentru descrierea modelelor elaborate i a relaiilor dintre acestea; posibilitatea generrii de cod surs pentru modelele realizate; modelele detaliate obinute permit generarea de cod n diverse limbaje de programare (C++, Java, VB); sunt create clasele i prototipurile metodelor, urmnd ca algoritmii i funcionalitatea acestora s fie completate de ctre programatori. La ora actual exist o multitudine de instrumente CASE care suport att metode de analiz i proiectare structurate, ct i metode orientate obiect. Tehnicile de analiz i proiectare alese influeneaz procesul de testare prin specificul acestora, prin modalitatea de abordare a problemei de rezolvat, prin documentele i diagramele utilizate i prin modul n care este vzut testarea.

3.6 Stadiul de certificare a firmei

Certificarea productorului este un proces care stabilete gradul de concordan dintre capacitatea real de a realiza calitate i cerinele impuse prin standarde. Certificarea unui productor asigur c acesta dezvolt produse de calitate ridicat. Certificarea calitii software presupune, conform [VOAS98]: certificarea procesului de dezvoltare software; certificarea produselor software realizate; 64

 certificarea personalului. n figura 3.9 este prezentat triunghiul certificrii calitii software [IVAN00].

Utilizatori

Produs

Personal Proces Figura 3.9 Diagrama certificrii calitii software

Certificarea impune o serie de restricii n parcurgerea etapelor din ciclul de via. Astfel, fiecare etap trebuie documentat corespunztor, transferurile de documente dintre membrii echipei trebuie nregistrate, dispoziiile managerului sunt de asemenea memorate fie n format electronic fie pe hrtie. Casele de software sunt uniti de dimensiuni variate care au ca obiect de activitate producia de software. Certificarea caselor de software este un proces complex, iar cei care beneficiaz de rezultatele pozitive dobndesc capacitatea de a ptrunde pe piaa de software, certificatul reprezentnd o garanie a seriozitii cu care sunt respectate standardele i se asigur un management care concur la ncadrarea n termene, la costuri corelate cu complexitatea produsului care se va realiza. Exist o serie de standarde referitoare la calitate, cunoscute sub denumirea generic ISO 9000. n familia de standarde ISO 9000 sunt incluse urmtoarele standarde: ISO 9001, ISO 9002, ISO 9003, ISO 9004; ISO 10001 - ISO 10020; ISO 8402. 65

Standardele din familia ISO 9000 sunt utilizate: n scopul asigurrii interne a calitii,; n situaii contractuale; pentru obinerea unei aprobri sau n scopul nregistrrii de ctre o a doua parte; n scopul certificrii sau nregistrrii de ctre o ter parte. n figura 3.10 este prezentat familia de standarde ISO 9000.

ISO 9000

Asigurarea intern a calitii

Asigurarea extern a caliti

ISO 9004

ISO 9001

ISO 9002

ISO 9003

Figura 3.10 Familia de standarde ISO 9000 Pentru asigurarea extern a calitii pot fi utilizate urmtoarele standarde, n funcie de activitatea desfurat: ISO 9001 Sistemele calitii model pentru asigurarea calitii n proiectare, dezvoltare, producie, instalare i servicii asociate; ISO 9002 Sistemele calitii model pentru asigurarea calitii n producie, instalare i servicii asociate; ISO 9003 Sistemele calitii model pentru asigurarea calitii n inspecie i ncercrile finale.

66

Standardul ISO 9004 pentru asigurarea intern a calitii se refer la activiti precum: asigurarea calitii n marketing si proiectare; asigurarea calitii n aprovizionare; asigurarea calitii proceselor. n [MIHA02] sunt prezentate avantajele certificrii ISO 9001 pentru companiile software: 1. Productivitate crescut: eficien sporit a operaiilor interne; definire mai clar a responsabilitilor i atribuiilor; reducerea timpului de localizare a erorilor; creterea numrului de activiti executate corespunztor de la nceputul procesului de dezvoltare software. 2. Reducerea costurilor: reducerea numrului de proceduri conduce la eliminarea practicilor de lucru redundante i a aprobrilor nenecesare; reducerea numrului de auditri, a costurilor i domeniului de aplicare pentru auditri. 3. Marketing mai eficient: acces mai larg pe pieele externe care impun ISO 9001; anse sporite pentru ctigarea contractelor guvernamentale; atractivitate mai mare pentru clieni noi; avantaj competitiv fa de firmele care nu sunt certificate ISO 9001. 4. Proiectare mai bun: practici de reutilizare mbuntite; mai puine erori recursive; autodisciplin sporit n proiectare; ncredere mai mare a clientului n companie. La ora actual sunt utilizate standardele din familia ISO 9000:2000 [PRAX02]. Standardele ISO 9001, ISO 9002 i ISO 9003 sunt acum grupate sub un singur standard, ISO 9001:2000. Standardele din familia ISO 9000:2000 pun la baza principiilor orientarea ctre client. Principiile acestei familii de standarde n privina managementului calitii sunt: concentrarea asupra necesitilor clienilor; rolul important al conducerii; implicarea angajailor; utilizarea unei abordri pe proces i sistemice; ncurajarea mbuntirii continue; 67

 luarea deciziilor s fie fundamentat pe fapte; colaborarea cu furnizorii. Trecerea la certificarea ISO 9000:2000 de la certificrile pentru variantele anterioare ale standardelor este necesar. Certificarea personalului n domeniul realizrii de aplicaii software presupune parcurgerea unor proceduri care evideniaz: cunoaterea unor tehnici i metode; sunt vizate acele tehnici i metode care se utilizeaz la dezvoltarea proiectelor software n cadrul firmei; abiliti pentru utilizarea de medii de programare; existena disponibilitii pentru lucrul n echip i pentru respectarea de cerine. Software Engineering Institute a elaborat modelul CMM (Capability Maturity Model) [SOME01], [PETE00], [PRES00],[VLIE00] de clasificare a stadiului n care se gsete procesul de realizare software ntr-o companie productoare de aplicaii informatice. CMM/SEI are cinci niveluri: iniial; la acest nivel organizaia nu are proceduri de management sau planuri pentru proiecte; repetabil; organizaia are un management formal i proceduri de asigurare a calitii i de control a configuraiei; definit; la acest nivel, organizaia are un proces definit i sunt puse bazele unui proces de mbuntire cantitativ continu a procesului; condus; organizaia are definit un proces i un program formal de colectare cantitativ a datelor; optimizat; la acest ultim nivel organizaia are un program clar de mbuntire continu a proceselor. Ierarhizarea pe baza CMM a suferit diferite modificri n timp. Pentru cele cinci niveluri au fost introduse procese cheie care trebuie atinse. n lume, marea majoritate a firmelor productoare de software se gsesc pe nivelurile inferioare ale modelului. S-a constat c organizaiile pentru care maturitatea proceselor este evaluat ca fiind de nivelul doi sau trei sunt compatibile cu standardul ISO 9000. Personalului implicat n procesul de elaborare a produselor software este evaluat pe baza experienei practice, a specializrilor profesionale i a diplomelor obinute. Prin obinerea de diplome de studii, precum diplom de licen cu o anumit specialitate, diplom de masterat sau alte diplome care atest urmarea unor cursuri de specialitate n instituii de nvmnt superior (cum ar fi cursuri postuniversitare, doctorat), se presupune parcurgerea anumitor 68

etape obligatorii de ctre persoanele care le dein i, prin acestea, se confirm pregtirea persoanelor n domeniul respectiv. n acest caz, instituiile de nvmnt superior garanteaz pregtirea persoanelor care au obinut aceste rezultate. O alt modalitate de certificare a personalului este prin promovarea unor examene de certificare profesional. Acest tip de certificare este voluntar i scump. Pentru obinerea certificrii trebuie urmate o serie de cursuri de specialitate, cursuri care cost destul de mult, ns prin certificare se conteaz pe obinerea unui venit mai mare. Experiena profesional a personalului este o alt modalitate pentru evaluarea acestuia. Experiena se ctig n timp, printr-o activitate ndelungat ntr-un domeniu specific. Experiena personalului este important i, de aceea, trebuie luat n considerare n certificarea acestuia. Pregtirea corespunztoare a personalului nu garanteaz automat c firma produce software de calitate. Pentru a obine software de calitate firma trebuie s aib personalul bine pregtit i procesul de dezvoltare software s se realizeze n conformitate cu standarde de calitate existente.

3.7 Numrul i diversitatea utilizatorilor

Numrul de utilizatori influeneaz ntr-o msur diferit testarea software, n funcie i de importana produsului software. Astfel, dac aplicaia software este realizat pentru un numr foarte mare de utilizatori, pentru testarea acesteia se acord o importan mai mare dect n cazul n care aplicaia ar fi pentru un numr restrns de utilizatori. Procesul de informatizare a societii modific concepia n dezvoltarea de software. Se trece de la sisteme de programe pentru o ntreprindere la sisteme generalizate. Aplicaia e-DSI se construiete pentru majoritatea persoanelor fizice. La nivelul rii, numrul total de utilizatori posibili ai aplicaiei e-DSI este dat de relaia:

N = nj
j =1

41

unde n1, n2, , n41 reprezint numrul de persoane fizice care au calculatoare i acces la Internet din fiecare jude. Dintre aceti utilizatori, dac utilizeaz deja aplicaia, rezult c exist n = N poteniali utilizatori ai aplicaiei. Dac utilizatori (n procente) cumpr aplicaia, numrul de utilizatori poteniali devine: 69

n = N (1 + )

Odat cu vnzarea unei reviste de calculatoare pe o dischet sau CD se gsesc programe de contabilitate, jocuri, programe de gestiune pentru crile din bibliotec, bugetul familiei, agenda electronic, procesoare de texte, software pentru Internet i pot electronic. Cumprtorul dischetei sau CD-ului instaleaz i ncepe s utilizeze programele pentru rezolvarea problemelor sale. Numrul de utilizatori este foarte mare i acetia trebuie s fie satisfcui de cum lucreaz programele i de rezultatele pe care le obin. Programele trebuie s fie nzestrate cu interfee prietenoase, s conin un sistem de informaii care asist procesul de utilizare. Interfaa aplicaiei e-DSI este realizat n conformitate cu cerinele diverilor utilizatori, de vrste i specializri diferite. Cel care a produs software are posibilitatea de a solicita un dialog cu utilizatorul pentru: nregistrare; specificarea de faciliti noi de prelucrare; transmiterea de versiuni mbuntite; recepionarea anomaliilor de prelucrare cu specificarea condiiilor la utilizator, care le-au generat; stabilirea canalelor de comunicaie destinate efecturii de corecii on-line n iniializri i selecii de opiuni. Rezult c programele pentru muli utilizatori sunt produse finite, care ndeplinesc cerine de calitate care le permit s funcioneze independent de cei care le-au produs. ntr-un cuvnt, programul de pe dischet sau CD trebuie s fie bun, adic s nu creeze probleme utilizatorilor si, instalarea s fie uoar, printr-o singur comand. Configurarea trebuie s fie automat sau s necesite un numr ct mai redus de informaii date de utilizator. La introducerea de date eronate, s existe modaliti simple, cunoscute de la alte programe, pentru efectuarea coreciilor. Pentru aceasta, utilizatorul trebuie s primeasc mesaje adecvate. nceperea prelucrrii este posibil dac i numai dac au fost furnizate date complete i corecte. Programul este bun dac permite utilizatorului s selecteze variante de structuri ale rezultatelor pe care le dorete. Programul este bun n cazul n care indiferent de ceea ce s-a introdus se obine, fie un rezultat, fie un mesaj. Niciodat nu are loc transmiterea automat a controlului ctre sistemul de operare (ieirea din program) sau se blocheaz calculatorul.

70

Programul este bun, dac i numai dac, las utilizatorului posibilitatea de a decide n puncte cheie: volumul de date introduse, selectarea prelucrrilor efectuate, selectarea opiunilor de obinere a rezultatelor, continuarea sau ntreruperea execuiei programului. Programul este bun, n general dac efectueaz exact prelucrrile pentru care a fost construit. La vnzarea dischetei sau a CD-ului exist un rezumat care specific toate tipurile de prelucrri pe care le efectueaz programul livrat. Numrul i diversitatea utilizatorilor constituie un factor foarte important pentru testare. n cazul unui numr mare de utilizatori, exist un dialog continuu ntre acetia i echipa care realizeaz produsul. Dac sunt luate n considerare opiniile acestora i sunt centralizate i grupate, procesul de realizare software i cel de testare se vor desfura n alte condiii. Pn la obinerea unui program care s fie utilizat fr asistare de ctre productor se parcurge un drum lung, n care testrile sunt necesare i mai ales ocup un volum de resurse foarte important.

3.8 Factori secundari de influen

Existena de produse similare pe pia are efecte importante asupra costului testrii software. n msura n care exist produse similare pe pia, se va pune accentul n primul rnd pe creterea calitii produsului software. Existena unei concurene puternice pe piaa anumitor produse software va conduce la realizarea de produse software de calitate ridicat, care au mai multe faciliti incluse, vitez de prelucrare crescut i mbuntiri ale interfeei grafice. Testarea evideniaz fie superioritatea, fie faptul c produsele sunt la fel. De asemenea, prin testare se identific diferenele. Testarea se face pe aceleai exemple de test, se caut s se lucreze la utilizatori care folosesc alte aplicaii pentru a putea compara. Gradul de noutate ncorporat n software i n hardware se reflect asupra efortului de testare. Utilizarea de tehnic de calcul i software moderne, conduce la creterea productivitii n activitatea de dezvoltare software. Este imposibil s se procedeze la testarea complet a unui produs program realizat pe o arhitectur de sistem de calcul n condiiile n care echipa de testare nu deine cel puin aceleai tipologii de resurse. Mai mult, problematica analizei automate a comportamentului unui produs software necesit existena unor instrumente specializate.

71

Testarea asistat se caracterizeaz prin rigurozitate. Odat achiziionat un instrument, echipa de testare este obligat s utilizeze tehnica de testare pe baza creia a fost implementat instrumentul. n procesul de testare este necesar ca aplicaia software s fie testat n mediul n care aceasta va rula. De aceea, n cazul n care nu exist, se vor achiziiona echipamente hardware specifice. Echipamentele fie vor fi cumprate, fie se vor nchiria pe perioada derulrii testelor. Gradul de noutate a echipamentelor i a produselor software se reflect i n efortul necesar pentru ca echipa s nvee s le utilizeze n condiii optime. Specificul aplicaiei informatice are un impact major asupra politicii de testare a aplicaiei. n anumite domenii, cum ar fi centrale nucleare, controlul traficului aeronavelor, trenurilor, metrourilor, apariia i manifestarea erorilor n aplicaiile software care le controleaz, poate conduce la pierderea de viei omeneti, precum i la pierderi materiale i financiare. Pentru aceste tip de aplicaii, testarea ocup un rol foarte important i este mult mai riguroas. O categorie intermediar de aplicaii o constituie cele n care apariia unei probleme n rulare s conduc la pierderi materiale i financiare, fr riscul pierderii de viei omeneti. n general aceste aplicaii sunt realizate pentru activiti economice ct i pentru sisteme de control a unor dispozitive n timp real. La majoritatea aplicaiilor software (editoare de texte, navigatoare Internet, aplicaii de prelucrri grafice) existena unor erori i manifestarea acestora nu conduce la pierderi majore pentru utilizator. O alt clasificare n funcie de domeniul pentru care sunt realizate aplicaiile le mparte n: aplicaii economice; astfel de aplicaii sunt destinate activitilor economice cum ar fi evidena contabil, gestiunea stocurilor, evidena personalului, salarizare; aplicaii de sistem; aceste aplicaii au acces la resursele hardware i la componentele de nivel sczut ale sistemului de operare i realizeaz diverse funcii precum interfaa cu hardware; aplicaii inginereti; aplicaii proiectate n scopul asistrii n domenii specifice precum proiectare, chimie, arhitectur. Dup numrul de utilizatori: aplicaii monoutilizator; presupun existena unui singur utilizator la un moment dat n timpul rulrii aplicaiei; aplicaii multiutilizator; permit ca aplicaia s fie folosit de mai muli utilizatori n acelai timp. 72

Dup numrul de calculatoare pe care ruleaz, exist: aplicaii nedistribuite, care funcioneaz i acceseaz resurse pe o singur main; aplicaii distribuite; sunt compuse din mai multe componente care se execut pe maini diferite; acest mod de lucru este transparent pentru utilizatori. Aceste tipuri de aplicaii se pot combina n diverse moduri, influennd n mod diferit procesul de testare. Omogenitatea aplicaiei este dat de numrul de limbaje de programare utilizate i de generaiile de software. n cazul n care sunt folosite mai multe limbaje de programare pentru dezvoltarea unei aplicaiei, o parte din testele care se aplic la nivelul codului surs trebuie realizate specific fiecrui limbaj de programare utilizat. Situaii deosebite apar i n testarea de integrare, atunci cnd modulele scrise n limbaje diferite sunt integrate i trebuie verificate interaciunile dintre acestea. n aplicaia e-DSI se utilizeaz preponderent limbajul Java, ns n cadrul programelor sunt integrate secvene de cod HTML precum i comenzi SQL pentru manipularea datelor din bazele de date. Reutilizarea software este un factor foarte important care influeneaz testarea software. n cazul reutilizrii de componente software care a fost deja testate, efortul de testare a noii aplicaii se reduce considerabil. Trebuie testat doar software-ul obinut prin reutilizare, ca un tot integrat, fr a mai testa separat componentele software reutilizate. n cazul aplicaiei e-DSI, prin reutilizarea de secvene de cod din mediul integrat de dezvoltare, o serie de activiti legate de probleme care nu au legtur cu logica aplicaiei au fost simplificate, iar activitatea de testare se concentreaz mai puin asupra acestor secvene i componente reutilizate. Modul de structurare a aplicaiei influeneaz de asemenea testarea software. Astfel, dac aplicaia este de tip monolit, etapele de testare sunt mai puine, iar dac aplicaia este structurat pe module, testarea devine mai complex i efortul de testare crete. Aplicaia e-DSI este structurat n mai multe aplicaii care pot rula independent i fiecare aplicaie n parte este compus dintr-un numr variabil de module.

73

3.9 Interdependene de aciune a factorilor

Factorii de influen a testrii acioneaz diferit de la produs la produs, de aceea se impune stabilirea unei modaliti de lucru pentru evaluare. Primul mod const n studierea corelaiei dintre factori de unde va rezulta o ierarhizare a acestora dup importana pe care o au. Dac se consider factorii F1, , Fn i se gsesc modele de a msura contribuia, se identific urmtoarele situaii: factori independeni, cnd indicatorul de corelaie este aproape 0; factori direci, cnd indicatorul de corelaie are o valoare apropiat de 1; factori indireci, cnd indicatorul de corelaie are o valoare apropiat de -1. Pentru studierea riguroas a modului n care factorii influeneaz testarea se stabilesc modaliti de obinere a informaiilor prin planuri de experiene sau prin planuri incomplete. Se consider produsele P1, P2, , Pk i factorii F1, , Fn. Se construiete matricea de aciune a factorilor conform tabelului 3.5. Tabelul 3.5 Matricea de aciune a factorilor F1 F2 Fj Fn P1 P2 Pi sij Pk n matricea de aciune a factorilor elementul sij are valoarea 1 atunci cnd factorul Fj acioneaz asupra produsului Pi, sau valoarea 0 n cazul n care factorul nu acioneaz. Se construiesc 2n combinaii experimentale. Un alt mod de abordare const n parcurgerea urmtorilor pai n vederea determinrii interaciunilor: Pasul 1 Definirea de ipoteze. Sunt definite ipoteze cu privire la factorii de influen, nivelul de testare dorit, nivelurile costurilor; sunt definite i modelele de evaluare a costului utilizate. Pasul 2 Efectuarea de observaii pe produse n testare. Sunt testate o serie de produse software i pe msura derulrii procesului de testare sunt 74

nregistrate o serie de date cu privire la factorii care au fost luai n considerare. Se creeaz astfel o baz de date care conine informaii despre efortul privind activitatea de testare i caracteristicile produselor testate, proceselor, instrumentelor i a personalului. Pasul 3 Modelare. Utiliznd informaiile culese prin activitile de la pasul 2, sunt determinai coeficienii modelelor de evaluare a costului testrii software. Modelele sunt validate, se evalueaz i se rafineaz. Pasul 4 Concluzii. Dup modelare se trag diverse concluzii privind stabilitatea modelelor, acurateea acestora, calitatea factorilor, clasele de modele obinute, modelele nefuncionale i alte concluzii cu privire la modele. Planificarea de experiene este costisitoare pentru c presupune dezvoltarea de software pentru fiecare experiment i, de aceea, lucrarea aprofundeaz a doua variant de lucru. ntre factorii identificai care influeneaz testarea exist anumite dependene, natura, sensul i intensitatea acestora fiind determinate de specificul problemei, de specificul aplicaiei, de mediul n care se deruleaz dezvoltarea proiectului.

75

4
CHELTUIELILE AFERENTE PROCESULUI DE TESTARE
4.1 Costurile dezvoltrii software
Dezvoltarea produselor program genereaz o serie de consumuri de resurse care au reflectare n plan economic prin nivelul costurilor, n concordan cu particularitile proceselor din domeniul informaticii. n literatura de specialitate [OPRE95], [CARA02], [DOBR99], [CEPE00] costul este definit ca un sacrificiu fcut n scopul de a deine un bun sau un serviciu. Acest sacrificiu se msoar prin suma de bani cheltuit, proprietatea transferat, serviciile prestate etc. n contabilitatea managerial, costul este definit astfel: suma de bani cheltuit pentru producerea sau cumprarea unui bun, efectuarea unei lucrri sau prestarea unui serviciu; un sacrificiu de resurse sau de valoare; un indicator sintetic prin intermediul cruia este caracterizat calitatea i eficiena activitii economice. n literatura de specialitate se face diferenierea dintre costuri i cheltuieli [BACI01], [OLAR75], [CARA02]. n sens larg, cheltuiala este sinonim cu o plat. n sens financiar, plile constituie o cheltuial. Consumul este factorul esenial prin care se hotrte dac o cheltuial n sens financiar este element de cost. Achiziionarea unei resurse este o cheltuial a firmei prin suma de bani pltit. Aceast cheltuial devine cost atunci cnd resursa este dat n producie. Exis mai multe tipologii de costuri, care sunt prezentate n continuare. Costul de producie include totalitatea cheltuielilor efectuate n cursul procesului de producie. Costurile de producie se clasific n costuri materiale directe, costuri salariale directe i costuri de producie indirecte. Dezvoltarea de software se realizeaz folosind tehnici i metode avansate

76

care permit cuantificarea att a consumurilor de resurse, ct i a duratelor activitilor specifice fiecrei etape din ciclul de dezvoltare. Costurile materiale directe includ toate cheltuielile cu materialele care devin parte component a produsului finit i se regsesc n acesta. Costurile materiale directe nu includ costurile materialelor care nu pot fi identificate direct in produs ci acestea vor intra la costuri de producie indirecte. Costurile salariale directe reprezint cheltuielile efectuate cu fora de munc direct implicat n realizarea produsului (salariile personalului care lucreaz la realizarea produsului i celelalte cheltuieli cu fora de munc). Procesele specifice analizei, proiectrii, programrii, implementrii i mentenanei software sunt caracterizate printr-un nivel foarte ridicat al ponderii forei de munc nalt calificate. De aceea se impune tratarea special a volumului de munc pe care trebuie s-l depun analitii, designerii, programatorii i celelalte categorii, pentru a menine nivelul cheltuielilor n general i nivelul cheltuielilor salariale n special, ntre limite care s genereze eficien la nivelul utilizatorilor de software. Costurile indirecte de producie reprezint un ansamblu variat de cheltuieli care nu pot fi atribuite direct produsului obinut aplicaia informatic. Cheltuielile indirecte se regsesc i sub denumirea de cheltuieli de regie. Aceste cheltuieli includ: materiale indirecte; n aceast categorie intr rechizite, hrtie i alte materiale care nu sunt folosite n mod direct la realizarea produsului software. salarii indirecte; i n firmele productoare de software exist personal care nu este implicat direct n procesul de realizare a produselor informatice, precum angajaii din contabilitate i serviciul administrativ; salariile acestora se reflect n cheltuielile indirecte; cheltuieli generale privind producia; se regsesc aici cheltuielile pentru iluminat, amortizri, reparaii, chirii, nclzire. Spre deosebire de procesul de producie tradiional, procesul dezvoltrii software se caracterizeaz printr-o serie de particulariti [APRE00]: produsele finite care se obin nu au o reprezentare fizic, nefiind caracterizate prin form, volum sau greutate; echipamentele utilizate n activitatea software pot fi folosite la o varietate de activiti precum analiz, proiectare, programare sau testare;

77

operaiile au durate cu fluctuaii mari deoarece se consider c fiecare produs este unicat; existena unei varieti de modele i metodologii care conduc la obinerea aceluiai rezultat nu permite stabilirea unei modaliti unice de urmat; deoarece produsul final obinut nu are o form msurabil prin uniti ale sistemului metric, fluxurile de producie sunt ambigue. Din punct de vedere al dependenei de evoluia volumului produciei exist costuri fixe i costuri variabile. Costurile fixe reprezint acele cheltuieli ale firmei care pe termen scurt sunt independente de volumul produciei realizate (amortizare capital fix, chirii, salarii personal administrativ, cheltuieli de ntreinere, dobnzi, electricitate, ap, nclzire). n timp, pe termen lung, se constat o evoluie cresctoare sau descresctoare a acestor costuri. Avnd n vedere stabilitatea structural a echipamentelor i instrumentelor ntr-un interval de timp determinat, pentru cheltuielile fixe repartizate unui produs software se construiesc algoritmi riguroi i stimulativi n raport cu creterea complexitii. Costurile variabile reprezint cheltuielile firmei care se modific n funcie de volumul produciei i includ cheltuieli cu materiile prime, materialele, salarii directe, combustibil i energie n cazul realizrii de software, aceste cheltuieli sunt destul de bine delimitate. Costul total al volumului produciei este dat de suma costului variabil i a costului fix. n funcie de modul de identificare i repartizare a consumurilor de resurse pe obiectul de cost, exist costuri directe i costuri indirecte. Costurile directe sunt acele costuri care se identific n mod evident pe obiectul de cost i reprezint cheltuieli care sunt atribuite cu exactitate pe unitatea de produs. n general, n costurile directe sunt incluse costurile cu salariile directe i costurile cu materiile prime. Costurile indirecte sunt costuri care nu pot fi identificate cu uurin i atribuite unui obiect de cost i ele trebuie repartizate dup anumite metode specifice (chei de repartiie). Costul poate fi privit att din punct de vedere economic, ct i din punct de vedere contabil. Costul economic cuprinde cheltuielile cu factorii de producie suportate de firm i consumul de resurse care nu sunt nregistrate sub form de pli. Costul contabil conine cheltuielile realizate efectiv de ctre firm, care rezult din evidenele contabile ale acesteia. 78

4.2 Costurile calitii produselor program

Costurile referitoare la calitatea software includ: costurile de prevenire, costurile de evaluare, costurile datorate erorilor interne i costurile datorate erorilor de utilizare extern [KANE96], [OLAR99], [PRESS00], [TEOD99]. Costurile de prevenire a erorilor n fazele de analiz, proiectare, programare (Cp) reprezint costurile legate de efortul de prentmpinare a apariiei defectelor. Cea mai mare parte a costurilor de prevenire se regsesc n proiectare, programare i marketing i o parte foarte mic n testare. Cheltuielile de prevenire sunt realizate pentru : instruirea personalului; aceasta reprezint una din cele mai bune metode de prevenire, ns costurile sunt de cele mai multe ori ridicate; analiza cerinelor; o analiz detaliat a cerinelor se reflect pozitiv n calitatea produsului obinut; specificaii clare; existena unor specificaii bine definite conduce la realizarea de produse informatice de calitate, ns pentru a ajunge la astfel de specificaii este necesar un efort suplimentar reflectat prin costuri mai mari; documentaie intern; documentarea tuturor activitilor i stabilirea i urmarea unui flux informaional coerent au efecte benefice asupra obinerii de procese de calitate ridicat; evaluarea fiabilitii instrumentelor de dezvoltare; este o activitate necesar, posibilitatea apariiei erorilor fiind micorat prin utilizarea de instrumente fiabile. Costurile de evaluare i control software (Ce) sunt costurile testrilor, inspeciilor i examinrilor realizate pentru a stabili concordana cu specificaiile produsului. Majoritatea costurilor de evaluare sunt legate de testarea software i includ cheltuieli pentru: analiza proiectului; se realizeaz n scopul determinrii posibilelor erori de logic n activitatea de proiectare; inspecia codului; reprezint o cale de verificare a codului surs precum i a produselor obinute n fazele de analiz i proiectare; instruirea personalului de testare; testarea structural; testarea funcional; automatizarea testrii; cheltuielile pentru automatizarea testrii sunt destul de mari, dar procesul de testare va fi mai eficient; 79

 activitile specifice testrii beta; testarea capacitii de utilizare; eforturile orientate spre testarea de acceptare. Costurile datorate neconformitilor interne (Cdi) reprezint costurile pentru corectarea neconformitilor descoperite nainte de livrarea produsului ctre beneficiar i includ: corectarea erorilor; testarea de regresie; eforturile specifice operaiilor suplimentare de testare; munca suplimentar de programare; munca suplimentar de marketing; munca suplimentar de publicitate; ntrzierea livrrii produsului software; costul de oportunitate al livrrii trzii. Costurile datorate neconformitilor externe (Cde) reprezint costurile pentru corectarea neconformitilor descoperite dup livrarea produsului ctre beneficiar. Costurile de defectare extern sunt foarte mari. n figura 4.1 sunt reprezentate ierarhic costurile aferente calitii software.
Costurile calitii software

Costurile realizrii calitii

Costurile de asigurare extern a caliti

Costurile de investiii

Costurile datorate neconformitilor

Costurile de prevenire

Costurile de evaluare

Costurile datorate neconformitilor interne

Costurile datorate neconformitilor externe

Figura 4.1 Costurile referitoare la calitatea software 80

Conform [OLAR99], potrivit abordrii tradiionale a analizei costurilor, referitor la corelaia cost-calitate, pe msura creterii costurilor de prevenire (Cp) i a costurilor de evaluare (Ce), se produce scderea costurilor defectrilor (Cd). Din figura 4.2 se observ c graficul costurilor totale referitoare la calitate admite un nivel minim, iar nivelul calitii corespunztoare zonei AB este considerat optim. Se remarc faptul c n zona de optim, Cd Cp + Ce. Se remarc pe grafic n stnga zonei optime o zon a mbuntirilor, unde Cd > 70% i Cp + Ce < 30%, respectiv, n dreapta, o zon a supracalitii, n care Cd < 40% Cp + Ce > 60%.
Costuri Costurile existenei erorilor
Zona optim Cd Cp + Ce Zona mbuntirilor Cd > 70% Cp + Ce < 30% Zona supracalitii Cd < 40% Cp + Ce > 60%

Costul total al calitii software

Costurile de prevenire i evaluare

A 0 Nivelul calitii

B 100

Figura 4.2 Corelaia cost calitate software Din analizele efectuate asupra costurilor calitii software s-a dedus importana alegerii momentului n care testarea se consider ncheiat, precum i a momentului lansrii aplicaiei pe pia sau predarea ctre beneficiar.
Costuri

Costurile testrii

Costurile nonfiabilitii Data livrrii aplicaiei

Timp

Figura 4.3 Costurile testrii software i ale nonfiabilitii 81

Este foarte important alegerea datei de livrare a produsului software, deoarece testarea este foarte costisitoare dup aceast dat. Costul testrii se multiplic de sute de ori dup ce produsul a fost livrat, fa de fazele de nceput ale ciclului de dezvoltare. Dup cum se observ n figura 4.3, pe msur ce testarea continu, costul livrrii unui software nefiabil scade, [PETE00]. n [PATT01] este identificat grafic efortul optim de testare. n figura 4.4 se observ o zon de sub-testare i o zon de supra-testare.
Cantitate Numrul de erori Testare optim Sub-testare Costurile testrii Supra-testare Volumul de testare

Figura 4.4 Efortul de testare Fiabilitatea depinde de testare. Dup ce un anumit nivel de fiabilitate a fost atins, continuarea testelor va crete nivelul fiabilitii doar cu un procent foarte mic. Pentru mbuntirea procesului de testare i scderea costurilor asociate acestuia, automatizarea testrii este o soluie eficient, chiar dac este imposibil de realizat pentru ntregul proces. Din analiza costurilor aprute n ciclul de dezvoltare software s-au obinut urmtoarele costuri asociate fazelor specifice dezvoltrii software [HUBE99]: analiza cerinelor/specificaii: 18%; proiectare: 19%; implementare: 34%; testare: 29%.

82

Grafic, aceste procente sunt reprezentate n figura 4.5

Figura 4.5 Repartiia costurilor pe fazele ciclului de dezvoltare Procentele asociate costurilor fazelor procesului de dezvoltare software variaz n funcie de specificul aplicaiei. Costul testrii software include cheltuielile legate de realizarea cazurilor de test, a scripturilor de test, rularea testelor i evaluarea rezultatelor execuiei testelor. Costurile induse de corectarea erorilor intr n categoria costurilor de dezvoltare. n [JONE86], pentru costurile testrii sunt identificate urmtoarele elemente de cheltuial: a) costuri de pregtire care includ: scrierea cazurilor de test; ncrcarea cazurilor de test ntr-o bibliotec; pregtirea scripturilor/scenariilor de test. Aceste cheltuieli nu depind de numrul de defecte i rmn la acelai nivel. b) costuri de execuie care includ: rularea scenariilor de test; scrierea rapoartelor pentru defectele pentru fiecare eroare descoperit. Costurile de execuie sunt proporionale cu numrul de erori gsite n program. Aceste costuri nu ating valoarea zero chiar dac nu sunt gsite erori, deoarece aceste teste oricum trebuie rulate.

83

4.3 Cheltuieli cu personalul

Cheltuielile cu personalul au ponderea cea mai mare n totalul cheltuielilor din procesul de testare. Pentru testarea de software clasic, orientat obiect, client/server sau bazat pe componente este necesar specializarea personalului. Acesta parcurge toate fazele procesului de testare i determin acceptarea sau respingerea intrrii n uz curent a aplicaiei software. Personalul se constituie n echip, fiecare membru al acesteia avnd sarcini precise. [DUST99] identific, n cadrul echipei de testare, urmtoarele categorii de specialiti: managerul de teste, responsabil cu dezvoltarea planurilor de test i a obiectivelor testrii, urmrirea desfurrii testelor, achiziia de hardware i software pentru teste, angajarea de personal specializat; pentru aplicaia e-DSI, managerul de teste are n vedere platforma pe care este dezvoltat aplicaia i utilizarea tehnologiei JSP; conductorul tehnic al testelor, responsabil cu alegerea metodologiei de testare i implementarea procesului de testare; inginer pentru testarea de utilizabilitate, responsabil cu proiectarea i dezvoltarea scenariilor de test i cu administrarea procesului de testare; inginer pentru testarea manual, responsabil cu implementarea procedurilor i a cazurilor de test bazate pe cerine i cu execuia manual a procedurilor de test construite; inginer pentru testarea automat, responsabil cu implementarea procedurilor i a cazurilor de test bazate pe cerine i cu proiectarea, implementarea i execuia secvenelor automate de test; inginer pentru testarea reelelor, responsabil cu testarea reelelor, a bazelor de date i a aplicaiilor middleware; n cazul aplicaiei e-DSI este necesar existena n echipa de testare a unui astfel de specialist, avnd n vedere faptul c aplicaia utilizeaz baze de date, aplicaii middleware precum i caracterul distribuit al acesteia; specialist n medii de testare, responsabil cu instalarea instrumentelor de testare, pregtirea mediilor instrumentelor de testare i ntreinerea bazei de date a testelor care se deruleaz; specialist n biblioteca testelor i n configurarea testelor, responsabil cu managementul schimbrilor n cadrul programelor 84

de test i cu ntreinerea bibliotecii cu programe de test reutilizabile; analist de afaceri, responsabil cu analiza domeniului legat de aplicaia aflat n dezvoltare, interviuri cu utilizatorii; reprezentant al utilizatorului, responsabil cu comunicarea cerinelor utilizatorului i a cerinelor specifice domeniului aplicaiei; de exemplu, pentru utilizarea curent a aplicaiei eDSI, interfeele au fost proiectate innd seama de cerinele exprese ale reprezentantului utilizatorilor, asigurndu-se continuitatea att n raport cu interfeele aplicaiei informatice care trebuie nlocuite, ct i n raport cu tipologiile interfeelor pentru aplicaii de afaceri electronice. Echipa de testare are n sarcin urmtoarele activiti: definirea obiectivelor testrii; pentru aplicaia e-DSI s-a stabilit ca accentul s fie pus pe testarea de funcionare, de utilizare i de coninut, iar testarea la nivel de cod surs s se efectueze pentru modulele n care acest lucru este posibil; colectarea i construirea exemplelor de test; pentru aplicaia informatic e-DSI s-a realizat un numr mare de cazuri de test; de exemplu pentru testarea funcional orientat pe interfaa grafic au fost construite nouzeci i apte cazuri de test; constituirea unei arhive pentru comportamentul software-ului n vederea comparaiilor i definirii corecte a contextului n care este plasat produsul de testat; definirea specificaiile de testare prin extragerea din specificaiile produsului a acelor elemente care formeaz punctele cheie ale procesului de testare; alegerea tehnicii de testare adecvat n raport cu produsul i obiectivele urmrite; particularitile aplicaiei informatice e-DSI au impus realizarea unui mod combinat de derulare a procesului de testare, urmrindu-se efectele accesului perturbator prin mesaje, la resursele existente; structurarea procesului de testare n etape cu ncrcarea specific fiecrui produs software; lansarea n execuie a produsului; pentru produsul e-DSI, aceast etap a fost pregtit cu minuiozitate avnd n vedere riscurile pe care le genereaz mai ales accesul neautorizat la resursele definite i referite; compararea comportamentului real (efectiv) cu comportamentul definit n specificaii; 85

elaborarea raportului de testare i celelalte piese care se constituie n elementele de baz ale certificrii sau respingerii. Testarea este un proces independent care are menirea s verifice comportamentul produsului sau al unui subansamblu la un moment dat. Instruirea personalului de testare este condiia asigurrii eficienei procesului. Eficiena testrii depinde exclusiv de personal, deoarece acesta este factorul cheie. Personalul de testare este prin activitatea lui singurul care dirijeaz acest proces. Cheltuielile cu personalul constau n mare parte din salariile pltite acestuia. Cele mai importante activiti ale personalului din testare pentru care sunt pltite salariile sunt: analiza i proiectarea testelor; implementarea testelor; rularea i evaluarea testelor; scrierea documentaiei de testare (rapoarte, planuri de test). Durata de timp (DT) a procesului de testare este dat de formula:
DT = d i
i =1 5

unde d1 durata obinerii datelor de test; d2 durata crerii cazurilor de test; d3 durata rulrii testelor; d4 durata evalurii rezultatelor; d5 durata construirii rapoartelor de testare. Ponderea cheltuielilor de personal variaz de la un proiect la altul, n funcie de factori legai de echipa de testare (numrul, experiena i eficiena personalului din echip), precum i de factori legai direct de proiect (dimensiunea proiectului, complexitatea proiectului) i de gradul de reutilizare a componentelor. Aa cum rezult din [STI01], salariul mediu n testarea software este n Statele Unite de 85000 USD pe an pentru testeri cu 3-6 ani de experien. Pentru personalul cu experiena de peste 7 ani n testare, salariul mediu este de 98000 USD pe an. n tabelul 4.1 sunt prezentate limitele minime i maxime ale salariilor pentru personalul din testare din Statele Unite n funcie de vechime i experien.

86

Tabelul 4.1 Salariile pltite personalului din testare n SUA n 2001 (USD/an) Ani de experien <1 44000 53000 12 54000 63000 36 64000 110000 >7 74000 135000

Salariile variaz n cadrul aceleai grupe de experien n funcie de statul n care sunt angajai. n aceast categorie de cheltuieli cu personalul sunt incluse i cheltuielile de formare a acestuia, sub form de pli pentru cursuri sau pentru alte moduri de pregtire i se identific: cheltuieli cu instruirea pe tehnici de testare; cheltuieli cu instruirea pentru certificare; cheltuieli cu instruirea n vederea utilizrii echipamentelor i instrumentelor, ntruct pot fi repartizate dup resursa timp alocat produsului testat. Pentru instruirea personalului specializat n testare se identific urmtoare moduri de pregtire: cursuri de specializare interne; cursuri de specializare externe; participri la conferine; cri, articole i materiale instructive; versiuni demo pentru utilizarea unor produse. Costurile pentru specializare n testare pe anumite tehnici, metode, instrumente software sau platforme hardware sunt foarte mari, ajungnd pn la cteva zeci de mii de dolari. Pentru certificarea testerilor exist mai multe stadii. De exemplu, QAI ofer: CSTE (Certified Software Test Engineer) i CSQA (Certified Software Quality Assurance). De regul, companiile productoare de software prefer personal deja calificat i acord o atenie limitat calificrii, ceea ce conduce la scderea performanei n raport cu un obiectiv strategic. Personalul manifest reineri mai ales pentru cursurile de foarte scurt durat ntruct creeaz dependene n raport cu mobilitatea spre un alt loc de munc. 87

4.4 Cheltuieli pentru instrumente de asistare

Testarea aplicaiilor software complexe este un proces care se execut n condiiile unei dotri cu echipamente i instrumente de asistare. Este imposibil s se procedeze la testarea complet a unui produs program realizat pe o arhitectur de sistem de calcul n condiiile n care echipa de testare nu deine cel puin aceleai tipologii de resurse. Mai mult, problematica analizei automate a comportamentului unui produs software necesit existena unor instrumente specializate. Chiar dac produsul program este elaborat n proces asistat, multitudinea deciziilor luate de analiti i programatori poate conduce la rezultate finale (module, programe, structuri de fiiere) care se ndeprteaz de la cerinele coninute n specificaii. Pentru desfurarea procesului de testare n bune condiii, trebuie s existe instrumente software corespunztoare. Acestea fie trebuie achiziionate de ctre firm, fie sunt nchiriate, fie se elaboreaz intern. n cazul testrii software, automatizarea acestui proces are ca efect reducerea costurilor necesare efecturii testelor. Obiectivul testrii asistate este acela de a garanta coerena procesului de testare, un grad ridicat de acoperire a testrii funciilor din program i realizarea corelaiilor posibile dintre funcii. Testarea asistat presupune existena unor instrumente (programe) pentru care programul de testat este intrare, iar ieirile sunt rezultate prin care este apreciat comportamentul intrrilor. Aceste instrumente au rolul de a ordona exemplele de test, de a sistematiza informaiile privind modul n care se activeaz modulele programului de testat. Principalele instrumente software utilizate n procesul de testare sunt: instrumente de dezvoltare a testelor (medii de programare, medii specializate pentru scrierea de programe de test); instrumente pentru testarea automat (analizoare de fiiere surs, programe pentru rularea modulelor aflate n testare); instrumente de culegere a datelor n timpul derulrii procesului de testare, precum i pentru stocarea acestora. La ora actual exist o multitudine de instrumente pentru asistarea testrii, cum ar fi: instrumente de captare/redare, instrumente de execuie automat a testelor, analizoare de acoperire, generatoare de cazuri de test, generatoare de date de test, analizoare logice/de complexitate, instrumente de trasare a erorilor i instrumente pentru managementul testrii. 88

Instrumentele de captare/redare se utilizeaz pentru nregistrarea sesiunilor de testare n fiiere script, permind repetarea acestora. Instrumentele permit efectuarea de teste multiple n manier automat i comparaii asupra rezultatelor. Aceste instrumente sunt eficiente n testarea regresiv. Instrumentele de execuie automat a testelor sunt asemntoare instrumentelor de captare/redare, dar cazurile de test sunt specificate de utilizator n fiiere script. Aceste instrumente i dovedesc eficiena atunci cnd sunt teste multe i acestea se execut de mai multe ori. Analizoarele de acoperire sunt folosite pentru evaluarea gradului n care structura codului testat a fost acoperit prin cazurile de test. Aceste instrumente sunt utile pentru identificarea secvenelor de cod care nu au fost parcurse. Generatoarele de cazuri de test construiesc cazuri de test semnificative pe baza unor informaii precum cerine, modele ale datelor, modele obiectuale. Avantajul utilizrii acestor instrumente este eliminarea redundanei n testare, prin determinarea cazurilor de test care asigur acoperirea ct mai mare a codului. Generatoarele de date de test servesc la popularea fiierelor i bazelor de date n vederea testrii. Popularea se face fie cu date aleatoare, fie cu date obinute prin specificarea unor condiii. Aceste instrumente se utilizeaz n general pentru volume mari de date necesare testrilor operaionale i la capacitate maxim. n activitatea de cercetare a fost realizat un generator de date de test pentru fiiere. Pe baza descrierii tipurilor i a domeniilor cmpurilor i a numrului de articole de pentru test, se genereaz fiiere de test corespunztoare. Analizoarele logice/de complexitate servesc la cuantificarea complexitii unor poriuni de cod. Majoritatea instrumentelor de acest tip ofer i reprezentri grafice ale cilor posibile n structura codului. Sunt utile pentru determinarea cazurilor de test necesare pentru atingerea anumitor puncte din cod din rutine complexe. Instrumentele pentru pregtirea codului sunt utilizate pentru analiza programelor surs supuse testrii i inserarea de apeluri de funcii specifice pentru culegerea de informaii n momentul n care programul este rulat. Instrumentele de trasare a erorilor permit gestiunea informaiilor privitoare la erorile detectate, stadiul corectrii lor i centralizarea acestor informaii pentru urmrirea tendinelor acestor defecte. Pe baza tendinelor observate se pot efectua mbuntiri n procesele din ciclul de dezvoltare software din cadrul organizaiei.

89

Instrumentele pentru managementul testrii sunt utilizate la asistarea planificrii i organizrii elementelor implicate n testare precum: fiiere script, cazuri de test, rapoarte de test i rezultate obinute. Instrumentele pentru execuia simbolic vizeaz luarea n considerare a unor variabile i operarea cu acestea, obinndu-se expresii agregat cu ajutorul crora se controleaz corectitudinea evalurilor. Pentru aplicaia e-DSI un astfel de instrument vizeaz controlul prin zero i prin unu. Dac variabilele totalc i totpc au atribuite valorile x i, respectiv, -x n evaluarea expresiei totalc+=totpc se va obine prin calcul simbolic totalc=x*(-x)=0. Dac variabilele totalc i cotaTVA au valoarea x, pentru expresia TVA=totalc/CotaTVA, prelucrrile simbolice vor conduce la TVA=1. Cheltuielile de asistare includ: cote pri repartizate din amortizrile pentru echipamente i instrumente software utilizate; cheltuieli pentru ntreinerea echipamentelor i instrumentelor; cheltuieli necesare analizei de comportament al produsului pe baza datelor de test generate sau a rezultatelor testrii rezultate n faze anterioare. Prin creterea automatizrii testrii, n momentul achiziionrii instrumentelor i pe o anumit perioad se nregistreaz cheltuieli mai mari (cheltuielile pentru instrumente i cheltuieli pentru instruire n utilizarea acestora), ns acestea se vor amortiza rapid prin scderea perioadei necesare realizrii anumitor teste. Automatizarea va fi eficient dac se respect etapele care trebuie urmate pentru trecerea de la testarea manual la cea automatizat i dac se are n vedere c nu toate testele pot fi automatizate. n Anexa 3 sunt prezentate cele mai importate instrumente de asistare a testrii, o descriere a lor precum i preul acestora, acolo unde este disponibil. Se observ c preurile variaz ntre 500 i 40.0000 USD, n funcie de caracteristicile fiecrui instrument. Preurile sunt date pentru un calculator, un utilizator sau un anumit numr de utilizatori. n cazul n care se iau mai multe produse pentru mai muli utilizatori sau mai multe calculatoare, preul crete corespunztor. n condiiile n care companiile productoare de software din ara noastr vizeaz obinerea certificrii ISO9003 n structura costului final al unui produs software, circa 20% trebuie s fie alocat amortizrii i utilizrii instrumentelor de asistare a procesului de testare.

90

4.5 Cheltuieli pentru echipamente

n procesul de testare este necesar ca aplicaia software s fie testat n mediul n care aceasta va rula. De aceea, n cazul n care nu exist, se vor achiziiona echipamente hardware specifice sau se vor utiliza simulatoare software. Echipamentele fie vor fi cumprate, fie se vor nchiria pe perioada derulrii testelor . Mrimea acestor cheltuieli este variat, lund n considerare faptul c pentru anumite proiecte nu este necesar achiziionarea sau nchirierea de echipamente, aceste echipamente existnd deja n cadrul firmei. Pentru alte proiecte este necesar s se achiziioneze sau s se nchirieze echipamente, ceea ce conduce la creterea considerabil a acestei categorii de cheltuieli. Echipamentele hardware utilizate n testare sunt calculatoare (servere, staii de lucru, calculatoare de proces) i infrastructura de reea (plci de reea, cabluri, hub-uri, switch-uri). Echipa de testeri, ca entitate distinct, beneficiaz de resurse diversificate, dintre care echipamentele au o pondere nsemnat. ntruct procesul de testare este continuu, att pentru faze ct i pentru produsul finit, specializarea echipamentelor se obine prin dispozitive periferice de mare performan, prin ncrcarea de interfee foarte puternice i prin izolarea reelei de factorii perturbatori ai procesului. Compania productoare de software dezvolt aplicaii deosebit de diverse, ceea ce implic n planul testrii, de asemenea, o mare diversitate de tehnici i instrumente. De aceea, echipamentele aflate la dispoziia echipei de testare trebuie s fie astfel alese nct s permit referirea oricrui instrument destinat testrii oricrui produs software. n acest scop se definete conceptul de configuraie minimal n raport cu cerine maximale. Se consider aplicaiile informatice A1, A2, , An crora le corespunde necesarul de k resurse, iar rij reprezint consumul din resursa Ri necesar derulrii activitilor pentru realizarea aplicaiei Aj. Se construiete un tablou cu n+1 coloane i k linii (tabelul 4.2). Coloana n+1 va corespunde aplicaiei ipotetice An+1 care se obine din alegerea maximelor valorilor de pe liniile tabloului.

91

Tabelul 4.2 Tabloul necesarului de resurse hardware Aj .. An An+1 Aplicaia A1 Resursa R1 Ri rij Rk Se stabilete configuraia minim care permite lansarea n execuie a unei aplicaii ipotetice, al crui necesar de resurse este dat de {max(r1 j ), max(r2 j ),..., max(rkj )} , care permite testarea aplicaiei An+1.
j =1, n j =1, n j =1, n

n [RTI02] se consider c mrimea costurilor cu instrumentele de testare i echipamentele hardware reprezint 20% din costul testrii software.

4.6 Cheltuieli indirecte

n aceast categorie intr cheltuielile pentru achiziionarea de consumabile, utilizate n general pentru elaborarea sistematizat a documentaiei. n cadrul acestor cheltuieli se includ i cheltuielile cu cotele de regie i alte cheltuieli indirecte. Testarea include elemente de consultan care sunt nsoite de cheltuieli. Consultana este specializat i se refer la domenii complementare ariei de cuprindere pentru care sunt specializai membrii echipei de testare. n anumite situaii aceste cheltuieli de consultan sunt destul de ridicate. Experiena arat c pentru aplicaii informatice de complexitate medie cheltuielile indirecte ocup aproximativ 20% din totalul cheltuielilor de testare (figura 4.6).

92

Cheltuieli indirecte

Cheltuieli directe

Figura 4.6 Structura cheltuielilor n cazul n care pentru procesul de testare este angajat o firm specializat (outsourcing), cheltuielile de testare sunt reprezentate n special de suma pltit firmei pentru prestarea unui serviciu, la care se adaug i alte cheltuieli specifice. Categoriile de cheltuieli prezentate vor deveni cheltuieli ale firmei care realizeaz testarea i se vor nregistra n evidenele acesteia. Decizia de alegere a unei firme din exterior se ia n primul rnd pe baz de eficien economic, astfel nct cheltuielile efectuate pentru testare folosind resurse interne s fie mai mari dect cheltuielile generate de angajarea unei echipe din afar. Un alt aspect luat n considerare este i capacitatea firmei care dezvolt proiectul software de a realiza testarea. Lipsa personalului specializat sau a instrumentelor i echipamentelor necesare sau a experienei necesar, conduce la cheltuielile de testare folosind resurse interne foarte mari. n plus, efectele negative nu ar ntrzia s apar dup ce aplicaia software a fost dat n utilizare curent, tiut fiind faptul [BOEH94] c efectele generate de descoperirea i corectarea erorilor la client se pot multiplica ntre 40 i 1000 ori fa de costul descoperirii erorilor n fazele de nceput ale ciclului de dezvoltare software.

4.7 Repartizarea cheltuielilor pe nivelurile testrii

Cheltuielile pentru testarea de module reprezint o parte important a testrii datorit faptului c numeroase echipe de analiz proiectare concep soluiile sub form de structuri arborescente puse n coresponden cu module n cadrul fiecrui nivel. 93

Cea mai important categorie de cheltuieli n testarea de module o constituie cheltuielile cu personalul, ns intervin i cheltuieli legate de utilizarea unor instrumente specifice de testare, a unor echipamente, precum i alte cheltuieli pentru materialele utilizate n cadrul acestui nivel de testare. Costurile privind testarea de modul au o pondere de circa 25% din totalul cheltuielilor de testare. Pentru testarea funcional, efortul n procesul de testare a modulelor const n urmtoarele activiti: analiza specificaiilor; este necesar pentru proiectarea cazurilor de test; efortul de analiz se reduce n cazul existenei unor specificaii clare i complete; identificarea domeniilor; n vederea alegerii seturilor de date de test pentru parametrii funciilor, este necesar analiza domeniilor parametrilor n funcie de tipul acestora; generarea datelor de test; crearea de programe conductoare de test; pentru apelul modulelor care se testeaz este necesar construirea de secvene care le apeleaz; crearea de module vide; sunt necesare n cazul n care n modulul de testat sunt apeluri la funcii care nu au fost scrise; rularea programului folosind seturi de date de test; evaluarea rezultatelor testelor; n cazul testrii manuale, evaluarea rezultatelor testelor se face comparnd valorile de ieire cu valorile ateptate; n caz de neconcordan, se raporteaz eroarea; n cazul automatizrii testrii, exist aseriuni cu privire la rezultatele ateptate i cele efectiv obinute; n caz de neconcordan, eroarea este evideniat automat; generarea de rapoarte; erorile descoperite sau comportamentul anormal identificat este nregistrat; pentru fiecare anomalie se precizeaz detalii cum ar fi modulul n care a aprut, manifestarea, data identificrii i persoana care e efectuat testele; de asemenea, se nregistreaz i rulrile testelor care nu au condus la descoperirea de erori. Pentru testarea structural, efortul n procesul de testare a modulelor const n urmtoarele activiti: analiza codului surs; n vederea construirii grafului asociat programului, trebuie parcurs codul surs; n aceast activitate se folosesc o serie de instrumente care genereaz automat graful; pentru modulele de dimensiuni reduse, analiza se face manual; 94

identificarea cilor n program; sunt identificate cile existente n cadrul modulului, cele pentru care se genereaz datele de test; generarea datelor de test; n funcie de cile identificate n cadrul modulului sunt identificate seturi de date de test, astfel nct prin rulare cu aceste seturi de date s fie parcurse cile identificate; rularea testelor; utiliznd seturile de date de test, modulele sunt rulate iar rezultatele acestora sunt colectate; evaluarea rezultatelor testelor; evaluarea testelor se face asemntor testrii funcionale; nregistrarea gradului de acoperire; se calculeaz raportul dintre numrul de elemente parcurse i numrul total de elemente (instruciuni, decizii, ramuri, ci); generarea de rapoarte; n mod asemntor sunt nregistrate rezultatele testelor pentru fiecare test n parte. Cheltuielile pentru testarea de integrare sunt rezultatul activitilor independente ale grupurilor de lucru i sunt generate de o serie de interfee care trebuie realizate pentru a remodela interaciuni dintre componente n vederea compatibilizrii. De asemenea, aceste cheltuieli apar i pe fondul necesitii scderii duratei de realizare software prin reutilizare de componente. Sunt situaii n care o aplicaie nou construit are caracter de continuator pentru aplicaii existente, aspect realizat fie prin preluarea de informaii din fiiere deja existente, fie prin realizarea de conversii ale unor fiiere, astfel nct acestea s devin intrri naturale n aplicaiile existente. Aceste activiti ale testrii de integrare genereaz cheltuieli specifice, n principal cheltuieli cu personalul. Este necesar construirea de module care ajut la realizarea testrii de integrare, volumul i complexitatea acestora depinznd de complexitatea modulelor sau claselor care se testeaz, iar de aici rezult cheltuieli suplimentare mai mari sau mai mici. Nivelul cheltuielilor pentru testarea de integrare depinde i de strategia de integrare aleas: ascendent, descendent, mixt sau de tip big-bang. Cheltuielile cele mai mari apar n cazul integrrii de tip big-bang, n special pentru proiecte de dimensiuni mari. Efortul n testarea de integrare este dat de: identificarea relaiilor ntre module; pe baza modelelor rezultate din fazele de analiz i proiectare se stabilesc relaiile i legturile dintre modulele care se integreaz; integrarea modulelor; testarea se desfoar pe msur ce sunt integrate modulele; pe lng testele noi, scrise pentru modulule 95

adugate, sunt rulate i testele utilizate pentru modulele integrate anterior; construirea de programe conductoare de test; construirea de module vide; rularea testelor; evaluarea rezultatelor testelor; generarea rapoartelor de testare. Cheltuielile pentru testarea de sistem reprezint o categorie important de cheltuieli ale procesului de testare prin prisma nivelurilor testrii. Testarea de sistem presupune verificarea ntregului sistem att din punct de vedere al respectrii specificaiilor sale, ct i din punct de vedere al performanelor: vitez de rulare, memorie ocupat, timp de rspuns. n acest caz testarea se efectueaz asupra ntregului sistem realizat, att software ct i hardware. Cheltuielile pentru testarea de sistem includ salariile personalului implicat, utilizarea de hardware i software, precum i cheltuieli pentru realizarea documentaiei necesare. Cheltuielile pentru testarea de validare sunt generate de activitile necesare validrii de ctre beneficiar a aplicaiei software dezvoltate. Cheltuielile care apar n cadrul testrii de validare sunt: cheltuieli cu personalul; ocup cea mai mare pondere n totalul cheltuielilor, n cea mai mare parte fiind date de salariile personalului implicat n procesul de testare; cheltuieli pentru distribuirea versiunilor beta ale aplicaiilor pe suport magnetic (CD-uri, dischete); cheltuieli pentru tiprirea documentaiei; sunt necesare multe rapoarte i documente cu privire la testarea de validare; cheltuieli legate de contactele cu beneficiarii. Evidenierea cheltuielilor pe nivelurile procesului de testare constituie o activitate dificil, avnd n vedere interaciunile dintre nivelurile testrii, precum i modul n care se realizeaz testarea (intern sau extern).

4.8 Repartizarea cheltuielilor pe fazele procesului de testare

Planificarea procesului de testare este parte integrat a etapei de realizare a planului la nivelul ntregului proiect software.

96

Cheltuielile specifice acestei faze sunt determinate de: estimarea volumului de test; avnd n vedere o serie de caracteristici ale aplicaiei, se determin necesarul de teste; pe parcurs, volumul de test se va ajusta; identificarea riscurilor i a nivelurilor de risc; identificarea riscurilor poteniale constituie a activitate important, avnd n vedere c de multe ori determinarea modulelor sau a funciilor care se testeaz se face pe baza riscului indus de acestea; estimarea numrului de cazuri de test i durata acestora; n scopul determinrii necesarului de resurse pentru activitatea de testare, pornind de la estimrile cu privire la aplicaie sunt avansate ipoteze cu privire la cazurile de test posibile; determinarea condiiilor de terminare pentru fiecare activitate de testare; este necesar s se stabileasc momentul n care testarea se consider ncheiat; printre criterii se enumr acoperirea prin teste a 95% dintre decizii sau numrul erorilor depistate este foarte mic i se apropie de zero; redactarea planului de test; este o activitate obligatorie care necesit un efort destul de mare i care se reduce prin utilizarea de instrumente specifice pentru asistarea testrii. n funcie de dimensiunea proiectului i de cerinele specifice aplicaiei software apar variaii ale cheltuielilor de la un proiect la altul, de la o firm la alta. Pentru aplicaia e-DSI, planificarea procesului de testare const n realizarea planului de test n care sunt nregistrate estimri ale numrului de cazuri de test necesare pentru testarea celor ase aplicaii componente, precum i pentru testarea ntregii aplicaii. Analiza i proiectarea testelor are la baz o serie de tehnici i metode care direcioneaz spre latura industrial a procesului de testare, eliminnd aspectele intuitive, meteugreti sau orientate spre arta testrii. Testele se creeaz prin traversarea tuturor etapelor procesului de elaborare software. Corespunztor etapei de analiz rezult o structurare a tipologiilor de date de test. n etapa de proiectare are loc o detaliere, iar lucrul pe textul surs conduce la definirea propriu-zis a datelor de test. Etapele de analiz i proiectare a testelor necesit un volum mare de munc, care antreneaz o serie de cheltuieli corespunztoare. Se identific urmtoarele categorii de cheltuieli: salariile personalului implicat n analiz i proiectare; este posibil ca aceleai persoane s lucreze n ambele etape;

97

cheltuielile materiale; sunt cuprinse hrtie, cartue imprimant, rechizite; cheltuielile indirecte; includ cheltuieli cu chiriile, energia, apa. Efortul depus n aceste etape ale procesului de testare variaz n funcie de dimensiunea aplicaiei software, cerinele beneficiarului, complexitatea aplicaiei, precum i de calificarea personalului. S-au determinat cazurile de test pentru aplicaia e-DSI. Au fost identificate pentru testarea funcional 97 de cazuri de test a celor ase aplicaii componente integrate i un numr de 72 de cazuri la nivel de modul. Implementarea testelor permite echipei s evidenieze latura calitativ a proceselor derulate anterior i msura n care exist concordan ntre specificaiile aplicaiei informatice i aplicaia propriu-zis. Cheltuielile care apar n aceast faz privesc n special salariile personalului pentru activiti precum scrierea secvenelor i a programelor de test i redactarea documentaiei aferente. Prin reutilizarea testelor, cheltuielile din aceast faz se reduc, dar reutilizarea nu este ntotdeauna posibil. Rularea i evaluarea testelor sunt activitile prin intermediul crora se stabilete dac n program sunt erori. Cheltuielile din cadrul acestei faze sunt n general realizate pentru efortul generat de: iniializarea instrumentelor de test; la majoritatea instrumentelor, iniializarea se realizeaz doar la nceputul testelor; efectuarea testelor; nregistrarea rezultatelor testelor; elaborarea rapoartelor. Rularea testelor depinde de caracteristicile de performan a echipamentelor utilizate n cazul testrii automate. Testarea manual presupune costuri mai mari, deoarece timpul petrecut de personalul specializat n aceast activitate este mult mai mare. Efortul pentru evaluarea rezultatelor testelor este influenat de numrul de erori descoperite prin rularea testelor. Componentele care au euat n testare se trimit la echipa de dezvoltare pentru corectare. Dup identificarea cauzelor erorilor i efectuarea modificrilor corespunztoare, testarea se reia att pentru acele componente n care s-au descoperit erori, ct i pentru componentele care depind de ele, pentru a asigura c modificrile efectuate pentru corecia erorilor nu afecteaz comportamentul componentelor testate anterior i care au trecut testul. 98

Pentru aplicaia e-DSI, testele funcionale la nivelul ntregii aplicaii s-au realizat manual. Testarea la nivel de modul s-a realizat automat, prin intermediul instrumentelor de asistare. De asemenea, testarea de ncrcare i testarea de verificare a coninutului s-au realizat automat. S-a constatat [WINO00] c efortul exprimat n uniti de timp (ore) este aproximativ egal pentru testarea de modul, generarea documentelor de test i execuia testelor. Testarea vizeaz aspecte pariale i aspecte globale, n toate cazurile urmrindu-se stabilirea necesarului de corecii pentru a ajunge n final la un produs software operaional, tiut fiind faptul c din zece aplicaii ncepute, cel mult dou ajung la procesul de mentenan. Tabelul 4.3 Repartizarea efortului pe fazele procesului de testare a aplicaiei
Etapa de testare Efort Planificare Analiz i proiectare Implementare Rulare i evaluare teste Total

Personal Materiale Instrumente software Hardware Total Procesul de testare are un management propriu care vizeaz toate etapele ciclului de via a unui produs program. n tabelul 4.3 este prezentat un exemplu pentru nregistrarea efortului n testare n cadrul fazelor procesului de testare software. Pentru fiecare echip de testare este necesar s se efectueze nregistrri de consumuri i de performan pentru a putea obine la timp baza de date solicitat n procesul de estimare a coeficienilor pentru modelele de costuri ale testrii.

4.9 Ci de reducere a cheltuielilor de testare

Reducerea cheltuielilor pentru testare se realizeaz prin utilizarea de inspecii, automatizarea testrii, pregtirea personalului i reutilizarea cazurilor de test. n continuare sunt tratate distinct aceste aspecte. n anumite situaii, scderea costurilor cu testarea se realizeaz pe termen lung, pe termen scurt cheltuielile fiind mai mari dect beneficiile. De 99

exemplu, achiziionarea de instrumente performante de asistare a testrii sau instruirea personalului au costuri foarte mari i rezultatele acestor investiii nu se vd dect peste o anumit perioad de timp, mai mult sau mai puin ndeprtat. Reducerea cheltuielilor de testare se realizeaz n primul rnd prin folosirea tehnicilor de analiz static dup fiecare faz din ciclul de dezvoltare software i pentru fiecare rezultat obinut n fazele respective. n cazul n care inspeciile tehnice nu sunt utilizate n fazele anterioare testrii (sau se utilizeaz foarte puin), costurile testrii sunt mult mai mari dect n cazul utilizrii inspeciilor, dup cum se observ n figura 4.7.
Cdce MT momentul de nceput a testrii

Timp MT

Figura 4.7 Repartiia costurilor pentru detectarea i corectarea erorilor (Cdce) cnd nu sunt efectuate inspecii S-a constatat c prin utilizarea inspeciilor tehnice pentru toate rezultatele fazelor de dezvoltare software (analiz, proiectare, implementare) [MYER79], [PRES00] costul testrii s-a redus cu pn la 40% datorit descoperirii mai multor erori mai devreme n ciclul de dezvoltare, astfel nct n faza de testare propriu-zis, cnd codul surs este disponibil, numrul erorilor este redus i efortul de testare este mai mic (figura 4.8).

100

Cdce MT momentul de nceput a testrii

Timp MT

Figura 4.8 Repartiia costurilor pentru detectarea i corectarea erorilor (Cdce) cnd sunt efectuate inspecii

O modalitate important de reducere a cheltuielilor legate de testare o constituie automatizarea procesului de testare din cadrul organizaiei. n cazul automatizrii procesului de testare apar cheltuieli mari legate de achiziia de instrumente specifice testrii automate, precum i de instruirea personalului implicat n testare n scopul utilizrii optime a instrumentelor. n timp ns se constat o scdere a cheltuielilor de testare efectuate prin scderea efortului de testare. n [SILV02] este prezentat o situaie din care rezult avantajul mbuntirii procesului de testare prin automatizare (tabelul 4.4).

101

Tabelul 4.4 Beneficiile aduse de automatizarea testrii [SILV02] Procesul actual de testare Costul testrii Procentul de descoperire a erorilor Erori descoperite n testare Costul corectrii erorii dup testare (100 USD/eroare) Erori descoperite dup lansarea produsului Costul corectrii erorilor dup lansare (1000 USD/eroare) Costul total Beneficiul adus de procesul mbuntit de testare Investiia n noul proces de testare Rata beneficiului 10000 USD 70% 700 70000 USD 300 300000 USD Procesul mbuntit de testare 20000 USD 90% 900 90000 100 100000 USD

380000 USD 210000 USD 170000 USD 10000 USD 17 ori (1700%)

Certificarea personalului din testare prezint o serie de avantaje pentru cei care se certific, pentru angajator i pentru beneficiar. Reutilizarea testelor reprezint o alt modalitate important de scdere a costurilor asociate testrii software. n [McGR97] se propune o tehnologie de testare (PACT) prin care se creeaz o ierarhie de clase de test, realizat n paralel cu ierarhia claselor care se testeaz. De asemenea exist o serie de biblioteci de clase care se utilizeaz pentru testare (JUnit, CppUnit), prin care este posibil reutilizarea. i n cazul aplicaiei informatice de comer electronic e-DSI s-a urmrit reducerea cheltuielilor de testare prin: analiza specificaiilor i a designului aplicaiilor componente; colaborarea cu poteniali utilizatori ai aplicaiei; automatizarea testelor pentru testarea de modul, testarea de integrare, testarea de ncrcare pentru analiza funcionalitii aplicaiei; 102

reutilizarea unor teste; utilizarea de componente i secvene de cod care au fost deja testate. Reducerea cheltuielilor este posibil n msura n care procesul de testare se desfoar ntr-un cadru organizat i n care sunt msurate i nregistrate toate consumurile de resurse care au loc n timpul dezvoltrii software. n primul rnd se impune definirea ca obiectiv esenial crearea bazei de date care conine durate, consumuri i cheltuieli aferente proceselor de testare. Odat creat o astfel de baz de date, se includ combinaii de modele pentru software deja n uz.

103

5
MODELE LINIARE DE EVALUARE A COSTULUI TESTRII SOFTWARE (CTS)
5.1 Estimri i ipoteze n elaborarea modelelor liniare de evaluare a CTS
Modelele liniare pentru evaluarea costurilor testrii sunt elaborate pornind de la ipoteze de lucru simplificatoare, dar care nu simplific modelele i problema. Se utilizeaz astfel de modele pentru c sunt uor de construit, coeficienii se estimeaz cu metode pentru care exist produse software i proprietile lor permit efectuarea de analize complexe iar cazuistica verific ipotezele specifice liniaritii. Modelele i dovedesc utilitatea dac reflect dependene liniare ntre factorii exogeni i variabilele endogene din realitate pe cale experimental. Modelele liniare sunt unifactoriale, n cazul n care este o variabil exogen dominant i multifactoriale, atunci cnd n model sunt luate n calcul mai multe variabile exogene. Studierea legturii dintre variabila endogen y i variabila exogen x este folositoare la evaluarea variabilei y. Evaluarea se realizeaz prin ajustarea mulimii de puncte printr-o linie dreapt, aceasta fiind cunoscut sub denumirea de dreapt de regresie. Pentru estimarea coeficienilor modelului liniar se folosesc diferite metode, dintre care cea mai ntlnit este metoda celor mai mici ptrate (MCMMP). Prin MCMMP se estimeaz parametrii modelului liniar astfel nct suma ptratelor erorilor s fie minim. Exist i alte metode descrise n lucrri de econometrie [PECI94]: metoda verosimilitii maxime; scopul metodei este de a se ajunge la valoarea cea mai probabil pentru un parametru rezultat din datele descrise de ecuaia de regresie; metoda se utilizeaz n cazul n care modelele nu sunt liniarizabile sau 104

repartiia valorilor variabilei endogene n raport cu valorile variabilei exogene nu este normal; metoda variabilelor instrumentale; n cazul n care se constat existena de estimatori distorsionai i neconsisteni prin aplicarea MCMMP, se introduce o variabil instrumental cauzal n ecuaie, variabil corelat cu variabila explicativ iniial, dar necorelat cu variabila rezidual; parametrii noului model se determin aplicnd MCMMP; metoda punctelor empirice; metoda presupune alegerea de seturi de date din seria de observaii astfel nct acestea s nu fie influenate de abateri accidentale; pe baza setului de date restrns se determin parametrii modelului; metoda bayesian; pentru estimarea parametrilor se consider cunoscut legea de distribuie a acestora; n cazul n care legea de distribuie a parametrilor nu este cunoscut, metoda este inaplicabil; metoda grafic; presupune reprezentarea grafic a norului de puncte generat de perechile y i x din seria de date; prin reprezentarea grafic se aproximeaz parametrii i semnul acestora. Se consider un proces P care este influenat de factorul F. Pe baza datelor nregistrate privind evoluia n timp a variabilelor legate de procesul P(y) i factorul F(x) se construiete tabelul 5.1. Tabelul 5.1 nregistrarea valorilor factorului F pentru procesul P Y X y1 x11 y2 x12 yt x1t Pe baza nregistrrilor valorilor pentru Y i X se construiete diagrama de mprtiere care arat dac ntre cele dou variabile exist o legtur i dac aceast legtur poate fi considerat liniar. Astfel, pentru studierea dependenei liniare se realizeaz grafice corespunztoare nregistrrilor (figurile 5.1 i 5.2).

105

CTS

Figura 5.1 Corelaie pozitiv ntre costul testrii (CTS) i dimensiunea aplicaiei (D) exprimat prin numr linii surs

CTS

Figura 5.2 Corelaie negativ dintre costul testrii (CTS) i productivitate (W) Intensitatea legturii dintre cele dou variabile este msurat cu ajutorul coeficientului de corelaie. Coeficientul de corelaie dintre costul testrii software i dimensiunea aplicaiei exprimat ca numr de linii surs este dat de relaia:

106

rCTS / D =

cov(CTS , D )

D CTS

m Di CTS i Di CTS i
i =1 i =1 i =1

m 2 m m Di Di i =1 i =1

2 m m 2 m CTS i CTS i i 1 i =1

unde: cov(CTS,D) covariana dintre costul testrii software(CTS) i dimensiunea aplicaiei (D); CTS, D abaterea medie ptratic a lui CTS, respectiv D; m numrul de nregistrri; Coeficientul de corelaie ry/x ia valori n intervalul [-1,1] i aceste valori indic dac: legtura este liniar direct (1); legtura este liniar invers (-1); nu exist legtur (0). Cazul ryy/x>0 corespunde situaiei conform creia la o cretere a nivelului variabilei x se obine o cretere a variabilei y, iar cazul ry/x<0 corespunde situaiei conform creia la o cretere a nivelului variabilei x se obine o descretere a nivelului variabilei y. Utiliznd nregistrrile din capitolul 9, coeficientul de corelaie dintre costul testrii i dimensiunea aplicaiei este rCTS / D = 0.919 . Se observ existena unei legturi directe puternice de tip funcional ntre costul testrii i numrul de linii surs ale aplicaiei care se testeaz.

107

5.2 Dependene liniare unifactoriale identificate n testarea software

Se consider urmtorii factori care influeneaz testarea software: C D NM GO TD SC NU PS GN SA NI W LP GR Complexitatea produselor software Dimensiunea aplicaiei Numrul de module Gradul de omogenitate a echipei de realizare software Tehnicile de dezvoltare utilizate n realizarea produsului Stadiul de certificare a firmei Numrul utilizatorilor Existena de produse similare pe pia Gradul de noutate software i hardware Specificul aplicaiei software Numrul elemente de interfa Productivitatea personalului Limbajul de programare utilizat Gradul de reutilizare software

Pornind de la forma generic a modelului liniar cu o singur variabil:

y = ax + b

unde: y variabila endogen sau rezultativ; x variabila exogen sau factorial; se vor obine 14 modele liniare corespunztoare influenei unifactoriale, n care se regsesc rnd pe rnd factorii de influen prezentai n lista enumerativ de mai sus. Model bazat pe complexitatea ciclomatic a produsului software testat:

CTS = aC + b
Model bazat pe dimensiunea aplicaiei, exprimat n numr de linii surs fr comentarii sau n puncte funcionale:

CTS = aD + b
108

Model de evaluare a costului testrii software bazat pe numrul de module sau numrul de clase ale unei aplicaii:

CTS = aNM + b
Model liniar exprimat pe gradul de omogenitate a echipei care dezvolt aplicaia software:

CTS = aGO + b
Model bazat pe tehnicile de dezvoltare software utilizate n realizarea produsului:

CTS = aTD + b
n funcie de criterii specifice, se acord ponderi, ranguri sau note tehnicilor de dezvoltare software, iar valorile obinute pentru tehnicile utilizate se folosesc n modelele liniare. Exprimarea costului testrii software n funcie de stadiul de certificare a firmei conduce la modelul liniar de evaluare:

CTS = aSC + b
Stadiul de certificare a firmei se calculeaz n funcie de standardele aplicabile n domeniu i n funcie de nivelul de utilizare a acestora n cadrul firmei. Pe baza numrului utilizatorilor poteniali ai produsului software se construiete modelul liniar de evaluare a costului testrii:

CTS = aNU + b
Existena de produse similare pe pia conduce la realizarea modelului liniar unifactorial:

CTS = aPS + b
Modelul liniar de evaluare a costului testrii prin luarea n considerare a gradului de noutate software i hardware este:

109

CTS = aGN + b
Model liniar unifactorial de evaluare a costului testrii software n care variabila exogen este specificul aplicaiei software este:

CTS = aSA + b
Tipurile de aplicaii existente se cuantific n funcie de diverse criterii, iar valorile obinute sunt utilizate n modelele de evaluare a costului testrii. Prin luarea n calcul a numrului de elemente de interfa se obine modelul liniar de evaluare a costului testrii software:

CTS = aNI + b
Productivitatea personalului se reflect n costul testrii software. Modelul liniar de evaluare a costului testrii n funcie de productivitatea personalului este:

CTS = aW + b
Limbajul de programare utilizat st la baza urmtorului modelul liniar de evaluare a costului testrii software:

CTS = aLP + b
Fiecare limbaj de programare are elemente specifice, care influeneaz procesul de testare. n funcie de aceste elemente, limbajele de programare sunt cuantificate i n model sunt incluse valorile corespunztoare limbajelor utilizate. Modelul de evaluare a costului testrii n funcie de gradul de reutilizare software este:

CTS = aGR + b
Gradul de reutilizare se exprim ca fiind raportul dintre numrul de cazuri de test reutilizate i numrul total de cazuri de test. n funcie de nregistrrile disponibile pentru fiecare model, se estimeaz parametrii a i b prin metoda celor mai mici ptrate i printr-o analiz comparat se determin validitatea i calitatea fiecruia. 110

n capitolul 9 sunt prezentate estimrile coeficienilor a i b obinui n procesul de testare pentru aplicaia e-DSI.

5.3 Structuri de modele liniare multifactoriale pentru evaluarea CTS

n continuare este prezentat o serie de modele liniare multifactoriale pentru evaluarea costului testrii software. Forma analitic a modelului liniar cu 14 factori pentru evaluarea costului testrii este:
CTS = a 0 + a i xi
i =1 14

unde: x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 ai complexitatea produselor software; dimensiunea aplicaiei; numrul de module; gradul de omogenitate a echipei de realizare software; tehnicile de dezvoltare utilizate n realizarea produsului; stadiul de certificare a firmei; numrul utilizatorilor; existena de produse similare pe pia; gradul de noutate software i hardware; specificul aplicaiei software; numrul elemente de interfa; productivitatea personalului; limbajul de programare utilizat; gradul de reutilizare software; coeficienii modelului care trebuie estimai (i=0, 14).

Estimarea parametrilor modelului liniar de evaluare a costului testrii cu 14 variabile se realizeaz cu metoda celor mai mici ptrate. Modelul bazat pe eficiena echipei de testare are n vedere corelaia dintre costul testrii i eficiena echipei de testare. Eficiena (EF) echipei de testare este dat de raportul:
EF = 1 Ni

111

unde Ni reprezint lungimea procesului de testare ca numr de iteraii. Se observ c eficiena echipei de testare crete o dat cu scderea numrului de iteraii.
Erori

Ni

Figura 5.3 Evoluia erorilor de la o iteraie la alta Se consider un program P care este testat ntr-un numr de iteraii. Graficul care red evoluia erorilor de la o iteraie la alta este descresctor, reprezentat prin hiperbol (figura 5.3). n ipoteza identificrii a trei factori de influen, costul testrii se estimeaz cu un model multi-parametric [IVAN99] de forma:

CTS = f (EF , C , TS )
unde: EF eficiena echipei; C complexitatea programului de testat; TS tehnica i instrumentele de testare. Eficiena testrii este dat de: durata procesului; numrul de iteraii necesar pentru a evidenia integral comportamentul produsului; concordana ntre rezultatul testrii i situaia real a produsului (un produs bun este refuzat dup testare sau un produs slab este acceptat dup testare). Forma analitic a dependenei difer de la un sistem de ipoteze la altul care se adopt atunci cnd se procedeaz la efectuarea estimrilor. Se iau n calcul att datele existente, ct i caracterul operaional care se dorete a fi obinut. 112

Este preferabil s se construiasc tabele cu coeficienii obinui pentru fiecare sistem de ipoteze i clase de complexitate a programelor pentru a fi utilizai la estimri mai nuanate ale costurilor testrii. Durata testrii i rezultatele, precum i resursele angrenate depind de complexitatea produsului program. Acest model multi-parametric poate fi extins prin luarea n calcul a unei game mai mari de factori care influeneaz costul testrii. Aceti factori sunt: dimensiunea aplicaiei software; gradul de pregtire i experiena programatorilor; metodologia de analiz, proiectare i programare; instrumentele utilizate pentru dezvoltare; specificaiile de programare; certificarea productorului. Pentru fiecare factor este necesar s se stabileasc modalitatea de comensurare a cheltuielilor i importana factorului n obinerea calitii produsului. Dac se consider c testarea are ca obiectiv evidenierea calitii produsului software i nu a non-calitii, aceti factori sunt cuantificai avnd n vedere aportul lor la realizarea calitii iar testarea evideniaz msura n care ei contribuie efectiv la procesul de obinere a calitii. Modelul bazat pe elemente de structur a programelor ia n considerare elemente de structur a programelor, precum: numrul de module (NM); lungimea programului (D); durata de realizare (T). Modelul pentru evaluarea costului testrii este: CTS = a 0 + a 1 NM + a 2 D + a 3T unde a0, a1, a2 i a3 sunt coeficieni care urmeaz a fi determinai printr-o metod de estimare specific modelelor liniare. Modelul liniar al cheltuielilor de testare bazat pe structura resurselor ia n considerare cheltuielile din procesul de testare pe baza destinaiei acestora. Astfel, n cadrul procesului de testare se identific urmtoarele categorii de cheltuieli: cheltuieli cu personalul; cheltuieli de asistare; cheltuieli pentru echipamente; 113

 alte cheltuieli specifice procesului de testare. Modul de obinere al costului testrii software, este dat de relaia : CTS = a 0 + a1C p + a 2 C e + a 3 C i + a 4 C a unde: Cp - cheltuieli cu personalul; Ce - cheltuieli pentru echipamente; Ci - cheltuieli pentru instrumente de asistare; Ca - alte cheltuieli; ai, i=0,4 coeficienii modelului care urmeaz a fi estimai. n practic, fiecare categorie de cheltuieli se difereniaz prin importana pe care aceasta o are n cadrul cheltuielilor totale. Ponderea cea mai mare o au cheltuielile cu personalul, celelalte cheltuieli avnd o pondere mai mic. Modelul bazat pe structura ierarhizat a procesului de testare are n vedere contorizarea cheltuielile aprute n cadrul procesului de testare, prin prisma nivelurilor testrii. Se pornete de la testarea de modul, urmeaz testarea de integrare, testarea de sistem i n cele din urm are loc testarea de validare. Fiecare nivel are la baz elemente realizate n cadrul celorlalte faze ale ciclului de dezvoltare software. n figura 5.4 este prezentat corespondena dintre fazele ciclului de dezvoltare software i nivelurile testrii.
Specificare cerine Testare de validare

Analiz

Testare de sistem

Proiectare ansamblu

Testare de integrare

Proiectare de detaliu

Testare de modul

Implementare

Figura 5.4 Corespondena dintre fazele ciclului de dezvoltare software i procesul de testare

114

n cadrul fiecrui nivel de testare verificarea aplicaiei software se realizeaz pe baza rezultatelor specifice provenind de la nivelul corespunztor din ciclul de dezvoltare software. Astfel, testarea de modul se realizeaz avnd codul surs obinut n faza de implementare pe baza proiectului de detaliu care rezult din faza de proiectare detaliat, testarea de integrare are la baz arhitectura aplicaiei, dezvoltat n faza de proiectare, testarea de sistem se realizeaz pe baza rezultatelor analizei, iar testarea de validare se face avnd n vedere cerinele utilizatorului. Costul total efectiv al testrii (CTTE) este dat de suma tuturor cheltuielilor efectuate la fiecare nivel al testrii: modul, integrare, sistem i validare. Astfel, rezult formula: CTTE = Ctm + C ti + C ts + Ctv unde: Ctm - Cheltuieli pentru testarea de modul; Cti - Cheltuieli pentru testarea de integrare; Cts - Cheltuieli pentru testarea de sistem; Ctv - Cheltuieli pentru testarea de validare. Costul total evaluat este: CTS = a 0 + a1C tm + a 2 C ti + a3 C ts + a 4 C tv unde a0, a1, a2, a3 i a4 se estimeaz pe baza costurilor agregate nregistrate Ctm, Cti, Cts i Ctv. n funcie de o serie de factori cum ar fi complexitatea aplicaiei, dimensiunea rezultatelor specifice fiecrei etape a ciclului de dezvoltare software etc., fiecare categorie de cheltuieli are o pondere diferit n totalul cheltuielilor. Avnd n vedere c exist mai multe module, costul testrii de module este dat de suma costului testrii fiecrui modul n parte. Astfel rezult costul total efectiv al testrii modulelor:
C tm = ctmi
i =1 n

unde: ctmi - costul testrii modulului i; n - numrul total de module de testat.

115

Tabelul 5.2 Repartizarea costului testrii pe module i metode de testare Modulul 1 Modulul j Modulul Total n Metoda de testare 1 n Metoda de cij cij testare i
j

Metoda de testare m Total

c
i

ij

c
i j

ij

Costul testrii modulelor poate fi redus prin reutilizarea testelor. Reutilizarea testelor este posibil n cazul n care aceleai teste sau categorii de teste sunt aplicabile mai multor module, fr a fi necesar rescrierea testelor sau prin efectuarea de modificri minore. Fiecare modul sau clas se testeaz utiliznd metode de testare specifice, care pot diferi de la un modul la altul. Astfel, pentru fiecare component n parte se determin metoda de testare utilizat, o aceeai metod de testare putnd fi utilizat la o serie de module. Aceasta se poate exprima ntr-o form matriceal (tabelul 5.2). n tabelul 5.2, valoarea cij reprezint costul testrii modulului j prin utilizarea metodei de testare i. n cazul n care pentru modulul j nu s-a utilizat metoda de testare i, atunci valoarea lui cij este zero. Din matricea corespondenelor dintre metodele de testare utilizate i modulele testate se identific urmtoarele categorii de costuri: costul testrii modulului j utiliznd metoda de testare i; costul testrii unui modul, utiliznd anumite metode de testare; costul testrii prin utilizarea unei anumite metode de testare. Costul total efectiv al testrii tuturor modulelor este dat de relaia:

Ctm = cij
i j

Avnd n vedere acest lucru, cheltuielile pentru testarea unui modul se pot defini ca sum a utilizrii metodei de testare. 116

Testarea fiind un proces iterativ, costurile testrii se nregistreaz pentru fiecare iteraie n parte:
CTTE = CTi
i =1 n

unde: CTTE costul total efectiv al testrii; CTi costul testrii la iteraia i; n numrul total al iteraiilor. Numrul total al iteraiilor efectuate variaz n funcie de o multitudine de factori, cum ar fi: numrul de erori descoperite n cadrul procesului de testare; n mod normal, acest numr ar trebui s scad de la o iteraie la alta; calitatea cu care aceste erori sunt corectate; acest lucru depinde de pregtirea personalului implicat n dezvoltarea aplicaiei; complexitatea aplicaiei; o complexitate ridicat a aplicaiei face ca procesul de testare s necesite un efort mai mare; productivitatea i eficiena programatorilor; constituie un factor important n derularea procesului de testare, o eficien sczut a acestora conducnd la noi iteraii n testare; bugetul alocat pentru testare; n funcie de dimensiunile acestuia se programeaz toate activitile de testare; un buget sczut conduce la un proces de testare de durat mai mic, ns acest lucru se va reflecta asupra fiabilitii produsului software obinut. Pe baza datelor culese despre proiectele realizate se stabilesc msuri pentru eficientizarea procesului de testare i scderea numrului de iteraii, ceea ce va duce la scderea cheltuielilor efectuate n procesul de testare. Modelul de evaluare bazat pe etapele testrii din ciclul de dezvoltare software ia n considerare cheltuielile efectuate n fazele procesului de testare. n procesul de testare se identific urmtoarele etape: planificarea procesului de testare; analiza i proiectarea testelor; implementarea testelor; execuia testelor i evaluarea rezultatelor testelor. Pentru fiecare etap este necesar s se scrie documentaia specific, ceea ce conduce la identificarea unor surse de cheltuieli. Cheltuielile de testare rezultate lund n calcul fazele procesului de testare conduc la modelul: CTS = a 0 + a1C pt + a 2 C ap + a 3 C it + a 4 C ee 117

unde: Cpt Cheltuieli pentru planificarea testrii; Cap Cheltuieli pentru analiza i proiectarea testelor; Cit Cheltuieli pentru implementarea testelor; Cee Cheltuieli pentru execuia i evaluarea testelor. ai, i=0,4 coeficienii modelului care urmeaz a fi estimai. Toate modelele prezentate necesit serii de date suficient de mari pentru a asigura stabilitatea coeficienilor estimai din ecuaiile de regresie. Coeficienii au caracter local fiind diferii de la un productor de software la altul. Pentru un productor de software se extrag din evidenele curente date privind: complexitatea programelor realizate; dimensiunea programelor; numrul de persoane care au lucrat la aceste programe; duratele testrilor pentru fiecare program; cheltuielile efectuate pentru ntreinerea programelor dup ce acestea au fost date n exploatare; costurile programelor; numrul de erori descoperite. Pentru realizarea estimrilor parametrilor sunt necesare instrumente statistice pentru determinarea coeficienilor ecuaiilor, pentru reprezentri grafice care preiau datele stocate de ctre firm din bazele de date ale acesteia. La ora actual exist o serie de aplicaii software care pot fi utilizate pentru estimarea parametrilor (de exemplu SPSS, Statistica, Excel etc.).

5.4 Analiza calitii modelelor liniare de evaluare a CTS

Se consider o serie de modele liniare M1, M2, , Mm utilizate pentru evaluarea costurilor testrii software. Pe baza evalurilor pentru costurile testrii, utiliznd modelele liniare considerate, pentru t programe P1, P2, , Pt, se ntocmete tabelul 5.4, unde ij reprezint costul testrii programului Pj evaluat cu modelul Mi.

118

Tabelul 5.3 Costurile evaluate n funcie de complexitatea programului Pj Pt Program P1 P2 Model M1 M2 Mi ij Mm n momentul n care se procedeaz la testarea efectiv, pe baza datelor obinute se construiete tabelul 5.4. Tabelul 5.4 Costurile efective ale testrii programelor Program Cost efectiv P1 y1 P2 y2 Pj yj Pt yt Se calculeaz diferenele dintre costul efectiv i costul obinut prin evaluare pentru fiecare model Mi i pentru fiecare program Pj:
ij =| y ij y j |

i se construiete matricea diferenelor, tabelul 5.5. Tabelul 5.5 Matricea diferenelor abaterilor Program P1 P2 Pj Model M1 M2 Mi ij Mm Pt

119

Pe baza diferenelor ij din matricea diferenelor se calculeaz indicatorul:

=
unde:

j =1

ij

ij = 0 dac ij > ij = 1 dac ij

Se consider limita acceptabil a diferenelor, iar a i b [0, 1] , a<b, limitele intervalului de ncredere pentru reprezentativitatea modelelor de evaluare, alese pe baze experimentale. Dac [a, b] se accept modelul liniar i se consider c modelele sunt bune. Dac [a, b] se elimin modelul cu cele mai multe valori zero pe linie. Dac va exista apartenena [a, b] , atunci se consider c aceast clas este reprezentativ i procedeul continu.

5.5 Rafinarea modelelor liniare de evaluare a CTS

Au fost identificai foarte muli factori care influeneaz efortul de testare a produselor software. Este dificil s se lucreze cu modele avnd un numr att de mare de factori, de aceea este necesar rafinarea modelelor. Se consider modelul liniar:
Y1 = a 0 + ai xi
i =1 n

unde: Y1 variabila dependent; ai coeficienii estimai, i=0, n; xi variabila independent care corespunde factorului Fi, i=1, n. Studiul calitativ al dependenelor factorilor F1, F2, Fn conduce la construirea de modele liniare reprezentative cu ajutorul crora se evalueaz fie evoluia unor fenomene, fie nivelurile unor parametri, pentru 120

fundamentarea deciziilor sau pentru planificarea resurselor sau fondurilor necesare pentru achiziionarea acestora. Cu ct n (numrul de factori luai n considerare este mai mare) crete, se modific n sens pozitiv i calitatea modelului i reprezentativitatea acestuia. Dac modelele M1 i M2 nu difer semnificativ, dar numrul de variabile ale modelului M1 este mai mic dect numrul de variabile ale modelului M2, rezult c modelul M1 este o rafinare a modelului M2. n procesele de dezvoltare software factorii care influeneaz procesul de testare sunt numeroi i instrumentele cu care se dezvolt produsele software culeg automat date privind consumurile de resurse, comportamentul dezvoltatorului i permit efectuarea de msurri asupra fiecrui stadiu parcurs i a fiecrui modul. Bazele de date care se construiesc automat n procesul de dezvoltare software sunt deosebit de complexe i conin foarte multe date care satisfac prin numrul lor orice structur de model liniar. Problema rafinrii modelului liniar a avut la baz timp de muli ani necesitatea de a reduce efortul culegerii datelor pentru construirea seriilor de date aferente celor n factori de influen. Rafinarea modelului revine la a reduce numrul de factori de la n la p, cu p mult mai mic dect n, astfel nct modelul

Y2 = a 0 + bi xi
i =1

s conduc la obinerea unor erori de reprezentativitate acceptabile, astfel nct suma ptratelor erorilor pentru modelul extins:
S1 = (Y1i Yi ) 2
i =1 n

i suma ptratelor erorilor pentru modelul rafinat:

S 2 = (Y2i Yi ) 2
i =1

s nu difere semnificativ, unde: Y1i nivelul calculat al variabilei dependente la momentul i a modelului extins; Y2i nivelul calculat al variabilei dependente la momentul i a modelului rafinat; Yi nivelul efectiv al variabilei dependente la momentul i; Pentru rafinare este folosit analiza factorial. Principiul este de a lua factorii F1, F2, , Fn i de a calcula ponderile cu care acetia particip n 121

model. Experiena arat c apar i aspecte calitative n ceea ce privete importana factorilor. De aceea, trebuie o tratare difereniat i trebuie construite structuri de modele. Paii procesului de rafinare sunt: Pasul 1: Se genereaz modelele cu o singur variabil, de forma Yi = axi + b ; fiind n modele se calculeaz n sume de forma

S i = (Yij Y j ) 2 , unde k este numrul de momente de timp,

j =1

reprezentnd lungimea seriei de date. Se ordoneaz aceste sume i se aleg dintre ele acelea cu valorile cele mai mici. Se compar cu suma S obinut pentru modelul cu n variabile i se utilizeaz testul de egalitate a dispersiilor. Pasul2: Se genereaz modelele cu dou variabile, de forma 2 Yij = axi + bx j + c ; sunt C n modele i se calculeaz tot attea sume

S i = (Yij Y j ) 2 , k este de asemenea numrul de momente de

j =1

timp. n mod asemntor se ordoneaz aceste sume i se aleg dintre ele acelea cu valorile cele mai mici. Pasul 3: Procedeul continu pn la modelele cu n-1 variabile. Pe cale experiment se stabilete numrul p al variabilelor modelului rafinat. n modelele liniare comutativitatea factorilor determin lucrul cu combinri. Fie S suma ptratelor erorilor pentru modelul extins cu n variabile i n M1 modelul care are toi cei n factori. Se construiesc C n 1 modele cu n-1 factori: M11, M12, M1n. Se calculeaz i sumele corespunztoare acestor modele, obinndu-se S11, S12, , S1n. Se compar sumele rezultate cu S i rezult c pot fi reinute un numr de q1 modele care au dispersiile identice. Procesul se repet pentru n-2 factori, n-3 factori, , n-k factori. Dac pentru n-k-1 factori nici una dintre sume nu respect criteriul, atunci rezult c procesul de rafinare s-a ncheiat i numrul de modele obinute prin rafinare este q = qi .
i =1 nk

Pentru implementarea algoritmului se construiete: o matrice X cu n coloane corespunztoare celor n factori i k linii corespunztoare momentelor de timp pentru care s-au fcut nregistrrile; un vector Y cu k componente, corespunztoare datelor nregistrate pentru variabila dependent; 122

un vector A cu n+1 componente reprezentnd coeficienii care se vor estima pentru cei n factori i termenul liber; o procedur care are ca parametri X, Y, A i S; prin utilizarea metodei celor mai mici ptrate se obin valorile din A; n S se memoreaz suma ptratelor de diferene dintre Y i calculat. o procedur pentru obinerea matricei X care are k linii i numr variabil de coloane iniializate, maxim n; procedura primete ca parametri pe X i un vector Z de n componente ale crui elemente au valorile 0 sau 1; scopul este de a copia n X consecutiv numai coloanele din X pentru care elementele corespunztoare din Z au valoarea 1; lucrul cu aceste dou proceduri d posibilitatea de a genera combinaiile i de a realiza estimrile; pentru varianta iniial toate componentele lui Z sunt 1; pentru modelele cu n-1 componente, ntr-o secven repetitiv Zi este iniializat cu 0 i deci X n secvena repetitiv respectiv genereaz toate combinaiile. Se consider modelul:
y = a 0 + ai xi
i =1 n

unde xi reprezint variabila asociat factorului Fi. Se construiesc 2n-1 modele pornind de la modelul liniar cu o singur variabil pn la modelul liniar cu n variabile. Se construiete tabelul 5.6. Tabelul 5.6 nregistrarea valorilor reale i a estimaiilor modelelor Valoarea Modelul 1 Modelul 2 Modelul k Modelul 2n-1 real Y 1 2 k Y2n-1 y1 1 1 21 k 1 2n-11 y2 12 22 k2 2n-12 yl 1l 2l kl 2n-1l ym 1m 2m km 2n-1m Se calculeaz diferenele dintre valorile obinute pe baza estimaiilor i valorile reale ale lui y (tabelul 5.7). Pentru fiecare model n parte se nsumeaz diferenele obinute.

123

Tabelul 5.7 Diferenele dintre estimaii i valorile reale M2 Mj M2n-1 M1 (y-11)2 (y-11)2 (y-j1)2 (y-2n-11)2 (y-12)2 (y-12)2 (y-j2)2 (y-2n-12)2 2 2 2 (y-1i) (y-2i) (y-ji) (y-2n-1i)2 2 2 2 (y-1t) (y-2t) (y-jt) (y-2n-1t)2 S1 S2 Sk S2n-1 Se ordoneaz sumele ptratelor erorilor de la Smin la Smax. Se determin raia r ca fiind raportul: unde u se alege n funcie de nivelul de precizie dorit. Pe baza raiei r obinut, sunt selectate acele modele care au suma ptratelor erorilor mai mic dect aceast valoare r.

5.6 Stabilitatea modelelor liniare de evaluare a CTS

Stabilitatea modelelor are n vedere comportamentul modelelor pe eantioane de date diferite. Se consider q eantioane de date referitoare la aceleai caracteristici. Se construiesc q tabele de forma tabelului 5.8. n tabel, Y reprezint costurile efective ale testrii, M valorile evaluate ale costului testrii i S sunt diferenele ridicate la ptrat dintre valorile evaluate i valorile efective ale costului testrii. Prin ordonarea cresctoare a sumelor, fiecrui model i se va asocia un rang pentru fiecare eantion n parte. Centraliznd rangurile obinute pentru toate eantioanele se construiete matricea rangurilor (tabelul 5.9). Tabelul 5.8 Centralizarea caracteristicilor i modelelor pentru un eantion M2 Mm S1 S2 Sm Y M1 y1 y2 ym 124

S1 S2 Si Sm

Eantion 1 r11 r21 ri1 rm1

Tabelul 5.9 Matricea rangurilor Eantion 2 Eantion j r12 r1j r22 r2j ri2 rij rm2 rmj

Eantion q r1q r2q riq rmq

Stabilitatea modelelor se determin utiliznd una din urmtoarele variante luate n considerare. Varianta v1 Se aleg primele p ranguri din fiecare eantion. Rezult q mulimi a cte p modele. Se efectueaz intersecia celor q mulimi de modele. MS = MM 1 MM 2 ... MM q Mulimea MS obinut conine modelele de evaluare care au stabilitatea cea mai ridicat. Varianta v2 Se calculeaz suma rangurilor pentru fiecare model n parte din matricea rangurilor: SRi = rij
j =1 q

Se ordoneaz cresctor dup sumele SRi obinute. Se rein primele p modele considerate a fi stabile. Varianta v3 Se calculeaz raportul dintre suma rangurilor i numrul de eantioane:
R=

r
i =1 j =1

ij

qm Se aleg modelele pentru care media rangurilor este mai mic dect valoarea medie obinut ( R ). Modul n care este ales numrul p depinde de mai muli factori i de specificul modelelor i a condiiilor n care au fost realizate evalurile i s-a efectuat culegerea datelor. Se obine un grup de modele i n faza de analiz se alege unul. Periodic se procedeaz la extinderea coeficienilor pentru a ncorpora modificrile influenei factorilor. n mod asemntor se determin stabilitatea modelelor obinute prin rafinare, prin eliminarea de variabile.

125

6
MODELE NELINIARE ALE COSTULUI PROCESULUI DE TESTARE SOFTWARE
6.1 Condiii specifice pentru elaborarea modelelor neliniare de evaluare a CTS
Realitatea arat c sunt puini factorii care influeneaz liniar i uniform nivelul costului testrii. Cei mai muli factori influeneaz neliniar i difereniat pe intervale volumul cheltuielilor i, implicit, costul final al procesului de testare. Dependenele liniare sunt numai cazuri particulare. Sa constat faptul c evoluia costului aplicaiei software n funcie de dimensiunea acesteia crete neliniar i, de aceea, majoritatea modelelor de evaluare a costurilor se bazeaz pe dependene neliniare. Modelele de evaluare sunt de dou tipuri [FENT96]: modele de cost care furnizeaz o evaluare direct a efortului sau a duratei; modele de restricii, care demonstreaz relaia n timp ntre doi sau mai muli parametri de efort, durat sau nivelul personalului. Dac se consider ipoteza conform creia costul testrii este influenat de patru factori: C W T D nivelul complexitii modulelor; productivitatea muncii; durata necesar dezvoltrii produsului; dimensiunea aplicaiei,

a construi un model neliniar revine la a identifica forma analitic a funciei:

CTS = f(C, W, T, D)

126

Pentru estimarea parametrilor modelelor neliniare se utilizeaz metoda celor mai mici ptrate, dup ce n prealabil modelul a fost liniarizat folosind fie logaritmarea, fie nlocuirea de variabile. n literatura de specialitate [GEOR97], [PECI93], [PECI02] sunt descrise modelele neliniare uni i multifactoriale, precum i modalitile de estimare a parametrilor acestora. n [DU73] sunt descrise formele analitice pentru o serie de funcii neliniare.

6.2 Modelul polinomial al evalurii costului testrii

Forma analitic a modelului polinomial general este:
y = a 0 + ai x i
i =1 n

unde: y variabila endogen; x variabila exogen; a0, a1, , an coeficienii modelului, care urmeaz s fie estimai. Modelul cel mai utilizat este pentru n=2, caz n care modelul polinomial este descris de funcia de gradul doi: y = ax 2 + bx + c Reprezentarea grafic indic o parabol (figura 6.1).
y

Figura 6.1 Evoluia dup o funcie polinomial de gradul doi 127

Modelul polinomial de evaluare a costului testrii software se construiete pe baza factorului timp, dup funcia:
CTS = aT 2 + bT + c

Evoluia n timp a costului dezvoltrii unui produs software este redat n figura 6.2, unde este indicat perioada de timp specific testrii software.

Cost (P/L)

CTS

Testare T
Figura 6.2 Evoluia n timp a costului produsului software Modelul polinomial al costului testrii software n funcie de dimensiunea aplicaiei este date de relaia:
CTS = aD 2 + bD + c

Pentru estimarea parametrilor modelului polinomial se liniarizeaz ecuaia funciei, aplicnd la modelul liniar obinut metoda celor mai mici ptrate.

6.3 Modelul produs de evaluare a CTS

Forma analitic a funciei produs este dat de expresia:
y = a x x ...x
a1 0 1 a2 2 an n

= a 0 xiai
i =1

unde: y variabila endogen; x1, , xn variabile exogen; a0, a1, , an coeficieni care urmeaz a fi estimai. 128

Funciile de producie sunt exprimate de modelul: y = Ax a y b z c Modelul de evaluare a costului testrii software n funcie de dimensiunea produsului software este:
CTS = a + bD c

unde: D dimensiunea produsului software exprimat n numr linii surs sau puncte funcionale; a, b i c parametrii modelului. O serie de modele pentru estimare a costurilor (cum ar fi COCOMO, COCOMO II [BOEH00], Wolverton) utilizeaz funcia de cost de forma:
CTS = aD b

de unde se deduce costul testrii n procesul de dezvoltare software. Reprezentarea grafic a funciei de cost este n figura 6.3.
CTS

Figura 6.3 Evoluia costului testrii CTS dup o funcie produs Estimarea parametrilor modelului se realizeaz aplicnd metoda celor mai mici ptrate funciei liniarizate. Liniarizarea se face prin logaritmare:
lg CTS = lg a + b lg D

129

Se fac urmtoarele notaii:

x = lg D a ' = lg a y = lg CTS

i se obine modelul liniar:

y = a '+bx

ai crui parametri se estimeaz utiliznd metoda celor mai mici ptrate. a' Parametrul a se obine din a = 10 .

6.4 Modelul exponenial de evaluare a CTS

Modelul exponenial are una din formele: y = ke ax +b sau y = ae bx sau y = ab x Nivelul costului testrii n funcie de complexitatea produsului software este exprimat printr-o funcie exponenial de forma:
CTS = ke aC + b

unde: C complexitatea programului; a, b coeficieni care trebuie estimai; k constant.

130

Graficul funciei exponeniale este redat n figura 6.4.

CTS

Figura 6.4 Evoluia costului testrii n funcie de complexitatea software Pentru estimarea coeficienilor, se liniarizeaz funcia prin logaritmare obinndu-se forma:

ln CTS = aC + b + ln k
Parametrii modelului liniar obinut sunt estimai folosind metoda celor mai mici ptrate.

6.5 Modelul logaritmic de evaluare a CTS

Forma analitic a modelului logaritmic este:
ln y = a + b ln x

reprezentarea grafic fiind dat n figura 6.5.

131

Figura 6.5 Evoluia dup o funcie logaritmic Estimarea coeficienilor a i b se realizeaz utiliznd metoda celor mai mici ptrate, aplicat modelului obinut prin liniarizare. Notnd cu y'= lny i x' = lnx se obine modelul liniar unifactorial:
y ' = a + bx '

ai crui parametri a i b se estimeaz cu ajutorul metodei celor mai mici ptrate. Dup obinerea estimrilor pentru a i b, acestea se transform pentru funcia iniial. Modelul de evaluare a costului testrii software n funcie de dimensiunea aplicaiei, pe baza funciei semi-log, este dat de:

CTS = a + b ln D
Graficul funciei este dat n figura 6.6.

CTS

Figura 6.6 Evoluia costului dup funcia semi-log

132

Utiliznd funcia log-invers, costul testrii software n funcie de productivitate muncii este: b ln CTS = a + W 1 Efectund substituirile y = ln CTS i x = se obine modelul liniar W y = a + bx ai crui parametri se estimeaz utiliznd MCMMP. Funcia log-log-invers conduce la obinerea modelului neliniar:
b + c ln W W Prin liniarizarea modelelor neliniare se estimeaz parametrii acestora utiliznd metoda celor mai mici ptrate.
ln CTS = a +

6.6 Modelul hiperbolic de evaluare a CTS

Un alt model neliniar este cel exprimat prin funcia invers (sau hiperbolic):
1 x a crei reprezentare grafic este prezentat n figura 6.7.

y = a+b

b>0 a b<0 x
Figura 6.7 Graficul funciei inverse

133

Costul testrii software (CTS) are o legtur neliniar invers n raport cu productivitatea muncii (W) dat de relaia:
CTS = a + b
1 W

Evoluia costului testrii software n raport cu productivitatea muncii este redat grafic n figura 6.8.

CTS

W
Figura 6.8 Evoluia costului testrii CTS n raport cu productivitatea muncii W Estimarea parametrilor a i b se realizeaz dup liniarizarea 1 z= x . Modelul liniar obinut este modelului prin efectuarea substituirii y = a + bz .

6.7 Alte modele neliniare de evaluare a CTS

Modelul neliniar de evaluare a costului utiliznd funcia Prais exprim costul testrii software n raport cu complexitatea aplicaiei.
CTS = e
a b C

134

Modulul neliniar bazat pe funcia Johnson:

CTS = e
k a b+C

Estimarea parametrilor se face prin liniarizare. Se logaritmeaz funcia i se obine: C ln CTS = b ln CTS + kC + bk a Se noteaz:

y = C ln CTS z = ln CTS d = bk a i se obine sistemul liniar:

y = bz + kC + d

ai crui coeficieni se determin prin metoda celor mai mici ptrate. Coeficientul a se determin din relaia a = bk d . Exprimarea costului testrii software n funcie de complexitatea software prin funcia log-parabolic conduce la modelul neliniar: CTS = a(ln C ) + b ln C + c Utilizarea funciei logistice pentru evaluarea costului testrii software n funcie de dimensiunea produsului informatic, exprimat ca numr de linii surs, conduce la modelul neliniar avnd forma analitic dat de: k CTS = 1 + be aD Graficul funciei logistice, prezentat n figura 6.9, are forma literei S.

135

CTS

D
Figura 6.9 Evoluia costului testrii CTS dup funcia logistic

Prin logaritmare se obine modelul liniar:

ln(

k 1) = ln b aD CTS

Se fac notaiile y = ln(

k 1) i d = ln b obinndu-se modelul liniar CTS y = d aD , ai crui parametri se determin cu metoda celor mai mici ptrate. Funcia logistic ptratic conduce la obinerea modulului neliniar de evaluare a costului testrii: k2 CTS = (1 + be aC ) 2 Se logaritmeaz i se obine modelul liniar:

ln( k

k CTS

1) = ln b aC

Se fac notaiile y = ln(

1) i d = ln b obinndu-se modelul liniar CTS y = d aC , coeficienii determinndu-se prin metoda celor mai mici ptrate, asemntor modelelor anterioare. Pentru toate modelele neliniare, prin liniarizarea funciilor i prin efectuarea de substituiri, aplicnd metoda celor mai mici ptrate, se
136

estimeaz parametrii. Modelele obinute cu parametrii estimai vor fi evaluate prin efectuare unei analize comparate.

6.8 Analiza comparat a modelelor neliniare

n funcie de datele obinute i de analizele care se efectueaz, pentru evaluarea costului testrii software se asociaz rnd pe rnd modele polinomiale, logaritmice i exponeniale. Se consider o mulime de forme analitice neliniare de forma yj=fj(X), j=1,m, unde X reprezint vectorul de factori pe baza crora se calculeaz costul testrii. Se caut identificarea formei analitice care ofer abaterile cele mai mici.
Tabelul 6.1 Costul testrii exprimat de funcii neliniare f2(X) fj(X) fm(X) Cost efectiv f1(X) y1 y2 yi y ij yn

n tabelul 6.1 se nregistreaz pentru fiecare model n parte, pentru n funcie de setul de date utilizate: yi valoarea efectiv a costului testrii;
y ij valoarea evaluat cu modelul fj.

Tabelul 6.2 Determinarea sumei ptratelor abaterilor modelor neliniare Cost efectiv Cost evaluat Diferena Ptrate diferene (y) () (e=y - ) (e2) y1 y1j y1 y1j (yj - y1j )2 y2 y 2j y 2 y 2j (yj - y 2j )2

yi yn TOTAL

y ij y nj

y i y ij y n y nj

(yj - y ij )2 (yj - y nj )2 ej
137

n tabelul 6.2 se nregistreaz suma ptratelor diferenele dintre valorile efective ale costului testrii software i valorile evaluate folosind cele m modele de evaluare a costului pentru fiecare model n parte:
e j = ( y i y ij ) 2
i =1 n

Dintre sumele calculate se va alege ek astfel nct ek = min{e j } . Va

1 j m

rezulta c modelul fk pentru care s-a identificat valoarea minim ek este cel mai bun pentru setul de date considerat. Este posibil automatizarea acestui procedeu de pentru analiza comparat a modelelor neliniare. n acest sens sunt necesare: o matrice A n care se memoreaz costurile evaluate cu cele m modele i costurile efective pentru cele n serii de date; o matrice B n care se calculeaz ptratele abaterilor; o procedur care pe baza matricei A completeaz matricea B i determin ierarhia de modele. Pentru a realiza analiza comparat a modelelor neliniare trebuie ca acestea s utilizeze aceeai factori i sunt necesare aceleai seturi de date.

6.9 Rafinarea modelelor neliniare de evaluare a CTS

Rafinarea modelelor neliniare se realizeaz prin eliminarea de monoame, de subexpresii sau prin trecerea la expresii analitice mai simple n scopul simplificrii modelului i a procesului de culegere a informaiilor pentru evaluarea costului testrii, fr ns a influena n mod negativ performanele modelelor. Spre deosebire de rafinarea modelelor liniare, rafinarea modelelor neliniare este un proces mai dificil care necesit o serie de analize asupra factorilor i a funciilor modelelor. Se consider modelul M definit prin relaia: y = f ( x1 , x 2 ,..., x n ) unde y este variabila dependent iar x1, x2, , xn variabile independente. Modelul are n variabile independente i este neliniar.

138

Ordinul unui model se definete ca fiind numrul de operaii aritmetice de nmulire, mprire, ridicare la putere sau funcii trigonometric sau logaritmice existente ntre variabilele independente ale modelului. Modelul este liniar dac ordinul lui este 0. Rafinarea este un procedeu prin care: se reduce numrul de variabile; se reduce ordinul de neliniaritate; se fac ambele modificri. Prin efectuarea acestor modificri, pentru a se considera o rafinare bun a modelului este necesar ca erorile care apar s fie nesemnificative. De exemplu, pentru modelul M considerat, care are n variabile, se calculeaz e1, suma ptratele diferenelor erorilor:
e1 = ( y i y1i ) 2
i =1 t

Se obine un model rafinat MR pentru evaluarea costului testrii prin eliminarea unui numr de variabile, astfel nct MR are q variabile, q mult mai mic dect n. i pentru acest model se calculeaz suma ptratelor diferenelor abaterilor, e2:
e2 = ( y i y 2i ) 2
i =1 t

n cazul n care aceste sume nu difer semnificativ, se consider c modelul rafinat MR care utilizeaz q variabile independente este corespunztor. Se efectueaz i alte teste de verificare a acurateei modelelor rafinate obinute. Marea majoritate a modelelor utilizate n acest capitol o constituie modelele unifactoriale i, de aceea, pentru aceste modele rafinarea se realizeaz prin reducerea ordinul de neliniaritate. Pe baza datelor nregistrate n cursul testrii aplicaiei e-DSI, n capitolul 9 sunt estimai parametrii pentru o serie de modele neliniare i sunt analizate rezultatele obinute.

139

7
TEHNOLOGIE DE IERARHIZARE A MODELELOR PENTRU EVALUAREA CTS
7.1 Criterii de ierarhizare a modelelor de evaluare a CTS
Ierarhizarea modelelor de evaluare a costului testrii software se realizeaz n funcie de o serie de criterii, fiecare metod de ierarhizare avnd la baz anumite intrri, care n general sunt diferite de la o metod la alta. n funcie de informaiile disponibile despre o serie de modele la un moment dat se opteaz pentru o metod de ierarhizare sau alta. Modelele de evaluare a costului testrii sunt ierarhizate folosind urmtoarele criterii: pe baza caracteristicilor cu care este nzestrat modelul; numrul de caracteristici variaz de la un model la altul i importana acestora este diferit; pe baza sumei ptratelor diferenelor erorilor; se determin acele modele pentru care diferenele dintre evaluri i costurile efective sunt minime; pe baza ponderilor acordate factorilor; fiecare factor care influeneaz costul testrii i este inclus ntr-un model contribuie n mod diferit la calitatea rezultatului obinut; n funcie de complexitatea modelelor; fiecare model are o complexitate caracteristic i aceasta conduce la stabilirea unei ierarhii de modele. Tehnologia de ierarhizare presupune urmtoarele activiti: validarea modelelor; ierarhizarea modelelor folosind analiza comparat; ierarhizarea modelelor pe baza sumei diferenei erorilor; ierarhizarea modelelor bazat pe ponderi;
140

 evaluarea modelelor. n figura 7.1 este prezentat tehnologia de ierarhizare a modelelor de evaluare a costului testrii software. Ca intrri se regsesc descrierile modelelor de evaluare, estimaiile realizate pentru coeficieni, costurile efective obinute, tehnicile de elaborare software utilizate i seturile de date utilizate.
Modele

Validare modele

Modele validate Ierarhizare

Clase de modele Figura 7.1 Tehnologie de ierarhizare a modelelor de evaluare

Verificarea modelului const n: verificarea ipotezelor pe care se fundamenteaz modelul; verificarea ipotezelor pe care se fundamenteaz estimarea parametrilor; verificarea semnificaiei estimatorilor; verificarea similitudinii modelului.
141

n funcie de obiectivele avute n vedere i de posibilitile de culegere a datelor, se utilizeaz o metod sau mai multe de ierarhizare a modelelor de evaluare a costurilor software.

7.2 Validarea modelelor de evaluare a CTS

Se consider modelul M de evaluare a costului testrii software, model construit pe baza unor ipoteze cunoscute. Modelul este construit n funcie de factorii de influen F1, F2, , Fn i exist setul de date D1, D2, , Dt. Se construiete tabelul 7.1 corespunztor modelului M n care sunt nregistrate pentru fiecare set de date Di, valorile variabilelor pentru factorii Fj.
Tabelul 7.1 nregistrrile pentru modelul M F2 Fj Fn Cost Factori F1 evaluat Set de date D1 1 Ds vsj s Dt t

Cost efectiv y1 ys yt

Pe baza datelor din tabelul 7.1 se estimeaz parametrii modelului. Se fac estimaii pentru parametrii modelului pentru un numr s de seturi de date, s < t. Se iau datele de la seturile de date de la Ds+1 pn la Dt i se introduc n model. Se obin ys+1 , ys+2 ,...,yt nivelurile costurilor evaluate folosind modelul M. Pe baza costurilor efective y1, y2, , yt din ultima coloan a tabelului 7.1 se calculeaz diferenele:
d 1 = ( y i y i ) 2 i d 2 =
i =1 s i = s +1

(y

yi ) 2

d1 d 2 . Dac este adevrat, nseamn s ts c erorile introduse nu sunt semnificative i modelul se consider bun. n mod asemntor se procedeaz pentru fiecare model de evaluare obinut. Pentru validarea modelului se utilizeaz testul F i testul t.
Se verific inegalitatea:
142

Pentru utilizarea testului F este necesar s se determine gradele de libertate v1 i v2 n funcie de numrul de observaii i numrul de factori. Se obine valoarea tabelar Ftab pe baza valorilor v1, v2 i a probabilitii din tabele statistice i se calculeaz valoarea Fcalc care rezult din datele disponibile. n cazul n care Fcalc>Ftab se consider, cu o probabilitate de 1, c legtura dintre variabile nu este ntmpltoare. Testul t se utilizeaz pentru a determina importana factorilor modelului i a estimaiilor realizate n cazul n care numrul de observaii este maxim 40. Pentru fiecare factor n parte se calculeaz valoarea tcalc ca fiind raportul dintre coeficientul estimat corespunztor factorului i eroarea standard pentru coeficientul obinut. Valoarea tabelar, ttab se determin din tabele statistice pe baza numrului gradelor de libertate i a probabilitii . n mod asemntor, dac valoarea calculat este mai mare dect valoarea tabelar, tcalc>ttab, se poate afirma cu probabilitatea 1- c factorul considerat are o influen important asupra variabilei dependente.

7.3 Analiza comparat a modelelor de evaluare a CTS

Se consider modelele M1, M2, ..., Mm de tipuri i naturi diferite. Analiza comparat a modelelor presupune: definirea unui set de caracteristici C1, C2, ..., Ct; stabilirea faptului c modelul Mi este nzestrat sau nu cu caracteristica Cj. Se observ din tabelul 7.2, c exist modele nzestrate cu un numr mai mare de caracteristici i modele care nu corespund n raport cu o serie de criterii impuse.
Tabelul 7.2 Matricea caracteristicilor modelelor C2 Cj Ct Caracteristica C1 Model M1 Mi aij Mm

Analiza comparat revine la a interschimba liniile i coloanele tabelului 7.1 n aa fel nct pe prima coloan s se gseasc caracteristica
143

care se regsete de cele mai multe ori n cele m modele, iar pe prima linie s se gseasc modelul nzestrat cu cele mai multe caracteristici. Ultima coloan va corespunde caracteristicii cel mai puin ndeplinit de modele iar ultima linie va corespunde celui mai slab model. De exemplu, se consider modelele M1, M2, M3 i M4 i caracteristicile C1, C2 i C3, cu semnificaiile: C1 lungimea seriei de date pe baza creia s-a fcut estimarea parametrilor conine mai mult de treizeci de termeni; C2 numrul de variabile ale modelului este mai mare ca doi; C3 coeficientul de corelaie este mai mare ca 0.85, crora le corespunde tabelul 7.3.
Tabelul 7.3 Matricea caracteristicilor C2 C3 Total Caracteristica C1

Model

M1 M2 M3 M4 Total

* * * 3

* * * 3

* * 2

1 3 2 2 8

Dup ordonarea prin interschimbare a liniilor i coloanelor se obine tabelul 7.4. Tabelul 7.4 Matricea ordonat a caracteristicilor C2 C3 Total Caracteristica C1 Model M2 * * * 3 M3 * * 2 M4 * * 2 M1 * 1 Total 3 3 2 8 Din tabelul 7.4 rezult c modelul M2 este nzestrat cu maximum de caracteristici, iar modelul M1 este cel mai slab n raport cu caracteristicile. Datorit faptului c i caracteristicile sunt diferite ntre ele, dac specialitii S1, S2, ..., Sk definesc un sistem de ierarhizare i le acord ponderile p1, p2, p3 va rezulta c: modelul M2 are p1+p2+p3 puncte; modelul M3 are p1+p3 puncte; modelul M4 are p1+p2 puncte;
144

 modelul M1 are p2 puncte. Considernd c p1=0.1, p2=0.6 i p3=0.3 rezult c modelul M2 are 1 punct, modelul M3 are 0.4 puncte, modelul M4 are 0.7 puncte i modelul M1 are 0.6 puncte, ceea ce conduce la obinerea ierarhiei de modele M2, M4, M1, M3. Paii acestei metode de ierarhizare sunt: identificarea caracteristicilor modelelor; construirea tabelului 7.4 i determinarea numrului de caracteristici din fiecare model; n cazul n care sunt definite ponderi pentru fiecare caracteristic, atunci se aplic aceste ponderi; ordonarea liniilor din tabel astfel nct aceste s fie sortate descresctor dup numrul de caracteristici, pe prima linie fiind modelul cu numrul maxim de caracteristici iar pe ultima linie modelul cu numrul minim de caracteristici. Metoda de ierarhizare este prezentat grafic n figura 7.2.
Modele Caracteristici

Contorizare caracteristici Ponderare Ordonare dup caracteristici

Ierarhia de modele

Figura 7.2 Metoda de ierarhizare pe baza caracteristicilor modelelor 145

Pentru realizarea unui program pentru ierarhizarea modelelor de evaluare dup caracteristici se definesc: o matrice A de m x t elemente corespunztoare celor m modele i t caracteristici asociate modelelor; o matrice T de m linii i 2 coloane utilizat pentru nsumarea caracteristicilor pentru fiecare model n parte; coloana a doua este utilizat pentru memorarea poziiei modelelor; o procedur care sorteaz matricea T pe linii descresctor dup numrul de caracteristici din prima coloan; n coloana a doua se vor regsi numerele modelelor pe poziiile corespunztoare ierarhizrii. Aceast analiz comparat se bazeaz pe structura modelelor i pe o analiz calitativ a acestora. Tehnologia de ierarhizare nu conduce la un model infailibil, ci la o clas de modele.

7.4 Ierarhizarea modelelor pe baza sumei ptratelor de erori

Se consider modelele M1, M2, ..., Mm i seturile de date S1, S2, , St culese dup testarea a numeroase loturi de produse program. Pentru fiecare set de date se calculeaz diferenele dintre valorile efective ale costului testrii i valorile obinute prin intermediul modelului (tabelul 7.5).
Tabelul 7.5 Suma ptratelor erorilor pentru modelul Mj cu setul de date Si valori efective erorile ptrate valori calculate 1 y1 (1-y1)2 2 y2 (2-y2)2 k yk (k-yk)2 p yp (p-yp)2 total xij

nregistrrile obinute pentru cele m modele pentru t seturi de date sunt centralizate n tabelul 7.6.

146

Tabelul 7.6 Statistici privind modelele de evaluare Model M1 M2 Mj Mm Set de date S1 S2 Si xij St

n tabelul 7.6 xij reprezint suma ptratelor erorilor modelului Mj pentru setul de date Si. Coloana Mj din tabel va da informaii referitoare la modelul Mj n raport cu seturile de date S1, S2, , St. n cazul n care valorile xij sunt egale sau sunt apropiate de o valoare x, atunci se consider c modelul Mj este foarte puin sau chiar deloc senzitiv la seturile de date diferite. Cu ct diferenele dintre valorile xij pentru modelul Mj sunt mai mari, cu att modelul este mai sensibil i rezult necesitatea revizuirii acestuia. Ierarhizarea modelelor n funcie de suma ptratelor erorilor se face astfel: se determin sumele abaterilor pentru fiecare model Mj:
x j = xij
i =1 t

se calculeaz valorile medii ale sumelor obinute:

m se sorteaz cresctor modelele n funcie de valorile medii x j obinute. n scopul realizrii unui produs software pentru ierarhizarea modelelor pe baza sumei ptratelor erorile se definesc: un vector care conine valorile estimate ale costului testrii pentru fiecare model, corespunztor fiecrui set de date; o matrice cu valorile efective ale costului testrii pentru fiecare set de date; o procedur care construiete matricea X de dimensiune m x t, matrice n care sunt centralizate sumele ptratelor erorilor pentru cele m modele;

147

xj =

x
j =1

o procedur care determin valorile medii ale ptratelor erorilor i sorteaz cresctor matricea, astfel nct pe prima coloan se va gsi modelul cel mai bun, iar pe ultima coloan cel mai slab model. Aceast metod de ierarhizare necesit foarte multe nregistrri efectuate n timp, precum i existena unei compatibiliti a modelelor de evaluare pentru a putea utiliza aceleai seturi de date.

7.5 Ierarhizarea dup ponderi a modelelor de evaluare a CTS

Se consider factorii de influen a testrii F1, F2, , Fn i produsele software P1, P2, , Pm. Se observ c de la produs la produs difer importana acordat factorilor de influen a testrii. Se asociaz ranguri acestor factori. Deci factorul Fi are rangul j. Rangurile nu pot depi numrul de factori i nu se repet. De exemplu, dac sunt 3 factori F1, F2, F3 vor fi trei ranguri 1, 2 i 3. Dac se presupune c F1 are rangul 2, F2 rangul 1, n acest caz, F3 poate avea doar rangul 3. Pentru nregistrarea rangurilor acordate se construiete tabelul 7.7. n tabelul 7.7 valoarea rij corespunde rangului acordat factorului Fj n produsul software Pi. Se adun rangurile pe factori i rezult sumele S1, S2, , Sn. Se calculeaz suma total S = S j . Se mpart sumele Sj la S i rezult
j =1 n

ponderile asociate fiecrui factor de influen: S pj = j S

Tabelul 7.7 Rangurile acordate factorilor de influen a testrii F2 Fn Factor F1 Fj Produs software P1 P2 Pi rij Pm Total S1 S2 Sj Sn Ponderi asociate p1 p2 pj pn 148

Ponderile se refer la cei n factori, ns sunt i modele care au mai puini factori la care se nsumeaz ponderile acelor factori i rezult modelul cu ponderile cele mai mari. Ponderile pot surprinde i alte aspecte dect cele strict msurabile. Modelele de evaluare a costurilor nlocuiesc produsele software i raionamentul rmne acelai. Pentru realizarea unei aplicaii de ierarhizare a modelelor de evaluare a costului testrii pe baza ponderilor se definesc urmtoarele: o matrice R de dimensiune m x n n care sunt memorate rangurile corespunztoare fiecrui factor pe fiecare produs n parte; un vector S de dimensiune n n care sunt memorate sumele rangurilor pe fiecare factor n parte; un vector P de dimensiune n n care sunt memorate ponderile calculate pentru fiecare factor n parte; o procedur care pe baza vectorului P determin poziia fiecrui model prin calcularea ponderilor fiecrui factor n parte n cadrul modelului considerat. n general, rangurile acordate i ponderile asociate factorilor sunt determinate n mod subiectiv i alegerea acestora depinde de la un specialist la altul i de la un proiect software la altul. Este posibil realizarea unei baze de nregistrri care s conin pentru fiecare factor n parte rangul i ponderea acordate de un numr mare de specialiti ntr-un numr considerabil de proiecte. Pentru fiecare factor n parte se determin valorile medii pentru ranguri i pentru ponderile asociate i n procedeul de ierarhizare se vor utiliza valorile medii obinute prin calcule.

7.6 Ierarhizarea bazat pe complexitate a modelelor de evaluare a CTS

Exist o serie de caracteristici care determin complexitatea modelelor de evaluare. Dintre acestea se enumer: numrul de factori; pentru un numr mai mare de factori ai modelului, complexitatea acestuia crete;
149

funcia modelului; funcia dup care este definit modelul are un rol important n creterea complexitii modelelor; gradul de liniarizare a modelului; n cazul modelelor neliniare, pentru estimarea coeficienilor se utilizeaz metoda celor mai mici ptrate aplicat modelului liniarizat; exist modele neliniare a cror liniarizare este imposibil de realizat; posibilitatea de culegere de date pentru factorii modelului; numrul de observaii efectuate. Pentru fiecare dintre aceste caracteristici care determin complexitatea modelului se asociaz ponderi (tabelul 7.8).
Tabelul 7.8 Notele acordate caracteristicilor de complexitate a modelelor Factor C1 C2 Cj Cn Total Model M1 T1 M2 T2

Mi Mm

pij

Ti Tm

n tabelul 7.8 elementul pij reprezint nota acordat caracteristicii Cj pentru modelul Mi. Se calculeaz sumele:

Ti = pij
j =1

dintre care se alege valoarea maxim: Tk = max{Ti } , aceasta corespunznd

1 i m

modelului Mk. Se ordoneaz descresctor modelele dup valorile Ti i sumele notelor se mpart la Tk, de unde rezult ierarhia de modele pe baza complexitii. O aplicaie software care realizeaz ierarhizarea pe baza acestei metode necesit: o matrice P de dimensiune m x n pentru nregistrarea notelor corespunztoare celor n caracteristici de complexitate luate n considerare pentru cele m modele;
150

o matrice T de dimensiune m x 2 care conine pe prima coloan sumele notelor pentru fiecare model n parte, iar pe a dou coloan numrul modelului; o funcie care primete ca parametri matricea P i matricea T i calculeaz sumele notelor, le memoreaz n prima coloan a matricei T, determin valoarea maxim i, pentru fiecare model, calculeaz raportul dintre nota modelului i nota maxim; o funcie care primete ca parametru de intrare matricea T i o sorteaz n ordine descresctoare dup prima coloan, astfel nct n a dou coloan se vor regsi numerele modelelor, de la cel mai complex la cel mai puin complex. Aceast metod de ierarhizare a modelelor de evaluare a costului testrii software depinde de modul n care au fost alese caracteristicile de complexitate a modelelor, precum i de notele acordate fiecrei caracteristici n parte pentru fiecare model luat n considerare. Pe baza datelor culese n timp de la proiectele software pentru care au fost evaluate costurile testrii utiliznd diferite modele este posibil asigurarea unui grad ridicat de obiectivitate n aprecierea caracteristicilor de complexitate asociate modelelor.

7.7 Evaluarea modelelor de evaluare a CTS

Obiectivul este construirea unor modele de evaluare a modelelor de costuri pentru testarea software. Fie metodele de testare T1, T2, , Tt, unde t este numrul metodelor de testare i modelele de evaluare a costului M1, M2, , Mm, unde m este numrul modelelor de evaluare a costurilor. Se construiete matricea de coresponden (tabelul 7.9).

151

Tabelul 7.9 nregistrri privind tehnicile de testare i modelele de evaluare Model M1 M2 Mj Mm Metoda testare T1 T2 Ti cij Tt

n tabelul 7.9 cij are valoarea 0 dac modelul Mj nu permite culegerea de date i cij are valoarea 1 dac se pot culege date i se poate evalua costul procesului de testare pentru metoda Ti. Se presupune c s-au construit programele P1, P2, , Pk, , Ps, unde s reprezint numrul de programe testate. Pentru programul Pk s-a folosit metoda de testare Ti i s-a evaluat costul testrii cu modelul Mj. Pe baza nregistrrilor privind programele realizate i testate, astfel nct s se gseasc un procent ridicat de erori, se fac evaluri (tabelul 7.10).
Tabelul 7.10 Costurile evaluate i costurile efective ale testrii

Programul (P) P1 P2 Pk Ps

Costul evaluat (CE) CE1 CE2 CEk CEs

Costul efectiv (CF) CF1 CF2 CFk CFs

Pentru evaluarea modelelor pe baza crora au fost determinate costurile evaluate (CE) sunt urmrii paii.

152

Pasul 1: Se calculeaz diferenele: D1 = CE1 CF1

... Ds = CE s CFs

Pasul 2: Se alege valoarea maxim a diferenelor pentru cele s programe luate n considerare: Dmax = max{Di }
1 i s

Pasul 3: Pentru fiecare variabil se calculeaz indicatorii:

ri = 1

Di Dmax

Dac ri = 0 nseamn c estimarea costului nu a fost fcut bine. Dac ri = 1 atunci costul a fost bine estimat.
Pasul 4: Cu o colectivitate omogen s-au obinut intervalele: [0,0.73) slab [0.73,0.86) mediu x [0.86,0.96) bun [0.96,1] foarte bun

n contextul acestei metode de evaluare se aleg elementele ri pentru care exist ri [0.86, 1].
Pasul 5: Se parcurge drumul invers: identificarea modelelor care au condus la estimrile pentru care ri0.86; Pentru aceste modele se consider c estimarea fcut este bun. n figura 7.3 sunt reprezentai sub forma unei scheme logice paii metodei de evaluare a modelelor.

153

i=1

is Di=|CEi-CFi|
Dmax = max Di } {
1is

i=i+1

i=1

is

ri = 1

Di D max

ri(0.86,1]

DA Mi acceptat

i=i+1

Figura 7.3 Etapele procesului de evaluare a modelelor

Evaluarea modelului revine la a gsi mulimea de modele pentru care ri0.86, adic pe cele care au valoarea ri cea mai mare.

154

n scopul realizrii unei aplicaii informatice de evaluare a modelelor sunt necesare: o matrice de m linii corespunztoare modelelor i 2 coloane corespunztoare costurilor evaluate i a costurilor efective; un vector D de s elemente corespunztoare diferenelor dintre costurile evaluate i costurile efective; un vector R care are s elemente corespunztoare indicatorilor calculai pentru fiecare model; o procedur care are ca intrri vectorul D i vectorul R; procedura calculeaz indicatorii ri i i memoreaz n vectorul R; o procedur care are ca intrare vectorul R i determin apartenena indicatorilor ri la intervalele de caracterizare; procedura afieaz rezultatele evalurii modelelor. Rezultatul evalurii const fie n respingerea modelului, fie n acceptarea acestuia, n acest caz rezultnd c este modelul cel mai potrivit n situaia dat. Ierarhizarea are rolul de a conduce la obinerea de grupuri de modele care s fie utilizate n activitatea curent, astfel nct efortul de culegere a datelor s fie redus, dar evalurile fcute s fie ct mai apropiate de valorile efective nregistrate. n capitolul 9 este utilizat tehnologia de ierarhizare a modelelor de evaluare a costului testrii software pentru aplicaia e-DSI.

155

8
PROBLEME ALE MODELELOR DE EVALUARE A CTS N TESTAREA ORIENTAT PE STRUCTURI DE CONTROL I STRUCTURI DE DATE
8.1 Costul testrii pentru proceduri care includ structuri de control liniare
Aplicaia e-DSI conine proceduri i structuri de date diverse care influeneaz modul n care se realizeaz procesul de testare cu efecte n planul efortului depus n aceast activitate. n [SMEU02], [SMEU04], i [TANA03] sunt descrise aspecte legate de limbajele de programare C++, C# i Java, precum i particularitile realizrii i utilizrii structurilor de date n aceste limbaje. Procedurile liniare includ secvene de instruciuni care se execut una dup alta. n aceste structuri nu exist instruciuni de salt necondiionat, instruciuni de salt condiionat sau structuri alternative multiple. Procedura liniar are forma:
tip nume_procedur(tip1 p1, tip2 p2,, tipq pq) { I1 I2 I3 Ik In return (valoare_retur); }

156

Instruciunile se execut n ordinea n care apar, dup graful dat n figura 8.1. I1 Ik In-1 In
Figura 8.1 Graful asociat procedurilor liniare

Pentru testarea unei funcii sunt avute n vedere att caracteristicile funcionale ct i caracteristicile structurale. Ca metod de testare funcional se utilizeaz generarea de valori aleatoare, analiza valorilor limit i partiionarea echivalent. Pentru testarea structural se utilizeaz numai acoperirea instruciunilor, avnd n vedere faptul c funciile conin doar structuri de control liniare. n vederea extinderii aplicaiei e-DSI cu o component pentru calculul salariului net pornind de la salariul brut sau invers, pornind de la salariul net s se ajung la salariul brut, se consider funcia pentru calculul salariului net al unui angajat. Funcia primete ca parametri: salariul de ncadrare; sporurile; reinerile; deducerea personal; cota fix de impozit; cota procentual de impozitare; limita de salariu peste care se impoziteaz aplicnd cota de impozitare procentual. Funcia returneaz o valoare care reprezint salariul net i are urmtorul prototip:
long CalculSalariuNet(long lSalIncadrare, long lSporuri, long lRetineri, long lDeducere, long lLimMax, float fCotaImpozit, long lImpozitFix);

Pentru parametrii funciei se identific tipul acestora, domeniul de definiie pentru tip i restriciile acestor parametri (tabelul 8.1). Generarea de date de test aleatoare pornete de la intervalul de valori valide pentru parametri i are ca efect obinerea unui numr prestabilit de date de test. Prin partiionare se determin clase de echivalene pentru fiecare parametru n parte. Se creeaz dou clase: o clas cu valori valide i o clas cu valori invalide n contextul problemei.

157

Tabelul 8.1 Specificaiile parametrilor funciei CalculSalariuNet() Parametru Tip Domeniu Restricii lSalIncadrare long -2147483648+2147483647 Pozitiv >= salariul minim pe economie lSporuri long -2147483648+2147483647 Pozitiv lRetineri long -2147483648+2147483647 pozitiv lDeducere long -2147483648+2147483647 pozitiv >=salariul minim pe economie lImpozitFix long -2147483648+2147483647 pozitiv lLimMax long -2147483648+2147483647 pozitiv fCotaImpozit float 3,4x10-383,4x1038 pozitiv

Prin utilizarea analizei valorilor limit pentru realizarea cazurilor de test, pentru fiecare parametru al funciei se determin un set de valori aflate la limita domeniul de validitate. Dac n este numrul de seturi de test i volumul setului de test i este Vi, atunci volumul total (VT) al celor n seturi de test este:
VT = Vi
i =1 n

n tabelul 8.2 este calculat numrul de cazuri de test pentru un parametru de tip numeric sau ir de caractere, utiliznd cele trei tehnici de testare. Se obine un total de Sn, respectiv Ss cazuri de test.
Tabelul 8.2 Volumul seturilor de test pentru un parametru Tehnica de testare Numr de cazuri de test Valori numerice iruri de caractere Generare valori m M aleatoare Analiza valorilor limit 6+k 3+k Partiionarea p P echivalent Total Sn Ss 158

Utiliznd cele trei tehnici de testare, pentru funcie se obin si seturi de test pentru parametrul pi. n cazul n care funcia are n parametri, numrul total de seturi de date de test pentru funcie este dat de relaia:
S T = si
i =1 n

Pentru funcia CalculSalariuNet(), prezentat anterior, se construiete tabelul 8.3, care conine numrul de seturi de date de test corespunztoare unei singure date de intrare.
Tabelul 8.3 Seturile de date de test pentru funcia CalculSalariuNet Metoda de testare Numr valori de test Generare valori aleatoare 6 Analiza valorilor limit 6 Partiionarea echivalent 2 Total 14

Avnd n vedere faptul c funcia CalculSalariuNet() are 7 parametri i c toi parametrii sunt numerici, numrul total de seturi de test independente este ST=147=105413505. Prin combinarea cazurilor de test, numrul de seturi de test se reduce semnificativ. Pentru fiecare caz de test n parte se specific valorile de intrare precum i rezultatul ateptat. Un astfel de exemplu de caz de test este prezentat n tabelul 8.4.
Tabelul 8.4 Caz de test Date de intrare Valoare lSalIncadrare 3124000 lSporuri 254606 lRetineri 662962 lDeducere 1840000 lImpozitFix 157616 lLimMax 0 fCotaImpozit 0.0 Rezultat ateptat Salariul net 2558028

159

Pentru testarea structural a funciei este necesar codul surs al acesteia. Funcia CalculSalariuNet are urmtoarea implementare:
long CalculSalariuNet(long lSalIncadrare, long lSporuri, long lRetineri, long lDeducere, long lImpozitFix, long lLimMax, float fCotaImpozit) { long lImpozit,lSal; /*I1*/ lSal=lSalIncadrare+lSporuri-lRetineri; /*I2*/ lSal-=lDeducere; /*I3*/ lImpozit=(lSallLimMax)*fCotaImpozit+lImpozitFix; /*I4*/ return lSal-lImpozit+lDeducere; }

Se construiete matricea de dependene ale instruciunilor, ale crei elemente aij iau valorile *, care arat inexistena unei dependene dintre instruciunea i i instruciunea j, respectiv d, care arat faptul c instruciunea i depinde de instruciunea j. Pentru funcia CalculSalariuNet() n tabelul 8.5 este dat matricea completat a dependenelor instruciunilor.
Tabelul 8.5 Matricea dependenelor instruciunilor pentru funcia
CalculSalariuNet()

I1 I2 I3 I4

I1 * d * *

I2 * * d d

I3 * * * d

I4 * * * *

Din analiza matricei dependenelor instruciunilor rezult c instruciunile I2, I3 i I4 depind de instruciunile precedente, (respectiv I1, I2 i I3) i, n plus, I4 depinde de instruciunea I2. Complexitatea ciclomatic [ARHI00] a procedurii CalculSalariuNet() este CV(G)=1. n procedur este o singur succesiune de arce deoarece nu exist nici o instruciune alternativ sau repetitiv, ceea ce conduce la existena unui singur set de date de test pentru executarea tuturor instruciunilor.

160

n analiza i proiectarea cazurilor de test, costul total al testrii unei funcii (CF) este dat de relaia: CF = C1 + C 2 + C3 unde: C1 costul realizrii tabelului domeniilor variabilelor; C2 costul realizrii matricei dependenelor; C3 costul seturilor de test. Toate aceste costuri sunt dependente de duratele activitilor, numrul de persoane implicate i salariile orare ale acestora. Costul seturilor de test depinde de volumul datelor, precum i de modul n care au fost obinute. Costul obinerii unui set de date de test particular, prin analiza specificaiilor i a algoritmului de rezolvare a unei probleme este mai mare dect costul obinerii unui set de date de test prin analiza valorilor limit. Costul obinerii seturilor de test (C3) este dat de formula:
C 3 = c i Vi
i =1 n

unde: ci costul obinerii setului de date de test de volum Vi. Pe cale experimental se efectueaz msurtori, se procedeaz la omogenizarea datelor obinute, n aa fel nct costurile ci i volumele Vi s fie rezultatul unor activiti de normare a muncii.

8.2 Testarea procedurilor alternative

Procedurile care conin n principal instruciuni if-then-else care implementeaz structuri alternative se regsesc sub denumirea de proceduri if-then-else sau proceduri alternative.

161

tipr nume_procedur(tip1 p1, tip2 p2,, tipq pq) { if(expresie1) { B11 } else { B12 } if(expresiek) { Bk1 } else { Bk2 } if(expresien) { Bn1 } else { Bn2 } return (valoare_retur); }

expresie1 B12 B11

expresie2 B22 B21

expresiek Bk2 Bk1

expresien Bn2 Bn1

a)

return

b) Figura 8.2 Structura i graful asociat procedurilor alternative n figura 8.2 a) este prezentat structura unei proceduri alternative, iar graful asociat unei astfel de proceduri este n figura 8.2 b). n figura 8.3 este prezentat structura arborescent asociat acestuia.

162

NU B12 expresie2 B22 expresien B21

expresie1 DA B11 expresie2 B22 expresien B21 expresien

expresien

Bn2

Bn1 Bn2

Bn1Bn2

Bn1 Bn2

Bn1

Figura 8.3 Structura arborescent asociat procedurii alternative

Numrul de ci ntr-o procedur alternativ care conine n instruciuni if-then-else complete, este egal cu 2n. n aplicaia e-DSI, pentru determinarea aparatului fotografic cu cel mai mic pre dintre trei aparate care se compar, se utilizeaz funcia PretMinim() care primete ca parametri trei numere de tip double, avnd codul surs:
double PretMinim(double p1, double p2, double p3) { double min=p1; if(min>p2) min=p2; if(min>p3) min=p3; return min; }

Graful asociat funciei PretMinim() este prezentat n figura 8.4 a) iar structura arborescent asociat n figura 8.4 b).

163

min=p1 a d ; e f i ; j min>p2 b min=p2 c min>p3 g min=p3 h k return min

min=p1 min>p2 ; min>p3 min=p3 ; return min min=p2 min>p3 min=p3

b) Figura 8.4 Graful (a) i structura arborescent (b) asociate funciei PretMinim() Graful din figura 8.4 a) asociat funciei PretMinim() are numrul ciclomatic CV(G)=3, ceea ce conduce la alegerea a trei exemple de test care vor parcurge toate instruciunile i toate cile independente din acesta.
Tabelul 8.6 Cazuri de test pentru acoperirea instruciunilor i a ramurilor Nr. crt Intrri Calea parcurs Ieiri 1 3.0,2.0,1.0 p3 1.0 abcfghk 2 2.0,3.0,1.0 adefghk p3 1.0 3 1.0,3.0,2.0 adefijk p1 1.0

a)

return min return min return min

Deoarece procedura are o complexitate redus, analiza condiiilor dup strategia BRO [PRES00], de testare a condiiilor, conduce la urmtoarele posibiliti.

164

C1: min>p2 min=p1 1) p1=p2 2) p1<p2 3) p1>p2 F F T

C2: min>p3 min=p2 4) p2=p3 5) p2<p3 6) p2>p3 min=p1 7) p1=p3 8) p1<p3 9) p1>p3 F F T F F T

Pe aceast baz se aleg cazurile de test din tabelul 8.7.

Tabelul 8.7 Date de test pentru funcia PretMinim() Nr. crt Situaii Intrri Ieiri acoperite 1 1), 7) p1=p2=p3 1.0, 1.0, 1.0 p1 1.0 2 1), 8) p1=p2>p3 2.0,2.0, 1.0 p3 1.0 3 1), 9) p1=p2<p3 1.0,1.0,2.0 p1 1.0 4 2), 7) p1<p2, p1=p3 1.0,2.0,1.0 p1 1.0 5 2), 8) p1<p2, p1<p3 1.0,2.0,3.0 p1 1.0 6 2), 9) p1<p2, p1>p3 2.0,3.0,1.0 p3 1.0 7 3), 4) p1>p2=p3 2.0,1.0,1.0 p2 1.0 8 3), 5) p1>p2<p3 2.0,1.0,3.0 p2 1.0 9 3), 6) p1>p2>p3 3.0,2.0,1.0 p3 1.0

Costul pentru elaborarea cazurilor de test pentru fiecare cale independent n program este dat de relaia:
C I = ci
i =1 n

unde ci reprezint costul elaborrii unui caz de test i n este numrul de ci independente din funcie. n cazul n care procedurile alternative conduc la un numr foarte mare de ci se procedeaz la ierarhizarea acestora, obinndu-se subarbori binari, testele concentrndu-se asupra acestora.
165

8.3 Cerine ale testrii procedurilor repetitive

Procedurile n care apare o structur repetitiv for, while sau do while incluznd o structur liniar se numesc proceduri repetitive i au una din formele:
tipr nume_procedur(tip1 p1, tip2 p2,, tipq pq) { for(expr) { I1 I2 I3 In } return (valoare_retur); }

sau
tipr nume_procedur(tip1 p1, tip2 p2,, tipq pq) { while(expr) { I1 I2 I3 In } return (valoare_retur); }

sau
tipr nume_procedur(tip1 p1, tip2 p2,, tipq pq) { do { I1 I2 I3 In } while(expr); return (valoare_retur); }

166

Instruciunile I1, I2, , In se constituie n secvena liniar Si ale crei repetri depind de nivelul unei variabile de control i n evaluarea unei expresii relaionale. Apelul procedurii repetitive conduce la generarea secvenei de secvene Si1, Si2, , Sim. Procedurii repetitive i se asociaz unul din grafurile din figura 8.5, n funcie de poziia expresiei relaionale.
if

I1 I2 I3 In-1 In
if

I1 I2 I3 In-1 In

a) for, while b) dowhile Figura 8.5 Graful asociat procedurii repetitive Structurile repetitive sunt n cadrul unei proceduri: simple, atunci cnd exist o singur secven repetitiv; concatenate, cnd exist mai multe secvene repetitive una dup alta; imbricate, n cazul n care sunt mai multe secvene repetitive, una n interiorul alteia. Testarea procedurii repetitive revine la testarea secvenei Si ct i la testarea secvenei de secvene Si1, Si2, , Sim. Sunt importante rezultatele intermediare ale testrii fiecrei secvene Sij, j=1, 2, m i rezultatele testrii finale ale secvenelor de secvene. Rezultatul testrii mparte secvenele n dou submulimi: submulimea secvenelor executate n concordan cu specificaiile (S); submulimea secvenelor eronate (S). n cazul submulimii S se identific o cauz, iar n cazul n care sunt identificate mai multe cauze se trece la analiza matricei de precedene definit pentru structura liniar inclus n blocul repetitiv.

167

Graful generator asociat secvenei de secvene este:

if I1 I2 In if I1 I2 In if I1 I2 In

S1 sau

S2

Sn

I1 I2 In if I1 I2 In if I1 I2 In if S1 Se contorizeaz 1, executie corecta (S i j ) = . 0, executie eronata S2 scorul Sn testrii secvenei Sij,

n cazul n care gradul de corectitudine

C=

(S
j =1

ij

) [ A, B], A, B [0,1], A < B ,

cu A i B definite n specificaii, procedura repetitiv este acceptat pentru a fi inclus n produsul finit. Indicatorul C intr n calculul fiabilitii experimentale a produsului software final. Datele de test pentru secvenele repetitive simple i concatenate independente se aleg astfel: valoarea 0, nici o iteraie; valoarea n, numrul maxim de iteraii; valoarea k, unde 0<k<n; valoarea n-1; valoarea n+1. Pentru secvenele repetitive imbricate, datele de test sunt alese astfel nct se pornete de la structura repetitiv din interior, care va fi testat cu valorile 0, n, k, n-1 i n+1, celelalte structuri repetitive rmnnd la valoarea minim de iteraii i se continu spre exterior pe rnd cu celelalte structuri
168

repetitive, pn cnd va fi testat ntreaga secven de instruciuni asociate structurilor repetitive imbricate. n scopul realizrii programelor pentru ierarhizarea metodelor de evaluare a costurilor testrii software se construiesc proceduri pentru diverse operaii cu matrice. Se consider procedura determinrii sumei elementelor pe linii pentru o matrice Amxn cu elemente numere ntregi. Rezultatul este un vector sum cu numrul de elemente egal cu numrul de linii ale matricei A, care conine sumele corespunztoare elementelor de pe linii. Textul surs al procedurii este:
public void SumeLinii(int a[][], sum[]) { for(int i=0;i<m;i++) { sum[i]=0; for(int j=0;j<n;j++) sum[i]+=a[i][j]; } } int m, int n, int

Graful asociat acestei proceduri este dat n figura 8.6.

a b c e d f g

Figura 8.6 Graful asociat procedurii SumeLinii()

Complexitatea ciclomatic a funciei SumeLinii() este CV(G)=3, de unde rezult c un numr de trei cazuri de test asigur parcurgerea tuturor instruciunilor i a ramurilor prin cele trei ci independente. Cazurile de test sunt prezentate n tabelul 8.8.
169

Nr. crt 1 2 3

Tabelul 8.8 Cazuri de test pentru acoperirea cilor independente

Intrri Calea parcurs abcdefg ag abefg a={{1,1,1},{10,10,10},{100,100,100}}, m= 3, n= 3, sum={0,0,0} a={{1,1,1},{10,10,10},{100,100,100}}, m= 0, n= 3, sum={0,0,0} a={{1,1,1},{10,10,10},{100,100,100}}, m= 3, n= 0, sum={0,0,0}

Ieiri

sum={3,30,300} sum={0,0,0} sum={0,0,0}

Nr. crt 1

Pentru testarea acestor proceduri urmnd strategia de testare a structurilor repetitive, pentru funcia SumeLinii(), datorit faptului c structurile sunt imbricate, se aleg date de test innd seama de faptul c numrul maxim de iteraii este 10 i egal cu dimensiunea maxim a matricei A. Valorile pentru m i n sunt: m=1, n={0,1,3,9,10,11}, respectiv, m={0,1,3,9,10,11} i n=1 Se obin cazurile de test din tabelul 8.9. Tabelul 8.9 Cazurile de test pentru testarea structurilor repetitive
Intrri a={{1}} m= 1 n= 1 sum={0} a={{1,1,1}} m= 1 n= 3 sum={0} a={{1,,1,1}} m= 1 n= 9 sum={0} a={{1,,1,1}} m= 1 n= 10 sum={0} a={{1,,1,1}} m= 1 n= 11 sum={0} a={{1},{10},{100}} m= 3 n= 1 sum={0,0,0} a={{1}, {1},, {1},{1}} m= 9 n= 1 sum={0,,0,0} a={{1}, {1},, {1},{1}} m= 10 n= 1 sum={0,,0,0} a={{1},{1},,{1},{1}} m= 11 n= 1 sum={0,,0,0} Ieiri ateptate sum={1}

sum={3}

sum={9}

sum={10}

sum={10} Caz eronat, se refer a[0][10] este ateptat mesaj de eroare sum={1,10,100}

sum={1,1,,1,1}

sum={1,1,,1,1}

sum={1,1,,1} Caz eronat, se refer a[10][0] i sum[10] este ateptat mesaj de eroare

170

8.4 Aspecte ale testrii procedurilor cu apeluri

Programarea orientat obiect, asemenea altor tehnici de programare bazate pe reutilizarea de cod, conduce la construirea de proceduri care conin exclusiv apeluri de proceduri i referiri de funcii prin numele acestora. Construcia de forma:
tipr nume_procedur(tip1 p1, tip2 p2,, tipq pq) { for(expr) { nume1(lista_param_1); nume2(lista_param_2); nume3(lista_param_3); numen(lista_param_n); } return (valoare_retur); }

este foarte frecvent ntlnit n programe realizate de programatori familiarizai cu folosirea de biblioteci de funcii sau biblioteci de clase. Testarea acestor proceduri n care nu sunt cunoscute semnificaiile procedurilor apelate presupune un nou mod de abordare. Lista de parametri a celor n proceduri este generatoarea unor dependene, care se reprezint n tabelul 8.10.
Tabelul 8.10 Dependenele dintre proceduri prin parametri pj pk Parametrul P1 p2 Procedura P1 P2 Pi aij Pn

n tabelul 8.10, elementul aij ia una din valorile: I dac pj este parametru de intrare n procedura Pi; E dac pj este parametru de ieire n procedura Pi; S dac pj este parametru de stare n procedura Pi.
171

Tabelul 8.11 Matricea dependenelor procedurilor Pn Procedura P1 P2 Pj Procedura P1 P2 Pi bij Pn

n matricea dependenelor (tabelul 8.11) valoarea elementului bij este 1 dac ieirea proceduri Pj este folosit direct n procedura Pj i 0 n caz contrar. O procedur Pi este puternic dependent de procedurile precedente apelului ei dac ieirile acestora au o pondere x[0.72,1] n lista de parametri a procedurii Pi. Procedura Pi este slab dependent, dac ponderea 1-x a procedurilor furnizeaz ieiri pentru procedura Pi. A testa nseamn a construi graful dependenelor i a traversa acest graf cu acoperirea de combinaii de valori. Fie procedura:
int P0(int a, int b, int c) { int x,y,z,w; P1(a,b,x); P2(a,c,y); P3(b,c,z); P4(x,y,z,w); return w; }

Matricea dependenelor pentru procedura P0() este dat n tabelul 8.12.

172

Tabelul 8.12 Matricea de dependene pentru procedura P0() Procedura P0() P1() P2() P3() P4() Procedura P0() 1 1 1 P1() 1 P2() 1 P3() 1 P4() 1

Costul obinerii cazurilor de test variaz n funcie de numrul de proceduri apelate, de numrul de parametri transmii fiecrei proceduri i de dependenele dintre proceduri. Graful de dependene este redat n figura 8.7, iar n figura 8.8 graful asociat procedurii P0().
P1 P2 P4 P0

P0

P3 Figura 8.7 Graful dependenelor

P1 P2 P3 P4

Figura 8.8 Graful asociat procedurii P0()

Cazurile de test pentru procedura P0() se construiesc n funcie de semnificaia pe care o au procedurile apelate. De regul se iau n considerare valori particulare aparinnd domeniului pe care sunt definii parametrii (0, 1, 1 sau valori foarte apropiate de capetele intervalelor). Se construiesc combinaii ale acestor valori i testele urmeaz reguli specifice planificrii experienelor din statistica aplicat.

8.5 Testarea programelor cu structuri statice

Testarea produselor program reprezint una dintre etapele creia dezvoltatorii de software trebuie s-i acorde maxim importan, ntruct comportamentul la utilizatori este influenat de existena sau inexistena
173

erorilor. Cu ct numrul de utilizatori este mai mare i n procesul de testare nu au fost identificate i corectate erori, cu att efectele negative de antrenare multipl sunt mai ample. Produsele program construite cu structuri statice caracterizeaz acea concepie conform creia dimensiunile problemelor de rezolvat se estimeaz cu suficient precizie, iar raportul dintre zonele de memorie alocate i cele strict utilizate se gestioneaz, asigurndu-se un grad de folosire cel puin satisfctor. Testarea programelor care includ structuri de date alocate static prezint particulariti specifice, accentul punndu-se fie pe ncadrarea cmpurilor referite n alocrile existente, fie pe stabilirea gradului de apartenen a operanzilor la domenii specificate. Structurile de date statice sunt: masive unidimensionale, masive bidimensionale, masive multidimensionale, articole, masive de articole i fiiere cu moduri de organizare i tipuri de acces crora le corespund funcii sau instruciuni de limbaj. Programele care includ masive unidimensionale conin secvene pentru: iniializarea din fiiere sau de la tastatur a elementelor masivelor; traversarea masivelor n vederea efecturii de calcule element cu element; iniializarea prin atribuire a elementelor din masive; afiarea coninutului elementelor. Testarea vizeaz stabilirea concordanei ntre specificaiile de program i prelucrrile efectiv realizate de secvenele programelor. n cazul n care programele aloc zone de memorie corespunztoare unor dimensiuni considerate maxime ale problemelor, programatorii trebuie s verifice dac numrul efectiv al componentelor referite din masive corespunde definirii iniiale. n secvena utilizat n aplicaia e-DSI:
public static int PMAX=20; Produs produse[]; int n=0; public boolean AdaugaProdus(Produs p) { produse[n] = p; n++; }

174

se observ c dup un numr de 20 de apeluri se ajunge la referirea unei zone de memorie adiacent masivului produse[]. n timpul execuiei se va genera o excepie de tipul ArrayIndexOutOfBoundsException. De aceea este necesar existena unui test pentru a evita depirea limitelor masivului. Testarea are rolul de a evidenia prezena sau absena secvenelor de validare a ncadrrii expresiilor indiciale n limite impuse de definirea masivelor unidimensionale. n cazul n care iniializarea masivului unidimensional ia n considerare n componente, iar referirea vizeaz m componente i m>n, rezult c la evaluarea expresiilor se utilizeaz i cmpuri neiniializate. De exemplu secvena:
#define N 10 int x[N]={1,2,3,4,5,6,7}, n=5, m=7, y[N]; for(int i=0;i<n;i++) y[i]=i*i*i+3; for(i=0;i<m;i++) x[i]+=y[i];

conduce la obinerea de rezultate incorecte n legtur cu componentele x[5] i x[6]. n cazul n care n program exist definite teste de validare a apartenenei expresiilor de referire la valori care corespund componentelor iniializate corect, testele vor determina apariia de mesaje specifice tentativei de ieire din aceste intervale. Programele care conin definiri de masive bidimensionale trebuie s includ o serie de expresii care s stabileasc concordana dintre aceste masive i masivele unidimensionale. De exemplu se consider expresia matriceal b = (A' A) -1 B unde: A masiv bidimensional avnd m linii i n coloane; A transpusa masivului bidimensional A; B masiv unidimensional avnd n elemente. Dac masivul A este iniializat pe m linii i n coloane, iar masivul B este iniializat pe k elemente, trebuie validat existena egalitii lui n cu k. Testarea programelor care manipuleaz elemente ale masivelor bidimensionale trebuie s scoat n eviden concordana dintre modul n care sunt iniializate blocuri i modul n care acestea sunt ntrebuinate. Definirea diferit de iniializare conduce la rezultate incorecte afectate de regulile de referire, diferite de la o etap la alta.
175

Lucrul cu articole ca tipuri de date neomogene impune construirea de expresii de referire care s ofere o flexibilitate suficient de mare pentru structurile instabile n care se adaug cmpuri, se insereaz cmpuri, se interschimb cmpuri, se elimin cmpuri, se modific tipul sau lungimea cmpurilor existente. Testarea programelor care utilizeaz structuri de tip articol are rolul de a scoate n eviden concordana dintre tipul cmpului i coninutul acestuia. n cazul structurilor statice testarea coninutului operanzilor prezint importan, ntruct numai apartenena la domeniul specific aplicaiei garanteaz calitatea i completitudinea rezultatelor. n cazul masivelor de articole este important ca expresiile de referire s asigure traversarea complet a componentelor iniializate n contextul existent n specificaiile de programare. Costul testrii programelor care utilizeaz structuri statice variaz n funcie de tipul structurilor, innd cont de faptul c n cazul fiierelor problemele care pot s apar sunt mai numeroase, dect de exemplu n cazul masivelor unidimensionale.

8.6 Particulariti ale testrii programelor cu structuri dinamice

Structurile dinamice, liste simple, liste duble, arbori binari, grafuri etc. sunt rezultatul necesitii creterii gradului de utilizare a zonelor de memorie definite i referite. Dac n cazul unui masiv unidimensional cu maxim N componente sunt referite primele n componente, n<N, n cazul unei liste simplu nlnuit cu m componente, toate cele m componente fac obiectul referirii n program. Spre deosebire de structurile statice, structurile dinamice folosesc variabile pointer, al cror coninut sunt deplasri (adrese relative). Testele programelor care conin structuri dinamice au dublu rol. Pe de o parte vizeaz coninutul cmpurilor aferente informaiilor utile scopului pentru care a fost elaborat programul i pe de alt parte, vizeaz coninutul variabilelor pointer care trebuie s fie NULL sau o deplasare care s permit referirea elementului urmtor, referirea elementului precedent sau a unuia descendent, n funcie de tipul structurii dinamice. n cazul n care legturile nu sunt corect realizate, funciile de traversare conduc la referiri pariale i la ntreruperi necontrolate ale execuiei. Exist situaii n care, printr-o gestionare defectuoas a variabilelor pointer se pierd adresele capetelor de list sau adresa rdcinii arborelui.
176

Pentru evitarea unor incidente, n faza de testare a produsului program informaiile utile trebuie s fie preluate din fiiere, pn la stabilizarea mecanismelor de construire i actualizare a structurilor dinamice. n limbajul Java, spre deosebire de C++, nu exist variabile de tip pointer i eliberarea memoriei alocate se face automat de ctre o component specializat, ceea ce conduce la posibiliti reduse de apariie a erorilor din aceste cauze, testarea concentrndu-se asupra altor aspecte. Dac se lucreaz cu componente adiacente trebuie gestionat comportamentul programului n raport cu primul element, respectiv cu ultimul element. Secvena C++ care include expresii de forma:
pcl->next->next

sau
pcl->prev->prev

trebuie s verifice dac este atins una dintre limite. Absena unui astfel de test genereaz tentative de referire a unor componente care nu aparin structurii de date creat prin programul scris n cadrul aplicaiei. Structurile dinamice presupun referirea funciilor de alocare a memoriei malloc(), calloc(), operatorul new, precum i funcia de eliberare a memoriei free() sau operatorul de eliberare a memorie delete. Oricrei alocri trebuie s-i corespund ntr-un alt moment al execuiei o eliberare de memorie. n cazul n care se nregistreaz dezechilibre, fie are loc umplerea stivei, fie are loc golirea prematur a acesteia. Testarea trebuie s vizeze simetria dintre procesele de alocare i procesele de eliberare a memoriei. Sunt numeroase situaiile n care nivelurile de indirectare sunt mai mari dect unu, ceea ce impune stabilizarea aritmeticilor de pointeri pentru a realiza concordana ntre modul n care sunt definite i iniializate pe toate nivelurile aceste variabile i, respectiv, evalurile expresiilor de referire. Bibliotecile de funcii create pentru manipularea elementelor constitutive ale structurilor dinamice sau funciile membre ale claselor asociate acestor structuri, fie n forma direct, fie n forma recursiv, trebuie s asigure obinerea de adrese sau de poziii ale elementelor. Dup fiecare funcie trebuie realizate teste care determin eliminarea fluxurilor de prelucrare generatoare de incidente, atunci cnd referirile de variabile pointer nu mai aparin domeniului specific unui segment de memorie. n cadrul aplicaiei e-DSI, fiind scris n limbajul Java, alocrile dinamice se realizeaz ntr-o manier transparent programatorului.
177

Existena componentei specifice de eliberare a memoriei alocat conduce la reducerea posibilitilor de eroare din aceast direcie. Testarea programelor cu structuri dinamice implic un efort de testare mai mare dect n cazul structurilor statice, avnd n vedere faptul c algoritmii utilizai n manipularea structurilor de date dinamice sunt mai compleci, i de aceea, i costul asociat testrii acestor programe este mai ridicat.

8.7 Procese de testare pentru programele cu structuri agregate

Structurile de date agregate sunt vectorii de structur, vectorii de pointeri spre structuri, spre funcii sau alte modaliti de concatenare a structurilor neomogene. Testarea structurilor de date agregate vizeaz, pe de o parte, verificarea dac agregarea corespunde cerinelor enunate n problem i, pe de alt parte, vizeaz testarea coninutului cmpurilor referite pentru a vedea dac exist concordan ntre modul de iniializare i modul de utilizare. Numeroase programe conin structuri de date statice i structuri de date dinamice agregate. De exemplu pentru construirea unui graf se iau n considerare informaiile de descriere a nodurilor sub forma unui masiv de articole ca structur static, de care se conexeaz liste care descriu arcele incidente spre exterior fiecrui nod n parte. Exist situaii n care structurile arborescente oarecare au asociate noduri alocate dinamic i legturi ntre noduri, construite n acelai fel. Fiecare nod conine un cmp care indic numrul de pointeri iniializai cu adresele descendenilor i un vector de pointeri ca structur static n care se stocheaz adrese de descendeni. Testele care se efectueaz pentru structurile dinamice agregate au rolul de a stabili c legturile dintre noduri sunt cele existente n realitate i mai ales c proprietile structurii redau proprieti existente ntre elementele din realitate care fac obiectul reflectrii n plan informatic. Agregarea de tip omogen care conduce la obinerea vectorilor de vectori, listelor de liste, articolelor de articole, fiierelor de fiiere au corespondent n planul testrii includerea de structuri repetitive imbricate, n numr egal cu numrul gradului de agregare.

178

n structura:
#include <stdio.h> struct dlista { struct dlista *dprev; int info; struct dlista *dnext; }; struct lista { struct dlista * plista; struct lista *next; }; void main() { struct dlista x11,x12,x13, x31,x32,x33,x34 ; struct lista *py, y1, y2, y3; py=&y1; y1.next=&y2; y2.next=&y3; y3.next=NULL; y1.plista=&x11;x11.dnext=&x12;x12.dnext=&x13; x13.dnext=NULL; y2.plista=&x21;x21.dnext=&x22;x22.dnext=&x23;x23.dnext= &x24;x24.dnext=NULL; y3.plista=&x31;x31.dnext=&x32;x32.dnext=&x33;x33.dnext= &x34;x34.dnext=NULL; while(py!=NULL) { while(py->plista!=NULL) { py->plista=py->plista->dnext; } py=py->next; } }

x21,x22,x23,x24,

prezint interes deosebit stabilirea modului n care comutativitatea operaiilor de agregare implic comutativitate n expresiile de referire.
179

Testarea acestei structuri prezint o serie de dificulti, avnd n vedere att gradul de agregare, ct i utilizarea variabilelor de tip pointer. n cazul n care cercetrile evideniaz astfel de proprieti, n procesul de testare se reflect prin modul de combinare a valorilor existena capacitii de traversare a structurilor arborescente asociate prelucrrilor n care operatorii sunt componente referite prin intermediul variabilelor pointer. Costul testrii programelor care conin structuri de date agregate este mai mare dect n cazul programelor care utilizeaz structuri de date statice. Numrul de cazuri de test este mai mare avnd n vedere complexitatea ridicat a programelor i numrul crescut de posibiliti de eroare. Testarea tipologiilor de proceduri urmeaz necesitii definirii de construcii software nzestrate cu proprietatea de coeziune maxim. Fiecare procedur este ortogonal celorlalte componente din produsul software care se realizeaz. nseamn c fiecare procedur realizeaz un anumit tip de prelucrare bine definit, care nu se regsete sub nici o form n alte proceduri. Acest tip de structuri omogene de proceduri (omogenitatea fiind specific secvenelor care se includ n procedur) creeaz un nou mod de abordare a activitii de programare, caracterizat prin controlul redundanei i orientarea acesteia spre niveluri sczute. Specializarea echipelor pe tipologii de proceduri conduce la creterea productivitii n procesul de testare i n utilizarea eficient a mediilor de asistare a acestui proces. Cnd se elaboreaz un produs program complex format din module neomogene n raport cu tipurile de date utilizate se urmrete folosirea difereniat a tehnicilor de testare pornind de la tipurile de date preponderente. Se impune utilizarea la nivelul modulelor de structuri de date de aceeai categorie i se obine drept consecin definirea de date de test specifice, exclusiv lucrului cu matrice sau exclusiv lucrului cu liste sau exclusiv lucrului cu structuri arborescente. Deci, vor exista module care utilizeaz masive unidimensionale, module care opereaz cu masive bidimensionale, module care utilizeaz fiiere, module care lucreaz cu liste simple, module care lucreaz cu liste duble, module destinate lucrului cu arbori i module destinate lucrului cu grafuri, fr a se face combinaii ntre structuri. Este numai o aparen frmiarea produsului program ntr-un numr foarte mare de module, cu creterea numrului de niveluri, pentru c n realitate prin creterea omogenitii modulelor crete eficacitatea procesului de testare i, implicit, calitatea produsului program n ansamblu. Pentru fiecare tip de structur se definesc un set de obiective ale testrii i proceduri de testare care trebuie urmate. Rezultatul testrii trebuie
180

s impun modificri n textele surs care amelioreaz prelucrrile i la reluarea procesului de testare nu se mai obin aceleai erori. tiindu-se c structurile de control sunt concepute difereniat pentru implementarea operatorilor pe structuri de date, o combinare adecvat a testrii orientate pe structuri de control cu testarea orientat pe structuri de date va avea efecte deosebite, chiar n condiiile n care complexitatea pe ansamblu a produsului program final este deosebit de ridicat. Mai mult, sunt create n acest fel condiii de testare pe trei categorii specializate de structuri de control i pe un numr K de structuri de date, ceea ce conduce la existena unui numr de 3K tipologii combinate de date de test. Oricare ar fi modulul, va exista printre cele 3K tipologii de date de test exemplul care s permit evidenierea erorilor, prin teste mecanice, nc de la nceput. Etapa de testare trece din planul artei dezvoltrii de software n planul proceselor coerente, previzibile.

181

9
TESTAREA APLICAIEI e-DSI
9.1 Aplicaia e-DSI
Aplicaia e-DSI (electronic Domestic Services Integration) Servicii casnice electronice integreaz ase aplicaii independente: magazin aparate foto, buget, bibliotec, reete, agend i jurnal.
e-DSI

Aparate foto

Bugetul meu

Biblioteca mea

Reetele mele

Agenda mea

Jurnalul meu

Figura 9.1 Structura aplicaiei e-DSI

Din toate paginile aplicaiilor componente se poate ajunge la pagina principal a aplicaiei eDSI. Testarea aplicaiei s-a realizat prin testarea independent a fiecrei aplicaii componente, urmat de testarea ntregii aplicaii integrate. Pentru testare s-au stabilit ca obiective: testarea structural a fiecrui modul astfel nct s se ating o acoperire corespunztoare pentru execuia instruciunilor testarea funcional a aplicaiei realizat att pentru fiecare aplicaie n parte, ct i pentru aplicaia integrat; s-au stabilit cazuri de test pentru fiecare aplicaie n parte; testarea coninutului astfel nct s fie respectate cerinele din specificaii: font ct mai mare, aezarea simetric n pagin, butoane de dimensiuni mai mari i s fie vizibile; testarea bazelor de date pentru fiecare aplicaie n parte;
182

testarea securitii tranzaciilor n cazul transferului datelor privind cartea de credit prin intermediul creia se realizeaz plata; testarea performanelor n diverse condiii de trafic, n special pentru transferul prin intermediul linei telefonice.

Figura 9.2 Interfaa aplicaiei e-DSI

Testarea structural se realizeaz pentru fiecare fiier Java generat. Pentru testare se utilizeaz instrumentele Jakarta Cactus, HttpUnit i JUnit. Este analizat cu precdere metoda conine principala funcionalitate pentru fiecare component n parte. Numrul de linii surs i complexitatea au o influen asupra efortului testrii n cazul determinrii seturilor de date de test. Prin testarea coninutului s-a urmrit corectitudinea i aezarea n pagin a textelor i imaginilor din cadrul site-ului. Au fost identificate
_jspService(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) deoarece aceasta

183

urmtoarele probleme: fontul utilizat pentru texte era prea mic; la formulare, butoanele aveau dimensiuni mici; legturile cu alte pagini erau realizate prin imagini care aveau un text scris pe acelai fundal cu culoarea de fond; butoanele de navigare de la o nregistrare la alta n cadrul anumitor pagini erau de dimensiuni mici; anumite texte nu corespundeau cu cerinele specificate.
Testarea funcional a fost realizat pentru a constata dac aplicaia se comport n conformitate cu specificaiile sale. S-au avut n vedere: verificarea legturile paginilor; testarea formularelor; verificarea tranzaciilor pentru comerul electronic i pentru baze de date.

S-a procedat i la testarea bazelor de date prin verificarea corectitudinii execuiei interogrilor, a operaiilor de adugare i actualizare a datelor, precum i verificarea conexiunilor dintre site-ul Web i baza de date. Bazele de date utilizate sunt MS Access, conexiunea realizndu-se prin intermediul JDBC-ODBC. S-au constat: interogri n care nu corespundea numrul de parametri; interogri n care tipurile datelor utilizate nu se potriveau; interogri n care apreau nume de coloane ce nu existau n tabele; interogri care returnau rezultate incorecte; interogri care accesau toate datele i nu pe cea cutat; nchiderea conexiunii cu baza de date naintea utilizrii setului de date obinut; existena unei anumite stri a setului de date.

184

Pentru fiecare clas n parte au fost nregistrate comenzile SQL cu baza de date i numrul de apariii ale acestora:
Aplicaia Aparate foto Clasa cassa produse comanda detalii situatia rsi centralizator restit venit imprumut chelt dat adaug cartile iau dau restituiri imprumut retete retetanoua adaug caut edit modific insemn scriu caut Tip operaie INSERT SELECT

Bugetul meu

Biblioteca mea

Retetele mele Agenda mea

Jurnalul meu

SELECT SELECT SELECT (2), INSERT SELECT (6) SELECT INSERT INSERT INSERT INSERT INSERT SELECT UPDATE, DELETE, SELECT UPDATE, INSERT, SELECT SELECT SELECT SELECT INSERT INSERT SELECT UPDATE, SELECT SELECT SELECT INSERT, SELECT, UPDATE SELECT

Comanda SQL SELECT se utilizeaz pentru interogarea tabelelor bazei de date i selectarea nregistrrilor care ndeplinesc anumite condiii, comanda INSERT se utilizeaz pentru adugarea de noi nregistrri n tabele, comanda UPDATE actualizeaz anumite cmpuri ale nregistrrilor i comanda DELETE terge una sau mai multe nregistrri care ndeplinesc anumite condiii.

185

Din analiza tabelului privind operaiile efectuate asupra tabelelor bazelor de date, rezult c sunt 24 interogri, 11 inserri, 4 actualizri i o tergere, n total 39 comenzi SQL. Pentru fiecare comand s-a executat un test n baza de date. Testarea securitii tranzaciilor este necesar s se realizeze n special pentru partea de transfer a datelor personale ale utilizatorilor (nume, adresa, informaii despre cartea de credit) n cazul efecturii plii pentru produsele fotografice pe care doresc s le achiziioneze. Au fost testate performanele aplicaiei, determinndu-se comportamentul acesteia n condiiile accesrii prin intermediul unui modem (56 Kbps), a unei reele LAN 10/100 Mbps. Testele au fost realizate pentru un singur client. Majoritatea erorile care apar la execuie sunt captate i descrierea acestora este transmis clientului sub forma unui text care conine numele excepiei i fiierele surs n care a aprut. Mesajul 500 Servlet Exception apare n bara de titlu a aplicaiei.

9.2 Aparate foto

Pentru achiziii de bunuri se face exemplificare pentru aparate fotografice. n cazul n care se extinde aplicaia, sunt dou soluii: se creeaz un nod numit Bunuri i din el se ramific prin clonare referiri pentru toate clasele de bunuri; sunt introduse prin clonare pe acelai nivel celelalte clase de bunuri. Cumprarea de produse prin intermediul Internetului ncepe s ia amploare i n ara noastr. A fost realizat un magazin virtual care comercializeaz aparate fotografice. Sunt prezentate aparate fotografice produse de diverse firme. Pentru fiecare aparat de fotografiat sunt prezentate modelul, preul i fotografia acestuia. Exist posibilitatea de a afla detalii suplimentare despre un anumit aparat de fotografiat prin selectarea acestuia. n momentul selectrii unui anumit produs, acesta poate fi adugat n coul de cumprturi. Dup ce au fost fcute cumprturile, se poate realiza plata. Oricnd este posibil renunarea la produsele adugate n coul de cumprturi. n figura 9.3 este prezentat structura aplicaiei Aparate foto.

186

Aparate foto

Produse

Detalii

Factura

Anulare

Cumprare

Plata

Figura 9.3 Structura aplicaiei Aparate foto

Aplicaia este alctuit din patru fiiere surs JSP i dou fiiere surs Java. n baza de date utilizat pentru teste sunt nregistrate urmtoarele produse: Canon 5 modele, FujiFilm 1 model, Kodak 1 model, Minolta 1 model, Nikon 3 modele, Olympus 1 model i Pentax 1 model. Nu exist nici un produs Konica i Ricoh . n vederea testrii se selecteaz trei productori pentru vizualizarea aparatelor de fotografiat existente.

187

Cazul 1.1.1 Se selecteaz Canon

Cazul 1.1.2 PRECONDIIE: S-a executat cazul 1.1.1. Se selecteaz butonul de navigare nainte Cazul 1.1.3 PRECONDIIE: S-a executat cazul 1.1.2. Se selecteaz butonul de navigare nainte Cazul 1.1.4 PRECONDIIE: S-a executat cazul 1.1.3. Se selecteaz butonul de navigare prima nregistrare Cazul 1.1.5 PRECONDIIE: S-a executat cazul 1.1.4. Se selecteaz butonul de navigare ultima nregistrare Cazul 1.1.6 Se selecteaz Minolta

Cazul 1.1.7 Se selecteaz Ricoh

Rezultat ateptat Se afieaz n pagin aparatele de fotografiat CNN10000/EOS300/300 USD i CNN10001/Prima Zoom 85/ 125 USD. Butoanele de navigare pentru prima nregistrare i napoi sunt dezactivate Rezultat ateptat Se afieaz n pagin aparatele de fotografiat CNN10002/A 100S/225 USD i CNN10003/Prima A/ 150 USD. Toate butoanele de navigare sunt active Rezultat ateptat Se afieaz n pagin aparatul de fotografiat CNN10004/EOS3/600 USD. Butoanele de navigare nainte i la ultima nregistrare sunt dezactivate. Rezultat ateptat Se afieaz n pagin aparatele de fotografiat CNN10000/EOS300/300 USD i CNN10001/Prima Zoom 85/ 125 USD. Butoanele de navigare pentru prima nregistrare i napoi sunt dezactivate Rezultat ateptat Se afieaz n pagin aparatul de fotografiat CNN10004/EOS3/600 USD. Butoanele de navigare nainte i la ultima nregistrare sunt dezactivate. Rezultat ateptat Se afieaz n pagin aparatele de fotografiat MNA10000/Vectis 300/290 USD i MNA10001/ Vectis 2000/ 270 USD. Toate butoanele de navigare sunt dezactivate. Rezultat ateptat n pagin nu exist nregistrri pentru acest productor. Toate butoanele de navigare sunt dezactivate.

Se selecteaz un produs pentru aflare detalii i cumprare.

188

Cazul 1.2.1 PRECONDIIE: S-a executat cazul 1.1.1. Se selecteaz aparatul cu codul CNN10000 Cazul 1.2.2 PRECONDIIE: S-a executat cazul 1.2.1. Se selecteaz opiunea Cumpr Cazul 1.2.3 PRECONDIIE: S-a executat cazul 1.2.2. Se selecteaz opiunea Factura Cazul 1.2.4 S-a PRECONDIIE: executat cazul 1.2.3. Se selecteaz opiunea Revenire Cazul 1.2.5 PRECONDIIE: S-a executat cazul 1.2.4. Se selecteaz aparatul cu codul CNN10001 Cazul 1.2.6 PRECONDIIE: S-a executat cazul 1.2.5. Se selecteaz opiunea Cumpr Cazul 1.2.7 PRECONDIIE: S-a executat cazul 1.2.6. Se selecteaz opiunea Factura

Rezultat ateptat n pagin sunt afiate detalii despre aparatul selectat: EOS300/Zoom: 28200/Greutate 300 g/ Pre 300 USD Rezultat ateptat Se efectueaz tranzacia. n pagin sunt afiate detalii despre aparatul selectat: EOS300/Zoom: 28-200/Greutate 300 g/ Pre 300 USD i Produse Comandate: 1 Rezultat ateptat n pagin sunt afiate detalii despre aparatul cumprat: EOS300/Cantitate: 1/ Pre 300 USD/ Pre cu TVA 357 USD, Total 357 USD Rezultat ateptat n pagin sunt afiate detalii despre aparatul cumprat: EOS300/Cantitate: 1/ Pre 300 USD, Pre cu TVA 357 USD Rezultat ateptat n pagin sunt afiate detalii despre aparatul selectat: CNN10001/Prima Zoom 85/ Pre125 USD

Rezultat ateptat Se efectueaz tranzacia. n pagin sunt afiate detalii despre aparatul selectat: CNN10001/Prima Zoom 85/ Pre125 USD i Produse Comandate: 2 Rezultat ateptat n pagin sunt afiate detalii despre aparatul cumprat: EOS300/Cantitate: 1/ Pre 300 USD/ Pre cu TVA 357 USD, CNN10001/Prima Zoom 85/ Pre125 USD/ Pre cu TVA 148.75 USD, Total 505.75 USD Cazul 1.2.8 Rezultat ateptat PRECONDIIE: S-a Se efectueaz tranzacia. Se face executat cazul 1.2.7. redirectarea la pagina cu productorii de Se selecteaz opiunea aparate fotografice Anulare

189

Se selecteaz opiunea PLATA pentru nregistrarea informaiilor despre cumprtor i cartea de credit.
Cazul 1.3.1 PRECONDIIE: S-au executat cazurile 1.2.1 1.2.7. Se selecteaz opiunea Plata Cazul 1.3.2 PRECONDIIE: S-a executat cazul 1.3.1. Se completeaz cmpurile formularului Se selecteaz opiunea Accept Rezultat ateptat n pagin este afiat suma total de plat 505.75 USD i un formular care trebuie completat de ctre cumprtor Rezultat ateptat Se efectueaz tranzacia. Se face redirectarea la pagina cu productorii de aparate fotografice

n total au fost proiectate 17 cazuri de test pentru aplicaia Aparate foto.

9.3 Bugetul meu

Gestiunea bugetului unei familii sau a unei persoane este necesar, de multe ori aprnd situaii n care nu se mai tie pe ce s-au cheltuit anumii bani sau cror persoane li se datoreaz bani sau crora le-au fost mprumutai bani. Sunt avute n vedere informaii privind veniturile, cheltuielile, datoriile i mprumuturile pe care le are utilizatorul. Aplicaia permite nregistrarea restituirilor realizate n contul datoriilor i a mprumuturilor. Informaiile nregistrate pot fi vizualizate fie pe fiecare categorie n parte, fie centralizat cu situaia bugetului disponibil la un moment dat. n figura 9.4 este prezentat structura aplicaiei Bugetul meu.

190

Bugetul meu

Venituri

mprumuturi

Cheltuieli

Datorii

Restituiri

Situaii

mprumuturi

Datorii

Venituri mprumuturi Cheltuieli Datorii

Centralizator

Figura 9.4 Structura aplicaiei Bugetul meu

Aplicaia realizat este alctuit din zece fiiere surs JSP. Se selecteaz opiunea obinute. Cazul 2.1.1 Se introduc valorile Suma: 1500000, Sursa: Salariu, Data: 1/8/2003 Se apas butonul Accept VENITURI, pentru nregistrarea de venituri
Rezultat ateptat Se efectueaz tranzacia. Valorile corespunztoare cmpurile Suma, Sursa, Data sunt terse

Cazul 2.1.2 Rezultat ateptat Se introduc valorile Suma: Se efectueaz tranzacia. Valorile 1400000, Sursa: Salariu, corespunztoare cmpurile Suma, Sursa, Data: 1/15/2003 Data sunt terse Se apas butonul Accept

Se selecteaz cheltuielilor efectuate.

opiunea

CHELTUIELI,

pentru

nregistrarea

191

Cazul 2.2.1

Rezultat ateptat

Se introduc valorile Suma: Se efectueaz tranzacia. 1000000, Destinaia: corespunztoare cmpurile Telefon, Data: 1/8/2003 Destinaia, Data sunt terse Se apas butonul Accept Cazul 2.2.2 Rezultat ateptat Se introduc valorile Suma: Se efectueaz tranzacia. 400000, Destinaia: Cadou, corespunztoare cmpurile Data: 1/16/2003 Destinaia, Data sunt terse Se apas butonul Accept

Valorile Suma,

Valorile Suma,

Se selecteaz opiunea MPRUMUTURI, pentru nregistrarea de sumelor de bani mprumutate altor persoane. Cazul 2.3.1 Rezultat ateptat Suma: 1000000, Destinaia: Se efectueaz tranzacia. Valorile D1, Moneda: ROL, Data corespunztoare cmpurilor Suma, mprumutrii: 1/10/2002/ Destinaia, Data mprumutrii, Termen Termen Restituire: Restituire sunt terse 1/10/2003 Cazul 2.3.2 Rezultat ateptat Suma: 1000, Destinaia: D2, Se efectueaz tranzacia. Valorile Moneda: USD, Data corespunztoare cmpurilor Suma, mprumutrii: 1/10/2002/ Destinaia, Data mprumutrii, Termen Termen Restituire: Restituire sunt terse 1/10/2003 Cazul 2.3.3 Rezultat ateptat Suma: 1000, Destinaia: D3, Se efectueaz tranzacia. Valorile Moneda: EURO, Data corespunztoare cmpurilor Suma, mprumutrii: 1/10/2002/ Destinaia, Data mprumutrii, Termen Termen Restituire: Restituire sunt terse 1/10/2003 Se selecteaz opiunea DATORII, pentru nregistrarea banilor mprumutai de la alte persoane.

192

Cazul 2.4.1 Suma: 500000, Sursa: S1, Moneda: ROL, Data mprumutului: 1/10/2003/ Termen Rambursare: 2/10/2003 Cazul 2.4.2 Suma: 500, Destinaia: S2, Moneda: USD, Data mprumutului: 1/10/2003/ Termen Rambursare: 2/10/2003 Cazul 2.4.3 Suma: 500, Sursa: S3, Moneda: EURO, Data mprumutului: 1/10/2003/ Termen Rambursare: 2/10/2003

Rezultat ateptat Se efectueaz tranzacia. Valorile corespunztoare cmpurilor Suma, Sursa, Data mprumutului, Termen Rambursare sunt terse Rezultat ateptat Se efectueaz tranzacia. Valorile corespunztoare cmpurilor Suma, Sursa, Data mprumutului, Termen Rambursare sunt terse Rezultat ateptat Se efectueaz tranzacia. Valorile corespunztoare cmpurilor Suma, Sursa, Data mprumutului, Termen Rambursare sunt terse

Se selecteaz opiunea RESTITUIRI MPRUMUTURI, pentru nregistrarea sumelor de bani primite de la persoanele crora le-au fost mprumutai.

Cazul 2.5.1 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Suma: 1000000, Destinaia: cazul de test 2.3.1 D1, UM: ROL, Data mprumut: 1/10/2002/ Se introduce Persoana: D1 Termen Restituire: 1/10/2003 Se apas butonul Caut Cazul 2.5.2 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Destinaia: D1, Suma cazul de test 2.5.1 mprumutat: 1000000, Restituiri: 0, Se selecteaz: D1 Moneda: ROL, Data mprumutului: 1/10/2002/ Termen Restituire: 1/10/2003. Cmpul Data restituirii este completat cu data curent. Se ateapt introducerea de valori n cmpul Suma restituit 193

Cazul 2.5.3 Rezultat ateptat PRECONDIIE: S-a executat Se efectueaz tranzacia. Se revine la cazul de test 2.5.2 Restituiri mprumuturi Se completeaz 300000 n cmpul Suma restituit Cazul 2.5.4 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Suma: 1000000, Destinaia: cazul de test 2.5.3 D1, UM: ROL, Data mprumut: Se introduce Persoana: D1 1/10/2002/ Termen Restituire: 1/10/2003 Se apas butonul Caut Cazul 2.5.5 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Destinaia: D1, Suma cazul de test 2.5.4 mprumutat: 1000000, Restituiri: 300000, Moneda: ROL, Data mprumutului: Se selecteaz: D1 1/10/2002/ Termen Restituire: 1/10/2003. Cmpul Data restituirii este completat cu data curent. Se ateapt introducerea de valori n cmpul Suma restituit Cazul 2.5.6 Rezultat ateptat PRECONDIIE: S-a executat Se efectueaz tranzacia. Se revine la cazul de test 2.5.5 Restituiri mprumuturi Se completeaz 200000 n cmpul Suma restituit Cazul 2.5.7 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Suma: 1000, Destinaia: D2, cazul de test 2.3.2 UM: USD, Data mprumut: 1/10/2002/ Se introduce Persoana: D2 Termen Restituire: 1/10/2003 Se apas butonul Caut Cazul 2.5.8 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Destinaia: D2, Suma cazul de test 2.5.7 mprumutat: 1000, Restituiri: 0, Moneda: Se selecteaz: D2 USD, Data mprumutului: 1/10/2002/ Termen Restituire: 1/10/2003. Cmpul Data restituirii este completat cu data curent. Se ateapt introducerea de valori n cmpul Suma restituit Cazul 2.5.9 Rezultat ateptat PRECONDIIE: S-a executat Se efectueaz tranzacia. Se revine la cazul de test 2.5.8 Restituiri mprumuturi Se completeaz 100 n cmpul Suma restituit

194

Se selecteaz opiunea RESTITUIRI DATORII, pentru nregistrarea sumelor de bani restituite persoanelor de la care s-au mprumutat bani. .Cazul 2.6.1 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Persoana: S1, Suma: 500000, cazul de test 2.4.1 UM: ROL, Data mprumut: 1/10/2003/ Se introduce Persoana: S1 Termen Restituire: 2/10/2003 Se apas butonul Caut
Cazul 2.6.2 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Persoana: S1, Suma cazul de test 2.6.1 mprumutat: 500000, Restituiri: 0, Se selecteaz: S1 Moneda: ROL, Data mprumutului: 1/10/2003/ Termen Restituire: 2/10/2003. Cmpul Data restituirii este completat cu data curent. Se ateapt introducerea de valori n cmpul Suma restituit Cazul 2.6.3 Rezultat ateptat PRECONDIIE: S-a executat Se efectueaz tranzacia. Se revine la cazul de test 2.6.2 Restituiri datorii. Se completeaz 300000 n cmpul Suma restituit Cazul 2.6.4 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Persoana: S1, Suma: 500000, cazul de test 2.6.3 UM: ROL, Data mprumut: 1/10/2003/ Se introduce Persoana: S1 Termen Restituire: 2/10/2003 Se apas butonul Caut Cazul 2.6.5 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Destinaia: S1, Suma cazul de test 2.5.4 mprumutat: 500000, Restituiri: 300000, Se selecteaz: S1 Moneda: ROL, Data mprumutului: 1/10/2003/ Termen Restituire: 2/10/2003. Cmpul Data restituirii este completat cu data curent. Se ateapt introducerea de valori n cmpul Suma restituit Cazul 2.6.6 Rezultat ateptat PRECONDIIE: S-a executat Se efectueaz tranzacia. Se revine la cazul de test 2.6.5 Restituiri datorii Se completeaz 200000 n cmpul Suma restituit 195

Cazul 2.6.7 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Suma: 500, Destinaia: S2, cazul de test 2.4.2 UM: USD, Data mprumut: 1/10/2003/ Se introduce Persoana: S2 Termen Restituire: 2/10/2003 Se apas butonul Caut Cazul 2.6.8 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz Destinaia: S2, Suma cazul de test 2.6.7 mprumutat: 500, Restituiri: 0, Moneda: Se selecteaz: S2 USD, Data mprumutului: 1/10/2003/ Termen Restituire: 2/10/2003. Cmpul Data restituirii este completat cu data curent. Se ateapt introducerea de valori n cmpul Suma restituit Cazul 2.6.9 Rezultat ateptat PRECONDIIE: S-a executat Se efectueaz tranzacia. Se revine la cazul de test 2.6.8 Restituiri datorii Se completeaz 100 n cmpul Suma restituit Se selecteaz opiunea SITUAII, pentru vizualizarea veniturilor, cheltuielilor, mprumuturilor, datoriilor i a unei situaii centralizate. Cazul 2.7.1 Rezultat ateptat PRECONDIIE: s-au Se afieaz Sursa: Salariu/ Suma: executat cazurile 2.1.1 i 1500000/Data: 1/8/2003 i Sursa: Salariu/ 2.1.2 Suma: 1400000/Data: 1/15/2003 Se selecteaz opiunea Venituri Cazul 2.7.2 Rezultat ateptat PRECONDIIE: s-au Se afieaz Sursa: Salariu/ Suma: executat cazurile 2.2.1, 2.2.2 1000000/Data: 1/8/2003 i Sursa: Salariu/ Se selecteaz opiunea Suma: 400000/Data: 1/16/2003 Cheltuieli Cazul 2.7.3 Rezultat ateptat PRECONDIIE: s-au Se afieaz Persoana: D1/Suma:1000000 executat cazurile 2.1.1, 2.1.2 /Moneda: ROL/Data: 1/10/2002/ i 2.1.3 Termen restituire: 1/10/2003; Persoana: Se selecteaz opiunea D2/Suma: 1000 /Moneda: Imprumuturi USD/Data: 1/10/2002/ Termen restituire: 1/10/2003; Persoana: D3 /Suma:1000 /Moneda: EURO/Data: 1/10/2002/ Termen restituire: 1/10/2003 196

Cazul 2.7.4 Rezultat ateptat PRECONDIIE: s-au Se afieaz Persoana: S1/Suma: 500000 executat cazurile 2.2.1, 2.2.2 /Moneda: ROL/Data: 1/10/2003 / i 2.2.3 Termen restituire: 2/10/2003; Persoana: Se selecteaz opiunea S2/Suma: 500 /Moneda: Datorii USD/Data: 1/10/2002/ Termen restituire: 1/10/2003; Persoana: S3 /Suma:500 /Moneda: EURO/Data: 1/10/2003/ Termen restituire: 2/10/2003 Cazul 2.7.5 Rezultat ateptat PRECONDIIE: s-au Se afieaz Venituri: 2900000/ Cheltuieli: executat cazurile 2.1.1, 2.1.2, 1400000 /Sold: 1500000/ Moneda: ROL/ 2.2.1, 2.2.2, 2.3.1, 2.3.2, Imprumuturi: 500000 /Datorii:0 2.3.3, 2.4.1, 2.4.2, 2.4.3 Se /Sold:500000 / Moneda: USD/ selecteaz opiunea Imprumuturi: 900 /Datorii:400 /Sold: 500 / Centralizator Moneda: EURO/ Imprumuturi:1000 /Datorii: 500 /Sold: 500

n total au fost proiectate 35 cazuri de test pentru aplicaia Bugetul meu.

9.4 Biblioteca mea

Una dintre activitile importante o reprezint gestionarea crilor din biblioteca unei familii. De multe ori este necesar nregistrarea crilor avnd n vedere c pot fi regsite cu uurin anumite cri, dac exist sau nu n biblioteca personal. Se ntmpl de multe ori ca membrii familiei s mprumute cri la prieteni i s uite de ele. Prin intermediul acestei aplicaii, utilizatorul are posibilitatea s nregistreze crile din bibliotec, crile mprumutate altor persoane i restituirea acestora, precum i s obin de informaii despre crile existente n bibliotec. Prin funcia de mprumut se face cutarea n baza de date a crilor dup autor sau titlu. n figura 9.5 este prezentat structura aplicaiei Biblioteca mea.

197

Biblioteca mea

Am cumprat

Am dat

Primesc

Crile mele

Figura 9.5 Structura aplicaiei Biblioteca mea Aplicaia realizat este alctuit din ase fiiere surs JSP. Se selecteaz opiunea AM CUMPRAT, pentru nregistrarea crilor noi n bibliotec. Cazul 4.1.1 Rezultat ateptat Se introduce Autor: Boris Se efectueaz tranzacia. Cmpurile Autor, Beizer, Titlu: Software Titlu, Editura, An sunt terse. Testing, Editura: NY, An: 1990 Cazul 4.1.2 Rezultat ateptat Se introduce Autor: Myers Se efectueaz tranzacia. Cmpurile Autor, G, Titlu: The Art of Software Titlu, Editura, An sunt terse. Testing, Editura: NY, An: 1979 Cazul 4.1.3 Rezultat ateptat Se introduce Autor: Se efectueaz tranzacia. Cmpurile Autor, Eminescu, Titlu: Poezii, Titlu, Editura, An sunt terse. Editura: Univers, An: 1985 Se selecteaz opiunea AM DAT, pentru nregistrarea crilor mprumutate altor persoane. Cazul 4.2.1 Rezultat ateptat Se selecteaz Autor. Se Apare n pagin: Cod:2, Autor: Myers G, introduce My* Se apas Titlu: The Art of Software Testing, butonul Caut. Editura: NY, An: 1979 Cazul 4.2.2 Rezultat ateptat PRECONDIIE: S-a executat Apare n pagin: Cartea de mprumutat cazul 4.2.1. Cod:2, Autor: Myers G, Titlu: The Art of Se selecteaz cartea de Myers Software Testing, Editura: NY, An: 1979. G. Cmpul Data este completat cu data curent. n cmpul Cui se ateapt introducerea numelui persoanei. 198

Cazul 4.2.3 PRECONDIIE: S-a executat cazul 4.2.2. Se introduce C1. Se apas butonul Accept. Cazul 4.2.4 Se selecteaz Titlu. Se introduce Soft* Se apas butonul Caut. Cazul 4.2.5 PRECONDIIE: S-a executat cazul 4.2.4. Se selecteaz cartea cu titlul Software Testing.

Rezultat ateptat Se efectueaz tranzacia. Se revine la pagina Am dat.

Rezultat ateptat Apare n pagin: Cod:1, Autor: Boris Beizer, Titlu: Software Testing, Editura: NY, An: 1990 Rezultat ateptat Apare n pagin: Cartea de mprumutat Cod:1, Autor: Boris Beizer, Titlu: Software Testing, Editura: NY, An: 1990. Cmpul Data este completat cu data curent. n cmpul Cui se ateapt introducerea numelui persoanei. Cazul 4.2.6 Rezultat ateptat PRECONDIIE: S-a executat Se efectueaz tranzacia. Se revine la cazul 4.2.5. pagina Am dat. Se introduce C2. Se apas butonul Accept.

Se selecteaz opiunea PRIMESC, pentru nregistrarea restituirilor crilor mprumutate. Cazul 4.3.1 Rezultat ateptat Se introduce Autor: Boris* Apare n pagin: Cod:1, Autor: Boris Beizer, Titlu: Software Testing, Editura: NY, An: 1990 Cazul 4.3.2 Rezultat ateptat PRECONDIIE: S-a executat Apare n pagin: S-a primit cartea Cod:1, cazul 4.3.1. Autor: Boris Beizer, Titlu: Software Se selecteaz cartea cu titlul Testing, Editura: NY, An: 1990, Persoana: Software Testing. C2. Cmpul Data 1/1/2003 Cazul 4.3.3 Rezultat ateptat PRECONDIIE:S-a executat Se efectueaz tranzacia. Se revine la cazul 4.3.2. pagina Restituiri. Se apas Accept Se selecteaz opiunea CRILE MELE, pentru vizualizarea crilor din bibliotec.
199

Cazul 4.4.1 Rezultat ateptat PRECONDIIE: S-au Se afieaz n pagin Cod:1, Autor: Boris executat cazurile 4.1.1, 4.1.2, Beizer, Titlu: Software Testing, Editura: 4.1.3, 4.2.3, 4.3.3 NY, An: 1990, In biblioteca: DA/ Cod:2, Autor: Myers G, Titlu: The Art of Software Testing, Editura: NY, An: 1979, In biblioteca: NU / Cod: 3, Autor: Eminescu, Titlu: Poezii, Editura: Univers, An: 1985, In biblioteca: DA. Butoanele de navigare nainte, napoi, la nceput i la sfrit sunt inactive

n total au fost proiectate 13 cazuri de test pentru aplicaia BIBLIOTECA MEA.

9.5 Agenda mea

Evidena electronic a numerelor de telefon i ale datelor de natere a persoanelor cunoscute este util. Aplicaia permite nregistrarea de informaii despre persoane, cum ar fi: nume, prenume, data naterii, adresa i numere de telefon de acas, de la serviciu i de mobil, informaii ce vor fi regsite ulterior pe baza unor criterii specifice (nume, prenume, telefon sau data naterii). n figura 9.6 este prezentat structura aplicaiei Agenda mea.
Agenda mea

Adaug

Caut

Modific

Figura 9.6 Structura aplicaiei Agenda mea

Aplicaia realizat este alctuit din patru fiiere surs JSP. Se selecteaz opiunea ADAUG, pentru nregistrarea n agend a datelor pentru o persoan nou.

200

Cazul 5.1.1 Se introduce Nume: AAA, Prenume: BBB, Telefon acas: 800000, Data Naterii: 1/8/1980. Nu se completeaz Telefon serviciu i telefon mobil. Se apas Accept Cazul 5.1.2 Se introduce Nume: HHH, Prenume: JJJ, Telefon acas: 890000, Telefon serviciu: 21111111, Telefon mobil: 074444444 Data Naterii: 1/8/1969. Se apas Accept

Rezultat ateptat Este efectuat tranzacia. Se revine la pagina Adaug

Rezultat ateptat Este efectuat tranzacia. Se revine la pagina Adaug

Se selecteaz opiunea CAUT, pentru regsirea informaiilor privind o anumit persoan. Cazul 5.2.1 Rezultat ateptat PRECONDIIE: S-au Se afieaz: Nume: AAA, Prenume: BBB, executat cazurile 5.1.1 i Telefon acas: 800000, Data Naterii: 5.1.2 1/8/1980. Se selecteaz Nume. Se introduce AAA. Se apas caut. Cazul 5.2.2 Rezultat ateptat PRECONDIIE: S-au Se afieaz n pagin: Nume: HHH, executat cazurile 5.1.1 i Prenume: JJJ, Telefon acas: 890000, 5.1.2 Telefon serviciu: 21111111, Telefon Se selecteaz Telefon. Se mobil: 074444444 Data Naterii: 1/8/1969 introduce 21111111. Se apas Caut Se selecteaz opiunea MODIFIC, pentru modificarea anumitor cmpuri din agend

201

Cazul 5.3.1 PRECONDIIE: S-au executat cazurile 5.1.1 i 5.1.2 Se selecteaz Nume. Se introduce AAA. Se apas caut. Cazul 5.3.2 PRECONDIIE: S-a executat cazul 5.3.1 Se selecteaz AAA. Cazul 5.3.3 PRECONDIIE: S-a executat cazul 5.3.2 Se introduce 7777777 la Telefon serviciu. Se apas Accept Cazul 5.3.4 PRECONDIIE: S-a executat cazul 5.3.3 Se selecteaz Nume. Se introduce AAA. Se apas Accept

Rezultat ateptat Se afieaz: Nume: AAA, Prenume: BBB, Telefon acas: 800000, Data Naterii: 1/8/1980.

Rezultat ateptat Se afieaz: Nume: AAA, Prenume: BBB, Telefon acas: 800000, Data Naterii: 1/8/1980. Rezultat ateptat Se efectueaz tranzacia. Se revine la pagina Modific

Rezultat ateptat Se afieaz: Nume: AAA, Prenume: BBB, Telefon acas: 800000, Telefon serviciu: 7777777, Data Naterii: 1/8/1980.

n total au fost proiectate opt cazuri de test pentru aplicaia Agenda mea.

9.6 Reetele mele

Aplicaia permite nregistrarea de reete culinare pe diverse categorii (ciorbe, mncruri i prjituri) precum i regsirea acestora. n figura 9.7 este prezentat structura aplicaiei Reetele mele.

202

Reetele mele

Reet nou

Ciorbe

Mncruri

Prjituri

Figura 9.7 Structura aplicaiei Reete

Aplicaia realizat este alctuit din dou fiiere surs JSP. Se selecteaz opiunea noi reete. Cazul 5.1.1 Se alege categoria Ciorbe Se introduc Denumire: C1, Cantiti: 5 l, Proces: Se fierbe Se selecteaz Accept Cazul 5.1.2 Se alege categoria Ciorbe Se introduc Denumire: C2, Cantiti: 6 l, Proces: Se fierbe apa Se selecteaz Accept Cazul 5.1.3 Se alege categoria Mincaruri Se introduc Denumire: M1, Cantiti: 1 pui, Proces: Se prjete Se selecteaz Accept REET NOU, pentru nregistrarea unei
Rezultat ateptat Se efectueaz nregistrarea. Cmpurile Denumire, Cantiti i Proces sunt terse

Rezultat ateptat Se efectueaz nregistrarea. Cmpurile Denumire, Cantiti i Proces sunt terse

Rezultat ateptat Se efectueaz nregistrarea. Cmpurile Denumire, Cantiti i Proces sunt terse

203

Cazul 5.1.4 Se alege categoria Mincaruri Se introduc Denumire: M2, Cantiti: 2 pui, Proces: Se fierbe Se selecteaz Accept Cazul 5.1.5 Se alege categoria Prjituri Se introduc Denumire: P1, Cantiti: 5 g, Proces: Se coace Se selecteaz Accept Cazul 5.1.6 Se alege categoria Prjituri Se introduc Denumire: P2, Cantiti: 10 g, Proces: Se amestec Se selecteaz Accept Se selecteaz opiunea aceast categorie. Cazul 5.2.1 PRECONDIIE: S-a executat cazul 5.1.1

Rezultat ateptat Se efectueaz nregistrarea. Cmpurile Denumire, Cantiti i Proces sunt terse

Rezultat ateptat Se efectueaz nregistrarea. Cmpurile Denumire, Cantiti i Proces sunt terse

Rezultat ateptat Se efectueaz nregistrarea. Cmpurile Denumire, Cantiti i Proces sunt terse

CIORBE, pentru vizualizarea reetelor din

Rezultat ateptat Se afieaz n pagin Cod: 1, Denumire: C1, Cantiti: 5 l, Proces: Se fierbe. Butoanele nainte i la sfrit sunt active iar butoanele la nceput i napoi sunt inactive Cazul 5.2.2 Rezultat ateptat PRECONDIIE: S-a executat Se afieaz n pagin Cod: 2, Denumire: cazul 5.1.2 i 5.2.1 C2, Cantiti: 6 l, Proces: Se fierbe apa. Se selecteaz butonul nainte Butoanele nainte i la sfrit sunt inactive iar butoanele la nceput i napoi sunt active 204

Se selecteaz opiunea MNCRURI, pentru vizualizarea pentru vizualizarea reetelor din aceast categorie. Cazul 5.3.1 Rezultat ateptat PRECONDIIE: S-a Se afieaz n pagin Cod: 3, Denumire: executat cazul 5.1.3 M1, Cantiti: 1 pui, Proces: Se prjete. Butoanele nainte i la sfrit sunt active iar butoanele la nceput i napoi sunt inactive Cazul 5.3.2 Rezultat ateptat PRECONDIIE: S-a Se afieaz n pagin Cod: 4, Denumire: executat cazul 5.1.4 i 5.3.1 M2, Cantiti: 2 pui, Proces: Se fierbe. Se selecteaz butonul nainte Butoanele nainte i la sfrit sunt inactive iar butoanele la nceput i napoi sunt active Se selecteaz opiunea PRJITURI, pentru vizualizarea pentru vizualizarea reetelor din aceast categorie. Cazul 5.4.1 Rezultat ateptat PRECONDIIE: S-a Se afieaz n pagin Cod: 5, Denumire: executat cazul 5.1.5 P1, Cantiti: 5 g, Proces: Se coace. Butoanele nainte i la sfrit sunt active iar butoanele la nceput i napoi sunt inactive Cazul 5.4.2 Rezultat ateptat PRECONDIIE: S-a Se afieaz n pagin Cod: 6, Denumire: executat cazul 5.1.6 i 5.4.1 P2, Cantiti: 10 g, Proces: Se amestec. Se selecteaz butonul nainte Butoanele nainte i la sfrit sunt inactive iar butoanele la nceput i napoi sunt active n total au fost proiectate 12 cazuri de test pentru aplicaia Reetele mele.
205

9.7 Jurnalul meu

Aplicaie ce permite realizarea nsemnrilor zilnice, consultarea acestora i cutarea nsemnrilor pentru o anumit zi. n figura 9.8 este prezentat structura aplicaiei Jurnalul meu.
Jurnalul meu

Scriu

nsemnri

Caut

Figura 9.8 Structura aplicaiei Jurnal

Aplicaia realizat este alctuit din trei fiiere surs JSP. n continuare sunt prezentate cazuri de utilizare pentru aplicaia Jurnalul meu pentru cele trei opiuni: Scriu, nsemnri i Caut. Se selecteaz opiunea SCRIU, pentru nregistrarea unor noi nsemnri n jurnal.

Cazul 6.1.1 Rezultat ateptat Se pstreaz data curent Se va realiza inserarea nregistrrii n baza afiat de date Se scrie nregistrarea: Primul test Jurnal Se selecteaz opiunea Accept 206

Cazul 6.1.2 Se introduce data: 10/12/2003 nregistrarea: Se scrie nsemnri pentru 10/12/2003 Se selecteaz opiunea Accept Cazul 6.1.3 Se introduce o data invalid: 29/29/2003 Se scrie nregistrarea: Test cu dat invalid Se selecteaz opiunea Accept Cazul 6.1.4 Se terge date curent Nu se scrie nimic n cmpul cu nsemnri Se selecteaz opiunea Accept

Se va realiza inserarea nregistrrii n baza de date

Se ateapt un mesaj de eroare

Nu se opereaz nici o nregistrare n baza de date

Se selecteaz nsemnrilor din jurnal.

opiunea

NSEMNRI,

pentru

vizualizarea

207

Cazul 6.2.1 Rezultat ateptat PRECONDIIE: n jurnal nu Se va afia pagina corespunztoare sunt nsemnri vizualizrii nsemnrilor, fr nici o nregistrare, i toate butoanele de navigare sunt dezactivate Cazul 6.2.2 PRECONDIIE: n jurnal Se va afia pagina corespunztoare exist nregistrarea: vizualizrii nsemnrilor, cu nregistrarea 1/9/2003, Primul test Data: 1/9/2003, nsemnarea: Primul test. Butoanele de navigare sunt dezactivate Cazul 6.2.3 PRECONDIIE: n jurnal Se va afia pagina corespunztoare exist pe lng nregistrarea vizualizrii nsemnrilor, cu nregistrarea de la 6.2.2 i nregistrarea: Data: 1/9/2003, nsemnarea: Primul test. 10/12/2003, nsemnri Butoanele de navigare la nceput i pentru 10/12/2003 nregistrarea precedent sunt dezactivate. Cazul 6.2.4 PRECONDIIE: S-a executat 6.2.2 Se apas butonul de trecere la urmtoarea nregistrare Cazul 6.2.5 PRECONDIIE: S-a executat 6.2.4 Se apas butonul de trecere la prima nregistrare

Apare nregistrarea Data: 10/12/2003, nsemnarea: nsemnri pentru 10/12/2003. Butoanele de navigare nainte i la ultima nregistrare sunt dezactivate. Se va afia pagina corespunztoare vizualizrii nsemnrilor, cu nregistrarea Data: 1/9/2003, nsemnarea: Primul test. Butoanele de navigare la nceput i nregistrarea precedent sunt dezactivate.

208

Cazul 6.2.6 PRECONDIIE: S-a Apare nregistrarea Data: 10/12/2003, executat 6.2.5 nsemnarea: nsemnri pentru 10/12/2003. Se apas butonul de trecere la Butoanele de navigare nainte i la ultima ultima nregistrare nregistrare sunt dezactivate. Se selecteaz opiunea CAUT, pentru vizualizarea unei nsemnri din jurnal de la o anumit dat. Data este introdus de la tastatur. Se consider c exist nregistrrile pentru 1/9/2003 i pentru 10/12/2003. Cazul 6.3.1 Rezultat ateptat Se introduce data: 1/9/2003 Se va afia nsemnarea: Primul test Se apas butonul Caut corespunztoare datei 1/9/2003 Cazul 6.3.2 Se introduce data: Se va afia nsemnarea: nsemnri pentru 10/12/2003 10/12/2003 corespunztoare datei Se apas butonul Caut 10/12/2003 Cazul 6.3.3 Nu se introduce nici o dat Nu se va afia nici o nregistrare Se apas butonul Caut Cazul 6.3.4 Se introduce data 1/1/1999 Nu se va afia nici o nregistrare Cazul 6.3.5 Se introduce data Nu se va afia nici o nregistrare 29/29/2003 Pentru aplicaia jurnal au fost proiectate 15 cazuri de test. n total au fost identificate 97 de cazuri de test funcionale pentru aplicaia e-DSI. Pe lng aceste cazuri de test, prin care se verific dac aplicaia respect specificaiile, sunt luate n calcul i cazuri de test pentru a testa comportamentul aplicaiei atunci cnd sunt introduse valori care nu aparin domeniului sau cmpurile nu sunt completate cu valori. Aplicaia este astfel proiectat nct utilizatorii neinformaticieni selecteaz opiuni din aproape in aproape. n interaciune, utilizatorul introduce texte, care au exclusiv rol de ir de caractere fr a determina selecii ale procedurilor de prelucrare.

209

10
UTILIZAREA MODELELOR DE EVALUARE A COSTURILOR N TESTAREA APLICAIEI e-DSI
10.1 Particularitile gestiunii electronice a serviciilor casnice
Sistemele de gestiune electronic a serviciilor casnice se bazeaz pe arhitectura Web, ceea ce confer acestora o fiabilitate, scalabilitate i flexibilitate ridicate. n figura 10.1 este prezentat arhitectura sistemelor de gestiune electronic a serviciilor casnice, care fac parte din categoria sistemelor de afaceri electronice.

Navigator

Server Web

Server de aplicaii

Baza de date

Server de pli

Figura 10.1 Arhitectura sistemelor de gestiune electronic a serviciilor casnice

Un software pentru gestiunea electronic a serviciilor casnice include componente pentru realizarea prezentrii, componente pentru efectuarea sigur a plilor cu ajutorul crilor de credit sau de debit i componente pentru securizarea tranzaciilor.
210

Principalele caracteristici ale unei aplicaiilor electronice care ofer servicii de succes sunt [SAMA99]: capacitatea de utilizare problemele cu interfaa utilizator duc la pierderea clienilor; testarea capacitii de utilizare const n verificarea funcionalitii interfeei, a uurinei de utilizare precum i a modului n care aceasta a fost proiectat; scalabilitatea - trebuie avut n vedere faptul ca succesul va aduce creterea cererii; sigurana controlul accesului, autentificarea i integritatea sunt foarte importante pentru desfurarea proceselor de afaceri electronice; testarea securitii sistemului este obligatorie pentru marea majoritate a aplicaiilor pentru afaceri electronice; fiabilitatea defectele sunt de nenchipuit pentru un sistem de afaceri critic, testarea aplicaiilor avnd un rol foarte important; bugetul i timpul alocat pentru activitatea de testare trebuie s fie corespunztoare; mentenabilitatea ratele crescute de schimbare sunt fundamentale pentru afacerile electronice; disponibilitatea cderea este prea scump pentru a fi tolerat; testarea la solicitare joac un rol important n determinarea limitelor aplicaiei; eficiena neutilizarea optim a resurselor hardware i software duce la scderea performanelor i scalabilitii aplicaiilor. Pentru proiectarea aplicaiilor de gestiune electronic a serviciilor casnice se utilizeaz att standarde tehnologice (XML, COM+, CORBA, RMI), ct i standarde pentru procese de afaceri (OFX pentru pli, OBI, ICE pentru schimburile informaionale, SWAP). Aplicaiile pentru gestiunea electronic a serviciilor casnice, asemntor aplicaiilor de comer electronic, necesit specialiti pentru administrarea serverului Web, a serverului de baze de date i a serverului de pli electronice.

10.2 Aplicaia e-DSI utilizat n analiza modelelor de evaluare a CTS

Societatea informaional presupune dezvoltarea unor aplicaii noi care s poteneze resursele umane, s permit dezvoltarea de noi forme de munc, dar n acelai timp s apropie omul de serviciile publice i de tranzacii materiale i valorice cu efecte directe asupra minimizrii timpului
211

necesar obinerii de servicii sau bunuri. n [GHIL02] sunt prezentate o serie de domenii n care au fost implementate aplicaii electronice, precum i oportunitile oferite de aceste aplicaii. Dac acum atenia este ndreptat spre aplicaii foarte mari, precum licitaia electronic, pli de impozite i taxe, tranzacii bancare, n viitorul imediat se va pune problema n mod deosebit a utilizrii resurselor Internet de ctre ceteni pentru soluionarea de probleme cotidiene. Toate acestea vizeaz serviciile casnice pe care familiile trebuie s le obin cu ajutorul unor aplicaii eterogene care trebuie integrate din aproape n aproape ntr-un tot unitar. La ora actual la noi n ar exist disparate magazine virtuale, posibiliti de gestionare a bugetului de familie, mersul trenurilor. Se pune problema testrii acestor aplicaii independente pentru a obine acelai nivel de calitate ridicat pentru toate viitoarele componente ale aplicaiei care vor face obiectul integrrii. Se testeaz separat folosind tehnica adecvat de testare. Produsul final, rezultat al integrrii, va fi la rndul lui testat. Toate datele privesc componentele i ntregul i modelele sunt elaborate pe aceste date. Avnd n vederea generalitatea acestui tip de aplicaie, metodele definite i implementate precum i modelele elaborate sunt utilizate direct n orice aplicaie fr modificri semnificative. Aplicaia integrat e-DSI (electronic Domestic Services Integration) este alctuit din urmtoarele aplicaii componente: Aparate foto; un magazin virtual care comercializeaz aparate fotografice; Bugetul meu; gestiunea veniturilor, cheltuielilor, mprumuturilor i a datoriilor unei familii; Biblioteca mea; gestiunea crilor din bibliotec; Reetele mele; nregistrarea de reete culinare, grupate pe trei categorii; Agenda mea; evidena numerelor de telefon; Jurnalul meu; nregistrarea i regsirea nsemnrilor zilnice. Aceste funcii au fost descrise n detaliu n Capitolul 9. Pentru a evidenia ntregul proces de testare este necesar traversarea tuturor etapelor ciclului de dezvoltare i realizarea cuantificrilor specifice n vederea obinerii de serii de date cu ajutorul crora s poat fi estimai coeficienii modelelor de evaluare a costului testrii n diferite ipoteze referitoare la structur.

212

Pentru dezvoltarea unei aplicaii complexe, pe lng serviciile oferite de e-DSI pot fi incluse i urmtoarele elemente: informarea asupra unor servicii; informaii privind numerele de telefoane ale unor instituii sau firme, actele necesare realizrii unor tranzacii; programarea vacanelor; achiziionarea de bilete; cumprarea de bilete pentru transportul feroviar, aerian sau auto pentru destinaii lungi; rezervri de locuri la hotel; efectuarea de abonamente; pe aceast cale este posibil s se fac abonamente la ziare i reviste, pentru mijloace de transport n comun, pentru tren, la competiii sportive; efectuarea aprovizionrii curente; posibilitatea de a cumpra bunuri pentru necesitile zilnice; programri medicale; programarea edinelor la medicul de familie, la policlinici sau la cabinetele de stomatologie; contabilitatea casnic; realizarea unor activiti contabile simple la nivelul unei familii sau a unei asociaii familiale; documentare pe teme date; sunt puse la dispoziie o serie de informaii cu privire la domenii care prezint interes n funcie de preferine; consultan juridic; informaii privind aspecte juridice simple sunt puse la dispoziia persoanelor interesate; memorarea i regsirea informaiilor; util pentru gestiunea documentelor personale; precum i orice alt activitate care i regsete utilitatea n serviciile casnice. Arhitectura aplicaiei e-DSI este prezentat n figura 10.2. Arhitectura conine elementele de baz necesare funcionrii aplicaiei i sunt prezentate att componentele la nivel generic, ct i cele utilizate efectiv la dezvoltarea aplicaiei. Arhitectura are la baz instrumente care exist la ora actual, dar dac vor aprea alte instrumente, alte tehnologii, funciile de baz prezentate n figura 10.2 trebuie s fie realizate pstrnd aceleai niveluri ale caracteristicilor.

213

Client1

Server Web (Apache) Motor JSP (Resin)

Driver acces la BD (JDBC-ODBC)

Baze de date

Client2

Clientn

e-DSI

Figura 10.2 Arhitectura aplicaiei e-DSI

Pentru realizarea aplicaiei e-DSI a fost utilizat tehnologia Java JSP. Clienii, prin intermediul unui navigator Internet, acceseaz pagini JSP care conin cod Java executat pe maina virtual Java (JVM) de pe sever. Rezultatele prelucrrilor efectuate sunt trimise clientului n format HTML prin serverul Web. n [ROC00] i [ROC04] sunt descrise n detaliu mecanismele acestor tehnologii. Fiierele JSP sunt transformate de ctre procesorul JSP n fiiere surs Java, care conin pe lng codul existent n fiierele JSP i secvene de cod propriu motorului JSP. Aplicaia a fost realizat utiliznd mediile de dezvoltare Dreamweaver i JBuilder.

10.3 Structuri de modele pentru evaluarea costurilor testrii aplicaiei

Pe durata dezvoltrii aplicaiei au fost colectate numeroase date privind procesul de testare, urmnd aceleai proceduri pentru a asigura comparabilitatea. Costurile testrii sunt influenate de o serie de factori enumerai n capitolul 3. Pentru aplicaia e-DSI sunt selectai urmtorii factori, avnd n vedere importana acestora n determinarea efortului pentru testarea software: dimensiunea modulelor (D) exprimat ca numr de linii surs; complexitatea ciclomatic a aplicaiei (C); numrul de parametri (NP); productivitatea muncii (W) exprimat n numr de linii surs/zi;
214

 numrul de elemente de interfa (NI); numrul de module (NM). Msurtorile efectuate pentru aplicaia e-DSI n privina numrului de linii surs i a complexitii ciclomatice au fost realizate cu ajutorul programului JMetric (www.jmetric.com). Durata total a testrii aplicaiei e-DSI de-a lungul perioadei de dezvoltare a fost de circa 70 ore, respectiv 8 zile i 6 ore. Aceasta reprezint aproximativ 30% din totalul perioadei de realizare a aplicaiei. n figura 10.3 sunt prezentate duratele nregistrate n procesului de testare a aplicaiei e-DSI.

Figura 10.3 Durata procesului de testare pentru aplicaia e-DSI

Pentru testare au fost necesare activiti de documentare i configurare care se regsesc n consumul de resurse (tabelul 10.1).
Tabelul 10.1 Durata de documentare i configurare (numr ore) Activitate Durat Documentare privind mediile de dezvoltare 6 Documentare privind instrumentele de testare 8 Configurare mediu de testare 3 TOTAL 17

n tabelul 10.2 sunt prezentate nregistrrile privind cazurile de test necesare testrii funcionale a aplicaiei e-DSI precum i evaluarea efortului testrii funcionale a aplicaiei. Duratele msurate se exprim de regul, n uniti de timp precum, minute, ore, zile, sptmni, n funcie de capacitatea de nregistrare a datelor. Pentru aplicaia e-DSI, avnd n vedere c obiectivul urmrit este de a estima coeficienii unor modele, s-a
215

considerat necesar utilizarea ca unitate de msur a duratelor numrul de minute, aceasta presupunnd un efort deosebit de ridicat. n mod curent se utilizeaz pentru unitatea de msur numrul de zile.
Tabelul 10.2 Duratele nregistrate pentru testarea funcional Cazuri de test Durate pe faze Execuie

Aplicaia

Aparate foto Bugetul meu Biblioteca mea Reetele mele Agenda mea Jurnalul meu TOTAL

17 35 13 12 8 12 97

85 175 65 60 40 60 485

34 70 26 24 16 24 194

51 105 39 36 24 36 291

nregistrar e rezultate

Numr

Proiectare

Redactare

Testare TOTAL coninut

34 70 26 24 16 24 194

60 80 60 20 40 30 290

264 500 216 164 136 174 1454

n tabelul 10.3 se regsesc numrul de clase i, centralizat pe fiecare clas, numrul de linii surs, complexitatea ciclomatic i numrul de elemente de interfa de intrare de tip text. Din analiza tabelului 10.3 se observ c aplicaiile Bugetul meu i Biblioteca mea au cele mai multe linii surs i complexitatea cea mai ridicat. n tabelul 10.4 sunt nregistrate pentru fiecare modul testat numrul de linii surs, complexitatea ciclomatic, productivitatea muncii i numrul de parametri. Pentru cele 29 de clase existente n aplicaia e-DSI au fost identificate 33 de metode i s-au realizat 72 de cazuri de test. Durata total a testrii structurale a fost de circa 20 ore. Pentru un specialist n testare, costul pe or se consider de 60 USD.

216

Tabelul 10.3 nregistrri privind aplicaia e-DSI

Aplicaia Aparate foto Bugetul meu Biblioteca mea Reetele mele Agenda mea Jurnalul meu Total

Numr module 6 8 6 2 4 3 29

Numr linii surs 789 994 929 690 488 481 4371

Complexitate ciclomatic 107 139 135 65 62 82

Numr elemente de intrare 7 20 8 3 14 3 55

Tabelul 10.4 nregistrri privind testarea structural Productivitatea muncii Complexitate ciclomatic Dimensiune modul Cost efectiv Numr parametri Modul

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

29 63 54 76 28 199 64 60 65 73 123 27 28 29 84 86 89

2 9 2 9 3 43 8 7 7 7 15 3 2 3 8 10 15

8 4 10 4 6 3 4 4 4 4 2 5 7 7 3 7 3

80 80 80 80 70 70 70 70 60 80 80 80 80 60 80 80 80

35 38 39 37 29 55 38 37 39 35 39 32 34 34 35 41 44
217

18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 TOTAL

27 49 58 67 240 41 191 40 4 2 2 2 2 8 27 200

3 5 3 6 47 6 43 3 1 1 1 1 1 1 2 43

5 9 4 5 4 3 3 4 1 0 0 1 0 7 6 4

60 60 60 60 60 70 60 70 60 60 60 60 60 70 60 60

28 39 34 36 58 30 56 32 21 18 18 19 18 28 36 59 1171

n figura 10.4 sunt prezentate ponderile pe care le are fiecare aplicaie n parte n ceea ce privete numrul de linii surs din numrul total de linii surs ale aplicaiei e-DSI.

11% 16%

11%

18%

23% 21%

Aparate foto Bugetul meu Biblioteca mea Retetele mele Jurnalul meu Agenda mea

Figura 10.4 Structura pe numr de linii surs pentru fiecare aplicaie n parte

218

Avnd n vedere seturile de date aferente factorilor determinani ai procesului de testare, au fost luate n considerare urmtoarele modele de evaluare a costului testrii.
Model liniar cu patru factori ML4

CTS = a 0 + a1 D + a 2 C + a3 NP + a 4W Pentru estimarea parametrilor modelului au fost utilizate observaiile din tabelul 10.4. Pe baza acestor date, folosind metoda celor mai mici ptrate cu funcia LINEST din Excel se obin estimrile din tabelul 10.5.
Tabelul 10.5 Parametrii estimai ai modelului ML4 Factorul Coeficient estimat Dimensiunea modulului 0.140079 Complexitatea ciclomatic 0.095989 Numrul de parametri 1.387015 Productivitatea muncii 0.037137 Termenul liber 17.00198

Ecuaia modelului liniar ML4 este:

CTS = 17.001 + 0.14 D + 0.095C + 1.38NP + 0.037W

Model liniar rafinat cu trei factori ML3

Modelul ML4 este rafinat prin reducerea numrului de factori. ML3 este obinut prin eliminarea factorului W. Modelul rafinat obinut este: CTS = a 0 + a1 D + a 2 C + a3 NP Pe baza datelor din tabelul 10.4, utiliznd metoda celor mai mici ptrate, prin aplicarea funciei LINEST din programul Excel s-au obinut estimrile coeficienilor modelului din tabelul 10.6.

219

Tabelul 10.6 Parametrii estimai ai modelului ML3 Factorul Coeficient estimat Dimensiunea modulului 0.148646 Complexitatea ciclomatic 0.055688 Numrul de parametri 1.403740 Termenul liber 19.32107

Ecuaia modelului liniar ML3 cu coeficienii estimai este:

CTS = 19.321 + 0.148D + 0.055C + 1.403NP

Model liniar unifactorial MLD

Se consider modelul liniar al costului testrii n funcie de dimensiunea aplicaiei: CTS = a 0 + a1 D Pe baza nregistrrilor din tabelul 10.4, aplicnd metoda celor mai mici ptrate, cu funcia LINEST din Excel se obin estimrile coeficienilor din tabelul 10.7.
Tabelul 10.7 Parametrii estimai ai modelului MLD Factorul Coeficient estimat Dimensiunea modulului 0.159135 Termenul liber 25.17963

Ecuaia modelului liniar MLD este:

CTS = 25.17 + 0.159D

Model liniar unifactorial MLC

Modelul liniar de evaluare a costului testrii n funcie de complexitatea ciclomatic a modulelor este: CTS = a0 + a1C Utiliznd datele din tabelul 10.4 se obin estimrile din tabelul 10.8 pe baza metodei celor mai mici ptrate cu funcia LINEST din Excel.
220

Tabelul 10.8 Parametrii estimai ai modelului MLC Factorul Coeficient estimat Complexitatea ciclomatic 0.677768 Termenul liber 28.91255

Ecuaia modelului liniar MLC este:

CTS = 28.912 + 0.677C

Model neliniar produs MNPD

Modelul de evaluare a costului testrii n funcie de dimensiunea modulelor construit cu o funcie produs este:
CTS = aD b

Prin liniarizare, folosind metoda celor mai mici ptrate s-au obinut cu funcia LINEST din Excel estimrile din tabelul 10.9.
Tabelul 10.9 Parametrii estimai ai modelului MNPD Coeficient Valoare estimat a 15.42219 b 0.220543

Ecuaia modelului neliniar MNPD este:

CTS = 15.422 D 0.22

Model neliniar exponenial MNEC

Se consider modelul neliniar exponenial de evaluare a costului testrii pe baza complexitii ciclomatice:
CTS = ke aC + b

Coeficientul k se consider constant, avnd valoarea 1.

221

Folosind datele din tabelul 10.4 prin aplicarea metodei celor mai mici ptrate la modelul liniar obinut prin logaritmare, cu ajutorul funciei LINEST din Excel se obin estimrile din tabelul 10.6 pentru coeficienii modelului.
Tabelul 10.10 Parametrii estimai ai modelului MNEC Parametru Valoare estimat a 0.017309 b 3.355077

Ecuaia modelului neliniar MNEC este:

CTS = e 0.017 C + 3.355

n mod asemntor se estimeaz parametrii modelelor prezentate n capitolele 5 i 6.

10.4 Analiza comparat a rezultatelor experimentale obinute

Pe baza nregistrrilor efectuate n timpul realizrii i testrii aplicaiei e-DSI au fost construite patru modelele liniare i dou modele neliniare de evaluare a costului testrii software.
Tabelul 10.11 Valorile efective ale costurilor i valorile obinute prin evaluare
Nr. Crt. 1 2 3 4 5 6 7 8 9 10 11 Cost efectiv 35 38 39 37 29 55 38 37 39 35 39 ML4 35.251 35.156 41.511 36.976 32.076 55.676 34.831 34.176 34.506 36.366 41.366 ML3 34.947 34.752 41.453 36.676 32.048 55.347 34.845 34.198 34.938 36.122 41.156 MLD 29.79 35.196 33.765 37.263 29.631 56.82 35.355 34.719 35.514 36.786 44.736 MLC 29.23 30.343 29.23 30.343 29.389 35.749 30.184 30.025 30.025 30.025 31.297 MNPD 32.34955 38.37034 37.0909 39.98708 32.10077 49.41837 38.50351 37.96068 38.63506 39.63435 44.45492 MNEC 29.6363 33.38144 29.6363 33.38144 30.14443 59.50141 32.81875 32.26555 32.26555 32.26555 36.96605

222

Nr. Crt. 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 Total

Cost efectiv 32 34 34 35 41 44 28 39 34 36 58 30 56 32 21 18 18 19 18 28 36 59 1171

ML4 30.926 33.731 33.226 36.621 42.611 37.986 30.186 38.976 33.146 36.071 62.806 30.041 54.186 30.996 21.256 19.596 19.596 20.976 19.596 30.466 31.471 56.826 1169.183

ML3 30.497 33.396 33.599 36.402 42.42 37.527 30.497 39.475 33.682 36.582 63.038 29.928 54.163 31.018 21.371 19.672 19.672 21.075 19.672 30.381 31.845 56.898 1169.292

MLD 29.472 29.631 29.79 38.535 38.853 39.33 29.472 32.97 34.401 35.832 63.339 31.698 55.548 31.539 25.815 25.497 25.497 25.497 25.497 26.451 29.472 56.979 1170.69

MLC 29.389 29.23 29.389 30.184 30.502 31.297 29.389 29.707 29.389 29.866 36.385 29.866 35.749 29.389 29.071 29.071 29.071 29.071 29.071 29.071 29.23 35.749 1004.976

MNPD 31.84496 32.10077 32.34955 40.87729 41.08945 41.40059 31.84496 36.30645 37.67861 38.89351 51.49762 34.91027 48.97428 34.72113 20.92155 17.96252 17.96252 17.96252 17.96252 24.36803 31.84496 49.47289 1161.452

MNEC 30.14443 29.6363 30.14443 32.81875 33.95377 36.96605 30.14443 31.18696 30.14443 31.72167 63.68824 31.72167 59.50141 30.14443 29.13674 29.13674 29.13674 29.13674 29.13674 29.13674 29.6363 59.50141 1148.138

n tabelul 10.11 sunt prezentate comparativ costurile efective ale testrii modulelor i costurile obinute prin aplicarea celor ase modele ai cror coeficieni au fost estimai. Din tabelul 10.11 se observ c cele mai apropiate valori evaluate de valoarea total efectiv sunt date de modelele MLD, ML4 i ML3, iar cea mai mare diferen se constat n cazul modelului MLC. n cazul n care se va proceda la proiectarea unei noi aplicaii distribuite se estimeaz numrul de module, dimensiunea modulelor ca numr de linii surs, complexitatea ciclomatic a modulelor, productivitatea muncii i numrul de parametri pentru aceste module. Utiliznd valorile estimate n modelele ML4, ML3, MLD, MLC, MNPD i MNEC se va obine costul estimat al testrii pe modul al noii aplicaii. Pentru aplicaia extins e-DSIEX valorile estimate pentru un modul sunt date n tabelul 10.12.
223

Tabelul 10.12 Valorile estimate pentru aplicaia e-DSIEX Variabil exogen Nivel estimat Dimensiunea modulului 1000 Complexitatea ciclomatic 30 Numrul de parametri 9 Productivitatea muncii 100 Costurile estimate pe baza nregistrrilor din tabelul 10.13 sunt date n tabelul 10.10. Aceste costuri calculate pe baza unor estimaii de niveluri au ncorporate un anumit nivel de imprecizie, dar creeaz o imagine vizavi de resursele necesare derulrii procesului. Tabelul 10.13 Nivelurile estimate ale costului testrii Modelul Cost estimat ML4 175.971 ML3 181.598 MLD 184.179 MLC 33.682 MNPD 70.49214 MNEC 47.70327 Se observ c exist diferene ntre valorile estimate ale costului testrii pentru un modul al aplicaiei extinse e-DSIEX. n continuare se ierarhizeaz modelele de evaluare a costului testrii software.

10.5 Ierarhizarea modelelor de evaluare a CTS

Coeficientul de determinare, care arat intensitatea legturii dintre variabilele independente i costul testrii software i valorile calculate pentru testul F corespunztoare celor ase modele sunt prezentate n tabelul 10.14. Valoarea calculat a testului F este dat pentru nivelul de semnificaie 0.05. Tabelul 10.14 Testul F pentru modelele de evaluare Coeficient Numr Numr de Modelul de F calculat F tabelar de factori observaii determinare ML4 4 33 0.948 128.0507639 2.71 ML3 3 33 0.947 174.288208 2.93 MLD 1 33 0.845 169.9923051 4.16 MLC 1 33 0.732 84.82053601 4.16 MNPD 1 33 0.915 333.7869 4.16 MNEC 1 33 0.543 36.96801 4.16
224

Din tabel se observ c pentru toate modelele valoarea calculat a lui F este mai mare dect valoarea tabelar, ceea ce conduce la concluzia c factorii de influen sunt bine alei i exist o relaie ntre ei i costul testrii software. Pentru fiecare model n parte este necesar s se determine semnificaia parametrilor de regresie. Pentru aceasta se utilizeaz testul t pentru coeficienii fiecrui model n parte. n tabelul 10.15 sunt date valorile testului t pentru parametrii celor ase modele. Valoarea tabelar este dat pentru =0.05. Tabelul 10.15 Valorile calculate i tabelare pentru testul t
Modelul ML4 ML3 MLD MLC MNPD MNEC W 0.6222 NP 6.8322 7.05099 C 0.6368 0.4135 9.2098 6.0801 D 4.3021 5.0919 13.0381 18.2698 Termen liber 4.3886 23.2344 23.9016 18.4638 59.3887 71.701 T tabelar 2.048 2.045 1.96 1.96 1.96 1.96

Din tabelul 10.15 se observ c factorii W i C pentru modelul ML4 i factorul C pentru modelul ML3 valorile calculate sunt mai mici dect valorile tabelare. Pentru fiecare model se calculeaz diferenele n modul dintre costul efectiv al testrii i costul obinut cu modelul de evaluare. Se determin valoarea maxim, valoarea minim, amplitudinea i media abaterilor, iar aceste valori nregistrate sunt prezentate n tabelul 10.16. Tabelul 10.16 Indicatori cu privire la abaterile modelelor
Model Indicator Maxim Minim Amplitudinea Media Suma ML4 6.014 0.024 5.99 1.877364 61.953 ML3 6.473 0.053 6.42 1.893152 62.474 MLD 7.497 0.168 7.329 3.432667 113.278 MLC 23.251 0.134 23.117 8.316121 274.432 MNPD 9.527108 0.037479 9.489629 2.836401 93.60124 MNEC 11.13674 0.501409 10.63533 5.057849 166.909

Din analiza tabelului 10.16 se constat c cele mai mici abateri se nregistreaz pentru modelele ML4 i ML3, dup care urmeaz MNPD i MLD. Prin utilizarea de seturi de date provenind de la diverse aplicaii testate, estimrile parametrilor se rafineaz.

225

11
CONCLUZII
n lucrare este tratat testarea software din punct de vedere al costurilor acesteia. Testarea software, un proces foarte important din ciclul de dezvoltare software, are un rol determinant n obinerea de produse informatice de calitate, cu fiabilitate i mentenan ridicat. Procesul de testare necesit un volum mare de munc i resurse financiare. De aceea, identificarea costurilor implicate de testarea software i realizarea de modele de evaluare a costului testrii sunt utile n planificarea ct mai exact a proiectelor software. Scopul acestei lucrri este de a identifica cele mai importante aspecte legate de costul testrii software n procesul dezvoltrii aplicaiilor, pentru a realiza o serie de modele de evaluare a acestor costuri. Obiectivul principal al lucrrii este de a construi o serie de modele de evaluare a costului testrii software, de a estima coeficienii acestor modele, de a valida modelele obinute i de a realiza o analiz comparat a acestora. Cercetarea a presupus studierea n detaliu a domeniului testrii software n scopul identificrii tuturor aspectelor importante. S-a plecat de la testarea aplicaiilor informatice clasice i a aplicaiilor orientate obiect ctre aplicaiile distribuite, urmrindu-se particularitile testrii fiecrui tip de aplicaie. Pentru aceasta a fost studiat o bibliografie vast, de peste 30 de cri i 100 de articole tiinifice, au fost identificate i utilizate instrumente de msurare a caracteristicilor aplicaiilor i au fost identificate metode i tehnici de testare. n vederea nregistrrii efortului depus n activitatea de testare a fost realizat o aplicaie distribuit pentru servicii casnice. Pentru realizarea aplicaiei e-DSI au fost parcurse toate etapele ciclului de dezvoltare software. Lucrarea are la baz o serie de activiti ntreprinse n scopul fundamentrii coninutului acesteia: identificarea factorilor de influen a costurilor testrii software; au fost identificai factorii importani n determinarea costului
226

testrii aplicaiilor informatice; pentru fiecare factor n parte a fost prezentat o descriere i s-a punctat modul n care influeneaz efortul depus n testarea aplicaiilor informatice; realizarea de modele liniare de evaluare a costurilor testrii software; pe baza factorilor identificai au fost concepute modele de evaluare a costului testrii; identificarea de modele neliniare de evaluare a costului testrii software; n funcie de complexitatea software, dimensiunea aplicaiilor i productivitatea muncii se construiesc modele neliniare de evaluare a costului testrii pe baza a diverse forme analitice: de tip exponenial, logaritmic, polinomial, produs, hiperbolic, precum i de alte tipuri; analiza comparat a modelelor identificate; pe baza datelor nregistrate, modelele liniare i neliniare sunt comparate din punct de vedere a aproximrii costului real al testrii software; identificarea posibilitilor de rafinare a modelelor de evaluare a costului testrii software construite i a modurilor de selectare a celor mai bune rafinri obinute; realizarea unei tehnologii de ierarhizare a modelelor de evaluare a costului testrii software; este propus o tehnologie bazat pe o serie de criterii cum ar fi rangurile obinute, ponderile acordate i mrimea erorile obinute prin evaluare, utiliznd modelele respective; realizarea unei aplicaii i testarea acesteia n scopul estimrii coeficienilor modelelor propuse; pe msura realizrii aplicaiei au fost nregistrate date privind efortul implicat de activitatea de testare; pe baza metricilor culese pentru aplicaie au fost estimai coeficienii modelelor de evaluare a costului testrii; de asemenea, s-au rafinat i au fost ierarhizate modelele obinute. n capitolele lucrrii se regsesc att aspecte teoretice, ct i practice n legtur cu testarea software i cu modelele de evaluare a costului testrii. O parte din rezultatele cercetrii au fost publicate n reviste de specialitate i prezentate la conferine naionale i internaionale.

227

ANEXA 1 Lista acronimelor utilizate

Acronim ASD CASE CMM COM CORBA CSQA CSTE CUT DCOM e-DSI HIPO HTML ICE IDL JSP JVM KLOC LCP LCS LOC MCMMP MIDL MLECTS MUT OBI OFX OMT OOA OOD OOSE ORB OUT Semnificaie Adaptive System Development Computer Aided Software Engineering Capability Maturity Model Component Object Model Common Object Request Architecture Certified Software Quality Assurance Certified Software Test Engineer Class Under Test Distributed Component Object Model Electronic Domestic Services Integration Hierarchical - Input Processing - Output Hyper Text Markup Language Information and Content Exchange Interface Description Language Java Server Pages Java Virtual Machine Kilo Lines of Code Logique de la Construction des Programes Logique de la Construction des Systemes Lines of Code Metoda celor mai mici ptrate Microsoft Interface Description Language Modele liniare de evaluare a costului testrii software Module Under Test Open Buying on the Internet Open Financial Exchange Object Modeling Technique Rumbaugh Object-Oriented Analisys Shlaer & Mellor Object-Oriented Design Booch Object Oriented Software Engineering Ivar Jacobson Object Request Broker Object Under Test

228

PACT PF QAI RMI RUP SADT SEI SWAP UML XML XP

Parallel Architecture for Class Testing Point Function Quality Assurance Institute Remote Method Interface Rational Unified Process Structured Analysis and Design Technique Software Engineering Institute Simple Workflow Access Protocol Unified Modeling Language Extensible Markup Language Extreme Programming

229

ANEXA 2 Notaii utilizate

ai C Ca Cap Ce Cee Ci Cit Cp Cpt Cti CTi Ctm CTS Cts CTTE Ctv D EF Fi GN GO GR LP m Ni NI NM NP Coeficientul i de estimat Complexitatea aplicaiei Alte cheltuieli Cheltuieli pentru analiza i proiectarea testelor Cheltuieli pentru echipamente Cheltuieli pentru execuia i evaluarea testelor Cheltuieli pentru instrumente de asistare Cheltuieli pentru implementarea testelor Cheltuieli cu personalul Cheltuieli pentru planificarea testrii Cheltuieli pentru testarea de integrare Costul testrii la iteraia i Cheltuieli pentru testarea de modul Costul testrii software Cheltuieli pentru testarea de sistem Costul total al testrii efectiv Cheltuieli pentru testarea de validare Dimensiunea aplicaiei Eficiena echipei Factorii de influen Gradul de noutate software i hardware Gradul de omogenitate a echipei de realizare software Gradul de reutilizare Limbajul de programare utilizat Numrul de modele Numrul de iteraii ale procesului de testare Numrul de elemente de interfa Numrul de module Numrul de parametri
230

NU PS SA SC T TD TS W xi yi i

Numrul utilizatorilor Existena de produse similare pe pia Specificul aplicaiei software Stadiul de certificare a firmei Timpul Tehnicile de dezvoltare utilizate n realizarea produsului Tehnica i instrumentele de testare Productivitatea personalului Variabilele independente Variabila rezultativ Variabil obinut prin evaluare

231

ANEXA 3 Instrumente pentru automatizarea testrii

Productor: Mercury Interactive / www.mercuryinteractive.com Instrument Mercury Quality Center TestDirector Descriere Soluie complet, integrat, bazat pe Web, pentru asigurarea calitii. Pachet software pentru managementul procesului de testare; conine modulele: Requirements, Test Plan, Test Lab i Defects Manager Instrument pentru managementul erorilor aplicaiilor Web Testare funcional pentru aplicaiile Web Instrument pentru testarea funcional a aplicaiilor GUI Instrument pentru automatizarea testrii funcionale i regresive a aplicaiilor Web Instrument pentru automatizarea testrii funcionale a aplicaiilor pentru platforma X-Window Instrument pentru managementul testrii de solicitare i performan Instrument pentru testarea performanelor aplicaiilor Web Pre N/A

12000 USD

Astra FastTrack Astra QuickTest WinRunner QuickTest professional XRunner LoadRunner Astra LoadTest

595 USD 3995 USD 4995-10000 USD N/A 10000-15000 USD 40000 USD 9995 USD

232

Productor: Segue / www.segue.com Produs SilkCentral Performance Manager SilkTest SilkPerformer SilkCentral Issue Manager SilkCentral Test Manager Descriere Soluie pentru monitorizarea comportamentului aplicaiilor Pre 18000 EUR

Soluie pentru testarea scalabilitii i funcional a aplicaiilor de ntreprindere. Soluie pentru testarea de performan i solicitare. Soluie software pentru urmrirea defectelor Sistem pentru managementul testrii

6495 USD 30000 USD N/A 3600 EUR

Productor: IBM Rational / www.rational.com Produs IBM Rational ClearQuest Descriere Instrument pentru urmrirea i i nregistrarea defectelor schimbrilor aprute n dezvoltarea de aplicaii. Pachet pentru testarea automat IBM Rational funcional, regresiv, modular i Functional Tester for Java de ncrcare a aplicaiilor Web, ERP i client/server bazate pe and Web Java Platform care integreaz accesul IBM Rational Team Unifying membrilor echipei la resursele existente n procesul de dezvoltare Platform software. Conine IBM Rational RequisitePro , IBM Rational ProjectConsole, IBM Rational ClearCase LT, IBM Rational ClearQuest, IBM Rational TestManager, IBM Rational SoDA i IBM Rational Unified Process. Pre 1620/1720/4535 USD

4120 USD

4120 USD

233

IBM Rational PurifyPlus for Windows IBM Rational Robot

Instrument care automatizeaz testarea modulelor Instrument pentru automatizarea testrii funcionale; include teste regresive pentru aplicaii Web, ERP i client/server

1370 USD 4120 USD

Productor: Compuware Corporation / www.compuware.com Produs Abend-AID PointForward QACenter XPEDITER QARun QADirector Descriere Instrumente pentru rezolvarea situaiilor de eroare a aplicaiilor testate Soluie pentru testarea i monitorizarea de la distan Pachet pentru testarea aplicaiilor Pre N/A

N/A N/A N/A 4250 EURO

Instrument pentru analiza i testarea aplicaiilor dezvoltate pe platforme diferite Instrument pentru testarea Sistem pentru managementul procesului de testare

Productor: Software Research / www.soft.com Produs eValid TestWorks TCAT C/C++ TestWorks TCAT Java Descriere Instrument pentru testarea automat a site-urilor Web Instrument pentru testarea structural cod C/C++ Pre ntre 445 i 6595 USD 715 USD

Instrument pentru testarea structural cod Java

715 USD

234

Productor: Cactus / jakarta.apache.org

HTU UTH

Produs Cactus

JMeter

Descriere Cadru de testare pentru testarea de integrare, testarea funcional i testarea la nivel de cod surs pentru aplicaii Java pentru Web (servlet, pagini JSP). Bazat pe JUnit (www.junit.org) Produs pentru testarea de ncrcare a aplicaiilor Web
HTU UTH

Pre Gratuit

Gratuit

235

BIBLIOGRAFIE
[ADRI82] Adrion, W. R., Branstad, M. A., Cerniavsky, J. C Validation, Verification, and Testing of Computer Software, ACM Computing Surveys, June, 1982, pp 159-192, in Tutorial software quality assurance, a practical approach, pp. 334-367, edition IEEE Computer Press, 1985 [ANDRE95] Andrei, Tudorel; Stancu, Stelian: Statistica Teorie i aplicaii, Editura All, Bucureti, 1995 [APRE00] Apreutesei, Paula Modele de estimare a costurilor aplicaiilor de reea Tez de doctorat, Academia de Studii Economice, Bucureti, 2000 [ARHI00] Arhire, Romulus Evaluarea complexitii sistemelor de programe Tez de doctorat, Academia de Studii Economice, Bucureti, 2000 [BACI99] Bacivarov, I., Balme, L., Goncalves A. (Editors) Quality Management, Assurance and Education, Editura Inforec, Bucureti, 1999 [BACI01] Baciu, Achim T. Costurile organizare, planificare, contabilitate, calculaie, control i analiz, Editura Dacia, Cluj-Napoca, 2001 [BALO97] Balog, Alexandru, Olaru, Marieta, .a. Managementul calitii i protecia consumatorilor, vol.3, lito ASE, Bucureti, 1997 [BARO76] Baron, Tudor Calitatea i fiabilitatea produselor, Editura Didactic i Pedagogic, Bucureti, 1976 [BARO79] Baron, Tudor Metode statistice pentru analiza i controlul calitii produselor, Editura Didactic i Pedagogic, Bucureti, 1979 [BARO88] Baron, Tudor i alii: Calitate i fiabilitate Manual practic, Editura Tehnic, Bucureti, 1988 [BARO99] Baron T., ian E., Matache S., Ciuchi L., Manual practic de statistic, Editura Expert, Bucureti, 1999 [BERA90] Berard, Edward V Issues in the Testing of Object-Oriented Software, www.itmweb.com, 1990 [BEIZ90] Beizer, Boris Software Testing Techniques Second Edition, Van Nostrad Reinhold, New York, 1990 [BERT96] Bertolino, Antonia, Strigini Lorenzo On the use of testability measures for dependability assessment, IEEE Transactions on Software Engineering, vol. 22, No. 2, February 1996, pp 96-108. [BIGG99] Biggs, Maggie. Wenterprise application testing require more integrated solution to make better apps, InfoWorld, 1999 236

[BIND94] Binder, Robert V. Design for Testability in Object Oriented Sytems, Comunications of the ACM, Vol 37, No 9, Sepetember 1994 [BODE01] Bodea, Constana-Nicoleta, Sabu, Gheorghe, Posdarie, Elena Sisteme Informatice Economice. Analiz i proiectare orientate obiect utiliznd UML, Editura Inforec, Bucureti, 2001 [BOEH94] Boehm, B. Software Engineering Economics, Prentice Hall, 1994 [BOEH00] Boehm, Barry W. et al Software Cost Estimation with COCOMO II, Prentice Hall, 2000 [BOOC91] Booch, Grady, Object Oriented Design with Applications, The Benjamin/Cummings Publishing Company, Inc., 1991 [BOWK60] Bowker, Albert H, Lieberman, Gerald J Engineering Statistics, Prentince-Hall, New Jersey, 1960 [BOYD95] Boyd, Harper, Walker, Orville, Larreche, Jean-Claude Marketing Management: A Strategic Approach with a Global Orientation, Richard D. Irwin, Inc., U.S., 1995 [CARA96] Caracota, Dumitrache: Previziune Economic Elemente de macroeconomie, Editura Didactic i Pedagogic, Bucureti, 1996 [CARA02] Caraiani, Chiri, Olimid, Lavinia, (coord) Bazele contabilitii, Biblioteca Virtual ASE, Bucureti, 2002 [CEPE00] Catedra de Economie i Politici Economice Economie, Ediia a V-a, Biblioteca Virtual ASE, Bucureti, 2000 [CERT93] Certo, Samuel, Peter, J. Paul: Strategic Management A Focus on Process, Richard D. Irwin, Inc., U.S., 1993 [CHAN02] Chan, W. K., Chen T. Y., Tse, T. H. An Overview of Integration Testing Techniques of Object-Oriented Programs, Proceedings of the 2nd ACIS Annual International Conference on Computer and Information Science, (ICIS 2002), International Association for Computer and Information Science, Mt. Pleasant, Michigan, 2002 [CHAR89] Charette, Robert N. Software Engineering Risk Analysis and Management, Intertext Publications, McGraw-Hill Book Company, 1989 [CHEN96] Chen, Sanping, Mills Shirley, A binary Markov process model for random testing, IEEE Transactions on Software Engineering, vol. 22, No. 3, March 1996, pp 218-223. [CHEN96a] Chen, Tson Yueh, Yu, Yuen Tak On the expected number of failures detected by subdomain testing and random testing, IEEE Transactions on Software Engineering, vol. 22, No. 2, February 1996, pp 109-119. [CHOW78] Chow, Tsun S. Testing Software Design Modeled by FiniteState Machines, IEEE Transactions on Software Engineering, vol. SE-4, No. 3, May 1978, pp 178-187. 237

[CHOW85] Chow, Tsun S Technical issue: Testing and Validation in Tutorial software quality assurance, a practical approach, pp. 269-274, edition IEEE Computer Press, 1985 [COX86] Cox, J. Brad Object Oriented Programming: An Evolutionary Approach, Reading, MA: Addison-Wesley, 1986 [DALA94] Dalal, Siddartha R., McIntosh, Allen A. Concise paper: When to stop testing for large software systems with changing code, IEEE Transactions on Software Engineering, vol. 20, No. 4, April 1994, pp 318323. [DeMI78] DeMillo, R. E., Lipton, R. J., SayWard, F. G. Hints on test data selection: Help for the Practical Programmer, IEEE on Computer, April, 1978, pp 34-41, in Tutorial software quality assurance, a practical approach, pp. 285-292, edition IEEE Computer Press, 1985 [DIAS00] Dias, Paulo Lightweight methodologies, INESC, 2000 [DIAC99] Diaconescu, tefan Stelian Evaluarea costurilor proiectelor software, PC Report, Iulie 1999, pp. 20-25 [DIBA99] Dibachi, Rhonda Testing e-commerce, Software Testing & Quality Engineering, March-April 1999, pp. 57-62 [DOBR97] Dobrot, Ni Economie Politic, Editura Economic, Bucureti, 1997 [DUST99] Dustin, Elfriede, Rashka, Jeff, Paul, John Automated Software Testing, Addison Wesley, 1999 [DU73] Du, Lucian D., Manual de prezentare i utilizarea VERONICA sistem de programe pentru calcule statistico-matematice i de prognoz, Bucureti, 1973 [EFTI02] Eftimescu, Despina, Ilioiu, Alexandru Testarea automat Introducere n testarea automat a produselor software, Net Report, Aprilie 2002, pp. 22-26 [FAGA76] Fagan, M. E. Design and Code Inspections to Reduce Errors in Program Development, IBM System Journal, Vol. 15, No. 3, 1976, pp 219-248, in Tutorial Software Quality Assurance, a Practical Approach, pp. 297-325, edition IEEE Computer Press, 1985 [FAIR78] Fairley, R. E. Tutorial: Static Analysis and Dynamic Testing, IEEE on Computer, April, 1978, pp 14-23, in Tutorial software quality assurance, a practical approach, pp. 275-284, edition IEEE Computer Press, 1985 [FENT96] Fenton, Norman E., Pfleeger, Shari Lawrence Software Metrics, A Practical and Rigorous Approach, International Thomson Computer Press, 1996 238

[GEOR97] Georgescu, Vasile Econometrie, Editura Universitaria, Craiova, 1997 [GHIL02] Ghilic-Micu, Bogdan, Stoica Marian eActivitile n societatea informaional, Editura Economic, Bucureti, 2002 [GHOS00] Ghosh, Sudipto Testing Component-Based Distributed Applications, Thesis on Purdue University, 2000 [GILL93] Gillies, Alan C. Software Quality, Theory and Management, Chapman & Hall Computing, 1993 [GLASS79] Glass, Robert Software Reliability Book, Prentice Hall, 1979 [HALS77] Halstead, M. H. Elements of Software Science, Elsevier, North Holland, 1977. [HARR92] Harrold, Mary Jean, McGregor, John D Incremental Testing of Object Oriented Class Structures, 1992 [HAWK99] Hawkins, John L. Whats e-business?, E-Business Advisor Magazine, Januarry 1999 [HAYE96] Hayes, Linda G. Testing Distributed Applications: Unraveling the Web, Datamation Magazine, July 1996 [HEND96] Henderson-Sellers, B. Object-Oriented Metrics Measures of Complexity, Prentice Hall PTR, New Jersey, 1996 [HOLT79] Holthouse, M. A., Hatch, M. J. Experience with Automated Testing Analysis, IEEE on Computer, August, 1979, pp 33-36, in Tutorial software quality assurance, a practical approach, pp. 293-296, edition IEEE Computer Press, 1985 [HOWD82] Howden, W. E. Life-Cycle Software Validation, IEEE on Computer, February, 1982, pp 71-78, in Tutorial software quality assurance, a practical approach, pp. 326-333, edition IEEE Computer Press, 1985 [HUBE99] Huber, Jon T. Efficiency and Effectiveness Measures to Help Guide the Business of Software Testing, Hewlett Packard Company, 1999 [IEEE94] IEEE IEEE Standards Collection: Software Engineering, IEEE, 1994 [INFO79] INFOTECH Software Testing: State of the Art Report, vol 1: Analysis and Bibliography, Infotech International, Editor: Anne E Westley, 1979 [INFO79a] INFOTECH Software Testing: State of the Art Report, vol 2: Invited Papers, Infotech International, Editor: Anne E Westley, 1979 [ISO86] ISO 8402 International Standard - Quality, Vocabulary, Geneve, Switzerland, 1986 [IVAN97] Ivan, Ion, Sinioros, Panagiotis, Popescu, Mihai, Simion, Felix Metrici Software, Editura INFOREC, Bucureti, 1997 239

[IVAN97b] Ivan, Ion, Popescu, Mihai Metrici Software, n Byte Romania, 1997 [IVAN99] Ivan, Ion, Pocatilu, Paul Testarea Software Orientat Obiect, Editura Inforec, Bucureti, 1999 [IVAN99a] Ivan, Ion, Pocatilu, Paul Testarea Software Orientat Obiect, n Informatica Economic, vol. III, nr. 9, trim. I/1999, pp 93-98 [IVAN00] Ivan, Ion, Pocatilu, Paul, Capisizu, Sergiu Certificarea n Informatica Aplicat, n Informatic Economic vol. III, nr. 14, trim. II/2000, pag. 90-96 [IVAN00a] Ivan, Ion, Pocatilu, Paul, Sinioros, Panagiotis Testarea aplicaiilor e-business, Lucrrile Simpozionului SIMPEC 2000, Vol. 2, Braov, 2000 [IVAN00b] Ivan, Ion, Teodorescu, Laureniu, Pocatilu, Paul Creterea calitii software prin testare, n Q-media, vol 2, no.5, 2000, pag 20-24 [IVAN00c] Ivan, Ion, Tcaciuc, Sebastian, Pocatilu, Paul Certificarea datelor, n Q-media, vol 2, no.5, 2000, pag 28-31 [IVAN01] Ivan, Ion, Pocatilu, Paul, Ungureanu, Doru Projects Complexity Evaluation, n Economy Informatics vol. I, nr. 1, 2001, pp. 84-89 [IVAN01a] Ivan, Ion, Pocatilu, Paul, Cazan, Doru Certificarea bazelor de date utilizate n aplicaii Internet, n Informatic Economic vol. V, nr. 2(18), 2001, pp. 71-74 [IVAN01b] Ivan, Ion, Pocatilu, Paul, Toma, Cristian, Leau, Alexandru e3commerce: e-commerce, mobile application. Aplicaia e3com, n Informatica Economic vol. V, nr. 3 (19), 2001, pag. 16-23 [IVAN01c] Ivan, Ion, Pocatilu, Paul, Amitroaie, Mihai Metrici ale societii informaionale, n Informatic Economic vol. V, nr. 4 (20), 2001, pag. 33-40 [IVAN02] Ivan, Ion, Pocatilu, Paul, Popa, Marius, Sacal, Mihai Clonarea Informaional, n Revista Romn de Informatic i Automatic, vol. 12, nr. 2, 2002, pp. 47-52 [IVAN02a] Ivan, Ion, Pocatilu, Paul, Popa, Marius, Toma, Cristian Semntura electronic i securitatea datelor n comerul electronic, n Informatica Economic, vol. VI, nr. 3(23), 2002, pp. 99-104 [IVAN02b] Ivan, Ion, Pocatilu, Paul, Ivan, Anca Andreea Control Structure Oriented Software Testing, n Economy Informatics, vol. II, nr. 1, 2002, pp. 73-80 [JACO96] Jacobson, Ivar et al Object-Oriented Software Engineering A Use Case Driven Approach, Addison-Wesley, 1996 [JONE86] Jones, Capers Programming productivity, McGraw-Hill Book Co., New York, 1986 240

[KANE96] Kaner, Cem Quality Cost Analysis: Benefit and Risks, Software QA, Volume 3, No. 1, 1996, p. 23 [KAN95] Kan, Stephen H. Metrics and Models in Software Quality Engineering, Addison-Wesley Publishing Company, 1995 [KEHL99] Kehlenbeck, Axel Holistic testing of Web Apps is Needed, Software Testing & Quality Engineering, 1999 [KNUT02] Knuth, Donald E. Arta programrii calculatoarelor, vol. 1, 2, 3, Editura Teora, Bucureti, 2002 [KORE90] Korel, Bogdan Automated Software Test Data Generation, IEEE Transactions on Software Engineering, vol. 16, No. 8, August 1990, pp 870-879. [KORS98] Korson, Timothy D. Testing across life cycle, Ninth Annual Borland Conference, August 11, 1998 [LAFO99] Lafore, Robert, Waite, Mitchell Structuri de date i algoritmi n Java, Editura Teora, Bucureti, 1999 [LOND87] Londeix, Bernard Cost Estimation for Software Development, Addison Wesley Publishing Co., 1987 [MARI97] Marick, Brian Classic Testing Mistakes, http://www.stlabs.com/marick/classic.htm, 1997 [MCCA76] McCabe, T. J., A Complexity Measure, IEEE Transactions on Software Engineering, 2/1976, pag 308-320. [McGR97] McGregor, John D. An overview of testing, Journal of ObjectOriented Programming, January 1997. [McGR97a] McGregor, John D Planning for testing, Journal of ObjectOriented Programming, February 1997, pag. 8-12. [McGR97b] McGregor, John D Component testing, Journal of ObjectOriented Programming, March/April 1997, pp 6-9. [McGR97c] McGregor, John D Parallel architecture for component testing, Journal of Object-Oriented Programming, May 1997, pp 10-14. [McGR97d] McGregor, John D A component testing method, Journal of Object-Oriented Programming, June/July 1997. [McGR97e] McGregor, John D Making component testing more effective, Journal of Object-Oriented Programming, August 1997. [McGR97f] McGregor, John D Testing from specifications, Journal of Object-Oriented Programming, Vol. 10, No. 6, October 1997, pp. 6-16. [McGR98] McGregor, John D Building tests from specifications, Journal of Object-Oriented Programming, Vol. 10, No. 8, January 1998, pp. 60-63/68 [McGR98a] McGregor, John D Test cases from a specification: An example, Journal of Object-Oriented Programming, Vol. 10, No. 9, February 1998, pp. 66-70 241

[McGR98b] McGregor, John D Quality, Thy Name is Not Testing, Journal of Object-Oriented Programming, Vol. 11, No.1, March/April 1998, pp. 8-12 [McGR98c] McGregor, John D Testing Models: The Requirements Model, Journal of Object-Oriented Programming, Vol. 11, No. 3, June 1998, pp. 20-23/31 [McGR98d] McGregor, John D The Fifty-Foot Look at Analysis and Design Models, Journal of Object-Oriented Programming, Vol. 11, No. 4, July/August 1998, pp. 10-15 [McGR98e] McGregor, John D Lets Dont and Say We Did, Journal of Object-Oriented Programming, Vol. 11, No. 5, September 1998, pp. 6-11/14 [McGR98f] McGregor, John D Now Where Did I Put Those Bugs?, Journal of Object-Oriented Programming, Vol. 11, No. 6,October 1998, pp. 9-14 [McGR99] McGregor, John D If the Devil is in the Details, then What is in the Plan?, Journal of Object-Oriented Programming, Vol. 11, No. 8, January 1999, pp. 16-21/74 [McGR99a] McGregor, John D Instrumentation for Class Testing, Journal of Object-Oriented Programming, Vol. 12, No. 1, March/April 1999, pp. 18-21/27 [McGR99b] McGregor, John D Making Diagram is Useful, Not Archival, Journal of Object-Oriented Programming, Vol. 12, No. 2, May 1999, pp. 24-28 [McGR99c] McGregor, John D Test Patterns: Please Stand By, Journal of Object-Oriented Programming, Vol. 12, No. 3, June 1999, pp. 14-19 [McGR99d] McGregor, John D Validating Domain Models, Journal of Object-Oriented Programming, Vol. 12, No. 4, July/August 1999, pp. 12-17 [McGR99e] McGregor, John D Beyond Y2K Its Just the Beginning, Journal of Object-Oriented Programming, Vol. 12, No. 5, September 1999, pp. 13-16 [McGR99f] McGregor, John D Interactions, Journal of Object-Oriented Programming, Vol. 12, No. 6, October 1999, pp. 16-20 [McGR00] McGregor, John D Testing Is It a Phase, an Activity or a Lifestyle?, Journal of Object-Oriented Programming, Vol. 13, No. 1, March/April 2000, pp. 36-39 [McGR00a] McGregor, John D Making a List and Checking It Twice: Guided Inspection Checklists, Journal of Object-Oriented Programming, Vol. 13, No. 3, June 2000, pp. 40-43 [McGR00b] McGregor, John D Another Test Pattern Its About Time, Journal of Object-Oriented Programming, Vol. 13, No. 7, November 2000, pp. 31-33 242

[McGR00c] McGregor, John D Pattern Language for Testing Distributed Components, Software Architects, 2000 [McGR01] McGregor, John D Taking Testing to the Extreme, Journal of Object-Oriented Programming, Vol. 13, No. 10, February 2001, pp. 8-11 [MIHA98] Mihalca, Rodica, Fabian, Csaba, U, Adina, Simion, Felix Analiz i proiectare orientate obiect Instrumente de tip CASE, Editura Societatea Autonom de Informatic, Bucureti 1998 [MIHA02] Mihalca, Rodica Programe aplicative, Biblioteca Virtual ASE, Bucureti, 2002 [MYER79] Myers, Glenford J. The Art of Software Testing, John Wiley & Sons, New York, 1979 [OLAR75] Olariu, Cornel Conducerea ntreprinderii prin costuri, Editura Facla, Bucureti, 1975 [OLAR99] Olaru, Marieta Managementul Calitii, Editura Economic, Bucureti, 1999 [OPRE95] Oprea, Clin, Ristea, Mihai, Vduva, Ilie, Neamu, Horia Bazele contabilitii, Editura Didactic i Pedagogic, Bucureti, 1995 [PARK98] Parker, Graham W. Costurile calitii, Editura Codecs, Bucureti, 1998 [PATT01] Patton, Ron. Software testing, SAMS Publishing House, USA, 2001 [PECI93] Pecican, Eugen tefan Econometrie, Editura All, Bucureti, 1993 [PECI02] Pecican, Eugen, Tnsoiu, Ovidiu, Iacob Andreea Modele econometrice, Biblioteca Virtual ASE, 2002 [PETE00] Peters, James F., Pedrycz, Witold Software Engineering An Engineering Approach, John Wiley & Sons, Inc, 2000 [POCA01] Pocatilu, Paul, Cazan, Doru, Mihai, Teodor Test Data Generation Using Genetic Algorithms, Lucrrile Evolutionary Algorithms Workshop, Bucureti, 2001 [POCA01a] Pocatilu, Paul, Mihai , Teodor An Evolutionary Method for Test Data Generation, Proceedings of the Fifth International Symposium on Economic Informatics, Bucureti, 10-13 Mai 2001, pag 761-764 [POCA01b] Pocatilu, Paul The Role of Software Testing in Increasing the Software Reliability, Lucrrile Software Reliability Workshop, Bucureti, 2001 [POCA02] Pocatilu, Paul Costurile testrii software, n Informatica Economic vol. VI, nr. 1, 2002, pag. 90-93 [POCA02a] Pocatilu, Paul Testarea aplicaiilor de comer electronic, n volumul lucrrilor Simpozionului ISIS'2002, Iai, 24-26 Octombrie 2002 243

[POCA02b] Pocatilu, Paul Factori de influen a testrii software, n Informatica Economic, vol. VI, nr. 4(24), 2002 [POCA02c] Pocatilu, Paul Automated Software Testing Process, n Economy Informatics, vol. II, nr. 1, 2002, pp. 97-99 [POCA03] Pocatilu, Paul Modele liniare de evaluare a costului testrii software NCPTS, n Informatica Economica, vol. VII, nr. 1(25), 2003, pp. 51-54 [POCA03a] Pocatilu, Paul Utilizarea modelelor unifactoriale n evaluarea costului testrii software, n Informatica Economica, vol. VII, nr. 2(26), 2003, pp. 97-99 [POCA03b] Pocatilu, Paul, Doru Ungureanu Managementul procesului de testare software, n Revista Romna de Informatica si Automatica, vol. 13, nr. 2, 2003, pp. 15 -21 [POCA03c] Pocatilu, Paul, Ion Ivan, Marius Popa, Cristian Toma, Luckacs Breda Fiabilitatea m-aplicaiilor bazate pe tranzacii, n Revista Romna de Informatica si Automatica, vol. 13, nr. 2, 2003, pp. 43-50 [POCA03d] Pocatilu, Paul Automatizarea testrii software orientat obiect, n Revista Tinerilor Economiti, An I, nr. 1, Noiembrie 2003, pp. 121-125 [POCA03e] Pocatilu, Paul Evaluarea modelelor liniare de evaluare a costului testrii software, n Informatica Economica, vol. VII, nr. 3(27), 2003, pp. 84-87 [POCA03f] Pocatilu, Paul Testarea funcional a m-aplicaiei Dicionar, n Informatica Economica, vol. VII, nr. 4(28), 2003, pp. 55-58 [POCA03g] Pocatilu, Paul Tehnologie de ierarhizare a modelelor de evaluare a costului testrii software - ECTS n volumul Conferinei Internaionale Trends in the Development of the Information and Communication Technologies in Education and Management, Chiinu, 20-21 Martie 2003, pag 244-250 [POCA03h] Pocatilu, Paul, Marius Popa "Internet Applications Testing", Proceedings of 6th International Conference on Economic Informatics, IE2003, Digital Economy, Bucureti, 8-11 Mai 2003, pp 1028-1032 [POCA03i] Pocatilu, Paul Verificarea si validarea software n contextul realizrii de aplicaii informatice pentru dezvoltarea durabila a regiunilor la Simpozionul International Competitive Advantages and Regional Development organizat de ARSR, Bucuresti, 22-23 Mai 2003 [POCA03j] Pocatilu, Paul Mobile Applications Testing n volumul International Workshop IE&SI, ediia a II-a, Timioara, 23-24 Mai 2003, pag 41-44 [POCA03k] Pocatilu, Paul, Cristian Toma "Calitatea aplicaiilor mobile, n volumul Conferinei internaionale "Rolul tiinei i nvmntului 244

economic n realizarea reformelor economice din Republica Moldova, Chiinu, 25-26 septembrie 2003, pp. 474-477 [POCA03l] Pocatilu, Paul Costurile asociate testrii software, n volumul Simpozionului National Tinerii economiti i provocrile viitorului, Craiova 31 Octombrie 1 Noiembrie 2003, pp. 294-299 [POCA03m] Pocatilu, Paul Aplicaii mobile pentru gestiunea afacerilor, n volumul Simpozionului Internaional Specializare, Dezvoltare si Integrare, Universitatea Babe-Bolyai, Cluj-Napoca, 14-15 Noiembrie 2003, pp. 91-95 [POPE98] Popescu, Octavian (coordonator) Matematici aplicate n economie, Editura Didactic i Pedagogic, Bucureti, 1998 [PORO93] Porojan, Dumitru Statistica i teoria sondajului, Editura ansa, Bucureti, 1993 [PRAX02] http://praxiom.com ISO 9000 2000 Translated into Plain English, 2002 [PRES92] Pressman, Roger S. Software Engineering A Practitioners Approach, third edition, McGraw-Hill, 1992 [PRES00] Pressman, Roger S. Software Engineering A Practitioners Approach, European Adaptation Fifth Edition, McGraw-Hill, 2000 [ROBI00] Robinson, Harry Intelligent Test Automation, Software Testing & Quality Engineering, September/October, 2000, pp 24-32 [ROPE94] Roper, Mark Software Testing, McGraw, London, 1994 [ROC00] Roca, Ion, pu, Nicolae (coordonatori) Internet i Intranet. Concepte i aplicaii, Editura Economic, Bucureti 2000 [ROC04] Roca, Ion, Bucur C., Stanciu C., Paiu O., Viean, M. Comerul electronic. Concepte, tehnologii i aplicaii, Editura ASE, Bucureti 2000 [ROYC98] Royce, Walker Software Project Management A Unified Method, Addison-Wesley, 1998 [RTI02] RTI Planning Report 02-3: The Economic Impacts of Inadequate Infrastructure for Software Testing, May 2002 [RUMB96] Rumbaugh, James E. To Form a More Perfect Union: Unifying the OMT and Booch Methods, JOOP, Vol. 8, No. 8, January 1996, pp. 14-18, 65 [SAMA99] Samaroo, Angelina, Allot, Steve, Hambling, Brian E-ffective testing for E-commerce, 1999 [SHEA00] Shea Billie Avoiding Scalability Shock: Five Steps to Managing the Performance of E-business Applications, Software Testing & Quality Engineering, 2000 [SHLA92] Shlaer, Sally A Comparison of OOA and OMT, Project Technology, 1992
245

[SIEG96] Siegel, Shel, Object Oriented Software Testing: A Hierarchical Approach, Wiley Computer Publishing, 1996 [SIKU96] Sikula, Andrew Applied Management Ethics, Richard D. Irwin, Inc., U.S., 1996 [SING99] Singpurwalla, Nozer D., Wilson, Simon P. Statistical Methods in Software Engineering, Springer-Verlag, New York, 1999 [SINH99] Sinha, Gunjan Build a Component Architecture for E-Commerce, E-Business Advisor Magazine, March 1999 [SILV02] SilverMark Smalltalk Testing Tips, SilverMark Inc., presentations@silvermark.com, 2002 [SMEU02] Smeureanu, Ion, Drdal Marian Programarea orientat obiect n limbajul C++, Editura CISON, Bucureti, 2002 [SMEU04] Smeureanu, Ion, Drdal Marian, Reveiu Adriana Visual C# .NET, Editura CISON, Bucureti, 2004 [SOMM01] Sommerville, Ian Software Engineering, 6th Edition, Addison Wesley, 2001 [SPIR95] Spircu, Claudia, Loptan, Ionu POO Analiza, proiectarea i programarea orientate spre obiecte, Editura Teora, 1995 [STOI89] Stoica Marcel, Andreica, Marin, Sndulescu, Iosif Introducere n modelarea procedural, Editura Scrisul Romnesc, Craiova, 1989 [STI01] Software Testing Institute, www.softwaretestinginstitute.com/salaries.html, 2001 [SWAN97] Swanson, Lena What Makes Client/Server Testing Unique?, www.data-dimension.com/testers/docs/Unique_CS1.htm, February 1997 [TAI78] Kuo-Chung Tai Program Testing and Complexity and Test Criteria, IEEE Transactions on Software Engineering, vol. SE-6, No. 6, November 1978, pp 531-538. [TANA03] Tanas, tefan, Olaru, Cristian, Andrei, tefan Java de la 0 la expert, Editura Polirom, Iai, 2003 [TEOD99] Teodorescu, Laureniu, Ivan, Ion Managementul calitii software, Editura Inforec, Bucureti, 1999 [TEST90] ***** Chapter 6: Testing, London,1990, pag 105-122 [VIEN91] Vienneau, Robert L. The Cost of Testing Software, Proceedings of Annual Reliability and Maintainability Symposium, 1991, pp. 423-427 [VLIE00] Vliet, Hans van, Software Engineering Principles and Practice, John Wiley & Sons, 2000 [VOAS98] Voas, Jeffrey Certification: The Software Quality Certification Triangle, Crosstalk, vol. 11, No. 11, Nov. 1998, pp. 12-14 [VOIN02] Voinegu, Vergil, Colibab, Dana, Grdinaru, Giani Statistic noiuni fundamentale i aplicaii, Editura ASE, Bucureti, 2002

246

[WANG97] Wang, Changqing, Musser, David R Dynamic verification of C++ generic algorithms, IEEE Transactions on Software Engineering, vol. 23, No. 5, May 1997, pp 314-323. [WIEL99] WIELE, Ton van der, DALE, Barrie, WILLIAMS, Roger Two Current Trends In Structuring Quality Management, Bucureti 1999 [WINO00] Winokur, Michael, Grinman, Arie, Iosha, Israel Process improvement experiment TESTART, Final Report, 2000

247