Meny

Hva er integrasjonstesting (opplæring med eksempel på integrasjonstesting)

  • Hoved
  • Testmetoder
  • Hva er integrasjonstesting (opplæring med eksempel på integrasjonstesting)

what is integration testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er integrasjonstesting: Lær med eksempler på integrasjonstesting

Integrasjonstesting gjøres for å teste modulene / komponentene når de er integrert for å verifisere at de fungerer som forventet, dvs. å teste modulene som fungerer fint hver for seg, har ikke problemer når de er integrert.

Når vi snakker når det gjelder testing av store applikasjoner ved bruk av black box testteknikk, innebærer det kombinasjonen av mange moduler som er tett sammenkoblet med hverandre. Vi kan bruke konseptene for integrasjonstestteknikk for å teste denne typen scenarier.

Liste over opplæringsprogrammer dekket i denne serien:

Opplæring # 1: Hva er integrasjonstesting? (Denne opplæringen)
Opplæring nr. 2: Hva er trinnvis testing
Opplæring # 3: Hva er komponenttesting
Opplæring # 4: Kontinuerlig integrering
Opplæring # 5 Forskjellen mellom enhetstesting og integrasjon
Opplæring # 6: Topp 10 verktøy for integrasjonstesting

hva er integrasjonstesting

Hva du vil lære:

Hva er integrasjonstesting?

Betydningen av integrasjonstesting er ganske grei- Integrer / kombiner enhetstestet modul en etter en og test oppførselen som en kombinert enhet.

Hovedfunksjonen eller målet med denne testen er å teste grensesnittene mellom enhetene / modulene.

Vi utfører normalt integrasjonstesting etter 'Enhetstesting'. Når alle de enkelte enhetene er opprettet og testet, begynner vi å kombinere disse “Unit Tested” -modulene og begynner å gjøre den integrerte testingen.

Hovedfunksjonen eller målet med denne testen er å teste grensesnittene mellom enhetene / modulene.

De enkelte modulene testes først isolert. Når modulene er enhetstestet, integreres de en etter en, til alle modulene er integrert, for å kontrollere kombinasjonsatferden og validere om kravene er implementert riktig eller ikke.

Her skal vi forstå at integrasjonstesting ikke skjer på slutten av syklusen, men den blir utført samtidig med utviklingen. Så i de fleste tilfeller er ikke alle modulene faktisk tilgjengelige for å teste, og her er utfordringen å teste noe som ikke eksisterer!

Hvorfor integrasjonstest?

Vi føler at integrasjonstesting er kompleks og krever litt utvikling og logiske ferdigheter. Det er sant! Hva er da hensikten med å integrere denne testingen i teststrategien vår?

Her er noen grunner:

  1. I den virkelige verden, når applikasjoner er utviklet, blir den delt inn i mindre moduler, og individuelle utviklere får tildelt 1 modul. Logikken implementert av en utvikler er ganske annerledes enn en annen utvikler, så det blir viktig å sjekke om logikken implementert av en utvikler er som forventet og gir riktig verdi i samsvar med de foreskrevne standardene.
  2. Mange ganger endres ansiktet eller strukturen til data når den beveger seg fra en modul til en annen. Noen verdier legges til eller fjernes, noe som forårsaker problemer i de senere modulene.
  3. Moduler samhandler også med noen tredjepartsverktøy eller API-er som også må testes for at dataene som er akseptert av dette APIet / verktøyet er korrekte, og at det genererte svaret også er som forventet.
  4. Et veldig vanlig problem ved testing - Hyppig kravendring! :) Mange ganger utvikler distribuerer endringene uten å teste den. Integrasjonstesting blir viktig på den tiden.

Fordeler

Det er flere fordeler med denne testingen, og få av dem er oppført nedenfor.

  • Denne testingen sørger for at de integrerte modulene / komponentene fungerer som de skal.
  • Integrasjonstesting kan startes når modulene som skal testes er tilgjengelige. Det krever ikke at den andre modulen skal fullføres for at testingen skal utføres, da stubber og drivere kan brukes til det samme.
  • Den oppdager feil relatert til grensesnittet.

Utfordringer

Nedenfor er det få utfordringer som er involvert i integrasjonstest.

#1) Integrasjonstesting betyr å teste to eller flere integrerte systemer for å sikre at systemet fungerer som det skal. Ikke bare integrasjonskoblingene bør testes, men en omfattende test med tanke på miljøet bør gjøres for å sikre at det integrerte systemet fungerer som det skal.

