Tarkvara testimine

Tarkvara testimine on tarkvaraarenduse protsess, mille käigus püütakse hinnata tarkvara kvaliteeti.

Kitsamas mõttes tähendab tarkvara testimine tarkvara käivitamist/täitmist selles olevate vigade avastamiseks ja tarkvara vastavuse kontrollimist ettenähtud nõuetele. Laiemas mõttes on testimine tarkvara analüüsi protsess, mille käigus "püütakse leida erinevusi olemasolevate ja nõutud tingimuste vahel ning hinnata tarkvara omadusi". Testimine laiemas mõttes on tarkvaratoote planeerimise, ettevalmistuse ja hindamisega seotud elutsükli tegevusi hõlmav protsess.

Tarkvara testimine on paljuski kogemustel põhinev tehniline uurimine. Testides võetakse arvesse konteksti, milles programm töötama peab. Testimise eesmärk on saada programmi käivitades tulemuseks viga.

Testimine annab infot toote kvaliteedi kohta, kuid tarkvara kvaliteet on iga kasutaja jaoks subjektiivne. Seepärast ei saa testimisega kunagi tagada programmi täiuslikkust. Kasutaja kritiseerib või võrdleb programmi seisu või käitumist oma seisukohast lähtuvalt.

Tarkvara testimine püüab anda 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 ajal kindlaks määratud tehnilistele nõuetele, et see rakendus või toode toimiks nii, nagu vaja ja oleks rakendatav.

Tarkvara saab testida arendusprotsessi igal hetkel. Mõnikord kasutatakse teste juba arendusprotsessi algusjärgus, kuid sageli toimub suurem osa testimisest pärast nõuete määratlemist ja programmeerimise lõppemist. Testimise meetodid sõltuvad seega tarkvaraarenduse metoodikast.

Ülevaade

Testimine ei tee kunagi täielikult kindlaks kõiki tarkvaratoote vigu, sest kõigi detailide ülekontrollimine on liiga ajamahukas ja kulukas ettevõtmine. Pigem kontrollitakse tarkvara vastavust üldlevinud põhimõtetele ja vaadatakse üle selle veaohtlikumad kohad. Arvesse võetakse spetsifikatsioone, võrdlust sarnaste toodetega, võrdlust toote varasemate versioonidega, kavandatud ja oodatud eesmärke, kasutajate või klientide ootusi, asjakohaseid standardeid, kehtivaid seadusi või muid aluseid.

Igal tarkvaratootel on oma sihtrühm. Näiteks arvutimängude sihtrühm erineb oluliselt pangandustarkvara omast. Seepärast peab organisatsioon tarkvarasse investeerides silmas pidama nii lõppkasutaja (sihtrühma, tarkvara soetaja) kui ka firma osanike vajadusi. Tarkvara testimise käigus püütakse välja selgitada, kas toode vastab kokkulepitud nõuetele ning on kooskõlas kliendi või lõppkasutaja vajadustega.

2002. aastal osutas NIST-is (The National Institute of Standards and Technology, USA riiklik standardite ja tehnoloogia instituut) tehtud uuring, et tarkvaravead lähevad USA majandusele maksma 59,5 miljardit dollarit aastas ja et rohkem kui kolmandiku sellest summast saaks kokku hoida tõhusama testimise abil.

Ajalugu

Dr David Gelperin ja dr Bill Hetzel jagasid 1988. aastal tarkvara testimise ajaloo viide arenguetappi, võttes jaotuse aluseks erinevatel perioodidel domineerinud tarkvara testimise mudelid.

–1956 silumine

Sellel perioodil koondus tähelepanu riistvara töökindlusele. Esimestes testimist käsitlevates artiklites kirjutati riistvarakomponentidest. Programmeerimisse suhtuti lihtsalt: programm kirjutati valmis ja seejärel kontrolliti, kas see töötab. Programmi silumisel ja testimisel oli üldjoontes sama tähendus.

1957–1978 demonstreerimine

