Poglavlje 4:
Verifikacija i validacija
Sastavio: Robert Manger
11.12.2020
Sveučilište u Zagrebu
PMF – Matematički odsjek
SOFTVERSKO INŽENJERSTVO
Predavanja 2020/2021
O čemu je riječ u Poglavlju 4
• Bavimo se verifikacijom i validacijom (V&V).
• Riječ je o osnovnoj aktivnosti unutar softverskog procesa kojom se nastoji utvrditi:– da li softver zadovoljava specifikaciju,
– da li on odgovara potrebama korisnika.
• Prvo potpoglavlje sadrži definicije pojmova vezanih uz V&V.
• Daljnja dva potpoglavlja proučavaju dvije metode verifikacije softvera:– statička verifikacija
– testiranje.
SI-4 SOFTVERSKO INŽENJERSTVO 2
Sadržaj Poglavlja 4
4.1. Općenito o verifikaciji i validaciji
4.2. Statička verifikacija
4.3. Testiranje softvera
SI-4 SOFTVERSKO INŽENJERSTVO 3
Općenito o verifikaciji i validaciji
SI-4 SOFTVERSKO INŽENJERSTVO 4
• V&V su srodni pojmovi, no postoji suptilna razlika.- Verifikacija (Are we building the product right?) je
provjera odgovara li softver specifikaciji, dakle dokumentu o zahtjevima.
- Validacija (Are we building the right product?) je provjera zadovoljava li softver „stvarnim“ potrebama korisnika.
• Razlika nastaje zato što specifikacija obično ne uspijeva u potpunosti zabilježiti stvarne potrebe korisnika.
• Konačni cilj V&V je uvjeriti se da je softver dovoljno dobar i pouzdan da može poslužitisvojoj svrsi.
Metode za verifikaciju i validaciju (1)
• Ugrubo se mogu podijeliti u dvije skupine.
– Statička V&V. Analiza i provjera dokumenata,
modela sustava, dizajna, odnosno programskog
koda. Odvija se bez stvarnog izvođenja softvera.
– Testiranje. Pokusno izvođenje softvera ili njegovih
dijelova, na umjetno pripravljenim podacima, uz
pažljivo analiziranje rezultata.
• Testiranje je uobičajena metoda, no statička
V&V ima sljedeće prednosti.
– Jedna statička provjera može otkriti puno pogrešaka.
– Statička provjera omogućuje bolje korištenje znanja
o programiranju ili aplikacijskoj domeni.
SI-4 SOFTVERSKO INŽENJERSTVO 5
Metode za verifikaciju i validaciju (2)
• Statička provjera može se obavljati u raznim
fazama softverskog procesa.
• Testiranje je primjenjivo samo na program
odnosno prototip.
• Statičkim metodama se može uz male troškove
otkriti 60-90% pogrešaka u programu.
• Nakon toga testiranje programa ide brže, a
ukupni troškovi su manji.
• Dvije vrste metoda su komplementarne te se
obje trebaju primjenjivati.
SI-4 SOFTVERSKO INŽENJERSTVO 6
Mjesto V&V u softverskom procesu (1)
• V&V se prvenstveno primjenjuju na programski kod, no poželjno je da se u što većoj mjeri primjenjuju i u ranijim fazama razvoja softvera.
SI-4 SOFTVERSKO INŽENJERSTVO 7
StatičkaV&V
Testiranje
Specifikacija
zahtjeva
Dizajn na
visokoj razini
Formalna specifikacija
Detaljni
dizajnProgram
Prototip
Mjesto V&V u softverskom procesu (2)
• Da bi aktivnosti V&V dale očekivane efekte, moraju postojati planovi testiranja
• Ti planovi trebali bi nastati već u fazi specifikacije i oblikovanja sustava
SI-4 SOFTVERSKO INŽENJERSTVO 8
Specifikacija
zahtjeva
Specifikacija
sustava
Oblikovanje
sustava
Detaljno
oblikovanje
Plan za
primopre-
dajni test
Plan za test
integracije
sustava
Plan za test
integracije
pod-sustava
Puštanje u
rad
Primopre-
dajni test
Test
integracije
sustava
Test
integracije
pod-sustava
Kodiranje i testiranje modula i manjih
dijelova
Mjesto V&V u softverskom procesu (3)
• Plan za testiranje softvera je dokument sa
sljedećim dijelovima:
– opis procesa testiranja,
– popis zahtjeva koji će se testirati,
– popis dijelova softvera koji će se testirati,
– kalendar testiranja,
– opis načina bilježenja rezultata testiranja,
– popis hardvera i softvera koji je potreban za testiranje,
– ograničenja koja utječu na proces testiranja.
SI-4 SOFTVERSKO INŽENJERSTVO 9
Odnos V&V i debagiranja (1)
• Tijekom V&V otkrivaju se pogreške. Softver se
mijenja da bi se pogreške popravile.
• Taj proces debagiranja često je integriran s
aktivnostima V&V.
• Ipak, V&V i debagiranje su različiti procesi.
Naime:
– V&V je proces koji utvrđuje postojanje pogrešaka u
softveru.
– Debagiranje je proces koji locira (otkriva uzrok) i
popravlja te pogreške.
SI-4 SOFTVERSKO INŽENJERSTVO 10
Odnos V&V i debagiranja (2)
• Proces debagiranja vidljiv je na slici.– Programeri koji provode debagiranje pouzdaju se u
svoje iskustvo, poznavanje čestih pogrešaka i
poznavanje svojstava korištenog programskog jezika.
– Pritom mogu biti od pomoći interaktivni debuggeri
kakvi postoje u lower-CASE alatima.
SI-4 SOFTVERSKO INŽENJERSTVO 11
Rezultati
testiranja
Specifikacija
(zahtjevi) Test primjeri
Lociraj
grešku
Oblikuj
popravak
greške
Popravi
grešku
Ponovo testiraj
program
Sadržaj Poglavlja 4
4.1. Općenito o verifikaciji i validaciji
4.2. Statička verifikacija
4.3. Testiranje softvera
SI-4 SOFTVERSKO INŽENJERSTVO 12
Statička verifikacija
• Statička V&V može se obavljati u raznim fazama
softverskog procesa.
• Ipak, ograničit ćemo se na njen najčešći oblik, a
to je statička verifikacija programa.
– Ona se svodi na analizu i pregled programskog koda,
bez stvarnog izvođenja programa.
– Primjenjuje se prije testiranja programa, da bi se otkrila
glavnina pogrešaka.
– Nakon toga testiranje ide znatno brže, a ukupni
troškovi verifikacije su znatno manji.
• Obradit ćemo tri tehnike koje spadaju u statičku
verifikaciju.SI-4 SOFTVERSKO INŽENJERSTVO 13
Inspekcija programa (1)
• Prakticirala se u velikim tvrtkama poput IBM i HP
tijekom 70-tih, 80-tih i 90-tih godina 20. stoljeća.
• Riječ je o reguliranom procesu u kojem sudjeluje
grupa ljudi sa strogo zadanim ulogama:
– autor ili vlasnik: programer odgovoran za program i za
naknadni popravak pogrešaka;
– inspektor: pronalazi pogreške, propuste i
nekonzistentnosti u programu;
– čitač: glasno čita programski kod na sastanku;
– zapisničar: bilježi rezultate sastanka;
– moderator: planira i organizira sastanke, upravlja
procesom.SI-4 SOFTVERSKO INŽENJERSTVO 14
Inspekcija programa (2)
• Proces inspekcije odvija se u skladu sa slikom.
– Najvažnija faza je sastanak na kojem inspekcijska
grupa pregledava program i otkriva pogreške.
– Na sastanku se ne raspravlja o tome kako će se
pogreške popraviti, već je to naknadni posao autora.
– Moderator u fazi nastavka odlučuje da li je potrebno
ponoviti cijeli proces.
SI-4 SOFTVERSKO INŽENJERSTVO 15
PlaniranjeDistribucija materijala
Individualna priprema
Sastanak inspekcije
Popravak programa Nastavak
Inspekcija programa (3)
• Da bi sastanak inspekcije uspio, važno je da:
– postoji precizna specifikacija (odgovarajućeg
dijela) programa;
– postoji ažurna i dovršena verzija programskog
koda;
– postoji kontrolna lista čestih programerskih
pogrešaka;
– članovi grupe su upoznati s organizacijskim
standardima i žele surađivati.
• Slijedi primjer moguće liste čestih
programerskih pogrešaka.
SI-4 SOFTVERSKO INŽENJERSTVO 16
Inspe-
kcija
progra
ma (4)
SI-4 SOFTVERSKO INŽENJERSTVO 17
Vrsta pogreške Inspekcijska provjera
Pogreške s
podacima
Postoje li varijable koje nisu deklarirane?
Postoje li varijable koje su deklarirane no nisu nigdje korištene?
Jesu li sve varijable u programu bile inicijalizirane prije korištenja?
Postoji li varijabla koja između dvaju pridruživanja vrijednosti nije bila
korištena?
Imaju li sve konstante svoja imena?
Jesu li indeksi elemenata polja uvijek unutar predviđenih granica?
Postoji li u svakom nizu znakova (stringu) znak za kraj niza?
Pogreške
vezane uz tok
kontrole
Za svaku uvjetnu naredbu, je li uvjet ispravan?
Za svaku petlju, je li sigurno da će ona završiti?
Jesu li složene naredbe ispravno zatvorene u zagrade?
U case naredbama, jesu li obuhvaćeni svi mogući slučajevi?
Jesu li u case naredbama navedene sve potrebne break naredbe?
Postoji li nedostupan programski kod?
Postoje li goto naredbe koje prebacuju kontrolu u unutrašnjost petlje?
Pogreške s
ulazom i
izlazom
Koristi li se svaki od ulaznih podataka?
Je li svakom izlaznom podatku pridružena vrijednost prije njegovog ispisa?
Postoje li izlazne varijable koje se dvaput ispisuju makar između tih ispisa nije
došlo do promjene njihove vrijednosti?
Mogu li neočekivani ulazi proizvesti „korupciju“ programa?
Pogreške sa
sučeljima
Imaju li svi pozivi funkcija ispravan broj parametara?
Jesu li tipovi formalnih i stvarnih parametara u pozivima funkcija međusobno
usklađeni?
Jesu li parametri u pozivima funkcija u ispravnom poretku?
Postoje li funkcije koje vraćaju vrijednosti, no te vrijednosti se ne koriste?
Postoje li funkcije koje se nigdje ne pozivaju?
Pogreške
vezane uz
upravljanje
memorijom
Postoje li ne-inicijalizirani pokazivači?
Jesu li kod promjene vezane strukture svi pokazivači ispravno preusmjereni?
Je li dinamička memorija alocirana na ispravan način?
Je li alocirana memorija ispravno de-alocirana onda kad se više ne koristi?
Pogreške u
upravljanju
iznimkama
Jesu li sve moguće iznimke uzete u obzir?
Inspekcija programa (5)
• Inspekcija programa danas djeluje zastarjelo.
– Ipak, ona se zasniva na neospornoj činjenici da
programeri teško uočavaju pogreške u svojem
vlastitom programskom kodu, no znatno bolje u
tuđem kodu.
• Ideja inspekcije programa ponovno je došla
do izražaja u agilnoj metodi XP.
– Programiranje u paru unutar XP može se shvatiti
kao vrsta uzajamne inspekcije.
– Dva programera jedan drugome pregledavaju
programski kod i otkrivaju pogreške.
SI-4 SOFTVERSKO INŽENJERSTVO 18
Automatska statička analiza (1)
• Obavlja se pokretanjem softverskih alata koji
prolaze kroz izvorni tekst programa i otkrivaju
moguće pogreške i anomalije u tom tekstu.
– Otkrivaju se „sumnjiva mjesta“ u programu koja bi
mogla sadržavati pogreške.
– Ispisuju se poruke.
– Sam popis sumnjivih situacija koje upućuju na
pogrešku ovisi o programskom jeziku.
– Popis nalikuje na prethodnu listu čestih
programerskih pogrešaka.
SI-4 SOFTVERSKO INŽENJERSTVO 19
Automatska statička analiza (2)
• Analiziranje
C programa
pomoću
UNIX alata
za statičku
analizu lint.
SI-4 SOFTVERSKO INŽENJERSTVO 20
> more lint_ex.c
#include
printarray (Anarray) {
int Anarray;
printf (“%d”, Anarray);
}
main ( ) {
int Anarray[5]; int i; char c;
printarray (Anarray, i, c);
printarray (Anarray);
}
> cc lint_ex.c
> lint lint_ex.c
lint_ex.c(8): warning: c may be used before set
lint_ex_c(8): warning: i may be used before set
printarray: variable # of args. lint_ex.c(2) :: lint_ex.c(8)
printarray: arg. 1 used inconsistently. lint_ex.c(2) :: lint_ex.c(8)
printarray: arg. 1 used inconsistently. lint_ex.c(2) :: lint_ex.c(9)
printf returns value which is always ignored
Automatska statička analiza (3)
• Za jezike poput C statička analiza predstavlja
efikasnu tehniku za otkrivanje programerskih
pogrešaka.
• No u „strožim“ jezicima poput Jave samim
pravilima jezika izbjegnute su neke konstrukcije
koje lako dovode do pogreške. Na primjer:
– sve varijable moraju biti inicijalizirane,
– nema goto naredbi (pa je teže stvoriti nedostupni kod),
– upravljanje memorijom je automatsko (nema pointera).
• Zato je statička analiza u slučaju Java programa
manje isplativa nego u slučaju C programa.
SI-4 SOFTVERSKO INŽENJERSTVO 21
Formalna verifikacija (1)
• Svodi se na matematičko dokazivanje da je
program konzistentan sa svojom specifikacijom.
• Moguća je pod sljedećim uvjetima:
– semantika programskog jezika je formalno definirana,
– postoji formalna specifikacija za program.
• Dokaz se provodi ovako:
– polazni uvjeti iz specifikacije i same naredbe iz
programa uzmu se kao činjenice,
– Iz tih činjenica izvode se konačni uvjeti koji po
specifikaciji moraju biti zadovoljeni nakon izvršenja
programa.
SI-4 SOFTVERSKO INŽENJERSTVO 22
Formalna verifikacija (2)
• Idejom formalne verifikacije bavila su se mnoga
velika imena računarstva tijekom 70-tih godina
20. stoljeća (Hoare, Dijkstra, Wirth).
– Ipak, u to vrijeme nije se došlo dalje od malih
akademskih primjera.
• Ideja se i dalje njeguje u krugovima pobornika
formalnih metoda za razvoj softvera.
– Predmet je intenzivnog istraživanja,
– Polako postiže sve bolje rezultate.
• U posljednje vrijeme pažnju istraživača privlači
varijanta formalne verifikacije koja se zove
provjera modela (model checking).SI-4 SOFTVERSKO INŽENJERSTVO 23
Formalna verifikacija (3)
• Kod model checking-a, softver koji želimo
verificirati prikazuje se matematičkim modelom,
npr. konačnim automatom ili logičkim izrazom.
• Zatim se dokazuje da taj model ima neko
poželjno svojstvo.
– Dokazivanje se svodi na sistematsku provjeru svih
mogućnosti,
• npr. prolazak svih putova kroz konačni automat, ili
• generiranje svih kombinacija vrijednosti u logičkom izrazu.
– Provjeru obavlja posebni alat, model checker.
– Rezultat provjere je potvrda da svojstvo vrijedi ili
protuprimjer koji pokazuje da svojstvo ne vrijedi.
SI-4 SOFTVERSKO INŽENJERSTVO 24
Formalna verifikacija (4)
• Postupak provjere modela (model checking).
SI-4 SOFTVERSKO INŽENJERSTVO 25
Dizajn ili program
Poželjna svojstva sustava
Model sustavaGradnja modela
Specifikacija svojstava
Model checker
Potvrda ili kontra-primjeri
• Metodama model checking-a postiže samo
parcijalna verifikacija softvera: - provjeravaju se samo neka svojstva iz specifikacije,
- zanemaruju se ostala svojstva.
Formalna verifikacija (5)
• Primjer model checking-a: za svjetionik iz
Odjeljka 3.3.3 želimo dokazati da on prije ili
kasnije ulazi u stanje slanja podataka.
– Kao model može nam poslužiti UML state machine
dijagram.
– Provjera svojstva svodi se na generiranje svih
mogućih putova (svih mogućih nizova prijelaza) kroz
dijagram.
– Ako svaki od tih putova sadrži stanje „Šalje podatke“,
svojstvo je dokazano.
– Inače smo našli protuprimjer, dakle mogući niz
prijelaza za koji svojstvo ne vrijedi. SI-4 SOFTVERSKO INŽENJERSTVO 26
Formalna verifikacija (6)
• Pobornici formalne verifikacije tvrde da ona
vodi do pouzdanijeg i sigurnijeg softvera.
• Tvrdnja je velikom dijelom točna, no ne u
potpunosti. Naime:
– Specifikacija (čak i formalna) ne mora odražavati
stvarne zahtjeve korisnika.
– Dokaz korektnosti programa je velik i složen, pa
može sadržavati i pogreške.
– Korisnici će možda koristiti softver na način koji se
razlikuje od onoga koji se pretpostavljao u dokazu
korektnosti.
SI-4 SOFTVERSKO INŽENJERSTVO 27
Sadržaj Poglavlja 4
4.1. Općenito o verifikaciji i validaciji
4.2. Statička verifikacija
4.3. Testiranje softvera
SI-4 SOFTVERSKO INŽENJERSTVO 28
Testiranje softvera
• Testiranje je pokusno izvođenje softvera ili
njegovih dijelova na umjetno pripravljenim
podacima, uz pažljivo analiziranje rezultata.
• Svrha testiranja može biti verifikacija ili validacija.
• U ovom potpoglavlju ograničavamo se na
testiranje u svrhu verifikacije, dakle na testiranje
kojim se provjerava radi li softver prema svojoj
specifikaciji.
• Objašnjavamo najvažnije vrste testiranja te se
bavimo danas aktualnom idejom razvoja softvera
vođenog testiranjem.
SI-4 SOFTVERSKO INŽENJERSTVO 29
Vrste i faze
testiranja (1)
• Klasifikacija
raznih vrsta
testiranja:
SI-4 SOFT. INŽ 30
Testiranje
Razvojno testiranje (development testing)
Testiranje izdanja (release testing)
Korisničko testiranje (user testing)
Statističko testiranje
Testiranje u svrhu otkrivanja grešaka
Testiranje dijelova
Testiranje integracije
Funkcionalno testiranje
Strukturalno testiranje
Testiranje po putovima
Testiranje zahtjeva
Testiranje scenarija
Testiranje performansi
Alfa testiranje
Beta testiranje
Primopredajno testiranje
Vrste i faze testiranja (2)
• Prva razina podjele na slici napravljena je po
kriteriju tko odnosno kada sudjeluje u
testiranju.
– Razvojno testiranje provodi razvojni tim tijekom
razvoja softvera.
– Testiranje izdanja obavlja posebni tim za testiranje
unutar softverske kuće uoči isporuke novog izdanja
softvera.
– Korisničkim testiranjem bave se sami korisnici
tijekom isporuke softvera.
• Svaka vrsta s prve razine dalje se dijeli na
podvrste.
SI-4 SOFTVERSKO INŽENJERSTVO 31
Vrste i faze testiranja (3)
• Razvojno testiranje uključuje sljedeće podvrste.
– Testiranje u svrhu otkrivanja pogrešaka. Služi za
provjeru funkcionalnih zahtjeva.
• Namjera je otkriti odstupanja između softvera i specifikacije.
• Ta odstupanja posljedica su pogrešaka u softveru.
• Test-podaci su konstruirani tako da otkriju prisutnost
pogreške, a ne tako da simuliraju normalnu upotrebu softvera.
– Statističko testiranje. Služi za provjeru nekih oblika ne-
funkcionalnih zahtjeva.
• Namjera je npr. izmjeriti performanse ili stupanj pouzdanosti.
• Test-podaci su odabrani tako da liče na stvarne korisničke
podatke, te da odražavaju stvarnu statističku razdiobu.
• Riječ je o velikom broju slučajno odabranih test primjera, što
omogućuje statističku procjenu performansi ili pouzdanosti.
SI-4 SOFTVERSKO INŽENJERSTVO 32
Vrste i faze testiranja (4)
• Dalje se ograničavamo se na testiranje u svrhu
otkrivanja pogrešaka.
– Takvo testiranje smatra se uspješnim onda kad ono
pokaže da softver ne radi dobro.
– Nakon testiranja pogrešaka slijedi debagiranje.
– Testiranje može pokazati da u softveru postoje
pogreške, no ne može dokazati da pogrešaka nema.
• Proces testiranja u svrhu otkrivanja pogrešaka:
SI-4 SOFTVERSKO INŽENJERSTVO 33
Testiranje jedinki
(funkcija, klasa)
Testiranje
modula
Testiranje
pod-sustava
Testiranje
sustava
Testiranje
dijelovaTestiranje integracije
Vrste i faze testiranja (5)
• Proces testiranja u svrhu otkrivanja pogrešaka -
sažeti prikaz:
SI-4 SOFTVERSKO INŽENJERSTVO 34
Testiranje
dijelovaTestiranje
integracije
- Najprije testiramo sastavne dijelove softvera.
Testiranje dijelova obično provode osobe koje su
razvile te dijelove.
- Nakon toga testiramo jesu li dijelovi na ispravan način
integrirani u veće cjeline. Testiranje integracije može
biti posao nezavisnog tima.
Testiranje dijelova – black-box (1)
• Promatramo nekoliko pristupa koji se razlikuju po
načinu odabira test podataka.
• Funkcionalno testiranje (black-box testing).
– Test-primjeri izvode se isključivo iz specifikacije
dotičnog dijela softvera.
– Softver se promatra kao „crna kutija“ koja bi (prema
specifikaciji) za zadane ulaze trebala proizvesti
zadane izlaze.
– Zbog postojanja pogrešaka, ulazi iz (nepoznatog)
skupa Ie izazvat će neispravno ponašanje, koje ćemo
prepoznati po izlazima iz skupa Oe.
SI-4 SOFTVERSKO INŽENJERSTVO 35
Testiranje dijelova – black box (2)
• Funkc.testiranje (nastavak).– Nastojimo izabrati ulaze za
koje je velika vjerojatnost da
pripadaju skupu Ie.
– Skup svih mogućih ulaznih
podataka (domenu) dijelimo na
klase.
– Očekujemo da će se softver
ponašati slično za sve podatke
iz iste klase.
– Biramo barem po jedan test-
primjer iz svake klase.
– Također je dobro isprobati
„rubove“ klasa.SI-4 SOFTVERSKO INŽENJERSTVO 36
Testirani dio
softvera
OeIzlazni
rezultati
IeUlazni
podaci
Testiranje dijelova – black box (3)
• Primjer: promatramo proceduru za traženje
elementa Key u polju T koja mora zadovoljavati
sljedeću specifikaciju.
SI-4 SOFTVERSKO INŽENJERSTVO 37
procedure Search (Key: ELEM; T: SEQ of ELEM;
Found: in out BOOLEAN; L: in out ELEM_INDEX);
pre-condition
-- polje sadrži barem jedan element
T'FIRST
Testiranje dijelova – black-box (4)
• Iz same specifikacije, jasno je da domenu
možemo podijeliti na dvije klase:
– ulazi gdje je Key zaista element polja T (Found = true);
– ulazi gdje Key nije element polja T (Found = false).
• Iskustva u radu s poljima kažu da treba probati:
– polje T s ekstremnom duljinom, tj. s jednim elementom;
– element Key na rubovima odnosno na sredini polja T.
• Kad kombiniramo ova dva načina podjele
domene na klase, dobivamo particiju od 6 klasa.
• Shodno tome, biramo 6 test-primjera.
SI-4 SOFTVERSKO INŽENJERSTVO 38
Testiranje dijelova - black-box (5)
• Particija
domene:
SI-4 SOFTVERSKO INŽENJERSTVO 39
• Test
primjeri:
Polje Traži se
jedna vrijednost element iz polja
jedna vrijednost element koji nije u polju
više od jedne vrijednosti prvi element u polju
više od jedne vrijednosti zadnji element u polju
više od jedne vrijednosti srednji element u polju
više od jedne vrijednosti element koji nije u polju
Ulazno polje (T) Tražena vrijednost (Key) Izlaz (Found, L)
17 17 true, 0
17 0 false, ??
17, 29, 21, 23 17 true, 0
41, 18, 9, 31, 30, 16, 45 45 true, 6
17, 18, 21, 23, 29, 41, 38 23 true, 3
21, 23, 29, 33, 38 25 false, ??
Testiranje dijelova – white-box (1)
• Strukturalno testiranje (white-box testing).
– Dodatni test-primjeri izvode se na osnovi poznavanja
interne strukture dijela softvera i korištenih algoritama.
– Dakle služimo se analizom programskog koda
dotičnog dijela softvera da bi odabrali dodatne test
primjere, to jest da bi bolje podijelili domenu na klase.
• Kao primjer, gledamo konkretnu implementaciju
procedure za traženje elementa u polju.
– Implementacija je u Javi.
– Koristi se algoritam binarnog traženja.
– Podrazumijeva malo stroža specifikacija, naime polje
mora biti uzlazno sortirano.
SI-4 SOFTVERSKO INŽENJERSTVO 40
Testi-
ranje
dijelova –
white-
box (2)
• Implem-
entacija
binarnog
traženja
u Javi.
SI-4 SOFTVERSKO INŽENJERSTVO 41
Class BinSearch{
// Funkcija uzima kao parametre sortirano polje cijelih brojeva elemArray i
// cjelobrojnu vrijednost key. Funkcija vraća objekt s dva atributa:
// index - indeks elementa u polju elemArray gdje se pojavljuje vrijednost key,
// found – booleovska vrijednost koja kaže je li key pronađen u polju ili nije.
// Ako key nije pronađen, tada se indeks u odgovoru postavlja na -1.
Public static void search (int key, int[] elemArray, Result r) {
1. int bottom = 0:
2. int top = elemArray.length – 1;
int mid
3. r.found = false;
4. r.index = -1;
5. while (bottom
Testiranje dijelova – white-box (3)
• Promatranjem programskog koda uočavamo da
svaki korak algoritma dijeli polje na tri dijela.
– Zato osim izbora Key na rubovima te na sredini polja T
uvodimo i dva nova izbora: neposredno ispred i iza
srednjeg elementa u polju.
SI-4 SOFTVERSKO INŽENJERSTVO 42
Elementi < srednjeg Elementi > srednjeg
Granice klasa ekvivalencije
Element na sredini
Testiranje dijelova – white-box (4)
– Nakon revizije starih test primjera (polje mora biti
sortirano), te dodavanja dvaju novih primjera,
dobivamo ukupno 8 test primjera.
SI-4 SOFTVERSKO INŽENJERSTVO 43
Ulazno polje (T) Tražena vrijednost (Key) Izlaz (Found, L)
17 17 true, 0
17 0 false, ??
17, 21, 23, 29 17 true, 0
9, 16, 18, 30, 31, 41, 45 45 true, 6
17, 18, 21, 23, 29, 38, 41 23 true, 3
17, 18, 21, 23, 29, 33, 38 21 true, 2
12, 18, 21, 23, 32 23 true, 3
21, 23, 29, 33, 38 25 false, ??
Testiranje dijelova – path testing (1)
• Testiranje po putovima (path testing).– Vrsta white box. Test primjeri biraju se tako da se proba
svaki „nezavisni put“ kroz dijagram toka kontrole.
– Crtanje dijagrama: • Naredbe while i if - then - else prikažu se obrascima sa slike,
• Ostale naredbe prikažu se svaka po jednim čvorom.
– Nezavisni put je onaj koji ide od „početka“ do „kraja“ i
prolazi bar jednim novim lukom.
SI-4 SOFTVERSKO INŽENJERSTVO 44
Uvjet
Tijelo
Nastavak
Uvjet
False-grana
Nastavak
True-grana
ne
da neda
while if-then-else
bottom > top
1
2
3
4
5
6
7
8
9
1014
11
12 13
while bottom key
Testiranje
dijelova –
path testing
(2)
SI-4 SOFTVERSKO INŽENJERSTVO 45
• Dijagram toka
kontrole za
prethodnu proceduru
binarnog traženja.
Testiranje dijelova – path testing (3)
• Dijagram toka kontrole (nastavak).
– Brojevi čvorova na dijagramu odgovaraju brojevima
redaka u Java kodu.
– Početak toka kontrole je čvor 1 a kraj je čvor 14.
– Postoje 4 nezavisna puta, i to:
• 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
• 1, 2, 3, 4, 5, 14
• 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, 6, 7, 8, 9, 10, 14
• 1, 2, 3, 4, 5, 6, 7, 11, 13, 5, 6, 7, 8, 9, 10, 14.
– Ako se u test primjerima prođe svaki od ovih putova,
tada smo sigurni da je:
• svaka naredba bila izvršena bar jednom,
• svako grananje bilo isprobano za slučaj istine i za slučaj laži.
SI-4 SOFTVERSKO INŽENJERSTVO 46
Testiranje dijelova – path testing (4)
• Maksimalni broj nezavisnih putova u dijagramu
jednak je ciklomatskoj složenosti dijagrama:
(broj lukova) – (broj čvorova) + 2.
• Ciklomatska složenost za program bez goto
naredbi jednaka je:
(broj uvjeta u if, while i sličnim naredbama) + 1.
• Kod testiranja kompliciranijih rutina koriste se
dinamički analizatori programa.
SI-4 SOFTVERSKO INŽENJERSTVO 47
Testiranje integracije (1)
• Provodi se nakon što se manji dijelovi softvera
udruže u veću cjelinu.
• Cilj testiranja je otkriti pogreške koje nastaju zato
što dijelovi na pogrešan način koriste
međusobna sučelja.
SI-4 SOFTVERSKO INŽENJERSTVO 48
• Važno za OO
sustave.
• Test primjeri
se primjenjuju
na cjelinu, a
ne na dijelove.
Test primjeri
A B
C
Testiranje integracije (2)
• Tipovi sučelja između udruženih dijelova.
– Proceduralno sučelje. Jedan dio softvera poziva
proceduru koja pripada drugom dijelu softvera.
– Parametarsko sučelje. Podatak ili referenca na njega
prenosi se kao parametar u pozivu procedure iz
jednog dijela softvera u drugi.
– Slanje poruka. Jedan dio softvera zahtijeva uslugu od
drugog dijela tako što mu pošalje poruku. Povratna
poruka uključuje rezultat izvršene usluge.
– Zajednička memorija. Blok memorije dostupan je
raznim dijelovima softvera. Jedan dio sprema podatke
u blok, a drugi ih čita iz bloka.
SI-4 SOFTVERSKO INŽENJERSTVO 49
Testiranje integracije (3)
• Vrste pogrešaka u korištenju sučelja:– Nerazumijevanje sučelja. Na primjer kod proceduralnog
sučelja, dio koji poziva rutinu za binarno traženje ne
zna da polje mora biti sortirano.
– Pogrešna upotreba sučelja. Na primjer, krivi tip podatka
u parametarskom sučelju.
– Pogreške u sinkronizaciji. Na primjer, kod slanja poruka
ili kod zajedničke memorije. Dijelovi koji proizvode
odnosno troše podatke rade na različitim brzinama.
• Testiranje integracije je teško jer: – pogreške se mogu pojaviti samo u iznimnim situacijama
(kod velikog opterećenja sustava),
– ili na neočekivanim mjestima (u drugom dijelu softvera). SI-4 SOFTVERSKO INŽENJERSTVO 50
Testiranje integracije (4)
• Naputci za testiranje integracije.
– Pregledaj programski kod svakog dijela softvera i popiši
sve interakcije jednog dijela s drugim dijelovima.
– U slučaju proceduralnog sučelja probaj situaciju kad
procedura vraća status pogreške.
– U slučaju parametarskog sučelja oblikuj testove koji
koriste ekstremne vrijednosti parametara.
– Ako se prenašaju pokazivači (pointeri), isprobaj
primjere s nul-pokazivačima.
– Ako se razmjenjuju poruke, probaj stvoriti znatno više
poruka nego što se očekuje u normalnim okolnostima.
– Ako se koristi zajednička memorija, variraj redoslijed
aktiviranja dijelova softvera koji pristupaju toj memoriji.SI-4 SOFTVERSKO INŽENJERSTVO 51
Testiranje integracije (5)
• Zbog više razina integracije (osnovne jedinke,
moduli, podsustavi, sustav) testiranje integracije
mora se ponoviti više puta.
• Pritom redoslijed testiranja može biti– S vrha prema dolje (top-down).
• Najprije se testira integracija na najvišoj razini, zatim na nižoj
razini, … , na kraju na najnižoj razini.
• Pritom se nepostojeći ili netestirani dijelovi s niže razine
zamjenjuju nadomjescima - stub-ovima.
– S dna prema gore (bottom-up). • najprije se testira integracija na najnižoj razini, zatim na idućoj
višoj razini, …, na kraju na najvišoj razini.
• Nisu potrebni stub-ovi, no potrebni su test driver-i koji pozivaju
manje dijelove softvera i simuliraju njihovu okolinu.
SI-4 SOFTVERSKO INŽENJERSTVO 52
Testiranje integracije (6)
• Testiranje top-down.– Prednost je da ono ranije otkriva pogreške u arhitekturi.
– Psihološka prednost je da se relativno rano dobiva
sustav koji donekle radi i može se pokazivati.
– Mana je da se troši vrijeme na izradu stub-ova.
SI-4 SOFTVERSKO INŽENJERSTVO 53
Umetci za razinu 2
Razina 1 ...
Razina 2 Razina 2 Razina 2
Razina 1
Razina 2
Umetci za razinu 3
Redoslijed
testiranja
Testiranje integracije (7)
SI-4 SOFTVERSKO INŽENJERSTVO 54
• Testiranje bottom-up.- Prednost je da se lakše uključuju gotove komponente.
- Također, prednost je da arhitektura ne mora biti
dovršena sve do zadnjeg časa.
- Mana je da se troši vrijeme na izradu test driver-a.
Razina N Razina N Razina N Razina N
Razina N-1
Razina N
Test driver-i
Redoslijed
testiranja
Razina N-1 Razina N-1
Test driver-i
Razvoj softvera vođen testiranjem (1)
• Neki autori smatraju da je testiranje toliko važno
da ono može voditi cijeli proces razvoja softvera.
• Ti autori formulirali su ideju razvoja vođenog
testiranjem (test-driven development). Svojstva:– Testiranje se isprepliće s razvojem programskog koda.
– Kod se razvija na inkrementalan način zajedno s
testovima za taj inkrement.
– Nema pomaka na idući inkrement sve dok trenutna
verzija koda ne prođe test.
• Ovakav pristup:– Predstavlja sastavni je dio agilnih metoda poput XP i
tamo se zove test-first development.
– Može se uklopiti i u klasične metode. SI-4 SOFTVERSKO INŽENJERSTVO 55
Razvoj softvera vođen testiranjem (2)
• Koraci u razvoju softvera vođenog testiranjem:
SI-4 SOFTVERSKO INŽENJERSTVO 56
Identificiraj novu
funkcionalnost
Implementiraj funkcionalnost uz refactoring
Napiši test Izvrši test
prošao
nije prošao
• Da bi ovakav razvoj bio izvediv, neophodan je
odgovarajući CASE-alat za automatsko
testiranje – npr. JUnit.
Razvoj softvera vođen testiranjem (3)
• Razvoj vođen testiranjem ima sljedeće prednosti.– Bolje razumijevanje koda. Pisanjem testa programer
artikulira ideju o tome što bi idući segment trebao raditi.
– Bolja pokrivenost koda testovima. Osigurano je da za
svaki komad koda postoji odgovarajući test. Sigurni
smo da će se svi dijelovi koda izvršiti prilikom testiranja.
– Mogućnost regresijskog testiranja. Nakon svake
promjene moguće je odmah izvesti sve stare testove i
provjeriti da promjena nije narušila staru funkcionalnost.
– Jednostavnije debagiranje. Kad test ne prođe, očito je
da se uzrok nalazi u novom dijelu koda.
– Dokumentiranje sustava. Sami testovi služe kao vrsta
dokumentacije koja opisuje što bi programski kod
trebao raditi.SI-4 SOFTVERSKO INŽENJERSTVO 57
Razvoj softvera vođen testiranjem (4)
• Razvoj vođen testiranjem ima sljedeće mane.
– Nepogodan je ako upotrebljavamo velike dijelove
tuđeg ili baštinjenog koda, pa moramo pisati testove
za te velike dijelove.
– Nije efikasan kod sustava s više dretvi (niti). Naime,
dretve se mogu drukčije ispreplesti pri različitim
pokretanjima testa, što može stvoriti različite rezultate.
– Nije primjenjiv za testiranje integracije ili testiranje
performansi ili pouzdanosti cijelog sustava.
• Slično kao i agilne metode, razvoj vođen
testiranjem za sada se pokazao uspješnim kod
malih ili srednje velikih projekata.
SI-4 SOFTVERSKO INŽENJERSTVO 58