1 Cuprins PLANIFICAREA ACTIVITĂȚII ………………………………………………..1 ABSTRACT ……………………………………………………………………….2 1. Stadiul actual ……………………………………………………………….. 1.1…. [610147]

1 Cuprins

PLANIFICAREA ACTIVITĂȚII ………………………………………………..1
ABSTRACT ……………………………………………………………………….2
1. Stadiul actual ………………………………………………………………..
1.1. Psihologia testării………………………………………………………..
1.2. Testare software………………………………………………………….
1.3. B ug-uri software celebre………………………………………………….
2. Fundamente teoretice ………………………………………………………….
2.1. Tipuri de testare…………………………………………………………..
2.1.1. Black -box testing………………………………………………..
2.1.2. White box testing………………………………………………..
2.1.3. Testare funcțio nală ……………………………………………….
2.1.3.1.Unit testing………………………………………………
2.1.3.2.Integration testing………………………………………
2.1.3.3. System testing………………………………………….
2.1.3.4. Acceptance testing……………………………………..
2.1.3.5.Regression testing……………………………………..
2.1.3.6.Smoke testing…………………………………………..
2.1.3.7.Sanity testing……………………………………………
2.1.4. Testare non -funcțională………………………………………..
2.1.4.1.Performance testing……………………………………
2.1.4.2.Security testing…………………………………………
2.1.4.3.Usability testing…………………………………………
2.1.4.4. Localization & Internalization testing…………………
2.2. Testare manuala…………………………………………….
2.3. Testare automata……………………………………………
2.4. Testare manuala vs. automata…………………………….
3. Implementare …………………………………………….
3.1. Cazuri de test………………………………………………..
3.2. Tehnologii utilizate pentru testarea aplicațiilor………………….
3.3. Aplicatia CrossNG…………………………………………………………
3.4. Implementarea testelor manuale
3.4.1. Descrierea unui bug
3.4.1. Testarea unui bug
3.5. Implementarea testelor automate
4. Rezultate experimentale …………………………………………………
4.1. Metodologia Agile……………………………………………
4.2. Metodologia Agile in testare…………………………………..
4.3. Procedura de eliberare interna a datelor………………..
5. Concluzii ……………………………………………………………

2 6.Bibliografie ………………………………………………………..

Planificarea activității

Sarcini de lucru

Data inceperii
Numar zile
Data sfarsit

Alegerea temei
10.11.2017

1
10.11.2017
Studiu bibliografic și
acumularea de
cunoștințe legate de
tema proiectului

10.11.2017

45
07.03.218

Studiul utiliz ării
aplicațiilor

07.03.2018

25
01.04.2018

Scrierea testelor
manuale/ automate
Redactarea lucrarii

01.04.2018

80

09.07.2018

Printare si legare

09.07.2018
2
11.07.2018

Termen de predare

12.07.2018
1
12.07.2018

3 Lista Figuri

Figura 1.1. Cauzele apariției unui bug in procesul de dezvoltare software
Figura 2.1 Conceptul metodologiei Black -Box
Figura 2.2. Conceptul metodologiei White -Box
Figura 2.3. Cand avem nevoie de Regression Testing
Figura 2.4. Executarea testarii smoke si s anity
Figura 2.5. Pașii execuției testării smoke
Figura 2.6. Procesele testării manuale
Figura 2.7. Piramida testarii lui Mike Cohn
Figura 2.8. Efectuare testare automata
Figura 2.9. Proiectul POM creat de Maven
Figura 2.10. Aplicatia CrossNG -pagina de sta rt
Figura 3.1. Ciclul de viata al unui bug(I)
Figura 3.2. Ciclul de viata al unui bug(II)
Figura 3.3. Descrierea unui bug din aplicatie
Figura 3.4. Testarea manuala a unui bug gasit in aplicatie
Figura 3.5. Pașii unui test de regresie care v -a fi automatiz at
Figura 3.6. Test de regresie automatizat
Figura 3.7. Identificarea unui element pe o pagină web cu ajutorul Firebug
Figura 4.1. Strategia testelor Agile
Figura 4.2 Pagina de RTC Jazz
Figura 4.3. Componente de test care au fost incarcate pe Gerrit
Figura 4.4. Statusul build -urilor care au fost deployed

Lista Tabele

Tabelul 2.1. Diferenta dintre smoke si sanity testing
Tabel 2.2. Comparare testare manuala/automata
Tabel 3.1. Pasii de executie ai unui test

Lista Abrevieri

1.Tool – unealtă
2.OOP – Object Oriented Programming
3. Test -case – set de condiții și variabile care alcătuiesc un test manual
4. JDK – Java Development Kit

4 5. IE – Internet Explorer
6. POM – Project Object Model
7. Pluggin – componentă software care adaugă anumite funcționalită ți unei aplicații
8. DB – Data Base
9. SQL – Structured Query Language
10. API – Application Programming Interface
11. NASA – The National Aeronautics and Space Administration

Abstract

1. State of the Art

In this paper I made a s hort summary about psychology of testing, how do you have to
think to become a good tester and find as many ways to approach this topic. When you want to
test an application, you want to add a value to it, to improve its quality by finding errors and
elimi nate them. We do test a program to find as many errors possible, not to show that the

5 program works. If our purpose is to show that the program has errors, we will find more test data
to help us find defect in the program.
As a point of view, a good devel oped test is successfully tested when it finds errors that
can be solved and also when it establish that there are no more errors to fix. The only
unsuccessfully test is the one which does not examine the specific software and in the meantime,
a test which does not find any error is considered unsuccessful because a program without errors
is practically unrealistic.
Software testing is a process of evaluation which establishes the quality of a product. The
tester compare the input data and the output data d esired. Therefore software testing is a process
of validation and verification of a product.
Verification of a product is the process that assure us that the program satisfy the
condition required in the beginning of the product development.
Validation is the process which assure us that the product satisfy the requirements at the
end time of product development.

Fig 1. Kind of tests included in verification and validation of a product [7]

Software testing is very important in the product life cycle because there are always things
that are not working as we wish during implementation of an application.
Testing is very important to be done from the early stage of product life, because in this
way we can save money and time.
Software products can prese nt defects when the specifications of the product are not well
written, they are continuously changing or they are not adequate transmitted to the development
team. Another reason can be that the implementation is not well documented, the product is very
complex or time pressure can make developers not to pay enough attention on their work.

2. Theoretical Fundamentals

6 There are two types of testing: functional and non -functional testing and both are very
important for a system to be done, but firstly th ere are 2 important strategies of testing:
● Black -Box testing, an important strategy where we imagine a program as a black
box. The purpose of this type of testing is to neglect the intern behavior, the
structure of the program and to be focused on the inpu t and output data. There are
also advantages and disadvantages for Black -Box testing. For using this test
strategy, tester does not need to know a programming language, test cases can be
created when the specifications are complete, but bad thing is that o nly a small
number of input data can be tested, so many parts of the program would be
untested.
● White -Box testing it is another strategy of testing which allows us to explore the
internal code. We name this methodology white box, because we imagine the
application as a white box, where the code is visible for the tester. Testing is done
by the tester who takes some input data, values which would give us the expected
outputs, after a code review. As an advantage of White -Box testing is the ease that
we can a utomate tests and the visibility of the internal code help us to find the
input data used for testing the application. There are also disadvantages because it
is a complex and expensive procedure which needs people with programming
knowledge and if the imp lementation is always changing, there is a need of new
tests.
Functional testing is done to be sure that the application works as expected. We want to be
sure that the output data is the same as client desires. There are many types of functional testing,
but the most important ones are:
● Unit testing tests individual components or units to be sure that every part of the software works
as client requires. If they are good written and runned every time when the code is changed, we
will be capable to find any issue caused by adding or changing the code. It is also important not to
create test for every part of the application, but test which has a big impact on the system
behavior. Unit tests are usually neglected but they are very important.
● Integration testin g tests individual components or modules combined and tested as a whole, to see
if none of them affects other parts of the system. This is the second type of testing performed after
unit testing.
● System testing tests the whole integrated system to see if the product follow its requirements.
Usually is used with Black -Box strategy, where the externe functionality of the system are
evaluated with the documents given from the client. It is not necessary to have knowledge of
intern design or code of an applica tion for this type of testing to be done.
● Acceptance testing tests the final product to be sure that it can be sent to the client. It is done by
the members of the organization who were not implicated directly into the project. We usually use
Black -Box str ategy. It does not follow a strict procedure and it is not documented.
● Regression testing is a type of testing which confirms that a recent implemented program or code
changes did not affect the system till that moment. Regression tests are parts of tests already

