poglavlje 4: verifikacija i validacijaweb.studenti.math.pmf.unizg.hr/~manger/si/si-4.pdf · 2020....

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


Općenito o verifikaciji i validaciji


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


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.


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.


StatičkaV&V

Testiranje

Specifikacija

zahtjeva

Dizajn na

visokoj razini

Formalna specifikacija

Detaljni

dizajnProgram

Prototip


• 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


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


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


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.


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.


Rezultati

testiranja

Specifikacija

(zahtjevi) Test primjeri

Lociraj

grešku

Oblikuj

popravak

greške

Popravi

grešku

Ponovo testiraj

program

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


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


PlaniranjeDistribucija materijala

Individualna priprema

Sastanak inspekcije

Popravak programa Nastavak


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


Inspe-

kcija

progra

ma (4)


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


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.



• Analiziranje

C programa

pomoću

UNIX alata

za statičku

analizu lint.


> 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


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


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.



• 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


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



• Postupak provjere modela (model checking).


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.


• 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


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


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.


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.



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



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


Testiranje jedinki

(funkcija, klasa)

Testiranje

modula

Testiranje

pod-sustava

Testiranje

sustava

Testiranje

dijelovaTestiranje integracije


• Proces testiranja u svrhu otkrivanja pogrešaka -

sažeti prikaz:


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.


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.


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.


Testiranje dijelova - black-box (5)

• Particija

domene:


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


Testi-

ranje

dijelova –

white-

box (2)

• Implem-

entacija

binarnog

traženja

u Javi.


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


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


Elementi < srednjeg Elementi > srednjeg

Granice klasa ekvivalencije

Element na sredini


– Nakon revizije starih test primjera (polje mora biti

sortirano), te dodavanja dvaju novih primjera,

dobivamo ukupno 8 test primjera.


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.


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)


• Dijagram toka

kontrole za

prethodnu proceduru

binarnog traženja.


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



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


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.


• Važno za OO

sustave.

• Test primjeri

se primjenjuju

na cjelinu, a

ne na dijelove.

Test primjeri

A B

C


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



• 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


• 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


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



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


Umetci za razinu 2

Razina 1 ...

Razina 2 Razina 2 Razina 2

Razina 1

Razina 2

Umetci za razinu 3

Redoslijed

testiranja



• 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


• Koraci u razvoju softvera vođenog testiranjem:


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


poglavlje 4: verifikacija i validacijaweb.studenti.math.pmf.unizg.hr/~manger/si/si-4.pdf · 2020....

Documents