Metode de Testare a Aplicatiilor Web

Metode de Testare a Aplicatiilor Web

Byadmin ianuarie 1, 2024

INTRODUCERE

Prin aplicatie web intelegem o aplicatie software, care poate fi aceasta prin Internet sau Intranet folosind o aplicatei client (spre exemplu browsere web). In general o aplicatie web este structurata pe trei nivele.

Primul nivel este alcatuit din browserele web, al doilea nivel este alcatuit din suportul pentru invocarea de scripturi CGI si de exploatarea unor servere de aplicatii si cadre de lucru (framework-uri) web precum ASP.NET, JSP, PHP, impreuna cu un server de aplicatii care este in directa legatura cu baze de date si alte obiecte web, iar al treilea nivel se refera la stocarea persistenta a datelor.

Aplicatiile web se caracterizeaza prin faptul ca pot genera reprezentari de resurse web specificate de tipurile MIME (text/html, image/png, application/pdf, etc.). Paginile web generate pot fi de doua tipuri: statice sau dinamice.

Paginile web statice sunt deservite de server-ul de web, continand cod HTML si cod interpretat de catre interpretorul inclus in browser, precum JavaScript.

Paginile web dinamice sunt deservite de serverul de aplicatii si generate ca urmare a invocarii de scripturi diferite si componente de pe server, acestea pot contine cod HTML si cod executabil in acelasi timp.

Modelele folosite in sectiunile urmatoare sunt axate pe scoaterea in evidenta a unor proprietati legate de structura de navigare, continut, comportament si de tipul acestora (static sau dinamic).

Aplicațiile web sunt alcătuite de obicei din pagini HTML, scripturi, imagini, foi de stil, obiecte multimedia, componente dezvoltate cu diverse limbaje de programare. Acest amestec de obiecte, programare și texte face aplicațiile web greu de înțeles și de testat. Desi există multe metode de modelare pentru a obține abstracțiuni ale aplicațiilor web (de exemplu [1], [3], [4], [8]), modelele propuse au tendința de a merge spre specificații și design. Testele aplicațiilor web nu au fost capturate în aceste modele. Un suport a venit de la modelul de test orientat obiect ce propune extragerea datelor atat structurat cât și comportamental a aplicațiilor web.

1. APLICATII WEB

Două modele sunt deosebit de importante:

modelul obiectual;

modelul comportamental.

În continuare ne vom ocupa de prezentarea celui de-al doilea model, exemplificându-l printr-o aplicație specifică multor instituții de învățamânt: orar-ul online.

1.1 Modelul comportamental pentru testarea aplicatiilor web

Modelul comportamental este folosit pentru a descrie aspectele dinamice ale unei aplicații web. Aplicațiile web au comportamente complicate, deoarece starea lor este dependentă de fiecare componentă, de navigare și de dinamica dintre pagini. Pentru aplicații web complexe, alcătuite din sute sau mii de pagini și componente, comportamentul dinamic este foarte complicat. Pentru a reduce complexitatea modelării în modelul comportamental, modelarea se face pe două niveluri.

Primul nivel clasifică obiectele concurente și interacțiunile unei aplicații web în clustere.

Al doilea nivel descrie starea detaliată – comportamentul obiectelor în cadrul clusterului, dependent de interacțiunea obiectelor.

1.1.1 Diagrama navigării clusterelor (CND – Cluster Navigation Diagram):

CND este o mașină de stări finită. Fiecare stare a CND reprezintă un cluster de obiecte, care sunt legate de o mulțime de pagini client concurente.

Tranzițiile lui CND reprezintă modificările de stare cauzate de navigare sau de generare dinamică a paginilor.

Formal CND, pentru o aplicație web este o masină deterministă cu stări finite CND=(S,σ,δ,q0,qf), unde:

S este o mulțime finită de stări, fiecare dintre ele este reprezentată de o pereche de obiecte agregate (<cp>,<sp>), unde <cp> reprezintă o mulțime de pagini client concurente și componentele lor asociate pe partea de client–side și <sp> reprezintă o mulțime de pagini server și componentele asociate pe partea de server-side. Mai mult paginile client <cp> au relații de cerere HTTP cu pagini de server în <sp>.

σ este o mulțime finită de triggere, fiecare dintre ele constă dintr-o condiție specifică (eventual vidă) și un hyperlink ce activează o pagină de navigare sau generează o pagină.

δ este o funcție, δ:S×σ→S, numită funcție de tranziție.

q0 este starea inițială, care conține pagina de pornire a unei aplicații web.

qf S este o mulțime (eventual vidă) de stări finale.

Stările unui CND pot fi derivate de clasificarea obiectelor, care sunt legate prin relațiile de cerere, redirecționare sau de asociere într-un ORD.

Tranzițiile între stări pot fi obținute din ORD prin intermediul navigării sau relațiilor de răspuns.

Construirea unui CND pentru o aplicație web poate fi realizată prin parcurgerea etapelor:

1) Construirea stării inițiale (cp0,sp0), unde cp0 și sp0 sunt mulțimi de obiecte. Inițial cp0 și sp0 sunt mulțimiea vidă, apoi:

– examinați ORD-ul aplicației web și adăugați paginile principale (inițial paginile client) pentru cp0;

– pentru fiecare pagină client ci în cp0 se identifică componentele lui ci din ORD și se adaugă în cp0;

– pentru fiecare pagină client ci în cp0 se identifică paginile server solicitate de ci din ORD și acestea se adaugă la sp0 ca submulțime;

– pentru fiecare pagină server sj în submulțimile lui sp0 se identifică paginile server redirecționate și asociate componentelor lui sj din ORD și se adaugă obiectele identificate în submulțimea corespunzătoare lui sj.

2) Crearea mulțimii S cu stările accesibile, inițial S={(cp0,sp0)}.

3) Selectați o pre-stare (cpi, spi) din S și identificați tranzițiile pentru (cpi,spi).

