Ohjelmistotestauksen Perusteet

Ohjelmistotestauksen perusteet
versio 1.0
Sisällysluettelo
Sisällysluettelo ................................................................................................................................ 2
Johdanto ......................................................................................................................................... 4
Luku 1 Mitä on ohjelmistotestaus? .................................................................................................. 5
Testauksen määritelmä ............................................................................................................... 5
Testauksen psykologia ja tavoitteet ............................................................................................. 5
Virheiden eliminointi ja aikainen testaus................................................................................... 5
Testaus osana laadunvarmistusta............................................................................................ 6
Virheet, viat ja häiriöt ................................................................................................................... 7
Virheiden tunnistaminen ja luokittelu ........................................................................................ 7
Virheiden vakavuus ja vaikutukset ........................................................................................... 8
Virheenjäljitys........................................................................................................................... 9
Luku 2 Testaus ohjelmiston elinkaaressa ...................................................................................... 10
V-malli ja testaustasot ............................................................................................................... 11
Moduulitestaus....................................................................................................................... 12
Integrointitestaus ................................................................................................................... 12
Järjestelmätestaus ................................................................................................................. 15
Hyväksymistestaus ................................................................................................................ 18
Ylläpito- ja uudelleentestaus ...................................................................................................... 19
Luku 3 Testausprosessi ja sen hallinta.......................................................................................... 19
Testaustyön roolit ja tehtävänjako ............................................................................................. 20
Testauksen suunnittelu.............................................................................................................. 20
Testausstrategia .................................................................................................................... 21
Testaussuunnitelma ............................................................................................................... 21
Testauksen kohdentaminen ja priorisointi .............................................................................. 23
Testitapausten suunnittelu ..................................................................................................... 23
Testauksen toteuttaminen ......................................................................................................... 24
2
Vaihekohtainen testaus .......................................................................................................... 25
Testitulosten tarkastelu ja raportointi ...................................................................................... 25
Testauksen riittävyyden arviointi ja testauksen päättäminen...................................................... 26
Testauksen kattavuus ............................................................................................................ 26
Virheiden analysointi .............................................................................................................. 27
Testauksen tehokkuuden arvioiminen .................................................................................... 28
Testauksen päättämistehtävät ............................................................................................... 28
Yhteenveto testauksen työvaiheista ja tuotoksista ..................................................................... 29
Luku 4 Testaustekniikat ................................................................................................................ 30
Staattiset testaustekniikat .......................................................................................................... 30
Katselmukset ......................................................................................................................... 31
Tarkastukset .......................................................................................................................... 32
Dynaaminen testaus .................................................................................................................. 34
Valkolaatikkotestauksen menetelmät ..................................................................................... 35
Mustalaatikkotestauksen menetelmät .................................................................................... 38
Kokemukseen perustuvat menetelmät ................................................................................... 44
Luku 5 Testauksen työkalut .......................................................................................................... 46
Testausprosessin hallintaan liittyvät työkalut ............................................................................. 46
Staattisen testauksen työkalut ................................................................................................... 47
Dynaamisen testauksen työkalut ............................................................................................... 47
Yksikkötestauksen työkalut .................................................................................................... 48
Toiminnallisen testauksen työkalut ......................................................................................... 49
Suorituskykytestauksen työkalut ............................................................................................ 50
Tietoturvatestauksen työkalut ................................................................................................ 50
Testiaineistogeneraattorit ....................................................................................................... 51
Lähteet.......................................................................................................................................... 52
Liite 1. Testaustermien suomi-englanti sanasto ............................................................................ 53
3
Johdanto
Tämän oppaan tarkoituksena on tutustuttaa lukija ohjelmistotestauksen käsitteisiin, näkökulmiin ja
tekniikoihin sekä havainnollistaa mitä ohjelmistotestaus käytännössä on. Oppaan keskeinen ajatus
on tarjota lukijalle käytännön perustiedot ja työkalut, joilla testauksen suunnittelua, toteutusta ja
analysointia pääsee itsenäisesti harjoittelemaan.
Opas on jaettu viiteen lukuun. Ensimmäisessä luvussa määritellään testauksen käsitteitä sekä esitetään näkökulmia miksi testausta tarvitaan. Toinen luku kuvaa V-mallin avulla testausprosessin
vaiheet osana ohjelmiston elinkaarta. Kolmannessa luvussa käsitellään testauksen perusprosessia
ja sen hallintaa. Neljännessä luvussa esitellään staattisen ja dynaamisen testauksen lähestymistapoja, menetelmiä ja tekniikoita. Viidennessä luvussa käsitellään testauksen työkalutukea sekä luetellaan vapaan lähdekoodin ohjelmistoja, joita voidaan hyödyntää testauksen eri työvaiheissa. Oppaan lopussa olevat liitteet sisältävät tärkeimpien testaustermien suomi-englanti sanaston sekä
hyödyllisiä dokumenttipohjia testauksen suunnittelua ja raportointia varten.
4
Luku 1 Mitä on ohjelmistotestaus?
Testauksen määritelmä
Glenford J. Myers esittää vuonna 1979 ilmestyneessä alkuperäisteoksessaan ”The Art of Software
Testing” käsitteen ohjelmistotestaus, johon yhä edelleen viitataan testaustyön keskeisimmän tehtävän ja tavoitteen määritelmänä:
Testing is the process of executing a program with the intent of finding errors (Myers 1979, 5).
Samaan tapaan muotoilee myös Haikala & Märijärvi (2002, 282), joiden mukaan ohjelmistotestaus
on systemaattista, ohjelmaa suorittamalla tapahtuvaa virheiden etsintää ohjelmasta tai sen osasta.
Testaaminen ei siis ole mitä tahansa kokeilua niin kuin arkikielessä usein testaamisella tarkoitetaan vaan tarkoituksena on toteuttaa systemaattinen ja suunnitelmallinen prosessi. Testauksella on
ohjelmistokehityksessä erityinen tehtävä, jossa pyrkimyksenä on löytää ohjelmassa olevia vikoja ja
puutteita. Määritelmän mukainen testaus perustuu ohjelmakoodin suorittamiseen, josta käytetään
myös termiä dynaaminen testaus. Dynaamisen testauksen lisäksi virheiden ja ongelmakohtien etsintää tehdään myös staattisilla testausmenetelmillä, jotka perustuvat ohjelmakoodin analysointiin
ja tarkastamiseen ilman, että ohjelmaa varsinaisesti käytetään.
Testauksen psykologia ja tavoitteet
Testaus nähdään usein toimenpiteenä, jonka tavoitteena on osoittaa, että ohjelma toimii oikein.
Myers (1979, 5) tuo vahvasti esiin testauksen psykologisen näkökulman. Ihmisen toimintaan vaikuttaa olennaisesti se, kuinka tavoitteet asetetaan. Jos testauksen tavoitteena on vahvistaa, että
ohjelma toteuttaa sille määritellyt tehtävät oikein, testaaja alkaa alitajuisesti toteuttaa testausta tavoitteensa mukaisesti. Tämä voi johtaa tilanteeseen, jossa testaaja välttää testitapauksia, jotka
tuovat esiin virheitä. Seurauksena on, että testauksen lisäarvo jää saavuttamatta.
Testauksen onnistumisen edellytyksenä on oikea asenne ja näkökulma testauksen tavoitteisiin.
Kun tavoitteena on löytää ohjelmassa olevia virheitä, testit todennäköisemmin myös löytävät niitä.
Kaner & al. (1999, 25) kiteyttää testauksen ydinajatuksen toteamalla, että onnistunut testi paljastaa
ongelman, kun taas testi, joka ei tuo esiin virheitä on hukkaan heitettyä aikaa.
Virheiden eliminointi ja aikainen testaus
Ohjelmat sisältävät virheitä. Jo pitkään käytössä olleissa ohjelmissakin arvioidaan olevan noin yksi
virhe tuhatta ohjelmariviä kohden (Haikala & Märijärvi 2002, 285). Tietoa tuotetaan, muunnetaan ja
5
siirretään kehitysprosessin vaiheiden läpi eri toimijoiden käyttöön, mikä on otollista maaperää virheiden syntymiselle. Suurin osa (jopa 80-85 %) ohjelmavioista saa alkunsa jo ohjelmistokehityksen
määrittely- ja suunnitteluvaiheessa (Kit 1995, 19). Mitä pitemmälle kehitystyö etenee sitä jyrkemmin virheiden etsinnästä ja erityisesti niiden korjauksesta aiheutuvat kustannukset kasvavat. Kaikkein kalleimmaksi tulevat virheet, jotka tulevat ilmi ohjelman julkaisun ja käyttöönoton jälkeen, jolloin kalliiden korjauskustannusten lisäksi voi aiheutua ikävää haittaa myös yrityksen imagolle.
Ohjelman täydellinen testaaminen ei ole mahdollista, eikä ohjelman virheettömyyttä pystytä testauksella osoittamaan. Aivan yksinkertaisia tapauksia lukuun ottamatta ohjelman kaikkien mahdollisten ohjelmapolkujen ja syötekombinaatioiden määrä on niin suuri, että niiden läpikäyminen testaamalla on mahdoton tehtävä (Kaner & al. 1999, 17). Testauksen ensisijaisena pyrkimyksenä onkin löytää mahdollisimman paljon virheitä mahdollisimman varhaisessa vaiheessa, jotta niiden korjaamisesta aiheutuva lisätyö voidaan minimoida. Virheiden aikainen havaitseminen estää niiden
siirtymisen ja ennaltaehkäisee uusien virheiden syntymistä. Testauksen hyöty saavutetaan, kun
löytyneet virheet korjataan ja sen myötä ohjelman luotettavuus ja laatu paranee.
Testaus osana laadunvarmistusta
Ohjelma tai järjestelmä joutuu testattavaksi aina kun sitä käytetään. Ohjelmistotestausta tarvitaan,
jotta tiedetään mitä käyttäjälle ollaan tarjoamassa ja kuinka hyvin ohjelman todellinen toiminta vastaa sitä mitä alun perin on lähdetty tekemään.
Laatu on käsite, jolla kuvataan tuotteen ja tuotantoprosessin ominaisuuksia ja onnistumista suhteessa asetettuihin tavoitteisiin. Korkealaatuinen ohjelmistotuote täyttää sille asetetut tekniset vaatimukset ja vastaa käyttäjän odotuksia ja tarpeita. Laadukkaan tuotantoprosessin tuloksena lopputuote valmistuu asetetun aikataulun ja budjetin mukaisesti. Prosessin vaiheiden ja vaihetuotteiden
seurannalla, arvioinnilla ja mittaamisella pyritään varmistamaan, että asetetut tavoitteet saavutetaan käytettävissä olevien resurssien puitteissa.
Termejä verifiointi ja validointi (suom. todentaminen ja kelpoistaminen; engl. verfication & validation) käytetään laadunvarmistuksen yhteydessä kuvaamaan menettelytapoja tuotteen ja tuotantoprosessin laadun arvioinnissa (Haikala & Märijärvi, 2002, 49). Verifioinnilla tarkoitetaan toimenpiteitä, joilla pyritään todentamaan, että tuote on tehty suunnitelmien mukaan ja toteuttaa sille määritellyt toiminnot oikein (”are we building the product right”). Validoinnilla puolestaan pyritään varmistamaan, että toteutettu ohjelmisto täyttää sille määritellyt vaatimukset (”are we building the right
product”).
Ohjelmistotuotannon näkökulmasta testaus on keskeinen osa ohjelmistoprojektin laadunvarmistusta, jonka avulla ohjelmiston ja tuotantoprosessin laatu saadaan näkyväksi. Testaus lisää luottamusta, että toteutettu tuote vastaa asetettuja tavoitteita ja vaatimuksia. Hyvin toteutettu testaus
6
auttaa hallitsemaan ohjelmistonkehitykseen liittyviä riskejä. Testausprosessista saatua tietoa voidaan käyttää apuna päätöksenteossa sekä hyödyntää tulevissa projekteissa ja testausprosessin
kehittämisessä. Laadunhallinnan kannalta on kuitenkin tärkeää huomioida, että ohjelmiston laatu
on kehitystyön tulos ja laatua rakennetaan koko ohjelmistokehityksen ajan. Testaus ei paranna laatua eikä testauksella voida korjata huonosti suunnitellun tai huonosti tehdyn työn tulosta. Testaus
todentaa ja vahvistaa olemassa olevan laadun. Mikäli ohjelmiston laatu on huono testauksen
alussa, laatu on huono myös testauksen lopussa (Pressmann 2005, 356).
Virheet, viat ja häiriöt
Standardi IEEE 610.12-1990 (IEEE Standard Glossary of Software Engineering Terminology) esittää termeille virhe, vika ja häiriö seuraavanlaiset määritelmät:
Mistake, error (virhe, erehdys) tarkoittaa virhettä, joka on seuraus ihmisen virheellisestä toiminnasta tai erehdyksestä. Inhimillinen virhe voi olla ohjelmointivirhe, virhe dokumentaatiossa tai dokumentaation tulkinnassa.
Fault, bug, error (virhe, vika) on ohjelmavirhe, joka on seuraus inhimillisestä virheestä. Ohjelmavika voi johtaa ohjelman toimintahäiriöön.
Failure (häiriö) on ohjelmavirheen seurauksesta aiheutuva toimintahäiriö, joka näkyy virheellisenä
tuloksena ohjelman suorituksessa.
Määritelmien mukaisesti ohjelmassa tai ohjelman dokumentaatiossa olevat virheet ovat seuraus
ihmisen virheellisestä toiminnasta tai erehdyksestä. Virheellisen kohdan suorittaminen voi aiheuttaa ohjelmavian, jonka seurauksena ohjelma ei toimi niin kuin pitäisi. Kaikki virheet eivät välttämättä johda ohjelman virheelliseen toimintaan. Virheen vaikutukset eivät aina myöskään tule käyttäjälle näkyviin, sillä vika voi peittyä tai kumoutua jonkin toiminnon tai toisen virheen seurauksena
(Haikala & Märijärvi 2002, 285). Toisaalta on myös tilanteita, joissa ohjelman toimintahäiriön syynä
on jokin ulkoinen tekijä esimerkiksi häiriö tietoliikenneverkossa, laitteiston vioittuminen, sähkökatkos tai järjestelmään päässyt haittaohjelma. Ohjelmavirheiden etsinnän lisäksi testauksella selvitetään myös järjestelmän toimintakykyä ja reagointia normaalista poikkeavissa tilanteissa.
Virheiden tunnistaminen ja luokittelu
Testauksen yhteydessä ohjelmavirhe todetaan poikkeamana spesifikaatiosta (Haikala & Märijärvi
2002, 285). Jotta tiedetään mitä etsitään, tyypillisten ja yleisesti esiintyvien virheiden
tunnistamiseksi on laadittu luokitteluja ja ns. tarkistuslistoja (checklists). Jo olemassa olevien
luokittelujen lisäksi uusia virheiden tarkistuslistoja muodostetaan aina tarpeen mukaan kutakin
ohjelmistoa ja sen testausta varten. Tarkistuslistaa voidaan hyödyntää sekä testien suunnittelussa
7
että testausta suoritettaessa esim. kooditarkastusten yhteydessä. Proseduuriin kuuluu, että
tarkistuslistaa täydennetään iteratiivisesti testausprosessin aikana.
Esimerkiksi Beizer (1990, 467-476) on laatinut kattavan taksonomian, jossa virheet on jaettu niiden
alkuperän mukaan kahdeksaan pääkategoriaan:
1. Vaatimusten määrittelyyn liittyvät virheet
2. Vaatimusten toteutukseen liittyvät virheet
3. Ohjelmakoodin rakenteelliset virheet
4. Tietorakenteiden ja tiedon määrittelyyn, toteutukseen ja käyttöön liittyvät virheet
5. Toteutukseen ja ohjelmointiin liittyvät virheet
6. Integraatioon liittyvät virheet
7. Järjestelmä- ja ohjelmistoarkkitehtuuriin liittyvät virheet
8. Testauksen määrittelyyn ja suorittamiseen liittyvät virheet
Virheiden luokittelun lisäksi Beizerin taksonomiassa on esitelty kuhunkin luokkaan kuuluvia virheitä
ja esitetty niistä havainnollisia esimerkkejä. Vastaavia virheiden luokitteluja ja tarkistuslistoja löytyy
runsaasti internetistä esim. hakusanoilla code checklists, code review checklists ja inspection
checklists ja niitä ovat laatineet myös mm. Myers (1979, 25-36) ja Kit (1995, 195-209).
Virheiden vakavuus ja vaikutukset
Ohjelmavirheen vakavuus riippuu virheen esiintyvyydestä, korjauskustannuksista ja virheen aiheuttamista seuraamuksista (Beizer 1990, 27). Pienten ja vähäisten virheiden vaikutukset ovat paikallisia ja ne ovat myös helppoja korjata esim. kirjoitusvirhe, huono asemointi, tarpeeton tai harhaanjohtava tuloste jne. Vakavien virheiden seuraukset eivät rajoitu yksittäisiin ja paikallisiin tapauksiin.
Ongelmat ovat usein kumuloituvia, jolloin sekä vaikutukset että kustannukset kertautuvat, leviävät
ja kasvavat. Pahimmassa tapauksessa kriittisen järjestelmän ongelma voi aiheuttaa vakavan uhan
ihmisten ja ympäristön turvallisuudelle.
Alla olevassa taulukossa on Beizerin (1990, 28-29) luokittelu virheen vakavuusasteesta 1-10 ja
esimerkkejä seuraamuksista, joita eri vakavuusasteen virheet voivat aiheuttaa.
Aste
Vakavuus
1
Vähäinen
2
Kohtalainen
Seuraus/oire

Kirjoitusvirhe tai huono asettelu tulosteessa

Kosmeettinen haitta

Harhaanjohtava tai tarpeeton tuloste

Suorituskyvyn aleneminen
8
3
Ärsyttävä
4
Häiritsevä
5
6
Vakava
Hyvin vakava

Hankalat komennot, vaikeasti ymmärrettävät tai turhat
toiminnot ja tulosteet

Esim. järjestelmä lähettää 0.00 Euron laskun

Sallittua transaktiota ei suoriteta

Esim. automaatti ei anna rahaa

Transaktio ei kirjaudu eikä siitä jää merkintää

Esim. tilin laskenta menee sekaisin

Järjestelmä suorittaa väärän transaktion

Esim. talletus muuntuu nostoksi
7
Erittäin vakava

Ongelmat eivät rajoitu yksittäisiin ja poikkeaviin tapahtumiin
vaan ovat toistuvia normaaliolosuhteissa esiintyviä häiriöitä
8
Sietämätön

Vääristynyttä dataa pitkältä ajanjaksolta, jota on vaikea
havaita ja palauttaa
9
Katastrofaalinen

Järjestelmä katuu
10
Infektoiva

Vika siirtyy ja tuhoaa muita järjestelmiä

