Black-box- versus white-box-testen: vergelijking door experts
Het verschil tussen white-box- en black-box-testen
Black-box-testen evalueert de functionaliteit van software zonder kennis van de interne code, met de nadruk op invoer en uitvoer. Bij white-box-testen worden de interne codestructuur en logica onderzocht, waarvoor toegang tot de broncode nodig is.
Black-box-testen worden doorgaans uitgevoerd door QA-teams om functionaliteit die aan gebruikers wordt aangeboden te valideren, met technieken zoals equivalentiepartitionering en grenswaardenanalyse.
White-box-testen daarentegen worden uitgevoerd door ontwikkelaars om de correctheid en dekking van de code te waarborgen, met methoden zoals instructie- en takdekking.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Door beide benaderingen te combineren, worden de testdekking en softwarekwaliteit verbeterd.
In dit bericht leid ik je door beide testtypen. Ik leg uit wat ze zijn, wat de belangrijkste verschillen ertussen zijn, hoe ze worden gebruikt en wat hun voor- en nadelen zijn.
Wat zijn black-box-testen?
Black-box-testen, ook wel gedragstesten genoemd, zijn een type softwaretest waarbij de tester geen toegang heeft tot de broncode van het systeem dat wordt getest. Ze worden meestal uitgevoerd door het kwaliteitsborgingsteam en vereisen niet noodzakelijk geavanceerde technische vaardigheden, zoals programmeren.
Bij black-box-testen worden de testgevallen geschreven op basis van de invoer en uitvoer van de AUT, zoals vastgelegd in de requirementspecificaties.
De meest opmerkelijke black-box-testtechnieken zijn:
- Equivalentiepartitionering: hierbij worden de invoerwaarden ingedeeld in equivalentieklassen (of partities), wat betekent dat elke waarde binnen een klasse dezelfde uitvoer oplevert. Voor een goede testdekking is één testgeval per equivalentieklasse voldoende.
Voorbeeld: Als een veld gehele getallen tussen 1 en 10 accepteert, bevat de geldige klasse alle getallen tussen 1 en 10. De twee ongeldige klassen zijn getallen kleiner dan 1 en getallen groter dan 10. Dit betekent dat in totaal 3 testgevallen voldoende zijn om alle mogelijke klassen te dekken.
- Grenswaardenanalyse: hierbij worden de uiterste invoerwaarden getest, omdat deze eerder defecten veroorzaken.
Voorbeeld: Voor hetzelfde veld als hierboven zijn de geldige grenswaarden 1 en 10, en de ongeldige grenswaarden 0 en 11.
- Testen met beslissingstabellen: hierbij worden de relaties tussen invoer en uitvoer in tabelvorm weergegeven. De tabel bevat doorgaans kolommen voor voorwaarden en rijen voor de verschillende combinaties. Elke rij moet een bijbehorend testgeval hebben.
Voorbeeld: Deze techniek is geschikt voor complexere scenario's. Stel dat we een aanvraag voor een banklening hebben met de volgende voorwaarden:
| Voorwaarden | Leeftijd gelijk aan of hoger dan 25 | Inkomen gelijk aan of hoger dan 50000 USD | Resultaat |
|---|---|---|---|
| 1 | Waar | Waar | Lening goedkeuren |
| 2 | Waar | Onwaar | Lening afwijzen |
| 3 | Onwaar | Onwaar | Doorverwijzen naar een manager |
| 4 | Onwaar | Onwaar | Lening afwijzen |
Er zijn vier mogelijke combinaties, dus er moeten vier testgevallen worden uitgevoerd.
- Testen van toestandsveranderingen: hiermee wordt het gedrag van een systeem gecontroleerd wanneer het tussen verschillende toestanden wisselt.
Voorbeeld: Stel dat je een eenvoudige bugtracker test. Het toestandsdiagram is:
De beschikbare overgangen zijn:
- Van Nieuw naar In behandeling
- Van In behandeling naar In test
- Van In test naar Gesloten
- Van In test terug naar In behandeling
Voor volledige dekking moet je ervoor zorgen dat elke overgang en elke toestand minstens één keer wordt getest.
- Op ervaring gebaseerd testen, zoals verkennend testen. Bij dit type testen worden tests uitgevoerd op basis van de ervaring van de tester met het systeem of met vergelijkbare systemen, en van kennis van het gedrag van de app.
Voorbeeld: Stel je voor dat je een nieuwe socialmedia-applicatie test. Je doel is om de applicatie te verkennen en defecten of problemen te vinden die moeten worden aangepakt.
Tijdens verkennend testen zou je de volgende acties kunnen uitvoeren:
- Een nieuw account aanmaken
- Een profielfoto uploaden
- Een bericht schrijven
- Je eigen profiel bekijken
- Vrienden zoeken
- Een vriendschapsverzoek versturen
- Een vriendschapsverzoek accepteren
- Een bericht leuk vinden en erop reageren
Bij verkennend testen zou je deze acties ongestructureerd uitvoeren, zonder een vooraf opgesteld plan. De focus zou liggen op het vinden van defecten of verbeterpunten in de applicatie.
Als je meer wilt leren over verkennend testen, vond ik het boek van Elisabeth Hendrickson, Explore It!, erg nuttig.
Voor- en nadelen van testen met gesloten doos
Natuurlijk zijn er zowel voordelen als nadelen aan het uitvoeren van testen met gesloten doos.
Voordelen:
- Het kost meer tijd
- De controle over testgevallen is beperkt
- Sommige specifieke scenario's kunnen moeilijk te testen zijn
- Beperkte informatie over de hoofdoorzaak van een fout
- Kan bepaalde fouten missen
- Beperkte mogelijkheden om prestaties en schaalbaarheid te testen
Nadelen:
- Het voorbereiden van de testomgeving en het uitvoeren van de tests kan meer tijd kosten
- De controle over testgevallen is beperkt
- Sommige specifieke scenario's kunnen moeilijk te testen zijn
- Beperkte informatie over de hoofdoorzaak van een fout
- Kan bepaalde fouten missen
- Beperkte mogelijkheden om prestaties en schaalbaarheid te testen
Wanneer gebruik je testen met gesloten doos?
Hulpmiddelen voor testen met gesloten doos kunnen op elk testniveau worden gebruikt. Het is echter beter om ze op een hoger niveau te gebruiken en het testen op een lager niveau over te laten aan testen met open doos. Dit betekent dat de methodologie voor testen met gesloten doos weliswaar kan worden gebruikt om op unitniveau te testen, maar geschikter is voor systeemtesten en acceptatietesten.
Technieken voor testen met gesloten doos kunnen worden gebruikt voor functionele en niet-functionele tests, zoals prestatietests, bruikbaarheid en toegankelijkheid.
Ze moeten ook worden toegepast op nieuw geïmplementeerde functionaliteiten. Bestaande testgevallen die met deze technieken zijn geïdentificeerd, kunnen tijdens regressietests worden uitgevoerd.
Wat zijn testen met open doos?
Testen met open doos (soms ook testen met transparante doos, testen met glazen doos, codegebaseerd testen of structureel testen genoemd) is een testmethode die zich richt op de interne werking van de UAT.
Benaderingen voor testen met open doos:
- Dekking van instructies: alle code-instructies (coderegels) worden op broncodeniveau ten minste één keer uitgevoerd. De formule om de dekking te berekenen is:
Dekking van instructies = (Aantal uitgevoerde instructies / Totaal aantal instructies in de broncode) * 100
Voorbeeld: Stel dat we de volgende code hebben:
if(condition1 or condition2)) {
print(“test 1 OK”)
}
else {
if(condition3) {
print(“test 2 OK”)
}
}
- Voor volledige dekking van de instructies moet je elke coderegel ten minste één keer doorlopen. Dit betekent dat een aantal tests nodig is:
- condition1=true condition2=false, waarmee “test 1 OK” wordt afgedrukt
- condition1=false, condition2=false en condition3=true, waarmee “test 2 OK” wordt afgedrukt.
- Takdekking: bij deze techniek dekken de testscenario's alle vertakkingen van de controlestroomgrafiek. Elke mogelijke true- en false-uitkomst van een conditie wordt ten minste één keer afgedekt. De formule voor takdekking is:
- Dekking van vertakkingen = (Aantal uitgevoerde vertakkingen / Totaal aantal vertakkingen in de code) * 100
- Voorbeeld: Voor dezelfde code is de instructiedekking 100%, maar zijn niet alle mogelijke vertakkingen gedekt. Je hebt een aanvullende test nodig waarbij:
- condition1=false, condition2=false, condition3=false - op deze manier dekken we ook het valse pad in de tweede if af. In deze testcase mag niets worden afgedrukt,
- Conditiedekking: een uitgebreide techniek waarbij alle paden worden getest. Deze zorgt ervoor dat elk toepassingspad door ten minste één test wordt afgedekt. Dit is vooral nuttig voor complexe apps. Voorbeeld: Voor de bovenstaande code hebben we nog één test nodig voor volledige conditiedekking:
- condition1=false, condition1=true, wat dezelfde uitkomst heeft als de eerste test, maar een andere conditie afdekt om het resultaat te bereiken.
Voor- en nadelen van testen met kennis van de interne code
Laten we de voor- en nadelen van testen met kennis van de interne code bekijken.
Voordelen:
- Kan fouten vroeg in de levenscyclus van softwareontwikkeling opsporen
- Test de interne codestructuur.
- Test codedekking en logica.
- Vergroot de kennis van de codebasis.
- Kan worden gebruikt bij prestatie- en schaalbaarheidstests.
Nadelen:
- Werkt beter op een lager testniveau
- Vereist een goede kennis van de programmeertaal van het systeem
- Beperkte testmogelijkheden vanuit het perspectief van de eindgebruiker
- Kan praktijkscenario's over het hoofd zien
Wanneer testen met kennis van de interne code gebruiken
Tests met kennis van de interne code zijn het meest geschikt voor lagere niveaus, zoals unit- en integratietests. Dit helpt om fouten en defecten vroeg in het ontwikkelingsproces te identificeren. Het is een goed idee om deze tests na elke implementatie uit te voeren, vooral wanneer je in een CI/CD-omgeving werkt.
Testen met kennis van de interne code kan worden gebruikt om functionaliteit te testen, maar ook om kwetsbaarheden in het systeem aan het licht te brengen - iets wat moeilijk te bereiken zou zijn met technieken voor testen van buitenaf.
Testen van buitenaf versus testen met kennis van de interne code: samenvatting
Laten we bekijken wat de belangrijkste verschillen zijn tussen testen van buitenaf en testen met kennis van de interne code:
| Testen van buitenaf | Testen met kennis van de interne code |
| Er is geen kennis van de interne werking nodig. | Is gebaseerd op een goed begrip van de code van het systeem. |
| Wordt meestal uitgevoerd door het QA-team. | Wordt meestal uitgevoerd door de ontwikkelaars. |
| Richt zich op het gedrag van het systeem. | Richt zich op de logica en implementatie van de software. |
| Technieken zijn onder andere: Equivalentieklassen Grenswaardeanalyse Beslissingstabel Toestands-overgang | Technieken zijn onder andere: Instructiedekking Dekking van vertakkingen Conditiedekking |
| Scenario's kunnen handmatig of geautomatiseerd worden uitgevoerd. | Wordt meestal uitgevoerd met behulp van geautomatiseerd testen. |
| Is beter geschikt voor hogere testniveaus. | Werkt het best op lagere testniveaus. |
| Test vanuit het perspectief van de eindgebruikers. | Test vanuit een technisch perspectief. |
Maar laten we niet vergeten dat beide benaderingen voor- en nadelen hebben. We moeten ze allebei in ons testproces gebruiken voor een goede test- en codedekking en om de belangrijkste defecten te vinden.
Conclusies
Testen van buitenaf en testen met kennis van de interne code zijn twee verschillende benaderingen die tijdens het ontwikkelingsproces aan verschillende behoeften voldoen. Hoewel testen met kennis van de interne code meestal door ontwikkelaars wordt uitgevoerd en van toepassing is op tests op een lager niveau, en testen van buitenaf door het QA-team op hogere niveaus wordt uitgevoerd, werken ze het best wanneer ze samen worden gebruikt.
Als je dit artikel interessant vond, abonneer je dan op de nieuwsbrief om alle nieuw gepubliceerde artikelen over testen en kwaliteitsborging te ontvangen!