– Pentru fiecare pagină client cj din cpi, există o tranziție de navigare, dacă exită o relație de navigare, care conduce cj la o pagină curentă.

– Pentru fiecare pagină server sj din spi există o pagină generată prin tranziție, dacă sj este răspunsul la o pagină client. Dacă sj poate genera mai mult de o pagină client, condiția asociată este necesară clarificării tranziției corespunzătoare fiecărei generări de pagină client.

4) Identificarea post-stărilor pentru tranzițiile din (cpi,spi).

– Pentru fiecare tranziție tk identificată în pasul de mai sus , construim o nouă mulțime cpk din cpi, astfel:

i) eliminarea paginii client schimbate de către tk și componentelor asociate din cpi ;

ii) adăugarea noii pagini client aduse sau generate de tk și componentele sale asociate în cpi

– Construirea noii mulțimi spk bazate pe cpk folosind abordări similare pasului i)

– Conectați post-starea (cpk,spk) din (cpi,spi) pentru tranziția tk cu hyperlink-ul URL prin eticheta lui tk.

5) Dacă (cpk,spk) nu a avut loc înainte, se adaugă în S.

6) Eliminați (cpi,spi) din S și repetați pasul 3) până când S devine mulțimea vidă.

Starea inițială (<Utilizator, Acasa>) precizează faptul că pagina client Utilizator și Acasa există în același timp. De la starea inițială, o tranziție de navigare poate fi declanșată, există un hyiperlink de navigare din pagina Utilizator în pagina CadruDidactic. Pagina Acasa este înlocuită cu pagina CadruDidactic ca atribut țintă al relației de navigare . Mai mult, pagina de server Lectori și asocierea componentei DateLectori sunt solicitate de pagina CadruDidactic.

