Introduktion til White Box Testing

Testning er en af ​​de vigtige dele af softwareudviklingen, det sørger for, at alle fejl er sorteret, og programmet fungerer, som det også var meningen. Test af et softwareprodukt kan have flere trin og flere procedurer. I denne artikel skal vi se på en af ​​de vigtige tilgange til testprocessen, White Box Testing.

Hvad er White Box Testing?

White box-test kaldes også kodebasetestning, clearbox-test, open box-test og strukturel test. Kernen i denne tilgang til softwaretestning er at se på den interne strukturdesign og på programkoden for at teste den.

I White Box-testning kan testeren se hele programkoden, og han har til opgave at verificere strømmen af, hvordan input og output fungerer i programmet. I modsætning til test af sort boks, som er mere fokuseret på at teste programmets funktionalitet, er White Box Testing optaget af at teste programmets interne strukturer. Når vi ser på programmet på denne måde, kan vi arbejde på at forbedre design, brugervenlighed og gøre produktet mere sikkert.

Som du kan gætte, kaldes det test af hvid boks eller glasboks, fordi testeren kan se koden og andre dele af programmet.

Hvad der gør White Box Testing forskellig fra Black Box Testing

Hvis du har tippet tæerne i test i fortiden, er jeg sikker på, at du er stødt på Black Box Testing. Den største forskel mellem White Box Testing og Black Box Testing er, at i modsætning til Black Box-test, der udføres fra en brugers synspunkt, udføres White Box Testing fra en udviklers synspunkt.

Med andre ord, snarere end at se på programmet udefra, ser White Box Testing-metoden den interne kode og tester det.

Hvordan udføres White Box Testing?

Vi kan dele processen med White Box Testing i to store trin.

1. Forståelse af den medfølgende kode

Til at begynde med er en tester i White Box Testing nødt til at lære programkoden. I betragtning af, at White Box Testing handler om at forstå og teste al programmets interne kode, skal enhver, der har til opgave at teste koden, ikke kun have et godt kendskab til programmering, men han vil også have behov for en god hånd med sproget af kildekoden.

Sikkerhed er et af de vigtige aspekter ved White Box Testing, så testeren bliver også nødt til at være god til sikker kodningspraksis.

2. Oprettelse af testsager og eksekvering af dem

Når koden er blevet undersøgt af testteamet, kan de begynde at teste koden for at kontrollere dens rigtige strøm og struktur. For at gøre dette vil testerne skrive nogle kode for nogle testtilfælde, som vil forsøge at gennemgå alle kodelinjer, der findes i programmet.

Det kan også udføres i manuel test, som involverer prøve og fejl. Testerne kan også bruge nogle automatiserede testværktøjer, såsom JUnit og NUnit.

Et eksempel på White Box Testing

For bedre at forstå begrebet White Box Testing, kig på koden herunder:

print (int x, int y) (
int sum = x + y;
If ( sum > 0 )
Print ( "Positive", result )
Else
Print ( "Negative", result )
)

Som vi diskuterede tidligere, er målet med White Box Testing at krydse alle grene, løkker og udsagn, der er til stede i koden. I betragtning af det kan vi lave 2 testtilfælde, et hvor begge input er positive og en anden hvor begge input er negative heltal.

Eksempel:

  • A = 10 og B = 20
  • A = -10 og B = -20

White Box Testing Techniques

En af de mest populære testteknikker til test af hvid boks kaldes kodedækningsanalyse, denne teknik forsøger at fjerne eventuelle huller i test case-pakken, og den identificerer dele af en app, der ikke bruges af testcases. Når disse huller er fundet, kan vi oprette sager for at se og verificere dele af koden, der ikke er testet, hvilket resulterer i et mere poleret produkt i slutningen.

Følgende er nogle dækningsanalyseteknikker:

  • Udsagnsdækning: I denne metode forsøger vi at krydse alle udsagn i koden mindst én gang. Dette sikrer, at al koden testes.
  • Filialdækning: Denne metode er planlagt til at krydse hver gren af ​​beslutningspunkterne i koden. Dette sikrer, at alle beslutninger mindst testes én gang.

Der er også nogle andre testteknikker, her er bare nogle få:

  • Tilstandsdækning: I denne testteknik sørger vi for, at alle betingelser er omfattet af koden, for eksempel:

READ A, B
IF (A == 0 || B == 0)
PRINT '0'

Som du kan se, her har vi 2 betingelser: A == 0 og B == 0. Nu får disse betingelser Sande og FALSE som værdier. Et muligt eksempel kan være:

# TC1 - A = 0, B = 110
# TC2 - A = 10, B = 0

  • Dækning af flere tilstande: Dette er en smule mere avanceret end den sidste. Som du kan gætte, tester vi alle mulige kombinationer og alle mulige resultater mindst én gang. Her er et anstændigt eksempel:

READ A, B
IF (A == 0 || B == 0)
PRINT '0'

# TC1: A = 0, B = 0
# TC2: A = 0, B = 10
# TC3: A = 110, B = 0
# TC4: A = 110, B = 5

Derfor. Vi kræver 4 testtilfælde under 2 forhold.

Derfor, hvis der er n betingelser, vil vi kræve 2 n test tilfælde.

  • Grundlæggende sti-test: I denne White Box Testing-teknik laver vi kontrolflowdiagram og beregner derefter dens cyklomatiske kompleksitet, som er antallet af uafhængige stier. Ved hjælp af den cyklomatiske kompleksitet kan vi finde det minimale antal testsager, vi kan designe for hver uafhængig bane i flowgrafen.
  • Loop Testing: Loops er et af de mest anvendte værktøjer i en programmerings våben. Da disse er kernen i så mange algoritmer, giver det kun mening at have en testteknik baseret på sløjfer. Der kan være 3 typer løkker: Enkel, indlejret og sammenkoblet. Lad os se på, hvordan en tester vil håndtere teknologien af ​​disse typer:

1. Enkle sløjfer: For en løkke, der er enkel i design og har størrelsen n, kan vi designe nogle testtilfælde, der gør følgende:

  • Spring over nævnte loop.
  • Kryds kun løkken én gang.
  • Har 2 pas
  • Har et hvilket som helst antal pass, der er mindre end dens størrelse.
  • n-1 og n + 1 passerer gennem løkken.

2. Indlejrede sløjfer: For kode med indlejrede sløjfer, starter vi med den inderste sløjfe og går derefter udad, indtil vi kan nå til den yderste sløjfe.

3. Sammenføjede sløjfer: For disse sløjfer. Vi bruger simpel sløjfe-test en gang efter den anden, og hvis den sammenkoblede sløjfe ikke er uafhængig, kan vi håndtere dem, som vi gjorde med indlejrede sløjfer.

Fordele

Nu hvor vi har set, hvad denne testmetode er, og hvordan den fungerer. Lad os se på nogle af fordelene ved dette.

  • White Box Testing har enkle og klare regler for at lade en tester vide, hvornår testen er udført.
  • White Box Testing-teknikker er lette at automatisere, hvilket resulterer i, at en udvikler skal ansætte færre testere og mindre udgifter.
  • Det viser flaskehalse, hvilket gør optimeringen ganske let for programmererne.
  • Et testteam kan komme i gang med deres arbejde uden at skulle vente på, at udviklingsholdet afslutter UI-udviklingen.
  • Da alle kodestier er dækket af koden i de fleste tilfælde, er testen af ​​kode mere igennem.
  • Det hjælper med at fjerne dele af koden, der ikke er væsentlige for programmets funktionalitet.

Ulemper

  • Det beskæftiger sig ret med ressourcer. For at få testen udført, har du brug for nogen, der kender din kode meget godt, for at være i testteamet, og som selv er en god programmør. Denne type færdighedsniveau øger udgifterne til testen.
  • I mange tilfælde er det ikke muligt at teste alle mulige betingelser i koden på grund af tidsbegrænsninger eller budgetbegrænsninger.
  • Da test i hvid boks er baseret på at kontrollere funktionaliteten af ​​den eksisterende kode, kan du ikke finde den manglende funktionalitet i programmet.
  • Hvis nogen del af koden omdesignes og omskrives igen, skal testere skrive testsagerne igen.

