Wat is componenttesten? Technieken, voorbeeldtestgevallen

Door: Thomas Hamilton Thomas Hamilton
Hours Bijgewerkt

⚡ Slimme samenvatting

Componenttesten controleren elk afzonderlijk onderdeel van een applicatie, zonder het te integreren met de rest, zodat defecten binnen een enkele module worden gevonden en verholpen voordat de assemblage begint.

  • 🧩 Domein: Eén component tegelijk, geïsoleerd van de componenten eromheen.
  • 👥 Bezitter: Testers voeren het uit nadat de ontwikkelaars de unit-tests hebben voltooid.
  • 🔬 CTIS: Componenttesten in kleine ruimtes isoleren het component volledig.
  • 🔗 CTIL: Componenttesten op grote schaal houden rekening met de afhankelijkheden, zowel reële als gesimuleerde.
  • 🧱 Doubles: Een driver roept de component aan; deze roept vervolgens een stub aan.
  • ✅ Exit: Er blijft geen enkel kritiek, ernstig of gemiddeld defect openstaan ​​in het logboek.
Meer informatie

Testtechnieken voor componenten en voorbeeldtestgevallen

Wat is componenttesten?

Component testen Dit is een type softwaretest waarbij elk afzonderlijk component apart wordt getest, zonder integratie met andere componenten. Vanuit architectuurperspectief wordt dit ook wel genoemd moduletestenEn sommige bronnen noemen het programmatesten.

Software als geheel bestaat uit verschillende componenten, en componenttesten richt zich op het individueel testen van die componenten. Het is een van de meest voorkomende testmethoden. black box testen typen die door het QA-team worden uitgevoerd.

Een opmerking over naamgeving is al vroeg op zijn plaats. De ISTQB-glossarium behandelt componenttesten en testen van een eenheid als synoniemen voor hetzelfde testniveau. Veel deliveryteams, en ook dit artikel, houden de twee in de praktijk gescheiden: ontwikkelaars voeren unit tests uit op hun eigen code, en testers voeren vervolgens component tests uit op de opgeleverde build. De vergelijkingstabel aan het einde van dit artikel laat dat praktische onderscheid zien.

Zoals het onderstaande diagram laat zien, heeft componenttesten een eigen teststrategie en testplan, waarbij elk onderdeel van de software of applicatie afzonderlijk wordt bekeken. Voor elke component een testscenario wordt gedefinieerd, wat vervolgens wordt opgesplitst in testgevallen op hoog niveau en uiteindelijk in gedetailleerde testgevallen op laag niveau. testgevallen met voorwaarden.

Hiërarchie van componenttesten, van teststrategie tot testgevallen op laag niveau.

De manier waarop de term 'componententesten' wordt gebruikt, verschilt per vakgebied en per organisatie. De drie meest voorkomende redenen voor dit verschil in perceptie zijn de volgende.

  1. Het gekozen type ontwikkelingslevenscyclusmodel
  2. De complexiteit van de te testen software of applicatie.
  3. Of het testen nu wel of niet geïsoleerd van de andere componenten in de applicatie wordt uitgevoerd.

De levenscyclus van softwaretesten genereert veel testartefacten, oftewel documenten die tijdens testactiviteiten worden aangemaakt en gebruikt. Hieronder vallen het testbeleid en de teststrategie, die bepalen welke soorten testen worden gebruikt en hoe diepgaand de testen in een bepaald project zijn.

Wie doet componenttesten?

Componenttesten worden uitgevoerd door testers. Unit-testen worden uitgevoerd door de ontwikkelaars, die een individuele functie of procedure testen. Zodra de unit-testen zijn afgerond, volgen de componenttesten, waarvoor de testers de verantwoordelijkheid dragen.

Wanneer moet u componenttesten uitvoeren?

Componenttesten worden uitgevoerd kort nadat de ontwikkelaars de unit-testen hebben afgerond en de build is vrijgegeven aan het testteam. Deze build wordt de UT-build, ofwel unit-testbuild, genoemd. In deze fase wordt de belangrijkste functionaliteit van elk component getest.

Toelatingscriteria voor het testen van componenten

  • De minimale set componenten die in de UT-build moeten worden opgenomen, is ontwikkeld en unit-getest.

Exitcriteria voor het testen van componenten

  • De functionaliteit van elk onderdeel werkt zoals gespecificeerd.
  • Er zijn geen kritieke, ernstige of middelzware defecten of defecten met een hoge prioriteit meer open in de defectenlogboek.

Testtechnieken voor componenten

Op basis van de diepte van het testniveau wordt componenttesten op twee manieren gecategoriseerd.

  1. CTIS — Componenttesten in het klein
  2. CTIL — Componenttesten in grote omgevingen

CTIS — Componenttesten in het klein

Componenttesten kunnen met of zonder isolatie van de andere componenten in de te testen applicatie worden uitgevoerd. Wanneer de testen met isolatie van de andere componenten worden uitgevoerd, spreekt men van componenttesten in kleine opstellingen.

Voorbeeld 1: Op een website met vijf verschillende webpagina's is het testen van elke webpagina afzonderlijk en geïsoleerd van de andere componenten een vorm van componenttesten in het klein.

Voorbeeld 2: De onderstaande homepage van guru99.com bevat veel onderdelen, zoals Home, Testen, SAPWeb, Must Learn!, Big Data, Live Projects en Blog.

Guru99 navigatiemenu's op de homepage worden behandeld als afzonderlijke, testbare componenten.

Software is op dezelfde manier opgebouwd uit vele componenten, en elke component heeft zijn eigen subcomponenten. Het afzonderlijk testen van elke module uit voorbeeld 2, zonder rekening te houden met de integratie met de andere componenten, is in feite componenttesten in het klein.

Als je het vervolgkeuzemenu 'Testen' opent, zie je de subonderdelen van de component 'Testen': Handmatig testen, SOAPUI, QTP, JUnit, Selenium, Testmanagement en Mobiel testenIn de onderstaande schermafbeelding zijn die subcomponenten rood gemarkeerd.

Het dropdownmenu wordt getest, waarbij de subonderdelen rood zijn gemarkeerd.

GERELATEERDE ARTIKELEN

CTIL — Componenttesten in grote omgevingen

Componenttesten die worden uitgevoerd zonder isolatie van de andere componenten in de te testen applicatie, worden componenttesten in grote lijnen genoemd.

Een voorbeeld maakt het verschil duidelijker. Stel dat een applicatie uit drie componenten bestaat: component A, component B en component C.

De ontwikkelaar heeft component B gebouwd en wil deze laten testen. Om component B volledig te testen, is een deel van de functionaliteit afhankelijk van component A en een deel van component C, zoals het onderstaande diagram illustreert.

Component B is getest met een driver ter vervanging van component A en een stub ter vervanging van component C.

De functionaliteitsstroom is A → B → C, wat betekent dat component B afhankelijk is van zowel A als C. In die stroom is de stub de aangeroepen functie en de driver de aanroepende functie.

Component A en Component C zijn nog niet ontwikkeld. Om Component B volledig te testen, worden A en C waar nodig vervangen door een driver en een stub, zodat de twee ontbrekende onderdelen als dummy-objecten fungeren totdat de echte onderdelen er zijn.

  • Stomp: Een stub wordt aangeroepen door het te testen component. Component C is nog niet gereed, dus een stub vervangt deze en retourneert de reacties die B verwacht.
  • Speaker: Een driver roept het te testen component aan. Component A is niet gereed, dus een driver neemt de rol over en roept B aan met de vereiste invoer.

Voorbeeldtestgevallen voor het testen van componenten

De twee onderstaande webpagina's zijn functioneel met elkaar verbonden, waardoor ze een nuttig paar componenten vormen om te testen.

Webpagina 1 is de inlogpagina van de demo-bankwebsite.

Inlogpagina-component met velden voor gebruikersnaam en wachtwoord

Wanneer de gebruiker een geldige gebruikersnaam en wachtwoord invoert en op de verzendknop klikt, wordt de pagina doorgestuurd naar de homepage van de demo-bankwebsite, die hiernaast wordt weergegeven.

