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?

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 unity
  • 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 fejlneous
  • Eksterne hardwaregrænseflader, hvis nogen, kan være fejlneous
  • 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.

Eksempel på integrationstestcases til following scenarie: Applikationen har 3 moduler siger 'Loginside', 'Mailbox' og 'Slet emails' 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 Case Beskrivelse forventet resultat
1 Tjek grænsefladeforbindelsen mellem login og Mailbox modul Indtast loginoplysninger og klik på knappen Log ind Skal henvises til Mail Box
2 Tjek grænsefladeforbindelsen mellem Mailbox og Slet Mails modul Fra Mailbox vælg email og klik på en slet-knap Valgt email skal vises i mappen Slettet/Papirkurv

Typer af integrationstest

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

  • Big Bang tilgang:
  • Incremental Approach: som er yderligere opdelt i following
    • 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:

Bottom-up-integrationstest

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å øverste niveau af software architecture), som styrer påføringsflowet, 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 foregår fra top til bund following kontrolstrømmen af ​​softwaresystem. 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:

Top-down integrationstest

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.

Sandwich test

Sandwich test er en strategi, hvor topmoduler testes med lavere niveau moduler 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 integrationstest. Den gør brug af både stubber og drivere.

Sandwich test

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.

Kort beskrivelse af integrationstestplaner

Det inkluderer following egenskaber:

  • 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 praksis/retningslinjer for integrationstest

  • Bestem først integrationen Test strategi der kunne vedtages og later 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.