Testaustyökalut Sini Mäkelä

Testaustyökalut Sini Mäkelä Helsinki 26.11.2000 Ohjelmistotuotantovälineet seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Sisällys 1 Johdanto...1 2 Testausprosessi...1 2.1 Testauksen tasot...1 2.2 Testausprosessin vaiheet...3 3 Testaustyökalut ohjelmakehityksen apuna...4 3.1 Testaus ohjelmoijan näkökulmasta...4 3.2 Ohjelmamittari...4 3.3 Koodin tarkastaja...4 3.4 Testikattavuusanalysaattori ja instrumentoija...4 3.5 Testipetigeneraattori...5 4 Työkalut testausvaiheessa...5 4.1 Testauksen tavoite...5 4.2 Testitapausten generointi...6 4.3 Testitapausten automatisointi...6 4.4 Testauksen hallinta...7 5 Työkalun valinta...7 5.1 Valintaprosessi...7 5.2 Vaatimusten kartoittaminen...8 5.3 Pilottiprojekti...8 6 Yhteenveto...9 Lähteet 9

1 Johdanto Ohjelmistotestaus kuuluu olennaisena osana ohjelmistoprosessiin. Ohjelmistotestaus pyrkii ensisijaisesti systemaattisesti löytämään tuotteessa olevia virheitä. Lisäksi testauksen tarkoituksena on varmistaa, että kehitetty tuote täyttää sille kehitysprosessin alussa annetut vaatimukset. Tuotteen testaus vie tyypillisesti yhtä kauan aikaa kuin tuotteen kehitys. Testauksen pitäisi olla kattava, mutta täysin kattavan testauksen toteuttaminen on useissa tapauksissa mahdotonta. Ohjelmalla on suuri määrä syötteitä ja näiden syötteiden yhdistelmiä eksponeniaalinen määrä. Testauksen tulisi myös pystyä simuloimaan tuotteen autenttista käyttötilannetta. Monilla ohjelmistoilla (tietokannat, palvelimet) saattaa olla kymmeniä, satoja tai tuhansia yhtäaikaisia käyttäjiä, joten testaaminen ilman apuna olevia työkaluja on vaikeaa.. Testauksen aikana joudutaan usein suorittamaan samoja testitapauksia moneen kertaan ns. regressiotestausvaiheessa. Saman toistaminen saattaa testaajista tuntua ikävältä ja aikaavievältä. Regressiotestauksen automatisointi on mahdollista useissa tapauksissa kirjoittamalla testitapaukset jollain skriptikielellä. Testauksen kestoa lyhentämään, tarvittavien testitapausten suorittamiseen, testidatan generointiin ja testauksen laadun arviointiin on kehitetty useita testaustyökaluja. Tässä esityksessä käydään lyhyesti testausprosessi eri vaiheineen ja kuhunkin vaiheeseen avuksi kehitettyjen työkalujen päätyypit. Lisäksi kuvataan menetelmä, jota voidaan käyttää apuna sopivan testaustyökalun valinnassa. 2 Testausprosessi 2.1 Testauksen tasot Testaus voidaan jakaa useaan eri tasoon esimerkiksi V mallia käyttäen. Kuvassa 1 on esitetty V mallin eri tasot. 1

