Modeliranje i sumulacija procesa testiranja programskih proizvoda
Zdenko Marinčić, Nenad Hećimović, Lovre Hribar
R&D
Ericsson Nikola Tesla
Krapinska 45, Zagreb, Hrvatska
Telefon: +385 1 3654372, E-mail: Zdenko.Marincic@ericsson.com
Sažetak – U ovom radu opisat će se modeliranje i
simulaciju procesa testiranja provedena u studijskom
slučaju u telekomunikacijskoj kompaniji.
I. UVOD
Programski proces testiranja predstavlja glavno
područje za poboljšanje kvalitete programskog
proizvoda jer su mu inherentni mehanizmi za
ispravljanje neispravnosti i provjeru funkcionalnosti
programskog proizvoda. Dinamička priroda okoline
u kojoj se razvija neki programski proizvod
zahtijeva mjerenja i stalna poboljšanja programskih
procesa. Simulacija omogućava njihovu efikasnu
analizu i rezultira performansama procesa na
temelju kojih se mogu predložiti optimalna
poboljšanja.
Ljudi razvijaju programske proizvode i u tome
često dolazi do određenih neispravnosti. U svakom
standardnom komercijalnom softveru postoje
greške. Greške su skupe, neke više od drugih.
Tester ne može spriječiti njihovu pojavu, ali ih
može locirati i ispraviti u ranoj fazi, osobito one
kritične. On mora razumjeti i imati znanja
implementirati pripadajuće tehnike testiranja.
Ispitivanje svih ulaznih elementata koji bi mogli
rezultirati greškom u softveru je nemoguće.
Potrebno je odabratati reprezentativne ulazne
elemente i pomoću njih izvoditi testiranje. Njome
se mogu otkriti neispravnosti u kodu, ali ne i
njihovo nepostojanje. Cilj testiranja je pronaći
neispravnost programskog koda i otkloniti ih.
Brzi razvoj računalne tehnologije doveo do sve
većeg broja programskih produkata na tržište. Ono
postaje jako konkurentno i proizvođači se natječu
tko će prije izbaciti novi proizvod koji će biti
kvalitetan i odgovarati zahtjevima korisnika. Da bi
imao te karakteristike on mora biti kvalitetno
testiran. Danas je nezamislivo razviti neki
programski proizvod i ne testirati ga. Ne postoji
savršeni razvojni proces i vjerojatnost je vrlo velika
da greške postoje.
U zadnjih par godina mnogo je istraživanja
posvećeno testiranju. Razvile su se metode,
programska pomagala i tehnike. Proces testiranja
narastao je iz nečeg što je proizlazilo iz osnovnih
akcija ocjenjivanja izrađenog programskog
proizvoda u važan dio cijelog ciklusa razvoja
programskog proizvoda. S vremenom se razvija i
poboljšava, a time i raste važnost programskih
procesa kao grane programskog inženjerstva. Cilj
inženjerstva programskih procesa je poboljšanje
programskih procesa, čime se posredno poboljšava
kvaliteta programskih proizvoda i smanjuju
troškovi proizvodnje.
II. OPĆENITO O TESTIRANJU SOFTVERSKIH
APLIKACIJA
IEEE/ANSI definicija [1]:
« Testiranje softverske aplikacije ili programa je
proces u kojem se pod strogo definiranim uvjetima
analizira izvedba (rad) jedne rutine i/ili cijele
aplikacije. Cilj testiranja je uočiti i ispraviti greške
koje uzrokuju da krajnji rezultat nije prema
zahtjevima programa ili aplikacije te u skladu s
propisanim naredbama (instrukcijama).»
A. Osnovni pojmovi
 Tester – osoba koja testira softverski
program ili aplikaciju
 Test uzorak (test case) – ulazne domene
koji omogućuje jedno samostalno
izvođenje testne jedinice
 Skup test uzoraka (test suite) – programi ili
rutine povezani u jednu logičnu cjelinu
 Otklanjanje (debugging) pogrešnog kôda -
