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.
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.
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
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 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.
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.
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× |
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.
Ü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.
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 testimist kasutatakse seoses verifitseerimise ja valideerimisega.
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 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.
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 (white-box) meetodi puhul on testijal juurdepääs sisemistele andmestruktuuridele ja algoritmidele (ja rakendatavale koodile).
Valge kasti testimise tüübid on:
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:
Mõlemad tagastavad koodi ulatuse mõõtarvu protsentides.
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õ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.
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 (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.
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.
Ü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.
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.
Testitakse täielikult integreeritud süsteemi, et kinnitada süsteemi nõuetele vastavust.
Kinnitatakse, et süsteem on integreeritud mistahes välise või kolmanda osapoole süsteemiga, mis on määratletud süsteemi nõuetes.
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 võib tähendada kahte asja:
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.
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.
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õ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 kontrollib, kas tarkvara on võimeline pidevalt töötama kindla ajaperioodi jooksul. Seda nimetatakse mõnikord vastupidavuse testimiseks.
Kasutuse katsetamine on vajalik, et kontrollida, kas kasutajaliidest on lihtne kasutada ja mõista.
Turvalisuse testimine on oluline tarkvara puhul, mis töötleb konfidentsiaalseid andmeid. Sel juhul peab süsteem vastu pidama häkkimisele ja küberrünnakule.
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:
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.
Destruktiivsel testimisel üritatakse tekitada tõrkeid tarkvaraprogrammis või käivituskeskkonnas, et testida selle robustsust.
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.
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).
Kuigi organisatsioonide vahel on erinevusi, on tüüpiline testimistsükkel järgmine:
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.
Testimise tööriistad ja silurid on tarkvara testimisel ja vigade leidmisel olulised abivahendid. Testimise/vigade leidmise vahendid sisaldavad järgmisi võimalusi:
Mõned nendest tööriistadest saab lõimida integreeritud arenduskeskkonda.
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.
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.
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
Testimise sertifikaadid
Kvaliteedi tagamise sertifikaadid
Tarkvara testimine põhjustab vahel eriarvamusi, sest see sisaldab mitmeid vastuolusid.
"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.
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.
Kas testid peaksid olema kavandatud teostamisega samal ajal või tuleks need kavandada juba eelnevalt?
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.
Kas testimine tuleks läbi viia ainult protsessi lõpus või ka selle vältel?
Idee seisneb selles, et iga jälgimisvorm on vastastikune, sest testi tegevus võib avalda mõju sellele, mida testitakse.
This article uses material from the Wikipedia Eesti article Tarkvara testimine, which is released under the Creative Commons Attribution-ShareAlike 3.0 license ("CC BY-SA 3.0"); additional terms may apply (view authors). Sisu on kasutatav litsentsi CC BY-SA 4.0 tingimustel, kui pole öeldud teisiti. Images, videos and audio are available under their respective licenses.
®Wikipedia is a registered trademark of the Wiki Foundation, Inc. Wiki Eesti (DUHOCTRUNGQUOC.VN) is an independent company and has no affiliation with Wiki Foundation.