Testauksesta ja testaussuunnitelmasta Luennon sisältö Motivointia, testaus projektin eri vaiheissa Yleistä ohjelmistojen testauksesta Testauksen suunnittelu Testaussuunnitelman sisältö ja tarkoitus Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto. Sivut 223 240. Pressman, Software Engineering. Sivut 464 532. 1
Motivointia Tärkeä laadunvarmistamisen väline. Projektien resursseista jopa 30 40 % saatetaan käyttää testaukseen. Ideaalisessa tilanteessa kutakin suunnittelijaa kohden on yksi testaaja. Vakuuttaa asiakkaan siitä, että tuote toimii sovitulla tavalla. Kustannusten vähentämien: virheen korjaaminen ohjelman julkaisemisen jälkeen on huomattavasti kalliimpaa kuin virheen löytäminen ja korjaaminen ennen! 2
Testaus ja projektin vaiheet (1/2) Testaussuunnitelmaa voi alkaa muodostamaan jo silloin, kun ensimmäisiä (suht. stabiileja) vaatimuksia löytyy. Vaatimusten kiinnityttyä voi niiden pohjalta jo kirjoittaa paljon testitapauksia. (Vaatimusmäärittelyyn tulee usein myös vaateita testauksesta.) Toteutussuunnitelman valmistuessa myös yksityiskohtaisia yksikkötestitapauksia voi alkaa muodostamaan. Testaamista voidaan tehdä esimerkiksi käytettävyystestien muodossa jo aivan projektien alussa, mutta usein testaus alkaa lähes samanaikaisesti toteutuksen kanssa: puolivalmiita ohjelmistokomponentteja voidaan jo testata! 3
Testaus ja projektin vaiheet (2/2) Kustakin suoritetusta testistä täytetään testiraportti, joka myös kuuluu kurssisuoritukseen ja kuuluu projektin tuotoksiin. Raportti on hyvä toimittaa myös toimeksiantajalle. Testisuunnitelma on tarkoituksellisesti laitettu katselmoitavaksi ennen toteutussuunnitelmaa. Tämä pakottaa pohtimaan asiaa myös vaatimusten perusteella! Lisäksi toteutussuunnitelmassa voidaan huomioida testiluokkien tarve. Moduuleihin on myös helpompi kirjoittaa testiominaisuuksia kun asiaa on mietitty etukäteen. 4
Testauksen perusteita ja tavoitteita (1/3) Testaus tarkoittaa prosessia, jossa käytetään ohjelmaa tai sen osaa ja tavoitteena on löytää virhe. Hyvä testitapaus on sellainen, jolla on korkea todennäköisyys löytää joku vielä havaitsematon virhe. Onnistunut testi on sellainen, joka löytää vielä havaitsemattoman virheen. Hyvä testitapaus ei ole liian monimutkainen. Hyvä testitapaus on nopea testata. Siis tavoitteena: löytää testejä, jotka systemaattisesti paljastavat erilaisia virheluokkia ja tarvitsevat siihen mahdollisimman vähän aikaa ja vaivaa. 5
Testauksen perusteita ja tavoitteita (2/3) Ohjelmissa arvioidaan yleensä olevan ohjelmoinnin jälkeen yksi virhe muutamaa kymmentä ohjelmariviä kohden! Pitkään käytetyissä ohjelmissa virhe / 1000 riviä koodia. Arviolta n. 5% virheistä on sellaisia että niitä ei havaita koskaan! Testaus näyttää, että ohjelmiston toiminnot toimivat määrittelyjen mukaan ja että tehokkuusvaatimukset saavutetaan. Antaa hyvän kuvan ohjelmiston luotettavuudesta. Kertoo jotain ohjelmiston yleisestä laadusta. Testaus ei voi osoittaa virheettömyyttä, ainoastaan että jotain virheitä löytyy. 6
Testauksen perusteita ja tavoitteita (3/3) Kaikki testitapaukset pitäisi olla mahdollista jäljittää asiakkaan vaatimuksiin (joko suoraan tai epäsuoraan). Testit pitäisi suunnitella huomattavan paljon aikaisemmin ennen kuin itse testaaminen alkaa. Testauksen pitäisi alkaa pienistä ja jatkua isoilla. Kaiken läpikäyvä testaus ei ole mahdollista. Jotta testaus olisi tehokasta, tulisi jonkin kolmannen osapuolen suorittaa se. 7
Hyvän testin ominaisuudet Löytää hyvin todennäköisesti virheen. Testaajan tulisi ymmärtää hyvin ohjelmisto ja miettiä, kuinka ohjelmisto voisi tehdä virheen. Hyvä testi ei ole tarpeeton. Aika ja resurssit ovat rajallisia. Eri testeillä tulisi olla omat tarkoituksensa. Hyvä testi on lajinsa paras. Joskus ehditään suorittamaan vain osa isommasta testijoukosta. Ei ole liian yksinkertainen eikä mutkikas. Sarja testejä saattaa toimia yhtenäkin mutta voivat tuoda sivuvaikutuksia. 8
Testauksen V-malli Määrittely Arkkitehtuuri suunnittelu Moduuli suunnittelu Testauksen suunnittelu ja tulosten verifiointi Ohjelmointi Järjestelmä testaus Integrointi testaus Moduuli testaus V-mallin mukaisesti testauksen suunnittelu tapahtuu testaustasoa vastaavalla suunnittelutasolla. Järjestelmätestaus suunnitellaan määrittelyvaiheessa, integrointitestaus suunnitteluvaiheessa ja moduulitestaus moduulisuunnitteluvaiheessa. 9
Testitapausten suunnittelu Erilaisia testitapausten suunnittelumenetelmiä löytyy runsaasti. Menetelmät tarjoavat systemaattisen lähestymisen testaamiseen. white-box -testaus: Tutkitaan ohjelman sisäistä rakennetta ja varmistetaan, että kunkin vaiheen jälkeen välitulokset ovat määrittelyjen mukaisia (tarkistuksia sopivin välietapein). gray box -testaus: Testejä suunniteltaessa otetaan huomioon vaatimukset, mutta huomioidaan myös tietoja moduulien sisäisestä toteutuksesta. black-box -testaus: Vaatimusten perusteella tiedetään, mihin ohjelman tulisi kyetä, ja testeillä osoitetaan, että ohjelma siihen kykenee. Kun V-mallissa siirrytään testauksessa alhaalta ylöspäin, niin siirrytään white-box gray-box black-box. 10
White-box -testaus (1/2) Glass-box -testing, structural testing, lasilaatikko -testaus. Käytetään ohjelmiston kontrollirakenteita testitapausten muodostamiseen. Takaa, että moduulin sisäiset toisistaan riippumattomat polut kokeillaan ainakin kerran lävitse. Kokeillaan kukin looginen ehto sekä true- että false-vaihtoehdoin. Kokeillaan kukin silmukka raja-arvoilla ja muillakin. Kokeillaan sisäisiä tietorakenteita ja varmistetaan niiden toiminnan oikeellisuus. 11
White-box -testaus (2/2) Kaikkea vaivaa ei kannata laittaa black-box -testaukseen. Seuraavia kohdat puoltavat white-box -testausta: Loogisten virheiden ja väärien oletuksien määrät ovat käänteisesti verrannollisia siihen todennäköisyyteen, että ohjelman kyseinen toiminto tai polku suoritetaan. Virheitä tulee siis enemmän sellaisiin osiin koodia, joita ei pidetä tärkeinä. Usein luullaan, että jotain loogista polkua ei todennäköisesti suoriteta, kun sitä itseasiassa suoritetaan säännöllisesti. Kirjoitusvihreet ovat satunnaisia. 12
Peruspolkujen testaus (1/5) Peruspolku = Peräkkäisten toimintojen jono ohjelmassa. Johdetaan ohjelman toimintarakenteen looginen monimutkaisuusmittari. Mittarin avulla muodostetaan perusjoukko suoritettavia polkuja. Johdettavat testitapaukset peruspoluille takaavat, että jokaista ohjelman osaa (käskyä, ilmaisua) kokeillaan ainakin kerran. 13
Peruspolkujen testaus (2/5) Ohjelman (kontrolli)virtakaavio: Kuvataan ohjelman toimintarakenne graafisesti. if while until case Kaavioissa usein peräkkäistoiminnot supistetaan yhdeksi solmuksi (ts. vasemmanpuoleisimman kaltaisista ketjuista päästään eroon). Yksi solmu voi tällöin kuvata useaa ohjelman käskyä. 14
Peruspolkujen testaus (3/5) Toisistaan riippumattomat polut muodostavat perusjoukon. Ensin otetaan yksi polku, jossa käydään kussakin solmussa korkeintaan kerran. Sitten muodostetaan uusia polkuja siten, että kussakin uudessa polussa tulee vähintään yksi uusi solmu mukaan. Saatava polkujen lukumäärä antaa yhden mittarin ohjelman monimutkaisuudelle. (Cyclomatic complexity, syklomaattinen kompleksisuus, parempi suomennos?) 15
Peruspolkujen testaus (4/5) 2,3 1 4 5 6 7 8 Esimerkistä löytyy yksi case-lause ja yhdet do-until- ja while-silmukat. Eri polkuja löytyy 4 kpl: 1-2,3-8 1-4-6-8 1-5-8 1-5-7-5-8. 16
Peruspolkujen testaus (5/5) 1. Muodosta koodin tai toimintarakenteen (-suunnitelman) perusteella kaavio. 2. Etsi toisistaan riippumattomat polut (peruspolut). 3. Valmista testijoukko, joka käy läpi kunkin peruspolun. 17
Black-box -testaus (functional testing) Perustuu toiminnallisiin vaatimuksiin, yleensä testataan käyttötapaukset. Täydentää white-box -testausta, ei korvaa. Voi paljastaa: väärät, väärin toimivat tai puuttuvat toiminnot (käyttö)liittymävirheet tietorakenteiden virheet, ongelmat ulkoisissa tietokannoissa tehokkuusongelmat alustus- ja päättöongelmat 18
Black-box -testaus, jatkoa Testeillä halutaan vastata mm. seuraaviin kysymyksiin: Kuinka toiminnallinen pätevyys testataan? Mitkä syöteluokat muodostavat hyviä testitapauksia? Onko systeemi erityisen herkkä tiettyihin syötteisiin? Kuinka dataluokkien rajat eristetään? Millä datamäärillä systeemi toimii? Mitä vaikutuksia tietyillä datan kombinaatioilla on systeemin toiminnalle? 19
Ekvivalenssiluokkiin perustuva testaus (Equivalence partitioning) Black-box -menetelmä, jossa syötteiden lähtöjoukko jaetaan ekvivalenssiluokkiin ja noista luokista valitaan edustusyksilöt testeihin. Perustuvat usein syöte-ehtoihin: 1. Epäkelvolliset syötteet. 2. Liian pienet tai liian suuret syötteet. 3. Kelvolliset syötteet. 4. Lisäksi yleensä valitaan luokkien rajoilla olevia tapauksia (esim. kelvollisten syötteiden ylä- ja alarajat). 20
Raja(reuna)-arvojen analyysi Testataan reuna-arvoja. Täydentää edellisen kalvon menetelmää: testataan testiluokan reuna-arvot. Voidaan myös testata tulos(tus)arvoja. Joukko samanlaisia ehtoja kuin ed. kalvossa: Esim. jos rajat a ja b, testataan niillä ja lisäksi a 1 ja b + 1 arvoilla. Ks. Pressman. 21
Testausohjeita - kansanviisauksia (1/3) Määritä systeemin vaatimukset mitattavalla tavalla (ennen testejä). Aseta selkeät tavoitteet testeille. Ymmärrä käyttäjiä ja kehitä kullekin käyttäjäryhmälle oma profiilinsa (kuvauksensa). Kehitä testisuunnitelma, joka korostaa nopean syklin testausta. Rakenna luotettavaa ohjelmistoa, joka on rakennettu (suunniteltu) testaamaan itse itseänsä. Katselmoi formaalisti myös testisuunnitelma ja testitapaukset. 22
Testausohjeita - kansanviisauksia (2/3) Kehitä jatkuvan parantamisen menetelmä testausprosessille. Tuotekehitysprojektissa järjestelmätestauksen loppuvaihe kestää pitempään kuin osaat kuvitella edes pahimmissa painajaisunissa! Test now or pay later; the later you find it, the more you pay. A good test can never save a bad program! Älä poista testauspiirteitä ohjelmasta. Tee / testaa muutokset ja lisäykset riittävän pieninä annoksina. 23
Testausohjeita - kansanviisauksia (3/3) Virheet kasaantuvat: jos jostain on löytynyt useita virheitä, lähistöllä on niitä vielä lisää. Varatun muistin kehityksestä kannattaa pitää kirjaa (roskien keruu, satunnaiset kuormitushuiput). Tarkasta vielä kerran laskennan liukulukujen pyöristykset, nollalla jako sekä tietorakenteiden yli ja alivuodot. Jos poikkeustilanteita käsittelevää koodia on vähän, kaikkia poikkeustilanteita ei ole otettu huomioon. 24
Yksikkötestaus (komponenttitestaus, moduulitestaus) Moduulit eivät ole toimivia ohjelmia (usein n. 100 1000 riviä koodia), joten niitä varten täytyy rakentaa omat ajurit (pääohjelma, joka syö tarvittavat syötteet ja antaa ne modulille). Lisäksi tarvitaan tynkäalimoduulit antamaan haluttuja syötteitä. Testataan moduulin vastuiden rajat, paikalliset tietorakenteet, liittymäpinnat, riippumattomat polut ja virheiden käsittelypolut. 25
Integrointitestaus Integrointitestauksessa yhdistellään yhteen moduuleita tai moduuliryhmiä (osajärjestelmiä). Painopiste on moduulien välisten rajapintojen toimivuuden tutkimisessa. Integrointitestaus etenee usein rinnan moduulitestauksen kanssa ja sitä onkin usein tarpeetonta tarkastella erillään moduulitestauksesta. Testauksen kattavuuden kannalta tosin moduulitestauksessa on helpompi saavuttaa kunnollinen testikattavuus (testattavan kokonaisuuden kasvaessa on vaikea käydä kaikkea koodia läpi). Integrointi etenee tavallisesti kokoavasti (bottom up) alimman tason moduuleista ylöspäin. Jäsentävässä eli osittavassa (top down) integroinnissa etenemissuunta on päinvastainen. 26
Hyväksymis(validointi)testaus Asiakas asettaa ohjelmalle kohtuullisia odotuksia, joista ohjelman on suoriuduttava, jotta hyväksymistestit näyttäisivät vihreää valoa. Hyväksymistestikriteerit: black-box testitapauksia. Konfiguroinnin katselmointi: onko ohjelmistotuotteen kaikki tarvittavat palaset mukana? Alfa- ja betatestaus: hyväksymistestauksia loppukäyttäjillä (alfa kehittäjän ja beta asiakkaan luona). 27
Järjestelmätestaus Toipumistestaus Virta irti seinästä. Verkkoyhteys poikki. Kuormitustestaus Kokeillaan tuhannen käyttäjän yhtäaikaista yhteydenottoa järjestelmään. Tehokkuustestaus Meneekö kaikki tietokantahaut määräajassa? Turvallisuustestaus Voiko ulkopuolinen päästä sairaalan järjestelmään ilman tunnuksia? 28
Muita tärkeitä testilajeja Käytettävyystestaus Pyritään varmistamaan että käyttäjä pystyy selviämään mahdollisimman hyvin tehtävistä, joiden suorittamiseksi järjestelmää ollaan rakentamassa. Laitoksella useita näitä asioita käsitteleviä kursseja. Regressiotestaus Yleisesti Regressiotestauksella tarkoitetaan vasta järjestelmätestauksessa (tai ohjelmiston käyttöönoton jälkeen) korjattujen virheiden aiheuttamien mahdollisten uusien virheiden etsimistä. Esim. Windows XP:n asennetaan Service Pack 2. Aiheuttaako tämä jotain ennalta-arvaamattomia virheitä? 29
Testauksen riittävyyden arviointi Tarvittavan testauksen määrää on yleensä vaikeaa arvioida. Varsinkin järjestelmätestauksessa testausta voidaan jatkaa kunnes aika ja/tai rahat loppuvat. Usein testauksen lopettaminen on kompromissi tuotteissa olevien vikojen aiheuttamien kustannusten ja markkinoilta myöhästymisen aiheuttaman tuoton menetyksen väliltä. Testauksen lopettamiselle tulisi asettaa aina hyväksymiskriteerit, jotka määritellään testaussuunnitelmassa. Kumulatiivinen löydettyjen virheiden ja korjattujen virheiden tarkastelu. Erilaisia mutkikkuus- (kompleksisuus-) ja kattavuusmitoilla voidaan arvioida tarvittavan testauksen määrää. 30
Testauksen suunnittelu Määrittely dokumentti Kokemus tarkastus listat Suunnittelu dokumentti Laatujär jestelmän ohjeistus Vanha tes taussuun nitelma Testauksen suunnittelu Testisuun nitelma TESTAUS Testira portit 31
Testauksen dokumentointi 1/4 Testausdokumentaatiota voi syntyä paljon: suunnitelma eri testausvaiheista ja raportit erikseen näistä kaikista. Moduulitestaustasolla testaussuunnitelman voi korvata joskus yrityksen oma laatukäsikirja (sisältää ohjeet kuinka moduulit kirjoitetaan ja suuntaviivat moduulitestaukseen). Pienehköissä projekteissa riittää yleensä yksi testaussuunnitelma joka kattaa moduuli-, integrointi- ja järjestelmätestauksen. Alustava suunnitelma laaditaan usein jo määrittelyvaiheessa ja sitä täydennetään suunnitteluvaiheessa. Joskus testaussuunnitelma sisällytetään projektisuunnitelmaan (yleiskuvaus), toiminnalliseen määrittelyyn (järjestelmätestaus) ja tekniseen määrittelyyn (integrointi- ja moduulitestaus). 32
Testauksen dokumentointi 2/4 Testaussuunnitelmasta selviää mitä testejä tehdään ja milloin, miten ne järjestetään ja millaisia lopputuloksia odotetaan. On tärkeää määritellä testauksen lopettamiskriteerit! Esim: varatun ajan päättyminen 100% testitapauksista tehty ja analysoitu 100% löydetyistä vioista on korjattu ja kaikkien korjausten jälkeen järjestelmä toimii vaatimusten mukaisesti 33
Testauksen dokumentointi 3/4 Kaikki löytyneet virheet tulisi raportoida ja analysoida. Raporttiin virheen kuvaus, miten vakavasta virheestä on kysymys, milloin virhe löydettiin, olisiko se voitu löytää aiemmin, milloin virhe oli tehty ja miten se olisi voitu estää. Asiakkaalta tulevia virheilmoituksia varten käytetään usein valmista lomaketta. Samaa lomaketta voidaan käyttää myös järjestelmätestauksessa. Ilman raportteja on mahdotonta saada selville testaukseen käytettyä aikaa ja laatujärjestelmän kehityskohteita. 34
Testauksen dokumentointi 4/4 Yksi suositeltava tekniikka on testauspäiväkirjan käyttö. Päiväkirjaan kirjataan kaikista löytyneistä virheistä: (edellisen kalvon kohdan yksi lisäksi) miten se korjattiin, korjaukseen käytetty aika ja virheen / korjauksen vaikutus järjestelmän/moduulin toimintaan. Testauspäiväkirjan käyttö moduulitestauksen alusta alkaen vaatii itsekuria, mutta sen avulla voidaan tehdä esim. kumulatiivinen virhe/korjaus diagrammi. Testausraportin muoto tällä kurssilla on vapaamuotoinen. Kts. esim. www.cs.tut.fi/~projekti/dokumentit/tera-sis.txt. 35
Testaussuunnitelma IEEE829 1. Johdanto 2. Testauksen kohde ja tavoitteet 3. Testausympäristö 4. Testauksen organisointi ja raportointi 5. Testausstrategia ja integrointisuunnitelma 6. Toimintojen testitapaukset, hyväksymiskriteerit 7. Ei-toiminnallisten ominaisuuksien testaaminen 8. Erikoistilanteet 9. Ominaisuudet, joita ei testata 36