Hvad er integrationstest (tutorial med integrationstesteksempel)

what is integration testing

Hvad er integrationstest: Lær med eksempler på integrationstest

Integrationstest udføres for at teste modulerne / komponenterne, når de er integreret for at kontrollere, at de fungerer som forventet, dvs. at teste de moduler, der fungerer fint individuelt, ikke har problemer, når de er integreret.

Når vi taler med hensyn til test af stor applikation ved hjælp af black box testteknik, involverer kombinationen af ​​mange moduler, der er tæt forbundet med hinanden. Vi kan anvende koncepterne til integrationstestteknik til at teste disse typer scenarier.

Liste over selvstudier, der er dækket af denne serie:

Tutorial # 1: Hvad er integrationstest? (Denne vejledning)
Tutorial # 2: Hvad er inkrementel test
Tutorial # 3: Hvad er komponenttest
Tutorial # 4: Kontinuerlig integration
Tutorial # 5 Forskellen mellem enhedstest og integration
Tutorial # 6: Top 10 integrationstestværktøjer

Hvad du vil lære:

• Hvad er integrationstest?
• Hvorfor Integration Test?
• Fordele
• Udfordringer
• Typer af integrationstest
  • Big Bang-tilgang:
• Testintegrationsmetoder
  • Bottom-up tilgang:
  • Top-down tilgang
• GUI-applikationsintegrationstest
  • Eksempel på integrationstest:
• Skridt til at starte integrationstests
• Indgangs- / udgangskriterier for integrationstest
• Integrationstest tilfælde
• Er integration en hvid kasse eller sort kasse-teknik?
• Integrationstestværktøjer
• Systemintegrationstest
• Forskel mellem integrationstest og systemtest
• Konklusion
• Anbefalet læsning

Hvad er integrationstest?

Betydningen af ​​integrationstest er ret ligetil- Integrer / kombiner det enhedstestede modul en efter en og test opførselen som en kombineret enhed.

Hovedfunktionen eller målet med denne test er at teste grænsefladerne mellem enhederne / modulerne.

Vi foretager normalt integrationstest efter “Enhedstest”. Når alle de enkelte enheder er oprettet og testet, begynder vi at kombinere disse “Unit Tested” moduler og begynder at udføre den integrerede test.

Hovedfunktionen eller målet med denne test er at teste grænsefladerne mellem enhederne / modulerne.

De enkelte moduler testes først isoleret. Når modulerne er enhedstestet, integreres de en efter en, indtil alle modulerne er integreret, for at kontrollere kombinationsadfærden og validere, om kravene er implementeret korrekt eller ej.

Her skal vi forstå, at integrationstest ikke sker i slutningen af ​​cyklussen, men snarere udføres samtidig med udviklingen. Så i de fleste gange er alle modulerne faktisk ikke tilgængelige til test, og her er udfordringen at teste noget, der ikke eksisterer!

Hvorfor Integration Test?

Vi føler, at integrationstest er kompleks og kræver en vis udvikling og logisk dygtighed. Det er rigtigt! Hvad er formålet med at integrere denne test i vores teststrategi?

Her er nogle grunde:

1. I den virkelige verden, når applikationer er udviklet, opdeles det i mindre moduler, og individuelle udviklere tildeles 1 modul. Den logik, der implementeres af en udvikler, er helt anderledes end en anden udvikler, så det bliver vigtigt at kontrollere, om den logik, der er implementeret af en udvikler, er som forventet og gengiver den korrekte værdi i overensstemmelse med de foreskrevne standarder.
2. Mange gange ændres ansigtet eller datastrukturen, når den bevæger sig fra et modul til et andet. Nogle værdier tilføjes eller fjernes, hvilket forårsager problemer i de senere moduler.
3. Moduler interagerer også med nogle tredjepartsværktøjer eller API'er, som også skal testes for, at de data, der accepteres af dette API / værktøj, er korrekte, og at det genererede svar også er som forventet.
4. Et meget almindeligt problem ved testning - Hyppig ændring af krav! :) Mange gange udvikler implementerer ændringerne uden at enheden tester det. Integrationstestning bliver vigtig på det tidspunkt.

Fordele

Der er flere fordele ved denne test, og få af dem er angivet nedenfor.

