TEMA

INGINERIE SOFTWARE

Tehnici de testare software

Studenti:
Damian Alexandra
Nae Daniel Madalin
Paun Florin
Grupa 441A

Cuprins
Testarea etap a ciclului de dezvoltare software.......................................2
Fazele procesului de testare software..........................................................8
Testarea funcional...................................................................................11
Testarea software orientat obiect...............................................................15
Testarea sistemelor distribuite bazate pe tehnologia Internet..................19
Modele de organizare a aplicaiilor distribuite...........................................20
Avantajele sistemelor distribuite................................................................23
Testarea sistemelor distribuite bazate pe componente.............................27
BIBLIOGRAFIE.............................................................................................32

Stundeti:
Nae Daniel Madalin:
Testarea etap a ciclului de dezvoltare software
Fazele procesului de testare software
Testarea sistemelor distribuite bazate pe componente
Damian Alexandra:
Testarea funcional
Testarea software orientat obiect
Paun Florin:
Testarea sistemelor distribuite bazate pe tehnologia Internet
Modele de organizare a aplicaiilor distribuite
Avantajele sistemelor distribuite

Introducere:
Testarea reprezint o etap important n procesul de realizare a produselor
software. 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.
Aceasta lucrare 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 lucrare sunt
fcute referiri la utilizarea tehnicilor de testare pentru aplicaia e-DSI (electronic Domestic
Services Integration - aplicaia de servicii casnice electronice)

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 .

Figura 1 Modelul clasic de dezvoltare software

n etapa de specificare a cerinelor se determin necesitile pentru toate
elementele sistemului, att hardware ct i software. Cerinele privind aplicaia eDSI 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 cara cterizarea 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
[PRES 00] se arat c peste 35% din erorile software i au originea n fazele de
analiz i proiectare.
Prin implementare se face trecerea de la proiect la o form specific 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 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
4

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

Figura 2 Testarea software n ciclul de dezvoltare

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 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.
In metoda testrii descendente (top-down testing), n me 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 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 structur ii obinute
anterior. n acest context este executat testarea de regresie, prin care se retesteaz noua structur obinut, utiliznd o parte din testele utilizate n etapa
precedent de integrare.
Testarea de validare are loc dup ce toate erorile de i nterfa descoperite n
cadrul testrii de integrare au fost corectate. Testarea de validare se ncheie cu
succes atunci cnd funcionalitatea aplicaiei software este n conformitate cu
cerinele beneficiaru lui. 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 termina t,
toate erorile aprute sunt corectate, urmnd s se realizeze versiunea final a
aplicaiei software.

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, 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 performantelor se realizeaza pentru determinarea confirmitatii
sistemului cu cerintele de performanta impuse. De exemplu sistemul este incarcat
intr-un interval de timp pornind de la capacitatea minima pana la capacitatea maxima
si se verifica daca resursele sistemului se afla in limitele corespunzatoare si nu sunt
intarzieri in executarea functiilor aplicatiei.
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.

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
8

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 . 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.
Sunt prezentate etapele fazelor de analiz i proiectare a testelor.
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;
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.
10

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 instrument automat, care
pe baza specificaiilor determin dac rezultatele execuiei testelor sunt corecte
sau nu.
n figura 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.

Fazele de executie 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 rul
structurii programului care sesteaz. Aprobarea de ctre beneficiar a rapoartelor
testrii de modul i ale testarii de integritate continue inchiierea 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.

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.

11

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 l s este limita superioar a domeniului unei date de intrare
de tip numeric, pentru aceasta se vor construi urmtoarele cazuri de test: l i-1, li, li+1, ls-1, ls
i ls+1.
Aplicaia e-DSI (electronic Domestic Services Integration) Servicii casnice electronice
integreaz ase aplicaii independente: magazin aparate foto, buget, bibliotec, reete,
agend i jurnal.
Testarea aplicaiei s-a realizat prin testarea independent a fiecrei aplicaii componente,
urmat de testarea ntregii aplicaii integrate. Pentru testare testarea funcional a
aplicaiei realizat att pentru fiecare aplicaie n parte, ct i pentru aplicaia integrat; sau 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 ;
Testarea securitii tranzaciilor n cazul transferului datelor privind cartea de credit prin
intermediul creia se realizeaz .
testarea structural a fiecrui modul astfel nct s se ating o acoperire
corespunztoare pentru execuia instruciunilor .

