Testaussuunnitelmat Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Pressman, Software Engineering 1
Tavoitteista Luentojen jälkeen opiskelijan tulisi osata: 2
Sisällöstä Tavoitekalvon asioita. 3
Motivointia Tärkeä laadunvarmistamisen väline. Projektien resursseista jopa 30 40 % saatetaan käyttää testaukseen. Ideaalisessa tilanteessa kutakin suunnittelijaa kohden on yksi testaaja. 4
Testaus ja projektin vaiheet Testisuunnitelmaa voi alkaa muodostamaan jo silloin, kun ensimmäisiä (suht. stabiileja) vaatimuksia löytyy. Vaatimusten kiinnityttyä voi niiden pohjalta jo kirjoittaa paljon testitapauksia. (Vaatimusmäärittelyyn on tulee myös vaateita testauksesta.) 5
Toteutussuunnitelman valmistuessa myös yksityiskohtaisia yksikkötestitapauksia voi alkaa muodostamaan. Sitä mukaan, kun ohjelmistokomponentit valmistuvat, niitä voi testata. Lopuksi suoritetaan integrointitestaus (kaikki komponentit samassa). Kustakin suoritetusta testistä täytetään testiraportti, joka myös kuuluu kurssisuoritukseen ja kuuluu projektin tuotoksiin. (Ne myös toimitetaan toimeksiantajalle.) Testisuunnitelma on tarkoituksellisesti laitettu katselmoitavaksi ennen toteutussuunnitelmaa. Tämä pakottaa pohtimaan asiaa myös vaatimusten perusteella! 6
Testauksen perusteita, tavotteista Testaus tarkoittaa prosessia, jossa käytetään ohjelmaa 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. Siis tavoitteena: läytää testejä, jotka systemaattisesti paljastavat erilaisia virheluokkia ja tarvitsevat siihen mahdollisimman vähän aikaa ja vaivaa. 7
Toinen hyöty: testaus näyttää, että ohjelmiston toiminnot toimivat määrittelyjen mukaan ja että tehokkuusvaatimukset saavutetaan. Antaa hyvän kuvan ohjelmiston luotettavuudesta ja jotain suuntaa ohjelmiston yleisestä laadusta. Testaus ei voi osoittaa virheettömyyttä, vain että jotain virheitä löytyy. 8
Periaatteista Kaikki testitapaukset pitäisi olla mahdollista jäljittää asiakkaan vaatimuksiin. Testit pitäisi suunnitella huomattavan paljon aikaisemmin ennen kuin itse testaaminen alkaa. Pareto-optimaalisuuden periaate ohjelmistojen testauksessa. 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. 9
Testattavuus Testaus on vaikeaa, mutta sitä voi helpottaa, mikäli tietyt asiat otetaan huomioon ohjelmistoa suunniteltaessa ja toteutettaessa. Jotkin metriikat voivat myös kertoa testattavuudesta. Kuinka ison osuuden testit kattavat tuotteesta (tai koodista)? Seuraavien 7 kalvoja voi käyttää tarkastuslistoina hyvän testattavuuden takaamiseksi. Esim. suunnitelmien muodostamisen aikana, ja katselmointien yhteydessä. 10
Operoitavuus ( mitä paremmin se toimii, sitä helpommin se voidaan testata ): Systeemissä on useita ohjelmointivirheitä (nämä lisäävät analyysin ja raportoinnin kuormaa testausprosessille). Yksikään ohjelmointivirhe ei estä testien suorittamista loppuun. Tuote kehittyy toiminnallisissa vaiheissa (sallii yhtäaikaisen kehityksen ja testauksen). 11
Havaittavuus ( mitä näet, sitä testaat ): Erillinen tuloste generoidaan kullekin syötteelle. Systeemin tilat ja muuttujat ovat näkyvissä tai kysyttävissä suorituksen aikana. Vanhat systeemin tilat ja muuttujat ovat näkyvissä tai kysyttävissä (logit). Kaikki tulostuksiin vaikuttavat tekijät ovat näkyvissä. Väärä tulostus havaitaan helposti. Sisäiset virheet havaitaan automaattisesti sisään rakennetun testauksen avulla. Sisäiset virheet raportoidaan automaattisesti. Lähdekoodi on käytettävissä. 12
Kontrolloitavuus ( ohjelman parempi kontrollointi auttaa testauksen automatisoinnissa ja optimoinnissa ): Kaikki mahdolliset tulostukset voidaan generoida jollain syötteiden kombinaatiolla. Kaikki koodi on suoritettavissa jollain syötteiden kombinaatiolla. Testaaja voi kontrolloida suoraan ohjelmiston ja laitteiston tiloja ja muuttujia. Syöte- ja tulostusformaatit ovat yhdenmukaisia (johdon-) ja rakenteellisia. Testit voidaan tarkoituksenmukaisesti määrittää, automatisoida ja uusia. 13
Hajautettavuus (ositettavuus?, testauksen kohdetta muuttamalla voidaan nopeasti eristää ongelmakohdat ja suorittaa uusia testejä ): Ohjelmisto koostuu erillisistä moduleista. Ohjelmiston modulit voidaan testata erikseen. 14
Yksinkertaisuus ( Vähemmän testattavaa, nopeampaa... ): Toiminnallisuus yksinkertaista (vaatimuksiin nähden ei toteuteta turhia toimintoja, vs. jokin toinen toiminto/tavoite ohj. kehityksessä). Rakenteellinen yksinkertaisuus (arkkitehtuuri on modulaarista, jotta ongelmat eivät leviä). Koodin yksinkertaisuus (noudatetaan koodausstandardia, mikä helpottaa formaaleja tarkastuksia ja ylläpitoa). 15
Vakaus ( Vähemmän muutoksia, vähemmän häiriöitä testauksessa ): Ohjelmiston muutokset harvinaisia. Ohjelmiston muutokset kontrolloitua. Ohjelmiston muutokset eivät vanhenna nykyisiä testejä. Ohjelmisto toipuu hyvin virhetilanteista. 16
Ymmärrettävyys ( Mitä enemmän tietoa on käytettävissä, sitä paremmin voidaan testata ): Suunnitelmat ymmärretään hyvin. Ulkoisten, sisäisten ja jaettujen komponenttien suhteen ymmärretään hyvin. Suunnitelmien muutoksista tiedotetaan. Tekninen dokumentaatio on jatkuvasti käytettävissä. Tekninen dokumentaatio on hyvin organisoitua. Tekninen dokumentaatio on yksityiskohtaista. Tekninen dokumentaatio on täsmällistä (paikkansapitävää). 17
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 joitakuita isommasta joukosta. Ei ole liian yksinkertainen eikä mutkikas. Sarja testejä saattaa toimia yhtenäkin mutta voivat tuoda sivuvaikutuksia. 18
Testitapausten suunnittelu Erilaisia testitapausten suunnittelumenetelmiä löytyy runsaasti. Tarjoavat systemaattisen lähestymisen testaamiseen. black-box -testaus, vaatimusten perusteella tiedetään, mihin ohjelman tulisi kyetä, ja testeillä osoitetaan, että ohjelma siihen kykenee. white-box -testaus, tiedetään ohjelman sisäistä rakennetta, ja testeillä varmistetaan, että kunkin vaiheen jälkeen välitulokset ovat määrittelyjen mukaisia (tarkistuksia sopivin välietapein). 19
White-box -testaus Glass-box -testaus. Käytetään ohjelmiston kontrollirakenteita testitapausten muodostamiseen. Takaa, että modulin 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 niiden toiminnan pätevyys (oikeellisuus). 20
Kaikkea vaivaa ei kannata laittaa black-box -testaukseen. Seuraavia kohdat puoltavat white-box -testausta: Loogiset virheet ja väärät oletukset ovat käänteisesti suhteellisia siihen todennäköisyyteen, että ohjelman tällainen toiminto tai polku suoritetaan. Usein luullaan, että jotain loogista polkua ei todennäköisesti suoriteta, kun sitä itseasiassa suoritetaan säännöllisesti. Kirjoitusvihreet ovat satunnaisia. 21
Peruspolkujen testaus Johdetaan ohjelman toimintarakenteen looginen mutkikkuusmittari. Mittarin avulla muodostetaan perusjoukko suoritettavia polkuja. Johdettavat testitapaukset peruspoluille takaavat, että jokaista ohjelman osaa (käskyä, ilmaisua) kokeillaan ainakin kerran. 22
Virtakaaviot: 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 tällöin voi kuvata useaa ohjelman käskyä. 23
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ää yksi uusi solmu mukaan. Saatava polkujen lukumäärä antaa yhden mittarin ohjelman mutkikkuudelle. (syklomaattinen kompleksisuus, suomennos?) 24
1 4 2,3 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. 25
1. Muodosta koodin tai toimintarakenteen (-suunnitelman) perusteella kaavio. 2. Etsi toisistaan riippumattomat polut (peruspolut). 3. Valmista testijoukko, joka käy läpi kunkin peruspolun. Kohdassa kaksi on mahdollista tarkistaa, kuinka monta polkua tulisi kaaviosta löytää. Tämä luku on E N + 2, missä E on särmäjoukko ja N solmujoukko. 26
Verkon matriisiesityksistä Kukin särmä, esimerkiksi särmä 1 4, voidaan esittää matriisissa siten, että riviltä yksi on merkitty sarake neljä jotenkin. Esimerkiksi numerolla yksi. Jos kahden solmun välillä ei ole yhteyttä, käytetään nollaa, tällainen solmupari esimerkissä on 1 ja 8. 27
Käyttämällä jotain muuta särmien yhteyspainoa, lukua 0 ja 1 väliltä, voidaan saada lisäinfoa/automatisoida testausta: luku voi kertoa särmän kulkemistodennäköisyyden särmään liittyvän suoritusajan särmän suoritukseen liittyvän muistitarpeen muut särmän suorituksen aikana tarvittavat resurssitarpeet. Lisäksi voidaan laskea, kuinka monta kertaa kutakin särmää pitkin on kuljettu. 28
Kontrollirakenteiden testaus Seuraavat täydentävät peruspolkujen testausta. Ehtojen testaus Tietovirtojen testaus Silmukoiden testaus 29
Ehtojen testaus Boolen muuttujat Boolen operaattorit: tai, ja, ei (negaatio) Aritmeettiset operaattorit: <,>,,,, = Relationaalinen ilmaisu: E 1 < E 2 Yksinkertaiset ehtolauseet: rel. ilmaisu tai boolen muuttuja (negaatio saa olla edessä) Yhdistetty ehtolause: kaksi tai useampia yks.kert. ehtolauseita, sulkeistamiset 30
Virheitä voi löytyä: boolen operaattoreista (väärä, puuttuva, ylimääräinen) boolen muuttujista sulkeistamisista relationaalisista operaattoreista aritmeettisista operaattoreista 31
Haaroittumistestit, (true-, false-vaihtoehdot) Alatestaus (domain-), (aritmeettisen operaattorin eri syötealueet) Jos muuttujia paljon, ei kaikkia syötealueita voi testata. Haaroittumis- ja relaatio-operaattoreiden testaus. Käyttää ehtorajoitteita. Ks. Pressman. 32
Tietovirtatestaus Valitaan ohjelman testipolkuja määritelmien ja muuttujien käytön perusteella. Määritelmä-käyttö-ketju-testausstrategia. Ei välttämättä käy kaikkea koodia lävitse. Käyttökelpoinen, jos ohjelmassa sisäkkäisiä ehto- ja toistolausekkeita. Lisätietoa ja esimerkkejä, ks. Pressman. 33
Silmukoiden testaus Yksinkertainen, rakenteeton, sisäkkäiset ja peräkkäiset. 34
Yksinkertaiset silmukat Oletetaan, että n on annettu yläraja silmukan suorituskerroille. Tehdään seuraavia tapauksia varten testit. 1. Hypätään silmukan yli. 2. Yksi kierros. 3. Kaksi kierrosta. 4. m kierrosta, missä m < n. 5. n 1, n, n + 1 kierrosta. 35
Sisäkkäiset silmukat Jos suoraan sovelletaan edellisen kalvon tapaa, kasvaa testien määrä nopeasti epäkäytännölliseksi. Tätä voidaan yksinkertaistaa: Aloitetaan sisimmästä silmukasta. Muut silmukat (niiden laskurimuuttujat) asetetaan minimiarvoikseen. Tehdään ed. kalvon testi sisimmälle. Muiden silmukkojen laskurit paikallaan. Testataan seuraavaksi sisimpää silmukkaa. Tätä uloimmilla minimi arvot ja sisimmillä puolestaan tyypilliset arvot. Jatketaan, kunnes kaikki tasot testattu. 36
Peräkkäiset silmukat Kuten yksinkertaiset, jos ovat toisistaan riippumattomia. Jos silmukat riippuvat toisistaan, esimerkiksi jos jälkimmäisen silmukan laskuri alustetaan edeltävän laskurin arvolla, niin suositellaan sisäkkäisten silmukoiden tapaa testata. Rakenteettomat silmukat Nämä silmukat tulisi rakentaa uudestaan, jos mahdollista. 37
Black-box -testaus Perustuu toiminnallisiin vaatimuksiin. 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 38
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? 39
Verkkoihin perustuvat testausmenetelmät Black-box-menetelmissä täytyy ymmärtää objektit (tietoalkiot, ohjelmistokomponentit, -modulit) ja niiden väliset suhteet. Sen jälkeen testein varmistetaan, että odotetut suhteet keskenään. Suhteet (särmät) ja objektit (solmut) voi esittää verkkoina. Särmille ja solmuille voi antaa myös painoja. Särmä voi olla kaksisuuntainen ja kahden solmun välillä voi olla useita samansuuntaisia särmiä. 40
Seuraavat testausmenetelmät käyttävät verkkoja hyväkseen. Niissä solmujen ja särmien tulkinnat vaihtelevat toisistaan. Transaktiovirtojen mallinnus. Äärellinen tilamallinnus. Tietovirtamallinnus. Ajoitusten mallinnus. Ensin määritetään solmut ja niiden painot (objektit ym.) Seuraavaksi määritetään särmät ja niiden painot. Särmille annetaan nimet. (Kontrollivirtoja ei välttämättä tarvitse nimetä.) 41
Jos silmukoita, voidaan soveltaan yltä löytyviä kalvoja. Transitiivisuus voi johtaa tiettyihin testeihin (a johtaa b johtaa c, siis a johtaa b:hen). Halutaan testata myös symmetrisyyttä (undo ja sen peruutus). Refleksiivisyys?? (Ks. Pressman.) Testeillä halutaan varmistaa solmujen peitto. Ja särmien peitto. 42
Ekvivalenssiluokkiin perustuva testaus (Equivalence partitioning) Black-box -menetelmä, jossa syötteiden lähtöjoukko jaetaan luokkiin ja noista luokista valitaan edustusyksilöt testeihin. Perustuvat usein syöte-ehtoihin: 1. Jos kyse välistä (range), 2. Jos vaatii tiettyä arvoa, 3. Jos määrittää joukon alkion, 4. Jos on boolen syöte-ehto, niin kussakin muodostetaan yksi käypä ja kaksi ei-käypää ekvivalenssiluokkaa. Ks. Pressman. 43
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 a + 1 arvoilla. Ks. Pressman. 44
Vertailutestit Jos tarvitaan kahdennettuja systeemejä (esim. luotettavuuskriittisissä ympäristöissä), saatetaan kehittää kaksi (tai useampia) toisistaan riippumatonta systeemiä tekemään samaa asiaa. Voidaan testata yhtä aikaa samoilla testisyötteillä ja vertailla tuloksia. Kahden systeemin kehitys saattaa kannattaa, vaikka vain yksi toimitettaisiin, jos kyse hyvin kriittisestä sovelluksesta. 45
Erityiset ympäristöt ja sovellukset GUI Asiakas-palvelin -sovellukset. Dokumenttien ja avustustoimintojen testaus. Reaaliaikasysteemien testaus.... 46
Testausstrategiat Tarjotaan ohjelmiston kehittäjälle, laatuorganisaatiolle jne suuntaviivoja. 47
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ä. Käytä tehokkaita formaaleja katselmointeja ennen testejä. Katselmoi formaalisti myös testisuunnitelma ja testitapaukset. Kehitä jatkuvan parantamisen menetelmä testauprosessille. 48
Yksikkötestaus Modulit eivät ole toimivia ohjelmia, joten niitä varten täytyy rakentaa omat ajurit (pääohjelma, joka syö tarvittavat syötteet ja antaa ne modulille). Lisäksi tarvitaan tynkäalimodulit antamaan haluttuja syötteitä. Testataan modulin vastuiden rajat, paikalliset tietorakenteet, liittymäpinnat, riippumattomat polut ja virheiden käsittelypolut. 49
Integrointitestaus Ei-lisäävä (non-incremental) testaus, big bang, usein ajanhukkaa. Incrementaalisia ovat: 1. jäsentävä (top-down) integrointi (syvyys- tai leveys-ensin tavat). 2. kokoava (bottom-up) integrointi 3. regressio(takautuvuus, kuormitus)testaus Voileipästrategia, top-down ja bottom-up yhdistelmä. 50
Kuvaavat järjestystä, jolla moduleja liitetään kokonaisuuteen. Ensimmäisessä pääkontrollimoduli toimii ajurina. Täytyy käyttää tynkäalimoduleja, joita sitten korvataan vuorollaan varsinaisilla moduleilla. Toisessa tehdään klustereita tai kokoelmia, niille täytyy rakentaa omia ajureitaan. Klustereita sitten yhdistellään yhä isommiksi kokonaisuuksiksi jahka ne on saatu testattua. Kolmannessa kokeillaan osa jo yksittäin testatuista toiminnoista (integrointitestauksen aiemmassa vaiheessa), jotta ei ole tullut sivuvaikutuksia. Lisäksi varmistutaan, että mahdollisten korjausten ym. muiden jälkeen kaikki pelaa halutusti. 51
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). 52
Systeemitestaus 53