what is system integration testing
Hvad er test af systemintegration?
System Integration Testing (SIT) er den samlede test af hele systemet, der består af mange undersystemer. Hovedformålet med SIT er at sikre, at alle softwaremodulafhængigheder fungerer korrekt, og at dataintegriteten bevares mellem forskellige moduler i hele systemet.
SUT (System Under Test) kan bestå af hardware, database, software, en kombination af hardware og software eller et system, der kræver menneskelig interaktion (HITL - Human in the Loop Testing).
Fra sammenhæng med software engineering og softwaretest kan SIT betragtes som en testproces, der kontrollerer softwaresystemets co-forekomst med andre.
SIT har en forudsætning, hvor flere underliggende integrerede systemer allerede har gennemgået og bestået systemtest. SIT tester derefter de krævede interaktioner mellem disse systemer som helhed. Leverancerne af SIT videregives til UAT (User accept testing).
Hvad du lærer:
- Behov for systemintegrationstest
- SIT's granularitet
- Hvordan udføres systemintegrationstest?
- Systemtest Vs System Integration Testing
- Systemintegrationstestning mod test af brugeraccept
- SIT Eksempel
- SIT-teknikker
- Konklusion
- Anbefalet læsning
Behov for systemintegrationstest
SIT's vigtigste funktion er at udføre testafhængigheder mellem forskellige systemkomponenter, og regressionstest er derfor en vigtig del af SIT.
For samarbejdsprojekter er SIT en del af STLC (Software Testing lifecycle). Generelt gennemføres en pre-SIT-runde af softwareleverandøren, før kunden kører deres egne SIT-testsager.
I de fleste af de organisationer, der arbejder i it-projekter efter Agile sprint-modellen, gennemføres en runde af SIT af QA-teamet før hver frigivelse. Manglerne i SIT sendes tilbage til udviklingsteamet, og de arbejder på rettelserne.
MVP-udgivelsen (Minimum Viable Product) fra sprinten går kun, når den passeres gennem SIT.
SIT er påkrævet for at afsløre de fejl, der opstår, når der sker interaktion mellem de integrerede undersystemer.
Der er flere komponenter, der bruges i systemet, og de kan ikke testes enkeltvis. Selvom enheden testes individuelt, er der også en mulighed for, at den kan mislykkes, når den kombineres i systemet, da der er mange problemer, der opstår, når undersystemer interagerer med hinanden.
Således er SIT meget krævet for at eksponere og rette fejlene, inden systemet implementeres i slutningen af brugeren. SIT registrerer manglerne på et tidligt tidspunkt og sparer dermed tid og omkostninger ved at rette det senere. Det hjælper dig også med at få tidligere feedback om modulets accept.
SIT's granularitet
SIT kan udføres på tre forskellige granularitetsniveauer:
(i) Intra-systemtest: Dette er et lavt niveau af integrationstest, der sigter mod at smelte modulerne sammen for at opbygge et samlet system.
(ii) Intersystemtest: Dette er test på højt niveau, der har behov for grænseflade til uafhængigt testede systemer.
(iii) Parvis test: Her testes kun to sammenkoblede undersystemer i hele systemet ad gangen. Dette sigter mod at sikre, at de to delsystemer kan fungere godt, når de kombineres, forudsat at de andre delsystemer allerede fungerer fint.
Hvordan udføres systemintegrationstest?
Den enkleste måde at udføre SIT på er via datadrevet metode. Det kræver mindst mulig brug af softwaretestværktøjer.
bedste program til at kontrollere computerens temperatur
For det første sker dataudveksling (dataimport og dataeksport) mellem systemkomponenterne, og derefter undersøges opførelsen af hvert datafelt inden for det enkelte lag.
Når softwaren er integreret, er der tre hovedtilstande for datastrøm som nævnt nedenfor:
# 1) Datatilstand inden for integrationslaget
Integrationslaget fungerer som en grænseflade mellem dataimport og -eksport. Udførelse af SIT på dette lag kræver grundlæggende viden om bestemt teknologi som skema (XSD), XML, WSDL, DTD og EDI.
Udførelsen af dataudveksling kan undersøges i dette lag gennem nedenstående trin:
- Valider dataegenskaberne inden for dette lag i forhold til BRD / FRD / TRD (forretningskravsdokument / funktionskravdokument / teknisk kravdokument).
- Kryds check webserviceanmodningen ved hjælp af XSD og WSDL.
- Kør nogle enhedstest, og valider datatilknytningerne og anmodningerne.
- Gennemgå mellemvarelogfiler.
# 2) Datatilstand inden for databaselaget
Udførelse af SIT på dette lag kræver grundlæggende viden om SQL og lagrede procedurer.
Udførelsen af dataudveksling på dette lag kan undersøges gennem nedenstående trin:
java vs c ++ syntaks
- Kontroller, om alle data fra integrationslaget er nået med succes i databaselaget og er blevet begået.
- Valider tabel- og kolonneegenskaberne i forhold til BRD / FRD / TRD.
- Valider de begrænsninger og datavalideringsregler, der anvendes i databasen i henhold til forretningsspecifikationer.
- Kontroller lagrede procedurer for behandling af data.
- Gennemgå serverlogfiler.
# 3) Datatilstand inden for applikationslaget
SIT kan udføres på dette lag gennem nedenstående trin:
- Kontroller, om alle de krævede felter er synlige i brugergrænsefladen.
- Udfør nogle positive og negative testtilfælde og valider dataegenskaberne.
Bemærk: Der kan være mange kombinationer svarende til dataimport og dataeksport. Du bliver nødt til at udføre SIT for de bedste kombinationer i betragtning af den tilgængelige tid.
Systemtest Vs System Integration Testing
Forskelle mellem systemtest og SIT:
| SIT (System Integration Testing) | Systemtest |
|---|---|
| SIT udføres hovedsageligt for at kontrollere, hvordan individuelle moduler interagerer med hinanden, når de integreres i et system som helhed. | Systemtest udføres hovedsageligt for at kontrollere, om hele systemet fungerer som forventet med henvisning til de specificerede krav. |
| Det udføres efter enhedstest og udføres hver gang, når et nyt modul føjes til systemet. | Det udføres på det endelige niveau, dvs. efter afslutningen af integrationstesten og lige før leveringen af systemet til UAT. |
| Det er en test på lavt niveau. | Det er en test på højt niveau. |
| SIT-testtilfælde fokuserer på grænsefladen mellem systemkomponenterne. | Testsager fokuserer i dette tilfælde på at simulere de virkelige scenarier. |
Systemintegrationstestning mod test af brugeraccept
Her er forskellen mellem SIT og UAT:
| SIT (System Integration Testing) | UAT (test af brugeraccept) |
|---|---|
| Denne test er fra perspektivet af grænsefladen mellem moduler. | Denne test er set fra brugerkravsperspektivet. |
| SIT udføres af udviklere og testere. | UAT udføres af kunder og slutbrugere. |
| Udført efter enhedstest og før systemtest. | Dette er det sidste testniveau og udføres efter systemtest. |
| Generelt vil de problemer, der findes i SIT, være relateret til datastrøm, kontrolflow osv. | De problemer, der findes i UAT, vil generelt være som de funktioner, der ikke fungerer i henhold til brugerens krav. |
Billedet nedenfor på testniveauerne gør strømmen fra enhedstest til UAT klar for dig:
SIT Eksempel
Lad os antage, at en virksomhed bruger software til at gemme klientoplysningerne.
Denne software har to skærme i brugergrænsefladen - Skærm 1 og skærm 2, og den har en database. Oplysningerne indtastet i skærm 1 og skærm 2 indtastes i databasen. Fra nu af er virksomheden tilfreds med denne software.
Et par år senere finder virksomheden imidlertid, at softwaren ikke opfylder kravene, og at der er behov for forbedring. Derfor udviklede de en skærm 3 og en database. Nu er dette system med skærm 3 og en database integreret med den ældre / eksisterende software.
Nu kaldes testen udført på hele systemet efter integrationen System Integration test. Her testes sameksistensen af et nyt system med et eksisterende for at sikre, at hele det integrerede system fungerer fint.
SIT-teknikker
Hovedsageligt er der 4 tilgange til at udføre SIT:
- Top-Down tilgang
- Bottom-up tilgang
- Sandwich tilgang
- Big Bang-tilgang
Top-down-tilgang og bottom-up-tilgang er en slags trinvise tilgange. Lad os først starte diskussionen med Top-down-tilgang.
# 1) Top-Down tilgang:
Under dette starter testningen kun med det øverste modul i en applikation, dvs. brugergrænsefladen, som vi kalder som testdriver.
Funktionaliteten af de underliggende moduler er simuleret med stubber. Topmodulet er integreret med modulstubben på et lavere niveau en efter en, og senere testes funktionaliteten.
Når hver test er afsluttet, erstattes stubben med det rigtige modul. Modulerne kan integreres enten i en bredde-første måde eller dybde-første måde. Testen fortsætter, indtil hele applikationen er bygget.
Fordelen ved denne tilgang er, at der ikke er behov for chauffører, og testcases kan specificeres med hensyn til systemets funktionalitet.
Den største udfordring i denne type tilgang er afhængigheden af tilgængeligheden af modulniveaufunktioner på lavere niveau. Der kan være forsinkelse i test, indtil de virkelige moduler udskiftes med stubber. Det er også svært at skrive stubbe.
# 2) Bottom-up tilgang:
Det eliminerer begrænsningerne ved top-down-tilgangen.
I denne metode samles først modulerne på det laveste niveau for at danne klynger. Disse klynger fungerer som en underfunktion af applikationen. Derefter oprettes en driver til at styre input og output af testcase. Herefter testes klyngen.
Når klyngen er testet, fjernes driveren, og klyngen kombineres med det næste øverste niveau. Denne proces fortsætter, indtil hele applikationsstrukturen er opnået.
Der er ikke behov for stubbe i denne tilgang. Det bliver forenklet, når behandlingen bevæger sig opad, og chaufførernes behov reduceres. Denne tilgang er tilrådelig til at udføre SIT til objektorienterede systemer, realtidssystemer og systemer med strenge præstationsbehov.
Imidlertid er begrænsningen af denne tilgang det vigtigste delsystem, dvs. UI testes sidst.
# 3) Sandwich tilgang:
Her kombineres ovenstående og nedadgående fremgangsmåder diskuteret ovenfor sammen.
Systemet opfattes som at have tre lag - det midterste lag, der er mållaget, et lag over målet og et lag under målet. Test udføres i begge retninger og samles ved mållaget, som er i midten, og dette er illustreret i nedenstående billede.
Sandwich teststrategi
En fordel ved denne fremgangsmåde er, at systemets øverste lag og bundlag kan testes parallelt. Begrænsningen ved denne fremgangsmåde er imidlertid, at den ikke udtømmende tester de enkelte delsystemer inden integration.
For at eliminere denne begrænsning har vi ændret sandwich-test, hvor integrationen af top-, mellem- og bundlag testes parallelt ved hjælp af stubbe og drivere.
# 4) Big Bang-tilgang:
I denne tilgang udføres integration, når alle programmets moduler er helt klar. Test udføres efter integrationen af alle modulerne for at kontrollere, om det integrerede system fungerer eller ej.
Det er udfordrende at finde årsagen til problemet i denne tilgang, da alt er integreret på én gang i modsætning til inkrementel test. Denne tilgang anvendes generelt, når kun en SIT-runde er påkrævet.
Konklusion
I denne artikel lærte vi, hvad der er System Integration Testing (SIT), og hvorfor er det vigtigt at udføre det.
hvordan man spiller .torrent filer
Vi forstod kernebegreberne, teknikkerne, tilgangene og metoderne involveret i udførelsen af SIT. Vi gik også igennem, hvordan SIT er forskellig fra UAT og systemtest.
Håber du nød denne fremragende artikel !!
Anbefalet læsning
- Hvad er komponenttest eller modultest (lær med eksempler)
- Hvad er sammenligningstest (lær med eksempler)
- Hvad er integrationstest (tutorial med integrationstesteksempel)
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Forskellene mellem enhedstest, integrationstest og funktionstest
- Funktionel testning mod ikke-funktionel testning
- Integration af selen med JMeter
- Spock til integration og funktionstest med selen