Astfel, există o tranziție de la starea inițială la starea ((<Utlizator, CadruDidactic>, <Lectori, DateLectori>). Tranziția este etichetată cu url: CadreDidactice, respectiv URL-ul paginii CadreDidactice.

În figura de mai jos (Figura 1) se află CND-ul pentru exemplul Orar.

Figura 1. Diagrama de Navigare Cluster pentru exemplul Orar

Similar, pagina Lectori poate genera două pagini client, Zi și UltimaZi, care înlocuiesc pagina CadruDidactic și rezultă două stări (<Utilizator, CadruDidactic>, [<Lectori,DateLectori>, <Gestiune, Orar>]) si (<Utilizator, UltimaZi>, <Gestiune,Orar>). Aceste două stări pot fi obținute prin cererea și relațiile de asociere ce corespund paginilor Zi și UltimaZi. Se poate întâmpla ca în aplicații web, o pagina server să genereze pagini client diferite, bazate pe datele primite sau starea internă a paginilor server. Astfel, cererea aceluiși hyperlink la o pagină server poate avea ca rezultat pagini client diferite.

Condiția de restricție este impusă pe o tranziție și trebuie să fie adevărată în scopul de tranziție fire.

Așa cum arată figura 1, condiția de restricție ultimul, între paranteze drepte, pentru tranziția url:Lectori, indică faptul că pagina server Lectori poate genera pagina Zi sau UltimaZi în funcție de stările interne.

În Orar, pagina Utilizator este folosită ca bară de meniu, existând în fiecare stare a CND. Ca rezultat, fiecare stare poate avea un URL de tranziție: url:Utilizatori, cauzată de pagina Utilizator a stării (<Utilizator,CadreDidactice>, <Lectori,DateLectori>).

Pentru a simplifica, figura 1 nu arată toate aceste tranziții. În plus, fiecare stare indică o mulțime de pagini client concurente și obiecte care interacționează. Acest lucru permite testări pentru clasificarea elementelor componente ale unei aplicații web în grupuri, care pot fi abordate împreună. Prin urmare comportamentul dinamic al unei aplicații web poate fi considerat un mixaj de stări – dependente comportamental de obiecte care interacționează în stările CND-ului și navigarea sau comportamentul paginilor generate între stări.

1.1.2 Diagrama de stări a obiectelor (Object State Diagram)

Pentru a specifica comportamentul propriu al unui obiect și modul de colaborare și comunicare se descrie Diagrama de Stare Obiect (OSD). OSD-ul este o mulțime ierarhică, concurentă, comunicând cu mașini de stare. Aceasta reprezintă starile comportamentale ale unui singur obiect dintr-o aplicație web. Comportamentul dependență-stare a unui obiect agregat este modelată ca un compozit OSD (COSD) din OSD-urile corespunzătoare. Din COSD poate fi descris comportamentul dinamic al diferitelor obiecte agregate, precum și interacțiunile lor. Descrierea detaliată a OSD-ului și COSD-ului poate fi găsită în [7].

Figura 2 contine COSD-ul pentru obiectele în starea (<Utilizator, Orar>,<Orar, OrarLector>) din figura 2. Dependența stare-comportament ale acestor obiecte este modelată ca un COSD, care este o agregare a paginilor client Utilizator și Orar, pagina server Orar și componenta OrarLector.Pagina client Orar poate accepta, reseta sau cere o revizuire a utilizatorului. De asemenea poate depune cereri de utilizatori de pagini server Orar, dacă intrările sunt valide.După primirea cererii pagina server Orar extrage datele de submit, întreabă OrarLectori pentru completarea orarului și generearea răspunsului bazat pe acest rezultat. OrarLectori are grijă de operațiile cu baza de date și returnarea răspunsurilor paginii server Orar. În COSD interacțiunile dintre obiecte, cum ar fi cererile HTTP reguest/response sunt modelate prin utilizarea trrigere-lor arătate înainte de /. Spre exemplu tranzitia ”submit/S.recv_request” a paginii client C are trigger-ul S.recv_request.

Acest lucru înseamnă că tranziția recv_request a server-lui S va fi invocată în cazul în care tranziția ”submit” va fi blocată. Astfel, presupunând că C este starea de “input” și S în starea “idle”, după tranziția de intrare, starea ulterioară a lui C și S devin ”wait”, respectiv ”retrieve”.

Mai mult o stare de așteptare este angajată în OSD, pentru a sincroniza obiecte concurente. În cazul în care un obiect intră în starea de așteptare, obiectul va aștepta până când o tranziție a sa este declanșată de alte obiecte. De exemplu pagina client Orar va sta în starea ”wait” până când tranziția ”recv_response” este declanșată de tranziția ”response” a paginii Orar. Observăm faptul că tranziția “response” a paginii server Orar și tranziția “link” a paginii client Utilizator conduce la generarea paginii indicate si navigarea putand conduce la tranzitiile din CND. Ca rezultat obiectele din actualul COSD vor intra în stările “exit”.

Figura 2. COSD pentru continutul obiectelor (Utilizator, Orar, Orar, OrarZi)

În construirea COSD pentru obiecte dintr-o stare din CND, un aspect important este faptul că o pagină client poate avea relații de cerere nu numai cu o pagină server. Cu toate acestea o pagină client poate solicita decât o singură dată pagina server la un moment dat. În consecință o pagină server și componentele asociate pentru pagină client particulară nu pot coexista cu alte pagini server solicitate de din aceeași pagină client, pe server-side, în același timp. Astfel în construirea COSD-ului, există o XOR compunere pe paginile server și componentele lor asociate de caâătre aceeași pagină client. Spre exemplu, în figura 2, pagina client Zi a stării (<Utilizator, Zi>, [<Lectori, DateLectori>|<Gestiune, ZiDate>]) poate solicita servicii fie de la pagina server Lectori, fie de la Gestiune. Astfel pentru aceasta stare exista doua COSD-uri ortogonale notate cu (<Utilizator, Zi>, <Lectori, DateLectori>) si respectiv (<Utilizator, Zi>, <Gestiune, ZiDate>).

Observatii

Modelul comportamental este folosit de majoritatea verificatoarelor existente pe Internet (spre exemplu: [9], [10], …, [15]), precum și de aplicațiile complexe care verifică aplicații web. Acest model este utilizat pe majoritatea platformelor care sunt destinate testării, în același timp poate folosit și la crearea și întreținerea aplicațiilor web.

1.2. MODELUL OBIECTUAL PENTRU TESTAREA APLICATIILOR WEB

1.2.1. Introducere

Aplicațiile web sunt alcătuite de obicei din pagini HTML, scripturi, imagini, foi de stil, obiecte multimedia, componente dezvoltate cu diverse limbaje de programare. Acest amestec de obiecte, programare și texte face aplicațiile web greu de înțeles și de testat. Desi există multe metode de modelare pentru a obține abstracțiuni ale aplicațiilor web (de exemplu [1], [3], [4], [8]), modelele propuse au tendința de a merge spre specificații și design. Testele aplicațiilor web nu au fost capturate în aceste modele. Un suport a venit de la modelul de test orientat obiect ce propune extragerea datelor atat structurat cât și comportamental a aplicațiilor web.

Două modele sunt deosebit de importante:

modelul obiectual;

modelul comportamental.

În continuare ne vom ocupa de prezentarea primului model, exemplificându-l printr-o aplicație specifică unei instituții de învățamânt: orar-ul online.

1.2.2 Modelul obiectual

Modelul obiectual este folosit pentru a descrie aspecte structurale ale unei aplicatii web folosind obiecte și relații de depență dintre ele. Se folosesc trei tipuri de obiecte:

pagină client ;

pagină server ;

componente .

O pagină client este un document HTML cu scripturi integrate, care este dată clientului prin browser.

O pagină server este un script CGI (Common Gatewaz Interface), un ASP (Active Server Page), o JSP (Java Server Page) sau un servlet, care este executat pe partea de server.

O componentă poate fi un element HTML, un applet Java, un control ActiveX, un Bean Java, un server-side incluzând fișierul, sau orice alt modul de program care interacționează cu pagini de client, pagini server sau alte componente.

Atributele pot fi variabile pot fi variabile, în timp ce operațiile pot fi funcții scrise în scripturi sau diferite limbaje de programare.

Pentru a descrie obiectele și relațiile dintre ele, folosim ORD-uri (Object Relation Diagram, [7]).

Un ORD (notație ORD=(V,E)) este un graf orientat, V fiind mulțimea nodurilor reprezentând obiecte și este mulțime arcelor, care reprezintă relațiile dintre obiecte.

Relațiile dintre obiecte pot fi clasificate astfel:

relații de cerere (Request)

relații de răspuns (Response)

relații de navigare (Navigation)

relații de redirecționare (Redirect)

relații de moștenire

relații de agregare

relații de asociere

Relațiile de cerere, de răspuns, de navigare și redirecționare sunt tipuri speciale de relații de asociere, pe care le vom defini în continuare.

Relația de cerere Request este o mulțime de arce care reprezintă relațiile dintre cererea HTTP dintre o pagină client și o pagină server. Astfel Request este defită de . Pentru orice două pagini indică faptul că pagina de server v2 este solicitată de pagina client v1.

Relația de răspuns Response este o mulțime de arce reprezentând relația de răspuns în HTTP dintre pagina client și pagina server. Astfel Response este defită de . Pentru orice două pagini indică faptul că v1 este generat de pagina de server v2.

Relația de navigare Navigation este o mulțime de arce reprezentând relațiile de navigare între două pagini client. Astfel Navigation este defită de . Pentru orice două pagini client indică faptul că există un hiperlink de navigare din pagina client v1 în pagina client v2. Dacă v2 este un frame sau o fereastră diferită de v1, atunci este necesar un atribut care să precizeze frame-ul țintă sau fereastra pentru v2.

Relația de redirectare Redirect este o mulțime de arce reprezentând relația dintre două pagini server. Astfel Redirect este definită de . Pentru orice două pagini server indică faptul că pagina server v1 redirectează prin http solicitarea la pagina server v2.

În continuare vom prezenta ORD-ul pentru aplicația Orar. Pagina client Orar este alcătuită din două pagini:

pagina client Acasa

pagina client Utilizator

De la pagina client Utilizator se poate naviga la tipul de utilizator dorit, cum ar fi de exemplu: pagina client Cadru didactic.

De la pagina client Cadru didactic se poate naviga la o subcategorie, cum ar fi pagina server Lectori, unde componenta Date_Lectori este necesră pentru a prelua date din baza de date. Având în vedere că datele preluate pot să nu încapă într-o singură pagină, pagina server Lectori va genera componentele: pagini client zi. Din paginile generate, utilizatorul poate selecta o zi în care va introduce anumite ore pe care le va efectua. În cazul în care se alege o oră se va trimite o solicitare către pagina server Gestionare în care componenta Date_zi este necesară pentru a prelua informațiile zilei selectate.

Pe baza rezultatelor, pagina server Gestionare generează o pagină client Orar, unde utilizatorul poate propune o plasarea unei ore în orar și trimiterea catre pagina sever Orar a acesteia.

Pagina server Orar solicită componentei Dare_zi procesarea propuneri de introducere in orar a respectivei ore și generează OrarComplet, fie pagina client OrarRespins. În continuare utilizatorul poate merge la pagina Cadru Didactic, pentru a continua plasarea celorlalte ore. Diagrama relațiilor dintre obiecte (ORD) este prezentată în continuare.

Figura 1. Diagrama de Relații Obiect pentru exemplul Orar

Utilizarea ORD-urilor poate ajuta la înțelegerea structurilor și relațiilor de dependanță ale aplicațiilor web. Componentele unei aplicații web, în ORD sunt tratate ca obiecte. Astfel fiecare tip de obiect poate avea metodele sale de testare, de sprijin și utilizare pentru testarea aplicației web. În plus, dependența de relațiile obiectelor din ORD, poate fi utilizată ca un plan de parcurs, pentru a identifica efectele schimbărilor cauzate de modificări și de a obține o strategie eficientă de testare (detalii în [6]).

Observatii

Modelul obiect este folosit de majoritatea verificatoarelor existente pe Internet (spre exemplu: [9], [10], …, [15]), precum și de aplicațiile complexe care verifică aplicații web. Acest model este utilizat pe majoritatea platformelor care sunt destinate testării, în același timp poate folosit și la crearea și întreținerea aplicațiilor web.

TESTAREA APLICATIILOR WEB FOLOSIND AUTOMATE FINIT DETERMINISTE

In capitolele anterioare au fost prezentate diverse modalitati de reprezentare a proiectului (designul) unei aplicatii web. Modelul pe care il vom folosi in aceasta sectiune este un automat finit determinist. Inca din faza de proiectare este simulata testarea prin diverse instrumente a proiectului aplicatiei, rolul acesteia fiind acela de a verifica daca starile obtinute prin tranzitie sunt in multimea de stari si conforme cu cerintele aplicatiei. Aceasta operatie o vom numi testarea proiectului.

Dupa aceasta testare prealabila urmeaza codificarea modulelor aplicatiei si testarea acestora.

Daca testarea a fost cu succes aceste module sunt integrate intr-o aplicatie urmand inca o testare. Aceasta operatie este denumita testul de sistem si de verificare a proiectului. Testarea proiectului constituie o sursa de teste pentru testarea aplicat，iei in sine.

In general metodele de testare pot fi automatizate prin intermediul unor aplicatii de testare. Au fost creati mai multi algoritmi care sa foloseasca automate finit deterministe si caracteristici ale acestora pentru a genera teste, precum cei prezentati in [22]. Automatele sunt folosite ca sursa de obtinere a testelor, acesta nefiind supus testarii. Implementarea acestui mecanism este cunoscut sub numele de Implementation Under Test (IUT). Spre exemplu putem sa gandim automatul finit determinist ca un model de protocol de comunicare, iar IUT ca punerea in aplicare a acestuia. Testele obtinute in sectiunile urmatoare prin diversi algoritmi sunt folosite la IUT pentru a verifica daca acesta se comporta conform cu specificatiile aplicatiei.

2.1 Metoda W

Metoda W este folosita pentru a determina o multime de teste pornind de la un automat finit determinist A. Un test este alcatuit dintr-o secventa de simboluri, fiind folosit ca intrare pentru un program ce are structura de control modelata de un automatul finit determinist A. Mai mult, un astfel de test poate fi folosit pentru a testa proiectul ce respecta specificatiile lui A.

Pentru a functiona corect, metoda W utilizeaza automate finite deterministe specificate complet, care incep intr-o stare initiala fixata, poate fi resetat, iar A si IUT au acelasi alfabet de intrare.

In continuare vom considera un automat finit determinist complet specificat si minimal.

Figura 1. Automat finit determinist

A=(S, σ, δ, qi, qf, γ), unde:

• S este o multime finita cu starile;

• σ este o multime finita cu simbolurile de intrare;

• δ este functia de tranzitie, δ:S×σ → S;

• qi starea initiala;

• qf multimea simbolurilor de ie，sire;

• γ functia de raspuns (de iesire), γ:σ+×S → qf+, unde pentru o multime X, folosim notatia X+ pentru multimea secventelor (cuvintelor) cu elemente din X.

Exemplul 1.

Sa consideram o aplicatie web caracterizata de automatul din figura 1,

S = {s1, s2, s3, s4}, σ = {a, b}, qf={0, 1}, qi=s1.

Sa consideram secventa baab，si sa vedem cum se comporta automatul cand se aplica aceasta. Automatul este pornit in starea s1 si trece pe rand prin starile: s1 → s4 → s3 → s2 → s3. Iesirea generata fiind 1101. Astfel γ(baab, s1) = 1101.

Metoda W, [22] consta in parcurgerea urmatorilor pasi:

• Determinarea numarului de stari in partea de proiectare.

• Construirea multimii de caracterizare, notata cu W pentru automatul A asociat aplicatiei.

Construirea arborelui de testare pentru automatul A，si determinarea multimii tranzitiilor de acoperire, notata cu P.

• Construirea multimii Z.

• Stabilirea multimii de teste, obtinuta prin concatenarea secventelor din P cu cele

din Z.

2.1.1 Determinarea multimii de caracterizare W

Multimea de caracterizare a unui automat A, ca cel precizat in partea introductiva, notata cu W caracterizeaza comportamentul acestuia. Mai precis, W este formata din secvente de caractere din σ+, care indeplinesc conditia:

pentru orice doua stari si, sj din S, exista o secventa w din W cu proprietatea γ(w, si) ≠ γ(w, sj).

Numarul de elemente al multimii W trebuie sa fie cat mai mic.

Exemplul 2

Folosind o aplicatie data prin intermediul automatului din figura 1 putem verifica prin calcule directe faptul ca W = {bb, abb, aab}.

Daca, de exemplu consideram starile s1 si s2, avem γ(aab, s1) ̸= γ(aab, s2), pentru ca γ(aab, s1) = 001, iar γ(aab, s2) = 101.

Folosind o relatie de echivalenta pe multimea starilor dependenta de lungimea secventelor in [22] se prezinta un algoritm de determinare a multimii W.

2.1.2 Determinarea multimii P

Multimea P este alcatuita din toate secventele care determina drumurile de la radacina la frunze in arborele de testare asociat automatului A. Acest arbore se construieste nivel cu nivel, radacina fiind starea initiala. Etichetele arcelor sunt intrarile ce conduc la starea respectiva. Daca ne aflam pe un nivel h intr-un nod si, atunci nodurile de pe nivelul h+1, adiacente cu si sunt cele corespunzatoare starilor sj in care putem ajunge din si, folosind o intrare din σ.

Pentru exemplul 1 arborele de testare este cel din figura 2.

Multimea P pentru exemplul 1 este urmatoarea: P = {ϵ, a, b, bb, bab, baaa, baab}, unde ϵ reprezinta secventa vida.

Figura 2. Arborele de testare

2.1.3 Determinarea multimii Z si a multimii de teste

Vom nota cu m numarul de stari al lui IUT, iar cel al lui A cu n, n≤m.

Multimea Z este reuniunea multimilor σi.W, i din {0, 1, …, m-n}, unde:

• pentru doua multimi de secvente de simboluri X si Y, X.Y reprezinta multimea

secventelor obtinute prin concatenarea unei secvente din X cu o secventa din Y;

• σ0={ϵ};

• σ1=σ;

• σ2=σ.σ;

• σi=σi-1.σ, i din {1, …, m-n}.

Pentru exemplul 1, m=n，si Z = σ0.W ={bb, abb, aab}.

Multimea de teste T se obtine prin concatenarea secventelor din P cu cele din Z. Astfel :

T = P.Z.

Pentru exemplul 1, obtinem T = {ϵ, a, b, bb, bab, baaa, baab}.{bb, abb, aab}. Astfel:

T = {bb, abb, aab,abb, aabb, aaab,

bbb, babb, baab, bbbb, bbabb, bbaab,

babbb, bababb, babaab, baabb, baaabb, baaaab,

baabbb, baababb, baabaab}.

2.2 Metoda produsului sincron

Metoda pe care o vom prezenta in continuare, [23] se bazeaza pe faptul ca o aplicatie web poate fi consiterate ca avand doua componente: partea de client, respectiv server. Fiecare dintre aceste parti va fi modelata folosind un automat determinist Ac, pentru client si As pentru server, iar modelarea intregii aplicatii va fi realizata prin intermediu produsului sincron, asociat celor doua automate si notat cu A = Ac Π As.

Pentru a exemplifica modul de construire a automatelor，si modul de generare al testelor vom folosi o aplicatie web, prin care studentii Facultatii de Matematica – Informatica consulta orarul de la una din sectiile matematica sau informatica, precum si informatii despre cursurile facultatii.

Aplicatia web va contine o pagina de intrare pe care o vom nota cu p1, de la care putem selecta prin trei link-uri intrarea in zona orarului, pentru matematica, respective informatica folosind o autentificare, iar pentru zona cursuri intrarea este fara restrictie. In figura 3 este prezentat modul de functionare a aplicatiei.

Aflarea orarului pentru un student la matematica presupune incarcarea doua pagini web: p2 (pentru autentificare) si p3 (informatii cu orarul de la sectia matematica). La fel avem paginile web p4 si p5, pentru sectia informatica, iar pentru sectiunea cursuri se va incarca pagina web p6. Modelarea parti de client va fi realizata prin automatul finit determinit Ac=(Sc, σc, δc, qic, qfc), unde:

• Sc este o multime finita de stari – alcatuita din pagini web si situatiile scurte de asteptare. Astfel, Sc = {A1, A2, A3, A4, A5, p1, p2, p3, p4, p5, p6 };

• σc = { info1, info2, login1, login2, submit1, submit2, logout1, login3, login4, submit3,

submit4, logout2 };

• qic = {p1} este multimea starilor initiale;

• δc este functia de tranzitie, δc:Sc×σc → Sc definita astfel:

δc(p1,login1)=A1; δc(A1,login2)=p2; δc(p2,submit1)=A2;

δc(A2,submit2)=p3; δc(p3,logout1)=p1; δc(p1,login3)=A3;

δc(A3,login4)=p4; δc(p4,submit3)=A4; δc(A4,submit4)=p5;

δc(p5,logout2)=p1; δc(p1,info1)=A5; δc(A5,info2)=p6;

• qfc = {p1, p6} este multimea starilor finale;

In figura 3 este reprezentat automatul Ac.

Figura 3. Reprezentarea partii de client a aplicatiei web

Figura 4. Reprezentarea partii de server a aplicatiei web

Modelarea partii de server va fi realizata prin automatul finit determinit As=(Ss, σs, δs, qis, qfs), unde:

• Sc este o multime finita de stari – alcatuita starile server-lui. Astfel, Ss = {S1, S2, S3, S4, S5, S6, S7, S8, S9};

• σs = { info1, info2, login1, login2, submit1, submit2, logout1, login3, login4, submit3, submit4, logout2, find1, find2, find3, find4};

• qis = {S1} este multimea starilor initiale;

• δs este functia de tranzitie, δs:Ss×σs → Ss definita astfel:

δs(S1,login1)=S7; δs(S7,login2)=S1; δs(S1,submit1)=S2;

δs(S2,submit2)=S4; δs(S4,logout1)=S1; δs(S2,find1)=S3;

δs(S3,find2)=S2;

δs(S1,login3)=S8; δs(S8,login4)=S1; δs(S1,submit3)=S5;

δs(S5,submit4)=S6; δs(S6,logout2)=S1; δs(S5,find3)=S6;

δs(S6,find4)=S5;

δs(S1,info1)=S9; δs(S9,info2)=S1;

• qfs = {S1} este multimea starilor finale;

In figura 4 este reprezentat automatul As.

Produsul sincron al automatelor Ac si As, il vom nota cu A = AcΠAs = (S, σ, δ, qi, qf), actiunile sincrone fiind σsinc = σc ∩ σc ={find1, find2, find3, find4} nevida, unde:

• S = Sc × Ss;

• σ = σc ∪ σs = { info1, info2, login1, login2, submit1, submit2, logout1, login3, login4, submit3, submit4, logout2, find1, find2, find3, find4};

• qi = qic × qis = {(p1, S1)} este multimea starilor initiale;

• qf = qfc × qfs = {(p1, S1), (p6, S1)} este multimea starilor finale;

• δ este functia de tranzitie, δ:S × σ → S definita astfel:

1) daca v este din σsinc, δc(wc,v) = uc, δs(ws,v) = us, atunci δ((wc, ws),v) = (uc, us);