Kuva 1. V mallin testaustasot [Paa00]. V mallissa eri testausvaiheet on liitetty yhteen tuotteen suunnitteluvaiheiden kanssa. V mallin mukaisesti testauksen suunnittelu tapahtuu testaustasoa vastaavalla suunnittelutsaolla. Testauksen tulokset tarkastellaan puolestaan vertaamalla niitä vastaavan suunnittelutason vaatimusdokumentteihin. V mallissa testaus on jaettu seuraaviin vaiheisiin: Moduulitestaus (module testing) Moduulitestauksessa keskitytään yhden ohjelmamoodulin toiminnan tarkasteluun. Moduulin toimintaa verrataan moduulisuunnittelun ja arkkitehtuurisuunnittelun tuloksiin, kuten tekniseen määrittelydokumenttiin. Toisin kuin muissa testausvaiheissa, moduulitestauksen suorittaa yleensä moduulin toteuttaja. Integrointitestaus (integration testing) Integrointitestauksessa yhdistellään moduuleita osajärjestelmiksi. Painopiste testauksessa on moduulien välisten rajapintojen toimivuuden tutkimisessa. Testausen tuloksia verrataan tekniseen määrittelyyn. Järjestelmätestaus (system testing) Tällä testaustasolla tarkastelun kohteena on koko järjestelmä ja sen tuloksia verrataan ohjelmistojen toiminnalliseen määrittelyyn (määrittelydokumenttiin). Järjestelmätestauksessa on tärkeää, että testaajina toimii kehitystyöstä mahdollisimman riippumattiomia henkilöitä. Järjestelmätestauksen piiriin luetaan myös järjestelmän ei toiminnallisten ominaisuuksien testaus, kuten kuormitustestit, asennustestit ja käytettävyystestit. Hyväksymistestaus (acceptance testing) Hyväksymistestauksen suorittavat ohjelmiston asiaakkaat ja käyttävät. Testauksen tarkoituksena on varmistaa, että ohjelmisto täyttää heidän vaatimuksensa. Hyväksymistestaus voidaan jakaa alfa ja beta testaukseen. Alfa testauksen suorittavat todelliset käyttäjät kehitystyön tehneessä yrityksessä. Beta testauksen suorittavat asiakkaat omassa todellisessa käyttöympäristössään. 2

V malli on suosittu tapa mallintaa testauksen etenemistä, mutta sisältää ongelmallisia kohtia. Suurin näistä on V mallin sitoutuminen ohjelmistokehityksen vesiputousmalliin. Näin ollen vesiputousmallissa olevat ongelmat siirtyvät suoraan myös V mallin mukaisesti tehtyyn testaukseen. V mallissa jaetaan testaus turhan tiukasti eri tasoihin, joskus saattaisi olla järkevää suorittaa moduuli ja integrointitestaus lomittain tai yhdistää nämä, mutta V malli ei rohkaise eri suunnittelutasojen tiedon yhdistämiseen [Mar00]. 2.2 Testausprosessin vaiheet Testausprosessi voidaan jakaa vaiheisiin samaan tapaan kuin ohjelmistokehitysprosessi. Testaus alkaa suunnitteluvaiheella, jossa määritellään testauksen laajuus ja kriteerit, joilla testaus hyväksytään (exit criteria). Suunnitteludokumentin (test plan) avulla kirjoitetaan testitapauksista koostuva testispesifikaatio (test specification). Suunnitteludokumentti ja testispesifikaatio voidaan myös tehdä yhdistettynä. Testausvaiheessa testispesifikaatiossa luetellut testitapaukset suoritetaan. Testauksen suorituksesta laaditaan raportti, josta käy ilmi testauksen kattavuus ja tiedot testauksen aikana löydetyistä virheistä. Kuvassa 2 on esitetty testausprosessin eri vaiheisiin soveltuvien testaustyökalujen tyypit [Pos95]. Kuva 2. Työkalut testausprosessin eri vaiheissa [Pos95]. 3

