Wat is grijs Box Testen? Technieken, voorbeeld

⚡ Slimme samenvatting

Grijs Box Bij testen wordt een applicatie onderzocht met gedeeltelijke kennis van de interne structuur. Het combineert het gebruikersgerichte perspectief van black-box testen met voldoende architectonisch inzicht om te verklaren waarom een fout is opgetreden, in plaats van alleen dát de fout is opgetreden.

🔍 Kennisniveau: De interne structuur is gedeeltelijk bekend, in tegenstelling tot volledig bekende structuren bij white-box-testen en onbekende structuren bij black-box-testen.
🧪 Vier technieken: Matrixtesten, regressietesten, orthogonale arraytesten en patroontesten vormen de kern van de instrumentarium.
🪜 Tien stappen: Identificeer de inputs, outputs en belangrijkste paden, verdeel het systeem vervolgens in subfuncties en controleer elk ervan.
🔗 Beste pasvorm: Integratietesten, penetratietesten, databasegestuurde workflows, webservices en API-configuratietracts.
Afweging: Gedeeltelijke zichtbaarheid vermindert de benodigde inspanning, maar beperkt tegelijkertijd hoe diep een enkel codepad kan worden doorgrond. traced..
📋 Voorwaarde: Nauwkeurige ontwerpdocumentatie is belangrijk, omdat een verouderd schema of specificatie het testontwerp ongemerkt ongeldig maakt.

Meer informatie

Wat is grijs Box Testen?

Grijs Box Testen (ook wel gespeld als Gray) Box Testen (Grey) is een softwaretesttechniek waarbij een softwareproduct of -applicatie wordt getest met gedeeltelijke kennis van de interne structuur van de applicatie. Het doel van Grey Box Testen is bedoeld om defecten op te sporen en te identificeren die worden veroorzaakt door een onjuiste codestructuur of onjuist gebruik van de applicatie.

Tijdens dit proces worden vaak contextspecifieke fouten met betrekking tot websystemen geïdentificeerd. De techniek verbetert de test dekking door zich te concentreren op alle lagen van een complex systeem in plaats van op slechts één ervan.

Grijs Box Testen is een softwaretestmethode die combineert Wit Box Testen en Zwart Box TestenHet verschil tussen de drie komt neer op hoeveel van de interne structuur de tester kan zien:

In het wit Box Het testen van de interne structuur (code) is bekend.
In het zwart Box De interne structuur (code) is niet getest.
In grijs Box Het testen van de interne structuur (code) is gedeeltelijk bekend.

Het onderstaande diagram plaatst de drie methoden op dezelfde schaal van zichtbaarheid.

In software engineering, Grijs Box Testen biedt de mogelijkheid om beide kanten van een applicatie te testen: zowel de presentatielaag als de code erachter. Het is vooral nuttig bij integratie testen en penetratietesten.

Voorbeeld van grijs Box testen: Bij het testen van een websitefunctie, zoals links of weeslinks, kan de tester, als hij een probleem met deze links tegenkomt, de wijziging direct in de HTML-code doorvoeren en in realtime controleren.

Waarom grijs? Box Testen

Grijs Box De tests worden om de volgende redenen uitgevoerd:

Het biedt de gecombineerde voordelen van zowel black-box-testen als white-box-testen.
Het combineert de inbreng van ontwikkelaars en testers en verbetert de algehele productkwaliteit.
Het vermindert de overheadkosten van het langdurige proces van het testen van functionele en niet-functionele typen.
Het geeft een ontwikkelaar voldoende vrije tijd om fouten te herstellen.
Het testen gebeurt vanuit het perspectief van de gebruiker, niet vanuit dat van de ontwerper.
Een fout kan worden verklaard in plaats van alleen gerapporteerd, omdat de tester de laag kan zien waar de fout is opgetreden.

Grijs Box Testen versus zwart Box versus Wit Box Testen

De drie methoden zijn niet zozeer concurrerende alternatieven, maar eerder drie toegangsniveaus, en elk beantwoordt een ander soort vraag. Door ze naast elkaar te plaatsen, wordt de keuze concreet.

Basis	Zwart Box Testen	Grijs Box Testen	Wit Box Testen
Kennis van de interne structuur	Geen	Partieel	Vol
Uitgevoerd door	Testers en eindgebruikers	Testers en ontwikkelaars die met testers samenwerken.	Ontwikkelaars en testengineers
Basis van het testontwerp	Eisen en specificaties	Archiarchitectuur, algoritmen, datastructuren en interfaces	Broncode en controlestroom
Typisch niveau	Systeem- en acceptatietesten	Integratie-, penetratie- en webservicetesten	Eenheid- en componenttesten
Dekking gemeten als	Vereistendekking	Interface-, data- en paddekking	Dekking van statements, vertakkingen en paden
Belangrijkste beperking	De oorzaak van een mislukking blijft verborgen.	De diepte wordt beperkt door de verleende toegang.	Kostbaar, en er kunnen ontbrekende vereisten over het hoofd worden gezien.

De meeste teams gebruiken ze alle drie. levenscyclus van softwaretestsEn de grijze laag is de plek waar de fouten die zich tussen de gebruikersinterface en de gegevensopslag bevinden, meestal worden opgevangen.

Grijs Box Strategie testen

Om Grey uit te voeren Box Bij het testen is het niet nodig dat de tester toegang heeft tot de broncode. Een test wordt ontworpen op basis van kennis van de algoritmen, architecturen, interne toestanden of andere beschrijvingen op hoog niveau van het programmagedrag.

Om Grey uit te voeren Box testen:

Het maakt gebruik van de eenvoudige technieken van black box-testen.
Het is gebaseerd op het genereren van testgevallen op basis van de vereisten, waardoor alle voorwaarden vooraf worden ingesteld voordat het programma wordt getest met behulp van de assertiemethode.

Technieken gebruikt voor Grijs Box De tests omvatten:

Matrixtesten: Deze techniek houdt in dat alle variabelen die in het programma voorkomen, worden gedefinieerd, samen met het risico dat aan elke variabele is verbonden, zodat ongebruikte en risicovolle variabelen zichtbaar worden.
Regressie Testing: Controleert of een wijziging in de vorige versie andere aspecten van het programma in de nieuwe versie negatief heeft beïnvloed. Dit gebeurt met strategieën zoals het volledig opnieuw testen, het opnieuw testen van risicovolle gebruiksscenario's en het opnieuw testen binnen een firewall.
Orthogonale array-testen of OAT: Biedt maximale codedekking met een minimaal aantal testgevallen.
Patroon testen: uitgevoerd op historische gegevens van eerdere systeemdefecten. In tegenstelling tot black-box-testen, Grey Box Testen analyseert de code grondig en bepaalt de oorzaak van de fout.

Grijs Box De methodologie maakt doorgaans gebruik van geautomatiseerde systemen. hulpprogramma's voor het testen van software Om de tests uit te voeren, worden stubs en modulestuurprogramma's aangemaakt, zodat de tester de code niet handmatig hoeft te genereren.

Stappen om Grey uit te voeren Box De tests omvatten:

Stap 1: Identificeer de invoergegevens.
Stap 2: Identificeer de output.
Stap 3: Identificeer de belangrijkste routes.
Stap 4: Subfuncties identificeren.
Stap 5: Ontwikkel invoer voor de subfuncties.
Stap 6: Ontwikkel outputs voor de subfuncties.
Stap 7: Voer de testcase voor de subfuncties uit.
Stap 8: Controleer of het resultaat voor de subfuncties correct is.
Stap 9: Herhaal stappen 4 tot en met 8 voor de andere subfuncties.
Stap 10: Herhaal stap 7 en 8 voor de andere subfuncties.

De testgevallen voor Grey Box Testen kan onder andere betrekking hebben op de gebruikersinterface, beveiliging, databases, browsers en besturingssystemen. Elk gegenereerd testgeval vereist nog steeds de gebruikelijke controle. testcase attributen, aangezien een geval dat niet kan worden gereproduceerd op basis van de eigen beschrijving weinig nut heeft tijdens regressietests.

Waar grijs Box Testen wordt gebruikt

Deze techniek is nuttig in situaties waar een defect alleen kan worden vastgesteld door twee lagen tegelijk te bekijken. De techniek wordt het vaakst toegepast in de volgende scenario's:

Databasegestuurde workflows: Een actie wordt uitgevoerd via de gebruikersinterface, waarna de resulterende rijen direct worden opgevraagd om te bevestigen dat de waarden, typen en relaties correct zijn opgeslagen.
Webdiensten en API's: Er wordt een verzoek verzonden en de responsstatus, headers en payload worden vergeleken met de gepubliceerde context.tract, wat de alledaagse vorm is van API-testen.
Integratiepunten: Berichten die de grens tussen twee modules overschrijden, worden gecontroleerd terwijl beide modules als actieve systemen worden beschouwd in plaats van als bronbestanden.
Beveiligingsbeoordeling: Een penetratietester die een normaal gebruikersaccount en een architectuuroverzicht krijgt, simuleert de positie van een insider, wat het standaard grey box-engagementmodel is.
Webapplicaties en grafische gebruikersinterfaces (GUI's): Kapotte links, weespagina's, sessiebeheer en client-side validatie worden allemaal gecontroleerd met gedeeltelijk inzicht in de markup en de aanvraagstroom.

Al deze factoren samen zorgen ervoor dat de totale kosten van systeemdefecten lager uitvallen, omdat problemen worden opgespoord en verklaard voordat ze verder in het proces terechtkomen. systeem testen of productie.

Grijs Box testtools

Geen enkel gereedschap presteert zoals Grey. Box Testen op zich. Wat deze categorie nodig heeft, is een combinatie van een interface-driver, een inspectietool voor de onderliggende laag en een manier om die twee samen te scripten.

API- en webserviceclients zoals Postman en SoapUI, gebruikt om verzoeken te versturen en beweringen te doen over statuscodes en antwoordinhoud.
Databaseclients en SQL-querytools, gebruikt om de opgeslagen status na een interfaceactie te verifiëren.
Ontwikkelaarstools voor browsers en HTTP-proxy's zoals Burp Suite, gebruikt om verzoeken te inspecteren en te wijzigen tijdens beveiligingsgerichte sessies.
UI-automatiseringsframeworks zoals Selenium, gebruikt om de presentatielaag binnen een aan te sturen automatisering testen op.
Log- en monitoringtools, gebruikt om een waargenomen storing te correleren met wat de applicatie op dat moment intern registreerde.

De keuze is minder belangrijk dan de bekabeling: tenzij de interface-driver en de inspectiestap in hetzelfde script worden uitgevoerd, resulteert dit in twee afzonderlijke handmatige controles in plaats van één test met een grijze doos.

Grijs Box Uitdagingen testen

Gedeeltelijke zichtbaarheid introduceert problemen die geen van beide zuivere methoden kent, en de volgende problemen komen teams het vaakst tegen:

Wanneer een te testen component een storing ondervindt, kan dit de lopende bewerking afbreken en de rest van de reeks niet uitvoeren.
Een test kan volledig worden uitgevoerd terwijl de inhoud van het resultaat onjuist is. Daarom moet de verificatiestap de waarden controleren in plaats van de voltooiing.
Volledige codedekking is niet haalbaar, omdat de tester nooit elke vertakking ziet die bij white-box testen wel bereikt zou worden.
De ontwerpdocumentatie waarop de tests gebaseerd zijn, kan verouderd zijn, en een verouderd schema of interfacespecificatie kan het testontwerp ongemerkt ongeldig maken.
Testers moeten zowel domeinkennis als diepgaande technische expertise bezitten, wat een beperkter vaardigheidsprofiel oplevert voor werving.
Verspreid en sterk abstracDoor de complexe architectuur is het lastig om een geconstateerde storing toe te schrijven aan een specifiek intern onderdeel.

Deze beperkingen pleiten voor behandeling van Grey. Box Testen is slechts één laag van de vele, en geen vervanging voor de andere lagen, wat ook het punt is dat in de bredere context wordt gemaakt. software testtechnieken en soorten softwaretestenHet past er vanzelfsprekend naast. functioneel testen en specificatiegestuurde benaderingen zoals modelgebaseerd testen.

Veelgestelde vragen

Beide termen verwijzen naar dezelfde techniek. Grey is de Britse spelling en gray de Amerikaanse, en de twee worden door elkaar gebruikt in documentatie en certificeringsprogramma's voor gereedschappen. Geen van beide heeft een andere technische betekenis.

Voldoende inzicht in de interne werking zonder elke regel te hoeven lezen: architectuurdiagrammen, het datamodel, interfaceconfiguratietracts en een alleen-lezen account op de testdatabase. Volledige toegang tot de repository maakt van de oefening een white-box test.

Meestal is dit een testengineer met een ontwikkelingsachtergrond, of een tester die voor de sessie samenwerkt met een ontwikkelaar. Beveiligingstests worden uitgevoerd door penetratietesters die een standaard gebruikersaccount en een architectuurbriefing krijgen.

Gebaseerd op interfaces en data in plaats van statements: elk eindpunt en elke statuscode die wordt aangeroepen, elke tabel en elke statusovergang die wordt aangeraakt, elk integratiepad dat wordt doorlopen. Statement- en branchpercentages behoren tot white-box-metingen.

Een stub vervangt een component dat door de te testen module wordt aangeroepen; een driver vervangt het component dat deze stub zou aanroepen. Samen maken ze het mogelijk om een subfunctie geïsoleerd te testen voordat het volledige systeem bestaat.

Wanneer een onafhankelijk oordeel vanuit het gebruikersperspectief vereist is, omdat gedeeltelijke kennis de tester bevooroordeelt ten gunste van verwachte scenario's, blijven acceptatietesten en gebruiksvriendelijkheidsonderzoek om die reden black box-analyses. Ook veiligheidskritieke code vereist nog steeds een volledige white box-analyse.

Machine learning analyseert de defectgeschiedenis voor de patroonherkenningsstap, rangschikt interfaces op basis van voorspeld risico zodat beperkte toegang efficiënt wordt benut, en groepeert logbestanden om een waargenomen storing te koppelen aan het interne onderdeel dat deze heeft veroorzaakt.

Ja, voor de herhalende onderdelen: request builders, response assertions, verificatiequeries, stubs en drivers die zijn opgesteld op basis van een interfacedefinitie. Beslissen welke interne status het correcte gedrag bewijst, blijft een ontwerpbeslissing van de engineer.