Meny

Vad är komponenttestning eller modultestning (lär dig med exempel)

  • Huvud
  • Testmetoder
  • Vad är komponenttestning eller modultestning (lär dig med exempel)

what is component testing

Prova Vårt Instrument För Att Eliminera Problem

Vad kallas komponenttest även för modultestning vid programvarutestning:

En komponent är den lägsta enheten i alla applikationer. Så, komponenttestning; som namnet antyder är en teknik för att testa den lägsta eller minsta enheten i någon applikation.

Komponenttestning kallas ibland också för Program- eller modultestning.

En applikation kan tänkas på en kombination och integration av många små enskilda moduler. Innan vi testar hela systemet är det viktigt att varje komponent ELLER den minsta enheten i applikationen testas noggrant.

hur man öppnar ett nytt projekt i förmörkelse

I detta fall testas modulerna eller enheterna oberoende av varandra. Varje modul tar emot en ingång, bearbetar lite och genererar utdata. Utdata valideras sedan mot den förväntade funktionen.

Vad är komponenttestning

Programvarorna är enorma till sin karaktär och det är en utmaning att testa hela systemet. Det kan leda till många luckor i testtäckningen. Innan vi går in i Integrationstest eller funktionstest rekommenderas därför att börja med Component testing.

Läs också=> Enhets-, integrations- och funktionstestningsskillnad

Vad du kommer att lära dig:

Komponenttestning

Det är ett slags vitlåda testning.

Så komponenttestning letar efter buggar och verifierar funktionerna hos modulerna / programmen som kan testas separat.

Det finns en teststrategi och testplan för komponenttestning. Och för varje komponent finns ett testscenario som kommer att delas upp ytterligare i testfall. Nedanstående diagram representerar samma:

Komponenttestning

Målet med komponenttestning

Huvudsyftet med komponenttestning är att verifiera testobjektets in / ut-beteende. Det säkerställer att testobjektets funktionalitet fungerar korrekt och helt fin enligt önskad specifikation.

Ingångar till komponentnivåtestning

De fyra viktigaste ingångarna till komponentnivåtestning är:

  • Projekt Testplan
  • Systemkrav
  • Komponentspecifikationer
  • Komponentimplementeringar

Vem testar komponenter?

Komponenttestning utförs av QA-tjänster eller testaren.

Vad testas under komponenttestning?

Komponenttestning kan ta hänsyn till verifiering av funktionella eller specifika icke-funktionella egenskaper hos systemkomponenter.

Det kan vara att testa resursbeteende (t.ex. bestämma minnesläckor), prestandatest, strukturell testning etc.

När komponenttestning är klar?

Komponenttestning utförs efter enhetstestning.

Komponenter testas så snart de skapas, så det finns chanser att resultaten som hämtas från en komponent som testas är beroende av andra komponenter som i sin tur inte utvecklas för närvarande.

Beroende på utvecklingslivscykelmodellen kan komponenttester utföras isolerat med andra komponenter i systemet. Isoleringen görs för att förhindra yttre påverkan.

Så, för att testa den komponenten använder vi Stubs and Driversför att simulera gränssnittet mellan programvarukomponenter.

Integrationstestning görs efter komponenttestning.

Komponenttestning teststrategi

Beroende på testnivåns djup delas testning av komponenter i två delar:

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

När komponenttestning görs isolerat med andra komponenter kallas det som komponenttestning i små. Detta görs utan att integrera med andra komponenter.

När komponenttestning görs utan isolering med andra komponenter i programvaran kallas det som komponenttestning i stort. Detta händer när det finns ett beroende av komponenternas funktionalitetsflöde och därmed kan vi inte isolera dem.

Om de komponenter som vi har beroende inte är utvecklade ännu, använder vi dummyobjekt istället för de faktiska komponenterna. Dessa dummyobjekt är stubben (kallas funktion) och föraren (samtalsfunktion).

Stubbar och drivrutiner