Testauksen suunnitteluun erikoistuneita työkaluja ei ole olemassa. Suunnitteluvaiheessa voi käyttää yleisiä projektin ajankäyttöön ja seurantaan tarkoitettuja työkaluja ja tavallisia tekstinkäsittelyohjelmia. 3 Testaustyökalut ohjelmakehityksen apuna 3.1 Testaus ohjelmoijan näkökulmasta Ohjelmakehityksessä käytettävillä testaustyökaluilla tarkoitetaan tässä työkaluja, joita ohjelmoija voi käyttää apunaan kehittäessään ohjelmakoodia tai välineitä, joita voi käyttää moduulitestauksessa. Virheiden etsimiseen (debugging) tarkoitettuja välineitä ei käsitellä tässä, sillä ne eivät kuulu varsinaisesti testauksen alaan vaan sisältyvät virheiden korjausvaiheeseen joka sijoittuu projektissa testauksen jälkeiseen aikaan. Ohjelmoinnin aikana testauksen syötteenä toimii ohjelmakoodi. Hyvin kommentoitu ohjelmakoodi voi jo itsessään toimia vaatimusmäärittelynä pienissä ohjelmamoduuleissa. Varsinaisista testaustyökaluista hyödyllisimpiä ohjelmointiprosessin aikana käytettäväksi ovat koodin stattiseen analysointiin perustuvat työkalut. Staattisessa analysoinnissa ohjelmakoodia tarkastellaan ilman, että sitä tarvitsee kääntää tai suorittaa. 3.2 Ohjelmamittari Ohjelmakoodin monimutkaisuudesta, tietorakenteista sekä kontrollin ja datankulusta usein graafisessa muodostavia apuvälineitä kutsutaan ohjelmamittareiksi (metrics reporter). Nämä työkalut auttavat ohjelmoijaa organisoimaan koodia paremmin ja antavat testaajille paremman näkökulman siihen, mitä alueita koodissa pitää erityisesti testata. Ohjelmamittarien avulla voi myös arvioida sitä, kuinka paljon testitapauksia tietyn moduulin testaukseen tarvitaan. Tunnetuin mitoista on McCaben syklomaattinen numero, joka lasketaan kullekin ohjelman funktiolle erikseen [Hai98]. Syklomaattisen numeron arvo saadaan lisäämällä funktion kontrolliverkon haarautumiskohtien lukumäärään ykkönen. Testitapausten minimimäärä on sama kuin syklomaattisen numeron arvo. 3.3 Koodin tarkastaja Koodin tarkastaja (code checker) joka etsii koodista epäilyttäviä kohtia, kuten huonosti määriteltyjä osoittimia, muuttujia, joita ei koskaan käytetä ja standardin vastaisia rakenteita. Monet nykyisistä ohjelmointikielen kääntäjistä osaavat varoittaa koodissa esiintyvistä epäilyttävistä kohdista käännösvaiheessa. 3.4 Testikattavuusanalysaattori ja instrumentoija Testikattavuusanalysaattorit (structure coverage analyzer) mittaavat testikattavuutta erilaisilla kattavuusmitoilla. Kattavuusanalysaattorien kanssa käytetään yleensä koodin instrumentoijaa (code instrumentor), joka lukee ohjelmakoodia ja tunnistaa kohdat, joihin pitää tehdä lisäyksiä, jotta kattavuusmittauksia voitaisiin tehdä. Kattavuusanalysaattori auttaa löytämään koodista vähän testatut alueet ja näin ollen 4

