Testarea aplicatiilor web

Aplicatiile web s-au dezvoltat intr-o platforma de comunicare de baza pentru multe companii. Aplicatiile web sunt cruciale pentru comert, schimbul de informatii si pentru gazduirea activitatilor sociale. Din acest motiv, aplicatiile web trebuie sa ofere o inalta performanta, fiabilitate si o mare usurinta in folosire. Furnizarea unor aplicatii web de calitate pentru utilizatorii existenti si cei viitori reprezinta o provocare majora pentru asigurarea calitatii. Testarea este una dintre cele mai importante masuri de asigurare a calitatii. Metodele si tehnicile de testare traditionale se concentreaza in principal pe testarea cerintelor functionale. Din pacate, acestea nu se concentreaza suficient pe o cerintele de calitate importante pentru utilizatorii de aplicatii Web, cum ar fi performanta, usurinta in folosire, fiabilitatea si securitatea. O provocare majora in testarea aplicatiilor web este dominanta schimbarii. Cerintele utilizatorilor si asteptarile, platformele si configuratiile, modelele de afaceri, dezvoltarea si testarea bugetelor sunt subiecte supuse unor modificari frecvente pe tot parcursul ciclului de viata al aplicatiilor web. Prin urmare, este necesara dezvoltarea unui sistem eficient de testare care sa acopere o gama larga de caracteristici de calitate ale aplicatiilor web, care sa faca fata la schimbari si care sa ajute la implementarea si buna intelegere a unei testari sistematice, complete si lipsita de riscuri. O astfel de schema de test formeaza baza pentru construirea unei metode model si a instrumentelor aferente. Experienta practica a demonstrat ca testarea metodica si sistematica fundamentata pe o astfel de schema este realizabila si utila pe tot parcursul dezvoltarii si evolutiei aplicatiilor web.

Aplicatiile web sunt expuse unor noi provocari privind asigurarea calitatii si testarea. Aplicatiile web sunt compuse din diverse componente software oferite in anumite cazuri de anumiti producatori. Calitatea aplicatiilor web este in principal determinata de calitatea fiecarei componente software implicate si de calitatea legaturilor dintre acestea. Testarea este una din cele mai importante instrumente folosite in dezvoltarea aplicatiilor web pentru realizarea produselor de inalta calitate, care indeplinesc asteptarile utilizatorilor.

Testarea aplicatiilor web merge dincolo de testarea software-ului din sistemele traditionale. Desi se aplica cerinte similare la corectitudinea tehnica a unei aplicatii, utilizarea unei aplicatii Web de catre grupuri eterogene de utilizatori, pe un numar mare de platforme, duce la cerinte speciale de testare. Deseori este greu de anticipat numarul viitor de utilizatori pentru o aplicatie web. Timpul de raspuns este unul din factorii de succes decisivi pe Internet si trebuie sa fie avut in vedere din timp, chiar daca platforma hardware finala este, in general, disponibila mult mai tarziu. Alti factori importanti pentru succesul aplicatiilor web sunt usurinta in folosire, disponibilitatea, compatibilitatea browserelor, securitatea, actualitatea si eficienta.

1 Fundamentele testarii

2.1 Terminologie

Testarea este o activitate efectuata pentru a evalua calitatea unui produs si pentru a imbunatati-o prin identificarea problemelor si defectelor. Daca vom rula un program cu intentia de a gasi erori, atunci putem vorbi de testare. Figura 7-1 arata ca testarea este parte a masurilor de asigurare a calitatii analitice. Prin descoperirea erorilor existente este determinata calitatea programului testat, in vederea imbunatatirii calitatii, acest lucru realizandu-se de cele mai multe ori doar prin eliminarea erorilor gasite.

Putem spune ca o eroare este prezenta in cazul in care rezultatul actual dintr-un test nu este in conformitate cu rezultat asteptat. Rezultatul asteptat este specificat, de exemplu, in definirea cerintelor. Aceasta inseamna ca fiecare abatere de la definirea cerintelor este o eroare; in termeni mai generali, o eroare este 'diferenta intre valoarea sau conditia calculata, observata sau masurata si valoarea corecta sau conditia adevarata, specificata sau teoretic corecta' (standard IEEE 610.12-1990).

Aceasta definitie implica faptul ca definirea cerintelor utilizate ca baza pentru testare este terminata si disponibila inainte de implementare si testare. Un fenomen comun in dezvoltarea aplicatiilor web este ca cerintele sunt deseori incomplete, neclare si reprezinta subiectul unor schimbari frecvente. De obicei, exista o viziune initiala privind functionalitatea de baza, care este implementata in faza initiala de lansare. Ca urmare, dezvoltarea ciclului initial de viata este urmata de mici cicluri de functionalitati adaugate. Abordarile Agile (cum ar fi Extreme Programming) se concentreaza pe natura evolutiva si repetata a dezvoltarii ciclului de viata fara a apela la o definire extinsa a cerintelor. In consecinta, obiectivele, preocuparile si asteptarile partilor interesate (mandatari) trebuie sa constituie baza testarii. Aceasta inseamna ca, de exemplu, fiecare abatere de la valoarea asteptata in mod firesc de catre utilizatori este, de asemenea, considerata o eroare.

In acest moment, partile interesate au asteptari diferite, iar unele dintre acestea pot fi concurente si neclare. Din acest motiv, asteptarile partilor interesate nu vor fi un reper util pentru a decide daca un rezultat este eronat, cu exceptia cazului in care un set de asteptari au fost atinse si au fost puse la dispozitie in forma testabila. Pentru a sprijini testerii in a avea o perspectiva a utilizatorilor si de a intelege mai bine asteptarile utilizatorilor, acestia ar trebui sa fie implicati cat mai devreme posibil in identificarea si definirea cerintelor.

Cand discutam despre un test ne vom referi la un set de cazuri de testare pentru un anumit obiect testat (de exemplu, o aplicatie web, componentele unei aplicatii Web sau un sistem care ruleaza o aplicatie Web). Un singur caz de test descrie un set de intrari, conditiile de executie, precum si rezultatele asteptate, care sunt utilizate pentru a testa un anumit aspect al obiectului testat (standard IEEE 610.12-1990).

2.2 Caracteristici de calitate

