Tarkvara testimist käsitlev juhendmaterjal
Tarkvara
testimine Testimise
parimad
praktikad Nõudmiste
määratlemine
Maili
MarkvardtASA
Quality Services OÜ
Tallinn
2006
Sisukord
1 Lugejaskond ja käsitlusala 3
2 Kasutatavad mõisted 3
3 Sissejuhatus testimisse 4
4 Testimise koht arendusprotsessis 5
5 Testimise liigid 5
5.1 Liigitus tarkvara testitavate omaduste järgi 5
5.2 Liigitus süsteemi detailsuse järgi 7
5.3 Liigitus testide läbiviija järgi 7
5.4 Liigitus testimise meetodi ja lähenemise järgi 7
5.5 Liigitus testimiseks kasutatavate andmete valiku meetodi järgi 8
5.6 Liigitus testitava objekti spetsiifika järgi 9
6 Testimise parimad praktikad – protsess 10
6.1 Töövoog 10
6.2 Rollid 11
6.3 Artefaktid 12
6.4 Tegevused 16
7 Nõuete määratlemine 19
7.1 Tarkvaranõuete määratlemine 19
7.2 Tarkvara testimist puudutavate nõudmiste määratlemine
hanke koostamisel 20
8 Lisa 1 - Spetsifikatsiooni mitmetimõistetavus 23
8.1 Vahemikud 23
8.2 Vähemalt üks AND ja OR samas
lauses 23
8.3 Ebamäärased terminid 23
8.4
Spetsiifilised mõisted 24
8.5 Üldistus +
mitmus 24
8.6 Üldistused 24
8.7 Asukohakriitilised sõnad 24
8.8 Asesõnad ta, nad, see 25
8.9 Tüüp vs
eksemplar 25
8.10 Tingimuslausete täielikkus 25
8.11 Tingimuslausete
seotus õige alternatiiviga 26
8.12 Kolme või enama
osapoole võrdlus 26
8.13 Protsessi kirjeldava tegusõna täielikkus 26
8.14 Protsessi kirjeldavate nimisõnade täielikkus 26
8.15 Lõpetamata loetelud 26
9 Lisa 2 – Spetsifikatsiooni mitmetimõistetavust leida võimaldav küsimustik 27
Lugejaskond ja käsitlusala
Antud
dokumendi lugejaskonnaks on eelkõige avaliku sektori, kuid laiemalt
ka igasuguse tellija -poole IT juhid, kes peavad tagama tellitava
tarkvara vastavuse hanke aluseks olevatele vajadustele. Dokument
kirjeldab testimise alaliike , eesmärke ja seda, kuidas planeerida ning läbi viia tarkvara testimist kogu projekti vältel tagamaks
tulemile esitatud nõuded. Esitatakse testimise planeerimise ning
läbiviimise tegevused, rollid ning nende sisendid ja väljundid.
Käesolevas
dokumendis kirjeldatud tarkvara testimise üldpõhimõtted on
sõltumatud tarkvaraarendusmetoodikast, projekti mahust ja omapärast.
Käesolev dokument selgitab ka seda, kuidas kohaldada üldist
testimisprotsessi erinevate projektide vajadustele, kuna üksikasjad
ei pruugi olla otstarbekad kõigis projektides.
Kasutatavad mõisted
Tarkvara
testimine – testimisel on mitmeid erinevaid definitsioone kuid
üldiselt ja lühidalt on see toote nõuetelevastavuse
kontrollimine. Kasutusel on ka definitsioon programmi käivitamine
eesmärgiga leida vigu, või ka programmi käivitamine ning lõpmatu
hulga võimalike testilugude seast valitud lõpliku hulga testilugude
läbiviimine kontrollimaks , kas programmi toimimine on ootuspärane.
Tarkvara
kvaliteedi järelvalve (Software
Quality Assurance)
– protsess, mis sisaldab planeeritud ja
süstemaatilist lähenemist hindamaks tarkvaratoote kvaliteeti ja
vastavust tunnustatud tarkvara-, protsessi- ja
protseduuristandarditele. Tarkvara testimine on üks tarkvara
kvaliteedi järelvalve osa.
Testitav objekt – süsteem, mida testime e
mille vastavust nõuetele kontrollime
Musta
kasti testimine – testimine, mis käsitleb testitavat objekti
musta kastina, st testide koostamisel vaadeldakse ja analüüsitakse
ainult sisend -väljund käitumist
Valge
kasti testimine – testimine, milles testide koostamisel
kasutatakse infot testitava objekti sisemise struktuuri kohta
(programmikoodi)
Vastuvõtutestimine
– Testimine eesmärgiga teha selgeks, kas loodud süsteem vastab
määratud vastuvõtukriteeriumidele, st kas süsteem on valmis
vastuvõtmiseks
Artefakt
– iga tarkvaraarenduse käigus loodav ja/või kasutatav tulem
(näiteks programmikood, nõudmiste dokument, projektiplaan ) on
artefakt
Testiplaan
– testimisprotsessi artefakt, mis kirjeldab projekti testimise
skoopi, meetodeid , ressursse ja vastutusi, ajagraafikuid, testitavaid
objekte ning testitavaid omadusi, riskide haldust
Testilugu
– testimisprotsessi artefakt, mis sisaldab detailset kirjeldust,
kuidas kontrollida testitava objekti vastavust mingile nõudmisele
Küsimustik
(checklist)
– nimekiri küsimustest, mis viitavad olulistele kontrollimist
vajavatele punktidele mingi eesmärgi suhtes
Nõudmine,
nõue (requirement)
– dokumenteeritud vajaduse kirjeldus selle kohta, milline süsteem
või tulem peab olema, mida võimaldama ja kuidas toimima .
Sissejuhatus testimisse
Testimine
on üks osa tarkvara kvaliteedi järelvalvest, mis on laiem protsess,
sisaldades planeeritud ja süstemaatilist
lähenemist hindamaks tarkvaratoote kvaliteeti ja vastavust
tunnustatud tarkvara-, protsessi- ja protseduuristandarditele.
Tarkvara
loomise ajendiks on mingid vajadused või probleem(id). Nende
lahendamiseks peab tarkvara realiseerima talle püstitatud nõudeid.
Nõudeid võib olla mitmesuguseid ning sellest lähtuvalt saab
eristada erinevaid testimise liike (vt Testimise liigid).
Tarkvara
testimist võib defineerida kui tarkvaraarenduse tulemi (programmi,
süsteemi) talle esitatud nõuetele vastavuse kontrollimist.
Kõrvalepõikena olgu märgitud, et testida (nõuetelevastavust
kontrollida) on võimalik iga tarkvaraarenduse artefakti, kuna
kõigile neile on püsititatud mingid nõudmised. Käesoleva dokument
käsitleb vaid arenduse käigus loodava süsteemi (tarkvara)
testimist.
Miks vead tekivad?
Tarkvara
mittevastavust nõuetele nimetatakse veaks ning vigu on võimalik
leida testimise käigus. Samuti on viga tarkvara mittevastavus
vajadustele, sobimatus probleemi lahendamiseks.
Võib
öelda, et vead on tarkvarasüsteemide keerukuse tõttu tarkvara
loomise paratamatu kaasnähtus. Vigade tekkimist pole võimalik
täielikult vältida, kuid kasutades efektiivset testimisprotsessi on
võimalik suur osa olulistest vigadest leida. Vigade teket saab
vähendada ka analüüsides ning parendades arendusprotsessi, kuid
see jääb antud juhise skoobist välja.
Tarkvara
vigade tekkimisel on mitmeid põhjuseid, olulisemaks võiks pidada
näiteks tarkvara loomise protsessi üldist suurt keerukust,
nõudmiste ebatäspsusi, kolmanda poole komponentide kasutamist,
tihedaid projektigraafikuid, juba leitud vigade parandamist
(parandamisel võib tekkida uusi vigu) ning tõsiasja, et igasuguse
inimtegevusega kaasnevad paratamatult vead.
Praktikas
on kinnitust leidnud ka väide, et programmeerijatel pole enamasti
piisavalt aega oma tööd testida ning nad on iseenda töö
testimisel suhteliselt ebaedukad: paljud vead jäävad leidmata , kuna
autor ei suuda märgata lünki iseenda mõtlemises ning samuti on
psühholoogiliselt raske oma tööd lõhkuda.
Tänapäeva
tarkvarasüsteemide suure keerukuse tõttu pole enamasti ka testimise
abil võimalik leida absoluutselt kõiki vigu, kuid on võimalik
leida suur osa olulistest vigadest.
Vigade
leidmise aeg on samuti oluline. On leitud, et mida varasemas tarkvara
elutsükli faasis viga leitakse, seda odavam on selle parandamine.
Sellest lähtuvalt võivad vead, mis on leitud arenduse varases
faasis, olla kümneid kuni sadu kordi odavamad paranda, kui sama vea
parandamine arenduse lõpus või pärast kasutusseandmist.
Eelnevast lähtuvalt on testimise eesmärgiks peale nõuetelevastavuse
kontrollimise leida olulised vead võimalikult kiiresti.
Testimise koht arendusprotsessis
Oluline
on märgata, et ükskõik, millisel arendusmetoodikal arendusprotsess põhineb (kosemudel, RUP, agiilmetoodikad), paikneb testimine oma
sisendite ja väljundite mõttes nõuete formuleerimise, analüüsi,
disaini ning realiseerimise vahel (vt joonis 1). Testimise sisendiks
on ühelt poolt süsteemile esitatavad nõudmised ning teiselt poolt
testitav objekt. Testimise põhiliseks väljundiks on eelkõige
leitud vigade kirjeldused, millele toetudes süsteemi ja vajadusel ka
nõudmisi parandatakse, kuid olulised on ka testide kirjeldused,
testiplaanid- ja aruanded .
Joonis
1 Tarkvara testimise asukoht teiste arendustegevuste suhtes
Arendusmetoodika spetsiifilisuse tõttu võivad protsessi etapid toimuda korduvalt
(iteratsioonidena) ning olla erineva pikkusega või olla jaotatud
alametappideks.
Seega
tuleb testimisega arvestada projekti algusest saadik ning see
projekti sisse planeerida, arvestades teisi tarkvaraarendustegevusi.
Testimise liigid
Vastavalt
testimise spetsiifilisele eesmärgile on võimalik eristada väga
palju erinevaid testimise klassifikatsioone. Liigitused võivad olla
omavahel kattuvad vastavalt sellele, millest testimismeetodi puhul
lähtutakse.
Näiteks
võib klassifikatsioone välja tuua selle põhjal,
Kes testib?
Mida testitakse ?
Kuidas testitakse?
Kõiki
testimise liike ei pruugi süsteemi testimisel olla võimalik ega ka
vajalik läbi viia (kuna testimisvajadused olenevad süsteemile
püstitatud nõuetest), samuti pole järgnevalt kirjeldatud kõiki
võimalikke testimise liike.
Testimise
erinevaid liike kirjeldatakse ka raamatutes Lessons Learned in
Software Testing [KA+], Effective Methods for Software Testing [PE]
ning Testing Standards Working Party materjalides [TS].
Liigitus tarkvara testitavate omaduste järgi
Tarkvaral
on palju erinevaid omadusi, millele võib defineerida nõuded.
Võimalike omaduste hulgas orienteerumise lihtsustamiseks on
koostatud kvaliteediatribuutide süsteeme. Üks neist on ISO/IEC 9216
poolt kirjeldatav kvaliteediatribuutide süsteem, mis jagab tarkvara
omadused kvaliteedinäitajateks ning nende allnäitajaiks. Standard
on vastu võetud ka Eesti standardiks EVS-ISO/IEC 9126-1: 2003.
Standardis kirjeldatud kvaliteedinäitajad ja allnäitajad (sulgudes)
on järgmised [9126]:
Funktsionaalsus
( sobivus kasutaja vajaduste rahuldamiseks, toimimise õigsus,
koostalitlusvõime teiste süsteemidega, turvalisus, funktsionaalsuse
vastavus normidele)
Töökindlus
(küpsus ehk tõrgete esinemise sagedus, tõrketaluvus väliskeskkonna
vigade suhtes, taastuvus, töökindluse vastuavus normidele)
Kasutuskõlblikkus
(Õpitavus, arusaadavus, käsitsetavus, meeldivus, kasutuskõlblikkuse
vastavus normidele)
Tõhusus
(ajaline käitumine, ressursikasutus, tõhususe vastavus normidele)
Hooldatavus
(analüüsitavus vea leidmiseks, muudetavus, stabiilsus muudatuste
suhtes, testitavus, hooldatavuse vastavus normidele )
Porditavus
(sobitatavus teisele riist - või tarkvaraplatvormile,
installeeritavus, koosoluvõime, vahetatavus, porditavuse vastavus
normidele)
Kõigile
standardis defineeritud kvaliteedinäitajatele vastavust on võimalik
testida, kui süsteemil on püstitatud nõudmised nende omaduste
suhtes.
Nimetatud
kvaliteedinäitajatest ja nende kombinatsioonidest tulenevad ka
järgmised tuntumad testimise liigid:
Funktsionaalne
testimine ehk vastavustestimine ( functional ,
conformance testing)
– eesmärgiks on kontrollida süsteemi vastavust funktsionaalsetele
nõuetele: kas vajalikke tegevusi on võimalik korrektselt läbi viia
Jõudlustestimine
( Performance testing)
– annab vastuse küsimusele, milline on süsteemi toimimise kiirus
tavaolukorras ning millised on kitsaskohad, mida oleks võimalik
parandada
Koormustestimine
( Load testing)
– annab vastuse küsimusele, kuidas toimib süsteem maksimaalse
talutava koormuse korral
Stresstestimine
(Stress testing)
– annab vastuse küsimusele, millise koormuse juures lakkab süsteem
korrektselt toimimast. Stresstestimine on seotud ka taastuvuse
testimisega. Taastuvuse testimine
(recoverability testing)
– annab vastuse küsimusele, kas süsteem taastub pärast
ülekoormuse kõrvaldamist aktsepteeritavalt
Kasutatavuse
testimine (Usability testing)
– Testitakse, kas süsteem vastab temale esitatud nõuetele
arusaadavuse, õpitavuse, kasutusmugavuse ning meeldivuse osas [AB+]
Robustness
testimine – kontrollida, kas süsteemi
on võimalik ebakorrektsete (ootamatute) sisendite või
keskkonnatingimuste loomise abil halvata või teha midagi, mis ei
tohiks olla lubatud. Kontrollida, kui suur on süsteemi võime taluda
ootamatuid olukordi .
Skaleeruvuse
testimine (Scalability testing)
– annab vastuse küsimusele: Kuidas on võimalik süsteemi kõige
optimaalsemalt laiendada ( riistvara konfiguratsiooni muutes)?
Turvalisuse
testmine ( Security testing)
– kontrollida süsteemi vastavust turvalisuse nõuetele: süsteemi
kasutamine peab olema võimalik ainult volitatud isikutele
kindlaksmääratud osas.
Kontrollida,
kas on säilitatud konfidentsiaalsus, kokkukuuluvus ning
kättesaadavus, kus kättesaadavus tähendab, et volitatud isikutel
on infole juurdepääs, kokkukuuluvus tähendab, et info õigsus ja
täielikkus on tagatud ning konfidentsiaalsus tähendab, et
juurdepääs on tagatud vaid selleks volitatud isikutele.
Installeeritavuse
testimine (installability
testing) –
annab vastuse küsimusele, kas süsteemi installeerimine toimub
vastavalt püstitatud nõudmistele (näiteks kas installeerimine
toimub ilma probleemideta kõigil soovitud platvorimidel)
Liigitus süsteemi detailsuse järgi
Süsteemitestimine
– testitakse kogu süsteemi vastavust talle esitatud nõuetele.
Musta kasti testimise alaliik . Süsteemitestimise liigid on ka
vastuvõtutestimine, alfa- ja beetatestimine, kuna nende käigus
testitakse kogu süsteemi.
Integratsioonitestimine
– testitakse erinevate komponentide liidestamist/koostööd. Kogu
süsteemi valmisolek ei ole vajalik, sest on võimalik kasutada
testidraivereid, mis simuleerivad puuduvate süsteemi osade käitumist
(top-down
ja bottom-up
või sandwich
meetodid). Suuremate süsteemide korral ongi otstarbekam liidestada
süsteemid järk-järgult.
Moodultestimine
– eraldiseisva tarkvaramooduli toimimise testimiseks. Mooduli iga
meetodi jaoks koostatakse test, mis on eraldiseisev mooduli teistest
testidest. Moodultestimine peaks olema tarkvaraarendajate vastutusel.
Liigitus testide läbiviija järgi
Alfatestimine
– testimeeskonna poolt läbi viidav testimine arendaja keskkonnas
arenduse lõpul
Beetatestimine
– testimine lõppkasutaja poolt väljaspool arendaja keskkonda
(lõppkasutaja keskkonnas) arenduse lõpul
Vastuvõtutestimine
– testitakse süsteemi vastavust kasutaja nõudmistele (lepingu
nõudmistele). Enamasti kontrollitakse vastuvõtutestimisel kasutaja
tüüpilisi tegevusi. Vastuvõtutestimist võib tellija viia läbi
iseseisvalt või koostöös arendajaga.
Kasutaja-testimine
– testimine lõppkasutaja poolt arenduse käigus kas arendaja või
lõppkasutaja keskkonnas, kusjuures kasutaja tegevusi juhendatakse ja
jälgitakse.
In-House
testimine – arendaja kasutab oma
tarkvara mõnda aega enne müügile laskmist oma vajaduste
rahuldamiseks, et olla kindel selle piisavas usaldusväärsuses.
Liigitus testimise meetodi ja lähenemise järgi
Staatiline vs dünaamiline
testimine
Staatilise
testimise käigus testitavat objekti ei käivitata vaid analüüsitakse
seda. Staatilist testimist on võimalik läbi viia nii
programmikoodile (koodi läbivaatused, küsimustikud) kui ka kõigile
teistele tarkvaraarenduse artefaktidele.
Dünaamilise
testimise käigus käitatakse testitav objekt (programm) ning
uuritakse selle käitumist.
Manuaalne vs automatiseeritud testimine
Manuaalse
testimise puhul viiakse testilood läbi käsitsi.
Automatiseeritud
testimise puhul kirjeldatakse testilood programmina ning need viib
läbi arvuti. Testimise automatiseerimist käsitleb põhjalikult
[FE+].
Musta kasti vs valge kasti
testimine
Musta
kasti testimise puhul koostatakse testilood süsteemile sisendite ja
väljundite põhjal. Süsteemi sisemine struktuur on teadmata. Musta
kasti testimismeetodite alla kuulub näiteks ekvivalentsiklasside ja
piirjuhtude analüüs.
Valge
kasti testimise puhul koostatakse testilood programmi struktuuri
põhjal. Valge kasti testimismeetodite alla käib kattekriteeriumide
alusel läbi viidav testimine.
Regressioonitestimine
– testimine pärast iga muudatust eesmärgiga, teha kindlaks, kas
muudatused ning funktsionaalsuse lisamine pole tekitanud vigu varem toiminud programmi osas.
Suitsutestimine
– pealiskaudne testimine eesmärgiga teha kindlaks, kas pole
põhjalikumat testimist takistavaid probleeme (näiteks programm ei
käivitu või kõiki põhifunktsioone pole võimalik testida).
Automatiseeritud suitsutestid võiksid olla esimene samm testimise automatiseerimise suunal.
Uuriv
testimine (Exploratory testing)
– testimine, mille käigus järgmised testilood tulenevad eelmise
tulemustest ning testija testimise ajal tekkivatest ideedest.
Testilugusid pole kohustuslik dokumenteerida, kuid seda võib teha.
Uuriva testimise alusena võib kasutada dokumenteeritud testilugusid,
mida testija laiendab vastavalt oma mõtetele. Tegelikkuses
praktiseerivad kõik testijad mingil määral uurivat testimist, kuna
tavaliselt viiakse läbi rohkem testilugusid kui on dokumenteeritud.
Seda põhjusel, et kõiki testilugusid ei saa paratamatult
dokumenteerida.
Uuriva
testimise rajajaks on James Bach . Täiendavaid materjale leiab [TE] .
Guerilla-testimine
– uuriva testimise alaliik, mis seisneb püüdes lühikese aja
jooksul leida programmi töös vigu kõige võimsamate meetoditega.
Kasutatakse juhul, kui on kiiresti vaja anda hinnang programmi
toimimisele. Võib eeldada, et kui kõige võimsamad rünnakud ei
paljasta ühtegi viga, siis ei leidu selles kriitilisi vigu.
Paaristestimine
– paarisprogrammeerimisele sarnanev tegevus testimisel: kaks
testijat kasutavad sama arvutit ning on kordamööda testimist
läbiviiva ning jälgiva ja vajadusel juhendava poole rollis.
Ad-hoc
testimine – programmi
mittesüstemaatiline testimine (juhuslike, mittedokumenteeritud
testilugudega). Ad-hoc
testimist ei ole soovitav pikka aega kasutada, kuna sellise testimise
puhul pole võimalik hinnata testikatet (millised testid on tehtud),
kuna mingit dokumentatsiooni läbiviidud testide kohta ei säili.
Samuti ei pruugi süsteemi testikate olla piisav, kuna teste ei
koostata süstemaatiliselt. Kolmandaks iseloomulikuks omaduseks on
see, et kuna teste ei viida läbi süstemaatiliselt ja
testidokumentatsiooni alusel, siis sõltub testimise efektiivsus
oluliselt testija kompetentsusest.
Liigitus testimiseks kasutatavate andmete valiku meetodi järgi
Sisendi/väljundi
ekvivalentsiklassid ja piirjuhud –
Ekvivalentsiklasside ja piirjuhtude analüüs (equivalence
partitioning) on kõige laialdasemalt
kasutatav meetod musta kasti testilugude koostamiseks . Programmi
sisendi ja väljundi põhjal leitakse ekvivalentsiklassid ehk andmete
piirkonnad, mille siseselt programm töötleb andmeid ühte moodi.
Kui ekvivalentsiklassi üks väärtus leiab vea, siis leiab vea ka suvaline teine väärtus ekvivalentsiklassist, eeldusel , et klassid
on õigesti määratletud. Analoogne on olukord, kui väärtus ei
leia viga. See omadus võimaldab testida programmi toimimist valides
1-2 väärtust igast ekvivalentsiklassidest. Ekvivalentsiklasside
piiridele jäävaid väärtusi nimetatakse piirjuhtudeks ning neid
tuleb reeglina testida eraldi.
Näiteks
programmil, mis sisestatud täisarvu kohta väljastab, kas sisestatud
arv on 0
või ei, on sisendi ekvivalentsiklassideks positiivsed arvud,
negatiivsed arvud ning piirjuhuks 0. Vastavalt sellele teadmisele
tuleks koostada testid, kus sisestatav arv omaks väärtust igast klassist ning ka klasside piiril . Ekvivalentsiklassid on võimalik
analoogselt leida ka väljundile, arvestades programmi
väljundväärtuste rühmitumist klassidesse. Antud juhul langevad
sisendi ja väljundi ekvivalentsiklassid ning piirjuhud kokku.
Kattekriteeriumil
põhinev testimine –
kattekriteeriumil põhineva testimise (code
coverage based testing) puhul luuakse testilood programmiteksti põhjal süstemaatiliselt vastavalt mingile
kattekriteeriumile (test
coverage/adequacy criterion). [KA+]
Tuntuimad kattekriteeriumid on näiteks lauseadekvaatsus,
haruadekvaatsus, kuid erinevaid kriteeriume on palju.
Näiteks
100% lauseadekvaatsuse saavutamiseks on vajalik, et kõik programmi
käivitatavad laused oleks testimise käigus käivitatud. Järgneva
pseudokoodis programmilõigu, mis väljastab, kas sisestatud arv on
0
või ei, lauseadekvaatseks testimiseks oleks vajalik testida mingi
negatiivse väärtusega, sest see võimaldab käivitada kõik
programmi käivitatavad read:
void
foo(int a)
printf("Sisestasite
");
if
(a printf("mitte-");
printf("positiivse
täisarvu.\n");
return;
Kasutades
sisendina väärtust 0,
jääb käivitamata lause printf("mitte-");.
Juhuslike andmetega testimine – testimisel kasutatakse sisendandmetena
juhuslikke andmeid. Juhuslikult valitud sisendandmed ei taga enamasti
piisavat testikatet, kuid juhuslikke andmeid on lihtne automaatselt
genereerida.
Statistiliste
andmetega testimine – testimisel kasutatakse andmeid, mida
lõppkasutajad kõige tõenäolisemalt kasutavad ( profiilid ).
Enamasti testitakse sel juhul vaid funktsionaalsuse
edustsenaariumeid.
Liigitus testitava objekti spetsiifika järgi
Hajus(süsteemide)testimine
(distributed
testing)
– testida tuleb eraldiseisvatest üksteisest sõltuvatest
alamsüsteemidest koosnevat süsteemi.
Pihuseadmete
(connection-limited device) testimine (mobiiltelefonid, pihuarvutid)
–testimist vajavad ka suhteliselt piiratud mälumahust ning
võrguressursside (mitte)kättesaadavusest tingitud alternatiivid
Reaalajasüsteemide
testimine – testimisel on oluline silmas pidades toimimise ajalisi piire – valel ajal muus osas korrektselt toimuv tegevus on
viga
Protokollide
testimine – spetsiifilised meetodid ning vahendid [PT]
Kasutajaliideste
testimine – graafiliste kasutajaliideste koostamise headele
tavadele vastavuse kontrollimiseks võib kasutada erinevaid
küsimustikke ja/või kasutajaliideste koostamise juhiseid. Viimased
võivad olla projektisisesed (stiiliraamatud), aga näiteks ka
operatsioonisüsteemist tulenevad (MAC OSi kasutajaliideste
koostamise juhised: [MAC], GNOME kasutajaliideste koostamise juhised:
[GN]).
Veebirakenduste
ja veebiteenuste testimine – olulised on nii turvalisuse [AN+],
[OWASP] kui ka kasutatavuse testimise aspektid
Testimise parimad praktikad – protsess
Järgnevalt
kirjeldatakse testimise protsessi, mis on kokku pandud lähtuvalt ASA
Quality Services töös kasutust leidnud parimatest praktikatest.
Testimise protsessi kirjapanemiseks kasutatakse RUPi protsesside modelleerimise metamudelit. See näeb ette protsessi üldise töövoo,
rollid, kes viivad läbi mingeid tegevusi, ning artefaktid, mida
kasutatakse, luuakse ja muudetakse tegevuste käigus.
Meie
protsessi põhiideedeks on lühidalt:
- Testimise alustamine arenduse varajases faasis, millega kaasneb nõudmiste täpsustamine
- Pidev koostöö tellijaga nõudmiste osas
- Pidev testimine (regressioonitestimine) ning testilugude täiendamine vastavalt nõudmiste ja süsteemi arengule.
Töövoog
Kirjeldatav
protsess püüab järgida üldtuntud fakti, et mida varasemas
tarkvaraarenduse faasis leitakse viga, seda odavam on selle
parandamine. Sellest tulenevalt on kõige odavamad need vead, mis
avastatakse tarkvaraarenduse erinevates faasides ning kõige kallimad
need, mis avastatakse pärast tarkvara kasutusseandmist.
Kogemused
näitavad, et parim lahendus on testimise arendusse sisseplaneerimine
hiljemalt analüüsi faasist alates, hilisem sekkumine ei ole nii
efektiivne. Protsessi töövoo esimeseks tegevuseks on planeerida
arenduse jooksul läbiviidavad tarkvara kvaliteedi tagamise
tegevused.
Vastavalt
süsteemi spetsiifikale määratakse testimise planeerimisel ära
testimisvajadused (mida ja kuidas testida)
kes testib ( ressursid )
millal testib (kooskõlas üldise projektiplaaniga)
Sellest
järgnevalt hakatakse ette valmistama planeeritud testimise tegevusi
(vastavalt testiplaanile). Vigade parandamiseks kuluva ressursi
optimeerimiseks on soovitav alustada tarkvara testimise tegevustega
juba tarkvaraarenduse algfaasis .
Kõige
esimeseks tegevuseks on testilugude koostamine. See sisaldab
muuhulgas ka analüüsi/nõuete sisulist ning põhjalikku
läbitöötamist ning seega võimaldab avastada analüüs puudusi
ning vasturääkivusi enne realiseerimist.
Testimist
tuleks loodud testilugude põhjal alustada nii vara kui võimalik,
kui on juba midagi testida. Üldise testimise käigu määrab ära
varem loodud testiplaan (kes millal mida testivad). Oluline on ka, et
testimist viidaks läbi kogu arenduse jooksul
(regressioonitestimine), sest muudatused toovad tihti kaasa uusi
vigu.
Testimise
käigus leitud vead dokumenteeritakse ning esitatakse parandamiseks.
Võimalik on ka nõudmiste muutumine ning uute nõudmiste ilmnemine.
Vastavalt sellele tuleb kaasajastada ka testilugusid.
Järgnevas
esitame täpsemalt protsessi rollide kirjeldused ja nende vastutused
tegevuste läbiviimisel ning artefaktide loomisel. Tuleb tähele
panna, et üks isik võib projektis olla mitmes rollis (näiteks võib
sama isik olla testikonsultandi ja testija rollis), kuid vastutuste
selguse eesmärgil on rollid kirjeldatud eraldi.
Kohaldamine
Kirjeldatud
protsess on vaikimisi mõeldud kasutamiseks tellija ja täitja
koostöös.
Antud
protsessi võib kohaldada ka ainult täitja organisatsiooni siseseks
kasutamiseks.
Sel juhul
võtab täitja testijuht enda kanda protsessis kirjeldatud
testikonsultandi ülesanded.
Protsessis
kirjeldatud testija võib töötada nii täitja organisatsioonis kui
tellija poolel, tegevused jäävad mõlemal juhul samaks.
Rollid
Testikonsultant (tellija esindaja)
Sisuliselt
võib testikonsultanti vaadelda kui tellija-poole kvaliteedialast
nõuandjat või järelvaatajat, kes hoolitseb tellitava tulemi
nõuetelevastavuse eest.
Tellija
poole testikonsultandi põhiliseks ülesandeks on:
- Aitab täpsustada nõudeid loodavale süsteemile
- Jälgib, et täitja-pool peaks kinni tulemile esitatud nõudmistest
- Osaleb testiplaani koostamisel ning vajadusel algatab selle muutmise (probleemide ilmnemisel , nõudmiste muutumisel)
- oluline osa vasutvõtutestimise juures (viib läbi või koordineerib vastuvõtutestimist)
- Võib juhtida ka testimist kogu arenduse käigus (kui tellijaorganisatsioonil on oma testimismeeskond)
Olulised oskused:
- Teadmised tellijaorganisatsiooni äriprotsessidest
- Teadmised tarkvaraarendusmetoodikatest ning tarkvara elutsüklist
- Teadmised ja kogemused erinevate testimismetoodikate ning testimisvahendite rakendamisel
Testijuht (täitja esindaja)
Täitja
poole testijuhi ülesanneteks on oma organisatsioonisisese
testimisprotsessi toimimise tagamine, kuid antud dokumendi kontekstis
on ta ka olulisel kohal projekti kvaliteedialase infovahetuse
tagajana. Sellest aspektist on täitja poole testijuht vastutav järgnevate tegevuste eest:
Osaleb testiplaani koostamisel täitja-poole esindajana
Annab õigeaegselt tagasisidet kõigist probleemidest, mis arenduse käigus võivad tekkida ning võivad nõuda testimisplaanide muutmist
Jälgib, et täitja viiks läbi planeeritud kvaliteedi tagamise tegevused
Testija (erinevad liigid)
Testija
praeguses kontekstis võib töötada nii tellija- kui
täitjaorganisatsioonis. Tema vastutusteks on:
Testimise läbiviimine vastavalt testimisplaanile
Õigeaegne probleemidest teavitamine (testijuhile või testikonsultandile, vastavalt sellele, kas on tegemist täitja- või tellijapoolse testijaga). Probleemideks on peamiselt nõuete muudatused ning testimisel leitud kriitilised vead, mis võivad ohtu seada projekti töögraafiku täitmise.
Olulised
oskused:
- Oskus konkreetse testimismetoodika rakendamisel või testimistööriista kasutamisel olenevalt testimise liigist
- Väga hea kirjalik ja suuline eneseväljendusoskus
- Kasuks tuleb rakendusvaldkonna tundmine, kogemused kasutatavate tehnoloogiate realiseerimisel
Testija
peaks endale teadvustama, et tema töö on vajalik suurele osale
projekti rollidest:
- Testijuht ja testikonsultant – anda operatiivset tagasisidet süsteemi ja testimise hetkeseisu kohta, informeerida võimalikes probleemidest
- Programmeerija – anda operatiivset tagasisidet leitud vigade kohta
- Tellija/lõppkasutaja – jälgida loodava süsteemi vastavust nõudmistele ning nõudmiste vastavust tellija vajadustele
Testiadministraator
Testiadministraatori
põhivastutuseks käesoleva protsessi kontekstis on testikeskkonna
seadistamine, hooldamine ning tööshoidmine.
Vastavalt
sellele on olulisteks oskusteks teadmised arvutisüsteemide
administreerimisest kui ka teadmised projekti nõutava testikeskkonna
kohta.
Testiadministraatori
ülesandeid võib täita tellija või täitja poole
süsteemiadministraator või muu töötaja, kes omab vastavaid
oskusi.
Artefaktid
Testimise
protsessi käigus loodavad ja kasutatavad artefaktid jagunevad laias
laastus kaheks:testispetsiifilised ja üldised artefaktid.
Testispetsiifilised artefaktid tekivad testimise protsessi tegevuste
tulemusel ning nende sisu ja loomise põhimõtteid kirjeldatakse
käesolevas dokumendis ka pikemalt . Detailsemat lisainfot on võimalik vaadata standardist IEEE std 829 – Standard for Software Test
Documentation [829] ning näiteid artefaktide struktuuri ja sisu
kohta leiab ka RUPi dokumentatasioonist [RUP].
Üldised
artefaktid on testiprotsessile põhilisteks sisenditeks ning neid
kirjeldatakse vaid ülevaatlikult. Täpsemat infot struktuuri ja sisu
kohta leiab RUPi dokumentatsioonist [RUP].
Üldised artefaktid
Visioon
– defineerib huvitatud osapoolte arusaama ja põhinõudmised (ning
nende aluseks olevad vajadused) arendatavale objektile. Visioon on
aluseks edasisele detailsemale analüüsile, kuid annab üldülevaate
arendatava objekti eesmärkidest.
Süsteemi funktsionaalsed ja mittefunktsionaalsed nõudmised – kõik
süsteemile (või süsteemi osale) esitatavad nõudmised, mille hulka
tavaliselt kuuluvad kasutuslugude mudel, kasutuslood ning
lisaspetsifikatsioonid ( kirjeldavad nõudmisi, mida pole võimalik
kasutuslugude abil kirjeldada)
Süsteemi
kasutuslugu – defineerib kasutaja
võimalikud tegevused süsteemiga ning süsteemi vastused.
Kasutuslood koondatakse kasutuslugude
mudelisse, mis väljendab kasutuslugude
omavahelisi ning kasutuslugude ja tegutsejate suhteid.
Projektiplaan
– kajastab kogu arendusprojekti läbiviimise korra, tegevused
ja vastutused. Võib kaasata ka teisi dokumente (näiteks
iteratsiooniplaane) vastavalt projekti iseloomule .
Kõikvõimalikud
asjassepuutuvad lisadokumendid – sõnastikud, kasutajaliidese prototüübid jm.
Testispetsiifilised artefaktid
Testiplaan
Testiplaan
defineerib testimise skoobi, testimise eesmärgid selles, meetodid,
loodavad tulemid ning nende loomiseks kasutatavad sisenddokumendid.
Samuti planeeritakse testimistegevuste ajagraafik ning määratakse
vastutused. Testimistegevused peavad olema kooskõlas projekti
üldplaaniga.
Testiplaani
eesmärgiks on välja tuua ja huvitatud osapooltele kättesaadavaks
teha testimise korraldus. Testiplaan juhendab, suunab ja piirab
testimise ressursside kasutamist, et saavutada testiplaaniga määratud
eesmärgid.
Testiplaanil
võib olla ka alamplaane. Peamine testiplaan kirjeldab sel juhul,
milliseid alamplaane luuakse ning tähtaegu nende koostamiseks.
Näiteks jõudlustestimise plaan võib olla eraldi dokument, mis
koostatakse vastavasse etappi jõudes.
Testiplaan
on tegevuse Testimise planeerimine väljund.
Testiplaan
on sisendiks tegevustele: Testilugude koostamine ja täpsustamine
ning nõuete täpsustamine, Testimine, Testikeskkonna seadistamine,
Vastuvõtutestide määramine ning vastuvõtutestimine
Testiplaani
koostamise eest vastutab: Testijuht (täitja)
Testilugu
Testiloo
eesmärgiks on detailselt kirjeldada, kuidas toimub mingi süsteemi
omaduse toimimise kontrollimine, millised tegevused peab testija läbi
viima ning kuidas otsutada, kas süsteem toimib korrektselt.
Testilood koostatakse seega süsteemi nõudmiste põhjal
(funktsionaalsed ja mittefunktsionaalsed nõudmised, kasutusjuhud).
Testiloo
soovitavas struktuuris on järgnev info:
- unikaalne ID – testiloo identifitseerimiseks
- Lühikirjeldus – testitav omadus lühidalt, et testija saaks kiiresti ettekujutuse, millise omaduse testimist kirjeldatakse
- Eeltingimused
- Tegevused samm- sammult (test sisendid)
- Tegevustele vastavad oodatavad tulemused (testi väljundid)
- Erinõudmised keskkonnale
Testilugu
on tegevuse Testilugude koostamine ja täiendamine, nõuete
täpsustamine väljund.
Testilugu
on sisendiks tegevustele: Testilugude koostamine ja täiendamine,
nõuete täpsustamine , Testimine, Vastuvõtutestide määramine ning
vastuvõtutestimine
Testiloo
koostamise eest vastutab: Testija
Vea aruanne
Vea
aruande eermärgiks on vea ja tekkimise kirjeldamine, seega on vea
aruanne ajalik vea põhjuste selgitamiseks ning seega ka vea
parandamiseks.
Vea
aruande eesmärgist tuleneb ka selle soovituslik struktuur:
- Unikaalne ID (näiteks vehaldussüsteemi poolt omistatav)
- Viide testiloole, mille läbiviimisel viga tekkis (võib ka mitte eksisteerida, kui tegemist on uuriva testimisega)
- Vea lühikokkuvõte (max 80 märki ehk üks rida)
- Probleemi detailne kirjeldus
- Samm-sammult tegevused ning detailsed tegelikud tulemused, koos sisend- ja väljundandmetega
- Kirjeldus selle kohta, mis peaks juhtuma, kuid ei juhtunud
- Vea korratavuse hinnang
Veaaruannete
koostamise puhul tuleks jälgida järgnevaid soovitusi :
ka vead, mida ei õnnestu korrata või mis näiliselt ilmnevad juhuslikult, tuleks dokumenteerida koos kordamise katsetustega (mida on tehtud, et proovida viga esile kutsuda)
Veaaruande lühikokkuvõte peaks olema lühike kuid ülevaatlik (max 80 märki ehk üks rida)
Veaaruanne peab olema lihtsas keeles, hästi arusaadav (ka väsinud, tülpinud, kiirustavale inimesele)
Veaaruande toon peab olema neutraalne, asjalik
Tööriistad
Vigade
aruannete halduseks on soovitav kasutada veahaldussüsteemi (näiteks
Itracker [IT], Trac [TR], Bugzilla [BZ]). See lihtsustab infovahetust
kõigi huvitatud osapoolte vahel:
- programmeerijad ja testijad saavad vahetada vigu ja nende parandamist puudutavat infot
- testijuhid ja/või konsultandid ja ka teised huvitatud osapooled saavad vajadusel infot leitud vigade hulga, tõsiduse kohta.
Vea
aruanne on tegevuse Testimine väljund.
Vea
aruanne on sisendiks tegevustele: Testimine
Vea
aruande koostamise eest vastutab: Testija
Testiaruanne
Testiaruande
eesmärgiks on anda ülevaade testimise ja testitava objekti
hetkeseisust. Testiaruandeid koostatakse perioodiliselt vastavalt
projektiplaanile ja vajadusele. Seetõttu peaks testiaruanne
sisaldama järgmist infot:
- Kokkuvõte läbi viidud testimise tegevustest
- Kõrvalekaldumised testiplaanist
- Kokkuvõte testimise tulemustest
- Hinnang testimise põhjalikkusele
- Hinnang testitavale objektile
Testiaruanne
on tegevuse Testimine väljund.
Testiaruanne
on sisendiks tegevustele: Testimine
Testiaruande
koostamise eest vastutab: Testija
Testilogi
Testilogi
eesmärgiks on pakkuda kronoloogiliselt järjestatud infot testide
läbiviimise kohta. Testilogid on abiks vigade põhjuslike seoste
otsimisel ning analüüsimisel või testitulemustest järelduste
tegemisel (näiteks jõudlustestide puhul), seega on otstarbekas
kirjeldada võimalikult palju konkreetsel juhul huvitavat infot.
Testilogid
tekivad erinevate testide käigus, seega pole võimalik kirjeldada
ühtset struktuuri .
Näiteks funktsionaalse käsitsitestimise logiks on testimise kuupäeva ja
tegeliku tulemusega varustatud testilood. Vajadusel võib lisada ka
küsimusi, millele hiljem vastuseid otsida.
Testilogiks
on ka automaatsete testide (näiteks funktsionaalsete või
jõudlustestide) käivitamisel genereeritavad logifailid, mida on
hiljem võimalik analüüsida.
Tihti
kasutatakse testilogisid analüüsi eesmärgil ning pärast
järelduste tegemist muutuvad testilogid mittevajalikuks või
vähemasti mitte aktiivselt kasutatavaks.
Testilogi
on tegevuse Testimine väljund.
Testilogi
on sisendiks tegevustele: Testimine
Testilogi
koostamise eest vastutab: Testija
Testikeskkond
Testikeskkonna
all mõeldakse vajalikku riist- ja tarkvara ( arvutid ,
operatsioonisüsteemid, testimisvahendid), mis on vajalikud
planeeritud testimise läbiviimiseks.
Testikeskkond
on tegevuse Testikeskkonna seadistamine väljund.
Testikeskkond
on sisendiks tegevustele: Testimine
Testiplaani
koostamise eest vastutab: Testiadministraator
Tegevused
Testimise planeerimine
Testimise
planeerimise tegevuse eesmärgiks on:
- Testimisele eraldatavate ressursside efektiivseima jaotuse leidmine
- Testimise eesmärkide, tegevuste ja meetodite paikapanemine
Sisendid:
Projekti üldplaan, visioon, nõuded, kasutusjuhud (kui on),
Väljundid:
Testiplaan
Testimise
tegevused peavad olema kooskõlas projekti üldise plaaniga ning
täitjaorganisatsiooni töökorraldusega. Näiteks kui tarkvaraarendus toimub iteratsioonidena, siis koostatakse esmane
projektiplaan arenduse alguses ning täiendatakse seda vastavalt iga
iteratsiooni plaanile.
Spetsiifiliste testimise alamtegevuste jaoks on võimalik koostada ka alamplaane
(näiteks testimise automatiseerimise plaan, jõudlustestimise plaan,
skaleeruvuse testimise plaan). Peamises testiplaanis kirjeldatakse
sel juhul alamplaanide eesmärgid ning loomise tähtajad.
Esimeseks
tegevuseks testimise planeerimisel on projekti olemasoleva
dokumentatsiooniga tutvumine – millise (milliste omadustega)
süsteemiga on tegemist. Testiplaan peab olema kooskõlas arenduse
üldplaani ja eesmärkidega, seega tuleb sobiva plaani koostamisel
infot vahetada ja kokkuleppeid saavutada nii arendajate esindajaga
kui vajadusel ka teiste huvitatud osapooltega.
Seejärel
tuleb saadud informatsiooni põhjal vastata küsimustele, millele
peab vastuse andma testiplaan.
- Milline on testimise projekti skoop ?
- Milliseid meetodeid ja vahended kasutatakse testimisel?
- Milliseid tegevusi viiakse läbi testimise käigus ning mis on nende tegevuste tulemiteks?
- Milliseid ressursse testimisel kasutatakse ning milline on testimise ajagraafik, kes viivad läbi testimise tegevusi?
- Milliseid omadusi ja objekte testitakse ja ei testita?
- Millised on testimise projektiga seotud riskid ning kuidas toimida nende realiseerumisel?
Kui
projekti näeb ette testimise automatiseerimist, on soovitav
testiplaani koostamisel sellele eraldi tähelepanu pöörata, kuna
automatiseerimise tegevused peavad edu tagamiseks olema põhjalikult
läbi mõeldud. Tuleks mõelda:
- milliste süsteemi osade testimist on otstarbekas automatiseerida?
- milline testimisvahend on antud projekti iseloomu arvestades kõige otstarbekam?
- kas testiandmete genereerimist oleks vajalik automatiseerida?
- milliseid meetodeid ja vahendeid on otstarbeksas testiandmete automatiseerimiseks kasutada?
Testiplaani
täpsemat struktuuri kirjeldab artefakt: Testiplaan
Testilugude koostamine ja täiendamine, nõuete täpsustamine
Sisendid:
Süsteemi nõudmised, spetsifikatsioonid, kasutuslood, testiplaan,
küsimustikud (valikuline)
Väljundid:
Testilood, ettepanekud sisenddokumentide täpsustamiseks
Testilugude koostamine
Testilugude
koostamisel võib esimese sammuna identifitseerida testiideed, mis
kirjeldavad lühidalt, mida peaks süsteemi juures testima. Seejärel
pannakse samm-sammult kirja juhis, kuidas süsteemi vastavalt sellele
testida. Nii testiideede kui testilugude koostamine toimub nõudmiste
ja/või kasutuslugude põhjal.
Testilugude
koostamisel tuleks jälgida ka seda, et testilood oleksid loogiliselt
struktureeritud (modulaarsed), mis tagab nende hallatavuse. Samuti ei
ole mõistlik koostada liiga detailseid testilugusid, kuna see toob
nõudmiste muutumisel kaasa ulatuslikud muudatused.
Testilugude täiendamine
Testilugusid
tuleb vastavalt nõuete muutumisele ning täpsustamisele pidevalt
täiendada ning parandada kuni projekti lõpuni. Vastasel juhul kaotavad testilood kiiresti oma relevantsuse ning ei ole
regressioonitestimisel kasutatavad ning sellega kaasneb testimise
muutumine Ad-Hoc
testimiseks, seega pole võimalik enam adekvaatselt hinnata, mida ja
kui palju on testitud.
Kõiki
testilugsid ei ole võimalik alguses ette näha ning kirjeldada.
Uuriv testimine on heaks allikaks testilugude täiendamisel.
Testimise käigus on soovitav teha läbi ka testilugudega
kirjeldamata tegevusi vastavalt tekkivatele ideedele (uuriv
testimine). Selle käigus aga võib ilmneda uusi ning häid
testilugusid, mis tuleks dokumenteerida. Tulemuseks on paremat
testikatet pakkuvad testilood.
Nõuete täpsustamine
Testilugude
koostamise aluseks on spetsifikatsiooni süstemaatiline
läbitöötamine, mis võimaldab leida puudusi spetsifikatsioonis.
Spetsifikatsiooni puudutavate küsimuste tekkimisel tuleb need edastada ja läbi arutada spetsifikatsiooni koostaja või tema
esindajaga. Selle tulemusena võib toimuda muudatusi alusdokumentides
ning need peavad kajastuma ka testilugudes.
Abistava
materjalina võib spetsifikatsiooniga tutvumisel kasutada
mitmetimõistetavuste küsimustikku, mis juhib tähelepanu
üldlevinumatele vigadele ning ebatäpsuste suhtes kriitilistele
kohtadele.
Testikeskkonna seadistamine
Sisendid:
Testiplaan, sihtkesskonda kirjeldavad nõudmised (kui on)
Väljundid:
Testikeskkond
Testimisele
eelneb testikeskkonna ettevalmistamine. Nõudmised testikeskkonnale
on püsititatud testiplaanis vastavalt testitavatele omadustele.
Nõudmiste ning plaanide muutumisel tuleb ka testikeskkonda vastavalt
muuta. Testikeskkonna töökorras hoidmine on samuti pidev protsess,
et keskkond ei saaks tööd pidurdavaks asjaoluks.
Testikeskkonna
puhul on oluline, et oleks loodud võimalikult sarnased tingimused
programmi testimiseks sihtkeskkonnaga, kuna vastasel juhul on väga
tõenäoline, et tekib probleeme projekti lõpufaasis, kui
arendatavat süsteemi siiratakse sihtkeskkonda. Testikeskkonna
sarnasus lõppkeskkonnaga aitab avastada need kriitilised probleemid
projekti varajases etapis . Kui testikeskkonda pole võimalik luua
sarnasena sihtkeskkonnale (näiteks sihtkeskkonna keerukuse või
kalliduse tõttu), siis oleks vajalik leida võimalus testida
süsteemi arendatavaid versioone sihtkeskkonnas, et varakult leida
võimalikud probleemid, mis võivad nõuda ulatuslikke muudatusi.
Testikeskkonna
loomine ning nõudmised sellele olenevad oluliselt projekti
eripärast, seega ei saa anda konkreetseid soovitusi.
Testimine
Sisendid: Testiplaan,
testilood, testitav süsteem, testiaruanded, vigade aruanded,
testilogid
Väljundid: Testilogid,
testiaruanded, vigade aruanded, täiendatud testilood
Testimine kujutab endast
kirjeldatud testilugude läbiviimist vastavalt testiplaanile.
Testimise liike on
erinevaid (vt Testimise liigid) ning vastavalt testieesmärgile on ka
testimise tegevused erinevad.
Testimise tegevuse alla
kuuluvad käesolevas protsessis ka funktsionaalse testimise
automatiseerimisega seotud tegevused, kui need on testiplaanis ette
nähtud. Testiplaaniga on määratud sel juhul ka testimisvahendid.
Kui on planeeritud funktsionaalsustestide automatiseerimine , siis
tuleb sellega samuti alustada võimalikult nii vara kui võimalik,
kuna vastasel juhul tekib harjumus käsitsitestimiseks ning
automatiseeritud testimise alustamine on raskendatud.
Testide automatiseerimine
toimub järkjärguliselt ning ka juba koostatud teste tuleb vajadusel
muuta ja parandada, kuna projekti käigus toimub täiendusi
nõudmistes ja testilugudes. Testimise automatiseerimisel on oluline
koostada testid nii, et neid oleks võimalikult lihtne hallata ning
nad oleksid võimalikult väikese hooldusega kasutatavad projekti
lõpuni. [MA]
Testimise
automatiseerimise puhul võib olla vajalik ka eraldiseisev testide
sisendandmete genereerimine. Testiandmete genereerimise vajaduse ning kasutatava meetodi üle tuleb igas olukorras eraldi otsustada, kuna
tihti ei pruugi see olla otstarbekas ja erinevaid võimalusi on palju
[ED]. Andmete genereerimise automatiseerimiseks tuleb suure
tõenäosusega kohaldada olemasolevaid algoritme ja vahendeid
käesoleva olukorra jaoks. Seetõttu tuleb kindlasti arvestada, et
valitud meetodi rakendamine võtab aega ning seega tuleb selle jaoks
ressursid planeerida juba testimise planeerimise etapis.
Testimisel
leitud vead tuleb kirjeldada. Leitud vea kirjeldamine on testimise
üks olulisemaid tegevusi, kuna vea kirjelduse põhjal määratakse
kindlaks vea põhjus ning otsustatakse, kas ja kuidas viga parandada.
Samuti on korralike veaaruannete põhjal hiljem lihtne vigade
parandusi kontrollida, kuna vea saamise muster on üksikasjalikult
kirjeldatud. Kui viga on kirjeldatud ebatäpselt, on ka testijal
hiljem raske adekvaatselt kontrollida, kas viga on parandatud.
Testimise
ja testitava objekti hetkeseisust teavitamise eesmärgil koostatakse
ka perioodilisi testiaruandeid.
Vastuvõtutestide määratlemine ja vastuvõtutestimine
Sisendid:
Testilood, testiplaan, visioon
Väljundid: Vastuvõtutestide
nimekiri, vastuvõtutestimise aruanne
Vastuvõtutestideks
valitakse mingi hulk kogu süsteemi testilugudest, kuna ei pruugi
olla aega kõiki testilugusid läbi viia. Vastuvõtutestideks
määratakse tellija äriprotsessi kõige kriitilisemad testid.
Vastuvõtutestide määramist võiks alustada juba testiplaani
koostamisel, kuid vahetult enne vastuvõtutestimist tuleks
vastuvõtutestide relevantsus üle kontrollida ning vajadusel teha
täiendusi.
Vastuvõtutestimine
peaks toimuma tellija poolel. Vastavalt projekti suurusele ning
kasutatavatele ressurssidele võib vastuvõtutestimise läbi viia
testikonsultant või tellijapoolne testija/testimeeskond.
Vastuvõtutestimisse võib kaasata ka tellija esindajaid, kui nende
ettevalmistus selleks on piisav (näiteks tellija IT osakond ).
Vastuvõtutestimise
tulemuseks on vastuvõtutestimise aruanne, mis vormilt on samasugune
kui testiaruanne.
Nõuete määratlemine
Tarkvaranõuete määratlemine
Nagu
eelnevalt öeldud, on testimine tarkvara nõuetelevastavuse
kontrollimine, nõuded aga on tarkvara vundamendiks. Seetõttu on
oluline, et nõuded, mis kirjeldavad piisavalt täpselt tarkvara
loomist ajendanud probleemi, oleks kirja pandud. Kogemused on
näidanud, et tegelikkuses on korrektsete nõuete kirjeldamine komplitseeritud ning veaohtlik tegevus, mis tingib vajaduse nõuetele
erilise tähelepanu pööramiseks.
Üldtuntud
on ka fakt, et valestipüstitatud nõuetest tekkinud vead on kõige
kallimad parandada (kümneid kuni sadu kordi kallimad kui vead, mis
leiti kodeerimise käigus), sest nad tekivad juba tarkvaraarenduse
varajases faasis ning pahatihti avastatakse vahetult enne tarkvara
kasutusseandmist (vastuvõtutestide käigus).
Sellest
lähtuvalt on oluline, et nõudmised oleks püstitatud võimalikult
täpselt ning üheseltmõistetavalt. Nõuete kirjeldamise ning
arendamise tehnoloogiat nimetatakse nõudmiste ehitamiseks
( requirements engineering)
[HU+]. See on hetkel küllalt reglementeerimata ning Eesti praktikas
üsna vähetuntud valdkond.
Tarkvaranõuded
ja spetsifikatsioonid koostatakse enamasti inimkeeles, kuna erinevalt
formaalsetest spetsifitseerimiskeeltest on see arusaadav kõigile
osapooltele. Inimkeele kasutamisega kaasneb paratamatult
mitmetimõistetavus (ambiguity)
– olukord, kus kirjeldatud nõudmisel on rohkem kui üks võimalik
interpretatsioon. Kuna tarkvaranõuded peavad olema siiski täpsed ja
kõigile üheselt mõistetavad, siis on vajalik teada, kus ja
millisel moel võib mitmetimõistetavus tekkida ning kuidas seda
vältida. Võimalikke ohtusid teades ja silmas pidades saab oluliselt
vähendada inimkeele mitmetimõistetavust.
Nõuete
täpsustamisele ning mitmetimõistetavuste avastamisele aitab kaasa
testilugude koostamine arenduse algfaasis, kuna testilugude
koostamisel töötatakse nõuded süstemaatiliselt läbi. See
võimaldab leida paljud vasturääkivused ja puudused enne, kui
hakatakse vastavat osa realiseerima ning see omakorda lihtsustab
realiseerimist ning vähendab tekkivaid vigu.
Analüüsidokumentide
süstemaatilisel läbivaatamisel (testilugude koostamiseks või
analüüsi verifitseerimiseks) võib kasutada nõuete keelelist
mitmetimõistetavust leida võimaldavat küsimustikku, mis on toodud
Lisas 2. Küsimustiku mõistmise lihtsustamiseks on Lisas 1 on välja
toodud küsimustiku aluseks olevad tüüpilised mitmetimõistetavad
olukorrad, mida võib spetsifikatsioonides esineda ning millele tuleb
tähelepanu pöörata. Iga probleemi juures on esitatud ka mõistmist
illustreeriv näide. Lisaks on antud soovitusi, kuidas esinenud vigu
parandada või kuidas neid edaspidi vältida
Keelelisest
mitmetimõistetavusest saab rohkem lugeda Kamsties’e ja Berry raamatust Linguistic Sources of Ambigutity [BE+].
Tarkvara testimist puudutavate nõudmiste määratlemine hanke koostamisel
Tarkvara
testimise hanke või tarkvara loomise hanke testimist puudutava osa
koostamisel tuleb samuti püstitada nõudmised testimisprotsessile,
et hanke täitjale oleks üheselt mõistetav, mida temalt oodatakse
ning et tagada hankija ja täitja ühene arusaam hanke eesmärgist
või tellitava tarkvara kvaliteedi tagamisest.
Seetõttu
tuleks tarkvara (testimise) hanget plaanides välja selgitada ning
hanke pakkumiskutsesse lisada suhteliselt konkreetne testimisülesande
püstitus:
Hanke sisendid (testitava objekti arenduse alusdokumendid ) ning testitav objekt (erinevad versioonid)
Hanke väljundid:
Testiplaan
Testilood
Täiendusettepanekud alusdokumentide (nõudmiste) osas
Testimise tulemused kõigi testimise liikide kohta
perioodilised testitulemuste aruanded kõigi läbiviidud testimise liikide kohta (sagedus vastavalt kokkuleppele)
Lõplik testiaruanne koos hinnanguga projekti kvaliteedile
Hanke
korraldamisel tuleks eelnevalt indentifitseerida:
Olulisemad testimisvajadused, milliseid teste läbi viiakse (vt. Testimise klassifikatsioonid). Läbiviidavate testide hulk ei pruugi pakkumiskutses olla täielik, kuna testimisvajadused vaadatakse üle ning täpsustatakse testimise algfaasis testikonsultandi osavõtmisel.
Hanke umbkaudne maht inimtundides
Hanke
nõudmiste püstitamisel võib oodata täitjalt käesolevas
dokumendis kirjeldatud testimise parimate praktikate kasutamist
mingis osas, kui täitja soovib neid oma arendusprotsessis kasutusele
võtta.
Viited
[829]
IEEE std 829-1998 Standard for Test Documentation
[9126]
EVS - ISO/IEC 9126-1:2003 Tarkvaratehnika . Toote kvaliteet. Osa 1: Kvaliteedimudel
[AB+]
Abratt, D., Mallinson, W., Bekker, A. (2003). Usability Testing: Recipe for success .
http://www.testingstandards.co.uk/usability_recipe_for_success.ht m
[AN+]
Andrews, M., Whittaker, J.A. (2006). How to break software:
Functional and Security Testing of Web Applications and Web Services.
Addison-Wesley Professional
[BE+]Berry,
D.M., Kamsties, E., Krieger , M.M. (2003). From Contract Drafting to
Software Specification: Linguistic Sources of Ambiguity--A Handbook ,
manuscript. http://se.uwaterloo.ca/~dberry/handbook/ambiguityHandbook.pdf
[BZ]
Bugzilla. Http://www.bugzilla.org/
Veahaldussüsteem
[ED]
Edvardsson, J. A survey on Automatic Test data Generation. http://www.ida.liu.se/~joned/papers/class_atdg.pdf
[FE+]Fewster,
M., Graham, D. (1999). Software test automation: effective use of
test execution tools . Addison-Wesley
[GN]
GNOME Human Interface Guidlines
http://developer.gnome.org/projects/gup/hig/2.0/
[HU+]
Hull, E., Jackson, K., Dick , J. (2004). Requirements Engineering 2nd edition . Springer
[IT]
Itracker. http://www.itracker.org/
Vabavaraline veahaldussüsteem
[KA+]
Kaner,C., Bach, J., Pettichord, B. (2001). Lessons learned in
Software testing 1st edition. Wiley
[MA]
Marick, B. (1998) When should a test be automated?
http://www.testing.com/writings/automate.pdf
[MAC] Apple Human Interface Guidlines
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/
[OWASP]
The Open Web Application Security Project www.owasp.org
[PE] Perry ,
W.E. (2000). Effective methods for software testing 2nd edition.
Wiley
[PT]
Protool testing – Theory, Test Suites, Tools, Formal Methods
http://www.protocoltesting.com/
[RUP] Rational unified process
[TE]
Center for Software Testing Education and Research
www.testingeducation.org
[TR]
Trac. http://trac.edgewall.org/
Veahaldussüsteem
[TS]
The Testing Standards Working Party
http://www.testingstandards.co.uk/
Lisa 1 - Spetsifikatsiooni mitmetimõistetavus
Järgnevalt
kirjeldatakse [BE+] alusel 15 levinumat mitmetimõistetavuse allikat
ning näidatakse, kuidas neid vältida.
Vahemikud
Kui
tekstis on spetsifitseeritud vahemikke, siis kas vahemike otspunktid
on üheselt kirjeldatud? Näiteks:
Kui registreerunud
osavõtjaid on 5 kuni 12, kasutatakse väikest saali, rohkema
osavõtjate arvu korral suurt saali, vähema osavõtjate arvu puhul
jäetakse üritus ära.
Kas
otspunktid 5 ja 12 on kaasa või välja arvatud? Soovitav on kasutada
notatsiooni:
mõlemad otspunktid kaasaarvatud: [algus, lõpp],
mõlemad otspunktid väljaarvatud: ]algus, lõpp[,
esimene otspunkt kaasa arvatud, teine välja arvatud [algus, lõpp[,
esimene otspunkt välja arvatud, teine kaasaarvatud ]algus, lõpp]
Vähemalt üks AND ja OR samas lauses
Kui
tingimuste sidumisel on kasutatud vähemalt ühte ANDi ja ORi samas
lauses, siis kas tingimuste järjekord on üheselt mõistetav?
Näiteks kuidas mõista järgnevat lauset?
Süsteem
annab häire, kui lähenev objekt on ebasõbralik või tundmatu ja
liigub ülehelikiirusel.
Antud
lauset võib mõista kahel viisil:
Süsteem annab häire, kui lähenev objekt on (ebasõbralik või tundmatu) ja (liigub ülehelikiirusel)
Süsteem annab häire, kui lähenev objekt on (ebasõbralik) või (tundmatu ja liigub ülehelikiirusel)
Mitme
ANDi ja ORi kasutamisel võib arusaamatuste vältimiseks kasutada
mitut moodust:
Võib kasutada sulge nagu antud näite seletuses,
Võib kasutada loetelusid
Võib sellised “valemid” lihtsustada.
Ebamäärased terminid
Ebamäärasteks
terminiteks nimetab autor sõnu, mille tähendus on suhteline, ei ole
üheselt määratud. Sellisteks sõnadeks on näiteks suur,
väike, harva, tihti, kiiresti. Analoogsed
sõnad spetsifikatsioonis viitavad otsesele ebatäpsusele, mis hiljem
tekitab probleeme, kuna nendel sõnadel puutub ühene mõõt.
Seetõttu ei tohi spetsifikatsioon selliseid sõnu sisaldada vaid
need tuleks asendada konkreetselt mõõdetavate suurustega (koos
mõõtühikuga).
Spetsiifilised mõisted
Spetsifikatsioonide kirjutamisel tuleb jälgida, et kõik spetsiifilised mõisted oleksid eelpool defineeritud. Näiteks:
Süsteem
teavitab andmete saabumisest.
Et antud
juhul oleks spetsifikatsioon täielik, peab olema defineeritud, mida
tähendab mõiste “andmed” ning mida tähendab mõiste
“saabumine”.
Üldistus + mitmus
Kui on
kasutatud üldistusi (sõnad „kõik“, „paljud“, „mõned“)
+ mitmus, siis enamasti pole täpselt aru saada, mida sellise
konstruktsiooniga mõeldakse. Näiteks
Kõik lambid on seotud
lülitiga.
Sellisel
lausel on kaks erinevat tähendust:
Iga lamp on seotud oma lülitiga
Kõik lambid on seotud ühise lülitiga
Esimesel
juhul viidatakse eraldi igale 1 – 1 suhtele, teisel juhul on
tegemist ühe 1 – mitu suhtega.
Kui
soovitakse viidata igale hulga elemendile eraldi, tuleks kasutada
sõna “iga”:
Iga lamp on seotud
lülitiga.
Kui
soovitakse viidata koos kõigile hulga elementidele, võib kasutada
sõna “kõik” täpsustamiseks sõna “ühine”:
Kõik lambid on seotud
ühise lülitiga.
Üldistused
Üldistustele
viitavad sõnad ( Universal qualifiers)
spetsifikatsioonis on näiteks kõik,
iga, iialgi, alati. Igasuguste
üldistuste juures aga peab meeles pidama , et enamasti leidub igal
reeglil erandeid , millega peab arvestama. Erandite otsimine aitab
leida alternatiivseid stsenaariume.
Asukohakriitilised sõnad
Asukohakriitilisteks
sõnadeks nimetab autor sõnu, mille asukohast lauses sõltub lause
tähendus. Järgnevalt käsitletakse neist kolme: ainult, ka ning
isegi. Asukohakriitilised sõnad olenevad ka kasutatavast keelest.
Järgnevalt kirjeldatud sõnade puhul kehtivad samad reeglid nii
eesti- kui ingliskeelsete spetsifikatsioonide puhul, teiste keelte
puhul pole sobivust uuritud.
Ainult
Nagu
eelpool mainitud , on “ainult” üks nendest sõnadest, mille
asukohast lauses oleneb lause mõte. Seetõttu peavad kõik sõnad
„ainult“ asuma täpselt õiges kohas.
Grammatikareeglid
ütlevad, et sõna “ainult” limiteerib seda fraasi, millele ta
vahetult eelneb. Järgnevas näites liigutatakse sõna “ainult”
lauses ning vaadeldakse lause sisu muutumust.
Ainult Mari võtab oma koera kaasa.
Mari võtab ainult oma koera kaasa.
Mari võtab oma koera ainult kaasa.
Esimene
lause viitab sellele, et Mari on ainuke, kes oma koera kaasa võtab,
teised oma koera kaasa ei võta. Teises lauses viidatakse sellele, et
Mari võtab kaasa ainult oma koera ja mitte kedagi teist, ka mitte
kellegi teise koera. Kolmas lause ütleb, et Mari ei tee koeraga muud
kui võtab ta kaasa, ehkki ta võiks näiteks ka teda toita või
pesta.
Ka
Sõna
“ka” jagab sisuliselt sama saatust kui “ainult”. Samalaadselt
sõnaga “ainult” tuleb “ka” panna vahetult selle fraasi ette,
mille kohta ta kehtib. Järgnev näide illustreerib lause mõtte
muutumist selle sõna asukoha muutumisel.
Ka Mari võtab oma koera kaasa.
Mari võtab ka oma koera kaasa.
Mari võtab oma koera ka kaasa.
Isegi
Isegi
kuulub samasse gruppi, kuhu “ainult” ja “ka”. Erinevalt
nendest sõnadest aga on “isegi” kasutamine spetsifikatsioonides
üldiselt ebasoovitav, kuna tegemist on suhteliselt mitteformaalse,
emotsionaalse ning „nõrga“ väljendiga.
Lause
mõtte muutumist sõna asukoha muutumisel kirjeldab järgnev näide:
Isegi ma (mina) ei näinud teda eile.
Ma isegi ei näinud teda eile.
Ma ei näinud eile isegi teda.
Asesõnad ta, nad, see
Ainsuse
ja mitmuse kolmandat isikut väljendavad isikulised asesõnad “ta”
ja “nad” ning näitav asesõna “see” [9] puhul tuleb jälgida,
et see, millele nad viitavad, on üheselt mõistetav ja korrektse
tähendusega. Näiteks kuidas mõista lauset “Bob
ütles Joele, et ta peab lahkuma “?
Kas lahkuma peab Bob või Joe?
Teiseks
näiteks võiks olla lause “Igal
lambil on lüliti, mis ühendab teda üldsüsteemiga”.
Mis on selles aluses “teda”?
Kas “Igal lambil on lüliti, mis
ühendab lampi üldsüsteemiga” või
“Igal lambil on lüliti, mis ühendab
lülitit üldsüsteemiga”? Sellises
olukorras võib segaduste vältimiseks asesõna asemel korrata tegelikku sõna, nagu toodud eelnevas lauses.
Tüüp vs eksemplar
Tüüp
vs eksemplar – kas mõeldakse kõiki mingit tüüpi olemeid või
konkreetset tüübi eksemplari? “See
on kiire auto” – kas konkreetne
auto on kiire, või seda marki autod üldiselt on kiired?
Tingimuslausete täielikkus
Igal
tingimuslausel peab olema määratud, mis toimub, kui tingimus ei ole
täidetud, st peab eksisteerima “ else ”.
Tingimuslausete seotus õige alternatiiviga
Paljude
tingimuslausete korral tuleb jälgida nende omavahelist järjekorda
ning if
osa vastamist korrektsele else-osale.
Ülevaatlikkuse ja selguse saavutamiseks on soovitav kasutada
programmeerimisest tuntud treppimist või hierarhilist numeratsiooni.
Kolme või enama osapoole võrdlus
Võrdlus
kolme või enamat osapoole vahel. Näiteks “Juhan tunneb veel
rikkamat meest kui Jaan”. Kas Juhani tutvusringkonnas on keegi
Jaanist veel rikkam mees? Või hoopis on Juhani tutvusringkonnas
rikkam mees kui Jaani tutvusringkonnas?
Protsessi kirjeldava tegusõna täielikkus
Kas
iga protsessi kirjeldava tegusõna (process verb ) kohta on vastatud küsimustele:
kes viib protsessi läbi? Kelle heaks? Millal? Mis on tulemus? Kuidas? Küsimus “Kuidas?” ei käi siinkohal mitte realisatsiooni
kohta vaid selle kohta, milliste sammudena protsess läbi viiakse.
Näiteks “Süsteem teavitab, kui
andmed saabuvad”. Eeldusel, et
“andmed” ja “saabumine” on eelnevalt defineeritud (vt punkt
4), peavad täielikus spetsifikatsioonis olema vastatud küsimused:
Kes teavitab? Mida teavitatakse? Kuidas toimub teavitamise protsess,
mil viisil? Kellele? Millal?
Protsessi kirjeldavate nimisõnade täielikkus
Olukord
on analoogne protsessi tegusõnadega. Moonutused tekivad protsessi
väljendavate sõnade (tegusõnade) viimisel nimisõna vormi ehk
sündmuseks. Näiteks “Andmete
saabumisest peab teavitatama”
– Ka nimisõna vormis oleva tegusõna puhul peavad olema vastatud
küsimused: kes? Millal? Kelle heaks? Mis on tulemus? Kuidas?
Lõpetamata loetelud
Lõpetamata
loeteludeks nimetab käesoleva töö autor fraase, milles viidatakse loetelu jätkumisele, kuid pole võimalik üheselt kindlaks määrata,
millised elemendid on välja jäetud. Lõpetamata loetelule viitavad fraasid on näiteks “ja nii edasi”,
“ja teised”,
“või muu sarnane”
loetelu lõpus, ka sõna “näiteks”
kasutus viitab lõpetamata loetelule.
Lõpetamata
loetelu pole kindlasti üheselt mõistetav, seega tuleb
spetsifikatsioonides kõik sellised fraasid eemaldada, eelnevalt
välja selgitades nende taga peituva informatsiooni
Lisa 2 – Spetsifikatsiooni mitmetimõistetavust leida võimaldav küsimustik
Vastavalt
Lisas 1 toodud mitmetimõistetavuste allikatele saab kokku panna
järgneva küsimustiku, mis aitab juhtida tähelepanu
spetsifikatsiooni mitmetimõistetavustele.
Kas spetsifikatsioonis kirjeldatud vahemike otspunktid on üheseltmõistetavalt defineeritud?
Kui tingimuste sidumisel on kasutatud vähemalt ühte ANDi ja ORi, siis kas tingimuste järjekord on üheselt määratud?
Kas spetsifikatsioonis on kasutatud ebamääraseid termineid?
Kas spetsiifilised mõisted on eelnevalt defineeritud?
Kas on kasutatud üldistusi (kõik, paljud, mõned) koos mitmusega?
Kui on kasutatud üldistusi (kõik, iga, iialgi, alati), siis kas on kindel, et ei leidu erandeid?
Kas on kasutatud lõpetamata loetelusid (täpsustamisel, jne, vms)?
Kas kõik sõnad “ainult” asuvad lauses õigel kohal?
Kas kõik sõnad “ka” asuvad lauses õigel kohal?
Kas kasutatakse sõna “isegi” ning kas see asub lauses õigel kohal?
Kas “ta”, “nad”, “see” viitavad sellele, millele vaja?
Kas esineb “tüüp vs eksemplar”-mitmetimõistetavust? Kas on üheselt aru saada, kas objekti puhul mõistetakse kõiki objekte mingist klassist või konkreetset eksemplari?
Kas kõigil tingimuslausetel on määratud ka see, mis juhtub siis, kui tingimused pole täidetud?
Kas kõik tingimuslaused on seotud õige alternatiiviga?
Kas kolme või enama osapoolega võrdlused on üheselt mõistetavad?
Kas kõik protsessi kirjeldavad tegusõnad on täielikult defineeritud?
Kas kõik protsessi kirjeldavad nimisõnad on täielikult defineeritud?
10 punkti
Autor soovib selle materjali allalaadimise eest saada 10 punkti.
~ 27 lehte
Lehekülgede arv dokumendis
2018-07-08
Kuupäev, millal dokument üles laeti
11 laadimist
Kokku alla laetud
0 arvamust
Teiste kasutajate poolt lisatud kommentaarid
urmash
Õppematerjali autor
annaabi.ee 
Kõik kommentaarid