Olioohjelmien testaamisen erityisongelmia luento kurssilla Ohjelmistotestaus TIES 546

Olio-ohjelmien testaamisen erityisongelmia luento kurssilla Ohjelmistotestaus (TIES 546) 26. 2. 2010 Jyväskylän yliopisto Tietojenkäsittelytieteiden laitos Markku Sakkinen

Ensisijainen lähde: Robert V. Binder: Testing Object-Oriented Systems : Models, Patterns, and Tools Addison-Wesley 1999 (copyright 2000) XLVIII + 1191 sivua • Uudempiakin kirjoja on, mutta ei mitään yhtä laajaa ja perusteellista. Toissijaisia lähteitä (mm. ): Harry M. Sneed ja Mario Winter: Testen objektorientierter Software – das Praxishandbuch für den Test objektorientierter Client/Server-Systeme Hanser 2002 XIV + 418 sivua Paul Ammann ja Jeff Offutt: Introduction to Software Testing Cambridge University Press (New York) 2008 Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 2

Clemens Szyperski (sekä Dominik Gruntz ja Stephan Murer): Component Software : Beyond Object-Oriented Programming (2. laitos), Addison-Wesley (UK) 2002 XXXII + 590 sivua • Ei varsinaisesti käsittele testausta, mutta korostaa joitakin sellaisia olio-ohjelmien ongelmia, joita ei aina oteta huomioon. Vielä 1990 -luvun alussa monet asiantuntijat arvelivat, että olio-ohjelmien testaaminen on jokseenkin samanlaista kuin perinteisemmillä välineillä rakennettujen – tai että oliokielten ominaisuudet jopa helpottavat testausta. Myöhemmin on jouduttu huomaamaan, että olioohjelmissa on monenlaisia uusia ongelmia testaajille. Nuo entiset näkemykset eivät kuitenkaan ole täysin vääriä. • Esim. hyväksymistestauksessa ohjelmiston sisäisellä rakenteella ei ole merkitystä. • Jotkin oliokielten ominaisuudet tosiaan helpottavat esim. testipetien rakentamista. • Oliokeskeisen analyysin ja suunnittelun tuottamista malleista (esim. UML-kaavioista) voidaan johtaa testausmalleja. Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 3

Virhemallit (virhehypoteesit) Binder, 4. 1 Testauksen lähestymistavat voidaan jakaa kahteen pääluokkaan: Vastaavuuteen suuntautuva (conformance-directed) testaus pyrkii selvittämään, toteuttaako ohjelmisto vaatimuksensa ja määrittelynsä. • Testien pitää kattaa määritellyt ominaisuudet ja toiminnot tarpeeksi hyvin. • Mikä häiriö tahansa osoittaa, että ohjelmistossa on vikaa. • Varsinaisista virheistä ja niiden syistä ei olla kiinnostuneita. • Tyypillisesti mustalaatikkotestausta. Virheisiin suuntautuva (fault-directed) testaus pyrkii löytämään ohjelmistosta toteutusvirheitä. • Jotta se olisi tehokasta, tarvitaan hyvä virhemalli: millaisia virheitä (ja missä osissa) ohjelmistossa odotetaan olevan. • Deduktiivisia perusteita tai empiirisiä todisteita. • Testausstrategia ja -menetelmät perustuvat virhemalliin. • On selvää, että mm. ohjelmointikieli vaikuttaa siihen, millaiset virheet ovat todennäköisiä tai edes mahdollisia. • Sekä lasi- että mustalaatikkotestausta. Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 4

