Avtomatiziranofunkcionalnotestiranjespletneaplikacije MihaˇStemberger

(1)

Univerza v Ljubljani

Fakulteta za raˇ cunalniˇ stvo in informatiko

Miha ˇ Stemberger

Avtomatizirano funkcionalno testiranje spletne aplikacije

DIPLOMSKO DELO

VISOKOˇSOLSKI STROKOVNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE

RA ˇCUNALNIˇSTVO IN INFORMATIKA

Mentor : doc. dr. Nejc Ilc

Ljubljana, 2021

(2)

To delo je ponujeno pod licenco Creative Commons Priznanje avtorstva-Deljenje pod enakimi pogoji 2.5 Slovenija (ali novejˇso razliˇcico). To pomeni, da se tako besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.

Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita programska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/

licenses/.

(3)

Kandidat: Miha ˇStemberger

Naslov: Avtomatizirano funkcionalno testiranje spletne aplikacije

Vrsta naloge: Diplomska naloga na visokoˇsolskem programu prve stopnje Raˇcunalniˇstvo in informatika

Mentor: doc. dr. Nejc Ilc

Opis:

Pri razvoju programske opreme se za zagotavljanje njene kvalitete posluˇzujemo razliˇcnih vrst testiranja. Ena izmed njih je funkcionalno testiranje, ki preverja pravilnost delovanja programske opreme na podlagi testnih primerov uporabe in vnaprej predpisanih zahtev. Roˇcno preverjanje testnih scenarijev je ˇcasovno zelo potratno, ˇse zlasti v kompleksnih aplikacijah. V diplomskem delu opiˇsite funkcionalno testiranje in raziˇsˇcite moˇznosti avtomatiziranega naˇcina testiranja. Izberite eno izmed brezplaˇcnih orodij za avtomatizirano funkcionalno testiranje in njegovo uporabnost ovrednotite na primeru razvoja spletne aplikacije. Ugotovite, kako se izbrano orodje vklaplja v ˇsirˇsi kontekst razvoja programske opreme, denimo v sistem neprekinjene integracije in neprekinjene dostave (ang. continuous integration and continuous delivery).

Title: Automated functional testing of a web application Description:

In software development, different types of testing are used to ensure the quality of the software. One of them is functional testing, which involves checking the behaviour of the software based on test use cases and defined specifications. However, manual review of test scenarios is very time consu- ming, especially for complex applications. In the thesis, describe functional testing and explore the possibilities of automated testing. Select one of the free tools for automated functional testing and evaluate its applicability in web application development. Find out how the chosen tool fits into the

(4)

broader context of software development, such as continuous integration and continuous deployment system.

(5)

Zahvaljujem se vsem, ki so mi pri opravljanju diplomskega dela kakorkoli pomagali. Posebna zahvala gre moji mami in ostalim druˇzinskim ˇclanom, za podporo in razumevanje skozi ˇstudijska leta. Zahvaljujem se doc. dr.

Nejcu Ilcu za vso potrpeˇzljivost, razumevanje, nasvete in hitro odzivnost pri mentoriranju diplomskega dela.

(6)

(7)

(8)

(9)

Kazalo

Povzetek Abstract

1 Uvod 1

2 Avtomatizirano testiranje 5

2.1 Zgodovina . . . 5

2.2 Tehnike testiranja . . . 6

2.3 Model V . . . 8

2.4 Ocenjevanje testnih primerov . . . 11

3 Orodja 13 3.1 Katalon Studio . . . 13

3.2 Katalon TestOps . . . 13

3.3 TeamCity . . . 14

3.4 Apache Maven . . . 14

4 Predstavitev aplikacije 17 4.1 Okolja . . . 17

4.2 Produkt . . . 17

4.3 Konfiguracija . . . 18

4.4 Tok nakupa . . . 18

(10)

5 Potek integracije 21

5.1 Posneti test . . . 21

5.2 Prve ugotovitve . . . 23

5.3 Prirejanje kode aplikacije . . . 26

5.4 Dinamiˇcni testni objekti . . . 29

5.5 Zagotavljanje edinstvenih atributov . . . 30

5.6 Branje vhodno/izhodnih testnih podatkov . . . 30

5.7 Integracija podatkovne baze . . . 36

5.8 Katalon TestOps . . . 38

5.9 Sistem neprekinjene integracije in dostave . . . 41

6 Sklepne ugotovitve 45

Clanki v zbornikihˇ 47

Celotna literatura 49

(11)

Seznam uporabljenih kratic

kratica angleˇsko slovensko API Application Programming In-

terface

Aplikacijski programski vme- snik

CD Continuous delivery Neprekinjena dostava CI Continuous integration Neprekinjena integracija CMS Content management system Sistem za upravljanje vsebin CSS Cascading Style Sheets Prekrivni slogi

CSV Comma-separated values Vrednosti, loˇcene z vejico DOM Document Object Model Objektni model dokumenta GDPR General Data Protection Re-

gulation

Sploˇsna uredba o varstvu podatkov

HTML HyperText Markup Language Jezik za oznaˇcevanje nadbesedila

JSF Java Server Faces Ogrodje, ki omogoˇca stan- darden razvoj Javanskih upo- rabniˇskih vmesnikov na strani streˇznika

JAR Java Archive Arhiv Java

POM Project Object Model Objektni model projekta SKU Stock Keeping Unit Enota za vodenje zalog QA Quality assurance Zagotavljanje kakovosti XML Extensible Markup Language Razˇsirljivi oznaˇcevalni jezik XPath XML Path Language Jezik poti XML

(12)

(13)

Povzetek

Naslov: Avtomatizirano funkcionalno testiranje spletne aplikacije Avtor: Miha ˇStemberger

Diplomsko delo opisuje potek integracije avtomatiziranega funkcionalnega testiranja spletne trgovine. Glede na predstavljene zahteve naroˇcnika je bilo uporabljeno orodje Katalon. Zaˇcnemo pri prvih korakih uporabe, kjer smo se razvijalci spoznavali z delovanjem in zmoˇznostmi orodja. Nadalju- jemo z reˇsevanjem odkritih problemov in optimizacijami za laˇzji razvoj ter vzdrˇzevanje testnih primerov. Zakljuˇcimo z integracijo Katalon TestOps, ki sluˇzi kot orodje za agregacijo rezultatov testiranj in umestitvijo pogona avtomatiziranih testnih skriptov v sistem neprekinjene integracije in dostave.

Kljuˇcne besede: avtomatizirano testiranje, Katalon, TeamCity, Katalon Studio, Katalon TestOps, spletna aplikacija.

(14)

(15)

Abstract

Title: Automated functional testing of a web application Author: Miha ˇStemberger

This thesis describes the integration of an automated functional testing tool for an online store. According to the requirements of the client, the Katalon tool was used. First, we present how the developers got to know the func- tionalities and capabilities of the tool. Next, we describe our approaches to solve the identified problems and implement optimizations to facilitate the development and maintenance of test cases. Finally, we conclude with the integration of Katalon TestOps, which serves as a tool for aggregating test results and executing automated test scripts in continuous integration and delivery system.

Keywords: automated testing, Katalon, TeamCity, Katalon Studio, Kat- alon TestOps, web application.

(16)

(17)

Poglavje 1 Uvod

Zaradi iterativne narave razvoja programske opreme postane kodna osnova sˇcasoma vedno bolj kompleksna. Nadgrajevanja, optimizacije in popravki doloˇcenih delov kode tako vplivajo na ostale funkcionalnosti aplikacije. Prva stopnja preverjanja pravilnosti delovanja spremenjene programske kode je test posameznih komponent (angl. unit testing). Naslednja stopnja preverjanja zajema integracijske teste, ki preverjajo pravilnost delovanja komponent, ko so te povezane z ostalimi komponentami. Ko pa postane obseg testiranja ˇsirˇsi, se pojavi potreba po funkcionalnem testiranju.

