Hvad er integrationstest?
INTEGRATIONSTEST er defineret som en type test, hvor softwaremoduler er integreret logisk og testet som en gruppe. Et typisk softwareprojekt består af flere softwaremoduler kodet af forskellige programmører. Formålet med dette testniveau er at afsløre mangler i interaktionen mellem disse softwaremoduler, når de er integreret
Integration Testing fokuserer på kontrol af datakommunikation mellem disse moduler. Derfor betegnes det også som 'I & T' (Integration and Testing), 'String Testing' og undertiden 'Thread Testing' .
- Hvad er integrationstest?
- Hvorfor test af integration?
- Eksempel på integrationstestsag
- Tilgange, strategier, metoder til integrationstest
- Big Bang-tilgang:
- Inkrementel tilgang
- Hvad er stub og driver?
- Bottom-up-integration
- Top-down integration:
- Hybrid / Sandwich-integration
- Hvordan udføres integrationstest?
- Kort beskrivelse af integrationstestplaner:
- Indgangs- og udgangskriterier for integrationstest
- Bedste praksis / retningslinjer for integrationstest
Hvorfor test af integration?
Selvom hvert softwaremodul er enhedstestet, findes der stadig mangler af forskellige årsager som f.eks
- Et modul er generelt designet af en individuel softwareudvikler, hvis forståelse og programmeringslogik kan afvige fra andre programmører. Integrationstestning bliver nødvendigt for at kontrollere, at softwaremodulerne fungerer i enhed
- På tidspunktet for moduludvikling er der store chancer for ændringer i kravene fra kunderne. Disse nye krav bliver muligvis ikke enhedstestet, og derfor bliver systemintegrationstest nødvendig.
- Grænseflader mellem softwaremodulerne og databasen kan være fejlagtige
- Eksterne hardwaregrænseflader, hvis der er nogen, kan være fejlagtige
- Utilstrækkelig håndtering af undtagelser kan forårsage problemer.
Klik her, hvis videoen ikke er tilgængelig
Eksempel på integrationstestsag
Integration Test Case adskiller sig fra andre testcases i den forstand, at det primært fokuserer på grænseflader og strøm af data / information mellem modulerne . Her skal der prioriteres de integrerende links i stedet for de enhedsfunktioner, der allerede er testet.
Eksempel på integrationstesttilfælde til følgende scenarie: Applikationen har 3 moduler, der siger 'Login Page', 'Mailbox' og 'Delete emails', og hver af dem er integreret logisk.
Her skal du ikke koncentrere dig meget om login-sidetesten, da det allerede er gjort i enhedstest. Men kontroller hvordan det er knyttet til postkassesiden.
Tilsvarende Postkasse: Kontroller dens integration til Slet mails-modulet.
| Test sags-ID | Test case mål | Test case beskrivelse | forventet resultat |
|---|---|---|---|
| 1 | Kontroller interfacelinket mellem login- og postkassemodulet | Indtast loginoplysninger, og klik på knappen Login | For at blive dirigeret til postkassen |
| 2 | Tjek interfacelinket mellem postkassen og Slet mails-modulet | Vælg e-mailen fra postkassen, og klik på en sletningsknap | Den valgte e-mail skal vises i mappen Slettet / Papirkurv |
Tilgange, strategier, metoder til integrationstest
Software Engineering definerer forskellige strategier til udførelse af integrationstest, nemlig
- Big Bang-tilgang:
- Inkremental tilgang: som yderligere er opdelt i følgende
- Top-down tilgang
- Bottom Up tilgang
- Sandwich tilgang - Kombination af top-down og bottom up
Nedenfor er de forskellige strategier, den måde, de udføres på, og deres begrænsninger samt fordele.
Big Bang Testing
Big Bang Testing er en integrationstestmetode, hvor alle komponenter eller moduler integreres sammen på én gang og derefter testes som en enhed. Dette kombinerede sæt komponenter betragtes som en enhed under testning. Hvis alle komponenterne i enheden ikke er afsluttet, udføres integrationsprocessen ikke.
Fordele:
- Praktisk til små systemer.
Ulemper:
- Fejllokalisering er vanskelig.
- I betragtning af det store antal grænseflader, der skal testes i denne tilgang, kan nogle grænsefladeslink, der skal testes, let gå glip af.
- Da integrationstesten kun kan begynde, efter at "alle" modulerne er designet, vil testteamet have mindre tid til udførelse i testfasen.
- Da alle moduler testes på én gang, er højrisikokritiske moduler ikke isoleret og testet efter prioritet. Perifere moduler, der beskæftiger sig med brugergrænseflader, er heller ikke isoleret og testet på prioritet.
Inkrementel test
I fremgangsmåden Incremental Testing udføres test ved at integrere to eller flere moduler, der er logisk relateret til hinanden og derefter testet for, at applikationen fungerer korrekt. Derefter integreres de andre relaterede moduler trinvist, og processen fortsætter, indtil alle de logisk relaterede moduler er integreret og testet med succes.
Inkrementel tilgang udføres til gengæld ved to forskellige metoder:
- Bunden i vejret
- Oppefra og ned
Stubs og drivere
Stubs og drivere er dummy-programmerne i integrationstest, der bruges til at lette softwaretestaktiviteten. Disse programmer fungerer som en erstatning for de manglende modeller i testen. De implementerer ikke hele softwaremodulets programmeringslogik, men de simulerer datakommunikation med det kaldende modul under test.
Stub : Opkaldes af modulet under test.
Driver : Opfordrer modulet til at blive testet.
Bottom-up Integration Testing
Bottom-up Integration Testing er en strategi, hvor modulerne på lavere niveau testes først. Disse testede moduler bruges derefter yderligere til at lette testningen af moduler på højere niveau. Processen fortsætter, indtil alle moduler på øverste niveau er testet. Når modulerne på lavere niveau er testet og integreret, dannes det næste niveau af moduler.
Diagrammatisk repræsentation :
Fordele:
- Fejllokalisering er lettere.
- Der spildes ingen tid på at vente på, at alle moduler skal udvikles i modsætning til Big-bang-tilgangen
Ulemper:
- Kritiske moduler (på det øverste niveau af softwarearkitektur), der styrer applikationsstrømmen, testes sidst og kan være tilbøjelige til mangler.
- En tidlig prototype er ikke mulig
Top-down integrationstest
Top Down Integration Testing er en metode, hvor integrationstest finder sted fra top til bund efter kontrolflowet i softwaresystemet. Modulerne på højere niveau testes først, og derefter testes og integreres lavere moduler for at kontrollere softwarefunktionaliteten. Stubs bruges til test, hvis nogle moduler ikke er klar.
Diagrammatisk repræsentation:
Fordele:
- Fejllokalisering er lettere.
- Mulighed for at opnå en tidlig prototype.
- Kritiske moduler testes på prioritet; store designfejl kunne først findes og løses.
Ulemper:
- Brug for mange stubbe.
- Moduler på et lavere niveau testes utilstrækkeligt.
Sandwich test
Sandwich Testing er en strategi, hvor topniveaumoduler testes med moduler på lavere niveau, samtidig med at lavere moduler integreres med topmoduler og testes som et system. Det er en kombination af Top-down og Bottom-up tilgange, derfor kaldes det Hybrid Integration Testing . Det gør brug af både stubbe samt drivere.
Hvordan udføres integrationstest?
Integrationstestproceduren uanset softwareteststrategierne (diskuteret ovenfor):
- Forbered Integration Tests Plan
- Design testscenarier, sager og scripts.
- Udførelse af testtilfælde efterfulgt af rapportering af manglerne.
- Sporing og gentestning af manglerne.
- Trin 3 og 4 gentages, indtil gennemførelsen af integrationen er vellykket.
Kort beskrivelse af integrationstestplaner:
Det inkluderer følgende attributter:
- Metoder / fremgangsmåder til testning (som beskrevet ovenfor).
- Scopes and Out of Scopes Elementer af integrationstest.
- Roller og ansvar.
- Forudsætninger for integrationstest.
- Testmiljø.
- Risiko- og afbødningsplaner.
Indgangs- og udgangskriterier for integrationstest
Indgangs- og udgangskriterier til integrationstestfase i enhver softwareudviklingsmodel
Indgangskriterier:
- Enhedstestede komponenter / moduler
- Alle højt prioriterede fejl rettet og lukket
- Alle moduler skal kode afsluttes og integreres med succes.
- Integrationstest Planlæg, test case, scenarier der skal underskrives og dokumenteres.
- Påkrævet testmiljø skal konfigureres til integrationstest
Udgangskriterier:
- Vellykket test af integreret applikation.
- Eksekverede testsager er dokumenteret
- Alle højt prioriterede fejl rettet og lukket
- Tekniske dokumenter, der skal indsendes, efterfulgt af frigivelsesnotater.
Bedste praksis / retningslinjer for integrationstest
- Først skal du bestemme den integrationsteststrategi, der kan blive vedtaget, og senere forberede testsagerne og testdataene i overensstemmelse hermed.
- Undersøg arkitekturens design af applikationen og identificer de kritiske moduler. Disse skal testes efter prioritet.
- Få interface-design fra Architectural-teamet, og opret testcases for at verificere alle interfaces i detaljer. Grænseflade til database / ekstern hardware / softwareapplikation skal testes i detaljer.
- Efter testsagerne er det testdata, der spiller den kritiske rolle.
- Sørg altid for at udarbejde mock-data inden udførelse. Vælg ikke testdata, mens du udfører testsagerne.