Hva er komponenttesting? Teknikker, eksempler på testtilfeller

by: Thomas Hamilton Thomas Hamilton
Hours oppdatert

⚡ Smart oppsummering

Komponenttesting sjekker hver enkelt del av en applikasjon for seg selv, uten å integrere den med resten, slik at feil blir funnet og rettet i en enkelt modul før monteringen begynner.

  • 🧩 Omfang: Én komponent om gangen, isolert fra komponentene rundt den.
  • 👥 Eieren: Testere kjører det etter at utviklerne har fullført enhetstestingen.
  • 🔬 CTIS: Komponenttesting i Small isolerer komponenten fullstendig.
  • 🔗 CTIL: Komponenttesting i Large beholder avhengighetene, reelle eller simulerte.
  • 🧱 Doubles: En driver kaller komponenten; en stub kalles av den.
  • ✅ Exit: Ingen kritiske, høye eller middels feil forblir åpne i loggen.
Les mer

Teknikker for komponenttesting og eksempler på testtilfeller

Hva er komponenttesting?

Komponenttesting er en type programvaretesting der testing utføres på hver enkelt komponent separat, uten å integrere den med andre komponenter. Sett fra et arkitekturperspektiv kalles det også modultesting, og noen referanser kaller det programtesting.

All programvare som helhet er laget av flere komponenter, og testing på komponentnivå omhandler testing av disse komponentene individuelt. Det er en av de vanligste svart boks testing typer utført av QA-teamet.

Det er verdt å merke seg navngivning tidlig. ISTQB-ordlisten omhandler komponenttesting og enhetstesting som synonymer for samme testnivå. Mange leveranseteam, og denne artikkelen, holder de to fra hverandre i praksis: utviklere kjører enhetstester på sin egen kode, og testere kjører deretter komponenttester på den leverte byggingen. Sammenligningstabellen på slutten av denne artikkelen viser dette praktiske skillet.

Som diagrammet nedenfor viser, har komponenttesting sin egen teststrategi og testplan, der hver del av programvaren eller applikasjonen vurderes individuelt. For hver komponent en testscenario er definert, som deretter deles opp i testtilfeller på høyt nivå og til slutt i detaljerte testtilfeller på lavt nivå test tilfeller med forutsetninger.

Komponenttestingshierarki fra teststrategi ned til testtilfeller på lavt nivå

Måten begrepet «komponenttesting» brukes på varierer fra domene til domene og fra organisasjon til organisasjon. De vanligste årsakene til denne forskjellen i oppfatning er de tre nedenfor.

  1. Den valgte typen utviklingslivssyklusmodell
  2. Kompleksiteten til programvaren eller applikasjonen som testes
  3. Om testingen utføres med eller uten isolasjon fra de andre komponentene i applikasjonen

Programvaretestens livssyklus produserer mange testartefakter, det vil si dokumentene som opprettes og brukes under testaktiviteter. Blant disse er testpolicyen og teststrategien som definerer hvilke typer testing som brukes og hvor dypt testingen går i et gitt prosjekt.

Hvem utfører komponenttesting

Komponenttesting utføres av testere. Enhetstesting utføres av utviklerne, som tester en individuell funksjon eller prosedyre. Når enhetstestingen er fullført, følger komponenttesting, og testerne tar eierskap til den.

Når du skal utføre komponenttesting

Komponenttesting utføres kort tid etter at enhetstestingen er utført av utviklerne og byggingen er utgitt til testteamet. Denne byggingen kalles UT-byggingen, eller enhetstestingsbyggingen. Hovedfunksjonaliteten til hver komponent testes i denne fasen.

Inngangskriterier for komponenttesting

  • Minimumssettet med komponenter som skal inkluderes i UT-bygget er utviklet og enhetstestet.

Utgangskriterier for komponenttesting

  • Funksjonaliteten til hver komponent fungerer som spesifisert.
  • Ingen kritisk, høy eller middels alvorlighetsgrad eller prioritetsfeil er fortsatt åpne i defektlogg.

Teknikker for komponenttesting

Basert på testnivåets dybde kategoriseres komponenttesting på to måter.

  1. CTIS — Komponenttesting i liten
  2. CTIL — Komponenttesting i store

CTIS — Komponenttesting i liten

Komponenttesting kan utføres med eller uten isolasjon fra de andre komponentene i applikasjonen som testes. Når det utføres med de andre komponentene isolert, kalles det komponenttesting i liten skala.

Eksempel 1: På et nettsted med fem forskjellige nettsider er komponenttesting i liten skala å teste hver nettside separat og isolert fra de andre komponentene.

Eksempel 2: guru99.com-hjemmesiden som vises nedenfor inneholder mange komponenter, for eksempel Hjem, Testing, SAP, Nett, Må lære!, Stordata, Live-prosjekter og blogg.

Guru99 navigasjonsmenyer for hjemmesider behandlet som separate testbare komponenter

All programvare er laget av mange komponenter på samme måte, og hver komponent har sine egne underkomponenter. Å teste hver modul som er oppført i eksempel 2 separat, uten å vurdere integrasjonen med de andre komponentene, er komponenttesting i det små.

Når du åpner rullegardinmenyen Testing, vises delkomponentene i Testing-komponenten: Manuell testing, SOAPUI, QTP, JUnit, Selenium, Testhåndtering og Mobil testingI øyeblikksbildet nedenfor er disse delkomponentene uthevet med rødt.