Det kan være forskjellige baner og permutasjoner som kan brukes for å teste det integrerte systemet.

#to) Administrering av integrasjonstesting blir komplisert på grunn av få faktorer som er involvert i den, som databasen, plattformen, miljøet etc.

# 3) Mens du integrerer ethvert nytt system med det eldre systemet, krever det mange endringer og testing. Det samme gjelder når du integrerer to eldre systemer.

# 4) Integrering av to forskjellige systemer utviklet av to forskjellige selskaper er en stor utfordring for hvordan et av systemene vil påvirke det andre systemet hvis det ikke er sikkert noen endringer gjøres i et av systemene.

For å minimere påvirkningen mens du utvikler et system, bør få ting tas i betraktning som mulig integrering med andre systemer, etc.

Typer av integrasjonstesting

Nedenfor er en type testintegrasjon sammen med fordeler og ulemper.

Big Bang-tilnærming:

Big bang-tilnærmingen integrerer alle modulene på en gang, dvs. det går ikke å integrere modulene en etter en. Den verifiserer om systemet fungerer som forventet eller ikke en gang integrert. Hvis det oppdages problemer i den fullstendig integrerte modulen, blir det vanskelig å finne ut hvilken modul som har forårsaket problemet.

Big bang-tilnærming er en tidkrevende prosess for å finne en modul som har en defekt i seg selv, da det vil ta tid, og når feilen er oppdaget, vil det å reparere den koste høye når feilen oppdages på et senere tidspunkt.

Big bang tilnærming

Fordeler med Big Bang-tilnærming:

  • Det er en god tilnærming for små systemer.

Ulemper med Big Bang Approach:

  • Det er vanskelig å oppdage modulen som forårsaker et problem.
  • Big Bang-tilnærmingen krever at alle modulene er samlet for testing, noe som igjen fører til mindre tid for testing, ettersom design, utvikling, integrasjon vil ta mesteparten av tiden.
  • Testing foregår samtidig med en gang, noe som ikke gir tid til kritisk modultesting isolert.

Trinn for integrasjonstesting:

  1. Forbered integrasjon Testplan.
  2. Forbered integrasjonstestscenarier og testtilfeller.
  3. Forbered testautomatiseringsskript.
  4. Utfør testsaker.
  5. Rapporter feilene.
  6. Spor og test på nytt feilene.
  7. Re-testing og testing fortsetter til integrasjonstesten er fullført.

Test Integration Approaches

Det er fundamentalt to tilnærminger for å gjøre testintegrasjon:

  1. Bottom-up-tilnærming
  2. Top-down tilnærming.

La oss se på figuren nedenfor for å teste tilnærmingene:

Integrasjon 1

Bottom-up-tilnærming:

Bunn-opp-testing starter, som navnet antyder, fra den laveste eller innerste enheten i applikasjonen, og beveger seg gradvis oppover. Integrasjonstesten starter fra den laveste modulen og går gradvis mot de øvre modulene i applikasjonen. Denne integrasjonen fortsetter til alle modulene er integrert og hele applikasjonen blir testet som en enhet.

I dette tilfellet er modulene B1C1, B1C2 og B2C1, B2C2 den laveste modulen som er enhetstestet. Modul B1 og B2 er ennå ikke utviklet. Funksjonaliteten til modul B1 og B2 er at den kaller modulene B1C1, B1C2 & B2C1, B2C2. Siden B1 og B2 ennå ikke er utviklet, vil vi trenge noe program eller en 'stimulator' som vil kalle modulene B1C1, B1C2 og B2C1, B2C2. Disse stimulatorprogrammene kalles FØRERE .

Med enkle ord, FØRERE er dummy-programmene som brukes til å ringe til funksjonene til den laveste modulen i tilfeller der anropsfunksjonen ikke eksisterer. Bunn-opp-teknikken krever at moduldriveren mater testinngangsinngang til grensesnittet til modulen som testes.

Fordelen med denne tilnærmingen er at hvis det foreligger en større feil ved den laveste enheten i programmet, er det lettere å oppdage den, og korrigerende tiltak kan iverksettes.

Ulempen er at hovedprogrammet faktisk ikke eksisterer før den siste modulen er integrert og testet. Som et resultat vil designfeil på høyere nivå bare bli oppdaget på slutten.