Virhemallit (jatkoa) Olio-ohjelmien tyypillisiä virheriskejä (verrattuna proseduraalisiin ohjelmiin): • Metodit ovat usein varsin lyhyitä ja rakenteeltaan yksinkertaisia. Metodien sisäiseen ohjausvuohon liittyvät virheet eivät siksi ole yhtä todennäköisiä kuin proseduraalisissa ohjelmissa. • Tiedonkätkentä on oliokielissä yleensä vahvempaa, ja siksi moduulien väliset virheelliset sivuvaikutukset ovat harvinaisempia. Globaalit muuttujat ovat usein ongelmallisia, ja niitä pyritään olio-ohjelmoinnissa välttämään. • Kirjoitusvirheet muuttujien ym. nimissä ja muut pikkuvirheet, jotka ovat toisinaan salakavalia, ovat yhtä todennäköisiä kuin ohjelmoinnissa yleensä. • Dynaaminen sidonta ja monimutkaiset periytymisrakenteet voivat aiheuttaa yllättäviä virheitä. • Rajapintavirheet ovat huomattava virhelähde proseduraalisissakin ohjelmissa. Olioohjelmissa on tyypillisesti paljon pieniä komponentteja ja siksi enemmän rajapintoja. Näin ollen rajapintoihin liittyviä virheitäkin on todennäköisesti enemmän. • Jokaisella oliolla on oma tilansa (atribuuttien arvot), mutta tilan hallinta (kelvolliset tapahtumasekvenssit) hajautuu tyypillisesti kautta koko ohjelman. Tilanhallintavirheet ovat siis todennäköisiä. Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 5

”Oliokeskeisen testauksen manifesti” Binder, 4. 5 Tehtyjä havaintoja: • Oliokeskeisyydeltä uudelleenkäytön ansiosta toivottu testaustarpeen väheneminen on pelkkä haave. • Periytyminen, polymorfismi, myöhäinen sidonta ja kotelointi (tiedon kätkentä) aiheuttavat uusia ongelmia testitapausten suunnittelulle, testattavuudelle ja kattavuusanalyysille. • Samassa määrin kuin oliokeskeinen kehitys on iteratiivista ja inkrementaalista, myös testien suunnittelun, määrittelyn ja toteutuksen täytyy olla iteratiivista ja inkrementaalista. • Regressiotestausta ja sen vaatimia asioita on pidettävä ammattitaitoisessa oliokeskeisessä kehityksessä välttämättöminä. Seuraavien perusvaatimusten pitää ohjata olio-ohjelmiston tehokasta testausta: 1. Ainutlaatuiset virheriskit 2. Oliokeskeinen testiautomaatio 3. Tehokas prosessi Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 6

Ainutlaatuiset virheriskit 1. 2. 3. 4. 5. 6. 7. Yksinään oikeiden yli- ja aliluokan metodien välinen vuorovaikutus voi olla virheellinen. Näitä vuorovaikutuksia pitää testata järjestelmällisesti. Kaukaisen yliluokan metodin syrjäyttäminen voi helposti unohtua syvässä periytymishierarkiassa. Yliluokkien testisarjat täytyy ajaa uudestaan aliluokille, ja ne on laadittava kaikille aliluokille uudelleenkäytettäviksi. Odottamattomat sidonnat, joita aiheutuu ominaisuuksien näkyvyyden vivahteista moniperinnässä, voivat aiheuttaa virheitä, jotka ilmenevät vain tietyissä yli- ja aliluokan vuorovaikutuksissa. Huonosti suunnitelluissa luokkahierarkioissa, joissa on dynaamista sidontaa (ns. polymorfiset palvelimet), aliluokat eivät aina noudata yliluokkiensa sopimuksia. Kaikkia sidontoja täytyy testata järjestelmällisesti, jotta tällaiset virheet paljastuvat. Spagettipolymorfismista aiheutuva ymmärrettävyyden katoaminen (jojo-ongelma) on virheriski. Polymorfisen palvelimen asiakasta voidaan pitää riittävästi testattuna vain, jos kaikki sen kutsujen mahdolliset sidonnat on testattu. Sellaisten luokkien, joiden metodien kutsuilla on järjestysrajoitteita, ja niiden asiakkaiden välillä voi olla kontrollivirheitä. Vaadittua käyttäytymistä voidaan testata järjestelmällisesti tilakonemallia käyttäen. Jos testausta ei ole suunniteltu systemaattisesti, sen ei voida odottaa löytävän tällaisia virheitä. Aliluokat voivat hyväksyä kiellettyjä yliluokan kutsusekvenssejä tai tuottaa virheellisiä tiloja, jos ne eivät noudata yliluokan tilamallia. Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 7

