Hva er System Integration Testing (SIT) 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 interaksjonene mellom modulene i et programvaresystem. Den omhandler verifiseringen av programvarekravene på høyt og lavt nivå spesifisert i programvarekravspesifikasjonen/dataene og programvaredesigndokumentet. Den verifiserer også et programvaresystems sameksistens med andre og tester grensesnittet mellom moduler i programvareapplikasjonen. I denne typen testing testes moduler først individuelt og deretter kombinert for å lage et system. For eksempel blir programvare- og/eller maskinvarekomponenter kombinert og testet gradvis inntil hele systemet er integrert.

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

Hvordan gjøre systemintegrasjonstesting

Det er en systematisk teknikk for å konstruere programstrukturen mens du 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. Vi vil se mer detaljer om en inkrementell tilnærming senere i opplæringen.

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, for eksempel feil i minnetildeling og deallokering. Det praktiske ved å dirigere 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 veldig 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].

Inn- og utgangskriterier for integrasjonstesting

Vanligvis brukes ETVX-strategien (Entry Criteria, Task, Validation og Exit Criteria) når du 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].

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 datamaskinprogramvarekomponenten som opererer på verts-/måldatamaskinen

Miljø, mens du 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 (top-down, en bottom-up-tilnærming eller en kombinasjon av begge).

Inkrementell tilnærming

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, er behovet for separate testførertimer. Faktisk, hvis de to øverste nivåene i programstrukturen er integrert ovenfra og ned, kan antallet drivere reduseres betraktelig, og integrasjon av klynger blir betydelig forenklet. Integrasjon følger mønsteret illustrert nedenfor. Etter hvert som integrasjonen beveger seg oppover, er behovet for separate testførertimer.

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.

Sammendrag

• Integrasjon utføres for å verifisere interaksjonene mellom modulene i et programvaresystem. Det hjelper å oppdage feil tidlig
• Integrasjonstesting kan gjøres for maskinvare-programvare eller maskinvare-maskinvare-integrasjon
• Integrasjonstesting gjøres ved to metoder
  • Inkrementell tilnærming
  • Big bang-tilnærming
• Mens du utfører integrasjonstesting, brukes generelt ETVX-strategien (Entry Criteria, Task, Validation og Exit Criteria).