White box är en kategori av programvarutestning som avser testmetoder för att testa hur programvarans interna struktur och design fungerar. Det står i kontrast till black box-testning, som är testning som inte berörs av programvarans interna funktioner utan endast testar programvarans externa utdata.
I den här artikeln ska vi utforska ämnet white box-testning: vad det är, hur det fungerar och vilka typer av verktyg för programvarutestning som kan hjälpa testare och utvecklare att utföra white box-testning i programvarutestning.
Vad är white box-testning?
White box-testning är en teknik för programvarutestning som innebär att man testar den interna strukturen och designen av en programvarubyggnad i motsats till de externa resultaten eller slutanvändarupplevelsen som testas i black box-testning.
White box-testning är ett paraplybegrepp som omfattar många olika typer av programvarutestning, inklusive enhetstestning och integrationstestning. Eftersom white box-testning innebär att man testar kod och programmering krävs det vanligtvis en viss förståelse för datorprogrammering för att utföra white box-testning.
Testning av vit ruta inom programvaruteknik kan innebära att man testar koden och den interna utformningen av programvaran för att verifiera input-outputflödet och kontrollera programvarans utformning, användbarhet och säkerhet.
White box testing gör det möjligt för testare att inspektera systemets inre funktion samtidigt som de kontrollerar att inmatningar resulterar i specifika, förväntade resultat.
White box-testning är ett viktigt steg i programvarutestning eftersom det är den enda typ av testning som tar hänsyn till hur själva koden fungerar.
1. När och varför behöver du en vit låda?
testning inom programvarutestning och teknik?
White box-testning kan utföras i olika skeden av testcykeln för att verifiera funktionen hos den interna koden och strukturen.
Vanligast är att white box-testning sker när utvecklare och testare utför enhetstestning och ibland under integrationstestning.
Per definition anses enhetstestning vara en typ av white box-testning, medan integrationstestning kan ha inslag av både white och black box-testning, men anses i allmänhet vara en form av black box-testning.
Annars kan white box-testning också användas ad hoc för att verifiera det interna arbetet i en programvarubyggnad. White box-testning är det mest ekonomiska sättet att öka testtäckningen om det finns ett behov av det, och det är också ett enkelt sätt att verifiera hur specifika avsnitt av koden fungerar eller att testa områden i en programvarubyggnad som testare misstänker är undertestat.
Formella kodgranskningar, som utförs tillsammans med white box-testning, kan också användas för att identifiera säkerhetsbrister och andra sårbarheter. Om delar av koden är trasiga kan white box-testning hjälpa programvaruingenjörer att fastställa var felet finns.
2. När du inte behöver göra testning i vit låda
I de flesta fall, när programvaruingenjörer och testare testar en ny programvarubyggnad, är det nödvändigt med en viss mängd white box-testning för att verifiera kodens interna funktionssätt.
Enhetstestning är en typ av white box-testning som utförs av utvecklare för att kontrollera att enskilda enheter fungerar som förväntat. Denna tidiga typ av testning gör det möjligt för utvecklare att identifiera fel och brister innan formell testning i en QA-miljö äger rum.
Efter enhetstestning sker integrationstestning, systemtestning och testning av användarnas acceptans. Dessa anses i allmänhet vara former av black box-testning som vanligtvis inte inbegriper en hel del white box-testningstekniker.
I vissa fall kan testare och utvecklare dock använda white box-testning under dessa faser för att identifiera specifika fel i koden. Om det i detta skede inte finns några indikationer på att det är något fel på koden och om alla black box-testerna är godkända, kan många testteam anse att det inte finns något behov av att utföra ytterligare white box-tester.
3. Vem är inblandad i white box-testning?
White box-testning utförs nästan alltid av mjukvaruutvecklare och mjukvaruingenjörer. Detta beror på att white box-testning kräver detaljerade kunskaper om datorkod och kodningstekniker, och de flesta QA-testare saknar de tekniska färdigheter som krävs för att utföra white box-testning.
Enhetstestning, den primära typen av white box-testning, utförs alltid av utvecklare i utvecklingsmiljön. Utvecklare kan också utföra white box-testning när det behövs, för att kontrollera hur olika delar av koden fungerar eller för att kontrollera att fel har rättats till på rätt sätt.
Fördelarna med white box testing
White box-testning gör det möjligt för utvecklare och mjukvaruingenjörer att testa fler aspekter av koden än black box-testning.
Medan black box-testning kan berätta hur en programvarubyggnad fungerar för slutanvändare, kan white box-testning berätta mer om hur programkoden fungerar. Ren och effektiv kod är viktigt vid programvaruutveckling, särskilt om utvecklarna vill återanvända koden senare eller lägga till patchar och uppgraderingar i framtiden.
1. Maximera testtäckningen
White box-testning kan hjälpa testare att maximera testtäckningen. Genom att testa så mycket som möjligt av programkoden maximeras vanligtvis chansen att upptäcka eventuella buggar eller fel i koden, och syftet med white box-testning är vanligtvis att testa så mycket som möjligt av koden.
Black box-testning å andra sidan handlar helt enkelt om att utföra testfall som kan eller inte kan erbjuda en bred kodtäckning.
2. Hitta dolda fel och buggar
En av de största fördelarna med white box-testning är att eftersom white box-testning verifierar intern funktionalitet gör det lättare för utvecklare att hitta fel och buggar som annars skulle kunna vara dolda djupt inne i koden.
Förutom att identifiera förekomsten av fel är det vanligtvis lättare att lokalisera exakt var i kodbasen felet finns när du utför white box-testning på grund av den här typen av testtekniks mycket specifika karaktär.
3. Lätt att automatisera
Det är mycket enkelt att automatisera white box-testning, särskilt när du utför enhetstestning. Enhetstester kräver vanligtvis att utvecklare testar små delar av koden individuellt för att se om de fungerar som förväntat. Detta är mycket lätt att automatisera, vilket innebär att det är en snabb och effektiv form av programvarutestning.
Detta är en av anledningarna till att enhetstestning utförs före andra, mer tidskrävande typer av testning.
4. Tidseffektivt
White box-testning är tidseffektivt av flera skäl.
Som nämnts ovan är det relativt enkelt att automatisera de flesta typer av white box-testning, vilket innebär att det ofta går snabbare att utföra white box-testning än black box-testning. White box-testning gör det dessutom lätt för utvecklare att hitta fel och buggar som de identifierar i koden eftersom de hittar dem när de testar själva koden.
5. Kodkvalitet
White box-testning gör det möjligt för utvecklare att ta en andra titt på den kod de har skrivit och bedöma dess kvalitet och renhet.
Att gå igenom koden bit för bit ger utvecklare möjlighet att ta bort onödiga avsnitt av koden och rensa upp koden, vilket gör det lättare att återanvända och redigera avsnitt av koden i framtiden.
Det kan också tvinga utvecklare att fundera över hur koden implementeras och om den kommer att kunna skalas upp i framtiden.
Utmaningarna med testning i vit låda
Testning av vita lådor är inte utan utmaningar. Det finns några skäl till varför vissa utvecklingsteam kan tycka att det är svårare att utföra white box-testning än black box-testning, och det finns också andra skäl till varför vissa anser att det är mindre viktigt än black box-testning.
1. Tekniska hinder
White box-testning medför tekniska hinder som black box-testning inte gör. För att utföra white box-testning behöver testare kunskap om systemets interna funktionssätt, vilket i programvarutestning vanligtvis innebär kunskaper i programmering.
Därför utförs white box-testning nästan alltid av mjukvaruingenjörer och utvecklare och inte av QA-testare, som sällan har den tekniska kompetens som krävs för att utföra denna typ av testning.
2. Kostnad
White box-testning kan vara dyrare att genomföra jämfört med black box-testning på grund av hur grundlig denna typ av testning är.
Utvecklare måste lägga ner mycket tid på att skriva intensiva enhetstester, och tester i vita lådor kan ofta inte återanvändas för andra tillämpningar, vilket innebär att tester i vita lådor vanligtvis kostar ganska mycket att utföra.
3. Noggrannhet
Testning i vit ruta är inte alltid den mest exakta metoden för programvarutestning och om utvecklingsteam enbart förlitar sig på testning i vit ruta skulle det resultera i många missade buggar och fall.
White box-testning validerar endast funktioner som redan finns, medan black box-testning kan användas för att testa delvis implementerade funktioner eller identifiera funktioner som faktiskt saknas i programvaran och som bör inkluderas i senare iterationer.
4. Tillämpningsområde
White box-testning säger vanligtvis inte mycket om användarupplevelsen eller slutresultatet av de funktioner som är inbyggda i programvaran.
Även om utvecklare kan använda white box-testning för att kontrollera om koden fungerar som den ska, kan de inte dra slutsatsen att den fungerande koden levererar rätt resultat till slutanvändarna utan att kombinera white box-testning med black box-testning.
Detta innebär att det finns begränsningar i omfattningen av white box-testning och hur mycket den kan berätta om programvaran.
Egenskaperna hos tester med vita lådor
White box-testning kan definieras genom särskilda egenskaper som skiljer den från andra former av testning, t.ex. black box- och grey box-testning.
De flesta av dessa egenskaper kan betraktas utifrån hur de skiljer sig från egenskaperna hos black box-testning och hur detta skiljer white box-testning och black box-testning åt.
1. Underhållbarhet
White box-testning leder till en högre grad av underhållbarhet i din kod, vilket förenklar det arbete som ditt team måste utföra i framtiden.
Eftersom det finns ett ständigt öga på koden och vad den gör med data är det mycket enklare att underhålla den eftersom du förstår var problem uppstår och varför de uppstår. Detta gör också koden enklare för framtida uppdateringar, eftersom du inte behöver utveckla stora och komplexa patchar för okända och enkla problem.
2. Flexibilitet
White box-testning sker på kod som är tillräckligt flexibel för att kunna ta emot ändringar relativt snabbt. Inflexibel kod, t.ex. sådan som ingår i en modul eller integration från tredje part, hindrar en testare av en vit låda från att göra snabba ändringar.
Att fokusera på att ha kod som du kan ändra så fort du upptäcker ett problem gör white box-testning mycket anpassningsbar och innebär att problem i ett program löses mycket tidigare.
3. Modularitet
White box-testning trivs bäst i kod som har en viss grad av modularitet, vilket innebär att separata delar av programvaran är tydligt åtskilda från varandra.
Om ett program har ett problem med ”spaghettikod” där varje aspekt är knuten till en annan, blir white box-testning oändligt mycket mer komplex eftersom testaren måste undersöka hela programmet snarare än en specifik enhet.
4. Integration
White box-testning är mycket användbart för integrationstestning. Testare kan se om en funktion fungerar fram till den punkt då den lämnar programvaran i fråga och om den återvänder från det integrerade systemet så funktionellt som förväntat.
Detta är mycket informativt och låter organisationen veta om problemet är lokalt eller om det är en del av den integrerade plattformen.
Vad testar vi i white box-tester?
White box-tester används för att testa funktioner i koden som inte kan verifieras med black box-testmetoder. Detta kan innebära att testa hur själva koden fungerar, vilket gör det möjligt för utvecklare att förstå orsak och verkan av olika aspekter av koden.
Utvecklare använder white box-testning för att testa säkerhetshål, uttalanden och funktioner, utgångar och vägar i koden.
1. Interna säkerhetshål
White box-testning kan användas för att leta efter säkerhetsluckor och sårbarheter i koden som hackare och cyberkriminella kan utnyttja i framtiden.
White box-testning kan användas för att kontrollera om bästa säkerhetsrutiner har följts under utvecklingsfasen och för att leta efter säkerhetsbrister som kan åtgärdas innan koden går vidare till ytterligare testning.
2. Vägar i kodningsprocesser
Testning i vit ruta gör det möjligt för utvecklare att testa de vägar som förbinder olika delar av koden med varandra. Utvecklare testar inte bara logiken i koden, utan de kan också titta på kodstruktur och hygien.
Bra och ren kod har inga onödiga rader eller trasiga element som inte fungerar som förväntat, även om de externa resultaten av black box-testningen är som förväntat.
3. Förväntade resultat
White box-testning kan också testa de förväntade resultaten av koden på samma sätt som black box-testning, även om testarna gör det genom att titta på koden snarare än genom att använda programmet som testarna kan göra vid black box-testning.
Utvecklare testar förväntade resultat genom att verifiera inmatningar en efter en och kontrollera att det resulterande resultatet överensstämmer med förväntningarna.
4. Uttalanden, objekt och funktioner
Genom att utföra white box-testmetoder kan programvaruutvecklare se till att uttalanden, objekt och funktioner i koden beter sig logiskt och ger förväntade resultat.
5. Villkorliga loopars funktionalitet
White box-testning kan också användas för att kontrollera funktionaliteten hos villkorliga slingor, inklusive enkla, sammanlänkade och inbäddade slingor. Utvecklarna kommer att kontrollera om dessa slingor är effektiva, om de uppfyller kraven på villkorlig logik och om de hanterar lokala och globala variabler korrekt.
För att reda ut en viss förvirring:
Testning av White box vs Black box vs Grey box
White box testing, black box testing och grey box testing är termer som mjukvarutestare använder för att hänvisa till olika kategorier av testning eller olika testmetoder.
En modern syn på dessa skillnader i testning är att gränserna mellan olika typer av boxtestning blir allt otydligare, eftersom olika typer av testning ofta kombinerar delar av både white och black box-testning och tar fram tester från dokument på olika abstraktionsnivåer.
Det finns dock fortfarande viktiga skillnader mellan dessa testformer.
1. Vad är black box-testning?
Testning i svart låda är en form av programvarutestning där programvarans funktionalitet kontrolleras av testare som inte har någon kunskap om kodens interna struktur eller hur koden ska implementeras på en mer teknisk nivå.
Black box-testning testar endast programvarans externa utdata, eller med andra ord testar man vad slutanvändaren kommer att uppleva när han eller hon använder programvaran.
Black box-testning kallas också beteendetestning eftersom den testar hur programvaran beter sig under vissa förhållanden.
Testare kan använda black box-testning för att bedöma hur olika funktioner i programvaran beter sig och kontrollera dessa mot förväntningarna för att se till att programvaran uppfyller användarnas krav. Black box-testning används vid systemtestning och acceptanstestning för att verifiera olika funktioner och kontrollera att systemet fungerar som förväntat när det fungerar som en helhet.
Vid testning i svart låda skriver användarna testfall för att verifiera olika delar individuellt. Eftersom testning av svarta lådor inte kräver samma tekniska färdigheter som testning av vita lådor, utförs testning av svarta lådor vanligtvis av testare i en QA-miljö snarare än av utvecklare.
Det är vanligtvis lättare att automatisera black box-testning jämfört med white box-testning genom att använda automatiseringsverktyg som ZAPTEST.
Vilka är skillnaderna mellan white box och black box testning?
Den främsta skillnaden mellan black box- och white box-testning är vad som testas.
Black box-testning handlar om att testa de externa resultaten av programvarubygget, medan white box-testning handlar om att testa vad som händer under huven.
Några av de viktigaste skillnaderna mellan testning med svart låda och testning med vit låda är följande:
Syfte
Syftet med black box-testning är att kontrollera att systemet fungerar som förväntat för slutanvändaren, medan syftet med white box-testning är att kontrollera kvaliteten och integriteten hos programvarans kod.
Vid testning av ett videospel i svart låda kan till exempel en slutanvändare prova spelet och utvärdera sin upplevelse, medan testning i vit låda av samma projekt säkerställer att inmatning av specifika inmatningar leder till att karaktären utför rätt handling.
Process
De processer som används vid testning av vita och svarta lådor är mycket olika. Det är mycket lättare att automatisera white box-testning än black box-testning, och vanligtvis måste black box-testning automatiseras med hjälp av verktyg för automatisering av programvara.
När man t.ex. testar en databas innebär ett white box-test att man automatiserar datainmatningen för att kontrollera att alla resultat är korrekta, medan black box-testning innebär att användare replikerar manuella processer och rapporterar om dem utan att använda ett automatiseringssystem.
Testare
Black box-testning utförs nästan alltid i en QA-miljö av professionella programvarutestare, medan white box-testning utförs av programvaruutvecklare och ingenjörer som har mer detaljerad teknisk kunskap om kodkällan.
Tekniker
Vid testning i svart låda används olika tekniker som ekvivalenspartitionering, gränsvärdesanalys och testning av beslutstabeller. Vid testning i vit ruta används tekniker som beslutstäckning, villkorstäckning och statementtäckning.
Verksamheter
Testmetoderna för black box-testning lämpar sig för testverksamhet på högre nivåer, t.ex. systemtestning och acceptanstestning, medan white box-testning lämpar sig bättre för verksamhet på lägre nivåer, t.ex. enhetstestning och integrationstestning.
Av denna anledning utförs testning av white box vanligtvis före de flesta former av black box-testning.
2. Vad är testning i grå box?
Grå box-testning är en teknik för programvarutestning som används för att testa programvaruprodukter och applikationer av testare som kanske har partiell kunskap om applikationens interna struktur, men inte fullständig kunskap om den.
Grå box-testning kan kombinera delar av både black box-testning och white box-testning för att göra det möjligt för utvecklare och testare att identifiera fel i koden och hitta kontextspecifika fel.
Grå box-testning kombinerar funktioner från både black box-testning och white box-testning. Testare måste ha en viss kunskap om systemets interna funktionssätt som i white box-testning, men de använder denna kunskap för att skapa testfall och utföra dessa testfall på funktionalitetsnivå som i black box-testning.
Grå box-testning erbjuder många av fördelarna med både black box- och white box-testning samtidigt som den är relativt tidseffektiv och flexibel.
Vilka är skillnaderna mellan white box och grey box testning?
Eftersom testning i grå box erbjuder en del av samma funktionalitet som testning i svart box finns det stora skillnader mellan testning i grå box och testning i vit box, även om de kanske inte är lika stora som för testning i svart box.
Några av de största skillnaderna mellan testning i grå box och testning i vit box är:
Strukturell kunskap
Vid white box-testning ska den person som utför testningen känna till kodens interna utformning och struktur fullt ut. Vid testning i grå box är kodens interna struktur vanligtvis endast delvis känd.
Berörda personer
Testning i vit ruta utförs nästan uteslutande av mjukvaruutvecklare och mjukvaruingenjörer, medan testning i grå ruta kan utföras av slutanvändare, testare och utvecklare.
Effektivitet
White box-testning anses vara den mest tidskrävande typen av programvarutestning, medan grey box-testning lånar en del av effektiviteten från black box-testning för att minska den tid det tar att utföra testerna.
Operation
Vid white box-testning skriver utvecklare helt enkelt kod för att genomföra white box-testningar och kör denna kod. Vid testning i grå box, liksom vid testning i svart box, utför testarna funktionella tester för att bedöma hur systemet fungerar externt.
Täckning
Testning i vit ruta är den mest uttömmande typen av testning, medan täckningen av testning i grå ruta kan variera beroende på om testfallen är baserade på kod eller GUI.
Slutsats:
Vit låda vs svart låda vs Grey box-testning
White box testing, black box testing och grey box testing är termer som används för att hänvisa till olika testmetoder för programvara. I stort sett kan varje testtyp definieras utifrån i vilken utsträckning testarna måste ha kunskap om kodbasen och implementeringen av koden:
1. Testning i svart låda:
Kodens inre struktur är okänd.
2. Testning i vit låda:
Kodens interna struktur är känd.
3. Grå box-testning:
Kodens interna struktur är delvis känd.
Under programvarutestning är alla tre typerna av testning viktiga för att verifiera programvarans funktion och integritet. White box-testning ger oss mer information om kodens underliggande struktur, medan grey box-testning och black box-testning kan verifiera hur systemet fungerar och om det uppfyller slutanvändarens krav.
De kanske största skillnaderna mellan dessa tre testtyper gäller vem som utför varje testtyp, vilka krav som ställs på själva testningen och vad testningen innebär.
White box-testning har det högsta inträdeshindret eftersom den utförs av utvecklare med detaljerad kunskap om själva kodbasen och eftersom det är den mest tidskrävande och ofta kostsamma typen av testning.
Black box-testning är däremot lättast att genomföra och kan utföras av testare utan kunskap om den underliggande koden.
Olika typer av tester i vit låda
Det finns många olika typer av white box-tester, som alla kan användas för att testa lite olika aspekter av kodens interna struktur.
Nedan följer några av de vanligaste typerna av white box-testning som används idag.
1. Testning av sökvägar
Path testing är en typ av white box-testning som bygger på ett programs kontrollstruktur. Utvecklare använder kontrollstrukturen för att skapa ett kontrollflödesdiagram och testa olika vägar i diagrammet.
Path testing är en typ av testning som är beroende av programmets kontrollstruktur, vilket innebär att det krävs att testarna har en grundlig förståelse för denna struktur.
Om ett system till exempel ska kontakta kunderna med bestämda meddelanden vid vissa punkter i försäljningstrappan innebär testning av sökvägar att man ser till att systemet följer rätt steg beroende på de villkor som anges i data.
2. Testning av slingor
Loop-testning är en av de viktigaste typerna av white box-testning som testar loopar i programkoden. Slingor implementeras i algoritmer i koden och genom testning av slingor verifieras om dessa slingor är giltiga.
Loop-testning kan bedöma om det finns sårbarheter i specifika loopar och belysa områden där utvecklare kan behöva korrigera koden för att se till att loopen fungerar som den ska.
Ett exempel på ett slingtest är att följa upp slingan med en specifik uppsättning datapunkter som får slingan att fortsätta, t.ex. att vägra acceptera vissa villkor, innan man anger en siffra som specifikt bryter slingan. Om slingan beter sig som förväntat är testet framgångsrikt.
3. Villkorlig testning
Villkorlig testning är en typ av white box-testning som kontrollerar om de logiska villkoren för värden i koden är sanna eller falska.
Villkorlig testning är en viktig form av testning i vit låda som talar om för utvecklarna om koden är logisk och uppfyller kraven för programmeringslogik.
Ett exempel på villkorlig testning är inom en redovisningsplattform. Om du matar in en rad utgifter och inkomster bör det resultera i rätt löpande summor, och programvaran ger korrekta resultat under ett framgångsrikt test.
4. Testning av enheter
Enhetstestning är ett viktigt steg i programvarutestning där utvecklare testar enskilda komponenter och moduler och kontrollerar att de fungerar som förväntat innan de integrerar olika enheter tillsammans.
Programvaruingenjörer använder white box-testmetoder i enhetstestning för att testa små delar av koden åt gången. Detta gör det enkelt att identifiera fel och buggar när de uppstår under testningen.
Ett exempel på enhetstestning är tidigt i utvecklingen när ett företag skapar en enkel knapp på en webbplats som leder användaren till en annan sida. Om enheten fungerar som förväntat är den framgångsrik, och utvecklarna gör ändringar tills den fungerar.
5. Testning av mutationer
Mutationstestning är en typ av testning som testar förändringar och mutationer. Vid mutationstestning gör utvecklare små ändringar i källkoden för att se om detta kan avslöja fel i koden.
Om testfallet klarar testet tyder det på att det finns något problem med koden, eftersom det inte borde klara testet efter att ändringarna har gjorts. Idealiskt sett ska alla testfall misslyckas vid mutationstestning.
Ett exempel på mutationstestning är inom maskininlärning. Program för maskininlärning ”muterar” automatiskt beroende på ny information, så genom att testa dessa program konsekvent för standarden för ”mutation” får utvecklarna information om huruvida programvaran fungerar som förväntat.
6. Integrationstestning
Integrationstestning är en viktig fas i programvarutestning där testare kontrollerar om olika moduler fungerar korrekt när de integreras med andra moduler.
White box-testmetoder används under integrationstestning för att kontrollera att koden fungerar även när flera moduler – som ofta har kodats av olika utvecklare – fungerar tillsammans.
När en databas hämtar information från en online-källa, till exempel, säkerställer integrationstestning att de uppgifter som hämtas är korrekta och uppdateras i en någorlunda jämn takt.
7. Penetrationstestning
Penetrationstestning är en typ av white box-testning som kan användas för att simulera specifika cyberattacker mot systemet.
Vid penetrationstestning får testarna tillgång till fullständiga nätverks- och systemdata, t.ex. lösenord och nätverkskartor. De försöker sedan komma åt eller förstöra data i systemet genom att försöka använda så många olika angreppsvägar som möjligt.
Penetrationstestning är en viktig aspekt av säkerhetstestning som bör utföras på alla programvarutillverkningar.
En HR-plattform kommer till exempel att genomföra penetrationstester och leta efter sårbarheter i koden för att se till att plattformen är tillräckligt säker för att kunna lagra uppgifter om anställda.
Testmetoder för vit låda
Det finns många olika tekniker för white box-testning som kan användas för att utföra de white box-tester som anges ovan. Som alltid är det så att olika tekniker är bäst lämpade för att testa olika aspekter av koden, men alla de white box-tekniker som anges nedan är viktiga.
1. Uppgiftstäckning
Ett av de utmärkande dragen för white box-testning är att testarna ska försöka täcka så mycket som möjligt av källkoden när de utför white box-testning.
Kodtäckning är ett bra mått på detta, och statement coverage är en sådan teknik som white box-testare kan använda för att öka täckningen av uttalanden i koden.
Statement coverage är ett mått som mäter antalet utförda statements dividerat med det totala antalet statements och multiplicerat med 100. White box-testare bör sträva efter en hög täckning av uttalanden.
2. Täckning av grenar
Täckning av förgreningar, liksom täckning av uttalanden, återspeglar hur omfattande täckningen av vissa delar av koden är vid testning i vita lådor. Förgreningar motsvarar IF-uttalanden i logik, där koden förgrenar sig i sanna och falska alternativ som påverkar resultatet av operationen.
Vid användning av tekniker för gren-täckning kontrollerar testare i vit box om varje gren bearbetas minst en gång och bekräftar att båda grenarna fungerar korrekt.
3. Täckning av banor
Med hjälp av tekniker för banetäckning bedöms banorna i ett programvaruprogram. Maximering av testbanetäckningen innebär att man ser till att alla banor inom programmet undersöks minst en gång. Det är en liknande typ av testteknik som grenövervakning, men den anses vara mer grundlig och effektiv.
Testning med ban-täckning anses vanligen vara lämpligast för att testa kompletta program snarare än partiella byggda program.
4. Täckning av beslut
Beslutstäckning är en av de viktigaste white box-teknikerna eftersom den ger information om sanna och falska resultat av boolska uttryck i källkoden.
Testning av beslutstäckning validerar källkoden genom att se till att varje varumärke för varje potentiellt beslut används minst en gång under testningen.
Beslutspunkter omfattar alla tillfällen där det finns en möjlighet till två eller flera olika utfall.
5. Villkorstäckning
Tillståndstäckning är också känd som uttryckstäckning. Med denna teknik utvärderas undervariablerna i villkorliga påståenden i koden för att verifiera resultatet av varje logiskt villkor.
Denna typ av testning omfattar endast uttryck med logiska operander, medan testning av beslutstäckning och testning av förgreningstäckning används för att säkerställa andra logiska operationer.
6. Täckning av flera tillstånd
I tester som täcker flera villkor kontrollerar testarna olika kombinationer av villkor och utvärderar det beslut som koden fattar för varje kombination.
Det kan finnas många olika testfall för test av täckning av flera villkor på grund av det stora antalet kombinationer av villkor som finns, så den här typen av testning är ofta mycket tidskrävande.
7. Täckning av finita tillståndsmaskiner
Täckning av finita tillståndsmaskiner är en viktig typ av testning, men också ett av de svåraste sätten att uppnå hög kodtäckning i white box-testning. Den bygger på konstruktionens funktionalitet och kräver att utvecklarna räknar hur många gånger ett tillstånd besöks eller överförs under testprocessen, samt hur många sekvenser varje finit tillståndssystem innehåller.
8. Testning av kontrollflödet
Kontrollflödestestning är en testteknik som syftar till att fastställa programmets exekveringsordning med hjälp av en enkel kontrollstruktur.
Utvecklare konstruerar testfall för kontrollflödestestning genom att välja en specifik del av programmet och bygga en testväg. Kontrollflödestestning används vanligtvis i enhetstestning.
Livscykeln för testning av vita lådor
inom programvaruutveckling
White box-testning är ett viktigt steg i livscykeln för mjukvaruutveckling, även om det inte har någon strikt ”plats” i cykeln.
Utvecklare kan utföra white box-testning när de behöver kontrollera kodens funktion, och vissa utvecklare kan vara mer noggranna än andra när det gäller att kontrollera nyskriven kod för att se till att den är ren och fri från onödiga rader.
White box-testning utförs dock oftast under enhetstestning och integrationstestning. Både enhetstester och integrationstester utförs av utvecklarna under utvecklingsfasen.
De sker innan funktionell testning, t.ex. systemtestning och acceptanstestning, äger rum och ger utvecklarna möjlighet att identifiera, lokalisera och åtgärda större fel tidigt i testfasen innan produkten överlämnas till kvalitetssäkringsteamet.
Manuella eller automatiserade white box-tester?
Precis som andra typer av programvarutestning är det möjligt att automatisera white box-testning. Det kan vara antingen manuellt eller automatiserat, även om det i de flesta fall är lättare att automatisera white box-testning än att automatisera black box-testning.
Eftersom testning av vita lådor är en mycket tidskrävande typ av testning blir automatisering allt populärare bland programvaruteam.
Manuell testning av vita lådor: fördelar, utmaningar och processer
Manuell white box-testning innebär att utföra white box-tester manuellt, och det kräver att utvecklarna har kompetens och tid att skriva enskilda testfall för att testa varje kodrad i en programvarubyggnad. Detta kan ta mycket tid, men det ger också de mest grundliga testresultaten och resultaten.
Några av fördelarna med manuell testning av vita lådor är följande:
1. Djup
Manuell testning gör det möjligt för testare att utforska programkoden mer ingående än automatiserad testning om de vill, till exempel genom att läsa igenom hela källkoden för ett program i stället för att bara automatisera uppgifter som rör funktionaliteten på ytan.
2. Plats för fel
Manuell testning gör det lätt att hitta fel och brister eftersom utvecklarna ska kunna peka ut exakt vilken kodrad felet finns i.
Om du till exempel ser att en bild inte laddas och sedan undersöker koden för att hitta rader som involverar laddning av bilder, kan du begränsa orsaken avsevärt.
3. Hastighet
Manuell testning tar vanligtvis längre tid än automatiserad testning, men om utvecklare bara vill köra ett eller två snabba tester är det förmodligen snabbare att utföra dem manuellt än att installera automatisering.
Enhetstestning innebär till exempel att man tittar på en funktion och ser om den fungerar, snarare än att samla in stora mängder data genom att automatisera processen. Men det finns också nackdelar med manuell testning av vita lådor.
Några av utmaningarna med manuell testning av vita lådor är följande:
1. Noggrannhet
Manuell testning kan göra det möjligt för utvecklare att täcka in ett stort antal koder, men mänskliga testare är alltid mer benägna att begå misstag och fel än datorprogram, vilket innebär att manuell testning ofta anses vara mindre exakt än automatiserad testning.
2. Tid
Manuell testning tar längre tid än automatiserad testning, och manuell testning av vita lådor är en av de mest tidskrävande testerna av alla. Detta ökar omloppstiden och kan göra det svårare att hålla snäva utvecklingsfrister.
3. Kostnad
På grund av den mängd arbetskraft och resurser som krävs för manuell testning av vita lådor är detta ofta dyrare för utvecklingsteamen än automatiserad testning, som vanligtvis kräver färre utvecklare och mindre tid.
4. Skalbarhet
Manuell testning lämpar sig egentligen bara för testning av små applikationer eller för testning av enskilda komponenter i större applikationer. För större tillämpningar, t.ex. en molnbaserad databas med tusentals inmatningar per minut, är automatiserad testning att föredra som en metod för att simulera standardbelastningar.
Automatiserad testning av vita lådor: fördelar,
utmaningar och processer
Automatiseringstekniken gör det lättare att automatisera aspekter av programvarutestning varje dag. Branschens övergång till hyperautomatisering beror delvis på den effektivitet och de kostnadsbesparingar som automatiseringen erbjuder utvecklingsteam som alltid känner sig pressade.
White box är en av de mest lämpliga typerna av testning för automatisering eftersom den är relativt lätt att automatisera och tids- och kostnadsbesparingarna med automatisering av white box-test kan vara betydande.
Automatiserad white box-testning kan innebära att utvecklarna själva skriver testskript, eller så kan processen påskyndas med hjälp av fullstackverktyg som ZAPTEST, som tillhandahåller toppmodern teknik för testning av mjukvara från början till slut.
Några av fördelarna med att automatisera white box-testning är:
1. Noggrannhet
Datorbaserade tester eliminerar risken för fel eftersom datorer inte tröttnar eller gör misstag.
2. Tid
Automatiserad white box-testning är betydligt snabbare än manuell white box-testning och frigör tid som utvecklarna kan lägga på andra uppgifter, t.ex. att åtgärda fel eller skriva uppgraderingspatchar.
3. Skala
Automatiserad testning kan skalas upp mycket bättre än manuell testning, så om din programvara växer eller om du vill utföra storskalig testning på en gång är automatisering det bättre alternativet.
Till exempel innebär en uppgradering av datainmatningen att man begär fler inmatningar vid automatisering, jämfört med att anställa fler anställda vid manuella tester.
4. Kostnad
Kostnaden för automatiserad testning är vanligtvis lägre än kostnaden för manuell testning på grund av det antal arbetstimmar som sparas genom automatiseringen. ZAPTESTs 10x ROI visar hur automatisering kan spara pengar för utvecklare och leda till högre avkastning. Automatiseringen är dock inte utan nackdelar.
Några av utmaningarna med att automatisera testning av vita lådor är följande:
1. Spårning av fel
Automatisering gör det inte alltid lätt att hitta fel i koden, beroende på hur utvecklarna automatiserar testerna eller vilka testverktyg som används, särskilt om man jämför med manuell white box-testning där testarna kan se koden som körs när ett fel dyker upp.
2. Kompetens
Det är inte alla utvecklare som vet hur man automatiserar tester eller hur man använder automatiserade testverktyg, så för att övergå till automatisering kan det krävas en viss investering i utbildning av viktiga färdigheter, t.ex. kodning i den specifika testplattformens språk och användning av färdigheter i dataanalys för att förstå orsaken till problem i ett white box-test.
Slutsats: Manuell testning av vita lådor
eller white box test automation?
Sammantaget är testning av vita lådor inom programvaruteknik en av de lämpligaste typerna av testning att anpassa till automatiserad testning, till stor del på grund av att manuell testning av vita lådor är tidskrävande och komplicerad.
Automatiserad white box-testning är snabbare, billigare, effektivare och mer exakt än manuell testning, särskilt när man arbetar med större applikationer.
Om möjligt bör programvaruutvecklare automatisera white box-testning i programvarutestning för att öka testens tillförlitlighet och täcka ett större område av större applikationer genom testning än vad som är praktiskt möjligt när testerna utförs manuellt. Detta beror på de betydande kostnader och den expertis som krävs när du utför white box-tester med enbart manuella metoder.
Vad behöver du för att börja
testning i vit låda?
Innan du börjar med white box-testning ska du se till att du har allt du behöver för att komma igång. Beroende på om du utför manuell eller automatiserad testning av vita lådor behöver du inte mycket resurser utöver tid och pengar.
Du måste dock se till att ditt team har lämplig kunskap och lämpliga verktyg för att kunna utföra testning i vit box på ett korrekt sätt.
1. Förståelse för källkoden
White box-testning är testning som utförs av programvaruutvecklare och ingenjörer som har full kännedom om källkoden och programvarans interna struktur.
Om du är en QA-testare utan denna kunskap måste du lämna över programvaran till någon annan innan testningen av den vita lådan kan påbörjas.
2. Testfall
Det är nödvändigt att skriva testfall innan man utför testning i vit låda. Testfall är enskilda uppsättningar av instruktioner som beskriver åtgärder som testare eller utvecklare kan utföra för att testa ett systems funktioner och arbetssätt.
Vid testning i vit låda utformas testfallen av personer med fullständig kunskap om systemets interna struktur och skapas för att kontrollera om det fungerar som det ska.
3. Verktyg för testning av vita lådor
Det finns gott om verktyg för white box-testning som ger tillgång till källkod och konstruktionsdokument samtidigt som man genomför testautomatisering. Dessa finns också i olika prisklasser för användarna, till exempel ZAPTEST FREE och ZAPTEST ENTERPRISE-versioner som ger mer flexibilitet.
Välj de verktyg som du vill använda innan du börjar testa, med tonvikt på att se till att verktyget har rätt funktionalitet, t.ex. plattformsoberoende drift och Computer Vision-teknik, så att du kan se det som automatiserade tester ser.
Se till att alla utvecklare och ingenjörer som deltar i testningen vet hur och när de ska använda dem.
Processen för testning av den vita lådan
White box-testning innebär mycket mer kunskap om hur ett system fungerar än black box-testning, och vissa av stegen i white box-testning är lite annorlunda.
White box-testare måste först identifiera de funktioner eller komponenter i systemet som de vill verifiera innan de planerar möjliga testvägar och skriver testfall som ska utföras.
Processen för white box-testning kan också skilja sig åt beroende på vilken testteknik du använder. Följ nedanstående steg för att ta reda på hur du kan utföra white box-testning och samtidigt maximera täckningen av sökvägen.
Steg 1: Identifiera de funktioner som ska testas
Innan du utför white box-testning ska du fundera på exakt vad du vill testa och hur du ska testa det. Detta innebär vanligtvis att man fokuserar på en liten uppsättning funktioner eller egenskaper och skapar en uppsättning testfall för att testa dessa.
Du kommer att utföra det här steget om och om igen för olika delar av systemet för att maximera testtäckningen, men det är viktigt att dela upp olika delar i enskilda tester.
Ju mer fokus du har, desto mer tillförlitliga och exakta kan dina tester vara.
Steg 2: Plotta alla möjliga vägar i en flödesgraf.
En stor del av förberedelserna för testning i vit ruta består i att plotta alla möjliga vägar som du behöver testa i ett flödesdiagram.
Det här steget kan hjälpa dig att maximera banetäckningen och se till att du verifierar alla möjliga banor i varje testfall som du skapar. Rita ett flödesdiagram som täcker alla möjliga vägar för varje funktion eller komponent som du testar, t.ex. genom att beskriva olika vägar som uppstår när olika värden matas in.
Steg 3: Identifiera alla möjliga vägar
Titta på ditt flödesdiagram och identifiera alla möjliga vägar som användarna kan ta, från det första steget i flödesdiagrammet till det sista steget.
Ju fler grenar och beslut som finns i flödesdiagrammet, desto fler unika vägar kommer att finnas. Att förstå hur många unika möjliga vägar som finns kan hjälpa dig att se till att dina testfall täcker alla möjligheter.
Steg 4: Skapa testfall
Nästa steg i White Box-testningen är att skriva testfall som verifierar alla de vägar som du har identifierat ovan.
Det är viktigt att se till att dina testfall täcker alla möjliga vägar och tydligt beskriver de åtgärder som testare eller utvecklare måste vidta för att utföra varje testfall.
För varje testfall ska du ange testfallets ID och namn tillsammans med en kort beskrivning och de förväntade resultaten av varje test.
Steg 5: Utför testfall
Det är nu dags att utföra testfallen, vilket de flesta anser vara att utföra själva testningen av den vita lådan.
Testare utför testfallen genom att följa de korta instruktioner som beskrivs i varje testfall och rapporterar resultatet av varje testfall. Detta kan jämföras med de förväntade resultaten som beskrivs i testfallet för att fastställa om varje test har godkänts eller misslyckats.
Steg 6: Upprepa cykeln vid behov.
Liksom andra former av programvarutestning handlar white box-testning om att jämföra hur systemet faktiskt fungerar med de förväntningar som testarna har på hur systemet ska fungera.
Om testarna upptäcker att systemet inte beter sig på det sätt som de förväntar sig kan det betyda att testningen av den vita lådan har misslyckats, och utvecklarna måste korrigera kodraderna innan de genomför ytterligare tester.
Upprepa processen ovan för att utföra ytterligare tester av den vita lådan tills systemet har testats grundligt och eventuella fel har rättats till.
Bästa praxis för testning av vit låda
De bästa metoderna för white box-testning beror på vilken typ av testning du utför och i vilket skede av testprocessen du befinner dig.
Eftersom de flesta testerna av white box sker under enhetstestning och integrationstestning, gäller de flesta bästa metoderna för white box-testning för dessa faser.
1. Maximera testtäckningen
Per definition är det viktigt att maximera testtäckningen när du utför white box-testning för att säkerställa att en hög procentandel av programvaran testas under denna fas.
Detta kan du göra genom att maximera täckningen av vägar och grenar och skriva testfall som utforskar alla möjliga vägar och resultat under förberedelsefasen.
2. Kontrollera beteende och prestanda
När du skriver testfall i white box-testning vill du skapa testfall som verifierar att systemet fungerar som du förväntar dig och testfall som verifierar systemets prestanda.
Förutom att kontrollera att vissa åtgärder leder till vissa resultat kan du till exempel också kontrollera hur snabbt systemet kan utföra vissa uppgifter eller hur prestandan påverkas av olika variabler.
3. Skriv testfall oberoende av varandra.
Om du vill verifiera två olika funktioner, t.ex. om en kodklass är beroende av en viss databas, skapar du ett abstrakt gränssnitt som återspeglar den här databasanslutningen och implementerar ett gränssnitt med ett mock-objekt för att testa den här anslutningen.
Detta säkerställer att testfallen verifierar de anslutningar som du vill att de ska verifiera och inte något annat.
4. Täck alla stigar och slingor.
Maximering av testtäckningen innebär att man täcker alla möjliga vägar och tar hänsyn till villkorliga slingor och andra typer av slingor i koden.
Se till att du utformar testfall som utforskar alla möjliga vägar och verifierar att slingorna beter sig som du förväntar dig, oavsett vad som anges.
7 misstag och fallgropar när du
Genomförande av tester i vit låda
När du börjar testa white box-testning är det viktigt att du är medveten om några av de vanligaste fallgroparna som utvecklare ofta hamnar i när de utför white box-testning. Vanliga misstag vid testning av vita lådor kan leda till förseningar och felaktigheter som kan skada kvaliteten och tidsplanen för programvaruutgivningen.
1. Tror att testning av vita lådor inte är nödvändigt.
En del testare anser att testning i vit låda inte är nödvändig, eftersom testning i svart låda testar alla programvarans externa utgångar, och om dessa fungerar korrekt antas det att systemets interna funktion också fungerar.
White box-testning kan dock hjälpa utvecklare att hitta problem och buggar som kanske inte alltid dyker upp i black box-testning, och det är viktigt för att verifiera säkerheten i programvarusystem.
Om ett program till exempel har en minnesläcka som orsakar prestandaförlust under längre tidsperioder och som inte kan undersökas med black box-testning, är white box-testning det enda alternativet för att gå igenom koden och hitta problemet innan den släpps till allmänheten.
2. Utföra all testning av vita lådor manuellt.
Vissa utvecklare tror kanske att det är lika lätt att utföra white box-testning som black box-testning.
Testning av vita lådor är dock betydligt mer tidskrävande och utvecklare som försöker utföra testning av vita lådor helt manuellt kan upptäcka att det är omöjligt att utföra manuella kontroller enligt önskad standard eller samtidigt maximera testtäckningen.
3. Tilldelning av testare för att utföra testfall
White box-testning bör utföras helt och hållet av utvecklare, mjukvaruingenjörer och personer som förstår mjukvarusystemets inre arbete fullständigt.
En del utvecklare tror att de kan överlåta white box-testning till QA-testare när de själva har skrivit testfallen, men det kommer bara att leda till dåligt genomförande och försämra kvaliteten på dokumentationen.
4. Att skynda sig igenom testerna
Mjukvarutestning är en lång och tidskrävande process, och vissa utvecklare kan frestas att skynda sig igenom white box-testning för att gå vidare till nästa utvecklingsfas. Det är viktigt att avsätta tillräckligt med tid och resurser för white box-testning för att säkerställa att utvecklarna inte känner sig pressade och att de har tillräckligt med tid för att maximera testtäckningen.
5. Dålig dokumentation
Genom att dokumentera ordentligt före, under och efter testningen säkerställer du att alla som är involverade i mjukvaruutveckling och testning har tillgång till rätt information vid rätt tidpunkt.
Se till att varje medlem i utvecklingsteamet vet hur man skriver tydlig dokumentation och hur man rapporterar resultaten av white box-testning.
6. Felaktig användning av automatiseringsverktyg
Automatiseringsverktyg kan göra det enkelt att utföra white box-testning, men det är viktigt att se till att hela teamet förstår vilka automatiseringsverktyg du använder och hur de ska användas.
Olika verktyg lämpar sig för olika typer av testning, så det är viktigt att välja automatiseringsverktyg som lämpar sig för white box-testning och lära sig att använda deras funktioner på rätt sätt.
Vissa verktyg integrerar till exempel inte automatisering och fokuserar istället på informationsinsamling och ärendeorganisation, vilket är långt ifrån idealiskt för automatiserad testning. Däremot täcker fullstack-verktyg som ZAPTEST hela testprocessen med hjälp av funktioner som Any Task Automation, vilket gör dem lämpliga för effektivare testning av vita lådor.
7. Inte samarbeta med QA-teamet
Bara för att white box-testning planeras och utförs av utvecklare betyder det inte att QA-teamet inte bör vara involverat på något sätt.
Det är viktigt att resultaten av white box-testningen förmedlas till QA-teamet så att de förstår vad som har testats hittills och hur resultaten av white box-testningen kan påverka hur QA-teamet går till väga vid black box-testningen.
Genom att inte involvera QA-teamet skapar du en potentiell brist på kontakt mellan olika avdelningar, vilket leder till dålig kommunikation och sämre återkoppling senare under testningen. Slutresultatet av detta är en betydligt lägre kvalitet på slutprodukten.
Typer av resultat från tester i vita lådor
När du utför white box-testning av programvara får du olika utdata beroende på resultaten av de tester som du utför. Om du förstår dessa resultat från white box-testerna kan det hjälpa dig att förstå vilka steg du ska ta härnäst.
1. Testresultat
Testresultaten av dina white box-tester visar om du behöver fortsätta med ytterligare tester, om det finns fel som måste åtgärdas och om varje enskilt testfall har godkänts eller misslyckats. Noggrann dokumentation är nödvändig eftersom den hjälper utvecklare och testare att förstå resultaten av white box-testningen.
2. Brister
Brister kan identifieras i white box-testning, och ibland kommer resultatet av dina white box-testningar att vara brister och buggar.
Om programvarusystemet inte beter sig som du förväntar dig under testningen av den vita lådan kan det tyda på att det finns allvarliga fel i programmet som måste åtgärdas innan utvecklingen och testningen fortsätter.
3. Testrapporter
Testrapporter är rapporter som sammanställs av utvecklare och testare under och efter testning av programvara.
De innehåller detaljer om testresultaten, inklusive vilka testfall som klarade och misslyckades, eventuella fel som upptäcktes under testningen och rekommendationer för nästa steg.
Utvecklare använder testrapporter för att kommunicera med andra utvecklare som kan ha till uppgift att åtgärda fel som upptäcks under testningen.
Exempel på tester i vita lådor
Testning i vit ruta gör det möjligt för utvecklare att kontrollera att programvarusystemets interna struktur fungerar som den ska, oavsett systemets externa resultat och utdata.
Exemplen nedan illustrerar hur testning i vit låda kan hjälpa utvecklare att verifiera programvarans interna funktioner.
1. Exempel på registreringssida för e-handel
Ett exempel på testning i vita lådor är hur utvecklare testar funktioner på webbplatser. Om du försöker testa registreringssidan på en e-handelswebbplats kan testning i vit låda göra det möjligt för utvecklare att förstå om de funktioner och klasser som är involverade i registreringen fungerar som de ska när registreringsfunktionen utförs.
Detta inkluderar all information som användaren anger och bedömer parametrarna bakom formuläret, inklusive vilka datum som är giltiga och vilka som inte är det och vad formuläret ser som en legitim e-postadress.
Laget går sedan in i en serie strängar som testar formuläret, där vissa är utformade för att misslyckas och andra för att lyckas, innan resultaten bedöms i förhållande till de förutspådda resultaten.
Black box-testning å andra sidan kontrollerar bara om sidan i sig fungerar, utan någon ytterligare analys av varför eller hur.
2. Exempel på en miniräknare
Applikationskalkylatorer är ett annat exempel på testning i vit låda.
Om du skapar en miniräknare som används som en del av ett program, testar testarna i svart låda helt enkelt om utmatningen av miniräknaren är korrekt när du använder den på avsett sätt.
White box-testare kontrollerar kalkylatorns interna beräkningar för att verifiera hur resultatet har beräknats och om det är korrekt. Detta är mer användbart för mer komplexa beräkningar med flera steg, t.ex. skatter. Testare undersöker koden för att se vilka steg som kalkylatorn tar och i vilken ordning stegen är, innan de ser resultatet efter varje steg.
Om inmatningen i kalkylatorn är (7*4) – 6 och utmatningen är 22, är detta korrekt, och black box-testning skulle klara testet. Detta beror dock på att 7*4 = 28, och 28 – 6 är 22. Testning i vit låda kan avslöja att programvaran har kommit fram till detta resultat genom att utföra 7*4 = 32 och 32 – 6 = 22, vilket inte är korrekt.
Denna större insikt visar att beräkningen är korrekt efter varje specifikt steg, hittar det steg där den kanske inte är korrekt och löser problemet snabbare eftersom testaren tydligt kan se var problemet uppstår.
Typer av fel och buggar vid testning av vita lådor
Under white box-testning är det möjligt att identifiera och lokalisera fel som kan påverka hur systemen fungerar under huven. Dessa fel kan påverka externa funktioner eller påverka prestanda eller tillförlitlighet.
Några av de vanligaste typerna av fel och buggar som uppstår under white box-testning listas nedan.
1. Logiska fel
Logiska fel uppstår i white box-testning eftersom white box-testning visar på områden där programmet inte fungerar logiskt eller där funktioner och villkor missbrukas i programkoden.
Logiska fel kan uppträda som systemfel eller helt enkelt resultera i oväntade beteenden och resultat.
2. Konstruktionsfel
White box-testning kan hjälpa utvecklare att identifiera konstruktionsfel i koden. Konstruktionsfel uppstår när det finns en skillnad mellan det logiska flödet i programvaran och den faktiska implementeringen av programvaran. De kan leda till oväntade beteenden och fel i prestanda.
3. Typografiska fel
Typografiska fel och syntaxfel är misstag som uppstår på grund av mänskliga fel – till exempel för att en utvecklare har skrivit fel på en viss fras eller lagt till fel interpunktion i en kodrad. Små fel som detta kan leda till trasiga funktioner och uttalanden som programvaran inte kan läsa, vilket kan orsaka större fel i systemet.
Vanliga mätvärden för testning av vita lådor
När du utför white box-testning kan vanliga testmått hjälpa dig att mäta hur framgångsrika och omfattande dina white box-test är samt förstå kvaliteten på dina utvecklares arbete.
Testningsmätningar ger information om utvecklingsprocessen eftersom de kan identifiera områden som behöver förbättras eller vägleda testningsprocessen framåt.
1. Kodtäckning
En av de viktigaste egenskaperna hos white box-testning är att den ska täcka så mycket av koden som möjligt, och du kan mäta hur mycket kod du har täckt med hjälp av kodtäckningsmått.
Mätvärden för kodtäckning visar hur stor del av applikationens totala kod du har verifierat med hjälp av white box-testning. Generellt sett strävar utvecklare efter att täcka så nära 100 % av programkoden som möjligt genom white box-testning.
Kodtäckning kan delas upp i olika mätvärden, bland annat för sökväg, segment, uttalande och grenar.
Compound condition coverage är en annan typ av kodtäckningsmått som kontrollerar att varje villkor i en uppsättning har kontrollerats längs flera vägar och kombinationer av vägar.
2. Mätning av fel
Defektmått återspeglar hur många defekter som har hittats, hur bra din white box-testning är på att identifiera defekter och hur stor andel av koden som klarar eller inte klarar white box-testningen.
Felmätningar kan presenteras som antalet fel per tusen rader kod eller antalet totala fel i programmet. Även om ett lågt antal fel kan verka positivt måste utvecklarna se till att det inte beror på att fel missas i testningen.
3. Genomförande av testet
Metriker för testutförande kan hjälpa utvecklare att snabbt se hur stor andel av de totala testerna som har utförts hittills och hur många tester som inte har utförts. Mätvärden för textutförande hjälper programvaruteam att förstå hur långt framskridet testningen av white box-testningen är och om automatiserade programvarutest körs som förväntat eller inte.
Det är dock möjligt att få både falska positiva och falska negativa resultat, vilket kan påverka noggrannheten hos detta mått.
4. Testets varaktighet
Mätvärden för testlängd visar hur lång tid det tar att köra automatiserade tester, vilket är särskilt viktigt vid white box-testning eftersom automatisering är viktigt för att maximera testets effektivitet och testtäckning.
Testens längd är ofta en flaskhals i agil mjukvaruutveckling, så att förstå hur lång tid det tar att köra mjukvarutester kan hjälpa utvecklingsteamen att påskynda utvecklingsprocessen.
Det är dock viktigt att komma ihåg att mätningar av testens varaktighet inte säger något om kvaliteten på de tester du kör.
Verktyg för testning i vit låda
Verktyg och teknik kan göra white box-testerna betydligt mer exakta, effektiva och omfattande. Verktyg för testning av vita lådor kan hjälpa mjukvaruingenjörer att automatisera testning av vita lådor, registrera och dokumentera testningsprocessen för vita lådor och hantera testning av vita lådor från början till slut.
De 5 bästa gratis verktygen för white box-testning
Om du inte vill investera i dyra testverktyg för white box-testning än så länge kan du prova en mängd gratis testverktyg för white box-testning på nätet utan att betala något.
Gratis testverktyg erbjuder inte alltid samma funktionalitet som företagsverktyg, men de är en bra utgångspunkt för nybörjare inom white box-testning och de kan hjälpa utvecklingsteam att få en bättre förståelse för vilka verktyg och tekniker de behöver.
1. ZAPTEST FREE edition
ZAPTEST är ett verktyg för programvarutestning och en programvara för automatisering av robotprocesser som gör det möjligt för utvecklare och QA-testare att automatisera både white box-testning och black box-testning.
ZAPTEST:s gratisversion tillåter flera virtuella användare, flera iterationer och stöd för användarforum. Programmet fungerar med både lokala och externa datakällor och integreras med HP ALM, Rally och JIRA. Användare som gillar ZAPTEST:s gratiserbjudande och vill se mer av vad företaget erbjuder kan också fråga om de vill uppgradera till företagsutgåvan när den är klar.
2. Bugzilla
Bugzilla är ett mycket populärt testverktyg med öppen källkod som gör det möjligt för utvecklare att spåra fel och brister i programvaran och hantera felens livscykel.
Bugzilla gör det enkelt att tilldela fel till utvecklare, prioritera och verifiera fel och stänga dem när de är åtgärdade. Bugzilla är ett utmärkt verktyg för team som fortfarande försöker standardisera sin strategi för felrapportering och det är helt gratis att använda.
3. OpenGrok
OpenGrok är en öppen källkodsbrowser och sökmotor för koddatabas. Det är kompatibelt med kod skriven i Java C++, JavaScript och Python samt andra programmeringsspråk.
Om du vill kunna navigera snabbt i en stor kodbas under white box-testning är OpenGrok helt gratis och lätt att använda.
4. SQLmap
SQLmap är ett annat verktyg med öppen källkod som anses vara nästan oumbärligt vid testning av vitrinskåp. SQLmap reglerar hur man utnyttjar och upptäcker SQL-injektionsfel.
SQLmap är ett självskrivet verktyg för penetrationstestning och kan hjälpa testare att identifiera och lokalisera säkerhetsfel i källkoden och åtgärda dem innan de går vidare.
5. Emma
Emma är en verktygslåda med öppen källkod som kan mäta din kodtäckning om du arbetar i Java. Det är ett mycket snabbt sätt att snabbt fastställa din kodtäckning och att hålla reda på hur mycket kod varje medlem av utvecklingsteamet har täckt på individuell basis.
Emma stöder klass-, metod-, linje- och grundläggande blocktäckning och är helt Java-baserad.
5 bästa verktyg för testning av vit låda för företag
Om du letar efter verktyg som erbjuder större funktionalitet eller bättre support kan testverktyg för företag vara bättre lämpade för ditt utvecklingsteam.
1. ZAPTEST ENTERPRISE utgåva
ZAPTEST:s företagsutgåva är en förstärkt version av den kostnadsfria ZAPTEST-versionen. I den här versionen kan användarna dra nytta av obegränsat antal OCR-mallar, obegränsat antal iterationer och obegränsat antal VBScript- och JavaScript-skript.
ZAPTEST:s företagsutgåva erbjuder en mer komplett uppsättning verktyg för utvecklingsteam som vill övergå till automatisering, och företagsversionen levereras också med expertstöd för att se till att ditt team får ut det mesta av ZAPTEST:s automatisering av programvarutestning och RPA-teknik.
2. Fiddler
Fiddler är en uppsättning verktyg från Telerik som är gjorda för att testa webbapplikationer. Fiddler kan logga all HTTP-trafik mellan ditt system och internet och utvärdera inställda brytpunkter samt justera utgående och inkommande data. Den finns i olika format beroende på din budget och dina krav, så det finns en Fiddler-utgåva för nästan alla team.
3. HP förstärka
HP Fortify, tidigare känt som Fortify, är ett annat verktyg för säkerhetstestning som erbjuder omfattande säkerhetslösningar för white box-testning. Fortify-verktygssviten innehåller verktyget Fortify Source Code Analysis, som automatiskt skannar din källkod efter sårbarheter som kan göra din applikation öppen för cyberattacker.
4. ABAP-enhet
Med ABAP Unit i företagsversionen kan programvaruutvecklare snabbt och enkelt utföra både manuella och automatiserade enhetstester. Utvecklare skriver enhetstester i ABAP-applikationen och använder dessa tester för att verifiera kodfunktioner och identifiera fel i enhetstesterna.
Programvaruteam som vill prova det här verktyget kan börja med gratisversionen av ABAP Unit innan de går vidare till företagsutgåvan.
5. LDRA
LDRA är en egenutvecklad uppsättning verktyg som kan användas för täckning av uttalanden, grenar och beslut när man utför testning i vit låda. Det är ett utmärkt verktyg om du vill kontrollera att din källkod uppfyller standardkraven för efterlevnad, spårning och kodhygien.
När ska du använda enterprise
vs freemium white box testverktyg?
Både testverktyg för företag och gratisverktyg har sin plats i alla moderna programvaruutvecklingsteam. När ditt team växer och automatiserad testning blir allt viktigare för din testmetod, kommer du troligen att vilja uppgradera från att i första hand arbeta med gratis testverktyg till att arbeta med företagsverktyg som erbjuder mer funktionalitet och obegränsad användning.
Det finns dock specifika scenarier där freemium-verktyg kan vara lämpligare än företagsverktyg.
Många utvecklare väljer att börja med freemium-verktyg när de experimenterar med nya funktioner och tekniker, främst för att utvärdera om dessa tekniker passar deras team innan de investerar i företagsteknik.
Du kan också prova gratisversioner av företagsverktyg som ZAPTEST, så att du kan prova dem innan du köper dem och få reda på mer om vad företagsverktygen erbjuder.
Slutligen finns det gratisverktyg som Emma och Bugzilla som specialiserar sig på nischade men viktiga funktioner som ger fortlöpande fördelar även för programvaruteam som är beredda att betala för företagsteknik.
Testning av vita lådor: checklista, tips och tricks
När du är redo att utföra white box-testning ska du se till att du har allt du behöver innan du börjar. Nedan finns en lista över saker du bör komma ihåg innan du börjar testa white box för att maximera testtäckningen och förbättra noggrannheten i dina testresultat.
1. Använd automatiseringsverktyg
Automatiseringsverktyg kan avsevärt påskynda processen för att utföra white box-testning, minska felprocenten och öka den totala noggrannheten.
Nästan alla programvaruteam använder idag någon form av automatisering för att utföra white box-testning, så om du experimenterar med olika automatiseringsverktyg och tekniker innan du börjar med white box-testning kan det hjälpa dig att välja de verktyg du vill använda innan testningen börjar.
2. Sträva efter 100 % testtäckning
Du kommer förmodligen inte att nå ditt mål om 100 % testtäckning, men det är bäst att försöka komma så nära denna siffra som möjligt när du utför white box-testning.
Använd testtäckningsverktyg för att spåra och mäta enskilda mätvärden som t.ex. täckning av vägar och grenar och se till att alla de viktigaste vägarna och grenarna i programvaran har täckts under white box-testning.
3. Utarbeta tydliga testrapporter.
Precis som med andra former av programvarutestning bör du se till att ditt team vet hur man sammanställer korrekta och tydliga testrapporter efter varje testfas.
En testrapport bör vara skriven i ett lättförståeligt format och innehålla detaljer om testmetoden samt en sammanfattning av utdata och resultat för varje testfall som utförts. Slutrapporten ska motivera de åtgärder som vidtagits och innehålla rekommendationer för nästa steg.
4. Mät dina framgångar med testningsmätningar
Testningsmått hjälper programvaruteam att spåra och registrera framstegen i testningen av white box-testning och ger värdefull information som kan användas i framtida utvecklingsprocesser.
Det är viktigt att utvecklare använder mätvärden för att förstå hur effektiv testningen de utför och hur ren deras ursprungliga kod var, så att de kan förbättra sitt arbete i framtiden.
Testning i vit låda:
Slutsats
White box-testning inom programvaruteknik är en viktig typ av programvarutestning som verifierar den interna strukturen och logiken i källkoden för en programvaruapplikation.
I samband med black box-testning säkerställer white box-testning inte bara att programvaran fungerar som förväntat utan också att den interna koden är logisk, ren och fullständig.
White box-testning utförs oftast i samband med enhetstestning och integrationstestning och utförs alltid av utvecklare och programvaruingenjörer med fullständig kunskap om programvarans interna kod.
Även om en del testning av vita lådor kan utföras manuellt, automatiseras idag mycket av testningen av vita lådor på grund av de förbättringar i hastighet, effektivitet och täckning som automatiseringen av testning av vita lådor erbjuder.
Vanliga frågor och resurser
Om du vill lära dig mer om white box-testning finns det många kostnadsfria resurser på nätet som du kan använda. Du kan använda videor, böcker och andra resurser för att lära dig själv hur du utför white box-testning och se till att dina standarder för white box-testning följer bästa praxis.
1. De bästa kurserna om automatisering av tester i vita lådor
Om du vill lära dig mer om automatisering av testning i vit låda kan du gå en kurs i programvarutestning och testning i vit låda. Vissa av dessa kurser är ackrediterade och ger formella kvalifikationer, medan andra är informella onlinekurser som är utformade för att hjälpa utvecklare och testare som vill förbättra sina kunskaper i ett visst ämne.
Några av de bästa kurserna i testning av vita lådor som finns tillgängliga online idag är bland annat:
2. Vilka är de fem vanligaste intervjufrågorna om white box test automation?
Om du förbereder dig för en intervju där du kan komma att diskutera white box-testning, white box-tekniker och automatiseringsverktyg är det viktigt att du vet.
- Vad är skillnaden mellan white box testing och black box testing?
- Varför är det viktigt med testning i vit låda?
- Vilka är de olika tillvägagångssätten som du kan använda dig av för att testa white box-testning?
- Vilka processer ingår i white box-testning och hur kan vi förbättra dem?
- Vilka verktyg och tekniker kan du använda för att göra white box-testning snabbare eller mer exakt?
3. De bästa YouTube-handledningarna om white box-testning
Om du vill lära dig mer om white box-testning kan YouTube-tutorials hjälpa dig att förstå hur white box-testning fungerar och att se visuella förklaringar av de processer och tillvägagångssätt som ingår i white box-testning.
Några av de mest informativa YouTube-handledningarna på nätet är:
- Udacity: White Box Testing Exempel
- Guru99: Vad är White Box Testing?
- Testning i vit låda och testning i svart låda
- Tekniker för testning av vita lådor
- Mentor för programvarutestning: Vad är White Box Testing?
4. Hur man upprätthåller tester i vit låda
Underhåll av programvarutester säkerställer att de tester du utför gång efter gång är grundliga och lämpliga för ändamålet. Det är viktigt att upprätthålla alla typer av programvarutester i både blackbox- och whitebox-testning eftersom koden som du testar ständigt förändras med varje felrättning och iteration. Detta innebär att dina testskript måste ändras i takt med detta.
Att upprätthålla white box-tester innebär att hålla din ram för automatiserad testning uppdaterad och att tillämpa processer som är utformade för att se till att tester och testfall uppdateras regelbundet.
Du kan göra detta genom att:
Inbygga underhåll i testdesignen:
Om du tänker på framtiden för white box-testning när du först bygger och utformar dina white box-test kommer det att bli lättare att underhålla testerna i framtiden.
Gör det möjligt att skapa tydlig kommunikation mellan grupperna:
Se till att alla medlemmar i utvecklingsteamet har flera kommunikationskanaler så att ändringar i koden snabbt kan återspeglas i testerna.
Var anpassningsbar:
Ibland kan det hända att du gör ändringar i koden som du inte har planerat för. Se till att ditt team vet hur man snabbt anpassar sig till dessa förändringar och har kompetens att följa upp dessa förändringar i testerna.
Ständigt omvärdera testprotokollen:
De testprotokoll som du införde i början av testningen kanske inte är lämpliga när programvaran har genomgått olika ändringar och förbättringar. Utvärdera dina testprotokoll regelbundet för att kontrollera om de fortfarande passar bra.
5. De bästa böckerna om testning i vit låda
Testning av vita lådor är ett djupt ämne som det kan ta flera år att behärska. Om du vill bli expert på modern white box-testning inom programvarutestning kan du läsa böcker om white box-testning skrivna av utvecklare, akademiker och ingenjörer.
Några av de bästa böckerna om testning i vita lådor och testautomatisering idag är bland annat:
- The Art of Software Testing, tredje upplagan av Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas
- Programvarutestning: A Craftsman’s Approach, Fourth Edition, av Paul C. Jorgensen
- Hur man bryter sönder programvara: A Practical Guide to Testing av James Whittaker
- Just Enough Software Test Automation av Dan Mosley och Bruce Posey
Du bör kunna hitta dessa böcker i vissa bokhandlar och bibliotek samt på nätet. Du kan också hitta annat läsmaterial och andra lärresurser i läslistorna för bra kurser och program för programvarutestning.
