Luokkatestauksen piirteitä: metodit. 4. Luokkatestaus (B, 10) Luokkatestauksen piirteitä: yliluokat. Luokan valmistelu. Alfa-Omega syklin vaiheet

Transkriptio

1 & 4. Luokkatestaus (B, 10) Luokkatestaus on matalimman tason testausta. Siinä testataan yksittäisiä luokkia tai ryppäitä (clusters). Ryväs on joukko vahvasti toisiinsa sitoutuneita luokkia. Pieniä ryppäitä voidaan testauksessa pitää yksittäisinä luokkina. Isot ryppäät kootaan integrointitestauksessa. Jatkossa luokkatestaus tarkoittaa sekä luokkien että pienten ryppäiden testausta. 1 Luokkatestauksen piirteitä: metodit Luokka testataan lähettämällä luokan metodeille yksi kerrallaan viestejä (kutsumalla niitä). Luokka testataan metodiensa kautta. Pelkkä yksittäisten metodien kutsuminen ei riitä, jos (ja kun) luokan metodeilla on keskinäisiä riippuvuuksia. Jokaisella luokan ilmentymällä, oliolla, on tila, joka määrää olion käytöksen. Tila on kaikkien sille tehtyjen metodikutsujen summa. Vaihtelemalla metodien kutsujärjestystä voidaan päätyä eri tiloihin. 2 Luokkatestauksen piirteitä: yliluokat Luokan valmistelu Luokka on kokoelma sille määriteltyjä ja sen yliluokilta perimiä metodeita ja attribuutteja. Aliluokan metodit voivat muuttaa perittyjen yliluokan metodeiden toimintaa muuttamalla olioiden tiloja. Pelkkä aliluokan metodien käyttö testauksessa ei välttämättä riitä. Ongelma voidaan ratkaista litistämällä luokka: otetaan testattavaksi luokaksi yhdistelmä aliluokasta ja sen perimistä kaikista yliluokista. Tämä voi tulla hyvin kalliiksi, jos perintähierarkia on syvä. 3 Ennen luokan testaamista sen täytyy olla valmis testattavaksi: Luokka on kirjoitettu valmiiksi: metodit on integroitu luokkaan. Luokassa ei ole testausta estäviä isoja virheitä. Luokka voidaan valmistella kahdella tavalla: Yksinkertaiset luokat voidaan valmistella kokoamalla vain metodit yhteen. Tätä sanotaan Small Pop kokoamiseksi. Monimutkaiset ja ehkä isoja virheitä sisältävät luokat valmistellaan Alfa-Omega syklillä. 4 Alfa-Omega -sykli Jokaisella oliolle voidaan määritellä kaksi virtuaalitilaa: alfa ja omega. Alfa kuvaa olion tilaa juuri ennen sen luontia. Omega kuvaa olion tilaa heti sen tuhoamisen jälkeen. Alfa-Omega syklissä oliolle suoritetaan eräänlainen savutesti suorittamalla jokainen sen metodi ainakin kerran. Jos sykli menee läpi, olion katsotaan olevan testauskelpoisessa kunnossa. 5 Alfa-Omega syklin vaiheet Testiajuri lähettää viestejä listan mukaisille metodeille seuraavassa järjestyksessä: 1. Konstruktorit: olion luonti. 2. Kapseloinnin get-metodit: lukijametodit. 3. Totuusarvoja palauttavat metodit. 4. Kapseloinnin set-metodit: kirjoittajametodit. 5. Iteraattorit: läpikäyvät metodit. 6. Destruktorit: olion tuhoaminen. Tyypin metodien suoritusjärjestys on private -> protected -> public. 6

