white box testing complete guide with techniques
Hvad er White Box Testing?
Hvis vi går efter definitionen, er 'White box testing' (også kendt som klar, glasboks eller strukturel test) en testteknik, der evaluerer koden og den interne struktur i et program.
Test af hvid boks indebærer at se på kodens struktur. Når du kender et produkts interne struktur, kan der udføres test for at sikre, at de interne operationer udføres i henhold til specifikationen. Og alle interne komponenter er blevet udnyttet tilstrækkeligt.
Hvad du vil lære:
- Min erfaring
- Forskellen mellem hvid-boks og sort-boks-test
- Skridt til at udføre WBT
- Typer og teknikker til White Box Testing
- Eksempel på testning af hvid boks
- White Box testværktøjer
- Konklusion
- Anbefalet læsning
Min erfaring
Det er næsten et årti nu, siden jeg er interesseret i softwaretestning og indtil videre har bemærket, at testere er de mest entusiastiske i hele softwareindustrien.
Hovedårsagen bag dette er - testeren har altid noget inden for deres omfang at lære. Det være sig et domæne, en proces eller en teknologi, en tester kan have en komplet udvikling, hvis de ønsker det.
Men som de siger “Der er altid en mørkere side” .
Testere undgår også faktisk en type test, som de føler er meget komplicerede og udviklerens stykke kage. Ja, 'White Box Testing'.
Dækning
White Box Testing er dækning af specifikationen i koden:
1. Kodedækning
2. Segmentdækning: Sørg for, at hver kodesætning udføres en gang.
3. Filialdækning eller knudeprøvning: Dækningen af hver kodeforgrening fra alle mulige var.
4. Dækning af sammensat tilstand: For flere forhold test hver tilstand med flere stier og en kombination af den forskellige sti for at nå den betingelse.
5. Basisvejstest: Hver uafhængige sti i koden tages til test.
6. Test af dataflow (DFT): I denne tilgang sporer du de specifikke variabler gennem hver mulig beregning og definerer således sæt af mellemstier gennem koden.DFT har tendens til at afspejle afhængigheder, men det er hovedsageligt gennem sekvenser af datamanipulation. Kort sagt spores hver datavariabel, og dens anvendelse er verificeret. Denne tilgang har tendens til at afdække fejl som anvendte variabler, men ikke initialiseres, eller erklæres, men ikke bruges osv.
7. Sti-test: Sti-test er, hvor alle mulige stier gennem koden er defineret og dækket. Det er en tidskrævende opgave.
8. Looptest: Disse strategier vedrører test af enkelte sløjfer, sammenkædede sløjfer og indlejrede sløjfer. Uafhængige og afhængige kodesløjfer og værdier testes ved denne tilgang.
Hvorfor udfører vi WBT?
At sikre:
- At alle uafhængige stier i et modul er blevet udøvet mindst én gang.
- Alle logiske beslutninger verificeret på deres sande og falske værdier.
- Alle sløjfer udført ved deres grænser og inden for deres operationelle grænser gyldighed af interne datastrukturer.
For at opdage følgende typer fejl:
- Logiske fejl har en tendens til at krybe ind i vores arbejde, når vi designer og implementerer funktioner, betingelser eller kontroller, der er uden for programmet
- Designfejlene på grund af forskellen mellem logisk flow af programmet og den faktiske implementering
- Typografiske fejl og syntaks kontrol
Kræver denne test detaljerede programmeringsfærdigheder?
Vi skal skrive test tilfælde der sikrer den fulde dækning af programlogikken.
Til dette er vi nødt til at kende programmet godt, dvs. vi skal kende specifikationen og koden, der skal testes. Kendskab til programmeringssprog og logik kræves til denne type test.
Begrænsninger
Det er ikke muligt at teste hver eneste sti til sløjferne i programmet. Dette betyder, at udtømmende test er umulig for store systemer.
Dette betyder ikke, at WBT ikke er effektiv. Ved at vælge vigtige logiske stier og datastruktur til test er det praktisk muligt og effektivt.
Forskellen mellem hvid-boks og sort-boks-test
For at sige det i enkle vendinger:
Under test af sort boks tester vi softwaren fra en brugers synspunkt, men i hvid boks ser og tester vi den aktuelle kode.
I Black Box-test udfører vi test uden at se den interne systemkode, men i WBT ser og tester vi den interne kode.
White box testteknik bruges af både udviklerne og testere. Det hjælper dem med at forstå, hvilken linje kode der faktisk udføres, og hvilken ikke. Dette kan indikere, at der enten er en manglende logik eller en tastefejl, som i sidste ende kan føre til nogle negative konsekvenser.
Anbefalet læsning => En komplet guide til Black Box-test
Skridt til at udføre WBT
Trin 1 - Forstå funktionaliteten af et program gennem dets kildekode. Hvilket betyder, at en tester skal være fortrolig med programmeringssproget og de andre værktøjer samt teknikker, der bruges til at udvikle softwaren.
Trin 2 - Opret testene og udfør dem.
Når vi diskuterer testbegrebet, “ dækning ”Betragtes som den vigtigste faktor. Her vil jeg forklare, hvordan man får maksimal dækning ud fra test af hvidboks.
Læs også=> Årsag og virkning Graf - Dynamisk testcase-skriveteknik for maksimal dækning
Typer og teknikker til White Box Testing
Der er flere typer og forskellige metoder til hver type hvid boks test.
Se nedenstående billede for din reference.
I dag vil vi primært fokusere på udførelsestesttyper af 'Unit testing white box-teknik'.
3 vigtigste teknikker til testning af hvid boks:
- Erklæringens dækning
- Filialdækning
- Sti dækning
Bemærk, at erklæringen, grenen eller stigdækningen ikke identificerer nogen fejl eller mangler, der skal rettes. Det identificerer kun de kodelinjer, der enten aldrig udføres eller forbliver uberørte. Baseret på dette kan yderligere test fokuseres på.
Lad os forstå disse teknikker en efter en med et simpelt eksempel.
# 1) Erklæringens dækning:
På et programmeringssprog er en erklæring intet andet end linjen med kode eller instruktion, som computeren kan forstå og handle i overensstemmelse hermed. En erklæring bliver en eksekverbar erklæring, når den bliver kompileret og konverteret til objektkoden og udfører handlingen, når programmet er i kørende tilstand.
Derfor “Erklæringens dækning” , som navnet selv antyder, er det metoden til at validere, om hver eneste linje i koden udføres mindst en gang.
# 2) Afgrænsning:
'Filial' på et programmeringssprog er som 'IF-udsagnene'. En IF-sætning har to grene: T rue og False .
Så i filialdækning (også kaldet beslutningsdækning) validerer vi, om hver filial udføres mindst én gang.
I tilfælde af en 'IF-erklæring' vil der være to testbetingelser:
- En til at validere den sande gren og,
- Andet for at validere den falske gren.
Derfor er filialdækning i teorien en testmetode, som når den udføres sikrer, at hver gren fra hvert beslutningspunkt udføres.
# 3) Sti-dækning
Sti dækning tester alle stier i programmet. Dette er en omfattende teknik, der sikrer, at alle stier i programmet krydses mindst én gang. Banedækning er endnu mere kraftfuld end filialdækning. Denne teknik er nyttig til test af de komplekse programmer.
Lad os tage et simpelt eksempel for at forstå alle disse teknikker til testning af hvid boks.
java-program for at sortere en matrix
Kontroller også=> Forskellige typer af test
Eksempel på testning af hvid boks
Overvej nedenstående enkle pseudokode:
INPUT A & B C = A + B IF C>100 PRINT “ITS DONE”
Til Erklæringens dækning - vi behøver kun en testtilfælde for at kontrollere alle linjerne i koden.
Det betyder:
Hvis jeg overvejer TestCase_01 skal være (A = 40 og B = 70), så udføres alle kodelinjerne.
Nu opstår spørgsmålet:
- Er det tilstrækkeligt?
- Hvad hvis jeg betragter min testsag som A = 33 og B = 45?
Fordi erklæringsdækning kun dækker den sande side, for pseudokoden, ville kun en testsag IKKE være tilstrækkelig til at teste den. Som tester skal vi også overveje de negative tilfælde.
Derfor skal vi overveje for maksimal dækning ' Filialdækning ' , som vil evaluere 'FALSE' -betingelserne.
I den virkelige verden kan du tilføje passende udsagn, når betingelsen mislykkes.
Så nu bliver pseudokoden:
INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” ELSE PRINT “ITS PENDING”
Da erklæringens dækning ikke er tilstrækkelig til at teste hele pseudokoden, ville vi kræve filialdækning for at sikre maksimal dækning .
Så for filialdækning ville vi kræve to testsager for at afslutte testen af denne pseudokode.
TestCase_01 : A = 33, B = 45
TestCase_02 : A = 25, B = 30
Med dette kan vi se, at hver linje i koden udføres mindst en gang.
Her er de konklusioner, der hidtil er afledt:
- Filialdækning sikrer mere dækning end erklæringens dækning.
- Filialdækning er stærkere end erklæringens dækning.
- 100% filialdækning betyder i sig selv 100% erklæring.
- Men 100% erklæring dækning garanterer ikke 100% gren dækning.
Lad os nu gå videre til Sti dækning:
Som tidligere nævnt bruges stidækning til at teste de komplekse kodestykker, som grundlæggende involverer loop-sætninger eller en kombination af sløjfer og beslutningserklæringer.
Overvej denne pseudokode:
INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” END IF IF A>50 PRINT “ITS PENDING” END IF
Nu for at sikre maksimal dækning ville vi kræve 4 testsager.
Hvordan? Simpelthen - der er to beslutningserklæringer, så for hver beslutningserklæring har vi brug for to grene for at teste. Den ene for sand og den anden for den falske tilstand. Så for 2 beslutningserklæringer ville vi kræve 2 testsager for at teste den sande side og 2 testsager for at teste den falske side, hvilket giver i alt 4 testsager.
For at forenkle disse, lad os overveje nedenstående rutediagram for den pseudokode, vi har:
For at få den fulde dækning har vi brug for følgende testsager:
TestCase_01: A = 50, B = 60
TestCase_02 : A = 55, B = 40
hvordan man åbner .swf filer
TestCase_03: A = 40, B = 65
TestCase_04: A = 30, B = 30
Så den dækkede vej vil være:
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)
******************
= >> Kontakt os at foreslå din liste her
*****************
White Box testværktøjer
Nedenfor er en liste over de bedste testværktøjer til hvid boks.
# 1) Veracode
Veracodes testværktøjer til hvid boks hjælper dig med at identificere og løse softwarefejlene hurtigt og nemt til en reduceret pris. Det understøtter flere applikationssprog som .NET, C ++, JAVA osv. Og giver dig også mulighed for at teste sikkerheden på desktop-, web- og mobilapplikationer. Der er stadig flere andre fordele ved Veracode-værktøjet. For detaljerede oplysninger om Veracode White box testværktøjer, se nedenstående link.
Webstedslink: Veracode
# 2) EclEmma
EclEmma blev oprindeligt designet til testkørsler og analyser inden for Eclipse-arbejdsbænken. Det anses for at være et gratis Java-kodedækningsværktøj og har også flere funktioner. For at installere eller vide mere om EclEmma, se nedenstående link.
Webstedslink: EclEmma
# 3) RCUNIT
En ramme, der bruges til test af C-programmer, er kendt som RCUNIT. RCUNIT kan bruges i overensstemmelse hermed baseret på vilkårene i MIT-licensen. Det er gratis at bruge og for at installere eller vide mere om det, bedes du tjekke nedenstående link.
Webstedslink: RCUNIT
# 4) cfix
cfix er en af enhedstestningsrammerne for C / C ++, der udelukkende sigter mod at gøre testsuiterudvikling så enkel og let som muligt. I mellemtiden er cfix typisk specialiseret til NT Kernel-tilstand og Win32. For at installere og vide mere om cfix, se venligst nedenstående link
Webstedslink: cfix
#5) Googletest
Googletest er Googles C ++ testramme. Testopdagelse, dødstest, værdiparameteriserede test, fatale og ikke-fatale fejl, generering af XML-testrapport osv. Er få funktioner i GoogleTest, men der er også flere andre funktioner. Linux, Windows, Symbian, Mac OS X er få platforme, hvor GoogleTest er blevet brugt. For atDownload, tjek nedenstående link.
Download link: Googletest
# 6) EMMA
Emma er et brugervenligt gratis JAVA-kodedækningsværktøj. Det indeholder flere funktioner og fordele. For at downloade og vide mere om Emma, se venligst nedenstående link.
Download link: EMMA
# 7) NUnit
NUnit er en brugervenlig testramme til open source-enheder, der ikke kræver nogen manuel indgriben for at bedømme testresultaterne. Det understøtter alle .NET-sprog. Det understøtter også datadrevne tests og tests, der kører parallelt under NUnit. Tidligere udgivelser af NUnit brugte NUnit-licens, men NUnit 3 frigives under MIT-licensen. Men begge licenserne tillader gratis brug uden begrænsninger. For at downloade og vide mere om NUnit bedes du tjekke nedenstående link.
Download link: NUnit
# 8) CppUnit
CppUnit er en enhedstestningsramme skrevet i C ++ og anses for at være havnen i JUnit. Testoutputtet til CppUnit kan enten være i XML- eller tekstformat. Det opretter enhedstest med sin egen klasse og kører tests i testpakkerne. Det er licenseret under LGPL. For at downloade og vide mere om CppUnit bedes du tjekke nedenstående link.
Download link: CppUnit
# 9) JUnit
JUnit er en stille enkel enhedstestramme, der understøtter testautomatisering i Java Programming Language. Det understøtter hovedsageligt i testdrevet udvikling og leverer også testdækningsrapporten. Det er licenseret under Eclipse Public License. For gratis download og for at vide mere om JUnit, se nedenstående link.
Download link: JUnit
# 10) JsUnit
JsUnit betragtes som havnen i JUnit til javascript. Og det er en open source-testramme til understøttelse af klientsidet Javascript. Det er licenseret under GNU Public License 2.0, GNU Lesser Public License 2.1 og Mozilla Public License 1.1. For at downloade og vide mere om JsUnit bedes du tjekke nedenstående link.
Download link: JsUnit
Kontroller også alle de værktøjer, som vi har angivet under Statisk kodeanalyse her .
Du er velkommen til at foreslå mere enkle eller avancerede værktøjer, som du bruger til hvid bokseteknik.
Konklusion
At stole kun på test af sort boks er ikke tilstrækkelig til maksimal testdækning. Vi er nødt til at have en kombination af både sort boks og hvid boks testteknikker til dække maksimale fejl .
Hvis det gøres ordentligt, vil White Box-test helt sikkert bidrage til softwarekvaliteten. Det er også godt for testere at deltage i denne test, da det kan give den mest 'upartiske' mening om koden. :)
Fortæl os, hvis du har spørgsmål om de metoder, vi diskuterede i denne artikel.
Anbefalet læsning
- Nøgleforskelle mellem Black Box Testing og White Box Testing
- Black Box Testing: En grundig tutorial med eksempler og teknikker
- Funktionel testning mod ikke-funktionel testning
- Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
- Tænker ud af kassen, mens du tester software!
- Vejledning til bærbarhedstestning med praktiske eksempler
- Alpha Testing og Beta Testing (En komplet guide)
- Typer af softwaretest: Forskellige testtyper med detaljer