Menu

Hvad er komponenttest eller modultest (lær med eksempler)

what is component testing

Prøv Vores Instrument Til At Fjerne Problemer

Hvad er komponenttest også kaldet modultest i softwaretest:

En komponent er den laveste enhed i enhver applikation. Så komponenttest; som navnet antyder, er en teknik til test af den laveste eller mindste enhed i enhver applikation.

Komponenttest kaldes undertiden også Program- eller modultest.

En applikation kan tænkes på en kombination og integration af mange små individuelle moduler. Før vi tester hele systemet, er det vigtigt, at hver komponent ELLER den mindste enhed i applikationen testes grundigt.

hvordan man fjerner element fra array i java

I dette tilfælde testes modulerne eller enhederne uafhængigt. Hvert modul modtager et input, behandler noget og genererer output. Outputtet valideres derefter mod den forventede funktion.

Hvad er komponenttest

Softwareapplikationerne er enorme, og det er en udfordring at teste hele systemet. Det kan føre til mange huller i testdækningen. Derfor anbefales det at starte med komponenttest, før du går ind i integrationstest eller funktionstest.

Læs også=> Enhed, integration og funktionel testforskel

Hvad du vil lære:

Komponenttest

Det er en slags hvid boks test.

Så komponenttest ser efter bugs og verificerer funktionen af ​​moduler / programmer, som kan testes separat.

Der er en teststrategi og testplan for komponenttest. Og for hver komponent er der et testscenarie, som vil blive yderligere opdelt i testsager. Diagrammet nedenfor repræsenterer det samme:

Komponenttest

Målet med komponenttest

Hovedformålet med komponenttest er at kontrollere input / output-opførsel af testobjektet. Det sikrer, at testobjektets funktionalitet fungerer korrekt og helt fint i henhold til den ønskede specifikation.

Indgange til komponentniveau testning

De fire vigtigste input til test på komponentniveau er:

  • Projekt Test Plan
  • Systemkrav
  • Komponentspecifikationer
  • Komponentimplementeringer

Hvem udfører komponenttest?

Komponenttest udføres af QA-tjenester eller testeren.

Hvad testes under komponenttest?

Komponenttest kan tage hensyn til verifikation af funktionelle eller specifikke ikke-funktionelle egenskaber ved systemkomponenter.

Det kan være at teste ressourceadfærd (f.eks. Bestemme hukommelseslækager), præstationstest, strukturel test osv.

Når komponenttest er udført?

Komponenttest udføres efter enhedstest.

Komponenter testes, så snart de er oprettet, så der er chancer for, at resultaterne hentet fra en komponent, der testes, er afhængige af andre komponenter, som igen ikke er udviklet lige nu.

Afhængig af udviklingslivscyklusmodellen kan komponenttest udføres isoleret med andre komponenter i systemet. Isolationen sker for at forhindre ekstern påvirkning.

Så for at teste denne komponent bruger vi Stubs og Driverstil simulering af grænsefladen mellem softwarekomponenter.

Integrationstest udføres efter komponenttest.

Komponenttest teststrategi

Afhængig af dybden af ​​testniveauet er komponenttest opdelt i to dele:

  1. Komponenttest i små (ctis)
  2. Komponenttestning i stort (CTIL)

Når komponenttest udføres isoleret med andre komponenter, kaldes det som komponenttest i små. Dette gøres uden at overveje integration med andre komponenter.

Når komponenttest udføres uden isolering med andre komponenter i softwaren, kaldes det stort set som komponenttest. Dette sker, når der er en afhængighed af komponenternes funktionalitet, og derfor kan vi ikke isolere dem.

Hvis de komponenter, som vi er afhængige af, ikke er udviklet endnu, så bruger vi narreobjekter i stedet for de faktiske komponenter. Disse dummy-objekter er stubben (kaldet funktion) og driveren (kaldefunktion).

Stubs og drivere

