1 / 17

Integrointitestaus (1/17)

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.

nam
Download Presentation

Integrointitestaus (1/17)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related