Testaustasot

Erilaisia testaustasoja ovat ns. V-mallin mukaisesti moduulitestaus, integrointitestaus ja järjestelmätestaus. Järjestelmätestausta voi joskus seurata erillinen hyväksymistestaus. Siirryttäessä V-mallissa alimmalta tasolta ylöspäin testauksen luonne muuttuu lasilaatikko-testauksesta tavallisesti yhä enemmän mustalaatikkotestaukseksi.

Kuva 1: Testauksen V-malli (Kautto 1996)

V-mallin mukaisesti testauksen suunnittelu tapahtuu testaustasoa vastaavalla suunnittelutasolla (kuvio 1). Määrittelyvaiheessa kuvataan ohjelmiston toiminnot, toteutukselle asetettavat ulkoiset vaatimukset sekä rajoitukset. Järjestelmätestaus suunnitellaan määrittely-vaiheessa. Arkkitehtuurin suunnitteluvaiheessa järjestelmä jaetaan mahdollisimman itsenäisiin, toisistaan riippumattomiin osiin, moduuleihin. Tähän vaiheeseen kuuluu integrointitestauksen suunnittelu. Moduulitestaus suunnitellaan moduulisuunnitteluvaiheessa, jossa jokaisen moduulin sisäinen rakenne suunnitellaan. Testauksesta syntyviä tuloksia verrataan näissä vaiheissa tapahtuneissa suunnitteluissa syntyneisiin dokumentteihin.

Näiden tasojen lisäksi voidaan suorittaa hyväksymistestaus, joka on asiakkaiden ja käyttäjien tekemä testi. Tällä varmistetaan, että järjestelmä on valmis otettavaksi käyttöön. Vaiheen testaustapaukset on hyvä suunnitella asiakkaan kanssa mahdollisimman nopeasti vaatimusmäärittelyn teon jälkeen.

Moduulitestaus

Moduulitestauksessa testattavana on yksittäinen moduuli. Moduulilla tarkoitetaan ohjelmasta erotettavissa olevaa loogista kokonaisuutta, kooltaan tyypillisesti alle 1000 ohjelmariviä. Tyypillinen moduuli sisältää tietomäärittelyjä ja joukon ko. tietoa käsitteleviä funktioita. Moduulin toimintaa verrataan moduulisuunnittelun ja arkkitehtuurisuunnittelun tuloksiin, tavallisimmin tekniseen määrittelydokumenttiin. Testauksen suorittaa yleensä moduulin toteuttaja. Yleensä testit ovat mustalaatikkotestejä. Jos prosessit ovat vaikeita, myös lasilaatikkotestausta voidaan käyttää.

Testeissä keskitytään sisäiseen logiikkaan ja tietorakenteisiin. Kun moduuli suorittaa vain yhden funktion, testitapausten määrä vähenee ja virheet ovat helpommin löydettävissä. Moduulitestauksen yhteydessä pyritään myös löytämään ristiriitoja testattavien moduulien määrittelyjen ja toiminnan välillä. Moduulitestaus ei sovellu ainoaksi testausmenetelmäksi, koska testimoduulit ovat ainoastaan pieniä ohjelman osia eikä laajoja kokonaisuuksia.

Integrointitestaus

Integrointitestauksessa yhdistellään yhteen moduuleita ja moduuliryhmiä. Pienemmät osat kootaan yhteen ja niitä testataan, kunnes koko systeemi on saatu kasaan. Painopiste on moduulien välisten rajapintojen toimivuuden tutkimisessa. Integrointitestaus etenee usein rinnan moduulitestauksen kanssa ja sitä onkin usein tarpeetonta tarkastella erillään moduulitestauksesta. Testauksen kattavuuden kannalta moduulitestauksessa on tosin helpompi saavuttaa kunnollinen testikattavuus, koska testattavan kokonaisuuden kasvaessa on vaikea käydä kaikkea koodia läpi. Integrointitestausta voidaan toteuttaa kahdella lähestymistavalla: kokoavalla tavalla alimman tason moduuleista ylöspäin tai jäsentävällä eli osittavalla integroinnilla päinvastoin. Osista kokonaisuuksiin eli kokoava on tavallisin tapa.

Integrointitestauksen tarkoituksena on varmistaa, että kasatut osat toimivat määritellysti keskenään, sekä löytää ja korjata mahdollisimman paljon yhteensoveltumattomia moduuleita. Virheitä voi löytyä, vaikka yksittäiset moduulit olisivatkin osoittautuneet toimiviksi. Testitapaukset muodostetaan siten, että voidaan paljastaa virheitä moduuleiden yhteistoiminnassa.

Järjestelmätestaus

Järjestelmätestauksessa tarkastelun kohteena on koko järjestelmä ja tuloksia verrataan määrittelyvaiheessa syntyneeseen dokumentaatioon. Järjestelmätestauksen suorittajina pitää olla kehitystyöstä mahdollisimman riippumattomia testaajia. Järjestelmätestauksessa testataan myös järjestelmän ei-toiminnalliset ominaisuudet: kuormitustestit, luotettavuustestit, asennustestit, käytettävyystestit jne.

Virheiden korjaus voi myös aiheuttaa uusia virheitä. Kun esimerkiksi järjestelmätestauksessa huomattu virhe korjataan, voidaan useisiin moduuleihin joutua tekemään muutoksia. Siltä varalta, että jokin muutostarve jää huomaamatta, myös muut moduulit pitäisi testata ja vielä lopuksi suorittaa järjestelmätestaus uudelleen. Tällaista uudelleentestausta kutsutaan regressiotestaukseksi ja sen suorittaminen voi tulla erittäin kalliiksi, ellei testausta saada automatisoitua.

Helpoimmillaan regressiotestaus tarkoittaa aikaisempien integraatiotestien ajamista uudelleen. Kaikkien testien ajaminen ei kuitenkaan aina ole mahdollista, koska testien suorittaminen saattaa vaatia paljon aikaa. Suurin osa ajettavista testeistä on yleensä turhia, kun tarkoituksena on testata ainoastaan muutetun ohjelmakoodin vaikutusalue. Tämän vuoksi regressiotestaus voidaan kohdistaa ohjelmiston tiettyihin komponentteihin, jolloin suoritettavien testien määrää voidaan rajata. Varsinkin regressiotestauksen suorittamiseksi testauksen tulisi olla mahdollisimman pitkälle automatisoitua.

Hyväksymistestaus

Hyväksymistestauksella pyritään osoittamaan, että järjestelmä pystyy suoriutumaan asiakkaan sille asettamista vaatimuksista. Hyväksymistestaus suoritetaan ajallisesti viimeisenä testausvaiheena osana järjestelmätestausta tai omana vaiheenaan sen jälkeen.

<<Takaisin alkusivulle