12

Testarea structural se realizeaz pentru fiecare fiier Java generat. Pentu testare se
utilizeaz instrumentele Jakarta Cactus, HttpUnit i Junit..Este analizata cu precadere
metoda
_jspService(javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse)

deoarece aceasta 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 urmatoarele probleme:
butoanele de navigare de la o nregistrare la alta n cadrul anumitor pagini erau de
dimensiuni mici;
anumite texte nu corespundeau cu cerinele specificate.
la formulare, butoanele aveau dimensiuni mici;
Testarea securitii tranzaciilor este necesar s se realizeze n special pentru partea
de transfer a datelor personale ale utilizatorilor (nume, adresa, inform plii pentru

13

produsele fotografice pe care doresc s le achiziioneze. Sunt testate performanele

aplicaiei, a unei reele LAN 10/100 Mbps.Aceste au fost realizate pentru un singur client.
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.
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.
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.

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.
Metoda white-box testing ocupa cu logica intern i structura codului. Este de asemenea,
numita de sticl, de testare structurale, caseta de deschis.
Testele care sunt scrise pe white box a strategiei de testare include acoperirea codului
scris, ramuri, poteci, declaraii i logica intern a codului, etc. n scopul de a pune n aplicare
testarii acestei metode, tester-ul trebuie s se confrunte cu codul, i, prin urmare, este
necesar s posede cunotine de codificare i de logic i anume, de lucru intern ale
codului. In cadrul ncercarii utilizarii metodei white box, de asemenea tester-ul trebuie s se
uite n codul i sa afla care unitate/ declaraia / bucat de cod este defecta.
Cu alte cuvinte, este imperativ necesar ca tester-ul sa aiba cunotine "structurale" despre
modul n care sistemul a fost implementat. Nu numai codul, dar chiar i fluxul de date i
fluxul de control trebuie s fie evaluate. Domeniile de cod, care sunt testate cu ajutorul
testelor
white
box
sunt:
Sectiunea
de
Cod
-Sectiunea
de
segment
-Filiale
-Sectiunea
de
stari
-Sectiunea
de
Bucle

14

-Cale
de
testare
-Fluxul
de
date
Exist trei aspecte ale codului, care sunt validate de tester n caseta de culoare alb, i
anume:
->n cazul n care software-ul a fost conceput ca in design-ul original al software-ului.
->n cazul n care msurile de securitate au fost puse n aplicare n software i este robust.
->Aflai
vulnerabiliti
n
software-ul
descris.
Avantajele
de
Testare
White
Box:
1.Deoarece cunoaterea structurii interne de codificare este condiie prealabil, devine foarte
uor a afla ce tip de date de intrare pot ajuta la testarea aplicatiei in mod eficient.
2.Cu toate acestea, un alt avantaj de testare white box este acela c ajut la optimizarea
codului.
3.El ajut la eliminarea liniilor suplimentare de cod, care pot introduce defecte n cod.
Dezavantaje
de
Testare
White
Box:
1. Pe msur ce cunoaterea de cod i structura intern este o condiie esenial, un tester
de calificare este necesar pentru a efectua acest tip de testare, i acest lucru, la rndul su,
crete
costul
software-ului.
2.Este aproape imposibil s se uite n fiecare bit de cod pentru a afla de erori ascunse, care
pot crea probleme, rezultnd n insuficiena cererii.
Tipuri
de
testare
care
au
la
baza
aceasta
metoda:
1.Unitatea
de
testare
Dezvoltatorul efectueaz unitatea de testare, n scopul de a verifica dac modulul special
sau unitatea de cod lucreaza bine. Unitatea vine de la testarea la nivel foarte de baz, dup
cum se desfoar i n cazul n care unitatea de cod este dezvoltata sub o funcie
speciala.
2.Analiza statice si dinamice
n timp ce analiza statica presupune parcurgerea codului n scopul de a afla orice defect este
posibil n cod, analiza dinamic implic execuia i analiza codului de la ieire.
3.
Acoperirea
declaratiilor
n acest tip de testare, codul este executat n aa fel nct fiecare declaraie a cererii este
executata cel puin o dat. Ajut la asigurarea c toate declaraiile sunt executate fr nici
un efect secundar. Diferite instrumente de management de acoperire sunt utilizate pentru a
evalua procentul de elemente executabile, care sunt n prezent testate. (Aceste instrumente
sunt
folosite
att
pentru
situaie,
precum
i
acoperirea
legaturilor).
4
Acoperire
Filiala
Nici o cerere de software nu poate fi scrisa ntr-un mod continuu de codificare. La un
moment dat avem nevoia de a ramifica n codul descris sau de a efectua o anumit
funcionalitate. Sucursala de acoperire a testarii ajut la validarea tuturor ramurilor n cod i
ajut asigurand c nici o ramificare nu duce la un comportament anormal a cererii.
5.Scurgeri
de
memorie
a
testarii
Atunci cnd un cod este scris, exist posibilitatea de a exist o problem de scurgere de
memorie n cod, ceea ce face codul sa fie defect. Prin urmare, n timpul fazei de testare
white box de cod este testat pentru a verifica, dac exist scurgeri de memorie n cod. n
caz de scurgere de memorie, mai mult memorie este necesara pentru software-ul i acest
lucru
afecteaz
viteza
de
software
aceasta
fiind
foarte
mica.
6.
Testarea
securitii
15

Testarea securitii se efectueaz n scopul de a afla cat de bine sistemul se poate proteja
mpotriva accesului neautorizat, hacking , care se ocup cu codul de aplicare. Acest tip de
testare
are
nevoie
de
tehnici
sofisticate
de
testare.
7.
Testarea
Mutatiei
Este un fel de testare, n care, cererea este testata de codul ce a fost modificat dup
stabilirea unui anumit bug / defect. De asemenea, ajut n a afla care cod i care strategia de
codificare poate ajuta n curs de dezvoltare funcionalitatea n mod eficient.
Pe langa toate tipurile de testare de mai sus, exist unele tipuri, care intr sub incidena att
cutiei neagr i a strategiilor de testare white-box, cum ar fi: testarea funcional (care se
ocupa cu codul, pentru a verifica performanele sale funcionale), testarea de integrare
elementara (care se ocup cu testarea de cod nou adugat n cerere), performan i
testare de ncrcare (care ajut n a afla modul n care gestioneaz resursele un anumit cod
i ofer performan), etc Din moment ce acestea se ncadreaz n caseta de culoare alb,
precum i cutie neagra este dificil s se clasifice n oricare dintre cele dou tipuri generale
de testare software.

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 :
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 obiect se utilizeaz clasele,
care sunt uniti de program mari datorit faptului c acestea includ metode i date

16

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

17

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.
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.
Este prezentat o metod de testare ierarhic a aplicaiilor software orientate
obiect. Aceast metod de testare se utilizeaz 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.
Testarea ierarhic este utilizat pentru software cu grad de complexitate ridicat.
Aplicaiile distribuite dezvoltate folosind tehnologii orientate obiect intr n aceast
categorie 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.

18

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.

De exemplu, se consider o metod care aparine unei clase, aceasta n contextul

clasei sale. Se creeaz o nou clas din aceasta , clas care va moteni i metoda ce a
fost testat n contextul superclasei, nu se poate garanta eficienta metodei n contextul
subclasei pn cnd aceasta nu creaza noul context . Tipurile de test bazate pe
funcionalitate vor trebui modificate i pentru cazurile de test bazate pe structur in
cadrul unei clase derivate si au fost distinse trei metode:
1.metode noi metode definite n subclase, incluzndu-le pe acelea cu acelai nume
ca metoda din superclas fiind testate prin derivarea testarii anteriore. Chiar dac
metoda corectitudinii testeaz n acest caz superclasa i metode din clasa derivat.
De asemenea metoda cu parametri cu n subclase necesit i o supradefinit sau
suprancrcat ntr-o subclas; se retesteaz dinainte de a fi nevoie s se testeze
doar prile ca ntr-o multitudine de domenii de arie temporar de rezervare a
biletelor de avion, rezervarea biletelor de tren etc.Se ia in considerare accesul unui
numr ct mai mare de cnd se prevede extinderea folosirii cardurilor ce necesit o
testare complet;
metode recursive metode definite ntr-o superclas i care nu sunt supradefinite
sau suprancrcate n retestare limitat dac metoda interacioneaz cu funcii
membre noi sau redefinite; este nevoie doar s fie retestat obiectul care
interacioneaz, nu toate obiectele;
19

 metode redefinite metode definite ntr-o superclas prin reutilizarea modelelor de

teste i obiecte dezvospecificaii i mai puin pe baza logicii interne . 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.

Testarea
sistemelor
distribuite
tehnologia
Internet

bazate

pe

Componentele unui sistem distribuit

Aplicaiile distribuite constau n mai multe componente ce 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. Un sistem distribuit are ca
principale componente: hardware distribuit; i/sau control distribuit (soft de sistem); i/sau
date
distribuite (soft de aplicaii).
Hardware distribuit
1. Un sistem distribuit trebuie s conin dou sau mai multe sisteme de calcul, fiecare cu
procesorul i memoria lui local. Acest aspect al distribuiei fizice este foarte important n
definirea unui sistem distribuit.
2. Pentru ca aceste calculatoare distribuite s poat comunica, este nevoie de o form de
reea de comunicare.
3. Distribuirea calculatoarelor poate reflecta distribuirea fizic a aplicaiei sau
descompunerea funcional a sistemului, unde sisteme de calcul diferite realizeaz funcii
diferite (de exemplu procesoarele dedicate).
Control distribuit

20

1. Sistemele conin resurse fizice sub forma procesoarelor, imprimante, etc. precum i
resurse logice sub forma proceselor, fiierelor etc.
2. Strategia folosit pentru controlul resurselor poate fi centralizat ierarhic sau s permit
o
autonomie complet a procesoarelor individuale peste resursele locale. Aceast ultim
abordare necesit o cuplare slab ntre componentele sistemului (de exemplu reelele de
calculatoare).
3. n multe cazuri se ncearc obinerea unei transparene, n sensul c sistemul apare ca un
sistem unic, uniform, ascunznd distribuia fizic i neomogenitatea componentelor sale.
Datele distribuite
1. Una din resursele majore ce necesit control i din partea sistemului i din partea
aplicaiei
sunt datele.
2. Datele n curs de procesare pot fi distribuite prin: replicare (copii multiple la locaii
diferite); partiionare (pri ale lor sunt stocate n diferite locaii).
3. Datele sunt adesea distribuite att pentru a crete tolerana la defecte, ct i pentru a
permite creterea perfor
4. manei prin stocarea datelor n apropierea zonelor unde sunt produse sau folosite.

Modele de organizare a aplicaiilor distribuite

Exist urmtoarele modele de organizare a aplicaiilor distribuite:
1. aplicaii tip client server, care presupun executarea unui volum important de prelucrri
locale sau autonome i partajarea resurselor de calcul sau date
2. aplicaii pe cluster, presupun utilizarea mai multor calculatoare conectate n reea, sub
forma unei resurse unice
3. aplicaii distribuite colaborative, care ofer posibilitatea participrii mai multor persoane
la atingerea unui obiectiv sau a mai multora, prin intermediul tehnologiei calculatoarelor
calcul plus comunicaii
4. metacalculul, care se refer la utilizarea unui numr foarte mare de resurse de calcul,

21

foarte puternice i distribuite pe o arie mare, pentru rezolvarea unor probleme de o mare
complexitate.
Modele arhitecturale specifice. Modelul cu acces neuniform la memorie NUMA (Non
Uniform
Memory Acces). NUMA cu memorii locale distribuite este o structur de sistem strns cuplat
folosit de obicei n cazul supercalculatoarelor. NUMA ierarhic cu clustere (ciorchine sau
grupare de staii de lucru legate printr-o reea care coopereaz la realizarea unui el comun).
Clusterul poate fi de tip NUMA sau UMA. Cazul conectrii tip Butterfly local este cel mai
rapid,
iar cel la distan cel mai lent.

Modelele calcului distribuit

1. modelul ferm de procesoare: se caracterizeaz prin existena unui ansamblu de
elemente de prelucrare generice i de servere cu funcii specifice, ale cror faciliti sunt
accesate de la staii de lucru, care n general au resurse de calcul i de memorare reduse.
2. modelul client-server: presupune executarea unui volum important de prelucrri locale
sau autonome i partajarea resurselor de calcul sau date.
3. modelul data flow: se bazeaz pe organizarea prelucrrii conform unui graf n care
nodurile
sunt elemente de prelucrare, iar arcele sunt conexiuni logice prin care circul mesajele.

22

4. modelul ierarhic: resursele de prelucrare sunt organizate (fizic sau logic) ntr-o reea de
prelucrare arborescent. n mod curent, nivelurilor mai nalte ale ierarhiei le sunt asociate
resurse de prelucrare mai puternice.
5. modelul cache: se bazeaz pe prelucrri realizate etap cu etap, efectuate de diverse
elemente de calcul, i pe combinarea rezultatelor pariale pe un alt element de calcul, de
regul mai puternic. O strategie de partajare a operaiunilor este adecvat n acest caz.

Modelul Client Server

1. n sistemele de operare pentru reele de calculatoare se utilizeaz de cele mai multe ori
modelul client-server.
2. n acest caz sistemul de operare conine, n afar de nucleu, un grup de procese numite
servere, care ofer servicii proceselor utilizator, acestea devenind astfel clieni.
3. Exist procese specializate care realizeaz diferite servicii, cum ar fi: lucrul cu fiiere,
compilare, tiprire etc. Un proces care are nevoie de o astfel de aciune, o cere de la unul din
serverele care sunt dedicate pentru respectivul tip de problem.
4. n timpul execuiei diferite procese pot fi att client, ct i server; de exemplu serverul de
fiiere poate deveni client pentru serverul care ofer timpul curent.
5. Dac att serverele, ct i clienii se execut n spaiul de memorie utilizator, structura
nucleului se simplific mult, rolul acestuia din punctul de vedere al comunicaiei
restrngndu-se la trimiterea i recepionarea de mesaje.
6. Dac realizarea comunicaiei se bazeaz pe operaii de tipul transmisie sau recepie,
nseamn c elementele principale utilizate n programare sunt de tip operaie de
intrareieire.
7. Activitile din timpul execuiei unei aplicaii distribuite sunt asociate de obicei,
abstractizrii
de proces si ele nu vor putea s existe dect ca pri ale aplicaiei.
8. Un sistem client-server este realizat pe trei nivele, cel al prezentrii, cel al aplicaiei i cel
alaccesului la date. Separarea fizic a celor trei nivele se numete partiionarea aplicaiei.

23

ntotdeauna nivelul prezentrii va fi implementat de ctre client. mprirea celorlalte dou

nivele ntre client i server conduce la 5 stiluri diferite: prezentare distribuit; prezentare la
distan; aplicaie distribuit, cnd calculele sunt mprite ntre client i server; date la
distan; date distribuite.

Fig1.Arhitectura client/server
Aplicaiile distribuite acioneaz ntr-un mediu foarte diferit de cel al aplicaiilor client/server.
In paradigma client/server, componentele aplicaiei software sunt folosite de ctre
calculatorul client si calculatorul server. In mediul aplicaiilor distribuite, aplicaia poate avea
componente care s ruleze pe mai multe calculatoare din reea. Diferena dintre client i
server dispare. n mod evident, o component a unei aplicaii distribuite acioneaz att drept
client, ct i ca server.

Avantajele sistemelor distribuite

1. Costuri reduse i s-a demonstrat economic c este mult mai ieftin s se foloseasc mai
multe sisteme de calcul la rezolvarea unei probleme complexe, dect unul foarte performant.
Acesta are un cost foarte mare i este dedicat, n general, numai un flux continuu de
probleme de calcul de foarte mari dimensiuni.
2. Modularitatea i simplitatea soft-ului sistemele distribuite pot fi construite ntr-o manier
foarte modularizat, unde fiecare component permite interfaarea cu restul sistemului
(celelalte componente) sau servicii foarte bine definite. Modularitatea permite o proiectare
simpl a sistemului, instalare i ntreinere mai simple.
3. Flexibilitatea i extensibilitatea modularitatea sistemului permite schimbarea sau
modificarea elementelor de calcul fr a deranja major operaiile n curs de desfurare. Prin
folosirea protocoalelor standard de comunicaii este posibil s se includ ntro reea
echipamente provenind de la diferii productori, rezultnd o reea omogen.
4. Fiabilitate i integritate sistemele distribuite au proprietatea de a putea continua
operaiunile indiferent de starea unei pri a sistemului folosirea mai multor noduri de calcul
24

permite ca, n cazul defectrii sau blocrii unei resurse, sistemul s continue activitatea
resurselor critice, n acest caz, pot avea control dublu sau triplu dac softul este proiectat n
stil tolerant la erori, sistemul poate continua absolut toate calculele n curs, prin redirectarea
taskurilor de calcul care nu mai rspund spre alte procesoare
5. Performana este n general definit n termenii timpului de rspuns la un anumit grad de
ncrcare timpul de rspuns poate fi sczut, n mod particular dac majoritatea procesrii
este fcuta local paralelismul datorat nodurilor multiple reduce defeciunile i ncetinirile ce
pot aprea la nivelul proceselor de calcul i genereaz o cretere a performanei globale
software-ul local poate fi folosit i la preprocesarea sau compactarea datelor, reducndu-se
astfel ncrcarea pe reeaua de comunicaie i crescnd performanele sistemului.

Reelele de calculatoare au o extindere rapid,intr-o multitudine de domenii

cum ar fi sistemul bancar, administraia public,alocarea temporara de resurse in
hoteluri,rezervarea de bilete de avion,rezervarea biletelor de tren,etc. Aplicaiile
moderne iau n considerare accesul unui numr ct mai mare de utilizatori,
mai ales cand se prevede extinderea folosirii cardurilor si crete numrul
acelora care utilizeaz Internetul.
Proiectarea aplicatiilor 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.In acest sistem nu exista notiunea de
obiecte,partea de client lucreaza direct cu tabelele de date si procedurile stocate din
baza de date.

25

n cadrul arhitecturii multistrat, un server de aplicaii se interpune intre aplicatia de client

si serverul de baza de date.Serverul de aplicatii implementeaza logica de aplicatie,iar
clientul implementeaza logica de prezentare a sistemului.Avantajul major al arhitecturii
multistrat fata de arhitectura client/server il reprezinta cresterea fiabilitatii.
Arhitectura Web confera acestora fiabilitate,scalabilitate si flexibilitate
ridicata.Aceasta difera fata de arhitectura multistrat prin doua aspecte:
-aplicatia client are o complexitate redusa,fiind un navigator Web;
-nivelul regulilor aplicatiei este bazat pe componete si nu este un singur sistem ce
implementeaza intreaga constructie.

Baza de
date
Server

Server
Navigator

De

Web

Aplicatii

Baza de
date
B

Componentele client sunt interfetele grafice utilizator si ruleaza in navigatoare Web

precum Netscape Navigator sau Internet Explorer.Componentele Server care ruleaza
intr-un server de aplicatii,furnizeaza logica procesului de afaceri.
Pentru testarea aplicatiilor distribuite bazate pe internet,trebuie luate in considerare
urmatoarele aspecte:
->capacitatea de utilizare; usurinta in utilizare si intelegerea elementelor interfetei
constituie elemente importante importante in acceptarea aplicatiei de catre clienti;
->functionalitatea;faptul ca aplicatia realizeaza ceea ce isi propune prin specificatii
conduce la cresterea increderii utilizatorilor in aceasta si in firma producatoare;
->compatibilitatea;avand in vedere faptul ca exista o multitudine de combinatii intre
sisteme de operare,navigatoare si aplicatiile care ruleaza in navigatoare,asigurarea
compatibilitatii aplicatiei este o problema importanta,deoarece exista riscul ca o parte
importanta dintre potentialii utilizatori sa nu poate utiliza aplicatia datorita
incompatibilitatii si astfel sunt pierduti o serie de clienti;
->performanta;timpul de raspuns si resursele ocupate reprezinta un aspect important
pentru utilizatorii aplicatiei.
In cazul aplicatiilor Internet care acceseaza baze de date exista o multitudine de
cause care duc la functionarea incorecta a acestora.De exemplu ,testul esuat al unei
tranzactii intr-o baza de date poate avea mai multe cauze:
26

a.logica bazei de date:procedurile stocate ,interogarile sau comenzile de

actualizare,inserare sau stergere contin erori;
b.logica serverului de aplicatii:exista erori de proiectare sau de programare in cadrul
functiilor implementate in serverul de aplicatii;
c.logica procesarii tranzactiilor:ordinea eronata a efectuarii unor operatii conduce la
esuarea intregii tranzactii;
d.comunicatia:in cazul unor probleme de comunicatie la diverse niveluri,tranzactiile
fie nu au loc,fie se realizeaza incomplet sau incorect.
Testarea aplicatiilor bazate pe arhitectura Web,in plus fata de testarea aplicatiilor
clasice,necesita o serie de teste specifice cum ar fi:
-testarea functionala
-testarea de compatibilitate
-testarea continutului
-testarea performantei
-testarea de incarcare
-testarea securitatii
-testarea serverului Web,al serverului de aplicatii si testarea bazelor de date.
Testarea functionala se realizeaza pentru a constata daca site-ul se comporta
conform cu specificatiile sale.Detaliile acestui tip de testare depend de natura siteului Web si,in general,consta in verificarea legaturilor paginilor,testarea
formularelor,verificarea tranzactiilor pentru comertul electronic si pentru baze de
date,testarea apleturilor java.
Prin testarea de compatibilitate se urmareste aspectul si comportamentul site-ului
Web in raport cu o varietate de sisteme de operare si de navigatoare
Internet.Aceasta testare scoate in evidenta problemele cu controalele
ActiveX,apleturile Java,functiile JavaScript sau VBScript si formulare din pagini.La
ora actuala exista peste 100 de combinatii posibile intre diverse sisteme de operare
Windows si diverse versiuni ale navigatoarelor NetScape si Internet Explorer.
Pentru testarea continutului se urmareste corectitudinea si asezarea in pagina a
textelor,imaginilor si a fisierelor de animatie si video din cadrul site-ului.
Prin testarea performantelor se masoara comportamentul site-ului Web in
diverse conditii de trafic.
Testarea de incarcare se utilizeaza pentru a a verifica daca site-ul Web poate
gestiona un anumit numar de utilizatori care il acceseaza concurrent ,in limite
acceptabile ca timp de raspuns.
Testarea securitatii tranzactiilor effectuate este foarte importanta pentru
aplicatiile de comert electronica avand in vedere faptul ca sunt vehiculate date
confidentiale,la care daca au acces personae neautorizate sau rauvoitoare se pot
produce pierderi materiale importante.
Testarea serverului Web are in vedere testarea interactiunilor dintre serverul
Web si serverul de aplicatii,verificarea integritatii bazei de date in cadrul serverului de
baze de date ,verificarea faptului ca scripturile ASP,PHP sau JSP se executa correct
pe server.
Testarea serverului de aplicatii se realizeaza tinandu-se seama de
caracteristicile functionale si structurale ale acestuia.Se testeaza componentele
serverului,folosind metode clasice de testare,precum si metode de testare care iau in
considerare tranzactiile si comunicatiile asincrone dintre aceste componente.

27

Testarea bazelor de date presupune verificarea executarii corecte a interogarilor

si operatiilor de adaugare si actualizare a datelor ,precum si verificarea conexiunilor
dintre site-ul Web si baza de date.
Testarea aplicatiilor distribuite bazate pe arhitectura Web este realizata fie de catre
echipe de specialitate din cadrul departamentului de asigurare a calitatii a firmei,fie
de catre o firma specializata in testare(out-sourcing).

Testarea
sistemelor
componente

distribuite

bazate

pe

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.

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

28

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 componenta n
parte. Fiecare test conine cazuri de test, ntru fiecare caz de test n parte fiind definite
driverul de test, i post-condiiile specifice fiecrei componente testate. componentele.
Acest nivel este orientat pe proces i are n vedere fazele de analiz, proiectare,
implementare i livrare. olerana la erori este evaluat prin injectarea de erori n scopul
determ Pentru de proiectare i implementare apar la definirea interfeei, implemtarea
datele de test, pre-condiiile
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.
Toleranta la erori este evaluat prin injectarea de erori n scopul determinarii
posibilitii serverului de a trata aceste situaii excepionale. aceasta, trebuie
determinate posibilele surse i tipuri de erori, utilizate pentru injectarea cu erori a
interfeei serverului . n cazul aplicaiilor bazate pe componente distribuite, erorile din
fazele de proiectare si implementare apar la definirea interfeei,implementarea
serverului i n codul client.
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([
*r); //
};
in] double a, [in] double b, [out] double

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.

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);
29

 probleme la nivelului ORB (de exemplu zona tampon a acestuia este plin);
