You are on page 1of 23

FAKULTET ZA INFORMACIONE TEHNOLOGIJE

PODGORICA

SEMINARSKI RAD
OBEZBJEĐENJE KVALITETA I TESTIRANJE SOFTVERA

TESTIRANJE SOFTVERA

Profesor: Student:

Student:
Prof. Dr Radomir Vukasojević Pekić Željko
Testiranje softvera

M/09-09

Podgorica, Decembar, 2009.

Sadržaj

Sadržaj.......................................................................................................................................................2
Uvod..........................................................................................................................................................3
Testiranje softvera.....................................................................................................................................3
Tehnike softverskog testiranja..................................................................................................................7
Vrste softverskog testiranja.......................................................................................................................9
Strukturalno testiranje –"White-box"........................................................................................................9
Funkcionalno testiranje...........................................................................................................................12
Metoda crne kutije –"Black-box"............................................................................................................12
Ekvivalentno particionisanje...................................................................................................................16
Cause – Effect Graphing Techniques......................................................................................................17
Testiranje putem grafikona......................................................................................................................18
Error Guessing.........................................................................................................................................18
Testiranje performansi.............................................................................................................................19
Poboljšanja procesa testiranja.................................................................................................................21
Instalaciono testiranje..............................................................................................................................21
Zaključak.................................................................................................................................................22
Literatura.................................................................................................................................................23

Željko Pekić Stranica 2


Testiranje softvera

Uvod

Razvojem mikroelektronike, informatičke i komunikacijske tehnologije, rješenja


zasnovana na računarima primjenjuju se u svim područjima ljudskog djelovanja.
Izvršavanje i najbizarnijih poslova postalo je danas zavisno od ispravnosti rada
računara. Računar se sastoji od sklopovkse opreme, njegovog fizičkog dijela i
programske podrške, koja predstavlja uputstva fizičkom dijelu kako da izvrši
postavljeni zadatak. Za ispravan rad neophodno je da su ispravna oba, odnosno
sklopovski i programski dio. Kako bi se postigao željeni kvalitet prije nego se
programska rješenja puste u eksploataciju, vrše se zahtjevna testiranja sa ciljem
uklanjanja što je moguće više grešaka.

Testiranje programske podrške je proces traženja grešaka. U njemu su


obuhvaćene sve aktivnosti potrebne za vrednovanje sposobnosti programa da
izvši pred njim postavljeni zadatak, kao i za tumačenje dobijenih rezultata.
Programska podrška nije poput drugih fizičkih sistema koji za date ulazne veličine
generišu odgovarajuće izlazne veličine. Razlika je u načinu u kojem dolazi do
pojave kvara. Kod većine fizičkih sistema do kvara dolazi zbog određenog i
najčešće nerazboritog skupa stanja koja u sistemu mogu nastupiti usled
spoljašnjeg uticaja. Do pojave grešaka u programskoj podršci dolazi zbog mnogo
bizarnih razloga. Detektovati sve različite modove kvara kod programske podrške
je opšte neizvodljivo.

Testiranje softvera

Testiranje softvera (ili samo testiranje) je bio prvi softverski alat za osiguranje
kvaliteta softvera koji se primjenjivao za kontrolu softverskih produkata prije
njihove isporuke ili instalacije kod klijenta. Na početku, testiranje je bilo
ograničeno na završnu fazu razvoja softvera. Kasnije, zbog važnosti ranije
detekcije softverskih defekata, a i da bi se ispunili koncepti osiguranja kvaliteta
softvera, SQA profesionalci su inicirali proširenje testiranja i na testiranje u
procesu kodiranja, što je dovelo do testiranja softverskih modula (unit testing) i
kompletnog integracionog testiranja.

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.

Željko Pekić Stranica 3


Testiranje softvera

Riječi i fraze u definiciji omogućavaju nam da poredimo glavne karakteristike


testiranja softvera sa d rugim alatima životnog ciklusa SQA:
■ Formalni proces – Planovi testiranja softvera su dijelovi razvoja projekta i
plana kvaliteta, sa unaprijed danim vremenskim rasporedom i aktivnostima
postignutim dogovorom izmeĎu klijenta i razvojnih inženjera.
Drugim riječima, ad hoc ispitivanje softvera od strane kolega ili regularne
provjere od strane tim lidera ne sačinjavaju testiranje softvera.
■ Specijalizirani tim za testiranje– Nezavisni tim ili eksterni konsultanti koji su
specijalizirani u testiranju izvršavaju testiranje uglavnom u namjeri da eliminiraju
pristranost i da garantiraju efektivno profesionalno testiranje. Generalno je
prihvaćeno da testovi koji se izvršavaju od strane developera koji su i pisali
softverski kod, vode do siromašnih rezultata jer je tako teško otkriti greške, jer
se radi o greškama, koje sami developer nisu bili u mogućnosti identifikovati
ranije. Još uvijek se testiranje, posebno testiranje programskih modula (unit)
nastavljaju da izvršavaju od strane developera u mnogim organizacijama.
■ Izvršavanje programa – Bilo koja forma aktivnosti osiguranja kvaliteta
softvera koja ne uključuje izvršavanje softvera, kao npr. inspekcije koda, ne
mogu se smatrati testom.
■ Odobrene test procedure – Procesi testiranja se izvršavaju u skladu sa
testnim planom i procedurama testiranja koje su odobrene i prilagoĎene od
strane softverske kompanije i u skladu sa SQA procedurama.
■ Odobreni test slučajevi – Slučajevi testiranja (test cases) koji se ispituju se u
potpunosti definiraju sa testnim planom. Izostavljanje ili dodavanje se ne očekuje
tokom procesa testiranja.

Testiranje je aktivnost izvedena radi evaluacije kvaliteta proizvodnje i njegovog


poboljšanja, putem identifikovanja defekata i problema. 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.

Testiranje softvera i otkrivanje grešaka

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


razlika u odnosu na shvatanje da je važno potvrditi da program ili sistem radi.
Ova definicija testiranja softvera je napisana u knjizi Glenford Majers "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 dokazati

Željko Pekić Stranica 4


Testiranje softvera

da je softver bez greške. A takođe je nemoguće povinovati se prostom


imperativu i naći sve greške.

Zašto testiranje?

Zato što su veliki gubici kompanija koje razvijaju softver upravo zbog velikog
broja defekata u isporučenom softveru. Prvenstveni zadatak test inženjera je
otkrivanje problema u softveru sa ciljem da se oni otklone prije predaje
softverskog proizvoda kupcu.

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.

Testiranje softvera je proces verifikacije programa ili sistema sa ciljem otkrivanja


i ispravljanja grešaka i predstavlja integralni dio razvoja softvera. Primenjuje se
u svakoj fazi razvojnog ciklusa,a obuhvata više od 50% vremena potrebnog za
razvoj softvera.

Vrijeme za testiranje?

Ukoliko se uspostavi strožiji proces obezbijeđenja kvaliteta softvera u pogledu


efikasne prevencije i detekcije grešaka, utoliko mijenjamo opšte mišljenje o tome
kako se obezbjeđuje visok kvalitet softverskog proizvoda. Drugi 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. Potrebno 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.

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

Željko Pekić Stranica 5


Testiranje softvera

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 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 njjima, 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 druge.

Kada prestati testirati?

Testiranje se praktično može izvoditi beskrajno. Nikad se ne može sa sigurnošću


reći da su otkriveni i uklonjeni svi mogući defekti. Ali u jednom trenutku treba
prestati testirati. Pitanje je kada to učiniti? 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 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. Svaki proces vrednovanja zahtijeva ponavljanje izvođenja
sledećih ciklusa: prikupljanja podataka koji dovode do greške, modeliranja i
predviđanje. 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.

Željko Pekić Stranica 6


Testiranje softvera

Tehnike softverskog testiranja

Tehnike testiranja odnose se na različite metode ispitivanja pojedine funkcije


računarskog programa,sistema ili softverskog proizvoda. Svaki tip testiranja ima
sopstvenu tehniku testiranja,a neke tehnike kombinuju funkcije oba tipa. Važnost
softverskog testiranja i njegovog uticaja na softver ne može biti podcijenjena.
Softversko testiranje je osnovna komponenta osiguranja softverskog kvaliteta i
predstavlja pregled specifikacija,dizajna i kodiranja. Veća vidljivost softverskih
sistema i troškovi povezani sa softverskim neuspehom su motivirajući faktori za
napredno planiranje, putem testiranja. Veoma je neugodno za softversku
oganizaciju kada utroši više od 40% svog rada na testiranje..

Osnove softverskog testiranja

Tokom testiranja softversko inženjerstvo izrađuje seriju test slučajeva koji se


koriste „rip apart“ (izdvajanje posebnih delova) softvera koji se proizvodi.
Softverski inženjeri su obično stvaraoci koji poznaju unaprijed predviđene
koncepte testiranja i bave se pronalaženjem i ispravljanjem grešaka kada one
budu identifikovane.

Dizajn test slučaja

Izrada dizajna softverskog testiranja može biti izazovan proces. Softverski


inženjeri testiranje često vide kao “zakašnjelu misao” (afterthought), međutim,
prilikom izrade pravog test slučaja još uvek nisu sigurni u njegovu kompletnost.
Cilj testiranja je u pronalaženju najviše mogućih grešaka uz minimalni utošak
vremena i napora za to. Razvijen je veliki broj metoda dizajna test slučajeva koji
nude developer-u sistematičan pristup testiranja. Metode nude pristup koji može
obezbijediti kompletnu analizu i ponuditi najviše mogućnosti za otkrivanje
grešaka u sofveru.

Test protoka informacija

Postoje dvije vrste tipa ulaznih koje se uzimaju pri testiranju protoka informacija
• Softverska konfiguracija i
• Test konfiguracije.

Testiranja se obavljaju i svi rezultati testa se porede sa očekivanim


rezultatima.Kada je pogrešan podatak identifikovan, greška je podrazumijevana i
započinje se debugging. Postupak debugging-a (ispravljanja greške) je
nepredvidiv element procesa testiranja. Identifikovanje i ispravak greške koja

Željko Pekić Stranica 7


Testiranje softvera

ukazuje na odstupanje od 0,01% između stvarnih i očekivanih rezultata, može


trajati satima, danima ili mjesecima.

Ciljevi softverskog testiranja

Pravila koja deluju na cilj testiranja su:


• Testiranje je proces izvršavanja programa, sa ciljem pronalaženja grešaka
• Dobar test slučaj će imati dobre šanse u pronalaženju neotkrivene greške
• Uspješan test slučaj otkriva novu grešku

• Softverska konfiguracija
• Test konfiguracije

Tip testiranja se bavi testiranjem cjelokupnog softvera, a tehnike testiranja se


bave određenim delovima softvera koje treba testirati. Drugim riječima,mi
testiranjem svake funkcije softvera možemo provjeriti da li je softver operativan,
ili možemo testirati interne komponente softvera kako bi provjerili njegovu
internu poslovnost prema specifikaciji softvera. Sa druge strane, ”tehnike
testiranja” obuhvataju niz metoda i načina koji se primjenjuju, kao i proračuna za
testiranje određene funkcije nekog softvera (ponekad se testira interfejs,
ponekad testiramo segmente, ponekad petlje i sl.)

Željko Pekić Stranica 8


Testiranje softvera

Vrste softverskog testiranja

Vrste pristupa za identifikovanje grešaka u softveru:

• Statičko
• Dinamičko

Postoje različite vrste pristupa testiranja (testiranje računarskog


programa,testiranje sistema ili testiranje softverskog proizvoda). Dvije osnovne
vrste pristupa su „Black box“ i „White box“ testiranje. U novije vrijeme razvile
su se „Grey box“ testiranje ili hibridno testiranje (ponekad nazvano kao
staklena kutija „glass box“) , koje objedinjuje funkcije obije vrste pristupa
testiranja. Testovi su osmišljeni i fokusirani na tačke gledišta kupaca – korisnika.
Testeri kombinacijom oba pristupa utvrđuju ispravnost i mogućnost novog
implementiranja na osnovu korisničkih želja.

Strukturalno testiranje –"White-box"

Bijela kutija (White Box) je model za sistem o kome sve znamo, tj. Čije
elemente, strukturu i ponašanje poznajemo.

Ovo testiranje provjerava i analizira izvorni kod i zahtijeva 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
Željko Pekić Stranica 9
Testiranje softvera

izvršava barem jednom, provjerom svih funkcija ili provjerom svih mogućih
kombinacija različitih programskih naredbi.
To je objekat kod kojega su poznati zakoni ponašanja i procesa u njemu kao
dinamičkom sistemu, i na osnovu toga, saznata njegova funkcija i struktura.
Specifičnim testovima može se provjeravati postojanje beskonačnih petlji ili koda
koji se nikada ne izvršava. Kodna pokrivenost je navedena u 6 sledećih koraka:

• Segment pokrivenost – svaki segment koda u B/W kontroli strukture se


izvršava makar jednom
• Područna rasprostranjenost ili čvorno testiranje – svaki ogranak u
kodu se koristi u jednom mogućem smjeru barem jednom
• Složeno stanje rasprostranjenosti – kada postoji više uslova, mora se
testirati ne samo svaki smer, već i sve moguće kombinacije uslova, što se
obično obavlja pomoću kombinacijske tabele (Truth Table)
• Osnovni put testiranja – svaka nezavisna staza kroz kod koristi
prethodno definisan niz
• Testiranje toka podataka – u ovom pristupu, skup srednjih staza kroz
kod definiše praćenje specifičnih promjenljivih kroz svaki mogući proračun.
Praćenje se zasniva na svakom odabranom pojedinačnom dijelu koda. Iako
ove staze smatraju nezavisnim, zavisnosti između višestrukih staza
zapravo nisu testirane za ovaj pristup. DFT (engl. Data Flow Testing) teži
da održava zavisnosti, ali to je uglavnom kroz manipulaciju sekvenci
podataka. Ovaj pristup prikazuje skrivene bagove i koristi ih kao
promjenljive, deklariše ih- ali ih ne koristi.
• Put testiranja – put testiranja definiše i pokriva sve moguće puteve kroz
kod. Ovo testiranja su vrlo teška i dugotrajana.
• Testiranje petlje – ove strategije se odnose na testiranju jedne petlje,
grupnih petlji i ispletenih petlji. Zavisnost petlji je prilično jednostavno
testirati, osim ako postoji među petlja ili kod sadrži B/W petlju.

U White box testingu, koristi se kontrola strukture proceduralnog dizajna za


dobijanje test slučajeva. Korišćenjem White box testing metoda jedan tester
može izvući probne slučajeve koji:

• Garantuju da sve nezavisne staze u modulu budu istestirane barem


jednom.
• Izvršavaju sve logičke odluke o njihovoj istinitosti ili lažnoj vrijednosti
• Izvlače sve petlje na sopstvenim granicama i unutar svojih dozvoljenih
operativnih granica.
• Upotrebljava unutrašnje strukture podataka kako bi obezbijedio njihovu
valjanost.

Željko Pekić Stranica 10


Testiranje softvera

Testiranje “bijele kutije” (staklene kutije)

Ovu vrstu testiranja može da obavlja ili programer koji je napisao program ili
neko drugi kome je specijalnost testiranje softvera. Testiranje se naziva »bela
kutija« zato što je onom ko testira poznat algoritam ili programski kod.

Posmatrajmo sledeći primer programa napisanog u pseudokodu:


if podatak < 100 then
print(‘Loša ocena’)
else
if podatak <200 then
display(‘Moglo je bolje’)
else
if podatak <300 then
display(‘Dobro’)
else
display(‘Vrlo dobro’)
endif
endif
endif
Pošto osoba koja testira program može da vidi program onda je u stanju da
proveri saki deo programa tako što će testirati program za razne vrednosti
podatka: za manje od 100, između 100 i 200, između 200 i 300, i na kraju za
300 ili više od 300.

Željko Pekić Stranica 11


Testiranje softvera

Funkcionalno testiranje

Analizira se samo izvršavanje specificiranih funkcija i vrši se provjera ulaznih i


izlaznih podataka. Tačnost izlaznih podataka provjerava se na osnovu
specifikacije zahtjeva za softver. U ovim testovima se ne vrši analiza izvornog
koda. Problem funkcionalnog testiranja može da se pojavi u slučaju dvosmislenih
zahtjeva i nemogućnosti opisivanja svih načina korišćenja softvera. Skoro 30%
svih grešaka u kodu posljedica su problema nepotpunih ili neodređenih
specifikacija.

Metoda crne kutije –"Black-box"

Sinonimi za black box uključuju: ponašanje, funckionalnost, neprozirnost i


zatvorenost.

Testiranjem se pokušavaju pronaći greške u sledećim kategorijama:


• Neispravna ili nepotpuna funkcija
• Greška interfejsa
• Greška u strukturi podataka ili u pristupu spoljnoj bazi podataka
• Greška performanse
• Greška inicijalizacije i greška izvršavanja

Metoda crne kutije(Black Box Method) se često upotrebljava u raznim strukama


kad se želi saznati ponašanje nekoga sistema, jer ona slijedi osnovna
podešavanja sistemskog pristupa. To je model za sistem čiju unutrašnjost ne
poznajemo ili u čiju unutrašnjost ne možemo ili ne želimo ući. O svojstvima
sistema zaključujemo na osnovu posmatranja ulaza i izlaza.

Primenom metode crne kutije izrađuje se skup test slučajeva koji ispunjavaju
zahtjeve:
• Test slučaja koji smanjuju broj test slučaja na mogućnost razumnog
testiranja
• Test slučaja koji će nam prikazati prisutnost ili odsutnost klase grešaka

“Crnu kutiju“ predstavlja svaki neistraženi objekat ili pojava, čije ponašanje se
istražuje kontrolisanim djelovanjem na taj objekat i proučavanjem reakcija
objekata na ta djelovanja. Pod njom se podrazumijeva onaj objekat ili pojava
koja se predstavlja na dinamički sistem, odnosno sistem koji pod spoljnim
uslovima mijenja svoja stanja, ali se ne raspolože informacijama o procesu u
“crnoj kutiji”, nepoznata je zakonitost ponašanja pojave. Najkraće, to je bilo

Željko Pekić Stranica 12