1957. aastal kirjutas Charles Baker arvustuse Dan McCrackeni raamatule "Digital Computer Programming". Arvustuses tegi ta vahet silumisel (programm peab tõrgeteta töötama) ja testimisel (programm peab lahendama ülesande). Kirjutatud programmide hulga, keerukuse, kulukuse ja programmeerimisega seotud majanduslike riskide kasvades hakati üha enam tähtsustama testimist, mis tähendas probleemide tuvastamist enne toote lõplikku üleandmist. Nii silumine kui ka testimine hõlmasid sel perioodil vea märkamist, selle asukoha leidmist ja vea parandamist. Olulisim oli programm tööle saada.

1979–1982 hävitamine

Glenford J. Myers juhtis 1979. aastal ilmunud teoses "The Art of Software Testing" esimest korda tähelepanu silumise ja testimise erinevusele. Kuigi tema tähelepanu oli suunatud programmi katki tegemisele (breakage testing) ("Edukas test leiab peidus olnud vea." ), illustreeris see tarkvaraarendajate soovi eraldada fundamentaalsed arendustegevused (nt silumine) töökindluse kontrollimisest (verifitseerimisest). Myers arvas, et kui testija loobub programmi töökindluse demonstreerimisest ning keskendub hoopis vigade otsimisele, siis tõenäoliselt leiabki ta üles rohkem vigu.

1983–1987 hinnangu andmine

1983. aastal avaldati "Guideline for Lifecycle Validation, Verification, and Testing of Computer Software".

1988–... ennetamine

Tarkvara testimise teemad

Käsitlusala

Testimise peamine eesmärk on tarkvara vigade ja puuduste avastamine. See ülesanne ei ole lihtne, kuna testimisega pole võimalik kindlaks teha toote nõuetekohast toimimist kõikidel tingimustel, vaid ainult kõrvalekaldeid korralikust töötamisest kindlatel tingimustel. Tarkvara testimine hõlmab koodi uurimist ja täitmist erinevates keskkondades ning erinevatel tingimustel. Kontrollitakse koodi eesmärgipärast toimimist. Tänapäevases tarkvaraarenduse kultuuris võivad testimisorganisatsioon ja tarkvara arendusmeeskond olla eraldiseisvad üksused. Tarkvara testijatel on mitmeid rolle. Testimisest saadud teabega saab parandada tarkvara väljatöötamise üldist protsessi.

Funktsionaalne ja mittefunktsionaalne testimine

Funktsionaalne testimine tähendab mingi kindla tegevuse või funktsiooni töötamise kontrollimist. Funktsionaalse testimisega kontrollitavad nõuded on tavaliselt kirjas koodi dokumentatsioonis, kuigi mõned testimismetoodikad kasutavad ka testjuhtumeid või kasutajate tagasisidet. Funktsionaalsed testid vastavad küsimustele "Kas kasutaja saab seda teha?" ja "Kas see funktsioon töötab?".

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

Vead ja puudused

Tarkvaratoote puuduste põhjuseks ei ole üksnes programmeerimisvead, vaid neid võivad põhjustada ka näiteks puudulikult kirjeldatud nõuded, mille põhjal tarkvara luuakse. Sageli on kirjeldamata jäetud või puudulikult kirjeldatud tarkvara mittefunktsionaalsed nõuded, näiteks testitavus, skaleeritavus, hallatavus, kasutatavus, jõudlus ja turvalisus.

Tarkvaravead võivad tekkida järgmiselt: programmeerija eksimuse tulemusena tekib viga tarkvara lähtekoodi. Teatud tingimustel läheb sellise koodi käivitamisel süsteem katki või töötab valesti. Kõik programmeerimisvead ei pruugi mõjutada tarkvara toimimist, näiteks võib viga sisaldav tarkvara töötada laitmatult, kui vigast koodilõiku programmis tegelikult ei kasutatagi. Viga võib avalduda, kui käivitamise keskkond (näiteks riistvaraplatvorm või tarkvara, millega programm suhtleb) või tööks kasutatavad andmed muutuvad ja seetõttu vigast koodi kasutama hakatakse. Üks viga võib avalduda mitmel eri moel.

Vigade leidmine varakult

Arvatakse, et mida varem viga leitakse, seda odavam ja lihtsam on seda parandada. Järgnev tabel näitab, kuidas probleemi lahendamise ajakulu sõltub arendamise järgust, mil viga leiti. Näiteks kui nõuetes sisalduvat viga märgatakse alles pärast toote väljalaset, siis võtab selle parandamine 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	1×	3×	5–10×	10×	10–100×
	Arhitektuur	–	1×	10×	15×	25–100×
	Ehitus	–	–	1×	10×	10–25×

Ühilduvus

Tihti põhjustavad tarkvaratõrkeid ühilduvusprobleemid, mis tähendab tarkvara sobimatust mõne muu programmiga, näiteks operatsioonisüsteemi või veebibrauseriga. Samuti võib tekitada probleeme muutunud käivituskeskkond, näiteks kui eelnevalt töölaual töötanud programm muudetakse veebibrauseris töötavaks veebirakenduseks.

Mitteühilduvus võib olla tingitud sellest, et tarkvara on testitud ainult ühe OSi versiooniga, tavaliselt kõige uuema väljalaskega. Nii võib juhtuda, et tarkvara ei toimi varasema või hilisema riist- või tarkvaraga või ta ei ühildu täielikult mõne teise OSiga. Selliseid riske on võimalik maandada, jagades OSi funktsioonid moodulitesse või teekidesse.

Lähteandmete kombineerimine ja eeltingimused

Üks tarkvara testimise põhiprobleeme on algandmete ja eeltingimuste kombinatsioonide paljusus, mille täismahus testimine võib isegi lihtsa tarkvara puhul olla liiga keeruline või kulukas. Sellest tulenevalt ei pruugi testid harva avalduvaid vigu üles leida ja testimisest hoolimata võib vigade arv tarkvaratootes olla suur. Mittefunktsionaalsed kvaliteedinäitajad (kuidas peab tegema, mitte mida peab tegema) ei pruugi olla kõigile üheselt mõistetavad, näiteks kasutatavus, skaleeritavus, jõudlus, ühilduvus ja veakindlus.

Staatiline ja dünaamiline testimine

Tarkvara testimise meetodeid on palju.

Staatilisel testimisel tarkvara ei käivitata, vaid analüüsitakse tarkvara lähtekoodi, vaadatakse läbi dokumentatsiooni või kontrollitakse koodi vastavust dokumentatsioonile. Staatiline testimine tuvastab tarkvara puudused (inglise keeles defect) varakult. Dünaamiline testimine tähendab koodi käivitamist ja selle toimimise jälgimist. Dünaamiline testimine tuvastab peamiselt tõrkeid (inglise keeles failure).

Staatilise testimise võib praktikas mõnikord välja jätta (mida ka tihti paraku tehakse), dünaamiline testimine leiab aset igal programmi käivitatamisel. Dünaamiline testimine võib alata enne programmi täielikku valmimist, et kontrollida eelkõige koodi osasid (mooduleid või alamprogramme). Tavaliselt tehakse seda siluri (debugger) abil. Näiteks arvutustabeli programme testitakse nende olemuse tõttu suurel määral interaktiivselt, valemite või teksti muutmisel kuvatakse tulemused kohe.

Tarkvara verifitseerimine ja valideerimine

Tarkvara testimist kasutatakse seoses verifitseerimise ja valideerimisega.

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

Tarkvara testijate meeskond

Tarkvara testimist viivad läbi tarkvara testijad. 1980. aastani kasutati mõistet "tarkvaratestija" üldiselt, kuid hiljem muutus see tegevus eraldi elukutseks. Aja jooksul muutunud eesmärkide tõttu on tarkvara testimises tekkinud erinevaid rolle: testimise juht, peatestija, testide projekteerija, testija, testide automatiseerimise arendaja ja testimise administraator.

Tarkvara kvaliteedi tagamine