• Denne test sikrer, at de integrerede moduler / komponenter fungerer korrekt.
• Integrationstest kan startes, når modulerne, der skal testes, er tilgængelige. Det kræver ikke, at det andet modul skal udfyldes, for at test kan udføres, da stubs og drivere kan bruges til det samme.
• Det registrerer fejl relateret til grænsefladen.

Udfordringer

Nedenfor er der få udfordringer, der er involveret i Integration Test.

# 1) Integrationstest betyder test af to eller flere integrerede systemer for at sikre, at systemet fungerer korrekt. Ikke kun integrationslinkene skal testes, men der bør foretages en udtømmende test i betragtning af miljøet for at sikre, at det integrerede system fungerer korrekt.

Der kan være forskellige stier og permutationer, der kan anvendes til at teste det integrerede system.

#to) Administration af integrationstest bliver kompleks på grund af få faktorer, der er involveret i det som databasen, platformen, miljøet osv.

# 3) Mens det integrerer ethvert nyt system med det ældre system, kræver det en masse ændringer og testindsats. Det samme gælder, når der integreres to arvssystemer.

# 4) Integration af to forskellige systemer udviklet af to forskellige virksomheder er en stor udfordring for, hvordan et af systemerne vil påvirke det andet system, hvis der ikke foretages ændringer i et af systemerne, er ikke sikkert.

For at minimere påvirkningen under udviklingen af ​​et system skal der tages nogle få ting i betragtning som mulig integration med andre systemer osv.

Typer af integrationstest

Nedenfor er en type testintegration sammen med dens fordele og ulemper.

Big Bang-tilgang:

Big bang tilgang integrerer alle modulerne på én gang, dvs. det går ikke til at integrere modulerne en efter en. Det verificerer, om systemet fungerer som forventet eller ikke en gang integreret. Hvis der opdages et problem i det fuldt integrerede modul, bliver det svært at finde ud af, hvilket modul der har forårsaget problemet.

Big bang-tilgang er en tidskrævende proces med at finde et modul, der i sig selv har en defekt, da det ville tage tid, og når først manglen er opdaget, vil det at reparere det koste højt, da manglen opdages på det senere tidspunkt.

Fordele ved Big Bang-tilgang:

• Det er en god tilgang til små systemer.

Ulemper ved Big Bang-tilgang:

• Det er vanskeligt at opdage det modul, der forårsager et problem.
• Big Bang-tilgang kræver alle moduler sammen til test, hvilket igen fører til mindre tid til test, da design, udvikling og integration ville tage det meste af tiden.
• Test finder kun sted med det samme, hvilket derved ikke giver tid til kritisk modultest isoleret.

Trin til integrationstest:

1. Forbered integration Testplan.
2. Forbered integrationsscenarier og testtilfælde.
3. Forbered testautomatiseringsskripter.
4. Udfør testsager.
5. Rapporter manglerne.
6. Spor og test igen manglerne.
7. Gentest og test fortsætter, indtil integrationstesten er afsluttet.

Testintegrationsmetoder

Der er grundlæggende to tilgange til testintegration:

1. Bottom-up tilgang
2. Top-down tilgang.

Lad os overveje nedenstående figur for at teste fremgangsmåderne:

Bottom-up tilgang:

Bottom-up-test, som navnet antyder, starter fra applikationens laveste eller inderste enhed og bevæger sig gradvist op. Integrationstesten starter fra det laveste modul og skrider gradvist mod applikationens øvre moduler. Denne integration fortsætter, indtil alle modulerne er integreret, og hele applikationen testes som en enkelt enhed.

I dette tilfælde er modulerne B1C1, B1C2 & B2C1, B2C2 det laveste modul, som er enhedstestet. Modul B1 og B2 er endnu ikke udviklet. Funktionaliteten af ​​modul B1 og B2 er, at det kalder modulerne B1C1, B1C2 & B2C1, B2C2. Da B1 og B2 endnu ikke er udviklet, har vi brug for et program eller en “stimulator”, der kalder modulerne B1C1, B1C2 & B2C1, B2C2. Disse stimulatorprogrammer kaldes KØRERE .

Med enkle ord, KØRERE er de dummy-programmer, der bruges til at kalde funktionerne i det laveste modul i tilfælde, hvor opkaldsfunktionen ikke findes. Bottom-up-teknikken kræver, at moduldriver tilfører input til testcase til grænsefladen på det modul, der testes.

Fordelen ved denne fremgangsmåde er, at hvis der findes en større fejl i programmets laveste enhed, er det lettere at opdage den, og der kan træffes korrigerende foranstaltninger.

Ulempen er, at hovedprogrammet faktisk ikke eksisterer, før det sidste modul er integreret og testet. Som et resultat registreres designfejlene på højere niveau kun i slutningen.

Top-down tilgang

Denne teknik starter fra det øverste modul og udvikler sig gradvist mod de nederste moduler. Kun det øverste modul er enhedstestet isoleret. Herefter integreres de nederste moduler en efter en. Processen gentages, indtil alle modulerne er integreret og testet.

grundlæggende SQL-spørgsmål og svar til nybegyndere

I forbindelse med vores figur starter test fra modul A, og nedre moduler B1 og B2 er integreret en efter en. Her er de nederste moduler B1 og B2 faktisk ikke tilgængelige for integration. Så for at teste de øverste moduler A udvikler vi “ STUBMER ”.

'Stubs' kan kaldes kode et uddrag, der accepterer input / anmodninger fra topmodulet og returnerer resultaterne / svaret. På denne måde, på trods af de nederste moduler, findes der ikke, vi er i stand til at teste det øverste modul.

I praktiske scenarier er stubers opførsel ikke så enkel, som den ser ud. I denne æra af komplekse moduler og arkitektur, det kaldte modul, involverer det meste af tiden kompleks forretningslogik som at oprette forbindelse til en database. Som et resultat bliver oprettelse af stubs lige så kompleks og tidskrævende som det virkelige modul. I nogle tilfælde kan Stub-modulet vise sig at være større end det stimulerede modul.

Både stubbe og drivere er dummy stykke kode, der bruges til at teste de 'ikke-eksisterende' moduler. De udløser funktionerne / metoden og returnerer svaret, som sammenlignes med den forventede adfærd

Lad os konkludere en forskel mellem Stubbe og driver :

Den eneste ændring er konstant i denne verden, så vi har en anden tilgang kaldet “ Sandwich test ”Som kombinerer funktionerne i både Top-down og bottom-up tilgang. Når vi tester enorme programmer som operativsystemer, skal vi have nogle flere teknikker, der er effektive og øger mere selvtillid. Sandwichtest spiller en meget vigtig rolle her, hvor både top-down og bottom up-test startes samtidigt.

Integration starter med mellemlaget og bevæger sig samtidigt opad og nedad. I tilfælde af vores figur starter vores test fra B1 og B2, hvor en arm vil teste det øvre modul A og en anden arm vil teste de nederste moduler B1C1, B1C2 & B2C1, B2C2.

Da begge fremgangsmåder starter samtidigt, er denne teknik en smule kompleks og kræver flere mennesker sammen med specifikke færdigheder og tilføjer dermed omkostningerne.

GUI-applikationsintegrationstest

Lad os nu tale om, hvordan vi kan antyde integrationstest i Black box-teknik.

Vi forstår alle, at en webapplikation er en multitier-applikation. Vi har en frontend, der er synlig for brugeren, vi har et mellemlag, der har forretningslogik, vi har noget mere mellemlag, der udfører nogle valideringer, integrerer nogle tredjeparts-API'er osv., Så har vi det bageste lag, som er database.

Eksempel på integrationstest:

Lad os kontrollere nedenstående eksempel:

Jeg er ejer af et reklamefirma, og jeg sender annoncer på forskellige websteder. I slutningen af ​​måneden vil jeg se, hvor mange mennesker der så mine annoncer, og hvor mange mennesker der klikkede på mine annoncer. Jeg har brug for en rapport for mine annoncer, der vises, og jeg debiterer tilsvarende for mine kunder.

GenNext software udviklet dette produkt til mig og nedenunder var arkitekturen:

LØG - Brugergrænseflademodul, som er synligt for slutbrugeren, hvor alle input er givet.
BL - Er Business Logic-modulet, som har alle beregningerne og forretningsspecifikke metoder.
VAL - Er valideringsmodulet, der har alle valideringer af korrektheden af ​​input.
CNT - Er indholdsmodulet, der har alt det statiske indhold, specifikt for de input, der er indtastet af brugeren. Dette indhold vises i rapporterne.
I - Er motormodulet, dette modul læser alle data, der kommer fra BL, VAL og CNT-modulet og udtrækker SQL-forespørgslen og udløser dem til databasen.
Planlægning - Er et modul, der planlægger alle rapporter baseret på brugervalg (månedligt, kvartalsvis, halvårligt og årligt)
DB - Er databasen.

