Hvad er System Integration Testing (SIT) med eksempel

Indholdsfortegnelse:

Anonim

Hvad er test af systemintegration?

Systemintegrationstest defineres som en type softwaretest udført i et integreret hardware- og softwaremiljø for at verificere det komplette systems opførsel. Det testes udført på et komplet, integreret system for at evaluere systemets overensstemmelse med det specificerede krav.

System Integration Testing (SIT) udføres for at verificere interaktionerne mellem modulerne i et softwaresystem. Det handler om verifikation af de høje og lave niveausoftwarekrav, der er specificeret i specifikation / data om softwarekrav og softwaredesigndokumentet.

Det verificerer også et softwaresystems sameksistens med andre og tester grænsefladen mellem modulerne i softwareapplikationen. I denne type test testes moduler først individuelt og kombineres derefter for at skabe et system.

For eksempel kombineres software og / eller hardwarekomponenter og testes gradvis, indtil hele systemet er integreret.

I denne vejledning lærer du-

  • Hvad er test af systemintegration?
  • Hvorfor teste systemintegration
  • Sådan foretages test af systemintegration
  • Indgangs- og udgangskriterier for integrationstest
  • Test af integration mellem hardware og software
  • Test af software til software-integration
  • Top-Down tilgang
  • Bottom-up tilgang
  • Big Bang-tilgang

Hvorfor teste systemintegration

I softwareteknik udføres systemintegrationstest, fordi

  • Det hjælper med at opdage defekt tidligt
  • Tidligere feedback om accept af det enkelte modul vil være tilgængelig
  • Planlægning af fejlrettelser er fleksibel, og den kan overlappes med udvikling
  • Korrekt datastrøm
  • Korrekt kontrolflow
  • Korrekt timing
  • Korrekt hukommelsesforbrug
  • Korrekt med softwarekrav

Sådan foretages test af systemintegration

Det er en systematisk teknik til konstruktion af programstrukturen, mens du udfører tests for at afdække fejl forbundet med grænseflade.

Alle moduler er integreret på forhånd, og hele programmet testes som en helhed. Men under denne proces er der sandsynligvis et sæt fejl.

Korrektion af sådanne fejl er vanskelig, fordi årsager til isolering er kompliceret af den store udvidelse af hele programmet. Når disse fejl er rettet og rettet, vises en ny, og processen fortsætter problemfrit i en endeløs løkke . For at undgå denne situation anvendes en anden tilgang, inkrementel integration. Vi vil se flere detaljer om en inkrementel tilgang senere i vejledningen.

Der er nogle inkrementelle metoder, som f.eks. Integrationstestene udføres på et system baseret på målprocessoren. Den anvendte metode er Black Box Testing. Enten bund-op eller top-down integration kan bruges.

Testcases defineres kun ved hjælp af softwarekravene på højt niveau.

Softwareintegration kan også opnås stort set i værtsmiljøet, hvor enheder, der er specifikke for målmiljøet, fortsat simuleres i værten. Gentagelse af test i målmiljøet til bekræftelse vil igen være nødvendigt.

Bekræftelsestest på dette niveau identificerer miljøspecifikke problemer, såsom fejl i hukommelsesallokering og de-allokering. Den praktiske gennemførelse af softwareintegration i værtsmiljøet afhænger af, hvor meget målspecifik funktionalitet der er. For nogle indlejrede systemer vil koblingen med målmiljøet være meget stærk, hvilket gør det upraktisk at gennemføre softwareintegration i værtsmiljøet.

Stor softwareudvikling vil opdele softwareintegration i en række niveauer. De lavere niveauer af softwareintegration kan overvejende være baseret i værtsmiljøet, hvor senere niveauer af softwareintegration bliver mere afhængig af målmiljøet.

Bemærk: Hvis kun software testes, kaldes det software-software-integrationstest [SSIT], og hvis både hardware og software testes, kaldes det hardware-software-integrationstest [HSIT].

Indgangs- og udgangskriterier for integrationstest

Normalt anvendes ETVX (Entry Criteria, Task, Validation and Exit Criteria) -strategi, når du udfører Integration Testing.

Indgangskriterier:

  • Afslutning af enhedstest

Indgange:

  • Software Krav Data
  • Software Design-dokument
  • Softwareverifikationsplan
  • Softwareintegrationsdokumenter

