Testiranje Softvera - Rad

Sadrzaj:

1. Uvod.......................................................................................................................................................1

2. Šta je testiranje?...................................................................................................................................2

2.1. Zašto testiramo?............................................................................................................................3

2.2. Vrijeme za testiranje?...................................................................................................................3

2.3. Otklanjanje grešaka......................................................................................................................4

2.4. Troškovi otklanjanja grešaka.......................................................................................................4

2.5. Kada prestati testirati?..................................................................................................................4

3. Ciljevi testiranja.....................................................................................................................................5

4. Softverske greške (error), mane, tj. defekti (faults) i otkazi (failures)............................................6

5. Klasifikacija i metode testiranja..........................................................................................................7

5.1. Metode crne kutije.........................................................................................................................7

5.1.1. Podjela na klase ekvivalencije..............................................................................................7

5.1.2. Analiza graničnih vrijednosti.................................................................................................9

5.1.3. Uzročno - posledični grafovi..............................................................................................10

5.2. Metode bijele kutije.....................................................................................................................14

5.2.1. Pokrivanje iskaza (Statement coverage)..........................................................................14

5.2.2. Pokrivanje odluka (Decision coverage).............................................................................17

5.2.3. Pokrivanje uslova.................................................................................................................17

5.2.4. Metoda graničnog testiranja unutrašnje putanje (boundary interior path testing).......18

5.2.5. Testiranje metodom toka podataka...................................................................................20

5.2.6. Pokrivanje bazičnih putanja................................................................................................23

Literatura..................................................................................................................................................26

1. Uvod

Dolaskom 21.vijeka, kao i manjim dijelom pripremanja ulaska naše zemlje u EU, naglašen je i te kako primjetan razvoj mikroelektronike, informatičke i komunikacijske tehnologije. Sve se obavlja računarom i rješenja se primenjuju u svim područjima ljudskog djelovanja, nezavisno od predmeta posla ili tematike i materije. Izvršavanje i najsitnijih obaveza, najbizarnijih poslova postalo je zavisno o računaru i ispravnosti istog. Da bi jedan računar bio ispravan nužno je da su ispravna oba dijela, i sklopovski i programski. Postoji tzv. testiranje programske greške, a taj proces predstavlja traženje grešaka u računaru. Programska podrška nije poput drugih fizičkih sistema, a do pojave grešaka dolazi zbog mnogih razloga, koji nam se ponekad i ne učine kao i adekvatni razlozi. Postoje i logičke greške, koje mogu biti otkrivene detaljnijim testiranjem aplikacije. Greške su gotovo neizbježne, pa čak i iskusniji programeri prave sitne, trivijalne opaske, koje svi smatramo da su banalne. A kako nas je život naučio, najbitnija su očekivanja ili neočekivanja. Najbitnije u ovom slučaju jeste očekivati greške u kodu.

2. Šta je testiranje?

Testiranje softvera je formalni proces koji se izvodi sa specifičnim timom za testiranje kojim se ispituju softverske jedinice ili cjelokupni softverski paketi izvršavanjem programa na kompjuteru. Svi povezani testovi se izvršavaju u skladu sa odobrenim test procedurama na odobrenim test slučajevima.

U razvojnom ciklusu softvera sve je značajniji zadatak Testiranje softvera (TS) ili Verifikacije i Validacije (V&V) koji treba da obezbijedi zahtjevani nivo povjerenja u ispravnost (ili korektnost) softvera, kao i obezbjeđenja ostalih zahtjevanih karakteristika softvera. Testiranje softvera je izuzetno skup proces.

Abnormalno veliki su gubici firmi uslijed grešaka u softveru, koji su uslovili razvoj oblasti krivične odgovornosti proizvođača softvera i zaštite kupaca zbog neadekvatnog kvaliteta softverskog proizvoda. Iz svih navedenih razloga, poslednjih godina je intenzivirano istraživanje u oblasti testiranja softvera u svijetu, kao i zbog dolje identifikovanih neriješenih problema u ovoj oblasti. Jedan od načina da se spriječi isporuka softvera kupcu sa greškama je da skoro sve kompanije ulažu sve više sredstava u obuku kadrova i opremu za testiranje softvera. Veoma je važno, da ne kažem presudno razviti mjerljive tehnike za ocjenu efektivnosti postojećeg procesa

2

testiranja softvera, kako bi se otkrile njegove slabosti i prednosti, identifikovali kako rizici tako i njihove posledice.

