Prof. univ. dr. ing. Mariana Marinescu ABSOLVENT: Ioana Isabela Margalinoiu FRAMEWORK PENTRU TESTAREA AUTOMATĂ A APLICAȚIILOR WEB COORDONATOR… [308221]

PROIECT DE DIPLOMĂ

COORDONATOR ȘTIINȚIFIC:

Prof. univ. dr. ing. Mariana Marinescu

ABSOLVENT: [anonimizat]:

Prof. univ. dr. ing. Mariana Marinescu

ABSOLVENT: [anonimizat], aceasta tema se dovedeste a avea o importanta majora in cadrul unei companii producatoare de aplicatii sau de software. [anonimizat] o [anonimizat] a face compromisuri de calitate. [anonimizat].

[anonimizat], [anonimizat], ingineresti de dezvoltare.

Testarea produselor este o [anonimizat], in limbaj de specialitate se discuta despre analizarea si asigurarea calitatii (Quality Assurance). Exista numeroase cai de a [anonimizat]-si conceperea unui framework de testare automata a aplicatiilor web. Testele automate executa o secventa de actiuni fara interventie umana si pot simula folosirea unei aplicatii in conditii de simultaneitate ridicata. [anonimizat], [anonimizat]. [anonimizat], spre deosebire de testarea manuala care este un proces costisitor in ceea ce priveste consumul de resurse: bani, timp si efort de munca.

Lucrarea este structurata in patru capitole. Primul capitol dezvolta idea centrala a tezei, si anume nevoia conceperii unui framework pentru testarea automata profitabil dar si deplin satisfacator pentru producatorii si utilizatorii si utilizatorii de produse software de calitate inalta. Totodata, primul capitol prezinta elemente si concepte generale ale testarii automate.

[anonimizat], notand aici totodata si modul de utilizare in spectru larg dar si in spectru restrans si importanta acestora in cadrul lucrarii.

[anonimizat]. Prezentarea aspectelor generice va avea o importanta majora in a intelege conceptele dupa care aplicatia a fost create. [anonimizat], iar ultima parte a lucrarii ilustreaza descrierea detaliata a framework-ului de testare automata.

Solutia propusa urmareste pe scurt reducerea timpului de dezvoltare si a costurilor, prevenirea erorilor prin abordarea structurala a procesului de dezvoltare a proiectului, reutilizarea informatiei asimilate ([anonimizat], conditii hardware etc.) [anonimizat]-le in functie de necesitati.

Motivatia alegerii temei are o latura strict subiectiva, intrucat consider ca pentru obtinerea unui randament stisfacator dintr-un proces, aplicatie sau software sunt necesare: calitatea si interactionarea cu clientii. Pasiunea mea pentru analiza software a inceput o data cu primul meu loc de munca, in care rolul meu a fost de inginer de testare automata si analiza de business. Pe masura ce am inteles importanta analizarii rapide si exacte din punct de vedere al economiei de timp si pe masura ce am inteles insemnatatea aspectului calitativ al unui sistem, am reusit sa pun bazele acestei solutii de automatizare a testarii, imbunatatind produsele si grabind procesul de integrare rapida si dezvoltare continua.

Pe aceasta cale multumesc admirabililor profesori coordonatori, societatii in cadrul careia am inceput sa ma dezvolt din punct de vedere profesional si nu in ultimul rand, multumesc parintilor mei pentru eforturile si sustinerea colosala oferite la fiecare pas al vietii mele.

Cap 1. CONCEPTE FOLOSITE IN ELABORAREA PROIECTULUI

1.1 Notiuni generale despre dezvoltare software

Procesul de dezvoltare al unui software se face in cconformitate cu nevoile utilizatorilor, urmand un set de baza de procedure interconectate, cunoscute sub numele de “Ciclul de viata al dezvoltarii”, Program Development Life Cycle (P.D.L.C).

Pentru înțelegerea managementului proiectelor este important ca pentru început să se înțeleagă conceptul de proiect. În general, un proiect este o lucrare temporară întreprinsă pentru a atinge un anumit scop. În mod normal, proiectele implică un număr de persoane, care execută activități legate între ele, un sponsor și/sau un beneficiar principal, care este interesat în valorificarea resurselor, pentru terminarea proiectului într-o manieră eficientă și într-un anumit timp.

Termenul de proiect provine din latinescul projicere – aruncare înainte. Rădăcina sa latină evocă o mișcare, o traiectorie și o raportare în timp și spațiu, deoarece sugerează implicarea următoarelor elemente:

un punct de plecare utilizat ca și bază, de la care se pornește;

