33
REPUBLIKA SRPSKA GIMNAZIJA PRNJAVOR PRNJAVOR M A T U R S K I R A D Predmet: PRIMJENA RAČUNARA Tema: TESTIRANJE SOFTVERA Mentor: Učenik: Aleksandar Ristić, prof. Mihajlo Tešić, IV 4 Prnjavor, avgust 2013. godina

TESTIRANJE SOFTVERA - Tesic

Embed Size (px)

Citation preview

Page 1: TESTIRANJE SOFTVERA - Tesic

REPUBLIKA SRPSKA

GIMNAZIJA PRNJAVOR

PRNJAVOR

M A T U R S K I R A D

Predmet: PRIMJENA RAČUNARA

Tema: TESTIRANJE SOFTVERA

Mentor: Učenik:

Aleksandar Ristić, prof. Mihajlo Tešić, IV4

Prnjavor, avgust 2013. godina

Page 2: TESTIRANJE SOFTVERA - Tesic

Sadržaj

1. Uvod........................................................................................................................................3

2. Pojam testiranja softvera....................................................................................................4

3. Istorija testiranja softvera..................................................................................................5

4. Odnos prema testiranju......................................................................................................8

4. 1 Komparacija pravaca – ekonomski aspekti.....................................................................9

5. Proces testiranja.................................................................................................................105.1 Organizacija procesa testiranja......................................................................................115.2 Tipovi testiranja..............................................................................................................115.3 Tehnike testiranja...........................................................................................................125.3 Pregled tehnika testiranja...............................................................................................13

6. Kada prestati testirati?.......................................................................................................16

7. Osnove softverskog testiranja.............................................................................................17

7.1 Ciljevi softverskog testiranja..........................................................................................187.2 Vrste softverskog testiranja............................................................................................207.3 Strukturalno testiranje – "White-box"..........................................................................207.4 Funkcionalno testiranje..................................................................................................237.5 Metoda crne kutije – "Black-box".................................................................................237.6 Ekvivalentno particionisanje..........................................................................................277.7 Cause – Effect Graphing Techniques.............................................................................287.8 Testiranje performansi...................................................................................................297.9 Poboljšanja procesa testiranja........................................................................................307.10 Instalaciono testiranje.....................................................................................................30

8. Zaključak............................................................................................................................32

9. Literatura..............................................................................................................................33

2

Page 3: TESTIRANJE SOFTVERA - Tesic

1. Uvod

U vremenu nemilosrdnog tržišta jedini siguran način za postizanje kontinuiranog uspjeha u softverskoj industriji je obezbjeđivanje kvaliteta putem primjene standarda i testiranja softvera.

Softverski proizvod se, kao najnježnija biljka, planira, razvija, prati i kontroliše, a na kraju posebno oblikuje, kako bi se isporučio kupcu i zadovoljio zahtjeve.

Kao i u većini drugih primjera iz raznih oblasti glavni značaj se postavlja na zadnju kariku u lancu – kupca. Da bi se izvršila potpuna implementacija proizvoda koji će da pokaže kvalitet i zadovolji kupca ono što se proizvodi najbolje je probati i okusiti na sopstvenom primjeru – otuda potreba, svrha i cilj testiranja svakog proizvoda, pa tako i softvera.

Pojam testiranja danas se razlikuje od vremena sedamdestih godina kada je to značilo isključivo traženje grešaka. Sada ono obuhvata niz aktivnosti od planiranja, dizajniranja, izgradnje, održavanja, pa sve do sprovođenja testova. Prva faza u određivanju kontrole kvaliteta je faza projektovanja. Testiranje je najefikasniji način za određivanje nivoa kvaliteta softverskog proizvoda. Bitno je da se testiranje posmatra kao jedna od faza u procesu razvoja softvera. Često se na testiranje gleda kao na sasvim odvojen, samostalan proces, što je greška. Najveći dio testiranja se obavlja od strane programera koji je razvio softver ali da bi testiranje bilo potpuno, potrebno je obezbijediti i testiranje od strane budućih korisnika jer se na na taj način moguće greške najbrže pronalaze.

