Meny

Hva er komponenttesting eller modultesting (Lær med eksempler)

  • Hoved
  • Testmetoder
  • Hva er komponenttesting eller modultesting (Lær med eksempler)

what is component testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er komponenttesting også kalt modultesting i programvaretesting:

En komponent er den laveste enheten i enhver applikasjon. Så, komponenttesting; som navnet antyder, er en teknikk for å teste den laveste eller minste enheten i enhver applikasjon.

Komponenttesting blir noen ganger også referert til som Program- eller modultesting.

En applikasjon kan tenkes på en kombinasjon og integrering av mange små individuelle moduler. Før vi tester hele systemet, er det viktig at hver komponent ELLER den minste enheten i applikasjonen blir testet grundig.

hvordan åpne et nytt prosjekt i formørkelse

I dette tilfellet testes modulene eller enhetene uavhengig. Hver modul mottar en inngang, behandler noe og genererer utdataene. Utdataene valideres deretter mot forventet funksjon.

Hva er komponenttesting

Programvarene er enorme og det er en utfordring å teste hele systemet. Det kan føre til mange hull i testdekningen. Derfor anbefales det å starte med komponenttesting før du går over til integrasjonstesting eller funksjonstesting.

Les også=> Enhet, integrasjon og funksjonell testforskjell

Hva du vil lære:

Komponenttesting

Det er en slags testing av hvit boks.

Så komponenttesting ser etter feil og verifiserer funksjonen til modulene / programmene som kan testes separat.

Det er en teststrategi og testplan for komponenttesting. Og for hver komponent er det et testscenario som vil bli ytterligere fordelt i testsaker. Diagrammet nedenfor representerer det samme:

Komponenttesting

Målet med komponenttesting

Hovedmålet med komponenttesting er å verifisere inngangs- / utgangsoppførselen til testobjektet. Det sørger for at testobjektets funksjonalitet fungerer riktig og helt i henhold til ønsket spesifikasjon.

Innganger til komponentnivåtesting

De fire viktigste inngangene til testing av komponentnivå er:

  • Prosjekt Test Plan
  • Systemkrav
  • Komponentspesifikasjoner
  • Komponentimplementeringer

Hvem utfører komponenttesting?

Komponenttesting utføres av QA-tjenester eller testeren.

Hva testes under komponenttesting?

Komponenttesting kan ta hensyn til verifisering av funksjonelle eller spesifikke ikke-funksjonelle egenskaper til systemkomponenter.

Det kan være å teste ressursadferd (f.eks. Bestemme minnelekkasjer), ytelsestesting, strukturell testing osv.

Når komponenttesting er utført?

Komponenttesting utføres etter enhetstesting.

Komponenter testes så snart de er opprettet, så det er sjanser for at resultatene hentet fra en komponent under test, er avhengige av andre komponenter som igjen ikke er utviklet per nå.

Avhengig av utviklingslivssyklusmodellen kan komponenttesting utføres isolert med andre komponenter i systemet. Isolasjonen er gjort for å forhindre ytre påvirkninger.

Så, for å teste den komponenten, bruker vi Stubs and Driversfor å simulere grensesnittet mellom programvarekomponenter.

Integrasjonstesting gjøres etter komponenttesting.

Komponent Testing teststrategi

Avhengig av dybden av testnivået, er komponenttesting delt i to deler:

  1. Komponenttesting i liten (ctis)
  2. Komponenttesting i stor (CTIL)

Når komponenttesting utføres isolert med andre komponenter, kalles det som komponenttesting i små. Dette gjøres uten å vurdere integrasjon med andre komponenter.

Når komponenttesting utføres uten isolasjon med andre komponenter i programvaren, kalles det stort sett komponenttesting. Dette skjer når det er en avhengighet av komponentens funksjonalitetsflyt, og dermed kan vi ikke isolere dem.

Hvis komponentene vi har avhengighet av ikke er utviklet ennå, bruker vi dummyobjekter i stedet for de faktiske komponentene. Disse dummyobjektene er stubben (kalt funksjon) og driveren (ringefunksjon).