Testiranje softvera

koji objekat o kojem se sudi na osnovu spoljnjih manifestacija bez poznavanja


strukture objekta.

Faze metode crne kutije su:


• Definisanje sistema
• Definisanje sistema kao crne kutije
• Određivanje ulaza i izlaza
• Rasčlanivanje sistema
• Istraživanje ponašanja elemenata pomoću neposredne primjene metode
crne kutije
• Definisanje modela sistema
• Eksperimentisanje ili utvrđivanje svojstva sistema pomoću modela
• Definisanje rezultata.

Definisanje sistema, se mora izvršavati na osnovu postavljene svhe i cilja


istraživanja. Svrha i cilj istraživanja određuju što će se smatrati karakteristikama
sistema, a što okolinom sistema. Postoje sistemi koje je relativno jednostavno
definisati(jedan čovjek, jedna porodica, jedno preduzeće i sl.), i oni koje je teže
definisati (sistemi informisanja, sistemi obrazovanja, turistički sistemi i sl.).

Definisanje crne kutije. Određivanjem elemenata i granicama sistema


određeno je i sve što spada u crnu kutiju. Sledeći je problem definisanje uloge i
funkcije sistema.

Definisanje ulaza i izlaza. Ulaz u sistem predstavlja uticaj okoline na sistem.


Kod metode crne kutije bitan je samo onaj ulaz u sistemu koji ima nekog odraza
na izabrane reprezentantne funkcije (može biti neki fenomen, agens ili računska
veličina, koja dobra odražava funkciju i kvlaitet funkcionisanja sistema, a može
se ili izmjeriti ili izračunati). Izlaz iz sistema predstavlja uticaj sistema na okolinu.
Kod metode crne kutije bitan je samo onaj izlaz koji ima nekog odraza na
reprezentantne funkcije sistema. Ulazi i izlazi iz sistema mogu biti najrazličitije
prirode, ali je bitno da se njihove vrste, veličine i intenzitet mogu odrediti i
ustanoviti uticajem njihovih promjena na reprezentantne funkcije.

Rasčlanivanje sistema, na podsisteme i elemente mora se vršiti vrlo smišljeno


i postepeno i ono mora biti u punom smislu heuristički postupak. Nespretnim
rasčlanivanjem sistema može se i relativno jednostavan problem učiniti
nerješivim.

Istraživanje ponašanja elemenata i procesa. Nakon rasčlanjivanja složenog


dinamičkog sistema i njegove razrade u obliku objektograma (može biti dobra
osnova za definisanje matematičkog modela) i funkciograma (može biti dobra
osnova za utvrđivanje vremenskih odnosa u sistemu) prelazi se na primjenu
metode crne kutije za svaki proces i element. Imamo dvije vrste procesa u
Željko Pekić Stranica 13
Testiranje softvera

sistemima, deterministički (potpuno određen) i stohastički (na osnovu


poznavanja vrste i veličine ulaza može samo sa određenom vjerovatnoćom
pretpostaviti vrsta i količina izlaza).

Definisanje modela sistema. Da bi se mogao postaviti matematički model


dinamičkog sistema potrebno je uz pomoć metode crne kutije definisati:
• Sve operatore transformacija svih procesa u sistemu
• Matematički opisati sve veze u sistemu
• Istražiti vremenske odnose u sistemu.

Eksperimentisanje ili utvrđivanje svojstva sistema pomoću modela.


Nakon izrade matematičkog modela vrši se istraživanje svojstava sistema
eksperimentisanjem. Eksperimentisanje u matematičkom smislu znači zadavanje
ulaznih veličina i proračun izlaznih veličina pomoću sistema jednačina. Sa njim
možemo da mijenjamo ulazne veličine, strukturu sistema i operatore
transformacija elemenata.

Definisanje rezultata. Imamo dvije vrsta definisanja rezultata, analitičkim i


simulacijskim modelom. Analitičkim modelom se sastavljaju od skupa
matematičkih jednačina koje se dobijaju matematičkim izvođenjem. Konačni
rezultati dobiju se uvrštavanjem početnih veličina u sistem jednačina.
Simulacijskim modelom računari simuliraju, tj. Oponašaju tokove procesa. Oni
zahtijevaju mnogo više računskih operacija od analitičkih modela i njihov razvoj
je vezan uz pojavu i mogućnost računara.

Prednosti Black box testinga

• Testiranje može biti ne – tehničko


• Ovo testiranje će najverovatnije pronaći one bagove koje je korisnik
pronašao
• Testiranje pomaže u identifikovanju nejasnoća i protivrječnosti
funkcionalnih specifikacija
• Test slučajevi mogu biti izrađeni po završetku funkcionalnih specifikacija.

Iako je osnovni cilj metode “crne kutije” transformisati predmet proučavanja u


“bijelu kutiju”, taj cilj nije moguće nikada apsolutno ostvariti, jer u bilo kojoj
“bijeloj kutiji” ostvaje uvijek nešto neobjašnjeno, nepoznato. To je posledica, ne
samo ograničenog znanja i motivacije istraživača, raspoloživog vremena, nego i
same prirode predmeta proučavanja.

Cilj svake sistemske analize treba biti da svaki sistem koji za nas na početku
predstavlja crnu kutiju pretvorimo u bijelu kutiju.

Željko Pekić Stranica 14


Testiranje softvera

Nedostatci Black box testinga

• Šanse za ponavljanje testova koje je već odradio programer


• Test input zauzima veliki dio prostora
• Teško je utvrditi sva moguća testiranja ulaza u ograničenom vremenu.
Pisanje test slučaja je prilično sporo i teško
• Šanse za posjedovanje neidentifikovanih staza tokom testiranja

Alati koji se koriste u Black box testingu

Osnovni funkcionalni alati testiranja izvode rezultate testova crne kutije u obliku
skripte. Jednom izvedene, ove skripte mogu koristiti u budućem razvoju softvera,
kao aplikacija koja verifikuje novu funkcionalnost, a da ne onemogući prethodnu.

Testiranje “crne kutije”

Testiranje “crne kutije” se tako naziva jer je programski kod ili algoritam nevidljiv
osobi koja vrši tetsiranje. test se sprovodi tako što se programu (crnoj kutiji)
daju razlišiti podaci i posmatra ponašanje algoritma. Da bi se postigao efekat
testiranja, kod ove vrste testova se test podaci pripremaju pre izrade programa,
imajući na umu samo programske zahteve date u psecifikaciji programa.

Za ovu vrstu testa se obično planiraju tri vrste testnih podataka :


• Ispravni podaci
• Neispravni podaci
• Granične vrednosti podataka

Za predhodni primer, ispravni podaci bi bili recimo 34, 150, 250, neispravni
recimo ako umesto cifara damo slova, a graničnim slučajevima se mogu smatrati
podaci 99,100,101,199,200,201,299,300 i 301.

Željko Pekić Stranica 15


Testiranje softvera

Ekvivalentno particionisanje

Ekvivalentno particionisanje je metoda testiranja crne kutije koja dijeli ulazni


softverski domen u klasu podataka od kojih se izrađuju test slučajevi. Idealan
test slučaja otkriva klasu grešaka prije nego što je greška detektovana.
Ekvivalentnost particionisanja pokušava da identifikuje naznačenu klasu grešaka
u test slučaju. Dizajn test slučaja za ekvivalentnost particionisanja je zasnovano
na planiranju ekvivalentnih vrijednosti unosa (inputa). Ekvivalentne vrijednosti
prikazuju skup važećih i nevažećih ulaznih uslova (input conditions) u sistemu.
Ekvivalentna vrijednost može da se određuje na osnovu sledećeg:
• Ako je ulazni uslov (input conditions) specifičan niz, jedna važeća i dvije
nevažeće ekvivalentne vrijednosti su definisane
• Ako ulazni uslov (input conditions) zahtijeva specifičnu vrijednost, jedna
važeća i dvije nevažeće ekvivalentne vrijednosti su definisane
• Ako je ulazni uslov (input conditions) član specifičnog niza, jedna važeća i
jedna nevažeća ekvivalentna vrijednost je definisana
• Ako je ulazni uslov (input conditions) Bulova, jedna važeća i jedna
nevažeća ekvivalentna vrijednost je definisana.

Analiza granične vrijednosti

Veoma mnogo grešaka se pojavljuje u granicama ulaznog domena i iz tog razloga


se koristi analiza granične vrijednosti. Analiza granične vrijednosti pripada
dizajnu test slučaja koji upotpunjuje ekvivalentnost particionisanja. Analiza
granične vrijednosti izrađuje test slučaja i za domen izlaza takođe.

Analiza granične vrijednosti se određuje na osnovu sledećeg:

Željko Pekić Stranica 16


Testiranje softvera

• Ako ulazni uslov specfikuje stanje oivičeno u rasponu od vrednosti A do B,


dobijamo test slučajeve sa vrednostima 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
• Ove dvije stavke se primenjuju i na izlazne uslove (output conditions)
• Ako je softver interni, čije su strukture podataka u propisanim granicama,
izrađuje se test slučaja za vježbu strukture podataka u granicama.

Cause – Effect Graphing Techniques

