Tarkvara testimine

Allikas: Vikipeedia

Tarkvara testimine on protsess tarkvaraarenduses, mille käigus püütakse hinnata arvutitarkvara kvaliteeti.

Tarkvara testimine on kogemustel põhinev tehniline uurimine, mis viiakse läbi selleks, et arvestades konteksti, milles programm töötama peab, informeerida huvitatud osapooli tarkvara kvaliteedist. Testimise peamiseks tegevuseks on vea leidmise eesmärgiga programmi käivitamine.

Tarkvara kvaliteet on iga kasutaja jaoks subjektiivne. Seepärast ei saa testimisega kunagi garanteerida programmi täiuslikkust. Kasutaja kritiseerib või võrdleb programmi seisu või käitumist oma seisukohast lähtuvalt.

Tarkvara testimine annab ka objektiivse ja erapooletu ülevaate tarkvarast, et äripool saaks aru selle tarkvara arendusega kaasnevatest riskidest. Seda saab nimetada ka protsessiks, kus kontrollitakse tarkvaraprogrammi, rakenduse või toote vastavust projekteerimis- ja arendustegevuse määratud tehnilistele nõuetele, et see toimiks nii nagu vaja ja oleks rakendatav.

Tarkvara testimist saab rakendada arendamise protsessi igal hetkel. Kuid suurem osa testimisest toimub pärast nõuete määratlemist ja programmeerimise lõppemist. Testimise meetodid sõltuvad seega tarkvaraarenduse metoodikast.

Ülevaade[muuda | redigeeri lähteteksti]

Testimine ei tee kunagi täielikult kindlaks kõiki tarkvara vigu. Pigem kontrollitakse vastavust üldlevinud põhimõtetele ja mehhanismidele, mida keegi võiks veaohtlikuks pidada. Arvesse võetakse spetsifikatsioone, võrdlust sarnaste toodetega, võrdlust toote varasemate versioonidega, kavandatud ja oodatud eesmärke, kasutaja või klientide ootusi, asjakohaseid standardeid, kehtivaid seadusi või muid aluseid.

Igal tarkvaratootel on oma sihtgrupp. Näiteks arvutimängul on hoopis teistsugune sihtgrupp, kui panganduse tarkvaral. Seepärast juhul kui organisatsioon investeerib tarkvarasse, siis arvatavasti tuleb hinnata, kas toode on vastuvõetav lõppkasutajatele, sihtgrupile, tarkvara soetajatele ja firma osanikele. Tarkvara testimine ongi protsess, mis üritab anda seda hinnangut.

2002. aastal NIST-i (Rahvusvaheline Standardite ja Tehnoloogia Instituut) poolt läbi viidud uurimus näitab, et tarkvara vead maksavad USA majandusele 59,5 miljardit dollarit aastas. Rohkem kui kolmandikku sellest saaks vältida tõhusama testimisega.[1]

Ajalugu[muuda | redigeeri lähteteksti]

Glenford J. Myers esitles esimesena silumise eraldamist testimisest 1979. aastal.[2] Kuigi tema tähelepanu oli suunatud vigade leidmisele ("Edukas test on selline, mis leiab vea." [2][3]), illustreeris see tarkvaraarendajate soovi eraldada fundamentaalsed arendustegevused, näiteks silumine ja töökindluse kontrollimine. Dr. Dave Gelperin ja Dr. William C. Hetzel rühmitasid 1988. aastal tarkvara testimise faasid ja lõppeesmärgid järgmistesse staadiumitesse:

  • kuni 1956 – silumisele orienteeritud
  • 1957–1978 – demonstreerimisele orienteeritud
  • 1979–1982 – hävitamisele orienteeritud
  • 1983–1987 – hinnangule orienteeritud
  • 1988–2000 – ennetamisele orienteeritud

Tarkvara testimise teemad[muuda | redigeeri lähteteksti]

Käsitlusala[muuda | redigeeri lähteteksti]

Testimise peamine eesmärk on avastada tarkvara puudused, leida vead ning need parandada. Selline jälgimine ei ole lihtne. Testimisega ei saa kindlaks teha, et toode toimib nõuetekohaselt kõikidel tingimustel, vaid ainult, et ta ei tööta korralikult kindlatel tingimustel. Tarkvara testimine hõlmab koodi uurimist, samuti selle koodi täitmist erinevates keskkondades ning erinevatel tingimustel. Kontrollitakse, kas kood teeb seda, mida ta on määratud tegema. Praeguses tarkvaraarenduse kultuuris võib testimisorganisatsioon olla eraldi tarkvara arendusmeeskonnast. Tarkvara testijatel on mitmeid rolle. Testimisest saadud teabega saab parandada tarkvara välja töötamise üldist protsessi.

Funktsionaalne ja mittefunktsionaalne testimine[muuda | redigeeri lähteteksti]

Funktsionaalne testimine tähendab mingi kindla tegevuse või funktsiooni töötamise kontrollimist. Nõuded, mida funktsionaalne testimine peab kontrollima, on tavaliselt kirjas koodi dokumentatsioonis, kuigi mõned testimise metoodikad kasutavad ka testjuhtumeid või tagasisidet kasutajatelt. Funktsionaalsed testid vastavad küsimusele "kas kasutaja saab seda teha?" või "kas see funktsioon töötab?"

