Download pdf - PRIMERJAVA ORODIJ ZA TESTIRANJE SPLETNIH STORITEV

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.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.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


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.


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].


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].


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.


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.


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]


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)


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].


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


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]


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.


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].


� 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].


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.


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]


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].


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].


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).


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]


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].


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].


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]


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].


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]


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


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.


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.


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]


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]


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.


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.


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


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,


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.


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].


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.


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.


� 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.


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.


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


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]


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.


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.


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).


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.


- 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.


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.


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.


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]


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


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


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.


54


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.


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.


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.


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.


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.


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.


60


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


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.


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)


[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)


[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)


[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)


[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)


PRILOGE

- CD zgoščenka (Diplomska naloga.pdf, testna orodja s primeri testiranja)

- Izjava o lektoriranju diplomske naloge

- Kopija o pridobljeni univerzitetni izobrazbi lektorice