2) daca v nu se afla in multimea σsinc, δc(wc,v) = uc, δs(ws,v) = ε, atunci δ((wc,ws),v) = (uc, ws);

3) daca v nu se afla in multimea σsinc, δc(wc,v) = ε, δs(ws,v) = us, atunci δ((wc,ws),v) = (wc, us);

4) daca v este din σsinc, δc(wc,v) = ε, δs(ws,v) = ε, atunci δ((wc, ws),v) = ε;

Pentru doua stari s si v, notat，ia δc(s,v) = ε semnifica faptul ca nu exista tranzitie de la starea s la starea v.

Datorita numarului mare de stari pe care le poate avea automatul obtinut prin produsul sincron a doua automate finit deterministe, practic acestea nu se vor construi decat pe baza cererilor, nu toate deodata. Algoritmii folositi pentru acest tip de automate, datorita constrangerilor legate de memorie, folosesc o functie succesor, precum cea definite in [24].

Pentru exemplul nostru, obtinem reprezentarea din figura 5.

Modul de construire a testelor :

Odata construit produsul sincron al automatelor, asociate partii de client si de server al unei aplicati web, folosind un algoritm de parcurgere al unui graf orientat se genereaza teste, care se pot folosi la testarea aplicatiei. Parcurgerea se va face pornind din starea initiala (in exemplul anterior este starea qis = {(p1, S1)}). Cazurile de testare pentru exemplu, ce se obtin cu aceasta metoda sunt urmatoarele:

