Automatizarea Procesului de Testare

Cuprins

Capitolul 1. INTRODUCERE

Capitolul 2. STUDIU BIBLIOGRAFIC

2.1 Asigurarea calității software

2.2 Testarea software

2.3 Testarea software ca parte a procesului de îmbunătățire continuu

2.4 Testarea automată

2.5 Testarea manuală vs autoamată

2.6 Tehnologii de testare software automata

2.6.1 Selenium

2.6.2 Flexibilitate și extensibilitate

2.6.3 Selenium Grid

2.7 Spring MVC & Hibernate

2.8 Tooluri de automatizare existente pe piață

Capitolul 3. ANALIZĂ ȘI PROIECTARE

3.1 Proiectarea scripturilor de test

3.1.1 Specificații privind modul de utilizare

3.2 Schema bloc a sistemului

3.3 Funcțiile Sistemului

3.4 Arhitectură generală

3.4.1 Arhitectură modul de autmatizare

3.4.2 Arhitectură modul spring mvc

3.4.3 Arhitectură bază de date

Capitolul 4. IMPLEMENTARE

4.1 Interfată utilizator și modul spring mvc

4.1.1 Structură

4.1.2 Funcționalitate

4.1.3 Dezvolatre si implementare

4.2 Modul de automatizare

4.2.1 Structură

4.2.2 Funcționalitate

4.2.3 Dezvoltare si implementare

4.3 Baza de date

Capitolul 5. UTILIZAREA SISTEMULUI

5.1 Instalare și configurare

5.2 Modurile de utilizare

Capitolul 6. TESTARE ȘI VALIDARE

Capitolul 7. CONCLUZII

7.1 Realizări

7.2 Direcții de dezvoltare

INTRODUCERE

Importanța automatizării procesului de testare a crescut enorm datorită complexității funcțiilor sistemelor dezvoltate. O vedere de ansamblu asupra calității produselor și reducerea timpului de lansare pe piață a produsului sunt puncte de multe ori critice pentru companiile dezvoltatoare de produse software. Produsele care sunt prezentate târziu potențialilor clienți pot duce la pierderi de venituri, clienți și cotă de piață.

Testarea automată se definește ca fiind procesul prin care cu ajutorul unui instrument software se execută automat cazul de test sau suita de cazuri de test, iar pe baza datelor de intrare în sistemul aflat sub test(AUT), se compară rezultatele așteptate cu cele actuale și se generează rapoarte de test.

Principalele beneficii cheie aduse de acest proces sunt :

acoperire mare a testelor pentru detectarea erorilor și reducerea costurilor datorate defectelor;

repetabilitatea execuției testelor pentru a economisi timp și pentru a reduce costul de lasare pe piață al produsului;

o pârghie pentru a îmbunătăți productivitatea resurselor.

Problema alegerii unei aplicații de testare automată care să se adapteze cerințelor impuse de fiecare proiect, poate fi de cele mai multe ori, încă de la începutul implementării procesului de automatizare, o sarcină extrem de grea.

Majoritatea companiilor se orientează spre tehnologii open-source ce pot fi mai apoi transformate într-un framework personalizat în conformitate cu proiectul dezvoltat.

În sensul acesta, Selenium este unul dintre instrumentele open-source din domeniu, de testare funcțională a aplicațiilor web; execută automat testele funcționale end-to-end și, extrem de flexibil, Selenium permite scrierea scripturilor de test în diferite limbaje de programare precum: java, c#, pyton, ruby, JavaScript.

Prezenta lucrare își propune analizarea resurselor curente disponibile în domeniul testării automate a siturilor și aplicațiilor web în contextul dezvoltării și integrării continue a cazurilor de test, precum și studiul principalelor metode de identificare a elementelor din componența paginilor web necesare regăsirii rapide și testării eficiente.

Identificarea elementelor repetitive în acțiunea procesului de testare și abstractizarea lor prin adăugarea de componente noi în cadrul framework-ului.

Analizarea funcționalităților din zona de testare distribuită și implementarea unor asfel de facilități în cadrul framework-ului dezvoltat. Analiza resultatelor grafice pe baza executării testelor automate. În cadrul dezvoltării acestui framework, se încearcă implementarea logicii unui model de test de regresie.Aplicația urmărește implementarea unei interfețe cu utilizatorul prin intermediul căruia să se importe și să ruleze scripturile de test. În urma acestuia, se va configura modul de execuție și tipul browser-ului utilizat. Datorită faptului că sunt testate aplicații web, testarea de compatibilitate este necesară motiv pentru care se va urmări integrarea aplicației în principele navigatoare utilizate pentru afișare de conținut web.

Figura 1 Model de test de regresie

Obiectivele includ proiectarea și dezvoltarea unei metode abstracte de creare a scripturilor de test, în vederea utilizării de către personal fără competențe specifice de codare. Se vor lua în considerare principale tehnologii open source care să implementeze cât mai multe funcționalități pentru dezvoltarea modulelor aplicației.

Această lucrare este structurată în șapte capitole după cum urmează:

Capitolul 1 Introduce: În acest capitol se face o scurtă prezentare despre obiectivele proiectului si despre structura acestei lucrări.

Capitolul 2 Studiu Bibliografic: În acest capitol se prezință o descriere domeniul asigurări calității software,testarea automată vs manuală si principalele tool-uri de testare automată.

Capitolul 3 Analiză și Proiectare: Acest capitol cuprinde modul de proiectare al scriptului de test,al funcțiilor sistemului și scheme care cuprind arhitectura sistemului implementat.

Capitolul 4 Implementare: Acest capitol cuprinde modul de implementare al principalelor functionalități și a metodelor folosite pentru aceata.

Capitolul 5 Utilizarea Sistemului: In acest capitol se prezintă modul de configurare a proectului utilizănd mediul de devoltare IntelliJ Idea și al modurilor de utilizare.

Capitolul 6 Testate și Validare: În acest capitol se prezintă modurile de testare al sistemului.

Capitolul 7 Concluzii: În acest capitol se prezintă concluziile referitoare la această lucrare.

STUDIU BIBLIOGRAFIC

Asigurarea calității software

Asigurarea calității software este definită ca fiind procesul și metodele utilizate pentru a monitoriza activitatea de implementare și că cerințele impuse sunt îndeplinite. Aceasta se concentrează pe client și pe eliminarea defectelor înainte ca acestea să fie livrate in producție.

Printre principalele caracteristici și performanțe pe care un produs software trebuie să le asigure se regăsesc:

Fiabilitatea,

Flexibilitatea,

Timpul de raspuns.

Asigurearea calității software se poate diviza în două mari direcții și anume analiza statică și analiza dinamică.

Caracteristicile analizei statice sunt:

Analiza documentelor și a specificațiilor, analiza principalelor modele software, cât și a codului;

Analize ce prevăd corectitudinea codului și algoritmilor folosiți;

Evaluarea codului ce se dezvoltă pentru a obține o eficiență din punct de vedere calitativ cât mai ridicată în urma complilări.

Caracteristicile analizei dinamice sunt:

se bazează pe execuția programului în scopul descoperirii defectelor funcționalității acestuia;

se observă atât caracteristici de comportament, cât și de performanță ale produsului;

datele de test sunt atât date tipice, cât și date special create să acopere anumite funcționalități

de importanță mare este de asemenea și determinarea setului finit de teste pentru o evaluare a corectitudinii și performanțelor cât mai corectă

Prin utilizarea ambelor concepte se dorește identificarea unui număr maxim de defecte posibile astfel încât acestea să fie rezolvate cât mai repede încă din procesul de dezvoltare a produsului.

Testarea software