2 ' Vastuu- ja toteutuspohjainen testaus Luokkatestaus on ennen kaikkea vastuupohjaista (responsibility-based). Luokka tarjoaa joukon palveluita eli on vastuussa siitä, että palvelut toimivat oikein. Palveluiden toiminnan ja poikkeustilanteiden hallinnan varmistus on luokkatestauksen ydin. Vastuupohjaisen testauksen tukena käytetään toteutuspohjaista (implementationbased) testausta. Siinä testitapaukset johdetaan testattavan luokan toteutuksesta. 7 Mustalaatikko- ja lasilaatikkotestaus Vastuupohjainen ja toteutuspohjainen testaus ovat Binderin termejä. Yleisemmin puhutaan kuitenkin mustalaatikko- ja lasilaatikkotestauksesta. Mustalaatikkotestauksessa testataan testattavan komponentin toiminnallisuutta. Lasilaatikkotestauksessa testataan testattavan komponentin rakennetta. Menetelmät eivät ole sidottuja luokkatestaukseen, vaan niitä voidaan käyttää kaikessa testauksessa. 8 Vastuu- ja toteutuspohjaisen testauksen testitapaukset Vastuu- ja toteutuspohjaiselle testaukselle ei tarvita erillisiä testitapauksia. Ensin suoritetaan vastuupohjaiset testit. Kun kaikki vastuupohjaiset testit on suoritettu, samoista testeistä lasketaan halutut toteutuspohjaisen testauksen kattavuudet (coverages). Jos halutut kattavuuskriteerit (coverage criteria) eivät toteudu, vastuupohjaisia testejä täydennetään sopivasti. Samalla usein löydetään puuttuneita vastuupohjaisia testejä. 9 Kattavuus ja kattavuuskriteeri Kattavuus on mittari, joka perustuu ohjelmasta tai sen osasta tehtyyn malliin. Kattavuus kertoo, miten suuren osan testitapaukset ovat testanneet mallista. Kattavuuskriteeri tarkoittaa ehtoja, mitkä testauksen on täytettävä, jotta se täyttää sitä vastaavalle kattavuudelle asetetut vaatimukset. Kattavuuskriteeri määrittelee siis, milloin kyseisen kattavuuden mukainen testaus on ollut riittävää. 10 Kattavuusesimerkki Kattavuus laajemmin Luokan metodikattavuus m voidaan määritellä esimerkiksi seuraavasti: m = M T /M, missä M on luokan metodien määrä ja M T on testitapauksissa käytyjen luokan metodien määrä. Olkoon meillä luokka C, jossa on 25 metodia. Käytetään luokan C testauksen kattavuuskriteerinä 100% metodikattavuutta. Jos meillä on testipaketti T, joka käy läpi 15 metodia, niin testipaketti T:n suorituksesta saatu metodikattavuus on m = 15/25 = 0,60, eli T antaa 60% metodikattavuuden. Testipaketti T ei täytä valittua kattavuuskriteeriä. 11 Kattavuus ei ole pelkästään toteutuspohjaisen testauksen tai edes luokkatestauksen mittari: Voimme määritellä esimerkiksi seuraavia kattavuuksia: Käyttötapauskattavuus: testeissä läpikäytyjen käyttötapausten suhde kaikkiin käyttötapauksiin. Toiminnallisten vaatimusten kattavuus: Testattujen toiminnallisten vaatimusten lukumäärän suhde kaikkiin toiminnallisiin vaatimuksiin. Tarkastuskattavuus: Tarkastuksissa läpikäytyjen dokumenttien sivumäärän suhde kaikkien tuotettujen dokumenttien sivumäärään. 12