Mittefunktsionaalne testimine ei ole seotud kindlate tegevuste või funktsioonide testimisega, vaid omadustega nagu mastabeeritavus, jõudlus, käitumine teatud tingimustel või turvalisus. Mittefunktsionaalsed nõuded on sellised, mis peegeldavad toote kvaliteeti ja vastavust kasutaja vajadustele.

Vead ja puudused[muuda | redigeeri lähteteksti]

Mitte kõik tarkvara puudused ei ole põhjustatud programmeerimise vigadest. Üheks vigade allikaks on osa nõuete tähelepanuta jätmine, mistõttu arendaja võib teha vigu, sest arvestab vaid etteantud nõudeid. Puuduvad nõuded, millest vead tulenevad, on tihti mittefunktsionaalsed nõuded, näiteks tarkvara testitavus, mastabeeritavus, hallatavus, kasutatavus, jõudlus ning turvalisus.

Tarkvara vead tekivad järgmiselt: programmeerija teeb vea, mis satub tarkvara lähtekoodi. Kui see kood käivitatakse, siis teatud tingimustel töötab programm süsteemis valesti. Kõik vead koodis ei põhjusta tingimata tarkvara mittetoimimist, näiteks vead kasutamata koodis. Selline tarkvara ei pruugi siiski töötada, kui vahetatakse keskkonda. Näiteks kui kasutatakse tarkvara uuel riistvaral, muudetakse lähteandmeid või tekivad konfliktid muu tarkvaraga. Üksik viga võib põhjustada palju erinevaid sümptomeid.

Vigade leidmine varakult[muuda | redigeeri lähteteksti]

Arvatakse, et mida varem viga leitakse, seda lihtsam on seda parandada.[4] Järgnev tabel näitab, kuidas probleemi lahendamise ajakulu sõltub arendamise järgust, mil viga leiti. Näiteks, kui probleem nõuetes leitakse pärast väljalaset, siis selle parandamine võtab 10–100 korda rohkem aega, kui siis, kui see viga oleks leitud juba nõuete ülevaatamisel.

Millal viga leitakse
Nõuded Arhitektuur Ehitus Süsteemi testimine Väljalase
Millal viga tehakse Nõuded 5–10× 10× 10–100×
Arhitektuur 10× 15× 25–100×
Ehitus 10× 10–25×

Ühilduvus[muuda | redigeeri lähteteksti]

Tihti on tarkvara mitte töötamine põhjustatud ühilduvusprobleemidest mõne muu programmiga, näiteks uue OSi (operatsioonisüsteemi) või veebibrauseriga. Samuti võib tekitada probleeme uus käivituskeskkond, näiteks kui eelnevalt töölaual jooksnud programm tehakse ümber veebirakenduseks, mis peab töötama veebibrauseris.

Mitteühilduvus võib olla tingitud sellest, et programmeerija on kirjutanud või testinud tarkvara ainult ühe OSi versiooniga, tavaliselt sellega, mis oli tol hetkel kõige uuem väljalase. Nii võib tahtmatult juhtuda, et antud tarkvara ei toimi varasema või hilisema riist- või tarkvaraga, või ta ei ühildu täielikult mõne teise OSiga. Selliseid probleeme saab vältida abstraheerides OSi funktsioone moodulitesse või teekidesse.

Lähteandmete kombineerimine ja eeltingimused[muuda | redigeeri lähteteksti]

Üks fundamentaalne probleem tarkvara testimisel on see, et kõikvõimalikke algandmete ja eeltingimuste kombinatsioone ei ole võimalik testida, isegi lihtsate toodete puhul. See tähendab, et vigade arv tarkvara tootes võib olla väga suur ning vigu, mis tulevad esile väga harva, on raske testidega leida. Veel tähelepanuväärsem on see, et mittefunktsionaalsed kvaliteedi näitajad (kuidas peab tegema, mitte mida peab tegema) võivad olla vastuolulised. Näiteks kasutatavus, mastabeeritavus, jõudlus, ühilduvus ja veakindlus võivad olla väga subjektiivsed omadused. Mis ühele isikule sobib, ei pruugi olla vastuvõetav teise poolt.

Staatiline ja dünaamiline testimine[muuda | redigeeri lähteteksti]

Tarkvara testimisele on mitmeid lähenemisviise. Eelvaateid, tutvustusi või läbivaatamist nimetatakse staatiliseks testimiseks, programmeeritud koodi käivitamist etteantud testjuhtumitel nimetatakse dünaamiliseks testimiseks. Staatilise testimise võib praktikas mõnikord välja jätta (mida ka tihti paraku tehakse), samas dünaamiline testimine leiab aset siis, kui programm käivitatakse esimest korda.

Dünaamiline testimine võib alata enne, kui programm on 100% valmis, selleks et kontrollida eelkõige koodi osasid (mooduleid või teatud alamprogramme). Tavaliselt tehakse seda siluri (debugger) abil. Näiteks arvutustabeli programme testitakse oma olemuse tõttu suurel määral interaktiivselt, valemite või teksti muutmisel kuvatakse tulemused kohe.

Tarkvara verifitseerimine ja kinnitamine[muuda | redigeeri lähteteksti]

Tarkvara testimist kasutatakse seoses verifitseerimise ja kinnitamisega:

  • Verifitseerimine: kas me oleme tarkvara õigesti koostanud (st kas see vastab tehnilistele nõuetele)?
  • Kinnitamine: kas me ehitasime õige tarkvara (st kas see on see, mida klient soovib)?

Tarkvara testijate meeskond[muuda | redigeeri lähteteksti]

Tarkvara testimist viivad läbi tarkvara testijad. Kuni 1980. aastani kasutati mõistet "tarkvara testija" üldiselt, kuid hiljem muutus see vaadeldavaks eraldi elukutsena. Seoses aja ja eesmärkide muutustega on tekkinud tarkvara testimises erinevaid rolle: testimise juht, peatestija, testide projekteerija, testija, testide automatiseerimise arendaja ja testimise administraator.

Tarkvara kvaliteedi tagamine (software quality assurance (SQA))[muuda | redigeeri lähteteksti]

Tarkvara testimist võib vaadelda kui olulist osa tarkvara kvaliteedi tagamisel (SQA). Tarkvara menetluse spetsialistid ja audiitorid jälgivad arendustegevust ja muudavad arenduse protsesse vastavalt vajadustele, et lõpuks tarnitud tarkvaras oleks aktsepteeritaval määral ja võimalikult vähe puudusi.

Mis on "aktsepteeritav määr", sõltub tarkvara laadist. Näiteks vigasid arvutimängudes kannatatakse enam kui vigasid süsteemis, mis on tehtud lennukite juhtimiseks.

Kuigi testimine on tihedalt seotud kvaliteedi tagamisega, on testimise osakonnad tihti eraldiseisvad. Mõnes ettevõttes ei pruugi üldse olla SQA osakonda.

Tarkvara testimine on protsess, mille eesmärk on avastada puudused tarkvaras ja võrrelda arvutiprogrammi loodetud tulemusi tegelike tulemustega. Seevastu kvaliteedi tagamise (quality assurance) eesmärk on korraldada arendustegevust ja selle põhimõtteid, et vältida juba alguses defektide tekkimist.

Testimismeetodid[muuda | redigeeri lähteteksti]

Tarkvara testimise meetodid jagatakse traditsiooniliselt valge ja musta kasti testideks. Neid kahte lähenemist kasutatakse kirjeldamaks testija vaatenurka mingil testjuhtumil.

Valge kasti testimine[muuda | redigeeri lähteteksti]

Valge kasti (white-box) testimisel on testijal juurdepääs sisemistele andmestruktuuridele ja algoritmidele (ja koodile, mida rakendatakse).

Valge kasti testimise tüübid on:

  • Rakendusliideste (API) testimine – rakendust testitakse avalike ja privaatsete rakendusliideste kaudu
  • Koodi ulatus – luuakse teste, mis testivad koodi ulatust. Näiteks testi disainer võib luua testi, mille käigus kõiki avaldisi (lauseid/käske) programmis käivitatakse vähemalt ühe korra
  • Vigade süstimine – koodi ulatuse parandamine kontrollides, kas tarkvara töötab vigade lisamisel
  • Mutatsioonitestimine
  • Staatiline testimine – valge kasti testimine hõlmab kogu staatilist testimist

Testide ulatus[muuda | redigeeri lähteteksti]

Valge kasti testimismeetodeid võib kasutada ka selleks, et hinnata musta kasti testimismeetoditega loodud testide komplekti täiuslikkust. See võimaldab arendusmeeskonnal uurida harva testitud süsteemi osasid ning tagab, et kõige olulisemad funktsioonid on testitud.

Kaks harilikku koodi ulatuse vormi on:

  • Funktsiooni ulatus, millega uuritakse täidetud funktsioone
  • Avaldiste ulatus, millega uuritakse, mitu rida koodi testi käigus täideti

Mõlemad tagastavad koodi ulatuse mõõtarvu protsentides.

Musta kasti testimine[muuda | redigeeri lähteteksti]

Musta kasti (black-box) testimine kohtleb tarkvara kui "musta kasti", teadmata midagi selle sisemisest teostusest. Musta kasti testimismeetodite hulka kuuluvad: samaväärsuste jaotamine, piirväärtuste analüüs, paarikaupa testimine, "hägune" testimine, mudelipõhine testimine, uurimuslik testimine ja spetsifikatsioonidel põhinev testimine.

Spetsifikatsioonidel põhinev testimine[muuda | redigeeri lähteteksti]

Spetsifikatsioonidel põhineva testimise eesmärk on testida tarkvara funktsionaalsust vastavalt kehtivatele nõuetele. Seega testija sisestab andmed testobjekti ja näeb ainult väljundit. Selline testimistase nõuab tavaliselt põhjalikke testjuhtumeid, mis antakse testijale. Testija saab siis lihtsalt kontrollida, kas antud sisendi puhul väljundi väärtus (või käitumine) "on" või "ei ole" sama nagu eeldatav väärtus, mis on määratud testjuhtumis. Spetsifikatsioonil põhinev testimine on vajalik, kuid see ei ole piisav, et vältida teatud riske.

Eelised ja puudused[muuda | redigeeri lähteteksti]

Musta kasti testijal ei ole "sidemeid" koodiga ja testija ettekujutus on väga lihtne: koodis peavad olema vead. Kasutades põhimõtet: "Küsige ja te saate," leiavad musta kasti testijad vigu, kus programmeerijad neid ei leia. Kuid teisest küljest on musta kasti testimist kirjeldatud kui "jalutuskäiku pimedas labürindis ilma taskulambita", sest testija ei tea, kuidas testitav tarkvara tegelikult üles ehitati. Seepärast on olukordi, kus musta kasti testija kirjutab mitmeid testjuhtumeid, et kontrollida midagi, mida tegelikult saaks kontrollida ainult ühe testiga ja mõnda osa mustast kastist ei testita üldse.

Seega ühest küljest on musta kasti testimise eeliseks "väliselt mõjutamata arvamus", kuid teisest küljest "pimedas kompamine".

Halli kasti testimine[muuda | redigeeri lähteteksti]

Halli kasti (grey-box) testimisel on olemas juurdepääs sisemistele andmestruktuuridele ja algoritmidele testjuhtumite koostamisel, kuid testimine viiakse läbi kasutaja või musta kasti tasemel. Manipuleerimine sisendandmetega ja väljundivormindamine ei kvalifitseeru halli kasti testimisena, sest sisend ja väljund on selgelt väljaspool "musta kasti", milleks on testitav süsteem. Selline eristamine on eriti oluline, kui viiakse läbi integratsiooni testimine kahe erineva arendaja poolt kirjutatud mooduli vahel, kus testimiseks on saadaval ainult liidesed. Halli kasti testimise alla kuulub andmebaasi muutmine, sest tavaliselt ei saa kasutaja väljaspool testitavat süsteemi andmeid muuta. Halli kasti testimine võib hõlmata ka pöördprojekteerimist leidmaks näiteks piirväärtusi või tõrketeateid.

Testimise tasemed[muuda | redigeeri lähteteksti]

Teste grupeeritakse tihti selle järgi, millises tarkvara arenduse staadiumis neid lisatakse, või nende spetsiifilisuse järgi. Tarkvara arenduse aegseid testimise tasemeid kirjeldatakse SWEBOKis (Software Engineering Body of Knowledge). Need tasemed on ühiktestimine, lõimumise testimine ja süsteemi testimine. Kindlat protsessi mudelit ei kirjeldata.[5] Teisi testimise tasemeid liigitatakse testimise eesmärgi järgi.[6]

Testimise subjektid[muuda | redigeeri lähteteksti]

Ühiktestimine[muuda | redigeeri lähteteksti]

Next.svg Pikemalt artiklis Ühiktestimine

Ühiktestimisel vastab üks test konkreetsele koodi osale, tavaliselt funktsioonile. Objektorienteeritud keskkonnas testitakse klasside tasemel ja minimaalsesse testi kaasatakse ka konstruktorid ja destruktorid.

Ühikteste kirjutavad arendajad tavaliselt valge kasti stiilis, et kontrollida, kas mingi funktsioon töötab, nagu ette nähtud. Ühe funktsiooni kohta võib olla mitu testi, et kontrollida funktsiooni töötamist piirväärtustel või erinevaid koodi harusid. Ühiktestimisega ei saa tagada terve tarkvaratoote õigsust. Pigem kontrollitakse sellega, kas erinevad tarkvara osad töötavad üksteisest eraldi.

Lõimumise testimine[muuda | redigeeri lähteteksti]

Lõimumise testimisel kontrollitakse, kas komponentide vahelised liidesed vastavad tarkvara disainile. Tarkvara komponente võib integreerida järk-järgult või ühekorraga (big bang). Tavaliselt eelistatakse viimast, sest nii saab kiiremini leida ja parandada vigu liidestes.[7]

Lõimumise testimine paljastab defektid liidestes ja vastastikustes toimetes integreeritud komponentide (moodulite) vahel. Integreeritakse ja testitakse järjest suuremaid tarkvara komponentide gruppe, mis vastavad arhitektuurilise disaini elementidele, kuni kogu tarkvara töötab ühtse süsteemina.

Süsteemi testimine[muuda | redigeeri lähteteksti]

Testitakse täielikult integreeritud süsteemi, et kinnitada süsteemi nõuetele vastavust.

Süsteemi integratsiooni testimine[muuda | redigeeri lähteteksti]

Kinnitatakse, et süsteem on integreeritud mistahes välise või kolmanda osapoole süsteemiga, mis on määratletud süsteemi nõuetes.

Testimise eesmärgid[muuda | redigeeri lähteteksti]

Regressioonitestimine[muuda | redigeeri lähteteksti]

Next.svg Pikemalt artiklis Regressioonitestimine

Regressioonitestimise eesmärk on otsida vigu pärast koodi olulist muutmist. Täpsemalt otsitakse tarkvara regressioone ehk vanu vigu, mis võivad uuesti ilmuda. Sellised regressioonid tekivad siis, kui varem töötanud kood lakkab töötamast, nagu ette nähtud. Tavaliselt tekib regressioon soovimatu tagajärjena programmi muutmisel, kui uus tarkvara osa ei tööta enam koos vana osaga. Tavaline regressioonitestimise meetod on läbi viia varem kasutatud teste, et kontrollida, kas eelnevalt kindlaks tehtud rikked on taas esile kerkinud. Regressioonitestimise ulatus sõltub arendustegevuse etapist ja lisatud funktsionaalsuse kaalukusest. Testimine võib olla täielik, kui muudatused on riskantsed või neid tehakse arenduse hilistes järkudes, või osaline, kui muudatused tehakse vara või ei ole eriti riskantsed.

Vastuvõtu testimine[muuda | redigeeri lähteteksti]

Vastuvõtu testimine võib tähendada kahte asja:

  1. Viiakse läbi proovitest, et kontrollida, kas uus tarkvara komponent on vastuvõetav peamisse testimise protsessi, näiteks enne lõimumis- või regressioonitestimist
  2. Kliendi tehtud testimist, tihti tema enda arenduskeskkonnas ja riistvaral, nimetatakse kasutaja vastuvõtu testimiseks.

Alfa-testimine[muuda | redigeeri lähteteksti]

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[muuda | redigeeri lähteteksti]

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.

Mittefunktsionaalne tarkvara testimine[muuda | redigeeri lähteteksti]

Erimeetodite olemasolul saab testida tarkvara mittefunktsionaalseid aspekte. Erinevalt talitluslikust (funktsionaalsest) testimisest, mis kontrollib tarkvara toimimist (et tarkvara käitumine vastaks nõuetes määratletud käitumisele), kontrollitakse mittefunktsionaalse testimisega ka seda, et tarkvara töötab korralikult ka siis, kui ta saab vigaseid või ootamatuid sisendeid. Mittefunktsionaalne testimine on näiteks hägune testimine, mis on vigade süstimise vorm. Mittefunktsionaalsel testimisel, eriti tarkvara puhul, vaadatakse, kas vigaste või ootamatute sisendandmete puhul on sisendandmete kontroll ja vigade töötlemine piisavalt robustne. Mittefunktsionaalse testimise läbiviimiseks on mitmeid avatud lähtekoodiga ja vabavaralisi tööriistu kui ka kommertstarkvara.

Jõudlustestimine ja koormustestimine[muuda | redigeeri lähteteksti]

Jõudlustest kontrollib, kui kiiresti tarkvara töötab kindla koguse andmete või kasutajatega. Selle abil mõõdetakse ka teisi süsteemi parameetreid nagu mastabeeritavus, usaldusväärsus ja ressursside kasutamine. Koormustestimisega kontrollitakse, kas tarkvara suudab püsivalt töötada kindlal koormusel. Kui koormustestimist tehakse mittefunktsionaalselt, siis nimetatakse seda tihti vastupidavuse testimiseks.

Jõudlustestimise ja koormustestimise all mõistetakse tihti sama asja.

Stabiilsuse testimine[muuda | redigeeri lähteteksti]

Stabiilsuse testimine kontrollib, kas tarkvara on võimeline pidevalt töötama kindla ajaperioodi jooksul. Seda nimetatakse mõnikord vastupidavuse testimiseks.

Kasutatavuse testimine[muuda | redigeeri lähteteksti]

Kasutuse katsetamine on vajalik, et kontrollida, kas kasutajaliidest on lihtne kasutada ja mõista.

Turvalisuse testimine[muuda | redigeeri lähteteksti]

Turvalisuse testimine on oluline tarkvara puhul, mis töötleb konfidentsiaalseid andmeid, et vältida süsteemi häkkimist või ründamist.

Internatsionaliseerimine ja lokaliseerimine[muuda | redigeeri lähteteksti]

Internatsionaliseerimise ja lokaliseerimise testimisega tehakse kindlaks, et teise keelde tõlgitud või teise kultuuri jaoks kohandatud (teiste valuutade või ajavöönditega) tarkvara töötab ja on tehtud õigesti.

Probleemid, mis võivad tekkida tarkvara lokaliseerimisel:

  • Tarkvara lokaliseerides tõlgitakse sõnesid tihti kontekstist aru saamata ja tõlkija kasutab algsele sõnele valet vastet.
  • Tehnilise sõnavara kasutamine ei pruugi olla järjekindel, kui projekti tõlgib mitu inimest ilma koordineerimiseta või kui tõlkija on tähelepanematu.
  • Sõna-sõnalt tõlge võib mõnes keeles tunduda sobimatu, tehislik või liiga tehniline.
  • Lähtekoodi võib jääda tõlkimata sõnesid.
  • Mõned sõned luuakse automaatselt programmi käivitamise ajal ja tulemus võib seetõttu olla grammatiliselt või sisuliselt ebakorrektne või segadust tekitav.
  • Tarkvaras võidakse kasutada klahvikombinatsioone, kus klaviatuuri klahvidel ei ole algses keeles tähendust, aga sihtkeeles kasutatakse neid klahve teksti kirjutamisel.
  • Tarkvara ei pruugi toetada sihtkeele tähemärkide kodeerimissüsteemi.
  • Kirja tüüp ja suurus, mis võib sobida algses keeles, ei pruugi sobida sihtkeeles. Näiteks hiina, jaapani ja korea kirjad võivad liiga väiksena olla loetamatud.
  • Sõne, mis on sihtkeeles väga pikk, võib jääda osaliselt varjatuks või tekitada muid vigu.
  • Tarkvara ei toeta paremalt vasakule või vasakult paremale kirjutatava teksti kujutamist või kirjutamist.
  • Tarkvara kasutab pilte, millel on lokaliseerimata sõnesid.
  • Lokaliseeritud operatsioonisüsteemidel võivad olla erineva nimega konfiguratsioonifailid, keskkonnamuutujad ning erinevad kuupäeva ja valuuta vormingud.

Nende probleemide vältimiseks peab sihtkeelt tundev testija kontrollima kõiki tõlkeid programmis ja vaatama, et need oleksid loetavad, vastavalt kontekstile õigesti tõlgitud ja ei tekitaks tõrkeid.

Destruktiivne testimine[muuda | redigeeri lähteteksti]

Destruktiivsel testimisel üritatakse tekitada tõrkeid tarkvaraprogrammis või käivituskeskkonnas, et testida selle robustsust.

Testimise protsess[muuda | redigeeri lähteteksti]

Traditsiooniline koskmudel[muuda | redigeeri lähteteksti]

Tarkvara testimisele on omane tava, et see viiakse läbi iseseisva testijate grupi poolt pärast programmi funktsionaalse poole valmimist ja enne tarkvara kliendile edastamist. Sedasi toimimine lõpeb tihti sellega, et testimisele mõeldud aega kasutatakse puhvrina juhuks, kui projektis tekib viivitusi, kuid sel juhul väheneb testimisele pühendatud aeg.

Teine viis on testimist alustada projekti alguses ja seda jätkata projekti lõppemiseni.

Väle või ekstreemne arendusmudel[muuda | redigeeri lähteteksti]

Mõned uued arendusmudelid, näiteks väle või ekstreemne programmeerimine, kasutavad testimise põhist arendust. Selles protsessis kirjutavad arendajad kõigepealt ühiktestid (ekstreemses mudelis tihti paarisprogrammeerimisega). Alguses testid loomulikult ebaõnnestuvad. Kui koodi kirjutatakse juurde, siis läbitakse järjest rohkem teste. Testide komplekte uuendatakse pidevalt kui leitakse järjest uusi kasutusjuhtumeid ja vigade tekkimise võimalusi ja neid integreeritakse juba arendatud regressioonitestidega. Ühiktestid hoitakse ülejäänud lähtekoodiga koos ja tavaliselt põimitakse ehitamisprotsessiga (interaktiivsed testid tehakse eraldi käsitsi).

Testimistsükli näide[muuda | redigeeri lähteteksti]

Kuigi organisatsioonide vahel on erinevusi, on tüüpiline testimistsükkel järgmine:[8]

  • Nõuete analüüs. Katsetamine peaks algama tarkvaraarenduse elutsükli nõuete faasis. Sellel etapil töötavad testijad arendajatega, et teha kindlaks, millised tarkvara aspektid on testitavad ja milliste parameetritega need testid töötavad.
  • Testimise planeerimine. Testimise strateegia, plaani ja testimiskeskkonna loomine. Kuna testimisel on palju tegevusi, siis on plaan vajalik.
  • Testide arendamine. Tarkvara testimiseks kasutatavate protseduuride, stsenaariumite, testjuhtumite, andmekogude ja skriptide loomine.
  • Testide täitmine. Testijad käivitavad testid plaanide ja testimise dokumentide alusel ja seejärel teavitavad arendusmeeskonda leitud vigadest.
  • Testide aruandlus. Kui testimine on lõpetatud, loovad testijad mõõtarve ja teevad lõpliku aruande testimise kohta ja selle kohta, kas tarkvara on valmis väljastamiseks.
  • Testitulemuste või vigade analüüs. Seda teeb arendusmeeskond tavaliselt koos kliendiga, et otsustada, milliseid vigu tuleks parandada, millised tagasi lükata (st leiti, et tarkvara töötab korralikult) ja milliseid vigu parandada millalgi tulevikus.
  • Vigade uuesti testimine. Kui arendusmeeskond on üritanud viga parandada, siis testitakse seda uuesti.
  • Regressioonitestimine. Tihti luuakse teatud hulgast testidest koosnev väike testprogramm iga uue, muudetud või parandatud tarkvara versiooni kohta, et tagada, et viimased muudatused midagi ei lõhkunud ja et tarkvaratoode tervikuna töötab endiselt õigesti.
  • Testimise lõpetamine. Kui katse vastab lõpetamise kriteeriumitele, siis tegevused nagu väljundi püüdmine, õppetunnid, tulemused, logid ja projektiga seotud dokumendid arhiveeritakse ja neid kasutatakse viitena tulevastes projektides.

Automatiseeritud testimine[muuda | redigeeri lähteteksti]

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.

Testimise vahendid[muuda | redigeeri lähteteksti]

Testimise tööriistad ja silurid 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.
    • Programmi käskude samm-sammult läbimine lähtekoodi või masinkoodi tasemel, mis võimaldab seada tingimustega murdepunkte (breakpoint).
    • Koodi ulatuse aruandlus.
  • Vormindatud väljavõtted või sümbolitega silumise programmid, mis võimaldavad jälgida programmi muutujaid vigade ajal või valitud tööetapis.
  • Automatiseeritud funktsionaalsed kasutajaliidese testimise vahendid.
  • Jõudlustestid, 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.

Mõned nendest tööriistadest saab lõimida integreeritud arenduskeskkonda.

  • Üks regressioonitestimise tehnikaid on, et luuakse standardsed testid, millega võrreldakse programmi väljundit enne ja pärast programmi koodi tehtud muudatusi. Kui programmi väljundis on muutusi, kus neid ei peaks olema, siis on tegemist ootamatu funktsionaalsuse muutuse ehk "regressiooniga".

Mõõtmised tarkvara testimises[muuda | redigeeri lähteteksti]

Tavaliselt mõistetakse kvaliteedi all vaid vigade puudumist, täielikkust ja turvalisust, aga kvaliteet võib hõlmata ka tehnilisemaid nõudeid, mis on kirjeldatud ISO standardis ISO/IEC 9126, näiteks suutlikkus, töökindlus, porditavus, hooldatavus, ühilduvus ja kasutatavus.

On hulk tarkvara mõõtühikuid, mida sageli kutsutakse meetrikaks, mida kasutatakse tarkvara seisundi mõõtmiseks või testimise adekvaatsuse määramiseks.

Testimise tulemid[muuda | redigeeri lähteteksti]

Tarkvara testimise käigus tekib lisaks paremini töötavale tarkvarale ka muid saadusi.

Testimisplaan : Testi spetsifikatsiooni nimetatakse testimisplaaniks. Tarkvaraarendajatele on hästi teada, millised testimisplaanid täidetakse ja see teave on juhtkonnale ja arendajatele kättesaadav. See teeb tarkvaraarendajad koodi arendamisel ja lisamuudatuste tegemisel ettevaatlikumaks. Mõnedel ettevõtetel on testimisstrateegia, mis on kõrgema taseme dokument.

Testjuhtum : Testjuhtum on tarkvara testimise dokument, mis koosneb mingit tegevust kirjeldavatest sammudest, eeltingimustest, sisendist, väljundist, oodatud tulemustest ja tegelikust tulemusest. Täpsemalt defineeritult on kasutuslugu sisend ja oodatud tulemus. Osad testid on praktilised, näiteks "tingimusel x saadakse tulemus y", teised kasutusjuhendid kirjeldavad detailsemalt sisestusskeemi ja milliseid tulemusi võiks oodata. See võib vahel olla rida samme ühe oodatud tulemusega. Mõnikord kasutatakse neid samme eraldiseisvas testimisprotseduuris, et testida mitut testjuhtumit korraga. Valikulised väljad testjuhtumis on identifitseerimisnumber, testi samm või tegevuse järjekorra number, põhjalikkus, seotud nõuded, testi kategooria, autor, märkeruudud, kas test on automatiseeritav ja on automatiseeritud. Suuremad testjuhtumid võivad sisaldada eelnevalt vajalikke tingimusi, samme ja kirjeldusi. Testjuhtum peaks samuti sisaldama kohta tegelikuks tulemuseks. Neid samme saab säilitada tekstidokumendis, tabelis, andmebaasis või mõnes muus levinud andmekogus. Andmebaasis on võimalik näha ka varasemaid testitulemusi, kes neid tegi ja mis süsteemiga tulemusi genereeriti. Varasemad tulemused hoitakse tavaliselt eraldi tabelis.

Testskript : Testskript on protseduur või kood kasutaja tegevuste matkimiseks. Algselt tähendas testskript automatiseeritud regressioonitestimise tööriistade väljundit. Testskripte luuakse testjuhtumite põhjal vastavate tööriistade või programmidega.

Testide komplekt : Testjuhtumite kogu nimetatakse testide komplektiks. Testide komplekt sisaldab sageli ka üksikasjalikke juhiseid või eesmärke iga testjuhtumi jaoks. Kindlasti sisaldab see ka osa, kus testija teeb kindlaks süsteemi konfiguratsiooni, mida testimise ajal kasutatakse. Testide komplekt võib sisaldada ka eelnevalt vajalikke tingimusi, samme ja eelolevate testide kirjeldusi.

Testandmed : Tavaliselt kasutatakse mitmeid erinevaid väärtusi või andmeid, et testida mingi tarkvara osa funktsionaalsust. Kõik testitavad andmed ja keskkonna muudetavad komponendid salvestatakse eraldi failidesse. Samuti oleks kliendi jaoks kasulik ka toodet või projekti nende andmetega varustada.

Testimisrakendus : Tarkvara koos tööriistade ning sisendite, väljundite ja konfiguratsioonide näidistega on testimisrakendus.

Sertifikaadid[muuda | redigeeri lähteteksti]

On olemas mitmeid sertifitseerimise programme edendamaks tarkvara testijate ja kvaliteedi tagamise spetsialistide karjääre. Ühegi praegu väljastatava sertifikaadi omandamine ei nõua tegelikult tarkvara testimise oskuse demonstreerimist. Ükski sertifikatsioon ei põhine mõnel üldtunnustatud teabekogul. Seetõttu arvavad mõned, et testimise valdkond pole valmis sertifitseerimiseks.[9] Sertifitseerimine ise ei saa mõõta individuaalselt tootlikkust, oskusi või praktilisi teadmisi ega taga pädevust või professionaalsust testijana.[10]

Tarkvara testimise sertifitseerimise liigid

  • Eksamineerimisel põhinev sertifitseerimine – selleks on tarvis sooritada eksam, mida saab teha ka ise õppides, näiteks ISTQB või QAI
  • Haridusel põhinev sertifitseerimine – juhendatud sessioonid, kus iga kursus tuleb läbida, näiteks IIST (International Institute for Software Testing)

Testimise sertifikaadid

  • Certified Associate in Software Testing (CAST) – pakutav QAI poolt[11]
  • CATe – pakutav International Institute for Software Testing poolt[12]
  • Certified Manager in Software Testing (CMST) – pakutav QAI poolt[11]
  • Certified Software Tester (CSTE) – pakutav Quality Assurance Institute (QAI) poolt[11]
  • Certified Software Test Professional (CSTP) – pakutav International Institute for Software Testingu poolt[12]
  • CSTP (TM) (Australian Version) – pakutav K. J. Ross & Associates'i poolt[13]
  • ISEB – pakutav Information Systems Examinations Boardi poolt
  • ISTQB Certified Tester, Foundation Level (CTFL) – pakutav International Software Testing Qualification Boardi poolt[14][15]
  • ISTQB Certified Tester, Advanced Level (CTAL) – pakutav International Software Testing Qualification Boardi poolt[14][15]
  • TMPF TMap Next Foundation – pakutav Examination Institute for Information Science'i poolt[16]
  • TMPA TMap Next Advanced – pakutav Examination Institute for Information Science'i poolt[16]

Kvaliteedi tagamise sertifikaadid

  • CMSQ – pakutav Quality Assurance Institute'i (QAI) poolt[11]
  • CSQA – pakutav Quality Assurance Institute'i (QAI) poolt[11]
  • CSQE – pakutav American Society for Quality (ASQ) poolt[17]
  • CQIA – pakutav American Society for Quality (ASQ) poolt[17]

Vastuolulisus[muuda | redigeeri lähteteksti]

Mõned peamised tarkvara testimise vastuolud on:

Mida kujutab endast vastutustundlik tarkvara testimine?

"Kontekstipõhise" testimise pooldajad usuvad, et testimisel ei ole kindlaid reegleid. Pigem peaks testimisel kasutama eelnevaid kogemusi ja oskusi, mis antud olukorras kasuks tuleksid, või ise testimise meetodid välja mõelda.

Väle või traditsiooniline

Kas testijad peaksid õppima töötama pidevate muutuste ja ebakindluse keskel või peaksid nad taotlema protsessi "küpsust"? Väle testimine on saanud järjest populaarsemaks alates 2006. aastast peamiselt kaubanduslikes valdkondades. Samas valitsuse ja sõjaväelise tarkvara tarnijad kasutavad nii seda kui ka traditsioonilisi mudeleid.

Uurimuslik katse või ette kirjutatud

Kas testid peaksid olema kavandatud samal ajal kui neid teostatakse või tuleks need kavandada juba eelnevalt?

Käsitsi või automaatne testimine

Mõned autorid usuvad, et testide automatiseerimine on nii kallis arvestades saadavat kasu, et seda tuleks kasutada säästlikult. Testimispõhise arendamise seisukohast peaks kirjutama xUnit-tüüpi testid enne funktsionaalsuse kirjutamist. Teste võib võtta kui nõuete jäädvustamise ja rakendamise viisi.

Tarkvara projekteerimine või tarkvara rakendus

Kas testimine tuleks läbi viia ainult protsessi lõpus või ka selle vältel?

Kes valvab valvureid?

Idee seisneb selles, et iga jälgimisvorm on vastastikune, sest testi tegevus võib avalda mõju sellele, mida testitakse.

Vaata ka[muuda | redigeeri lähteteksti]

Viited[muuda | redigeeri lähteteksti]

  1. Software errors cost U.S. economy $59.5 billion annually NIST-i uurimus
  2. 2,0 2,1 Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 0-471-04328-1. 
  3. (1987) "Dr. Dobb's journal of software tools for the professional programmer". Dr. Dobb's journal of software tools for the professional programmer 12 (1–6). M&T Pub. 
  4. Kaner, Cem; James Bach, Bret Pettichord (2001). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley, 4. ISBN 0-471-08112-4. 
  5. http://www.computer.org/portal/web/swebok/html/ch5#Ref2.1
  6. http://www.computer.org/portal/web/swebok/html/ch5#Ref2.2
  7. Beizer, Boris (1990). Software Testing Techniques, Second, New York: Van Nostrand Reinhold, 21,430. ISBN 0-442-20672-0. 
  8. Pan, Jiantao (Spring 1999). Topics in Dependable Embedded Systems. Electrical and Computer Engineering Department, Carnegie Mellon University. 
  9. Kaner, Cem (2001). "NSF grant proposal to "lay a foundation for significant improvements in the quality of academic and commercial courses in software testing"" (pdf).
  10. Kaner, Cem (2003). "Measuring the Effectiveness of Software Testers" (pdf).
  11. 11,0 11,1 11,2 11,3 11,4 Quality Assurance Institute
  12. 12,0 12,1 International Institute for Software Testing
  13. K. J. Ross & Associates
  14. 14,0 14,1 "ISTQB".
  15. 15,0 15,1 "ISTQB in the U.S.".
  16. 16,0 16,1 EXIN: Examination Institute for Information Science
  17. 17,0 17,1 American Society for Quality