p1S1 A5S9 p6S1

p1S1 A1S7 p2S1 A2S2 A2S3 A2S2 p3S4 A5S1

p1S1 A3S8 p4S1 A4S5 A4S6 A4S5 p5S10 A5S1.

Figura 5. Reprezentarea produsului sincron asociat aplicatiei web

3.APLICATIE WEB TESTATA CU TOOL-URI ONLINE

3.1 Validatoare

In acest moment exista multe aplicatii folosite pentru testarea si verificarea aplicatiilor web. Aceste aplicatii folosesc metodele prezentate in capitolele anterioare, unele dintre ele se pot folosi liber direct de pe Internet, precizand locatia unde se gaseste aplicatia web de testat.

Dintre aceste tool-uri amintim:

1. HTML Validator
http://validator.w3.org/
Acest validator HTML verifica validitatea marcarii documentelor Web in HTML, XHTML, SMIL, MathML, etc;

2. CSS Validator

http://jigsaw.w3.org/css-validator/
CSS Validator – valideaza stilurile CSS;

3. Links Validator
http://validator.w3.org/checklink
Link Checkerul analizeaza legaturile intr-un document HTML/XHTML. Folositor pentru depistarea legaturilor intrerupte.

4. RSS Feed Validator
http://validator.w3.org/feed/
Acesta este un serviciu care verifica sintaxa RSS feeds.