Tarkvara testimist võib vaadelda tarkvara kvaliteedi tagamise (inglise keeles Software Quality Assurance ehk SQA) olulise osana. Tarkvara menetluse spetsialistid ja audiitorid jälgivad arendustegevust ja muudavad arendusprotsesse vastavalt vajadustele minimeerimaks tarnitavas tarkvaras esinevaid puudusi nii, et nende hulk mahuks aktsepteeritava määra sisse. "Aktsepteeritav määr" sõltub tarkvara otstarbest, näiteks arvutimängus olevad vead on ohutumad lennujuhtimissüsteemi vigadest.

Kuigi testimine on tihedalt seotud kvaliteedi tagamisega, on testimisosakonnad tihti eraldi üksused. 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 tulemusi loodetud tulemustega. Kvaliteedi tagamise (quality assurance) eesmärk on korraldada arendustegevust ja selle põhimõtteid, et vältida defektide teket juba arendusprotsessi alguses.

Testimismeetodid

Tarkvara testimise meetodid jagatakse traditsiooniliselt valge ja musta kasti testideks. Esimesel juhul uuritakse koodi ja testid tehakse programmi teksti alusel. Teisel juhul ei süveneta programmi teksti, vaid testitakse programmi funktsionaalsust.

Valge kasti meetod

Valge kasti (white-box) meetodi puhul on testijal juurdepääs sisemistele andmestruktuuridele ja algoritmidele (ja rakendatavale koodile).

Valge kasti testimise tüübid on:

• rakendusliideste (lühendatult API, Application Program Interface) testimine – rakendust testitakse avalike ja privaatsete rakendusliideste kaudu;
• testimise katvus – luuakse teste, mis testivad koodi teatud ulatuseni. Näiteks testi disainer võib luua testi, mille käigus kõiki programmi avaldisi (lauseid/käske) käivitatakse vähemalt üks kord;
• vigade lisamine – seda meetodit kasutatakse arvutisüsteemide töökindluse hindamiseks;
• mutatsioonitestimine;
• staatiline testimine – valge kasti testimine hõlmab kogu staatilist testimist.

Testide ulatus

Valge kasti testimismeetodeid võib kasutada ka selleks, et hinnata musta kasti testimismeetoditega loodud testide komplekti täiuslikkust. See võimaldab arendusmeeskonnal uurida süsteemi harvem testitud osi ning aitab tagada, 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 meetod

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

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

Musta kasti testija ei näe koodi ja ta eeldab, et koodis on kindlasti vead. Kasutades põhimõtet: "Küsige ja te saate", leiavad musta kasti testijad vigu seal, kus programmeerijad neid otsidagi ei oska. Teiselt poolt on musta kasti testimist kirjeldatud kui "pimeda labürindi läbimist ilma taskulambita", sest testija ei tea, kuidas on testitav tarkvara tegelikult üles ehitatud. Seepärast on olukordi, kus musta kasti testija kirjutab mitmeid testjuhtumeid, et kontrollida mõnd lihtsat asja, mida koodi teades saaks kontrollida ainult ühe testiga, ja mõni osa mustast kastist jääb üldse testimata.

Musta kasti testimise eeliseks on "koodist mõjutamata arvamus", kuid puuduseks "pimedas kompamine".

Halli kasti meetod

Halli kasti (grey-box) testimisel on programmi sisemine ehitus osaliselt teada, nt selle andmestruktuurid ja algoritmid, kuid testimine viiakse läbi kasutaja või musta kasti tasemel. Sisendandmetega manipuleerimine ja väljundivormindamine ei ole halli kasti testimine, sest sisend ja väljund on väljaspool "musta kasti" ehk testitavat süsteemi. Selline eristamine on eriti oluline integratsioonitestimises, kui kontrollitakse liideste põhjal, kas nt kahe erineva arendaja kirjutatud moodulid ühilduvad. 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