Un utilizator nu asteapta doar ca o aplicatie sa se comporte intr-un anumit mod; de asemenea, se asteapta ca anumite functii sa fie disponibile 24 de ore pe zi si 7 zile pe saptamana (24x7). Mai mult, utilizatorii se asteapta ca aplicatia sa fie usor de utilizat, fiabila, rapida si compatibila cu alte sisteme si versiuni viitoare. Pe langa comportament, de o deosebita importanta este testarea aplicatiei prin prisma cerintelor de calitate (de exemplu, tipurile de caracteristici de calitate asteptate de catre utilizatori).

In contextul aplicatiilor web, trebuie avute in vedere diferite caracteristici de calitate. O taxonomie generala pentru caracteristicile de calitate ale produselor software este specificata in standardul ISO/IEC 9126-1. Acest standard mentioneaza sase categorii de caracteristici principale: functionalitate, fiabilitate, usurinta in folosire, eficienta, mentenanta si portabilitate si le divide in continuare in mai multe sub-caracteristici.

Cerintele de calitate joaca un rol esential in testarea aplicatiilor web. Chiar daca acestea sunt in general similare cu cerintele de calitate pentru sistemele software traditionale, ele ajung deseori dincolo de ele. Datorita importantei caracteristicilor de calitate si diferentelor privind modul in care pot fi testate, majoritatea metodelor de testare pentru aplicatiile Web se concentreaza pe una sau cateva caracteristici de calitate. Cu toate acestea, toate caracteristicile de calitate sunt importante pentru calitatea generala a unei aplicatii Web. Testarea trebuie sa se asigure ca acestea sunt implementate cu succes.

2.3 Obiectivele testarii

Testarea nu va duce la imbunatatirea calitatii cu exceptia cazului in care erorile sunt detectate si eliminate. Principalul obiectiv al testarii este de a gasi erori i nu de a arata absenta lor. Testele software sunt inadecvate pentru a dovedi absenta unor erori. Daca un test nu gase te erori, atunci acest lucru nu inseamna ca testat cererea nu contine nici un fel. Acestea, pur si simplu nu au fost inca detectate.

Numarul mare de caracteristici de calitate, toate valorile de intrare si combinatiile de intrare potentiale care trebuie luate in considerare, inclusiv toate conditiile si procesele potentiale, fac imposibila realizarea unei testari complete. Chiar si o paleta larga de teste este de obicei imposibila, datorita ciclurilor de dezvoltare extrem de scurte. Consecintele inevitabile sunt erorile in functiile testate si un risc mai mare in apari ia erorilor nedetectate. Acestea sunt motivele pentru care testarea tinde spre o abordare bazata pe risc. Aceste parti ale unei aplica ii in care erorile sunt nedetectate si in care au consecin e critice, ar trebui sa fie testate primele, acordanduli-se o aten ie sporita. Explorand sursele de risc putem semnala defectele mult mai direct decat pe fundamentarea testelor pe baza cerintelor. In consecinta, un obiectiv important al testarii este de a aduce riscul la lumina.

Un test rulat are succes daca sunt detectate erori i daca sunt ob inute informatii suplimentare despre problemele si starea aplica iei. Testele nereusite, cum ar fi, testele in care nu sunt gasite erori, sunt 'o pierdere de timp'. Acest lucru este valabil mai ales in dezvoltarea aplicatiilor web, in care testarea este in mod necesar limitata la un minim, datorita resurselor limitate si presiunii de timp extreme in care se dezvolta aplicatiile Web. Aceasta situatie necesita, de asemenea, descoperirea erorilor grave cat mai devreme posibil pentru a evita investitiile inutile cum ar fi costurile de gasire si eliminare a erorilor care cresc dramatic in fiecare etapa de dezvoltare. Erorile care au aparut in fazele timpurii de dezvoltare sunt greu de localizat in etapele ulterioare, si eliminarea lor cauzeaza, in mod normal, modificari ample si necesitatea de a rezolva erorile ulterioare. Prin urmare, testare trebuie inceputa cat mai devreme posibil, preferabil la inceputul unui proiect.

Pe scurt, putem spune ca ciclurile de testare, in general, si pentru proiectele Web in particular, trebuie sa detecteze cat mai multe erori posibile, in mod ideal cat mai multe erori grave, la cel mai mic cost posibil, intr-o perioada cat mai scurta de timp si cat mai devreme posibil.

2.4 Nivele de Test

In conformitate cu fazele de dezvoltare in care putem ob ine rezultate ale testarii, putem identifica anumite nivele de test pentru facilitarea testarii acestor rezultate.

. testarea unita ilor: testarea celor mai mici unitati testabile (clase, pagini web, etc), independent una de alta. Unitatea de testare este ob inuta de dezvoltator, pe parcursul implementarii.

. testele de integritate: evaluarea interactiunii intre unita ile testate distinct si separat dupa ce acestea au fost integrate. Testele de integritate sunt de obicei efectuate de catre un tester, un dezvoltator sau de ambii.

. testele sistem: testarea completa, integrata a sistemului. Teste sistem sunt, de obicei, efectuate de catre o echipa de test specializata.

. testele de acceptare: evalueaza sistemul in cooperare cu sau sub patronajul clientului intr-un mediu apropiat mediului de productie. Testele de acceptare utilizeza condi iii i date reale.

. testele beta: permit utilizatorilor sa lucreze cu versiunile timpurii ale unui produs cu scopul de a oferi feedback-ul din timp. Testele beta sunt informale (fara planuri de testare si cazuri de test) i se bazeaza pe numarul i creativitatea potentialilor utilizatori.

Pe masura ce dezvoltarea progreseaza, cineva va realiza o verificare vizavi de specificatiile tehnice (daca este cazul) - la fel ca in testarea unita ilor, testarea integrita ii si testarea sistemului - la o validare a asteptarilor utilizatorilor - la fel ca in testele de acceptare si testele beta.

Un risc inerent care apare atunci cand se efectueaza testele secvential in acord cu fazele proiectului este ca pot apare erori datorita neintelegerii asteptarilor utilizatorilor (care pot fi gasite numai intr-un stadiu tarziu), ceea ce conduce la costuri mari de eliminare a acestora. Pentru a minimiza acest risc, testarea trebuie sa fie parte integranta a construirii produsului si ar trebui sa cuprinda intregul proces de dezvoltare. Prin urmare, masurile de asigurare a calitatii cum sunt recenziile sau prototipizarea sunt utilizate deseori inainte de a rula testarea unitatilor. Un proces de dezvoltare iterativ si evolutiv reduce acest risc deoarece partile mai mici ale sistemului sunt testate frecvent pe toate nivelurile de test (inclusiv cele cu validare pentru asteptarile utilizatorilor), astfel incat erorile pot fi depistate inainte de a putea avea un impact asupra altor parti ale sistemului. Aceasta inseamna ca secventa nivelurilor de test descrise mai sus nu sunt in permanenta dictate de succesiune temporala a testarii proiectul web, dar pot fi efectuate de mai multe ori (de exemplu, o data pentru fiecare dezvoltare a functionalitatii).

2.5 Rolul tester-ului

Pentru a gasi cat mai multe erori posibile testerii trebuie sa aiba o atitudine 'distructiva' fata de testare. O astfel de atitudine este dificila pentru un dezvoltator care lucreaza la un modul software. Aceeasi perspectiva de abordare face deseori ca dezvoltatorii sa realizeze aceleasi greseli si neintelegeri pe perioada de testare, greseli care au condus la erori pe perioada implementarii. Din acest motiv, (Myers 1979) sugereaza ca dezvoltatorii sa nu testeze propriile produse.

In proiectele web, se observa o focalizare sporita pe testarea unitatilor care sunt scrise de dezvoltatori. Desi acest lucru este o incalcare a sugestiilor lui Myers, testele suplimentare sunt, de obicei, efectuate de persoane diferite de dezvoltatorul original (de exemplu, de catre testerii recrutati de departamentul de afaceri al clientului).

Deoarece calitatea este intotdeauna o problema de echipa, o separare stricta a testarii si dezvoltarii nu este recomandabila si prezinta un risc inerent in impiedicarea cooperarii intre programatori si testeri. In esenta, obiectivul urmarit este de a detecta erori, erori care vor fi eliminate de catre dezvoltatori. In acest scop, se recomanda o comunicare si o intelegere reciproca. Acest lucru inseamna pentru tester: 'Cel mai bun tester nu este cel care gaseste cele mai multe bug-uri sau care stanjeneste majoritatea programatorilor. Cel mai bun tester este cel care depisteaza cele mai multe bug-uri fixe. '.

Deoarece echipele de proiect web sunt multidisciplinare si cooperarea in echipa este, de obicei, de scurta durata, este dificil pentru membrii echipei sa stabileasca un nivel superior de incredere, necesara pentru o colaborare stransa intre dezvoltatori si testeri.

3 Teste specifice ingineriei web

Elementele de baza prezentate anterior se aplica atat la testarea software-ului traditional cat si in aplicatiile web. Testarea aplicatiilor web este diferita de testarea produselor software traditionale, lucru datorat caracteristicilor specifice aplicatiilor web:

. erorile din 'continut' pot fi deseori gasite doar prin masuri costisitoare sau organizationale (de exemplu, prin corectarea greselilor). Formularele simple de verificare automata (de exemplu, un corector ortografic) sunt foarte valoroase, dar sunt limitate la o paleta redusa de depistare a potentialelor defecte. Meta-informatiile despre structurarea si semantica continutului sau despre un sistem de referinta care furnizeaza valori comparative, sunt deseori o conditie prealabila pentru a putea efectua testele de profunzime. Daca aceste premise nu sunt disponibile, trebuie gasite alte abordari. De exemplu, daca apar schimbari frecvente privind modificarea datelor legate de cantitatea de zapada dintr-un sistem de informare turistica, acestea nu pot fi testate cu acuratete prin intermediul meta-informatiilor sau valorilor comparative, si, in consecinta, valabilitate datelor poate fi restrictionata euristic la doua zile pentru a se asigura actualitatea datelor.

. cand testam structura hipertext, trebuie sa ne asiguram ca paginile sunt legate in mod corect (de exemplu, fiecare pagina trebuie sa fie accesibile printr-o legatura si, la randul sau, ar trebui sa aiba o legatura inapoi la structura hipertext). In plus, toate legaturile trebuie sa duca la pagini existente, adica, nu trebuie sa fie "intrerupte". Legaturile nefunctionale sunt erori frecvente atunci cand legaturile statice predefinite devin invalide (de exemplu, atunci cand se face referire la o pagina web externa, care a fost eliminata sau s-a schimbat structura acesteia). O alta sursa de erori este navigarea prin intermediul functiilor browser-ului web (de exemplu, 'Inapoi in Istoric', in asociere cu starile in care o aplicatie web poate fi). Un exemplu tipic intalnit este: daca un utilizator adauga un articol in cosul de cumparaturi virtual in timp ce realizeaza cumparaturi online, atunci acest articol va ramane in cosul de cumparaturi, chiar daca utilizatorul se duce cu un pas inapoi in istoricul browser-ului, afisand pagina anterioara fara acel articol.

. cerintele soft, subiective de pe nivelul prezentare al aplicatiilor web (de exemplu, 'estetica'), sunt dificil de specificat. Cu toate acestea, ele sunt este o conditie prealabila esentiala pentru tester pentru a putea distinge in mod clar si obiectiv comportamentul acceptabil (si de dorit) la defectele de comportament. Mai mult, doar cateva metode si tehnici traditionale pentru testarea software-ul sunt adecvate pentru testarea prezentarii. Pentru a testa o prezentare, trebuie sa fie utilizate metode din alte discipline (de exemplu, publicistica tiparita si masurile organizationale), in aceeasi masura cu asigurarea calitatii continutului.

. numarul mare de dispozitive si caracteristicile lor diferite de performanta (distribuirea multi-platforma) reprezinta o alta provocare. Chiar daca un tester dispune de toate dispozitivele posibile, acesta ar trebui sa ruleze cazurile de test pentru fiecare dispozitiv. Desi simulatoarele pentru dispozitive pot fi de ajutor daca tester-ul nu dispune de dispozitivul fizic, ele insele prezinta in majoritatea cazurilor defecte.