Testiranje je aktivnost izvedena radi evaluacije kvaliteta proizvodnje i njegovog poboljšanja. Ono nije aktivnost koja počinje samo nakon kompletiranja faze kodiranja. Softversko testiranje se danas vidi kao aktivnost koja obuhvata cio proces razvoja i održavanja, i predstavlja važan dio kompletne konstrukcije softvera. Planiranje testiranja treba da počne sa ranom fazom requirement procesa, i test planovi i procedure moraju biti sistematski i kontinualno razvijani i po potrebi redifinisani. Pravi stav prema kvalitetu je prevencija, mnogo je bolje izbjeći probleme nego ih ispravljati...kao i za sve ostale životne situacije fraza je neizbežna da je bolje sprečiti, nego lečiti. Stoga, ja posmatram stvari vrlo jednostavno- Softer je kao i život. Ima neminovnih grešaka, naše je da ih svedemo na minimum ili potpuno uklonimo. Da stvorimo harmoniju i balans.

2.1. Zašto testiramo?

Veliki su gubici kompanija zbog defekata u softeru i problema o kojem gore govorimo. Prvenstveni zadatak test inženjera jeste 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 inženjera se zahteva da otkrije što je moguće više problema i to što više onih, vrlo ozbiljnih čije posledice mogu biti katastrofalne sa materijalnog i bezbjednosnog aspekta. Zato je sa svih aspekata potrebno da se proces testiranja softvera učini što efikasnijim i uz što manje troškove ukoliko je to moguće.

2.2. Vrijeme za testiranje?

Neophodno je misliti o testiranju softvera već prvog dana nakon početka projekta, a ne kao što je uobičajeno da se aktivnost testiranja softvera planira na kraju razvoja softvera. Glavni problem je taj, da skoro nikad nema dovoljno vremena za testiranje softvera. Zato treba da mijenjamo odnos prema aktivnosti testiranja softvera i vremenu koje je planirano za testiranje, tako što ćemo ga efikasnije utrošiti u ranim fazama razvoja softvera.

3

2.3. Otklanjanje grešaka

Pristup testiranju softvera na bazi otklanjanja grešaka je takođe proces koji je podložan greškama. Tester softver mora da identifikuje i proprati uočen problem do mjesta nastanka (izvora) greške u softveru. Za otklanjanje grešaka u softveru se moraju istražiti sve prethodne verzije i dokumentacija o aktivnostima u svim prethodnim fazama u razvoju softvera, ukoliko su raspoloživi. Cilj da se pokaže da softver nema grešaka, kroz otkrivanje i otklanjanje grešaka, je lošija od strategije da se izvrši analiza uzroka nastanka grešaka, pa tek onda izvrši uklanjanje grešaka.

2.4. Troškovi otklanjanja grešaka

Troškovi otklanjanja uočenih grešaka, umjesto spriječavanja njihovog nastanka, su veliki i prouzrokuju veliki gubitak u poslovanju i nezadovoljstvo kupca zbog grešaka u softveru. Prije nego što se čeka završetak faze implementacije komponente softvera, pa tek onda testiranje komponente u clju otkrivanja i otklanjanja grešaka u njima, a koje su nastale u ranijim fazama procesa razvoja, potrebno je preventivno djelovati na nastanak tih grešaka, kako bi se izbjegla kašnjenja i uvećali troškovi njihovog otklanjanja. Upravo je to cilj sprovođenja aktivnosti prevencije nastanka grešaka. U poslednje vrijeme je razvijen veliki broj metoda u cilju spriječavanja nastanka grešaka u softveru- metod dokazivanja korektnosti sofrvera, strategija projektovanja po Six Sigma i mnoge druge.

2.5. Kada prestati testirati?

Ne postoji vrijeme kada treba prestati sa testiranjem. Ono se praktično može izvoditi beskrajno puta i nikad da se stane, sa istim. Nikad se ne može sa sigurnošću reći da su otkriveni i uklonjeni svi mogući defekti. Ali, naravno da u jednom trenutku treba prestati testirati. Pitanje je samo kada to učiniti, kada je taj trenutak? Realno posmatrano, testiranje je trgovina između cijene koštanja, vremena i kvaliteta. Stoga se, na nesreću, najčešće koristi pristup da se testiranje prekida kad god je jedan od resursa (vrijeme, novac ili broj testova) prekoračen. Bolji je pristup da se definiše prekid testiranja, kada

4

