White Box Testing: En komplett guide med tekniker, exempel och verktyg

white box testing complete guide with techniques

Vad är White Box Testing?

Om vi ​​går efter definitionen är 'White box testing' (även känd som klar, glaslåda eller strukturell testning) en testteknik som utvärderar koden och den interna strukturen i ett program.

Testning av vitlåda innebär att man tittar på kodens struktur. När du känner till produktens interna struktur kan test utföras för att säkerställa att de interna operationerna utförs enligt specifikationen. Och alla interna komponenter har utnyttjats tillräckligt.

Vad du kommer att lära dig:

• Min erfarenhet
  • Rapportering
  • Varför utför vi WBT?
  • Kräver denna testning detaljerad programmeringskunskap?
  • Begränsningar
• Skillnaden mellan White-Box och Black-Box Testing
• Steg för att utföra WBT
• Typer och tekniker för White Box Testing
• White Box Testing Exempel
• White Box Testing Tools
• Slutsats
• Rekommenderad läsning

Min erfarenhet

Det är nästan ett decennium nu sedan jag är intresserad av programvarutestning och hittills märkt att testarna är de mest entusiastiska i hela programvaruindustrin.

Den främsta anledningen bakom detta är - testaren har alltid något i sitt utrymme att lära sig. Vare sig det är en domän, process eller en teknik, en testare kan ha en fullständig utveckling om de vill.

Men som de säger 'Det finns alltid en mörkare sida' .

Testare undviker också verkligen en typ av test som de tycker är mycket komplicerade och utvecklarens bit. Ja, 'White Box Testing'.

Rapportering

White Box Testing täcker specifikationen i koden:

1. Kodtäckning

2. Segment täckning: Se till att varje koduttal körs en gång.

3. Testning av grengrenar eller noder: Täckningen av varje kodgren från alla möjliga var.

4. Täckning av sammansatt tillstånd: För flera förhållanden testa varje tillstånd med flera vägar och en kombination av de olika vägarna för att nå det tillståndet.

5. Grundvägstestning: Varje oberoende väg i koden tas för testning.

6. Dataflödestestning (DFT): I detta tillvägagångssätt spårar du de specifika variablerna genom varje möjlig beräkning, vilket definierar uppsättningen mellanvägar genom koden. DFT tenderar att återspegla beroenden, men det är huvudsakligen genom sekvenser av datamanipulation. Kort sagt, varje datavariabel spåras och dess användning verifieras. Detta tillvägagångssätt tenderar att avslöja buggar som variabler som används men inte initialiseras, eller deklareras men inte används, och så vidare.

7. Bantestning: Vägtestning är där alla möjliga vägar genom koden definieras och täcks. Det är en tidskrävande uppgift.

8. Loop Testing: Dessa strategier avser testning av enstaka slingor, sammanhängande slingor och kapslade slingor. Oberoende och beroende kodslingor och värden testas med denna metod.

Varför utför vi WBT?

Att försäkra:

• Att alla oberoende vägar i en modul har utövats minst en gång.
• Alla logiska beslut verifierade på deras sanna och falska värden.
• Alla slingor som körs vid deras gränser och inom deras operativa gränser giltighet för interna datastrukturer.

För att upptäcka följande typer av buggar:

• Logiska fel tenderar att smyga in i vårt arbete när vi utformar och implementerar funktioner, villkor eller kontroller som inte finns i programmet
• Designfelen på grund av skillnaden mellan programmets logiska flöde och den faktiska implementeringen
• Typografiska fel och syntaxkontroll

Kräver denna testning detaljerade programmeringskunskaper?

Vi måste skriva testfall som garanterar fullständig täckning av programlogiken.

För detta måste vi känna till programmet väl, det vill säga vi borde veta specifikationen och koden som ska testas. Kunskap om programmeringsspråk och logik krävs för denna typ av testning.

Begränsningar

Det går inte att testa varje sökväg till slingorna i programmet. Det betyder att omfattande testning är omöjligt för stora system.