Efter at have set arkitekturen for hele webapplikationen som en enkelt enhed vil Integrationstest i dette tilfælde fokusere på datastrømmen mellem modulerne.

Spørgsmålene her er:

1. Hvordan vil BL, VAL og CNT-modulet læse og fortolke de data, der er indtastet i UI-modulet?
2. Modtager BL, VAL og CNT-modulet de korrekte data fra brugergrænsefladen?
3. I hvilket format overføres dataene fra BL, VAL og CNT til EQ-modulet?
4. Hvordan læser EQ dataene og udtrækker forespørgslen?
5. Uddrages forespørgslen korrekt?
6. Får planlæggeren de korrekte data til rapporter?
7. Er resultatsættet modtaget af EN fra databasen korrekt og som forventet?
8. Er EN i stand til at sende svaret tilbage til BL, VAL og CNT-modulet?
9. Er UI-modul i stand til at læse dataene og vise dem korrekt til grænsefladen?

I den virkelige verden foregår kommunikationen af ​​data i et XML-format. Så uanset hvilke data brugeren indtaster i brugergrænsefladen, bliver de konverteret til et XML-format.

I vores scenarie konverteres dataene i UI-modulet til XML-fil, som fortolkes af de 3 moduler BL, VAL og CNT. EN-modulet læser den resulterende XML-fil, der er genereret af de 3 moduler, og udtrækker SQL fra den og spørger ind i databasen. EN-modulet modtager også resultatsættet og konverterer det til en XML-fil og returnerer det tilbage til UI-modulet, der konverterer resultaterne i brugerlæsbar form og viser det.

I midten har vi planlægningsmodulet, der modtager resultatsættet fra EN-modulet, opretter og planlægger rapporterne.

Så hvor integrationstest gør kommer ind i billedet?

Nå, at teste om oplysningerne / dataene flyder korrekt eller ej, er din integrationstest, som i dette tilfælde ville validere XML-filerne. Er XML-filerne genereret korrekt? Har de de korrekte data? Overføres dataene korrekt fra et modul til et andet? Alle disse ting testes som en del af integrationstest.

Prøv at generere eller hente XML-filer og opdatere tags og kontrollere adfærd. Dette er noget meget forskelligt fra den sædvanlige test, som testere normalt gør, men dette vil tilføje værdi til testernes viden og forståelse af applikationen.

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

• Genererer menuindstillingerne det rigtige vindue?
• Er vinduerne i stand til at påkalde vinduet under test?
• For hvert vindue skal du identificere de funktionskald til det vindue, som applikationen skal tillade.
• Identificer alle opkald fra vinduet til andre funktioner, som applikationen skal tillade
• Identificer reversible opkald: lukning af et kaldt vindue skal vende tilbage til vinduet, der ringer.
• Identificer irreversible opkald: vinduer, der ringer, lukkes, inden det kaldte vindue vises.
• Test de forskellige måder at udføre opkald til et andet vindue f.eks. - menuer, knapper, nøgleord.

Skridt til at starte integrationstests

1. Forstå arkitekturen i din applikation.
2. Identificer modulerne
3. Forstå hvad hvert modul gør
4. Forstå hvordan dataene overføres fra et modul til et andet.
5. Forstå hvordan dataene indtastes og modtages i systemet (indgangs- og udgangssted for applikationen)
6. Opdel applikationen, så den passer til dine testbehov.
7. Identificer og opret testbetingelserne
8. Tag en betingelse ad gangen, og skriv testcases ned.

Indgangs- / udgangskriterier for integrationstest

Indgangskriterier:

• Integrationstestplanens dokument er underskrevet og godkendt.
• Integrationstestsager er udarbejdet.
• Testdata er oprettet.
• Enhedstest af udviklede moduler / komponenter er komplet.
• Alle kritiske og høje prioritetsfejl er lukket.
• Testmiljøet er indstillet til integration.

Udgangskriterier:

• Alle sager om integrationstest er blevet udført.
• Ingen kritiske P1- og P2-defekter åbnes.
• Testrapport er udarbejdet.

