1 1.1.1 Määratlus 3 Sissejuhatus Määratlus 2 1.1.1 Määratlus 4 Põhiidee Tarkvaraviga ehk puuk Tarkvaraviga ehk puuk (Am ingl bug putukas) on tarkvara omadus, mida tal ei tohiks olla. On kasutusel palju erinevaid sõnu tarkvaravea tähistamiseks, millest igaühel on oma varjund. Erinevates firmades, koolkondades jne on samal sõnal tihti erinev varjund. Viga on üldisem mõiste kui puuk.
1.1.1 Määratlus 5 7 Täpsem definitsioon Tarkvaraveaga on tegemist, kui kehtib vähemalt üks järgmistest tingimustest. Tarkvara ei vasta oma spetsifikatsioonile. Tarkvara jätab tegemata midagi, mida spetsifikatsioon talt nõuab. Tarkvara teeb midagi, mille spetsifikatsioon tal keelab. Tarkvara teeb midagi, mida spetsifikatsioon ei maini. Tarkvara ei vasta kasutaja nõudmistele. Raskesti mõistetav. Raske kasutada. Aeglane. Muud... Esimene puuk Aastal 1947 võtsid arvutid enda alla suuri ruume... Kord olid tehnikud jooksutamas Harvardi ülikoolis uut arvutit, kui see äkki lakkas töötamast. Tehnikud uurisid asja ja avastasid sügavalt arvuti sisemusest ülekandemehhanismide vahelt surnud ööliblika. Ilmselt oli ta lennanud süsteemi valguse ja soojuse peale ja, istunud ülekandemehhanismile, saanud elektrilöögist surma. Nii sündis computer bug. 6 8 Lõvikuninga juhtum, 1994 1995 Ajalugu, kurikuulsad tarkvaravigade juhtumid Lõvikuningas oli Disney seltsi esimene turule paisatud arvutimäng lastele. Reklaam ja läbimüük olid tohutud. Paraku ei läinud mäng enamikus kodudes käima. Tootjad olid testinud produkti ainult mõnede arvutimudelite peal, mille hulgas ei olnud kõige enam levinud mudeleid.
9 11 Intel Pentium protsessori ujukomaarvude jagamise viga, 1994 Tol aastal lasi Intel masstoodanguna välja Pentium protsessoreid, mille kiipi oli sisse ehitatud ebakorrektne ujukomaarvude jagamisalgoritm. Et algoritm töötas valesti ainult üksikutel juhtudel, ilmnes viga ainult väga töömahukate matemaatiliste arvutuste puhul. Seejuures enne kiibi väljalaskmist olid Inteli testijad selle vea avastanud, kuid juhatus leidis, et seda viga ei tasu parandama hakata ega sellest avalikult teatada; kui viga siiski välja tuli, püüdis Intel igati selle vea tõsidust tegelikust väiksemana kujutada; Patriot Missile Defense System, 1991 Sellenimeline oli tähesõdade vähendatud versioon, mida katsetati esmakordselt Lahesõja ajal Iraagi rakettide vastu. Üleskiidetud süsteem lasi läbi mitu raketti, millest üks tappis 28 USA sõdurit. Uurimus näitas, et viga oli tarkvaras. Seal peitus salakaval ajamääramise viga, mille tagajärjena polnud süsteem tundi peale käivitamist enam täpne. Saatusliku rünnaku ajal oli aga süsteem järjest töötanud üle 100 tunni. surve alla sattunud, soostus Intel vigased kiibid asendama, kuid ainult tingimusel, et ostja tõendab, et kiibil on see viga. Lõpuks Intel aga vabandas selle viisi pärast, kuidas ta vea ilmnemisel käitus, ja võttis enda kanda üle 400 miljoni dollari suurused kiipide asendamise kulud. 10 12 Mars Polar Lander, 1999 Mars Polar Lander oli kosmoseaparaat, mis kadus oma maandumisel Marsi pinnale. Tagantjärgi tehtud uurimustest selgus, et tõenäolisimalt põhjustas katastroofi üksainus vale bitt. Tarkvara oli testitud gruppides; iga grupp testis üht maandumise etappi. Üleminekud ühelt etapilt teisele olid jäetud testimata. Y2K, umbes 1974 1970ndatel aastatel oli mälu kallis ja see pani programmeerijaid igalt poolt mälu kokku hoidma. Sellepärast kujutati aastaarvu 2-kohalisena. Arvati, et need programmid on sajandivahetuseks ammu käibelt kadunud. Tegelikkuses tuli neid jõuga käibelt välja vahetada. Maailmas kokku nõudis see mitusada miljardit dollarit.
13 15 Spetsifikatsiooni ja disaini vead Vigade allikad, põhjused, hind Spetsifikatsioon/disain on informaalne, koosneb suuliselt edasiantavast infost. Spetsifikatsioon/disain pole küllalt põhjalikult tehtud. Spetsifikatsiooni/disaini otsuseid ei arutata küllaldaselt tarkvara kirjutava seltskonna seas. 14 16 Kodeerimise vead Vigade tekkimine etapiti Vigadest üle poole tekivad spetsifikatsiooni etapil, üle veerandi disaini etapil, ülejäänutest kolmveerand kodeerimisel. Tarkvaraarenduse seisukohalt on kodeerimine tarkvara tõlkimine masinloetavasse keelde. Vigade põhjused: tarkvara on väga keeruline; parandatav kood on halvasti dokumenteeritud; liginev tähtaeg kiirustab; lollus.
17 19 Kvaliteedi tagamise kulude liigid Vastavuse kulud (costs of conformance) kulud kontrollimiseks, kas puuke on. Mittevastavuse kulud (costs of non-conformance) kulud leitud puukide likvideerimiseks. Testimise alused Seesmised ebaõnnestumised (internal failures) puugid, mis avastatakse enne tarkvara väljalaskmist. Välimised ebaõnnestumised (external failures) puugid, mis avastatakse pärast tarkvara väljalaskmist. 18 1.2.1 Terminoloogia 20 Kulude seaduspärasused Iga viivitatud etapp vea avastamisel suurendab kõrvaldamise hinda 10 korda. Vastavuse kulud ja mittevastavuse kulud seesmiste ebaõnnestumiste tõttu on kokku väiksemad kui mittevastavuse kulud välimiste ebaõnnestumiste tõttu. Terminoloogia Kvaliteet on tasuta!
1.2.1 Terminoloogia 21 1.2.1 Terminoloogia 22 Üldmõisted Testimine (testing) on (tarkvara)toote kasutamine eesmärgiga leida selles puuke. Silumine (debugging) on toote vigade kõrvaldamine. Kvaliteeditagamine (quality assurance) tarkvaraarenduses hõlmab meetodite ja standardite loomist ja juurutamist parandamaks tarkvara tootmisprotsessi ja vähendada tekkivaid puuke. Kvaliteet (quality) on (tarkvara)toote kasutaja nõudmistele vastavuse mõõt. Ei ole sama mis töökindlus. Musta kasti meetod vs valge kasti meetod Tarkvara testimine on musta kasti meetodil (black-box testing), kui selle käigus ei kasutata programmi algteksti. Vastasel korral, st kui kasutatakse algteksti või selle olemasolust tulenevaid lisavõimalusi, on tarkvara testimine valge kasti meetodil (white-box testing). Testimist, milles algteksti kasutamine piirdub vaid koodi lugemisega selleks, et otsustada, missuguseid teste peaks jooksutama, nimetatakse mõnikord testimiseks halli kasti meetodil (gray-box testing). Verifitseerimine (verification) on protsess eesmärgiga kindlustada (tarkvara)toote vastavus spetsifikatsioonile. Valideerimine (validation) on protsess eesmärgiga kindlustada (tarkvara)toote vastavus kasutaja nõudmistele. Sertifitseerimine on kolmanda osapoole tegevus otsustamaks, kas toode vastab standarditele ja normdokumentidele. 1.2.1 Terminoloogia 23 Staatiline vs dünaamiline testimine Tarkvara testimine on staatiline (static testing), kui ei testita otseselt tarkvara funktsionaalsust. Vastasel korral, st kui testitakse otseselt tarkvara funktsionaalsust, on tarkvara testimine dünaamiline (dynamic testing).
1.2.2 Testimise osa erinevates tarkvaraarenduse mudelites 24 1.2.2 Testimise osa erinevates tarkvaraarenduse mudelites 26 Kirjuta-ja-paranda mudel Spetsifikatsioon on mitteformaalne, mis võib tekitada raskusi otsustamisel, mis on puuk ja mis mitte. Testimise osa erinevates tarkvaraarenduse mudelites Testimine toimub kogu tootearenduse protsessi jooksul ja sel on arendatavale tootele mõju. Testimisel leitud vead koodis lähevad parandamisele. Parandatud kood testitakse üle. Kas vead on parandatud? Ega pole uusi vigu sisse tehtud? 1.2.2 Testimise osa erinevates tarkvaraarenduse mudelites 25 1.2.2 Testimise osa erinevates tarkvaraarenduse mudelites 27 Suure paugu mudel Eraldi testijaid pole. Mõnikord siiski rakendatakse pärast arendusmeeskonna töö lõpetamist ja enne toote turule paiskamist testimist. Kuna spetsifikatsioon puudub, siis saab testida ainult vastavust kasutaja arvatavate nõudmistega. Testimisprotsessi lõpptulemuseks on avastatud probleemide aruanne, mis pannakse tootega kaasa. Kaskaadmudel On olemas tootespetsifikatsioon, seega saab (vähemalt ideaalis) täpselt öelda, mis on puuk ja mis ei ole. Testimine toimub arendusprotsessi lõpus ja avastatud vigu ei saa parandada.
1.2.2 Testimise osa erinevates tarkvaraarenduse mudelites 28 30 Pole võimalik programmi täielikult testida. Spiraalmudel Ühendab kõigi eelmiste mudelite head küljed. Võimalike sisendite hulk on liiga suur. Võimalike teede hulk läbi tarkvara on liiga suur. Spetsifikatsioonist arusaamine on subjektiivne. Kui kasutaja näeb puuki, võib testija öelda, et puuk asub kasutaja silmas. 29 31 Testimise põhitõed Testimine ei saa näidata, et puuke pole. Testimine saab puukide kohta näidata ainult nende leidumist.
32 34 Mida rohkem puuke leitakse, seda rohkem neid on. Programmeerijad on inimesed, neil on halvad päevad. Sama programmeerija kordab tihtipeale sama viga. Palju puuke võib olla tekkinud ühest algpõhjusest tootearenduse varajases staadiumis. Kehtib ka pöördväide: kui pika testimise peale puuke ei leia, on tarkvara tõenäoliselt puhas. Tarkvara testimine põhineb riskianalüüsil. Milliseid osi, millist käitumist testida? Kas leitud puuk kõrvaldada? Kas testimine lõpetada? 33 35 Kõiki leitud puuke ei kõrvaldata. Nn pestitsiidiparadoks (pesticide paradox): mida rohkem sa tarkvara testid, seda immuunsemaks tarkvara sinu testide suhtes muutub. Testijad peavad pidevalt looma uutlaadi teste. Selleks pole aega. See oleks liiga riskantne. Ühe puugi kõrvaldamine võib tekitada mitu uut, mis võivad aga jääda leidmata. See pole vaeva väärt. Puugi kõrvaldamise asemel viiakse spetsifikatsioon sellega vastavusse.
36 1.2.4 Testija ülesanne 38 Tootespetsifikatsioon pole kunagi lõplik. Turg muutub ühe toote arendamise jooksul tundmatuseni. Testimise planeerimisel tuleb sellega arvestada ja olla piisavalt paindlik. Testija ülesanne 37 1.2.4 Testija ülesanne 39 Testimisel ei kehti, et lõhkuda on kergem kui luua. Metoodiline testimine on niisama raske kui programmeerimine. Testija ei pea olema küps programmeerija, kuid see olla tuleb tugevalt kasuks. Testija eesmärk Testija eesmärk on leida puuke nii vara kui võimalik ja kanda hoolt selle eest, et nad läheksid kõrvaldamisele.