what is incremental testing
Met behulp van dit artikel ga ik een van de belangrijke integratiemethoden behandelen: incrementeel testen.
Aan het einde van dit gedeelte heeft het publiek een behoorlijke kennis van het volgende:
- Wat is incrementeel testen?
- Zijn doel
- Methodologieën
- Voordelen
- Nadelen
Wat je leert:
- Wat is incrementeel testen
Wat is incrementeel testen
Incrementeel testen, ook wel bekend als incrementele integratietesten, is een van de benaderingen van integratietesten en omvat de fundamentele concepten ervan.
Het is als een test die module en integratie combineert teststrategie
Bij deze tests testen we elke module afzonderlijk in de testfase van de eenheid, en vervolgens worden de modules incrementeel geïntegreerd en getest om een soepele interface en interactie tussen modules te garanderen.
In deze benadering wordt elke module incrementeel gecombineerd, d.w.z. één voor één totdat alle modules of componenten logisch zijn toegevoegd om de vereiste toepassing te maken, in plaats van het hele systeem in één keer te integreren en vervolgens het eindproduct te testen. Geïntegreerde modules worden als een groep getest om een succesvolle integratie en gegevensstroom tussen modules te garanderen.
Net als bij integratietests, is de primaire focus van het uitvoeren van deze tests het controleren van de interface, geïntegreerde koppelingen en de informatiestroom tussen modules. Dit proces wordt herhaald totdat de modules met succes zijn gecombineerd en getest.
Voorbeeld
Laten we dit concept begrijpen met een voorbeeld:
Systeem- of softwareapplicatie bestaat uit de volgende modules:
Aanpak voor incrementele integratietests
- Elke module, d.w.z. M1, M2, M3, enz., Wordt afzonderlijk getest als onderdeel van het testen van eenheden
- Modules worden stapsgewijs gecombineerd, d.w.z. één voor één, en getest op succesvolle interactie
- In Fig2 worden module M1 en module M2 gecombineerd en getest
- In Fig3 is Module M3 toegevoegd en getest
- In Fig4 is Module M4 toegevoegd en wordt er getest om er zeker van te zijn dat alles succesvol samenwerkt
- De rest van de modules worden ook stapsgewijs toegevoegd bij elke stap en getest op succesvolle integratie
Figuur 2
Afb3
hoe je een java-project bouwt in eclipse
Afb4
Doelstelling van incrementele test
- Om ervoor te zorgen dat verschillende modules na integratie succesvol samenwerken
- Identificeer de defecten eerder en in elke fase. Dit geeft ontwikkelaars een voorsprong om te identificeren waar het probleem zit. Alsof het testen nadat M1 en M2 zijn geïntegreerd succesvol is, maar wanneer M3 wordt toegevoegd, mislukt de test; dit zal de ontwikkelaar helpen bij het scheiden van het probleem
- Problemen kunnen in een vroege fase worden opgelost zonder veel nabewerking en tegen lagere kosten
Methodologieën voor het testen van incrementele integratie
Voordat we met dit onderwerp beginnen, wil ik er een korte introductie over geven Stubs en stuurprogramma's aangezien we deze termen vaak zullen gebruiken.
Stubs en stuurprogramma's zijn pseudocode of dummy-code die wordt gebruikt in Integration of component testen wanneer een of meer modules niet zijn ontwikkeld, maar vereist zijn om een andere module te testen.
Stompjes worden gebruikt in de Top-down-testbenadering en staan bekend als 'zogenaamde programma's'. Stubs helpen bij het simuleren van de interface tussen lagere hefboommodules die niet beschikbaar of ontwikkeld zijn.
Bestuurders worden gebruikt in de bottom-up testbenadering en staan bekend als 'aanroepende programma's'. Drivers helpen bij het simuleren van de interface tussen modules op het hoogste niveau die niet ontwikkeld of beschikbaar zijn.
Een vraag die bij sommigen van ons kan opkomen, is waarom niet wachten tot alle applicatiemodules zijn ontwikkeld in plaats van stub / driver te gebruiken voordat u begint met testen?
Het simpele antwoord is dat het de projectuitvoeringstijd verlengt, aangezien testers inactief zullen blijven totdat alle modules zijn ontwikkeld. Dit maakt ook de wortelanalyse van defecten moeilijk. Dit type testaanpak staat bekend als Big-Bang Integration-testen.
Nu we Stubs en stuurprogramma's hebben behandeld, gaan we verder met verschillende methodologieën van incrementeel testen:
# 1) Van boven naar beneden
Zoals de naam al doet vermoeden, vindt het testen plaats van boven naar beneden, dus van de centrale module naar de submodule. Modules die de bovenste applicatielaag omkaderen, worden eerst getest.
Deze benadering volgt de structurele stroom van de te testen applicatie. Niet beschikbare of niet ontwikkelde modules of componenten worden vervangen door stubs.
Laten we dit begrijpen met een voorbeeld:
- Module : Website Login ook bekend als L
- Module : Bestel aka O
- Module Order Summary aka OS (nog niet ontwikkeld)
- Module : Betaling aka P
- Module contante betaling ook bekend als CP
- Module Debet / Credit Payment aka DP (nog niet ontwikkeld)
- Module Wallet Payment aka WP (nog niet ontwikkeld)
- Module: Rapportage aka R (nog niet ontwikkeld)
Top-down incrementele integratietestaanpak
Volgende testcases worden afgeleid:
hoeveel kost het verkooppunt van quickbooks
Testgeval1: Module L en Module O worden geïntegreerd en getest
Testgeval2: Module L, O en P worden geïntegreerd en getest
Testgeval3: Module L, O, P en R worden geïntegreerd en getest.
En zo worden andere testgevallen afgeleid.
Dit type testen waarbij alle modules op een laag eerst worden geïntegreerd en getest, staat bekend als 'breedte eerst'. Een andere categorie is 'diepte eerst'.
De volgende testcases worden afgeleid voor 'depth-first':
Testgeval1: Module L en Module O worden geïntegreerd en getest
Testgeval2: Module L, O en OS worden geïntegreerd en getest
Testgeval3: Module L, O, OS, P wordt geïntegreerd en getest
Testgeval4: Module L, O, OS, P, CP worden geïntegreerd en getest
En zo worden andere testgevallen afgeleid.
Verdiensten van top-down methodologie
- Vroegtijdige blootstelling van architectuurdefecten
- Het schetst de werking van een applicatie als geheel in vroege stadia en helpt bij het vroegtijdig onthullen van ontwerpfouten
- De belangrijkste controlepunten worden vroeg getest
De-verdiensten van top-down methodologie
- Significante modules worden laat in de cyclus getest
- Het is erg uitdagend om testvoorwaarden te schrijven
- Een stomp is geen perfecte implementatie van een gerelateerde module. Het simuleert gewoon de gegevensstroom tussen twee modules
# 2) Bottom-up
In deze benadering vindt het testen plaats van onder naar boven, d.w.z. modules op de onderste laag worden eerst geïntegreerd en getest en vervolgens worden achtereenvolgens andere modules geïntegreerd naarmate we hoger komen. Niet beschikbare of niet ontwikkelde modules worden vervangen door stuurprogramma's.
Laten we eens kijken naar een hieronder genoemd voorbeeld voor een beter begrip:
Modules Rank, Marks, Percentage en Sports Grade zijn nog niet ontwikkeld, dus ze zullen worden vervangen door gerelateerde coureurs:
Bottom-up incrementele integratietestaanpak
Volgende testcases worden afgeleid:
Testgeval1: Unit testen van module Praktisch en Theorie
Testgeval2: Integratie en toetsing van Modules Marks-Practical-theorie
Testgeval 3 : Integratie en testen van modules Percentage-Cijfers-Praktische-Theorie
Testgeval4: Unit testen van Module Sports Grade
Testgeval5: Integratie en testen van modules Rank-Sports Grade-Percentage-Cijfers-Practical-Theory
Verdiensten van bottom-up methodologie
- Deze methodologie is erg handig voor toepassingen waarbij een bottom-up ontwerpmodel wordt gebruikt
- Het is gemakkelijker om testomstandigheden te creëren in een bottom-upbenadering
- Om te beginnen met testen op het onderste niveau van de hiërarchie, moet u in een vroeg stadium kritische modules of functionaliteit testen. Dit helpt bij het vroegtijdig ontdekken van fouten
- Interface-defecten worden in een vroeg stadium gedetecteerd
De-verdiensten van bottom-up methodologie
- Bestuurders zijn moeilijker te schrijven dan stomp
- Ontwerpfouten worden in een later stadium opgevangen
- In deze benadering hebben we geen werkende applicatie totdat de laatste module is gebouwd
- Driver is geen volledige implementatie van gerelateerde module. Het simuleert gewoon de gegevensstroom tussen twee modules.
# 3) Sandwich-testen
Deze benadering is een hybride van top-down en bottom-up methodologie. Stub en stuurprogramma's worden gebruikt voor onvolledige of niet ontwikkelde modules.
Testbenadering
- Een middelste laag wordt geïdentificeerd van waaruit bottom-up en top-down testen worden gedaan. Deze middelste laag wordt ook wel targetlaag genoemd
- De doellaag wordt geïdentificeerd volgens de heuristische benadering, d.w.z. selecteer een laag die minimaal gebruik van stubs en stuurprogramma's mogelijk maakt
- Top-down testen begint vanaf de middelste laag en gaat naar beneden naar modules op een lager niveau. Deze laag onder de middelste laag staat bekend als de onderste laag
- Bottom-up testen begint ook vanaf de middelste laag en gaat omhoog naar de bovenste laagmodules. Deze laag boven de middelste laag staat bekend als Toplaag
- Met gebruik van stubs en stuurprogramma's worden respectievelijk gebruikersinterface en functies van modules op een lager niveau getest
- Uiteindelijk blijft alleen de middelste laag over voor de uitvoering van de eindtest
Voorbeeld:
De volgende testcases kunnen worden afgeleid met Sandwich Testing Strategy:
Testgeval1: Test A, X, Y en Z afzonderlijk - waarbij Test A onder Toplaagtest valt en Test X, Y en Z onder Onderlaagtesten
Testgeval2: Test A, G, H en I.
Testgeval3: Test G, X en Y
Testgeval4: Test hand Z
Testgeval5: Test A, G, H, I, X, Y en Z
Verdiensten van sandwich-testmethodologie
- Het is erg voordelig voor een groot project met verschillende deelprojecten
- Top-down en bottom-up testmethodologieën kunnen naast elkaar worden gebruikt
De-verdiensten van Sandwich Testing Methodology
- Vóór de unificatie van modules worden subsystemen en hun interfaces niet grondig getest
- Hogere kosten door betrokkenheid van zowel top-down als bottom-up testmethodologie
- Dit type testen wordt niet aanbevolen voor een systeem waarin modules sterk van elkaar afhankelijk zijn
Gevolgtrekking
Incrementeel testen valt onder de deken van integratietesten. Bij deze benadering van testen worden integratietests uitgevoerd op de individuele module als onderdeel van het testen van eenheden en in de volgende fase worden modules of componenten van de applicatie incrementeel geïntegreerd en worden testen uitgevoerd op gecombineerde modules als een groep.
Van de drie methodologieën van incrementele integratietests hangt de keuze van de te kiezen methodologie af van de structuur van de applicatie en ook van de positie van risicovolle modules.
Alle drie de methodologieën voor incrementeel testen vallen onder de categorie Horizontaal vanwege de volgende gedragsaspecten:
- Alle drie de methodologieën zijn gericht op het testen van lagen
- Ze beschouwen allemaal een structureel of hiërarchisch ontwerp
- Ze integreren allemaal incrementeel lagen
Verdiensten:
Met deze testaanpak is het gemakkelijker om defecten vroegtijdig op te sporen, en het helpt de ontwikkelaar ook om de oorzaak van het probleem te achterhalen. Omdat het de basis van gestructureerd testen gebruikt, is deze testaanpak zeer effectief en nauwkeurig.
Gebreken:
Dit type testaanpak is tijdrovend vanwege het gebruik van stubs en stuurprogramma's. Het is ook repetitief.
Over de auteur: Deze handige tutorial is geschreven door Neha B. Ze is ISTQB-gecertificeerde Lead Quality Analyst met 8+ jaar ervaring.
Laat het ons weten als u vragen / suggesties heeft.
Aanbevolen literatuur
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Wat is componenttesten of moduletesten (leer met voorbeelden)
- Primer eBook downloaden testen
- Functioneel testen versus niet-functioneel testen
- Wat is duurtesten bij softwaretests (voorbeelden)
- Zelfstudie over paarsgewijs testen of testen in alle paren met tools en voorbeelden
- Soorten softwaretests: verschillende testtypen met details
- Zelfstudie voor het testen van volumes: voorbeelden en tools voor het testen van volumes