integrointitestaus 1 17 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Integrointitestaus (1/17) PowerPoint Presentation
Download Presentation
Integrointitestaus (1/17)

Loading in 2 Seconds...

play fullscreen
1 / 17

Integrointitestaus (1/17) - PowerPoint PPT Presentation


  • 73 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Integrointitestaus (1/17)' - nam


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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.
  • 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.
integrointitestaus 2 17
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.
integrointitestaus 3 17
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.
integrointitestaus 4 17
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ä.
integrointitestaus 5 17
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.
integrointitestaus 6 17
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.
integrointitestaus 7 17
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
integrointitestaus 8 17
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.
integrointitestaus 9 17
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.
integrointitestaus 10 17

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)
integrointitestaus 11 17
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.

integrointitestaus 12 17
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.

integrointitestaus 13 17
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.
integrointitestaus 14 17
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.
integrointitestaus 15 17
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).
integrointitestaus 16 17
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.
integrointitestaus 17 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.