6 faze testiranja softvera

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


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


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


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


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


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 seodređ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


Funkcionalno testiranje

Metoda crn e 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 zatvorenostTestiranjem 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


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


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 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 performansi

Testiranje performansi obuhvata pronalaženje i otklanjanje problema koji degradiraju performansesoftvera. 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


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


• 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


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

6 faze testiranja softvera

Documents