Tarkvaratestimine (0)

TARKVARA TESTIMINE
Ainetöö
Tallinn 2012
SISUKORD
SISSEJUHATUS 2
TARKVARA TESTIMISE VEAD 2
MIS ON VIGA? 3
MIKS VEAD TEKIVAD? 4
KUI PALJU VEAD MAKSAVAD? 4
MIDA TÄPSELT TEEB TARKVARA TESTIJA? 4
TARKVARA TESTIJAL PEAVAD OLEMA KA KINDLAD OMADUSED. 5
ERINEVAD TARKVARA ARENDUS MEETODID 5
MUSTA-KASTI, VALGE-KASTI JA HALLI-KASTI TESTIMINE 8
STAATILINE JA DÜNAAMILINE TESTIMINE 8
KOODI TESTIMINE 8
ÜHILDUVUSE TESTIMINE 8
KASUTATAVUSE TESTIMINE 9
TARKVARA TURVALISUSE TESTIMINE 9
AUTOMATISEERITUD TESTIMINE JA TÖÖRIISTAD 9

SISSEJUHATUS

Aastal 1947 olid arvutid suured, ruumi suurused masinad mis töötasid mehaaniliste releede ja ja hõõguv vaakumlampidega. Uusi ja parim arvuti mis ehitati oli Mark II, mis ehitati Harvardi Ülikoolis. Teadlased jooksutasid arvutit omas tempos kuni see järsku seisma jäi. Nad uurisid , miks arvuti end välja lülitas ja avastasid, et sügavale arvutisse relee kontakti peale oli lennanud liblikas. Arvatavasti oli ta lennanud sinna, kuna seal on soe ja valge. Ning kui ta maandus releele sai ta elektri löögi ja suri. Niimoodi sündis esimene viga.
Lihtne on kasutada tarkvara ja selle eest olla mitte tänulik. Paljud inimesed ei saa aru kui palju tarkvara meie elu tänapäeval puudutab. 1947. aastal vaja Marki II tervet leegioni programmeerijaid, et teda käimas hoida. Sel ajal ei mõelnud keegi, et kunagi on kõigil kodus personaalne arvuti. Tänapäeval on vaba tarkvara CD plaat kaasa pandud isegi teraviljahelveste karbiga, ning rohkem tarkvara on arvuti mängudes kui kunagi oli kosmosesüstikus. Mis kunagi oli haruldane tehniline vidin, nagu piipar ja mobiiltelefon on tänapäeval peaaegu kõigil olemas. Enamik meist ei suuda päevagi olla internetita, vähemalt korra päevas vaadatakse ikka oma e-mailid üle. Tarkvara on igale pool kuhu me vaatame. Kuid kõik tarkvara on kirjutatud inimese poolt, nii, et see ei ole kunagi täiesti täiuslik.

TARKVARA TESTIMISE VEAD

Disney Lion King 1994/1995
1994 aasta sügisel lasi Disney välja esimese multimeedia cd-rom mängu lastele, Lion Kingi animeeritud  juturaamatu . See oli Disneyle esimene turule tulemine, ning seda promoti ja reklaamiti väga palju. Mängu müük oli tohutu. Kuid peale jõule olid Disney klienditoe telefonid punased. Laste vanemad olid väga pahased, sest tarkvara ei läinud arvutis tööle. Ning siis tuli välja, et Disney tarkvara testijad, ei olnud tarkvara testinud erinevatel arvutitel mis seal ajal olid müügis. Mäng töötas vaid nendel arvutitel mille peal olid Disney programmeerijad mängu loonud.
Patriot rakettide tõrjesüsteem, 1991
Esimest korda kasutati Patriot rakettide tõrjesüsteemi Lahesõjas Iraagi Scud rakettide vastu. Kuigi oli palju uudiseid süsteemi edust, ei suutnud ta siiski kaitsta mitme raketi vastu. Üks rakett pääses kaitsest läbi ja tappis 28 USA sõdurit Dhahranis. Pärast analüüse leiti, et põhjuseks oli viga tarkvars. Väike ajaline viga tekkis süsteemi kella, et peale 14 tundi töötamist ei olnud enam tõrjesüsteem täpne. Kui Dhahrani rünnati oli süsteem töötanud juba üle 100 tunni.
Y2K (aasta 2000) viga, 1974
1970 aasta alguses töötas programmeerija palgasüsteemi kallal. Kuna arvutil oli vähe mälu ja tal ei olnud seda raisata siis kasutas ta 4-numbri formaadi asemel 2-numbri formaati. Tema programmist sõltus suuresti kuupäeva töötlemine, millega säästeti palju kallist mälu. Ta mõtles mis juhtub aastal 2000 kui hakatakse kasutama 00 ja 01, et see võib kindlasti probleeme tekitama hakata. Kuid ta arvas, et selleks ajaks on kindlasti tema programmi ammu uuendatud . Kuid 1995 aastal kasutati veel tema programmi, kuid keegi ei osanud vaadata kas programm vastab Y2K nõuetele, veel vähem viga parandada. Arvatakse, et kulutati sadu miljoneid dollareid ülemaailma, et uuendada arvuteid või neid välja vahetada.

