testare_software v4

8/18/2019 Testare_Software v4

1/31

TEMA

INGINERIE SOFTWARE

Tehnici de testare software

Studenti:

Damian Aleandra

Nae Daniel Madalin

!aun Florin

Gru"a ##$A

1


2/31

Cuprins Testarea – etapă a ciclului de dezvoltare software.......................................2

Fazele procesului de testare software..........................................................8

Testarea funcţională...................................................................................11

Testarea software orientat obiect...............................................................15

Testarea sistemelor distribuite bazate pe tehnoloia !nternet..................1"

#odele de oranizare a aplicaţiilor distribuite...........................................2$

%vanta&ele sistemelor distribuite................................................................2'

Testarea sistemelor distribuite bazate pe componente.............................2(

)!)*!+,-%F!.............................................................................................'2

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

!aun Florin: Testarea sistemelor distribuite bazate pe te"nolo#ia $nternet Modele de or#anizare a aplicaiilor distribuite Avanta%ele sistemelor distribuite

2


3/31

Introducere:

Testarea reprezintă o etapă importantă &n procesul de realizare a produselor software' !onderea c"eltuielilor cu testarea reprezintă &ntre ()* +i ,)* din totalulc"eltuielilor pentru dezvoltarea unei aplicaii software'

Te"nicile +i metodele moderne de elaborare a produselor software acordă oimportană deosebită efortului de &nlăturare a erorilor de analiză- proiectare +i pro#ramareprin folosirea unor mi%loace evoluate de testare'

Aceasta lucrare .Te"nici de testare software. prezintă procesul de testare- te"nicile +imetodele de testare specifice aplicaiilor software' Sunt avute &n vedere aplicaiile clasice-aplicaiile realizate utiliz/nd te"nolo#ii orientate obiect +i aplicaiile distribuite' 0n lucrare suntfăcute referiri la utilizarea te"nicilor de testare pentru aplicaia e1DS$ 2electronic DomesticServices $nte#ration 1 aplicaia de servicii casnice electronice3

Testarea – etapă a ciclului de dezvoltare software!roiectarea aplicaiilor software de dimensiuni mari- dezvoltată &n cadrul unei ec"ipe-

nu se face trec/nd direct la implementarea pro#ramului- ci urmează etape bine stabilite'!rocesul de dezvoltare al aplicaiilor software este alcătuit din următoarele etape:specificarea cerinelor- analiză- proiectare- implementare- testare +i &ntreinere' 0n fi#ura 4'5este prezentat #rafic modelul clasic de dezvoltare software '

'


4/31

Fi%ura $ – Modelul clasic de dezvoltare software

0n etapa de specificare a cerinelor se determină necesităile pentru toateelementele sistemului- at/t "ardware c/t +i software' 6erinele privind aplicaia e1DS$ au fost analizate &mpreună cu beneficiarul' !ornind de la cerina unei aplicaiiaccesibile &ntr1o manieră simplă- s1au stabilit variantele posibile de realizare +icerinele #lobale' S1a convenit cu privire la detaliile validării sistemului de cătrebeneficiar' Testarea specificaiilor se realizează prin metode de analiză statică:inspecii- parcur#eri +i analize te"nice'

7tapa de analiză continuă procesul de stabilire a cerinelor' Analistultrebuie să &nelea#ă domeniul informaiilor pentru software- funciile necesare-performanele +i interfeele' Se documentează cerinele- iar acestea sunt revăzute &mpreună cu beneficiarul' 0n această etapă este descris ceea ce trebuie să facăaplicaia informatică +i nu modul &n care se realizează' !entru aplicaia e1DS$ suntdefinite principalele caracteristici ale aplicaiilor componente: ma#azin electronic-#estiunea bibliotecii- bu#etul personal- a#enda telefonică- reete culinare +i %urnalulpersonal' Sunt descrise cazurile de test pentru fiecare componentă &n parte'

0n etapa de proiectare accentul se pune pe structurile de date- ar"itecturasistemului- detaliile procedurale +i cara cterizarea interfeelor' 0n această etapă suntidentificate structurile de date- interfeele- modulele +i sunt descri+i al#oritmii' !entrufiecare modul &n parte sunt definite specificaiile de realizare' !entru aplicaia e1DS$s1a stabilit structura fiecărei aplicaii componente- ar"itectura de bază- tabele dinbaza de date- modalităile de re#ăsire +i actualizare a datelor' 6azurile de test suntrafinate +i sunt adău#ate noi cazuri de test corespunzătoare detaliilor introduse' 0n8!97S )) se arată că peste (,* din erorile software &+i au ori#inea &n fazele deanaliză +i proiectare'

!rin implementare se face trecerea de la proiect la o formă specifică ma+iniide calcul' $mplementarea este cu at/t mai u+or de realizat cu c/t proiectarea serealizează mai &n detaliu' Testarea &n etapa de implementare are rolul de a evideniadiferenele dintre comportamentul produsului din specificaii +i cel dat la nivelulutilizatorilor' Aplicaia e1DS$ s1a implementat &n limba%ul de pro#ramare corespunzător cerinelor'

Testarea se concentrează at/t asupra lo#icii interne a pro#ramului- av/ndu1se &n vedere ca anumite elemente ale acestuia să fie parcurse- c/t +i pe funcionalitateaexternă a sa- pe baza specificaiilor' Se compară rezultatele efective obinute dupărularea pro#ramului cu seturi de date de test cu rezultatele scontate pe bazaspecificaiilor'

0n timp- după livrarea la beneficiar- aplicaiile software suferă sc"imbări carese datorează erorilor descoperite pe parcursul funcionării aplicaiei- modificărilor mediului &n care rulează aplicaia 2software- "ardware3 precum +i noilor cerine deperformană +i funcionalitate dorite de beneficiar' 0ntreinerea aplicaiilor softwarese aplică tuturor fazelor ciclului de viaă'

0n cadrul ciclului de dezvoltare software- un rol important &l au verificarea +ivalidarea 2; < ;3' ;erificarea +i validarea reprezintă un proces prin care sedetermină dacă cerinele unui sistem sau componentă sunt complete +i corecte-dacă rezultatul fiecărei faze de dezvoltare &ndepline+te cerinele sau condiiileimpuse &n faza anterioară +i dacă sistemul sau componenta finală este &nconcordană cu cerinele specificate 8!97S))'

Verificarea este mulimea activităilor care asi#ură că o aplicaie softwareimplementează corect o anumită funcie' Testarea software este o componentă a

/


5/31

procesului de ; < ;'Validarea este mulimea activităilor care asi#ură că o aplicaie software

realizată este &n concordană cu cerinele beneficiarului' !e măsura dezvoltăriiincrementale aplicaiei e1DS$ rezultatele din fazele intermediare sunt

validate de către beneficiar'

Testarea sau analiza statică are ca scop examinarea aplicaiilor softwarefără a fi executate +i cuprinde activităi precum inspeciile- execuia simbolică +iverificarea' Aceste activităi fac parte din cate#oria evaluările te"nice 8M=79>?'

Inspecţiile codului presupun citirea sau inspecia vizuală a codului sursă decătre un #rup de persoane' Av/nd la dispoziie codul sursă +i specificaiile deproiectare- #rupul de persoane din ec"ipa de inspecie urmăre+te explicaiilepro#ramatorului le#ate de lo#ica pro#ramului- instruciune cu instruciune' 0n acestmod se descoperă o serie de erori specifice acestei metode cum ar fi: declarareadatelor- referirea datelor- erorile de calcul- erorile de comparare- erorile de lo#ică-erorile de intrare@ie+ire- erorile de interfaă etc'

Parcurgerile constau &n citirea sau inspecia vizuală a codului sursă de către

un #rup de persoane- &nsă procedura de lucru este diferită av/nd ca scop execuialo#ică a fiecărei secvene de cod de testat pe baza unor seturi de test pre#ătiteanterior' !rin urmărirea pro#ramului pas cu pas sunt identificate erori care apar laacest nivel' 9ezultatele acestei activităi de verificare depind- ca +i &n cazulinspeciilor codului- de atitudinea ec"ipei faă de persoana care a scris pro#ramul-av/nd &n vedere faptul că atenia trebuie acordată pro#ramului care se verifică +i nucelui care l1a scris'

Verificarea de birou este o te"nică de analiză statică &n care listin#urilecodurilor sau rezultatele testelor sau alte documente sunt examinate vizual- deobicei de persoana care le1a realizat- pentru a identifica erorile sau abaterile de lastandardele de dezvoltare sau alte probleme'

Testarea dinamică presupune examinarea aplicaiilor software &n scopul#enerării datelor de test cu care acestea vor fi executate +i rularea aplicaiilor cuseturile de date de test obinute' Se observă că spre deosebire de testarea statică-testarea dinamică presupune execuia aplicaiei care se testează' 7xistă douăstrate#ii de dezvoltare a cazurilor de test: o strate#ie bazată pe structurapro#ramelor +i o alta- bazată pe funcionalitatea acestora'

0n dezvoltarea unui produs software testarea se realizează pe mai multeniveluri: testarea de module- testarea de inte#rare- testarea de sistem +i testareade acceptare 2validare3' 0n fi#ura 4'4 este prezentat procesul de verificare +ivalidare &n cadrul ciclului de dezvoltare a unui produs software 8T7ST?)' Se

identifică etapele de realizare a aplicaiei precum +i etapele +i nivelurile procesuluide testare software'

5


6/31

Fi%ura & – Testarea software &n ciclul de dezvoltare 0n cadrul testării de module se realizează verificarea celor mai mici unităi

software care pot fi compilate +i lin1editate independent' 0n pro#ramarea clasicăun modul este un subpro#ram 2funcie sau procedură3' 0n cadrul pro#ramelor orientate obiect- cea mai mică unitate testabilă este clasa'

Testarea de module se concentrează asupra verificării interfeelor modulelor-structurilor de date locale- condiiilor de la limite- căilor independente +i căilor detratare a erorilor' 8!97S))

Deoarece modulele nu sunt pro#rame de sine stătătoare- este necesar să seconstruiască pro#rame sau funcii care să a%ute la testarea de module'

B primă cate#orie o reprezintă pro#ramele conducătoare 2drivers3 careapelează modulele supuse testării cu datele de test construite +i preiau rezultatele

execuiei'B altă cate#orie este reprezentată de funciile sau procedurile apelate decătre modulul de testat' Acestea sunt substituite cu subpro#rame care au acela+iprototip- &nsă cu funcionalitate redusă la minim- denumite module vide 2stubs)'Modulele vide sunt funcii sau proceduri simple care nu fac nimic &n afarareturnării controlului- sau sunt funcii sau proceduri complexe- care simuleazăefectul apelării modulelor reale' 0n cele mai multe cazuri- modulele vide simple suntnepotrivite' Cn efort considerabil este necesar pentru implementarea de modulevide complexe'

Testarea de integrare este o te"nică sistematică de construire a structuriipro#ramului prin #ruparea componentelor &n paralel cu testarea aspectelor le#ate

de interfaa dintre componente' Testarea de inte#rare se realizează &ntr1o manierăneincrementală sau incrementală'

0


7/31

Testarea neincrementală 2big-bang testing 3 constă &n inte#rareacomponentelor prin #ruparea tuturor modulelor dintr1o dată- urmată de testarea &ntre#ului ansamblu' Acest tip de inte#rare nu este recomandată- deoarececorectarea erorilor va fi foarte #reu de realizat'

Testarea incrementală presupune construirea structurii pro#ramului pas cu pas +i

testarea ansamblului obinut' Cn element important &n execuia testului este secvena &n care modulele trebuie să fie testate' Astfel- testarea de inte#rare se realizeazăascendent 2bottom-up3- descendent 2top-down3 sau mixt'

Metoda de testare ascendentă 2bottom-up testing 3 presupune testareamai &nt/i a modulelor de pe cel mai de %os nivel al ierar"iei pro#ramului- apoi secontinuă &n sus cu testarea celorlalte module' Metoda de testare ascendentănecesită construcia de pro#rame conducătoare pentru a iniializa mediul +i pentru aapela modulele' !ro#ramele de pe nivelul de sus- care de obicei sunt critice- sunttestate ultimele' 0n timp sunt descoperite erori care pot influena multe module careau fost de%a testate' După corecia erorilor este necesar ca toate modulele de pe nivelurile de %os să fie testate re#resiv'

$n metoda testării descendente 2top-down testing 3- 0n me modulul din v/rfulierar"iei de pro#rame este testat primul- procesul de testare continu/nd cu modulelede pe nivelurile inferioare' Metoda de testare descendentă necesită construcia demodule vide asociate subpro#ramelor care nu sunt disponibile' Avanta%ul acesteimetode este că dacă estedescoperită o eroare &n modulele de pe nivelurile &nalte- impactul va fi asupramodulelor de pe nivelurile de %os care nu au fost &ncă implementate- deci refacereamodulelor de pe nivelurile inferioare poate fi evitată'

0n cadrul metodei mixte- testarea urmează mai &nt/i metoda descendentă'Modulele selectate de pe nivelurile inferioare sunt testate utiliz/nd metodaascendentă' Această flexibilitate permite preluarea avanta%elor metodelor deascendentă +i descendentă' 0n cele mai multe aplicaii- metoda mixtă este cea maipotrivită modalitate de abordare' Aplicaia e1DS$ a fost testată utiliz/nd aceastămetodă de inte#rare'

!e măsură ce sunt adău#ate noi module &n cadrul testării de inte#rare- apar sc"imbări &n software- care pot să modifice comportamentul structur ii obinuteanterior' 0n acest context este executată testarea de regresie- prin care se re1testează noua structură obinută- utiliz/nd o parte din testele utilizate &n etapaprecedentă de inte#rare'

Testarea de validare are loc după ce toate erorile de i nterfaă descoperite &ncadrul testării de inte#rare au fost corectate' Testarea de validare se &nc"eie cu

succes atunci c/nd funcionalitatea aplicaiei software este &n conformitate cucerinele beneficiaru lui' !entru testarea de validare se utilizează o serie de testefuncionale pentru a confirma faptul că aplicaia software se comportă conformcerinelor'

0n cadrul testării de validare se re#ăsesc testările alfa +i beta' Testarea alfaeste realizată la firma care produce aplicaia software- beneficiarul fiind acela careconduce testele' Testarea beta este realizată la beneficiari +i utilizatori finali' Ace+tiaprimesc o versiune a aplicaiei software- versiune apropiată de cea finală +i outilizează &n scopul descoperirii erorilor +i a problemelor de performană +ifuncionalitate' !roblemele apărute &n cadrul acestei testări sunt raportate firmei carea realizat aplicaia' După ce perioada acordată pentru testarea beta s1a termina t-

toate erorile apărute sunt corectate- urm/nd să se realizeze versiunea finală aaplicaiei software'

