Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio

Transkriptio

1 Testiraportti /5 - Noheva II Testiraportti Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio 1 Yleistä Toteutusvaiheen 2 virallinen testaus on muodostunut automaattisista yksikkötesteistä ja testitapauksiin perustuvista järjestelmätesteistä. Alun perin suunnitellut integraatiotestit on jätetty pois, kuten ensimmäisessäkin toteutusvaiheessa, koska arkkitehtuurissa ei ole niille soveltuvia kokonaisuuksia. Virallisen testauksen lisäksi on ohjelmaa tietenkin testattu monella tavalla kehitystyön yhteydessä. Myös asiakas on kokeiluversioita käyttäessään raportoinut vikoja, ja nämä tiedot ovat olleet poikkeuksetta hyödyllisiä. Tarkoituksena on lisäksi järjestää hyväksymistestaus, jossa ohjelmiston toimintaa verrataan alun perin asetettuihin tavoitteisiin ja vaatimuksiin. Hyväksymistestaus järjestetään tämän asiakirjan valmistumisen jälkeen. 2 Automaattiset yksikkötestit Yksikkötestausta ei ole laajennettu ensimmäisen toteutusvaiheen jälkeen, koska uusia ominaisuuksia ei olisi voitu niillä järkevästi testata. Tämä luku on kopioitu suoraan ensimmäisen toteutusvaiheen testiraportista, koska muutoksia ei ole tullut. 2.1 Kattavuus Automaattiset yksikkötestit on tehty seuraaville ohjelman osille: laskenta tietorakenteet VBOX-tiedoston parseri

2 Testiraportti /5 tiedostojen käsittely Käyttöliittymän ja raporttitoiminnon testauksessa automaattiset yksikkötestit eivät ole mielekkäitä, koska toiminnot eivät tuota paluuarvoja eikä niitä kutsuta muista ohjelman osista. 2.2 Suoritus Automaattiset yksikkötestit ovat osittain liittyneet testiohjattuun kehitykseen. Näissä tapauksissa testit on kirjoitettu ennen niihin liittyviä luokkia. Automaattisia testejä on suoritettu kehitystyön ohessa sen varmistamiseksi, että niihin liittyvien ohjelman osien toiminta pysyy vakaana tehtävistä muutoksista huolimatta. 2.3 Laatu Yksikkötesteillä katetaan niihin liittyvien luokkien normaali käyttötilanne sekä mahdollisimman paljon erilaisia poikkeustilanteita, joita voidaan olettaa esiintyvän. Kaikkia mahdollisia tapauksia ei ole käsitelty eikä esimerkiksi rajaarvoanalyysiä (boundary-value analysis) ole yleensä tehty. 3 Ohjelmakoodin analyysi QJ-Pro-ohjelmiston testiversiolla suoritetussa analyysissä Noheva II:sta saatiin ohjelmointityyliin liittyvää huomautusta. Ensimmäisen toteutusvaiheen jälkeen löytyi huomautusta koodirivin joukosta. Toisessa projektissa saatiin hyvälaatuisesta koodista noin 0,28 huomautusta yhtä koodiriviä kohti. Ensimmäisen testivaiheen jälkeen tämä luku oli 0,41. Toisen testivaiheen lukua ei voida esittää, koska koodirivien määrä ei ollut tiedossa tätä kirjoitettaessa. Oletettavaa kuitenkin on, että huomautusten määrä on kasvanut. Lukuarvoista ei voi tehdä suoraa päätelmää ohjelmakoodin laadusta. Koodauskäytäntöjä on yleensä noudatettu hyvin, mutta koodiin on jäänyt myös kohtia, joissa olisi parantamisen varaa. Koodia pyritään selventämään ennen ohjelman lopullista luovutusta asiakkaalle, mikä tapahtuu tämän asiakirjan viimeistelyn jälkeen.

3 Testiraportti /5 4 Järjestelmätesti Testi tehtiin versiolle, josta puuttui raporttitoiminto. Lisäksi testiympäristössä oli tietoliikenneongelmia. Oheismateriaalina käytetty, alkuperäinen Excel-laskentaarkki ei myöskään toiminut. Tästä syystä neljä testitapausta 26:sta jätettiin suorittamatta. 4.1 Yleistä Päivämäärä: Kellonaika: Testaaja: Sami Tikkanen 4.2 Testiympäristö Tietokone: AMD Ahtlon XP 2133 MHz, 512 MB Käyttöjärjestelmä: Windows 2000 Professional SP4 Java-versio: 1.5 Noheva II -versio: _ Testin sisältö Projektiryhmän kotisivuilla osoitteessa kohdassa Asiakirjat on määritelty testitapaukset, jotka on koottu testijoukoiksi. Testijoukkoja testattiin seuraavasti: Testijoukko Testejä Suoritettiin Läpäisi Hylättiin Läpäisyprosentti Projekti % Testityyppi % Koesarja % Koe % Graafit % Laskenta % Raportti %