Aiheuttaa peruuttamatonta ja jopa henkeä uhkaavaa
vahinkoa ympäristölle ja ihmisille
Virheenjäljitys
Testauksella havaittu vika paljastaa ongelman mutta ei useinkaan vian alkuperäistä syytä tai tarkkaa sijaintia. Testaajan tehtäviin kuuluu havaitun vian tai ongelman dokumentointi, jonka jälkeen
vastuu ongelmakohdan paikantamisesta ja korjaamisesta siirtyy ohjelman kehittäjille.
Virheenjäljitys (debugging) on kehitystyöhön liittyvä toimenpide, jonka tarkoituksena on jäljittää,
analysoida ja poistaa testauksella havaitut virheet. Virheiden paikantamista helpottaa merkittävästi
mitä aikaisemmin virhe havaitaan. Kun virhekohta löydetään, se korjataan ja ohjelma palautetaan
takaisin testaajien testattavaksi. Mikäli virheenjäljityksellä ei suoraan löydetä virhekohtaa, voidaan
sen avulla kuitenkin tehdä päätelmiä virheen todennäköisistä syistä ja mahdollisesta alkuperästä.
Tiedon perustella testaajat voivat kohdentaa lisätestausta epäiltyihin virhekohtiin. (Pressman 2005,
379-381).
9
Virheenjäljitystä tehdään ohjelmoinnin yhteydessä ohjelmoijan toimesta ja siihen tarkoitettu työkalu
sisältyy usein kehitysympäristöön (voidaan myös käyttää erillistä ohjelmaa). Virheenjäljittäjän (debugger) perusominaisuuksiin kuuluu, että ohjelman kulkua ja muuttujia voidaan seurata vaiheittain
esim. rivi tai funktiokutsu kerrallaan ja ohjelmaan voidaan tehdä hallitusti muutoksia. Esimerkiksi
ohjelmoijan tyypillinen manuaalinen ”debuggaus”-tapa, jossa ohjelman etenemistä seurataan ylimääräisillä tulostuksilla ohjelmakoodin seassa sisältää turhan riskin ylimääräisille virheille. Virheenjäljittäjä soveltuu erityisesti loogisten ohjelmavirheiden paikantamiseen. Useimpiin virheenjäljittäjiin
sisältyy myös hyödyllisiä kooditarkastustoimintoja kuten syntaksivirheiden etsintä, automaattinen
kooditäydennys ja koodimuotoilun asetustoiminto.
Luku 2 Testaus ohjelmiston elinkaaressa
Ohjelmiston elinkaari on aika, joka kuluu ohjelmiston kehittämisen aloittamisesta sen poistamiseen
käytöstä (Haikala & Märijärvi 2002, 36). Ohjelmiston elinkaari ja siihen sisältyvän työn jakaminen
vaiheisiin muodostaa ohjelmistokehityksen prosessimallin, jonka tunnetuin muoto ns. vesiputousmalli on esitetty kuvassa 1.
Kuva 1. Vesiputousmalli (Haikala & Märijärvi 2002, 36).
Vesiputousmallissa elinkaaren vaiheet esitetään peräkkäisinä askelmina mutta käytännössä ohjelmistokehitys ei koskaan etene suoraviivaisesti vaihe vaiheelta alusta loppuun vaan usein seuraava
vaihe aloitetaan ennen kuin edellinen vaihe on saatu päätökseen ja kertaalleen suoritettuihin vaiheisiin joudutaan palaamaan uudelleen prosessin aikana. Vesiputousmalli antaa kuitenkin perusmallin kehitystyön vaiheistamiseen ja sen pohjalta on kehitetty useita prosessimallityyppejä (protoilumalli, evo-malli, spiraalimalli, RUP, ketterät menetelmät jne.), joita voidaan soveltaa käytäntöön
kunkin ohjelmistoprojektin erityispiirteiden mukaan.
10
Riippumatta siitä, mitä ohjelmiston kehitysmallia käytetään, testaus on keskeinen osa ohjelmiston
elinkaarta. Seuraavassa kappaleessa esitetään testauksen V-malli, joka on yksi tapa kuvata testausprosessi ja siihen sisältyvät vaiheet ohjelmiston elinkaaressa.
V-malli ja testaustasot
V-malli on testauksen prosessimalli, joka jakaa testaustyön osavaiheisiin eli testaustasoihin. Testaustyön vaiheistaminen mahdollistaa tehokkaamman ja tarkemman testauksen, sillä eri testaustasoilla testausta voidaan kohdentaa erityyppisten ja eri kehitysvaiheille ominaisten virheiden etsintään. Kuvassa 2 on esitetty nelitasoinen V-malli, jonka testaustasot ovat moduulitestaus, integrointitestaus, järjestelmätestaus ja hyväksymistestaus. Käytännössä testaustasojen määrä vaihtelee
riippuen ohjelman elinkaarimallista ja ohjelmistoprojektin koosta ja luonteesta.
Kuva 2. Testauksen V-malli.
V-mallin mukaisesti testauksen suunnittelua tehdään vastaavalla tasolla ohjelmiston suunnittelun
kanssa. Suunnittelu aloitetaan mahdollisimman varhaisessa vaiheessa ja suunnittelua täydennetään ohjelmistoprosessin edetessä. Testauksen suunnittelu ja testaustulosten todentaminen perustuvat ohjelmistolle asetettuihin tavoitteisiin ja vaatimuksiin, jotka on määritelty ohjelmiston määrittely- ja suunnitteludokumentaatiossa.
Testauksen suorittaminen aloitetaan ohjelmointivaiheessa moduulitason testauksella. Moduulien
suunnittelu, ohjelmointi, testaus ja integrointi määritellään usein ohjelman toteutusvaiheeksi, jonka
aikaisesta testauksesta käytetään myös nimitystä alemman tason testaus. Alemman tason testausta tekevät tavallisesti ohjelman kehittäjät ja testauksen tavoitteena on ohjelmointi- ja suunnitteluvirheiden eliminointi. Ylemmän tason testauksella tarkoitetaan ohjelman toteutusvaiheen jälkeen
tapahtuvaa erillistä testausvaihetta, jonka suorittavat testaukseen erikoistuneet ammattilaiset.
Ylemmän tason testaukseen kuuluvat V-mallin järjestelmä- ja hyväksymistestaus. Järjestelmätestauksen tavoitteena on löytää ristiriidat ja virheet ohjelman todellisen toiminnan ja sille määriteltyjen
11
ohjelmistovaatimusten välillä. Hyväksymistestaus on testausprosessin viimeinen vaihe, jossa varmistetaan, että toteutettu järjestelmä vastaa tarkoitustaan eli niitä tavoitteita ja tarpeita, joita varten
järjestelmää on alun perin lähdetty tekemään.
Moduulitestaus
Moduuli- eli yksikkötestauksessa (module testing, unit testing) tarkastelun kohteena on ohjelman
pienin itsenäinen yksikkö eli moduuli/komponentti. Moduulin testaaja on yleensä moduulin tekijä eli
ohjelmoija ja tyypillisesti moduuli testataan välittömästi ohjelmoinnin jälkeen kehitysympäristöön
sisältyvillä yksikkötestauksen työkaluilla. Ohjelmarakenteen testaaminen moduuli kerrallaan parantaa testauksen hallittavuutta ja tehokkuutta. Ohjelman eri osia voidaan testata samanaikaisesti,
usean eri henkilön toimesta ja toisistaan riippumatta. Lisäksi virheen paikallistaminen tiettyyn moduuliin mahdollistaa ongelmakohdan eristämisen ja nopeuttaa virheen korjausta. (Myers 1979, 77).
Moduulin toteutusperiaatteesta johtuen moduulin toimintaa testataan kahdesta näkökulmasta: 1)
moduulin ulkoista toimintaa analysoimalla, missä selvitetään toteuttaako moduuli spesifikaation
mukaiset toiminnot ja 2) etsimällä virheitä ohjelmakoodin sisäisestä rakenteesta ja loogisesta toteutuksesta. Tyypillisiä testauksen kohteita ovat moduulin rajapintafunktiot, paikalliset tietorakenteet ja tiedon käyttö, loogiset ohjelmapolut, ohjausrakenteet, silmukat, virheidenkäsittely ja arvoalueiden rajakohdat (Pressman 2005, 363).
Ohjelmakoodin rakenteen ja loogisen toiminnan analysointiin käytetään ns. valkolaatikkotestauksen menetelmiä (ks. sivu 35, Valkolaatikkotestauksen menetelmät). Tavoitteena on kehittää joukko
testitapauksia, jotka testaavat ohjelmakoodin mahdollisimman kattavasti. Testitapausten suunnitteluun käytetään sekä ohjelman lähdekoodia että ohjelman toiminnan määrittelevää spesifikaatiota.
Valkolaatikkotestauksella saavutettua kattavuutta täydennetään moduulin toiminnallisella testauksella, jossa tapauskohtaisesti sovelletaan erilaisia mustalaatikkotestauksen menetelmiä (ks. sivu
38, Mustalaatikkotestauksen menetelmät).
Ohjelmamoduulien testaaminen voidaan aloittaa vaikka koko ohjelma ei olekaan valmis. Tällöin
testauksen suorittamiseksi tehdään ns. testipetejä (test bed). Testipeti sisältää testiajureita (test
driver), jotka simuloivat ohjelman ympäristöä (esim. testattavan moduulin funktioiden tai metodien
kutsuminen) ja tynkiä (stub), jotka korvaavat puuttuvia ohjelmakomponentteja, joita testattava moduuli tarvitsee suorituksen aikana. (Haikala & Märijärvi 2002, 287).
Integrointitestaus
Moduulitestausta seuraava taso on integraatiotestaus (integration testing), jossa arkkitehtuurisuunnitelman mukainen ohjelmarakenne kootaan ja samalla etsitään virheitä liitettyjen komponenttien
rajapinnoista. Testitapausten kehittäminen perustuu ohjelman arkkitehtuurin kuvaukseen ja mo-
12
duulien rajapintamäärittelyihin. Vaiheittaisessa integraatiossa uusi, yksikkötestattu komponentti lisätään aina jo aiemmin testattuun rakenteeseen. Vastakohtana vaiheittain etenevälle integraatiolle
on ns. kertarysäys (big-bang), jossa testatut komponentit liitetään kerralla yhteen.
Vaiheittaisessa menetelmässä uuden integraation testaaminen aiheuttaa aina myös kaikkien aiemmin integroitujen osien uudelleen testaamisen, jolloin testausta tehdään määrällisesti enemmän
sekä monipuolisemmin kuin kertarysäysmenetelmässä (Myers 1979, 91). Luonnollisesti myös virheiden etsintää, jäljitystä ja korjausta on huomattavasti helpompi tehdä, kun integrointi toteutetaan
komponentti kerrallaan. Kertarysäysmenetelmää voidaan hyödyntää esim. tilanteessa, jossa halutaan arvioida järjestelmän valmiutta integraatiotestaukseen tai tilanteessa, jossa järjestelmään
tehty muutos on pieni ja paikallinen (Kasurinen 2013, 55).
Vaiheittainen integraatio toteutetaan tavallisesti joko alhaalta ylöspäin tai ylhäältä alaspäin. Kokoava integrointi (bottom-up) aloitetaan komponenttihierarkiassa alimpana olevista, riippumattomista komponenteista. Riippumaton komponentti on päätekomponentti, josta ei kutsuta muita moduuleja. Komponentin integraatioon riittää ylemmän tason toimintaa simuloivan testiajurin kehittäminen. Integraatiojärjestyksestä johtuen kokoavassa integroinnissa ei tarvita testitynkiä. Komponenttien lisäysjärjestys voidaan muutoin valita vapaasti, kunhan alemman tason moduuli on testattu ennen sitä kutsuvaa ylemmän tason moduulia. Alhaalta ylöspäin etenevässä integraatiossa
toimiva ohjelma on valmis vasta, kun viimeisinkin komponentti on lisätty ohjelmaan.
Kuva 3. Kokoava integrointi (Bottom-up)
13
Päinvastainen vaiheittaisen integraation lähestymistapa on osittava integrointi (top-down), jossa
integroimissuunta on ylhäältä alaspäin ja lähtöpisteenä on ylin tai keskeisin komponentti esim. pääohjelma. Testattavaa komponenttia varten toteutetaan tarvittavista alemman tason komponenteista
testityngät. Testitynkien kehittäminen aloitetaan jo moduulivaiheessa ja usein moduulitestaus ja
integrointitestaus etenevät rinnakkain. Testauksen edetessä testityngät korvautuvat valmiilla, testatuilla komponenteilla kunnes ohjelman integraatio on valmis.
Ylhäältä alaspäin etenevässä integraatiossa on useita vaihtoehtoisia etenemispolkuja ja ohjelmasta voidaan jo aikaisessa vaiheessa rakentaa toimiva ns. luurankoversio. Menetelmän haasteena on toteuttaa yksinkertaisia testitynkiä, jotka simuloivat lopullisia toteutuksia oikein. Yhdestä
testityngästä voidaan joutua tekemään useita eri versioita, jotta kaikki testitapaukset saadaan testatuksi. Työläs menetelmä houkuttelee myös jättämään osan testitapauksista odottamaan alempien komponenttien valmistumista, jolloin riskinä on niiden unohtuminen ja testauksen jääminen
vaillinaiseksi. Testityngät ovat aina myös mahdollisia virheiden lähteitä, joten ohjelmakomponenttien lisäksi myös sijaiskomponentit tulee testata ennen käyttöönottoa.
Kuva 4. Osittava integrointi (Top-down)
Integraation toteutustapa valitaan aina tapauskohtaisesti. Hyvä lähestymistapa on integroida ohjelman kriittiset ja virhealttiit osat mahdollisimman aikaisessa vaiheessa. Tällaisia ovat esim. uudet
algoritmit, monimutkaiset moduulit ja syöte- ja tulostustoimintoja sisältävät moduulit. Jos ohjelman
kriittiset osat ovat enemmän painottuneet komponenttihierarkian alemmille tasoille, on järkevää
aloittaa integroiminen alhaalta ylöspäin. Alhaalta ylöspäin edetessä testitapausten toteuttaminen
14
on usein myös yksinkertaisempaa ja helpompaa. Ylhäältä alaspäin integroitaessa etuna on, että
ohjelman lopullista toimintaa voidaan demonstroida jo varhaisessa vaiheessa ja hyödyntää esim.
käytettävyyden testaamisessa. (Myers 1979, 95-100).
Edellä kuvattu itsenäisten ohjelmakomponenttien integraatio kuuluu alemman tason testaukseen.
Vaiheittaista integraatiota käytetään myös järjestelmätason integroinnissa esimerkiksi, kun itsenäisiä ohjelmia liitetään yhteen, alijärjestelmistä kootaan yhdessä toimiva ylemmän tason järjestelmä
tai paikallisista järjestelmistä muodostetaan verkon yli kommunikoivia hajautettuja järjestelmiä.
Top-down ja bottom-up eivät myöskään ole ainoita integraation toteutustapoja. Esimerkiksi voileipä- eli sandwich-integraatio on kokoavan ja jäsentävän tavan yhdistelmä, jossa integrointia lähdetään toteuttamaan yhtä aikaa molemmista päistä. Menetelmä tehostaa integraatiota mutta sen
hallinta on huomattavasti haasteellisempaa.
Järjestelmätestaus
Järjestelmätestaus (system testing) suoritetaan testiympäristössä ohjelmistolle, jossa ei ole enää
sijaiskomponentteja. Testauksessa järjestelmää tarkastellaan kokonaisuutena ja tapauskohtaisesti
sovelletaan erilaisia korkean tason testausmenetelmiä. Objektiivisuuden säilyttämiseksi järjestelmätestauksen toteuttajina ovat kehitystiimin ulkopuoliset testaajat, jotka voivat olla kehittäjäyrityksen työntekijöitä tai ulkopuolisia, testaukseen erikoistuneita ammattilaisia.
Järjestelmätestauksen tavoitteena on selvittää täyttääkö järjestelmä sille asetetut tavoitteet ja esiintyykö järjestelmän/ohjelman ja sen määrittelyn välillä ristiriitoja. Ohjelmalle asetettujen toiminnallisten tavoitteiden lisäksi järjestelmätestauksessa tarkastellaan ei-toiminnallisia vaatimuksia kuten
suorituskykyä, käytettävyyttä, tietoturvaa ja luotettavuutta. Testaustyypistä riippuen järjestelmän
laadullisia ominaisuuksia tarkastellaan ns. normaaliolosuhteissa ja normaalista poikkeavissa kuormitustilanteissa. Järjestelmätason testausta tehdään erityisesti ohjelmistotuotteille, jotka toteutetaan sopimusperusteisesti tai laajan asiakaskunnan käyttöön. Pienten ohjelmien kuten kokeellisten
tai ohjelmoijan omaan käyttöön tarkoitettujen ohjelmien testauksessa riittää usein ohjelman toiminnallisuuden testaaminen (Myers 1979, 106).
Toiminnallinen testaus
Ohjelman toiminnallisen testauksen (functional testing, function testing) tarkoituksena on löytää
ristiriitaisuudet ohjelman ulkoisen toiminnan ja toiminnallisen määrittelyn välillä. Toiminnallinen
määrittely on spesifikaatio, jossa jokainen ohjelman toiminto on kuvattu yksityiskohtaisesti käyttäjän
näkökulmasta. Myös toimintojen testaus suoritetaan järjestelmän ulkoista eli käyttäjälle näkyvää
käyttäytymistä
analysoimalla.
Testitapausten
suunnittelussa
hyödynnetään
pääasiallisesti
mustalaatikkotestauksen menetelmiä. Esimerkiksi ekvivalenssiositus, raja-arvoanalyysi, syyseuraus-mallinnus ja virheenarvaus ovat tyypillisiä toiminnalliseen testaukseen sovellettuja
tekniikoita (Myers 1979, 108). Toiminnallinen testaus voidaan aloittaa heti, kun toimintoja on valmiina
15
suoritettavaksi tai sitten, kun yksikkö- ja integraatiotestaus on saatu päätökseen. Toiminnallinen
testaus sijoitetaankin usein omaksi vaiheeksi ennen varsinaista järjestelmätestausta (Myers ym.
2012, 117; Kit 1995, 98-99).
Käytettävyystestaus
Käytettävyydeltään hyvä ohjelma on tehty käyttäjän tarpeisiin, mikä tarkoittaa, että ohjelma
sovitetaan käyttäjän toimintatapoihin eikä päinvastoin (Kit 1995, 96). Käytettävyystestauksessa
(usability testing) pyritään löytämään järjestelmän toiminnot ja käyttötilanteet, jotka ovat hankalia tai
vaikeaselkoisia käyttäjille. Käytettävyyden vaatimukset toteutetaan käyttöliittymässä. Käytännössä
käytettävyystestaus painottuukin juuri käyttöliittymän toimivuuden ja tarkoituksenmukaisuuden
analysointiin (Kasurinen 2013, 70).
Käytettävyyden testausta voidaan suorittaa kaikissa ohjelmistokehityksen vaiheissa ja erilaisia
menetelmiä sovelletaan ohjelmiston valmiusasteen mukaisesti. Tavallinen tapa on järjestää
koetilanne, jossa käyttäjä kertoo ääneen ajattelemalla, mihin hänen toimintansa käyttötilanteessa
perustuu. Tarkempaa analysointia varten koetilanne myös taltioidaan. Ongelmia paljastavasta
käytettävyystauksesta on sitä enemmän hyötyä, mitä aikaisemmin sen tuloksia saadaan.
Esimerkiksi ns. pikatestit käyttöliittymän näköiskuvilla ilman toiminnallisuutta mahdollistavat
käytettävyystestauksen jo käyttöliittymän suunnitteluvaiheessa.
Luotettavuustestaus
Luotettavuustestaus (reliability testing) perustuu ohjelmassa esiintyvien vikojen ja häiriöiden mittaamiseen ja tilastolliseen analyysiin. Järjestelmän luotettavuustason arvioinnissa kiinnitetään huomiota mm. häiriöiden esiintymistiheyteen ja vakavuuteen. Lisäksi voidaan kerätä tietoa vikojen korjaamiseen käytetystä ajasta. Testausprosessin aikana kerättyjen tietojen perusteella voidaan todentaa milloin ohjelmiston luotettavuus (ohjelman häiriötön toiminta tietyssä ympäristössä tietyn
ajanjakson aikana) vastaa vaatimusmäärittelyssä asetettuja tavoitteita. Luotettavuudelle määriteltyä tavoitetasoa voidaan käyttää myös testauksen lopetuskriteereinä esim. tuotantoon julkaisua
varten. (Kit 1995, 159).
Tietoturvatestaus
Tietoturvatestauksella (security testing) selvitetään järjestelmään toteutettujen tietoturvatoimintojen
(palomuuri, tiedon salaus ja käyttöoikeudet) kykyä torjua väärinkäytöksiä ja uhkia, jotka tulevat järjestelmän ulkopuolelta (virukset, haittaohjelmat tai asiattomat käyttäjät). Tietoturvatestauksella pyritään löytämään järjestelmässä olevia heikkoja kohtia ja haavoittuvuuksia, jotka aiheuttavat tietoturva-aukkoja järjestelmään. Testeillä voidaan simuloida hyökkäyksiä, jotka kohdistuvat havaittuihin tai mahdollisiin tietoturva-aukkoihin. Tietoturvaan liittyviä ongelmia voi syntyä missä ohjelmistonkehitysvaiheessa tahansa, joten myös tietoturvatestausta tulisi tehdä kaikilla testauksen tasoilla.
16
Tietoturvan ylläpito ja testaus ovat keskeisiä toimintoja myös ohjelmiston käyttöönoton jälkeen.
(Pressman 2005, 377).
Toipuvuustestaus
Toipuvuustestaus (recovery testing) on järjestelmätestauksen muoto, jossa testataan järjestelmän
kykyä toipua erilaisista häiriötilanteista. Toipuvuustestaus voi liittyä myös tietoturvatestaukseen,
jossa järjestelmä kaatuu ulkopuolisen hyökkäyksen seurauksena. Toipuvuustestaukseen sisältyy
häiriötilannetestausta, jossa arvioidaan järjestelmän toimintakykyä poikkeustilanteissa sekä toipumismenettelyjen testausta, jossa arvioidaan järjestelmän kykyä palautua häiriötilanteesta ns. normaalitilaan. (Pressman 2005, 377).
Suorituskykytestaus
Monilla sovelluksilla on erityisiä suorituskykyyn ja tehokkuuteen liittyviä vaatimuksia kuten vastausaika, välityskyky, saatavuus ja resurssien käyttöaste (muisti, CPU), joilla mitataan järjestelmän kykyä suoriutua sille määritellyistä tehtävistä.
Suorituskykytestauksen (performance testing) tavoitteena on testata vastaako järjestelmän toiminta asetettuja suorituskykyvaatimuksia ja löytyykö järjestelmästä ns. pullonkauloja, jotka heikentävät järjestelmän toimintaa kokonaisuutena. Suorituskykytestausta voidaan tehdä kaikilla testaustasoilla (yksittäisille komponenteille, integraation yhteydessä ja järjestelmätasolla) riippuen toteutettavasta ohjelmasta/järjestelmästä ja sille asetetuista suorituskykyvaatimuksista.
Suorituskykytestausta varten määritellään kuormitustaso ja laite- ja ohjelmistokonfiguraatio, joilla
testausta suoritetaan sekä suorituskyvyn tavoitetaso, johon tuloksia verrataan. Suorituskykytestaukseen on olemassa erityisiä ohjelmallisia työkaluja, joilla voidaan simuloida käyttötilanteita ja mitata haluttuja ominaisuuksia dynaamisesti ohjelman suorituksen aikana (ks. Luku 5 Testauksen
työkalut). Järjestelmän suorituskykyä voidaan arvioida myös käyttäjän subjektiivisen kokemuksen
perusteella eli kuinka järjestelmä käyttäjän mielestä suoriutuu sille määrätyistä tehtävistä (Pressman 2005, 378)
Kuormitustestaus ja stressitestaus
Kuormitustestauksella tutkitaan järjestelmän käyttäytymistä erilaisilla kuormituksilla esim. samanaikaisten käyttäjien määrä (load testing) tai käsiteltävän tiedon määrä (volume testing). Kuormitustestauksella pyritään myös selvittämään maksimitaso kuormitukselle, jonka järjestelmä kestää kaatumatta.
17
Stressi- eli rasitustestauksella (stress testing) tutkitaan kuormitushuippuja, joissa järjestelmä joutuu
äärirajoille ja selvitetään kuinka järjestelmä niihin reagoi. Rasitustestauksella voidaan myös selvittää yläraja rasitukselle, jonka ylittyessä järjestelmä ei enää kykene suoriutumaan tehtävistään vaatimusten mukaisesti esim. samanaikaisten käyttäjien maksimimäärä, yhtäaikaiset tietokantatransaktiot, palvelimelle tehtävien pyyntöjen tiheys jne. Kuormitus- ja stressitestauksessa käytetään tavallisesti apuna simulaattoreita, joilla voidaan luoda virtuaalisia käyttäjiä ja simuloida yhtäaikaisia tapahtumia. (Myers 1979, 113; Kasurinen 2013, 71-72)
Muita tärkeitä järjestelmätestauksen muotoja ovat:

Yhteensopivuustestaus (compatibility testing), jossa selvitetään ohjelman/järjestelmän yhteensopivuutta laiteympäristön, käyttöjärjestelmän, tietokannan ja muiden ohjelmistojen
kanssa esim. selaimet.

Asennettavuus- ja asennustestaus (installability/installation testing), joissa varmistetaan ohjelmiston asennettavuus.

Käyttäjädokumentaation (user documentation testing) testaus, jolla varmistetaan sekä käyttöohjeiden että ohjelmiston käytettävyyden laatu.
Näillä kaikilla pyritään varmistamaan, että järjestelmä on valmis siirrettäväksi lopulliseen käyttöympäristöön, jossa suoritetaan testauksen viimeinen vaihe eli virallinen hyväksymistestaus. (Myers
1979, 116-117; Kit 1995, 128).
Hyväksymistestaus
Hyväksymistestauksella (acceptance testing) todennetaan kuinka hyvin lopputuote vastaa
tarkoitustaan eli niitä tarpeita ja odotuksia, joita asiakas- ja käyttäjävaatimusten määrittelyssä
asetettu. Jos kyseessä on sopimusasiakkuus, hyväksymistestauksella myös varmistetaan, että
asiakkaalle luovutettava ohjelmisto täyttää ne tavoitteet, joita sopimukseen on kirjattu.
Asiakasprojekteissa virallinen hyväksymistestaus tehdään tavallisesti asiakkaan toimesta. Testaus
voidaan toteuttaa pitempänä ajanjaksona ja usean testin sarjana, jolloin virheiden kumuloituvat
vaikutukset
voidaan
paremmin
havaita
(Pressman
2005,
375).
Hyväksymistestauksen
lopputuloksena vahvistetaan virallisesti, että tuote siirtyy asiakkaan omaisuudeksi ja ohjelmiston
kehitystyö päättyy.
Alfa- ja beta-testaus
Laajalle asiakaskunnalle suunnattujen ”off-the-shelf” -ohjelmistotuotteiden kohdalla käytetään alfaja beta-testauksena tunnettua hyväksymistestauksen muotoa, jossa valitaan rajattu joukko
18
asiakkaita ja/tai loppukäyttäjiä testaamaan tuotetta. Prosessissa löytyvät virheet ovat tyypillisesti sen
kaltaisia, joita erityisesti loppukäyttäjät ovat hyviä havaitsemaan (Pressman 2005, 375).
Alfa-testaus tehdään yleensä ohjelman toimittajan tiloissa, jolloin kehittäjillä on mahdollisuus seurata
ja kontrolloida testauksen suoritusta. Beta-testauksessa valitut asiakaskunnan edustajat testaavat
ohjelmaa omissa tiloissaan itsenäisesti ja raportoivat havaitsemistaan ongelmista ohjelman
kehittäjille.
Alfa- ja beta-testauksen tavoitteena on varmistaa, että valmis ohjelmaversio täyttää potentiaalisen
asiakaskunnan odotukset. Pyrkimyksenä on kehittää kaupallisesti kannattava tuote, joten
testaustulosten perusteella tuotteeseen voidaan tehdä isojakin muutoksia ennen virallista julkaisua.
Ylläpito- ja uudelleentestaus
Kun ohjelmaan tai järjestelmään tehdään mikä tahansa muutos, tulee uusi versio testata.
Uudelleentestaus eli regressiotestaus on jatkuva prosessi, jonka tarkoituksena on varmistaa, että
tehtyjen muutosten tai korjaustoimenpiteiden jälkeen aiemmin havaittuja virheitä ei enää esiinny ja
että muutokset eivät ole aiheuttaneet uusia virheitä. (Pressman 2005, 369).
Uudelleentestausta kohdennetaan muutoskohtien lisäksi valikoidusti myös muutosten ulkopuolisille
alueille. Muutosten vaikutusten arviointia voidaan käyttää perusteena testitapausten valinnassa.
Uudelleentestaus voi tulla erittäin kalliiksi, joten siinä pyritään hyödyntämään mahdollisimman paljon
automatisointia.
testitapausten
Esimerkkejä
ja
testidatan
testaustyökalujen
automaattinen
automatisoiduista
generointi,
toiminnoista
testitapausten
ovat
mm.
nauhoittaminen
ja
automaattinen toistaminen sekä testitulosten automaattinen kirjaaminen ja vertaaminen odotettuihin
lopputuloksiin. (Haikala & Märijärvi 2002, 294-295).
Ylläpitotestauksella tarkoitetaan muutostestausta, jota tehdään ohjelman käyttöönoton jälkeen.
Esimerkkejä ylläpitotestauksesta ovat mm. uuden päivitetyn ohjelmaversion testaaminen ennen
julkaisua, korjattujen vikojen seurauksena tehtävä uudelleentestaus, muunnos- eli konversiotestaus
(esim. järjestelmä siirretään uudelle alustalle) tai testaus tilanteessa, kun järjestelmää ollaan
poistamassa käytöstä.
Luku 3 Testausprosessi ja sen hallinta
Testausprosessin vaiheet ovat testauksen suunnittelu, testauksen suorittaminen, tulosten tarkastelu
ja testausprosessin päättäminen (Haikala & Märijärvi 2002, 281). Testausprosessin onnistunut
läpivienti perustuu samoihin elementteihin kuin minkä tahansa hyvin hallitun projektityön. Niihin
kuuluvat mm.

hyvin organisoitu ja johdettu testaustiimi
19

ammattitaitoiset tekijät

työn jakaminen helpommin hallittaviin osavaiheisiin

työn suunnittelu ja tarvittavien resurssien määrittäminen

työtä helpottavien käytäntöjen, menetelmien ja välineiden omaksuminen ja käyttöönotto

projektin seuranta ja riskien hallinta
Katselmoinnit, arvioinnit ja testaustoiminnan mittaaminen ovat konkreettisia käytännön toimia, joilla
prosessin eteneminen tehdään näkyväksi ja varmistetaan testaustyön laatu.
Testaustyön roolit ja tehtävänjako
Testausta tehdään tiimityönä ja siinä tarvitaan erilaisia osaajia. Testaustiimin koko vaihtelee testattavan kohteen ja projektin koon mukaisesti mutta pienenkin projektin kohdalla työtehtävien ja vastuiden jakaminen mahdollistavat hallitun ja tehokkaan työskentelyn. Testaustiimi toimii myös tiiviissä yhteistyössä ohjelman kehittäjien kanssa. Testauksen organisointi, roolit ja vastuut määritellään testaussuunnitelmassa, jonka mukaisesti työtehtäviä jaetaan. Tyypillisesti testaustiimin vetäjänä toimii testauspäällikkö, jonka vastuulla on testauksenhallintaan liittyvät tehtävät kuten testaussuunnitelman laatiminen, tarvittavien resurssien määrittely ja hankkiminen, prosessin etenemisen
seuranta ja ohjaus sekä testaustulosten arviointi ja loppuraportin laatiminen. Varsinaisen testaustyön tekevät testaajat, jotka suunnittelevat, suorittavat ja dokumentoivat testit. Testaajien tehtäviin
kuuluu myös havaittujen poikkeamien analysoiminen ja raportointi. Lisäksi testaajat voivat toimia
testausprosessissa tuotettujen dokumenttien tarkastajina ja katselmoijina. Testaustiimin muut roolit
määräytyvät työtehtävien mukaan. Osa tehtävistä vaatii erityisasiantuntemusta, jolloin vastuuhenkilön tehtävänä voi olla pelkästään esim. testiympäristön rakentaminen, työkalujen asentaminen ja
ylläpito, testauksen automatisointi, testitulosten analysointi jne.
Testauksen organisoinnissa pyritään testauksen riippumattomuuteen ja testaustiimin itsenäisyyteen (Kit 1995, 174). Alemman tason testausta tekevät usein ohjelman kehittäjät. Isot ja vaativat
projektit toteutetaan usealla testaustasolla, jolloin vastuut voidaan jakaa eri tahoille. Ylemmän tason testaus voidaan esimerkiksi ulkoistaa osittain tai kokonaan kehitysorganisaation ulkopuolisille
testaukseen erikoistuneille ammattilaisille.
Testauksen suunnittelu
Testauksen suunnittelu aloitetaan mahdollisimman varhaisessa vaiheessa yhdessä ohjelmiston
suunnittelun kanssa. Testauksen suunnittelun tavoitteena on liittää testaus osaksi hyvin suunniteltua
ja onnistuneesti etenevää ohjelmistoprojektia. Resurssit ovat usein rajalliset, joten testauksessa
joudutaan tekemään valintoja kuinka paljon ja kuinka kattavasti testejä suoritetaan. Hyvä suunnittelu
20
ohjaa miten testausprosessia viedään hallitusti eteenpäin ja auttaa hyödyntämään rajalliset resurssit
mahdollisimman tehokkaasti.
Testausstrategia
Testausstrategiassa linjataan lähestymistapa miten testausta lähdetään toteuttamaan ja millä ehdoilla prosessissa edetään. Strategian määrittely voi olla erillinen dokumentti tai se voi sisältyä testaussuunnitelmaan.
Testausstrategiassa määriteltäviä asioita ovat mm.

testauksen prosessimalli (esim. V-malli)

testauksen organisaatio (projektin johto, testaustiimin riippumattomuus esim. osallistuuko
kehittäjät testaukseen, muodostetaanko testaustiimi kehitysorganisaation sisällä, käytetäänkö ulkopuolisia asiantuntijoita vai ulkoistetaanko testaus kokonaan)

testaustyöhön liittyvät käytännöt ja standardit (dokumentointi, projektin hallinta, laadunvarmistus)

vastuut päätöksenteossa ja poikkeustilanteissa

testaukselle asetettavat kriteerit eli milloin testaus voidaan aloittaa, mitkä ovat ehdot testauksen keskeyttämiselle ja jatkamiselle ja milloin testaus lopetetaan.
Testaussuunnitelma
Testaussuunnitelma on dokumentti, jossa kuvataan yksityiskohtaisesti testauksen vaiheet eli mitä
testataan, miten testaus suoritetaan ja mitä tuotoksia testaustyössä tuotetaan (Liitteet 1 ja 2
sisältävät
dokumenttipohjat
ylemmän
tason
testaussuunnitelmasta
ja
vaihekohtaisesta
testaustasojen suunnittelusta). Testaussuunnitelman laajuus riippuu testattavasta ohjelmistosta,
testaukselle
asetetuista
tavoitteista
sekä
testausta
suorittavien
tahojen
käytännöistä.
Testaussuunnitelman pohjana voidaan käyttää olemassa olevia standardeja ja suosituksia (esim.
ISO/IEC 29119, SPACE DIRT, IEEE 829), jotka sisältävät perusteellisen ja monitasoisen kuvauksen
testausprosessista ja siihen liittyvistä tehtävistä. Käytännössä testaussuunnitelma tehdään aina
projektikohtaisesti, jolloin suunnitelman sisältö ja laajuus määräytyy kunkin projektin erityispiirteiden
mukaisesti.
Testaussuunnitelman perussisältö määrittelee mm. seuraavia asioita:

dokumentin tarkoituksen ja tavoitteet

testauksen kohteen eli testattavan ohjelmiston kuvaus pääpiirteittäin ja projektin tavoitteet
21

testausympäristön eli millainen järjestelmä testausta varten tarvitaan ja kenen vastuulla sen
rakentaminen ja ylläpito on

henkilöstön osaamisvaatimukset ja koulutustarpeet

testausstrategian, jos sitä ei ole erillisenä dokumenttina (tai viittaus strategian määrittelyyn,
jota käytetään)

testauksen laajuuden eli mitä ohjelmasta testataan, mitä ei testata ja mitä rajoitteita testaukseen liittyy

testauksen aikataulun ja työmääräarvion mm. deadline-päivämäärät, katselmoinnit, ja välitavoitteet

testauksen tuotokset, joita ovat suunnitteludokumentaatio, yksikkötestit, testiajurit, sijaiskomponentit, testiloki, virheraportit ja testauksen väliraportit ja loppuraportti

testausprojektiin liittyvät riskit sekä menettelytavat, joilla niihin varaudutaan

testauksen kriteerit eli ehdot testauksen aloittamiselle, keskeyttämiselle, jatkamiselle ja lopettamiselle
Testaussuunnitelmaa tarkennetaan vaihekohtaisella suunnittelulla, jossa määritellään kuhunkin
testaustasoon liittyvät ehdot ja tavoitteet. Suunnittelun lähdemateriaalina käytetään ohjelmiston
määrittely- ja suunnitteluspesifikaatioita, joissa ohjelman toiminnalliset ja laadulliset vaatimukset on
määritelty.
Ohjelmistovaatimuksista johdetaan kutakin tasoa vastaavat testauksen tavoitteet seuraavasti:

Asiakas- ja käyttäjävaatimukset → Hyväksymistestaus

Järjestelmän toiminnalliset ja ei-toiminnalliset vaatimukset → Järjestelmätestaus

Järjestelmän arkkitehtuuri ja moduulien rajapintamäärittelyt → Integrointitestaus

Moduulien toiminnalliset ja ei-toiminnalliset vaatimukset → Moduulitestaus
Lähdemateriaalin saatavuus ja laatu vaikuttavat ohjelman testattavuuteen. Testauksen aloitusehdoksi voidaankin mm. määritellä, että tarvittava lähdedokumentaatio on tarkastettu ja saatavilla.
Mikäli dokumentaatiota ei ole tai se on puutteellinen, tarvittavia tietoja täydennetään esim. yhteistyössä ohjelman kehittäjien kanssa.
22
Testauksen kohdentaminen ja priorisointi
Testauksen suunnittelun suurin haaste on, että testattavaa on paljon enemmän kuin mitä käytännössä pystytään tekemään. Testaussuunnitelman keskeinen osa on määritellä mitä osia ohjelmasta testataan ja mitä ei testata. Testauksen kohdentamista ja priorisointia voidaan tehdä useasta eri näkökulmasta riippuen millaisesta ohjelmasta tai järjestelmästä on kysymys.
Suunnitelmalähtöisessä testauksessa pyritään varmistamaan ohjelmistotuotteen korkea laatutaso
testaamalla ohjelma mahdollisimman perusteellisesti (Kasurinen 2013, 122). Perusteellisen testauksen edellytyksenä on, että aikaa ja rahaa on riittävästi käytettävissä. Onnistunut testaus edellyttää testausprosessin hyvää hallintaa ja ammattitaitoista testaushenkilöstöä.
Riskiperusteisessa lähestymistavassa testattavat ohjelmanosat luokitellaan riskianalyysin perusteella tärkeysjärjestykseen, jonka mukaisesti työpanoksia kohdistetaan. Testaus voidaan aloittaa
ohjelman keskeisimmistä osista ja edetä kohti vähemmän tärkeitä yksityiskohtia, jolloin voidaan
varmistaa, että ainakin kaikki tärkeimmät toiminnot tulevat kunnolla testatuksi (Kasurinen 2013,
123). Testauksen priorisoinnissa voidaan myös arvioida mikä on testien kehityksestä aiheutuvien
kustannusten suhde riskiin, jos testit jätetään kehittämättä (Kit 1995, 26-28).
Testauksen kohdentaminen voi perustua myös analyysiin ohjelmanosien virhealttiudesta ja käyttöasteesta. Ohjelmallisilla koodianalysaattoreilla voidaan mitata ohjelman suorituksenaikaisia tiloja ja
tapahtumia sekä analysoida ohjelman rakenteen monimutkaisuutta ja loogista kompleksisuutta.
Analyysin perusteella testausta voidaan kohdentaa erityisesti niihin ohjelman osiin, jotka todennäköisemmin sisältävät virheitä. (Kit 1995, 26-27).
Virhealttiiden ohjelmanosien tunnistamisessa voidaan hyödyntää myös tietoa tyypillisistä ja usein
esiintyvistä ohjelmavirheistä sekä tilanteista, joissa virheitä helposti tehdään. Virheiden todennäköisyyttä lisääviä tekijöitä ovat esimerkiksi ohjelmaan tehdyt muutokset, viime hetken korjaukset, uusi
koodi, ulkopuolelta tuotu koodi, uusi teknologia, uudet työntekijät, kokematon ohjelmoija, kiire, paineen alla työskentely jne. (Kasurinen 2013, 119-120).
Testitapausten suunnittelu
Testauksen suunnittelun viimeisessä vaiheessa valitaan ja suunnitellaan suoritettavat testitapaukset. Testitapausten suunnittelussa keskeistä on turhien, päällekkäisten ja kertakäyttöisten testien
välttäminen. Testitapausten valinnassa pyritään löytämään kaikkien mahdollisten testitapausten
joukosta ne, joilla on suurin todennäköisyys löytää virheitä (Myers 1979, 36). Testitapausten suunnittelutekniikat (ks. Luku 4 Testaustekniikat) ovat systemaattisia menetelmiä, joiden avulla testien
määrää voidaan järkevällä tavalla rajata.
23
Testitapauksen määrittely
Testitapaus (test case) on kuvaus toimenpiteistä ja ehdoista, jotka suorittamalla voidaan testata
haluttua ohjelman osaa, toimintoa, ominaisuutta tai tapahtumaa. Tarkoituksena on, että yksi testitapaus testaa vain yhtä asiaa tietystä näkökulmasta. Testitapauksen määrittelyssä pyritään kuvamaan mahdollisimman tarkasti ja yksiselitteisesti testisyötteet, tarvittavat askeleet testin suorittamiseksi sekä odotettu lopputulos, johon testin tulosta verrataan. Testitapaus liittyy aina tiettyyn
vaatimukseen tai toimintoon ja sillä voi olla riippuvuuksia, jotka vaikuttavat testin suorittamiseen.
Testitapausten dokumentoinnissa tuleekin huomioida, että määrittelystä löytyy viittaus vaatimukseen, josta testitapaus on johdettu (ns. kaksisuuntainen jäljitettävyys) sekä esiehdot testin suorittamiseen mikäli niitä on.
Testitapauksen määrittely sisältää mm. seuraavia tietoja:

Yksilöllinen tunniste

Testijoukon tunniste (mikäli sellainen on)

Sanallinen kuvaus mitä testitapauksella testataan

Testausympäristö, jossa testitapaus suoritetaan

Viittaus vaatimukseen tai toimintoon, johon testitapaus liittyy

Esiehdot testitapauksen suorittamiselle esim. riippuvuudet muihin testitapauksiin

Testitapauksen odotettu tulos

Testitapauksen todellinen tulos, joka kirjataan testin suorittamisen jälkeen

Testitapauksen lopputulos (hyväksytty/hylätty)

Lisätietoja esim. jos testin suoritus epäonnistuu

Testitapauksen luomispäivämäärä ja suunnittelija

Testin suorituspäivämäärä ja suorittaja
Liite 3 sisältää mallin testitapauksen määrittelydokumentista.
Testauksen toteuttaminen
Testaus toteutetaan testaussuunnitelmassa määriteltyjen vaiheiden eli testaustasojen mukaisesti.
Ennen testauksen aloittamista voidaan suorittaa katselmointi, jossa laaditut testaussuunnitelmat
24
tarkastetaan. Testaustyön valmisteluun kuuluu myös testiympäristön rakentaminen ja kunkin testaustason mukaisen testiproseduurin määrittäminen, jossa tarkennetaan mitä ja missä järjestyksessä testitapauksia suoritetaan.
Vaihekohtainen testaus
Testauksen toteutus aloitetaan ohjelmointivaiheessa ohjelmamoduulien testaamisella. Moduulitestaus tehdään kehitysympäristöön kuuluvilla tai erillisillä yksikkötestaukseen tarkoitetuilla työkaluilla
(ks. luku 5 Testauksen työkalut). Yksittäisen moduulin testaa tavallisesti moduulin tekijä ja löytyneet virheet korjataan välittömästi testien suorittamisen jälkeen ilman muodollisia raportointimenettelyjä. Moduulitestaukseen kuuluu myös testipetien eli tarvittavien testiajureiden ja sijaiskomponenttien kehittäminen.
Integrointitestaus voidaan aloittaa valitun integroimistavan mukaisesti heti, kun valmiita ohjelmamoduuleja on saatavilla. Integrointitestauksessa komponenttien yhteistoiminta testataan aina, kun
uusi yksikkötestattu komponentti lisätään kokoonpanoon. Vaiheittaisella integraatiolla pyritään eristämään mahdolliset viat viimeksi lisätyn komponentin vaikutuspiiriin, jolloin vikojen etsinnästä ja
korjaamisesta aiheutuisi mahdollisimman vähän lisätyötä. Integrointitestaus voi koostua useasta eri
osa-alueesta riippuen millaisesta kokonaisuudesta on kysymys esim. moduulitason integrointi, järjestelmätason integrointi, tarvittavien oheislaitteiden ja ulkoisten resurssien käyttöönotto ja testaus
(tietokanta, verkkoyhteydet, levytila) jne.
Järjestelmätestaus toteutetaan yksityiskohtaisten suunnitelmien mukaisesti. Ennen testauksen
aloittamista voidaan suorittaa esitestaus, jolla varmistetaan, että ohjelma tai järjestelmä on valmis
testattavaksi. Jos ohjelman toimivuus ei täytä tiettyjä minimitason vaatimuksia, perusteellista testausta ei kannata aloittaa (Kasurinen 2013, 72).
Järjestelmätestauksessa testiympäristön pitäisi vastata mahdollisimman paljon lopullista käyttöympäristöä, jotta myös käyttöympäristöön liittyvät häiriötilanteet ja mahdolliset riskitekijät voidaan havaita ja poistaa. Koska testaus suoritetaan aina tietylle järjestelmälle tietyssä ympäristössä, on tärkeää dokumentoida millaisesta laite- ja ohjelmistokokoonpanosta testiympäristö kokonaisuudessaan koostuu. Järjestelmätestauksessa testaustyypistä riippuen testit suoritetaan käsin (toimintojen testaus) tai apuna käytetään erilaisia testauksen työkaluja kuten simulaattoreita.
Testitulosten tarkastelu ja raportointi
Testitapaukset suoritetaan testiproseduurissa määritellyssä järjestyksessä ja jokainen suoritettu
testi dokumentoidaan. Testausprosessin mittaamista varten suoritetut testit tallennetaan testauksenhallintajärjestelmään tai testilokiin. Testilokiin kirjattavia tietoja ovat testin yksilöivä tunniste, testin lopputulos, testin suorittaja ja suorituspäivämäärä.
25
Testauksen tärkein vaihe on testitulosten vertaaminen odotettuihin tuloksiin, jolloin tuloksissa esiintyvät poikkeamat havaitaan. Poikkeamat analysoidaan ja niistä laaditaan virheraportti (dokumenttipohja löytyy liitteestä 4). Virheraportissa jokaiselle löydetylle virheelle määritellään tunnus ja kirjoitetaan kuvaus millaisesta virheestä on kysymys, mitä vaikutuksia virheellä on, kuinka vakava virhe
on ja missä tilanteessa virhe esiintyy. Virheraporttiin kirjattujen tietojen perusteella tehdään päätös
jatkotoimenpiteistä, joten asianmukaisen virheraportin laatiminen on sujuvan tiedonvälityksen kannalta erityisen tärkeää.
Virheraportit tallennetaan vianhallintajärjestelmään tai virhelokiin, jonka kautta tietoa välitetään eri
toimijoiden kesken. Virhelokia voidaan käyttää työlistana ja sen kautta voidaan seurata virheiden
käsittelyn etenemistä. Virhelokiin tallennettuja tietoja hyödynnetään myös testausprosessin seurannassa ja testauksen loppuarvioinnissa. Tilastoitavia tietoja ovat esim. virheiden kokonaismäärä,
korjattujen virheiden määrä, korjaamattomien virheiden määrä, erityyppisten virheiden esiintymistiheys sekä havaittujen virheiden jakautuminen eri vakavuus- ja prioriteettiluokkiin. (Kit 1995, 159;
Kasurinen 2013, 165-166).
Testauksen riittävyyden arviointi ja testauksen päättäminen
Testauksen tasoa ja riittävyyttä voidaan arvioida saavutetun testikattavuuden perusteella, ohjelmasta löydettyjen virheiden perusteella sekä analysoimalla testauksen tehokkuutta ja kannattavuutta (Kit 1995, 133-136). Testaukselle asetettujen lopetuskriteerien perusteella päätetään tarvitaanko lisätestausta vai lopetetaanko testaus.
Testauksen kattavuus
Testitapausten kehittämisellä pyritään saavuttamaan mahdollisimman hyvä testauksen kattavuus
(test coverage) ja kattavuuden parantamiseksi uusia testitapauksia kehitetään iteratiivisesti lisää
kaikissa testausprosessin vaiheissa. Testauksella saavutettu kattavuus kertoo kuinka hyvin testaukselle asetetut tavoitteet kullakin testaustasolla saavutetaan.
Moduulitestauksessa
pyritään
testaamaan
ohjelmakoodin
rakenne
ja
looginen
toiminta
mahdollisimman kattavasti. Testauksen kattavuutta mitataan erilaisilla koodikattavuusmitoilla, jotka
kertovat kuinka suuren osan ohjelman lauseista, päätöksistä, haarautumista ja ehdoista testeillä on
käyty läpi. (Ks. sivu 33, Koodikattavuuden kriteerit).
Integrointitestauksen kattavuus kertoo kuinka suuri osa ohjelmiston komponenteista on liitetty
onnistuneesti järjestelmään.
Järjestelmätason kattavuus perustuu testattuihin toimintoihin ja ominaisuuksiin (toimintojen kattavuus) sekä ei-toiminnallisten vaatimusten kohdalla olemassa olevan laatutason todentamiseen
26
(esim. käytettävyysvaatimukset, tietoturvavaatimukset, kuormituskykyvaatimukset ja luotettavuusvaatimukset). Laadullisten ominaisuuksien arvioinnissa käytetään etukäteen määriteltyä tavoitetasoa, johon testituloksia verrataan. Toimintojen kattavuuden mittaamiseen voidaan käyttää kattavuusmatriisia, johon on listattu testattavat toiminnot, kunkin toiminnon prioriteettitaso (esim. korkea,
keskitaso, alhainen) sekä toimintoihin liittyvät testitapaukset. Testien suorittamisen jälkeen kattavuusmatriisista voidaan tarkastaa kuinka suuri osa eri prioriteettitason toiminnoista testeillä on
käyty läpi. (Kit 1995, 100).
Hyväksymistestauksessa tavoitteena on varmistaa, että asiakasvaatimuksiin kirjatut tavoitteet on
toteutettu järjestelmään (käyttäjävaatimusten kaatavuus). Kattavuuden mittaamiseen voidaan
käyttää edellä kuvattua kattavuusmatriisiin perustuvaa menetelmää. Testauksen kattavuus kertoo
kuinka suuren osan määritellyistä vaatimuksista suoritetut testit kattavat.
Virheiden analysointi
Vianhallintajärjestelmään tallennettuja virheraportteja voidaan hyödyntää virheiden tilastollisessa
analysoinnissa. Virheet voidaan jakaa niiden alkuperän, vakavuuden ja vaikutusten perusteella eritasoisiin luokkiin ja kerättyä tietoa voidaan hyödyntää testauksen ja korjaustoimenpiteiden priorisoinnissa sekä tulevien projektien suunnittelussa. Löytyneiden virheiden määrän ja esiintymistiheyden perusteella voidaan tehdä päätelmiä virheiden kasaantumisesta ja vielä löytymättömien virheiden todennäköisyydestä. On mm. havaittu, että ohjelman osasta löydettyjen virheiden määrä on
suoraan verrannollinen siinä vielä jäljellä olevien virheiden määrään (Myers 1979, 15-16; Kit 1995,
159). Virheiden kasaantuminen on testauksen yhteydessä havaittu ilmiö, jossa löydetyn virheen
läheisyydestä löydetään tavallisesti lisää virheitä. Virheiden esiintymistiheyden perusteella lisätestausta kannattaakin ensisijaisesti kohdentaa niihin ohjelman osiin, joista virheitä on löytynyt eniten.
Testauksen riittävyyden arviointiin voidaan käyttää ns. virhekäyrää, jossa kuvataan löytyneiden ja
korjattujen virheiden määrällistä kehitystä testausprosessin edetessä. Lopetuskriteeriksi voidaan
esimerkiksi määritellä, että testausta on tehty riittävästi, kun virhekäyrän kasvu tasaantuu (Haikala
& Märijärvi 2002, 291).
27
Kuva 5. Virhekäyrä (Haikala & Märijärvi, 2002, 291).
Testauksen tehokkuuden arvioiminen
Täydellisen kattavaa testausta ei käytännössä koskaan pystytä toteuttamaan. Testauksen säännöllisen mittaamisen avulla (esim. vertaamalla suunniteltujen ja suoritettujen testitapausten määrää)
voidaan seurata kuinka tehokkaasti testaustyö etenee. Testien suunnittelun ja suorittamisen laadusta kertovat esim. hylättyjen, keskeneräisten tai käyttämättömien testien määrät. Testauksen onnistumista voidaan analysoida myös ohjelman käyttöönoton jälkeen raportoitujen virheiden perusteella.
Testauksen riittävyyden arvioinnissa joudutaan usein pohtimaan onko testauksen jatkaminen taloudellisesti järkevää. Testaus voidaan joutua lopettamaan, koska siihen varatut rahat on käytetty tai
aikaa lisätestauksen tekemiseen ei enää ole. Testauksen kannattavuutta voidaan arvioida myös
riskiperusteisesti. Mikäli riski mahdollisten virheiden jättämisestä ohjelmaan arvioidaan pieneksi,
voidaan tehdä päätös testauksen lopettamisesta.
Testauksen päättämistehtävät
Testauksen päättämistehtäviin kuuluvat testauksen loppuraportin laatiminen ja testauksen hyväksyntä. Loppuraportti sisältää tilastollisen analyysin testausprosessin mittareista sekä yhteenvedon
testauksen tuloksista. Tilastollinen vertailu testilokin ja virhelokin tiedoista havainnollistaa mitä tuloksia testauksen eri työvaiheissa on saatu ja kuinka testausprosessin läpivienti on onnistunut. Lopetusehtojen mukaisesti suoritettu testaus hyväksytään ja suunnitelman mukainen testausprosessi
voidaan todeta päättyneeksi.
Dokumenttipohja testauksen loppuraportin laatimiseen löytyy liitteestä 5.
28
Yhteenveto testauksen työvaiheista ja tuotoksista
Testauksen suunnittelu

Testauksen pääsuunnitelma

Vaihekohtaiset testaustasojen suunnitelmat

Testitapausten määrittelyt

Testiproseduurin määrittely

Kattavuusmatriisit
Testauksen toteutus

Testiajurit

Sijaiskomponentit

Yksikkötestit

Testiloki

Virheraportit

Mahdolliset testauksen väliraportit (esim. testaustasoittain tai erikseen tietystä testaustyypistä kuten suorituskyky- tai tietoturvatestauksesta)
Testauksen päättäminen

Kattavuusarvio

Virheanalyysi

Testauksen loppuraportti
29
Luku 4 Testaustekniikat
Testaustekniikat ovat systemaattisia menetelmiä, joiden avulla testausta voidaan toteuttaa
suunnitelmallisesti ja tehokkaasti testausprosessin eri vaiheissa. Osa tekniikoista on tarkoitettu
tietyille testauksen tasoille ja tietyn tyyppisten virheiden etsintään ja joitakin tekniikoita voidaan
soveltaa monipuolisesti kaikilla testauksen tasoilla. Menetelmien valintaan ja käytettäviin tekniikoihin
vaikuttavat testauksen kohteena olevan ohjelman lisäksi ohjelman kehitystapa sekä testaukselle
asetetut tavoitteet. Erilaisilla menetelmillä havaitaan erityyppisiä virheitä ja parhaaseen
lopputulokseen päästään, kun valitaan eri lähestymistapoihin perustuvia tekniikoita, jotka
täydentävät toisiaan.
Staattiset testaustekniikat
Staattinen testaus (static testing) tarkoittaa ohjelmakoodin analysointi- ja tarkastustekniikoita, jotka
eivät perustu ohjelman suorittamiseen. Ohjelmakoodin staattinen analysointi tehdään tavallisesti
ohjelmallisilla työkaluilla, joissa on toimintoja ohjelmakoodin syntaksin, rakenteen ja tyylin automaattiseen tarkastamiseen. Perusvälineitä kooditarkastuksessa ovat ohjelmointivaiheessa käytettävät ohjelmakoodin kääntäjät ja virheenjäljitystyökalut eli debuggerit. Kehittyneempiä ohjelmakoodin analysointityökaluja ovat ns. koodianalysaattorit, joilla voidaan monipuolisemmin mitata ja analysoida ohjelman kokoa, monimutkaisuutta ja virhealttiutta.
Monimutkainen koodi vaikeuttaa ohjelman ylläpidettävyyttä ja lisää todennäköisyyttä ohjelmavikoihin. Staattisen analyysin tarkoituksena on arvioida ja parantaa ohjelmakoodin laatua etsimällä virheitä ja todennäköisiä virhekohtia.
Koodianalysaattori varoittaa esim. seuraavanlaisista ohjelmakoodin heikkouksista:

monimutkaiset rakenteet

toistuva koodi

kuollut koodi (ohjelmakoodi suoritetaan mutta se ei varsinaisesti tee mitään)

saavuttamaton koodi (ohjelmakoodia ei edes suoriteta)

määritellyt muuttujat joita ei ole käytetty

alustamattomat muuttujat

viittaukset muuttujiin, joille ei ole annettu arvoa

viittaukset indeksirajojen ulkopuolelle

kutsumattomat funktiot

parametrien virheellinen käyttö
30

osoittimien virheellinen käyttö

dynaamisesti varattu muisti, jota ei ole vapautettu
Ohjelmakoodin staattista analysointia voidaan kooditarkastuksen lisäksi hyödyntää myös testauksen suunnittelussa. Esimerkiksi ohjelman kompleksisuuden perusteella lisätestausta voidaan kohdentaa ohjelmanosiin, jotka monimutkaisen rakenteensa vuoksi ovat erityisen riskialttiita virheille
(Kit 1995, 145).
Manuaaliset katselmukset, tarkastukset ja läpikäynnit ovat ryhmässä suoritettuja tarkastusmenettelyjä, joilla pyritään poistamaan dokumenteissa olevia virheitä ja puutteita mahdollisimman varhaisessa vaiheessa. Tarkastuksia ja katselmuksia voidaan tehdä kaikille ohjelmistoprosessissa syntyville vaihetuotteille. Menettelyä kutsutaan myös dokumenttien verifiointiprosessiksi (Myers 1979,
106; Kit 1995, 30).
Katselmukset
Katselmointi (reviewing) on ohjelmistoprojektin etappeihin liittyvä arviointi- ja tarkastustapahtuma,
jonka tarkoituksena on varmistaa, että tietylle vaiheelle asetetut kriteerit on täytetty ja tarvittavat
tehtävät on suoritettu. Katselmus on sekä projektinhallintaan että laadunvarmistukseen kuuluva
menettelytapa, jolla saadaan prosessin eteneminen ja laatu näkyväksi. (Haikala & Märijärvi 2002,
266-267).
Katselmukset ovat usein tilannearvioita, joissa etsitään ongelmakohtia, keskustellaan ja jaetaan
tietoa. Katselmointiprosessin keskeinen tavoite on eliminoida virheitä jo niiden syntyvaiheessa, jotta
ongelmien siirtyminen seuraaviin vaiheisiin voidaan estää. Katselmointitilaisuuden sisältö ja muoto
vaihtelevat riippuen mitä ja millä tasolla asioita tilaisuudessa käsitellään. Tyypillisesti katselmoinnin
kohteena ovat ohjelmistoprosessin vaihetuotteet kuten määrittely- ja suunnitteludokumentaatio tai
koodi. Katselmointiin voi sisältyä myös prosessin ja menettelytapojen arviointia eli auditointia.
(Pressman 2005, 719; Kit 1995, 57; Kasurinen 2013, 158).
Epämuodollinen katselmointi voidaan järjestää kehitys- tai testaustiimin sisäisenä tapahtumana,
jossa käydään vapaamuotoisesti läpi kehitysvaiheen tilaa ja tarkastellaan vaiheeseen liittyviä
menettelytapoja,
tehtäviä
ja
tuotoksia.
Virallisempi
tekninen
katselmointitilaisuus
on
projektisuunnitelmassa etukäteen määritelty tarkastuspiste, jonka tarkoituksena on todeta tietyn
kehitysvaiheen päättyminen. Muodolliseen katselmointitilaisuuteen osallistuu kehitysvaiheen
toteutuksesta vastaavia henkilöitä ja projektiorganisaation (johdon) edustajia. Asiakasprojekteissa
tärkeimpiin katselmointitilaisuuksiin osallistuu myös asiakas.
Katselmointiproseduuriin kuuluu, että katselmoijat tutustuvat tarkastettavaan materiaaliin etukäteen.
Katselmoijien tehtävänä on arvioida vastaako tarkastettava vaihetuote sille asetettuja laadullisia ja
31
teknisiä vaatimuksia. Lisäksi voidaan tarkastella yleisiä hyvän dokumentaation ominaisuuksia kuten
standardien ja tyylikäytäntöjen mukaisuutta, tiedon jäljitettävyyttä, sisällön yhtenäisyyttä,
ymmärrettävyyttä ja virheettömyyttä. Katselmoinnissa havaitut puutteet ja virheet kirjataan raporttiin,
jonka perusteella tehdään tarvittavat korjaustoimenpiteet. Tarkistuspisteen katselmointiprosessi
toistetaan tarvittaessa uudestaan kunnes päädytään hyväksyttävään lopputulokseen ja vaihe
voidaan todeta päättyneeksi. (Pressman 2005, 722-725).
Tarkastukset
Muodollinen tarkastus (inspection) on prosessi, jonka tarkoituksena on varmistaa tarkastettavan
materiaalin laatu. Tarkastuksen kohteena voi olla mikä tahansa ohjelmistoprojektin dokumentti tai
sen
osa
esim.
vaatimusmäärittely,
suunnitteluspesifikaatiot,
koodi,
testaussuunnitelma,
testitapaukset, käyttöohjeet tai www-sivut. Muodollisen tarkastusmenettelyn elementtejä ovat
etukäteen tehty suunnittelu- ja valmistelutyö, tarkastukseen osallistuvien henkilöiden erityisroolit,
puheenjohtajan johtama kokousmenettely ja toimenpiteiden jälkiseuranta (Haikala & Märijärvi 2002,
267-268).
Tarkastusmenettelyn
organisoinnista
vastaava
henkilö
huolehtii
aikataulun
laatimisesta,
tilajärjestelyistä sekä tarkastettavan materiaalin jakamisesta tarkastajille hyvissä ajoin ennen ryhmän
kokoontumista. Tarkastukseen osallistuvien jäsenten tehtävänä on perehtyä tarkastettavaan
materiaalin mahdollisimman hyvin etukäteen, etsiä virheitä ja kirjata ongelmaksi havaitsemiaan
asioita. Tarkastustyön helpottamiseksi ja nopeuttamiseksi voidaan laatia ns. tarkastuslista, johon on
koottu asioita, joihin tarkastajien on erityisesti kiinnitettävä huomiota (Haikala & Märijärvi 2002, 270).
Tarkastusistunnossa kokouksen puheenjohtaja (moderaattori) johtaa kokousta ja huolehtii
kokouksen sujuvasta etenemisestä. Tarkastettava materiaali esitellään sopivan kokoisina palasina
kohta kohdalta läpi. Esittelijä on usein dokumentin tekijä vaikka objektiivisuuden kannalta
suositeltavampaa olisi, että esittelijänä toimisi joku muu. Tarkastajat kommentoivat ja esittävät
kysymyksiä esittelyn aikana. Sihteeri kirjaa istunnossa löydetyt virheet ja havaitut ongelmakohdat.
Tarkastusistunnon päätteeksi puheenjohtaja tekee yhteenvedon, jonka perusteella päätetään
jatkotoimista. Korjaustoimenpiteiden jälkeen voidaan järjestää uusintatarkastus tai korjaukset
voidaan hyväksyä ilman uutta muodollista kokousmenettelyä (Haikala & Märijärvi 2002, 270-272).
Eri vaiheissa tehdyt dokumenttien tarkastukset ovat osoittautuneet erittäin kustannustehokkaaksi
virheiden eliminointikeinoksi (Haikala & Märijärvi 272-274). Ongelmat havaitaan aikaisessa
vaiheessa, jolloin virheiden alkuperä on helpommin selvitettävissä. Usean virheen löytyminen
kerralla mahdollistaa myös niiden korjaamisen kerralla. Tarkastuksilla havaitaan myös virheitä, jotka
eivät testaamalla tule esille. Vaikka muodollinen tarkastus on työläs ja aikaavievä prosessi niin
virheiden etsiminen myöhemmin testaamalla on vielä työläämpää.
32
Tarkastuksen onnistumista voi edesauttaa noudattamalla seuraavia ohjeita:

tarkastettavaksi ei viedä keskeneräistä materiaalia

tarkastettavaa materiaalia ei saa olla kerralla liikaa

osallistujat tekevät valmistelevan työn huolellisesti

istunnossa keskitytään ongelmien etsimiseen, ei ratkaisuehdotusten tekemiseen

jälkiseurannassa huolehditaan, että vaadittavat korjaukset on tehty
Ohjelmakoodin tarkastus
Ohjelmakoodin tarkastuksessa ohjelmistokehityksen ja testauksen ammattilaisista muodostettu
ryhmä (3-6 henkilöä) kokoontuu istuntoon ohjelmakoodin manuaalista tarkastusta varten. Myersin
(1979, 24) mukaan manuaalisessa kooditarkastuksessa on mahdollista käydä läpi noin 150 lausetta
tunnissa. Istunnon sopiva kesto on 90-120 minuuttia kerrallaan, joten laajojen ohjelmien
läpikäymiseksi
tarvitaan
useampia
istuntokertoja.
Kooditarkastuksen
apuna
käytetään
tarkastuslistaa, johon on koottu ohjelmissa usein esiintyviä tyypillisiä virheitä.
Kooditarkastuksen ensisijaisia hyötyjä ovat virheiden aikainen havaitseminen ja virhealttiiden
ohjelmanosien tunnistaminen. Ongelmana on usein tarkastettavan koodin suuri määrä, jolloin koko
ohjelman yksityiskohtainen läpikäyminen ei ole mahdollista. Kooditarkastus voidaankin kohdentaa
esimerkiksi virheenkäsittelyyn, standardien mukaisuuteen, ohjelmointityylin yhtenäisyyteen,
kommentointiin jne., jolloin erityyppisten virheiden etsintään voidaan järjestää useita, toisiaan
täydentäviä istuntoja. (Haikala & Märijärvi 2002, 274-275; Kit 1995, 59-60).
Ohjelmakoodin läpikäynti
Ohjelmakoodin läpikäynti (walkthrough) on myös ryhmänä suoritettava proseduuri mutta tavallisesti
se on muodoltaan vapaampi kuin varsinainen tarkastusmenettely. Ryhmään valitaan 3-5 jäsentä,
joista yksi on ohjelmakoodin tekijä. Muiden jäsenten olisi hyvä edustaa erilaisia näkökulmia eri
osaamisalueilta esim. kokenut/kokematon ohjelmoija, testaaja, ylläpitäjä, suunnittelija jne.
Ohjelmakoodin läpikäynnissä ohjelman tekijä esittelee ohjelman toimintaa muille ryhmän jäsenille.
Muilta osallistujilta ei välttämättä edellytetä etukäteen valmistautumista, mistä johtuen istunnon
järjestäminen
ja
läpivienti
on
nopeampaa
ja
helpompaa
kuin
monivaiheisessa
tarkastusmenettelyssä. Ohjelman läpikäynti ryhmässä avartaa näkökulmia ja virheiden etsinnän
lisäksi istunnot ovat hyviä kommunikaatio- ja oppimistapahtumia. (Kit 1995, 60-61).
33
Pöytätarkastus ja ohjelmakoodin vertaisarvostelu
Pöytätarkastus (desk checking) tarkoittaa ohjelmakoodin tai mikä tahansa dokumentin epämuodollista tarkastusta, jonka tekee joku toinen kuin dokumentin tekijä. Kyseessä on tarkastuksen perusmuoto, joka vähintään olisi hyvä tehdä kaikille dokumenteille. (Myers 1979, 33).
Vertaisarvostelu (peer rating) on menetelmä, jossa ohjelmoijat arvostelevat anonyymisti muiden
tekemää koodia. Arvostelussa kiinnitetään huomiota esimerkiksi ohjelmakoodin selkeyteen, ylläpidettävyyteen, laajennettavuuteen, uudelleenkäytettävyyteen ja testattavuuteen. Arvostelu tehdään
kyselylomakkeella pisteyttämällä koodin laadullisia ominaisuuksia. Arvosteluprosessin tarkoituksena on tuoda esiin ohjelmissa olevia laadullisia puutteita sekä kartoittaa ohjelmoijien ohjelmointitasoa. Menetelmä auttaa myös ohjelmoijaa arvioimaan omaa ohjelmointitaitoa ja siinä olevia heikkouksia. (Myers 1979, 34-35).
Dynaaminen testaus
Dynaaminen eli ohjelman suorittamiseen perustuva testaus (dynamic testing) on ainoa keino, jolla
ohjelmakoodin todellinen toiminta voidaan todentaa (Beizer 1990, 74). Dynaamisessa testauksessa
ohjelmaa käydään systemaattisesti läpi valikoiduilla testitapauksilla ja testien tuloksia verrataan
odotettuihin lopputuloksiin. Testitapausten kehittämiseen käytetään suunnittelutekniikoita, jotka
perustuvat tyypillisesti kahteen peruslähestymistapaan: rakenteelliseen eli valkolaatikkotestaukseen
ja toiminnalliseen eli mustalaatikkotestaukseen.
Mustalaatikkotestauksessa (black-box testing, input/output testing, functional testing) ohjelman
ajatellaan olevan kuin musta laatikko, jonka käyttäytymistä tarkastellaan käyttäjän näkökulmasta.
Laatikon sisältöä eli ohjelmakoodia ja toteutuksen yksityiskohtia ei huomioida testien suunnittelussa.
Testitapaukset kehitetään ohjelman määrittely- ja suunnitteludokumentaation perusteella, mistä
johtuen testaustavasta käytetään myös termiä määrittelypohjainen testaus. Mustalaatikkotestaus
soveltuu
erityisesti
ohjelman
toimintojen
ja
laadullisten
ominaisuuksien
testaamiseen.
Ohjelmavirheiden lisäksi mustalaatikkotestauksen menetelmillä havaitaan spesifikaatioissa olevia
ristiriitaisuuksia ja puutteita. (Myers 1979, 8-9).
Valko- eli lasilaatikkotestauksessa (white-box testing, glass-box testing, structural testing) etsitään
virheitä ohjelman sisäisestä toteutuksesta. Valkolaatikkotestauksen menetelmiä käytetään erityisesti
moduulitestauksessa, jossa testauksen kohteena ovat ohjelman rakenneosat kuten funktiot, lauseet,
määrätyt suorituspolut, silmukat ja tietorakenteet. Testien suunnittelussa käytetään sekä ohjelman
suunnitteludokumentaatiota että valmista ohjelmakoodia. Tavoitteena on löytää testitapaukset, jotka
testaavat ohjelmakomponentin loogisen toiminnan ja sisäisen tilan mahdollisimman kattavasti.
Lisäksi ohjelman rakenteen perusteella pyritään löytämään kohdat, joissa todennäköisemmin
esiintyy virheitä. (Myers 1979, 9-10).
34
Musta- ja valkolaatikkotestauksen lisäksi kaikilla testaustasoilla voidaan hyödyntää testaajan
ammattitaitoon ja kokemukseen perustuvia lähestymistapoja, jolloin testitapausten suunnittelu
perustuu enemmän intuitioon kuin systemaattiseen spesifikaatioiden tulkintaan. Tyypillisiä
kokemusperusteisia testausmenetelmiä ovat virheenarvaus ja tutkiva testaaminen. (Myers 1979, 7374; Kasurinen 2013, 74).
Valkolaatikkotestauksen menetelmät
Valkolaatikkotestauksen tavoitteena on kehittää testitapauksia, jotka testaavat ohjelmakoodin
rakenteen ja loogisen toiminnan mahdollisimman kattavasti. Mitä kriittisempi järjestelmä on
kyseessä, sitä korkeammat kriteerit testauksen kattavuudelle asetetaan. Kattavuutta mittaamalla
todennetaan, kuinka hyvin valittu testijoukko täyttää asetetut vaatimukset.
Koodikattavuuden kriteerit
100 % lausekattavuudella (statement coverage) tarkoitetaan, että ohjelman jokainen lause
suoritetaan vähintään kerran. Lausekattavuus ei edellytä esim. ehtolauseiden eri haarojen
läpikäymistä, joten ohjelmalogiikan riittävään testaamiseen lausekattavuuden kriteeri on liian heikko
(Myers 1979, 38).
Kattavampi kriteeri loogisten suorituspolkujen testaamiseen on päätöskattavuus (decision coverage,
branch coverage). 100 % päätöskattavuus edellyttää, että myös jokainen ohjelman päätöskohdissa
muodostuva lauseen haara testataan (Myers 1979, 46).
Ehtokattavuuden (condition coverage) vaatimuksena on, että valintarakenteen kaikkien ehtojen on
saatava sekä tosi- että epätosiarvot ainakin kerran. Ehtokattavuudesta ei kuitenkaan välttämättä
seuraa päätöskattavuus. Jos ehtokattavuuden halutaan johtavan myös päätöskattavuuteen, on
käytettävä sekä ehto- että päätöskattavuuden kriteerit täyttävää mittaa eli päätösehtokattavuutta
(Myers 1979, 41).
Päätös- ja ehtokattavuuden yhdistämisellä parannetaan merkittävästi polkukattavuutta, mutta sillä
ei vielä varmisteta, että valintarakenteen kaikkien ehtojen kaikki eri kombinaatiot tulevat testatuksi.
Moniehtokattavuuden (multiple-condition coverage) kriteeri edellyttää sekä valintarakenteen
kaikkien ehtojen muodostamien erilaisten kombinaatioiden että päätöstulosten eri vaihtoehtojen eli
haarojen läpikäymistä. (Myers 1979, 42).
Mitä perusteellisempaa testausta halutaan tehdä, sitä vahvempaa kattavuusmittaa käytetään.
Vahvempi kattavuuden kriteeri tarkoittaa tavallisesti myös sitä, että suoritettavia testitapauksia
tarvitaan enemmän. Seuraavat esimerkit havainnollistavat ehtorakenteiden testausta erilaisilla
kattavuuden kriteereillä.
35
Esimerkki 1.
Ohjelmakoodin valintarakenteen ehdot on yhdistetty loogisella AND-operaattorilla.
Ehtolause:
if(ika >= 0 &&
Ehto 1:
ika >= 0
ika < 20)
Ehto 2: ika < 20
Testi
Ehto 1
Ehto 2
Päätöstulos
1
Tosi
Epätosi
Epätosi
2
Epätosi
Tosi
Epätosi
3
Tosi
Tosi
Tosi
4
Epätosi
Epätosi
Epätosi
Kattavuusmittojen kriteerit saavutetaan esimerkiksi seuraavasti:

Ehtokattavuus testitapauksilla 1 ja 2

Päätöskattavuus testitapauksilla 1 ja 3

Päätösehtokattavuus testitapauksilla 3 ja 4 (myös tapauksilla 1, 2 ja 3)

Moniehtokattavuus testitapauksilla 1, 2, 3 ja 4
Esimerkki 2.
Monimutkaisempi valintarakenne edellyttää enemmän testitapauksia.
Ehtolause:
if ( ( a >= 0 && a < b ) || ( c != 0 ) )
Ehto 1:
a >= 0
Ehto 2: a < b
Ehto 3: c != 0
Testi
Ehto 1
Ehto 2
Ehto 3
1
Tosi
Tosi
Tosi
Tosi
2
Tosi
Tosi
Epätosi
Tosi
3
Tosi
Epätosi
Epätosi
Epätosi
4
Epätosi
Tosi
Tosi
Tosi
36
Päätöstulos
5
Epätosi
Epätosi
Tosi
Tosi
6
Epätosi
Epätosi
Epätosi
Epätosi
7
Epätosi
Tosi
Epätosi
Epätosi
8
Tosi
Epätosi
Tosi
Tosi
Moniehtokattavuuden saavuttamiseksi tarvitaan kaikkien ehtojen kombinaatiota, joiden määrä
saadaan kaavasta 2n (n on ehtojen lukumäärä). Lisäksi kriteeri edellyttää, että päätöstuloksen on
saatava sekä tosi ja epätosiarvot vähintään kerran.
Kattavuusmittojen kriteerit saavutetaan seuraavilla valinnoilla:

Päätösehtokattavuus testitapauksilla 3 ja 4

Moniehtokattavuus kaikkien testitapausten 1-8 läpikäynnillä
Polkutestaus
Polkutestaus (path testing) on rakenteellisen testauksen perusta. Polkutestauksessa pyritään kattamaan mahdollisimman monta erilaista ohjelman suorituspolkua. Täydellinen polkutestaus tarkoittaisi ohjelman kaikkien loogisten suorituspolkujen läpikäymistä. Aivan yksinkertaisimpia tapauksia
lukuun ottamatta 100 % polkukattavuus ei ole mahdollista eikä käytännön testauksen kannalta
edes järkevä tavoite (Myers 1979,37).
Ohjelmapolkujen perusjoukon määritys (basic path testing) on polkutestauksen muoto, jossa
testitapaukset kehitetään itsenäisten ohjelmapolkujen perusjoukolle. Ohjelmasta muodostetaan
suunnattu verkko, joka kuvaa ohjelmalogiikan etenemistä. Suunnatun verkon solmut ovat ohjelman
lohkorakenteita ja linkit siirtymiä lohkojen välillä. Itsenäinen polku tarkoittaa suunnatussa verkossa
kuljettua reittiä alkusolmusta loppusolmuun niin, että reitillä on ainakin yksi uusi, ennen käyttämätön
siirtymä. Perusjoukko on tällöin itsenäisten ohjelmapolkujen lukumäärä, joka tarvitaan, jotta jokainen
solmu ja väli tulevat suoritetuksi vähintään kerran. Testaamalla perusjoukon määrittämät
ohjelmapolut testaus täyttää vähintään lausekattavuuden kriteerin. (Pressman 2005, 393-395).
Mutkikkuusmitat
Ohjelmakoon kasvaessa ohjelman rakenne monimutkaistuu ja todennäköisyys virheisiin lisääntyy.
McCaben syklomaattinen numero on klassinen menetelmä, jolla ohjelmakoodin loogista
kompleksisuutta
eli
mutkikkuutta
voidaan
määrällisesti
mitata
(Pressman
2005,
395).
Syklomaattinen numero määrittää samalla minimimäärän testitapauksille, joilla saavutetaan
lausekattavuus testattavalle koodille.
37
McCaben syklomaattinen numero voidaan määrittää kolmella eri tavalla:
1) Syklomaattinen numero vastaa solmujen ja linkkien muodostamien alueiden eli silmukoiden
määrää suunnatussa verkossa. Suunnattua verkkoa ympäröivä ulkopuolinen alue lasketaan
myös yhdeksi silmukaksi.
2) Kaavalla V(G) = E – N + 2, jossa E on linkkien määrä ja N solmujen määrä verkossa.
3) Kaavalla V(G) = P + 1, jossa P on predikaattisolmujen eli haarautumiskohtien lukumäärä
verkossa (predikaattisolmusta lähtee vähintään kaksi linkkiä toisiin solmuihin).
Syklomaattisen kompleksisuuden määrityksellä saadaan laskennallinen arvo myös perusjoukon
itsenäisten polkujen lukumäärälle. Menetelmää voidaan soveltaa esim. funktioiden testauksessa,
jolloin kompleksisuusluku on minimimäärä testitapauksille, joilla ko. funktiota on testattava (Haikala
& Märijärvi 2002, 292).
Mustalaatikkotestauksen menetelmät
Mustalaatikkotestauksella pyritään löytämään tilanteet, joissa ohjelman ulkoinen toiminta ei vastaa
spesifikaation määrittelyä. Testausta varten on oltava käsitys ohjelman syöte- ja tulosavaruudesta
sekä tiedettävä mikä on oikea lopputulos (Haikala & Märijärvi, 2002, 283). Testitapausten
suunnittelussa
hyödynnetään
ohjelman
määrittely-
ja
suunnitteludokumentaatiota
sekä
kokemuksella kertynyttä tietoa virheistä, joita ohjelmissa esiintyy. Syöteavaruuden rajaamisella
pyritään valitsemaan testitapaukset, joilla on suurin todennäköisyys löytää virheitä.
Ekvivalenssiositus
Ekvivalenssiositus (equivalence partitioning) on menetelmä, jossa testisyötteiden rajaaminen
perustuu syöteavaruuden jakamiseen ekvivalenssiluokkiin eli arvoalueisiin. Syöteavaruudesta
muodostetaan kahdenlaisia ekvivalenssiluokkia: kelvollisten syötteiden ekvivalenssiluokat ja eikelvollisten syötteiden ekvivalenssiluokat. Oletuksena on, että jos ohjelma toimii yhdellä
ekvivalenssiluokan edustajalla, niin se toimii myös muilla saman luokan edustajilla. Saman asian voi
ilmaista myös käänteisesti; mikäli yksi ekvivalenssiluokan testitapaus paljastaa virheen, voidaan
olettaa, että myös muut saman ekvivalenssiluokan testitapaukset paljastaisivat samaan luokkaan
kuuluvan virheen. (Myers 1979, 45).
Syöteavaruuden jakaminen ekvivalenssiluokkiin vähentää huomattavasti testattavien tapausten
määrää. Ekvivalenssiosituksessa haasteena on osituksen oikeellisuus. Ongelmia aiheuttavat mm.
epäyhtenäiset arvoalueet, arvoalueiden päällekkäisyydet ja arvoalueiden rajakohdat. Ekvivalenssiosituksen tarkkuutta parannetaan jakamalla luokkia pienempiin osiin.
38
Ekvivalenssiosituksessa testitapausten kehittäminen sisältää kaksi vaihetta (Myers 1979, 46-47;
Pressman 2005, 405-406; Kit 1995, 83-84). Ensimmäisessä vaiheessa pyritään tunnistamaan syötetilat (input conditions), joiden pohjalta ekvivalenssiluokkia voidaan muodostaa. Pääsääntönä on,
että yhtenäisen arvoalueen muodostamista syötteistä muodostetaan yksi ekvivalenssiluokka kelvollisille arvoille ja kaksi ekvivalenssiluokkaa ei-kelvollisille arvoille (arvoalueen molempien päiden
ulkopuolelta). Mikäli syötetilat muodostavat arvojoukon, muodostetaan yksi kelvollisten arvojen
ekvivalenssiluokka arvojoukkoon kuuluville syötteille ja yksi ei-kelvollisten arvojen ekvivalenssiluokka arvojoukon ulkopuolisille arvoille.
Ekvivalenssiosituksen toisessa vaiheessa tunnistetuille ekvivalenssiluokille kirjoitetaan testitapaukset. Testitapausten määrittely aloitetaan kelvollisten arvojen ekvivalenssiluokista. Erilaisia testitapauksia kehitetään niin kauan kunnes ne kattavat kaikki tunnistetut ekvivalenssiluokat. Tämän jälkeen määritellään testitapaukset ei-kelvollisille ekvivalenssiluokille, jolloin on erityisesti huomioitava, että jokainen ei-kelvollinen ekvivalenssiluokka tulee testata omassa testitapauksessaan.
Usean virhetilanteen testaaminen samassa testitapauksessa voi johtaa tilanteeseen, jossa ensimmäinen virhe peittää ja estää muiden virhetilanteiden suorittamisen, jolloin osa virheistä jää tunnistamatta.
Esimerkki 3.
Kenttään syötetyn viestin pituus tulee olla 10-3000 merkkiä. Ohjelma tarkistaa viestin pituuden ja
antaa virheilmoituksen käyttäjälle, jos viestin pituus on väärä.
Syötetiloista muodostetaan yksi kelvollisten syötteiden ekvivalenssiluokka
E1
”merkkijonon pituus on 10-3000 merkkiä”
ja kaksi ei-kelvollisten syötteiden ekvivalenssiluokkaa
E2
”merkkijonon pituus < 10”
E3
”merkkijonon pituus > 3000”
Kullekin ekvivalenssiluokalle kehitettään luokkaa edustava testitapaus esim. seuraavasti:
Syötetila
Kelvolliset syötteet
Ei-kelvolliset syötteet
merkkijonon pituus
(E1) 15 merkkiä
(E2) 0 merkkiä
(E3) 4000 merkkiä
39
Raja-arvoanalyysi
Raja-arvoanalyysi (boundary-value analysis) on ekvivalenssiosituksesta kehitetty menetelmä,
jossa keskitytään ekvivalenssiluokkien rajoilla sekä juuri niiden ala- ja yläpuolella olevien arvojen
tarkasteluun. Eroten ekvivalenssiosituksesta, jossa testitapaukset kehitetään syöteavaruuden perusteella, raja-arvoanalyysissä ekvivalenssiluokkia muodostetaan myös analysoimalla myös mahdollinen tulosavaruus. Jos odotetut lopputulokset muodostavat tulosjoukkoja tai arvoalueita kehitetään testitapaukset myös tulosavaruudelle raja-arvoanalyysin mukaisesti.
Esimerkki 4.
Edellistä esimerkkiä 3 voitaisiin täydentää raja-arvoanalyysiin perustuvilla testitapauksilla
seuraavasti:
Testisyöte
Odotettu lopputulos
viestin pituus 9 merkkiä
hylätty syöte, virheilmoitus käyttäjälle
viestin pituus 10 merkkiä
hyväksytty syöte
viestin pituus 11 merkkiä
hyväksytty syöte
viestin pituus 2999 merkkiä
hyväksytty syöte
viestin pituus 3000 merkkiä
hyväksytty syöte
viestin pituus 3001 merkkiä
hylätty syöte, virheilmoitus käyttäjälle
Esimerkissä on määritelty tulosavaruudelle kaksi ekvivalenssiluokkaa ”hyväksytyt syötteet” ja ”hylätyt syötteet”. Molempien luokkien edustajat tulevat testatuksi esimerkin kelvollisten- ja ei-kelvollisten syötteiden testitapauksilla. Tulosavaruudesta voitaisiin muodostaa lisää ekvivalenssiluokkia
esimerkiksi tapauksille, joissa ohjelman normaali eteneminen keskeytyy virheeseen ja siirtyy virheenkäsittelylohkoon.
Raja-arvoanalyysi on oikein toteutettuna tehokas menetelmä ja sitä voidaan soveltaa monipuolisesti
testauksen eri vaiheissa. Sekä ekvivalenssiosituksessa että raja-arvoanalyysissä testitapaukset
kirjoitetaan vain yhdelle syötteelle kerrallaan, joten menetelmillä ei voida testata usean syötteen
yhdistelmiä (Myers 1979, 56).
Syy-seuraus-mallinnus ja päätöstaulutestaus
Syy-seuraus-mallinnus (cause-effect graphing) on systemaattinen menetelmä testitapausten kehittämiseen usean syötteen yhdistelmille. Syy-seuraus-mallinnuksessa luonnollisella kielellä laadittu
spesifikaatio muunnetaan notaatioksi, jossa käytetään graafisia symboleita. Kuvan 6 notaatiossa
40
objektit (syyt ja seuraukset) on merkitty ympyröillä eli solmuilla ja niiden välinen suhde (funktio) viivalla eli linkillä. Solmut ja niitä yhdistävät linkit muodostavat verkon eli graafin.
Kuva 6. Syy-seuraus-verkko (Myers 1979, 58).
Syy-seuraus-mallinus toteutetaan vaiheittain seuraavan proseduurin mukaisesti (Myers 1979, 5657):
1) Mallinnus aloitetaan jakamalla spesifikaatio helpommin työstettäviin osiin. Sopivan kokoinen
osa voi olla esim. yksi toiminto tai funktio.
2) Syyt ja niiden seuraukset etsitään spesifikaatiosta käymällä teksti huolellisesti läpi kohta
kohdalta. Syy voi olla erillinen, yksittäinen syötetila tai syöteavaruudesta muodostettu
ekvivalenssiluokka. Seuraus on esim. ohjelman tuloste tai suorituksen tulos kuten tiedoston
päivitys, muutos tietorakenteen tiedoissa tai muuttujissa, viesti tilan muutoksesta käyttäjälle
jne.
3) Löydetyt
syy-seuraussuhteet muunnetaan graafiseksi syy-seurausmalliksi.
Syy-
ja
seurauskombinaatiot, joita ei voida graafilla mallintaa, selitetään sanallisesti kuvaukseen.
4) Graafisesta syy-seurausmallista muodostetaan päätöstaulu, jossa syyt (muuttujat/ehdot) ja
seuraukset (toiminnot/operaatiot) sijoitetaan riveille allekkain. Syy-seurausmallin perusteella
määritellään riveille arvot. Esimerkiksi Boolean-algebraan perustuvassa notaatiossa syyt ja
seuraukset saavat loogisen tila-arvon 0 tai 1 (Myers 1979, 56).
5) Proseduurin viimeisessä vaiheessa päätöstaulun sarakkeista muodostetaan testitapaukset.
Päätöstaulun kaikki erilaiset syy-seurauskombinaatiot tulevat katetuksi, kun jokaisesta
sarakkeesta muodostetaan vähintään yksi testitapaus.
Spesifikaation tarkkaan analyysiin perustuva syy-seuraus-mallinnus on työläs prosessi mutta sen
hyödyllinen sivuvaikutus on, että spesifikaatiossa olevat puutteet ja monitulkintaisuudet tulevat hyvin
esiin (Myers 1979, 71). Menetelmän työvaiheita helpottaa mallinnustyökalu, jonka avulla esimerkiksi
päätöstaulu voidaan generoida suoraan kaavion syy-seuraussuhteista.
41
Päätöstauluihin perustuvaa testausta voidaan hyödyntää kaikissa tilanteissa, joissa ohjelman
toiminta riippuu erilaisista syötevaihtoehdoista ja niiden kombinaatioista. Seuraavassa esimerkissä
muodostetaan päätöstaulu verkkokaupan asiakkaille myönnettävistä alennuksesta.
Esimerkki 5.
Verkkokaupan asiakkaalle lasketaan alennus tilauksen loppusummasta riippuen ostosumman
suuruudesta, ostohetkestä ja asiakkuudesta.
1) Uusi asiakas, joka rekisteröityy järjestelmään saa ostosummasta riippumatta 25 %
alennuksen tilauksen loppusummasta.
2) Kanta-asiakas, joka on jo rekisteröitynyt verkkokaupan asiakkaaksi saa ostosummasta
riippuvan alennuksen seuraavien ehtojen mukaisesti:

ostosumma >= 50 Euroa → alennus 20 Euroa

ostosumma >= 120 Euroa → alennus 50 Euroa