7 executed. They are runned again to be sure that the existing functionalities behaves correctly after
other defects are fixed or the customer requirements are changing.
● Smoke testing is a type of testing which verifies the major functionalities of a product after new
implementations, to check if the product works as required. Smoke testing has an important role
in development because it assures the corectitude of the application from its early stage. Every
problem from the applicatio n can be identified performing smoke testing.
● Sanity testing is a type of testing which is performed when any minor bug is fixed or when there
are new things developed or parts of code are changed. These tests are almost same as regression
tests, but they are more fast. Sanity testing is different than Smoke because first one is
concentrated on one or two functionalities, while smoke testing is effectuated to be sure that all
major functionalities of the application are working correctly.
Non-functional tes ting is done to prove the performance, speed and stability of a product.
We test how prepared is the application, after the functional testing is done. There are also many
types of non -functional testing which can be done, some of them are:
● Performance tes ting has the role to eliminate the obstacles which decrease the performance of the
system. It verifies the speed, scalability and stability of the application. There are many types of
performance testing as load, stress, endurance, spike, volume. Speed is usually the most important
part of an application. If a program is slow it can lose the user interest.
● Security testing is performed to ensure the security of the system, to observe how vulnerable is
the application, as long as in our days there are a lot of transactions done using web applications
and its very important for them to be secured and not to lose important data. The most important
things for this type of testing is the access on an application, data protection, attacks.
● Usability testing is pe rformed to see how intuitive is an application, because it is very important
for an user to use an application easily. Tests are executed by putting few people to execute a
series of tasks on the application interface. Tasks represent actions that an user can do after the
product is done. In this way we can see the react of users so the problems can be fixed or we can
debate the way we could improve the application.
● Localization & Internalization testing is performed to check if the product adapt with cultu re and
needs of users. It is concentrate on cultural aspects and language, translation of the interface,
documentations and files in other languages, phone numbers and the local hour.
In the end we are asking how can we perform testing. There are two ways , both of them
with advantages and disadvantages, and both very important depending on what we use it:
Manual and Automation testing.
Manual testing is performed by a tester in person, to check if the application works as
desired. He follows a set of test s cases he documents and checks if everything works fine. It
requires much effort, but it is very important because automation testing can not cover everything,
as a human can. It allows the tester to be more flexible during the tests and try more scenario s.
Automation testing is done by tools to avoid the repetitive manual work, and get a faster
answer about the quality of the product. It saves time when the tests are executed for many times.
It is performed in the following cases like: Regression testing , Load testing, Repetitive execution,
Performance testing.

8

Figura 2. Automation Testing Services [31]

As a comparison of this to ways of making tests, both of them have advantages and
disadvantages. The type of testing used depends on many factors, as project requirements, costs,
time, defects types. Manual testing is not so accurate since the people can not pay so much
attention as an automated test can and it also requires more time. Automation testing is performed
when tests are runned repeatedly, w hile manual testing is performed when tests are runned once
or twice.
Technologies needed for automation testing were made to create a good and an easy
environment for users, to execute and implement tests cases in a more efficient way.
For my project I u sed the following technologies:
● Java is a programming language, which can be used for automation testing used in my
case with IntelliJ IDEA.
● IntelliJ IDEA is a development environment for Java, used for developing new softs and
automation tests.
● SQL develo per is a free graphic interface. It allows DB users and admins to execute their
tasks.
● Selenium WebDriver it is a automation testing tool for web applications, to check if the
softs works as we desire.
● Maven is a tool used for the project build and managem ent, written in Java. We can build
a project using project object model(POM) and a set of data which are transmitted in every
project.

My project includes manual and automated tests on CrossNG application, to be sure every
functionality works good after every new implementation, since the application has new releases
every year.
Cross is the Car -Dealer -Management -System of the most profitable car manufacturer

9 worldwide. Volkswagen transacts about 50% of its yearly turnover
(greater than 100 billion euros) by using Cross.
The cloud -based CrossNG (Next Generation) features state of the art business processes
and supports sellers and service staff all over the world.

3. Implementation

Now, after classification we need to know what is a test case, what it includes and why it
is important.
A test case is a set of conditions a tester follows. It is a document where a tester need to
introduce data about scenarios he makes to test an application, and where he can establish if the
application does what is nece ssary. It includes the following data: Test Case ID, Summary,
Preconditions, Steps, Actual and Expected results and in the end the Status of the test, if it is
passed or failed. The test cases structures depends on every organisation, but these are the mos t
important things.
It is very important that the description of a defect to be as specific it could so the
developer can fix the problem and the tester to be able to verify if the application works correctly.
For testing a bug tester takes the document ation created by requirements engineers with
and creates its testing document where he writes all steps and how the application behaves after
the fix is done.

4. Experimental Results

For everything to work good in an organization, people started t o follow some principles,
as Agile Methodology. It suppose to make people more collaborative, flexible and easily adapt in
a project. Agile favors teamwork and split the requirements in sprints, and present every new
implementation to the client at the end of the sprint, which is a very good way to improve the
software, during its implementation, than to find out at the end of production that something is not
working as client desires.

5. Conclusion

In conclusion testing has a given place in a softwar e product lifecycle. The quality of the
product depends by user in the most time. Testing is the only way to check a module before it is
released. The efficiency of testing influence all development cycle phases.

10 If we pay attention to the testing phase, the producer needs to spent considerable money,
but they will be recovered by the positive effects given by users, effects based on the quality of
the product. Since a product has a good quality, users will spend more money on it.

1.Stadiul actual

1.1. Psihologia testării

Una dintre cauzele testării insuficiente sau vagi ale unei aplicații este aceea ca majoritatea
programatorilor încep cu o falsa definiție a termenului “testare”.
● “ Testarea este procesul de a demonstra ca erorile nu sunt prezente.”
● “ Scopul testării este de a arata ca o aplicație își executa funcțiile destinate corect.”
● “ Testarea este procesul de a produce siguranța ca un program funcționează cum ar trebui.”
Aceste definiții nu sunt in totalitate corecte.
Când testezi un program, vrei sa adaugi o valoarea acestuia, prin ai creste calitatea sau fiabilitatea,
acestea presupunând găsirea și eliminarea erorilor.
Așadar, nu testam un program pentru a arata ca acesta funcționează, ci ar trebui sa pornim
cu ipoteza ca programul conține e rori, iar apoi testând sa găsim cat mai multe erori posibile.
O definitie mai adecvata ar fi:
● “ Testarea este procesul de execuție al unui program cu intenția de a găsi erori”.
Dacă scopul nostru este de a demonstra ca programul nu are erori, atunci vom f i
subconștient dirijați spre acest scop și vom tinde sa alegem niște date de test prin care puțin
probabil vom găsi defecte în program.
Ca un alt punct de vedere, dacă scopul nostru este acela de a demonstra ca un program are
erori, datele noastre de test ne vor ajuta sa găsim cat mai multe. Astfel, urmând a doua varianta
vom adăuga mult mai multa valoare programului nostru.
Aceasta definiție a testării are implicari imense, faptul ca testarea este un proces distructiv,
chiar unul sadic, care explica de ce majoritatea oamenilor o găsesc a fi dificila. Majoritatea
persoanelor au mai degrabă o viziune constructiva, decât una distructiva.
O alta modalitate de a consolida definiția propriu -zisa a testării este de a analiza rularea
testelor cu sau fără succes.
Expresia “ fară succes” denotă consecințe nedorite, dezamăgitoare.
Din punctul nostru de vedere, un test bine dezvoltat este executat cu succes când acesta
găsește erori care pot fi rezolvate și totodată când, eventual, acesta stabilește ca nu mai sunt eror i
care pot fi rezolvate. Singurul test “fără succes” este acela care nu examinează softul
corespunzător și, în majoritatea cazurilor, un test care nu a găsit erori va fi de obicei considerat
“fără succes”, ținând cont de faptul ca un program fără erori est e practic nerealist.

11 In concluzie, testarea este mai degrabă văzuta ca un proces distructiv în încercarea de a
găsi erori într -un program. Un test de caz este cu adevărat eficient, atunci când acesta favorizează
progresul in cauzarea unui defect. [1]

1.2 Testarea software

Testarea software este procesul de evaluare a unui produs software pentru a detecta
diferența dintre datele de intrare și datele de ieșire dorite.
Totodată acesta evaluează trăsăturile unui produs software. Testarea stabilește calitate a
unui produs, procedeu ce ar trebui finalizat in timpul unui proces de dezvoltare. Cu alte cuvinte
testarea este un proces de verificare și validare.
Verificarea este procesul care oferă certitudinea ca programul satisface condițiile impuse
la începutul fazei de dezvoltare, sa ne asigure ca programul se comporta in modul in care ne
dorim.
Validarea este procesul care ne oferă certitudinea ca produsul satisface cerințele la
sfârșitul fazei de dezvoltare, sa ne asigure ca produsul este construit pe baza cer ințelor clientului.
[3]

De ce este testarea importanta?

Testarea software este necesară deoarece toți facem greșeli. Unele nu sunt atât de
importante, dar exista unele care implica pericol sau costuri mari. Trebuie sa verificam tot ceea ce
producem deoar ece lucrurile nu vor funcționa întotdeauna asa cum ne dorim.

Figura 1.1. Cauzele apariției unui bug in procesul de dezvoltare software [7]

De ce apare un bug in procesul de dezvoltare software?

12 Produsele software prezintă defecte atunci când:
● specifica țiile unui produs nu sunt scrise in detaliu, sunt superficiale, se schimba continuu sau când
acestea nu sunt transmise echipei de dezvoltare corespunzător.
● proiectarea este superficiala, se modifica sau nu este comunicata corespunzător, eficient.
● implement area nu este documentata corespunzător, complexitatea produsului sau presiunea
termenului limita.

1.3. Bug -uri software celebre

1. Naveta spatiala Mariner 1 (1962)

Naveta Spatiala Mariner 1 a deviat de la traiectoria sa după scurt timp ce a fost lansata,a
fost distrusa la 293 secunde după lansare. Cauza acestui eșec a fost o eroare la transcrierea unei
instrucțiuni, determinând calculul eronat al traiectoriei. Costul acesteia a fost de 18.5 milioane de
dolari.

2. Tratamente împotriva cancerului (1985)

Pentru tratamentul împotriva cancerului a fost dezvoltat dispozitivul Therac -25, folosit in
terapia prin radiații, programul calcula greșit doza de radiații pe baza datelor de intrare, iar ca
urmare pacienții au primit o doza mult mai mare decât cea normala , aceasta ducând la moartea a 3
pacienți și radierea a 3 persoane.

3. Jocul asociat desenului animat Disney Lion King (1995)

La apariția pe piața a companiei Disney cu un joc pentru copii, The Lion King Animated
Storybook, unii utilizatori nu au putut folosii produsul achiziționat, întrucât compania nu testase
produsul pe diferite modele de calculatoare existente pe piață. Acest lucru i -a costat credibilitatea
companiei și schimbarea unităților CD -ROM.

