Tekniikkakartta

Testaustekniikat
Tekniikkakartta
Tekniikoita luokiteltuna
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Testaustekniikat
• Erilaisten testaustekniikoiden lista on todella pitkä
• Tekniikoiden nimeäminen on epäkonsistenttia
• Tavoitteena kyky soveltaa oikeaa tekniikkaa oikeassa
tilanteessa
– Vaikea ymmärtää mihin tilanteeseen tietty tekniikka sopii
– Vaikea ymmärtää miten tiettyä tekniikkaa pitäisi soveltaa
• Luokittelemme tekniikat soveltamistilanteen mukaan jotta
voidaan havainnollisesti nähdä mitä tekniikkaa tai tai
tekniikoiden yhdistelmää kulloinkin kannattaa käyttää
– --> tekniikkakartta
– black-box vs. white-box ja staattinen vs. dynaaminen ovat
tekniikoiden luokittelua irrallaan soveltamisesta eivätkä siksi
havainnollisia käytännössä
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
1
Tekniikkakartta
•
1)
2)
3)
4)
5)
Mikä tahansa tekniikka voidaan kuvata viiden sen
soveltamiseen liittyvän näkökulman mukaan
Testaaja: kuka testaa?
Kattavuus: mitä osaa tai näkökulmaa
ohjelmistosta testaan?
Testauksen syy: mikä mahdolinen ongelma tai
riski motivoi testauksen?
Testaustapa: miten testataan?
Tulosten arviointi: mistä tiedetään testin tulos
(pass/fail)?
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Kartan soveltamisohje
• Jokaisessa käytännön testaustilanteessa on mukana kaikki
viisi näkökulmaa
• Tyypillisesti testaustekniikka ohjeistaa yhtä tai kahta
näkökulmaa eikä ota kantaa muihin näkökulmiin
• Testaaja voi
– Laajentaa ja sovittaa tekniikkaa oman ammattitaitonsa perusteella
– Yhdistellä tekniikoita jotka ohjeistavat eri näkökulmia
• Kummassakin tapauksessa testaaja tavallaan luo uuden
tekniikan
– Kytkös yrityksen prosessien kehittämiseen, kehitetyt tekniikat
käytettäväksi tulevissa hankkeissa
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
2
Esimerkkejä
• Usein testaustehtävät annetaan vain yhden tai kahden
näkökulman suhteen
• Tehtävä: ‘toiminnallinen testaus’
– Avoimeksi jää kuka testaa, mihin virheisiin pitäisi keskittyä, millä
perusteella ja työkaluilla ja missä ympäristöissä testataan, mikä
määrää oikean testituloksen
• Tehtävä: ‘ääriarvotestaus’
– Tiedetään mitä ongelmia etsitään, muu avoinna
• Tehtävä: “vaatimusperustainen testaus”
– Monimielinen, voi kiinnittää ohjeistaa mitkä tahansa seuraavista
• Kattavuus - testaa kaikki vaatimuksissa määritelty toiminnallisuus
• Testauksen syy - testaa monipuolisesti tärkeää vaatimusta
• Tulosten arvionti - suunnittele sellaiset testit että
vaatimusdokumentin perusteela voidaan päätellä testin tulos
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Testaaja
Tekniikkakartta
• Käyttäjätestaus (user testing)
–
–
–
–
Testauksen suorittavat henkilöt jotka käyttäisivät tuotetta
Voidaan käyttää kehtyksen aikana tai lopussa
Ohjattuja ‘harjoituksia’ tai vapaata käyttäjän testailua
Yhteistestaus testaajan ja käyttäjän kanssa, tehtäväanalyysi
• Buginmetsästys (bug bash)
– Organisaation sisäinen testi, testaajina ohjelmoijat, myyjät,
sihteerit, kuka tahansa joka on saatavilla
– Intensiivinen esim. yhden päivän kesto
– Kevyesti suunniteltu ja ohjeistettu
• Alfatestaus (alpha testing)
– Kehittäjäorganisaation testaustiimin testaus koko tuotteelle.
• Eat your own dogfood
– Kehittäjäorganisaatio käyttää raakileversioita tuotteesta itse.
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
3
Testaaja
Tekniikkakartta
• Betatestaus (beta testing)
– Testaajat ovat kehittäjäorganisaation ulkopuolisia, kuuluvat
tuotteen kohdemarkkinaan
• Keskimääräistä käyttäjää suurempi asiantuntemus toimialan tuotteista
– Useita eri tyyppisiä (eri testauksen syy)
– Suunnittelubeta
• Toteutuksen perusratkaisujen evaluointi toimialan asiantuntijoilla
• Käytetään mahdollisimman aikaisin
– Markkinointibeta
• Varmistetaan markkinaosuutta, tavoitteena saada asiakas odottamaan
tuotetta kilpailevan jo markkinoilla olevan tuotteen hankinnan sijaan
• Käytetään lähes virheettömälle tuotteelle
– Yhteensopivuusbeta
• Asiakkaat testaavat tuotetta laite- ja ohjelmistoympäristöissä joita on
vaikea toteuttaa kehitysorganisaatiossa
• Mahdollisimman aikaisin sillä bugit aiheuttavat suurehkoja muutoksia
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Kattavuus
Tekniikkakartta
• Funktiotestaus (function testing)
– Testataan funktio kerrallaan läpikotaisin
– White-box toimintotestaus ~ yksikkötestaus, testaa toimintoja
irrallaan kokonaisuudesta
– Black-box toimintotestaus ~ testaa toimintoja asiakkaan
näkökulmasta
• Toiminnon integrointitestaus (function, feature
integration testing)
– Testataan toimintoja yhdessä tai uutta toimintoa osana
järjestelmää
– Keskeinen ketterässä kehityksessä
• Menu tour
– Kaikki valikkotoiminnot
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
4
Kattavuus
Tekniikkakartta
• Spesifikaatioperustainen testaus
– Testaus joka pyrkii verifioimaan jokaisen väitteen mitä
spesifikaatio tuotteesta sanoo
– Kehityksen aikaisten spesifikaatioiden testausta tai manuaalien,
markkinointimateriaalin ... testausta
• Vaatimusperustainen testaus
– Testaus joka varmistaa että kaikki vaatimusdokumentissä mainitut
tuotteen ominaisuudet on toteutettu ja toimivia
– Käytetään usein sopimukseen kirjattujen vaatimusten
varmistamiseen
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Kattavuus
Tekniikkakartta
• Domaintestaus (arvoaluetestaus?)
– Arvoalue on kaikkien mahdollisten syöte/tulos parien joukko
– Keskitytään siihen mitä arvoja testauksessa muuttujat (joko syöte tai
tulos) saavat, ei yksittäisten funktioiden testaukseen
– Tyypillisesti yhtä funktiota testataan monilla arvoilla ja yksillä arvoilla
testataan useita funktioita(toimintoja).
– Perusajatuksena jakaa koko arvoalue luokkiin ja valita edustaja jokaisesta
luokasta siten että edustajan testitulos yleistyy koko luokalle
• Tapoja muodostaa arvoalueen luokat
– Ekvivalenssiluokka analyysi
– Ääriarvo testaus (boundary testing)
• Tilaperustainen testaus (state based testing)
– Tilakoneella mallinnetaan ohjelmiston käyttäytyminen ja käytetään
tilakonetta generoimaan testitapauksia tai arvioimaan testien kattavuutta
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
5
Kattavuus
Tekniikkakartta
• Polkutestaus (path testing)
– Testataan erilaisia polkuja jotka johtavat ohjelman tiettyyn tilaan
– Polku on joko käyttäjän tekemät ‘askeleet’ (black-box) tai ohjelman
suorituksen lauseet (white-box)
• Lause- ja haarautumiskattavuus (statement, branch coverage)
– Pyritään kattamaan testeillä mahdollisimman suuri osa ohjelman lauseista
– Työkaluilla arvioitavissa automaattisest
– Kykenee havaitsemaan vain hyvin rajallisen joukon bugeja, siksi 100%
lausekattavuus on virheellinen turvallisuudentunne
– Hyödyllinen osoittamaan testaus riittämättömäksi
• Konfiguraatiokattavuus
– Pyritään testaamaan kaikki oleelliset laite- ja ohjelmistokonfiguraatiot
– Usein kallista ja hankalaa
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Testauksen syy
Tekniikkakartta
• Riskiperustainen testaus (1)
– Testausta tehdään suoraan kustannusperusteisesti
– Prioriteetti: todennäköisyys jonkin toiminnon toimimattomuudelle
* kustannus joka siitä aiheutuisi
– Bottom-up tapa kohdentaa testauspanostus
• Riskiperustainen testaus (2)
– Käytetään riskejä lähtökohtana testattavien mahdollisten
ongelmien löytämiseksi
– Millä tavoin jokin ominaisuus voi toimia väärin?
– Miten se havaittaisiin, miten sitä voi testata ?
– Missä olosuhteissa virhe tapahtuisi ?
– Top-down, perinteinen riskinhallinta
• Järjestelmätestauksen erityismuodot
– Suorituskyky-, tietoturva-, kuormatestaus...
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
6
Testauksen syy
Tekniikkakartta
• Test-to-pass: Testausstrategia, jossa
ohjelmistoa käsitellään “silkkihansikkain” ja jonka
tarkoitus on varmistaa perustoiminnallisuus
• Test-to-fail: Testausstrategia, jossa
ohjelmistosta yritetään tarkoituksella saada
virheitä esiin
• Varmista aina ensin perustoiminnallisuus
• Täysimittaista järjestelmätestausta ei kannata
aloittaa ennen kuin perustoiminnallisuus on
kunnossa
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Testaustapa
Tekniikkakartta
• Regressiotestaus
– Uudelleenkäytetään aikaisempia testejä muutoksen jälkeen ja
varmistetaan että muutos ei rikkonut tuotetta
– Kolme perustyypiä: bugin korjaus-, muutoksen sivuvaikutus- ja
vanhat bugit-regressiotestaus.
• Exploratory testing
– Testaaja oppii jatkuvasti hankkeen aikana tuotteesta ja sen
riskeistä ja osaa näin kohdentaa testausta
– Uusia testejä tehdään jatkuvasti sen mukaan mitä informaatiota
edellisillä testeillä saadaan tuotteesta
– Muistuttaa ad-hoc testausta mutta on suunnitelmallista ja
systemaattista
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
7
Testaustapa
Tekniikkakartta
• Skenariotestaus (scenario testing)
– Testataan järjestelmän käytön tärkeitä, tavoitteellisia kokonaisuuksia
jotka ovat
•
•
•
•
Realistisia, jotain mitä asiakas todella tekee tuotteella
Monimutkaisia, sisältäen useita toimintoja
Helppo todeta testin tulos
Jos bugeja löytyy ne on käytännössä pakko korjata
– Testien laadinta työlästä
• Skriptattu testaus (scripted testing)
– Manuaalista testausta, tyypillisesti kokematon testaaja ohjeiden mukaan
• Savutestaus (smoke testing)
– Pyritään osoittamaan kevyellä ja nopealla testauksella että järjestelmä ei
ole kunnolliseen testaukseen kypsä.
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Tulosten tarkastelu
Tekniikkakartta
• Itse-verfiova data
– Testauksessa käytettävä data sisältää tiedon jonka perusteella nähdään
heti onko tulos odotettu vai ei
– Tiedon lataaminen, siirtäminen ...
• Vertaaminen talletettuihin tuloksiin
– Regressiotestauksessa voidaan verrata testiajon tuoksia edellisellä kerralla
ajettujen samojen testien tuloksiin
• Vertaaminen spesifikaatioon tai muuhun dokumenttiin
– Eroavaisuus spesifikaatiossa määritetystä toiminnasta on virhe, joko
tuotteessa tai spesifikaatiossa
• Oraakkeli
– Oraakkeli on työkalu joka kertoo onko testi onnistunut vai ei
– Oraakkeli on usein toinen ohjelmisto joka generoi testituloksia ja vertaa
niitä SUT:n tuottamiin
– Oraakkelin oikeellisuuteen luotetaan
– Isojen volyymien automaattinen testaus
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
8
Tulosten tarkastelu
Tekniikkakartta
•
Heuristinen johdonmukaisuus (Heuristic
consistency)
–
–
1)
2)
Epäjohdonmukaisuus on yleensä merkki virheestä
Evaluointi yleensä testaajan ammattitaidosta riippuvaa
Ajallinen johdonmukaisuus: toiminto toimii kuten ennenkin
Vastaavat tuotteet: toiminto on samanlainen kuin vastaavilla
tuotteilla
3) Käyttäjän odotukset: toiminto on konsistenttia sen kanssa mitä
käyttäjät siltä yleisesti odottavat
4) Tuotteen sisäinen: toiminto on konsistentti tuotteen muiden
toimintojen kanssa
5) Tarkoitus: toiminnon tulos on johdonmukainen sen ilmeisen
tarkoituksen kanssa
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Luokittelun käyttöohje
• Edellä luokittelu vain yhden näkökulman mukaan, monet
kuuluvat kuitenkin useaan näkökulmaan
• Esimerkki: Kuormatestauksen voi nähdä joko testauksen
syynä tai testaustapana
– Riskiperustainen kuormatestaus testaa jotain ennakoitua riskiä ja
miten järjestelmä siitä selviää (esimerkiksi DoS hyökkäys)
– Kuormatestaus testaustapana ohjeistaa testausjärjestelyn jolla
kyetään mallintamaan järjestelmän todellisen kuormankeston
testaus
• Esimerkiksi mallinnetaan eri käyttöskenarioiden frekvenssit ja tehdään
testiympäristö joka tämän frekvenssin mukaisesti luo käyttösessioita
ja suorittaa niissä ko. skenaariota
• Molemmat luokittelut oikein, oleellista on ymmärtää mitä
tekniikka antaa ja mitä on vielä testauksessa
suunnittelematta (muut näkökulmat).
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
9