Inleiding tot het testen van witte dozen

Testen is een van de belangrijke onderdelen van softwareontwikkeling, het zorgt ervoor dat alle bugs worden opgelost en dat het programma werkt zoals het ook bedoeld was. Het testen van een softwareproduct kan meerdere stappen en meerdere procedures hebben. In dit artikel gaan we een kijkje nemen op een van de belangrijke benaderingen van het testproces, de White Box Testing.

Wat is White Box-testen?

White box testing wordt ook code base testing, clear box testing, open box testing en structurele testing genoemd. Het kernidee van deze benadering van het testen van software is het bekijken van het interne structuurontwerp en de code van het programma om het te testen.

In White box-testen kan de tester de volledige code van het programma zien en moet hij de stroom controleren van de manier waarop invoer en uitvoer in het programma werken. In tegenstelling tot black box-testen, die meer gericht zijn op het testen van de functionaliteit van het programma, houdt White Box-testen zich bezig met het testen van de interne structuren van het programma. Als we op deze manier naar het programma kijken, kunnen we werken aan het verbeteren van het ontwerp, de bruikbaarheid en het veiliger maken van het product.

Zoals je kunt raden, noemde het witte doos of glazen doos testen omdat de tester de code en andere delen van het programma kan zien.

Wat maakt White Box Testing anders dan Black Box Testing

Als je in het verleden met je tenen hebt geklopt, weet ik zeker dat je Black Box Testing bent tegengekomen. Het grootste verschil tussen White Box-testen en Black Box-testen is dat, in tegenstelling tot Black Box-testen, die wordt gedaan vanuit het oogpunt van een gebruiker, White Box-testen wordt gedaan vanuit het perspectief van een ontwikkelaar.

Met andere woorden, in plaats van het programma van buitenaf te bekijken, ziet de benadering van White Box Testing de interne code en test deze.

Hoe wordt White Box Testing uitgevoerd?

We kunnen het proces van White Box Testing in twee grote stappen verdelen.

1. Inzicht in de verstrekte code

In eerste instantie moet een tester in White Box Testing de code van de applicatie leren. Gezien het feit dat White Box-testen draait om het begrijpen en testen van alle interne code van het programma, moet iedereen die de code moet testen niet alleen een goede kennis van programmeren hebben, maar hij zal ook nodig zijn om een ​​goede hand te hebben met de taal van de broncode.

Beveiliging is een van de belangrijke aspecten van White Box Testing, dus de tester moet ook goed zijn in veilige coderingsmethoden.

2. Testgevallen maken en uitvoeren

Nadat de code door het testteam is bestudeerd, kunnen ze beginnen met het testen van de code om de juiste stroom en structuur te controleren. Om dit te doen, zullen de testers wat code schrijven voor sommige testgevallen die zullen proberen alle regels code te doorlopen die aanwezig zijn in het programma.

Het kan ook worden gedaan in de handmatige testen die vallen en opstaan ​​inhoudt. De testers kunnen ook enkele geautomatiseerde testtools gebruiken, zoals JUnit en NUnit.

Een voorbeeld van White Box-testen

Bekijk de onderstaande code om het concept van White Box-testen beter te begrijpen:

print (int x, int y) (
int sum = x + y;
If ( sum > 0 )
Print ( "Positive", result )
Else
Print ( "Negative", result )
)

Zoals we eerder hebben besproken, is het doel van White Box Testing om alle vertakkingen, lussen en instructies in de code te doorlopen. Overwegend dat we 2 testgevallen kunnen maken, een waarbij beide ingangen positief zijn en een andere waarbij beide ingangen negatieve gehele getallen zijn.

Voorbeeld:

  • A = 10 en B = 20
  • A = -10 en B = -20

White Box-testtechnieken

Een van de meest populaire testtechnieken voor white box-testen wordt codedekkingsanalyse genoemd. Deze techniek probeert eventuele hiaten in de testcase-suite te elimineren en identificeert delen van een app die niet door testcases worden gebruikt. Zodra deze hiaten zijn gevonden, kunnen we cases maken om niet-geteste delen van de code te bekijken en te verifiëren. Dit resulteert uiteindelijk in een meer gepolijst product.

Hier volgen enkele dekkingsanalysetechnieken:

  • Dekking van verklaringen: Bij deze methode proberen we alle verklaringen in de code minstens één keer te doorlopen. Dit zorgt ervoor dat alle code wordt getest.
  • Branch Coverage: deze methode is gepland om elke tak van de beslissingspunten in de code te doorlopen. Dit zorgt ervoor dat alle beslissingen minstens één keer worden getest.