Funkcionalno testiranje je namenjeno preverjanju, ali se aplikacija pravilno obnaˇsa. Testni primeri (angl. test case) so sestavljeni iz predvidenih akcij, ki jih bo uporabnik izvedel, da bo dosegel svoj cilj. Ce za primerˇ vzamemo vpis na spletno mesto, so osnovne akcije, ki jih uporabnik izvede, naslednje: odpre brskalnik, navigira na vpisno stran, vnese uporabniˇsko ime, vnese geslo in pritisne gumb za prijavo. Skupek teh akcij predstavlja testni primer, katerega rezultat je lahko uspeˇsna prijava ali pa opozorilo o neuspeˇsni prijavi. Veˇc testnih primerov skupaj predstavlja preskuˇsalni niz (angl. test suite). V resniˇcnosti se seveda med izvajanjem teh akcij lahko zgodi cela paleta nepredvidenih napak na strojni ali programski opremi sistema. Kakorkoli, pri funkcionalnem testiranju ne izvajamo obremenitvenih testov posameznih strojnih ali programskih komponent sistema, temveˇc ugo-

1

(18)

2 Miha ˇStemberger tavljamo pravilnosti izvajanja zaporedja uporabniˇskih akcij. Na voljo sta roˇcno in avtomatizirano testiranje.

Pri roˇcnem testiranju mora oseba sama izvajati preverjanje pravilnosti rezultatov akcij. Zaradi ˇcloveˇske narave ta postopek pogosto vodi v napake, je ˇcasovno potraten in poslediˇcno finanˇcno neuˇcinkovit.

Avtomatizirano testiranje odpravlja omenjene slabosti roˇcnega postopka, hkrati pa predstavlja nove izzive, ki jih moramo nasloviti. Kot je bilo reˇceno, je razvoj programske opreme iterativen, to pomeni, da moramo spremem- bam v aplikaciji primerno prilagajati tudi testne primere, v kolikor je to potrebno. Zelo priporoˇceno je, da se na avtomatizirano testiranje pomisli na zaˇcetku razvoja, saj tako aplikacijo prilagajamo tudi orodju, ki bo izvajalo avtomatizirano testiranje.

Priloˇznost integracije orodja za avtomatizirano testiranje funkcionalnosti aplikacije sem dobil pri opravljanju svojega dela v podjetju Parsek d.o.o.

Integracija je bila narejena v okviru projekta razvoja spletne trgovine ponudnika mobilnih in spletnih storitev, kjer lahko opravimo nakup naprave, naroˇcniˇskih mobilnih paketov ali internetnih paketov. Uporabnik lahko iz ponujenih izdelkov in storitev sam sestavi svojo konfiguracijo. Pobuda za uvedbo avtomatiziranega testiranja je nastala zaradi ponavljajoˇcih se scenarijev, kjer se je preverjalo, ali so cene konfiguracij pravilno prikazane. Ker pa je cena bolj kot ne konˇcni rezultat doloˇcenih akcij, se je tako preverjala pravilnost obnaˇsanja aplikacije. Na strani lahko neko konfiguracijo sesta- vimo na veˇc naˇcinov, kar pa koliˇcinsko predstavlja prevelik zalogaj za roˇcno testiranje.

V podjetju smo sestavili naslednje kriterije, katerim mora zadostiti izbrano orodje:

• podpira testiranje mobilnih aplikacij,

• podpira testiranje spletnih aplikacij,

• lahko ga uporablja oseba brez obseˇznejˇsega poznavanja programiranja,

(19)

Diplomska naloga 3

• lahko ga umestimo v sistem za neprekinjeno integracijo in dostavo (ang.

continuous integration and continuous delivery - CI/CD),

• je brezplaˇcno.

Na podlagi naˇsega predhodnega znanja in izkuˇsenj, smo se odloˇcili, da izbor zoˇzimo na Katalon [8] in Selenium [12]. Selenium je uporabno orodje in lahko z njim doseˇzemo zelo veliko, je pa bolj primerno za uporabnike, ki se jim ni neprijetno sreˇcati s pisanjem kode. Predstavlja samo delˇcek celote in lahko nanj gledamo kot na knjiˇznico. Uporaba programskih vmesnikov orodja Selenium je dostopna v razliˇcnih programskih jezikih, kar olajˇsa njegovo integracijo z ostalimi ogrodji za testiranje. Ena od naˇsih zahtev je bila, da mora biti orodje primerno tudi za neprogramerje, zato smo se odloˇcili, da bomo funkcionalno testiranje izvedli z orodjem Katalon. Katalon deluje na osnovi Seleniuma in nam tako zagotovi najboljˇso kombinacijo obeh. Skupaj s svojim integriranim razvojnim okoljem poskrbi za lepˇso in enostavnejˇso uporabniˇsko izkuˇsnjo. Hkrati tudi dopuˇsˇca, da bolj programersko naravnani uporabniki razvijajo pripomoˇcke, s katerimi si bodo olajˇsali integracijo. Raz- vijanje poljubnih pripomoˇckov je v Katalonu omejeno na programska jezika Java in Groovy.

(20)

4 Miha ˇStemberger

(21)

Poglavje 2

Avtomatizirano testiranje

Avtomatizirano testiranje je dandanes ena izmed nepogreˇsljivih komponent razvoja programske opreme. S prenosom ponavljajoˇcih se testnih opravil na stroj se z avtomatiziranimi testi pridobi doloˇcene priloˇznosti in nove izzive.

Prednosti v veliki veˇcini pokrijejo stvari, kjer smo ljudje zaradi svoje narave omejeni. To so recimo: ˇcasovna omejenost, nekonsisenˇcnost in izguba zani- manja zaradi ponavljajoˇcih nalog. Stroj lahko izvaja isto nalogo stokrat na dan, jo opravi ob dveh zjutraj ali enajstih zveˇcer in vedno s toˇcno doloˇcenimi podatki. Tako se lahko oseba, zadolˇzena za testiranje, posveti roˇcnemu preverjanju bolj robnih primerov.

2.1 Zgodovina

Soˇcasno se je skupaj z napredki v razvoju programske opreme razvijalo tudi njeno testiranje. V zaˇcetkih, ko je bil razvoj programske opreme namenjen obseˇznejˇsim znanstvenim in obrambnim programom, se je testiranje roˇcno izvajalo na koncu ˇzivljenjskega cikla projekta. Testni scenariji so preverjali kontrolne poti izvajanja in raˇcunanja kompleksnih algoritmov, kar pa je pomenilo, da je lahko konˇcni nabor testov pokril testiranje celotnega sistema. Prihod osebnih raˇcunalnikov je povzroˇcil uvedbo razliˇcnih standardov, ki so vplivali na razvoj programske opreme. Z napredkom je tako arhitek-

5

(22)

6 Miha ˇStemberger tura sistema postala vedno veˇcja in s tem tudi obseg testiranja. Tako so se zaˇceli pojavljati koncepti in reˇsitve avtomatiziranega testiranja, ki so se osredotoˇcili na testne scenarije, ki pokrijejo najbolj uporabljene dele programske reˇsitve [5]. V literaturi je avtomatizirano testiranje prviˇc omenjeno leta 1962 [11].

2.2 Tehnike testiranja

Glede na poznavanje in moˇznosti vpogleda v programsko opremo poznamo tehnike bele, ˇcrne in sive ˇskatle.

2.2.1 Bela ˇ skatla

Tehnika testiranja po principu bele ˇskatle (angl. white-box testing), ki je predstavljena na Sliki 2.1, je tako poimenovana zato, ker ima izvajalec testov znanje in celoten vpogled v notranjost programske opreme. Na podlagi tega znanja bo lahko sestavil pogoje, ki jih bodo testni primeri preverjali. Taka tehnika je izvedena v testih enot.

Slika 2.1: Bela ˇskatla

2.2.2 Crna ˇ ˇ skatla

Crna ˇskatla, predstavljena s Sliko 2.2, je ˇˇ cisto nasprotje tehniki bele ˇskatle.

Tukaj izvajalec testov nima nobenega vpogleda in znanja o delovanju pro-

(23)

Diplomska naloga 7 gramske opreme. Fokus te tehnike je na preverjanju vhodno-izhodnih podatkov in v celoti temelji na zahtevah ter specifikacijah programske opreme.

Uporabljena je v korakih sprejemnega testiranja in testiranja sistema.

Slika 2.2: ˇCrna ˇskatla

2.2.3 Siva ˇ skatla

Na Sliki 2.3 je predstavljena tehnika sive ˇskatle, kjer ima izvajalec testov nekaj znanja o delovanju programske opreme. Ta tehnika je kombinacija bele in ˇcrne ˇskatle in je v veˇcini prisotna v integracijskih testih.

Slika 2.3: Siva ˇskatla

(24)

8 Miha ˇStemberger

2.3 Model V

Model V, viden na Sliki 2.4, predstavlja testne nivoje v povezavi z razvojem projekta. Lahko ga razdelimo na dve fazi: na levi strani je faza definicije projekta in na desni strani faza testiranja projekta. V fazi definicije projekta morajo koraki poskrbeti za oblikovanje testnih primerov, s katerimi se bo v fazi testiranja preverjalo pravilnost izvedbe. Odkritje nepravilnosti v poznejˇsih nivojih testiranja ima veˇcji vpliv na celoten sistem in je zaradi tega potrebno imeti vnaprej definirane sprejemne pogoje. Vsi koraki v fazi testiranja, razen korak sprejemnega testiranja, imajo moˇznost uvedbe avto- matizacije testiranja.

Slika 2.4: Model V

2.3.1 Testiranje enot

Testiranje enot se navezuje na preverbo funkcionalnosti posamezne komponente v sistemu. Vzorˇcni testni primer bi lahko preverjal delovanje metode razvrstiPoVelikosti, ki z uporabo enega izmed sortirnih algoritmov podan seznam ˇstevilk razvrsti od najmanjˇse do najveˇcje. V testu enote izvedemo

(25)

Diplomska naloga 9 klic metode razvrstiPoVelikosti([1,6,4]) in rezultat primerjamo z vrednostjo, ki je priˇcakovana ([1,4,6]). ˇCe bo v prihodnosti sortirni algoritem v metodi zamenjan, priˇcakujemo, da bo rezultat isti. Test je tako prisoten v struk- turi projekta in se bo ob gradnji projekta avtomatsko izvedel ter razvijalca opozoril na neskladnosti.

2.3.2 Integracijsko testiranje

Integracijsko testiranje je namenjeno preverjanju delovanja povezanosti enot, bodisi med zunanjimi ali notranjimi. Tukaj je poudarek na prenosu podatkov med enotami.

Za primer si poglejmo kodo 2.1. V trenutni razliˇcici kode ima enota A metodo foo, ki lahko kot parameter prejme statusa OK in ERROR. Enota B ima metodo bar, ki v trenutni razliˇcici lahko vrne statusa OK in ER- ROR. Nato imamo enoto C z metodo foobar, ki najprej pokliˇce Status re- zultatBarMetode = B.bar(); in rezultat uporabi kot vhodni podatek metode A.foo(rezultatBarMetode);. V metodi B.bar se z naslednjo razliˇcico omogoˇci vraˇcanje statusa WARNING, ker pa metoda A.foo trenutno ne razume tega statusa, bo v integracijskem testu priˇslo do napake. Prav tako kot pri testih enot se lahko integracijski testi po implementaciji zaganjajo ob vsaki gradnji projekta.

1 Enota A {

2 Metoda f o o ( S t a t u s s t a t u s ) {

3 // i m p l e m e n t a c i j a d e l o v a n j a

4 }

5 }

6

7 Enota B {

8 Metoda bar ( ) {

9 // i m p l e m e n t a c i j a d e l o v a n j a

10 }

11 }

(26)

10 Miha ˇStemberger

12

13 Enota C {

14 Metoda f o o b a r ( ) {

15 S t a t u s r e z u l t a t B a r M e t o d e = B . bar ( ) ;

16 A. f o o ( r e z u l t a t B a r M e t o d e ) ;

17 }

18 }

Izvorna koda 2.1: Demonstracija integracije enot

2.3.3 Testiranje sistema

Testiranje sistema lahko vkljuˇcuje veˇc tipov testiranja, ki so uvedeni po po- trebi. Primer so lahko: funkcionalno testiranje, regresijsko testiranje, obremenitveno testiranje itd. [13]

Obremenitveno testiranje je namenjeno preverjanju stabilnosti in zaneslji- vosti sistema. Primer orodja, ki to omogoˇca, je Apache JMeter [1]. Z orodjem JMeter simuliramo ˇstevilo uporabnikov po meri in izoblikujemo ˇzeljen scena- rij testiranja. S tem odkrijemo ozka grla, ki se pojavijo ˇsele ob veˇcjem ˇstevilu ukazov in kritiˇcne toˇcke odpovedi sistema, preden je ta na voljo javnosti.

Funkcionalno testiranje je namenjeno preverjanju funkcionalnosti sistema.

Ceprav je izrazˇ funkcionalno testiranje lahko predstavljen na razliˇcne naˇcine in pomeni marsikaj, bo v tem diplomskem delu uporabljen v obsegu regresij- skega testiranja, ki preverja delovanje funkcionalnosti aplikacije po uvedbah sprememb. V primeru, da se med regresijskimi testi odkrije napako, to pomeni, da je priˇslo do regresije/nazadovanja sistema [4].

2.3.4 Sprejemno testiranje

Sprejemno testiranje je zadnji korak pred namestitvijo programske reˇsitve na produkcijsko okolje. Tukaj se z naroˇcniki preveri, ali so bili vsi potrebni zahtevki implementirani in vse deluje kot naroˇceno. Moˇznost je tudi, da tukaj testiranje izvajajo konˇcni uporabniki.

(27)

Diplomska naloga 11

2.4 Ocenjevanje testnih primerov

Testni primer se lahko oceni na podlagi tega, kako je uˇcinkovit, ekonomiˇcen, lahek za vzdrˇzevanje in uporaben [6]. Uˇcinkovitost je merjena na podlagi zmoˇznosti odkrivanja nepravilnosti. Ekonomiˇcnost lahko predstavljata iz- vedba in analiza testa. Lahkotnost vzdrˇzevanja opisuje vloˇzeni trud, ki je potreben ob spremembah programske opreme. Glede na zmoˇznost uporabe v razliˇcnih testnih nizih se oceni uporabnost testnega primera. Dober primer bi za to bil test, ki preverja funkcionalnost za vpis v spletno mesto, ker je predpogoj za mnoge druge funkcionalnosti in bo zato uporabljen v veliko testnih nizih. Navedeni atributi testa so v veˇcini primerov med seboj povezani in uravnoveˇsajo en drugega. Na Sliki 2.5 je prikazana primerjava med roˇcnim in avtomatiziranim testnim primerom. Pri roˇcnem testiranju bodo vrednosti atributov ˇcez ˇcas ostale nespremenjene. Na zaˇcetku uporabe avtomatiziranega testnega primera bo ekonomiˇcnost vedno slabˇsa, kot ˇce bi test izvedli roˇcno. Ekonomiˇcnost avtomatiziranega testnega primera se pojavi ˇsele po veˇckratni uporabi, njegova lahkotnost vzdrˇzevanja pa bo v veˇcini primerov slabˇsa v primerjavi z roˇcnim testiranjem.

(28)

Slika 2.5: Graf ocene testnega primera

(29)

Poglavje 3 Orodja

3.1 Katalon Studio

Katalon Studio je orodje za avtomatizacijo testiranja. S svojim integriranim razvojnim okoljem poskrbi za enostavno uporabo in dopuˇsˇca naprednim uporabnikom razvoj pripomoˇckov po meri. Uporablja metodologijo testiranja s kljuˇcnimi besedami (angl. keyword), ki je primerna tako za roˇcno kot avtomatizirano testiranje. Kljuˇcne besede so uporabljene za opis akcij, ki jih bo testni primer izvedel za preverbo doloˇcene funkcionalnosti sistema [14].

Razvoj poljubnih kljuˇcnih besed je omejen na programska jezika Java in Groovy.

3.2 Katalon TestOps

Predhodnik Katalon TestOps je bilo orodje Katalon Analytics, ki je bilo namenjeno analizi in pregledu testnih rezultatov. Katalon TestOps je nadgradnja Katalon Analytics in poleg analitiˇcnih funkcionalnosti omogoˇca naˇcrtovanje, nadzor in izvedbo testov.

13

(30)

3.3 TeamCity

TeamCity je sistem za neprekinjeno integracijo, ki ga je razvilo podjetje Jet- Brains. Kot streˇznik za neprekinjeno integracijo lahko zazna spremembe v sistemih za upravljanje razliˇcic (angl. version control) in sproˇzi gradnjo projekta z dodanimi spremembami. Gradnja lahko vkljuˇcuje prevajanje iz- vorne kode, pogon testiranja enot in integracijskih testov, prenos zgrajenih izvrˇsljivih datotek na okolje, kjer se lahko izvedejo funkcionalni testi in izpo- stavi artefakte (angl. artifact) za prenos [9]. Artefakt je nekaj, kar projekt uporablja ali ustvari [7]. Primer artefakta je datoteka arhiva Jave (angl. Java Archive - JAR) [10].

3.4 Apache Maven

Maven je orodje za avtomatizacijo gradnje projekta, ki se uporablja predvsem za projekte v jeziku Java. Obravnava dva vidika gradnje programske opreme:

kako se programska oprema gradi in njene odvisnosti (angl. dependency).

Objektni model projekta (angl. Project Object Model - POM) opisuje projekt programske opreme, ki se gradi, njegove odvisnosti od drugih zunanjih modulov in komponent, vrstni red gradnje, imenike in zahtevane vtiˇcnike.

Ponuja vnaprej doloˇcene cilje za izvajanje nekaterih natanˇcno doloˇcenih nalog. Maven dinamiˇcno prenaˇsa knjiˇznice Java in vtiˇcnike Maven iz enega ali veˇc skladiˇsˇc, kot je centralno skladiˇsˇce Maven 2, in jih shrani v lokalni repozitorij. Ta lokalni predpomnilnik prenesenih predmetov je mogoˇce posodobiti tudi z artefakti, ustvarjenimi z lokalnimi projekti [2]. Primer objektnega modela projekta je viden s kodo 3.1.

1 <p r o j e c t xmlns=” h t t p : //maven . apache . o r g /POM/ 4 . 0 . 0 ”

2 x m l n s : x s i=” h t t p : //www. w3 . o r g /2001/XMLSchema− i n s t a n c e ”

3 x s i : s c h e m a L o c a t i o n=” h t t p : //maven . apache . o r g / POM/ 4 . 0 . 0 h t t p : //maven . apache . o r g /maven−v 4 0 0 . xsd ”>

(31)

Diplomska naloga 15

4 <m o d e l V e r s i o n>4 . 0 . 0</ m o d e l V e r s i o n>

5 <g r o u p I d>o r g . example</ g r o u p I d>

6 <a r t i f a c t I d>primer−pom−p r o j e c t</ a r t i f a c t I d>

7 pom

8 <name>Moj t e s t n i POM</name>

9 <version>1.0−SNAPSHOT</version>

10 <d e s c r i p t i o n>

11 Primer d a t o t e k e pom . xml

12 </ d e s c r i p t i o n>

13 <modules>

14 <module>c o r e</ module>

15 <module>e x a m p l e s</ module>

16 </ modules>

17

18

19 t e s t

20

21

22 <d e p e n d e n c i e s>

23 <dependency>

24 <g r o u p I d>j a k a r t a . j s o n</ g r o u p I d>

25 <a r t i f a c t I d>j a k a r t a . j s o n−a p i</ a r t i f a c t I d>

26 <version>1 . 1 . 6</version>

27 </ dependency>

28 </ d e p e n d e n c i e s>

29

Izvorna koda 3.1: Primer datoteke POM

(32)

(33)

Poglavje 4

Predstavitev aplikacije

Spletna aplikacija, v kateri je bilo integrirano orodje za avtomatizirano testiranje, je spletna trgovina ponudnika mobilnih in internetnih storitev. Omogoˇca nakup razliˇcnih naprav, naroˇcniˇskih mobilnih paketov ali internetnih paketov. V nadaljevanju tega poglavja bodo predstavljene glavne zasnove aplikacije, ki so vplivale na potek integracije.

4.1 Okolja

Projekt za delovanje uporablja tri okolja: razvojno, testno in produkcijsko.

Razvojno okolje je lahko osebni raˇcunalnik razvijalca na projektu. Okolje, kjer se s strani stranke potrjujejo implementacije, je testno. Ob potrditvi in pravilnem delovanju implementiranih zahtevkov se na koncu ti prenesejo na produkcijo, kjer so vidni obiskovalcem strani.

4.2 Produkt

Produkt lahko opiˇsemo kot glavno entiteto podatkovnega modela. Najbolje je, da si bralec predstavlja produkt kot nekaj abstraktnega, saj iz njega izhajajo bolj specifiˇcno definirani objekti, kot so telefon, promocija, opcija, paket, vezava.

17

(34)

18 Miha ˇStemberger Na sebi ima razliˇcne identifikatorje, ki pa so lahko glede na okolje razliˇcni.

Identifikator, ki je vedno isti na vseh okoljih, je enota za vodenje zalog (angl.

stock keeping unit - SKU). Uporabil se je zaradi potrebe po edinstvenih elementih v jeziku za oznaˇcevanje nadbesedila (angl. HyperText Markup Language - HTML). Veˇc o tem je opisano v poglavju 5.3.

4.3 Konfiguracija

Konfiguracija je glavni objekt, ki v sebi nosi mnoˇzico produktov in podatke, potrebne za nakup. Kot primer si lahko na Sliki 4.1 pogledamo sestavo konfiguracije. Na zaˇcetku se nahaja predel Mobilne storitve, kjer lahko opazimo prisotnost mobilnega paketa A1 Go! M. Nato imamo predel Naprava, ki nakazuje, da je naprava, ki pripada konfiguraciji mobilni telefon Samsung Galaxy S21 Ultra 256 GB. SledijoDodatne opcije, v tem primeru zavarovanje mobilne naprave. Na koncu je prikazan informativni prikaz cene prikljuˇcnine.

Za produkte je tudi prikazana njihova koliˇcina, enkraten znesek in meseˇcni znesek. Na dnu je seˇstevek zneskov takojˇsnjega, meseˇcnega in prvega plaˇcila.

Ta prikaz informacij bo uporabljen pri potrjevanju pravilnosti cen.

4.4 Tok nakupa

Tok nakupa predstavljajo strani spletnega mesta, skozi katere lahko potujemo glede na izvedene akcije in stanje trenutne konfiguracije. Strani so v veˇcini med seboj ohlapno povezane, saj se vsebina obiskane strani obnaˇsa primerno temu, kar je v konfiguraciji. To pomeni, da je vstop v tok nakupa mogoˇc na veˇc mestih. Na Sliki 4.2 je v grobem predstavljen koncept.

Cilj toka nakupa je vedno zakljuˇcni nakupni proces (angl. checkout), ta pa je sam po sebi prav tako sestavljen iz veˇc strani. V nakupni proces lahko uporabnik vstopi samo z veljavno konfiguracijo. Tam je pozvan k izpolnitvi obrazcev, ki mu bodo predstavljeni. Obrazci lahko pokrivajo vnos osebnih podatkov, soglasje s sploˇsno uredbo o varstvu podatkov (angl. General Data

(35)

Diplomska naloga 19 Protection Regulation - GDPR), izbiro nove telefonske ˇstevilke ali prenosa telefonske ˇstevilke, naˇcin plaˇcila in dostave. Po izpolnitvi obrazcev se uporabniku prikaˇze povzetek nakupa, kjer so spet, podobno kot v koˇsarici na Sliki 4.1, prikazane cene naprav ter zneski plaˇcila. ˇCe se po pregledu podatkov uporabnik odloˇci za nadaljevanje nakupa, je po povzetku naroˇcila preusmerjen na zahvalno stran, kjer je lahko prikazano opozorilo, da je bilo z naroˇcilom nekaj narobe ali pa da je z njim vse v redu.

Slika 4.1: Koˇsarica

Slika 4.2: Tok nakupa

(36)

(37)

Poglavje 5

Potek integracije

To poglavje opisuje potek integracije avtomatiziranega testiranja z uporabo orodja Katalon. Opisani bodo zaˇcetni koraki uporabe, spoznanja, teˇzave in njihovo reˇsevanje. Med drugim bodo predstavljene tudi uporabljene komponente integriranega razvojnega okolja Katalon Studio (v nadaljevanju: Ka- talon Studio IDE).

5.1 Posneti test

Pristop s posnetkom testa omogoˇca uporabniku zelo prijazno uvajanje k spo- znavanju avtomatiziranih testnih skriptov. Z uporabo spletnega snemalnika, vidnega na Sliki 5.1, ki je dostopen v Katalon Studio IDE, smo najprej pov- praˇsani po naslovu strani, na kateri ˇzelimo zaˇceti posnetek in brskalniku, ki ga bomo uporabili. Po kliku na gumb Record se avtomatsko ustvarita akciji Open Browser, ki odpre izbrani brskalnik, za njo pa ˇse akcijaNavigate To Url ki nas navigira na naslov, ki je bil podan v prvem koraku. Akcije so v skriptu predstavljene s kljuˇcnimi besedami. Kljuˇcno besedo si je najbolje predsta- vljati kot klic metode ali funkcije, ki jih skripti lahko uporabijo. ˇCe ˇzelimo, lahko ustvarimo svoje kljuˇcne besede, kot na primer nakazuje koda 5.1.

1 @Keyword

21

(38)

2 d e f p o c a k a j N a C e l o t n o S t r a n ( ) {

3 WebUI . waitForPageLoad ( 1 0 )

4 }

Izvorna koda 5.1: Primer kljuˇcne besede

Slika 5.1: Spletni snemalnik

Na Sliki 5.2 je vidno, kako brskalnik opozori uporabnika, da je brskalnik, v katerem se izvaja snemanje, pod tujim nadzorom.

Slika 5.2: Opozorilo brskalnika, da je pod nadzorom snemalnika

(39)

Diplomska naloga 23 Sedaj lahko na spletni strani izvajamo poljubne akcije. Ko smo z ˇzelenim potekom akcij zakljuˇcili, je treba skript shraniti in tako ga imamo na voljo za ponovno uporabo.

5.2 Prve ugotovitve

Za zaˇcetni prototip testa je bil izbran tok nakupa, ki je na prvi pogled dokaj enostaven. Uporabil se je pristop s posnetim testom, ki je opisan v poglavju 5.1. Vstopna toˇcka toka nakupa je na strani s seznamom naprav, ki je viden na Sliki 5.3. Naslednji korak je izbira naprave s seznama, ki se zgodi ob kliku na gumbPreveri. S pritiskom na gumb smo prestavljeni na detajlno stran naprave, vidno na Sliki 5.4. Tukaj lahko na veˇc naˇcinov nadaljujemo tok nakupa. Najkrajˇsi je samo nakup naprave, ki ga izberemo s klikom na gumb Kupi samo napravo. Na Sliki 5.5 je prikazano modalno okno, ki se prikaˇze ob kliku in omogoˇca navigacijo v koˇsarico ali nadaljevanje pregleda trenutne strani. Naˇs cilj je bil, da konˇcamo testni primer v koˇsarici.

Po opravljenem posnetku testa, smo tega tudi ponovno pognali. Prva opaˇzena teˇzava je bila, da skript ne poˇcaka, da bi se stran v celoti naloˇzila.

Posledica je napaka ob pridobivanju objekta, na katerem naj bi se izvedla akcija, ker objekt (ˇse) ne obstaja v objektnem modelu dokumenta (angl.

Document Object Model - DOM). Zaradi tega smo po vsakem kliku na sidro ali gumb dodali kljuˇcno besedo Wait For Page Load, ki poˇcaka doloˇceno ˇstevilo sekund, da se stran naloˇzi v celoti.

Po ponovnem zagonu testa se je ta nekajkrat izvedel do konca, ampak veˇcinoma neuspeˇsno. Teˇzava je bila, da se na strani pojavljajo razliˇcna modalna okna, kot na primer nakazuje slika 5.5. Modalna okna imajo v glavnem eno teˇzavo in ta je, da modalno okno potrebuje nekaj ˇcasa za prikaz in za- prtje. V obeh primerih je treba poˇcakati na prisotnost in vidnost elementa, na katerem ˇzelimo izvesti akcijo. ˇCeprav se lahko nekatera okna prikaˇzejo nepriˇcakovano, je funkcionalnost oken takˇsna, da se po zaprtju ne bodo veˇc prikazala brez posega uporabnika. Problem smo reˇsili tako, da ob prvem na-

(40)

Slika 5.3: Seznam naprav

laganju strani s kljuˇcnima besedama Wait For Element Present inWait For Element Visible poˇcakamo na obstoj in prikaz elementa, s katerimi potem okno zapremo. Ob zaprtju okna prav tako poˇcakamo z kljuˇcno besedo Wait For Element Not Visible, da se okno v celoti odstrani iz ospredja.

Z zadovoljivimi rezultati pri pogonu testa je bil naslednji korak podrob- nejˇsi pregled izvoˇzenih testnih objektov. Kot je vidno na Sliki 5.6, se ob

(41)

Diplomska naloga 25

Slika 5.4: Detajlna stran naprave

shrambi skripta, poleg seznama izvedenih akcij, izvozijo tudi testni objekti, na katerih so bile akcije izvedene. S strani delovanja ni s tem niˇc narobe, ˇce se pa pogleda s strani vzdrˇzevanja, to ob veˇcjem ˇstevilu testov postane nepregledno in poslediˇcno oteˇzi vzdrˇzevanje.

Zajeti testni objekti na sebi vsebujejo lokatorje, s katerimi kontekstni element najdemo v dokumentu HTML. Ob zajemu se avtomatsko uporabi eden izmed lokatorjev, ki se orodju zdi najbolj primeren. Lokator je odvisen

(42)

Slika 5.5: Modalno okno nakupa naprave

od strukture dokumenta HTML in je zato potrebno imeti ustrezno oznaˇcene kljuˇcne komponente, na katerih se bodo izvajale akcije.

Po pregledu prototipne verzije testnega skripta so bili zadani naslednji cilji:

• opremiti elemente HTML z ustreznimi podatki, ki bodo omogoˇcili ge- neriranje edinstvenih lokatorjev,

• uporabiti pristop dinamiˇcni testnih objektov.

5.3 Prirejanje kode aplikacije

Kot je predstavljeno v poglavju 5, izvoˇzeni objekti testnih skriptov dosto- pajo do elementov HTML z uporabo lokatorjev. Bolj podrobno si bomo v nadaljevanju pogledali lokator XPath.

XPath uporablja sintakso, ki omogoˇca fleksibilen naˇcin kreacije kazalcev na razliˇcne dele dokumenta razˇsirljivega oznaˇcevalnega jezika (angl. Extensi-

(43)

Diplomska naloga 27

Slika 5.6: Repozitorij objektov

ble Markup Language - XML). Ima zelo dober naˇcin za navigacijo po DOM-u kateregakoli dokumenta, ki ima XML-ju podobno strukturo [3].

Ob zajemu objekta se do kontekstnega elementa ustvari veˇc lokatorjev XPath. V primeru, da element, katerega iˇsˇcemo, ne zaznamuje nekaj edin- stvenega, bo do njega zgeneriran zelo nezanesljiv lokator XPath. Kot slabˇsi primer si lahko pogledamo primer prikazan s kodo 5.2.

1 ( . / /∗[ t e x t ( ) =’We Care About Your Health ’ ] ) [ 1 ] / f o l l o w i n g : : a [ 1 ] )

Izvorna koda 5.2: Slab primer XPath

Da bomo razumeli, kaj omenjeni XPath poˇcne, ga bomo predstavili po veˇc delih. (.//*[text()=’We Care About Your Health’]) ˇzeli v dokumentu HTML najti vse elemente, ki vsebujejo besedilo We Care About Your Health. Ker nam prvi del vraˇca seznam elementov, imamo potem[1], s katerim naslovimo prvi element v seznamu. /following::a poiˇsˇce vsa sidra, ki so v dokumentu za kontekstnim elementom in potem spet z[1] najdemo prvi element v seznamu pridobljenih sider. Omenjen XPath je zaradi dinamiˇcne narave aplikacije zelo nezanesljiv. ˇCe nekdo zamenja besedilo, da bo namestoWe Care About Your Health pisalo We Care About You, bo test padel. Isto se zgodi, ko bo zaradi prenove sidro postavljeno pred element, ki vsebuje besedilo. /following::a[1]

(44)

28 Miha ˇStemberger bo v tem primeru dobil neˇzeleni element dokumenta HTML in test ne bo uspeˇsen. Boljˇsi primer je prikazan s kodo 5.3.

1 ( / / a [ @id=’ btn−make−appointment ’ ] )

Izvorna koda 5.3: Dober primer XPath

Vse, kar se tukaj zgodi, je to, da poiˇsˇcemo sidro, katerega vrednost atributaid je btn-make-appointment. Ob uporabi atributaid, mora ta vsebovati vrednost, ki v dokumentu HTML edinstveno predstavlja element. Ni nujno, da z lokatorjem ciljamo na id, ampak na nekaj, kar edinstveno predstavlja element. V naˇsem primeru atribut id ni priˇsel v poˇstev, ker se elementom zaradi uporabljenih tehnologij ti dinamiˇcno generirajo. Veˇc o teˇzavi in reˇsevanju tega, je opisano v poglavju 5.5. Ne samo zaradi te ovire, ampak tudi, kerid sam po sebi ne predstavlja nobene povezave s testiranjem, smo se odloˇcili uporabiti atribut po meri. ˇZeleli smo, da atribut imensko namiguje na povezavo s testiranjem in se tako odloˇcili zadata-qa, kar naj bi namigovalo na zagotavljanje kakovosti (angl. Quality assurance - QA).

V poglavju 4.2 je bil predstavljen produkt, katerega edinstveno predstavlja vrednost SKU. Omenjeno vrednost se je tako uporabilo za vrednost atributa data-qa, kot je prikazano s kodo 5.4.

1 <a href=” . . . ” c l a s s=” . . . ” data−qa=” SPO 117601 ”>

Izvorna koda 5.4: Atribut data-qa

Za elemente, kot so vnosno polje za ime, znesek takojˇsnjega plaˇcila in gumb za naprej so bile ustvarjene konstante, ki se jih je uporabilo za vrednosti atributa data-qa, kot je prikazano v kodi 5.5

1 . . .

2 <a data−qa=” next−s t e p ”>. . .</a>

3 <input data−qa=”name”>

Izvorna koda 5.5: Razliˇcni primeri atributa data-qa

(45)

Diplomska naloga 29

5.4 Dinamiˇ cni testni objekti

Zaradi laˇzjega vzdrˇzevanja se je ˇstevilo testnih objektov zniˇzalo z uporabo dinamiˇcnih testnih objektov. Za dan primer iz kode 5.4, bi do elementa dostopali s statiˇcnim lokatorjem XPath, kot je prikazano s kodo 5.6. Zaradi velikega ˇstevila naprav, ki so na spletni strani, bi to pomenilo, da mora za vsak interaktiven element z napravo obstajati njegov testni objekt.

1 // a [ @data−qa =’SPO 117601 ’ ]

Izvorna koda 5.6: Statiˇcni lokator XPath

Temu se izognemo z dinamiˇcnimi testnimi objekti, katerih struktura je prikazana na Sliki 5.7. S kodo 5.7 je predstavljen lokator XPath, ki je sestavljen iz poljubnih spremenljivk, ki jih v ˇcasu izvajanja posredujemo objektu s pomoˇcjo funkcij.

1 // a [ @data−qa =’${d a t a q a}’ ]

Izvorna koda 5.7: Dinamiˇcni lokator XPath

Slika 5.7: Dinamiˇcni testni objekti

V kljuˇcni besedi po meri, bi s klicem funkcije findTestObject(String te- stObjectRelativeId, Map<String, Object> variables)pridobili ˇzeljeni element tako, da funkciji podamo relativno pot do obstojeˇcega testnega objekta ter preslikavo z ˇzeljenimi podatki o spremenljivkah, kot je predstavljeno s kodo 5.8.

(46)

1 f i n d T e s t O b j e c t ( ’ G l o b a l T e s t O b j e c t s / a n c h o r b y d a t a q a ’ , [

” d a t a q a ” : ” SPO 117601 ” ] )

Izvorna koda 5.8: Pridobivanje dinamiˇcnega elementa

5.5 Zagotavljanje edinstvenih atributov

Zaradi uporabe JavaServer Faces (v nadaljevanju JSF) in sistema za upravljanje vsebin (angl. Content management system - CMS), se elementom HTML dinamiˇcno zgenerirajo vrednosti atributa id. Zaradi potrebe po robustnosti so ti bili neprimerni, saj bi lahko vsakodnevne vsebinske spremembe vplivale na izvajanje skriptov. Cilj novega atributa je bil, da je edinstven in olajˇsa priˇcakovana vzdrˇzevalna dela. Aplikacija uporablja verzijo JSF, ki v svoji osnovi ne podpira uporabe poljubnih podatkovnih (angl. data) atributov po meri. Zaradi tega smo morali razˇsiriti delovanje upodabljalnikov (angl.

renderer) vseh komponent JSF, ki so bile uporabljene v tokih nakupa. Upo- dabljalnik opravlja delo generiranja HTML za komponento JSF. Primer, v kaj se komponenta JSFh:inputText pretvori, je prikazan s kodo 5.9.

1 <!−− komponenta JSF −−>

2 <h : i n p u t T e x t>

3 <!−− e l e m e n t HTML−−>

4 <input type=” t e x t ”>

Izvorna koda 5.9: Upodabljalnik JSF

5.6 Branje vhodno/izhodnih testnih podat- kov

Na zaˇcetku so testni objekti na sebi vsebovali statiˇcne lokatorje o elementih.

Implementacija reˇsitev omenjenih v poglavju 5.3 in poglavju 5.4 je omogoˇcila izvajanje testnih skriptov s poljubnimi vhodnimi podatki.

(47)

Diplomska naloga 31 Za prototip se je najprej preverilo delovanje z uporabo datoteke, ki vsebuje vrednosti, loˇcene z vejico (angl. Comma-separated values - CSV). Po- datke, ki ˇzelimo imeti na voljo za uporabo, umestimo v korensko mapoData files, kot je vidno na Sliki 5.8.

device,start_url,immediatePrice,firstMonthPrice,monthlyPrice SPO_117601,https://www.a1.si/telefoni,0.00,81.97,69.98

SPO_451889,https://www.a1.si/telefoni,0.00,55.99,38.20 Primer datoteke CSV

Slika 5.8: Testni podatki

Testni primer mora vsebovati definicijo spremenljivk, ki jih lahko uporabi.

Za laˇzjo predstavi si poglejmo datotekoTestni primer.tc, ki je predstavljena s kodo 5.10. Datoteka vsebuje razliˇcne podatke, med njimi opazimo tudi

znaˇcko <variable>, ki predstavlja podporo spremenljivke. Omenjen testni

primer ima moˇznost uporabe naslednjih spremenljivk: device, start url, im- mediatePrice, firstMonthPrice inmonthlyPrice.

1 <? xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF−8” ?>

2 <T e s t C a s e E n t i t y>

3 <d e s c r i p t i o n>Opis t e s t n e g a p r i m e r a</ d e s c r i p t i o n>

4 <name>T e s t n i p r i m e r</name>

5 <t a g>Znacka t e s t n e g a p r i m e r a</ t a g>

6 <comment></comment>

7 <t e s t C a s e G u i d>808 a0a21−0277−406b−9895−f 0 9 5 8 3 3 a 6 9 0 6</

t e s t C a s e G u i d>

(48)

8 <v a r i a b l e>

9 <d e f a u l t V a l u e>’ ’</ d e f a u l t V a l u e>

10 <d e s c r i p t i o n></ d e s c r i p t i o n>

11 <id>edccd32b−f 9 c c−4947−9724−d 8 3 a b 1 f 5 2 8 f 2</id>

12 <masked>f a l s e</ masked>

13 <name>d e v i c e</name>

14 </ v a r i a b l e>

15 <v a r i a b l e>

18 <id>85 d f 9 f 7 b−2cc1−476d−85ee−a a 9 d 5 9 8 5 a d 5 f</id>

20 <name>s t a r t u r l</name>

21 </ v a r i a b l e>

25 <id>74893823−f 2 b c−41 e f−a9a5−079 d 5 f d 3 b f a 4</id>

27 <name>i m m e d i a t e P r i c e</name>

28 </ v a r i a b l e>

32 <id>5 e4437bb−8495−4706−9830−0 e 9 0 6 2 7 5 4 3 0 1</id>

34 <name>f i r s t M o n t h P r i c e</name>

35 </ v a r i a b l e>

(49)

Diplomska naloga 33

39 <id>53852 bdd−60b1−416c−9648−91 e 7 d f b 1 3 0 d e</id>

41 <name>m o n t h l y P r i c e</name>

42 </ v a r i a b l e>

43 </ T e s t C a s e E n t i t y>

Izvorna koda 5.10: Datoteka Testni primer.tc

Za povezavo med testnim primerom in testnimi podatki poskrbi pre- skuˇsalni niz. Preskuˇsalni niz je namenjen zdruˇzitvi veˇc testnih primerov.

Kot primer si poglejmo kodo 5.11, ki predstavlja datotekoPreskusalni niz.ts s podatki o preskuˇsalnem nizu. Podatki o povezavi med preskuˇsalni nizom in testnim primerom so predstavljeni v znaˇckah <testCaseLink>preko <te- stCaseId>. Tukaj definiramo vhodne podatke z znaˇcko <testDataLink>, ki vsebuje povezavo do vira podatkov preko <testDataId>. Znaˇcka <vari- ableLink> pa s svojo vrednostjo <variableId> povezuje vhodne podatke s spremenljivkami testnega primera.

1 <? xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF−8” ?>

2 <T e s t S u i t e E n t i t y>

4 <name>P r e s k u s a l n i n i z</name>

5 <t a g></ t a g>

6 f a l s e

7 <m a i l R e c i p i e n t></ m a i l R e c i p i e n t>

8 <numberOfRerun>0</ numberOfRerun>

9 <pageLoadTimeout>30</ pageLoadTimeout>

10 <pageLoadTimeoutDefault>t r u e</ pageLoadTimeoutDefault

>

11 <r e r u n F a i l e d T e s t C a s e s O n l y>f a l s e</

r e r u n F a i l e d T e s t C a s e s O n l y>

12 <r e r u n I m m e d i a t e l y>f a l s e</ r e r u n I m m e d i a t e l y>

13 <t e s t S u i t e G u i d>3 c 5 4 f 6 8 1−9f 1 5−4641−9e38−0 c 5 a f 6 5 2 b 2 0 f<

/ t e s t S u i t e G u i d>

(50)

14 <t e s t C a s e L i n k>

15 <g u i d>a441c0d9−a 0 c f−42ed−b133−25685 d0549d6</ g u i d>

16 f a l s e

17 <isRun>t r u e</ isRun>

18 <t e s t C a s e I d>Test C as e s / T e s t n i p r i m e r</ t e s t C a s e I d>

19 <t e s t D a t a L i n k>

20 <combinationType>ONE</ combinationType>

21 <id>9999 fab8−a70a−4a25−8767−f9dd56babb91</id>

22

23 ALL

24 <value></value>

25

26 <t e s t D a t a I d>Data F i l e s /CSV/ T e s t n i P o d a t k i</

t e s t D a t a I d>

27 </ t e s t D a t a L i n k>

28 <v a r i a b l e L i n k>

29 <t e s t D a t a L i n k I d>9999 fab8−a70a−4a25−8767−

f9dd56babb91</ t e s t D a t a L i n k I d>

30 <type>DATA COLUMN</type>

31 <value>d e v i c e</value>

32 <v a r i a b l e I d>edccd32b−f 9 c c−4947−9724−

d 8 3 a b 1 f 5 2 8 f 2</ v a r i a b l e I d>

33 </ v a r i a b l e L i n k>

37 <value>s t a r t u r l</value>

38 <v a r i a b l e I d>85 d f 9 f 7 b−2cc1−476d−85ee−

a a 9 d 5 9 8 5 a d 5 f</ v a r i a b l e I d>

(51)

Diplomska naloga 35

43 <value>i m m e d i a t e P r i c e</value>

44 <v a r i a b l e I d>74893823−f 2 b c−41 e f−a9a5−079 d 5 f d 3 b f a 4</ v a r i a b l e I d>

49 <value>f i r s t M o n t h P r i c e</value>

50 <v a r i a b l e I d>5 e4437bb−8495−4706−9830−0 e 9 0 6 2 7 5 4 3 0 1</ v a r i a b l e I d>

55 <value>m o n t h l y P r i c e</value>

56 <v a r i a b l e I d>53852 bdd−60b1−416c−9648−91 e 7 d f b 1 3 0 d e</ v a r i a b l e I d>

58 </ t e s t C a s e L i n k>

59 </ T e s t S u i t e E n t i t y>

Izvorna koda 5.11: Datoteka Preskusalni niz.ts

S tem, ko smo vhodne podatke povezali s spremenljivkami testnega primera, so ti na voljo za uporabo v razliˇcnih kljuˇcnih besedah. Spremenljivka start url je uporabljena v kljuˇcni besedi WebUI.openBrowser(start url), ki odpre brskalnik na podanem naslovu. Device poskrbi za izvajanje klika na si-

(52)

36 Miha ˇStemberger dro zWebUI.click(findTestObject(’GlobalTestObjects/anchor by data qa’, [(”data- qa”) : device])), ki navigira na detajlno stran naprave. Spremenljivke mon- thlyPrice, firstMonthPrice in immediatePrice pa so v koˇsarici uporabljene za preverjanje pravilnosti seˇstevka zneskov takojˇsnjega, meseˇcnega in prvega plaˇcila z uporabo kljuˇcne besede WebUI.getText(...), ki pridobi tekst elementa, katerega nato primerjamo z eno izmed podanih vrednosti spremenljivk.

5.7 Integracija podatkovne baze

Po uspeˇsni integraciji branja testnih podatkov iz datoteke CSV je bil cilj prenesti vir podatkov v podatkovno bazo. Na Sliki 5.9 lahko opazimo, da se je podatkovni model, ki smo ga videli v poglavju 5.6, nekoliko spremenil.

(53)

Diplomska naloga 37

Slika 5.9: Podatkovni model

Tabela WS CONFIGURATION vsebuje podobne podatke kot datoteka CSV, odstranjen je bil podatekstart url, saj je bil naˇs cilj, da lahko konfiguracijo uporabimo na razliˇcnih tokih nakupa. To je bilo doseˇzeno z implemen- tacijo relacije mnogo proti mnogo med tabelama WS CONFIGURATION ter WS TAG. Podatki v tabeli WS TAG predstavljajo oznake, ki omogoˇcijo uporabo konfiguracije v razliˇcnih tokih nakupa. Kot primer je s kodo 5.12 prikazan poizvedbeni stavek, ki vrne vse konfiguracije z oznako FT (angl.

free trade). FT oznaka je bila uporabljena pri konfiguracijah, ki so bile

(54)

38 Miha ˇStemberger namenjene toku nakupa, kjer se zgodi samo nakup naprave.

1 s e l e c t c .∗ from a p l a t .WS CONFIGURATION c

2 inner j o i n a p l a t . WS CONFIGURATION TAG c t ON c . c o n f i g u r a t i o n i d = c t . c o n f i g u r a t i o n i d

3 inner j o i n a p l a t .WS TAG t ON c t . t a g i d = t . t a g i d

4 where t . t a g v a l u e l i k e ’FT ’ ;

Izvorna koda 5.12: Poizvedbeni stavek

Kot nadgradnja je dodana tabela WS CUSTOMER INFORMATION, ki vsebuje ime, priimek, telefonsko ˇstevilko, ulico, hiˇsno ˇstevilko, elektronski naslov ter tip plaˇcila. Ti podatki so omogoˇcili pripravo testnih primerov za opravljanje zakljuˇcnega nakupnega procesa.

5.8 Katalon TestOps

Rezultat testa je lahko preskoˇcen, uspeˇsno, neuspeˇsno ali delno izveden test.

Katalon Studio IDE ponuja izdelavo razliˇcnih formatov poroˇcil: HTML, CSV in PDF. Kot primer, je na Sliki 5.10 prikazano poroˇcilo formata HTML. Tukaj so vidni vsi koraki, ki so se za testne primere izvedli, status rezultatov in v primeru, da je priˇslo do napake, tudi razlog za napako.

(55)

Diplomska naloga 39

Slika 5.10: Poroˇcilo v formatu HTML

(56)

40 Miha ˇStemberger Mogoˇca je tudi integracija z reˇsitvijo Katalon TestOps, ki je prav tako lahko izvedena preko Katalon Studio IDE. Zahteva kreacijo in povezavo do projekta Katalon TestOps, kot je vidno na Sliki 5.11. S tem lahko v dnevniˇskem zapisu (angl. log) opazimo informacijo Katalon TestOps: Start uploading report to Katalon TestOps server: https://analytics.katalon.com, ki pravi, da se poroˇcilo nalaga v nastavljeni projekt Katalon TestOps. Preko spletnega uporabniˇskega vmesnika je na voljo veˇc razliˇcnih naˇcinov za pregled podatkov. Eden izmed njih je prikazan na Sliki 5.12.

Slika 5.11: Nastavitve integracije s Katalon TestOps

(57)

Diplomska naloga 41

Slika 5.12: Primer vmesnika Katalon TestOps

5.9 Sistem neprekinjene integracije in dostave

Ostala nam je ˇse integracija v sistem CI/CD. Izbrana je bila reˇsitev TeamCity, ki je opisana v poglavju 3.3. V nadaljevanju bo predstavljen primer uporabe.

Po namestitvi TeamCitya moramo najprej ustvariti projekt, kot je vidno na Sliki 5.13. Nato imamo na voljo moˇznost dodajanja konfiguracij gradnje projekta (angl. build configuration). V naˇsem primeru smo dodali dve konfiguraciji: Application build and deploy inKatalon Tests.

Konfiguracija gradnje Application build and deploy je predstavljena na Sliki 5.14 in vsebuje en korak gradnje (angl. build step). Korak gradnje uporablja tip zaganjalnika Maven, ki je opisan v poglavju 3.4 in izvede ukazmvn clean install wildfly:deploy-only. Ker se med izvajanjem tega ukaza izvede kar nekaj stvari, bo zaradi laˇzjega razumevanja bolj v grobem opisan in se lahko podrobnosti prebere na [16] in [15]. mvn je klic programa Maven, opcija clean povzroˇci brisanje vseh datotek projekta aplikacije, install poskrbi za namestitev zgrajenih paketov v lokalni repozitorij in na koncuwildfly:deploy-

(58)

Slika 5.13: Primer pojekta v TeamCityju

only, ki vse skupaj umesti na aplikacijski streˇznik. Ob uspeˇsnem zakljuˇcku bi tako aplikacija morala biti na voljo.

Konfiguracija gradnjeKatalon Tests, vidna na Sliki 5.15, poskrbi za zagon testnih skriptov. Tukaj se prav tako uporabi samo en korak gradnje, ki za tip zaganjalnika uporablja ukazno vrstico. Ukaz za izvajanje ˇzeljenega skripta zgeneriramo s pomoˇcjo komponente Build CMD v Katalon Studio IDE, ki za ˇzeljen preskuˇsalni niz zgenerira ukaz za uporabo v ukazni vrstici, kot je vidno na Sliki 5.16. Zgeneriran ukaz nato prenesemo v korak gradnje.

Trenutno konfiguraciji med seboj nimata nobene povezave, lahko pa na- stavimo proˇzilec, kot je vidno na Sliki 5.17, ki bo ob uspeˇsno konˇcanem izvajanju konfiguracije Application build and deploy pognal ˇse konfiguracijo Katalon Tests. S tem je bila prva iteracija integracije sistema za avtomatizirano testiranje funkcionalnosti konˇcana.

(59)

Diplomska naloga 43

Slika 5.14: Gradbena konfiguracija aplikacije

Slika 5.15: Gradbena konfiguracija testov

(60)

Slika 5.16: Ukaz ukazne vrstice

Slika 5.17: Proˇzilec konfiguracije

(61)

Poglavje 6

Sklepne ugotovitve

Avtomatizirano testiranje ne more v celoti nadomestiti roˇcnega testiranja.

Vedno se bodo naˇsli nekateri testi, ki jih je laˇzje opraviti roˇcno kot avtomatizirano. Testi morajo sprva biti primerni za avtomatizacijo, nato pa pravilno implementirani. V knjigi [6] je zapisano: ^≫Ali je test avtomatiziran ali ne nima vpliva na njegovo zmoˇznost odkrivanja nepravilnosti. Ni vaˇzno, kako pameten si pri avtomatizaciji testa: ˇce sam test ne doseˇze niˇcesar, potem je konˇcni rezultat test, ki hitreje ne doseˇze niˇcesar.^≪

Zavedati se je potrebno, da avtomatizirani testi nimajo domiˇsljije in samo opravljajo podana navodila. Ker je bil test pred avtomatizacijo ˇze roˇcno izveden, imajo avtomatizirani testi manjˇso moˇznost odkritja nepravilnosti in so orodja, ki ponovno testirajo (angl. re-test) programsko opremo ter tako preverjajo njeno regresijo/nazadovanje.

Zelo priporoˇcljivo je, da se o testiranju in avtomatizaciji testiranja razmiˇslja v vsakem koraku definicije projekta. S tem si postavimo cilje in sprejemne pogoje za naprej in njim primerno prilagajamo razvoj. ˇCeprav to za podjetje predstavlja veˇcji zaˇcetni vloˇzek, saj se ekonomiˇcnost avtomatiziranih testov pojavi komaj po veˇcjem ˇstevilu izvajanj, je bolje, da se sistem vnaprej pri- pravi za integracijo z orodjem za avtomatizacijo testov. Programsko opremo je laˇzje prilagajati orodju od zaˇcetka razvoja, kot da jo kasneje spreminjamo in s tem po moˇznosti predstavimo nove nepravilnosti.

45

(62)

(63)

Clanki v zbornikih ˇ

[4] Gaurav Duggal in Bharti Suri. “Understanding regression testing tech- niques”. V:Proceedings of 2nd National Conference on Challenges and Opportunities in Information Technology. 2008.

[11] G.F. Renfer. “Automatic program testing”. V: Proceedings of the 3rd Conference of the Computing and Data Processing Society of Canada.

1962.

47

(64)

(65)

Celotna literatura

[1] Apache JMeter. Dosegljivo: https://jmeter.apache.org/. [Dosto- pano 18.07.2021].

[2] Apache Maven. Dosegljivo: https://maven.apache.org/. [Dostopano 29.07.2021].

[3] MDN Web Docs. Xpath. Dosegljivo: https://developer.mozilla.

org/en-US/docs/Web/XPath. [Dostopano 27. 5. 2021].

[4] Gaurav Duggal in Bharti Suri. “Understanding regression testing tech- niques”. V:Proceedings of 2nd National Conference on Challenges and Opportunities in Information Technology. 2008.

[5] Elfriede Dustin, Jeff Rashka in John Paul.Automated software testing:

introduction, management, and performance. Addison-Wesley, 1999.

[6] Mark Fewster in Dorothy Graham.Software test automation. Addison- Wesley Reading, 1999.

[7] Kaj je artefakt? Dosegljivo: https://maven.apache.org/glossary.

html. [Dostopano 29.07.2021].

[8] Katalon. Dosegljivo:https://www.katalon.com/. [Dostopano 04.06.2021].

[9] Manoj Mahalingam. Learning Continuous Integration with TeamCity.

Packt Publishing Ltd, 2014.

[10] Razlaga datoteke arhiva Jave. Dosegljivo: https : / / docs . oracle . com/javase/8/docs/technotes/guides/jar/jarGuide.html. [Do- stopano 29.07.2021].

49

(66)

50 Miha ˇStemberger [11] G.F. Renfer. “Automatic program testing”. V: Proceedings of the 3rd Conference of the Computing and Data Processing Society of Canada.

1962.

[12] Selenium. Dosegljivo: https : / / www . selenium . dev/. [Dostopano 04.06.2021].

[13] Sanjay Kumar Singh in Amarjeet Singh. Software testing. Vandana Publications, 2012.

[14] Testiranje z uporabo kljuˇcnih besed. Dosegljivo:https://en.wikipedia.

org/wiki/Keyword-driven_testing. [Dostopano 15.07.2021].

[15] Vtiˇcnik Wildfly. Dosegljivo: https : / / docs . jboss . org / wildfly / plugins/maven/latest/. [Dostopano 10.07.2021].

[16] Zivljenski cikel Mavena. Dosegljivo:ˇ https : / / maven . apache . org / guides / introduction / introduction - to - the - lifecycle . html.

[Dostopano 10.07.2021].