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
© Copyright 2024