3

Page 4: TESTIRANJE SOFTVERA - Tesic

2. Pojam testiranja softvera

Testiranje softvera je proces za mjerenje kvaliteta softvera. Kvalitet se obično vezuje za pojmove tačnosti, potpunosti, sigurnosti, ali takođe uključuje i neke zahtjeve propisane ISO standardom, kao i tehničke zahtjeve ISO 9126: karakteristike, pouzdanost, efikasnost, portabilnost, istrajnost, kompatibilnost i korisnost.

Testiranje je proces tehničke istrage, čiji je cilj da otkrije informacije vezane za kvalitet proizvoda, naravno, sa poštovanjem konteksta funkcionisanja proizvoda. Ovaj proces uključuje izvršavanje programa ili aplikacije sa namerom pronalaženja grešaka. Kvalitet nije apsolutna, već vrijednost za neku osobu. Kada se ovo uzme u obzir testiranje se ne može uzeti kao parametar za uspostavljanje kontrole nad softverom; testiranje obezbjeđuje kritiku i komparaciju za stanje i ponašanje proizvoda u odnosu na specifikaciju. Postoje mnogi pristupi testiranju softvera, ali je efektivno testiranje kompleksnih proizvoda u osnovi proces istrage, a ne samo pitanje kreiranja i praćenja rutinske procedure. Jedna od definicija testiranja je: „Proces ispitivanja softvera u cilju procjene istog“, gdje se ispitivanje odnosi na operacije koje tester pokušava da izvrši nad proizvodom, a proizvod odgovara na to ponašanjem izazvanim probama testera. Testiranje se vezuje i za dinamičko analiziranje proizvoda kroz faze razvoja. Za statičko testiranje smatra se istraživanje, a za dinamičko pokretanje programa uz predefinisani skup test scenarija na određenom nivou razvoja.1

1 http://en.wikipedia.org, mart 2010.4

Page 5: TESTIRANJE SOFTVERA - Tesic

3. Istorija testiranja softvera

Autori Gelperin i Hetzel 1998. godine publikuju podjelu istorije testiranja prema sledećim fazama:2

Period od Period do Faza Opis

- 1956 Debagovanje

Programe je pisao, a zatim i testirao, programer, do trenutka uklanjanja svih bug-ova. Testovi su kreirani ad hoc, na osnovu iskustva programera i fokusirani na operativnost sistema. Ne postoji jasna granica između testiranja i razvoja.

1957 1978 Demonstracija

Debagovanje se i dalje izvodilo kako bi sistem proradio, ali je dodat još jedan nivo testiranja - da se demonstrira da softver ne samo radi, već da radi ono što treba.

1979 1983 DestrukcijaFokus testiranja se pomjera sa obezbjeđenja da softver radi ono što treba, na otkrivanje grešaka u sistemu.

1983 1987 Evaluacija

Testiranje postaje aktivnost na kraju svakog nivoa u razvoju životnog ciklusa, jer se prihvata stanovište da što ranije otkrivanje grešaka u sistemu izaziva manje troškove.

1988 - Prevencija

Ideja je da se spriječe greške u bilo kom

stadijumu životnog ciklusa proizvoda

testiranjem svakog nivoa. Testiranje se fokusira

na ispravljanje grešaka.

Tabela 1: Istorija testiranja

Odvajanje debagovanja od testiranja je uveo Glenford J. Mayers 1979. godine. Gelperin i Hetzel klasifikovali su 1988. godine faze i ciljeve softverskog testiranja koji su dati u tabeli.

Kroz istoriju razvoja softvera pojavljivale su se razne definicije testiranja:

2 http://www.softwaretestingwiki.com, januar 2010.5

Page 6: TESTIRANJE SOFTVERA - Tesic

1. Debagovanje: Pedesetih godina XX vijeka testiranje softvera se definisalo kao „ono što programeri rade u cilju pronalaženja grešaka u sopstvenim programima“. Testiranja su bila iscrpljujuća zbog svih mogućih kombinacija koda koje su se trebale provjeriti i nije bilo moguće do kraja istestirati aplikaciju, jer je: (1) domen ulaza bio prevelik, (2) ima previše mogućih ulaznih kombinacija i (3) dizajn i specifikacija se teško testiraju. Sa razvojem softvera u periodu od 60-tih do 70-tih aktivnost razvoja softvera prerasla je u „kompjutersku nauku“.

2. Demonstracija:

Ranih 70-tih testiranje softvera definiše se kao „ono što se radi da bi se demonstrirale dobre strane programa“ ili kao „proces uspostavljanja povjerenja da program ili sistem rade ono što bi trebalo“. Iako je ovaj pristup teoretski obećavao puno, u praksi je zahtjevao previše vremena i bio je nepotpun. Kada se radilo o prostim testovima bilo je lako pokazati da softver radi i dokazati da će teorijski raditi. Međutim, u većini slučajeva softver nije trebalo testirati samo na ovaj način i veliki broj grešaka ostajao je neotkriven do same implementacije. Ubrzo je izveden zaključak da „dokaz ispravnosti“ nije dovoljan metod u testiranju softvera.

3. Destrukcija:

Kasnih 70-tih ustanovljeno je da je testiranje proces izvršenja programa sa namjerom pronalaženja greške, a ne omogućavanja da softver radi. Naglašeno je da je dobar test onaj kod kog postoji velika vjerovatnoća za pronalaženje neotkrivene greške.

4. Evaluacija i prevencija:

U periodu 80-tih definicija testiranja se proširila i uključila prevenciju grešaka. Dizajniranje testova predstavlja jednu od najefektivnijih tehnika za prevenciju. Predlaže se da metodologija testiranja bude obavezna, da uključuje kontrolu kompletnog životnog ciklusa i da bude organizovan proces. Ovaj pravac ističe značaj, ne samo testiranja programa, već i zahtjeva, dizajna, koda, samih testova i na kraju programa. „Testiranje“ se tradicionalno (do 80-tih) odnosi na ono što je urađeno sa sistemom do isporuke koda koji radi, a danas je testiranje „više testiranje“ u kom tester treba da učestvuje u skoro svakom aspektu razvoja u životnom ciklusu softverskog proizvoda. Pored testiranja i provjere koda isporučenog na testiranje, u trenutku kada nešto nije dobro moraju se ispitati i prethodne faze razvoja. Ako je greška izazvana nedostatkom u dizajnu ili programskim propustom, neophodno je identifikovati izvor problema. Istraživanja pokazuju da oko 50% grešaka nastaje kada se definiše ono što se želi od softvera (faza zahteva) ili u fazi dizajna, i da ove greške utiču na ostale defekte za vrijeme kodiranja.

5. Automatsko i novi oblici testiranja:

Sredinom 80-tih pojavili su se alati za automatsko testiranje i pokrenuta je automatizacija manuelnih testova kako bi se povećala efikasnost i kvalitet aplikacije. Poznato je da računar može da uradi testova nego čovek ručno, i da ih, naravno, izvodi pouzdanije. Ovi alati su u početku bili jako prosti i nisu posjedovali napredan jezik za skriptovanje.

Ranih 90-tih uočene su prednosti ranog dizajniranja testova. Testiranje se definiše kao planiranje, dizajn, izgradnja, održavanje i izvršavanje testova i testnih okruženja. U ovom periodu pojavljuju se napredniji alati za testiranje koji nude veći obim jezika za skriptovanje i oblika izvještavanja.

6

Page 7: TESTIRANJE SOFTVERA - Tesic