MIS ON VIGA?

Eelpool kirjutasin mis juhtub, kui tarkvara ebaõnnestub. See võib olla ebamugav, nagu kui arvuti mäng ei tööta korralikult või võib olla katastroofiline lõppedes kellegi elu kaotusega. Parandamine võib minna maksma vaid mõned pennid, kuid miljoneid dollareid, et lahendust levitada. Vea parandamine võib maksta vaid mõni euro, kuid, et uus parandatud tarkvara uuesti poodidesse laiali saata. Eelpool toodud näidetes oli selge, et tarkvara ei töötanud nii nagu ta pidi. Tarkvara testijana sa avastad, et kunagi ei ole kõik vead nii märgatavad. Enamus vead on lihtsad, aga paljud on ka väga väiksed vead, et ei saagi aru millised on tõelised vead ja millised ei ole.

MIKS VEAD TEKIVAD?

Enamus vigu ei tulene programmeerimisest. On tehtud uuringuid väga suurtel projektidel, ning kõik on alati ühe ja sama saanud, et tarkvara vead tekivad spetsifikatsioonis. Põhjusi on mitmeid miks vead tekivad spetsifikatsioonides. Mõnel juhul lihtsalt ei kirjutada spetsifikatsiooni. Mõnel juhul ei ole spetsifikatsioon ei ole põhjalik, see muutub pidevalt või see ei ole tervele arendusmeeskonnale edastatud . Teine suurim koht kus vigu tekib on kujundus. Neid tekib sellepärast, et kas kiirustatakse või ei ole piisavalt infovahetust meeskondade vahel. Koodi kirjutamise vead on tavaliselt jälitatavad. Vead võivad tekkida kui tarkvara on keerukas, halb dokumentatsioon (eriti kui koodi on uuendatud või muudetud), tähtaeg või lihtsalt mõni loll viga. Tähtis on teada, et paljud vead mis võivad tunduda programmeerimise vigadena on üldjuhul võimalik jälitada nende algus kohani mis tavaliselt on tekkinud spetsifikatsioonis või disainis.

KUI PALJU VEAD MAKSAVAD?

Kui viga avastatakse tarkvara valmistamise algfaasis võib vea parandus maksa ainult euro või isegi mitte midagi, aga kui sama viga leitakse kodeerimise ja testimise käigus võib ta maksta juba mõnikümmend kuni isegi sada eurot. Kui aga klient leiab selle võib see maksta isegi tuhandeid või miljoneid eruosid.

MIDA TÄPSELT TEEB TARKVARA TESTIJA?

Tarkvara testija tööks on leida tarkvaras vigu. Kui testija ei leia vigu üles siis see võib minna tema projektile ja firmale kalliks maksma. Vead tuleb leida võimalikult kiiresti üles ja need ära parandada.

TARKVARA TESTIJAL PEAVAD OLEMA KA KINDLAD OMADUSED.

Ta ei karda ja julgeb minna tundmatutesse olukordadesse. Nad on vigade avastajad. Nad armastavad uut tarkvara. Testija on järeleandmatu. Nad on loomingulised ja püüdlevad alati täiuslikkusse poole. Nad on taktitundelised ja diplomaatilised. Testija peab alati tooma halbu uudiseid programmeerijatele ja kujundajatele.