4. Knight Capital Group (2012)

Casa de brokera j Knight Capital Group a suferit o pierdere consistenta pe bursa din New
York din cauza sistemului care a introdus tranzacții care au provocat fluctuații violente ale
preturilor multor acțiuni. Ca și rezultat s -au produs pierderi de 440 milioane de dolari in doar 45
minute.

5. Naveta spatiala Mars Polar Lander (1998)

Aceasta avea ca și obiectiv studierea solului și a climei din regiunea Planum Australe de
pe Marte. Pentru a identifica oprirea motoarelor navetei, NASA a folosit un senzor pe talpa

13 picioar elor navetei, care determina oprirea alimentarii cu combustibil. La intrarea in atmosfera
planetei Marte, programul a interpretat vibrațiile navetei, ca și cum aceasta ar fi aterizat, iar
motoarele navetei au fost oprite. Aceasta a avut ca și rezultat prăb ușirea navetei de la înălțimea de
40m fata de suprafața planetei Marte.
Așadar, din nou, cauza acestui eșec este testarea incompleta a programului, procedura de
aterizare fiind împărțită in 2 etape care au fost testate independent, fără o testare integral a a
acestora. [7]

2. Fundamente teoretice

2.1. Tipuri de testare

2.1.1. Black -Box Testing

Una dintre strategiile importante ale testării este black -box. Pentru a folosii aceasta
metoda, trebuie sa ne gândim la program ca la o cutie neagra . Scopul este de a neglija total
comportamentul intern și structura programului și concertarea testerului in a căuta circumstanțele
in care programul nu se comporta conform specificațiilor sale. [24]

Figura 2.1 Conceptul metodologiei Black -Box[24]

14
Privind aceasta abordare, datele de test sunt derivate numai din specificații, fără a avea
avantajul de a cunoaște structura interna a programului.
Dacă vrem sa folosim aceasta abordare pentru a găsi toate erorile dintr -un program,
trebuie sa găsim toate date le de intrare posibile și sa le folosim într -un test de caz.
Aceasta metoda de testare se folosește in următoarele cazuri:
● Funcții incorecte sau care lipsesc;
● Erori in interfata;
● Erori in cazul structurilor de date sau la accesul bazelor de date externe;
● Erori de performanta ale sistemului;
● Erori de initializare;

Avantaje ale testarii Black -Box:

● Teste care sunt executate deja din punctul de vedere al utilizatorului și vor ajuta sa expună
anumite discrepante intre specificațiile produsului;
● Testerul nu tr ebuie sa cunoască un limbaj de programare sau cum a fost implementat
softul;
● Testele de caz pot fi create odata ce specificatiile sunt complete;
● Teste impartiale deoarece designer -ul si testerul lucreaza independent;

Dezavantajele testarii Black -Box:

● Doar o mic număr de date de intrare pot fi testate, așadar multe părți din program vor
rămâne netestate;
● Fara specificații clare, testele de caz vor fi greu de creat;
● Testele pot fi redundante daca testele de caz au fost deja executate de către developer sau
de către software designer;
● Testarea fiecărei date de intrare nu este posibila deoarece necesita mult timp;

2.1.2. White -box testing

O alta strategie a testării, white -box permite examinarea structurii interne ale unui
program. Aceasta strategie derivea ză datele de test dintr -o examinare a logicii programului și de
obicei, din păcate prin neglijarea specificațiilor sale.
Testerul alege datele de intrare, ca odată analizat codul, sa determine datele de ieșire
corecte. Cunoștințele de programare sunt esen țiale.
Aceasta metoda a fost numita astfel deoarece programul, in ochii unui taster este ca o cutie
alba/ transparenta, înăuntrul căreia se vede foarte clar.

15 Pentru a înțelege pe deplin un sistem sau o componenta este nevoie sa le cunoaștem la
nivel de cod. Așadar testerul are nevoie să înțeleagă codul sau sa aibă acces la acesta. [32]

Figura 2.2. Conceptul metodologiei White -Box [33]

Avantajele testarii White -Box:

● Optimizarea codului in urma dezvăluiri erorilor ascunse;
● Transparenta in structura co dului intern, ceea ce ne ajuta la derivarea datelor de intrare
necesare in testarea unei aplicații;
● Testele de caz pot fi cu ușurința automatizate;

Dezavantajele testarii White -Box:

● Este o procedura complexa și scumpa care necesita îndemânarea unei pers oane
profesioniste in programare care înțelege structura interna a codului;
● Este nevoie de noi teste in cazul in care implemetarile se schimba prea des;
● Daca aplicatia este de mari dimensiuni, testarea completa devine mult mai complexa
utilizand metoda whi te-box;
● Necesitatea de a crea o gama intreaga de date de intrare, pentru a testa fiecare parte din
aplicatie, face ca aceasta metoda de testare sa consume prea mult timp;

2.1.3. Testarea funcțională

Fiecare tip de testare are caracteristicile, avantajel e și dezavantajele sale.
Testarea funcționala este un proces de testare software folosit pentru a ne asigura ca
programul se comporta conform cerințelor. Aceasta este in primul rând folosita pentru a verifica
dacă anumite parți din program prezintă acelea și date de ieșire prevazute de către client sau de
către companie. Pe scurt, aceasta include evaluarea și compararea fiecărei funcții a programului in
concordanta cu cerințele clientului. Programul este testat prin preluarea de date de intrare care sa
furnizeze date de ieșire corespunzătoare, pentru a vedea dacă odată comparate cu cerințele,
acestea sunt corecte. Totodată, testarea funcționala verifica programul pentru a observa ușurința
utilizării acestuia, pentru a ne asigura ca funcțiile de navigare func ționează cum ne așteptăm.

16 Unele tehnici de functionare includ testarea smoke, white box, black box, unit si user
acceptance. [2]

2.1.3.1.Unit testing

Unit testing este un tip de testare software unde sunt testate componente sau unități
individuale. Scop ul acesteia este de a verifica ca fiecare părticica a softului creat funcționează
conform cerințelor. De obicei acesta are unul sau sau doar câteva date de intrare și doar o singura
ieșire. In programarea obișnuita, un unit poate fi un program, o funcție s au procedura individuala.
In OOP cel mai mic unit este o metoda care aparține unei clase derivate, super clase sau unei clase
abstracte. Este utilizata in primul nivel de testare software și este efectuata înainte de Integration
testing.
Aceasta este efect uata utilizând testarea White -Box, in principiu de către dezvoltatori, in rare
cazuri este efectuata și de testări.

Avantaje Unit tests

● Prin dezvoltarea de Unit tests creste siguranța ca in urma schimbării codului, programul rămâne
intact. Daca acest ea sunt bine scrise și sunt rulate de fiecare data când codul este schimbat, vom fi
capabili sa găsim orice defect introdus in urma adăugării/ schimbării codului;
● Codul se poate refolosi cu ușurință.
Sfaturi pentru unit tests:
● Găsește un tool/framework pe ntru limbajul de programare folosit de tine;
● Nu crea teste de caz pentru orice, concentrează -te pe testele care au un impact mai mare asupra
comportamentului sistemului;
● Separa mediul de implementare de mediul de testare;

17 ● Înainte de a rezolva un defect, sc rie un test care sa expună problema defectului, deoarece in cazul
in care defectul nu este rezolvat in totalitate sau cum ar trebui, vei fi capabil sa găsești problema
mai rapid;
● Scrie teste de caz care sunt independente una de alta, de exemplu dacă o clas a are legătura cu baza
de date, nu scrie un caz care interacționează cu aceasta. Crează o interfața abstracta, in jurul bazei
de date și fa implementarea folosind un sistem virtual;
● Efectueaza unit test continuu si frecvent;
● Da atentie mare conditiilor in bucla;
● In plus, atunci când scrii teste pentru a verifica comportamentul programului, acestea trebuie sa ne
asigure și performanta codului.
Unit testele sunt de obicei neglijate, dar sunt defapt cele mai importante. [10]

2.1.3.2.Integration testing

Integration testing este un tip de testare software unde unități individuale sunt combinate
și testate împreuna. Scopul acestui tip de testare este acela de a expune problemele care apar la
interacțiunea intre unitățile integrate.
Acesta este al doilea tip d e testare efectuat după Unit testing și înainte de System testing. Acesta
poate fi efectuat de către developeri sau testări.
Orice metoda precum black box, white box și gray box pot fi folosite, aceasta depinzând
de testarea unit. [12]
.

2.1.3.3 System testing

System testing este un tip de testare in care se testează un sistem complet integrat. Scopul
acestui tip de testare este de a evalua daca sistemul final este in concordanta cu cerințele
clientului.

18 Este al treilea nivel de testare software, fiind efectuata după Integration Testing și înainte
de Acceptance Testing, efectuata independent de către testări.
In mare parte, este folosita testarea black -box, in care funcționalitatile externe ale softului
sunt evaluate cu ajutorul documentelor primite de l a client, in legătură cu dorințele sale și e in
totalitate bazata pe viziunea utilizatorilor. Pentru acest tip de testare nu sunt necesare cunoștințe
despre designe -ul intern al aplicației sau de cod. [14]

De ce este important acest tip de testare?

● Este primul tip de testare care testează sistemul ca și un întreg;
● Putem observa daca sistemul îndeplinește funcționalitatile dorite de către client;
● Testarea sistemului iți da libertatea de a testa, valida și verifica atât arhitectura aplicației cat și
cerințele de business.

2.1.3.4. Acceptance testing

Acceptance testing este un tip de testare in care se testează produsul final, daca acesta
poate fi trimis la client, îndeplinind toate condițiile acestuia.
De obicei este folosita testarea Black -Box. Ac easta nu urmează o procedura stricta si nu
este documentata.
Acceptance testing este al patrulea și ultimul tip de testare efectuata după System testing și
înainte de a pune aplicația in folosința.
Acest tip de testare este efectuat de către membrii orga nizației care au dezvoltat softul dar
care nu sunt implicați direct in proiect. De obicei este testat de către cei de la managementul
producției, vânzări sau suportul clienților.
Customer Acceptance Testing este efectuat de către clienții organizației ca re au dezvoltat
softul.
User acceptance testing este efectuat de către clienții finali, cărora le vom livra produsul.

19

2.1.3.5.Regression testing

Regression testing este un tip de testare care confirma ca un program recent implementat
sau un cod schim bat de curând nu a afectat in nici un fel funcționalitatile implementate pana in
momentul respectiv.
Acestea sunt parți selectate din teste deja executate, acestea fiind testate din nou pentru
siguranța ca functionalitatile existente se comporta corect, ne asigura ca vechiul cod încă
funcționează după ce schimbările in noul cod sunt efectuate. [15]

Cand este nevoie sa facem Regression Testing?

● Când se schimba cerințele și codul este modificat in funcție de acestea;
● Când noi funcționalități sunt introduse in aplicație;
● Atunci când anumite defecte sunt fixate;

Fig 2.3. Tehnicile testarii de regresie[15]

Mentenanța softului include, ca și activitate, îmbunatățiri, erori, schimbări, ștergeri ale
componentelor deja existente, implementate. Aceste modificări pot cauza daune aplicației noastre,

20 făcând ca aceasta sa nu mai funcționeze corect. Așadar, Regression Testing devine foarte necesara
și cuprinde anumite tehnici.
Pentru a selecționa cazurile de test care ne interesează pentru Regression Tests trebuie sa
avem in vedere anumite lucruri, deoarece in urma experientelor numărul cel mai mare de defecte
găsite in industrie, sunt reportate de către clienți in ultimul moment.
● Cazuri de test care au defecte cel mai frecvent;
● Funcționalități care sunt foarte vizibila din punct de vedere al utilizatorilor;
● Teste care verifica in profunzime implementarile necesare aplicatiei;
● Teste pentru functionalitatile care au trecut prin mai multe schimbări, sau schimbări recente;
● Toate Integration tests
● Toate cazurile de test comp lexe;
● Anumite teste care au trecut cu succes;
● Teste care au intampinat probleme in efectuarea lor;
Daca softul trece prin schimbări frecvente, costurile pentru Regression Testing vor creste.
In astfel de cazuri, efectuarea acestora prin testare manuala va necesita mult timp și bani. Testarea
automata prezintă un avantaj, dar aceasta depinde de numărul testelor care se pot refolosii. [15]

Diferenta dintre Re -testare si Regression Testing
Re-testarea presupune testarea functionalitatilor sau a defectelor pe ntru a ne asigura ca
codul este corect. Daca acesta nu este corect, nu îndeplinește cerințele, defectul trebuie deschis
din nou. Daca acesta este corect, defectele sunt închise.
Regression Testing presupune testarea aplicației când a avut loc o schimbare a codului,
pentru a ne asigura ca noul cod nu a afectat alte părți ale softului. [15]

2.1.3.6.Smoke testing

Smoke testing este un tip de testare care verifica, odată ce anumite funcționalități au fost
implementate, daca produsul încă funcționează cum n e dorim. Acesta cuprinde câteva mici teste
de caz care se rulează după fiecare adăugare de cod. Pe scurt, verificam daca caracteristicile
importante ale aplicației funcționează și nu exista anumite acțiuni care sa ne oprească in
dezvoltarea aplicației.
Acesta reprezinta un mic test de regresie efectuat asupra functionalitatilor majore ale
aplicației. Este un test simplu care ne asigura ca produsul poate fi testat in continuare, astfel
economisind timp și resurse materiale.
Smoke testing este efectuat oricâ nd noi funcționalități sunt dezvoltate și integrate in
aplicația curenta. Ne asigura daca toate functionalitatile majore se comporta corect sau nu. Daca
aceste teste trec, echipa de testări continua cu Functional testing.
Orice eroare întâmpinata trebuie semnalata programatorilor. Oricând exista o schimbare in
aplicație, efectuam Smoke testing ca sa ne asiguram de stabilitatea sistemului.

21 Smoke testing are un rol important in dezvoltarea unei aplicații, deoarece aceasta asigura
corectitudinea aplicației încă din stadiile inițiale.
● Toate obstacolele din aplicație vor fi identificate efectuând smoke testing;
● Cu ajutorul testelor Smoke majoritatea defectelor sunt identificate in primul stagiu al
dezvoltării softului;
● Cu Smoke testing simplificam detectia si corectia defectelor majore;
● Echipa de testări pot găsi defecte in funcționalitatea aplicației care au apărut datorita
noului cod implementat;
● Smoke testing gaseste defectele cele mai majore;
Smoke testing este de obicei testat manual, dar este posibil sa fie si automatizat. Variaza in
funcție de companie.
Testarea automata este in mare folosita pentru testele de regresie, dar este posibila și
automatizarea unui set de teste Smoke, astfel programatorii pot verifica ceea ce au implementat
foarte rapid, asi gurându -se ca toate funcționalitate majore se comporta corect. Daca exista ceva
probleme, ei pot sa le rezolve imediat, astfel economisesc timp și asigura calitatea produsului. [17]

Cum se executa testarea Smoke?
Odată ce schimbările au fost implementate ș i testele smoke au trecut cu succes, urmează
sa facem testarea funcționala. Daca testele smoke întâmpina defecte in program, oprim testarea
pana când defectele sunt fixate.

Figura 2.5. Pașii execuției testării smoke[17]

Avantajele testării Smoke
● Sunt u sor de testat

22 ● Defectele sunt identificate într -un stagiu rapid al dezvoltării
● Asigura calitatea sistemului
● Reduce riscurile aparitiei altor defecte
● Reduce timp si efort din partea testerului/programatorului
● Se executa rapid
Daca nu executam testele Smoke î ntr-un stagiu cat mai puțin evoluat al aplicației,
defectele pot apărea mai târziu, iar costurile pot creste semnificativ. Un defect găsit, mai târziu,
poate bloca alte parți din aplicație, iar produsul nostru va necesita mult mai mult timp și efort
pentru a fi readus la o funcționalitate corecta.

2.1.3.7. Sanity testing

Sanity testing este un tip de testare care se efectuează atunci când orice bug minor este
fixat sau atunci când se implementează, sau schimba anumite parți din cod. Acesta este efectuat
de testări, pentru a se asigura ca aplicația merge după cerințele clientului.
Spre deosebire de Smoke testing, Sanity testing se concentrează pe una sau doua
funcționalități, pe când Smoke testing este efectuata pentru a ne asigura ca toate functionalitat ile
majore a aplicației funcționează corect.
Dupa ce schimbările au fost făcute in cod, testării preiau aplicația, după care se fac teste
Sanity, in locul testelor de regresie care ar necesita mult mai mult timp.
Daca aplicația nu funcționează in continuar e cum ar trebui, testării nu accepta schimbările
făcute in cod, iar problema este semnalata într -un stagiu rapid, datorita testelor Sanity.

Lucruri importante despre Sanity testing:

● Este un tip de testare care urmărește in detaliu anumite caracteristici ale aplicației;
● In Sanity testing, testării urmăresc și verifica comenzile și funcționalitatile produsului;
● Este o subcategorie a testelor de regresie;
● Este efectuata atunci când nu avem destul timp pentru o testare detaliata a aplicației;
● Aceasta nu este documentata;
● Este un tip de testare rapida și scurta, pentru a ne asigura ca schimbările funcționează după cum
ne așteptam;
● Sanity testing urmărește functionalitatile produsului in urma rezolvării defectelor minore și a
schimbărilor mici de cod, daca aces tea se comporta la fel in urma adăugării altor funcționalități,
iar cele vechi au rămas intacte;

Avantajele testelor Sanity

23 ● Economisesc mult timp și efort deoarece acest tip de testare se concentrează doar asupra câtorva
funcționalități;
● Nu necesita doc umentatie;
● Ajuta la identificarea functionalitatilor care lipsesc;
● Este folosita pentru a verifica daca mici funcționalități ale aplicației funcționează după anumite
schimbări de cod;

Dezavantajele testarii Sanity

● Sanity testing se concentrează doar asup ra comenzilor și funcțiilor produsului;
● Acestea nu ajung la nivel de design, așadar este dificil pentru dezvoltatori sa înțeleagă ce au de
reparat in urma acestui tip de testare;
● Este efectuata doar pentru câteva dintre functionalitatile produsului, astfel daca sunt probleme in
alte funcționalități ale acesteia, defectele vor fi greu de găsit;
● Acestea nu sunt documentate, astfel nu pot fi refolosite pe viitor;

Diferentele dintre Smoke testing si Sanity testing

Tabelul 2.1. Diferenta dintre smoke si sanity testing
Smoke testing Sanity testing
Scopul testării Smoke este de a verifica
întreaga stabilitate a sistemului Scopul testării Sanity este ce a verifica
întregul raționament al sistemului
Smoke testing este folosita pentru a verifica
daca funcționalita tile de baza se comporta
precum vrem Sanity testing este folosita pentru a verifica
daca produsul se mai comporta precum ne
dorim, după anumite schimbări, adăugări de
cod
Smoke testing urmareste o abordare larga si
superficiala Sanity testing urmareste o abordare
aprofundata, dar mai restransa
Smoke testing este de obicei documentata Sanity testing nu este documentata in mare
parte
Smoke testing este efectuata de testari, dar si
de dezvoltatori Sanity testing este efectuata doar de testari
Smoke testin g se efectueaza mai devreme Pe cand Sanity testing este efectuata dupa
Smoke testing