(


8/31

!entru testarea aplicaiei e1DS$ au fost &nre#istrate observaiile primite de la oserie de utilizatori care au folosit aplicaia &n diverse stadii ale acesteia &n scopulidentificării problemelor +i nea%unsurilor din utilizare' Ctilizatorii care au testataplicaia au niveluri de pre#ătire +i experienă &n lucrul cu calculatorul diferite'

După ce a avut loc testarea aplicaiei software- intervine testarea de sistem-

prin care se testează &ntre#ul sistem &n care produsul software este o partecomponentă a acestuia' Testarea de sistem presupune rularea unor teste diferite-astfel &nc/t să fie examinate toate caracteristicile sistemului'

0n literatura de specialitate- sunt prezentate c/teva te"nici specifice pentrutestarea de sistem' Astfel- se identifică testarea pentru determinarea capacităii derecuperare 2recovery testing 3- testarea securităii- testarea de solicitare 2stresstesting 3- testarea de &ncărcare 2load testing 3 +i testarea performanelor 2 performancetesting 3'

Testarea pentru determinarea capacităţii de recuperare este un test desistem care- printr1o multitudine de căi- forează aplicaia software să &+i &nc"eieexecuia &n mod necorespunzător' !rin acestea se testează capacitatea

aplicaiei de revenire dintr1o situaie necorespunzătoare'Testarea securităţii se realizează pentru a verifica eficiena

mecanismelor de protecie dintr1un sistem software +i dacă acesta se comportăcorespunzător la atacurile externe'

Testarea de solicitare se execută astfel &nc/t sistemul să funcioneze cu unvolum mai mare de resurse dec/t cel normal- cu scopul de a determina fiabilitateaaplicaiei +i momentul &n care funcionarea aplicaiei devine critică +i pentru alua măsurile corespunzătoare- astfel &nc/t să nu se a%un#ă &n exploatarea de zicu zi a sistemului informatic la astfel de situaii' Ctiliz/nd instrumente caresimulează existena mai multor utilizatori simultan- precum Meter +i 9ationalSite6"ec- pentru aplicaia e1DS$ s1au descoperit cazuri &n care serverul devineinaccesibil' Acest lucru impune verificarea confi#urării serverului de Eeb sau aprocesorului S!- prin modificarea numărului de clieni care accesează aplicaiasimultan'

Testarea de încărcare constă &n rularea sistemului software &n condiiile &ncare resursele 2memorie- microprocesor- reea3 sunt &ncărcate la maxim astfel &nc/tse a%un#e la situaii critice- &n care o parte din resurse nu mai sunt disponibile' Seurmăre+te capacitatea sistemului de a1+i &ntrerupe funcionarea fără pierderea saucoruperea datelor'

Testarea performantelor se realizeaza pentru determinarea confirmitatiisistemului cu cerintele de performanta impuse' De exemplu sistemul este incarcat

intr1un interval de timp pornind de la capacitatea minima pana la capacitatea maximasi se verifica daca resursele sistemului se afla in limitele corespunzatoare si nu suntintarzieri in executarea functiilor aplicatiei'

!rin folosirea de instrumente pentru măsurarea performanelor aplicaiei e1DS$2precum Meter3 s1a constat că aplicaia răspunde &n limite acceptabile- cu excepiaprimei cereri efectuate- datorită particularităilor serverului Eeb +i a motorului S!'

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 str/nsă le#ătură cu planificarea

8


9/31

derulării proiectului' 0n faza de planificare a proiectului pentru testare se alocăresurse- specific/ndu1se bu#etul +i perioada de timp &n care se va derulatestarea' !e baza acestora se realizează planificarea detaliată a procesului detestare'

!lanificarea testării are scopul de a determina ce să testeze +i c/t să

testeze- astfel &nc/t procesul de testare să se &ncadreze &n limitele resurselor alocate' 0n urma planificării testării rezultă planul de test- un document pe bazacăruia se desfă+oară celelalte faze ale testării' 0n această fază se identifică +iobiectivele testării'

!lanul de test este un document important- fiind utilizat ca bază pentrudesfă+urarea &ntre#ului proces de testare' 0n plus- trebuie identificate +i sursele derisc &n testare' !lanificarea testării poate să &nceapă din momentul &n care au fostelaborate cerinele aplicaiei software ' 0n planul de test sunt descrise:

F aria de cuprindereGF responsabilităile fiecărui membru al ec"ipei de testareGF resursele umane necesareGF desfă+urarea &n timp a testelorGF descrierea +i confi#urarea mediului specific aplicaieiGF lista ec"ipamentelor care trebuie ac"iziionateGF crearea +i mana#ementul datelor de testGF criteriile de acceptare a testelor'Deoarece este foarte dificil să se stabilească momentul &n care se va &nc"eia

testarea- &n planul de test se specifică o serie de criterii care constituie obază pentru determinarea finalizării testării'

nali!a 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ă următorii pa+i:F identificarea scopurilor- obiectivelor +i a strate#ilor testării de către

ec"ipa de testareGF metodele de verificare sunt asociate cerinelor sistemului sau

cazurilor de utilizare +i sunt documentate &n cadrul unei matrice deurmărire a cerinelorG

F analiza cerinelor testelorGF construirea matricei cerinelor testelor- &n care declaraiile

cerinelor testelor sunt asociate cerinelor sistemului sau a cazurilor deutilizareG

F

asocierea te"nicilor de testare cu declaraiile cerinelor testelor' 0n faza de analiză a procesului de testare- un aspect important &l ocupăanaliza cerinelor pentru testare' 6erinele testării trebuie să fie identificate +idocumentate astfel &nc/t toate persoanele implicate &n procesul de testare săfie con+tiente de scopul acestuia' Analiza se desfă+oară din mai multe punctede vedere- depinz/nd de faza de testare' Astfel se identifică o abordare structurală+i o abordare bazată pe comportament'

Faza de proiectare a testelor urmează după &nc"eierea analizei' 0n faza deproiectare- apar următorii pa+i:

F definirea modelului pro#ramului de test astfel &nc/t acesta săreflecte te"nicile de testare utilizateG

F

definirea ar"itecturii de testGF definirea procedurilor de testG

"


10/31

F luarea deciziei de automatizare a anumitor teste +i de testaremanuală a altor componenteG

F asocierea datelor de test astfel &nc/t fiecare cerină pentru datele detest să se reflecte pentru fiecare procedură de test'

!ro#ramul de test se elaborează fie la nivelul proiectării- fie la nivelul

te"nicilor de testare' 0n primul caz- procedurile de test sunt asociate componentelor "ardware +i software ale aplicaiei- iar &n al doilea caz procedurile de testare suntvăzute la nivelul te"nicilor de testare'

!roiectarea procedurilor de test &ncepe după determinarea cerinelor testării'!roiectarea procedurilor de test constă &n:

F analiza ar"itecturii de test pentru determinarea te"nicilor de testarerelevanteG

F definirea procedurilor de test at/t la nivelul sistemului c/t +i la nivelulde implementareG

F elaborarea sau preluarea de standarde de utilizare a procedurilor detestG

F identificarea procedurilor de test care vor fi efectuate manual +i a celor care vor fi efectuate automatG

F identificarea procedurilor de test complexe- pentru a fi proiectate &ncontinuare &n faza de proiectare detaliatăG

F proiectarea detaliată' 0n etapa de implementare a testelor sunt construite cazurile de test +i

procedurile de test- pe baza rezultatelor fazei de proiectare' 6azurile de testdescriu at/t parametrii de intrare c/t +i rezultatele a+teptate după execuie utiliz/ndacei parametri' 9ealizarea de cazuri de test c/t mai complete duce ladescoperirea unui număr mai mare de erori' !rocedurile de test identifică toi pa+ii

necesari pentru executarea cazurilor de test specifice'!rimul pas &n faza de implementare este iniializarea mediului deimplementare prin punerea la punct a ar"itecturii dezvoltării testelor'

Cn alt aspect important este identificarea standardelor pe care se bazeazăelaborarea secvenelor de test' Dacă au fost definite astfel de standarde deimplementare- atunci implementarea se realizează pe baza acestora' Dacă nuexistă standarde- &n cadrul acestei faze- la &nceput- se stabilesc convenii de scrierea pro#ramelor de test 2alinieri- comentarii- prefixe pentru date3'

$mplementarea secvenelor de test se realizează &n limba%e specificemediilor de testare 2asemănătoare ;isual Hasic3 sau se utilizează limba%e depro#ramare evoluate 26II- ava3'

!rin reutilizare se folosesc proceduri de test din proiectele anterioare sau dincadrul aceluia+i proiect pentru module care au pări comune' 0n 8McJ9?>c-8McJ9?>d este prezentată o ar"itectură paralelă de testare a claselor- &n careclasele de test sunt derivate &n paralel cu dezvoltarea ierar"iei claselor care setestează'

"a!a de rulare a testelor are ca intrări planul de test +i orarul execuieiprocedurilor de test- mediul de test fiind pre#ătit corespunzător' $e+irile fazei deexecuie a testelor sunt rezultatele testelor- leciile &nvăate +i orarul modificat altestelor' 7xecuia modulelor se realizează &n conformitate cu planul de test'!rocedurile de test descriu intrările +i ie+irile a+teptate după execuie'

0n această etapă din cadrul procesului de testare sunt rulatesecvenele de test' 7xecuia secvenelor de test se realizează pe c/t posibil &nmediul specific aplicaiei iar dacă nu este posibil- acest mediu este simulat'

1$


11/31

9ezultatele execuiei secvenelor de test sunt evaluate pentru a determina dacăprodusul a trecut testul cu succes' 7valuarea rezultatelor testelor se face decătre un oracol ' Bracolul este o persoană sau un instrument automat- carepe baza specificaiilor determină dacă rezultatele execuiei testelor sunt corectesau nu'

0n fi#ura este prezentat fluxul procesului de execuie +i evaluare a testelor pentru testarea la nivel de modul- bazată pe specificaii' 9ezultatele testelor arată dacă pro#ramul a trecut sau nu testul'

Fazele de executie +i evaluare pentru testarea de module

9ezultatele execuiei testelor se vor memora &ntr1o bază de date care conine+i alte informaii referitoare la aplicaia software realizată'

7xecuia +i evaluarea testării de inte#rare necesită noi secvene de test pe rulstructurii pro#ramului care sestează' Aprobarea de către beneficiar a rapoartelor testării de modul +i ale testarii de inte#ritate continue inc"iierea acestor faze'' 0n execuia +i evaluarea testării de sistem- beneficiarul aplicaiei seimplică mai mult dec/t &n celelalte faze' 0n mod asemănător- acesta trebuie săsemneze raportul de test pentru a considera &nc"eiată această fază de testare'

!rocesul de testare pentru aplicaia e1DS$ a urmat acelea+i etape- #radul deaprofundare fiind diferit'

Testarea funcţională

Testarea funcională 2blac#-box testing 3 este o strate#ie de testare care necesităcunoa+terea comportamentului extern al pro#ramului pe baza specificaiilor' Testareafuncională nu necesită cunoa+terea structurii interne a pro#ramului sau cuno+tinedespre modul &n care este implementat pro#ramul sau modulul'

11


12/31

!rincipalele te"nici de testare funcională sunt testarea cu intrări aleatoare-partiionarea pe clase de ec"ivalene- analiza valorilor limită- #raful cauză1efect +i#"icirea erorilor'

Testarea cu intrări aleatoare porne+te de la domeniul datelor de intrare +i constă &n #enerarea de date de test &n mod aleator- &n cadrul domeniului acestora' 7ste o

te"nică slabă de testare- cu cel mai mic procent de descoperire a erorilor' Aceastăte"nică de testare a fost dezvoltată- astfel &nc/t datele de test sunt alese aleatoriu dindomeniu +i sunt filtrate astfel &nc/t să &ndeplinească anumite condiii- ca de exempluproducerea unui rezultat dintr1o clasă de ie+iri posibile'

Partiţionarea pe clase de ec$ivalenţe constă &n &mpărirea domeniului datelor deintrare &n subdomenii- astfel &nc/t comportamentul pro#ramului să fie acela+i- cel puinteoretic- pentru orice dată de intrare din subdomeniul corespunzător' De exemplu- pentrufuncia care returnează valoare absolută a unui număr &ntre#- un subdomeniu ar fiintervalul numerelor strict ne#ative- iar un alt subdomeniu ar fi cel al numerelor pozitive'Dintr1un număr ridicat de cazuri de test posibile se a%un#e la două cazuri de test'

6aracteristicile partiionării pe clase de ec"ivalene sunt: domeniul datelor de intrare este &mpărit &n clase de ec"ivaleneG elementele din aceea+i clasă sunt tratate &n mod asemănătorG de asemenea se are &n vedere partiionarea ie+irilorG se consideră at/t clasele valide c/t +i cele invalideG pentru testare se ale#e cel puin un element din fiecare clasă de ec"ivalenă'

!rin utilizarea anali!ei valorilor limită pentru realizarea cazurilor de test- pentrufiecare parametru al funciei se determină un set de valori aflate la limita domeniul devaliditate' Analiza valorilor limită se concentrează asupra valorilor de la limita claselor deec"ivalene +i sunt avute &n vedere limitele at/t &n spaiul intrărilor c/t +i &n spaiulie+irilor'Dacă li este limita inferioară +i ls este limita superioară a domeniului unei date de intrare

de tip numeric- pentru aceasta se vor construi următoarele cazuri de test: l i15- l i- l iI5- ls15- ls+i lsI5'

Aplicaia e1DS$ 2electronic Domestic Services $nte#ration3 – Servicii casnice electroniceinte#rează +ase aplicaii independente: ma#azin aparate foto- bu#et- bibliotecă- reete-a#endă +i %urnal'

Testarea aplicaiei s1a realizat prin testarea independentă a fiecărei aplicaii componente-urmată de testarea &ntre#ii aplicaii inte#rate' !entru testare testarea funcională aaplicaiei realizată at/t pentru fiecare aplicaie &n parte- c/t +i pentru aplicaia inte#ratăG s1

au stabilit cazuri de test pentru fiecare aplicaie &n parteG testarea coninutului astfel &nc/t să fie respectate cerinele din specificaii: font c/t maimare- a+ezarea simetrică &n pa#ină- butoane de dimensiuni mai mari +i să fie vizibileG

testarea bazelor de date pentru fiecare aplicaie &n parte G

Testarea securităii tranzaciilor &n cazul transferului datelor privind cartea de credit prinintermediul căreia se realizează '

testarea structurală a fiecărui modul astfel &nc/t să se atin#ă o acoperire

corespunzătoare pentru execuia instruciunilor '

12


13/31


14/31

produsele foto#rafice pe care doresc să le ac"iziioneze' Sunt testate "erforman0eleaplicaiei- a unei reele KAN 5)@5)) Mbps'Aceste au fost realizate pentru un sin#ur client'!entru ac"iziii de bunuri se face exemplificare pentru aparate foto#rafice' 0n cazul &ncare se extinde aplicaia- sunt două soluii:

se creează un nod numit .Hunuri. +i din el se ramifică prin clonare referiri pentru toateclasele de bunuriG

sunt introduse prin clonare pe acela+i nivel celelalte clase de bunuri' 6umpărarea deproduse prin intermediul $nternetului &ncepe să ia amploare +i &n ara noastră' A fostrealizat un ma#azin virtual care comercializează aparate foto#rafice' Sunt prezentateaparate foto#rafice produse de diverse firme' !entru fiecare aparat de foto#rafiat suntprezentate modelul- preul +i foto#rafia acestuia' 7xistă posibilitatea de a afla detaliisuplimentare despre un anumit aparat de foto#rafiat prin selectarea acestuia' 0nmomentul selectării unui anumit produs- acesta poate fi adău#at &n co+ul de cumpărături'

După ce au fost făcute cumpărăturile- se poate realiza plata' Bric/nd este posibilărenunarea la produsele adău#ate &n co+ul de cumpărături'

Ma%oritatea erorile care apar la execuie sunt captate +i descrierea acestora estetransmisă clientului sub forma unui text care conine numele excepiei +i fi+ierele sursă &ncare a apărut'

+raful cau!ă-efect este o te"nică pentru ale#erea cazurilor de test &ntr1un mod sistematic +iar e la bază un limba% formal &n care sunt translatate specificaiile bazate pe limba%ulnatural' 6auza este o condiie distinctă de intrare sau o clasă de ec"ivalenă iar efectuleste o condiie de ie+ire sau o transformare a sistemului'

7ste prezentată o metodă de testare de g$icire a erorilor . metodă care nu presupuneutilizarea unei metodolo#ii anume- ci se bazează pe intuiia anumitor persoane +icapacitatea acestora de a descoperi erori'

Metoda w"ite1box testin# ocupa cu lo#ica internă +i structura codului' 7ste de asemenea-numita de sticlă- de testare structurale- caseta de desc"is'

Testele care sunt scrise pe w"ite box a strate#iei de testare include acoperirea coduluiscris- ramuri- poteci- declaraii +i lo#ica internă a codului- etc' 0n scopul de a pune &n aplicaretestarii acestei metode- tester1ul trebuie să se confrunte cu codul- +i- prin urmare- este

necesar să posede cuno+tine de codificare +i de lo#ică +i anume- de lucru intern alecodului' $n cadrul &ncercarii utilizarii metodei w"ite box- de asemenea tester1ul trebuie să seuite &n codul +i sa afla care unitate@ declaraia @ bucată de cod este defecta'6u alte cuvinte- este imperativ necesar ca tester1ul sa aiba cuno+tine LstructuraleL despremodul &n care sistemul a fost implementat' Nu numai codul- dar c"iar +i fluxul de date +ifluxul de control trebuie să fie evaluate' Domeniile de cod- care sunt testate cu a%utorultestelor w"ite box sunt:1 Sectiunea de 6od1Sectiunea de se#ment1Filiale

1Sectiunea de stari1Sectiunea de Hucle

1/


15/31

16ale de testare1Fluxul de date7xistă trei aspecte ale codului- care sunt validate de tester &n caseta de culoare albă- +ianume:10n cazul &n care software1ul a fost conceput ca in desi#n1ul ori#inal al software1ului'

10n cazul &n care măsurile de securitate au fost puse &n aplicare &n software +i este robust'1Aflai vulnerabilităi &n software1ul descris' Avanta%ele de Testare E"ite Hox:5'Deoarece cunoa+terea structurii interne de codificare este condiie prealabilă- devine foarteu+or a afla ce tip de date de intrare pot a%uta la testarea aplicatiei in mod eficient'4'6u toate acestea- un alt avanta% de testare w"ite box este acela că a%ută la optimizareacodului'('7l a%ută la eliminarea liniilor suplimentare de cod- care pot introduce defecte &n cod'Dezavanta%e de Testare E"ite Hox:5' !e măsură ce cunoa+terea 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 r/ndul său-cre+te costul software1ului'4'7ste aproape imposibil să se uite &n fiecare bit de cod pentru a afla de erori ascunse- carepot crea probleme- rezult/nd &n insuficiena cererii'

Tipuri de testare care au la baza aceasta metoda:5'Cnitatea de testareDezvoltatorul efectuează unitatea de testare- &n scopul de a verifica dacă modulul specialsau unitatea de cod lucreaza bine' Cnitatea vine de la testarea la nivel foarte de bază- dupăcum se desfă+oară +i &n cazul &n care unitatea de cod este dezvoltata sub o funcie

speciala'4'Analiza statice si dinamice

0n timp ce analiza statica presupune parcur#erea codului &n scopul de a afla orice defect esteposibil &n cod- analiza dinamică implică execuia +i analiza codului de la ie+ire'(' Acoperirea declaratiilor 0n acest tip de testare- codul este executat &n a+a fel &nc/t fiecare declaraie a cererii esteexecutata cel puin o dată' A%ută la asi#urarea că toate declaraiile sunt executate fără niciun efect secundar' Diferite instrumente de mana#ement de acoperire sunt utilizate pentru aevalua procentul de elemente executabile- care sunt &n prezent testate' 2Aceste instrumente

sunt folosite at/t pentru situaie- precum +i acoperirea le#aturilor3' Acoperire FilialaNici o cerere de software nu poate fi scrisa &ntr1un mod continuu de codificare' Ka unmoment dat avem nevoia de a ramifica &n codul descris sau de a efectua o anumităfuncionalitate' Sucursala de acoperire a testarii a%ută la validarea tuturor ramurilor &n cod +ia%ută asi#urand că nici o ramificare nu duce la un comportament anormal a cererii','Scur#eri de memorie a testarii Atunci c/nd un cod este scris- există posibilitatea de a există o problemă de scur#ere dememorie &n cod- ceea ce face codul sa fie defect' !rin urmare- &n timpul fazei de testarew"ite box de cod este testat pentru a verifica- dacă există scur#eri de memorie &n cod' 0ncaz de scur#ere de memorie- mai multă memorie este necesara pentru software1ul +i acestlucru afectează viteza de software aceasta fiind foarte mica'O' Testarea securităii

15


16/31

Testarea securităii se efectuează &n scopul de a afla cat de bine sistemul se poate prote%a &mpotriva accesului neautorizat- "acin# - care se ocupă cu codul de aplicare' Acest tip detestare are nevoie de te"nici sofisticate de testare'>' Testarea Mutatiei7ste un fel de testare- &n care- cererea este testata de codul ce a fost modificat după

stabilirea unui anumit bu# @ defect' De asemenea- a%ută &n a afla care cod +i care strate#ia decodificare poate a%uta &n curs de dezvoltare funcionalitatea &n mod eficient'!e lan#a toate tipurile de testare de mai sus- există unele tipuri- care intră sub incidena at/tcutiei nea#ră +i a strate#iilor de testare w"ite1box- cum ar fi: testarea funcională 2care seocupa cu codul- pentru a verifica performanele sale funcionale3- testarea de inte#rareelementara 2care se ocupă cu testarea de cod nou adău#at &n cerere3- performană +itestare de &ncărcare 2care a%ută &n a afla modul &n care #estionează resursele un anumit cod+i oferă performană3- etc Din moment ce acestea se &ncadrează &n caseta de culoare albă-precum +i cutie nea#ra este dificil să se clasifice &n oricare dintre cele două tipuri #eneralede testare software'

Testarea software orientat obiect

!ro#ramarea orientată obiect presupune definirea de clase +i obiecte- construireade ierar"ii- precum +i referirea obiectelor create' 0n cazul &n care clasele sunt binedefinite- reutilizarea #enerează efecte pozitive' 6/nd clasele sunt subdefinite estenecesară construirea de clase derivate de completare' 6/nd clasele sunt supradefiniteapar restricii de referire +i de reutilizare' Testarea completă a claselor este premisareutilizării'

Testarea claselor evideniază #radul de mo+tenire +i de acoperire probabilă a

tipolo#iilor de clase de probleme prin constructori@destructori definii'Sistemul orientat obiect este caracterizat printr1un nivel foarte ridicat al reutilizării

software' De aceea el a c/+ti#at teren &n faa metodolo#iilor clasice- tocmai datorităacestui aspect al reutilizării' Dacă nu ar fi reutilizarea- te"nolo#ia orientată obiect ar fi lafel ca celelalte- doar puin mai rapidă'

6onstruirea clasei &os&umparaturi &n cadrul aplicaiei e1DS$ este ec"ilibrată-nefiind necesară obinerea de clase derivate' Mai mult- definirea de metode de tipul #et-face ca referirea membrilor să se facă fără utilizarea de parametri: %etNumar!roduse*/GNumeroase aplicaii complexe se prezintă sub forma unor pro#rame apelatoare-corespunzător limba%ului 6II funcia principală main*/- care conin secvene lun#i dedirective 3include iar ca instruciuni executabile- &n #eneral structuri liniare de expresii de

definire de obiecte +i referire a funciilor membre ale obiectelor definite 8$;AN??'Testarea software orientat obiect presupune două planuri: testarea construciilor propriiG testarea construciilor incluse pentru reutilizare'

Metodele orientate obiect utilizează strate#ii diferite de &ncapsulare faă demetodele convenionale- acest lucru av/nd un dublu impact asupra testării software :

cea mai mică unitate testabilă nu mai este modululG strate#ia pentru testarea de inte#rare trebuie modificată'

0n mediile neorientate obiect- unitatea testabilă are o interfaă bine definită +i

realizează o sin#ură funcie specifică' 0ntr1un mediu orientat obiect se utilizează clasele-care sunt unităi de pro#ram mari datorită faptului că acestea includ metode +i date

10


17/31


18/31

Polimorfismul este exemplul cel mai practic al reutilizării- fiind prin definiiecapacitatea unei entităi de a lua mai multe forme' Ke#area dinamică %oacă un rol &ndeterminarea cerinelor testării- dar numai &n contextul testării de inte#rare' Ke#areadinamică creează posibilitatea unui set de mesa%e 2combinaii de obiecte emiătoare +ireceptoare de mesa%e3- ceea ce &nseamnă că va fi nevoie de mai multe teste 2&n locul

unuia sin#ur3 pentru a testa un mesa% specific' !olimorfismul +i le#area dinamică crescfoarte mult numărul căilor posibile de execuie' Analiza statică a codului sursă pentruidentificarea căilor nu mai este de mare a%utor &n acest nou context'Sunt prezentate nivelurile la care sunt testate pro#ramele orientate obiect: nivel al#oritmicG metodele claselor sunt tratate independentG aplicarea te"nicilor detestare clasice se realizează fără problemeG nivelul claseiG clasa este testată ca o entitate de sine stătătoareG sunt inte#ratemetodele care au fost testate la nivelul anteriorG nivel de #rup 2cluster 3G testarea se concentrează asupra inte#rării claselorG se au &nvedere apelurile de metode efectuate &ntre clase +i sincronizările dintre obiecteleconcurenteG nivel de sistemG sunt testate interaciunile dintre #rupurile de clase'

7ste prezentată o metodă de testare ierar"ică a aplicaiilor software orientateobiect' Această metodă de testare se utilizează +i se construie+te pe baza unor te"nicide testare cunoscute- le#ate &mpreună &ntr1un sistem de testare corespunzător' Metodadefine+te +i aplică standarde de testare pentru c/teva niveluri ale componentelor software: obiecte- clase- componente de bază +i sisteme'

Metoda de testare ierar"ică constă &n desemnarea ca fiind corespunzătoare acelecomponente care &ndeplinesc standardele de testare pentru tipul respectiv decomponentă' Bdată ce o componentă a fost calificată drept corespunzătoare printestare- aceasta va fi inte#rată cu alte componente care au fost desemnate ca fiindcorespunzătoare- pentru a realiza &mpreună componentele de pe nivelul următor'

Starea de a fi corespunzător pentru o componentă este relativă +i depinde foartemult de standardele utilizate pentru realizarea aplicaiei- de atitudinea faă de risc- deriscurile specifice +i de practicile de mana#ement al riscului adoptate &n cadrulproiectului'

Metoda ierar"ică elimină obli#ativitatea testării tuturor combinaiilor de stări &ntimpul testării de inte#rare- ceea ce duce la cre+terea productivităii prin accesarea doar a interconexiunilor dintre componentele de bază +i orice funcionalitate complexă nouă'Metoda de testare ierar"ică este reprezentată #rafic &n fi#ura 4'5)'

Testarea ierar"ică este utilizată pentru software cu #rad de complexitate ridicat' Aplicaiile distribuite dezvoltate folosind te"nolo#ii orientate obiect intră &n această

cate#orie 0n cadrul testării ierar"ice- sunt utilizate următoarele suite de teste: suita de teste condiionale care constă din testarea claselor utiliz/nd modelul detestare condiională +i aseriunile- excepiile- operaiile de testare concurenteadiionaleG

suita de teste ierar"ice incrementale utilizată pentru testarea componentelor debază prin diverse modele de testare +i scenariiG

suita de teste de inte#rare pentru testarea combinaiilor de componente de bazăutiliz/nd modelul ierar"ic incremental cu scenarii care utilizează toatecomponentele- nu doar module videG

suita de teste de sistem care are ca scop testarea sistemelor componentelor debază utiliz/nd modele de testare de sistemeG

suita de teste de re#resie pentru a testa componentele de bază +i sistemul'

18


19/31

Ka baza metodei ierar"ice +i incrementale de testare stă ansamblul de relaiidintre clase' 0n mediul orientat obiect- &ntr1o ierar"ie de clase- c/nd se testează o clasăse testează &n acela+i timp +i clasele părinte +i- construind teste- acestea pot fi reutilizateulterior +i pentru testarea subclaselor' Fiecare subclasă este rezultatul combinăriistructurii +i comportamentului claselor părini cu atribute +i metode noi'

0n fi#ura 4'55 se observă cum- prin mo+tenire- clasa derivată &os&umparaturi se obineprin combinarea clasei de bază .b/ect cu un modificator- care cuprinde metodele +iproprietăile specifice clasei derivate'

De exemplu- se consideră o metodă care aparine unei clase- aceasta &n contextulclasei sale' Se creează o nouă clasă din aceasta - clasă care va mo+teni +i metoda ce afost testată &n contextul superclasei- nu se poate #aranta eficienta metodei &n contextulsubclasei p/nă c/nd aceasta nu creaza noul context ' Tipurile de test bazate pefuncionalitate vor trebui modificate +i pentru cazurile de test bazate pe structură incadrul unei clase derivate si au fost distinse trei metode:

5'metode noi – metode definite &n subclase- incluz/ndu1le pe acelea cu acela+i numeca metoda din superclasă fiind testate prin derivarea testarii anteriore' 6"iar 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ă sausupra&ncărcată &ntr1o subclasăG se retestează dinainte de a fi nevoie să se testezedoar pările ca &ntr1o multitudine de domenii de arie temporară de rezervare abiletelor de avionrezervarea biletelor de tren etc'Se ia in considerare accesul unuinumăr c/t mai mare de c/nd se prevede extinderea folosirii cardurilor ce necesită otestare completăG metode recursive – metode definite &ntr1o superclasă +i care nu sunt supradefinitesau supra&ncărcate &n retestare limitată dacă metoda interacionează cu funciimembre noi sau redefiniteG este nevoie doar să fie retestat obiectul careinteracionează- nu toate obiecteleG

1"


20/31

metode redefinite – metode definite &ntr1o superclasă prin reutilizarea modelelor deteste +i obiecte dezvospecificaii +i mai puin pe baza lo#icii interne ' Acest lucru cre+tesemnificativ productivitatea testării-precum +i productivitatea pro#ramării +i proiectării'Mo+tenirea multiplă conduce la clasificări mai dificile- dar nu afectează cate#oriile &nsine' Anumite modele de mo+tenire multiplă- din limba%ul 6II- determină existena

aceleia+i superclase &n două sau mai multe instane- &n obiect- cre/nd astfel mai multdec/t o metodă recursivă'

Testarea sistemelor distribuite bazate pe

tehnologia Internet

Componentele unui sistem distribuit Aplicaiile distribuite constau &n mai multe componente ce rulează pe ma+ini diferite- acestea

aplicaii inte#r/nd aciunile componentelor lor' !roiectarea aplicaiilor distribuite se axează nu

numai pe detaliile părilor individuale- ci +i pe realizarea unei inte#rări a componentelor

distribuite- astfel &nc/t acestea să coopereze foarte bine &ntre ele' Cn sistem distribuit are ca

principale componente: $ardware distribuit0 i1sau control distribuit 2soft de sistem)0 i1saudate

