Veleučilšte u Šibeniku

Šibenik

Seminarski rad

Lipanj, 2011.

Veleučlište u Šibeniku

Šibenik

Testiranje softvera

Kolegij: Softversko inženjerstvo

Profesor: Dipl.ing. Frane Urem

Student: Dragan Župan

Br indeksa: 129331073

Lipanj, 2011.

Sadržaj:

1. Uvod 12. Tesiranje softvera 2

2.1. Zašto testirati softver 32.2. Otklanjanje grešaka 3

3. Ciljevi testiranja 43.1. Zahtjevi za stalnim razvojem 53.2. Poboljšanje procesa testiranja

6

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

5. Klasifikacija i metode testiranja 85.1. Metode Crne kutije 8

5.1.1. Podjela na klase ekvivalencije 85.1.2. Analiza graničnih vrijednosti 85.1.3. Uzročno.posljedični graf 9

5.2. Metode bijele kutije 95.2.1. Pokrivanja iskaza (Statement Coverage) 95.2.2. Pokrivanje odluka (Decision Coverage) 105.2.3. Metoda graničnog testiranja unutrapnje putane (Boundary Interior Path

Testing)6. Zaključak

1. Uvod

Tema ovog seminarskog rada je testiranje softvera. Rad je pisan indukcijsko – dedukcijskom

metodom, a podijeljen je na tri dijela.

U prvom dijelu objašnjava se općenito testiranje softvera, zašto se testira te kako se otklanjaju

greške na softveru.

U sljedećem dijelu govori se o ciljevima testiranja i mogućnostima poboljšanja.

U posljednjem dijelu navedene su metode testiranja koje možemo podijeliti na metode Crne

kutije te metode Bijele kutije.

2. Testiranje softvera

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 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 poboljšanja.

Ono nije aktivnost koja počinje samo nakon kompletiranja faze kodiranja. Softversko

testiranje se danas vidi kao aktivnost koja obuhvaća cijeli proces razvoja i održavanja, i

predstavlja važan dio kompletne konstrukcije softvera. Planiranje testiranja treba početi 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 izbjeći probleme nego ih ispravljati...kao i za sve ostale životne situacije fraza

je neizbežna da je bolje sprečiti, nego liječiti. Stoga, stvari su vrlo jednostavne - Softver je kao

i život. Ima neminovnih grešaka, naše je da ih svedemo na minimum ili potpuno uklonimo.

Treba stvoriti harmoniju i balans.

2.1. Zašto testirati softver

Zato što su veliki gubitci kompanija koje razvijaju softver upravo zbog velikog broja defekata

u isporučenom softveru kupcima. Prvenstveni zadatak test inženjera 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 inženjera se zahtjeva da otkrije što je

moguće više problema i to što više onih, vrlo ozbiljnih čije posljedice mogu biti katastrofalne

sa materijalnog i sigurnosnog 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. Otklanjanje grešaka

Posebna pažnja danas se posvećuje aktivnosti otkrivanja grešaka. Ovo je bitna razlika u

odnosu na shvaćanje da je važno 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. Nemoguće je otkriti sve greške u softveru. Nemoguće je

dokazati da je softver bez greške. Takođe je jasno da je nemoguće pobjediti prosto uvjerenje o

imperativu da se otkriju sve greške.

Pristup testiranju softvera na bazi otklanjanja grešaka je proces koji je podložan greškama.

Tester softver mora identificirati i slijediti 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.

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 provođenja aktivnosti

prevencije nastanka grešaka. U posljednje vrijeme je razvijen veliki broj metoda u cilju

spriječavanja nastanka grešaka u softveru- metoda dokazivanja korektnosti sofrvera, strategija

projektiranja po Six Sigma i mnoge druge.

3. Ciljevi testiranja

Dva su osnovna, glavna i najveća 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 očekivanim rezultatima pojedine

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

Dva su osnovna cilja su otkriti nedostatke (greške) i procijeniti koliko je sistem upotrebljiv.

Verifikacija i validacija treba stvoriti povjerenje da je softver spreman za produkciju i to ne

znači da je softver potpuno bez nedostataka, ali mora biti dovoljno dobar da može 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 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 podacima, ispitivanje

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

3.1. Zahtjevi za stalnim razvojem

Postoji veliki nesklad između sve složenijih softverskih rješenja i tehnika, alata koji se

primenjuju u procesu razvoja softvera i procesa testiranja softvera. Zahtjevi za softverskim

rješenjima u svim područjima dramatično rastu uz konstantan zahtjev: brže, bolje i jeftinije. S

druge strane, i očekivanja korisnika softvera su ne realno velika. Zahtjevi za razvoj i testiranje

softverskog proizvoda daleko prelaze znanje i iskustvo programera i menadžera na tržištu.

3.2. Poboljšanja procesa testiranja

Poboljšanja procesa testiranja je konstantan proces zajedno sa svim drugim elementima

razvoja softvera. Angažiraju se sve veći resursi kako velikih tako i malih kompanija u proces

testiranja i njegovo unapređenje.

Postoji više aspekata koji doprinose poboljšanju 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 postojećeg procesa testiranja

- identifikacije rizika i njihovih posledica na uspeh procesa razvoja

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 uvjeta (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 djelomič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 funkcioniranjem 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 verificiralo da li 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 developeri zainteresirani za otkrivanje softversih grešaka i njihovo

otklanjanje, korisnike softvera brinu softverski otkazi.

5. Klasifikacija i metode testiranja

U sljedeć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 promatranjem dobivenih 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 kvalitete programa. Detaljno testiranje kombinacija

različitih ulaznih podataka za većinu 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 različitih 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 graničnih vrednosti

- Testiranje zasnovano na tablici odlučivanja

5.1.1. Podjela na klase ekvivalencije

Klase ekvivalencije definiramo 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 cijeli skup ulaza

(relacija “sličnosti” ulaza je relacija ekvivalencije)

Klase ekvivalencije se određuju 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 obuhvaćaju dopuštene situacije.

– nelegalne klase obuhvaćaju sve ostale situacije.

5.1.2. Analiza graničnih vrijednosti

Posebnu pažnju treba 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 participiranja. Analiza granične vrijednosti se određuje na osnovu

sledećeg:

Ako ulazni uvjet specificira stanje okvirno u rasponu od vrijednosti A do B, dobiva se 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 trebaju biti izrađeni za vježbu sa

minimalnim i maksimalnim brojkama

5.1.3. Uzročno - posljedični grafovi

Testiranje softvera bi bilo znatno olakšano kada bi se mogli automatski generirati test primjeri

iz zahtjeva. Stoga je potrebno analizirati zahtjeve i preformulirati ih u vidu logičke relacije

između ulaza i izlaza. Rezultat se može predstaviti u obliku 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. Redovi tabele odgovaraju test primjerima. Kolone se definiraju analiziranjem

čvorova posljedica u uzročno – posljedičnom grafu. Upotrebom tabele odlučivanja broj test

primjera se značajno smanjuje.

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 sljedeće tehnike testiranja bijele kutije:

1. Pokrivanje iskaza (Statement coverage)

2. Pokrivanje odluka (Decision coverage)

3. Pokrivanje uvjeta

4. Metoda graničnog testiranja

5.2.1. Pokrivanje iskaza (Statement coverage)

Svaki iskaz u programu se mora bar jednom izvršiti, jer ne možemo znati da li u bilo kojem

iskazu postoji greška ukoliko ga ne izvršimo bar jednom.

Međutim, ne možemo garantirati da će se iskaz koji se ispravno izvršavao za jednu ulaznu

vrijednost , isvršavati ispravno i za neku drugu ulaznu vrijednost, što je loša strana ove

tehnike.

5.2.2. Pokrivanje odluka (Decision coverage)

Svaka od uvjetnih grana se izvršava najmanje jednom. Ova metoda je jača 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 složenog uvjetnog izraza uzima i točnu i netočnu 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 graničnog testiranja unutrašnje putanje (boundary interior path testing)

Zahtjeva pokrivanje sljedeć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.

5. Zaključak

Posljednih godina je intenzivirano istraživanje u oblasti testiranja softvera u svijetu, kao i

zbog mnogih neriješenih problema u ovom području. 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 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