Inden jeg springer til briefing om stubs og drivere, skal jeg orientere om forskel mellem komponenttest og integrationstest. Årsagen er - stubs og drivere bruges også til integrationstest, så dette kan føre til en vis forvirring mellem disse to testteknikker.

Integrationstestteknik er en teknik, hvor vi kombinerer 2 komponenter sekventielt og tester det integrerede system sammen. Data fra et system krydses til et andet system, og dataens rigtighed valideres for det integrerede system.

I modsætning til modultest, hvor enkeltkomponenten / modulet testes grundigt, inden det integreres i andre komponenter. Så vi kan sige, at komponenttest udføres inden integrationstest.

Både integration og komponentanvendelse Stubs og drivere .

“Drivere” er dummy-programmer, der bruges til at kalde funktionerne i det laveste modul, hvis opkaldsfunktionen ikke findes.

“Stubs” kan kaldes kode et uddrag, der accepterer input / anmodninger fra topmodulet og returnerer resultaterne / svaret

Som forklaret tidligere testes komponenterne individuelt og uafhængigt. Så der kan være nogle funktioner i komponenterne, afhængigt af den anden komponent, som ikke er udviklet i øjeblikket. Så for at teste komponenterne med disse 'uudviklede' funktioner, er vi nødt til at bruge nogle stimulerende midler, som vil behandle dataene og returnere dem til de kaldende komponenter.

På denne måde sørger vi for, at de enkelte komponenter testes grundigt.

de enkelte komponenter testes grundigt

Her ser vi, at:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— er komponenterne
  • C1, C2 og C3 udgør sammen underenheden 1
  • C4 og C5 udgør sammen underenhed 2
  • C6, C7 og C8 udgør sammen underenheden 3
  • C9 alene gør underenheden 4
  • Underenhed 1 og underenhed 2 skaber sammen forretningsenhed 1
  • Underenhed 3 og underenhed 4 kombineres til at skabe forretningsenhed 2
  • Forretningsenhed 1 og forretningsenhed 2 skaber sammen applikationen.
  • Så komponenttesten, i dette tilfælde, ville være at teste de enkelte komponenter, der er C1 til C9.
  • Det Net pil mellem Underenhed 1 og Underenhed 2 viser Integration-testpunktet.
  • Tilsvarende er Net pil mellem Underenhed 3 og Underenhed 4 viser testpunktet for integration
  • Den grønne pil mellem forretningsenhed 1 og forretningsenhed 2 viser integrationstestpunktet

Derfor ville vi gøre:

  • KOMPONENT test for C1 til C9
  • INTEGRATION test mellem underenhederne og forretningsenhederne
  • SYSTEM test af applikationen som helhed

Et eksempel

Indtil nu skal vi have fastslået, at komponenttest er en slags hvid boks testteknik . Nå, det kan være rigtigt. Men dette betyder ikke, at denne teknik ikke kunne bruges i Black Box-testteknik.

hvordan man skriver et eksempel på en fejlrapport

Overvej en enorm webapplikation, der starter med en login-side. Som tester (det også i en agil verden) kunne vi ikke vente, indtil hele applikationen er udviklet og er klar til test. For at øge vores tid til markedet skal vi begynde at teste tidligt. Så når vi ser, at login-siden er udviklet, skal vi insistere på, at den stilles til rådighed for os til test.

Så snart du har loginsiden tilgængelig, som du kan teste, kan du udføre alle dine testsager (positive og negative) for at sikre, at login-sidefunktionaliteten fungerer som forventet.

Fordelene ved at teste din login-side på dette tidspunkt er:

prøve test plan dokument til mobil applikation
  • UI er testet for brugervenlighed (stavefejl, logoer, justering, formatering osv.)
  • Prøv at bruge negative testteknikker som godkendelse og autorisation. Der er stor sandsynlighed for at finde mangler i disse tilfælde.
  • Brug af teknikker som SQL Injektioner ville sikre at teste sikkerhedsbruddet på et meget tidligt tidspunkt.

De mangler, som du ville logge på på dette tidspunkt, ville fungere som 'erfaringer' for udviklingsteamet, og disse ville blive implementeret i kodningen af ​​den på hinanden følgende side. Derfor ved at teste tidligt - du har sikret en bedre kvalitet af de sider, der endnu ikke er udviklet.

Da de andre på hinanden følgende sider endnu ikke er udviklet, skal du muligvis have stubber for at validere login-sidefunktionaliteten. For eksempel ,du vil muligvis have en simpel side med angivelse af 'logning vellykket' i tilfælde af korrekte legitimationsoplysninger og pop op-vindue med fejlmeddelelse i tilfælde af forkerte legitimationsoplysninger.

Du kan gennemgå vores tidligere vejledning om Integrationstest at få mere indsigt i stubs og drivere.

Hvordan skriver man komponenttestsager?

Testcases til komponenttest stammer fra arbejdsprodukter, for eksempel software design eller datamodellen. Hver komponent testes gennem en række testsager, hvor hver testcase dækker en specifik kombination af input / output, dvs. delvis funktionalitet.

Nedenfor er et stikprøve af en komponenttestkasse til Login Module.

Vi kan skrive andre testsager på samme måde.

test tilfælde

Komponenttest mod enhedstest

Den allerførste forskel mellem komponenttest og enhedstest er, at den første udføres af testere, mens den anden udføres af udviklere eller SDET-fagfolk.

Enhedstest udføres på et granulært niveau. På den anden side udføres komponenttest på applikationsniveau. I enhedstestning verificeres det, om et enkelt program eller kodestykket bliver udført i henhold til det specificerede. Ved komponenttest testes hvert objekt i softwaren separat med eller uden isolering med andre komponenter / objekt i systemet.

Så komponenttestning ligner enhedstest, men det udføres på et højere integrationsniveau og i applikationens sammenhæng (ikke kun i sammenhæng med enheden / programmet som ved enhedstest).

Component Vs Interface Vs Integration Vs Systems testing

Komponent , som jeg forklarede, er den laveste enhed i en applikation, der testes uafhængigt.

An interface er forbindelseslaget af de to komponenter. Test af platformen eller grænsefladen, som de 2 komponenter interagerer med, kaldes Interface-test.

Nu er test af grænsefladen lidt anderledes. Disse grænseflader er for det meste API'er eller webservices , så test af disse grænseflader ville ikke svare til Black Box-teknikken, snarere ville du lave en slags API-test eller Web Service-test ved hjælp af SOAP UI eller ethvert andet værktøj.

Når grænsefladen testes er færdig, kommer Integrationstest .

Under integrationstesten kombinerer vi de enkelte testede komponenter en efter en og tester den trinvist. Vi bekræfter under integrationen, at de enkelte komponenter, når de kombineres en efter en, opfører sig som forventet, og dataene ændres ikke, når de flyder fra 1 modul til et andet modul.

Når alle komponenter er integreret og testet, vi udfører Systemtest at teste hele applikationen / systemet som helhed. Denne test validerer forretningskravene i forhold til den implementerede software.

Konklusion

Det vil jeg sige Enhedstest og komponenttest udføres side om side.

I modsætning til enhedstest, der udføres af udviklingsteamet, udføres komponent- / modultest af testteamet. Det anbefales altid at have gennemført komponenttest, inden du starter Integration-testen.

Hvis komponenttesten er solid, finder vi færre defekter i integrationstesten. Der ville være problemer, men disse problemer ville være relateret til integrationsmiljøet eller konfigurationsudfordringerne. Du kan sikre, at funktionaliteten af ​​de integrerede komponenter fungerer fint.

Håber, at denne tutorial var nyttig til at forstå komponent-, integrations- og systemtesten. Hvis du stadig har spørgsmål, er du velkommen til at spørge os i kommentarer.

Anbefalet læsning

^