24
Figura de mai jos exemplifica faptul ca testarea smoke este executata in primele versiuni
ale programului pe cat acesta nu este foarte stabil. Verifica functionalitati le majore, dar nu intra
prea mult in detaliu. Testele Sanity sunt efectuate la sfârșitul versiunii programului, pe cand
acesta devine mai stabil, verificând defectele din versiunea anterioara și noile implementări. Dupa
ce aceste 2 tipuri de teste au trecu t este efectuata testarea funcțională și cea de regresie.

Figura 2.4. Executarea testarii smoke si sanity [34]

Un build reprezinta versiunea unui program. Versiunile repetitive reprezinta parti
importante in procesul de implementare. Prin implementare, componentele unei aplicații sunt
colectate și compilate in mod repetat in scopuri de testare, pentru a asigura un produs final de
încredere. [29]

2.1.4. Testarea non -funcționala

Testarea non -funcționala reflecta performanta, viteza și stabilitatea si stemului. Aceasta se
concentrează pe cerințele non -funcționale și este efectuata pentru a evalua cat de pregătita este
aplicația in concordanta cu multitudinea de criterii care nu sunt acoperite de testarea funcțională.
De exemplu, prin testarea funcțional ă vrem sa vedem ca un set de date este introdus corect in baza
de date și funcționează totul cum ne dorim, pe când prin Usability testing, un tip de testare non –
funcționala, vrem sa observam cat timp durează stocarea datelor, daca acest timp este prea lung
sau se încadrează in cerințele noastre.
Testarea non -funcționala demonstrează cat de bine se comporta produsul nostru. Desigur,
și testarea funcțională este foarte importanta, dar totodată încrederea și atracția unui utilizator fata

25 de produsul software dezvoltat este constituit prin calitățile sale non -funcționale. Așadar, testarea
non-funcționala este indispensabila produsul dorit. [19]

2.1.4.1.Performance testing

Performance testing este un tip de testare prin care ne asiguram ca programul se execu ta
corect conform așteptărilor in funcție de volumul de munca.
Scopul acestui tip de testare nu este de a găsi defecte in aplicației ci de a elimina impedimentele
care scad performață acestuia. Timpul de răspuns al aplicației, fiabilitatea, rata de folos ire a
resurselor sunt niște factori foarte importanți.
Scopul testelor de performanta sunt de a verifica programul in funcție de:
● Viteza – determina viteza aplicației și cat de repede răspunde la acțiunile pe care le facem;.
● Scalabilitatea – determina num arul maxim de persoane pe care il suporta aplicația;
● Stabilitatea – verifica daca aplicația este stabila;
De ce sa efectuam testarea de performanta?

Testarea funcționala se efectuează pentru a vedea ce mai avem nevoie pentru ca aplicația
sa funcționeze cum ne dorim și sa fie mai apoi trimisa clientului. Problemele care ar putea sa
apară in urma neefectuări acestui tip de testare ar fi: încărcarea înceată a aplicației odată ce mai
multi utilizatori folosesc aplicația in mod simultan, inconsistenta in dife rite sisteme de operare,
utilizarea mult mai dificila a aplicației.
Tipuri de Performance Testing

● Load testing – testează când de repede se încarcă aplicația, in funcție de acțiunile pe care le
efectuam.
● Stress testing – testează care este numărul maxim d e utilizatori care pot folosii aplicația simultan,
fără ca aceasta sa functioneze mai greu.
● Endurance testing – vrem sa vedem daca aplicația poate fi solicitata la fel de mult după o mai
lunga perioada te timp;
● Spike testing – testează cum se comporta aplic ația in funcție de scăderea și crestearea brusca a
utilizatorilor care folosesc aplicația;
● Volume testing – verificam cum se comporta aplicația in funcție de volumul bazelor de date pe
care acesta le folosește;
Viteza este de multe ori una dintre cele mai importante caracteristici ale unei aplicații. Un
program care rulează foarte greu va pierde interesul utilizatorilor. Testele de performanta sunt

26 făcute pentru a ne asigura ca aplicația rulează destul de rapid încât sa le păstreze atenția și
interesul util izatorilor. [30]

2.1.4.2. Security testing

Security testing este un proces care este efectuat pentru a găsi erori in mecanismul de
securitate și pentru a găsi vulnerabilitatile sau slăbiciunile a aplicației.
Primul scop in efectuarea acestui tip de te stare este de a observa cat de vulnerabil este
sistemul și pentru a determina cat de protejate sunt datele și resursele de către anumiți intruși.
Numărul tranzacțiilor online au crescut foarte rapid, făcând ca testarea securității acestora sa fie
un factor foarte important, mai ales testarea aplicațiilor web. Aceasta cu cat este efectuata mai
des, cu atât este mai eficace in detectarea vulnerabilitatilor softului. [20]

De ce este nevoie de Security testing?

● Pentru a nu pierde credibilitatea/încrederea uti lizatorilor;
● Lipsa securității implica costuri mari, in cazul unui atac,
● Implicari legale din cauza unei securități slabe;
● Pierderea de date importante;
● Timp pierdut pentru repararea daunelor;

Tehnici de testare a securitatii:

1. Accesul la o aplicatie

Chiar daca este o aplicație desktop sau pagina web, securitatea este implementata prin acel
“Roles and Rights”(roluri și drepturi) pe care le are un utilizator. Pentru a testa acest lucru, un
tester ar trebui sa creeze mai multe conturi, cu diferite sau mult iple roluri și sa verifice daca
fiecare rol are acces la modulele, ecranele, formele sau datele pe care doar el le poate accesa, sau
neavându -le acestea sa nu poate fi accesate. Acest lucru poate fi înțeles totodată ca fiind efectuata
o testare a autentifi cării și autorizării utilizatorilor.
Așadar, trebuie sa testam ‘cine ești’ și ‘ce poți sa faci’ pentru diferiți utilizatori.
Unele dintre testele de autentificare include teste pentru calitatea parolei, pentru recuperarea
acesteia, teste pentru funcționali tatea de log out, teste pentru schimbarea parolei, teste pentru
întrebările/răspunsurile de securitate in cazul uitării datelor de acces username/parola.

2. Protecția datelor

27 Exista trei aspecte cu referir e la protecția datelor. In primul rând un utilizator poate sa
vizualizeze și sa utilizeze doar datele pe are voie sa le acceseze. Acest lucru este stabilit, încă
odată de rolurile și drepturile pe care le are respectivul utilizator. Al doilea aspect in pro tecția
datelor se refera la cum sunt stocate datele in baza de date. Toate datele importante trebuie
securizate si criptate, in special parolele conturilor, numere de card sau alte informații sensibile
despre companii. Al treilea aspect, este o extensie a celui de al doilea. O securitate foarte buna
trebuie adoptata in cazul informațiilor importante. O data ce aceste date sunt transmise prin alte
module ale aceleiași aplicații sau transmise către alte aplicații, datele trebuie sa fie criptate, pentru
a fi in siguranța.
Pentru a testa protectia datelor un tester va interoga baza de date pentru parole, informatii
de plați ale clienților, sau alte date importante și va verifica daca datele respective sunt salvate sub
forma criptata in baza de date. Totodată, e ste important de testat daca datele criptate la sursa, sunt
corect decriptate la destinație, iar daca ceva merge prost, cu siguranța aplicația are erori de
securitate.

3. Atacuri
Majoritatea atacurilor sunt efectuate de către alte aplicații software. De exemplu, acesta
folosind un user valid, softul tinde sa ghicească și sa asocieze parole încercând sa se logheze de
mai multe ori. Pentru a putea evita acest lucru, este foarte important ca pentru funcționalitatea de
log in, odată ce este executata de mai multe ori, utilizatorul sa fie anunțat, sau aplicația sa
blocheze accesul pentru o perioada de timp.

2.1.4.3. Usability testing

Usability testing este un mod de testare pentru a vedea cat de ușoara este utilizarea unei
aplicații pentru un grup de utiliz atori reprezentativi. Aceasta include, observarea utilizatorilor,
daca aceștia reușesc sa -și îndeplinească task -urile pe diferite designe -uri, de la interfețe ale
utilizatorilor pana la produsele fizice. Se efectuează repetat, de la început pana la lansare a
produsului.
Principalul avantaj și scop al acestui tip de testare este de a identifica problemele de
utilizare cat mai devreme posibil, pentru ca acestea sa fie rezolvate înainte ca o anumita interfața
sa fie implementata.
Testele sunt executate prin pu nerea a mai multi participanți sa efectueze o serie de task -uri
cu respectiva interfața. Task -urile reprezinta acțiuni pe care le face un utilizator odată ce produsul
este finalizat. In timpul testului, testerul observa acțiunile fiecărui participant și de obicei acesta
înregistrează video sesiunea de test. Dupa analiza rezultatelor, testerul raportează aspectele
importante, incluzând aspecte de interfața care cauzează probleme și severitatea pe care le are
acestea și totodată parți ale interfeței pe care u tilizatorii le -au apreciat. [21]

Avantaje Usability testing :

28 ● Feedback direct către echipa care dezvolta proiectul;
● Putem observa cum reacționează utilizatorii, iar problemele pot fi rezolvate sau putem avea
dezbateri cum am putea îmbunătății anumite lucr uri in interfața;
● Problemele sau defectele sunt puse in evidenta inate ca produsul sa fie lansat;
● Creste satisfacția utilizarii produsului de catre clienti;
● Minimizeaza riscul defectării produsului;
● Utilizatorii sunt capabili sa -și atingă scopurile mult ma i ușor;
Ca și dezavantaj al acestui tip de testare, este ca testarea nu este 100% reprezentativa fata
de un scenariu din viata reala, deoarece fiecare om percepe diferit lucrurile. Totodată Usability
testing nu aduce la fel de mult feedback precum ar putea un chestionar, dar acesta poate fi mult
mai precis și profund.
In concluzie Usability testing poate fi folosit in mai multe moduri, pe tot parcursul
dezvoltării proiectului. Chiar daca nu suntem capabili sa mimam utilizarea acesteia ca și in viata
reala, usability testing este încă cea mai buna metoda de a asigura ca utilizatorii își pot atinge
scopul rapid și ușor. Odată ce o companie știe ce își dorește un utilizator, este mult mai probabil
sa dezvolte o aplicație de succes. [21]

