what is incremental testing
Ved hjælp af denne artikel vil jeg dække en af de vigtige integrationsmetoder - inkrementel test.
Ved afslutningen af dette afsnit vil publikum have en rimelig viden om følgende:
- Hvad er trinvis test?
- Dens mål
- Metoder
- Fordele
- Ulemper
Hvad du lærer:
- Hvad er inkrementel test
Hvad er inkrementel test
Incremental Testing, også kendt som Incremental Integration Testing, er en af tilgangene til Integration Testing og inkorporerer de grundlæggende begreber.
Det er som en test, der kombinerer modul og integration teststrategi .
I denne test tester vi hvert modul individuelt i enhedstestfasen, og derefter integreres modulerne trinvist og testes for at sikre glat interface og interaktion mellem moduler.
I denne tilgang kombineres hvert modul trinvist, dvs. en efter en, indtil alle moduler eller komponenter tilføjes logisk for at fremstille den krævede anvendelse i stedet for at integrere hele systemet på én gang og derefter udføre test på slutproduktet. Integrerede moduler testes som en gruppe for at sikre en vellykket integration og dataflytning mellem modulerne.
Som i integrationstest er det primære fokus for at udføre denne test at kontrollere interface, integrerede links og informationsstrøm mellem moduler. Denne proces gentages, indtil modulerne kombineres og testes med succes.
Eksempel
Lad os forstå dette koncept med et eksempel:
System- eller softwareapplikation består af følgende moduler:
Incremental Integration testmetode
- Hvert modul, dvs. M1, M2, M3 osv., Testes individuelt som en del af enhedstest
- Moduler kombineres trinvist, dvs. en efter en og testes for vellykket interaktion
- I fig2 kombineres og testes modul M1 og modul M2
- I fig3 tilføjes og testes modul M3
- I Fig4 tilføjes modul M4, og test udføres for at sikre, at alt fungerer sammen
- Resten af modulerne tilføjes også trinvist ved hvert trin og testes for vellykket integration
Fig2
Fig3
softwareudvikling livscyklus modeller pdf
Fig4
Formål med inkrementel test
- For at sikre, at forskellige moduler fungerer sammen efter integration
- Identificer manglerne tidligere og i hver fase. Dette giver udviklere en fordel for at identificere, hvor problemet er. Som om test efter M1 og M2 er integreret er vellykket, men når M3 tilføjes, mislykkes testen; dette vil hjælpe udvikleren med at adskille problemet
- Problemer kan løses i en tidlig fase uden meget omarbejdning og til mindre omkostninger
Incremental Integration Testing Methodologies
Før vi begynder med dette emne, vil jeg gerne give en kort introduktion om Stubbe og drivere da vi ofte bruger disse udtryk.
Stubs og drivere er pseudokode eller dummy-kode, der bruges i Integration eller komponenttest når et eller flere moduler ikke er udviklet, men det er nødvendigt at teste et andet modul.
Stubbe bruges i Top-down testmetode og er kendt som “kaldte programmer”. Stubs hjælper med at simulere grænsefladen mellem moduler med lavere håndtag, som ikke er tilgængelige eller udviklet.
Chauffører bruges i bottom-up-testmetoden og er kendt som 'opkaldsprogrammer'. Drivere hjælper med at simulere grænsefladen mellem topmoduler, som ikke er udviklet eller tilgængelige.
Et spørgsmål, der kan forekomme hos nogle af os, er, hvorfor ikke vente, indtil alle applikationsmodulerne er udviklet i stedet for at bruge stub / driver, før du begynder at teste?
Det enkle svar er, at det øger projektets gennemførelsestid, da testere sidder inaktive, indtil alle modulerne er udviklet. Dette gør også rodanalysen af defekten vanskelig. Denne type testtilgang er kendt som Big-Bang Integration-test.
Nu hvor vi har dækket Stubs og drivere, lad os gå videre til forskellige metoder til trinvis test:
# 1) Top ned
Som navnet antyder, finder test sted fra top til bund, dvs. fra det centrale modul til undermodul. Moduler, der indrammer det øverste applikationslag, testes først.
Denne tilgang følger den strukturelle strøm af applikationen under test. Ikke-tilgængelige eller ikke udviklede moduler eller komponenter erstattes af stubbe.
Lad os forstå dette med et eksempel:
- Modul : Login til webstedet aka L
- Modul : Bestil aka O
- Oversigt over modulordre aka OS (endnu ikke udviklet)
- Modul : Betaling aka P
- Modul kontant betaling aka CP
- Modulbetaling / kreditbetaling aka DP (endnu ikke udviklet)
- Module Wallet Payment aka WP (endnu ikke udviklet)
- Modul: Rapportering aka R (endnu ikke udviklet)
Top-down Incremental Integration Testing Approach
Følgende testsager udledes:
Spil wow gratis privat server
Test sag 1: Modul L og Modul O integreres og testes
Test Case2: Modul L, O og P vil blive integreret og testet
Test Case3: Modul L, O, P og R vil blive integreret og testet.
Og så afledes andre testsager.
Denne type test, hvor alle moduler i et lag først integreres og testes, kaldes 'bredde-først'. En anden kategori er 'dybde-først'.
Følgende testsager udledes for 'dybde-først':
Test sag 1: Modul L og Modul O integreres og testes
Test Case2: Modul L, O og OS vil blive integreret og testet
Test Case3: Modul L, O, OS, P integreres og testes
Test sag 4: Modul L, O, OS, P, CP integreres og testes
Og så afledes andre testsager.
Fordele ved top-down-metode
- Tidlig eksponering af arkitekturdefekter
- Det skitserer arbejdet med en applikation som helhed i tidlige stadier og hjælper med tidlig afsløring af designfejl
- Hovedkontrolpunkter testes tidligt
De-merits af top-down-metodologi
- Væsentlige moduler testes sent i cyklus
- Det er meget udfordrende at skrive testbetingelser
- En stub er ikke en perfekt implementering af relateret modul. Det simulerer bare datastrømmen mellem to moduler
# 2) Bottom-up
I denne tilgang finder test sted fra bund til top, dvs. moduler i nederste lag er integreret og testet først, og derefter sekventielt integreres andre moduler, når vi bevæger os op. Ikke-tilgængelige eller ikke udviklede moduler erstattes af drivere.
Lad os se på et nedenstående eksempel for bedre forståelse:
Modulerangering, mærker, procentdel og sportsgrad er endnu ikke udviklet, så de vil blive erstattet med relateret driver:
Bottom up Incremental Integration test tilgang
Følgende testsager udledes:
Test sag 1: Enhedstest af modulet Praktisk og teori
Test Case2: Integration og test af moduler Marks-Praktisk-teori
Test sag3 : Integration og test af moduler Procent-mærker-praktisk-teori
Test sag 4: Enhedstest af modulets sportsgrad
Test sag 5: Integration og test af moduler Rank-Sports Grade-Procent-Marks-Practical-Theory
Fordele ved bund-op-metodologi
- Denne metode er meget nyttig til applikationer, hvor der bruges bottom-up designmodel
- Det er nemmere at oprette testbetingelser i bottom up-tilgang
- At starte test på det nederste niveau af hierarki betyder at teste kritiske moduler eller funktionalitet på et tidligt tidspunkt. Dette hjælper med tidlig opdagelse af fejl
- Interfacefejl opdages på et tidligt tidspunkt
De-merits af bund-op-metodologi
- Drivere er sværere at skrive end stub
- Designfejl fanges i det senere stadium
- I denne tilgang har vi ikke en fungerende applikation, før det sidste modul er bygget
- Driver er ikke en komplet implementering af relateret modul. Det simulerer bare datastrømmen mellem to moduler.
# 3) Sandwichtest
Denne tilgang er en hybrid af top-down og bottom-up metode. Stub og drivere bruges til ufuldstændige eller ikke udviklede moduler.
Testmetode
- Der identificeres et mellemlag, hvorfra der foretages test nedenfra og op. Dette midterlag er også kendt som mållag
- Mållaget identificeres i henhold til heuristisk tilgang, dvs. vælg et lag, der tillader minimal brug af stubbe og drivere
- Top-down test starter fra mellemlag og bevæger sig nedad mod moduler på lavere niveau. Dette lag under det midterste lag er kendt som bundlaget
- Bottom-up-test starter også fra mellemlag og bevæger sig op mod moduler i øverste lag. Dette lag over det midterste lag er kendt som det øverste lag
- Ved brug af stubs og drivere testes brugergrænsefladen og funktionerne på moduler på lavere niveau henholdsvis
- I sidste ende er der kun mellemlag tilbage til udførelse af den sidste test
Eksempel:
Følgende testsager kan udledes med Sandwich Testing Strategy:
Test sag 1: Test A, X, Y og Z individuelt - hvor Test A kommer under Toplagstest og Test X, Y og Z kommer under Bundlagstest
Test Case2: Test A, G, H og I
Test Case3: Test G, X og Y
Test sag 4: Testhånd Z
Test sag 5: Test A, G, H, I, X, Y og Z
Fordele ved Sandwich Testing Methodology
- Det er meget gavnligt for et stort projekt, der har forskellige delprojekter
- Top-down og bottom-up testmetode kan køre side om side
De-meritter af Sandwich Testing Methodology
- Før modulforening testes undersystemer og deres grænseflader ikke grundigt
- Højere omkostninger på grund af involvering af både top-down og bottom-up testmetode
- Denne type test anbefales ikke til et system, hvor moduler er meget indbyrdes afhængige
Konklusion
Incremental Testing kommer under tæppet til integrationstest. I denne testmetode udføres integrationstestning på det enkelte modul som en del af enhedstest, og i næste fase integreres moduler eller komponenter i applikationen trinvist, og test udføres på kombinerede moduler som en gruppe.
Ud af tre metoder til Incremental Integration Testing afhænger valget af hvilken metode, der skal vælges, af applikationens struktur og også af placeringen af højrisikomoduler.
Alle tre metoder til trinvis test hører under vandret kategori på grund af følgende adfærdsmæssige aspekter:
- Alle tre metoder fokuserer på lagtest
- Alle overvejer et strukturelt eller hierarkisk design
- Alle integrerer lag trinvist
Fordele:
Med denne testtilgang er det lettere at identificere fejl tidligt, og det hjælper også udvikleren med at bestemme årsagen til problemet. Da den bruger det grundlæggende i struktureret test, er denne testmetode meget effektiv og nøjagtig.
Ulemper:
Denne type testtilgang er tidskrævende på grund af brug af stubbe og drivere. Det er også gentaget.
Omkring forfatter: Denne nyttige tutorial er skrevet af Neha B. Hun er ISTQB-certificeret Lead Quality Analyst med mere end 8 års erfaring.
Fortæl os, hvis du har spørgsmål / forslag.
Anbefalet læsning
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Hvad er komponenttest eller modultest (lær med eksempler)
- Test af Primer eBook Download
- Funktionel testning mod ikke-funktionel testning
- Hvad er udholdenhedstest i softwaretest (eksempler)
- Parvis test eller test af selvstudier med værktøjer og eksempler
- Typer af softwaretest: Forskellige testtyper med detaljer
- Volume Testing Tutorial: Eksempler og Volume Testing Tools