Razvili su se i alati za mjerenje performansi sistema. Ovi alati testirali su stres i preopterećenje sistema kako bi odredili slabe tačke. Mada je koncept testa kao procesa opstao kroz cjelokupan razvoj životnog ciklusa, sredinom 90-tih, softver se razvijao i bez specifičnih modela testiranja, što je značajno unazadilo ovaj proces. Ovaj problem se naziva „agilno testiranje“.

6. Novo doba:

Početkom XXI vijeka Mercury Interactive je uveo još širu definiciju testiranja uvođenjem koncepta optimizacije poslovne tehnologije (BTO).

BTO povezuje IT strategiju i izvršenje sa poslovnim ciljevima. Koncept pomaže upravljanju prioritetima, ljudima i procesima IT-a. Osnovni pristup podrazumijeva mjerenje i maksimiziranje vrijednosti u okviru životnog ciklusa, kako bi se obezbijedio kvalitet, performanse i ciljevi dostupnosti.3

Slika 1: Istorija testiranja softvera

4. Odnos prema testiranju

Programeri početnici nisu navikli proces testiranja posmatrati kao proces otkrivanja. Najčešći problem predstavlja to što se kritika programa prihvata kao kritika ličnih sposobnosti što svakako nije pravi pokazatelj, pravo mjerilo. Najčeći primjer navedenog vidljiv je već u

3 Lewis W.E.: „Software Testing and Continuous Quality Improvement“, Second Edition - Auerbach Publications 2005.

7

Page 8: TESTIRANJE SOFTVERA - Tesic

toku studija kada student pokušava uvjeriti predavača u ispravnost nekog programa za koji je ulaze odredio sam student. Međutim, kada je riječ o razvoju softverskog proizvoda za određenog kupca, njega kao korisnika nekod softvera prije svega zanima funkcionalnost softvera u svim situacija, a ne samo onim koje prezentije proizvođač softvera.

Iz navedenog zaključujemo da bi cilj svakog projektanta – programera bio da otkrije što više grešaka bez obzira na to u kojoj su fazi napravljene i ko ih je napravio. S toga sujeti i emotivnim osjećanjima nema mjesta, mada u realnosti to predstavlja čest problem. Čest je slučaj i česta je inicijativa težnja na bezličnom programiranju gdje se programeri posmatraju kao komponente većeg sistema, a ne kao vlasništvo onih koji su ih napisali. Kada se otkrije greška ili dođe do otkaza, depersonalizovani razvojni tim se bavi ispravljanjem greške, a ne prebacivanjem krivice na konkretnog izvršioca.

4. 1 Komparacija pravaca – ekonomski aspekti

U literaturi se navode prednosti nekih od pravaca ili metoda u testiranju posmatrano sa aspekta troškova prije svega:

Prevencija ili detekcija:

Kvalitet se ne može postići na već gotovom proizvodu. Cilj je da se spriječe defekti ili nedostaci i da se proizvod učini mjerljivim pomoću parametara kvaliteta.

Neke od mjera kvaliteta su: struktuiranje razvojnog procesa uz pomoć standarda za razvoj softvera i podršku razvojnog procesa metodama, tehnikama i alatima. Nedetektovane greške koje su izazvale milione poslovnih gubitaka uslovile su rast nezavisnog testiranja. Troškovi proizvodnje se smanjuju sa ranim otkrivanjem i ispravkom grešaka. Uz alate za automatsko testiranje, dugoročno gledano, rezultat su proizvodi visokog kvaliteta i smanjeni troškovi održavanja.

Ukupni trošak efektivnog upravljanja kvalitetom predstavlja sumu četri komponente troškova: prevencije, inspekcije, internih i eksternih otkaza.

Preventivni troškovi sastoje se od akcija koje se preduzimaju kako bi se spriječili defekti.

Inspekcioni troškovi sastoje se od mjerenja, procjene i provjere proizvoda ili usluga i njihovog slaganja sa standardima i specifikacijama.

