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
© Copyright 2024