Meny

Vad är Integration Testing (Tutorial med Integration Testing Exempel)

  • Huvud
  • Testmetoder
  • Vad är Integration Testing (Tutorial med Integration Testing Exempel)

what is integration testing

Prova Vårt Instrument För Att Eliminera Problem

Vad är Integration Testing: Lär dig med exempel på Integration Testing

Integrationstestning görs för att testa modulerna / komponenterna när de är integrerade för att verifiera att de fungerar som förväntat, dvs. att testa modulerna som fungerar bra individuellt har inga problem när de är integrerade.

När vi pratar om att testa stora applikationer med testningsteknik för svart låda, innebär kombinationen av många moduler som är tätt kopplade till varandra. Vi kan använda konceptet för integrationstestteknik för att testa dessa typer av scenarier.

Lista över handledning som omfattas av denna serie:

Handledning nr 1: Vad är integrationstestning? (Denna handledning)
Handledning nr 2: Vad är inkrementell testning
Handledning nr 3: Vad är komponenttestning
Handledning nr 4: Fortsatt integration
Handledning nr 5 Skillnaden mellan enhetstestning och integration
Självstudie nr 6: Topp 10 Integrationstestverktyg

vad är integrationstestning

Vad du kommer att lära dig:

Vad är integrationstestning?

Betydelsen av integrationstestning är ganska enkel- Integrera / kombinera den enhetstestade modulen en efter en och testa beteendet som en kombinerad enhet.

Huvudfunktionen eller målet för denna testning är att testa gränssnitten mellan enheterna / modulerna.

Vi gör vanligtvis Integrationstest efter ”Unit testing”. När alla enskilda enheter har skapats och testats, börjar vi kombinera dessa 'Unit Tested' -moduler och börjar göra den integrerade testningen.

Huvudfunktionen eller målet för denna testning är att testa gränssnitten mellan enheterna / modulerna.

De enskilda modulerna testas först isolerat. När modulerna väl är enhetstestade integreras de en efter en tills alla modulerna är integrerade för att kontrollera kombinationsbeteendet och verifiera om kraven implementeras korrekt eller inte.

Här bör vi förstå att integrationstest inte sker i slutet av cykeln utan snarare utförs samtidigt med utvecklingen. Så för det mesta är alla moduler faktiskt inte tillgängliga för test och här är vad utmaningen kommer att testa något som inte finns!

Varför Integration Test?

Vi anser att integrationstestning är komplex och kräver viss utveckling och logisk skicklighet. Det är sant! Vad är då syftet med att integrera denna testning i vår teststrategi?

Här är några anledningar:

  1. I den verkliga världen, när applikationer utvecklas, är det uppdelat i mindre moduler och enskilda utvecklare tilldelas en modul. Logiken som implementeras av en utvecklare är helt annorlunda än en annan utvecklare, så det blir viktigt att kontrollera om den logik som implementeras av en utvecklare är enligt förväntningarna och ger rätt värde i enlighet med de föreskrivna standarderna.
  2. Många gånger ändras ansiktet eller datastrukturen när den går från en modul till en annan. Vissa värden läggs till eller tas bort, vilket orsakar problem i de senare modulerna.
  3. Moduler interagerar också med några tredjepartsverktyg eller API: er som också måste testas för att de data som accepteras av API: et / verktyget är korrekta och att det genererade svaret också är som förväntat.
  4. Ett mycket vanligt problem vid testning - Frekvent kravändring! :) Många gånger utvecklare distribuerar ändringarna utan att enheten testar den. Integrationstestning blir viktigt vid den tiden.

Fördelar

Det finns flera fördelar med denna testning och få av dem listas nedan.

  • Denna testning ser till att de integrerade modulerna / komponenterna fungerar som de ska.
  • Integrationstestning kan startas när modulerna som ska testas finns tillgängliga. Det kräver inte att den andra modulen ska slutföras för att testning ska kunna göras, eftersom stubbar och drivrutiner kan användas för samma.
  • Den upptäcker felen relaterade till gränssnittet.

Utmaningar

Nedan listas några få utmaningar som är involverade i Integration Test.

# 1) Integrationstest innebär att testa två eller flera integrerade system för att säkerställa att systemet fungerar korrekt. Inte bara integrationslänkarna bör testas utan en uttömmande testning med tanke på miljön bör göras för att säkerställa att det integrerade systemet fungerar korrekt.

Det kan finnas olika vägar och permutationer som kan användas för att testa det integrerade systemet.

#två) Att hantera integreringstester blir komplicerat på grund av få faktorer som är inblandade i det som databas, plattform, miljö etc.

# 3) Samtidigt som alla nya system integreras med det äldre systemet kräver det många förändringar och testinsatser. Samma gäller vid integrering av två äldre system.

# 4) Att integrera två olika system som utvecklats av två olika företag är en stor utmaning för hur ett av systemen kommer att påverka det andra systemet om inga ändringar görs i något av systemen är osäker.

För att minimera påverkan vid utveckling av ett system, bör få saker tas med i beräkningen, t ex möjlig integration med andra system etc.

Typer av integrationstestning

Nedan följer en typ av testintegration tillsammans med dess fördelar och nackdelar.

Big Bang-tillvägagångssätt:

Big bang-tillvägagångssätt integrerar alla moduler på en gång, det vill säga det går inte att integrera modulerna en efter en. Det verifierar om systemet fungerar som förväntat eller inte en gång integrerat. Om något problem upptäcks i den helt integrerade modulen blir det svårt att ta reda på vilken modul som har orsakat problemet.

Big bang-tillvägagångssättet är en tidskrävande process för att hitta en modul som har en defekt i sig eftersom det skulle ta tid och när defekten upptäcks, skulle en fixering av densamma kosta högt eftersom defekten upptäcks i det senare skedet.

Big bang-tillvägagångssätt

Fördelar med Big Bang-metoden:

  • Det är ett bra tillvägagångssätt för små system.

Nackdelar med Big Bang Approach:

  • Det är svårt att upptäcka den modul som orsakar ett problem.
  • Big Bang tillvägagångssätt kräver alla moduler tillsammans för testning, vilket i sin tur leder till mindre tid för testning eftersom design, utveckling, integration skulle ta det mesta av tiden.
  • Testning sker endast på en gång vilket därmed inte lämnar tid för kritisk modultestning isolerat.

Steg för integrationstest:

  1. Förbered integration Testplan.
  2. Förbered integrationstestscenarier och testfall.
  3. Förbered testautomationsskript.
  4. Utför testfall.
  5. Rapportera bristerna.
  6. Spåra och testa igen defekterna.
  7. Omprövning och testning fortsätter tills integrationstestningen är klar.

Testintegrationsmetoder

Det finns i grunden två metoder för att göra testintegration:

  1. Nedifrån och upp-tillvägagångssätt
  2. Top-down-tillvägagångssätt.

Låt oss överväga nedanstående figur för att testa metoderna:

Integration 1

Bottom-up-tillvägagångssätt:

Nedifrån och upp-testning, som namnet antyder, börjar från applikationens lägsta eller innersta enhet och går gradvis uppåt. Integrationstestningen börjar från den lägsta modulen och går gradvis mot applikationens övre moduler. Denna integration fortsätter tills alla moduler är integrerade och hela applikationen testas som en enhet.

I detta fall är modulerna B1C1, B1C2 och B2C1, B2C2 den lägsta modulen som är enhetstestad. Modul B1 och B2 är ännu inte utvecklade. Funktionaliteten hos modul B1 och B2 är att den kallar modulerna B1C1, B1C2 & B2C1, B2C2. Eftersom B1 och B2 ännu inte är utvecklade skulle vi behöva något program eller en 'stimulator' som kommer att kalla modulerna B1C1, B1C2 och B2C1, B2C2. Dessa stimulatorprogram kallas FÖRARE .

Med enkla ord, FÖRARE är dummy-program som används för att anropa funktionerna i den lägsta modulen om ett samtalsfunktion inte finns. Nedifrån och upp-tekniken kräver att moduldrivrutinen matar in testfallet till gränssnittet för modulen som testas.

Fördelen med detta tillvägagångssätt är att om det finns ett större fel vid programmets lägsta enhet är det lättare att upptäcka det och korrigerande åtgärder kan vidtas.

Nackdelen är att huvudprogrammet faktiskt inte existerar förrän den sista modulen har integrerats och testats. Som ett resultat kommer konstruktionsfel på högre nivå att upptäckas först i slutet.

Top-down-tillvägagångssätt

Denna teknik börjar från den översta modulen och utvecklas gradvis mot de lägre modulerna. Endast toppmodulen testas isolerat. Därefter integreras de nedre modulerna en efter en. Processen upprepas tills alla moduler är integrerade och testade.

företag som erbjuder produkttestning hemma

Inom ramen för vår figur börjar testning från modul A och nedre moduler B1 och B2 integreras en efter en. Nu är de lägre modulerna B1 och B2 inte tillgängliga för integration. Så för att testa de översta modulerna A utvecklar vi ” STUBBAR ”.

'Stubbar' kan kallas kod ett kodavsnitt som accepterar ingångarna / förfrågningarna från toppmodulen och returnerar resultaten / svaret. På detta sätt, trots de lägre modulerna, finns det inte, vi kan testa toppmodulen.

I praktiska scenarier är stubbarnas beteende inte så enkelt som det verkar. I denna era av komplexa moduler och arkitektur, den kallade modulen, involverar det mesta komplexa affärslogik som att ansluta till en databas. Som ett resultat blir skapandet av Stubs lika komplicerat och tidskrävande som den verkliga modulen. I vissa fall kan Stub-modulen visa sig vara större än den stimulerade modulen.

Både stubbar och drivrutiner är en dummy kod som används för att testa de 'icke-existerande' modulerna. De utlöser funktionerna / metoden och returnerar svaret, vilket jämförs med förväntat beteende

Låt oss dra en skillnad mellan Stubbar och förare :

StubbarFörare
Används i Top down-tillvägagångssättAnvänds i Bottom up-tillvägagångssätt
Toppmodulen testas förstLägsta moduler testas först.
Stimulerar den lägre nivån av komponenterStimulerar den högre nivån av komponenter
Dummy-program med komponenter på lägre nivåDummy-program för komponent på högre nivå

Den enda förändringen är konstant i denna värld, så vi har ett annat tillvägagångssätt som heter ” Sandwich testning ”Som kombinerar funktionerna i både Top-down och bottom-up strategi. När vi testar stora program som operativsystem måste vi ha fler tekniker som är effektiva och ökar mer självförtroende. Sandwichtest spelar en mycket viktig roll här, där både testning uppifrån och ned och startas samtidigt.

Integration börjar med mittlagret och rör sig samtidigt uppåt och nedåt. När det gäller vår figur kommer våra tester att starta från B1 och B2, där en arm testar den övre modulen A och en annan arm testar de nedre modulerna B1C1, B1C2 & B2C1, B2C2.

Eftersom båda tillvägagångssätten startar samtidigt är den här tekniken lite komplex och kräver fler människor tillsammans med specifika färdighetsuppsättningar och därmed ökar kostnaden.

GUI-applikationsintegrationstest

Låt oss nu prata om hur vi kan innebära integrationstester i Black Box-teknik.

Vi förstår alla att en webbapplikation är en multitier-applikation. Vi har en frontend som är synlig för användaren, vi har ett mellanskikt som har affärslogik, vi har lite mer mellanskikt som gör några valideringar, integrerar några tredjeparts-API: er etc., sedan har vi bakre skiktet som är databas.

Exempel på integrationstest:

Låt oss kontrollera exemplet nedan:

Jag är ägare till ett reklamföretag och jag publicerar annonser på olika webbplatser. I slutet av månaden vill jag se hur många som såg mina annonser och hur många som klickade på mina annonser. Jag behöver en rapport för att mina annonser ska visas och jag debiterar därefter mina kunder.

GenNext-programvara utvecklade den här produkten för mig och nedan var arkitekturen:

Integration 2