Teste rühmitatakse tihti selle järgi, millises tarkvaraarenduse staadiumis neid lisatakse, või nende spetsiifilisuse järgi. Tarkvaratehnika IEEE juhendmaterjalis "Guide to the Software Engineering Body of Knowledge" (SWEBOK) kirjeldatakse tarkvara testimise tasemeid. Need tasemed on ühiktestimine, integratsioonitestimine ja süsteemitestimine. Kindlat protsessi mudelit ei kirjeldata. Teisi testimise tasemeid liigitatakse testimise eesmärgi järgi.

Testimise subjektid

Ühiktestimine

 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 nii nagu vaja. Ü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.

Integratsioonitestimine

Integratsioonitestimisel kontrollitakse komponentidevaheliste liideste vastavust tarkvara disainile ning kõigi komponentide ühilduvust üksteisega. Tarkvara komponente võib integreerida järk-järgult või ühekorraga (big bang). Tavaliselt eelistatakse viimast, sest nii saab liideste vigu kiiremini leida ja parandada.

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

Süsteemitestimine

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

Süsteemi integratsiooni testimine

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

Regressioonitestimine

 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 avalduda. Sellised regressioonid tekivad siis, kui varem töötanud kood lakkab vajalikul moel töötamast. Tavaliselt on regressioon programmi muutmise soovimatu kõrvalnähe, mis avaldub selles, et uus tarkvara osa ei hakka koos vana osaga tööle. Ühe regressioonitestimise meetodina kasutatakse varasemaid teste, et kontrollida, ega eelnevalt kindlaks tehtud vead pole 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 lõppjärgus, või osaline, kui muudatused tehakse algusjärgus või kui need ei ole eriti riskantsed.

Vastuvõtutestimine

Vastuvõtutestimine 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. testitakse tellija/kliendi vaatepunktist lähtudes, tihti tema enda arenduskeskkonnas ja riistvaral, hinnatakse, kas tarkvara on kasutuselevõtuks valmis. Seda testimist nimetatakse kasutaja vastuvõtu testimiseks.

Alfatestimine

Alfatestimine on simuleeritud või tegelik testimine arendaja juures, seda teostavad potentsiaalsed kasutajad/kliendid või iseseisev testimismeeskond. Alfatestimist rakendatakse arendaja organisatsioonis vastvalminud tarkvara vastuvõtmiseks. Pärast alfatestimist läheb tarkvara edasi beetatestimisele.

Beetatestimine

Kui alfatestid õnnestuvad, saadetakse valmistarkvara beetatestimisse. Tarkvara versioone, mida nimetatakse beetaversioonideks, antakse vähestele inimestele väljaspool programmeerimise meeskonda. Need inimesed kasutavad vastvalminud tarkvaratoodet ja annavad kasutuskogemuse kohta arendajatele tagasisidet. Mõnikord tehakse beetaversioonid täiesti avalikuks, et saada tagasisisidet võimalikult paljudelt inimestelt.

Mittefunktsionaalne testimine

Erimeetodite olemasolul saab testida tarkvara mittefunktsionaalseid aspekte. Erinevalt talitluslikust (funktsionaalsest) testimisest, mis kontrollib tarkvara toimimist (ehk seda, kas tarkvara käitumine on kooskõlas dokumenteeritud ja dokumenteerimata nõuetega), kontrollitakse mittefunktsionaalse testimisega näiteks seda, kas tarkvara töötab korralikult ka siis, kui ta saab vigaseid või ootamatuid sisendeid. Mittefunktsionaalne testimine on näiteks hägune testimine, mis on sihiliku 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 nii mitmeid avatud lähtekoodiga ja vabavaralisi tööriistu kui ka kommertstarkvara.

Jõudlustestimine ja koormustestimine

Jõudlustest kontrollib tarkvara töökiirust määratud hulga andmete või kasutajatega, kuid sellega mõõdetakse ka teisi süsteemi parameetreid, näiteks skaleeritavust, töökindlust ja ressurssikasutust. Koormustestimisega kontrollitakse tarkvara suutlikkust töötada püsivalt kindlal koormusel. Mittefunktsionaalset koormustestimist nimetatakse tihti vastupidavuse testimiseks.

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

