Testarea Software
Listă abrevieri
STLC – Software Testing Life Cycle
UAT – User acceptance testing
ISTQB – International Software Testing Qualifications Board
SEETB – South European Testing Board
TDD – Test Driven Development
TC (test cases)
CSS – Cascading Style Sheets
URL – Uniform Resource Locator
IDE – Integrated Development Environment
RC – Remote Control
HTML – HyperText Markup Language
Listă figuri
Figura 1.1 Structura certificării ISTQB [4] ……………………………………………………….….4
Figura 2.1 Șapte Principii ale testării [19] …………………………………………………………….9
Figura 2.2 Etape în procesul de testare ……………………………………………………………..10
Figura 2.3 Testarea black box …………………………………………………………………….…12
Figura 2.4. Testarea white box ………………………………………………………………………13
Figura 2.5 Nivele ale testării …………………………………………………………………………14
Figura 2.6 Testare unitară ……………………………………………………………………………14
Figura 2.7 Testarea de integrare … …………………………………………….……………………15
Figura 2.8 Testarea sistemului ………………………………………………………………………16
Figura 2.9 Gama de browsere, tehnologii………………………………………..………………….22
Figura 2.10 Pachetele Selenium ……………………………………………………………………..22
Figure 2.11 Diferențe suita Selenium…………………………………………………………………23
Figura 2.12 Diferențe Selenium-Ranorex……………………………………………………………29
Figura 3.1 Diagrama logică ………………………………………………………………………….31
Figura 3.2 Java . ……………………………………………………………………………………..32
Figura 3.3 Eclipse IDE……………………………………………………… ………………………32
Figura 3.4 Selenium Java Client Driver …………………………………………………….……….33
Figura 3.5 Adăugare librării……………………………………………………………………….…34
Figura 3.6 Biblioteci……….………………………………………………………………………….34
Figura 3.7 Structura proiectului….………………………………………………………………..…35
Figura 3.8 DataAddAnnouncement………………………………………………………………….36
Figura 3.9 DataLogin…………………………………………………………………………..…….36
Figura 3.10 AddNewAnnouncement…………………………………………………………………37
Figura 3.11 Inspect element……………………………………………………………………….…37
Figura 3.12 Id element……………………………………………………………………………….38
Figura 3.13 Xpath element……………………………………………………………………………38
Figura 3.14 LoginLocators……………………………………………………………………………39
Figura 3.15 MainPageLocators………………………………………………………………………39
Figura 4.1 Rulare teste……………………………………………………………………………….44
Figura 4.2 Rezultat teste rulate………………………………………………………………………45
Figura 4.3 Rezultat teste login……………………………………………………..…………………45
Figura 4.4 Rezultat test adaug anunț…………………………………………………………………46
Figura 4.5 Rezultat test adaug anunț picat……………………………………………………………46
Figura 4.6 Rezultat test caut anunț………………………………………………………….……….47
Figura 4.7 Rezultat test caut anunț picat………………………………………………….……….…47
Figura 4.8 Rulare teste ………………………………………………………………………………48
Figura 4.9 Rulare teste…………………………………………………………………………….…48
Figura 4.10 Rulare teste din fereastră……………………………………………………………..…49
Figura 4.11 Run Config………………………………………………………………………………49
Figura 4.12 Run teste success….………………………………………………………….…………50
Figura 4.13 Run teste fără success……………………………………………………………………50
Rezumat în limba engleză
State of the Art
1.1 Generalities
We can assume that each person can be wrong at a certain point, it is needed that each of us has to verify it is own work. All in all some mistakes come from some bad ideas or some dead angles to say so, it is not enough for each person to verify it’s own work. Later it is required for other people to verify the quality of the software product, motiv of wich testing is divided in categories, stes or testing methods.
1.2 ISTQB – attested certification for software testing
ISTQB is a global organisation with the vision to enable the testing profesionals through a certified standards of software testing accepted worldwide, to help the development of they’r profesional career. ISTQB has created the most renowed scheme with the purpose to certify the software testers. The sistem is based on a set of knowledge, and some examination norms, wich are applied all around the world. The material and the exams are available in a multitude of languages.
2. Theoretical Fundamentals
2.1 Introduction
According to the literature, testing is the process of running a program in order to find errors. An error can be almost anything but typically means a problem, a console log, or other operation where you can continue, but receive the incorrect result. Of course, the first thought leads us to the programmer because he is the one who writes the program, but this is only a small part of the problem.
Software Testing Life Cycle refers to a testing process which has specific steps to be executed in a definite sequence to ensure that the quality goals have been met. In STLC process, each activity is carried out in a planned and systematic way. Each phase has different goals and deliverables. Different organizations have different phases in STLC; however the basis remains the same.
Below are the phases of STLC:
Requirements phase
Planning Phase
Analysis phase
Design Phase
Implementation Phase
Execution Phase
Conclusion Phase
Closure Phase
2.2 Principles of Software Testing
a. Testing shows the presence of bugs
Testing an application can only reveal that one or more defects exist in the application, however, testing alone cannot prove that the application is error free. Therefore, it is important to design test cases which find as many defects as possible.
b. Exhaustive testing in impossible
Unless the application under test (UAT) has a very simple logical structure and limited input, it is not possible to test all possible combinations of data and scenarios. For this reason, risk and priorities are used to concentrate on the most important aspects to test.
c. Early testing
The sooner we start the testing activities the better we can utilize the available time. As soon as the initial products, such the requirement or design documents are available, we can start testing.
d. Defect clustering
During testing, it can be observed that most of the reported defects are related to small number of modules within a system. i.e. small number of modules contain most of the defects in the system. This is the application of the Pareto Principle to software testing: approximately 80% of the problems are found in 20% of the modules.
e. The pesticide paradox
If you keep running the same set of tests over and over again, chances are no more new defects will be discovered by those test cases. Because as the system evolves, many of the previously reported defects will have been fixed and the old test cases do not apply anymore.
f. Testing is context dependent
Different methodologies, techniques and types of testing is related to the type and nature of the application. For example, a software application in a medical device needs more testing than a games software.
g. Absence of errors fallacy
Just because testing didn’t find any defects in the software, it doesn’t mean that the software is ready to be shipped [21]
2.3 Testing Methods
2.3.1 Black-box Method
Black Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is NOT known to the tester.
2.3.2 White-box Method
White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester.
2.4 Testing Levels
2.4.1 Unit testing
A unit is the smallest testable part of an application like functions, classes, procedures, interfaces. Unit testing is a method by which individual units of source code are tested to determine if they are fit for use.
Unit tests are basically written and executed by software developers to make sure that code meets its design and requirements and behaves as expected.
2.4.2 Integresion testing
Integration testing tests integration or interfaces between components, interactions to different parts of the system such as an operating system, file system and hardware or interfaces between systems.
Also after integrating two different components together we do the integration testing.
2.4.3 System testing
In system testing the behavior of whole system/product is tested as defined by the scope of the development project or product.
2.4.4 Acceptance testing
After the system test has corrected all or most defects, the system will be delivered to the user or customer for acceptance testing.
Acceptance testing is basically done by the user or customer although other stakeholders may be involved as well.
The goal of acceptance testing is to establish confidence in the system.
2.5 Automation testing
Using Automation tools to write and execute test cases is known as automation testing. No manual intervention is required while executing an automated test suite. Testers write test scripts and test cases using the automation tool and then group into test suites.
2.5.1 Selenium
Selenium-WebDriver makes direct calls to the browser using each browser’s native support for automation. How these direct calls are made, and the features they support depends on the browser you are using. Information on each ‘browser driver’ is provided later in this chapter.
3. Implementation
3.1 Project structure
In order to highlight the advantages of the Selenium tool, there were created some auto tests by using a known site called ‘www.olx.ro’.
There were created more tests, among which:
Successfully Login
Failed Login
Verifying the title of the page if the login is successful
Verifying the mandatory fields for the page where a new announcement can be added
Looking for a certain product and checking the result
In order to have a better structure and highlight how the tests have to be created, five packages have been created:
Data – this package contains some classes with the data which is used for fill in the fields
Locators – this package contains some classes for identify the elements within the Web page
Setup- this package contains the main test (there is a method where the desired bowser is set)
Testexec – this package contains the classes with the test which were created
Teststeps – this package contains the classes where the all the methods have been written
3.1.1 Setup package
This package contains the MainTest class, in this class has been created the method setBrowser() for setting the desired browser. This class contains the SetUp() and TearDown() methods as well, the role of these methods is for setting and closing the browser for every test which was executed. Which means that these tests can be run independent.
3.1.2 Testexec package
This package contains three classes, every class contains one test where are called all the methods which were created in another classes from teststeps package.
TestExecusion
TestExecutionAddNewAnnouncementFailed
TestExecutionSearchAnnouncement
3.1.3 Teststeps package
The teststeps package contains three classes where have been written the methods for fill in some fields, for selecting a certain button, making some validations for a label, etc:
ScreenActionsAddNewAnnouncement
ScreenActionsLogin
ScreenActionsSearchAnnouncement
For example the ScreenActionsLogin class contains more methods, among which: fillinUser(), VerifyPageTitle(), VerifyLabelLoginFailed(), etc. In order to be able to use the data from the LoginLocators and DataLogin classes, the following instances have to be done:
public LoginLocators loc = new LoginLocators();
public DataLogin dat = new DataLogin();
public void fillinUser()
{
try{
driver.findElement(loc.user).sendKeys(dat.userlogin);
}
catch(NoSuchElementException e){
screenshot();
}
}
4. Experimental Results
As I said above the advantage of the auto tests is that can be run every test independently. For example the TestExecution class contains two tests, the first one is for testing the login functionality when there are valid data and the second one is for the case when the data is not valid any more.
After running these two tests, the results can be viewed and can be noticed if both of them passed successfully or not and the duration of each test.
Figure 1. Tests results
If a label is changed, for example if the text of the label which is displayed when the user and password are not valid, can be noticed that the test which verify that functionality failed:
Figure 2. Analyze error
Also all the tests which were created can be run in the same time:
Figure 3. All tests results
5.Conclusion
The purpose of this paper was to bring out the differences between manual testing and automatic testing.
Manual testing , long time seen as the only solution to discover the defects, it delays a lot the launch of the product and brings with it a lot of costs especialy when discovered the defects.The proceses of manual testing , through they’r limited nature , don’t find all the defects and don’t have a chance to simulate the terms of simultaneous utilization , intensive, of an application. There are numerous ways to improve the testing process, one of the most efficient is the automatic testing.
Autonomus testing execute a sequence of actions without human intervension and can simulate the utilization of an application in ters of high simultaneity. In general, the majority of the products needs to be tested many times , on different software and hardware platforms, after the changes or at the launch of a new version of the product.
Planificarea activității
1. Stadiul actual
1.1 Introducere
Obiectivul acestui raport este acela de a definii cât se poate de bine termenul de testare, rolul testării și de ce este necesară sau unde se folosește testarea. Trăind într-o lume în care software-ul are un cuvânt greu de spus, fiind într-o continuă dezvoltare este important ca atunci când există deja un soft pentru un anumit produs să ne asigurăm că software-ul produsului respectiv are o calitate cât se poate de bună indiferent din ce punct de vedere îl privim, iar acest lucru, practic fără testare nu poate fi realizat. Chiar dacă produsul software este trecut prin toate etapele testării la final nu putem spune că a existat o parte a testării care a permis detectarea tuturor defectelor posibile ce le poate conține produsul în sine.
În zilele noastre aproape oricine este conștient de importanța și ceea ce înseamnă un sistem software. Aceste sisteme sunt întâlnite în viața de zi cu zi (acasă, la serviciu, etc). Din ce în ce mai mult ele fac parte din viața noastră. Cu toate acestea mulți dintre noi am avut o problemă sau mai bine zis o experiență nu foarte plăcută cu un software care nu lucra cum ne așteptam (o sumă de bani primită greșit de la un bancomat, un site care nu încarcă ceea ce dorim sau încarcă foarte greu, etc), toate aceste lucruri se pot întâmpla din cauza problemelor software. Poate unii dintre noi ne întrebăm de ce este nesesară testarea, sau de ce în această perioadă majoritatea companiilor mari pun accept foarte mare pe această etapă care face parte din implementarea produsului software.
Nu există nici o abordare sau strategie de testare care să permită identificarea tuturor defectelor posibile, pe care le poate conține un produs software. Totodată, un astfel de proces poate genera un punct de vedere comparativ, care vine să evidențieze unele caracteristici ale produsului (cum ar fi: starea și comportamentul actual) metricile și limitările care servesc drept condiții de acceptanță. Fiecare produs software are un public de utilizatori caracteristic. De exemplu, publicul pentru un produs din industria jocurilor video este complet diferită de audiența unui produs din sistemul bancar. De aceea, când o companie dezvoltă sau investește în dezvoltarea unui produs software, ea trebuie să fie capabilă să investigheze acceptabilitatea produsului din perspectiva utilizatorilor finali, publicului țintă, cumpărătorilor și altor părți interesate. Procesul de testare software este procesul care vine să realizeze această evaluare, efectuată într-un mod cât mai obiectiv.
Când este vorba de procesul de testare, una dintre cele mai importante probleme într-o organizație este dacă să se automatizeze sau să se testeze manual. Nu toate testele pot sa fie automatizate și de cele mai multe ori este dificil de luat o decizie in legatură cu ce să se automatizeze și ce să se testeze manual.
Testarea manuală, a fost vazută singura soluție de a gasi defecțiuni software timp de mult timp. Aceasta încetinește foarte mult procesul de release al produsului pe piață și introduce costuri semnificative, atât în procesul proiectării unei aplicații cât și în cazul schimbărilor ulterioare. Totodată abordările de testare manuală, prin caracteristicile lor limitate, nu reușesc să descopere toate defectele. Există numeroase modalități de a aduce o imbunătățire procesului de testare, una dintre cele mai eficiente fiind testarea automată.
Testele automate execută o secvență de pași fără intervenția omului și pot simula utilizarea unui produs în condiții de simultaneitate ridicată. Majoritatea produselor necesită să fie testate de mai multe ori, pe mai multe infrastructuri software și hardware și după schimbările ulterioare sau la lansarea unei noi versiuni de produs. Prin folosirea procesului de testare automată, costurile repetării testărilor se reduc aproape la zero.
Aceste companii pun accentul pe asigurarea calității produsului software din mai multe motive. Unul dintre aceste motive este acela că aceste produse sunt gândite și implementate de către oameni. Foarte mulți dintre acești oameni fac anumite greșeli, doar că unele dintre acestea sunt nesemnificative, altele sunt mai puțin semnificative, altele sunt greșeli mai semnificative sau putem spune că sunt periculoase. Acesta este unul din motivele cele mai importante si faptul căruia i se datorează în mare parte testarea.
1.2 Generalități
Deoarece trebuie asumat faptul că fiecare persoană poate greși la un moment dat, este nevoie în primul rând ca fiecare să-și verifice propria muncă. Cu toate acestea greșelile vin de la unele ipoteze rele sau anumite unghiuri moarte dacă se pot numi așa, deci nu este îndeajuns ca fiecare persoană să-și verifice propria muncă. Ulterior este nevoie de alte persoane care să mai verifice ori de câte ori este nevoie calitatea produsului software, motiv pentru care testarea se împarte în mai multe categorii, etape și moduri sau metode de testare.
Putem compara produsul software cu viața umană, uneori sunt anumite greșeli care nu contează aproape deloc în viața umană dar din păcate sunt și unele care pot marca întreaga perioadă de supraviețuire. Cu cât suntem mai precauți și cu cât le descoperim mai repede avem posibilitatea de a le îndrepta sau chiar de a le corecta.
Această idee de bază se poate folosi și în ciclul de viață al unui produs software, adică cu cât defectele sunt descoperite mai repede cu atât calitatea produsului este mai bună și nu se ajunge într-o perioadă care necesită foarte mulți bani pentru a putea corecta sau elimina chiar complet anumite defecte conținute de produsul software. Fiecare proiect trebuie să conțină un plan amplu de testare care să cuprindă toate funcționalitățile aplicației și să asigure funcționarea corectă a întregului produs. Strategiile de testare se concentrează pe funcționalitatea și utilizabilitatea produsului. Testarea software reprezintă o investigație empirică realizată cu scopul de a oferi părților interesate informații referitoare la calitatea produsului sau serviciului supus testării luând în considerație contextul operațional în care acesta din urma va fi folosit.
Testarea software pune la dispoziție o viziune obiectivă și independentă asupra produsului în dezvoltare, oferind astfel business-ului posibilitatea de a înțelege și evalua riscurile asociate cu implementarea produsului soft. Testarea nu este procesul prin care se demonstrează că nu mai există erori [Dij69], sau procesul prin care se arată că un anumit program functionează corect având funcționalitatea pentru care a fost dezvoltat ci este procesul prin care se execută un program cu intenția de a găsi erori [Myers] sau realizarea testării asupra unui produs software are ca scop semnalarea prezenței defectelor fară a garanta absența lor. Pentru o testare de calitate, este important să existe o planificare riguroasă a testării încă din faza de proiectare sau development. Pe măsură ce se conturează definițiile modulelor, entităților de date, obiectelor, claselor, funcțiilor, etc. este recomandabil să se scrie și “scenarii” de testare ale acestora.[3]
Adeseori, testarea este văzută ca și constând într-o suită de teste care rulează, executând produsul software. Aceasta într-adevăr face parte din testare, dar nu definește întreg procesul de testare. Activitățile de testare au loc înainte și după executarea testelor. Aceste activități includ planificarea și controlul, alegerea condițiilor de test, proiectarea și executarea cazurilor de test, verificarea rezultatelor, evaluarea criteriilor de ieșire, raportarea proceselor de testare și a sistemului aflat sub test, și finalizarea activităților de încheiere după ce o fază de test a fost încheiată. Testarea include de asemenea revizuirea documentelor (inclusiv a codului sursă) și efectuarea analizei statice. Atât testarea dinamică cât și cea statică, pot fi folosite ca și mijloace pentru obținerea obiectivelor similare, ele vor furnizând informații care pot fi uitlizate pentru îmbunătățirea sistemului care trebuie testat, dar și a procesului de dezvoltare și a proceselor de testare.
Satisfacerea cerințelor clientului este cheia reușitei oricărei afaceri. De asemenea încrederea clientului poate fi câștigată doar prin oferirea unui soft care este unul bun și care respectă așteptările clientului. Iar pentru a indica calitatea softului este nevoie ca acesta să fie testată. Principala sursă a apariției erorilor este lipsa comunicării între membrii echipei care participă la dezvoltarea produsului software. Erorile depistate și fixate în faza de descriere a specificațiilor nu costă practic nimic. În schimb dacă acestea sunt descoperite după livrarea produsului pot fi destul de costisitoare, din aceasta cauză testarea joaca un rol deosebit de important. Să ne gândim la consecințele greșelilor. Putem spune ca suntem de acord că orice om fiind, programator sau tester, poate face o eroare. Aceste erori pot produce defecte în codul sau sistemul de software, sau într-un document. În cazul în care un defect în cod nu este descoperit, sistemul poate fi un eșec. Deci, greșelile pe care le facem sunt foarte importante pentru că ele au consecințe pentru produsele pentru care suntem responsabili. Deci, greșeli noastre sunt importante, deoarece sistemele și proiectele software sunt complicate. Omul, prin natura lui, este predispus la a face erori (greșeli), care duc la un defect (bug) în codul programului, sau într-un document. Dacă un defect dintr-un cod este executat, sistemul poate eșua în a face ceea ce trebuie, provocând căderea întregului sistem. Defectele în produsele software, în sisteme sau în documente pot duce la eșecuri, însă nu toate defectele fac asta. Defectele apar deoarece omul este imperfect, timpul este limitat, codul și infrastructura sunt complexe, iar tehnologiile se schimbă foarte des.[1]
1.3 ISTQB – certificare atestată pentru testarea software
ISTQB este o organizație globală a cărei viziuni este de a permite profesioniștilor de testare prin intermediul unor standarde de certificare de testare software acceptate la nivel mondial, de a sprijini dezvoltarea carierei lor profesionale. ISTQB a creat cea mai renumită schemă în scopul certificării testerilor de software. Sistemul se bazează pe un set de cunoștințe, precum și norme de examen, care sunt aplicate în mod consecvent peste tot în lume. Materialele și examenele sunt disponibile în mai multe limbi.
ISTQB promovează un program numit ISTQB Certified Tester, bazat pe o schemă de certificare structurată pe trei niveluri: foundation, advanced și expert. Această schemă de certificare este recunoscută și acceptată în mai mult de 70 de țări în care există comitete naționale sau regionale ISTQB. Peste 300.000 de persoane din întreaga lume au fost certificate în cadrul ei. ISTQB este alcătuit din peste 45 de organizații regionale și naționale. Organizațiile naționale și regionale controlează procesul de acreditare și certificare prin regulamente specifice. SEETB – South European Testing Board, în calitate de membru oficial al ISTQB, administreaza certificarea internațională ISTQB în Europa de Sud-Est, Bulgaria, Muntenegru, România, Serbia -prin autorizarea companiilor și certificarea trainerilor.
Figura .1 Structura certificării ISTQB [4]
Cele 3 niveluri de certificare sunt:
a. Foundation Level:
Acest nivel se adresează profesioniștilor care au nevoie să demonstreze cunoștințele practice ale conceptelor fundamentale de testare software. Aceasta include: designeri de testare, analiști de testare, ingineri de test, consultanți de testare, manageri de testare. Nivelul foundation este de asemenea potrivit pentru oricine care are nevoie de o înțelegere de bază a testarii software, cum ar fi manageri de proiect, manageri calitate, manageri de dezvoltare de software, analiști de afaceri, directori de IT și consultanți de management.
Cei care dețin această certificare ar trebui să fie în măsură să:
• folosească un limbaj comun pentru comunicare eficientă și eficace cu alti testeri.
• ințeleagă concepte stabilite de testare, procesul de testare fundamental, abordări de testare.
• prioritizeze design-ul testelor prin utilizarea tehnicilor stabilite.
• analizeze specificațiile funcționale si cele non-funcționale
• execute teste în conformitate cu planurile de testare convenite
• analizeze și să raporteze rezultatele testelor.
• scrie rapoarte de incidente clare și ușor de înțeles.
• fie familiarizat cu diferite tipuri de instrumente de testare și utilizările lor.
• asiste în procesul de selecție și de punere în aplicare.
b. Advanced Level:
Nivelul avansat este destinat persoanelor care au atins un punct avansat în testarea software. Pentru a primi certificare de nivel avansat, candidații trebuie să dețină certificatul Foundation și să aiba suficientă experiență practică. Nivelul advance conține 3 module:
• Test Manager
• Test Analyst
• Technical Test Analyst
Un examen specific este disponibil pentru toate cele trei module. Tester-ul își prelungește înțelegerea largă de testare achiziționată la nivelul foundation pentru a „activa” rolul de test manager sau test analyst. Abilitățile unui test analyst pot fi extinse în continuare în rolul unui technical test analyst. După obținerea experienței pentru un test manager, o persoană poate alege să dezvolte cariera prin achiziționarea de certificate de nivel expert. Oamenii care dețin un certificat de nivel avansat ISTQB pot utiliza certificarea în funcție de modul în care aceasta este certificată. Oamenii care dețin toate cele 3 certificate de nivel avansat pot obține nivelul “Full Advanced level”.
c. Expert Level:
Acest nivel extinde cunoștințele și experiența obținută la nivelul avansat, oferind în profunzime, certificări practice orientate într-o gamă diferită de subiecte de testare. Criteriile sunt stabilite pentru a asigura o calitate bună și consecventă a acestui nivel. Pentru a obține certificarea, candidații trebuie să aibă nivelul foundation, advance, cel puțin 5 ani de experiență practică de testare și cel puțin 2 ani de experiență în subiectul specific pentru nivel de expert.
Nivelul expert are 5 module, 3 lansate și 2 in development:
• Improving the Testing Process
• Test Management
• Test Automation Engineering
• Test Automation Management (in progres)
• Security Testing (in progres)
O persoană cu această certificare este o persoană cu abilități speciale și cunoștințele reprezintă stăpânirea pe un anumit subiect de testare. Fiind un expert de testare înseamnă posesia aptitudinilor speciale și a cunoștințelor derivate din formarea, experiența și capacitatea de a aplica aceste cunoștințe în situații din viața reală. Un expert de testare este o persoană care combină o înțelegere mai amplă de testare, cu o înțelegere în profunzime într-o anumita zonă de test. O înțelegere în profunzime înseamnă suficiente cunoștințe de teorie și practică de testare pentru a putea influența direcția pe care o organizație sau un proiect o ia la crearea, implementarea și executarea activităților de testare referitoare la acea zona. Persoana certificată este capabilă sa efectueze fiecare din următoarele activități:
• conduce programe pentru imbunătățirea procesului de testare într-o organizatie sau intr-un proiect
• poate identifica si gestiona factori critici cu succes.
• să ia decizii corespunzătoare cu privire la modul de abordare de îmbunătățire a procesului de testare
• evaluarea situației actuale a unui proces de testare, propune îmbunătățiri înțelepte
• arată modul în care modificarile sunt legate de atingerea obiectivelor de business
• configurarea unei politici strategice pentru îmbunătățirea procesului de testare
• punerea în aplicare a acestei politicii pentru imbunatățire
• analiza problemelor specifice cu procesul de testare și să propună soluții eficiente
• dezvoltarea unor concepte organizationale de îmbunătățire a procesului de testare care includ roluri necesare, competențe și structură organizatorică
• să înțeleagă și să gestioneze în mod eficient problemele umane asociate cu evaluarea procesului de testare și punere în aplicare a modificărilor necesare. [4]
2. FUNDAMENTARE TEORETICĂ
2.1 Introducere
Eșecurile pot fi cauzate de condițiile de mediu, precum: de exemplu, o explozie de radiații, un puternic camp magnetic, câmpurile electronice ar putea provoca defecțiuni la hardware. Aceste defecte ar putea preveni sau modifica executarea software-ului. Eșecurile pot apărea, de asemenea, din cauza unei erori umane în interacțiunea cu software-ul, poate o valoare de intrare fiind introdusă greșită sau o ieșire se poate interpreta gresit. Când un tester constată un defect, programatorul trebuie să localizeze defectul în cod și să-l fixeze. Am văzut că erorile umane pot provoca un defect sau o eroare care apare sau este introdusă în orice etapă a ciclului de viață de dezvoltare a produsului software au consecințe asupra rezultatelor, acestea putând fii slabe sau chiar catastrofale, asta înseamnă că testarea este necesară în timpul dezvoltării și întreținerii întregului produs pentru a crește calitatea sistemului operațional. Dacă ar fi sa evaluăm calitatea produselor software două dintre atributele cele mai importante ar fi:
Siguranța
Eficiența
Siguranța se referă la completitudine si la consistența, adică să se trateze toate intrările posibile și produsul să se comporte întotdeauna așa cum este de așteptat. În mod normal eficiența este întotdeauna mai puțin importantă decât siguranța, deoarece se referă la faptul utilizării a resurselor intr-un mod cât mai eficient si întotdeauna este mai ușor să facem un program sigur să fie eficient, decât un program eficient să fie sigur. Un alt atribut al calității ar fi utilitatea care se referă la masura în care produsul soft satisface cerințele utilizatorului. Cu toate acestea pentru a avea o calitate a produsului cât mai bună trebuie sa ținem cont de următoarele activități:
Analiza statică
Analiza dinamică
Analiza statică se referă la examinarea unor documente (cod sursă, diagrame de clase, specificații, modele conceptuale, etc). Această analiză statică include activități de inspectare a codului, analiza algoritmului și demonstrarea corectitudinii si nu include activitatea de execuție propriu-zisă a programului. Analiza dinamică presupune examinarea comportamentului programului cu scopul de a evidenția defecțiunile posibile. Această analiză include activitatea de execuție propriu-zisă a programului. Punctele diferite de vedere iau în considerare diferite obiective. De exemplu, în testarea din etapa de dezvoltare (unit testing, integration testing și system testing), obiectivul principal este de a cauza cât mai multe eșecuri astfel încât să se poată identifica și rezolva defectele cât mai repede posibil. În testarea de acceptanță, principalul obiectiv este acela de a confirma că sistemul funcționează conform cerințelor, pentru a câștiga încrederea în acesta. În unele cazuri principalul obiectiv al testării ar putea fi de a evalua calitatea software (fără intenția de a rezolva defecte), de a oferi informații despre riscul lansării produsului într-un anumit timp. Testarea de mentenanță include adesea testarea în vederea confirmării că nu au fost introduse alte defecte în timpul schimbărilor făcute în perioada de dezvoltare de noi funcții. În timpul testării operaționale, principalul obiectiv poate fi evaluarea caracteristicilor sistemului, gradul de încredere sau disponibilitatea. Debuggingul și testarea reprezintă două procese diferite. Testarea dinamică poate arăta eșecuri care sunt provocate de defecte. Debuggingul este activitatea de dezvoltare care găsește, analizează și înlătură cauza eșecului. Retestarea făcută de către tester este cea care asigură că fix-ul rezolvă într-adevăr eșecul. Responsabilitățile pentru aceste activități sunt împărțite astfel : testarea pentru testeri, iar debuggingul pentru developeri. [1]
Testarea se face pe tot parcursul ciclului de viață al produselor software și include mai multe etape:
Planificarea – activitățile au loc înainte și după executarea testării, deoarece testarea trebuie gestionată, de exemplu, ne-am propus ceea ce vrem să facem. Există și un raport privind progresele testării și starea software-ului testat.
Prepararea – de acestă etapă este nevoie pentru a alege tipul de testare pe care îl vom face, prin selectarea și alegerea tipului de testare și crearea test case-urilor (cazurilor de test).
Evaluarea – după executarea testelor, rapoartele generate și rezultatele trebuie verificate și analizate, deoarece asta contribuie la luarea deciziei dacă produsul software a trecut cu succes sau nu testele.
2.2 Browsere folosite
Un browser este o aplicație software care permite utilizatorilor să afișeze informații de tip text, grafică, video, muzică și altele poziționate pe o pagină din World Wide Web. Cele mai cunoscute și importante browsere sunt Internet Explorer, Safari, Mozilla Firefox, Opera, Google Chrome. Incepând cu anul 1991, dezvoltarea browserelor începe să ia amploare, atunci când o diversitate de tehnologii i-au permis lui Tim Berners Lee să creeze primul browser web. Termenul de hyperlink a fost deja introdus in randul utilizatorilor de Ted Nelson și Douglas Engelbart cu mult înainte de Tim Berners Lee.
2.2.1 Internet Explorer
Descriere:
Internet Explorer este un browser de navigare web produs și dezvoltat de firma Microsoft, devenind unul dintre cele mai populare browsere din lume, transmis odată cu sistemul de operare Windows pe calculatoare sau device-uri mobile. Istoria acestui browser începe în anul 1995, an în care sistemul de operare Windows 95 este lansat pe piață. Internet Explorer a primit multe critici pentru golurile si incertitudinile sale în materie de securitate și performanță. Internet Explorer era pe punctul să fie exclus din sistemul de operare Windows 7 și Windows Server 2008 R2 în versiunile acestor sisteme din Europa, dar gigantul IT l-a inclus totuși la lansarea acestor sisteme în pachetul de programe cu care vin instalate implicit, incluzând însă și un ecran de alegere pentru utilizatori între mai multe browsere, care să fie browser-ul principal de navigare. Multe din caracteristicile noi nu sunt ușor de observant: trebuie accesat meniul browser-ului, Settings – Advanced pentru a le gasi. Acolo sunt prezente urmatoarele: dezactivarea și accelerarea hardware, alegerea schimbării tab-urile în ordinea folosirii, funcția de completare inline a textului să fie disponibilă în Windows Explorer și în fereastra Run din Windows.
2.2.2 Google Chrome
Descriere:
Google Chrome este un browser web de tip open source dezvoltat de compania Google. Este unul dintre cele mai populare browsere in momentul de față, având o cotă de piață de aproximativ 50% din totalul utilizatorilor de internet. Numele navigatorului este provenit de la interfața sa grafică. Chromium este numele proiectului de open source, iar Chrome este numele versiunii care a aparut pe piata sub licența BSD. Prima versiune pentru sistemele de operare Microsoft Windows a apărut pe data de 2 septembrie 2008 în 43 de limbi. Lansarea navigatorului Google Chrome a fost planificată pe data de 3 septembrie 2008, iar câteva articole ce-l aveau ca autor pe Scott McCloud urmau să fie transmise către jurnaliști și bloggeri, explicând functionalitațile și motivațiile lansarii noului navigator de internet. Google Chrome funcționează pe sistemele de operare windows XP , Vista, Windows 7 si Windows 8 – Mac și Linux. Este de asemenea compatibil cu device-uri mobile: Android și iPhone. Pentru a putea folosi Google Chrome este nevoie de minim: un procesor Pentium de de 1 GHz, memorie de 512 Mb RAM, iar spațiul liber pe disc sa fie de 500 MB, dar se recomandă: un processor de 3 GHz Pentium, memorie: 2 Gb RAM si pațiu liber pe disc: 5 GB.
2.2.3 Mozilla Firefox
Descriere:
Mozilla Firefox este un browser web gratuit realizat de Mozilla Foundation. Mozilla Firefox este folosit de aproximativ 50% din toți utilizatorii Internetului din lume. Mozlla Firefox are numeroase caracteristici, cum ar fi tabbed browsing, un sistem bine pus la punct pentru securitate, o caracteristică de gestionare a descărcărilor. Este configurabil și se pot adăuga multe add-on-uri făcute de diverși utilizatori; gruparea de add-onn-uri este deja foarte complexă, fiind disponibile peste 8.000 de extensii.
2.2.4 Safari
Descriere:
Nu este flexibil in configurare ceea ce pierde foarte mult in fața celorlalți competitori
Safari are o interfață simplă și elegantă. Printre funcțiile cele mai populare se numară: funcționalitate rapidă, memorări usoare, blocaje pop-up, SnapBack, RSS încorporat, ajustarea textelor, browsing anonym și siguranța.
2.2.5 Opera
Descriere:
Opera oferă multe funcții care să ajunte atunci când se navighează pe internet. Printre cele mai populare se numară: Opera Turbo aceasta grăbește conexiunile lente. Opera Link poate sincroniza memorarea paginilor cu alte computere si telefoane mobile. Opera Unite ajută la șeruirea de fișiere, poze si muzică din calculatorul personal.
Opera este conceput ca un program MDI (Multiple Document Interface). Asta înseamnă că pentru fiecare pagina care se vrea vizualizată în paralel trebuie să se deschidă un nou document în interiorul aceleiași instanțe de Opera. Asta duce în primul rând la o utilizare mult mai eficientă a resurselor sistemului (mai ales al memoriei RAM). De exemplu, programul Paint din Windows este SDI (Single Document Interface), pe cand Word –ul este MDI. Pe scurt asta înseamnă că poți avea mai multe ferestre în interiorul uneia singure, principale. Un alt avantaj evident este viteza mult mai mare cu care se încarcă în memorie (pornește).
2.3 Testarea software
Asigurarea calității unui program este un întreg proces care surprinde programul în toate fazele dezvoltării lui, pentru menținerea activității de dezvoltare mereu în concordanță cu specificațiile tehnice și cu limitele de timp si de cost prestabilite, în acest proces intră, desigur, și activitatea de testare.
2.3.1 Introducere
Conform literaturii de specialitate, testarea este procesul prin care se execută un program cu scopul de a găsi erori.
Este considerată o eroare a unui program soft nefuncționarea corespunzător specificațiilor. Desigur, primul gând ne duce către programator deoarece el este cel care scrie programul , însă aceasta este doar o mică parte a problemei. Priviind imaginea de ansamblu a ceea ce înseamnă software, constatăm că până a ajunge la partea de programare, trebuie parcurși mulți alți pași în care se pot strecura diferite greșeli, dar desigur si în timpul procesului de programare apar unii factori:
definirea greșită de către client a cerințelor programului. Aceasta este una din cele mai frecvente cause ale erorilor deoarece clientul poate din neatenție, dar și neavând pregătirea necesară să omită unele aspecte importante, sau să specifice incomplet o anumită cerință.
scăpări sau neînțelegeri în comunicarea client – developer, unde prin developer se poate înțelege project – manager, programator, cel care proiectează softul sau chiar tester. Aceste erori de comunicare pot provoca erori ale softului care e posibil să nu fie descoperite decât după livrarea produsului. În general se poate întampla ca specificațiile să fie făcute gresit deoarece clientul nu a știut sa exprime suficient de clar cee ace vrea , sau pentru ca developerul a înțeles greșit ce vroia să spună clientul.
modificări ale specificațiilor care apar pe parcursul dezvoltării
erori logice de proiectare
slaba documentare a muncii efectuate de un programator. Acest lucru poate genera erori atunci când o persoană nouă este introdusă în echipă și practice nu va putea înțelege exact funcționalitățiile deja implementate, sau după predarea la client , când documentația de tip manual de utilizare nu este scrisă corespunzător.
2.3.2 Principiile testării
Figura .1 Șapte Principii ale testării [19]
Testarea evidențiază prezența defectelor. Testarea poate evidenția prezența defectelor, dar nu poate dovedi lipsa acestora. Această abordare reduce probabilitatea de a rămâne defecte în aplicații, cu toate că lipsa acestora nu susține corectitudinea produsului.
Testarea exhaustivă nu este posibilă. A testa toate combinațiile în toate scenariile existente nu este fezabil în majoritatea cazurilor. Pentru a acoperi aceasta realitată, analiza riscului și prioritizarea trebuie folosite pentru orientarea testelor relevante
Testarea timpurie sau din fazele incipiente. Pentru a identifica defectele din etapele incipiente, activitatea de testare trebuie realizată cât de repede cu putință pe parcursul ciclului de dezvoltare a unei aplicații și să fie orientată asupra obiectivelor definite.
Testarea clusterelor de defecte. Efortul de testare trebuie focusat proporțional în funcție de densitatea defectelor din module. In general o parte mica de module conține majoritatea defectelor descoperite înainte de producție sau este responsabilă de cele mai multe probleme ulterioare..
Paradoxul pesticidelor. Daca un test este executat în repetate rânduri în cele din urma nu va mai identifica defecte. Pentru a preintâmpina “paradoxul pesticidelor”, aplicarea unui pesticid asupra unui bug poate în mod surprinzător rezultă la dezvoltarea acestuia prin dobândirea unei rezistente la acest factor de atac – testele ar trebui revizuite și îmbunatatițe periodic prin adăgarea de noi elemente pentru a lărgi aria de testare cu scopul de a identifica noi potentiale defecte.
Testarea este dependenta contextual. Testarea se realizează diferit în funcție de mediu, context. Spre exemplu, o aplicație de tranzacții bancare este testată în mod diferit față de o aplicație precum un magazin virtual.
Absenta erorilor. Identificarea și fixarea defectelor nu ajută foarte mult dacă sistemul este inutilizabil si nu răspunde cerințelor si nevoilor utilizatorilor. [5]
2.3.3 Procesul de testare fundamental: Procesul de testare constă din 5 etape:
Planificare și control
Analiza și design
Implementare și execuție
Evaluarea rezultatelor și raportarea.
Finalizarea procesului de testare
Figura 2.2 Etape in procesul de testare
1. Planificare și control
Planificarea determină ceea ce urmează a fi testat si modul în care acest lucru se va realiza. cum se vor face activitătile și cine le va face. Planificarea este, de asemenea, situația în care se definesc criteriile de finalizare ale testarii. Controlul este ceea ce facem atunci când activitățile nu se potrivesc cu planurile.
Principalele activități de planificare de testare sunt:
Definirea scopului și obiectivele de testare și identificarea riscurilor
Determinarea abordarilor de testare
Detalii cu privire la ce este necesar pentru a face testarea
Implementarea politicii de testare și a strategiei de test
Programarea analizei și proiectarea sarcinilor de testare
Detalii cu privirea la finalizarea testarii, criteriile de ieșire
Principalele activități de control sunt:
Măsurarea și analiza rezultatelor
Compararea progresului, acoperirea testarii și criterii de finalizare a testarii
Efectuarea de corecții dacă lucrurile nu merg bine si deciderea acțiunilor.
2. Analiza și design
Analiza si design-ul se ocupă cu detaliile de ceea ce urmează a se testa (condițiile de testare) și cum să se combine condițiile de testare în cazurile de testare, astfel încât un număr mic de cazuri de testare pot acoperi cât mai multe dintre condițiile de testare posibile. Principalele puncte ale acestei activități sunt:
Revizuirea specificatiilor, arhitecturii, design-ului, interfețelor și a altor părți care cuprind în mod colectiv baza de testare.
Analiza elementelor de testare, specificatiilor, comportamentul și structura pentru a identifica condițiile de testare și datele de testare necesare.
Proiectarea testelor si determinarea testabilitatii cerințelor.
Detalierea despre cum ar trebuie să fie mediul de testare si dacă există orice infrastructură și instrumente necesare.
3. Implementare și execuție:
Implementarea și execuția implică rularea testelor, iar acest lucru va include și setarea mediului de lucru pentru testare. Punerea în aplicare și executia constau din urmatoarele activitati:
Dezvoltarea și prioritizarea cazurilor de testare, crearea de date de testare, proceduri de testare și opțional, pregătirea scripturilor automate de testare.
Colectarea cazurilor de testare, unde testele pot fi rulate unul după altul pentru eficiență.
Verificarea mediului de test că a fost setat corect.
Rularea cazurilor de testare în ordinea determinată. Acest lucru poate fi manual sau cu ajutorul instrumentelor de execuție de test.
Menținerea unui jurnal de activități de testare, inclusiv rezultatul (admis / respins) și versiunile de software, date, unelte și testware (script-uri, etc).
Compararea rezultatelor actuale cu rezultatele așteptate.
Raportarea discrepanțelor ca incidente
4. Evaluarea criteriilor de ieșire
Evaluarea crtiteriilor de ieșire constă in:
Verificarea indeplinirii criteriilor de iesire stabilite anterior
Determinarea necesitătii unor teste adiționale
Determinarea criteriilor de ieșire specificate
Redactarea rezultatul activităților de testare
5. Finalizarea procesului de testare
Testarea se incheie în această etapă. Activitățile de finalizare se concentreaza pe siguranta că totul este pus in ordine, rapoartele sunt scrise, defectele sunt închise.
2.3.4 Metode de testare
Ca și metode de testare, se identifică două categorii mari:
Testarea funcțională – este de asemenea cunoscută ca și testarea după specificații, sau în termeni specifici, black-box testing.
Testarea structurală – sau testarea codului propriu-zis, care ăn termineni specifici se numește și white-box testing.
În multe cazuri pot fi aplicate ambele metode, chiar dacă pentru unele cerințe de asigurare a calității softului, numai una din ele este potrivită. Totuși, în majoritatea cazurilor, se practică doar testarea funcțională din motive financiare.
2.3.4.1 Metoda black-box
Metoda black-box presupune privirea programului ca pe o cutie neagră, căreia nu îi cunoaștem structura internă și modul de funcționare. În schimb, preocuparea principală se îndreaptă spre introducerea unor date de test și verificarea dacă rezultatele produse de acestea sunt sau nu cele așteptate. Această abordare face ca datele de test să fie generate exclusiv din specificații.
Figura 2.3 Testarea black box
Deși testarea exhaustivă ar fi ideală, ea nu poate fi realizată. De aceea, pentru a îmbunătății eficiența testării funcționale se folosesc clase de echivalență ale datelor de test. Acest lucru presupune împărțirea întregului domeniu de date în seturide valori care duc la același rezultat, sau care sunt procesate asemănător. [7]
Clasele de echivalență care conțin doar date de intrare ce fac precondiția adevarată, se numesc clase de echivalență valide.
Clasele de echivalență care conțin doar date de intrare ce fac precondiția falsă, , se numesc clase de echivalență invalide.
Marginile claselor de echivalență sunt definite de o valoare, sau un grup de valori aflate la un capăt și la celălalt al intervalului pe care este definită clasa.
Aplicarea metodei black-box se poate eficientiza prin crearea cel puțin al unui caz de test pentru fiecare din clasele de echivalență identificate și câte un caz de test pentru marginile fiecărei clase de echivalență. Comparativ cu folosirea unor date de test generate aleator, clasele de echivalență reduc din timpul acordat testării deoarece se elimină posibile date de test duplicate.
2.3.4.2 Metoda white-box
Metoda white-box permite examinarea structurii interne a programului. Cu alte cuvinte, având codul la dizpoziție, se generează cazuri de test care să ducă la execuția unei părți cât mai mari din program, iar pentru a ușura oarecum această sarcină se creează ceea ce se numește schemă logică a programului. Testarea exhaustivă ar însemna, pentru această metodă, parcurgerea tuturor drumurilor posibile de la început până la sfârșitul schemei logice, dar acest proces ar fi mult prea costisitor si complex, De asemenea, și stabilirea unor cazuri de test cât mai cuprinzătoare este un factor important pentru o testare eficientă, însă eficiența trebuie să vină și din timpul alocat testării, iar aceste lucruri vor reduce metoda white-box la alegerea unei submulțimi de date de test care au șanse maxime de a depista erori și executarea cel puțin o data a fiecărei instrucțiuni din program.
2.3.4.3 Metoda Black-box versus white-box
Fiecare dintre aceste metode are propriile avantaje și dezavantaje relativ la criteriul după care alegem să le comparăm, însă niciodată nu vom putea decide că o metodă e mai avantajoasă față de cealaltă discutând un singur crieteriu.
Efortul construirii cazurilor de test este mai mic în cazul metodei black-box, acestea fiind extrase doar din specificațiile aplicațiilor. Comparativ, pentru metoda white-box, este necesară parcurgerea unei părți cât mai mare din codul sursă și analiza acestuia, ceea ce implică timp și concentrare la nivele mai ridicate.
Metoda black-box permite simularea mai apropiată de utilizarea reală a produsului prin nivele precum testare de sistem sau timp de raspuns, în contrast cu metoda white-box.
Folosind metoda white-box se poate ști îm orice moment în ce măsură testele au parcurs sau nu tot codul sursă existent. Gradul de acoperire nu poate fi ușor calculat în cazul metodei black-box, fapt pentru care uneori există șansa ca nu toate situațiile posibile să fi fost testate și ca unele erori sa rămână nedescoperite până în momentul testării de acceptare.
Metoda white-box permite evaluarea calității codului și respectarea anumitor standarde în procesul de dezvoltare, eventual îmbunătățirea acestora în cazul în care se consideră necesar, lucru pe care metoda black-box nu îl permite.
Prin caracteristicile pe care le prezintă, putem spune ca metoda white-box oferă un avantaj în cazul modulelor de o importanță majoră, pentru care costurile unei erori ar fi foarte ridicate, situație în care este foarte important ca erorile să fie eliminate. Din punct de vedere al costurilor de timp, financiare și umane implicate, am putea trage concluzia că metoda black-box ar fi alegerea potrivită. Dar cum calitatea și rapiditatea sunt două cerințe pe care clienții le cer în mod constant, și cum fiecare aplicație conține anumite părți care pot fi considerate critice, nu se poate identifica una dintre metode ca fiind ideală la modul general. Ar fi recomandat ca ambele să fie aplicate în cadrul aceluiași proiect, pentru ca una să consolideze aplicația acolo unde cealaltă nu este pe deplin capabilă.
2.3.5 Nivele ale testării
Testarea poate fi efectuată la diferite nivele, incluzând întregul system sau părți din acesta, pe parcursul a diferite momente din ciclul de viață al produsului software. Un system software trece prin patru nivele de testare înainte ca produsul sa fie considerat finit. Acestea sunt: testarea unui modul (sau unit testing), testarea de integrare, testarea de sitem și testarea de acceptare.
Primele trei nivele de testare sunt efectuate de cei direct implicați în procesul de dezvoltare a aplicației , cum ar fi programatori sau testeri, în timp ce testarea de acceptare este efctuată de către clienți.
Figura 2.5 Nivele ale testării
2.3.5.1 Testarea unitară
Testarea celor mai mici unități testabile (clase, metode, pagini web) independent una de alta.
Figura 2.6 Testare unitară
Se găsesc defecte în modul și se verifică funcționalitatea software-ului. Testarea componentelor se poate face independent de restul sistemului în funcție de modelul ciclului de viață de dezvoltare ales pentru acea aplicație particulară. Testarea componentelor poate include teste de funcționalitate și caracteristici non-functionale specifice, sau teste de robustețe, precum și testarea structurală (de exemplu, acoperirea deciziilor). Cazurile de test sunt derivate din produsele de muncă, cum ar fi specificația unei componente, design-ul software sau modelul de date.
Testarea unitară s-a impus în ultima perioadă în dezvoltarea proiectelor scrise în limbajul Java și nu numai, pe măsura apariției unor utilitare gratuite de testare a claselor, care au contribuit la creșterea vitezei de programare și la micșorarea drastică a numărului de bug-uri. Testare unitară poate cuprinde testarea caracteristicilor funcționale și nonfuncționale, ca și comportamentul resurselor (de exemplu căutarea lipsei de memorie) sau testarea robusteții, dar și testarea structurală. Cazurile de testare provin din specificațiile componentei, design-ul software sau modelul de date. De obicei, testarea unitară are loc cu accesul la codul care trebuie testat și cu suportul unui mediu de dezvoltare, cum ar fi un framework de testare unitară sau un tool de debugging. În practică, testarea unitară implică programatorul care a scris codul. În mod normal defectele sunt fixate în momentul în care sunt descoperite, fără formalizarea procedeului de administrare. O abordare a testării unitare este cea în care se pregătesc și se automatizează cazurile de test înainte de codare. Această abordare se numește TDD (Test Driven Development). Ea este iterativă și se bazează pe ciclii de dezvoltare a cazurilor de test, apoi construirea și integrarea bucăților de cod, și executarea testelor unitare, corectând orice problemă și incrementându-se până când trec. [7]
2.3.5.2 Testarea de integrare
Evaluarea interacțiunii între unitățile testate distinct și separat după ce au fost integrate.
Figura 2.7 Testarea de integrare
Testarea de integrare ar trebui să fie diferențiată de alte activități de integrare. Testarea de integrare este de multe ori efectuată de integrator, dar de preferință se face de către echipa de testare. Ar putea fi mai mult de un nivel de testare de integrare. În acest nivel are loc interfațarea dintre componente, interacțiunile cu diferite părți ale sistemului cum ar fi sistemele de operare, fișierele. Pot exista mai multe nivele ale testării de integrare:
a. Testarea integrării componentelor care testează interacțiunea dintre componentele software și are loc imediat după testarea unitară.
b. Testarea integrării sistemului care testează interacțiunea dintre diferite sisteme sau dintre hardware și software, și poate fi făcută după testarea sistemului. În acest caz, organizația de dezvoltare poate controla doar o parte a interfeței. Acesta poate fi considerat un risc. Procesele business implementate ca și workflow-uri pot implica multe sisteme . Testarea pe mai multe platforme poate fi foarte semnificativă. Testarea de integrare are ca obiectiv testarea pe diverse niveluri de integrare a modulelor. Se pune accentul pe funcționarea corectă a ansamblului, pe compatibilitatea dintre componente, de asemenea se pune accent pe depistarea erorilor de interfață între module, păstrarea integrității semantice a structurilor de date externe, eliminarea conflictelor privind accesul la resursele de calcul. Este indicat ca testele să fie desfășurate într-un mediu cât mai apropiat de cel în care sistemul va funcționa ulterior.
Testarea părților combinate ale unei aplicații pentru a stabili dacă ele funcționează corect împreună, este testarea de integrare. Există două metode de a face testarea de integrare: de jos în sus si de sus în jos. Bottom-up testing se face de obicei prima, urmată de top-down testing. Bottom-up testing va incepe cu unit testing, urmata de teste ale combinațiilor de nivel superior ale unităților numite module sau build-uri. In cadrul testării top-down integration, modulele de nivel mai înalt sunt testate mai întâi și progresiv urmeaza cele de nivel inferior .
2.3.5.3 Testarea sistemului
Testarea sistemului de software sau hardware este testarea efectuată pe un sistem complet, integrat pentru a evalua respectarea sistemului cu cerințele sale specific, ca atare, ar trebui să nu necesite cunoștințe de proiectare interioară a codului sau cunoștințe de logica. De regulă, testarea sistemului ia, in intrari, toate componentele "integrate" de software care au trecut testarea de integrare. Odată ce toate componentele sunt integrate, aplicația ca un întreg este testată riguros pentru a vedea că acesta îndeplinește standardele de calitate. Acest tip de testare este efectuată de către o echipă de testare de specialitate.
Figura 2.8 Testarea sistemului
2.3.5.4 Testarea de acceptare
Evaluează sistemul în cooperare cu clientul sau sub patronajul acestuia într-un mediu apropiat mediului de producție. După ce testarea de sistem a corectat toate sau cele mai multe defecte, sistemul va fi livrat utilizatorului sau clientului pentru testele de acceptare. Testele de acceptare, în principiu se fac de către utilizator sau client. Scopul testelor de acceptare este de a stabili încrederea în sistem. Testele de acceptare sunt cel mai adesea axate pe o testare de tip validare. Aceasta este, fără îndoială, cel mai important tip de testare, deoarece este realizată de echipa de asigurare a calității, care va decide dacă aplicatia îndeplinește specificațiile destinate și care satisface cerințele clientului.
Echipa de asigurare a calității va avea un set de scenarii de prescrise și TC (test cases) vor fi utilizate pentru a testa aplicația. Testele de acceptare nu sunt destinate numai pentru a sublinia greșelile de ortografie simple, erori minore sau lacune de interfață, dar, de asemenea, să sublinieze orice bug-uri în aplicare care vor rezulta în crash de sistem sau erori majore. Prin efectuarea testelor de acceptare a unei aplicatii, echipa de testare va deduce modul în care aplicația va actiona în producție. Există, de asemenea, cerințele legale și contractuale de acceptare a sistemului.
2.3.6 Alte tipuri de testare
2.3.6.1 Testarea de Performanță
Testarea de performanță este "procesul de testare prin care se determină performanța unui produs". Cu alte cuvinte scopul nostru este de a afla cât de bun este un produs software, cât de rapid, câți useri poate să susțină precum și timpul de răspuns pentru fiecare dintre ei, sau care sunt limitele produsului. Rezultatele obținute în urma testelor de performanță vor ajuta factorii de decizie din Business să ia o decizie informată cu privire la lansarea unui produs. Testarea de performanță va oferi informații despre cum se va comporta produsul în utilizarea zilnică, cu acces concurent din partea utilizatorilor. Rezultatele vor folosi în estimarea resurselor hardware necesare pentru a susține un anumit număr de utilizatori.
Există câteva categorii de Teste de Performanță, fiecare având particularități în ceea ce privește scopul, planificarea și execuția:
Load – al cărui scop este de a vedea comportamentul sistemului când un anumit număr de utilizatori îl folosește simultan
Stress – al cărui scop este de a determina limitele și robustețea sistemului
Soak – al cărui scop este de a determina comportamentul sistemului pe o perioadă mai mare timp în care un anumit număr de utilizatori îl folosește. [8]
2.3.6.2 Testarea regresivă
Testarea regresivă (black & white box) reprezintă procesul de re-testare dupa remedieri sau modificări ale produsului sau ale mediului său. Acest tip de testare implică verificarea ca odată cu avansarea în proiect să nu se piardă funcționalități deja implementate, sau să se genereze erori noi. Cea mai simplă și eficientă metodă de regression testing este să se păstreze toate testele într-un batch care să se ruleze periodic, astfel orice bug nou va fi remarcat imediat și poate fi remediat. Desigur, asta implică ca testele respective să poată fi rulate automat. [3]
2.3.6.3 Testarea beta
Testarea beta (black box) permite utilizatorilor să lucreze cu versiunile timpurii ale unui produs cu scopul de a oferi feedback-uri din timp. Testare Beta este ultima etapă de testare, și în mod normal poate implica expedierea produsului pe site-ul de testare beta in afara companiei pentru expunerea la lumea reala. Testarea Beta este adesea precedata de testarea alfa. Testarea beta poate fi considerată : "pre-release testing."[9]
2.3.6.4 Testarea alpha
Testarea Alpha este una dintre cele mai comune strategii de testare software folosita în dezvoltarea de produse software. Modificări de proiectare minore pot fi făcute încă ca urmare a testelor alpha. Testarea Alpha este de obicei realizată de un grup care este independent de echipa de design, dar încă în cadrul companiei, de exemplu ingineri in-house de testare software, sau ingineri software QA. [10]
2.3.6.5 Testarea de confirmare
După ce un defect a fost descoperit și fixat, este nevoie de o retestare de confimare a acestuia, pentru a ne asigura ca întradevar a fost indepărtat.
2.3.6.6 Testarea compatibilităților
Când vorbim de compatibilitate ne gândim la aspect precum:
Compatibilitatea cu diferitele browsere
Browserele au configurări și setări diferite. De asemenea stilurile CSS, precum și scripturile javascript și call-urile AJAX pot fi interpretate diferit de fiecare browser. Asta făcând să trebuiască testat intensiv comportamentul aplicației web pe fiecare browser pentru a ne asigura o gama cât mai larga de utilizatori.
Compatibilitatea cu sistemele de operare
Trebuie testat comportamentul aplicației web pe diferite sisteme de operare precum Windows, Unix, Solaris, Linux. Tehnologiile utilizate în dezvoltarea aplicațiilor web, precum design-ul graphic, diferitele API-uri, pot să nu fie disponibile pe toate sistemele de operare.
Compatibilitate cu diferitele platform mobile
Pe lângă browserele pentru desktop, trebuie să ne asigurăm constant ca aplicația web funcționează corespunzător pe diferitele browsere mobile. Pentru asta ne putem folosi de add-ons cu user agents de mobile încorporate în browserele desktop, fără a fi efectiv nevoie să avem telefoanele mobile pentru testare.
2.3.6.7 Testarea securității
Este foarte importantă testarea securității aplicației web, Atât pentru a ne proteja de atacuri și operații periculoase pentru aplicație, dar și pentru a proteja utilizatorul nostru.
Câteva exemple de astfel de teste sunt:
Testarea CAPTCHA-ul importriva scripturilor automate de login
Testarea cu URL-uri interne directe în browser, fără ca utilizatorul să fie logat
Testarea utilizării SSL ca măsură de securitate.
Directoarele web sau fișierele nu trebuie să poată fi utilizate direct decât ca opțiune de download.
Când este vorba de testare cea mai des întalnită problema într-o companie este dacă să se automatizeze sau sa se testeze manual. Nu toate testele pot fi automatizate si de cele mai multe ori poate fi dificil de decis ce să se automatizeze si ce sa se testeze manual.
2.3.6.8 Testarea performanțelor
O aplicație web trebuie să facă fata unui load mare de cereri de la utilizatori. Pentru aceasta testarea performanțelor este obligatorie, mai ales în cazul aplicațiilor web ce se conectează la baza de date și realizează operații de scriere pe acestea. Trebuie testat și comportamentul aplicației web cu diferite viteze de conectare la internet.
Testarea performanțelor web ar trebui să includă testarea load-ului (cantității) și testatea stresului.
Pentru testarea load-ului, trebuie să verificăm felul în care se comportă aplicația web dacă mai multi utilizatori accesează și fac requesturi pe aceleași pagini. Load-ul maxim trebuie stabilit în funcție de momentul din zi la care aplicația este cel mai mult accesată.
Testarea stresului făcând de obicei fortarea sistemului peste limitele sale. Practic trebuie observat cum reacționează aplicația în situații excepțională, dacă se blochează sau returnează erori grave.
2.4 Testarea Manuală
Avantaje:
Dacă Test Cases-urile trebuiesc rulate de un numar mic de ori e mult mai probabil să se prefere testarea manuală.
Permite tester-ului să facă mai multe teste ad-hoc
Costurile pe termen scurt sunt reduse
Cu cât un tester petrece mai mult timp verificând un modul cu atât cresc șansele de a găsi mai multe defecte si posibile greșeli de utilizare
Dezavantaje:
Testele manuale pot fi mari consumatoare de timp
Pentru fiecare release trebuiesc rulate aceleași seturi de teste ceea ce poate deveni monoton. [11]
2.5 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 demai multe ori, pe mai multe platforme software și hardware, ca și după schimbările ulterioare sau lansarea unei noi versiuni de produs. Prin folosirea testării automate, costurile testărilor repetate se reduc aproape la zero.
Testarea automată înseamnă mai mult decât o simplă captură de ecran și răspunsul la câteva scripturi : ea trebuie să înceapă cu planificarea și design-ul procedurii de testare, să conțină o serie de teste repetabile, o interfață de management al scenariilor de test și un mecanism de raportare și gestionare a bug-urilor descoperite în urma testării. Un sistem de test evoluat sprijină utilizatorii printr-un sistem de documentare pe tot parcursul acestui proces. Într-o abordare mai detaliată testarea automată înseamnă:
Planificare:
identificarea cerințelor și a funcționalităților
gruparea acestora în condiții de test
crearea cazurilor de test pentru aceste condiții
Design:
construcția scripturilor de test
generarea testelor de rulare
Execuție:
crearea scenariului de rulare a scripturilor
rularea uneltelor monitor pentru înregistrarea datelor
înregistrarea rezultatelor pentru fiecare rulare
raportarea și gestionarea bug-urilor management
generarea rapoartelor și graficelor
controlul dintr-un singur punct de comandă
2.5.1 Tipuri de testare automată
structurală – se verifică structura software-ului și necesită acces complet la codul sursă. Acest tip de testare verifică dacă structura codului este eficientă: bucle complicate, zone de date comune, mii de linii de cod încurcate sunt numai câteva din problemele care pot fi îndepărtate. Scopul acestui test este mărirea performanței aplicației și a lizibilității codului.
funcțională – se definesc așteptările clientului de la aplicație și se verifică automat dacă software-ul se comportă conform acestor așteptări. Prin testele ce se execută se observă comportamentul aplicației, evidențiat prin datele de ieșire, fără a se face referire la funcțiile interne.
regresivă – se verifică dacă s-a modificat neașteptat comportamentul aplicației în urma implementării unor noi cerințe sau schimbări
de stres- se determină capabilitățile absolute ale aplicației și ale infrastructurii pe care este implementată; cu ajutorul acestui tip de test se dezvăluie caracteristicile de performanță ale unui sistem menținut în condiții de încărcare totale, adică sunt pornite și rulate toate serviciile care în mod normal ar fi fost rulate separat în timp și independent.
de performanță – în urma acestui tip de testare se verifică dacă performanța aplicației este adecvată pentru cerințele stabilite, în termeni de viteză de acces, resurse de sistem utilizate și procesarea cererilor de acces.
de încărcare- se determină punctele slabe ale aplicației și dacă sunt necesare îmbunătățiri ale infrastructurii hardware sau software prin măsurarea caracteristicilor de performanță și scalabilitate a principalelor componente ale aplicației web; de regulă aceasta se realizează prin creșterea numărului de sesiuni utilizator sau a conexiunilor TCP/IP.
Avantaje:
Dacă trebuiesc repetate aceleași teste de multe ori automatizarea prezintă un mare avantaj
Permite executarea scenariilor de testare ajutând la testele de regresie
Ajută la executarea de teste de compatibilitate a programelor pe mai multe configurații
Costurile pe termen lung sunt reduse
Pot fi rulate simultan pe mai multe mașini astfel scăzând timpul de testare
prevenirea erorilor prin abordarea structurată a procesului de dezvoltare a proiectului
detecția erorilor care au ajuns până în faza de producție (prin teste de regresie automată)
reducerea creării de noi scripturi (refolosindu-le și adaptându-le pe cele vechi)
execuția automată a testelor de performanță în fazele de început ale proiectului poate evita eforturile de redesign în fazele ulterioare
odată ce scripturile de testare automată sunt implementate, o parte din personal poate fi redirecționat către alte necesități
analiză rapidă și exactă în cazul schimbării parametrilor sistemului
durată scurtă a ciclurilor de testare
estimări mai exacte pentru procesul de planificare a testului
posibilitatea efectuării mai multor teste
mai bună înțelegere a scopului testării
rezultate mai consistente datorită repetabilității testelor
Dezavantaje:
Nu se poate automatiza totul, anumite teste trebuie făcute manual
E mult mai scump sa automatizezi, investițiile inițiale sunt mai mari decât în cazul testării manuale. [11]
2.5.2 Tool-uri pentru testarea automată
Automatizarea de testare înseamnă folosirea a unui instrument software pentru a rula testele în mod repetat împotriva cererii pentru a fi testate. Rularea testelor automate ajută foare mult la testarea de regresie, mod prin care se face maintenance la întreaga aplicație software. Există multe avantaje pentru automatizarea testelor. Cele mai multe sunt legate de repetabilitatea testelor și viteza cu care testele pot fi executate. Există o serie de instrumente comerciale și open source disponibile pentru asistarea și dezvoltarea de automatizare a testării. Seleniul este soluția posibilă open source mai utilizată pe scară largă. Acest ghid va ajuta si utilizatorii noi și cu experiență de selenium în procesul de învățare tehnici eficiente în construirea de automatizare de testare pentru aplicatii web.
Nu este întotdeauna avantajos pentru a automatiza cazuri de testare. Există situații în care testarea manual poate fi mai adecvată. De exemplu, dacă interfața cu utilizatorul a aplicației se va schimba considerabil in viitorul apropiat, atunci orice automatizare ar putea avea nevoie să fie rescrisa aproape in totalitate. De asemenea, uneori, pur și simplu nu este suficient timp pentru a crea teste automate. Pe termen scurt, testarea manuală poate fi mai eficientă. Unul dintre cele mai utilizate tool-uri pentru testarea automată este Selenium.
Selenium este un set de diferite tool-uri de software, fiecare cu o abordare diferită pentru sprijinirea de automatizare a testelor. Cei mai multi QA Engineers se concentrează pe unu sau două tool-uri care răspund nevoilor proiectelor lor, cu toate acestea este bine să se cunoască toate tool-urile care le va oferi mai multe opțiuni diferite pentru abordarea problemelor diferite de automatizare de testare.
2.5.2.1 Istoria
Selenium a apărut prima oară pe piață în anul 2004, când Jason Huggins a realizat testarea unei aplicații interne la ThoughtWorks. Fiind un tip inteligent, el si-a dat seama că ar fi mai bine daca ar avea un tool pentru a testa automat aceleași scenarii care erau executate în mod repetitiv de el manual. Ca urmare a dezvoltat o bibliotecă Javascript, care sa conducă interacțiunile cu paginile, permițându-i să ruleze în mod automat testele împotriva mai multe browsere. Care în cele din urmă a devenit biblioteca Selenium Core, care stă la baza tuturor funcționalităților ale Selenium Remote Control (RC) si seleniu IDE.
În 2006, un inginer curajos la Google, numit Simon Stewart a început să lucreze la un proiect numit WebDriver. Google a fost mult timp un utilizator greu de selenium. Simon a dorit un instrument de testare care să interactioneze direct cu browser-ul folosind metoda "nativa" pentru sistemul de operare și browser-ul, evitând astfel restricțiile de mediu Javascript sandboxed.
2.5.2.2 Suita Selenium
Seleniu suportă o gamă largă de browsere, tehnologii și platforme.
Figura 2.9 Gama de browsere, tehnologii
Selenium nu este doar un tool unic sau un utilitar, ci un pachet de mai multe tool-uri de testare și pentru același motiv, el este ca o suită. Fiecare dintre aceste tool-uri este proiectat pentru a satisface diverse cerințe de testare și de mediu de testare.
Selenium este compus din mai multe tool-uri software. Fiecare dintre acestea având un rol specific.
Selenium RC și WebDriver, într-o combinație sunt cunoscute popular ca Selenium 2. RC singur este, de asemenea, menționat ca selenium 1.
Figura 2.10 Pachetele Selenium 1
Selenium IDE se instalează ca și add-on al Firefox-ului și permite înregistrarea și rularea de teste aferente paginilor web.
Caracteristici principale:
Interfață ușor de utilizat
Înregistrarea automată a pașilor urmați de către utilizator
Selectarea câmpurilor unei pagini web pe baza id-ului sau numelui
Posibilitate de depanare și adăugare de breakpoint-uri
Salvarea testelor ca și HTML, PHP, C#,…
Adăugarea de scripturi în „seleneză” sau alte limbaje cunoscute
Cele mai folosite comenzi în Selenium IDE sunt:
open deschide o pagină folosind un URL
click/clickAndWait execută o acțiune de apăsare și opțional, așteaptă încărcarea unei noi pagini verifyTitle/assertTitle verifică titlul unei pagini
verifyTextPresent verifică prezența unui text undeva în pagină
verifyElementPresent verifică prezența unui element al interfeței grafice în pagină, definit prin tag HTML verifyText verifică prezența unui text și a unui tag HTML în pagină
verifyTable verifică conținutul așteptat al unui tabel waitForPageToLoad amână execuția până când o pagină așteptată se încarcă. Este chemată automat când se folosește
clickAndWait waitForElementPresent amână execuția până când un element al interfeței grafice, definit prin tag HTML, este prezent în pagină. [12]
Selenium RC (Remote Control) Selenium RC este o completare a add-on-ului Selenium IDE, oferind posibilitatea automatizării testelor și rularea scripturilor aferente, în diferite limbaje de programare. [12]
Selenium WebDriver este un instrument pentru automatizarea testării aplicaților web, și, în special, pentru a verifica dacă acestea funcționează conform așteptărilor. Acesta oferă un API prietenos, care este ușor de înțeles, și este mai ușor de utilizat decât Seleniu-RC. [13]
2.5.2.3 Diferențe între Selenium IDE, Selenium RC, Selenium Web-driver
Figure 2.11 Diferențe suita Selenium[14]
2.5.3 Drivere Webdriver-lui
2.5.3.1 Firefox driver [16]
Controlează browser-ul Firefox folosind un plugin Firefox. Profilul Firefox care este utilizat este simplificat de la ceea ce este instalat pe mașină pentru a include numai Selenium WebDriver.xpi (plugin). Firefox driver este capabil de a fi rulat si este testat pe Windows, Mac, Linux. Unul dintre principalele avantaje ale driver-ului Firefox este acela că rulează ca un browser real și acceptă JavaScript. Se pare a fi al doilea driver din punct de vedere al vitezei (mai lent decât HTMLUnit dar mai rapid decât IEDriver).
Using Firefox driver
WebDriver driver = new FirefoxDriver();
Running with firebug
Trebuie descărcat fișierul Firebug xpi pentru Mozilla si se poate incepe profilul astfel:
File file = new File("firebug-1.8.1.xpi");
FirefoxProfile firefoxProfile = new FirefoxProfile();
firefoxProfile.addExtension(file);
firefoxProfile.setPreference("extensions.firebug.currentVersion", "1.8.1"); // Avoid startup screen
WebDriver driver = new FirefoxDriver(firefoxProfile);
2.5.3.2 IE driver [17]
Acest driver este controlat de un .dll și este, prin urmare, disponibil numai pe sistemul de operare Windows. Unul dintre principalele avantaje ale driver-ului Firefox este că rulează ca un browser real și acceptă JavaScript. Din păcate, acest driver prezintă un set de dezavantaje:
funcționează doar pe Windows
un pic mai lent
XPath nu este acceptat nativ în cele mai multe versiuni
CSS nu este acceptat nativ în versiunea 6 și 7
Using IE driver
WebDriver driver = new InternetExplorerDriver();
2.5.3.3 Chrome driver [18]
WebDriver lucrează cu Chrome prin binar chromedriver.
Principalele avantaje:
Execută într-un browser reală și acceptă JavaScript
Deoarece Chrome este un browser bazat pe Webkit, Driver-ul Chrome poate permite să se verifice dacă un anumit site funcționează în Safari. Deoarece Chrome foloseste propriul motor V8 JavaScript, mai degrabă decât motorul Nitro Safari, executarea JavaScript poate fi diferită.
Chrome driver usage
WebDriver driver = new ChromeDriver();
2.5.4 Comenzi și operații Selenium WebDriver API
Crearea unei instanțe de driver (în exemplu de mai jos Firefox)
WebDriver driver = new FirefoxDriver();
Deschiderea unei pagini
driver.get("http://www.google.com");
Localizarea elementelor web
Poate cel mai dificil aspect al creării testelor automate web, este identificarea elementelor de pe paginile web. Aceasta nu este de cele mai multe ori ușoară (mai ales dacă acestea nu sunt identificate prin id-uri sau clase), însă există numeroase metode de identificare și se poate alege cel mai potrivi în fiecare caz particular.
Localizarea după id
Acolo unde există, cel mai rapid și simplu mod de a localiza un element este după id-ul acestuia.
<div id="coolestWidgetEvah">…</div>
WebElement element = driver.findElement(By.id("coolestWidgetEvah"));
Localizarea după numele clasei
Acolo unde există doar clasă pentru elementul web, și avem siguranța că o să fie identificat unic prin intermediul ei (lucru puțin probabil), atunci se poate utiliza localizarea elementelor prin intermediul clasei.
<div class="cheese"><span>Cheddar</span></div><div class="cheese"><span>Gouda</span></div>
List<WebElement> cheeses = driver.findElements(By.className("cheese"));
Localizarea utilizând stilurile CSS
Cea mai rapidă metodă de identificare a elementelor web, este considerată în momentul de fața indentificarea acestora cu ajutor stilurilor CSS.
<div id="food"><span class="dairy">milk</span><span class="dairy aged">cheese</span></div>
WebElement cheese = driver.findElement(By.cssSelector("#food span.dairy.aged"));
Localizarea utilizând calea XPATH
De cele mai multe ori, acolo unde nici o altă metodă de indentificare a elementelor nu se poate utiliza, varianta XPATH vine în ajutor.
<input type="text" name="example" />
<INPUT type="text" name="other" />
List<WebElement> inputs = driver.findElements(By.xpath("//input"));
Inputul utilizatorului:
Completarea unei căsuțe text
driver.findElement(By.id("id_of_previous_input_field")).sendKeys(Keys.TAB,"This text will appear in textarea");
Alegerea unei opțiuni dintr-un select (dropdown box, combo box)
WebDriver driver = new FirefoxDriver();
WebElement identifier = driver.findElement(By.id("periodId"));
Select select = new Select(identifier);
select.selectByVisibleText("Last 52 Weeks");
Apăsarea unui buton
driver.findElement(By.xpath("//input[@value='Open access device' and @type='submit']")).click();
Navigarea între ferestrele browserului și între frame-uri
driver.switchTo().window("windowName");
driver.switchTo().frame("frameName");
2.5.5 Metode de validare
Cele mai utilizate metode de validare sunt:
assertEquals(boolean actual, Boolean expected, java.lang.String message)
Aceasta metode validează dacă doua variabile de tipul Boolean sunt egale. Pe lângă acest tip de variabile, se mai pot valida două variabile de tipul array, de tipul byte, două caractere, două colecții, două variabile de tipul double, de tipul float, două obiecte, două string-uri, două variabile de tipul map, două de tipul integer sau long.
assertEqualsNoOrder(java.lang.Object[] actual, java.lang.Object[] expected)
Această metodă validează ca două obiecte de tipul array conțin aceleași elemente, ignorând ordinea lor.
assertFalse(boolean condition, java.lang.String message)
Această metodă validează că ceea ce se trimite în primul parametru, ca și condiție, este fals.
assertNotEquals(java.lang.Object actual1, java.lang.Object actual2, java.lang.String message)
Această metodă validează că obiectele trimise ca și parametru nu sunt egale.
assertNotNull(java.lang.Object object, java.lang.String message)
Această metodă validează că obiectul trimis ca și parametru nu este null.
assertNull(java.lang.Object object)
Această metodă validează că obiectul trimis ca și parametru este Null.
assertTrue(boolean condition, java.lang.String message)
Această metodă validează că ceea ce se trimite în primul parametru, ca și condiție, este adevarat.
În toate metodele de mai sus parametrul “message” este opțional, însemnând că avem aceleași metode cu sau fără parametrul de tipul String.
2.5.5 Comparare cu alte tool-uri (Exemplu Ranorex)
Multe dintre companii se întreabă de ce ar trebui să plătească pentru un tool comercial în loc de a folosi unul gratuit? La prima vedere, ambele tool-uri se confruntă cu aceleași provocări când se fac teste automate pe o aplicație web, dar este foarte important să se înțeleagă alte aspecte atunci când se compară cele două instrumente. [20]
În momentul în care un tester nu are cunoștinte de programare, este foarte greu să instaleze și să configureze Selenium Web Driver, în schimb ce Ranorex este foarte ușor de instalat nefiind nevoie de cunoștințe tehnice. În momentul în care un tool trebuie ales este evident că, compania ia în considerare și partea financiară, ceea ce înseamnă că din acest punc de vedere Selenium are un mare avantaj față de Ranorex (Selenium este free). Pentru a crea teste automate folosind Selenium este nevoie de cunoștințe tehnice despre un anumit limbaj de programare: java, python, C, etc în timp ce cu Ranorex se poate lucra și fără a cunoaște un limbaj de programare (Ranorex se poate scrie doar cu C#). Tehnologiile suportate de Ranorex sunt: Desktop, Web și Mobile Applications, Selenium este limitat doar în a testa doar aplicațiile Web.
Din punct de vedere tehnic, ambele tool-uri utilizează o abordare similară pentru a identifica elementele de UI pe o pagină web. O expresie XPath este folosită de Selenium și Ranorex pentru a naviga printr-o pagină HTML. În cadrul Selenium xpath-ul poate fi folosit doar la nivelul codului, în timp ce pentru Ranorex xpath-ul poate fi folosit la nivelul codului, dar folosind Ranorex Spy tool, xpath-ul se poate edita fără a merge în cod.
Cu Seleniu nu este la fel de ușor să se ruleze testele ca și cu Ranorex, pentru Ranorex se generează un fișier executabil de unde se pot rula suite de teste sau dacă se dorește se poate rula doar un singur test.
Figura 2.12 Diferențe Selenium-Ranorex
2.5.6 Testare manuală vs testare automată
Problema tuturor companiilor de IT este aceea de a alege între testare manuală și testare automată dacă compania nu poate să acopere investițiile substanțiale pentru ambele tipuri de testare, costurile pentru testarea automată sunt mai mari dar asta nu înseamna că testarea manuală nu presupune și ea efort. În continuare se vor compara cele două tipuri de testare relativ la câteva criterii considerate importante în domeniul testării.
Acuratețe și completitudine
Testarea automată garantează că toate cazurile de test se vor executa complet și la fel de riguros de fiecare dată, spre deosebire de testarea manuală în cazul căreia factorul uman poate influența negativ execuția din cauza lipsei de concentrare sau a lipsei de implicare, ducând la scăderea nivelului de acuratețe sau la erori care scapă neobservate.
Documentarea erorilor
Dacă rezultatul pe care îl așteptăm este bine definit, instrumentele pentru testarea automată vor detecta de fiecare dată eventualele erori și în același timp vor genera automat rapoartele necesare cu rezultatele obținute. Aspectul documentării poate fi privit ca un dezavantaj în cazul testării manuale, deoarece se întâmplă adesea ca testerii să nu includă în rapoartele lor unele erori care li se pot părea nesemnificative, sau în cazul în care programatorul efectuează testarea, e posibil ca acesta să o depaneze pe loc fără să mai consemneze depistarea ei. Acest lucru poate determina probleme în cazul altor erori detectate ulterior, care ar putea avea legătură cu cea depanată și nedocumentată, însă neavând-o pe aceasta din urmă la îndemână. Depanarea primeia poate dura mult mai mult timp.
Necesitatea de resurse umane
Pentru executarea testării manuale este nevoie de resurse semnificativ mai ridicate de oameni, comparativ cu executarea testării automate. Totuși, pentru a pregăti instrumentele de testare automată e nevoie de mai mulți oameni față de pregătirea procedurilor manuale pentru același pachet soft.
Durata testării
Din punct de vedere al timpului, execuțiile automate au din nou un avantaj. Ele vor rula la viteza pe care o permite mașina, ceea ce este de foarte multe ori mai mare fată de capabilitățiile umane. Mai mult decât atât, execuțiile automate pot fi programate să ruleze neîntrerupt, 24 de ore zilnic, lucru care este uman imposibil.
Completitudinea testării de regresie.
Și de această dată avantajul este de partea testării automate. Odata construite, cazurile de test pot fi executate oricând, de oricâte ori se dorește. În cazul testării manuale, de cele mai multe ori testarea de regresie se aplică numai asupra unei porțiuni mici a softului, cea directă afectată de modificări, lucru datorat insuficienței de timp și de resurse umane. Prin prisma acestui criteriu, testarea automată oferă cel mai mare grad de siguranță că prin depanarea unei erori nu s-au introdus altele.
Simularea condițiilor reale de utilizare a sistemului
Testarea automată permite executarea de load testing sau testarea eficienței pentru sistemele medii și mari. Acest gen de testări sunt aproape imposibili de executat manual asupra sistemelor care sunt altfel decât relativ reduse ca și complexitate.
Costuri necesare
La capitolul investiții, testarea automată începe să necesite mai multe resurse în detrimentul testări manuale. Pentru testarea manuală este nevoie doar de oameni care trebuie sa aibă cunoștințe generale despre metode de testare. În cazul testării automate, dacă un pachet care să corespundă nevoile softului dezvoltat există deja , este necesară întâi achiziționarea lui , apoi instruirea personalulul care îl va folosi. Însă, datorită faptului că varietatea mediilor de dezvoltare ale aplicațiilor este în continuă creștere, aceste pachete nu sunt mereu disponibile, ceea ce înseamnă că instrumentele de testare automată vor trebui dezvoltate intern, lucru care din nou implică asignarea de resurse umane și financiare.
3.IMPLEMENTAREA SOLUȚIEI ADOPTATE
3.1 Introducere
Din analiza făcută în capitolele anterioare putem spune ca nu există o cale ideală în a asigura calitatea produselor software în întregime, dar ne putem asigura că cele mai multe defecte ale produsul software au fost descoperite și fixate. În cadrul proiectelor mari, acolo unde există foarte multă fucționalitate, este foarte ușor să se introducă alte defecte atunci când se fixează unul existent sau când se implementează o funcționalitate nouă. Din acest punct de vedere testarea automată joacă un rol deosebit de important, deoarece după fixarea unui bug, sau adăugarea unei noi funcționalități este foarte ușor să se ruleze testele automate in timpul nopții, fiind imposibil ca testerii, indiferent de numărul lor să poată testa toată aplicația într-un timp atât de scurt.
De exemplu, dacă avem o aplicație care are o bază de date și unele funcționalități care sunt folosite foarte des, de exemplu CRUD (create, read, update, delete) este foarte important ca atunci când se modifică ceva în aplicație, cel puțin aceste funcționalități să fie retestate. În cadrul aplicațiilor web, aceste scenarii trebuie testate pe mai multe browsere și pe mai multe environment-uri, iar ca și timp și resurse o companie poate fi afectată din punct de vedere funcțional. Din această cauză, testete automate, odată ce au fost create se pot rula pe toate browserele și pe toate environmenturile, nefiind nevoie de un efort uman și financiar.
Pentru a scoate in evidență avantajele testării automate am ales să creez unele scenarii care sunt folosite zilnic pe un site online, și anume ’www.olx.ro’. Cu ajutorul acestui site se pot promova anunțuri online. Cele mai importante scenario pe acest site sunt: funcționalitatea de login, căutarea unui produs și publicarea unui anunț (dacă nu se completează toate field-urile care sunt obligatorii se afișează o eroare, această eroare fiind verificată ), prin urmare am ales să automatizez aceste scenarii.
Figura 3.1 Diagrama logică
3.2 Setarea mediului de lucru
3.2.1 Instalare Java
Pentru a putea crea teste automate folosind Selenium trebuie să avem instalat local Java SE Development Kit:
Figura 3.2 Java
3.2.2 Instalare Eclipse IDE
După instalarea Java, trebuie de asemedea instalat Eclipse IDE:
Figura 3.3 Eclipse IDE
3.2.3 Selenium Java Client Driver
Următorul pas este avela de a downloada Selenium Java Client Driver, care conține si o arhivă selenium-java-2.53.0, director care conține toate fișierele JAR care ulterior vor fi importate in Eclipse:
Figura 3.4 Selenium Java Client Driv 1
3.2.4 Configurarea Eclipse IDE cu Selenium WebDriver
După ce s-a creat un nou proiect trebuie importate câteva librării. Pașii pentru a importa aceste librării sunt enumerați mai jos:
Se dă click drapta pe numele proiectului si se alege Properties
Se selectează Java Build Path
Se selectează tabul Libraries
Se dă click pe Add External JARs..
Figura 3.5 Adăugare librării
Trebuie adăugate toate fișierele din folderul libs și cele din exteriorul său. După importarea acestor librării o să avem următoarea structură:
Figura 3.6 Biblioteci
3.3 Structura proiectului
Pentru a scoate in evidență modul de lucru cu tool-ul de testare automată Selenium, s-au creat câteva teste automate folosind site-ul www.olx.ro.
Au fost create mai multe cazuri de testare printre care:
Login cu succes
Login fără succes
Verificarea titlului paginii în cazul în care loghinul a fost cu succes
Verificarea câmpurilor mandatory pe pagina de adăugare a unui anunț nou
Căutarea unui anumit produs și verificarea rezultatului obținut
Pentru a fi mai bine structurat și a scoate în evidență modul în care trebuie lucrat cu testele automate s-au creat cinci pachete:
data – pachet care conține clasele cu datele care se introduce în fielduri
locators – pachet care conține clasele cu identificarea elementelor pe pagina web
setup – pachet care conține clasa cu testul de bază (metoda în care se determină browserul folosit)
testexec – pachet cu clasele în care sunt testele
teststeps – pachet cu clase în care s-au scris metodele de scrierea în fielduri, validarea butoanelor, validarea label-urilor, etc
Figura 3.7 Structura proiectului
3.3.1 Pachetul data
Pachetul data conține două clase:
Prima clasa ‘DataAddAnnouncement’ conține datele pentru adăugarea unui anunț nou care sunt stocate în variabile de tip string:
Figura 3.8 DataAddAnnouncement
A doua clasă ‘DataLogin’ conține datele pentru login stocate în variabile de tip string și publice. Primele două variabile conțin date valide, folosite la testul în care loghinul se face cu succes. Următoarele două variabile conțin date invalide folosite la testul în care loghinul este fără succes:
Figura 3.9 DataLogin
3.3.2 Pachetul locators
Pachetul locators conține 3 clase cu elementele identificate în pagina web, identificate după id, xpath sau className:
Prima clasă ‘AddNewannouncement’ conține id-urile și xpath-urile ale elementelor de pe pagina de adăugare al unui anunț nou:
Figura 3.10 AddNewAnnouncement
Pentru a afla id-ul unui element din pagina Web se dă click dreapta pe elementul dorit, se alege opțiunea Inspect și se poate vizualiza id-ul si clasele elementului respectiv (De exemplu pentru fieldul titlu)
Figura 3.11 Inspect element
După ce se selectează această opțiune se poate vizualiza id-ul:
Figura 3.12 Id element
Se poate ca un element sa nu aibă id, moment în care pentru a găsi elementul respectiv în pagină se poate folosi xpath-ul acestuia. Xpath-ul unui element se poate afla în felul următor: după ce s-a dat click dreapta pe fieldul respectiv și se selectează opțiunea Inspect se dă click dreapta pe linia respectivă si se selectează Copy xpath:
Figura 3.13 Xpath element
A doua clasă ‘LoginLocators’ conține id-urile și xpath-urile ale elementelor de pe pagina de login:
Figura 3.14 LoginLocators
Variabila labelloginfailed conține xpath-ul către label-ul care este afișat pe pagină în momentul în care userul sau parola sunt greșite și loghinul nu este cu succes.
A treia clasă ‘MainPageLocators’ conține id-urile și xpath-urile ale elementelor de pe pagina principală. Se poate observa că în această clasă avem elemente identificate și dupa numele clasei (className), modul în care se poate afla clasa din care face parte un element este similar cu aflarea id-ului:
Figura 3.15 MainPageLocators
3.3.3 Pachetul setup
Acest pachet conține clasa MainTest care la rândul ei conține metoda de setare a browser-ului setBrowser(). Tot în această clasă sunt și metodele SetUp() și TearDown(). Rolul acestor metode este acela de a seta și a face teardown la browser pentru fiecare test executat. Lucru care scoate în evidență faptul ca testele automate se pot rula independent unul față de celelalte, acesta fiind un avantaj mare.
Deoarece majoritatea proiectelor Web se testează pe mai multe browsere s-a creat metoda de setare a browser-ului, metoda care se apelează în metoda SetUp() alegând browser-ul cu care se dorește să se lucreze:
private static void setBrowser(String browser){
switch(browser)
{
case "Firefox":
{
driver = new FirefoxDriver();
break;
}
case "Chrome":
{
System.setProperty("webdriver.chrome.driver",
System.getProperty("user.dir")
+ "\\drivers\\chromedriver.exe");
driver = new ChromeDriver();
break;
}
case "IE":
{
System.setProperty("webdriver.ie.driver",
System.getProperty("user.dir")
+ "\\drivers\\IEDriverServer_x64.exe");
DesiredCapabilities caps = DesiredCapabilities.internetExplorer();
caps.setCapability("ignoreZoomSetting", true);
driver = new InternetExplorerDriver(caps);
break;
}
}
}
Iar in metoda SetUp() se apelează această metodă cu browserul droit, de exemplu pentru Chrome apelul metodei este:
setBrowser("Chrome");
3.3.4 Pachetul testexec
Pachetul testexec conține 3 clase, în fiecare clasă este un test în care se apelează metodele create în alte clase din pachetul teststeps :
TestExecusion
TestExecutionAddNewAnnouncementFailed
TestExecutionSearchAnnouncement
De exemplu clasa TestExecusion, este clasa care conține două teste: în primul test se folosește userul și parola corectă, drept urmare loghinul este cu succes, iar în al doilea test se folosește un user greșit și o parole greșită, urmând să se facă o validare ca loghinul in acest caz nu este cu succes și este afișat un mesaj de eroare, care este și el validat prin apelarea metodei VerifyLabelLoginFailed():
@Test
public void LoginSuccessful() throws InterruptedException
{
pageSteps.fillinUser();
pageSteps.fillinPassword();
pageSteps.pressLoginButton();
pageSteps.VerifyPageTitle();
}
@Test
public void LoginFailed() throws InterruptedException
{
pageSteps.fillinWrongUser();
pageSteps.fillinWrongPassword();
pageSteps.pressLoginButton();
Thread.sleep(3000);
pageSteps.VerifyLabelLoginFailed();
}
Deoarece aceste metode sunt create în clasa ScreenActionsLogin avem conceptul de moștenire și de instanțiere a acestei clase pentru a putea apela metodele respective:
public class TestExecusion extends ScreenActionsLogin{
ScreenActionsLogin pageSteps = new ScreenActionsLogin();
}
Clasa TestExecutionAddNewAnnouncementFailed conține și ea metodele scrise în clasa ScreenActionsAddNewAnnouncement:
SelectAddNewAnnouncementButton();
AddTitleAnnouncement();
AddDescriptionAnnouncement();
AddCityAnnouncement();
AddContactNameAnnouncement();
AddPhoneAnnouncement();
Cookiesbar();
VerifyLabelCategory();
După cum spuneam mai sus fiecare test este independent, motiv pentru care si în această clasă se face apelul metodelor pentru loghin din clasa ScreenActionsLogin verificându-se titlul paginii pentru a fi sigur că loghinul a fost cu secces:
fillinUser();
fillinPassword();
pressLoginButton();
VerifyPageTitle();
Clasa TestExecutionSearchAnnouncement conține metodele scrise în clasa ScreenActionsSearchAnnouncement:
gotoMainPage();
selectCarLogo();
selectAutoturisme();
selectMarcaAuto();
selectModelAuto();
OpenCaroserieList();
SelectCaroserie();
PressSearch();
VerifyResultsCar();
3.3.4 Pachetul teststeps
Pachetul teststeps conține trei clase în care sunt scrise metodele pentru a face fill in la un field, pentru a da click pe un buton, pentru a face anumite validări pe un anumit text, etc:
ScreenActionsAddNewAnnouncement
ScreenActionsLogin
ScreenActionsSearchAnnouncement
De exemplu clasa ScreenActionsLogin conține mai multe metode printre care: fillinUser(), VerifyPageTitle(), VerifyLabelLoginFailed(), etc. Pentru a putea folosi datele din clasele LoginLocators și DataLogin au trebuit făcute instanțele următoare:
public LoginLocators loc = new LoginLocators();
public DataLogin dat = new DataLogin();
public void fillinUser()
{
try{
driver.findElement(loc.user).sendKeys(dat.userlogin);
}
catch(NoSuchElementException e){
screenshot();
}
}
Se poate observa că se folosește metoda findElement(loc.user), user este variabila din clasa LoginLocators care conține id-ul field-ului unde trebuie introdus user-ul. Prin metoda sendKeys(dat.userlogin) se face fill in la acest field, valoarea fiind luată din variabila userlogin din clasa DataLogin.
public void VerifyPageTitle() throws InterruptedException{
String expectedTitle = "Anunturi Gratuite – Peste 4 milioane anunturi – OLX.ro";
//salvarea titlului paginii intr-o variabila de tip string
String actualTitle = driver.getTitle();
//comparare intre expectedTitle si actualTitle
Assert.assertEquals(expectedTitle, actualTitle);
Thread.sleep(3000);
}
În această metodă se salvează titlul paginii într-o variabilă de tip string, după care prin apelarea metodei getTitle() se determină titlul paginii si se compară cele două.
public void VerifyLabelLoginFailed(){
String expectedLabel = "Date de autentificare incorecte";
String actualLabel=driver.findElement(loc.labelloginfailed).getText();
System.out.println(actualLabel);
Assert.assertEquals(expectedLabel, actualLabel);
}
}
În această metodă se compară dacă label-ul obținut prin metoda getText() (în urma apelării ei în testul în care se verifică funcționalitatea de loghin), este egal cu label-ul salvat în variabila expectedLabel de tip string.
4. REZULTATE EXPERIMENTALE
4.1 Rulare teste login
După cum ziceam în capitolele anterioare avantajul testelor automate este acela că se pot rula independent fiecare test. De exemplu clasa TestExecution conține două teste, primul test este pentru a testa funcționalitatea de loghin când atât userul cât și parola sunt valite și al doilea test este pentru cazul în care userul și parola nu sunt valine. Aceste două teste se pot rula independent de celelalte, pentru a face acest lucru trebuie dat click dreapta pe clasa respectivă, se selectează Run as și JUnitTest:
Figura 4.1 Rulare teste
În urma rulării acestor două teste se poate vizualiza rezultatul care arată dacă testele au trecut sau nu și durata fiecărui test:
Figura 4.2 Rezultat teste rulate
Dacă se schimbă un anumit label, de exemplu am schimbat textul label-ului care se afișează când userul sau parola nu sunt corecte, se poate observa că testul care verifică acel label a picat fiind posibil să verificăm și motivul pentru care testul a picat:
Figura 4.3 Rezultat teste loghin
4.2 Rulare test adăugare anunț nou
La fel se poate executa independent testul de adăugare al unui anunț nou:
Figura 4.4 Rezultat test adaug anunț
Dacă se schimbă label-ul pentru fieldul categorie testul o sa pice:
Figura 4.5 Rezultat test adaug anunț picat
4.3 Rulare test căutare anunț
Și testul de a căuta un anumit anunț se poate rula independent:
Figura 4.6 Rezultat test caut anunț
La fel dacă se schimbă textul care se dorește să se valideze, testul o să pice:
Figura 4.7 Rezultat test caut anunț picat
4.4 Rulare teste
Dacă se lucrează pe un proiect mai mic și testele se rulează manual se pot rula care se doresc, dar în cazul proiectelor mai mari unde sunt foarte multe scenarii de test iar în momentul în care se adaugă ceva funcționalități noi și se face testarea de regresie, testerul nu are timp sa testeze manual întreaga aplicație acoperind toate scenariile. De aceea se rulează toate testele automate și cazurile care nu sunt automatizate se testează manual. În cadrul acestot proiecte se crează in fiecare noapte un nou build automat și testele se rulează pe build-ul respectiv, testerul având posibilitatea ca atunci când ajunge la locul de muncă primul lucru care îl face este să verifice rapoartele generate cu testele executate în timpul nopții și în cazul în care sunt teste picate, se analizează și se raportează buguri dacă e cazul.
Figura 4.8 Rulare teste 1
Pentru a rula toate testele se dă click dreapta pe proiect, se selectează Run as și apoi Run Configurations..:
Figura 4.9 Rulare teste
Sau se poate folosi butonul de run din fereastră:
Figura 4.10 Rulare teste din fereastră
Figura
După ce se selectează Run Configurations se deschide următoarea fereastră:
Figura 4.11 Run Config
După ce se selectează Run all tests in the selected project, package or sourcefolder și se apasă butonul Run se rulează toate testele existente în proiect:
Figura 4.12 Run teste success
Se poate întâmpla ca unele dintre teste să treacă iar unele să pice, dacă în suita de teste sunt foarte multe teste create și pot apărea probleme de blocare a bowser-ului:
Figura 4.13 Run teste fără succes
5.Concluzii
Scopul acestei lucrări a fost de a scoate în evidență diferențele între testarea manuală și testarea automată.
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 nici o ș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ă fie testate de mai multe ori, pe mai multe platforme software și hardware, ca și după schimbările ulterioare sau la lansarea unei noi versiuni de produs. Prin folosirea testării automate, costurile testărilor repetate se reduc aproape la zero.
Rularea testelor automate ajută foare mult la testarea de regresie, mod prin care se face maintenance la întreaga aplicație software. Există multe avantaje pentru automatizarea testelor. Cele mai multe sunt legate de repetabilitatea testelor și viteza cu care testele pot fi executate. Nu este întotdeauna avantajos pentru a automatiza cazuri de testare. Există situații în care testarea manuală poate fi mai adecvată. De exemplu, dacă interfața cu utilizatorul a aplicației se va schimba considerabil in viitorul apropiat, atunci orice automatizare ar putea avea nevoie să fie rescrisă aproape în totalitate. De asemenea, uneori, pur și simplu nu este suficient timp pentru a crea teste automate.
Având în vedere aceste detalii s-au creat teste automate pe site-ul www.olx.ro, teste care pot sa fie rulate individual, mai multe sau toate în același timp. Acest mod de a rula testele este un avantaj foarte mare deoarece testele se pot rula pe diferite mașini în același timp fără a fi nevoie de intervenția unui tester, acesta urmând să vizualizeze și să analizeze rezultatele care se află în rapoartele generate.
În funcție de proiect, de cât de complex sau cât de des se schimbă se poate allege între testarea manual și testarea automată sau ambele. Dacă trebuie repetate aceleași teste e multe ori și pe mai multe configurații automatizarea prezinta un mare avantaj. La fel, testele pot fi rulate simultan pe mai multe mașini scăzând timpul de testare iar costurile pe termen lung sunt reduse. Dar dacă problema este analizată din perspectiva testării manuale, utilizând doar testarea automată nu se pot face teste ad-hoc, iar dacă testele create trebuiesc rulate de un număr mic de ori e mult mai probabil să se prefere testarea manuală, deoarece costurile pe termen scurt sunt reduse.
Deoarece nu se poate automatiza totul, anumite teste trebuie rulate manual pe mai multe configurații ceea ce la un moment dat poate să devină monoton.
Selenium nu este doar un tool unic sau un utilitar, ci un pachet de mai multe tool-uri de testare și pentru același motiv, el este ca o suită.
6.Bibliografie
[1]T.Boudreau, J.Glick, S.Greene, J.Woehr, V.Spurlin, NetBeans: The Definitive Guide, O’Reily Media, 2002
[2]L.Vogel, W.Beaton, Eclipse IDE – Java programming, debugging, unit testing, task managementand Git version control, Vogella, 2013
[3] http://elf.cs.pub.ro/mps/wiki/
[4] The ISTQB website, http://istqb.org
[5] http://www.testingexcellence.com/seven-principles-of-software-testing/
[6] http://www.testingexcellence.com/fundamental-test-process-software-testing/
[7] http://www.testingexcellence.com/fundamental-test-process-software-testing/
[8] http://www.todaysoftmag.ro/article/392/planificarea-testarii-de-performanta
[9] http://istqbexamcertification.com/what-is-beta-testing/
[10] http://istqbexamcertification.com/what-is-alpha-testing/
[11]http://www.softwaretesting.ro/Romana/Files/ManualVsAutomation/Software%20Testing%20Manual%20vs%20Automated.html
[12] http://www.aut.upt.ro/
[13] http://docs.seleniumhq.org/
[14] http://webdriverselenium.blogspot.ro/2012/05/difference-between-selenium-ide.html
[15] http://www.todaysoftmag.ro/article/392/planificarea-testarii-de-performanta
[16] https://code.google.com/p/selenium/wiki/FirefoxDriver
[17] https://code.google.com/p/selenium/wiki/InternetExplorerDriver
[18] https://code.google.com/p/selenium/wiki/ChromeDriver
[19]https://www.google.ro/search?q=testing+principles+in+software+testing&espv=2&biw=1920&bih=979&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjI4YCxl7nNAhWCCpoKHfqQDDgQ_AUIBigB#imgrc=chr6RcPM6NKiQM%3A
[20] http://www.ranorex.com/ranorex-vs-selenium.html
[21] http://www.testingexcellence.com/seven-principles-of-software-testing/
7.Anexe
Clasa TestExecusion :
public class TestExecusion extends ScreenActionsLogin{
ScreenActionsLogin pageSteps = new ScreenActionsLogin();
@Test
public void LoginSuccessful() throws InterruptedException
{
pageSteps.fillinUser();
pageSteps.fillinPassword();
pageSteps.pressLoginButton();
pageSteps.VerifyPageTitle();
}
@Test
public void LoginFailed() throws InterruptedException
{
pageSteps.fillinWrongUser();
pageSteps.fillinWrongPassword();
pageSteps.pressLoginButton();
Thread.sleep(3000);
pageSteps.VerifyLabelLoginFailed();
}
}
Clasa TestExecutionAddNewAnnouncementFailed:
public class TestExecutionAddNewAnnouncementFailed extends ScreenActionsAddNewAnnouncement {
ScreenActionsAddNewAnnouncement actionsAdd = new ScreenActionsAddNewAnnouncement();
ScreenActionsLogin log = new ScreenActionsLogin();
@Test
public void AddNewAnnouncement() throws InterruptedException
{
log.fillinUser();
log.fillinPassword();
log.pressLoginButton();
log.VerifyPageTitle();
actionsAdd.SelectAddNewAnnouncementButton();
actionsAdd.AddTitleAnnouncement();
actionsAdd.AddDescriptionAnnouncement();
actionsAdd.AddCityAnnouncement();
actionsAdd.AddContactNameAnnouncement();
actionsAdd.AddPhoneAnnouncement();
actionsAdd.Cookiesbar();
actionsAdd.VerifyLabelCategory();
}
}
Clasa TestExecutionSearchAnnouncement:
public class TestExecutionSearchAnnouncement extends ScreenActionsSearchAnnouncement{
ScreenActionsSearchAnnouncement searchA = new ScreenActionsSearchAnnouncement();
ScreenActionsLogin log = new ScreenActionsLogin();
@Test
public void SearchCar() throws InterruptedException
{
log.fillinUser();
log.fillinPassword();
log.pressLoginButton();
log.VerifyPageTitle();
searchA.gotoMainPage();
searchA.selectCarLogo();
searchA.selectAutoturisme();
searchA.selectMarcaAuto();
searchA.selectModelAuto();
searchA.OpenCaroserieList();
searchA.SelectCaroserie();
searchA.PressSearch();
searchA.VerifyResultsCar();
}
}
Clasa ScreenActionsAddNewAnnouncement:
public class ScreenActionsAddNewAnnouncement extends MainTest {
AddNewannouncement addA = new AddNewannouncement();
DataAddAnnouncement dataAddA = new DataAddAnnouncement();
MainPageLocators locAdd = new MainPageLocators();
public void SelectAddNewAnnouncementButton() throws InterruptedException
{
try{
driver.findElement(locAdd.addNewA).click();
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
private void screenshot() {
// TODO Auto-generated method stub
}
public void AddTitleAnnouncement() throws InterruptedException
{
try{
driver.findElement(addA.title).sendKeys(dataAddA.titleA);
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void AddDescriptionAnnouncement() throws InterruptedException
{
try{
driver.findElement(addA.description).sendKeys(dataAddA.descriptionA);
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void AddCityAnnouncement() throws InterruptedException
{
try{
driver.findElement(addA.city).sendKeys(dataAddA.cityA);
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void AddContactNameAnnouncement() throws InterruptedException
{
try{
driver.findElement(addA.contactname).sendKeys(dataAddA.contactNameA);
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void AddPhoneAnnouncement() throws InterruptedException
{
try{
driver.findElement(addA.phonenumber).sendKeys(dataAddA.phonenumberA);
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void Cookiesbar() throws InterruptedException
{
try{
if (driver.findElement(addA.closeCookiesbar).isDisplayed()) {
driver.findElement(addA.closeCookiesbar).click();
}
driver.findElement(addA.saveannouncement).click();
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void VerifyLabelCategory() throws InterruptedException{
String expectedLabelCat = "Alege o categorie";
String actualLabelCat=driver.findElement(addA.labelCatError).getText();
System.out.println(actualLabelCat);
Assert.assertEquals(expectedLabelCat, actualLabelCat);
Thread.sleep(3000);
}
}
Clasa ScreenActionsLogin:
public class ScreenActionsLogin extends MainTest{
public LoginLocators loc = new LoginLocators();
public DataLogin dat = new DataLogin();
public void fillinUser()
{
try{
driver.findElement(loc.user).sendKeys(dat.userlogin);
}
catch(NoSuchElementException e){
screenshot();
}
}
private void screenshot() {
// TODO Auto-generated method stub
}
public void fillinWrongUser()
{
try{
driver.findElement(loc.user).sendKeys(dat.wronguserlogin);
}
catch(NoSuchElementException e){
screenshot();
}
}
public void fillinPassword()
{
try{
driver.findElement(loc.password).sendKeys(dat.passwlogin);
}
catch(NoSuchElementException e){
screenshot();
}
}
public void fillinWrongPassword()
{
try{
driver.findElement(loc.password).sendKeys(dat.wrongpasswlogin);
}
catch(NoSuchElementException e){
screenshot();
}
}
public void pressLoginButton()
{
try{
driver.findElement(loc.login).click();
}
catch(NoSuchElementException e){
screenshot();
}
}
public void VerifyPageTitle() throws InterruptedException{
String expectedTitle = "Anunturi Gratuite – Peste 4 milioane anunturi – OLX.ro";
// fetch the title of the web page and save it into a string variable
String actualTitle = driver.getTitle();
// compare the expected title of the page with the actual title of the page and print the result
System.out.println(actualTitle);
Assert.assertEquals(expectedTitle, actualTitle);
Thread.sleep(3000);
}
public void VerifyLabelLoginFailed(){
String expectedLabel = "Date de autentificare incorecte";
String actualLabel=driver.findElement(loc.labelloginfailed).getText();
System.out.println(actualLabel);
Assert.assertEquals(expectedLabel, actualLabel);
}
}
Clasa ScreenActionsSearchAnnouncement:
public class ScreenActionsSearchAnnouncement extends MainTest{
public MainPageLocators locM = new MainPageLocators();
public DataSearchCar sCar = new DataSearchCar();
public void gotoMainPage() throws InterruptedException
{
try{
driver.findElement(locM.logo).click();
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
private void screenshot() {
// TODO Auto-generated method stub
}
public void selectCarLogo() throws InterruptedException
{
try{
driver.findElement(locM.carlogo).click();
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void selectAutoturisme() throws InterruptedException
{
try{
driver.findElement(locM.selectautoturisme).click();
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void selectMarcaAuto() throws InterruptedException
{
try{
// Select dropdown = new Select(driver.findElement(locM.marca));
//dropdown.selectByVisibleText("Audi");
driver.findElement(locM.marca).click();
driver.findElement(locM.namecar).click();
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void selectModelAuto() throws InterruptedException
{
try{
// Select dropdown = new Select(driver.findElement(locM.marca));
//dropdown.selectByVisibleText("Audi");
driver.findElement(locM.model).click();
driver.findElement(locM.modelcar).click();
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(3000);
}
public void fillinStartPrice()
{
try{
driver.findElement(locM.startPrice).sendKeys(sCar.startpr);
}
catch(NoSuchElementException e){
screenshot();
}
}
public void fillinEndPrice()
{
try{
driver.findElement(locM.endPrice).sendKeys(sCar.endpr);
}
catch(NoSuchElementException e){
screenshot();
}
}
public void OpenCaroserieList() throws InterruptedException
{
try{
driver.findElement(locM.caroseriefield).click();;
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(5000);
}
public void SelectCaroserie() throws InterruptedException
{
try{
driver.findElement(locM.caroserie).click();;
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(5000);
}
public void VerifyResultsCar() throws InterruptedException
{
try{
String expectedcar = "Audi A4";
String actualcar = driver.findElement(locM.resultscar).getText();
System.out.println(actualcar);
Assert.assertTrue( actualcar.toLowerCase().contains(expectedcar.toLowerCase()));
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(5000);
}
public void PressSearch() throws InterruptedException
{
try{
driver.findElement(locM.search).click();;
}
catch(NoSuchElementException e){
screenshot();
}
Thread.sleep(5000);
}
}
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: Testarea Software (ID: 104945)
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.