Hvad er komponenttestning? Teknikker, eksempler på testcases

Hvad er komponenttestning?

Komponenttestning er defineret som en softwaretesttype, hvor testen udføres på hver enkelt komponent separat uden integration med andre komponenter. Det kaldes også modultest, når det ses fra et arkitekturperspektiv. Komponenttestning omtales også som enhedstest, programtest eller modultest.

Generelt er enhver software som helhed lavet af flere komponenter. Komponentniveautest beskæftiger sig med testning af disse komponenter individuelt.

Det er en af ​​de hyppigste sorte boks-testtyper, som udføres af QA Team.

Som i nedenstående diagram vil der være en teststrategi og testplan for komponenttestning. Hvor hver eneste del af softwaren eller applikationen betragtes individuelt. For hver af denne komponent a Testscenarie vil blive defineret, som yderligere vil blive bragt ned i en High Level Test Cases -> Low Level detaljerede Test Cases with Prerequisites.

Brugen af ​​udtrykket "Komponenttestning” varierer fra domæne til domæne og organisation til organisation.

Den mest almindelige årsag til forskellig opfattelse af komponenttestning er

1. Udviklingstype Valgt livscyklusmodel
2. Kompleksiteten af ​​den software eller applikation, der testes
3. Test med eller uden isolation fra resten af ​​anden komponent i software eller applikation.

Som vi kender Software Test Life Cycle Architecture har mange mange test-artefakter (dokumenter lavet, brugt under testaktiviteter). Blandt mange test – artefakter, er det Test Policy & Test Strategy, som definerer testtyperne, testdybden, der skal udføres i et givet projekt.

Hvem udfører komponenttestning

Komponenttestning udføres af testere. 'Unit Testing' udføres af udviklerne, hvor de tester den enkelte funktionalitet eller procedure. Efter Enhedstest udføres, er den næste test komponenttest. Komponenttestning udføres af testerne.

Hvornår skal man udføre komponenttest

Komponenttestning udføres kort efter, at enhedstesten er udført af udviklerne, og bygningen er frigivet til testteamet. Denne build kaldes UT build (Unit Testing Build). Hovedfunktionaliteten af ​​alle komponenterne testes i denne fase,

Adgangskriterier for komponenttestning

• Minimumsantallet af den komponent, der skal inkluderes i UT, bør udvikles og enhedstestes.

Udgangskriterier for komponenttestning

• Funktionaliteten af ​​hele komponenten burde fungere fint.
• Der bør ikke være nogen kritiske eller høj eller medium sværhedsgrad og prioriterede defekter Defekt log.

Teknikker til komponenttestning

Baseret på dybden af ​​testniveauer kan komponenttestning kategoriseres som

1. CTIS – Komponenttestning i små
2. CTIL – Component Testing In Large

CTIS – Komponenttest i små

Komponenttestning kan udføres med eller uden isolering af resten af ​​andre komponenter i softwaren eller applikationen, der testes. Hvis det udføres med isolering af en anden komponent, kaldes det komponenttestning i lille.

Eksempel 1: Overvej et websted, der har 5 forskellige websider, og test derefter hver webside separat og med isolering af andre komponenter omtales som komponenttest i Small.

Eksempel 2: Overvej hjemmesiden for guru99.com hjemmesiden, som har mange komponenter som

Hjem, Test, SAP, Web, Must Learn!, Big Data, Live Projects, Blog og etc.

På samme måde er enhver software lavet af mange komponenter, og hver komponent vil også have sine egne underkomponenter. Afprøvning af de enkelte moduler nævnt i eksempel 2 separat uden at overveje integration med andre komponenter kaldes Komponenttestning i små.

Klik på Drop Down-menuen Test i henhold til nedenstående snapshow og se forskellige "underkomponenter" af testkomponent. Så de viste underkomponenter er Manuel testning, SOAPUI, QTP, JUnit, Selenium, Test Management, Selenium, Mobil Test mv.

