Vad är System Integration Testing (SIT) Exempel

Vad är systemintegrationstestning?

Systemkrav Integrationstestning definieras som en typ av mjukvarutestning som utförs i en integrerad hårdvaru- och mjukvarumiljö för att verifiera beteendet hos hela systemet. Det är tester utförda på ett komplett, integrerat system för att utvärdera systemets överensstämmelse med dess specificerade krav.

System Integration Testing (SIT) utförs för att verifiera interaktionerna mellan modulerna i ett mjukvarusystem. Den behandlar verifieringen av mjukvarukraven på hög och låg nivå som specificeras i programvarukravspecifikationen/data och mjukvarudesigndokumentet. Den verifierar också ett mjukvarusystems samexistens med andra och testar gränssnittet mellan modulerna i mjukvaruapplikationen. I denna typ av testning testas moduler först individuellt och kombineras sedan till ett system. Till exempel kombineras mjukvara och/eller hårdvarukomponenter och testas successivt tills hela systemet har integrerats.

Varför testar man systemintegration?

Inom mjukvaruteknik görs systemintegrationstestning eftersom,

Det hjälper att upptäcka defekt tidigt
Tidigare feedback om acceptansen av den enskilda modulen kommer att finnas tillgänglig
Schemaläggning av defektkorrigeringar är flexibel och kan överlappas med utveckling
Korrekt dataflöde
Rätt styrflöde
Rätt timing
Korrekt minnesanvändning
Korrekt med mjukvarukrav

Hur man gör systemintegrationstestning

Det är en systematisk teknik för att konstruera programstrukturen samtidigt som man utför tester för att upptäcka fel i samband med gränssnitt.

Alla moduler är integrerade i förväg, och hela programmet testas som en helhet. Men under denna process kommer sannolikt en uppsättning fel att uppstå.

Korrigering av sådana fel är svårt eftersom isoleringsorsaker kompliceras av den enorma expansionen av hela programmet. När dessa fel är åtgärdade och rättade kommer ett nytt att dyka upp och processen fortsätter sömlöst i en oändlig slinga. För att undvika denna situation används ett annat tillvägagångssätt, Incremental Integration. Vi kommer att se mer detaljer om ett inkrementellt tillvägagångssätt senare i handledningen.

Det finns några inkrementella metoder som att integrationstesterna utförs på ett system baserat på målprocessorn. Metodiken som används är Svart Box Testning. Antingen bottom-up eller top-down integration kan användas.

Testfall definieras endast med hjälp av mjukvarukraven på hög nivå.

Programvaruintegration kan också till stor del uppnås i värdmiljön, med enheter som är specifika för målmiljön fortsätter att simuleras i värddatorn. Upprepa tester i målmiljön för bekräftelse kommer återigen att bli nödvändigt.

Bekräftelsetest på den här nivån kommer att identifiera miljöspecifika problem, såsom fel i minnesallokering och avallokering. Det praktiska med att dirigera programvara integration i värdmiljön beror på hur mycket målspecifik funktionalitet som finns. För vissa inbyggda system kommer kopplingen till målmiljön att vara mycket stark, vilket gör det opraktiskt att genomföra programvaruintegration i värdmiljön.

Stora mjukvaruutvecklingar kommer att dela upp mjukvaruintegration i ett antal nivåer. De lägre nivåerna av mjukvaruintegration kan huvudsakligen baseras på värdmiljön, med senare nivåer av mjukvaruintegration som blir mer beroende av målmiljön.

Obs: Om bara programvara testas kallas det Software Software Integration Testing [SSIT] och om både hårdvara och mjukvara testas kallas det Hardware Software Integration Testing [HSIT].

In- och utträdeskriterier för integrationstestning

Vanligtvis används ETVX-strategin (Entry Criteria, Task, Validation och Exit Criteria) när man utför integrationstestning.

Ingångskriterier:

Slutförande av Enhetstestning

ingångar:

Programvarukrav Data
Mjukvarudesigndokument
Programverifieringsplan
Programvaruintegreringsdokument

Aktiviteter:

Skapa testfall och procedurer baserat på kraven på hög och låg nivå
Kombinera lågnivåmoduler som implementerar en gemensam funktionalitet
Utveckla en testsele
Testa bygget
När testet är godkänt kombineras konstruktionen med andra konstruktioner och testas tills systemet är integrerat som en helhet.
Utför alla tester på nytt på den målprocessorbaserade plattformen och få resultaten

