Veleuilte u ibeniku

ibenik

Seminarski rad

Lipanj, 2011.

Veleulite u ibeniku
ibenik

Testiranje softvera

Kolegij: Softversko inenjerstvo

Profesor: Dipl.ing. Frane Urem
Student: Dragan upan
Br indeksa: 129331073

Lipanj, 2011.

Sadraj:

1. Uvod
2. Tesiranje softvera
2.1. Zato testirati softver
2.2. Otklanjanje greaka
3. Ciljevi testiranja
3.1. Zahtjevi za stalnim razvojem
3.2. Poboljanje procesa testiranja
6

1
2
3
3
4
5

4.

Softverske greke (error), mane, tj. defekti (faults) i otkazi (failures)

5. Klasifikacija i metode testiranja

8
5.1. Metode Crne kutije
8
5.1.1. Podjela na klase ekvivalencije
8
5.1.2. Analiza graninih vrijednosti
8
5.1.3. Uzrono.posljedini graf
9
5.2. Metode bijele kutije
9
5.2.1. Pokrivanja iskaza (Statement Coverage)
9
5.2.2. Pokrivanje odluka (Decision Coverage)
10
5.2.3. Metoda graninog testiranja unutrapnje putane (Boundary Interior Path
Testing)
6. Zakljuak

1. Uvod

Tema ovog seminarskog rada je testiranje softvera. Rad je pisan indukcijsko dedukcijskom
metodom, a podijeljen je na tri dijela.
U prvom dijelu objanjava se openito testiranje softvera, zato se testira te kako se otklanjaju
greke na softveru.
U sljedeem dijelu govori se o ciljevima testiranja i mogunostima poboljanja.
U posljednjem dijelu navedene su metode testiranja koje moemo podijeliti na metode Crne
kutije te metode Bijele kutije.

2. Testiranje softvera

Testiranje softvera je formalni proces koji se izvodi sa specifinim timom za testiranje kojim
se ispituju softverske jedinice ili cjelokupni softverski paketi izvravanjem programa na
kompjuteru. Svi povezani testovi se izvravaju u skladu sa odobrenim test procedurama na
odobrenim test sluajevima.
U razvojnom ciklusu softvera sve je znaajniji zadatak Testiranje softvera (TS) ili Verifikacije
i Validacije (V&V) koji treba osigurati da zahtijevani nivo povjerenja u ispravnost (ili
korektnost) softvera, kao i osiguranje ostalih zahtjevanih karakteristika softvera. Testiranje
softvera je izuzetno skup proces.
Testiranje je aktivnost izvedena radi evaluacije kvalitete proizvodnje i njegovog poboljanja.
Ono nije aktivnost koja poinje samo nakon kompletiranja faze kodiranja. Softversko
testiranje se danas vidi kao aktivnost koja obuhvaa cijeli proces razvoja i odravanja, i
predstavlja vaan dio kompletne konstrukcije softvera. Planiranje testiranja treba poeti sa
ranom fazom requirement procesa, i test planovi i procedure moraju biti sistematski i
kontinuirano razvijani i po potrebi redefinirani. Pravi stav prema kvalitetu je prevencija,
mnogo je bolje izbjei probleme nego ih ispravljati...kao i za sve ostale ivotne situacije fraza
je neizbena da je bolje spreiti, nego lijeiti. Stoga, stvari su vrlo jednostavne - Softver je kao
i ivot. Ima neminovnih greaka, nae je da ih svedemo na minimum ili potpuno uklonimo.
Treba stvoriti harmoniju i balans.

2.1. Zato testirati softver

Zato to su veliki gubitci kompanija koje razvijaju softver upravo zbog velikog broja defekata
u isporuenom softveru kupcima. Prvenstveni zadatak test inenjera jest otkrivanje
softverskog kvara, sa ciljem da se on otkloni prije predaje softverskog proizvoda kupcu, kako
bi kupac bio zadovoljan i dobio ono to eli. Od test inenjera se zahtjeva da otkrije to je
mogue vie problema i to to vie onih, vrlo ozbiljnih ije posljedice mogu biti katastrofalne
sa materijalnog i sigurnosnog aspekta. Zato je sa svih aspekata potrebno da se proces
testiranja softvera uini to efikasnijim i uz to manje trokove ukoliko je to mogue.

2.2. Otklanjanje greaka