Troškovi internih otkaza su oni koji podrazumijevaju ispravku proizvoda sa greškama prije njihove isporuke. Troškovi eksternih otkaza sastoje se od grešaka otkrivenih nakon lansiranja proizvoda. Prevencija se najviše isplati jer povećavanje preventivnih troškova smanjuje broj defekata koji idu kupcu neotkriveni i tako se unapređuje kvalitet proizvoda i smanjuju troškovi proizvodnje i održavanja.

Verifikacija ili validacija:

Verifikacija omogućava da proizvod zadovolji zahtjeve koji si specificirani tokom prethodnih aktivnosti i oblikovani kroz životni iklus proizvoda, a validacija zadovoljenje zahtjeva kupaca na kraju životnog ciklusa proizvoda.

Kreiranje test proizvoda je bliže validaciji nego verifikaciji. Testiranje softvera se posmatra kao validacioni proces. Nakon završetka programiranja sistem se validira ili testira da bi se odredile funkcionalne ili operativne performanse. naravno, savremeni procesi testiranja se ne odvijaju samo nakon završetka programiranja, već su utkane u sam proces razvoja softvera.

Dobitna kombinacija je korišćenje verifikacije i validacije u procesu testiranja.

Verifikacija obuhvata sistematične procedure pregleda, analize i testiranja ugrađene u životni

8

Page 9: TESTIRANJE SOFTVERA - Tesic

ciklus, počevši od faze softverskih zahtjeva, do faze kodiranja. Verifikacija obezbjeđuje kvalitet i održavanje softvera. Koncept verifikacije uključuje dva kriterijuma: softver mora adekvatno i korektno izvršavati sve funkcije i ne smije izvršavati one funkcije koje sam po sebi ili u kombinaciji sa ostalim funkcijama mogu degradirati performanse čitavog sistema. Verifikacija takođe omogućava interoperabilnost među različitim sekcijama u softverskoj dokumentaciji i povezanim dijelovima zahtjeva.

Jedina kritika verifikacije je da povećava troškove razvoja softvera. Kada se troškovi softvera posmatraju kroz čitav životni vijek proizvoda, verifikacija zapravo umanjuje troškove softvera.

Uz efektivan proces verifikacije redukuju se defekti instaliranih sistema. Ukupna ušteda prevazilazi početni trošak, jer ispravka grešaka može koštati 20 do 100 puta više za vrijeme operacija i održavanja sistema, nego za vrijeme dizajniranja.

5. Proces testiranja

Testiranje se sastoji od sljedećih aktivnosti:

9

Page 10: TESTIRANJE SOFTVERA - Tesic

1. Planiranje testiranja

- Određuje se predmet, cilj i razlog testiranja (na osnovu zahtjeva, modela i drugih ulaza testiranja), gdje se testiranje vrši, kada se vrši i ko izvršava testove.

2. Dizajn testova

- Određuje kako se sprovodi testiranje na osnovu artefakta tj. test primjera.

3. Implementacija testova

- Pravljenje višestruko upotrebljivih test skriptova koji realizuju test primjere.

4. Izvršavanje testova

- Izvršavanje implementacije testa radi provjere funkcionalnosti sistema.

5. Evaluacija testova

- Procjena testova tj. validnosti izvršavanja testa, analiza izlaza, pregled zbirnih rezultata, uticaj promjene zahtjeva i ulaza na plan testiranja.

Svaka od ovih aktivnosti ima ulaze i izlaze. U procesu testiranja koriste se i različiti alati koji pospješuju proces i daju bolji uvid u rezultate (npr. Rational, Test Complete i sl.).

Organizacija procesa testiranja

Proces testiranja mora se odvijati tokom svih faza životnog ciklusa. Za ovaj proces moraju se realizovati standardizovani propisi i procedure koje definišu način rada i aktivnosti test odjeljenja, kao i svih učesnika u razvoju. Sve aktivnosti članova tima koji učestvuju u realizaciji procesa testiranja moraju biti dokumentovane i moraju pokriti sledeće:

- Odgovornosti i zaduženja za planiranje testa, izvršenje i evaluaciju.

- Ciljeve testa, tipove koji će se primijeniti, raspored i zaduženja kod testiranja kroz

plan testiranja.

- Odgovarajući materijal (dokumenta, test primjeri i dr.).

- Test materijal je podložan periodičnim aktivnostima kontrole kvaliteta.

Tipovi testiranja

Inspekcije, recenzije, pregledi

Inspekcije, recenzije i pregledi su specifične tehnike fokusirane na ocjenjivanje artefakata

10

Page 11: TESTIRANJE SOFTVERA - Tesic

(pogodno za dokumentaciju, programski kod) i efikasne su metode za poboljšanje kvaliteta i razvojnog procesa proizvoda. Sprovode se na sastancima, gdje jedan od učesnika ima ulogu vodećeg, a ostali uloge zapisičara (beleži pitanja, predloge, probleme i sl.).

Ove tehnike opisuju se u okviru IEEE standarda na sljedeći nalin:

- Recenzija (review) - formalni stastanak na kome se artefakt ili skup artefakata predstavlja korisniku ili drugim stranama koje učestvuju u procesu odobravanja ili komentarisanja.

- Inspekcija (inspection) - fomalna tehnika procjene u kojoj se artefakti detaljno pregledaju. Pregled vrše osobe koje nisu autori, da bi se lakše uočile greške i drugi problemi.

- Pregledi (walkthrough) - tehnika pregleda u kojoj autor upoznaje ostale članove tima sa elementima artefakta koji je izgradio. Ostali članovi učestvuju aktivno u raspravi.

5.3 Tehnike testiranja

1. Jedinično testiranje (unit testing) - primjenjuje se na pojedine klase, module ili komponente programskog koda. Ova tehnika dijeli se na tehnike bijele i crne kutije.

2. Integraciono testiranje - primjenjuje se na softverski sitem kao cjelinu.

3. U testiranja višeg reda spadaju:

- testiranje sigurnosti (security testing): da li su funkcije dostupne onim i samo onim korisnicima kojima su i namenjene.

- testiranje količine podataka - verifikovanje da li softver može obraditi veliku količinu podataka. .-

- testiranje upotrebljivosti (usability testing) - estetski aspekti, konzistentnost korisničkog interfejsa, korisnička dokumentacija.

- testiranje integriteta (integrity testing) - robusnost(otpornost na otkaze), konzistentna upotreba resursa i sl.

- test u stresnim uslovima (stress testing) - vrsta testa pouzdanosti sistema pod nenormalnim uslovima (velika opterećenja sistema, nedovoljno memorije ili drugih resursa, neraspoloživi servisi i sl.).

- etalonski test - upoređenje performansi novog sistema sa nekim, referentnim, poznatim sistemom.

- test zagušenja - provjera da li sistem može da zadovolji višestruke zahtjeve različitih aktera za istim resursom.

- test opterećenja - vrsta testa performansi kojim se procjenjuju operativni limiti nepromjenjivog sistema pod različitim opterećenjima ili različitih konfiguracija sistema pri istom opterećenju. Najčešće se mjere protok i vrijeme odziva (srednja i granična vrednost).

- test konfiguracije (configuration testing) - testira ponašanje softvera u različitim hardversko/softverskim okruženjima.

- test instalacije (installation testing) - testira instaliranje softvera na različitim sistemima i u različitim situacijama (npr. prekid napajanja ili nedovoljno prostora na disku).

11

Page 12: TESTIRANJE SOFTVERA - Tesic

4. Regresiono testiranje - na osnovu jednom razvijenog testa više puta se sprovodi testiranje softvera (tipično nakon neke izmjene u softveru da bi se utvrdilo da nisu pokvarene funkcionalnosti softvera).