Utgångskriterier:

Framgångsrikt slutförande av integrationen av mjukvarumodulen på målmaskinvaran
Korrekt prestanda för programvaran enligt de angivna kraven

Utgångarna

Integrationstestrapporter
Programvarutestfall och -procedurer [SVCP].

Integrationstestning av hårdvaruprogramvara

Integrationstestning av hårdvaruprogramvara är en process för att testa Computer Software Components (CSC) för högnivåfunktioner i målmaskinvarumiljön. Målet med hårdvaru-/mjukvaruintegreringstestning är att testa beteendet hos utvecklad mjukvara integrerad på hårdvarukomponenten.

Kravbaserad hårdvaru-mjukvaruintegreringstestning

Syftet med kravbaserad hårdvaru-/mjukvaruintegreringstestning är att säkerställa att mjukvaran i måldatorn kommer att uppfylla de höga kraven. Typiska fel som avslöjas av denna testmetod inkluderar:

Hårdvaru-/mjukvarugränssnittsfel
Brott mot programvarupartitionering.
Oförmåga att upptäcka fel genom inbyggt test
Felaktigt svar på hårdvarufel
Fel på grund av sekvensering, transienta ingångsbelastningar och ineffekttransienter
Feedback loopar felaktigt beteende
Felaktig eller felaktig kontroll av minneshanteringshårdvara
Problem med databussstrid
Felaktig funktion av mekanismen för att verifiera kompatibiliteten och korrektheten hos fältladdningsbar programvara

Hardware Software Integration handlar om verifiering av kraven på hög nivå. Alla tester på denna nivå utförs på målhårdvaran.

Black box-testning är den primära testmetoden som används på denna testnivå.
definiera testfall endast från högnivåkraven
Ett test måste utföras på produktionsstandardhårdvara (på mål)

Saker att tänka på när man designar testfall för HW/SW-integration

Korrekt inhämtning av all data av programvaran
Skalning och omfång av data som förväntat från hårdvara till mjukvara
Korrekt utmatning av data från mjukvara till hårdvara
Data inom specifikationerna (normalt intervall)
Data utanför specifikationerna (onormalt intervall)
Gränsdata
Avbryter bearbetningen
Tidpunkten
Korrekt minnesanvändning (adressering, överlappningar, etc.)
Statliga övergångar

Obs: För avbrottstestning kommer alla avbrott att verifieras oberoende av den första begäran genom fullständig service och fram till slutförandet. Testfall kommer att utformas specifikt för att adekvat testa avbrott.

Integrationstestning av programvara till programvara

Det är testning av datorprogramvaran som fungerar inom värddatorn/måldatorn

Miljö, samtidigt som man simulerar hela systemet [andra CSC:er], och på högnivåfunktionalitet.

Den fokuserar på beteendet hos en CSC i en simulerad värd/målmiljö. Tillvägagångssättet som används för programvaruintegration kan vara ett stegvis tillvägagångssätt (top-down, bottom-up eller en kombination av båda).

Inkrementell inställning

Inkrementell testning är ett sätt för integrationstestning. I den här typen av testmetod testar du först varje modul i programvaran individuellt och fortsätter sedan att testa genom att lägga till andra moduler till den sedan en annan och så vidare.

Inkrementell integration är kontrasten till big bang-metoden. Programmet är uppbyggt och testat i små segment, där fel är lättare att isolera och rätta till. Det är mer sannolikt att gränssnitt testas fullständigt, och en systematisk testmetod kan tillämpas.

Det finns två typer av inkrementell testning

Uppifrån och ner tillvägagångssätt
Bottom Up tillvägagångssätt

Uppifrån och ned-tillvägagångssätt

I den här typen av tillvägagångssätt, börja individuellt med att endast testa användargränssnittet, med den underliggande funktionaliteten simulerad av stubbar, sedan flyttar du nedåt och integrerar lägre och lägre lager som visas i bilden nedan.

