Testarea unui site web şi a aplicaţiilor

web
Testarea web este numele dat testărilor software care se concentreaza pe aplicaţii web. Testarea
completă a unui sistem web înainte de a fi lansat oficial poate ajuta în abordarea unor aspecte
înainte ca sistemul să fie deschis publicului. Probleme cum ar fi securitatea aplicației web,
funcționalitatea de bază a site-ului, accesibilitatea pentru persoanele cu handicap și pentru utilizatorii
complet capabili, precum și disponibilitatea pentru traficul estimat și numărul de utilizatori, și
capacitatea de a supraviețui unui varf masiv de trafic de utilizatori, ambele fiind legate de testarea la
sarcină.

Instrumente pentru testarea performanţelor

aplicaţiilor web
Instrumentele pentru testarea performanţelor aplicaţiilor web sunt folosite pentru a testa aplicații web
și interfețe legate de web. Aceste instrumente sunt folosite pentru performanță, sarcină, și teste de
stres pentru aplicaţii web, site-uri web, servere web și alte interfețe web. Instrumentele pentru
testarea performanţelor aplicaţiilor web simulează utilizatori virtuali. Astfel, instrumentul este util
pentru a verifica strangulării în trafic și probleme de performanță ale site-ului sau aplicaţiei web în
curs de testare.

Un astfel de instrument se confruntă cu diverse provocări în timpul testării și ar trebui să fie în

măsură să efectueze teste pentru:

 Compatibilitate browser
 Compatibilitate sistem de operare
 Compatibilitate aplicație Windows, în cazul în care este necesar
Instrumentul permite unui utilizator să specifice modul în care utilizatorii virtuali sunt implicaţi în
mediul de testare, respectiv utilizatori în creștere, în număr constant, sau încărcări periodice de
utilizatori. Creșterea sarcinii de utilizatori, pas cu pas, se numește RAMP, unde utilizatorii virtuali
sunt crescuţi de la 0 la sute. Sarcina constantă de utilizatori menține sarcina de utilizatori specificată
în orice moment. Sarcina de utilizatori periodică tinde să crească și să scadă sarcina utilizatorilor din
timp în timp.

Teste de securitate web

Teste de securitate web ne spun dacă cerințele de aplicații web sunt îndeplinite atunci când sunt
supuse la date de intrare malware.
Testarea interfeţei cu utilizatorul a aplicațiilor
web
Unele şabloane oferă un set de instrumente pentru testarea aplicațiilor web.

Instrumente de testare web în sursă deschisă

 Apache JMeter: program Java pentru testarea încărcării și măsurarea performanței.
 Curl-loader: instrument puternic scris în C pentru testarea încărcării în diferite scenarii.
 Selenium: suită de instrumente pentru automatizarea browserelor web. Disponibil in mai
multe limbi.
 Watir: Web Automation Testing In Ruby – pentru automatizarea browserelor web.

Instrumente de testare web pe bază de

Windows
 CSE HTML Validator – Testează HTML (inclusiv HTML5), XHTML, CSS (inclusiv CSS3),
accesibilitatea – software-ul de la AI Internet Solutions LLC.
 HP LoadRunner – testează automat performanțe și sarcina – software de la HP.
 HP QuickTest Professional – testează automat funcționalitatea și regresia – de la HP.
 IBM Rational Functional Tester
 NeoLoad – teste de încărcare și de performanță – instrument de la Neotys.
 Soatest – instrument de testare API de la Parasoft
 Ranorex – testare automată funcţionalitate cross-browser, de la Ranorex.
 Silk Performer – instrument de testare performanță, de la Borland.
 SilkTest – instrument pentru testarea automată a funcționalității aplicațiilor de întreprindere.
 TestComplete – instrument de testare automată, dezvoltat de SmartBear Software
 Testing Anywhere – instrument de testare automatizat pentru toate tipurile de teste
Automation Anywhere.
 Test Studio – instrument de testare software pentru testarea web a funcționalităţii, de la
Telerik.

Instrumente de testare pe bază de cloud

 Blitz: testarea de încărcare și de performanță a site-urilor web, aplicații web, mobile, și API-
uri REST.
 Testdroid: testarea compatibilităţii și funcționalităţii site-urilor web, şi aplicatii web şi mobile,
pe dispozitive reale Android și iOS.
  Testize: serviciu simplu de testare сross-dispozitiv şi cross-browser și servicii de analiză
pentru proprietarii de site pentru a identifica problemele de impact ale site-ului.

Testarea aplicatiilor web

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

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.

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

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

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.

și testarea sistemului ('testarea in ansamblu').

5 Schema de testare

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.

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

Functionalitate Functii Continut si structura Infrastructura si

mediu
Oportunitate recenzii si inspectii, liste de verificare,
dezvoltarea pe baza testare lexicala, ghiduri
de testare de stil, recenzii
 Exactitate captura / re-rulare, analiza statica, testarea analiza statica,
dezvoltarea pe baza legaturilor, testatea testarea legaturilor
de testare lexicala, recenzii
Interoperabilitate testarea compabilitatii test de tiparire, liste de testarea compabilitatii
pe browsere si verificare, recenzii, pe browsere si
platforme multiple teste de compatibilitate platforme multiple
Conformitate teste de liste de verificare, testarea compabilitatii
compatibilitate, ghiduri teste de compatibilitate, pe browsere si
de stil, dezvoltarea pe ghiduri de stil, recenzii platforme multiple
baza de testare
Securitate analiza celor mai analiza celor mai
frecvente atacuri, frecvente atacuri,
recenzii si inspectii testare prin fortarea
erorilor, hacking-ul
etic
Fiabilitatea Maturitate testarea andurantei testarea andurantei

Toleranta la erori testarea prin fortarea testarea prin fortarea

erorilor, testarea la erorilor, testarea in
solicitari conditii de resurse
scazute, testarea la
solicitari
Posibilitatea de testarea prin fortarea testarea in caz de
recuperare erorilor, testarea in avarie, testarea prin
caz de avarie fortarea erorilor,
testarea in conditii de
resurse scazute
Usurinta in Intelegerea studii de usurinta in analiza lizibilitatii
folosire folosire, evaluare statice, studii de
euristica usurinta in folosire
Invatarea studii de usurinta in
folosire, evaluare
euristica
Operabilitatea studii de usurinta in Evaluare euristica
folosire, evaluare
euristica
Atractivitatea testarea publicitatii

Eficienta Comportamentul testarea la incarcare si testarea la incarcare si

in timp solicitari, monitorizare solicitari, monitorizare
Utilizarea testarea andurantei testarea la incarcare testarea andurantei,
resurselor monitorizare

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 http://www.webreference.com/stats/browser.html.

<="" span="" style="color: rgb(51, 51, 51); font-family: Tahoma, helvetica, arial, sans-serif; font-size: 12px; font-
style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal;
orphans: 2; text-align: justify; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-
spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial;
text-decoration-color: initial;">

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
(http://validator.w3.org/) utilizat in asociere cu manualul de referinta si testarea de catre utilizator a caracteristicilor
de accesibilitate.
 6.4 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':

• autentificarea: Cum se autentifica utilizatori sau serverele?

• responsabilitatea: Cum se jurnalizeaza accesul?

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