Testiranje softvera

SADRŽAJ:

1. Uvod 4
2. Definicija i ciljevi testiranja 5
3. Strategije testiranja softvera 7
3.1 „Big Bang“ strategija 8
3.2 Top-down i bottom-up testiranje 8
4. Klasifikacije softverskih testova 8
4.1 Klasifikacija prema konceptu testiranja 9
4.2 Klasifikacija u skladu sa zahtjevima 9
5. Klasične tehnike bijele kutije 10
5.1 Testiranje osnovnih putanja 11
5.2 Kontrola toka/testiranje pokrivenosti 13
5.2.1 Pokrivenost iskaza 13
5.2.2 Pokrivenost grana(odluka) 14
5.2.3 Pokrivenost baznih putanja 15
5.2.4 Pokrivenost uslova 15

6. Klasične tehnike crne kutije 16
6.1 Podjela na klase ekvivalencije 16
6.2 Alaniza graničnih vrijednosti 18
6.3 Tabela odlučivanja 19

7. Zaključak 22

8. Literatura 23

Softver obuhvata računarske programe, procedure, eventualno prateću dokumentaciju, i podatke vezane za operacije u računarskom sistemu (IEEE definicija).

Kvalitet softvera se može definisati kao skladnost softvera sa prethodno utvrđenim funkcionalnim zahtjevima, dokumentovanim u razvojnim standardima i karakteristikama koje se očekuju od svakog profesionalno razvijenog softvera.

Osiguranje kvaliteta softvera je planirani niz akcija koji obezbjeđuje odgovarajuće povjerenje u to da je proces razvoja ili održavanja softverskog proizvoda u skladu sa funkcionalnim tehničkim zahtjevima kao i sa zahtjevima menadžmenta u smislu održanja vremena i troškova u granicama budžeta[1].

Da bi softver bio kvalitetan mora ispuniti zahtjeve koji se tiču pouzdanosti i sigurnosti, efikasnosti, upotrebljivosti i mogućnosti održavanja. Kvalitet softvera najviše zavisi od projektanata i programera, tj. vođa razvojnih timova. Oni definišu politiku izgradnje i testiranja određenog nivoa kvaliteta u različitim fazama razvoja softvera. Kontrola kvaliteta softvera je neophodna faza u životnom ciklusu softvera i treba je shvatiti kao preventivu.

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. U ovom radu će biti opisane osnovne strategije i najčešće korišćene tehnike testiranja softvera.

2. DEFINICIJA I CILjEVI TESTIRANjA

Testiranje softvera je proces izvršavanja programa s ciljem pronalaženja grešaka. Ono se sastoji od dinamičke verifikacije ponašanja programa na konačnom skupu test slučajeva, prikladno izabranih iz obično beskonačnog domena izvršavanja, prema očekivanom ponašanju [2].

Testiranje softvera takođe pruža objektivan, nezavisan pogled na softver kako bi se omogućilo klijentu da cijeni i razumije rizike implementacije tog softvera. Tehnike testiranja uključuju proces izvršavanja aplikacije u cilju pronalaženja softverskih grešaka, ali nisu ograničene samo na to.
Testiranje softvera se takođe može navesti kao proces provjere i verifikovanja programa odnosno proizvoda koji:
• Ispunjava poslovne i tehničke zahtjeve kojima je sproveden njegov dizajn i razvoj,
• Radi kako treba,
• Može biti implementiran sa tim istim karakteristikama.

CILJEVI TESTIRANJA:

Glavni cilj testiranja je da se utvrdi da li sistem ispunjava zahtjeve korisnika i da li je sistem pouzdan.

Direktni ciljevi
• Identifikacija i objavljivanje onoliko grešaka koliko je moguće u softveru koji se testira.
• Dati testirani softver nakon korekcije identifikovanih grešaka i ponovnog testiranja do prihvatljivog nivoa kvaliteta.
• Izvršavanje zahtijevanih testova efektivno i efikasno unutar budžeta i vremenskog rasporeda.
Indirektni ciljevi
• Skupljanje zapisa o softverskim greškama da bi se koristile u prevenciji grešaka za korektivne i preventivne akcije.


