Dynaaminen analyysi II Luento 4 Antti-Pekka Tuovinen www.cs.helsinki.fi 9 April 2018 1
Tavoitteet Black-box testitapausten suunnittelutekniikat II Tilamallien käyttö Syy-seurausverkot ja päätöstaulut Kombinaatioiden testaus pareittain Käyttötapaukset Yhteenvetoa black-box -tekniikoista www.cs.helsinki.fi 9 April 2018 2
Tilamallit testitapausten suunnittelussa www.cs.helsinki.fi 9 April 2018 3
Tilamalli Mikä on ohjelman tila? Tila kertoo Mitä ohjelma juuri nyt tekee Mitä syötteitä/pyyntöjä se voi nyt käsitellä Miten se reagoi syötteisiin/pyyntöihin Millä ehdoilla se voi siirtyä toiseen tilaan Ohjelman tilamalli on abstraktio, jolla kuvataan miten ohjelman suoritushistoria vaikuttaa sen käyttäytymiseen tietyllä ajan hetkellä Ulkoisesti havaittavan käyttäytymisen malli - ei sisäisen implementaation www.cs.helsinki.fi 9 April 2018 4
Tilamalli Sopii käytettäväksi, jos ohjelman suorituksessa on selviä vaiheita tai jaksoja, joissa sen käyttäytyminen on oleellisesti erilaista kuin muissa vaiheissa Hyväksytyt syötteet, tuotetut tulosteet, tietosisällön muutokset ja tuetun liiketoimintaprosessin vaiheet Siirtymiseen vaiheesta toiseen voi liittyä herätteitä, toimintoja ja ehtoja www.cs.helsinki.fi 9 April 2018 5
Tilamallin määrittely tilakoneena Tilakone eli äärellinen automaatti (finite state machine) Kiinnitetty, äärellinen määrä tiloja ja syötteitä Koostuu tiloista, siirtymistä, syötteistä ja tulosteista Mallinnetaan yleensä tilojen ja niiden välisten siirtymien välisenä verkkona Tilakaavio (state diagram) Tilakoneen graafinen esitys Näyttää mahdolliset tilat sekä tapahtumat ja olosuhteet, jotka aiheuttavat siirtymän tilasta toiseen tai jotka seuraavat tilasiirtymistä www.cs.helsinki.fi 9 April 2018 6
Esimerkki pinon tilakaavio (kurssikirja kuva 5-3, s. 129) push function, operation [height > 1] guard www.cs.helsinki.fi 9 April 2018 7
Tilamallin perusteella tehtävä testaus Testin kohde (test object) Koko ohjelma tai jokin yksittäinen komponentti/palvelu, usein myös yksittäinen olio Testin suoritus koostuu sarjasta kohteelle annettuja syötteitä Testauksen kattavuus Testin vähimmäisvaatimus on, että kaikissa tiloissa käydään vähintään kerran Vahvempi ehto on, että jokaisen tilan kaikki toiminnot ja tilasiirtymät tulisi suorittaa ainakin kerran Myös reagointi odottamattomiin tai vääriin syötteisiin on testattava jokaisessa tilassa www.cs.helsinki.fi 9 April 2018 8
Testitapausten suunnittelu Esimerkki vähimmäistestistä (pinon maksimikoko on tässä tapauksessa 4) 1. Esiehto: pino on alustettu ja tilassa empty 2. Syöte: vie pinoon (push) hello 3. Syöte: vie pinoon (push) hello 4. Syöte: vie pinoon (push) hello 5. Syöte: vie pinoon (push) hello 6. Tulos: pinon huipulla (top) on hello 7. Jälkiehto: pino on tilassa full www.cs.helsinki.fi 9 April 2018 9
Testitapausten muodostaminen Testitapausten suunnittelua helpottaa (syklisen) tilakaavion purkaminen tilasiirtymäpuuksi Algoritmi 1. Aseta tilamallin alkutila puun juureksi 2. Lisää uusi oksa puuhun jokaista alkutilasta lähtevää tilasiirtymää kohden siten, että siirtymän kohdetila tulee uudeksi lehdeksi puuhun 3. Toista askelta kaksi jokaiselle puun lehdelle, kunnes jompikumpi ehdoista täyttyy: i. Uusi tila on lopputila (ei enää siirtymiä muihin tiloihin) ii. Uusi tila esiintyy jo puussa polulla juuresta lisättyyn tilaan (eli on löytynyt sykli) www.cs.helsinki.fi 9 April 2018 10
Pinon siirtymäpuu initial initialize pop empty delete push deleted filled push push pop top empty filled full filled filled top push* pop full full filled www.cs.helsinki.fi 9 April 2018 11
Testitapausten muodostaminen Puun jokainen polku juuresta lehteen vastaa yhtä testitapausta Siirtymiin liittyvät ehdot (guard) on otettava huomioon testitapauksia muodostettaessa Jotakin tiettyä polun segmenttiä on mahdollisesti toistettava: Initial empty filled filled filled full Myös odottamattomia syötteitä on kokeiltava jokaisessa tilassa Puuta laajennetaan sisältämään vääriä syötteitä vastaavat tilat www.cs.helsinki.fi 9 April 2018 12
Virhetilat pinon siirtymäpuussa initial initialize FAIL pop pop FAIL empty delete top push deleted filled delete push push pop top FAIL empty filled full filled filled delete top push* pop full full filled FAIL www.cs.helsinki.fi 9 April 2018 13
Tilamallit järjestelmätestauksen apuna Tilamallit sopivat luontevasti kuvaamaan siirtymiä ohjelman erilaisten loppukäyttäjän näkymien ja dialogien välisten siirtymien kuvaukseen www.cs.helsinki.fi 9 April 2018 14
Esimerkki DreamCar GUI (kurssikirja kuva 5-6, s. 134) www.cs.helsinki.fi 9 April 2018 15
Testitapausten rakenne Testitapauksessa määritellään Testin kohteen alkutila ennen testitapauksen suoritusta Annettava syöte Odotettu testikohteen tuottama tulos tai käyttäytyminen Odotettu testikohteen lopputila suorituksen jälkeen Tilasiirtymistä pitää tietää Tila, josta siirtymä tapahtuu Tapahtuma tai olosuhde, joka laukaisee siirtymän Odotettu reaktio tai toiminto, jonka siirtymä käynnistää Seuraava tila, johon siirtymä johtaa www.cs.helsinki.fi 9 April 2018 16
Testauksen lopetusehto Yleinen ehto heikommasta vahvempaan 1. Jokainen tila on saavutettu vähintään kerran testin aikana 2. Jokainen siirtymä on suoritettu vähintään kerran (sisältää 1:n) 3. 2 + Jokaista odottamatonta/väärää syötettä on kokeiltu kaikissa tiloissa Kriittisille ohjelmille voidaan määritellä vielä kattavampiakin siirtymiä ja niiden kombinaatioita koskevia ehtoja (esim. tiedonsiirtoprotokollien testaus) www.cs.helsinki.fi 9 April 2018 17
Tekniikan arviointia Sopii käytettäväksi, kun testin kohteella on selvästi tilapohjaista käyttäytymistä (suoritushistoria vaikuttaa toimintaan) ja prosessoinnin vaiheet tai tilat ovat erotettavissa toisistaan Erityisen luontevaa olioperustaisille järjestelmille, jossa jokainen olio tavallaan on pieni tilakone Kapseloi tilan (attribuuttien/propertyjen arvot) ja siihen kohdistuvat operaatiot (metodit) www.cs.helsinki.fi 9 April 2018 18
Syy-seurausverkot, päätöstaulut ja parikombinaatiot testitapausten suunnittelussa www.cs.helsinki.fi 9 April 2018 19
Syötteiden väliset riippuvuudet Aiemmin esitellyt tekniikat eivät ota huomioon ohjelman/komponentin eri syötteiden välisiä riippuvuuksia ja yhteisvaikutusta testin kohteen toimintaan Syötteitä tarkastellaan erillisinä (esim. ekvivalenssiluokat) Huom - tulosteiden ekvivalenssiluokat ottavat jossain määrin syötteiden riippuvuudet huomioon Syy-seurausverkkojen (cause-effect graph) avulla voidaan kuvata tiettyyn ohjelmiston käyttäytymiseen (action, effect) johtavat tilanteet ja syyt (condition, cause) ja niiden kombinaatiot www.cs.helsinki.fi 9 April 2018 20
Esimerkki pankkiautomaatin toiminta (kurssikirja kuva 5-7, s.137) www.cs.helsinki.fi 9 April 2018 21
Päätöstaulut Testitapausten määrittelyä varten syyseurausverkko muunnetaan päätöstauluksi Algoritmi kurssikirjassa s. 138 (luku 5.1.4) Päätöstaulusta voidaan suoraviivaisesti muodostaa loogiset testitapaukset, jotka kuvaavat ohjelman eri käyttäytymisvaihtoehdot ja niihin johtavat ehdot ja tapahtumapolut Konkreettiset testitapaukset vaativat syötteet ja askeleet, joilla halutut tilanteet saavutetaan www.cs.helsinki.fi 9 April 2018 22
Esimerkki päätöstaulu (kurssikirja taulu 5-11, s. 139) www.cs.helsinki.fi 9 April 2018 23
Testauksen lopetusehto Jokainen päätöstaulun sarake on suoritettava vähintään yhdellä testitapauksella Verifioi kaikki järkevät ehtojen kombinaatiot ja niitä vastaavan toiminnan www.cs.helsinki.fi 9 April 2018 24
Kombinaatioiden testaus Edellä selostettuja tekniikoita voidaan käyttää, kun syötteiden ja muiden ehtojen vaikutus testin odotettuun tulokseen tiedetään (syy-seuraussuhde) Jos syy-seuraussuhteita ei tunneta, periaatteessa pitäisi testata kaikki mahdolliset syötteiden ja (tulokseen mahdollisesti vaikuttavien) tilannetekijöiden kombinaatiot Esimerkiksi syötteiden validien ekvivalenssiluokkien kaikkien edustajien kombinaatiot Tavoitteena on löytää vahingollisia vuorovaikutuksia näennäisesti riippumattomien tekijöiden välillä www.cs.helsinki.fi 9 April 2018 25
Kombinaatioiden testaus pareittain Kombinaatioiden määrä kasvaa nopeasti hyvin suureksi, jos syötteitä/tekijöitä ja ekvivalenssiluokkia on monta Usein ongelmat johtuvat kuitenkin nimenomaan kahden tekijän vuorovaikutuksesta, joten käytännössä on havaittu yleensä riittäväksi, että testaus kattaa vain kaikki mahdolliset kahden syötteen kombinaatiot (syöteparit) Ei tarvitse käydä läpi myös kaikkia kolmen, neljän jne, syötteen kombinaatioita Tarvittavien testitapausten määrä pienenee merkittävästi www.cs.helsinki.fi 9 April 2018 26
Kombinaatioiden testaus pareittain Esimerkki kurssikirjassa s. 140 141 ja taulukko 5-12 www.cs.helsinki.fi 9 April 2018 27
Tekniikan arviointia Syitten ja seurausten huolellinen analysointi syyseurausverkkojen ja päätöstaulujen avulla voi paljastaa ehtojen kombinaatioita, jotka eivät tule esiin muilla tekniikoilla Loogisten testitapausten muodostaminen helppoa Päätöstaulun muodostamisessa ja optimoinnissa voi tapahtua virheitä Verkot ja taulut voivat kasvaa suuriksi ja niiden hallinta vaatii erityisiä työkaluja Algoritmisia ratkaisuja kuitenkin löytyy Kombinaatioiden testaus pareittain voi vähentää testitapausten määrää huomattavasti, kun yritetään löytää tuntemattomia (haitallisia) vuorovaikutuksia www.cs.helsinki.fi 9 April 2018 28
Käyttötapausmallit testitapausten suunnittelussa www.cs.helsinki.fi 9 April 2018 29
Käyttötapausmallit Käyttötapauksia (use case) ja UML:n käyttötapausmalleja käytetään yleisesti ohjelmiston toiminnalliseen määrittelyyn Käyttötapaus kuvaa ulkopuolisen toimijan (actor) vuorovaikutuksen (syötteet ja vastaukset) ohjelmiston kanssa jonkin toimijan tavoitteen saavuttamiseksi Käyttötapauksen suoritus tuottaa jotain arvoa toimijalle www.cs.helsinki.fi 9 April 2018 30
Käyttötapausmallit UML kuvaa käyttötapaukset nimeämällä toimijat ja käyttötapaukset, sekä osoittamalla käyttötapausten väliset suhteet UML-mallit eivät kuvaa yksityiskohtaisesti käyttötapaukseen liittyvää vuorovaikutusta (toimijan antamia syötteitä ja ohjelmiston tuottamia vastauksia) Yksityiskohtaiset kuvaukset valituista käyttötapauksista kannattaa kirjoittaa erikseen: http://www.agilemodeling.com/artifacts/systemus ecase.htm www.cs.helsinki.fi 9 April 2018 31
Esimerkki pankkiautomaatti (kurssikirja kuva 5-8, s. 142) www.cs.helsinki.fi 9 April 2018 32
Käyttötapausmallit Käyttötapauksiin liittyy aina tiettyjä esiehtoja ja jälkiehtoja Käyttötapausmallit ja yksityiskohtaiset käyttötapauskuvaukset soveltuvat järjestelmä- ja hyväksyntätestauksen testitapausten suunnittelun pohjaksi Käyttötapauksia voi käyttää myös ohjelmiston alijärjestelmien välisen vuorovaikutuksen määrittelyyn, jolloin ne sopivat myös integrointitestien suunnitteluun www.cs.helsinki.fi 9 April 2018 33
Mallinnettu toiminnallisuus Käyttötapaukset keskittyvät ohjelmiston normaalin toiminnan ja tyypillisten tilanteiden kuvaamiseen Järjestelmän vakaa ja luotettava käyttäytyminen tärkeää Usein myös tärkeimmät vaihtoehtoiset tapahtumakulut kuvataan Käyttötapauksiin perustuvat testit ovat erittäin relevantteja asiakkaan ja loppukäyttäjän kannalta! www.cs.helsinki.fi 9 April 2018 34
Testitapausten muodostaminen Käyttötapaukseen liittyy toimijan jokin tavoite, joka on tarkoitus saavuttaa (lopputulos) Toimijan ja ohjelmiston välisen vuorovaikutuksen kulku koostuu aktio - reaktio -askeleista, joista osa voi olla vaihtoehtoisia tai johtaa muihin aktiviteetteihin (tai käyttötapauksiin) www.cs.helsinki.fi 9 April 2018 35
Testitapausten muodostaminen Käyttötapauksen kuvaukseen kuuluu Lähtötilanne ja esiehdot Muut mahdolliset ehdot tai olosuhteet Odotettu tulos Jälkiehdot Konkreettiset syötteet ja tulosteet täytyy erikseen määritellä testitapauksia varten Käyttötapausta vastaava testitapaus on eräänlainen skripti, joka muodostuu peräkkäisestä sarjasta askeleita, joissa testaaja ensin antaa jonkin syötteen ja sitten vertaa testin kohteen käyttäytymistä odotettuun tulokseen Vaihtoehtoisia tapahtumankulkuja varten on myös määriteltävä testitapaukset www.cs.helsinki.fi 9 April 2018 36
Lopetusehto Jokainen käyttötapaus sekä sen vaihtoehtoiset kulut ja laajennukset on käyty läpi vähintään yhdessä testitapauksessa www.cs.helsinki.fi 9 April 2018 37
Tekniikan arviointia Hyödyllinen menetelmä tyypillisten toimintojen testaamiseen Sopii parhaiten järjestelmä- ja hyväksyntätestaukseen Käyttötapaukset voivat sisältää myös vaihtoehtoisia tapahtumakulkuja ja poikkeustilanteiden kuvauksia Asioita, joita käyttötapaukset eivät kuvaa, ei voi niiden perusteella testata Tarvitaan täydentäviä tekniikoita, esim raja-arvo analyysi, tutkiva testaus jne. www.cs.helsinki.fi 9 April 2018 38
Huomioita black-box tekniikoista www.cs.helsinki.fi 9 April 2018 39
Black-box testauksen rajoituksia Edellä selostettujen tekniikoiden lähtökohtana ovat järjestelmän vaatimukset ja spesifikaatiot Vaatimusten ja spesifikaatioiden virheet eivät tule helposti esille, koska tämän tyyppiset testit voivat vain osoittaa toimiiko ohjelmisto vaatimusten mukaisesti Tarkkaavainen testien suunnittelija voi kuitenkin havaita vaatimuksissa puutteita ja ristiriitaisuuksia Heuristiikat oraakkeleina! Määrittelyvirheitä voidaan löytää katselmoinneilla (staattinen testaus) www.cs.helsinki.fi 9 April 2018 40
Black-box testauksen rajoituksia Ylimääräisen, ei-vaaditun toiminnallisuuden löytäminen näillä testeillä on sattuman kauppaa Testauksen kattavuus- ja lopetusehdot perustuvat tunnettuihin vaatimuksiin ja spesifikaatioihin, eivätkä siihen mitä on tullut implementoitua www.cs.helsinki.fi 9 April 2018 41
Toiminnallisuuden verifiointi Vaatimuksista/määrityksistä lähtevä Black-box testaus keskittyy ohjelmiston toiminnallisuuden verifiointiin Käsitellyt suunnittelutekniikat tarjoavat systemaattisia tapoja johtaa kattava testitapausten joukko erilaisista malleista ja määrityksistä Ohjelmiston toimintojen kelvollisuus on kiistämättä sen kaikkein tärkein ominaisuus Sen vuoksi black-box tekniikoita on aina syytä käyttää! www.cs.helsinki.fi 9 April 2018 42
Tärkeä huomautus Black-box testauksessa ei yleisesti ottaen tarvitse rajoittua vain spesifioituun/määriteltyyn käyttäytymiseen, vaan testaaja voi myös asettua käyttäjän/asiakkaan asemaan ja pyrkiä validoimaan testin kohteen käyttäytyminen (sen sopivuus) Käyttäen testien suunnittelussa apuna omaa kokemustaan, ymmärrystä testattavasta ohjelmistosta ja asiakkaan todennäköisistä tarpeista, sekä erilaisia heuristiikkoja Black-box testausta voi siis tehdä, vaikka mitään speksiä ei olisikaan Ja tarvittaessa esimerkiksi käyttöliittymän tilamallin voi laatia itse testitapausten suunnittelun avuksi www.cs.helsinki.fi 9 April 2018 43