Innan jag hoppar för att informera om Stubs och Drivers, borde jag informera om skillnad mellan komponenttest och integrationstest. Anledningen är - Stubbar och drivrutiner används också vid integrationstester så detta kan leda till viss förvirring mellan dessa två testtekniker.

Integrationstestteknik är en teknik där vi kombinerar två komponenter sekventiellt och testar det integrerade systemet tillsammans. Data från ett system överförs till ett annat system och riktigheten av data valideras för det integrerade systemet.

Till skillnad från modultestning där den enskilda komponenten / modulen testas noggrant innan den integreras i andra komponenter. Så vi kan säga att komponenttest utförs före integrationstestning.

Både integrations- och komponentanvändning Stubbar och drivrutiner .

'Förare' är dummy-program som används för att anropa funktionerna i den lägsta modulen om samtalsfunktionen inte existerar.

“Stubbar” kan kallas kod ett utdrag som accepterar ingångarna / förfrågningarna från toppmodulen och returnerar resultaten / svaret

Som förklarats tidigare testas komponenterna individuellt och oberoende. Så det kan finnas vissa funktioner i komponenterna, beroende på den andra komponenten som för närvarande inte är utvecklad. Så, för att testa komponenterna med dessa 'outvecklade' funktioner, måste vi använda några stimulerande medel som skulle behandla data och returnera den till de anropande komponenterna.

På så sätt ser vi till att de enskilda komponenterna testas noggrant.

de enskilda komponenterna testas noggrant

Här ser vi att:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— är komponenterna
  • C1, C2 och C3 tillsammans gör underenheten 1
  • C4 och C5 tillsammans gör underenheten 2
  • C6, C7 och C8 gör tillsammans underenheten 3
  • C9 ensam gör underenheten 4
  • Underenhet 1 och underenhet 2 kombineras för att göra affärsenhet 1
  • Underenhet 3 och underenhet 4 kombineras för att göra affärsenhet 2
  • Affärsenhet 1 och affärsenhet 2 kombineras för att göra ansökan.
  • Så komponenttestningen skulle i det här fallet vara att testa de enskilda komponenterna som är C1 till C9.
  • De Netto pil mellan underenhet 1 och underenhet 2 visar testpunkten för integration.
  • På samma sätt har Netto pil mellan underenhet 3 och underenhet 4 visar testpunkten för integration
  • Den gröna pilen mellan affärsenhet 1 och affärsenhet 2 visar integrationsprovpunkten

Därför skulle vi göra:

  • KOMPONENT testning för C1 till C9
  • INTEGRATION testning mellan underenheterna och affärsenheterna
  • SYSTEMET testning av applikationen som helhet

Ett exempel

Fram till nu måste vi ha fastställt att komponenttestning är någon typ av vitlåda testteknik . Det kan vara rätt. Men detta betyder inte att denna teknik inte kunde användas i Black Box-testteknik.

vad man ska göra med en bin-fil

Tänk på en enorm webbapplikation som börjar med en inloggningssida. Som testare (det också i en smidig värld) kunde vi inte vänta tills hela applikationen har utvecklats och görs redo att testas. För att öka vår tid på marknaden måste vi börja testa tidigt. Så när vi ser att inloggningssidan är utvecklad måste vi insistera på att den görs tillgänglig för oss att testa.

Så snart du har inloggningssidan tillgänglig för dig att testa kan du utföra alla dina testfall (positiva och negativa) för att säkerställa att inloggningssidans funktionalitet fungerar som förväntat.

Fördelarna med att testa din inloggningssida vid denna tidpunkt är:

selen webdriver intervju frågor och svar för erfarna
  • UI testas för användbarhet (stavfel, logotyper, justering, formatering etc.)
  • Försök använda negativa testtekniker som autentisering och auktorisering. Det finns en stor sannolikhet att hitta fel i dessa fall.
  • Användning av tekniker som SQL-injektioner skulle säkerställa att säkerhetsöverträdelsen testas i ett mycket tidigt skede.