kattavuusmittoja voidaankin käyttää myös arvioitaessa testauksen laatua. Eräs kattavuusanalysaattorien ryhmä on keskittynyt tutkimaan ohjelman muistinkäyttöä ja tunnistamaan kohdat joissa ohjelma joko lukee alustamatonta muistia tai kirjoittaa varaamattoman muistialueen ulkopuolelle. Muistivuotojen tutkiminen on erityisen tärkeää mikäli käytössä on jokin sellainen ohjelmointikieli, jossa muistivirheiden teko on helppoa. Kattavuusanalysaattori voi käyttää useita yleisimmin käyttössä olevat kattavuusmitat: eri mittoja. Seuraavassa on lueteltu Lausekattavuudessa (statement coverage) ohjelman jokainen lause suoritetaan vähintään kerran. Päätöskattavuudessa (decision coverage) jokainen ehto saa testattessa molemmat arvonsa. Ehtokattavuudessa (condition coverage) päätöksen kaikkien ehtojen on saatava kaikki arvonsa. Moniehtokattavuudessa (multiple condition coverage) testaus on suoritettava kaikkien ehtojen kaikilla yhdistelmillä. Kattavuusmittojen paremmuusjärjestystä voi arvioida tutkimalla sitä miten täyttääkö tietyn mitan perusteella tehty testitapaus myös toisen mitan ehdot. Päätöskattavuudesta seuraa lausekattavuus ja moniehtokattavuudesta puolestaan seuraa sekä ehto, että päätoskattavuus. Näin ollen moniehtokattavuus on vahvin tässä esitellyistä kattavuusmitoista. Kattavuusmittoja käytetään yleisesti määriteltäessä testauksen vaatimuksia. Kattavuusmittojen käytöllä on kuitenkin rajansa ja näin ollen kattavuusmittojen ei tulisi olla ainoa kriteeri arvioitaessa testauksen laatua. Ainoastaan hyvien kattavuusmittojen saavuttamiseksi tehty testaus ei pysty löytämään kaikkia koodissa olevia loogisia virheitä tai koodista täysin puuttuvia osia [Mar99]. 3.5 Testipetigeneraattori Yksittäinen moduuli tarvitsee usein palveluja ulkopuolisilta moduuleilta tai tarjoaa niille palveluita. Moduulitestausvaiheessa yksittäinen moduuli tulisi kuitenkin testata itsenäisenä yksikkönä. Näin ollen testauksen suorittamiseksi on tarpeen toteuttaa testipetejä (test bed), jotta moduulin toimivuutta voidaan tarkastella. Testipetiin voi kuulua moduulin ympäristöä simuloivia osia kuten testiajureita (test driver) ja tynkämoduuleita (test stubs). Testiajurit kutsuvat moduulin tuottamia palveluita ja tynkämoduulit korvaavat testattavan moduulin tarvitsemat muut moduulit. Testipetigeneraattori (test bed generator) luo testattavalle moduulille automaattisesti testipetin, jolle voidaan kuvata testikuvauskielellä ajattevat testi. Kielellä voidaan myös kuvata halutut testitulokset, jolloin testin tulosten tarkastelu on automatisoitavissa. 5

4 Työkalut testausvaiheessa 4.1 Testauksen tavoite Järjestelmätestauksessa tuotteen ohjelmointi on jo valmis ja tuote on läpikäynyt moduulitestauksen ja mahdollisen integrointitestauksen. Järjestelmätestauksessa keskitytäänkin lähinnä tuotteen testaamisen loppukäyttäjän näkökulmasta. Suurin haaste järjestelmätestauksessa käytettäville työkaluille testitapausten järkevä suorittaminen ja sekä raportoinnin automatisointi. Järjestelmätestauksen apuna voi käyttää myös samoja työkaluja kuin moduuli ja integrointitestauksessa. Erityisesti testikattavuusanalysaattori on apuna arvioitaessa järjestelmätestauksen laatua. Testikattavuusanalysaattoria käytettäessä järjestelmätestauksessa käytetty ohjelma on pitänyt instrumentoida ko. analysaattorin vaatimalla tavalla. 4.2 Testitapausten generointi Testitapausten laatiminen on monesti testausprosessin aikaavievin osio varsinkin jos testauksen muut vaiheet on automatisoitu. Monissa tapauksissa testitapausten automaattinen generointi on käytännössä mahdotonta, sillä se edellyttää testattavan ohjelman toiminnan formaalia spesifiointia. Mikäli testattava ohjelma on formaalisti määritelty käyttäen esimerkiksi STL kieltä [IEEE1175] ainakin osa testitapauksista voidaan tuottaa suoraan määrittelyä apuna käyttäen. Testitapausten automattisessa generoinnissa käytetään usein apuna testaajan syötteelle määrittelemiä ekvivalenssiluokkia (equivalence class) tai testaajan määrittelemiä malleja, joita syötteen pitää toteuttaa. Testidatan generoimiseen voidaan käyttää samaa ekvivalenssiluokkiin perustuvaa menetelmää myös silloin kun testitapauksia ei pystytä automaattisesti generoimaan. 4.3 Testitapausten automatisointi Suurimman ryhmän testausvaiheeseen suunnitelluista työkaluista muodostavat ns. nauhoitus toisto (capture replay) työkalut. Suurin osa markkinoilla olevista työkaluista on suunniteltu käyttöliittymän (graafisen tai tekstipohjaisen) omaavien ohjelmatuotteiden testaamiseen. Nauhoitus toisto työkalujen idea on hyvin yksinkertainen. Nauhoitustilassa työkalu nauhoittaa käyttäjän, tässä tapauksessa testaajan, ohjelmassa tekemiä toimintoja, kuten näppäimistöllä syötettyjä arvoja tai hiiren painalluksia. Toistotilassa nauhoitettu toimintoketju ajetaan uudelleen testattavalla ohjelmalla. Näiden työkalujen käyttö on hyödyllistä erityisesti regressiotestauksessa, jossa suoritetaan uudelleen suuri määrä jo kerran ajettuja testitapauksia. Nauhoitustyökalujen käyttö tuntuu houkuttelevalta juuri niiden helppokäyttöisyyden takia. Käytännössä on kuitenkin todettu ettei pelkkä testitapausten nauhoitus ja niiden myöhempi toisto ole tehokas tapa lisätä testauksen laatua tai tehokkuutta. Automatisoitujen testitapausten tulee kyetä myös saadun tuloksen vertaamiseen 6