Detta betyder inte att WBT inte är effektivt. Genom att välja viktiga logiska vägar och datastruktur för testning är det praktiskt möjligt och effektivt.

Skillnaden mellan White-Box och Black-Box Testing

För att uttrycka det enkelt:

Under Black Box-test testar vi programvaran ur en användares synvinkel, men i White Box ser vi och testar den faktiska koden.

I Black Box-test utför vi testning utan att se den interna systemkoden, men i WBT ser vi och testar den interna koden.

Testteknik för vitlåda används av både utvecklare och testare. Det hjälper dem att förstå vilken kodrad som faktiskt körs och vilken inte. Detta kan indikera att det antingen saknas en logik eller ett stavfel, vilket så småningom kan leda till några negativa konsekvenser.

Rekommenderad läsning => En komplett guide till Black Box-testning

Steg för att utföra WBT

Steg 1 - Förstå funktionerna i ett program genom dess källkod. Vilket innebär att en testare måste vara väl insatt i programmeringsspråket och andra verktyg samt tekniker som används för att utveckla programvaran.

Steg 2 - Skapa testerna och kör dem.

När vi diskuterar testbegreppet, “ rapportering ”Anses vara den viktigaste faktorn. Här kommer jag att förklara hur man får maximal täckning från White Box-testet.

Läs också=> Orsak och effektdiagram - Dynamisk testfallsteknik för maximal täckning

Typer och tekniker för White Box Testing

Det finns flera typer och olika metoder för varje vitlåda testtyp.

Se bilden nedan för din referens.

Idag ska vi fokusera främst på utförande testtyper av ”Unit testing white box-teknik”.

3 huvudtekniker för vitlåda:

1. Uttalande täckning
2. Filialtäckning
3. Bantäckning

Observera att uttalandet, grenen eller sökvägen inte identifierar något fel eller defekt som behöver åtgärdas. Den identifierar bara de kodrader som antingen aldrig körs eller förblir orörda. Baserat på detta kan ytterligare tester fokuseras på.

Låt oss förstå dessa tekniker en efter en med ett enkelt exempel.

# 1) Uttalande täckning:

På ett programmeringsspråk är ett uttalande ingenting annat än kodraden eller instruktioner för datorn att förstå och agera därefter. Ett uttalande blir ett körbart uttalande när det kompileras och konverteras till objektkoden och utför åtgärden när programmet är i körläge.

Därmed “Uttalande täckning” , som namnet själv antyder, är det metoden för att validera om varje rad i koden körs minst en gång.

# 2) Filialtäckning:

'Filial' i ett programmeringsspråk är som 'IF-uttalanden'. Ett IF-uttalande har två grenar: T rue och False .

Så i filialtäckning (även kallad beslutstäckning) validerar vi om varje gren körs minst en gång.

Vid ett ”IF-uttalande” kommer det att finnas två testvillkor:

• En för att validera den sanna grenen och
• Annat för att validera den falska grenen.

Följaktligen är filialtäckning i teorin en testmetod som är när den körs säkerställer att varje gren från varje beslutspunkt körs.

# 3) Bantäckning

Bantäckning testar alla programvägar. Detta är en omfattande teknik som säkerställer att alla vägar i programmet går igenom minst en gång. Path Coverage är ännu kraftfullare än filialtäckning. Denna teknik är användbar för att testa komplexa program.

Låt oss ta ett enkelt exempel för att förstå alla dessa tekniker för testning av vita rutor.

företag som betalar dig för att prova sina produkter

Kontrollera också=> Olika typer av test

White Box Testing Exempel

Tänk på nedanstående enkla pseudokod:

För Uttalande täckning - vi behöver bara ett testfall för att kontrollera alla rader i koden.

Det betyder:

Om jag överväger TestCase_01 ska vara (A = 40 och B = 70), då kommer alla kodrader att köras.

Nu uppstår frågan:

1. Är det tillräckligt?
2. Vad händer om jag anser att mitt testfall är A = 33 och B = 45?

Eftersom uttalandets täckning endast kommer att täcka den verkliga sidan, för pseudokoden skulle bara ett testfall INTE vara tillräckligt för att testa det. Som testare måste vi också överväga de negativa fallen.

Därför måste vi tänka på för maximal täckning ' Filialtäckning ' , som utvärderar 'FALSE' -villkoren.

I den verkliga världen kan du lägga till lämpliga uttalanden när villkoret misslyckas.

Så nu blir pseudokoden:

Eftersom uttalande täckning inte är tillräcklig för att testa hela pseudokoden, skulle vi behöva filialtäckning för att säkerställa maximal täckning .

Så för filialtäckning skulle vi kräva två testfall för att slutföra testningen av denna pseudokod.

TestCase_01 : A = 33, B = 45

TestCase_02 : A = 25, B = 30

Med detta kan vi se att varje rad i koden körs minst en gång.

Här är de slutsatser som hittills härleds:

• Filialtäckning säkerställer mer täckning än uttalande täckning.
• Filialtäckning är kraftfullare än Statement-täckning.
• 100% filialtäckning i sig betyder 100% uttalande täckning.
• Men 100% uttalande täckning garanterar inte 100% gren täckning.

Nu går vi vidare till Vägtäckning:

Som sagt tidigare används Path-täckning för att testa de komplexa kodavsnitten, som i grunden involverar loop-uttalanden eller en kombination av loopar och beslutsuttalanden.

Tänk på den här pseudokoden:

Nu för att säkerställa maximal täckning skulle vi kräva fyra testfall.

Hur? Enkelt - det finns två beslutsuttalanden, så för varje beslutsuttalande skulle vi behöva två grenar för att testa. En för sant och den andra för det falska tillståndet. Så för två beslutsuttalanden skulle vi kräva 2 testfall för att testa den verkliga sidan och 2 testfall för att testa den falska sidan, vilket gör totalt 4 testfall.

För att förenkla dessa ska vi överväga nedan flödesschemat för den pseudokod vi har:

För att få full täckning skulle vi behöva följande testfall:

TestCase_01: A = 50, B = 60

TestCase_02 : A = 55, B = 40

TestCase_03: A = 40, B = 65

TestCase_04: A = 30, B = 30

Så den täckta vägen blir:

Röd linje - TestCase_01 = (A = 50, B = 60)

Blå linje = TestCase_02 = (A = 55, B = 40)

Orange linje = TestCase_03 = (A = 40, B = 65)

Grön linje = TestCase_04 = (A = 30, B = 30)

******************
= >> Kontakta oss för att föreslå din lista här
*****************

White Box Testing Tools

Nedan följer en lista över de bästa testlådorna för vita rutor.

# 1) Veracode

Veracodes testverktyg för vita rutor hjälper dig att snabbt och enkelt identifiera och lösa programvarufel till en reducerad kostnad. Den stöder flera applikationsspråk som .NET, C ++, JAVA etc och gör det också möjligt att testa säkerheten för stationära, webb- och mobilapplikationer. Ändå finns det flera andra fördelar med Veracode-verktyget. För detaljerad information om Veracode White Box-testverktyg, se nedanstående länk.

Webbplatslänk: Veracode

# 2) EclEmma

EclEmma designades ursprungligen för testkörningar och analyser inom Eclipse-arbetsbänken. Det anses vara ett gratis Java-kodtäckningsverktyg och har också flera funktioner. För att installera eller veta mer om EclEmma, ​​kolla in länken nedan.

Webbplatslänk: EclEmma

hur man öppnar en burkfil Windows 10

# 3) RCUNIT

Ett ramverk som används för testning av C-program kallas RCUNIT. RCUNIT kan användas i enlighet därmed baserat på villkoren i MIT-licensen. Det är gratis att använda och för att installera eller veta mer om det, se länken nedan.

