Procesul de Testare. Tehnicile Si Metodele de Testare Specifice Aplicatiilor Software
Cuprins:
Capitolul 1 – Introducere
1.1 Testarea – etapă a ciclului de dezvoltare software…………………………………………………
Capitolul 2 – Tehnici de testare
2.1 Testarea unui modul.
2.2 Testarea de integrare.
2.3 Testarea functionala
2.4 Testarea de validare
Capitolul 3 – Testarea sistemelor distribuite bazate pe tehnologia Internet
3.1 Componentele unui sistem distribuit
3.2 Modele de organizare a aplicațiilor distribuite
3.3 Modele arhitecturale specifice
3.4 Modelele calcului distribuit
3.5 Modelul Client Sever.
3.6 Avantajele sistemelor distribuite
3.7 Testarea sistemelor distribuite bazate pe componente
Capitolul 4 – Testarea automată
4.1 De ce este testarea automată atât de importantă pentru companii
4.2 Testarea Manuală vs Testarea Automată
APLICATIE
CONCLUZII
BIBLIOGRAFIE.
Capitolul 1 – Introducere
Testarea este activitatea de concepie a cazurilor de test, de execuie a testelor i de evaluare a rezultatelor testelor, n diferite etape ale ciclului de via al programelor.
Testarea reprezintă o etapă importantă în procesul de realizare a produselor software. Ponderea cheltuielilor cu testarea reprezintă între 30% și 50% din totalul cheltuielilor pentru dezvoltarea unei aplicații software.
Tehnicile și metodele moderne de elaborare a produselor software acordă o importanță deosebită efortului de înlăturare a erorilor de analiză, proiectare și programare prin folosirea unor mijloace evoluate de testare.
Aceasta lucrare prezintă procesul de testare, tehnicile și metodele de testare specifice aplicațiilor software. Sunt avute în vedere aplicațiile clasice, aplicațiile realizate utilizând tehnologii orientate obiect și aplicațiile distribuite. În lucrare sunt făcute referiri la utilizarea tehnicilor de testare pentru clientul de email Gmail
Un test const n execuia programului pentru un set de date de intrare convenabil ales, pentru a verifica dac rezultatul obinut este corect.
Un caz de test este un set de date de intrare mpreun cu datele de ieire pe care programul ar trebui s le produc. De exemplu, valorile coeficienilor a,b,c ai unei ecuaii de gradul doi mpreun cu valorile x1, x2, n testul unui program de rezolvare a ecuaiilor de gradul doi. Cazurile de test se aleg astfel nct s fie puse n eviden, dac este posibil, situaiile de funcionare necorespunztoare.
Prin testare nu se poate demonstra corectitudinea unui program. Aceasta deoarece n cele mai multe cazuri este practic imposibil s se testeze programul pentru toate seturile de date de intrare care pot conduce la execuii diferite ale programului. Testarea poate doar s demonstreze prezena erorilor ntr-un program. ntr-un sens, testarea este un proces distructiv, deoarece urmrete s determine o comportare a programului neintenionat de proiectani sau implementatori. Din acest punct de vedere testarea nu trebuie s fie fcut de persoanele care au contribuit la dezvoltarea programului. Pe de alt parte conoaterea structurii programului și a codului poate fi foarte utila pentru alegerea unor date de test relevante.
Testarea – etapă a ciclului de dezvoltare software
Proiectarea aplicațiilor software de dimensiuni mari, dezvoltată în cadrul unei echipe, nu se face trecând direct la implementarea programului, ci urmează etape bine stabilite. Procesul de dezvoltare al aplicațiilor software este alcătuit din următoarele etape: specificarea cerințelor, analiză, proiectare, implementare, testare și întreținere. În figura 2.1 este prezentat grafic modelul clasic de dezvoltare software .
Figura 1.1. – Modelul clasic de dezvoltare software
Conform figurii 1.1, în etapa de specificare a cerințelor se determină necesitățile pentru toate elementele sistemului, atât hardware cât și software. Testarea specificațiilor se realizează prin metode de analiză statică: inspecții, parcurgeri și analize tehnice.
Etapa de analiză continuă procesul de stabilire a cerințelor. Analistul trebuie să înțeleagă domeniul informațiilor pentru software, funcțiile necesare, performanțele și interfețele. Se documentează cerințele, iar acestea sunt revăzute împreună cu beneficiarul. În această etapă este descris ceea ce trebuie să facă aplicația informatică și nu modul în care se realizează. în testarea unei aplicații sunt definite principalele caracteristici ale aplicațiilor componente: magazin electronic, gestiunea bibliotecii, bugetul personal, agenda telefonică, rețete culinare și jurnalul personal. Sunt descrise cazurile de test pentru fiecare componentă în parte.
În etapa de proiectare accentul se pune pe structurile de date, arhitectura sistemului, detaliile procedurale și caracterizarea interfețelor. În această etapă sunt identificate structurile de date, interfețele, modulele și sunt descriși algoritmii. Pentru fiecare modul în parte sunt definite specificațiile de realizare. Cazurile de test sunt rafinate și sunt adăugate noi cazuri de test corespunzătoare detaliilor introduse. Statistic peste 35% din erorile software își au originea în fazele de analiză și proiectare.
Prin implementare se face trecerea de la proiect la o formă specifică mașinii de calcul. Implementarea este cu atât mai ușor de realizat cu cât proiectarea se realizează mai în detaliu. Testarea în etapa de implementare are rolul de a evidenția diferențele dintre comportamentul produsului din specificații și cel dat la nivelul utilizatorilor. Testarea se concentrează atât asupra logicii interne a programului, avându-se în vedere ca anumite elemente ale acestuia să fie parcurse, cât și pe funcționalitatea externă a sa, pe baza specificațiilor. Se compară rezultatele efective obținute după rularea programului cu seturi de date de test cu rezultatele scontate pe baza specificațiilor.
În timp, după livrarea la beneficiar, aplicațiile software suferă schimbări care se datorează erorilor descoperite pe parcursul funcționării aplicației, modificărilor mediului în care rulează aplicația (software, hardware) precum și noilor cerințe de performanță și funcționalitate dorite de beneficiar. Întreținerea aplicațiilor software se aplică tuturor fazelor ciclului de viață.
În cadrul ciclului de dezvoltare software, un rol important îl au verificarea și validarea (V & V). Verificarea și validarea reprezintă un proces prin care se determină dacă cerințele unui sistem sau componentă sunt complete și corecte, dacă rezultatul fiecărei faze de dezvoltare îndeplinește cerințele sau condițiile impuse în faza anterioară și dacă sistemul sau componenta finală este în concordanță cu cerințele specificate.
Verificarea este mulțimea activităților care asigură că o aplicație software implementează corect o anumită funcție. Testarea software este o componentă a procesului de V & V.
Validarea este mulțimea activităților care asigură că o aplicație software realizată este în concordanță cu cerințele beneficiarului. Pe măsura dezvoltării incrementale a aplciatiei rezultatele din fazele intermediare sunt validate de către client.
Testarea sau analiza statică are ca scop examinarea aplicațiilor software fără a fi executate și cuprinde activități precum inspecțiile, execuția simbolică și verificarea. Aceste activități fac parte din categoria evaluările tehnice.
Inspecțiile codului presupun citirea sau inspecția vizuală a codului sursă de către un grup de persoane. Având la dispoziție codul sursă și specificațiile de proiectare, grupul de persoane din echipa de inspecție urmărește explicațiile programatorului legate de logica programului, instrucțiune cu instrucțiune. În acest mod se descoperă o serie de erori specifice acestei metode cum ar fi: declararea datelor, referirea datelor, erorile de calcul, erorile de comparare, erorile de logică, erorile de intrare/ieșire, erorile de interfață etc.
Parcurgerile constau în citirea sau inspecția vizuală a codului sursă de către un grup de persoane, însă procedura de lucru este diferită având ca scop execuția logică a fiecărei secvențe de cod de testat pe baza unor seturi de test pregătite anterior. Prin urmărirea programului pas cu pas sunt identificate erori care apar la acest nivel. Rezultatele acestei activități de verificare depind, ca și în cazul inspecțiilor codului, de atitudinea echipei față de persoana care a scris programul, având în vedere faptul că atenția trebuie acordată programului care se verifică și nu celui care l-a scris.
Verificarea de birou este o tehnică de analiză statică în care listingurile codurilor sau rezultatele testelor sau alte documente sunt examinate vizual, de obicei de persoana care le-a realizat, pentru a identifica erorile sau abaterile de la standardele de dezvoltare sau alte probleme.
Testarea dinamică presupune examinarea aplicațiilor software în scopul generării datelor de test cu care acestea vor fi executate și rularea aplicațiilor cu seturile de date de test obținute. Se observă că spre deosebire de testarea statică, testarea dinamică presupune execuția aplicației care se testează. Există două strategii de dezvoltare a cazurilor de test: o strategie bazată pe structura programelor și o alta, bazată pe funcționalitatea acestora.
În dezvoltarea unui produs software testarea se realizează pe mai multe niveluri: testarea de module, testarea de integrare, testarea de sistem și testarea de acceptare (validare). În figura 2.2 este prezentat procesul de verificare și validare în cadrul ciclului de dezvoltare a unui produs software. Se identifică etapele de realizare a aplicației precum și etapele și nivelurile procesului de testare software.
Figura 1.2. – Testarea software în ciclul de dezvoltare
Capitolul 2 – Tipuri de testare software
Modelul V de testare identifica 5 faze ale testarii sofdtware, fiecare cu anumite tipuri de testare specifice:
Testarea de regresie se utilizieaza in toate fazele
Fiecare faza de testare si fiecare test individual, trebuie sa aibe criterii specifice de intrare ce trebuie sa le indeplineasca inainte ca testarea sa inceapa si deasemnea trebuie sa contina criterii specifice de iesire ce tebuie sa le indeplineasca fiecare test sau faza, ca testarea sa fie considerata ok. Si citeriile de intrare si cele de iesire, sunt stabiliate de coordonatorii de test ele fiind trecute in planul de testare.
Testele unitare
In timpul testarii unitare sunt create o serie de teste individuale. Fiecare test verifica o componenta individuala, daca a fost modificata sau daca e noua. Testarea unitara este numita si testare de modul, deoarece testeaza unitatile individuale care compun aplicatia.
Fiecare test va valida un singur modul bazandu-se pe documentul ce reprezinta design-ul tehnic, care a fost creat sa faca un anumit task si de la care se asteapta sa se comporte intr-un anumit fel sau sa produca anumite rezultate. Testele unitare se axeaza pe functionalitate si stabilitate, iar datele de intrare si cele de iesire pot fi acealasi pentru fiecare modul sau specifice pentru fiecare modul in parte. Testele unitare sunt create intr-un mediu de test inainte de integrarea sistemului. Daca este descoperit un defect in timpul testarii unitare, gravitatea defectului va decide daca va fi reparat sau nu inainte ca acea unitate, modul sa fie aprobat
Criterii de intrare si de iesire pentru testarea unitara:
Criterii de intrare:
Cerintele de business sunt cel putin 80% complete si au fost aprobate la data inceperii testarii unitare
Design-ul tehnic a fost finalizat si aprobat
Mediu nde dezvoltare a fost stabilit si este stabil
Codul epntru modul a fost in totalitate scris
Criterii de iesire:
Codul are un sistem de versionare
Nu se cunosc defecte critice sau majore care sa impiedice modulul sa ajunga la testarea de sistem
Trebuie sa se tina o sedinta de tranzitie a testelor
Aprobarea managerului de proiect a fost obtinuta
Testarea de sistem
Testarea de sistem, testeaza toate componentele si modulele care sunt noi, modificate, au fost afectate de o modificare sau e nevoie sa indeplatea defectului va decide daca va fi reparat sau nu inainte ca acea unitate, modul sa fie aprobat
Criterii de intrare si de iesire pentru testarea unitara:
Criterii de intrare:
Cerintele de business sunt cel putin 80% complete si au fost aprobate la data inceperii testarii unitare
Design-ul tehnic a fost finalizat si aprobat
Mediu nde dezvoltare a fost stabilit si este stabil
Codul epntru modul a fost in totalitate scris
Criterii de iesire:
Codul are un sistem de versionare
Nu se cunosc defecte critice sau majore care sa impiedice modulul sa ajunga la testarea de sistem
Trebuie sa se tina o sedinta de tranzitie a testelor
Aprobarea managerului de proiect a fost obtinuta
Testarea de sistem
Testarea de sistem, testeaza toate componentele si modulele care sunt noi, modificate, au fost afectate de o modificare sau e nevoie sa indeplineasca o cerinta noua. Testarea sistemului este posibil sa necesite si alte sisteme, dar acest lucru trebuie minimizat cat mai mult posibil pentru a reduce riscul problemelor externe induse de aceste sisteme. Testarea interactiunii cu alte parti ale sistemului complet, se va face in testarea de integrare. Accentul in testarea sistemului este pus pe validarea si verificarea cerintelor venite de la design-ului functional si pentru a vedea daca toate modulele functioneaza impreuna. De exemplu, sistemul de test pentru o aplicatie web noua care care colecteaza date de la user intr-o baza de date, nu trebuie sa contina si baza de date, procesarea poate fi oprita cand datele sunt mutate intr-o faza intermediara de transfer de date, daca exista una
Primul sistem de test este de obicei un smoke test. Acesta este o un tip de testare informala care parcurge functionalitatile importnate ale aplicatiei fara sa intre prea mult in detalii. Termenul vine din practicile de testare hardware, atunci cand un nou echipament este pornit pentru prima data, este considerat un succes atunci cand nu scoate fum sau nu ia foc.
Testarea sistemului necesita multe rulari de teste deoarece presupune validarea comportamentului facilitatilor folosind o plaja larga de date de intrare, atat date corecte cat si date eronate. Existenta unui plan de test este critica in aceasta faza, deoarece contine descrierea cazurilor de test, secventa in care un anumit test trebuie executat si datele ce trebuie colectate la fiecare rulare.
Cand o eroare sau un defect este descoperit, testele de sistem executate anterior trebuie rerulate dupa reparare, pentru a ne asigura ca modificarea nu a cauzat alte probleme. Acest lucru va fi detaliat in sectiunea testelor de regresie.
Criterii de intrare si criterii de iesire pentru testele de sistem:
Criterii de intrare:
Testarea unitara a fiecarui modul a fost efectuata si aprobata, fiecare modul este versionat
Un plan pentru urmarirea incidentelor a fost aprobat
A fost stabilit un mediu pentru testele de sistem
Planificarea testelor de sistem a fost aprobata
Criterii de iesire:
Aplicatia indeplineste toate cerinele functionale si de business
Niciun defect critic ce sa impiedice treecerea la testarea de integrare
Toata lumea implicata a aprobat testele ca fiind complete
Trebuie sa se tina o sedinta de tranzitie a testelor si dezvoltatorii sa fie de acord cu el
Ca parte a testelor de sistem, testele de conformitate si analiza pot fi rulate pentru a verifica daca aplicatia este conform standardelor corporatiei sau industriei, in materie de portabilitate si interoperabilitate. De exemplu, pentru a spori portabilitatea, un standard impus de coporatie poate fi ecela ca toate SQL-urile sa fie scrise in asa fel incat sa poate fi rulate atat in Oracle cat si in DB2.
Testele de integrare
Testarea de integrare veirfica toate componentele si modulele noi, modificate sau afectate de o modificare sau necesare pentru a forma un sistem complet. Unde testele de sistem incearca sa minimizeze factorii externi, testele de integrare necesita implicarea altor sisteme si interfete cu alte aplicatii, inclusiv cele detinute de un furnizor extern, parteneri externi sau clientul. De exemplu, testele de integrare pentru o interfata web noua care colecteaza date de la utilizator intro baza de date, trebuie neaparat sa includa si baza de date a aplicatiei chiar daca baza de date este detinuta de un furnizor extern – sistemul complet trebuie testat end-to-end, de la un capat la alltul. In acest exemplu, testarea de integrare nu se opreste la incarcarea bazei de date, testele trebuie sa verifice si ca baza de date s-a incarcat corect.
Acest tip de teste se diferentiaza de testele de sistem si prin faptul ca daca un defect este descoperit, nu toate testele executate anterior trebuie reexecutate dupa ce repararea defectului a fost facuta. Doar testele care au conexiune cu acel defect vor trebui rerulate, dar retestarea trebuie sa inceapa in punctul in care se repara, daca este inaintea punctului in care s-a depistat problema. De exemplu, retestarea unui proces FTP ar putea folosi un fisier existent, in loc sa se foloseasca un fisier nou daca pana in acel punct totul a fost ok.
Criterii de intrare:
Testele de sistem au fost complete
Problemele nerezolvate si defectele au fost identificate si documentate
Scripturile de test si planificarea lor sunt gata
Mediul pentru testele de integrare a fost stabilit
Criterii de iesire
Toate sistemele implicate au trecut testele de integrare si indeplinesc toate cerintele de functionalitate si performanta cerute
Defectele nerezolvate au fost identificate, documentate si prezentate managerului general
Planul de implementare e in stadiul final
Trebuie sa se tina o sedinta de tranzitie a testelor si toata lumea sa fie de acord cu el
Testarea de integrare are un numar de subtipuri de testare ce pot fi folosite sau nu, in functie de aplicatia ce trebuie testata sau de modul in care aceasta ar putea fi folosita.
Testarea de compatibilitate – asigura functionalitatea corecta pe diferite configuratii de sistem bazate pe ce au userii sau pe ce ar putea avea. Cand testam o aplicatie web, asta inseamna ca testarea se va face pe mai multe browsere cu diferite viteze de conexiune
Testarea performantei – este folosita pentru evalua si intelege scalabilitatea aplicatiei daca de exemplu este utilizata de mai multi useri sau volumul de date creste. Este foarte importnata pentru a identifica scaderile de performanta pentru aplicatiile cu o utilizare mare. Abordarea de baza, este sa se colecteze timpi pentru procesele de business critice in timp ce sistemul de test este supus la o incarcare mica si apoi colectarea acelorasi timpi la o majorare progresiva a incarcarii pana cand este atins maximul necesar. Pentru o aplicatie care preia date, revizuirea modelului de performanta poate arata dace e nevoie de modificari in procedurile stocate din SQl sau daca trebuie adaugat un index in design-ul bazei de date.
Stress Testing – este testarea performantei aplicatiei la incarcari simulate mai mari decat cele normale. Aceste teste solicita sistemul sau aplicatia pestele limitele specificate in cerinte, pentru a determina la ce incarcare cedeaza si cum cedeaza. Incetinirea sistemului la o incarcare mai mare este rezultatul ideal, fara sa aduca daune sistemului, dar daca sitemul cedeaza este foarte important sa stim cand se poate intampla acets lucru. Daca un system cedeaza acest lucru atrage dupa sine oameni care terbuie sa fie la lucru in afara programului, restartarea sistemului si posbile pierderi financiare. Acest tip de testare este cea mai importanta pentru sistemele critice.
Testele de incarcare – sunt opusul testelor de stres. Testeaza capacitatea aplicatiilor de a functiona normal, in conditii normale asteptate din productie si masoara timpul de raspuns pentru tranzactiile si procesele critice, pentru a determina daca sunt in limitele cerute de cerintele de business si de design. Pentru aplicatii cu baze de date, testeara incarcarii terbuie facuta pe o baza de date de aceeasi dimensiune ca cea din productie. Daca anumite baze de date sunt fortate sa cerasca in viitorul apropiat atunci trebuie testate cum trebuie bazele de date cu dimeniunile cerute la proiectare.
Testele de performanta, stress si de incarcare sunt niste angajamente majore si trebuie sa li se acorde o atentie speciala de catre mangeri si departamentul de IT, pentru a avea un mediu de test si a face un design ale cazuriloe de test care sa permita executarea cu acuratete. Din aceasta cauza aceste teste cateodata sunt facut mai tarziu si fac parte din faza testelor de acceptare. Testele de incarcare, in special, trebuie sa fie documentate in detaliu astfel sa poata fi repetate in cazul in care trebuie rulate de mai multe ori, pentru a ne asigura ca noile versiuni ale produsului sau modificarile dimensiunii bazei de date, nu modifica timpul de raspuns in afara intervalelor stabilite in cerinte.
Testele de acceptare din partea userului (User Acceptance Testing – UAT)
Mai este numita si testare Beta, testarea aplicatiei si testarea end-user. Este stadiul in care testarea se muta de la deprtamentul de IT catre useri. Furnizorii de software deseori folosesc varianta Beta pe o scara larga de useri, unii mai mult ca altii pentru ca obtin o testare facuta de userii finali si e gratis.
Momentul cand aceasta va incepe este dup ace departamentul de IT a reparat intr-un mod sau altul toate defectele identificate de ei. Indiferent de eforul lor sigur nu vor gasi toate problemele din aplicatie. O regula generala este aceea ca indifferent de cat de sigura pare sa fie aplicatia, cand ajunge la testarea efectuata de user, acesta poate gasi undeva o secventa de cod ce poate produce o eroare.
Pentru a fi de real ajutor, tesarea de acceptare nu poate fi facuta de useri alesi intamplatori care sa foloseasca aplicatia. Trebuie facut un mix de useri care ce folosesc o aplicatie de acest gen, cu diferite grade de experienta si expertiza care sa participe activ la testarea aplicatiei intr-un mediu controlat. Reprezentanti ai grupului de useri vor lucra alaturi de coordonatorii de testare, pentru a crea teste ce reflecta activitatea si conditiile existente intr-un proces de folosire normal. Acesti useri participa si la evaluarea reultatelor date de teste. Ei vor asigura faptul ca aplicatia este testata in situatii din lumea reala si ca testele acopera comportamentul tuturor tipurilor de useri. Scopul UAT este de a simula activitati si procese de business realiste in mediul de test.
O etapa a testelor de acceptare numita Testare Nestructurata se va face sau nu in functie de existent ei in planul de testare. Stiuta si sub numele de testare de gherila, consta in incercarea de a se gasi punctele slabe ale aplicatiei, incercand sa strice aplicatia, fiind un tip de testare liber, userii care participa intelegand ca trebuie sa fie capabili sa reproduca problema gasita, altfel nu e de nici-un folos.
O intamplare obisnuita in UAT este aceea ca odata ce userii icnep sa lucreze cu aplicatia isi vor da seama daca ea va face exact ce se asteapta sa faca sau daca va face acest lucru, chiar daca e correct, poate nu e chiar optim in unele cazuri. Invetigarea va gasi ca problema vine chiar de la cerintele de business, deci userii vor cere o modificare.
Criterii de intrare si criterii de iesire pentru testele de acceptare.
Criterii de intrare:
Testele de integrare au fost aprobate cu success
Cerintele de business au fost indeplinite sau renegociate cu managerul general sau reprezentantul sau
Scripturile testelelor de acceptare sunt gata de executie
Mediul de test a fost stability
Cerintele de securitate au fost documentate si li s-a acordat accesul userilor ce vor testa aplicatia
Criterii de iesire:
Testarea a fost finalizata si aprobata de comunitatea de useri intr-o intalnire.
Se vor gestiona cerintele si modificarile solicitate
Managerul trebuie sa-si dea acordul ca defectele identificate nu vor afecta negative lansarea produsului
Testarea in conditii de productie
Este tot o metoda de testare si este sansa finala pentru a determina daca un produs software este gata de lansare. Scopul acestei metode de testare este de a simula trecerea in productie cat de mult posibil si pentru o perioada de timp sa se simuleze activitati reale de folosire a produsului. Este ca o repetie generala si ar tebui sa identifice anomalii sau modificari neasteptate ale proceselor existente deja, introduce de noua aplicatie.
Aplicatia ar tebui complet scoasa din mediul de testare si reinstalata exact ca si cum ar fi in productie. Atunci se va verifica daca procesele de business, flow-urile, interfetele si procesele de incarcare continua sa ruleze correct. Spre deosebire de testarea in parallel in care sistemele noi si vechi rulau unul langa altul, acum e posibil sa nu obtinem date corecte din cauza limitarilor bazei de date testate sau a surselor de date.
Criterii de intrare si criterii de iesire pentru testele in conditii de productie.
Criterii de intrare:
Testarea de acceptare a fost terminate si aprobata de toate aprtile
Defectele cunoscute sunt documentate
Documentatia pachetului de migrare a fost efectuata, revazuta si aprobata de ctare managerul de sisteme de productie.
Criterii de iesire:
Pacehtul de migrare este complet
Testarea instalarii a fost facuta si documentata si rezultatele au fost verificate
Testarea mostrei a fost documentata, revazuta si aprobata
Toate testele indica faptul ca aplicatia nu va afecta in mod negative mediul de productie
Un system de inregistrare a modificariloe cu aprobari a fost pregatit
Testarea de regresie
Este cunoscuta si ca testarea de validare ce furnizeaza o validare sonsistenta si repetitiva a fiecarei modificari din aplicatie aflata in dezvoltare sau care este modificata. De fiecare data cand un defect este reparat, exista riscul ca in aplicatie sa fie introdus un alt defect, eroare sau problema.
Testarea de regresie, reprezinta retestarea selectiva a unei aplicatii sau sistem, ce a fost modificat, pentru a ne asigura ca toate componentele, functiile sau functionalitatile ce functionau anterior, nu au fost stricate dupa repararea defectului descoperit.
Testarea de regresie poate fi executata in paralel cu alte teste si poate fi privita ca un control al calitatii, pentru confirma ca dupa modificarea codului, codul modificat se va comporta conform cerintelor si ca partea de cod nemodificata nu a fost afectata de modificare. Este important de inteles ca testarea de regresie nu testeaza daca un anumit defect a fost rezolvat, aceasta verifica daca restul aplicatiei dupa rezolvarea defectului nu a fost afectata in mod negative de catre reparatie.
Criterii de intrare si criterii de iesire pentru testele in conditii de productie.
Criterii de intrare:
Defectul se poate reproduce si a fost documentat corespunzator
A fost deschisa o inregistrare de urmarire a defectului pentru a identifica si urmari efortul testarii de regresie
Un test de regresie specific defectului a fost creat, revazut si acceptat
Criterii de iesire:
Rezultatele testelor arata ca nu exista un impact negative asupra aplicatiei
Capitolul 3 – Testarea sistemelor distribuite bazate pe tehnologia Internet
Componentele unui sistem distribuit
Aplicațiile distribuite constau în mai multe componente ce rulează pe mașini diferite, acestea
aplicații integrând acțiunile componentelor lor. Proiectarea aplicațiilor distribuite se axează nu
numai pe detaliile părților individuale, ci și pe realizarea unei integrări a componentelor
distribuite, astfel încât acestea să coopereze foarte bine între ele. Un sistem distribuit are ca
principale componente: hardware distribuit; și/sau control distribuit (soft de sistem); și/sau date
distribuite (soft de aplicații).
Hardware distribuit
1. Un sistem distribuit trebuie să conțină două sau mai multe sisteme de calcul, fiecare cu
procesorul și memoria lui locală. Acest aspect al distribuției fizice este foarte important în
definirea unui sistem distribuit.
2. Pentru ca aceste calculatoare distribuite să poată comunica, este nevoie de o formă de
rețea de comunicare.
3. Distribuirea calculatoarelor poate reflecta distribuirea fizică a aplicației sau
descompunerea funcțională a sistemului, unde sisteme de calcul diferite realizează funcții
diferite (de exemplu procesoarele dedicate).
Control distribuit
1. Sistemele conțin resurse fizice sub forma procesoarelor, imprimante, etc. precum și
resurse logice sub forma proceselor, fișierelor etc.
2. Strategia folosită pentru controlul resurselor poate fi centralizată ierarhic sau să permită o autonomie completă a procesoarelor individuale peste resursele locale. Această ultimă
abordare necesită o cuplare slabă între componentele sistemului (de exemplu rețelele de
calculatoare).
3. În multe cazuri se încearcă obținerea unei transparențe, în sensul că sistemul apare ca un
sistem unic, uniform, ascunzând distribuția fizică și neomogenitatea componentelor sale.
Datele distribuite
1. Una din resursele majore ce necesită control și din partea sistemului și din partea aplicației sunt datele.
2. Datele în curs de procesare pot fi distribuite prin: replicare (copii multiple la locații
diferite); partiționare (părți ale lor sunt stocate în diferite locații).
3. Datele sunt adesea distribuite atât pentru a crește toleranța la defecte, cât și pentru a
permite creșterea performanței prin stocarea datelor în apropierea zonelor unde sunt produse sau folosite.
Modele de organizare a aplicațiilor distribuite
Există următoarele modele de organizare a aplicațiilor distribuite:
1. aplicații tip „client ‐ server”, care presupun executarea unui volum important de prelucrări locale sau autonome și partajarea resurselor de calcul sau date
2. aplicații pe „cluster”, presupun utilizarea mai multor calculatoare conectate în rețea, sub
forma unei resurse unice
3. aplicații distribuite colaborative, care oferă posibilitatea participării mai multor persoane
la atingerea unui obiectiv sau a mai multora, prin intermediul tehnologiei calculatoarelor –
calcul plus comunicații
4. metacalculul, care se referă la utilizarea unui număr foarte mare de resurse de calcul,
foarte puternice și distribuite pe o arie mare, pentru rezolvarea unor probleme de o mare
complexitate.
Modele arhitecturale specifice. Modelul cu acces neuniform la memorie NUMA (Non‐Uniform
Memory Acces). NUMA cu memorii locale distribuite este o structură de sistem strâns cuplat
folosită de obicei în cazul supercalculatoarelor. NUMA ierarhic cu clustere (ciorchine sau
grupare de stații de lucru legate printr-o rețea care cooperează la realizarea unui țel comun).
Clusterul poate fi de tip NUMA sau UMA. Cazul conectării tip Butterfly local este cel mai rapid,
iar cel la distanță cel mai lent.
Figura 3.1. – Modelul NUMA
Modelele calcului distribuit
1. modelul “fermă de procesoare”: se caracterizează prin existența unui ansamblu de
elemente de prelucrare generice și de servere cu funcții specifice, ale căror facilități sunt
accesate de la stații de lucru, care în general au resurse de calcul și de memorare reduse.
2. modelul “client-server”: presupune executarea unui volum important de prelucrări locale
sau autonome și partajarea resurselor de calcul sau date.
3. modelul “data flow”: se bazează pe organizarea prelucrării conform unui graf în care nodurile sunt elemente de prelucrare, iar arcele sunt conexiuni logice prin care circulă mesajele.
4. modelul ierarhic: resursele de prelucrare sunt organizate (fizic sau logic) într-o rețea de
prelucrare arborescentă. În mod curent, nivelurilor mai înalte ale ierarhiei le sunt asociate
resurse de prelucrare mai puternice.
5. modelul “cache”: se bazează pe prelucrări realizate etapă cu etapă, efectuate de diverse
elemente de calcul, și pe combinarea rezultatelor parțiale pe un alt element de calcul, de
regulă mai puternic. O strategie de partajare a operațiunilor este adecvată în acest caz.
Modelul Client Server
În sistemele de operare pentru rețele de calculatoare se utilizează de cele mai multe ori
modelul client-server.În acest caz sistemul de operare conține, în afară de nucleu, un grup de procese numite servere, care oferă servicii proceselor utilizator, acestea devenind astfel clienți.
Există procese specializate care realizează diferite servicii, cum ar fi: lucrul cu fișiere,
compilare, tipărire etc. Un proces care are nevoie de o astfel de acțiune, o cere de la unul din
serverele care sunt dedicate pentru respectivul tip de problemă.În timpul execuției diferite procese pot fi atât client, cât și server; de exemplu serverul de fișiere poate deveni client pentru serverul care oferă timpul curent.
Dacă atât serverele, cât și clienții se execută în spațiul de memorie utilizator, structura
nucleului se simplifică mult, rolul acestuia din punctul de vedere al comunicației
restrângându-se la trimiterea și recepționarea de mesaje.Dacă realizarea comunicației se bazează pe operații de tipul transmisie sau recepție, înseamnă că elementele principale utilizate în programare sunt de tip operație de intrareieșire. Activitățile din timpul execuției unei aplicații distribuite sunt asociate de obicei, abstractizării de proces și ele nu vor putea să existe decât ca părți ale aplicației.
Un sistem client-server este realizat pe trei nivele, cel al prezentării, cel al aplicației și cel alaccesului la date. Separarea fizică a celor trei nivele se numește partiționarea aplicației.
Întotdeauna nivelul prezentării va fi implementat de către client. Împărțirea celorlalte două
nivele între client și server conduce la 5 stiluri diferite: prezentare distribuită; prezentare la
distanță; aplicație distribuită, când calculele sunt împărțite între client și server; date la
distanță; date distribuite.
Figura 3.2. – Arhitectura client/server
Aplicațiile distribuite acționează într-un mediu foarte diferit de cel al aplicațiilor client/server. în paradigma client/server, componentele aplicației software sunt folosite de către calculatorul client și calculatorul server. în mediul aplicațiilor distribuite, aplicația poate avea componente care să ruleze pe mai multe calculatoare din rețea. Diferența dintre client și server dispare. În mod evident, o componentă a unei aplicații distribuite acționează atât drept client, cât și ca server.
Avantajele sistemelor distribuite
1. Costuri reduse i s-a demonstrat economic că este mult mai ieftin să se folosească mai multe sisteme de calcul la rezolvarea unei probleme complexe, decât unul foarte performant.Acesta are un cost foarte mare și este dedicat, în general, numai un flux continuu de
probleme de calcul de foarte mari dimensiuni.
2. Modularitatea și simplitatea soft-ului – sistemele distribuite pot fi construite într-o manieră foarte modularizată, unde fiecare componentă permite interfațarea cu restul sistemului
(celelalte componente) sau servicii foarte bine definite. Modularitatea permite o proiectare
simplă a sistemului, instalare și întreținere mai simple.
3. Flexibilitatea și extensibilitatea – modularitatea sistemului permite schimbarea sau
modificarea elementelor de calcul fără a deranja major operațiile în curs de desfășurare. Prin
folosirea protocoalelor standard de comunicații este posibil să se includă într‐o rețea
echipamente provenind de la diferiți producători, rezultând o rețea omogenă.
4. Fiabilitate și integritate sistemele distribuite au proprietatea de a putea continua
operațiunile indiferent de starea unei părți a sistemului folosirea mai multor noduri de calcul
permite ca, în cazul defectării sau blocării unei resurse, sistemul să continue activitatea
resurselor critice, în acest caz, pot avea control dublu sau triplu dacă softul este proiectat în
stil tolerant la erori, sistemul poate continua absolut toate calculele în curs, prin redirectarea
task‐urilor de calcul care nu mai răspund spre alte procesoare
5. Performanța este în general definită în termenii timpului de răspuns la un anumit grad de
încărcare timpul de răspuns poate fi scăzut, în mod particular dacă majoritatea procesării
este făcuta local paralelismul datorat nodurilor multiple reduce defecțiunile și încetinirile ce
pot apărea la nivelul proceselor de calcul și generează o creștere a performanței globale
software-ul local poate fi folosit și la preprocesarea sau compactarea datelor, reducându-se
astfel încărcarea pe rețeaua de comunicație și crescând performanțele sistemului.
Rețelele de calculatoare au o extindere rapidă, intr-o multitudine de domenii cum ar fi sistemul bancar, administrația publică, alocarea temporara de resurse în hoteluri, rezervarea de bilete de avion rezervarea biletelor de tren etc. Aplicațiile moderne iau în considerare accesul unui număr cât mai mare de utilizatori, mai ales cand se prevede extinderea folosirii cardurilor și crește numărul acelora care utilizează Internetul.
Proiectarea aplicațiilor distribuite se axează nu numai pe detaliile părților individuale, ci și pe realizarea unei integrări a componentelor distribuite, astfel încât acestea să coopereze foarte bine între ele.
Principalele cerințe pentru aplicațiile distribuite sunt:
• interfețe puternice;
• fiabilitate foarte mare;
• securitate ridicată;
• viteză ridicată de prelucrare și transmitere a datelor.
În mod tradițional, aplicațiile software distribuite se bazează pe arhitectura client/server sau pe arhitectura multistrat (n-tier).
În contextul aplicațiilor client/server care utilizează baze de date, arhitectura client/server presupune existența unui server de baze de date(denumit server) și a unui modul software specific aplicației (denumit client) care prelucrează daÎtele și prezintă rezultatele, deci conține logica aplicației și logica prezentării. În acest sistem nu există noțiunea de obiecte, partea de client lucrează direct cu tabelele de date și procedurile stocate din baza de date.
În cadrul arhitecturii multistrat, un server de aplicații se interpune între aplicația de client și serverul de baza de date. Serverul de aplicații implementează logica de aplicație, iar clientul implementează logica de prezentare a sistemului. Avantajul major al arhitecturii multistrat față de arhitectura client/server îl reprezintă cresterea fiabilitătii.
Arhitectura Web confera acestora fiabilitate, scalabilitate și flexibilitate ridicată. Aceasta diferă față de arhitectura multistrat prin doua aspecte:
– aplicația client are o complexitate redusa, fiind un navigator Web;
– nivelul regulilor aplicației este bazat pe componete și nu este un singur sistem ce implementeaza intreaga construcție.
Figura 3.3. – Arhitectura Web
Componentele client sunt interfețele grafice utilizator și ruleaza în navigatoare Web precum Netscape Navigator sau Internet Explorer.Componentele Server care ruleaza într-un server de aplicații,furnizeaza logica procesului de afaceri.
Pentru testarea aplicațiilor distribuite bazate pe internet, trebuie luate în considerare urmatoarele aspecte:
-> capacitatea de utilizare; usurința în utilizare și intelegerea elementelor interfeței constituie elemente importante în acceptarea aplicației de catre clienti;
-> funcționalitatea; faptul ca aplicația realizeaza ceea ce isi propune prin specificații conduce la cresterea increderii utilizatorilor în aceasta și în firma producatoare;
-> compatibilitatea; avand în vedere faptul ca exista o multitudine de combinații intre sisteme de operare, navigatoare și aplicațiile care ruleaza în navigatoare, asigurarea compatibilitatii aplicației este o problema importanta, deoarece exista riscul ca o parte importanta dintre potentialii utilizatori să nu poate utiliza aplicația datorita incompatibilitatii și astfel sunt pierduti o serie de clienti;
-> performanta; timpul de raspuns și resursele ocupate reprezinta un aspect important pentru utilizatorii aplicației.
În cazul aplicațiilor Internet care acceseazǎ baze de date existǎ o multitudine de cauze care duc la funcționarea incorectǎ a acestora. De exemplu, testul eșuat al unei tranzacții într-o bazǎ de date poate avea mai multe cauze:
a. logica bazei de date: procedurile stocate, interogǎrile sau comenzile de actualizare, inserare sau ștergere contin erori;
b. logica serverului de aplicații: existǎ erori de proiectare sau de programare în cadrul funcțiilor implementate în serverul de aplicații;
c. logica procesǎrii tranzactiilor: ordinea eronatǎ a efectuǎrii unor operații conduce la eșuarea intregii tranzacții;
d. comunicația: în cazul unor probleme de comunicație la diverse niveluri, tranzacțiile fie nu au loc, fie se realizeazǎ incomplet sau incorect.
Testarea aplicațiilor bazate pe arhitectura Web, în plus fața de testarea aplicațiilor clasice, necesita o serie de teste specifice cum ar fi:
– testarea funcționala
– testarea de compatibilitate
– testarea continutului
– testarea performanței
– testarea de incarcare
– testarea securitații
– testarea serverului Web, al serverului de aplicații și testarea bazelor de date.
Testarea funcțională se realizează pentru a constata dacă site-ul se comportă conform cu specificațiile sale. Detaliile acestui tip de testare depind de natura site-ului Web si, în general, constă în verificarea legăturilor paginilor, testarea formularelor, verificarea tranzacțiilor pentru comertul electronic și pentru baze de date, testarea apleturilor java.
Prin testarea de compatibilitate se urmăreste aspectul și comportamentul site-ului Web în raport cu o varietate de sisteme de operare și de navigatoare Internet. Această testare scoate în evidentă problemele cu controalele ActiveX, apleturile Java, funcțiile JavaScript sau VBScript și formulare din pagini. La ora actuală există peste 100 de combinații posibile intre diverse sisteme de operare Windows și diverse versiuni ale navigatoarelor NetScape și Internet Explorer.
Pentru testarea conținutului se urmăreste corectitudinea și asezarea în pagina a textelor, imaginilor și a fisierelor de animatie și video din cadrul site-ului.
Prin testarea performanțelor se măsoară comportamentul site-ului Web în diverse condiții de trafic.
Testarea de incărcare se utilizează pentru a verifica daca site-ul Web poate gestiona un anumit număr de utilizatori care il accesează concurent, în limite acceptabile ca timp de răspuns.
Testarea securitatii tranzactiilor efectuate este foarte importanta pentru aplicațiile de comert electronica avand în vedere faptul ca sunt vehiculate date confidențiale, la care daca au acces persoane neautorizate sau rauvoitoare se pot produce pierderi materiale importante.
Testarea serverului Web are în vedere testarea interacțiunilor dintre serverul Web și serverul de aplicații, verificarea integritatii bazei de date în cadrul serverului de baze de date, verificarea faptului ca scripturile ASP, PHP sau JSP se execută correct pe server.
Testarea serverului de aplicații se realizează tinăndu-se seama de caracteristicile funcționale și structurale ale acestuia. Se testează componentele serverului, folosind metode clasice de testare, precum și metode de testare care iau în considerare tranzacțiile și comunicațiile asincrone dintre aceste componente.
Testarea bazelor de date presupune verificarea executarii corecte a interogarilor și operatiilor de adaugare și actualizare a datelor, precum și verificarea conexiunilor dintre site-ul Web și baza de date.
Testarea aplicațiilor distribuite bazate pe arhitectura Web este realizata fie de catre echipe de specialitate din cadrul departamentului de asigurare a calitatii a firmei, fie de catre o firma specializata în testare(out-sourcing).
Capitolul 4 – Testarea automată
În noua economie, producătorii de soluții IT sunt confruntați cu o nouă cerință care îi obligă să schimbe total modul de constructie a unui produs, fără a face compromisuri de calitate. A fi primul pe piață cu ultimele tehnologii este mai important ca oricând. Lucrând cu o infrastructura software și hardware din ce în ce mai complexă, confruntați cu creșterea continuă a cerințelor de calitate și cunecesitatea reducerii costurilor, firmele de software încep să prețuiască tot mai mult soluții solide, inginerești, de dezvoltare de software. Testarea produsului este în software o componentă majoră în procesul de dezvoltare. În limbaj de specialitate se discută despre asigurarea calității (Quality Assurance).
Firmele din industria tradițională – de ex. industria de mașini, de construcții, de produse electronice sau alimentare au de zeci de ani departamente de testare și verificare a calității. În materie de software, organizarea și automatizarea muncii de testare și verificare a produselor a început din motive istorice evidente abia în anii '80. Testarea manuală, mult timp văzută ca singura soluție de a descoperi eventualele defecte, întârzie foarte mult lansarea pe piață a produsului și induce cheltuieli semnificative mai ales în cazul descoperirii efectelor laterale – atât în procesul dezvoltării unei aplicații cât și în cazul de schimbări ulterioare.
Totodată procedurile de testare manuală, prin natura lor limitată, nu reușesc să descopere toate defectele și nu au nicio șansă să simuleze condiții de utilizare simultană, 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 reduca proape la zero.
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. 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.
De ce este testarea automată atât de importantă pentru companii?
Testarea automată salvează timp și bani – testele software trebuie să fie repetate des în timpul ciclului de dezvoltare pentru a asigura calitatea. De fiecare dată cand codul sursa este modificat testele trebuie repetate. Pentru fiecare release al software-ului tb testate toate sistemele de operare și configuratiile hardware pe care aplicația le suportă. Dacă se efectuează manual aceste teste, duce la costuri mari și timp consumat. Odata create testele automate pot fi rulate și rerulate fără cost aditional și sunt mult mai rapide ca testele manuale. Automatizarea testelor pot reduce timpul testelor repetitive de la cateva zile la cateva ore. Automatizarea economiseste timp, timp ce se poate traduce în economisirea costurilor.
Testarea imbunătăteste acuratetea – chiar și cei mai constiinciosi testeri vor face greseli în timpul testarii manuale care poate deveni foarte monotona cand e repetitivă. Testele automate execută aceeasi pasi, precis, de fiecare dată cand sunt executate și nu omit să inregistreze detaliile rezultatelor.
Cresterea acoperirii testelor – testarea automată poate creste profunzimea și aria de testare ce ajută la cresterea calitătii produsului. Testele lungi care sunt adesea evitate de testeri pot fi acum rulate fara să fie supravegheate. Ele pot fi rulate chiar în paralel pe mai multe calculatoare cu configuratii diferite. Testele automate se pot uita în interiorul uneia aplicații și pot vedea continutul memoriei, tabele cu date, continutul fisierelor și starea programelor pentru a determina daca produsul se comporta conform asteptarilor. Testele automate pot executa usor sute de test case-uri diferite și complexe la fiecare rulare reusind să asigue o acoperire ce este impsobil de facut prin testarea manuala. Testerii sunt eliberati de testarea manuala repetitiva avdn mai mult timp pentru crearea de noi teste automate și mult mai complexe.
Automatizarea face ceea ce testarea manuala nu poate face – pana și cele mai mari departamente de dezvoltare software nu pot simula controlat testarea aplicației cu cateva sute de useri. Testele automate pot simula zeci, sute și chiar mii de useri virtuali care interactioneaza cu reteaua și cu aplicația
Testarea automatizata ajuta și developerii și testerii – testele automate share-uite pot fi folosite și de programatori pentru a identifica probeleme repede inainte de a la trimite la QA. Teestele pot rula automat atunci cand codul este modificat și pot notifica echipa daca acestea pica. Facilitatile ca acestea economisesc timp pentru progamatori și creste increderea.
Creste moralul echipei – acest lucru este greu de masurat dar a fost exeperimentat și testele automatizate pot creste moralul echipei. Automatizand task-urile repetitive cu ajutorul testelor, acorda mai mult timp aomenilor din echipa pentru proiecte sau task-uri mult mai interesante și challenging. Oamenii isi imbunatatesc
Testarea Manuala vs Testarea Automată
Nu toate testele pot fi automatizate și de cele mai multe ori poate fi dificil de decis ce să se automatizeze și ce să se testeze manual. în urmatoarele randuri va prezentam cateva avantaje și dezavantaje ale ambelor solutii.
Tool-uri pentru testarea automată:
Voi enumera cateva tool-uri pe care le-am folosit, de altfel sunt si cele mai populare, pentru testarea aplicatiilor:
HP Unified Functional Testing este cea mai noua versiune a vechiului QuickTest Professional – este un produs dezvoltat de cei de la HP si ca orice produs are avantajele si dezavantajele lui.
Ca avantaje ar fi:
usurinta scrierii testelor
integrarea cu ALM (Application Lyfecycle Management). Integrarea celor doua solutii ofera un sistem complet de scriere de teste si rulare de teste, avand suport pentru fiecare etapa a testelor incepand cu etapa de cerinte.
se pot scrie atat teste functionale cat si teste de performanta
cu ajutorul acestui tool se pot automatiza teste si pentru aplicatii web cat si pentru aplicatii desktop
Dezavantaje:
pretul – e un produs foarte scump
limbajul de programare in care se scriu testele, VBScript, practic singurul browser nativ pe care sunt executate testele este Internet Exlporer. Se pot rula teste si pe celalate browsere dar versiunile suportate sunt mereu in spate.
fiind un sistem foarte complex, asta duce la viteza mica de executie a testelor
Jmeter – este un tool open source si este folosit pentru a testa performanta site-urilor/aplicatiilor web. Este cel mai popular din categoria lui. Suportul pentru el este destul de bun.
Selenium WebDriver – este un tool open source si despre el vom vorbi mai pe larg in cele ce urmeaza.
Ce este WebDriver?
WebDriver este un framework rapid si curat pentru testarea automata a aplicatiilor web. De ce este nevoie de acest framework? Cum poate sa ajute in rezolvarea problemelor, mai mult decat framework-urile deja existente?
De exemplu, Selenium, este bine definit si un framework foarte popular; este un tool care pune la dispozitie o interfata care functioneaza pe un numar mai mare de browsere si care permite scrierea testelor in aproape orice limbaj de programare, de la Java sau C# la PHP sau Erlang!. Este unul din primele proiecte Open Source care aduc testarea bazata pe browsere si deoarece este scris in JavaScript face posibil adaugarea de noi browsere care ar putea fi suportate.
Ca orice proiect mare, nu este perfect. Selenium este scris in JavaScript, iar acest lucru aduce un minus signifiant: browserele impun un model de securitate foarte strict pe orice JavaScript pe care il executa pentru a putea proteja utilizatorul de scriptarea malitioasa. Exemple in care acest model de securitate face testarea mai grea, ar fi:
cand se incearca uploadarea unui fisier (IE nu permite JavaScript sa schimbe valoarea unui element dintr-un fisier INPUT) s
cand se incearca navigarea intre domenii (din cauza problemei politicii originii semnalului de baza).
Aditional, este un produs matur, API pentru Selenium RC a crescut in timp si acest lucru a facut sa fie din ce in ce mai greu de inteles modul lui de utilizare. De exemplu, nu este din prima evident daca ar trebui sa fie folosit „ type” sau „ typeKeys” pentru a introduce un text intr-un input. Desi tine de estetica, unii utilizatori gasesc acest produs intimidant si greu de folosit.
Versiuni de Selenium
Selenium Core sau simplu Core este un set de script-uri JavaScript care controleaza browser-ul, imitand activitatea unui utilizator. Aceste script- uri sunt introduse in pagina web in functie de lista actiunilor scrise intr-un tabel special de comanda din HTML sau Selense, astfel simuland activitatea utilizatorului.
Selenium RC sau Selenium Remote Control sau Selenium 1 primeste comenzi Selenium Core prin HTTP si le executa pe o unitate remote, folosind proxy- uri pentru a preveni restrictia aceleasi origini. Acest lucru permite scrierea testelor in alte limbaje ca C#, Python, Perl, PHP, Java si Ruby (prin legaturi de limbaje pentru Selenium Core).
Selenium WebDriver sau WebDriver sau Selenium 2 – este un succesor al Selenium RC. Face acelasi lucru, dar intr-un mod diferit: in loc sa introduca un cod JavaScript in browser pentru a simula activitatea unui user, foloseste chiar suportul browser-ului pentru automatizare ( fiind diferit pentru fiecare browser). De asemenea, in loc sa foloseasca un dictionar API ( folosit in Selenium RC), ofera un API orientat pe obiecte.
Selenium Server – permite utilizarea Selenium WebDrive pe o unitate remote.
Selenium IDE – este un addon pentru Firefox care inregistreaza activitatea utilizatorului si creaza teste bazate pe aceasta activitate. De asemena poate rula testele din nou si se pot salva ca programe in diferite limbaje de programare..
Selenium Grid – permite rularea testelor pe mai multe masini odata si in acelasi timp pe browsere diferite; cu alte cuvinte permite executarea testelor distribuite.
Selense – este un „ limbaj” special reprezentat de un set de comenzi Selenium care ruleaza testele. O astfel de secventa de comanda se numeste test script.
De unde sa incepem? (mai bine zici Avantaje)
Este bine sa se inceapa cu Selenium IDE. Te ajuta sa devii mai familiar cu comenzile din Selenium si se va putea vedea cum functioneaza Selenium prin rularea scripturilor direct din tool. Cand se ruleaza testele prin Selenium IDE, se executa intr-un mod diferite decat atunci cand sunt rulate folosind alte tool- uri Selenium. Daca este nevoie sa se testeze aplicatii, mai bine se utilizeaza Selenium WebDriver sau Selenium RC. Totusi, pe primul loc ar fi Selenium WebDriver, pentru ca este varianta imbunatatita a Selenium RC, care, oficial a fost depreciat.
Putina Istorie
2004 – Jason Huggins a creat tool-ul bazat pe JavaScript, pentru testarea automatia numit Selenium (stiut ca si Selenium Core). Mai tarziu Selenium Remote Control sau Selenium RC a fost dezvoltat sa permita mai multor limbaje sa se lege si sa controleze browserele la distanta
2006 – Simon Stewart a inceput sa lucreze la un alt tool de testare web denumit WebDriver.
2009 – Selenium RC si WebDriver fuzioneaza intr-un singur proiect denumit Selenium WebDriver sau Selenium 2.0.
2013 – Este lansat primul draft functional al WebDriver API, conform specificatiilor W3C.
Selenium WebDriver
Introducere in WebDriver
Trasatura principala a Selenium 2.0 este integrarea cu WebDriver API. WebDriver este proiectat pentru a pune la dispozitie o interfata de programare mai simpla si mai concisa compensand lipsurile ce le avea Selenium-RC API. Selenium WebDriver a fost dezvoltat pentru avea un suport mai bun pentru paginile web dinamice, unde elementele paginilor se pot schimba fara ca aceastea sa fie reincarcate. Scopul WebDriver este acela de a pune la dispozitie un mai bun API orientat pe obiecte care ofera un suport imbunatatit pentru probleme de testare ale modernelor si avansatelor aplicatii web..
Cum foloseste WebDriver browser-ul in comparatie cu Selenium RC?
Selenium WebDriver face apeluri direct la browser folosind suportul nativ al acestuia pentru automatizare.
Selenium- RC lucreaza la fel cu fiecare browser. „ Injecteaza” functii JavaScript in browser cand acel browser este incarcat si atunci foloseste functiile JavaScript pentru a utilzia AUT din browser.
Exemplu de script in WebDriver
WebDriver este un tool pentru automatizarea testarii aplicatiilor si in special verifica daca aceasta functioneze conform asteptarilor. Tinteste sa ofere un API prietenos care este usor de utilizat si de inteles, mai usor de folosit decat Selenium- RC ( 1.0) API, care te ajuta sa faci testele mai usor de citit si mentinut. Nu este legat de nici un framework in special, astfel poate fi folosit la fel de bine si in unit testing sau prin vechea metoda „ main”.
package org.openqa.selenium.example;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.support.ui.ExpectedCondition;
import org.openqa.selenium.support.ui.WebDriverWait;
public class Selenium2Example {
public static void main(String[] args) {
// Creaza o noua instanta a driver-ului pentru Firefox
WebDriver driver = new FirefoxDriver();
// navigam catre pagina www.google.com
driver.get("http://www.google.com");
// in mod alternativ navigarea catre un url se poate face si astfel:
// driver.navigate().to("http://www.google.com");
// Cauta input-u pentru cautare dupa numele lui
WebElement element = driver.findElement(By.name("q"));
// Tasteaza in input-ul cautat anterior cuvantul Cheese!
element.sendKeys("Cheese!");
// Va efectua cautarea. WebDriver fa gasi butonul dupa tipul elemetului
element.submit();
// Verifica titlul paginii
System.out.println("Page title is: " + driver.getTitle());
// Google's search is rendered dynamically with JavaScript.
// De aceea vom astepta 10 secunde ca pagina sa se incarce
(new WebDriverWait(driver, 10)).until(new ExpectedCondition<Boolean>() {
public Boolean apply(WebDriver d) {
return d.getTitle().toLowerCase().startsWith("cheese!");
}
});
// Titlul paginii ar tebui sa fie: "cheese! – Google Search"
System.out.println("Page title is: " + driver.getTitle());
// Inchide browser-ul
driver.quit();
}
}
Exemplul de mai sus este un exemplu bun pentru a intelege principiul de functionare al acetui tool de automatizare dar din experienta proprie, folosind Selenium in acest mod se poate ajunge la scripturi foarte mari, greu de citit si nescalabile la care mentenanta se poate face foarte greu ajungand sa ocupe foarte mult timp, deci costuri mai mari.
In acest sens pentru ca aceasta problema de scalabilitate sa fie evitata si pentru a face folosirea tool-ului mult mai usoara si inteligibila s-a creat un pattern de folosire numit Page Objects:
Ce reprezinta Page Objects:
Cand se scriu teste pentru o pagina web, trebuie sa se faca referire la elementele din acea pagina web pentru a putea accesa link-urile si a determina ce va afisa. Cu toate acestea, daca se scriu teste care manipuleaza elemntele HTML direct, testele vor fi mai fragile la schimbarile din UI. Page Objects impacheteaza o pagina HTML sau un fragment cu o aplicatie specifica API, permitand manipularea elementelor din acea pagina fara sa fie nevoie sa se caute pe langa, in HTML.
Regula de baza Page Objects este aceea ca ar trebui sa permita unui client soft sa faca si sa vada tot ce poate si un om. De asemenea ar trebui sa ofere o interfata care este usor de programat Ca sa accesezi un camp text ar trebui sa existe metode care fac asta si returneaza un string, pentur checkbox-uri ar terbui sa se folosesca boolean si butoanele ar trebui reprezentate prin metode care fac o actiune pe ele, click. Page Objects ar trebui sa encapsuleze mecanica necesara pentru a gasi si a manipula datele din GUI.
In ciuda termenului de obiect al paginii aceste obiecte nu ar trebui, de obicei, sa fie construite pentru fiecare pagina, ci mai degraba pentru elementele importante de pe pagina. Deci o pagina care arata multiple albume ar trebui sa aibe un obiect al paginii lista de albume, care sa contina mai multe obiecte pagina album. Acolo ar fi si un header si un footer ce pot fi incapsulate intr-un page objects. Regula page objects este sa structureze pagina intr-un mod in care sa aibe sens pentru userul aplicatiei
Sunt pareri diferite referitoare la Page Objects. Daca sa includa assertii in ele sau doar sa ofere date pentru scripturile testelor, pana la assertii. Sustinatorii introducerii assertiilor in obiectul paginii, spun ca acest lucru ajuta la evitarea duplicarii de assertii in teste si ca poate oferi mesaje de eroare mai utile. Cei ce sustin ca obiectele paginilor sa nu contina asertii, spun ca introducand assertiile amesteca responsabilitatile, in oferirea accesului la informatiile din pagina si conduce catre un obiect al paginii mare.
Este de preferat sa nu fie assertii in pagina obiect. Se poate evita duplicarea prin punerea la dizpozitie a unei librarii pentru assertiile comune – care, de asemenea, duc la o diagnosticare buna.
Obiectele paginilor sunt de obicei folosite pentru testare, dar nu ar trebui sa contina assertii in interiorul lor. Responsabiliatea lor este de a oferi acces la elementele paginii. Depinde de testeri sa-si faca logica assertiilor.
Problemele de concurenta sunt un alt topic pe care o pagina obiect le poate incapsula. Acest lucru ar putea implica ascunderea asincronizarea din operatiunile asincron care nu apar utilizatorului ca si asincron. De asemenea ar putea implica incapsularea impartirii problemelor in framework-ul UI unde trebuie sa ne ingrijoreze alocarea unui comportament intre UI si impartirea lucratorilor.
Paginile obiect sunt de obicei folosite in testare, dar de asemenea pot fo folosite pentru a oferi o interfata scriptata deasupra unei aplicatii. De obicei e mai bine sa pui o interfata scriptata sub UI, care este de obicei mai putin complicata si mai rapida. Totusi cu o aplicatie care pune prea mult comportament in UI apoi folosind pagini obiect se face cea mai buna treaba rea.
Modelele care muta logica din UI fac sa fie mai putin folositoare testarea prin UI si astfel reduce nevoia de Page Objects.
Paginile obiect sunt un exemplu clasic de incapsulare – ascund detaliile unei structuri UI si a lagaturilor cu alte componente (testele). Ca orice incapsularea aceasta duce la doua mari beneficii. Limitarea logicii care manipuleaza UI la un singur loc, poate fi modificata fara a fi afectate alte componente din sistem. Un alt beneficiu este acela ca face clientului codul mai usor de inteles pentru ca logica de acolo se refera la intentia testului nu se pierde un detaliile UI-ului.
In continuare folosind Selenium WebDriver si Page Objects am scris in Java cateva teste pentru clientul de email Gmail.
Am scris o suita de teste pentru interfata de login a acestui client de email, teste care vor acoperi cele mai multe cazuri posibile ce se pot intampla, inclusiv verificarea textelor din aceasta pagina.
Pentru a crea interfata paginii vom implementa o clasa LoginPage.class in care vom adauga toate elementele paginii si deasemenea metodele aferente actiunilor ce se pot face pe aceste elemente:
public class LoginPage {
public WebDriver driver;
public LoginPage(WebDriver driver) {
this.driver = driver;
}
Pagina contine mai multe elemente HTML ce vor fi reprezentate ca si WebElements. Identificatorul elementului trebuie definit o singura data.
By usernameInput = By.id("Email");
By passInput = By.id("Passwd");
By loginButton = By.id("signIn");
By staySigned = By.id("PersistentCookie");
By needHelp = By.id("link-forgot-passwd");
By newAccount = By.id("link-signup");
//texts and images in page
By h1 = By.xpath("html/body/div[1]/div[2]/div[1]/h1");
By h2 = By.xpath("html/body/div[1]/div[2]/div[1]/h2");
By profileImg = By.id("profile-img");
By profileName = By.id("profile-name");
By profileEmail = By.id("reauthEmail");
//error messages
By userOrPassIncorrectError = By.id("errormsg_0_Passwd");
By noUserError = By.id("errormsg_0_Email");
Pagina de login permite userului sa introduca userul in input-ul pentru user. Acesta este singurul loc care stie, cum, si unde, sa introduca username-ul. Metoda va returna obiectul paginii curente deorece aceasta actiune nu va naviga catre o alta pagina care la randul ei sa fie reprezentata de un alt obiect.
public LoginPage UsernameInputFill(String user) {
driver.findElement(usernameInput).sendKeys(user);
return this;
}
Acelasi lucru ca la user se va intampla si pentru input-ul dedicat introducerii parolei. Metoda va returna obiectul paginii curente
public LoginPage PassInputFill(String pass) {
driver.findElement(passInput).sendKeys(pass);
return this;
}
Metoda urmatoare va permite bifarea checkbox-ului folosit pentru login-urile uletiror ca userul sa fie tinut minte, la al doilea login userul va trebui sa introduca doar parola. Deasemenea va returna obiectul paginii curente.
public LoginPage CheckStaySigned() {
driver.findElement(staySigned).click();
return this;
}
Urmatoarele doua metode ne permit sa obtinem textele de la locurile specificate mai sus pentru elementele cu tagurile ha si h2 ale paginii cat si mesajele de eroare ce pot aparea in pagina. Le vom folosi ulterior pentru a valida daca textele sunt corecte. Metodele sunt de tip String si vor returna textele din locatia data.
public String H1Value() {
return driver.findElement(h1).getText();
}
public String H2Value() {
return driver.findElement(h2).getText();
}
public String UserOrPassIncorrectError() {
return driver.findElement(userOrPassIncorrectError).getText();
}
public String NoUserError() {
return driver.findElement(noUserError).getText();
}
Urmatoarele metode sunt pentru cazul in care s-a dorit login-ul cu checkbox-ul Stay Sign bifat si vor fi folosite sa validam ca pagina s-a modificat si ca elementele noi specifice acestui caz se afla in pagina.
Metoda de mai jos verifica daca exista poza userului, daca acesta are o poza da profil sau placehoder-ul pozei, daca nu are poza. E de tip intreg si va returna numarul de poze gasite in pagina.
public Integer ProfileImgExist() {
return driver.findElements(profileImg).size();
}
Metoda ProfileName() e de tip string si va obtine si returna numele utilizatorului care a ales ca datele de logare sa fie tinute minte.
public String ProfileName() {
return driver.findElement(profileName).getText();
}
La fel ca metoda anterioara, aceasta metoda va returna de aceasta data email-ul userului.
public String ProfileEmail() {
return driver.findElement(profileEmail).getText();
}
public LoginPage ClickInput() {
driver.findElement(passInput).click();
return this;
}
Urmatoarele metode sunt mai speciale, adica ele vor fi folosite pentru diferite actiuni a caror finalitate va fi parasirea paginii curente si navigarea catre alte pagini, ele returnand la apelarea lor obictele paginilor in care se va ajunge.
Mai exact, metoda de mai jos va da click pe link-ul Need Help din pagina de login, este folosit in cazul in care utilizatorul intampina probleme cu autentificarea. Ea va fi de tipul NeedHelpPage, deoarece la sfarsit va returna obiecul paginii Need Help, care va avea la randul ei elementele si metodele proprii. Acesta trebuie sa fie singurul loc din care se poate ajunge din pagina de login, in pagina Need Help.
public NeedHelpPage ClickNeedHelp() {
driver.findElement(needHelp).click();
return new NeedHelpPage(driver);
}
Exact ca metoda de mai sus, metoda ClickNewAccount va da click pe link-ul ce va duce in pagina in care userul isi poate crea un nou cont pe Gmail. Metoda va fi de tipul NewAccountPage si va returna obiecul paginii pentru crearea unui cont nou.
public NewAccountPage ClickNewAccount() {
driver.findElement(newAccount).click();
return new NewAccountPage();
}
Metoda LoginClickOk, este metoda care va da click pe butonul de login si care va duce in contu-ul de email al utilizatorului, de aceeas aceasta va returna obicetul paginii AccountMainPage.
public AccountMainPage LoginClickOk() {
driver.findElement(loginButton).click();
return new AccountMainPage(driver);
}
Metoda urmatoare este asemanatoare cu cea dinainte dar o vom folosi in cazul in care testam ca login-ul nu se va efectua din cauza anumitor erori. La fel, va da click pe butonul de login, dar cum login-ul nu se va efectua si nu vom naviga catre contul userului, ea va returna obiectul paginii login.
public LoginPage LoginClickNok() {
driver.findElement(loginButton).click();
return this;
}
Ultima metoda din aceasta clasa o vom folosi doar pentru navigare. Adica, daca vrem sa facem verificari in contul de email, pentru a nu apela de fiecare cand avem nevoie sa ajungem acolo metodele: UsernameInputFill(), PassInputFill() si LoginClickOk(), cream astfel o scurtatura catre acea pagina si vom apela doar aceasta metoda ce va returna la sfarsit obiectul paginii contului de email.
public AccountMainPage LoginOk() {
UsernameInputFill(Helper.USER);
PassInputFill(Helper.PASSWORD);
return LoginClickOk();
}
}
Luand in considerare clasa creata anterior avem urmatoarele Test Case-uri ce s-au automatizat pentru pagina de login. Voi scrie detaliat fiecare test case in ce consta si sub el codul scris pentru automatizare.
TC1: Login OK
Pasi:
Mergi la pagina de login: http://gmail.com
Introdu user valid
Introdu parola valida
Click Sign In
Rezultat asteptat: Trebuie sa ajungem in pagina ce reprezinta contul user-ului
@Test
public void LoginOk() {
LoginPage loginpage = new LoginPage(driver);
CommonMethods commonmethods = new CommonMethods(driver);
loginpage.UsernameInputFill(Helper.USER);
loginpage.PassInputFill(Helper.PASSWORD);
AccountMainPage accountMainpage = loginpage.LoginClickOk();
commonmethods.WaitUntilPresent(accountMainpage.composeButton, 20);
}
TC2: Login fara user
Mergi la pagina de login: http://gmail.com
Introdu parola
Click Sign In
Rezultat asteptat: tb sa apara mesajul de eroare „Enter your email address”
@Test
public void LoginWithoutUser() {
LoginPage loginPage = new LoginPage(driver);
loginPage.UsernameInputFill("");
loginPage.PassInputFill(Helper.PASSWORD);
loginPage.LoginClickNok();
Assert.assertEquals(loginPage.NoUserError(),"Enter your email address.");
}
TC3: Login fara parola
Mergi la pagina de login: http://gmail.com
Introdu user
Click Sign In
Rezultat asteptat: tb sa apara mesajul de eroare „Enter your password.”
@Test
public void LoginWithoutPassword() {
LoginPage loginPage = new LoginPage(driver);
loginPage.UsernameInputFill(Helper.USER);
loginPage.PassInputFill("");
loginPage.LoginClickNok();
Assert.assertEquals(loginPage.UserOrPassIncorrectError(),"Enter your password.");
}
TC4: Login utilizator gresit
Mergi la pagina de login: http://gmail.com
Introdu user invalid
Click Sign In
Rezultat asteptat: tb sa apara mesajul de eroare „The email or password you entered is incorrect.” si deasemenea cerculetul rosu cu semnul intrebarii cu link catre Help Page
@Test
public void LoginWithWrongUser() {
LoginPage loginPage = new LoginPage(driver);
loginPage.UsernameInputFill("sdsadad");
loginPage.PassInputFill(Helper.PASSWORD);
loginPage.LoginClickNok();
Assert.assertEquals(loginPage.UserOrPassIncorrectError(),"The email or password you entered is incorrect. ?");
loginPage.RedCircleExists();
}
TC5: Login parola gresita
Mergi la pagina de login: http://gmail.com
Introdu user invalid
Click Sign In
Rezultat asteptat: tb sa apara mesajul de eroare „The email or password you entered is incorrect.” si deasemenea cerculetul rosu cu semnul intrebarii cu link catre Help Page
@Test
public void LoginWithWrongPassword() {
LoginPage loginPage = new LoginPage(driver);
loginPage.UsernameInputFill(Helper.USER);
loginPage.PassInputFill("asdasd");
loginPage.LoginClickNok();
Assert.assertEquals(loginPage.UserOrPassIncorrectError(),"The email or password you entered is incorrect. ?");
loginPage.RedCircleExists();
}
TC6: Campul parola sa fie de tip password(transforma caracterele introduse in stelute la introducerea lor)
@Test
public void VerifyPassInputType() {
LoginPage loginpage = new LoginPage(driver);
Assert.assertEquals(loginpage.GetPasswordTypeAttribute(), "password");
}
TC7: Toate textele din pagina: One Google Account for everything Google, One account. All of Google si Sign in to continue to Gmail sa existe
@Test
public void ValidateTextsInPage() {
LoginPage loginPage = new LoginPage(driver);
Assert.assertEquals(loginPage.H1Value(), "One account. All of Google.");
Assert.assertEquals(loginPage.H2Value(), "Sign in to continue to Gmail");
}
TC8: Click pe link-ul Need help sa duca pe pagina cu titlul: Google Account Recovery
@Test
public void ClickOnNeedHelp() {
LoginPage loginpage = new LoginPage(driver);
loginpage.ClickNeedHelp();
Assert.assertEquals(driver.getTitle(), "Google Account Recovery");
}
TC9: Click pe Create an account sa duca pe pagina in care se poate crea un cont nou si in care exista titlul: Google Accounts<de vazut>
@Test
public void ClickOnNewAccount() {
LoginPage loginpage = new LoginPage(driver);
loginpage.ClickInput();
loginpage.ClickNewAccount();
Assert.assertEquals(driver.getTitle(), "Google Accounts");
}
Folosind acelasi principiu s-au creat si 2 scenarii de test mai complexe care acopera mai multe pagini conexe cu pagina de login pentru a arata si modul cum se poate naviga dintr-o pagina in alta si deasemenea cum se pot folosi elemente din fiecare pagina folosind clasele si metodele fiecarei pagini:
S1: Trimiterea unui email
Mergem in pagina de login: www.gmail.com
Introducem user valid
Introducem parola valida
Click Sign In
Click pe butonul Compose
Introducem destinatarul
Introducem subiectul
Click pe trimite
Verificam ca emailul cu subiectul introdus e in inbox
Parasire cont
@Test
public void Scenario1() throws InterruptedException {
Se creaza un obiect al clasei LoginPage, pentru a folosti elementel de acolo
LoginPage loginpage = new LoginPage(driver);
Se creaza un obiect al clasei CommonMethods, e o clasa in care vom scrie functii ce le folosim des, de exemplu: functiile cu ajutorul carora asteptam incarcarea unui element in pagina. Am ales aceasta metoda pentru a nu avea cod duplicat.
CommonMethods commonMethods = new CommonMethods(driver);
Cu ajutorul rumatoarelor 3 randuri se ajunge in pagina contului de email. Se putea folosi direct metoda de navigare din clasa paginii LoginPage, dar am vrut sa se observe pasii explicit catre pagina de cont. La sfarsitul rularii celor 3 randuri vom avea instantiata clasa AccountMainPage in obiectul accountMainPage.
AccountMainPage accountMainPage = loginpage.UsernameInputFill(Helper.USER)
.PassInputFill(Helper.PASSWORD)
.LoginClickOk();
Deorece dupa click-ul pe login avem un loader care permite incarcarea contului, am folosit functia WaitUntilPresent, ce permite executarea urmatoarei linii de cod din test dupa ce elementul specificat dintr-o pagina este incarcat, intr-un anumit interval maxim de timp. In cazul nostru asteapta ca butonul Compose sa fie prezent in maxim 5 secunde. Daca in cele 5 secunde butonul nu exista, testul va da fail.
commonMethods.WaitUntilPresent(accountMainPage.composeButton, 5);
Urmatoarea linie, da click pe butonul de compose email. La click pe acest buton se va deschide o fereastra, care va fi reprezentata prin alta clasa numita: NewEmailForm, si astfel vom avea obiectul newEmailForm.
NewEmailForm newEmailForm = accountMainPage.ComposeButtonClick();
Urmatoarele comenzi vor crea emailul, adica vor introduce destinatarul, subiectul, continutul si vor da click pe trimite, dar dupa ce se va da click pe acest buton, fereastra se inchide si vom ajunge tot in pagina contului de email, de aceea dupa rularea acestor comenzi, vom avea ca rezultat un nou obiect al clasei AccountMainPage, numit accountMainPage1.
AccountMainPage accountMainPage1 = newEmailForm.ToFieldFill(Helper.USER)
.SubjectFieldFill("Subject")
.ContentFieldFill("Email sent with Selenium")
.SendEmail()
.ClickInboxTab();
Dupa ce revenim in foderul Inbox al clientului de email, cu urmatoarea secventa de cod vom astepta in cont pana cand emailul va ajunge, verificand ca emailul cu subiectul introdus anterior este in inbox. Cand acesta este gasit, va trece mai departe
int wait = 1;
boolean title = true;
while (!"Subject".equals(accountMainPage1.EmailTitle())) {
wait = wait + 1;
title = false;
}
if (title = true ) {
Assert.assertEquals("Subject", accountMainPage1.EmailTitle());
}
In ultimele doua randuri vom face iesirea din contul utilizatorului
accountMainPage1.SignOutMenu()
.SignOut();
}
S2: Stergerea unuia sau mai multor email-uri
Mergem in pagina de login: www.gmail.com
Introducem user valid
Introducem parola valida
Click Sign In
Intram in Inbox
Verificam prin toate emailurile din prima pagina cu emailuri listate, mailurile cu titlul introdus anterior
Le bifam spre stergere
Click pe butonul sterge
Parasire cont
@Test
public void Scenario2() {
Instantiem cele doua clase LoginPage si CommonMethods pentru a efectua login-ul si pentru a folosi metodele ce ne permite asteptarea rularii dupa anumite elemente.
LoginPage loginpage = new LoginPage(driver);
CommonMethods commonMethods = new CommonMethods(driver);
Se face login-ul si se va returna clasa paginii contului de email.
AccountMainPage accountMainPage = loginpage.UsernameInputFill(Helper.USER)
.PassInputFill(Helper.PASSWORD)
.LoginClickOk();
Asteptam 5 secunde pana butonul Compose va fi prezent in interfata.
commonMethods.WaitUntilPresent(accountMainPage.composeButton, 5);
In urmatoarea secventa de cod, parcurgem toate emailurile din prima pagina de emailuri. Obtinem numarul emailurilor din pagina, ele vor fi toate elementele emailItem definite dupa locatie in clasa.
Numarul lor va fi emailNumber – 5, deorece mai sunt 5 elemente pe langa emailuri care au ceeasi descriere(locatie) dar nu reprezinta emailuri ci alte elemnte din pagina, cum ar fi cele 3 taburi ale folderului Inbox: Primary, Social, Promotions.
int emailsNumber = driver.findElements(accountMainPage.emailItem).size();
Parcurgem toata lista si luam titlul fiecari email.
for (int i=1; i < emailsNumber-5; i++ ) {
if (driver.findElement(By.xpath(".//table[@id=':3a']/tbody/tr["+i+"]/td[6]/div/div/div/span")).getText().equals("Subject")) {
Daca se gasesc emailuri cu subiectul dorit, atunci acestea se bifeaza spre stergere
driver.findElement(By.xpath(".//table[@id=':3a']/tbody/tr["+i+"]/td[2]/div/div")).click();
} else {
Daca nu, afisam mesaj ca nu s-a gasit nimic
System.out.println("The email with suject 'Subject' doesn't exist!");
}
}
Dupa ce am bifat emailurile vom da click pe stergere.
accountMainPage.DeleteEmail()
Ultimele doua linii vor face iesirea din cont.
.SignOutMenu()
.SignOut();
}
Concluzii:
Testarea reprezinta in momentul de fata una din ramurile software in plina dezvoltare, din ce in ce mai multe firme producatoare de software au inceput sa puna accent pe calitatea produsului si astfel au apelat ori la firme specilizate in testare, ori si-au facut propriile departamante de testare, devenind parte din planul de dezvoltare a aplicatiilor software.
Viitorul testarii software consta in testarea automata, drept dovada stau numeroasele tool-uri care apar pe piata si care vin sa intampine nevoile companiilor producatoare de software ajutandu-i pe aceastia sa scoata pe piata produse din ce in ce mai bune.
De asemenea cu ajutorul testarii automate costurile de productie ale produselor software, pe termen lung, pot sa scada semnificativ. Intr-adevar pe termen scurt testarea manuala aduce mai multe beneficii, mai ales daca e un produs deja existent. Automatizarea testarii implica un cost initial mai mare pentru o aplicatie existenta deja, deorece trebuie acoperit prin teste tot ce s-a dezvoltat anterior apelarii la testele automate, asta inseamna resurse noi, ca in paralel cu resursele existente sa se poata dezvolta si testa facilitatile noi ale aplicatiei.
Costurile suplimentare sunt in principal legate de oamenii noi angajati pentru a automatiza testarea, existand o gama larga de tooluri de automatizare open source, cum de altfel este si WebDriver-ul prezentat in capitolele anterioare.
WebDriver-ul este un tool puternic, usor de inteles, stabil, rapid, gratis, inca, si cu multiple module care iti pot face viata de tester mai usoara. Are deasemnea avantajul ca poate fi folosit in aproape orice limbaj de programare existent. Devenit in ultmii anii un tool foarte popular in industrie, se bucura de un suport si de o comunitate de utilizatori foarte mare ceea ce usureaza si mai mult efortul de invatare al acestuia.
Cu el poti testa site-uri sau aplicatii web, pe browsere multiple, poti testa in paralel pe mai multe masini, exista de asemnea si module pentru mobil, unde se pot face teste pentru browserele native de pe Android sau iOS.
Automatizarea testarii nu vine sa inlocuiasca omul, ci vine sa inlocuiasca munca repetitiva a omului care se ocupa de testare, astfel dispare monotonia de la locul de munca, timpul castigat putand fi folosit in dezvoltarea de teste noi, mult mai complexe si mai challenging sau pentru a invata tehnologii noi in testare ce pot fi folosite ulterior.
BIBLIOGRAFIE
http://www.freetutes.com/systemanalysis/sa9-testing-quality-assurance.html
Agile Testing: A Practical Guide for Testers, Autori: Lisa Crispin, Janet Gregory
Software Testing (2nd Edition) (Paperback) by Ron Patton editura SAMS
http://en.wikipedia.org/wiki/Software_testing
http://www.softwareqatest.com/
ISTQB Foundation Level Syllabus – http://www.istqb.org/downloads/finish/16/15.html
BIBLIOGRAFIE
http://www.freetutes.com/systemanalysis/sa9-testing-quality-assurance.html
Agile Testing: A Practical Guide for Testers, Autori: Lisa Crispin, Janet Gregory
Software Testing (2nd Edition) (Paperback) by Ron Patton editura SAMS
http://en.wikipedia.org/wiki/Software_testing
http://www.softwareqatest.com/
ISTQB Foundation Level Syllabus – http://www.istqb.org/downloads/finish/16/15.html
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Procesul de Testare. Tehnicile Si Metodele de Testare Specifice Aplicatiilor Software (ID: 150164)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.