LÖK - Användargränssnittsmodul, som är synlig för slutanvändaren, där alla ingångar ges.
BL - Är Business Logic-modulen, som har alla beräkningar och affärsspecifika metoder.
VAL - Är valideringsmodulen som har alla valideringar av ingångens riktighet.
CNT - Är innehållsmodulen som har allt det statiska innehållet, specifikt för de ingångar som användaren anger. Detta innehåll visas i rapporterna.
I - Är motormodulen, den här modulen läser all data som kommer från BL, VAL och CNT-modulen och extraherar SQL-frågan och utlöser den till databasen.
Schemaläggare - Är en modul som schemalägger alla rapporter baserat på användarvalet (månadsvis, kvartalsvis, halvårsvis och årligen)
DB - Är databasen.

Nu, efter att ha sett arkitekturen för hela webbapplikationen, som en enda enhet, kommer Integrationstest, i detta fall, att fokusera på dataflöde mellan modulerna.

Frågorna här är:

  1. Hur kommer BL, VAL och CNT-modulen att läsa och tolka de data som matats in i UI-modulen?
  2. Tar BL-, VAL- och CNT-modulen rätt data från UI?
  3. I vilket format överförs data från BL, VAL och CNT till EQ-modulen?
  4. Hur läser EQ data och extraherar frågan?
  5. Extraheras frågan korrekt?
  6. Får schemaläggaren rätt data för rapporter?
  7. Är resultatuppsättningen mottagen av EN, från databasen korrekt och som förväntat?
  8. Kan EN skicka svaret tillbaka till BL, VAL och CNT-modulen?
  9. Kan UI-modulen läsa data och visa dem på rätt sätt i gränssnittet?

I den verkliga världen sker kommunikationen av data i ett XML-format. Så oavsett vilken data användaren matar in i användargränssnittet blir det konverterat till ett XML-format.

I vårt scenario konverteras data som anges i UI-modulen till XML-fil som tolkas av de 3 modulerna BL, VAL och CNT. EN-modulen läser den resulterande XML-filen som genereras av de tre modulerna och extraherar SQL från den och frågar in i databasen. EN-modulen tar också emot resultatuppsättningen och konverterar den till en XML-fil och returnerar den tillbaka till UI-modulen som omvandlar resultaten i användarläsbar form och visar den.

I mitten har vi schemaläggningsmodulen som tar emot resultatuppsättningen från EN-modulen, skapar och schemalägger rapporterna.

Så där integreringstestning kommer in i bilden?

Tja, att testa om informationen / data flyter korrekt eller inte kommer att bli din integrationstestning, vilket i detta fall skulle validera XML-filerna. Är XML-filerna genererade korrekt? Har de rätt data? Överförs data korrekt från en modul till en annan? Alla dessa saker kommer att testas som en del av Integrationstestning.

Försök att skapa eller hämta XML-filer och uppdatera taggarna och kontrollera beteendet. Detta är något helt annat än den vanliga testningen som testare normalt gör, men detta kommer att ge mervärde till testarnas kunskap och förståelse för applikationen.

Få andra provtestförhållanden kan vara följande:

  • Genererar menyalternativen rätt fönster?
  • Kan windows starta fönstret som testas?
  • För varje fönster, identifiera funktionssamtal för fönstret som applikationen ska tillåta.
  • Identifiera alla samtal från fönstret till andra funktioner som applikationen ska tillåta
  • Identifiera reversibla samtal: att stänga ett anropat fönster ska återgå till samtalsfönstret.
  • Identifiera irreversibla samtal: samtalsfönster stängs innan fönstret visas.
  • Testa olika sätt att genomföra samtal till ett annat fönster, t.ex. - menyer, knappar, nyckelord.

Steg för att starta integrationstester

  1. Förstå arkitekturen i din applikation.
  2. Identifiera modulerna
  3. Förstå vad varje modul gör
  4. Förstå hur data överförs från en modul till en annan.
  5. Förstå hur data matas in och tas emot i systemet (startpunkt och utgångspunkt för applikationen)
  6. Segregera applikationen för att passa dina testbehov.
  7. Identifiera och skapa testvillkor
  8. Ta ett tillstånd i taget och skriv ner testfallet.

Inträdes- / utgångskriterier för integrationstestning

Inträdeskriterier:

  • Integrationstestdokumentet är undertecknat och godkänt.
  • Integrationstestfall har förberetts.
  • Testdata har skapats.
  • Enhetstestning av utvecklade moduler / komponenter är kompletta.
  • Alla kritiska och höga prioritetsfel är stängda.
  • Testmiljön är inställd för integration.

