testiranje softvera(faze testiranja) Boris Tikvenjac ITA/08

Softversko Inženjerstvo

Faze testiranja softvera

Predmetni nastavnik: polaznik:

Vesna Šatev Boris Tikvenjac ITA/08
02.08.2009.

1/13
testiranje softvera(faze testiranja) Boris Tikvenjac ITA/08

TABLE OF CONTENTS

CHAPTER TITLE PAGE

SOFTVERSKO INŽENJERSTVO (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 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 "Umetnost 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
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 pre 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 bezbednosnog 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 deo razvoja softvera. Primenjuje se u svakoj fazi razvojnog ciklusa,a obuhvata
više 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 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 tipaVažnost softverskog testiranja i njegovog uticaja na softver ne
može biti podcenjena. 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 unapred 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 “zakasnelu 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 obezbediti kompletnu
analizu i ponuditi najviše mogućnosti za otkrivanje grešaka 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 očekivanim rezultatima.Kada je pogrešan

podatak identifikovan, greška je podrazumevana i započinje se debugging. Postupak debugging-a
(ispravljanja greške) je nepredvidiv element procesa testiranja. Identifikovanje i ispravka greške koja
ukazuje na odstupanje od 0,01% između stvarnih i očekivanih rezultata, može trajati satima,danima ili
mesecima.
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
• Uspešan test slučaj otkriva novu grešku

• Softverska konfiguracija
• Test konfiguracije

4/13
testiranje softvera(faze testiranja) Boris Tikvenjac ITA/08

Razlika između tipa i tehnike softverskog testiranja

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

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). 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 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.

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,
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 provere skoro
celokupnog koda, na primer proverom da li se svaka linija koda izvršava barem jednom, proverom svih
funkcija ili proverom svih mogućih kombinacija različitih programskih naredbi. Specifičnim testovima
može se proveravati 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 rasprostanjenost ili čvorno testiranje – svaki ogranak u kodu se koristi u jednom
mogućem smeru 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 promenljivih kroz svaki mogući proračun. Praćenje se zasniva na svakom
odabranom pojedinačnom delu koda.Iako ove staze smatraju nezavisnim, zavisnosti između
višestrukih staza zapravo nisu testirane za ovaj pristup. DFT (Data Flow Testing) teži da
održava zavisnosti, ali to je uglavnom kroz manipulaciju sekvenci podataka. Ovaj pristup
prikazuje skrivene bugove i koristi ih kao promenljive, 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 vrednosti
• Izvlače sve petlje na sopstvenim granicama i unutar svojih dozvoljenih operativnih granica.
• Upotrebljava unutrašnje 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 izvršavanje specificiranih funkcija i vrši se provera ulaznih i izlaznih podataka.
Tačnost izlaznih podataka proverava se na osnovu specifikacije zahteva za softver. U ovim testovima se
ne vrši analiza izvornog koda. Problem funkcionalnog testiranja može da se pojavi u slučaju
dvosmislenih zahteva i nemogućnosti opisivanja svih načina korišćenja softvera. Skoro 30% svih
grešaka u kodu posledica su problema nepotpunih ili neodređenih specifikacija. Sinonimi za black box
uključuju: ponašanje, funckionalnost, neprozinost 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

Primenom metode crne kutije izrađuje se skup test slučajeva koji ispunjavaju zahteve:

• 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

Prednosti Black box testinga

• Testiranje može biti ne – tehničko

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

Nedostatci Black box testinga

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

• Test inputa zauzima veliki deo 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 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 budućem razvoju softvera,kao aplikacija koja verifikuje novu
funkcionalnost a da ne onemogući prethodnu.

Ekvivalentno particionisanje

Ekvivalentno particionisanje je metoda testiranja crne kutije koja deli ulazni softverski domen u klasu
podataka od kojih se izrađuju u test slučajevi. Idealan test slučaja otkriva klasu grešaka pre 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 vrednosti unosa (inputa). Ekvivalentne vrednosti prikazuju skup važećih i nevažećih
ulznih uslova (input conditions) u sistemu.
Ekvivalentna vrednost može da se određuje na osnovu sledećeg:

• Ako je ulazni uslov (input conditions) specifičan niz, jedna važeća i dve nevažeće ekvivalentne
vrednosti su definisane
• Ako ulazni uslov (input conditions) zahteva specifičnu vrednost, jedna važeća i dve nevažeće
ekvivalentne vrednosti su definisane
• Ako je ulazni uslov (input conditions) član specifičnog niza, jedna važeća i jedna nevažeća
ekvivalentna vrednost je definisana
• Ako je ulazni uslov (input conditions) Bulova, jedna važeća i jedna nevažeća ekvivalentna
vrednost je definisana

8/13
testiranje softvera(faze testiranja) Boris Tikvenjac ITA/08

Analiza granične vrednosti

Veoma mnogo grešaka se pojavljuje u granicama ulaznog domena i iz tog razloga se koristi analiza
granične vrednosti. Analiza granične vrednosti pripada dizajnu test slučaja koji upotpunjuje
ekvivalentnost particionisanja. Analiza granične vrednosti izrađuje test slučaja i za domen izlaza
takođe.
Analiza granične vrednosti se određuje na osnovu sledećeg:

• 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 vrednosti, test slučajevi treba da budu izrađeni za vežbu 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,izrađuje se test slučaja
za vež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 dodeljena za svaki
• Cause – Effect graph je izrađen
• Grafikon je izmenio 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 primeniti bilo na cause ili na effect.

9/13
testiranje softvera(faze testiranja) Boris Tikvenjac ITA/08

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 umeće gde 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, dali prilikom čitanja funkcionalnog dokumenta ili prilikom testiranja pronaći
grešku koja nije bila dokumentovana.

10/13
testiranje softvera(faze testiranja) Boris Tikvenjac ITA/08

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 vreme 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, softvar 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. Npr 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 merenjem
iskorištenosti resursa (npr. 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 deo velikog
sistema koji zahteva više pristupa i obrade podataka, sadrži ranjive čvorove koji moraju biti testirani
pre implementacije. Nažalost, većina stres testiranja mogu samo da simuliraju različite vrste
opterećenja na tačke u sistemu, ali nemogu testirati celu mrežu. Na sreću, jednom kada se uradi stres
testiranje i faktori opterećenja budu uspešno prevaziđeni, potreban ponovni stres testing se vrši samou
slučaju kada dođe do većih promena. 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.

11/13
testiranje softvera(faze testiranja) Boris Tikvenjac ITA/08

Regresivno testiranje

Regresivno testiranje potvrđuje da implementacija promena ne utiče negativno na rad ostalih funkcija.
Regresivno testiranje se primenjuje u svim fazama kada je promena 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 proveri standarda
u navedenim specifikacijama, u proveri kodiranja i dokumentovanja softvera. One proveravaju
dokumentovanje originalnog zahteva, verifikuju implementaciju potrebnih funkcija i prosleđuju
proizvod do krajnjeg korisnika.
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 proveri 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 zameniti 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 postavaljaju 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 provere dužine trajanja, instalirati ga na drugom
severu...
Instalaciono testiranje treba da vodi brigu o sledećim:
• Za proveru instaliranog produkta proveriti zavisnost softvera / zakrpe usluga SP3
• Proizvod bi trebalo proveriti verziju istog proizvoda na ciljanoj mašini, 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 može instalisati preko mreže
• 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 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

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