what is system integration testing
Vad är systemintegrationstestning?
System Integration Testing (SIT) är den övergripande testningen av hela systemet som består av många delsystem. Huvudsyftet med SIT är att se till att alla mjukvarumodulberoende fungerar korrekt och dataintegriteten bevaras mellan olika moduler i hela systemet.
SUT (System Under Test) kan bestå av hårdvara, databas, programvara, en kombination av hårdvara och programvara eller ett system som kräver mänsklig interaktion (HITL - Human in the Loop Testing).
Ur kontext av programvaruteknik och programvarutestning kan SIT betraktas som en testprocess som kontrollerar mjukvarusystemets samverkan med andra.
SIT har en förutsättning där flera underliggande integrerade system redan har genomgått och godkänt systemtestning. SIT testar sedan de interaktioner som krävs mellan dessa system som helhet. Leveranserna av SIT skickas till UAT (test av användaracceptans).
Vad du kommer att lära dig:
- Behov av systemintegrationstest
- SIT: s granularitet
- Hur utför jag systemintegrationstester?
- Systemtestning mot systemintegrationstestning
- Systemintegrationstestning mot testning av användaracceptans
- SIT Exempel
- SIT-tekniker
- Slutsats
- Rekommenderad läsning
Behov av systemintegrationstest
SIT: s huvudsakliga funktion är att göra testberoenden mellan olika systemkomponenter och därför är regressionstest en viktig del av SIT.
För samarbetsprojekt är SIT en del av STLC (Software Testing lifecycle). I allmänhet genomförs en pre-SIT-runda av programvaruleverantören innan kunden kör sina egna SIT-testfall.
I de flesta organisationer som arbetar med IT-projekt enligt Agile sprint-modellen genomförs en SIT-runda av QA-teamet före varje release. Defekterna i SIT skickas tillbaka till utvecklingsteamet och de arbetar med fixarna.
Släppet från MVP (Minimum Viable Product) från sprinten går bara när det passeras genom SIT.
SIT krävs för att avslöja de fel som uppstår när interaktion sker mellan de integrerade delsystemen.
Det finns flera komponenter som används i systemet och de kan inte enhetstestas individuellt. Även om enheten testas individuellt, finns det också en möjlighet att den kan misslyckas när den kombineras i systemet eftersom det finns många problem som uppstår när delsystem interagerar med varandra.
SIT krävs alltså mycket för att avslöja och åtgärda felen innan systemet distribueras i slutet av användaren. SIT upptäcker defekterna i ett tidigt skede och sparar därmed tid och kostnad för att åtgärda det senare. Det hjälper dig också att få tidigare feedback om modulens godtagbarhet.
SIT: s granularitet
SIT kan genomföras på tre olika granularitetsnivåer:
(i) Intestsystemtestning: Detta är en låg nivå av integrationstest som syftar till att smälta samman modulerna för att bygga ett enhetligt system.
(ii) Testning mellan system: Detta är test på hög nivå som behöver gränssnitt oberoende testade system.
(iii) Parvis testning: Här testas bara två sammankopplade delsystem i hela systemet åt gången. Detta syftar till att säkerställa att de två delsystemen kan fungera bra när de kombineras förutsatt att de andra delsystemen redan fungerar bra.
Hur utför jag systemintegrationstester?
Det enklaste sättet att utföra SIT är genom datadriven metod. Det kräver minimalt med användning av testverktyg för programvara.
bästa gratisanställda mjukvara för tidsklocka
Först sker datautbyte (dataimport och dataexport) mellan systemkomponenterna och sedan undersöks beteendet hos varje datafält inom det enskilda lagret.
När programvaran är integrerad finns det tre huvudtillstånd för dataflöde som nämns nedan:
# 1) Datatillstånd inom Integration Layer
Integrationslagret fungerar som ett gränssnitt mellan dataimporten och exporten. Att utföra SIT i detta lager kräver viss grundläggande kunskap om viss teknik som schema (XSD), XML, WSDL, DTD och EDI.
Prestanda för datautbyte kan undersökas i detta lager genom följande steg:
- Validera dataegenskaperna i detta lager mot BRD / FRD / TRD (Affärskravsdokument / Funktionskravdokument / Tekniskt kravdokument).
- Korskolla webbtjänstförfrågan med XSD och WSDL.
- Kör några enhetstester och validera datakartningarna och förfrågningarna.
- Granska mellanvaruloggarna.
# 2) Datatillstånd inom databaslagret
c ++ odefinierat referensfel
Att utföra SIT i detta lager kräver grundläggande kunskaper om SQL och lagrade procedurer.
Prestanda för datautbyte i detta lager kan undersökas genom följande steg:
- Kontrollera om alla data från integrationslagret har nått framgångsrikt i databaslagret och har begåtts.
- Validera tabell- och kolumnegenskaperna mot BRD / FRD / TRD.
- Validera de begränsningar och datavalideringsregler som tillämpas i databasen enligt affärsspecifikationer.
- Kontrollera lagrade procedurer för eventuell bearbetning av data.
- Granska serverloggar.
# 3) Datatillstånd inom applikationslagret
SIT kan utföras i detta lager genom följande steg:
- Kontrollera om alla obligatoriska fält är synliga i användargränssnittet.
- Utför några positiva och negativa testfall och validera dataegenskaperna.
Notera: Det kan finnas många kombinationer som motsvarar dataimport och dataexport. Du måste utföra SIT för de bästa kombinationerna med tanke på den tid som är tillgänglig för dig.
Systemtestning mot systemintegrationstestning
Skillnader mellan systemtestning och SIT:
| SIT (System Integration Testing) | Systemtestning |
|---|---|
| SIT görs främst för att kontrollera hur enskilda moduler interagerar med varandra när de integreras i ett system som helhet. | Systemtestning görs främst för att kontrollera om hela systemet fungerar som förväntat med hänvisning till de angivna kraven. |
| Det utförs efter enhetstestning och kommer att göras varje gång en ny modul läggs till i systemet. | Det genomförs på den slutliga nivån, dvs efter att integreringstestet har slutförts och strax innan systemet levereras för UAT. |
| Det är en test på låg nivå. | Det är en testning på hög nivå. |
| SIT-testfall fokuserar på gränssnittet mellan systemkomponenterna. | Testfall, i detta fall, fokuserar på att simulera verkliga scenarier. |
Systemintegrationstestning mot testning av användaracceptans
Här är skillnaden mellan SIT och UAT:
| SIT (System Integration Testing) | UAT (test av användaracceptans) |
|---|---|
| Denna testning är ur perspektivet för gränssnitt mellan moduler. | Denna testning är ur användarnas krav. |
| SIT görs av utvecklare och testare. | UAT görs av kunder och slutanvändare. |
| Gjort efter enhetstestning och före systemtestning. | Detta är den sista testnivån och görs efter systemtestning. |
| I allmänhet skulle problemen i SIT vara relaterade till dataflöde, kontrollflöde etc. | Problemen i UAT skulle i allmänhet vara som de funktioner som inte fungerar enligt användarkraven. |
Bilden nedan på testnivåerna skulle göra flödet från enhetstest till UAT tydligt för dig:
SIT Exempel
Låt oss anta att ett företag använder programvara för att lagra klientinformation.
Denna programvara har två skärmar i användargränssnittet - skärm 1 och skärm 2, och den har en databas. De uppgifter som anges i skärm 1 och skärm 2 anges i databasen. Från och med nu är företaget nöjd med denna programvara.
Några år senare finner företaget dock att programvaran inte uppfyller kraven och det finns ett behov av förbättring. Därför utvecklade de en skärm 3 och en databas. Nu är detta system med skärm 3 och en databas integrerat med den äldre / befintliga programvaran.
Nu kallas testet för hela systemet efter integrationen System Integration test. Här testas samexistensen av ett nytt system med ett befintligt system för att säkerställa att hela det integrerade systemet fungerar bra.
SIT-tekniker
Huvudsakligen finns det fyra sätt att göra SIT:
- Uppifrån och ner strategi
- Nedifrån och upp-tillvägagångssätt
- Sandwich-tillvägagångssätt
- Big Bang-tillvägagångssätt
Uppifrån och ner-tillvägagångssättet och nedifrån och upp-tillvägagångssättet är ett slags stegvisa tillvägagångssätt. Låt oss börja med diskussionen med Top-down-tillvägagångssätt först.
# 1) Uppifrån och ner-tillvägagångssätt:
Under detta börjar testningen med bara den översta modulen i en applikation, dvs användargränssnittet som vi kallar som testdrivrutin.
Funktionaliteten hos de underliggande modulerna simuleras med stubbar. Toppmodulen är integrerad med modulstubben på lägre nivå en efter en och senare testas funktionaliteten.
När varje test har slutförts ersätts stubben med den riktiga modulen. Modulerna kan integreras antingen på bredd-första sätt eller djup-första sätt. Testet fortsätter tills hela applikationen är byggd.
Fördelen med detta tillvägagångssätt är att det inte finns något behov av drivrutiner och testfallet kan specificeras i termer av systemets funktionalitet.
Huvudutmaningen i denna typ av tillvägagångssätt är beroendet av tillgängligheten av modulnivåfunktioner på lägre nivå. Det kan finnas en försening i testerna tills de riktiga modulerna ersätts med stubbar. Att skriva stubbar är också svårt.
# 2) Uppifrån och upp-strategi:
Det eliminerar begränsningarna i top-down-metoden.
I den här metoden monteras först de lägsta nivåmodulerna för att bilda kluster. Dessa kluster fungerar som en underfunktion av applikationen. Sedan skapas en drivrutin för att hantera testfallets inmatning och utdata. Efter detta testas klustret.
När klustret har testats tas drivrutinen bort och klustret kombineras med nästa övre nivå. Denna process fortsätter tills hela applikationsstrukturen uppnås.
Det finns inget behov av stubbar i detta tillvägagångssätt. Det blir förenklat när behandlingen går uppåt och förarens behov minskas. Detta tillvägagångssätt är lämpligt för att göra SIT för objektorienterade system, realtidsystem och system med strikta prestandabehov.
Begränsningen av detta tillvägagångssätt är dock det viktigaste delsystemet, dvs UI testas äntligen.
# 3) Sandwichstrategi:
Här kombineras ovanstående och nedifrån och uppåt-metoderna som diskuterats ovan.
Systemet uppfattas ha tre lager - mittlagret som är mållagret, ett lager ovanför målet och ett lager under målet. Testning görs i båda riktningarna och samlas vid målskiktet som är i mitten och detta illustreras i bilden nedan.
Sandwich Testing Strategi
En fördel med detta tillvägagångssätt är att det översta lagret och det nedre lagret i systemet kan testas parallellt. Begränsningen av detta tillvägagångssätt är dock att den inte uttömmande testar de enskilda delsystemen innan integration.
För att eliminera denna begränsning har vi modifierat sandwich-test där integrering av topp-, mellan- och bottenlager testas parallellt med stubbar och drivrutiner.
# 4) Big Bang Approach:
I detta tillvägagångssätt görs integrationen när alla moduler i applikationen är helt klara. Testning görs efter integrering av alla moduler för att kontrollera om det integrerade systemet fungerar eller inte.
Det är utmanande att hitta orsaken till problemet i detta tillvägagångssätt eftersom allt integreras på en gång i motsats till inkrementell testning. Detta tillvägagångssätt antas i allmänhet när endast en SIT-runda krävs.
bästa gratis mp3 nedladdningsapp för Android
Slutsats
I den här artikeln lärde vi oss vad som är System Integration Testing (SIT) och varför är det viktigt att utföra det.
Vi förstod kärnkoncepten, teknikerna, metoderna och metoderna för att utföra SIT. Vi gick också igenom hur SIT skiljer sig från UAT och systemtestning.
Hoppas du gillade den här utmärkta artikeln !!
Rekommenderad läsning
- Vad är komponenttestning eller modultestning (lär dig med exempel)
- Vad är jämförelsetestning (lär dig med exempel)
- Vad är Integration Testing (Tutorial med Integration Testing Exempel)
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Skillnaderna mellan enhetstestning, integrationstestning och funktionstestning
- Funktionell testning mot icke-funktionell testning
- Integration av selen med JMeter
- Spock för integration och funktionstestning med selen