White box is een categorie van softwaretests die verwijst naar testmethoden van hoe de interne structuur en het ontwerp van de software werken. Dit staat in contrast met black box testing, dat is testen die zich niet bezighouden met de interne werking van software, maar alleen de externe output van de software testen.
In dit artikel verkennen we het onderwerp white box testing: wat het is, hoe het werkt, en welke soorten software testing tools testers en ontwikkelaars kunnen helpen bij het uitvoeren van white box testing in software testing.
Wat is white box testing?
White box testing is een softwaretesttechniek waarbij de interne structuur en het ontwerp van de software worden getest, in tegenstelling tot de externe output of eindgebruikerservaring die bij black box testing wordt getest.
White box testing is een overkoepelende term die veel verschillende soorten softwaretests omvat, waaronder eenheidstests en integratietests. Omdat white box tests het testen van code en programmering inhouden, is voor het uitvoeren van white box tests gewoonlijk enig begrip van computerprogrammering vereist.
Bij white box testing in software engineering kan het gaan om het testen van de code en het interne ontwerp van software om de input-output flow te verifiëren en het ontwerp, de bruikbaarheid en de veiligheid van de software te controleren.
White box testing stelt testers in staat de innerlijke werking van het systeem te inspecteren en tegelijkertijd te verifiëren of inputs resulteren in specifieke, verwachte outputs.
White box testing is een essentiële stap in het testen van software, omdat het de enige vorm van testen is die nagaat hoe de code zelf functioneert.
1. Wanneer en waarom heeft u een white box nodig?
testen in software testen en engineering?
White box tests kunnen in verschillende stadia van de testcyclus worden uitgevoerd om de werking van de interne code en structuur te verifiëren.
Meestal komen white box tests voor wanneer ontwikkelaars en testers unit tests uitvoeren en soms tijdens integratietests.
Eenheidstesten worden per definitie beschouwd als een vorm van white box testing, terwijl integratietesten kenmerken van zowel white als black box testing kunnen hebben, maar over het algemeen worden beschouwd als een vorm van black box testing.
Anders kunnen white box tests ook ad hoc worden gebruikt om de interne werking van een software build te controleren. White box testing is de meest economische manier om de testdekking te vergroten als daar behoefte aan is, en het is ook een gemakkelijke manier om na te gaan hoe specifieke delen van code werken of om delen van een software te testen waarvan testers vermoeden dat ze te weinig worden getest.
Formele codebeoordelingen, die worden uitgevoerd met white box tests, kunnen ook worden gebruikt om beveiligingsfouten en andere kwetsbaarheden op te sporen. Evenzo, als elementen van de code gebroken zijn, kunnen white box tests software-ingenieurs helpen te bepalen waar de fout zit.
2. Wanneer u geen white box tests hoeft te doen
In de meeste gevallen, wanneer software engineers en testers een nieuwe software build door de testcyclus halen, is enige mate van white box testing nodig om de interne werking van de code te verifiëren.
Unit testen is een soort white box testen die wordt uitgevoerd door ontwikkelaars om te controleren of individuele eenheden werken zoals verwacht. Deze vroege vorm van testen stelt ontwikkelaars in staat bugs en defecten op te sporen voordat formele tests in een QA-omgeving plaatsvinden.
Na eenheidstests vinden integratietests, systeemtests en gebruikersacceptatietests plaats. Deze worden doorgaans beschouwd als vormen van black box testing waarbij meestal niet veel white box testtechnieken worden toegepast.
Echter, in sommige gevallen kunnen testers en ontwikkelaars tijdens deze stadia white box tests gebruiken om specifieke defecten in de code op te sporen. In dit stadium, als er geen aanwijzingen zijn dat er iets mis is met de code en de black box tests allemaal slagen, kunnen veel testteams van mening zijn dat het niet nodig is om verdere white box tests uit te voeren.
3. Wie is betrokken bij white box testing?
White box testing wordt bijna altijd uitgevoerd door softwareontwikkelaars en software-ingenieurs. Dit komt omdat white box testing gedetailleerde kennis vereist van computercode en coderingstechnieken, en de meeste QA-testers niet over de technische vaardigheden beschikken die nodig zijn om white box testing uit te voeren.
Unit testen, de primaire vorm van white box testen, wordt altijd uitgevoerd in de ontwikkelomgeving door ontwikkelaars. Ontwikkelaars kunnen ook white box tests uitvoeren wanneer dat nodig is, om de werking van verschillende elementen van de code te controleren of om na te gaan of bugs correct zijn opgelost.
De voordelen van white box testing
Met white box testing kunnen ontwikkelaars en software engineers meer aspecten van de code testen dan met black box testing.
Terwijl black box testing ons kan vertellen hoe een software-build voor eindgebruikers functioneert, kan white box ons meer vertellen over hoe softwarecode werkt. Schone, efficiënte code is essentieel bij de ontwikkeling van software, vooral als ontwikkelaars de code later opnieuw willen gebruiken of in de toekomst patches en upgrades willen toevoegen.
1. Maximale testdekking
White box testing kan testers helpen de testdekking te maximaliseren. Het testen van zoveel mogelijk softwarecode maximaliseert gewoonlijk de kans om eventuele bugs of fouten in de code op te sporen, en het doel van white box testing is gewoonlijk om zoveel mogelijk code te testen.
Bij black box testing daarentegen gaat het gewoon om het uitvoeren van testgevallen die al dan niet een brede codedekking bieden.
2. Verborgen fouten en bugs vinden
Een van de grootste voordelen van white box testing is dat, omdat white box testing de interne functionaliteit verifieert, het voor ontwikkelaars gemakkelijker wordt om fouten en bugs te vinden die anders diep in de code verborgen zouden zitten.
Naast het identificeren van de aanwezigheid van bugs, is het meestal gemakkelijker om precies te lokaliseren waar in de code base een bug zich bevindt bij het uitvoeren van white box tests vanwege de zeer specifieke aard van dit type testtechniek.
3. Automatiseringsgemak
Het is heel eenvoudig om white box tests te automatiseren, vooral bij het uitvoeren van unit tests. Unit tests vereisen meestal dat ontwikkelaars kleine stukjes code afzonderlijk testen om te zien of ze werken zoals verwacht. Dit is zeer eenvoudig te automatiseren, wat betekent dat het een snelle en efficiënte vorm van softwaretesten is.
Dit is een van de redenen waarom unit tests worden uitgevoerd vóór andere, meer tijdrovende vormen van testen.
4. Tijdsefficiënt
White box testing is om een aantal redenen tijdbesparend.
Zoals gezegd is het relatief eenvoudig om de meeste soorten white box tests te automatiseren, wat betekent dat white box tests vaak sneller kunnen worden uitgevoerd dan black box tests. Daarnaast maakt white box testing het voor ontwikkelaars gemakkelijk om de bugs en fouten die zij in code ontdekken op te sporen, omdat zij die vinden tijdens het testen van de code zelf.
5. Codekwaliteit
Met white box testing kunnen ontwikkelaars de code die ze hebben geschreven nog eens goed bekijken en de kwaliteit en netheid ervan beoordelen.
Het stuk voor stuk doorlopen van code geeft ontwikkelaars de kans om overbodige stukken code te verwijderen en code op te schonen waardoor het in de toekomst gemakkelijker wordt om stukken code te hergebruiken en aan te passen.
Het kan ontwikkelaars ook dwingen na te denken over hoe code wordt geïmplementeerd en of dit in de toekomst goed zal schalen.
De uitdagingen van white box testing
White box testing is niet zonder uitdagingen. Er zijn een paar redenen waarom sommige ontwikkelingsteams white box testing moeilijker vinden om uit te voeren dan black box testing, en ook andere redenen waarom het door sommigen als minder belangrijk wordt gezien dan black box testing.
1. Technische belemmeringen
White box testing brengt technische belemmeringen met zich mee die black box testing niet heeft. Om white box tests uit te voeren, hebben testers kennis nodig van de interne werking van het systeem, wat bij het testen van software meestal programmeerkennis betekent.
Daarom worden white box tests bijna altijd uitgevoerd door software engineers en ontwikkelaars en niet door QA testers die zelden over de technische vaardigheden beschikken om dit soort tests uit te voeren.
2. Kosten
White box testing kan duurder zijn om uit te voeren dan black box testing vanwege de grondigheid van dit type test.
Ontwikkelaars moeten veel tijd besteden aan het schrijven van intensieve unit tests, en white box tests kunnen vaak niet worden hergebruikt voor andere toepassingen, wat betekent dat white box tests meestal veel kosten om uit te voeren.
3. Nauwkeurigheid
White box testing is niet altijd de meest nauwkeurige testmethode voor software en als ontwikkelingsteams alleen op white box testing zouden vertrouwen, zou dat resulteren in veel gemiste bugs en cases.
White box testing valideert alleen functies die al bestaan, terwijl black box testing kan worden gebruikt om gedeeltelijk geïmplementeerde functies te testen of om functies te identificeren die eigenlijk ontbreken in de software en in latere iteraties moeten worden opgenomen.
4. Toepassingsgebied
White box tests zeggen meestal niet veel over de gebruikerservaring of het eindresultaat van de in de software ingebouwde functies.
Hoewel ontwikkelaars white box tests kunnen gebruiken om na te gaan of de code werkt zoals het hoort, kunnen ze vervolgens niet concluderen dat de werkende code de juiste output levert aan eindgebruikers zonder white box tests te combineren met black box tests.
Dit betekent dat er beperkingen zijn aan de reikwijdte van white box testing en hoeveel het ons kan vertellen over software.
De kenmerken van white box tests
White box testing kan worden gedefinieerd door bepaalde kenmerken die het onderscheiden van andere vormen van testing zoals black box en grey box testing.
De meeste van deze kenmerken kunnen worden beschouwd vanuit het perspectief van hoe zij verschillen van de kenmerken van black box testing en hoe dit white box testing en black box testing van elkaar onderscheidt.
1. Onderhoudbaarheid
White box testing leidt tot een hoger niveau van onderhoudbaarheid van uw code, waardoor het werk dat uw team in de toekomst moet doen wordt vereenvoudigd.
Omdat de code en wat die met de gegevens doet voortdurend in de gaten wordt gehouden, is het onderhoud veel eenvoudiger, omdat u begrijpt waar zich problemen voordoen en waarom. Dit houdt de code ook eenvoudiger voor toekomstige updates, omdat u geen grote en complexe patches ontwikkelt voor onbekende en eenvoudige problemen.
2. Flexibiliteit
White box testing vindt plaats op code die flexibel genoeg is om relatief snel veranderingen te accepteren. Inflexibele code, zoals die welke deel uitmaakt van een module of integratie van een derde partij, verhindert een white box tester om snel wijzigingen aan te brengen.
Door je te richten op code die je kunt veranderen zodra je een probleem ontdekt, is white box testing zeer flexibel en worden problemen met een programma veel sneller opgelost.
3. Modulariteit
White box testing gedijt bij code met een zekere mate van modulariteit, wat betekent dat afzonderlijke elementen van de software zich duidelijk van elkaar onderscheiden.
Als een programma “spaghetti-code” heeft waarin elk aspect aan een ander is gekoppeld, wordt white box testing oneindig veel complexer, omdat een tester het hele programma moet onderzoeken in plaats van een specifieke eenheid.
4. Integratie
White box testing is uiterst nuttig voor integratietests. Testers kunnen zien of een functie werkt tot het punt waarop deze de betrokken software verlaat en of deze uit het geïntegreerde systeem terugkeert zoals verwacht.
Dit is zeer informatief en laat een organisatie weten of het probleem lokaal is of deel uitmaakt van het geïntegreerde platform.
Wat testen we in white box tests?
White box tests worden gebruikt om functies van de code te testen die niet kunnen worden geverifieerd met black box testmethoden. Dit kan betekenen dat wordt getest hoe de code zelf werkt, waardoor ontwikkelaars de oorzaak en het gevolg van verschillende aspecten van de code kunnen begrijpen.
Ontwikkelaars gebruiken white box testing om veiligheidslekken, verklaringen en functies, uitgangen en paden in de code te testen.
1. Interne veiligheidslekken
Met white box tests kan worden gezocht naar gaten in de beveiliging en kwetsbaarheden in de code waar hackers en cybercriminelen in de toekomst misbruik van zouden kunnen maken.
White box tests kunnen worden gebruikt om na te gaan of tijdens de ontwikkelingsfase de beste beveiligingspraktijken zijn gevolgd en om te zoeken naar beveiligingsproblemen die kunnen worden verholpen voordat de code verder wordt getest.
2. Paden in coderingsprocessen
Met white box testing kunnen ontwikkelaars de paden testen die verschillende elementen van de code met elkaar verbinden. Ontwikkelaars testen niet alleen de logica van de code, maar kunnen ook kijken naar codestructuur en hygiëne.
Goede, schone code heeft geen overbodige regels of gebroken elementen die niet werken zoals verwacht, zelfs als de externe output van black box tests is zoals verwacht.
3. Verwachte outputs
White box testing kan ook de verwachte output van code testen op dezelfde manier als black box testing dat kan, hoewel testers dat doen door de code te bekijken en niet door de applicatie te gebruiken zoals testers dat doen bij black box testing.
Ontwikkelaars testen de verwachte outputs door de inputs één voor één te controleren en na te gaan of de resulterende output overeenstemt met de verwachtingen.
4. Verklaringen, objecten en functies
Door white box-testtechnieken toe te passen, kunnen softwareontwikkelaars ervoor zorgen dat verklaringen, objecten en functies in de code zich logisch gedragen en de verwachte output opleveren.
5. Functionaliteit van voorwaardelijke lussen
White box tests kunnen ook worden gebruikt om de functionaliteit van voorwaardelijke lussen te controleren, waaronder enkelvoudige, samengevoegde en geneste lussen. Ontwikkelaars zullen nagaan of deze lussen efficiënt zijn, voldoen aan de vereisten voor voorwaardelijke logica, en of ze correct omgaan met lokale en globale variabelen.
Wat verwarring ophelderen:
White box vs Black box vs Grey box testen
White box testing, black box testing en grey box testing zijn termen die softwaretesters gebruiken om te verwijzen naar verschillende categorieën van testen of verschillende testmethoden.
Een moderne kijk op dit testonderscheid is dat de grenzen tussen de verschillende soorten boxtests steeds vager worden, aangezien verschillende soorten tests vaak elementen van zowel white als black box tests combineren en tests afleiden uit documenten op verschillende abstractieniveaus.
Toch zijn er nog belangrijke verschillen tussen deze vormen van testen.
1. Wat is black box testing?
Black box testing is een vorm van softwaretesten waarbij de functionaliteit van software wordt gecontroleerd door testers die geen kennis hebben van de interne structuur van de code of hoe de code op een meer technisch niveau moet worden geïmplementeerd.
Black box testing test alleen de externe output van de software, of met andere woorden, het test wat de eindgebruiker zal ervaren wanneer hij de software gebruikt.
Black box testing is ook bekend als behavioral testing omdat het test hoe de software zich onder bepaalde omstandigheden gedraagt.
Testers kunnen black box testing gebruiken om te beoordelen hoe verschillende functies van de software zich gedragen en deze toetsen aan de verwachtingen om er zeker van te zijn dat de software voldoet aan de eisen van de gebruikers. Black box testing wordt gebruikt bij systeemtests en acceptatietests om verschillende functies te controleren en na te gaan of het systeem in zijn geheel werkt zoals verwacht.
Bij black box testing schrijven gebruikers testgevallen om verschillende elementen afzonderlijk te verifiëren. Omdat black box testing niet dezelfde technische vaardigheden vereist als white box testing, wordt black box testing meestal uitgevoerd door testers in een QA-omgeving in plaats van door ontwikkelaars.
Het automatiseren van black box testing is meestal gemakkelijker dan white box testing door gebruik te maken van end-to-end automation tools zoals ZAPTEST.
Wat zijn de verschillen tussen white box en black box testen?
Het belangrijkste verschil tussen black box en white box testen is wat er wordt getest.
Black box testing gaat over het testen van de externe output van de software build, terwijl white box testing gaat over het testen van wat er onder de motorkap gebeurt.
Enkele van de belangrijkste verschillen tussen black box en white box testen zijn:
Doel
Het doel van black box testing is na te gaan of het systeem voor de eindgebruiker werkt zoals verwacht, terwijl het doel van white box testing is de kwaliteit en integriteit van de code van de software te controleren.
Bij black box testing voor een videogame bijvoorbeeld kan een eindgebruiker het spel uitproberen en beoordelen op zijn ervaring, terwijl white box testing op hetzelfde project ervoor zorgt dat het invoeren van specifieke inputs ertoe leidt dat het personage de juiste actie uitvoert.
Proces
De processen die bij white en black box tests worden gebruikt, zijn zeer verschillend. White box tests zijn veel gemakkelijker te automatiseren dan black box tests, en meestal moeten black box tests worden geautomatiseerd met behulp van softwareautomatiseringshulpmiddelen.
Bij het testen van een database bijvoorbeeld houdt een white box test in dat de gegevensinvoer wordt geautomatiseerd om te controleren of alle uitkomsten correct zijn, terwijl een black box test inhoudt dat gebruikers handmatige processen repliceren en daarover rapporteren zonder gebruik te maken van een automatiseringssysteem.
Testers
Black box testing wordt bijna altijd uitgevoerd binnen een QA-omgeving door professionele softwaretesters, terwijl white box testing wordt uitgevoerd door softwareontwikkelaars en ingenieurs die meer gedetailleerde technische kennis hebben van de broncode.
Technieken
Bij black box testing worden verschillende technieken gebruikt, zoals equivalentieverdeling, grenswaardeanalyse en beslissingstabeltests. White box testing gebruikt technieken als decision coverage, condition coverage en statement coverage.
Operaties
De testmethoden van black box testing zijn geschikt voor testoperaties op hogere niveaus zoals systeemtesten en acceptatietesten, terwijl white box testing meer geschikt is voor operaties op lagere niveaus zoals unit testing en integratietesten.
Daarom worden white box tests meestal uitgevoerd vóór de meeste vormen van black box tests.
2. Wat is grey box testing?
Grey box testing is een softwaretesttechniek die wordt gebruikt om softwareproducten en -toepassingen te testen door testers die wellicht gedeeltelijke kennis hebben van de interne structuur van de toepassing, maar geen volledige kennis ervan.
Grey box testing kan elementen van zowel black box testing als white box testing combineren om ontwikkelaars en testers in staat te stellen gebreken in code op te sporen en contextspecifieke fouten te lokaliseren.
Grey box testing combineert kenmerken van zowel black box testing als white box testing. Testers moeten enige kennis hebben van de interne werking van het systeem, zoals bij white box testing, maar zij gebruiken deze kennis om testgevallen te creëren en deze testgevallen uit te voeren op het niveau van de functionaliteit, zoals bij black box testing.
Grey box testing biedt veel van de voordelen van zowel black box als white box testing en is tegelijkertijd relatief tijdsefficiënt en flexibel.
Wat zijn de verschillen tussen white box en grey box testen?
Omdat grey box testing deels dezelfde functionaliteit biedt als black box testing, zijn er enkele grote verschillen tussen grey box testing en white box testing, hoewel misschien niet zoveel als bij black box testing.
Enkele van de grootste verschillen tussen grey box testing en white box testing zijn:
Structurele kennis
Bij white box testing moeten het interne ontwerp en de structuur van de code volledig bekend zijn bij degene die de test uitvoert. Bij grey box testing is de interne structuur van de code meestal slechts gedeeltelijk bekend.
Betrokkenen
White box testing wordt bijna uitsluitend uitgevoerd door softwareontwikkelaars en software-ingenieurs, terwijl grey box testing kan worden uitgevoerd door eindgebruikers, testers en ontwikkelaars.
Efficiëntie
White box testing wordt beschouwd als de meest tijdrovende vorm van software testing, terwijl grey box testing enkele van de efficiënties van black box testing leent om de tijd die nodig is om tests uit te voeren te verminderen.
Operatie
Bij white box testing schrijven ontwikkelaars gewoon code om white box tests uit te voeren en voeren deze code uit. Bij grey box testing voeren testers, net als bij black box testing, functionele tests uit om te beoordelen hoe het systeem extern werkt.
Dekking
White box testing is de meest uitputtende vorm van testen, terwijl de dekking van grey box testing kan variëren naargelang het type uitgevoerde testcases gebaseerd is op code of GUI.
Conclusie:
White box vs Black box vs. Grey box testen
White box testing, black box testing en grey box testing zijn termen die worden gebruikt om te verwijzen naar verschillende softwaretesttechnieken. In grote lijnen kan elk type test worden gedefinieerd op basis van de mate waarin testers kennis moeten hebben van de codebasis en de implementatie van de code:
1. Black box testing:
De interne structuur van de code is onbekend.
2. White box testing:
De interne structuur van de code is bekend.
3. Grey box testing:
De interne structuur van de code is gedeeltelijk bekend.
Bij het testen van software zijn alle drie de soorten tests belangrijk om de werking en integriteit van de software te verifiëren. Terwijl white box testing ons meer vertelt over de onderliggende structuur van de code, kunnen grey box testing en black box testing nagaan hoe het systeem werkt en of dit voldoet aan de eisen van de eindgebruiker.
De grootste verschillen tussen deze drie testtypen hebben wellicht te maken met wie elk testtype uitvoert, de eisen van het testen zelf en wat het testen inhoudt.
White box testing heeft de hoogste drempel omdat het wordt uitgevoerd door ontwikkelaars met gedetailleerde kennis van de codebase zelf en omdat het de meest tijdrovende en vaak kostbare vorm van testen is.
Black box testing daarentegen is het gemakkelijkst uit te voeren en kan worden uitgevoerd door testers zonder kennis van de onderliggende code.
Soorten white box tests
Er zijn veel verschillende soorten white box tests, die elk kunnen worden gebruikt om iets andere aspecten van de interne structuur van de code te testen.
Hieronder staan enkele van de meest voorkomende soorten white box testing die tegenwoordig worden gebruikt.
1. Padtest
Path testing is een soort white box testing op basis van de controlestructuur van een programma. Ontwikkelaars gebruiken de controlestructuur om een controlestroomgrafiek te maken en verschillende trajecten in de grafiek te testen.
Path testing is een type test dat afhankelijk is van de controlestructuur van het programma, wat betekent dat testers een grondig begrip van deze structuur moeten hebben.
Als een systeem bijvoorbeeld op bepaalde punten in de verkooptrechter met vaste berichten contact moet opnemen met klanten, moet er bij padtests voor worden gezorgd dat het de juiste stappen volgt, afhankelijk van de voorwaarden die de gegevens stellen.
2. Lus testen
Loop testing is een van de belangrijkste vormen van white box testing waarbij lussen in de programmacode worden getest. Lussen worden geïmplementeerd in algoritmen binnen de code en lus testen controleert of deze lussen geldig zijn.
Loop testing kan beoordelen of er kwetsbaarheden bestaan binnen specifieke loops en gebieden aanwijzen waar ontwikkelaars de code moeten corrigeren om ervoor te zorgen dat de loop naar behoren functioneert.
Een voorbeeld van een lus-test is het doorlopen van de lus met een specifieke reeks gegevenspunten die de lus doen voortduren, zoals de weigering om bepaalde voorwaarden te aanvaarden, alvorens een cijfer in te voeren dat de lus specifiek verbreekt. Als de lus zich gedraagt zoals verwacht, is de test geslaagd.
3. Voorwaardelijk testen
Voorwaardelijke tests zijn een soort white box tests die controleren of de logische voorwaarden voor waarden in de code waar of onwaar zijn.
Voorwaardelijk testen is een belangrijke vorm van white box testing die ontwikkelaars vertelt of de code logisch is en voldoet aan de eisen van de programmeringslogica.
Een voorbeeld van voorwaardelijk testen is binnen een boekhoudplatform. Het invoeren van een reeks uitgaven en inkomsten moet resulteren in de juiste lopende totalen, waarbij de software gedurende een succesvolle test nauwkeurige resultaten oplevert.
4. Eenheidstesten
Unit testing is een belangrijke fase in het testen van software, waarbij ontwikkelaars afzonderlijke componenten en modules testen en nagaan of ze werken zoals verwacht, alvorens verschillende eenheden met elkaar te integreren.
Software engineers gebruiken white box testmethoden bij unit testing om kleine stukjes code tegelijk te testen. Dit maakt het gemakkelijk om bugs en fouten op te sporen wanneer deze zich tijdens het testen voordoen.
Een voorbeeld van unit testing is vroeg in de ontwikkeling, als een bedrijf een eenvoudige knop op een website maakt die de gebruiker naar een andere pagina brengt. Als de eenheid werkt zoals verwacht, dan slaagt ze, en de ontwikkelaars brengen wijzigingen aan tot ze dat doen.
5. Mutatietests
Mutatietesten zijn een soort testen waarbij wijzigingen en mutaties worden getest. Bij mutatietesten brengen ontwikkelaars kleine wijzigingen aan in de broncode om te zien of dit bugs in de code aan het licht kan brengen.
Als de testcase slaagt, geeft dit aan dat er een probleem is met de code, want hij zou niet moeten slagen nadat de wijzigingen zijn aangebracht. Idealiter falen bij mutatietesten alle testgevallen.
Een voorbeeld van mutatietests is bij machinaal leren. Machine-learningprogramma’s “muteren” automatisch afhankelijk van nieuwe informatie, dus het consequent testen van deze programma’s op de norm van “mutatie” informeert de ontwikkelaars of de software werkt zoals verwacht.
6. Integratie testen
Integratie testen is een belangrijke fase van software testen waarin testers nagaan of verschillende modules correct werken wanneer zij met andere modules zijn geïntegreerd.
Bij integratietests worden white box-testtechnieken gebruikt om te controleren of de code ook functioneert wanneer meerdere modules – die vaak door verschillende ontwikkelaars zijn gecodeerd – samenwerken.
Wanneer een database informatie haalt uit een online bron, bijvoorbeeld, zorgen integratietests ervoor dat de gegevens die worden opgehaald accuraat zijn en met een redelijk consistente snelheid worden bijgewerkt.
7. Penetratietesten
Penetratietests zijn een soort white box tests waarmee specifieke cyberaanvallen op het systeem kunnen worden gesimuleerd.
Bij penetratietests krijgen testers toegang tot volledige netwerk- en systeemgegevens, zoals wachtwoorden en netwerkkaarten. Vervolgens proberen zij toegang te krijgen tot gegevens in het systeem of deze te vernietigen door zoveel mogelijk verschillende aanvalswegen te bewandelen.
Penetratietests zijn een belangrijk aspect van beveiligingstests die op alle software moeten worden uitgevoerd.
Een HR-platform, bijvoorbeeld, zal penetratietests uitvoeren en zoeken naar kwetsbaarheden in de code om er zeker van te zijn dat het platform veilig genoeg is om werknemersgegevens te bewaren.
White box testtechnieken
Er zijn veel verschillende white box testtechnieken die kunnen worden gebruikt om de bovengenoemde white box tests uit te voeren. Zoals altijd het geval is, zijn verschillende technieken het meest geschikt om verschillende aspecten van de code te testen, maar alle onderstaande white box-technieken zijn belangrijk.
1. Verklaring dekking
Een van de kenmerken van white box testing is dat testers moeten proberen zoveel mogelijk van de broncode te bestrijken bij het uitvoeren van white box tests.
Code coverage is een sterke maatstaf hiervoor, en statement coverage is zo’n techniek die white box testers kunnen gebruiken om de dekking van statements binnen de code te vergroten.
Statement coverage is een metriek die het aantal uitgevoerde statements gedeeld door het totale aantal statements en vermenigvuldigd met 100 meet. White box testers moeten streven naar een hoge statementdekking.
2. Takdekking
Branch coverage, zoals statement coverage, geeft aan hoe breed de dekking van bepaalde elementen van de code is bij white box testing. Vertakkingen zijn equivalent aan “IF”-statements in de logica, waarbij de code zich vertakt in ware en onware opties die het resultaat van de operatie beïnvloeden.
Bij het gebruik van branch coverage technieken controleren white box testers of elke branch ten minste één keer wordt verwerkt en valideren ze of beide branches correct werken.
3. Paddekking
Paddekkingstechnieken beoordelen de paden binnen een softwaretoepassing. Maximale dekking van testtrajecten betekent dat alle trajecten binnen het programma ten minste eenmaal worden onderzocht. Het is een soortgelijke testtechniek als takdekking, maar wordt als grondiger en effectiever beschouwd.
Path coverage testing wordt gewoonlijk het meest geschikt geacht voor het testen van volledige toepassingen in plaats van gedeeltelijke builds.
4. Besluitvorming
Decision coverage is een van de belangrijkste white box technieken omdat het gegevens oplevert over de ware en valse resultaten van booleaanse expressies in de broncode.
Decision coverage testing valideert de broncode door ervoor te zorgen dat elk merk van elke potentiële beslissing minstens één keer wordt doorlopen tijdens het testen.
Beslissingspunten zijn alle gelegenheden waarbij twee of meer verschillende resultaten mogelijk zijn.
5. Conditiedekking
Conditiedekking wordt ook wel expressiedekking genoemd. Deze white box-techniek evalueert de subvariabelen in voorwaardelijke verklaringen binnen de code om de uitkomst van elke logische voorwaarde te verifiëren.
Bij dit soort tests worden alleen uitdrukkingen met logische operanden in aanmerking genomen, terwijl decision coverage tests en branch coverage tests worden gebruikt om andere logische bewerkingen te waarborgen.
6. Dekking van meerdere aandoeningen
Bij multiple condition coverage tests controleren testers verschillende combinaties van voorwaarden en evalueren ze de beslissing die de code voor elke combinatie neemt.
Er kunnen veel verschillende testgevallen zijn voor tests met meervoudige voorwaardedekking vanwege het enorme aantal combinaties van voorwaarden die bestaan, zodat dit type tests vaak zeer tijdrovend is.
7. Eindige toestandsmachine dekking
Finite state machine coverage is een belangrijke vorm van testen, maar ook een van de moeilijkste manieren om een hoge codedekking te bereiken bij white box testing. Het werkt op de functionaliteit van het ontwerp en vereist dat ontwikkelaars het aantal keren tellen dat een toestand wordt bezocht of doorlopen tijdens het testproces, alsook hoeveel sequenties elk eindig toestandsstelsel bevat.
8. Testen van de stuurstroom
Control flow testing is een white box testtechniek die tracht de uitvoeringsvolgorde van het programma vast te stellen aan de hand van een eenvoudige controlestructuur.
Ontwikkelaars bouwen control flow testing test cases door een specifiek deel van het programma te kiezen en een testpad te bouwen. Control flow testing wordt meestal gebruikt bij unit testing.
De levenscyclus van white box testen
in software ontwikkeling
White box testing is een belangrijke stap in de levenscyclus van softwareontwikkeling, hoewel het geen strikte ‘plaats’ in de cyclus heeft.
Ontwikkelaars kunnen white box tests uitvoeren als en wanneer zij de werking van code moeten controleren, en sommige ontwikkelaars zijn grondiger dan anderen in het controleren van nieuw geschreven code om er zeker van te zijn dat deze schoon is en vrij van onnodige regels.
White box testing wordt echter meestal uitgevoerd tijdens unit testing en integratietests. Zowel eenheidstesten als integratietesten worden tijdens de ontwikkelingsfase uitgevoerd door ontwikkelaars.
Ze vinden plaats voordat functionele tests zoals systeemtests en acceptatietests plaatsvinden, en ze geven ontwikkelaars de kans om belangrijke bugs vroeg in de testfase op te sporen, te lokaliseren en te repareren voordat het product aan het QA-team wordt overgedragen.
Handmatige of geautomatiseerde white box tests?
Net als andere soorten softwaretests is het mogelijk om white box tests te automatiseren. Het kan handmatig of geautomatiseerd, hoewel het in de meeste gevallen gemakkelijker is white box tests te automatiseren dan black box tests.
Omdat white box testing een zeer tijdrovende vorm van testen is, wordt automatisering steeds populairder onder softwareteams.
Handmatig white box testen: voordelen, uitdagingen en processen
Handmatig white box testen betekent het handmatig uitvoeren van white box tests, en het vereist dat ontwikkelaars de vaardigheden en de tijd hebben om individuele testgevallen te schrijven om elke regel code in een software build mogelijk te testen. Dit kan veel tijd kosten, maar levert ook de meest grondige testresultaten en output op.
Enkele voordelen van het handmatig uitvoeren van white box tests zijn:
1. Diepte
Bij handmatig testen kunnen testers softwarecode grondiger onderzoeken dan bij geautomatiseerd testen, als zij daarvoor kiezen, bijvoorbeeld door de volledige broncode van een applicatie te lezen in plaats van alleen taken te automatiseren die de oppervlaktefunctionaliteit raken.
2. Plaats van het insect
Handmatig testen maakt het gemakkelijk om bugs en defecten op te sporen, omdat ontwikkelaars precies moeten kunnen aanwijzen in welke regel code de bug zich bevindt.
Als u bijvoorbeeld ziet dat een afbeelding niet wordt geladen, kunt u door de code te onderzoeken op regels die betrekking hebben op het laden van afbeeldingen, de oorzaak aanzienlijk beperken.
3. Snelheid
Handmatig testen duurt meestal langer dan geautomatiseerd testen, maar als ontwikkelaars slechts één of twee snelle tests willen uitvoeren, is het waarschijnlijk sneller om die handmatig uit te voeren dan om automatisering in te stellen.
Eenheidstests houden bijvoorbeeld in dat je een functie bekijkt en kijkt of die werkt, in plaats van enorme hoeveelheden gegevens te verzamelen door het proces te automatiseren. Er zijn echter ook nadelen verbonden aan handmatig white box testen.
Enkele van de uitdagingen bij handmatig white box testen zijn:
1. Nauwkeurigheid
Met handmatig testen kunnen ontwikkelaars weliswaar een breed scala aan code bestrijken, maar menselijke testers zijn altijd vatbaarder voor fouten en vergissingen dan computerprogramma’s, waardoor handmatig testen vaak als minder nauwkeurig wordt beschouwd dan geautomatiseerd testen.
2. Tijd
Handmatig testen duurt langer dan geautomatiseerd testen, en handmatig white box testen behoort tot de meest tijdrovende testen van allemaal. Dit verhoogt de doorlooptijd en kan het moeilijker maken om strakke ontwikkelingsdeadlines te halen.
3. Kosten
Vanwege de hoeveelheid mankracht en middelen die gemoeid zijn met handmatig white box testen, is dit vaak duurder voor ontwikkelingsteams dan geautomatiseerd testen, waarvoor meestal minder ontwikkelaars en minder tijd nodig zijn.
4. Schaalbaarheid
Handmatig testen is eigenlijk alleen geschikt voor het testen van kleine toepassingen of het testen van afzonderlijke onderdelen van grotere toepassingen. Voor grotere toepassingen, zoals een cloud-hosted database met duizenden inputs per minuut, hebben geautomatiseerde tests de voorkeur als methode om standaardbelastingen te simuleren.
Geautomatiseerde white box tests: voordelen,
uitdagingen en processen
Automatiseringstechnologie maakt het elke dag gemakkelijker om aspecten van het testen van software te automatiseren. De overstap van de industrie naar hyperautomatisering is deels te danken aan de efficiëntie en de kostenbesparingen die automatisering biedt aan ontwikkelingsteams die het altijd benauwd hebben.
White box is een van de meest geschikte en geschikte soorten tests voor automatisering, omdat ze relatief gemakkelijk te automatiseren zijn en de tijd- en kostenbesparingen van white box testautomatisering aanzienlijk kunnen zijn.
Geautomatiseerde white box testing kan inhouden dat ontwikkelaars zelf testscripts schrijven, maar het proces kan ook worden versneld met behulp van full-stack tools zoals ZAPTEST, die geavanceerde end-to-end softwaretesttechnologie bieden.
Enkele voordelen van het automatiseren van white box testing zijn:
1. Nauwkeurigheid
Computertests elimineren het risico op fouten omdat computers niet moe worden of fouten maken.
2. Tijd
Geautomatiseerde white box tests zijn aanzienlijk sneller dan handmatige white box tests en maken tijd vrij die ontwikkelaars kunnen besteden aan andere taken, zoals het oplossen van bugs of het schrijven van upgrade patches.
3. Schaal
Geautomatiseerd testen schaalt veel beter op dan handmatig testen, dus als uw softwareapplicatie groeit of als u op grote schaal tegelijk wilt testen, is automatisering de betere optie.
Bijvoorbeeld, bij het opschalen van gegevensinvoer wordt meer input gevraagd bij automatisering, in vergelijking met het inhuren van meer personeel bij handmatige tests.
4. Kosten
De kosten van geautomatiseerd testen zijn gewoonlijk, als ze eenmaal zijn getotaliseerd, lager dan de kosten van handmatig testen, vanwege het aantal werkuren dat door automatisering wordt bespaard. De 10x ROI van ZAPTEST laat zien hoe automatisering ontwikkelaars geld kan besparen en tot een hoger rendement kan leiden. Automatisering is echter niet zonder nadelen.
Enkele van de uitdagingen van het automatiseren van white box tests zijn:
1. Bug tracking
Automatisering maakt het niet altijd gemakkelijk om bugs in code op te sporen, afhankelijk van hoe ontwikkelaars tests automatiseren of welke testtools worden gebruikt, vooral in vergelijking met handmatige white box testing waarbij testers de code kunnen zien die wordt uitgevoerd wanneer een bug opduikt.
2. Vaardigheden
Niet alle ontwikkelaars weten hoe ze tests moeten automatiseren of hoe ze geautomatiseerde testtools moeten gebruiken, dus de overstap naar automatisering kan enige investering vergen in de opleiding van belangrijke vaardigheden zoals coderen in de taal van dat specifieke testplatform en het gebruik van vaardigheden op het gebied van gegevensanalyse om de oorzaak van problemen in een white box-test te begrijpen.
Conclusie: Handmatig white box testen
of white box test automatisering?
In het algemeen is white box testing in software engineering een van de meest geschikte soorten testen om aan geautomatiseerde tests aan te passen, grotendeels vanwege de tijdrovende en complexe aard van handmatige white box testing.
Geautomatiseerde white box tests zijn sneller, goedkoper, efficiënter en nauwkeuriger dan handmatige tests, vooral bij grotere toepassingen.
Waar mogelijk moeten softwareontwikkelaars bij het testen van software white box tests automatiseren om de betrouwbaarheid van de tests te vergroten en een groter gebied van grotere toepassingen door middel van tests te bestrijken dan praktisch mogelijk is bij het handmatig uitvoeren van tests. Dit komt door de aanzienlijke kosten en expertise die nodig zijn wanneer u white box tests uitvoert met uitsluitend handmatige methoden.
Wat heb je nodig om te beginnen
white box testen?
Voordat u begint met white box testing, moet u ervoor zorgen dat u alles hebt wat u nodig hebt om te beginnen. Afhankelijk van de vraag of u handmatige of geautomatiseerde white box tests uitvoert, hebt u naast tijd en geld niet veel middelen nodig.
U moet er echter wel voor zorgen dat uw team over de juiste kennis en hulpmiddelen beschikt om white box tests goed uit te voeren.
1. Inzicht in de broncode
White box tests zijn tests die softwareontwikkelaars en ingenieurs met volledige kennis van de broncode en de interne structuur van de software uitvoeren.
Als u een QA-tester bent zonder deze kennis, zult u de software aan iemand anders moeten doorgeven voordat het white box testen kan beginnen.
2. Testgevallen
Het is noodzakelijk testgevallen te schrijven alvorens white box tests uit te voeren. Testgevallen zijn individuele reeksen instructies die acties beschrijven die testers of ontwikkelaars kunnen uitvoeren om de functies en de werking van een systeem te testen.
Bij white box testing worden testgevallen ontworpen door mensen met volledige kennis van de interne structuur van het systeem en gemaakt om na te gaan of dit werkt zoals het hoort.
3. White box test tools
Er zijn tal van hulpmiddelen beschikbaar voor white box testing die toegang tot broncode en ontwerpdocumenten ondersteunen, naast het voltooien van testautomatisering. Deze zijn er ook in verschillende prijsklassen voor gebruikers, zoals de versies ZAPTEST FREE en ZAPTEST ENTERPRISE, die meer flexibiliteit bieden.
Kies de tools die u wilt gebruiken voordat u begint met testen, met de nadruk op de juiste functionaliteit zoals cross-platform werking en Computer Vision technologie, zodat u ziet wat geautomatiseerde tests zien.
Zorg ervoor dat alle ontwikkelaars en ingenieurs die bij het testen betrokken zijn, weten hoe en wanneer ze die moeten gebruiken.
Het white box testproces
Bij white box testing komt veel meer kennis van de werking van een systeem kijken dan bij black box testing, en sommige stappen bij white box testing zijn iets anders.
White box testers moeten eerst de functies of onderdelen van het systeem identificeren die zij willen verifiëren voordat zij mogelijke paden uitstippelen om te testen en testgevallen schrijven om uit te voeren.
Het white box testproces kan ook verschillen afhankelijk van de white box testtechniek die u gebruikt. Volg de onderstaande stappen om uit te vinden hoe u white box tests kunt uitvoeren met maximale paddekking.
Stap 1: Bepaal de te testen functies
Voordat u white box tests uitvoert, moet u bedenken wat u precies wilt testen en hoe u dat gaat doen. Dit houdt meestal in dat men zich concentreert op een kleine reeks functies of kenmerken en een reeks testgevallen opstelt om alleen die te testen.
U zult deze stap steeds opnieuw uitvoeren voor verschillende gebieden van het systeem om de testdekking te maximaliseren, maar het is belangrijk om verschillende gebieden op te splitsen in afzonderlijke tests.
Hoe nauwer u zich concentreert, hoe betrouwbaarder en nauwkeuriger uw tests kunnen zijn.
Stap 2: plot alle mogelijke paden in een flowgraph
Een belangrijk deel van je voorbereidingswerk voor white box testing is het plotten van alle mogelijke paden die je moet testen in een flowgraph.
Deze stap kan u helpen de paddekking te maximaliseren en ervoor te zorgen dat u alle mogelijke paden verifieert in elk testgeval dat u maakt. Teken een flowgraph die alle mogelijke paden omvat voor elke functie of component die u test, bijvoorbeeld door verschillende paden te schetsen die ontstaan wanneer verschillende waarden worden ingevoerd.
Stap 3: Alle mogelijke paden identificeren
Bekijk uw flowgraph en identificeer alle mogelijke paden die gebruikers kunnen nemen, beginnend bij de eerste stap van uw flowgraph en eindigend bij de laatste stap.
Hoe meer takken en beslissingen in uw stroomdiagram, hoe meer unieke paden er zullen bestaan. Als u begrijpt hoeveel unieke mogelijke paden er zijn, kunt u ervoor zorgen dat uw testgevallen elke mogelijkheid bestrijken.
Stap 4: Testgevallen maken
De volgende fase van white box testen is het schrijven van testgevallen die alle paden verifiëren die u hierboven hebt geïdentificeerd.
Het is belangrijk ervoor te zorgen dat uw testgevallen alle mogelijke paden bestrijken en duidelijk de acties aangeven die testers of ontwikkelaars moeten ondernemen om elk testgeval uit te voeren.
Vermeld voor elk testgeval een ID en naam van het testgeval, een korte beschrijving en de verwachte resultaten van elke test.
Stap 5: Testgevallen uitvoeren
Het is nu tijd om de testgevallen uit te voeren, wat de meeste mensen beschouwen als het uitvoeren van de white box testing zelf.
Testers voeren de testcases uit door de korte reeks instructies te volgen die in elke testcase worden beschreven en rapporteren het resultaat van elke testcase. Dit kan worden vergeleken met de verwachte resultaten die in de testcase zijn beschreven, om na te gaan of elke white box-test is geslaagd of mislukt.
Stap 6: Herhaal de cyclus indien nodig
Net als bij andere vormen van softwaretesten gaat het bij white box testing om het vergelijken van hoe het systeem feitelijk functioneert met de verwachtingen die testers hebben over hoe het systeem zou moeten functioneren.
Als testers ontdekken dat het systeem zich niet gedraagt zoals ze verwachten, kan dat betekenen dat de white box-tests zijn mislukt, en moeten ontwikkelaars regels code corrigeren voordat ze verder testen.
Herhaal het bovenstaande proces om verdere white box tests uit te voeren totdat het systeem grondig is getest en eventuele fouten zijn hersteld.
Beste praktijken voor white box testen
Best practices bij white box testing hangen af van het type test dat u uitvoert en de fase van het testproces waarin u zich bevindt.
Aangezien de meeste white box testen plaatsvinden tijdens unit testen en integratietesten, zijn de meeste white box test best practices van toepassing op deze fasen.
1. Maximale testdekking
Per definitie is het belangrijk om de testdekking te maximaliseren bij het uitvoeren van white box tests, zodat een hoog percentage van de software tijdens deze fase wordt getest.
U kunt dit doen door paddekking en takdekking te maximaliseren en testgevallen te schrijven die alle mogelijke paden en uitkomsten verkennen tijdens de voorbereidingsfase.
2. Controleer het gedrag en de prestaties
Wanneer u testgevallen schrijft bij white box testing, wilt u testgevallen maken die controleren of het systeem functioneert zoals u verwacht en testgevallen die de prestaties van het systeem controleren.
U kunt bijvoorbeeld niet alleen controleren of bepaalde acties tot bepaalde resultaten leiden, maar ook nagaan hoe snel het systeem bepaalde taken kan uitvoeren of hoe de prestaties worden beïnvloed door verschillende variabelen.
3. Schrijf testgevallen onafhankelijk van elkaar
Als u twee verschillende functies wilt verifiëren, bijvoorbeeld als een codeklasse afhankelijk is van een bepaalde database, maak dan een abstracte interface die deze databaseverbinding weergeeft en implementeer een interface met een mock object om deze verbinding te testen.
Dit zorgt ervoor dat uw testgevallen de verbindingen verifiëren die u wilt verifiëren, en niet iets anders.
4. Bedek alle paden en lussen
Maximale testdekking betekent dat alle mogelijke paden worden bestreken, rekening houdend met voorwaardelijke lussen en andere soorten lussen in de code.
Zorg ervoor dat u testgevallen ontwerpt die mogelijke paden volledig verkennen en controleer of lussen zich gedragen zoals u verwacht, ongeacht de invoer.
7 fouten en valkuilen bij
Uitvoering van white box tests
Wanneer u begint met white box testen, is het belangrijk dat u zich bewust bent van enkele van de meest voorkomende valkuilen waar ontwikkelaars vaak in trappen bij het uitvoeren van white box testen. Veel voorkomende fouten bij white box testing kunnen leiden tot vertragingen en onnauwkeurigheden die de kwaliteit en het tijdschema van de softwarerelease kunnen schaden.
1. Denken dat white box testen niet nodig is
Sommige testers denken dat white box testing niet nodig is, omdat black box testing alle externe outputs van de software test, en als die correct werken, wordt aangenomen dat de interne werking van het systeem ook werkt.
Echter, white box testing kan ontwikkelaars helpen bij het opsporen van problemen en bugs die bij black box testing niet altijd aan het licht komen en is essentieel om de veiligheid van softwaresystemen te controleren.
Als een programma bijvoorbeeld een geheugenlek heeft dat gedurende langere tijd prestatieverlies veroorzaakt dat niet door black box tests kan worden onderzocht, zijn white box tests de enige optie om de code door te spitten en het probleem te vinden voordat het op grote schaal openbaar wordt gemaakt.
2. Alle white box tests handmatig uitvoeren
Sommige ontwikkelaars denken misschien dat het net zo gemakkelijk is om white box tests uit te voeren als black box tests.
White box testing is echter aanzienlijk tijdrovender en ontwikkelaars die white box testing volledig handmatig proberen uit te voeren, kunnen erachter komen dat het onmogelijk is om handmatige controles uit te voeren volgens de gewenste normen of met een maximale testdekking.
3. Het toewijzen van testers om testgevallen uit te voeren
White box testing moet volledig worden uitgevoerd door ontwikkelaars, software engineers en mensen die de innerlijke werking van het softwaresysteem volledig begrijpen.
Sommige ontwikkelaars denken dat ze white box testing kunnen doorschuiven naar QA testers als ze zelf de testcases hebben geschreven, maar dit leidt alleen maar tot slechte uitvoering en vermindert de kwaliteit van de documentatie.
4. Overhaast testen
Het testen van software is een lang en tijdrovend proces, en sommige ontwikkelaars kunnen in de verleiding komen om zich door white box tests te haasten om naar de volgende ontwikkelingsfase te gaan. Het is belangrijk om voldoende tijd en middelen uit te trekken voor white box testing, zodat ontwikkelaars zich niet opgejaagd voelen en voldoende tijd hebben om de testdekking te maximaliseren.
5. Slechte documentatie
Het bijhouden van goede documentatie voor, tijdens en na het testen zorgt ervoor dat iedereen die betrokken is bij de ontwikkeling en het testen van software op het juiste moment toegang heeft tot de juiste informatie.
Zorg ervoor dat elk lid van het ontwikkelingsteam weet hoe duidelijke documentatie te schrijven en hoe de resultaten van white box tests te rapporteren.
6. Onjuist gebruik van automatiseringshulpmiddelen
Automatiseringstools kunnen het uitvoeren van white box tests gemakkelijk maken, maar het is belangrijk ervoor te zorgen dat uw hele team begrijpt welke automatiseringstools u gebruikt en hoe u ze moet gebruiken.
Verschillende tools zijn geschikt voor verschillende soorten testen, dus het is belangrijk om automatiseringstools te kiezen die geschikt zijn voor white box testen en te leren hoe je hun functies goed kunt gebruiken.
Sommige tools integreren bijvoorbeeld geen automatisering en richten zich in plaats daarvan op het verzamelen van informatie en het organiseren van tickets, wat verre van ideaal is voor geautomatiseerd testen. Full-stack tools zoals ZAPTEST dekken daarentegen het hele testproces af met functies als Any Task Automation, waardoor ze geschikt zijn voor effectiever white box-testwerk.
7. Niet samenwerken met het QA team
Alleen omdat white box tests worden gepland en uitgevoerd door ontwikkelaars, betekent dit niet dat het QA-team er op geen enkele manier bij betrokken moet worden.
Het is belangrijk om de resultaten van white box testen door te geven aan het QA-team, zodat zij begrijpen wat er tot nu toe is getest en hoe de resultaten van white box testen van invloed kunnen zijn op de manier waarop het QA-team black box testen benadert.
Door het QA-team er niet bij te betrekken, introduceer je een potentiële kloof tussen verschillende afdelingen, wat leidt tot slechte communicatie en slechtere feedback later bij het testen. Het eindresultaat hiervan is een aanzienlijk lager kwaliteitsniveau van het eindproduct.
Soorten outputs van white box tests
Wanneer u white box software testen uitvoert, krijgt u verschillende outputs, afhankelijk van de resultaten van de tests die u uitvoert. Inzicht in deze resultaten van white box tests kan u helpen te begrijpen welke stappen u vervolgens moet nemen.
1. Testresultaten
De testresultaten van uw white box tests vertellen u of u verder moet gaan met testen, of er defecten zijn die moeten worden verholpen, en of elk individueel testgeval is geslaagd of mislukt. Grondige documentatie is noodzakelijk omdat het ontwikkelaars en testers helpt de resultaten van white box tests te begrijpen.
2. Gebreken
Bij white box tests kunnen defecten worden vastgesteld, en soms zal de output van uw white box tests defecten en bugs zijn.
Als het softwaresysteem zich tijdens white box tests niet gedraagt zoals u verwacht, kan dit erop wijzen dat er ernstige gebreken aan het programma zijn die moeten worden hersteld voordat de ontwikkeling en het testen worden voortgezet.
3. Testverslagen
Testrapporten zijn rapporten die door ontwikkelaars en testers worden opgesteld tijdens en na het testen van software.
Ze bevatten details over de resultaten van de test, waaronder welke testgevallen zijn geslaagd en welke niet, eventuele defecten die tijdens het testen zijn gevonden en aanbevelingen voor de volgende stappen.
Ontwikkelaars gebruiken testrapporten om te communiceren met andere ontwikkelaars wiens taak het kan zijn om bugs en fouten die tijdens het testen zijn gevonden, op te lossen.
Voorbeelden van white box tests
Met white box testing kunnen ontwikkelaars controleren of de interne structuur van het softwaresysteem werkt zoals het hoort, ongeacht de externe resultaten en output van het systeem.
De onderstaande voorbeelden illustreren hoe white box testing ontwikkelaars kan helpen om de interne functies van software te verifiëren.
1. E-commerce registratiepagina voorbeeld
Een voorbeeld van white box testing is hoe ontwikkelaars websitefuncties testen. Als u de registratiepagina van een e-commerce website probeert te testen, kunnen ontwikkelaars met white box testing nagaan of de functies en klassen die bij de registratie betrokken zijn, werken zoals ze zouden moeten werken wanneer de registratiefunctie wordt uitgevoerd.
Dit omvat specifiek alle informatie die een gebruiker invoert en beoordeelt de parameters achter het formulier, inclusief de data die wel en niet geldig zijn en wat het formulier ziet als een legitiem e-mailadres.
Het team voert dan een reeks strings in die de vorm testen, waarbij sommige ontworpen zijn om te mislukken en andere om te slagen, voordat de resultaten worden vergeleken met de voorspelde resultaten.
Bij black box testing daarentegen wordt alleen gecontroleerd of de pagina zelf werkt, zonder verdere analyse van het waarom of hoe.
2. Rekenvoorbeeld
Toepassingscalculators zijn een ander voorbeeld van white box testing.
Als u een rekenmachine maakt die wordt gebruikt als onderdeel van een toepassing, testen black box testers gewoon of de uitvoer van de rekenmachine correct is bij gebruik zoals bedoeld.
White box testers controleren de interne berekeningen van de rekenmachine om na te gaan hoe de output is berekend en of deze correct is. Dit is nuttiger voor complexere berekeningen met meerdere stappen, zoals belastingen. Testers onderzoeken de code om te zien welke stappen de rekenmachine neemt en in welke volgorde de stappen staan, voordat ze na elke stap het resultaat zien.
Als de input van de rekenmachine (7*4) – 6 is en de output 22, dan is dit correct, en zou de black box-test deze test doorstaan. Dit is echter omdat 7*4 = 28, en 28 – 6 is 22. Uit white box tests zou kunnen blijken dat de software dit resultaat heeft gevonden door 7*4 = 32, en 32 – 6 = 22, wat geen van beide correct is.
Dit grotere inzicht toont aan dat de berekening nauwkeurig is na elke specifieke fase, vindt de fase waarin deze mogelijk niet nauwkeurig is, en lost deze sneller op omdat de tester duidelijk kan zien waar het probleem zich voordoet.
Soorten fouten en bugs bij white box testing
Tijdens white box tests is het mogelijk om bugs te identificeren en te lokaliseren die van invloed kunnen zijn op de manier waarop systemen onder de motorkap werken. Deze bugs kunnen externe functies aantasten of de prestaties of betrouwbaarheid beïnvloeden.
Hieronder staan enkele van de meest voorkomende soorten fouten en bugs die optreden bij white box testing.
1. Logische fouten
Logische fouten ontstaan bij white box tests omdat white box tests gebieden aan het licht brengen waar het programma niet logisch functioneert of waar functies en voorwaarden binnen de code van de software verkeerd worden gebruikt.
Logische fouten kunnen zich voordoen als systeemfouten of gewoon leiden tot onverwachte gedragingen en outputs.
2. Ontwerpfouten
White box testing kan ontwikkelaars helpen ontwerpfouten in de code op te sporen. Ontwerpfouten ontstaan wanneer er een verschil is tussen de logische stroom van de software en de feitelijke uitvoering ervan. Ze kunnen leiden tot onverwacht gedrag en prestatiefouten.
3. Typografische fouten
Typografische fouten en syntaxfouten zijn fouten die ontstaan door een menselijke fout – bijvoorbeeld omdat een ontwikkelaar een bepaalde zin verkeerd heeft getypt of de verkeerde interpunctie aan een regel code heeft toegevoegd. Kleine fouten als deze kunnen leiden tot gebroken functies en verklaringen die de software niet kan lezen, wat grote fouten in het systeem kan veroorzaken.
Gemeenschappelijke white box testcriteria
Wanneer u white box tests uitvoert, kunnen gemeenschappelijke testcriteria u helpen om te meten hoe succesvol en uitgebreid uw white box tests zijn en om inzicht te krijgen in de kwaliteit van het werk van uw ontwikkelaars.
De testgegevens vormen een informatiebron voor het ontwikkelingsproces, omdat zij gebieden voor verbetering kunnen aanwijzen of het testproces in de toekomst kunnen sturen.
1. Code dekking
Een van de belangrijkste kenmerken van white box testing is dat het zoveel mogelijk van de code moet dekken, en je kunt meten hoeveel code je hebt gedekt met code coverage metrics.
Code coverage metrics laten zien hoeveel van de totale code van de applicatie u heeft geverifieerd met white box testing. In het algemeen streven ontwikkelaars ernaar zo dicht mogelijk bij 100% van de softwarecode te komen door middel van white box tests.
Code coverage kan worden onderverdeeld in verschillende metrieken, waaronder path, segment, statement en branch coverage.
Compound condition coverage is een ander type code coverage metric die controleert of elke voorwaarde binnen een set is gecontroleerd langs meerdere paden en combinaties van paden.
2. Tekortkomingen
De defectmetriek geeft aan hoeveel defecten er zijn gevonden, hoe goed uw white box testen zijn in het identificeren van defecten, en welke percentages van de code de white box testen doorstaan of niet.
De gebrekencijfers kunnen worden weergegeven als het aantal gebreken per duizend regels code of het aantal totale gebreken in het programma. Hoewel een laag aantal defecten positief lijkt, moeten ontwikkelaars ervoor zorgen dat dit niet komt doordat defecten bij het testen worden gemist.
3. Uitvoering van de test
Metrics over testuitvoering kunnen ontwikkelaars snel zien welk deel van de totale tests tot nu toe is uitgevoerd en hoeveel niet-uitgevoerde tests er nog zijn. Metrics voor tekstuitvoering helpen softwareteams te begrijpen hoe ver de voortgang van white box tests is en of geautomatiseerde softwaretests al dan niet verlopen zoals verwacht.
Er kunnen echter zowel fout-positieven als fout-negatieven zijn, die de nauwkeurigheid van deze metriek kunnen beïnvloeden.
4. Duur van de test
Testduurmetingen vertellen ons hoe lang het duurt om geautomatiseerde tests uit te voeren, wat vooral belangrijk is bij white box tests, omdat automatisering essentieel is om de efficiëntie en de dekking van tests te maximaliseren.
Testduur is vaak een knelpunt bij agile softwareontwikkeling, dus inzicht in de duur van softwaretests kan ontwikkelingsteams helpen het ontwikkelingsproces te versnellen.
Het is echter belangrijk te onthouden dat testduurmetingen niets zeggen over de kwaliteit van de tests die u uitvoert.
White box test tools
Tools en technologie kunnen white box tests aanzienlijk nauwkeuriger, efficiënter en uitgebreider maken. White box test tools kunnen software engineers helpen white box testen te automatiseren, het white box testproces vast te leggen en te documenteren, en white box testen van begin tot eind te beheren.
5 beste gratis white box testtools
Als u nog niet wilt investeren in dure white box testing tools, kunt u online een hele reeks gratis white box testing tools uitproberen zonder iets te betalen.
Gratis testtools bieden niet altijd dezelfde functionaliteit als enterprise tools, maar ze zijn een goed startpunt voor beginners in white box testing en ze kunnen ontwikkelteams helpen meer inzicht te krijgen in welke tools en technologieën ze nodig hebben.
1. ZAPTEST GRATIS editie
ZAPTEST is een software test tool en robotic process automation software waarmee ontwikkelaars en QA testers zowel white box testen als black box testen kunnen automatiseren.
De gratis versie van ZAPTEST maakt meerdere virtuele gebruikers, meerdere iteraties en ondersteuning van het gebruikersforum mogelijk. De applicatie werkt met zowel lokale als externe gegevensbronnen en integreert met HP ALM, Rally en JIRA. Gebruikers die het gratis aanbod van ZAPTEST goed vinden en meer willen zien van wat het bedrijf te bieden heeft, kunnen ook informeren naar een upgrade naar de bedrijfseditie zodra die klaar is.
2. Bugzilla
Bugzilla is een zeer populaire open-source software testing tool waarmee ontwikkelaars bugs en defecten in de software kunnen opsporen en de levenscyclus van bugs kunnen beheren.
Bugzilla maakt het gemakkelijk om bugs toe te wijzen aan ontwikkelaars, bugs te prioriteren en te verifiëren, en ze te sluiten zodra ze zijn opgelost. Bugzilla is een geweldig hulpmiddel voor teams die nog steeds proberen hun aanpak van bugrapportage te standaardiseren, en het is volledig gratis te gebruiken.
3. OpenGrok
OpenGrok is een open source codebrowser en zoekmachine voor codebase. Het is compatibel met code geschreven in Java C++, JavaScript en Python naast andere programmeertalen.
Als u tijdens white box tests snel door een grote codebase wilt kunnen navigeren, is OpenGrok volledig gratis en gemakkelijk te gebruiken.
4. SQLmap
SQLmap is een andere open source tool die bijna essentieel wordt geacht bij white box testen. SQLmap regelt de stroom van uitbuiting en opsporing van SQL-injectiebugs.
SQLmap, een zelf omschreven “penetratietesthulpmiddel”, kan white box testers helpen om beveiligingsfouten in de broncode te identificeren en te lokaliseren en deze te herstellen alvorens verder te gaan.
5. Emma
Emma is een open-source toolkit die je code coverage kan meten als je in Java werkt. Het is een supersnelle manier om snel uw codedekking vast te stellen en bij te houden hoeveel code elk lid van het ontwikkelingsteam individueel heeft afgedekt.
Emma ondersteunt klasse-, methode-, regel- en basisblokdekking en is volledig op Java gebaseerd.
5 Beste white box testtools voor ondernemingen
Als u op zoek bent naar tools die meer functionaliteit of betere ondersteuning bieden, zijn white box testing tools voor bedrijven wellicht beter geschikt voor uw ontwikkelingsteam.
1. ZAPTEST ENTERPRISE editie
De enterprise-editie van ZAPTEST is de opgevoerde versie van de gratis ZAPTEST. In deze versie kunnen gebruikers profiteren van grenzeloze OCR-sjablonen, grenzeloze iteraties en grenzeloze VBScript- en JavaScript-scripts.
De enterprise editie van ZAPTEST biedt een completer pakket aan tools voor ontwikkelteams die willen overstappen op automatisering, en de enterprise versie wordt ook geleverd met deskundige ondersteuning om ervoor te zorgen dat uw team het maximale uit de software testautomatisering en RPA-technologie van ZAPTEST haalt.
2. Fiddler
Fiddler is een pakket tools van Telerik dat gemaakt is voor het white box testen van webapplicaties. Fiddler kan al het HTTP-verkeer tussen uw systeem en het internet loggen en ingestelde breekpunten evalueren en uitgaande en inkomende gegevens aanpassen. Het is beschikbaar in verschillende formaten, afhankelijk van uw budget en behoeften, dus er is een Fiddler-editie voor bijna elk team.
3. HP Versterken
HP Fortify, voorheen bekend als Fortify, is een andere beveiligingstesttool die uitgebreide beveiligingsoplossingen biedt voor white box tests. De Fortify-suite van tools omvat de Fortify Source Code Analysis tool, die uw broncode automatisch scant op kwetsbaarheden die uw applicatie open kunnen stellen voor cyberaanvallen.
4. ABAP-eenheid
Met de ondernemingsversie van ABAP Unit kunnen softwareontwikkelaars snel en eenvoudig zowel handmatige als geautomatiseerde eenheidstests uitvoeren. Ontwikkelaars schrijven eenheidstests binnen de ABAP-toepassing en gebruiken deze tests om de functies van de code te controleren en fouten binnen de eenheidstests op te sporen.
Softwareteams die deze tool willen uitproberen, kunnen beginnen met de gratis versie van ABAP Unit alvorens over te stappen op de bedrijfseditie.
5. LDRA
LDRA is een eigen pakket hulpmiddelen dat kan worden gebruikt voor statement coverage, branch coverage en decision coverage bij het uitvoeren van white box tests. Het is een uitstekend hulpmiddel als u wilt controleren of uw broncode voldoet aan de standaardeisen voor compliance, tracing en codehygiëne.
Wanneer moet u enterprise gebruiken
versus freemium white box testing tools?
Zowel enterprise als freemium software testing tools hebben hun plaats in elk modern software ontwikkelings team. Naarmate uw team groeit en geautomatiseerd testen belangrijker wordt voor uw white box testaanpak, zult u waarschijnlijk willen upgraden van het werken met voornamelijk gratis testtools naar het werken met enterprise tools die meer functionaliteit en onbeperkte gebruiksmogelijkheden bieden.
Er zijn echter specifieke scenario’s waarin freemium tools geschikter kunnen zijn dan enterprise tools.
Veel ontwikkelaars kiezen ervoor om te beginnen met freemium tools wanneer ze experimenteren met nieuwe functies en technologieën, voornamelijk om te evalueren of deze technologieën goed passen bij hun team voordat ze investeren in enterprise technologieën.
U kunt ook gratis versies van enterprise tools zoals ZAPTEST uitproberen, zodat u ze kunt proberen voordat u ze koopt en meer te weten kunt komen over wat enterprise tools bieden.
Ten slotte zijn sommige freemium tools zoals Emma en Bugzilla gespecialiseerd in niche maar belangrijke functies die blijvende voordelen bieden, zelfs voor softwareteams die bereid zijn te betalen voor enterprise technologieën.
White box testing: checklist, tips en trucs
Als je klaar bent om white box tests uit te voeren, zorg er dan voor dat je alles hebt wat je nodig hebt voordat je begint. Hieronder volgt een lijst van dingen die u moet onthouden voordat u begint met white box testen om uw testdekking te maximaliseren en de nauwkeurigheid van uw white box testresultaten te verbeteren.
1. Gebruik automatiseringstools
Automatiseringstools kunnen de uitvoering van white box tests enorm versnellen, het foutenpercentage verlagen en de algehele nauwkeurigheid verhogen.
Bijna alle softwareteams gebruiken tegenwoordig een zekere mate van automatisering om white box tests uit te voeren, dus experimenteren met verschillende automatiseringstools en -technologieën voordat u begint met white box tests kan u helpen de tools te kiezen die u wilt gebruiken voordat het testen begint.
2. Streven naar 100% testdekking
U zult uw doel van 100% testdekking waarschijnlijk niet bereiken, maar het is het beste om dit cijfer zo dicht mogelijk te benaderen wanneer u white box tests uitvoert.
Gebruik hulpmiddelen voor testdekking om individuele meetgegevens zoals paddekking en takdekking bij te houden en te meten, en zorg ervoor dat alle belangrijke paden en takken binnen uw software zijn gedekt tijdens white box tests.
3. Duidelijke testrapporten opstellen
Net als bij andere vormen van softwaretests moet u ervoor zorgen dat uw team weet hoe het nauwkeurige en duidelijke testrapporten moet opstellen nadat elke testfase heeft plaatsgevonden.
Een testrapport moet in een gemakkelijk te begrijpen formaat worden geschreven en details van de testaanpak bevatten, alsmede een samenvatting van de outputs en resultaten van elk uitgevoerd testgeval. Het eindverslag moet de ondernomen stappen verantwoorden en aanbevelingen doen voor volgende stappen.
4. Meet uw succes met testgegevens
Testmetriek helpt softwareteams de voortgang van white box tests te volgen en vast te leggen en biedt waardevolle informatie voor toekomstige ontwikkelingsprocessen.
Het is belangrijk dat ontwikkelaars metrieken gebruiken om te begrijpen hoe effectief hun tests zijn en hoe schoon hun oorspronkelijke code was, zodat ze hun werk in de toekomst kunnen verbeteren.
White box testen:
Conclusie
White box testing in software engineering is een essentiële vorm van software testing die de interne structuur en logica van de broncode van een softwareapplicatie verifieert.
In combinatie met black box-tests wordt met white box-tests niet alleen vastgesteld dat de software werkt zoals verwacht, maar ook dat de interne code logisch, schoon en volledig is.
White box tests worden het vaakst uitgevoerd bij unit tests en integratietests, en worden altijd uitgevoerd door ontwikkelaars en software engineers met volledige kennis van de interne code van de software.
Hoewel sommige white box tests handmatig kunnen worden uitgevoerd, worden tegenwoordig veel white box tests geautomatiseerd vanwege de verbeteringen in snelheid, efficiëntie en dekking die white box testautomatisering biedt.
FAQ’s en hulpmiddelen
Als u meer wilt weten over white box testing, zijn er veel gratis online bronnen die u kunt raadplegen. U kunt video’s, boeken en andere bronnen gebruiken om uzelf te leren hoe u white box tests uitvoert en ervoor zorgen dat uw white box teststandaarden de beste praktijken volgen.
1. De beste cursussen over white box testautomatisering
Als u meer wilt leren over white box testautomatisering, kunt u een cursus volgen over softwaretesten en white box testen. Sommige van deze cursussen zijn geaccrediteerd en bieden formele kwalificaties, terwijl andere informele online cursussen zijn om ontwikkelaars en softwaretesters te helpen die hun kennis van een bepaald onderwerp willen verbeteren.
Enkele van de beste white box testing cursussen die vandaag online beschikbaar zijn, zijn:
2. Wat zijn de top vijf interviewvragen over white box testautomatisering?
Als je je voorbereidt op een interview waarin je misschien white box testing, white box technieken en automatiseringstools bespreekt, is het belangrijk dat je dat weet.
- Wat is het verschil tussen white box testen en black box testen?
- Waarom is white box testing belangrijk?
- Wat zijn enkele van de verschillende benaderingen van white box testing?
- Welke processen zijn betrokken bij white box testing en hoe kunnen we die verbeteren?
- Wat zijn enkele van de hulpmiddelen en technologieën die u zou kunnen gebruiken om white box tests sneller of nauwkeuriger te maken?
3. De beste YouTube tutorials over white box testen
Als je meer wilt leren over white box testing, kan het bekijken van YouTube-tutorials je helpen om te begrijpen hoe white box testing werkt en om visuele uitleg te zien van de processen en benaderingen die bij white box testing komen kijken.
Enkele van de meest informatieve YouTube tutorials online nu zijn:
- Udacity: Voorbeeld van white box testen
- Guru99: Wat is White Box Testing?
- White Box vs. Black Box Testen
- White Box Testtechnieken
- Software Testing Mentor: Wat is White Box Testing?
4. Hoe white box tests te onderhouden
Softwaretestonderhoud zorgt ervoor dat de tests die u uitvoert keer op keer grondig en doelmatig zijn. Het is belangrijk om alle soorten softwaretests te onderhouden, zowel blackbox als whitebox, omdat de code waarop u tests uitvoert voortdurend verandert bij elke bugreparatie en iteratie. Dit betekent dat uw testscripts mee moeten veranderen.
Het onderhouden van white box tests houdt in dat u uw testautomatiseringskader up-to-date houdt en dat u processen toepast die ervoor zorgen dat tests en testgevallen regelmatig worden bijgewerkt.
Je kunt dit doen door:
Onderhoud inbouwen in uw testontwerp:
Als u rekening houdt met de toekomst van white box tests wanneer u uw white box tests voor het eerst bouwt en ontwerpt, wordt het gemakkelijker om tests in de toekomst te onderhouden.
Duidelijke communicatie tussen teams mogelijk maken:
Zorg ervoor dat alle leden van uw ontwikkelingsteam over meerdere communicatiekanalen beschikken, zodat, zodra er wijzigingen in de code zijn aangebracht, deze snel in de tests kunnen worden verwerkt.
Wees flexibel:
Soms breng je wijzigingen aan in code die je niet gepland hebt. Zorg ervoor dat uw team weet hoe het zich snel aan deze veranderingen moet aanpassen en over de vaardigheden beschikt om deze veranderingen in tests op te volgen.
Testprotocollen voortdurend opnieuw evalueren:
De testprotocollen die u bij het begin van het testen hebt ingevoerd, zijn misschien niet meer geschikt wanneer uw software diverse wijzigingen en verbeteringen heeft ondergaan. Evalueer uw testprotocollen regelmatig om na te gaan of ze nog steeds goed passen.
5. De beste boeken over white box testen
White box testing is een diepgaand onderwerp dat jaren kan duren om onder de knie te krijgen. Als u een expert wilt worden op het gebied van moderne white box testing in software testing, kunt u boeken lezen over white box testing, geschreven door ontwikkelaars, academici en ingenieurs.
Enkele van de beste boeken over white box testing en testautomatisering van dit moment zijn:
- De kunst van het testen van software, derde editie door Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas.
- Software Testen: A Craftsman’s Approach, Fourth Edition, door Paul C. Jorgensen
- Hoe software te breken: Een praktische gids voor testen door James Whittaker
- De Just Enough Software Test Automation door Dan Mosley en Bruce Posey
Je zou deze boeken moeten kunnen vinden in sommige boekhandels en bibliotheken en ook online. U kunt ook ander leesmateriaal en leermiddelen vinden in de leeslijsten van goede software test cursussen en programma’s.