Ainutlaatuiset virheriskit (jatkoa) 8. 9. 10. 11. Luokkamallista (geneerisestä luokasta) sellaisella geneerisellä parametrillä tuotettu luokka, jolla sitä ei ole testattu, vastaa melkein sitä, että luokkamallia ei olisi ollenkaan testattu. Jokainen generoitu luokka täytyy testata. Moninkertaisuusrajoitteiden (UML: n assosiaatioissa) toteuttamisen vaikeus ja mutkikkuus voi helposti johtaa virheelliseen tilaan, kun toisiinsa liittyviä olioita lisätään tai poistetaan. Näiden rajoitteiden toteutus täytyy testata järjestelmällisesti. Virheitä voi helposti jäädä huomaamatta, jos jokin muuntava metodi tuottaa oliolle virheellisen tilan, tämä tila ei näy luokan rajapinnan kautta eikä virheellisyys estä muita operaatioita. Muuntavien ja lukevien (käyttävien) metodien sekvenssejä täytyy testata järjestelmällisesti, jotta tällaiset virheet paljastuvat. Mosaiikkimodulaarisuus ja siitä aiheutuva kontrollin hajautuminen kuuluvat olioohjelmoinnin paradigmaan. Yhtä luokkaa laajemmalle ulottuvat kontrollisuhteet ovat epäselviä. Analyysi- ja suunnittelumenetelmien kontrolliabstraktiot tällä tasolla ovat heikkoja ja tarjoavat vain osittaisia malleja. Tästä aiheutuu virheriski, joka vaatii integroituihin kontrollimalleihin perustuvaa järjestelmällistä testausta. Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 8

Oliokeskeinen testiautomaatio 1. 2. 3. 4. 5. Olio-ohjelmointiin kuuluvat kotelointi (tiedonkätkentä) ja mosaiikkimodulaarisuus heikentävät kontrolloitavuutta ja havainnoitavuutta. Testattavassa kokonaisuudessa on yleensä paljon olioita, joiden tilaa ei päästä helposti tutkimaan eikä muuttamaan. Automaatiossa on jotenkin selvittävä näistä esteistä. Testattavuuden huomioonottamattomuus suurten järjestelmien suunnittelussa voi vähentää testauksen tehokkuutta tuntuvasti. Kontrolloitavuuden ja havainnoitavuuden puutteen lisäksi ohjelmiston sisäiset riippuvuudet voivat aiheuttaa sen, että testausta täytyy suorittaa laajemmille kokonaisuuksille, kuin olisi toivottavaa. Suunnittelu testattavuutta varten on otettava huomioon kehityksen kaikissa vaiheissa. Testiajurien ja testisarjojen pitäisi vastata testattavan järjestelmän perintä-, pakkaus- ja ryväsrakennetta. Tämä menettely parantaa testisarjojen ylläpidettävyyttä ja uudelleenkäyttöä. Sopimuksiin perustuva suunnittelu väittämiä (assertions) käyttäen on suoraviivainen ja tehokas lähestymistapa sisäänrakennettuihin testeihin. Tämä strategia sekä tehostaa testausta että on hyvä virheitä ehkäisevä tekniikka. Kirjan julkaisuajankohtana mikään kaupallinen testausväline ei tarjonnut pitemmälle kuin metodeihin ja kutsupareihin (asiakkaan ja palvelimen välille) menevää kattavuusanalyysiä. Se on täysin riittämätöntä olio-ohjelmille. Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 9

