Mitä integraatiotestaus on? (Esimerkki)

Mitä integraatiotestaus on?

Integraation testaus on määritelty testauksen tyypiksi, jossa ohjelmistomoduulit integroidaan loogisesti ja testataan ryhmänä. Tyypillinen ohjelmistoprojekti koostuu useista ohjelmistomoduuleista, jotka eri ohjelmoijat koodaavat. Tämän tason testauksen tarkoituksena on paljastaa vikoja näiden ohjelmistomoduulien välisessä vuorovaikutuksessa, kun ne on integroitu

Integraatiotestaus keskittyy näiden moduulien välisen tiedonsiirron tarkistamiseen. Siksi sitä kutsutaan myös nimellä "Minä & T" (Integraatio ja testaus), "Joutojen testaus" ja joskus "Säikeen testaus".

Milloin ja miksi integraatiotestausta kannattaa tehdä?

Integraatiotestausta käytetään yksikkötestauksen jälkeen ja ennen koko järjestelmätestausta. Se on hyödyllisintä tiedonkulun, jaettujen API-rajapintojen ja toisistaan ​​riippuvien moduulien varmentamisessa eri ympäristöissä. Suorittamalla integraatiotestejä varhaisessa vaiheessa tiimit voivat paljastaa rajapintojen yhteensopimattomuuksia, puuttuvia datasopimuksia ja riippuvuusongelmia, jotka yksikkötestauksessa usein jäävät huomaamatta.

Integraatiotestausta tulisi käyttää, kun useiden moduulien tai palveluiden on vaihdettava dataa, kun kyseessä on kolmannen osapuolen integraatioita ja aina kun yhden moduulin muutokset voivat vaikuttaa muihin. Se vähentää vikavuotoja, parantaa yleistä laatua ja antaa varmuutta siitä, että järjestelmä voi toimia luotettavasti ennen siirtymistä laajempaan testaukseen tai julkaisuun.

Vaikka jokainen ohjelmistomoduuli testataan yksikkökohtaisesti, vikoja esiintyy silti useista syistä, kuten

• Moduulin suunnittelee yleensä yksittäinen ohjelmistokehittäjä, jonka ymmärrys ja ohjelmointilogiikka voivat poiketa muiden ohjelmoijien ymmärryksestä ja logiikasta. Integrointitestaus on välttämätöntä sen varmistamiseksi, että ohjelmistomoduulit toimivat yhtenäisesti.
• Moduulien kehitysvaiheessa asiakkaiden vaatimuksiin voi tulla muutoksia. Näitä uusia vaatimuksia ei välttämättä testata yksikkökohtaisesti, joten järjestelmäintegraatiotestaus on välttämätöntä.
• Ohjelmistomoduulien liitännät tietokantaan voivat olla virheellisiä
• Mahdolliset ulkoiset laitteistoliitännät voivat olla virheellisiä
• Riittämätön poikkeusten käsittely voi aiheuttaa ongelmia.

Napauta tätä jos video ei ole saatavilla

Esimerkki integraatiotestitapauksesta

Integraatio Testitapaus eroaa muista testitapauksista siinä mielessä, että se keskittyy pääasiassa rajapintoihin ja tiedon/informaation kulkuun moduulien välilläTässä etusijalle on asetettava linkkien integrointi eikä yksikön toimintoja, jotka on jo testattu.

Esimerkkiintegraatiotestitapauksia seuraavalle skenaariolle: Sovelluksessa on 3 moduulia, esimerkiksi 'Kirjautumissivu', 'Mail"laatikko" ja "Poista sähköpostit", ja jokainen niistä on integroitu loogisesti.

Älä keskity liikaa kirjautumissivun testaamiseen, koska se on jo tehty kohdassa Yksikkötestaus. Mutta tarkista, miten se liittyy Mail Box Sivu.

Vastaavasti Mail BoxTarkista sen integrointi Poista-toiminnon kanssa Mails moduuli.