Utgångskriterier:

  • Alla fall av integrationstest har utförts.
  • Inga kritiska P1- och P2-defekter öppnas.
  • Testrapport har upprättats.

Integrationstestfall

Integrationstestfall fokuserar främst på gränssnitt mellan modulerna, integrerade länkar, dataöverföring mellan modulerna som moduler / komponenter som redan är enhetstestade, dvs. funktionaliteten och andra testaspekter har redan behandlats.

Så huvudidén är att testa om integrering av två arbetsmoduler fungerar som förväntat när den är integrerad.

Till exempel Integration Test fall för Linkedin ansökan kommer att innehålla:

  • Verifiera gränssnittslänken mellan inloggningssidan och hemsidan, dvs. när en användare anger inloggningsuppgifterna och loggarna ska den dirigeras till hemsidan.
  • Verifiera gränssnittslänken mellan hemsidan och profilsidan, dvs. att profilsidan ska öppnas.
  • Verifiera gränssnittslänken mellan nätverkssidan och dina anslutningssidor, dvs genom att klicka på acceptera-knappen på Inbjudningar på nätverkssidan ska den godkända inbjudan visas på din anslutningssida när du klickat.
  • Verifiera gränssnittslänken mellan meddelandesidorna och säg Grattis-knappen, dvs. klicka på säg Grattis-knappen ska riktas mot det nya meddelandefönstret.

Många fall med integrationstest kan skrivas för denna specifika webbplats. Ovanstående fyra punkter är bara ett exempel för att förstå vilka Integration-testfall som ingår i testningen.

Är integration en vit låda eller svart låda teknik?

Integrationstestteknik kan räknas i såväl svarta rutor som vit låda teknik . Black box-teknik är där en testare inte behöver ha någon intern kunskap om systemet, dvs. kodningskunskap krävs inte medan vitlåda-teknik behöver intern kunskap om applikationen.

Nu när du utför integreringstest kan det inkludera testning av de två integrerade webbtjänsterna som hämtar data från databasen och tillhandahåller informationen efter behov vilket innebär att den kan testas med testningsteknik för vitlåda medan integrering av en ny funktion på webbplatsen kan testas med hjälp av black box-tekniken.

Så det är inte specifikt att integrationstestning är en svart ruta eller en vit ruta-teknik.

Integrationstestverktyg

Det finns flera verktyg tillgängliga för denna testning.

Nedan följer en lista över verktyg:

  • Rational Integration Tester
  • Gradskiva
  • Ånga
  • TESSY

För mer information om ovanstående verktyg, se den här handledningen:

Topp 10 Integrationstestverktyg för att skriva integrationstester

Systemintegrationstestning

System Integration Test görs för att testa komplett integrerat system .

Moduler eller komponenter testas individuellt i enhetstester innan komponenterna integreras.

När alla moduler har testats görs systemintegrationstest genom att integrera alla moduler och systemet som helhet testas.

Skillnad mellan integrationstest och systemtestning

Integrationstestning är en testning där en eller två moduler som enhetstestas integreras för att testa och verifiering görs för att verifiera om de integrerade modulerna fungerar som förväntat eller inte.

Systemtestning är en testning där systemet som helhet testas, dvs. alla moduler / komponenter är integrerade tillsammans för att verifiera om systemet fungerar som förväntat och inga problem uppstår på grund av de integrerade modulerna.

Slutsats

Det här handlar om integreringstestning och dess implementering i både White Box och Black Box-teknik. Hoppas vi förklarade det tydligt med relevanta exempel.

Testintegration är en viktig del av testcykeln eftersom det gör det lättare att hitta defekten när två eller flera moduler är integrerade för att integrera alla modulerna tillsammans i det första steget.

Det hjälper till att hitta fel i ett tidigt skede vilket i sin tur sparar ansträngning och kostnad också. Det säkerställer att de integrerade modulerna fungerar som förväntat.

Hoppas den här informativa handledningen om Integration Testing skulle ha berikat din kunskap om konceptet.

Rekommenderad läsning

^