Ohjelmien testaustyökalut Antti Hämäläinen Helsinki 13.11.2000 Ohjelmistotuotantovälineet seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Ohjelmien testaustyökalut Antti Hämäläinen Ohjelmistotuotantovälineet seminaari Tietojenkäsittelytieteen laitos Helsingin yliopisto 13.11.2000, 7 sivua Seminaarityö käsittelee ohjelmien testausta automatisoivia työkaluja ja yksikkötestausta käytten JUnit testikehystä. Avainsanat: testaaminen, testauksen automatisointi, testaustyökalut 2
1 JOHDANTO... 4 2 TESTAAMINEN... 4 2.1 TESTIEN RAPORTOINTI JA HALLINNOINTI... 4 2.2 YKSIKKÖTESTAUS... 5 2.3 INTEGRAATIOTESTAUS... 5 2.4 JÄRJESTELMÄTESTAUS... 5 3 TESTAUSTYÖKALUT... 5 3.1 TESTDIRECTOR... 6 3.2 JUNIT... 6 4 JUNIT KÄYTÖSSÄ... 7 4.1 KEHYKSEN TOIMINTA JA RAKENNE... 7 4.1.1 Testi (TestCase)... 8 4.1.2 Testihuone (TestSuite)... 8 4.2 TESTIHIERARKIOIDEN RAKENTAMINEN... 8 4.3 KÄYTTÖLIITTYMÄ, TESTRUNNER... 8 4.4 KÄYTÄNNÖN KOKEMUKSIA... 9 5 YHTEENVETO... 10 3
1 Johdanto Ohjelmistojen toiminnallisuuden ja oikeellisuuden testaaminen on aikaa ja resursseja vaativaa työtä. Testaaminen jakautuu testien määrittelyyn ohjelman vaatimusmäärittelyn pohjalta ja määriteltyjen testien suorittamiseen. Suoritetuista testeistä luodun testiraportin ja testien määritelmien hallinnointiin on kehitetty työkaluja. Testaamisen suorittamisen helpottamiseksi on kehitetty testien suorittamisen automatisoivia ympäristöjä. Seminaari keskittyy yksikkötestaamiseen java ympäristössä käyttäen JUnit testikehystä. Kokemuksia ja käytännön esimerkkejä kevään ohjelmistotuotanto ryhmän beta projektista, jossa testaukseen käytettiin onnistuneesti JUnit testikehystä. 2 Testaaminen Testauksen tarkoitus on varmistaa ja parantaa kehitettävän ohjelmiston laatua. Tämä tapahtuu etsimällä ohjelmassa tai ohjelman toiminnallisessa määrittelyssä esiintyvät virheet. Käsitteenä virhe on hieman tulkinnanvarainen. Yleisesti ottaen virheeksi käsitetään mikä tahansa tila tai tapahtuma, jossa ohjelman käytös poikkeaa odotetusta. Toisaalta ohjelman käytöksen määrittely voi olla itsessään virheellinen, ja ohjelma toimiikin oikein. Tämä ristiriita tekee testaamisen automatisoinnin hankalaksi. Ohjelmallinen ohjelman testaaminen kykenee löytämään vain ne virheet, jotka testiohjelma on ohjelmoitu löytämään. 2.1 Testien raportointi ja hallinnointi Testien kirjaaminen, hallinnointi ja testiraporttien generointi ovat tärkeä osa testausprosessia. Tähän tarkoitukseen on kehitetty erinäisiä hallinnointityökaluja. Hyvän työkalun tulisi tukea testien ja testituloksen kirjaamista, sekä testiraportin generointia. Testiraportteja tehtäessä on tärkeää erottaa ohjelman versiot toisistaan ja kyetä 4
vertaamaan versioiden välisiä muutoksia. Yhtäläisen tärkeää on merkitä testit kullekin versiolle, jotta ohjelman toimintojen regressiotestaus oli mahdollista. 2.2 Yksikkötestaus Yksikkötestaus sisältää luokkien sisältämien metodien toiminnan testaavat testit. Tarkoituksena on varmistaa luokan sisäinen toiminta ja löytää mahdolliset loogiset virheet luokan sisältämissä algoritmeissa. [2] 2.3 Integraatiotestaus Integraatiotestaus sisältää luokkien ulkoisten rajapintojen toiminnan testaamisen. Integraatiotestauksen tavoitteena on löytää selvien virheiden lisäksi ristiriitoja luokkien implementaation ja määrittelyiden välillä. Jotta ristiriitojen löytäminen olisi mahdollista integraatiotestauksen testit tulee määritellä luokan toiminnallisen suunnitelman pohjalta.[2] 2.4 Järjestelmätestaus Järjestelmätestauksen tarkoituksena on selvittää suuremman ohjelmiston ulkoisten rajapintojen ja liityntöjen toiminta ja mahdolliset epäyhteensopivuudet implementaation ja rajapintakuvausten välillä. [2] 3 Testaustyökalut Tyypillisesti ohjelman testaus suoritetaan ohjelmaa varten kirjoitetuilla ajureilla ja testiohjelmilla, joiden tuottamasta tulosteesta luodaan testiraportti enemmän tai vähemmän manuaalisesti. Tämä tekee testaajan työn erittäin hitaaksi ja hankalaksi. Testaustyökaluilla pyritään helpottamaan testaajan työtä, automatisoimaan testejä ja testiraportin generointia. Koneellisesti kyetään testaamaan paremmin ohjelman sisäistä rakennetta ja etsimään mahdollisia loogisia virheitä algoritmeista. Yksikkötestausta 5
voidaan käyttää XP (extreme programming) tyylisesti ohjelmoijan työkaluna oman koodin toiminnallisuuden todentamisessa implementoinnin ohessa. [5] 3.1 TestDirector TestDirector on testien hallinnointi ja raportointi työkalu, jossa on www käyttöliittymä sekä windows pohjainen asiakasohjelmisto. TestDirector on Mecury interactiven tuote ja osa isompaa tuoteperhettä, johon kuuluu muita testaustyökaluja. Tuoteperheeseen kuuluvat testien automatisointiin soveltuvat WinRunner ja LoadRunner, sekä testien ryhmittelyyn soveltuva TestSuite. TestDirector mahdollistaa vaatimusmäärittelyyn pohjautuvan testien luomisen. Järjestelmä antaa jokaiselle testille oman tunnisteen, jonka avulla tunnistetaan testiin liittyvä materiaali ja luodaan automaattinen testiraportti. 3.2 JUnit JUnit on java pohjainen testikehys, jota voidaan käyttää testien ajamiseen ja hierarkisten testipuiden rakentamiseen. JUnit mahdollistaa testien automatisoinnin ja automaattisen testiraportin generoinnin testejä ajettaessa. [3] JUnit voidaan integroida osaksi Visual Age kehitysympäristöä. Pääasiallisesti JUnitia käytetään yksikkötestauksessa, mutta mikään ei estä rakentamasta myös integraatiotestausjärjestelmää JUnitin kehyksen päälle. Käytännössä JUnitin kehystä voidaan käyttää minkä tahansa hierarkian kuvaamiseen. JUnitin kehittäjät Kent Beck ja Erich Gamma halusivat helpottaa testaamista ja liittää testaamisen osaksi ohjelmointiprosessia.[1] 6
4 Junit käytössä Käytännön ongelmia ja ajatuksia JUnit testikehyksen käytöstä ohjelmistotuotanto projektissa keväällä 2000. [4] 4.1 Kehyksen toiminta ja rakenne Suoritetut testit jaetaan kolmeen luokkaan, onnistuneet (success), epäonnistuneet (failure) ja virheelliset (error). Epäonnistunut testi on päättynyt edeltä ennakoituun virhetilanteeseen, eli virhe on kyetty raportoimaan assert() metodikutsulla. Virheellinen testi on päättynyt ennakoimattomasti keskeytykseen, eikä tapahtunutta virhettä ole raportoitu assert() metodikutsulla. Yksittäinen testiluokka sisältää metodit testimetodien vaatiman testiympäristön pystyttämiseen ja sammuttamiseen. <<Interface>> Tes t counttestcases () : int run(result : Tes tresult) : void contains TestCase TestSuite addtest(test) : void counttestcases() : int run(testresult) : void run() setup() teardown() assert(string message, boolean condition) : void) getresult() : TestResult kuva 5.1.1.1 Junit kehyksen luokkarakenne 7
4.1.1 Testi (TestCase) Testit (testcase) periytetään junit.framework.testcase luokasta. Periytetyt testiluokat voivat sisältää useita testimetodeita, jokainen testimetodi tulee alkaa test literaalilla. Testiluokka voidaan ajaa yksinään, jos yksittäisen testimetodin nimeä ei ilmoiteta, kaikki luokan sisältämät testimetodit suoritetaan. 4.1.2 Testihuone (TestSuite) Testihuoneet (testsuite) periytetään junit.framework.testsuite luokasta. Testihuone luokkaan voidaan lisätä yksittäisiä testiluokkia ja uusia testihuone luokkia. Kun testihuoneen testit suoritetaan, kaikki huoneeseen lisätyt testit suoritetaan. Tämä mahdollistaa testi hierarkioiden rakentamisen. 4.2 Testihierarkioiden rakentaminen Junitin kehys mahdollistaa testien koostamisen hierarkisesti. Testeistä voidaan rakentaa puumalliseksi, jolloin suorittamalla juuren testi, suoritetaan samalla koko puun sisältämät testit. Hierarkinen testipuu mahdollistaa ohjelman yhden osa-alueen tai toiminnallisuuden testaamisen kerrallaan. 4.3 Käyttöliittymä, TestRunner JUnit testikehys tarjoaa tekstipohjaisen ja graafisen käyttöliittymän testien ajamiseen ja virheraportin generoimiseen. Perustoiminnallisuus on molemmissa sama, testien suorittamisen eteneminen, ajetut testit, epäonnistuneet testit ja virheet raportoidaan käyttäjälle. 8
kuva 5.3.1 junit.ui.testrunner, graafinen käyttöliittymä testien suorittamiseen 4.4 Käytännön kokemuksia JUnit ympäristö helpottaa ohjelman testaamista ja muutosten toiminnan oikeellisuuden tarkistamista. Junit soveltuu hyvin käytettäväksi ohjelman implementoinnin yhteydessä tapahtuvaan testaamiseen. Testien kirjoittaminen on luonnollinen jatke ohjelman yksittäisen komponentin tai luokan implementaatiota ja dokumentaatiota. Testien ajaminen implementaation ohessa helpotti huomattavasti virheiden metsästämisessä. Ohjelmistotuotanto projektissa huomattiin komponenttien tai luokkien muutosten seurauksien tutkiminen koko ohjelman laajuudelta olevan äärimmäisen helppoa kun 9
jokaisen luokan toiminnallisuuden testaavat testit tehtiin samalla kuin itse luokka. Useita kertoja Junitin käyttö pelasti ryhmämme mahdollisesti pulmallisesta tilanteesta, kun pieni muutos jonkin luokan sisäisessä toimintalogiikassa olisi rikkonut koko ohjelman ja aiheuttanut vaikeasti löydettävän loogisen virheen. 5 Yhteenveto Testaamisen tulisi olla luonnollinen osa ohjelman kehitysprosessia. Automaattinen laadunvalvonta ja laadulliset ohjelmistomittarit voidaan perustaa automaattisten testien päälle. Testaamisen automatisointi helpottaa ohjelman päivityksestä johtuvien muutosten vaikutusten havainnointia. Yksikkötestaaminen ohjelman kehitysvaiheessa käyttäen xunit tyyppistä ympäristöä parantaa huomattavasti ohjelman laatua ja vähentää virheiden määrää. [6] Testaustyökalujen käyttö vaatii opettelua ja asennoitumista, mutta työkalujen käytöllä saatava hyöty on suurempi kuin käytön hinta. Testien automatisointi vaatii ohjelmointitaitoa ja ymmärrystä testattavasta ohjelmasta. 10
Lähteet [1] Kent Beck, JUnit Test Infected: Programmers Love Writing Tests, <URL: http://www.junit.org/junit/doc/testinfected/testing.htm, 11.11.2000> [2] Roger S. Pressman, (1997). Software Engineering, a practitioner's approach. U.S.A., McGraw Hill. 630-657 [3] JUnit cookbook <URL: http://www.junit.org/junit/doc/cookbook/cookbook.htm, 11.11.2000> [4] Antti Hämäläinen, Marko Saaresto, Mika Huhtamäki ja Niklas Laine, JFilterTable Testing document, Ohjelmistotuotanto ryhmä BETA, kevät 2000 [5] Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999. [6] ExteremeProgramming-website. <URL: http://www.extremeprogramming.org/, 11.11.2000> 11