Posebna panja danas se posveuje aktivnosti otkrivanja greaka. Ovo je bitna razlika u
odnosu na shvaanje da je vano potvrditi da li program ili sistem radi. Ova definicija
testiranja softvera je napisana u knjizi Glenford Myers "Umjetnost testiranja softvera".
Ovakvu definiciju je dao iz razloga to je tvrdio da je softver jedan od najkompleksnijih
proizvoda ljudskog umnog rada. Nemogue je otkriti sve greke u softveru. Nemogue je
dokazati da je softver bez greke. Takoe je jasno da je nemogue pobjediti prosto uvjerenje o
imperativu da se otkriju sve greke.
Pristup testiranju softvera na bazi otklanjanja greaka je proces koji je podloan grekama.
Tester softver mora identificirati i slijediti uoen problem do mjesta nastanka (izvora) greke
u softveru. Za otklanjanje greaka u softveru se moraju istraiti sve prethodne verzije i
dokumentacija o aktivnostima u svim prethodnim fazama u razvoju softvera, ukoliko su
raspoloivi. Cilj da se pokae da softver nema greaka, kroz otkrivanje i otklanjanje greaka,
je loija od strategije da se izvri analiza uzroka nastanka greaka, pa tek onda izvri
uklanjanje greaka.
Trokovi otklanjanja uoenih greaka, umjesto sprijeavanja njihovog nastanka, su veliki i
prouzrokuju veliki gubitak u poslovanju i nezadovoljstvo kupca zbog greaka u softveru. Prije
nego to se eka zavretak faze implementacije komponente softvera, pa tek onda testiranje
komponente u clju otkrivanja i otklanjanja greaka u njima, a koje su nastale u ranijim fazama
procesa razvoja, potrebno je preventivno djelovati na nastanak tih greaka, kako bi se izbjegla
kanjenja i uveali trokovi njihovog otklanjanja. Upravo je to cilj provoenja aktivnosti
prevencije nastanka greaka. U posljednje vrijeme je razvijen veliki broj metoda u cilju
sprijeavanja nastanka greaka u softveru- metoda dokazivanja korektnosti sofrvera, strategija
projektiranja po Six Sigma i mnoge druge.

3. Ciljevi testiranja

Dva su osnovna, glavna i najvea cilja testiranja, a to su:

Verifikacija: Da li dobro gradimo proizvod?
Softver to treba potvrditi svojom specifikacijom (dokumentacijom)
Validacija: Da li gradimo dobar proizvod?
Softver treba initi ono to korisnik stvarno eli
Verifikacija je provjera odgovaraju li rezultati etapa razvoja oekivanim rezultatima pojedine
etape.Validacija je provjera da je sistem oekivane rezultate kao funkciju ulaza.
Dva su osnovna cilja su otkriti nedostatke (greke) i procijeniti koliko je sistem upotrebljiv.
Verifikacija i validacija treba stvoriti povjerenje da je softver spreman za produkciju i to ne
znai da je softver potpuno bez nedostataka, ali mora biti dovoljno dobar da moe ispuniti
svoju namjenu.
Unutar procesa verifikacije i validacije primjenjuje se dvije tehnike provjere i analize
programskog sistema: kontrola softvera i testiranje sistema.
Kontrola softvera se odnosi se na analizu statikog prikaza sistema kako bi se otkrili problemi
(statika verifikacija). Ono ukljuuje analizu i provjeru predstavljenog sistema kroz
specifikaciju (dokument) zahtjeva, dijagrame oblikovanja, izvorni kod programa.
Testiranje sistema se odnosi na ispitivanje i posmatranje ponaanja softverskog proizvoda
(dinamika verifikacija). Ono ukljuuje implementaciju sistema sa test podacima, ispitivanje
izlaznih rezultata i provjera da li se ponaanje sistema odvija na nain kako je to zahtijevano.

3.1. Zahtjevi za stalnim razvojem

Postoji veliki nesklad izmeu sve sloenijih softverskih rjeenja i tehnika, alata koji se
primenjuju u procesu razvoja softvera i procesa testiranja softvera. Zahtjevi za softverskim

rjeenjima u svim podrujima dramatino rastu uz konstantan zahtjev: bre, bolje i jeftinije. S
druge strane, i oekivanja korisnika softvera su ne realno velika. Zahtjevi za razvoj i testiranje
softverskog proizvoda daleko prelaze znanje i iskustvo programera i menadera na tritu.

3.2. Poboljanja procesa testiranja

Poboljanja procesa testiranja je konstantan proces zajedno sa svim drugim elementima

razvoja softvera. Angairaju se sve vei resursi kako velikih tako i malih kompanija u proces
testiranja i njegovo unapreenje.
Postoji vie aspekata koji doprinose poboljanju procesa testiranja:
-

obuka kadrova za proces testiranja

automatizacija procesa testiranja
razvoj novih alata
razvoj novih modela testiranja
integracije procesa merenja parametara efikasnosti i efektivnosti procesa testiranja
analize slabih i jakih strana postojeeg procesa testiranja
identifikacije rizika i njihovih posledica na uspeh procesa razvoja

4. Softverske greke (error), mane, tj. defekti (faults) i otkazi (failures)

