Upload
others
View
5
Download
0
Embed Size (px)
UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO
Robi Kuserbanj
PRIMERJAVA ORODIJ ZA TESTIRANJE SPLETNIH STORITEV
Diplomska naloga
Maribor, november 2008
UNIVERZA V MARIBORU
FAKULTETA ZA ELEKTROTEHNIKO,
RAČUNALNIŠTVO IN INFORMATIKO
2000 Maribor, Smetanova ul. 17
Diplomska naloga visokošolskega študijskega programa
PRIMERJAVA ORODIJ ZA TESTIRANJE SPLETNIH STORITEV
Študent: Robi Kuserbanj
Študijski program: Visokošolski, računalništvo in informatika
Smer: Informatika
Mentor: red. prof. dr. MARJAN HERI ČKO
SoMentor: viš. pred. mag. BOŠTJAN KEŽMAH
Maribor, november
ZAHVALA
Zahvaljujem se svojemu mentorju dr. Marjanu Heričku, somentorju Boštjanu Kežmahu, ter
Urošu Goljatu za pomoč, strokovne nasvete ter potrpežljivo pregledovanje diplomske naloge.
Za vso pomoč in nasvete bi se rad še zahvalil Andreju Krajncu.
Na koncu se še zahvaljujem svojim staršem, kateri so mi omogočili študij.
Primerjava orodij za testiranje spletnih storitev
Klju čne besede: programska oprema, spletne storitve, testiranje, primerjava orodij
UDK: 004.415.53:004.777(043.2)
Povzetek:
V diplomskem delu smo opisali in primerjali orodja za testiranje spletnih storitev.
Testiranje sodi k najpomembnejšim stvarem današnjega sveta, predvsem v sedanji dobi
računalništva. Tako ima danes že skoraj vsako gospodinjstvo svoj računalnik, s katerim
opravlja in dostopa do različnih stvari in od katerih pričakuje, da bodo vedno delovale
brezhibno. Prav zaradi tega je testiranje tako pomembno, kajti s testiranjem preprečimo
morebitne napake in druge nepotrebne težave. Tako smo v začetnih poglavjih spoznali
razlike med programsko opremo oz. testiranjem le-te in testiranje spletnih storitev. Da bi
bilo testiranje programske opreme in spletnih storitev čim enostavnejše, uporabljamo pri
tem različna orodja. Tako smo v ospredje te diplomske naloge postavili orodja, s katerimi
testiramo spletne storitve, jih primerjamo med sabo itd. Predvsem smo hoteli prikazati, kaj
nekatera orodja imajo in česa druga nimajo. S tem, ko smo jih primerjali, testirali itd.,
smo prišli do zanimivih dejstev, katera so prikazana in komentirana v različnih tabelah.
Comparison of Tools for Web-Services Testing
Key words: computer software, web services, testing, tool-comparison UDK: 004.415.53:004.777(043.2) Abstract:
In diplome work we described and compared web-services testing tools. Testing is
nowadays one of the most important things, especialy in the present computer era. Almost
every household has its own computer, with which it manages and accesses different things
and expects that they will always work perfectly. That is why testing is so important, we
can namely prevent future mistakes and other unimportant problems. In the first few
chapters we aknowledged the differences between computer software and the testing of it
and web services and their testing. To make the testing of computer software and web
services easier, we use specific tools. The main stress in the Diploma is on tools, with
which we test web services, compare them with each other and so on. We wanted to
present the advantages and disadvantages of individual tools. By comparing and testing
them, we came to interesting facts, which have been presented and commented in different
tables.
KAZALO:
1 UVOD....................................................................................................................... 1
2 TESTIRANJE.......................................................................................................... 3
2.1 Glavni mejniki ................................................................................................... 3
2.2 Kaj je testiranje? ................................................................................................ 3
2.2.1 Referenčna meritev............................................................................................4
2.2.2 Verifikacija in validacija ................................................................................... 4
2.2.3 Uspešnost testiranja ........................................................................................... 5
2.3 Kdo nadzoruje preizkuševalca ? ........................................................................ 5
2.4 Pri testiranju je dobro vedeti.............................................................................. 6
3 TESTIRANJE PROGRAMSKE OPREME .............................................................. 7
3.1. Testiranje ........................................................................................................... 7
3.1.1 Funkcionalnost .................................................................................................. 8
3.1.2 Zanesljivost........................................................................................................ 8
3.1.3 Uporabnost ........................................................................................................ 8
3.1.4 Učinkovitost ...................................................................................................... 8
3.1.5 Vzdrževalnost .................................................................................................... 9
3.1.6 Prenosljivost ...................................................................................................... 9
3.2 Stopnje testiranja programske opreme ............................................................ 12
3.2.1 Testiranje modulov.......................................................................................... 12
3.2.2 Integracijsko testiranje..................................................................................... 12
3.2.3 Testiranje funkcionalnosti ............................................................................... 13
3.2.4 Sistemsko testiranje ......................................................................................... 13
3.2.5 Prevzemno testiranje........................................................................................ 13
3.2.6 Regresijsko testiranje....................................................................................... 14
3.2.7 Strukturno testiranje ........................................................................................ 14
3.3 Najpogostejše metode testiranja programske opreme ..................................... 15
3.3.1 Testiranje po metodi ''bele škatle'' ................................................................... 15
3.3.2 Testiranje po metodi ''črne škatle'' ................................................................... 15
3.3.3 Testiranje po metodi ''sive škatle'' ................................................................... 15
3.3.4 Primerjava testiranja po metodi ''bele škatle'' in ''črne škatle''......................... 16
4 SPLETNE STORITVE............................................................................................ 17
4.1 Principi spletnih storitev.................................................................................. 17
4.2 Zgodovina........................................................................................................ 17
4.3 Arhitektura....................................................................................................... 18
4.3.1 Odjemalec........................................................................................................ 18
4.3.2 Strežnik............................................................................................................ 19
4.3.3 Jezik XML....................................................................................................... 19
4.4 Specifikacije spletnih storitev.......................................................................... 19
4.4.1 Protokol SOAP ................................................................................................ 20
4.4.2 Jezik WSDL..................................................................................................... 21
4.4.3 Register UDDI................................................................................................. 22
4.5 Dodatki k specifikaciji spletnih storitev .......................................................... 24
4.6 Storitveno usmerjena arhitektura SOA............................................................ 26
4.6.1 Kaj obljublja SOA? ......................................................................................... 27
4.6.2 Naslednja generacija SOA............................................................................... 28
4.7 Arhitektura REST............................................................................................ 28
4.8 Arhitektura WOA ............................................................................................ 30
5 TESTIRANJE SPLETNIH STORITEV.................................................................. 31
5.1 Dejstva pri testiranju spletnih storitev............................................................. 31
5.2 Testiranje strežnikov........................................................................................ 31
5.2.1 Funkcionalno testiranje ................................................................................... 32
5.2.2 Regresijsko testiranje....................................................................................... 32
5.2.3 Obremenitveno testiranje................................................................................. 33
5.2.4 Testiranje zmogljivosti .................................................................................... 33
5.3 Testiranje odjemalca........................................................................................ 34
5.4 Druge možnosti testiranja................................................................................ 35
5.4.1 Testiranje varnosti ........................................................................................... 35
5.4.2 Medsebojna interoperabilnost.......................................................................... 35
5.5 Glavni izzivi pri testiranju spletnih storitev ....................................................36
5.6 Faze testiranja spletnih storitev ....................................................................... 36
5.7 SOA testiranje z uporabo črne, bele in sive škatle .......................................... 39
5.7.1 Testiranje po metodi črne škatle...................................................................... 39
5.7.2 Testiranje po metodi bele škatle ...................................................................... 39
5.7.3 Testiranje po metodi sive škatle ...................................................................... 40
5.8 Testna orodja so ključna za uspeh spletnih storitev ........................................ 40
6 ORODJA ZA TESTIRANJE SPLETNIH STORITEV........................................... 42
6.1 Opis orodij ....................................................................................................... 42
6.1.1 Orodje SOAP Sonar ........................................................................................ 42
6.1.2 Orodje GreenHat.............................................................................................. 43
6.1.3 Orodje Parasoft SOAtest ................................................................................. 44
6.1.4 Orodje itko LISA 4 SOA................................................................................. 44
6.1.5 Orodje SoapUI................................................................................................. 46
6.1.6 Orodje JMeter .................................................................................................. 46
6.1.7 Orodje TestMaker (PushToTest Test Maker).................................................. 47
6.1.8 Orodje Altova XmlSpy.................................................................................... 47
6.2 Prikaz značilnosti posameznih orodij .............................................................. 48
7 ZNAČILNOSTI ORODIJ ....................................................................................... 50
7.1 Osnovna primerjalna tabela............................................................................. 50
7.3 Analiza raziskav .............................................................................................. 54
7.3.1 Funkcionalno testiranje ................................................................................... 54
7.3.2 Obremenitveno testiranje................................................................................. 55
7.3.3 Testiranje zmogljivosti .................................................................................... 55
7.3.4 Regresijsko testiranje....................................................................................... 56
7.3.5 Testiranje varnosti ........................................................................................... 56
7.3.6 Možnost validiranja ......................................................................................... 57
7.3.7 Podpora različnim protokolom........................................................................ 57
7.3.8 Poročanje o rezultatih ...................................................................................... 58
7.3.9 Podpora (dokumentov, baz, itd.) ..................................................................... 58
7.4 Uporabniške značilnosti orodij....................................................................... 59
7.4.1 Uporabniška analiza orodij.............................................................................. 60
8 SKLEP..................................................................................................................... 61
9 VIRI IN LITERATURA.......................................................................................... 63
UPORABLJENE KRATICE
SQA - Software Quality Assurance
WOA - Web Oriented Architecture
SOA - Service Oriented Architecture
REST - Representational State Transfer
API - Application Programming Interface
XML - Extensible Markup Language
HTTP - Hypertext Transfer Protocol
HTTPS - Hypertext Transfer Protocol Secure
RFC - Request for Comments
W3C - World Wide Web Consortium
SOAP - Simple Object Access Protocol
WSDL - Web Service Descripton Language
UDDI - Universal Descripton, Discovery and Integration
SMTP - Simple Mail Transfer Protocol
XMPP - Extensible Messaging And Presence Protocol
MIME - Multipurpose Internet Mail Extensions
EDA - Event Driven Architecture
HTML - Hypertext Markup Language
IT - Information technology
PDF - Portable Document Format
ESB - Enterprise Service Bus
XSLT - Extensible Stylesheet Language Transformations
JDBC - Java Database Connectivity
EJB - Enterprise Java Beans
DTD - Data Transfer Device
POP3 - Post Office Protocol version 3
IMAP - Internet Message Access Protocol
SSL - Secure Sockets Layer
SEZNAM SLIK
Slika 1: Grafični prikaz ISO/IEC 9126
Slika 2: Uporabnost karakteristik kakovosti po ISO 9126
Slika 3: Intenzivnost odpovedi
Slika 4: Prikaz arhitekture spletnih storitev
Slika 5: Konceptualni model WSDL 2.0
Slika 6: UDDI in SOAP
Slika 7: Sklad tehnologij spletnih storitev
Slika 8: Arhitektura SOA
Slika 9: Opredelitev URI
Slika 10: Arhitektura REST
Slika 11: Prikaz rasti orodij za avtomatizacijo testiranja
Slika 12: Arhitektura spletnih storitev
Slika 13: Delovanje orodja SOAPSonar
Slika 14: Prikaz IT tveganja in zanesljivosti SOA
Slika 15: Arhitektura orodja itko LISA 4 SOA
Slika 16: Arhitektura orodja TestMaker
SEZNAM TABEL
Tabela 1: Primerjava testiranja po metodi ''bele škatle'' in ''črne škatle''
Tabela 2: Prikaz značilnosti posameznih orodij
Tabela 3: Osnovna primerjava orodij
Tabela 4: Podrobna primerjava orodij
Tabela 5: Uporabniške značilnosti orodij
Primerjava orodij za testiranje spletnih storitev 1
1 UVOD
Še pred nekaj leti spletne storitve niso bile dovolj zanimive za uporabo, saj so bile zelo
počasne. To se je zaradi prizadevanja različnih razvijalcev spremenilo. Danes se
uveljavljajo kot ključna tehnologija za elektronsko poslovanje. Prav tako omogočajo
povezljivost med informacijskimi sistemi ne glede na platformo, programski jezik in
operacijski sistem. O spletnih storitvah govorimo kot o revolucionarni tehnologiji, kot o
nečem česar na področju informatike še ni bilo.
Pereča tema je testiranje spletnih storitev, ki postajajo vedno bolj kompleksne in jih je
posledično težje testirati. Prav zato bomo v diplomskem delu podrobno raziskali področje
testiranja spletnih storitev.
V začetku diplomske naloge smo opisali testiranje in ga v splošnem opredelili na vse
pomembnejše pojme, s katerimi se srečamo pri testiranju.
Ko smo spoznali posamezne pojme testiranja in se zavedli kako pomembno je
testiranje, nadaljujemo s predstavitvijo programske opreme. Nato smo opisali vse faze
razvoja programske opreme ter testiranje le-te. Testiranje programske opreme je proces, ki
se uporablja za 'merjenje' kvalitete pri razvijanju računalniške programske opreme. Tukaj
se najprej osredotočimo na samo kvaliteto testiranja in prikažemo vse njegove
najpomembnejše lastnosti, kot so pravilnost, popolnost, varnost itd. Ko spoznamo te
pomembne osnove, začnemo s spoznavanjem metod testiranja po beli, črni in sivi škatli, ki
so najpomembnejše metode testiranja programske opreme.
Po opisu testiranja programske opreme opišemo spletne storitve in na začetku prav tako
predstavimo celoviten pogled na spletne storitve. Začnemo z zgodovino in nadaljujemo s
predstavitvijo vseh pomembnejših lastnosti spletnih storitev. Predstavimo arhitekturo,
specifikacije, opišemo storitveno usmerjene arhitekture, spletno usmerjene arhitekture ter
princip REST (ang. Representational State Transfer je arhitektura programske opreme za
hipermedijske sisteme, kot je svetovni splet). Po opisu spletnih storitev preidemo na
testiranje spletnih storitev, ki predstavlja glavni del diplomske naloge.
Testiranje spletnih storitev smo razdelili na tri dele, in sicer na testiranje strežnikov,
testiranje odjemalcev in na druge možnosti testiranja. Ta razdelitev se nam zdi dokaj
Primerjava orodij za testiranje spletnih storitev 2
pomembna, saj se moramo najprej odločiti, kateri del bomo testirali in katero testiranje
bomo izbrali. Vse smo dodatno prikazali skozi faze testiranja, ko smo časovno prikazali,
kako je potekalo oz. kako poteka samo testiranje. Prav tako kot pri testiranju programske
opreme se tudi tukaj pojavijo pomembne metode testiranja in sicer testiranje po metodi
bele, črne in sive škatle.
Ker je ročno testiranje spletnih storitev zamudno opravilo, smo raziskali možnosti
uporabe orodij za avtomatizirano testiranje spletnih storitev. Prav tako smo poizkušali najti
orodje, ki bi bilo najprimernejše za našo nalogo, saj so različna orodja pri testiranju
spletnih storitev bistvenega pomena. Uporabili smo nekaj najbolj uveljavljenih orodij za
testiranje spletnih storitev, ki smo najprej jih najprej opisali, predstavili njihove
karakteristike in jih na koncu medsebojno primerjali.
V zadnjem poglavju smo s pomočjo najpomembnejših karakteristik, ki smo jih
predstavili v prejšnjih poglavjih, primerjali orodja. Najprej smo oblikovali osnovno
primerjalno tabelo, nato pa nadaljevali s podrobno primerjavo. Tako smo dobili veliko
tabelo z najpomembnejšimi primerjalnimi podatki o orodjih. Na koncu smo dodali tudi
tabelo z uporabniškimi značilnostmi orodij, v kateri podamo lastno mnenje o uporabnosti
posameznih orodij.
Primerjava orodij za testiranje spletnih storitev 3
2 TESTIRANJE
2.1 Glavni mejniki
Ko začnemo spoznavati testiranje, se moramo najprej ustaviti pri letu 1956, ko je bilo
razhroščevanju (ang. debugging) v vzponu. Z besedo razhroščevanje se je v tistem času
označevalo testiranje. To se je med letoma 1957 in 1978 spremenilo in vsaka od besed je
dobila svoj pomen. Prve razlike med razhroščevanjem in testiranjem je predstavil
Glenforda J. Myersa leta 1979. V obdobju 1979–1982 se je računalniška miselnost
nekoliko spremenila in glavni namen testiranja je postalo iskanje napak. Prav tako so ljudje
med letoma 1983 in 1987 začeli razmišljati, kako pregledati oz. meriti kvaliteto izdelka v
času njegovega delovanja. Od leta 1988 naprej pa se sprašujemo, ali programska oprema
zadošča specifikacijam, ki so bile napisane prav za njo [2].
Gelperin je prvi izdal standard IEEE 829-1989 skupaj s Hetzlom pa je izdal knjigo z
naslovom Celotni vodič skozi testiranje. Oba veljata za pionirja testiranja programske
opreme in še v današnjem času testiranje v veliki meri temelji na njunih teorijah [1].
2.2 Kaj je testiranje?
Ko pridemo do tega vprašanja, se moramo zavedati, da nanj ne moremo odgovoriti kar
tako, saj moramo poznati veliko dejstev. Eno od njih je določanje glavne vloge pri
testiranju, ki jo ima največkrat preizkuševalec (ang. tester). To je oseba, ki je zadolžena za
testiranje programske ali strojne opreme. Pred letom 1950 se je beseda preizkuševalec,
uporabljala splošno. Kasneje pa je začela označevati različne osebe kot na primer testnega
vodja, preizkuševalca, oblikovalca testov, razvijalca avtomatičnih testov in administratorja
testov.
Testiranje je analiza celotnega ali le dela programa, ki se izvaja z namenom preverjanja
ustreznosti programa oz. iskanjem odstopanj od pričakovanih vrednosti. Osnovni namen
testiranja je dokazati prisotnost ene ali več napak, ne pa lokacije napak [3].
Primerjava orodij za testiranje spletnih storitev 4
Poznamo tudi stopnje testiranja. Pri sestavni stopnji testiranje izvede večja skupina
programerjev. Tukaj so vse komponente kombinirane med seboj. Druga takšna stopnja
testiranja je sistemska stopnja, kjer proizvajalci ali neodvisni razvijalci testirajo produkte
ali storitve z enim ali več zmogljivostnimi testi in če je le mogoče z enim ali več programi
za testiranje referenčnih meritev.
2.2.1 Referenčna meritev
Referenčna meritev (ang. benchmarking ) je referenca, s katero odmerimo določeno
stvar. Lahko jo opišemo tudi kot vrsto pogojev, s katerimi se lahko proizvod ali sistem
odmeri, oz. vrsto kriterijev, ki naj bi jih izdelek imel.
Tako Eric Raymond [4] o referenčni meritvi govori kot o nenatančnem merilu in
pravi: »Stari hekerji govorijo, da obstajajo v računalniški industriji tri vrste laži, to so laži,
velike laži in referenčne meritve«.
Metoda testiranja je nekakšen proces, ki nam da testne rezultate. Testiranje in
eksperimentiranje sodita med t.i. znanstvene metode, ki potrdijo ali ovržejo določena
pričakovanja. Za testnega preizkuševalca lahko rečemo, da je to oseba, ki validira in
verificira kvaliteto programske opreme.
2.2.2 Verifikacija in validacija
Ko govorimo o verifikaciji, govorimo o procesu, pri katerem preverjamo ali produkt
tekoče faze ustreza zahtevam, postavljenim v predhodni fazi. Za verifikacijo lahko rečemo,
da je sinonim za vse vrste preverjanj. Za razumevanje besede verifikacija si lahko
pomagamo tako, da se vprašamo, ali smo naredili ustrezen izdelek oz. izdelek, skladen s
specifikacijo [5, str. 12–15].
Drugi takšen proces je validacija, o kateri govorimo, ko vrednotimo programsko
opremo na koncu njenega razvoja z namenom, da ugotovimo njeno skladnost z zahtevami.
Za razumevanje besede validacija si lahko pomagamo tako, da se vprašamo, ali smo
naredili ustrezen izdelek oz. ali je to izdelek, ki ga hoče stranka [5, str. 12–15].
Primerjava orodij za testiranje spletnih storitev 5
2.2.3 Uspešnost testiranja
Testiranje je uspešno, če uspemo dokazati prisotnost napak. Testiranje predstavlja
destruktiven proces, razvoj programske opreme pa označujemo kot konstruktiven proces
[5]. Ena izmed pomembnejših trditev je, da naj oseba, ki določen proizvod razvija, tega ne
testira sama.
Odpravljanje napak se pogosto zamenjuje s testiranjem. V bistvu pa gre za postopek,
pri katerem vnaprej vemo, da je v programu napaka (ena ali več). Naloga razhroščevanja
pa je, da na primer ugotovimo, na katerih mestih so napake oz. kje se te napake pojavljajo
itd.
Največje težave se pojavijo pri vprašanju, kdaj prenehati s testiranjem. Pri tem nam
pomaga kriterijska funkcija, s katero predpišemo, kdaj končati s preverjanjem. Ta funkcija
je zelo pomembna, kajti od nje so odvisni stroški preverjanja. Sestavljajo jo različni
parametri kot npr. testni čas, število uporabljenih testnih vzorcev itd.
2.3 Kdo nadzoruje preizkuševalca ?
Pri testiranju se pojavlja klasično latinsko vprašanje ''Quis Custodiet Ipsos Custodes''
oz. kdo nadzoruje preizkuševalca. Bistvo je v tem, da je nadzorovanje neka vrsta
delovanja, ki ima posledice za testiranje. Na to, ali je tak nadzor dober ali slab, vpliva
veliko dejavnikov.
V praksi preizkuševalec testira programsko opremo z drugimi programskimi rešitvami
in sistemi. V procesu testiranja lahko celotna zadeva propade in ne dobimo nobenega
poročila o napakah v sistemu, lahko pa se te napake pojavijo pri naših orodjih za testiranje
[9].
Zato se razvijajo metrike, na podlagi katerih se ocenjuje učinek nekega testiranja.
Z merjenjem števila napak v programu in s primerjanjem le-teh s podobnimi projekti,
dobimo približno sliko testiranja. Pri testiranju se lahko pojavljajo tudi napake, ki so bile
namenoma povzročene. Za dokazovanje teh namernih napak ni posebne metode in jih je
sila težko dokazati.
Primerjava orodij za testiranje spletnih storitev 6
2.4 Pri testiranju je dobro vedeti
Obstaja kar nekaj zadev, ki jih moramo pri testiranju upoštevati. Prva od njih je ta, da je
proizvod nemogoče testirati v celoti. Naslednja je ta, da je nemogoče kakovostno testirati
lasten program. Prav tako je pri testiranju težko dokazati oz. pokazati, da napak ni. Čim
več napak najdemo, toliko več napak še ostane. In vse te napake, ki jih najdemo, ne bodo
popravljene iz različnih razlogov, itd. [60].
Testiranje naj opravljajo najbolj kreativni ljudje v podjetju. Za vsak testni primer
moramo obvezno že pred testiranjem ugotoviti pravilne rezultate. O tem, kdaj je testiranje
končano, se moramo odločati na podlagi vnaprej določenih kriterijev.
Primerjava orodij za testiranje spletnih storitev 7
3 TESTIRANJE PROGRAMSKE OPREME
3.1. Testiranje
Testiranje je informacijska rešitev, ki se uporablja za merjenje kvalitete pri razvijanju
programske opreme. Ponavadi je kvaliteta omejena na različne zadeve, kot so pravilnost
(ang. correctness), ki je dosežena, ko se algoritem ujema z zahtevami specifikacije,
popolnost (ang. completeness), ki določa, da je program popoln, če mu ni treba ničesar
dodati, kar pa se v praksi le redko zgodi. Zato uporabljamo formalni sistem, ki je lahko
maksimalno, ekstremno in močno popoln, kot zadnja je tukaj še varnost (ang. security), ki
je lahko ročna ali avtomatična [10].
Zraven vseh teh pomembnih stvari testiranje programske opreme vključuje tudi bolj
tehnične zahteve (ISO 9126) (Slika 1), kot so npr. funkcionalnost, zanesljivost, uporabnost,
učinkovitost, vzdrževalnost in prenosljivost.
Slika 1: Grafični prikaz ISO/IEC 9126 [44]
Primerjava orodij za testiranje spletnih storitev 8
3.1.1 Funkcionalnost
Kako proizvod deluje, da zadovolji potrebe uporabnika se sprašujemo pri
funkcionalnosti (ang. functionality). Tukaj so pomembni pojmi ustreznost (govori o
prisotnosti in primernosti posameznih funkcij), natančnost (govori o pričakovanih
natančnih rezultatih), kompatibilnost (govori o tem, kako se proizvod povezuje z
navedenim okoljem glede na prejšnje verzije), skladnost (govori o skladnosti z zakonodajo,
standardi, poročili itd.) in zaščita (nanaša se na onemogočanje neavtorizirane uporabe
programske opreme) [11, 12].
3.1.2 Zanesljivost
Zanesljivost (ang. reliability) je sposobnost osebe ali sistema, da izvaja in vzdržuje
svoje delovanje v različnih okoliščinah. Ločimo podatkovno zanesljivost (lastnost
nekaterih diskovnih razporeditev in računalniških diskov) in inženirsko zanesljivost
(zagotavlja, da bo sistem zanesljiv, ko bo deloval v določenih načinih) [11].
3.1.3 Uporabnost
Uporabnost (ang. usability) se ponavadi nanaša na prefinjenost in jasnost, pri čem se
delovanje kaže v računalniških programih in spletnih straneh.
O uporabnosti govorimo tudi tedaj, ko se pogovarjamo o uporabnosti nekega izdelka, ki
je povezan z uporabniških vmesnikom. Besedo uporabnost lahko prav tako uporabljamo v
kontekstu z besedno zvezo uporabniku prijazno. Uporabnost lahko ugotovimo tako, da se
vprašamo, kdo so uporabniki, kaj hočejo, kaj potrebujejo, kaj se lahko naučijo itd. [11].
3.1.4 Učinkovitost
Učinkovitost (ang. efficiency) razdelimo na dva dela, in sicer na hitrost in prostor.
1. Hitrost (čas potreben za končanje operacije)
Primerjava orodij za testiranje spletnih storitev 9
Hitrost algoritma se lahko meri na različne načine. Najpogosteje uporabljena metoda je ta,
da uporabljanje časovne zapletenosti za določitev Big-O algoritma. Tako lahko povečamo
hitrost našega algoritma.
Big-O se uporablja za opisovanje, kako velikost vhodni podatkov vpliva na hitrost
algoritma (ponavadi tekoči čas ali čas pomnilnika) [11, 12].
2. Prostorsko zahtevnost (disk oz. pomnilnik porabljen pri procesiranju )
Prostor algoritma dejansko delimo na dva ločena, vendar podobna vidika. Prvi del
algoritma je prostor s strani delovanja diska. Tega lahko pogosto zmanjšamo z ocenitvijo
časa izvajanja. Drugi del algoritma predstavlja čas pri procesiranju začasnega pomnilnika.
Optimizacija celotnega algoritma za zmogljivost je v večini primerov odvisna od tega, na
kakšnem računalniku bo algoritem deloval [11, 12].
3.1.5 Vzdrževalnost
Vzdrževalnost (ang. maintainability) pomeni kako dolgo lahko programsko ali strojno
opremo spreminjamo, v smislu da bo delovala brez napak, pri čemer skušamo povečati
zmogljivost, prilagodljivost, vstavljanje novih atributov itd. [11].
3.1.6 Prenosljivost
Prenosljivost (ang. portability) pomeni prilagajanje programske opreme tako, da se
lahko prilagodi program, ki je drugačen od tistega, za katerega je bil v prvi vrsti namenjen
(operacijski sistemi, različne knjižnice itd.). Glavni namen prenosljivosti je uporabnost
programske in strojne opreme v različnih računalniških okoljih [11].
Primerjava orodij za testiranje spletnih storitev 10
Slika 2 prikazuje uporabo tehničnih zahtev ISO 9126 v praksi. Iz nje je razvidno, da
predstavlja funkcionalnost in zanesljivost najpomembnejši del razvoja programske opreme,
najmanjši pa uporaba prenosljivosti.
Slika 2: Uporabnost karakteristik kakovosti po ISO 9126 [45]
Tako lahko rečemo, da je testiranje proces tehnične raziskave v prid nepristranske
osebe, katere namen je ugotoviti kakovost oz. skladnost proizvoda, z upoštevanjem
pričakovanj o delovanju našega proizvoda [10].
To vključuje programe in aplikacije z njihovo namero, da najdejo napake. Tako je
najbolje, da testiranje programske opreme opravljajo različne ustanove kot enota, oddelek,
skupina za SQA, katere obseg dela zajema vse procese, ne le testiranja.
SQA (Software Quality Assurance) – zagotavljanje kvalitete programske opreme
V današnjem času se programska oprema razvija zelo hitro, kar lahko opazimo v vsej
njeni zapletenosti in velikosti. Vsa ta programska oprema se mora tako hitro razvijati
zaradi vse večjih sistemskih zahtev. Vsak programski proizvod ima svojo ciljno skupino.
Zato mora industrija, ki razvija programsko opremo, biti posebej pazljiva v kaj vlaga
denar, kajti proizvod mora biti na koncu dostopen oz. dovolj dober, da bo zadovoljil kupce.
Prav tukaj nam testiranje zelo pomaga. Testiranje ne pomeni samo iskanja napak in
''hroščev'' v proizvodu, ampak lahko ovrednotimo kvaliteto proizvoda oz. programske
Primerjava orodij za testiranje spletnih storitev 11
opreme. Programska oprema pa lahko deluje pravilno ali deluje nepravilno (je v stanju
odpovedi).
Programsko opremo delimo na programsko opremo z napako in programsko opremo,
katera ima napake. O napaki programske opreme govorimo tedaj, ko programska oprema
ne deluje tako, kot želi uporabnik. O programski opremi, ki ima napake, pa govorimo
tedaj, ko delamo popravke v smislu semantičnih popravkov in kot rezultat namesto
delovanja programa dobimo napako (error).
Najpogostejša praksa testiranja programske opreme je, da je ta testirana s strani
različnih skupin programerjev inženirjev (preizkuševalec). Z vsemi popravki se lahko
podaljša izdaja izdelka in posledično lahko s tem prekoračimo proračun, predviden za ta
izdelek. Zato tudi velja, da prej ko najdemo napako v proizvodu, ceneje nas bo stalo njeno
odpravljanje. Programi brez napak so zelo redki. Takšne programe imenujemo korektni
programi. Korektni program je tak program, ki nikoli ne odpove [10].
Slika 3 prikazuje intenzivnost odpovedi, ki jo izračunamo tako, da število odpovedi
delimo s časovno enoto.
Slika 3: Intenzivnost odpovedi [10]
Primerjava orodij za testiranje spletnih storitev 12
3.2 Stopnje testiranja programske opreme
3.2.1 Testiranje modulov
Pri testiranju modulov (ang. unit testing) gre za testiranje manjših programskih delov
ali modulov. Vsak modul proizvoda je testiran tako, da se pogleda, če je bil pravilno
implementiran. Ponavadi se to testiranje izvaja v sami kodi programa na t.i. razredih in pri
konstruktorjih in destruktorjih.
Ločimo tri tipe modulov. To so navadni moduli, rečemo jim lahko kar moduli, krmilni
moduli, ki imajo nalogo, da prenesejo izbrane testne vzorce v modul, ki ga potem
testiramo, in dobimo izhodne podatke, in nadomestni moduli, ki simulirajo delovanje
originalnega modula, ki jih je zahteval klicani modul [5, str. 46–78].
3.2.2 Integracijsko testiranje
Po opravljenem testiranju modulov lahko začnemo s testiranjem integracije (ang.
integration testing). To testiranje razkrije pomanjkljivosti oz. napake v samem vmesniku in
interakcije med integriranimi moduli. Enostavno rečeno je testiranje integracije faza, v
kateri se posamezne programske enote testirajo v skupinah [5, str. 50–51].
Poznamo različne tipe testiranja integracije. Veliki pok (ang. big bang) je prvi izmed
njih. V tem pristopu so vsi oz. večina razvijalskih enot zbrani skupaj, da tvorijo celotno
programsko opremo in jih potem uporabimo za testiranje integritete. Drugi takšen način je
testiranje od zgoraj-navzdol (ang. top-down), kjer je na prvi stopnji celotna slika sistema
slaba, s povečanjem teh stopenj dobivamo vedno boljšo oz. popolnejšo sliko sistema. Tretji
tip testiranja je testiranje od spodaj-navzgor (ang. bottom-up), kjer imamo že na začetku
celotno sliko sistema potem pa z dodajanjem povezav na višjih stopnjah dobimo pregled
nad sistemom.
Primerjava orodij za testiranje spletnih storitev 13
3.2.3 Testiranje funkcionalnosti
Pri testiranju funkcionalnosti (ang. functional testing) gre za testiranje programa oz.
programske opreme kot celote. To testiranje deluje na vsakem nivoju (razreda, vmesnika,
sistema itd.) in skrbi za primerno funkcionalnost, ki je bila določena v specifikaciji. K
testiranju funkcionalnosti naj bi se pristopilo podobno kot k testiranju enot. Funkcijski testi
so napisani z uporabniškega stališča. Končno je testiranje funkcionalnosti najpomembnejši
del razvoja programske opreme [5, str. 52–59].
3.2.4 Sistemsko testiranje
Pri sistemskem testiranju (ang. system testing) testiramo celotni sistem in preverjamo,
ali ustreza potrebam. Osnovna naloga sistemskega testiranja je dokazati, da program v
celoti ne ustreza vsem postavljenim kriterijem. To testiranje skoraj v celoti temelji na
testiranju po metodi ''črne škatle'' in kot takšno testiranje ne rabi nobenega znanja o
notranji strukturi programske kode in programske logike. Obstajajo še drugi tipi testiranja
sistema, kot so testiranje uporabnosti, testiranje zmogljivosti, testiranje obremenitev,
testiranje varnosti itd. [5, str. 51–52].
3.2.5 Prevzemno testiranje
Pri prevzemnem testiranju (ang. acceptance testing) so testi lahko opravljeni s strani
končnih uporabnikov, strank ali odjemalcev, ki se odločajo, ali hočejo to programsko
opremo ali ne. Zaradi tega se pred predajo programske opreme oz. proizvoda, izvršita dva
pomembna testa:
� Alfa testiranje
Alfa testiranje (ang. alpha testing) je testiranje s strani potencialnih uporabnikov ali
strank. V večini primerov to testiranje opravijo testne skupine. Ponavadi se najprej
naredijo alpha testi, šele nato lahko proizvod preide v beta testiranje [5, str. 199–200].
Primerjava orodij za testiranje spletnih storitev 14
� Beta testiranje
Pri beta testiranju (ang. beta testing) se proizvod v manjših enotah pošlje iz podjetja in
se imenuje ta beta verzija. Proizvod je poslan različnim skupinam ljudi, tako da lahko
preko njih izvemo, če ima še kakšno napako. Z beta verzijo proizvoda, dobimo tudi
povratno informacijo o proizvodu [5, str. 199–200].
3.2.6 Regresijsko testiranje
Pri regresijskem testiranju (ang. regression testing) gre za to, da odpravimo vse napake,
ki so povzročile odpoved proizvoda. Preveriti moramo, da nismo pri tem naredili novih
napak. Nato ponovno testiramo program in uporabimo vse prejšnje testne primere.
Zato je bila glavna ideja, da bi naredili regresijske teste bolj učinkovite in dovolj
zmogljive za razvijanje regresijskih testov (ang. RTS). Kljub vsem prizadevanjem se še
vedno pojavljajo težave, kot so nenapovedljive zmogljivosti regresijskih testov,
nezdružljive procesne domneve in različna neprimerna vrednotenja modelov [5, str. 29].
3.2.7 Strukturno testiranje
Za strukturno testiranje (ang. structural testing) se uporablja sinonim testiranje po
metodi bele škatle. Pri tej metodi ne tvorimo specifikacij sistema ali njegovih komponent
na podlagi testnih vzorcev, ampak to naredimo na podlagi strukture in uporabljenih
algoritmov.
Glavni cilj strukturnega testiranja je enak kot pri vseh vrstah testiranja, in sicer
odkrivanje napak.
Pri izbiri objektov strukturnega testiranja obstaja ogromno možnosti. Najpomembnejši so
stavki, poti, predikati, odločitve, kombinacije predikatov itd. [5, str. 60–68].
Primerjava orodij za testiranje spletnih storitev 15
3.3 Najpogostejše metode testiranja programske opre me
3.3.1 Testiranje po metodi ''bele škatle''
To testiranje uporablja notranji pogled sistema, pri katerem testni primeri temeljijo na
notranji strukturi in so sinonim za strukturno testiranje. Od preizkuševalca se zahtevajo
dobre izkušnje na programskem področju [6].
Glede na to, da testni primerki temeljijo na dejanski implementaciji, velja, da če
spremenimo njihovo implementacijo, moramo spremeniti testne primerke oz. izhode
(rezultate) testiranja. Splošno lahko rečemo, da se testiranje po metodi ''bele škatle'' zgodi
takrat, ko ima preizkuševalec dostop do strukture in kode programa ter algoritmov.
3.3.2 Testiranje po metodi '' črne škatle''
Testiranje po metodi ''črne škatle'' deluje tako, da obravnava programsko opremo kot
črno škatlo, brez kakršnega koli razumevanja sistema in je hkrati sinonim za funkcionalno
testiranje [7]. Preizkuševalec pri tem testiranju izbere vrednosti in vhodne (začetne)
vrednosti ter določi pravilne izhodne (končne) vrednosti. Pri tem ne potrebuje nobenega
znanja o testnih objektih notranje strukture. Čim višjo zahtevnost testiranja imamo, toliko
bolj kompleksna je ''škatla''.
3.3.3 Testiranje po metodi ''sive škatle''
Testiranje po metodi ''sive škatle'' prihaja v zadnjem času v splošno rabo in je sinonim
za kombinacijo funkcionalnega in strukturnega testiranja. Pri tem testiranju imamo dostop
do notranje podatkovne strukture in algoritmov. [8]. Testiranje po tej metodi se uporablja v
okolju testiranja odjemalec–strežnik, ko ima preizkuševalec kontrolo pri vhodu in
pričakuje rezultate v SQL–bazi ter na izhodu.
Primerjava orodij za testiranje spletnih storitev 16
3.3.4 Primerjava testiranja po metodi ''bele škatle '' in '' črne škatle''
V tabeli 1 lahko vidimo stopnje testiranja, na podlagi katerih so določena področja in
metode testiranja, ter prikazuje, kdo je odgovoren oz. kdo opravlja testiranje [64].
Tabela 1: Primerjava testiranja po metodi ''bele škatle'' in ''črne škatle''
Stopnje testiranja Področje testiranja Metode testiranja Kdo opravlja testiranje ?
testiranje modulov majhne module kode, ne
večje od razredov
''bela škatla'' programerji, ki so napisali
kodo
integracijsko testiranje mnogovrstni razredi ''bela škatla''
''črna škatla''
programerji, ki so napisali
kodo
testiranje
funkcionalnosti
celotni proizvodi ''črna škatla'' neodvisni testerji
Sistemsko testiranje celotni proizvodi v
tipičnih okoljih
''črna škatla'' neodvisni testerji
prevzemno testiranje celotni proizvodi v
tipičnih okoljih
''črna škatla'' stranka
strukturno testiranje celotne proizvodi v
tipičnih okoljih
''bela škatla'' programerji, ki so napisali
kodo
regresijsko testiranje vse zgoraj našteto ''bela škatla''
''črna škatla''
programerji ali neodvisni
testerji
Vir: Primerjava testiranja [64]
Primerjava orodij za testiranje spletnih storitev 17
4 SPLETNE STORITVE
4.1 Principi spletnih storitev
Spletne storitve so odvisne od različnih principov in arhitektur. Najpomembnejše so
spletno orientirane arhitekture - WOA (ang. Web Oriented Architecture), storitveno
orientirane arhitekture – SOA (ang. Service Oriented Architecture) in programske
arhitekture – REST (ang. Representational State Transfer).
4.2 Zgodovina
Kot prvega od najpomembnejših spletnih mejnikov lahko omenimo 25. januar 2002, ko
so bile oblikovane skupine, ki so ustvarjale in skrbele za arhitekturo spletnih storitev,
koordinacijo in opisovanje. Že naslednji dan so bili predstavljeni protokoli XML (XMLP),
arhitektura SOAP 1.2 itd.
9. julija 2002 je izšla verzija jezika WSDL 1.1 nato še 1.2. 10. novembra 2003 je izšla
nova verzija jezika WSDL in sicer WSDL 2.0, ki je še vedno aktualna [46].
Celotno zgodovino spletnih storitev podrobno opisuje spletna stran [46].
Primerjava orodij za testiranje spletnih storitev 18
4.3 Arhitektura
Slika 4: Prikaz arhitekture spletnih storitev [47]
Slika 4 prikazuje pošiljanje zahtev in prejemanje odgovorov. Pri tem se uporabljajo
jezik WSDL, protokola HTTP in SOAP ter UDDI-register.
Spletna storitev je programski proizvod, narejen za podporo povezave med
računalnikom in računalnikom preko omrežja. Spletne storitve so navadni spletni API, do
katerih lahko dostopamo preko omrežja in se izvajajo na oddaljenem računalniku.
API (ang. application programming interface) je nabor deklaracij funkcij (procedur), ki
jih operacijski sistem, knjižnica ali storitev omogočajo za sprejem zahtev s strani
odjemalca.
4.3.1 Odjemalec
Odjemalec je aplikacija ali sistem, ki dostopa do oddaljenega strežnika na drugem
računalniškem sistemu, ki je poznan kot strežnik. Vse to poteka preko omrežja. Model
odjemalec/strežnik se še vedno uporablja na spletu, kjer se lahko uporabnik poveže s
storitvijo preko protokola. Spletni brskalniki so odjemalci, ki se povežejo s spletnimi
storitvami in prikažejo vsebino spletne strani. Večina ljudi uporablja odjemalca za pregled
elektronske pošte, klepetanje preko spleta, igranje preko spleta itd. [14].
Primerjava orodij za testiranje spletnih storitev 19
4.3.2 Strežnik
Strežnik je aplikacija ali naprava, ki izvaja storitve s povezanim odjemalcem v smislu
arhitekture odjemalec – strežnik.
Strežniška aplikacija je bila definirana na podlagi protokola RFC 2616 (HTTP 1.1) in
deluje tako, da sprejema zahteve in pošilja odgovore. Strežniški računalniki so naprave, ki
tečejo kot aplikacije z daljšo časovno periodo in zelo nizko stopnjo človeškega posega v
njihovo delovanje [15].
4.3.3 Jezik XML
Obravnavan je kot ''razširljiv'' označevalni jezik, ker dovoljuje uporabo svojih oznak
(ang. tags). Jezik XML je zelo preprost in podoben jeziku HTML. Njegov glavni namen je,
da olajšuje razdeljevanje podatkovne strukture preko različnih informacijskih sistemov,
zlasti preko spleta.
Jezik XML je priporočen s strani konzorcija W3C (mednarodne organizacije za
standarde) in spada med odprte standarde [16].
Jezik XML delimo na podatkovni del, kjer shranjujemo podatke, ki lahko imajo
različne oznake deklarativni del, ki skrbi za pomen oznak pri dodajanju novih podatkov, in
predstavitveni del, s katerim oblikujemo izpis podatkov.
4.4 Specifikacije spletnih storitev
Glavne specifikacije spletnih storitev so:
� Protokol SOAP (ang. Simple Object Access Protocol),
� Jezik WSDL (ang.Web Service Descripton Language) in
� Register UDDI (Universal Descripton, Discovery and Integration).
Primerjava orodij za testiranje spletnih storitev 20
4.4.1 Protokol SOAP
Protokol SOAP je sprva pomenil ''enostaven objektni dostopni protokol'', pozneje pa
protokol storitveno orientirane arhitekture. Danes ga enostavno imenujemo samo SOAP.
SOAP so ustvarili Dave Winer, Don Box, Bob Atkinson in Mohsen Al-Ghosein leta 1998 z
namenom pomoči Microsoftu. SOAP-verzija 1.1 je bila izdana leta 2000 s podporo
organizacije W3C. Zadnja verzija SOAP je 1.2, izdana je bila leta 2007, prav tako ob
podpori organizacije W3C.
SOAP je protokol za izmenjavo XML-sporočil preko računalniškega omrežja, ponavadi
z navezo HTTP/HTTPS. HTTP (HyperText Transfer Protocol) je glavna metoda za prenos
informacij na spletu. HTTPS (HyperText Transfer Protocol Secured) je zavarovana
različica protokola http. Obstaja nekaj različnih tipov sporočil pri protokolu SOAP, med
najbolj pogostimi se uporablja RPC (oddaljeno obravnavanje klicev). Deluje na način, da
omrežje (odjemalec) pošilja sporočila v obliki zahtev na druga vozlišča (strežnike), ta pa
nato pošiljajo odzivna sporočila nazaj k odjemalcu.
Enostavno rečeno je to protokol, ki skrbi za komunikacijo med aplikacijami [17]. Oba
protokola, SMTP in HTTP, sta veljavna aplikacijska protokola, ki se uporabljata kot
nekakšno ''prevozno sredstvo'' za SOAP [20, 21]. SOAP se lahko prav tako uporablja preko
protokola HTTPS, ki je v bistvu enak protokolu HTTP, vendar z dodatnim uporabljanjem
šifriranja podatkov oz. sporočil.
Glavna prednost uporabe protokola SOAP preko protokola HTTP je v tem, da omogoča
lažje komuniciranje preko posrednikov (ang. proxy) in požarnih zidov. Kot standard še
vedno uporablja protokol HTTP. Kot slabost lahko navedemo obsežnost jezika XML, ki
SOAP upočasni, in veliko je takšnih implementacij protokola SOAP, ki omejujejo velikost
poslanih podatkov [17].
Nekaj največjih razlik med SOAP 1.1 in SOAP 1.2
Dokument verzije SOAP 1.2 je sestavljen iz treh delov, medtem ko je SOAP 1.1
samostojen dokument. SOAP 1.1 temelji na XML 1.0, SOAP 1.2 na XML infoset. Tudi
imenski prostor se je pri SOAP 1.2 spremenil. [18]
Primerjava orodij za testiranje spletnih storitev 21
4.4.2 Jezik WSDL
WSDL je jezik za opisovanje spletnih storitev in temelji na jeziku XML. Primarna
protokola, preko katerih deluje, sta HTTP in HTTPS, deluje pa tudi z drugimi, kot so
SMTP in XMPP [19, 22].
Trenutna verzija jezika WSDL je 2.0, ki je v bistvu preimenovana verzija jezika WSDL
1.2, ki jo podpira konzorcij W3C. Prejšnje verzije jezika WSDL (verzije 1.1) mednarodni
konzorcij ni podpiral. Glavna razlika med verzijama je, da jezik WSDL 2.0 ne podpira
samo get in post zahtev kot prejšnja verzija, ampak podpira tudi ostale [23].
WSDL 2.0 sestavljajo 3 komponente:
1.del: Jedro
To je abstraktni vmesnik, neodvisen od protokola in kodiranja. Med najpomembnejše
novosti uvrščamo večjo natančnost, pridobitev novega modela (komponentnega),
reference gredo vse na QName itd.
2.del: Izmenjava vzorcev sporočil
Novost se kaže predvsem v razširljivosti sporočil, pri poljubno mnogo vozliščih itd.
Tukaj je najprej treba definirati in določiti tipe.
3.del: Povezave
Povezava je mogoča preko protokola SOAP in HTTP/MIME. Novost je predvsem
podpora protokola SOAP 1.2 in ne 1.1.
Jezik WSDL se največkrat uporablja v navezi s protokolom SOAP in XML-shemo.
Odjemalčev program se poveže na spletno storitev in prebere dokument WSDL, da določi,
katere funkcionalnosti so razpoložljive na strežniku. Potem lahko odjemalec uporabi
protokol SOAP, da dejansko pokliče eno od funkcionalnosti, ki je opisana v dokumentu
WSDL [19].
Primerjava orodij za testiranje spletnih storitev 22
Konceptualni model WSDL 2.0 lahko razdelimo na dva dela, in sicer na abstraktni del
(ang. abstract part), ki se deli na sporočila (ang. messages), operacije (ang. operation) in
vmesnik (ang. interface), in stvarni del (ang. concrete part), ki se deli na povezave (ang.
binding), storitve (ang. services) in končne točke (ang. endpoints).
Slika 5 prikazuje celotno zgradbo konceptualnega modela WSDL 2.0.
Slika 5: Konceptualni model WSDL 2.0 [65]
4.4.3 Register UDDI
Je protokol za objavljanje in raziskovanje podatkov o spletnih storitvah, ki omogoča da
aplikacija najde te podatke, naj si bo v času razvoja ali v času delovanja. Temelji na jeziku
XML, v njem pa hrani dokument WSDL in ostale pomembne dokumente, ki opisujejo
spletno storitev in so pomembni za odjemalca. Odjemalec mora poznati način kako
uporabiti storitve, ki jih določena spletna storitev ponuja.
Register UDDI je podprt s strani organizacije OASIS, ki deluje kot globalni konzorcij,
ki skrbi za razvijanje, konvergenco in sprejemanje elektronskega poslovanja, prav tako
skrbi za standarde spletnih storitev [24].
Primerjava orodij za testiranje spletnih storitev 23
Imenik UDDI sestoji iz treh delov:
- ''belih strani'' (naslov, kontakt, itd.),
- ''rumenih strani'' (industrijsko kategorizirana baza) in
- ''zelenih strani'' (tehnične informacije)
UDDI ni repozitorij, kar pomeni, da to ni podatkovna shramba, pač pa register, ki
usmerja uporabnika na ustrezne vire s podatki. Večina uporabnikov ne bo implementirala
svojih UDDI-registrov, ampak bo njihova prioriteta testiranje vsebine registra. Najbolj
zanesljiv način testiranja vsebine je, da napišemo testnega odjemalca, ki izvede poizvedbo
o registrih in potem uporabi podatke registra, da dejansko pokliče storitve. Zadnja verzija
UDDI-registra je 3.0.2, ki je izšla leta 2006 [63].
Kar nekaj velikih podjetij je prekinilo z uporabo javnih UDDI-registrov, največja med
temi so Microsoft, IBM, SAP itd [63].
Slika 6 prikazuje delovanje registra UDDI s protokolom SOAP. Na sliki vidimo, kako
se pošlje zahteva (ang. request), ki je zaščitena s protokolom SSL. Ko zahteva prispe do
podatkovnega registra, ta vrne odziv oz. odgovor (ang. response) preko vmesnika API.
Slika 6: UDDI in SOAP [66]
Primerjava orodij za testiranje spletnih storitev 24
4.5 Dodatki k specifikaciji spletnih storitev
BPEL (ang. Business Process Execution Language) je deklarativni jezik, s pomočjo
katerega lahko določimo zaporedje proženja spletnih storitev
v smislu opisa izvajanja določenega poslovnega procesa. Omogoča lahko tudi dodatne
možnosti, kot so pogojne vejitve, vzpostavitev povezav, itd [67].
Spletne storitve - zmožnost kompozicije (ang. WS-Policy) določajo mehanizme
specifikacije polic, načine preverjanja podpore določenih polic in specificiranje pravila
sodelovanja med spletnimi storitvami [67].
Spletne storitve - potrebe po zmožnosti (ang. WS-Eventing), da spletna storitev reagira
na določen dogodek, hkrati pa ponujako dogodkovni model, uporaben pri asinhronem
delovanju spletnih storitev [67].
Spletne storitve – odkrivanje funkcionalnosti (ang. WS-Inspection), pomeni vpogled v
notranjo zgradbo spletnih storitev. WS-Inspection dopolnjuje spletno storitev (npr.
ugotavlja lokacijo jezika WSDL), na nekaterih mestih pa zamenjuje UDDI [67].
Spletne storitve – transakcije (ang. WS-Transaction) definirajo transakcijske modele v
porazdeljenih računalniških okoljih in trenutno podpirajo dva modela, ki se nanašata na
dolžino trajanja transakcij v porazdeljenih okoljih. Prvi se imenuje atomarne transakcije
(ang. WS-Atomic transaction) in temelji na ACID-semantiki porazdeljenih transakcij ter na
dvofaznem protokolu potrjevanja. Drugi se imenuje poslovne aktivnosti in temelji na
kompenzacijski logiki in je s tem primernejši za dolgotrajnejše transakcije [27, 67].
Spletne storitve – koordinacije (ang. WS-Coordination), definirajo ogrodje za
koordinacijo spletnih storitev oz. virov. Prav tako so transakcije povezane z koordinacijo
vpletenih virov [67].
Spletne storitve – ponovno naslavljanje (ang. WS-Addressing) podpira usmerjanje in
koordinacijo sporočil. Omogoča tudi dinamično oblikovanje naslovov končnih točk [67].
Primerjava orodij za testiranje spletnih storitev 25
Spletne storitve – določanje poti (ang. WS- Routing) določa standardni način, s katerim
lahko opišemo pot sporočila SOAP od pošiljatelja, preko posrednikov, do končne točke
[67].
Spletne storitve – varnost (ang. WS-Security) zagotavljajo varnost poslanih sporočil
preko protokola SOAP. Zagotavljajo integriteto, zaupnost, avtentikacijo in enkripcijo
sporočil ter varnost od točke izvornega SOAP-sporočila do končnega prejemnika. V ta
namen uporablja WS-Security tehnologijo digitalnega podpisa dokumentov XML,
enkripcijo dokumentov XML ter časovno žigosanje [25, 67].
Spletne storitve – zanesljivost sporočil (ang. WS-Reliable Messaging) opisujejo
protokol, ki dovoljuje sporočilom SOAP, da so zanesljivo dostavljena med programskimi
komponentami, sistemi in omrežji.
Standard WS-Reliable Messaging omogoča univerzalno povezljivost med spletnimi
storitvami, razvitimi na različnih platformah, in tako omogoča enolično identifikacijo,
spremljanje dostave sporočil prejemniku in zagotavlja dostavo sporočila v istem vrstnem
redu [26, 67].
Slika 7 prikazuje sklad tehnologij spletnih storitev. Temelji vsem tehnologijam so protokol
SOAP, jezik za opis spletnih storitev WSDL in register UDDI.
Slika 7: Sklad tehnologij spletnih storitev [67]
Primerjava orodij za testiranje spletnih storitev 26
4.6 Storitveno usmerjena arhitektura SOA
Slika 8 prikazuje delovanje arhitekture SOA.
Slika 8: Arhitektura SOA [48]
SOA je zgrajena iz treh delov:
Storitveni ponudnik (ang. service provider) naredi spletno storitev in morda objavi
vmesnik in dostopne informacije v storitvenem registru. Vsak ponudnik mora pri tem
sprejeti več odločitev (varnost, dostopnost, cena, itd.) [30].
Storitveni posrednik (ang. Service broker), znan kot storitveni register, je odgovoren za
vmesnik spletnih storitev in zagotavlja dostopnost vsem storitvenim povpraševalcem. Javni
storitveni posredniki so dostopni preko spleta, medtem ko so privatni dostopni le redkim,
npr. dostop preko notranjega omrežja v podjetju. Na kakšen način se naj objavljajo in
odkrivajo informacije o spletnih storitvah določa standard UDDI [30].
Storitveni povpraševalci (ang. service requestor) uporabljajo storitveni register za
iskanje primernih storitev, ki ustrezajo njihovim zahtevam [30].
V računalniškem svetu izraz storitveno usmerjena arhitektura (ang. Service Oriented
Architecture) ni nov in predstavlja arhitekturo, v katero je združenih več neodvisnih
programskih paketov. Te programske storitve niso med seboj tesno povezane in so
praviloma tudi od različnih proizvajalcev, vendar komunicirajo med seboj po nekem
vnaprej predpisanem pravilu. Pri SOA ne gre za novo tehnologijo, saj so lahko posamezne
Primerjava orodij za testiranje spletnih storitev 27
storitve implementirane v različnih tehnologijah, bistveno pa je, da so dostopne vsem
uporabnikom ali drugim storitvam. V smislu povezovanja gre torej za zelo odprto
strukturo.
Zaradi potrebe po prilagodljivi, standardizirani arhitekturi, ki vključuje različne
aplikacije in omogoča deljenje podatkov je nastala arhitektura po imenu SOA. Arhitektura
ni vezava na določeno tehnologijo. Implementirana je lahko z uporabo različnih tehnologij,
kot so SOAP, RPC itd.
SOA je arhitektura, ki se nanaša na storitveno orientirani princip oblikovanja.
Predstavlja model, ki je funkcionalno razgrajen na majhne, jasne enote (storitve), ki jih
lahko povežemo preko omrežja in jih sestavimo skupaj tako, da tvorijo poslovno
aplikacijo. Storitev komunicira z vsakim, na način, da pošilja podatke od ene storitve do
druge. Spletne storitve so tipično opisane z uporabo jezika WSDL [28].
Glavni namen SOA je povezovanje poslovnih virov (zlasti organizacij, aplikacij in
podatkov) na zahtevo doseganja željenih rezultatov za storitvene potrošnike. Tudi nove
aplikacije, narejene iz različnih storitev, omogočajo večjo prilagodljivost in poenotenost
[29].
4.6.1 Kaj obljublja SOA?
Velika obljuba SOA je, da lahko naredimo poljubno veliko aplikacijo in bo še vedno
cenovno spremenljiva. Prav tako lahko uporabljamo programsko opremo, ki smo jo že
razvili. Storitve so izdelane na osnovi tradicionalnih programskih jezikov, kot so java, C#,
C, COBOL itd.
Najpomembnejša prednost storitvene arhitekture (SOA) je zmožnost razvoja takega
informacijskega sistema, ki neposredno podpira poslovne procese podjetja in je veliko bolj
prilagodljiv od obstoječih rešitev. Zato SOA omogoča dejansko merljivo povečanje
učinkovitosti informatike in omogoča, da prihranke namenimo razvoju novih, inovativnih
storitev.
Primerjava orodij za testiranje spletnih storitev 28
4.6.2 Naslednja generacija SOA
Inženirji verjamejo, da lahko SOA pomaga k hitrejšemu odzivu in manjšim stroškom
pri poslovanju. Ta arhitektura zagovarja uporabo makro (storitve) stopnje pred mikro
(razredi) stopnjo. SOA se zavzema, da se uporabniki ločijo od implementacije storitev.
Medtem ko se industrija še vedno ubada s SOA, Oracle že govori o novi verziji SOA
(SOA 2.0), ki bo kombinacija storitveno orientirane arhitekture (SOA) in dogodkovno
vodene arhitekture (EDA) [31].
EDA je arhitektura programske opreme. Ta arhitektura lahko dopolnjuje storitveno
orientirano arhitekturo na način, da s pomočjo sprožilcev (ang. triggers) aktivira spletne
storitve. Dogodek je lahko definiran kot pomemben prehod med stanji [32].
Večina atributov, ki jih obljublja SOA 2.0, že obstaja oz. jo že uporabljajo nekatera
podjetja (Tibco podjetje itd.), zato bo SOA 2.0 le marketinška oz. tržna poteza. Oracle
pripisuje združitev platforme Jave EE, SOA 2.0 in Web 2.0 čim večji produktivnosti pri
aplikacijskih platformah. Zato je veliko podjetij, ki pravijo, da bi morala naslednja
generacija SOA (SOA 2.0) biti bolj usmerjena na optimizacijo informacijskih tehnologij
(IT) pri poslovnem razvoju.
4.7 Arhitektura REST
REST (Representational State Transfer) je arhitektura programske opreme za
hipermedijske (ang. hypermedia) sisteme, kot je svetovni splet (WWW). Arhitektura REST
se uporablja kot opis za preprosti vmesnik, ki prenaša specifične domenske podatke preko
protokola HTTP. Deluje brez dodatnega sporočilnega sloja, kot je protokol SOAP, brez
sledenja sejam in HTTP-piškotom. Arhitekturo REST je leta 2000 predstavil Roy Fielding,
ki je tudi eden od glavnih avtorjev protokola HTTP [33].
Veliko navedb definira REST v povezavi s spletnimi storitvami kot nasprotje protokola
SOAP. Na začetku je bil definiran kot koncept, ki ima dostop do informacij in medijev.
Primerjava orodij za testiranje spletnih storitev 29
Nekateri govorijo, da je uporaben z zahtevo GET, ampak nepripravljen oz. neprimeren za
druge kot npr. za zahtevo PUT. Razviti so bili tudi nekateri REST-sistemi, ki so podpirali
GET, POST, prav tako tudi http-metode HEAD, DELETE, PUT, COPY, MOVE itd. [33].
Glavni problem arhitekture REST je, da se preveč zanaša na spletne brskalnike. Prehodi,
strežniki, vrata itd., ki se nenehno spreminjajo, so glavne kritične komponente, ki slabijo
arhitekturo REST oz. jo naredijo slabo. Moč in fleksibilnost sistema REST temeljita na
uporabi URI (Uniform Resource Identifier). URI so samo imena in naslovi virov. Na
začetku je splet imel tri glavne komponente, in sicer jezik HTML, protokol HTTP in URI,
ki se je pozneje preimenoval v URL. Tako spoznamo, da splet ni zaslovel zaradi jezika
HTML in protokola HTTP, ampak zaradi URI oz. URL (Uniform Resource Locator) [33].
Slika 9 prikazuje, kako je URI lahko opredeljen kot ''lokator'' URL ali kot ime URN
(Uniform Resource Name). Za lažje razumevanje lahko URN razumemo kot osebno ime,
medtem ko si lahko URL razlagamo kot ime ulice [68].
Slika 9: Opredelitev URI [68]
Slika 10 prikazuje preprosti primer delovanja arhitekture REST.
Slika 10: Arhitektura REST [49]
Primerjava orodij za testiranje spletnih storitev 30
Kljub temu da REST ni standard, predpisuje uporabo standardov, kot so HTTP, URL,
XML, HTML, JPG itd. Preostane nam le, da poskušamo razumeti to arhitekturo in
oblikovati svojo spletno storitev po tem konceptu [34].
Splet je primer sistema REST. Vse spletne storitve, ki smo jih uporabljali leta nazaj
(storitev naročanja knjig, iskalne storitve itd.) temeljijo na arhitekturi REST. Ko govorimo
o arhitekturi REST, lahko rečemo, da ima njen pristop prednost v ceni arhitekture REST in
implementaciji storitev.
4.8 Arhitektura WOA
Arhitektura WOA (Web-Oriented Architecture) oz. spletno orientirana arhitektura
opisuje jedro določenih spletnih protokolov kot HTTP in planira XML kot najbolj
dinamičen, stopenjski pristop k spletnim storitvam. Edina prava razlika med SOA in
konceptom WOA je v tem, da WOA zagovarja arhitekturo REST in protokol HTTP. Eden
od glavnih ustvarjalcev WOA je tudi Roy Fielding [35].
Splošni odjemalec v arhitekturi WOA temelji na preizkušenih stvareh, ki temeljijo na
t. i. dobrih praksah. To pomeni izogibanje ustvarjanju in zmanjševanju serijskih abstrakcij
med storitvami in odjemalci ter zelo dobro razumevanje dogajanja preko omrežja. V
največ primerih ugotavljamo, da se arhitektura WOA najbolje obnese, ko uporablja REST
s protokolom HTTP [35].
Slika 11 prikazuje arhitekturo SOA in WOA. Na sliki lahko vidimo bistvene razlike med
obema arhitekturama.
Slika 11: Skupne lastnosti SOA in WOA [50]
Primerjava orodij za testiranje spletnih storitev 31
5 TESTIRANJE SPLETNIH STORITEV
5.1 Dejstva pri testiranju spletnih storitev
Na začetku moramo poudariti, da se testiranje programske opreme in testiranje spletnih
storitev bistveno ne razlikujeta [61]. Ko se odločimo, da bomo testirali storitve, se ti testi
največkrat vršijo kar na našem računalniku. Testiranje spletnih storitev poteka tako, da
pokličemo spletne metode testiranih enot. To testiranje je podobno testiranju drugih
programskih enot.
Čvrste tehnike testiranja so bistvene za razvijanje robustnih spletnih storitev. Napake se
lahko pojavijo v različnih slojih storitev in celo najmanjša napaka lahko povzroči, da
celotna storitev ne deluje več. Glede na to, da so spletne storitve dokaj nove, moramo pri
testiranju le-teh zelo dobro poznati arhitekturo, s katero imamo opravka.
5.2 Testiranje strežnikov
Testiranje strežnikov, lahko razvrstimo v štiri glavne kategorije, in sicer :
� funkcionalno testiranje (ang. Functional Testing): preveri, ali spletne storitve
delujejo pravilno,
� regresijsko testiranje (ang. Regression testing): preveri, kje se pojavljajo
''regresije'',
� obremenitveno testiranje (ang. Load testing): proces, v katerem podamo zahteve in
merimo odzive,
� zmogljivostno testiranje (ang. Performance testing): proces, v katerem
pregledujemo, kako hitro deluje določena storitev pri določenih obremenitvah.
Primerjava orodij za testiranje spletnih storitev 32
5.2.1 Funkcionalno testiranje
Funkcionalno testiranje je tipično prvi korak pri testiranju strežnikov spletnih storitev.
Bistveno pri tem testiranju je, da strežnik dostavi primeren odgovor na zastavljeno
vprašanje. Zaradi zapletenosti spletnih storitev je ta naloga zelo težka. Pregledovanje vseh
mogočih odgovorov je neprimerno, kajti prostor za primerne odgovore je brezmejen oz.
zelo velik. Kot rezultat je pomembno, da preverimo, ali lahko strežnik obravnava širši
pogled zahtevanih tipov in parametrov [36, 37].
Pri funkcionalnem testiranju spletnih storitev poznamo dva pristopa:
� Testni odjemalec pošlje zahteve strežniku preko HTTP povezave
To vključuje določanje tipov in mej zahtev, ki morajo biti testirane. S tem določimo, ali
bo lahko strežnik dosegel želene zahteve.
� Testni odziv se testira na podlagi pravilnosti
Najenostavnejši funkcionalni test vsebuje pošiljanje zahtev in pregledovanje, ali je
strežnik vrnil pravilni odgovor ali napako.
Ko opravljamo funkcionalno testiranje, moramo upoštevati, da imajo spletne storitve
več slojev in da se lahko pojavijo napake v katerem koli sloju oz. nivoju. Glavna naloga
funkcionalnega testiranja je ta, da pregleduje, ali se je zagotovila funkcionalnost spletne
storitve, kot smo pričakovali.
Za lažje razumevanje besede funkcionalnost si pomagamo z vprašanji, kot so npr. če
imamo spletno storitev, ki deluje kot kalkulator, ali vrne prave rezultate, če delimo z nič,
ali dobimo pravilen rezultat itd. Da lahko pozitivno odgovorimo na ta vprašanja, so zelo
pomembna mejna testiranja in pregledovanje najrazličnejših napak.
5.2.2 Regresijsko testiranje
Najpogostejša tehnika je, da pošljemo različne zahteve, ročno potrdimo odzive in jih
potem shranimo kot ''regresijsko kontrolo''. Če regresijski testi niso pogosti, se
popravljanje regresij hitro opravi. Regresijski test je ponavadi zmanjšana oz. znižana
Primerjava orodij za testiranje spletnih storitev 33
verzija funkcionalnega testiranja. Deluje na ta način, da pregleduje, ali spletna storitev še
deluje, medtem ko smo spreminjali staro oz. gradili novo [36, 37].
Za lažje razumevanje besede regresija si pomagamo z vprašanji, kot so npr. ali je
zmogljivost še vedno zadovoljiva in ali še deluje metoda za seštevanje, kljub temu da je
bila na novo definirana.
5.2.3 Obremenitveno testiranje
Glavna naloga je, da preverimo zmogljivost in funkcionalnost pri velikih obremenitvah
storitev. Preden se lotimo obremenitvenega testiranja, je treba izvesti regresijsko in
funkcionalno testiranje. Najboljši način pri obremenitvenem testiranju je, da imamo
delujoče odjemalce, ki pregledujejo celotne funkcionalne teste z vključevanjem zahtev in
pravilnostjo odgovorov. Če pri tem obremenitvenem testiranju ugotovimo nezaželene
spremembe pri zmogljivosti in funkcionalnosti, je najpomembneje, da to čim prej
analiziramo in popravimo napake [36, 37].
Ker napake, najdene pri obremenitvenem testiranju, povzročajo popravljanje aplikacij
ali celotnih sistemov, je najbolje, da čim prej začnemo s testiranjem. S tem testiranjem
ugotavljamo, kako se sistem obnaša, ko začne spletno storitev uporabljati 10, 100, 1000 in
več uporabnikov.
Za lažje razumevanje besede obremenitev si pomagamo z vprašanji, kot so npr, če
povečujemo število uporabnikov, ali se odzivni čas spreminja, ob katerem času je storitev
najbolj obremenjena itd.
5.2.4 Testiranje zmogljivosti
Testiranje zmogljivosti je proces za določanje hitrosti, učinkovitosti oz. uspešnosti pri
omrežjih, programski opremi, spletnih storitvah itd. Uspešno razvijanje spletnih storitev je
pogojeno z zmogljivostnim testiranjem. Zmogljivost spletnih storitev je največkrat
prepuščena kasnejšim fazam razvoja spletnih storitev. Če upoštevamo zmogljivost v
zgodnejši fazi razvoja spletnih storitev, dobimo številne ugodnosti oz. koristnosti. Prva
takšna koristnost je povezana z zgodnejšim odkrivanjem programskih hib (ang. bug), kjer
odkrivamo probleme v pomnilniku, pri sočasnem izvajanju itd. Druga takšna pridobitev je,
Primerjava orodij za testiranje spletnih storitev 34
da imajo projektni vodje nenehen vpogled v zmogljivost spletne storitve. Kot zadnjo
pomembno pridobitev lahko navedemo, da lahko s tem testiranjem preračunamo oz.
določimo stroške opravljanja zmogljivosti spletne storitve [38].
Glavni cilj testiranja zmogljivosti spletnih storitev je iskanje odgovora na vprašanje,
kako se spletna storitev obnaša, ko se število uporabnikov povečuje. Zbiramo
zmogljivostne informacije storitev na strežniku, lokalnih računalnikih in spremljamo
uporabo centralne procesne enote, obremenjenost omrežja, uporabo delovnega spomina itd.
Omenimo, da se zmogljivostno testiranje in obremenitveno testiranje v nekaterih
člankih, orodjih itd. pojavljata v skupni navezi kot obremenitveno in zmogljivostno
testiranje (Load & Performance testing).
5.3 Testiranje odjemalca
Razvijalci odjemalca spletne storitve so odgovorni, da zagotovijo, da odjemalec pošlje
pravilne zahteve. Če odjemalec pošlje nepravilno ali neprimerno zahtevo, mu strežnik ne
more odgovoriti s pričakovanim rezultatom in največkrat vrne napako. Proces testiranja
odjemalca je nekoliko drugačen od testiranja spletnih storitev [36, 37].
Obstajata dva vidika, ki ju je treba preveriti:
- ali odjemalec pravilno deluje pri pošiljanju zahtev in
- ali je obnašanje odjemalca, ko dobi odgovor, pravilno.
Odjemalec pošlje zahtevo, strežnik mu odgovori, ali je odgovor uspešen ali napačen pa
je odvisno od pregledovanja in ugotavljanja pravilnosti zahteve, ki določa pravilnost
odgovora.
Seveda nas lahko napake na strežniku zavedejo. Npr. če strežnik ne deluje pravilno,
lahko namesto zahteve, za katero vemo, da vrača napako, dobimo pozitiven odgovor.
Primerjava orodij za testiranje spletnih storitev 35
5.4 Druge možnosti testiranja
Testiranje funkcionalnosti in obremenitev sta dva temeljna načina testiranja spletnih
storitev. Zraven teh dveh jih je še nekaj, med drugimi tudi testiranje varnosti, testiranje
medsebojne interoperabilnost in uporaba registra UDDI.
5.4.1 Testiranje varnosti
Varnost (ang. security) spletnih storitev ni samostojen problem [36, 37].
Pomembni vidiki pri razvijanju varnih spletnih storitev so:
� zasebnost
Pri storitvah je pomembno, da sporočila niso vidna, razen za tista dva akterja, ki
komunicirata. To pomeni, da mora biti promet šifriran.
� preverjanje neokrnjenosti sporočila
Priskrbi zagotovilo, da sporočilo, ki je bilo sprejeto, med potjo ni bilo spremenjeno.
� avtentikacija
Priskrbi zagotovila, da je sporočilo iz dejanskega izvora, iz katerega je bilo poslano.
� avtorizacija
Odjemalcu naj bi bil dovoljen samo dostop do storitev, do katerih sme dostopati.
5.4.2 Medsebojna interoperabilnost
Interoperabilnost je zmožnost sistema ali izdelka, da sodeluje z drugimi sistemi ali
izdelki brez posebnega truda uporabnika storitve. Interoperabilnost je zelo pomembna
kakovost za izdelke informacijske tehnologije.
Testiranje interoperabilnosti (ang. interoperability) pri spletnih storitvah zahteva, da
naredimo posebne teste za WSDL. Ti testi zagotavljajo, da so izbrane spletne storitve
interoperabilne s pošiljanjem posebnih zahtev k spletnim storitvam in določanjem, ali
spletna storitev odgovori [36, 37].
Primerjava orodij za testiranje spletnih storitev 36
5.5 Glavni izzivi pri testiranju spletnih storitev
Tako kot vse programske rešitve morajo biti preizkušene tudi spletne storitve. Spletne
storitve so ponavadi zelo izpostavljene, zato morajo biti še toliko bolj robustne.
Glede na vse lahko rečemo, da obstajata dva glavna tipa spletnih storitev:
� spletne storitve, uporabljene na intranetu
Te storitve se uporabljajo znotraj različnih organizacij in so izpostavljene manjšemu
krogu uporabnikov. Intranet je zasebno računalniško omrežje, ki uporablja spletni protokol
in mrežno povezanost za varno delovanje podjetja in varno pošiljanje informacij
zaposlenim. Z uporabo intraneta imamo kontrolo nad tem, kdo dostopa do naše spletne
storitve. Glede na to, da je omrežje notranje, lahko ima dostop le določeno osebje. Tako
lahko imamo pri varnostnem sistemu svoje zahteve in svoje postopke [39].
Pri intranetu se največkrat uporabljata enak koncept in tehnologija kot pri spletu, npr.
odjemalec in strežnik, ki tečeta na spletnem protokolu. Tudi uporaba protokola FTP pri
intranetu je zelo pogosta.
� spletne storitve, uporabljene na spletu
Splet deluje v medmrežju in se uporablja za prikaz spletnih strani in pošiljanje datotek.
Do uporabe spletnih storitev na spletu ima dostop že skoraj vsak. To prinaša dodatne
težave pri varnosti. Naslednja težava pri testiranju spletnih storitev je ta, da ne vidimo
uporabniškega vmesnika, ki naj bi ga testirali. To pomeni, da jih zelo težko ''ročno''
testiramo, in so idealne za avtomatično testiranje [40].
5.6 Faze testiranja spletnih storitev
V današnjem času so spletne storitve malo več kot komponente programske opreme,
ovite v SOAP-vmesnik. Tako lahko prodajalci dodajo preprosto XML-podporo k njihovim
proizvodom in že lahko uporabnikom ponujajo testiranje spletnih storitev.
Primerjava orodij za testiranje spletnih storitev 37
Zato se pri testiranju spletnih storitev pogosto sprašujemo, katero orodje je najboljše za
testiranje spletnih storitev, kajti marketinških proizvodov je veliko in njihova kakovost oz.
uporabnost je slaba [41, 42].
1.faza (2002–2004) Notranje osredotočeno testiranje
Prvotna uporaba spletnih storitev je temeljila na zmanjševanju stroškov integracij
znotraj požarne pregrade (ang. firewall) [41, 42].
Pri prvi fazi je najpomembnejše testiranje zmožnosti spletnih storitev, kot so:
� testiranje sporočil SOAP
Uporabimo SOAP kot vmesnik za spletne storitve, pri katerem testiramo obliko samih
sporočil.
� testiranje datotek WSDL in uporabe le-teh za ustvarjanje testnih načrtov
Datoteke WSDL vsebujejo metapodatke o vmesniku spletne storitve. Testna orodja
lahko uporabijo te datoteke za ustvarjanje avtomatičnih testnih načrtov.
� spletne storitve uporabnikov
Ko testno orodje ustvari testno sporočilo, se le to pošlje na spletno storitev.
2.faza (2004–2007) Testiranje SOA
Ko so se pojavili novi produkti in nove storitve na trgu, so te spletne storitve
vključevale varnost, upravljanje in transakcije, s katerimi je bilo možno izmenjavati
sporočila z drugimi podjetji (uporabniki, dobavitelji, partnerji itd.) [41, 42].
Naslednje zmožnosti so postale pomembne pri testiranju spletnih storitev:
� testiranje objavljanja, iskanja in povezovanja oz. »objavi, poišči in poveži«
zmožnosti SOA.
� testiranje asinhrone zmožnosti spletnih storitev
Pri uporabi asinhronih zmožnosti povemo, da SOAP prav tako uporablja asinhrona
sporočila, vključno z notifikacijami in opozorilnimi sporočili. Testna orodja naj
testirajo kakršno koli sporočilo SOAP.
Primerjava orodij za testiranje spletnih storitev 38
� testiranje SOAP vmesnih zmožnosti
SOAP specifikacija omogoča vmesna sporočila. Testna orodja morajo preveriti
primerno funkcionalnost teh vmesnih sporočil.
� spremljanje kvalitete storitev
Tradicionalno je IT-vodstvo odgovorno za delovanje, medtem ko za testiranje
programske opreme odgovarjajo razvijalci. To se z uvedbo storitveno orientiranega
okolja (npr. SOA) spremeni.
3. faza (od leta 2004): Testiranje zmožnosti dinamičnega časovnega izvajanja
Ta faza je zelo podobna prejšnji, vendar se tukaj storitve spreminjajo, ko jih uporabnik
''pokliče''. Zaradi koncepta spletne storitve postajata uporabnik in izdelovalec vedno manj
pomembna. Na podlagi tega bomo dobili vedno bolj obsežne spletne storitve, ki bodo
povezane z različnimi drugimi storitvami, s katerimi bo možno dostopati do različnih
storitev (npr. do odobritve kredita pri banki) [41, 42].
Tukaj naj bi imela testna orodja naslednje zmožnosti testiranja:
� testiranje orkestriranih (ang. orchestration) spletnih storitev
Tukaj se kombinira veliko majhnih spletnih storitev v večje. Takšne spletne storitve
ponavadi vključujejo več podjetij.
� testiranje različnih verzij spletnih storitev
Z novimi verzijami spletnih storitev postaja testiranje kompleksnih storitev posebej
kompleksno in tvegano.
Prav zaradi vseh teh dejstev bodo morali razvijalci spletnih storitev uporabiti agilen
pristop k testiranju in razvijanju. Treba bo sodelovati z uporabniki, uporabiti pravilen
pristop, napisati testno programsko kodo in ponavljati teste do konca produkta.
Agilen pristop (ang. agile approach) je pristop, ki omogoča pregled projekta skozi vse
faze življenjskega cikla proizvoda.
Primerjava orodij za testiranje spletnih storitev 39
5.7 SOA testiranje z uporabo črne, bele in sive škatle
Obstajajo bistvene razlike med temi metodami in tradicionalnimi metodami za
testiranje programske opreme. Pri SOA so metode veliko bolj razširljive in diagnostične ter
se nanašajo na tretjo skupino spletnih storitev, ki jih lahko spreminjamo brez predčasne
najave. Pomembna stvar pri teh metodah je tudi, da imajo razvijalci med testiranjem
dostop do opisa vmesnika (WSDL) spletne storitve in programske kode [43].
5.7.1 Testiranje po metodi črne škatle
To testiranje lahko uporabljajo različni preizkuševalci, ne da bi vedeli, kakšna sta
implementacija, programski jezik itd. Prednosti se pokažejo pri velikih kodnih segmentih
in enotah. Imamo jasno ločeno uporabniško in razvijalčevo perspektivo in dostop do kode
ni potreben. Slabosti se kažejo v tem, da ne poznamo implementacije in zato je težko najti
najprimernejše podatke, prav tako ni mogoče določiti, kje v programu je več in kje manj
napak. Testiranje po metodi črne škatle se najbolje obnese pri hitrih testnih scenarijih in pri
hitrih prototipih spletnih storitev. Pri tej metodi dobimo hitre odzive na to, kako stvar
deluje [43].
5.7.2 Testiranje po metodi bele škatle
Prednosti tega testiranja so, da implementacija ni pogojena z obliko proizvoda. Z
analiziranjem programske kode in razvijanjem testov, ki temeljijo na implementaciji,
preizkuševalcu omogoča, da hitreje najde programske napake. Tudi dostop do izvorne
kode izboljšuje razumevanje in hitrejšo zaznavanje sprememb v programu.
Glavna slabost tega testiranja je, da moramo imeti zanesljivega in visoko
usposobljenega preizkuševalca, kljub temu da poznamo celotni sistem, testna orodja, jezik
programiranja in modeliranje. Pri spreminjanju programske kode pri manjših aplikacijah
ne pride do težav, medtem ko v primeru, da želimo spreminjati programsko kodo velikih
aplikacij, pride do težav. Tudi t. i. meja med razvijalcem in preizkuševalcem se začne
rušiti.
Primerjava orodij za testiranje spletnih storitev 40
Testiranje po metodi bele škatle je najbolj primerno za spletne storitve v zgodnji fazi
razvoja, saj lahko preizkuševalec hitreje najde napake. To testiranje je problematično pri
testiranju objektnega sistema SOA. Pozitivna stran tega testiranja je ta, da poznamo
programski jezik, operacijski sistem in strojno opremo.
Pogosto so metode bele skrinjice povezane z merami za pokritost testiranja, ki merijo
odstotek izbranih poti, izvršenih v določenem testnem scenariju. Tako imajo projekti
ponavadi določeno stopnjo pokritosti, katera služi razvijalcem in testerjem kot merilo
kako temeljito je potrebno testirati aplikacijo [43].
5.7.3 Testiranje po metodi sive škatle
Najpomembnejša prednost tega testiranja je, da je povezano z metodama bele in črne
škatle ter da se zanaša na dostop do programske kode. To testiranje temelji na definiciji
vmesnika, funkcionalni specialnosti in aplikacijski arhitekturi, t. i. meja med razvijalci in
preizkuševalci pa ostaja.
Slabost tega testiranja je, da je pot skozi kodo vedno omejena, kar pa se kaže pri
razpoložljivost informacij. To testiranje omogoča delovanje z arhitekturo SOA. Z uporabo
jezika WSDL omogoča nekakšen sporazum med uporabniki in proizvajalci spletnih
storitev, ki temeljijo na arhitekturi SOA.
Prodajna lastnost spletnih storitev prispeva k popolnosti metode sive škatle za
odkrivanje napak znotraj SOA. Ker jezik WSDL vsebuje bogato vsebino informacij, lahko
po metodi sive škatle ustvarjamo inteligentne in zmogljive teste [43].
5.8 Testna orodja so klju čna za uspeh spletnih storitev
Testna orodja veliko pripomorejo k izboljšanju in razumevanju spletnih storitev.
Osnove uporabe spletnih storitev, kot je zbiranje aplikacij preko spleta z uporabo odprtega
vmesnika in protokola, pa ustvarjajo svoje izzive. Zato se podjetja nenehno sprašujejo, kaj
lahko storijo, da bodo spletne storitve delovale zanesljivo in da bodo brez večjih
problemov delovale v spletnih poslih.
Eden od odgovorov je, da uporabljajo primerno programsko opremo in s tem testirajo
zmogljivost in funkcionalnost spletnih storitev. Strokovnjaki vedno pričakujejo in
Primerjava orodij za testiranje spletnih storitev 41
govorijo, da testna orodja zelo vplivajo na uspešnost implementacij spletnih storitev.
Kakovost je veliko bolj pomembna pri spletnih storitvah kot pa pri drugih aplikacijah,
kajti pri spletnih storitvah imamo veliko združljive programske opreme, ki je nato
povezana v neko celoto, ki tvori sistem, in ta sistem mora vedno delovati popolno. Zato je
najbolje uporabljati avtomatizirana orodja za testiranje spletnih storitev.
Slika 12 prikazuje porast (v milijardah) uporabe avtomatiziranih testnih orodij med leti
2001 in 2006.
Slika 12: Prikaz rasti avtomatiziranih testnih orodij [51]
Primerjava orodij za testiranje spletnih storitev 42
6 ORODJA ZA TESTIRANJE SPLETNIH STORITEV
6.1 Opis orodij
Brez dobrih orodij ni dobrega izdelka, zato je priporočljivo vedno uporabljati najboljša
orodja, ki so na voljo. Prav tako morajo orodja podpirati posameznike ter razvojno ekipo in
ne obratno. Za avtomatizirano testiranje spletnih storitev obstajajo različna orodja, ki delo
olajšujejo.
6.1.1 Orodje SOAP Sonar
Orodje SOAP Sonar [52] je preprosta rešitev za testiranje spletnih storitev. Lahko ga
zelo hitro namestimo brez sprememb v aplikacijski kodi ali mrežni topologiji. Zagotavlja
celotno vidljivost obstojnosti, uporabnosti in ''zdravje'' spletnih storitev. SOAP Sonar lahko
pregleda celotno vsebino sporočil spletnih storitev in jo predstavi na razumljiv način.
Slika 13 prikazuje delovanje orodja SOAP Sonar.
Slika 13: Delovanje orodja SOAPSonar [52]
SOAP Sonar je orodje, ki zagotavlja obsežno testiranje spletnih storitev. Z njim lahko
izvajamo funkcionalno testiranje, zmogljivostne profile, ocenitve ranljivosti in identiteto
upravljanja testiranja.
Primerjava orodij za testiranje spletnih storitev 43
Glavna naloga orodja SOAP Sonar je, da uporabnikom omogoča izvajanje
funkcionalnega in obremenitvenega testiranja. Prav tako omogoča testiranje zanesljivosti
in robustnosti spletnih storitev, še preden so razvite.
6.1.2 Orodje GreenHat
Orodje GreenHat [53] razdelimo na tri dele, in sicer na GH Viewer, GH Tester in GH
Tracer. Namen orodja GH Tracer je shranjevanje sporočil od TIBCO. Zanimata nas
predvsem GH Viewer in GH Tester.
• GH Viewer
Omogoča pregledovanje omrežnega prometa, shranjuje zgodovino ter primerja minule
in trenutne izvršitve.
GH Viewer omogoča:
- spremljanje prometa: z nenehnim posodabljanjem prikaza omrežnega prometa
omogoča spremljanje stanja omrežja,
- alarmiranje: uporabnik lahko postavi lastna pravila, na podlagi katerih se sproži
alarm. Alarm se lahko pokaže na različne načine, kot so npr. sporočila na zaslonu,
elektronska sporočila itd.,
- shranjevanje podatkov: GH Viewer shranjuje podatke tako dolgo, kot si to želi
uporabnik,
- prikaz ''povzetkov'' (ang. summaries): omogoča zelo pregleden prikaz delovanja.
• GH Tester
Omogoča avtomatično testiranje ESB, SOA, JMS, spletnih storitev. Dobra strateška
integracija bo oblikovala poslovni proces in katalog sporočil avtomatično in potem
naročila posameznikom ali skupini, da naredijo te komponente.
Primerjava orodij za testiranje spletnih storitev 44
Z delitvijo definicij sporočil med uporabnikom in proizvajalcem lahko obe strani z
vmesnikom testirata enake podatke, odpravljata najrazličnejša presenečenja itd.
Novejše verzije tega programa podpirajo tudi sisteme, ki ne uporabljajo grafičnega
vmesnika. Je zelo močno orodje, ki omogoča hitro oblikovanje testov.
6.1.3 Orodje Parasoft SOAtest
Orodje Parasoft SOAtest [54] je proizvod za zagotavljanje varnosti, zanesljivosti in
skladnosti s SOA. Je orodje, narejeno posebej za testiranje in validiranje varnosti in SOA.
Orodje SOAtest avtomatizira prakse, ki dovoljujejo verifikacijo pri vsakem pogledu
spletnih storitev, ki vključujejo validacijo dokumentov WSDL, enotno in funkcionalno
testiranje odjemalca in strežnika, testiranje zmogljivosti, kompleksnost testiranja itd.
Njegove prednosti se kažejo predvsem v kvaliteti procesov, ki niso odvisni od
zagotavljanja kakovosti – QA (ang. Quality assurance). Orodje teži k zmanjšanju časa,
potrebnega za izvedbo testiranja, in zagotavljanju uspešnosti projekta.
6.1.4 Orodje itko LISA 4 SOA
Orodje itko LISA 4 SOA [55] je obsežno orodje, grajeno od spodaj navzgor, z
namenom zagotoviti kvaliteto, kompleksnost, povezanost aplikacij in integracijo pri SOA
aplikacijah. Vse zgoraj omenjene razsežnosti tega orodja so vidne na sliki 14.
Slika 14: Prikaz IT tveganja in zanesljivosti SOA [55]
Da preprečimo IT tveganje in zagotovimo zanesljivo SOA-aplikacijo,
mora proizvod delovati v smislu zagotavljanja celovitosti (ang.
complete), skupinskega sodelovanja (ang. collaborative) in trajanja
(ang. continuous).
Primerjava orodij za testiranje spletnih storitev 45
Produkt itko Lisa 4 SOA je razdeljen na dve skupini, kar prikazuje slika 15.
Slika 15: Arhitektura itko LISA 4 SOA [55]
LISA Server
- obremenitveno in zmogljivostno testiranje
Omogoča visoko zmogljivost, nizke sistemske stroške, nenehno podporo pri razvoju in
integraciji življenjskega cikla, napredno metrično vidljivost in alarmiranje, itd.
- nepretrgano validiranje storitev
Omogoča validiranje integracijske aktivnosti, razvijajoče aplikacije in običajne
postopke, itd.
- navidezno spletno okolje
Omogoča varčevanje denarja, lažje upravljanje s testi ter razvijanje in testiranje, itd.
Lisa Enterprise
- funkcijsko testiranje
Omogoča testiranje po ''širini in globini'', visoko učinkovitost testiranja, ponovno
uporabo, itd.
- integracijsko testiranje
Omogoča podporo in zagotavlja interoperabilnosti in podporo integracijskih procesov,
itd.
Primerjava orodij za testiranje spletnih storitev 46
- validiranje poslovnih procesov
Omogoča uporabo kolaboracije in maksimira ponovno uporabo testiranja.
Lisa Extension Kit
Omogoča razširljivost orodja za razvijalce preko API-zahtev. Lisa Extension Kit deluje
v smislu vzajemnega delovanja naše aplikacije.
6.1.5 Orodje SoapUI
Orodje SoapUI [56] je v celoti zgrajeno na platformi Java in uporablja Java Swing za
predstavitev uporabniškega vmesnika. Orodje SoapUI je eno vodilnih orodje za testiranje
spletnih storitev. Z več kot 500.000 namestitvami je eno najbolj uporabljanih orodij na
svetu.
Orodje SoapUI deluje kot namizna aplikacija za pregledovanje, proženje, razvijanje,
simuliranje, funkcionalno in obremenitveno testiranje spletnih storitev. Glavni cilj
razvijalcev/preizkuševalcev je določevanje uporabniških spletnih storitev (Java, .Net itd.)
Orodje SoapUI delimo na različne podskupine, in sicer na pregled spletnih storitev,
klicanje spletnih storitev, simuliranje spletnih storitev, razvijanje spletnih storitev,
funkcionalno testiranje spletnih storitev, obremenitveno testiranje spletnih storitev itd.
6.1.6 Orodje JMeter
Orodje Apache JMeter [57] je orodje, izdelano na platformi Java, in deluje kot namizna
aplikacija. Lahko ga uporabimo za testiranje zmogljivosti na statičnih in dinamičnih virih
(datotekah, servletih, Perl skriptah, FTP-strežnikih itd.). Uporabimo ga lahko za
simuliranje obremenitev strežnikov, omrežij itd. in jih nato analiziramo s pomočjo
grafičnega vmesnika. Uporablja se lahko tudi za testiranje JDBC baz, FTP, LDAP, JMS,
HTTP in generične TCP-povezave. JMeter ni spletni brskalnik, ampak le simulira spletni
brskalnik.
Primerjava orodij za testiranje spletnih storitev 47
6.1.7 Orodje TestMaker (PushToTest Test Maker) Orodje TestMaker [58] je primerno za testiranje spletnih aplikacij, SOA, spletnih
strežnikov, poštnih sistemov, java aplikacij itd.
TestMaker je razdeljen tako, da ga lahko uporabljajo tri različne skupine ljudi oz.
uporabnikov: razvijalci, QA-preizkuševalci in IT-direktorji. Slika 16 prikazuje zgradbo in
delovanje orodja PushToTest.
Možna je tudi združitev SoapUI in Pushtotest.
Slika 16: Arhitektura TestMaker [62]
6.1.8 Orodje Altova XmlSpy
Orodje Altova XMLSpy je razvojno okolje za modeliranje, urejanje, odkrivanje napak
in pretvorbo obstoječih dokumentov XML ter samodejno generiranje izvajalne kode v
različnih programskih jezikih itd. Orodje Altova XMLSpy povečuje storilnost J2EE, NET,
Eclipse razvijalcev, načrtovalcev podatkovnih zbirk, skratka vseh, ki želijo uporabljati
najnovejše tehnologije XML, spletne storitve in podatkovne zbirke.
Primerjava orodij za testiranje spletnih storitev 48
Izdelki orodja Altova XmlSpy [59],so razdeljeni v 10 podskupin, za nas zanimiv je
predvsem produkt Altova XmlSpy 2008.
Altova XMLSpy je standardno razvojno okolje za modeliranje, urejanje, pretvarjanje in
razhroščevanje tehnologij, povezanih z jezikom XML. Nudi vodilni urejevalnik za
datoteke XML, originalni grafični načrtovalec shem, generator kode, pretvornike datotek,
razhroščevalnik in profilirnik za XSLT, XQuery, WSDL, SOAP, integracijo z Visual
Studio in Eclipse itd. Orodje Altova XmlSpy je nepogrešljivo za razvijalce XML, spletnih
storitev in podatkovnih baz.
6.2 Prikaz zna čilnosti posameznih orodij
V Tabeli 2 so orodja razdeljena glede na štiri osnovne kriterije. Ti kriteriji (zadnja
verzija, integracija z drugimi proizvodi, sistemske zahteve in cena) služijo kot prvo
spoznavanje z novimi orodji in so zelo pomembni za prvo oceno teh orodij. Kot vsa dobra
orodja so tudi ta na svojih spletnih straneh predstavljena s temi kriteriji. Tako je bila naša
naloga te podatke izbrskati v uradnih publikacijah in jih predstaviti v tabeli.
Primerjava orodij za testiranje spletnih storitev 49
Tabela 2: Prikaz značilnosti posameznih orodij
orodje zadnja verzija
integracija z drugimi produkti
sistemske zahteve cena
SOAP Sonar
last
enterprise edition
JUnit, HP Quality center,
Windows Tasks, Batch
Processing Sugar CRM
Windows 2000/XP/
2003 Server
799 $
GreenHat
3.4.2 Tibco Windows 2000/XP ?
Parasoft SOAtest
5.5.1
Microsoft VSTS (Visual
Studio Team System),
Bea
Windows 2000/XP/ Vista,
Linux, Solaris/ Unix
Pentium 4 - min 512 mb
RAM, priporočeno 1024
mb RAM
od 3.995$ dalje
licenca + učenje skupine petih ljudi stane okrog 50.000$
itko Lisa 4 Soa
4.0.4
IBM MQ-Series, TIBCO,
WebMethods, Oracle
Fusion, Sun JCAPS,
Sonic MQ, Bussiness
Works, Software AG
Windows 2000/XP/ Vista,
Linux, Solaris/ Unix,
Mac OS X
Pentium III z 1Ghz
procesor in 1024mb RAM
4.000$ – 9.500$
SoapUI
2.0.2
XmlBeans 2.x, JAXB 2.x,
GSoup, JBoosWs, JAX-
RPC, Axis 1.x, Axis 2.x,
xFire 1.x, Apache Top-M.
Windows 2000/XP/Vista
Linux, Mac OS X,
Solaris/Unix
177 $ - 415 $
JMeter
2.3.1
AIPs, ULC 6.1, NetBeans, Eclipse
Windows 98/NT/XP/
Vista, Linux, Solaris/Unix
OpenVMS Alpha 7.3
odprta koda (BSD Open
Source License)
TestMaker (PushToTest)
5.1
SoapUI, WLS 8.1,
WebLogic, Oracle
Windows 2000/XP/Vista/
2003 Server, Linux,
Solaris/Unix, Mac OS X
odprta koda (BSD Open
Source License)
XmlSpy
2008
IBM DB2, MapForce,
Style Vision, Eclipse,
Visual Studio .Net, E
Windows 2000/XP/Vista/
2003 Server, Linux,
Mac OS X
65$ - 1790$
Vir: Spletne strani [52-59]
Primerjava orodij za testiranje spletnih storitev 50
7 ZNAČILNOSTI ORODIJ Tabela 3 prikazuje za nas najpomembnejše karakteristike orodij. Te karakteristike so
prikazane v t.i. osnovni tabeli, v kateri predstavimo najvišji nivo. V prejšnjih poglavjih
diplomske naloge smo te karakteristike podrobno opisali in jih predstavili. Posamezne
primerjave so opisane v analizi raziskav.
Oznaka »« označuje podporo, prazna celica tabele označuje, da orodje ne vsebuje
podpore za določeno funkcionalnost.
7.1 Osnovna primerjalna tabela
Tabela 3: Osnovna primerjalna tabela
Orodje
Fu
nkcio
nalno
testiranje
Ob
remen
itven
o testiran
je
Zm
og
ljivostn
o
testiranje
Reg
resijsko
testiranje
Testiran
je
varno
sti
Mo
žno
st
validiran
ja
Po
dp
ora
različnih
pro
toko
lom
Po
ročanje o
rezultatu
Po
dp
ora
(do
k., baz,..)
SOAP Sonar
GreenHat
Parasoft SOAtest
itko Lisa 4 SOA
SoapUI
JMeter
TestMaker
XmlSpy
Funkcionalno testiranje
Obremenitveno testiranje
Orodje
delo
vanje z po
sredn
ikom
ustvarjan
je / gen
eriranje testov
zahtev/o
dziva
prikaz W
SD
L
po
dpora u
kazne vrstice
avtom
atični testi
SO
AP
prilog
e
po
dpora R
ES
T
avtom
atično u
stvarjanje testov
na p
odlag
i WS
DL
up
orabn
iško p
rijazna
navig
acija SOA
P
uvo
z WS
DL
-ja
preg
led p
o ustrezn
osti W
SD
L
GU
I/IDE
pro
jektno up
ravljanje
od
zivni čas
op
timizacija tesn
ih pod
atkov
različne m
ožn
ost d
oloč. (čas,
velikost, niti,..)
št. transakcij u
spešn
ih /
neu
spešn
ih
SOAP Sonar
GreenHat
Parasoft SOAtest
itko Lisa 4 SOA
SoapUI
JMeter
TestMaker
XmlSpy
.
Prim
erja
va orod
ij za te
stiran
je sp
letn
ih sto
ritev
51
Tabela 4 prikazuje podro
bno primerjavo zgoraj preds
tavljenih karakteristik (podpogl. 7.1). T
ukaj se osredotočimo n
a posamezno karakteristiko in jo s pom
očjo tabele nazorno
prikažemo.
7.2 Podrobna prim
erjalna tabela T
abela 4: Podrobna prim
erjalna tabela
Primerjava orodij za testiranje spletnih storitev 52
Zmogljivostno testiranje
Regresijsko testiranje
Testiranje varnosti
Validiranje (ang.validate)
Orodje
navid
ezni up
orabn
iki
do
ločan
je testov in sprem
ljanje
rezultato
v
Sp
remljan
je porab
e om
režja
Sp
remljan
je porab
e RA
M-a
op
timizacija tesn
ih pod
atkov
Sp
remljan
je porab
e CP
U
po
vprečn
i čas
funkcija za d
ol. reg. kon
trol
snem
anje in
pon
ovno p
red.
spo
ročil
Po
novn
a upo
raba (tesn
ih p
rimerkov, ...)
WS
-varnost po
dpis / p
reverjanje
WS
-varnost šifriranje /
dešifriran
je
Up
orab
a SS
L
Preg
led certifikata
zaščita up
orab
niško ime
zaščita z geslo
m avten
tikacija
Preg
led S
OA
P
po
dpora u
kazne vrstice
prejem
anje / p
ošiljan
je
zahteve / od
ziva
razhro
ščevanje
WS
DL
XM
L
SOAP Sonar
GreenHat
Parasoft SOAtest
itko Lisa 4 SOA
SoapUI
JMeter
TestMaker
XmlSpy
Tabela 4: P
odrobna primerjalna tab
ela
Prim
erjava o
rodij za
testira
nje sp
letn
ih sto
ritev
52
Primerjava orodij za testiranje spletnih storitev 53
Podpora različnim protokolom
Poročanje o rezultatih
Podpora (dokumenotv, podatkovnih baz, ..)
Orodje
HT
TP
HT
TP
S
TC
P/IP
SO
AP
FT
P
SM
TP
SS
L
Kerb
eros
PO
P3
& IM
AP
Excel
PD
F
HT
ML
statistika lo
giran
ja
grafičn
i prikaz
XM
L
UR
I
xPath
XM
L
WS
DL
Pod
. bazam
XS
D
DT
D
SOAP Sonar
GreenHat
Parasoft SOAtest
itko Lisa 4 SOA
SoapUI
JMeter
TestMaker
XmlSpy
Tabela 4: P
odrobna primerjalna tab
ela
Prim
erjava o
rodij za
testiran
je sp
letn
ih sto
ritev
53
7.3 Analiza raziskav
Rezultati raziskav so bili pridobljeni s pomočjo različnih publikacij o uporabljenih
orodjih, v največji meri pa s testiranjem in primerjavo orodij.
Največ podatkov oz. rezultatov je bilo pridobljenih s posamičnim (fizičnim) testiranjem
in primerjavo teh orodij na posameznih primerih. Vsa orodja so bila testirana na istem
računalniku z istimi primeri. Prav tako so bila vsa orodja podrobno pregledana, preučena,
testirana in na koncu s pomočjo tabel podrobno predstavljena.
Konfiguracija računalnika:
- računalnik: '' itwef2'' – operacijski sistem Windows XP
(Pentium 4 – 2,66 Ghz, 512 mb RAM)
- Pri testiranju smo se omejili na spletne storitve izdelane na platformi Java.
Delujejo na principu Strežnika in Odjemalca. Uporabili smo orodje NetBeans 6.0 v
katerem smo postavili okolje za našo testiranje. Pripravili smo spletno storitev
»Kalkulator« in preko nje testirali vsa naša orodja.
7.3.1 Funkcionalno testiranje
Kot kaže tabela 3, vsa orodja podpirajo funkcionalno testiranje, kar se za današnja
sodobna testna orodja zdi popolnoma logično. V tabeli 4 je prikazana podrobna primerjava
orodij pri funkcionalnem testiranju. Večina orodij podpira posrednike (ang. proxy), le
orodja SoapUI, TestMaker in XmlSpy tega ne omogočajo. Tudi ko pogledamo stolpec
SOAP-priloge (ang. Soap attachments), lahko vidimo, da vsa orodja podpirajo to opcijo.
SOAP-priloge dovoljujejo uporabo MIME za pošiljanje binarnih podatkov v SOAP-
sporočilih. Nekatera orodja (JMeter, TestMaker, SOAPSonar) ne omogočajo avtomatične
izdelave ukaza zahteva/odziv (ang. Response/request) na podlagi dokumenta WSDL, kar
pomeni, da si moramo sami pripraviti primerno zahtevo in jo pošiljati. Ostala orodja
omogočajo avtomatično generiraje oz. prikaz zahtev in odzivov, ki jih lahko poljubno
spreminjamo in dopolnjujemo. Večina orodij podpira pregled samega dokumenta WSDL,
izjema je le orodje JMeter. Prav tako vsa orodja omogočajo ustvarjanje in generiranje
najrazličnejših testov. Ustvarjanje in generiranje testov je ena najpomembnejših funkcij, ki
jo mora imeti vsako sodobno in dobro orodje, da ga lahko štejemo kot orodje za testiranje.
Primerjava orodij za testiranje spletnih storitev
54
Primerjava orodij za testiranje spletnih storitev 55
Kot ostale pomembne značilnosti še lahko navedemo uvoz dokumenta WSDL in pregled
ustreznosti le-tega, vendar omenjeni funkcionalnosti omogočajo le SOAPSonar, SoapUI,
itko LISA 4 SOA in XmlSpy 2008. Večina orodij podpira tudi REST-arhitekturo za spletne
storitve, le orodje JMeter in orodje GreenHat ne. Orodja (SoapUI, JMeter, TestMaker)
delujejo preko GUI/IDE-okolja. Zaradi skupnih načrtov in enakega okolja se orodji
SoapUI in TestMaker (PushToTest) združujeta v skupno orodje SoapUI + TestMaker.
7.3.2 Obremenitveno testiranje
Kot prikazuje tabela 3, skoraj vsa orodja podpirajo obremenitveno testiranje, le
SOAPSonar in XmlSpy ne. V tabeli 4 je prikazana podrobna primerjava orodij pri
obremenitvenem testiranju. Prikaz odzivnega časa pri testiranju obremenitev omogočajo
samo orodja Parasoft SOAtest, itko LISA 4 SOA, SoapUI, TestMaker, medtem ko
omogočata optimizacijo tesnih podatkov le orodji itko LISA 4 SOA in TestMaker. Prav
tako vsa orodja razen dveh (SOAPSonar, XmlSpy) podpirajo različne možnosti pri
obremenitvenem testiranju, tj. spremljanje časa, določanje ponavljajočih intervalov,
določanje trajanja testov itd. Seveda je najbolje, če imamo čim več možnosti, s katerimi
lahko spremljamo in izvajamo obremenitveno testiranje, tako nam obremenitveno
testiranje nudi obilo koristnih možnosti, s katerimi obremenjujemo našo spletno storitev in
spremljamo rezultate. Kot koristno zadevo lahko omenimo tudi spremljanje št. transakcij,
pri katerih izvajamo teste in na koncu spremljamo, ali smo bili uspešni ali ne. Omenjeno
funkcionalnost podpirajo vsa orodja razen dveh (SOAPSonar in XmlSpy).
7.3.3 Testiranje zmogljivosti
Kot kaže tabela 3, samo štiri orodja podpirajo testiranje zmogljivosti, in sicer
SOAPSonar, GreenHat, itko LISA 4 SOA in TestMaker. V tabeli 4 je prikazana podrobna
primerjava orodij pri testiranju zmogljivosti. Vsa zgoraj našteta orodja omogočajo
določanje in spremljanje rezultatov pri testiranju. Prav tako lahko spremljamo porabo
omrežja pri orodju SOAPSonar in orodju itko LISA 4 SOA. Spominski modul (ang. RAM)
lahko spremljamo pri orodju SOAPSonar in GreenHat. Centralne procesorske enote (ang.
Primerjava orodij za testiranje spletnih storitev 56
CPU) pa lahko spremljamo samo pri orodju SOAPSonar in orodju JMeter. Poleg tega
lahko orodja pregledujejo povprečni čas, razen pri orodju itko LISA 4 SOA, kjer to ni
mogoče. Kot dve zelo pomembni možnosti pri tej vrsti testiranja bi izpostavili uporabo
navideznih uporabnikov, ki je mogoča le pri orodju SOAPSonar, in optimizacijo testnih
podatkov, ki je mogoča le pri orodjih itko LISA 4 SOA in TestMaker.
7.3.4 Regresijsko testiranje
Kot kaže tabela 3, le malo orodij podpira regresijsko testiranje, med te lahko štejemo
orodje GreenHat in orodje TestMaker. V tabeli 4 je prikazana podrobna primerjava orodij
pri regresijskem testiranju. Obe orodji (GreenHat in TestMaker) podpirata funkcionalnost
za določanje regresijskih kontrol. Orodje GreenHat omogoča tudi možnost ponovne
uporabe različnih testnih primerkov, medtem ko nudi orodje TestMaker snemanje sporočil,
testiranja itd. in ponovno predvajanje le-teh.
7.3.5 Testiranje varnosti
Kot kaže tabela 3, vsa orodja podpirajo testiranje varnosti, kar je v današnjem času zelo
pomembna stvar, če že ne nujna. V tabeli 4 je prikazana podrobna primerjava orodij pri
testiranju varnosti. Zaščita z uporabniškim imenom in geslom je dokaj pogosta metoda.
Samo orodje Parasoft SOAtest ne podpira zaščite z geslom, medtem ko zaščite z
uporabniškim imenom ne podpirajo orodja GreenHat, itko LISA 4 SOA, JMeter in
TestMaker. Pregledujemo lahko tudi certifikate, na žalost pa to možnost ponujajo samo
orodja GreenHat, itko LISA 4 SOA in SoapUI. Zelo pomembna stvar je tudi testiranje
mehanizmov, ki jih uporablja standard WS-varnost, mišljeno kot pregled
podpisa/preverjanja in pregled šifriranja/dešifriranja. Pri podpisu/preverjanju vidimo, da
samo orodji GreenHat in XmlSpy tega ne podpirata, medtem ko šifriranja/dešifriranja ne
podpirata orodji TestMaker in XmlSpy.
Primerjava orodij za testiranje spletnih storitev 57
7.3.6 Možnost validiranja
Kot kaže tabela 3, samo orodje JMeter ne podpira možnosti validiranja. V tabeli 4 je
prikazana podrobna primerjava orodij pri validiranju oz. uveljavitvi. Vsa orodja podpirajo
validiranje pri pošiljanju in sprejemanju sporočil in prav tako skoraj vsa orodja podpirajo
pregledovanje sporočil SOAP, le JMeter je izjema. Naslednja pomembna stvar je možnost
validiranja zahtev in odzivov pri pošiljanju in sprejemanju, zato tudi večina orodij to
podpira, le orodja GreenHat, Parasoft SOAtest in TestMaker ne. Pri validiranju je
pomembno tudi, da orodja podpirajo validiranje različnih tipov dokumentov, predvsem sta
tukaj najbolj pomembna WSDL in XML. Validiranje dokumenta WSDL ni mogoče samo
pri orodju JMeter, medtem ko validiranje XML omogočajo samo orodja SOAPSonar,
Parasoft SOAtest, SoapUI in XmlSpy. Omenimo razhroščevanje, ki je najbolj koristno pri
iskanju napak, vendar to možnost nudijo samo orodja itko LISA 4 SOA, XmlSpy in
TestMaker.
7.3.7 Podpora razli čnim protokolom
Kot kaže tabela 3, vsa orodja vsebujejo podporo različnim protokolom. Katera orodja
podpirajo kateri protokol, lahko vidimo v tabeli 4, ki prikazuje podrobno primerjavo
podprtih protokolov. Vsa orodja podpirajo protokol HTTP in SOAP, kar je za takšna
orodja popolnoma razumljivo in nujno. Glede varnosti je pomembno, da uporabljamo t. i.
varne protokole – protokole HTTPS, SSL in Kerberos. Protokol HTTPS podpirajo orodja
Parasoft SOAtest, GreenHat in TestMaker, medtem ko protokol SSL podpirajo orodja
GreenHat, SOAPSonar in SoapUI. Malo manj znan protokol Kerberos podpira samo
orodje SOAPSonar. Le orodji JMeter in TestMaker nudita uporabo POP3 in IMAP
protokolov.
Primerjava orodij za testiranje spletnih storitev 58
7.3.8 Poročanje o rezultatih
Kot kaže tabela 3, vsa orodja podpirajo poročanje o rezultatih. V tabeli 4 so prikazani
načini poročanja o rezultatih in podrobna primerjava orodij. Iz nje je razvidno, da vsa
orodja podpirajo grafični prikaz bodisi rezultatov tabel bodisi diagramov, prav tako vsa
orodja podpirajo prikaz rezultatov v obliki html. Velika večina orodij (SOAPSonar,
GreenHat, Parasoft SOAtest, SoapUI, JMeter, XmlSpy) omogoča poročanje o rezultatih v
obliki XML. Statistiko beleženja je mogoče spremljati pri orodjih SOAPSonar, GreenHat,
SoapUI in TestMaker.
7.3.9 Podpora (dokumentov, baz, itd.)
Kot kaže tabela 3, vsa orodja podpirajo različne dokumente, podatkovne baze itd.
Tabela 4 prikazuje podroben prikaz teh podpor. Iz nje je razvidno, da skoraj vsa orodja
podpirajo URI, le JMeter ne. URI je v bistvu URL naslov, v katerega vpišemo naslov do
naše datoteke WSDL. Vidimo lahko tudi, da vsa orodja podpirajo dokumente WSDL, le
orodji SOAP Sonar in JMeter ne podpirata datotek XML. Prav tako orodje XmlSpy
podpira vse datoteke oblike XSD, DTD, xPath. Zanimivo je tudi, da lahko nekatera orodja
(GreenHat, SOAPSonar, SoapUI, JMeter) povežemo z različnimi podatkovnimi bazami
(Oracle, SQL Server itd.)
7.4 Uporabniške zna čilnosti orodij
Tabela 5 prikazuje uporabniške značilnosti orodij, ki so razdeljene so na dva dela. Prvi del
prikazuje uporabnost dokumentacije oz. opis orodja, drugi del prikazuje uporabnost
posameznega orodja na različnih primerih uporabe. Tudi posamezne ocene od 1 do 3
temeljijo na uporabi teh orodij bodisi pri testiranju ali primerjanju orodij. Posamezni
pomen ocen je opisan pod tabelo.
Tabela 5: Uporabniške značilnosti orodij
Orodje
Dokumentacija oz. opis produktov
Uporabnost produkta
kakovost pomoči
preko spleta
kakovost pomoči
primeri, vodiči
dokumentacija o orodju
prijaznost orodja
dostopnost do orodja
zahtevnost namestitve
orodja SOAP Sonar
3 3 3 3 3 2*
GreenHat
1 2 1 2 1 2*
Parasoft SOAtest
3 3 2 3 2 2*
itko Lisa 4 SOA
3 3 3 2 1 2*
SoapUI
2 2 3 2 2 2*
JMeter
1 1 1 1 3 3*
TestMaker
2 3 3 1 3 1*
XmlSpy
3 2 2 3 3 3*
• Ocena »1« označuje slabo podporo, ocena »2« označuje srednjo podporo in ocena
»3« odlično podporo.
• Ocena »1*« označuje težko namestitev, ocena »2*« označuje srednje težko
namestitev in ocena »3*« lahko namestitev.
Primerjava orodij za testiranje spletnih storitev
7.4.1 Uporabniška analiza orodij V tabeli 5 skušamo prikazati uporabniške značilnosti orodij in njihove ocene na podlagi
testiranja, primerjanja, preučevanja orodij. Tabela je razdeljena na dokumentacijo oz. opis
proizvoda in uporabnost proizvoda.
Dokumentacija oz. opis proizvoda je razdeljena na tri podskupine, in sicer na kakovost
pomoči preko spleta, kjer vidimo, da sta orodji GreenHat in JMeter najslabše ocenjeni.
Poleg tega smo ocenjevali še kakovost pomoči s pomočjo primerov, vodičev itd., kjer so v
ospredju orodja SOAPSonar, Parasoft SOAtest, itko LISA 4 SOA in TestMaker z
najvišjimi ocenami. Ocenjevali smo tudi dokumentacijo o orodju, kjer so najbolje ocenjena
orodja SOAPSonar, itko LISA 4 SOA in TestMaker. Če pogledamo vse tri podskupine,
ugotovimo, da imata orodji SOAPSonar in itko LISA 4 SOA najboljše ocene, medtem ko
ima JMeter najslabše.
Tudi uporabnost orodja je razdeljena v tri podskupine, in sicer na prijaznost orodja,
dostopnost do orodja in zahtevnost namestitve orodja. Najslabše ocene glede prijaznosti
orodja do uporabnika sta dobili orodji JMeter in TestMaker. Najboljše ocene pri
dostopnosti do orodja so dobila orodja SOAPSonar, JMeter, TestMaker in XmlSpy. Kot
zadnje omenimo, da najlažjo namestitev orodja omogočata orodji JMeter in XmlSpy. Če
pogledamo vse tri podskupine, ugotovimo, da je najbolje ocenjeno orodje XmlSpy.
Primerjava orodij za testiranje spletnih storitev
60
Primerjava orodij za testiranje spletnih storitev 61
8 SKLEP
V diplomski nalogi smo proučili različna orodja za testiranje spletnih storitev. Tako
smo skozi celotno diplomsko nalogo podrobno predstavili več segmentov, kot so testiranje,
testiranje programske opreme, spletne storitve, testiranje spletnih storitev in primerjava
različnih orodij za testiranje spletnih storitev. Kot pomembno dejstvo nam služi spoznanje,
da se testiranje programske opreme in testiranje spletnih storitev bistveno ne razlikujeta.
Osredotočili smo se predvsem na podporo orodij določenim karakteristikam, kot so
omogočanje funkcionalnega testiranja, obremenitvenega testiranja, testiranja zmogljivosti,
regresijskega testiranja in testiranja varnosti. Vse te vrste testiranja smo spoznali in opisali
skozi celotno diplomsko nalogo. S pridobljenim znanjem smo se lotili testiranja in
primerjave orodij.
Pred primerjavo in testiranjem orodij smo morali najti nekaj najprimernejših orodij, s
katerimi bi lahko testirali spletne storitve. V ta namen smo poiskali čim več orodij,
definiranih kot orodja za testiranje spletnih storitev. Na tem mestu bi želeli izpostaviti, da
smo imeli težave pri pridobitvi nekaterih proizvodov ter njihove dokumentacije. Vendar
smo z vztrajnostjo le prepričali odgovorne, da so nam dovolili uporabiti njihovo orodje, pa
čeprav le za nekaj dni.
Po pregledu in preučevanju orodij, ki so bila dostopna, smo se odločili za osem orodij.
To so: SOAP Sonar, GreenHat, Parasoft SOAtest, itko LISA 4 SOA, SoapUI, JMeter,
TestMaker in XmlSpy. Večina orodij je na področju testiranja spletnih storitev zelo znana
in spada v sam vrh orodij, namenjenim testiranju spletnih storitev. Izbrana orodja smo
testirali in primerjali med seboj tako, da smo izdelali lastno spletno storitev, ki je
implementirala funkcionalnost računala. Izbrana orodja smo obravnavali na enak način.
Glavna naloga je bila primerjati orodja med sabo in na koncu najti najprimernejše. Ker
je določevanje najprimernejšega orodja težko, je treba poudariti, da je izbira orodja odvisna
od same naloge testiranja. Iz izdelanih tabel lahko vidimo, da nekatera orodja podpirajo
določene karakteristike testiranja, nekatera pa ne. Prav zaradi tega je pomembno, da
natančno vemo, kaj bomo testirali in kakšne karakteristike naj orodje podpira. Šele tedaj se
lahko odločimo, katero orodje za testiranje spletnih storitev bo za nas najprimernejše. Pri
Primerjava orodij za testiranje spletnih storitev 62
pregledu vseh orodij kot pri testiranju in primerjanju le-teh smo se odločili, da je
najprimernejše orodje Parasoft SOAtest. Na odločitev je vplivalo več vidikov, tako
uporabniški vidik orodja kot tudi funkcionalnosti, ki jih to orodje podpira. S tem orodjem
smo bili najbolj zadovoljni, saj je zadovoljilo vse naše potrebe. Omenimo tudi, da so bila
tudi druga orodja zelo dobra, vendar se pri naših nalogah niso tako dobro odrezala.
Za nadaljevanje tega dela bi bilo treba razširiti funkcionalnosti izdelane spletne
storitve, kar bi le-to naredilo bolj kompleksno. S tem, ko bi izvajali testiranje na bolj
kompleksni spletni storitvi, bi lahko podali boljšo oceno o izbiri orodja za testiranje
spletnih storitev, ki bi bila uporabna tudi za širšo množico uporabnikov, predvsem za
podjetja.
Primerjava orodij za testiranje spletnih storitev 63
9 VIRI IN LITERATURA [1] Standard ANSI/IEEE Std 792-1983 - http://standards.ieee.org/ (zadnji obisk: december 2007) [2] Computer history - http://www.computerhope.com/history/1900.htm (zadnji obisk: december 2007) [3] Testing - http://searchwindevelopment.techtarget.com/sDefinition/ 0,,sid8_gci534970,00.html (zadnji obisk: december 2007) [4] Benchmark - http://searchcio-midmarket.techtarget.com/sDefinition/ 0,,sid183_gci211650,00.html (zadnji obisk: december 2007) [5] Tomaž Dogša - Verifikacija in validacija programske opreme,Univerza v Mariboru, Tehniška fakulteta, Maribor, 1993 [6] Niles Parekh - Software Testing-White Box Testing Strategy - http://www.buzzle.com/editorials/4-10-2005-68350.asp (zadnji obisk: december 2007) [7] Black box testing - http://www.testingbrain.com/BLACKBOX/ BLACK_BOX_Testing.html (zadnji obisk: december 2007) [8] Grey box testing - http://www.robdavispe.com/free2/software-qa-testing-test-tester-2210.html (zadnji obisk: december 2007) [9] Juvenal - Wikipedia, the free encyclopedia - http://en.wikipedia.org/wiki/ Quis_custodiet_ipsos_custodes%3F (zadnji obisk: december 2007) [10] Adison Wesley - Software Testing in the Real World (2000) (zadnji obisk: december 2007) [11] ISO 9126 - http://www.issco.unige.ch/ewg95/node1.html (zadnji obisk: december 2007) [12] ISO 9126 - http://www.angelfire.com/nt2/softwarequality/ISO9126.pdf (zadnji obisk: december 2007) [13] API - Wikipedia, the free encyclopedia - http://en.wikipedia.org/wiki/ Application_programming_interface (zadnji obisk: december 2007) [14] John Sullivan - Client/Server - http://searchnetworking.techtarget.com/sDefinition/ 0,,sid7_gci211796,00.html (zadnji obisk: december 2007)
Primerjava orodij za testiranje spletnih storitev 64
[15] Server - http://whatis.techtarget.com/definition/0,,sid9_gci212964,00.html (zadnji obisk: december 2007) [16] W3C – Xml - http://www.w3.org/TR/REC-xml/ (zadnji obisk: december 2007) [17] W3C –Soap - http://www.w3.org/TR/soap/ (zadnji obisk: december 2007) [18] W3C - What's New in SOAP 1.2 - http://www.idealliance.org/papers/xmle02/ dx_xmle02/papers/02-02-07/02-02-07.html (zadnji obisk: december 2007) [19] W3C – Wsdl – http://www.w3.org/TR/wsdl (zadnji obisk: december 2007) [20] Wendy Boswell – Http & https - http://websearch.about.com/od/dailywebsearchtips/ qt/dnt0513.htm (zadnji obisk: december 2007) [21] Appy Now – SMTP – http://ruby.about.com/od/programmingglossary/g/smtp.htm (zadnji obisk: december 2007) [22] Xmpp – http://searchdomino.techtarget.com/sDefinition/0,,sid4_gci935535,00.html (zadnji obisk: december 2007) [23] W3C – Wsdl 2.0 – http://www.w3.org/TR/wsdl20/ (zadnji obisk: december 2007) [24] Luc Clement, Andrew Hately, Tony Rogers - UDDI -http://www.uddi.org/pubs/ uddi_v3.htm (zadnji obisk: december 2007) [25] WS-Securty - Wikipedia, the free encyclopedia - http://en.wikipedia.org/wiki/WS-Security (zadnji obisk: december 2007) [26] WS-Reliability - Wikipedia, the free encyclopedia - http://en.wikipedia.org/wiki/WS-Reliability (zadnji obisk: december 2007) [27] WS-Transaction - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/WS-Transaction (zadnji obisk: december 2007) [28] SOA - http://www.techweb.com/encyclopedia/defineterm.jhtml?term=SOA (zadnji obisk: december 2007) [29] Brian Connell – SOA Definition - http://searchsoa.techtarget.com/sDefinition/ 0,,sid26_gci929153,00.html (zadnji obisk: december 2007) [30] Thomas Ert - SOA, WSDL, SOAP and UDDI – http://www.informit.com/articles/ article.aspx?p=336265&seqNum=1&rl=1 (zadnji obisk: december 2007) [31] Paul Krill – Make way for SOA 2.0 – http://www.infoworld.com/article/06/05/17/ 78420_HNsoa20_1.html (zadnji obisk: december 2007)
Primerjava orodij za testiranje spletnih storitev 65
[32] EDA - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/ Event_Driven_Architecture (zadnji obisk: december 2007) [33] What is REST ? – http://rest.blueoxen.net/cgi-bin/wiki.pl?WhatIsREST (zadnji obisk: december 2007) [34] Roy Thomas Fielding – REST – http://www.ics.uci.edu/~fielding/pubs/ dissertation/ rest_arch_style.htm (zadnji obisk: december 2007) [35] Dion Hinchclife – The SOA with reach: Web-Oriented Architecture - http://blogs.zdnet.com/Hinchcliffe/?p=27 (zadnji obisk: december 2007) [36] Adam Kolawa – Testing Web Services – http://soa.sys-con.com/read/43574.htm (zadnji obisk: december 2007) [37] Jim Clune, Luke Chen – Testing Web Services – http://websphere.sys-con.com/ read/ 43273.htm (zadnji obisk: december 2007) [38] Sergei Baranov – Performence Testin Web Services – http://websphere.sys-con.com/ read/46513.htm (zadnji obisk: december 2007) [39] Intranet – Wikipedia, the free encyclopedia – http://en.wikipedia.org/wiki/Intranet (zadnji obisk: december 2007) [40] Web - Wikipedia, the free encyclopedia – http://en.wikipedia.org/wiki/Web (zadnji obisk: december 2007) [41] Damian V. Rinaldi – Testing & QA in the Web Services World – http://www.softwaremag.com/L.cfm?Doc=2005-09/2005-09testing (zadnji obisk: december 2007) [42] Jason Bloomberg – Web Services testing : Beyond SOAP – http://searchsoa.techtarget.com/originalContent/0,289142,sid26_gci846941,00.html (zadnji obisk: december 2007) [43] Rizwan Mallal and Mamoon Yunus – SOA Testing using Black, White and Gray Box Techniques – http://www.softwaremag.com/L.cfm?Doc=958-6/2006 (zadnji obisk: december 2007) [44] ISO/IEC 9126 - http://www.torsten-horn.de/techdocs/sw-dev-process.htm (zadnji obisk: december 2007) [45] Evaluation of Quality - http://www.ercim.org/publication/Ercim_News/enw28/ fabbrini.html (zadnji obisk: december 2007) [46] Web Services Activity: History - http://www.w3.org/2002/ws/history.html (zadnji obisk: december 2007)
Primerjava orodij za testiranje spletnih storitev 66
[47] Architecture Web Services - http://help.sap.com/saphelp_nw04s/helpdata/en/42/ 5f934249c30c31e10000000a1550b0/content.htm (zadnji obisk: december 2007) [48] SOA Architecture – http://www.dnzone.com/showDetail.asp?TypeId=2&NewsId=113 (zadnji obisk: december 2007) [49] Representational State Transfer - http://www.ics.uci.edu/~fielding/pubs/dissertation/
rest_arch_style.htm (zadnji obisk: december 2007)
[50] Dion Hinchcliffe – The SOA with reach: Web-Oriented Architecture -
http://blogs.zdnet.com/Hinchcliffe/?p=27 (zadnji obisk: december 2007)
[51] Testing Tools Are Key To Web Services' Success – http://www.informationweek.com/ software/showArticle.jhtml?articleID=6502927&pgno=3&queryText= (zadnji obisk: december 2007) [52] SOAPSonar - http://www.crosschecknet.com (zadnji obisk: februar 2007)
[53] GreenHat – http://www.greenhatsoftware.com (zadnji obisk: februar 2007)
[54] Parasoft SOAtest – http://www.parasoft.com (zadnji obisk: februar 2007)
[55] itko Lisa 4 SOA – http://www.itko.com (zadnji obisk: februar 2007)
[56] SoapUI – http://www.soapui.org (zadnji obisk: februar 2007)
[57] JMeter – http://jakarta.apache.org/jmeter/index.html (zadnji obisk: februar 2007)
[58] TestMaker (PushToTest) – http://www.pushtotest.com (zadnji obisk: februar 2007)
[59] Altova XmlSpy – http://www.altova.com/ (zadnji obisk: februar 2007)
[60] 10 rules - http://www.softwaretestinghelp.com/remember-software-testing-10-rules/ (zadnji obisk: december 2007)
[61] Juan Luo, Offutt - Difference - http://ieeexplore.ieee.org/Xplore/login.jsp?url= /iel5/10370/32973/01544740.pdf?arnumber=1544740 (zadnji obisk: december 2007)
[62] Pushtotest - http://www.pushtotest.com/Docs/downloads/features.html (zadnji obisk: december 2007)
Primerjava orodij za testiranje spletnih storitev 67
[63] Luc Clement, IBM Claus von Riegen, SAP AG Tony Rogers, Computer Associates – UDDI Spec TC - http://www.uddi.org/pubs/uddi_v3.htm (zadnji obisk: december 2007) [64] Laurie Williams (2006) - Testing Overview http://agile.csc.ncsu.edu/ Sematerials/ BlackBox.pdf (zadnji obisk: december 2007) [65] Arulazi Dhesiaseelan - What's New in WSDL 2.0 - www.xml.com/pub/a/ws /2006/05/19/wsdl2.html (zadnji obisk: december 2007) [66] Tom BellWood (IBM) – Understanding UDDI - http://www.ibm.com
/developerworks/library/ws-featuddi/ (zadnji obisk: december 2007)
[67] M. B. Juric, B. Mathew, P. Sarang, Business Process Execution Language for Web Services, 2nd Edition, Packt Publishing, Birmingham, UK, 2006 (zadnji obisk: december 2007) [68] URI - Wikipedia, the free encyclopedia - http://en.wikipedia.org/wiki/
Uniform_Resource_Identifier (zadnji obisk: december 2007)
Primerjava orodij za testiranje spletnih storitev 68
PRILOGE
- CD zgoščenka (Diplomska naloga.pdf, testna orodja s primeri testiranja)
- Izjava o lektoriranju diplomske naloge
- Kopija o pridobljeni univerzitetni izobrazbi lektorice