Menu

Wat is componenttesten of moduletesten (leer met voorbeelden)

what is component testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is Component Testing, ook wel Module Testing genoemd in Software Testing:

Een component is de laagste eenheid van elke toepassing. Component testen dus; zoals de naam al doet vermoeden, is een techniek om de laagste of de kleinste eenheid van elke toepassing te testen.

Het testen van componenten wordt soms ook wel programma- of moduletesten genoemd.

Een applicatie kan worden gedacht aan een combinatie en integratie van vele kleine individuele modules. Voordat we het hele systeem testen, is het absoluut noodzakelijk dat elk onderdeel OF de kleinste eenheid van de applicatie grondig wordt getest.

wat is er nodig bij het testen van software

In dit geval worden de modules of de units onafhankelijk getest. Elke module ontvangt een input, doet wat bewerkingen en genereert de output. De uitvoer wordt vervolgens gevalideerd tegen de verwachte functie.

Wat is componenttesten

De softwaretoepassingen zijn enorm van aard en het is een uitdaging om het hele systeem te testen. Het kan leiden tot veel hiaten in de testdekking. Daarom is het raadzaam om te beginnen met het testen van componenten voordat u overgaat op integratietests of functionele tests.

Lees ook​ Verschil in eenheid, integratie en functioneel testen

Wat je leert:

Component testen

Het is een soort white box-testen.

Het testen van componenten zoekt dus naar bugs en verifieert de werking van de modules / programma's die afzonderlijk kunnen worden getest.

Er is een teststrategie en een testplan voor het testen van componenten. En voor elk onderdeel is er een testscenario dat in testgevallen verder wordt uitgesplitst. Het onderstaande diagram geeft hetzelfde weer:

Component testen

Het doel van Component Testing

Het belangrijkste doel van het testen van componenten is om het invoer- / uitvoergedrag van het testobject te verifiëren. Het zorgt ervoor dat de functionaliteit van het testobject correct en volledig in orde is volgens de gewenste specificatie.

Ingangen voor testen op componentniveau

De vier belangrijkste inputs voor testen op componentniveau zijn:

  • Projecttestplan
  • systeem vereisten
  • Component Specificaties
  • Component implementaties

Wie doet componenttests?

Het testen van componenten wordt gedaan door QA-services of de tester.

Wat wordt getest onder Component testen?

Bij het testen van componenten kan rekening worden gehouden met het verifiëren van functionele of specifieke niet-functionele kenmerken van systeemcomponenten.

Het kan het gedrag van bronnen zijn (bijv. Het bepalen van geheugenlekken), prestatietests, structurele tests, enz.

Wanneer het testen van componenten is voltooid?

Het testen van componenten wordt uitgevoerd na het testen van de unit.

Componenten worden getest zodra ze zijn gemaakt, dus de kans is groot dat de resultaten die worden opgehaald uit een te testen component, afhankelijk zijn van andere componenten die op hun beurt vanaf nu niet zijn ontwikkeld.

Afhankelijk van het ontwikkelingslevenscyclusmodel, kunnen componenttests worden uitgevoerd in isolatie met andere componenten van het systeem. De isolatie wordt gedaan om externe invloeden te voorkomen.

Dus om dat onderdeel te testen, gebruiken we Stubs en Driversvoor het simuleren van de interface tussen softwarecomponenten.

Integratietesten worden gedaan na het testen van componenten.

Teststrategie voor het testen van componenten

Afhankelijk van de diepte van het testniveau, is het testen van componenten onderverdeeld in twee delen:

  1. Component testen in Small (ctis)
  2. Component testen in het groot (CTIL)

Wanneer het testen van componenten afzonderlijk wordt uitgevoerd met andere componenten, wordt dit in het klein genoemd als componenttests. Dit gebeurt zonder rekening te houden met integratie met andere componenten.

Wanneer componenttests worden uitgevoerd zonder isolatie met andere componenten van de software, wordt dit in het algemeen componenttests genoemd. Dit gebeurt wanneer er een afhankelijkheid is van de functionaliteitsstroom van de componenten en we ze dus niet kunnen isoleren.

Als de componenten waarvan we afhankelijk zijn nog niet zijn ontwikkeld, gebruiken we dummy-objecten in plaats van de feitelijke componenten. Deze dummy-objecten zijn de stub (functie genaamd) en driver (functie aanroep).

Stubs en stuurprogramma's

Voordat ik ga kort ingaan op Stubs en Drivers, moet ik eerst het verschil tussen componenttests en integratietests. De reden is: Stubs en stuurprogramma's worden ook gebruikt bij integratietests, dus dit kan tot verwarring leiden tussen deze twee testtechnieken.

Integratietesttechniek is een techniek waarbij we 2 componenten opeenvolgend combineren en het geïntegreerde systeem samen testen. Gegevens van het ene systeem worden doorgestuurd naar een ander systeem en de juistheid van de gegevens wordt gevalideerd voor het geïntegreerde systeem.

In tegenstelling tot moduletests waarbij de enkele component / module grondig wordt getest voordat deze met andere componenten wordt geïntegreerd. We kunnen dus zeggen dat het testen van componenten wordt uitgevoerd vóór integratietests.

Zowel integratie als componentgebruik Stubs en stuurprogramma's ​

'Bestuurders' zijn de dummy-programma's die worden gebruikt om de functies van de onderste module aan te roepen voor het geval de aanroepfunctie niet bestaat.

'Stubs' kan worden aangeduid als code een fragment dat de invoer / verzoeken van de bovenste module accepteert en de resultaten / respons retourneert

Zoals eerder uitgelegd, worden de componenten afzonderlijk en onafhankelijk getest. Er kunnen dus enkele kenmerken van de componenten zijn, afhankelijk van de andere component die momenteel niet is ontwikkeld. Dus om de componenten met deze 'onontwikkelde' eigenschappen te testen, moeten we enkele stimulerende middelen gebruiken die de gegevens zouden verwerken en terugsturen naar de oproepende componenten.

Op deze manier zorgen we ervoor dat de afzonderlijke componenten grondig worden getest.

de afzonderlijke componenten worden grondig getest

Hier zien we dat:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— zijn de componenten
  • C1, C2 en C3 vormen samen de subeenheid 1
  • C4 en C5 vormen samen de subeenheid 2
  • C6, C7 en C8 vormen samen de subeenheid 3
  • C9 alleen maakt de subeenheid 4
  • Subeenheid 1 en subeenheid 2 vormen samen bedrijfseenheid 1
  • Subunit 3 en subunit 4 vormen samen Business Unit 2
  • Business Unit 1 en Business Unit 2 combineren om de aanvraag te maken.
  • Het testen van de componenten in dit geval zou dus zijn om de afzonderlijke componenten te testen die C1 tot C9 zijn.
  • De Netto pijl tussen subeenheid 1 en subeenheid 2 toont het integratietestpunt.
  • Evenzo is het Netto pijl tussen subeenheid 3 en subeenheid 4 toont het integratietestpunt
  • De groene pijl tussen Business Unit 1 en Business Unit 2 geeft het integratietestpunt aan

Daarom zouden we doen:

  • COMPONENT testen voor C1 tot C9
  • INTEGRATIE testen tussen de Sub Units en Business Units
  • SYSTEEM testen van de applicatie als geheel

Een voorbeeld

Tot nu toe moeten we hebben vastgesteld dat Component testing dat wel is een soort white box-testtechniek ​Nou, misschien is het juist. Maar dit betekent niet dat deze techniek niet kan worden gebruikt in de Black box-testtechniek.

hoe u een swf-bestand uitvoert

Overweeg een enorme webtoepassing die begint met een inlogpagina. Als tester (ook dat in een agile wereld) konden we niet wachten tot de gehele applicatie ontwikkeld en testklaar gemaakt is. Om onze time-to-market te verlengen, moeten we vroeg beginnen met testen. Dus als we zien dat de aanmeldingspagina is ontwikkeld, moeten we erop staan ​​dat deze beschikbaar wordt gesteld om te testen.

Zodra u de aanmeldpagina beschikbaar heeft om te testen, kunt u al uw testgevallen uitvoeren (positief en negatief) om ervoor te zorgen dat de functionaliteit van de aanmeldingspagina werkt zoals verwacht.

De voordelen van het testen van uw inlogpagina op dit moment zijn:

wat is de beste dicteersoftware
  • UI is getest op bruikbaarheid (spelfouten, logo's, uitlijning, opmaak etc.)
  • Probeer te gebruiken negatieve testtechnieken zoals authenticatie en autorisatie. In deze gevallen is de kans groot dat er defecten worden gevonden.
  • Gebruik van technieken zoals SQL-injecties zou ervoor zorgen dat de inbreuk op de beveiliging in een zeer vroeg stadium wordt getest.

De defecten die u in deze fase zou registreren, zouden fungeren als 'geleerde lessen' voor het ontwikkelingsteam en deze zouden worden geïmplementeerd in de codering van de opeenvolgende pagina. Door vroeg te testen, hebt u dus gezorgd voor een betere kwaliteit van de pagina's die nog moeten worden ontwikkeld.

Omdat de andere opeenvolgende pagina's nog niet zijn ontwikkeld, hebt u mogelijk stubs nodig om de functionaliteit van de inlogpagina te valideren. Bijvoorbeeld ​misschien wilt u een eenvoudige pagina met de vermelding 'succesvol inloggen', in het geval van correcte inloggegevens en een pop-upvenster met foutmeldingen in geval van onjuiste inloggegevens.

U kunt onze eerdere tutorial over Integratietesten om meer inzichten te hebben over Stubs en Drivers.

Hoe componenttestcases schrijven?

De testcases voor het testen van componenten zijn afgeleid van werkproducten, bijvoorbeeld software-ontwerp of het datamodel. Elke component wordt getest door middel van een reeks testcases waarbij elke testcase een specifieke combinatie van input / output omvat, d.w.z. gedeeltelijke functionaliteit.

Hieronder ziet u een voorbeeldfragment van een componenttestcase voor Login Module.

We kunnen op dezelfde manier andere testcases schrijven.

testgevallen

Component testen versus unit testen

Het allereerste verschil tussen het testen van componenten en het testen van eenheden is dat de eerste wordt uitgevoerd door testers, terwijl de tweede wordt uitgevoerd door ontwikkelaars of SDET-professionals.

Het testen van eenheden wordt op gedetailleerd niveau uitgevoerd. Aan de andere kant wordt het testen van componenten gedaan op applicatieniveau. Bij het testen van eenheden wordt geverifieerd of een individueel programma of het stuk code wordt uitgevoerd volgens het gespecificeerde. Bij het testen van componenten wordt elk object van de software afzonderlijk getest met of zonder isolatie met andere componenten / object van het systeem.

Component testen lijkt dus veel op unit testing, maar het wordt gedaan op een hoger niveau van integratie en in de context van de applicatie (niet alleen in de context van die unit / programma zoals bij unit testing).

Component versus interface versus integratie versus systeemtesten

Component , zoals ik heb uitgelegd, is de laagste eenheid van een applicatie die onafhankelijk wordt getest.

Een koppel is de verbindingslaag van de 2 componenten. Het testen van het platform of de interface waarop de 2 componenten samenwerken, wordt interfacetesten genoemd.

Nu is het testen van de interface een beetje anders. Deze interfaces zijn meestal API's of webservices , dus het testen van deze interfaces zou niet vergelijkbaar zijn met de Black Box-techniek, maar u zou eerder een soort API-testen of Web Service-testen doen met SOAP-gebruikersinterface of een ander hulpmiddel.

Zodra de interfacetest is voltooid, komt het Integratietesten ​

Tijdens de integratietest combineren we de afzonderlijke geteste componenten één voor één en testen we deze stapsgewijs. We valideren tijdens de integratie dat de afzonderlijke componenten, wanneer ze één voor één worden gecombineerd, zich gedragen zoals verwacht en dat de gegevens niet worden gewijzigd wanneer ze van de ene module naar de andere gaan.

Zodra alle componenten zijn geïntegreerd en getest, wij voeren de Systemen testen om de gehele applicatie / systeem als geheel te testen. Deze test valideert de zakelijke vereisten ten opzichte van de geïmplementeerde software.

Gevolgtrekking

Dat zou ik zeggen Testen van een eenheid en het testen van componenten gebeurt naast elkaar.

In tegenstelling tot unit-testen die worden gedaan door het ontwikkelteam, wordt het testen van componenten / modules gedaan door het testteam. Het wordt altijd aanbevolen om een ​​doorlopende componenttest uit te voeren voordat u met de integratietest begint.

Als de Component-testen keihard zijn, zullen we minder defecten vinden in de integratietesten. Er zouden problemen zijn, maar die problemen zouden verband houden met de integratieomgeving of configuratie-uitdagingen. U kunt ervoor zorgen dat de functionaliteit van de geïntegreerde componenten goed werkt.

Ik hoop dat deze tutorial nuttig was om de component-, integratie- en systeemtests te begrijpen. Mocht u toch nog vragen hebben, stel deze dan gerust in opmerkingen.

Aanbevolen literatuur

^