Webbplatslänk: RCUNIT

# 4) cfix

cfix är en av enhetens testramar för C / C ++ som enbart syftar till att göra testsviter utveckling så enkel och enkel som möjligt. Under tiden är cfix vanligtvis specialiserat för NT Kernel-läge och Win32. För att installera och lära dig mer om cfix, kolla in länken nedan

Webbplatslänk: cfix

# 5) Google-test

Googletest är Googles C ++ - testramverk. Test Discovery, Death test, Value-parameterized tests, fatal & non-fatal failures, XML test report generation etc är få funktioner i GoogleTest men det finns flera andra funktioner också. Linux, Windows, Symbian, Mac OS X är få plattformar där GoogleTest har använts. För attLadda ner, kontrollera länken nedan.

Nedladdningslänk: Google-test

# 6) EMMA

Emma är ett lättanvänt gratis JAVA-kodtäckningsverktyg. Den innehåller flera funktioner och fördelar. För att ladda ner och veta mer om Emma, ​​vänligen kontrollera länken nedan.

Nedladdningslänk: EMMA

# 7) NUnit

NUnit är ett lättanvänt testramverk för öppen källkod som inte kräver något manuellt ingripande för att bedöma testresultaten. Den stöder alla .NET-språk. Den stöder också datadrivna tester och tester som körs parallellt under NUnit. Tidigare utgåvor av NUnit använde NUnit-licens men NUnit 3 släpptes under MIT-licensen. Men båda licenserna tillåter fri användning utan några begränsningar. För att ladda ner och veta mer om NUnit, vänligen kontrollera länken nedan.

Nedladdningslänk: NUnit

# 8) CppUnit

CppUnit är ett enhetstestningsramverk skrivet i C ++ och anses vara hamnen för JUnit. Testutmatningen för CppUnit kan vara antingen i XML- eller textformat. Det skapar enhetstester med sin egen klass och kör test i testsviterna. Det är licensierat under LGPL. För att ladda ner och veta mer om CppUnit, vänligen kontrollera länken nedan.

Nedladdningslänk: CppUnit

# 9) JUnit

JUnit är en tyst enkel enhetstestram som stöder testautomatisering i Java Programming Language. Den stöder främst inom testdriven utveckling och tillhandahåller också testtäckningsrapporten. Det är licensierat under Eclipse Public License. För gratis nedladdning och för att få veta mer om JUnit, se nedanstående länk.

Nedladdningslänk: JUnit

# 10) JsUnit

JsUnit anses vara hamnen i JUnit to javascript. Och det är ett testkod för öppen källkod för att stödja klientsidig Javascript. Det är licensierat under GNU Public License 2.0, GNU Lesser Public License 2.1 och Mozilla Public License 1.1. För att ladda ner och veta mer om JsUnit, vänligen kontrollera länken nedan.

Nedladdningslänk: JsUnit

Kontrollera också alla verktyg som vi har listat under Statisk kodanalys här .

Föreslå gärna enklare eller avancerade verktyg som du använder för vitlåda-teknik.

Slutsats

Förlita sig bara på testning i svart låda räcker inte för maximal testtäckning. Vi måste ha en kombination av testningstekniker för både black box och white box täcka maximala defekter .

Om det görs ordentligt kommer vitlåda testning säkert att bidra till programvarukvaliteten. Det är också bra för testare att delta i denna testning eftersom det kan ge den mest 'opartiska' åsikten om koden. :)

Låt oss veta om du har några frågor om metoderna vi diskuterade i den här artikeln.

Rekommenderad läsning

• Viktiga skillnader mellan Black Box Testing och White Box Testing
• Black Box Testing: En djupgående handledning med exempel och tekniker
• Funktionell testning mot icke-funktionell testning
• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Att tänka ur lådan medan du testar programvara!
• Handbok för testbarhet med praktiska exempel
• Alfatestning och betatestning (En komplett guide)
• Typer av programvarutestning: Olika testtyper med detaljer