5. Free Site Validator

http://freesitevalidator.com/

Acest serviciu scaneaza intregul site pentru a valida erorile si linkurile “moarte” si genereaza un raport in timp real.

6. WebAIM Wave
http://wave.webaim.org/

Wave este serviciul meu de accesibilitate favorit – acesta iti arata greselile si este chiar productiv.

7. Functional Accessibility Evaluator
http://fae.cita.uiuc.edu/
Folositor pentru evaluarea accesibilitatii functionale a site-ului.

8. Hera
http://www.sidar.org/hera/
HERA este o unealta care verifica accesibilitatea paginilor Web, potrivit specificatiilor Web Content Guidelines.

9. Xenocode

http://www.xenocode.com/Browsers/

Folosind Xenocode poate fi folosit orice browser. Chiar IE6, IE7, si IE8 simultan.

10. Browsershots
http://browsershots.org/
Un serviciu foarte bun pentru a testa un site in orice browser pe majoritatea sistemelor de operare.

11. IeTester
http://www.my-debugbar.com/wiki/IETester/
Acesta incorporeaza toate versiunile de IE intr-o singura aplicatie.

12. Microsoft Expression SuperPreview

http://www.microsoft.com/expression/

Noua aplicatie de la Microsoft este facuta sa ajute la comparatia unui site pe diferite browsere.

13. Pingdom Tools
http://tools.pingdom.com
Analizeaza viteza website-ului and testeaza felul in care elementele sunt incarcate.

14. YSlow
http://developer.yahoo.com/yslow/
Aplicatia autoritara in optimizarea site-ului pentru obtinerea unei viteze superioare.

15. Web Page Analyzer

Analyze

O aplicatie simpla dar foarte folositoare care genereaza un raport despre performantele site-ului.

Cateva dintre aceste tool-uri le vom utiliza pentru testarea si verificarea unei aplicatii web creata special in acest scop. Rezultatele obtinute cu acestea vor fi prezentate in ultima sectiune.

3.2Prezentarea genarala a aplicatiei web

Aplicatia web este un site de prezentare a sistemului nostru solar. Din meniul principal putem alege:

Prima pagină

Caracteristici

Soarele

Planete

Galerie

Video

Contact

Aplicatia a fost realizata in cea mai mare parte in limbajul HTML, prin programare direct in cod sursa (scrierea liniilor de comanda). Filmele din categoria Video au fost introduse cu ajutorul unui flash player (‘FLVPlayer_Progressive.swf’) si al unui skin (‘Corona_Skin_3.swf’).

3.3 Structura și conținutul aplicatiei web

Aplicatia a fost realizata in cea mai mare parte in limbajul HTML, prin programare direct in cod sursa. Scrierea liniilor de comanda s-a facut cu Adobe Dreamweaver CS4 , vizualizarea codului putandu-se face cu orice editor text (MS Word, Notepad s.a.).

Structural, prima pagina (index.html) este structurata cu ajutorul div-urilor si a tabelelor.

In primul rand (table row) este prezentat meniul animat,din care poti alege: Prima pagină, Caracteristici, Soarele, Planete, Galerie, Video, Contact

Meniul principal a fost realizat in html si css (cascading style sheet), pentru care s-a folosit in principal programul de editare Adobe Dreamweaver CS4. De asemenea banner-ul din partea de sus a paginii a fost facut in Adobe Photoshop CS3 .

Prima pagina – index.html. In aceasta pagina este prezentata o animatie a sistemului solar, cu miscarile de revolutie reprezentative pentru toate planetele ( cat si pentru Luna).

Imaginea contine link-uri care te conduc la pagina respectiva.

Contine o animatie a sistemului solar inclusiv pentru Luna.

Caracteristici – caracteristici.html Detalii generale despre sistemul solar si planetele sale.

Soarele – soarele.html Aceasta pagina prezinta detalii despre steaua sistemului solar: Soarele.

Planete – In aceasta pagina sunt prezentate detalii despre fiecare planeta a sistemului solar. Avem urmatorul submeniu cu planetele:

Mercur

Venus

Pământul

Marte

Jupiter

Saturn

Uranus

Neptun

Pluto

Galerie foto – galerie.html In aceasta pagina se prezinta imagini despre sistemul solar (se foloseste Jquery pentru animatie)

Video – video.html. Sectiunea video a site-ului. Se prezinta un clip video despre nasterea sistemului solar.

Contact – contact.html. Detalii despre autorul aplicatiei web.

Codul sursa al paginii ‘index.html’:

<head>

<title>Sistemul Solar</title>

$(function(){

$('ul#descriptions h2').hover(function(){

$('ul.solarsystem li.' + $(this).attr('id') ).toggleClass('active');

})

});

</script>

</head>

<body>

<h2>Sistemul Solar</h2>

<p class="disclaimer">Sistemul solar – informații generale</p>

</header>

</section>

<li class="mercury"><a href="#mercury"><span>Mercury</span></a></li>

<li class="venus"><a href="#venus"><span>Venus</span></a></li>

<li class="earth"><a href="#earth"><span>Earth<span class="moon"> & Moon</span></span></a></li>

<li class="asteroids_meteorids"><span>Asteroids & Meteorids</span></li>

<li class="jupiter"><a href="#jupiter"><span>Jupiter</span></a></li>

<li class="saturn"><a href="#saturn"><span>Saturn & <span class="ring">Ring</span></span></a></li>

<li class="uranus"><a href="#uranus"><span>Uranus</span></a></li>

<li class="neptune"><a href="#neptune"><span>Neptune</span></a></li>

<li class="pluto"><a href="#pluto"><span>Pluto</span></a></li>

</ul>

<li>

<h2 id="sun"><a href="soarele.html">Soarele</a></h2>

<p>Soarele este steaua aflată în centrul sistemului nostru solar. Pământul, toate celelalte planete, asteroizii, meteoriții, cometele precum și cantitățile enorme de praf interplanetar orbitează în jurul Soarelui, care totuși, prin mărimea sa, conține mai mult de 99% din masa întregului sistem solar. Energia provenită de la Soare (sub forma luminii, căldurii ș.a.) face posibilă întreaga viață de pe Pământ, de ex. prin fotosinteză, iar prin intermediul căldurii și clima favorabilă.</p>

</li>

<li>

<h2 id="mercury"><a href="mercur.html">Mercur</a></h2>

<p>Mercur este planeta cea mai apropiată de Soare, înconjurându-l o dată la fiecare 88 zile. Luminozitatea sa variază între -2,0 și 5,5 în magnitudine aparentă, dar nu este ușor de văzut fiindcă cea mai mare separare angulară (cea mai mare elongație) față de Soare este de doar 28,3 °, însemnând că se poate vedea doar imediat după apusul Soarelui.</p>

</li>

<li>

<h2 id="venus"><a href="venus.html">Venus</a></h2>

<p>Venus este a doua planetă ca distanță față de Soare în sistemul nostru solar.Situată la 108 milioane km de Soare, Venus își parcurge orbita în 224,7 de zile. Rotația în jurul propriei sale axe este foarte lentă, durează 243 de zile și are loc de la vest la est, în sens invers față de rotația celorlalte planete.</p>

</li>

<li>