distribuite 2soft de aplicaţii)

Hardware distribuit

5' Cn 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'

4' !entru ca aceste calculatoare distribuite să poată comunica- este nevoie de o formă de

reea de comunicare'

(' Distribuirea calculatoarelor poate reflecta distribuirea fizică a aplicaiei sau

descompunerea funcională a sistemului- unde sisteme de calcul diferite realizează funcii

diferite 2de exemplu procesoarele dedicate3'

Control distribuit

2$


21/31

5' Sistemele conin resurse fizice sub forma procesoarelor- imprimante- etc' precum +i

resurse lo#ice sub forma proceselor- fi+ierelor etc'

4' Strate#ia folosită pentru controlul resurselor poate fi centrali2at1 ierarhic sau să permităo

autonomie com"let1 a procesoarelor individuale peste resursele locale' Această ultimă

abordare necesită o cuplare slabă &ntre componentele sistemului 2de exemplu reelele de

calculatoare3'

(' 0n multe cazuri se &ncearcă obinerea unei transparene- &n sensul că sistemul apare ca un

sistem unic- uniform- ascunz/nd distribuia fizică +i neomo#enitatea componentelor sale'

Datele distribuite

5' Cna din resursele ma%ore ce necesită control +i din partea sistemului +i din parteaaplicaiei

sunt datele'

4' Datele &n curs de procesare pot fi distribuite prin: re"licare 2copii multiple la locaii

diferite3G "arti0ionare 2pări ale lor sunt stocate &n diferite locaii3'

(' Datele sunt adesea distribuite at/t pentru a cre+te tolerana la defecte- c/t +i pentru a

permite cre+terea perfor

' manei prin stocarea datelor &n apropierea zonelor unde sunt produse sau folosite'

Modele de organizare a aplicaţiilor distribuite

7xistă următoarele modele de or#anizare a aplicaiilor distribuite:

5' aplicaii tip Pclient ‐ ser)er .- care presupun executarea unui volum important de prelucrări

locale sau autonome +i parta%area resurselor de calcul sau date

4' aplicaii pe Pcluster .- presupun utilizarea mai multor calculatoare conectate &n reea- sub

forma unei resurse unice

(' aplicaii distri4uite cola4orati)e- care oferă posibilitatea participării mai multor persoane

la atin#erea unui obiectiv sau a mai multora- prin intermediul te"nolo#iei calculatoarelor –

calcul plus comunicaii

' metacalculul- care se referă la utilizarea unui număr foarte mare de resurse de calcul-

21


22/31

foarte puternice +i distribuite pe o arie mare- pentru rezolvarea unor probleme de o mare

complexitate'

Modele arhitecturale s"ecifice+ Modelul cu acces neuniform la memorie NCMA 2Non‐Cniform

MemorQ Acces3+ NCMA cu memorii locale distribuite este o structură de sistem str/ns cuplat

folosită de obicei &n cazul supercalculatoarelor' NCMA ierar"ic cu clustere 2ciorc"ine sau

#rupare de staii de lucru le#ate printr1o reea care cooperează la realizarea unui el comun3'

6lusterul poate fi de tip NCMA sau CMA' 6azul conectării tip HutterflQ local este cel mairapid-

iar cel la distană cel mai lent'

Modelele calcului distri4uit

5' modelul 3fermă de procesoare4 : se caracterizează prin existena unui ansamblu deelemente de prelucrare #enerice +i de servere cu funcii specifice- ale căror facilităi sunt

accesate de la staii de lucru- care &n #eneral au resurse de calcul +i de memorare reduse'

4' modelul 3client-server4 : presupune executarea unui volum important de prelucrări locale

sau autonome +i parta%area resurselor de calcul sau date'

(' modelul 3data flow4 : se bazează pe or#anizarea prelucrării conform unui #raf &n carenodurile

sunt elemente de prelucrare- iar arcele sunt conexiuni lo#ice prin care circulă mesa%ele'

22


23/31

' modelul ierar$ic : resursele de prelucrare sunt or#anizate 2fizic sau lo#ic3 &ntr1o reea de

prelucrare arborescentă' 0n mod curent- nivelurilor mai &nalte ale ierar"iei le sunt asociate

resurse de prelucrare mai puternice'

,' modelul 3cac$e4 : se bazează pe prelucrări realizate etapă cu etapă- efectuate de diverse

elemente de calcul- +i pe combinarea rezultatelor pariale pe un alt element de calcul- de

re#ulă mai puternic' B strate#ie de parta%are a operaiunilor este adecvată &n acest caz'

Modelul 5lient Ser)er

5' 0n sistemele de operare pentru reele de calculatoare se utilizează de cele mai multe ori

modelul client1server'

4' 0n acest caz sistemul de operare conine- &n afară de nucleu- un #rup de procese numite

servere- care oferă servicii proceselor utilizator- acestea devenind astfel clieni'

(' 7xistă procese specializate care realizează diferite servicii- cum ar fi: lucrul cu fi+iere-

compilare- tipărire etc' Cn proces care are nevoie de o astfel de aciune- o cere de la unul din

serverele care sunt dedicate pentru respectivul tip de problemă'

' 0n timpul execuiei diferite procese pot fi at/t client- c/t +i serverG de exemplu serverul de

fi+iere poate deveni client pentru serverul care oferă timpul curent'

,' Dacă at/t serverele- c/t +i clienii se execută &n spaiul de memorie utilizator- structura

nucleului se simplifică mult- rolul acestuia din punctul de vedere al comunicaiei

restr/n#/ndu1se la trimiterea +i recepionarea de mesa%e'

O' Dacă realizarea comunicaiei se bazează pe operaii de tipul transmisie sau recepie-

&nseamnă că elementele principale utilizate &n pro#ramare sunt de tip operaie deintrareie+ire'

>' Activităile din timpul execuiei unei aplicaii distribuite sunt asociate de obicei-abstractizării

de proces si ele nu vor putea să existe dec/t ca pări ale aplicaiei'

R' Cn sistem client1server este realizat pe trei nivele- cel al prezentării- cel al aplicaiei +i celalaccesului la date' Separarea fizică a celor trei nivele se nume+te partiionarea aplicaiei'

2'


24/31

0ntotdeauna nivelul prezentării va fi implementat de către client' 0mpărirea celorlalte două

nivele &ntre client +i server conduce la , stiluri diferite: prezentare distribuităG prezentare la

distanăG aplicaie distribuită- c/nd calculele sunt &mpărite &ntre client +i serverG date la

distanăG date distribuite'

"ig5r$itectura client1server

Aplicaiile distribuite acionează &ntr1un mediu foarte diferit de cel al aplicaiilor client@server'$n paradi#ma client@server- componentele aplicaiei software sunt folosite de cătrecalculatorul client si calculatorul server' $n mediul aplicaiilor distribuite- aplicaia poate aveacomponente care să ruleze pe mai multe calculatoare din reea' Diferena dintre client +iserver dispare' 0n mod evident- o componentă a unei aplicaii distribuite acionează at/t dreptclient- c/t +i ca server'

vanta!ele sistemelor distribuite

5' 6osturi reduse i s1a demonstrat economic că este mult mai ieftin să se folosească maimulte sisteme de calcul la rezolvarea unei probleme complexe- dec/t unul foarte performant'

Acesta are un cost foarte mare +i este dedicat- &n #eneral- numai un flux continuu de

probleme de calcul de foarte mari dimensiuni'

4' Modularitatea +i simplitatea soft1ului – sistemele distribuite pot fi construite &ntr1o manieră

foarte modularizată- unde fiecare componentă permite interfaarea cu restul sistemului

2celelalte componente3 sau servicii foarte bine definite' Modularitatea permite o proiectaresimplă a sistemului- instalare +i &ntreinere mai simple'

(' Flexibilitatea +i extensibilitatea – modularitatea sistemului permite sc"imbarea sau

modificarea elementelor de calcul fără a deran%a ma%or operaiile &n curs de desfă+urare' !rin

folosirea protocoalelor standard de comunicaii este posibil să se includă &ntr o reea‐

ec"ipamente provenind de la diferii producători- rezult/nd o reea omo#enă'

' Fiabilitate +i inte#ritate sistemele distribuite au proprietatea de a putea continuaoperaiunile indiferent de starea unei pări a sistemului folosirea mai multor noduri de calcul

2/


25/31

permite ca- &n cazul defectării sau blocării 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

tas urilor de calcul care nu mai răspund spre alte procesoare‐

,' !erformana este &n #eneral definită &n termenii timpului de răspuns la un anumit #rad de

&ncărcare timpul de răspuns poate fi scăzut- &n mod particular dacă ma%oritatea procesării

este făcuta local paralelismul datorat nodurilor multiple reduce defeciunile +i &ncetinirile ce

pot apărea la nivelul proceselor de calcul +i #enerează o cre+tere a performanei #lobale

software1ul local poate fi folosit +i la preprocesarea sau compactarea datelor- reduc/ndu1se

astfel &ncărcarea pe reeaua de comunicaie +i cresc/nd performanele sistemului'

-eţelele de calculatoare au o etindere rapidăintr3o multitudine de domenii

cum ar 4 sistemul bancar administraţia publicăalocarea temporara de resurse in

hotelurirezervarea de bilete de avionrezervarea biletelor de trenetc. %plicaţiile

moderne iau n considerare accesul unui număr c6t mai mare de utilizatori

mai ales cand se prevede etinderea folosirii cardurilor si cre7te numărul

acelora care utilizează !nternetul.

!roiectarea aplicatiilor distribuite se axează nu numai pe detaliile părilor individuale- ci +ipe realizarea unei inte#rări a componentelor distribuite- astfel &nc/t acestea săcoopereze foarte bine &ntre ele'

!rincipalele cerine pentru aplicaiile distribuite sunt:

interfee puterniceG

fiabilitate foarte mareG

securitate ridicatăG

viteză ridicată de prelucrare +i transmitere a datelor'

0n mod tradiional- aplicaiile software distribuite se bazează pe ar"itectura client@server sau pe ar"itectura multistrat 2n-tier 3'

0n contextul aplicaiilor client@server care utilizează baze de date- ar"itectura client@server presupune existena unui server de baze de date2denumit server3 +i a unui modulsoftware specific aplicaiei 2denumit client3 care prelucrează datele +i prezintă rezultatele-deci conine lo#ica aplicaiei +i lo#ica prezentării'$n acest sistem nu exista notiunea deobiecte-partea de client lucreaza direct cu tabelele de date si procedurile stocate din

baza de date'

25


26/31

0n cadrul ar"itecturii multistrat- un server de aplicaii se interpune intre aplicatia de clientsi serverul de baza de date'Serverul de aplicatii implementeaza lo#ica de aplicatie-iar clientul implementeaza lo#ica de prezentare a sistemului'Avanta%ul ma%or al ar"itecturiimultistrat fata de ar"itectura client@server il reprezinta cresterea fiabilitatii' Ar"itectura Eeb confera acestora fiabilitate-scalabilitate si flexibilitate

ridicata'Aceasta difera fata de ar"itectura multistrat prin doua aspecte:1aplicatia client are o complexitate redusa-fiind un navi#ator EebG1nivelul re#ulilor aplicatiei este bazat pe componete si nu este un sin#ur sistem ceimplementeaza intrea#a constructie'

6omponentele client sunt interfetele #rafice utilizator si ruleaza in navi#atoare Eebprecum Netscape Navi#ator sau $nternet 7xplorer'6omponentele Server care ruleazaintr1un server de aplicatii-furnizeaza lo#ica procesului de afaceri'!entru testarea aplicatiilor distribuite bazate pe internet-trebuie luate in considerareurmatoarele aspecte:1capacitatea de utilizareG usurinta in utilizare si intele#erea elementelor interfetei

constituie elemente importante importante in acceptarea aplicatiei de catre clientiG1functionalitateaGfaptul ca aplicatia realizeaza ceea ce isi propune prin specificatiiconduce la cresterea increderii utilizatorilor in aceasta si in firma producatoareG1compatibilitateaGavand in vedere faptul ca exista o multitudine de combinatii intresisteme de operare-navi#atoare si aplicatiile care ruleaza in navi#atoare-asi#urareacompatibilitatii aplicatiei este o problema importanta-deoarece exista riscul ca o parteimportanta dintre potentialii utilizatori sa nu poate utiliza aplicatia datoritaincompatibilitatii si astfel sunt pierduti o serie de clientiG1performantaGtimpul de raspuns si resursele ocupate reprezinta un aspect importantpentru utilizatorii aplicatiei' $n cazul aplicatiilor $nternet care acceseaza baze de date exista o multitudine de

cause care duc la functionarea incorecta a acestora'De exemplu -testul esuat al uneitranzactii intr1o baza de date poate avea mai multe cauze:

aviator

9erver

:eb

9erver

;e

%plicatii

)aza de

date

%

)aza de

date

)

20


27/31

a'lo#ica bazei de date:procedurile stocate -intero#arile sau comenzile deactualizare-inserare sau ster#ere contin eroriGb'lo#ica serverului de aplicatii:exista erori de proiectare sau de pro#ramare in cadrulfunctiilor implementate in serverul de aplicatiiG

c'lo#ica procesarii tranzactiilor:ordinea eronata a efectuarii unor operatii conduce laesuarea intre#ii tranzactiiGd'comunicatia:in cazul unor probleme de comunicatie la diverse niveluri-tranzactiilefie nu au loc-fie se realizeaza incomplet sau incorect' Testarea aplicatiilor bazate pe ar"itectura Eeb-in plus fata de testarea aplicatiilor clasice-necesita o serie de teste specifice cum ar fi:1testarea functionala1testarea de compatibilitate1testarea continutului1testarea performantei1testarea de incarcare

1testarea securitatii1testarea serverului Eeb-al serverului de aplicatii si testarea bazelor de date' Testarea functionala se realizeaza pentru a constata daca site1ul se comportaconform cu specificatiile sale'Detaliile acestui tip de testare depend de natura site1ului Eeb si-in #eneral-consta in verificarea le#aturilor pa#inilor-testareaformularelor-verificarea tranzactiilor pentru comertul electronic si pentru baze dedate-testarea apleturilor %ava' !rin testarea de compatibilitate se urmareste aspectul si comportamentul site1uluiEeb in raport cu o varietate de sisteme de operare si de navi#atoare$nternet'Aceasta testare scoate in evidenta problemele cu controalele Active-apleturile ava-functiile avaScript sau ;HScript si formulare din pa#ini'Kaora actuala exista peste 5)) de combinatii posibile intre diverse sisteme de operareEindows si diverse versiuni ale navi#atoarelor NetScape si $nternet 7xplorer' !entru testarea continutului se urmareste corectitudinea si asezarea in pa#ina atextelor-ima#inilor si a fisierelor de animatie si video din cadrul site1ului' !rin testarea performantelor se masoara comportamentul site1ului Eeb indiverse conditii de trafic' Testarea de incarcare se utilizeaza pentru a a verifica daca site1ul Eeb poate#estiona un anumit numar de utilizatori care il acceseaza concurrent -in limiteacceptabile ca timp de raspuns' Testarea securitatii tranzactiilor effectuate este foarte importanta pentru

aplicatiile de comert electronica avand in vedere faptul ca sunt ve"iculate dateconfidentiale-la care daca au acces personae neautorizate sau rauvoitoare se potproduce pierderi materiale importante' Testarea serverului Eeb are in vedere testarea interactiunilor dintre serverulEeb si serverul de aplicatii-verificarea inte#ritatii bazei de date in cadrul serverului debaze de date -verificarea faptului ca scripturile AS!-!! sau S! se executa correctpe server' Testarea serverului de aplicatii se realizeaza tinandu1se seama decaracteristicile functionale si structurale ale acestuia'Se testeaza componenteleserverului-folosind metode clasice de testare-precum si metode de testare care iau inconsiderare tranzactiile si comunicatiile asincrone dintre aceste componente'

2(


28/31

Testarea bazelor de date presupune verificarea executarii corecte a intero#arilor si operatiilor de adau#are si actualizare a datelor -precum si verificarea conexiunilor dintre site1ul Eeb si baza de date'Testarea aplicatiilor distribuite bazate pe ar"itectura Eeb este realizata fie de catreec"ipe de specialitate din cadrul departamentului de asi#urare a calitatii a firmei-fie

de catre o firma specializata in testare2out1sourcin#3'

Testarea sistemelor distribuite bazate pe

componente6ele mai cunoscute te"nolo#ii pentru dezvoltarea sistemelor distribuite bazate pecomponente sunt 6B9HA- standardizată de Bb%ect Mana#ement Jroup- D6BM26BMI3dezvoltată de Microsoft +i 9M$ dezvoltată de firma Sun' Aceste te"nolo#ii presupunexistena unor componente 2denumite server3 care- prin intermediul unor interfee- pun ladispoziie funcii- care sunt apelate de componente client aflate pe un alt sistem'Transferul &n cadrul sistemului distribuit se realizează prin intermediul unui protocol binedefinit'

6omponentele unui sistem distribuit operează deseori pe platforme +i ar"itecturi

etero#ene +i- de aceea- este necesar ca instrumentele de testare să opereze +i ele peplatforme +i cu ar"itecturi etero#ene' 6omplexitatea aplicaiilor distribuite cre+te pe

28


29/31

măsură ce componentele din aplicaia software devin complicate' Testarea aplicaiilor distribuite bazate pe componente este văzută la nivel de: micro1model – la acest nivel se descriu pa+ii fiecărui test- pentru fiecare componenta &nparte' Fiecare test conine cazuri de test- ntru fiecare caz de test &n parte fiind definitedriverul de test- +i post1condiiile specifice fiecărei 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 in%ectarea de erori &n scopuldeterm !entru de proiectare +i implementare apar la definirea interfeei- implemtareadatele de test- pre1condiiile macro1model – &n acest nivel se define+te contextul &n care fiecare test va fi rulat' Seare &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 in%ectarea de erori &n scopul determinariiposibilităii serverului de a trata aceste situaii excepionale' aceasta- trebuiedeterminate posibilele surse +i tipuri de erori- utilizate pentru in%ectarea cu erori ainterfeei serverului ' 0n cazul aplicaiilor bazate pe componente distribuite- erorile din

fazele de proiectare si implementare apar la definirea interfeei-implementareaserverului +i &n codul client'6ele mai frecvente erori apar &n descrierea interfeei' B #re+eală des &nt/lnită estespecificarea incorectă a direciei parametrilor- astfel că un parametru de ie+ire estedefinit ca parametru de intrare sau invers' De exemplu se consideră o metodă &ntr1ointerfaă care are ca scop adunarea a două numere' !arametrii metodei sunt a +i b deintrare +i r de ie+ire- declaraia interfeei fiind:

interface I5alcule : I6n7nown

8

99

,RES6;T Suma*<

=r/> 99

?>in@ dou4le a. 99

execuia metodei Suma va avea va efect QUxIz' 0n aplicaiile distribuite există diferite surse +i tipuri de &nc"eieri nereu+ite a execuiei'

Aceste nereu+ite sunt datorate unor cauze diverse- cum ar fi: probleme &n cadrul componentelor 2de exemplu blocarea serverului3G probleme de comunicare &n reea 2&nt/rzieri- con#estionarea reelei3G

2"


30/31

probleme la nivelului B9H 2de exemplu zona tampon a acestuia este plină3G probleme le#ate de securitate +i autentificareG probleme de sincronizare'

7ste prezentat un model de testare distribuită 2fi#ura 4'5,3- precum +i un limba% +ablon

pentru testarea sistemelor distribuite'

Fi#(' 7lementele modelului de testare a sistemelor distribuite

Kimba%ul +ablon pentru testarea sistemelor distribuite prezintă e caracteristici: 1izolarea obiectului de testat care a%ută la testarea implementărilor pariale +ieste utilă la testele unde colaboratorii sunt partialiG

1&ncapsularea obiectului de testat pentru ca &ncapsulatorul să aiba aceea+i interfaăca +i

clasa de testat 26CT3 +i metodele &ncapsulatorului să poată modifica mesa%ele &nainte de retransmitereG

1utilizarea metodelor incapsulate pentru controlG mesa%ele clienilor suntredirecionate către &ncapsulatorG &ncapsulatorul poate &nt/rzia +i c"iar poate reordonamesa%ele &nainte de

retransmitere către obiectul de testatG1 utilizarea unui %urnal de urmărire sincronizatG prin utilizarea %urnalelor de

urmărire fiecare mesa% va avea asociat un astfel de %urnal- iar la analiza ulterioară sepot identifica secvenele testateG se vor testa toate mesa%ele posibileG

1 utilizarea unui client substituit pentru că ace+tia pot &ncapsula cazuri de test cametode +i- de asemenea- clientul poate fi un serverG 1 testarea completă a protocolului este necesară deoarece execuia corectă a uneisin#ure metode nu este de a%uns +i- de aceea- se impune testarea secvenelor demesa%e care &nsoesc o operaieG

'$


31/31

1 verificarea locală a rezultatelor testelorG trimiterea fiecărui rezultat &napoi cătredriverul de test este costisitoare iar distribuirea cuno+tinelor despre teste duce la o &mbunătăire a performanelorG 1 testarea tuturor secvenelor posibileG utilizarea de &nt/rzieri &ntre metode pentru acontrola secvena execuiilor +i acordarea unei atenii speciale ordinii &n care se execută

testeleG 1 utilizarea unui %urnal de urmărire distribuitG &mbunătăirea performanelor se poateface prin distribuirea %urnalului de urmărireG un dezavanta% &l prezintă necesitateasincronizării ceasurilor ma+inilor pentru acurateea %urnalelorG $n momentul de fata se constata o scadere a duratei de proiectare si implementareale aplicatiilor distribuite- &n special ale aplicaiilor de afaceri electronice- datorată &nprincipal necesitaii oportunităilor de afaceri de a patrunde cat mai rapid pe piata'Scăderea duratei ciclului de dezvoltare are consecinte ne#ative asupra procesului derealizare a aplicatiilor in cazul in care nu se acorda o atentie sporita procesului deasi#urare a calitatii'

"I"#I$%&FI':

ANDREW TANENBAUM-Computer Networks

http://www.freetutes.com/systemaa!ys"s/sa#-test"$-%ua!"ty-assurace.htm!

&!efor' Myers( Corey )a'!er ( Tom Ba'$ett-Art of )otware Test"$

http://e.w"k"pe'"a.or$/w"k"/)oftware*test"$

http://www.software%atest.com/
http://www.freetutes.com/systemanalysis/sa9-testing-quality-assurance.htmlhttp://www.euro-libris.ro/autor/glenford-myers--i9819http://www.euro-libris.ro/autor/corey-sandler--i9820http://www.euro-libris.ro/autor/corey-sandler--i9820http://www.euro-libris.ro/autor/tom-badgett--i9821http://en.wikipedia.org/wiki/Software_testinghttp://www.softwareqatest.com/http://www.freetutes.com/systemanalysis/sa9-testing-quality-assurance.htmlhttp://www.euro-libris.ro/autor/glenford-myers--i9819http://www.euro-libris.ro/autor/corey-sandler--i9820http://www.euro-libris.ro/autor/tom-badgett--i9821http://en.wikipedia.org/wiki/Software_testinghttp://www.softwareqatest.com/

testare_software v4

Documents