Testiranje softvera

Sadrzaj:

1. Uvod 1
2. Šta je testiranje? 2
2.1. Zašto testiramo? 3
2.2. Vrijeme za testiranje? 3
2.3. Otklanjanje grešaka 4
2.4. Troškovi otklanjanja grešaka 4
2.5. Kada prestati testirati? 4
3. Ciljevi testiranja 5
4. Softverske greške (error), mane, tj. defekti (faults) i otkazi (failures) 6
5. Klasifikacija i metode testiranja 7
5.1. Metode crne kutije 7
5.1.1. Podjela na klase ekvivalencije 7
5.1.2. Analiza graničnih vrijednosti 9
5.1.3. Uzročno - posledični grafovi 10
5.2. Metode bijele kutije 14
5.2.1. Pokrivanje iskaza (Statement coverage) 14
5.2.2. Pokrivanje odluka (Decision coverage) 17
5.2.3. Pokrivanje uslova 17
5.2.4. Metoda graničnog testiranja unutrašnje putanje (boundary interior path testing) 18
5.2.5. Testiranje metodom toka podataka 20
5.2.6. Pokrivanje bazičnih putanja 23
Literatura 26


1. Uvod

Dolaskom 21.vijeka, kao i manjim dijelom pripremanja ulaska naše zemlje u EU, naglašen je i te kako primjetan razvoj mikroelektronike, informatičke i komunikacijske tehnologije. Sve se obavlja računarom i rješenja se primenjuju u svim područjima ljudskog djelovanja, nezavisno od predmeta posla ili tematike i materije. Izvršavanje i najsitnijih obaveza, najbizarnijih poslova postalo je zavisno o računaru i ispravnosti istog. Da bi jedan računar bio ispravan nužno je da su ispravna oba dijela, i sklopovski i programski. Postoji tzv. testiranje programske greške, a taj proces predstavlja traženje grešaka u računaru. Programska podrška nije poput drugih fizičkih sistema, a do pojave grešaka dolazi zbog mnogih razloga, koji nam se ponekad i ne učine kao i adekvatni razlozi. Postoje i logičke greške, koje mogu biti otkrivene detaljnijim testiranjem aplikacije. Greške su gotovo neizbježne, pa čak i iskusniji programeri prave sitne, trivijalne opaske, koje svi smatramo da su banalne. A kako nas je život naučio, najbitnija su očekivanja ili neočekivanja. Najbitnije u ovom slučaju jeste očekivati greške u kodu.


2. Šta je testiranje?

Testiranje softvera je formalni proces koji se izvodi sa specifičnim timom za testiranje kojim se ispituju softverske jedinice ili cjelokupni softverski paketi izvršavanjem programa na kompjuteru. Svi povezani testovi se izvršavaju u skladu sa odobrenim test procedurama na odobrenim test slučajevima.
U razvojnom ciklusu softvera sve je značajniji zadatak Testiranje softvera (TS) ili Verifikacije i Validacije (V&V) koji treba da obezbijedi zahtjevani nivo povjerenja u ispravnost (ili korektnost) softvera, kao i obezbjeđenja ostalih zahtjevanih karakteristika softvera. Testiranje softvera je izuzetno skup proces.
Abnormalno veliki su gubici firmi uslijed grešaka u softveru, koji su uslovili razvoj oblasti krivične odgovornosti proizvođača softvera i zaštite kupaca zbog neadekvatnog kvaliteta softverskog proizvoda. Iz svih navedenih razloga, poslednjih godina je intenzivirano istraživanje u oblasti testiranja softvera u svijetu, kao i zbog dolje identifikovanih neriješenih problema u ovoj oblasti. Jedan od načina da se spriječi isporuka softvera kupcu sa greškama je da skoro sve kompanije ulažu sve više sredstava u obuku kadrova i opremu za testiranje softvera. Veoma je važno, da ne kažem presudno razviti mjerljive tehnike za ocjenu efektivnosti postojećeg procesa testiranja softvera, kako bi se otkrile njegove slabosti i prednosti, identifikovali kako rizici tako i njihove posledice.
Testiranje je aktivnost izvedena radi evaluacije kvaliteta proizvodnje i njegovog poboljšanja. Ono nije aktivnost koja počinje samo nakon kompletiranja faze kodiranja. Softversko testiranje se danas vidi kao aktivnost koja obuhvata cio proces razvoja i održavanja, i predstavlja važan dio kompletne konstrukcije softvera. Planiranje testiranja treba da počne sa ranom fazom requirement procesa, i test planovi i procedure moraju biti sistematski i kontinualno razvijani i po potrebi redifinisani. Pravi stav prema kvalitetu je prevencija, mnogo je bolje izbjeći probleme nego ih ispravljati...kao i za sve ostale životne situacije fraza je neizbežna da je bolje sprečiti, nego lečiti. Stoga, ja posmatram stvari vrlo jednostavno- Softer je kao i život. Ima neminovnih grešaka, naše je da ih svedemo na minimum ili potpuno uklonimo. Da stvorimo harmoniju i balans.


2.1. Zašto testiramo?