Aktiviteter:

  • Baseret på kravene på højt og lavt niveau oprettes testsager og procedurer
  • Kombiner moduler med lavt niveau, der implementerer en fælles funktionalitet
  • Udvikl en testsele
  • Test build
  • Når testen er bestået, kombineres build med andre builds og testes, indtil systemet er integreret som en helhed.
  • Udfør alle testene igen på den målprocessorbaserede platform og få resultaterne

Udgangskriterier:

  • Vellykket afslutning af integrationen af ​​softwaremodulet på målet hardware
  • Korrekt ydelse af softwaren i henhold til de specificerede krav

Udgange

  • Integrations testrapporter
  • Softwaretest Tilfælde og procedurer [SVCP].

Test af integration af hardware-software

Hardware Software Integration Testing er en proces til test af Computersoftwarekomponenter (CSC) for funktionaliteter på højt niveau i målhardwaremiljøet. Målet med hardware- / softwareintegrationstest er at teste adfærden for udviklet software integreret på hardwarekomponenten.

Kravsbaseret hardware-software integrationstest

Målet med kravsbaseret test af hardware / software-integration er at sikre, at softwaren i målcomputeren opfylder kravene på højt niveau. Typiske fejl afsløret ved denne testmetode inkluderer:

  • Fejl ved hardware / software-grænseflader
  • Overtrædelser af partitionering af software.
  • Manglende evne til at opdage fejl ved hjælp af indbygget test
  • Forkert svar på hardwarefejl
  • Fejl på grund af sekventering, forbigående indgangsbelastninger og indgangseffekt transienter
  • Feedback sløjfer forkert opførsel
  • Forkert eller forkert kontrol af hardware til hukommelsesadministration
  • Problem med databus-konflikt
  • Forkert betjening af mekanismen for at kontrollere kompatibiliteten og rigtigheden af ​​software, der kan indlæses i marken

Integration af hardware-software beskæftiger sig med verifikation af kravene på højt niveau. Alle tests på dette niveau udføres på målhardwaren.

  • Black box-test er den primære testmetode, der anvendes på dette testniveau.
  • Definer kun testcases fra kravene på højt niveau
  • En test skal udføres på produktionsstandardhardware (på mål)

Ting, du skal overveje, når du designer testsager til HW / SW-integration

  • Korrekt erhvervelse af alle data fra softwaren
  • Skalering og rækkevidde af data som forventet fra hardware til software
  • Korrekt output af data fra software til hardware
  • Data inden for specifikationer (normalt interval)
  • Data uden for specifikationer (unormalt interval)
  • Grænsedata
  • Afbryder behandlingen
  • Timing
  • Korrekt hukommelsesforbrug (adressering, overlapning osv.)
  • Statlige overgange

Bemærk: Ved afbrydelse af test bliver alle afbrydelser verificeret uafhængigt af den første anmodning gennem fuld service og efter afslutningen. Testcases vil være specielt designet til at afprøve afbrydelser på passende vis.

Test af software til software-integration

Det er testningen af ​​Computersoftware-komponenten, der fungerer inden for værts- / målcomputeren

Miljø, mens man simulerer hele systemet [andre CSC'er] og på højt niveau funktionalitet.

Det fokuserer på adfærd fra en CSC i et simuleret vært / målmiljø. Den tilgang, der anvendes til softwareintegration, kan være en trinvis tilgang (top-down, en bottom-up-tilgang eller en kombination af begge).

Inkrementel tilgang

Inkrementel test er en måde at integrere test på. I denne type testmetode tester du først hvert modul af softwaren individuelt og fortsætter derefter testen ved at tilføje andre moduler til det, derefter et andet og så videre.

Inkrementel integration er kontrasten til big bang-tilgangen. Programmet er konstrueret og testet i små segmenter, hvor fejl er lettere at isolere og rette. Grænseflader testes mere sandsynligt fuldstændigt, og en systematisk testtilgang kan anvendes.

Der er to typer inkrementel test

  • Top-down tilgang
  • Bottom Up tilgang

Top-Down tilgang

I denne type tilgang starter den enkelte med kun at teste brugergrænsefladen med den underliggende funktionalitet simuleret af stubbe, hvorefter du bevæger dig nedad og integrerer nedre og nedre lag som vist på billedet nedenfor.

  • Fra og med hovedstyringsmodulet integreres modulerne ved at bevæge sig nedad gennem kontrolhierarkiet
  • Undermoduler til hovedstyringsmodulet er inkorporeret i strukturen enten på en bredde-første måde eller dybde-første måde.
  • Dybde-første integration integrerer alle moduler på en større kontrolsti i strukturen som vist i følgende diagram:

Modulintegrationsprocessen udføres på følgende måde:

  1. Hovedkontrolmodulet bruges som testdriver, og stubberne erstattes af alle moduler, der er direkte underordnede hovedkontrolmodulet.
  2. De underordnede stubbe udskiftes en ad gangen med faktiske moduler afhængigt af den valgte tilgang (bredde først eller dybde først).
  3. Test udføres, da hvert modul er integreret.
  4. Efter afslutningen af ​​hvert sæt tests udskiftes en anden stub med et ægte modul ved afslutningen af ​​hvert sæt tests
  5. For at sikre, at der ikke er introduceret nye fejl, kan der udføres regressionstest.

Processen fortsætter fra trin 2, indtil hele programstrukturen er bygget. Top-down-strategien lyder relativt ukompliceret, men i praksis opstår der logistiske problemer.

De mest almindelige af disse problemer opstår, når der kræves behandling på lave niveauer i hierarkiet for at kunne teste de øverste niveauer tilstrækkeligt.

Stubbe erstatter moduler på lavt niveau i begyndelsen af ​​top-down-test, og derfor kan ingen væsentlige data strømme opad i programstrukturen.

Udfordringer, som Tester måske står over for:

  • Forsink mange test, indtil stubbe erstattes med faktiske moduler.
  • Udviklestubber, der udfører begrænsede funktioner, der simulerer det aktuelle modul.
  • Integrer softwaren fra bunden af ​​hierarkiet og opad.

Bemærk: Den første tilgang får os til at miste en vis kontrol over overensstemmelse mellem specifikke tests og inkorporering af specifikke moduler. Dette kan resultere i vanskeligheder med at bestemme årsagen til fejl, der har tendens til at krænke top-down-tilgangens meget begrænsede karakter.

Den anden tilgang er brugbar, men kan føre til betydelige omkostninger, da stubbe bliver mere og mere komplekse.

Bottom-up tilgang

Bottom-up integration begynder konstruktion og test med moduler på det laveste niveau i programstrukturen. I denne proces er modulerne integreret fra bund til top.

I denne fremgangsmåde er behandling, der kræves til modulerne underlagt et givet niveau, altid tilgængelig, og behovet for stubbe elimineres.

Denne integrationstestproces udføres i en serie på fire trin

  1. Moduler på lavt niveau kombineres i klynger, der udfører en bestemt softwarefunktion.
  2. En driver er skrevet til at koordinere input og output til testcase.
  3. Klyngen eller buildet er testet.
  4. Drivere fjernes, og klynger kombineres og bevæger sig opad i programstrukturen.

Efterhånden som integrationen bevæger sig opad, er behovet for separate testdrivere lektioner. Faktisk, hvis de to øverste niveauer af programstruktur er integreret top-down, kan antallet af drivere reduceres betydeligt, og integration af klynger er meget forenklet. Integration følger mønsteret illustreret nedenfor. Efterhånden som integrationen bevæger sig opad, er behovet for separate testdrivere lektioner.

Bemærk: Hvis de to øverste niveauer af programstruktur er integreret Top-down, kan antallet af drivere reduceres betydeligt, og integrationen af ​​builds er meget forenklet.

Big Bang-tilgang

I denne tilgang er alle moduler ikke integreret før og medmindre alle modulerne er klar. Når de er klar, er alle moduler integreret, og derefter udføres det for at vide, om alle de integrerede moduler fungerer eller ej.

I denne tilgang er det vanskeligt at kende årsagen til fejlen på grund af at integrere alt på én gang.

Der vil også være en stor chance for forekomst af de kritiske fejl i produktionsmiljøet.

Denne tilgang anvendes kun, når integrationstest skal udføres på én gang.

Resumé:

  • Integration udføres for at verificere interaktionerne mellem modulerne i et softwaresystem. Det hjælper med at opdage defekt tidligt
  • Integrationstest kan udføres for hardware-software eller hardware-hardware-integration
  • Integrationstest udføres efter to metoder
    • Inkrementel tilgang
    • Big bang tilgang
  • Mens der udføres Integration Testing, anvendes generelt ETVX (Entry Criteria, Task, Validation, and Exit Criteria) strategi.