Pregled tehnika testiranja

12

Page 13: TESTIRANJE SOFTVERA - Tesic

Testiranje se posmatra kao posebna faza životnog ciklusa proizvoda koja prati kodiranje. Moderni model softverskog životnog ciklusa izbjegava ovakvo gledanje na stvari i u prvi plan stavlja iterativno testiranje kroz razvoj životnog ciklusa.

Testiranje omogućava ranu detekciju grešaka i ispravku istih i tehnički uvid u pravu prirodu performansi sistema. Obično se koristi nekoliko testnih metodologija da bi se obradili različiti aspekti softverskog proizvoda.

Kako su do sada objašnjeni samo neki od tipova i tehnika testiranja u tabeli je dat pregled savremenih tehnika testiranja sa opisom. Tehnike se kombinuju i variraju.

Tehnika Kratak opis

Acceptance testing – Testiranje prihvatljivosti

Finalno testiranje bazirano na specifikacijma krajnjeg korisnika, potrošača, ili bazirano na korišćenju krajnjih korisnika, potrošača u određenom vremenskom periodu.

Ad hoc testing - Ad hoc testiranjeSlično istraživačkom testiranju, ali se često odnosi na to da testeri dobro razumiju softver pre samog testiranja.

Alpha testing - Alfa testiranje

Testiranje kada je razvoj pri kraju; manje promjene u dizajnu moguće su kao rezultat ovog testiranja.

Obično ga izvršavaju krajnji korisnici ili drugi, a ne programeri i testeri.

Basis path testing - Testiranje osnovnih tokova

Identifikovanje testova na bazi tokova i putanja programa ili sistema.

Beta testing - Beta testiranje

Kada su razvoj i testiranje u suštini završeni i potrebno je pronaći konačne greške i probleme prije samog lansiranja proizvoda. Obavljaju ga krajnji korisnici ili drugi, ne programeri ili testeri.

Tehnika Kratak opis

13

Page 14: TESTIRANJE SOFTVERA - Tesic

Black-box testing - Black-box testiranjeTestovi se generišu na osnovu funkcionalnosti sistema.

Bottom - up testing - Testiranje od dna ka vrhu

Integrisanje modula ili programa počevši od dna.

Boundary value testing - Testiranje graničnih vrednosti

Testovi se generišu iz graničnih vrijednosti odgovarajućih klasa

Branch coverage testing –Branch (gransko) testiranje

Verifikacija da svaka grana ima true ili false izlaze.

Branch/condition coverage - Grana/uslov testiranje

Verifikacija da svaki uslov obuhvata sve moguće izlaze

Comparison testing - Uporedno testiranje Upoređivanje slabosti i dobrih strana softvera sa konkurentskim proizvodima.

Compatibility testing – Testiranje kompatibilnosti

Testiranje koliko dobro softver radi u određenom hardversko/softverskom/OS/ mrežnom/okruženju.

Condition coverage testing - Testiranje pokrivenosti uslova

Potvrda da svaki uslov obuhvata sve moguće izlaze.

Tehnika Kratak opis

14

Page 15: TESTIRANJE SOFTVERA - Tesic

White-box testing - White-box testiranjeTestovi se definišu ispitivanjem logičkih iskaza sistema

Unit testing - Jedinično testiranje

Mikro testiranje određenih funkcija ili modula koda. Obično ih obavlja programer, a ne tester, jer zahteva detaljno poznavanje internog dizajna i koda programa.

Table testing - Tabelarno testiranjeTestiranje pristupa, sigurnosti i integriteta podataka tabela ulaza.

System testing - Sistemsko testiranje

Black-box tip testiranja koji se bazira na zahtjevima; pokriva sve kombinovane dijelove sistema.

Syntax testing - Sintaksno testiranjeTehnika vođena podacima i test kombinacijama ulazne sintakse.

Stress testing - Stres testiranje

