Vad är integrationstestning?
INTEGRATIONSTESTING definieras som en typ av test där mjukvarumoduler integreras logiskt och testas som en grupp. Ett typiskt programvaruprojekt består av flera mjukvarumoduler, kodade av olika programmerare. Syftet med denna testnivå är att avslöja defekter i interaktionen mellan dessa programvarumoduler när de är integrerade
Integration Testing fokuserar på att kontrollera datakommunikation mellan dessa moduler. Därför kallas det också som "I & T" (Integration and Testing), "String Testing" och ibland "Thread Testing" .
- Vad är integrationstestning?
- Varför gör Integration Testing?
- Exempel på Integration Test Fall
- Metoder, strategier, metoder för integrationstestning
- Big Bang-strategi:
- Inkrementell strategi
- Vad är Stub and Driver?
- Bottom-up-integration
- Top-down-integration:
- Hybrid / Sandwich-integration
- Hur gör man integrationstestning?
- Kort beskrivning av integrationstestplaner:
- Inträdes- och utgångskriterier för integrationstestning
- Bästa praxis / riktlinjer för integrationstestning
Varför gör Integration Testing?
Även om varje mjukvarumodul är enhetstestad, finns det fortfarande fel av olika skäl som
- En modul är generellt utformad av en enskild programutvecklare vars förståelse och programmeringslogik kan skilja sig från andra programmerare. Integrationstestning blir nödvändigt för att verifiera att mjukvarumodulerna fungerar i enhet
- Vid tidpunkten för modulutveckling finns det stora chanser att förändra kraven hos kunderna. Dessa nya krav kanske inte enhetstestas och därför blir systemintegrationstest nödvändigt.
- Gränssnitt mellan mjukvarumodulerna och 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å Integration Test Fall
Integration Test Case skiljer sig från andra testfall i den meningen att det främst fokuserar på gränssnitt och flöde av data / information mellan modulerna . Här prioriteras de integrerande länkarna snarare än de enhetsfunktioner som redan har testats.
Exempel på integreringstestfall för följande scenario: Applikationen har tre moduler som säger 'Inloggningssida', 'Brevlåda' och 'Ta bort e-postmeddelanden' och var och en av dem är integrerat logiskt.
Här koncentrerar du dig inte mycket på inloggningssidan, eftersom det redan har gjorts i enhetstestning. Men kolla hur den är kopplad till brevlådessidan.
På samma sätt Mail Box: Kontrollera dess integrering med Delete Mails Module.
| Testfall ID | Testfallets mål | Testfall Beskrivning | Förväntat resultat |
|---|---|---|---|
| 1 | Kontrollera gränssnittslänken mellan inloggnings- och postlådemodulen | Ange inloggningsuppgifter och klicka på inloggningsknappen | Riktas till brevlådan |
| 2 | Kontrollera gränssnittslänken mellan brevlådan och Radera e-postmodulen | Välj e-postmeddelandet från brevlådan och klicka på en raderingsknapp | Valt e-postmeddelande ska visas i mappen Borttaget / Papperskorgen |
Metoder, strategier, metoder för integrationstestning
Software Engineering definierar olika strategier för att utföra Integrationstest, dvs.
- Big Bang-strategi:
- Incremental Approach: som ytterligare delas in i följande
- Uppifrån och ner-tillvägagångssätt
- Bottom Up Approach
- Sandwich Approach - Kombination av uppifrån och ner och uppifrån
Nedan följer de olika strategierna, hur de genomförs och deras begränsningar samt fördelar.
Big Bang Testing
Big Bang Testing är en metod för integrationstestning där alla komponenter eller moduler integreras tillsammans samtidigt och sedan testas som en enhet. Denna kombinerade uppsättning komponenter betraktas som en enhet under testningen. Om alla komponenter i enheten inte är färdiga kommer inte integrationsprocessen att genomföras.
Fördelar:
- Bekvämt för små system.
Nackdelar:
- Fellokalisering är svårt.
- Med tanke på det stora antalet gränssnitt som behöver testas i detta tillvägagångssätt kan vissa gränssnittslänkar som ska testas lätt missas.
- Eftersom integrationstestningen kan börja först efter att "alla" modulerna har utformats kommer testteamet att ha mindre tid för körning i testfasen.
- Eftersom alla moduler testas på en gång är högrisk-kritiska moduler inte isolerade och testas på prioritet. Perifera moduler som hanterar användargränssnitt är inte heller isolerade och testade på prioritet.
Inkrementell testning
I tillvägagångssättet Incremental Testing utförs testning genom att integrera två eller flera moduler som är logiskt relaterade till varandra och sedan testas för att applikationen ska fungera korrekt. Därefter integreras de andra relaterade modulerna stegvis och processen fortsätter tills alla logiskt relaterade moduler integreras och testas framgångsrikt.
Incremental Approach utförs i sin tur med två olika metoder:
- Botten upp
- Uppifrån och ner
Stubbar och drivrutiner
Stubbar och drivrutiner är dummy-program i Integration-testning som används för att underlätta programvarutestaktiviteten. Dessa program fungerar som en ersättning för de saknade modellerna i testningen. De implementerar inte hela programmeringslogiken för mjukvarumodulen men de simulerar datakommunikation med den anropande modulen under testningen.
Stub : kallas av modulen under test.
Drivrutin : kräver att modulen ska testas.
Bottom-up Integration Testing
Bottom-up Integration Testing är en strategi där modulerna på lägre nivå testas först. Dessa testade moduler används sedan vidare för att underlätta testningen av moduler på högre nivå. Processen fortsätter tills alla moduler på toppnivå testas. 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 i väntan på att alla moduler ska utvecklas till skillnad från Big-bang-metoden
Nackdelar:
- Kritiska moduler (på den översta nivån av programvaruarkitektur) som styr applikationsflödet testas senast och kan vara utsatta för defekter.
- En tidig prototyp är inte möjlig
Top-down Integration Testing
Top Down Integration Testing är en metod där integrationstestning sker från topp till botten efter kontrollflödet av mjukvarusystemet. De högre nivåmodulerna testas först och sedan testas och integreras lägre nivåmoduler för att kontrollera programvarans funktionalitet. Stubbar används för testning om vissa moduler inte är redo.
Diagrammatisk representation:
Fördelar:
- Fellokalisering är lättare.
- Möjlighet att få en tidig prototyp.
- Kritiska moduler testas med prioritet; stora konstruktionsfel kunde hittas och åtgärdas först.
Nackdelar:
- Behöver många stubbar.
- Moduler på lägre nivå testas otillräckligt.
Sandwich Testing
Sandwich Testing är en strategi där toppnivåmoduler testas med lägre nivåmoduler samtidigt som lägre moduler integreras med toppmoduler och testas som ett system. Det är en kombination av Top-down- och Bottom-up-metoder, därför kallas det Hybrid Integration Testing . Den använder både stubbar och drivrutiner.
Hur gör man integrationstestning?
Integrationstestförfarandet oavsett programvarutestningsstrategierna (diskuteras ovan):
- Förbered Integration Tests Plan
- Designa testscenarier, fall och manus.
- Genomförande av testfall följt av rapportering av brister.
- Spåra och testa om bristerna.
- Steg 3 och 4 upprepas tills slutförandet av integrationen är framgångsrik.
Kort beskrivning av integrationstestplaner:
Den innehåller följande attribut:
- Metoder / metoder för testning (som diskuterats ovan).
- Räckvidd och utom räckvidd Objekt för integrationstestning.
- Roller och ansvar.
- Förutsättningar för integrationstestning.
- Testmiljö.
- Risk- och begränsningsplaner.
Inträdes- och utgångskriterier för integrationstestning
Inträdes- och utgångskriterier för testfasen för integration i vilken programvaruutvecklingsmodell som helst
Inträdeskriterier:
- Enhetstestade komponenter / moduler
- Alla högprioriterade buggar fixade och stängda
- Alla moduler ska kodas och integreras framgångsrikt.
- Integrationstest Planera, testfall, scenarier som ska undertecknas och dokumenteras.
- Nödvändig testmiljö ska ställas in för integrationstestning
Utgångskriterier:
- Framgångsrik testning av integrerad applikation.
- Exekverade testfall är dokumenterade
- Alla högprioriterade buggar fixade och stängda
- Tekniska dokument som ska lämnas in följt av release notes.
Bästa praxis / riktlinjer för integrationstestning
- Bestäm först den Integrationsteststrategi som kan antas och förbered sedan testfallet och testdata därefter.
- Studera applikationens arkitekturdesign och identifiera de kritiska modulerna. Dessa måste testas med prioritet.
- Skaffa gränssnittsdesignerna från Architectural-teamet och skapa testfall för att verifiera alla gränssnitt i detalj. Gränssnitt till databas / extern hårdvara / programvara måste testas i detalj.
- Efter testfallet är det testdata som spelar den kritiska rollen.
- Ha alltid hånade data förberedda innan de körs. Välj inte testdata när du utför testfallet.