analiza kôda radi lokaliziranja i otklanjanja
neispravnosti.
 Neočekivani prestanak rada programa
(failure) – izvođenje programa ne odvija
se prema propisanim zahtjevima
 Pogreška u softverskom programu (fault,
bug) – programski kôd koji uzrokuje
odstupanje od predviđenog rada programa
 Test specifikacija – dokument koji
propisuje što i kako testirati
 Test jedinica (test unit) – programska
cjelina koja se testira
 Funkcionalni test (function test) –
testiranje koje se izvodi na temelju
funkcionalnosti softverskog programa
  Sustavno testiranje (system test) –
testiranje koje obuhvaća cjelokupnu
aplikaciju i pojedinačne programe (rutine)
koje čine neki sustav
 Osnovni test (basic test) – testiranje koje
se izvodi za jednu programsku jedinicu
B. Testiranje
Kao i svaki proces tako i testiranje treba
promatrati s aspekta efikasnosti. U tu svrhu
potrebno je odabrati najbolju metodu da se analizira
i ocijene rezultati testiranja za daljnja poboljšanja i
primjenu određenog programa ili aplikacije.
Uspješno i efikasno testiranje obuhvaća planiranje,
vrijeme, sredstva i obvezu. Za to su zaduženi
specijalisti koji organiziraju i izvode testiranje. Oni
su, također, zaduženi za pripremu test specifikacija,
metodologiju, test uzoraka, redoslijed izvođenja,
predviđanje rizika, analiza, pronalaženje i ispravak
grešaka te daljnja poboljšanja.
Iako se primjenjuju različite metode i postupci
testiranje se uglavnom svodi na sljedeće:
 Testiranje počinje od najmanje programske
jedinice (rutine) i završava s cijelom
aplikacijom.
 Metoda i postupci testiranja se prilagođuju
zahtjevima i potrebama aplikacije ili
programa.
 Testiranje vrše specijalisti koji su razvili i
primijenili softver. Ovisno o veličini
aplikacije može biti uključeno i više osoba.
 Pronalaženje i ispravak grešaka
(debugging) mora biti sastavni dio svakog
testiranja.
Bez obzira na to što se testiranje sastoji od vrlo
temeljitih priprema, metoda i postupaka ono ipak
ima određene rizike. Ti rizici se moraju predvidjeti
da bi se postigla što veća pouzdanost i efikasnost.
C. Rizici u testiranju programskih proizvoda
Rizik je stanje koje može rezultirati gubitkom.
Cijeli problem u riziku je vjerojatnost da će se
gubitak dogoditi. Rizične situacije uvijek postoje
iako se gubitak možda nikada neće dogoditi.
Naprimjer uvijek postoji rizik od požara, ali se
požari rijetko dogode. S obzirom na to da postoji
mogućnost od požara moraju se poduzeti određene
preventivne mjere kako bi se smanjila vjerojatnost
da do njega dođe. Rizici se ne mogu eliminirati, ali
se zato može smanjiti vjerojatnost da se gubitak
dogodi.
Kao što je prethodno spomenuto testiranje je
proces kojim se postiže da je primjena softversikih
aplikacija pouzdana, tj. smanjenje predviđenih i
nepredviđenih grešaka. I unatoč svim poduzetim
mjerama uvijek postoji vjerojatnost da :
 važni podaci bit će izgubljeni,
 funkcioniranje (rad) aplikacije bit će
narušen,
 usluga prema korisniku bit će nekvalitetna,
 aplikacija će biti komplicirana za
održavanje,
 izvedba (rad) aplikacije bit će ispod
zadovoljavajuće razine,
 aplikacija se neće moći povezati s drugim