Testitapauksen tunnus	Testitapauksen tavoite	Testitapaus Descriptioni	odotettu tulos
1	Tarkista käyttöliittymälinkki sisäänkirjautumisen ja Maillaatikko moduuli	Syötä kirjautumistiedot ja napsauta Kirjaudu-painiketta	Ohjataan osoitteeseen Mail Box
2	Tarkista liittymän välinen yhteys Mailruutu ja Poista-painike Mails moduuli	alkaen Mailvalitse sähköpostiviesti ja napsauta poistopainiketta	Valitun sähköpostin pitäisi näkyä Poistetut/Roskakori-kansiossa

Integraatiotestauksen tyypit

Ohjelmistotekniikka määrittelee useita strategioita integraatiotestauksen suorittamiseksi, nimittäin.

• Big Bang -lähestymistapa:
• Inkrementaalinen lähestymistapa: joka on edelleen jaettu seuraaviin
  • Alhaalta ylös -lähestymistapa
  • Ylhäältä alas -lähestymistapa
  • Sandwich-lähestymistapa – Ylhäältä alas ja alhaalta ylös -yhdistelmä

Alla on eri strategiat, niiden toteutustavat ja niiden rajoitukset sekä edut.

Big Bang -testaus

Big Bang -testaus on integraatiotestausmenetelmä, jossa kaikki komponentit tai moduulit integroidaan yhteen kerralla ja testataan sitten yhtenä kokonaisuutena. Tätä yhdistettyä komponenttijoukkoa pidetään kokonaisuutena testattaessa. Jos kaikki yksikön komponentit eivät ole valmiit, integrointiprosessia ei suoriteta.

edut:

• Nopeampi asennus – Kaikki moduulit integroitu yhdellä kertaa.
• Koko järjestelmän näkymä – Tarkkaile yleistä käyttäytymistä välittömästi.
• Ei tynkiä/ajureita – Vähentää ylimääräistä kehitystyötä.
• Sopii pieniin projekteihin – Yksinkertaisemmat järjestelmät sopivat hyvin.
• Käyttäjälähtöinen – Vastaa tarkasti loppukäyttäjän kokemusta.

Haitat:

• Vaikea debugata – Vikoja on vaikeampi eristää.
• Myöhäinen vian havaitseminen – Virheitä löydettiin vasta täyden integroinnin jälkeen.
• Suuri riski – Suuret ongelmat voivat estää koko testauksen.
• Ei skaalautuva – Monimutkaisista järjestelmistä tulee hallitsemattomia.
• Huono testikattavuus – Joitakin moduuleja testattu riittämättömästi.

Inkrementaalinen testaus

In Inkrementaalinen testaus Tässä lähestymistavassa testaus tehdään integroimalla kaksi tai useampia toisiinsa loogisesti liittyviä moduuleja ja testaamalla sitten sovelluksen asianmukaista toimintaa. Sitten muut toisiinsa liittyvät moduulit integroidaan inkrementaalisesti, ja prosessi jatkuu, kunnes kaikki loogisesti liittyvät moduulit on integroitu ja testattu onnistuneesti.

Inkrementaalinen lähestymistapa puolestaan ​​suoritetaan kahdella eri menetelmällä:

• Alhaalta ylös
• Ylös alaspäin
• Sandwich-lähestymistapa

Alhaalta ylöspäin integroinnin testaus

Alhaalta ylöspäin integroinnin testaus on strategia, jossa alemman tason moduulit testataan ensin. Näitä testattuja moduuleja käytetään sitten ylemmän tason moduulien testaamiseen. Prosessi jatkuu, kunnes kaikki ylimmän tason moduulit on testattu. Kun alemman tason moduulit on testattu ja integroitu, muodostetaan seuraava moduulitaso.

Kaavioesitys:

edut:

• Varhainen moduulitestaus – Alemman tason moduulit testataan ensin.
• Helpompi virheenkorjaus – Moduulitasolla eristetyt viat.
• Ei tynkiä tarvita – Ohjainten luominen on yksinkertaisempaa.
• Luotettava perusta – Ydinmoduulit testattiin ennen korkeampia tasoja.
• Progressiivinen integraatio – Järjestelmä kasvaa tasaisesti ja luottavaisin mielin.

Haitat:

• Myöhäisen käyttäjän katselukerta – Koko järjestelmä näkyy vasta lopussa.
• Tarvitsee kuljettajia – Lisäponnisteluja ajureiden rakentamiseksi.
• Käyttöliittymä viivästetty – Huipputason rajapinnat testattiin hyvin myöhään.
• Aikaavievä – Progressiivinen integroituminen vie kauemmin.
• Testirajat – Korkean tason vuorovaikutuksessa voi jäädä huomiotta ongelmia.