Top-down tilnærming

Denne teknikken starter fra den øverste modulen og utvikler seg gradvis mot de nedre modulene. Bare toppmodulen er enhetstestet isolert. Etter dette er de nedre modulene integrert en etter en. Prosessen gjentas til alle modulene er integrert og testet.

topp markedsundersøkelsesbedrifter i verden

I sammenheng med figuren vår starter testing fra modul A, og nedre moduler B1 og B2 er integrert en etter en. Nå er de nedre modulene B1 og B2 faktisk ikke tilgjengelige for integrering. Så for å teste de øverste modulene A, utvikler vi “ STUPPER ”.

'Stubber' kan refereres til som kode en kodebit som godtar innganger / forespørsler fra toppmodulen og returnerer resultatene / svaret. På denne måten, til tross for de nedre modulene, ikke eksisterer, kan vi teste toppmodulen.

I praktiske scenarier er ikke oppførselen til stubber så enkel som den virker. I denne tiden av komplekse moduler og arkitektur, den såkalte modulen, involverer det meste komplisert forretningslogikk som å koble til en database. Som et resultat blir det å lage stubber like komplisert og tidkrevende som den virkelige modulen. I noen tilfeller kan Stub-modulen vise seg å være større enn den stimulerte modulen.

Både stubber og drivere er dummy kode som brukes til å teste de 'ikke-eksisterende' modulene. De utløser funksjonene / metoden og returnerer responsen, som sammenlignes med forventet atferd

La oss konkludere med forskjellen mellom Stubber og sjåfør :

StubberSjåfør
Brukes i Top down-tilnærmingBrukes i Bottom up-tilnærming
Toppmodulen testes førstLaveste moduler testes først.
Stimulerer det lavere nivået av komponenterStimulerer det høyere nivået av komponenter
Dummy-program med komponenter på lavere nivåDummy-program for komponent på høyere nivå

Den eneste endringen er konstant i denne verden, så vi har en annen tilnærming kalt “ Sandwich testing ”Som kombinerer funksjonene i både Top-down og bottom-up-tilnærming. Når vi tester store programmer som operativsystemer, må vi ha noen flere teknikker som er effektive og øker mer selvtillit. Sandwichtesting spiller en veldig viktig rolle her, hvor begge testene fra topp til bunn og bunn opp startes samtidig.

Integrering starter med mellomlaget og beveger seg samtidig mot opp og ned. Når det gjelder figuren vår, starter testingen vår fra B1 og B2, hvor en arm vil teste den øvre modulen A og en annen arm vil teste de nedre modulene B1C1, B1C2 & B2C1, B2C2.

Siden begge tilnærmingene starter samtidig, er denne teknikken litt kompleks og krever flere mennesker sammen med spesifikke ferdighetssett, og legger dermed til kostnadene.

GUI-applikasjon Integrasjonstest

La oss nå snakke om hvordan vi kan antyde integrasjonstesting i Black Box-teknikken.

Vi forstår alle at en webapplikasjon er en multitier-applikasjon. Vi har en frontend som er synlig for brukeren, vi har et mellomlag som har forretningslogikk, vi har noe mer mellomlag som gjør noen valideringer, integrerer noen tredjeparts APIer osv., Så har vi baklaget som er database.

Eksempel på integrasjonstesting:

La oss sjekke eksemplet nedenfor:

Jeg er eier av et annonseringsfirma og legger ut annonser på forskjellige nettsteder. På slutten av måneden vil jeg se hvor mange som så annonsene mine og hvor mange som klikket på annonsene mine. Jeg trenger en rapport for at annonsene mine skal vises, og jeg belaster kundene mine tilsvarende.

GenNext-programvare utviklet dette produktet for meg og nedenfor var arkitekturen:

Integrasjon 2

LØK - Brukergrensesnittmodul, som er synlig for sluttbrukeren, der alle inngangene er gitt.
BL - Er Business Logic-modulen, som har alle beregningene og forretningsspesifikke metoder.
VAL - Er valideringsmodulen, som har alle valideringene av riktigheten av inngangen.
CNT - Er innholdsmodulen som har alt det statiske innholdet, spesifikt for inngangene som er angitt av brukeren. Dette innholdet vises i rapportene.
I - Er motormodulen, denne modulen leser alle dataene som kommer fra BL, VAL og CNT-modulen og trekker ut SQL-spørringen og utløser den til databasen.
Planlegger - Er en modul som planlegger alle rapportene basert på brukervalget (månedlig, kvartalsvis, halvårlig og årlig)
DB - Er databasen.