3 ? ) 3 < K? ),,? 3 )? 3 ) ) 3? Koodikattavuus Toteutuspohjaiset kattavuudet ovat koodikattavuuksia (code coverage). Koodikattavuudessa testitapausten suorittamia ohjelman osia verrataan ohjelman lähdekoodista tehtyyn malliin. Yleisimmät koodikattavuudet ovat metoditasolla. Niissä lähdekoodista tehty malli on metodista tehty vuokaavio (control flow graph tai flow graph). Vuokaavio Vuokaavio rakennetaan seuraavasti: Kaaviolla on alkusolmu, joka vastaa metodiin tuloa (metodin otsikkoa). Alkusolmuun ei tule särmiä. Kaaviolla on joukko loppusolmuja, jotka vastaavat metodista poistumisia (return-lauseita). Loppusolmusta ei lähde särmiä. Jokaisesta metodin lauseesta tulee solmu. Jokaisesta mahdollisesta siirtymästä lauseesta toiseen tulee särmä vastaavien lauseiden solmujen välille. Ohjelmointikielen korkean tason rakenteet vaativat vuokaavioon useita solmuja ja särmiä Vuokaavio II Halutessa ehtojen atomiset lausekkeet erotellaan omiksi solmuiksi. Särmät lausekesolmujen välillä kuvaavat ehtojen suoritusjärjestystä. Jos kaaviossa on joukko peräkkäisiä solmuja, joissa ei ole haaraumia, nämä voidaan koota yhteen segmentiksi (segment). Jos kaaviossa on monta loppusolmua, näistä kannattaa liittää särmät virtuaaliseen metodin loppusolmuun L. Joskus korkean tason rakenteiden lopumista kuvataan virtuaalisella rakenteen loppusolmulla E. Vuokaaviorakenteita )+*-,.* / )+* ,.*:9 ; / 6 3!1 354 )+* <5= )+*>9 ; / 6 3!1 354, ) Vuokaaviorakenteita II 8 9 / F G ; =7@ 1 3+A * 3B * 35CD4 )E* G ) 8 3 G5A5H ) A * G ) 8 3 GIBJH ) B *5K 3+A < 30 )7L 6 F%H <+* M N 3B ) A XIY RIT-ZP[ MPO QIRPS T UIVW XIY RT Z\[ ) B 35C 17 Ei-atomisten ehtojen hajottaminen Ei-atomiset ehtorakenteet saadaan hajotettua atomisiksi seuraavilla säännöillä: / 071 3EA]J]^3B74 )+*,7* 3EA 3B / Ä I3B74 )+*,7* 3+A 3B, ) 18 (

4 h Vuokaavioesimerkki Vuokaavioesimerkki II Olkoon meillä seuraava metodi: // Kommenteissa olevat numerot ovat vastaavan vuokaavion solmujen numerot public int displaylastmsg(int ntoprint) { // 1 np = 0; // 2 if ((msgcounter > 0) && (ntoprint > 0)) { // 3 for (int j = lastmsg;((j!= 0) && (np < ntoprint));--j) { // 4;5;8 System.out.println(messageBuffer[j]); // 6 ++np; // 7 } if (np < ntoprint) { // 9 for (int j = SIZE; (( j!= 0) && (np < ntoprint)); --j) { // 10; 11; 14 System.out.println(messageBuffer[j]); // 12 ++np; // 13 } } } return np; // Metodia vastaava vuokaavio on: N O ` a b c d ikj l\monp5j qrm5s t upv vminp5j qrm5s t\w N b e Ngf NIN N>O N ` N a 20 Vuokaavioesimerkki III Entry-exit -polut Kaaviossa peräkkäisiä solmuja ilman haaraumia voidaan yhdistää segmenteiksi: (1,2), (6,7,8), (12,13,14). Atomisia lausekkeita ei ole eroteltu omiksi solmuiksi. Jos erottelu tehdään, solmut 3, 5 ja 11 jakautuvat kahdeksi solmuksi. Esimerkissä ei tarvita rakenteiden virtuaalisia loppusolmuja. Ne eivät selkeyttäisi kaaviota. Koska esimerkissä on vain yksi loppu, siinä ei tarvita virtuaalista metodin loppusolmua. 21 Vuokaavion polku (path) on reitti jostakin solmusta i johonkin solmuun j. Vuokaavion entry-exit polku (entry-exit path) on polku alkusolmusta loppusolmuun. Jokainen entry-exit polku kuvaa yhden tavan käydä metodi läpi. Kun jokin metodin testitapaus suoritetaan, se kulkee metodin läpi. Näin jokainen testitapaus käy läpi jonkin testatun metodin entry-exit poluista. 22 Polkukattavuus Entry-exit polut ovat pohjana useimmille metoditason kattavuuskriteereille. Kriteeri määritellään osajoukkona kaikista mahdollisista entry-exit poluista. Laajin kattavuus on polkukattavuus (path coverage). Siinä kattavuuskriteerinä ovat kaikki mahdolliset entry-exit polut. Kaikkien polkujen lukumäärä voi olla ääretön tai ainakin hyvin iso luku. Tämän johdosta polkukattavuutta ei käytetä testauksessa. 23 Lausekattavuus Lausekattavuus (statement coverage) on yksinkertaisin vuokaavioihin perustuva kattavuus. Se lasketaan kaavalla c = N T /N, missä c = lausekattavuus. N T = testauksessa käytyjen vuokaavion solmujen määrä. N = vuokaavion kaikkien solmujen määrä. Lausekattavuuden kattavuuskriteeri määrittelee, kuinka suuressa osassa metodin koodia tulee vähintään käydä testauksessa. 24

5 x Lausekattavuus II Lausekattavuuden heikkouksia Täydelle 100% lausekattavuudelle riittää parhaimmillaan yksi entry-exit polku, jos se käy läpi kaikki vuokaavion solmut. Edellisessä vuokaavioesimerkissä tällainen polku olisi 1,2,3,4,5,6,7,8,5,9,10,11,12,13,14,11,15. Aina ei selvitä yhdellä polulla, mutta yleensä lausekattavuus ei vaadi kovin montaa polkua. Lausekattavuus on selkeä ja helposti ymmärrettävä kattavuus, mutta sen kattavuuskriteeri on yleensä liian löysä. 25 Sellaisissa if-lauseissa, missä ei ole else-haaraa, riittää täydessä lausekattavuudessa testata ehto yhdellä true-arvolla. Sellaisissa switch-lauseissa, missä ei ole defaulthaaraa, ei tarvitse testata tilannetta, missä mikään case-haaroista ei toteudu. Riittää, että while- ja for-silmukat käydään läpi täsmälleen kerran. Täysi lausekattavuus ei vaadi sellaista testiä, missä silmukkaan ei mennä lainkaan. Moniehtolauseissa täysi lausekattavuus voidaan saavuttaa testaamalla vain yksi ehtokombinaatio. 26 Haaraumakattavuus Haaraumakattavuus II Lausekattavuutta kehittyneempi kattavuus on haaraumakattavuus (branch coverage). Se lasketaan seuraavasti: c = E T /E, missä c = haaraumakattavuus. E T = testauksessa käytyjen vuokaavion särmien määrä. E = vuokaavion kaikkien särmien määrä. Haaraumakattavuuden kattavuuskriteeri määrittelee, kuinka suuressa osassa metodin vuokaavion särmiä täytyy käydä testauksessa. 27 Täydellinen haaraumakattavuus vaatii, että jokainen vuokaavion haarautumaa täytyy seurata ainakin kerran. Edellisessä vuokaavioesimerkissä tähän päästään kolmella entry-exit polulla: 1,2,3,15. 1,2,3,4,5,6,7,8,5,9,15. 1,2,3,4,5,6,7,8,9,10,11,12,13,14,11,15. Haaraumakattavuus on hyvä ja aika yksinkertainen kattavuus, jonka kattavuuskriteeri on usein riittävän tiukka. 28 Haaraumakattavuuden heikous Haaraumakattavuuskriteerille riittää, että joillain testitapauksilla saadaan käytyä läpi kaikki haaraumat. Jos haaraumaan, kuten if-lauseeseen, liittyy monta ehtoa, niin haaraumakattavuuskriteeri vaatii vain kaksi ehtojen kombinaatiota: yhden tosi-haaralle ja yhden epätosi-haaralle. Esim. if (a!= 0 b!= 0) vaatii kaksi testitapausta: a=0 ja a!= 0. Haaraumakattavuuskriteeri ei vaadi, että b:n arvot testataan erikseen. Moniehtokattavuus Moniehtokattavuus ottaa huomioon, että ehto voi toteutua monella eri tosiepätosikombinaatiolla. Se määritellään seuraavasti: c = AE T /AE, missä c = moniehtokattavuus. AE T = testauksessa käytyjen atomisten lausekkeiden (atomic predicates) tosi- ja epätosivaihtoehtojen summa. AE = metodin kaikkien ehtojen atomisten lausekkeiden tosi- ja epätosivaihtoehtojen kombinaatioiden summa

6 y Moniehtokattavuus II Moniehtokattavuus III Moniehtokattavuuden kriteeri määrittelee, miten monta atomista tosi- ja epätosikombinaatiota täytyy saavuttaa testauksella. Kaikkien kombinaatioiden lukumäärä saadaan summaamalla kaikkien ehtojen atomisten lausekkeiden kombinaatioiden lukumäärät yhteen. Esim. edellä meillä oli if (a!= 0 b!= 0). Lauseelle saadaan 100% moniehtokattavuus neljällä tapauksella: a = 0, b = 0; a!= 0, b = 0; a = 0, b!= 0; a!=0, b!= Täydellinen moniehtokattavuus takaa, että vuokaavion kaikki solmut, särmät ja ehdot on käyty läpi testauksessa. Moniehtokattavuus on tehokas työkalu, mutta se vaatii paljon. Jos meillä on n atomista tosiepätosilauseketta, niin tarvitaan 2 n testiä saavuttamaan 100% moniehtokattavuus. Aina ei päästä 100% moniehtokattavuuteen. Esim. if (a<0 a > 10) vaatii tapauksen, missä a<0 ja a>10, mikä on mahdottomuus. 32 Peruspolkukattavuus Peruspolkukattavuus (basis-path coverage) perustuu entry-exit polkuihin: c = IP T /IP, missä c = peruspolkukattavuus. IP T = testauksessa läpikäytyjen riippumattomien polkujen (independent paths) määrä IP = metodin kaikkien riippumattomien polkujen määrä. Riippumaton polku on sellainen entry-exit polku, jota ei saada lineaarisena kombinaationa muista riippumattomista poluista. 33 Riippumattomat polut Riippumattomat polut saadaan vuokaaviosta seuraavalla algoritmilla. 1. Merkitään kaikki solmut ja särmät käymättömiksi. 2. Etsitään lyhin entry-exit polku, jossa on ainakin yksi merkitsemätön solmu tai särmä. Lisätään polku riippumattomien polkujen joukkoon ja merkitään sen solmut ja särmät käydyiksi. 3. Jatketaan etsintää, kunnes vuokaavion kaikki solmut ja särmät on merkitty käydyiksi. Riippumattomien polkujen määrä: C = e n + 2, missä C = syklomaattinen monimuotoisuus (cyclomatic complexity) e = vuokaavion särmien määrä n = vuokaavion solmujen määrä Kaava vaatii, että vuokaaviossa on vain yksi loppusolmu. 34 Vuokaavioesimerkin riippumattomat polut Aiemmasta vuokaavioesimerkistä saadaan algoritmilla seuraavat riippumattomat polut: 1,2,3,15 1,2,3,4,5,9,15 1,2,3,4,5,9,10,11,15 1,2,3,4,5,6,7,8,5,9,15 1,2,3,4,5,9,10,11,12,13,14,11,15 Kaikille poluille ei välttämättä saada tehtyä testiaineistoa. Tällöin polku täytyy testata osana jotain toista polkua. 35 Peruspolkutestaus ja vuokaaviot Kattavaan peruspolkutestaukseen vaaditaan, että vuokaavion ehdot hajotetaan atomisiksi ehdoiksi. Hajottamalla riippumattomien polkujen määrä vuokaaviossa lisääntyy. Samalla täydelliseen riippumattomien polkujen kattavuuteen liittyy vaatimus, että jokainen mahdollinen atomisten ehtojen kombinaatio tullaan testaamaan ainakin kerran. 36

7 z Peruspolkutestauksen idea Peruspolkutestauksen idea on vähentää testattavien polkujen määrää litistämällä silmukat nollaksi ja yhdeksi kierrokseksi. Idea toimii, jos peruspoluista johdetaan testitapaukset. Sen sijaan ongelmia syntyy, jos suoritetuista testitapauksista päätellään käydyt riippumattomat polut. Jokainen testi suorittaa jonkin entry-exit polun, mutta se ei todennäköisesti ole mikään todetuista riippumattomista poluista. 37 Peruspolkutestaus ja testitapaukset Usein käytetty ratkaisu suoritettujen polkujen ja riippumattomien polkujen väliseen yhteyteen on sopia, että testitapauksen suorituksen sisältämä pisin riippumaton polku on katettu testitapauksella. Joka tapauksessa yksi testitapaus ei voi kattaa enempää kuin yhden riippumattoman polun. Näin ollen täydellisen peruspolkutestauksen testipaketissa on oltava vähintään yhtä monta testitapausta kuin vuokaaviossa on riippumattomia polkuja. 38 Silmukkakattavuus Yksinkertaiset silmukat Jos silmukalla on kiinteä määrä iteraatioita, sille riittää yksi silmukan läpi kulkeva testi. Jos silmukalla ei ole kiinteää määrää iteraatioita, sille tarvitaan ainakin kaksi testiä: 0 iteraatiokerrosta, silmukassa ei käydä lainkaan 1 iteraatiokierros, silmukka litistetään Lisäksi suositellaan seuraavia testejä: minimi iteraatiokierrosta, minimi voi olla 0 minimi+1 iteraatiokierrosta maksimi iteraatiokierrosta, jos maksimi tiedetään Silmukkakattavuus (covering iteration) perustuu silmukan suorittaviin entry-exit -polkuihin. Polut riippuvat silmukan tyypistä. Silmukoita on neljää tyyppiä: Yksinkertaiset silmukat: silmukalla on yksi sisääntulo- ja yksi poistumispiste. Sisäkkäiset silmukat: monta yksinkertaista silmukkaa sisäkkäin. Peräkkäiset silmukat: monta silmukkaa samalla entry-exit -polulla. Spagettisilmukat: silmukalla on useita sisääntuloja/tai poistumispisteitä Yksinkertaiset silmukat II Sisäkkäiset silmukat Täydelliseen yksinkertaisten silmukoiden testaukseen tarvitaan lisäksi seuraavat testit: minimi-1 kierrosta, jos mahdollista maksimi-1 kierrosta, jos maksimi tunnetaan maksimi+1 kierrosta tyypillinen kierrosmäärä iteroitavasta koodista johdettava määrä iteraatioita iteroitavassa koodissa voi olla iteraation raja-arvoja (boundaries) tai sisäisiä erikoistapauksia (interior points), joissa silmukan toiminta vaihtuu. Tällöin silmukka pitää testata myös poikkeusarvojen ympärillä olevien kierrosten lukumäärä. 41 Täydellinen sisäkkäisten silmukoiden testaus vaatisi vähintään 2 n testiä, missä n on sisäkkäisten silmukoiden määrä. Sisäkkäiset silmukat testataankin näin: 1. Testataan sisäkkäisin silmukka ensin yksinkertaisena silmukkana. Asetetaan muille silmukoille minimiarvot. 2. Kiinnitetään testatulle silmukalle sopiva arvo. 3. Testataan seuraavaksi sisäkkäisin silmukka. 4. Toistetaan vaiheita 2-3, kunnes uloin silmukka on testattu. 42

8 Peräkkäiset silmukat Jos peräkkäiset silmukat ovat toisistaan riippumattomia, ne testataan erikseen yksinkertaisina silmukoina. Jos peräkkäisillä silmukoilla on jokin riippuvuussuhde, ne testataan yhdessä samalla tavalla kuin sisäkkäiset silmukat. Riippuvuussuuhde tarkoittaa, että jälkimmäisen silmukan iteraatiokierrosten määrä riippuu edellisen kierroksen iteraatioista. Peräkkäisistä silmukoista testaatan ylin ensin. Muut silmukat Spagettisilmukoita ei ole mahdollista testata järkevästi. Ne voidaan aina suunnitella ja toteuttaa muilla silmukkatyypeillä, testauksen sijaan ne pitää suunnitella ja koodata uudestaan. Kiinteät silmukat ovat erikoistapauksia yksinkertaisista silmukoista. Niissä iteraatioiden määrä on vakio (minimi ja maksimi ovat sama luku). Nämä testataan yhdellä silmukan läpi kulkevalla testillä Tietovuokattavuus Tietovuokattavuus (data flow coverage) perustuu huomioon, että entry-exit -polussa on jonoja muuttujiin kohdistuvia toimintoja. Jos jossain tällaisessa jonossa on virhe, mutta jonon sisältävää polkua ei suoriteta minkään testitapauksen osana, niin testauksessa ei luultavasti löydetä virhettä. Tietovuotestauksessa (data flow testing) pyritään tunnistamaan ja testaamaan tällaisia muuttujiin kohdistuvia toimintoja. 45 Muuttujan toiminnot Jokaiselle muuttujalle voidaan määritellä kolmenlaisia toimintoja: Muuttuja voidaan määritellä (define). Tällöin muuttuja luodaan tai muuttujan arvo vaihtuu. Näitä sanotaan D-toiminnoiksi. Muuttujaa voidaan käyttää (use). Tällöin muuttujan arvo luetaan. Näitä sanotaan U- toiminnoiksi. Muuttuja voidaan tuhota (kill). Tällöin muuttujalle varattu tila vapautetaan muistista. Muuttuja ei ole enää käytettävissä. Näitä sanotaan K-toiminnoiksi. 46 Muuttujan toimintoparit All-uses -tietovuokattavuus Ottamalla jonkun muuttujan suhteen toimintopareja, saadaan muuttujaan kohdistuvia kaksitoimintoisia jonoja. Toimintojen välissä ei ole muita samaan muuttujaan kohdistuvia toimintoja. -D: muuttuja luodaan (- tarkoittaa, että toimintoa ei ole) DU: muuttuja luodaan ja sitä käytetään K-: muuttuja tuhotaan KD: muuttuja tuhotaan ja luodaan heti uudestaan UD: muuttujaa käytetään ja sitten tuhotaan jne. 47 Kun edelliset toimintaparit yleistetään kuvaamaan parin sisältävää entry-exit - polkua, saadaan tietovuokattavuuskriteerejä: all-uses -kattavuus: Jokaista DU-paria kohti testaan ainakin yksi parin sisältävä entry-exit - polku. Jos tietystä määritelmästä D menee monta eri polkua tiettyyn käyttöön U, näistä riittää valita yksi. Tämä on osoittautunut riittävän vahvaksi kattavuuskriteeriksi. all-du-paths -kattavuus: Jokaista DU-paria kohti testataan kaikki parin sisältävät entry-exit -polut. 48 {

9 Polunherkistys Manuaalinen polunherkistys Polunherkistys (path sensitization) tarkoittaa prosessia, missä selvitetään, millä metodin syötteillä ja paikallisten muuttujien arvoilla saadaan suoritettua tietty polku. Jos polunherkistys onnistuisi kaikille poluille, niin sen avulla voitaisiin täysin automatisoida kaikki polkuihin perustuvat testit. Valitettavasti on osoitettu, että ongelmalle ei ole olemassa yleistä ratkaisua. Jokainen tapaus olisi käsiteltävä erikseen. 49 Polunherkistys vaatii heuristiikan: sarjan päätöksiä. Seuraava algoritmi toimii usein: 1. Tarkista vastuupohjaisten testitapausten polut. Nämä yleensä kattavat suurimman osan tarvittavista poluista. Katso jääkö jokin ilmeinen käsittelemättömän polun herkistävä kombinaatio käsittelemättä. 2. Valitse herkistettävä polku. Etsi testitapaus, joka herkistää osan polusta. Etsi polulta haarauma, missä testiapaus ei enää seuraa haluttua polkua. Muuta syötettä mahdollisuuksien mukaan sellaiseksi, että haaraumasta jatketaan oikein. 50 Manuaalinen polunherkistys II Mahdottomat polut 3. Jos yksikään lasketuista poluista ei näytä osuvan lähelle haluttua polkua, listaa polulla olevat predikaatit (haaraumien atomiset ehdot). 4. Jos vaan mahdollista, vältä sellaisia polkuja, missä predikaatit lasketaan polun suoritusaikana. Jos jokin arvo on pakko laskea polun suoritusaikana, selvitä mahdollisuuksien mukaan alkuehdot, mistä muuttujalle saadaan haluttu tulos. 5. Aloita etsintä polun alusta tai lopusta. Seuraa polkua etsien predikaatit toteuttavia arvoja. Tarpeen vaatiessa palaa takaisin (tai luovuta). 51 Manuaalinenkaan polunherkistys ei välttämättä löydä syötteitä kaikille poluille: Joskus predikaatit ovat niin solmussa keskenään, että sopivien syötteiden arvojoukot ovat tyhjiä. Toisin sanottuna vaikka polun logiikka näyttää oikealta, mikään syötekombinaatio ei toteuta sitä. Joskus ohjelmassa on kuollutta koodia tai mahdottomia haaraumia joko suunnitteluvirheen takia tai tarkoituksella. Esim. seuraava koodi estää 100% haaraumakattavuuden (miksi?): while (true) { /* koodia */ if (lopetus()) return; } 52 Arvoalueanalyysi Avoimet ja suljetut rajaehdot Testausta ei voida tehdä ilman testitapausten syötteiden valintaa. Arvoalueanalyysi (Domain analysis) on suoraviivainen ja tehokas tapa valita syötteet. Arvoalue (domain) on kaikkien testattavan kohteen syötteiden joukko. Osa-arvoalue (subdomain) on rajaehdon (boundary condition) määrittämä osajoukko arvoalueesta. Arvoalueanalyysissa arvoalue ositetaan Rajehto on avoin (open), jos se voidaan esittää aitona epäyhtälönä. Rajaehto on suljettu (closed), jos se ei ole avoin. Avoimilla ehdoilla määritelty osa-arvoalue vastaa matematiikan avointa väliä: ]a,b[. Suljetuilla ehdoilla määritelty osa-arvoalue vastaa matematiikan suljettua väliä: [a,b]. Jos osa-arvoalueessa on sekä avoimia että suljettuja ehtoja, se vastaa matematiikan puoliavointa väliä: [a,b[ tai ]a,b]. tunnetuilla rajaehdoilla osa-arvoalueiksi

10 Arvoaluetestaus Arvoaluetestausesimerkki Arvoaluetestaus (domain testing) perustuu vikamalliin, missä testattavan kohteen yksi tai useampi rajaehto on toteutettu väärin. Vastaava testaustrategia on testata kaikki osa-arvoalueet erityisesti osa-arvoalueen reunoilla olevilla arvoilla. Arvoaluetestaus aloitetaan selvittämällä testattavan kohteen arvoalue, osittamalla arvoalue osa-arvoalueiksi ja selvittämällä kunkin arvoalueen rajaehdot. 55 Olkoon meillä kokoelmaluokka korkeintaan 4096:lle alkiolle (esimerkiksi taulukko). Olkoon n kokoelmaluokassa olevien alkioiden määrä. Oletetaan, että luokka hyväksyykin vain 4095 alkiota ( koodissa on n<4096 eikä n<=4096). Kokoelmaluokan arvoalue on kokoelmaluokan alkioiden määrä: [0..MAX], missä MAX=suurin mahdollinen kokonaisluku. Kokoelmaluokan arvoalue jakautuu ainakin kahteen osa-arvoalueeseen: 0 <= n <= 4096 ja n > Kokoelmaluokan osa-arvoalueen rajaehto on n<= Arvoaluetestausesimerkki II On-, off-, in- ja out-pisteet Kokoelmaluokan vikamalli on, että rajaehto n <= 4096 on toteutettu väärin. Kokoelmaluokan vikamallin mukainen testausstrategia on testata kokoelmaluokkaa ainakin 4095:lla, 4096:lla ja 4097:lla alkiolla. Tuloksena saadaan, että kokoelmaluokka on toteuttanut rajehdon n<=4096 väärin. Kokoelmaluokassa on toinenkin rajehto: n>=0. Myös tämä ehto pitäisi testata. Sen testaamiseksi testataan tyhjä kokoelmaluokka (n=0) ja yhden alkion kokoelmaluokka (n=1). 57 Arvoaluetestauksen testiarvojen valintakriteerit perustuvat on- ja off-pisteisiin. on-piste (on-point) on osa-arvoalueen rajalla oleva piste. Rajat saadaan rajaehdoista. off-piste (off-point) on osa-arvoalueen rajan ulkopuolella oleva piste. in-piste (in-point) toteuttaa osa-arvoalueen kaikki rajaehdot eikä ole rajalla. out-piste (out-point) ei toteuta mitään osaarvoalueen rajehdoista eikä ole rajalla. Pisteiden valinta riippuu rajaehdon avoimuudesta X 1 -arvoaluetestaus 1 X 1 -arvoaluetestaus II 1 X 1 ( one-by-one ) arvoaluetestausstrategia valitsee kunkin rajaehdon kohdalta vähintään yhden on-pisteen ja yhden off-pisteen. Pisteiden valintastrategia on seuraava: Jokaista osa-alueen relaatio-operaattorilla määriteltyä rajaehtoa kohti valitaan yksi on-piste ja yksi off-piste. Pisteiden tulee olla mahdollisimman lähellä osa-arvoalueen rajaa. Relaatio-operaattoreita ovat ainakin <, <=, > ja >= 59 Jokaista osa-alueen yhtäsuuruusoperaattorilla määriteltyä rajaehtoa kohti valitaan yksi on-piste ja kaksi off-pistettä. off-pisteet valitaan mahdollisimman läheltä molemmilta puolilta rajaa. Jokaista ei-skalaarista tyyppiä kohti valitaan yksi on-piste ja yksi off-piste. Valittujen arvojen tulee olla mahdollisimman lähellä toisiaan. Jokaista epälineaarista rajaehtoa kohti (esim. ehto y < x 2-2) valitaan yksi on-piste ja yksi off-piste Viereisten osa-alueiden testauksessa käytetään mahdollisuuksien mukaan samoja pisteitä ja testejä. 60 & }

11 Testauksen suunnittelumallit Metoditason suunnittelumallit Suunnittelumalli (design pattern) on yleistetty ratkaisu toistuvasti esiintyvään suunitteluongelmaan. Myös testaus on suunnittelua, ja myös siinä toistuvat samat ongelmat. Testauksen suunnittelumalli (test design pattern) tarjoaa yleistetyn ratkaisun johonkin testaukseen liittyvään ongelmaan. Binder esittää kirjassaan 37 testauksen suunnittelumallia. 61 Metoditasolla Binder määrittelee seuraavat testauksen suunnittelumallit: Category-partition Syötteiden ja tulosteiden arvoalueanalyysiin perustuva testipaketin suunnittelu. Combinational Function Päätöstauluihin perustuva testipaketin suunnittelu. Recursive Function Rekursiivisen funktion testipaketin suunnittelu. Polymorphic Message Polymorfisia parametreja vastaanottavan palvelimen asiakkaan testipaketin suunnittelu. 62 Luokkatason suunnittelumallit Luokkatason suunnittelumallit II Luokkatasolla Binder määrittelee seuraavat testauksen suunnittelumallit: Invariant Boundaries Vaikeasti hallittavien kompleksisten arvoalueiden testipaketin suunnittelu. Nonmodal Class Tilattomien luokkien testitapausten suunnittelu (olion toiminta ei riipu sen tilasta). Modal Class Tilaperustaisten luokkien testitapausten suunnittelu (olion toiminta riippuu sen tilasta). 63 Quasi-modal Class Näennäistilaluokkien testitapausten suunnittelu (näennäistilaluokka: olion toiminta riippuu olion hallitsemista tiedoista; esim. kokoelmaluokat ovat näennäistilaluokkia). Small pop ja Alpha-Omega Cycle Koodauksen ja testauksen suhde luokka- ja metoditasolla. Polymorphic Server Polymorfisia viestejä hyväksyvän palvelimen testaus. Modal Hierarchy Tilaperustaisten luokkien testaus, kun osa tiloista ja siirtymistä peritään yliluokilta. 64 Testauksen suunnittelumalliesimerkki Kaikkien, tai edes tärkeimpien, testauksen suunnittelumallien käsittely veisi liikaa aikaa. Esimerkkinä käsittelen Category-Partition - testauksen suunnittelumallin. Testauksen suunnittelumallien rakenne on: tavoite: tuotettava testipaketti, sisältö: ratkaistava testausongelma, vikamalli: löydettävät ongelmat, strategia: testipaketin suunnittelu- ja toteutustapa, Alkuehto: mitä vaaditaan ennen mallin käyttöä ja Category-Partition Tavoite Suunnittella metodin syötteiden ja tulosteiden analyysiin perustuva metodin testipaketti. Sisältö Joskus metodit tarjoavat useita palveluita, jotka pitää testata erikseen. Jos metodi on suunniteltu hyvin, palvelut voidaan aina erottaa toisistaan syöteparametrien ja luokan attribuuttien arvojen avulla. Category-Partition -mallia käyttämällä tällaiset hyvin käyttäytyvät monta palvelua tarjoavat metodit voidaan testata systemaattisesti. Menetelmä sopii myös yhden palvelun metodeille. Loppuehto: milloin mallin mukainen testaus on ok & &

12 Category-Partition II Category-Partition III Vikamalli Viat liittyvät syötteiden kombinaatioihin, jolloin virheellinen syötekombinaation tulkinta synnyttää väärän tuloksen. Strategia Toimi seuraavasti: 1. Tunnista testattavan metodin toiminnot. 2. Tunnista kunkin testattavan toiminnon syöte- ja tulosparametrit Osita kunkin syöteparametrin arvojoukko sopiviksi toisistaan erillään oleviksi osa-arvojoukoiksi. Tee ositus sellaiseksi, että metodin toiminta on kaikilla osaarvojoukon alkioilla samanlaista. 4. Valitse kustakin osa-arvojoukosta joukko testiarvoja esimerkiksi 1 X 1 -menetelmällä. Pyri valitsemaan arvoja sekä osa-arvojoukon keskeltä että reunoilta. 5. Ota huomioon sellaiset valittujen arvojen väliset yhteydet, jotka voivat vaikuttaa testien suoritusjärjestykseen. 6. Generoi jokaista valittujen arvojen kombinaatiota kohti testitapaus. 7. Tee jokaiselle testitapaukselle oraakkeli, jolla testaat testin hyväksymisehdot. 68 Category-Partition III Alkuehto Small Pop Loppuehto Kaikkien syöteparametrien valittujen arvojen kombinaatiot on testattu ainakin kerran. Jokainen metodin generoima poikkeus on testattava ainakin kerran. Testauksessa tulee päästä 100% haaraumakattavuuteen tai perustella, miksi siihen ei päästy. 69 Category-Partition -esimerkki Olkoon meillä metodi, joka tulostaa saamansa tunnisteen id perusteella virheilmoituksen ja lisää siihen perään annetun merkkijonon extra. Lailliset id:n arvot ovat väliltä 0-9. extra voi olla mikä tahansa merkkijono. Tehdään metodille C-P:n mukaiset testitapaukset. Metodin määrittely on seuraava: void error(int id, String extra); 70 Category-Partition -esimerkki II Category-Partition -esimerkki III 1. error-metodilla on yksi palvelu: tulosta virheilmoitus. 2. syöteparametrit ovat int id ja String extra, tulosparametreja ei ole. 3. id voidaan osittaa osa-arvoalueiksi seuraavasti: Kaikkia laittomia arvoja varten yksi luokka. Luokan alkiot eivät vastaa mitän virheilmoitusta Jokaista laillista arvoa kohti yksi luokka. vastaavasti extra voidaan osittaa seuraavasti: null-parametrista yksi luokka. Muista merkkijonoista yksi luokka Valitaan id:n osa-arvoalueiden testiarvoiksi yksi laiton arvo ja jokainen laillinen arvo. Valitaan extran testiarvoiksi null ja satunnainen merkkijono. 5. Testiarvojen välillä ei ole rajoituksia. 6. Valitaan testitapaukset: error(-1,null); error(-1, random ); error(1,null); error(1, random );... error(9,null); error(9, random ); 7. Kirjoitetaan oraakkeli, joka varmistaa, että testeillä saadut virheilmoitukset ovat oikein. 72 &~'