Hva er SIT? Systemintegrasjonstesting med eksempel

Hva er systemintegrasjonstesting?

System Integrasjonstesting er definert som en type programvaretesting utført i et integrert maskinvare- og programvaremiljø for å verifisere oppførselen til hele systemet. Det er testing utført på et komplett, integrert system for å evaluere systemets samsvar med dets spesifiserte krav.

Systemintegrasjonstesting (SIT) utføres for å verifisere samspillet mellom modulene i et programvaresystem. Det omhandler verifisering av programvarekravene på høyt og lavt nivå som er spesifisert i programvarekravspesifikasjonen/dataene og programvaredesigndokumentet.

SIT verifiserer også et programvaresystems sameksistens med andre og tester grensesnittet mellom moduler i programvaren. I denne typen testing testes modulene først individuelt og kombineres deretter for å lage et system. For eksempel kombineres og testes programvare- og/eller maskinvarekomponenter gradvis inntil hele systemet er integrert.

Diagrammet ovenfor viser progresjonen som definerer SIT: separat verifiserte moduler slås sammen trinn for trinn inntil ett enkelt integrert system fortsatt er under testing.

Hvorfor tester systemintegrasjon?

I programvareteknikk utføres systemintegrasjonstesting fordi,

• Det hjelper å oppdage Defekt tidlig
• Tidligere tilbakemelding om aksept av den enkelte modul vil være tilgjengelig
• Planlegging av feilrettinger er fleksibel, og den kan overlappes med utvikling
• Riktig dataflyt
• Riktig kontrollflyt
• Riktig timing
• Riktig minnebruk
• Korrekt med programvarekrav

Systemintegrasjonstesting vs. systemtesting vs. brukeraksepttesting

Fordi disse tre nivåene går etter hverandre, blir de ofte forvekslet. Systemtesting undersøker ett ferdig bygg mot kravene, SIT undersøker skjøtene mellom byggene, og Brukerautentiseringstesting undersøker forretningsegnethet fra kundens synspunkt. Tabellen nedenfor skiller dem.

Parameter	Systemintegrasjonstesting	Systemtesting	Brukerautentiseringstesting
Primært fokus	Grensesnitt og dataflyt mellom integrerte moduler	Oppførselen til den samlede konstruksjonen som helhet	Forretningsfitness for reell bruk
Testnivå	Nivå to	Nivå tre	Siste nivå før lansering
Teknikk	Svart boks	Svart boks, hvit boks eller grå boks	Svart boks
Fremført av	Integrasjonstestere og -utviklere	Uavhengig testteam	Kunde eller sluttbrukere
Typiske defekter	Grensesnitt, timing, minne og datakartping feil	Funksjonelle og ikke-funksjonelle systemfeil	Brukbarhet og kravavvik
Kjører når	Etter Enhetstesting	Etter SIT	Etter systemtesting

Rekkefølgen er viktig. Modulene består enhetstesting, SIT beviser grensesnittene, systemtesting beviser det sammensatte produktet, og UAT bekrefter at produktet samsvarer med forretningsforventningene. Hopp overping SIT legger grensesnittfeil inn i UAT, hvor hver rettelse koster mye mer å gjøre.

Hvordan gjøre systemintegrasjonstesting

Det er en systematisk teknikk for å konstruere programstrukturen samtidig som man utfører tester for å avdekke feil knyttet til grensesnitt.

Alle moduler er integrert på forhånd, og hele programmet testes som en helhet. Men i løpet av denne prosessen vil det sannsynligvis oppstå et sett med feil.

Korrigering av slike feil er vanskelig fordi isolasjonsårsaker er komplisert av den enorme utvidelsen av hele programmet. Når disse feilene er rettet og rettet, vil en ny dukke opp, og prosessen fortsetter sømløst i en endeløs sløyfe. For å unngå denne situasjonen brukes en annen tilnærming, inkrementell integrasjon. Den inkrementelle tilnærmingen forklares i detalj i neste avsnitt.

Det er noen inkrementelle metoder som integrasjonstestene er utført på et system basert på målprosessoren. Metodikken som brukes er Svart Box Testing. Enten bottom-up eller top-down integrasjon kan brukes.

Testtilfeller defineres kun ved å bruke høynivåprogramvarekravene.

Programvareintegrasjon kan også i stor grad oppnås i vertsmiljøet, med enheter som er spesifikke for målmiljøet som fortsetter å bli simulert i verten. Gjentatte tester i målmiljøet for bekreftelse vil igjen være nødvendig.

Bekreftelsestester på dette nivået vil identifisere miljøspesifikke problemer, som feil i minneallokering og deallokering. Hvor praktisk det er å gjennomføre programvareintegrasjon i vertsmiljøet vil avhenge av hvor mye målspesifikk funksjonalitet som finnes. For noen innebygde systemer vil koblingen til målmiljøet være svært sterk, noe som gjør det upraktisk å gjennomføre programvareintegrasjon i vertsmiljøet.

Store programvareutviklinger vil dele programvareintegrasjon inn i en rekke nivåer. De lavere nivåene av programvareintegrasjon kan hovedsakelig være basert i vertsmiljøet, med senere nivåer av programvareintegrasjon som blir mer avhengig av målmiljøet.

OBS: Hvis bare programvare blir testet, kalles det Software Software Integration Testing [SSIT] og hvis både maskinvare og programvare testes, kalles det Hardware Software Integration Testing [HSIT].

Inkrementell tilnærming

Siden det å integrere alt samtidig gjør det vanskelig å isolere feil, følger de fleste team den trinnvise ruten som er beskrevet her.

Inkrementell testing er en måte for integrasjonstesting. I denne typen testmetode tester du først hver modul i programvaren individuelt og fortsetter deretter å teste ved å legge til andre moduler til den, deretter en annen og så videre.

Inkrementell integrasjon er kontrasten til big bang-tilnærmingen. Programmet er konstruert og testet i små segmenter, hvor feil er lettere å isolere og rette. Det er mer sannsynlig at grensesnitt testes fullstendig, og en systematisk testtilnærming kan brukes.

Det finnes to typer inkrementell testing

• Top down tilnærming
• Bottom Up-tilnærming

Topp-ned-tilnærming

I denne typen tilnærming, start individuelt med å teste bare brukergrensesnittet, med den underliggende funksjonaliteten simulert av stubber, deretter beveger du deg nedover og integrerer nedre og nedre lag som vist på bildet nedenfor.

• Fra og med hovedkontrollmodulen integreres modulene ved å bevege seg nedover gjennom kontrollhierarkiet
• Undermoduler til hovedkontrollmodulen er integrert i strukturen enten på en bredde-først måte eller dybde-først måte.
• Dybde-først-integrasjon integrerer alle moduler på en hovedkontrollbane for strukturen som vist i følgende diagram:

Modulintegrasjonsprosessen gjøres på følgende måte:

1. Hovedkontrollmodulen brukes som testdriver, og stubbene erstattes av alle moduler som er direkte underlagt hovedkontrollmodulen.
2. De underordnede stubbene erstattes en om gangen med faktiske moduler avhengig av valgt tilnærming (bredde først eller dybde først).
3. Tester utføres etter hvert som hver modul er integrert.
4. Etter fullføring av hvert sett med tester, erstattes en annen stump med en ekte modul ved fullføring av hvert sett med tester
5. For å sikre at nye feil ikke har blitt introdusert Regresjonstesting kan utføres.

Prosessen fortsetter fra trinn 2 til hele programstrukturen er bygget. Top-down-strategien høres relativt ukomplisert ut, men i praksis oppstår det logistiske problemer.

De vanligste av disse problemene oppstår når behandling på lave nivåer i hierarkiet kreves for å teste de øvre nivåene tilstrekkelig.

Stubber erstatter moduler på lavt nivå i begynnelsen av topp-ned-testing, og derfor kan ingen signifikante data flyte oppover i programstrukturen.

Utfordringer som testeren kan møte:

• Utsett mange tester til stubber er erstattet med faktiske moduler.
• Utvikle stubber som utfører begrensede funksjoner som simulerer selve modulen.
• Integrer programvaren fra bunnen av hierarkiet og oppover.

OBS: Den første tilnærmingen fører til at vi mister en viss kontroll over samsvar mellom spesifikke tester og inkorporering av spesifikke moduler. Dette kan resultere i vanskeligheter med å fastslå årsaken til feil som har en tendens til å bryte med den svært begrensede karakteren til ovenfra-ned-tilnærmingen.

Den andre tilnærmingen er gjennomførbar, men kan føre til betydelige overhead, ettersom stubber blir stadig mer komplekse.

Bottom-up-tilnærming

