Upload
others
View
17
Download
0
Embed Size (px)
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