INTEGROINTI- JA JÄRJESTELMÄTESTAUS
Huom! Myös yksikkötestaus on käsitelty tällä sivulla.
Yleistä
Kunnollinen testaaminen maksaa itsensä takaisin vähentyneenä ylläpidon tarpeena, vähentyneenä tarpeena käydä asiakkaan luona tekemässä jälkiasennuksia ja parempana asiakastyytyväisyytenä.
Testaamaton ohjelma ei toimi. Testaamisen jälkeen todennäköisyys, että ohjelma toimii kaikissa tilanteissa, on vain hieman parantunut.
Jos testaus paljastaa runsaasti virheitä, kannattaa moduuli tehdä kokonaan uudelleen, koska lisätestauksella ei kuitenkaan pystytä löytämään kuin vain hyvin pieni osa jäljellä olevista virheistä.
Testaamiseen katsotaan kuuluvan myös muita menetelmiä kuin varsinaisten testiajojen suorittamista: ohjelmakoodin katselmukset ja määritysten sekä muiden dokumenttien tarkastukset. Tässä kohdassa keskitytään kuitenkin testiajoihin.
Testaaminen voi kohdistua myös muihin seikkoihin kuin ohjelmiston tulosteiden oikeellisuuteen: suorituskykyyn, toimintaan epänormaaleissa tilanteissa jne.
Terminologiaa
- Verifiointi (verification, todentaminen): Ohjelman toiminnan tarkastaminen ohjelman määrityksiin nähden.
- Formaali verifiointi (formal verification): Ohjelman oikeellisuuden todentaminen jollain formaalilla menetelmällä.
- Testaus (testing, suppeassa mielessä): Ohjelman (tai sen osan) suorittaminen tarkoituksena löytää virheitä.
- Validointi (validation, kelpoistaminen; ohjelman tapauksessa): Ohjelman suoritus todellisessa ympäristössä tarkoituksena löytää kohtia, joissa ohjelma toimii käyttäjän tarpeiden vastaisesti.
- Virheidenpoisto (debugging): Havaitun virheen syyn etsiminen ja poistaminen (on siis korjaava eikä testaava toiminta).
Virheiden luokittelu
Virheitä voidaan luokitella eri perusteilla sen mukaan mihin luokittelua halutaan käyttää. Seuraavassa on eräitä luokitteluja.
- Virheiden luokittelu käyttäjän kokeman vaikutuksen mukaan:
- Vähäinen: Virheellä on vain esteettinen vaikutus (sarakkeen verran sivussa oleva porrastus raportissa).
- Ärsyttävä: Järjestelmän käyttäytyminen on ihmisen kannalta kummallista (esim. nimet katkaistaan tulostuksessa satunnaisesti).
- Kohtalainen: Tuloste on harhaanjohtava, virhe huonontaa suorituskykyä.
- Estävä: Järjestelmä ei suostu käsittelemään kelvollista syötettä.
- Vakava: Järjestelmä kadottaa tapahtuman.
- Erittäin vakava: Tapahtuma muuntuu toiseksi (tilillepano muuttuu tilitä otoksi).
- Kohtuuton: Erittäin vakavia virheitä tapahtuu jatkuvasti (eikä vain harvinaisten erikoistapausten kohdalla).
- Kestämätön: Järjestelmän tietokanta sekoaa siten, että sen kuntoonlaittaminen on vaikeaa.
- Katastrofaalinen: Järjestelmän suoritus päättyy hallitsemattomasti itsekseen.
- Saastuttava: Järjestelmä aiheuttaa virheitä muissa järjestelmissä tai ympäristössään.
- Virheiden luokittelu vaihemallin kannalta katsottuna:
- Syy virheellisessä vaatimusmäärittelyssä
- Syy virheellisessä suunnittelussa
- Syy ohjelmoinnissa
Testien lajeja
Yksikkötesti: yksittäisten moduulien testaaminen heti kun ne ovat suorituskelpoisia; katettava mahdollisimman tarkkaan ohjelmakoodin eri osat.
Integrointitesti: (osa)järjestelmän testaaminen kokonaisuutena sen varmistamiseksi, että osat toimivat yhdessä täydellisenä kokonaisuutena.
Järjestelmätesti: järjestelmän testaaminen ennen sen toimittamista asiakkaalle sen varmistamiseksi, että järjestelmä on vaatimusmäärittelyn ja sopimuksen mukainen.
Hyväksymistesti: asiakkaan suorittama testi, jossa järjestelmää verrataan vaatimusmäärittelyyn. Lisätietoa vaatimusmäärittely-sivulta.
Taantumatesti (regression test): kiinteän testiaineiston läpiajaminen määräajoin sekä aina ennen integrointitestausta sen varmistamiseksi, että jo olemassaolevat piirteet eivät ole "pilaantuneet" uusien piirteiden ohjelmoimisen yhteydessä.
Asennustesti: tarkoituksena varmistua siitä, että asiakkaalle asennettu versio sisältää oikean toimitusversion oikein parametrein ja että tämä versio todella toimii.
"Beettatesti": ohjelmisto (jolla ei yleensä ole erityistä tilaajaa ja jolle ei sen takia yleensä tehdä hyväksymistestiä) annetaan joillekin käyttäjille ennakkokäyttöön:
- käyttäjä saa ohjelman mahdollisimman aikaisin ja toimittaja antaa erityistukea
- käyttäjä on velvollinen raportoimaan toimittajalle kaikista havaitsemistaan virheistä
- toimittaja saa mahdollisuuden korjata erityyppisten käyttäjien havaitsemia virheitä ennen ohjelmiston massalevitystä
Päälähestymistavat
Lasilaatikko (white box): testaajlla on käytettävissään ojelmakoodi (käytetään yleensä yksikkötestissä).
Musta laatikko (black box): testaaja ei tiedä mitään ohjelman rakenteesta eikä sisäisestä toiminnasta.
Musta laatikko -testaus edellyttää kunnollista (ulkoista) määrittelyä. Sitä ei saada yleensä kovin kattavaksi, joten jokaisen paljastuneen virheen kohdalla tulee tarkastaa huolellisesti sekä virheellisen kohdan ympäristö että muut samantyyppiset kohdat koko ohjelmasta.
Yksikkötesti
Yksikkötesti tehdään yleensä lasilaatikkoperiaatteella, jolloin testaaja voi myös tarkastaa ohjelmakoodin.
Ohjelmoijan itsensä pitää tehdä ohjelmakoodin läpikäynti näin:
- Tarkista, että koodi noudattaa käytössä olevia ohjelmointiohjeita (tai teetä tämä jollain muulla ja tarkasta vastapalvelukseksi hänen koodinsa)
- Lue ohjelma läpi neljään kertaan etsien
- ensin painovirheitä
- sitten tietorakennevirheitä
- sitten ohjausrakennevirheitä
- ja viimeisellä kerralla käsittelyvirheitä.
- Käytä lukemisen apuna (=hidasteena) viivainta ja katso koodia hitaasti sana kerrallaan.
- Jos on käytettävissä vuokaavion automaattinen muodostaja, käytä sitä ja vertaa tulosta ajatuksiisi (tai suunnitelman yhteydessä mahdollisesti tehtyyn vuokaavioon tai muuhun suunitelmaan)
- Käy läpi suunnitelmasta ilmenevät erilaiset suorituspolut yksi kerrallaan ja tunnista ne ohjelmasta.
- Käännä ohjelma ensimmäistä kertaa ja poista syntaksivirheet
- Vasta tämän jälkeen voidaan siirtyä testiajojen suoritukseen.
Testitapausten suunnittelu
Lasilaatikkoperiaatetta käytettäessä täytyy huomioida eräitä testitapausten suunnittelu- eli kattavuusperiaatteita:
- Jokainen lause tulee suoritetuksi vähintään kerran.
- Jokainen ehto saa vähintään kerran kunkin yksittäisen tulosmahdollisuutensa.
- Jokainen silmukka suoritetaan vähintään kerran siten, että silmukassa tehdään 0, 1, maksimimäärä ja jokin muu määrä kierroksia.
- Jokainen polku (mahdollinen reitti alusta loppuun) tulee suoritetuksi vähintään kerran. (Silmukat huomioiden näitä on yleensä ääretön määrä, joten täytyy valita joukko tyypillisiä polkuja ja jokunen harvinainen polku.)
- Jokainen muuttuja ja jokainen parametri saa arvokseen vähintään
kerran seuraavat:
a) jos kyseessä numeerinen muuttuja:- jonkin liian pieni arvo (mikäli mahdollista)
- pienintä sallittua yhtä pienempi (mikäli mahdollista)
- pienin sallittu
- pienintä sallittua yhtä suurempi
- jokin väliarvo
- suurinta sallittua yhtä pienempi
- suurin sallittu
- suurinta sallittua yhtä suurempi (mikäli mahdollista)
- jokin liian suuri (mikäli mahdollista)
- ei yhtään bittiä päällä
- jokainen bitti yksinään päällä
- jokainen bitti yksinään pois päältä
- kaikki bitit päällä
- tyhjä jono
- yhden mittainen jono
- "tavanomaisen" mittainen jono
- maksimipituinen jono
- liian pitkä jono (mikäli mahdollista)
- pelkästään numeroita sisältävä jono
- numeroita ja kirjaimia sisältävä jono
- erikoismerkkejä sisältävä jono
- Jokaisen taulukon ylivuototilanne esiintyy vähintään kerran.
- Jokainen mutantti (eli ohjelmaan systemaattisella tavalla tehty mahdollista virhettä kuvaava muutos) paljastuu.
Mustan laatikon periaatetta käytettäessä on huomioitava seuraavat testitapausten kattavuusperiaatteet:
- Jokainen syöte saa arvokseen vähintään kerran jokaisen ylläluetelluista arvoista
- "Jokainen polku" -ajattelu, missä polku on peräkkäisten, käyttäjälle näkyvien toimenpiteiden sarja.
- Tyypillisten virheiden metsästys; tyypillisiä virheitä ovat:
- puuttuvat haarat ohjelmassa
- väärän reitin valinta
- väärän toimenpiteen suorittaminen
- Syötteiden testauskohteita:
- oikeiden ja virheellisten tietojen yhdistelmät
- tyhjien kenttien käsittely
- kelvottomien tunnistetietojen käsittely
- ensimmäisen syötteen käsittely
- toisen syötteen käsittely
- viimeisen syötteen käsittely
- liian vähän syötteitä
- liikaa syötteitä
- erikoistilanteet (vuodenvaihde, vuosituhannen vaihde)
- Päivityksen testauskohteita:
- tyhjän tiedoston päivitys
- tietueen lisääminen alkuun, loppuun, keskelle
- tietueen poisto alusta, lopusta, keskeltä
- olemassaolevan tietueen lisäys uudelleen
- olemattoman tietueen poisto
- erilaiset tiedostojen lopputilanteet
- erilaiset tapahtumayhdelmät (lisäys, muutos, poisto) samalle tietueelle
- tunnistetietojen muuttaminen
- Käsittelyn testauskohteita:
- laskentatarkkuus ja pyöristykset
- erikoistilanteet (vuodenvaihde, vuosituhannen vaihde)
- Tulostuksen testauskohteita:
- kaikki erilaiset tulostusmuodot
- otsikot ja sivunumerot
- erilaiset sivunvaihtotilanteet
- tulostettavien tietojen osittainen puuttuminen
- ohjetekstit
- erikoistilanteet (vuodenvaihde, vuosituhannen vaihde)
- Virheiden arvaaminen: oman kokemuksen perusteella testaaja voi arvata, mitkä seikat ovat vaikeita ja joissa siten arvattavasti esiintyy virheitä.
Testatessasi muista:
- toimi väärin (eli käyttöohjeen vastaisesti)
- käytä vääriä yhdistelmiä
- älä tee tarpeeksi
- älä tee mitään
- tee liikaa
- mutta älä unohda normaalitapauksiakaan!
Lisäksi määritysmuutosten jälkeen on aina (suoritettava taantumatesti ja) testattava muuttuneet kohdat (esim. kun kenttä on aiemmin ollut pakollinen vaan ei ole enää jne.)
Testitapausten tallettaminen
Testimateriaalin suunnittelussa ja muodostamisessa on niin paljon työtä, että materiaalin poisheittämisessä ei ole mitään järkeä. Testimateriaali kannatta yleensä jakaa 3-6 tasoon. Esimerkiksi:
- alitesti: yksittäinen testiaineisto
- testi: kokoelma alitestejä, jotka tulee aina suorittaa yhdessä (koska esim. ensimmäisen tulos on toisen syöte)
- testiryhmä: kokoelma testejä, jotka testaavat samaa asiakokonaisuutta
Testimateriaali tulee tallettaa versiohallinnan alaisuuteen, koska se muuttuu versioiden muuttuessa.
Testimateriaalin tulee sisältyä syötemateriaali, odotetut tulokset, kuvaus siitä mitä moduuleita testi koskee ja missä tilanteessa se voidaan suorittaa:
- tietokannan tila testiä käynnistettäessä
- tarvittavat apuohjelmistot ja niiden versiot
Virheiden raportoiminen
Testaajan on annettava ohjelmoijalle yksityiskohtainen kuvaus virheestä ja sen havaitsemisen aikana vallinneesta tilanteesta:
- käytetty laitteisto
- ohjelman versio
- apuohjelmien versiot
- testiaineiston tunnus ja versio
- tilanne yksityiskohtaisesti
- virhe ja odotettu tulos
- saadaanko tilanne toistumaan
- testin suorittaja
Virheiden syyn etsiminen
Ohjelmakoodin analysointiohjelmat (esim. lint) paljastavat muuttujat, joille ei anneta arvoa ennen ensimmäistä käyttöä, muuttujat, joita ei käytetä, koodin osat, joihin ei koskaan jouduta jne. Näitä apuvälineitä voidaan käyttää jo ennenkuin virhe esiintyy!
Virheen voi yrittää etsiä päättelemällä, jolloin lähtökohtana on mm. mitä oireita on löydetty, mistä ne on löydetty, missä olosuhteissa ne esiintyvät ja kuinka laajasti ne vaikuttavat. Tältä pohjalta kehitetään teoria virheen alkuperälle ja suunnitelma teorian paikkansapitävyyden selvittämiselle. Sen jälkeen suunnitelma toteutetaan.
Jos päättely ei auta, niin nuku yön yli. Jos et vieläkään pääse eteenpäin, niin kuvaa ongelma jollekin toiselle henkilölle. Jos et vieläkään löydä virhettä, niin käytä suoritusaikaista jäljitysohjelmaa.
Jos et vieläkään löydä virhettä, niin tee kokeiluja, esim. tulostuslauseiden sijoittaminen koodin sekaan.
Voit kokeilla myös virheiden nappaamista ja apupinon tulostamista; tärkeimmät funktiot laittavat tiedon itsestään apupinoon toimintansa alussa ja poistavat sen lopussa.
Virheiden korjaaminen
Päivitä ensin dokumentit tarvittavilta osin (mikä voi johtaa määritysdokumenttien uudelleenkäsittelyyn). Tee seuraavaksi korjaus (ja korjaa virhe äläkä vain sen oiretta).
Testaa korjauksen ympäristö huolellisesti, koska korjaus synnyttää helposti uuden virheen. Mieti tarvitaanko uusia testitapauksia. Suorita taantumatesti asianmukaiselta osaltaan.
Testaamisen lopettaminen
Testaamisen voi lopettaa, kun testitapaukset täyttävät valitun menetelmän vaatimukset eivätkä paljasta enää virheitä tai kun löydettyjen virheiden tiheys (testitapauksia kohti) laskee alle ennalta kiinnitetyn rajan.
Tätä varten voi käyttää "virheiden kylvämistä" (error seeding): ohjelmaan laitetaan joukko tahallisia virheitä, joiden löytymisprosentti antaa karkean arvion kaikkien virheiden löytymisprosentista.
Laatutietokanta
Laatutietokantaan tulee kerätä tiedot havaituista virheistä ja niiden syistä (jotka osittain selviävät vasta korjaamisen yhteydessä) sekä tiedot tehdyistä testeistä. Laatutietokannan avulla voidaan seurata testauksen etenemistä ja poimia esiin ongelmalliset moduulit, jotka kaipaavat erikoistarkastelun ja mahdollisen uudelleenohjelmoinnin.
Ongelmamoduulien tunnusmerkkejä:
- Virheitä on selvästi enemmän kuin muissa moduuleissa
- Uusien virheiden määrä ei laske tasaisesti
- Virheiden juuret ovat suunnittelun tasolla
Taantumatesteistä tulee kerätä tietoa yksittäisten testitapausten paljastamien viheiden lukumäärästä ("testitapauksen saanti"), jonka pohjalta taantumatestiä voidaan kehittää edelleen.
Integrointitesti
Järjestelmän osat liitetään toisiinsa yksi kerrallaan ja joka kerta uuden osan liittymät vanhoihin osiin testataan. Yleensä käytetään mustan laatikon ja lasilaatikon yhdistelmää.
Ensimmäiseksi valmistuneet komponentit eivät välttämättä muodosta kokonaisuutta, joka toimisi sellaisenaan, vaan voidaan joutua laatimaan erityinen testiympäristö, jossa komponenttien yhteistoimintaa voidaan testata.
Integrointi voidaan tehdä ylhäältä alas tai alhaalta ylös. Integrointi voidaan myös tehdä kertarysäyksellä (big bang); menetelmä toimii kuitenkin vain silloin, kun komponenttien väliset yhteydet ovat vähäisiä ja niistä huolehtii vain muutama (hyvin testattu) funktio.
Järjestelmätesti
Tämän testin kohteena on koko järjestelmä sekä dokumentaatio ja muut ei-ohjelmistokomponentit. Kohteina ovat (vaatimusmäärittelyssä ja sopimuksessa erikseen mainittujen kohteiden lisäksi)
- toiminnallisuus
- käyttöliittymä
- opasteet
- käyttäjädokumentaatio
- lopetus virhetilanteissa
- kuormitus
- isot määrät
- turvallisuus
- suorituskyky
- liitettävyys
- ulkoiset liittymät
- luotettavuus
- toipumiskyky
- asennettavuus
Järjestelmätestin on katettava kaikki edellä luetellut osa-alueet, vaikka niitä ei olisi erityisesti mainittu järjestelmän määrityksissä. Muuten näiden virheiden löytyminen tapahtuu järjestelmän varsinaisen käytön aikana, jolloin niiden korjaaminen tulee vielä kalliimmaksi.
Asennustesti
Suoritetaan jokaisen (asiakkalle tehdyn) asennuksen jälkeen. Asennustestissä on varmistuttava kahdesta asiasta:
- asennettu versio on oikea
- normaalit käyttäjät voivat käyttää järjestelmää
Testaukseen tulee kuulua
- Järjestelmän normaalia käyttöä peruskäyttäjän oikeuksilla varustetulla käyttäjätunnuksella
- Testejä, jotka osoittavat käytettävän version yksikäsitteisesti
- Testejä, jotka osoittavat, että asiakaskohtaiset parametrit ovat oikein
- Testejä, jotka paljastavat ovatko mahdolliset käyttöjärjestelmän ja apuohjelmien parametrit asetettu sopiviksi
Järjestelmän on jäätävä asennustestin jälkeen siihen tilaan, että sen käyttöönotto on välittömästi mahdollista (ilman tietokannan puhdistamista tms.).
Siltä varalta, että (uutta versiota asennettaessa) asennustesti ei mene läpi, on vanhasta ohjelmistosta otettava varmuuskopio ennen asentamisen aloittamista.
Apuvälineitä
Joidenkin tutkimusten mukaan testauksen apuvälineet ovat selvästi kannattavampi sijoituskohde kuin mikään muu ohjelmistotyön apuväline. Parhaat apuvälineet ovat yritysten oman kehittelytyön tuloksia ja nämä yritykset katsovat saavansa niin suuren etumatkan muihin nähden, että ko. apuvälineet eivät ole kaupan. Valtaosa todella käytettävistä apuvälineistä on nimenomaan itse tehtyjä.
Apuvälineiden luokkia
- Yleisvälineitä:
- kattavuuden raportoijat
- vuokaavion muodostajat
- mittarit (esimerkiksi monimutkaisuus, joka osoittaa tarvittavan testauspanoksen määrää)
- Testiajojen suorituksen automatisointi:
- "nappaus/toisto" (capture/replay): nappaa testaajan näpyttelyt ja tarjoaa ne myöhemmin uudelleen ohjelmalle; edellyttää napatun näppäilysarjan muokkausmahdollisuutta sekä älykästä vertailijaa
- puuttuvien moduulien korvaajien muodostamisen apuvälineet
- Testitapausten suunnittelun automatisointi:
- ohjelmaa tutkivat testigeneraattorit: tuottavat testitapauksia, joiden avulla saadaan tietyn tyyppinen kattavuus
- satunnaiset generaattorit: tuottavat satunnaisia testitapauksia (esim. materiaalia kuormitustesteihin)
Testaamisen suunnittelusta
Yksikkötesteille ei aina laadita testaussuunnitelmia, mutta tällöinkin on oltava käytössä yksikkötestin suoritusohje. Katso myös eräs toimiva ratkaisu.
Integrointitestille ja järjestelmätestille on laadittava testaussuunnitelma, josta on käytävä ilmi mm:
- integroinnin järjestys (integrointitestin tapauksessa)
- kukin suoritettava testi:
- tarkoitus (tehokkuustesti, ...)
- testattava moduuli/kokonaisuus
- viite vastaavaan vaatimukseen
- testauksessa käytettävä ympäristö (laitteisto, ohjelmistot)
- testin aloitustoimenpiteet
- testimateriaali ja testin suorittaminen askel askeleelta
- testin lopetuskriteeri
- testin lopetustoimenpiteet
- testaamisen aikataulu
- tarvittavat resurssit (henkilöt, laitteet, apuohjelmistot)
Testaussuunnitelma on tarkastettava kiinnittäen huomiota seuraaviin seikkoihin:
- täydellisyys
- kattaako testaus kaikki vaatimukset?
- kattaako testaus kaikki moduulit ja liitännät?
- toteutettavuus
- ovatko resurssit käytettävissä suunniteltuina ajankohtina?
- ovatko resurssit riittävät?
- ovatko moduulit valmiita silloin, kun niitä tarvitaan?
- muodostavatko moduulit yhtenäisen kokonaisuuden silloin, kun niitä tarvitaan yhdessä?
Integrointitestauksesta ja järjestelmätestauksesta on laadittava testausraportti, josta käy ilmi kaikki havaitut ongelmat.
Vain jäsenille: