Vad är integrationstestning? (Exempel)

Vad är integrationstestning?

Integrationstestning definieras som en typ av testning där mjukvarumoduler integreras logiskt och testas som en grupp. Ett typiskt programvaruprojekt består av flera programvarumoduler, kodade av olika programmerare. Syftet med denna testnivå är att avslöja defekter i interaktionen mellan dessa programvarumoduler när de är integrerade

Integrationstestning fokuserar på att kontrollera datakommunikationen mellan dessa moduler. Därför kallas det också för 'DEN' (Integration och testning), "Strängtestning" och ibland 'Trådtestning'.

Varför görs integrationstestning?

Även om varje mjukvarumodul är enhetstestad, finns det fortfarande defekter av olika anledningar som

• En modul är i allmänhet designad av en enskild mjukvaruutvecklare vars förståelse och programmeringslogik kan skilja sig från andra programmerare. Integrationstestning blir nödvändig för att verifiera att mjukvarumodulerna fungerar i enhet
• Vid tidpunkten för modulutveckling finns det stora möjligheter att ändra krav från kunderna. Dessa nya krav kanske inte är enhetstestade och därför blir systemintegrationstestning nödvändig.
• Mjukvarumodulernas gränssnitt med databasen kan vara felaktiga
• Externa hårdvarugränssnitt, om några, kan vara felaktiga
• Otillräcklig undantagshantering kan orsaka problem.

Klicka här. om videon inte är tillgänglig

Exempel på integrationstestfall

Integration Testfall skiljer sig från andra testfall i den meningen att det fokuserar främst på gränssnitten & flödet av data/information mellan modulerna. Här ska prioritet ges för integrera länkar snarare än de enhetsfunktioner som redan är testade.

Exempel på integrationstestfall för följande scenario: Applikationen har 3 moduler som säger 'Inloggningssida', 'Mailbox" och "Ta bort e-postmeddelanden" och var och en av dem är logiskt integrerade.

Koncentrera dig inte mycket på inloggningssidans testning här eftersom det redan har gjorts i Enhetstestning. Men kolla hur det är kopplat till Mail Box Sida.

Liknande Mail Box: Kontrollera dess integration med Ta bort Mails Modul.

Testfalls-ID	Testfallsmål	Testfall Description	Förväntat resultat
1	Kontrollera gränssnittslänken mellan inloggningen och Mailboxmodul	Ange inloggningsuppgifter och klicka på knappen Logga in	Att hänvisas till Mail Box
2	Kontrollera gränssnittslänken mellan Mailbox och ta bort Mails Modul	Från MailVälj e-postmeddelandet och klicka på en radera-knapp	Vald e-post ska visas i mappen Deleted/Trash

Typer av integrationstestning

Software Engineering definierar olika strategier för att utföra integrationstestning, dvs.

• Big Bang Approach:
• Inkrementell tillvägagångssätt: som är ytterligare uppdelad i följande
  • Uppifrån och ner tillvägagångssätt
  • Bottom Up Approach
  • Sandwich Approach – Kombination av Top Down och Bottom Up

Nedan är de olika strategierna, hur de utförs och deras begränsningar samt fördelar.

Big Bang-testning

Big Bang-testning är en integrationstestmetod där alla komponenter eller moduler integreras på en gång och sedan testas som en enhet. Denna kombinerade uppsättning komponenter betraktas som en enhet under testning. Om alla komponenter i enheten inte är slutförda kommer inte integrationsprocessen att köras.

fördelar:

• Bekvämt för små system.

Nackdelar:

• Fellokalisering är svårt.
• Med tanke på det stora antalet gränssnitt som måste testas i detta tillvägagångssätt, kan vissa gränssnittslänkar som ska testas lätt missas.
• Eftersom integreringstestningen kan påbörjas först efter att "alla" modulerna är designade, kommer testteamet att ha mindre tid för utförande i testfasen.
• Eftersom alla moduler testas på en gång, isoleras inte högriskkritiska moduler och testas med prioritet. Perifera moduler som hanterar användargränssnitt är inte heller isolerade och prioriterade testade.

Inkrementell testning

I Inkrementell testning metod, testning görs genom att integrera två eller flera moduler som är logiskt relaterade till varandra och sedan testas för att applikationen fungerar korrekt. Sedan integreras de andra relaterade modulerna stegvis och processen fortsätter tills alla logiskt relaterade moduler har integrerats och testats framgångsrikt.

Inkrementell tillvägagångssätt utförs i sin tur med två olika metoder:

• Botten upp
• Top Down

Stubbar och drivrutiner

Stubbar och drivrutiner är dummy-programmen i integrationstestning som används för att underlätta mjukvarutestning aktivitet. Dessa program fungerar som ett substitut för de saknade modellerna i testningen. De implementerar inte hela programmeringslogiken för mjukvarumodulen men de simulerar datakommunikation med den anropande modulen under testning.

Stump: Anropas av modulen under Test.

Chaufför: Anropar modulen som ska testas.

Bottom-up-integrationstestning

Bottom-up-integrationstestning är en strategi där modulerna på lägre nivå testas först. Dessa testade moduler används sedan ytterligare för att underlätta testning av moduler på högre nivå. Processen fortsätter tills alla moduler på toppnivå är testade. När modulerna på lägre nivå har testats och integrerats, bildas nästa nivå av moduler.

Diagrammatisk representation:

fördelar:

• Fellokalisering är lättare.
• Ingen tid slösas bort på att vänta på att alla moduler ska utvecklas till skillnad från Big-bang-metoden

Nackdelar:

• Kritiska moduler (på den översta nivån av mjukvaruarkitektur) som styr applikationsflödet testas sist och kan vara utsatta för defekter.
• En tidig prototyp är inte möjlig

Integrationstest uppifrån och ner

Top Down-integreringstestning är en metod där integrationstestning sker från topp till botten efter mjukvarusystemets kontrollflöde. Modulerna på högre nivå testas först och sedan testas och integreras moduler på lägre nivå för att kontrollera mjukvarans funktionalitet. Stubbar används för att testa om vissa moduler inte är klara.

Diagrammatisk representation:

fördelar:

• Fellokalisering är enklare.
• Möjlighet att få en tidig prototyp.
• Kritiska moduler testas på prioritet; stora designbrister kunde hittas och åtgärdas först.

Nackdelar:

• Behöver många stubbar.
• Moduler på lägre nivå är otillräckligt testade.

Hur gör man integrationstestning?

Integrationstestproceduren oberoende av programvaruteststrategierna (diskuterade ovan):

1. Förbered integrationen Testplan
2. Designa testscenarierna, fallen och skripten.
3. Utförande av testfall följt av rapportering av defekterna.
4. Spåra och testa defekterna igen.
5. Steg 3 och 4 upprepas tills integrationen är klar.

Kort Descriptintegrationstestplaner

Den innehåller följande attribut:

• Metoder/metoder för testning (som diskuterats ovan).
• Omfattningar och utanför omfattningen Integrationstestning.
• Roller och ansvar.
• Förutsättningar för Integrationstestning.
• Testmiljö.
• Risk- och begränsningsplaner.

In- och utträdeskriterier för integrationstestning

Ingångs- och utgångskriterier till integrationstestfasen i valfri mjukvaruutvecklingsmodell

Ingångskriterier:

• Enhetstestade komponenter/moduler
• Alla högprioriterade buggar fixade och stängda
• Alla moduler ska kodklareras och integreras framgångsrikt.
• Integrationstester Plan, testfall, scenarier som ska signeras och dokumenteras.
• Krävs Testmiljö ska ställas in för integrationstestning

Utgångskriterier:

• Framgångsrik testning av integrerad applikation.
• Utförda testfall dokumenteras
• Alla högprioriterade buggar fixade och stängda
• Tekniska dokument som ska skickas in följt av release Notes.

Bästa praxis/riktlinjer för integrationstestning

• Bestäm först integrationen Teststrategi som skulle kunna antas och senare förbereda testfallen och testdata därefter.
• Studera Archiutforma applikationen och identifiera de kritiska modulerna. Dessa måste prioriteras.
• Skaffa gränssnittsdesignerna från Architekturteam och skapa testfall för att verifiera alla gränssnitt i detalj. Gränssnitt till databas/extern hårdvara/mjukvara måste testas i detalj.
• Efter testfallen är det testdata som spelar den avgörande rollen.
• Ha alltid skendata förberedda innan exekvering. Välj inte testdata medan testfallen körs.