Testaus Johdanto: Mitä testaus on (ja mitä se ei ole) Testauksen ongelmia Testaustasot, V-malli Testitapausten valinta Testauksen kattavuus Työkalut Suunnittelu, seuranta ja dokumentointi Oliokeskeisyys ja testaus Kansanviisauksia Esimerkki Testaus Testing Testing is is the the process process of of exercising exercising a a program program with with the the specific specific intent intent of of finding finding errors errors prior prior to to delivery delivery to to the the end end user. user.
Testaus ohjelma syöteavaruus ohjelmakoodi tulosavaruus X Y sisäinen tila Johtopäätös? Syöteavaruuden koko ja mahdollisten tilojen määrä on niin valtava, ettei edes pienen ohjelman kattava testaus ei ole käytännössä mahdollista. Reaaliaikajärjestelmän tapauksessa tilanne on kertaluokkaa ongelmallisempi. Testaamalla voi siis osoittaa, että ohjelmassa on virheitä, ei sen virheettömyyttä. Testaus Testaus on systemaattista virheiden etsimistä -- ei sattumanvaraista ohjelman kokeilua. Testauksen tarkoitus on osoittaa että ohjelmassa on virheitä. Mitä enemmän virheitä löytyy, sitä onnistuneempi testi on. Virhe on ristiriita spesifikaation ja toteutuksen välillä. Virheiden jäljitys eli debuggaus ei ole testausta. Tehtäviä... Testaussuunnitelman laatiminen. Ensimmäinen versio jo määrittelyvaiheessa. Testauksen tavoitteet kussakin testissä. Testikohtaisesti testitapausten suunnittelu. Testausympäristöjen luonti. Testauksen suoritus. Tulosten tarkastelu.
Error, fault, failure Virhe (error, kansanomaisesti bugi) ihmisen tekemä möhläys, esimerkiksi ohjelmointivirhe tai virhe dokumentissa. ohjelmiston poikkeaminen sen spesifikaatiosta Kun virheellinen ohjelmankohta suoritetaan, se saattaa aiheuttaa vian (fault). Järjestelmä on nyt tilassa, joka ei ole sen määrittelyn mukainen. Vika puolestaan voi aiheuttaa häiriön (failure), joka on vian ilmeneminen järjestelmän ulkoisessa käyttäytymisessä. kaikki viat eivät johda virheeseen Testauksesta Virheiden määrä? hyvä ohjelmoija tuottaa noin yhden virheen / 200 riviä koodia keskikokoisessa ohjelmistossa helposti satoja virheitä! Virheen poistaminen testauksessa kuluttaa noin 12 työtuntia testaus on tehoton ja kallis tapa varmistua ohjelmiston toimivuudesta testauksella ei voida koskaan osoittaa ohjelmiston tomivuutta, vain virheellisyys Missä virheet sijaitsevat? 25% ohjelmakoodin lauseissa 22% tietorakenteissa 16% spesifikaation tulkinnassa 9% modulien integroinnissa... 8% spesifikaatioissa
Testauksen ongelmia Asenne: testauksella yritetään osoittaa ohjelman toimivuus, ei toimimattomuus. Testauksen aliarvostus: "ne jotka eivät muuta osaa, testaavat". Milloin testaus voidaan lopettaa: kun rahat/aika loppuu? Onko kaikki testattu? Mihin tehdyt korjaukset vaikuttavat? Testien toistaminen korjausten jälkeen (regressiotestauksen työmäärä). Testin toistettavuus (ajastukset ja muut hallitsemattomat ilmiöt), esimerkkejä: osoittimien käyttö (yllättävän usein) reaaliaikajärjestelmä, hajautettu järjestelmä ja graafinen käyttöliittymä....testauksen ongelmia Moduulitestauksessa testausympäristö. Testaustyökalujen vaikutus järjestelmän toimintaan. Järjestelmä on maantieteellisesti laaja (hajautettu). Poikkeamien havaitseminen on vaikeaa (esimerkiksi niiden pienuuden takia) Ei tiedetä, mikä oikean tuloksen pitäisi olla. Tilanteet, jota ei voida testitilanteessa järjestää (ohjelmistoissa on lähes aina tällaisia osia). Tulosten toteaminen oikeaksi, kun järjestelmän toimintaa ei voida seurata ulkopuolelta.
Testauksen V-Malli Määrittely Arkkitehtuurisuunnittelu Moduulisuunnittelu Testauksen suunnittelu ja tulosten verifiointi Moduulitestaus Integrointitestaus Järjestelmätestaus Ohjelmointi V-malli yksikkötestaus, modulitestaus (unit testing) testataan jokainen komponentti (moduli, luokka,...) spesifikaatiotaan vastaan (jos sellainen on tehty) yleensä white box testausta integrointitestaus (integration test) komponenttien yhteistoiminta validointitestaus (validation testing) ohjelmiston vastaavus vaatimusmäärittelyyn pääsääntöisesti järjestelmätestaus (system testing) koko järjestelmän testaus asennettuna laitteistot mukana black box V-malli kytkee rakennus ja testausvaiheen toisiinsa, testaussuunnitelma laaditaan testausvaihetta vastaavassa rakentamisvaiheessa käytännössä useita pieniä V-malleja iteratiivisen vaiheistuksen sisällä
V-malli Moduulitestauksessa testausympäristö. Testaustyökalujen vaikutus järjestelmän toimintaan. Järjestelmä on maantieteellisesti laaja (hajautettu). Poikkeamien havaitseminen on vaikeaa (esimerkiksi niiden pienuuden takia) Ei tiedetä, mikä oikean tuloksen pitäisi olla. Tilanteet, jota ei voida testitilanteessa järjestää (ohjelmistoissa on lähes aina tällaisia osia). Tulosten toteaminen oikeaksi, kun järjestelmän toimintaa ei voida seurata ulkopuolelta. Moduulitestaus Testattava moduli Testitulokset Ohjelmistosuunnittelija (yleensä) Testitapaukset (testcase) Moduulitestaus (module testing, unit testing) varmistaa, että yksittäiset moduulit toimivat määrittelynsä mukaisesti irrallisena kokonaisuutena. esim. toimivatko paikalliset tietorakenteet Ohjelmoija tekee yleensä itse, tosin korkeaa virheettömyyttä vaativissa sovelluksissa käytetään ulkopuolista testaajaa.
Moduulitestausympäristö Ajuri Moduli rajapinta lokaalit tietorakenteet rajatapaukset suorituspolut virheelliset syötteet Tynkä Tynkä Testitapaukset RESULTS Testiajuri (driver) ajaa testitapauksia Puuttuvat testattavan modulin tarvitsemat modulit korvataan tynkämoduleilla (stub) Integrointitestaus Integrointitestaus testaa moduulien välisiä liittymiä. toimiiko tiedonvälitys rajapinnoissa toimiiko modulien kytkentä (ajoitukset realiaikajärjestelmissä) kokonaisuutta tekeekö modulijoukko kokonaisuutena mitä pitää testaus tehdään teknistä määrittelyä vastaan mitä aiemmin aloitetaan, sitä aiemmin nähdään ongelmia arkkitehtuurissa Testaus etenee usein rinnan moduulitestauksen kanssa joko kokoavasti (bottom up) tai jäsentävästi (top down). Jäsentävässä integroinnissa joudutaan rakentamaan kutsuttavia funktioita varten tynkämoduuleita (test stubs). Kokoavassa vaihtoehdossa tarvitaan usein testipetejä (test bed, test driver). Reaaliaikajärjestelmän ohjelma koostuu tavallisesti useista tehtävistä (task, multitasking) => myös tynkäprosessien käyttö on usein hyvä idea. Kaksi perusstrategiaa Inkrementaalinen "Big bang" on yleensä ongelmallinen
Inkrementaalinen integrointitestaus A T1 A T1 A T1 T2 B T2 T2 B T3 B T3 C T3 T4 C T4 D T5 Test sequence 1 Test sequence 2 Test sequence 3 Integrointitestaus top down A Ylin moduli testataan tynkien avulla B F G Tynkämodulit korvataan oikeilla yksi kerrallaan C D E Lisättäessä uusia moduleita, Aikaisemmat testit ajetaan uudelleen (ainakin osa) Tynkämoduleilla on sama rajapinta kuin varsinaisella, mutta rajallinen funktionaalisuus
Integrointitestaus bottom up A B F G C Testiajurit korvataan testatuilla klustereilla Yksi kerrallaan Moduleista kootaan klustereita D E cluster modulit implementoidaan ja testataan aloittaen hierarkian alaosasta moduleista kootaan klustereita (tyypillisesti jonkin toiminnon toteuttavia) integraatiotestauksessa koko järjestelmä näkyy testiajurina Integrointitestaus testauksen eteneminen Level 1 Testing Level 1 sequence... Level 2 Level 2 Level 2 Level 2 Level 2 stubs top down bottom up Level 3 stubs T est d ri vers Lev el N L evel N L e vel N Lev el N Lev e l N Testin g s eq uen ce T est d ri v ers Lev el N 1 L ev el N 1 Lev el N 1
Integrointitestaus Suurin ongelma integrointitestauksessa on löytyneiden virheiden lokalisointi - mistä anomalia testin tulosteessa johtuu? interaktiot modulien välillä ovat kompleksisia, käyttääkö joku moduli toisen rajapintaa väärin? onko kyseessä modulin sisäinen virhe jota ei löydetty modulitestauksessa? Virheen lokalisointia helpottaa inkrementaalinen integraatio ja testaus sopimuspohjainen ohjelmointi (onko vika kutsujassa vai kutsuttavassa) realiteetteja järjestelmän ominaisuuksien implementaatio saattaa jakaantua usealle modulille, jollon integroinnin inkrementti on iso virheitä saattaa löytyä uuden modulin lisäyksen seurauksena jo integroiduista ja testatuista osista järjestelmää rajapintavirheiden korjaus vaatii usein koko integraatiotestauksen uudelleensuorittamista koska rajapintaa käyttävät muutkin kuin s e moduli jonka yhteydessä virhe tuli esille Top-down vs. bottom up vertailukriteerejä Arkkitehtuurin testaus top-down löytää todennäköisemmin virheitä arkkitehtuurista aikaisessa vaiheessa bottom-up testing ei vaadi arkkitehtuurin kiinnittämistä XP-tyyppinen ohjelmistoprosessi mahdollinen Järjestelmän toiminta top-down antaa toimivan tynkä järjestelmän heti alussa demonstraatio (feasibility), protoilu, psykologinen motivaattori validointitestaus voi alkaa ennen kuin koko integraatio on tehty Testien toteuttaminen top-down vaatii tynkämodulien toteuttamisen, mikä saattaa olla työlästä bottom-up vaatii ajurien toteutuksen, usein helpompaa Tulosten kerääminen top-down rakentamisessa yleensä ylimmät (kontrolli-) tasot eivät tuota mitään näkyvää tulostetta pitää toteuttaa ylimääräisiä toimintoja raportoimaan mitä järjestelm ässä tapahtuu bottom-up vaatii usein ajureihin testattavien modulien toimintaa tarkkailevia ja tuloksia kerääviä osia. Käytännössä käytetään melkein aina yhdistelmää molemmista strategioista
Järjestelmätestaus Järjestelmätestauksessa varmistetaan, että järjestelmä toimii määrittelynsä mukaisesti (ja käyttöohjeensa). Testauksen voi suorittaa ulkopuolinen ryhmä (suositeltavaa) Virheiden korjaus kallista. testataan ei toiminnalliset ominaisuudet: luotettavuus-, toipumis-, turvallisuus- ja kuormitustestit (vasteajat, volyymit). Yhteensopivuus muiden järjestelmien kanssa. Muita testauksen muotoja kenttätestaus hyväksymistestaus alfatestaus betatestaus regressiotestaus release testing käytettävyystestaus suorituskykytestaus...
Testitapausten valinta Testidata syöte ohjelmalle testaustarkoitukseen Testitapaus (test case) testidata testausjärjestelmään ja sitä vastaava spesifikaatioiden perusteella tehty ennustus suorituksen tuloksesta mikäli ohjelmisto toimii oikein Perusstrategioita testitapausten valintaan Lasilaatikkotestaus, rakenteellinen-, sisäinen testaus (white-box testaus, classbox testing) ohjelman rakenne (koodi) tunnetaan polkutestaus (paht testing): testitapaukset valitaan siten että mahdolliset suorituspolut koodissa tulevat kattavasti läpikäytyä täysi kattavuus ei ole mahdollista Harmaalaatikkotestaus tunnetaan ohjelman toteutusperiaatteita joita käytetään hyväksi testitapausten valinnassa Testitapausten valinta Mustalaatikkotestaus, toiminnallinen-, ulkoinen testaus (Black-box testaus, functional testing) testaus perustuu ohjelman ulkoisesti havaittavaan toimintaan testitapaukset valitaan spesifikaatioiden perusteella, ohjelmasta ei tiedetä mitään (musta laatikko) syöte suoritus tulos ok? avainkysymys on testitapausten valinta siten että virheiden löytyminen on todennäköistä ekvivalenssi-ositus ek vivalenssiositus: jaetaan syötteet (ja tulosteet) ekvivalenssiluokkiin, mikä tahansa arvo luokassa edustaa koko luokkaa. Valitaan joka luokasta yksi arvo. raja-arvoanalyysi: Valitaan ekvivalenssiluokista rajatapaukset. voidaan soveltaa sekä syöteavaruuteen että tulosavaruuteen. Virheenarvaus (tarkastuslista tavallisimmista virheistä).
Testauksen kattavuus white box Valittu polku 14 Tällä modulilla on 10 erilaista Suorituspolkua! loop < 20 X Käytetään kontrolloitua polkutestausta, pyritään kattavuuteen muilla määritelmillä loop < 20 X Polkutestaus - testauksen riittävyys kattavuusmitoilla Polkutestauksessa testitapaukset valitaan siten että tietty kattavuuskriteeri saadaan täyttymään testauspolitiikka määrää kattavuuden Kattavuusmittoja polkutestaukselle Lausekattavuus: Int palkka 100% => jokainen lause suoritetaan vähintään kerran. if ehto {... Palkka=123...} Heikkoudet return Palkka Ei ota huomioon haarautumisia kontrollirakenteissa joten paljon jää suorittamatta ei ota huomioon modulin sisäisen tilan vaikutusta lauseen suoritukseen
Testauksen riittävyys kattavuusmitoilla Päätöskattavuus (haarakattavuus, decision coverage): jokainen ehtolauseke saa vähintään kerran molemmat arvonsa (T/F), ts. ehdollisen rakenteen molemmat haarat suoritetaan. McCaben kompleksisuusmitta antaa testiajojen vähimmäismäärän Yleisesti vaadittava minimikattavuus Heikkous: ehtojen kaikkia osia, saatikka sitten kombinaatioita ei testata If (palkka>1000) orf (ylitoita andf paivitaylityot()>1000) {...} else {...} Testiaineistot: palkka=1234 (ehtolauseke tosi) ja palkka=0, ylitoita=epätosi (ehtolauseke epätosi) (orf = &&, andf = ) Testauksen riittävyys kattavuusmitoilla Ehtokattavuus (condition coverage): jokainen ehtolausekkeen osa (or/and-yhdistämä) saa vähintään kerran molemmat arvonsa (T/F). Ei impilikoi välttämättä päätöskattavuutta: If (palkka>1000) and (ylitoita) {...} else {...} Testiaineistot: palkka=1234 ja ylitoita=epätosi (ehtolauseke epätosi) ja palkka=0, ylitoita=tosi (ehtolauseke epätosi) (huom : and on tässä normaali and-operaatio, ei c-tyylinen oikoevaluointi) Vaatimalla sekä päätös/ehtokattavuus korjataan yo. ongelman.
Testauksen riittävyys kattavuusmitoilla Moniehtokattavuus (multiple condition coverage): jokainen päätös evaluoidaan vähintään kerran kaikilla mahdollisilla ehtojen totuusarvojen yhdistelmillä. If (palkka>1000) orf (ylitoita andf paivitaylityot()>1000) {...} else {...} 1 2 3 4 palkka>0 T F F F ylitoita - F T T paivitaylityot()>1000 - - T F Päätös/moniehtokattavuus vaatii lisäksi päätöskattavuuden. Testauksen riittävyys kattavuusmitoilla Polkukattavuus: kaikki suorituspolut (lukukumäärä, silmukoiden käsittely). Montako polkua? i=0 while i<20 loop if ehto1 then if ehto2 then L1 else L2; else if ehto3 then L3 else L4; end while Funktiokattavuus: onko rajapinnan kaikkia funktioita testattu. Kutsukattavuus: onko kaikki funktiokutsut suoritettu. Silmukkakattavuus: silmukat suoritettu 0, 1 ja monta kertaa. Tilakattavuus: kaikki tilat&tilasiirtymät Poikkeuskattavuus...
Kattavuusmitat käytännössä Kannattaa mitata: tarkoituksena on löytää puutteita testiaineistossa, ei niinkään todistaa testauksen perusteellisuutta. Prosenttilukujen tulkinnassa kannattaa olla varovainen suuri kattavuus ei välttämättä tarkoita hyvää testausta mitat eivät välttämättä ole keskenään vertailukelpoisia 100% kattavuus käytännössä usein mahdottomuus Yleensä tavoitteena esimerkiksi 85% kattavuus (lause- tai päätöskattavuus) Kattavasti testattu ei ole kattavasti testattu. Kattavuus ei ota huomioon olion tilaa. Milloin testattu riittävästi?
Milloin testattu riittävästi? Mutkikkuusmitat: Voidaan arvioida mm. koodin laatua (esimerkiksi alihankinnat), ohjelman "rispaantumista" ylläpidossa ja testauksen vaativuutta. Halsteadin mitta: lähinnä historiallista merkitystä McCaben syklomaattinen numero G on ohjelman kontrolliverkko ja c päätösten määrä Ohjelman syklomaattinen numero v(g) = c+1 Virheiden kylväminen Ohjelmassa X virhettä (X tuntematon). Kylvetään N virhettä. Testauksessa löytyy X' oikeaa virhettä ja N' kylvettyä virhettä. Oletetaan, että X'/X = N'/N. Siis ohjelmassa on yhteensä X = X'N/N' virhettä, joista vielä X-X' kpl on löytämättä. sovellettavissa myös tarkastusmenettelyyn Black Box - Testauksen kattavuus (toiminnallinen testaus) Testattavan syöteavaruuden kattaminen on mahdotonta Arvoaluetestaus (domain testing) Arvoalue syntyy syötemuuttujan tyypistä sekä spesifikaatiossa määritellyistä rajoista, modulin käyttörajapinnan esiehdoista Esim. kokonaislukusyöte x, sallitut arvot x? [0, 200] Valitaan testitapauksiin Tapaus arvoalueen sisältä Arvoalueen rajat Tapaukset heti arvoalueiden ulkopuolelta Esimerkissä testitapauksiksi tulisivat arvot 50, 0, 200, -1, 201 Ekvivalennsitestaus Arvoalueet jaetaan ekvivalenssiluokkiin joille on voimassa Jokainen ekvivalenssiluokan arvo antaa saman testituloksen (toimii oikein tai ei) Käytännössä: paljastaa virheen samalla todennäköisyydellä Testitapauksia valitaan yksi jokaisesta ekvivalenssiluokasta Ekvivalenssiluokan rajat valitaan myös testitapauksiksi
Black Box - Testauksen kattavuus Ekvivalenssiluokkien määrittely Aiempi arvoalueen jakaminen: arvoalueen sisältä ja ulkoa Syötteet ovat jollain perusteella samaan luokkaan kuuluvia Tulosteet ovat jollain perusteella samaan luokkaan kuuluvia Luokittelu sellaisten ominaisuuksien mukaan jotka todennäköisimmin aiheuttavat virheitä Modulin (julkisesta) määrittelystä Syötteet jotka ovat esiehdon mukaisia Syötteet jotka eivät ole esiehdon mukaisia Syötemuuttujien rakenteesta Esim. vektorista tyhjä vektori, yksialkioinen, monialkioinen, järjestetty, Black Box testitapausten valinta esimerkki: binäärihaku procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Pre-condition -- the array has at least one element T FIRST <= T LAST Post-condition -- the element is found and is referenced by L ( Found and T (L) = Key) or -- the element is not in the array ( not Found and not (exists i, T FIRST >= i <= T LAST, T (i) = Key ))
Esimerkki jatkuu syötteen ekvivalenssipartitiot 1) Esiehdot täyttyvät, etsitty arvo taulukossa 2) Esiehdot täyttyvät, etsitty arvo ei taulukossa 3) Esiehdot eivät täyty, etsitty arvo taulukossa 4) Esiehdot eivät täyty, etsitty arvo ei taulukossa 5) Taulukossa vain yksi alkio 6) Taulukossa parillinen määrä alkioita 7) Taulukossa pariton määrä alkioita 8) Etsitty arvo taulukossa ensimmäisenä, viimeisenä 9)... Kohdat 5-9 voidaan lukea myös rakenteelliseen testaukseen, sillä näiden ekvivalenssiluokkien perusteet löytyvät koodista Syötteen ekvivalenssipartitiot ja testitapaukset Array Single value Single value More than 1 value More than 1 value More than 1 value More than 1 value Element In sequence Not in sequence First ele ment in sequence Last element in sequence Middle element in sequence Not in sequence Inp ut sequ ence (T) Key (Key) Output (Found, L) 17 17 true, 1 17 0 false,?? 17, 29, 21, 23 17 true, 1 41, 18, 9, 31, 30, 16, 45 45 true, 7 17, 18, 21, 23, 29, 41, 38 23 true, 4 21, 23, 29, 33, 38 25 false,??
Testaustyökalut Testikattavuusanalysaattorit Purify, Bounds Checker: osoitinongelmat, muistivuodot Profilointiohjelmat Vertailuohjelmat Testipetigeneraattorit, testiskriptit Emulaattorit, simulaattorit Nauhoitustyökalut, kuormageneraattorit Testauksen automatisointi? Testausympäristö, testipenkki testidatan generaattori spesifikaatio lähde koodi testipeti testidata oraakkeli profiloija testattava ohjelma testi tulokset testi ennusteet suoritus raportti simulaattori vertaaja raportti generaattori Testin tulosraportti
Testausprosessi Määrittelydokumentaatio Kokemus, tarkastuslistat Suunnitteludokumentaatio Laatujärjestelmän ohjeistus Vanha testaussuunnitelma Testauksen suunnitelu Testisuunnitelma Testaus Testiraportit Testauksen suunnittelu Projektisuunnitelma: mitä dokumentteja tuotetaan, kuka tuottaa ja milloin Sopimus ja/tai sen liitteet: Hyväksymiskoesuunnitelma joka kuvaa hyväksymiskriteerit, joita asiakas testaa hyväksymistestissä. Testauksesta saattaa olla hyvä tuottaa erillinen yleissuunnitelma: kuka vastaa ja mistä (mm. testiympäristöjen pystyttäminen jne.). Järjestelmätestaussuunnitelma: määrittelydokumentissa tai erillisenä dokumenttina. Integrointitestaussuunnitelma: suunnitteludokumentissa tai erillisenä dokumenttina. Moduulitestaus: Kunkin moduulin määrittelyyn liittyy testiympäristön määrittely ja testitapausten määrittely. Voi olla yleisohje, ei välttämättä erillistä suunnitelmaa
Testaussuunnitelma 1. Johdanto. 2. Testauksen kohde ja tavoitteet. 3. Testausympäristö. 4. Testauksen organisointi ja raportointi. 5. Testausstrategia ja integrointisuunnitelma. 6. Testattavat toiminnot. 7. Toimintojen testitapaukset, hyväksymiskriteerit. 8. Ei-toiminnallisten ominaisuuksien testaus. 9. Erikoistilanteet. 10. Ominaisuudet, joita ei testata. 11. Testauksen lopettamiskriteeri Seuranta Testeistä syntyy testiraportteja poislukien modulitestaus Asiakasreklamaatiot dokumentoitava. Laatujärjestelmän kehittämiseksi virheet on analysoitava ja tilastoitava virheiden löytymis-, syntymis- ja korjausajankohdat, testauksen kattavuusmitat, virheiden luokittelu (mild, moderate, annoying, disturbing, serious, very seriuos, extreme, intolerable, catastrophic, infectious) testauksen riittävyyttä voidaan parhaiten arvioida kokemukseen nojautuen
Oliokeskeisyyden vaikutus testaukseen Suurin vaikutus moduli- ja integraatiotestaus vaikea erottaa toisistaan Olioparadigmassa käytetään usein inkrementaalisia prosessia Ei eroja järjestelmätestaustasolla (?) Top-Down? Onko Top tasoa olemassa? Bottom-up? Onko edes hierarkiaa olemassa? Klusteritestaus! Alemmilla testaustasoilla lisäongelmia aiheuttavat periytyminen ja dynaaminen sitominen. Kun jotain on peritty, onko se testattava uudelleen? Vastaus näyttäisi (ikävä kyllä) olevan myönteinen. Vain hyvin yksinkertaisten funktioiden tapauksessa voi olla varma, että kantaluokalle tehty testaus riittää. Jos perityssä funktiossa käytetään dynaamista sitomista, ei voida olla varmoja funktion toimivuudesta uudessa ympäristössä. Kattavuus? Kaikki dynaamista sitomista sisältävät pitää testata päätöskattavasti (kutsukohtahan on tavallaan ehdollinen haarautuminen olion tyypin perusteella). OO testaus Luokan testaus vastaa modulitestausta Integrointitestauksessa kolme strategiaa Integroitavat ja testattavat klusterit pitää löytää jollakin tavalla sillä selvää hierarkiaa ei ole. Kolme tapaa Use-case testing (tai skenaariotestaus) Integroitavat ja testattavat klusterit muodostetaan suoraan käyttötapauksista Thread testing Integroidaan ja testataan tapahtumia (event) vastaan luokat jotka suorittuvat yhdessä säikeessä Klusteri testaus Ideana testata modulien (luokkien) klustereita jotka yhdessä aikaansaavat jotkut tietyt palvelut (one collaboration)
OO testaus Testaustasot Olioiden operaatioiden testaus (vastaa jotakuinkin funktion whitebox testausta) Luokkien testaus Kattavuusmitat? Kaikki operaatiot Kaikkien attribuuttien arvon asetus ja luku Kaikkien olion mahdollisten tilojen läpikäynti Yhteistyöklustereiden testaus (black box) Koko järjestelmän testaus (ei oo-erityispiirteitä) Luokkatestaus (esimerkki) WeatherStation identifier reportweather () calibrate (instruments) test () startup (instruments) shutdown (instruments) Test cases are needed for all operations Use a state model to identify state transitions for testing Examples of testing sequences Shutdown? Waiting? Shutdown Waiting? Calibrating? Testing? Transmitting? Waiting Waiting? Collecting? Waiting? Summarising? Transmitting? Waiting
Integrointitestaus (Skenaario perustainen esimerkki) :CommsController request (report) acknowledge () report () :WeatherStation summarise () :WeatherData send (report) reply (report) acknowledge () Thread of methods executed CommsController:request? WeatherStation:report? WeatherData:summarise Inputs and outputs needed for the test Input of report request with associated acknowledge and a final output of a report Can be tested by creating raw data and ensuring that it is summarised properly Use the same raw data to test the WeatherData object Interface testing (~rajapintatestaus) Osa integrointitestausta testataan integroitavien modulien, luokkien tai alijärjestelmien rajapintojen yhteensopivuus pyritään havaitsemaan virheitä joko rajapintojen toteutuksessa tai väärissä oletuksissa ja tulkinnoissa Erityisen tärkeä oliosuuntautuneissa järjestelmissä, modulit määritellään rajapintojensa kautta Test cases A B C
Interface testing rajapinta- ja virhetyyppejä Parametrirajapinta normaali datan välitys modulista toiseen Jaettuun muistiin perustuva rajapinta Metodi-rajapinta Tavallinen olion (tai ADT:n) julkinen rajapinta Viestivälitykseen perustuva rajapinta Palvelupyyntö viestinä, tulokset paluuviestinä Jotkut oliojärjestelmät, client-server arkkitehtuurit Väärin käytetty rajapinta kutsuva komponentti käyttää rajapintaa väärin Väärin ymmärretty rajapinta kutsuja olettaa rajapinnan palveluista jotain mikä ei pidä paikkansa Ajoitusvirheet kutsuja ja kutsuttava toimivat eri nopeuksilla, tarjolla oleva informaatio on vanhentunutta (esimerkiksi) Interface testing suunnittelun ohjeita Käytä testejä jotka aiheuttavat kutsuissa parametreille arvoja arvoalueen rajoilta Jos rajapinnassa välitetään osoittimia, testaa aina null-osoitin. Käytä testejä jotka aiheuttavat varmasti epäonnistumisen. Poikkeustilanteiden käsittely on yleisin rajapinnoissa väärin tulkittu alue. Viestinvälitykseen perustuvat rajapinnat on testattava suurilla volyymeillä, stress testing. Lisäät todennäköisyyttä löytää ajoitusvirheitä. Jaettuun muistiin perustuvissa rajapinnoissa, rajapintaa käyttävien modulien aktivointijärjestystä pitää vaihdella.
Kansanviisauksia Testauksen suorittaa joku muu kuin tekijä. Teoksessa [Kit 1995] on esitetty otsakkeen The Six Essentials of Software Testing alla seuraavat perusperiaatteet. The quality of the test process determines the success of the test effort. Prevent defect migration by using early life-cycle testing techniques. The time for software testing tools is now. A real person must take responsibility for improving the testing process. Testing is a professional discipline requiring trained, skilled people. Cultivate a positive team attitude of creative destruction. Tuotekehitysprojektissa järjestelmätestauksen loppuvaihe kestää pitempään, kuin osaat kuvitella edes pahimmissa painajaisunissasi. Kokeile, mutta älä luule, että se on testausta, suunnitelmallisuus on valttia. Test now or pay later; the later you find it, the more you pay.... kansanviisauksia A good test can never save a bad program. Älä poista testauspiirteitä ohjelmasta. Suorita "apinatestejä, ota pistoke irti seinästä. Tee/testaa muutokset ja lisäykset riittävän pieninä annoksina. Virheet kasaantuvat: jos jostain on löytynyt useita virheitä, lähistöllä on niitä vielä lisää. Dynaamisen muistin määrän kehityksestä kannattaa pitää kirjaa (roskaantuminen, satunnaiset kuormitushuiput). Tarkasta vielä kerran laskennan virhetilanteet: nollalla jako, yli/alivuodot sekä liukulukujen pyöristys. Tee myös testipetit kunnolla, suurin osa ajasta kuluu muuten virheiden hakuun testipeteistä. Jos poikkeustilanteita käsittelevää koodia on vähän, kaikkia poikkeustilanteita ei ole vielä otettu huomioon.
Reaaliaikajärjestelmien testauksen kansanviisaudet Motto: sulautetun ohjelmiston testaus alkaa siitä, mihin tavallisen ohjelmiston testaus loppuu. Testattavuus on otettava jo suunniteltaessa huomioon ja ohjelmoitava järjestelmään mukaan. Tuotantoversiossakin voi olla testauspiirteitä, jotka saa tarvittaessa kytkettyä toimintaan. Ensin sarjallisesti mahdollisimman perusteellisesti. Mahdollisimman pitkään kehityslaitteistossa ja sitten simulaattoreita ja emulaattoreita hyväksikäyttäen. Kriittiset osat on katselmoitava huolellisesti ja mahdollisesti todistettava oikeiksi (tai edes perusteltava vakuuttavasti, miksi kuviteltu riski ei pääse toteutumaan). Seuraa CPU:n käyttöastetta varsinkin muutosten jälkeen. Seurannan voi toteuttaa joko kellokeskeytyskäsittelijässä tai matalimman prioriteetin taustaprosessina. Kerää tilastoa poikkeustapauksista: menetetyt kellokeskeytykset ja oheislaitteiden ohjauksessa sekä tiedon siirrossa tapahtuneet virheet. Seinäkelloa voi tarpeen mukaan nopeuttaa tai hidastaa. Nopeuttamalla kelloa saadaan esimerkiksi koko vuosi nopeasti testattua. Tärkein asia viimeiseksi Automatisoi Testing is the testaus process mahdollisimman of exercising pitkälle a program with the specific intent of finding Automatisoitu errors prior to testaus delivery on to kääntäjän the end user. laajennos joka tarkistaa ohjelmistosi semantiikan!