Hva er systemintegrasjonstesting?
Systemintegrasjonstesting er definert som en type programvaretesting utført i et integrert maskinvare- og programvaremiljø for å verifisere oppførselen til hele systemet. Det testes utført på et komplett, integrert system for å evaluere systemets samsvar med det spesifiserte kravet.
System Integration Testing (SIT) utføres for å verifisere samspillet mellom modulene i et programvaresystem. Den behandler verifisering av programvarekravene på høyt og lavt nivå som er spesifisert i programvarekravspesifikasjonen / dataene og programvaredesigndokumentet.
Det verifiserer også et programvaresystems sameksistens med andre og tester grensesnittet mellom modulene i programvaren. I denne typen testing blir moduler først testet hver for seg og deretter kombinert for å lage et system.
For eksempel kombineres programvare og / eller maskinvarekomponenter og testes gradvis til hele systemet er integrert.
I denne veiledningen vil du lære-
- Hva er systemintegrasjonstesting?
- Hvorfor teste systemintegrasjon
- Hvordan gjøre systemintegrasjonstesting
- Inn- og utgangskriterier for integrasjonstesting
- Testing av maskinvare til programvareintegrasjon
- Testing av programvare til programvareintegrasjon
- Top-Down Approach
- Bottom-up-tilnærming
- Big Bang-tilnærming
Hvorfor teste systemintegrasjon
I programvareutvikling gjøres systemintegrasjonstesting fordi,
- Det hjelper å oppdage Defekt tidlig
- Tidligere tilbakemelding om aksept av den enkelte modulen 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 gjennomfører tester for å avdekke feil assosiert med grensesnitt.
Alle modulene 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 kompliseres av den store utvidelsen av hele programmet. Når disse feilene er rettet og rettet, vises en ny, og prosessen fortsetter sømløst i en endeløs løkke . 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 integrasjonstester utføres på et system basert på målprosessoren. Metoden som brukes er Black Box Testing. Enten nedenfra og opp eller integrasjon kan brukes.
Testtilfeller defineres kun ved hjelp av programvarekravene på høyt nivå.
Programvareintegrasjon kan også i stor grad oppnås i vertsmiljøet, med enheter som er spesifikke for målmiljøet, fortsetter å bli simulert i verten. Gjenta 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 de-allokering. Det praktiske med å gjennomføre programvareintegrasjon i vertsmiljøet vil avhenge av hvor mye målspesifikk funksjonalitet som er der. For noen innebygde systemer vil koblingen med målmiljøet være veldig sterk, noe som gjør det upraktisk å gjennomføre programvareintegrasjon i vertsmiljøet.
Stor programvareutvikling 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.
Merk: Hvis bare programvare testes, kalles det Software Software Integration Testing [SSIT], og hvis både maskinvare og programvare blir testet, kalles det Hardware Software Integration Testing [HSIT].
Inn- og utgangskriterier for integrasjonstesting
Vanligvis brukes ETVX (Entry Criteria, Task, Validation, and Exit Criteria) når du utfører Integration Testing.
Oppføringskriterier:
- Fullføring av enhetstesting
Innganger:
- Programvarekrav Data
- Programvare for design av programvare
- Programvareverifiseringsplan
- Programvareintegrasjonsdokumenter
Aktiviteter:
- Basert på kravene på høyt og lavt nivå, opprett testtilfeller og prosedyrer
- Kombiner moduler på lavt nivå som implementerer en felles funksjonalitet
- Utvikle en testsele
- Test byggingen
- Når testen er bestått, blir bygningen kombinert med andre bygg og testet til systemet er integrert som en helhet.
- Utfør alle testene på den nye prosessorbaserte plattformen, og få resultatene
Utgangskriterier:
- Vellykket gjennomføring av integrasjonen av programvaremodulen på målet Maskinvare
- Riktig ytelse av programvaren i henhold til de spesifiserte kravene
Utganger
- Integrasjonstestrapporter
- Tilfeller og prosedyrer for programvaretest [SVCP].
Testing av integrering av maskinvareprogramvare
Hardware Software Integration Testing er en prosess for testing av programvarekomponenter (CSC) for funksjoner på høyt nivå på målvaremiljøet. Målet med testing av maskinvare / programvare integrasjon er å teste oppførselen til utviklet programvare integrert på maskinvarekomponenten.
Kravbasert testing av integrasjon av maskinvare og programvare
Målet med kravbasert testing av maskinvare / programvare er å sørge for at programvaren i måldatamaskinen tilfredsstiller kravene på høyt nivå. Typiske feil avslørt ved denne testmetoden inkluderer:
- Maskinvare / programvare grensesnitt feil
- Brudd på partisjonering av programvare.
- Manglende evne til å oppdage feil ved innebygd test
- Feil respons på maskinvarefeil
- Feil på grunn av sekvensering, forbigående inngangsbelastning og inngangseffekt transienter
- Tilbakemelding sløyfer feil oppførsel
- Feil eller feil kontroll av maskinvaren for minnestyring
- Problem med databuss
- Feil betjening av mekanismen for å verifisere kompatibilitet og korrekthet av programvare som kan lastes i felt
Integrering av maskinvareprogramvare håndterer verifisering av kravene på høyt nivå. Alle tester på dette nivået blir utført på maskinvaren.
- Black box testing er den primære testmetoden som brukes på dette testnivået.
- Definer bare testtilfeller fra kravene på høyt nivå
- En test må utføres på produksjonsstandard maskinvare (på mål)
Ting du bør vurdere når du designer testsaker for HW / SW Integration
- Riktig anskaffelse av alle data fra programvaren
- Skalering og rekkevidde av data som forventet fra maskinvare til programvare
- Riktig utdata av data fra programvare til maskinvare
- Data innenfor spesifikasjoner (normal rekkevidde)
- Data utenfor spesifikasjoner (unormalt område)
- Grensedata
- Avbryter behandlingen
- Timing
- Riktig minnebruk (adressering, overlapping osv.)
- Statlige overganger
Merk: For avbruddstesting, vil alle avbrudd verifiseres uavhengig av første forespørsel gjennom full service og etter fullføring. Test tilfeller vil være spesielt utformet for å tilstrekkelig teste avbrudd.
Testing av programvare til programvareintegrasjon
Det er testing av programvarekomponenten som opererer i verts- / måldatamaskinen
Miljø, mens du simulerer hele systemet [andre CSC-er], og på funksjonalitet på høyt nivå.
Den fokuserer på atferden 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 nedenfra og opp-tilnærming eller en kombinasjon av begge).
Inkrementell tilnærming
Inkrementell testing er en måte å integrere testing på. I denne typen testmetode tester du først hver modul av programvaren individuelt, og fortsetter deretter testen ved å legge til andre moduler til den, så en annen og så videre.
Inkrementell integrasjon er kontrasten til big bang-tilnærmingen. Programmet er konstruert og testet i små segmenter, der feil er lettere å isolere og korrigere. Grensesnitt blir mer sannsynlig testet fullstendig, og en systematisk testtilnærming kan brukes.
Det er to typer inkrementell testing
- Topp tilnærming
- Bottom Up-tilnærming
Top-Down Approach
I denne typen tilnærminger starter individuelt med å teste bare brukergrensesnittet, med den underliggende funksjonaliteten simulert av stubber, og 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 innarbeidet i strukturen enten på en bredde-første måte eller dybde-første måte.
- Dybde-første integrering integrerer alle moduler på en hovedkontrollbane av strukturen som vist i følgende diagram:
Modulintegrasjonsprosessen gjøres på følgende måte:
- Hovedkontrollmodulen brukes som en testdriver, og stubbene erstattes av alle moduler som er direkte underordnet hovedkontrollmodulen.
- De underordnede stubbene byttes ut en om gangen med faktiske moduler, avhengig av valgt tilnærming (bredde først eller dybde først).
- Tester utføres når hver modul er integrert.
- Når hvert sett med tester er fullført, erstattes en annen stubbe med en ekte modul når hvert sett med tester er fullført
- For å sikre at nye feil ikke er innført, kan det utføres regresjonstesting.
Prosessen fortsetter fra trinn 2 til hele programstrukturen er bygget. Top-down-strategien høres relativt ukomplisert ut, men i praksis oppstår logistiske problemer.
De vanligste av disse problemene oppstår når prosessering på lave nivåer i hierarkiet er nødvendig for å teste de øvre nivåene tilstrekkelig.
Stubber erstatter moduler på lavt nivå i begynnelsen av test fra ovenfra og ned, og derfor kan ingen signifikante data strømme oppover i programstrukturen.
Utfordringer som Tester kan møte:
- Forsink mange tester til stubber erstattes med faktiske moduler.
- Utvikle stubber som utfører begrensede funksjoner som simulerer selve modulen.
- Integrer programvaren fra bunnen av hierarkiet og oppover.
Merk: Den første tilnærmingen får oss til å miste litt kontroll over samsvar mellom spesifikke tester og innlemmelse av spesifikke moduler. Dette kan føre til vanskeligheter med å bestemme årsaken til feil som har en tendens til å bryte den svært begrensede karakteren fra ovenfra og ned.
Den andre tilnærmingen er brukbar, men kan føre til betydelig overhead, ettersom stubber blir stadig mer komplekse.
Bottom-up-tilnærming
Bottom-up integrasjon begynner konstruksjon og testing med moduler på det laveste nivået i programstrukturen. I denne prosessen er modulene integrert fra bunnen til toppen.
I denne tilnærmingen er prosessering som kreves for modulene underlagt et gitt nivå alltid tilgjengelig, og behovet for stubbene elimineres.
Denne integrasjonstestprosessen utføres i en serie på fire trinn
- Moduler på lavt nivå kombineres i klynger som utfører en spesifikk programvaredelfunksjon.
- En driver er skrevet for å koordinere testinngang og -utgang.
- Klyngen eller bygningen er testet.
- Drivere fjernes, og klynger kombineres og beveger seg oppover i programstrukturen.
Etter hvert som integrasjonen beveger seg oppover, er behovet for separate leksjoner for testførere. Faktisk, hvis de to øverste nivåene av programstruktur er integrert ovenfra og ned, kan antall drivere reduseres betydelig, og integrering av klynger er sterkt forenklet. Integrasjon følger mønsteret illustrert nedenfor. Etter hvert som integrasjonen beveger seg oppover, er behovet for separate leksjoner for testførere.
Merk: Hvis de to øverste nivåene av programstrukturen er integrert Top-down, kan antall drivere reduseres betydelig, og integreringen av builds er sterkt forenklet.
Big Bang-tilnærming
I denne tilnærmingen er ikke alle modulene integrert før og med mindre alle modulene er klare. Når de er klare, er alle modulene 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.
Dessuten vil det være stor sjanse for forekomst av kritiske feil i produksjonsmiljøet.
Denne tilnærmingen benyttes bare når integrasjonstesting må gjøres på en gang.
Sammendrag:
- Integrasjon utføres for å verifisere samspillet mellom modulene i et programvaresystem. Det hjelper å oppdage feil tidlig
- Integrasjonstesting kan gjøres for maskinvare-programvare eller maskinvare-maskinvareintegrasjon
- Integrasjonstesting gjøres med to metoder
- Inkrementell tilnærming
- Big bang-tilnærming
- Mens du utfører integrasjonstesting, brukes generelt ETVX (Entry Criteria, Task, Validation, and Exit Criteria) strategi.