Stabiilsuse testimine

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

Kasutatavuse testimine

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

Turvalisuse testimine

Turvalisuse testimine on oluline tarkvara puhul, mis töötleb konfidentsiaalseid andmeid. Sel juhul peab süsteem vastu pidama häkkimisele ja küberrünnakule.

Internatsionaliseerimine ja lokaliseerimine

Internatsionaliseerimise ja lokaliseerimise testimisega kontrollitakse, kas teise keelde tõlgitud või teise kultuuri jaoks kohandatud (nt muudetud valuuta või ajavööndiga) tarkvara töötab ja kas tõlkevasted on õiged.

Probleemid, mis võivad tekkida tarkvara lokaliseerimisel:

• kui tarkvara lokaliseerides peab tõlkima kontekstita esitatud sõnu, võib tõlkesse sattuda valesid tõlkevasteid;
• kui projekti tõlgib mitu inimest ilma koordineerimiseta või kui tõlkijal ei ole süsteemset ülevaadet terminitest, võib tehnilise sõnavara kasutamine olla ebaühtlane;
• sõnasõnalised tõlkevasted võivad sihtkeeles tunduda sobimatute, tehislike või liiga tehnilistena;
• 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õivad olla kasutusel klahvid, mida saab kasutada ainult lähtekeele klahvipaigutusega klaviatuuril (nt USA klaviatuur), sest sihtkeele klahvipaigutus on teistsugune (nt Eesti klaviatuur);
• tarkvara ei pruugi toetada sihtkeele tähemärkide kodeerimissüsteemi;
• kirja tüüp ja suurus, mis sobivad algses keeles, ei pruugi sobida sihtkeeles. Näiteks liiga väikese suurusega hiina, jaapani ja korea kirjad võivad olla loetamatud;
• sihtkeelne sõne on etteantud dialoogiboksi või tekstivälja jaoks liiga pikk;
• 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 programmis olevaid tõlkeid ja veenduma, et need oleksid loetavad, vastavalt kontekstile õigesti tõlgitud ja et need ei tekitaks tõrkeid.

Destruktiivne testimine

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

Testimise protsess

Traditsiooniline koskmudel

Tarkvara testimisele on omane tava, et seda teeb iseseisev testijate rühm 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

Mõned uued arendusmudelid, näiteks väle või ekstreemne programmeerimine, kasutavad testimisepõ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 töö käigus, kui leitakse uusi kasutusjuhtumeid ja vigade tekkimise võimalusi, ning need 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

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

• 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 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 sellised tegevused nagu väljundi püüdmine, õppetunnid, tulemused, logid ja projektiga seotud dokumendid arhiveeritakse ja neid kasutatakse viitena tulevastes projektides.

Automatiseeritud testimine

Paljud tarkvaraarendajad kasutavad järjest rohkem automatiseeritud testimist, eriti testimispõhise arenduse juures. Testide kirjutamiseks leidub tarkvaralisi raamistikke, mis võimaldavad iga versioonihaldussüsteemi sisse kantud muudatuse järel automaatselt teste läbi viia.

Testimisvahendid

Testimise tööriistad ja silurid on tarkvara testimisel ja vigade leidmisel olulised abivahendid. Testimise/vigade leidmise vahendid sisaldavad järgmisi 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 selliseid muutusi, mida seal ei peaks olema, siis on tegemist ootamatu funktsionaalsuse muutuse ehk "regressiooniga".

Mõõtmised tarkvara testimises

Tavaliselt peetakse kvaliteetseks sellist tarkvara, milles ei ole vigu, mis on terviklik ja turvaline, aga kvaliteet võib hõlmata ka selliseid tehnilisi nõudeid nagu suutlikkus, töökindlus, porditavus, hooldatavus, ühilduvus ja kasutatavus. Neid on kirjeldatud ISO standardis ISO/IEC 9126.

Tarkvara meetrikaks nimetatakse mõõtühikuid, mida kasutatakse tarkvara seisundi mõõtmiseks või testimise adekvaatsuse määramiseks.