je pouzdanost u zahtjevanim okvirima ili kad su dobici od daljnjeg testiranja manji od cijene testiranja. Ovo će obično zahtijevati upotrebu pouzdanih modela da bi se vrednovala predviđena pozdanost testirane programske podrške. Ova metoda neće biti najbolja ukoliko je riječ o jako zavisnim sistemima i to zato, što je kod njih potrebno mnogo vremena i truda da bi se akumulirali stvarni podaci koji dovode do pojave greške.

3. Ciljevi testiranja

Dva su osnovna, glavna i najveća cilja ovog fenomena koji obradjujem, problemi i testiranje, 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 očekivanim rezultatima pojedine etape.

Validacija je provjera da je sistem očekivane rezultate kao funkciju ulaza.

Ove dvije definicije objašnjavaju i terminoloshko i fenomenoloshki pojam i značenje. Naišao sam radeći na još mnogo sličnih ili manje sličnih def. Ali su ove bile najbliže i mom logičkom redosledu shvatanja stvari. Dva su osnovna cilja su otkriti nedostatke (greške) i procijeniti koliko je sistem upotrebljiv. V&V treba stvoriti povjerenje da je softver spreman za produkciju i to ne znači da je softver potpuno bez nedostaka, ali mora biti dovoljno dobar da može ispuniti svoju namjenu.

Unutar procesa V&V primjenjuje se dvije tehnike provjere i analize programskog sistema: kontrola softvera i testiranje sistema.

Kontrola softvera se odnosi se na analizu statičkog prikaza sistema kako bi se otkrili problemi (statička verifikacija). Ono uključuje analizu i provjeru predstavljenog sistema kroz specifikaciju (dokument) zahtjeva, dijagrame oblikovanja, izvorni kod programa.

Testiranje sistema se odnosi na ispitivanje i posmatranje ponašanja softverskog proizvoda (dinamička verifikacija). Ono uključuje implementaciju sistema sa test

5

podacima, ispitivanje izlaznih rezultata i provjera da li se ponašanje sistema odvija na način kako je to zahtijevano.

4. Softverske greške (error), mane, tj. defekti (faults) i otkazi (failures)

Testiranje u skladu sa ANS/IEEE-1059 standardom je proces analiziranja stavki softvera za otkrivanje razlike između postojećih i potrebnih uslova (koje su greške, mane i otkazi) i procjena funkcija softverske stavke. Zapamtite: Svrha testiranja je verifikacija, validacija i otklanjanje grešaka u cilju nalaženja problema- i svrhe pronalaženja tih problema je da ih popravi!

Softverska greška (engl. software error) je dio koda koji je djelimično ili totalno pogrešan kao rezultat gramatičke, logičke ili druge greške od strane sistem analitičara, programera ili nekog drugog člana softverskog tima.

Softverske mane, tj. defekti (engl. software faults) su softverske greške koje su prouzrokovane nepravilnim funkcionisanjem softvera tokom specifične primjene.

Softverske mane postaju softverski otkazi (engl. software failures) samo kada se aktiviraju, tj. kada korisnik pokušava da primjeni specifičnu softversku sekciju koja ima defect. To znači da je izvor bilo kojeg neuspjeha u stvari greška.

Jedno od pitanja koji se nameću je zašto se ustvari vrši testiranje softvera. Testiranje se vrši da bi se verifikovalo da su zadovoljeni postavljeni zahtjevi projekta sa zadovoljavajućim kvalitetom. Nalaženje bug-ova (grešaka) je jedan od važnijih koraka u tom procesu. Svakom dobrom testeru je cilj pronaći što više bug-ova u aplikaciji, jer oni sigurno postoje, samo ih treba pronaći.

Veoma je važno napomenuti da developer i korisnici imaju različit pogled na softver sa strane softverskih mana. Dok su developer zainteresovani za otkrivanje softversih grešaka i njihovo otklanjanje, korisnike softvera brinu softverski otkazi.

6

5. Klasifikacija i metode testiranjaU sledećim 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 sadržaja kod koje su vidljivi samo ulazi i izlazi, a funkcionalnost je određena posmatranjem dobijenih izlaznih podataka na temelju odgovarajućih poznatih ulaza. Prilikom testiranja, na osnovu različitih ulaznih podataka dobijeni izlazni podaci se upoređuju s unaprijed očekivanim te se na taj način vrši vrednovanje ispravnosti programa. Svi testovi proizlaze iz specifikacije programa pri čemu se ne vrši nikakvo razmatranje programskog koda. Očigledno je da će se, čim se primjeni više mogućih ulaznih podataka, pronaći i više neispravnosti te će se njihovim otklanjanjem povećati i pouzdanost kvaliteta programa. Detaljno testiranje kombinacija različitih ulaznih podataka za većinu programa je neizvodivo, čak i ako se posmatra ispravnost samo ulaznih podataka kroz najosnovnije činjenice, kao što su ispravnost unešenih vrijednosti, vrijeme unosa, redosljed unosa, itd. Mnogo različitih kombinacija koje mogu nastupiti kod ulaznih podataka glavna je prepreka u funkcijskom testiranju.

Navešćemo primjere za tri metode „Crne kutije“:

• Podela na klase ekvivalencije • Analiza graničnih vrednosti• Testiranje zasnovano na tabeli odlučivanja

– Uzročno-posledični graf

5.1.1. Podjela na klase ekvivalencije

Klase ekvivalencije definišemo da bismo testirali program sa po jednom reprezentativnom vrijednošću ulaza iz svake klase ekvivalencije .

U idealnom slučaju podskupovi su međusobno disjunktni i pokrivaju cio skup ulaza (relacija “sličnosti” ulaza je relacija ekvivalencije)

Klase ekvivalencije se određuju tako što se posmatraju svi uslovi vezani za ulaze programa koji proizilaze iz specifikacije. Za svaki uslov se posmatraju dvije grupe klasa prema zadovoljenosti uslova:

– legalne klase obuhvataju dozvoljene situacije.– nelegalne klase obuhvataju sve ostale situacije.

7

Koraci za formiranje test primjera:

Prvi korak je u identifikaciji uslova za ulazne podatke i odgovarajuće klase ekvivalencije.

Drugi korak je u formiranju skupa test-primjera koji pokrivaju sve legalne klase ekvivalencije (jedan test primjer smije da pokrije veći broj klasa)

Poslednji korak je u formiranju posebnog test-primjera za svaku od nelegalnih klasa.

Primjer:

Metodom dijeljenja na klase ekvivalencije testirati dio programa koji ispituje da li zadati telefonski broj zadovoljava format +| 00 (nnn) nn – nnn – nnn, gdje n predstavlja numericki symbol, pri cemu prva 3 numericka simbola (nnn) moraju pripadati skupu {382}, a grupa nn mora pripadati skupu {67, 68, 69}

Primjer:+(382)67-619-334

Uslov legalne klase Nelegalne klase

Pocetni simbol +, 00 (1) Sve ostalo (2)

Simbol oznake drzave (382) (3) Sve ostalo (4)

Broj numerickih simbola za oznaku telefonskog operatera

2 (4) Više li manje od 2 broja (5)

Prvi broj u spisku brojeva za oznaku telefonskog operatera

6 (6) Sve ostalo (7)

Drugi broj u spisku brojeva za oznaku telefonskog operatera

7, 8,9 (8) Broj razlicit od 7, 8 ,9 ili neki nenumericki simbol (9)

Znaci razdvajanja izmedju grupe brojeva - (10) Bilo koji drugi simbol (11)

Ukupan broj brojeva izmedju znakova razdvajanja (zadnje 2 grupe brojeva)

3 (12) Broj !=3 (13)

Test primjer koji zadovoljavaju legalne klase: +(382)68 – 456 - 456

8

Test primjeri koji zadovoljavaju nelegalne klase:

1. –(382) 68 – 345 – 567 (2)2. 00(678)62 – 346 – 123 (4), (9)3. +(382)567 – 456 – 678 (5)4. +(382)57 - 456 – 276 (7)5. +(382 )67/567/234 (11)6. 00(382) 67 – 4567 – 1234 (13)

5.1.2. Analiza graničnih vrijednosti

Posebnu paznju trebamo obratiti na granicama klasa ekvivalencije!

Veoma mnogo grešaka se pojavljuje u granicama klasa ekvivalencije i iz tog razloga se koristi analiza graničnih vrijednosti. Analiza granične vrijednosti pripada dizajnu test slučaja koji upotpunjuje ekvivalentnost particionisanja.. Analiza granične vrijednosti se određuje na osnovu sledećeg:

Ako ulazni uslov specifikuje stanje oivičeno u rasponu od vrijednosti A do B, dobijamo test slučajeve sa vrijednostima A i B, samo iznad i ispod A i B

Ako ulaz specifira stanje različitih vrijednosti, test slučajevi treba da budu izrađeni za vježbu sa minimalnim i maksimalnim brojkama

Test primjeri sa graničnim vrijednostima, koji zadovoljavaju legalne klase za primjer pisanja datuma formata dd.mm.yyyy su:

Legalne klaseSrednja

vrijednost

Donja-granična

vrijednost legalne klase

Gornja-granična

vrijednost legalne klase

Test primjeri sa graničnim

vrijednostima za dan23.09.2010 01.04.2010 30.04.2010

Test primjeri sa graničnim

vrijednostima za mjesec24.09.2010 04.01.2010 04.12.2010

9

Nelegane klase u prethodnom primjeru su:

dd>31 ili dd<00 za mjecece 1,3,5,7,8,10,12

dd>30 ili dd<00 za mjesece 4,6,9,11

dd>28 ili dd<00 za mjesec 2 (6)

mm>12 ili mm<00 (8)

Nelegalne klaseTest

primjer

Donja – granicna

vrijednost

nelegalne klase

Gornja-granična vrijednost

nelegalne klase

Test primjeri sa graničnim

vrijednostima za dan(6) 00.05.2010 32.05.2010

Test primjeri sa graničnim

vrijednostima za mjesec(8) 06.00.2010 06.13.2010

5.1.3. Uzročno - posledični grafovi

Testiranje softvera bi bilo znatno olakšano kada bi se mogli automatski generisati test primjeri iz zahtjeva. Stoga je potrebno analizirati zahtjeve i preformulisati ih u vidu logičke relacije između ulaza i izlaza. Rezultat se može predstaviti u vidu takozvanog uzročno – posljedičnog grafa.

Uzročno – posljedični grafovi nisu primjenjivi na sisteme koji posjeduju vremenska ograničenja i na sisteme koji posjeduju konkurentne procese.

Tabela odlučivanja je dvodimenzionalno mapiranje uzroka na posljedice. Može se izvesti iz uzročno – posljedičnog grafa. Tabela odlučivanja ima po jedan red za svaki uzrok i posljedicu. Kolone tabele odgovaraju test primjerima. Kolone se definišu

10

analiziranjem čvorova posljedica u uzročno – posljedičnom grafu. Upotrebom tabele odlučivanja broj test primjera se značajno smanjuje.

Koraci pri konstrukciji uzročno-posledičnog grafa:1. Podjela specifikacije na radne dijelove (da ograniči veličinu rezultujućeg grafa).2. Identifikacija uzroka (ulazni uslov ili klasa ekvivalencije ulaznih uslova) i posledica

(izlaz ili neka unutrašnja promjena stanja sistema). Binarna vrijednost: 0/1.3. Analiziranjem značenja specifikacije konstruiše se uzročno-posledični graf.

Čvorovima se predstavljaju uzroci, posledice i međučvorovi. Grane označavaju AND, OR i NOT zavisnosti među čvorovima, kao i ograničenja tipa I, E, O i R.

Ograničenja: I – inkluzija, bar jedan od povezanih čvorova mora biti 1 (nedozvoljena kombinacija da

su svi 0).E – ekskluzija, najviše jedan od povezanih čvorova može biti 1 (nije dozvoljeno da više

od jednog ima vrijednost 1) O – one&only one, tačno jedan od povezanih čvorova mora biti jedanR – requires, ako strelica ide od čvora A ka čvoru B, to znači da bi A bilo 1 mora B biti 1

(nedozvoljena kombinacija B=0 i A=1, ostale su dozvoljene). 4. Konstrukcija tabele odlučivanja na osnovu uzročno posledičnog grafa.5. Određivanje konkretnih test primjera sa podacima na osnovu tabele odlučivanja.

Primjer:Kompanija Export-Import svake godine za osobe zenskog pola za 8. Mart I dan zaljubljenih, dijeli novcane poklone, i to:

1. Za zaposlene zene od 1-10 godina staza – 50 eura2. Za zaposlene zene od 10-20 godina staza - 100 eura3. Za zaposlene zene od 20-30 godina staza – 150 eura

Uzroci:1. Zaposlene zenskog pola (U1)2. 8. Mart i dan zaljubljenih (U2)3. Kompanija Export-Import (U3)4. 1-10 godina staza (U4)5. 10-20 godina staza (U5)6. 20-30 godina staza (U6)

Posledice:1. Zaposleni muskog pola (P1)2. Nije 8. Mart ni dan zaljubljenih (P2)3. Poklon 50 (P3)4. Poklon 100 (P4)5. Poklon 150 (P5)

11

Medjučvorovi :1. Kompanija Export- Import dijeli poklone za 8. Mart i dan zaljubljenih zaposlenim

zenskog pola (M1)

12

13

U3

U1

P1

U2

P2

M1

U5

U6

P3

P4

P5

U4

Uzročno – posledični graf za dati primjer

14

Čvorovi T1 T2 T3 T4 T5

U1 0 * 1 1 1

U2 * 0 1 1 1

U3 * * 1 1 1

U4 * * 1 0 0

U5 * * * 1 0

U6 * * * 0 1

P1 1 * * 0 0

P2 * 1 * 0 0

P3 * * 1 0 0

P4 * * * 1 0

P5 * * * 0 1

Tabela odlučivanja koja odgovara gore nacrtanom grafu

Test primjeri:

1. Zaposleni muskarac2. 27. decembar3. Poklon za osobu zenskog pola sa radnim stažom Od 4 godine za 8. mart4. Poklon za osobu zenskog pola sa radnim stazom od 13 godina na dan

zaljubljenih5. Poklon za osobu zenskog pola sa radnim stazom Od 25 godina na dan

zaljubljenih

15

5.2. Metode bijele kutije

Ovo testiranje provjerava i analizira izvorni kod i zahtjeva dobro poznavanje programiranja, odgovarajućeg programskog jezika, kao i dizajna konkretnog softverskog proizvoda. Plan testiranja se određuje na osnovu elemenata implementacije softvera, kao što su programski jezik, logika i stilovi. Testovi se izvode na osnovu strukture programa. Kod ove metode postoji mogućnost provjere skoro cjelokupnog koda, na primjer provjerom da li se svaka linija koda izvršava barem jednom, provjerom svih funkcija ili provjerom svih mogućih kombinacija različitih programskih naredbi. Specifičnim testovima može se provjeravati postojanje beskonačnih petlji ili koda koji se nikada ne izvršava.

Ovaj oblik testiranja se naziva i strukturno testiranje.

Objasnićemo sledeće tehnike testiranja bijele kutije:

1. Pokrivanje iskaza (Statement coverage)

2. Pokrivanje odluka (Decision coverage)

3. Pokrivanje uslova

4. Metoda graničnog testiranja

5. Testiranje metodom toka podataka

6. Pokrivanje bazicnih putanja (Basic path testing)

5.2.1. Pokrivanje iskaza (Statement coverage)

Svaki iskaz u programu se mora bar jednom izvrsiti, jer ne mozemo znati da li u bilo kojem iskazu postoji greška ukoliko ga ne izvršimo bar jednom.

Međutim, ne možemo garantovati da će se iskaz koji se ispravno izvršavao za jednu ulaznu vrijednost , isvršavati ispravno i za neku drugu ulaznu vrijednost, sto je loša strana ove tehnike.

16

Primjer:

Program prvi(x, y, z);

Var k: integer;

Begin

If(x>0) then (If1)

If(y>0 && z>0) then (If2)

k=x-y-z; (I1)

Else if(y<0 && z<0) then (If3)

K=x+y+z; (I2)

Else k=0; (I3)

else

k=-1; (I5)

writeln(“promjenljiva k je”, k); (I6)

End

17

18

truefalse

truetrue

false

false

IF1

IF2

k=-1

K=0

I1

k=x-y-zIF3

true

k=x+y+z

false

K

true

Pokriveni iskaz x y z Test primjer

IF1,IF2,I1, I6 4 4 1 (1)

IF1, IF2,IF3,I2,I6 4 -1 -2 (2)

IF1, IF2,IF3, I3, I6 4 -1 2 (3)

If1, I5,I6 -1 4 1 (4)

5.2.2. Pokrivanje odluka (Decision coverage)

Svaka od uslovnih grana se izvršava najmanje jednom. Ovaj metod je jači od metode pokrivanja iskaza jer pokrivanje odluka garantuje pokrivanje iskaza. Svaka izlazna grana mora biti izabrana bar jednom.

Primjer: Možemo uzeti primjer iz prethodne metode.

Pokrivene odluke x y z Test primjer

IF1 4 4 1 (1)

IF1 -1 4 1 (4)

IF2 4 4 1 (1)

IF2 4 -1 2 (3)

IF3 4 -1 -2 (2)

IF3 4 -1 2 (3)

19

5.2.3. Pokrivanje uslova

Svaka elementarna komponenta složenog uslovnog izraza uzima i tačnu i netačnu vrijednost. Elementarni uslovi se posmatraju nezavisno jedan od drugog.

Ovaj metod ne garantuje pokrivanje svih odluka . Samim tim nije garantovano ni pokrivanje svih iskaza.

20

Primjer: Iz prethodne 2 metode.

Pokrivanje uslova x y z Test primjer

IF-1 4 4 1 (1)

IF-1 -1 4 1 (2)