aplikacijama i sustavima.
Bilo koji od navedenih gubitaka jednostavno
znači neuspjeh softverske aplikacije što
možedovesti do neželjenih posljedica kao sto su
financijski gubitci, neispunjenje rokova pa i stečaj.
Prema veličini rizika će se zato i odrediti i izvršiti
testiranje, ocijeniti i primijeniti metoda testiranja.
Za svaki softverski program mora se primijeniti
najefkasnije testiranje koje će osigurati pouzdanost i
povjerenje korisnika programa (aplikacije). Ovo
zvuči jednostavno, međutim dosadašnje iskustvo
govori da može biti izuzetno veliki broj test uzoraka
za samo par linija kôda. Ako bi izvršavanje svakog
test uzorka iznosilo pola sekunde, onda bi za neku
veću aplikaciju trebalo skoro stoljeće da se izvrše
svi mogući test uzorci. Ovo ne znači da se mora
odustati od testiranja. Jednostavno nema dovoljno
vremena da se sve u potpunosti testira. Odluka o
tome što će se testirati mora biti temeljena na
rizicima. Kada se rizik koristi kao osnova za odluku
što će se testirati tada je to racionalno razmišljanje
koje za rezultat ima fokus i koncentraciju testiranja
u najkritičnijim dijelovima aplikacije.
Jedna od osnova za odabir testiranja je dio kôda
koji se najčešće izvodi. Ako se tu nalazi greška,
frekventnost izvršavanja tog dijela kôda rezultirat
će neuspjehom ili promašajem u aplikaciji
(programu). Primjerice, ako se isti dio kôda izvodi
(ponavlja) u beskonačnoj petlji, i u tom dijelu kôda
se nalazi greška, ona će se pojaviti svaki put kada
program prođe kroz taj dio. Stoga je važno da se
takva greška što prije ispravi.
D. Isplativost
Efikasno testiranje je najbolji način pronalaženja
grešaka gledano s financijskog aspekta. Stoga je
potrebno razmotriti sve moguće gubitke uzrokovane
neuspjehom aplikacije i na temelju toga planirati
testiranje. U tom smislu treba razmotriti i odgovoriti
sljedeća pitanja:
► Da li se znaju krajnji troškovi testiranja?
► Kako će testiranje utjecati na vrijeme razvoja
aplikacije (softverskog programa)?
► Koliko sredstava i vremena odvojiti na
testiranje?
► Koje metode i softverske tehnike primijeniti za
testiranje?
► Je li testiranje isplativo?
Kada dođe do postavljanja ovih pitanja u nekoj
organizaciji, raskorak između akcija i svijesti gdje
se problem nalazi može biti velik. Taj problem je
problem menadžmenta i postoje mnoge studije o
tome[1].
Za efikasno testiranje postoji ravnoteža između
kvalitete softvera i troškova utrošenih na testiranje.
Premalo testiranja smanjuje kvalitetu softverskog
programa, a time i manje troškove. Previše
testiranja daje visoku kvalitetu, ali i visoke
troškove. Ovaj problem prikazan je na slici 1.
Slika 1. Krivulja troškova testiranja
Većina problema vezana uz testiranje događa se iz
sljedećih razloga:
 Krivo se definira što će se testirati,
 Testiranje se izvršavalo u krivoj fazi
razvojnog procesa,
 Koristile su se neefikasne tehnike
testiranja.
Što je efikasnije pronalaženje grešaka to su i veće
uštede u razvojnom procesu i procesu održavanja.
E. Izvođenje testa
Nakon izrade test specifikacije slijedi njeno
pretvaranje u izvedivi (izvršni) oblik, obično kao
kôd. Izvršavanje testa je obično automatsko, ali isto
tako koristi se i manualno izvršavanje. Kôd
automatskog izvršavanja koriste se programske
tehnike u tu svrhu. One su napravljene tako da na
temelju test specifikacije same izvršavaju test, te
prijavljuju otkrivene greške.
F. Ocjena testiranja
Po završetku testiranja vrši se ocjena koja
uključuje sve aspekte koji proistječu iz tog cijelog
procesa. Svakako se treba razmotriti uspješnost i
efikasnost testiranja. Jedan od važnih aspekata u
krajnjoj prosudbi je prihvaćanje krajnjeg rezultata
od strane onih koji nemaju iskustva u testiranju, a
trebaju to odobriti i prihvatiti. To su uglavnom
korisnici i menadžeri.
Da bi tester dao kvalitetnu ocjenu testiranja
predlažu se sljedeća pitanja koja bi on morao
postaviti na kraju svoga rada:
 Da li je testirao sve opće poznate greške?
 Da li je testom pokriosav kôd?
 Da li je predvidio sve moguće uzroke koji
