Integrointitestaus (1/17)

1. Integrointitestaus (1/17) Ainakin kaksi päämerkitystä: • Yksi testauksen taso, yksikkö- ja järjestelmätestauksen välissä. • Hyvin yksinkertaisissa järjestelmissä ei ehkä tarvita. • Laajoissa ja monimutkaisissa järjestelmissä voidaan käyttää useampiakin testaustasoja. • Millä tasolla hyvänsä testataan sellaisten osien yhteistoimintaa, jotka on aikaisemmin testattu erikseen. Huonoimmin systematisoitu ja jossakin suhteessa vaikein testauksen taso. • Teoriaa ja kirjallisuutta on etupäässä strategioista (integrointi- ja testausjärjestyksestä). • Tekniikat (mm. testitapausten valinta) huonommin tutkittuja. • Yksikkötestauksessa käsitellään pienempiä ja hallittavampia kokonaisuuksia. • Järjestelmätestauksessa tavoitteet ovat selkeämmät. • Nykyisissä ohjelmistoissa rinnakkaisuus, hajautus ja heterogeenisyys lisävaikeuksina.

2. Integrointitestaus (2/17) Kiinnostuksen pääkohteena osien väliset liittymät. • Binder (2000): Liittymät tarkoittavat komponenttien välistä suoraa vuorovaikutusta. • Lisäksi esiintyy epäsuoria vuorovaikutuksia, esim. • yhteisen palvelinkomponentin käyttö • yhteisen tietokannan käyttö • resurssiongelmat • Epäsuorien vuorovaikutusten testaamiseen ei tunnu olevan systemaattisia lähestymistapoja.

3. Integrointitestaus (3/17) Tyypillisiä vuorovaikutusvirheitä: • Asiakas kutsuu palvelua (metodia), jota ei ole toteutettu. • Asiakkaan kutsu ei vastaa palvelimen vaatimuksia (esiehtoja): • kielletty parametrin arvo • nykytilassa kielletty kutsu (modaalinen palvelin). • Palvelimen antama tulos ei vastaa asiakkaan vaatimuksia (jälkiehtoja). • Asiakas ja palvelin tulkitsevat syötteen tai tuloksen eri tavoin. Virhe voi olla kummassa tahansa (tai molemmissa). Tarvitaan yleensä enemmän regressiotestausta kuin yksikkö- ja järjestelmätasolla. • Komponentin muutos vaatii kaikkien niiden testien uusimista, joissa se on mukana. • mahdollisesti myös ylemmillä integrointitasoilla • Automaatio on tarpeen ainakin testitapausten ajamiseen ja tulosten arviointiin.

4. Integrointitestaus (4/17) Riippuvuusanalyysi • Integrointistrategiat perustuvat komponenttien välisiin riippuvuuksiin. Tyypillisiä eksplisiittisiä riippuvuuksia ryppään (läheisesti yhteenkuuluvien luokkien ryhmän) tasolla: • periytyminen • assosiaatiot ja koostaminen • riippuvuus ohjelmointirajapinnoista (API) • riippuvuus palvelinolioista • riippuvuus metodinkutsujen parametreinä käytetyistä olioista. Implisiittisiä riippuvuuksia ei käsitellä. • esim. yhteisen tietokannan käyttö Riippuvuudet esitetään yleensä suunnattuna verkkona. • Myös välilliset riippuvuudet ovat tärkeitä. • Ihannetapauksessa verkko on syklitön (DAG – directed acyclic graph). • Käytännössä sykliset riippuvuussuhteet ovat melko yleisiä.

5. Integrointitestaus (5/17) Binderin yksinkertainen esimerkki • Verkko on syklitön ja määrittelee siis luokkien välille osittaisjärjestyksen. • Tässä tapauksessa verkossa on neljä selvää tasoa.

6. Integrointitestaus (6/17) Lisähuomioita Binderin integrointistrategioista (Conformiqin kalvot) Iso pamauskin voi joskus olla järkevä vaihtoehto. • Testattavan kokonaisuuden (TK) osat liittyvät niin tiukasti toisiinsa, että osakokonaisuuksia ei pystytä testaamaan mielekkäästi. • TK on hyvin yksinkertainen ja sen osat riittävästi testattuja. • Regressiotestauksessa, kun TK on jo stabiili ja muutokset edellisen testauskierroksen jälkeen ovat pieniä. Alhaalta ylös • Tynkiä tarvitaan vähemmän kuin missään muussa strategiassa. • Voidaan tarvita esim. jos riippuvuusverkko on syklinen. • Jos sykli on lyhyt, siihen kuuluvat komponentit kannattaa yleensä paremmin integroida ja testata yhdessä. • Ääritapauksessa voi toimia samalla yksikkötestauksena. • Ajureita tarvitaan enemmän kuin missään muussa strategiassa.