Er zijn ook enkele andere testtechnieken, hier zijn er een paar:

  • Voorwaarde dekking: In deze testtechniek zorgen we ervoor dat alle voorwaarden in de code worden opgenomen, bijvoorbeeld:

READ A, B
IF (A == 0 || B == 0)
PRINT '0'

Zoals u kunt zien, hebben we hier 2 voorwaarden: A == 0 en B == 0. Nu ontvangen deze voorwaarden WAAR en ONWAAR als waarden. Een mogelijk voorbeeld kan zijn:

# TC1 - A = 0, B = 110
# TC2 - A = 10, B = 0

  • Meerdere condities: dit is iets geavanceerder dan de vorige. Zoals je kunt raden, testen we alle mogelijke combinaties en alle mogelijke resultaten minstens één keer. Hier is een goed voorbeeld:

READ A, B
IF (A == 0 || B == 0)
PRINT '0'

# TC1: A = 0, B = 0
# TC2: A = 0, B = 10
# TC3: A = 110, B = 0
# TC4: A = 110, B = 5

Vandaar. We hebben 4 testgevallen nodig voor 2 voorwaarden.

Dus als er n voorwaarden zijn, hebben we 2 n testgevallen nodig.

  • Basispadtest: in deze White Box-testtechniek maken we een controlestroomgrafiek en berekenen we vervolgens de cyclomatische complexiteit die het aantal onafhankelijke paden is. Met behulp van de cyclomatische complexiteit kunnen we het minimale aantal testgevallen vinden dat we kunnen ontwerpen voor elk onafhankelijk pad van de stroomgrafiek.
  • Lus testen: Lussen zijn een van de meest gebruikte tools in de wapens van een programmeur. Omdat deze de kern vormen van zoveel algoritmen, is het alleen zinvol om een ​​testtechniek te hebben die op lussen is gebaseerd. Er kunnen 3 soorten lussen zijn: eenvoudig, genest en aaneengeschakeld. Laten we eens kijken hoe een tester omgaat met de technologie van deze typen:

1. Eenvoudige loops: voor een eenvoudige loop met de maat n kunnen we enkele testgevallen ontwerpen die het volgende doen:

  • Sla die lus over.
  • Doorloop de lus slechts eenmaal.
  • Heb 2 passen
  • Een willekeurig aantal passen hebben dat kleiner is dan zijn grootte.
  • n-1 en n + 1 gaan door de lus.

2. Geneste lussen: voor code met geneste lussen beginnen we met de binnenste lus en gaan dan naar buiten totdat we de buitenste lus kunnen bereiken.

3. Aaneengeschakelde lussen: in het geval van deze lussen. We gebruiken de eenvoudige lus-test een voor een en in het geval dat de aaneengeschakelde lus niet onafhankelijk is, kunnen we ermee omgaan zoals we deden met geneste lussen.

voordelen

Nu we hebben gezien wat deze testmethode is en hoe het werkt. Laten we een paar van de voordelen hiervan bekijken.

  • White Box Testing heeft eenvoudige en duidelijke regels om een ​​tester te laten weten wanneer de test is voltooid.
  • White Box-testtechnieken zijn eenvoudig te automatiseren, waardoor een ontwikkelaar minder testers en kleinere kosten hoeft in te huren.
  • Het vertoont knelpunten waardoor de optimalisatie vrij eenvoudig is voor de programmeurs.
  • Een testteam kan aan de slag met hun werk zonder te hoeven wachten tot het ontwikkelingsteam de UI-ontwikkeling heeft voltooid.
  • Aangezien in de meeste gevallen alle codepaden in de code worden behandeld, is het testen van code meer door.
  • Het helpt bij het verwijderen van delen van de code die niet essentieel zijn voor de functionaliteit van het programma.

nadelen

  • Het is behoorlijk belastend voor middelen. Om het testen gedaan te krijgen, hebt u iemand nodig die uw code heel goed kent om in het testteam te zitten en die zelf een goede programmeur is. Dit type vaardigheid verhoogt de kosten van het testen.
  • In veel gevallen is het niet mogelijk om elke mogelijke voorwaarde in de code te testen vanwege tijdsgebrek of budgetbeperkingen.
  • Omdat testen in witte dozen gebaseerd is op het controleren van de functionaliteit van de bestaande code, kunt u de ontbrekende functionaliteit niet vinden in het programma.
  • Als een deel van de code opnieuw wordt ontworpen en opnieuw wordt geschreven, moeten testers de testgevallen opnieuw schrijven.

White Box Testtools

Nu u bekend bent met de voordelen, nadelen en technieken van het testen van witte dozen, kunnen we enkele populaire tools bekijken die testers kunnen gebruiken om testen met witte dozen uit te voeren.

  • JSUnit.net

Dit is een JavaScript-testtool. JSUnit is een onderdeel van Junit en het is een open source-testkader dat kan worden gebruikt om White Box-tests uit te voeren. JSUnit is volledig open source onder GNU Public License 2.0, wat betekent dat een ontwikkelaar zelfs voor commercieel gebruik geen licentiekosten hoeft te betalen.

  • cppunit

Net als JSUnit wordt CppUnit ook beschouwd als onderdeel van JUnit. De tool kan worden uitgevoerd in platte tekst of XML-indeling, afhankelijk van de behoefte van de tester en het kan unit-tests maken met zijn eigen klassen. De CppUnit is gelicenseerd onder LGPL.

  • Veracode

Hoewel het niet gratis is voor gebruik, heeft Veracode een aantal krachtige tools die kunnen worden gebruikt om .NET, C ++, Java en enkele andere talen te testen. De White Box-tests kunnen ook worden uitgevoerd voor desktop-, web- en mobiele apps.

  • NUnit

Het is een eenheidstestraamwerk en het is geschreven in C #. De tool ondersteunt alle beschikbare .Net-talen en ondersteunt ook datagestuurde tests. Qua functionaliteit kan het zowel op parallelle als gelijktijdige uitvoering werken en kan het een klassenframework en test runner-apps bieden. Een opvallend kenmerk van de NUnit dat het redelijk eenvoudig te gebruiken is.

  • JUnit

Zoals je uit de naam kunt raden, is JUnit een automatiseringstool voor het testen van eenheden voor Java. De JUnit-bus is eenvoudig te integreren met IDE's zoals eclipse, Macen ACT, enz. Het kan testgestuurde ontwikkeling ondersteunen en het kan bestaande tests ook synchroniseren met nieuw gecreëerde eenmaal. JUnit is een volledig open source en gratis te gebruiken voor elke vorm van Java-ontwikkeling.

  • CSUnit

Net als Nunit is CSUnit gebouwd om het testen van eenheden in .Net Framework te ondersteunen. Het ondersteunt talen zoals C # en VB.Net. CSUnit heeft ingebouwde ondersteuning voor factoring en andere soorten praktijken die worden gebruikt in de agile ontwikkelingsbenadering van SDLC.

Conclusie

Testen heeft een zeer belangrijke plaats in het softwareontwikkelingsproces en White Box-testen is een waardevolle manier om dit voor elkaar te krijgen. Hoewel deze testaanpak duur en tijdrovend kan zijn, blijft White Box Testing de enige manier om ervoor te zorgen dat alle delen van de code tijdens het testproces aan bod kwamen.

Het belangrijkste onderdeel van White Box Testing is hoe vertrouwd de tester is met de code. Iemand die is belast met het testen op de WBT-aanpak en die geen goede hand heeft met de broncode en de gebruikte programmeertaal, zal veel problemen veroorzaken. Het is ook geen goed idee om alleen afhankelijk te zijn van de White Box-test, omdat deze geen betrekking heeft op ontbrekende functionaliteit. Voor een meer gedekte benadering van de ontwikkeling moeten zowel White Box Testing als Black Box testing worden gedaan, omdat dan maximale bugs, defecten en resterende functies worden behandeld die moeten worden toegevoegd voordat het product kan worden verzonden.

Aanbevolen artikelen

Dit is een leidraad geweest voor het testen van White Box. Hier hebben we besproken hoe White Box Testing wordt uitgevoerd met behulp van voorbeelden en verschillende White Box Testing Technieken met tools. U kunt ook onze andere voorgestelde artikelen doornemen voor meer informatie–

  1. Sollicitatievragen voor Software Testing
  2. Carrières in het testen van software
  3. Sollicitatievragen voor Game Testing
  4. Sollicitatievragen voor ETL Testing
  5. Codedekking versus testdekking | Top 4 verschillen om te leren
  6. Hulpmiddelen voor codedekking | Top 6 Code Coverage Tools

Categorie:

Software ontwikkeling