White Box Testing Tools

Nu hvor du er bekendt med fordele, ulemper og teknikker til test af hvid boks, kan vi se på nogle populære værktøjer, som testere kan bruge til at udføre test af hvid boks.

  • JSUnit.net

Dette er et JavaScript-testværktøj. JSUnit er en del af Junit og dets en open source enhedstestningsramme, der kan bruges til at udføre White Box Testing. JSUnit er fuldstændig open source under GNU Public License 2.0, hvilket betyder, at selv for kommerciel brug behøver en udvikler ikke betale noget licensgebyr.

  • CppUnit

Ligesom JSUnit betragtes CppUnit også som en del af JUnit. Værktøjet kan udsendes i almindelig tekst eller XML-format, afhængigt af testerens behov, og det kan oprette enhedstest med sine egne klasser. CppUnit er licenseret under LGPL.

  • Veracode

Selvom det ikke er gratis at bruge, har Veracode nogle kraftfulde værktøjer, der kan bruges til at teste .NET, C ++, Java og nogle andre sprog. White Box-testen kan også udføres applikationer, der er lavet til desktop, web og mobile apps.

  • NUnit

Det er en enhedstestningsramme, og den blev skrevet i C #. Værktøjet understøtter alle tilgængelige. Net-sprog, og det understøtter også datadrevet test. Funktionalitetsmæssigt er det, det kan arbejde på både parallel og samtidig udførelse, og det kan give en klasse ramme og testløber apps. Én et bemærkelsesværdigt træk ved NUnit, at det er forholdsvis let at bruge.

  • JUnit

Som du kan gætte fra dens navn, er JUnit et enhedsprøvningsautomatiseringsværktøj til Java. JUnit-varevognen er let integreret med IDE'er som formørkelse, Macen ACT osv. Den er i stand til at understøtte testdrevet udvikling, og den kan også synkronisere eksisterende tests med nyoprettet en gang. JUnit er en helt open source og gratis at bruge til enhver form for Java-udvikling.

  • CSUnit

Ligesom Nunit er CSUnit bygget til at understøtte enhedstest i .Net Framework. Det understøtter sprog som C # og VB.Net. CSUnit har indbygget support til factoringpraksis og andre former for praksis, der bruges i den smidige udviklingsmetode fra SDLC.

Konklusion

Testning har et meget vigtigt sted i softwareudviklingsprocessen, og White Box Testing er en værdifuld tilgang til at få det til. Selvom denne testmetode kan være dyr og tidskrævende, er White Box Testing stadig den eneste måde at sikre sig, at alle dele af koden blev dækket i testprocessen.

Den vigtigste del af White Box Testing er, hvor velkendt testeren er med koden. En person, der har til opgave at teste på WBT-tilgang, som ikke har en god hånd med kildekoden og det anvendte programmeringssprog, vil forårsage en masse problemer. Afhængig af kun den hvide boks er ikke en god ide, da det ikke dækker manglende funktionalitet. For en mere dækket tilgang til udviklingen bør både White Box Testing og Black Box Testing udføres, da det derefter vil dække maksimale fejl, defekter og resterende funktioner, der skal tilføjes, før produktet kan sendes.

Anbefalede artikler

Dette har været en guide til White Box Testing. Her diskuterede vi, hvordan White Box Testing udføres ved hjælp af eksempler og forskellige White Box Testing-teknikker med værktøjer. Du kan også gennemgå vores andre foreslåede artikler for at lære mere–

  1. Spørgsmål om software-testintervju
  2. Karrierer inden for softwaretestning
  3. Spørgsmål om interviewtest til spil
  4. ETL Testing Interview spørgsmål
  5. Kode dækning vs test dækning | Top 4 forskelle at lære
  6. Kode dækningsværktøjer | Top 6 kode dækningsværktøjer

Kategori:

Softwareudvikling