POENOSTAVLJENA NAPOVED NASTOPA NAPAK
PRI TESTIRANJU PROGRAMSKE OPREME
Tomaž Dogša, dipl. ing., dr. Ivo Rozman
TEHNIŠKA FAKULTETA MARIBOR
JUGOSLAVIJA
UDK: 681.3.06
POVZETEK - V članku je prikazana praktična in enostavna metoda za predikacijo nastopa napak v zadnjem obdobju testi-
ranja. Ocenjen potrebni čas testiranja za odkritje naslednjih napak nam omogoča objektivno odločitev o prenehanju te-
stiranja. Prikazan je tudi konkreten primer predikcije, ki se je uporabil pri testiranju simulatorja teleinformacijskih
sistemov v železniškem prometu.
SIMPLE METHOD FOR SOFTWARE FAILURE PREDICTION - A practical and simple method for softvrare failure prediction in
the last period of software testing in presented. Objectiv decision when to stop with testing, is possible with results of
prediction. A practical example of prediction that was used by software testing of computer railway control systems is
also included.
UVOD
Eden izmed glavnih kazalcev kvalitete programske opre-
me je njena zanesljivost. S testiranjem programov sku-
šamo dobiti odgovore na naslednja vprašanja:
a) Koliko je vseh napak v programu?
b) Kolikšna je zanesljivost delovanja programa v realnem
okolju?
c) Kako dolgo je potrebno še testirati, da bo odkritih npr.
90 % vseh napak? •
d) Kolikšni bodo stroški testiranja?
Danes so že razviti določeni matematični modeli /2/,
/5/, ki bolj ali manj uspešno dajejo odgovore na ta vpra-
šanja. Predvsem v praksi pogosto nerealne predpostavke,
na katerih bazirajo ti modeli in pa vpletenost čisto sub-
jektivnega faktorja otežuje deterministični pristop. (Po-
goste predpostavke: število vseh napak v programu je
konstantno, velikost programa se ne spreminja, večina
napak je odpravljenih itd.)
V nadaljevanju članka je prikazano, kako se da brez upo-
rabe zapletenih modelov odgovoriti na vprašanje d). Ta
metoda bo ilustrirala še s konkretnim primerom testi-
ranja.
POENOSTAVUENA PREDIKCIJA
Pri uporabi vsakega modela potrebujemo podatke o rezul-
tatih testiranja. V ta namen je bila razvita posebna pro-
cedura /4/, ki je omogočala zbiranje najosnovnejših po-
datkov:
1. CPU čas potrebnega odkritja napake
2. število odkritih napak (v primeru, da jih je več kot 1)
3. koledarski čas potreben za odkritje napake
4. čas potreben za odpravo napake
5. velikost programa, ki ga testiramo.
Iz teh podatkov se dobijo osnovni pokazatelji, ki jih po-
trebujemo pri zasledovanju uspešnosti testiranja. V kon-
kretnem primerif smo opazovali intenzivnost pojavljanja
napak v odvisnosti od skupnega časa testiranja (slika l)
in pa kumulativno število napak v odvisnosti od CPU časa
testiranja (slika 2) /2/.
20.
10.
S.
k
-Ufc.
B 300. 388. 108.
saa.
Slika 1: Intenzivnost pojavljanja napak P(t) v odvisnosti
od skupnega CPU časa testiranja t.
Z interpolacijo grafa na slikl 2 dobimo potreben čas za
odkritje nekaj naslednjih napak (slika 3). Ta pristop te-
melji na naslednjih predpostavkah:
1. večina napak je že odkritih
2. intenzivnost pojavljanja napak ne bo naraščala ampak
padala.
Za interpolacijsko funkcijo je bila zbrana
f(x) = k2f7+ kj.
Za napoved potrebnega časa At, v katerem bomo našli
še AN napak, moramo določiti enačbo, ki ponazarja

129
graf na sliki 2. S pomočjo metode povprečnih vrednosti
120.
20.
10B. 5B8.
Slika 2: Kumulativno število napak n v odvisnosti od CPU
časa testiranja t. .
določimo koeficiente interpolacijske funkcije za interval
AN'. Za AN'naj velja:
Ko je funkcija f (x) določena, lahko izračunarrto nastop
napak v intervalu /vt.
Tabela na slikl 4 prikazuje del numericnih rezultatov, ki
smo jih dobili pri testiranju simulatorja procesov v že-
N
*N ••:.-••. -
ll
; • r; - ' '
i
SHka 3: Preprosta predikcija.
lezniškem prometu. Ko smo odkrili 85 napako, smo na-
pravili predikcijo za nastop naslednjih 5 napak. Napove-
dan potreben čas testiranja je bil 48,5 sek.(CPU),
9 k Rlik j šl
ka-
p p
dan potreben čas testiranja je bil 48,5 sek.(CPU), ka-
sneje izmerjen pa 40,9 sek. Razlika je znašala 18,6 %.
Iz primerjave med napovedanimi podatki in dejanskimi je
razvidno, da izbrana interpolacijska funkcija f(x) dobro
ustreza. Maksimalno odstopanje na celotnem intervalu je
bilo 4 %. Napoved za daljši interval je manj zanesljiva.
Če bi v prejšnjem primeru povečali interval AN in /5>N'
na 10, bi maksimalno odstopanje naraslo na 10,4 %.
Ker izbrana interpolacijska funkcija nima llmitne vred-
nosti, se analitično ne da določiti število vseh napak.
Slednje bi omogočila izbira funkcije
kl je podlaga znanerou Musovemu modelu /6/. V tem pri-
meru bi postalo določanje koeficlentov k In k precej za-
pleteno, saj bi morali reševati transcendentne enačbe.
t
150,9
152,2
165,7
177,5
183,1
201,8
213,9
219,0
224,3
244,7
254,8
t*
146,49
156,25
166,33
176,72
187,43
198,45
207,79
221,44
233,41
245,69
258,29
N
80
81
.2 -'
84
85
86
87
88 AN
89
90
odstopanje
4,41
-4,05
-0,63
0,78 •
-4,33
3,35
4,11
-2,44
-9,11 (-4%)
-:0,99
-3,49
40,9 .. 48,5
Sllka 4:Primerjava med predikacijo t* in dejanskimi re-
zultati t za napake od 86 do 90. Za kontrolo je iz-
računano odstopanje interpolacijske krivulje v po-
dročju že dobljenih rezultatov AN^
ZAKLJUČEK
Z izbiro preprostega matematičnega modela se da dokaj
natančno napovedati nastop napak v zadnjem obdobju te-
stiranja. S temi podatki lahko zelo dobro ocenimo nadalj-
nje stroške testiranja. Z opazovanjem intenzivnosti pojav-
ljanja napak lahko sklepamo o umirjanju pojavljanja napak.
Velika nihanja pomenijo, da s testiranjem vsekakor ne •
smemo končati.
UTERATURA
/1/ Myers J. G.: The Art of Softvrare Testing, John
Wiley and Sons, Inc., New York 1979
/2/J.Virant: Zanesljivost računalniških sistemov, Zal.
Fakulteta za elektrotehniko v Ljubljani, Ljubljana 1981
/3/ M. L. Schooman: Softvrare Reliability: A. Historical
Perspective, IEEE Trausactions on Raliability,
1984april, Vol. R-33, No 1, str. 48-55
/4/ T. Dogša: Testiranje programske opreme teleinfor-
macijskih sistemov za vodenje železniškega prometa,
Magistrska naloga, Tehniška fakulteta v Mariboru,
Maribor 1985
/5/ Alan N. Sukert: Empirical Validation of Three Soft-
ware Error Predictlon Models, IEEE Traus. on Re-
liability, Vol. R - 28, No. 3, August 1979, str.
199-204
/6/ J.. D. Musa: Validity of Execution - Time Theoriy of
Software Reliability, IEEE Traus. on Reliability, Vol.
R - 28; No. 3, August 1979, str. 181-191
f(x)