Strokovne razprave
Splošen koncept
načrtovanja testnih primerov
Tomaž Dogša cV&Vs Center za verifikacijo in validacijo sistemov Fakulteta ¿a elektrotehniku, računalništvo m informatiko Univerza v Mariboru, Smetanova 17, 2000 Maribor E-pošta: tdogsa@uni-mb.si
Izvleček
Učinkovito testiranje zmanjša skupne stroške načrtovanja in vzdrževanja ter omogoča objektiven pogled na kakovost programske opreme. V prispevku bomo prikazali enega izmed možnih splošnih konceptov načrtovanja testnih primerov, ki temelji na testirnem modelu. Za zgled smo izbrali dve preprosti in najpogosteje uporabljeni strategiji.
Abstract
,4/i effective testing reduces the costs of development and maintenance. At the same time it enables an objective view on software quality. In the paper we shall describe the general concepts of test case design based on testing models. We have illustrated this with two simple and most widely used strategies.
L Uvod
Testiranje programske opreme je še vedno ena izmed najdražjih aktivnosti, ki jih izvajamo v življenjskem ciklusu programskega produkta. Učinkovito testiranje zmanjša skupne stroške in omogoča objektiven pogled na kakovost programske opreme. S pojmom testiranje označujemo skupek naslednjih aktivnosti: načrtovanje testnih primerov, izvajanje programa {ali pa samo njegove komponente), opazovanje in beleženje rezultatov tega poganjanja ter njihovo vrednotenje glede na določen vidik (IEEE, 1990b]. V skupini teh aktivnosti je načrtovanje testnih primerov zagotovo ena izmed najzahtevnejših nalog.
Za sistematičen opis postopka načrtovanja testnih primerov obstaja več sinonimov. Myers goVori o metodologiji načrtovanja testnih primerov ([MY-ERS,1979j, str. 36), Beizer o ti stimi strategiji ¡RHI/1'R, 1990], Binder uporablja testirne Šablone {[BINDER, 2000], str, 338), mnogi drugi pa so zavzemajo za pojma: (estima metoda in testirna tehnika. V tem prispevku smo ne odločili za tes tirno strategijo.
I estni primer (test čase) je sestavljen i/ opisa vhodnih podatkov in pričakovanega obnašanja. Kakovosten testni primer mora biti učinkovit^ razumljiv in zagotovili mora ponovljivost. Učinkovitost je povezana z Verjetnostjo odkritja nepravilnosti. Razumljiv je takrat, ko ga lahko izvede oseba, ki ni avtor tega testnega primera. Ce so testni primeri zadostno razumljivi, je izvedba testa v večini primerov najenostavnejša aktivnost v celotnem testirnem procesu (več o opisovanju testnih primerov glej v [DQGŠA,1999,a]).
Načrtovanje testnih primerov poteka po podobnih korakih (lazah) kot načrtovanje programske opreme.
Mnogi testni primeri so v bistvu programi (testni skripti), s katerimi delno aH pa popolnoma avtomatiziramo nekatere testirne aktivnosti [DUSTIN,1999J; Ker se program med razvojem spreminja, je potrebno ustrezno prilagajati tudi testne primere. Podobno kot pri programski opremi lahko tudi tukaj govorimo o ttaČrtdvanju, implementaciji, preverjanju, uporabi in vzdrževanju testnih primerov.
S testiranjem nikakor ni mogoče dokazati odsotnosti napak ali pravilnost delovanja, saj bi zato potrebovali izredno veliko Število testnih primerov. Izjema so skrajno preprosti programi, katere lahko preskusimo z vsemi možnimi kombinacijami vhodnih podatkov. Kratke programe lahko tudi formalno verificiramo (matematično dokazovanje pravilnosti) in tako dokaže m o, da ne vsebujejo napak. S testiranjem lahko dokažemo samo: 1, prisotnost določene lastnosti in 2. prisotnost ene ali več napak.
Vsak testni primer je načrtovan z nekim namenom, Glede na vrsto namena jih lahko razdelimo v dve veliki skupni: skupina pozitivnih (clean test čase, pozitive test čase) in skupina negativnih testni h primerov (negative tesi rase, ti i rt y test čase). Namen pozitivnega testnega primera je dokazovanje prisotnosti določene lastnosti. Testni primer, s katerim npr. ugotavljamo, ali je sploh implementirana funkcija za izračun obresti, spada v skupino pozitivnih testnih priirtc-rov. Pozitivne testne primere je relativno enostavno načrtovati, Žal nas ne morejo prepričati o pravilnosti delovanja programa. Ker s testiranjem ni možno dokazati odsotnosti napak, je osnovni cilj testiranja dokazovanje njihove prisotnosti. Takim testnim primerom
2001 - številkah - letnik IX
nfnmiimu\ nfor m ati ka
romaž OogSa: Splošen koncept načrtovanja leslnih primerov
pravimo negativni testni primeri. Za učinkovito testiranje naj bo Število negativnih testnih primerov večje od pozitivnih (Beitzer priporoča razmerje 5:1 [BEITZER, 1995]),
V prispevku bomo prikazali splošen koncept načrtovanja testnih primerov, ki temelji na t os tirnem modelu. Pobudnika za ta novejši pristop sta predvsem Binder [BINDER,2000J in Beizer [BEIZER,1990J. V drugem poglavju bomo opisali pomen predpostavke o napaki ali nepravilnosti, ki je začetno izhodišče /a načrtovanje testnih primerov. Nato bomo opisali koncept testirnega modela in definirali osnovne zahteve za testi r no strategijo.
2. Predpostavka o napaki ali nepravilnosti
ideja testiranja je zelo preprosta: pre ve rje valeč vedno predpostavlja, da program vsebuje eno ali več napak Oziroma, da ima določene nepravilnosti. Ta predpostavka (hug assumption, fault assumption) je zelo pomembno začetno izhodišče /a načrtovanje testnih primerov. Obstoj te predpostavke je seveda samo-posebi umeven, saj če bi predpostavljali, da v programu ni nobenih napak, bi bilo testiranje nepotrebno1. Za ilustracijo je na siiki l prikazanih nekaj predpostavk.
1.	Program bo pomotoma sprejel negativno vrednost.
2.	V predikatu, ki se nahaja v odločitvenem stavku, je napaka.
3.	Izpis tabele so pozabili implementirati.
4.	Program ne bo deloval pravilno po letu 2000.
5.	Če bo indeks M = 0, se while zanka ne bo nikoli končala.
(i. Pri dolpeeni kombinaciji vhodnih podatkov bo program odpovedal.
Slika 1: Niz predpostavk o napakah alt nepravilnostih
Predpostavka o napaki ali nepravilnosti je v bistvu namen testnega primera. Pove, kaj želimo s testnim primerom dokazati. Zelo pogosto pretvorimo predpostavko v vprašanje, npr.: Ali je izpis tabele implementiran? S testnim primerom, ki izhaja i/ te predpostavke, lahko enostavno dokažemo, ali tabela je ali ni implementirana. Ne glede na i/id tega testa, dobimo
vedno nedvoumen odgovor. Ker je pravilna postavitev predpostavke in namena testnega primera zelo pomemben korak pri načrtovanju, bomo navedli Se nekaj napačnih oziroma neprimernih predpostavk. Npr.: 1. Namen testnega primera je preveriti pravilnost izračuna inflacije. 2. Namen testnega primera je ugotavljanje nepravilnosti. Kaj lahko sklepamo, če program testiramo in v prvem primeru ne odpove? Je brez napak? Kot smo že v uvodu opozorili, s testiranjem ni možno dokazati pravilnost, ampak samo prisotnost napak ali določenih lastnosti. Namen pri drugem zgledu je preveč splošen, saj vetja za vse testne primere. Če je namen testnega primera preveč splošen, ga bomo s težavo vzdrževali, Če uporabimo analogijo z razvojnim modelom programske Opreme, ima namen testnega primera enako vlogo kol jo imajo zahteve (requirements) za program.
Po izboru namena testnega primera sledi njegova implementacija. Najprej si napravimo kratek osnutek, katerega nato postopoma izdelamo do zadostnih podrobnosti, ki zagotavljajo ponovljivost in razumljivost. Najbolj pogosta metoda, ki se v tem koraku uporablja, je postopno izboljševanje.
Zgled2:
Namen testnega primera: Ali je izpis l a bele implementiran?
Osnutek: Izpišemo tabelo. Izboljšan 1. osnutek: Odpremo datoteko s podatki, zahtevamo izračun stroškov. Nastalo tabelo izpišemo. Izboljšan 2. osnutek: . . .
Opis testnega primera: Odpremo datoteko tesll.dat. V meniju Analiza zahtevamo izračun stroškov (opcija 7). Nastalo tabelo izpišemo (meni Tisk. opcija 2.
Pričakovani rezultat: Izpisana mora bili celotna tabela.
3. Testirni model
Analiza žalitev in postavitev specifikacij sta ena izmed najzahtevnejših faz v razvojnem ciklu programske opreme. Če so specifikacije pravilno zastavljene, postane implementacija v mnogih primerih rutinska zadeva. Analogno velja /a načrtovanje testnih primerov. Če je namen pravilno izbran in opisan, postane realizacija testnega primera rutinska zadeva, ki jp lahko izvede preverjevalčev pomočnik. I akoj vidimo, da je izbor namena testnega primera ključni problem, ki
1	Nekateri enačijo pojma analiza ter meritve in testiranje. Za (iste ta trditev seveda, ne velja. Če telimo samo ovrednotiti lastnosti nekega produkta, je to v bistvu samo anatha. ne pa testiranje. Če vrednotenju dodamo ie primerjavo i referenčnim podatkom, potem gnj ¿a testiranje.
2	Pri opisu testnega primere v prejšnjem zgledu smo zaradi preglednost prikazen le najnujnejše atribute.
i j;* mifinid nfo rm a tika
2ooi številka2-letnikix
Tomaí Dogša: Splošen koncepl načrtovanja tcstnili prtmerw
nastopa pri načrtovanju testnih primerov. Za rešitev tega problema si preverjevalci pomagajo z različnimi testirnimi modeli, IVstirni model je pripomoček, ki preverjevaicu pomaga določiti namen testnega primeril. V večini primerov je objekt, ki ga testiramo, zelo kompleksen. I estirni model je poenostavljen opis (ob našanja ali lastnosti) objekta (npr. programa), izpuščene so vse podrobnosti, katerih preverjevalec ne potrebuje. Pogosto so testirni modeli podobni modelom, ki jili uporabljajo načrtovalci (grai prehajanja stanj, odločitvene tabele, diagram toka podatkov itd.). VeČino modelov lahko predstavimo z grafom, z matriko ali s tabelo, pa tudi s seznamom.
Prvi testirni model, ki so ga uporabili za tvorjenje testnih vzorcev, je bil krmilni diagram (flowgraph, control flowgraph) oziroma grai programa (glej sliko 2). Ta mode! lahko zelo hitro tvorimo iz diagrama poteka (flowehart). Načrtovanju testnih primerov na podlagi krmilnega modela pravimo tudi testiranje poti (patti testing). Ker je teorija testiranja programskih poti zelo dobro obdelana, se v literaturi z njo zelo pogosto srečamo [BEIZFR, 1990], [DOGŠA,1994j, [MY-ER5,1979J, IVUET/19')3]f[.iORGENSFN,1995J.
Mnoge ideje, nastale v zvezi s tem modelom, je možno posplošiti in ustvariti splošen koncept testirne-ga modela. Najbolj preprost testirni model je seznani predpostavk o napakah ali nepravilnostih (glej sliko 1). Preproste tes tirne modele prikazujemo z usmerjenim grafom, kompleksnejše pa / matriko ali s tabelo. Vsak usmerjeni grai je sestavljen i/, vozlišč in usmerjenih povezav, Razvoj testirnega modela poteka po naslednjih korakih:
L določimo, kaj bodo predstavljala vozlišča
2.	določimo, kaj bomo predstavili z relacijo med vozlišči
3.	ustrezno povežemo vozlišča med seboj in
4.	če je potrebno, opremimo vozlišča in povezave z dodatnim atributom, povezanim z določeno lastnostjo (npr. pogostost)
1.	zahteval vpis Imena datoteke
2.	II datoteka ne obstaja ttien
3.	izpiši obvestilu
'1 else IzpISI vsebino d atole te na ekran 5. zakliuii program
transformacija

izvorna koda
Slika 2: Graf programa Je zelo pogost testirni model
4. Testirna strategija
Za izborom testirnega modela sledi postavitev ustrezne tes tirne strategije. Njen osrednji del je seveda testirni model. Testirna strategija ima podobno vlogo kot sistemske specifikacije. Če je pravilno opisana, lahko tretja oseba (npr. preverjevalčev pomočnik) relativno enostavno tvori testne primere. Vsaka pravilno zastavljena testirna strategija mora odgovoriti na naslednja vprašanja (v oklepajih so predlogi za imena posameznih alinej):
1.	Kdaj in kje je ta strategija uporabna? (Območje uporabnosti)
2.	Katere vrste napak ali nepravilnosti odkriva in katerih ne? (Opis predpostavke o napakah)
3.	Na kakšnem testirnem modelu temelji? (Opis testirnega modela)
4.	Kako na podlagi testirnega modela tvorimo testne primere? (Navodilo za načrtovanje)
5.	Kateri pogoji morajo biti izpolnjeni, da bomo lahko začeli / načrtovanjem? (Pogoji za načrtovanje)
6.	Kdaj je strategija izčrpana? (Terminalna kriterijska funkeija za določeno strategijo)
Omejili smo se samo na šest najpomembnejših elementov, ki tvorijo opis strategije. Nekateri dodajajo še alineje o avtomatizaciji, zgledu, morebitnih problemih in omejitvah (glej npr. [BEITZER,1995j, [BIND-ER,2000]). /a zgled smo izbrali preprosto strategijo, ki uporablja pozitivne testne primere. Poimenovali jo bomo Preverjanje prisotnosti zahtev. Ker je ena izmed najpreprostejših in najpogosteje uporabljenih, navajamo njen opis:
1.	Strategija je uporabna v vseli primerih, kjer so znane specifikacije in zahteve, med katerimi ni nobenih relacij. Uporablja se lahko za testiranje kompletnih programov ali pa samo komponent.
2.	Predpostavka o napaki: določena zahteva ni implementirana. S to strategijo odkrivamo zahteve, ki niso implementirane. Razen zelo redkih izjem ne bomo odkrili napačno implementirani!) zahtev in zahtev, ki so po nepotrebnem implementirane.
3. Testirni model je seznam zahtev. Za vsako zahtevo tvorimo en testni primer. Vhodne podatke si poljubno izberemo.
Z načrtovanjem testnih primerov lahko začnemo, ko so zahteve postavljene.
Testirna strategija je izčrpana, ko preverimo prisotnost vsake zahteve v seznamu. S to testirno strategijo bomo samo ugotovili, ali so vse lastnosti in zahteve implementirane. !.e v red kili primerih bomo odkrili tudi druge nepravilnosti. Za ugotavljanje prisotnosti napak moramo
U ll
d < #3
graf programa
4.
5.
6.
2001 - številka 2 - letnik IX
i i/A>utf» m! N FOR M AT IKA
77
Tomaž DogSa: Spi o Sen koncept načrtovanja testnih primerov
postaviti Še najmanj eno ali več strategij, ki temeljijo na negativnih testnih primerih.
Druga najpogosteje uporabljena strategija uporablja seznam nepravilnosti ali napak i/ preteklih projektov (glej primer na sliki l). 7a vsako nepravilnost, za katero predpostavljamo, da je prisotna, tvorimo enega ali pa več testnih primerov. Če je ta seznam tudi formalno zapisan, lahko govorimo o sistematični strategiji, sicer pa o intuitivni, Zagotovo sta intuitivno ugibanje napak in nepravilnosti ter preverjanje prisotnosti zahtev najbolj uporabljeni strategiji, saj ju uporablja večina neprofesionalnih preverjevalcev. Slabost intuitivnega ugibanja napak in nepravilnosti je predvsem v tem, da je ta strategija tesno vezana na izkušnje preverjevalea. Z njegovim odhodom na drugo delovno mesto lahko zelo pade učinkovitost preverjanja. Rešitev je v sistematičnem zbiranju najdenih napak in nepravilnosti (glej sliko 3). Preverjevalee analizira vsako poročilo o najdenih nepravilnostih in poročilo o najdenih napakah. Glede na izbran tak-sonomijski sistem tvori seznam, ki ga kasneje uporablja pri načrtovanju testnih primerov (več o tem glej v [BEIZER,I990], (7AVERSKI, 1999], [KANER, 1993]).
Izbor in število strategij ter testirnih modelov sta odvisna predvsem olI zahtevane kakovosti produkta,
razpoložljivih resursov in vrste produkta ali projekta. Splošen postopek načrtovanja testnih primerov prikazuje slika 4. Uporabljene strategije so običajno opisane v testirnem načrtu ali pa v priročniku za kakovost.
5. Sklep
Pri razvoju in kasnejšem vzdrževanju programske opreme se neprestano spreminjata izvorna koda in zahteve. Temu se mora prilagajati tudi preverjanje. Stroške načrtovanja in kasnejšega vzdrževanja testnih primerov lahko znižamo le s sistematičnim pristopom. Prikazali smo enega izmed možnih splošnih konceptov načrtovanja testnih primerov, ki temelji na testirnem modelu. Izbor in število strategij ter testii nih modelov sta odvisna predvsem od zahtevane kakovosti produkta, razpoložljivih resursov in vrste produkta ali projekta. Največ napora zahteva izbor pravega testirnega modela in njegovo vzdrževanje. Izhodišče za načrtovanje testnih primerov predstavlja predpostavka o napaki ali nepravilnosti, ki jo določimo s pomočjo modela. Za zgled smo izbrali dve preprosti in najpogosteje uporabljeni strategiji. Ideje za druge zahtevnejše modele lahko dobi preverjevalec v navedeni literaturi (npr. [BEIZER,1990], [BINDER,2000].
r i;j(vtii h jijI N FO RM ATI KA
Slika 3: Sistematično zbiranje napak in nepravilnosti
3001 številka 2 - letnik: IX
Tomaž Dog$a: Sploíen koncept načrtovanin testnih primerov
oko [je
zahteve glede
kakovosti, vrsta programa
1
specifikacije
izvorna koda
izvršljiv program
seznam napak in nepravilnosli iz preteklih projektov
C načrtovanje testnih primerov^
testni primeri
Slika 4: Model načrtovanja testnih primerov
6. Literatura
[8EI2ER.1990] B. Beizer:
"Software Testing Techniques". Van Nostrand Reinhold, New York.1990. 2. izdaja.
[BEIZER,1995] Boris Beizer:
"B/ack-Box Testing. Techniques for Functional Testing of Software and Systems". John Wiley and Sons, Inc., 1995.
[BINDER,2000] Robert Binder:
" testing Object-oriented systems: models, patterns and tools". Addion Wesley Longman, Inc. 2000,
[D0GŠA,1994] T Dogéa:
"Verifikacija in validacija programske opreme". Tehniška fakulteta. Maribor, 1993.
[006ŠA,1999.a] Tomaž Dogfci:
"Dokumentiranje testnih vzorcev". Uporabne informatika, Številka 1. letnik VII, 1999. str.9-16,
[D0GŠA.1999] Tomai Dofiéa:
"Načrtovanje testnih vzorcev s pomočjo tes tirnih modelov". Zbornik osme Elektrotehniške ¡n računalniške konference GRK '99, 23. - 25. september 1999, Portorož, Slovenija.
[DUSTIN,1999] E. Dustin, J. Rashka, J, Paul:
'Automated Software Testing: Intoduction. Management, and PerformanceAddison-Wesley
[IEEE, 1990b]
"IEEE Standard Glossary of Software Engineering Terminology". IEEE Sid, 610.12 1990, Revision and ^designation of IEEE Std. 792-1983, The institute of Electrical and Electronics Engineers, USA, 1990,
[J0RGENSEN.1995] Paul CJorgensen:
"Software testing - A Craftsman's Approach", CRC Press LLC 1995.
|KANER,1993] Cem Kaner, Jack Falk, Hunt; Quoc Nguyen: "Testing Computer Software", Van Nostrand Reinhold, 1993.
[MYERS .1979] J. G. Myers:
"The Art of Software Testing", John Wiley and Sons, Inc., New York, 1979.
[ZAVERSKI.1999] Igor Zavcrski, Tomaž Dogša:
"Ortogonalna klasifikacija napak programov v C+ 4 ". Objektna tehnologija v Sloveniji ŠtudiČ OTS'99 ; zbornik Četrtega strokovnega srečanja, Maribor, 16. in 17. junij 1999. Maribor: Fakulteta za elektrotehniko, računalništvo in informatiko, Center za objektno tehnologijo, 1999. str. 209-217.
Dr Tomaž Dorjša /e docent na fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru, kjer predava na dodipiamski in podiplomski stopnii m vodi Center za verifikacijo in validacijo sistemov Na raziskovalnem področju se ukvarja predvsem z V&V tehnologijo, tako tudi s testirnimi orodji.
2001 - številka 2 • letnik IX
upombnilNFORHATHÍA
t