Testarea software este o strategie uzitată pentru gestionarea riscurilor și este folosită, printre altele, pentru a verifica că cerințele funcționale au fost îndeplinite. Principalul scop al execuției testelor este asigurarea că toate cerințele sunt testate în toate combinațiile posibile de valori de intrare și de stări ale sistemului. Cu toate acestea, nu toate defectele sunt descoperite în timpul testării, unele cazuri de funcționare eronată depinzând de configurații unice ale sistemelor hardware unde rulează. Testarea software include, pe lânga cele amintite anterior, activitățile de verificare și de validare. Scopul major al acestor activități este de a asigura că design-ul software, codul și documentația îndeplinește toate cerințele impuse acestora.

Cîteva exemple de cerințe sunt redate mai jos:

cerințele utilizatorilor,

specificații derivate din cerințele utilizatorilor ,

testarea de acceptanță a codului,

cerințe de testare module, subsisteme și nivele de integrare software.

În timpul procesului de proiectare și implementare software, verificarea ajută la determinarea faptului că produsele îndeplinesc cerințele stabilite în timpul fazei anterioare. Efortul de verificare durează mai puțin timp și este mai puțin complex, atunci când este efectuat pe tot parcursul procesului de dezvoltare.

Testarea software ca parte a procesului de îmbunătățire continuu

Ciclul de viața al testării software-rului trebuie să aibă loc împreună cu ciclul de viață al dezvoltării produsului software. Procesul de testare trebuie sa înceapă încă de la începutul implementării produsului dezvoltat nu doar în mod tradițional după ce implementarea codului a avut loc, așa cum este prezentat în figura 1. Testarea ar trebui inclusă în procesul de dezvoltare software, iar pentru ca acest lucru să fie realizabil este nevoie de comunicare bună si flexibilitate din partea echipelor responsabile pentru dezvoltarea codului și a celor responsabile de asigurarea calității.

Figura 1.0 Faza de dezvoltare vs tipurile de testare implicate

Testarea automată

În cazul testării manuale, personalul implicat în testare va executa în mod manual cazurile de test pentru a valida funcționalitatea aplicației. În contrast cu testarea funcțională manuală, testarea funcțională automată este procesul prin care cu ajutorul unui tool de testare automată se rulează cazul de test sau suita de cazuri de test, iar pe baza datelor de intrare in sistemul aflat sub test(AUT), compararea rezultatelor așteptate cu cele actuale și generarea de rapoarte de test.

Există o serie de avantaje pe care testarea automată le aduce procesului de testare și asigurare al calității, câteva dintre acestea evidențiindu-se încă de la început. Următoarele puncte pot fi considerate motive clare pentru care procesul de automatizare ar trebui implementat:

testarea manuală a întregului flux funcțional și a totalității scenariilor positive sau negative este mare consumatoare de timp;

automatizarea nu necesită intervenție umană, testele pot rula automat nesupravegheat (în timpul nopții);

viteza de execuție a cazurilor de test crește considerabil;

crește acoperirea cazurilor de test și reducerea costurilor datorate defectelor;

testarea manuală poate deveni plictisitoare și prin urmare e predispusă la erori.

Nu toate cazurile de test pot fi automatizate și acesta reprezintă motivul pentru care este de cele mai multe ori dificilă alegerea testelor care se automatizează si care se vor executa manual. Câteva puncte de referință în alegerea cazurilor de test care trebuie luate în calcul în procesul de automatizare sunt următoare:

alegerea testelor în conformitate cu criteriul de crestere ROI(Return-on-Investment)

cazuri de test care sunt critice din punct de vedere al business-ului;

cazuri de test ce sunt executate în mod repetat, pachete cu teste de regresie;

cazuri de test ce sunt dificil de executat manual;

cazuri de test care sunt mari consumatoare de timp.

cazurile de test care nu sunt potrivite pentru automatizare:

cazuri de test care au fost noi create și nu au fost execute cel puțin odata manual;

cazuri de testare pentru care cerințele se schimbă frecvent;

cazuri de test ce sunt executate ad-hoc.

Testarea manuală vs automată

O prima etapă în procesul de automatizare este reprezentată de alegera tipului de testare abordat și care sunt cazurile de test care ar trebui incluse. Între cele două tipuri de testare se pot pune în evidență încă de la început cateva diferente majore , avand fiecare avantaje si dezavantaje.

Tehnologii de testare software automata

Problema alegru care este de cele mai multe ori dificilă alegerea testelor care se automatizează si care se vor executa manual. Câteva puncte de referință în alegerea cazurilor de test care trebuie luate în calcul în procesul de automatizare sunt următoare:

alegerea testelor în conformitate cu criteriul de crestere ROI(Return-on-Investment)

cazuri de test care sunt critice din punct de vedere al business-ului;

cazuri de test ce sunt executate în mod repetat, pachete cu teste de regresie;

cazuri de test ce sunt dificil de executat manual;

cazuri de test care sunt mari consumatoare de timp.

cazurile de test care nu sunt potrivite pentru automatizare:

cazuri de test care au fost noi create și nu au fost execute cel puțin odata manual;

cazuri de testare pentru care cerințele se schimbă frecvent;

cazuri de test ce sunt executate ad-hoc.

Testarea manuală vs automată

O prima etapă în procesul de automatizare este reprezentată de alegera tipului de testare abordat și care sunt cazurile de test care ar trebui incluse. Între cele două tipuri de testare se pot pune în evidență încă de la început cateva diferente majore , avand fiecare avantaje si dezavantaje.

Tehnologii de testare software automata

Problema alegerii unui tool de testare automată care să se adapteze cerințelor impuse de fiecare proiect, poate fi de cele mai multe ori încă de la inceputul implementării procesului de automatizare o sarcină extrem de grea. Majoritatea companiilor se orienteaza spre tehnologii open-source care să poată fi mai apoi transformate intr-un framework personalizat în conformitate cu proiectul care urmează să fie automatizat. Din acest punct de vedere am ales să prezint câteva tehnologii extrem de populare care se pretează pe piața software în momentul actual.

Selenium

Selenium este un framework popular, open-source, de testare functională al aplicatiilor web.Este un tool foarte puternic de rulare al testelor functionale end-to-end. Selenium este extrem de flexibil si permite scrierea scripturilor de test in diferite limbaje de programare precum: java, c#,pyton,ruby,JavaScript.

Figura 2.0 Principale tehnologii suportate de Selenium WebDriver 2

Selenium WebDriver 2 API este ultima versiune care vine in urma îmbinării variantelor anterioare de Selenium 1și Selenium Webdriver , cu scopul de a forma un produs mult mai performant care să rezolve problemele din varianta anterioară. Selenium WebDriver API(Interfată de programare a aplicatiilor) este total orientat pe obiect si folosește comunicarea cu browserul intr-un mod căt mai eficient și rapid folosind protocolul de comunicare numit “JSON Wire Protocol”. Din punct de verede al sistemelor de operare este un tool cross-platform.

Selenium WebDriver 2 oferă driver-e pentru:

Mozilla Firefox

Google Chrome

Microsoft Internet Explorer

Opera

Apple iPhone

Android

Figura 2.1 Diferența de comunicare Selenium WebDriver 2 vs Selenium 1.0 cu browser-ul

Flexibilitate și extensibilitate

Selenium oferă in permanență, fiind un tool open source , posibilitatea de a extindere a actualelor librări si de customizare al propriului framework după cerințele impuse de proiectul pe care se rulează testele automate.Flexibilitate mare se poate observa si la scrierea scripturilor de test, posibilitate de a alege diverse metode si limbaje de codare , facănd astfel posibilă adaptabilitatea la diverse priecte care depind mai mult sau mai puțin de un anumit limbaj de programare.

Fluxul de lucru utilizănd Selenium WebDriver 2 se compune din urmatorii pași:

Scrierea scripturilor de test intr-un limbaj de programare specific,

Comunicarea cu Selenium WebDriver se realizează prin instanțele de bowser care sunt apelate in scripturi de test

Selenium WebDriver comunică în mod direct cu browserul

Figura 2.2 Fluxul de Lucru Selenium WebDriver 2 API

Selenium Grid

Selenium Grid este un server care permite executarea de teste pe instanțe de browser care rulează pe mașinile de la distanță.Selenium Grid are doua componente majore hub-ul care este punctul central si nodurile pe care ruleaza diferinte instanțe de browser. Testele contactaeaza hub-ul pentru a obține acces la instanțele de browser. Hub-ul are o listă de servere care oferă acces la instanțe de browser (noduri WebDriver), și oferera testelor permisiunea de utilizare a acestor resurse. Seleniu Grid permite rularea de teste în paralel pe mai multe mașini, și de a gestiona dintrun punct central diferite versiuni si configurații de browser.

Figura 2.3 Arhitectura modului de comunicare si utilizare a serverului Selenium Grid

Spring MVC & Hibernate

Framework-ul String MVC are la bază o ahitectură Model-View-Controler si componente gata implementate , care se pot folosi pentru a dezvolta aplicații web căt mai flexibile si slab cuplate.Modelul MVC separară diferitele aspecte ale unei aplicații (logica de intrare, logica de business, și logica UI), oferind în același timp un cuplaj minim între aceste elemente.

1.Modelul încapsulează datele aplicației și in general constă din POJO.

2.View-ul este responsabil pentru randarea datelor modelului și, în general, generează codul HTML pe care browser-ul clientului îl poate interpreta.

3.Controller-ul este responsabil pentru procesarea cererilor de la utilizator și construirea modelelului adecvat pentru al trimite sa fie procesat de modulul View.

DispatcherServlet-ul

Framework-ul Spring MVC este conceput în jurul unui DispatcherServlet, care are rolul de a gestiona cererile si răspunsurile HTTP.Modul in care cererile sunt procesate de acesta sunt prezentate in urmatoarea diagramă:

Figura 2.3 Fluxul de procesare al cererilor HTTP la nivel DispatcherServlet

Secvența de procesare al evenimentelor unuei cereri http la nivel DispatcherServlet este urmatoarea:

După ce a primit o cerere HTTP, DispatcherServlet-ul consultă HandlerMapping pentru a apela Controller-ul adecvat.

Controller-ul preia cererea și cheamă metode de servicii cele mai adecvate bazate pe metode GET sau POST. Metoda de servicii va seta modelul de date, bazat pe logica de business definită și va întoarce numele View-lui corespunator spre DispatcherServlet.

Cu ajutorul oferit de ViewResolver , DispatcherServlet-ul va alege View-ul definit pentru cererea facută

Odata ce view-ul este finalizat , DispatcherServlet-ul va pasa modelul de date catre View care mai apoi va fi procesat si afișat de browser

Figura 2.4 Fluxul de procesare al cererilor HTTP

Toate componentele de mai sus: HandlerMapping, Controller și ViewResolver sunt părți ale WebApplicationContext, care este o extensie a componentei simple ApplicationContext , cu unele caracteristici suplimentare necesare pentru aplicatii web.

Hibernate este un serviciu performant de persistență si interogare baze de date pentru orice aplicatie Java.Cu ajutorul hibernate clasele java mapează tabele din baza de date si tipurile de date din java sunt mapate peste tipurile de date SQL, minimizănd efortul programatorului cu 95% datorat realizarii de task-urii pentru persistenta comună de date. Hibernate se află intre obiectele traditionale Java si baza de date pentru rezolvarea problemei de persistentă al obiectelor prin metode și mecanisme O/R adecvate.

Arhitectura Hibernate este una stratificată pentru a vă menține izolat,făra a fi nevoie de cunoașterea API-urile care stau la baza. Hibernate face uz de bazele de date și de configurarea datelor pentru a furniza servicii de persistența (și obiecte persistente), la nivelul aplicațiilor.

Figura 2.5 Arhitectura Aplicației Hibernate vedere de ansamblu

Figura 2.6 Arhitectura Aplicației Hibernate vedere detaliat

Tooluri de automatizare existente pe piață

În momentul de față există numeroase tool-uri de automatizare pe piața swoftware,fiecare cu o serie de avantaje si dezavantaje.Toolurile care se pretează cel mai mult sunt cele open source și care oferă deasemenea flexibilitate de extindere si customizare raportată la cerințele proiectelor.Interfața grafica a aplicației este deasemenea importantă,majoritea aplicațiilor fiind aplicații standard instalate pe computer.In continuare voi prezenta cateva caracteristici a unor tool-uri existente in contrast cu funtionalitati aduse Selenium baza framework-ul KeyQuality , care este de altfel tema acestui proiect de licentă.

HP QuickTest Professional (QTP)

Este unul dintre cele mai populare tooluri din domeniu testării automate, este folosit in mod general la testarea GUI aplicațiilor desktop/web.

Tabel 2.0

Datorita faptului ca KeyQuality este un framework care are ca baza platforma de pachete selenium webdriver/Grid voi prezenta cateva concepte si funtionalități noi generate de acest tool:

Panou de control cu interfată grafica web,posibilate de acces din orice locație.

Testare distribuita pentru executie mai rapida prin integrarea pachetelor selenium grid.

Scriea testelor automate rapid prin completarea unor cuvinte cheie intr-un fișier sablon cu extensia .json , conceptul ce are la baza testarea key-driven.

Stabiliate mare a testelor si mentenanță rapidă.

Vizualizarea rapoartelor din panoul de control.

Utilizarea frameworkului nu necesită cunoașterea unui limbaj de programare.

ANALIZĂ ȘI PROIECTARE

Proiectarea scripturilor de test

Obiectivul dezvoltarii aplicației in cauză este înlocuirea pașilor repetitivi din implemetarea manuală a cazurilor de test in tehnica testarii in cutie neagra. Funcționalitățile suplimentare vor permite utilizarea de resursă umană cu experienta redusa in dezvoltare de cod sursa, ci mai degraba, in validarea functionalităților aplicațiilor specifice(de exemplu, aplicatii bancare, de navigare, de taxi).

Caracteristicile care stau la baza proiectării cazurilor de test care să inlocuiască scrierea scripturilor de test in vederea rulări automate ale acestora, se conturează in jurul conceptului de keyword-driven testing concept care va fi definit in urmatoarele rănduri:

Keyword-driven testing este o metodologie de testare software potrivită atât pentru testarea manuală căt și pentru testare automată. Această metodă separă documentația cazurilor de test ce includ si datele de test, de modul în care sunt executate cazurilor de testare. Ca urmare se separă procesul de creare de cazuri de test în două stagii distincte: un stadiu de design si dezvoltare, și un stadiu de executie.Stagiul de design si dezvoltare in cazul de fată, vine in ajutorul testărilor care nu au o pregatire tehnică de a scrie in mod direct utilizand un anumit limbaj de programere(java,c#,etc..) scripturile de test , ci transpunearea lor intr-un limbaj cat mai natural pe baza unui șablon “json” , care va fi mai apoi va fi manipulat in stagiul de execuție, prin multiple functionalități oferite de framework-ul KeyQaulity dezvoltat in cadrul acestui proect de diplomă.

In urma unui studiu de ansamblu a design-ului cazuilor de test care fac parte din testarea manuală, putem indentifica urmatoarele sectiuni componente ale acestora:

Identificarea cazului de test: este partea in care se specifică un id sau nume al cazului de test pentru ca acestă sa poată fi indentificat în mod unic.De asemenea se poate pune în evidentă persoana care va rula cazul de test, ce componente din sistem vor fi testate, etc…

Acțiunile de testare: în acestă zonă se includ principali pași cu specificare exactă a acțiunilor care trebuiesc făcute in vederea testării propriuzise dar si ce date de intrare sunt necesare pentru validarea funcționalitații sistemului,care in mod normal este vazut de tester ca un sistem black-box.

Rezultatele așteptate: în acestâ parte se specifică datele cate trebuie validate in urma executării pașilor din zona anterioară

Rezultatele actuale: este zona care validează execuția cazului de test și in mod normal se completeză cu atributele Pass/Faild

Exemplu de șablon generic al cazurilor de test:

In vederea proiectări cazurilor de test care să abstactizeze, intr-un limbaj cat mai natural, scripturile de test automate scrise de obicei intr-un limbaj de programare, s-au luat in considerare urmatorele:

Secțiunea de identificare a cazului de test

Secțiunea de pași care trebuie executați

Secțiunea de rezultate așteptate in urma execuției

Cele din urmă două secțiuni se scriu in general in mod unic si anume: fiecărui pas de execuție cu date de intrare specifice îi corespunde un rezultat așteptat care validează execuția pasului executat, toți acești pași urmand sa valideze o anumita funcționalitate din componența sistemului aflat sub test.

Datorita faptului că framework-ul KeyQuality va realiza testare funtională web, aspecte necesare si foate impotante precum modul de indetificare al elementelor din conținutul paginilor web trebuie deasemenea analizate in vederea proiectari scripturilor de test.

In mod uzual principale elemente care compun o interfată grafică a unei pagini web și in jurul carora se implementează principalele funtionalitați ale sistemului ce urmează să fie testat sunt urmatoarele:

Butoane

Cămpuri de text (Text Area Field)

Liste de opțiuni(Drop-down list)

Butoane radio și CheckBox-uri

Iframe-uri

Toate aceste elemente sunt identificate in funcție de atributele asignate în cadrul implementări astfel se evidențiază cateva metode usoare și sigure de indetificare și manipulate:

Identifacare dupa atributele “id” , “class” atribute care se modifica mai rar in sursa paginilor web si prin urmare reprezinta un avantaj considerabil al timpului de mentenanța

Indentificarea cu ajutorul selectorului XPATH , in situații in care artibutele „id” sau „class” se repetă in cadrul mai multor elemente si avem astfel nevoie de o indentificare unica a elementului

Astfel modalitățile de identificare incluse in șablonul care constituie scriptul de test sunt indentificarea dupa atributele ID, CLASS si cu ajutorul selectorului XPATH.In vederea construirii xpath-urilor si extrageri atributelor id si class din sursa paginilor web se vor utiliza browsere precum Mozilla FireFox care oferă suport pentru diferite tool-uri in direcția aceasta, unul dintre ele fiind FirePath.

In urma identificării principalelor elemente din aplicațiile web se pot contura următoarele acțiuni de manipulare ale acestora:

pentru accesarea funcționalități butoanelor actiunea de bază este clic

pentru Drop-Down list acțiunea este selectarea opțiunii specifice

pentru cămpuri de text acțiunea este scrierea datelor de intrare

Pentru evaluarea rezultatele așteptate in urma execuției pașilor de test se evidențiază urmatoarele actiuni:

verificarea unui anumit element este prezent pe pagina web

verificarea unui mesaj,text specific

preluarea unui mesaj text din pagina si verificarea lui contra date specifice

In urma analizei și proiectării cazurilor de test precum și al pricipalelor metode de indentificare al elementelor din componența paginilor web a rezultat următorul șablon pentru scripturile de test:

Specificații privind modul de utilizare

In cazul de fața scrierea de scripturii in mod direct prin implementare cu ajutorul limbajelor de programare nu mai este necesară , ci doar completarea specifică a elementelor din șablonul prezentat mai sus.

Astfel primele elemente din noul script se vor completa in ordinea in care sunt scriese , de sus in jos valorile atribuite cheilor avand următoarele semnificații:

„name” va semnifica numele cazului Șde test

„environment” se completează cu url-ul aplicației web care se află sub test , valoarea este una unica,ea se modifică in funție de aplicația pe care vor rula testele

„actionSteps” aceasta reprezintă un array de pași ce vor fi executați in cadrul testului

„id” reprezintă id-ul pasului de test

„action” cuvintele cheie obligatorii sunt: click , fillIn , select

„elementPath” se completează cu id ,clasa sau xpath-ul de identificare al elementelor implicate

„elementPathType” urmtoarele valori obligatorii sunt: 1= identificare element după id, 2=identificare element după calsă ,3=identificare element dupa selectorul xpath

„dataInput” se completează datele de test

„iframe” in cazul in care elementul face pace din cadrul unui iframe este necesară schimbarea in cadru respectiv pentru ca acțiunea sa fie interceptată de element se va completa cu identificatorul iframe-ului

„expectationAction” cuvintele cheie obligatorii sunt: getAssert, isPresent, verify

„expectationPath” se completează cu id-ul ,clasa sau xpath-ul de identificare al elementelor implicate in pași de testare

„expectationPathType” următoarele valori obligatorii sunt: 1= identificare element după id, 2=identificare element după calsă ,3=identificare element dupa selectorul xpath

„expectationData” se completează cu datele de validare al rezultatelor așteptate

„iframeExpectation” se completează daca este necesar, ca și in cazul atributului iframe

Se descrie astfel modul de utilizare standard pe baza șablonului prezentat al scriptului de test.Cuvintele cheie ce stau la baza actiunilor din cadrul testelor sunt: click , fillIn ,select ,getAssert, isPresent, verify in jurul cărora se formează principala funcționalitate din cadrul KeyQuality.Fiecărui pas de execuție îi corespunde in mod unic un pas de validare al rezultatului așteptat.In cazul in care nu este necesar ca date de intrare sa fie procesate campurile din șablon se vor completa cu cuvantul cheie null. Fiecare caz de test se va tanspune șablonului descris,urmand sa se treaca apoi la urmărul pas de rulare automată a acestuia.

Schema bloc a sistemului

Schema bloc include următoarele module:

Modul de interfață grafică

Modulul SpringMVC ce permite care comunica cu celelate module ale aplicației

Modulul Automation Core ce conține implementatea pentru interpretarea si execuția scripturilor de test

Componente externe sunt in acest caz: selenium grid și masini virtuale sau fizice

Baza de date prentru gestionarea utilizatorilor

Sa abordat o arhitectură pe trei nivele: interfață grafică , module back-end și bază de date.

Funcțiile Sistemului

Obiectivul acestui subcapitol se conturează in jurul diagramelor cazurilor de utilizare din care se pot vedea in mod grafic principale funtionalități și moduri de interacțiunie al utilizatorulor cu aplicația dezvoltată.

Cazul de utilizare numărul 1

Descriere pașilor implicați în cazul de utilizare numarul 1:

În pasul 1 utilizatorul cu drep de administrator se logheză in aplicație

Utilizatorul accesează pagina care îi permite să adauge utilizatori noi in baza de date

În pasul 3 utilizatorul logat are posibilitate de vizualizare al userilor curenți din baza de date si deasemenea poate sa execute acțiuni precum editarea sau stergerea utilizatorilor

Utilizatorul se va deloga din aplicație

Cazul de utilizare numărul 2:

Descriere pașilor implicați in cazul de utilizare numarul 2:

Testerul se logează in aplicație cu rolul de user, acțiunea implică o verificarea la nivel de securitate al rolului care il deține contul utilizatorului.

Utilizatorul navigheză spre pagina de control,de unde se personalizează modul de rulare al cazurilor de test

Utilizatorul navighează pe pagina de vizualizare rapoarte generate generate in urma execuției testelor

Utilizatorul se delogeaza din aplicație

Cazul de utilizare numarul 3:

Descrierea pașilor implicați in cazul de utilizare numarul 3:

În primul rănd in acest caz de utilizare pasul 1 este compus din 2 actiuni: startarea serverul de selenium grid și înregistrearea de noduri ce reprezintă mașinile fizice sau virtuale unde vor fi executate remote testele

Testerul se logează in aplicație cu rolul de user, acțiunea implică o verificarea la nivel de securitate al rolului pe care il deține contul utilizatorului in baza de date

Utilizatorul navigheză spre pagina de control,de unde se personalizează modul de rulare al cazurilor de test , in acest caz execuția va fi remote pe browsere care sunt instalate pe mașini la distantă , motiv pentru care exista si dependența directa i

Pasul 4 si 5 se repeta ca si in cazul de utilizare numarul 2

Cazurile de utlizare 2 si 3 nu implică scrirea scripturilor de test,ele au fost create inaintea utilizării framework-ului in modurile descries mai sus.

In ultima parte a acestui capitol se va prezenta ultimul caz de utilizare, scopul principal al acestuia este de a evidenția modul in care utilizator va interactiona cu aplicatie sub test pentru completarea scripturilor de test care au fost proiectate sa ușureze cat mai mult munca personalului care nu deține cunostințe tehnice de codare al cazurilor de test.

Cazul de utilizare numarul 4

Descrierea pașilor implicați in cazul de utilizare numarul 4:

Utilizatorul utilizează browserul Mozilla FireFox pentru accesul la aplicația web aflată sub test in scopul extrageri identificatorilor elementelor implicate in testarea funcționalității.Motivul principal pentru care se lucreză cu FireFox este suportul de tool-uri pe care acesta le oferă in direcția manipulării codului sursă al paginilor web.

Găsirea si extragerea propriuzisă a identificatorilor unici ai elemenetelor necesită pornirea tool-ului FireBug(FirePath),oferit de cate browser.Se vor analiza in mod principal atributele id,class si xpath-ul elementelor.

După identificarea elementelor se completează șablonul impus cu specificațiile descrise in subcapitolul 3.1.1.

Arhitectură generală

Arhitectură modul de autmatizare

Diagrama claselor responsabile pentru funtionalitatea de testare și procesare al scriptului de test:

Figura 4.1 Diagrama claselor modul de automatizare

Datorită complexități schemei din diagrama claselor se descriu mai jos blocurile de clase cu atribute și metodele pe care le conțin:

Se prezintă secvența de comunicare între obiecte după startarea profilului de test maven:

Figura 4.2 Diagrama de secvente modul automatizare al testelor

Arhitectură modul spring mvc

Figura 4.3 Diagrama claselor modul spring mvc

În următoarea schemă este prezentat modul de comunicare secvențială al obiectelor din modulul spring mvc compuse din două scenarii ce redau principalele funtionalitați:

configurarea si startarea testelor

adăugarea unui nou utilizator

pentru pașii de editare si ștergere se utilizează aceiași logică ca în cazul anterior

Figura 4.4 Diagrama secvențială

Arhitectură bază de date

Baza de date nu este una complexă deoarece este folosită implicit pentru gestiunea utilizatorilor care utilizează apliacția și este compusă din tabele users și user_roles.Legatura dintre cele două tabele este de tipul 1: N.

Figură 4.5 Diagramă tabele bază de date

IMPLEMENTARE

Interfată utilizator și modul spring mvc

Structură

Pentru implementarea interfeței grafice cu utilizatorul și a modului spring mvc de gestiune al cererilor efectuate din interfața grafică s-a decis gruparea lor in doua pachete separate, in cadrul pachetului principal com.automation.web. In următoarele figuri se prezintă structura pachelor cu clasele și paginile web care le formează:

Figură 4.1 Structura pachetelor cu principale clase din modulul spring mvc

Figură 4.2 Structura pachetelor cu principale pagini jsp din interfața cu utilizatorul

Funcționalitate

În pachetul controller clasele AutomationController, MainControler si UserController implementează funtionalitatea prin care se gestionează cererilor utilizatorilui efectuate din interfata grafică.Acestea implementează logica standard din aflicație la nivel de gestiune al paginlor web accesate de utilizator dupa modelul caracteristic controlerului spring mvc.In continuare se prezintă funtionaliatea oferita de fiecare clasă din acest pachet:

MainController este responsabil pentru afișarea pagini de logare in aplicatie login.jsp si procesarea ceceri de logare al utilizatorilor.La nivelul acestui controler se verifică rolul utilizator si afișarea paginilor corespunzatoare pentru fiecare rol in parte.Dacă cererea de logare sa executat cu succes se afisează pagina home.jsp sau in caz contrat mesaje de eroare pagina login.jsp.

AutomationController implementează funionalitatea de afișare al paginilor AutomationTestRun.jsp, AutomationTestRunRemote.jsp, Configuration.jsp și ReportResultsView.jsp.Se procesează startarea testelor prin apelul făcut cu instanța clasei StartBatFiles al profilului maven responsabil de rularea unui anumit test in conformitate cu configurația procesată din interfată.

UserControler are funcținalitatea de afișare și procesare ale paginilor add-user-form.jsp, list-of-users.jsp si edit-from-user.jsp.Se gestionează adăgarea unui nou utilizator, editarea si stergerea acestuia din baza de date.

Clasele RolDaoImpl si UserDAOImpl oferă funcționalitatea de interfațare cu baza de date și de persistență a datelor.In pachetul model clasele Role si User ofera funtionalitatea de mapare al tabelor din baza de date ca si obiecte java ce vor fi folosite de mecanizmul DAO pentru persitentă.LocalBrowser este clasa responsabilă pentru maparea tipurilor de date care se selectează din interfața cu utilizatorul prin mecanizmul oferit de librăriile spring mvc.Clasa ReadAndWriteFile oferă funcționalitatea de scriere in fișier și citire din fisier.In pachetul service se gasesc clasele RoleServiceIml si UserServiceImpl care accesează cu ajutorul obiectelor DAO baza de date oferind funcționalitățiile CRUD la nivelul bazei de date.

Pentru gestiunea utilizatorilor paginile add-user-form.jsp, list-of-users.jsp și edit-user-form.jsp sunt responsabile pentru următoarele funcționalități:

Panou de adaugare al utilizatorilor in baza de date

Panou editare utilizatori

Panou stergere utilizator

Paginele AutomationTestRun.jsp, AutomationTestRunRemote.jsp si ConfiguationSuiteStatus.jsp oferă funtionalitate de configurare ale suitelor de test.

Dezvoltare si implementare

Pentru implementarea codului s-a utilizat mediul de dezvoltate InteliJ Idea integrat cu Maven pentru compilare si respectiv Tomcat server 7.0 pentru deploy-ul aplicatiei.

Principalele configurări pentru integrarea pachetelor spring mvc si hibernate in vederea realizari unui proeiect web dimic sau realizat la nivelul urmatoarelor fișiere:

mvc-dispatcher-servlet.xm

spring-database.xml

spring-security.xml

web.xml

Dependențele pachetelor java pentru dezvolatarea paginilor jsp si al modulului spring mvc se configurează in fisierul pom.xml fișier din cadrul maven.In acest fisier se configurează proprietațile proectului, pluginuri si pachete de fieșiere pentru complilarea aplicației

Explu de dependentă maven in fisierul pom.xml:

<dependencies>

<dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-webmvc</artifactId>

<version>${spring.version}</version>

</dependency>

</dependencies>

Metodele de gestiune al cererilor POST si GET descrise în clasele controler au urmatoarea implementare:

Metoda ce implementeaza o cerere de tipul GET

@RequestMapping(value = "/automation", method = RequestMethod.GET)

public ModelAndView getAutomation() {

ModelAndView model = new ModelAndView("manag-pages/AutomationTestRun");

…………

return model;

}

Metoda care implementeză o cerere de tipul POST

@RequestMapping(value = "/edit/{id}", method = RequestMethod.POST)

public ModelAndView edditingUser(@Valid @ModelAttribute User user, @PathVariable String id) {

ModelAndView modelAndView;

try {

……………….

modelAndView = new ModelAndView("list/list-of-users");

} catch (Exception e) {

}

return modelAndView;

}

Adnotările specifice spring mvc sunt:

@Controller adnotare care se scrie inaintea fiecarei clase care implemetează aceste metode si care definește ca clasa ca si container

@ RequestMapping

@Autowired

@ModelAttribute

@PathVariable

Model de cerere trimisă dintr-o pagina jsp spre controler este implementată sub forma:

<form:form method="POST" modelAttribute="remoteTest"

action="${pageContext.request.contextPath}/test/remoteTest-result.html">

……

</form>

Clasele din pachetul model sunt implementate folosind anotări hibernate, mecanizm prin care se mapează tipurile de date ale tabelelor bazei de date pe sablonul unei clase java.

Exemplu de implementare al tabelei users_rols folosind metode hibernate:

Figura 4.3 Implementarea clasei Role

Adnotările oferite de hibernate si folosite pentru implementate sunt urmatoarele:

@Entity

@Table(name=numele tabelei din Baza de date care se mapează)

@Column

@OneToOne

@JoinColumn

În cadrul implementari paginilor jsp s-a folosit limbaj html, taguri jsp, CSS si imagini care formeaza designul paginii.

Modul de automatizare

Structură

Structura pentru modul de automatizare s-a grupat in doua subpachete si anume pachetul java si resources in cadrul pachetului principal test.In urmatoarele figuri se prezinta structura pachetelor cu clase si fisire conținute:

Figura 4.4 Structura pachete și clase modul automatizare

Figură 4.4 Structură pachete si fișiere de configurare

Funcționalitate

In pachetul de test sunt incluse clasele care implementează funcționalitatea de bază al modulului de test iar in pachetul resources principalele fișire de configurare al suitelor de test necesare pentru distribuirea testelor local sau pe mașini remote in arhitectura distribuită oferită de selenium grid.Se vor prezenta clase și funtionalitatea pe care o oferă in cadrul framewok-ului KeyQuality.

ElementsPathConfiguration implementează funcționalitatea de identificare al elementelor din pagina web al aplicației care se află sub test, elemente care sunt procesate din scriptul de test conform cu logica specificată in script.

Clasele ActionMapped și EnvironmentMapped sunt folosite pentru maparea elementelor din scriptul de test care vor fi folosite in implementarea altor clase si metode din cadrul frameworkului.JsonParseTest este clasa care are rolul de citire al fișierului json care compune scriptului de test.

În clasa PrepareActionStringMapping se vor forma principalele obiecte care conțin datele mapate cu ajutorul clasei JacksonJsonProcessing.

La nivelul claselor CreateActionTestExpectation si CreateActionTestSteps se implentează functionalitatea de baza a acțiunilor și rezultatelor așteptate descrise in cadrul scriptului de test.

WebDriverSupplier este clasa principală din care se generează instanțe de obiectele care cheamă browserele unde vor rula scripturile de test in conformitate cu cofigurările realizate de utilizatori in vederea execuției automate.

Clasa UtillBrowsers implementeză metode utilizate in manipularea elementelor de test din paginile web ,funtionalitatea lor regasinduse in clasele CreateActionTestExpectation și CreateActionTestSteps.În cadrul acestei clase se folosesc apeluri ale driverelor cromedriver si IEDriverServer utilizate pentru instanțierea obiectelor WebDriver.

RunAutomationTest, RunAutomationTest sunt practic clasele de test fara care testele nu ar putea fi executate.In aceste clase se instațiată principale clase care au funtionalități independente , cu scopul de realiza secvențe complecte din cadrul scriptului de test.

Fișirele cu extensia bat au rolul de startare cu ajutorul comeni maven , al profilului care contine calea spre un fișier xml , in care este configurată suita claselor de test precum RunAutomationTest.Toate aceste funtionalități descrise mai sunt sunt folosite cu scopul de a crea un tool de testare automata, cat mai flexibil care sa permită execuția cat mai multor scripuri de test avănd ca rezultat asigurarea căt mai multor funtionalități ale sistemului.

Dezvoltare si implementare

Din punct de vedere al dezvoltării si implementării principalor funtionalităti care să permită rularea scripturilor de test intr-un mod cat mai flexibil sau utilizat mai multe tooluri care sa ofere un suport tehnic căt mai diversificat si performant.Principalele pachete care stau la baza implementării funcțiilor sistemului sunt din selenium webdriver api.

Deasemenea s-au folosit tooluri de creare al claselor de test precum TestNG, care sa suporte si mecanizme de distribuire al testelor pe arhitecturii distribuite care adoptă conceptul de virtualizare, făcand astfel posibilă reducerea duratelor de execuție al scripturilor de test si al costurilor achizitionari de masinilor fizice.

Pentru compilarea claselor si rularea claselor de test s-a folosit tool-ul Maven, in cadrul caruia sau configurat:

Plugin-uri de generare rapoarte

Profiluri de rulare de test

Dependente de librarii selenium webdriver

In continuare se vor prezenta modul de dezvoltare si implementare al celor mai importante clase din proiect.

Pentru implemantarea claselor care procesează fișierul de test json sau utilizat pachetele com.googlecode.json-simple și org.codehaus.jackson care oferă mecanizme de preluare si mapare al fieșierlor json.

Modul de citire si mapare al pasilor de test implementat in clasele JsonParseTest și JacksonJsonProcessing este:

Pentru procesarea string-ului de tipul

[{"id":"AC-1","action":"fillIn", ….. },{"id":"AC-2","action":"fillIn","elementPath":"pass",..}]

utilizăm implementarea de mai jos, unde “elem” ia valoarea string-ului descris :

Se relizează de asemenea maparea acțiunilor in obiectul actionMapped care se adaugă in map-ul actionMapOject, elementele sale find utilizate ca si parametrii pentru metodele dezvoltate in cadrul celelorlate clase.

Logica de indentificare al elementelor implementată in clasa ElementsPathConfiguration este dezvoltată in jurul urmatoarelor funcții:

Instanța WebDriver permite accesul la următoarele medotode de identificare al elemetelor html:

By.id(calea spre element= id)

By.className(calea spre element = clasa)

By.xpath(calea spre element = selectorul xpath)

Metoda primește ca si parametri obiectul de tip WebDriver, elementPath identificatorul elementului si tipul acestuia in funcție de care se alege modul de identificare.Dupa execuția părți de identificare al elementelor se poate trece dezvoltarea si implementarea actiunilor si resultatelor așteptate al testelor.

Implementare acțiunilor este următoarea:

Metodele oferite de selenium webdriver pentru acțiunile folosite sunt:

click()

clear()

sendKeys()

Select().selectByVisibleText()

La fel ca și in cazul indentificări elementelor logica alegeri tipului de acțiune se crează in jurul cuvintelor cheie din scriptul de test click , fillIn , select .

Implementarea pașilor care execută actiunile de verificare al rezultatelor așteptate este:

Metodele oferite de selenium webdriver care au fost imbunatățite in clasa UtilsActions sunt:

isElementPresent()

getText()

isDisplayed()

Metodele oferite de modul de test TestNg si folosite pentru validare sunt:

assertEquals()

assertTrue()

Logica folosită in implementarea acestei clase se compune in jurul cuvintelor cheie getAssert, isPresent, verify.

Pentru implementarea claselor de test RunAutomaitonTest, se folosesc anotările specifice acestor clase si care sunt dezvolate in cadul tool-ului TestNg:

@BeforeSuite

@Test

@AfterTest

@Parameters

Dezvoltarea clasei WebDriverSupplier este extrem de importantă deoarece aceasta implementează funtionalitate de instanțiere al driverlui browserului unde se vor excuta scriturile de test si modul de comunicare al acestora cu serverul selenium grid.

Implementarea metodelor clasei WebDriverSupplier este urmatoarea:

Clase din pachetul selenium webdriver folosite sunt:

WebDriver

FirefoxDriver

ChromeDriver

RemoteWebDriver

DesiredCapabilities

Cu ajutorul obiectului DesiredCapabilities se setează proprietațile browserelor care ruleaza pe mașinile remote.Pe baza acestei instanțe se gestionează la nivelul serverului selenium grid care din browsere execută suita de teste.

Modul de implementare al metodei responsabile pentru setarea capabilițătilor:

Dezvolatearea configurărilor suitelor de clase de test sunt implementate in fișiere xml care utilizează functionalitatea oferită de TestNg.Aceste fișiere sunt incluse la nivelul fișierului pom.xml in profile care utilizeaza pluginuri de compilare și de generare al raportelor testari.

Exemplu de configurare al suitelor claselor de test:

Modul de implementare al unui profil de test in fișierul pom.xml este:

Comanda maven de apel “mvn -PrunTestFireFox test” al acestui profil care execută suita de teste din fisierul TestSuitePatch.xml este scrisă la nivelul fișierelor ce extensia “.bat”.

Baza de date

Baza de date este proiectată in vederea gestionări utilizatorilor care vor utiliza aplicația KeyQuality.Este formata tabele „users”si „user_role” care memorează principalele caracteristici ale utilizatorilor.Tabele implementează o legătură de tipu 1:N.Pentru crearea bazei de date este folosit modelul relational MySQL.

Tipurile de date folosite implementate sunt prezentate in urmatorul tabel:

Definirea datelor si scopul utilizării acestora in aplicatie:

user_name = este utilizat pentru memorarea logarea utilizatorului in aplicație, si are rolul de cheie primară pentru tabela user

enable = are valoare implicită 1 , valoarea 0 inseamna user invalid

position = se va completa cu poziția tehnica al utilizarului

available = are valoarea 0,1

user_role_id = are valoare de cheie primară in tabelul user_roles

username=are valoare de cheie straină in tabela user_roles

role=valorile utilizate sunt ROLE_USER,ROLE_ADMIN acestea se validează cand user-ul se loghează in aplicație

UTILIZAREA SISTEMULUI

Instalare și configurare

Pentru utilizarea framework-ului de testare atutomată KeyQuality este necesară instalarea următoarelor programe:

Instalarea pachet java jdk 1.7

Instalare apache-maven-3.2.1

Se descarcă apache-tomcat-7.0.54

Se descarcă selenium-server-standalone-2.41.0.jar

Instalarea mediului de dezvoltare IntelliJ Idea

Instalarea bazei de date MySql Server

Se rulează scriptul de creare al bazei de date si se adaugă userul admin manual

Toate sursele descrise mai sus tooluri open-source și se găsesc pe siturile oficiale ale producătorilor.Sursa prectului se copiază pe partiția “D:” al computerului utilizatorului in directorul AutomationTool, urmănd mai apoi să fie configurat si startat cu ajutorul tool-lui de dezvoltare mentionat mai sus.

În continuare se prezintă pașii de importare si configurare al frameworkului cu ajutorul mediului de dezvolatare IntellliJ Idea:

Se pornește mediul de dezvoltare IntelliJ Idea

Se selectează din meniul File Import Project(vezi figura 5.1)

Figura 5.1 Meniu import proiect

Selectăm proiectul din locația unde a fost copiat(vezi figura 5.2)

Figura 5.2 Fereastră selectare proect

Se alege modelul de proect maven(vezi figura 5.3)

Figura 5.3 Fereastră de selectare a tipului de proiect

Clic pe butonul Next pană la apariția ecanului de mai jos, unde se selectează ca și in imagine proiectul apoi clic pe butonul Next(vezi figura 5.4)

Figura 5.4 Fereastră de selectare a tipului de proiect

Se face clic pe butonul plus verde din stanga sus și se alege locația unde a fost instalat java jdk(vezi figura 5.5)

Figura 5.5 Fereastră de alegere librărie jdk

Se poate da un nume proiectului și apoi clic pe butonul Finish(vezi figura 5.6)

Figura 5.6 Fereastră pentru denumirea proiectului

Clic pe butonul finish,This Window și apoi se reportnește mediul IntelliJ

Pasul noua setearea serverului in IntelliJ pentru rularea aplicației(vezi figura 5.7, 5.8)

Figura 5.7 Meniu editare configurație run

Figura 5.8 Fereastră alegere server

Se porneste aplicație din meniul prin clic pe butonul run iconița verde

Modurile de utilizare

Aplicația poate fi utilizată în două moduri și anume utilizatorul se logează cu rol de administrator sau se logheză cu rol de user.În urmatoarele imagine se prezinta modul de utilizare al aplicației.

Cazul în care utilizatorul are rolul de admistrator:

Utilizatorul se logează in aplicație cu credențiale personale

Figura 5.9 Pagină de logare

După introducerea cu success a elementelor de identificare în aplicație, este afișată pagina de mai jos cu menirile LIST OF USERS și Add USERS

Figura 5.10 Pagină de primire

În pagina ADD USERS se adaugă utilizatori noi in baza de date.In cazul în care nu se completează corect datele despre utilizator se vor afișa mesagele de eroare

Figura 5.11 Pagină adaugare utilizatori

Pagina de vizualizare utilizatori din bază de date,de aici se pot edita sau șterge utilizatori.

Figura 5.12 Pagină vizualizare utilizatorii

Pagina de editare al unui utilizator

Figura 5.13 Pagină editare utilizator

Utilizatorul se poate deloga din aplicație prin apăsarea butonului LogOut situat în drepta sus pe pagină

Cazul in care utilizatorul nu mai are rolul de administrator doar de utilizator:

Utilizatorul se logează în aplicație în mod normal cu credențiale valide.În cazul în care credențialele nu sunt bune se afișează un mesaj de eroare.

Figura 5.14 Pagină logare cu mesaj de validare credențiale

Pagina este afișată dacă utilizatorul s-a logat cu success în aplicație

Figura 5.15 Pagină de primire

Pagina de configurare pentru execuția locală a scripturilor de test

Figura 5.16 Pagină configurare execuție teste local

Pagina de configurare a executiei remote al testelor pe mașini virtuale este cea prezentată în figura de mai jos. Aici se alege tipul browser-lui unde se vor executa scripturile de test.

Figura 5.17 Pagină configurare execuție teste remote

Pagina de confirmare după finalizarea execuției scripturilor de test .

Figura 5.18 Pagină confirmare execuție teste

Pagina de unde se acesează rapoartele generate în urma execuței scripturilor de test.

Figura 5.19 Pagină accesare rapoarte

Pagină de rapoarte unde se vizualizează informati referitoare la testele care au executat.

Figura 5.20 Pagină vizualizare rapoarte

Pentru startarea serverului selenium grid si inregistrarea nodurilor se vor folosi urmatoarele comenezi:

java -jar selenium-server-standalone-2.41.0.jar -role hub -port 4444

java -jar selenium-server-standalone-2.41.0.jar -role node -hub http://IP/grid/register -nodeConfig config.json

Fișierul nodeConfig.json este scris sub forma:

{ "capabilities" : [ { "browserName" : "firefox",

"maxInstances" : 1,

"platform" : "WINDOWS",

"version" : "27.0"

},

{ "browserName" : "internet explorer",

"maxInstances" : 1,

"platform" : "WINDOWS",

"version" : "11"

}

],

"configuration" : { "cleanUpCycle" : 2000,

"hubHost" : "127.16.100.44",

"hubPort" : 4444,

"maxSession" : 1,

"nodePolling" : 2000,

"nodeTimeout" : 120,

"port" : 5556,

"register" : true,

"registerCycle" : 10000,

"timeout" : 300 }

}

TESTARE ȘI VALIDARE

Testarea și validarea principalelor funcționalități ale sistemului au fost realizate cu succes aplicația funcționând corect pentru fiecare caz in parte.

Șcenariile de testare ale aplicației dezvoltate au inclus urmatoare funcționalităti:

Testarea și validarea interfeței grafice a aplicației.Elementele din paginile web se randează corect in browserele Chrome și FireFox.

Testarea funcționalității de logare folosind diferite tipuri de utilizatori cu roluri diferite pentru a testa afisarea corecta a paginilor specifice fiecărui tip de utilizator.Abordarea testări negative cu date alterate in vederea testari recției corecte a aplicației.

Testarea de adaugare utilizatori noi, editare si stergerea lor din aplicație.

Din punct de vedere al funcționalități oferite de modulul de testare automată s-a verificat procesarea corectă al scriptului de test scris in format json. Configurarea la nivelul interfetei utilizănd toate combinațiile suportate al execuției scripturilor de test introduse in aplicație.

Scripturile au fost executate după configurațiile făcute din aplicație în urmatorul fel:

Pe masină locală:

Pe fiecare browser suportat de aplicație în parte:Mozilla FireFox,Chrome și IExplorer;

În parelel pe toate cele trei browsere.

Pe masină virtuală remote utilizănd aceleașii scenarii ca și in cazul testări locale

Startarea serverului selenium grid și inregistrarea nodurilor sau realizat cu success pentru a pune in evidentă funcționalitate de distribuiere al testelor pe mașini remote.

Rapoartele configurare cu ajutorul plugin-urilor importate si configurate in fișierul pom.xml, au fost generate cu succes in urma execuției scripturilor de test.

CONCLUZII

Realizări

În cadrul lucrării s-a realizat un suport de testare automată a aplicațiilor web folosind script-uri de test bazate pe cuvinte cheie. Scripturile au fost proiectate folosind un fișier de tip JSON si sunt scrise intr-un limbaj cât mai apropriat de cel natural facând posibilă astfel utilizarea acestui instrument de către personal fară competențe tehnice specifice. Scripturile de test se vor crea astfel, pe baza șablonului proiectat în acest scop.

Integrarea unui set de resurse ce facilitează realizarea acestui framework sunt:

Selenium Webdriver pentru partea de procesare si rulare al scripturilor de test

Spring mvc si hibernate pentru dezvolarea interfetei grafice cu utilizatorul si al bazei de date

TestNg pentru scrierea claselor de test

Maven pentru build-uri si integrarea pluginurilor de generare al raportelor

Aplicația oferă doua pagini dedicate configurării modului execuției al script-urilor de test pe diferite navigatoare web locale sau distribuite pe mașini virtuale sau fizice. Inainte de utilizarea funcționalității pentru a rula testele remote, se starteaza serverul de Selenium grid și se înregistrează pentru ca testele să poata accesa arhitectura distribuita oferita de aceste module.

Aplicația pune la dispoziție in pagina “Automation Run Test Local” următoarele moduri de configurare a execuției:

Execuție independent pe unul din browserele Internet Explorer, Mozilla FireFox , Chrome;

Execuție in paralel pe doua sau trei browsere alese de utilizator.

Aplicația pune la dispoziție in pagina “Automation Run Test Remote” următoarele moduri de configurare al execuției:

Execuție remote independent pe unul din browsere Internet Explorer, Mozilla FireFox , Chrome;

Execuție in paralel remote pe două sau trei browsere alese de utilizator.

Deoarece in testarea automată interpretarea rezultatelor este un pas extrem de important sau configurat plugin-uri de generare al rapoartelor la nivelul fișierul pom.xml din maven.

In urma execuției scripturilor rapoartele generate au următoarele caracteristici de bază pentru interpretarea rezultatelor:

testul este valid sau invalid,

timpul de execuție,

numele suitelor si claselor de test care rulează,

excepții generate în procesul execuției propriu-zise.

Framework-ul pune la dispoziție și rolul de admin prin care sunt gestionație utilizatorii sistemului.Principalele funcții de gestiune al clienților sunt:

Adaugare utilizator nou

Editare utilizator

Stergere utilizator

Așadar prin studiul facut asupra domeniului testării automate și al integrarii tuturol funcționalitățiile prezentate mai sus, consider că s-a indeplinit tema acestui proiect.

Direcții de dezvoltare

Direcțiile de dezvoltare, ca și in cazul multor sisteme proiectate din diverse domenii, sunt binevenite să aducă un plus inovativ care să crească și mai mult performațele sistemului.

Imbunatățirele framework-ului KeyQuality pot fi aduse în direcția dezvoltării caracteristicilor funcționale:

Interfață grafică mai dezvoltată in direcția integrării procesului de testare STLC

Extinderea funționalităților la nivelul modului de automatizare: suport pentru toate navigatoarele,

modurile de identificare a elementelor diversificate

o abstractizare mai complexă a scripturilor de test care să poată fi memorate la nivelul aplicației fiind posibile o predicție al pasilor si zonelor testate

atribuire de funcții de inteligentă artificială in vederea memorarii și învațării a sistemului aflat sub test.

Toate direcțiile prezentate mai sus pot constitui direcții de cercetare in domeniul dezvoltări si asigurării calități software.

Bibliografie:

William E. Lewis ,Gunasekaran Veerapillai,Second Edition, Software Testing and Continuous Quality Improvement,anul 2005;

Manfred Rätzmann, Clinton De Young, Galileo Computing Software Testing and Internationalization,anul 2003;

Linda G. Hayes, The Automated Testing Handbook,

Gary Mak, Josh Long, and Daniel Rubio, Spring Recipes, Second Edition,anul 2010;

Dave Minter, Jeff Linwood,Beginning Hibernate: From Novice to Professional,anul 2006;

David Burns, Selenium 2 Testing Tools,anul 2012;

http://blog.testing-whiz.com/2013/06/comparing-qtp-selenium-and-testingwhiz.html

http://docs.spring.io/spring/docs/2.5.6/reference/mvc.html

http://www.tutorialspoint.com/spring/spring_web_mvc_framework.htm

http://www.wikipedia.org/ ;

Bibliografie:

William E. Lewis ,Gunasekaran Veerapillai,Second Edition, Software Testing and Continuous Quality Improvement,anul 2005;

Manfred Rätzmann, Clinton De Young, Galileo Computing Software Testing and Internationalization,anul 2003;

Linda G. Hayes, The Automated Testing Handbook,

Gary Mak, Josh Long, and Daniel Rubio, Spring Recipes, Second Edition,anul 2010;

Dave Minter, Jeff Linwood,Beginning Hibernate: From Novice to Professional,anul 2006;

David Burns, Selenium 2 Testing Tools,anul 2012;

http://blog.testing-whiz.com/2013/06/comparing-qtp-selenium-and-testingwhiz.html

http://docs.spring.io/spring/docs/2.5.6/reference/mvc.html

http://www.tutorialspoint.com/spring/spring_web_mvc_framework.htm

http://www.wikipedia.org/ ;