Hvad er System Integration Testing (SIT) Eksempel

Hvad er systemintegrationstest?

Systemkrav Integrationstest er defineret som en type softwaretest, der udføres i et integreret hardware- og softwaremiljø for at verificere det komplette systems opførsel. Det er test udført på et komplet, integreret system for at evaluere systemets overensstemmelse med dets specificerede krav.

System Integration Testing (SIT) udføres for at verificere interaktionerne mellem modulerne i et softwaresystem. Den omhandler verifikationen af ​​softwarekravene på højt og lavt niveau, der er specificeret i softwarekravspecifikationen/dataene 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 til et system. For eksempel kombineres software- og/eller hardwarekomponenter og testes gradvist, indtil hele systemet er blevet integreret.

Hvorfor tester man systemintegration?

I Software Engineering udføres systemintegrationstest fordi,

• Det hjælper 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 dataflow
• Korrekt kontrolflow
• Korrekt timing
• Korrekt hukommelsesbrug
• Korrekt med softwarekrav

Sådan laver du systemintegrationstest

Det er en systematisk teknik til at konstruere programstrukturen, mens der udføres tests for at afdække fejl forbundet med grænseflader.

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

Korrektion af sådanne fejl er vanskelig, fordi isolationsårsager er kompliceret af den store udvidelse af hele programmet. Når disse fejl er rettet og rettet, vil en ny dukke op, og processen fortsætter problemfrit i en endeløs sløjfe. For at undgå denne situation anvendes en anden tilgang, Incremental Integration. Vi vil se flere detaljer om en inkrementel tilgang senere i selvstudiet.

Der er nogle trinvise metoder, såsom integrationstestene udføres på et system baseret på målprocessoren. Den anvendte metode er Sort Box Test. Enten bottom-up eller top-down integration kan bruges.

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

Softwareintegration kan også opnås i vid udstrækning i værtsmiljøet, hvor enheder, der er specifikke for målmiljøet, fortsætter med at blive simuleret i værten. Det vil igen være nødvendigt at gentage test i målmiljøet til bekræftelse.

Bekræftelsestest på dette niveau vil identificere miljøspecifikke problemer, såsom fejl i hukommelsestildeling og deallokering. Det praktiske ved at lede software integration i værtsmiljøet vil afhænge af, hvor meget målspecifik funktionalitet der er. For nogle indlejrede systemer vil koblingen til målmiljøet være meget stærk, hvilket gør det upraktisk at udføre softwareintegration i værtsmiljøet.

Store softwareudviklinger vil opdele softwareintegration i en række niveauer. De lavere niveauer af softwareintegration kunne overvejende være baseret i værtsmiljøet, hvor senere niveauer af softwareintegration bliver mere afhængige af målmiljøet.

Bemærk: Hvis kun software bliver testet, kaldes det Software Software Integration Testing [SSIT], og hvis både hardware og software bliver testet, kaldes det Hardware Software Integration Testing [HSIT].

Ind- og udgangskriterier for integrationstest

Normalt bruges ETVX (Entry Criteria, Task, Validation og Exit Criteria) strategi under udførelse af integrationstest.

Adgangskriterier:

• Færdiggørelse af Enhedstest

Indgange:

• Software Krav Data
• Software design dokument
• Softwareverifikationsplan
• Softwareintegrationsdokumenter

Aktiviteter:

• Opret testcases og -procedurer baseret på høj- og lavniveaukravene
• Kombiner moduler på lavt niveau, der implementerer en fælles funktionalitet
• Udvikl en testsele
• Test bygningen
• Når testen er bestået, kombineres buildet med andre builds og testes, indtil systemet er integreret som en helhed.
• Genudfør alle testene på den målprocessorbaserede platform, og få resultaterne

Afgangskriterier:

• Succesfuld afslutning af integrationen af ​​softwaremodulet på målhardwaren
• Korrekt ydeevne af softwaren i henhold til de specificerede krav

Udgange

• Integrationstestrapporter
• Softwaretestsager og -procedurer [SVCP].

Hardware Software Integration Test

Hardware Software Integration Test er en proces til at teste computersoftwarekomponenter (CSC) for funktionaliteter på højt niveau på målhardwaremiljøet. Målet med hardware/software integrationstest er at teste adfærden af ​​udviklet software integreret på hardwarekomponenten.

Kravbaseret hardware-software-integrationstest

Formålet med kravbaseret hardware/software-integrationstest er at sikre, at softwaren i målcomputeren opfylder de høje krav. Typiske fejl afsløret af denne testmetode omfatter:

• Hardware/software interface fejl
• Overtrædelser af softwarepartitionering.
• Manglende evne til at opdage fejl ved indbygget test
• Forkert svar på hardwarefejl
• Fejl på grund af sekvensering, transiente inputbelastninger og inputeffekttransienter
• Feedback sløjfer forkert adfærd
• Forkert eller ukorrekt kontrol af hukommelsesstyringshardware
• Problem med databusstrid
• Forkert betjening af mekanismen til at verificere kompatibiliteten og korrektheden af ​​feltindlæsbar software

Hardware Software Integration beskæftiger sig med verifikation af de høje krav. Alle test på dette niveau udføres på målhardwaren.

• Black box-testning er den primære testmetode, der bruges på dette testniveau.
• Definere test tilfælde kun fra de høje krav
• En test skal udføres på produktionsstandard hardware (på mål)

Ting at overveje, når man designer testcases til HW/SW-integration

• Korrekt indhentning af alle data af 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 område)
• Data uden for specifikationer (unormalt område)
• Grænsedata
• Afbryder behandlingen
• Timing
• Korrekt hukommelsesbrug (adressering, overlapninger osv.)
• Statsovergange

Bemærk: For afbrydelsestestning vil alle afbrydelser blive verificeret uafhængigt af den første anmodning gennem fuld service og frem til færdiggørelsen. Testcases vil blive specielt designet til at teste afbrydelser tilstrækkeligt.

Software til softwareintegrationstest

Det er test af computersoftwarekomponenten, der fungerer på værts-/målcomputeren

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

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

Inkrementel tilgang

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

Inkrementel integration er kontrasten til big bang-tilgangen. Programmet er opbygget og testet i små segmenter, hvor fejl er nemmere at isolere og rette. Grænseflader er mere tilbøjelige til at blive testet fuldstændigt, og en systematisk testmetode kan anvendes.

Der er to typer inkrementel test

• Top down tilgang
• Bottom Up tilgang

Top-down tilgang

I denne type tilgang, start individuelt med kun at teste brugergrænsefladen, med den underliggende funktionalitet simuleret af stubs, derefter bevæger du dig nedad og integrerer lavere og lavere lag som vist på billedet nedenfor.

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

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

1. Hovedkontrolmodulet bruges som testdriver, og stubbene erstattes af alle moduler direkte underordnet hovedkontrolmodulet.
2. De underordnede stubber udskiftes en ad gangen med faktiske moduler afhængigt af den valgte tilgang (bredde først eller dybde først).
3. Test udføres, efterhånden som hvert modul er integreret.
4. Efter afslutningen af ​​hvert sæt af tests, erstattes en anden stub med et rigtigt modul efter afslutningen af ​​hvert sæt af tests
5. For at sikre, at der ikke er indført nye fejl Regressionstest kan udføres.

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 behandling på lave niveauer i hierarkiet er påkrævet for at teste de øvre niveauer tilstrækkeligt.

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

Udfordringer, som testeren kan stå over for:

• Forsink mange tests, indtil stubberne er erstattet med faktiske moduler.
• Udvikle stubbe, der udfører begrænsede funktioner, der simulerer det faktiske 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 korrespondance mellem specifikke test og inkorporering af specifikke moduler. Dette kan resultere i vanskeligheder med at fastslå årsagen til fejl, som har en tendens til at overtræde den meget begrænsede karakter af top-down-tilgangen.

Den anden tilgang er brugbar, men kan føre til betydelige overhead, 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 integreres modulerne fra bunden til toppen.

I denne tilgang er behandling påkrævet for de moduler, der er underordnet et givet niveau, altid tilgængelig, og behovet for stubberne er elimineret.

Denne integrationstestproces udføres i en række af fire trin

1. Moduler på lavt niveau kombineres i klynger, der udfører en specifik software-underfunktion.
2. En driver er skrevet for at koordinere testcase input og output.
3. Klyngen eller buildet testes.
4. Drivere fjernes, og klynger kombineres ved at bevæge sig opad i programstrukturen.

Efterhånden som integrationen bevæger sig opad, er behovet for separate testkørertimer. Faktisk, hvis de to øverste niveauer af programstruktur er integreret top-down, kan antallet af drivere reduceres væsentligt, og integrationen af ​​klynger forenkles betydeligt. Integration følger mønsteret vist nedenfor. Efterhånden som integrationen bevæger sig opad, er behovet for separate testkørertimer.

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

Big Bang tilgang

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

I denne tilgang er det svært 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 defekter tidligt
• Integrationstest kan udføres for Hardware-Software eller Hardware-Hardware Integration
• Integrationstest udføres ved to metoder
  • Inkrementel tilgang
  • Big bang tilgang
• Under udførelse af integrationstest bruges generelt ETVX-strategien (Entry Criteria, Task, Validation og Exit Criteria).