Testiranje u skladu sa ANS/IEEE-1059 standardom je proces analiziranja stavki softvera za

otkrivanje razlike izmeu postojeih i potrebnih uvjeta (koje su greke, mane i otkazi) i
procjena funkcija softverske stavke. Zapamtite: Svrha testiranja je verifikacija, validacija i
otklanjanje greaka u cilju nalaenja problema- i svrhe pronalaenja tih problema je da ih
popravi!
Softverska greka (engl. software error) je dio koda koji je djelomino ili totalno pogrean
kao rezultat gramatike, logike ili druge greke od strane sistem analitiara, programera ili
nekog drugog lana softverskog tima.
Softverske mane, tj. defekti (engl. software faults) su softverske greke koje su
prouzrokovane nepravilnim funkcioniranjem softvera tokom specifine primjene.
Softverske mane postaju softverski otkazi (engl. software failures) samo kada se aktiviraju,
tj. kada korisnik pokuava da primjeni specifinu softversku sekciju koja ima defect. To znai
da je izvor bilo kojeg neuspjeha u stvari greka.
Jedno od pitanja koji se nameu je zato se ustvari vri testiranje softvera. Testiranje se vri da
bi se verificiralo da li su zadovoljeni postavljeni zahtjevi projekta sa zadovoljavajuim
kvalitetom. Nalaenje bug-ova (greaka) je jedan od vanijih koraka u tom procesu. Svakom
dobrom testeru je cilj pronai to vie bug-ova u aplikaciji, jer oni sigurno postoje, samo ih
treba pronai.
Veoma je vano napomenuti da developer i korisnici imaju razliit pogled na softver sa strane
softverskih mana. Dok su developeri zainteresirani za otkrivanje softversih greaka i njihovo
otklanjanje, korisnike softvera brinu softverski otkazi.

5. Klasifikacija i metode testiranja

U sljedeim poglavljima detaljnije emo se upoznati sa metodama crne i bijele kutije.

5.1. Metode crne kutije

Kod ovog testiranja, program se tretira kao crna kutija nepoznatog sadraja kod koje su
vidljivi samo ulazi i izlazi, a funkcionalnost je odreena promatranjem dobivenih izlaznih
podataka na temelju odgovarajuih poznatih ulaza. Prilikom testiranja, na osnovu razliitih
ulaznih podataka dobijeni izlazni podaci se uporeuju s unaprijed oekivanim te se na taj
nain vri vrednovanje ispravnosti programa. Svi testovi proizlaze iz specifikacije programa
pri emu se ne vri nikakvo razmatranje programskog koda. Oigledno je da e se, im se
primjeni vie moguih ulaznih podataka, pronai i vie neispravnosti te e se njihovim
otklanjanjem poveati i pouzdanost

kvalitete programa. Detaljno testiranje kombinacija

razliitih ulaznih podataka za veinu programa je neizvedivo, ak i ako se promatra ispravnost

samo ulaznih podataka kroz najosnovnije injenice, kao to su ispravnost unesenih
vrijednosti, vrijeme unosa, redosljed unosa, itd. Mnogo razliitih kombinacija koje mogu
nastupiti kod ulaznih podataka glavna je prepreka u funkcijskom testiranju.
Navedena su tri primjera za metode Crne kutije:
-

Podjela na klase ekvivalencije

Analiza graninih vrednosti
Testiranje zasnovano na tablici odluivanja

5.1.1. Podjela na klase ekvivalencije

Klase ekvivalencije definiramo da bismo testirali program sa po jednom reprezentativnom
vrijednou ulaza iz svake klase ekvivalencije .
U idealnom sluaju podskupovi su meusobno disjunktni i pokrivaju cijeli skup ulaza
(relacija slinosti ulaza je relacija ekvivalencije)

Klase ekvivalencije se odreuju tako to se promatraju svi uvjeti vezani za ulaze programa
koji proizilaze iz

specifikacije. Za svaki uvjet se promatraju dvije grupe

klasa prema

zadovoljenosti uvjeta:

legalne klase obuhvaaju doputene situacije.

nelegalne klase obuhvaaju sve ostale situacije.

5.1.2. Analiza graninih vrijednosti

Posebnu panju treba obratiti na granicama klasa ekvivalencije!
Veoma mnogo greaka se pojavljuje u granicama klasa ekvivalencije i iz tog razloga se koristi
analiza graninih vrijednosti. Analiza granine vrijednosti pripada dizajnu test sluaja koji
upotpunjuje ekvivalentnost participiranja. Analiza granine vrijednosti se odreuje na osnovu
sledeeg:
Ako ulazni uvjet specificira stanje okvirno u rasponu od vrijednosti A do B, dobiva se test
sluajeve sa vrijednostima A i B, samo iznad i ispod A i B
Ako ulaz specifira stanje razliitih vrijednosti, test sluajevi trebaju biti izraeni za vjebu sa
minimalnim i maksimalnim brojkama