Beheerder startpagina-component met navigatielinks en afbeeldingen

De inlogpagina is hier één component en de homepage een andere. Het afzonderlijk testen van de functionaliteit van elke pagina noemen we componenttesten.

Testscenario's voor componenten op webpagina 1:

  • Voer een ongeldige gebruikers-ID in en controleer of er een gebruiksvriendelijke waarschuwing aan de eindgebruiker wordt getoond.
  • Voer een ongeldige gebruikersnaam en wachtwoord in, klik op 'Reset' en controleer of de velden voor gebruikersnaam en wachtwoord zijn leeggehaald.
  • Voer een geldige gebruikersnaam en wachtwoord in en klik op de knop 'Inloggen'.

Testscenario's voor componenten op webpagina 2:

  • Controleer of het welkomstbericht voor de beheerderspagina op de startpagina wordt weergegeven.
  • Controleer of alle links aan de linkerkant van de webpagina aanklikbaar zijn.
  • Controleer of de manager-ID in het midden van de homepage wordt weergegeven.
  • Controleer of de drie verschillende afbeeldingen op de homepage aanwezig zijn, zoals weergegeven in het diagram.

Het testen van eenheden versus het testen van componenten

Onderstaande tabel geeft een overzicht van de verschillen tussen de twee niveaus in de dagelijkse praktijk.

Testen van een eenheid Component testen
Het testen van individuele programma's en modules om aan te tonen dat het programma volgens de specificaties werkt. Het afzonderlijk testen van elk object of onderdeel van de software, met of zonder isolatie van andere objecten.
Gevalideerd aan de hand van ontwerpdocumenten. Gevalideerd aan de hand van testvereisten en gebruiksscenario's.
Gemaakt door ontwikkelaars. Uitgevoerd door testers.
Eerst gedaan. Dit wordt gedaan nadat de unit-tests door de ontwikkelaars zijn afgerond.
Defecten worden meestal ter plekke verholpen en niet formeel geregistreerd. Defecten worden geregistreerd en tracked via het defectbeheerproces.

Veelgestelde vragen

Het risico verlagen, het functionele en niet-functionele gedrag van het onderdeel verifiëren, vertrouwen in de kwaliteit ervan opbouwen, defecten opsporen en voorkomen dat deze defecten zich verder verspreiden.ping naar hogere testniveaus.

Modellen lezen een component contracen stelt de ongeldige invoerwaarden, grenswaarden en foutpaden voor die bij een handmatige controle vaak over het hoofd worden gezien. Een tester bevestigt nog steeds elk verwacht resultaat vóór de uitvoering.

Ja. Een stub die voorgeprogrammeerde antwoorden teruggeeft en een driver die vaste invoer levert, vormen een gestandaardiseerde code die een assistent snel schrijft. Beslissen welke antwoorden realistisch zijn, blijft een menselijke beslissing.

Componenttesten onderzoeken één component afzonderlijk. integratie testen Het analyseert de interfaces en interacties tussen componenten en wordt uitgevoerd na het testen van de componenten.

Code-niveau frameworks zoals JUnit, TestNGNUnit en pytest, plus UI-componentrunners zoals Cypress Componenttesten, Storybook en Jest. Ze passen allemaal in een automatisering pijpleiding.

Het bouwen en onderhouden van de duplicaten. Een placeholder die afwijkt van het echte component verbergt defecten tot de integratie, dus elke gesimuleerde respons moet opnieuw worden bekeken zodra de echte afhankelijkheid is uitgebracht.

Het draait de volgorde om. Testcases worden geschreven en geautomatiseerd voordat het component bestaat, waarna code wordt toegevoegd totdat ze slagen. Het component wordt geleverd met de bijbehorende testsuite al geïnstalleerd.

Beide, afhankelijk van wie het uitvoert. Testers werken in een black box-omgeving met de componentspecificatie, terwijl ontwikkelaars met toegang tot de code de componenten toepassen. witte doos dekking binnen hetzelfde component.

Vat dit bericht samen met: