2. Äärelliset mallit (P&Y: 5) Malli (model) on kuvaus, joka on kuvattavaa kohdetta yksinkertaisempi, mutta joka säilyttää (mahdollisimman hyvin) mallinnettavan kohteen tarkasteltavat ominaisuudet. Hyvä malli on kompakti: mallin täytyy olla hallittavan kokoinen, ennustava: mallin avulla on voitava ennustaa mallinnetun kohteen käytöstä, semanttisesti mielekäs: mallin ennusteesta on voitava tehdä mallinnettavaa kohdetta kuvaavia syy-seuraussuhteita ja riittävän yleinen: mallin täytyy olla sellaisella tasolla, että siitä johdetut tulokset ovat yleistettävissä käytännön sovelluksiin. Ohjelmistojen testaus / Taina 25 Lähdekoodin suorituksen malli Ohjelman lähdekoodista on mahdollista tehdä malli, joka kuvaa ohjelman lauseiden suhdetta toisiinsa. Yleensä malli kuvataan suunnattuna verkkona, jossa jokainen lause on solmu ja jokainen siirtymä lauseesta toiseen on särmä. Tällainen malli on ennustava: seuraamalla reittejä solmujen välillä on mahdollista ennustaa mallinnetun ohjelman toimintaa, semanttisesti mielekäs: ennusteesta on mahdollista päätellä, onko toiminta ollut oikein (esimerkiksi tarkastelemalla, mitä reittiä ohjelma päätyi lopputulokseen) ja riittävän yleinen: mallia voidaan käyttää minkä tahansa lähdekoodin kuvaukseen. Malli ei ole normaalien ohjelmien kohdalla kompakti, minkä johdosta sillä yleensä mallinnetaan pientä osajoukkoa ohjelmasta esimerkiksi yhtä metodia. Ohjelmistojen testaus / Taina 26 Ohjausvuokaaviot Ohjausvuokaavio, OVK (control flow graph) on metodista tehty suunnattuna verkkona kuvattu malli, jonka solmut ovat ohjelmakoodin osia ja särmät ovat mahdollisia siirtymiä koodin osien välillä. Solmujen koko voi olla periaatteessa lauseita tai jopa konekielikäskyjä, mutta yleensä samaan solmuun laitetaan kaikki lauseet, jotka on pakko suorittaa peräkkäin. Tällaisia lausejoukkoja kutsutaan lauseiden peruslohkoiksi (basic block). Peruslohkojen avulla OVK:ssa on mahdollisimman vähän solmuja: vähintään joka toisesta solmusta lähtee ainakin kaksi särmää. Ohjelmistojen testaus / Taina 27 Haarautumien kuvaaminen ohjausvuokaavioissa Kun OVK:ssa on haarauma, se tarkoittaa, että vastaavassa kohdassa ohjelmakoodia on ehto. Ehto voi olla totuusarvoinen (if-lause, while-lause, do-while lause, for-lause), jolloin solmusta lähtee kaksi särmää. Ehto voi olla moniarvoinen (switch-lause), jolloin solmusta lähtee n tai n+1 särmää, missä n on case-vaihtoehtojen lukumäärä. Tapaus +1 tulee mahdollisesta default-haarasta. Myös poikkeuskäsittelyssä voi olla monta haaraa, mutta näitä on vaikea mallintaa OVK:lla. Ohjelmistojen testaus / Taina 28 Atomiset ehdot Jos OVK:sta halutaan mahdollisimman täydellinen, ehdot pitää rikkoa atomisiksi ehdoiksi (basic condition (kirjan termi) tai atomic expression). Atominen ehto on ehto, joka ei sisällä operaattoreita AND, OR, XOR, NOT, jne. Esimerkiksi Java-ehdossa (((a < 0 a > 100) && b!= 0) c == 0) &&!e) on viisi atomista ehtoa: a<0, a>100, b!=0, c==0, e Ohjelmistojen testaus / Taina 29 Atomiset ehdot OVK:ssa OVK:ssa atomiset ehdot esitetään solmuina, joiden välillä on särmät kuvaamassa evaluoinnin etenemistä atomisesta ehdosta toiseen. Jos kielessä lasketaan atomisia ehtoja vain niin pitkälle, kunnes lopullinen tulos tiedetään, vain sellaiset särmät otetaan mukaan, jotka kuvaavat todellista laskentaa. Näin tehdään esim. Javassa. Jos kielessä lasketaan kaikkien atomisten ehtojen arvo ennen lausekkeen arvon laskemista, jokaisesta atomisesta ehdosta lähtee kaksi särmää. Näin tehdään esim. Pascalissa. Ohjelmistojen testaus / Taina 30 (c) Juha Taina, 2007 1
Muutama OVK:n ohjausrakenne OVK-esimerkki Seuraavassa ovat oppikirjan versiot iflauseesta, while-lauseesta ja switchlauseesta: Ohjelmistojen testaus / Taina 31 (Vastaava Java-metodi on oppikirjan sivulla 61) Ohjelmistojen testaus / Taina 32 Kutsuverkot Edelliset ohjausvuokaaviot kuvasivat metodien sisäisiä suorituspolkuja. Vastaavalla tavalla voidaan kuvata metodien välisiä suorituspolkuja. Yksinkertaisin metodien välisten suorituspolkujen malli on kutsuverkko (call graph). Siinä solmut ovat metodeja ja särmät metodien kutsuja. Kutsuverkot ovat usein liiankin kompakteja. Ne jättävät niin paljon tietoja pois, että yleensä niiden ennustavuus ja semanttinen mielekkyys kärsivät. Kutsuverkot ovat parhaimmillaan hahmotettaessa laajan ohjelmiston kutsusuhteita. Sen sijaan ne eivät sovi kovin tarkkaan analyysiin. Äärelliset automaatit Edelliset mallit voidaan generoida suoraan lähdekoodista. Ne kuvaavat ohjelman rakennetta enemmän kuin toiminnan logiikkaa. Äärelliset automaatit (finite state machines) ovat lähdekoodista riippumattomia. Ne kuvaavat tiloja (states) ja siirtymiä (transitions) tilojen välillä. Äärellinen automaatti on aina jossakin tilassa. Kun automaatti saa herätteen, se siirtyy tilasta siirtymän kautta toiseen tilaan. Äärelliset automaatit kuvataan suunnattuina verkkoina, joissa jokainen solmu on tila ja jokainen nimetty särmä siirtymä tilasta toiseen. Särmän nimi kertoo samalla, millä herätteellä siirtymä toteutuu. Ohjelmistojen testaus / Taina 33 Ohjelmistojen testaus / Taina 34 Äärellisen automaatin ominaisuudet Äärellinen automaatti on mallina ennustava: mallin avulla voidaan ennustaa koko mallinnettavan kohteen elinkaari, semanttisesti mielekäs: mallilla voidaan tehdä ennusteita mallinnettavan kohteen toiminnasta ja riittävän yleinen: mallista saatavat tulokset ovat helposti yleistettävissä käytännön sovelluksiin, kunhan mallinnetun kohteen tilakäytös vastaa mallia. Äärellinen automaatti ei yleensä ole kompakti. Vähänkään monimutkaisempaa järjestelmää mallinnettaessa tapahtuu tilaräjähdys (state explosion). Tilojen ja varsinkin siirtymien määrä kasvaa hallitsemattoman suureksi. Äärellisten automaattien esimerkki Ohjelmistojen testaus / Taina 35 Ohjelmistojen testaus / Taina 36 (c) Juha Taina, 2007 2
3. Testitapausten valinta ja sopivuus (P&Y:9) Nyt jätämme toistaiseksi analyysin ja keskitymme puhtaasti testaukseen. Ohjelmisto, jolle on tehty systemaattinen testaus, on luultavasti luotettavampi kuin ohjelmisto, joka on testattu satunnaisesti. Jokainen ohjelmiston osa pienimmästä suurimpaan pitää testata perusteellisesti ja systemaattisesti ennen sen liittämistä valmiiseen tuotteeseen. Mutta mitä perusteellinen ja systemaattinen testaus tarkoittaa? Ohjelmistojen testaus / Taina 37 Systemaattisuus ja perusteellisuus Systemaattisuus on helppo määritellä. Systemaattinen testaus tarkoittaa, että testaukselle on määritelty prosessi tai prosesseja, joita noudatetaan kaikessa testauksessa. Perusteellisuus on vaikeampi termi. Se pitäisi määritellä tarkoittamaan testausta, joka varmistaa, että ohjelmisto on oikeellinen. Valitettavasti näin sitä ei voida määritellä, sillä ohjelmiston oikeellisuutta ei voida verifioida. Ohjelmistojen testaus / Taina 38 Riittävyys Perusteellisuuden sijaan puhutaan riittävyydestä (adequacy). Testaus on riittävää, kun se täyttää sille asetetut ehdot. Riittävyys on mukava termi, sillä sen määritelmä riippuu testattavan ohjelmiston lisäksi testaavasta organisaatiosta: testaus on riittävää, kun sitä on tehty yrityksen strategian kannalta tarpeeksi. Toki yleensä kunkin yrityksen määrittelemä testauksen riittävyys riippuu testausteoriasta, mutta riittävyyden määritelmä ei vaadi sitä. Ohjelmistojen testaus / Taina 39 Testauksen terminologiaa Ohjelma (program): testattava suorituskelpoinen osa. Ohjelman koko voi vaihdella sovelluksesta metodiin. Testitapaus (test case): Joukko syötteitä, suoritusehtoja ja hyväksymisehto. Testitapausmäärittely (test case specification): Jokin vaatimus (requirement), jonka yksi tai usea testitapaus täyttää. Testipaketti (test suite): Testitapausten tai testipakettien joukko, joilla on yhteinen tavoite. Testi tai testin suoritus (test or test execution): Ohjelman suorittaminen testitapauksen syötteillä ja tuloksen arviointi testitapauksen hyväksymisehdolla. Riittävyysehto (adequacy criterion): totuusarvo tosi/epätosi parille <ohjelma,testipaketti>. Riittävyysehto määrittelee, onko ohjelmalle tehty testipaketti testannut ohjelmaa riittävästi. Ohjelmistojen testaus / Taina 40 Testitapaus Testitapaus sisältää kaiken sen informaation, joka tarvitaan sitä vastaavan testin suoritukseen ja tulosten analysointiin. Testitapauksen syöte voi olla mikä tahansa ohjelman tapahtuma, esimerkiksi keskeytys. Testitapauksen suoritusehto on ehto, jonka on oltava voimassa testauksessa, esimerkiksi muuttujien alustus. Testitapauksen hyväksymisehto on ehto, jonka on oltava voimassa testin suorituksen jälkeen. Hyväksymisehto kertoo, menikö testi läpi. Testitapausmäärittely Jos testitapauksen analogia ohjelmistotuotannossa on valmis ohjelmisto, niin testitapausmäärittelyn analogia on ohjelmiston määrittelydokumentti. Testitapausmäärittely listaa ne vaatimukset, jotka sen mukaisten testitapausten tulee täyttää. Yhden testitapausmäärittelyn voi täyttää usea testitapaus ja testitapaus voi täyttää usean testitapausmäärittelyn. Ohjelmistojen testaus / Taina 41 Ohjelmistojen testaus / Taina 42 (c) Juha Taina, 2007 3
Lisää testitapausmäärittelyistä Testitapausmäärittelyt johdetaan järjestelmän, ohjelmiston, moduulin tai luokan spekseistä (eli määrittelystä). Testitapausmäärittely voi syötemäärittelyjen lisäksi käyttää hyväksi mitä tahansa spekseissä kuvattua havaittavaa toimintaa. Esimerkiksi laitteiston hajoamisesta seuraavat poikkeustilanteet ovat hyviä testitapausmäärittelyiden lähtökohtia. Mitä formaalimpi on speksi, sitä täsmällisemmät ovat testitapausmäärittelyt. Ohjelmistojen testaus / Taina 43 Riittävyysehto Testipaketti täyttää riittävyysehdon, jos sen jokainen suoritettu testi täytti hyväksymisehdon ja kaikki testipaketille asetetut vaatimukset täyttyivät testeillä. Oppikirja puhuu testien sitoutumisesta (test oblication): testin sitoutuma on jokin täsmällinen ehto, jonka testitapauksen tulee täyttää. Esimerkiksi jos testipaketin riittävyysehto on, että jokainen metodin lause suoritetaan ainakin kerran, niin tietyn testin sitoutuma voi määritellä, minkä osan metodin lauseista kyseisen testin tulee ainakin suorittaa. Ohjelmistojen testaus / Taina 44 Riittävyysehdon valinta Riittävyysehdon valinnassa on oltava tarkkana. Liian tiukka riittävyysehto tarkoittaa, että yksikään testipaketti ei voi täyttää ehtoa. Liian löysä riittävyysehto voi tarkoittaa, että tuotteen laatu kärsii kohtuuttomasti. Riittävyysehdon valinta on strategiakysymys: kuinka paljon olemme valmiit ottamaan riskiä. Kevyellä riittävyysehdolla säästetään testauksen resursseissa, mutta samalla kasvatetaan riskiä, että tuote ei ole hyödyllinen. Ohjelmistojen testaus / Taina 45 Riittävyysehtojen vertailu Riittävyysehdot voidaan laittaa osittaisjärjestykseen sen mukaan, miten hyvin niillä löydetään virheitä. Osittaisjärjestys voidaan tehdä empiirisesti keräämällä tietoa löydetyistä virheistä. Tällöin tuloksissa on paljon epävarmuutta, sillä testauksen onnistuminen riippuu lukemattomista tekijöistä. Speksien taso, testattava yksikkö, testaajat, testausajankohta, ym. vaikuttavat tulokseen. Ohjelmistojen testaus / Taina 46 Riittävyysehtojen sisältyvyys Riittävyysehtoja voidaan verrata analyyttisesti sisältää-relaation (subsumes) avulla. Jos jokainen testipaketti, joka täyttää riittävyysehdon A, täyttää myös riittävyysehdon B, niin A sisältää B:n: Testikattavuuskriteeri (riittävyysehto) A sisältää testikattavuuskriteerin B, jos ja vain jos kaikille ohjelmille P pätee: jokainen A:n täyttävä testijoukko P:ssa täyttää myös B:n. Eli jos ehto A:n täyttämillä testeillä saadaan myös B:n täyttämät testit, niin A sisältää B:n. Ohjelmistojen testaus / Taina 47 Riittävyysehtojen sisältyvyyden merkitys Valitettavasti riittävyysehtojen sisältyvyys ei ole niin vahva tulos kuin miltä se kuulostaa. Voi olla, että A:n täyttämällä testipaketilla ei löydetä lainkaan B:n testipaketista poikkeavia virheitä tai A:n täyttämiseen vaaditaan paljon enemmän testejä kuin B:n täyttämiseen. Sisältyvyyttä mielenkiintoisempi mittari olisi testipaketin koko. Jos riittävyysehdolla A tietyn virheen löytämiseen tarvitaan vähemmän testejä kuin riittävyysehdolla B, niin silloin A paremmalta ehdolta tämän virheen etsinnässä kuin B. Valitettavasti tällaista relaatiota ei voida yleisessä tapauksessa käsitellä analyyttisesti, koska emme yleensä tiedä etukäteen, mitä testejä virheen löytymiseen vaaditaan. Ohjelmistojen testaus / Taina 48 (c) Juha Taina, 2007 4
4. Toiminnallinen testaus (P&Y: 10) Ohjelman toiminnallinen määrittely (functional specification) on tärkein testitapausmäärittelyjen syöte. Toiminnallisesta määrittelystä johdettujen testien suoritusta sanotaan toiminnalliseksi testaukseksi (functional testing) tai mustalaatikkotestaukseksi (black-box testing). Toiminnallisessa testauksessa vain ohjelmaa kuvaavat määrittelyt vaikuttavat testaukseen. Ohjelman rakenteella ei ole merkitystä. Ohjelmistojen testaus / Taina 49 Miksi toiminnallista testausta? Toiminnallinen testaus (tt) on perustestausta: Tt aloitetaan heti vaatimusmäärittelyssä suunnittelemalla testitapausmäärittelyjä. Tt:lla löydetään sellaisia virheitä, joita on vaikea tai mahdoton löytää muilla keinoilla. Tt:n tekniikoita voidaan soveltaa riippumatta siitä, millä tasolla ohjelman toiminnallinen määrittely on annettu. Tt:n tekniikat sopivat kaikenkokoisten ohjelmien testaamiseen metodeista ohjelmistoihin. Tt on yleensä halvin ja helpoin suunniteltava. Ohjelmistojen testaus / Taina 50 Ositus Toiminnallinen testaus perustuu ositukseen (partitioning). Testattavan ohjelman mahdolliset toimintatavat ositetaan homogeenisiksi luokiksi, joista jokainen kuvaa yhtenevän tavan käyttää ohjelmaa. Jokaista luokkaa kohti suunnitellaan sopivat testitapausmäärittelyt ja kirjoitetaan niihin sopivat testitapaukset. Jos ositus on tehty hyvin, luokat ovat ulkoisesti erillisiä ja sisäisesti yhteneviä: Ulkoisesti erillisiä = luokkien leikkaukset ovat tyhjiä. Sisäisesti yhteneviä = luokan sisällä kaikki ohjelman toimintatavat käyttävät ohjelmaa samalla tavalla. Ositus 2 Koska ohjelman toiminta riippuu vain syötteistä, ositus tehdään syötteille. Esimerkiksi palvelupyyntö, skedulointi ja keskeytys ovat syötteitä. Onnistuneessa osituksessa osajoukon toiminta millä tahansa osajoukon syötteellä on yhtenevää. Esimerkiksi ohjelmalla, joka palauttaa syötteenä saamansa luvun x käänteisluvun, ositus voi olla luvut x!= 0 ja x=0. Ehdolla x!= 0 ei ole väliä, mikä luku valitaan testitapaukseksi. Ohjelman pitäisi käyttäytyä kaikilla luvuilla x!= 0 samalla tavalla. Jos ohjelma ei käyttäydy arvoilla x!= 0 samalla tavalla, ositus (tai ohjelma) on pielessä. Ohjelmistojen testaus / Taina 51 Ohjelmistojen testaus / Taina 52 Testitapausten johtamisen haasteet Testitapausten johtaminen määrittelystä vaatii lukemattomien muuttujien huomiointia. Syötteet ja tulosteet on tunnistettava. Syötteiden ja tulosteiden arvoalueet on tunnistettava. Ohjelmaan kohdistuvat tapahtumat on tunnistettava. Poikkeustilanteet on tunnistettava jne. Kun vielä määrittely voi olla vajaa, niin testitapausten johtaminen on virhealtista työtä. Satunnaistestaus Testitapausten suunnittelu ja kirjoittaminen on sekä hidasta että virhealtista. Ei siis ihme, että prosessia haluttaisiin yksinkertaistaa. Eräs tapa korvata suunnitteluprosessia olisi testata raa alla voimalla kaikki mahdollinen. Valitettavasti resurssit eivät riitä tähän. Koska kaikkea ei voida testata, niin ehkä voisimme testata satunnaisesti joillain arvoilla? Tätä kutsutaan satunnaistestaukseksi (random testing). Ohjelmistojen testaus / Taina 53 Ohjelmistojen testaus / Taina 54 (c) Juha Taina, 2007 5
Satunnaistestauksen edut ja haitat Satunnaistestauksella voidaan suorittaa monta kertaluokkaa enemmän testitapauksia kuin toiminnallisella testauksella. Suurin osa testaukseen menevästä ajasta menee testitapausmäärittelyihin ja niistä johdettuihin testitapauksiin. Esimerkiksi miljoonan satunnaisen testin suorittaminen on mahdollisuuksien rajoissa, mutta kukaan ei suunnittele miljoonaa testitapausmäärittelyä. Valitettavasti satunnaistestauksen tarkkuus on niin huono, että käytännössä aina toiminnallinen testaus on satunnaistestausta järkevämpi vaihtoehto. Satunnaistestausta voidaan toki käyttää täydentämään muita testausmenetelmiä, mutta se ei käy ainoaksi menetelmäksi. Testitapaukset ja toiminnallinen määrittely Testitapausten johtaminen toiminnallisesta määrittelystä on monivaiheinen prosessi. Periaatteessa testitapaukset voitaisiin johtaa suoraan toiminnallisesta määrittelystä, mutta tällöin testitapauksia tulee hyvin paljon, suuri osa testitapauksista on päällekkäisiä, riittävyysehtoja on vaikea arvioida ja tuloksena ei ole (helposti) toistettava prosessi. Ohjelmistojen testaus / Taina 55 Ohjelmistojen testaus / Taina 56 Systemaattinen toiminnallinen testaus Toiminnallisen testauksen prosessi on systemaattinen ja toistettava. Se sisältää seuraavat työvaiheet: 1. Riippumattomien testattavien ominaisuuksien tunnistus. Ositetaan ohjelman toiminnallisuus sellaisiksi osajoukoiksi, jotka ovat mahdollisimman itsenäisiä. 2. Testattavan ominaisuuden testiarvojen valinta tai testattavan mallin generointi. Toiminnallisuusosajoukkoa edustavien syötteiden arvot luetteloidaan. Yleensä arvoja on paljon (jopa ääretön määrä), joten pääosin arvot kuvataan joukko-opin keinoin. Jos toiminnallisuusosajoukosta on olemassa käyttökelpoinen toiminnallisuutta kuvaava malli tai malli on generoitavissa helposti, käytetään mallia. Mallin parametrien arvojoukot vastaavat syötearvojoukkoja. Ohjelmistojen testaus / Taina 57 Systemaattinen toiminnallinen testaus 2 3. Testitapausmäärittelyjen generointi. Kaikki testitapausmäärittelyt ovat edellisen kohdan syötearvojoukkojen tai mallin parametrien arvojoukkojen karteesinen tulo. Koska karteesisen tulon koko kasvaa syötearvojoukkojen määrän suhteen eksponentiaalisesti, kaikkien testitapausmäärittelyjen joukko kasvaa nopeasti hallitsemattoman suureksi. Edellisen kohdan johdosta testitapausmäärittelyiden joukkoa pitää karsia (prune). Karsinnassa testitapausmäärittelyistä valitaan sopivalla heuristiikalla osajoukko, jonka mukaiset testitapaukset testaavat toiminnallisuusosajoukkoa riittävän hyvin. Ohjelmistojen testaus / Taina 58 Systemaattinen toiminnallinen testaus 3 4. Testitapausten generointi. Jokaista valittua testitapausmäärittelyä kohti generoidaan yksi tai useampi testitapaus. 5. Testien suoritus. Generoidaan/toteutetaan tarvittava ohjelman toimintaympäristö. Tämä on tarpeen, jos testattava ohjelma ei pysty toimimaan yksin. Suoritetaan testit ja analysoidaan tulokset. Tärkein työ on testitapausmäärittelyiden karsinta. Ilman sitä testaus on käytännössä mahdotonta, koska testejä tulee liikaa. Systemaattisen toiminnallisen testauksen prosessi Ohjelmistojen testaus / Taina 59 Ohjelmistojen testaus / Taina 60 (c) Juha Taina, 2007 6