Testing av rullegardinmeny med underkomponenter uthevet i rødt

RELATERTE ARTIKLER

CTIL — Komponenttesting i store

Komponenttesting utført uten isolasjon fra de andre komponentene i applikasjonen som testes, refereres til som komponenttesting i stor grad.

Et eksempel gjør forskjellen tydeligere. Anta at en applikasjon består av tre komponenter: Komponent A, Komponent B og Komponent C.

Utvikleren har bygget komponent B og ønsker at den skal testes. For å teste komponent B fullstendig, avhenger noe av funksjonaliteten av komponent A og noe av komponent C, som diagrammet nedenfor illustrerer.

Komponent B testet med en driver som erstatter komponent A og en stub som erstatter komponent C

Funksjonalitetsflyten er A → B → C, som betyr at komponent B avhenger av både A og C. I den flyten er stubben den kalte funksjonen og driveren er den kallende funksjonen.

Komponent A og komponent C er ikke utviklet ennå. For å teste komponent B fullstendig, erstattes A og C av en driver og en stub etter behov, slik at de to manglende delene fungerer som dummyobjekter inntil de virkelige finnes.

  • Stubb: En stub kalles av komponenten som testes. Komponent C er ikke klar, så en stub erstatter den og returnerer svarene B forventer.
  • Sjåfør: En driver kaller komponenten som testes. Komponent A er ikke klar, så en driver erstatter den og kaller B med de nødvendige inndataene.

Eksempel på testtilfeller for komponenttesting

De to nettsidene nedenfor er sammenhengende fra et funksjonalitetssynspunkt, noe som gjør dem til et nyttig komponentpar å teste.

Nettside 1 er innloggingssiden til demobanknettstedet.

Innloggingssidekomponent med bruker-ID- og passordfelt

Når brukeren oppgir en gyldig bruker-ID og et gyldig passord og klikker på send-knappen, navigerer siden til hjemmesiden til demobankens nettsted, som vises nedenfor.

Hjemmesidekomponent for ledere med navigasjonslenker og bilder

Her er innloggingssiden én komponent og hjemmesiden en annen. Å teste funksjonaliteten til hver side separat er komponenttesting.

Scenarier for komponenttesting på nettside 1:

  • Skriv inn en ugyldig bruker-ID og bekreft at en brukervennlig advarsel vises til sluttbrukeren.
  • Skriv inn en ugyldig bruker-ID og et ugyldig passord, klikk på Tilbakestill, og kontroller at feltene for bruker-ID og passord er tømt.
  • Skriv inn et gyldig brukernavn og passord, og klikk på Logg inn-knappen.

Scenarier for komponenttesting på nettside 2:

  • Kontroller at velkomstmeldingen for ledersiden vises på hjemmesiden.
  • Kontroller at alle lenkene på venstre side av nettsiden er klikkbare.
  • Kontroller at leder-ID-en vises midt på hjemmesiden.
  • Bekreft tilstedeværelsen av de tre forskjellige bildene på hjemmesiden, i henhold til diagrammet.

Enhetstesting vs komponenttesting

Tabellen nedenfor oppsummerer hvordan de to nivåene skiller seg fra hverandre i daglig praksis.

Enhetstesting Komponenttesting
Testing av individuelle programmer og moduler for å demonstrere at programmet kjører i henhold til spesifikasjonen. Testing av hvert objekt eller hver del av programvaren separat, med eller uten isolasjon fra andre objekter.
Validert mot designdokumenter. Validert mot testkrav og brukstilfeller.
Gjort av utviklere. Utført av testere.
Ferdig først. Utført etter at enhetstestingen er fullført hos utviklerne.
Mangler blir vanligvis rettet på stedet og ikke formelt loggført. Feil loggføres og tracgått gjennom feilhåndteringsprosessen.

Spørsmål og svar

Redusere risiko, verifisere funksjonell og ikke-funksjonell oppførsel til komponenten, bygge tillit til kvaliteten, finne feil og forhindre at disse feilene unnslipperping til høyere testnivåer.

Modeller leser en komponentkonfigurasjontracog foreslå ugyldige inndata, grenseverdier og feilveier som en manuell gjennomgang har en tendens til å bomme på. En tester bekrefter fortsatt alle forventede resultater før utførelse.

Ja. En stubb som returnerer ferdiglagde svar og en driver som mater faste input er formelkode som en assistent skriver raskt. Å avgjøre hvilke svar som er realistiske er fortsatt et menneskelig valg.

Komponenttesting undersøker én komponent for seg selv. integrasjonstesting undersøker grensesnittene og interaksjonene mellom komponenter, og kjører etter komponenttesting.

Code-nivårammeverk som JUnit, TestNG, NUnit og pytest, pluss UI-komponentkjørere som Cypress Komponenttesting, Storybook og Jest. Alle disse passer inn i en automatisering rørledning.

Bygge og vedlikeholde doblingene. En stub som driver bort fra den virkelige komponenten skjuler defekter frem til integrasjon, så alle simulerte responser må sees på nytt når den virkelige avhengigheten sendes.

Den reverserer rekkefølgen. Saker skrives og automatiseres før komponenten eksisterer, deretter legges kode til de består. Komponenten leveres med testpakken sin allerede på plass.

Begge deler, avhengig av hvem som kjører det. Testere jobber med svart boks mot komponentspesifikasjonen, mens utviklere med kodetilgang bruker koden. hvit boks dekning innenfor samme komponent.

Oppsummer dette innlegget med: