PREIZKUŠANJE PROGRAMSKE OPREME Z UPORABO TESTNE ... · bomo tudi izseke iz dokumentacije, ki je pri takšnem testiranju nastala. Na koncu tega poglavja bomo analizirali učinkovitost

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Rok Leš

PREIZKUŠANJE PROGRAMSKE OPREME Z

UPORABO TESTNE METODOLOGIJE STEP

Diplomska naloga

Maribor, september 2008

I

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO 2000 Maribor, Smetanova ul. 17

Diplomska naloga visokošolskega strokovnega študijskega programa



Študent: Rok LEŠ

Študijski program: visokošolski strokovni, Računalništvo in informatika

Smer: Programska oprema

Mentor: izr. prof. dr. Božidar POTOČNIK

Maribor,september 2008

II

ZAHVALA

Zahvaljujem se mentorju dr. Boţidarju Potočniku

za pomoč in vodenje pri opravljanju diplomske

naloge. Prav tako se zahvaljujem vsem zaposlenim

v podjetju Comtron d.o.o., za sodelovanje in

pomoč pri projektu.

Posebna zahvala velja moji druţini, ki me je

spremljala ob študiju in mi nudila moralno

podporo.

III



Ključne besede: testna metodologija STEP, razvoj programske opreme, načrtovanje,

dokumentiranje, preizkušanje, izpisovanje dokumentov

UDK: 004.41.05(043.2)

Povzetek

Programske napake se bodo zaradi zahtevnosti razvoja programske opreme vedno

pojavljale. Za zmanjšanje števila teh napak je potrebno programsko opremo temeljito

preizkusiti. Včasih se je testiranje izvajalo le ob koncu razvoja produkta, danes pa

poznamo t.i. preventivno testiranje, ki skuša odkriti napake že v zgodnjih fazah ter tako

zmanjšati stroške projekta. Takšen pristop predpostavlja tudi metodologija STEP.

V tem diplomskem delu smo ugotavljali, zakaj se preventivno preizkušanje v praksi ne

uporablja prav pogosto. Najprej smo preučili testno metodologijo STEP, ki smo jo nato

uporabili v praksi za razvoj poslovnega programskega sistema, in sicer tako, da smo

vzporedno razvijali in testirali aplikacijo za tvorjenje poročil oziroma izpisov. Izkazalo se

je, da je takšen postopek razvoja in preizkušanja relativno zahteven tudi pri dokaj

preprosti aplikaciji. Ugotovili smo, da preventivno preizkušanje zahteva veliko vloženega

truda. V tem projektu je nastalo 82 strani dokumentacije, naš vložek pri preizkušanju pa je

bil 162 ur. Pri razvoju produkta je sicer sodelovalo še 5 oseb iz podjetja Comtron d.o.o.,

pri testu sprejemljivosti pa še trije končni uporabniki.

Med izvajanjem teh aktivnosti smo se soočili tudi s problemom neizkušenosti osebja pri

testiranju in zmotnem prepričanju podjetij o preveliki porabi časa za testne aktivnosti.

Navzlic tem problemom in na osnovi izračunanih standardnih metrik za oceno

učinkovitosti testiranja ocenjujemo, da smo z uporabo testne metodologije STEP razvili

veliko kakovostnejši programski produkt, kot bi ga sicer.

IV

SOFTWARE TESTING BY USING “STEP”

TESTING METHODOLOGY

Key words: STEP testing methodology, software development, planning, documentation,

testing, documents printing

UDK: 004.41.05(043.2)

Abstract

There will always appear software errors because of pretentiousness software

development. The software should be thoroughly tested in order to reduce an amount of

these errors. Formerly, the testing was performed at the end of products’ development;

however, a preventing testing has become one of the widely acknowledged practices today

that tries to reduce project expenses by detecting errors in early development phases. Such

approach supposes also the STEP methodology.

In this diploma, we asses the reasons for seldom use of preventive testing in the

practice. Firstly, we studied the STEP testing methodology that was later used in practice

for a new business software system development. We simultaneously developed and tested

this application for creating reports or excerpts, respectively. It pointed out that such

development and testing is relatively complex even by simple application. We found out

that the preventive testing requires a big amount of our effort. We dedicated 162 hours to

the testing and produced 82 pages of documentation. It should be stressed that at this

software development another five employees from Comtron d.o.o. company were

participated, while at the acceptance test yet three end-users were included.

During project activities we were confronted with a problem of staff inexperience by

testing and mistaken persuasion of companies about too big time consumption for testing

activities. Despite these problems, and based on the calculated standard metrics for an

estimation of testing efficiency, we estimate that by using STEP testing methodology a

more quality software was developed as it would be developed otherwise.

V

VSEBINA

1 UVOD 1

2 METODOLOGIJA STEP 4

2.1 PODROČJE IN CILJI 4 2.2 GRADNIKI 5 2.3 ARHITEKTURA 5 2.4 ČASOVNI POTEK AKTIVNOSTI 7 2.5 KLJUČNI PRODUKTI V POSAMEZNI FAZI 8 2.6 VLOGE IN ODGOVORNOSTI 8 2.7 PLANIRANJE SPLOŠNEGA NAČRTA 9

2.7.1 Nivoji planiranja 9 2.7.2 Analiza ciljne publike 11 2.7.3 Časovni potek 11 2.7.4 Standardne predloge 12

2.8 PLANIRANJE PODROBNEGA NAČRTA 12 2.8.1 Test sprejemljivosti 14 2.8.2 Sistemski test 17 2.8.3 Integracijski test 18 2.8.4 Test enot 20

2.9 DOLOČITEV TESTNIH CILJEV IN PRIPRAVLJANJE PREIZKUSOV 21 2.10 UVAJANJE PREIZKUSOV 24

2.10.1 Testno okolje 24 2.10.2 Avtomatizacija testov 26

2.11 IZVAJANJE PREIZKUSOV 27 2.12 ZAKLJUČEK PREVERJANJA 30 2.13 OCENA UČINKOVITOSTI TESTIRANJA 32

3 APLIKACIJA, NAMENJENA ZA IZPISOVANJE DOKUMENTOV 36

3.1 ODJEMALEC 36 3.2 STREŢNIK 39

4 OPIS PREIZKUŠANJA 44

4.1 KRONOLOŠKI PREGLED AKTIVNOSTI 44 4.2 DOKUMENT SPECIFIKACIJE ZAHTEV PROGRAMSKE OPREME (SZPO) 45 4.3 GLAVNI TESTNI NAČRT (GTN) 46 4.4 PODROBNI TESTNI NAČRTI 49 4.5 IZVAJANJE PREIZKUŠANJA 49

4.5.1 Testni primeri za test enot 50 4.5.2 Testni primeri za integracijski test 55 4.5.3 Testni primeri za sistemski test 57 4.5.4 Testni primeri za test sprejemljivosti 59 4.5.5 Dnevnik testiranja 59 4.5.6 Dokument s povzetkom testiranja 61 4.5.7 Ugotovitve 65

5 ZAKLJUČEK 67

VIRI, LITERATURA 69

VI

KAZALO SLIK

Slika 1: Različni pogledi na testiranje.................................................................................1

Slika 2: Ţivljenjski cikel programske opreme – model slap. ...............................................2

Slika 3: Časovni potek aktivnosti na posameznem nivoju testiranja. ...................................6

Slika 4: Časovni potek na različnih nivojih testiranja. ........................................................7

Slika 5: Primerjava razvoja programske in testne opreme. ..................................................8

Slika 6: Stopnje načrtovanja testov. .................................................................................. 10

Slika 7: Časovni potek planiranja testnih načrtov. ............................................................ 11

Slika 8: Integracijski test. ................................................................................................. 19

Slika 9: Matrika testnih ciljev. .......................................................................................... 23

Slika 10: Vhodi in izhodi v izvajanje testov. ..................................................................... 28

Slika 11: Kriterij odkrivanja novih napak. ........................................................................ 31

Slika 12: Glavno okno odjemalca. .................................................................................... 37

Slika 13: Pregledovalnik izpisov na osnovi komponente ActiveX. ................................... 38

Slika 14: Moţni izvozi izpisa. .......................................................................................... 38

Slika 15: Izvorna koda za prirejanje parametrov izpisu. .................................................... 40

Slika 16: Primer datoteke XML s prevodi. ....................................................................... 41

Slika 17: Izsek izvorne kode za prevajanje izpisov. .......................................................... 41

Slika 18: Izsek izvorne kode za izvoz izpisov. .................................................................. 43

VII

UPORABLJENE KRATICE

STEP - angl. Systematic Test and Evaluation Process

IEEE - angl. Institute of Electrical and Electronics Engineers

GTN - glavni testni načrt

TIC - programski produkt Tron inter center

VB6 - Visual basic 6

URL - angl. Uniform Resource Locator

SZPO - dokument Specifikacije zahtev programske opreme

COM - angl. Component Object Model

ASP - angl. Active Server Pages

PDF - angl. Portable Document Format

IE - angl. Internet explorer

Rok Leš, Diplomsko delo

1

1 UVOD

Napake v programski opremi se bodo vedno pojavljale. Pa ne zato, ker bi bili programerji

neodgovorni ali brezbriţni, ampak zaradi tega, ker je razvijanje programske opreme zelo

zahteven postopek. Potrebno se je tudi zavedati, da imamo ljudje omejene zmoţnosti za

obvladovanje aktivnosti pri načrtovanju in razvoju programske opreme.

Skozi zgodovino razvoja programske opreme so se pojavile različne definicije

testiranja (glej sliko 1). Tako je leta 1979 Glenford Myers opredelil, da je testiranje proces

izvajanja programa, kjer je glavni cilj odkrivanje napak. Testiranje se je torej izvajalo na

koncu razvoja, ko je bil produkt ţe izdelan. Nekaj let pozneje, tj. leta 1983, je Bill Hetzel

definiral testiranje kot kakršnokoli aktivnost, s katero ovrednotimo atribute ali lastnosti

programov, hkrati pa z njim opredelimo ali ustreza zahtevanim rezultatom. Testiranje je

tudi merjenje kvalitete proizvoda. Te definicije veljajo še danes. Sodobni pogled na

testiranje vidi to aktivnost kot proces, ki se dogaja vzporedno z ţivljenjskim ciklom

razvoja programske opreme. Testiranje ima torej iste faze kot razvoj, in sicer:

analizo (izberemo cilje in zahteve testiranja),

načrtovanje (določitev metode za testiranje),

uvajanje (implementacija testnih procedur) in

vzdrţevanje (sprememba testnih procedur, če se spremeni programska oprema).

Osnovni motiv testiranja je torej preventiva. Ideja je v tem, da lahko izboljšamo kvaliteto

programske opreme, če se testiranje začne dovolj zgodaj v ţivljenjskem ciklu razvoja.

Slika 1: Različni pogledi na testiranje.

Kljub temu, da preventivno testiranje vsekakor ni nova ideja, pa le-to v praksi ni prav

pogosto uporabljeno. Večina podjetij uporablja pri razvoju t.i. zaporedne modele, pri

katerih si faze ţivljenjskega cikla sledijo ena za drugo. Najprej določimo zahteve, zatem


2

načrt, sledi kodiranje in šele na koncu pride na vrsto testiranje. Najbolj "popularen" takšen

model je model slapa model, ki je prikazan na sliki 2.

Slika 2: Ţivljenjski cikel programske opreme – model slap.

Ko končamo z razvojem ene faze, lahko gremo šele v naslednjo. Vrnitev nazaj za več kot

eno fazo sicer ni nemogoča, je pa zelo teţka. Takšno vračanje (npr. ponovno pisanje

dokumentacije, ponovno testiranje, ponovno pisanje zahtev) pa lahko pomeni zelo velik

strošek. Prav to poizkuša preprečiti preventivno testiranje, saj so stroški odprave napak ob

pravočasnem odkritju veliko manjši.

Leta 1986 sta dr. David Gelperin in William Hetzel razvila testno metodologijo

imenovano STEP (angl. Systematic Test and Evaluation Process). Ta metoda je

univerzalna, saj je razširila zgodnjo definicijo testiranja in tako podprla sodobne poglede

na testiranje.

Cilj te diplomske naloge je raziskati ter naštudirati metodo STEP in s pomočjo nje

prikazati testiranje programske opreme skozi celoten ţivljenjski cikel razvoja. Priporočila

metodologije STEP bomo uporabili pri razvoju programskega produkta za tvorjenje

izpisov oziroma poročil. Ta rešitev je bila namensko razvita za podjetje Comtron d.o.o.

Produkt bomo zgradili na osnovi arhitekture streţnik-odjemalec. Na koncu bomo ocenili in

analizirali uspešnost preizkušanja, ter skušali ugotoviti, zakaj se metodologija STEP v


3

praksi ne uporablja prav pogosto. Naša motivacija je torej uporabiti odlično razvito teorijo

o preizkušanju programske opreme tudi v praksi in s pomočjo nje razviti kvaliteten

programski produkt.

Diplomsko delo je sestavljeno iz 5. poglavij. Po uvodu bomo v 2. poglavju podrobneje

predstavili testno metodologijo STEP. V nadaljevanju bomo v 3. poglavju na kratko opisali

delovanje streţnika in odjemalca, ki sta sestavna dela poslovne aplikacije za tvorjenje

izpisov oziroma poročil. V naslednjem poglavju bomo opisali postopek razvoja in

testiranja te aplikacije, pri čemer smo uporabili priporočila metodologije STEP. Ogledali si

bomo tudi izseke iz dokumentacije, ki je pri takšnem testiranju nastala. Na koncu tega

poglavja bomo analizirali učinkovitost testiranja, podali pa bomo tudi kvantitativne

rezultate. V zaključnem poglavju bomo strnili naše vtise in spoznanja pri preizkušanju

programske opreme z uporabo testne metodologije STEP. Pojasnili bomo dejavnike, ki

botrujejo temu, da se danes v praksi še vedno največ preizkuša neformalno (brez pisanja

ustrezne dokumentacije) in to le ob koncu razvoja programske opreme.


4

2 METODOLOGIJA STEP

Metodologija STEP je bila prvič pod tem imenom predstavljena leta 1985. Temelji na

naslednjih standardih IEEE (angl. Institute of Electrical and Electronics Engineers):

829-1983 (Standard for Software Test Documentation),

828-1998 (Standard for Software Configuration Management Plans),

1008-1987 (Standard for Software Unit Testing).

Ta metodologija je nastala zaradi tega, ker so ti standardi sicer dobro opisali, katere

dokumente za testiranje moramo ustvariti, vendar pa niso specificirali, kako jih naredimo

oziroma, kako vodimo procese (tj. analizo, načrtovanje, uvajanje itd.), pri katerih lahko

uporabimo te dokumente. Pozneje je bila ta metodologija še mnogokrat predelana. Ker

metodologija STEP temelji na standardih, je postala ena izmed vodilnih metod za

učinkovito testiranje programske opreme.

V tem poglavju si bomo najprej ogledali arhitekturo in časovni potek posameznih

aktivnosti metodologije STEP. Opisali bomo, kateri so ključni produkti, ki nastanejo pri

testiranju, ter kakšne vloge imajo posamezniki, ki sodelujejo v procesu. Spoznali bomo

tudi, kako določiti testne cilje in napisati glavne ter podrobne testne načrte. Na koncu

poglavja si bomo ogledali še postopek uvajanja in izvajanja preizkusov. Skušali bomo

odgovoriti tudi na vprašanja, kot so: kdaj zaključiti preizkušanje ter kako izmeriti

učinkovitost testiranja.

2.1 Področje in cilji

Metoda pokriva večino aktivnosti, ki so povezane z ovrednotenjem oziroma ocenjevanjem

programske opreme. Pod besedno zvezo ovrednotenje programske opreme mislimo

predvsem na tisti del razvoja opreme, ki je namenjen temu, da ocenimo ali naš produkt

resnično deluje v skladu z zahtevami, ali pa so med zahtevami in delovanjem kakšna

odstopanja.


5

2.2 Gradniki

Metodologija je sestavljena iz več individualnih aktivnosti, ključnih produktov (tj.

dokumentacije ter implementiranih testov), s katerimi se zaključi vsaka faza testiranja, ter

vlog, ki jih imajo udeleţenci v projektu. Vsi gradniki pa skupaj delujejo kot sistem, ki vodi

v razvoj kvalitetne programske opreme.

Metodologija STEP ne predpisuje orodij za testiranje, prav tako ne predvideva testnega

oddelka. Predpostavlja pa ustrezen vloţek pri razvoju testiranja, kjer vhodne podatke

predstavljajo zahteve programske opreme in tehnični načrt (angl. use-case). Če zahteve in

načrt programske opreme morebiti niso določeni, lahko kljub temu uporabimo del

metodologije STEP. S pomočjo le-te lahko hitro opravimo analizo ter dobimo specifikacije

za zahteve ter načrt programske opreme.

2.3 Arhitektura

Metodologija STEP predvideva, da je celoten proces testiranja razdeljen na posamezne

nivoje. Vsak nivo pa predstavlja različno testno okolje. Preprosti projekti so lahko

sestavljeni iz enega ali dveh nivojev (npr. testiranje enot in testiranje sprejemljivosti),

medtem ko lahko imajo kompleksni projekti tudi več nivojev (npr. test enot, test funkcij,

test podsistemov, test sistemov ter test sprejemljivosti).

Na sliki 3 vidimo, da metodologija STEP sestoji iz 3 glavnih faz, ki se izvedejo na

vsakem nivoju:

načrtovanje strategije – izberemo strategijo, določimo nivoje in pristop – tj.

zasnova,

zbiranje dodatnih podatkov – gre za določitev podrobnejših testnih ciljev,

planiranje in uvajanje preizkusov, in

meritev – izvajanje preizkusov in ovrednotenje programske opreme ter

procesov.


6

Slika 3: Časovni potek aktivnosti na posameznem nivoju testiranja.

Omenjene tri faze pa so razdeljene še v osem glavnih aktivnosti, kar prikazuje tabela 1.

Faza 1 Načrtovanje strategije

N1 Planiranje splošnega načrta

N2 Planiranje podrobnejšega načrta

Faza 2 Zbiranje dodatnih podatkov

Z1 Določitev testnih ciljev

Z2 Pripravljanje testov

Z3 Uvajanje testov

Faza 3 Meritev

M1 Izvajanje testov

M2 Zaključek preverjanja

M3 Urejevanje testnih rezultatov

Tabela 1: Faze in aktivnosti v metodologiji STEP.


7

2.4 Časovni potek aktivnosti

Metodologija STEP določa, kdaj se izvajajo posamezne aktivnosti, ter kaj se naj sploh

izvaja. Časovni potek določa, da preden nadaljujemo s podrobnim načrtovanjem

programske opreme, moramo končati načrt za testiranje. Testni načrt začnemo izdelovati,

ko so podane zunanje ali funkcionalne specifikacije za programsko opremo, ki jo ţelimo

testirati. Za testiranja na višjem nivoju (test sprejemljivosti in sistemski test) so zunanje

specifikacije enake dokumentu o sistemskih zahtevah. Ko je ta dokument na voljo pa lahko

začnemo načrtovati testiranje zahtev.

Med podrobnim načrtovanjem programske opreme se ustvari dokumentacija za

posamezne module oziroma funkcionalnosti. Ti dokumenti nam pomagajo, da začnemo z

načrtovanjem testov na niţjih nivojih. Ko se razvoj programske opreme premakne v fazo

implementacije, se aktivira tretja faza testiranja, ki temelji na informacijah o programski

kodi in podrobnostih implementacije. Cilj je torej dokončati mnoţico testov na vsakem

posameznem nivoju takoj, ko je le-to moţno. S takšnim pristopom odkrijemo napake v

najkrajšem moţnem času. Na sliki 4 vidimo časovni potek vzporednega razvoja projekta in

testiranja.

Slika 4: Časovni potek na različnih nivojih testiranja.


8

2.5 Ključni produkti v posamezni fazi

Metodologija STEP uporablja izraz testna programska oprema (angl. testware) za ključne

produkte v posamezni fazi. V to kategorijo spadajo testni načrti, testna dokumentacija,

implementirane testne procedure, testni primeri in testne datoteke. Testna programska

oprema je podobna programski, saj se oba procesa dogajata sočasno. Kakor pri razvoju

programske opreme določimo specifikacije, napišemo načrt in programsko opremo

implementiramo, opravimo iste korake tudi pri testni programski opremi (glej sliko 5).

Slika 5: Primerjava razvoja programske in testne opreme.

Oba procesa torej nudita podporo drug drugemu. Razvoj testne opreme se opira na ključne

produkte programske opreme ter skuša preprečiti napake le-te. Razvoj programske opreme

pa s pregledovanjem testne opreme skuša preprečiti napake slednje.

2.6 Vloge in odgovornosti

Glavne vloge v tej metodologiji imajo vodja, analitik, tehnik in ocenjevalec. Tabela 2

opisuje odgovornosti v tem procesu. Vodja preizkuševalcev je odgovoren za splošno

usmerjanje in koordiniranje testiranja ter za komunikacijo med sodelujočimi. Testni

analitik skrbi za podroben testni načrt, izdelavo podrobnih testnih ciljev, specifikacije

testnega načrta ter pregledovanje in ocenjevanje testov. Testni tehnik je odgovoren za

implementacijo testnih procedur glede na načrte, ki mu jih je pripravil analitik. Prav tako je


9

odgovoren za izvajanje preizkusov in primerjavo rezultatov z izhodnimi kriteriji ter za

dnevnik testiranja in poročanje o problemih. Pregledovalec pa je dolţan poskrbeti za

pregled vseh korakov testiranja in ključnih proizvodov v testnem procesu.

Vloga Opis odgovornosti

Vodja Komuniciranje, načrtovanje in koordiniranje.

Analitik Načrtovanje, določitev ciljev, planiranje in

ovrednotenje.

Tehnik Implementacija, izvedba in kontrola.

Ocenjevalec Pregledovanje in ovrednotenje.

Tabela 2: Vloge in odgovornosti posameznikov.

Metodologija STEP ne zahteva, da so v majhnih projektih te vloge v resnici razdeljene

med štiri različne osebe, ampak lahko vse vloge opravlja zgolj ena oseba. Pri velikih

projektih se vloge seveda porazdelijo. Pri tem se osebe specializirajo le za svoje področje.

2.7 Planiranje splošnega načrta

Planiranje testnega načrta je ključnega pomena za uspešno testiranje programske opreme.

Pogosto je omejeno bodisi zaradi časovne stiske ali pa preprosto zaradi pomanjkanja

znanja in izkušenj. Testiranje brez testnega načrta se lahko enači z razvojem programske

opreme brez razvojnega načrta. Do razvoja oziroma testiranja brez načrtov pride ponavadi

zaradi ţelje po čimprejšnjem kodiranju oziroma testiranju programske opreme, saj nekatera

podjetja merijo napredek razvoja produkta prav po številu napisanih vrstic kode ali pa s

številom pognanih testov.

2.7.1 Nivoji planiranja

Planiranje testnega načrta se lahko pojavi na več različnih nivojih. Prvi načrt, o katerem

moramo razmisliti, je glavni testni načrt (načrt GTN). To je lahko ločen dokument ali pa je

del projektnega načrta. Cilj načrta GTN je nadzorovanje testiranja na vseh nivojih.


10

Standard IEEE 829-1983 pozna naslednje nivoje testiranja:

testiranje enot,

integracijski test oziroma test povezljivosti,

sistemski test in

test sprejemljivosti.

Slika 6: Stopnje načrtovanja testov.

Načrt GTN mora vodji testiranja predstavljati eno izmed glavnih orodij za komuniciranje s

sodelujočimi v projektu. Namen tega načrta ni v dolgem seznamu testnih primerov, ampak

gre bolj za razrešitev pomembnih vprašanj o testni strategiji, odgovornosti posameznikov,

tveganjih, prioritetah, izkoriščanju virov, kaj ţelimo preizkušati itd. Čeprav je izdelava

samega dokumenta pomembna, je od nje še bolj pomemben proces izdelave in debatiranje

o prej naštetih vprašanjih.

Načrt GTN ima običajno še dopolnila v obliki podrobnejših načrtov, ki opisujejo

posamezen nivo (glej sliko 6). Pri večjih projektih je zato smiselno in koristno zapisati še

testne načrte za test sprejemljivosti, sistemski test, test integracije in enot. Za manjše

projekte zadostuje en testni načrt, ki pokriva vse nivoje testiranja. Določitev števila testnih

načrtov mora biti ena izmed prvih strateških odločitev pri planiranju testnih načrtov.


11

2.7.2 Analiza ciljne publike

Pri izdelavi testnega načrta se moramo najprej vprašati, kdo je naša ciljna publika, saj je

le-ta glede na testni načrt lahko zelo različna (npr. načrt testa sprejemljivost, načrt testa

enot, glavni načrt). Pri izdelavi načrta je zato treba biti pozoren na uporabljene tehnične

izraze in ţargon. Drugi problem pa je, da ima posamezna ciljna publika zelo različen

tolerančni nivo (npr. kakšno količino informacij/dokumentov ţeli in je zmoţna predelati).

Izogibati se torej moramo predolgim testnim načrtom, ki jih ne bi nihče prebral. Velike

dokumente je vsekakor bolje razdeliti na več manjših delov.

2.7.3 Časovni potek

Planiranje načrta GTN se mora začeti čim prej. Začnemo ga hkrati z določitvijo zahtev in

razvojem projektnega načrta. Na sliki 7 je prikazano, v kateri fazi projekta se začne in kako

dolgo traja načrtovanje testov na posameznem nivoju.

Slika 7: Časovni potek planiranja testnih načrtov.

Če se planiranje testnih načrtov začne dovolj zgodaj, bo to skoraj zagotovo vplivalo tudi na

vsebino projektnega načrta. Planiranje načrta za test sprejemljivosti se lahko prične hkrati z

začetkom procesa definiranja zahtev. Nekatere stranke celo vključijo test sprejemljivosti

kot zahtevo programske opreme.


12

Načrtovalci testov, ki začnejo s planiranjem dovolj zgodaj, so pogosto razočarani, saj

odkrijejo, da informacije, ki jih potrebujejo, še niso na voljo, ali pa so v fazi pridobivanja

le-teh. Izkušenejši so pri tem bolj odločni, saj običajno angaţirajo preostale sodelujoče, da

pridobijo manjkajoče informacije. Pogosto se tudi dogodi, da je potrebno spremeniti

zgodaj napisane testne načrte. Takšno spreminjanje je zelo dragoceno, saj z njimi testni

načrtovalci pridobivajo dragocene izkušnje, ki jih lahko uporabijo v naslednjih projektih.

2.7.4 Standardne predloge

Koristno je, da ima podjetje predpisano predlogo za izdelavo testnega načrta. V standardu

IEEE 829-1983 najdemo osnovo takšne predloge. V nekaterih projektih lahko ta predloga

popolnoma ustreza, nič pa ni narobe, če jo prilagodimo (npr. izbrišemo nepotrebna polja).

Če se izkaţe, da je pri vsakem projektu del dokumenta enak, lahko ta del prav tako

izbrišemo ter ga dodamo k naši standardni metodologiji. Ker se količina dokumentacije

med projekti razlikuje, lahko nekatere sekcije iz te predloge označimo za neobvezne.

Poleg standardnih dokumentov je potrebno definirati format spremljajoče

dokumentacije. Spremljajoča dokumentacija lahko npr. definira, kako prijaviti napako,

kako vstaviti in vzeti kodo iz streţnika, kako in kdaj shraniti testne primere, kako uporabiti

zgodovino testiranja ipd. Ključnega pomena pa je, da naredimo vse te postopke in

dokumentacijo čim preprostejšo.

2.8 Planiranje podrobnega načrta

V prejšnjem podpoglavju smo videli, da iz splošnih informacij izdelamo načrt GTN.

Podrobni načrt pa izdelamo na osnovi bolj specifičnih informacij o programski opremi.

Nivo predstavlja različno testno okolje, ki je sestavljeno iz različnih dejavnikov, kot so

ljudje, strojna oprema, odvisna programska oprema, vmesniki in izvor testnih podatkov. V

tabeli 3 so prikazani primeri takšnih dejavnikov, ki pa se lahko med posameznimi projekti

in podjetji zelo razlikujejo.


13

Dejavniki Nivo

Enote Integracija Sistem Sprejemljivost

Ljudje Razvijalci Razvijalci in

preizkuševalci

Preizkuševalci Preizkuševalci

in uporabniki

Strojna

oprema

Delovno

okolje

programerja

Delovno okolje

programerja

Računalnik ali

področje za

sistemsko testiranje

Ista kot v

produkciji

Odvisna

programska

oprema

Brez Brez Brez / dejanska Dejanska

Vmesniki Brez Interni Simuliran in

resničen

Simuliran in

resničen

Izvor testnih

podatkov

Ročno

ustvarjeni

Ročno

ustvarjeni

Produkcijski in

ročno ustvarjeni

Produkcijski

Količina

testnih

podatkov

Malo Malo Veliko Veliko

Strategija Enot Skupine enot Celoten sistem Simulacija

produkcije

Tabela 3: Primeri dejavnikov v posameznem testnem okolju.

Zelo pomembno je tudi, da pravilno določimo število nivojev. Ponavadi je to odvisno od

kompleksnosti projekta, sistema, števila unikatnih uporabnikov, finančne podpore projekta

ipd. O pravilnem številu nivojev odloča vodja preizkuševalcev, saj si ne smemo privoščiti,

da bi imeli prekrivajoče se nivoje oziroma, da bi bili med posameznimi nivoji preveliki

razmiki. Med različnimi projekti lahko najdemo tudi različna poimenovanja nivojev.

Predpogoj za planiranje testnega načrta za točno določen nivo je poznavanje

posameznih zahtev tega nivoja. Zelo dobro moramo pretehtati in oceniti naslednje

dejavnike: tveganje produkta, zbiranje informacij, zahteve po osebju in izobraţevanju,

urnike, testne strategije, obseg posameznega nivoja, cilje ipd. Pri kreiranju podrobnejših

testnih načrtov uporabljamo iste predloge kot za kreiranje glavnega testnega načrta.


14

Časovni potek planiranja testnih načrtov za posamezen nivo je obraten od njegove

izvedbe. Čeprav se test sprejemljivosti izvede kot zadnji, naredimo načrt zanj na samem

začetku To pa zaradi tega, ker je ta test zgrajen iz informacij (zahtev programske opreme),

ki so na voljo prve. Ta skupina testov opredeli, kakšen bo končni izdelek.

2.8.1 Test sprejemljivosti

Cilj tega testa je dokazati, da so vse uporabnikove zahteve pokrite. Največjo učinkovitost

doseţemo, če ga izvedejo kar uporabniki sami, in sicer v realnem (produkcijskem) okolju.

Analiza ciljne publike

Končni uporabniki so tista ciljna publika, ki bo brala testni načrt. V ciljno publiko lahko

štejemo tudi osebje, ki vodi sistemske teste, saj je izhod iz sistemskega testa vhod v test

sprejemljivosti. Zaradi zelo različne ciljne publike, ki vključuje tudi končne uporabnike,

mora biti ta načrt napisan v ne-tehničnem jeziku (brez uporabe ţargona).

Izvor informacij

Ključni dokumenti, ki jih potrebujemo pri izdelavi tega načrta so:

projektni načrt,

glavni načrt in

dokument SZPO (Specifikacija zahtev programske opreme).

Načrtovalci testa sprejemljivosti se pri načrtovanju bolj opirajo na glavni načrt kot pa na

projektni, saj so v glavnem načrtu na grobo opisani cilji vsakega posameznega nivoja, kar

vključuje tudi njihove vhodne in izhodne kriterije. To je tudi razlog, da bi morali vsi

podrobni načrti (ne samo podrobni načrt testa sprejemljivosti) slediti shemi glavnega

načrta. Če v času izdelave podrobnega načrta pride do kakšne večje spremembe, moramo

to popraviti tudi v glavnem testnem načrtu.


15

Naloge uporabnikov

Pri testu sprejemljivosti imajo veliko vlogo uporabniki. Njihove naloge so:

določanje zahtev,

odkrivanje poslovnega tveganja,

kreiranje, popravljanje in pregled testa sprejemljivosti,

določanje realnih scenarijev za teste,

priprava uporabnih testnih podatkov,

izvajanje testov,

pregled dokumentacije,

pregled rezultata testa, in

določanje kriterijev sprejemljivosti.

Ker so tudi končni uporabniki del preizkušanja sprejemljivosti, je potrebno vedeti, da je

takšno preizkušanje lahko zelo teţavno. Vsak uporabnik lahko ima namreč svoj pogled na

določen problem. Na primer, določenemu uporabniku je opozorilo pred brisanjem datoteke

na mestu, spet drugemu pa je potrjevanje takšnega opozorila povsem odveč. Če je med

zahtevami zapisano, da mora biti grafični vmesnik uporabniku prijazen, nam takšna

informacija kot programerju prav nič ne koristi. Takšno zahtevo je potrebno razčleniti na

tako majhne dele, ki jih lahko prenesemo v programski produkt. Pri tem si nekatera

podjetja pomagajo z zbiranjem zahtev na osnovi izdelanih prototipov.

Sledenje zahtevam

Glavni cilj testa sprejemljivost je dokazati uporabnikom, da smo upoštevali vse njihove

zahteve. Pri tem si velikokrat pomagamo s potrditveno matriko zahtev. V tabeli 4 so v

stolpcih prikazani testni primeri, v vrsticah pa so nanizane zahteve.


16

Zahteve Testni primer 1 Testni primer 2 Testni primer 3 Testni primer 4

Zahteva 1

Zahteva 2

Zahteva 3

Zahteva 4

Tabela 4: Potrditvena matrika zahtev.

Izhodni kriterij

Izhodni kriterij testa sprejemljivosti je zelo pomemben, saj je to pravzaprav tudi kriterij, ki

določa izid (kvaliteto) končnega produkta. Ti kriteriji so zasnovani ţe v načrtu GTN,

zapisani pa so tudi v podrobnih načrtih. Navedimo nekaj preprostih primerov:

v produktu ne smejo biti prisotne srednje ali teţke napake,

v posamezni funkcionalnosti smeta biti kvečjemu 2 napaki oziroma skupno je

lahko največ 50 napak,

vsaj en testni primer mora biti pravilen za vse zahteve,

testni primeri 15, 16 in 18 morajo biti pravilni,

program mora biti sposoben izvesti 1000 prenosov v 5 minutah,

odzivni čas sistema mora biti 2 sekundi.

Testno okolje

Testno okolje za izvajanje testov sprejemljivosti mora biti, kolikor je to le mogoče, realno.

Vsako odstopanje od realnega okolja predstavlja določeno tveganje. Za vsak nivo testiranja

bi morali preizkuševalci primerjati njihovo okolje z realnim in preučiti ter odpraviti

morebitne razlike.


17

2.8.2 Sistemski test

Pri izvajanju tega testa ponavadi porabimo večino testnih virov, saj mora test potekati

daljši čas in biti zelo obseţen. Obseţnost preizkušanja je omejena z razpoloţljivimi viri in

sprejemljivim tveganjem. Ob testiranju funkcionalnosti sistema lahko preizkusimo še:

zmogljivost, učinkovitost, uporabnost, obremenitev, prenosljivost, namestitev in stabilnost.

Med sistemsko preizkušanje lahko štejemo tudi regresijsko testiranje.


Če v podjetju obstaja testni oddelek, potem je le-ta zadolţen za sistemski test. Vodja tega

oddelka je običajno avtor načrta za sistemski test. V primeru, da podjetje ne premore

testnega oddelka, potem so avtorji testnega načrta kar razvijalci sami.

Planiranje načrta za sistemski test se lahko prične, ko so končani prvi osnutki zahtev, za

njegovo dokončanje pa potrebujemo še načrt programske opreme.

Sledenje zahtevam

Potrditvena matrika zahtev (glej podpoglavje 2.8.1) je dober začetek za sledenje zahtevam

sistemskega testiranja. Vendar pa ni dovolj obseţna za podporo celotnega koncepta

sistemskega testa, saj moramo pri tej vrsti testiranja ob samih zahtevah, upoštevati še

nastavitve, prilagodljivost, stanja, namestitev, lokalizacijo, vmesnike, obnovitev delovanja

po napaki, uporabo virov, občutljivost itd..

Vhodni kriterij

Kadar razvijalec naleti na napako v času testiranja enot oziroma integracijskega testa, jo

ponavadi popravi, ne da bi napako dokumentiral. Če se ista napaka odkrije v času

sistemskega testiranja, pa mora biti le-ta dokumentirana in prioritetno razvrščena ter

ustrezno pripravljena za ponovno, tj. regresijsko testiranje. Ko poteka sistemsko testiranje

se običajno razvijalci ukvarjajo ţe z drugimi problemi (celo projekti), kar pomeni, da je


18

odprava napake v času sistemskega testiranja veliko teţja, kot pa v času testiranja enot in

integracijskega testiranja. Zaradi tega je izredno pomembno, da predpišemo ustrezen

izhodni kriterij iz testa enot in integracijskega testa. Ta izhodni kriterij je dejansko vhodni

kriterij za sistemski test. Navedimo primer izhodnega kriterija iz razvojnih testov (test enot

in integracijski test):

vsi testi enot in integracijski testi morajo biti dokumentirani,

ne sme biti teţkih napak,

imeti moramo 90 % pokritost programske kode in

100 % pokritost vseh programskih specifikacij.

2.8.3 Integracijski test

Integracijski test je test, ki zagotovi, da posamezni programski deli sistema med seboj

pravilno sodelujejo (si pošiljajo pravilne podatke). Ta test potrdi ustrezno povezljivost med

deli sistema. Integracija je lahko izvedena z različnimi pristopi:

od spodaj-navzgor. V tem pristopu najprej integriramo in testiramo module na

najniţjem nivoju (npr. gonilnike). Ko smo le-te preizkusili, sledi integracija

naslednjih modulov iz višjega nivoja, ki jih zatem spet preizkusimo. Postopek

zaključimo, ko so vsi moduli integrirani in preizkušeni.

od zgoraj navzdol. Tukaj pa najprej integriramo in testiramo module na višjem

nivoju, kasneje pa dodajamo tiste iz niţjih nivojev.

Module, ki še niso integrirani v sistem, simuliramo. Eno glavnih vprašanj pri tem testiranju

je, katere module ustvariti in testirati prve. Najboljše je, da so prvi tisti moduli, ki so

najbolj rizični, da na ta način čim prej odkrijemo morebitne napake.


V večini podjetij integracijski načrt uporabljajo predvsem razvijalci kot kaţipot, saj

nakazuje, kako so posamezni deli sistema povezani, in kakšen je njihov medsebojni vpliv.

Uporabljajo pa ga tudi testne skupine, da se prepričajo, če se njihova testiranja ne

prekrivajo z drugimi testnimi skupinami.


19

Veliko podjetji ne opravlja posebej integracijskega testa, ampak ga vključijo kar na

začetek sistemskega testiranja. Integracijski test je zelo pomemben pri zelo velikih in

kompleksnih projektih, ali pa pri razvoju novega produkta. Določene napake se v

posamezni enoti odkrijejo šele pri integraciji, saj jih pri testu enot namreč ni moţno odkriti

(ni moţno vzpostaviti takšnih stanj). Integracijski test je usmerjen na testiranje vmesnikov

med posameznimi enotami, ki so pogosto vzrok za napačno delovanje celotnega sistema.

Problemi pri načrtovanju

Pred izvedbo integracijskega testa moramo natančno preučiti naslednje dejavnike:

katere module oziroma objekte bomo sestavili in testirali,

koliko časa moramo testirati,

ali je potrebna implementacija za doseganje določenih testnih ciljev,

kako bomo izločili probleme,

kako bomo uskladili to vrsto testiranja s sistemskim testiranjem,

kateri moduli so kritični.

Slika 8: Integracijski test.

Slika 8 prikazuje preprost projekt, ki sestoji iz več programskih modulov, ki jih je potrebno

integrirati. Sive kocke predstavljajo module, ki jih moramo zdruţiti, preden dobimo

funkcionalnost "naredi rezervacijo". Šele po uspešni integraciji in preizkusu njihovega

medsebojna delovanja, lahko to funkcionalnost posredujemo naprej v sistemsko testiranje.


20

Testno okolje

V večini organizacij je okolje integracijskega testa enako razvojnemu okolju. Podatki za

integracijsko testiranje pa so pogosto vzeti iz produkcijskega okolja.

2.8.4 Test enot

Testiranje enot je testiranje posameznih (najmanjših) delov programa. Opisano je tudi v

standardu IEEE 1008-1987. Pogosto se izvaja neformalno in ga enačimo z očiščevanjem

kode (angl. debugging). Testiranje običajno izvede programer sam. Poznamo še formalno

testiranje enot, ki se pa pogosto slabo izvaja oziroma se sploh ne izvaja. Do te vrste

testiranja pridemo tako, da po nekem obdobju očiščevanja in razvijanja programske

opreme razvijalcem ne dovolimo več nekontrolirano/nedokumentirano spreminjati kode

med izvajanjem testov enot. Formalno testiranje enot lahko začnemo šele, ko razvijalec

uspešno zaključi pregled kode in je mnenja, da le ta pravilno deluje.

Problemi pri testiranju enot

V podjetjih uspešnost razvijalcev oziroma programerjev merijo po številu napisanih vrstic

kode. S tega stališča je testiranje seveda popolnoma neproduktivno delo. Programerji so ob

tem še "kaznovani", če v njihovi kodi najdemo napake. Kljub temu pa je pritisk, da

dokončajo programski produkt v predpisanem roku, skoraj vedno močnejši od testiranja.

Drug problem je v tem, da so razvijalci preveč samozavestni in verjamejo, da bo

njihova koda zagotovo delovala pravilno. Zato jim je testiranje enot seveda odveč in ga

izvajajo le, če jim to dopušča čas, kar pa se pravzaprav nikoli ne zgodi. Zmotno je tudi

prepričanje: če razvijalec zna pisati programsko kodo, zna tudi testirati. Za izvajanje

preizkušanja moramo seveda programerje oziroma razvijalce ustrezno usposobiti ter jim

dati dostop do orodij za očiščevanje kode, orodij za kontrolo pokritosti kode ter sistema za

sledenje napakam ipd.

Programerji morajo pri formalnem testiranju enot tudi pisati dokumentacijo, vendar jo

pogosto ne ţelijo. Zato morajo dobiti občutek, da lahko s pomočjo vodilne osebe

programerjev spremenijo standarde, če se jim zdi, da ti ne funkcionirajo.


21

Prednost formalnega testiranja enot je, da lahko napisano dokumentacijo uporabimo kot

del dokumentacije nastale pri sistemskem testu. Tudi testne primere je moţno uporabiti pri

poznejšem regresijskem testiranju (ali pa celo za višje nivoje testiranja). Dodatna prednost

formalnega testiranja je tudi v tem, da lahko uporabimo kriterije, ki nam omogočajo odkriti

problematična območja oziroma module.

Izhodni kriterij

Pogost izhodni kriterij pri testiranju enot je gostota napak, ki ga definiramo kot število

napak na vrstico kode. Kljub mnoţici odkritih in popravljenih napak obstaja še velika

verjetnost, da v programski kodi obstajajo še neodkrite napake. Eden od razlogov za to je,

da smo z odpravljanjem napak lahko vnesli kakšno novo.

2.9 Določitev testnih ciljev in pripravljanje preizkusov

Testne cilje lahko ločimo na splošne in podrobne cilje. Če ţelimo, na primer, testirati

varnost programa in imamo na voljo samo splošen cilj, potem to ne zadostuje, saj ne vemo,

česa vse se moramo lotiti pri testiranju. Zato moramo seveda zgraditi seznam podrobnih

testnih ciljev. Za prej omenjeni primer bi lahko to bilo testiranje:

kodiranja,

shranjevanja gesel in

moţnosti vdora v sistem.

Kreiranje testnih ciljev poteka v več korakih. Začne se z zbiranjem materiala in konča z

vzdrţevanjem testne matrike. V nadaljevanju te korake kratko predstavljamo.

Korak 1: Zbiranje materiala

V tem koraku zberemo vso moţno dokumentacijo, ki je na voljo o našem preizkušanem

sistemu. Ti dokumenti so:

specifikacije zahtev,


22

navodila za uporabo,

povratne informacije strank,

funkcionalne specifikacije in

programski načrt.

Korak 2: Oblikovanje miselne ekipe

Miselno skupino (angl. brain storming team) sestavimo iz treh oziroma štirih, vsekakor pa

ne več kot osmih strokovnjakov iz ustreznega področja. To skupino lahko sestavljajo

razvijalci, preizkuševalci, končni uporabniki, analitiki, sistemski arhitekti itd.

Korak 3: Določitev splošnih testnih ciljev

Miselna skupina mora najprej določiti le splošne testne cilje. Navedimo nekaj primerov:

funkcije oziroma metode,

ovire,

sistemske nastavitve,

vmesnike z drugimi sistemi,

vhode/izhode programa in

vse ostalo, kar je povezano z zunanjim delovanjem sistema.

Korak 4: Določitev prioritete testnim ciljem

Vsakemu splošnemu cilju nato dodelimo nivo pomembnosti. Ponavadi jim določimo

prioriteto glede na obseg in tveganje. Testni cilj z največjim obsegom ima običajno visoko

prioriteto. Prednost tega je, da takšen cilj pokrije večino funkcionalnosti in zahtev.

Korak 5: Razdelitev splošnih testnih ciljev na podrobne

Naslednji korak je razdelitev splošnih ciljev na bolj podrobne. Ta postopek lahko seveda

večkrat ponovimo. Vsekakor pa ni priporočeno, da cilje preveč podrobno razdelimo.


23

Korak 6: Tvorjenje matrike testnih ciljev

V prvi stolpec potrditvene matrike zahtev (glej tabelo 4) zapišemo še naše testne cilje, ki

naj bodo razvrščeni po prioriteti. Nad cilje pa nato zapišemo testne primere, ki smo jih

uporabljali v prejšnjih verzijah našega programa. Ta proces prirejanja testnih primerov k

testnim ciljem se imenuje kalibracija. Ta matrika nam tudi pomaga pri odkrivanju

redundance testnih ciljev in primerov. Slika 9 prikazuje primer tvorjenja matrike testnih

ciljev, kjer smo potrditveni matriki zahtev dodali testne cilje A, B in C.

Slika 9: Matrika testnih ciljev.

Korak 7: Preverjanje, če testni primeri pokrivajo vse testne cilje

Iz slike 9 je razvidno, da zahteva 1 in funkcionalnost 2 nista pokriti, to nakazuje, da je

potrebno narediti dodaten testni primer in ga vključiti v matriko. Pogosto je laţje narediti

nov testni primer kot pa spreminjati starega.

Korak 8: Ocenitev vsakega podrobnega testnega cilja

V tem koraku ocenimo, če ima vsak testni cilj dovolj veliko pokritost testnih primerov, v

nasprotnem primeru pa dodamo nove testne primere. Če je testni cilj pokrit samo z enim

testnim primerom, moramo raziskati, ali le to zadostuje. Če ne zadostuje, potem bodisi

razdelimo testni cilj na manjše, ali pa ustvarimo nove testne primere.


24

Korak 9: Vzdrţevanje matrike testnih ciljev

Vzdrţevanje matrike testnih ciljev zahteva "veliko časa", vendar pa je zelo pomembno, saj

to matriko lahko uporabimo tudi pri regresijskem testiranju ali pa pri testiranju nove

verzije programa. Če matrike ne vzdrţujemo, lahko izgubimo dobre testne primere.

Pripravljanje preizkusov

Pripravljanje preizkusov poteka po zgoraj navedenem procesu.

2.10 Uvajanje preizkusov

Uvajanje preizkusov ni le pisanje kode, ampak je to celoten proces od zbiranja podatkov,

razvijanja testnih procedur, priprave testnega okolja, do izbire in uvajanja orodij, s katerimi

si pomagamo pri izvedbi tega procesa. Pri tem procesu moramo odgovoriti na naslednja

vprašanja:

Kako bomo dobili podatke za testiranje?

Kaj vse bomo potrebovali za testno okolje?

Katere testne procedure bi lahko avtomatizirali?

Katera testna orodja bomo uporabili?

Kako bomo ugotovili pravilnost testov?

2.10.1 Testno okolje

V podpoglavju 2.8 smo ţe analizirali testno okolje. V tem podpoglavju bomo s to analizo

nadaljevali, saj bomo bolj podrobno predstavili določene atribute testnega okolja.

Strojna oprema

Strojna oprema igra pomembno vlogo v testnem okolju. Zelo pomembno je, da se pri

testiranju čim bolj pribliţamo produkcijskemu okolju stranke. Dodaten problem pa


25

predstavljajo še nastavitve strojne opreme, saj lahko ima vsaka stranka svoje nastavitve. Pri

testiranju sistema, na katerem tipično dela 100 uporabnikov, seveda ne moremo simulirati

vseh, lahko pa izdelamo profile za, recimo, 20 najbolj tipičnih nastavitev. Te profile lahko

kasneje uporabimo pri skupnem analiziranju problemov s stranko. Vsekakor pa moramo

testiranje izvesti na profilu, ki ima definirano minimalno strojno opremo, na kateri se še

lahko izvaja naša programska oprema.

Odvisna programska oprema

Naš dokončan programski produkt je tipično nameščen na določen računalniški sistem. Na

tem računalniškem sistemu pa se seveda nahaja tudi druga programska oprema, ki jo naš

program za svoje delovanje potrebuje. Zato seveda obstaja verjetnost, da si programi

medsebojno preprečujejo delovanje. To je moţno, če uporabljajo skupne vire (npr. skupne

zbirke). Takšne situacije moramo seveda preizkusiti.

Preizkušanja se lotimo podobno kot pri različni strojni opremi, in sicer definiramo več

profilov, kjer vsak profil predstavlja kombinacijo naše in ostale programske opreme.

Vmesniki

Testiranje vmesnikov med programsko opremo je teţko. Vmesniki so pogost izvor napak,

saj različna programska oprema v osnovi ni bila mišljena za skupno delovanje. Dodatni

problem je še, da vsaka programska oprema uporablja svoje standarde in tehnologije. Test

vmesnikov se običajno opravi nepopolno, saj največkrat teste izvajamo kar na simulatorjih

vmesnikov. To storimo zaradi tega, ker se drugi vmesnik ţe uporablja v produkciji in zato

na njem ne moremo opraviti testiranja, saj bi lahko uničili realne podatke.

Testni podatki

Med testiranjem ţelimo ustvariti čimbolj realno testno okolje (seveda, če to dopuščajo viri

in ocenjena tveganja). K realnemu okolju vsekakor spadajo tudi realni podatki. Ti podatki

so lahko v obliki sporočil, transakcij, zapisov v podatkovni bazi, datotek ipd. Najbolje je,

če lahko uporabimo podatke iz realnega-produkcijskega okolja. Ţal v praksi pogosto to ni


26

moţno. Razlogov je več. Zadnja verzija našega programa lahko, na primer, uporablja

drugačen format podatkov od produkcijskega. V določenih primerih so lahko ti podatki

tudi zaupne narave. Če pa imamo dostop do realnih podatkov, se lahko kljub temu zgodi,

da le-ti ne bodo pokrili vseh testnih scenarijev. Zato je pogostokrat potrebno testne podatke

kreirati bodisi ročno ali pa z uporabo programskih orodij.

Obseg testnih podatkov

Veliko organizacij se odloči, da bo pri testiranju uporabilo omejeno količino podatkov, saj

le-ta v večini primerov pokrije vse testne primere. Treba pa se je zavedati, da lahko večje

količine podatkov v produkcijskem delovanju povzročijo slabo odzivnost sistema. Idealno

bi bilo, če bi pri testiranju uporabili enako količino podatkov kot v produkcijskem okolju.

Strategija

Tudi strategija testiranja vpliva na testno okolje. Če za testiranje enot uporabljamo, na

primer, prijateljsko testiranje (angl. buddy testing), potem moramo v takšnem okolju imeti

preprost dostop do dokumentacije in kode drugega programerja.

2.10.2 Avtomatizacija testov

Določena preizkuševalna orodja avtomatizirajo del preizkuševalnega procesa. V to

kategorijo orodij štejemo tudi orodja za vodenje projektov, za iskanje napak in orodja za

očiščevanje programov.

Avtomatizacija testiranja je dejansko integracija preizkuševalnih programov v testno

okolje tako, da so izvedba preizkusov, zapisovanje in primerjava rezultatov narejeni

praktično brez interakcije človeka. Vseh testov seveda ni smiselno, niti moţno

avtomatizirati (npr. uporabniške interakcije ne moremo avtomatizirati).

Avtomatizacija preizkušanja seveda zahteva svoj čas. V praksi je prav moţno, da za

avtomatizacijo porabimo isto časa kot kreiranje ročnih testov. Kako ocenimo, da se nam

avtomatizacija izplača? Predstavimo preprost postopek. Vse teste najprej opravimo ročno,

zatem pa avtomatiziramo tiste teste, za katere mislimo, da se bodo velikokrat ponovili.


27

Nato ocenimo, koliko časa prihranimo z avtomatizacijo pri celotnem testiranju. Če je

prihranek na času večji od časa, ki ga porabimo za razvoj orodij in programske opreme za

avtomatizacijo, potem je avtomatizacija smiselna. Ob samem prihranku časa, pa je razlog

za avtomatiziranje preizkušanja tudi to, da človek ob izvajanju testov, ki se pogosto

ponavljajo, postane nepazljiv. Naštejmo še teste, ki so primerni za avtomatizacijo:

regresijski test,

dimni test,

test zmogljivosti in

zagonski test.

Ob ponavljajočih se testih so za avtomatizacijo primerni tudi dolgočasni, naporni in

obseţni testi, kot so:

test pokritosti kode,

test matematičnih funkcij in

test simulacij.

2.11 Izvajanje preizkusov

Priprave na izvedbo preizkusov potekajo skozi cel ţivljenjski cikel razvoja programske

opreme, sama izvedba pa se zgodi skoraj ali pa čisto na koncu. Izvajanje preizkusov je

najbolj viden del testiranja in se običajno začne izvajati na samem koncu razvoja. Tako

imenovani stranski produkti izvajanja preizkusov pa so še:

poročila o napakah,

dnevnik testiranja ter

rezultati in povzetek.


28

Slika 10: Vhodi in izhodi v izvajanje testov.

Slika 10 prikazuje vhode in izhode pri izvajanju testiranja. Pred testiranjem moramo

določiti, kdo bo teste izvajal (glej tabelo 5) in kakšen bo vrstni red izvajanja testov.

Odgovorna

skupina

Test

enot

Integracijski

test

Sistemski

test

Test

sprejemljivosti

Preizkuševalci

Razvijalci

Končni uporabniki

Tabela 5: Odgovorne skupine za izvajanje testov.

Pisanje novih testnih primerov med izvajanjem preizkušanja

Četudi smo še tako vešči načrtovanja testnih primerov, se nam bodo pri izvajanju

preizkusov zagotovo porodili še novi testni primeri. Med samim izvajanjem testov namreč

bolje spoznavamo naš sistem in tako dobimo vedno nove ideje za testne primere. Zaradi

stiske s časom vseh novih testnih primerov običajno ţal ne uspemo zabeleţiti.


29

Zapisovanje rezultatov testnih primerov

Rezultate testiranj moramo seveda vedno zabeleţiti. Če je testiranje avtomatizirano, se tudi

rezultati shranjujejo samodejno, sicer pa rezultate ročno zapisujemo v dokument testnih

primerov. Pomembno je tudi, da označimo, ali je testni primer uspel ali ne. Za neuspele

teste se ustvari še poročilo o napaki.

Dnevnik testiranja

Ta dnevnik pišemo zato, da bi laţje posredovali informacije med preizkuševalce,

uporabnike in razvijalce, ter tudi zaradi laţjega spremljanja trenutnega stanja testiranja.

Ker je namen dnevnika testiranja deliti informacije in ne analiziranje podatkov, mora biti

vnos in pregledovanje teh informacij relativno enostavno. Standard IEEE 829-1998

vsebuje predlogo za pisanje dnevnika testiranja.

Poročilo o incidentih testiranja

To poročilo je mehanizem, s katerim beleţimo incidente, napake in napredek pri testiranju.

Predloga se nahaja v standardu IEEE 829-1998. Poročilo napiše tisti, ki odkrije napako ali

incident. Če je napako odkril uporabnik v produkcijskem okolju, in če ima dostop do

sistema za sledenje napakam, ga zapiše on, sicer pa napako zapiše odgovorna oseba iz

oddelka sistemske podpore. Če napako odkrije razvijalec, potem poročilu o incidentu

napiše kar ta isti razvijalec. Del analize incidenta je tudi, da ugotovimo, ali je odpoved

povzročila nova napaka, ali pa je odpoved le še en primer stare napake. To poročilo

direktno vpliva na to, kako hitro lahko programsko napako ponovno vzpostavimo in jo

analiziramo, ter seveda odpravimo.

Status testiranja in rezultati

Ključna naloga vodje preizkuševalcev je, da vodi oziroma nadzoruje status testiranja. Ţe v

glavnem testnem načrtu mora biti opredeljeno, kako bomo spremljali status testiranja.

Status se pogosto beleţi ob mejnikih testiranja, ki so lahko številka, pomembnost ali


30

lokacija odkritih napak. Nekateri vodje pa beleţijo status glede na izbrane kriterije sistema,

kot so stabilnost, zanesljivost in uporabnost. Poročilo o statusu testiranja se lahko uporablja

kot formalno obvestilo o napredku testiranja. Primer takšnega poročila prikazuje tabela 6.

Projekt: Ime projekta

Testirana

funkcionalnost

Vsi

testi

Število

dokončanih

%

Dokončanih

Število

uspešnih

%

uspešnih

Funkcionalnost 1 46 46 100 41 89



… … … … … …

Skupaj 395 320 81 290 91

Tabela 6: Primer poročila o statusu testiranja.

Poročilo s povzetkom testiranja

V tem poročilu povzamemo rezultate testnih aktivnosti. Na tej osnovi lahko nato naredimo

oceno kvalitete programske opreme. Poročilo mora vsebovati tudi vse poznane

nepravilnosti programa. Za vsak testni načrt mora obstajati svoje poročilo s povzetkom

testiranja posameznega nivoja.

Pogosto se podjetja pritoţujejo, da za pisanje poročila s povzetkom ni dovolj časa, saj

se testiranje izvaja tik pred rokom izdaje produkta. Vendar za pisanje tega poročila ne

porabimo veliko časa. Podatke za to poročilo smo namreč zbirali skozi celoten ţivljenjski

cikel. To poročilo je pravzaprav enako poročilu statusa testiranja, in sicer na zadnji dan

testiranja. Predloga takšnega poročila se nahaja v standardu IEEE 829-1998.

2.12 Zaključek preverjanja

Odgovor na vprašanje, kdaj testiranje zaključiti, bi moral biti zapisan v izhodnih kriterijih

posameznega testnega nivoja. Kar pomeni, da ko izpolnimo izhodni kriterij za test

sprejemljivosti, je naš produkt pripravljen za produkcijsko delovanje.


31

Kriterij odkrivanja novih napak

Ta kriterij uporabljajo nekateri za določitev datuma izdaje produkta. Če število na novo

odkritih napak v določenem časovnem obdobju pade pod vnaprej predpisan kriterij (npr.

prag), je produkt pripravljen za izdajo. Seveda pa je lahko vzrok, da ne najdemo novih

napak tudi, da nismo napisali novih testnih primerov oziroma, da smo vloţili manj napora

v testiranje. Odločitev o izdaji programskega produkta zato ponavadi kombiniramo še z

drugimi pokazatelji (npr. s stroški odkrivanja napak kot je prikazano na sliki 11).

Slika 11: Kriterij odkrivanja novih napak.

Kriterij števila preostalih napak

Moţen kriterij za dokončanje testiranja je tudi, da ocenimo, koliko napak se bo še pojavilo

v času uporabe produkta. To lahko storimo s pomočjo dokumentacije podobnih projektov,

pri čemer moramo seveda upoštevati razlike med projekti in njihove specifičnosti.

Poraba vseh virov

Preveliki porabi časa in denarja lahko vplivata na izdajo produkta, četudi morebiti ta še ni

brez napak. Razlog za takšno izdajo je lahko, da ima uporabnik nameščeno še slabšo

verzijo od pravkar razvite, ali pa, da je tveganje za izdajo nepopolnega produkta manjše od

poslovnega tveganja, če tega produkta sploh ne bi izdali in bi nas prehitela konkurenca.


32

2.13 Ocena učinkovitosti testiranja

Zadovoljstvo strank

Veliko podjetij uporablja za merjenje učinkovitosti testiranja kar mero zadovoljstva kupcev

z njihovim produktom. Mnenje strank o programskem produktu lahko dobimo z anketami

ali pa z analiziranjem njihovih klicev v oddelek za podporo. Slabost te ocene je v tem, da

je na voljo šele po izdaji oziroma namestitvi in uporabi produkta.

Analiza napak

Učinkovitosti testiranja lahko ocenimo tudi na osnovi analiziranja programskih napak.

a. Število napak odkritih pri testiranju

Slabost ocenitev, ki temeljijo na analizi napak, je v tem, da se vse programske napake

upoštevajo kot enako pomembne. Napake moramo zato seveda kategorizirati (npr. v

kritične, srednje-kritične, dovoljene ipd.).

Še na drug problem lahko pri tem naletimo. Če v produkt vključimo programske

komponente, ki jih nismo sami razvijali niti testirali, potem odkrite napake v teh

komponentah seveda vplivajo na število odkritih napak v našem programskem sistemu.

Zelo pomembno je torej, da imamo kvalitetne vstopne komponente.

Metodo štetja napak pri testiranju pa lahko kljub temu uspešno uporabimo. Najprej

ustvarimo mnoţico testnih primerov, ki zagotavlja določeno pokritost kode, zatem pa

beleţimo število napak pri testiranju. Dobljene rezultate nato primerjamo s prejšnjimi

testiranji. Število napak dodatno normaliziramo, pri čemer upoštevamo stopnjo sprememb

v sistemu in zahtevnost ter količino na novo dodanih funkcionalnosti.

b. Število napak odkritih v produkciji

Zelo pogost kriterij za ocenitev učinkovitosti testiranja je štetje napak odkritih v

produkcijskem delovanju programa. Predvsem je tu zanimivo vprašanje, zakaj napak, ki jih


33

odkrije stranka, ni odkril tudi preizkuševalec, oziroma jih ni odpravil. Seveda je tudi ta

kriterij na voljo šele po uporabi produkta v produkciji. Ob tem moramo meriti še pogostost,

razširjenost in trende odkritih napak, in sicer od izdaje do izdaje.

c. Odstotek odkritja napak

Na osnovi kriterijev iz točk a in b lahko sestavimo samostojen kriterij. Z njim ţelimo

dejansko oceniti, koliko napak od vseh moţnih smo odkrili. Odstotek izračunamo z

pomočjo naslednje formule:

O=A/(A+B)*100,

kjer je O odstotek odkritih napak, A je število napak odkritih pri testiranju in B je število

neodkritih napak. Za število neodkritih napak običajno vzamemo kar število napak, ki jih

je odkrila stranka. Odstotek odkritja napak je odličen kriterij, kljub temu pa moramo biti

pozorni na naslednje probleme:

upoštevati moramo pomembnost in razširjenost napak.

kako bomo vedeli, da je uporabnik odkril vse napake? Zato moramo pregledati

prejšnje projekte ter izdaje in ugotoviti čas, ki ga je porabil za odkritje vseh napak.

tudi to metodo lahko uporabimo šele potem, ko je naš izdelek ţe v produkciji. Ta

metrika nam torej ne pomaga izmeriti učinkovitost testiranja pri trenutnem

projektu, ampak na dolgi rok.

kdaj začnemo šteti napake: ob testiranju enot, integracijskem testu, sistemskem

testu ali testu sprejemljivosti? Ustrezno izbiro moramo nato upoštevati v vseh

projektih.

odločiti se moramo še, ali bomo šteli tudi tiste napake, ki jih preizkuševalec

objektivno ne more odkriti (npr. ker ne moremo testirati v dejanskem

produkcijskem okolju).


34

d. Starost napake

Znano je, da pozneje ko odkrijemo programsko napako, večjo škodo naredi našemu

sistemu, hkrati pa jo je tudi veliko teţje odpraviti. Logično je, da učinkovitejše testiranje

odkrije napake ţe v zgodnjih fazah. Vsako fazo razvoja zato označimo z določeno

prioriteto (npr. poznejšim fazam razvoja dodelimo višje prioritete). Zatem beleţimo napake

v odvisnosti od posamezne faze. Manj kot je napak v poznejših razvojnih fazah, bolj je

testiranje učinkovito.

e. Gostota napak

Gostoto napak definiramo z izrazom

G=A/B,

kjer je G gostota napak, A je število odkritih napak in B je število vrstic kode. Tudi ta

metoda za merjenje učinkovitosti ni popolna. Pojavljata se dve nejasnosti, in sicer:

kaj je napaka oziroma kaj štejemo za napako? Jasno moramo opredeliti, ali

upoštevamo vse napake ali pa zgolj kritične. Definirati je treba tudi, od katere

faze naprej štejemo napake.

kaj je vrstica kode? Tudi merjenje velikosti modulov je lahko problem, saj se

število vrstic zaradi izkušenj, znanja ter načina programiranja in uporabljenega

programskega jezika od programerja do programerja razlikuje.

Metode pokritosti

Metode pokritosti se izkaţejo še za najbolj učinkovite pri merjenju učinkovitosti testiranja.

Niso odvisne od kvalitete programske opreme, ki jo testiramo, prav tako pa jih lahko

uporabljamo ţe pred samo izdajo produkta (tj. pred produkcijskim delovanjem). Pokritost

zahtev in ciljev lahko preverimo takoj, ko so na voljo testni primeri. To pomeni, da jih

lahko preizkusimo še preden imamo napisano kodo. To metodo lahko uporabimo za


35

merjenje učinkovitosti testiranja zato, ker sloni na filozofiji, da je dober testni primer tisti,

ki bodisi odkrije napako ali pa pokaţe, da funkcija deluje dobro.

a. Pokritost zahtev in načrta (potrditvena matrika zahtev)

Vsaka testna metodologija ţeli pokriti vse zahteve. Čeprav bi testirali vse zahteve, pa je še

vedno moţno, da nismo pokrili oziroma testirali kakšnega pomembnega pogoja. Morebiti

obstajajo celo problemi v programskem načrtu, ki jih ni moţno identificirati s testiranjem

zahtev. Zato je pomembno, da ob pokritosti zahtev merimo tudi pokritost programskega

načrta.

b. Pokritost kode

Veliko strokovnjakov za testiranje je mnenja, da je merjenje pokritosti kode

najpomembnejše. Merjenje pokritosti kode se uporablja ţe vsaj 20 let. Pokritost kode

dejansko opredeljuje preizkuševalcu, kateri stavki, poti ali vejitve, so oziroma niso pokrite

z določenim testnim primerom.

Metoda pa ima svojo slabost. Četudi dobimo pozitiven rezultat pokritosti, še vedno ni

nujno, da je koda tudi pravilna oziroma ustreza zahtevam. Metoda je najbolj učinkovita na

niţjih nivojih testiranja (npr. pri testiranju enot, testu integracije).


36

3 APLIKACIJA, NAMENJENA ZA IZPISOVANJE

DOKUMENTOV

V tem poglavju bomo na kratko predstavili programski produkt za tvorjenje izpisov

oziroma poročil. Produkt je zgrajen na osnovi arhitekture streţnik-odjemalec. Naša rešitev

je integrirana v obstoječ produkt komercialnega podjetja Comtron d.o.o. Čeprav to podjetje

trţi in do določene mere razvija lastne programske rešitve, pa nima posebnega oddelka za

testiranje, niti ne uporablja kakšne posebne metodologije pri testiranju. Naša motivacija je

zato bila, da se bomo pri razvoju in preizkušanju tega programskega sistema drţali

priporočil testne metodologije STEP.

3.1 Odjemalec

Glavna naloga odjemalca je, da podatke, ki jih sprejme iz obstoječega produkta TIC (Tron

inter center) podjetja Comtron d.o.o., sestavi v ustrezen niz, ki ga v obliki zahteve nato

pošlje na streţnik. Odjemalec omogoča tudi prikazovanje izpisov, ki jih kreira streţnik.

Prikaz izpisov

V odjemalcu teoretično obstajata dve moţnosti za prikazovanje izpisov (slika 12), in sicer:

1. prikaz izpisov v oknih in

2. prikaz izpisov s pomočjo kontrolnika spletni brskalnik, s katerim navigiramo do

ASP (angl. Active Server Pages) .Net strani.

Odločili smo se za drugi način, saj smo upoštevali dejstvo, da je produkt TIC napisan

še v modelu COM (angl. Component Object Model). Našo formo .Net lahko dvignemo na

raven modela COM le s pomočjo zavijalcev (angl. wrapper). Ob tem tudi ni treba skrbeti

za prenos izpisa s streţnika na odjemalca. Vsi izpisi se namreč kreirajo kar na streţniku, za

prenos pa poskrbi spletni brskalnik.


37

Zgradba ustreznega niza

Kontrolnik spletni brskalnik vsebuje metodo "navigate", ki jo lahko kličemo s parametrom

"postdata" (tj. pošlji podatke). Takšna funkcionalnost omogoča pošiljanje podatkov do

našega streţnika za izpise. Podatke moramo zato formirati v ustrezen zakodiran niz URL,

ki ima naslednjo obliko:

Ime_param1=vrednost1&Ime_Param2=vrednost2....Ime_ParamN=vrednostN .

Grafični vmesnik

Na sliki 12 je prikazan grafični vmesnik odjemalca, kjer lahko uporabnik izbere obrazec, ki

ga ţeli izpisati ter tip pregledovalnika za izpise. Ko uporabnik izbere vse ustrezne

nastavitve, aktivira izpis bodisi s klikom na gumb za izpis ali gumb . Izpis se nato kreira

in prikaţe v izbranem pregledovalniku.

Slika 12: Glavno okno odjemalca.

Privzeti pregledovalnik je pregledovalnik na osnovi komponente ActiveX (glej sliko

13), uporabnik pa se lahko odloči tudi za izpis, ki je transformiran v format PDF (angl.

Portable Document Format).


38

Slika 13: Pregledovalnik izpisov na osnovi komponente ActiveX.

Ustvarjen dokument lahko uporabnik nato izvozi v enega izmed formatov, ki so

prikazani na sliki 14

Slika 14: Moţni izvozi izpisa.

Ko uporabnik izbere format, mu odjemalec ponudi bodisi, da dokument odpre ali pa ga

shrani na disk. Prikaţe se mu dialog brskalnika IE (angl. internet explorer), in sicer dialog

za prenos. Dokument pa je seveda moţno zgolj natisniti.


39

3.2 Strežnik

Glavna naloga streţnika je sprejemanje parametrov, ki jih pošilja odjemalec. Nekatere od

teh parametrov (npr. "DirectPrint", "LanguageID", "ExportFormat", "ReportName")

uporabljamo za nastavitve streţnika. Z njimi pridobimo informacije o tem, če bomo, na

primer, dokument takoj natisnili in to brez predogleda, ali bomo izpis le izvozili v ustrezen

zbirčni format, ali moramo dokument pred predogledom še prevesti v ustrezen jezik itd.

Preostale parametre, ki so potrebni za poizvedovanje v podatkovni bazi ali za oblikovanje

izpisa (npr. "ArticleID", "FirmID", "MultiLine"), pa priredimo izpisu, ki je fizično shranjen

na streţniku. Ko so vsi podatki na voljo in ustrezne streţnikove nastavitve posodobljene, se

aktivira generiranje izpisa.

Streţnik je napisan v okolju ASP .Net. Pri razvoju smo si pomagali s knjiţnicami

ActiveReports za okolje .NET 3.0 podjetja Data Dynamics. Uporabili smo programski

jezik C#. V nadaljevanju bomo podrobneje predstavili pomembnejše funkcionalnosti tega

streţnika.

Sprejemanje in prirejanje parametrov

Podatke na streţniku sprejemamo z ukazom "Request.Form", ki je naslednje oblike

RequestForm ["ime parametra"].

Največja prednost metode "post" je, da podatki niso vidni, hkrati pa je lahko količina

podatkov neomejena. Podatke nato priredimo izpisu, pri čemer upoštevamo, da morajo biti

imena parametrov na izpisu in tistih, ki jih sprejemamo na streţniku, enaka. V nasprotnem

primeru se parametri ne priredijo. Na sliki 15 vidimo izvorno kodo funkcije

Nastavi_parametre, ki prireja parametre izpisu.


40

Slika 15: Izvorna koda za prirejanje parametrov izpisu.

Nastavitev ustrezne povezave v podatkovno bazo

Pri razvoju smo morali upoštevati, da ima lahko vsaka stranka več firm in posledično več

podatkovnih baz. Zato smo morali dinamično nastavljati tudi povezave v podatkovno bazo.

Opcije za podporo več firmam so naslednje:

več firm lahko ima isto podatkovno bazo,

vsaka firma lahko ima svojo podatkovno bazo na eni instanci SQL in

vsaka firma ima svojo instanco SQL.

Avtomatsko prevajanje izpisov

Večjezikovna podpora oziroma prevajanje izpisov deluje tako, da ima vsak izpis svojo

datoteko XML za prevode, ki je shranjena na streţniku. Primer takšne datoteke XML je

prikazan na sliki 16


41

Slika 16: Primer datoteke XML s prevodi.

Streţnik primerja vrednosti polja ime v zbirki XML (npr. name="label10") z imenom

besedilnega polja na izpisu. Če sta imeni enaki, potem priredi tekst besedilnega polja iz

izpisa, s tistim v datoteki XML. Po prevajanju vseh imen kontrol, shrani streţnik izpis na

disk. Tega izpisa zato ne rabimo ponovno prevajati, vse dokler uporabnik ne izbere v

produktu TIC (tj. odjemalcu) drug jezik. To je silno pomembno, saj je prevajanje izpisov –

streţnik mora namreč primerjati in prevesti imena vseh kontrol – časovno zahtevna

operacija.

Na sliki 17 vidimo del izvorne kode funkcije "Localize". Ta funkcija je zasnovana za

branje prevodov iz datoteke XML in njihovo prirejanje izpisu.

Slika 17: Izsek izvorne kode za prevajanje izpisov.


42

Izvoz izpisov

Odjemalec pošlje zahtevo za izvoz izpisa. Vrednosti parametra "ExportFormat", le-tega

prejme streţnik, so lahko (glej sliko 14):

PDF,

TXT,

TIFF,

EXCEL in

RTF.

Ta vrednost določa tip izvoza. Z uporabo funkcije "export" (iz knjiţnic ActiveReports

3.0) za določen tip izvoza (npr. PDF) ustvarimo dokument in ga zapišemo v pomnilnik

("MemoryStream"). Streţnik nato kot odgovor s pomočjo ukaza "response", odjemalcu

pošlje "MemoryStream", v katerem se dokument nahaja.

Slika 18 prikazuje izsek funkcije "export", kjer določamo tip izvoza. Prikazana je tudi

pomoţna funkcija "dialog_download", kjer formiramo streţnikov odgovor namenjen

odjemalcu.


43

Slika 18: Izsek izvorne kode za izvoz izpisov.


44

4 OPIS PREIZKUŠANJA

V tem poglavju bomo predstavili, kako je potekal razvoj ter preizkušanje aplikacije za izpis

dokumentov. Za testno metodologijo smo uporabili metodologijo STEP. Opisali bomo vse

nastale dokumente, določene izseke teh dokumentov pa bomo tudi prikazali. Zaradi večje

preglednosti jih bomo zapisali s posebno pisavo. Strnjeno bomo predstavili tudi rezultate

preizkušanja.

4.1 Kronološki pregled aktivnosti

Najprej smo skupaj z analitiki, vodjo programerjev in končnimi uporabniki ustvarili

dokument SZPO, kjer smo opisali funkcionalnosti in specifikacije naše aplikacije za izpis

dokumentov. Na osnovi tega dokumenta smo pričeli s pisanjem testnih načrtov. Najprej

smo imeli na voljo samo zunanje (grobe) specifikacije produkta, zato smo lahko napisali le

glavni testni načrt, načrt za test sprejemljivosti ter sistemski test. Kasneje, ko smo s

projektom prešli v fazo uvajanja, smo pridobili še podrobnejše informacije. Ti podatki pa

so nam sluţili za izdelavo načrta za integracijski test in aţuriranje sistemskega testa.

Razvoj programske opreme je potekal sočasno s pisanjem testnih načrtov. Najprej smo

razvili osnovni streţniški del (tj. brez funkcionalnosti za prevajanje) ter izvedli test enot

nad tem delom programske opreme. Podatke, ki jih pošilja odjemalec, smo simulirali, saj

le-tega še nismo imeli razvitega. Po razvoju odjemalca smo najprej izvedli test enot, zatem

pa je sledilo povezovanje obeh modulov (tj. odjemalca in streţnika) ter izvedba

integracijskega testa. Podobne teste smo izvedli še kasneje, ko smo razvili in integrirali

funkcionalnost za prevajanje. Na koncu projekta, ko je bil naš programski sistem ţe

delujoč, smo izvedli še sistemski test ter nato še test sprejemljivosti.

Potek izvajanja testiranja smo zabeleţili v dnevnik testiranja. Posamezne testne

procedure, testne primere ter rezultate preizkušanj smo opisali v dokumentu o testnih

primerih. Po zaključku preizkušanja smo rezultate analizirali in napisali dokument s

povzetkom testiranja.


45

4.2 Dokument Specifikacije zahtev programske opreme (SZPO)

Dokument SZPO je temelj vsakega projekta in preizkušanja, saj zgolj na njegovi osnovi

lahko začnemo snovati načrte za testiranje. Napisali smo ga po standardu IEEE 830-1998.

Dokument SZPO vsebuje naslednje razdelke:

1 Uvod

1.1 Namen

1.2 Področje/cilji

1.3 Definicije, okrajšave

1.4 Reference

1.5 Pregled vsebine SZPO

2 Splošen opis

2.1 Perspektive produkta

2.2 Funkcionalnost produkta

2.3 Značilnosti uporabnikov

2.4 Omejitve

2.5 Domneve in odvisnosti

3 Specifične zahteve

Dodatno

Kazalo

Najpomembnejši del dokumenta SPZO je vsekakor točka 2.2, kjer opisujemo

funkcionalnost programskega produkta. V nadaljevanju podajamo ta izsek dokumenta

SZPO. Naj še enkrat poudarimo, da so vsi izseki iz teh dokumentov, zapisani s posebno

pisavo.

Točka 2.2 Funkcionalnost produkta

Odjemalec

Odjemalec naj bo integriran v obstoječ produkt TIC. Njegova glavna naloga je pošiljanje podatkov

in zahtev na strežnik, hkrati pa je zadolžen tudi za prikaz izpisov, ki jih generira strežnik.

Funkcionalnosti odjemalca so naslednje:


46

pošiljanje parametrov na strežnik,

prikaz izpisa (dokumenta) na strani odjemalca,

prijava novih glav ter nog dokumentov, ki jih lahko uporabimo na izpisu,

možnost izbire različnih glav ter nog,

tiskanje dokumentov,

izvoz oziroma shranjevanje dokumentov in

možnost izbire različnega tipa pregledovalnika izpisov.

Strežnik

Glavna naloga strežnika je sprejemanje podatkov, ki jih pošilja odjemalec. Iz prejetih podatkov

mora ustvariti ustrezen izpis in le-tega prikazati oziroma poslati odjemalcu. Naštejmo vse

funkcionalnosti strežnika:

podpora več firmam (Nastavitev ustrezne povezave v podatkovno bazo glede na tip

"multifirm"),

sprejemanje parametrov iz odjemalca ter prireditev parametrov izpisu,

dinamična zamenjava pregledovalnika glede na prejete parametre (npr. PDF, ActiveX,

HTML),

podpora za avtomatsko prevajanje izpisov in

kreiranje izpisa.

Urejevalnik

Urejevalnik izpisov omogoča uporabniku izdelovanje in oblikovanje lastnih izpisov, oziroma

spreminjanje že obstoječih. Omogočeno naj bo tudi generiranje datotek XML, ki so potrebne za

prevajanje dokumentov. Funkcionalnosti urejevalnika so:

avtomatsko generiranje skripte ob dodajanju pod-izpisov,

grafični vmesnik za prenos parametrov iz glavnega izpisa na pod-izpis,

avtomatska namestitev urejevalnika in

podpora avtomatskemu generiranju datotek XML za prevajanje izpisov.

4.3 Glavni testni načrt (GTN)

Na osnovi dokumenta SZPO začnemo z načrtovanjem testiranja. Najprej smo napisali

glavni testni načrt, kjer smo opisali strategijo oziroma pristop k testiranju. Zapisali smo


47

funkcionalnosti, ki jih bomo, in tiste, ki jih ne bomo testirali. Našteli smo še preizkusna

orodja, ki jih bomo uporabili.

Pomembnejše poglavje načrta GTN je točka 7, in sicer Pristop/strategija. Tukaj v

grobem opišemo posamezen nivo testiranja, določimo, kako bomo vodili spremembe ob

napakah, kdaj bomo začeli s testiranjem, kdo bo testiral itd. Sledijo določeni izseki iz

glavnega testnega načrta.

Točka 7 Pristop/strategija

Programske napake razdelimo po pomembnosti na naslednje štiri kategorije:

1. nepomembna: je estetske narave (zamaknjen izpis),

2. nadležna: napačna opozorila, majhne napake v kodiranju, odvečna koda ipd.,

3. resna: zavrača dovoljene posege (bankomat zavrne veljavno kartico),

4. ekstremna: izgubljanje podatkov.

Vsaki odkriti programski napaki pripišemo eno izmed teh kategorij. Glede na izhodne kriterije

posameznega nivoja, nadaljujemo s testiranjem. Če je pomembnost odkrite napake prevelika,

potem napako odpravimo in ponovimo testni primer, pri katerem je do napake prišlo. Preizkušanje

izvajamo ročno, kar pomeni, da sami vnašamo, spreminjamo podatke in opazujemo odziv

aplikacije. Za preizkušanje bomo uporabljali testno metodologijo STEP.

Točka 7.1 Nivoji testiranja

Točka 7.1.1 Testiranje enot

S testiranjem enot bomo preizkusili posamezne komponente programa, vključno z njihovimi

funkcionalnostmi. Testirali bomo po metodi črne in bele škatle. Pri metodi črne škatle bomo

preizkusili delovanje programa tako pri pravilnih kot pri nepravilnih vhodih za posamezne funkcije.

Metoda bele škatle pa bo pokazala strukturno pravilnost programa.

Testiranje enot bodo izvajali razvijalci sistema. Vsak testni primer mora vsebovati korake

preizkušanja in testne primere. S testiranjem enot bomo zaključili, ko bomo dosegli naslednji

izhodni kriterij:

vsi testi enot morajo biti dokumentirani,

skupno lahko imajo vse enote maksimalno 3 nepomembne in 2 nadležni napaki.

Zaključek testiranje enot določi vodja razvijalcev po pregledu izhodnega kriterija in dobljenih

rezultatov testiranja.


48

Točka 7.1.2 Integracijski test

Nove module dodajamo v sistem in testiramo postopoma. Kot rezultat te integracije dobimo sistem,

ki je pripravljen za sistemsko testiranje. Najprej bomo razvili in integrirali module z visoko prioriteto,

zatem pa bomo dodajali še module z nižjimi prioritetami. Pri integracijskem testiranju bomo

uporabili pristop od zgoraj navzdol. Če modul z nižjim nivojem še ni razvit, ga bomo v sistemu

simulirali. Podobno kot pri testiranju enot, tudi tukaj ustvarimo ustrezne testne primere, ki jih zatem

še dokumentiramo. Test opravijo razvijalci posameznih modulov. Izhodni kriterij tega testa je

definiran kot:

vsi testi integracije morajo biti dokumentirani,

sistem lahko ima maksimalno 4 nepomembne oziroma nadležne napake,

vsak dodan modul mora imeti enega ali več testnih primerov in

z enim testnim primerom preizkušamo zgolj integracijo med dvema izbranima

moduloma.

Točka 7.1.3 Sistemski test

S sistemskim testiranjem začnemo, ko je izpolnjen izhodni kriterij integracijskega testiranja. Namen

tega testa je, da preverimo, če delujejo vse funkcionalnosti, ki so bile zapisane v dokumentu SZPO.

V okviru sistemskega testiranja bomo ob funkcionalnem preizkušanju izvedli še zmogljivostni test.

Podjetje nima posebnega testnega oddelka, zato bodo preizkuse izvedli kar razvijalci sami. Vse

testne primere zapisujemo v dokument testnih primerov. Preizkušamo po metodi črne škatle.

Postavili smo naslednji izhodni kriterij:

program lahko ima največ 2 nepomembni in 1 nadležno napako in

vsaka funkcionalnost mora biti preizkušena najmanj z enim testnim primerom.

Točka 7.1.4 Test sprejemljivosti

Test sprejemljivosti bodo opravili končni uporabniki produkta, in sicer komercialisti in analitiki

podjetja Comtron d.o.o. Test sprejemljivosti se bo začel izvajati od dva do tri dni po uspešno

končanem sistemskem preizkušanju. Pri tem preizkušanju pomaga tudi razvijalec produkta.

Testiranje se bo izvedlo v realnem okolju z realnimi podatki na računalnikih končnih uporabnikov.

Zaradi večje sistematičnosti si bomo pomagali s potrditveno matriko zahtev. Cilj tega preizkušanja

je prepričati uporabnika, da so vse uporabniške zahteve v programskem sistemu izpolnjene.

Uporabniki izvedejo neformalni preizkus po metodi črne škatle. Definiramo naslednji izhodni kriterij:

vsaj en testni primer mora biti pravilen za vse zahteve in

ob zaključku testa sprejemljivosti lahko ima program samo dve nepomembni napaki.


49

Točka 7.2 Vodenje sprememb in testno okolje

Za razvoj in testiranje posameznih modulov imamo na voljo dva strežnika. Na razvojnem strežniku,

kjer so pripravljeni testni podatki in je nameščen obstoječ produkt TIC, opravimo test enot in

integracijski test. Nato naš programski sistem prestavimo na drug strežnik, kjer je prav tako

nameščena zadnja verzija obstoječega produkta TIC. Po uspešno opravljenem sistemskem testu

prestavimo naš produkt iz tega strežnika na računalniške strežnike strank. V produkcijskem okolju

nato izvedemo še test sprejemljivosti.

Če pride v času sistemskega testiranja na t.i. strežniku verzije (tj. strežnik, kjer se nahaja

zadnja verzija obstoječega produkta TIC) do napake, le-to najprej odpravimo na razvojnem

strežniku. Zatem v programskem orodju ibug – tj. lasten produkt podjetja Comtron d.o.o. –

zabeležimo spremembe. Vnesti moramo predvsem podatke o popravljenem modulu in kakšne

napake smo odpravili. Če je napaka kritična, jo takoj prenesemo na strežnik z verzijo in ponovimo

testiranje. Če napaka ni kritična, kar pomeni, da ne preprečuje nadaljevanje izvajanja testiranja na

strežniku verzije, se o prenosu popravljenega modula iz razvojnega strežnika na strežnik verzije

dogovorimo z vodjo projekta. Ob vsaki odkriti napaki ponovimo zgoraj opisani postopek vodenja

spremembe.

4.4 Podrobni testni načrti

Podrobni testni načrti imajo podobno strukturo kot glavni testni načrt, le da sestojijo iz

detajlnejših informacij. Podrobne testne načrte napišemo v obratnem vrstnem redu, kot jih

dejansko izvajamo. Splošne dejavnike posameznih testnih nivojev smo ţe opisali v

glavnem testnem načrtu, zato podrobnih testnih načrtov ne bomo opisovali.

4.5 Izvajanje preizkušanja

Ko so načrti preizkušanja pripravljeni in aplikacija implementirana (ali vsaj nekaj njenih

modulov), pričnemo z izvajanjem preizkušanja, in sicer v naslednjem vrstnem redu:

1. test enot,

2. test integracije,

3. sistemski test in

4. test sprejemljivosti.


50

Rezultat izvajanja teh preizkusov so naslednji dokumenti:

načrt izvajanja testiranja,

dokument o testnih primerih,

dokument s testnimi procedurami,

dnevnik testiranja in

dokument s povzetkom testiranja.

V dokumentu načrt izvajanja testiranja identificiramo, katero funkcionalnost bomo

testirali. Definiramo potrebne testne primere za to funkcionalnost ter izhodne kriterije.

Testni primeri so pravzaprav jedro samega testiranja, saj podrobno opisujejo, kaj bomo

izvajali in katere funkcionalnosti bomo s tem pokrili. V dokumentu o testnih primerih za

vsak testni primer zapišemo:

vhode,

izhode,

zahtevano okolje pri testiranju in

medsebojne odvisnosti testnih primerov.

V dokumentu s testnimi procedurami podrobno opišemo postopek izvajanja testiranja za

posamezen testni primer.

Zaradi nezahtevnosti našega projekta in večje preglednosti, smo dokument načrt

izvajanja testiranja, dokument o testnih primerih in dokument s testnimi procedurami

zdruţili v skupen dokument. Sledi nekaj testnih primerov iz našega dokumenta.

4.5.1 Testni primeri za test enot

V nadaljevanju podajamo nekaj testnih primerov, uporabljenih pri testiranju enot. Z njimi

ţelimo demonstrirati pravilno delovanje posamezne enote, za katero je programer po

pregledu kode ocenil, da pravilno deluje. Vsak testni primer je prikazan v svoji tabeli.


51

a) Streţnik - osnovni modul

TESTNI PRIMER 7 – Interno shranjevanje izpisa

FUNKCIJA - CurrentRptSave

Testna Procedura 1:

Podamo vse vhodne parametre:

1. izpis,

2. pot shranjevanja,

3. ime datoteke.

Testna Procedura 2:

Isto kot testna procedura 1,

vendar tokrat poskuša isti izpis

shraniti več uporabnikov hkrati.

Pričakovan rezultat:

Testna Procedura 1:

Shranjen izpis.

Testna Procedura 2:

Shranjen izpis.

Rezultat testa:

Testna Procedura 1:

OK

Testna Procedura 2:

NAPAKA:

izpis se ne shrani.

3-Resna

Izhodni kriterij: Vsi testni primeri morajo biti uspešni.

Opomba: Napaka se pojavi, ker hoče do datoteke naenkrat dostopati več procesov.

Napako odpravimo tako, da skušamo dokument večkrat shraniti (v več časovnih

intervalih). To počnemo tako dolgo, dokler nam ne uspe, oziroma po 15 poskusih

javimo napako.

Popravljena programska koda: while (shranjeno != true && stevecIOError <= 15)

{

try

{

current.SaveLayout(@"" + WorkPath + ReportNameSave);

shranjeno = true;

}

catch (IOException e)

{

//če nam ne uspe shranit zaspimo

stevecIOError++;

Thread.Sleep(2000);

}


52

TESTNI PRIMER 6 – Pridobivanje seznama izpisov, ki jih je treba prevesti

FUNKCIJA - make_Translation_list

Testna Procedura 1:

Izberemo takšen izpis, ki ga je

potrebno prevajati. To pomeni, da

izberemo takšen "LanguageID", ki

je različen od trenutnega na izpisu.

Testna Procedura 2:

"LangugageID" enak tistemu na

izpisu.

Testna Procedura 3:

Izberemo takšen izpis, katerega

pod-izpis je potrebno prevajati.


Testna Procedura 1:

Seznam z imenom

datoteke prevedenega

izpisa.

Testna Procedura 2:

Prazen seznam.

Testna Procedura 3:

Ime pod-izpisa, se mora

pojaviti v seznamu.

Rezultat testa:

Testna Procedura 1:

OK

Testna Procedura 2:

OK

Testna Procedura 3:

OK


b) Streţnik - dodatni modul za prevajanje

TESTNI PRIMER 10 – Branje in nalaganje prevodov iz datoteke XML v strukturo

FUNKCIJA - RetrieveLocalizationResources(DataDynamics.ActiveReports.ActiveReport3

rpt, String TranslationFile,String WorkPath)

Testna Procedura 1:

Pravilno podamo vse naslednje

parametre

- izpis,

- datoteka XML,

- delovna mapa.

Testna Procedura 2: Podamo nepravilne parametre.


Testna Procedura 1:

Funkcija ustrezno prebere

prevode in zgradi strukturo XmlDocument.

Testna Procedura 2:

Če parametri niso pravilni,

program ne sme javiti

ničesar, struktura pa se ne

sestavi.

Rezultat testa:

Testna Procedura

1:

NAPAKA:

odvečen parameter

izpis.

2-nadleţna

Testna Procedura

2:

OK


Opomba: Funkcija ima nepotreben parameter, tj. izpis, ki ga odstranimo iz funkcije.


53

TESTNI PRIMER 11 – Prirejanje prevodov iz strukture XML k izpisu

FUNKCIJA - Localize(DataDynamics.ActiveReports.ActiveReport3 rpt, String LanguageID,String TranslationFile,String WorkPath)

Testna Procedura 1:

Vse parametre podamo pravilne:

- izpis,

- "LanguageID",

- "ReportNamePrevedi",

- "WorkPath".

Preverimo direktno na izpisu, če se

je le-ta prevedel.

Testna Procedura 2: "LanguageID" podamo takšen, da v

datoteki XML ne obstaja.

Testna Procedura 3:

Ne podamo pravilno nobenega

parametra.


Testna Procedura 1:

Funkcija ustrezno prevede

izpis.

Testna Procedura 2:

Nepreveden izpis.

Testna Procedura 3:

Program ne sme javiti

nobene napake, le izpis se

ne prevede.

Rezultat testa:

Testna Procedura 1:

NAPAKA: v prevodu

ni šumnikov.

4-ekstremna

Testna Procedura 2:

OK

Testna Procedura 3:

OK


Opomba: Popraviti je potrebno urejevalnik izpisov, kjer kreiramo prevode, saj le-ta ne

shrani datoteke XML v kodiranju UTF-8.

c) Odjemalec

TESTNI PRIMER 12 – Sestavljanje podatkov v ustrezen zakodiran niz URL

FUNKCIJA - sestavi_postdata

Testna Procedura 1:.

Podamo prazen seznam podatkov

ter pravilne fiksne parametre.


Kot testna procedura 1, le da

dodamo še seznam podatkov.



Ustrezen niz podatkov

fiksnih parametrov v obliki

Ime_Param1=vrednost1&

Ime_Param2=vrednost2 .


Ustrezen niz podatkov s

fiksnimi in dinamičnimi

podatki (iz seznama).

Rezultat testa:

Testna Procedura 1:

OK

Testna Procedura 2:

NAPAKA:

izgubljanje podatkov.

4-ekstremna


Opomba: Med fiksnimi in dinamični parametri ni znaka &. Kodo popravimo tako, da ta

znak dodamo na koncu niza dinamičnih parametrov.


54

TESTNI PRIMER 13 – Nastavljanje naslova streţnika

FUNKCIJA - load_webbrowser

Testna Procedura 1:

Podamo:

- prazen "ServerPort" in

- pravilen "ServerIP", ki se nahaja

v nastavitvah XML.

Testna Procedura 2:

Podamo prazen "ServerIP" in

pravilen "ServerPort".


Testna Procedura 1:

Pravilen naslov IP streţnika,

ki se prebere iz nastavitev

XML.

Testna Procedura 2:

Pravilen naslov, ki se sestavi

iz TicLogin naslova IP in

"ServerPorta", ki se prebere

iz nastavitev XML.

Rezultat testa:

Testna Procedura 1:

OK

Testna Procedura 2:

OK


TESTNI PRIMER 16 – Shranjevanje podatkov za obrazec in pregledovalnik v register

FUNKCIJA - SaveControls

Testna Procedura 1:

Nastavimo parametre:

- "header",

- "footer",

- naslov obrazca in

- ID obrazca.

Te vrednosti primerjamo z

vrednostmi v registrih.


Testna Procedura 1:

Enake vrednosti zapisane v

register.

Rezultat testa:

Testna Procedura 1:

OK



55

4.5.2 Testni primeri za integracijski test

a) Odjemalec-streţnik

TESTNI PRIMER 14 – Pošiljanje podatkov iz odjemalca na streţnik

FUNKCIJA - load_webbrowser(odjemalec) in Nastavi_Fiksne_param(strežnik)

Testna Procedura 1: S pomočjo kontrolnika "navigate

webbrowser" navigiramo in

pošljemo podatke na streţnik, kjer

izpišemo celoten seznam

"Request.Form". Prejete podatke na

streţniku primerjamo s poslanimi.



Enaka imena in vrednosti

parametrov na streţniku in

odjemalcu.

Rezultat testa:

Testna Procedura 1:

NAPAKA: na

streţniku ni posebnih

znakov.

4-ekstremna


Opomba: V prejetih podatkih na streţniku ni šumnikov, presledkov in ostalih posebnih

znakov. Preden pošljemo niz, ga moramo zakodirati. Pomagamo si s pomočjo kodirne

tabele URL. Dodana programska koda: paramColl(i).Value = Replace(paramColl(i).Value, "+", "%2B", 1, , vbBinaryCompare)

paramColl(i).Value = Replace(paramColl(i).Value, " ", "%20", 1, , vbBinaryCompare)

paramColl(i).Value = Replace(paramColl(i).Value, "[", "%5B", 1, , vbBinaryCompare) paramColl(i).Value = Replace(paramColl(i).Value, "]", "%5D", 1, , vbBinaryCompare)

paramColl(i).Value = Replace(paramColl(i).Value, "&", "%26", 1, , vbBinaryCompare)

paramColl(i).Value = Replace(paramColl(i).Value, "š", "%C5%A1", 1, , vbBinaryCompare)

paramColl(i).Value = Replace(paramColl(i).Value, "Š", "%C5%A0", 1, , vbBinaryCompare)

paramColl(i).Value = Replace(paramColl(i).Value, "č", "%C4%8D", 1, , vbBinaryCompare)

paramColl(i).Value = Replace(paramColl(i).Value, "Č", "%C4%8C", 1, , vbBinaryCompare)

paramColl(i).Value = Replace(paramColl(i).Value, "Ţ", "%C5%BD", 1, , vbBinaryCompare)

paramColl(i).Value = Replace(paramColl(i).Value, "ţ", "%C5%BE", 1, , vbBinaryCompare)


56

b) Modul za nastavitev povezave v podatkovno bazo – streţnik

TESTNI PRIMER 15 – Nastavitev ustrezne povezave v bazo glede na tip multifirm-a

FUNKCIJA - nastavi_connection_string(strežnik) in konstruktor DSN.ConnectionString (DSN.dll)

Testna Procedura 1:

V konstruktor razreda

DSN.ConnectionString,

pošljemo pravilna oba

podatka "FirmID" in

"DatabaseName".

Testna Procedura 2:

Pošljemo nepravilno

"DatabaseName" (npr.

številke) in pravilen

"FirmID."

Testna Procedura 3:

Pošljemo pravilen

"DatabaseName" in

nepravilen "FirmID".


Testna Procedura 1:

Pravilen povezovalni niz za

povezavo v bazo.

Testna Procedura 2:

Obvestilo uporabniku o

neustreznem parametru

"DatabaseName".

Testna Procedura 3:

Obvestilo uporabniku o

nepravilnem parametru

"FirmID".

Rezultat testa:

Testna Procedura 1:

OK

Testna Procedura 2:

NAPAKA: obvestila ni.

2-nadleţna

Testna Procedura 3:

NAPAKA: obvestila ni.

2-nadleţna


Opomba: Nastavljanje povezave je bilo brez blokov "try-catch", zato dodamo

naslednjo kodo: try

{

DSN.ConnectionString nov = new

DSN.ConnectionString(System.Convert.ToInt32(FirmID), DatabaseName);

((SqlDBDataSource)rpt.DataSource).ConnectionString =

nov.ConnectionString;

}

catch (Exception err)

{

Response.Write("<h1><font color=red > Prišlo je do napake

pri nastavljanju povezave v bazo. Eden od parametrov DatabaseName: "

+ DatabaseName + " ali FirmID: " + FirmID + " ni pravilen </h1>" +

"StackTrace: " + err.Message);

WebViewer1.Visible = false;

}


57

4.5.3 Testni primeri za sistemski test

a) Testiranje funkcionalnosti

1. Predogled

TESTNI PRIMER 17 – Predogled izpisa

OPIS TESTNEGA PRIMERA - Po kliku na gumb "Osveţi" oziroma gumb "Izpis", se

mora zgenerirati in prikazati izpis.

Vhod:

1. v urejevalniku dokumentov izberemo dokument in kliknemo ikono predogled

izpisa,

2. na odjemalcu kliknemo gumb "Izpis" ali gumb "Osveţi",

3. koraka 1 in 2 ponovimo z več različnimi tipi dokumentov.


Generiranje izpisa traja nekaj časa, ko je izpis zgeneriran se prikaţe.

Rezultat testa:

OK

2. Izvoz

TESTNI PRIMER 18 – Izvoz izpisa

OPIS TESTNEGA PRIMERA - Po kliku na gumb "Izvozi izpis" se odpre dialog, kjer

izberemo, ali bomo dokument shranili ali odprli.

Vhod:

1. na odjemalcu kliknemo ikono za izvoz,

2. izberemo enega od moţnih formatov, in sicer izbiramo med formati PDF, WORD,

TIFF, TXT in EXCEL,

3. odpremo izpis,

4. ponovimo koraka 1 in 2, pri čemer shranimo izpis na disk,

5. ponavljamo korake 1 do 4, dokler ne preizkusimo vseh formatov.


Generiranje izpisa traja nekaj časa. Nato se pojavi dialog, kjer lahko izpis odpremo ali pa

ga shranimo.

Rezultat testa:

OK


58

3. Avtomatsko prevajanje izpisov

TESTNI PRIMER 22 – Avtomatsko prevajanje izpisov

OPIS TESTNEGA PRIMERA - izpis pokličemo iz drugega modula, kjer ni nastavitev

za jezik.

Vhod:

1. v prijavnem dialogu (login) produkta TIC nastavimo jezik na EN (angleški jezik),

2. v modulu QueryReport2 izberemo "Izpis" in kliknemo ikono za predogled,

3. odpre se odjemalec, kjer kliknemo gumb "Izpis".


Izpis se mora prevesti v angleški jezik.

Rezultat testa:

NAPAKA: izpis se ne prevede. 3-resna

Opombe:

Izpis se ne prevede, ker nismo pridobili parametra "LanguageID" iz modula TicLogin.

Ustrezno popravimo odjemalca na razvojnem streţniku, napako pa zabeleţimo v produkt

iBug.

b) Testiranje zmogljivosti

TESTNI PRIMER 26 – Zmogljivost streţnika

OPIS TESTNEGA PRIMERA – Poţenemo izpis, ki več različnih dokumentov zdruţi v

skupnega.

Vhod:

1. V obstoječem produktu TIC, kamor smo integrirali našo aplikacijo za izpise,

najprej s pomočjo modula listanje dokumentov izberemo tip dokumenta račun

(RAC),

2. nato izberemo še časovno obdobje, v katerem je 190 dokumentov,

3. v našem odjemalcu za izpise nato kliknemo na gumb "Izpis".


Vsi dokumenti se zgenerirajo in zdruţijo v skupni izpis.

Rezultat testa:

Zgenerira se vseh 190 dokumentov OK

Število strani skupnega dokumenta: 780 OK

Skupen čas:15 min OK

Čas/dokument: 4,7s/dokument OK

Pomnilnik streţnika: NAPAKA: po nekajkratnem ponovljenem poskusu zasedata server

SQL in streţnik za izpise ves pomnilnik. 3-resna

OPOMBA: Po preučitvi dokumentacije izpisov "Active Reports", naj bi pomnilnik bil

zaseden le navidezno. Kljub tem pa na streţniku preventivno kličemo modul za

pospravljanje pomnilnika (angl. garbage collector). Ob tem še pregledamo obstoječe

izpise in na koncu vsakega uničimo objekte. Po ponovnem preizkušanja zgoraj navedenih

teţav nismo več zaznali.


59

4.5.4 Testni primeri za test sprejemljivosti

Za test sprejemljivosti uporabimo iste testne primere kot pri sistemskem testiranju. Edina

razlika je v tem, da tukaj ne opravimo testa zmogljivosti. V nadaljevanju bomo predstavili

le tisti testni primer, pri katerem so končni uporabniki odkrili programsko napako, med

tem ko sistemski test te napake ni odkril.

TESTNI PRIMER 20 – Tiskanje

OPIS TESTNEGA PRIMERA - Tiskanje izpisa s predogledom dokumenta

Vhod:

1. v urejevalniku dokumentov izberemo dokument in kliknemo na ikono za

predogled,

2. na odjemalcu kliknemo gumb "Izpis" oziroma "Osveţi",

3. po prikazu izpisa, aktiviramo tiskanje s klikom na ikono tiskalnik.


1. Dokument se uspešno natisne na privzeti tiskalnik, odjemalec pa nas obvesti, koliko

strani je natisnil.

Rezultat testa:

NAPAKA: dokument se ne natisne. 3-resna

Opomba:

Odjemalec nas obvesti o uspešnosti tiskanja, vendar se dokument na tiskalniku ne natisne.

Ugotovimo, da se kontrola ActiveX, ki je potrebna za tiskanje na računalnikih, kjer

uporabniki nimajo administratorskih privilegijev, ne namesti. Prav tako se pojavijo

problemi, če nastavitve v spletnem brskalniku (npr. Internet explorer) ne dovoljuje

izvajanje skript. Implementiramo avtomatsko namestitev kontrolnika ActiveX, če se

morebiti ţe ni ob zagonu odjemalca. Nazadnje aţuriramo še vrednosti v registru, s čimer

dovoljujemo izvajanje skripte našega produkta. Ustrezno popravimo odjemalca na

razvojnem streţniku, napako pa vnesemo v produkt iBug. Ta test ponovno poţenemo.

4.5.5 Dnevnik testiranja

Med izvajanjem testnih primerov pišemo dnevnik testiranja. Le-ta sluţi predvsem kot

obvestilo nadrejenim o napredovanju oziroma poteku testiranja. V nadaljevanju sledi izsek

iz tega dokumenta.


60

Opis: sistemski test – testiranje

funkcionalnosti

Datum: 03/06/2008

ID Čas Aktivnosti in dogodki

1 08:20 Začetek testiranja predogleda (Testni primer 17 - TP17)

2 09:00 Testiranje izvoza izpisa (TP18)

3 10:00 Testiranje tiskanja (TP20)

4 10:30 Avtomatsko prevajanje izpisov (TP22)

5 10:50 Napaka: izpis se ne prevede

6 12:00 Odprava napake, ponoven zagon testnih primerov:

TP17, TP18,TP20, TP22.

7 14:00 Testiranje obrazcev (TP23)



Opis: sistemski test - testiranje

obremenitve/zmogljivosti

Datum: 04/06/2008


1 08:05 Zagon testiranja zmogljivosti (TP26)

2 9:00 Ponavljanje testnega primera TP26

3 12:00 Napaka: pomnilnik strežnika zaseden 90 %

4 15:00 Odprava napake

5 15:05 Ponoven zagon testa

6 16:30 Test zmogljivosti uspešno zaključen

Opis: test sprejemljivosti Datum: 5/06/2008


1 8:00 Ponovitev testnih primerov sistemskega preizkušanja pri

končnih uporabnikih

2 11:00 Odkrita napaka pri testnem primeru TP20

3 12:00 Odkrita napaka pri testnem primeru TP17

4 13:00 Raziskovanje in odpravljanje napake


61

Opis: test sprejemljivosti Datum: 6/06/2008


1 8:00 Raziskovanje in odpravljanje napake odkrite pri testnih

primerih TP20 in TP17

2 15:00 Ponovitev testnih primerov TP17n TP20 pri končnih

uporabnikih

3 16:30 Test sprejemljivosti uspešno zaključen

4.5.6 Dokument s povzetkom testiranja

Po končanem izvajanju preizkušanja analiziramo rezultate in napišemo dokument s

povzetkom testiranja. Ta dokument mora vsebovati povzetek testnih aktivnosti, oceno

učinkovitosti testiranja, odpravljene ter neodpravljene napake, poznane nepravilnosti

programa ipd. Predlogo poročila smo povzeli po standardu IEEE 829-1998. Zgradba

dokumenta je naslednja:

1. Identifikator poročila s povzetkom testiranja,

2. Povzetek,

3. Odstopanja,

4. Pokritost in učinkovitost preizkušanja,

5. Povzetek rezultatov testiranja,

5.1 Odpravljene napake,

5.2 Neodpravljene napake,

6. Ocena,

7. Statistika aktivnosti testiranja,

8. Odobritev dokumenta s povzetkom.

V nadaljevanju bomo predstavili le najpomembnejše točke tega dokumenta.

Točka 4. Pokritost in učinkovitost preizkušanja

Preizkusili smo praktično vse funkcionalnosti, ki smo jih navedli v glavnem testnem načrtu.

Za ugotavljanje učinkovitosti testiranja smo uporabili dva kriterija, in sicer:

zadovoljstvo strank in


62

odstotek odkritja napak.

a) Zadovoljstvo strank

Informacije glede zadovoljstva strank smo pridobili z analizo klicev v oddelek za podporo. Produkt

smo v začetni fazi namestili na 15 računalniških sistemov končnih uporabnikov. Klice v oddelek za

podporo smo spremljali tri tedne. V treh tednih smo v tem oddelku prejeli le dva klica, ki sta bila

neposredno povezana z našim produktom. Če primerjamo to število s številom klicev, ki smo jih

prejemali pri prejšnjem sistemu za izpise, lahko ugotovimo, da so stranke neprimerno bolj

zadovoljne z našim novim produktom.

b) Odstotek odkritja napak

Odstotek odkritja napak smo izračunali po naslednji formuli:

O=A/(A+B)*100,

kjer je O odstotek odkritih napak, A je število napak odkritih pri testiranju in B je število neodkritih

napak. V našem primeru je število odkritih napak enako 14, število neodkritih napak pa smo ocenili

z 2. Odstotek odkritja napak torej izračunamo kot (14/14+2)*100, kar pomeni, da je odstotek

odkritja napak 87,5 %.

Točka 5. Povzetek rezultatov testiranja

Točka 5.1 Odpravljene napake

Testni primer/testna

procedura

Opis napake Odprava napake Ocena

napake

TP11/1 - Prirejanje

prevodov iz strukture

XML k izpisu.

Ni šumnikov.

Popraviti je potrebno urejevalnik

izpisov, kjer kreiramo prevode, saj le-

ta ne shrani datoteke XML v kodiranju

UTF-8.

4

TP15/2,3 - Nastavitev

ustrezne povezave v

bazo glede na tip

multifirm-a.

Ni obvestila

uporabniku o

nepravilnem

parametru.

Nastavljanje povezave je bilo brez

blokov "try/catch", zato jih dodamo.

2


63

TP22 - Avtomatsko

prevajanje izpisov.

Izpis se ne

prevede, ker

nismo dobili

parametra

"LanguageID".

"LanguageID" pridobimo iz prijavne

maske (login) produkta TIC.

3

TP14 - Pošiljanje

podatkov iz odjemalca

na strežnik.

Na strežniku ni

šumnikov,

presledkov in

ostalih

posebnih

znakov.

Preden pošljemo niz, ga je potrebno

zakodirati v format URL. Pri tem si

pomagamo s kodirnimi tabelami URL.

4

TP12/2 - Sestavljanje

podatkov v ustrezen

zakodiran niz URL.

Niz podatkov,

ki ga pošljemo

na strežnik, ni

pravilen.

Med fiksnimi in dinamični parametri ni

znaka &. To popravimo tako, da ta

znak dodamo na konec niza

dinamičnih parametrov.

4

TP 20 - Tiskanje

Odjemalec

nas obvesti o

uspešnosti

tiskanja,

vendar se

dokument na

tiskalniku ne

natisne.

V register vnesemo vrednosti, ki

dovoljujejo izvajanje naši skripti za

tiskanje.

3

TP26 - Zmogljivost

strežnika.

Strežnik SQL

in strežnik za

izpise

zasedata ves

pomnilnik.

Na strežniku preventivno kličemo

modul za sproščanje pomnilnika

(garbage collector). Pregledamo še

obstoječe izpise in na koncu vsakega

uničimo objekte. Po ponovnem

preizkusu teh težav ni več.

3

TP7/2 - Interno

shranjevanje izpisa.

Dostop do

datoteke ni

možen (File

Access

denied).

Napako odpravimo tako, da skušamo

dokument večkrat shraniti (v več

časovnih intervalih). To počnemo tako

dolgo, dokler nam ne uspe, oziroma

po 15 poskusih javimo napako.

3


64

Točka 6. Ocena

Iz tabele 7 je razvidno, da smo uspešno zadovoljili izhodne kriterije vseh nivojev testiranja in tako

uspešno opravili preizkušanje aplikacije za izpisovanje dokumentov. Edina napaka, ki je nismo

uspeli odpraviti (tj. v pregledovalniku se pojavi dvojni drsnik pri nekaterih strankah), je estetske

narave in se je pojavila v času testa sprejemljivosti. Razlog, da smo jo odkrili šele v testu

sprejemljivosti je, da smo le v testu sprejemljivosti imeli na voljo dejansko produkcijsko okolje, kjer

se je ta napaka manifestirala.

Faza

testiranja

Izhodni kriterij

(število napak)

Število napak

(odpravljenih)

Število napak

(neodpravljenih) Rezultat

Test Enot Skupno lahko imajo vse enote maksimalno 3 nepomembne in 2 nadležni napaki.

1 nepomembna

1 nadležna

1 resna

2 ekstremni

0 OK

Integracijski

test

Sistem lahko ima

maksimalno 4

nepomembne oziroma

nadležne napake.

2 nadležni

1 ekstremna

0 OK

Sistemski test

Program lahko ima

največ 2 nepomembni

in 1 nadležno napako.

2 resni napaki 0 OK

Test

sprejemljivosti

Ob zaključku testa

sprejemljivosti lahko

ima program samo 2

nepomembni napaki

1 nadležna

1 resna

1 nepomembna

1 nepomembna OK

Skupaj 13 1

Tabela 7: Primerjava rezultatov testiranja in izhodnih kriterijev.

Poznana tveganja oziroma omejitve produkta

Še vedno se lahko pojavi problem pri direktnem tiskanju dokumentov, ki deluje preko spletne

skripte. Razlog za to tiči v varnostnih nastavitvah za spletni brskalnik (tj. internetni raziskovalec).

Četudi ta problem v spletnem brskalniku odpravimo, pa lahko ima stranka nameščene še dodatne

varnostne mehanizme (npr. programe), ki onemogočajo izvajanje spletnih skript.

Pozorni moramo še vedno biti na napako, ki smo jo odkrili pri zmogljivostnem testu sistema, in

sicer pri testnem primeru 26. Gre za problem, ko se po končanem predogledu izpisov pomnilnik ne

sprosti. V posameznem izpisu moramo zato, na koncu ustrezno uničiti vse objekte.


65

Točka 7. Statistika aktivnosti testiranja

Osebje: 5

Vključenih strank: 3

Število vseh uporabljenih računalnikov: 13

Vseh odkritih napak: 14

Število odpravljenih napak: 13

Število neodpravljenih napak: 1

Vseh napak, ki so jih odkrile stranke: 2

4.5.7 Ugotovitve

Uporaba testne metodologije in samo izvajanje testiranja je imelo ključno vlogo pri razvoju

aplikacije za tvorjenje izpisov oziroma poročil. S temi procesi smo dejansko dosegli naš

ţelen cilj, tj. razviti kakovosten programski produkt. S pomočjo testiranja smo odkrili

pomanjkljivosti oziroma programske napake v naši aplikaciji, še preden smo produkt

predali v uporabo strankam.

S pomočjo metodologije STEP smo odkrivali napake ţe v zgodnjih fazah razvoja

produkta, kar nam je vsekakor prihranilo ogromno časa in denarja. Slednjo trditev potrjuje

tudi popravljanje programske napake, ki se je pojavila pri testiranju sprejemljivosti (testni

primer 20). Ker je bila napaka odkrita v zelo pozni fazi razvoja, smo za njeno odpravo

porabili veliko več časa, kot za popravljanje ostalih napak.

Zaradi uporabe priporočil metodologije STEP smo k razvoju programske opreme

pristopili zelo sistematično. Ta metodologija namreč zahteva izdelavo več dokumentov,

kot sta, na primer, dokument specifikacije zahtev programske opreme (SZPO) in

programski načrt. Vso dokumentacijo, ki je nastala v razvoju, bomo lahko uporabili pri

testiranju naslednje verzije programa, s čimer se bo postopek testiranja še nekoliko pohitril.

Nastalo dokumentacijo bo moţno uporabiti tudi za izdelavo reklamnih materialov za našo

aplikacijo.

Skozi celoten proces testiranja je nastalo skupaj 82 strani dokumentacije, zbrane v

devetih dokumentih. Naštejmo dokumente:

dokument SZPO,

glavni testni načrt,


66

štirje podrobni testni načrti (tj. test enot, integracijski test, sistemski test in test

sprejemljivosti),

dokument o testnih primerih,

dnevnik testiranja in

dokument s povzetkom testiranja.

Ker smo metodologijo STEP uporabljali prvič, smo jo morali seveda natančno preučiti. Za

raziskovanje, načrtovanje, uvajanje, izvajanje in analiziranje testiranja smo porabili

ogromno časa – pribliţno 162 ur. V sam razvoj produkta (analiza, pridobivanje informacij,

načrtovanje, uvajanje in vzdrţevanje) pa je bilo vloţenega 150 ur dela. Za celoten projekt

smo tako porabili slabih 2 meseca dela, pri čemer je na projektu skupno sodelovalo 5 oseb

(del od njih je zaposlenih v podjetju Comtron d.o.o.). V testiranje smo vključili 3 stranke,

skupaj pa smo aplikacijo preizkusili na 13 računalniških sistemov.

Testiranje naše aplikacije ocenjujemo kot uspešno, saj smo dobili kakovostnejšo

aplikacijo za tvorjenje izpisov. Slednje potrjuje tudi večje zadovoljstvo strank z našo

aplikacijo, o čemer smo sklepali na osnovi majhnega števila klicev strank v oddelek za

podporo. S preizkušanjem smo dosegli tudi visok odstotek odkritja napak, ki je 87,5 %,

hkrati pa smo zadostili tudi vsem izhodnim kriterijem na vseh nivojih testiranja.


67

5 ZAKLJUČEK

Navkljub odlično razviti teoriji o preizkušanju programske opreme skozi celoten njen

razvoj, se danes v praksi še vedno največ preizkuša le ob koncu razvoja programske

opreme in to brez pisanja kakršnekoli testne dokumentacije. V tem diplomskem delu smo

to stanje analizirali, hkrati pa smo tudi identificirali vzroke, zakaj je temu tako.

Eden izmed razlogov za ne testiranje je zmotno prepričanje podjetij o preveliki porabi

časa za testne aktivnosti. Podjetja se ne zavedajo, da je čas, ki bi ga porabili za kakovostno

testiranje produkta skozi celoten ţivljenjski cikel, enak ali pa celo krajši od tistega, ki ga

porabijo za vzdrţevanje in odpravljanje napak na ne ali slabo preizkušenih programskih

produktih. Drug razlog vidimo v pomanjkanju strokovnjakov, ki bi imeli ustrezne izkušnje

na področju preizkušanja. Brez ustreznih izkušenj s preizkušanjem programske opreme se

je namreč zelo teţko pravilno odločiti o najprimernejši testni strategiji za izbran projekt, o

optimalnem številu nivojev preizkušanja, kateri dokumenti so ključni ipd. Naslednji

problem pa je tudi v tem, da razvijalci in drugo osebje nima nikakršne motivacije za

pisanje testne dokumentacije, ki je v praksi, to je treba priznati, kar obseţna. Za te in druge

testne aktivnosti, bi v podjetju morali imeti testni oddelek, ki bi ga seveda morali še

ustrezno motivirati.

Testiranje skozi celoten ţivljenjski cikel programske opreme se na kratek rok ne

izplača, saj ne daje ţelenih ekonomskih rezultatov. Zaradi zgoraj naštetih problemov (tj.

neizkušenosti, pomanjkanju osebja, časa in denarja) testiranje namreč ni učinkovito in se

zato ne izplača. Rešitev vidimo v tem, da bi v podjetju morali uporabljali določeno testno

metodologijo dalj časa, pri čemer bi razvili predloge za standardne dokumente, ob tem pa

bi vpeljali še lasten oddelek za testiranje. Tako bi skozi več let nabirali izkušnje, s čimer bi

vsekakor pridobili na hitrosti in učinkovitosti testiranja. Šele po takšnem pristopu bi se

začeli kazati ekonomski učinki.

V našem diplomskem delu smo v praksi preizkusili testno metodologijo STEP. Navzlic

zgoraj omenjenim problemom smo prepričani, da smo z uporabo testne metodologije STEP

izboljšali aplikacijo za izpis dokumentov. Uspešno smo odkrili programske napake, ki jih

najverjetneje pred izdajo programskega produkta sicer ne bi. S tem smo vsekakor zgradili

kakovostnejši izdelek. Ob testiranju je nastala testna dokumentacija, ki jo bomo lahko


68

uporabili pri razvoju in testiranju naslednje verzije programa. Na koncu naj še omenimo,

da je celotno preizkušanje zahtevalo 162 ur vloţenega dela. Skupaj z razvojem, ki je od nas

zahteval okrog 150 ur dela, smo tako za celoten projekt porabili pribliţno 2 meseca. V tem

procesu je nastalo 9 dokumentov oziroma 82 strani dokumentacije. V tem projektu je še

sodelovalo 5 oseb iz podjetja Comtron d..o.o. in trije končni uporabniki. Za razvoj in

preizkušanje smo uporabljali 13 računalniških sistemov. Ocenjujemo, da takšen vloţek v

preizkušanje ne sme pomeniti prevelik zalogaj (strošek) za podjetje.


69

VIRI, LITERATURA

[1] Slap model, Wikipedia, http://en.wikipedia.org/wiki/Waterfall_model

[2] J. E. Durant, Applying systematic testing to application development audits,

http://findarticles.com/p/articles/mi_m4153/is_n1_v48/ai_10380967/pg_1

[3] Software testing, Wikipedia, http://en.wikipedia.org/wiki/Software_testing

[4] IEEE standardi, http://www.ieee.org/portal/site

[5] R. D. Craig, S. P. Jaskiel, Systematic Softtware Testing, Artech House, 2002.

[6] D. Zazula, Preizkušanje računalniške opreme, Univerza v Mariboru, Fakulteta za

elektrotehniko, računalništvo in informatiko, Maribor, 2006.

http://en.wikipedia.org/wiki/Waterfall_model

http://findarticles.com/p/articles/mi_m4153/is_n1_v48/ai_10380967/pg_1

http://en.wikipedia.org/wiki/Software_testing

http://www.ieee.org/portal/site

Documents

PREIZKUŠANJE PROGRAMSKE OPREME Z UPORABO TESTNE ... · bomo tudi izseke iz dokumentacije, ki je pri takšnem testiranju nastala. Na koncu tega poglavja bomo analizirali učinkovitost