Från och med huvudkontrollmodulen integreras modulerna genom att flytta nedåt genom kontrollhierarkin
Undermoduler till huvudstyrmodulen är inkorporerade i strukturen antingen på ett bredd-först-sätt eller ett djup-först-sätt.
Depth-first-integration integrerar alla moduler på en större kontrollväg i strukturen som visas i följande diagram:

Modulintegrationsprocessen görs på följande sätt:

Huvudkontrollmodulen används som testförare, och stubbarna ersätter alla moduler som är direkt underordnade huvudkontrollmodulen.
De underordnade stubbarna byts ut en i taget med faktiska moduler beroende på vald tillvägagångssätt (bredden först eller djupet först).
Tester utförs när varje modul är integrerad.
När varje uppsättning tester har slutförts ersätts en annan stubb med en riktig modul när varje uppsättning tester har slutförts
För att säkerställa att nya fel inte har införts Regressionstestning kan utföras.

Processen fortsätter från steg 2 tills hela programstrukturen är uppbyggd. Top-down-strategin låter relativt okomplicerad, men i praktiken uppstår logistiska problem.

Det vanligaste av dessa problem uppstår när bearbetning på låga nivåer i hierarkin krävs för att testa de övre nivåerna på ett adekvat sätt.

Stubbar ersätter lågnivåmoduler i början av top-down-testning och därför kan inga betydande data flöda uppåt i programstrukturen.

Utmaningar som testaren kan möta:

Fördröj många tester tills stubbar ersätts med faktiska moduler.
Utveckla stubbar som utför begränsade funktioner som simulerar själva modulen.
Integrera programvaran från botten av hierarkin och uppåt.

Obs: Det första tillvägagångssättet gör att vi förlorar en viss kontroll över korrespondensen mellan specifika tester och inkorporering av specifika moduler. Detta kan resultera i svårigheter att fastställa orsaken till fel som tenderar att bryta mot den mycket begränsade karaktären hos uppifrån-och-ned-metoden.

Det andra tillvägagångssättet är genomförbart men kan leda till betydande omkostnader, eftersom stubbar blir allt mer komplexa.

Nedifrån och upp-tillvägagångssätt

Bottom-up-integration påbörjar konstruktion och testning med moduler på den lägsta nivån i programstrukturen. I denna process integreras modulerna från botten till toppen.

I detta tillvägagångssätt är bearbetning som krävs för modulerna underordnade en given nivå alltid tillgänglig och behovet av stubbarna elimineras.

Denna integrationstestprocess utförs i en serie av fyra steg

Lågnivåmoduler kombineras till kluster som utför en specifik mjukvaruunderfunktion.
En drivrutin skrivs för att koordinera testfallsinmatning och -utgång.
Klustret eller konstruktionen testas.
Drivrutiner tas bort och kluster kombineras och rör sig uppåt i programstrukturen.

När integrationen går uppåt, behövs separata testförarlektioner. Faktum är att om de två översta nivåerna i programstrukturen integreras uppifrån och ned, kan antalet förare minskas avsevärt och integrationen av kluster förenklas avsevärt. Integration följer mönstret som illustreras nedan. När integrationen går uppåt, behövs separata testförarlektioner.

Obs: Om de två översta nivåerna i programstrukturen är integrerade Top-down, kan antalet drivrutiner minskas avsevärt och integrationen av builds förenklas avsevärt.

Big Bang Approach

I detta tillvägagångssätt integreras inte alla moduler förrän och om inte alla moduler är klara. När de är klara integreras alla moduler och exekveras sedan för att veta om alla integrerade moduler fungerar eller inte.

I detta tillvägagångssätt är det svårt att veta grundorsaken till misslyckandet på grund av att allt integreras på en gång.

Det kommer också att finnas en stor chans att de kritiska buggarna uppstår i produktionsmiljön.

Detta tillvägagångssätt används endast när integrationstestning måste göras på en gång.

Sammanfattning

Integration utförs för att verifiera interaktionerna mellan modulerna i ett mjukvarusystem. Det hjälper till att upptäcka defekter tidigt
Integrationstestning kan göras för hårdvara-mjukvara eller hårdvara-hårdvaruintegration
Integrationstestning görs med två metoder
- Inkrementellt förhållningssätt
- Big bang tillvägagångssätt
När man utför integrationstestning används generellt ETVX-strategin (Entry Criteria, Task, Validation, and Exit Criteria).