Meny

Vad är inkrementell testning: Detaljerad förklaring med exempel

what is incremental testing

Prova Vårt Instrument För Att Eliminera Problem

Med hjälp av den här artikeln kommer jag att täcka en av de viktiga integrationsmetoderna - Incremental Testing.

I slutet av detta avsnitt kommer publiken att ha en rättvis kunskap om följande:

  • Vad är inkrementell testning?
  • Dess mål
  • Metoder
  • Fördelar
  • Nackdelar

Vad du kommer att lära dig:

Vad är inkrementell testning

Incremental Testing, även känd som Incremental Integration Testing, är en av metoderna för Integration Testing och innehåller dess grundläggande begrepp.

Det är som ett test som kombinerar modul och integration teststrategi .

Inkrementell testning

I denna testning testar vi varje modul individuellt i enhetstestfasen, och sedan integreras modulerna stegvis och testas för att säkerställa smidigt gränssnitt och interaktion mellan modulerna.

I detta tillvägagångssätt kombineras varje modul stegvis, dvs en efter en tills alla moduler eller komponenter läggs till logiskt för att göra den önskade applikationen, istället för att integrera hela systemet på en gång och sedan utföra test på slutprodukten. Integrerade moduler testas som en grupp för att säkerställa framgångsrik integration och dataflöde mellan modulerna.

Precis som vid integrationstestning är det primära fokus för att göra denna testning att kontrollera gränssnitt, integrerade länkar och informationsflöde mellan moduler. Denna process upprepas tills modulerna kombineras och testas framgångsrikt.

Exempel

Låt oss förstå detta koncept med ett exempel:

System- eller programapplikation består av följande moduler:

Mjukvaruapplikation

Incremental Integration testmetod

  • Varje modul, dvs M1, M2, M3, etc. testas individuellt som en del av enhetstestning
  • Moduler kombineras stegvis, dvs. en efter en och testas för framgångsrik interaktion
  • I Fig2 kombineras och testas modul M1 och modul M2
  • I Fig3 läggs modul M3 till och testas
  • I Fig4 läggs modul M4 till och testning görs för att se till att allt fungerar tillsammans
  • Resten av modulerna läggs också till stegvis i varje steg och testas för framgångsrik integration

Fig2

Kombinerade två moduler

Fig3

Kombinerade 3 moduler

bästa gratis hårddiskkloningsprogramvara 2017

Fig4

Kombinerade fyra moduler

Syftet med inkrementellt test

  • För att säkerställa att olika moduler fungerar framgångsrikt efter integrationen
  • Identifiera bristerna tidigare och i varje fas. Detta ger utvecklare en fördel för att identifiera var problemet är. Som om testning efter M1 och M2 är integrerad lyckas men när M3 läggs till misslyckas testet; detta hjälper utvecklaren att separera problemet
  • Frågor kan åtgärdas i tidig fas utan mycket omarbetning och till lägre kostnad

Incremental Integration Testing Methodologies

Innan vi börjar med detta ämne vill jag ge en kort introduktion om Stubbar och förare eftersom vi ofta använder dessa termer.

Stubbar och drivrutiner är pseudokod eller dummy-kod som används i Integration eller komponenttestning när en eller flera moduler inte utvecklas men krävs för att testa någon annan modul.

Stubbar används i Top-down-testmetoden och kallas 'kallade program'. Stubbar hjälper till att simulera gränssnittet mellan lägre spakmoduler som inte är tillgängliga eller utvecklade.

Förare används i testmetoden från botten upp och kallas ”anropsprogram”. Drivrutiner hjälper till att simulera gränssnittet mellan toppmoduler som inte är utvecklade eller tillgängliga.

En fråga som kan förekomma hos vissa av oss är varför inte vänta tills alla applikationsmoduler är utvecklade istället för att använda stub / drivrutin innan testningen påbörjas?