Testausprosessi 1. 2. 3. Vaikka luokka on pienin luonnollinen testattava yksikkö, luokkaryväs on käytännöllinen testausyksikkö. Luokan testaaminen aivan erillään on yleensä epäkäytännöllistä. Metodit ovat merkityksettömiä luokkansa ulkopuolella, mutta niitä täytyy käyttää yksittäin luokan vastuiden testaamiseksi. Testien suunnittelun pitää olla metodikohtaista mutta perustua ryvästason vastuisiin. Testejä täytyy tehdä toteutusriippuvuuksien määräämässä järjestyksessä. Tällä tasolla testauksessa on sekä yksikkö- että integrointitestauksen piirteitä. Testien suunnittelutekniikkojen on käytettävä olemassa olevia analyysi- ja suunnittelumalleja luokkien, ryppäiden ja käyttötapausten tasolla. Jos testausmalleja joudutaan laatimaan puuttuvien, epätäydellisten tai virheellisten vaatimusten ja suunnittelumallien korvikkeeksi, niissä on noudatettava hyviksi tunnettuja suunnittelukäytäntöjä. Ihmisten suorittama suunnitteludokumenttien ja koodin tarkistaminen saattaa olla tehottomampaa kuin proseduraalisille ohjelmistoille. Näille katselmoinnit on osoitettu testausta tehokkaammiksi tietyntyyppisten virheiden poistamiseen. Oliokeskeinen koodi voi olla vaikeammin ymmärrettävää (ks. ainutlaatuisia virheriskejä). Siksi olio-ohjelmat tarvitsevat staattisten menetelmien ohella enemmän testausta samaan laadun saavuttamiseksi. Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 10

Testausprosessi (jatkoa) 4. 5. 6. Uudelleenkäytettävien komponenttien tuottajille sopiva testausstrategia on erilainen kuin komponenttien käyttäjien tai sellaisen ohjelmiston testausstrategia, jota ei ole tarkoitettu yleiseen uudelleenkäyttöön. Vaikka liialliset odotukset olio-ohjelmoinnin maagisista eduista ovat hälvenneet, jotkut kehittäjät laiminlyövät tai vähättelevät ohjelmistotekniikan perinteisiä hyviä käytäntöjä, myös testausta. Tätä asennetta on vastustettava. Luokkien testauksen täytyy olla tiiviissä yhteydessä luokkien ohjelmointiin. Oliokeskeinen yksikkötestaus edistyy nopeammalla kierrolla kuin proseduraalisessa ohjelmoinnissa. Kehitysprosessin on mahdollistettava lyhyet koodaus- ja testausjaksot. Kaikki testaus (ainakaan alijärjestelmien integrointitestaus ja järjestelmätestaus) ei kuitenkaan voi edetä näin nopeasti. Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 11

Viitteet, moninimisyys (aliasing) ja vapaakäyntisyys (reentrance) (osittain Szyperskin mukaan) Oliokielten muuttujat noudattavat enimmäkseen viitesemantiikkaa. • Esim. C++: ssa ja Eiffelissä muuttujan arvona voi olla myös itse olio viitteen sijasta. • Moni muuttuja voi viitata samaan olioon ja sama muuttuja eri aikoina eri olioihin. • Viitteet voivat muodostaa hyvin mutkikkaan suunnatun verkon. • Perinteiset lasilaatikkotestauksen tekniikat (varsinkin tietovuohon perustuvat) on suunniteltu muuttujien arvosemantiikan näkökulmasta. Ohjelmiston kutsurakenne ei yleensä ole hierarkkinen. • Takaisinkutsut (callbacks) ovat yleisiä. • Yksi alkuperäinen metodinkutsu voi aiheuttaa olioverkossa mielivaltaisen laajalle leviävän kutsusarjan. • Kontrolli voi tulla yllättäenkin uudestaan olioon, jossa on vielä metodi aktiivisena (syvemmällä kutsupinossa). • Perinteisissä ohjelmissa vapaakäyntisyyttä esiintyy yleensä vain rinnakkaisuuden takia. • Miten tarkistetaan, että olion tila ei turmellu? Olio-ohjelmien testaamisen erityisongelmia (Markku Sakkinen) 26. 2. 2010 12