ostosumma >= 250 Euroa → alennus 100 Euroa
3) Lisäksi kaikille asiakkaille tarjotaan vaihtoehtona (etuja ei voi yhdistää) 30 % alennusta
kaikista viikonloppuna tehdyistä tilauksista.
Päätöstaulu muodostetaan sijoittamalla ensin ehdot riveille allekkain ja niiden perään päätöstulosten
eri vaihtoehdot kukin omalle rivilleen. Yo. määrittelyn perusteella muodostetaan mahdolliset syötekombinaatiot ja määritellään odotetut lopputulokset.
Ehdot
Uusi asiakas
Syötteet
x
x
x
x
x
x
Kanta-asiakas
50<= ostosumma < 120
x
x
120 <= ostosumma < 250
x
x
-
x
x
x
x
x
Ostosumma >= 250
Viikonloppuetu
x
-
42
x
x
x
-
x
-
x
x
x
x
x
-
x
x
x
x
x
-
Päätösvaihtoehdot
Päätöstulokset
Alennus 25 %
Alennus 30 %
x
x
x
x
x
x
Alennus 20 Euroa
x
x
x
x
Alennus 50 Euroa
x
Alennus 100 Euroa
x
Kaikkien mahdollisten syöte- ja lopputulosvaihtoehtojen testaaminen edellyttäisi, että jokaiselle päätöstaulun sarakkeelle kehitettäisiin ainakin yksi testitapaus.
Seuraavassa on esitetty esimerkkinä sarakkeista 1,2,7 ja 10 muodostetut testitapaukset.
Testi 1
(sarake 1)
Syöte:
uusi asiakas, ostosumma 50 Euroa, viikonloppuetu kyllä
Odotettu lopputulos:
alennus 30 %
Testi 2
(sarake 2)
Syöte:
uusi asiakas, ostosumma 50 Euroa, viikonloppuetu ei
Odotettu lopputulos:
alennus 25 %
Testi 3
(sarake 7)
Syöte:
kanta-asiakas, ostosumma 50 Euroa, viikonloppuetu kyllä
Odotettu lopputulos:
alennus 30 %
Testi 4
(sarake 10)
Syöte:
kanta-asiakas, ostosumma 150 Euroa, viikonloppuetu ei
Odotettu lopputulos:
alennus 50 Euroa
43
Tilasiirtymätestaus
Tilasiirtymätestaus (state transition testing) on menetelmä, jossa testitapausten suunnittelussa
hyödynnetään järjestelmän kuvauksessa käytettyjä tilakaavioita ja matriisiesityksiä. Tilakaaviossa
(käytetään myös termiä tilakone) ohjelman tai järjestelmän toiminta on kuvattu erilaisina tiloina ja
niiden välisinä siirtyminä. Tyypillisiä tilakaavioilla mallinnettavia kohteita ovat mm. sulautetut järjestelmät ja tietoliikenneprotokollat.
Tilasiirtymämatriisi on tilakaavion taulukkomuotoinen esitystapa, joka on hyödyllinen silloin, kun tiloja ja tilojen välisiä siirtymiä on paljon. Matriisimuodosta on helpompi tarkistaa, että kaikki mahdolliset tilat ja tapahtumat on otettu huomioon. Matriisi voi myös paljastaa mahdollisia epäkelvollisia
tilojen välisiä siirtymiä.
Tilasiirtymätestauksessa matriiseja voidaan käyttää monipuolisesti erilaisten testitapausten generoimiseen. Testit voidaan suunnitella kattamaan jokainen tila ja siirtymä tai testaus voidaan kohdentaa tiettyyn tilasiirtymäjaksoon, siirtymien sarjoihin tai epäkelvollisten siirtymien tarkasteluun
(Haikala & Märijärvi 2002, 140-142).
Käyttötapaustestaus
Käyttötapaustestaus (use case testing, scenario-based testing) on mustalaatikkotestauksen menetelmä, jossa testitapaukset johdetaan järjestelmän toimintaa kuvaavista käyttäjäskenaarioista
(käyttötapauksista). Käyttäjäskenaariot ovat tapahtumasarjoja, joilla kuvataan järjestelmän ja sen
eri käyttäjien välinen vuorovaikutus. Käyttötapauskuvauksia voidaan hyödyntää sekä järjestelmän
käyttäjävaatimusten että käyttäjädokumentaation testauksessa. (Pressman 2005, 412-413).
Kokemukseen perustuvat menetelmät
Systemaattisesti toteutettavien ja siten myös paljon aikaa ja työtä vaativien menetelmien lisäksi
testauksessa voidaan käyttää enemmän intuitiivista lähestymistapaa ja hyödyntää kokemuksella
hankittua tietoa. Kokemusperusteista testausta sovelletaan kaikilla testauksen tasoilla ja erityisesti
tilanteissa, joissa määrittelypohjainen testaus ei ole mahdollista esim. rajallisten resurssit, tiukka
aikataulu tai puutteellinen dokumentaatio.
Virheenarvaus
Virheenarvaus (error guessing) on menetelmä, jossa testaajat ennakoivat mahdollisia virheitä ja
virhealttiita tilanteita. Testitapausten kehittäminen perustuu virhelistaan, joka on koottu aiempien
havaintojen ja testauksessa kerätyn tiedon perusteella. Tiedonlähteenä voivat olla esimerkiksi
yleisesti
tunnetut
tyypilliset
ohjelmointivirheet,
ohjelmasta jo
löydetyt
virheet,
aiempien
testausprosessien vika- ja häiriölokit tai ohjelmakoodin monimutkaisuudesta ja virhealttiudesta tehty
44
analyysi. Virheenarvaus on hyvä keino täydentää testikattavuutta tapauksilla, joita muun testauksen
yhteydessä ei ole riittävästi huomioitu esim. helpot ja itsestäänselvyyksinä pidetyt tapaukset,
reaalimaailmassa mahdottomat tapaukset, poikkeusten käsittely jne. (Myers ym. 2012, 81).
Tutkiva testaaminen
Tutkiva testaaminen (exploratory testing) on toinen yleisesti käytetty testausmuoto, joka perustuu
todennäköisten ongelmakohtien tutkimiseen. Erityistä tutkivassa testaamisessa on, että testien
suunnittelu ja suorittaminen tehdään samalla, kun perehdytään ohjelman toimintaan ja toteutukseen (Kasurinen 2013, 74). Menetelmä soveltuu tilanteisiin, joissa riittävää lähdedokumentaatiota
testitapausten kehittämiseen ei ole saatavilla tai kun halutaan täydentää testausta testitapauksilla,
joiden kehittämiseen formaalit menetelmät eivät sovellu.
Savutestaus
Savutestaus (smoke testing) on menetelmä, jossa perusasioiden toimivuutta testaamalla selvitetään ohjelman laadullista tasoa ja valmiutta perusteellisempaan testaukseen. Savutestausta voidaan hyödyntää kaikilla testauksen tasoilla. Esim. ketterien menetelmien yhteydessä savutestausta voidaan tehdä jokaiselle kehitetylle ohjelman tai sen osan versiolle (daily build testing). (Kasurinen 2013, 72-73; Pressman 2005, 369-370).
45
Luku 5 Testauksen työkalut
Testausprosessin työvaiheita ja toimintoja voidaan helpottaa monilla erilaisilla työkaluilla, joita on
saatavilla sekä kaupallisina tuotteina että ilmaisohjelmistoina. Useimmat ilmaiset työkalut ovat
avoimen lähdekoodin ohjelmistoja, jolloin niitä voidaan muokata, kehittää ja laajentaa omiin tarpeisiin sopivaksi. Kaupallisiin testausohjelmistoihin verrattuna vapaiden tai ilmaisten ohjelmien haittana on usein työläämpi käyttöönotto, vaillinaisemmat toiminnallisuudet sekä hankala ja osin mahdoton työkalujen yhteensovittaminen.
Työkalujen valikoima ja kirjo on laaja, joten työkaluihin perehtyminen ja sopivan työkalupakin kokoaminen vaatii melko paljon aikaa ja vaivannäköä. Työkalujen valinnassa tuleekin pohtia mikä on
todellinen tarve ja työkaluista saatava hyöty suhteessa työmäärään ja kustannuksiin, joita työkalujen hankinnasta, ylläpidosta ja käyttöönotosta aiheutuu. Seuraavat kappaleet esittelevät lyhyesti
testauksen työkalutukea ja esimerkkejä avoimen lähdekoodin tarjonnasta. Lähteenä on käytetty
opensourcetesting.org-sivustoa (http://www.opensourcetesting.org).
Testausprosessin hallintaan liittyvät työkalut
Testauksenhallinnan työkalut helpottavat testauksen organisointia, seurantaa ja dokumentointia.
Moniin hallintajärjestelmiin on yhdistetty ominaisuuksia sekä laadunhallinnan että testaustyön tarpeisiin, jolloin ne toimivat yhteisenä työympäristönä sekä projektin johdolle että testaustiimin jäsenille. Testausprosessissa tuotettua tietoa voidaan tallentaa ja muokata hallintajärjestelmän kautta
ja jakaa usean käyttäjän kesken. Esimerkiksi dokumenttien laatiminen on keskeinen testaustyöhön
liittyvä toimenpide, jota voidaan helpottaa valmiiksi muotoiluilla dokumenttipohjilla. Muita tyypillisiä
toimintoja ja tehtäviä, joihin hallintatyökalut tarjoavat apua ovat testitapausten ja testijoukkojen
suunnittelu ja ylläpito, testitulosten analysointi, virheiden ja testitulosten raportointi sekä testaustyön mittaaminen ja seuranta.
Esimerkkejä monipuolisista testauksenhallinnan ilmaisohjelmistoista ovat:

Fitnesse

Salome-TMF

Tarantula
Tarjolla on myös useita web-sovelluksia, jotka mahdollistavat joustavan työskentelyn erilaisissa
käyttötilanteissa esim. toimiston ulkopuolella. Tällaisia ovat esim. Test Case Web (TCW), Testcube ja RTH (asennetaan LAMP-alustalle).
46
Monet testauksen työkalut ovat osia samasta työkalukokonaisuudesta, josta valitsemalla voidaan
rakentaa sopiva työkalupaketti tilanteen ja tarpeen mukaan. Esimerkkinä laajennettavasta työkalupaketista on Bugzilla-vianhallintajärjestelmä, johon voidaan asentaa erillinen Testopia-lisämoduuli
testitapausten hallintaa varten. Muita erillisiä vikatietokantoja ovat mm. Anthill Bug Manager,
GNATS ja Mantis, jotka soveltuvat myös useimmille eri alustoille (Windows, Unix ja MacOS).
Staattisen testauksen työkalut
Staattinen analysointi on tärkeä laaduntarkastusmenetelmä, jossa koodin oikeellisuutta ja rakennetta tutkitaan ohjelmallisen analyysin avulla. Ohjelmakoodia analysoimalla saadaan myös tietoa
ohjelman loogisesta kompleksisuudesta ja virhealttiudesta. Koodianalysaattoreita on kehitetty runsaasti eri ohjelmointikieliä varten. Myös monet sovelluskehittimet sisältävät staattisia ohjelmakoodin tarkastus- ja analysointitoimintoja kuten esim. monikielinen kehitysympäristö Eclipse.
Eri kielille soveltuvia vapaan lähdekoodin koodianalysaattoreita ovat:
C/C++

Splint

FramaC

CppCheck
Java

Jlint

JCSC

PMD
Python

Pylint
PHP

RIPS
Dynaamisen testauksen työkalut
Dynaamisen testauksen toteuttaminen edellyttää ympäristöä, jossa ohjelmakoodia voidaan ajaa.
Dynaamisen testauksen työkalut simuloivat tarvittaessa testattavan koodin suoritusympäristöä ja
mahdollistavat testauksen automatisointia. Lisäksi dynaamisen analyysin työkaluilla voidaan arvioida ohjelman ajonaikaista toiminta- ja suorituskykyä.
47
Yksikkötestauksen työkalut
Yksikkötestauksessa ohjelmaa testataan moduuleina, joiden suoritusympäristöksi tarvitaan testipeti eli testiajureita ja sijaiskomponentteja. Yksikkötestauksen työkalut tarjoavat testausympäristön,
jossa voidaan kehittää ja suorittaa tarvittavia testifunktioita sekä tallentaa testit ja testien tulokset
myöhempää käyttöä ja analysointia varten. Useimmat yksikkötestauksen työkalut perustuvat xUnitarkkitehtuuriin, jossa testausympäristönä on ns. testikehys. Testikehykset mahdollistavat testitapausten systemaattisen organisoinnin, jolloin toisistaan riippuvat testitapaukset voidaan ryhmitellä
testijoukkoihin (test suite) ja suorittaa määritellyn testiproseduurin mukaisessa järjestyksessä. Testikehykset sisältävät tyypillisesti myös valmiita assert-funktioita, joita käytetään testin todellisen tuloksen ja odotetun lopputuloksen vertaamiseen.
Yksikkötestauksen työkalut valitaan käytettävän ohjelmointikielen mukaan. Moniin kehitysympäristöihin sisältyy tuki yksikkötestausta varten mutta työkaluja voidaan helposti asentaa myös erillisinä
kirjastoina ja ohjelmistokehyksinä.
Esimerkkejä yksikkötestauksen työkaluista eri kielille ovat:
C/C++

CUnit

CppUnit

CppTest
Java

JUnit

Emma (työkalu koodikattavuuden mittaamiseen)

Jester (täydentävä työkalu, jolla löydetään vielä testaamaton koodi)
Python

PyUnit (moduuli sisältyy Pythonin standardikirjastoon)

Pester (täydentävä työkalu, jolla löydetään vielä testaamaton koodi)
PHP

PHPUnit
48
Toiminnallisen testauksen työkalut
Ohjelman toiminnallisen testauksen työkalut tarjoavat automatisoituja toimintoja graafisen käyttöliittymän testaukseen, ohjelmointirajapintojen tarkastukseen (API compatibility), testitapausten automaattiseen generoimiseen, testien tallentamiseen ja testitulosten analysointiin. Testaustyökaluja
on tarjolla erityyppisten ja eri alustoille rakennettujen järjestelmien testaamiseen, joiden avulla testausta voidaan kohdentaa sovelluksen erityispiirteiden mukaisesti esim. web-sovellukset, tietokantasovellukset, hajautetut järjestelmät, sulautetut ohjelmistot, tietoliikenneohjelmisot jne.
Esimerkkejä toiminnallisen testauksen työkaluista ovat:

ABI Compliance Checker (C/C++ API rajapintojen testaukseen)

Arbiter (Hyväksymistestauksen automatisointi Word- ja RTF-dokumenttien pohjalta)

Avingon (Hyväksymistestauksen automatisointi XML-dokumenttien pohjalta)

Behat (Käyttäjäskenaarioihin perustuva testaustyökalu)

Concordion (Käyttäjäskenaarioihin perustuva testaustyökalu Java-ohjelmien testaamiseen)

Cucumber (Toiminnallisen testauksen automatisointi tekstidokumenttien pohjalta)

DBSanity (Työkalu tietokantojen testaukseen)

Doit (web-sovellusten testityökalu)

Eclipse Jubula (Työkalu Javalla toteutetun käyttölittymän testaukseen)

JFunc (Toiminnallisen testauksen laajennos JUnit-testauskehykseen)

TextTest (Sovellusriippumaton työkalu testauksen automatisointiin tekstitiedostojen pohjalta)

Toster (The Object-oriented Sofware Testing Environment on alustariippumaton testausympäristö, jossa voidaan hyödyntää UML-kuvauksia testitapausten generoimiseen)

XML Test Suite (web-sovellusten testityökalu)
49
Suorituskykytestauksen työkalut
Suorituskykyanalysaattoreilla tutkitaan ohjelman ajonaikaista suorituskykyä ja resurssien käyttöä.
Järjestelmätestauksessa pyritään selvittämään suorituskykyyn vaikuttavia pullonkauloja. Moduulitestauksessa voidaan tarkastella myös ohjelmanosien suorittamiseen käytettyä prosessointiaikaa
sekä ohjelmanosien suoritustiheyttä. Testausympäristöt mahdollistavat käyttötilanteiden simuloimisen erilaisilla kuormituksilla (käyttäjämäärät, tietokantaoperaatiot, käsiteltävän datan määrä), joiden vaikutuksia (vastausaikoja, läpimenoaikoja, muistin käyttöastetta) mitataan ohjelman käytön
aikana. Tyypillisiä analysaattoreilla havaittavia ongelmia ovat esimerkiksi muistivuodot, joiden seurauksena ohjelman käytettävissä olevan (RAM) muistin määrä vähenee. Muistin vähenemisen seurauksena vastausajat hidastuvat ja ajan mittaan se voi johtaa myös ohjelman kaatumiseen. Muistivuotoja esiintyy tyypillisesti C- ja C++- kielillä toteutetuissa ohjelmissa, jossa muuttujalle dynaamisesti varattua muistia ei vapauteta käytön jälkeen.
Esimerkkejä suorituskykytestauksen työkaluista ovat:

Apache Jmeter (kuormitus ja suorituskykytestauksen työkalu)

FunkLoad (toiminnallisen ja kuormitustestauksen työkalu web-sovelluksille)

OpenWebLoad (suorituskyky- ja kuormitustestauksen työkalu web-sovelluksille)

Valgrind (dynaamisten analyysin työkalu C/C++ -kielisille ohjelmille Linux-ympäristöön)
Tietoturvatestauksen työkalut
Tietoturvatestauksen tarkoituksena on todentaa tietoturvatoimintojen kykyä torjua tietoturvaan kohdistuvia uhkia. Tietoturvatestauksen työkalut mahdollistavat testihyökkäysten simuloimisen, testihyökkäysten tulosten tarkastamisen, tietoturva-aukkojen tunnistamisen sekä ohjelman yleisen tietoturvatason tarkastamisen.
Esimerkkejä tietoturvatestauksen työkaluista ovat:

Nessus (monipuolinen työkalu ohjelmistojen, tietoliikenneyhteyksien, tietokantojen ja erilaisten laitteiden tietoturva-aukkojen tunnistamiseen)

Wireshark (tietoliikenteen analyysi- ja vianmääritystyökalu)

Vega (web-sovellusten tietoturvatestauksen työkalu)
50
Testiaineistogeneraattorit
Testiaineistogeneraattoreilla voidaan luoda automaattisesti ohjelman tarvitsemaa dataa kuten tietokantaan tallennettavia tietoja ja testisyötteitä. Automaattinen generointi perustuu tyypillisesti käyttäjän määrittelemään tiedon muotoon ja määrään, jonka mukaisesti generaattori tuottaa sopivaa testiaineistoa.
Esimerkkejä testiaineistogeneraattoreista ovat:

Mockaroo (työkalu CSV-, JSON-, SQL- ja Excel- muotoisen testidatan generoimiseen)

Databene Benerator (työkalu tietokantojen, teksti- ja binäärimuotoisten tiedostojen, sekä
XML-, CSV-, Excel-muotoisen testidatan generoimiseen)
51
Lähteet
Beizer Boris, Software Testing Techniques, International Thomson Computer Press, Boston, USA,
1990.
Haikala, I., Märijärvi, J., Ohjelmistotuotanto, Talentum Media Oy, Pieksämäki, Suomi, 2002.
IEEE 610.12-1990, Standard Glossary of Software Engineering Terminology, IEEE Computer
Society, 1990.
IEEE 829-2008, Standard for Software Test Documentation, IEEE Computer Society, 2008.
Kaner, C., Falk, J., Nguyen, H. Q., Testing Computer Software, 2nd edition, John Wiley & Sons,
Inc., New York, USA, 1999.
Kaner, C., Bach, J., Pettichord, B., Lessons Learned in Software Testing, John Wiley & Sons, Inc.,
New York, USA, 2002.
Kasurinen Jussi, Ohjelmistotestauksen käsikirja, Docendo Oy, Jyväskylä, Suomi, 2013.
Kit, E., Software Testing in the Real World Improving the Process, ACM Press, Inc., USA, 1995.
Myers Glenford J., The Art of Software Testing, John Wiley & Sons Inc., New York, USA 1979.
Pressman, Roger S, Software Engineering A Practitioner`s Approach, 6th edition, McGraw-Hill Inc.,
New York, USA, 2005.
52
Liite 1. Testaustermien suomi-englanti sanasto
Tähän liitteeseen on koottu suomi-englanti sanasto oppaassa esitetyistä testauksen termeistä.
Asennettavuustestaus
Installability testing
Asennustestaus
Installation testing
Dynaaminen testaus
Dynamic testing
Ehtokattavuus
Condition coverage
Ekvivalenssiositus
Equivalence partitioning
Haarakattavuus
Branch coverage
Hyväksymistestaus
Acceptance testing
Häiriö
Failure
Integraatiotestaus
Integration testing
Järjestelmätestaus
System testing
Kelpoistaminen, validointi
Validation
Kertarysäys
Big-bang
Kokoava integraatio
Bottom-up integration
Koodikattavuus
Code coverage
Kuormitustestaus
Load/Volume testing
Käytettävyystestaus
Usability testing
Käyttäjädokumentaation testaus
User dokumentation testing
Käyttötapaustestaus
Use case testing
Lasilaatikkotestaus
Glass-box testing
Lausekattavuus
Statement coverage
Luotettavuustestaus
Reliabilty testing
Moduulitestaus
Module testing
Moniehtokattavuus
Multiple-condition coverage
Mustalaatikkotestaus
Black-box testing
Osittava integraatio
Top-down integration
Peruspolkutestaus
Basic path testing
53
Polkutestaus
Path testing
Päätöskattavuus
Desicion coverage
Raja-arvoanalyysi
Boundary-value analysis
Rakenteellinen testaus
Structural testing
Savutestaus
Smoke testing
Staattinen testaus
Static testing
Stressitestaus
Stress testing
Suorituskykytestaus
Performance testing
Syy-seuraus-mallinnus
Cause-effect graphing
Testiajuri
Test driver
Testikattavuus
Test coverage
Testipeti, testikehys
Test bed
Testitapaus
Test case
Testitynkä
Test stub
Tietoturvatestaus
Security testing
Tilasiirtymätestaus
State transition testing
Todentaminen, verifiointi
Verification
Toiminnallinen testaus
Functional testing
Toipuvuustestaus
Recovery testing
Tutkiva testaaminen
Exploratory testing
Uudelleentestaus
Regression testing
Vaiheittainen integraatio
Incremental integration
Valkolaatikkotestaus
White-box testing
Virhe, erehdys
Error, mistake
Virhe, vika
Error, bug, defect, fault
Virheenarvaus
Error guessing
Virheenjäljittäjä
Debugger
Virheenjäljitys
Debugging
54
Voileipä integraatio
Sandwich integration
Yhteensopivuustestaus
Compatibility testing
Ylläpitotestaus
Maintenance testing
55
Liite 2: Testaussuunnitelma
Tämä liite sisältää dokumenttipohjan testaussuunnitelmasta, joka perustuu IEEE 829-2008 standardiin.
Projektin nimi
Testaussuunnitelma
versio 1.0
56
1Versiohistoria ................................................................................................................................ 2
2Johdanto ....................................................................................................................................... 3
2.1Dokumentin tarkoitus.............................................................................................................. 3
2.2Viittaukset muihin dokumentteihin .......................................................................................... 3
2.3Testauksen kohde .................................................................................................................. 3
3Testausympäristö ja työkalut ......................................................................................................... 3
3.1Laiteet ja ohjelmistot .............................................................................................................. 3
3.2Testauksen työkalut ............................................................................................................... 3
3.2.1Työkalujen käyttöönotto ja ohjeistus ................................................................................ 3
4Henkilöstö- ja osaamisvaatimukset ............................................................................................... 3
5Testausstrategia ........................................................................................................................... 3
5.1Testauksen prosessimalli ja työvaiheet .................................................................................. 3
5.2Testauksen organisointi ......................................................................................................... 3
5.3Testauksen seuranta .............................................................................................................. 4
5.4Standardit ja yleiset käytännöt................................................................................................ 4
5.5Testauksen kriteerit ................................................................................................................ 4
5.5.1Aloitusehdot .................................................................................................................... 4
5.5.2Keskeytys- ja jatkamisehdot ............................................................................................ 4
5.5.3Lopetusehdot .................................................................................................................. 4
6Testattavat toiminnot ja ominaisuudet ........................................................................................... 4
7Ei-toiminnallisten ominaisuuksien testaus ..................................................................................... 4
8Ominaisuudet, joita ei testata ........................................................................................................ 4
9Regressiotestaus .......................................................................................................................... 4
10Testauksen rajoitteet ................................................................................................................... 5
11Testaukseen liittyvät riskit ja niiden hallinta ................................................................................. 5
12Testauksen aikataulu ja työmääräarvio ....................................................................................... 5
13Testauksen hyväksyntä ja päättäminen ...................................................................................... 5
57
1 Versiohistoria
Versio
Päiväys
Tekijä
Tila/toimenpiteet
1.0
58
2 Johdanto
2.1 Dokumentin tarkoitus
Tähän kuvataan tämän dokumentin tarkoitus, laajuus ja tavoitteet.
2.2 Viittaukset muihin dokumentteihin
Tässä kappaleessa kuvataan testaussuunnitelman yhteydet muihin dokumentteihin, kuten projektisuunnitelmaan, ohjelmiston määrittely- ja suunnitteludokumentaatioon, testauksessa käytettäviin
standardeihin ja ohjeistuksiin sekä muihin testauksen dokumentteihin kuten testitapausten ja testiproseduurin määrittelyihin.
2.3 Testauksen kohde
Tässä kuvataan testauksen kohde eli ohjelma, ohjelmistotuote tai järjestelmä.
3 Testausympäristö ja työkalut
3.1 Laiteet ja ohjelmistot
Tässä kuvataan testausympäristössä käytettävät laiteet ja ohjelmistot versiotietojen tarkkuudella.
3.2 Testauksen työkalut
Tässä luetellaan testausympäristön rakentamiseen ja testaustyöhön liittyvät työkalut kuten testikehykset, simulaattorit, testiaineistogeneraattorit jne.
4 Henkilöstö- ja osaamisvaatimukset
Tähän listataan testaushenkilöstö. Lisäksi tässä osiossa määritellään osaamisvaatimukset, jotka
liittyvät testattavaan ohjelmistoon, testauksen eri työtehtäviin, menetelmiin ja työkaluihin. Henkilöiden osaamistason perusteella määritellään tarve lisäkoulutukseen ja perehdytykseen.
5 Testausstrategia
5.1 Testauksen prosessimalli ja työvaiheet
59
Tässä määritellään mitä prosessimallia testauksessa käytetään. Mallin valinta perustuu tavallisesti
ohjelmiston elinkaarimalliin. Lisäksi tässä määritellään testauksen työvaiheet eli testaustasojen
mukainen testauksen suunnittelu ja suorittaminen. Jos testaus on laaja, dokumentointia voidaan
selkeyttää laatimalla erillisiä vaihekohtaisia suunnitelmia, joihin tässä dokumentissa viitataan.
5.2 Testauksen organisointi
Testauksen organisointimalli määrittelee mm. käytetäänkö testaukseen kehitysorganisaation ulkopuolista asiantuntemusta ja onko testauksen riippumattomuudelle erityisiä vaatimuksia. Testauksen organisointiin vaikuttaa testaustaso esim. moduulitestausta tekevät usein kehittäjät ja järjestelmätestausta riippumaton testaustiimi, jonka jäsenet ovat testaukseen erikoistuneita ammattilaisia.
5.3 Testauksen seuranta
Tähän määritellään kuinka testausprosessin etenemistä seurataan (laadunvalvonta) ja mitä mittareita käytetään.
5.4 Standardit ja yleiset käytännöt
Tässä selvitetään mitä standardeja testaustyössä noudatetaan sekä yleiset käytännöt, jotka liittyvät
esim. tietoturvaan, dokumentointiin, raportointiin ja ohjeistuksiin.
5.5 Testauksen kriteerit
5.5.1 Aloitusehdot
Tähän listataan mitä vaatimuksia ja esiehtoja testauksen aloittamiselle on (esim. tuote on valmis
testattavaksi, lähdedokumentaatio on katselmoitu, testausympäristö on valmis jne.)
5.5.2 Keskeytys- ja jatkamisehdot
Tässä määritellään millä ehdoilla testaus voidaan keskeyttää ja millä ehdoilla keskeytynyttä testausta voidaan jatkaa.
5.5.3 Lopetusehdot
Tähän määritellään testauksen lopetusehdot esim. saavutettu kattavuus ja laatutaso, aikaraja jne.
6 Testattavat toiminnot ja ominaisuudet
Tähän luetellaan kaikki ominaisuudet (käyttäjävaatimukset) ja toiminnot (toiminnalliset vaatimukset), jotka testataan.
7 Ei-toiminnallisten ominaisuuksien testaus
60
Tähän määritellään mitä laadullisia ominaisuuksia testattavasta ohjelmasta tarkastellaan esim.
suorituskyky, luotettavuus, tietoturva, asennettavuus, käytettävyys jne.
8 Ominaisuudet, joita ei testata
Tässä luetellaan ne toiminnot ja ominaisuudet, joita tämän suunnitelman mukaisesti ei tulla testaamaan.
9 Regressiotestaus
Tähän määritellään kuinka menetellään korjaus ja muutostoimenpiteiden jälkeen.
10 Testauksen rajoitteet
Tässä kuvataan testausta rajoittavia tekijöitä esim. puuttuvat osat, tietoturvarajoitteet, resurssirajoitteet ym.
11 Testaukseen liittyvät riskit ja niiden hallinta
Tähän kuvataan testausprojektiin liittyvät riskit sekä menettelytavat, joilla niihin varaudutaan.
12 Testauksen aikataulu ja työmääräarvio
Tässä määritellään testauksen aikataulu ja työnjako sekä projektin tarkastuspisteet kuten deadlinepäivämäärät ja katselmoinnit.
13 Testauksen hyväksyntä ja päättäminen
Suunnitelman loppuun määritellään testauksen päättämistehtävät kuten testauksen arviointi, vaadittavat tuotokset ja hyväksymiskriteerit.
61
Liite 3: Vaihekohtainen testaussuunnitelma
Tämä liite sisältää dokumenttipohjan vaihekohtaisesta testaussuunnitelmasta. Dokumentti perustuu IEEE 829-2008 standardiin.
Projektin nimi
Vaihekohtainen testaussuunnitelma
versio 1.0
62
Sisällysluettelo
1
Versiohistoria ......................................................................................................................... 66
2
Dokumentin tarkoitus ............................................................................................................. 67
3
Moduulitestaus....................................................................................................................... 67
4
3.1
Testauksen tavoitteet ...................................................................................................... 67
3.2
Rajoitteet ja riskit ............................................................................................................ 67
3.3
Testattavat moduulit........................................................................................................ 67
3.4
Moduulit, joita ei testata .................................................................................................. 67
3.5
Testauksen lähestymistavat ja menetelmät..................................................................... 67
3.6
Testauksen kriteerit ........................................................................................................ 67
3.6.1
Ehdot testauksen aloittamiselle................................................................................ 67
3.6.2
Ehdot testauksen keskeyttämiselle ja jatkamiselle ................................................... 68
3.6.3
Ehdot testauksen lopettamiselle .............................................................................. 68
3.7
Testauksen tuotokset ...................................................................................................... 68
3.8
Testausympäristö ja työkalut........................................................................................... 68
3.9
Henkilöstö- ja osaamisvaatimukset ................................................................................. 68
3.10
Testauksen hyväksyntä .................................................................................................. 68
Integrointitestaus ................................................................................................................... 68
4.1
Testauksen tavoitteet ...................................................................................................... 68
4.2
Rajoitteet ja riskit ............................................................................................................ 68
4.3
Testauksen kohteet ja osa-alueet ................................................................................... 68
4.4
Testattavat toiminnot ja ominaisuudet ............................................................................. 69
4.5
Toiminnot ja ominaisuudet, joita ei testata ...................................................................... 69
4.6
Testauksen lähestymistavat ja menetelmät..................................................................... 69
4.7
Testauksen kriteerit ........................................................................................................ 69
4.7.1
Ehdot testauksen aloittamiselle................................................................................ 69
4.7.2
Ehdot testauksen keskeyttämiselle ja jatkamiselle ................................................... 69
63
4.7.3
5
6
Ehdot testauksen lopettamiselle .............................................................................. 69
4.8
Testauksen tuotokset ...................................................................................................... 69
4.9
Testausympäristö ja työkalut........................................................................................... 70
4.10
Henkilöstö- ja osaamisvaatimukset ................................................................................. 70
4.11
Testauksen hyväksyntä .................................................................................................. 70
Järjestelmätestaus ................................................................................................................. 70
5.1
Testauksen tavoitteet ...................................................................................................... 70
5.2
Rajoitteet ja riskit ............................................................................................................ 70
5.3
Testauksen kohteet ja osa-alueet ................................................................................... 70
5.4
Testattavat toiminnot ja ominaisuudet ............................................................................. 70
5.5
Toiminnot ja ominaisuudet, joita ei testata ...................................................................... 70
5.6
Testauksen lähestymistavat ja menetelmät..................................................................... 70
5.7
Testauksen kriteerit ........................................................................................................ 71
5.7.1
Ehdot testauksen aloittamiselle................................................................................ 71
5.7.2
Ehdot testauksen keskeyttämiselle ja jatkamiselle ................................................... 71
5.7.3
Ehdot testauksen lopettamiselle .............................................................................. 71
5.8
Testauksen tuotokset ...................................................................................................... 71
5.9
Testausympäristö ja työkalut........................................................................................... 71
5.10
Henkilöstö- ja osaamisvaatimukset ................................................................................. 71
5.11
Testauksen hyväksyntä .................................................................................................. 71
Hyväksymistestaus ................................................................................................................ 71
6.1
Testauksen tavoitteet ...................................................................................................... 71
6.2
Rajoitteet ja riskit ............................................................................................................ 72
6.3
Testattavat ominaisuudet ................................................................................................ 72
6.4
Ominaisuudet, joita ei testata .......................................................................................... 72
6.5
Testauksen organisointi ja menettelytavat ...................................................................... 72
6.6
Testauksen kriteerit ........................................................................................................ 72
6.6.1
Ehdot testauksen aloittamiselle................................................................................ 72
6.6.2
Ehdot testauksen keskeyttämiselle ja jatkamiselle ................................................... 72
64
6.6.3
Ehdot testauksen lopettamiselle .............................................................................. 72
6.7
Testauksen tuotokset ...................................................................................................... 72
6.8
Testausympäristö ja työkalut........................................................................................... 72
6.9
Henkilöstö- ja osaamisvaatimukset ................................................................................. 72
6.10
Testauksen hyväksyntä .................................................................................................. 72
65
Versiohistoria
Versio
Päiväys
Tekijä
Tila/toimenpiteet
1.0
66
Dokumentin tarkoitus
Tähän kuvataan mitä dokumentti sisältää ja kenen käyttöön se on tarkoitettu.
Viittaukset muihin dokumentteihin
Tässä kappaleessa luetellaan dokumentit, joihin tässä dokumentissa viitataan.
Esim.

Ohjelmiston projektisuunnitelma

Testauksen pääsuunnitelma

Ohjelmiston vaatimusmäärittely

Ohjelmiston toiminnallinen määrittely

Moduulien suunnitteluspesifikaatiot

Laatujärjestelmän ohjeistus

Standardit
Moduulitestaus
13.1 Testauksen tavoitteet
13.2 Rajoitteet ja riskit
13.3 Testattavat moduulit
Tähän luetellaan testattavat moduulit ja kunkin moduulin testattavat osat ja toiminnot. Testauksen
kohteeseen lisätään viittaus lähdedokumenttiin, jossa moduulin vaatimukset on määritelty.
13.4 Moduulit, joita ei testata
Tähän luetellaan moduulit, joita ei testata. Lisäksi selvitetään syyt miksi kohteen testausta ei tehdä.
13.5 Testauksen lähestymistavat ja menetelmät
Tähän tarkennetaan mitä lähestymistapaa ja tekniikoita testien suunnittelussa ja suorituksessa
käytetään esim. staattinen analysointi, valkolaatikkotestaus, mustalaatikkotestaus, uudelleentestaus, automatisointi jne.
13.6 Testitapaukset
Tähän yksilöidään suunnitellut testitapaukset. Testitapaukselle määritellään tunniste ja lyhyt kuvaus mitä testitapauksella testataan.
13.7 Testauksen kriteerit
13.7.1 Ehdot testauksen aloittamiselle
67
Esim.




moduuli on valmis testattavaksi
lähdemateriaali (spesifikaatiot ja koodi) on tarkastettu ja saatavilla
testiympäristö on rakennettu
testityngät on kehitetty ja testattu
13.7.2 Ehdot testauksen keskeyttämiselle ja jatkamiselle
13.7.3 Ehdot testauksen lopettamiselle
Esim.





Koodikattavuudelle asetettu taso esim. 100 % lausekattavuus on saavutettu
Kaikki edellä listatut moduulit on testattu
Kaikki korkean prioriteetit testit on suoritettu onnistuneesti
Kaikki vakavat virheet on korjattu
Uudelleentestaus on suoritettu
13.8 Testauksen tuotokset
Tässä kuvataan mitä materiaalia testaustasolla tuotetaan.
Esim.






Testiskriptit
Testityngät
Testiloki
Virheraportit
Virheloki
Testausraportti
13.9 Testausympäristö ja työkalut
Tähän tarkennetaan testaustasolla käytettävä laite- ja ohjelmistokokoonpano sekä testaustason
työkalut. Tärkeää on kirjata tarkat tiedot laitteiden teknisistä tiedoista ja ohjelmistojen versioista.
13.10 Henkilöstö- ja osaamisvaatimukset
Tässä tarkennetaan testaushenkilöstön roolit, tehtävät ja vastuut. Osaamistason perusteella arvioidaan tarve lisäkoulutukseen.
13.11 Testauksen hyväksyntä
Tähän määritellään testauksen hyväksymiskriteerit ja henkilöt, jotka vahvistavat hyväksynnän.
Integrointitestaus
13.12 Testauksen tavoitteet
13.13 Rajoitteet ja riskit
13.14 Testauksen kohteet ja osa-alueet
68
Tässä kuvataan järjestelmään integroitavat osat ja ohjelmistokomponentit. Integraatio voi koostua
useasta tasosta, jossa integroitavia osa-alueita ovat ohjelmamoduulien integrointi, ulkoisten resurssien integrointi ja ylemmän tason järjestelmäintegraatio.
13.15 Testattavat toiminnot ja ominaisuudet
Tässä tarkennetaan integraatiossa testattavat toiminnot ja ominaisuudet. Esim. moduulien rajapinnat, kokoonpanon suorituskyky ja luotettavuustaso integraation eri vaiheissa jne.
13.16 Toiminnot ja ominaisuudet, joita ei testata
Tähän luetellaan toiminnot ja ominaisuudet, joita ei testata. Lisäksi selvitetään syyt miksi testausta
ei tehdä.
13.17 Testauksen lähestymistavat ja menetelmät
Tässä tarkennetaan mitä lähestymistapaa integraatiossa käytetään (vaiheittainen, ylhäältä alas,
alhaalta ylös, jonkin muu)
13.18 Testitapaukset
Tähän yksilöidään suunnitellut testitapaukset. Testitapaukselle määritellään yksilöllinen tunniste ja
lyhyt kuvaus mitä testitapauksella testataan.
13.19 Testauksen kriteerit
13.19.1 Ehdot testauksen aloittamiselle
Esim.



integroitava moduuli on testattu
testiympäristö on valmis
testiajurit ja tyngät on kehitetty ja testattu
13.19.2 Ehdot testauksen keskeyttämiselle ja jatkamiselle
13.19.3 Ehdot testauksen lopettamiselle
Esim.



Kaikki osat on integroitu järjestelmän eikä sijaiskomponentteja enää ole
Savutestaus ei tuo esille vakavia ongelmia
Suorituskyky ja luotettavuusvaatimukset täyttyvät
13.20 Testauksen tuotokset
Esim.




Testiskriptit
Testityngät
Testiloki
Virheraportit
69


Virheloki
Testausraportti
13.21 Testausympäristö ja työkalut
Tähän tarkennetaan testaustasolla käytettävä laite- ja ohjelmistokokoonpano sekä testaustason
työkalut. Tärkeää on kirjata tarkat tiedot laitteiden teknisistä tiedoista ja ohjelmistojen versioista.
13.22 Henkilöstö- ja osaamisvaatimukset
Tässä tarkennetaan testaushenkilöstön roolit, tehtävät ja vastuut. Osaamistason perusteella arvioidaan tarve lisäkoulutukseen.
13.23 Testauksen hyväksyntä
Tähän määritellään testauksen hyväksymiskriteerit ja henkilöt, jotka vahvistavat hyväksynnän.
Järjestelmätestaus
13.24 Testauksen tavoitteet
13.25 Rajoitteet ja riskit
13.26 Testauksen kohteet ja osa-alueet
Tähän kuvataan testattavat järjestelmän osat. Esim. MVC-arkkitehtuurissa testattavia kohteita ovat
tietokanta ja tiedot (model), käyttöliittymät (view), tiedonkäsittely-yksiköt (controller), palvelinpuolen
konfiguraatio, asiakassovelluksen konfiguraatio, verkkoliitynnät jne.
13.27 Testattavat toiminnot ja ominaisuudet
Tähän määritellään testattavat toiminnalliset ominaisuudet (käyttäjävaatimukset ja toiminnalliset
vaatimukset) sekä ei-toiminnalliset eli laadulliset vaatimukset kuten tietoturva, käytettävyys, suorituskyky, luotettavuus, asennettavuus ym. Testattaviin ominaisuuksiin lisätään viite lähdedokumenttiin, jossa kohteen vaatimukset on määritelty.
13.28 Toiminnot ja ominaisuudet, joita ei testata
Tähän luetellaan ominaisuudet, joita ei testata. Lisäksi selvitetään syyt miksi testausta ei tehdä.
13.29 Testauksen lähestymistavat ja menetelmät
Tähän tarkennetaan mitä lähestymistapaa/tapoja ja tekniikoita testien suunnittelussa ja suorituksessa käytetään esim. suunnitelmalähtöinen testaus, riskiperusteinen testaaminen, tutkiva testaaminen, dynaaminen analysointi, valkolaatikkotestaus, mustalaatikkotestaus, automatisointi jne.
13.30 Testitapaukset
70
Tähän yksilöidään suunnitellut testitapaukset. Testitapaukselle määritellään yksilöllinen tunniste ja
lyhyt kuvaus mitä testitapauksella testataan.
13.31 Testauksen kriteerit
13.31.1 Ehdot testauksen aloittamiselle
Esim.




järjestelmä on valmis testattavaksi eikä siinä ole enää sijaiskomponentteja
lähdemateriaali (määrittely- ja suunnitteluspesifikaatiot) on tarkastettu ja saatavilla
testiympäristö on rakennettu
testaushenkilöstön osaamistaso on varmistettu
13.31.2 Ehdot testauksen keskeyttämiselle ja jatkamiselle
13.31.3 Ehdot testauksen lopettamiselle
Esim.




Kaikki listatut toiminnot ja ominaisuudet on testattu
Ei-toiminnallisten ominaisuuksien laatutaso on saavutettu
Kaikki korkean prioriteetit testit on suoritettu onnistuneesti
Kaikki korkean prioriteetin virheet on korjattu ja regressiotestaus on suoritettu
13.32 Testauksen tuotokset
Tässä kuvataan mitä materiaalia testaustasolla tuotetaan.
Esim.





Testiloki
Virheraportit
Virheloki
Kattavuusmatriisi
Testausraportti
13.33 Testausympäristö ja työkalut
Tähän tarkennetaan testaustasolla käytettävä laite- ja ohjelmistokokoonpano sekä testaustason
työkalut
13.34 Henkilöstö- ja osaamisvaatimukset
Tässä tarkennetaan testaushenkilöstön roolit, tehtävät ja vastuut. Osaamistason perusteella arvioidaan tarve lisäkoulutukseen.
13.35 Testauksen hyväksyntä
Tähän määritellään testauksen hyväksymiskriteerit ja henkilöt, jotka vahvistavat hyväksynnän.
Hyväksymistestaus
13.36 Testauksen tavoitteet
71
13.37 Rajoitteet ja riskit
13.38 Testattavat ominaisuudet
Tähän määritellään testattavat ominaisuudet, jotka on määritelty käyttäjävaatimuksina asiakkaan
kanssa tehtyyn sopimukseen tai ohjelmiston vaatimusmäärittelyyn. Testattaviin ominaisuuksiin lisätään viite lähdedokumenttiin, josta vaatimusmäärittely löytyy.
13.39 Ominaisuudet, joita ei testata
Tähän luetellaan ominaisuudet, joita ei testata. Lisäksi selvitetään syyt miksi testausta ei tehdä.
13.40 Testauksen organisointi ja menettelytavat
Tähän tarkennetaan kuka, mitä, missä ja miten hyväksymistestaus suoritetaan.
13.41 Testitapaukset
Tähän yksilöidään suunnitellut testitapaukset. Testitapaukselle määritellään yksilöllinen tunniste ja
lyhyt kuvaus mitä testitapauksella testataan.
13.42 Testauksen kriteerit
13.42.1 Ehdot testauksen aloittamiselle
Esim.

järjestelmä on valmis ja se voidaan siirtää lopulliseen käyttöympäristöön
13.42.2 Ehdot testauksen keskeyttämiselle ja jatkamiselle
13.42.3 Ehdot testauksen lopettamiselle
13.43 Testauksen tuotokset





Testiloki
Virheraportit
Virheloki
Kattavuusmatriisi
Testauksen loppuraportti
13.44 Testausympäristö ja työkalut
Tähän tarkennetaan testaustasolla käytettävä laite- ja ohjelmistokokoonpano sekä testaustason
työkalut
13.45 Henkilöstö- ja osaamisvaatimukset
Tässä tarkennetaan testaushenkilöstön roolit, tehtävät ja vastuut. Osaamistason perusteella arvioidaan tarve lisäkoulutukseen.
13.46 Testauksen hyväksyntä
Tähän määritellään testauksen hyväksymiskriteerit ja henkilöt, jotka vahvistavat hyväksynnän.
72
73
Liite 4: Testitapauksen määrittely
Tämä liite sisältää mallin testitapauksen määrittelystä. Dokumentti perustuu IEEE 829-2008 standardiin.
Dokumentin tiedot
Versio
Päiväys
Tekijä
Tila
Testitapauksen tiedot
Testitapauksen tunniste
Prioriteetti
Testitapauksen kuvaus
Viittaukset vaatimuksiin
Testausympäristö
Esiehdot ja riippuvuudet
Alkutilanne
Vaiheet
Askel
Syöte
Odotettu tulos
1.
2.
…
74
Todellinen tulos
Tulokset
Lopputilanne
Testin suorittaja
Suoritus pvm
Lisätietoja
Testin tila/hyväksyntä
75
Liite 5: Virheraportti
Tämä liite sisältää mallin virheraportista. Dokumentti perustuu IEEE 829-2008 standardiin.
Dokumentin tiedot
Päiväys
Tekijä
Tila
Virheraportin tunniste
Testilokin tiedot
Testaaja
Testiympäristö
Poikkeaman kuvaus
Syöte
Odotettu tulos
Poikkeama
Vaikutukset
Vakavuus
Virheen vakavuusaste

Kriittinen – Ohjelma ei toimi tai kaatuu

Vakava – Vakavia ongelmia mutta ohjelma ei kaadu

Häiritsevä – Vaikutuksia käytettävyyteen tai suorituskykyyn mutta ei aiheuta virheellistä
suoritusta

Vähäinen – Kosmeettinen haitta esim. kirjoitusvirhe, huono asemointi
Prioriteetti
Virheen korjaustarpeen prioriteetti

Välitön – Virhe tulee korjata välittömästi
76

Korkea – Virhe voi odottaa mutta tulee korjata ennen seuraavaan vaiheeseen siirtymistä

Matala – Virhe voidaan jättää ohjelmaan esim. aika tai kustannusrajoitteiden vuoksi
77
Liite 6: Testausraportti
Tämä liite sisältää mallin testauksen loppuraportista. Dokumentti perustuu IEEE 829-2008 standardiin.
Projektin nimi
Testausraportti
78
Sisällysluettelo
1Dokumentin tiedot ......................................................................................................................... 3
2Testauksen yhteenveto ................................................................................................................. 3
3Poikkeamat suunnitelmasta .......................................................................................................... 3
4Yhteenveto tuloksista .................................................................................................................... 3
4.1Kattavuustarkastelu ................................................................................................................ 3
4.2Testauksen mittarit ................................................................................................................. 3
5Arviointi ja johtopäätökset ............................................................................................................. 4
6Hyväksyntä ................................................................................................................................... 4
1
79
1 Dokumentin tiedot
Päiväys
Tekijä
Tila
2 Testauksen yhteenveto
Tässä kuvataan mitä ja miten testattiin, mitä suunnitelmaa noudatettiin, missä ympäristössä ja kenen toimesta testaus suoritettiin.
3 Poikkeamat suunnitelmasta
Tässä kerrotaan mitä poikkeamia testaussuunnitelmasta jouduttiin tekemään.
4 Yhteenveto tuloksista
4.1 Kattavuustarkastelu
Tässä analysoidaan testauksen kattavuutta; mitkä olivat tavoitteet ja kuinka ne saavutettiin.
4.2 Testauksen mittarit
Tässä esitetään testi- ja virhelokin tilastot esim. tarkastuspisteissä viikoittain ja kuukausittain.
Testilokin tiedot
Määrä
%
Suunnitellut testitapaukset
100
Suoritetut testitapaukset
Onnistuneet testitapaukset
Epäonnistuneet testitapaukset
Hyväksytyt testitapaukset
Hylätyt testitapaukset
Virhelokin tiedot
Määrä
%
Havaitut viat
80
Raportoidut viat
Korjatut viat
Hylätyt ilmoitukset
Käsittelemättömät ilmoitukset
Virheet vakavuusasteittain
Määrä
%
Kriittinen
Vakava
Häiritsevä
Vähäinen
5 Arviointi ja johtopäätökset
Tässä arvioidaan testauksen onnistumista tavoitteisiin nähden ja analysoidaan testauksen tulokset.
Lopuksi esitetään johtopäätökset ja suositukset jatkotoimenpiteistä esim. kuinka menettelytapoja
voitaisiin jatkossa kehittää.
6 Hyväksyntä
Tähän voidaan vielä lisätä testauksen virallinen hyväksyntä allekirjoituksineen.
81