Bemærk: Underkomponenten er nævnt med rød fremhævet farve i nedenstående snapshot.

CTIL – Component Testing in Large

Komponenttest udført uden isolering af andre komponenter i softwaren eller applikationen, der testes, kaldes Component Testing Large.

Lad os tage et eksempel for at forstå det på en bedre måde. Lad os sige, at der er en applikation bestående af tre komponenter Komponent A, Komponent B, og Komponent C.

Udvikleren har udviklet komponent B og ønsker den testet. Men for at fuldstændig test komponent B, få af dens funktionaliteter er afhængige af komponent A og få af komponent C.

Funktionsflow: A -> B -> C hvilket betyder, at der er en afhængighed til B fra både A & C, som pr. diagramstubben er kaldet funktion, og chaufføren er opkaldsfunktion.

Men komponent A og komponent C er ikke udviklet endnu. I så fald, for at teste komponent B fuldstændigt, kan vi erstatte komponent A og komponent C med stub og drivere efter behov. Så dybest set er komponent A & C erstattet af stub & driver's, som fungerer som et attrapobjekt, indtil de rent faktisk er udviklet.

• Stub: En stub kaldes fra softwarekomponenten, der skal testes, som vist i diagrammet nedenfor 'Stub' kaldes af komponent A.
• Chauffør: En driver kalder den komponent, der skal testes, som vist i diagrammet nedenfor 'Komponent B' kaldes af føreren.

Eksempel på testcases til komponenttestning

Overvej 2 websider i henhold til diagrammerne nævnt nedenfor. Her er begge websider forbundne med hinanden fra et funktionsmæssigt synspunkt.

1. Webside 1 er login-side til demo.guru99.com

Når brugeren indtastede gyldigt bruger-id og adgangskode i tekstfeltet og klik på send-knappen, vil websiden navigere til hjemmesiden for guru99 demo bank hjemmeside.

2. Webside 2 er hjemmesiden for Guru99.com

Så her er login-siden én komponent, og hjemmesiden er en anden. Nu kaldes det at teste funktionaliteten af ​​individuelle sider separat komponenttest.

Komponenttestscenarier på webside1 –

• Indtast ugyldigt bruger-id, og kontroller, om der vises en brugervenlig advarsel til slutbrugeren.
• Indtast ugyldigt bruger-id og adgangskode, og klik på 'nulstil' og bekræft, om de data, der er indtastet i tekstfelterne bruger-id og adgangskode, er slettet.
• Indtast det gyldige brugernavn og adgangskoden, og klik på 'Login'-knappen.

Komponenttestscenarier på webside2 –

• Bekræft, om meddelelsen "Velkommen til managersiden for guru99 bank" vises på startsiden.
• Bekræft, om alle linkene i venstre side af websiden er klikbare.
• Bekræft, om manager-id'et vises i midten af ​​startsiden.
• Bekræft tilstedeværelsen af ​​de 3 forskellige billeder på hjemmesiden i henhold til diagrammet.

Enhedstest vs komponenttest

Enhedstest	Komponenttestning
Afprøvning af individuelle programmer, moduler for at demonstrere, at programmet udføres i henhold til specifikationen kaldes Enhedstest	Test af hvert objekt eller dele af softwaren separat med eller uden isolering af andre objekter kaldes Komponenttestning
Den er valideret i forhold til designdokumenter	Det er valideret i forhold til testkrav, use cases
Enhedstest udføres af udviklere	Komponenttestning udføres af testere
Enhedstest udføres først	Komponenttestning udføres efter enhedstestning er afsluttet fra udviklerens ende.

Resumé

In Software Engineering, Komponenttestning spiller en afgørende rolle i at finde fejlene. Inden vi starter Integrationstest efter komponenttestningen og integrationstesten efterfølges af komponenttesten.

Komponenttestning omtales også som modultest i nogle referencer.