<h2 id="earth"><a href="pamantul.html">Pământul</a></h2>

<p>Planeta Pământ este a treia planetă după distanța față de Soare și a cincea ca mărime în sistemul solar. Când desemnează planeta (și nu solul), cuvântul se scrie cu majusculă. Terra face parte dintre planetele interioare ale sistemului solar (planetele aflate în interiorul centurii de asteroizi). Este cea mai mare planetă telurică din sistemul solar</p>

</li>

<li>

<h2 id="mars"><a href="marte.html">Marte</a></h2>

<p>Marte este, pornind dinspre Soare, a patra planetă a sistemului solar, a cărei denumirea provine de la Marte, zeul roman al războiului. Uneori mai este numită și „planeta roșie” datorită înfățișării sale văzută de pe Pământ. Culoarea roșiatică se explică prin prezența pe suprafața sa a oxidului de fier.</p>

</li>

<li>

<h2 id="jupiter"><a href="jupiter.html">Jupiter</a></h2>

<p>Jupiter este a cincea planetă de la Soare și este cea mai mare dintre toate planetele din Sistemul solar. Are diametrul de 11 ori mai mare decât cel al Pământului, o masă de 318 ori mai mare și un volum de 1300 ori mai mare.</p>

</li>

<li>

<h2 id="saturn"><a href="saturn.html">Saturn</a></h2>

<p>Saturn este a șasea planetă de la Soare și a doua ca mărime din Sistemul Solar, după Jupiter. Împreună cu Jupiter, Uranus și Neptun, Saturn este clasificat ca un gigant gazos. Aceste planete sunt numite corpuri joviane, însemnând planete asemănătoare cu Jupiter.</p>

</li>

<li>

<h2 id="uranus"><a href="uranus.html">Uranus</a></h2>

<p>Uranus este a șaptea planetă de la Soare și a treia că mărime (după diametru). Uranus este mai mare ca diametru însă mai mică sub aspectul masei decât Neptun. Plasat pe o orbită de 19 ori mai îndepărtată de Soare decât cea a Pământului, Uranus, ca și Neptun, primește foarte puțină căldură.</p>

</li>

<li>

<h2 id="neptune"><a href="neptun.html">Neptun</a></h2>

<p>Neptun este a opta și cea mai îndepărtată de Soare planetă din Sistemul solar. Numită după zeul roman al mării, este cea de a patra planetă după diametru și a treia după masă. Neptun are masa de 17 ori mai mare decât cea a Pământului și puțin mai mare decât a lui Uranus, care este de 15 ori mai greu decât Pământului, dar nu la fel de dens.</p>

</li>

<li>

<h2 id="pluto"><a href="pluto.html">Pluto</a></h2>

<p>Pluton (sau Pluto) este o planetă pitică din Sistemul Solar, a doua ca mărime după Eris. A fost descoperită în anul 1930 de către astronomul american Clyde William Tombaugh. Până în 2006 a fost considerată a noua planetă a Sistemului Solar, atât în ordinea distanței față de Soare, cât și a descoperirii.</p>

</li>

</ul>

</section>

</div>

</body>

</html>

3.4 Rezultate obtinute folosind tool-uri de testare si verificare

Folosind tool-ul HTML Validator de la adresa http://validator.w3.org/ s-au obtinut urmatoarele rezultate:

… (capturi imagine)

Bibliografie

M. Alalfi, J. Cordy, T. Dean, Modeling methods for web application verification and testing: State of the art, 2008 John Wiley & Sons, Ltd.

T. D. Cao, P. Felix, R. Castanet, I. Berrada, Testing Web Services Composition using TGSE Tool, 2009.

J. Conallen, “Modeling Web Application Arhitectures with UML”, Communications of the ACM, Vol. 42, No. 10, 1999

H. Gellersen and M Gaedke, “Object-Oriented Web Application Development”, IEEE Internet Computing, 1999

M. L. Gillenson, D.L. Sherrell, L. Chen, A Taxonomy of Web Site Transversal Patterns and Structures, C. A. I. S., vol. 3, 2000.

D.Kung, N.Suchak, J. Gao, P. Hsia, Y. Toyoshima and C. Chen, “On Object State Testing”, in Proceedings of Computer Software and Application Conference, 1994.

Kung, J. Gao, P. Hsia, J. Lin, and Y. Toyoshima, “Design Recovery for Software Testing of Object-Oriented Programs”, In Proceedings of the Working Conference on Reverse Engineering, Baltimore Maryland, 1993

C.H. Liu, D. C. Kung, P. Hsia, C.T.Hsu, Structural Testing of Web Applications, 11th International Symposium on Software Reliability Engineering, 2000

W3C Markup Validation Service: http://validator.w3.org

Alpine HTML Doctor: http://www.alpineinternet.com/.docs/pg/11133

Validome HTML/XHTML/WML/XML validator: http://www.validome.org/

CSE HTML Validator Lite: http://onlinewebcheck.com

NetMechanic: http://netmechanic.com/products/HTML_Toolbox_FreeSample.shtml

WDG HTML Validator: http://www.htmlhelp.com

Lithops Software HTML Link Validator: http://lithopssoft.com/hlv/

http://ro.wikipedia.org/wiki/Adobe_Dreamweaver

http://ro.wikipedia.org/wiki/Adobe_Flash

http://ro.wikipedia.org/wiki/Sistemul_solar

http://ro.wikipedia.org/wiki/Soare

http://www.infoastronomy.com/sistemsolar.html

Sistemul Solar

Aditya P. Mathur, Foundations of Software Testing, Addison-Wesley Professional, 1 edition (2008)

Tao He, Huaikou Miao, Modeling and Composition of Web Application Components using Extended, Fourth International Conference on Natural Computation,IEEE, pg. 363-368, 2008.

C. Courcoubetis, M. Vardi, P. Woper, M Yannakakis, Memory-efficient algorithms for the verification of temporal proprieties. Formal Methods in System Design. 2-3 Octomber 1992, pp. 275-288.