Testiranje funkcionalnosti sistema pod opterećenjem, ponavljanjem određenih akcija ili ulaza, veliki ulazni brojevi ili kompleksni upiti nad bazom.

Security testing - Testiranje sigurnostiTestiranje koliko dobro sistem reaguje na neautorizovane napade.

Tabela 2: Pregled tehnika testiranja

6. Kada prestati testirati?

15

Page 16: TESTIRANJE SOFTVERA - Tesic

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.

7. Osnove softverskog testiranja

16

Page 17: TESTIRANJE SOFTVERA - Tesic

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 ukazuje na odstupanje od 0,01% između stvarnih i očekivanih rezultata, može trajati satima, danima ili mjesecima.

7.1 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

17

Page 18: TESTIRANJE SOFTVERA - Tesic

Slika 2: Testiranje softvera

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

18

Page 19: TESTIRANJE SOFTVERA - Tesic

7.2 Vrste softverskog testiranja

Vrste pristupa za identifikovanje grešaka u softveru:

Statičko

Dinamičko

Slika 3: Vrste softverskog testiranja

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.

7.3 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

19

Page 20: TESTIRANJE SOFTVERA - Tesic

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.

20

Page 21: TESTIRANJE SOFTVERA - Tesic

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.

21

Page 22: TESTIRANJE SOFTVERA - Tesic

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

7.5 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 koji objekat o kojem se sudi na osnovu spoljnjih manifestacija bez poznavanja strukture objekta.

22

Page 23: TESTIRANJE SOFTVERA - Tesic

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

23

Page 24: TESTIRANJE SOFTVERA - Tesic

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.

Nedostaci 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

24

Page 25: TESTIRANJE SOFTVERA - Tesic

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

25

Page 26: TESTIRANJE SOFTVERA - Tesic

7.6 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:

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.

26

Page 27: TESTIRANJE SOFTVERA - Tesic

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

Slika 4: Cause – Effect grafik

27

Page 28: TESTIRANJE SOFTVERA - Tesic

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

7.9 Poboljšanja procesa testiranja

28

Page 29: TESTIRANJE SOFTVERA - Tesic

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.

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

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

29

Page 30: TESTIRANJE SOFTVERA - Tesic

Pokušati instalaciju na slabijem računaru koji ima manje memorije (non–compliant), RAM, HDD

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

30

Page 31: TESTIRANJE SOFTVERA - Tesic

podrške proizilaze iz složenosti programskog rješenja. Testiranje je više od običnog debagovanja.

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

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.

Kako bi se izbegli ovi problemi, problemi kasnog sprovođenja kontrole kvaliteta, danas je sve zastupljenija ideja da se testiranje uvodi paralelno sa razvojem, da od starta bude sjenka razvoja. Na ovaj način, uklanjaju se brojni nedostaci kasne spoznaje grešaka, gubljenje vremena i smanjuju troškovi.

Proces testiranja se usavršava i automatizuje i na taj način štedi vrijeme i povećava kvalitet.

Ovo je prava formula uspjeha.

9. Literatura

- Ivaneža D.: „Primjena standarda u radu informacionog sistema“, Zavod za informatiku i internet 2003

31

Page 32: TESTIRANJE SOFTVERA - Tesic

- Chillarege, R.: „Software Test Best Practices“, Center for Software Engineering, IBM Research 1999

- Dejanovic R., Preradovic Lj., Softverski inženjering, Elektrotehnički fakultet, Banja Luka 2007.

- Lewis W.E.: „Software Testing and Continuous Quality Improvement“, Second Edition - Auerbach Publications 2005.

- www.wikipedia.org

- www.softwaretestingwiki.com

32

Page 33: TESTIRANJE SOFTVERA - Tesic

Mišljenje o radu:

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Ocjena rada:___________________________________________________________________________

Usmena odbrana rada:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Ocjena usmene odbrane rada:___________________________________________________________________________

Članovi komisije:1. _________________________2. _________________________3._________________________

33