UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Milan Fesel

PRIMERJAVA TESTIRNIH ORODIJ DOSTOPNIH NA

PROSTEM TRGU

Diplomsko delo

Maribor, september 2017

i

PRIMERJAVA TESTIRNIH ORODIJ DOSTOPNIH NA PROSTEM TRGU

Diplomsko delo

Študent: Milan Fesel

Študijski program: Visokošolski študijski program

Informatika in tehnologije komuniciranja

Smer: Razvoj informacijskih sistemov

Mentor: red. prof. dr. Ivan Rozman

Lektor: Ivan Cepanec, prof. slov. jez. in zgod.

ii

iii

ZAHVALA

Zahvaljujem se mentorju prof. dr. Ivanu

Rozmanu za pomoč in vodenje pri izdelavi

diplomskega dela.

Zahvaljujem se tudi svoji punci Špeli za

spodbudo in podporo pri pisanju diplomskega

dela.

Posebna zahvala velja staršem, ki so verjeli

vame in mi omogočili študij.

iv

Primerjava testirnih orodij dostopnih na prostem trgu

Ključne besede: primerjava testirnih orodij, prosto dostopna orodja, upravljanje

testiranja, orodje FitNesse.

UDK: 004.4'22(043.2)

Povzetek

V diplomskem delu smo predstavili prosto dostopna orodja za upravljanje testiranja. Na

začetku smo podali pregled priporočil, metode in nivoje testiranja. Nato smo raziskali

lastnosti in zahteve orodij za upravljanje testiranja. Predstavljena orodja smo najprej

primerjali med seboj, nato pa še s prosto dostopnimi orodji. Na koncu smo v prosto

dostopnem orodju FitNesse predstavili primer testiranja, tako da smo s pomočjo

programske kode in testnih primerov primerjali aktualne in pričakovane rezultate.

v

The testing tools available on open market comparison

Key words: comparison of test management tools, open source test management tools,

testing, FitNesse tool

UDK: 004.4'22(043.2)

Abstract

The thesis present open source test management tools. In the first part, we provided an

overview of recommendations, methods and levels of testing. We also studied properties

and requirements of test management tools. Then, we compared the tools we presented to

one another and to other open source tools. At the end of the paper, we prepared a test

example in an open source tool FitNesse and compared real and expected results using code

and test examples.

vi

KAZALO VSEBINE

1 UVOD ..................................................................................................................... 1

2 UPRAVLJANJE TESTIRANJA ..................................................................................... 2

2.1 TESTIRANJA PO PRIPOROČILIH STANDARDA IEEE 829 ..................................................... 2

2.1.1 Dokumentacija za pripravo testov .............................................................. 2

2.1.2 Dokumentacija za izvedbo testiranja .......................................................... 4

2.2 METODE TESTIRANJA ............................................................................................... 5

2.2.1 Testiranje po principu črne skrinje .............................................................. 5

2.2.2 Testiranje po principu bele skrinje .............................................................. 6

2.2.3 Primerjava testiranja po principu črne in bele skrinje ................................ 8

2.3 ROČNO IN AVTOMATSKO TESTIRANJE .......................................................................... 9

3 GLAVNI NIVOJI TESTIRANJA ................................................................................... 11

3.1 FUNKCIONALNO TESTIRANJE .................................................................................... 11

3.1.1 Testiranje programskih enot ..................................................................... 12

3.1.2 Integracijsko testiranje ............................................................................. 13

3.1.3 Validacijsko testiranje ............................................................................... 14

3.1.4 Sistemsko testiranje .................................................................................. 15

3.1.5 Sprejemno testiranje ................................................................................. 16

3.2 NEFUNKCIONALNO TESTIRANJE ................................................................................ 17

4 OPIS ORODIJ ZA UPRAVLJANJE TESTIRANJA ........................................................... 18

4.1 IMPLEMENTACIJA ORODIJ ........................................................................................ 18

4.2 UPORABA ORODIJ ................................................................................................. 18

4.3 LASTNOSTI IN ZAHTEVE ORODIJ PRI UPRAVLJANJU TESTIRANJA ........................................ 19

4.4 IZBOLJŠAVE ORODIJ V PRIHODNOSTI .......................................................................... 21

4.5 ODPRTOKODNA ORODJA ......................................................................................... 22

5 PRIMERJAVA ORODIJ............................................................................................. 29

5.1 PRIMERJAVA ODPRTOKODNIH ORODIJ ....................................................................... 32

6 PRIMER TESTIRANJA V ORODJU FITNESSE .............................................................. 33

6.1 OPIS PROBLEMA ................................................................................................... 33

6.2 PROGRAMSKI DEL .................................................................................................. 33

6.3 TESTNI PRIMERI .................................................................................................... 35

6.4 REZULTATI TESTIRANJA ........................................................................................... 39

7 SKLEP .................................................................................................................... 42

VIRI ............................................................................................................................. 43

vii

KAZALO SLIK

SLIKA 2.1: TESTIRANJE PO METODI ČRNE SKRINJE. [18] ...................................................................... 5

SLIKA 2.2: TESTIRANJE PO METODI BELE SKRINJE. [17] ....................................................................... 7

SLIKA 3.1: FUNKCIONALNO TESTIRANJE PO PRINCIPU ČRNE SKRINJE. .................................................... 11

SLIKA 3.2: NIVOJI TESTIRANJA. .................................................................................................... 12

SLIKA 4.1: DIAGRAM LASTNOSTI ORODIJ PRI UPRAVLJANJU TESTIRANJA. [14] ....................................... 20

SLIKA 4.2: RAZPOREDITEV MOŽNOSTI QABOOK. [21] ..................................................................... 26

SLIKA 4.3: POSTOPEK IZVEDBE TESTIRANJA V ORODJU FITNESSE. [20] ................................................. 27

SLIKA 6.1: PROGRAMSKA KODA ZA IZVEDBO TABELNE VSEBINE. .......................................................... 34

SLIKA 6.2: DODAJANJE TESTNE STRANI IN PREUSMERITEV.................................................................. 35

SLIKA 6.3: UREDITEV TESTNEGA PRIMERA. ..................................................................................... 36

SLIKA 6.4: PRIKAZ TESTNEGA PRIMERA PO UREDITVI. ....................................................................... 37

SLIKA 6.5: TESTNI PRIMER Z NEPRAVILNIMI REZULTATI. .................................................................... 38

SLIKA 6.6: TESTNI PRIMER V MANJKAJOČEM IN V NAPAČNEM REZULTATU. ............................................ 38

SLIKA 6.7: REZULTATI TESTNEGA PRIMERA S PRAVILNIMI IZRAČUNI...................................................... 39

SLIKA 6.8: REZULTATI TESTNEGA PRIMERA Z NAPAČNIMI REZULTATI. ................................................... 40

SLIKA 6.9: REZULTATI TESTNEGA PRIMERA V PRAZNEM IN V NAPAČNEM VNOSU..................................... 41

KAZALO TABEL

TABELA 2.1: PRIMERJAVA TESTIRANJA PO METODI ČRNE IN BELE SKRINJE [8] .......................................... 8

TABELA 5.1: PRIMERJAVA ORODIJ: TESTRAIL, TESTLINK, ZEPHYR IN TESTOPIA (PODPORA, UVOZ IN IZVOZ

TESTNIH PRIMEROV IN SLEDENJE). [9] .............................................................................. 29

TABELA 5.2: PRIMERJAVA ORODIJ TESTRAIL, TESTLINK, ZEPHYR IN TESTOPIA (CENA, UPORABA,

KONFIGURACIJA IN POVEZAVA Z EL. POŠTO). [9] ................................................................. 30

TABELA 5.3: PRIMERJAVA ORODIJ TESTRAIL, TESTLINK ZEPHYR IN TESTOPIA (AVTOMATIZACIJA IN

INTEGRACIJA, POROČANJE, STATISTIKA IN GRAFI). [9] .......................................................... 31

TABELA 5.4: PRIMERJAVA ORODIJ ZA UPRAVLJANJE TESTIRANJA ......................................................... 32

viii

UPORABLJENE KRATICE

Kratica Angleški pomen Slovenski pomen

OSS Open Source Software Odprtokodna programska

oprema

OSI Open Source Initiative Odprtokodne iniciative

FSF Free Software Foundation Neprofitna organizacija

SQL Structured Query Language Sestavljeni strukturni jezik

GNU General Public License Splošna licenca

XML Extensible Markup

Language

Razširljivo označevalni jezik

CSV Comma – Separated Values Ločene vrednosti

OCR Object Character

Recognition

Objektna prepoznava

znakov

ICR Image Character

Recognition

Slikovna prepoznava

znakov

IEEE Institute of Electrical and

Electronics Engineers

Inštitut inženirjev

elektrotehnike in

elektronike

UX User Experience Uporabniške izkušnje

SLIM Simple List Invocation

Method

Enostavna seznamska

metoda

FIT Framework Integrated Test Okvirno integracijsko

testiranje

1

1 UVOD

Upravljanje testiranja predstavlja ključni del razvoja kakovostne programske in strojne

opreme. Skozi dobro vodene in načrtovane postopke lahko zagotovimo najboljše rešitve.

[1] Zelo pomemben faktor pri testiranju je tudi človek, pri čemer je priporočljivo, da akter,

ki je implementiral izvorno kodo, ne sodeluje pri samem testiranju, saj lahko odkrijemo več

napak. Bistvo upravljanja testiranja predstavljajo sama orodja. Imajo namreč nalogo pri

shranjevanju informacij, načinu upravljanja ter pri zagotavljanju kakovosti. Pri odločanju o

programskih orodjih testnih avtomatizacij lahko opazimo, da bodo nova orodja temeljila

na: uporabniški prijaznosti in integracijah med orodji, ki združujejo različna orodja za

ustreznost uporabniških potreb. [13]

Veliko podjetij ima že izbrane rešitve za upravljanje testiranja, čeprav so vidne izboljšave

pri procesih. Značilno je, da pri izbiri ustrezne rešitve prevladuje strah pred visokimi stroški

licence in uporabe. [19]

Namen diplomskega dela je preučiti odprtokodna orodja, področje testiranja, principe in

metode testiranja. Osnovni namen testiranja je iskanje napak, tako da odkrijemo

pomanjkljivosti in jih odpravimo. Cilj diplomskega dela je zagotavljanje kvalitetnih in

odprtokodnih rešitev, ki jih bomo predstavili in primerjali.

V diplomskem delu bomo raziskali upravljanje testiranja, kjer bomo razložili postopke

uporabe, metode in načine testiranja. Predstavili bomo različne nivoje testiranja, ki jih

vključujejo metodologije in se uporabljajo pri izvajanju testiranja. Potem bomo raziskali

orodja za upravljanje testiranja, jih opisali in primerjali. Obravnavali bomo pogosto

uporabljena odprtokodna orodja, pri katerih bomo predstavili uporabo, licenco in vrste

testiranja, ki jih lahko izvedejo. V zadnjem delu diplomskega dela bomo raziskali sprejemno

testiranje v orodju FitNesse. Na svojem programskem delu bomo izvedli testne primere ter

prikazali rezultate testiranja. S pomočjo testnih primerov bomo na našem primeru

obrazložili ugotovitve.

2

2 UPRAVLJANJE TESTIRANJA

Upravljanje testiranja predstavlja proces testov, ki so namenjeni uporabi orodij za

upravljanje avtomatskih in ročnih testov. Orodja za upravljanje testiranja pogosto temeljijo

na večnamenskih opravilih, kot so: poročanje, sledenje, beleženje rezultatov in upravljanje

incidentov. [27]

Skozi dobro vodene in načrtovane postopke testiranja lahko skupine zagotavljajo najboljše

možne izdelke. Upravljanje vse bolj kompleksnih produktov programske opreme vključuje

pametne teste v praksi. [1]

2.1 Testiranja po priporočilih standarda IEEE 829

Standard za testiranje programske opreme in sistemov je IEEE (angl. Institute of Electrical

and Electronics Engineers), ki določa dokumente za uporabo v osmih opredeljenih fazah

testiranja programske opreme in sistemov. Standard določa obliko dokumentov, vendar ne

določa, da bodo vsi narejeni. Prav tako ne določa vseh kriterijev glede na ustrezne vsebine

dokumentov. To so stvari presoje zunaj standarda. [12]

2.1.1 Dokumentacija za pripravo testov

Priprava testiranja je najpomembnejše opravilo kateregakoli programskega projekta in

lahko predstavlja veliko birokratskega dela. Namen te stopnje je pripraviti izvedbo testa ter

ustvariti okolje za njihovo delovanje.

Plan testiranja

Predstavlja ključni dokument, po katerem si sledijo vsi projekti za testiranje programske

opreme. Dokument sestavljajo:

storitve za potrebe delovanja,

standardi kakovosti,

viri,

3

časovna merila,

tveganja.

Specifikacije zasnove testiranja

Prva faza pri razvoju testiranja je kreiranje testne zasnove. Za samo izvedbo testiranja

posname, kar potrebuje, ter izhaja iz dokumentov, ki so v testni fazi.

Ne beleži vnesene vrednosti, vendar opiše zahteve za določitev te vrednosti.

Ta dokument spada med zelo pomembna opravila, a manjka pri mnogih projektih. Razlog

za to je, da so testni primeri napisani, preden se ljudje odločijo, kaj bodo testirali.

Specifikacije testnih primerov

Testni primeri se izvedejo po končani zasnovi testiranja. Zahteve za testne primere:

natančne vhodne vrednosti,

natančne izhodne vrednosti,

vse potrebne nastavitve pri testiranju.

Zelo pomembno je določanje pričakovanih vrednosti. S tem lahko opazimo razlike.

Specifikacija testnih procedur

Procedure so se razvile iz testnih zasnov in testnih primerov. Dokument opisuje, kako mora

tester izvesti test na fizični način. Ta standard opredeljuje deset korakov uporabe pri izvedbi

testiranja.

Poročilo posredovanega izdelka

Dokument ne izhaja iz plana testiranja, temveč je predaja dokumenta iz prejšnje faze

razvoja. V uporabniškem testiranju je to lahko konec sistemskega testiranja.

Dokument je pomemben, saj testerjem zagotavlja, da so testne stvari pripravljene za

izvedbo. Brez tega dokumenta ne smemo izvesti testiranja. [11]

4

2.1.2 Dokumentacija za izvedbo testiranja

Izvedba testov se izvede po končanem razvoju. Razpored testnih primerov je določen v

planu testiranja. Testni rezultati se zabeležijo v testne dnevnike in poročila.

Faze izvedbe

Testni dnevnik

Testni dnevnik beleži podatke o izvedbi, vrstnem redu in rezultatih najboljših testnih

primerov. Dejanski in pričakovani rezultati so lahko enaki. Če obstaja neskladje v enem ali

več poročilih, so enaki incidenti zabeleženi v testnem dnevniku.

Poročilo o incidentu

Ta dokument je namerno poimenovan poročilo o incidentu in ne poročilo o napaki. To je

zaradi razlike med pričakovanimi in aktualnimi rezultati, kjer lahko nastane napaka v

sistemu.

Poročilo je sestavljeno iz vseh podrobnosti incidenta, kot so dejanski in pričakovani rezultati

za izvršitev problema. Napačen test lahko sproži več kot en incident.

Zaključek testiranja

Testiranje se bo zaključilo v skladu s kriteriji, ki so določeni v planu testiranja.

Povzetek testiranja

Povzetek vsebuje vse ustrezne informacije o testiranju, vključno z oceno opravljenih

incidentov ter oceno kakovosti sistema. Zajema tudi uporabo prihodnosti projektnega

planiranja. Ta dokument je pomemben pri odločanju za nadaljevanje naslednje faze, če je

kvaliteta sistema dovolj dobra. [11]

5

2.2 Metode testiranja

2.2.1 Testiranje po principu črne skrinje

Testiranje po principu črne skrinje je metoda programskega testiranja, ki poučuje

funkcionalnost aplikacije brez pogleda notranje strukture ali delovanja.

Metoda testiranja se lahko uporablja na vseh ravneh testiranja programske opreme:

enotni, integracijski, sistemski in sprejemni ravni. [7]

Slika 2.1: Testiranje po metodi črne skrinje. [18]

Pri testiranju z metodo črne skrinje testiramo vhode in izhode (Slika 2.1). Testiranje se

izvede v primeru, če se vsak podan vhod ujema s predvidenim izhodom. Nemogoče je

izvesti vse možne testne primere (vhode). Cilj testiranja po tej metodi je zmanjšati število

testnih primerov z ekvivalenčnim particioniranjem. To izvedemo tako, da razdelimo vhodne

pogoje v ekvivalenčne razrede ter izberemo testne primere iz vsakega ekvivalenčnega

razreda. [18]

Izbira ekvivalenčnih razredov

Primer 1: vhod je veljaven v nekem intervalu vrednosti (npr. med 10 in 1000).

Določitev treh ekvivalenčnih razredov

o pod intervalom (x < 10)

o znotraj intervala (10 ≤ x ≤ 1000)

o nad intervalom (1000 < x)

6

Primer 2: vhod je veljaven za množico diskretnih vrednosti (npr. {A, B, C}).

Določitev dveh ekvivalenčnih razredov

o veljavna diskretna vrednost (x ∈ {A, B, C})

o neveljavna diskretna funkcija (x ∉ {A, B, C})

Testiranje po principu črne skrinje je namenjeno iskanju napak za naslednje kategorije:

nepravilne ali manjkajoče funkcije,

vmesniške napake,

napake podatkovne strukture,

napake predstave,

napake prekinitve in inicializacije.

Z uporabo testiranja po principu črne skrinje izdelamo nabor testnih primerov, ki

izpolnjujejo naslednje zahteve:

testne primere, ki zmanjšujejo število testnih primerov za arhiv testiranja,

testne primere, ki povedo nekaj o uporabi prisotnosti ali odsotnosti razrednih

napak. [23]

2.2.2 Testiranje po principu bele skrinje

Metoda bele skrinje je znana tudi kot razločno, stekleno, transparentno in strukturno

testiranjo. Namenjena je testiranju programske opreme, ki preizkuša notranje strukture in

delovanje aplikacij v nasprotju s funkcionalnostjo črne skrinje. Za testiranje funkcionalnosti

bele skrinje in znanja programiranja se za oblikovanje uporabljajo testni primeri.

Preizkuševalci izberejo vhode za izvajanje poti ter določijo ustrezne izhode.

Testiranje po principu bele skrinje se lahko uporablja pri enotni, integracijski in sistemski

stopnji. Tradicionalni preizkuševalci danes menijo, da se testiranje po principu bele skrinje,

ki poteka na enotni ravni, uporablja za integracijsko in sistemsko testiranje. [37]

7

Metoda po principu bele skrinje izvede testiranje po osnovni poti testiranja. Tehnike

testiranja omogočajo testne primere za ustvarjanje logične kompleksnosti oblikovanja

postopkovnih meril. Namen je, da za vsako opravilo izvede testne primere vsaj enkrat. [23]

Slika 2.2: Testiranje po metodi bele skrinje. [17]

Tipi testiranja z metodo bele skrinje

Testiranje po principu bele skrinje izvedemo po štirih tipih testiranja (Slika 2.2):

Testiranje zank

Pogoje določimo tako, da se zanka ne izvede (izjema so zanke repeat). Izvajanje zanke je

treba izvesti več kot enkrat. Zanke nas lahko pripeljejo do zazankanih programov.

Testiranje lahko zajema naslednje vrste zank:

enostavne zanke,

gnezdene zanke,

konkatencijske zanke,

nestrukturirane zanke.

Testiranje stavkov (algebrajsko testiranje)

Testiramo posamezne stavke (npr. izbira operaterjev v izrazih).

Testiranje poti

Zagotovimo, da se izvedejo vse poti v programu.

Testiranje vejitev

Zagotovimo, da je vsak možen izhod iz pogoja testiran vsaj enkrat. [17]

8

Primer:

If (x == true)

printf (»Yes«);

else

printf (»NO);

Testna primera: x=true, x=false

2.2.3 Primerjava testiranja po principu črne in bele skrinje

Razlike testiranja po metodi črne in bele skrinje so glede na določene kriterije obrazložene

v spodnji tabeli (Tabela 2.1).

Tabela 2.1: Primerjava testiranja po metodi črne in bele skrinje [8]

Kriterij Metoda črne skrinje Metoda bele skrinje

Opredelitev Metoda za testiranje

programske opreme, kjer

notranja struktura, oblika in

implementacija, ki se izvaja,

ni znana preizkuševalcu.

Metoda za testiranje

programske opreme, kjer so

notranja struktura, oblika in

implementacija, ki se izvajajo,

znane preizkuševalcu.

Veljavne stopnje Večinoma se uporablja za

testiranje na visoki ravni

(sistemsko testiranje).

Večinoma se uporablja za

testiranje na nižji ravni

(testiranje enot, integracijsko

testiranje).

Odgovornost splošna, neodvisni

programski tester

splošna, razvijalci programske

opreme

Znanje programiranja ni potrebno potrebno

Znanje implementacije ni potrebno potrebno

Osnove testnih

primerov

zahteve specifikacije podrobno oblikovanje

9

2.3 Ročno in avtomatsko testiranje

Ročno testiranje

Ročno testiranje programske opreme je proces delovanja in izvajanja vsakega programa.

Pravimo mu tudi proces opravil in rezultatov za iskanje napak v programu. Pri ročnem

testiranju programov uporabljamo vse možne scenarije. Treba je paziti na ustrezno

delovanje vseh lastnosti.

Izbira vseh nastavitev v programskem paketu lahko postane zamudno delo. Za izvajanje

ročnega testiranja v majhnem podjetju z majhnimi finančnimi sredstvi sodi med najboljše

opcije. Ročno testiranje za razliko od robota pri razvoju programa omogoča ogled napak.

Ročno testiranje temelji na fleksibilnosti. Pri uporabi avtomatskih orodij je težko

spreminjati vrednosti v času testiranja. Ročno testiranje pripomore k hitrim rezultatom ter

nam omogoča izbiro najboljše ideje.

Nasploh avtomatsko testiranje pri kratkoročnih projektih nima smisla zaradi prevelikih

stroškov. Poleg tega, če testiramo zaradi določene stvari, potrebujemo človeško uporabo,

ki je boljša od avtomatskega testiranja. Za podjetja, ki imajo malo znanja, je priporočljivo,

da začnejo z ročnim testiranjem. Priporočljivo je, da ekipa prične z avtomatskim

testiranjem, ko obvlada testiranja ter pozna možna tveganja. [5]

Prednosti ročnega testiranja:

raziskovalno testiranje je najbolje izvedeno ročno,

ročno testiranje uporabniških vmesnikov je najbolje izvedeno, ko ga izvajajo ljudje,

UX (angl. User Experience) je mogoče oceniti le z ljudmi za testiranje.

Slabosti ročnega testiranja:

ročno testiranje je nagnjeno k človeškim napakam, zato lahko privede do neskladnih

rezultatov;

človeška testiranja so v primerjavi s testnimi stroji dražja;

simulacijo velikega števila uporabnikov ali konfiguracijo je skoraj nemogoče ročno

izvesti. [15]

10

Avtomatsko testiranje

Avtomatsko testiranje uporabljajo orodja, ki temeljijo na algoritmih za primerjavo

pričakovanih rezultatov z dejanskimi rezultati. Program deluje pravilno, če so rezultati

usklajeni. V primeru, da se rezultata ne ujemata, preverimo lastno kodo in jo spremenimo.

Testiranje izvajamo tako dolgo, dokler se rezultati ne uskladijo.

Avtomatsko testiranje je primerno uporabiti na velikem projektu, kjer obstaja veliko

sistemskih uporabnikov. Hitrost in učinkovitost spadata med največje prednosti

avtomatskega testiranja. [5]

Prednosti avtomatskega testiranja:

zajame veliko kode v kratkem času,

predstavlja lažje testiranje ponavljajočih opravil,

omogoča izvedbo testiranja ne-tehničnim izvajalcem ali strankam,

omogoča prihranek časa zaradi paralelne testne izvedbe,

avtomatske teste lahko na tisoče uporabnikov simulira in konfigurira na preprost

način.

Slabosti avtomatskega testiranja:

avtomatizacija in vzdrževanje zahtevata velike investicije orodij in znanja,

avtomatizacija ne more zamenjati človeškega znanja za ocenjevanje določene

programske opreme,

ni primerna za raziskovalna testiranja, ki se uporabljajo za izboljševanje

programskega oblikovanja. [15]

11

3 GLAVNI NIVOJI TESTIRANJA

Testiranje vključuje različne metodologije, ki se lahko uporabljajo med izvajanjem

testiranja. Glavni ravni programskega testiranja sta: [22]

funkcionalno testiranje,

nefunkcionalno testiranje.

3.1 Funkcionalno testiranje

Slika 3.1: Funkcionalno testiranje po principu črne skrinje.

Spada med testiranja programske opreme, ki jih izvedemo po principu črne skrinje (Slika

3.1). Aplikacije testiramo tako, da zagotovimo vnos ter pregledamo rezultate, ki morajo biti

v skladu s funkcionalnostjo. Funkcionalno testiranje poteka na integriranih sistemih zaradi

ocenitve predpisanih zahtev.

Koraki funkcionalnega testiranja:

določanje funkcionalnosti ustreznega programa,

kreiranje testnih podatkov, ki temeljijo na specifikacijah uporabe,

izhod, ki temelji na izhodnih podatkih in specifikacijah uporabe,

pisanje scenarijev in izvedba testnih primerov,

primerjava dejanskih in pričakovanih rezultatov, ki temeljijo na izvedbah testnih

primerov.

12

Za testiranje programske opreme uporabljamo nivoje testiranja, ki so razvidni iz spodnje

slike (Slika 3.2).

Slika 3.2: Nivoji testiranja.

3.1.1 Testiranje programskih enot

Testiranje programskih enot opravljajo razvijalci. Pred namestitvijo se izvedejo testni

primeri, ki so bili predani testni ekipi. Takšno testiranje opravijo posamezni razvijalci na

točno določenih mestih izvorne kode. Razvijalci uporabijo testne podatke, ki se razlikujejo

glede na testne podatke ekip.

Cilj testiranja programskih enot je ločiti vsak del programa ter pokazati posamezne

pravilnosti glede na zahteve in funkcionalnosti.

13

Omejitve testiranja programskih enot

Testiranje ne more zaznati vsake napake v aplikaciji. Nemogoče je oceniti vsako izvedbo

poti programskih aplikacij, kar velja tudi za testiranje programskih enot.

Obstaja omejeno število scenarijev in testnih podatkov, ki jih razvijalec lahko uporabi za

preverjanje izvorne kode. Po izvedbi vseh možnosti ustavimo testiranje ter združimo kodni

segment z drugimi programskimi enotami. [22]

3.1.2 Integracijsko testiranje

Integracijsko testiranje je opredeljeno na pravilno testiranje kombiniranih delov aplikacije.

Integracijsko testiranje lahko izvedemo z dvema metodama:

Najvišje integracije

Testiranje pričnemo s testiranjem programskih enot, ki sledijo testom na visoki stopnji in

so v kombinaciji z enotnimi moduli (Slika 3.3).

Slika 3.3: Najvišje integracije.

14

Najnižje integracije

Teste izvedemo postopoma, kar pomeni, da na začetku izvedemo module na visoki stopnji.

Za tem izvedemo še testiranje modulov, ki so na nizki ravni (Slika 3.4). [22]

Slika 3.4: Najnižje integracije.

3.1.3 Validacijsko testiranje

Z validacijskim testiranjem ugotavljamo, če sistem izpolnjuje zahteve, opravlja naloge, za

katere je namenjen. Validacija se opravi na koncu razvojnega procesa in poteka, ko se

preverjanje izvede. Testiranje poteka na visoki stopnji. Validacijo izvedemo po delu

produkta, ki je proizveden v nasprotju z kriteriji. Kriteriji zagotavljajo, da se produkti

pravilno vključujejo v okolje. [22]

Prednosti validacijskega testiranja:

Poišče manjkajoče napake med testiranjem validacijskega procesa.

Prikaže razlike dejanskih in pričakovanih rezultatov pri končnem razvoju in napačno

opredeljenem testiranju.

Zaključi validacijo med: funkcijskim, integracijskim, sistemskim, združljivostnim

testiranjem.

Omogoča izgradnjo zastavljenega produkta glede na zahteve in potrebe klienta. [24]

15

3.1.4 Sistemsko testiranje

V svetu testiranja programske opreme sistemsko testiranje izvede preizkuse popolnih in

celotno integriranih programskih produktov. V veliko primerih programska oprema

predstavlja le en del večjega računalnika, ki temelji na sistemu. Prav tako je programska

oprema povezana z drugimi programskimi in strojnimi sistemi. Sistemsko testiranje je niz

različnih testov, katerih edini namen je izvesti testiranje na popolnoma sistemski način.

Sistemsko testiranje spada k metodi testiranja črne skrinje. Testiranje po metodi bele

skrinje testira notranje delovanje ali pa kodo programske aplikacije. Testiranje po metodi

črne skrinje izvedemo obratno kot pri metodi bele skrinje. Z uporabniškega vidika sistemsko

testiranje vključuje zunanje delovanje programske opreme. [36]

Sistemsko testiranje vključuje programske kode za:

testiranje celotne integrirane aplikacije,

temeljito preverjanje vsakega vhoda aplikacije,

testiranje uporabniških izkušenj pri uporabi.

Obstaja več kot petdeset vrst sistemskega testiranja. V nadaljevanju bom predstavil

običajne za uporabo:

testiranje uporabe – predvsem se osredotoča na samo uporabniško uporabo

aplikacije in fleksibilnost pri nadzoru;

testiranje obremenjenosti – pomembno je poznati programske rešitve, da bodo

opravljene v okviru resničnih obremenitev.

testiranje obnove – testiranje zaključi, ko dokaže zanesljive programske rešitve.

testiranje migracije – zagotavlja, da programsko opremo lahko brez vprašanj

premaknemo iz starejše sistemske infrastrukture v dejansko sistemsko

infrastrukturo.

testiranje funkcionalnosti – vključuje preizkušanje vseh morebitnih manjkajočih

funkcij. Testerji lahko ustvarijo seznam dodatnih funkcionalnosti, ki pomaga pri

sami izboljšavi funkcionalnega testiranja. [36]

16

3.1.5 Sprejemno testiranje

Sprejemno testiranje je stopnja testiranja programske opreme, kjer testiramo

sprejemljivost. Namen tega testiranja je ovrednotiti skladnost sistema z zahtevami ter

oceniti, če je sprejemljivo za dostavo. Sprejemno testiranje izvedemo glede na

uporabnikovo potrebo, pri čemer ugotavljamo, ali sistem izpolnjuje merila sprejemljivosti

uporabnika ali stranke.

Sprejemno testiranje se običajno izvede po metodi testiranja črne skrinje. Testiranje

običajno ne sledi striktni proceduri. Sprejemno testiranje se izvede po sistemskem

testiranju ter preden je sistem dostopen za dejansko rabo. [2]

Vrste sprejemnega testiranja:

uporabniško sprejemno testiranje

Osredotoča se predvsem na funkcionalnosti validacije poslovnih uporabnikov. Uporabniško

sprejemno testiranje se izvede s strani uporabnika in upravljalcev aplikacij.

operativno sprejemno testiranje

Naloga operativnega sprejemnega testiranja je preveriti, ali sistem izpolnjuje zahteve za

delovanje. V večini organizacij pred sistemskim izidom operativno sprejemno testiranje

opravlja sistemska administracija. Operativni testi lahko vključujejo varnostne kopije.

pogodbeno sprejemno testiranje

Izvede se na podlagi pogodb sprejemnih kriterijev za razvijanje programske opreme po

meri.

usklajeno sprejemno testiranje

Znano tudi kot regularno sprejemno testiranje, za katerega velja, da se izvaja v nasprotju s

predpisi, ki jih treba upoštevati, kot so vladni, pravni ali pa varnostni predpisi. [33]

17

3.2 Nefunkcionalno testiranje

Za nefunkcionalno testiranje je značilno kakovostno testiranje delov in sistemov. Nanaša se

na vidike programske opreme, ki ne smejo biti povezani s specifičnimi funkcijami,

uporabniško razširljivostjo in varnostjo. Nefunkcionalno testiranje, kot tudi funkcionalno

testiranje se izvajata na vseh ravneh.

Nefunkcionalno testiranje vključuje testiranje:

zanesljivosti

Namen je ugotoviti zanesljivost produkta ter ugotoviti, če programska oprema izpolnjuje

zahteve uporabnika.

uporabe

Preizkuša, če so aplikacije ali produkti uporabniku prijazni oziroma neprijazni.

učinkovitosti

Programsko testiranje učinkovitosti je število testnih primerov, ki se izvajajo deljeno s

časovno enoto (običajno na uro).

osnov

Nanaša se na preverjanje dokumentov in specifikacij.

izvedbe

Služi lahko za različne namene, kot je npr. izpolnjevanje meril uspešnosti. Za iskanje boljše

izvedbe sistemov jih lahko med seboj primerjamo.

združljivosti

Preizkuša, če je aplikacija programske opreme združljiva s strojno opremo, operacijskim

sistemom, zbirko podatkov in z drugo programsko opremo.

varnosti

Temelji na varnosti, in sicer na zaščitenosti oziroma nezaščitenosti aplikacije. [35]

18

4 OPIS ORODIJ ZA UPRAVLJANJE TESTIRANJA

Orodja za upravljanje testiranja so namenjena shranjevanju informacij, načinu opravljanja

ter zagotavljanju kakovosti. Imajo različne sklope funkcij ter so prisotna v vseh fazah

testiranja. Zaradi zagotavljanja kvalitetnih ter varnih programskih rešitev za podjetja in

fizičnih oseb morajo člani ekipe biti seznanjeni ne samo z orodji za golo testiranje, temveč

tudi z orodji za večje učinkovitosti samega procesa. [26]

4.1 Implementacija orodij

Orodje za upravljanje testiranja zajema vse, kar potrebujemo, za testiranje procesa. Proces

testiranja lahko shrani uporabnik ločenih aplikacij, ki ju potrebujemo za samo testiranje

procesa. Te aplikacije lahko implementiramo z osnovnim programskim znanjem, ki

omogoča enostavno namestitev in spremljanje več projektov. Ko je opravljena ena

namestitev, imajo ekipe takojšen dostop do uporabniškega vmesnika ter lahko pričnejo

prikazovati in snemati testne primere. Takšne aplikacije so namenjene poenostavitvi orodij

za upravljanje testiranj z visokimi stopnjami avtomatizacije ter ne zahtevajo naprednega

znanja za programiranje in izvajanje. So uporabne za ekipe, ki upravljajo z različnimi

testnimi primeri, in za večje ekipe, ki potrebujejo obsežno aplikacijo za vodenje projektov.

[25]

4.2 Uporaba orodij

Pogoji uporabe odprtokodnih orodij so določeni v okviru ene od licenčnih pogodb, ki jih

določa združenje odprtokodne iniciative (angl. Open Source Iniative – OSI) oziroma v okviru

pravic, ki jih določa neprofitna organizacija (angl. Free Software Foundation – FSF). Večina

odprtokodnih rešitev omogoča trajno uporabo. Vsak uporabnik ima svoje avtorske pravice

nad programom in ima možnost omejiti pravice kopiranja, uporabe ali spreminjanja.

Licenca pri plačljivih orodjih točno določa uporabo, pogoje ter pravice. Odprtokodna orodja

uporabljajo drugačen pristop v primerjavi s plačljivimi orodji. Pri odprtokodnih je

19

brezplačna licenca, ki ureja pravice uporabnika ter dovoljuje spreminjanje programske

opreme. Omogoča uporabo in popravljanje napak, s čimer naredi programsko orodje bolj

učinkovito. [28]

4.3 Lastnosti in zahteve orodij pri upravljanju testiranja

Orodja zajemajo tri sklope zahtev pri upravljanju testiranja (Slika 4.1). Prvi sklop zahtev

zajema razvoj različnih modelov, kot so padajoči, spiralni in agilni model.

Drugi sklop zahtev je zgrajen iz naslednjih funkcij:

načrtovanja – proces strategije, ki se uporablja za preverjanje in zagotovitve, da

produkt ali sistem izpolnjuje specifikacije in druge zahteve. Prav tako vključuje

opredelitve odvisnosti;

oblike – temelji na ustvarjanju in pisanju testnih primerov ter spremljanju testiranja

programske opreme;

izvedbe – proces, v katerem izvedemo teste;

sledenja – sposobnost sledenja povezav med zahtevami testnih načrtov, primerov

in pomanjkljivosti;

poročanja – poroča o zahtevah testnih primerov, napakah, rezultatih in številu

testnih primerov, ki se izvajajo.

20

Zadnji oziroma tretji sklop zajema objekte, ki jih morajo podpirati orodja za izvedbo

testiranja.

načrtovanje programske opreme – dokumentiranje strategije, ki bo uporabljena za

preverjanje in zagotavljanje, da produkt ali sistem izpolnjuje svoje specifikacije in

druge zahteve;

testni primeri – testne skripte izvedejo korake in pričakovane rezultate;

testne zbirke – uporabljajo se pri samem testiranju programske opreme za prikaz

specifičnih dejanj. [14]

Slika 4.1: Diagram lastnosti orodij pri upravljanju testiranja. [14]

Bistvene lastnosti orodij za upravljanje testiranja

Preprosta uporaba in fleksibilnost

Vsaka rešitev pri upravljanju testiranja, ki zahteva zahtevno in zapleteno uporabo,

predstavlja stroške pri usposabljanju. Za sisteme velja, da morajo biti logični in dostopni,

kar omogoča hitrejše in lažje razumevanje pri izvedbi testiranja.

Prav tako mora biti dovolj fleksibilno, da lahko upravlja z različnimi situacijami.Različni

projekti vsebujejo različne izvedbe testiranja, zato je pomembno, da ne ponavljamo testnih

primerov. Fleksibilnost je treba razširiti na strukturno in specifično izvedbo testov v sklopu

zahtev in napak.

21

Transparentnost in sledljivost

Zagotavljati morata odgovornost ter podatke, ki se uporabljajo pri testiranju in načrtovanju

projektov. Dobro testiranje programske opreme sledi življenjskemu ciklu napak in zahtev.

Obstajati mora postopek zahtev testnih primerov, napak, ponavljajočih ciklov in

odgovornosti. Takšen način olajša napetost med testi in v razvoju.

Za ustvarjanje neposredne povezave med zahtevami in testnimi primeri, kjer imamo več

zahtev, je pomembno, da upravljamo z eno samo zahtevo.

Dodeljevanje in spremljanje

Bistvo predstavlja dodeljevanje in spremljanje opravil. Sposobnost za dodelitev posebne

naloge z zahtevami ali napakami je ključnega pomena, vendar mora biti možno sledenje, če

je dejanje opravljeno in kdo ga je opravil. Razvojna skupina, v nekaterih primerih vodja,

mora vedeti, katere naloge lahko odobri. Naloge, ki imajo določene ukrepe, morajo biti

dodeljene ustreznim članom ekipe. Izvajalci morajo biti sposobni za pravilno razvrščanje

nalog ter morajo že vnaprej predvidevati, kaj vse se od nalog pričakuje. Filtri pri nalogah

zagotavljajo pregled napredka testne skupine, ki pomagajo vodjam in menedžerjem, da v

poročilu izpostavijo izvajanje in ponavljajoča vprašanja. [34]

4.4 Izboljšave orodij v prihodnosti

Pri odločanju o rasti programskih orodij testnih avtomatizacij lahko opazimo, da bodo nova

orodja temeljila na uporabniški prijaznosti in integracijah med orodji, ki združujejo različna

orodja za ustrezanje uporabnikovim potrebam.

Z avtomatizacijo skript bodo nova orodja izvedla testiranje na preprost in logičen način. To

pomeni, da tehnično znanje ali pa samo znanje programiranja ne bosta več potrebni. Drugi

vidik vizualne testne avtomatizacije je prihodnost testnih objektov v modernih programskih

aplikacijah. Sestava vsebuje algoritme, zgrajene na objektnem prepoznavanju znakov (angl.

Object Character Recongnition – OCR), slikovnem prepoznavanju znakov (angl. Image

Character Recongnition – ICR) in na tehnologiji za prepoznavanje človeških potez.

Tehnologija temelji na vizualnih objektih in testerjem omogoča izvajanje skripte navzkrižnih

klientov in platform. Avtomatizirana orodja za testiranje bodo postala manj zapletena,

22

enostavna za uporabo ter prilagodljiva. Uporabniki ne bodo potrebovali tedenskih opravil,

da se bodo naučili uporabljati orodje. Samo testiranje bo potekalo hitreje in z bolj

natančnimi rezultati. [13]

4.5 Odprtokodna orodja

Odprtokodna programska oprema (angl. Open Source Software – OSS) so orodja, izdana z

izvorno kodo in prosto dostopno licenco, s katero nosilec avtorskih pravic zagotavlja pravico

do študija, spreminjanje in distribucijo programske opreme komur koli. Odprtokodni model

in razvoj neodvisnih virov ustvarja vse bolj raznoliko področje oblikovanja perspektive.

Poročilo skupine Standish iz leta 2008 navaja, da je sprejetje odprtokodne programske

opreme povzročilo prihranke v višini 60 milijard $ na leto za potrošnike. Največja slabost

odprtokodne programske opreme so nedokončani izdelki, ki po navadi ostanejo le v

preizkusni različici. [16]

Veliko podjetij ima danes že sprejete rešitve za upravljanje testiranja, čeprav so vidne

izboljšave pri procesih. Preprosto se zanašajo na Excel in Googlove razpredelnice, kjer po

navadi prihaja do težav pri sami izvedbi ter s časovno izvedbo. V letu 2008 je programsko

opremo za upravljanje testiranja uporabljalo le 29 % organizacij. Značilno je, da pri

organizacijah prevladuje strah pred visokimi stroški licence in izbiranje najboljšega orodja

za njihovo uporabo. [19]

TestLink

Gre za spletno odprtokodno orodje za upravljanje testiranja, ki zagotavlja kakovost

programske opreme. Platforma je razvita za izvajanje različnih poročil, testnih primerov,

načrtov in projektov. Orodje potrebuje dostop do spletnega strežnika in podatkovne baze

za namestitev in zagon. Orodje je podprto s strani odprtokodne implementacije relacijske

podatkovne baze in objektno relacijskih podatkovnih baz (angl. Structured Query Language

– SQL). Za samo uporabo orodja potrebujemo spletni brskalnik. [19]

23

Struktura:

Produkti in testni plani

Produkti v TestLinku ostanejo trajno. Produkte je možno opraviti na veliko načinov. Produkt

vključuje specifikacije s testnih primerov, katere je treba sortirati po ključnih besedah.

Testni plani nastanejo, ko izvedemo testne primere. Testni plan je lahko sestavljen iz

primerov enega ali več produktov. Testni plani vključujejo gradnjo, primere in rezultate

testov.

Primeri testov in uporabniki

TestLink razdeli strukturo testnih primerov na tri ravni komponent, kategorij in testnih

primerov. Te stopnje so prisotne skozi vse aplikacije.

Komponente so starši kategorij. Vsaka kategorija ima lahko več kategorij. Za kategorije

velja, da so starši testnih primerov. Prav tako lahko imajo več testnih primerov. Testne

primere opredeljujemo med temeljne dele TestLinka. Med specifikacijo testov sodijo vse

komponente kategorij in testnih primerov v produktu. Pri testnih primerih imamo vse

komponente kategorij in testnih primerov v testnem planu.

Uporabniki imajo vlogo, ki jo definirajo razpoložljive funkcije TestLinka. [30]

Specifikacije testov:

Kreiranje testnih primerov

Izvajalec testov mora upoštevati strukturo: komponent, kategorij in testnih primerov. Na

začetku kreiramo komponente za produkt. Nato lahko dodamo opise, ki jih bo možno

natisniti. Komponente vsebujejo kategorije, za katere velja, da imajo podoben pomen,

vendar druge stopnje specifikacije za testiranje in vključujejo le testne primere.

Uporabnik lahko testne primere premika in kopira.

Testni primeri so zgrajeni iz naslednjih delov:

naslov: lahko vključuje kratek opis ali kratico;

povzetek: kratek ter je namenjen samo pregledu;

koraki: opisujejo testni scenarij, lahko vključujejo pogoj in informacije;

rezultati: opisane kontrolne točke in pričakovanja testnega produkta ali sistema.

24

Testne primere, kategorije in komponente lahko izbrišemo iz testnega plana s pomočjo

dovoljenj samega uporabnika. Brisanje podatkov je lahko koristno, če se najprej ustvari plan

testiranja, kjer ni nobenih rezultatov. Brisanje podatkov, kjer obstajajo rezultati, povzroči

izgubo vseh rezultatov, povezanih z njimi, zato je priporočena sama previdnost pri uporabi

te funkcije. [31]

Tarantula

Tarantula je sodobno orodje za izvajanje testiranja programske opreme v agilnih

programskih projektih. Tarantulo štejemo med odprtokodna programska orodja. Orodje

želi postati najboljše odprtokodno orodje za upravljanje testiranje, predvsem pri:

agilnem testiranju,

upravljanju testiranja,

poročanju,

uporabnosti.

Tarantula je popolnoma brezplačno orodje ter pod splošno licenco (angl. General Public

License – GNU) GPLv3. Orodje je razvilo podjetje Prove Experte, vodilno podjetje za

testiranje agilne programske opreme na Finskem. Z uradne strani lahko prenesemo

preizkusno različico. [3]

Mozilla Testopia

Testopia je pri upravljanju testiranja odprtokodna razširitev za Bugzillo. Narejena je kot

generično orodje za spremljanje testnih primerov. Organizacijam omogoča integracijsko

poročanje o napakah s primeri rezultatov pri testiranju. Orodje so razvili: Greg Hendricks,

Vance Baarda in Ed Fuentetaja. Čeprav je orodje narejeno za programsko testiranje, se

lahko uporablja pri virtualnem inženirskem procesu.

Orodje ima vključene naslednje lastnosti:

integracija z Bugzillinimi produkti, komponentami, različicami in mejniki za

omogočanje enotnih upravljalnih vmesnikov za objekte na visoki ravni;

uporabnikom dovoljuje prijavo na eno orodje in uporablja pravice Bugzilline skupine

za spreminjanje testnih objektov;

25

uporabnikom dovoljuje pritrjevanje napak v izvajalnem testnem primeru za

centralizirano upravljanje programskega procesa. [32]

Orodje ima na voljo različice od 1.0 do 2.5, ki so brezplačno dostopne na uradni strani. Od

različice 2.3 dalje, ki je podprta z Bugzillo 3.4, so na voljo nove lastnosti:

izvoz razširljivih in označevalnih (angl. Extensible Markup Language – XML)

dokumentov ter uvažanje testnih planov in otrok,

izvoz ločenih (angl. Comma – Separated Values – CSV) testnih primerov in

rezultatov,

nastavitev prioritet v dvojnih primerih,

nove klonirane možnosti,

uporaba knjižnice Extjs 3.0,

pretvarjanje orodja v pravilne Bugzilline razširitve,

številni popravki napak. [32]

QABook

QABook je orodje za upravljanje testiranja, ki omogoča kreiranje, upravljanje in urejanje:

zahtev,

testnih primerov,

testnih izvajanj,

napak,

okolij,

poročanj.

Orodje je dostopno v namizni verziji, spletni ali Microsoft SharePoint kot uporabniški

vmesnik v prostoru ali v oblaku.

Namizna verzija nam omogoča brezplačen prenos z uradne strani. Za ostale verzije je

potrebno povpraševanje za tridesetdnevno preizkusno verzijo. [29]

QABook je na voljo posameznikom ali ekipam. Zasnovan je bil zaradi reševanja številnih

vprašanj, ki jih lahko opazimo pri ostalih orodjih za upravljanje testiranja.

26

Na voljo imamo štiri različice s tridesetdnevno preizkusno uporabo:

Desktop,

BugReach,

BugShare,

Enterprise.

Iz spodnje slike (Slika 4.2) lahko razberemo razporeditev možnosti, ki so na voljo.

Slika 4.2: Razporeditev možnosti QABook. [21]

FitNesse

Odprtokodno orodje FitNesse je avtomatizirano orodje za testiranje programske opreme.

Temelji na Framework-u za integracijske teste ter je zgrajen za izvajanje sprejemnega

testiranja in ne za testiranje programskih enot. Testi se izvedejo sistemsko ter vrnejo

izhodne podatke uporabnikom. Prednost takšnega testiranja je, da omogoča hitre povratne

informacije uporabniku. Razvili so ga v jeziku Java, in sicer so to bili Robert C. Martin, Micah

D. Martin, Patrick Wilson-Welsh in ostali FitNesse razvijalci. Orodje je na začetku bilo

podprto v Javinem jeziku, čez čas pa so bili dodani še ostali programski jeziki: Python, Ruby,

Delphi in C#. [10]

27

Orodje se izvede s pomočjo Wiki strani, ki zahteva po meri napisane programske kode

(Fixtures). Programska koda definira povezavo med Wiki ter sistemom za testiranje (SUT –

angl. System Under Test). Pri izvedbi sklopa deluje na vpoklicu sistema za testiranje, z

ustreznimi parametri, ki se po sami izvedbi vrnejo na Wiki stran. Na spodnji sliki (Slika 4.3)

imamo prikazan postopek izvedbe testiranja v orodju FitNesse. [20]

Slika 4.3: Postopek izvedbe testiranja v orodju FitNesse. [20]

Orodje podpira dve vrsti testiranja, in sicer: seznamsko metodo (angl. SLIM – Simple List

Invocation Method) in integrirani model za testiranje (angl. FIT – Framework Integrated

Test). Integrirani model spada med starejšo vrsto testiranja, v katerem že nekaj časa ni

mogoče razvijati. Zaradi kompleksnosti in podpore različnih platform je bilo ustvarjeno

testiranje po seznamski metodi. Različica, ki testira po seznamski metodi, za razliko od FIT-

a omogoča uporabo različnih vrst programskih jezikov in ni odvisna od modela. [20]

TestRail

TestRail je orodje za upravljanje testiranja programske opreme. Zgrajeno je iz spletnega

uporabniškega vmesnika, ki omogoča preprosto kreiranje testnih primerov in upravljanje

testov. S pomočjo nadzorne plošče in poročil o delu omogoča preprosto sledenje in

spremljanje posameznih testov in projektov. Prav tako nam omogoča vpogled o napredkih

testiranja, osebnih seznamov, filtrov ter elektronskih obvestil.

TestRail vključuje integracijo prepoznavnih orodij: JIRA, Redmine, FogBugz, Selenium …

Orodje s pomočjo hitrega in intuitivnega uporabniškega vmesnika omogoča preprosto

upravljanje ročnih, raziskovalnih in avtomatiziranih testov. [4]

28

Zephyr

Orodje Zephyr je na voljo v treh različicah, in sicer: Zephyr Enterprise, Zephyr For JIRA in

Zephyr Community Edition. Različica Enterprise je v integraciji z orodjem JIRA ter je

plačljiva, medtem ko različica Zephyr FOR JIRA vsebuje JIRO in je na voljo preizkusno za

obdobje tridesetih dni. [38]

Prosto dostopna različica Zephyr Community Edition zagotavlja bogate funkcionalnosti pri

kreiranju in izvedbi testnih primerov z manj napora.

Različica Community Edition je namenjena manjšim skupinam do največ deset uporabnikov

ali manj, ki upravlja testiranje trenutnih projektov, ali pa je namenjena ekipam, ki so šele

začele z upravljanjem testiranja. [6]

29

5 PRIMERJAVA ORODIJ

Primerjali smo orodji TestLink in Testopia s prosto dostopno licenco ter orodji TestRail in

Zephyr, ki sta plačljivi. Iz spodnje tabele (tabela 5.1) lahko razberemo razlike glede na

podporo, uvoz in izvoz testnih primerov in sledenje.

Tabela 5.1: Primerjava orodij: TestRail, TestLink, Zephyr in Testopia (podpora, uvoz in izvoz testnih primerov in sledenje). [9]

Orodja TestRail TestLink Zephyr Testopia

Podpora Vključuje Saas,

strokovne storitve

in usposabljanje.

Odprtokodno

orodje s

prosto

dostopno

dokumentacij

o.

Vključuje SaaS,

strokovne

storitve.

Podprt spletno

ali preko

telefona.

Odprtokodno

orodje s prosto

dostopno

dokumentacijo.

Uvoz/izvoz

testnih

primerov

Uvoz in izvoz

testnih primerov

XML s povezavo

CSV/Excel/TestLink

do TestRail skript.

Uvoz in izvoz

testnih

primerov kot

XML

Uvoz in izvoz

testnih

primerov kot

Excel datoteke.

Uvoz testnih

primerov z uporabo

XML iz drugih

Testopia testnih

primerov kot CSV

ali XML.

Sledenje V integraciji je

lahko z Jira,

FogBugz, Trac,

Redmine, Bugzilla

…

Integracijsko

sledenje ni

voljo.

Integrirano je

lahko z Bugzilla

ali Jira.

Bugzilla je

ponastavljena

platforma za

iskanje napak, ki je

lahko integrirana z

Jira.

30

V drugem delu tabele (Tabela 5.2) smo orodja TestRail, TestLink, Zephyr in Testopia razdelili

glede na ceno , uporabo, konfiguracijo in povezavo z el. pošto.

Tabela 5.2: Primerjava orodij TestRail, TestLink, Zephyr in Testopia (cena, uporaba, konfiguracija in povezava z el. pošto). [9]

Orodja TestRail TestLink Zephyr Testopia

Cena TestRail – Server

Approx – 239,00

$ na uporabnika

TestRail – SaaS –

25,00 $ na

mesec na enega

uporabnika.

Prosto

dostopno

orodje.

Community Edition (10

uporabnikov, 1 projekt)

– prosto dostopna.

Zephyr for Jira – 10,00–

14.000,00 $ (10 –

10.000 uporabnikov).

Zephyr Enterprise 96,00

$ na mesec na

uporabnika.

Prosto

dostopno

orodje.

Uporaba,

konfigurac

ija

Zgrajen iz

preprostega

vmesnika za

upravljanje.

Uporabniku

zelo

prilagodljiv

zaradi

opredeljivih

polj.

Fleksibilen sistem za

upravljanje testiranja.

Zagotavlja po meri

nadzorne plošče.

Enostavna uporabi pri

ponovni uporabi testnih

primerov.

Prijazen

vmesnik za

uporabo.

Povezava z

elektronsk

o pošto

Poročanje HTML

prilog preko

elektronske

pošte.

Poročanje se

lahko izvede

direktno

preko orodja.

/ Uporablja

elektronsko

poročanje iz

Bugzille.

31

V zadnjem delu tabele (Tabela 5.3) smo orodja TestRail, TestLink, Zephyr in Testopia

razdelili glede na avtomatizacijo in integracijo, poročanje, statistko in grafe.

Tabela 5.3: Primerjava orodij TestRail, TestLink Zephyr in Testopia (avtomatizacija in

integracija, poročanje, statistika in grafi). [9]

Orodja TestRail TestLink Zephyr Testopia

Avtomatiz

-acija

in

integracij

a

Integracija z

BugTrackers,

avtomatskimi

testnimi orodji,

zahtevami.

Lahko je v

integraciji z

Bugzilla, Mantis,

Jira. Avtomatsko

upravljanje,

testiranje je

mogoče s

spletnimi

storitvami XML

RPC.

Spletne

storitve (API)

temeljijo z

Java, Python,

Perl in PHP.

Orodje je

lahko

integrirano s:

Selenium,

JUnit, Test

Complete,

Load Runner,

Rational

Robot …

Avtomatsko

upravljanje

testiranja je

mogoče s

spletnimi

storitvami XML

RPC. Orodje za

izvajanje uporablja

orodja, kot so:

TestPartner,

Selenium, Perl

modules, PHP unit

...

Poročanje

,

statistika,

grafi

Omogoča

poročila o

napredku in

dejavnosti v

realnem času.

Poročila o testih,

meritve,

grafikoni, izvedba

testov in

spremljanje.

Orodje generira

poročila v

HTML/CSV/Excel

formatih.

Zagotavlja

meritve in

poročila.

Končna poročila,

velike napake,

najdene napake v

planu, poročila za

tiskanje v

odstotkih, ocenjen

čas v primerjavi z

aktualnim.

32

5.1 Primerjava odprtokodnih orodij

Za primerjavo smo izbrali zgoraj opisana orodja za upravljanje testiranja: TestLink,

Tarantula, Testopia in QABook. Glede na določene kriterije smo pri orodjih predstavili

razvijalce, licence, zahteve in vrste testiranja, ki so vidna v spodnji tabeli (Tabela 5.4).

Tabela 5.4: Primerjava orodij za upravljanje testiranja

TestLink Tarantula Mozilla

Testopia

FitNesse QABook

Desktop

Razvijalec TeamTest Prove

Expertise

Greg

Hendricks,

Vance

Baarda, Ed

Fuentetaja

Robert C.

Martin, Micah

D. Martin,

Patrick Wilson-

Welsh

QA

Works

Compan

y

Jezik izdelave PHP PHP Perl Java Java

Licenca GNU –

General

Public

License

GNU GPLv3 Mozilla

Public

Licence

CPL – Common

Public License

Copy of

QABook

OS Windows,

Linux, Mac

Windows,

Linux, Mac,

CentOS

Windows,

Linux

Windows,

Linux,

Mac

Windows

XP/Vista/

7/8

Avtomatizirani

unit testi

Ne Ne Ne Da Ne

Avtomatizirani

GUI testi

Da Da Ne Ne Da

Ročni testi Da Da Da Da Da

Upravljanje

napak

Da Da Da Da Da

Na voljo od leta 2004 2008 2007 2001 2010

33

6 PRIMER TESTIRANJA V ORODJU FITNESSE

6.1 Opis problema

Uporabnikom smo želeli prikazati statistične podatke o slovenskih nogometnih klubih. Za

vsaki klub posebej smo lahko izpisali oceno glede na število odigranih tekem in zmag. Prav

tako smo lahko izpisali število porazov posameznega slovenskega kluba.

S pomočjo orodja FitNesse smo izvedli sprejemno testiranje, kjer smo primerjali aktualne

in pričakovane rezultate.

6.2 Programski del

Najprej smo napisali programsko kodo, ki se uporablja za obdelavo tabelne vsebine. V

programu smo določili razred z imenom SlovenskiKlubi, v katerem smo deklarirali

spremenljivke za uporabo in prikaz. V razred smo dodali še dve funkciji, kjer smo izračunali

število porazov in oceno glede na število odigranih tekem in zmag. Iz spodnje slike (Slika

6.1) lahko razberemo programsko kodo za samo izvedbo in prikaz statističnih podatkov o

slovenskih nogometnih klubih, ki je napisana v programskem jeziku Java.

34

Slika 6.1: Programska koda za izvedbo tabelne vsebine.

35

6.3 Testni primeri

Za izvedbo testnih primerov smo najprej ustvarili svojo podstran ter se nanjo preusmerili,

kot je tudi prikazano na spodnji sliki (Slika 6.2). Podstran smo poimenovali TestSloKlubi ter

se s pomočjo URL naslova (http://localhost:/FrontPage.TestSloKlubi) preusmerili na

ustvarjeno podstran, v kateri smo uredili testni primer.

Slika 6.2: Dodajanje testne strani in preusmeritev.

36

Za testni primer smo uporabili pet slovenskih klubov, pri katerih smo testirali poraze in

ocene glede na število odigranih tekem in zmag.

Na ustvarjeni podstrani smo testni primer uredili tako, da smo najprej zapisali, da bomo

testirali po metodi SLIM. Zatem smo dodali vrstico, za dodajanje Javine datoteke pod

imenom fitnesseTest in se sklicali na razred SlovenskiKlubi. Nato smo za pregled statističnih

podatkov dodali parametre (imeKluba, tekme, zmage in remi). Poleg parametrov smo

določili dve funkciji (porazi in ocena) za testiranje. Celoten postopek je viden na spodnji sliki

(Slika 6.3).

Določiti je bilo treba:

vrsto testiranja,

lokacijo datoteke,

razred,

parametre.

Slika 6.3: Ureditev testnega primera.

37

Testni primer smo nato shranili in dobili ustrezen prikaz v tabelni obliki, kot prikazuje slika

(Slika 6.4). Pri metodah, ki smo ju testirali, smo imeli dopisana vprašaja, kar pomeni, da smo

testirali poraze in ocene slovenskih nogometnih klubov.

Slika 6.4: Prikaz testnega primera po ureditvi.

38

Za primerjavo smo izdelali testni primer z nepravilnimi rezultati, v katerem smo pri

nogometnem klubu Maribor spremenili izračune porazov in ocen, ter pri nogometnem

klubu Domžale spremenili izračun porazov, kar je razvidno v naslednji sliki (Slika 6.5).

Slika 6.5: Testni primer z nepravilnimi rezultati.

Spodnja slika (Slika 6.6) nam prikazuje primer z manjkajočim številom porazov pri klubu

Celje ter neustrezni niz porazov pri istem klubu.

Slika 6.6: Testni primer v manjkajočem in v napačnem rezultatu.

39

6.4 Rezultati testiranja

Za izvedbo testiranja smo izbrali pet slovenskih nogometnih klubov, ki so odigrali največ

tekem. Med testiranjem nam je program pravilne rezultate obarval z zeleno barvo, medtem

ko je napačne obarval z rdečo barvo. Z rdečo barvo so bili obarvani rezultati, ki se niso

ujemali s pričakovanimi rezultati.

V spodnji sliki (Slika 6.7) imamo pri vsakem klubu posebej prikazane pravilne izračune ocen

in porazov. Iz slike je razvidno, da se vsi rezultati ujemajo in da v tem testnem primeru ne

pričakujemo drugih rezultatov. Prav tako imamo z zeleno barvo obarvano ime paketa in

razreda, kar pomeni, da smo izvedli pravilno datoteko in dostopali do pravega razreda.

Slika 6.7: Rezultati testnega primera s pravilnimi izračuni.

40

Iz testnega primera z napačnimi izračuni smo razbrali, da imamo sedem pravilnih rezultatov

in tri napačne, kar je razvidno iz spodnje slike (Slika 6.8). Do neujemanja je prišlo pri

nogometnima kluboma Maribor in Domžale, za katera velja, da se aktualni rezultati ne

ujemajo s pričakovanimi rezultati.

Slika 6.8: Rezultati testnega primera z napačnimi rezultati.

41

V naslednjem testnem primeru, kot nam prikazuje spodnja slika (Slika 6.9), je program javil

osem pravilnih rezultatov, enega napačnega ter enega, ki ga je ignoriral. Za metodo porazi

je pri klubu Celje rezultat obarval s sivo barvo, kar pomeni, da je bil rezultat ignoriran zaradi

praznega vnosa. Prav tako smo opazili, da pri klubu Domžale pričakujemo znakovni niz, ki

pa je v našem primeru celo število.

Slika 6.9: Rezultati testnega primera v praznem in v napačnem vnosu.

42

7 SKLEP

Testiranje temelji na razvoju kakovostne programske opreme. Za upravljanje testiranja smo

primerjali prosto dostopna orodja: TestLink, Tarantula, Mozilla Testopia, FitNesse, QaBoox

Desktop ter orodji TestRail in Zephyr. Ugotovili smo, da večina orodij že temelji na testnih

avtomatizacijah, zaradi česar so postala manj zapletena, enostavna za uporabo ter

prilagodljiva. Največja slabost nekaterih prosto dostopnih orodij pa ostaja pri tem, da

ostanejo le v preizkusni različici. Za podjetja, organizacije in posameznike je značilno, da

zaradi samih stroškov in nevednosti uporabe raje posežejo po Google razpredelnicah in

Excelu.

Diplomsko delo smo razdelili na dva dela: v teoretičnem delu smo preučili vrste testiranja,

glavne nivoje testiranja ter orodja za upravljanje testiranja. V praktičnem delu pa smo

izvedli primer testiranja v prosto dostopnem orodju FitNesse. Pri vzpostavitvi nismo naleteli

na težave, paziti smo le morali, da smo, če smo uporabljali še kateri drugi spletni strežnik,

uporabili ustrezna vrata, ki imajo privzeto vrednost 80. Ugotovili smo, da orodje ni

uporabno za testiranje programskih enot (unit testing) in za testiranje grafičnih vmesnikov.

Orodje se požene preko Wiki strežnika, ki ne potrebuje namestitve ali konfiguracije. Na

podlagi sestavljenega primera smo izvedli sprejemno testiranje, kjer smo primerjali

aktualne in pričakovane rezultate. Za sam prikaz in izvedbo slovenskih nogometnih klubov

smo napisali programsko kodo, napisano v jeziku Java. Pri samem pisanju testnih primerov

nismo imeli večjih težav, treba je bilo le pravilno navesti: vrsto testiranja, lokacijo datoteke,

razred in parametre. Orodje FitNesse nam omogoča dve vrsti testiranja: FIT in SLIM. V

našem primeru smo uporabili novejšo metodo SLIM, ki za razliko od testiranja FIT ni odvisna

od programskega jezika in platform.

Orodje FitNesse je priporočljivo za majhne in srednje velike projekte. Ni priporočljivo in

namenjeno obsežnim projektom, za katere velja, da so potrebni dodatni stroški pri sami

izvedbi testiranja. Problemi se lahko pojavijo pri uporabnikih z neustreznim znanjem, saj ne

omogoča funkcij, kot so avtomatsko preverjanje črkovanja ali urejevalnika besedila. Pri

izvozu datotek lahko naletimo na težavo, ki vpliva na samo preglednost in natisnjene

dokumente, saj ne moremo izvoziti datotek v PDF ali v katerem drugem formatu.

43

VIRI

[1] About Test Management. Dostopno na: http://www.testmanagement.com/about-

test-management.html [12.8.2016]

[2] Acceptance Testing. Dostopno na:

http://softwaretestingfundamentals.com/acceptance-testing/ [19.4.2017]

[3] Agile Test Management. Dostopno na: http://www.testia.fi/ [9.7.2016]

[4] Arsenault, R. TestRail. Dostopno na: https://www.utest.com/tools/testrail [17.5.2017]

[5] Arsenault, R. When You Should Choose Manual vs. Automated Testing, 2014.

Dostopno na: https://www.utest.com/articles/when-you-should-choose-manual-vs-

automated-testing [20.7.2016]

[6] Arsenault, R. Zephyr Community Edition. Dostopno na:

https://www.utest.com/tools/zephyr-enterprise-edition [18.5.2017]

[7] Black – box testing. Dostopno na: https://en.wikipedia.org/wiki/Black-box_testing

[18.7.2016]

[8] Differences Between Black Box and White Box Testing. Dostopno na:

http://softwaretestingfundamentals.com/differences-between-black-box-testing-and-

white-box-testing/ [20.7.2016]

[9] Evaluating Test Management Tools. Dostopno na:

http://www.cigniti.com/blog/simplify-testing-with-the-right-combination-of-test-

management-tools/ [25.3.2017]

[10] FitNesse. Dostopno na: https://en.wikipedia.org/wiki/FitNesse [10.8.2016]

[11] IEE 829 Documentation. Dostopno na:

http://www.coleyconsulting.co.uk/IEEE829.html [16.7.2016]

[12] IEEE 829. Dostopno na: https://en.wikipedia.org/wiki/Software_test_documentation

[16.7.2016]

[13] Kodituwakku, W. Open Source Software Quality Assurance Testing Tools, Chapter 3 -

Future of Software Testing Tools. Dostopno na:

http://www.slideshare.net/vharshana/open-source-sqatools [15.7.2016]

[14] Kopel, E. Software Test Management Tool Evaluation Framework, Chapter 6 - Test

Management Tool Requirements, 2012 [12.8.2016]

44

[15] Manual Testing vs Automated Testing – Pros and Cons, 2015. Dostopno na:

http://www.optimusinfo.com/manual-testing-vs-automated-testing-pros-and-cons/

[20.7.2016]

[16] Open Source Software. Dostopno na: https://en.wikipedia.org/wiki/Open-

source_software [4.7.2016]

[17] Podgorelec, V. Informacijski sistemi, Testiranje po metodi bele skrinje. Dostopno na:

http://mafalda.informatika.uni-mb.si/2007-08/isizr/predavanja/tisk/11-testiranje.pdf

[19.7.2016]

[18] Podgorelec, V. Informacijski sistemi, Testiranje po metodi črne skrinje. Dostopno na:

http://mafalda.informatika.uni-mb.si/2007-08/isizr/predavanja/tisk/11-testiranje.pdf

[18.7.2016]

[19] Poschenrieder, M. Top free test case management tools. Dostopno na:

https://blog.testmunk.com/top-free-test-case-management-tools/ [6.7.2016]

[20] Pragt, E. FitNesse Overview. Dostopno na: https://dzone.com/refcardz/getting-

started-fitnesse [12.8.2016]

[21] QABook Product Set. Dostopno na:

http://www.freetestmanagementtool.com/index.html [12.7.2016]

[22] Software Testing – Levels. Dostopno na:

http://www.tutorialspoint.com/software_testing/software_testing_levels.htm

[22.7.2016]

[23] Software testing techniques. Dostopno na:

http://www.his.sunderland.ac.uk/~cs0mel/comm83wk5.doc [19.7.2016]

[24] Software Validation. Dostopno na: http://istqbexamcertification.com/what-is-

validation-in-software-testing-or-what-is-software-validation/ [26.7.2017]

[25] Test Management Tools, Implementation. Dostopno na:

https://en.wikipedia.org/wiki/Test_management_tools#Implementation [4.7.2016]

[26] Test Management Tools: https://en.wikipedia.org/wiki/Test_management_tools

[4.7.2016]

[27] Test Management, What is Test Management? Dostopno na:

https://www.tutorialspoint.com/software_testing_dictionary/test_management.htm

[12.6.2017]

45

[28] Test Menagament Tools, Definitions. Dostopno na:

https://en.wikipedia.org/wiki/Open-source_software#Definitions [4.7.2016]

[29] Test Tools – QABook. Dostopno na: http://www.qabook.com/ [10.7.2016]

[30] TestLink UserManual, Overall structure. Dostopno na:

http://testlink.sourceforge.net/docs/documents/end-users/manual.html#d0e7

[6.7.2016]

[31] TestLink UserManual, Test Specification. Dostopno na:

http://testlink.sourceforge.net/docs/documents/end-users/manual.html#d0e39

[6.7.2016]

[32] Testopia. Dostopno na: https://developer.mozilla.org/en-

US/docs/Mozilla/Bugzilla/Testopia [10.7.2016]

[33] The Types of Acceptance testing. Dostopno na:

http://istqbexamcertification.com/what-is-acceptance-testing/ [19.4.2017]

[34] Vu Lam. 4 Essential Features that Test Management Tools Should Have. Dostopno na:

http://www.softwaretestinghelp.com/features-test-management-tools/ [22.12.2016]

[35] What is Non-functional testing. Dostopno na:

http://istqbexamcertification.com/what-is-non- functional-testing-testing-of-

software-product-characteristics/ [7.8.2016]

[36] What is System Testing. Dostopno na: http://www.guru99.com/system-testing.html

[5.8.2016]

[37] White – box testing. Dostopno na: https://en.wikipedia.org/wiki/White-box_testing

[19.7.2016]

[38] Zephyr Products. Dostopno na: https://www.getzephyr.com/products [18.5.2017]

46

47

48

49