white box testing complete guide with techniques
Wat is White Box-testen?
Als we de definitie volgen, is 'White box testing' (ook bekend als clear, glass box of structureel testen) een testtechniek die de code en de interne structuur van een programma evalueert.
Bij het testen van de witte doos wordt gekeken naar de structuur van de code. Als u de interne structuur van een product kent, kunnen tests worden uitgevoerd om ervoor te zorgen dat de interne bewerkingen volgens de specificatie hebben uitgevoerd. En alle interne componenten zijn voldoende uitgeoefend.
Wat je leert:
- Mijn ervaring
- Verschil tussen White-Box- en Black-Box-testen
- Stappen om WBT uit te voeren
- Typen en technieken van White Box-testen
- White Box-testvoorbeeld
- White Box-testtools
- Gevolgtrekking
- Aanbevolen literatuur
Mijn ervaring
Het is nu bijna een decennium geleden dat ik me met het testen van software bezighoud en tot dusver heb gemerkt dat de testers het meest enthousiast zijn in de hele software-industrie.
De belangrijkste reden hierachter is: de tester heeft altijd iets in zijn bereik om te leren. Of het nu gaat om een domein, proces of technologie, een tester kan desgewenst een volledige ontwikkeling doormaken.
Maar zoals ze zeggen 'Er is altijd een donkere kant'
Testers vermijden inderdaad ook een soort testen die volgens hen erg ingewikkeld is en het is een fluitje van een cent voor de ontwikkelaar. Ja, de 'White Box Testing'.
Dekking
White Box Testing omvat de specificatie in de code:
1. Code dekking
2. Segmentdekking: Zorg ervoor dat elke code-instructie één keer wordt uitgevoerd.
3. Aftakkingsdekking of knooppunttest: De dekking van elke codetak van alle mogelijke was.
4. Dekking van samengestelde condities: Test voor meerdere condities elke conditie met meerdere paden en een combinatie van de verschillende paden om die conditie te bereiken.
5. Basispadtesten: Elk onafhankelijk pad in de code wordt gebruikt om te testen.
6. Data Flow Testing (DFT): In deze benadering volgt u de specifieke variabelen via elke mogelijke berekening, waardoor de set van tussenliggende paden door de code wordt gedefinieerd. DFT heeft de neiging om afhankelijkheden weer te geven, maar het is voornamelijk door reeksen van gegevensmanipulatie. Kortom, elke gegevensvariabele wordt bijgehouden en het gebruik ervan wordt geverifieerd. Deze benadering heeft de neiging om bugs aan het licht te brengen, zoals variabelen die worden gebruikt maar niet worden geïnitialiseerd, of gedeclareerd maar niet worden gebruikt, enzovoort.
7. Pad testen: Bij padtests worden alle mogelijke paden door de code gedefinieerd en afgedekt. Het is een tijdrovende klus.
8. Loop testen: Deze strategieën hebben betrekking op het testen van enkele lussen, aaneengeschakelde lussen en geneste lussen. Met deze benadering worden onafhankelijke en afhankelijke codelussen en waarden getest.
Waarom voeren we WBT uit?
Verzekeren:
- Dat alle onafhankelijke paden binnen een module minimaal één keer zijn uitgeoefend.
- Alle logische beslissingen geverifieerd op hun ware en valse waarden.
- Alle loops worden uitgevoerd op hun grenzen en binnen hun operationele grenzen, interne datastructuren validiteit.
Om de volgende soorten bugs te ontdekken:
- Logische fouten sluipen vaak in ons werk wanneer we functies, voorwaarden of bedieningselementen ontwerpen en implementeren die buiten het programma vallen
- De ontwerpfouten als gevolg van verschil tussen logische stroom van het programma en de daadwerkelijke implementatie
- Typografische fouten en syntaxiscontrole
Vereist dit testen gedetailleerde programmeervaardigheden?
We moeten schrijven testgevallen die de volledige dekking van de programmalogica garanderen.
Hiervoor moeten we het programma goed kennen, d.w.z. we moeten de specificatie en de te testen code kennen. Kennis van programmeertalen en logica is vereist voor dit type testen.
Beperkingen
Het is niet mogelijk om elk pad van de loops in het programma te testen. Dit betekent dat uitgebreide tests onmogelijk zijn voor grote systemen.
Dit betekent niet dat WBT niet effectief is. Door belangrijke logische paden en datastructuren te selecteren voor testen is dit praktisch mogelijk en effectief.
Verschil tussen White-Box- en Black-Box-testen
Om het simpel te zeggen:
Bij Black Box-testen testen we de software vanuit het oogpunt van de gebruiker, maar in White Box zien en testen we de daadwerkelijke code.
Bij Black box testing voeren we tests uit zonder de interne systeemcode te zien, maar bij WBT zien en testen we de interne code wel.
White box-testtechniek wordt zowel door de ontwikkelaars als door testers gebruikt. Het helpt hen te begrijpen welke regel code daadwerkelijk wordt uitgevoerd en welke niet. Dit kan erop duiden dat er ofwel een ontbrekende logica of een typefout is, wat uiteindelijk tot enkele negatieve gevolgen kan leiden.
Aanbevolen lezen => Een complete gids voor Black Box-testen
Stappen om WBT uit te voeren
Stap 1 - Begrijp de functionaliteit van een applicatie via de broncode. Wat betekent dat een tester goed thuis moet zijn in de programmeertaal en de andere tools, evenals de technieken die worden gebruikt om de software te ontwikkelen.
Stap 2 - Maak de tests en voer ze uit.
Als we het concept van testen bespreken, ' Dekking ”Wordt beschouwd als de belangrijkste factor. Hier zal ik uitleggen hoe u maximale dekking krijgt vanuit de context van White box-testen.
Lees ook Oorzaak en gevolg-grafiek - Dynamische testcase-schrijftechniek voor maximale dekking
Typen en technieken van White Box-testen
Er zijn verschillende typen en verschillende methoden voor elk type white box-test.
Zie de onderstaande afbeelding voor uw referentie.
Vandaag gaan we ons vooral richten op de uitvoeringstesten van ‘Unit testing white box-techniek’.
3 belangrijkste White Box-testtechnieken:
- Verklaring dekking
- Branch dekking
- Paddekking
Merk op dat de verklaring, branch of paddekking geen bug of defect identificeert die moeten worden verholpen. Het identificeert alleen die regels code die ofwel nooit worden uitgevoerd of onaangeroerd blijven. Op basis hiervan kan verder worden getest.
Laten we deze technieken een voor een bekijken met een eenvoudig voorbeeld.
# 1) Dekking van de verklaring:
In een programmeertaal is een statement niets anders dan de regel code of instructie die de computer moet begrijpen en ernaar moet handelen. Een instructie wordt een uitvoerbare instructie wanneer deze wordt gecompileerd en geconverteerd naar de objectcode en de actie uitvoert wanneer het programma in actieve modus is.
Vandaar 'Statement Coverage' , zoals de naam zelf suggereert, is het de methode om te valideren of elke regel van de code minstens één keer wordt uitgevoerd.
# 2) Dekking van filialen:
'Branch' in een programmeertaal is als de 'IF statements'. Een IF-instructie heeft twee takken: T rue en False
Dus in Branch-dekking (ook wel Decision-dekking genoemd) valideren we of elke branch minstens één keer wordt uitgevoerd.
In het geval van een 'IF statement' zijn er twee testcondities:
- Een om de ware branch te valideren en,
- Other om de false branch te valideren.
Vandaar dat Branch Coverage in theorie een testmethode is die, wanneer uitgevoerd, ervoor zorgt dat elke branch van elk beslissingspunt wordt uitgevoerd.
# 3) Paddekking
Paddekking test alle paden van het programma. Dit is een uitgebreide techniek die ervoor zorgt dat alle paden van het programma minstens één keer worden doorlopen. Path Coverage is zelfs krachtiger dan Branch-dekking. Deze techniek is handig voor het testen van de complexe programma's.
Laten we een eenvoudig voorbeeld nemen om al deze white box-testtechnieken te begrijpen.
youtube naar mp4 converter-app voor Android
Controleer ook Verschillende soorten testen
White Box-testvoorbeeld
Beschouw de onderstaande eenvoudige pseudocode:
Voor Verklaring dekking - we hebben maar één testcase nodig om alle regels van de code te controleren.
Dat betekent:
Als ik erover nadenk TestCase_01 te zijn (A = 40 en B = 70), dan worden alle regels code uitgevoerd.
Nu rijst de vraag:
- Is dat voldoende?
- Wat moet ik doen als ik mijn testgeval beschouw als A = 33 en B = 45?
Omdat Statement-dekking alleen de ware kant dekt, zou voor de pseudocode slechts één testcase NIET voldoende zijn om deze te testen. Als tester moeten we ook rekening houden met de negatieve gevallen.
Daarom moeten we voor een maximale dekking overwegen Branch dekking , die de 'FALSE' voorwaarden zal evalueren.
In de echte wereld kunt u passende uitspraken toevoegen als de voorwaarde mislukt.
Dus nu wordt de pseudocode:
Omdat de dekking van de verklaring niet voldoende is om de volledige pseudocode te testen, hebben we Branch-dekking nodig om maximale dekking te garanderen
Dus voor Branch-dekking zouden we twee testcases nodig hebben om het testen van deze pseudocode te voltooien.
TestCase_01 : A = 33, B = 45
TestCase_02 : A = 25, B = 30
Hiermee kunnen we zien dat elke regel van de code minstens één keer wordt uitgevoerd.
Hier zijn de conclusies die tot nu toe zijn afgeleid:
- Branch Coverage zorgt voor meer dekking dan Statement-dekking.
- De dekking van een bijkantoor is krachtiger dan de dekking van verklaringen.
- 100% dekking van het filiaal zelf betekent 100% dekking van het overzicht.
- Maar 100% dekking van de verklaring garandeert geen 100% dekking van het filiaal.
Laten we nu verder gaan Paddekking:
Zoals eerder gezegd, wordt Path-dekking gebruikt om de complexe codefragmenten te testen, die in feite lusinstructies of een combinatie van lussen en beslissingsinstructies omvatten.
Beschouw deze pseudocode:
Om een maximale dekking te garanderen, zouden we 4 testcases nodig hebben.
Hoe? Simpel gezegd - er zijn twee beslissingsverklaringen, dus voor elke beslissingsverklaring hebben we twee takken nodig om te testen. De ene voor waar en de andere voor de valse toestand. Dus voor 2 beslissingsverklaringen zouden we 2 testgevallen nodig hebben om de ware kant te testen en 2 testgevallen om de valse kant te testen, wat in totaal 4 testgevallen oplevert.
Laten we, om deze te vereenvoudigen, het onderstaande stroomschema bekijken van de pseudocode die we hebben:
Om de volledige dekking te hebben, hebben we de volgende testcases nodig:
wat is de beste mp3-downloader
TestCase_01: A = 50, B = 60
TestCase_02 : A = 55, B = 40
TestCase_03: A = 40, B = 65
TestCase_04: A = 30, B = 30
Dus het afgelegde pad zal zijn:
Rode lijn - TestCase_01 = (A = 50, B = 60)
Blauwe lijn = TestCase_02 = (A = 55, B = 40)
Oranje lijn = TestCase_03 = (A = 40, B = 65)
Groene lijn = TestCase_04 = (A = 30, B = 30)
Neem contact op om uw vermelding hier voor te stellen
White Box-testtools
Hieronder vindt u een lijst met de beste testtools voor de witte doos.
#1) Veracode
De white box-testtools van Veracode helpen u bij het snel en eenvoudig identificeren en oplossen van softwarefouten tegen lagere kosten. Het ondersteunt verschillende applicatietalen zoals .NET, C ++, JAVA enz. En stelt u ook in staat om de beveiliging van desktop-, web- en mobiele applicaties te testen. Toch zijn er verschillende andere voordelen van de Veracode-tool. Raadpleeg de onderstaande link voor gedetailleerde informatie over de testtools van Veracode White Box.
Website link Veracode
# 2) EclEmma
EclEmma is in eerste instantie ontworpen voor testruns en analyse binnen de Eclipse-werkbank. Het wordt beschouwd als een gratis hulpmiddel voor Java-codedekking en heeft ook verschillende functies. Raadpleeg de onderstaande link om EclEmma te installeren of er meer over te weten.
Website link: EclEmma
# 3) RCUNIT
Een raamwerk dat wordt gebruikt voor het testen van C-programma's staat bekend als RCUNIT. RCUNIT kan dienovereenkomstig worden gebruikt op basis van de voorwaarden van de MIT-licentie. Het is gratis te gebruiken en om het te installeren of er meer over te weten, kijk op de onderstaande link.
Website link: RCUNIT
# 4) cfix
cfix is een van de unit testing frameworks voor C / C ++ dat er uitsluitend op gericht is de ontwikkeling van testsuites zo eenvoudig en gemakkelijk mogelijk te maken. Ondertussen is cfix meestal gespecialiseerd voor NT-kernelmodus en Win32. Om cfix te installeren en meer te weten, kijk op de onderstaande link
Website link: cfix
# 5) Google-test
Googletest is het C ++ -testframework van Google. Test Discovery, Death tests, Value-parameterized tests, fatale en niet-fatale fouten, XML-testrapporten genereren, enz. Zijn enkele functies van GoogleTest, maar er zijn ook verschillende andere functies. Linux, Windows, Symbian, Mac OS X zijn enkele platforms waarop GoogleTest is gebruikt. Om teDownload, kijk dan op de onderstaande link.
Download link: Google-test
# 6) EMMA
Emma is een gebruiksvriendelijke gratis tool voor JAVA-codedekking. Het bevat verschillende functies en voordelen. Bekijk de onderstaande link om meer te weten te komen over Emma.
Download link: EMMA
# 7) NUnit
NUnit is een eenvoudig te gebruiken open source unit-testraamwerk dat geen handmatige tussenkomst vereist om de testresultaten te beoordelen. Het ondersteunt alle .NET-talen. Het ondersteunt ook datagestuurde tests en tests die parallel worden uitgevoerd onder NUnit. Eerdere releases van NUnit gebruikten de NUnit-licentie, maar NUnit 3 wordt vrijgegeven onder de MIT-licentie. Maar beide licenties laten gratis gebruik toe zonder enige beperking. Om te downloaden en meer te weten over NUnit, kijk dan op de onderstaande link.
Download link: NUnit
# 8) CppUnit
CppUnit is een framework voor het testen van eenheden geschreven in C ++ en wordt beschouwd als de poort van JUnit. De testuitvoer voor CppUnit kan in XML- of tekstformaat zijn. Het maakt unit-tests met zijn eigen klasse en voert tests uit in de testsuites. Het is gelicentieerd onder LGPL. Om CppUnit te downloaden en meer te weten te komen, kijk op de onderstaande link.
Download link: CppUnit
# 9) JUnit
JUnit is een rustig, eenvoudig framework voor het testen van eenheden dat testautomatisering in Java-programmeertaal ondersteunt. Het ondersteunt voornamelijk bij Test Driven Development en biedt ook het testdekkingsrapport. Het is gelicentieerd onder Eclipse Public License. Voor gratis download en om meer te weten over JUnit, kijk op de onderstaande link.
Download link: JUnit
# 10) JsUnit
JsUnit wordt beschouwd als de poort van JUnit naar javascript. En het is een open source testraamwerk voor eenheden om Javascript aan de klantzijde te ondersteunen. Het is gelicentieerd onder GNU Public License 2.0, GNU Lesser Public License 2.1 en Mozilla Public License 1.1. Om JsUnit te downloaden en meer te weten te komen, kijk op de onderstaande link.
Download link: JsUnit
Controleer ook alle tools die we hieronder hebben vermeld Statische code-analyse hier
Voel je vrij om meer eenvoudige of geavanceerde tools voor te stellen die je gebruikt voor de white box-techniek.
Gevolgtrekking
Alleen vertrouwen op black box-testen is niet voldoende voor een maximale testdekking. We hebben een combinatie van zowel black box- als white box-testtechnieken nodig dekking van maximale defecten
Als het goed wordt gedaan, zal White box-testen zeker bijdragen aan de softwarekwaliteit. Het is ook goed voor testers om aan deze tests deel te nemen, omdat dit de meest ‘onbevooroordeelde’ mening over de code kan geven.
Laat het ons weten als u vragen heeft over de methoden die we in dit artikel hebben besproken.
Aanbevolen literatuur
- Belangrijkste verschillen tussen Black Box-tests en White Box-tests
- Black Box-tests: een diepgaande zelfstudie met voorbeelden en technieken
- Functioneel testen versus niet-functioneel testen
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Out of the box denken tijdens het testen van software!
- Gids voor het testen van draagbaarheid met praktische voorbeelden
- Alfatesten en bètatesten (een complete gids)
- Soorten softwaretests: verschillende testtypen met details