Tarkvara testimine

Allikas: Teadmusbaas

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

Testimise olemuseks on kontrolltegevused, et näidata kõikide tarkvarale esitatud nõuete täidetust. Samuti peab testimisel veenduma, et kõik parandamiseks esitatud defektid ka parandatud saavad ning parandused ei põhjustaks omakorda uusi vigu.

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.

Ülevaade

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. Täpsem ülevaade Wikipediast(Ivo)


Testimise tüübid

Staatilise ja dünaamilise testimise võrdlus(Nugzar)

Kuna tarkvaratoote kvaliteet oleneb suures osas läbiviidavate testide tüübist, tuleb neid hoolikalt valida ja toote tellijaga kokku leppida. Osa testimist teeb programmeerija, osa testimist testijad ning lõpuks rakendatakse ka kliente-tellijaid. Järgnevalt lühike ülevaade erinevatest testimise tüüpidest.

Moodultestimise(Kevin või Maris) korral testitakse konkreetset tarkvaramoodulit - ühte alamsüsteemi kogu süsteemist. Testimist viib üldjuhul läbi moodulit realiseeriv arendaja. Moodulit tuleb kindlasti testida enne, kui moodul integreeritakse ülejäänud süsteemi. Mooduli testimisel tuleb jälgida, et moodul vastaks analüüsis püstitatud nõuetele. Mooduli testimise eesmärgiks on siiski vigade leidmine, mitte kasutajanõuetele vastavuse tõestamine. Näiteks kas moodulisse lisatud funktsioonid töötavad korrektselt ning tagastavad õigeid vastuseid. Mooduleid testitakse andmetepõhiselt: õigete, puudulike ja vigaste andmetega. Tüüpiliselt on siin tegemist nn „valge kast" testimisega, st testija tunneb testitava tarkvara sisemist ülesehitust ja tööloogikat.

Integratsioontestimise(Kevin või Maris) korral testitakse moodulitevahelist koostööd - kontrollitakse, kas kokku pandud moodulid töötavad omavahel ja kas iseseisvalt vigadeta töötanud moodulid koos vigasid ei genereeri. Testijana kasutatakse üldjuhul sõltumatut testijat, st testijat, kes ise ei arendanud testitavaid mooduleid. Näide integratsioonitestist on igaöine kompileerimine, et kontrollida arendatava toote käivitatavust.

Süsteemtestimise korral testitakse süsteemi kui terviku töötamist. Süsteemi testimisel musta kasti meetodil vaadeldakse süsteemi kasutajale nähtavaid osi (kasutajaliidest), süvenemata koodi (siit nimetus „must kast"). Testjuhtumid koostab testija (peamiselt kasutuslugude põhjal), kes testid ka läbi viib. Testijaid peab olema nii tellija kui täitja poolel. Seda laadi testimist nimetatakse ka funktsionaalsuse testimiseks.

Regressioontestimine(Villem) on igat tüüpi tarkvara testimine, mida kasutatakse peale koodi/süsteemi viidud muudatusi. Näiteks uue funktsionaalsuse lisamisel, konfiguratsiooni muutmisel, paikamisel. Regressioontestimise eesmärk on veenduda, et muudatused ja veaparandused pole tekitanud süsteemi uusi vigu. Testitakse muudetud mooduleid (moodultestimine) ja nendega seotud mooduleid ning kogu süsteemi funktsionaalsust (funktsionaalsuse testimine). Peamiseks meetodiks on juba kasutatud testide taaskäivitamine veendumaks, et süsteem toimib, vanad vead ei avaldu uuesti ja ei ole tekkinud uusi. Regressioontestimist on kasulik automatiseerida üldise töökoormuse vähendamiseks.

Jõudlus- ja koormustestid(Lauri) on ette nähtud süsteemi tehniliste nõuetele vastavuse läbiproovimiseks. Jõudlustesti on võimalik läbi viia mitmel moel - iga komponendi jõudlust eraldi mõõtes või suure hulga testandmetega süsteemi tavakasutamist katsetades. Jõudlustesti eesmärk on tuvastada kriitilisemad kohad, kus võib tekkida ülekoormus ja kulutada aeg nende kohtade optimeerimiseks. Kui tavaliselt mõeldakse testandmed korralikult läbi ning valitakse sisendid eesmärgist lähtudes, siis selle testimisel puhul on võimalik testida ka juhusliku, arvuti poolt genereeritud suure andmehulgaga.

Valideerimise eesmärk on kinnitada, et tarkvara töö tulemid väljatöötatud kujul sobivad määratud kasutamiseks. "Kas me teeme õiget tarkvarasüsteemi?"

Verifitseerimise(Tõnu) eesmärk on kinnitada, et protsessi või projekti iga tulem vastab spetsifitseeritud nõuetele. "Kas me teeme tarkvarasüsteemi õigesti?"

Kasutatavuse testid(Bert) hindavad süsteemi kasutusmugavust kasutaja vaatenurgast: Kasutatavuse testi eesmärk on avastada vigu ja kohti, mida paremaks võiks teha, selleks jälgitakse inimesi toodet kasutamas. Kindlasti ei saa kasutatavuse testimiseks pidada seda, kui kliendile näidatakse tulevase toote prototüüpi / pilti ja küsitakse, kas on arusaadav. Testimiseks peab inimene täitma konkreetseid ülesandeid ja sel teel selguvad tarkvarasüsteemis või ka veebilehel halvasti arusaadavad kohad. Kasutatavuse testimiseks sobivad nö "inimesed tänavalt", kes süsteemi esimest korda näevad. Aga ka eksperdid, kes oskavad kogemustest ja teooriatest lähtuvalt leida kasutusmugavuses nõrku kohti.

Vastuvõtutest(Ott Villem) ehk aktsepteerimistest on kliendi poolt läbiviidav test valminud toote hindamiseks ja vastuvõtmiseks. Vastuvõtutesti testijuhtumid kirjeldavad üheselt projekti üleandmise ja vastuvõtmise kriteeriumid ning testijuhtumid peavad olema konkreetsed ja mõõdetavad ning nendes lepivad tellija ja teostaja projekti realiseerimise eel kokku;

Koodi läbivaatus - erinevalt eelnevalt käsitletud testi tüüpidest, koodi läbivaatuse puhul koodi ei käivitata vaid koodi inspekteeritakse testija poolt. Läbivaatus eeldab küsimustiku olemasolu, mille alusel koodi hinnata ning sealt vigu otsida, mis tavatingimustes testides ei pruugi avalduda. Läbivaatajad peavad olema väga kompetentsed ka näiteks kasutatava keele osas. Mida otsitakse? Näiteks algväärtustamata muutujaid, ebasobivalt valitud andmetüüpe, muutujate või massiiviindeksite väljumist lubatud piiridest, tehete järjekorda, erinevate muutujatüüpide kokkusobivust jne.

Paigaldamistest ja ühilduvustest(Alex)

Suitsu ja jätkamise mõttekuse testid(Markus)

Turvalisuse testimine(Marek)

Purustav testimine(Werner)

Sertifikaadid

On olemas mitmesuguseid sertifitseerimisprogramme, 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.

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
    • 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]
Allikad:

Autor: Ostapenko

Lingid:

⇒ IEEE standardite loetelu juurde

⇒ SWEBOK