Hvad er SIT? Systemintegrationstest med 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.

Systemintegrationstestning (SIT) udføres for at verificere interaktionerne mellem modulerne i et softwaresystem. Det omhandler verifikation af de softwarekrav på højt og lavt niveau, der er specificeret i softwarekravspecifikationen/dataene og softwaredesigndokumentet.

SIT verificerer også et softwaresystems sameksistens med andre og tester grænsefladen mellem moduler i softwareapplikationen. I denne type test testes moduler først individuelt og kombineres derefter for at danne et system. For eksempel kombineres og testes software- og/eller hardwarekomponenter gradvist, indtil hele systemet er integreret.

Diagrammet ovenfor viser den progression, der definerer SIT: separat verificerede moduler flettes sammen trin for trin, indtil et enkelt integreret system forbliver under test.

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

Systemintegrationstest vs. systemtest vs. brugeraccepttest

Fordi disse tre niveauer går efter hinanden, bliver de ofte forvekslet. Systemtest undersøger et færdigt byggeri i forhold til dets krav, SIT undersøger samlingerne mellem byggerierne, og Bruger Acceptance Testing undersøger forretningsegnethed fra kundens synspunkt. Tabellen nedenfor adskiller dem.

Parameter	Systemintegrationstest	Systemtest	Bruger Acceptance Testing
Primært fokus	Grænseflader og dataflow mellem integrerede moduler	Opførsel af den samlede bygning som helhed	Business fitness til reel brug
Testniveau	Niveau to	Niveau tre	Sidste niveau før lancering
Teknik	Sort kasse	Sort boks, hvid boks eller grå boks	Sort kasse
Udført af	Integrationstestere og -udviklere	Uafhængigt testhold	Kunde eller slutbrugere
Typiske defekter	Grænseflade, timing, hukommelse og datakortping fejl	Funktionelle og ikke-funktionelle systemfejl	Uoverensstemmelser mellem brugervenlighed og krav
Kører når	Efter Enhedstest	Efter SIT	Efter systemtest

Rækkefølgen er vigtig. Moduler består enhedstestning, SIT beviser grænsefladerne, systemtestning beviser det samlede produkt, og UAT bekræfter, at produktet matcher forretningsforventningerne. Spring overping SIT overfører grænsefladefejl til UAT, hvor hver rettelse koster langt mere at lave.

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ænsefladen.

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, inkrementel integration. Den inkrementelle tilgang forklares detaljeret i næste afsnit.

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 hukommelsesallokering og deallokering. Det praktiske ved at udføre softwareintegration 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].

Inkrementel tilgang

Da integration af alt på én gang gør det svært at isolere defekter, følger de fleste teams den trinvise rute, der er beskrevet her.

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, øges behovet for separate lektioner i testdrivere. Faktisk, hvis de to øverste niveauer af programstrukturen integreres top-down, kan antallet af drivere reduceres betydeligt, og integrationen af ​​klynger forenkles betydeligt. Integrationen følger mønsteret illustreret nedenfor.

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.

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 testning af computersoftwarekomponenten, der opererer i værts-/målcomputermiljøet, samtidig med at hele systemet [andre CSC'er] simuleres, og på højt niveau funktionalitet.

Den fokuserer på en CSC's opførsel i et simuleret værts-/målmiljø. Den anvendte tilgang til softwareintegration kan være en trinvis tilgang (top-down, bottom-up-tilgang eller en kombination af begge, også kaldet sandwich- eller hybridtilgangen).

Ind- og udgangskriterier for integrationstest

Når tilgangen og de to integrationsvarianter er afklaret, er det tilbageværende spørgsmål, hvornår et team kan starte, og hvornår det kan stoppe. Normalt anvendes ETVX-strategien (Entry Criteria, Task, Validation, and Exit Criteria) under integrationstestning.

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].

Almindelige udfordringer i systemintegrationstestning

Selv med en fornuftig tilgang og klare exitkriterier skaber integrerede miljøer problemer, der aldrig dukker op under enhedstestning. Ved at genkende dem tidligt holder du tidsplanen realistisk.

• Miljømæssig uoverensstemmelse: den integrerede testmiljø afspejler sjældent produktionen, så timing- og konfigurationsfejl undslipper først meget sent.
• Afhængighedsberedskab: Tredjeparts- og ældre grænseflader er ofte ufærdige, hvilket tvinger testere til at stole på stubs og simulatorer i langt længere tid end planlagt.
• Datauoverensstemmelse: To moduler kan repræsentere den samme post forskelligt, hvilket producerer tavse uoverensstemmelser i stedet for synlige fejl.
• Ejerskab af defekt: Når en fejl spænder over to teams, skal der foretages en rodårsagsanalyse og defekthåndtering sænke farten mærkbart.
• Regressionsomkostninger: hver ny grænseflade udvider regressionstest suite, så manuel genudførelse hurtigt bliver uholdbar.

De fleste af disse er tidsplanrisici snarere end tekniske blindgyder. At aftale datoer for grænsefladeklarhed, simulatoromfang og ejerskab for fejlvurdering, før den første build integreres, fjerner størstedelen af ​​dem. For leverandørejede grænseflader skal du også registrere det aftalte meddelelsesformat og en eskaleringskontakt, da en manglende ejer forsinker en reparation længere end fejlen berettiger.

Bedste praksis for systemintegrationstest

En gentagelig SIT-cyklus afhænger mindre af værktøjer end af disciplin omkring grænseflader, data og evidens. De fem fremgangsmåder nedenfor passer ligeligt til en lille embedded build og et stort landskab med flere leverandører, og hver især reducerer behovet for omarbejde, der når senere testniveauer.

1. Kortlæg først alle grænseflader. Angiv hver dataudveksling, dens retning, protokol og ejer, før du skriver en enkelt testcase.
2. Prioritér efter risiko. Bekræft grænsefladerne, der overfører penge, identitet eller regulerede data, før de kosmetiske.
3. Design realistiske testdata. Dæk normale, rand- og unormale områder, så skalerings- og afrundingsfejl dukker op tidligt.
4. Automatiser de stabile stier. Ledningsgrænsefladen tjekker ind i en kontinuerlig integration pipeline, så hver build verificerer dem igen.
5. Behold beviserne tracmulig. Forbind hvert resultat med et krav via en tracevnematrix så exitkriterier kan bevises, ikke hævdes.

⚠ Tip: Frys grænsefladespecifikationer, før integrationen begynder. En sen ændring af et meddelelsesformat ugyldiggør testtilfælde på begge sider af grænsefladen og er den mest almindelige årsag til SIT-omarbejdning.

Ofte Stillede Spørgsmål