7. Integrointitestaus (7/17) Toiminnallinen integrointi (collaboration integration) • Varsinkin ensiksi testattavissa toiminnoissa mukaan voi tulla paljon komponentteja kerralla. • Toiminto- tai säiekohtainen ''iso pamaus'' Muita strategioita (Binder): • Kerroksittainen integrointi (layer integration) • Selkärankaintegrointi (backbone integration) • Asiakas-palvelin-integrointi (client/server integration) • Hajautettujen palvelujen integrointi (distributed services integration) Muuan mielenkiintoinen lähestymistapa: Infuse (Kaiser ym. 1989) • Rakennetaan hierarkia (puu), jossa kaikki komponentit ovat lehtisolmuina. • Puun muut solmut (''experimental databases'', EDB) vastaavat komponenttijoukkoja. • Jokainen solmu alipuidensa unionia

8. Integrointitestaus (8/17) Esimerkki: • Pyritään yhdistämään aina sellaisia komponentteja ja EDB:eitä, joiden välillä on vahvoja kytkentöjä. • Automaatiomahdollisuus: esim. kuinka monta toistensa ominaisuutta ne käyttävät. • EDB:t testataan tässä hierarkiassa alhaalta ylöspäin. • Ei tarkoita alhaalta ylöspäin komponenttien välillä riippuvuuden mielessä! • Sekä ajureita että tynkiä voidaan tarvita.

9. Integrointitestaus (9/17) • Oletetaan esimerkissä, että A ja C tarvitsevat D:n palveluja. • Kummallekin tarvitaan D:n korvaava tynkä – voivat olla erilaisia. • ABC:n testauksessa voi olla mukana kaksi D-tynkää. • Vasta solmua ABCDEFG testattaessa todellinen komponentti D korvaa tyngät. • Kaikki alemmilla tasoilla tyngillä tehdyt testit on uusittava, kun tyngät korvataan.

10. Kattavuuskriteerejä Integrointitestaukselle ei ole yhtä yleisesti hyväksyttyjä ja tunnettuja kriteerejä kuin yksikkötestaukselle. Mustalaatikkotestaus: toimiiko TK määritelmänsä mukaisesti? • Voidaan käyttää samanlaisia menetelmiä kuin toisaalta yksikkö-, toisaalta järjestelmätestauksessa. • Myös määrittelypohjaiset kattavuusmitat samoja. Lasilaatikkotestaus: tapahtuvatko TK:n komponenttien väliset vuorovaikutukset oikein? • Tai ''harmaalaatikko'', koska komponenttien sisään ei katsota. • Tässä tarvitaan omia kriteerejä. • Yleinen mutta kovin heikko vaatimus: jokainen palvelu, jota asiakkaat ylipäänsä käyttävät, tulee testatuksi ainakin kerran. • Kattava testaus: kaikki kutsut tulevat testatuiksi kaikilla mahdollisilla syötteillä, joita asiakkaat ylipäänsä käyttävät. • Normaalisti mahdoton; myös implisiittiset syötteet (tila). Integrointitestaus (10/17)

11. Integrointitestaus (11/17) Muita mahdollisia kattavuuskriteerejä (Sneed ja Winter, 2002): • tarjotut palvelut • kutsujen parametrien (ja luokan julkisten atribuuttien yms.)ekvivalenssiluokat • aiheutetut poikkeukset • käsitellyt (siepatut) poikkeukset • atribuuttien muutokset • olioiden tilat (modaalisille luokille) • tilojen ja kutsujen yhdistelmät • tilasiirtymät • käyttötapaukset • sekvenssikaaviot (skenaariot) • olioiden luonnit • assosiaatiot. Useimmat vaativat ajonaikaista instrumentointia.

12. Integrointitestaus (12/17) Tietovuopohjaisuuden laajentaminen integrointitestaukseen (Linnenkugel ja Müllerburg 1990): • Tarkastellaan komponentin K jokaiseen ''kommunikaatiomuuttujaan'' M liittyviä DU-polkuja. • parametri, globaali muuttuja tms. • Kaikki määrittelyt: • Jokaisesta K:n ulkopuolella tapahtuvasta M:n määrittelystä johonkin K:ssa tapahtuvaan M:n käyttöön. • Jokaisesta K:ssa tapahtuvasta M:n määrittelystä johonkin K:n ulkopuolella tapahtuvaan M:n käyttöön. • Kaikki käytöt: kuten kaikki määrittelyt, mutta jokaisesta määrittelystä jokaiseen mahdolliseen käyttöön. • Muita tietovuokriteerejä voidaan soveltaa vastaavasti. • Vrt. Binderin luokanlaajuiseen vuoverkkoon (metodit komponentteina). Jin ja Offutt (1995): Kahden moduulin välisten DU-polkujen kattavuusvaatimus riippuu moduulien välisen kytkennän vahvuudesta.

13. Integrointitestaus (13/17) Arvoaluetestaus (Beizer): • Palvelimen hyväksymän parametrin arvoalueen (domain)täytyy olla vähintään sama kuin asiakkaan antaman parametrin arvoalue (range). • Virheitä (vas. asiakas, oik. palvelin): • Sovelletaan ekvivalenssiluokitusta ja raja-arvoanalyysiä kumpaankin arvoalueeseen. Sekvenssitestaus, protokollatestaus: • Modaaliselle palvelimelle. • Testataan sellaisia kutsusarjoja, joita asiakas voi tuottaa. • Usein suppeampi joukko kuin kaikki kutsusarjat, jotka palvelimen pitäisi hyväksyä. • Sovelletaan tilatestauksen periaatteita.

14. Integrointitestaus (14/17) Syntaksitestaus (Beizer) Usein komponentit lähettävät toisilleen viestejä sen sijaan, että kutsuisivat toistensa operaatioita. • Viestejä varten on usein käytännössä määritelty oma kieli. • Voi olla huonosti määritelty ''kätketty kieli''. • Myös joissakin kutsuparametrissä (ja tuloksissa) voidaan käyttää vastaavaa kieltä. • Parhaassa tapauksessa sisäisen kielen syntaksi on määritelty täsmällisesti esim. syntaksikaavioilla. • Voidaan soveltaa samanlaisia kattavuuskriteerejä kuin vuoverkkoon. • haarakattavuus • silmukoiden käsittely. • Vastaanottaja ei ehkä hyväksy kaikkia lähettäjän tuottamia viestejä. • Viestit voidaan ymmärtää eri tavalla.

15. Integrointitestaus (15/17) • Esimerkki (McGregor ja Sykes, 2001, hieman muunnettuna): Orthogonal Array Testing System (OATS) Testataan luokan C yksiparametrisen metodin kutsua. • Kohdeolio voi olla myös C:n aliluokkaa D tai E. • Parametrinä on luokan P olio. • Kutsujana on joko luokan A tai sen aliluokan B olio. • Jokaisella luokalla on 3 eri tilaa. • Tai tilojen sijasta arvojen ekvivalenssiluokkia. • Jos halutaan ottaa huomioon kaikki eri tekijät, yhdistelmiä on 3 * 2 * 3 * 3 * 3 = 162. • ''Ortogonaalisilla (suorakulmaisilla) taulukoilla'' saadaan katetuksi kaikista kahden tekijän pareista kaikki mahdolliset yhdistelmät. • Kirjallisuudessa on paljon valmiita taulukkoja. • Myös vahvempia taulukkoja (ainakin kaikista kolmen tekijän joukoista kaikki yhdistelmät).

16. Integrointitestaus (16/17) • Kunkin tekijän tilojen (arvojen, ekvivalenssiluokkien) määrä useimmisssa taulukoissa jaollinen vain 2:lla ja 3:lla. • Ortogonaalisuus tarkoittaa, että jokaisen tekijän kaikki vaihtoehdot esiintyvät yhtä monta kertaa. • Jos eri tekijöiden vaihtoehtojen määrät ovat keskenään jaottomia, ortogonaalinen taulukko ei hyödytä. Esimerkissä riittää 18 tapausta: • Sama määrä riittää vielä 1 kaksiarvoiselle ja 7 kolmiarvoiselle tekijälle.

17. Integrointitestaus (17/17) Useimpien testaustapojen ja kattavuuskriteerien ongelma: • Miten saadaan asiakaskomponentti tuottamaan kaikki halutut kutsut (tai viestit)? • Vaatii samantapaista ''käänteislaskentaa'' kuin polkujen herkistäminen ll-yksikkötestauksessa. Rinnakkaisuus tulee usein mukaan integrointivaiheessa. • Hallintamekanismit yleensä alhaisella abstraktiotasolla. • Virhemahdollisuuksia: lukkiumat, kilpailutilanteet. • Häiriöt voivat olla vaikeasti toistettavissa. • Testauskirjallisuudessa ei juuri ole systemaattisia menetelmiä rinnakkaisuuden käsittelyyn. Hajautettujen komponenttien integrointitestaus: • Hajautus voi vaikeuttaa rinnakkaisuuden ongelmia. • Toisaalta rinnakkaisten prosessien väliset vuorovaikutukset voivat olla vähäisempiä ja selkeämmin suunniteltuja kuin esim. monisäikeisessä Java-ohjelmassa. • Esim. CORBA:ssa on testaamista helpottavia mahdollisuuksia. • Instrumentointia voidaan lisätä asiakas- ja palvelinpään tynkiin.