. datorita disponibilitatii si utilizarii globale ale aplicatiilor web, exista o serie de provocari in ceea ce priveste multi-lingvismul si usurinta in folosire in testarea aplicatiilor web. Provocarea principala este de a recunoaste interdependentele culturale si le ia in considerare in mod adecvat de test. De exemplu, ordinea de citire in diferite culturi (de exemplu: araba, chineza) implica folosirea de ajutoare de navigare laterale in fereastra browser-ului. O alta dificultate provine din lungimea diferita a mesajelor de tip text in limbi diferite, care poate determina probleme in afisarea layout-ului.

. 'tineretea' si 'multi-disciplinaritatea' echipelor sunt adesea legate de slaba acceptare a metodologiilor si de nepromptitudinea in efectuarea testarii. Deseori, trebuie acumulate pe parcurs cunostinte despre metodele, tehnologiile si instrumentele necesare pentru realizarea testarii. De asemenea sunt necesare puncte de vedere diferite cu privire la testare. Numai o echipa formata din membri cu experienta vor ajunge la o decizie corecta despre volumul testarii - prea multa testare poate fi la fel de neproductiva ca cea insuficienta. Testerii sunt deseori tentati sa testeze tot in intregime, mai ales la inceput.

. aplica iile web constau dintr-un numar de diferite componente software (de exemplu: servere web, baze de date, middleware) si sisteme integrate (de exemplu: sisteme ERP, sisteme de management al continutului), care sunt oferite de diferi i furnizori, si implementate cu ajutorul unor tehnologii. Aceste componente formeaza infrastructura tehnica a aplicatiilor Web. Calitatea unei aplicatii Web este in principal determinata de calitatea tuturor componentelor software singulare si de calitatea interfetei dintre ele. Aceasta inseamna ca, pe langa componentele dezvoltate intr-un proiect, va trebui sa testam componentele software furnizate de parti terte, dar si integrarea si configurarea acestor componente. Multe erori in aplicatiile web rezulta din 'imaturitatea' unei componente software, 'incompatibilitatea' intre componentele software, sau defecte de configurare a componentelor software corecte.

. 'imaturitatea' majorita ii metodelor i instrumentelor de testare reprezinta provocari suplimentare pentru testeri. Daca o aplicatie Web este implementata cu o tehnologie noua, de cele mai multe ori nu exista inca metode si instrumente de testare adecvate. Daca instrumentele de testare devin disponibile, multe dintre ele sunt imature, prezinta defecte si dificil de utilizat.

. 'dominanta schimbarii' face ca testarea aplicatiilor web sa fie mai complexa decat testarea software-ului traditional. Cerintele si asteptarile utilizatorilor, platformele, sistemele de operare, tehnologiile si configuratiile Internet, modelele de afaceri si de asteptarile clientilor, dezvoltarea si testarea bugetelor sunt subiectul unor frecvente modificari pe tot parcursul ciclului de viata al unei aplicatii Web. Adaptarea la cerintele noi sau modificate este dificila pentru ca functionalitatea existenta trebuie sa fie reanalizata, ori de cate ori se face o schimbare. Aceasta inseamna ca un singur fragment de functionalitate trebuie sa fie testat de mai multe ori, in ideea realizarii unor teste automate si repeatable. Acestea pun accentul in special pe teste de regresie, care verifica daca ceea ce s-a lucrat functioneza dupa o anumita schimbare. Upgrade-urile si migrarea aplicatiilor web, determinate de schimbarile permanente ale platformelor, sistemelor de operare sau hardware-ului, trebuie sa ruleze si sa dovedeasca ca sunt un succes in mediul de test, pentru a ne asigura ca nu vor fi probleme neasteptate in mediul de productie. 

4 Abordari privind testarea

Abordarile Agile (cum ar fi Extreme Programming) sunt din ce in ce mai folosite in proiectele web. In timp ce abordarile Agile se concentreaza pe colaborare, abordarile traditionale se focalizeaza pe planificarea si managementul proiectului. In functie de caracteristicile unui proiect web, poate fi necesara realizarea activitatilor de testare folosind atat abordarile Agile cat si cele traditionale pe parcursul proiectului. (Boehm si Turner 2003) descriu pe larg modul de a gasi a un echilibru corect intre agilitate si disciplina in proiecte. In continuarea, vom prezenta caracteristicile abordarilor de testare traditionale si Agile, si vom evidentia modul in care acestea difera.

4.1 Abordarile traditionale

Din perspectiva unei abordari traditionale, activitatile de testare dintr-un proiect includ planificarea, pregatirea, executarea si raportarea:

. Planificarea: pasii planificarii definesc obiectivele de calitate, strategia generala de testare, planurile de test pentru toate nivelurile de test, metodele metrice si de masurare si testarea mediului.

. Pregatirea: Acest pas implica selectarea tehnicilor si instrumentelor de testare si specificarea cazurilor de test (inclusiv datele de test).

. Executarea: Acest pas pregateste infrastructura de test, executa cazurile de test si in final documenteaza si evalueaza rezultatele.

. Raportarea: Acest pas final rezuma rezultatele testelor si genereaza rapoartele testarii.

Abordarile traditionale definesc rezultatele muncii (de exemplu, planul de calitate, strategia de testare, planurile de test, cazurile de test, masuratorile testarii, mediul de testare, rapoartele de testare) si rolurile (de exemplu, managerul testarii, consultantul testarii, specialistul testarii, specialistul instrumentelor de testare), precum si pasii detaliati pentru a crea rezultatele (de exemplu, analiza datelor de test disponibile sau pregatirea/furnizarea datelor de test). Abordarile Agile, definesc obiectivul de calitate si apoi se bazeaza pe echipa sa se auto-organizeze si sa creeze un software care indeplineste (sau depaseste) obiectivul de calitate.

Datorita ciclurilor scurte de a ajunge pe piata in care se dezvolta aplicatiile Web, este necesar sa selectam doar cele mai importante rezultate ale muncii, rolurile cheie si sa eliminam pasii de lucru inutili. Activitatile de testare trebuie sa fie incepute cat mai devreme posibil pentru a scurta perioada distribuirii. De exemplu, activitatile de planificare si de proiectare pot fi finalizate inainte de inceperea dezvoltarii, iar rezultatele muncii pot fi verificate static, de indata ce acestea devin disponibile. Figura 7-2 demonstreaza ca acest lucru va scurta perioada de livrare, care respecta astfel ciclurile scurte de dezvoltare ale aplicatiilor web.