aruncare înainte, planificare (funcția cea mai importantă în managementul proiectului;

scopul, obiectivul.

Dicționarul Oxford definește proiectul astfel:

“Întreprindere individuală sau colectivă, planificată cu foarte mare atenție și destinată a atinge un obiectiv particular, ex: un proiect de cercetare, un proiect național pentru a încuraja dezvoltarea întreprinderilor (afacerilor). “

PMBOK Guide:

Un proiect este un efort temporar asumat pentru a realiza un produs, un serviciu sau un rezultat unic.

Dicționarul francez Petit Robert propune următoarele definiții:

imaginea unei situații pe care ne gândim să o atingem;

ceea ce este „aruncat” în fața eului ca și ghid de acțiune;

desen, intenție, plan, rezolvare, viziune;

prima stare a unei activități, redactarea pregătitoare, schiță;

toate acțiunile prin care omul tinde să modifice lumea sau pe el însuși întrun sens dat;

planul unei clădiri de construit.

Datorită gradului de unicitate și complexitate a proiectelor, precum și a dificultăților care apar în procesul de definire a obiectivelor, a stabilirii duratei și costurilor, fiecare proiect are un anumit nivel de nesiguranță. Această nesiguranță este unul din principalele motive pentru care managementul proiectului este atât de provocator, în special în proiectele ce implică utilizarea sau proiectarea de tehnologii noi.

Fiecare proiect este constrâns în diferite moduri de scopul, durata și costul obiectivelor. Aceste limitări sunt denumite în managementul proiectului ca fiind o triplă constrângere. Pentru a crea un proiect de succes, scopul, durata și costul trebuie luate toate în considerare, și este de datoria managerului de proiect să balanseze aceste trei obiective competitive. [3]

În acest scop, trebuie să fie în vedere următoarele:

Scopul: (funcționalitatea): Ce încearcă să îndeplinească proiectul? Care este produsul sau serviciul unic pe care beneficiarul sau sponsorul îl așteaptă de la proiect? Ținta SCOP TIMP COST Radu V. Pascu – Managementul Proiectelor 10

Durata: Cât timp ar trebui să dureze finalizarea proiectului? Care este data limită pentru finalizarea proiectului?

Costul: Cât ar trebui sa coste finalizarea proiectului?

În timp ce tripla constrângere (Figura 1.1) descrie cum elementele de bază ale proiectului – scopul, durata și costul – interrelaționează, există și alte elemente care pot juca roluri importante. De exemplu, calitatea este deseori un factor cheie în proiecte, ca și satisfacția beneficiarului sau/și a sponsorului. O echipă de proiect poate atinge obiectivele legate de scop, durată și cost, dar nu și standardele de calitate sau satisfacerea beneficiarului sau/și a finanțatorilor.[3]

Acest ciclu de viata al dezvoltarii, pe care il vom denumi P.D.L.C. include diverse seturi de procedure si activitati care se presupun a fi izolate si secventiale, insa in mediul real acestea se suprapun si sunt interconectate. Setul de procedure de baza dupa care se ghideaza numeroase organizatii in programul lor de dezvoltare, sunt urmatoarele:

Definirea scopului;

Conceperea arhitecturii programului;

Dezvoltarea;

Cautarea defectelor majore;

Testarea;

Documentarea testarii si dezvoltarii;

Mentenanta;

Extinderea;

Redesign-ul;

In continuare vor fi abordate pas cu pas fiecare metoda din procesul de dezvoltare software.

1.1.1 Definirea scopului

Aceasta etapa constituie definirea formala a sarcinii de lucru, incluzand specificatiile datelor de intrare (inputs) si datelor de iesire (outputs), cerintele de procesare, constrangerile de sistem si metodele de manipulare a erorilor ce vor aparea.

Acest pas este definitoriu pentru conceperea unui produs satisfacator. Este imposibil ca o problema sa fie rezolvata cu ajutorul unui computer, fara o intelegere clara a acesteia si fara o identificare. Identificarea necorespunzatoare a problemei conduce la o proasta performanta a sistemelor. Programatorul ar trebui sa investeasca o buna perioadaa de timp pentru idetificarea cerintelor generale, ca ulterior, pe masura ce software-ul va fi dezoltat, topicurile care vor trebui atinse sa fie clare. In cazul in care acest lucru nu se va intampla, se poate ca programatorul sa sesizeze ca programul sau bine-scris nu rezolva problema propusa.

In studiul care se realizeaza trebuie sa fie pusi în evidenta urmatorii factori:

capacitatea firmei de a realiza proiectul în timpul cerut;

costul final al proiectului;

cheltuielile implicate;

bugetul cerut pentru proiect;

specificatiile proiectului, incluzând aspecte de calitate i cerine de siguranta;

identificarea unor probleme majore a cror rezolvare este accesibila firmei;

definirea activitatilor majore i estimarea costurilor, a resurselor necesare si a celor disponibile;

acceptarea altor conditii contractuale (cerine geografice, ecologice etc.).

Scopuri și obiective clar definite și formulate astfel încât să producă rezultate clare, bine determinate. Scopul lor este acela de a rezolva o problemă, ceea ce implică o analiză preliminară a necesităților. Sugerând una sau mai multe soluții, ele vizează o schimbare durabilă. Majoritatea proiectelor au ca scop furnizarea unui produs sau serviciu cu un grad mai mic sau mai mare de noutate pe piață. Scopul unui proiect răspunde la întrebarea: „unde dorim să ajungem prin realizarea proiectului respectiv ?” În anumite situații scopul înseamnă rezolvarea unor probleme, iar în alte situații doar ameliorarea problemei într-o anumită măsură. [13]

Obiectivele unui proiect trebuie exprimate de la început cât mai clar cu putință, pentru a se armoniza punctele de vedere ale tuturor părților implicate și a se evita neînțelegerile între echipa proiectului și deținătorii de interese.

In concluzie, acesta etapa este procesul de familiarizare cu problema. Incepe cand programatorului se asigneaza sarcina. Include revizuirea proiectului din punct de vedere al design-ului arhitecturii. Procesul se va termina in momentul in care vor fi finalizate toate cerintele din sarcina si cand intrebarile au fost lamurite si au de asemenea un raspuns.

1.1.2 Conceperea arhitecturii programului

Odata ce problema a fost identificata, urmatoarea etaoa din cadru P.D.LC. este conceperea arhitecturii programului. Un computer este in acelasi timp rapid si versatile, insa ii sunt necesare specificatii meticuloase pentru actiunile pe care trebuie sa le desfasoare. Pentru utilizator, exista rareori o oportunitate de a permite computer-ului sa faca o actiune nedirectionata, de aceea programatorul trebuie sa decida inainte de scrierea in program exact ceea ce trebuie sa faca calculatorul. O astfel de descriere functionala a sarcinii de lucru este denumita “algoritm”.

Tehnici de proiectare a software-urilor.

Programarea modulara

O metoda in care programele de dimensiuni mari sunt impartite in programe sau module mai mici care pot fi proiectate, codate si separate cu un minim de interactiune intre ele.

Proiectarea top-down

O metadata prin care sarcina generala este prima sarcina care va fi defrinita, urmand ulterior definirea celorlalte subsarcini. Procesul incepe dezvoltarea de sus in jos, incepand cu prima sarcina si continuand cu celelalte.

Proiectarea structurala

O metoda prin care programele sunt scrise in conformitate cu formele specific definire; cu ajutorul acestei metode doar unele tipuri logice de programe sunt permise. Designer-ul arhitecturii de software poate utiliza o mixture de tehnici, in fuctie de cerinre si de modul de dezvoltare.

1.1.3 Dezvoltarea

Cel de-al treilea pas este procesul de transformare a logicii scrise a programului si documentatiei in cod. Acest topic este detinut de programator, el fiind responsabil de dezvoltare. Erorile logice vor fi detectare, de asemenea, la nivelul acestui pas.

Un mediu pentru dezvoltarea sistemelor software este o colecție de utilitare software și hardware pentru producția de sisteme software într-un domeniu specific. Există trei tipuri de astfel de medii:

medii de programare – pentru programare, testare, depanarea programelor;

medii CASE – orientate spre fazele de definire a specificațiilor software și a proiectării sistemelor;

medii de inginerie software – dedicate producției de sisteme software complexe, cu un ciclu îndelungat de viață, a căror întreținere costă mai mult decât dezvoltarea lor și care sunt produse de echipe și nu de programatori individuali;

Acestea furnizează suportul pentru toate activitățile de dezvoltare și de management. În practică, granițele dintre aceste tipuri nu sunt bine delimitate.

Mediile CASE – sunt destinate diferitelor fazelor din dezvoltarea sistemelor. Aceste medii sunt orientate spre un suport grafic care e folosit în diverse metode de proiectare. Ele pot suporta fie o singură metodă, fie o gamă de câteva din cele mai cunoscute metode. Componentele tipice într-un mediu CASE sunt:

un sistem de editare a diagramelor pentru crearea diagramelor fluxurilor de date, a hărților de structură, a diagramelor de tip entitate-relație (entity-relationship), a dicționarelor de date, a arborilor de decizie, etc.; informațiile despre aceste identități sunt înregistrate într-o bază de date centrală (enciclopedie);

facilități de analiză și verificare în timpul creării diagramelor;

facilități ce permit utilizatorului de a regăsi informațiile;

dicționarul de date, conținând informații despre entitățile folosite în proiectul sistemului;

facilități de generare a rapoartelor care folosesc informațiile din baza centrală de date și generează documentația sistemului;

utilitare de generare a formatelor ecran și document;

facilități import-export pentru schimbul de informații dintre baza centrală de date și alte utilitare de dezvoltare;

unele medii CASE suportă generatoare de cod pe baza informațiilor de proiectare înregistrate în dicționarul de date.

Unele din criticile care au fost aduse acestor medii sunt următoarele:

nu există o standardizare care să facă informația interschimbabilă dintre diverse medii CASE;

nu există facilități care să permită utilizatorului să modifice regulile implicite ale metodei pe care mediul o suportă, și să o adapteze problemei sale specifice;

nu sunt facilități suficiente pentru crearea unei documentații de calitate;

facilitățile oferite pentru realizarea diagramelor determină o greoaie creare a acestora (diagrame nu foarte complicate pot necesita câteva ore de lucru); este necesar un mod automatizat de creare și aranjare a diagramelor, dat fiind un text de intrare;

suportul pentru specificațiile formale este sărac;

suportul pentru proiectarea orientată-obiect este sărac; de aceea, avantajele productivității și scăderii costului sistemelor soft prin folosirea unor tehnici ca analiza orientată obiect sunt negate cel puțin datorită unor utilitare inadecvate.[8]

Pentru dezvoltarea unui program avem nevoie de:

înțelegerea clară a cerințelor;

un set de metode și instrumente de lucru;

un plan de acțiune.

Planul de acțiune se numește model de dezvoltare. Dezvoltarea unui anumit program constă într-un set de pași ce se fac pentru a-l realiza. Luând în considerare tipul pașilor ce se efectuează se creează un model de lucru, ce poate fi aplicat unei serii mai largi de proiecte. Acesta este motivul pentru care planul de acțiune este numit model: el poate fi privit ca un șablon al dezvoltării de programe. [8]

Există o serie largă de modele de dezvoltare:

ad-hoc (do-it-yourself)

cascadă (waterfall)

prototipizare

metode formale

spirală

RUP (Rational Unified Process)

XP (Extreme Programming)

1.1.4. Depanarea

Aceasta etapa presupune descoperirea si corectarea erorilor de programare. Putine programe relueaza correct prima oara, deci depanarea este o etapa importanta si consumatoare de timp de-a lungul dezvoltarii unui software. In limbaj de specialitare “verficare” si “validare”.

De-a lungul ultimului deceniu comunitatea științifică internațională a început să privească cu deosebit interes domeniul diagnozei tehnice, fapt demonstrat de abundența de lucrări din literatura de specialitate, precum și de numeroasele evenimente științifice, simpozioane, conferințe consacrate acestui domeniu.

Pornind de la aspectul științific, este evident avantajul comercial-industrial: un sistem de supraveghere cu detectarea și diagnoza automată a defectelor, contribuie atât la creșterea autonomiei cât și a fiabilității instalațiilor industriale.[8]

De-a lungul timpului, studiul teoretic al diagnozei se descompune în două etape: punerea în evidență a simptomelor unui defect urmată de o etapă de decizie. Cunoscând faptul că prima etapă este studiată, în principal, în cadrul comunității automaticii, în timp ce cea de-a doua este interesantă din punct de vedere al comunității științifice ce se ocupă de prelucrarea semnalelor, nu este de mirare că acest decupaj a contribuit la trecerea obiectivelor inițiale pe al doilea plan, procesul decizional fiind mult mai spectaculos decât efortul de pregătire a informațiilor necesare acestuia.

Verificarea asigura ca programul sa faca cee ace programatorul a intentionat sa dezvolte , iar validarea asigura ca programul ofera rezultatele corecte pentru un set de date de testare.

Instrumentele ce pot fi utilizate pentru depanarea unui program sunt prezentate mai jos:

-Simulatoare

Analizatoare logice

-Puncte de intrerupere

Urmarirea rutinelor

“Cape de memorie”

Software de intrerupere

1.1.5 Testarea

Testarea softwarelor reprezinta un pas extrem de important dinP.D.L.C., care nu poate lipsi din ciclul de viata al acestuia. Testarea este insura modalitate de asigurare a faptului ca soft-ul este operational. Fiecare etapa aduce erori specifice, ceea ce implica modalitati, de asemenea, specifice, de testare. Realizarea de software fiabil este conditionata de efectuarea unei testari cât mai riguroase. Cu cât procesul de testare este mai riguros, cu atât costurile care se propaga în timp la utilizatori sunt mai reduse. Aceleasi efecte le resimte însusi producatorul. [1]

Crearea de software orientat spre reutilizare 100 % schimba atât atitudinea producatorului cât si pe cea a echipei de testare, acordând o atentie speciala produselor care se realizeaza. Metricile testarii evidentiaza caracteristici de calitate software si progresele acestora ca rezultate ca rezultat al procesului de testare-corectie.

Defectele sunt cauzate de erorile umane introduse in timpul dezvoltarii unui program. Ele se manifesta fie prin functionarea incorecta a aplicatiei la nivel logic, fie prin nefunctionarea sa sau printr-un comportament, sa ii spunem, deviant (erori, crashuri, etc.).

Testarea in general si in particular cea software, reprezinta suma tuturor procedurilor, operatiilor si actiunilor menite sa asigure buna functionare a programelor. Prin "buna functionare" intelegem:

Respectarea specificatiilor / cererilor clientului

Implementarea corecta a cerintelor de functionare (requirements)

Absenta erorilor de proiectare logica si algoritmica

Siguranta datelor folosite in cadrul programului

Viteza optima de rulare a aplicatiei

Folosirea eficienta a resurselor disponibile

Grad ridicat de folosinta

In acceptiunea generala, testarea se caracterizeaza prin rularea testelor. Aceasta este, in schimb, doar partea vizibila din exterior. Pentru a asigura toate cele de mai sus, este nevoie de mult mai multe etape pana a ajunge in punctul executiei testelor. Din motive de eficienta, planurile de teste trebuie neaparat sa contina si o perioada de timp alocata planificarii testelor, design-ului test case-urilor, planificarii executiei si, bineinteles, analizei rezultatelor. [2]

1.1.6 Documentarea testarii si dezvoltarii

Acest stadiu face referire la documentarea programelor cu scopul de a face inteles programulo de cei ce il vor utiliza, dar si de cei ce ii vor asigura mentenata. Documentatia are rolul de a ajuta programatorii viitori ai unei companii sa inteleaga aplicatia, pentru ca aceasta sa fie dezvoltata I viitor.

Aceasta etapa este adesea trecuta cu vederea. Totusi, documetarea corespunzatoare nu este utila doar in etapele de dezvoltare si depanar, ea este de asemenea esentiala in intretinerea si proiectarea unor alte etape de viitor. Documentatia este constituita din: diagrame, comentarii, harti si liste de parametri.

O buna documentatie va face sarcinile ulterioare mult mai simple. Diagnosticarea starii tehnice a unui sistem complex, cum ar fi unul software, se bazează pe faptul că în principiu, comportarea globală a sistemului este determinată de comportarea fiecărei componente în parte.[2] La rândul ei, fiecare componentă, are comportarea caracterizată de un set de parametri tehnici care pot fi măsurați. În aceste condiții, se poate spune că în principiu, dacă toți parametrii caracteristici ai unui sistem tehnic sunt măsurați și valorile acestora (vectorii de test) se încadrează în valorile normale, sistemul respectiv se găsește într-o stare tehnică bună de funcționare, iar comportarea sistemului este normală.

1.1.7 Mentenanta

Etapa in care sunt actualizate si corectate schimbarile produselor in timpm din P.D.L.C. Testarea si documentarea corespunzatoare ar trebui sa reduca documentarea corespunzatoare ar trebui sa reduca in mod semnificativ frecventa mentenantei, insa intretinerea produsului este necesara. Schimbarile survenite in productie pot aparea din cauza:

Bug-urilor descoperite recent

Schimbarilor de specificatii

Extinderea specificatiilor

Echipamente noi

Medii de dezvoltare noi

Costurile implicate in intretinerea programelor sunt de obicei subestimate, un studio recent aratand ca intr-un mediu de programare, peste 50% din timp este alocat mentinerii programelor existente. Deci, devine cu adevarat necesar sa se reduca costurile si timpul petrecut pentru intretinere.

Costul produsului. Cheltuielile pentru producerea sistemelor software sunt imense. Se apreciază că ele au depășit suma de 140 bilioane $ la nivelul anului 1985 și urmau să crească de atunci cu 12% pe an. Costul este influențat de cerințele impuse pentru funcționarea acestuia (exemplu: necesitatea de a se executa în timp real – timpul tipic de răspuns este de ordinul microsecundelor). De asemenea, timpul mare de viață și frecventele modificări cerute pentru menținerea sistemului sau pentru adăugarea unor noi facilități vor mări costurile generale. Se estimează că cel mai mare volum al cheltuielilor (60%-80%) se înregistrează în cazul întreținerii softului. Totodată, cu cât produsul soft este mai complex, mai mare, cu atât costurile totale vor crește. Figura 2 se bazează pe un număr de studii care demonstrează distribuția tipică a timpului consumat pentru crearea unui sistem software.

O reducere a costurilor poate fi posibila cu ajutorul urmatoarelor bune practici:

Calitateaa codului

Portabilitatea si generalitatea

Cod structurat

Testare

Documentatie

1.1.8 Extinderea si Redesign-ul

Extinderea face referire la rezolvarea de cerinte ce nu au fost descrise in problema initiate. Extinderea are loc atunci cand componentele actuale ale sistemului nu mai sunt suficiente pentru client, asa ca problema initiala este din nou abordata si actualizata. Extinderea implica atat crearea unei structuri arhitecturale ale sitemului, complementara celei din problema initiala, dar si redesign-ul produsului in asa fel incat aceasta sa fie usor de utilizat si interactive petru utilizatori.

Redesign-ul poate implica adaugarea de noi functionalitati in cadrul software-ului , de aceea etapa redesign-ului se paralelizeaza pe cat de mult posibil cu extinderea produsului. O optimizarea, extindere a unui program nu poate adduce castiguri enorme, cu exceptia cazului in care programul este foarte slab scris, insa o crestere mai mare de 25% este rara. [8]

1.2 Testarea software

1.2.1 Obiectivele testarii software

Importanta testarii software si a impactului sau asupra mediului de dezvoltare nu poate fi subestimata. Privita si inteleasa ca fiind o component fundamental a asigurarii calitatii software, reprezinta de asemnea si o revizuire a specificatiilor si design-ului. O organizatie software isi aloca 40% din resursele de timp pentru testare. O serie de reguli care actioneaza ca obiective de testare sunt:

Testarea este procesul prin care se execcuta programele cu scopul de a gasi erori;

Un caz bun de test are o sansa de a gasi erori nedescoperite;

Un caz de test de success descopera o noua eroare;

Exista numeroase definiri si ierarhizari ale caracteristicilor de calitate. Abordarea acestora este facuta in mod diferit de catre autorii care s-au ocupat de acesta problema. Ei folosesc fie termenul de caracteristici de calitate, fie le grupeaza in caracterisitici si atribute, caracteristici si factori sau caracteristici si subcaracteristici. [7]

Conceptul de fiabilitate se defineste drept probabilitatea ca o functie data sa fie executata in mod corect de un sistem pe o perioada de timp impusa. Fiablitatea este privita ca masura increderii pe care o avem in conceptia si in capacitatea unui sistem de programe de a functiona corect in toate conditiile avute in vedere de la inceput. Definitia se refera mai mult la fibilitatea procesului decat la cea a sistemului de programe. Este legata de probabilitatea ca o eroare din cadrul programelor componente ale sistemului sa fie activata de un set specific de date de intrare.

In comparatie cu fiabilitatea produselor hardware, fiabilitatea produselor software exprima particularitatile industriei producatoare de software. Abordarile cantitative ale fiabilitatii software exprima probabilitatea ca un sistem de programe sa-si indeplineasca functiile cu anumite performante si fara erori intr-un interval de timp si in conditii de exploatare date. Abordarile calitative privesc fiabilitatea ca o capacitate a sistemului de programe.[11]

Standardul ISO/IEC 9126, defineste fiabilitatea ca un set de atribute bazat pe capabilitatea produsului software de a-si mentine nivelul de performanta, in conditii si pe o perioada de timp stabilite. Analiza acestei caracteristici pune accentul pe toleranta la defecte si corectitudine.[3]

Tehnicile de obtinere a tolerantei la defecte se aplica in special la componentele hardware si la sistemele de operare. Principala problema in programare este corectitudinea sistemelor de programe, in sensul ca acestea trebuie sa indeplineasca specificatiile functionale stabilite.

Aprecierea fiabilitatii sistemelor de programe se face prin trei elemente:

Disponibilitatea – implica conservarea unei capacitati ridicate de prelucrare a unui sistem de programe, chiar daca apare o anomalie in textul sursa al componentelor acestuia;

Integritatea – impune ca rezultatele sa fie exacte;

Reproductibilitatea prelucrarii – urmareste obtinerea acelorasi rezultate, cu ajutorul unor seturi de date identice, la momente si conditii de executie diferite.

Testabilitatea ofera utilizatorilor posibilitatea de a scoate in evidenta comportamentul sistemului de programe in situatii particulare. Prin asigurarea testabilitatii se urmareste descoperirea cat mai multor variante de probleme rezolvabile cu aceste sisteme de programe.

În practică s-a observat că un sistem de programe cu robustețe ridicată are un nivel de fiabilitate superior și este în același timp un sistem de programe testabil.

În prezent, testarea se realizeaza utilizand fie strategia black box (cand se urmareste numai comportamentul functional al produsului), fie strategia white box (se analizeaza comportamentul programului avand la dispozitie codul sursa al acestuia). [6]

Nici o metoda de testare nu garanteaza corectitudinea produselor software, însa creste probabilitatea ca acestea sa se încadreze în limitele de calitate cerute. Initial, testarea se facea integral manual, fiind considerata singura solutie de a descoperi eventualele defecte. Ulterior, testarea manuala a fost ajutata si de testarea automata.

Pentru aprecierea importanței care se acordă caracteristicilor de calitate a fost efectuat un studiu în care au fost cuprinși un număr de zece programatori și zece utilizatori. Acestora li s-au cerut sa specifice nivelul de semnificatie al caracteristicilor de calitate pe care le considera cele mai importante in procesul de evaluare a calitatii sistemelor de programe destinate evidentei contabile. Exprimarea s-a efectuat in format procentual, iar suma acestora nu trebuie sa depaseasca 100 de procente.

Figura 1.3 Ponderile utilizatorilor

In figura de mai sus sunt reprezentate ponderile acordate de utilizatori. Din punctul lor de vedere factorii determinanti in aprecierea calitatii sistemelor de programe pentru contabilitate, acele caracteristici pe care le percep in mod direct. Astfel utilizabilitatea (13.2%), functionalitatea (11.9%) si fiabilitatea (10.8%) sunt caracteristicile principale pe care utilizatorii le urmaresc atunci atunci cand evalueaza calitatea unui astfel de sistem de programe. [9]

Caracteristicile care nu le confera o perceptie directa asupra sistemului sunt mai putin importante pentru utilizatori si de aceea ei le atribuie ponderi reduse. Astfel stabilitatea (3.9%), adaptabilitatea (4.3%) si robustetea (5.6%) sunt caracteristici de calitate, carora utilizatorii le acorda un nivel redus de importanta.

Acest lucru se datoreaza si faptului ca utilizatorii nu inteleg bine semnificatia acestor caracteristici si de aceea nu au o viziune corecta asupra modului in care ele influenteaza calitatea generala a serviciilor oferite de sistemele de programe pentru compatibilitate.

Utilizatorii acorda niveluri de imortanta medii unor caracteristici cum sunt eficienta (8.2%), siguranta in utilizare (7.9%) si complexitatea (7.2%). Astfel, rezulta ca ei inteleg relatia de dependenta dintre calitatea si complexitatea unui sistem de programe sau faptul ca acesta trebuie sa aiba un nivel de siguranta in exploatare corespunzator si deasemenea, o buna eficienta. [9]

Analizate din punctul de vedere al programatorilor, rezultatele exprimă viziunea diferită a acestora în raport cu utilizatorii, față de nivelul de importanță atribuit caracteristicilor de calitate.

Astfel, aceștia sunt interesați de acele caracteristici care produc efecte majore și imediate asupra activităților pe care ei le desfășoară. Sunt urmărite aspecte referitoare la reducerea volumului de muncă vie, creșterea productivității și a eficienței programatorilor și nu în ultimul rând, reducerea costurilor pe care le implică dezvoltarea sistemelor de programe pentru contabilitate.

Figura 1.4 Ponderile Programatorilor

În acest context, programatorii au considerat ca factori determinanți în evaluarea calității acestor sisteme de programe, următoarele caracteristici: portabilitatea (12,1%), fiabilitatea (11,6%) și complexitatea (9,7%).

O mai mică importanță a fost acordată unor carateristici cum sunt flexibilitatea (5,3%), testabilitatea (4,8%) și stabilitatea (4,2%). A surprins nivelul redus de semnificație pe care programatorii l-au atribuit testabilității. O explicație a acestui aspect este faptul că în majoritatea companiilor care dezvoltă sisteme de programe pentru contabilitate, asamblarea componentelor în produsul final și testarea întregului sistem este efectuată de aceleași persoane care au participat la activitățile de analiză, proiectare și codificare.

În aceste condiții, aceștia au o viziune subiectivă asupra procesului de dezvoltare și implicit asupra nivelului de importanță al fiecărei etape din ciclul de viață al sistemelor de programe.

Mai mult, utilizatorii sunt rareori implicați în procesul de dezvoltare a sistemelor de programe. Acest lucru este reliefat de diferențele existente în modul de apreciere a importanței acordate diverselor caracteristici de calitate care influențează calitatea generală a serviciilor furnizate de sistemele de programe pentru contabilitate.

1.2.2 Specializarea in testare software

In contextual dezvoltarii profesionale in domeniul informatics, oamenii sunt in general obisnuitit cu faptul ca pentru a avansa in cariera, pentru a ajunge dezvoltatori trebuie sa participle la diferite taining-uri de specialitate pentru a obtine diverse certificari.

Domeniul testarii software nu este deloc diferit din aacest punct de vedere, fata de domeniul dezvoltarii software. Ca si specializari exista cele mai populare specializari in domeniul testarii:

Specialist in domeniul testarii de performanta

Este de obicei folosita pentru a determina in ce fel poate reactiona un sistem in cazuri particulare de folosire, incercand sa se determine daca acesta este stabil si daca raspunde la actiunile ce i se adreseaza.

Specialist in testarea manuala

Tester-ul actioneaza ca un utilizator, incarcand toate functiile sistemului si cautand erori si defecte. Testerii nu folosesc niciun instrument in timpul unei astfel de activitati. De obicei acestia au deja un plan elaborat conform caruia efecctueaza testarea.

Specialist in testarea automata

Acest tip de activitate consta in scriere de script-uri. Automatizarea diminueaza semnificativ cantitatea de munca manuala si permite economisirea de foarte mult timp.

Analistul

Acest tip de specilizare are ca obiective activitati de realizare a analizei in vederea definirii specificatiilor pentru construirea efectiva a sistemelor informatice, succeptibile si sa raspunda la cerintele utilizatorului.

1.2.3 Economia testarii software

Exista un impact economic determinat de testarea software, un impact economic produs de costul defectelor. Aceste costuri sunt reate si tangibile intr-o companie software. Un alt impact este modul in care se desfasoara testarea. Exista posibilitatea de a avea motivatii foarte bune si obiective bine stabilite ale testarii , insa procesul in sine sa fie unul ineficient.

In aceasta sectiune vom examina impacctul economic al defectelor si al tipului de testare.

De unde provin defectele? Petru a intelege dinamica si costurile defectelor, trebuie sa luam in considerare cateva aspect. Unul dintre cele mai des intalnite lucrui cu privire la defecte este faptul ca cele mai multe apar, provin din faza de finire a cenrintelor unui proiect. [5]

Unele problem in obtinerea unor cerinte exacte, testabile si clare sunt:

Multe companii nu au un proces de colectare a defectelor clar si binedefinit.

Putini oameni au fost instruiti, in cadrul unei companii, in a intelege dinamismul cerintelor.

Proiectele, oamenii si lumea di jur se schimba foarte repede.

Limba engleza este o limba ambigua si chiar si atunci cand consideram ca toul este clar, mesajul poate fi interpretat in mod diferit de mai multi oameni.

Cele mai multe defecte provin din cerinte si design, insa majoritatea eforturilor de testare apar in faza traditionala de testare, spre sfarsitul proiectului. Abordarea “big-bang” reprezinta concentrarea eforturilor de testare intr-o faza mai mare. [5]

Problema metodei “big-bang” este faptul ca defectele nu sunt gasite in stadia incipiente ale produsului. Una dintre cele mai cunoscute fapte despre defectele unui soft este ca cu cat timpul de detectare al unei eori este mai mare, cu atat costurile pentru fixare cresc. O regula generala, un raport in cee ace priveste acest ciclu este 1:10:100. Asta inseamna ca, daca un defect costa o unitate, pentru a stabili cerintele, desidgn-ul; acesta va costa 10 unitati, pentru a stabili testarea (sistem acceptare) , si de peste 100 de ori pentru a se stabili in productie. [7]

Figura 1.5 Comparatie BigBang si LifeCycle

1.2.4 Tipuri de testare software

In procesul de viata al uni software, testarea are un rol extrem de importand, iar in functie de posibilitati fiecare companie isi alege propriul tip si propriile metode de testare.

Tipurile generale de testare software sunt:

Testarea manuala

Testarea automata

Testarea mixta (manuala si automata)

1.2.5 Metode si niveluri de testare software

In continuare va fi prezentata o clasificare detaliata a metodelor de testare software cunoscute.

Metoda Black Box

Aceasta metoda este constituita din testarea programului din punct de vedere al unui user, plecand de la premise ca produsul care urmeaza a fi testat nu este cunoscut (din punct de vedere al functionalitatii). Practic, nu se va lua in calcul modul in care programul este construit, ci pur si simplu I se va cere orice, iar acesta va trebui sa dea un raspuns. Pentru acest tip de testare, tester-ul trebuie sa cunoasca rezultatele ce se asteapta din partea programului pentru fiecare caz in parte.

Metoda White Box

Aceasta metoda este opusul metodei prezentate anterios, “Black Box”, tester-ul avand acces la cudul sursa al programului, la algoritmi. De multe ori aceasta metoda poate reprezenta scriere de cod sau urmarirea codului existent. Luand la cunostinta constrctia software-ului si modul sau de lucru, se va testa fiecare metoda in mod separate, apoi se va testa si interoperarea acestora. Aceasta metoda poate fi echivalenta cu testarea unitara.

Metoda Gray Box

Pe parcursul anilor, aceasta metoda a aparut din nevoie si practicabilitate. Este, dupa cum ii spune si numele, etapa intermediara intre "White box" si "Black box". Ca mod de lucru, avand acces la sursele programului, se construiesc test case-urile. Dupa care, acestea sunt executate in mod Black box ca si user simplu, neaxandu-ne in momentul executarii testului pe structura interna a programului.

Testarea funcționala

Este ca si testarea “Black Box” o testare bazata verificarea cerintelor de functionalitate ale aplicatiei; acest tip de testare trebuie sa fie facuta de testeri. Din aceeasi categorie de testare, fac parte si urmatoarelle metode:

Unit testing – testarea pe unitate este prima treapta a testarii ; se testeaza functiile sau module de cod . De obicei sunt facute de programatori deoarece presupun cunostinte avansate a design-ului intern al aplicatiei si codului. Nu intotdeauna sunt usor de executat daca aplicatia nu are o arhitectura bine pusa la punct; poate presupune dezvoltarea de drivere sau alte componente.

Testarea integrata – Testarea combinata a diferitelor parti dintr-o aplicatie pentru a vedea daca functioneaza corect. Aceste "parti" pot fi module de cod, aplicatii individuale, aplicatii client-server intr-o retea etc.[10]

Testarea de sistem – Testare de tip black-box bazata pe specificatii care acopera toate partile sistemului.

Testarea acceptarii de catre user – Determina daca softul este satisfacator pentru utilizatorul final sau client.

Testarea utilizabilitatii – Testarea daca un software este "user-friendly". Evident aceasta testare este subiectiva si va depinde de utilizatorul sau clientul vizat. Interviuri cu utilizatorii, survey-uri, monitorizarea sesiunilor utilizatorilor sunt metode care pot fi folosite. Programatorii si testerii nu sunt cei mai indicati pentru acest tip de testare. [10]

Testarea instalarii si a dezinstalarii – testarea partiala sau integrala a procesului de instalare sau upgrade. • End-to-end testing – similar cu system testing; este testare de nivel 'macro' ; presupune testarea aplicatiei in mediul in care va fi folosita.

Sanity testing or smoke testing – testarea starii de “sanatate” a sistemelor dupa a noua versiune de soft a aplicatiei. Daca un nou soft face ca sistemele sa se blocheze frecvent, corupe bazele de date, etc inseamna ca aplicatia nu este destul de “sanatoasa” pentru a fi testate in continuare in starea curenta. Mentinerea testarii in stadiul actual poate duce la distrugerea sistemelor de test.[10]

Testarea de acceptanta – testarea finala bazata pe specificatiile utilizatorului final, sau bazata pe folosirea de catre utilizatorul final intr-o anumita perioada de timp; este tesatrea tipica pentru variatele de program aparute in stadiul beta, care sunt disponibile pentru toti utilizatorii pentru o perioada limitata de timp;

Testarea de compatibilitate – se testeaza cat de bine se comporta aplicatia intr-o anumita configuratie hardware, sistem de operare si impreuna cu alte aplicatii;

Testarea non-funcționala

Putem descrie acest tip de testare ca fiind focusata pe aspectE legate de performanta, Securitate, incarcare, etc. ci nu pe functionalitatea aplicatiei. De obicei acest tip de testare se face la sfarsitul testarii functionale, sau in timpul testarii de acceptanta. Daca in cazul in care se gaseste un defect de performanta care necesita un redesign major al functionalitatii, este de preferat sa se conceapa teste non-functionale inca din primele etape ale dezvoltarii soft-ului, si pe masura ce soft-ul se “maturizeaza”si testarea non-functionala poate devein mai complexa. Din aceeasi categorie fac parte si urmatoarele metode:

Testarea de stocare – Similar testării de performanță, există unele software care au anumite obiective în ceea ce privește capacitatea de stocare a datelor. De exemplu, ne putem pune întrebările: care sunt dimensiunile memoriei principale? Dar ale memoriei secundare? Care este cantitatea de fișiere temporare ce pot fi stocate de program? Scenariile de test trebuie create analog, demonstrând că programul nu respectă obiectivele privind capacitatea de stocare a datelor. [11]

Testarea de performanta – testarea obiectivelor de performanță sau eficacitate prestabilite, precum timpi de răspuns sub încărcarea unui anumit set de date sau diferite condiții de configurație. Din moment ce scopul unei testări de sistem este să demonstrăm că un program nu își îndeplinește obiectivele, scenariile de test pentru o testare de performanță ar trebui create astfel încât să demonstrăm că programul nu respectă obiectivele de performanță.

Testarea de stres – este strans legata de testarea de incarcare si performanta. Pentru astfel de testare se incearca operatii cu un numar foarte mare de repetitii, introducere de valori foarte mari, interogari complexe in bazele de date, etc.

Testarea de recuperare – Programe complexe, precum sistemele de operare sau de administrare a bazelor de date au impuse obiective de recuperare în cazul unor defecțiuni critice provocate de erori în programare sau de ordin hardware. Există funcții speciale de recuperare a datelor, iar testarea va consta în a demonstra că aceste funcții nu funcționează corect.. Nu este suficient ca sistemul să își revină la starea inițială. Scopul este ca acest lucru să se întâmple într-un timp cât mai scurt (MTTR: mean-time-to-recovery).[11]

Testarea de securitate – Fiindcă societatea este din ce în ce mai îngrijorată în privința securitații datelor, multe dintre programele software din ziua de astăzi pun accent pe acest aspect. Acest gen de testare este foarte important mai ales in aplicatiile web, la care au acces cu foarte putine restrictii un numar teoretic nelimitat de persone.

1.3 Testarea automată

Procedurile de testare manuală, prin natura lor limitată, nu reușesc să descopere toate defectele și nu reusesc să simuleze condiții de utilizare simultană si intensivă a unei aplicații. Există numeroase căi de a îmbunătăți procesul de testare, una dintre cele mai eficiente fiind testarea automată.

Testele automate execută o secvență de acțiuni fără intervenție umană și pot simula utilizarea unei aplicații în condiții de simultaneitate ridicată. În general, majoritatea produselor necesită să fie testate de mai multe ori, pe mai multe platforme software și hardware, ca și după schimbările ulterioare sau la lansarea unei noi versiuni de produs. Prin folosirea testării automate, costurile testărilor repetate se reduc aproape la zero. [1]

Cele mai importante beneficii sunt: • acoperirea tuturor etapelor de testare de la concepție până la lansare

posibilitatea simulării testării cu mai mulți utilizatori

posibilitatea repetării testelor

creșterea siguranței în produs.

Un sistem de testare automată trebuie să aibă la bază două caracteristici principale:

module reutilizabile

întreținerea și urmărirea activității dintr-un singur punct de control

De aceea una din calitățile care trebuie să le aibă un astfel de sistem este capabilitatea de a fi ușor configurat și adaptat în același ritm cu software-ul ce se testează . Sistemele de testare automată sunt o tehnologie în plină dezvoltare care au ca scop descoperirea și raportarea eventualelor defecte, mărirea longevității produsului și reducerea procesului de întreținere.[2] Testarea automată înseamnă mai mult decât o simplă captură de ecran și răspunsul la câteva scripturi : ea trebuie să înceapă cu planificarea și design-ul procedurii de testare, să conțină o serie de teste repetabile, o interfață de management al scenariilor de test și un mecanism de raportare și gestionare a bug-urilor descoperite în urma testării. Un sistem de test evoluat sprijină utilizatorii printr-un sistem de documentare pe tot parcursul acestui proces. Într-o abordare mai detaliată testarea automată înseamnă:

Planificare

identificarea cerințelor și a funcționalităților

gruparea acestora în condiții de test

crearea cazurilor de test pentru aceste condiții

Design

construcția scripturilor de test

generarea testelor de rulare

Execuție

crearea scenariului de rulare a scripturilor

rularea uneltelor monitor pentru înregistrarea datelor

înregistrarea rezultatelor pentru fiecare rulare

raportarea și gestionarea bug-urilor

Management

generarea rapoartelor și graficelor

controlul dintr-un singur punct de comandă

documentarea permanentă a stadiului curent al proiectului

1.3.1 Tipuri de testare automată

Testarea automata este impartita in mai multe tipuri si poate fi constituita din mai multe metode, similar cu cele descrise mai sus in topicul “Metode ale testarii software”, si anume:

testarea structurala (“White Box”)

testarea functionala (“Black Box”)

testarea regresiva – se verifică dacă s-a modificat neașteptat comportamentul aplicației în urma implementării unor noi cerințe/schimbări

testarea negativa – se solicită aplicația, producând deliberat cazuri complicate, neobișnuite sau particulare pentru a forța apariția erorilor

testarea de solicitare – e determină capabilitățile absolute ale aplicației și ale infrastructurii pe care este implementată;

testarea de performanta – în urma acestui tip de testare se verifică dacă performanța aplicației este adecvată pentru cerințele stabilite

testarea de incarcare – se determină punctele slabe ale aplicației și dacă sunt necesare îmbunătățiri ale infrastructurii hardware sau software prin măsurarea caracteristicilor de performanță a principalelor componente ale aplicației web.[2]

1.3.2 Tipuri de de unelte pentru testarea automată

Sistemele de testare automata pot include atat unelte open source cat si aplicatii care nu faciliteaza accesul la codul sursa, ambele fiind extrem de eficiente in procesul de automatizare a testarii software. Se poate face o delimitare succinta si din punct de vedere al mediului in care se desfasoara testarea, si anume: FontEnd, BackEnd sau testarea automata pentru aplicatii Standalone.

Toate cele trei tipuri mentionate mai sus pot folosi unelte, instrumente care fac parte din urmatoaarele categorii:

GUI (Graphical user interface) Interfata grafica , prin folosirea metodei înregistrare/redare

analizoare de cod – analizează codu scris, respectarea unor standarde de scriere a codului

analizoare de memorie – detectează depășirea memoriei alocate, suprascrieri în zone nealocate și zone rămase nedealocate

testare de solicitare/performanță – pentru testarea aplicațiilor web și client/server în diferite scenarii de solicitare

testare servere web – verifică validitatea și integritatea link-urilor, a codului html, programe client-side și server-side, securitatea transmiterii datelor

alte unelte – pentru managementul documentației, raportării bug-urilor, configurației;

1.3.3 Comparatie intre testarea manuala si testarea automata

Testarea automata si testarea manuala sunt doua procese diferite, care pot fi reprezentate drept doua cai diferite de a executa acelasi process. Acest lucru reiese din dinamismul procesului, dar si din modul in care releveaza erorile sau bug-urile.

Exista conditii in care se poate face o delimitare clara intre cele doua moduri de abordare a testarii, fiecare avand timpi cheie de folosinta. Testarea manuala este mai folositoare in situatiile in care este nevoie de tipuri de teste specifice si limitate, in care rezultatele sa fie communicate intr-un timp extrem de scurt. Cum îmbunătățirea calității produsului implică costuri adiționale pentru găsirea bugurilor și gestionarea acestora până la repararea lor definitivă, testarea manuală s-a dovedit a fi în timp extrem de costisitoare. Testarea manuală pe scară largă presupune alocarea de resurse hardware și umane destul de mari, iar riscul să apară erori este amplificat de factorul uman.

Testarea automată necesită un efort inițial mai mare pentru planificarea, organizarea și producerea testului, criteriul principal în obținerea de rezultate bune fiind planificarea atentă, amănunțită și precisă a acestuia. Testarea automată se dorește a fi soluția ideală pentru reducerea timpului de dezvoltare și a costurilor. O echipă de testeri poate să pornească uneltele de testare automată, să le lase să ruleze și în final să colecteze și analizeze rezultatele. Timpul este astfel mai bine organizat și poate fi petrecut pentru izolarea și raportarea bug-urilor.[5]

O alternativă interesantă poate fi si "testare parțială". Această soluție este combinație de testare manuală și testare automată, aceasta din urmă fiind folosită acolo unde se pot obține beneficii maxime.

AVANTAJE

Tabel 1.1 Avantaje Testare Manuala si Testare Automata

Fiind prezentate anterior avantajele testarii manual si automate, in acelasi mod obiectiv vor fi prezentate si dezavantajele.

Dezavantajele testarii automate sunt:

faptul ca este mult mai scump sa automatizezi, investitiile initiale sunt mai mari decat in cazul testarii manuale.

nu se poate automatiza totul, anumite teste trebuiesc facute manual, de testeri.

1.3.4 Procesul testarii automate

Majoritatea uneltelor de testare automată sunt compatibile cu entitățile software ce intervin pe traseul de la clienți la furnizorul de aplicații. În orice punct de pe traseu se pot face teste si evaluări de performanță. În diagrama de mai jos sunt prezentate cele mai cunoscute și utilizate componente software ce intervin într-un astfel de proces. [10]

Figura 1.6 Procesul testarii automate

Cap 2. TEHNOLOGII SI INSTRUMENTE INFORMATICE FOLOSITE

2.1 Selenium WebDriver

Selenium WebDriver este un modul extern NodeJS, open source, care are scopul de a simula un utilizator intr-o pagina web cu roul de a testa, valida pagini web in browser in mod automat prin declararea unor evenimente de anumite etichete HTML. Selenium Webdriver poate introduce date intr-unul sau mai multe campuri din formulare, modaluri sau tabele prezente in pagina web.

Modulul se poate folosi pe oricare browser, cu orice versiune, cu conditia ca acel browser sa prezinte un executabil care poate fi descarcat. In cazul folosirii browser-ului FireFox la sfarsitul script-ului, acesta se va inchide automat.

Inainte de a descrie arhitectura Selenium WebDriver-ului, va ajuta intelegerea conexiunii dintre componentele acestuia. In mare, Selenium reprezinta o suita de 3 instrumente. Prima unealta folosita, si anume Selenium IDE, este o extensie a browser-ului FireFox care permite utilizatorilor sa inregistreze si sa revada teste. Aceasta actiunea de RECORD/PLAYBACK este limitata si nu este potrivita pentru multi utilizatori, aici va interveni cea de-a doua unealta, Selenium WebDriver, asigura un API intr-o varietate de limbaje de programare. Instrumentul final, Selenium Grid, face posibila utilizarea Selenium API-ului pentru a controla instantele browser-ului distribuite peste catevagrid-masini. [16]

De seamenea, Selenium Grid, face posibila rularea in paralel a mai multor teste, lucru util pentru costul testarii unei aplicatii.

Asadar, aceasta tehnologie este o mixture de trei tehnologii Selenium IDE, Selenium Grid, Selenium WebDriver.

Jason Huggins a demarat proiectul Selenium în 2004, în timp ce lucra la ThoughtWorks la propriul sistem de timp și cheltuieli (T & E), care a folosit in deosebi Javascript. Deși Internet Explorer era browserul dominant în acel moment, ThoughtWorks a folosit o serie de browsere alternative (în special variantele Mozilla) și ar fi trimis rapoarte de erori atunci când aplicația T & E nu ar funcționa pe browserul ales. [16]

Instrumentele de testare Open Source de la acel moment au fost fie concentrate pe un singur browser (de obicei IE), fie simulările unui browser (cum ar fi HttpUnit). Costul unei licențe pentru un instrument comercial ar fi epuizat bugetul limitat pentru un mic proiect intern, astfel încât acestea nu au fost nici măcar considerate alegeri viabile de testare.

În cazul în care automatizarea este dificilă, este normal să se bazeze pe testarea manuală. Această abordare nu scaleaza când echipa este foarte mică sau când releas-urile sunt extrem de frecvente. De asemenea, este o risipă de umanitate pentru a cere oamenilor să treacă printr-un scenariu care ar putea fi automatizat. Mai prozaic, oamenii sunt mai lenți și mai predispuși la erori decât o mașină pentru sarcini repetitive plictisitoare. Testarea manuală nu a fost o opțiune.

Deoarece SELENIUM a fost scrisă în Javascript pur, proiectul său inițial a cerut dezvoltatorilor să găzduiască Core și testele lor pe același server ca și aplicația testată (AUT), pentru a evita încălcarea politicilor de securitate ale browserului și a Javascript sandbox. Acest lucru nu a fost întotdeauna practic sau posibil. Mai rău, deși IDE-ul dezvoltatorului le oferă posibilitatea de a manipula rapid codul și de a naviga la o bază de cod mare, nu există un astfel de instrument pentru HTML. A devenit rapid clar că menținerea unui set de teste de dimensiuni medii a fost dificil.

Pentru a rezolva această problemă și alte probleme, un proxy HTTP a fost scris astfel încât fiecare cerere HTTP să poată fi interceptată de Selenium. Folosirea acestui proxy a făcut posibilă parcurgerea a mai multor constrângeri ale politicii de "aceeași origine gazdă", unde un browser nu va permite Javascript să efectueze apeluri către altceva decât serverul de la care a fost difuzată pagina curentă, permițând primei slabiciuni sa fie atenuată. Proiectul a deschis posibilitatea scrierii legărilor Selenium în mai multe limbi: au avut nevoie doar de a putea trimite cereri HTTP către o anumită adresă URL.

Formatul a fost modelat îndeaproape pe sintaxa Selenium Core și, alături de sintaxa table-base, a devenit cunoscută sub numele de "Selenese". Deoarece legăturile lingvistice controlau browser-ul la distanță, instrumentul era denumit "Selenium Remote Control" sau "Selenium RC".

Nu este întotdeauna posibilă legarea strânsă la un anumit browser. În aceste cazuri, WebDriver revine la mecanismul original utilizat de Selenium. Acest lucru înseamnă utilizarea Selenium Core, un cadru Javascript pur, care introduce un șir de dezavantaje pe măsură ce se execută în contextul Javascript sandbox. De la un utilizator al API-urilor WebDriver, aceasta înseamnă că lista browserelor acceptate se încadrează în niveluri, unele fiind bine integrate și oferind un control excepțional, iar altele sunt conduse prin Javascript și oferind același nivel de control ca și originalul Selenium RC.

Figura 2.1 Interacțiunea Selenium –Browser

Unul dintre obiectivele inițiale ale WebDriver a fost de a acționa ca un bloc de construcție pentru alte API-uri și instrumente. Bineînțeles, Selenium nu trăiește în vid: există o mulțime de alte instrumente de automatizare a browserului Open Source. Una dintre acestea este Watir (Web Application Testing in Ruby), iar munca a inceput, ca un efort comun al dezvoltatorilor Selenium si Watir, de a plasa API-ul Watir peste nucleul WebDriver.[16]

2.2 Limbajul HTML

HTML (HyperText Markup Language) este un standard ce descrie formatul primar in care documentele sunt vizibile si distribuite pe Web. Este totodata o forma de marcare orientata catre prezentarea documentelor text pe o singura pagina, utilizant un software de redare specializat numit agent utilizator HTML. HTML furnizează mijloacele prin care conținutul unui document poate fi adnotat cu diverse tipuri de metadate și indicații de redare. [20]

Termenul de hypertext desemneaza un material sub forma de text si imagine, interconectat intro maniera complexa, nesecventiala, in care utilizatorul poate naviga, cauta informatii referitoare la un obiect. Hypertext-ul trebuie interpretat ca un text care semnaleaza o legatura la o alta informatie web, de obicei un alt document web, si este identificat prin subliniere sau culoare, pentru a-l deosebi de textul simplu.

Hypermedia este un termen aproape sinonim celui de hypertext, singura deosebire fiind faptul ca subliniaza prezenta si a unor elemente care nu sunt de tip text, cum ar fi animatii, secvente sonore sau secvente video. [20]

HTML se utilizeaza din 1990, cunoscand cateva versiuni de dezvoltare, fiecare dintre acestea imbunatatind performantele limbajului. Ultima varianta (la data elaborarii acestui ghid) este HTML 4.01. ce include facilitatile versiunilor anterioare (tag-uri de marcare, tag-uri pentru hiperlegaturi, antete, paragrafe, liste, elemente de meniu, formatare caractere, imagini in-line si tag-uri pentru schimbul de date dinamic intre utilizatori), adaugand facilitati si extensii pentru numere, tabele si elemente de control. Un document HTML este format dintr-o succesiune de blocuri de informatie.[21] Aceste blocuri pot fi incluse unul in altul. Un bloc este delimitat de simboluri speciale, numite tag-uri (etichete). Modul in care un document este marcat cu elemente si cu atribute ale acestor elemente se realizeaza in conformitate cu Document Type Definition (DTD – definitia tipului de document). Aceasta contine regulile ce caracterizeaza fiecare tip de document.

Paginile HTML sunt formate din etichete sau tag-uri și au extensia „.html” sau „.htm”. În marea lor majoritate aceste etichete sunt pereche, una de deschidere <eticheta> și alta de închidere </eticheta>.

2.3 Limbajul Java

Java este un limbaj de programare dezvoltat de JavaSost, compania Sun MicroSystems, acum filiala Oracle. Este un limbaj de programare compet orientat obiect si ofera posibilitatea refolosirii codului (acest aspect fiind promisiunea facuta la aparitie programarii orientate obiect O.O.P.).

Putem spune ca Java este neutru din punct de vedere arhitectural, un limbaj de programare independent de platforma de lucru, aceeasi aplicatie putand fi rulata, fara nicio modificare, pe sisteme diferite: Windows, Unix, Linux, Macintoch etc. Acest lucru aduce economii substantiale companiilor care dezvolta software.

Ca si anfitrioni ai acestui limbaj de programare, avem C, C++ trecerea de la C la Java facadu-se foarte usor. Are posibilitatea de a elimina sursele frecvete de erori ce apar in programe prin eliminarea pointerilor, administrarea automata a memoriei si eliminarea fisurilor de memorie printr-o procedura de colectare a trash-ului care ruleaza ca proces de fundal.

Este cel mai sigur limbaj de programare disponibil in acest moment, asigurant mecanisme de securitate a programelor concretizate prin:

verificarea dinamica a codului pentru detectarea secventelor periculoase;

impunerea unor reguli stricte pentru programele lansate pe calculatoarele aflate la distanta

In 1991, firma SUN, mergând pe direc ia dezvoltării sistemelor deschise de lucru în ț re ea, a creat un proiect de lucru numit Green, care avea drept scop punerea la punct a unor ț procesoare care să poată rula pe diferite tipuri de aparate si punerea la punct a unui sistem care sa poata rula pe platforme diferite. Planul initial prevedea dezvoltarea proiectului în C++, dar au apărut foarte multe probleme în încercarea de dezvoltare acompilatorului de C++. Ca urmare, James Gosling, membru al grupului Green, a început să lucreze la dezvoltarea unui nou limbaj, numit Oak, care, mai târziu, avea să se numească Java. De asemenea grupul Green avea sa-si schimbe numele întâi în FirstPerson, apoi în JavaSoft. Abia dupa ce a fost înfiin ata compania Netscape Communications Corporation, cei de ț la JavaSoft s-au orientat către Internet si Web, mediul multiplatforma distribuit al retelei Internet fiind perfect pentru

testarea proiectului. In prezent licen a pentru tehnologia Java a fost acordată unor firme precum IBM, ț Microsoft, Sillicon Graphics, Adobe si Netscape.[19]

Programale scrise in Java pot fi atat interpretate cat si compilate. Interpretorul Java transforma codul din octeti in set de instructiuni-masina. Datorita asemanarii dintre codul de octeti si limbajul de asamblare executia se face aproape la fel de repde ca in cazul programelor compilate.

Java renuntă complet la programarea procedurală specifică C-ului si va obligă să folositi conceptele solide ale POO:

Abstractizarea

Încapsularea

Modularitatea

Ierarhizarea

Abstractizarea este una dintre căile fundamentale prin care oamenii ajung să înțeleagă și să cuprindă complexitatea. Ea scoate în evidență toate detaliile semnificative pentru perspectiva din care este analizat un obiect, suprimând sau estompând toate celelalte caracteristici ale obiectului. În contextul programării orientate pe obiecte, toate acestea se transpun astfel:

obiectele și nu algoritmii sunt blocurile logice fundamentale;

fiecare obiect este o instanță a unei clase. Clasa este o descriere a unei mulțimi de obiecte caracterizate prin structură și comportament similare;

clasele sunt legate între ele prin relații de moștenire.

Încapsularea este conceptul complementar abstractizării. Încapsularea este procesul de compartimentare a elementelor care formează structura și comportamentul unei 2 abstracțiuni; încapsularea servește la separarea interfeței „contractuale” de implementarea acesteia. Din definiția de mai sus rezultă că un obiect este format din două părți distincte:

interfața (protocolul);

implementarea interfeței.

Abstractizarea definește interfața obiectului, iar încapsularea definește reprezentarea (structura) obiectului împreună cu implementarea interfeței. Separarea interfeței unui obiect de reprezentarea lui permite modificarea reprezentării fără a afecta în vreun fel pe nici unul dintre clienți, deoarece aceștia depind de interfață și nu de reprezentarea obiectului-server.[19]

Modularitatea constă în divizarea programului într-un număr de subunități care pot fi compilate separat, dar care sunt cuplate (conectate) între ele. Gradul de cuplaj trebuie să fie mic, pentru ca modificările aduse unui modul să afecteze cât mai puține module. Pe de altă parte, clasele care compun un modul trebuie să aibă legături strânse între ele pentru a justifica gruparea (modul coeziv). Limbajele care suportă conceptul de modul fac distincția între: — interfața modulului, formată din elementele (tipuri, variabile, funcții etc.) „vizibile” în celelalte module; — implementarea sa, adică elemente vizibile doar în interiorul modulului respectiv.

Ierarhizarea reprezintă o ordonare a abstracțiunilor. Cele mai importante ierarhii în paradigma obiectuală sunt:

ierarhia de clase

ierarhia de obiecte

Moștenirea definește o relație între clase în care o clasă folosește structuri și comportamente definite în una sau mai multe clase (după caz vorbim de moștenire simplă sau multiplă). Semantic, moștenirea indică o relație de tip is a („este un/o”). Ea implică o ierarhie de tip generalizare/specializare, în care clasa derivată specializează structura și comportamentul mai general al clasei din care a fost derivată. Agregarea este relația între două obiecte în care unul dintre obiecte aparține celuilalt obiect.

2.4 Limbajul JavaScript

JavaScript este un limbaj de programare care vă permite să implementați lucruri complexe pe paginile web. Javascript cel de-al treilea strat de tehnologie din cohorta HTML, CSS cu ajutorul careia se pot afisa informatii in timp util, harti interactive, animatii 2D/3D pe o pagina web.[18]

Limbajul de bază JavaScript este alcătuită din câteva funcții comune de programare care vă permit să faceți lucruri precum:

Stocare de valori utile in interiorul variabilelor;

Operatii pe fragmente de text;

Rularea codului ca raspuns la anumite evenimente ce apar pe o pagina web;

Cee ace face acest limbaj de programare si mai interesant este interactiunea cu asa-zisele Application Programming Interfaces (APIs). API –urile sunt blocuri de cod gata-facute care permit unui dezvoltator sa implementeze programe, care altfel ar fi greu sau imposibil de implementat. [18]

Aceste API-uri se impart in doua mari categorii: API-uri de browser si Third Party API-uri. Despre prima categorie putem spune ca este construita in “interiorul” web-browser-ului, si este capabila sa expuna date din mediul informatic din jur, de exemplu:

API-ul DOM-ului (Document Object Model) vă permite să manipulați HTML și CSS, să creați, să eliminați și să modificați codul HTML, să aplicați dinamic stiluri noi paginii dvs. Etc. De fiecare dată când vedeți o fereastră pop-up aparand pe o pagină, sau se afișează un conținut nou, DOM-ul este responsabil. [22]

API-ul Geolocation recuperează informațiile geografice. Acesta este modul în care Google Maps poate să vă găsească locația și să o compileze pe o hartă.

API-urile Canvas și WebGL vă permit să creați animații grafice 2D și 3D. Oamenii fac unele lucruri uimitoare folosind aceste tehnologii web.

API-urile audio și video, cum ar fi HTMLMediaElement și WebRTC, vă permit să faceți lucruri interesante cu multimedia, cum ar fi redarea audio și video chiar într-o pagină web.[18]

API-urile Third Party nu sunt incorporate in browser in mod implicit, de ceea trebuie urcat codul si informatiile pe Web. De exemplu:

API-ul Twitter permite sa faceti lucruri precum afisarea celor mai recente tweet-uri pe un site web;

API-ul Google Maps permite incorporaea de harti personalizate pe un site web.

Figura 2.2 JavaScript in Browser

JavaScript este un limbaj interpretat, codul este rulat de sus in jos, iar rezultatul executarii codului este imediat returnat. Codul scris este rulat ca atare, nu trebuie transformat intr-o alta forma. Limbajele compilate, pe de alta parte, sunt transformate inainte de a fi executate de computer. De exemplu C/C++ sunt compilate in limbaje de asamblare, iar apoi sunt rulate pe calculator.[18]

JavaScript este aplicat paginii web in mod similar cu CSS. In timp ce CSS foloseste elemente <link> pentru a aplica straturi de stiluri externe si elemente <style> paginii web, JavaScript are nevoie doar de elementul <script> .

În ciuda numelui și a unor similarități în sintaxă, între JavaScript și limbajul Java nu există nicio legătură. Ca și Java, JavaScript are o sintaxă apropiată de cea a limbajului C, dar are mai multe în comun cu limbajul Self decât cu Java.

JavaScript oferă un tip de date Boolean cu valorile true și false. Operatorul returnează șirul “boolean” pentru aceste tipuri de primitive.Atunci când este utilizat într-un context logic, 0 , -0 , null , NaN , undefined , iar șir vid ( “” ) evaluează în false din cauza constrângerii automate.

Când conversia de tip este necesară, JavaScript convertește String, Number, Boolean, sau operanzilor obiect, după cum urmează: [22]

Șir de caractere este convertit la o valoare număr. JavaScript încearcă să transforme literal șir de caractere numeric, la o valoare tip de număr. În primul rând, o valoare de matematică este derivat din literal șir de caractere numeric. Apoi, această valoare este rotunjită la cea mai apropiată valoare tip de număr.

Dacă unul dintre operanzi este un Boolean, operand Boolean este convertit la 1 dacă este true sau la 0, dacă este false .

Dacă un obiect este comparat cu un număr sau un șir de caractere, JavaScript încearcă să se întoarcă valoarea implicită pentru obiect. Un obiect este convertit la un șir de caractere sau o valoare numerică, folosind .valueOf() sau .toString() metode de obiect. Dacă acest lucru nu reușește, o eroare de execuție este generată.

Experți folosesc termenii “true” și “false” pentru a descrie modul în care valorile de diferite tipuri, se comportă atunci când a evaluat într-un context logic, în special în ceea ce privește cazurile de margine. Operatorii logici binare a returnat o valoare booleană în primele versiuni de JavaScript, dar acum se vor întoarce unul dintre operanzi loc. [22]

2.5 Server-ul Jenkins

Jenkins este un server de integrare continuă. Integrarea continua este practica de a rula teste pe o masina non-dezvoltare, in mpod automat, de fiecare data cand cineva urca cod nou in depoziul de surse. Acest lucru are avantajul extraordinar de a ști mereu dacă toate testele funcționează și de a obține feedback rapid.[13] Feedback-ul rapid este important, astfel încât să se stie întotdeauna imediat după ce a picat constructia unu build (modificările care au făcut fie ciclul de compilare / construire, fie încercările nu reușesc) motivul si modul de reversie.

Daca testele se executa ocazional, iar intre timp s-au produs extrem de multe schimbari in cod, va fi destul de greu sa se afle cauza problemei. In schimb, cand testele sunt rulate in mod automat la fiecare urcare a codului in sursa, va fi evident ce si cine a introdus problema.

Jenkins este un instrument de automatizare cu sursă deschisă, scris în Java, cu pluginuri construite în scopul integrării continue. Jenkins declanșează o construcție pentru fiecare schimbare făcută în depozitul de cod sursă, de exemplu, depozit Git. Odată ce codul este construit, acesta se implementează pe serverul de testare pentru testare. Echipele îngrijorate sunt în permanență informate despre rezultatele construirii și a testelor. În cele din urmă, Jenkins implementează aplicația de construire pe serverul de producție. [13]

Cu Jenkins, organizațiile pot accelera procesul de dezvoltare a software-ului prin automatizare. Jenkins integrează procesele de dezvoltare a ciclului de viață de toate tipurile, inclusiv construirea, documentarea, testul, pachetul, stadiul, implementarea, analiza statică și multe altele.

Jenkins ofera urmatoarele caracteristici in pachet si multe altele pot fi adaugate prin plugin-uri:

Instalare simplă: Doar rulați java –jar jenkins.war, implementați-o într-un container de servlet.

Configurare simplă: Jenkins poate fi configurat în întregime din GUI-ul prietenos pe web cu controale extinse de eroare și asistență online.

Rich ecosystem plugin: Jenkins se integrează cu aproape orice instrument SCM sau construit care există.

Extensibilitate: cele mai multe părți ale lui Jenkins pot fi extinse și modificate și este ușor să creați noi pluginuri Jenkins. Acest lucru vă permite să personalizați Jenkins la nevoie.

Construcții distribuite: Jenkins poate distribui sarcini de construire / testare la mai multe computere cu sisteme de operare diferite. Crearea de software pentru OS X, Linux și Windows este posibila.

2.6 TestNG si Maven

TestNG este un cadru de testare conceput pentru a simplifica o gamă largă de cerințe de testare, de la testarea unității (testarea unei clase în izolare a celorlalte) la testarea integrării (testarea sistemelor întregi formate din mai multe clase, mai multe pachete și chiar mai multe cadre externe, Servere de aplicații).[17]

Scrierea unui test este de obicei un proces în trei etape:

Scrierea logicii testului și introducerea adnotărilor TestNG în cod.

Adăugarea informațiilor despre test (de exemplu, numele clasei, grupurile etc.) într-un fișier testng.xml sau în build.xml.

ExecutareaTestNG.

Conceptele utilizate în această documentație sunt următoarele:

Suita este reprezentată de un fișier XML. Acesta poate conține unul sau mai multe teste și este definit de eticheta <suite>.

Un test este reprezentat de <test> și poate conține una sau mai multe clase TestNG.

Clasa TestNG este o clasă Java care conține cel puțin o adnotare TestNG. Acesta este reprezentat de eticheta <class> și poate conține una sau mai multe metode de testare.

Metoda de testare este o metodă Java adnotată de @Test în sursa dvs.

Un test TestNG poate fi configurat prin adnotări @BeforeXXX și @AfterXXX care permite efectuarea unor logici Java înainte și după un anumit punct, aceste puncte fiind oricare dintre elementele enumerate mai sus.[17]

Informații de configurare pentru o clasă TestNG:

@BeforeSuite: Metoda adnotată va fi rulată înainte ca toate testele din această suită să se execute.

@AfterSuite: Metoda adnotată va fi rulată după executarea tuturor testelor din această suită.

@BeforeTest: Metoda adnotată va fi rulată înainte ca orice metodă de testare care aparține claselor din eticheta <test> să fie rulată.

@AfterTest: Metoda adnotată va fi rulată după ce toate metodele de test aparținând claselor din eticheta <test> au fost executate.

@BeforeGroups: Lista de grupuri pe care aceasta metoda de configurare o va rula inainte. Această metodă este garantată să se execute cu puțin înainte ca prima metodă de testare care aparține oricăruia dintre aceste grupuri să fie invocată.

@AfterGroups: Lista grupurilor pe care această metodă de configurare o va rula după. Această metodă este garantată să se execute la scurt timp după ce se invocă ultima metodă de testare care aparține oricăruia dintre aceste grupuri.

@BeforeClass: Metoda adnotată va fi rulată înainte de a fi invocată prima metodă de testare din clasa curentă.

@AfterClass: Metoda adnotată va fi rulată după ce au fost executate toate metodele de testare din clasa curentă.

@BeforeMethod: Metoda adnotată va fi rulată înainte de fiecare metodă de testare.

@AfterMethod: Metoda adnotată va fi rulată după fiecare metodă de testare.[15]

Comportamentul adnotărilor în superclajul unei clase TestNG: Adnotările de mai sus vor fi, de asemenea, onorate (moștenite) atunci când sunt plasate pe o superclasă a unei clase TestNG. Acest lucru este util, de exemplu, pentru a centraliza configurarea testului pentru mai multe clase de test într-o superclasă comună.

În acest caz, TestNG garantează că metodele “@Before” sunt executate în ordine de moștenire (mai întâi superclasa cea mai înaltă, apoi coborârea lantului de moștenire) și metodele “@After” în ordine inversă (urcând în lanțul mostenirii).

Maven, produs Apache, reprezintă un instrument de gestiune a unui proiect software. Gestiunea cuprinde construirea, raportarea și documentarea unui proiect, bazându-se pe conceptul de POM (Project Object Model). Un POM este unitatea fundamentală de lucru în Maven și este de fapt un fișier XML, ce conține informații despre proiect și detaliile de configurare, folosite în construirea proiectului.[15]

Maven este unul dintre cele mai cunoscute project builder-e, alături poate de Ant, un produs tot Apache. Deosebirile majore între acestea două constau în faptul că Ant este orientat doar spre procesare, compilare, împachetare, testare și distribuție. Pe lângă capabilitățile de build, amintite anterior, Maven poate rula rapoarte, genera rapoarte sau facilita comunicarea între membrii unei echipe de lucru.

2.7 GitLab

GitLab Inc. este o companie bazată pe proiectul open-source GitLab. GitLab este o aplicație de codificare, testare și implementare a unui cod împreună. Oferă gestionarea depozitului Git cu controale de acces cu granulație fină, recenzii de cod, urmărirea problemelor, feed-uri de activitate, wiki-uri și integrare continuă.

Software-ul a fost scris de Dmitriy Zaporozhets și Valery Sizov din Ucraina. Codul este scris în Ruby. Ulterior, unele părți au fost rescrise în Go. Începând cu decembrie 2016, compania are 150 de membri ai echipei și mai mult de 1400 de contribuabili open source. Este utilizat de organizații precum IBM, Sony, Centrul de Cercetare Jülich, NASA, Alibaba, Invincea, O’Reilly Media, Leibniz-Rechenzentrum (LRZ) și CERN. [12]

Atunci când colaborăm cu alte persoane la un același proiect este necesară folosirea unui sistem de versionare a surselor. Acesta ajută pentru a putea colabora la distanță și rezolvă problemele de partajare ale acelorași surse. Chiar și în cazurile în care suntem singurul dezvoltator al unui proiect, versionarea este indicată pentru că:

ajută la identificarea mai ușoară a schimbării care a introdus un bug

permite salvarea surselor în diferite stagii ale dezvoltării

permite revenirea la o versiune anume a surselor

Câteva exemple de sisteme de versionare sunt:

SVN

Mercurial

Git

GitLab oferă un tablou de bord care permite echipelor să măsoare timpul necesar pentru a trece de la o idee la o producție. GitLab poate furniza aceste date deoarece are toate instrumentele încorporate: de la idee, la IC, la revizuirea codului, pentru a fi implementate în producție. GitLab poate importa proiecte și probleme din mai multe surse (GitHub, BitBucket, Google Code, FogBugz, Gitea și de la orice adresă git) decât GitHub sau orice alt VCS. [14]

Cap 3. STUDIU DE CAZ: FRAMEWORK PENTRU TESTAREA AUTOMATĂ A APLICAȚIIOR WEB

3.1 Mediul de testare automată: http://phptravels.com

Procesul de automatizare este unul complet, care trece prin diferite faze pentru automatizarea cazurilor si topicurilor de test din cadrul aplicatiei. Automatizarea testelor ar trebui sa inceapa fparte devreme in ciclul de viata al proiectului, iar succesul acesteia depinde de:

Cunoașterea ciclului de viață al automatizării

Procese în automatizarea testării

Selectarea instrumentului potrivit

Planificarea automatizării testelor

cunoștințe tehnice adecvate privind automatizarea și instrumente de automatizare

Mediul de testare automata, software-ul care urmeaza a fi testat este principalul pilon din cadrul procesului, intrucat telul automatizarii este ca in urma rularii testelor acesta sa fie cal mai calitativ. Mediul de testare propus este unul open source, o aplicatie conceputa pentru a fi testata automat, cu scopul de practica.

Aplicatia poate fi gasita la: http://phptravels.com/demo/, iar ea este o pseudo-companie care se ocupa cu industra online de calatorii si rezervari. PHPTRAVELS este o companie bazata pe software-ul Lahore, din Pakistan . Scopul ei este de a oferi un mediu de testare real, functional si in continua schimbare pentru inginerii de calitate sau pasionatii de testare manuala sau automata.

Arhitectura aplicatiei este una robusta si foarte stabila in anumite puncta cheie. Dezvoltarea acesteia a fost facuta pe 3 nivele principale:

Aplicatia Front-End

Aplicatia Back-End

Aplicatia Supplier Back-End

Figura 3.1 Pagina Principală

Când discutăm despre front-end , vorbim despre acea parte a site-ului sau a aplicației web, pe care o putem vedea și cu care interacționează vizitatorii. Front-End-ul are două părți: design-ul (partea creativă) și dezvoltarea interfeței (partea de cod sau implementare HTML CSS).

Asadar, prima parte a aplicatiei este partea interactiva, partea G.U.I. in care server-ul Selenium va actiona la nivel de browser. Aici sunt prezente toate unitatile de design ale interfetei-client. Interfata este una interactica, bazata pe componente de MaterialUI.

Structura Front-End-ului este intuitiva si formata din:

Bara principala cu pagini

Pagina de Login

Sectiunea de comentarii

Motorul de cautare

Meniul de oferte

Aplicatiile interne

Gadjet-urile

Sectiunea paltilor

Figura 3.2 FrontEnd

Fiecare sectiune poate fi accesata separat din interfata prezenta pe pagina “Home”, dar si din arborele principal al aplicatiei prezent in partea de jos a fiecarei pagini (Flights, Hotels, Tours, Offers, Blog etc.).

Din punct de vedere visual, cand o cautare va fi initiata se va astepta un raspuns clar din partea componentei actionate. Un caz pozitiv de test pentru motorul principal de cautare ar fi:

Pasi de reproducere a testului:

Se va cauta input-ul denumit Locatie

Actiunea Click va fi desfasurata in input-ul acesteia;

Se va performa actiunea de scriere in interiorul input-ului nou deschis;

Se va alege elementul din lista aparuta in functie de compatibilitatea cautarii anterioare;

Actiunea Click va fi performata pe butonul de cautare

Dintre optiunile oferite, se va alege a doua.

Pentru primul pas din cadrul acestui scenariu de test, rezultatul pozitiv la care se asteapta este de gasire a elementului denumit “Locatie” in pagina web, implicit in DOM. In cazul in care aceasta actiunea s-a incheiat cu success, se va trece la urmatorul pas.

In cazul in care cerinta precedenta este finilizata cu succes, urmatorul pas este de a actiona cu ajutorul evenimentului “click” pe input-ul locatiei. Aceasta situatie poate avea mai multe rezultate din punct de vedere al testarii automate:

Input-ul exista si poate fi gasit in DOM, dar nu dispobil pentru actiunea “click”;

Input-ul nu exista visual, dar acesta este prezent in DOM;

Input-ul este vizibil, poate fi gasit in DOM, este disponibil pentru a performa actiunea “click”;

Dupa cum a fost prezentata aceasta situatie, se poate observa faptul ca fiecare actiune va fi verificata de catre framework-ul de testare automata, iar ca pasul de test sa fie considerat unul trecut cu succes, fiecare etapa de verificare trebuie sa fie valida.

Daca pasii anterior de reproducere a testului au trecut cu success, iar cel prezent nu a reusit, ceilalti pasi nu se vor mai executa intrucat funstionalitatea testata este un inlantuita, iar pasii depind unii de ceilalti. Un exemplu elocvent poate fi faptul ca actiunea de scriere nu este posibila atunci cand actiunea de click nu este posibila. Focus-ul trebuie sa fie mentinut pentru a performa si introduce date in input, iar acest lucru poate fi posibil doar cu actiunea de “click”.

Datele de intrare trebuiesc sa fie de asemenea valide si verificate in timpul procesarii cererilor, si dupa incheierea actiunilor cu acestea.

Dupa finalizarea cu succes a cautarii locatiei, urmatorul pas ales este de alegere a hotelui. O lista cu hoteluri va aparea in partea de jos a paginii, insotita cu diverse descrieri ale acestora. Alegerea unui hotel va conduce, in caz ideal, la o pagina cu detalii despre acesta.

Redirectionarea spre pagina de detalii va putea fi verificata prin 3 procedee simultan:

Redirectionarea cu success va duce la modificarea URL-ului, adaugandu-se un nou parametru cu numele hotelului ales

Figura 3.3 Link pentru verificare

Din punct de vedere vizual si din punct de vedere al continutului paginii, textele trebuie sa coincida cu textele din cautare (chiar si din punct de vedere al limbii alese)

Figura 3.4 Pagina Detalii Hoteluri

Autentificarea si autorizarea sunt necesare daca o pagina Web trebuie sa fie accesata doar de anumiti utilizatori. Autentificarea in sine asigura ca cineva este cine pretinde ca este. De obicei, este nevoie de un nume de utilizator si o parola, dar poate include si alte metode pentru demonstrarea identitatii, precum smart card, amprente, etc. Autorizarea este calea prin care o persoana, o data ce a fost identificata (autentificata), are permisiunea sa acceseze/modifice anumite resurse. Acest lucru se face de obicei verificand daca respectiva persoana are un anumit rol care are permisiunea de a accesa resursele in cauza.

Asadar, Login-ul unei pagini web este vital sa fie stabil si ferit de vulnerabilitati. Un scenariu de test al obligatoriu al paginii de Login este urmatorul:

Verificați dacă ecranul de conectare are opțiunea de a introduce numele de utilizator și parola cu butonul de trimitere și opțiunea de parolă uitată

Verificați că utilizatorul poate să se autentifice cu un nume de utilizator și o parolă valide

Verificați că utilizatorul nu se poate conecta cu numele de utilizator și parola nevalide

Verificați dacă mesajul de validare este afișat în cazul în care utilizatorul renunță la câmpul de utilizator sau parolă ca necompletat

Verificați dacă mesajul de validare este afișat în cazul în care utilizatorul depășește limita de caractere a câmpurilor de nume de utilizator și de parolă

Verificați dacă există buton de resetare pentru a șterge textul câmpului

Verificați dacă există o casetă de selectare cu eticheta "memorați parola" în pagina de conectare

Verificați dacă parola este în formă criptată atunci când ați introdus-o

Verificați dacă există o limită a numărului total de încercări nereușite

Din punct de vedere al securității, în cazul în care există acreditări corecte, utilizatorul afișează mesajul "nume de utilizator sau parolă incorecte" în locul mesajului exact care indică un câmp care este incorect. Întrucât mesajul precum "numele de utilizator incorect" va ajuta hackerul în bruteforcing câmpurile unul câte unul

Verificați timpul de expirare al sesiunii de autentificare

Verificați dacă parola poate fi copiată sau nu

Verificați că, odată ce v-ați conectat, faceți click pe butonul înapoi nu deconectează utilizatorul

Verificați dacă atacurile SQL Injection funcționează pe pagina de conectare

Verificați dacă vulnerabilitatea XSS funcționează pe pagina de conectare

Aplicatia Back-End, denumita generic si pagina Admin, reprezinta unealta interna cu ajutorul careia se monitorizeaza si actioneaza pagina Front-End. La nivelul acestei parti ale aplicatiei PHPTRAVELS, sunt prezente rapoarte cu privire la numarul de utilizatori ai aplicatiei Front-End, la rolurile pe care utilizatorii le detin, iar ca actiuni, la acest nivel se adauga sau se scot functionalitati si oferte.

Aici se pot adaunga noi hoteluri, masini, oferte, zboruri, locatii si pot fi vizionate mesajele clientilor. Practic, aici prinde contur tot ceea ce un client poate vedea de-a lungul turului sau in PHPTRAVELS.

Structura aplicatiei Admin este una de tip arbore, nivelul 0 fiind nivelul Super Admin. Turul acesteia poate fi inceput accesand meniul principal, care redirectioneaza utilizatorul spre fiecare componenta existenta.

Figura 3.5 Meniul Aplicatiei BackEnd

Managementul utilizatorilor se face prin impartirea succincta in urmatoarele roluri:

Admini

Furnizori

Clienti

Clienti-Musafir

Admin-ul are drepturi depline in aplicatie, el poate adauga noi utilizatori, clienti sau clienti-musafir. Dar, totodata ii poate si scoate din aplicatie.

Figura 3.6 Baza de date cu clienti

Aplicatia prezinta de asemenea un portal de Login pentru autentificare, care prezinta aceeasi functionalitate cu cea de FrontEnd.

Aplicatia Supplier-BackEnd este similara cu cea prezentata anterios din punct de vedere al utilizarii. Aici se autentifica furnizorii de servicii pentru a vedea numarul de utilizatori care au accesat ofertele disponibile, mesajele primite, disponibiliatea camerelor etc

Figura 3.7 Aplicatia Supplier

3.2 Arhitectura si descrierea detaliata sistemului de testare automata

3.2.1 Framework-ul

Un framework pentru testarea automata a aplicatiilor web este o incercare de a simplifica si de a accelera scrierea codului utilizand recuperarea. Incepe cu idea data de noile generatii de smart-scripturi, si anume, conceptul de: “Nu copia codul, ci refactorizeaza-l”. Framework-ul extinde acest concept la o altitudine mai mare: “Nu creati un algoritm optional, create o regula!” De asemenea, se lasa in urma abordarea procedural de a apela script-uri si se inlocuieste cu o metoda mult mai functionala care creeaza functii cu parametri.

Se propune folosirea functiilor pentru a asigura reutilizarea. Următorul pas este organizarea acestor funcții în biblioteci separate, care ajută la menținerea funcțiilor mai bine gestionate și organizate. Încercăm să clasificăm funcțiile în categorii distincte. Modul în care se face această clasificare ne conduce la conceptul de niveluri. Mai intai de toate, conceptual, scripturile sunt „rupte” in ceea ce vom numi generic pasi de navigare. Pasi precum login-ul.

Solutia propusa de automatizare a testarii este alcatuita din 4 componente majore:

Framework-ul,

Conținutul,

Interfața cu utilizatorul,

Generatorul de rapoarte.

Framework-ul de testare automata este de obicei definit ca un set de presupuneri, concept, practici utilizate pentru a oferi suport pentru testarea automata a unui produs software. Framework-ul este baza unei soluții de automatizare. Acesta se ocupă de alocarea resurselor, execuția testelor, validarea opțiunilor selectate și gestionarea mediului de testare utilizat. Este foarte important să utilizăm un framework care se potrivește atât cu tipul automatizării propuse cât și cu produsul testat.

Pentru a executa teste automate pe un asemenea produs ca PHPTRAVELS avem nevoie de un framework ce poate gestiona un mediu de testare cu multi-platformă. Solutia propusa se bazeaza pe un framework dezvoltat in jurul ideii de componente reutilizabile denumite pseudo-servicii.

Dupa cum a fost mentionat anterior, framework-ul este constituit din functii, biblioteci si metode separate pentru a oferi suport pentru testarea automata a unui produs software. Din punct de vedere arhitectural, solutia este impartita pe mai multe straturi:

Bibliotecile,

Clasele,

Resursele,

Dependintele.

Solutia fiind totodata si un proiect de tip Maven, arhitectura framework-ului poate fi privita chiar si din acest unghi, avand o structura dupa cum urmeaza:

Pachetul .idea

Librariile

Pachetul src

Clasele Java

Resursele

Pachetul target

Fisierul pom.xml

Librariile externe

Figura 3.8 Arhitectura Framework Figura 3.9 Pachetul .idea

Figura 3.10 Pachetul src Figura 3.11 Librariile Externe

Resursele si dependintele pentru plugin-uri, dependintele folosite pentru a executa testele, cele specifice TestNG din suitele XML de teste sunt sunt prezente in fisierul pom.xml.

Fișierul pom.xml este nucleul configurației unui proiect în Maven. Este un singur fișier de configurare care conține majoritatea informațiilor necesare pentru a construi un proiect exact așa cum doriți. POM este imens și poate fi descurajator în complexitatea sa. Pom.xml-ul acestui proiect va fi prezentat in urmatoarele linii de cod:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>com.testing.websitetesting</groupId>
<artifactId>selenium-test</artifactId>
<version>1.0-SNAPSHOT</version>
<build>
<plugins>
<!– Compiler plug-in –>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<!– Below plug-in is used to execute tests –>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.18.1</version>
<configuration>
<suiteXmlFiles>
<!– TestNG suite XML files –>
<suiteXmlFile>testng.xml</suiteXmlFile>
</suiteXmlFiles>
</configuration>
</plugin>
</plugins>
</build>

<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-server</artifactId>
<version>3.3.1</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>3.3.1</version>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.9.4</version>
</dependency>
</dependencies>

</project>

Pentru a reusi sa se creeze o solutie calitativa de testare automata nu este suficienta folosirea metodelor propuse de Selenium WebDriver. Se vor detalia metodele folosite de WebDriver, impreuna cu sintaxele si modul de functionare:

get(url)

Acesta va încărca o nouă pagină web în fereastra browserului curent. Acest lucru se face folosind o operație http get, iar metoda se va bloca până când încărcarea este completă. URL-ul de încărcat ar trebui să fie un URL complet si correct.

findElements(By By)

Aceasta metoda cauta toate elementele din pagina curenta, utilizant parametri cei ii sunt atribuiti. By reprezinta mecanismul de localizare utilizat.

Metoda a fost suprascrisa in framework-ul propus iar pe baza ei au fost create alte metode care se comporta adecvat la cautarea unui element in pagina.

public boolean isElementOfGroupVisibleNoImplicit(By groupLocator, int nthChild) {
boolean result = false;
//Wait so everything is loaded before acting on it
this.waitForPageLoadFully();
driver.manage().timeouts().implicitlyWait(0, TimeUnit.SECONDS);
List<WebElement> elements = this.getWebElements(groupLocator);
if (elements != null && elements.size() >= nthChild) {
WebElement element = elements.get(nthChild – 1);
result = element.isDisplayed();
}
driver.manage().timeouts().implicitlyWait(3, TimeUnit.SECONDS);
return result;

Metoda suprascrisa asteapta incarcarea tuturor elementelor in pagina inainte de a incepe cautarea propriu-zisa a elementului. Exista numeroase cazuri in care, metodele Selenium nu asteapta suficient timp, iar elementele cautare nu sunt gasite, desi ele sunt prezente in DOM, din cauza faptului ca pagina inca se incarca sau incearca sa se stabilizeze.

Din aceasta cauza, testele pica, iar motivele sunt actiunile facute de metodele Selenium.

public By waitForOneOfTheElementsVisible(By… selectors) {
By result = null;
for (int i = 0; i < 40; i++) {
for (By selector : selectors) {
try {
if (this.isElementVisibleNoImplicit(selector)) {
result = selector;
break;
}
} catch (TimeoutException e) {
result = null;
}
}
if (result == null) {
try {
Thread.sleep(500);
} catch (InterruptedException ignored) {
}
}
}
return result;
}

O alta metoda suprascrisa foloseste ca si radacina metodele Selenium, imbunatatindu-le considerabil. Aceasta metoda asteapta ca un element dintr-un grup, dintr-o serie de elemente sa fie vizibil in pagina. Deci, intervine aici conceptul de vizibil. Un element este vizibil in pagina daca atributul sau de dimensiune are o valoare numerica ce depășește 0 pixeli.

Aceasta metoda asteapta pana la 20 de secunde maxim pentru vizibilitatea elementului, apoi se intrerupe pentru evitarea unui ciclu cotinuu de rulare, pentru evitarea unui loop.

public boolean waitForElementsVisiblePresent(int timeout, By… selectors) {
boolean result = true;
if (selectors != null) {
for (int i = 0; i < selectors.length && result; i++) {
try {
result = this.waitForVisiblePresence(selectors[i], timeout) != null;
} catch (TimeoutException | Error e) {
result = false;
}
}
}
return result;
}

Metoda waitforElemetVisiblePresent prezinta functionalitatea metodei anterioaare, insa este structurata in gasirea si asteptarea unui singur element Web.

public List<WebElement> findElementsNoImplicit(By locator) {
List<WebElement> results;
driver.manage().timeouts().implicitlyWait(0, TimeUnit.SECONDS);
results = driver.findElements(locator);
driver.manage().timeouts().implicitlyWait(3, TimeUnit.SECONDS);
return results;
}

Chiar si metoda click() a fost suprascrisa intrucat aceasta nu este stabila utilizata in noile tehnologii web. Metoda click() a Selenium, practica actiunea de click, doar in mijlocul elementului, impartindu-l in coordonate.

public void mouseClick(By selector) {
List<WebElement> elements = this.getWebElements(selector);
if (elements != null && elements.size() == 1) {
this.mouseClick(elements.get(0));
} else {
throw new Error("None or to many elements found for " + selector.toString());
}
}

Toate aceste metode au fost suprascrise, si multe altele, reusind sa se compuna mixture de metode care se comporta foarte stabil in mediul Web. Clasa care detine toate aceste metode, clasa cea mai importanta din framework care constituie solutia generala de automatizare este denumita ActionDriver.

ActionDriver reprezinta o solutie general valabila pentru testarea automata, indiferent de mediile in care se executa testarea, indiferent de versiuile tehnologiilor web folosite. Metodele din care este construita clasa sunt versatile si abstracte, iar parametrii acestora nu variaza.

ActionDriver este utilizata ca si Singleton. Pattern-ul Singleton este utilizat pentru a restricționa numărul de instanțieri ale unei clase la un singur obiect, deci reprezintă o metodă de a folosi o singură instanță a unui obiect în aplicație. Asadar, ActionDriver va fi util si in urmatoarele conditii:

ca un subansamblu al altor pattern-uri

obiectele care reprezintă stări

în locul variabilelor globale. Singleton este preferat variabilelor globale deoarece, printre altele, nu poluează namespace-ul global cu variabile care nu sunt necesare.

obiecte de tip logger

obiecte care reprezintă resurse partajate (conexiuni, sockets etc.)

obiecte ce conțin configurații pentru aplicație

pentru obiecte de tip Factory

Folosind JavaScript, aplicatiile si softwarele web sunt din ce in ce mai prietenoase utilizatorilor, utilizand animatii 2D sau 3D. In aceasta situatie, testare este mai dificila, intrucat pentru a accesa un element si petru a actiona asupra lui, trebuie ca elementul sa fie vizibil, capabil de a primi click, preset in DOM, sis a nu fie in spatele niciunei animatii.

Animatiile sunt introduse prin parametrii style si transition in DOM, iar acestea pot altera focus-ul impus de server-ul Selenium. Spre exemplu, elementul a fost gasit si este vizibil, insa nu se poate actiona asupra lui intrucat se misca datorita sau din cauza unei animatii.

Din acest motiv au fost create metodele scrise in JavaScript: transitionAnimationCancel(By) si transitionAnimationCancel(Webelement) cu scopul de a impiedica aceste sincope:

De asemenea, in JavaScript, au fost scrise si urmatoarele metode care seteaza Cookie-urile din browser la o valoarea aleasa de utilizatorul testelor, acceseaza Logurile de retea si reseteaza Local Storage-ul.

In momentul in care testele sunt rulate in slave-ul server-ului Jenkins, se intampla ca din cauza mediului de testare, testele sa pie, iar local, la nivelul utilizatorului, testele sa se termine cu success. Aici poate fi de mare ajutor o metoda special create pentru a face screenshot-uri in anumite puncta critice ale aplicatiei.

Metoda creata in ActionDriver se numeste takeScreenshot(), si are ca parmetrii: directorul in care se vor salva imaginile, numele directorului current si numele propriu-zis al imaginii:

O clasa importanta la nivelul Framework-ului este de asemenea si FirstTestCase, care este inclusa in pachetul basetest. La nivelul acestei clase Java, Singleton-ul definit in ActionDriver este instantiat si folosit pentru toate clasele ce vor extinde FirstTestCase. Una dintre cele mai bune practici este folosirea instantierii Singleton-ului la acest nivel, intrucat nu mai este necesara o alta instantiere la nivelul aplicatiei. Altfel spus, o alta alegere ar fi fost instantierea Singleton-ului la inceputul fiecarei clase din Framework, asta insemnand foarte mult cod duplicat.

Aici, server-ul Selenium este setat impreuna cu executabilul browser-ului. Framework-ul foloseste in mod predefinit browser-ul FireFox. Aplicatia isi propune la acest nivel folosirea browser-ului Chrome.

Dupa ce executabilul Chrome a fost gasit la nivelul sistemului de operare, oferind ca parametrii de cautare calea harcodata spre acesta, o instanta de browser va fi deschisa si maximizata in functie de rezolutia computerului pe care se ruleaza testele. Odata ce browser-ul a fost deschid parametrul pentru navigare va fi trimis, si anume http;//phptravel.com/demo.

Metoda setUP() prezenta in clasa FirstTestCase, datorita adnotarii specifice de TestNG va putea fi rulata la inceputul fiecarui test, rezultand un mediu de testare curat si stabil, prin simpla extindere a clasei FirstTestCase.

In cazul in care vor aparea diferite erori din cauza conexiunii la internet, sau URL-ul de navigare nu va fi valid, sau calea harcodata spre chromedriver.exe nu va mai exista, exceptia rezultata va fi afisata in consola cu ajutorul Exception e. Acest lucru va ajuta la o mai buna depanare a testelor sau a mediului in care se desfasoara acestea.

Clasele specifice fiecarei functionaliate a aplicatiei PHPTRAVELS fac parte de asemenea din framework-ul de automatiza a testarii. Ele sunt construite in functie de prioritatile testarii, in sensul in care, le nivelul fiecarei aplicatii exista anumite componente vitale care trebuiesc sustinute permanent in productie, cu alte cuvinte, anumite compoente este vital sa nu se strice niciodata.

Un bun exemplu ar fi clasa MainApplication ale carei metode vor fi folosite de testele ce vor verifica si valida meniul principal de intrare in aplicatie:

FrontEnd

BackEnd

Supplier

Daca aceasta compoeneta a aplicatiei PHPTRAVELS nu ar functiona, intreaga aplicatie nu ar putea fi folosita, si nici macar vizualizata.

Elementele din pagina principala a produsului vor fi identificate in mod unic cu ajutorul CSS selectorilor de la nivelul DOM-ului. Prima parte a clasei, este partea de declarare a elementelor care vor fi cautate, validate, verificate si asupra carora se vor exercita diferite actiuni (click, scriere, stergere, dublu-click etc.)

Elementele vor fi cautate in DOM, apasand tasta F12. Identificatorii vor trebui sa fie unici la nivelul paginii, astfel incat adresarea catre obiectul cautat sa se finalizeze cu succes. La fel cum focusul pentru click nu poate fi activ in doua instante simultan, la nici doua sau mai multe elemente nu pot fi accesate simultan.

Figura 3.12 DOM

Pentru a gasi selectorul primului buton din pagina, vom cauta in arborele DOM-ului atribute CSS sau HTML prin care sa fie identificat. Cazul ideal este de a gasi atributul ID, insa de putine ori este posibil acest lucru. Odata gasit atributul, sau inlantuirea de atribute, printr-o comanda de JavaScript se va putea verifica daca identificatorul este unul valid si unic.

Comandata document.querySelectorAll() primeste ca parametru selectorul cautat in DOM. Daca acesta este valid si unic, in consola va fi afisat elementul cauta, iar in pagina acesta va fi selectat pentru a iesi in evidenta.

Figura 3.13 Cautarea Selectorilor

Asadar, elementele fiind gasite in pagina, vor putea fi verficate si validate folosind metodele din interiorul Framework-ului. Clasa MainApplication contine 3 metode principale care navigheaza pe rand pe fiecare dintre cele 3 parti ale PHPTRAVELS.

Butoanele de navigare vor fi cautate in pagina, daca vor fi gasite vor fi actionate cu “click”, apoi pagina meniului principal fiind schimbata cu paginile FronEnd, BackEnd sau Supplier (in caz ideal) se va astepta ca butoanele de navigare sa dispara, fapt care asigura schimbarea paginii Main.

O alta componenta importanta fara de care produsul nu ar putea fi folosit de utilizatori este navigarea intre paginile aplicatiei FrontEnd. Clasa in care metodele pentru validarea navigarii au fost scrise se numeste MainPages.

package com.imargalinoiu.websitetesting.basic.mainpages;

import com.imargalinoiu.websitetesting.basic.webdriver.ActionDriver;
import org.openqa.selenium.By;

/**
* Created by Isabela on 4/10/2017.
*/
public class MainPages {
protected final ActionDriver action;
public MainPages(ActionDriver action) {
this.action = action;
}

protected static final By HOME_PAGE = By.cssSelector("body > nav.navbar.navbar-default.navbar-orange > div > div > div > ul > li:nth-child(1)");
protected static final By HOTELS_PAGE = By.cssSelector("body > nav.navbar.navbar-default.navbar-orange > div > div > div > ul > li:nth-child(2)");
protected static final By FLIGHTS_PAGE = By.cssSelector("body > nav.navbar.navbar-default.navbar-orange > div > div > div > ul > li:nth-child(3)");
protected static final By TOURS_PAGE = By.cssSelector("body > nav.navbar.navbar-default.navbar-orange > div > div > div > ul > li:nth-child(4)");
protected static final By CARS_PAGE = By.cssSelector("body > nav.navbar.navbar-default.navbar-orange > div > div > div > ul > li:nth-child(5)");
protected static final By OFFERS_PAGE = By.cssSelector("body > nav.navbar.navbar-default.navbar-orange > div > div > div > ul > li:nth-child(6)");
protected static final By BLOG_PAGE = By.cssSelector("body > nav.navbar.navbar-default.navbar-orange > div > div > div > ul > li:nth-child(7)");
protected static final By CONTACT_US_PAGE = By.cssSelector("body > nav.navbar.navbar-default.navbar-orange > div > div > div > ul > li:nth-child(8)");
protected static final By SEARCH_GROUND_HOME_PAGE = By.cssSelector(".searchground");
protected static final By SEARCH_GROUND_HOTELS_PAGE = By.cssSelector(".searchbox");
protected static final By SEARCH_BUTTON_FLIGHTS_PAGE = By.cssSelector("#flights-form-whitelabel_en > div.mewtwo-flights-submit_button > button");
protected static final By TOURS_GROUND_HOTELS_PAGE = By.cssSelector(".searchbox");
protected static final By SEARCH_BUTTON_CARS = By.cssSelector("#frmModal > form > div:nth-child(9) > input.btn.btn-lg.btn-primary.green.btn-block");
protected static final By LIST_OFFERS_PAGE = By.cssSelector(".rightcontent.col-md-9.pl15pr0");
protected static final By LATEST_POSTS_BLOG_PAGE = By.cssSelector("body > div.container.margin_60 > div");
protected static final By SUBMIT_BUTTON_CONTACT_PAGE = By.cssSelector(".btn.btn-primary.btn-block.btn-lg.go-right");

public void goToHotelsPage(){
action.driver.findElement(HOTELS_PAGE).click();
action.waitForElementToBeClickable(SEARCH_GROUND_HOTELS_PAGE,4);
}

public void goToHomePage(){
action.driver.findElement(HOME_PAGE).click();
action.waitForPageLoadFully();
action.waitForElementToBeClickable(SEARCH_GROUND_HOME_PAGE,2);
}

public void goToFlightsPage(){
action.driver.findElement(FLIGHTS_PAGE).click();
action.waitForElementPresent(SEARCH_BUTTON_FLIGHTS_PAGE);
}

public void goToToursPage(){
action.driver.findElement(TOURS_PAGE).click();
action.waitForElementToBeClickable(TOURS_GROUND_HOTELS_PAGE,2);
}

public void goToCarsPage(){
action.driver.findElement(CARS_PAGE).click();
action.waitForElementToBeClickable(SEARCH_BUTTON_CARS,2);
}

public void goToOffersPage(){
action.driver.findElement(OFFERS_PAGE).click();
action.waitForElementToBeClickable(LIST_OFFERS_PAGE,2);
}

public void goToBlogPage(){
action.driver.findElement(BLOG_PAGE).click();
action.waitForElementToBeClickable(LATEST_POSTS_BLOG_PAGE,2);
}

public void goToContactUsPage(){
action.driver.findElement(CONTACT_US_PAGE).click();
action.waitForElementToBeClickable(SUBMIT_BUTTON_CONTACT_PAGE,2);
}
}

Metodele create navigheaza intre paginile disponibile ale aplicatiei, asteptand sa se incarce fiecare element din pagina, in mod intamplator. Un utilizator nou al aplicatiei, va fi simulat, acesta accesand toate paginile, nestiind ce ar trebui sa se intample. Acest caz este face parte din testarea explorativa, tipul de testare dupa care ne dam seama daca aplicatia poate fi folosita de utilizatori care nu fac parte din mediul IT.

public void typeIntoTheLocationInputField(String locationName){
this.testLocationName = locationName;
action.driver.findElement(LOCATION_INPUT_FIELD_HOME_);
action.type(LOCATION_INPUT_FIELD_HOME_, locationName);
action.waitForElementToBeClickable(LOCATION_LIST_AFTER_SEARCH,2);
}

public void typeAndSearchLocation(int numberOfLocationInTheList){
this.typeIntoTheLocationInputField(testLocationName);
List<WebElement> locationList = action.findElementsNoImplicit(SEARCH_RESULTS);
try {
locationList.get(numberOfLocationInTheList-1).click();
}catch(IndexOutOfBoundsException e){
throw new CheckInExeption("Location number" + numberOfLocationInTheList + "doesn't exist");
}
}

3.2.2 Continutul

Continutul este reprezentat de testele automate în sine. Este bine să avem o separare clară între framework și conținut astfel încât soluția de automatizare să poată fi folosită pentru mai multe produse. Testele în sine pot fi dezvoltate în orice limbaj de programare ales, atât timp cât acesta este suportat de framework și de produs.

Crearea conținutului necesită o bună înțelegere a produsului ce va fi testat, astfel că echipele de testare ar trebui să joace un rol important în dezvoltarea testelor automate.

Realizarea continutului se face prin revizuirea procesului de testare existent. Trecerea in revista a testelor manuale existete pentru asigurarea faptului ca sunt scrise intr-o maniera ce permite automatizarea lor. Colaborarea cu echipa de testare pentru alcatuirea unor scenarii de test, sau pentru a alcatui o lista cu testele ce trebuiesc automatizate, in cadrul unei companii, este obligatorie.

Cele mai la indemana exemple ce pot fi automatizate sunt suitele de regresie, suitele de teste smoke sau testele de instalare a produsului. Indentificarea testelor cheie care, in cazul in care nu trec, vor produce defecte sau incidente cu prioritate pentru utilizatpri. De asemenea, trebuiesc definite din start notiunile de PASS si FAIL pentru teste cu scopul de a evita orice cconfuzii ulterioare.

O alta operatiune ce trebuie aplicata la acest nivel este stabilirea unei legaturi clare intre scenariile scrise manual si testele automate. Aceasta legatura va ajuta la determinarea gradului de acoperire al testelor. Acest nivel necesita efort, investind foarte mult timp, in schimb pe masura ce testele vor fi automatizate, prograsul va fi mult mai usor de urmarit. Acest nivel este folosit, de asemene, si in procesul de raportare al rezultatelor testelor automate catre sistemul de monitorizare utilizat in management.

Pentru o testare de calitate, este important să existe o planificare riguroasă a testării încă din faza de proiectare sau development. Pe măsură ce se conturează definițiile modulelor, entităților de date, obiectelor, claselor, funcțiilor, etc. este recomandabil să se scrie și “scenarii” de testare ale acestora, fie top-down, fie bottom-up.Există “testare pozitivă” și “testare negativă”, concretizată în positive test cases și negative test cases.

Testarea pozitiva înseamnă verificarea faptului că sistemul face ceea ce trebuie să facă.

Testarea negativă înseamnă verificarea faptului că sistemul nu face ceea ce nu trebuie să facă.

În principiu, cele două abordari sunt echivalente, însă în practică testarea pozitivă se referă la funcționarea “normală” a sistemului, iar testarea negativă la “corner cases”. De exemplu, pentru testarea unui modul critic ca timp in productie dar non-critic ca și calitate (ex. twitter), se va prefera testarea pozitivă, care asigură că sistemul funcționează corect pentru cei mai mulți utilizatori. Pentru testarea unui modul critic ca și calitate (ex. online banking) se va insista pe teste negative, ex. se va încerca “spargerea” sistemului prin combinații incorecte.

Continutul a fost separat de Framework, pastrand o structura de tip arbore, in care testele sunt structurate in functie de ce module testeaza, si in functie de ce fel de tip de abordare asigura (negativa sau pozitiva).

Figura 3.14 Arhitectura Testelor

Un exemplu de test care verifica funstionarea unui modul critic in productie este ViewAllPages. Testul extinde componenta FirstTestCase, componenta care deschide browser-ul si navigheaza spre URL-ul PHPTRAVELS. Aceasta inlantuire de teste foloseste ca instante, obiecte ale claselor MainPages si MainApplication.

Scenariul testului va fi urmatorul:

Navigare spre http://phptravels.com;

Comportamentul asteptat este:

Browser-ul se va deschide,URL-ul va fi scris, iar cautarea va incepe.

Acest pas se va termina cu succes in momentul in care pagina va fi complet vizibila, iar fiecare element din aceasta va fi capabil de a primi actiuni.

Verificarea tuturor acestor astepte se va face la nivelul Testului WiewAllPages.

Alegerea aplicatiei FontEnd;

Comportamentul asteptat este:

Butonul trebuie sa fie vizibil, prezent in DOM si capabil de a primi actiuni;

Pagina Front-End trebuie sa apara ca nou Tab activ;

Pagina meniului trebuie sa existe inca in browser;

Pagina FrontEnd trebuie sa incarcata complet;

O verificare suplimentara se va realiza la acest pas, cu ajutorul URL-ului. Dupa navigare, acesta trebuie sa fie de forma: http://www.phptravels.net/

Din meniul cu pagini se va alege pagina Hotels:

Comportamentul asteptat este:

Tab-ul de accesare al paginii Hotels trebuie sa fie vizibil, prezent in DOM si capabil de a primi actiuni;

Pagina FrontEnd, home, va fi schimbata cu pagina Hotels;

Se va astepta ca un element prezet doar in pagina Hotels sa fie vizibil, prezent in DOM si capabil de a primi actiuni;

O verificare suplimentara se va realiza la acest pas, cu ajutorul URL-ului. Dupa navigare, acesta trebuie sa contina: “/hotels”.

Din meniul cu pagini se va alege pagina Home:

Comportamentul asteptat este:

Tab-ul de accesare al paginii Home trebuie sa fie vizibil, prezent in DOM si capabil de a primi actiuni;

Pagina FrontEnd, Hotels, va fi schimbata cu pagina Home;

Se va astepta ca un element prezet doar in pagina Home sa fie vizibil, prezent in DOM si capabil de a primi actiuni;

O verificare suplimentara se va realiza la acest pas, cu ajutorul URL-ului. Dupa navigare, acesta trebuie sa contina: http://www.phptravels.net/

Din meniul cu pagini se va alege pagina Tours:

Comportamentul asteptat este:

Tab-ul de accesare al paginii Tours trebuie sa fie vizibil, prezent in DOM si capabil de a primi actiuni;

Pagina FrontEnd, Home, va fi schimbata cu pagina Tours;

Se va astepta ca un element prezet doar in pagina Tours sa fie vizibil, prezent in DOM si capabil de a primi actiuni;

O verificare suplimentara se va realiza la acest pas, cu ajutorul URL-ului. Dupa navigare, acesta trebuie sa contina: “/tours”

Din meniul cu pagini se va alege pagina Cars:

Comportamentul asteptat este:

Tab-ul de accesare al paginii Cars trebuie sa fie vizibil, prezent in DOM si capabil de a primi actiuni;

Pagina FrontEnd, Tours, va fi schimbata cu pagina Cars;

Se va astepta ca un element prezet doar in pagina Cars sa fie vizibil, prezent in DOM si capabil de a primi actiuni;

O verificare suplimentara se va realiza la acest pas, cu ajutorul URL-ului. Dupa navigare, acesta trebuie sa contina: “/cars”

Aceeasi pasi vor fi executati si pentru paginile: Offers, Blog, Contact Us.

Toate topicurile descrise in “Comportamentul asteptat” trebuie sa fie indeplinite pentru ca testele sa fie finalizate cu succes, cu alte cuvinte, sa aiba eticcheta PASSED. Altfel, testele vor pica, si vor avea eticheta FAILED.

package com.imargalinoiu.websitetesting.modules.mainTest.pages;

import com.imargalinoiu.websitetesting.basic.basetest.FirstTestCase;
import com.imargalinoiu.websitetesting.basic.main.MainApplication;
import com.imargalinoiu.websitetesting.basic.mainpages.MainPages;
import org.testng.Assert;
import org.testng.annotations.Test;

import java.util.ArrayList;
import java.util.List;

/**
* Created by Isabela on 5/3/2017.
*/
public class ViewAllPages extends FirstTestCase{

private MainPages page;
private MainApplication main;

@Test(priority = 1)
public void goToMainPagesOneByOne(){
main = new MainApplication(actionDriver);
page = new MainPages(actionDriver);
main.fromMainToFrontendPage();
actionDriver.waitForNumberOfBrowserTabs(2, 2);
List<String> browserTabs = new ArrayList<>(actionDriver.driver.getWindowHandles());
actionDriver.driver.switchTo().window(browserTabs.get(1));
actionDriver.waitForLoadPage();
Assert.assertTrue(actionDriver.driver.getCurrentUrl().contains("http://www.phptravels.net/"));
page.goToHotelsPage();
Assert.assertTrue(actionDriver.driver.getCurrentUrl().contains("/hotels"));
page.goToHomePage();
Assert.assertTrue(actionDriver.driver.getCurrentUrl().contains("http://www.phptravels.net/"));
page.goToToursPage();
Assert.assertTrue(actionDriver.driver.getCurrentUrl().contains("/tours"));
page.goToCarsPage();
Assert.assertTrue(actionDriver.driver.getCurrentUrl().contains("/car"));
page.goToOffersPage();
Assert.assertTrue(actionDriver.driver.getCurrentUrl().contains("/offers"));
page.goToBlogPage();
Assert.assertTrue(actionDriver.driver.getCurrentUrl().contains("/blog"));
page.goToContactUsPage();
Assert.assertTrue(actionDriver.driver.getCurrentUrl().contains("/contact-us"));
page.goToHomePage();
Assert.assertTrue(actionDriver.driver.getCurrentUrl().contains("http://www.phptravels.net/"));
}
}

Dupa rularea testelor, acestea vor avea patru stari:

PASSED

Toate testele au trecut, nu a existat nicio problema vizuala sau de functionalitate

FAILED

Toate testele au picat.

SKIPPED

Unele teste din suita au fost omise din cauza problemelor de inlantuire.

UNSTABLE

Unele teste pica, si unele trec in mod intamplator.

3.2.3 Intocmirea Rapoartelor – Jenkins

Maven este un instrument de gestiune al proiectului, bazat pe conceptul de Model de proiect de obiect (POM) care contine toate informatiile despre proiect. Maven permite unui proiect de a costrui, folosind POM-ul proiectului, de a gestiona construirile, dependintele si versiunile de documentatie care sunt toate stocate in fisierul pom.xml.

Maven definește un mod standard pentru a construi proiectele, a testa și a implementa artefacte de proiect. Acesta oferă un cadru care permite reutilizarea ușoară a logicii comune de construire pentru toate proiectele care respectă standardele Maven.

Pasii crearii proiectului Maven in Jenkins:

Click pe „New Items” in partea din stanga a meniului Jenkins;

Scrierea numelui proiectului

Selectarea Optiunii Maven

Figura 3.15 Meniu Principal Jenkins

Introducerea descrierii job-ului (aici testarea automata a aplicatiei PHPTRAVELS)

În gestionarea codului sursă, Jenkins suportă CVS și Subversion, cu suport încorporat pentru Git și se integrează cu multe alte sisteme de control al versiunilor prin pluginuri.

Pentru declansarea constructiei, avem mai multe opțiuni, cum ar fi "Construiți periodic", "Sondaj SCM", "Construiți ori de câte ori este construită o dependență SNAPSHOT etc. Exemplu: dacă selectați opțiunea" Sondaj SCM ", Jenkins va efectua sondaj la depozit pentru modificările bazate pe expresia cron specificată.

In constructie trebuie mentionat pentru Jenkins unde sa gaseasca fisierul pom.xml

Figura 3.16 Rută pom.xml

In setarile build-ului, constrctiei, se poate accepta optiunea de trimitere de notificari pe email;

In optiunea “Post build actions” se pot alege optiuni de arhivare a artefactelor, publicare a rezultatelor etc.

Dupa rularea unui build, unei constructii, rezultatele afisate in mod implicit in consola arata:

Figura 3.17 Rezultat dupa rularea unui build

In Jenkins exista posibilitatea de a crea rapoarte configurate dupa TestNG. Dupa instalrea plugin-urilor TestNG pentru Jenkins, in tab-ul Installed exista acum posibilitatea de a vedea o lista cu plugin-urile instalate dupa cum urmeaza:

Figura 3.18 Plugin-uri Jenkins

Adaugarea plugin-ului se face din optiunea Post Build Actions, mentionata si anterior, dupa cum urmeaza:

Figura 3.19 Publicarea rapoartelor Jenkins

O structura instabila (UNSTABLE) va fi marcata daca rezultatul a ignorat testul dupa executare, iar o structura succes (PASSED) va fi marcata daca toate testele din constructie au trecut. Nu in cele din urma, o structura picata (FAILED) va fi marcata daca testele din construtie au picat.

Figura 3.20 Marcare Build Instabil

3.3 Elemente ale procesului decizional

Definitia deciziei in general, are urmatoarea forma: A decide, iseamna a alege dintr-o multime de variante de actiune, tinand cont de anumite criterii, pe cea care este considerata cea mai avantajoasa pentru atingerea unor obiective. [9] Procesul decizional reprezinta un ansamblu de activitati desfasurat de un individ sau un grup, care se confrunta cu un eveniment care genereaza mai multe variante de actiune, obiectivul activitatii fiind alegerea unei variante care corespunde sistemului de valori ale individului sau grupului. [10]

Luarea unei decizii la nivel organizational este foarte importanta, deoarece deciziile gresite pot genera pierderi in organizatie. Pagubele pot fi cu atat mai mari cu cat greselile sunt asociate cu niveluri superioare ale conducerii.

In testare, fazele procesului decizional sunt neliniare, cu revenire, fiecare din aceste faze avand mai multe etape. Inainte de eliberarea in productie a unor noi functionalitati sau module ale software-ului, va fi rezervata o buna bucata de timp testarii si luarii deciziilor de eliberare a modificarilor. Teste generale, care verifica intreaga functionalitate a software-ului, teste de regresie, vor fi rulate si performate, de asemnea teste de securitate, performanta, fum, stabilitate si integrare. Toate aceste validari vor avea loc pe un mediu similar cu cel al productiei, in asa fel incat cazuri noi de test in productie care sa nu fi fost acoperite sa nu existe.

Mediul in care se vor rula testele automate va fi cat mai similar cu cel din productie, iar fazele crearii acestuia sunt echivalente cu fazele procesului decizional:

Figura 3.21 Diagrama de decizie

Mulți manageri de testare cu experiență folosesc deja în mod inconștient DDTM (Decision Driven Test Management) sau conducerea testării prin decizie, într-un anumit nivel. În multe moduri, este modul logic de a lucra și mulți adoptă această abordare chiar și fără să o observe.

Deciziile la nivel de produs vor fi luate in functie de gravitatea problemelor gasite in stadiul de testare. Daca testele din suita Smoke vor avea succes, constructia testata va avea parte de „lumina verde”, Green light, pentru productie. Dar aceasta conditie este necesara dar nu suficienta. Un caz concret ar fi: suita Smoke a fost incheiata cu succes, in schimb un procent de 30% din testele de regresie pica. In aceasta situatie, produsul nu va avea acceptul de a fi livrat in productie intrucat impactul asupra clientilor este unul extrem de mare.

Elementele decizionale in acest proces trebuiesc foarte bine cantarite si comunicate. Acest lucru este posibil prin mentinerea unei evidente complete si clare cu ajutorul rapoartelor si diagramelor create in acest caz de Jenkins. Mai exista de asemenea si conceptul de „Copac de deccizie”, nu prea des folosit.

In 70% din cazuri, decizia de eliberare spre productie, sau de oprire a eliberarii spre productie a unui software nu este luata de o singura persoana, decidentul, este aici un grup de persoae care studiaza rapoartele intocmite pentru controlul calitatii.

Astefel de rapoarte ajutatoare in procesul decizional eu fost intocmite cu ajutorul rularii succesive a testelor automate. Suprafata delimitata cu rosu reprezinta testele care au picat, iar suprafata verde reprezinta testele care au avut succes.

Figura 3.22 Grafic general Jenkins

Figura 3.23 Rezultate dupa rularea suitelor: smoke și regresie

In acest caz prezentat prin diagramale si tabelele de mai sus, se va lua decizia de eliberare a produsului in mediul de productie, spre clienti, intrucat testele din suita smoke.xml au avut succes, iar doar 4 teste din regresie nu s-au finalizat cu succes. Aceasta decizie va fi luata, insa probleme aparute din cauza carora testele au picat, trebuiesc sa fie fixate si livrate cat mai curand posibil, pentru mentinerea unui proces de integrare si dezoltare continue.

Cap 4. CONCLUZII ȘI CONTRIBUȚII. PERSPECTIVE

Solutia de automatizare si framework-ul de testare automata isi propun reducerea timpului de dezvoltare si a costurilor pe termen lung, a muncii repetitive, economisirea orelor de munca si eliminarea erorilor umane intr-un mediu de productie in care dezvoltarea este continua, pentru orice aplicatie WEB. Avantajele pe care proiectul le ofera pentru un mediu de dezvoltare software sunt viteza superioara avand in vedere faptul ca testarea automata este potrivita pentru aplicatiile software aflate in evolutie continua, cu un ritm ridicat de schimbari dictate de clienti sau de factori legistalivi, intrucat automatizarea testarii reduce semnificativ timpul necesar executiei testarii pentru eliberarea spre productie si utilizatori a unei noi versiuni sau functionalitati. Detectarea la timp a erorilor reduce riscurile generate de ajungerea defectelor in productie.

Usurinta cu care poate fi folosit framework-ul de testare automata subliniaza mai mult veridicitatea si importanta acestuia, secretul succesului testarii automate reprezentand creearea unor metode general-valabile extrem de utile care sa se plieze pe cerintele oricarui software. De asemenea, sistemul de automatizare ajuta la determinarea capacitatii de incarcare maxima suportata de orice sistem software si de performanta acestuia, fie simuland utilizarea aplicatiei, cu un numar riducat de useri, paralelizand procesele de testare, fie simuland modul in care se comporta aplicatia atunci cand pe termen lug un numar ridicat de utilizatori o folosesc.

În contextul actual, livrarea rapidă pe piață este crucială, iar erorile și bugurile nu sunt foarte tolerate. Prin urmare, este important să se livreze produse de calitate. Deoarece asigurarea calității nu este un obiectiv principal din cauza unor constrângeri precum timpul, costul, resursele, acest aspect este doar parțial acoperit în munca efectivă. Consecința imediată este o experiență negativă a utilizatorului.

Testare manuală are probleme de fiabilitate, deoarece este laborioasă și înceată. De exemplu, până când se descoperă un bug, se vor uita detaliile importante care trebuie reproduse. De asemenea, rezultatele testelor manuale ar trebui să fie bine documentate de tester pentru a funcționa ca reper pentru alți testeri. Din aceste motive, testarea este o disciplină în cadrul căreia automatizarea poate ajuta cu adevărat.

Aplicatia reuseste sa introduca conceptul de documentatie imbunatatita prin folosirea uneltelor precum Jenkins, care masoara concretizarea obiectivelor, presupunund rezultate detaliate: numele testelor care si-au terminat rularea cu succes, status-ul testelor, numele testelor care au picat, numele testelor care au fost omise. Cu ajutorul acestor date, vor fi intocmite rapoarte folositoare in procesul decizional, pentru a minimiza de asemenea timpul de decizie.

Odata create, framework-ul si continutul, pot fi folosite si rulate de multiple ori fara costuri suplimentare, ori de cate ori va fi nevoie, fiind mult mai rapide decat procesul de testare manuala, fiind totodata si usor de paralelizat si instalat. Pune la dispozitie metode superioare care faciliteaza actiunile precum click-ul pe butoane, asteptarea dupa elemente indiferent de timpul necesar acetora de a fi afisate in pagina, completarea formularelor, efecutarea de capturi de ecran cu scopul determinarii problemelor ce apar atunci cand testele sunt rulate pe un alt mediu decat cel local, de dezvoltare, descarcarea de resurse si de continut Web.

Inovatiile pe care framework-ul de testare automata a aplicatiilor web il aduce este totodata si securizarea codului scris, intrucat proiectul conceput a fost urcat intr-un depozit cu contraoale de acces, si anume GitaLab, care asigura si recenzii de cod, urmărirea problemelor, feed-uri de activitate, wiki-uri și integrare continuă. La nivelul depozitului, codul este securizat din protocolul SSH, cu o cheie privata, asigurand astfel un transport optim de date.

Solutia de automatizare este una generica si poate fi folosita pe orice platforma sau sistem de operare existent pe piata, nevand restrictii din acest punct de vedere, executand teste de compatibilitate pe mai multe configuratii versionate diferit, in orice punct de pe traseu putand sa se faca teste si evaluări de performanță.

Fiind totodata si o aplicatie scrisa in Java, solutia de automatizare are posibilitatea de a elimina sursele frecvete de erori ce apar in programe prin eliminarea pointerilor, administrarea automata a memoriei si eliminarea fisurilor de memorie printr-o procedura de colectare a trash-ului care ruleaza ca proces de fundal. Foloseste deci cel mai sigur limbaj de programare disponibil in acest moment, asigurand mecanisme de securitate a programelor.

Rescrierea metodelor Selenium imbunatateste considerabil calitatea proiectului, reusind sa eficientizeze metodele existente si sa creeze metode noi care fac a dubla verificare a obiectelor din paginile web testate. Exista, deci, o dubla verificare pe care ochiul uman greu o poate performa.

In afara de timpul propriu-zis necesar conceperii proiectului, costul framework-ului de testare a aplicatiilor web este nul, instrumentele folosite fiind open source.

Asadar, aplicatia prezentata sub numele de „Framework pentru testarea automata a plicatiilor web” a reusit sa atinga obiectivele stabilite in faza de proiectare, reusind diminueze timpul de lucru fata de testarea manuala cu 80%, reusind sa diminueze costurile pe termen lung si a muncii repetitive, reusind sa implementeze tehnologii noi din industria software, cum ar fi: Jenkins, GitLab, JavaScript, Maven, TestNG, si nu in ultimult rand reusind sa verfice din punct de vedere functional, vizual si din punct de vedere al securitatii, software prezente in productie.

Solutiei i se mai pot aduce imbunatatiri cum ar fi disponibilitatea pentru platformele de mobil: iOS si Android, dar si crearea unei interfete prietenoase pentru utilizatori care nu detin cunostinte de programare. De asemnea, implementarea paralela a unor API-uri pentru testarea server-side ar fi o imbunatatire considerabila, intrucat ar face posibila testarea automata a aplicatiilor standalone care nu se deschid in browser. Testarea automata a aplicatiilor standalone, in acest caz, ar putea fi facuta chiar din command line-ul aplicatiei.

BIBLIOGRAFIE

[1] Herbert M. Isenberg – The practical organization of automated software testing

[2] Elisabeth Hendrickson – Test automation advice

[3] ISO/IES 9126

[4] ISO 9000 Quality systems developmenthandbook – Hoyle D.

[5] Test Automation Architecture: Planning for Test Automation – Douglas Hoffman, 1999

[6] Test Automation Frameworks – Carl J. Neagle, 2000

[7] Managementul calitatii software – Ion Ivan

[8] Proiectarea si implementarea sistemului calitatii – D. Constantinescu

[9] Metode statistice in analiza software – Ion Ivan, Catalin Boja

[10] Elfriede Dustin, Jeff Rashka – Automated Software Testing

[11] Beekman G.and Beekman B. Digital Planet: Tomorrow’s Technology and You. Ediția 10. 2012

Referințe internet:

[12] https://about.gitlab.com/features/

[13] https://www.quora.com/What-is-Jenkins-When-and-why-is-it-used

[14] https://about.gitlab.com/about/

[15] https://www.jetbrains.com/help/idea/maven.html

[16] http://www.seleniumhq.org/docs/02_selenium_ide.jsp#introduction

[17] http://testng.org/doc/

[18] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Introduction

[19] https://www.java.com/en/download/faq/whatis_java.xml

[20] http://www.yourhtmlsource.com/starthere/whatishtml.html

[21] https://en.wikipedia.org/wiki/HTML

[22] https://www.thoughtco.com/what-is-javascript-2037921