4 Testiraportti /5 Säätiedot % Keskustietokanta % YHTEENSÄ % 4.4 Tulokset Testatut ominaisuudet toimivat pääpiirteissään hyvin. Ohjelma toimi vakaasti, ja sitä voitaisiin jo käyttää tuotantotoiminnassa. Raportin puuttuminen rajoittaa kuitenkin merkittävästi ohjelmasta saatavaa hyötyä. Keskustietokantaan ja laskennan oikeellisuuteen liittyviä testitapauksia ei voitu käyttää ohjelmaan liittymättömien ongelmien vuoksi. Laskennan oikeellisuus on todettu aikaisemmin, ja keskustietokantaan liittyvät ominaisuudetkin ovat toimineet muissa testiympäristöissä. Ohjelmassa on kuitenkin muutamia pikkuvikoja, jotka pääasiassa häiritsevät lievästi käyttöä. Ainoa keskeisempi vika on se, ettei suoritusten kellonaikoja voi muokata. Vähintäänkin tämä vika tulee korjata ennen ohjelman luovutusta asiakkaalle. Testiloki on nähtävillä projektiryhmän kotisivujen yhteydessä osoitteessa Testauksessa löydetyt viat on raportoitu kurssin tarjoamaan Bugzilla-järjestelmään. 5 Vertaistestaus Toimitimme vertaisryhmälle ohjelmamme kattavine testausohjeineen aikataulun mukaisesti. Vertaisryhmä toimitti aikataulun mukaisesti testiraportin, jossa testin tulokset on kerrottu. Vertaisryhmä oli testannut ohjelmaa huolellisesti ja monipuolisesti. Myös testitulokset olivat pääosin hyödyllisiä, vaikkakin näkökulma ohjelman käyttöön oli luonnollisesti lähinnä tutkiva sen sijaan, että ohjelmaa olisi tarvittu tiettyyn tarkoitukseen. Vertaistestaukseen liittyvät asiakirjat ovat saatavilla erikseen toteutusvaihe 2:n dokumenttien palautussivun kautta. Näihin sisältyvät myös vertaisryhmän meille lähettämät ohjeet sekä vertaisryhmälle lähettämämme testitulokset.

5 Testiraportti /5 6 Vikojen hallinta Varsinaisissa järjestelmätesteissä (myös aikaisemmissa) havaitut viat on kirjattu Bugzillaan. Manageriryhmään kuuluvat ovat seuranneet vikoja ja päättäneet niihin liittyvistä toimenpiteistä. Suurin osa testauksesta on kuitenkin tehty kehitystyön yhteydessä ilman erityistä testitapauslistaa. Tällä tavoin havaitut, yleensä pienet viat on joko korjattu heti tai käsitelty ryhmätapaamisissa. Korjausvastuu on annettu jollekin kehittäjistä. Vikaraportteja on saatu myös asiakkaalta sekä vertaisryhmältä. Myös nämä viat on käsitelty ja korjattu kuten kehitystyön yhteydessä havaitut viat. Vaikka Bugzillan käyttö kaikkien vikojen kirjaukseen olisikin ollut projektinhallinnan kannalta järkevää, kokivat kehittäjät Bugzillan liian hitaaksi ja huonosti käytettäväksi, jos kyseessä oli ainoastaan vähäisen vian merkitseminen. Bugzillan käytettävyydessä onkin tuntuvasti parantamisen varaa. Erityisenä harmistuksen aiheuttajana on kankea navigointi sivujen välillä. Käyttäjä haluaisi siirtyä nopeasti sivulta toiselle, mutta linkki halutulle sivulle joko puuttuu tai sitten se on sijoitettu vaikeasti löydettävään kohtaan sivun alatai ylälaitaan. Bugzillan sivut ovat myös joskus liian pitkiä, jolloin haluttua kohtaa voi joutua etsimään vierittämällä sivua toistuvasti edestakaisin. Vikojenhallintajärjestelmän pitäisi olla merkittävästi parempi, jotta kynnys sen käyttöön ei muodostuisi niin korkeaksi. Jälkikäteen todeten olisi kannattanut ehdottomasti rakentaa oma vikojenhallintajärjestelmä tuntikirjausjärjestelmämme yhteyteen.