Abordarile Agile presupun ca o echipa va gasi solutii la probleme, in comun si in mod autonom (se bazeaza pe auto-organizare). Acest lucru se aplica, de asemenea, la teste. Prin urmare, testarea nu este o chestiune de roluri ci de o mai mai buna colaborare si utilizare a aptitudinilor disponibile in echipa. Aceasta inseamna ca testarea este o activitate de dezvoltare integrata. Intreaga echipa este responsabila pentru calitate si pentru testare.

Abordarile Agile omit activitatile care nu par sa promita un beneficiu imediat. De exemplu, ele documenteaza anumite aspecte sau scriu planuri de test; in schimb, ele comunica direct, exprimand in mod clar asteptarile. Membrii echipei trebuie sa coopereze strans si sa se 'inteleaga' reciproc pentru a se asigura ca erorile sunt depistate si analizate rapid, eliminate in mod eficient.

Intr-o abordare Agile, dezvoltatorii efectueaza testarea unita ilor, adica ei i i testeaza propria munca. Prin automatizarea acestor teste ale unita ilor, acestea pot fi folosite ca mici 'detectoare ale schimbarii'. De fiecare data cand o mica por iune din aplica ie nu mai functioneaza adecvat, schimbarea va fi detectata imediat. Intarzierea intre apari ia unei erori si detectarea acesteia este redusa in mod semnificativ, ceea ce face mai usor pentru dezvoltatori sa corecteze eroarea, deoarece activitatile sau modificarile recente sunt inca proaspete in mintea lor. Pe langa feedback-ul rapid, testele automatizate sunt o cerinta prealabila importanta pentru ciclurile scurte de dezvoltare si pentru refactoring (reproiectarea unui program pastrandu-se semanticile pentru reducerea redundan ei si cresterea calita ii proiectarii).

Intr-o echipa poate exista un tester dedicat, acceptat de echipa de dezvoltatori care isi asuma calitatea de conducator pentru asigurarea calita ii, in cadrul echipei. De asemenea, un tester poate pregati teste functionale (care sunt pe un nivel mai mare de abstractizare decat testea unita ilor dezvoltatorilor) si face scripturile de test tolerante la modificari. In plus, tester-ul poate sprijini clientul cu teste functionale scrise.

Urmatoarele practici de Extreme Programming (XP) au o influenta speciala asupra asigurarii testarii si calitatii:

. programarea in pereche: accelereaza schimbul de cunostinte intre dezvoltatori, intre dezvoltatori si testeri si, in general, in cadrul echipei. Similar cu inspectarea software-ului, ajuta la detectarea din timp a erorilor.

. un client de pe site: este disponibil pentru intrebari privitoare la cerinte, in orice moment si ia decizii in acest sens. Impreuna cu tester-ul, clientul de pe site pregateste pentru testele functionale, care pot fi folosite pentru testele de acceptare ulterior.

. integrarea continua: ne asigura ca ace ti mici pasi contribuie la minimizarea riscului la modificari, si parcurge toate testele pentru o verificare continua a faptului ca intregul sistem este infailibil.

. testarea inainte de dezvoltare: se refera la faptul ca testele sunt scrise inainte de cod, asigurandu-se ca 'dezvoltatorii', se gandesc la 'ce' inainte de a implamenta 'cum'. Aceste teste sunt automatizate, astfel incat acestea sa poata fi folosite pentru o integrare continua.

Abordarea Agile se refera in principal la testarea unita ilor si la testele de acceptare. In contrast, abordarile conventionale sunt folosite pentru integrarea i testarea sistemului ('testarea in ansamblu').

5 Schema de testare

In continuare vom prezenta o schema generica pentru testarea aplicatiilor Web. Schema reuneste testele de baza - cazurile de test, caracteristicile de calitate, si nivelurile de test - descrise anterior intr-un mod uniform si usor de administrat. Schema reprezinta un model pentru testarea aplicatiilor Web proiectat pentru a intelege mai bine cum poate fi organizata testarea pentru a sprijini o abordare sistematica, cuprinzatoare, si lipsita de riscuri a testarii. In forma prezentata, schema poate fi folosita pentru a vizualiza aspectele implicate in testare, structura toate testele, si reprezinta un liant de comunicare pentru echipa.

5.1 Testatea pe trei dimensiuni

Fiecare test are un scop definit (de exemplu, verificarea corectitudinii unui algoritm, pentru a dezvalui incalcarea securitatii dintr-o tranzactie sau pentru a gasi incompatibilitati privitoare la stilul dintr-o reprezentare grafica). Obiectivele sunt descrise pe de o parte de caracteristicile de calitate cerute (de exemplu, corectitudine, securitate, compatibilitate) si de obiectele testarii, pe de alta parte (de exemplu, algoritmi, tranzactii, reprezentari). Astfel, caracteristicile de calitate si obiectele testarii sunt in mod reciproc ortogonale. Ele pot fi vazute pe doua dimensiuni separate, in care prima dimensiune se concentreaza pe caracteristicile de calitate relevante pentru sistemul testat, iar cel de-al doilea mod (ortogonal) pune accentul pe caracteristicile sistemului testat. Acest punct de vedere implica faptul ca obiectele sunt executate si analizate in timpul derularii testului, in timp ce caracteristicile de calitate determina obiectivele testarii. Ambele dimensiuni sunt necesare pentru a specifica un test si poate fi folosit pentru a organiza un set de teste aflate in legatura.

Pentru o abordare sistematica a testarii este util sa se faca o distinctie intre aceste doua dimensiuni astfel incat sa fie posibila identificarea tuturor obiectelor de test care afecteaza o anumita caracteristica de calitate, sau, invers, toate caracteristicile de calitate care afecteaza un anumit obiect al testarii. Acest lucru este foarte important, deoarece caracteristicile de calitate nu sunt la fel de relevante pentru toate obiectele de test. De exemplu, un utilizator al unui magazin online ar trebui sa fie liber vizualizeze si sa rasfoiasca oferta de produse, fara a fi deranjat de elemente de securitate, cum ar fi de autentificarea sau criptarea, cu exceptia cazului in care are de gand sa achizitioneze un articol. Prin urmare, in timp ce caracteristica de calitate 'securitate' joaca un rol de subordonat pentru functionalitatea de navigare in magazin, ea este de o importanta majora pentru tranzactiile de plata. Facand distinctie intre aceste doua dimensiuni ne putem permite sa precizam un criteriu de relevanta pentru diferite caracteristici de calitate ale fiecarui obiect unic testat.