Testimise tulemid

Tarkvara testimise tulemuseks on paremini töötav tarkvara ja suur kogus tarkvaraga seotud materjale.

Testimisplaan

Testi spetsifikatsiooni nimetatakse testimisplaaniks. Tarkvaraarendajatele on hästi teada, millised testimisplaanid täidetakse, ning 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. Osad testid on praktilised, näiteks "tingimusel x saadakse tulemus y", teised kasutusjuhendid kirjeldavad detailsemalt sisestusskeemi ja oodatavaid tulemusi. See võib olla rida samme ühe oodatud tulemusega. Mõnikord kasutatakse neid samme eraldiseisvas testimisprotseduuris, et testida mitut testjuhtumit korraga. Testjuhtumi valikulised väljad 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 tegeliku tulemuse jaoks. Neid samme saab säilitada tekstidokumendis, tabelis, andmebaasis või mõnes muus levinud andmekogus. Andmebaasis on võimalik näha ka varasemaid testitulemusi, nende tegijaid ja seda, mis süsteemiga tulemusi genereeriti. Varasemad tulemused hoitakse tavaliselt eraldi tabelis.

Testskript – 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

Tarkvara testijate ja kvaliteedi tagamise spetsialistide karjääri edendamiseks on loodud sertifitseerimisprogramme, kuid ühegi praegu väljastatava sertifikaadi omandamine ei nõua tegelikult tarkvara testimise oskuse demonstreerimist ning ükski sertifikatsioon ei põhine mõnel üldtunnustatud teabekogul. Seetõttu on avaldatud arvamust, et testimise valdkond pole sertifitseerimiseks valmis. Sertifitseerimine ei saa mõõta individuaalselt tootlikkust, oskusi või praktilisi teadmisi ega taga testija pädevust või professionaalsust.

Tarkvara testimise sertifitseerimise liigid

• Eksamineerimisel põhinev sertifitseerimine – läbimiseks on tarvis sooritada eksam, mida saab teha ka iseseisvalt õppides, vaata näiteks ISTQB või QAI.
• Haridusel põhinev sertifitseerimine – juhendatud sessioonid, kus iga kursuse läbimine on kohustuslik, vaata näiteks IIST (International Institute for Software Testing).

Testimise sertifikaadid

• Certified Associate in Software Testing (CAST) – pakub QAI
• CATe – pakub International Institute for Software Testing
• Certified Manager in Software Testing (CMST) – pakub QAI
• Certified Software Tester (CSTE) – pakub Quality Assurance Institute (QAI)
• Certified Software Test Professional (CSTP) – pakub International Institute for Software Testing
• CSTP (TM) (Australian Version) – pakub K. J. Ross & Associates
• ISEB – pakub Information Systems Examinations Board
• ISTQB Certified Tester, Foundation Level (CTFL) – pakub International Software Testing Qualification Board
• ISTQB Certified Tester, Advanced Level (CTAL) – pakub International Software Testing Qualification Board
• TMPF TMap Next Foundation – pakub Examination Institute for Information Science
• TMPA TMap Next Advanced – pakub Examination Institute for Information Science

Kvaliteedi tagamise sertifikaadid

• CMSQ – pakub Quality Assurance Institute (QAI)
• CSQA – pakub Quality Assurance Institute (QAI)
• CSQE – pakub American Society for Quality (ASQ)
• CQIA – pakub American Society for Quality (ASQ)

Vastuolulisus

Tarkvara testimine põhjustab vahel eriarvamusi, sest see sisaldab mitmeid vastuolusid.

• Mida tähendab "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. Testimise meetodid tuleks endal välja mõelda.

• Väle versus traditsiooniline testimine

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

• Uurimuslik katse versus ette kirjutatud testid

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

• Manuaalne testimine versus automaatne testimine

Mõned autorid usuvad, et testide automatiseerimine on saadavat kasu arvesse võttes sedavõrd kallis, 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 versus tarkvara rakendamine

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

• Regressioonitestimine
• Tarkvaraarendus