IF-2 4 4 1 (1)

IF-2 4 -4 -3 (3)

IF-3 4 -4 -3 (3)

IF-3 4 4 1 (1)

5.2.4. Metoda graničnog testiranja unutrašnje putanje (boundary interior path testing)

Zahtjeva pokrivanje sledećih putanja u programu:

izvršavanje tijela petlje 0 puta izvršavanje tijela petlje 1 put (granični test) ponavljanje tijela petlje bar jednom (unutrašnji test)

Za svaki od prethodnih slučajeva potrebno je potpuno prekriti sve (otvorene) putanje u grafu.

Primjer:

Napisati program u c++, koji racuna da li je dati broj savrsen. Broj je savrsen ako je jednak zbiru svojih djelitelja.

#include<iostream>using namespace std;int main() {        int brojac,zbroj,N;       cout<<"Upisi prirodni broj: ";       cin>>N;       zbroj=0; brojac=1;       while (brojac<=(N-1)) (While1)

21

       {                         if(N%brojac==0) (If1)               {                       zbroj=zbroj+brojac;               } brojac++       }       if(zbroj==N) (If2)                cout<<"Broj "<<N<<" je savrsen."<<endl;       else                cout<<"Broj "<<N<<" nije savrsen."<<endl;return 0; }

Datom primjeru odgovara sledeći graf:

22

23

If2While1

true

true

false

falseN je savrsen

N nije savrsenIf1

Izvrsavanje petlje 0 puta : While1 grana false, IF2 grana false – N=1

Izvrsavanje petlje 1 put : While1 grana true, IF1 grana true,while1 grana false, IF2 grana false - N=2

Izvrsavanje petlje bar jednom: While2 grana true, IF1 grana true...while2 grana true, IF1 grana true, while2

grana false, if2 grana true – N=28 While5 grana true,... IF1 grana true , while5 grana true, while5 grana false, if2

grana false – N=30

5.2.5. Testiranje metodom toka podataka

Testiranje toka podataka (data flow testing) je metoda za strukturno testiranje programa koja se temelji na opažanju da se izvođenjem programskog koda nad varijablama i objektima izvode određeni tipovi akcija . Akcija dodjele mijenja stanje varijable, akcija upotrebe koristi vrijednost varijable, ali je ne mijenja. Analiza toka podataka prati svaku varijablu (objekt) programa od početne deklaracije, inicijalizacije i definisanja vrijednosti varijable, do njenog korišćenja i modifikovanja vrijednosti u program.

Definicije:

Za iskaz označen S, definiše se:

o DEF(S) = {X | iskaz S sadrži dodjelu vrijednosti promjenljivoj X}

o USE(S)= {X | iskaz S sadrži upotrebu promjenljive X}

Dodjela promjenljivoj X u iskazu S je ŽIVA (LIVE) u iskazu S1, ako postoji putanja

izvršavanja programa od S do S1 koja nigdje ne sadrži dodjelu vrednosti promjenljivoj

X. Na osnovu toga definiše se lanac dodjele-upotrebe (engl. definition-use chain skr.

DU chain) promenljive X u oznaci [X, S, S1], gdje su:

o S i S1 su iskazi i

o X DEF(S) i

o X USE(S1) i

24

o dodjela promjenljivoj X u iskazu S je živa u iskazu S1.

Prilikom testiranja softvera ovom metodom, potrebno je pokriti svaki DU lanac u

programu bar jednom.

Primjer:

Program Example()

Var staffDiscount, totalPrice, discount, price

Input( staffDiscount) (S1)

input(price) (S3)

if(price!=-1) do (S4)

totalPrice=price (S5)

else

totalPrice=0 (S6)

end if (S7)

print(“Total price” + totalPrice) (S8)

if(totalPrice>15.00) then (S9)

discount=(staffDiscount*totalPrice) +0.5 (S10)

else

discount=staffDiscount*totalPrice (S11)

end if

print(“Discount” + discount) (S12)

end program

25

Du lanci za promjenljivu price:

DEF: S3 [dodjela]

USE: S4, S5 [upotreba]

Postoji 2 DU lanca:

1. C1=[price,S3,S4];2. C2=[price,S3,S5];

DU lanci za promjenljivu totalPrice:DEF: S5, S6USE: S8, S9, S10, S11

Postoji 8 DU lanaca:

1. C3=[ totalPrice,S5,S8];2. C4=[ totalPrice,S5,S9];3. C5=[ totalPrice,S5,S10];4. C6=[ totalPrice,S5,S11];5. C7=[ totalPrice,S6,S8];6. C8=[ totalPrice,S6,S9];7. C9=[ totalPrice,S6,S10];8. C10=[ totalPrice,S6,S11];

DU lanci za promjenljivu staffDiscount:DEF: S1USE: S10, S11

Postoji 2 DU lanca:

1. C11=[ staffDiscount,S1,S10];2. C12=[ staffDiscount,S1,S11];

DU lanci za promjenljivu discount:DEF: S10, S11USE: S12

Postoji 2 DU lanca:

1. C13=[ discount,S10,S12];2. C14=[ discount,S11,S12];

26

Primjeri:

Prim1:Price=5TotalPrice=5;StaffDiscount=0.2Discount=2.4

Ovaj primjer pokriva lance:c1,c2,c3,c6, c14,c11

Prim 2:Price=-1TotalPrice=0;StaffDiscount=0.1Discount=0

Ovaj primjer pokriva lance:c7, c10,c8,c9

Prim 3:Price=20TotalPrice=20;StaffDiscount=0.1Discount=2.5

Ovaj primjer pokriva lance: c4, c5,c13,c12

5.2.6. Pokrivanje bazičnih putanja

Pokrivanje bazicnih putanja zahtjeva da svaka nezavisna(bazicna ) putanja u kodu mora biti istestirana.

Ova metoda zahtjeva crtanje flowgrafa.

Pravougaonici pokazuju sekvencu koraka koji se izvršavaju bezuslovno. Rombovi prikazuju logički uslov ili predikat. Neki primjeri logičkih predikata su if-then, if-then-else, selection, loops. Strelice prikazuju tok kontrole. Za svaki pravougaonik postoji tačno jedna strelica koja izlazi iz njih. Za predikat, postoje 2 strelice koje izlaze – jedna za pozitivan , i jedna za negativan ishod.

27

Skup putanja naziva se bazičnim ako i samo ako su

– Putanje u skupu međusobno linearno nezavisne i– Bilo koja druga putanja u flowgraf - u može biti predstavljena kao linearna

kombinacija putanja iz posmatranog skupa

Koristeći flowgraf, možemo izračunati broj linearno – nezavisnih (bazičnih) putanja, nazvan cyclomatic number (ciklomatska kompleksnost) – V(g).

V(G)= broj predikata (rombova)+1.

Takođe, drugi način za računanje broja ciklomatske kompleksnosti je:

• V(G) = e – n + 2 za grafove sa jednim početnim i jednim završnim čvorome – broj grana grafan – broj čvorova grafa

Primjer:

void foo (float y, float a *, int n){float x = sin (y) ; (1)

if (x > 0.2) (2)z = tan (x) ; (3)

else z = cos (x) ; (4)int i = 1 (5)while ( i < y ) { (6)

a[i] = a[i] * z ; (7)Cout < < a [i] ; (8)i++; (9)

}

28

U ovom primjeru postoje 2 binarne odluke, pa je stoga V(G)=3

29

2

43

5

6 10

7

1

true

false

true

false

8

9

Iz ovoga slijedi da imamo 3 linearno nezavisne putanje:

1. 1, 2, 3, 5, 6, 7, 8, 9, 10

2. 1,2,4,5,6,7,8,9,6, 10

3. 1,2,3,5,6,10

30

Primjeri za ove 3 putanje:

1. y=20

2. y=2

3. y=1

Literatura

1. TESTIRANJE SOFTVERA – STRATEGIJE TESTIRANJA

2. White Box Testing Tutorial – 2: Basis Path Testing – Estimation of Complexity Measure V(G)http://www.scribd.com/doc/16191205/White-Box-Testing-Tutorial-2-Basis-Path-Testing

3. Data flow testing, http://www.cs.swan.ac.uk/~csmarkus/CS339/presentations/20061202_New_Data_Flow_Testing.pdf

4. Metodologija testiranja softverskog proizvoda, Slavica Boštjancic, Mirjana Stojanovic, Ranko Nedeljkovic, http://2007.telfor.rs/files/radovi/09_03.pdf

5. Osnove programiranja u jeziku C++, http://sites.google.com/site/sandasutalo/vjezbenica/zadatci---struktura-petlje

6. TESTIRANJE PROGRAMSKE OPREME, testiranje toka podataka, Ivana Podnarhttp://old.tel.fer.hr/files/cetvrta/PTS/test_skripta.pdf

7. Standardi u testiranju softvera, Nadica Raicevic, http://www.standardi.yubc.net/index.php?option=com_docman&task=doc_view&gid=23

31