Mnogo termina se u literaturi o softverskom inžinjerstvu koristi radi opisa mana i grešaka (eng. error, fault, failure i dr.). Ključno je razdvojiti uzroke defekata, za koje se često koristi termin greška (fault ili defect) i neželjenog efekta posmatranog u isporučenom sistemu koji zovemo otkaz (failure). Otkaz je posledica odnosno manifestacija greške u softveru. Uzrok za otkaz ne može uvijek biti nedvosmisleno identifikovan jer ne postoji teoretski kriterijum radi preciznog određivanja koja je greška prouzrokovala posmatrani otkaz.

Mnogo je efikasnije spriječiti nastanak grešaka nego detektovati i otkloniti iste. To znači da treba testirati svaku proceduru ili modul odmah nakon njegovog pisanja. Testiranje u fazi integracije sistema se mora izvršiti odmah nakon integracije komponenti softvera u sistem.

VERIFIKACIJA I VALIDACIJA

Kada se proces razvoja softvera završi, prije njegove isporuke kupcu treba ga još jednom testirati u smislu da se utvrdi: da li proizvod korektno radi, odnosno da li izvršava sve one funkcije koje kupac od njega očekuje.
Želimo li provjeriti je li softverski proizvod u informatičkom smislu korektno napravljen primijenićemo postupak verifikacije (Traži se odgovor na pitanje: Da li dobro gradimo proizvod?), a ako želimo provjeriti da li taj proizvod zaista zadovoljava želje i potrebe korisnika (kupaca) primijenićemo postupak validacije (Traži se odgovor na pitanje: Da li gradimo dobar proizvod?). Verifikacija i validacija moraju biti primijenjene u svakoj fazi razvoja softvera. Proces verifikacije i validacije ima dva osnovna cilja:
• Da otkrije defekte u sistemu
• Da procijeni da li je softver koristan i upotrebljiv u operativnom smislu

Verifikacijom i validacijom bi se trebalo steći povjerenje u to da je softver pogodan za korišćenje (što ne znači da nema nikakvih defekata).

3. STATEGIJE TESTIRANjA SOFTVERA

Iako metodologije testiranja mogu varirati, najčešće se nalaze u okviru dvije osnovne strategije:
• Testiranje softvera u cjelosti, nakon što je kompletan paket raspoloživ i poznat (“big bang testing”).
• Testiranje softvera u manjim dijelovima, modulima kada se oni završe (unit tests); poslije testiranje grupe testiranih modula sa novim završenim modulima (integration tests). Ovaj proces se nastavlja dok svi softverski moduli ne budu testirani. Kada se ova faza kompletira, sadržaj paketa se testira kao cjelina (system test). Ova strategija se uobičajeno naziva “inkrementalno testiranje”.

3.1 „BIG BANG” STRATEGIJA

U ovom pristupu, sve ili većina razvijenih modula su spojena zajedno formirajući kompletan softverski sistem ili glavni dio sistema a zatim se koriste za testiranje integracije [3]. Metoda Big Bang je vrlo djelotvorna za uštedu vremena u procesu testiranja integracije. Međutim, ako se testni slučajevi i njihovi rezultati ispravno ne zabilježe, cijeli proces integracije će biti mnogo komplikovaniji i može čak spriječiti tim za testiranje da ostvari cilj testiranja integracije.

Jedan tip Big Bang testiranja integracije zove se Usage Model testiranje. Usage Model testiranje se može koristiti u testiranju i softvera i hardvera. Osnove ovog tipa integracionog testiranja leže u upotrebi korisnički orijentisanih opterećenja u integrisanim korisničkim okruženjima.

Radeći testiranja na ovaj način, utvrđeno je okruženje, dok su pojedine komponente sistema testirane indirektno kroz njihovo korišćenje. Usage model testiranje daje optimističan pristup testiranju jer očekuje da će biti malo problema sa pojedinim komponentama. Strategija se u velikoj mjeri oslanja na to da ljudi koji razvijaju komponente izvrše testiranje izolovanih jedinica njihovog proizvoda. Cilj strategije je izbjegavanje ponovnog testiranja koje su već odradili programeri i umjesto toga utvrđivanje problema izazvanih interakcijom komponenata u okolini. Za testiranje integracije, Usage Model testiranje može biti efikasnije i omogućava bolju pokrivenost testa od tradicionalno usmjerenih funkcionalnih testova integracije. Da bi bio efikasan i precizan, mora se fokusirati na definisanje opterećenja izazvanih od strane korisnika da bi se stvorili realni scenariji uticaja okruženja. Ovo osigurava da integrisana okolina radi kao što bi trebalo za ciljne korisnike.

