Vad är systemintegrationstestning?
Systemintegrationstestning definieras som en typ av programvarutestning som utförs i en integrerad maskin- och programvarumiljö för att verifiera hela systemets beteende. Det testas 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 handlar om verifiering av de höga och låga programvarukraven som anges i specifikationen / data för programvarukrav och programvarudesigndokumentet.
Det verifierar också ett mjukvarusystems samexistens med andra och testar gränssnittet mellan modulerna i programvaran. I denna typ av testning testas modulerna först individuellt och kombineras sedan för att skapa ett system.
Till exempel kombineras programvara och / eller hårdvarukomponenter och testas successivt tills hela systemet har integrerats.
I den här handledningen lär du dig-
- Vad är systemintegrationstestning?
- Varför testa systemintegration
- Hur man gör systemintegrationstestning
- Inträdes- och utgångskriterier för integrationstestning
- Testning av integrering av maskinvara till programvara
- Testning av integrering av programvara till programvara
- Uppifrån och ner strategi
- Bottom-up-tillvägagångssätt
- Big Bang-tillvägagångssätt
Varför testa systemintegration
Inom mjukvaruteknik görs systemintegrationstester för att
- Det hjälper till att upptäcka Defect tidigt
- Tidigare feedback om acceptansen för den enskilda modulen kommer att finnas tillgänglig
- Schemaläggning av felkorrigeringar är flexibel och kan överlappas med utveckling
- Rätt dataflöde
- Rätt kontrollflöde
- Korrekt timing
- Rätt minnesanvändning
- Korrigera med programvarukrav
Hur man gör systemintegrationstestning
Det är en systematisk teknik för att konstruera programstrukturen medan du utför tester för att avslöja 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 troligen en uppsättning fel att stöta på.
Korrigering av sådana fel är svårt eftersom isoleringsorsaker kompliceras av den stora expansionen av hela programmet. När dessa fel har rättats till och korrigerats kommer en ny att visas och processen fortsätter sömlöst i en oändlig slinga . För att undvika denna situation används en annan metod, Incremental Integration. Vi kommer att se mer detaljer om ett stegvis tillvägagångssätt senare i handledningen.
Det finns några stegvisa metoder som integrationstesterna utförs på ett system baserat på målprocessorn. Metoden som används är Black Box Testing. Antingen nedifrån och upp eller integrering kan användas.
Testfall definieras endast med hjälp av mjukvarukraven på hög nivå.
Mjukvaruintegration kan också uppnås till stor del i värdmiljön, med enheter som är specifika för målmiljön fortsätter att simuleras i värden. Upprepade tester i målmiljön för bekräftelse kommer igen att vara nödvändiga.
Bekräftelsestester på denna nivå kommer att identifiera miljöspecifika problem, till exempel fel i minnesallokering och avallokering. Det praktiska med att genomföra programvaruintegration i värdmiljön beror på hur mycket målspecifik funktionalitet som finns. För vissa inbäddade system kommer kopplingen med målmiljön att vara mycket stark, vilket gör det opraktiskt att genomföra programvaruintegration i värdmiljön.
Stor mjukvaruutveckling kommer att dela upp programvaruintegration i ett antal nivåer. De lägre nivåerna av mjukvaruintegration kan huvudsakligen baseras i värdmiljön, med senare nivåer av mjukvaruintegration blir mer beroende av målmiljön.
Obs! Om endast programvara testas kallas det Software Software Integration Testing [SSIT] och om både hårdvara och programvara testas kallas det Hardware Software Integration Testing [HSIT].
Inträdes- och utgångskriterier för integrationstestning
Normalt används ETVX (Entry Criteria, Task, Validation, and Exit Criteria) -strategi när du utför Integration Testing.
Inträdeskriterier:
- Slutförande av enhetstestning
Ingångar:
- Programvarukrav Data
- Dokument för programvarudesign
- Program för verifieringsprogram
- Program för integrering av programvara
Aktiviteter:
- Baserat på kraven på hög och låg nivå skapar testfall och procedurer
- Kombinera moduler med låg nivå som implementerar en gemensam funktionalitet
- Utveckla en testkabel
- Testa byggnaden
- När testet väl är godkänt kombineras build med andra builds och testas tills systemet integreras som en helhet.
- Kör igen alla tester på målprocessorbaserad plattform och få resultaten
Utgångskriterier:
- Framgångsrik slutförande av integrationen av programvarumodulen på målhårdvaran
- Korrekt prestanda för programvaran enligt de angivna kraven
Utgångar
- Integrationstestrapporter
- Fall och procedurer för programvarutest [SVCP].
Integrering av hårdvaruprogramvara
Integration av hårdvaruprogramvara är en process för att testa datorprogramvarukomponenter (CSC) för högnivåfunktioner i målhårdvarumiljön. Målet med hårdvaru- / programvaruintegrationstestning är att testa beteendet hos utvecklad mjukvara integrerad på hårdvarukomponenten.
Kravbaserad testning av integrering av hårdvara och programvara
Målet med kravbaserad hårdvaru- / programvaruintegrationstestning är att se till att mjukvaran i måldatorn uppfyller kraven på hög nivå. Typiska fel som avslöjas med denna testmetod inkluderar:
- Fel på hårdvara / mjukvara
- Brott mot partitionering av programvara.
- Oförmåga att upptäcka fel genom inbyggt test
- Felaktigt svar på maskinvarufel
- Fel på grund av sekvensering, övergående ingångsbelastningar och ingångseffekter
- Feedback slingor felaktigt beteende
- Felaktig eller felaktig kontroll av minneshanteringshårdvaran
- Problem med databussstridighet
- Felaktig användning av mekanismen för att verifiera kompatibilitet och korrekthet med programvara som kan laddas i fält
Integration av hårdvaruprogramvara handlar om verifiering av högnivåkraven. Alla tester på denna nivå utförs på målhårdvaran.
- Black box-testning är den primära testmetoden som används vid denna testnivå.
- Definiera endast testfall från högnivåkraven
- Ett test måste utföras på produktionsstandardhårdvara (på målet)
Saker att tänka på när man utformar testfall för HW / SW-integration
- Rätt förvärv av all data av programvaran
- Skalning och utbud av data som förväntat från hårdvara till programvara
- Rätt utdata från programvara till hårdvara
- Data inom specifikationer (normalt intervall)
- Data utanför specifikationerna (onormalt intervall)
- Gränsdata
- Avbryter behandlingen
- Tidpunkt
- Rätt minnesanvändning (adressering, överlappningar etc.)
- Statliga övergångar
Obs: För avbrottstest kommer alla avbrott att verifieras oberoende av den ursprungliga begäran genom fullständig service och efter avslutad. Testfall kommer att utformas specifikt för att på ett adekvat sätt kunna testa avbrott.
Testning av integrering av programvara till programvara
Det är testningen av datorprogramvarukomponenten som arbetar inom värddatorn
Miljö, samtidigt som man simulerar hela systemet [andra CSC: er], och på funktionaliteten på hög nivå.
Den fokuserar på beteendet hos en CSC i en simulerad värd / målmiljö. Det tillvägagångssätt som används för mjukvaruintegration kan vara en stegvis metod (uppifrån och ner, en nedifrån och upp-metod eller en kombination av båda).
Inkrementell strategi
Inkrementell testning är ett sätt att integrera testning. I den här typen av testmetod testar du först varje modul av programvaran individuellt och fortsätter sedan testningen 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 konstruerat och testat i små segment, där fel är lättare att isolera och korrigera. Gränssnitt är mer benägna att 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 ner strategi
I den här typen av tillvägagångssätt, börja individuellt med att bara testa användargränssnittet, med den underliggande funktionen simulerad av stubbar, sedan flyttar du nedåt och integrerar nedre och nedre lager som visas i bilden nedan.
- Från och med huvudstyrmodulen integreras modulerna genom att flytta nedåt genom kontrollhierarkin
- Undermoduler till huvudstyrmodulen införlivas i strukturen antingen på ett bredd-första sätt eller djup-första sätt.
- Djup-första-integrering integrerar alla moduler på en större kontrollväg för strukturen, som visas i följande diagram:
Processen för modulintegrering görs på följande sätt:
- Huvudkontrollmodulen används som testdrivrutin och stubbarna ersätter alla moduler som är direkt underordnade huvudstyrmodulen.
- De underordnade stubbarna byts ut en i taget med faktiska moduler beroende på valt tillvägagångssätt (bredd först eller djup först).
- Tester utförs när varje modul är integrerad.
- När varje testuppsättning har slutförts ersätts en ny stubbe med en riktig modul efter varje testuppsättning
- För att säkerställa att nya fel inte har införts kan regressionstest utföras.
Processen fortsätter från steg 2 tills hela programstrukturen är byggd. 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 övre nivåer på lämpligt sätt.
Stubbar ersätter lågnivåmoduler i början av testning uppifrån och ner och därför kan inga signifikanta data flöda uppåt i programstrukturen.
Utmaningar som testaren kan möta:
- Försena 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 tappar viss kontroll över korrespondensen mellan specifika tester och införlivande av specifika moduler. Detta kan leda till svårigheter att bestämma orsaken till fel som tenderar att bryta mot den mycket begränsade karaktären hos top-down-metoden.
Det andra tillvägagångssättet är praktiskt men kan leda till betydande omkostnader, eftersom stubbar blir alltmer komplexa.
Bottom-up-tillvägagångssätt
Bottom-up-integration börjar bygga och testa med moduler på lägsta nivå i programstrukturen. I denna process är modulerna integrerade från botten till toppen.
I detta tillvägagångssätt är alltid bearbetning som krävs för modulerna underordnad en viss nivå alltid tillgänglig och behovet av stubbarna elimineras.
Denna integrationstestprocess utförs i en serie med fyra steg
- Moduler på låg nivå kombineras i kluster som utför en specifik underfunktion för programvara.
- En drivrutin skrivs för att samordna testfallets inmatning och utdata.
- Klustret eller byggnaden testas.
- Drivrutiner tas bort och kluster kombineras och rör sig uppåt i programstrukturen.
När integrationen går uppåt är behovet av separata lektioner för testförare. Faktum är att om de två översta nivåerna av programstrukturen är integrerade uppifrån och ner kan antalet drivrutiner minskas avsevärt och integreringen av kluster förenklas kraftigt. Integration följer det mönster som illustreras nedan. När integrationen går uppåt är behovet av separata lektioner för testförare.
Obs! Om de två översta nivåerna av programstrukturen är integrerade Top-down kan antalet drivrutiner minskas avsevärt och integrationen av builds förenklas kraftigt.
Big Bang-tillvägagångssätt
I detta tillvägagångssätt är alla moduler inte integrerade förrän och om inte alla modulerna är klara. När de är klara är alla moduler integrerade och sedan körs de för att veta om alla integrerade moduler fungerar eller inte.
I detta tillvägagångssätt är det svårt att känna till orsaken till misslyckandet på grund av att integrera allt på en gång.
Det kommer också att finnas en stor chans att kritiska buggar förekommer i produktionsmiljön.
Detta tillvägagångssätt används endast när integrationstester 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årdvaruprogramvara eller hårdvaruintegration
- Integrationstestning görs med två metoder
- Inkrementell strategi
- Big bang-tillvägagångssätt
- När Integration Testing utförs används vanligtvis ETVX (Entry Criteria, Task, Validation, and Exit Criteria) strategi.