testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Softversko Inenjerstvo

Faze testiranja softvera

Predmetni nastavnik:
Vesna atev

polaznik:
Boris Tikvenjac ITA/08
02.08.2009.

1/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

TABLE OF CONTENTS

CHAPTER TITLE

PAGE

SOFTVERSKO INENJERSTVO (FAZE TESTIRANJA SOFTVERA) ____________ 1/13

UVOD U SOFTVERSKO TESTIRANJE _____________________________________ 3/13
TEHNIKE SOFTVERSKOG TESTIRANJA __________________________________ 4/13
VRSTE SOFTVERSKOG TESTIRANJA ( Vrste i razlike softverskog testiranja) ______ 5/13
STRUKTURALNO TESTIRANJE (WHITE BOX METODA) ____________________ 6/13
FUNKCIONALNO TESTIRANJE (BLACK BOX METODA) ___________________ 7/13
FUNKCIONALNO TESTIRANJE (Ekvivalentno Particionisanje) __________________ 8/13
FUNKCIONALNO TESTIRANJE (Cause Effect Graphing Techniques) ___________ 9/13
FUNKCIONALNO TESTIRANJE (Testiranje putem grafikona, Error Guessing) _____ 10/13
TESITIRANJE PERFORMANSI ( Regresivno testiranje, Osiguranje soft. testiranja) __ 11/13
INSTALACIONO TESTIRANJE __________________________________________ 12/13
REFERENCES _________________________________________________________ 13/13

2/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

UVOD

Testiranje softvera i otkrivanje greaka

Posebna panja danas se posveuje aktivnosti otkrivanja greaka. Ovo je bitna razlika u odnosu na
shvatanje da je vano potvrditi da program ili sistem radi. Ova definicija testiranja softvera je napisana
u knjizi Glenford Majers "Umetnost testiranja softvera". Ovakvu definiciju je dao iz razloga to je
tvrdio da je softver jedan od najkompleksnijih proizvoda ljudskog umnog rada. Nemogue je dokazati
da je softver bez greke. A takoe je nemogue povinovati se prostom imperativu i nai sve greke.

Zato testiranje?
Zato to su veliki gubici kompanija koje razvijaju softver upravo zbog velikog broja defekata u
isporuenom softveru. Prvenstveni zadatak test inenjera je otkrivanje problema u softveru sa ciljem da
se oni otklone pre predaje softverskog proizvoda kupcu.
Od test inenjera se zahteva da otkrije to je mogue vie problema i to to vie onih, vrlo ozbiljnih ije
posledice mogu biti katastrofalne sa materijalnog i bezbednosnog aspekta. Zato je sa svih aspekata
potrebno da se proces testiranja softvera uini to efikasnijim i uz to manje trokove ukoliko je to
mogue.
Testiranje softvera je proces verifikacije programa ili sistema sa ciljem otkrivanja i ispravljanja greaka
i predstavlja integralni deo razvoja softvera. Primenjuje se u svakoj fazi razvojnog ciklusa,a obuhvata
vie od 50% vremena potrebnog za razvoj softvera.

3/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Tehnike softverskog testiranja

Tehnike testiranja odnose se na razliite metode ispitivanja pojedine funkcije raunarskog

programa,sistema ili softverskog proizvoda. Svaki tip testiranja ima sopstvenu tehniku testiranja,a neke
tehnike kombinuju funkcije oba tipaVanost softverskog testiranja i njegovog uticaja na softver ne
moe biti podcenjena. Softversko testiranje je osnovna komponenta osiguranja softverskog kvaliteta i
predstavlja pregled specifikacija,dizajna i kodiranja. Vea vidljivost softverskih sistema i trokovi
povezani sa softverskim neuspehom su motivirajui faktori za napredno planiranje, putem testiranja.
Veoma je neugodno za softversku oganizaciju kada utroi vie od 40% svog rada na testiranje..
Osnove softverskog testiranja
Tokom testiranja softversko inenjerstvo izrauje seriju test sluajeva koji se koriste rip apart
(izdvajanje posebnih delova) softvera koji se proizvodi. Softverski inenjeri su obino stvaraoci koji
poznaju unapred predviene koncepte testiranja i bave se pronalaenjem i ispravljanjem greaka kada
one budu identifikovane.
Dizajn test sluaja
Izrada dizajna softverskog testiranja moe biti izazovan proces. Softverski inenjeri testiranje esto
vide kao zakasnelu misao (afterthought), meutim, prilikom izrade pravog test sluaja jo uvek nisu
sigurni u njegovu kompletnost. Cilj testiranja je u pronalaenju najvie moguih greaka uz minimalni
utoak vremena i napora za to. Razvijen je veliki broj metoda dizajna test sluajeva koji nude
developer-u sistematian pristup testiranja. Metode nude pristup koji moe obezbediti kompletnu
analizu i ponuditi najvie mogunosti za otkrivanje greaka u sofveru.
Test protoka informacija
Postoje dve vrste tipa ulaznih koje se uzimaju pri testiranju protoka informacija
Softverska konfiguracija
Test konfiguracije
Testiranja se obavljaju i svi rezultati testa se porede sa oekivanim rezultatima.Kada je pogrean
podatak identifikovan, greka je podrazumevana i zapoinje se debugging. Postupak debugging-a
(ispravljanja greke) je nepredvidiv element procesa testiranja. Identifikovanje i ispravka greke koja
ukazuje na odstupanje od 0,01% izmeu stvarnih i oekivanih rezultata, moe trajati satima,danima ili
mesecima.
Ciljevi softverskog testiranja
Pravila koja deluju na cilj testiranja su:
Testiranje je proces izvravanja programa, sa ciljem pronalaenja greaka
Dobar test sluaj e imati dobre anse u pronalaenju neotkrivene greke
Uspean test sluaj otkriva novu greku

Softverska konfiguracija
Test konfiguracije

4/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Razlika izmeu tipa i tehnike softverskog testiranja

Tip testiranja se bavi testiranjem celokupnog softvera, a tehnike testiranja se bave odreenim delovima
softvera koje treba testirati. Drugim reima,mi testiranjem svake funkcije softvera moemo proveriti da
li je softver operativan, ili moemo testirati interne komponente softvera kako bi proverili njegovu
internu poslovnost prema specifikaciji softvera. S druge strane, tehnike testiranja obuhvataju niz
metoda i naina koji se primenjuju, kao i prorauna za testiranje odreene funkcije nekog softvera
(ponekad se testira interfejs, ponekad testiramo segmente, ponekad petlje i sl.)
Vrste softverskog testiranja
Vrste pristupa za identifikovanje greaka u softveru:

Statiko
Dinamiko

Postoje razliite vrste pristupa testiranja ( testiranje raunarskog programa,testiranje sistema ili
testiranje softverskog proizvoda). Dve osnovne vrste pristupa su Black box i White box testiranje.
U novije vreme razvija se Grey box testiranje ili hibridno testiranje(ponekad nazvano kao staklena
kutija glass box) , koje objedinjuje funkcije obe vrste pristupa testiranja. Testovi su osmiljeni i
fokusirani na take gledita kupaca korisnika. Testeri kombinacijom oba pristupa utvruju ispravnost
i mogunost novog implementiranja na osnovu korisnikih elja.
5/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Strukturalno testiranje
Metoda bele kutije "White-box"
Ovo testiranje proverava i analizira izvorni kod i zahteva 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 provere skoro
celokupnog koda, na primer proverom da li se svaka linija koda izvrava barem jednom, proverom svih
funkcija ili proverom svih moguih kombinacija razliitih programskih naredbi. Specifinim testovima
moe se proveravati postojanje beskonanih petlji ili koda koji se nikada ne izvrava.
Kodna pokrivenost je navedena u 6 sledeih koraka:

Segment pokrivenost svaki segment koda u B/W kontroli strukture se izvrava makar
jednom
Podruna rasprostanjenost ili vorno testiranje svaki ogranak u kodu se koristi u jednom
moguem smeru barem jednom
Sloeno stanje rasprostranjenosti kada postoji vie uslova, mora se testirati ne samo svaki
smer, ve i sve mogue kombinacije uslova, to se obino obavlja pomou 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 definie praenje
specifinih promenljivih kroz svaki mogui proraun. Praenje se zasniva na svakom
odabranom pojedinanom delu koda.Iako ove staze smatraju nezavisnim, zavisnosti izmeu
viestrukih staza zapravo nisu testirane za ovaj pristup. DFT (Data Flow Testing) tei da
odrava zavisnosti, ali to je uglavnom kroz manipulaciju sekvenci podataka. Ovaj pristup
prikazuje skrivene bugove i koristi ih kao promenljive, deklarie ih ali ih ne koristi.
Put testiranja put testiranja definie i pokriva sve mogue puteve kroz kod. Ovo testiranja su
vrlo teka i dugotrajana.
Testiranje petlje ove strategije se odnose na testiranju jedne petlje, grupnih petlji i ispletenih
petlji. Zavisnost petlji je prilino jednostavno testirati, osim ako postoji meu petlja ili kod
sadri B/W petlju.

U White box testingu, koristi se kontrola strukture proceduralnog dizajna za dobijanje test sluajeva.
Korienjem White box testing metoda jedan tester moe izvui probne sluajeve koji:

Garantuju da sve nezavisne staze u modulu budu istestirane barem jednom.

Izvravaju sve logike odluke o njihovoj istinitosti ili lanoj vrednosti
Izvlae sve petlje na sopstvenim granicama i unutar svojih dozvoljenih operativnih granica.
Upotrebljava unutranje strukture podataka kako bi obezbedio njihovu valjanost.

6/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Funkcionalno testiranje
Metoda crne kutije "Black-box"
Analizira se samo izvravanje specificiranih funkcija i vri se provera ulaznih i izlaznih podataka.
Tanost izlaznih podataka proverava se na osnovu specifikacije zahteva za softver. U ovim testovima se
ne vri analiza izvornog koda. Problem funkcionalnog testiranja moe da se pojavi u sluaju
dvosmislenih zahteva i nemogunosti opisivanja svih naina korienja softvera. Skoro 30% svih
greaka u kodu posledica su problema nepotpunih ili neodreenih specifikacija. Sinonimi za black box
ukljuuju: ponaanje, funckionalnost, neprozinost i zatvorenost
Testiranjem se pokuavaju pronai greke u sledeim kategorijama:

Neispravna ili nepotpuna funkcija

Greka interfejsa
Greka u strukturi podataka ili u pristupu spoljnoj bazi podataka
Greka performanse
Greka inicijalizacije i greka izvravanja

Primenom metode crne kutije izrauje se skup test sluajeva koji ispunjavaju zahteve:

Test sluaja koji smanjuju broj test sluaja na mogunost razumnog testiranja
Test sluaja koji e nam prikazati prisutnost ili odsutnost klase greaka
Prednosti Black box testinga

Testiranje moe biti ne tehniko

Ovo testiranje e najverovatnije pronai one bugove koje je korisnik pronaao
Testiranje pomae u identifikovanju nejasnoa i protivrenosti funkcionalnih specifikacija
Test sluajevi mogu biti izraeni po zavretku funkcionalnih specifikacija
Nedostatci Black box testinga

anse za ponavljanje testova koje je ve odradio proramer

Test inputa zauzima veliki deo prostora
Teko je utvrditi sva mogua testiranja ulaza u ogranienom vremenu. Pisanje test sluaja je
prilino sporo i teko
anse za posedovanje neidentifikovanih staza tokom testiranja
Alati koji se koriste u Black box testingu

7/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Osnovni funkcionalni alati testiranja izvode rezultate testova crne kutije u obliku skripte. Jednom
izvedene, ove skripte mogu koristiti u buduem razvoju softvera,kao aplikacija koja verifikuje novu
funkcionalnost a da ne onemogui prethodnu.
Ekvivalentno particionisanje
Ekvivalentno particionisanje je metoda testiranja crne kutije koja deli ulazni softverski domen u klasu
podataka od kojih se izrauju u test sluajevi. Idealan test sluaja otkriva klasu greaka pre nego to je
greka detektovana. Ekvivalentnost particionisanja pokuava da identifikuje naznaenu klasu greaka u
test sluaju. Dizajn test sluaja za ekvivalentnost particionisanja je zasnovano na planiranju
ekvivalentnih vrednosti unosa (inputa). Ekvivalentne vrednosti prikazuju skup vaeih i nevaeih
ulznih uslova (input conditions) u sistemu.
Ekvivalentna vrednost moe da se odreuje na osnovu sledeeg:

Ako je ulazni uslov (input conditions) specifian niz, jedna vaea i dve nevaee ekvivalentne
vrednosti su definisane
Ako ulazni uslov (input conditions) zahteva specifinu vrednost, jedna vaea i dve nevaee
ekvivalentne vrednosti su definisane
Ako je ulazni uslov (input conditions) lan specifinog niza, jedna vaea i jedna nevaea
ekvivalentna vrednost je definisana
Ako je ulazni uslov (input conditions) Bulova, jedna vaea i jedna nevaea ekvivalentna
vrednost je definisana

8/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Analiza granine vrednosti

Veoma mnogo greaka se pojavljuje u granicama ulaznog domena i iz tog razloga se koristi analiza
granine vrednosti. Analiza granine vrednosti pripada dizajnu test sluaja koji upotpunjuje
ekvivalentnost particionisanja. Analiza granine vrednosti izrauje test sluaja i za domen izlaza
takoe.
Analiza granine vrednosti se odreuje na osnovu sledeeg:

Ako ulazni uslov specfikuje stanje oivieno u rasponu od vrednosti A do B, dobijamo test
sluajeve sa vrednostima A i B, samo iznad i ispod A i B
Ako ulaz specifira stanje razliitih vrednosti, test sluajevi treba da budu izraeni za vebu sa
minimalnim i maksimalnim brojkama
Ove dve stavke se primenjuju i na izlazne uslove (output conditions)
Ako je softver interni, ije su strukture podataka u propisanim granicama,izrauje se test sluaja
za vebu strukture podataka u granicama.
Cause Effect Graphing Techniques

Cause Effect Graphing Techniques je pristup dizajna test sluaja koji nudi jedan koncizan opis
logikih uslova i pridruenih akcija.
Pristup ima etiri faze:
Cause (ulazni uslov) i Effect (radnja) navedeni su za modul i identifikacija je dodeljena za svaki
Cause Effect graph je izraen
Grafikon je izmenio odluku u tabeli
Tabela pravila odluke modifikovanja test sluajeva
Pojednostavljena verzija Cause Effect graph simbola je prikazana ispod. U levoj koloni figura daje
razliita logika udruenja meu causes i c i effect i e. Desna kolona pokazuje potencijalna prinudna
(constraining) udruenja koja bi se mogla primeniti bilo na cause ili na effect.

9/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Testiranje putem grafikona

Softversko testiranje zapoinje stvaranjem grafikona vanih objekata i njihovih veza i onda
osmiljavanje niza testova koji e pokrivati grafikon, tako da svaki objekat i veza budu iscrtan a greka
nepokrivena.
Error Guessing
Error Guessing dolazi sa iskustvom u tehnologiji i u projektu. Greka Guessing je umee gde greke
mogu biti sakrivene. Ne postoje specijalizovani alati i tehnika za to, ali moe se pisati test sluaja u
zavisnosti od situacije, dali prilikom itanja funkcionalnog dokumenta ili prilikom testiranja pronai
greku koja nije bila dokumentovana.

10/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Testiranje performansi
Testiranje performansi obuhvata pronalaenje i otklanjanje problema koji degradiraju performanse
softvera. Ispitivanje performansi najee obuhvata:iskorienje procesorskih resursa, protok podataka
i vreme odziva. Tipini resursi koji se proveravaju su: propusni opseg, brzina procesora, iskorienje
memorije, zauzetost prostora na disku.U real time sistemima i ugraenim sistemima, softvar koji prua
potrebne funkcije ponekad nije prihvatljiv u skladu sa performansama. Testiranje performansi
dizajnirano je za izvoenje run-time testa perfmormansi u softverskom okruenju jednog integrisanog
sistema. Testiranje performansi se pojavljuje u svim procesima testiranja. Npr metoda White box
testiranja pojedinanog modula moe se ponaati kao test performanse modula. Izvoenje testa
performansi esto je povezano sa stress testom softvera i hardvera i proveravanjem i merenjem
iskoritenosti resursa (npr. ciklus rada procesora) u extremnim sluajevima. Stres testovi su najkorisniji
kada se sistem ugrauje u vea okruenja, ili kada se prvi put implementira. Web sajt, kao deo velikog
sistema koji zahteva vie pristupa i obrade podataka, sadri ranjive vorove koji moraju biti testirani
pre implementacije. Naalost, veina stres testiranja mogu samo da simuliraju razliite vrste
optereenja na take u sistemu, ali nemogu testirati celu mreu. Na sreu, jednom kada se uradi stres
testiranje i faktori optereenja budu uspeno prevazieni, potreban ponovni stres testing se vri samou
sluaju kada doe do veih promena. Mana testiranja performansi je ta to potvruje validnost sistema
u oteanim uslovima obrade podataka,ali ne garantuje za njihovu tanost i ispravnost.

11/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Regresivno testiranje
Regresivno testiranje potvruje da implementacija promena ne utie negativno na rad ostalih funkcija.
Regresivno testiranje se primenjuje u svim fazama kada je promena napravljena.
Osiguranje softverskog testiranja
Postoje organizacije odravanja kvaliteta softvera, koje pruaju razliite take gledita, koriste razliite
set testove, vre kompletan test softverskog okruenja Te organizacije uestvuju u proveri standarda
u navedenim specifikacijama, u proveri kodiranja i dokumentovanja softvera. One proveravaju
dokumentovanje originalnog zahteva, verifikuju implementaciju potrebnih funkcija i prosleuju
proizvod do krajnjeg korisnika.

Instalaciono testiranje
Instalaciono testiranje najvie je testirano u podruju testiranja. Ovaj tip testiranja je predvien kako bi
se osiguralo da su sve mogunosti i opcije pravilno instalirane. Takoe je predvieno da proveri da li
su sve komponente aplikacija pravilno instalirane. Kada je u pitanju vrlo mali sistem instalacija se
moe postaviti direktno,dok kod veih sistema postoji nekoliko naina za instalaciju (implementiranje)
sistema. Ako se eli zameniti postojei sistem, instalacija novog sistema se vri u paralelnom modu. To
znai da e oba sistema raditi istovremeno u jednom periodu. Programeri svakodnevno prate rad
korisnika na ovakvom sistemu i kad se steknu uslovi (komforan i olakan rad korisnika novog sistema),
stari sistem se uninstalira ili brie. Mnoge kompanije postavaljaju nekoliko servera (multi server) na
jedan sistem, koji su nezavisni jedan od drugog. Jedan dobar nain za instaliranje sistema je probna
instalacija na jednom odabranom serveru, posle provere duine trajanja, instalirati ga na drugom
severu...
Instalaciono testiranje treba da vodi brigu o sledeim:
Za proveru instaliranog produkta proveriti zavisnost softvera / zakrpe usluga SP3
Proizvod bi trebalo proveriti verziju istog proizvoda na ciljanoj maini, prethodna verzija ne bi
trebala biti postavljena pre nove verzije

12/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Installer bi trebao da da podrayumevani put instalacije npr C:\programs\.

Installer treba da dopusti korisniku instalaciju na drugu lokaciju od podrazumevane
Proveriti da li se proizvod moe instalisati preko mree
Trebalo bi se automatski pokrenuti CD kada se postavi u DVD ROM
Installer treba da dopusti opciju REMOVE/REPAIR
Pri deinstaliranju proveriti da li su svi kljuevi registra, foldera, dll, preica, active X
komponente uklonjene iz sistema
Pokuati instaliranje softvera bez administrativne povlastice (login kao gost)
Pokuati instaliranje na razliitom operativnom sistemu
Pokuati instalaciju na slabijem raunaru koji ima manje memorije (noncompliant), RAM,
HDD

REFERENCES

13/13

testiranje softvera(faze testiranja)

Boris Tikvenjac ITA/08

Software Testing Guide Book - Fundamentals of Software Testing

The Importance of Software Testing - Compiled by JanErik Finlander
Software Engineering FIFTH EDITION Roger S. Pressman, Ph.D.

14/13