In plus, a treia dimensiune specifica cand sau in ce faza a ciclului de viata al software-ului, o combinatie de obiecte testate si caracteristici de calitate ar trebui sa fie testate. Aceasta dimensiune este necesara pentru a descrie perioadele de timp in care activitatile de testare au loc: de la inceputul fazelor timpurii cum ar fi definirea cerintelor din faza de proiectare, implementare si instalare pana la exploatare si intretinere. Ca rezultat, testarea poate profita din sinergii valoroase, atunci cand luam in considerare activitatile din intregul ciclu de viata, de exemplu, prin proiectarea testarii sitemului care pot fi refolosite de testarea regresiei sau pentru monitorizarea sistemului. Mai mult, dimensiunea timp ne ajuta sa stabilim o vedere de ansamblu a testarii in toate fazele de testare si ne permite o mai buna intelegere a efectelor caracteristicilor de calitate si obiecte testate in timp. Este mai usor sa se justifice investitiile in fazele de testare timpurii, fata de cele din fazele tarzii.

Daca vom alatura aceste trei dimensiuni - caracteristicile de calitate, obiectele testarii, si fazele - , rezultatele pot fi vizualizate ca un cub tri-dimensional, asa cum este aratat in Figura 7-3. Cubul contine toate testele vazute sub forma de noduri, la intersectia unei anumite caracteristici de calitate, obiect al testarii, si faze. Figura indica o posibila structurare pentru cele trei dimensiuni, pentru testarea aplicatiilor web.

5.2 Aplicarea schemei de testare aplicatiilor web

Aceasta sectiune descrie modul in care dimensiunile unei scheme generice discutata anterior poate fi structurata pentru a se potrivi caracteristicilor speciale ale aplicatiilor web si proiectelor web. In practica, structurarea depinde de cerintele sistemului testat. Prin urmare, este necesara o personalizare si o detaliere a schemei generice in functie de situatia specifica a proiectului.

Caracteristicile de calitate

Dimensiunea caracteristicilor de calitate este determinata de caracteristicile de calitate care sunt relevante pentru aplicatiile web aflate in testare. Astfel, caracteristicile de calitate relevante pentru testare provin din obiectivele si asteptarile partilor interesate (stakeholders - imputernicitilor) si trebuie descrise drept cerinte non-functionale in definirea cerintelor. Trebuie luate in considerare si informatiile suplimentare provenite din alte masuri de asigurare a calitatii si din experienta de testare (de exemplu, factori tipici de risc, exploit-uri frecvente), atunci cand este definita dimensiunea caracteristicilor de calitate pentru o anumita aplicatie web.

Pentru o clasificare generica este indicata utilizarea caracteristicilor de calitate propuse de standardul ISO/IEC 9126-1, respectiv, un subset reprezentativ, cum ar fi functionalitatea, fiabilitatea, usurinta in folosire si eficienta. O alta descompunere rezulta din ierarhia de caracteristici si sub-caracteristici specificate in standard.

Obiectele testarii

Testarea traditionala a software-ului descrie dimensiunea obiectelor de test, in principal prin functii ale sistemului aflat in testare, specificate sub forma cerintelor functionale.

Spre deosebire de sistemele software traditionale, care se axeaza in principal pe cerintele functionale, aplicatiile web ofera, de asemenea, continut, care, deseori trebuie sa fie dezvoltat si testat ca parte a unui proiect web. In aplicatiile web axate pe documente, continutul este la fel de important pentru utilizatorii lor cat este si functionalitatea. Pentru testare, aceasta se traduce in cerinta de a detecta erori in continut, in structura hipertext si in cea de prezentare.

Chiar daca o aplicatie web indeplineste sau nu asteptarile utilizatorilor, in lumea reala acest lucru depinde, de asemenea, de infrastructura si mediul aplicatiei web. Aceasta include, de exemplu, configurarea serverului web, conexiunea la retea, companiile partenere integrate si fluxurile asociate. Utilizatorii se confrunta cu intregul sistem. Din perspectiva utilizatorilor, nu conteaza daca o aplicatie web nu satisface cerintele lor datorita unei erori de programare sau din cauza configurarii gresite a serverului web. Din acest motiv, este necesara extinderea testarii catre infrastructura si mediul aplicatiei web.

Dimensiunea generica a obiectelor testarii ar trebui, prin urmare, sa includa continutul, structura, infrastructura si mediul unei aplicatii Web.

Fazele

Cea de-a treia dimensiune a schemei - fazele - se concentreaza pe secven a temporala a aplicatiilor web testate. Aceasta dimensiune arata cand trebuie rulat un test in cadrul ciclului de viata al unei aplicatii web. Acesta a treia dimensiune este structurata in conformitate cu un proces general de dezvoltare sau un ciclu de viata al software-ului. Fazele procesului de dezvoltare pot diferi de la un proiect web la altul, in functie de modelul procesului selectat. Ca regula generala, se disting urmatoarele etape: definirea cerintelor, proiectarea si implementarea, acceptarea si instalarea, si exploatarea si intretinerea.

Includerea tuturor etapelor din intregul ciclu de viata denota faptul ca testarea unei aplicatii web nu se incheie atunci cand un proiect este finalizat. De exemplu, monitorizarea se repeta ca o parte a testarii in mod regulat, in cazul operatiilor normale, pentru a gasi erori noi sau existente, dupa ce au fost facute schimbari in cadrul infrastructurii sau mediului de lucru. Exemple tipice pentru astfel de modificari sunt actualizarile serverului Web sau noi versiuni ale browser-ului web. De exemplu, trebuie sa rulam periodic teste de compatibilitate pentru a ne asigura ca utilizatorii pot accesa o aplicatie web cu orice browser web, imediat ce o noua versiune devine disponibila, cu toate ca nu au fost efectuate modificari ale aplicatiei web.

5.3 Exemple de utilizare a schemei de testare