odotettuun tulokseen ja pystyä mukautumaan mahdollisesti myöhemmin tapahtuviin muutoksiin käyttöliittymässä [Few99]. Testauksen automatisointiin tulisikin suhtautua erääntyyppisenä ohjelmistokehitysprojektina. Testauksen automatisointia suunnitellessa ja toteuttaessa pitää varautua siihen, että automatisoinnin tulokset eivät välttämättä ole heti näkyvissä. On arvioitu, että ensimmäinen testisykli automatisoinnin jälkeen vie 3 10 kertaa enemmän aikaa kuin vastaavan syklin läpivienti manuaalisesti testattaessa. Nauhoitusvälineiden käyttö soveltuu yleensä vain sellaisten ohjelmarajapintojen testaukseen, joissa käyttäjä kommuikoi järjestelmän kanssa käyttöliittymän avulla. Suurimmalla osalla ohjelmistoista on myös rajapinta käyttöjärjestelmän, tietokantajärjestelmän tai muun ulkopuolisen järjestelmän kanssa tapahtuvaa kommunikointia varten. Näiden rajapintojen testauksen automatisointia varten täytyy usein kehittää testattavan ohjelmiston tarpeisiin rakennettu työkalu. Myös testipetigeneraattoria voi käyttää hyödyksi käyttöjärjestelmä ja ohjelmistorajapintojen testauksen automatisoinnissa. 4.4 Testauksen hallinta Testausprosessiin kuuluu monia osatekijöitä (testauksen suunnittelu, testitapausten suunnittelu, testiskriptien kirjoittaminen, testaus, virheiden raportointi, tulosten evaluointi), joten testauksen hallinta saattaa muodostua ongelmaksi ellei hallinan apuna käytetä jotain työkalua. Testauksen hallinnassa voidaan käyttää samoja työkaluja kuin yleisesti projektin hallinnassa. Tavallisten projektinhallintaohjelmien lisäksi, monissa testauksen avuksi tarjotuissa välineissä on ominaisuuksia, jotka auttavat testauksen hallinassa. Monissa testausohjelmistoissa on integroitu samaan ohjelmaan useita testauksessa käytettäviä työkaluja. Saman ohjelmiston eri osilla voi kirjoittaa testitapaukset ja hallinnoida niitä, liittää testitapauksiin automaattisesti suoritettavia testiskriptejä ja pitää kirjaa suoritetuista testeistä sekä niiden tuloksista. 5 Työkalun valinta 5.1 Valintaprosessi Testauksen automatisointi ja työkalujen käyttö ovat apuna testauksen laadun lisääntymiseen. Markkinoilla on kuitenkin valtava määrä vaihtelevan laatuisia ja erilaisiin tarpeisiin sopivia testaustyökaluja, joten oikean työkalun tai työkalujen löytäminen saattaa vaikuttaa mahdottomalta tehtävältä. Monesti työkalun hankintapäätös tehdään hätiköiden ja huono valinta kostautuu myöhemmin työkalun jäämisellä käyttämättömäksi. Työkalun valintaprosessin tulisikin kartoittaa tarpeet ja tavoitteet mahdollisimman systemaattisesti [Pos92]. Kuvassa 3 on esitetty esimerkki valintaprosessin osavaiheista. 7

