Hva er integrasjonstesting?
INTEGRASJONSTESTING er definert som en type testing der programvaremoduler er integrert logisk og testet som en gruppe. Et typisk programvareprosjekt består av flere programvaremoduler, kodet av forskjellige programmerere. Hensikten med dette testnivået er å avsløre mangler i samspillet mellom disse programvaremodulene når de er integrert
Integration Testing fokuserer på å kontrollere datakommunikasjon mellom disse modulene. Derfor blir det også betegnet som 'I & T' (Integration and Testing), 'String Testing' og noen ganger 'Thread Testing' .
- Hva er integrasjonstesting?
- Hvorfor gjør integrasjonstesting?
- Eksempel på integrasjonstest
- Tilnærminger, strategier, metoder for integrasjonstesting
- Big Bang-tilnærming:
- Inkrementell tilnærming
- Hva er Stub and Driver?
- Integrasjon nedenfra og opp
- Top-down Integrasjon:
- Hybrid / Sandwich-integrasjon
- Hvordan gjøre integrasjonstesting?
- Kort beskrivelse av integrasjonstestplaner:
- Inngangs- og utgangskriterier for integrasjonstesting
- Beste praksis / retningslinjer for integrasjonstesting
Hvorfor gjør integrasjonstesting?
Selv om hver programvaremodul er enhetstestet, eksisterer det fortsatt mangler av forskjellige årsaker som
- En modul er generelt designet av en individuell programvareutvikler hvis forståelse og programmeringslogikk kan avvike fra andre programmerere. Integrasjonstesting blir nødvendig for å bekrefte at programvaremodulene fungerer i enhet
- På tidspunktet for modulutvikling er det store sjanser for endring i krav fra kundene. Disse nye kravene blir kanskje ikke enhetstestet, og derfor blir systemintegrasjonstesting nødvendig.
- Grensesnitt mellom programvaremodulene og databasen kan være feil
- Eksterne maskinvaregrensesnitt, hvis noen, kan være feil
- Mangelfull unntakshåndtering kan forårsake problemer.
Klikk her hvis videoen ikke er tilgjengelig
Eksempel på integrasjonstest
Integration Test Case skiller seg fra andre testsaker i den forstand at den hovedsakelig fokuserer på grensesnitt og strøm av data / informasjon mellom modulene . Her skal prioritet gis for integreringslenker i stedet for enhetsfunksjonene som allerede er testet.
Eksempel på integrasjonstest tilfeller for følgende scenario: Applikasjonen har 3 moduler som sier 'Login Page', 'Mailbox' og 'Delete e-post', og hver av dem er integrert logisk.
Her må du ikke konsentrere deg mye om påloggingssiden som det allerede er gjort i enhetstesting. Men sjekk hvordan det er knyttet til postbokssiden.
Tilsvarende Mail Box: Sjekk integrasjonen til Delete Mails Module.
| Test saks-ID | Test Case Objective | Test Case Beskrivelse | forventet resultat |
|---|---|---|---|
| 1 | Sjekk grensesnittkoblingen mellom påloggings- og postkassemodulen | Skriv inn påloggingsinformasjonen og klikk på Logg inn-knappen | For å bli sendt til postboksen |
| 2 | Sjekk grensesnittkoblingen mellom postboksen og Delete Mails Module | Velg e-posten fra postkassen og klikk på en sletteknapp | Valgt e-postadresse skal vises i mappen Slettet / papirkurven |
Tilnærminger, strategier, metoder for integrasjonstesting
Software Engineering definerer en rekke strategier for å utføre integrasjonstesting, nemlig.
- Big Bang-tilnærming:
- Inkrementell tilnærming: som videre er delt inn i følgende
- Top Up Down Approach
- Bottom Up Approach
- Sandwich-tilnærming - kombinasjon av ovenfra og ned
Nedenfor er de forskjellige strategiene, måten de blir utført på, og deres begrensninger og fordeler.
Big Bang Testing
Big Bang Testing er en integrasjonstesttilnærming der alle komponentene eller modulene er integrert sammen samtidig og deretter testet som en enhet. Dette kombinerte settet med komponenter betraktes som en enhet under testing. Hvis alle komponentene i enheten ikke er fullført, vil ikke integreringsprosessen utføres.
Fordeler:
- Praktisk for små systemer.
Ulemper:
- Feillokalisering er vanskelig.
- Gitt det store antallet grensesnitt som må testes i denne tilnærmingen, kan noen grensesnittkoblinger som skal testes lett gå glipp av.
- Siden integrasjonstestingen kan starte bare etter at "alle" modulene er utformet, vil testteamet ha mindre tid til utføring i testfasen.
- Siden alle modulene testes samtidig, blir ikke høyrisikokritiske moduler ikke isolert og testet på prioritet. Perifere moduler som håndterer brukergrensesnitt, blir heller ikke isolert og testet på prioritet.
Inkrementell testing
I tilnærmingen med inkrementell testing utføres testing ved å integrere to eller flere moduler som er logisk relatert til hverandre og deretter testet for at applikasjonen fungerer korrekt. Deretter integreres de andre relaterte modulene trinnvis, og prosessen fortsetter til alle de logisk relaterte modulene er integrert og testet.
Inkrementell tilnærming utføres i sin tur med to forskjellige metoder:
- Opp ned
- Top Down
Stubber og drivere
Stubber og drivere er dummy-programmene i integrasjonstesting som brukes for å lette programvaretestaktiviteten. Disse programmene fungerer som en erstatning for de manglende modellene i testingen. De implementerer ikke hele programmeringslogikken til programvaremodulen, men de simulerer datakommunikasjon med anropsmodulen under testing.
Stub : Kalles av modulen under test.
Driver : Kaller modulen som skal testes.
Integrasjonstesting nedenfra og opp
Bottom-up Integration Testing er en strategi der modulene på lavere nivå testes først. Disse testede modulene blir deretter videre brukt for å lette testing av moduler på høyere nivå. Prosessen fortsetter til alle modulene på toppnivå er testet. Når modulene på lavere nivå er testet og integrert, dannes neste nivå av moduler.
Diagrammatisk fremstilling :
Fordeler:
- Feillokalisering er lettere.
- Det går ikke bort med tid på å vente på at alle moduler skal utvikles i motsetning til Big-bang-tilnærmingen
Ulemper:
- Kritiske moduler (på det øverste nivået av programvarearkitektur) som styrer applikasjonsflyten blir testet sist og kan være utsatt for mangler.
- En tidlig prototype er ikke mulig
Top-down Integration Testing
Top Down Integration Testing er en metode der integrasjonstesting foregår fra topp til bunn etter kontrollflyten til programvaresystemet. Modulene på høyere nivå testes først og deretter moduler på lavere nivå testes og integreres for å sjekke programvarefunksjonaliteten. Stubber brukes til testing hvis noen moduler ikke er klare.
Diagrammatisk fremstilling:
Fordeler:
- Feillokalisering er lettere.
- Mulighet for å få en tidlig prototype.
- Kritiske moduler testes på prioritet; store designfeil kunne bli funnet og løst først.
Ulemper:
- Trenger mange stubber.
- Moduler på et lavere nivå testes utilstrekkelig.
Sandwich Testing
Sandwich Testing er en strategi der moduler på toppnivå testes med moduler på lavere nivå samtidig som lavere moduler integreres med toppmoduler og testes som et system. Det er en kombinasjon av Top-down og Bottom-up tilnærminger, derfor kalles det Hybrid Integration Testing . Den bruker både stubber og drivere.
Hvordan gjøre integrasjonstesting?
Integrasjonstestprosedyren uavhengig av teststrategier for programvare (diskutert ovenfor):
- Forbered integrasjonstestplanen
- Design testscenarier, tilfeller og skript.
- Gjennomføring av testtilfellene etterfulgt av rapportering av manglene.
- Spore og re-teste feilene.
- Trinn 3 og 4 gjentas til fullføringen av integrasjonen er vellykket.
Kort beskrivelse av integrasjonstestplaner:
Den inkluderer følgende attributter:
- Metoder / tilnærminger til testing (som diskutert ovenfor).
- Scopes and Out of Scopes Items of Integration Testing.
- Roller og ansvar.
- Forutsetninger for integrasjonstesting.
- Testmiljø.
- Risiko- og avbøtningsplaner.
Inngangs- og utgangskriterier for integrasjonstesting
Inngangs- og utgangskriterier for testfasen for integrasjon i en hvilken som helst programvareutviklingsmodell
Oppføringskriterier:
- Enhetstestede komponenter / moduler
- Alle høyprioriterte feil løst og lukket
- Alle moduler skal fullføres og integreres med suksess.
- Integrasjonstester Planlegg, test case, scenarier som skal signeres og dokumenteres.
- Nødvendig testmiljø skal konfigureres for integrasjonstesting
Utgangskriterier:
- Vellykket testing av integrert applikasjon.
- Utførte testsaker er dokumentert
- Alle høyprioriterte feil løst og lukket
- Tekniske dokumenter som skal leveres etterfulgt av utgivelsesnotater.
Beste praksis / retningslinjer for integrasjonstesting
- Først må du bestemme integrasjonsteststrategien som kan bli vedtatt, og senere forberede testsakene og testdata deretter.
- Studer arkitekturdesignet til applikasjonen og identifiser de kritiske modulene. Disse må testes på prioritet.
- Få grensesnittdesignene fra Architectural-teamet og opprett testtilfeller for å verifisere alle grensesnittene i detalj. Grensesnitt til database / ekstern maskinvare / programvare må testes i detalj.
- Etter testsakene er det testdataene som spiller den kritiske rollen.
- Ha alltid spottdata utarbeidet før utførelse. Ikke velg testdata mens du utfører testsakene.