De brister som du skulle logga in i detta skede skulle fungera som 'lärdomar' för utvecklingsteamet och dessa skulle implementeras i kodningen av den på varandra följande sidan. Därför genom att testa tidigt - du har säkerställt en bättre kvalitet på de sidor som ännu inte utvecklats.

Eftersom de andra på varandra följande sidorna ännu inte är utvecklade kan du behöva stubbar för att validera inloggningssidans funktionalitet. Till exempel ,du kanske vill ha en enkel sida som anger 'loggning lyckad', i händelse av korrekta uppgifter och felmeddelande popup-fönster i händelse av felaktiga uppgifter.

Du kan gå igenom vår tidigare handledning på Integrationstestning att få mer insikt om Stubs och Drivers.

Hur skriver jag komponenttestfall?

Testfallet för komponenttestning härrör från arbetsprodukter, till exempel programvarudesign eller datamodellen. Varje komponent testas genom en sekvens av testfall där varje testfall täcker en specifik kombination av input / output, dvs delvis funktionalitet.

Nedan följer ett exempel på ett komponenttestfall för inloggningsmodul.

Vi kan skriva andra testfall på samma sätt.

testfall

Komponenttestning mot enhetstestning

Den allra första skillnaden mellan komponenttest och enhetstestning är att den första utförs av testare medan den andra utförs av utvecklare eller SDET-proffs.

Enhetstester utförs på en granulär nivå. Å andra sidan görs komponenttestning på applikationsnivå. Vid enhetstestning verifieras det om ett enskilt program eller kodkoden körs enligt det angivna. Vid komponenttestning testas varje objekt i programvaran separat med eller utan isolering med andra komponenter / objekt i systemet.

Så komponenttestning är precis som enhetstestning, men det görs på en högre nivå av integration och i applikationens sammanhang (inte bara i samband med den enheten / programmet som vid enhetstestning).

Komponent mot gränssnitt mot integrering mot systemtestning

Komponent , som jag förklarade, är den lägsta enheten i en applikation som testas oberoende.

En gränssnitt är fogskiktet av de två komponenterna. Test av plattformen eller gränssnittet som de två komponenterna interagerar med kallas gränssnitttestning.

Nu är det lite annorlunda att testa gränssnittet. Dessa gränssnitt är mestadels API: er eller webbtjänster , så testning av dessa gränssnitt skulle inte likna Black Box-tekniken, utan du skulle göra någon form av API-testning eller webbtjänsttestning med SOAP UI eller något annat verktyg.

När gränssnitttestningen är klar kommer Integrationstestning .

Under integreringstestet kombinerar vi de enskilda testade komponenterna en efter en och testar den stegvis. Vi bekräftar under integrationen att de enskilda komponenterna, när de kombineras en efter en, fungerar som förväntat och att data inte ändras när de flödar från en modul till en annan modul.

När alla komponenter är integrerade och testade, vi utför Systemtestning för att testa hela applikationen / systemet som helhet. Detta test validerar affärskraven mot den implementerade programvaran.

Slutsats

jag skulle säga att Enhetstestning och komponenttestning görs sida vid sida.

Till skillnad från enhetstestning som görs av utvecklingsteamet, görs komponent- / modultestning av testteamet. Det rekommenderas alltid att göra en genomgående komponenttest innan du startar integrationstestningen.

Om komponenttestningen är solid, kommer vi att hitta färre defekter i integrationstestningen. Det skulle finnas problem, men dessa frågor skulle vara relaterade till integrationsmiljön eller konfigurationsutmaningar. Du kan se till att funktionerna hos de integrerade komponenterna fungerar bra.

Hoppas att den här guiden var användbar för att förstå komponent-, integrations- och systemtesterna. Om du fortfarande har frågor är du välkommen att fråga oss i kommentarer.

Rekommenderad läsning

^