what is incremental testing
Ved hjelp av denne artikkelen skal jeg dekke en av de viktige integrasjonsmetodene - inkrementell testing.
Mot slutten av denne delen vil publikum ha god kunnskap om følgende:
- Hva er inkrementell testing?
- Dens mål
- Metoder
- Fordeler
- Ulemper
Hva du vil lære:
- Hva er trinnvis testing
Hva er trinnvis testing
Incremental Testing, også kjent som Incremental Integration Testing, er en av tilnærmingene til Integration Testing og inkorporerer de grunnleggende konseptene.
Det er som en test som kombinerer modul og integrasjon teststrategi .
I denne testingen tester vi hver modul individuelt i enhetstestfasen, og deretter integreres modulene trinnvis og testes for å sikre jevnt grensesnitt og interaksjon mellom modulene.
I denne tilnærmingen kombineres hver modul trinnvis, dvs. en etter en til alle moduler eller komponenter blir lagt til logisk for å lage den nødvendige applikasjonen, i stedet for å integrere hele systemet på en gang og deretter utføre testing på sluttproduktet. Integrerte moduler testes som en gruppe for å sikre vellykket integrering og dataflyt mellom modulene.
Som i integrasjonstesting, er det primære fokuset for å gjøre denne testingen å sjekke grensesnitt, integrerte lenker og informasjonsflyt mellom modulene. Denne prosessen gjentas til modulene er kombinert og testet.
Eksempel
La oss forstå dette konseptet med et eksempel:
System- eller programvareapplikasjon består av følgende moduler:
Inkrementell integrasjonstesttilnærming
- Hver modul, dvs. M1, M2, M3, etc. testes individuelt som en del av enhetstesting
- Moduler kombineres trinnvis, dvs. en etter en og testes for vellykket interaksjon
- I Fig2 kombineres og testes modul M1 og modul M2
- I Fig3 blir modul M3 lagt til og testet
- I Fig4 er modul M4 lagt til og testing blir gjort for å sikre at alt fungerer sammen
- Resten av modulene blir også lagt til trinnvis ved hvert trinn og testet for vellykket integrering
Fig2
Fig3
swf-filen åpnes ikke i krom
Fig4
Målet med inkrementell test
- For å sikre at forskjellige moduler fungerer sammen etter integrering
- Identifiser feilene tidligere og i hver fase. Dette gir utviklere en fordel for å identifisere hvor problemet er. Som om testing etter M1 og M2 er integrert er vellykket, men når M3 er lagt til, mislykkes testen; Dette vil hjelpe utvikleren med å adskille problemet
- Problemer kan løses i tidlig fase uten mye omarbeid og til mindre kostnad
Inkrementell integrasjonstestmetodikk
Før vi begynner med dette emnet, vil jeg gjerne gi en kort introduksjon om Stubber og drivere siden vi ofte bruker disse begrepene.
Stubber og drivere er pseudokode eller dummy-kode som brukes i integrasjon eller komponenttesting når en eller flere moduler ikke er utviklet, men som kreves for å teste en annen modul.
Stubber brukes i Top-down testtilnærming og er kjent som “kalt programmer”. Stubber hjelper til med å simulere grensesnittet mellom nedre spakmoduler som ikke er tilgjengelige eller utviklet.
Drivere brukes i Bottom-up-testtilnærming og er kjent som “ringe programmer”. Drivere hjelper med å simulere grensesnittet mellom toppnivåmoduler som ikke er utviklet eller tilgjengelig.
Et spørsmål som kan oppstå for noen av oss er hvorfor ikke vente til alle applikasjonsmodulene er utviklet i stedet for å bruke stub / driver før du begynner å teste?
Det enkle svaret er at det øker prosjektgjennomføringstid siden testere vil sitte inaktiv til alle modulene er utviklet. Dette gjør også rotanalysen av feil vanskelig. Denne typen testtilnærminger er kjent som Big-Bang Integration testing.
Nå som vi har dekket stubber og drivere, la oss gå videre til forskjellige metoder for inkrementell testing:
# 1) Top Down
Som navnet antyder, foregår testing fra topp til bunn, dvs. fra den sentrale modulen til undermodulen. Moduler som rammer inn det øverste laget av applikasjonen blir testet først.
Denne tilnærmingen følger den strukturelle strømmen av applikasjonen som testes. Utilgjengelige eller ikke utviklede moduler eller komponenter erstattes av stubber.
La oss forstå dette med et eksempel:
- Modul : Nettstedsinnlogging aka L
- Modul : Bestill aka O
- Sammendrag av modulordre aka OS (Foreløpig ikke utviklet)
- Modul : Betaling aka P
- Modul kontant betaling aka CP
- Modul debet / kreditt betaling aka DP (ennå ikke utviklet)
- Modul Wallet Payment aka WP (Foreløpig ikke utviklet)
- Modul: Rapportering aka R (Foreløpig ikke utviklet)
Top Up Down Incremental Integration Testing Approach
Følgende testsaker vil bli avledet:
hvordan ser en wep-tast ut
Test Case1: Modul L og Modul O vil bli integrert og testet
Test Case2: Modul L, O og P vil bli integrert og testet
Test Case3: Modul L, O, P og R vil bli integrert og testet.
Og så kommer andre testsaker ut.
Denne typen tester der alle moduler i et lag først er integrert og testet er kjent som 'bredde-først'. En annen kategori er “dybde-først”.
Følgende testsaker vil bli avledet for 'dybde-først':
Test Case1: Modul L og Modul O vil bli integrert og testet
Test Case2: Modul L, O og OS vil bli integrert og testet
Test Case3: Modul L, O, OS, P vil bli integrert og testet
Test Case4: Modul L, O, OS, P, CP vil bli integrert og testet
Og så kommer andre testsaker ut.
Fordeler med Top-down Methodology
- Tidlig eksponering av arkitektoniske mangler
- Den skisserer bruken av en applikasjon som en helhet i tidlige stadier og hjelper i tidlig avsløring av designfeil
- Hovedkontrollpunkter testes tidlig
De-meritter av Top-down Methodology
- Viktige moduler blir testet sent i syklusen
- Det er veldig utfordrende å skrive testforhold
- En stub er ikke en perfekt implementering av relatert modul. Det simulerer bare dataflyten mellom to moduler
# 2) Bottom-up
I denne tilnærmingen foregår testing fra bunn til topp, dvs. moduler nederst blir integrert og testet først, og deretter integreres andre moduler etter hvert som vi beveger oss oppover. Utilgjengelige eller ikke utviklede moduler erstattes av drivere.
La oss se på et eksempel nedenfor for bedre forståelse:
Modulerangering, merker, prosentandel og sportsgrad er ennå ikke utviklet, så de vil bli erstattet med tilhørende driver:
Bottom up Incremental Integration testing approach
Følgende testsaker vil bli avledet:
Test Case1: Enhetstesting av modul Praktisk og teori
Test Case2: Integrering og testing av Modules Marks-Practical-theory
Test tilfelle3 : Integrering og testing av moduler Prosent-merker-praktisk-teori
Test Case4: Enhetstesting av Module Sports Grade
Test Case5: Integrering og testing av moduler Rank-Sports Grade-Procent-Marks-Practical-Theory
Fordeler med Bottom-up Methodology
- Denne metoden er veldig nyttig for applikasjoner der bunn og opp designmodell brukes
- Det er lettere å lage testforhold i nedenfra og opp tilnærming
- Å begynne å teste på det nederste nivået av hierarki betyr å teste kritiske moduler eller funksjonalitet på et tidlig stadium. Dette hjelper deg med å oppdage feil tidlig
- Grensesnittfeil oppdages på et tidlig stadium
Nedsatte fordeler av Bottom-up Methodology
- Drivere er vanskeligere å skrive enn stubbe
- Designfeil blir fanget i det senere stadiet
- I denne tilnærmingen har vi ikke fungerende applikasjon før den siste modulen er bygget
- Driver er ikke en fullstendig implementering av relatert modul. Det simulerer bare dataflyten mellom to moduler.
# 3) Sandwich Testing
Denne tilnærmingen er en hybrid av top-down og bottom-up metodikk. Stub og drivere brukes til ufullstendige eller ikke utviklede moduler.
Testing Approach
- Det identifiseres et mellomlag som testes nedenfra og opp og ned. Dette mellomlaget er også kjent som mållag
- Mållaget er identifisert i henhold til heuristisk tilnærming, dvs. velg et lag som tillater minimal bruk av stubber og drivere
- Testing ovenfra og ned starter fra mellomlag og beveger seg nedover mot moduler på lavere nivå. Dette laget under mellomlaget er kjent som Bunnlag
- Bottom-up testing starter også fra mellomlag og beveger seg opp mot topplagsmoduler. Dette laget over mellomlaget er kjent som topplaget
- Ved bruk av stubber og drivere testes brukergrensesnittet og funksjonene til moduler på lavere nivå henholdsvis
- Til slutt er det bare mellomlaget som er igjen for gjennomføring av den siste testen
Eksempel:
Følgende testsaker kan utledes med Sandwich Testing Strategy:
Test Case1: Test A, X, Y og Z hver for seg - der Test A kommer under Topplagstest og Test X, Y og Z kommer under Bunnlagstester
Test Case2: Test A, G, H og I
Test Case3: Test G, X og Y
Test Case4: Testhånd Z
Test Case5: Test A, G, H, I, X, Y og Z
Meritter av Sandwich Testing Methodology
- Det er veldig gunstig for et stort prosjekt som har forskjellige delprosjekter
- Testmetodikk ovenfra og ned og ned kan løpe side om side
De-meritter av Sandwich Testing Methodology
- Før modulforening blir ikke undersystemer og deres grensesnitt testet grundig
- Høyere kostnader på grunn av involvering av både top-down og bottom-up testmetodikk
- Denne typen testing anbefales ikke for et system der modulene er svært avhengige av hverandre
Konklusjon
Inkrementell testing kommer under teppet for integrasjonstesting. I denne tilnærmingen med testing blir integrasjonstesting gjort på den enkelte modulen som en del av enhetstesting, og i neste fase integreres moduler eller komponenter i applikasjonen trinnvis, og testing utføres på kombinerte moduler som en gruppe.
Av tre metoder for inkrementell integrasjonstest, avhenger valget av hvilken metode du skal velge, av applikasjonens struktur og også av plasseringen av høyrisikomoduler.
Alle tre metodene for trinnvis testing kommer inn under Horisontal kategori på grunn av følgende atferdsmessige aspekter:
- Alle tre metodene fokuserer på lagtesting
- Alle vurderer en strukturell eller hierarkisk design
- Alle av dem integrerer lag trinnvis
Meritter:
Med denne testtilnærmingen er det lettere å identifisere feil tidlig, og det hjelper også utvikleren med å finne årsaken til problemet. Siden den bruker det grunnleggende om strukturert testing, er denne testtilnærmingen veldig effektiv og nøyaktig.
Ulemper:
Denne typen testtilnærminger er tidkrevende på grunn av bruk av stubber og drivere. Det er også repeterende.
Om forfatter: Denne nyttige opplæringen er skrevet av Neha B. Hun er ISTQB-sertifisert Lead Quality Analyst med 8+ års erfaring.
Gi oss beskjed hvis du har spørsmål / forslag.
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Hva er komponenttesting eller modultesting (Lær med eksempler)
- Testing Primer eBook Download
- Funksjonstesting mot ikke-funksjonell testing
- Hva er utholdenhetstesting i programvaretesting (eksempler)
- Pairwise Testing eller All-Pair Testing Tutorial med verktøy og eksempler
- Typer programvaretesting: Ulike testtyper med detaljer
- Volumtestopplæring: Eksempler og volumtestverktøy