Bottom-up integrasjon starter konstruksjon og testing med moduler på det laveste nivået i programstrukturen. I denne prosessen integreres modulene fra bunnen til toppen.

I denne tilnærmingen er prosessering nødvendig for modulene underordnet et gitt nivå alltid tilgjengelig, og behovet for stubbene er eliminert.

Denne integrasjonstestprosessen utføres i en serie på fire trinn

1. Moduler på lavt nivå kombineres til klynger som utfører en spesifikk programvareunderfunksjon.
2. En driver er skrevet for å koordinere testcase-inngang og -utgang.
3. Klyngen eller bygget er testet.
4. Drivere fjernes, og klynger kombineres og beveger seg oppover i programstrukturen.

Etter hvert som integrasjonen beveger seg oppover, øker behovet for separate leksjoner med testdrivere. Faktisk, hvis de to øverste nivåene i programstrukturen integreres ovenfra og ned, kan antallet drivere reduseres betraktelig, og integrasjonen av klynger forenkles betraktelig. Integrasjonen følger mønsteret illustrert nedenfor.

OBS: Hvis de to øverste nivåene i programstrukturen er integrert ovenfra og ned, kan antall drivere reduseres betraktelig, og integrasjonen av byggverk blir betydelig forenklet.

Big Bang-tilnærming

I denne tilnærmingen blir ikke alle moduler integrert før og med mindre alle modulene er klare. Når de er klare, blir alle moduler integrert og deretter utført for å vite om alle de integrerte modulene fungerer eller ikke.

I denne tilnærmingen er det vanskelig å vite årsaken til feilen på grunn av å integrere alt på en gang.

Det vil også være stor sjanse for at de kritiske feilene oppstår i produksjonsmiljøet.

Denne tilnærmingen brukes bare når integrasjonstesting må gjøres på en gang.

Testing av maskinvareprogramvareintegrering

Testing av maskinvareprogramvareintegrering er en prosess for å teste Computer Software Components (CSC) for funksjonalitet på høyt nivå på målmaskinvaremiljøet. Målet med testing av maskinvare/programvareintegrering er å teste oppførselen til utviklet programvare integrert på maskinvarekomponenten.

Kravbasert maskinvare-programvareintegrasjonstesting

Målet med kravbasert maskinvare-/programvareintegrasjonstesting er å sikre at programvaren i måldatamaskinen vil tilfredsstille høynivåkravene. Typiske feil avslørt av denne testmetoden inkluderer:

• Maskinvare/programvare grensesnitt feil
• Brudd på programvarepartisjonering.
• Manglende evne til å oppdage feil ved innebygd test
• Feil respons på maskinvarefeil
• Feil på grunn av sekvensering, transiente inngangsbelastninger og inngangseffekttransienter
• Tilbakemeldinger gir feil oppførsel
• Feil eller feil kontroll av maskinvare for minneadministrasjon
• Problem med databussstrid
• Feil drift av mekanismen for å verifisere kompatibiliteten og korrektheten til feltlastbar programvare

Hardware Software Integration omhandler verifisering av høynivåkravene. Alle tester på dette nivået utføres på målmaskinvaren.

• Black box-testing er den primære testmetoden som brukes på dette testnivået.
• Definere test tilfeller bare fra høynivåkravene
• En test må utføres på produksjonsstandard maskinvare (på mål)

Ting du bør vurdere når du designer testtilfeller for HW/SW-integrasjon

• Korrekt innhenting av alle data av programvaren
• Skalering og rekkevidde av data som forventet fra maskinvare til programvare
• Riktig utdata fra programvare til maskinvare
• Data innenfor spesifikasjoner (normalt område)
• Data utenfor spesifikasjoner (unormalt område)
• Grensedata
• Avbryter behandlingen
• timing
• Riktig minnebruk (adressering, overlapping osv.)
• Statlige overganger

OBS: For avbruddstesting vil alle avbrudd verifiseres uavhengig av første forespørsel gjennom full service og frem til ferdigstillelse. Testtilfeller vil bli spesielt utformet for å teste avbrudd på en adekvat måte.

Programvare til programvareintegrasjonstesting

Det er testing av dataprogramvarekomponenten som opererer i verts-/måldatamaskinmiljøet, samtidig som den simulerer hele systemet [andre CSC-er], og på høynivåfunksjonalitet.

Den fokuserer på oppførselen til en CSC i et simulert verts-/målmiljø. Tilnærmingen som brukes for programvareintegrasjon kan være en inkrementell tilnærming (ovenfra-og-ned, en bottom-up-tilnærming eller en kombinasjon av begge, også kalt sandwich- eller hybridtilnærming).

Inn- og utgangskriterier for integrasjonstesting

Når tilnærmingen og de to integrasjonsvariantene er avgjort, er det gjenværende spørsmålet når et team kan starte og når det kan stoppe. Vanligvis brukes ETVX-strategien (Entry Criteria, Task, Validation, and Exit Criteria) når man utfører integrasjonstesting.

Oppføringskriterier:

• Ferdigstillelse av Enhetstesting

innganger:

• Programvarekrav Data
• Programvaredesigndokument
• Programvareverifiseringsplan
• Programvareintegrasjonsdokumenter

Aktiviteter:

• Lag testsaker og prosedyrer basert på kravene på høyt og lavt nivå
• Kombiner moduler på lavt nivå som implementerer en felles funksjonalitet
• Utvikle en testsele
• Test konstruksjonen
• Når testen er bestått, kombineres bygget med andre bygg og testes til systemet er integrert som en helhet.
• Utfør alle testene på nytt på den målprosessorbaserte plattformen, og få resultatene

Utgangskriterier:

• Vellykket fullføring av integreringen av programvaremodulen på målmaskinvaren
• Riktig ytelse av programvaren i henhold til de spesifiserte kravene

Utganger

• Integrasjonstestrapporter
• Programvaretestsaker og prosedyrer [SVCP].

Vanlige utfordringer i systemintegrasjonstesting

Selv med en god tilnærming og klare avslutningskriterier, skaper integrerte miljøer problemer som aldri dukker opp under enhetstesting. Å gjenkjenne dem tidlig holder tidsplanen realistisk.

• Miljømessig uoverensstemmelse: det integrerte test miljø speiler sjelden produksjonen, så timing- og konfigurasjonsfeil forsvinner før veldig sent.
• Avhengighetsberedskap: Tredjeparts- og eldre grensesnitt er ofte uferdige, noe som tvinger testere til å stole på stubber og simulatorer mye lenger enn planlagt.
• Datainkonsekvens: To moduler kan representere den samme posten forskjellig, noe som produserer stille avvik i stedet for synlige feil.
• Eierskap av feil: Når en feil strekker seg over to team, rotårsaksanalyse og feilhåndtering bremse merkbart ned.
• Regresjonskostnad: hvert nytt grensesnitt utvider Regresjonstesting suite, slik at manuell ny utførelse raskt blir uholdbar.

De fleste av disse er tidsplanrisikoer snarere enn tekniske blindveier. Å avtale datoer for grensesnittberedskap, simulatoromfang og eierskap til feilsortering før den første byggingen integreres, fjerner de fleste av dem. For leverandøreide grensesnitt, registrer også det avtalte meldingsformatet og en eskaleringskontakt, fordi en manglende eier forsinker en reparasjon lenger enn feilen tilsier.

Beste praksis for testing av systemintegrasjon

En repeterbar SIT-syklus avhenger mindre av verktøy enn av disiplin rundt grensesnitt, data og bevis. De fem fremgangsmåtene nedenfor passer like godt til en liten innebygd konstruksjon som til et stort landskap med flere leverandører, og hver av dem reduserer omarbeidet som når senere testnivåer.

1. Kartlegg hvert grensesnitt først. List opp hver datautveksling, dens retning, protokoll og eier før du skriver et enkelt testtilfelle.
2. Prioriter etter risiko. Verifiser grensesnittene som bærer penger, identitet eller regulerte data før de kosmetiske.
3. Design realistiske testdata. Dekk normale, grense- og unormale områder, slik at skalerings- og avrundingsfeil dukker opp tidlig.
4. Automatiser de stabile stiene. Ledningsgrensesnittet sjekker inn i en kontinuerlig integrering pipeline slik at hver bygg verifiserer dem på nytt.
5. Behold bevisene tracmulig. Koble hvert resultat til et krav gjennom en tracevnematrise så utgangskriterier kan bevises, ikke hevdes.

⚠ Tips: Frys grensesnittspesifikasjoner før integrasjonen starter. En sen endring av et meldingsformat ugyldiggjør testtilfeller på begge sider av grensesnittet og er den vanligste årsaken til SIT-omarbeiding.

Spørsmål og svar