Integrationstest tilfælde

Integrationstestsager fokuserer primært på interface mellem modulerne, integrerede links, dataoverførsel mellem modulerne som moduler / komponenter, der allerede er enhedstestet, dvs. funktionaliteten og de øvrige testaspekter er allerede blevet dækket.

Så hovedideen er at teste, om integration af to arbejdsmoduler fungerer som forventet, når den er integreret.

Eksempel på integrationsprøvesager for Linkedin-applikationer inkluderer:

• Bekræftelse af grænsefladeslinket mellem login-siden og hjemmesiden, dvs. når en bruger indtaster legitimationsoplysningerne og logfiler, skal den dirigeres til startsiden.
• Bekræftelse af interface-linket mellem startsiden og profilsiden, dvs. profilsiden skal åbnes.
• Bekræft grænsefladeslinket mellem netværkssiden og dine forbindelsessider, dvs. klik på accept-knappen på Invitationer på netværkssiden skal vise den accepterede invitation på din forbindelsesside, når du har klikket.
• Bekræft grænsefladeslinket mellem notifikationssiderne og sig 'Tillykke' -knappen, dvs. klik på 'Tillykke' -knappen skal vende mod det nye meddelelsesvindue.

Mange sager om integrationstest kan skrives til dette specifikke websted. Ovenstående fire punkter er kun et eksempel på, hvordan man kan forstå, hvilke integrationstestsager der er inkluderet i testningen.

Er integration en hvid kasse eller sort kasse-teknik?

Integrationstestteknik kan tælles i både sorte kasser såvel som hvid boks teknik . Black box-teknik er, hvor en tester ikke behøver nogen intern viden om systemet, dvs. kodning af viden er ikke påkrævet, mens white box-teknik har brug for intern viden om applikationen.

Under udførelse af integrationstest kan det nu omfatte test af de to integrerede webservices, som henter dataene fra databasen og leverer dataene efter behov, hvilket betyder, at de kan testes ved hjælp af testteknik i hvidboks, mens integrering af en ny funktion på webstedet kan testes ved hjælp af black box-teknikken.

Så det er ikke specifikt, at integrationstest er en sort boks eller hvid boks-teknik.

Integrationstestværktøjer

Der er flere værktøjer til rådighed til denne test.

Nedenfor er en liste over værktøjer:

• Rationel integrationstester
• Vinkelmåler
• Damp
• TESSY

For flere detaljer om ovenstående værktøjer, se denne vejledning:

Top 10 værktøjer til integrationstest til at skrive integrationstests

Systemintegrationstest

Systemintegrationstest udføres for at teste komplet integreret system .

Moduler eller komponenter testes individuelt i enhedstest, før komponenterne integreres.

Når alle modulerne er testet, udføres systemintegrationstest ved at integrere alle modulerne, og systemet som helhed testes.

Forskel mellem integrationstest og systemtest

Integrationstest er en test, hvor et eller to moduler, der er enhedstestet, er integreret til test, og verifikation udføres for at kontrollere, om de integrerede moduler fungerer som forventet eller ej.

Systemtest er en test, hvor systemet som helhed testes, dvs. alle moduler / komponenter er integreret sammen for at kontrollere, om systemet fungerer som forventet, og der ikke opstår problemer på grund af de integrerede moduler.

Konklusion

Dette handler om integrationstest og dets implementering i både White box og Black box-teknik. Håber vi forklarede det tydeligt med relevante eksempler.

Testintegration er en vigtig del af testcyklussen, da det gør det lettere at finde fejlen, når to eller flere moduler er integreret for at integrere alle modulerne sammen i det første trin.

Det hjælper med at finde manglerne på et tidligt tidspunkt, hvilket igen også sparer kræfter og omkostninger. Det sikrer, at de integrerede moduler fungerer korrekt som forventet.

Håber, at denne informative tutorial om integrationstest ville have beriget din viden om konceptet.

Anbefalet læsning

• Hvad er komponenttest eller modultest (lær med eksempler)
• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Spock til integration og funktionel test med selen
• Forskellene mellem enhedstest, integrationstest og funktionstest
• Integration af selen med JMeter
• Test af Primer eBook Download
• Funktionel testning mod ikke-funktionel testning
• Parvis test eller vejledning til test af alle par med værktøjer og eksempler