2.1.4.4. Localization & Internalization testing

Localization & Internationalization testing verifica daca produsul se adaptează cu nevoile
și cultura publicului. Se concentrează pe aspecte culturale și de limba, traducerea interfeței, a
documentației și fișierelor in alte limb i, precum și numere de telefon, ora locala.
Specialiștii vor efectua localizarea și traducerea aplicației in rusa, engleza, germana,
franceza, italiana și alte versiuni ale produsului, in funcție de dorințele clientului.
Localization testing demonstrează ca traducerea conținutului este corecta, precum și diverse
elemente din interfață, erori, mesaje din sistem și documentații sunt citite corespunzător.
Nu se testeaza erorile de pronuntie si gramaticale.
Internationalization testing testează daca produsul suporta alte locații, evita problemele
integrării produsului in alte tari, cu diferite culturi. De exemplu in tarile arabe, textul este afișat
diferit și totodată nu sunt permise orice date. [23]

2.2. Testare manuala

Testarea manuala este procesul in care se folosesc funcționalități și caracteristici ale unei
aplicații ca și utilizator, pentru a verifica dacă o aplicație funcționează după dorințele clientului.
Prin testarea manuala, un tester verifica aplicația prin urmărirea unui set de teste de caz
predefinite.
Odată ce cerințele sunt înțelese bine, se pot scrie testele de caz. Testele de caz ghidează
testerul printr -o secventa de pași pentru a testa funcționalități și diferite scenarii in aplicație.
Testarea manuala necesita mult efort, dar este f oarte importanta deoarece testarea
automata nu poate acoperii chiar totul. Aceasta este preferata in cazurile in care vrem sa găsim și

29 sa fixam probleme de utilizare, Aceasta permite testerului sa fie mai flexibil in timpul testelor și
sa încerce mai multe scenarii.
Chiar daca acesta necesita mult timp, testarea manuala este necesara pentru a asigura o
buna calitate a produsului. Un tester poate găsi mai multe lucruri decât ar putea un test automat.
Testarea manuala de succes include înțelegerea cerințelor proiectului, scrierea unor teste de caz
complete și analiza rapoartelor defectelor.

Figura 2.6. Procesele testării manuale [35]

2.3. Testare automata

De ce automatizam?

In general automatizam pentru a evita munca manuala repetitiva, pentru a primi u n
răspuns mai rapid despre calitatea produsului, pentru a salva timp in rularea testelor, la infinit, și
pentru a ne asigura ca testele noastre au aceleași precondiții și funcționează cum ar trebui.
Testele manuale repetitive sunt plictisitoare, iar aces tea nu vor furniza același rezultat de
fiecare data. O persoana poate sa execute un test manual și sa nu tina cont de anumiți pași
importanți, ca mai apoi sa eșueze in găsirea unei erori in aplicație.
Un rezultat rapid e important pentru orice strategie d e integrare reușita. Aceasta iți permite
sa identifici dacă exista vre -o involuție a calității in același timp ce codul este comis, permițând
echipei sa rezolve problemele cat de repede. Totodată permite și dezvoltarea unor scenarii de test
care pot fi rep roduse de fiecare data când vrem sa rulam testele respective. Echipa se bazează pe
asta, pentru a implementa noile schimbări, sau sa refactorizeze codul. [5]

Ce automatizam?

Când vrem sa decidem ce teste sa automatizăm, in primul rând trebuie sa studiem
piramida testării lui Mike Cohn. Acesta este specializat sprijinul companiilor in a adopta
îmbunatățirea folosirii metodologiei agile și a tehnicii de a construi echipe de mare succes.

30
Figura 2.7. Piramida testarii lui Mike Cohn [6]

Instinctul unui no u tester care dezvolta teste automate este de a încerca sa acopere fiecare
scenariu pe care l -ar testa
manual. Integrarea continua a noilor îmbunatățiri, într -o aplicație necesita teste automate,
deoarece pentru fiecare schimbare, acesta va fi capabil sa r eexecute toate testele și sa se asigure ca
nici o funcționalitate nu este afectata.
Având in vedere ca o aplicație evoluează continuu, nu vrem ca și numărul testelor noastre
sa crească și întotdeauna sa treacă cu succes. Noi vrem teste care sa ne garantez e ca noile
implementări, chiar și cele adăugate deja, vor funcționa asemeni așteptărilor noastre. O abordare
foarte buna și eficienta ar fi sa acoperim toate ariile importante din perspectiva unei afaceri.
După cum știm, probabilitatea ca un test sa aibă rezultate negative, după ce acesta a trecut cu
succes, este mica. Rezultatele ar trebui sa fie examinate constant, iar testele trebuie evaluate după
fiecare interacțiune. [6]

2.4. Testare manuala vs. automata

Testarea software include multe domenii, da r se poate in prima parte împărții in 2
categorii: testarea manuala și testarea automata. Acestea au ambele atât avantaje cat și
dezavantaje, dar e important sa știm diferența dintre ele, cat și momentele când fiecare dintre ele
trebuie folosite pentru a d uce la cele mai bune rezultate.
In testarea manuala, testele de caz sunt executate manual fără ajutorul nici unui program,
pe când testarea automata se executa cu ajutorul anumitor softuri.
Tipul de testare folosit depinde de mai multi factori, cum ar fi cerințele pe care le are
proiectul, costuri, timp, expertize cat și potrivirea defectelor sau functionalitatilor pe care le
testam cu tipul de testare folosit. Trei dintre cele mai importante lucruri in orice proiect sunt
costurile, timpul și calitatea. S copul oricărui proiect de succes este acela de a reduce costurile și
timpul, iar aplicația sa aibă o calitate buna, cat mai aproape sau egale cu așteptările. [18]
Testarea manuala și cea automata acoperă doi arii vaste. In fiecare dintre cele doua
categor ii, exista metode de testare specifice, cum ar fi black box testing, white box testing,
integration testing, System testing, performance testing și load testing. Unele dintre acestea se
executa de preferat manual, iar altele prin intermediul automatizării .

Tabel 1.2. Comparare testare manuala/automata [18]

31 Testare manuala Testare automata
Testarea manuala nu este întotdeauna precisa
din cauza neatenției oamenilor, deci este mai
puțin de încredere Testarea automata este mult mai de încredere,
fiind efectu ata de anumite tehnologii
Testarea manuala consuma mai mult timp Testarea automata este executata de alte
aplicații, deci este mult mai rapida decât cea
manuala
Investitia se face in oameni Investitia se face in aplicatiile de testare
Testarea manuala este efectuata atunci când
testele sunt executate o data sau de doua ori, o
repetare frecventa a acestora nu este necesara. Testarea automata este efectuata atunci când
testele sunt rulate im mod repetat pe o
perioada mai lunga.
Necesita implicarea unei p ersoane, așadar
aceasta ne poate transmite cat este de intuitiva
aplicația și cat de plăcută este pentru utilizator. Testarea automata nu implica observațiile unei
persoane, așadar aceasta nu ne poate da un
feedback pozitiv la utilizarea aplicației de
către utilizatori.

Testarea automata se executa in urmatoarele cazuri:
● Regression testing – Testele automate sunt de preferat deoarece exista schimbări frecvente
de cod, iar testele trebuie repetate destul de des, astfel economisind timp.
● Load Testing: Testa rea automata este din nou cea mai buna varianta pentru a testa
eficienta unei aplicații.
● Execuțiile repetate: Testele ce implica execuția lor repetata, este cel mai bine sa fie
automatizate.
● Performance testing: Testarea ce implica simularea a mii de utili zatori, necesita
automatizare.
Daca memoram acești factori, putem găsi cele mai bune variante de testare a unei aplicații,
in funcție de situație. Sa cream un soft de o calitate cat mai buna, iar totodată sa economisim bani
și timp.

32
Figura 2.8. Efectuar e testare automata

3. Implementare
3.1. Cazuri de test

Un caz de test este un set de condiții sau variabile in urma căruia un tester determina daca
programul îndeplinește cerințele sau funcționează corect. Prin crearea de cazuri de test putem
totodată sa găsim probleme in specificațiile produsului sau designe -ul acestuia.

33 Un test de caz poate avea următoarele elemente, dar formatul acestuia difera in funcție de
aplicația folosita de companie.
Tabel 3.1. Pasii de executie ai unui test [11]
Test Case ID ID-ul cazului de test
Test Case
Summary Rezumatul/ Obiectivul cazului de test
Prerequisites Precodintiile pe care le implica efectuare testului.
Test Procedure Pașii executării testului.
Test Data Date de test sau link -uri care ne ajuta la executarea testului.
Expected
Result Rezultatele pe care le așteptam in urma executării testului
Actual Result Rezultatele pe care le primim in urma executării testului.
Status “Pass” sau “Fail”. Notam daca testul a trecut cu bine, iar
rezultatele pr imite sunt cele pe care ni le dorim, sau nu.
Remarks Cometarii legate de cazul de test sau de executarea testului.
Created By Numele celui care a creat testul.
Date of
Creation Data in care a fost creat cazul de test.
Executed By Numele celui care a e xecutat testul.
Date of
Execution Data executiei cazului de test.
Test
Environment Mediul in care a fost executat testul.

