Introduksjon til White Box Testing

Testing er en av de viktige delene av programvareutvikling, den sørger for at alle feilene er sortert ut og at programmet fungerer slik det var ment også. Testingen av et programvareprodukt kan ha flere trinn og flere prosedyrer. I denne artikkelen skal vi ta en titt på en av de viktige tilnærmingene til testprosessen, White Box Testing.

Hva er White Box Testing?

Testing av hvite bokser kalles også kodebasetesting, klarbokstesting, åpen boksetesting og strukturell testing. Kjerneideen med denne tilnærmingen til programvaretesting er å se på den interne strukturdesignen og koden til programmet for å teste den.

I hvitboks-testing kan testeren se hele koden til programmet, og han har til oppgave å bekrefte flyten av hvordan innganger og utganger fungerer i programmet. I motsetning til svartboks-testing, som er mer fokusert på å teste funksjonaliteten til programmet, er White Box Testing opptatt av å teste de interne strukturene i programmet. Når vi ser på programmet på denne måten, kan vi jobbe med å forbedre designen, brukervennligheten og gjøre produktet sikrere.

Som du kan gjette, het det test av hvit boks eller glassboks fordi testeren kan se koden og andre deler av programmet.

Hva som gjør White Box Testing annerledes enn Black Box Testing

Hvis du har tippet tærne i tester i det siste, er jeg sikker på at du har kommet over Black Box Testing. Den største forskjellen mellom White Box Testing og Black Box Testing er at i motsetning til Black Box testing, som gjøres fra en brukers synspunkt, blir White Box Testing gjort fra utviklerens synspunkt.

Med andre ord, i stedet for å ta en titt på programmet utenfra, ser White Box Testing-tilnærmingen den interne koden og tester den.

Hvordan utføres White Box Testing?

Vi kan dele prosessen med White Box Testing i to hovedtrinn.

1. Forstå koden som følger med

Til å begynne med, En tester i White Box Testing må lære seg koden til applikasjonen. Tatt i betraktning det faktum at White Box Testing handler om å forstå og teste all den interne koden til programmet, bør alle som får i oppgave å teste koden ikke bare ha god kunnskap om programmering, men han vil også trenge å ha en god hånd med språket av kildekoden.

Sikkerhet er et av de viktige aspektene ved White Box Testing, så testeren må også være god på sikker koding.

2. Opprette testsaker og henrette dem

Når koden er studert av testteamet, kan de begynne å teste koden for å sjekke den riktige flyten og strukturen. For å gjøre dette vil testerne skrive noen kode for noen testtilfeller som vil prøve å gå gjennom alle kodelinjer som er til stede i programmet.

Det kan også gjøres i manuell testing som innebærer prøving og feiling. Testerne kan også bruke noen automatiserte testverktøy som JUnit og NUnit.

Et eksempel på testing av hvite bokser

For å forstå begrepet White Box Testing bedre, ta en titt på koden nedenfor:

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

Som vi diskutert tidligere, er målet med White Box Testing å krysse alle grener, løkker og utsagn som er til stede i koden. Tatt i betraktning det, kan vi lage to testtilfeller, en der begge innspillene er positive og en annen der begge innspillene er negative tall.

Eksempel:

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

White Box Testing Techniques

En av de mest populære testteknikkene for testing av hvite bokser kalles kodedekningsanalyse. Denne teknikken prøver å eliminere eventuelle hull i test case-pakken, og den identifiserer deler av en app som ikke brukes av testtilfeller. Når disse hullene er funnet, kan vi opprette saker for å se og verifisere deler av koden som ikke er testet, dette resulterer i et mer polert produkt på slutten.

Følgende er noen teknikker for dekningsanalyse:

  • Uttalelsesdekning: På denne metoden prøver vi å krysse alle utsagn i koden minst en gang. Dette sikrer at all koden er testet.
  • Grendekning: Denne metoden er planlagt å krysse hver gren av beslutningspunktene i koden. Dette sørger for at alle beslutninger blir testet minst en gang.

Det er noen andre testteknikker også, her er bare noen få:

  • Tilstandsdekning: I denne testteknikken sørger vi for at alle forhold dekkes i koden, for eksempel:

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

Som du kan se, her har vi 2 forhold: A == 0 og B == 0. Nå får disse forholdene SANN og FALSE som verdier. Et mulig eksempel kan være:

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

  • Flere tilstrekkelig dekning: Dette er litt mer avansert enn den siste. Som du kan gjette, tester vi alle mulige kombinasjoner og alle mulige utfall minst en gang. Her er et anstendig 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

Derav. Vi krever 4 testtilfeller under 2 forhold.

Derfor, hvis det er n forhold, vil vi kreve 2 n testsaker.

  • Test av grunnstien: I denne White Box Testing-teknikken lager vi kontrollflytdiagram og beregner deretter syklomatisk kompleksitet som er antallet uavhengige baner. Ved bruk av syklomatisk kompleksitet kan vi finne det minimale antallet testtilfeller vi kan utforme for hver uavhengig bane i flytgrafen.
  • Loop Testing: Loops er et av de mest brukte verktøyene i et programmerings våpen. Siden disse er kjernen i så mange algoritmer, er det bare fornuftig å ha en testteknikk basert på løkker. Det kan være tre typer løkker: Enkel, nestet og sammenkoblet. La oss se på hvordan en tester vil takle teknologien av disse typene:

1. Enkle løkker: For en sløyfe som er enkel i design og har størrelsen n, kan vi designe noen testtilfeller som gjør følgende:

  • Hopp over nevnte loop.
  • Kryss bare løkken én gang.
  • Har 2 pasninger
  • Har et hvilket som helst antall passeringer som er mindre enn størrelsen.
  • n-1 og n + 1 går gjennom løkken.

2. Nested Loops: For kode med nestede løkker, starter vi med den innerste løkken og går deretter utover til vi kan nå den ytterste løkken.

3. Sammenføyede løkker: For disse løkkene. Vi bruker enkel sløyfetest en gang etter hverandre og i tilfelle den sammenkoblede sløyfen ikke er uavhengig, kan vi takle dem som vi gjorde med nestede løkker.

Fordeler

Nå som vi har sett hva denne testmetoden er og hvordan den fungerer. La oss ta en titt på noen av fordelene med dette.

  • White Box Testing har enkle og tydelige regler for å gi en tester beskjed når testingen er utført.
  • White Box Testing Techniques er enkle å automatisere, dette resulterer i at en utvikler må ansette færre testere og mindre utgifter.
  • Den viser flaskehalser som gjør optimaliseringen ganske enkel for programmererne.
  • Et testteam kan komme i gang med arbeidet sitt uten å måtte vente på at utviklingsteamet skal fullføre UI-utviklingen.
  • Siden alle kodebaner dekkes i koden i de fleste tilfeller, er testingen av koden mer gjennom.
  • Det hjelper med å fjerne deler av koden som ikke er avgjørende for funksjonaliteten til programmet.

ulemper

  • Det er ganske beskatning av ressurser. For å få testen utført, trenger du noen som kjenner koden din veldig godt for å være med i testteamet og som selv er en god programmerer. Denne typen ferdighetsnivå øker utgiftene til testingen.
  • I mange tilfeller er det ikke mulig å teste alle mulige forhold i koden på grunn av tidsbegrensninger eller budsjettbegrensninger.
  • Siden testing av hvite bokser er basert på å sjekke funksjonaliteten til den eksisterende koden, kan du ikke finne den manglende funksjonaliteten i programmet.
  • Hvis noen del av koden blir redesignet og skrevet om på nytt, må testere skrive testsakene på nytt.

Testingsverktøy for hvit boks

Nå som du er kjent med fordeler, ulemper og teknikker for testing av hvite bokser, kan vi ta en titt på noen populære verktøy som testere kan bruke til å utføre testing av hvite bokser.

  • JSUnit.net

Dette er et JavaScript-testverktøy. JSUnit er en del av Junit og dens et rammeverk for testing av åpen kildekode som kan brukes til å utføre White Box Testing. JSUnit er fullstendig åpen kildekode under GNU Public License 2.0, som betyr at selv for kommersiell bruk, trenger ikke en utvikler å betale lisensavgift.

  • CppUnit

Akkurat som JSUnit, anses CppUnit også å være en del av JUnit. Verktøyet kan produseres i ren tekst eller XML-format, avhengig av testerens behov, og det kan lage enhetstester med egne klasser. CppUnit er lisensiert under LGPL.

  • Veracode

Selv om det ikke er gratis å bruke, har Veracode noen kraftige verktøy som kan brukes til å teste .NET, C ++, Java og noen andre språk. White Box-testingen kan gjøres applikasjoner laget for desktop, web og mobile apper også.

  • NUnit

Det er et enhetstesting rammeverk, og det ble skrevet i C #. Verktøyet støtter alle tilgjengelige. Net-språk, og det støtter datadrevet test også. Funksjonalitetsmessig kan det fungere med både parallell og samtidig utførelse, og det kan gi et klassetrinn og testløperapper. Én en bemerkelsesverdig egenskap ved NUnit at den er ganske enkel å bruke.

  • JUnit

Som du kan gjette på navnet, er JUnit et enhetstesting av automatiseringsverktøy for Java. JUnit-varebilen er enkelt integrert med IDE-er som formørkelse, Macen ACT, etc. Den er i stand til å støtte testdrevet utvikling og den kan synkronisere eksisterende tester med nyopprettede en gang også. JUnit er en helt åpen kildekode og gratis å bruke for alle slags Java-utvikling.

  • CSUnit

Akkurat som Nunit er CSUnit bygget for å støtte enhetstesting i .Net Framework. Den støtter språk som C # og VB.Net. CSUnit har innebygd støtte for factoring praksis og andre typer praksis som brukes i den smidige utviklingen tilnærming av SDLC.

Konklusjon

Testing har en veldig viktig plass i programvareutviklingsprosessen, og White Box Testing er en verdifull tilnærming for å få det til. Selv om denne testtilnærmingen kan være dyr og tidkrevende, gjenstår testing av hvite bokser å være den eneste måten å sikre at alle delene av koden ble dekket i testprosessen.

Den viktigste delen av White Box Testing er hvor kjent testeren er med koden. Noen som har til oppgave å teste på WBT-tilnærming som ikke har en god hånd med kildekoden og programmeringsspråket som brukes, vil føre til mye problemer. Avhengig bare av White Box Testing er ikke en god idé, da det ikke dekker manglende funksjonalitet. For en mer tildekket tilnærming til utviklingen, bør både White Box Testing og Black Box Testing gjøres, da den da vil dekke maksimale feil, mangler og gjenværende funksjoner som må til før produktet kan sendes.

Anbefalte artikler

Dette har vært en guide til White Box Testing. Her diskuterte vi hvordan White Box Testing utføres ved hjelp av eksempler og forskjellige White Box Testing Techniques med verktøy. Du kan også gå gjennom de andre foreslåtte artiklene våre for å lære mer–

  1. Spørsmål om programvaretesting intervju
  2. Karrierer innen programvaretesting
  3. Spørsmål om intervju av spilltest
  4. ETL Testing Interview Questions
  5. Kodedekning vs testdekning | Topp 4 forskjeller å lære
  6. Kode dekningsverktøy | Topp 6 kodedekningsverktøy

Kategori:

Programvare utvikling