Frjáls verslun - 01.07.1988, Síða 44

leg tilvik auk þess að prófa helstu
jaðartilvik.
Þriðja skrefið er að framkvæma
kerfispróf. Þá er prófað hvort
samræmi sé í framsetningu
gagna; hvort mismunandi sam-
antektir gefi samvarandi niður-
stöður; hvort kerfið standist yfir-
leitt þær kröfur sem gerðar voru
við hönnun. Þessum hluta er oft-
ast sleppt þar sem hér er gjarnan
kominn mikill þrýstingur af hálfu
notanda um að fá kerfið til notk-
unar. Bráðnauðsynlegt er þó að
tryggja a.m.k. að gögn notanda
tapist aldrei, þ.e. að allar skrán-
ingar séu öruggar.
Fjórða og síðasta þrepið er að
setja kerfi í gang hjá notanda. í
byrjun er nauðsynlegt að fylgjast
vel með gangi kerfisins. Tryggja
þarf að forritið sé notað eins og
ætlast var til. Oft þarf að breyta
ýmsum smáatriðum til að tryggja
að notkunin sé þjál. Á þessu stigi
prófunar er unnið með raunveru-
leg gögn notanda, og því verður
að taka afrit af kerfinu mjög oft til
að tryggja lágmarks áhrif ef villa
finnst ekki fyrr en á þessu stigi.
DÆMI UM AÐFERÐIR TIL AÐ
AUÐVELDA PRÓFUN OG VILLULEIT:
Hönnuðir og forritarar geta gert
ýmislegt til að auðvelda prófun og
villuleit forrita. Eitt mikilvægasta
atriðið er að hægt sé að skoða
beint allar skráðar upplýsingar.
Stundum dugar að sýna allar
forsendur með niðurstöðum, en
ef um mikið magn gagna er að
ræða er æskilegast fyrir prófar-
ann að hægt sé að kanna gögnin
með almennu fyrirspurnakerfi.
Best er að nota almennan gagna-
grunn, þar sem bæði er hægt að
skrifa forrit og koma með almenn-
ar fyrirspurnir. Almennur gagna-
grunnur hefur auk þess þann kost
að oft er hægt að svara auðveld-
lega spurningum, sem notandi
kemur með. Síðar má byggja
þessa fyrirspurn inn sem hluta af
kerfinu, ef þurfa þykir.
Æskilegast er að hönnuðir út-
búi prófgögn strax við lok hönn-
unar kerfisins. Hjá stærri fyrir-
tækjum tíðkast nú að prófarar taki
þátt í hönnuninni, alveg frá fyrstu
tíð. Með þessari aðferð verða
prófgögn og niðurstöður skil-
greindar í byrjun. Þessi gögn má
bera undir notandann og fá sam-
þykki hans við vinnugangi kerfis-
ins. Þannig hefur prófun forrita
verið stöðugt að færast framar í
hönnunarferilinn og blandast
meira inn í öll stig smíðinnar. Yfir-
leitt er þá útbúin röð prófana, sem
ný útgáfa verður að standast áður
en hún er sett af stað hjá notanda.
Til að auðvelda allt viðhald
kerfisins, en ekki eingöngu próf-
anir og villuleit, er nauðsynlegt að
samloðun milli mismunandi að-
gerða og eininga kerfisins sé sem
allra minnst. Með lítilli samloðun
er átt við að breyting á einum stað
geti ekki haft áhrif á öðrum. Allar
aðgerðir eru sjálfstæðar og breyt-
ur sem allir hlutar forritsins þekkja
eru fáar. Öll undirforritasöfn sem
notuð eru, eru mjög ítarlega próf-
uð og vandlega afmörkuð.
Varnarforritun er nauðsynleg til
að stöðva misnotkun kerfisins
eða einstakra hluta þess. Til
dæmis má nefna athugun á
stærðartakmörkunum, deilingu
með núlli og fleira í þeim dúr.
Varnarforritun er sérstaklega
nauðsynleg í öllum almennum
undirforritasöfnum, til að tryggja
skynsamleg viðbrögð við vafa-
sömun gögnum.
Góð handbók hefur óbeint
reynst öflugt tæki við prófanir.
Höfundur handbókarinnar verður
að prófa allt kerfið út í æsar til að
geta lýst aðgerðum. Það lendir
því á höfundi að lýsa gangi kerfis-
ins og útskýra og réttlæta allar
aðgerðir þess.
Dæmi um algengar villur í forritum:
Ein algengasta villan í forritum
hér á landi er sú að skráning
gagna er ekki trygg. Sérstaklega
á þetta við ef sama aðgerðin þarf
að uppfæra margar færslur sam-
tímis. Þá er mikil hætta á að hluti
færslanna skráist, en ekki allar.
Þannig myndast innbyrðis mis-
ræmi í gögnum, sem erfitt getur
verið að finna fyrir notanda. Sem
dæmi má taka bókhaldsforrit,
sem þarf að færa fjárhagsfærslur
á marga lykla fyrir eitt og sama
fylgiskjalið. Ef einungis hluti
þessara færslna færist, stemmir
bókhaldið ekki þótt allt hafi verið í
lagi upphaflega. Ástæðurfyrir því
að einungis hluti færslnanna
skráist geta verið mismunandi.
Rafmagn getur farið af í miðjum
klíðum, notandi getur stöðvað for-
ritið, diskur getur skemmst eða
fyllst og margt fleira.
Einnig þekkist það að ná-
kvæmni í útreikningum er önnur
en notandi sér á skjánum. Þannig
er ekki alltaf víst að notandi fái
sömu samtölu úr lista og forritið.
Ástæðan er gjarnan sú að forritið
reiknar með fleiri aukastöfum en
sýndir eru. Annar angi af þessari
sömu villu er að notandi fær mis-
munandi niðurstöður, eftir því
hvernig gögnin eru framsett. Sala
dagsins getur verið mismunandi
eftir því hvort beðið er um einn
einstakan dag eða samantekt yfir
mánuðinn. Villur af þessu tagi eru
mjög hvimleiðar og verða þess
valdandi að notandinn fer að van-
treysta kerfinu.
Ein algengasta villan við próf-
anir er sú að eingöngu eru prófuð
einstök einföld tilvik. Jaðartilfellin
gleymast, einkum og sér í lagi
það að hluta af gögnunum vanti.
Þannig vill gleymast að byggja
inn nægjanlegt varnarkerfi til að
tryggja að hönnunarforsendum
kerfisins sé ekki misþyrmt. Deil-
ing er sérlega varasöm, og nauð-
synlegt er að athuga sérstaklega
hver viðbrögð forritsins eiga að
vera ef deila á með núlli.
Þegar villa hefur fundist í forriti
er gjarnan rokið til og hún leiðrétt.
Yfirleitt gleymist að athuga hvort
fleiri slíkar leynist í forritinu. Það
er nú svo að forritun er að tölu-
verðu leyti breyting á eldri forrit-
um. Þannig vill misskilningur eða
villa flæða vítt og breitt yfir forrit.
Einnig vill gleymast í hrifningunni
yfir að hafa fundið og leiðrétt
„VILLUNA" að athuga hvort aðrar
villur hafi slæðst inn við leiðrétt-
Framhald á sícu 50
44