Reguli de raportare a unui bug

● Pentru început se realizează o descriere a problemei, defectului întâmpinat;
● Se raportează cat de repede, după identificarea acestuia;
● Testerul trebuie sa fie cat mai consecvent și riguros, sa urmărească starea defectelor raportate
anterior, sa nu se bazeze pe ceea ce au făcut sau spus alții;
● Timpul necesita atenție, întrucât nu trebuie ignorata du rata de realizare a unei operații;

34 ● Secventa de pași executata trebuie urmărită atent, deoarece aparent operația poate fi încheiata cu
succes, aceasta fiind evidențiata de execuția într -o anumita ordine a pașilor și nu de momentul in
care eroarea a apărut;
● Dependențele și interacțiunile trebuie identificate, întrucât acestea pot indica inconsistente sau
incompatibilități;
● Totodată componentele hard sunt importante, acestea trebuie analizate pentru a nu fi degradate,
iar ca urmare sa aibă o funcționalitate i mprevizibila; [8]

Ciclul de viata al unui bug

● Testerul investigheaza aplicatia, gaseste un defect si intocmeste un raport;
● Raportul creat este asignat programatorului, care la randul lui fixeaza problema;
● Raportul este mai departe asignat testerului, ca re poate confirma dacă defectul a fost fixat;
● Daca totul este in regula, testerul poate închide raportul;

Figura 3.1. Ciclul de viata al unui bug(I) [8]

● Stari ale unui bug stabilite de tester: new, pending testing, retest, reopened, verified, closed;
● Stari ale unui bug stabilite de programator: assigned, open(duplicate, rejected, ot a bug), fixed

35
Figura 3.2. Ciclul de viata al unui bug(II) [8]

3.2. Tehnologii utilizate pentru testarea aplicațiilor

Framework -urile au fost create pentru a asigura un mediu de execuție pentru testarea
automata, dar totodată și pentru a ajuta utilizatorii sa implementeze, sa execute și sa raporteze
teste de caz mult mai eficient. Cel mai important scop al unui framework de testare automata este
acela de a întâmpina ob iectivele testării și de a face munca tasterului mult mai ușoară și rapida.

3.2.1. Java

Java este un limbaj de programare si o platforma de calcul lansata in 1995 de către Sun
MicroSystems. Exista o mulțime de aplicații și site -uri web care nu funcțione ază, doar in cazul in
care Java este instalat, iar multe altele sunt create zilnic. Java este rapid, securizat si de incredere.
Aceasta se gaseste oriunde, de la laptopuri, console de joc pana la computerele de știința,
telefoane și Internet, aceasta este folosita peste tot.
Exista 2 modalitati de a lucra in Java: in linia de comanda sau prin crearea unei aplicatii in unul
dintre mediile de dezvoltare Java: Eclipse, IntelliJ IDEA sau NetBeans.

3.2.2. Intellij IDEA

Intellij IDEA este un mediu de dezvolt are pentru Java, folosit pentru crearea de softuri.
Acesta a fost lansat in 2001, și a fost primul mediu de lucru Java, care conținea navigație de cod

36 avansata și capacitatea de a refactoriza codul. Este compatibil cu sistemele de operare: Windows,
Mac OS și Linux și suporta limbaje precum Groovy, Java, Pyton, XML. [25]

3.2.3. SQL developer

Oracle SQL Developer este o interfața grafica gratuita. Aceasta permite utilizatorilor
bazelor de date și administratorilor sa -și execute task -urile prin câteva click -uri. Este un
instrument productiv, acesta ajutând utilizatorul sa economisească timp.

3.2.4. Selenium WebDriver

Selenium WebDriver este un instrument portabil de testare software pentru aplicatii web,
pentru a verifica daca acestea functioneaza cum dorim . Obiectivul acestei aplicatii este de a ne
furniza un API favorabil care sa fie usor de explorat si inteles, care va face ca testele sa fie mai
usor de citit. Nu este legat de nici un framework particular de test, deci se poate folosi foarte bine
cu JUni t sau TestNG. Se poate folosi pentru a crea suite de teste automate de regresie si sa testeze
si sa transmită scripturi in mai multe medii de lucru.
Selenium Webdriver accepta comenzi si le transmite catre browser. Acesta nu necesita un
server special pen tru a executa testele. In schimb, acesta pornește direct o instanta de browser și o
controlează.
Avantajele cele mai importante ale acestei aplicatii sunt:
● Transmite comenzi rapide catre browser;
● Este usor de folosit si inteles;
● Se poate folosi, de asemene a și pentru testarea aplicațiilor pentru Android și
IPhone;
● Ofera suport multor browsere cum ar fi IE, Safari, Opera, Chrome, Firefox;
● Poate fi integrat cu usurinta cu alte tool -uri;
● Exista multe date pe internet in legatura cu problemele tehnice ce tin de acesta;

3.2.5. Maven

Maven este un tool folosit pentru construirea și managementul proiectelor, scris in Java.
Maven permite construirea unui proiect utilizând POM (project object model) si un set de date
care sunt transmise prin toate proiectele. Aces ta prevede un ciclu de viata al proiectelor, poate
rula rapoarte, este un sistem de manangement al dependintelor.

37
Figura 2.9. Proiectul POM creat de Maven

3.3. Aplicatia CrossNG

CrossNG este o aplicație web de vânzări, dezvoltata de firma Porche Inf ormatik, aplicație
dezvoltata pentru reprezentanta Volkwagen pentru a înregistra toate datele atât despre persoanele
care cumpăra autoturisme din reprezentanta cat și totul despre autoturismele achiziționate, pe
toata durata folosinta. Cross reprezinta Sis temul managerial de vânzări de mașini al celui mai
profitabil producător de peste tot din lume. Volkwagen face afaceri cu aproximativ 50% din cifra
de afaceri anuala, folosind acest sistem. Cross NG (Next Generation) caracterizează procesele de
afaceri și sprijină vânzătorii și personalul de serviciu, in întreaga lume.

Figura 2.10. Aplicatia CrossNG -pagina de start

3.4. Implementarea testelor manuale

38
3.4.1. Descrierea unui bug

Este foarte important ca descrierea unui bug sa fie cat mai specifica, pen tru ca cel care se
ocupa de fixarea problemei și cel care testează mai apoi sa poate verifica daca programul merge
precum ne dorim.

Figura 4.3. Descrierea unui bug din aplicatie

3.4.2. Testarea unui bug

Testarea unui bug consta in preluarea documenta ției create pentru defectul găsit și mai
apoi crearea unei alte documentații de test in care se va menționa persoana care a executat testul,
mediul de lucru, pașii și rezultatul actual.

39
Figura 4.4. Testarea manuala a unui bug gasit in aplicatie

3.5. Implementarea testelor automate

Testele sunt automatizate,in mare parte, in cazul testelor de regresie, teste ce sunt create
pentru a verifica daca functionalitati importante ale aplicatiei se comporta la fel dupa
implementari noi in cod.

Figura 4.5. Pașii unui test de regresie care v -a fi automatizat

40 In următoarea parte am automatizat un test care se va loga la aplicatie, va cauta pe pagina
de search un folder de vanzari de autoturisme, cu un nume dat, in cazul in care acest fold er nu
exista, aplicatia va crea un folder nou, introducand toate datele obligatorii pentru creerea acestuia.
Odata ce folderul a fost creat, pagina acestuia v -a fi deschisa si se vor face anumite functii
pe aceasta, precum adaugarea unei date de receptie si adaugarea unui pret special de vanzari.

Figura 4.6. Test de regresie automatizat

Adnotarile reprezinta o informatie suplimentara asociata unei parti de document.
Adnotarea @Test este folosita pentru a specifica ca urmează sa dezvoltam un test.
@Test Data specifica ca vom prelua anumite date de intrare dintr -un fisier . yaml in care vor fi
trecute mai multe date de care vom avea nevoie mai apoi in testul nostru.

Pentru a testa un produs software avem nevoie de a introduce anumite date. Orice date
identificate care se folosesc in test sunt cunoscute ca “test data”. Funcție cu care vom prelua
datele din fișierele .yaml in testul nostru:

41 SalesVehicle salesVehicle = testdata(SalesVehicle.class);
Site site = testdata(Site.class);
BusinessPartne r bp = testdata(BusinessPartner.class);
String price = testdata("price");
LocalDate fromDate = testdata("fromDate");
LocalDate toDate = testdata("toDate");
LocalDate localDate = LocalDate.now();

Fisierul .yaml trebu ie sa aiba acelasi nume cu clasa de test. Aici vor fi adaugate toate
datele de care avem nevoie:

TestData:
SalesVehicle:
_include: forCreateNewVSF
Site:
_include: default
BusinessPartner:
_include: forCreateVehicle
String:
price: "10000"
LocalDate:
fromDate: { function: "RELATIVEDATE", expression: "NOW" }
toDate: { function: "RELATIVEDATE", expression: "NOW+1d" }

Firebug

În Selenium, programul recunoaște multiple elemente pe o pagină web și execută acțiuni
asupra lor. Pentru ident ificarea elementelor dintr -o pagină web se folosește Firebug, care este o
extensie adăugată browserului de Firefox. Identificarea elementelor din interfata este o
precondiție în scrierea testelor automate.

42
Figura 4.7. Identificarea unui element pe o p agină web cu ajutorul Firebug

//BEGIN:XPATH
private static final String SPECIAL_SALES_PRICE_NEW_BUTTON =
"specialSalesPriceNewButton";
//END:XPATH

public SalesVehicleAddPriceDialog openNewSpecialSalesPricesDialog()
{
$(SPECIAL_SALE S_PRICE_NEW_BUTTON).click();
return salesVehicleAddPriceDialog;
}
salesVehicleAddPriceDialogPrice=.//INPUT[starts -with(@id, 'price')