Ylhäältä alas integraatiotestaus

Ylhäältä alas -integraatiotestaus on menetelmä, jossa integraatiotestaus tapahtuu ylhäältä alas ohjelmistojärjestelmän ohjausvirtaa seuraten. Ylemmän tason moduulit testataan ensin ja sitten alemman tason moduulit testataan ja integroidaan ohjelmiston toiminnallisuuden tarkistamiseksi. Tyngiä käytetään testaukseen, jos jotkin moduulit eivät ole valmiita.

edut:

• Varhainen käyttäjänäkymä – Rajapinnat testattu alusta alkaen.
• Kriittiset moduulit ensin – Korkean tason logiikka validoitiin varhaisessa vaiheessa.
• Progressiivinen integraatio – Ongelmat ratkotaan askel askeleelta.
• Ei kuljettajia tarvita – Vain kuitit vaaditaan.
• Varhainen suunnittelun validointi – Vahvistaa järjestelmäarkkitehtuurin nopeasti.

Haitat:

• Tarvitsee tynkiä – Useiden tynkien kirjoittaminen lisää vaivaa.
• Alemmat moduulit viivästyvät – Ydinmoduulit testataan myöhemmin.
• Keskeneräiset varhaiset testit – Puuttuvia tietoja integroimattomista moduuleista.
• Virheenkorjaus vaikeampaa – Virheet voivat levitä tynkistä.
• Aikaavievä – Tyngän luonti hidastaa prosessia.

edut:

• Tasapainoinen lähestymistapa – Yhdistää ylhäältä alas ja alhaalta ylös suuntautuvat vahvuudet.
• Rinnakkainen testaus – Ylä- ja alamoduulit testataan samanaikaisesti.
• Nopeampi kattavuus – Useampia moduuleja testattu aiemmin.
• Kriittiset moduulit priorisoitu – Sekä korkea että matala taso validoitu.
• Vähentynyt riski – Ongelmia havaittu molemmista päistä.

Haitat:

• Korkea monimutkaisuus – Vaikeampi suunnitella ja hallita.
• Tarvitsee kuitteja/ajureita – Lisätyötä testitelineiden kanssa.
• kallis – Tarvitaan enemmän resursseja ja aikaa.
• Keskimmäiset moduulit viivästyvät – Testattu vasta ylä- ja alaosan jälkeen.
• Ei ihanteellinen pienille järjestelmille – Yleiskustannukset ovat suuremmat kuin hyödyt.

Mitä ovat tynkät ja ajurit integraatiotestauksessa?

Tyngät ja ajurit ovat olennaisia ​​harjoitusohjelmia, jotka mahdollistavat integraatiotestauksen silloin, kun kaikki moduulit eivät ole saatavilla samanaikaisesti. Nämä testituplaohjelmat simuloivat puuttuvia komponentteja, jolloin testaus voi jatkua odottamatta täydellistä järjestelmäkehitystä.

Mitä ovat tynkät?

Tyngät ovat mallimoduuleja, jotka korvaavat alemman tason komponentteja, joita ei ole vielä kehitetty tai integroitu. Testattava moduuli kutsuu niitä, ja ne palauttavat ennalta määritettyjä vastauksia. Esimerkiksi testattaessa maksujen käsittelymoduulia, joka tarvitsee verolaskennan, tynkä voi palauttaa kiinteitä veroarvoja, kunnes varsinainen veromoduuli on valmis.

Tyngän ominaisuudet:

• Simuloi alemman tason moduulien toimintaa
• Palauttaa kiinteästi koodattuja tai yksinkertaisesti laskettuja arvoja
• Käytetään ylhäältä alas -integraatiotestauksessa
• Minimaalisen toiminnallisuuden toteutus

Mitä ovat ajurit?

Ajurit ovat tyhmiä ohjelmia, jotka kutsuvat testattavaa moduulia ja simuloivat korkeamman tason komponentteja. Ne välittävät testidataa alemman tason moduuleille ja keräävät tuloksia. Esimerkiksi tietokantamoduulia testattaessa ajuri simuloi liiketoimintalogiikkakerrosta lähettämällä kyselyitä.

