Vad är Grey Box Testning? Tekniker, exempel

Vad är Grey Box Testning?

Grå Box Testning (även stavat Grå Box Testing) är en teknik för mjukvarutestning som testar en mjukvaruprodukt eller applikation med delvis kunskap om applikationens interna struktur. Syftet med Grey Box Testning går ut på att söka efter och identifiera fel som orsakas av felaktig kodstruktur eller felaktig användning av applikationen.

I denna process identifieras ofta kontextspecifika fel relaterade till webbsystem. Tekniken ökar testtäckning genom att koncentrera sig på alla lager i ett komplext system snarare än på ett av dem.

Grå Box Testning är en metod för mjukvarutestning som kombinerar Vit Box Testning och Svart Box TestningSkillnaden mellan de tre beror på hur mycket av den interna strukturen testaren kan se:

• I vitt Box Att testa den interna strukturen (koden) är känt.
• I svart Box Testning av den interna strukturen (koden) är okänd.
• I Grått Box Testning av den interna strukturen (koden) är delvis känd.

Diagrammet nedan placerar de tre metoderna på samma synlighetsskala.

In mjukvaruutveckling, Grå Box Testning ger möjlighet att testa båda sidor av en applikation, presentationslagret såväl som koden bakom det. Det är främst användbart i integrationstest och penetrationstestning.

Exempel på grått Box Testning: Om testaren stöter på problem med länkarna när en webbplatsfunktion testas, såsom länkar eller föräldralösa länkar, kan ändringen göras direkt i HTML-koden och kontrolleras i realtid.

Varför grå Box Testning

Grå Box Testning utförs av följande skäl:

• Det ger de kombinerade fördelarna med både black box-testning och white box-testning.
• Det kombinerar input från både utvecklare och testare och förbättrar den övergripande produktkvaliteten.
• Det minskar omkostnaderna för den långa processen att testa funktionella och icke-funktionella typer.
• Det ger en utvecklare tillräckligt med fritid för att åtgärda fel.
• Testning görs ur användarens synvinkel snarare än designerns synvinkel.
• Ett fel kan förklaras snarare än bara rapporteras, eftersom testaren kan se lagret där det inträffade.

Grå Box Testning vs svart Box mot Vit Box Testning

De tre metoderna är inte konkurrerande alternativ utan snarare tre åtkomstnivåer, och var och en besvarar en annan typ av fråga. Att ställa dem sida vid sida gör valet konkret.

De flesta lag använder alla tre över hela livscykel för mjukvarutestning, och det gråa boxlagret är där defekterna som faller mellan användargränssnittet och datalagret vanligtvis fångas.

Grå Box Teststrategi

Att utföra Grå Box Vid testning är det inte nödvändigt för testaren att ha tillgång till källkoden. Ett test utformas baserat på kunskap om algoritmer, arkitekturer, interna tillstånd eller andra övergripande beskrivningar av programbeteende.

Att utföra Grå Box Testning:

• Den tillämpar de enkla teknikerna för black box-testning.
• Den är baserad på kravdriven testfallsgenerering, så den förinställer alla villkor innan programmet testas med assertion-metoden.

Tekniker som används för grått Box Testningen är:

• Matristestning: Den här tekniken innebär att alla variabler som finns i programmet definieras, tillsammans med den risk som varje variabler medför, så att oanvända och högriskvariabler är synliga.
• Regressionstestning: kontrollerar om en ändring i den tidigare versionen har påverkat andra aspekter av programmet negativt i den nya versionen. Det görs med strategier som att testa om alla, testa om riskfyllda användningsfall och testa om inom en brandvägg.
• Ortogonal arraytestning eller HAVRE: ger maximal kodatäckning med ett minimalt antal testfall.
• Mönstertestning: utförs på historiska data från tidigare systemfel. Till skillnad från black box-testning, Grey Box Testning gräver i koden och fastställer varför felet inträffade.

Grå Box metodiken använder vanligtvis automatiserad testverktyg för programvara för att utföra testningen. Stubbar och moduldrivrutiner skapas så att testaren inte behöver generera koden manuellt.

Steg för att utföra Grey Box Testningen är:

• Steg 1: Identifiera ingångar.
• Steg 2: Identifiera utgångarna.
• Steg 3: Identifiera de viktigaste vägarna.
• Steg 4: Identifiera delfunktioner.
• Steg 5: Utveckla indata för delfunktionerna.
• Steg 6: Utveckla utdata för delfunktionerna.
• Steg 7: Kör testfallet för delfunktionerna.
• Steg 8: Verifiera korrekt resultat för delfunktionerna.
• Steg 9: Upprepa steg 4 till 8 för de andra delfunktionerna.
• Steg 10: Upprepa steg 7 och 8 för de andra delfunktionerna.

Testfallen för Grey Box Testning kan bland annat omfatta problem med gränssnitt, säkerhet, databas, webbläsare och operativsystem. Varje genererat fall behöver fortfarande de vanliga testfall attribut, eftersom ett fall som inte kan reproduceras från sin egen beskrivning är av liten nytta under regression.

Där grå Box Testning används

Tekniken förtjänar sin plats överallt där en defekt endast kan diagnostiseras genom att titta på två lager samtidigt. Följande scenarier är de som den oftast tillämpas på:

• Databasbaserade arbetsflöden: en åtgärd utförs via användargränssnittet, och de resulterande raderna frågas sedan direkt för att bekräfta att värdena, typerna och relationerna lagrades som avsett.
• Webbtjänster och API:er: en begäran skickas och svarsstatus, rubriker och nyttolast kontrolleras mot den publicerade kontract, vilket är den vardagliga formen av API-testning.
• Integrationspunkter: Meddelanden som korsar en gräns mellan två moduler inspekteras medan båda modulerna behandlas som körande system snarare än som källfiler.
• Säkerhetsbedömning: En penetrationstestare med ett normalt användarkonto och en arkitekturöversikt reproducerar positionen för en insider, vilket är standardmodellen för grå rutor.
• Webbapplikationer och grafiska gränssnitt: Trasiga länkar, föräldralösa sidor, sessionshantering och klientsidesvalidering kontrolleras alla med delvis insyn i markupen och förfrågningsflödet.

På alla dessa områden minskar den totala kostnaden för systemfel eftersom problem upptäcks och förklaras innan de går vidare i processen till systemtestning eller produktion.

Grå Box Testverktyg

Inget verktyg presterar grått Box Testning av sig själv. Vad kategorin behöver är en kombination av en gränssnittsdrivrutin, ett inspektionsverktyg för lagret under och ett sätt att skripta de två tillsammans.

• API- och webbtjänstklienter såsom Postman och SoapUI, används för att utfärda förfrågningar och göra gällande statuskoder och svarstexter.
• Databasklienter och SQL-frågeverktyg, används för att verifiera bestående tillstånd efter en gränssnittsåtgärd.
• Verktyg för webbläsarutveckling och HTTP-proxyservrar såsom Burp Suite, används för att inspektera och ändra förfrågningar under säkerhetsorienterade sessioner.
• Ramverk för UI-automation såsom Selenium, används för att driva presentationslagret inuti en automatiseringstestning på.
• Logg- och övervakningsverktyg, används för att korrelera ett observerat fel med vad applikationen registrerade internt vid det ögonblicket.

Valet spelar mindre roll än kabeldragningen: om inte gränssnittsdrivrutinen och inspektionssteget körs i samma skriptade flöde blir resultatet två separata manuella kontroller snarare än ett grårutetest.

Grå Box Testa utmaningar

Delvis insyn introducerar problem som ingen av de rena metoderna har, och följande är de som teamen stöter på oftast:

• När en komponent som testas drabbas av något slag kan den avbryta den pågående operationen och lämna resten av sekvensen oexekverad.
• Ett test kan köras i sin helhet medan innehållet i resultatet är felaktigt, så verifieringssteget måste kontrollera värden snarare än slutföra.
• Fullständig täckning av kodsökvägen är inte uppnåelig, eftersom testaren aldrig ser varje gren som white box-testning skulle nå.
• Designdokumentationen som testerna förlitar sig på kan vara inaktuell, och ett föråldrat schema eller en gränssnittsspecifikation ogiltigförklarar i tysthet testdesignen.
• Testare behöver både domänförståelse och teknisk djup, vilket är en snävare kompetensprofil att rekrytera för.
• Distribuerad och kraftig magmuskulaturtracTed-arkitekturer gör det svårt att tillskriva ett observerat fel till en specifik intern komponent.

Dessa begränsningar talar för att behandla grå Box Testning som ett lager bland flera snarare än en ersättning för de andra, vilket är poängen som görs i den bredare uppsättningen av tekniker för mjukvarutestning och typer av mjukvarutestningDen sitter naturligt bredvid funktionstestning och specifikationsdrivna metoder som modellbaserad testning.

Vanliga frågor