Testarea Unui Site Web Şi A Aplicaţiilor Web [PDF]

Zitiervorschau

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 APIuri 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 multilingvismul 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 autoorganizare). 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 feedbackul 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 Oportunitate

Continut si structura Infrastructura mediu recenzii si inspectii, liste de verificare, dezvoltarea pe baza testare lexicala, ghiduri de testare de stil, recenzii

si

Exactitate

Fiabilitatea

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 Maturitate testarea andurantei testarea andurantei Toleranta la erori testarea prin fortarea erorilor, testarea la solicitari

Posibilitatea recuperare

Usurinta in folosire

Intelegerea

Invatarea

Operabilitatea

Atractivitatea Eficienta

de testarea prin fortarea erorilor, testarea in caz de avarie

testarea prin fortarea erorilor, testarea in conditii de resurse scazute, testarea la solicitari testarea in caz de avarie, testarea prin fortarea erorilor, testarea in conditii de resurse scazute

studii de usurinta in analiza lizibilitatii folosire, evaluare statice, studii de euristica usurinta in folosire studii de usurinta in folosire, evaluare euristica studii de usurinta in Evaluare euristica folosire, evaluare euristica testarea publicitatii

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

testarea la incarcare si solicitari, monitorizare testarea andurantei, 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.

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, layoutul 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?