Stubber og drivere

Før jeg begynner å orientere meg om Stubs and Drivers, bør jeg orientere om forskjell mellom komponenttester og integrasjonstester. Årsaken er - stubber og drivere brukes også i integrasjonstesting, så dette kan føre til forvirring mellom disse to testteknikkene.

Integrasjonstestteknikk er en teknikk der vi kombinerer 2 komponenter sekvensielt og tester det integrerte systemet sammen. Data fra ett system krysses til et annet system, og korrektheten av data blir validert for det integrerte systemet.

I motsetning til modultesting der enkeltkomponenten / modulen testes grundig før den integreres i andre komponenter. Så vi kan si at komponenttesting utføres før integrasjonstesting.

Både integrasjon og komponentbruk Stubber og drivere .

“Drivere” er dummy-programmene som brukes til å ringe til funksjonene til den laveste modulen i tilfelle ringefunksjonen ikke eksisterer.

“Stubber” kan bli referert til som kode en kodebit som godtar innganger / forespørsler fra toppmodulen og returnerer resultatene / svaret

Som forklart tidligere, testes komponentene individuelt og uavhengig. Så det kan være noen funksjoner i komponentene, avhengig av den andre komponenten som ikke er utviklet for øyeblikket. Så for å teste komponentene med disse 'uutviklede' funksjonene, må vi bruke noen stimulerende midler som vil behandle dataene og returnere dem til de anropende komponentene.

På denne måten sørger vi for at de enkelte komponentene blir testet grundig.

de enkelte komponentene testes grundig

Her ser vi at:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— er komponentene
  • C1, C2 og C3 utgjør underenhet 1 sammen
  • C4 og C5 utgjør sammen underenhet 2
  • C6, C7 og C8 utgjør sammen underenhet 3
  • C9 alene gjør underenheten 4
  • Underenhet 1 og underenhet 2 kombineres for å lage forretningsenhet 1
  • Underenhet 3 og underenhet 4 kombineres for å lage forretningsenhet 2
  • Forretningsenhet 1 og forretningsenhet 2 kombineres for å lage applikasjonen.
  • Så komponenttesten, i dette tilfellet, ville være å teste de enkelte komponentene som er C1 til C9.
  • De Nett pil mellom underenhet 1 og underenhet 2 viser testpunktet for integrasjon.
  • Tilsvarende Nett pil mellom underenhet 3 og underenhet 4 viser testpunktet for integrasjon
  • Den grønne pilen mellom forretningsenhet 1 og forretningsenhet 2 viser testpunktet for integrering

Derfor ville vi gjøre:

  • KOMPONENT testing for C1 til C9
  • INTEGRERING testing mellom underenhetene og forretningsenhetene
  • SYSTEM testing av applikasjonen som helhet

Et eksempel

Inntil nå må vi ha slått fast at komponenttesting er en slags teknikk for testing av hvit boks . Det kan være riktig. Men dette betyr ikke at denne teknikken ikke kunne brukes i Black Box-testteknikk.

beste youtube video converter til mp3

Tenk på et stort webapplikasjon som starter med en påloggingsside. Som tester (det også i en smidig verden) kunne vi ikke vente til hele applikasjonen er utviklet og gjort klar til å teste. For å øke tiden vår til markedet, må vi begynne å teste tidlig. Så når vi ser at påloggingssiden er utviklet, må vi insistere på at den blir gjort tilgjengelig for oss å teste.

Så snart du har påloggingssiden tilgjengelig for deg å teste, kan du utføre alle testsakene dine (positive og negative) for å sikre at funksjonen for påloggingssiden fungerer som forventet.

Fordelene med å teste påloggingssiden din på dette tidspunktet vil være:

gratis alternativ til hurtigbøker for små bedrifter
  • UI er testet for brukervennlighet (stavefeil, logoer, justering, formatering osv.)
  • Prøv å bruke negative testteknikker som godkjenning og autorisasjon. Det er stor sannsynlighet for å finne feil i disse tilfellene.
  • Bruk av teknikker som SQL Injections ville sørge for å teste sikkerhetsbrudd på et veldig tidlig stadium.

Manglene som du vil logge på på dette stadiet vil fungere som 'leksjoner' for utviklingsteamet, og disse vil bli implementert i kodingen av den påfølgende siden. Derfor ved å teste tidlig - du har sikret en bedre kvalitet på sidene som ennå ikke skal utvikles.

Siden de andre sidene på rad ikke er utviklet ennå, kan det hende du trenger stubber for å validere påloggingssidefunksjonaliteten. For eksempel ,Det kan være lurt å ha en enkel side med opplysninger om 'logging er vellykket', i tilfelle riktig legitimasjon og popup-vindu for feilmelding i tilfelle feil legitimasjon.

Du kan gå gjennom vår tidligere opplæring på Integrasjonstesting å ha mer innsikt i stubber og drivere.

Hvordan skriver jeg komponenttestsaker?

Testtilfellene for komponenttesting er avledet fra arbeidsprodukter, for eksempel programvareutforming eller datamodellen. Hver komponent testes gjennom en sekvens av testtilfeller der hver testtilfelle dekker en spesifikk kombinasjon av input / output, dvs. delvis funksjonalitet.

Nedenfor er et eksemplar av en komponenttest for Logg på modul.

Vi kan skrive andre testsaker på samme måte.

test tilfeller

Komponenttesting mot enhetstesting

Den aller første forskjellen mellom komponenttest og enhetstesting er at den første utføres av testere mens den andre utføres av utviklere eller SDET-fagpersoner.

Enhetstesting utføres på granulatnivå. På den annen side gjøres komponenttesting på applikasjonsnivå. I enhetstesting blir det bekreftet om et enkelt program eller kodebiten blir utført i henhold til det angitte. Ved komponenttesting testes hvert objekt av programvaren separat med eller uten isolasjon med andre komponenter / objekt i systemet.

Så komponenttesting er ganske som enhetstesting, men det gjøres på et høyere nivå av integrering og i sammenheng med applikasjonen (ikke bare i sammenheng med den enheten / programmet som i enhetstesting).

Komponent mot grensesnitt mot integrasjon mot systemtesting

Komponent , som jeg forklarte, er den laveste enheten i en applikasjon som testes uavhengig.

An grensesnitt er sammenføyningslaget til de to komponentene. Testing av plattformen eller grensesnittet som de to komponentene samhandler med kalles Interface testing.

Nå er det litt annerledes å teste grensesnittet. Disse grensesnittene er for det meste API-er eller webtjenester , så testing av disse grensesnittene vil ikke være lik Black Box-teknikken, men du vil gjøre en slags API-testing eller Web Service-testing ved hjelp av SOAP UI eller noe annet verktøy.

Når grensesnitttesten er ferdig, kommer Integrasjonstesting .

Under integrasjonstesten kombinerer vi de enkelte testede komponentene en etter en og tester den trinnvis. Vi bekrefter under integrasjonen at de enkelte komponentene når de kombineres en etter en, oppfører seg som forventet, og dataene blir ikke endret når de flyter fra en modul til en annen modul.

Når alle komponentene er integrert og testet, vi utfører Systemtesting for å teste hele applikasjonen / systemet som helhet. Denne testen validerer forretningskravene mot den implementerte programvaren.

Konklusjon

Jeg ville sagt det Enhetstesting og komponenttesting gjøres side om side.

I motsetning til enhetstesting som utføres av utviklingsteamet, utføres komponent- / modultesting av testteamet. Det anbefales alltid å ha gjennomført komponenttesting før du starter integrasjonstesten.

Hvis komponenttestingen er bunnsolid, vil vi finne færre mangler i integrasjonstestingen. Det ville være problemer, men disse problemene ville være relatert til integrasjonsmiljøet eller konfigurasjonsutfordringene. Du kan sikre at funksjonaliteten til de integrerte komponentene fungerer bra.

Håper denne opplæringen var nyttig for å forstå komponent-, integrasjons- og systemtesting. Hvis du fortsatt har spørsmål, er du velkommen til å spørre oss i kommentarer.

Anbefalt lesing

^