Kuva 3. Testityökalun valintaprosessin vaiheet [Pos92]. 5.2 Vaatimusten kartoittaminen Työkalun valintaprosessi vaatii yhteistyötä sekä työkalun tulevien käyttäjien että työkalun ostopäätöksestä vastuussa olevien johtajien kanssa. Valintaprosessin aikana tulee identifioida käyttäjien tarpeet sekä johtajien vaatimukset ja antaa kullekin osakomponentille painokerroin. Näiden avulla voidaan karsia markkinoilla olevista työkaluista ehdokkaat, joista laaditaan laajamittaisempi arviointi ennen valintapäätöstä. Vaatimuksia saattavat olla esimerkiksi testaukseen nykyisellään käytettävä aikamäärä ja haluttu virheiden löytöprosentin parannus. Työkalujen löytämisen avuksi on tarjolla useita ulkopuolisten yritysten tai yhteisöjen tekemiä selvityksiä ja arviointeja erilaisista testaustyökaluista. Näitä ja työkalulle esitettyjä vaatimuksia, kuten käyttöympäristöä, koulutusta ja organisaatiota koskevia vaatimuksia, apuna käyttäen valitaan yksi tai kaksi työkalua, joita arvioidaan yrityksen sisällä. 5.3 Pilottiprojekti Pilottiprojektiksi kutsutaan tiettyä työkalua käyttävää ja samalla arvioivaa projektia. Muutoin pilottiprojekti on täysin normaali ohjelmistotuotantoprojekti. Pilottiprojektiksi ei pitäisi valita projektia, joka on jo nykyisellään aikataulusta jäljestä tai muuten ongelmallinen. Pilottiprojektin kestolle tulisi myös asettaa selvä takaraja, projekti ei saisi kestää muutamaa kuukautta pidempää. Pilottiprojektin tehtävänä on tutustua uuteen välineeseen ja kerätä tietoa sen soveltuvuudesta yrityksen tarpeisiin. Projektin jälkeen työkalusta tulee tehdä 8

arviointiraportti, jonka perusteella päätetään tullaanko työkalua käyttämään laajamittaisesti yrityksen ohjelmistoprojekteissa. 6 Yhteenveto Testaus on tärkeä osa ohjelmistoprosessia, mutta sen laadusta tingitään usein aikapulan tai muiden tekijöiden, kuten testauksen ominaisluonnetta kohtaan tunnetun vastenmielisyyden vuoksi. Testauksen avuksi on olemassa useita työkaluja, joita käyttämällä voidaan lisätä testauksen laatua ja kattavuutta sekä vähentää testauksen vaatimaa aikaa. Testaustyökalujen käyttö ei kuitenkaan välttämättä lisää testauksen laatua. Erityisesti testauksen automatisointi vaatii laajamittaista paneutumista eivätkä automatisoinnin positiiviset tulokset näy heti. Oikean testaustyökalun löytäminen suuresta tarjonnasta saattaa olla vaikeata joten työkalun valitsemiseen tehtävä kartoitustyö tulee suorittaa mahdollisimman perusteellisesti. Lähteet [Few99] [Hai98] [IEEE1175] [Mar99] [Mar00] [Paa00] [Pos92] [Pos95] Fewster M., Graham D., Software Test Automation, Addison Wesley, 1999 Haikala I., Märijärvi J., Ohjemistotuotanto, Suomen ATK kustannus, 1998 IEEE CS Std 1175, A Standard Reference Model for Computing System Tool Interconnections, IEEE Standards Board Marick B., How to Misuse Code Coverage http://www.testing.com/writings/coverage.pdf Marick B., New Models for Test Development http://www.testing.com/writings/new models.pdf Paakki J., Ohjelmistojen testaus, luentomoniste, Tietojenkäsittelytieteen laitos, Helsingin Yliopisto, 2000 Poston M. R.., Sexton M. P., Evaluating and Selecting Testing Tools, IEEE Software, 1992 Poston M. R., Testing tools combine best of new and old, IEEE Software, 1995 9