Det enkla svaret är att det ökar genomförandetiden för projektet eftersom testare kommer att sitta tomgång tills alla moduler har utvecklats. Detta gör också rotanalysen av defekter svår. Denna typ av testmetod kallas Big-Bang Integration-testning.

Nu när vi har täckt stubbar och drivrutiner, går vi vidare till olika metoder för inkrementell testning:

# 1) Uppifrån och ner

Som namnet antyder sker testning från topp till botten, dvs. från den centrala modulen till undermodulen. Moduler som inramar det översta applikationsskiktet testas först.

Detta tillvägagångssätt följer det strukturella flödet av applikationen som testas. Otillgängliga eller ej utvecklade moduler eller komponenter ersätts av stubbar.

Låt oss förstå detta med ett exempel:

  • Modul : Webbplatsinloggning aka L
  • Modul : Beställ aka O
    • Sammanfattning av modulorder aka OS (Ännu inte utvecklat)
  • Modul : Betalning aka P
    • Modul kontant betalning aka CP
    • Modulbetaling / kreditbetalning aka DP (ännu inte utvecklad)
    • Module Wallet Payment aka WP (Ännu inte utvecklad)
  • Modul: Rapportering aka R (Ännu inte utvecklad)

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

Uppifrån och ner Incremental Integration Testing Approach

Följande testfall kommer att härledas:

c ++ slumptal mellan 1 och 3

Testfall 1: Modul L och Modul O kommer att integreras och testas
Testfall 2: Modul L, O och P kommer att integreras och testas
Testfall 3: Modul L, O, P och R kommer att integreras och testas.

Och så vidare härleds andra testfall.

Denna typ av testning där alla moduler i ett lager först integreras och testas kallas 'bredd först'. En annan kategori är 'djup-först'.

Följande testfall kommer att härledas för 'djup-först':

Testfall 1: Modul L och Modul O kommer att integreras och testas
Testfall 2: Modul L, O och OS kommer att integreras och testas
Testfall 3: Modul L, O, OS, P kommer att integreras och testas
Testfall 4: Modul L, O, OS, P, CP kommer att integreras och testas

Och så vidare härleds andra testfall.

Fördelar med Top-down Methodology

  • Tidig exponering av arkitekturdefekter
  • Den beskriver hur en applikation fungerar som helhet i tidiga skeden och hjälper till att tidigt avslöja designfel
  • De viktigaste kontrollpunkterna testas tidigt

De-Merits of Top-down Methodology

  • Betydande moduler testas sent i cykeln
  • Det är mycket utmanande att skriva testvillkor
  • En stub är inte en perfekt implementering av relaterad modul. Det simulerar bara dataflödet mellan två moduler

# 2) Uppifrån och upp

I det här tillvägagångssättet sker testning från botten till toppen, dvs. moduler i bottenlagret integreras och testas först och sedan integreras andra moduler när vi rör oss uppåt. Otillgängliga eller ej utvecklade moduler ersätts av drivrutiner.

Låt oss titta på nedanstående exempel för bättre förståelse:

Moduler Rank, Marks, Procent och Sports Grade är ännu inte utvecklade så de kommer att ersättas med relaterad Driver:

Bottom Up Approach

Uppifrån och upp Incremental Integration testmetod

Följande testfall kommer att härledas:

Testfall 1: Enhetstestning av modul Praktik och teori
Testfall 2: Integration och testning av Modules Marks-Practical-theory
Testfall3 : Integration och testning av moduler Procent-Marks-Practical-Theory
Testfall 4: Enhetstestning av Module Sports Grade
Testfall 5: Integrering och testning av moduler Rank-Sports Grade-Procentage Marks-Practical-Theory

Fördelar med metoderna från botten upp

  • Denna metod är mycket användbar för applikationer där design uppifrån och upp används
  • Det är lättare att skapa testförhållanden i bottom-up-inställning
  • Att börja testa på den nedre nivån av hierarkin innebär att testa kritiska moduler eller funktionalitet i ett tidigt skede. Detta hjälper till vid tidig upptäckt av fel
  • Gränssnittsfel upptäcks i ett tidigt skede

De-merits av Bottom-up Methodology

  • Förare är svårare att skriva än stub
  • Designfel fastnar i det senare skedet
  • I detta tillvägagångssätt har vi inte en fungerande applikation förrän den sista modulen byggs
  • Driver är inte en fullständig implementering av relaterad modul. Det simulerar bara dataflödet mellan två moduler.

# 3) Sandwich Testing

Detta tillvägagångssätt är en hybrid av top-down och bottom-up metodik. Stub och drivrutiner används för ofullständiga eller ej utvecklade moduler.

Testmetod

  • Ett mellanlager identifieras från vilket testas från undersidan upp och ner. Detta mellanskikt kallas också målskikt
  • Målskiktet identifieras enligt Heuristic-metoden, dvs. välj ett lager som tillåter minimal användning av Stubbar och drivrutiner
  • Testning uppifrån och ned börjar från mittlagret och rör sig nedåt mot lägre nivåmoduler. Detta lager under mellanskiktet kallas bottenlager
  • Testning från botten upp börjar också från mittlagret och rör sig uppåt mot topplagermoduler. Detta lager ovanför mellanskiktet är känt som topplager
  • Med hjälp av stubbar och drivrutiner testas användargränssnitt och funktioner för lägre nivåmoduler
  • I slutändan är det bara mellanskiktet kvar för genomförandet av det slutliga testet

Exempel:

Sandwich Testing Exempel

Följande testfall kan härledas med Sandwich Testing Strategy:

Testfall 1: Test A, X, Y och Z individuellt - där Test A faller under Test av toppskikt och Test X, Y och Z under test av bottenlager
Testfall 2: Test A, G, H och I
Testfall 3: Testa G, X och Y
Testfall 4: Testhand Z
Testfall 5: Testa A, G, H, I, X, Y och Z

Fördelar med Sandwich Testing Methodology

  • Det är mycket fördelaktigt för ett stort projekt som har olika delprojekt
  • Testmetoder uppifrån och ned och uppifrån och upp kan köras sida vid sida

Nackdelar med Sandwich Testing Methodology

  • Innan modulföreningen testas undersystem och deras gränssnitt inte noggrant
  • Högre kostnad på grund av involvering av både top-down och bottom-up testmetodik
  • Denna typ av test rekommenderas inte för ett system där moduler är mycket beroende av varandra

Slutsats

Incremental Testing kommer under filten för Integration-testning. I detta testmetod görs integreringstestning på den enskilda modulen som en del av enhetstestning och i nästa fas integreras moduler eller komponenter i applikationen stegvis och testas på kombinerade moduler som en grupp.

Av tre metoder för Incremental Integration Testing, valet av vilken metod som ska väljas beror på applikationens struktur och även på placeringen av högriskmoduler.

Alla tre metoderna för inkrementell testning faller under Horisontell kategori på grund av följande beteendemässiga aspekter:

  • Alla tre metoderna fokuserar på lagertestning
  • Alla överväger en strukturell eller hierarkisk design
  • Alla integrerar lager stegvis

Meriter:

Med denna testmetod är det lättare att identifiera fel tidigt, och det hjälper också utvecklaren att avgöra orsaken till problemet. Eftersom den använder grunderna för strukturerad testning är denna testmetod mycket effektiv och korrekt.

Nackdelar:

Denna typ av testmetod är tidskrävande på grund av användning av stubbar och drivrutiner. Det är också repetitivt.

Om författare: Denna hjälpsamma handledning är skriven av Neha B. Hon är ISTQB-certifierad Lead Quality Analyst med 8+ års erfarenhet.

Låt oss veta om du har några frågor / förslag.

Rekommenderad läsning

^