Hvad er integrationstest? (Eksempel)

Hvad er integrationstest?

Integrationstest er defineret som en type test, hvor softwaremoduler integreres logisk og testes 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 defekter i interaktionen mellem disse softwaremoduler, når de er integreret

Integrationstest fokuserer på at kontrollere datakommunikation mellem disse moduler. Derfor betegnes det også som 'DET' (Integration og test), 'Strengetest' og nogle gange 'Trådtest'.

Hvorfor udfører integrationstest?

Selvom hvert softwaremodul er enhedstestet, eksisterer der stadig defekter af forskellige årsager, f.eks

• Et modul er generelt designet af en individuel softwareudvikler, hvis forståelse og programmeringslogik kan afvige fra andre programmører. Integrationstest bliver nødvendigt for at verificere, at softwaremodulerne fungerer i enhed
• På tidspunktet for moduludvikling er der store chancer for ændringer i kundernes krav. Disse nye krav er muligvis ikke enhedstestet, og derfor bliver systemintegrationstest nødvendig.
• Grænseflader mellem softwaremodulerne og databasen kan være fejlagtige
• Eksterne hardwaregrænseflader, hvis nogen, kan være fejlagtige
• Utilstrækkelig håndtering af undtagelser kan forårsage problemer.

Klik link. hvis videoen ikke er tilgængelig

Eksempel på integrationstestcase

Integration Test sag adskiller sig fra andre testcases i den forstand, at det fokuserer hovedsageligt på interfaces & flow af data/information mellem modulerne. Her skal der prioriteres integrere links i stedet for de enhedsfunktioner, som allerede er testet.

Eksempler på integrationstesttilfælde for følgende scenarie: Applikationen har 3 moduler, der siger 'Loginside', 'Mailbox' og 'Slet e-mails', og hver af dem er integreret logisk.

Her skal du ikke koncentrere dig meget om test af loginsiden, da det allerede er blevet udført i Enhedstest. Men tjek hvordan det er knyttet til Mail Box Side.

Tilsvarende Mail Box: Tjek dens integration til Slet Mails modul.

Test Case ID	Test Case Målsætning	Test sag Description	forventet resultat
1	Tjek grænsefladeforbindelsen mellem login og Mailboks modul	Indtast loginoplysninger og klik på knappen Log ind	Skal henvises til Mail Box
2	Tjek grænsefladeforbindelsen mellem Mailboks og Slet Mails modul	Fra Mailvælg e-mailen og klik på en sletknap	Den valgte e-mail skal vises i mappen Slettet/Papirkurv

Typer af integrationstest

Software Engineering definerer forskellige strategier til at udføre integrationstest, dvs.

• Big Bang tilgang:
• Inkrementel tilgang: som er yderligere opdelt i følgende
  • Top Down tilgang
  • Bottom Up tilgang
  • Sandwich Approach – Kombination af Top Down og Bottom Up

Nedenfor er de forskellige strategier, måden de udføres på og deres begrænsninger samt fordele.

Big Bang test

Big Bang test er en integrationstestmetode, hvor alle komponenter eller moduler integreres på én gang og derefter testes som en enhed. Dette kombinerede sæt af komponenter betragtes som en enhed under testning. Hvis alle komponenterne i enheden ikke er fuldført, vil integrationsprocessen ikke udføres.

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ænsefladelink, der skal testes, let gå glip af.
• Da integrationstesten først kan påbegyndes efter "alle" moduler er designet, vil testteamet have mindre tid til udførelse i testfasen.
• Da alle moduler testes på én gang, isoleres højrisiko-kritiske moduler ikke og testes på prioritet. Perifere moduler, der beskæftiger sig med brugergrænseflader, er heller ikke isoleret og testet på prioritet.

Inkrementel test

I Inkrementel test fremgangsmåde, test udføres ved at integrere to eller flere moduler, der er logisk relateret til hinanden og derefter testet for korrekt funktion af applikationen. 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

Stubber og drivere

Stubber og drivere er dummy-programmerne i integrationstest, der bruges til at lette software test aktivitet. Disse programmer fungerer som en erstatning for de manglende modeller i testen. De implementerer ikke hele programmeringslogikken i softwaremodulet, men de simulerer datakommunikation med det kaldende modul under test.

Stub: Kaldes af modulet under Test.

Chauffør: Kalder det modul, der skal testes.

Bottom-up-integrationstest

Bottom-up-integrationstest er en strategi, hvor modulerne på lavere niveau testes først. Disse testede moduler bruges derefter yderligere til at lette afprøvningen af ​​højere niveau moduler. Processen fortsætter, indtil alle moduler på topniveau er testet. Når modulerne på lavere niveau er testet og integreret, dannes det næste niveau af moduler.

Diagrammatisk fremstilling:

fordele:

• Fejllokalisering er nemmere.
• Ingen tid spildes 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), som styrer applikationsflowet, testes sidst og kan være tilbøjelige til defekter.
• En tidlig prototype er ikke mulig

Top-down integrationstest

Top Down Integrationstest er en metode, hvor integrationstest finder sted fra top til bund efter softwaresystemets kontrolflow. Modulerne på højere niveau testes først, og derefter testes og integreres moduler på lavere niveau for at kontrollere softwarens funktionalitet. Stubber bruges til at teste, hvis nogle moduler ikke er klar.

Diagrammatisk fremstilling:

fordele:

• Fejllokalisering er nemmere.
• Mulighed for at få en tidlig prototype.
• Kritiske moduler testes på prioritet; store designfejl kunne findes og rettes først.

Ulemper:

• Har brug for mange stubber.
• Moduler på et lavere niveau testes utilstrækkeligt.

Hvordan laver man integrationstest?

Integrationstestproceduren uanset softwareteststrategierne (diskuteret ovenfor):

1. Forbered integrationen Testplan
2. Design testscenarier, cases og scripts.
3. Udførelse af testen Cases efterfulgt af rapportering af defekterne.
4. Sporing og gentest af defekterne.
5. Trin 3 og 4 gentages, indtil fuldførelsen af ​​integrationen er vellykket.

Brief Description af integrationstestplaner

Den indeholder følgende attributter:

• Metoder/tilgange til test (som diskuteret ovenfor).
• Omfang og uden for anvendelsesområde Elementer af integrationstest.
• Roller og ansvar.
• Forudsætninger for integrationstest.
• Test miljø.
• Risiko- og afhjælpningsplaner.

Indgangs- og udgangskriterier for integrationstest

Indgangs- og udgangskriterier til integrationstestfase i enhver softwareudviklingsmodel

Adgangskriterier:

• Enhedstestede komponenter/moduler
• Alle højt prioriterede fejl rettet og lukket
• Alle moduler skal kodeudfyldes og integreres med succes.
• Integrationstests Plan, testcase, scenarier, der skal underskrives og dokumenteres.
• påkrævet Testmiljø skal sættes op til integrationstest

Afgangskriterier:

• Vellykket test af integreret applikation.
• Udførte testsager dokumenteres
• Alle højt prioriterede fejl rettet og lukket
• Tekniske dokumenter skal indsendes efterfulgt af release Notes.

Bedste Practices/ Guidelines for Integration Testing

• Bestem først integrationen Test strategi der kunne vedtages og senere forberede testcases og testdata i overensstemmelse hermed.
• Undersøg Archiudforme applikationen og identificere de kritiske moduler. Disse skal afprøves på prioritet.
• Få interface design fra Architekturteam og opret testcases for at verificere alle grænseflader i detaljer. Interface til database/ekstern hardware/softwareapplikation skal testes i detaljer.
• Efter testcaserne er det testdataene, der spiller den afgørende rolle.
• Hav altid de falske data forberedt, før de udføres. Vælg ikke testdata, mens du udfører testcases.