Cause – Effect Graphing Techniques je pristup dizajna test slučaja koji nudi jedan
koncizan opis logičkih uslova i pridruženih akcija.
Pristup ima četiri faze:
• Cause (ulazni uslov) i Effect (radnja) navedeni su za modul i identifikacija
je dodjeljena za svaki
• Cause – Effect graph je izrađen
• Grafikon je izmijenio odluku u tabeli
• Tabela pravila odluke modifikovanja test slučajeva

Pojednostavljena verzija Cause – Effect graph simbola je prikazana ispod. U levoj


koloni figura daje različita logička udruženja među causes i c i effect i e. Desna
kolona pokazuje potencijalna prinudna (constraining) udruženja koja bi se mogla
primijeniti bilo na cause ili na effect.

Željko Pekić Stranica 17


Testiranje softvera

Testiranje putem grafikona

Softversko testiranje započinje stvaranjem grafikona važnih objekata i njihovih


veza i onda osmišljavanje niza testova koji će pokrivati grafikon, tako da svaki
objekat i veza budu iscrtan, a greška nepokrivena.

Error Guessing

Error Guessing dolazi sa iskustvom u tehnologiji i u projektu. Greška Guessing je


umijeće gdje greške mogu biti sakrivene. Ne postoje specijalizovani alati i
tehnika za to, ali može se pisati test slučaja u zavisnosti od situacije, da li
prilikom čitanja funkcionalnog dokumenta ili prilikom testiranja pronaći grešku
koja nije bila dokumentovana.

Željko Pekić Stranica 18


Testiranje softvera

Testiranje performansi

Testiranje performansi obuhvata pronalaženje i otklanjanje problema koji


degradiraju performanse softvera.

Ispitivanje performansi najčešće obuhvata:


• iskorišćenje procesorskih resursa,
• protok podataka i
• vrijeme odziva.

Tipični resursi koji se proveravaju su:


• propusni opseg,
• brzina procesora,
• iskorišćenje memorije,
• zauzetost prostora na disku.

U real time sistemima i ugrađenim sistemima, softver koji pruža potrebne


funkcije ponekad nije prihvatljiv u skladu sa performansama. Testiranje
performansi dizajnirano je za izvođenje run-time testa perfmormansi u
softverskom okruženju jednog integrisanog sistema. Testiranje performansi se
pojavljuje u svim procesima testiranja. Na primjer, metoda White box testiranja
pojedinačnog modula može se ponašati kao test performanse modula. Izvođenje
testa performansi često je povezano sa stress testom softvera i hardvera i
proveravanjem i mjerenjem iskorištenosti resursa (na primjer ciklus rada
procesora) u extremnim slučajevima. Stres testovi su najkorisniji kada se sistem
ugrađuje u veća okruženja, ili kada se prvi put implementira.

Web sajt, kao dio velikog sistema koji zahtijeva više pristupa i obrade podataka,
sadrži ranjive čvorove koji moraju biti testirani prije implementacije. Nažalost,
većina stres testiranja mogu samo da simuliraju različite vrste opterećenja na
tačke u sistemu, ali nemogu testirati cijelu mrežu. Na sreću, jednom kada se
uradi stres testiranje i faktori opterećenja budu uspješno prevaziđeni, potreban
ponovni stres testing se vrši samo u slučaju kada dođe do većih promjena. Mana
testiranja performansi je ta što potvrđuje validnost sistema u otežanim uslovima
obrade podataka,ali ne garantuje za njihovu tačnost i ispravnost.

Željko Pekić Stranica 19


Testiranje softvera

Regresivno testiranje

Regresivno testiranje potvrđuje da implementacija promena ne utiče negativno


na rad ostalih funkcija. Regresivno testiranje se primjenjuje u svim fazama kada
je promjena napravljena.

Osiguranje softverskog testiranja

Postoje organizacije održavanja kvaliteta softvera, koje pružaju različite tačke


gledišta, koriste različite set testove, vrše kompletan test softverskog okruženja…
Te organizacije učestvuju u provjeri standarda u navedenim specifikacijama, u
provjeri kodiranja i dokumentovanja softvera. One provjeravaju dokumentovanje
originalnog zahtjeva, verifikuju implementaciju potrebnih funkcija i prosljeđuju
proizvod do krajnjeg korisnika.

Željko Pekić Stranica 20


Testiranje softvera

Poboljšanja procesa testiranja

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


elementima razvoja softvera. Angažuju se sve veći resursi, kako velikih, tako i
malih kompanija u proces testiranja i njegovo unaprijeđenje.

Postoji više aspekata koji doprinose poboljšanju procesa testiranja:


• Obuka kadrova za proces testiranja,
• Automatizacija procesa testiranja,
• Razvoj novih modela testiranja,
• Integracije mjerenja parametara efikanosti i efektivnosti procesa testiranja,
• Analize slabih i jakih strana postojećeg procesa testiranja
• Identifikacije rizika i njihovih posljedica na uspjeh procesa razvoja.

Instalaciono testiranje

Instalaciono testiranje najviše je testirano u području testiranja. Ovaj tip


testiranja je predviđen kako bi se osiguralo da su sve mogućnosti i opcije
pravilno instalirane. Takođe je predviđeno da provjeri da li su sve komponente
aplikacija pravilno instalirane. Kada je u pitanju vrlo mali sistem instalacija se
može postaviti direktno, dok kod većih sistema postoji nekoliko načina za
instalaciju (implementiranje) sistema. Ako se želi zamijeniti postojeći sistem,
instalacija novog sistema se vrši u paralelnom modu. To znači da će oba sistema
raditi istovremeno u jednom periodu.
Programeri svakodnevno prate rad korisnika na ovakvom sistemu i kad se steknu
uslovi (komforan i olakšan rad korisnika novog sistema), stari sistem se
uninstalira ili briše. Mnoge kompanije postavljaju nekoliko servera (multi –
server) na jedan sistem, koji su nezavisni jedan od drugog. Jedan dobar način za
instaliranje sistema je probna instalacija na jednom odabranom serveru, posle
provjere dužine trajanja, instalirati ga na drugom serveru...

Željko Pekić Stranica 21


Testiranje softvera

Instalaciono testiranje treba da vodi brigu o sledećem:


• Za provjeru instaliranog produkta provjeriti zavisnost softvera/zakrpe
usluga SP3
• Proizvod bi trebalo provjeriti verziju istog proizvoda na ciljanoj mašini,
prethodna verzija ne bi trebala biti postavljena prije nove verzije
• Installer bi trebao da da podrazumijevani put instalacije,na primjer:
“C:\Program Files\.”
• Installer treba da dopusti korisniku instalaciju na drugu lokaciju od
podrazumijevane
• Provjeriti da li se proizvod može instalirati preko mreže
• Trebalo bi se automatski pokrenuti CD kada se postavi u DVD ROM
• Installer treba da dopusti opciju REMOVE/REPAIR
• Pri deinstaliranju provjeriti da li su svi ključevi registra, foldera, dll, prečica,
active X komponente uklonjene iz sistema
• Pokušati instaliranje softvera bez administrativne povlastice (login kao
gost).
• Pokušati instaliranje na različitom operativnom sistemu
• Pokušati instalaciju na slabijem računaru koji ima manje memorije (non–
compliant), RAM, HDD

Zaključak

Testiranje softvera je svaka aktivnost usmjerena na procjenu osobina ili


sposobnosti programa i određivanje onoga što vodi zahtijevanim rezultatima.
Teškoće u razvoju programske podrške proizilaze iz složenosti programskog
rješenja. Testiranje je više od običnog debagiranja. Cilj testiranja nije samo u
provjeri, radi li program ispravno, nego i u procjeni kvalitetne sigurnosti,
procjene pouzdanosti ili procjene performansi gotovih programskih rješenja.
Testiranje se izvodi u svim fazama životnog vijeka programa. Mogu se testirati
gotova programska rješenja ili samo pojedini djelove.

Tehnike koje se najčešće koriste kod testiranja su testiranje crnom kutijom,


testiranje bijelom kutijom, testiranje stresa, testiranje izdržljivosti, kao i razni
programi za testiranje performansi. Kako se zbog složenosti gotovih programskih
rješenja nikad sa sigurnošću ne može kazati da su otkrivene i otklonjene sve
greške unutar programske podrške, a samo testiranje predstavlja trošak, pitanje
je kad prestati sa testiranjem. Zato se može zaključiti da je testiranje
programske podrške trgovina između raspoloživih novčanih sredstava, vremena i
željenog kvaliteta.

Željko Pekić Stranica 22


Testiranje softvera

Literatura

[1] Software Testing Guide Book - Fundamentals of Software Testing

[2] The Importance of Software Testing - Compiled by JanErik Finlander

[3] Software Engineering FIFTH EDITION Roger S. Pressman, Ph.D.

[4] Software Testing: A Craftsman’s Approach, second edition, P.C.Jorgenses

[5] Test-Driven Development by Example, Addison-Wesley, K.Beck

[6] Essential Software Testing A Use-Case Approach, Greg Fournier

[7] Performance testing of software systemProceedings of the first international workshop on


Software and performance, Vokolos, F.I.; Weyuker, E.J.

[8] Software Testing Techniques Second edition, Beizer, B.

Željko Pekić Stranica 23