Kuljettajien ominaisuudet:

• Testattavien moduulien käynnistäminen testidatalla
• Vastausten tallentaminen ja validointi
• Käytetään alhaalta ylöspäin suuntautuvassa integraatiotestauksessa
• Ohjaustestien suoritusvirta

Käytännön toteutusesimerkki

Payment Module Testing:
- Stub: Simulates tax calculation service returning 10% tax
- Driver: Simulates checkout process calling payment module
- Result: Payment module tested independently of unavailable components

Milloin kutakin käytetään?

komponentti	Käytä tynkää	Käytä ohjainta
Testausmenetelmä	Ylhäältä alas -testaus	Alhaalta ylöspäin suuntautuva testaus
Korvaa	Alemman tason moduulit	Ylemmän tason moduulit
Toiminto	Palauttaa näennäisdatan	Lähettää testidataa
Monimutkaisuus	Yksinkertaiset vastaukset	Testien orkestrointi

Tyngät ja ajurit vähentävät testausriippuvuuksia, mahdollistavat rinnakkaiskehityksen ja nopeuttavat testaussyklejä poistamalla odotusajat järjestelmän täydelliseen saatavuuteen.

Kuinka integraatiotestaus tehdään?

Integrointitestausmenettely riippumatta ohjelmistotestausstrategioista (käsitelty edellä):

1. Valmistele integraatio Testisuunnitelma
2. Suunnittele testiskenaariot, tapaukset ja komentosarjat.
3. Testin suorittaminen Tapaukset, joita seuraa vioista ilmoittaminen.
4. Vikojen seuranta ja uudelleentestaus.
5. Vaiheet 3 ja 4 toistetaan, kunnes integrointi on onnistunut.

Lyhyt DescriptIntegration Test Plans -ohjelmasta

Se sisältää seuraavat attribuutit:

• Testausmenetelmät/lähestymistavat (kuten edellä on käsitelty).
• Integrointitestauksen laajuuskohteet ja laajuuden ulkopuoliset kohteet.
• Roolit ja vastuut.
• Edellytykset integraatiotestaukseen.
• Testausympäristö.
• Riskienhallintasuunnitelmat.

Mitkä ovat integraatiotestauksen aloitus- ja lopetuskriteerit?

Aloitus- ja lopetuskriteerit määrittelevät selkeät tarkistuspisteet integraatiotestauksen aloittamiselle ja suorittamiselle, varmistaen systemaattisen etenemisen testauksen elinkaaren aikana ja samalla ylläpitäen laatustandardeja.

Pääsyperusteet:

• Yksikkötestatut komponentit/moduulit
• Kaikki korkean priorisoinnin omaavat virheet korjattu ja suljettu
• Kaikkien moduulien koodi on valmis ja integrointi onnistuu.
• Integrointitestit Suunnitelma, testitapaus, skenaariot allekirjoitettava ja dokumentoitava.
• edellytetään Testiympäristössä määritettävä integraatiotestausta varten

Poistumisperusteet:

• Integroidun sovelluksen onnistunut testaus.
• Suoritetut testitapaukset dokumentoidaan
• Kaikki korkean priorisoinnin omaavat virheet korjattu ja suljettu
• Toimitettavat tekniset asiakirjat ja niiden jälkeen julkaisutiedot.

Miten suunnittelisit integraatiotestitapauksia?

Vahva integraatiotesti validoi, miten moduulit vaihtavat tietoja todellisissa työnkuluissa. Alla on esimerkki käyttäjän kirjautumisprosessi joka yhdistää käyttöliittymän, API:n ja tietokannan kerrokset:

Vaihe	panos	Odotettu tulos
1	Käyttäjä syöttää kelvolliset tunnistetiedot kirjautumisnäytössä	Tunnistetiedot lähetetään turvallisesti todennus-API:in
2	API validoi tunnistetiedot tietokantaa vasten	Tietokanta vahvistaa käyttäjätunnuksen/salasanan osuman
3	API palauttaa todennustunnuksen	Tunniste luotiin ja lähetettiin takaisin sovellukselle
4	Käyttöliittymä ohjaa käyttäjän kojelautaan	Käyttäjäistunto luotu onnistuneesti

Tämä yksinkertainen työnkulku vahvistaa tiedonsiirron kolmen kriittisen moduulin välillä: Käyttöliittymä → API → TietokantaEpäonnistunut vaihe osoittaa tarkalleen, missä integraatio epäonnistuu, mikä auttaa tiimejä eristämään viat nopeammin kuin pelkkä järjestelmätason testaus.

Integraatiotestauksen parhaat käytännöt/ohjeet

• Määritä ensin integrointi Testistrategia jotka voitaisiin ottaa käyttöön, ja myöhemmin valmistella testitapaukset ja testidata vastaavasti.
• Tutki Archisovelluksen suunnittelu ja tunnistaa kriittiset moduulit. Nämä on testattava ensisijaisesti.
• Hanki käyttöliittymämallit osoitteesta Archirakenneryhmä ja luo testitapauksia varmistaaksesi kaikki rajapinnat yksityiskohtaisesti. Liitäntä tietokantaan/ulkoiseen laitteistoon/ohjelmistosovellukseen on testattava yksityiskohtaisesti.
• Testitapausten jälkeen testidatalla on ratkaiseva rooli.
• Pidä mallidata aina valmisteltuna ennen suorittamista. Älä valitse testidataa testitapausten suorittamisen aikana.

Yleisiä haasteita ja ratkaisuja

Integraatiotestaus tuo mukanaan ainutlaatuisia esteitä, jotka voivat vaikuttaa projektin aikatauluihin ja laatuun. Tässä ovat kriittisimmät haasteet ja niiden käytännön ratkaisut.

1. Monimutkaisten riippuvuuksien hallinta

Haaste: Useiden moduulien riippuvuudet luovat monimutkaisia ​​testausskenaarioita, joissa on kaskadoituneita virheitä.

Ratkaisu: Käytä riippuvuuksien injektointia, säilömistä (Docker) ja testausta inkrementaalisilla kerroksilla. Dokumentoi kaikki yhteydet riippuvuusmatriiseihin.

2. Keskeneräiset moduulit

Haaste: Testaus estetään, kun riippuvaiset moduulit eivät ole valmiita.

Ratkaisu: Kehitä kattavat tynkät/ajurit varhaisessa vaiheessa, käytä palveluvirtualisointia (WireMock) ja toteuttaa sopimustestausta hyvin määritellyillä rajapinnoilla.

3. Testitietojen hallinta

Haaste: Yhdenmukaisen ja realistisen testidatan ylläpitäminen eri järjestelmissä.

Ratkaisu: Toteuta automaattinen testidatan generointi, käytä tietokannan tilannevedoksia nopeisiin nollauksiin ja versionhallintatestidataa testitapausten rinnalla.

4. Ympäristön konfigurointi

Haaste: Epäjohdonmukaiset ympäristöt aiheuttavat integraatio-ongelmia.

Ratkaisu: Käytä Infrastructure as Code (IaC) -menetelmää, konttimuotoilua ympäristöpariteetin saavuttamiseksi ja konfiguraationhallintatyökaluja, kuten Ansible.

5. Integraatiovirheiden virheenkorjaus

Haaste: Useiden eri osien taustalla olevien syiden tunnistaminen on monimutkaista.

Ratkaisu: Ota käyttöön kattava lokikirjaus, käytä hajautettua jäljitystä (Jaeger/Zipkin) ja lisää korrelaatiotunnisteita pyyntöjen seuraamiseksi eri palveluissa.

6. Kolmannen osapuolen palveluintegraatio

Haaste: Ulkoisen palvelun saatavuuskatkos tai API-muutokset häiritsevät testausta.

Ratkaisu: Ulkoisten palveluiden mallit (Postman Mock Server), toteuta uudelleenyritysmekanismeja ja ylläpidä API-versioiden yhteensopivuustestausta.

7. Suorituskyvyn pullonkaulat

Haaste: Integraatiopisteistä tulee kuormituksen alla pullonkauloja.

Ratkaisu: Suorita varhainen suorituskykyprofilointi, toteuta välimuististrategioita ja käytä asynkronista viestintää tarvittaessa.

UKK

Yhteenveto