Introduktion till White Box Testing

Testning är en av de viktiga delarna av mjukvaruutvecklingen, det ser till att alla buggar är sorterade och att programmet fungerar som det också var tänkt. Testningen av en mjukvaruprodukt kan ha flera steg och flera procedurer. I den här artikeln ska vi ta en titt på en av de viktiga metoderna för testprocessen, White Box Testing.

Vad är White Box Testing?

Vitruta-testning kallas också kodbaserad testning, klarbox-testning, öppenbox-testning och strukturell testning. Grundidén med denna strategi för mjukvarutestning är att titta på den interna strukturdesignen och på programkoden för att testa den.

I vitrutetestning kan testaren se hela programkoden och han har till uppgift att verifiera flödet för hur ingångar och utgångar fungerar i programmet. Till skillnad från svartboxtestning, som är mer fokuserad på att testa programmets funktionalitet, är White Box Testing upptagen med att testa programmets interna strukturer. Genom att titta på programmet på detta sätt kan vi arbeta med att förbättra designen, användbarheten och göra produkten säkrare.

Som du kan gissa kallade det vitlåda eller glaslådestestning eftersom testaren kan se koden och andra delar av programmet.

Vad som gör White Box Testing skiljer sig från Black Box Testing

Om du har tippat tårna i tester tidigare, är jag säker på att du har stött på Black Box Testing. Den största skillnaden mellan White Box Testing och Black Box Testing är att till skillnad från Black Box-testning, vilket görs ur användarens synvinkel, görs White Box Testing från utvecklarens synvinkel.

Med andra ord, snarare än att ta en titt på programmet utanför ser White Box Testing-metoden den interna koden och testar den.

Hur utförs White Box Testing?

Vi kan dela in processen för testning av vitlåda i två viktiga steg.

1. Förstå koden

Först måste en testare i White Box Testing lära sig applikationskoden. Med tanke på att White Box Testing handlar om att förstå och testa hela programmets interna kod, ska alla som har till uppgift att testa koden inte bara ha god kunskap om programmering, utan han kommer också att behöva ha en bra hand med språket av källkoden.

Säkerhet är en av de viktiga aspekterna av White Box Testing, så testaren måste också vara bra på säker kodningssed.

2. Skapa testfall och kör dem

När koden har studerats av testteamet kan de börja testa koden för att kontrollera dess korrekta flöde och struktur. För att göra detta kommer testarna att skriva någon kod för vissa testfall som kommer att försöka gå igenom alla kodrader som finns i programmet.

Det kan också göras i manuell testning som innebär test och fel. Testarna kan också använda några automatiserade testverktyg som JUnit och NUnit.

Ett exempel på vitlåda-testning

För att bättre förstå begreppet White Box Testing, titta på koden nedan:

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

Som vi diskuterade tidigare är målet med White Box Testing att korsa alla grenar, slingor och uttalanden som finns i koden. Med tanke på det kan vi göra två testfall, ett där båda ingångarna är positiva och en annan där båda ingångarna är negativa heltal.

Exempel:

  • A = 10 och B = 20
  • A = -10 och B = -20

Testningstekniker för vit låda

En av de mest populära testteknikerna för testning av vitlåda kallas kodtäckningsanalys, den här tekniken försöker eliminera eventuella luckor i testfallsviten och den identifierar delar av en app som inte används av testfall. När dessa luckor har hittats kan vi skapa fall för att se och verifiera delar av koden som inte är testad, vilket resulterar i en mer polerad produkt i slutet.

Följande är några tekniker för täckningsanalys:

  • Uttalningstäckning: I den här metoden försöker vi genomgå alla uttalanden i koden minst en gång. Detta säkerställer att hela koden testas.
  • Grenstäckning: Denna metod är planerad att korsa varje gren av beslutspunkterna i koden. Detta ser till att alla beslut testas minst en gång.

Det finns några andra testtekniker också, här är bara några:

  • Tillståndstäckning: I denna testteknik ser vi till att alla villkor täcks i koden, till exempel:

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

Som ni ser har vi här två villkor: A == 0 och B == 0. Nu får dessa villkor SANT och FALSE som värden. Ett möjligt exempel kan vara:

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

  • Täckning av flera tillstånd: Det här är lite mer avancerat än den senaste. Som ni kan gissa testar vi alla möjliga kombinationer och alla möjliga resultat minst en gång. Här är ett anständigt exempel:

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

Därav. Vi kräver fyra testfall under två villkor.

Därför om det finns n villkor kommer vi att kräva 2 n testfall.

  • Grundvägstestning: I den här vita rutan testningsteknik gör vi kontrollflödesdiagram och sedan beräknar vi dess cyklomatiska komplexitet som är antalet oberoende vägar. Med hjälp av den cyklomatiska komplexiteten kan vi hitta det minimala antalet testfall vi kan utforma för varje oberoende bana i flödesgrafen.
  • Loop Testing: Loops är ett av de mest använda verktygen i en programmerares vapen. Eftersom dessa är kärnan i så många algoritmer, är det bara meningsfullt att ha en testteknik baserad på slingor. Det kan finnas tre typer av slingor: Enkel, kapslad och sammankopplad. Låt oss ta en titt på hur en testare kommer att hantera tekniken av dessa typer:

1. Enkla öglor: För en slinga som är enkel i designen och har storleken n, kan vi utforma några testfall som gör följande:

  • Hoppa över nämnda slinga.
  • Korsa endast slingan en gång.
  • Har 2 pass
  • Har något antal pass som är mindre än storleken.
  • n-1 och n + 1 passerar genom slingan.

2. Kapslade slingor: För kod med kapslade slingor börjar vi med den innersta slingan och går sedan utåt tills vi når den yttersta slingan.

3. Sammankopplade öglor: När det gäller dessa öglor. Vi använder enkla slingtest en gång efter varandra och om den sammanfogade slingan inte är oberoende kan vi hantera dem som vi gjorde med kapslade slingor.

fördelar

Nu när vi har sett vad denna testmetod är och hur den fungerar. Låt oss ta en titt på några av fördelarna med detta.

  • White Box Testing har enkla och tydliga regler för att låta en testare veta när testningen är genomförd.
  • Testningstekniker i vitlåda är enkla att automatisera, vilket resulterar i att en utvecklare måste anställa färre testare och mindre utgifter.
  • Den visar flaskhalsar vilket gör optimeringen ganska enkel för programmerarna.
  • Ett testteam kan komma igång med sitt arbete utan att behöva vänta på att utvecklingsgruppen ska slutföra UI-utvecklingen.
  • Eftersom alla kodvägar behandlas i koden i de flesta fall är testet av kod mer genom.
  • Det hjälper till att ta bort delar av koden som inte är väsentliga för programmets funktionalitet.

nackdelar

  • Det är ganska beskattning av resurser. För att få testen gjort behöver du någon som känner din kod mycket väl för att vara i testteamet och som är en bra programmerare själv. Denna typ av färdighetsnivå ökar testkostnaderna.
  • I många fall är det inte möjligt att testa alla möjliga villkor i koden på grund av tidsbegränsningar eller budgetbegränsningar.
  • Eftersom vitrutetestning baseras på att kontrollera funktionaliteten för den befintliga koden kan du inte hitta den saknade funktionaliteten i programmet.
  • Om någon del av koden omformas och skrivs om igen, måste testare skriva testfallen igen.

Testning av vitlåda

Nu när du är bekant med fördelar, nackdelar och tekniker för testning av vitlåda kan vi ta en titt på några populära verktyg som testare kan använda för att utföra vitlådestestning.

  • JSUnit.net

Detta är ett JavaScript-testverktyg. JSUnit är en del av Junit och dess ett ramverk för öppen källkodstest som kan användas för att göra White Box Testing. JSUnit är helt öppen källkod under GNU Public License 2.0 vilket betyder att även för kommersiellt bruk behöver en utvecklare inte betala någon licensavgift.

  • cppunit

Precis som JSUnit, anses CppUnit också vara en del av JUnit. Verktyget kan matas ut i ren text eller XML-format, beroende på testarens behov och det kan skapa enhetstester med sina egna klasser. CppUnit är licensierat enligt LGPL.

  • Veracode

Även om det inte är gratis att använda, har Veracode några kraftfulla verktyg som kan användas för att testa .NET, C ++, Java och vissa andra språk. White Box-testen kan också göras applikationer gjorda för stationära, webb- och mobila appar också.

  • NUnit

Det är ett enhetstestningsramverk och det skrevs i C #. Verktyget stöder alla tillgängliga. Net-språk och det stöder också datadriven test. Funktionsmässigt klokt, det kan fungera på både parallellt och samtidigt utförande och det kan ge en klassramverk och testrunner-appar. En av de anmärkningsvärda funktionerna i NUnit är att den är ganska lätt att använda.

  • JUnit

Som du kan gissa från dess namn är JUnit ett enhetstestningsautomatiseringsverktyg för Java. JUnit-skåpbilen kan enkelt integreras med IDE: er, såsom eclipse, Macen ACT, etc. Den kan stödja testdriven utveckling och den kan synkronisera befintliga test med nyligen skapade en gång också. JUnit är en helt öppen källa och gratis att använda för alla typer av Java-utveckling.

  • CSUnit

Precis som Nunit är CSUnit byggd för att stödja enhetstest i .Net Framework. Det stöder språk som C # och VB.Net. CSUnit har inbyggt stöd för factoringpraxis och andra typer av metoder som används i SDLC: s smidiga utveckling.

Slutsats

Testning har en mycket viktig plats i mjukvaruutvecklingsprocessen och White Box Testing är en värdefull strategi för att få det gjort. Även om denna testmetod kan vara dyr och tidskrävande återstår White Box Testing att vara det enda sättet att se till att alla delar av koden täcktes i testprocessen.

Den viktigaste delen av White Box Testing är hur bekant testaren är med koden. Någon som har till uppgift att testa på WBT-strategi som inte har en bra hand med källkoden och det programmeringsspråk som används kommer att orsaka mycket problem. Beroende på White Box Testing är det inte en bra idé eftersom det inte täcker funktionalitet som saknas. För en mer täckt strategi för utvecklingen bör både White Box Testing och Black Box Testning göras eftersom det sedan kommer att täcka maximala buggar, defekter och återstående funktioner som måste läggas till innan produkten kan levereras.

Rekommenderade artiklar

Detta har varit en guide till White Box Testing. Här diskuterade vi hur White Box Testing utförs med hjälp av exempel och olika White Box Testing-tekniker med verktyg. Du kan också gå igenom våra andra artiklar som föreslås för att lära dig mer–

  1. Intervjufrågor för mjukvarutestning
  2. Karriärer inom mjukvarutestning
  3. Speltestintervjuer
  4. ETL-testintervjufrågor
  5. Kodtäckning vs testtäckning | Topp 4 skillnader att lära sig
  6. Verktyg för kodtäckning | Topp 6 verktyg för kodtäckning

Kategori:

Mjukvaruutveckling