5.1.3. Uzrono - posljedini grafovi

Testiranje softvera bi bilo znatno olakano kada bi se mogli automatski generirati test primjeri
iz zahtjeva. Stoga je potrebno analizirati zahtjeve i preformulirati ih u vidu logike relacije
izmeu ulaza i izlaza. Rezultat se moe predstaviti u obliku takozvanog uzrono
posljedinog grafa.
Uzrono posljedini grafovi nisu primjenjivi na sisteme koji posjeduju vremenska
ogranienja i na sisteme koji posjeduju konkurentne procese.
Tabela odluivanja je dvodimenzionalno mapiranje uzroka na posljedice. Moe se izvesti iz
uzrono posljedinog grafa. Tabela odluivanja ima po jedan red za svaki uzrok i posljedicu.
Redovi tabele odgovaraju test primjerima. Kolone se definiraju analiziranjem vorova

posljedica u uzrono posljedinom grafu. Upotrebom tabele odluivanja broj test primjera
se znaajno smanjuje.

5.2. Metode bijele kutije

Ovo testiranje provjerava i analizira izvorni kod i zahtjeva dobro poznavanje programiranja,
odgovarajueg programskog jezika, kao i dizajna konkretnog softverskog proizvoda. Plan
testiranja se odreuje na osnovu elemenata implementacije softvera, kao to su programski
jezik, logika i stilovi. Testovi se izvode na osnovu strukture programa. Kod ove metode
postoji mogunost provjere skoro cjelokupnog koda, na primjer provjerom da li se svaka linija
koda izvrava barem jednom, provjerom svih funkcija ili provjerom svih moguih
kombinacija razliitih programskih naredbi. Specifinim testovima moe se provjeravati
postojanje beskonanih petlji ili koda koji se nikada ne izvrava.
Ovaj oblik testiranja se naziva i strukturno testiranje.

Objasniemo sljedee tehnike testiranja bijele kutije:

1. Pokrivanje iskaza (Statement coverage)
2. Pokrivanje odluka (Decision coverage)
3. Pokrivanje uvjeta
4. Metoda graninog testiranja

5.2.1. Pokrivanje iskaza (Statement coverage)

Svaki iskaz u programu se mora bar jednom izvriti, jer ne moemo znati da li u bilo kojem
iskazu postoji greka ukoliko ga ne izvrimo bar jednom.
Meutim, ne moemo garantirati da e se iskaz koji se ispravno izvravao za jednu ulaznu
vrijednost , isvravati ispravno i za neku drugu ulaznu vrijednost, to je loa strana ove
tehnike.

5.2.2. Pokrivanje odluka (Decision coverage)

Svaka od uvjetnih grana se izvrava najmanje jednom. Ova metoda je jaa od metode
pokrivanja iskaza jer pokrivanje odluka garantira pokrivanje iskaza. Svaka izlazna grana mora
biti izabrana bar jednom.

5.2.3. Pokrivanje uvjeta

Svaka elementarna komponenta sloenog uvjetnog izraza uzima i tonu i netonu vrijednost.
Elementarni uvjeti se promatraju nezavisno jedan od drugog.
Ova metoda ne garantira pokrivanje svih odluka . Samim tim nije garantirano ni pokrivanje
svih iskaza.

5.2.4. Metoda graninog testiranja unutranje putanje (boundary interior path

testing)
Zahtjeva pokrivanje sljedeih putanja u programu:
-

izvravanje tijela petlje 0 puta

izvravanje tijela petlje 1 put (granini test)
ponavljanje tijela petlje bar jednom (unutranji test)

Za svaki od prethodnih sluajeva potrebno je potpuno prekriti sve (otvorene) putanje u

grafu.

5. Zakljuak
Posljednih godina je intenzivirano istraivanje u oblasti testiranja softvera u svijetu, kao i
zbog mnogih nerijeenih problema u ovom podruju. Jedan od naina da se sprijei isporuka
softvera kupcu sa grekama je da skoro sve kompanije ulau sve vie sredstava u obuku
kadrova i opremu za testiranje softvera. Veoma je vano, da ne kaem presudno razviti
mjerljive tehnike za ocjenu efektivnosti postojeeg procesa testiranja softvera, kako bi se
otkrile njegove slabosti i prednosti, identificirali kako rizike tako i njihove posljedice.

Literatura:
1. www.scridb.com/doc/27426792/Testiranje-Softvera-Rad
2. www.sistemciefri.vacau.com/esej.coc
3. www.web.studenti.math.hr/manager/si/skripta.pdf