će dovesti do prekida ili nepredviđenog
funkcioniranja (rada) programa?
 Da li je koristio sve ulazne podatke?
 Da li je predvidio i isprobao sve moguće
izvedbe programa koje bi mogao i
korisnik?
Ova pitanja su uvijek korisna jednom testeru
pomoću kojih on sam može odrediti u kojem
trenutku testiranje prestaje i kada je programska
aplikacija spremna upotrebu i isporuku.
III. OPĆENITO O SIMULACIJI I
MODELIRANJU
U posljednjih nekoliko desetljeća došlo je do
velikog razvoja u softverskoj djelatnosti i paralelno
s time potražnja korisnika za boljim, bržim i
jeftinijim softverom. Potražnja na tržištu osjetno je
podigla razinu kompleksnosti softvera, a time one
koji rade na razvoju softvera da poboljšaju svoju
kompetentnost. Istodobno, softverska djelatnost se
oslanja na razvoj računala, programske tehnike i
programske jezike. Pitanje koje se postavlja je kako
poboljšati procese u ovoj djelatnosti koristeći
programske tehnike, cjelokupnu računalsku
tehnologiju i povećati kompetentnost onih koji se
bave razvojem softvera. Odgovor se nalazi u
primjeni simulacije u softverskom inženjerstvu.
Najpoznatiju definiciju simulacije dao je Robert
E. Shannon:
“Simulacija je proces dizajniranja modela realnog
sustava i izvođenje niza ekperimenata na tom
modelu s ciljem razumijevanja ponašanja sustava
ili istraživanja različitih pristupa upravljanja
sustavom.” [4]
A. Modeliranje sustava
Najvažnija komponenta u simulaciji je
modeliranje sustava. Stoga su definirani sljedeći
postupci kako bi se razvio vjerodostojan
simulacijski model [3]:
1) Identifikacija problema – prepoznati i navesti
probleme u postojećem sustavu te postaviti zahtjeve
za promatrani sustav.
2) Formuliranje problema – odrediti granice
sustava ili njegovog dijela koji će se promatrati.
Definirati ukupni cilj razmatranja i kvantitativne
kriterije na osnovi kojih će se uspoređivati i
ocjenjivati različite konfiguracije sustava. Važno je
odrediti da li će se model koristiti za jednokratnu
odluku ili će se koristiti na dulje vrijeme. Također
se u cilju što boljeg definiranja problema mora
identificirati korisnik.
3) Sakupljanje i obrada podataka iz stvarnog
sustava – prikupljanje podataka o specifikaciji
sustava, ulaznim varijablama te o izvedbama
postojećeg sustava. Također se treba uzeti u obzir
vjerojatnost koja se odnosi na varijable i njhove
raspodjele.
4) Formuliranje i razvoj modela – razvoj sheme i
dijagrama tijeka sustava, tj. kako entiteti prolaze
kroz sustav. Nakon toga kreira se model prilagođen
simulacijskom programu. Ovdje se još uključuje
provjera izvođenja modela prema danoj
specifikaciji.
5) Validacija modela – provjera da li izgrađeni
simulacijski model uistinu odgovara realnosti.
Validacija se provodi tako da se kao ulaz
simuliranog modela koriste ulazne varijable iz
realnog sustava za koje su poznate izlazne varijable.
Nakon simulacije uspoređuju se dobiveni rezultati s
onima iz realnog sustava. Ako se poklapaju tada je
modeliran sustav valjan.
6) Dokumentacija modela za buduću upotrebu –
kako bi olakšali ponovnu upotrebu modela za druge
namjene, dokumentiraju se ciljevi razvoja
simulacijskog modela, pretpostavke korištene pri
izgradnji te ulazne varijable.
S obzirom na to da simulacijski modeli
nadomještaju eksperimente na stvarnim sustavima
koji mogu biti jako skupi i kompleksni, oni moraju
osiguravati aproksimaciju stvarnog sustava kako
niti jedan zaključak izvučen iz njega ne bi bio
pogrešan. U tu svrhu provodi se validacija
simulacijskog modela.
B. Metode verifikacije i validacije
Dok validacija provjerava da li je model ispravan
u odnosu na stvarni sustav, verifikacija provjerava
da li je računalni model pomoću kojeg će se
realizirati simulacija ispravan u odnosu na
konceptualni model. Putem tih procesa mora se
osigurati dovoljna ispravnost modela s obzirom na
svrhu i ciljeve.
Metode verifikacije i validacije su sljedeće[3]:
1) Validacija konceptualnog modela – ne postoji
neka formalna metoda za validaciju konceptualnog
modela. Najčešće se radi o proučavanju projektne
specifikacije. U tom se slučaju analiziraju pristupi
modeliranju i ciljevima nekog projekta. Dokument
se kao izvještaj šalje svim važnim sudionicima s
dobrim poznavanjem problematike te se od njih
prikupljaju povratne informacije o prikladnosti
modela.
2) Validacija podataka – da bi podaci bili što
precizniji potrebno je:
ispitati pouzdanost i vjerodostojnost
svakog izvora podataka,
provjeriti da li postoje neke netočnosti u
podacima,
ustanoviti postupak prikupljanja
podataka u pogrešnom formatu i njihovu pretvorbu
u prikladni format,
spremiti podatke odvojene od
simulacijskog kôda.
3) Verifikacija i strukturna validacija – ove dvije
metode se navode zajedno jer se tijekom faze
kodiranja modela obje izvode kontinuirano. Metode
verifikacije i strukturne validacije su:
provjera kôda – prolaskom kroz kôd
provjerava se da li su primijenjeni pravi podaci i
logika,
vizualna provjera modela – neki od
načina vizualne provjere modela su: prolaženje kroz
model događaj po događaj, zaustavljanje modela u
određenom trenutku, predviđanje sljedećeg
događaja te njegova provjera uz ponovno
aktiviranje, interaktivno postavljanje uvjeta kako bi
se naglasilo izvođenje određenih problematičnih
događanja, izoliranje pojedinih dijelova modela,
praćenje kretanja pojedinog entiteta kroz model,
provjera izlaznih rezultata simulacije uspoređivanje
pohranjenih rezultata i s onim koji se očekuju.
4) Validacija cjelokupnog modela :
usporedba s realnim sustavom –
prikupljanje zastarjelih podataka ponašanja sustava
te uspoređivanje prosječne vrijednosti, raspršenost
podataka, distribucije podataka i odnosa ulaznih i
izlazni veličina za stvarni sustav i model,
usporedba s drugim modelima – ako ne
postoje zastarjeli podaci onda se sljedeće metode
primjenjuju: usporedba s matematičkim modelom –
gruba aproksimacija očekivanih rezultata uz
upotrebu matematičkih formula, teorije
posluživanja i statističke analize, usporedba s
determinističkim modelom – uklanjanje svih
elemenata iz modela koji uzrokuju slučajnost,
usporedba s drugim simulacijskim modelima –
usporedba s modelom koji je već verificiran i
ocijenjen kao valjan na temelju ulaznih i izlaznih
podataka te njihovih odnosa[2].
C. Simulacija diskretnih događaja
Simulacijom diskretnih događaja dobiva se
najbolji opis događaja iz realnog svijeta. Ta
simulacija spada pod vjerojatnosnu simulaciju kod
koje se ulazni parametri mogu dobro opisati
funkcijama raspodjele vjerojatnosti te na osnovi
njih upotrijebiti algoritme koji generiraju slučajne
vrijednosti. Simulacija diskretnih događaja
predstavlja model sustava koji se mijenja u
vremenu. Njegove varijable stanja se trenutno
mijenjaju u odvojenim vremenskim točkama. Ti
događaji mogu utjecati na stanje simuliranog
sustava. Zbog mogućnosti mijenjanja dinamike
stvarnog sustava ova simulacija ima jako veliku
važnost.
 Osnovne komponente od kojih se sastoje sve
simulacije diskretnih događaja su [4]:
1) Entiteti – uzrokuju promjene u stanju simulacije.
Bez njih se ništa ne bi događalo. Imaju svoje
jedinstvene karakteristike, tj. atribute. Atributi su
važni za razumijevanje izvedbe i funkcije entiteta u
simulaciji.
2) Aktivnosti i događaji – aktivnosti su procesi i
logika unutar simulacije. Događaji su uvjeti koji se
pojavljuju u određenom vremenskom trenutku i
uzrokuju promjene u sustavu. Događaj kreiraju
entiteti u interakciji s aktivnostima. Tri su osnovne
vrste aktivnosti: odgoda (delay), rep (red čekanja) i
logika. Odgoda je aktivnost u kojoj je izvršenje
entiteta odgođeno za točno određeni vremenski
period. Rep je aktivnost u simulaciji u kojoj entitet
mora čekati neodređeni vremenski period. Logika
omogućava entitetu da utječe na stanja sustava kroz
upravljanje varijablama ili logikom odlučivanja.
3) Sredstva – ona su u simulaciji sve što ima
ograničenu vrijednost i kapacitet. To može biti npr.
broj ulaznih varijabli, broj testera, broj računala i sl.
4) Globalne varijable – one se koriste kako bi se
pratile vrijednosti svih važnih faktora u simulaciji.
Ove su varijable uvijek dostupne čitavom modelu
tijekom izvođenja simulacije.
5) Generator slučajnih brojeva – služi generiranju
slučajnih vrijednosti između 0 i 1. Te se vrijednosti
koriste prilikom kreiranja vjerojatnosnih raspodjela.
6) Kalendar – kalendar sadrži popis događaja koji
se trebaju dogoditi nakon početka simulacije. Ti
događaji ovise samo o vremenu a ne o uvjetima u
simulaciji.
7) Vrijeme – vrijeme je varijabla koja je zajednička
svim simulacijskim modelima.
. aktivnostima nije pridružen rep, jer se pretpostavlja
IV. SIMULACIJA STUDIJSKOG SLUČAJA
Studijski slučaj na kojem je provedena simulacija
i analiza procesa sastoji se od šest
testera. Testere prema razini znanja,
brzini rješavanja problema i iskustvu
dijelimo u tri skupine: eksperte, one
koji su više iskusni i one koji su manje
iskusni. Studijski test tim sastoji se od
jednog eksperta, dva više iskusna
testera i tri manje iskusna testera.
A. Opis aktivnosti u studijskom slučaju
Internim kompanijskim procesom testiranja
definirane su dvije aktivnosti za testere: priprema
test specifikacije i izvođenje testa. Ove dvije
aktivnosti obuhvaćaju niz podaktivnosti koje
detaljnije opisuju rad pojedinog testera.
Kod eksperta u internom kompanijskom procesu
testiranja za pripremu test specifikacije spadaju
sljedeće podaktivnosti: proučavanje ulazne
dokumentacije (dokumentacija vezana za ono što će
se testirati), priprema test specifikacije i pomoć
manje iskusnim testerima u izradi test specifikacije.
U izvođenje testa definirano internim kompanijskim
procesom testiranja spadaju sljedeće podaktivnosti:
izvođenje testa, pomoć pri izvođenju testa manje
iskusnim testerima, evidentiranje greške i
regresijsko testiranje.
Kod više iskusnih testera u pripremu test
specifikacije definirane internim kompanijskim
procesom spadaju podaktivnosti: proučavanje
ulazne dokumentacije i priprema test specifikacije.
U izvođenje testa definirano internim kompanijskim
procesom spadaju podaktivnosti: izvođenje testa,
evidentiranje greške i regresijsko testiranje.
Kod manje iskusnih testera u pripremu test
specifikacije definirane internim kompanijskim
procesom spadaju sljedeće podaktivnosti:
proučavanje ulazne dokumentacije, priprema test
specifikacije i dorada test specifikacije. U izvođenje
testa definirano internim kompanijskim procesom
spadaju podaktivnosti: izvođenje testa, regresijski
test i evidentiranje greške.
B. Simulacija procesa u studijskom slučaju
Model mreže repova transformiran je u
simulacijski model primjenom grafičkog sučelja
simulacijskog softvera Micro Saint. Repovi su
pridruženi onim čvorovima koji prikazuju
aktivnosti posluživanja zahtjeva za modifikacijom
koje se, zbog ograničenosti resursa procesa, ne
odvijaju trenutno, nego se neko vrijeme provodi
čekajući. S obzirom da je proces dizajniran tako da
se neke aktivnosti nad istim zahtjevom izvode
sekvencijalno od strane istog poslužitelja, tim
da poslužitelj obrađuje isti zahtjev od prve do
zadnje aktivnosti u dotičnoj fazi procesa bez
prekida i bez čekanja.
Historijski podaci o projektu u studijskom
slučaju dobiveni su iz baze podataka o projektu i iz
intervjua sa svakim od testera. Svi dobiveni podaci
uvršteni su u simulaciju za pojedinu aktivnost.
Ukupna simulacija je imala sto reputacija, što znači
da je u jednom pokretanju simulacijskog modela
svaka pojedina. Vremenska jedinica koja se koristila
u simulaciji i u svim aktivnostima su sati. U svakom
koraku simulirao se proces kroz vremensko
razdoblje od 12383 sata koje je ujedno i ukupno
vrijeme trajanja testiranja u projektu. Na osnovi
dobivenih podataka prilikom izvođenja simulacije
te njihovih malih odstupanja od podataka iz
stvarnog procesa može se zaključiti da se radi o
valjanom modelu koji kao takav čini dobar prikaz
stvarnog procesa (tablica 1.).
Tablica 1.
Broj nađenih
Broj ulaza
grešaka
Historijski
73 45
podaci
Podaci dobiveni
74.61 46.71
simulacijom
Daljnjom analizom podataka koji su dobiveni
putem simulacije dobilo se da je iskoristivost
eksperta 0.784, više iskusnih testera 0.795 i manje
iskusnih testera 0.641. Iz pretpostavke koje se
dobila putem intervjua da manje iskusnom testeru
za isti posao treba dva puta više vremena od
eksperta, i jedan i pol puta više vremena od više
iskusnog testera vidi se da su manje iskusni testeri
najkritičniji dio procesa testiranja u studijskom
slučaju. Manje iskusne testere treba što više
educirati da bi stekli odgovarajuća znanja, vještine i
iskustvo, a samim time bi se povećala efikasnost
cjelokupnog procesa. Više iskusni testeri imaju
visoku iskoristivost i kada se uzme u obzir da oni
naprave velik dio posla, omjer znanja i cijene koju
se za njih mora platiti je najidealniji u procesu
testiranja u studijskom slučaju. Ekspert napravi
najveći dio posla u studijskom slučaju i kraj toga
pomogne u radu manje iskusnim testerima. On je
ključni čovjek za projekt (eng. key person).
V. ZAKLJUČAK
Programski proces testiranja predstavlja važnu
kariku u životnom ciklusu razvoja programskog
proizvoda. Riječ je o vrlo složenom procesu koji
uključuje mnogo različitih aktivnosti, interakcija i
povratnih veza. Svaka od tih aktivnosti ima veliku
važnost u uspješnom dovršenju programskog
procesa testiranja. Proces započinje ulaskom radne
cjeline ili promjene zahtjeva u fazu testiranja u
studijskom slučaju u čijoj se grupi nalazi šest
testera: jedan ekspert, dva više iskusna testera i tri
manje iskusna testera. Radna cjelina ili promjena
zahtjeva se dodijeli jednom od šest testera i to
počinju aktivnosti vezane uz testiranje. Za vrijeme
testiranja se evidentiraju greške nađene u softveru
koje su u domeni radne cjeline ili promjene
zahtjeva.
Prethodnica postupku modeliranja predstavljalo
je prikupljanje podataka i znanja o procesu,
neizostavnih aktivnosti prilikom svakog
modeliranja nekog procesa. Analizom prikupljenih
podataka utvrđuje se ponašanje procesa, a samim
time se omogućuje lakše i efikasnije postizanje
konačnog, valjanog modela. Modeliranje je
zasnovano na temeljima teorije posluživanja i
mrežama repova. Na taj je način bilo moguće
prikazati događaje iz realnog svijeta i u tome
obuhvatiti interakcije promatranog procesa. Kao
rezultat modeliranja dobiva se jasan prikaz
redoslijeda i načina odvijanja aktivnosti sadržanih
unutar procesa koji se promatra.
Simulacija se pokazala kao korisna tehnika koja
omogućuje razmatranje ponašanja i performansi
procesa testiranja programskih proizvoda. Njena
primjena donosi velik napredak u daljnjoj analizi
procesa. U radu se koristio simulacijski programski
paket Micro Saint koji sadrži razne mogućnosti
analize simuliranog procesa. Simulacijom su
omogućena brža i jednostavnija prikupljanja
korisnih podataka koja bi u stvarnosti trajala puno
duže. Na osnovi prikupljenih podataka provedene
su statističke obrade i analize, a omogućen je i
prikaz putem raznih dijagrama i grafova. Ti će
podaci otvoriti razne mogućnosti poboljšanja
dotičnog procesa u onim segmentima koji su prema
prikupljenim podacima na to ukazivali. Na taj način
će se ujedno smanjiti rizici ukoliko se krene u takav
eksperiment jer će se sva ispitivanja obavljati na
modelu bez uplitanja u stvarni proces.
Rezultati koji su dobiveni provođenjem
simulacije na modelu pokazali su da je model
valjan, te da su na njemu moguće daljnje analize
procesa. Analizom studijskog slučaja došlo se do
saznanja o nedostacima procesa, i to konkretno kod
manje iskusnih testera. Da bi se proces testiranja
programskih proizvoda poboljšao potrebno je što
prije obučiti manje iskusne testere znanjem,
vještinama i iskustvom. Analizom procesa se
usredotočilo na promatranje onih performansi
procesa koje se mogu prikazati karakterističnim
parametrima mreže repova. To se odnosi na vrijeme
zadržavanja, vrijeme posluživanja i vrijeme čekanja
radnih cjelina i promjeni zahtjeva, kao i stupnju
iskoristivosti pojedinih testera. Prikupljeni podaci
upozorili su na one dijelove koji trebaju krenuti za
poboljšanjem kako bi se postigla viša razina
efikasnosti promatranog procesa, a na taj način
osigurati što kvalitetniji programski proizvod.
LITERATURA
[1] Perry, W., “Effective Methods for Software
Testing”, John Wiley & Sons, New York, USA,
1995.
[2] Car, Ž, “Modeliranje procesa održavanja
telekomunikacijske programske podrške”,
Doktorska disertacija, Fakultet elektrotehnike i
računarstva, Zagreb, 2001.
[3] Law, A. M., W. D. Kelton., “Simulation
Modeling and Analysis”, McGraw-Hill Inc., 2000.
[4] Ingalls, R.G., “Introduction to Simulation”,
Proceedings of the 2001 Winter Simulation,
Conference, pp.7-16.