Nå, etter å ha sett arkitekturen til hele webapplikasjonen, som en enkelt enhet, vil integrasjonstesting, i dette tilfellet, fokusere på datastrømmen mellom modulene.

Spørsmålene her er:

  1. Hvordan vil BL, VAL og CNT-modulen lese og tolke dataene som er lagt inn i UI-modulen?
  2. Mottar BL, VAL og CNT-modulen de riktige dataene fra brukergrensesnittet?
  3. I hvilket format overføres dataene fra BL, VAL og CNT til EQ-modulen?
  4. Hvordan vil EQ lese dataene og trekke ut spørringen?
  5. Er spørringen hentet riktig?
  6. Får planleggeren de riktige dataene for rapporter?
  7. Er resultatsettet mottatt av EN, fra databasen riktig og som forventet?
  8. Er EN i stand til å sende svaret tilbake til BL, VAL og CNT-modulen?
  9. Er UI-modulen i stand til å lese dataene og vise dem riktig til grensesnittet?

I den virkelige verden skjer kommunikasjonen av data i et XML-format. Så uansett hvilke data brukeren legger inn i brukergrensesnittet, blir det konvertert til et XML-format.

I vårt scenario konverteres dataene i UI-modulen til XML-fil som tolkes av de 3 modulene BL, VAL og CNT. EN-modulen leser den resulterende XML-filen generert av de 3 modulene og trekker ut SQL fra den og spørrer inn i databasen. EN-modulen mottar også resultatsettet og konverterer det til en XML-fil og returnerer det tilbake til UI-modulen som konverterer resultatene i brukervennlig form og viser det.

I midten har vi planleggingsmodulen som mottar resultatsettet fra EN-modulen, oppretter og planlegger rapportene.

Så hvor integrasjonstesting gjør kommer inn i bildet?

Vel, å teste om informasjonen / dataene flyter riktig eller ikke, vil være integrasjonstesten din, som i dette tilfellet vil validere XML-filene. Er XML-filene generert riktig? Har de riktige dataene? Overføres dataene riktig fra en modul til en annen? Alle disse tingene vil bli testet som en del av integrasjonstesting.

Prøv å generere eller få XML-filer og oppdater kodene og sjekk oppførselen. Dette er noe helt annet enn den vanlige testingen som testere normalt gjør, men dette vil gi testere kunnskap og forståelse av applikasjonen verdi.

Få andre prøvetestforhold kan være som følger:

  • Genererer menyalternativene riktig vindu?
  • Er vinduene i stand til å påkalle vinduet som testes?
  • For hvert vindu, identifiser funksjonskallene for vinduet som applikasjonen skal tillate.
  • Identifiser alle samtaler fra vinduet til andre funksjoner som applikasjonen skal tillate
  • Identifiser reversible samtaler: Å lukke et oppkalt vindu skal gå tilbake til anropsvinduet.
  • Identifiser irreversible anrop: anropsvinduer lukkes før anropsvinduet vises.
  • Test de forskjellige måtene å utføre samtaler til et annet vindu, f.eks. - menyer, knapper, nøkkelord.

Fremgangsmåte for å starte integrasjonstester

  1. Forstå arkitekturen til applikasjonen din.
  2. Identifiser modulene
  3. Forstå hva hver modul gjør
  4. Forstå hvordan dataene overføres fra en modul til en annen.
  5. Forstå hvordan dataene blir lagt inn og mottatt i systemet (inngangspunkt og utgangssted for applikasjonen)
  6. Separer applikasjonen for å dekke dine testbehov.
  7. Identifiser og opprett testbetingelsene
  8. Ta en tilstand om gangen og skriv ned testtilfellene.

Inngangs- / utgangskriterier for integrasjonstesting

Oppføringskriterier:

  • Integrasjonstestplandokument er signert og godkjent.
  • Integrasjonstestsaker er utarbeidet.
  • Testdata er opprettet.
  • Enhetstesting av utviklede moduler / Komponenter er komplett.
  • Alle kritiske og høye prioritetsfeil er lukket.
  • Testmiljøet er satt opp for integrering.