Pentru a aborda cele trei dimensiuni ale cubului prezentat anterior, vom folosi matrici bidimensionale care reprezinta felii (bucati) sau proiectii pentru eliminarea unuia din cele trei dimensiuni. Un exemplu este Tabelul 7-1, care prezinta cele doua dimensiuni ale obiectelor testarii si caracteristicilor de calitate. O astfel de schema este utilizata pentru o privire de ansamblu si ca un cadru conceptual pentru organizarea sistematica a metodelor si tehnicilor aplicabile testarii aplicatiilor web. Matricea poate fi folosita pentru a stabili un proiect specific sau o metoda la nivel de companie si ca un instrument de testare pentru aplicatiile Web.

Un alt exemplu este prezentat in (Ramler et al. 2002), care demonstreaza aplicarea schemei in managementul bazat pe risc al testarii pentru a privilegia testele pentru o aplicatie web. Prioritatile de testare au fost definite cu ajutorul testerilor, dezvoltatorilor, utilizatorilor, si expertilor in domeniu, pe baza prioritatilor cazurilor de utilizare (obiectelor testate) si cerintelor non-functionale (caracteristicile de calitate). Aceasta abordare faciliteaza planificarea testarii, estimarea activitatilor de testare si permite urmarirea prioritatilor pentru fiecare test in functie de cerintele prioritare.

6 Metode si tehnici de testare

Cand testam aplicatiile web, putem aplica toate metodele si tehnicile folosite frecvent in testarea software-ului traditional. Pentru tine cont de specificul aplicatiilor web, unele din aceste metode si tehnici de testare vor trebui analizate sau adaptate si extinse (de exemplu, 'Ce factori de influenta vor fi luati in considerare atunci cand testam compatibilitatea cu diferite browsere Web?'). In plus, cel mai probabil vom avea nevoie noi metode si tehnici de testare pentru a acoperi toate caracteristicile care nu au nici o corespondenta in testarea software-ului traditional (de exemplu, testarea structurii hipertext).

Rezumatul prezentat in Tabelul 7-1 corespunde schemei de test prezentate in sectiunea 5 si este alcatuit din dimensiunea obiectelor testarii si din dimensiunea caracteristicilor de calitate. Tabelul ofera o privire de ansamblu asupra metodelor, tehnicilor, si claselor de instrumente pentru testarea aplicatiilor web. Tabelul arata tehnicile si metodele de testare reprezentative, ele servind drept baza de referinta pentru metodele si utilitarele specifice unui proiect.

Tabelul 7-1 Metode, tehnici, si clase de instrumente pentru testarea aplicatiilor web

In continuare vom descrie pe scurt metodele si tehnicile reprezentative pentru testarea aplicatiilor web.

6.1 Testarea legaturilor

Legaturile dintr-o structura de navigare hipertext care trimit la un nod non-existent (pagini, imagini, etc) sau ancora sunt numite legaturi moarte si reprezinta erori bine-cunoscute si frecvente in aplicatiile web. Pentru a testa corectitudinea legaturilor paginilor (verificarea legaturilor), toate legaturile sunt urmate in mod sistematic incepand cu pagina de start, si apoi grupate intr-un grafic de legaturi (harta site-ului).

Cand lansam o rutina de verificare a legaturilor, vom gasi nu numai legaturile care duc la paginile non-existente, dar si paginile care nu legate cu celelalte sau asa-numitele pagini orfane. Paginile orfane pot fi atinse printr-o legatura, dar nu au o legatura inapoi catre structura hipertext. Pentru utilizatorii ocazionali, nu este evident unde sa navigheze in continuare, astfel abandonand site-ul web. Ideal ar fi ca paginile sa fie proiectate astfel incat sa se termine cu o sugestie privitoare la locul in care cititorul ar putea merge in continuare.

In plus, atunci cand parcurgem legaturile, cineva poate gasi date suplimentare care sa ofere indicatii privind erorile potentiale (de exemplu, adancimea si latimea structurii de navigare, distanta intre doua pagini legate, masurata prin numarul de legaturi, sau timpul de incarcare a paginilor).

6.2 Testarea in browser

Un numar mare de browsere web pot fi folosite drept client pentru aplica iile web. In functie de producator (de exemplu, Microsoft, Mozilla, Netscape, Opera), sau de versiune (de exemplu, Internet Explorer 5.0, 5.01, 5.5, 6.0), sau de sistemul de operare (de exemplu, Internet Explorer pentru Windows XP/2000, Windows 98/ME/NT sau Macintosh), sau de echipamentul hardware (de exemplu, rezolutia ecranului si adancimea de culoare), sau de configurare (de exemplu, activarea cookie-urilor, limbajul de scripting, foi de stiluri), fiecare browser web are un comportament diferit. Standardele specificate de catre W3C nu sunt puse in aplicare in totalitate si sunt 'consolidate' de catre specifica iile incompatibile ale distribuitorilor. Statistici privind browserele web sunt disponibile online la adresa https://www.webreference.com/stats/browser.html.

Testarea din browser incearca sa descopere erorile din aplicatiile web cauzate de incompatibilitati intre diferite browsere web. In acest scop, una defineste in mod normal functiile de baza ale unei aplicatii web, proiectarea adecvata a cazurilor de test, si execu ia de teste pe sisteme tinta diferite, cu diferite versiuni de browser. In timpul acestor teste, trebuie sa inem cont de urmatoarele intrebari:

. Aplicatiile web sunt gestionate corect, sau apar situa ii nea teptate cand navigam direct la o pagina, de exemplu, prin utilizarea butonul 'Inapoi' din browser?

. Poate o (generata dinamic) pagina web fi re inuta ca un semn de carte in timpul unei tranzactii, si utilizatorii pot naviga la pagina respectiva mai tarziu, fara a nevoi i sa introduca un nume de utilizator si o parola pentru a se autentifica?

. Pot folosi utilizatorii web o aplica ie deschisa in mai multe ferestre de browser (una sau mai multe instante ale browser-ului web) concomitent?

. Cum reactioneaza aplica iile web atunci cand a browser-ul are dezactivate cookie-urile sau limbajele de script?

