Sisältö Integrointitestaus Antti Tevanlinna, tutkija, Helsingin yliopisto, Tietojenkäsittelytieteen laitos Yleinen teoreettinen pohja Mitä on integrointitestaus Integrointitestauksen tarve Integrointitestauksen rajat Klassinen näkemys Ylhäältä alas vai toisinpäin? Tyngistä Lähestymistapoja eri tilanteisiin 2 Integrointitestaus Yleinen teoreettinen pohja Integroida (eng. integrate); yhdistää, laittaa yhteen Integrointitestaus on Erillisten ohjelmiston (yksikköinä testattujen) osien (metodi, luokka, komponentti, ohjelma, ) vuorovaikutuksen, yhteistoiminnan ja muodostuvan kokonaisuuden oikeellisuuden arviointia Laajentaa Laajennos BLuokka m1() m2() Ohjelmistokehys Komponentti ALuokka Käyttää/ laajentaa,.. Ohjelma a Putkitus, ORB-kutsu Ohjelma b Kutsuu metodia() metodib() 4 Skooppi, focus ja locus Integrointitestaus prosessina Elementti (focus) Metodi Luokka Ryväs Alijärjestelmä Skooppi, konteksti (scope) Luokka Ryväs Alijärjestelmä (komponentti) Järjestelmä Yhteystyyppi (virheiden locus) Muuttujat ja Metodikutsut Luokkien väliset viestit (LVV), jaetut muuttujat LVV, jaetut muuttujat, IPC LVV, IPC, RPC, ORB- ja KJ-palvelut Integrointitestaus on osa testausta Integrointitestausprosessi on testausprosessin aliprosessi Integrointitestausprosessi vastaa samoihin kysymyksiin kuin testausprosessi Mitä, kuka, miten, milloin, millä työkaluilla? Aliprosessit jälleen eri skoopeille Metodi, luokka jne. Tuottaa virheraportteja ja tietoa järjestelmän tai sen osien laadusta eri konteksteissa Luokkatasolta aina arkkitehtuuritasolle Jos (automatisoituja) integrointitestejä on valmiina ennen toteutusta, testit tuottavat hyödyllistä tietoa ohjelmoinnin etenemisestä Hyödynnettäessä arkkitehtuuri- ja suunnittelutason dokumentteja niistä voidaan paikantaa epäselvyyksiä, puutteita ja jopa virheitä 5 6 1
Integrointitestauksen tarve Integrointitestausta tarvitaan teoreettisesti Antidekompositioaksiooma: järjestelmä on enemmän kuin mitä sen ulkokuori antaa ymmärtää Antikompositioaksiooma: järjestelmä on enemmän kuin sen osat yhteensä Käytännössä vähentämään kokonaisen ohjelman testaustarvetta Vähentämään testien määrää Nostamaan testaustehokkuutta Pienentämään havaittavien vikojen etsintäaluetta Aikaisempi korkean tason virheiden löytäminen Testauksen systematisointi Esimerkkivirhe Testienvalmistelija Luo testitapauksen Asettaa mm. luokkapolun Kääntäjä kääntää Testitapauksen käyttäen Testitapauksen tietoja Kääntäjä kaatuu, jos luokkapolku on null Virhe Kääntäjän oletuksissa Testienvalmistelijasta tai Testienvalmistelijan oletuksissa Kääntäjästä Riippuu määritelmistä (, jos ne ottavat tilanteen huomioon) XML XML Testienvalmistelija valmistatesti() asetacp( CP c ) annacp() Kääntäjä käännä() 7 8 Integrointivirheitä Arvoaluevirheet Väärät parametrit viestissä Väärän metodin kutsuminen / väärän luokan käyttö Operaation/luokan esiehtojen rikkominen Väärä käyttöprotokolla Viestin vastaanottaja väärä aliluokka Virheellinen olion alustus Muistinhallinta Väliohjemiston tai KJ:n väärä käyttö Prosesseihin liittyvät virheet Konfigurointivirheet (tiedostot, lähdekoodi, ) Tiedon eheys tietovarastossa Resurssien loppuminen Palvelija - - -200-200 -20-10 -1 Virhe 1 200 Integrointitestauksen rajat Antidekompositio- ja antikompositioaksiooma Integrointitestaus ei ole tehokasta korkean tason eitoiminnallisien ominaisuuksien puutteiden havaitsemisessa, vaikkakin näitäkin voidaan havaita Suorituskyky Luotettavuus Integrointitestaus on vaikeata tai jopa mahdotonta, kun ohjelmiston rakenne ei salli sen hajottamista osiin. Esimerkiksi spagettikoodi, vahva ja turha kytkentä estävät tehokkaan integrointitestauksen Modulaarisuus ja design for testability (testattavuus) Käyttöliittymät useimmiten vaikeita integrointitestata Suunnittele testattava ydin ja minimaalinen käyttöliittymä Älä sekoita käyttöliittymäkoodia toiminnalliseen koodiin 9 10 Yksikkö-, Integrointi ja järjestelmätestaus Yksikkötestaus on kiinnostunut yhden osan toiminnan oikeellisuudesta Järjestelmätestaus on kiinnostunut koko järjestelmän toiminnasta Suoritetaan järjestelmän tarjoamien käyttörajapintojen kautta Testaustasojen raja on häilyvä Korkean tason integrointitestit kelpaavat järjestelmätesteiksi Korkean tason yksikkötestit kelpaavat integrointitesteiksi Testejä voi käyttää uudelleen eri tasoilla Huomattava tarkistaa onko testillä tehoa uudella tasollaan 11 Yksikkö-, Integrointi ja järjestelmätestaus Inkrementaalisessa ohjelmistokehityksessä (kuten olioohjelmointi) integrointitestaus sekoitetaan usein yksikkötestaukseen Uusi luokka (yksikkö)testataan kontekstissaan Korkean tason integrointitestaus suoritetaan osana järjestelmätestausta Mm. alkuperäinen XP ei sisällä vastinetta integrointitestaukselle Jatkuva integrointi Toimii pienessä mittakaavassa Yksikkötason ja järjestelmätason väli on pieni TDD, Tuoteperheet 12 2
Kytkentä ja integrointi Integrointitestausjärjestyksiä ja tynkiä Ohjelmiston osien yhteistyö on mahdollista (vain) kytkennän avulla Ohjelmiston osat voivat olla kytkettyinä toisiinsa mm. oikean puolen taulukon tavoilla Lista ei ole täydellinen, koska erityyppisiä yhteyksiä voidaan aina ohjelmoida lisää Koostaminen Perintä Globaali muuttuja API-kutsut Palvelinoliot Parametrinä annetut oliot (kopiointi ja viitteet) Geneeristen luokkien tyyppiparametrit Tiedostot, tietokannat 14 Integrointitestaus on kytkentäpohjaista Integrointitestauksen ensimmäisiä toimintoja on kytkentöjen löytäminen Näiden perusteella muodostetaan erillisten yhdistämis- ja testausjärjestys lasilaatikkomenetelmä Tietolähteitä Arkkitehtuuri (looginen ja kehitysnäkymä) Suunnittelu (luokkakaaviot) Koodi Ihmiset Löytämistapoja Takaisinmallinnustyökalut (UML-työkalut, Rita, Rigi, Eclipse, ) Dokumenttien lukeminen Käsityö Kirjoittaa Lukee 15 16 Kytkentäkaaviot käytännössä Integrointitestausesimerkit ovat aina karkeita yksinkertaistuksia Esimerkiksi järjestelmä joka sisältää luokkaa ja 500 metodia ja sen jokainen luokka käyttää kahta muuta luokkaa sekä jokainen metodi käyttää kahta muuta metodia Sisältää 200 luokkayhteyttä ja 0 metodiyhteyttä Suuret järjestelmät sisältävät jopa tuhansien luokkien alijärjestelmiä Toisin kuin esimerkeissä, kaaviot ovat syklisiä verkkoja eivätkä puita start abst. execute rollback execute Alhaalta ylöspäin -integrointitestaus Aloitetaan riippuvuuspuun lehdistä. Asetetaan testatuksi joukoksi lehdet Loop kunnes ei testaamattomia solmuja Kasvatetaan testattavaa joukkoa puun solmuilla (tai solmulla), jotka käyttävät vain testatun joukon tarjoamia palveluita Testataan testattava joukko Asetetaan testattava joukko testatuksi joukoksi Ajurit kutsuvat integroitavien puiden juuria 17 18 3
Ylhäältä alaspäin -integrointitestaus Aloitetaan riippuvuuspuun juuresta Asetetaan testatuksi joukoksi juuri Asetetaan testattavaksi joukoksi juuri Loop kunnes ei testaamattomia solmuja Kasvatetaan testattavaa joukkoa puun testaamattomilla solmulla (solmuilla), joiden palveluita käyttää (ainoastaan) testattu joukko Testataan testattava joukko Asetetaan testattava joukko testatuksi joukoksi Ajurit kutsuvat integroidun puun juurta 19 20 Etuja ja haittoja Alhaalta ylös -integrointi Ei tarvita tynkiä (paitsi muuten saavuttamattomien tilanteiden, kuten poikkeusten, aiheuttamiseen) Kontrollihierarkiassa matalan tason virheet löytyvät aikaisin Mahdollistaa erillisten ryppäiden rinnakkaisen integroinnin Testaus voidaan aloittaa kontrollihierarkian lehtien valmistuttua Korkean tason ongelmat ja niiden korjaukset voivat vaatia muutoksia jo testattuun matalan tason toiminnallisuuteen Oraakkelit tarkastavat matalan tason sopimusten toteutumisen Testitapaukset ovat riippuvaisia toteutuksesta Testitapaukset muistuttavat yksikkötestejä Toteutuksen muuttuessa useita testejä joudutaan muokkaamaan 21 22 Etuja ja haittoja Ylhäältä alas -integrointi Ohjelman prototyyppi käytössä testauksen ajan Virheet korkean tason kontrollissa tulevat esiin aikaisessa vaiheessa On ongelmallista suunnitella testitapauksia, jotka saavuttavat matalan tason toiminnallisuuden käyttäen ainoastaan korkealta tason palveluita kontrollihierarkiassa Testaus voidaan aloittaa kontrolli-hierarkian juuren valmistuttua Vaikka korkean tason kontrolli testataan aikaisin, muutokset matalalla tasolla voivat vaatia muutoksia testatussa osassa Testitapauksen ilmoittaessa virheestä on selvitettävä johtuiko se tyngistä vai testattavasta tuotteesta Oraakkelit tarkastavat korkean tason yhteistoiminnan onnistumisen Testitapaukset muistuttavat järjestelmätestejä Testitapaukset eivät ole erityisen riippuvaisia toteutusyksityiskohdista Tyngät Ylhäältä alas integroinnissa testataan osaa saavutettavasta riippuvuuspuusta Jotta osa olisi suoritettavissa on sen riippuvuuksia eliminoitava Riippuvuuksia poistavia ohjelmiston osia kutsutaan tyngiksi Stub (eng.) Minimaalinen toteutus tarvittavalle palvelulle Asetetaan vastaanottamaan asiakkaana olevan metodin, olion tai komponentin lähettämät viestit Tarjoaa yleensä ennalta määritellyn paluuarvon ilman algoritmia Voi ohjata asiakkaansa toimintaa palauttamalla asiakkaan toimintaan vaikuttavia arvoja 23 24 4
Tynkien hinta Tynkien valmistukseen ja ylläpitoon käytetyt resurssit muodostavat suuren osan integrointitestauksen kuluista Otettava huomioon testausta suunniteltaessa Pahimmassa tapauksessa useita tynkiä joudutaan tuottamaan jokaista testitapausta kohden Tynkäkoodi ei lisää ohjelmiston toiminnallisuutta Tynkien valmistus on aikaavievää, mahdollisesti vaikeaa ja useimmiten suorastaan tylsää Tynkiä on pidettävä yllä luokkien ja rajapintojen muuttuessa Tynkiä on vaikeampi valmistaa koodin tuottamisen loputtua Esim. Java-kielen final-metodien syrjäyttäminen Huonosti hallittuna muuttuu käyttökelvottomaksi yhtä lailla kuin tuotekoodi Uudelleenkäyttö Tynkä(suunnittelu)malleja versio1 Luokkatynkä versio2 Valitaan käännös-, linkitys- tai latausaikana Perintätynkä Tynkä voi olla luokka, komponentti tai alijärjestelmä tynkä Tynkä 25 26 Tynkä(suunnittelu)malleja Testitapauksen ja tyngän yhteys mahdollista myös asiakkaan iteraktioden Varmistaminen (yksikkötestaus) Tynkä Mock-olio Self-shunt Alustaa testitilaan voi olla luokka, komponentti tai alijärjestelmä Kontrolloitu edustaja Käyttää Edustaja (proxy) Delegoi jos ei ole testitilassa Tyngät käyttöön helposti Vältä olioiden luotikoodin sekoittamista muuhun koodiin Tällöin on helppoa vaihtaa käytetty palveleva olio tynkään Käytä esimerkiksi Factory method suunnittelumallia Vältä staattista koodia, jota ei voi syrjäyttää Käytä rajapintoja (täysin abstrakteja luokkia) kohdissa, joissa tynkien käyttö on todennäköistä Rajapinnalle on huomattavasti helpompi tehdä tynkiä Modernit kehitystyökalut tukevat tynkien valmistusta rajapinnan eristäminen tyngän luonti muuttujan tyypin muuttaminen rajapinnan tyyppiseksi Modernien ohjelmointikielten ominaisuuksia voidaan hyödyntää Tynkiä voi luoda puoliautomaattisesti ajoaikana Mock objects mm. Java- ja.net-ympäristöissä Aspect oriented programming Ohjelman suorituksessa mm. metodikutsujen kohteisiin ja paluuarvoihin voi vaikuttaa 27 28 Big Bang -integrointitestaus Testataan kaikki järjestelmän osat kerralla Pistetään järjestelmä päälle ja katsotaan toimiiko se ; Tietenkään se ei toimi Ongelmia Testaus ei ole keskittynyttä Virheen aiheuttajaa on vaikeata paikallistaa Silti toimiva Pienessä mittakaavassa (esim. Ryväs) Koodin muuttuessa vain osin (regressiotestaus) Ei tarvita tynkiä eikä osittaisia testattavia konfiguraatioita Nopea suorittaa (tosin voi olla tehoton) Mahdollista myös jakamattomalle spagettikoodille Osoittaa järjestelmän tai sen osan minimaalisen valmiuden järjestelmätestauksen tai laajemman kontekstin integrointitestauksen aloittamiseen 29 30 5
Yhteistyöpohjainen integrointitestaus Määritellään yhteistyö loogiseksi järjestelmän osien toiminnaksi vastauksena syötteeseen (kuten näppäimen painallukseen) Loop kunnes ei testaamattomia yhteistöitä Asetetaan testattavaksi joukoksi yhteistyöhön osallistuvat solmut tai Kasvatetaan testattavaa joukkoa yhteistyöhön osallistuvilla solmuilla Testataan testattava yhteistyö Asetetaan yhteistyö testatuksi Ajurit kutsuvat integroitavan yhteistyön juurta Jos yhteistyö testataan erikseen on vielä tehtävä kokonaisen järjestelmän integrointi Käytännössä yhteistyön Big bang Mahdollista myös alhaalta ylös integrointi yhteistyön sisällä Päivitäkurssit Nostarahaa Keskuspankki 31 32 Integrointitestaus luokalle Lähestymistapoja eri skooppeihin Entry-kriteerit Luokan metodit testattu yksiköinä Integrointistrategia Alhaalta ylös integrointi luokan sisällä voidaan suorittaa metodien käyttöjärjestyksessä (konstruktorit, aksessorit, muuttajat, iteraattorit, tuhoajat) Big bang integrointi luokan sisällä ten suunnitteluun tarvittava tieto Luokkasuunnitelmat Lasilaatikkotieto käytettyjen palveluiden löytämiseksi ja suorittamiseksi Exit-kriteerit iteraatiossa Suunnitellut testitapaukset suoritettu päätöskattavuus integroitavassa osassa ja kutsukattavuus (kannattaa myös harkita vahvempaa integrointikattavuutta) integroitavan osan ja muun rakenteen välillä 34 Integrointitestaus ryppäälle Entry-kriteerit Luokat testattu yksiköinä Integrointistrategia Esitellyt strategiat sovellettavissa. Ylhäältä alas vain jos ryppäällä on selvä käyttörajapinta ten suunnittelu Luokkassuunnitelmat, arkkitehtuuri Tarvittaessa lasilaatikkotieto kytkennän muihin ryppäisiin löytämiseksi ja suorittamiseksi Exit-kriteerit iteraatiossa Suunnitellut testitapaukset suoritettu Lause- ja kutsukattavuus integroitavassa osassa ja polymorfinen kutsukattavuus integroitavan ja muiden rakenteiden välillä Integrointitestaus järjestelmälle Entry-kriteerit Komponentit/alijärjestelmät testattu yksiköinä Integrointistrategia Ylhäältä alas (ohjelmistokehykset) Yhteistyöpohjainen Alhaalta ylös ten suunnittelu Arkkitehtuuri, käyttötapaukset, vaatimusskenaariot Tarvittaessa lasilaatikkotieto alijärjestelmien sekä näiden suhteiden löytämiseksi ja suorittamiseksi Exit-kriteerit iteraatiossa Suunnitellut testitapaukset suoritettu Kutsukattavuus integroitavan ja integroidun osan välillä 35 36 6
Integrointistrategian muistilista Tunnista ja määrittele integrointitestaus osaksi testausprosessia Tue ohjelmiston kehitystä jatkuvasti tuottamalla tietoa ohjelmiston osien integroinnin laadusta Integrointitestaus ei ole saareke testausvaiheessa Integroi integrointitestaus osaksi tuotantoprosessia Harkitse säännöllistä integrointitestausta päivittäin, viikoittain, kuukausittain Valitse sopivat integrointistrategiat Säädä inkrementin koko strategiassa Pienet inkrementit: paljon kierroksia, ja testikoodia sekä useita testattavia konfiguraatioita Suuret inkrementit: suurempi alue katettavana inkrementissä ja pidempi inkrementin suoritusaika Integrointistrategian muistilista Minimoi ajuri- ja tynkäkoodin määrää Hallitse kuten tuotekoodia ja käytä uudelleen myös näitä Valitse sopiva testitapausten suunnittelutapa Sopivia malleja löydettävissä mm. Binderin kirjasta osista luokat, komponentit, alijärjestelmät ja järjestelmät Yleensä mustalaatikkomenetelmä, mutta riippuen tavoitteista myös lasilaatikkomenetelmiä on sovellettavissa Testattavuus maksaa lisäkulunsa takaisin Tarkasta kattavuus mahdollisuuksien mukaan Valitse tehokkaat työkalut riippuvuuksien löytämiseen, konfiguraationhallintaan, testien suoritukseen ja kattavuuden laskentaan 37 38 Kiitti Käyttäkää Rita-työkalua Integrointitestauksen harjoitustehtäviä on huomattavasti helpompi tehdä työkalun avulla Osallistukaa tutkimukseen Integrointitestauslähteitä Kirjoja Binder: Testing object-oriented systems Myers: Software reliability Beizer: Software testing techniques McGregor & Sykes: A practical guide to testing object-oriented software Sommerville: Software engineering Pressman: Software engineering Kurssimuistiinpanoja Paakki: Ohjelmistojen testaus Katara: Ohjelmistojen testaus http://www.cs.tut.fi/~testaus/luennot/ Papereita Jorgensen & Erickson: Object-oriented integration testing CACM 94 numero 9 Hartmann et. Al.: UML-based integration testing ISSTA 00 Mackinnon et. Al.: Endo-testing: Unit testing with Mock objects XP2000 Le Traon et. Al.: Efficient Object-oriented integration and regression testing IEEE Transactions on reliability 00 numero 1 39 40 7