Assertion

In programarea computerelor, un assert este o afirmație conform căreia o funcție de
valoare booleana este întotdeauna adevărata la acel moment de execuție a codului. Acesta ajuta
testerul sa citească mai ușor codul, sa ajute un compilator sa compileze sau sa ajute programul sa –
si detecteze propriile defecte.
In cazul nostru cream un ass ert pentru a ne asigura ca ceea ce am creat este intradevar
valid.

assertThat(dateGrid.isSpecificCellExisting(localDate.format(DateTimeFormatter.ofPattern("dd/
MM/yyyy")))
||

43 dateGrid.isSpecificCellExisting(localDate.format(DateTimeFormatter.of Pattern("dd.MM.yyyy")))
)
.as("Checking that the expected reception date is visible")
.isTrue(); }

}

4. Rezultate experimentale

4.1. Metodologia Agile

44 Principiile Agile presupun colaborare , flexibilitate și adaptare. Sunt construite pe idea ca
lumea se schimba continuu, iar asta presupune ca echipele software nu mai au ani întregi pentru a
dezvolta noi produse, deoarece in tot acest timp ofertele competitorilor sau așteptările clienților se
pot schimba, iar echipa risca inconsecventa. Astfel, metodologia Agile micșorează acest risc,
susținând echipa sa colaboreze pentru a se adapta tuturor necesitaților, a -și asigura succesul și a
încuraja echipa de sa -și prezente munca cat mai regulat, pent ru a primii opinii și a se adapta
schimbărilor cat mai ușor și rapid.

Figura 4.1. Strategia testelor Agile

Pentru a urma aceasta metodologie testării trebuie sa urmeze următoarele imperative:
● Prioritizarea cerințelor, in funcție de riscul lor, având i n vedere ca nu este posibil ca totul sa fie
testat;
● Crearea testelor automate pentru creșterea eficientei;
● Sa se adapteze schimbarilor de la un sprint la altul [9]

4.2. Metodologia Agile in testare

Rational Team Concernt (RTC Jazz) este un tool folosit pentru a crea un mediu
colaborativ intre membrii unei echipe, unde toate noile implementari sunt impartite in mici task –
uri, atat pentru programatori cat și pentru testeri. Aceasta deține toate aspectele muncii fiecărui
membru al echipei, rapoarte, planifi cări, documentații despre tot ce include implementarea unei
noi componente in aplicația noastră.
Task -urile pot totodată sa fie mutate, in funcție de status -ul lor, acestea putând fi in starea
de Open, In progress, In review, In verification sau Done, ast fel fiecare membru al echipei poate
știi in ce stadiu se afla proiectul la momentul actual.

45

Figura 4.2 Pagina de RTC Jazz

4.3. Procedura de eliberare interna a datelor

Arta de a face commit

Git și platformele precum GitHub sau Bitbucket oferă unelt e care sa ne arata ceea ce s -a
schimbat la un commit. Mesajul de commit este o parte foarte importanta deoarece este singurul
loc in care ni se precizează nu doar ce s -a schimbat, ci și de ce. Acest mesaj trebuie sa fie unul
scurt, deoarece acesta poate fi văzut, de multe ori, într -un loc unde nu exista mult spațiu.

Cum ajunge un commit pe DEV?

Pentru ca un commit sa ajungă pe un anumit environment acesta trebuie sa fie pushed pe
Gerrit. Cand se executa acest lucru:
1. Commit -ul isi va schimba baza (rebase) pe branch -ul current de master.
2. Verifier -ul rulează pe branch -ul de master cu respectivul commit.
3. Verifier -ul trece cu succes.
4. Commit -ului ii este făcut un review si primește un calificativ (+2).
5. Commit -ul este merged pe master.

46
Figura 4.3. Compone nte de test care au fost incarcate pe Gerrit

Dupa ce datele au fost încărcate pe Gerrit și au fost merged, acestea sunt transmise către
Jenkins.
Daca in fiecare ora avem cate un commit , Jenkins:
1. Preia masterul cu cele mai noi commit -uri
2. Ruleaza un buil d si un deployment pe master.
3. Daca build -ul este verde înseamnă ca acesta a trecut cu succes.

47
Figura 1. Noile build -uri ce urmeaza sa fie deployed

ATARI

Atari ( Advanced Test Automation Report Instruments) este o aplicatie creata de firma
Catalysts in care se pot verifica rapoarte despre noile implementări. Aici putem vedea, in cazul
testelor automate, cate dintre ele au fost executate cu succes, au cauzat defecte, cate dintre ele
prezintă probleme, sau pur și simplu nu au trecut.

Figura 4.4. St atusul build -urilor care au fost deployed
5. Concluzii

48
In cadrul lucrării am pus in evidenta faptul ca testarea este foarte necesara in timpul
dezvoltării unui produs software, pentru a identifica defectele ce apar in urma noilor implementări
și pentru a ridica calitatea sistemului. Executarea cat mai multor teste ajuta la dezvoltarea
produsului de o calitate buna și care totodată oferă servicii corespunzătoare prin verificarea și
validarea metodelor aplicate produselor. Exista nenumărate tipuri de testar e care ne ajuta la
detectarea cat mai multor probleme care pot apărea in aplicația noastră, acestea verificând
funcționalitatile cat și comportamentul aplicației odată ce aceasta este folosita de către un
utilizator, depinde din ce punct de vedere este ac easta văzuta.
Testarea poate fi făcuta manual și automat, modalitatea aleasa ținând cont de costuri și de
timpul pe care ar trebui sa -l alocam pe anumite teste, iar dorința unui client e aceea de a
economisi cat mai mult și de a face o aplicație cat mai buna. Ambele tipuri de testare au
avantajele și dezavantajele lor, dar atâta timp cat acestea sunt făcute astfel încât atât bugetul cat și
timpul sa fie micșorat, vor fi tot timpul un avantaj.
Pentru testarea manuala nu avem nevoie de tool -uri, totul est e făcut de către tester.
Testarea automata necesita anumite tool -uri pentru ca munca sa ne fie ușurată și pentru a fi
executate testele cu succes. Cele trei resurse dintr -un proiect de testare automată sunt: codul,
datele de test, obiectele și definiția l or în cadrul aplicației aflată în proces de testare.
Tipurile de testare folosite variază in funcție de ceea ce ne interesează sa testam la
aplicația noastră, fiecare benefica in felul ei.
Testele de caz au un rol foarte important in procesul de testar e, întrucât acestea trebuie
urmărite pentru a reproduce problemele deja găsite sau pentru a documenta ceea ce a fost testat
deja și care au fost rezultatele. Documentele trebuie păstrate pe toată perioada de dezvoltare a
produsului, in cazul unei probleme, aceasta sa fie identificata mai ușor, economisind astfel atât
timp cat și bani.

6. Bibliografie

[1] Glenford J.Myers, The art of software testing, 3rd Edition

49
[2]https://www.qasymphony.com/blog/functional -testing -types/

[3]https://www.codeproject.com/Tips/351122/What -is-software -testing -What -are-the-diffe rent-ty

[4]Miguel Nabuco, Automation testing framework implementation for post -production and
broadcast HW/SW, Facultatea de Inginerie din Porto, 16 Iulie 2012

[5]https://www.thoughtworks.com/insights/blog/functional -tests-how-decide -what -automate

[6]https://www.mountaingoatsoftware.com/blog /the-forgotten -layer -of-the-test-automation –
pyramid

[7]https://drive.google.com/file/d/1ucpBhTdoX5plLbx -JNYqBPdqMrosvnFa/view

[8]https://drive.google.com/file/d/1mSxMm2UojeYdnVxeh22qIslKqJ38uq6y/view

[9]https://www.qasymphony.com/blog/agil e-methodology -guide -agile -testing/

[10]http://softwaretestingfundamentals.com/unit -testing/

[11]Advanced Sofware Testing,Vol 3, rockynook Computing, 2011

[12]http://softwaretestingfundamentals.com/integration -testing/

[13]http://softwaretestingfundamentals.com/test -case/

[14]http://softwaretestingfundamentals.com/system -testing/

[15]https://www.guru99.com/regression -testing.html

[16] Gayatri Ghan akota, Testing Frameworks, 29 Martie 201

[17]https://www.guru99.com/smoke -testing.html

[18]https://www.a picasystems.com/blog/automated -testing -vs-manual -testing/

[19]https://reqtest.com/testing -blog/functional -vs-non-functional -testing/

[20]https://www.softwaretestinghelp.com/how -to-test-application -security -web-and-desktop –
application -security -testing -techniques/

50
[21]https://www.interaction -design.org/literature/topics/usability -testing

[22]https://www.exp erienceux.co.uk/faqs/what -is-usability -testing/

[23]https://xbsoftware.com/qa -software -testing/full -qa-cycle/localization -testing/

[24]http://softwaretestingfundamentals.com/black -box-testing/

[25]https://en.wikipedia.org/wiki/IntelliJ_IDEA

[26]https://en.wikipedia.org/wiki/Oracle_SQL_Developer

[27]https://www.easterbrook.ca/steve/2010/11/th e-difference -between -verification -and-
validation/

[28]https://en.wikipedia.org/wiki/Assertion_(software_development)

[29] https://searchsoftwarequality.techtarget.com/definition/build

[30]https://www.testing -whiz.com/blog/types -of-non-functional -software -tests

[31]https://sisgain.com/automation -testing

[32]http://softwaretestingfundamentals.com/white -box-testing/

[33]https://wpdistrict.sitelock.com/blog/black -box-vs-white -box-part2 -sast/

[34]https://www.guru99.com /smoke -sanity -testing.html

[35]http://toolsqa.com/software -testing/manual -testing/