Veliki su gubici kompanija zbog defekata u softeru i problema o kojem gore govorimo. Prvenstveni zadatak test inženjera jeste otkrivanje softverskog kvara, sa ciljem da se on otkloni prije predaje softverskog proizvoda kupcu, kako bi kupac bio zadovoljan i dobio ono što želi. Od test inženjera se zahteva da otkrije što je moguće više problema i to što više onih, vrlo ozbiljnih čije posledice mogu biti katastrofalne sa materijalnog i bezbjednosnog aspekta. Zato je sa svih aspekata potrebno da se proces testiranja softvera učini što efikasnijim i uz što manje troškove ukoliko je to moguće.

2.2. Vrijeme za testiranje?
Neophodno je misliti o testiranju softvera već prvog dana nakon početka projekta, a ne kao što je uobičajeno da se aktivnost testiranja softvera planira na kraju razvoja softvera. Glavni problem je taj, da skoro nikad nema dovoljno vremena za testiranje softvera. Zato treba da mijenjamo odnos prema aktivnosti testiranja softvera i vremenu koje je planirano za testiranje, tako što ćemo ga efikasnije utrošiti u ranim fazama razvoja softvera.


2.3. Otklanjanje grešaka

Pristup testiranju softvera na bazi otklanjanja grešaka je takođe proces koji je podložan greškama. Tester softver mora da identifikuje i proprati uočen problem do mjesta nastanka (izvora) greške u softveru. Za otklanjanje grešaka u softveru se moraju istražiti sve prethodne verzije i dokumentacija o aktivnostima u svim prethodnim fazama u razvoju softvera, ukoliko su raspoloživi. Cilj da se pokaže da softver nema grešaka, kroz otkrivanje i otklanjanje grešaka, je lošija od strategije da se izvrši analiza uzroka nastanka grešaka, pa tek onda izvrši uklanjanje grešaka.


2.4. Troškovi otklanjanja grešaka

Troškovi otklanjanja uočenih grešaka, umjesto spriječavanja njihovog nastanka, su veliki i prouzrokuju veliki gubitak u poslovanju i nezadovoljstvo kupca zbog grešaka u softveru. Prije nego što se čeka završetak faze implementacije komponente softvera, pa tek onda testiranje komponente u clju otkrivanja i otklanjanja grešaka u njima, a koje su nastale u ranijim fazama procesa razvoja, potrebno je preventivno djelovati na nastanak tih grešaka, kako bi se izbjegla kašnjenja i uvećali troškovi njihovog otklanjanja. Upravo je to cilj sprovođenja aktivnosti prevencije nastanka grešaka. U poslednje vrijeme je razvijen veliki broj metoda u cilju spriječavanja nastanka grešaka u softveru- metod dokazivanja korektnosti sofrvera, strategija projektovanja po Six Sigma i mnoge druge.


2.5. Kada prestati testirati?

Ne postoji vrijeme kada treba prestati sa testiranjem. Ono se praktično može izvoditi beskrajno puta i nikad da se stane, sa istim. Nikad se ne može sa sigurnošću reći da su otkriveni i uklonjeni svi mogući defekti. Ali, naravno da u jednom trenutku treba prestati testirati. Pitanje je samo kada to učiniti, kada je taj trenutak? 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. 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.


3. Ciljevi testiranja

Dva su osnovna, glavna i najveća cilja ovog fenomena koji obradjujem, problemi i testiranje, a to su:
Verifikacija: Da li dobro gradimo proizvod?
Softver to treba potvrditi svojom specifikacijom (dokumentacijom)
Validacija: Da li gradimo dobar proizvod?
Softver treba činiti ono što korisnik stvarno želi
Verifikacija je provjera odgovaraju li rezultati etapa razvoja očekivanim rezultatima pojedine etape.
Validacija je provjera da je sistem očekivane rezultate kao funkciju ulaza.
Ove dvije definicije objašnjavaju i terminoloshko i fenomenoloshki pojam i značenje. Naišao sam radeći na još mnogo sličnih ili manje sličnih def. Ali su ove bile najbliže i mom logičkom redosledu shvatanja stvari. Dva su osnovna cilja su otkriti nedostatke (greške) i procijeniti koliko je sistem upotrebljiv. V&V treba stvoriti povjerenje da je softver spreman za produkciju i to ne znači da je softver potpuno bez nedostaka, ali mora biti dovoljno dobar da može ispuniti svoju namjenu.
Unutar procesa V&V primjenjuje se dvije tehnike provjere i analize programskog sistema: kontrola softvera i testiranje sistema.
Kontrola softvera se odnosi se na analizu statičkog prikaza sistema kako bi se otkrili problemi (statička verifikacija). Ono uključuje analizu i provjeru predstavljenog sistema kroz specifikaciju (dokument) zahtjeva, dijagrame oblikovanja, izvorni kod programa.
Testiranje sistema se odnosi na ispitivanje i posmatranje ponašanja softverskog proizvoda (dinamička verifikacija). Ono uključuje implementaciju sistema sa test podacima, ispitivanje izlaznih rezultata i provjera da li se ponašanje sistema odvija na način kako je to zahtijevano.