what is system integration testing
Hva er systemintegrasjonstesting?
System Integration Testing (SIT) er den totale testen av hele systemet som består av mange delsystemer. Hovedmålet med SIT er å sikre at alle programvaremodulavhengigheter fungerer som de skal, og at dataintegriteten bevares mellom forskjellige moduler i hele systemet.
SUT (System Under Test) kan bestå av maskinvare, database, programvare, en kombinasjon av maskinvare og programvare eller et system som krever menneskelig interaksjon (HITL - Human in the Loop Testing).
Fra kontekst av programvareutvikling og programvaretesting, kan SIT betraktes som en testprosess som kontrollerer programvaresystemets medvirkning med andre.
SIT har en forutsetning der flere underliggende integrerte systemer allerede har gjennomgått og bestått systemtesting. SIT tester deretter de nødvendige interaksjonene mellom disse systemene som helhet. Leveringene av SIT sendes til UAT (testing av brukeraksept).
Hva du vil lære:
- Behov for systemintegrasjonstest
- Granititeten til SIT
- Hvordan utføre systemintegrasjonstesting?
- Systemtesting mot systemintegrasjonstesting
- Systemintegrasjonstesting mot testing av brukeraksept
- SIT Eksempel
- SIT-teknikker
- Konklusjon
- Anbefalt lesing
Behov for systemintegrasjonstest
Hovedfunksjonen til SIT er å gjøre testavhengigheter mellom forskjellige systemkomponenter, og regresjonstesting er derfor en viktig del av SIT.
For samarbeidsprosjekter er SIT en del av STLC (Software Testing lifecycle). Vanligvis gjennomføres en pre-SIT-runde av programvareleverandøren før kunden kjører sine egne SIT-testtilfeller.
I de fleste organisasjoner som jobber i IT-prosjekter etter Agile sprint-modellen, gjennomføres en SIT-runde av QA-teamet før hver utgivelse. Manglene funnet i SIT sendes tilbake til utviklingsteamet, og de jobber med løsningene.
MVP-utgivelsen (Minimum Viable Product) fra sprinten går bare når den blir passert gjennom SIT.
SIT kreves for å avsløre feilene som oppstår når interaksjon skjer mellom de integrerte delsystemene.
Det er flere komponenter som brukes i systemet, og de kan ikke testes enkeltvis. Selv om enheten testes individuelt, er det også en mulighet for at den kan mislykkes når den kombineres i systemet, da det er mange problemer som oppstår når delsystemer samhandler med hverandre.
Dermed er SIT veldig påkrevd for å avsløre og fikse feilene før du distribuerer systemet ved brukerens slutt. SIT oppdager manglene på et tidlig tidspunkt og sparer dermed tid og kostnad for å fikse det senere. Det hjelper deg også med å få tidligere tilbakemeldinger om akseptabiliteten til modulen.
Granititeten til SIT
SIT kan gjennomføres på tre forskjellige granularitetsnivåer:
(i) Testing innenfor systemet: Dette er et lavt nivå av integrasjonstesting som tar sikte på å smelte modulene sammen for å bygge et enhetlig system.
(ii) Intersystemtesting: Dette er testing på høyt nivå som trenger grensesnitt for uavhengige testede systemer.
(iii) Parvis testing: Her testes bare to sammenkoblede delsystemer i hele systemet om gangen. Dette tar sikte på å sikre at de to delsystemene kan fungere godt når de kombineres forutsatt at de andre delsystemene allerede fungerer bra.
Hvordan utføre systemintegrasjonstesting?
Den enkleste måten å utføre SIT på er gjennom datadrevet metode. Det krever minimum bruk av testverktøy for programvare.
beste gratis programvare for tidsklokke for ansatte
Først skjer datautveksling (dataimport og dataeksport) mellom systemkomponentene, og deretter blir oppførselen til hvert datafelt i det enkelte laget undersøkt.
Når programvaren er integrert, er det tre hovedtilstander for dataflyt som nevnt nedenfor:
# 1) Datatilstand i integrasjonslaget
c # intervjuspørsmål for erfarne
Integreringslaget fungerer som et grensesnitt mellom dataimport og eksport. Å utføre SIT på dette laget krever grunnleggende kunnskap om bestemt teknologi som skjema (XSD), XML, WSDL, DTD og EDI.
Ytelsen til datautveksling kan undersøkes i dette laget gjennom trinnene nedenfor:
- Valider dataegenskapene i dette laget mot BRD / FRD / TRD (forretningskravdokument / funksjonskravdokument / teknisk kravdokument).
- Kryssjekk webtjenesteforespørselen ved hjelp av XSD og WSDL.
- Kjør noen enhetstester og valider datatilordningene og forespørslene.
- Gå gjennom mellomvareloggene.
# 2) Datatilstand i databaselaget
Å utføre SIT på dette laget krever grunnleggende kunnskap om SQL og lagrede prosedyrer.
Ytelsen til datautveksling på dette laget kan undersøkes gjennom trinnene nedenfor:
- Sjekk om alle dataene fra integreringslaget har nådd vellykket i databaselaget og er blitt begått.
- Valider tabell- og kolonneegenskapene mot BRD / FRD / TRD.
- Valider begrensningene og datavalideringsreglene som brukes i databasen i henhold til forretningsspesifikasjoner.
- Sjekk lagrede prosedyrer for behandling av data.
- Gjennomgå serverloggene.
# 3) Datatilstand i applikasjonslaget
SIT kan utføres på dette laget gjennom trinnene nedenfor:
- Sjekk om alle obligatoriske felt er synlige i brukergrensesnittet.
- Utfør noen positive og negative testtilfeller og valider dataegenskapene.
Merk: Det kan være mange kombinasjoner som tilsvarer dataimport og dataeksport. Du må utføre SIT for de beste kombinasjonene med tanke på tiden som er tilgjengelig.
Systemtesting mot systemintegrasjonstesting
Forskjeller mellom systemtesting og SIT:
| SIT (System Integration Testing) | Systemtesting |
|---|---|
| SIT er hovedsakelig gjort for å sjekke hvordan individuelle moduler samhandler med hverandre når de er integrert i et system som helhet. | Systemtesting gjøres hovedsakelig for å sjekke om hele systemet fungerer som forventet med referanse til de spesifiserte kravene. |
| Det utføres etter enhetstesting og vil bli gjort hver gang en ny modul blir lagt til systemet. | Det gjennomføres på det endelige nivået, dvs. etter fullført integrasjonstesting og like før du leverer systemet for UAT. |
| Det er en test på lavt nivå. | Det er en testing på høyt nivå. |
| SIT-testtilfeller fokuserer på grensesnittet mellom systemkomponentene. | Test tilfeller, i dette tilfellet, fokuserer på å simulere virkelige scenarier. |
Systemintegrasjonstesting mot testing av brukeraksept
Her er forskjellen mellom SIT og UAT:
| SIT (System Integration Testing) | UAT (testing av brukeraksept) |
|---|---|
| Denne testen er fra perspektivet til grensesnitt mellom moduler. | Denne testingen er fra perspektivet til brukernes krav. |
| SIT gjøres av utviklere og testere. | UAT utføres av kunder og sluttbrukere. |
| Gjort etter enhetstesting og før systemtesting. | Dette er det siste testnivået og gjøres etter systemtesting. |
| Generelt vil problemene som finnes i SIT være relatert til dataflyt, kontrollflyt osv. | Problemene i UAT vil generelt være som funksjonene som ikke fungerer i henhold til brukerens krav. |
Bildet nedenfor på testnivåene vil gjøre strømmen fra enhetstesting til UAT tydelig for deg:
SIT Eksempel
La oss anta at et selskap bruker programvare for å lagre klientinformasjonen.
Denne programvaren har to skjermer i brukergrensesnittet - Skjerm 1 og skjerm 2, og den har en database. Detaljene som er angitt i skjerm 1 og skjerm 2 blir lagt inn i databasen. Per nå er selskapet fornøyd med denne programvaren.
Noen år senere finner selskapet imidlertid at programvaren ikke oppfyller kravene, og det er behov for forbedring. Derfor utviklet de en skjerm 3 og en database. Nå er dette systemet med skjerm 3 og en database integrert med den eldre / eksisterende programvaren.
Nå kalles testingen utført på hele systemet etter integrasjonen System Integration test. Her testes sameksistensen av et nytt system med et eksisterende system for å sikre at hele det integrerte systemet fungerer bra.
SIT-teknikker
Hovedsakelig er det fire tilnærminger for å gjøre SIT:
- Top-Down Approach
- Bottom-up-tilnærming
- Sandwich-tilnærming
- Big Bang-tilnærming
Top-down-tilnærming og bunn-opp-tilnærming er en slags trinnvise tilnærminger. La oss begynne diskusjonen med Top-down-tilnærming først.
# 1) Top-Down Approach:
Under dette starter testingen med bare den øverste modulen i et program, dvs. brukergrensesnittet som vi kaller som testdriver.
Funksjonaliteten til de underliggende modulene er simulert med stubber. Toppmodulen er integrert med modulnivået på det nedre nivået en etter en, og senere blir funksjonaliteten testet.
Når hver test er fullført, erstattes stubben med den virkelige modulen. Modulene kan integreres enten på en bredde-første måte eller dybde-første måte. Testen fortsetter til hele applikasjonen er bygget.
Fordelen med denne tilnærmingen er at det ikke er behov for drivere, og testtilfellene kan spesifiseres med tanke på systemets funksjonalitet.
Hovedutfordringen i denne typen tilnærminger er avhengigheten av tilgjengeligheten av modulnivåfunksjoner på lavere nivå. Det kan være forsinkelse i tester til de virkelige modulene byttes ut med stubber. Å skrive stubber er også vanskelig.
Nr. 2) Bottom-up-tilnærming:
Det eliminerer begrensningene fra top-down-tilnærmingen.
I denne metoden blir modulene på det laveste nivået først samlet for å danne klynger. Disse klyngene fungerer som en underfunksjon av applikasjonen. Deretter opprettes en driver for å håndtere testinngang og -utgang. Etter dette testes klyngen.
Når klyngen er testet, fjernes driveren, og klyngen kombineres med neste øvre nivå. Denne prosessen fortsetter til hele applikasjonsstrukturen er oppnådd.
Det er ikke behov for stubber i denne tilnærmingen. Det blir forenklet når behandlingen beveger seg oppover og behovet til sjåfører blir redusert. Denne tilnærmingen er tilrådelig for å gjøre SIT for objektorienterte systemer, sanntidssystemer og systemer med strenge ytelsesbehov.
Imidlertid er begrensningen av denne tilnærmingen det viktigste delsystemet, dvs. brukergrensesnittet ble testet til slutt.
# 3) Sandwichtilnærming:
Her kombineres ovennevnte og bunn opp-tilnærminger diskutert ovenfor.
Systemet oppfattes som å ha tre lag - det midterste laget som er mållaget, et lag over målet og et lag under målet. Testing utføres i begge retninger og samles ved mållaget som er i midten, og dette er illustrert i bildet nedenfor.
Sandwich Testing Strategi
En fordel med denne tilnærmingen er at topplaget og det nederste laget i systemet kan testes parallelt. Begrensningen med denne tilnærmingen er imidlertid at den ikke uttømmende tester de enkelte delsystemene før integrering.
For å eliminere denne begrensningen har vi modifisert sandwich-testing der integrasjonen av topp-, mellom- og bunnlag testes parallelt ved hjelp av stubber og drivere.
gratis DVD-kopimaskin for Windows 10
# 4) Big Bang-tilnærming:
I denne tilnærmingen gjøres integrering når alle modulene i applikasjonen er helt klare. Testing utføres etter integrering av alle modulene for å sjekke om det integrerte systemet fungerer eller ikke.
Det er utfordrende å finne årsaken til problemet i denne tilnærmingen, ettersom alt er integrert samtidig i motsetning til inkrementell testing. Denne tilnærmingen blir vanligvis benyttet når bare en SIT-runde er nødvendig.
Konklusjon
I denne artikkelen lærte vi hva som er System Integration Testing (SIT) og hvorfor er det viktig å utføre det.
Vi forsto kjernekonseptene, teknikkene, tilnærmingene og metodene som er involvert i å utføre SIT. Vi gikk også gjennom hvordan SIT er forskjellig fra UAT og systemtesting.
Håper du likte denne utmerkede artikkelen !!
Anbefalt lesing
- Hva er komponenttesting eller modultesting (Lær med eksempler)
- Hva er sammenligningstesting (lær med eksempler)
- Hva er integrasjonstesting (opplæring med eksempel på integrasjonstesting)
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Forskjellene mellom enhetstesting, integrasjonstesting og funksjonstesting
- Funksjonstesting mot ikke-funksjonell testing
- Integrering av selen med JMeter
- Spock for integrasjon og funksjonstesting med selen