3.2 TOP-DOWN I BOTTOM-UP TESTIRANjE

Bottom-up testiranje je pristup integracionom testiranju gdje se prvo testiraju komponente najnižeg nivoa što olakšava kasnije testiranje komponenti višeg nivoa. Proces se ponavlja sve dok se ne testira komponenta na vrhu hijerarhije.

Svi donji moduli, odnosno procedure ili funkcije nižeg nivoa su integrisani i zatim testirani. Poslije integracionog testiranja integrisanih modula nižeg nivoa, formira se sljedeći nivo modula i može biti korišten za testiranje integracije. Ovaj pristup je koristan samo ako su svi ili većina modula istog razvojnog nivoa spremni. Ova metoda takođe pomaže da se utvrde nivoi razvijanog softvera i da se olakša dobijanje izvještaja o napretku softvera u obliku procenta.

Top-down testiranje je pristup integracionom testiranju gdje se testiraju moduli najvišeg nivoa, a grane modula se testiraju korak po korak sve dok se ne dođe do kraja tog modula.

Sandwich testiranje je pristup u kojem se kombinuju top-down i bottom-up strategije. Glavna prednost bottom-up pristupa je što je greške lakše naći. S top-down strategijom, lakše je naći vezu grane koja nedostaje.

4. KLASIFIKACIJA SOFTVERSKIH TESTOVA

Postoje dva nivoa klasifikacije. Jedan razlikuje nivo granularnosti:
• Nivo jedinice
• Nivo sistema
• Nivo integracije

Ostale klasifikacije [4] (uglavnom za nivo jedinice) bazirane su na metodologijama:

• Metoda crne kutije (funkcionalno testiranje)
Testiranje koje ignoriše interne mehanizme sistema ili komponente i fokusira se samo na izlaze generisane u odzivu na odabrane ulaze i uslove izvršavanja.
• Metoda bijele kutije (strukturalno testiranje)
Testiranje sprovedeno radi procjenjivanja saglasnosti sistema ili komponente sa specifikovanim funkcionalnim zahtjevima.

Softverski testovi se takođe mogu klasifikovati u skladu sa konceptom testiranja ili u skladu sa klasifikacijom zahtjeva – McCall koja se odnosi na osiguranje kvaliteta softvera.

4.1 KLASIFIKACIJA PREMA KONCEPTIMA TESTIRANjA

U toku su debate da li je testiranje funkcionalnosti softvera samo na osnovu njegovih izlaza dovoljno da se postigne prihvatljiv nivo kvaliteta. Neki tvrde da se interna struktura softvera i kalkulacije trebaju uključiti za uspješno testiranje. Bazirajući se na ova dva suprotna koncepta pristupa kvalitetu softvera, razvijene su tri klase testiranja:

Black box (funkcionalno) testiranje

Identifikuje bugove samo u skladu sa softverskim nepravilnostima u radu koji se otkrivaju u pogrešnim izlazima. U slučaju kada su pronađeni izlazi za korekciju, black box testiranje zanemaruje interni put kalkulacija i procesuiranja.

White box (strukturalno) testiranje

Ispituje interne kalkulacijske puteve u namjeri da identifikuje bugove. Izraz “white” je dat da istakne razliku između ove metode i black box testiranja. Pored ovoga postoji i drugo ime za ovu metodu, a to je “glass box” testiranje i koje bolje izražava osnovne karakteristike ove metode testiranja, ispitivanje korektnosti strukture koda.

Grey box testiranje

Uključuje mogućnost pristupa internim strukturama podataka i algoritama zbog potrebe izrade testnih slučajeva, ali i testiranja kod korisnika ili na black-box nivou. Manipulisanje ulaznim podacima i kreiranje izlaza, ne kvalifikuje se kao gray box jer je jasno da su ulaz i izlaz izvan crne kutije, koju nazivamo sistemom koji se testira. Ova razlika je posebno važna kada se sprovodi integraciono testiranje između dva modula koda koji su napisala dva različita programera gdje su samo interfejsi izloženi testiranju. Međutim, modifikacija podataka se ne kvalifikuje kao gray box jer bi korisnik normalno mogao promijeniti podatke izvan testiranog sistema. Gray box testiranje takođe može da uključuje obrnuti (reverse) inženjering da bi se utvrdile, na primjer, granične vrijednosti ili poruke o greškama.

OSTATAK RADA JE U ATACHMENTU BESPLATAN ZA DONWLOAD.