probleme legate de securitate i autentificare;
probleme de sincronizare.
Este prezentat un model de testare distribuit (figura 2.15), precum i un limbaj ablon
pentru testarea sistemelor distribuite.

Fig3. Elementele modelului de testare a sistemelor distribuite

Limbajul ablon pentru testarea sistemelor distribuite prezint e caracteristici:

-izolarea obiectului de testat care ajut la testarea implementrilor pariale i
este
util la testele unde colaboratorii sunt partiali;
-ncapsularea obiectului de testat pentru ca ncapsulatorul s aiba aceeai interfa
ca i
clasa de testat (CUT) i metodele ncapsulatorului s poat modifica mesajele nainte de
retransmitere;
-utilizarea metodelor incapsulate 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;

30

- 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;
In momentul de fata se constata o scadere a duratei de proiectare si implementare
ale aplicatiilor distribuite, n special ale aplicaiilor de afaceri electronice, datorat n
principal necesitaii oportunitilor de afaceri de a patrunde cat mai rapid pe piata.
Scderea duratei ciclului de dezvoltare are consecinte negative asupra procesului de
realizare a aplicatiilor in cazul in care nu se acorda o atentie sporita procesului de
asigurare a calitatii.

BIBLIOGRAFIE:
ANDREW TANENBAUM-Computer Networks
http://www.freetutes.com/systemanalysis/sa9-testing-quality-assurance.html
Glenford Myers, Corey Sandler, Tom Badgett-Art of Sotware Testing
http://en.wikipedia.org/wiki/Software_testing
http://www.softwareqatest.com/

31