Pentru a limita numarul de combinatii posibile de browsere, platforme, setari, si al i factori de influenta folosi i pentru a gestiona un set de cazuri de test, trebuie analizate configuratiile existente sau potentiale de utilizatori; de exemplu, prin evaluarea fisierelor jurnal (log-urilor) si consultarea statisticilor browser-ului, pentru a gasi cele mai populare combinatii.

6.3 Testarea usurintei in folosire

Testarea usurintei in folosire evalueaza probleme de usurinta in folosirea diferitelor proiectari ale siturilor web, layout-ul general, si posibilitati de navigare (vezi capitolul 11) a unei aplicatii web de catre un set reprezentantiv de utilizatori. Accentul se va pune pe aspect si pe u urin a in folosire. Un test formal de u urin a in folosire este, de obicei, efectuat intr-un laborator, utilizand camere de lucru echipate cu un singur geam de sticla, camere video si o statie de inregistrare. Sunt colectate atat date cantitative cat i calitative.

Al doilea tip de evaluare a usurintei in folosire este recenzia euristica. O recenzie euristica implica folosirea uneia sau mai multor interfete, aplicarea unui set de linii directoare pentru a masura usurinta in folosire a solutiei propuse, identificarea domeniilor de remediat, si oferirea de recomandari pentru schimbarea design-ului. Aceasta evaluare sistematica implica urmarea unor principii de usurinta in folosire care ar trebui sa fie urmate de toti proiectantii interfetei cu utilizatorul. Dintre acestea mentionam: prevenirea erorilor si furnizarea de feedback si consistenta.

In contextul testarii usurintei in folosire, trebuie luata in considerare problema de a face aplicatiile web accesibile utilizatorilor cu handicap. Accesibilitatea inseamna ca persoanele cu incapacitati (vizuale, auditive, sau cognitive) pot percepe, intelege, navigheze si sa interactioneze cu aplicatiile web. Web Accessibility Initiative (WAI) apartine de W3C si a dezvoltat abordari pentru evaluarea site-urilor web din punct de vedere al accesibilitatii, care aspect relevant pentru testarea aplicatiilor web. Pe langa liniile directoare de evaluare, W3C ofera un serviciu de validare (https://validator.w3.org/) utilizat in asociere cu manualul de referinta si testarea de catre utilizator a caracteristicilor de accesibilitate.

Testarea in conditii de incarcare, solicitari si continua

Testele la incarcare, testele la solicitari si testarea continua se bazeaza pe proceduri similare. Cereri multiple sunt trimise concomitent aplica iei web testate, prin simularea timpilor de raspuns si cantita ii de date trimisa de utilizatori. Cererile utilizate in aceste teste sunt generate de catre unul sau mai multe 'generatoare de incarcare'. O aplicatie de control distribuie script-urile de test generatoarelor de incarcare; de asemenea, sincronizeaza rularea testului i colecteaza rezultatele testului.

Cu toate acestea, testele in condi ii de incarcare, testele la solicitari si testarea continua au obiective diferite:

. testarea in condi ii de incarcare verifica daca un sistem este conform timpilor de raspuns necesari si volumului de date solicitat. In acest scop, vom determina profilul de incarcare (tipurile de acces, vizitele pe zi, orele de varf, vizitele pe sesiune, tranzac iile pe sesiune, etc) si tranzactiile mixate (ce functii ar trebui sa fie executate i cu ce procent). Apoi, vom determina valorile tinta pentru timpii de raspuns si volumul de date (in cazul functionarii normale si la orele de varf, pentru o accesare normala sau complexa, cu valori minime, maxime si medii). Ulterior, vom rula testele, generand volumul de incarcare impreuna cu tranzactiile mixate definite in profilul de incarcare si vom masura timpii de raspuns si volumul de date. Rezultatele sunt evaluate si potentialul blocaj este identificat.

. testarea in conditii de solicitare verifica daca un sistem reactioneaza intr-un mod controlat, in 'situatii de stres'. Situatiile de solicitare sunt simulate prin aplicarea unor conditii extreme, cum ar fi supraincarcarea nerealista sau o fluctuatie mare la incarcare. Scopul testului este de a afla daca un sistem ajunge la timpii de raspuns si volumul de date necesar in cazul unei solicitari de moment si daca acesta raspunde adecvat, prin generarea un mesaj de eroare (de exemplu, prin respingerea tuturor cererilor suplimentare imediat ce 'volumul maxim de date primite' este atins). Aplicatia nu trebuie sa cedeze sub 'stres' datorita cererilor suplimentare. Odata ce situatia de solicitare s-a incheiat, sistemul trebuie sa recupereze cat de repede posibil si sa revina la comportamentul normal.

. testarea continua se refera la faptul ca sistemul aflat in 'exercitiu', dupa o perioada mare de timp returneaza erori 'subtile'. Probleme de gestionare a resurselor, cum ar fi omiterea deconectarii la bazele de date sau 'scurgeri de memorie' sunt exemple tipice. Ele apar atunci cand o operatiune aloca resurse (de exemplu, memoria principala, handlere de fisiere sau conexiuni la bazele de date), dar nu le elibereaza atunci cand se termina. Daca am apela de cateva ori operatiunea cu 'defecte' in testarea 'normala', nu vom detecta eroarea. Doar testarea continua ne asigura ca operatiunea este executata in mod repetat, pentru perioade lungi de timp, pentru a reproduce in cele din urma 'gatuirea" resurselor cauzate de aceasta eroare (de exemplu, lipsa de memorie).

6.5 Testarea securitatii

Probabil, cel mai critic aspect al unei aplicatii web este securitatea. Necesitatea de a reglementa accesul la informatii, de a verifica identitatea utilizatorului si de a cripta informatiile confidentiale este de o importanta. Testarea securitatii este un domeniu vast si va fi discutat succint in aceasta sectiune. Testarea securitatii nu reprezinta o tehnica de testare in sensul literal; se refera la aspecte aflate in legatura cu caracteristica de calitate 'securitate':

. confidentialitatea: Cine poate accesa anumite date? Cine poate modifica si sterge date?

. autorizarea: Cum si unde sunt gestionate drepturile de acces? Toate datele sunt criptate? Cum sunt datele criptate?

. autentificarea: Cum se autentifica utilizatori sau serverele?

. responsabilitatea: Cum se jurnalizeaza accesul?

. integritatea: Cum este protejata la schimbare informatia, pe timpul transmiterii acesteia?