Utgangskriterier:

  • Alle integrasjonstestsakene er utført.
  • Ingen kritiske P1- og P2-defekter åpnes.
  • Testrapport er utarbeidet.

Integrasjonstest tilfeller

Integrasjonstestsaker fokuserer hovedsakelig på grensesnitt mellom modulene, integrerte lenker, dataoverføring mellom modulene som moduler / komponenter som allerede er enhetstestet, dvs. funksjonaliteten og de andre testaspektene har allerede blitt dekket.

Så hovedideen er å teste om integrering av to arbeidsmoduler fungerer som forventet når den er integrert.

For eksempel vil integrasjonstestsaker for Linkedin-applikasjonen omfatte:

  • Bekrefte grensesnittkoblingen mellom påloggingssiden og hjemmesiden, dvs. når en bruker skriver inn legitimasjonen og loggene, skal den sendes til hjemmesiden.
  • Bekreftelse av grensesnittkoblingen mellom hjemmesiden og profilsiden, dvs. at profilsiden skal åpne seg.
  • Bekreft grensesnittkoblingen mellom nettverkssiden og tilkoblingssidene, dvs. ved å klikke på godta-knappen på Invitasjoner til nettverkssiden, skal den godkjente invitasjonen vises på tilkoblingssiden din når du har klikket.
  • Bekreft grensesnittkoblingen mellom varslingssidene og si gratulasjonsknappen, dvs. å klikke på si gratulasjonsknappen skal rette mot det nye meldingsvinduet.

Mange integrasjonstesttilfeller kan skrives for dette nettstedet. Ovennevnte fire punkter er bare et eksempel for å forstå hvilke integrasjonstestsaker som er inkludert i testingen.

Er integrering en hvit boks eller svart boks-teknikk?

Integrasjonstesteteknikk kan telles i både svarte bokser og hvit boks teknikk . Black box-teknikk er hvor en tester ikke trenger intern kunnskap om systemet, dvs. kodingskunnskap er ikke nødvendig, mens teknikk for hvit boks trenger intern kunnskap om applikasjonen.

Nå mens det utføres integrasjonstesting, kan det inkludere testing av de to integrerte webtjenestene som henter dataene fra databasen og gir dataene etter behov, noe som betyr at de kan testes ved hjelp av testboksteknikk for hvit boks, mens integrering av en ny funksjon på nettstedet kan testes. ved hjelp av black box-teknikken.

Så det er ikke spesifikt at integrasjonstesting er en svart boks eller en hvit boks-teknikk.

Integrasjonstestverktøy

Det er flere verktøy tilgjengelig for denne testen.

Nedenfor er en liste over verktøy:

  • Rasjonell integrasjonstester
  • Vinkelmåler
  • Damp
  • TESSY

For mer informasjon om verktøyene ovenfor, sjekk denne opplæringen:

Topp 10 integrasjonstestverktøy for å skrive integrasjonstester

Systemintegrasjonstesting

Systemintegrasjonstest er gjort for å teste komplett integrert system .

Moduler eller komponenter testes individuelt i enhetstesting før komponentene integreres.

Når alle modulene er testet, gjøres systemintegrasjonstesting ved å integrere alle modulene og systemet som helhet blir testet.

Forskjellen mellom integrasjonstesting og systemtesting

Integrasjonstesting er en test der en eller to moduler som er enhetstestet er integrert for å teste og verifisering gjøres for å verifisere om de integrerte modulene fungerer som forventet eller ikke.

System testing er en testing der systemet som helhet er testet, dvs. alle modulene / komponentene er integrert sammen for å verifisere om systemet fungerer som forventet, og ingen problemer oppstår på grunn av de integrerte modulene.

Konklusjon

Dette handler om integrasjonstesting og implementering av den både i White Box og Black Box-teknikken. Håper vi forklarte det tydelig med relevante eksempler.

Testintegrasjon er en viktig del av testsyklusen, da det gjør det lettere å finne feilen når to eller flere moduler er integrert for å integrere alle modulene sammen i det første trinnet.

Det hjelper med å finne feilene på et tidlig stadium, som igjen sparer krefter og kostnader også. Det sørger for at de integrerte modulene fungerer som forventet.

Håper denne informative veiledningen om integrasjonstesting ville ha beriket din kunnskap om konseptet.

Anbefalt lesing

^