ERINEVAD TARKVARA ARENDUS MEETODID

Üldjuhul kasutatakse nelja erinevat arendus meetodit: Big- Bang (suur- pauk ), Code -and-Fix ( kodeeri ja paranda), Waterfall ( kosk ) ja Spiral ( spiraal ). Igal mudelil on omad plussid ja miinused. Testijana puutud sa tõenäoliselt kõigi nendega kokku ja pead oma testid kõigi nende meetodite ja kohandama .
Big-Bang (suur-pauk) meetod:
See tarkvara loomise meetod sarnaneb paljugi teooriaga kuidas loodi universum kus me praegu elame. Suur hulk inimesi ja raha suunatakse sellesse projekti. Projekti suunatakse väga palju energiat, ning lõpptulemus on ideaalne tarkvara või mitte midagi. Ilu selle meetodi juures on see, et see on lihtne, ei ole kindlat ajalimiiti millal see valmis peab saama, seal ei ole kindlat projekti ja tavalist arendusmeeskonda. Kogu protsess on suunatud arendusele ja kodeerimisele. Kuid kliendid kes tellivad tarkvara peavad olema väga paindlikud, sest alles lõpus saavad nad teada mille nad saavad. Testimist selle projekti puhul peaaegu ei tehtagi, kui siis ainult enne tarkvara välja tulemist. Halb külg selle meetodi juures on see, et projektijuhi nägemuse järgi on toode valmis müüki minema ja sina kui testija hoiad seda veel kinni. Mida kauem sa oma tööd teed seda rohkem vigu sa leiad, ning seda kriitilisemaks see olukord muutub. Kui võimalik siis hoiduda selle mudeli juures testimisest.
Code-and-Fix (kodeeri ja paranda) meetod:
Selle meetodi kohta kehtib üks vanasõna: „Pole kunagi aega, et seda õigesti teha, kuid on alati aega, et seda uuesti teha“.
Selle meetodi juurest tuleb meeskond tavaliselt hea, kuid keerulise idee peale. Tehakse lihtne disain ja siis hakatakse koodi kirjutama ja vigu otsima , seda tsüklit korratakse mitu korda kuni leitakse, et aitab küll sellest ja lasevad toote müüki. Kuna selles meetodis on vähe planeerimist siis saab meeskond kohe oma tulemisi näidata. See meetod sobib ideaalselt väikestele projektidele.
Waterfall (kosk) meetod:
See meetod on lihtne, elegantne ja sellest saab kergesti aru. Ning see võib õigetel projektidel töötada perfektselt.
Siin meetodis liigutakse samm-sammu haaval edasi. Kui projektijuht arvab , et meeskond pole veel valmis edasi järgmise tasemeni liikuma siis nad püsivad seal niikaua kuni ta leiab, et kõik on valmis. Suur rõhk on pandud sellele milline peab toode valmimisel olema. Kui on liigutud edasi järgmise sammuni ei saa enam tagasi minna vaid tuleb seal oma töö ära teha ja edasi liikuda järgmise etapini. Testija vaatest on see hea meetod, sest kui nemad saavad tarkvara kätte on see täiesti valmis. Nad saavad panna paika täpse plaani ja ajakava kaua testimine aega võtab.See meetod on hea aga on ka halb, sest tarkvara testitakse alles kõige viimasena ja vigade parandamine mis leitakse võib minna väga kulukaks.
Spiral (spiraal) meetod:
Siin meetodis ei määrata kohe alguses kõiki üksikasju ära. Alustatakse väiksest osast, tehakse see valmis, ning siis saadetakse kliendile see üle vaatamiseks. Kui klient on rahul alustatakse järgmise etapiga ja see kestab niikaua kuni toode on valmis.
Spiraal meetod hõlmab endas kuut etappi :

Kindlad eesmärgid, alternatiivid ja piirangud

Riskide välja selgitamine ja lahendamine

Alternatiivide hindamine

Arendamine ja testimine hetkesel tasemel

Järgmise taseme plaanimine

Otsustamine kas minna edasi järgmisele tasemele
Spiraal meetodis kasutatakse natuke iga meetodi etappe .
Tarkvara pole kunagi võimalik täielikult läbi testida. Tarkvara testija amet on väga riskantne. Kui sa ei testi läbi kõiki võimalikke võimalusi ja mõni klient avastab selle vea, võib selle parandamine minna väga kulukaks. Paljud tarkvara testijad tulevad projekti niimoodi, et nad ei teagi täpselt mis otsused on vastu võetud ja milliseid protseduure tuleks jälgida. Nii on võimatu olla efektiivne.
Kui sa leiad ühe vea on väga tõenäoline, et sa leiad sealt lähedalt veel mõne vea. Alati ei ole võimalik kõiki vigu ära parandada, sest selleks ei pruugi aega olla. Tuleb välja, et mida sa pidasid veaks ei olegi tegelikult viga.

MUSTA-KASTI, VALGE-KASTI JA HALLI-KASTI TESTIMINE

Musta-kasti testimisel teatakse mida tarkvara peab tegema aga ei teata sisemusi rakendusi ja kuidas ta töötab. Kui ta midagi proovib siis ta näeb ainult selle tulemast aga ta ei tea kuidas see juhtus. Valge kasti testimine, on vastandiks musta kasti testimisele, kus testijal on juurdepääs siseandmete struktuuridele.
Viimastel aastatel on termini hall-kasti testimine hakatud üldisemalt kasutama. Sellega kaasneb juurdepääs siseandmete struktuuridele ja algoritmidele, eesmärgiga kavandada test juhtumeid, kuid testimine kasutaja tasemel või must-kasti tasemel. Manipuleerimine sisendandmetega ja väljundivormindamine ei kvalifitseeru kui "Halli kasti", sest sisend ja väljund on selgelt väljaspool "musta kasti", et me kustume "tarkvara testimise all."

STAATILINE JA DÜNAAMILINE TESTIMINE

Staatilisel testimisel ei käivitata tarkvara vaid uuritakse ja loetakse ainult koodi. Dünaamilisel testimisel käivitatakse tarkvara ja kasutatakse seda.

KOODI TESTIMINE

Koodi testides staatilise valge-kastiga on ennast ära tasunud, sest vead leitakse kiiremini üles. See on ülesanne mis nõuab palju ettevalmistamist, et oleks produktiivne . Uurimused näitavad, et see aeg mis ettevalmistamise alla pannakse on ennast ära tasunud. Et tarkvara produktsioon oleks veel huvitavam on võimalus automatiseerida palju tööd. Tarkvara vaatab koodi üle, et see vastaks vastavatele standarditele ja juhtnööridele. Tarkvara on arenenud juba sinnamaani kui sa lubad tal kõiki tasandeid kontrollida siis on võimalus, et ta leiab vea kiiresti üles, kui see on standardisse kirja pandud. Need testid ei leia muidugi kõiki vigu üles kuid see annab testijale võimaluse minna sügavamale programmi sisse, et leida rohkem vigu üles.

ÜHILDUVUSE TESTIMINE

Ühilduvuse testimises uuritakse kas programmid omavahel korrektselt suhtlevad ja infot vahetavad teiste programmidega. Selline suhtlemine saab toimuda siis kui kaks programmi samaaegselt töötavad ühes arvutis või erinevates arvutites mis on interneti vaheldusel ühendatud omavahel. Testitakse ka erinevate platvormide peal pc ja mac ja ka erinevaid operatsiooni süsteemide peal nagu windows xp, 7, linux , mac os jne, ning ka veebibrausereid. Tarkvara testitakse ka nii, et ta töötaks ka uuemate operatsiooni süsteemidel.

KASUTATAVUSE TESTIMINE

Kasutuse testimine on vajalik, et kontrollida, kas kasutajaliidest on lihtne kasutada ja see on kergelt mõistetav kõigile inimestele. Tarkvara testija on esimene kes saab uut programmi või tarkvara kasutada. Kindlasti on see tal ka seda alguses raske kasutada ja sellest aru saada, kuid ta peab selle inimeste jaoks tegema kergelt kasutatavaks. Kui inimene on harjunud programmi ühtemoodi kasutama siis ta ka loodab, et saab mõnda teist programmi ka samamoodi kasutada, sellepärast ongi mõeldud välja kindlad standardi mida tuleb jälgida tarkvara loomisel.

TARKVARA TURVALISUSE TESTIMINE

Turvalisuse testimine on oluline tarkvara puhul, mis töötleb konfidentsiaalseid andmeid, et vältida süsteemi häkkimist või ründamist. Ükski arvuti süsteem ei ole turvaline. Alati võidakse süsteeme rünnata, et kas sealt saada kätte andmeid või neid enda kontrolli alla võtta. Tarkvara tootmise algusfaasis peab juba hakkama rõhku panema turvalisusele. See peab olema väga läbi mõeldud, disainitud ja testitud .

AUTOMATISEERITUD TESTIMINE JA TÖÖRIISTAD

Paljud tarkvaraarendajad kasutavad järjest rohkem automatiseeritud testimist, eriti testimise põhise arenduse juures. Testide kirjutamiseks on mitmeid tarkvara raamistikke, mis võimaldavad iga versioonihaldussüsteemi sisse kantud muudatuse järel automaatselt teste läbi viia. Automaatsed testimisprogrammid võivad olla kuni tuhat korda kiiremad kui manuaalne testimine. Testimise tööriistad on tarkvara testimisel ja vigade leidmisel olulised abivahendid . Testimise/vigade leidmise vahendid sisaldavad endas järgnevaid võimalusi: Programmi jälgijad, mis võimaldavad täielikku või osalist programmikoodi jälgimist, sealhulgas: Käsustiku simulaatorid, millega saab jälgida programmi kulgu masinakäskude tasemel. Tarkvara käskude samm-sammult läbimine lähtekoodi tasemel, mis võimaldab seada tingimustega murdepunkte. Automatiseeritud funktsionaalsed  kasutajaliidese  testimise vahendid. Stress testid, mis võimaldavad testida tarkvara jõudlust selle töötamise ajal. Jõudluse analüüsi ehk profileerimise tööriistad, mis aitavad esile tuua kuumkohti ja ressursside kasutamist.
ALFA JA BETA TESTIMINE
Alfa-testimine on simuleeritud või tegelik testimine arendaja juures, mida viivad läbi potentsiaalsed kasutajad/kliendid või iseseisev testimismeeskond. Alfa-testimist rakendatakse tihti vastvalminud tarkvara jaoks sisemise vastuvõtu testimise vormina, enne kui tarkvara läheb edasi beeta-testimisele.
Beeta-testimine toimub pärast alfa-testimist. Seda võib lugeda välimiseks kasutaja vastuvõtu testimiseks. Tarkvara versioone, mida nimetatakse beetaversioonideks, antakse vähestele inimestele väljaspool programmeerimise meeskonda. Need inimesed kontrollivad veelkord, et tootel oleks võimalikult vähe vigu. Mõnikord tehakse beetaversioonid täiesti avalikuks, et saada tagasisisidet võimalikult paljudelt inimestelt.
TESTI DOKUMENT
Tarkvara testimise plaani tegemine isegi väiksele projektile on suur tegemine ja seda ei tohi kergelt võtta. Dokumendi kavandamisel tuleks kaasata kõik testijad ja tähtsamad inimesed kes tarkvara arendamisel töötavad. Korraliku dokumendi valmistamine võib võtta aega mõni nädal või isegi kuid. See dokument teeb tarkvara testija töö lihtsamaks kui ta teab täpselt mida tal vaja on testida.
KOKKUVÕTE
Tarkvara loomisel kasutatakse mitut erinevat meetodit. Sammuti on ka tarkvara testmisel mitu erinevat võimalust. Tarkvara testija peab olema väga paindlik ja oma tööd hoolega tegema, muidu võivad mõned vead nägemata jääda, ning nende parandamine võib kalliks maksma minna. Oluline on ka testi dokumentide koostamine, et tarkvara testimine oleks lihtsam testijal. Kasutatakse ka automatiseerituid programme mis ise vaatavad programmi üle ja parandavad osad vead ära, mis on standardites kirjas. Turvalisuse testimine on oluline tarkvara puhul ja seda peaks teostama juba tarkvara ehitamise algusfaasis.
KASUTATUD ALLIKAMATERJALID

Software testing . (25.05.2012). [ http://en.wikipedia.org/wiki/Software_testing ]

Ron. Patton (25.05.2012) (2006). USA: Sams Publishing
12