Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Testisuunnitelma Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset 0.1 19.11.2003 Kalle Valo Alustava suunnitelma kirjoitettu. 0.2 25.11.2003 Kalle Valo Paranneltu kommenttien ja keskustelujen pohjalta. 0.3 28.11.2003 Kalle Valo Lisätty tekstiä yksikkötestauksesta ja testikohteista. 1.0 29.11.2003 Jouni Karppinen & Hannu Kauppinen Dokumentti tarkastettu ja korjattu I1-vaiheen palautusta varten.
Sisällysluettelo 1 Johdanto... 1 2 Testikohteet... 2 2.1 Julkaisut... 2 2.2 Testattavat ominaisuudet... 2 2.3 Testaamattomat osa-alueet... 3 3 Lähestymistapa... 4 3.1 Yksikkötestaus... 4 3.2 Automaattinen järjestelmätestaus... 4 3.3 Julkaisutestaus... 5 3.3.1 Testitapausmatriisi... 5 3.3.2 Testiraportti... 5 3.4 Rasitustestaus... 5 3.5 Integraatiotestaus... 6 3.6 Hyväksyntätestaus... 6 3.7 Virheraportointi... 6 4 Testijärjestelyt... 7 4.1 Tuotokset... 7 4.2 Tehtävät ja aikataulutus... 7 4.3 Ympäristövaatimukset... 7 4.4 Vastuualueet... 7 4.5 Koulutustarpeet... 8 Viitteet... 9
1 Johdanto Tämä on projektin Lmodels testisuunnitelma. Lmodels on lineaaristen rajoitteiden ratkaisija, joka toteutetaan TKK:n kurssin T-76.115 Tietojenkäsittelyopin ohjelmatyö puitteissa lukuvuonna 2003-2004. Projektissa on seitsemän jäsentä ja kaikki ovat TKK:n opiskelijoita. Projektin tavoitteena on kehittää Teknillisen korkeakoulun Ohjelmistoliiketoiminnan ja -tuotannon instituutin WeCoTin (Web Configuration Technology) -tutkimusryhmälle lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija, jota tutkimusryhmä voi hyödyntää osana omaa järjestelmäänsä. Projektin tuote voidaan jakaa kolmeen pääkomponenttiin: Lmodels Server, Lmodels CLI client ja Lmodels Web client. Asiakas tarvitsee erityisesti Lmodels Server -komponentin. CLI client ja Web client ovat pääasiassa järjestelmän testausta varten. Tämä testisuunnitelma seuraa pääpiirteittään IEEE:n standardin 829-1998 määrittelyä testisuunnitelmasta, mutta projektin pienuudesta johtuen sitä ei noudateta tarkkaan [1]. Tämä suunnitelma ei ota kantaa vertaisryhmän testaukseen. 1
2 Testikohteet Järjestelmän ytimenä on lineaarisen mallin käsittely ja ratkaisujen etsiminen sen pohjalta. Testaus on tarkoitus kohdentaa pääosin tähän, ja käyttöliittymät, joiden avulla ratkaisuja voidaan hakea, testataan vain päällisin puolin. On kuitenkin huomioitava, että koska testaus tapahtuu osittain näiden käyttöliittymien läpi, niin testeillä voidaan myös varmistaa käyttöliittymän riittävä toiminta. Testattava pääpaino kohdistuu siten komponentille: Lmodels Server Vähemmän huomiota kohdistetaan käyttöliittymille: Lmodels CLI client Lmodels Web client 2.1 Julkaisut Iteraatioiden loppupuolella järjestelmästä tehdään julkaisuja, jotka testataan kattavasti. Myös epävirallista testausta tehdään koko kehityksen aikana, mutta virallinen testaus suoritetaan vain versionhallintaan merkityille julkaisuille. Näiden testauksesta kirjoitetaan myös testiraportit. Julkaisuja tehdään kaksi jokaisen iteraation loppupuolella. Näistä ensimmäinen, välijulkaisu, tehdään noin puolitoista viikkoa ennen iteraation loppua ja lopullinen julkaisu iteraation lopussa. Molemmat testataan, ja jälkimmäinen toimitetaan asiakkaalle testiraportin kanssa. Vastuu julkaisuista ja niihin liittyvistä tehtävistä on selvennetty taulukossa 1. Tehtävä Välijulkaisun ja virallisen julkaisun merkitseminen versionhallintaan. Julkaisujen kääntäminen ja pakettien toimittaminen testaajalle. Julkaisujen testaaminen: - automaattisten testien ajaminen - manuaalisten testien tekeminen Testiraportin kirjoittaminen: - testauksen tulokset ja tiedossa olevat puutteet Lopullisen julkaisun ja testiraportin toimittaminen asiakkaalle. Taulukko 1: Julkaisuvastuut. 2.2 Testattavat ominaisuudet Vastuuhenkilö Hannu Kauppinen Hannu Kauppinen Kalle Valo Kalle Valo Hannu Kauppinen Järjestelmän testaus kohdistuu pääosin sen normaaliin käyttöön eli kielen lukemiseen ja rajoitteiden ratkaisujen löytymiseen. Lisäksi testataan myös järjestelmän suorituskykyyn liittyviä ominaisuuksia sekä koko järjestelmän kuormituksen sietokykyä. Suorituskykytestauksen tavoitteena on selvittää järjestelmän tehovaatimukset sekä ratkaisuihin kuluva aika erilaisilla syötteillä. Näillä tiedoilla on tärkeä merkitys projektin 2
asiakkaan tutkimustyön kannalta. Lisäksi niillä voidaan arvioida mallin optimoinnin hyödyllisyyttä ratkaisuaikojen kannalta. Testausta tehdään siis seuraaviin ominaisuuksiin: Syötteen lukeminen Rajoitteiden ratkaisujen löytyminen Ratkaisijan tehovaatimukset ja kulutettu aika Kuormituksen sietäminen 2.3 Testaamattomat osa-alueet Asiakas ei ole suuremmin kiinnostunut järjestelmän käyttöliittymästä, ja siksi sitä ei testata kattavasti. Näin ei myöskään käyttöliittymälle tehdä kattavia käytettävyystestejä, ja muutenkin kaikki käyttöliittymään kulutetut resurssit pyritään pitämään mahdollisimman vähäisinä. Myöskään eri laitteistoarkkitehtuureita ei testata vaan luotamme Java-virtuaalikoneen toimivan samalla tavalla eri arkkitehtuureissa. Järjestelmää kehitetään pääosin Linux ympäristössä, mutta sitä ajetaan myös koulun ATK-keskuksen koneilla ja siten pyritään välttämään ympäristökohtaisten asetusten käyttöä. 3
3 Lähestymistapa Testauksen pitää olla kehittäjien kannalta mahdollisimman kevyttä ja joustavaa. Muuten testaaminen voi jäädä puolitiehen tai jopa kokonaan huomioimatta. Automatisointiin kannattaa panostaa mahdollisimman paljon, koska se lisää testien ajamisen määrää huomattavasti. Asiakas on erityisesti kiinnostunut Lmodels Server -komponentista, jonka tulee olla helposti liitettävissä muihin järjestelmiin. Tästä johtuen käyttöliittymien testaus on pienemmällä prioriteetilla testauksen painottuessa Lmodels Server -komponentin testaukseen. Projektin luonne pitää ottaa huomioon testauksessa. Kehitettävä tuote ei tule olemaan mikään yksinkertainen tiedontallennusväline (esimerkiksi ajanseurantajärjestelmä) vaan matemaattisen mallin ratkaisija, joka perustuu paljolti teoriaan. Tämä tuottaa haasteita testaukseen, ja pelkkä nappien toimintojen testaaminen ei riitä. Testiaineisto tulee olemaan hyvin laajaa ja monimutkaista, ja odotetut vastaukset ovat pitkiä. Siksi testauksessa painotetaan eniten automatisoitua yksikkö- ja järjestelmätestausta. Julkaisuille tehdään myös manuaalisia testejä, mutta niiden osuus on pienempi. 3.1 Yksikkötestaus Yksikkötestauksella testataan järjestelmässä toteutettujen luokkien yksittäisiä metodeja. Testien kirjoittaja on perillä toteutuksen yksityiskohdista ja testien tarkoituksena on varmistaa, että toteutus toimii halutulla tavalla. Tämän lisäksi testit kirjoitetaan siten, että niiden automaattinen ajaminen on mahdollista, jotta voidaan varmistaa, että toiminnallisuus ei ole hajonnut sitä parannettaessa tai laajennettaessa. Testauksessa käytetään apuvälineenä JUnit-ohjelmistoa, joka tarjoaa yksinkertaisen tavan tehdä automaattisesti ajettavia testejä Java:lla toteutettuun järjestelmään. Ohjelmisto on vapaasti levitettävä ja hyvin laajalti käytössä. Testejä voidaan kirjoittaa joko kehityksen tukena itse toiminnallisuutta toteutettaessa, tai niitä voidaan lisätä jälkikäteen tärkeille komponenteille. Parasta olisi, että kehittäjä itse kirjoittasi omiin luokkiinsa yksikkötestit, mutta projektin aikataulun rajoitteiden puitteissa tähän ei välttämättä riitä aikaa. Yksikkötestien ajaminen liitetään osaksi kääntöympäristöä, jotta niiden ajaminen olisi mahdollisimman helppoa. Kehittäjien olisi hyvä ajaa testejä läpi aina silloin tällöin sekä varsinkin silloin, kun he ovat tehneet suuria muutoksia toteutukseen. Testikierros pitää suorittaa ennen jokaista julkaisua. Testikierroksista ei kirjoiteta erillisiä testiraportteja, vaan niiden tulokset sisällytetään muihin testiraportteihin tarpeen mukaan. 3.2 Automaattinen järjestelmätestaus Lmodels:n automaattista järjestelmätestausta varteen luodaan järjestelmä, joka ajaa automaattisesti testitapauksia ja osaa tarkistaa testien tulokset. Itse testit kirjoitetaan erillisiin tiedostoihin, yksi testi tiedostoa kohti, jotta testejä voidaan helposti lisätä. Nämä testitiedostot sisältävät syötteen ja oikeat vastaukset. Testijärjestelmä ajaa testit käyttäen CLI client -ohjelmaa ja raportoi tulokset testaajalle. Testitiedoston tarkka formaatti sovitaan iteraation I2 alussa. WWW-käyttöliittymän automaattinen järjestelmätestaus toteutetaan HttpUnitilla. 4
Automaattisesta järjestelmätestauksesta ei tarvitse kirjoittaa testiraportteja. 3.3 Julkaisutestaus Yksikkötestauksen ja automaattisen järjestelmätestauksen lisäksi tehdään julkaisutestauksia, jotka suoritetaan aina kun uusi julkaisu on valmis. Julkaisutestauksessa ajetaan testitapausmatriisissa määritellyt testitapaukset ja siitä kirjoitetaan aina testiraportti. 3.3.1 Testitapausmatriisi Testitapaukset listataan omassa testitapausmatriisissa, joka sisältää taulukossa 2 mainitut asiat. Matriisi pohjautuu kurssin antamaan esimerkkiin [2]. Matriisi tehdään erilliseen taulukkoon. Nimi Testikokoelma Testitapaus Vaatimusmäärittely Prioriteetti Kuvaus Sisältö Odotettu tulos Automatisoitu Tarkoitus Mihin kokoelmaan testitapaus kuuluu Testitapauksen tunniste Vaatimusmäärittelyn tunniste Testitapauksen prioriteetti (matala, normaali tai korkea) Lyhyt kuvaus Miten testitapaus suoritetaan Miten järjestelmän pitäisi toimia Onko testitapaus automatisoitu Huomioitavaa Muuta huomioitavaa, esim. virheraportin tunniste merkitään tähän Taulukko 2: Testitapausmatriisin sisältö. Aina, kun uusi testi suoritetaan, matriisiin lisätään kaksi uutta saraketta, testitapauksen tulos ja kommentit. Tulos sisältää testitapauksen tuloksen, joka on joko läpi tai hylätty. Kommenttiin pitää merkitä ainakin virheraportin tunniste, mikäli sellainen on kirjoitettu. Jokaiseen uuteen testitulossarakkeeseen merkitään myös testauksen päivämäärä ja testattu versio. 3.3.2 Testiraportti Testiraportteja varten luodaan erillinen raporttipohja, joka pohjautuu kurssin antamaan testiraporttimalliin [3]. 3.4 Rasitustestaus Lmodels-järjestelmälle tullaan tekemään rasitustestejä ja mittauksia siitä, miten se käyttäytyy kuormitettuna. Testien tulosten pitäisi antaa suuntaviivoja siitä, millaisia tehovaatimuksia järjestelmällä on ja mikä on sen luotettavuus kuormitettuna. Rasitustestaus tehdään palautusvaiheen iteraatiossa (DE) lähes valmiille järjestelmälle. Näin testauksen tuloksista on eniten hyötyä järjestelmän jatkokehityksen kannalta. 5
Rasitustestauksesta kirjoitetaan vapaamuotoinen raportti. Rasitustestauksen prioriteetti on matala, ja se tehdään, jos resursseja riittää. 3.5 Integraatiotestaus Projektissa ei tehdä ollenkaan integraatiotestausta, koska ei ole tietoa siitä, millaiseen järjestelmään tuote myöhemmin liitetään. 3.6 Hyväksyntätestaus Asiakas toimittaa testitapaukset, joilla tehdään hyväksyntätestaus DE-iteraatiossa. Hyväksyntätestauksesta kirjoitetaan virallinen testiraportti. 3.7 Virheraportointi Projektiryhmän käyttöön on asennettu Bugzilla virheraportointia varten. Kehittäjien pitää merkitä sinne virheet, jotka eivät ole heidän omalla vastuualueellaan tai joiden korjaaminen tapahtuu vasta seuraavassa iteraatiossa. Myös julkaisutestauksissa löydetyt virheet kirjataan Bugzillaan. Bugzillassa virheet jaetaan eri komponenteille, ja joka komponentille annetaan vastuuhenkilö, joka vastaa komponentin virheraporteista. Jos virheelle ei löydy sopivaa komponenttia, virheraportti sijoitetaan General-komponenttiin, joka on testaaja Kalle Valon vastuulla. 6
4 Testijärjestelyt 4.1 Tuotokset Seuraavat asiat ovat testaamisen tuotoksia: Testisuunnitelma Testitapaukset Testiraportit Virheraportit (Bugzillaan) 4.2 Tehtävät ja aikataulutus Taulukossa 3 on listattu testaukseen liittyvät tehtävät ja niiden aikataulut karkealla tasolla. Tehtävä Testisuunnitelman kirjoittaminen Bugzillan käyttöönotto Yksikkötestauksen perustan toteutus Automaattisen järjestelmätestauksen toteutus Testitapauksien suunnittelu Julkaisutestausten tekeminen ja raportointi Rasitustestaus Hyväksyntätestaus 4.3 Ympäristövaatimukset Vaihe I1 I1 I2 I2 I2 I2, I3, DE DE DE Taulukko 3: Testaukseen liittyvät tehtävät ja niiden aikataulutus. Ympäristövaatimukset ovat samat kuin kehitysympäristön vaatimukset, jotka on kuvattu tarkemmin projektisuunnitelmassa ja vaatimusmäärittelyssä. 4.4 Vastuualueet Yleisestä testauksesta vastaa Kalle Valo. Hänen vastuualueinaan ovat erityisesti: Testisuunnitelman kirjoittaminen Testitapauksien suunnittelu Bugzillan asentaminen, ylläpito ja käyttötuki Automaattisen järjestelmätestauksen suunnittelu ja toteutus (henkilökohtainen aihe) Julkaisutestien suorittaminen Hyväksyntätestauksen suorittaminen Rasitustestien suorittaminen Testiraporttien kirjoittaminen 7
Vesa Salento vastaa yksikkötestauksesta, joka on hänen henkilökohtainen aiheensa kurssilla. Luokkien kirjoittajien odotetaan myös kirjoittavan yksikkötestejä, mutta Kalle Valo huolehtii, että niitä on myös kirjoitettu. 4.5 Koulutustarpeet Projektin jäsenille pitää kouluttaa, miten järjestelmä- ja yksikkötestejä kirjoitetaan ja miten testejä ajetaan. Vesa Salento kirjoittaa pienen ohjeen yksikkötestauksien tekemiseen ja muutenkin opastaa kehittäjiä aiheeseen liittyen. Järjestelmätestauksen ohjeistuksen tekee Kalle Valo. Myöskin Bugzillan opastukseen voi olla tarvetta ja sitä tehdään tarpeen mukaan. Kalle Valo vastaa Bugzillaan liittyvistä kysymyksistä. Kielen käsittelyyn liittyvien testitapauksien kirjoittamisessa auttaa tarvittaessa Joonas Kekoni. 8
Viitteet [1] IEEE, IEEE Std 829-2998, IEEE Standard for Software Test Documentation, 16.9.1998, viitattu 25.11.2003, URL: http://standards.ieee.org/reading/ieee/std/se/829-1998.pdf (maksullinen) [2] SoberIT, T-76.115 kurssimateriaali, Test Case Matrix, 14.10.2003, viitattu 29.11.2003, URL: http://www.soberit.hut.fi/t-76.115/03-04/ohjeet/testcasematrix.xls [3] SoberIT, T-76.115 kurssimateriaali, Test Report, 9.9.2003, viitattu 29.11.2003, URL: http://www.soberit.hut.fi/t-76.115/03-04/ohjeet/template/test_report.html 9