White box er en kategori af softwaretestning, der henviser til testmetoder for, hvordan softwarens interne struktur og design fungerer. Det står i kontrast til black box-testning, som er testning, der ikke beskæftiger sig med softwarens interne operationer, men i stedet kun tester softwarens eksterne output.
I denne artikel udforsker vi emnet white box-testning: hvad det er, hvordan det fungerer, og hvilke typer værktøjer til softwaretestning der kan hjælpe testere og udviklere med at udføre white box-testning i forbindelse med softwaretestning.
Hvad er white box-testning?
White box-testning er en softwaretestteknik, der indebærer test af den interne struktur og design af en softwareopbygning i modsætning til de eksterne output eller slutbrugeroplevelsen, som testes i black box-testning.
White box-testning er et paraplybegreb, der omfatter mange forskellige typer af softwaretestning, herunder enhedstestning og integrationstestning. Da white box-testning indebærer test af kode og programmering, kræver det normalt en vis forståelse af computerprogrammering at udføre white box-testning.
White box-testning inden for softwareudvikling kan omfatte test af softwares kode og interne design for at verificere input-output flowet og kontrollere softwarens design, brugervenlighed og sikkerhed.
White box-testning giver testerne mulighed for at inspicere systemets indre funktioner samtidig med, at de kontrollerer, at input resulterer i specifikke, forventede output.
White box-testning er et vigtigt skridt i softwaretestning, fordi det er den eneste type test, der tager hensyn til, hvordan selve koden fungerer.
1. Hvornår og hvorfor har du brug for white box
testning inden for softwaretestning og -udvikling?
White box-testning kan udføres i forskellige faser af testcyklussen for at verificere funktionen af intern kode og struktur.
White box-testning forekommer oftest, når udviklere og testere udfører enhedstest og nogle gange under integrationstestning.
Enhedstest betragtes pr. definition som en form for white box-testning, mens integrationstest kan dele træk fra både white og black box-testning, men anses generelt for at være en form for black box-testning.
Ellers kan white box-testning også bruges ad hoc til at verificere den interne funktion af et software build. White box-testning er den mest økonomiske måde at øge testdækningen på, hvis der er behov for det, og det er også en nem måde at verificere, hvordan specifikke sektioner af kode fungerer, eller teste områder af et software build, som testerne har mistanke om ikke er tilstrækkeligt testet.
Formelle kodegennemgange, som udføres sammen med white box-test, kan også bruges til at identificere sikkerhedsfejl og andre sårbarheder. På samme måde kan white box-testning hjælpe softwareingeniører med at finde ud af, hvor fejlen er, hvis dele af koden er defekt.
2. Når du ikke har brug for at lave white box-test
I de fleste tilfælde, når softwareingeniører og testere tester et nyt software build gennem testcyklussen, er det nødvendigt at foretage en vis mængde white box-test for at verificere kodens interne funktioner.
Enhedstest er en type white box-test, som udviklere udfører for at kontrollere, at de enkelte enheder fungerer som forventet. Denne tidlige form for testning gør det muligt for udviklere at identificere fejl og mangler, før der foretages formel testning i et QA-miljø.
Efter enhedsafprøvning finder integrationstest, systemtest og brugeraccept test sted. Disse anses generelt for at være former for black box-testning, som normalt ikke involverer en masse white box-testteknikker.
I nogle tilfælde kan testere og udviklere dog bruge white box-testning i disse faser for at identificere specifikke fejl i koden. Hvis der på dette tidspunkt ikke er noget, der tyder på, at der er noget galt med koden, og hvis alle black box-testene er bestået, vil mange testteams måske mene, at der ikke er behov for at udføre yderligere white box-test.
3. Hvem er involveret i white box-testning?
White box-testning udføres næsten altid af softwareudviklere og softwareingeniører. Det skyldes, at white box-testning kræver detaljeret viden om computerkode og kodningsteknikker, og de fleste QA-testere mangler de tekniske færdigheder, der kræves for at udføre white box-testning.
Unit-test, den primære type white box-test, udføres altid i udviklingsmiljøet af udviklere. Udviklere kan også udføre white box-test, når det er nødvendigt, for at verificere den måde, forskellige elementer i koden fungerer på, eller for at kontrollere, at fejl er blevet rettet korrekt.
Fordelene ved white box-testning
White box-testning giver udviklere og softwareingeniører mulighed for at teste flere aspekter af koden end black box-testning.
Mens black box-testning kan fortælle os, hvordan en softwareopbygning fungerer for slutbrugerne, kan white box-testning fortælle os mere om, hvordan softwarekoden fungerer. Ren og effektiv kode er afgørende i softwareudvikling, især hvis udviklerne ønsker at genbruge koden senere eller tilføje patches og opgraderinger i fremtiden.
1. Maksimer testdækningen
White box-testning kan hjælpe testerne med at maksimere testdækningen. Ved at teste så meget af softwarekoden som muligt er der normalt størst chance for at opdage eventuelle fejl eller fejl i koden, og formålet med white box-testning er normalt at teste så meget af koden som muligt.
Black box-testning handler på den anden side blot om at udføre testcases, som måske eller måske ikke giver en bred kodedækning.
2. Find skjulte fejl og fejl
En af de største fordele ved white box-testning er, at fordi white box-testning verificerer intern funktionalitet, gør det lettere for udviklere at finde fejl og mangler, som ellers ville være skjult dybt inde i koden.
Ud over at identificere tilstedeværelsen af fejl er det normalt nemmere at finde præcis, hvor i kodebasen en fejl er, når man udfører white box-testning på grund af den meget specifikke karakter af denne type testteknik.
3. Lethed til automatisering
Det er meget nemt at automatisere white box-testning, især når du udfører enhedstest. Enhedstests kræver normalt, at udviklere tester små stykker kode enkeltvis for at se, om de kører som forventet. Det er meget nemt at automatisere, hvilket betyder, at det er en hurtig og effektiv form for softwaretestning.
Dette er en af grundene til, at enhedstestning udføres før andre, mere tidskrævende testtyper.
4. Tidseffektivitet
White box-testning er tidseffektiv af flere grunde.
Som nævnt ovenfor er det relativt nemt at automatisere de fleste typer white box-test, hvilket betyder, at det ofte er hurtigere at udføre white box-test end black box-test. White box-testning gør det desuden nemt for udviklere at finde de fejl og fejl, som de identificerer i koden, fordi de finder dem, mens de tester selve koden.
5. Kodekvalitet
White box-testning giver udviklere mulighed for at tage et andet kig på den kode, de har skrevet, og vurdere dens kvalitet og renhed.
Ved at gennemgå kode stykke for stykke får udviklerne mulighed for at fjerne unødvendige kodedele og rydde op i koden, hvilket gør det lettere at genbruge og redigere kodedele i fremtiden.
Det kan også tvinge udviklere til at overveje, hvordan koden implementeres, og om den vil kunne skaleres i fremtiden.
Udfordringerne ved white box-testning
White box-testning er ikke uden udfordringer. Der er et par grunde til, at nogle udviklingsteams kan finde white box-testning vanskeligere at udføre end black box-testning, og der er også andre grunde til, at nogle mennesker anser det for mindre vigtigt end black box-testning.
1. Tekniske hindringer
White box-testning indebærer tekniske barrierer, som black box-testning ikke gør. For at udføre white box-test kræver testere viden om systemets indre funktioner, hvilket i softwaretestning normalt betyder kendskab til programmering.
Derfor udføres white box-test næsten altid af softwareingeniører og udviklere og ikke af QA-testere, som sjældent har de tekniske færdigheder, der er nødvendige for at udføre denne type test.
2. Omkostninger
White box-testning kan være dyrere at udføre end black box-testning, fordi denne type testning er så grundig.
Udviklerne skal bruge meget tid på at skrive intensive enhedstests, og white box-tests kan ofte ikke genbruges til andre applikationer, hvilket betyder, at white box-tests normalt koster ret meget at udføre.
3. Nøjagtighed
White box-testning er ikke altid den mest præcise metode til softwaretestning, og hvis udviklingsteams udelukkende baserede sig på white box-testning, ville det resultere i en masse overset fejl og mangler.
White box-testning validerer kun funktioner, der allerede findes, mens black box-testning kan bruges til at teste delvist implementerede funktioner eller til at identificere funktioner, der faktisk mangler i softwaren og bør inkluderes i senere iterationer.
4. Anvendelsesområde
White box-testning fortæller normalt ikke meget om brugeroplevelsen eller slutresultatet af de funktioner, der er indbygget i softwaren.
Selv om udviklere kan bruge white box-test til at kontrollere, om koden fungerer, som den skal, kan de ikke konkludere, at koden leverer de korrekte resultater til slutbrugerne uden at kombinere white box-test med black box-test.
Det betyder, at der er begrænsninger i omfanget af white box-testning, og hvor meget den kan fortælle os om software.
Karakteristika for white box-test
White box-testning kan defineres ved hjælp af særlige karakteristika, der adskiller den fra andre former for testning som f.eks. black box- og grey box-testning.
De fleste af disse egenskaber kan betragtes ud fra, hvordan de adskiller sig fra egenskaberne ved black box-testning, og hvordan dette adskiller white box-testning og black box-testning fra hinanden.
1. Vedligeholdbarhed
White box-testning fører til et højere niveau af vedligeholdelsesvenlighed i din kode, hvilket forenkler det arbejde, som dit team skal udføre fremover.
Da der er et konstant øje på koden, og hvad den gør med data, er det langt nemmere at vedligeholde den, da du forstår, hvor der opstår problemer, og hvorfor de opstår. Dette gør også koden enklere for fremtidige opdateringer, da du ikke behøver at udvikle store og komplekse patches for ukendte og enkle problemer.
2. Fleksibilitet
White box-testning finder sted på kode, der er fleksibel nok til at acceptere ændringer relativt hurtigt. Ufleksibel kode, som f.eks. kode, der er en del af et modul eller en integration fra en tredjepart, forhindrer en white box-tester i at foretage hurtige ændringer.
Ved at fokusere på at have kode, som du kan ændre, så snart du opdager et problem, er white box-test meget tilpasningsdygtig og betyder, at problemerne i et program løses langt hurtigere.
3. Modularitet
White box-testning trives i kode, der har en vis grad af modularitet, hvilket betyder, at separate elementer af softwaren er klart adskilt fra hinanden.
Hvis et program har et problem med “spaghettikode”, hvor hvert aspekt er bundet til et andet, bliver white box-testning uendeligt meget mere kompleks, da testeren skal undersøge hele programmet i stedet for en specifik enhed.
4. Integration
White box-testning er yderst nyttig til integrationstestning. Testerne kan se, om en funktion fungerer indtil det punkt, hvor den forlader den pågældende software, og om den vender tilbage fra det integrerede system som funktionel som forventet.
Dette er meget informativt og giver en organisation mulighed for at vide, om problemet er lokalt eller en del af den integrerede platform.
Hvad tester vi i white box-test?
White box-tests bruges til at teste funktioner i koden, som ikke kan verificeres ved hjælp af black box-testmetoder. Dette kan betyde at teste, hvordan selve koden fungerer, hvilket giver udviklerne mulighed for at forstå årsag og virkning af forskellige aspekter af koden.
Udviklere bruger white box-testning til at teste sikkerhedshuller, statements og funktioner, output og stier i koden.
1. Interne sikkerhedshuller
White box-testning kan bruges til at finde sikkerhedshuller og sårbarheder i koden, som hackere og cyberkriminelle kan udnytte i fremtiden.
White box-testning kan bruges til at kontrollere, om bedste sikkerhedspraksis er blevet fulgt i udviklingsfasen, og til at lede efter sikkerhedshuller, der kan udbedres, inden koden går videre til yderligere testning.
2. Veje i kodningsprocesser
White box-testning giver udviklere mulighed for at teste de veje, der forbinder forskellige kodeelementer med hinanden. Udviklerne tester ikke kun logikken i koden, men de kan også se på kodestruktur og hygiejne.
God, ren kode har ingen unødvendige linjer eller ødelagte elementer, der ikke fungerer som forventet, selv om de eksterne resultater af black box-testning er som forventet.
3. Forventede resultater
White box-testning kan også teste de forventede output af kode på samme måde som black box-testning, selv om testerne gør det ved at se på koden i stedet for at bruge applikationen, som testerne kan gøre i black box-testning.
Udviklerne tester de forventede output ved at verificere input et efter et og kontrollere, at det resulterende output svarer til forventningerne.
4. Udsagn, objekter og funktioner
Ved at udføre white box-testteknikker kan softwareudviklere sikre, at udsagn, objekter og funktioner i koden opfører sig logisk og resulterer i de forventede resultater.
5. Funktionaliteten af betingede sløjfer
White box-testning kan også bruges til at kontrollere funktionaliteten af betingede loops, herunder enkeltstående, sammenkædede og indlejrede loops. Udviklerne skal kontrollere, om disse loops er effektive, om de opfylder kravene til betinget logik, og om de håndterer lokale og globale variabler korrekt.
Jeg rydder lidt op i forvirringen:
White box vs. Black box vs. Grey box-testning
White box-test, black box-test og grey box-test er udtryk, som softwaretestere bruger til at referere til forskellige testkategorier eller forskellige testmetoder.
En moderne opfattelse af disse testforskelle er, at grænserne mellem de forskellige typer af bokstest bliver mere og mere udviskede, da forskellige testtyper ofte kombinerer elementer af både white og black box-test og udleder test fra dokumenter på forskellige abstraktionsniveauer.
Der er dog stadig vigtige forskelle mellem disse testformer.
1. Hvad er black box test?
Black box-testning er en form for softwaretestning, hvor softwarens funktionalitet kontrolleres af testere, som ikke har kendskab til kodens interne struktur eller til, hvordan koden implementeres på et mere teknisk niveau.
Black box-testning tester kun de eksterne output af softwaren, eller med andre ord, den tester det, som slutbrugeren vil opleve, når softwaren anvendes.
Black box-testning er også kendt som adfærdstestning, fordi den tester, hvordan softwaren opfører sig under visse betingelser.
Testerne kan bruge black box-testning til at vurdere, hvordan forskellige funktioner i softwaren opfører sig, og kontrollere disse funktioner i forhold til forventningerne for at sikre, at softwaren opfylder brugernes krav. Black box-testning bruges i systemtestning og accepttestning til at verificere forskellige funktioner og kontrollere, at systemet fungerer som forventet, når det fungerer som en helhed.
Ved black box-testning skriver brugerne testcases for at verificere forskellige elementer enkeltvis. Da black box-testning ikke kræver de samme tekniske færdigheder som white box-testning, udføres black box-testning normalt af testere i et QA-miljø snarere end af udviklere.
Det er normalt lettere at automatisere black box-testning sammenlignet med white box-testning ved hjælp af end-to-end automatiseringsværktøjer som ZAPTEST.
Hvad er forskellene mellem white box- og black box-testning?
Den primære forskel mellem black box- og white box-testning er, hvad der testes.
Black box-testning handler om at teste de eksterne output af softwarebygningen, mens white box-testning handler om at teste det, der foregår under motorhjelmen.
Nogle af de primære forskelle mellem black box- og white box-testning er:
Formål
Formålet med black box-testning er at verificere, at systemet fungerer som forventet for slutbrugeren, mens formålet med white box-testning er at kontrollere kvaliteten og integriteten af softwarens kode.
For eksempel kan black box-testning af et videospil betyde, at en slutbruger prøver spillet og vurderer det for deres oplevelse, mens white box-testning af det samme projekt sikrer, at indtastning af specifikke input fører til, at karakteren udfører den rigtige handling.
Proces
De processer, der anvendes i white og black box test, er meget forskellige. White box-testning er meget lettere at automatisere end black box-testning, og normalt skal black box-testning automatiseres ved hjælp af softwareautomatiseringsværktøjer.
Når man f.eks. tester en database, indebærer en white box-test automatisering af dataindtastning for at kontrollere, at alle resultater er korrekte, mens black box-testning indebærer, at brugere replikerer manuelle processer og rapporterer om dem uden brug af et automatiseringssystem.
Testere
Black box-testning udføres næsten altid i et QA-miljø af professionelle softwaretestere, mens white box-testning udføres af softwareudviklere og ingeniører, som har mere detaljeret teknisk viden om kodekilden.
Teknikker
Black box-testning anvender forskellige teknikker såsom ækvivalenspartitionering, grænseværdianalyse og testning ved hjælp af beslutningstabeller. White box-testning anvender teknikker som beslutningsdækning, betingelsesdækning og statement-dækning.
Operationer
Testmetoderne black box-testning passer til testoperationer på højere niveauer som systemtestning og accepttestning, mens white box-testning er mere egnet til testoperationer på lavere niveauer som enhedstestning og integrationstestning.
Af denne grund udføres white box-testning normalt før de fleste former for black box-testning.
2. Hvad er grey box-testning?
Grå boks-testning er en softwaretestteknik, der bruges til at teste softwareprodukter og applikationer af testere, som måske har delvis viden om applikationens interne struktur, men ikke fuldstændig viden om den.
Grå boks-testning kan kombinere elementer fra både black box-testning og white box-testning for at give udviklere og testere mulighed for at identificere fejl i koden og finde kontekstspecifikke fejl.
Grå boks-testning kombinerer funktioner fra både black box-testning og white box-testning. Testerne skal have en vis viden om systemets interne funktioner som ved white box-testning, men de bruger denne viden til at oprette testcases og udføre disse testcases på funktionsniveau som ved black box-testning.
Grå boks-testning giver mange af fordelene ved både black box- og white box-testning og er samtidig relativt tidseffektiv og fleksibel.
Hvad er forskellene mellem white box- og grey box-testning?
Da grey box-testning tilbyder nogle af de samme funktioner som black box-testning, er der nogle store forskelle mellem grey box-testning og white box-testning, om end måske ikke så mange som med black box-testning.
Nogle af de største forskelle mellem grey box-test og white box-test er:
Strukturel viden
Ved white box-testning skal den person, der udfører testen, have fuldt kendskab til kodens interne design og struktur. Ved grey box-testning er kodens interne struktur normalt kun delvist kendt.
Berørte personer
White box-testning udføres næsten udelukkende af softwareudviklere og softwareingeniører, mens grey box-testning kan udføres af slutbrugere, testere og udviklere.
Effektivitet
White box-testning anses for at være den mest tidskrævende type softwaretestning, mens grey box-testning låner nogle af effektivitetsfordelene ved black box-testning for at reducere den tid, det tager at udføre testene.
Operation
Ved white box-testning skriver udviklere simpelthen kode til at implementere white box-test og kører denne kode. Ved grey box-testning udfører testerne ligesom ved black box-testning funktionelle test for at vurdere, hvordan systemet fungerer udadtil.
Dækning
White box-testning er den mest udtømmende type testning, mens dækningen af grey box-testning kan variere afhængigt af, om den type testcases, der udføres, er baseret på kode eller GUI.
Konklusion:
White box vs. Black box vs. Grey box test
White box-test, black box-test og grey box-test er udtryk for forskellige softwaretestteknikker. Overordnet set kan hver testtype defineres ud fra, i hvilket omfang testerne skal have viden om kodebasen og implementeringen af koden:
1. Black box-testning:
Den interne struktur af koden er ukendt.
2. White box test:
Den interne struktur af koden er kendt.
3. Grå boks test:
Den interne struktur af koden er delvis kendt.
Under softwaretestning er alle tre testtyper vigtige for at verificere softwarens funktion og integritet. Mens white box-testning fortæller os mere om den underliggende struktur i koden, kan grey box-testning og black box-testning verificere, hvordan systemet fungerer, og om det opfylder slutbrugernes krav.
De måske største forskelle mellem disse tre testtyper vedrører hvem der udfører hver testtype, kravene til selve testen og hvad testen indebærer.
White box-testning har den højeste adgangsbarriere, fordi den udføres af udviklere med detaljeret viden om selve kodebasen, og fordi det er den mest tidskrævende og ofte dyreste type testning.
I modsætning hertil er black box-testning den letteste at udføre, og den kan udføres af testere uden kendskab til den underliggende kode.
Typer af white box-test
Der findes mange forskellige typer white box-tests, som hver især kan bruges til at teste lidt forskellige aspekter af kodens interne struktur.
Nedenfor er nogle af de mest almindelige typer af white box-test, der anvendes i dag.
1. Test af stier
Path testing er en type white box-test, der er baseret på et programs kontrolstruktur. Udviklerne bruger kontrolstrukturen til at oprette en kontrolflowdiagram og teste forskellige veje i diagrammet.
Path testing er en type test, der er afhængig af programmets kontrolstruktur, hvilket betyder, at det kræver, at testerne har en grundig forståelse af denne struktur.
Hvis et system f.eks. skal kontakte kunderne med bestemte beskeder på bestemte punkter i salgstrappen, skal det ved hjælp af path testing sikres, at systemet følger de rigtige trin afhængigt af de betingelser, som dataene fastsætter.
2. Test af sløjfe
Loop-testning er en af de vigtigste typer af white box-testning, som tester loops i programmets kode. Loops er implementeret i algoritmer i koden, og ved loop-testning kontrolleres det, om disse loops er gyldige.
Loop-testning kan vurdere, om der findes sårbarheder i specifikke loops, og fremhæve områder, hvor udviklerne muligvis skal rette koden for at sikre, at loopet fungerer, som det skal.
Et eksempel på en loop-test er at følge loopet med et bestemt sæt datapunkter, der får loopet til at fortsætte, f.eks. ved at nægte at acceptere nogle vilkår og betingelser, før man indtaster et tal, der specifikt bryder loopet. Hvis løkken opfører sig som forventet, er testen vellykket.
3. Betinget afprøvning
Betinget testning er en type white box-testning, der kontrollerer, om de logiske betingelser for værdier i koden er sande eller falske.
Betinget testning er en vigtig form for white box-testning, der fortæller udviklerne, om koden er logisk og opfylder kravene til programmeringslogikken.
Et eksempel på betinget testning er inden for en regnskabsplatform. Indtastning af en række udgifter og indtægter bør resultere i de rigtige løbende totaler, og softwaren giver nøjagtige resultater under en vellykket test.
4. Test af enheder
Test af enheder er en vigtig fase i softwaretestning, hvor udviklere tester individuelle komponenter og moduler og kontrollerer, at de fungerer som forventet, før de integrerer forskellige enheder sammen.
Softwareingeniører bruger white box-testmetoder i enhedstest til at teste små stykker kode ad gangen. Det gør det nemt at identificere fejl og mangler, når de opstår under testningen.
Et eksempel på enhedstest er tidligt i udviklingen, når en virksomhed opretter en simpel knap på et websted, som fører brugeren til en anden side. Hvis enheden fungerer som forventet, lykkes den, og udviklerne foretager ændringer, indtil den fungerer som forventet.
5. Mutationsundersøgelse
Mutationstest er en type test, der tester ændringer og mutationer. Ved mutationstest foretager udviklerne små ændringer i kildekoden for at se, om dette kan afsløre fejl i koden.
Hvis testcasen består, tyder det på, at der er et problem med koden, for den burde ikke bestå, efter at ændringerne er blevet foretaget. Ideelt set vil alle testcases fejle ved mutationstestning.
Et eksempel på mutationstest er maskinlæring. Programmer til maskinlæring “muterer” automatisk afhængigt af nye oplysninger, så ved at teste disse programmer konsekvent for standarden for “mutation” kan udviklerne få oplysninger om, hvorvidt softwaren fungerer som forventet.
6. Integrationstest
Integrationstest er en vigtig fase af softwaretestning, hvor testerne undersøger, om forskellige moduler fungerer korrekt, når de er integreret med andre moduler.
White box-testteknikker anvendes under integrationstest for at kontrollere, at koden fungerer, selv når flere moduler – som ofte er kodet af forskellige udviklere – arbejder sammen.
Når en database f.eks. henter oplysninger fra en online kilde, sikrer integrationstest, at de data, den henter, er nøjagtige og opdateres med en rimelig ensartet hastighed.
7. Penetrationstest
Penetrationstest er en type white box-test, der kan bruges til at simulere specifikke cyberangreb på systemet.
Ved penetrationstest får testerne adgang til alle netværks- og systemdata som f.eks. adgangskoder og netværkskort. Derefter forsøger de at få adgang til eller ødelægge data i systemet ved at forsøge så mange forskellige angrebsmuligheder som muligt.
Penetrationstest er et vigtigt aspekt af sikkerhedstest, som bør udføres på alle software builds.
En HR-platform vil f.eks. gennemføre penetrationstest og kigge efter sårbarheder i koden for at sikre, at platformen er sikker nok til at opbevare medarbejderdata.
White box testteknikker
Der findes mange forskellige white box-testteknikker, der kan bruges til at udføre de ovenfor nævnte white box-tests. Som det altid er tilfældet, er forskellige teknikker bedst egnet til at teste forskellige aspekter af koden, men alle de white box-teknikker, der er anført nedenfor, er vigtige.
1. Erklæringens dækning
Et af de definerende træk ved white box-testning er, at testerne skal forsøge at dække så meget af kildekoden som muligt, når de udfører white box-test.
Kodedækning er et godt mål for dette, og statement coverage er en teknik, som white box-testere kan bruge til at øge dækningen af statements i koden.
Statement coverage er et mål, der måler antallet af udførte statements divideret med det samlede antal statements og ganget med 100. White box-testere bør tilstræbe en høj erklæringstæthed.
2. Branchedækning
Branch coverage afspejler ligesom statement coverage, hvor omfattende dækningen af bestemte elementer af koden er i white box testing. Forgreninger svarer til “IF”-udsagn i logik, hvor koden forgrener sig i sande og falske muligheder, som påvirker resultatet af operationen.
Ved brug af branch coverage-teknikker kontrollerer white box-testere, om hver gren er behandlet mindst én gang og bekræfter, at begge grene fungerer korrekt.
3. Stiernes dækning
Ved hjælp af teknikker til dækning af stier vurderes stierne i en softwareapplikation. At maksimere testvejsdækningen betyder at sikre, at alle veje i programmet udforskes mindst én gang. Det er en lignende testteknik som branch coverage, men den anses for at være mere grundig og effektiv.
Path coverage-testning anses normalt for at være mest velegnet til test af komplette applikationer snarere end delvise builds.
4. Afgørelsens dækning
Beslutningsdækning er en af de vigtigste white box-teknikker, fordi den giver data om de sande og falske resultater af boolske udtryk i kildekoden.
Test af beslutningsdækning validerer kildekoden ved at sikre, at hvert mærke af hver potentiel beslutning er blevet gennemgået mindst én gang under testen.
Beslutningspunkter omfatter alle tilfælde, hvor der er mulighed for to eller flere forskellige udfald.
5. Betingelsesdækning
Betingelsesdækning er også kendt som udtryksdækning. Denne white box-teknik evaluerer undervariablerne i betingede udsagn i koden for at verificere resultatet af hver logisk betingelse.
Denne type testning tager kun hensyn til udtryk med logiske operander, hvorimod testning af beslutningsdækning og testning af branchedækning anvendes til at sikre andre logiske operationer.
6. Dækning af flere sygdomme
I tests, der dækker flere betingelser, verificerer testerne forskellige kombinationer af betingelser og evaluerer den beslutning, som koden træffer for hver kombination.
Der kan være mange forskellige testcases for test af flere betingelsers dækning på grund af det enorme antal kombinationer af betingelser, der findes, så denne type test er ofte meget tidskrævende.
7. Dækning af endeløse tilstandsmaskiner
Finite state machine coverage er en vigtig testtype, men også en af de vanskeligste måder at opnå en høj kodedækning i white box-testning på. Den arbejder på designets funktionalitet og kræver, at udviklerne tæller antallet af gange, en tilstand besøges eller gennemløbes i løbet af testprocessen, samt hvor mange sekvenser hvert finite state-system indeholder.
8. Test af kontrolstrømme
Kontrolstrømsafprøvning er en white box-afprøvningsteknik, der søger at fastslå programmets udførelsesrækkefølge ved hjælp af en simpel kontrolstruktur.
Udviklere konstruerer testcases til kontrolflowtestning ved at vælge en specifik del af programmet og opbygge en testvej. Kontrolstrømsafprøvning anvendes normalt i forbindelse med enhedstest.
Livscyklus for white box-testning
inden for softwareudvikling
White box-testning er et vigtigt skridt i softwareudviklingslivscyklussen, selv om det ikke har en bestemt “plads” i cyklussen.
Udviklere kan udføre white box-test, når de har brug for at kontrollere kodens funktion, og nogle udviklere er måske mere grundige end andre med hensyn til at kontrollere nyskrevet kode for at sikre, at den er ren og fri for unødvendige linjer.
White box-testning udføres dog oftest i forbindelse med enhedstestning og integrationstestning. Både enhedstest og integrationstest udføres af udviklerne i udviklingsfasen.
De finder sted før funktionel testning som f.eks. systemtest og accepttestning, og de giver udviklerne mulighed for at identificere, finde og rette større fejl tidligt i testfasen, før produktet overdrages til QA-teamet.
Manuelle eller automatiserede white box-tests?
Ligesom andre typer af softwaretestning er det muligt at automatisere white box-testning. Den kan enten være manuel eller automatiseret, selv om det i de fleste tilfælde er lettere at automatisere white box-testning end black box-testning.
Da white box-testning er en meget tidskrævende type testning, bliver automatisering mere og mere populær blandt softwareteams.
Manuel white box-test: fordele, udfordringer og processer
Manuel white box-testning betyder at udføre white box-tests manuelt, og det kræver, at udviklerne har de nødvendige færdigheder og den fornødne tid til at skrive individuelle testcases for at teste hver eneste linje kode i et software build. Det kan tage meget tid, men det giver også de mest grundige testresultater og resultater.
Nogle af fordelene ved at udføre white box-testning manuelt er bl.a:
1. Dybde
Manuel testning giver testerne mulighed for at udforske softwarekoden i større dybde end automatiseret testning, hvis de ønsker det, f.eks. ved at læse hele kildekoden til et program i stedet for blot at automatisere opgaver, der berører overfladiske funktioner.
2. Fejlplacering
Manuel testning gør det nemt at finde fejl og mangler, fordi udviklerne skal kunne identificere præcis, i hvilken kodelinje fejlen findes.
Hvis du f.eks. ser, at et billede ikke indlæses, og derefter undersøger koden for linjer, der involverer indlæsning af billeder, kan du begrænse årsagen betydeligt.
3. Hastighed
Manuel testning tager normalt længere tid end automatiseret testning, men hvis udviklere kun ønsker at køre en eller to hurtige test, er det sandsynligvis hurtigere at udføre dem manuelt end at oprette automatisering.
Enhedstest indebærer f.eks. at man ser på en funktion og ser, om den fungerer, i stedet for at indsamle store mængder data ved at automatisere processen. Der er dog også ulemper ved manuel white box-testning.
Nogle af udfordringerne ved manuel white box-testning omfatter:
1. Nøjagtighed
Manuel testning kan give udviklere mulighed for at dække en bred vifte af kode, men menneskelige testere er altid mere tilbøjelige til at begå fejl og fejl end computerprogrammer, hvilket betyder, at manuel testning ofte anses for at være mindre præcis end automatiseret testning.
2. Tid
Manuel testning tager længere tid end automatiseret testning, og manuel white box-testning er noget af det mest tidskrævende testarbejde overhovedet. Dette øger gennemløbstiden og kan gøre det sværere at overholde stramme udviklingsfrister.
3. Omkostninger
På grund af den mængde arbejdskraft og ressourcer, der er involveret i manuel white box-testning, er dette ofte dyrere for udviklingsteams end automatiseret testning, som normalt kræver færre udviklere og mindre tid.
4. Skalerbarhed
Manuel testning er egentlig kun egnet til brug ved test af små applikationer eller test af enkelte komponenter i større applikationer. For større applikationer som f.eks. en cloud-hosted database med tusindvis af input pr. minut er automatiseret test meget bedre som en metode til simulering af standardbelastninger.
Automatiseret white box-test: fordele,
udfordringer og processer
Automatiseringsteknologi gør det nemmere at automatisere aspekter af softwaretestning hver dag. Industriens bevægelse i retning af hyperautomatisering skyldes til dels den effektivitet og de omkostningsbesparelser, som automatisering giver udviklingsteams, der altid føler sig pressede.
White box er en af de mest hensigtsmæssige og egnede testtyper til automatisering, fordi den er relativt nem at automatisere, og tidsbesparelserne og omkostningsbesparelserne ved automatisering af white box-test kan være betydelige.
Automatiseret white box-testning kan involvere, at udviklerne selv skriver testskripter, eller processen kan fremskyndes ved hjælp af full-stack-værktøjer som ZAPTEST, der leverer state-of-the-art end-to-end softwaretestteknologi.
Nogle af fordelene ved at automatisere white box-testning er bl.a:
1. Nøjagtighed
Computerbaserede test eliminerer risikoen for fejl, fordi computere ikke bliver trætte eller begår fejl.
2. Tid
Automatiseret white box-testning er betydeligt hurtigere end manuel white box-testning og frigør tid, som udviklerne kan bruge på andre opgaver, f.eks. fejlrettelse eller udarbejdelse af opgraderingspatches.
3. Skala
Automatiseret testning kan skaleres meget bedre end manuel testning, så hvis din softwareapplikation vokser, eller hvis du ønsker at udføre testning i stor skala på én gang, er automatisering den bedre løsning.
For eksempel indebærer en opskalering af dataindtastning, at der skal anmodes om flere input i forbindelse med automatisering i forhold til at ansætte flere medarbejdere i forbindelse med manuelle test.
4. Omkostninger
Omkostningerne ved automatiseret testning er normalt lavere end omkostningerne ved manuel testning på grund af det antal arbejdstimer, der spares ved automatisering. ZAPTEST’s 10x ROI viser, hvordan automatisering kan spare udviklere penge og føre til højere afkast. Automatisering er dog ikke uden ulemper.
Nogle af udfordringerne ved at automatisere white box-testning omfatter:
1. Fejlsporing
Automatisering gør det ikke altid let at finde fejl i koden, afhængigt af hvordan udviklerne automatiserer testene, eller hvilke testværktøjer der anvendes, især sammenlignet med manuel white box-testning, hvor testerne kan se den kode, der køres, når en fejl opstår.
2. Færdigheder
Det er ikke alle udviklere, der ved, hvordan man automatiserer test eller bruger automatiserede testværktøjer, så det kan kræve en vis investering i uddannelse i vigtige færdigheder såsom kodning i den specifikke testplatforms sprog og brug af dataanalysefærdigheder til at forstå årsagen til problemer i en white box-test.
Konklusion: Manuel white box test
eller white box test automatisering?
Samlet set er white box-testning inden for softwareudvikling en af de mest hensigtsmæssige testtyper at tilpasse til automatiseret testning, hovedsagelig på grund af den tidskrævende og komplekse karakter af manuel white box-testning.
Automatiseret white box-testning er hurtigere, billigere, mere effektiv og mere præcis end manuel testning, især når der arbejdes med større applikationer.
Hvor det er muligt, bør softwareudviklere automatisere white box-testning i softwaretestning for at øge testens pålidelighed og dække et større område af større applikationer gennem testning, end det er praktisk muligt, når testene udføres manuelt. Dette skyldes de betydelige omkostninger og den ekspertise, der kræves, når du gennemfører white box-tests udelukkende med manuelle metoder.
Hvad skal du bruge for at komme i gang
white box-testning?
Før du begynder at lave white box-test, skal du sikre dig, at du har alt det, du skal bruge for at komme i gang. Afhængigt af, om du udfører manuel eller automatiseret white box-testning, behøver du ikke mange ressourcer ud over tid og penge.
Du skal dog sikre dig, at dit team har den rette viden og de rette værktøjer til at udføre white box-testning korrekt.
1. En forståelse af kildekoden
White box-testning er testning, som softwareudviklere og ingeniører med fuldt kendskab til kildekoden og softwarens interne struktur udfører.
Hvis du er QA-tester uden denne viden, skal du give softwaren videre til en anden person, før white box-testning kan begynde.
2. Testcases
Det er nødvendigt at skrive testcases, før du udfører white box-testning. Testcases er individuelle sæt af instruktioner, der beskriver handlinger, som testere eller udviklere kan udføre for at teste et systems funktioner og funktion.
Ved white box-testning udformes testcases af personer med fuldstændig viden om systemets interne struktur og oprettes for at verificere, om systemet fungerer, som det skal.
3. White box-testværktøjer
Der findes masser af værktøjer til white box-testning, som understøtter adgang til kildekode og designdokumenter samtidig med at de gennemfører testautomatisering. Disse findes også i forskellige prisklasser for brugerne, f.eks. ZAPTEST FREE- og ZAPTEST ENTERPRISE-versioner, der giver større fleksibilitet.
Vælg de værktøjer, du vil bruge, før du begynder at teste, og læg vægt på at sikre, at de har den rette funktionalitet, f.eks. platformsukoperationer og Computer Vision-teknologi, så du kan se det samme som automatiserede tests.
Sørg for, at alle de udviklere og ingeniører, der er involveret i testningen, ved, hvordan og hvornår de skal bruges.
White box-testprocessen
White box-testning indebærer meget mere viden om systemets funktion end black box-testning, og nogle af trinene i white box-testning er lidt anderledes.
White box-testere skal først identificere de funktioner eller komponenter i systemet, som de ønsker at verificere, før de udstikker mulige testveje og skriver testcases, der skal udføres.
White box-testprocessen kan også variere afhængigt af, hvilken white box-testteknik du bruger. Følg nedenstående trin for at finde ud af, hvordan du udfører white box-testning, samtidig med at du maksimerer stidækningen.
Trin 1: Identificer de funktioner, der skal testes
Før du udfører white box-testning, skal du overveje præcis, hvad du vil teste, og hvordan du vil teste det. Dette indebærer normalt, at man fokuserer på et lille sæt funktioner eller features og opretter et sæt testcases, der kun tester disse.
Du vil udføre dette trin igen og igen for forskellige områder af systemet for at maksimere testdækningen, men det er vigtigt at opdele de forskellige områder i individuelle tests.
Jo mere snævert dit fokus er, jo mere pålidelige og præcise kan dine tests være.
Trin 2: Plot alle mulige stier i en flowgraf
En væsentlig del af dit forberedelsesarbejde til white box-testning er at plotte alle de mulige veje, som du skal teste, i et flowdiagram.
Dette trin kan hjælpe dig med at maksimere stidækningen og sikre, at du verificerer alle mulige stier i hver testcase, som du opretter. Tegn et flowdiagram, der dækker alle mulige stier for hver funktion eller komponent, som du tester, f.eks. ved at skitsere forskellige stier, der opstår, når forskellige værdier indtastes.
Trin 3: Identificer alle mulige stier
Kig på dit flowdiagram og identificer alle de mulige veje, som brugerne kan tage, fra det første trin i flowdiagrammet til det sidste trin.
Jo flere grene og beslutninger der er i dit flowdiagram, jo flere unikke stier vil der være. Hvis du forstår, hvor mange unikke mulige stier der findes, kan du sikre, at dine testcases dækker alle muligheder.
Trin 4: Opret testcases
Den næste fase af white box-testning er at skrive testcases, der verificerer alle de veje, du har identificeret ovenfor.
Det er vigtigt at sikre, at dine testcases dækker alle mulige veje og klart beskriver de handlinger, som testere eller udviklere skal udføre for at udføre hver testcase.
For hver testcase skal du angive et testcase-ID og et navn sammen med en kort beskrivelse og de forventede resultater af hver test.
Trin 5: Udfør testcases
Det er nu tid til at udføre testcases, hvilket er det, som de fleste anser for at være selve white box-testningen.
Testerne udfører testcases ved at følge de korte instruktioner, der er beskrevet i hver testcase, og rapporterer resultatet af hver testcase. Dette kan sammenlignes med de forventede resultater, der er beskrevet i testcasen, for at fastslå, om hver white box-test er bestået eller ikke bestået.
Trin 6: Gentag cyklussen om nødvendigt
Ligesom andre former for softwaretestning handler white box-testning om at sammenligne, hvordan systemet rent faktisk fungerer, med de forventninger, testerne har til, hvordan systemet skal fungere.
Hvis testerne finder ud af, at systemet ikke opfører sig, som de forventer, kan det betyde, at white box-testningen er mislykkedes, og udviklerne skal rette kodelinjerne, før de udfører yderligere testning.
Gentag ovenstående proces for at udføre yderligere white box-testning, indtil systemet er blevet grundigt testet, og eventuelle fejl er blevet rettet.
Bedste praksis for white box-testning
Bedste praksis for white box-testning afhænger af, hvilken type test du udfører, og hvilken fase af testprocessen du befinder dig i.
Da det meste af white box-testningen finder sted under enhedstestning og integrationstestning, gælder de fleste bedste praksis for white box-testning for disse faser.
1. Maksimer testdækningen
Det er pr. definition vigtigt at maksimere testdækningen ved white box-testning for at sikre, at en høj procentdel af softwaren testes i denne fase.
Det kan du gøre ved at maksimere sti- og grendækningen og skrive testcases, der udforsker alle mulige stier og resultater i forberedelsesfasen.
2. Kontroller adfærd og ydeevne
Når du skriver testcases i white box-testning, skal du oprette testcases, der verificerer, at systemet fungerer, som du forventer det, samt testcases, der verificerer systemets ydeevne.
Ud over at kontrollere, at bestemte handlinger fører til bestemte resultater, kan du f.eks. også kontrollere, hvor hurtigt systemet kan udføre bestemte opgaver, eller hvordan ydelsen påvirkes af forskellige variabler.
3. Skriv testcases uafhængigt af hinanden
Hvis du ønsker at verificere to forskellige funktioner, f.eks. hvis en kodeklasse er afhængig af en bestemt database, skal du oprette en abstrakt grænseflade, der afspejler denne databaseforbindelse, og implementere en grænseflade med et mock-objekt til at teste denne forbindelse.
Dette sikrer, at dine testcases verificerer de forbindelser, som du ønsker, at de skal verificere, og ikke noget andet.
4. Dæk alle stier og sløjfer
At maksimere testdækningen betyder at dække alle mulige veje og tage højde for betingede loops og andre typer loops i koden.
Sørg for at designe testcases, der fuldt ud undersøger de mulige veje, og kontroller, at loops opfører sig som forventet, uanset hvad input er.
7 fejl og faldgruber, når du
Gennemførelse af White box-test
Når du begynder white box-testning, er det vigtigt at være opmærksom på nogle af de mest almindelige faldgruber, som udviklere ofte falder i, når de udfører white box-testning. Almindelige fejl ved white box-testning kan forårsage forsinkelser og unøjagtigheder, som kan skade kvaliteten og tidsplanen for softwareudgivelsen.
1. At tro, at white box-test ikke er nødvendigt
Nogle testere mener, at white box-testning ikke er nødvendig, fordi black box-testning tester alle de eksterne output af softwaren, og hvis disse fungerer korrekt, antages det, at systemets interne funktioner også fungerer.
White box-testning kan dog hjælpe udviklere med at finde problemer og fejl, som måske ikke altid dukker op i black box-testning, og det er vigtigt for at verificere softwaresystemers sikkerhed.
Hvis et program f.eks. har en hukommelseslækage, der forårsager ydelsesforringelse i længere perioder, som black box-test ikke kan undersøge, er white box-test den eneste mulighed for at gennemrode koden og finde problemet før en bred offentlig udgivelse.
2. Udførelse af alle white box-tests manuelt
Nogle udviklere tror måske, at det er lige så nemt at udføre white box-testning som black box-testning.
White box-testning er imidlertid betydeligt mere tidskrævende, og udviklere, der forsøger at udføre white box-testning helt manuelt, kan opleve, at det er umuligt at udføre manuelle kontroller efter de ønskede standarder eller samtidig maksimere testdækningen.
3. Tildeling af testere til at udføre testcases
White box-testning bør udføres af udviklere, softwareingeniører og folk, der har fuld forståelse for softwaresystemets indre funktioner.
Nogle udviklere tror, at de kan overlade white box-testning til QA-testerne, når de selv har skrevet testcases, men det vil kun resultere i dårlig udførelse og reducere kvaliteten af dokumentationen.
4. Testning i al hast
Softwaretestning er en lang og tidskrævende proces, og nogle udviklere kan være fristet til at skynde sig gennem white box-testning for at komme videre til næste udviklingsfase. Det er vigtigt at afsætte tilstrækkelig tid og ressourcer til white box-testning for at sikre, at udviklerne ikke føler sig pressede, og at de har tilstrækkelig tid til at maksimere testdækningen.
5. Dårlig dokumentation
Ved at opbevare korrekt dokumentation før, under og efter testning sikrer du, at alle, der er involveret i softwareudvikling og testning, har adgang til de korrekte oplysninger på det rigtige tidspunkt.
Sørg for, at alle medlemmer af udviklingsteamet ved, hvordan man skriver klar dokumentation, og hvordan man rapporterer resultaterne af white box-testning.
6. Ukorrekt brug af automatiseringsværktøjer
Automatiseringsværktøjer kan gøre det nemt at udføre white box-testning, men det er vigtigt at sikre, at hele dit team forstår, hvilke automatiseringsværktøjer du bruger, og hvordan de skal bruges.
Forskellige værktøjer er velegnede til forskellige typer testning, så det er vigtigt at vælge automatiseringsværktøjer, der er velegnede til white box-testning, og lære at bruge deres funktioner korrekt.
Nogle værktøjer integrerer f.eks. ikke automatisering og fokuserer i stedet på informationsindsamling og billetorganisering, hvilket langt fra er ideelt til automatiseret testning. Tværtimod dækker full-stack-værktøjer som ZAPTEST hele testprocessen gennem funktioner som Any Task Automation, hvilket gør dem velegnede til mere effektiv white box-testning.
7. Ikke samarbejde med QA-teamet
Bare fordi white box-testning planlægges og udføres af udviklerne, betyder det ikke, at QA-teamet ikke bør være involveret på nogen måde.
Det er vigtigt at videregive resultaterne af white box-testning til QA-teamet, så de forstår, hvad der er blevet testet indtil videre, og hvordan resultaterne af white box-testning kan påvirke den måde, hvorpå QA-teamet griber black box-testning an.
Ved ikke at inddrage QA-teamet skaber du en potentiel uoverensstemmelse mellem de forskellige afdelinger, hvilket fører til dårlig kommunikation og dårligere feedback senere i testforløbet. Slutproduktet af dette er et betydeligt lavere kvalitetsniveau i det endelige produkt.
Typer af output fra white box-test
Når du udfører white box softwaretest, får du forskellige output afhængigt af resultaterne af de test, du udfører. Hvis du forstår disse resultater fra white box-tests, kan det hjælpe dig med at forstå, hvilke skridt du skal tage som det næste.
1. Testresultater
Testresultaterne af dine white box-tests fortæller dig, om du skal fortsætte med yderligere testning, om der er fejl, der skal rettes, og om hver enkelt testcase er bestået eller ikke bestået. Grundig dokumentation er nødvendig, fordi den hjælper udviklere og testere med at forstå resultaterne af white box-testning.
2. Mangler
Fejl kan identificeres ved white box-testning, og nogle gange vil resultatet af dine white box-test være fejl og mangler.
Hvis softwaresystemet ikke opfører sig som forventet under white box-testning, kan det være tegn på, at der er alvorlige fejl i programmet, som skal udbedres, før udvikling og testning fortsætter.
3. Testrapporter
Testrapporter er rapporter, der udarbejdes af udviklere og testere under og efter softwaretestning.
De indeholder detaljer om testresultaterne, herunder hvilke testcases der bestod og ikke bestod, eventuelle fejl, der blev fundet under testen, og anbefalinger til de næste skridt.
Udviklere bruger testrapporter til at kommunikere med andre udviklere, hvis opgave det kan være at rette fejl og mangler, der er fundet under testningen.
Eksempler på white box-test
White box-testning gør det muligt for udviklere at kontrollere, at softwaresystemets interne struktur fungerer, som den skal, uanset systemets eksterne resultater og output.
Eksemplerne nedenfor illustrerer, hvordan white box-testning kan hjælpe udviklere med at verificere softwarens interne funktioner.
1. E-commerce registreringsside eksempel
Et eksempel på white box-testning er den måde, hvorpå udviklere tester webstedsfunktioner. Hvis du forsøger at teste registreringssiden på et e-handelswebsted, kan white box-testning give udviklerne mulighed for at forstå, om de funktioner og klasser, der er involveret i registreringen, fungerer, som de skal, når registreringsfunktionen udføres.
Dette omfatter specifikt alle de oplysninger, som en bruger indtaster, og vurderer parametrene bag formularen, herunder de datoer, der er gyldige og ikke-gyldige, og hvad formularen opfatter som en legitim e-mailadresse.
Holdet indtaster derefter en række strenge, der tester formularen, hvor nogle er designet til at mislykkes, mens andre er designet til at lykkes, før resultaterne vurderes i forhold til de forudsagte resultater.
Black box-testning tjekker derimod kun, om selve siden fungerer, uden yderligere analyse af hvorfor eller hvordan.
2. Eksempel på en lommeregner
Applikationsberegnere er et andet eksempel på white box-testning.
Hvis du laver en lommeregner, der bruges som en del af et program, vil black box-testere blot teste, om lommeregnerens output er korrekt, når lommeregneren bruges som tiltænkt.
White box-testere kontrollerer regnemaskinens interne beregninger for at verificere, hvordan output er beregnet, og om det er korrekt. Dette er mere nyttigt til mere komplekse beregninger med flere trin, f.eks. skatter. Testerne undersøger koden for at se de trin, som beregneren tager, og i hvilken rækkefølge trinene er, før de ser resultatet efter hvert trin.
Hvis inddatoen i lommeregneren er (7*4) – 6, og output er 22, er dette korrekt, og black box-testning vil bestå denne test. Det skyldes dog, at 7*4 = 28, og 28 – 6 er 22. White box-test kan afsløre, at softwaren har fundet dette resultat ved at udføre 7*4 = 32 og 32 – 6 = 22, hvilket ikke er korrekt.
Denne større indsigt viser, at beregningen er nøjagtig efter hvert enkelt trin, finder det trin, hvor den måske ikke er nøjagtig, og løser det hurtigere, da testeren tydeligt kan se, hvor problemet opstår.
Typer af fejl og fejl i white box-testning
Under white box-testning er det muligt at identificere og lokalisere fejl, der kan påvirke den måde, som systemerne fungerer på under motorhjelmen. Disse fejl kan påvirke eksterne funktioner, eller de kan påvirke ydeevne eller pålidelighed.
Nogle af de mest almindelige typer af fejl og fejl, der opstår under white box-testning, er anført nedenfor.
1. Logiske fejl
Logiske fejl opstår i white box-test, fordi white box-test viser områder, hvor programmet ikke fungerer logisk, eller hvor funktioner og betingelser misbruges i softwarens kode.
Logiske fejl kan vise sig som systemfejl eller blot resultere i uventet adfærd og output.
2. Konstruktionsfejl
White box-testning kan hjælpe udviklere med at identificere designfejl i koden. Designfejl opstår, når der er en forskel mellem det logiske flow i softwaren og den faktiske implementering af softwaren. De kan resultere i uventet adfærd og fejl i ydeevnen.
3. Typografiske fejl
Typografiske fejl og syntaksfejl er fejl, der opstår som følge af menneskelige fejl – f.eks. fordi en udvikler har skrevet en bestemt sætning forkert eller tilføjet forkert tegnsætning i en kodelinje. Små fejl som disse kan resultere i ødelagte funktioner og erklæringer, som softwaren ikke kan læse, hvilket kan medføre større fejl i systemet.
Almindelige målinger af white box-testning
Når du udfører white box-testning, kan almindelige testmetrikker hjælpe dig med at måle, hvor vellykkede og omfattende dine white box-test er, samt med at forstå kvaliteten af dine udvikleres arbejde.
Testmetrikker informerer udviklingsprocessen, fordi de kan identificere områder, der skal forbedres, eller vejlede testprocessen fremadrettet.
1. Kodedækning
Et af de primære kendetegn ved white box-testning er, at den skal dække så meget af koden som muligt, og du kan måle, hvor meget kode du har dækket med kodedækningsmetrikker.
Kodedækningsmetrikker viser, hvor stor en del af applikationens samlede kode du har verificeret ved hjælp af white box-test. Generelt tilstræber udviklere at dække så tæt på 100 % af softwarekoden som muligt ved hjælp af white box-testning.
Kodedækning kan opdeles i forskellige målinger, herunder sti-, segment-, statement- og branchedækning.
Compound condition coverage er en anden type metrik for kodedækning, der kontrollerer, at hver betingelse i et sæt er blevet kontrolleret langs flere stier og kombinationer af stier.
2. Målinger af fejl og mangler
Defektmålinger afspejler, hvor mange defekter der er fundet, hvor god din white box-testning er til at identificere defekter, og hvor stor en procentdel af koden der består eller ikke består white box-testningen.
Fejlmålinger kan præsenteres som antallet af fejl pr. tusinde linjer kode eller antallet af fejl i programmet i alt. Selv om et lavt antal fejl kan virke positivt, skal udviklerne sikre sig, at det ikke skyldes, at fejl overses under testningen.
3. Udførelse af test
Testudførelsesmetrikker kan hjælpe udviklere med hurtigt at se, hvor stor en del af de samlede test der er blevet udført indtil videre, og hvor mange test der ikke er udført. Tekstudførelsesmetrikker hjælper softwareteams med at forstå, hvor langt de er nået med white box-testning, og om automatiserede softwaretests kører som forventet.
Det er dog muligt at få både falske positive og falske negative resultater, hvilket kan påvirke nøjagtigheden af denne målemetriks nøjagtighed.
4. Testens varighed
Testvarighedsmålinger fortæller os, hvor lang tid det tager at køre automatiserede tests, hvilket er særligt vigtigt i white box-testning, fordi automatisering er afgørende for at maksimere testens effektivitet og testdækning.
Testens varighed er ofte en flaskehals i agil softwareudvikling, så hvis man forstår, hvor lang tid det tager at køre softwaretests, kan det hjælpe udviklingsteams med at fremskynde udviklingsprocessen.
Det er dog vigtigt at huske, at målinger af testvarighed ikke fortæller dig noget om kvaliteten af de tests, du kører.
White box-testværktøjer
Værktøjer og teknologi kan gøre white box-testning betydeligt mere præcis, effektiv og omfattende. White box-testværktøjer kan hjælpe softwareingeniører med at automatisere white box-test, registrere og dokumentere white box-testprocessen og administrere white box-test fra start til slut.
5 bedste gratis white box-testværktøjer
Hvis du ikke ønsker at investere i dyre white box-testværktøjer endnu, kan du afprøve en lang række gratis white box-testværktøjer online uden at betale noget.
Gratis testværktøjer tilbyder ikke altid alle de samme funktioner som virksomhedsværktøjer, men de er et godt udgangspunkt for nybegyndere inden for white box-testning, og de kan hjælpe udviklingsteams med at få en større forståelse af, hvilke værktøjer og teknologier de har brug for.
1. ZAPTEST GRATIS udgave
ZAPTEST er et værktøj til softwaretestning og software til automatisering af robotprocesser, der gør det muligt for udviklere og QA-testere at automatisere både white box-testning og black box-testning.
ZAPTEST’s gratis version giver mulighed for flere virtuelle brugere, flere gentagelser og brugerforumsupport. Applikationen fungerer med både lokale og eksterne datakilder og integreres med HP ALM, Rally og JIRA. Brugere, der kan lide ZAPTEST’s gratis tilbud og ønsker at se mere af det, virksomheden tilbyder, kan også spørge om opgradering til enterprise-udgaven, når den er klar.
2. Bugzilla
Bugzilla er et meget populært open source værktøj til softwaretestning, der giver udviklere mulighed for at spore fejl og mangler i softwaren og administrere fejlenes livscyklus.
Bugzilla gør det nemt at tildele fejl til udviklere, prioritere og verificere fejl og lukke dem, når de er rettet. Bugzilla er et fantastisk værktøj til teams, der stadig forsøger at standardisere deres tilgang til fejlrapportering, og det er helt gratis at bruge.
3. OpenGrok
OpenGrok er en open source kodebrowser og søgemaskine til kodebase. Det er kompatibelt med kode skrevet i Java C++, JavaScript og Python sammen med andre programmeringssprog.
Hvis du ønsker at kunne navigere hurtigt i en stor kodebase under white box-testning, er OpenGrok helt gratis og let at bruge.
4. SQLmap
SQLmap er et andet open source-værktøj, som anses for at være næsten uundværligt i white box-testning. SQLmap regulerer strømmen af udnyttelsen og opdagelsen af SQL-injektionsfejl.
SQLmap er et selvbeskrevet “penetrationstestværktøj” og kan hjælpe white box-testere med at identificere og lokalisere sikkerhedsfejl i kildekoden og rette dem, før de går videre.
5. Emma
Emma er et open source-værktøjssæt, der kan måle din kodedækning, hvis du arbejder i Java. Det er en superhurtig måde til hurtigt at fastslå din kodedækning og til at spore, hvor meget kode hvert medlem af udviklingsteamet har dækket på individuel basis.
Emma understøtter klasse-, metode-, linje- og grundlæggende blokdækning og er fuldt Java-baseret.
5 bedste værktøjer til white box-testning i virksomheder
Hvis du leder efter værktøjer med større funktionalitet eller bedre support, kan white box-testværktøjer til virksomheder være bedre egnet til dit udviklingsteam.
1. ZAPTEST ENTERPRISE udgave
ZAPTEST’s enterprise-udgave er den forstærkede version af den gratis ZAPTEST. I denne version kan brugerne drage fordel af ubegrænsede OCR-skabeloner, ubegrænsede iterationer og ubegrænsede VBScript- og JavaScript-scripts.
ZAPTEST’s enterprise-udgave tilbyder en mere komplet pakke af værktøjer til udviklingsteams, der ønsker at skifte til automatisering, og enterprise-versionen leveres også med ekspertsupport, så dit team får mest muligt ud af ZAPTEST’s automatisering af softwaretestning og RPA-teknologi.
2. Fiddler
Fiddler er en pakke af værktøjer fra Telerik, der er udviklet til white box-test af webapplikationer. Fiddler kan logge al HTTP-trafik mellem dit system og internettet og evaluere indstillede breakpoints samt justere udgående og indgående data. Det fås i forskellige formater afhængigt af dit budget og dine krav, så der er en Fiddler-udgave til næsten alle hold.
3. HP styrke
HP Fortify, tidligere kendt som Fortify, er et andet værktøj til sikkerhedstestning, der tilbyder omfattende sikkerhedsløsninger til white box-testning. Fortify-værktøjspakken omfatter værktøjet Fortify Source Code Analysis, som automatisk scanner din kildekode for sårbarheder, der kan gøre din applikation åben for cyberangreb.
4. ABAP-enhed
ABAP Unit gør det muligt for softwareudviklere at udføre både manuelle og automatiserede enhedstest hurtigt og enkelt. Udviklere skriver enhedstests i ABAP-applikationen og bruger disse tests til at verificere kodefunktioner og identificere fejl i enhedstests.
Softwareteams, der ønsker at afprøve dette værktøj, kan starte med den gratis version af ABAP Unit, før de går videre til enterprise-udgaven.
5. LDRA
LDRA er en proprietær pakke af værktøjer, der kan bruges til statement coverage, branch coverage og decision coverage ved white box-testning. Det er et fremragende værktøj, hvis du vil kontrollere, at din kildekode opfylder standardkravene til overholdelse, sporing og kodehygiejne.
Hvornår skal du bruge virksomhed
vs freemium white box testværktøjer?
Både enterprise- og freemiumværktøjer til softwaretestning har deres plads i ethvert moderne softwareudviklingsteam. Efterhånden som dit team vokser, og automatiseret testning bliver vigtigere for din white box-testtilgang, vil du sandsynligvis ønske at opgradere fra primært at arbejde med gratis testværktøjer til at arbejde med virksomhedsværktøjer, der tilbyder flere funktioner og ubegrænsede anvendelsesmuligheder.
Der er dog specifikke scenarier, hvor freemium-værktøjer kan være mere velegnede end virksomhedsværktøjer.
Mange udviklere vælger at starte med freemium-værktøjer, når de eksperimenterer med nye funktioner og teknologier, primært for at vurdere, om disse teknologier passer til deres team, før de investerer i virksomhedsteknologier.
Du kan også prøve gratis versioner af virksomhedsværktøjer som ZAPTEST, så du kan prøve dem, før du køber dem, og finde ud af mere om, hvad virksomhedsværktøjer kan tilbyde.
Endelig er nogle freemium-værktøjer som Emma og Bugzilla specialiseret i nichefunktioner, men vigtige funktioner, der giver løbende fordele selv for softwareteams, der er villige til at betale for virksomhedsteknologier.
White box-test: tjekliste, tips og tricks
Når du er klar til at udføre white box-test, skal du sikre dig, at du har alt det, du har brug for, inden du går i gang. Nedenfor er en liste over ting, du skal huske, før du begynder at teste white box-testning for at maksimere din testdækning og forbedre nøjagtigheden af dine white box-testresultater.
1. Brug automatiseringsværktøjer
Automatiseringsværktøjer kan i høj grad fremskynde processen med at udføre white box-testning og reducere fejlprocenten og øge den samlede nøjagtighed.
Næsten alle softwareteams bruger i dag en vis grad af automatisering til at udføre white box-testning, så hvis du eksperimenterer med forskellige automatiseringsværktøjer og -teknologier, før du begynder white box-testning, kan det hjælpe dig med at vælge de værktøjer, du ønsker at bruge, før testningen begynder.
2. Sigt efter 100 % testdækning
Du vil sandsynligvis ikke nå dit mål om 100 % testdækning, men det er bedst at forsøge at komme så tæt på dette tal som muligt, når du udfører white box-testning.
Brug testdækningsværktøjer til at spore og måle individuelle målinger såsom path coverage og branch coverage og sikre, at alle de vigtigste stier og grene i din software er blevet dækket under white box-testning.
3. Udarbejdelse af klare testrapporter
Som det er tilfældet med andre former for softwaretestning, skal du sørge for, at dit team ved, hvordan man udarbejder præcise og klare testrapporter efter hver testfase har fundet sted.
En testrapport skal være skrevet i et letforståeligt format og indeholde detaljer om testmetoden samt et resumé af output og resultater for hver testcase, der er udført. Den endelige rapport skal begrunde de skridt, der er taget, og indeholde anbefalinger om de næste skridt.
4. Mål din succes med testmetrikker
Testmetrikker hjælper softwareteams med at spore og registrere udviklingen i white box-testning og giver værdifulde oplysninger, som kan bruges i fremtidige udviklingsprocesser.
Det er vigtigt, at udviklere bruger målinger til at forstå, hvor effektiv den testning, de udfører, er, og hvor ren deres oprindelige kode var, så de kan forbedre deres arbejde i fremtiden.
White box-testning:
Konklusion
White box-testning inden for softwareteknik er en vigtig type softwaretestning, der verificerer den interne struktur og logik i en softwareapplikations kildekode.
Sammen med black box-testning sikrer white box-testning ikke blot, at softwaren fungerer som forventet, men også at den interne kode er logisk, ren og komplet.
White box-testning udføres oftest i forbindelse med enhedstestning og integrationstestning, og den udføres altid af udviklere og softwareingeniører med fuldstændig viden om softwarens interne kode.
Selv om nogle white box-test kan udføres manuelt, er mange white box-test i dag automatiseret på grund af de forbedringer i hastighed, effektivitet og dækning, som automatisering af white box-test giver.
Ofte stillede spørgsmål og ressourcer
Hvis du gerne vil vide mere om white box-testning, er der masser af gratis online ressourcer, som du kan bruge. Du kan bruge videoer, bøger og andre ressourcer til at lære dig selv at udføre white box-testning og sikre, at dine white box-teststandarder følger bedste praksis.
1. De bedste kurser i white box test automatisering
Hvis du vil lære mere om white box-testautomatisering, kan du tage et kursus i softwaretestning og white box-testning. Nogle af disse kurser er akkrediterede og giver formelle kvalifikationer, mens andre er uformelle online-kurser, der er designet til at hjælpe udviklere og softwaretestere, som ønsker at forbedre deres viden om et bestemt emne.
Nogle af de bedste kurser i white box-testning, der er tilgængelige online i dag, omfatter:
2. Hvad er de fem vigtigste interviewspørgsmål om white box test automatisering?
Hvis du forbereder dig til et interview, hvor du måske skal tale om white box-test, white box-teknikker og automatiseringsværktøjer, er det vigtigt, at du ved.
- Hvad er forskellen mellem white box-test og black box-test?
- Hvorfor er white box-testning vigtig?
- Hvad er nogle af de forskellige tilgange til white box-testning, som du kan vælge?
- Hvilke processer er involveret i white box-testning, og hvordan kan vi forbedre dem?
- Hvilke værktøjer og teknologier kan du bruge til at gøre white box-testning hurtigere eller mere præcis?
3. De bedste YouTube-tutorials om white box-testning
Hvis du vil lære mere om white box-testning, kan du se YouTube-tutorials, som kan hjælpe dig med at forstå, hvordan white box-testning fungerer, og se visuelle forklaringer på de processer og tilgange, der er involveret i white box-testning.
Nogle af de mest informative YouTube-tutorials på nettet omfatter nu:
- Udacity: White Box Testing Eksempel
- Guru99: Hvad er White Box Testing?
- White Box vs. Black Box-testning
- White Box Testing-teknikker
- Mentor for softwaretestning: Hvad er White Box Testing?
4. Hvordan man vedligeholder white box-tests
Vedligeholdelse af softwaretest sikrer, at de tests, du udfører, gang på gang er grundige og egnede til formålet. Det er vigtigt at vedligeholde alle typer softwaretests i både blackbox- og whitebox-testning, fordi den kode, du udfører test på, konstant ændrer sig med hver fejlretning og iteration. Det betyder, at dine testskripter skal ændres sammen med dem.
Vedligeholdelse af white box-tests indebærer, at du holder din ramme for testautomatisering opdateret og håndhæver processer, der er designet til at sikre, at test og testcases opdateres regelmæssigt.
Det kan du gøre ved at:
Indarbejdelse af vedligeholdelse i dit testdesign:
Hvis du overvejer fremtiden for white box-testning, når du først opbygger og designer dine white box-test, bliver det lettere at vedligeholde testene i fremtiden.
Gør det muligt at sikre klar kommunikation mellem teams:
Sørg for, at alle medlemmer af dit udviklingsteam har flere kommunikationskanaler, så ændringer i koden hurtigt kan afspejles i testene, så snart der er foretaget ændringer i koden.
Vær fleksibel:
Nogle gange kan det ske, at du foretager ændringer i koden, som du ikke har planlagt. Sørg for, at dit team ved, hvordan man hurtigt tilpasser sig disse ændringer, og at det har de nødvendige færdigheder til at følge op på disse ændringer i forbindelse med testning.
konstant revurdere testprotokollerne:
De testprotokoller, som du implementerede i starten af testen, er måske ikke længere egnede, når din software har gennemgået forskellige ændringer og forbedringer. Revurder dine testprotokoller med jævne mellemrum for at kontrollere, om de stadig passer godt.
5. De bedste bøger om white box testing
White box-testning er et dybt emne, som det kan tage flere år at mestre. Hvis du ønsker at blive ekspert i moderne white box-testning inden for softwaretestning, kan du læse bøger om white box-testning skrevet af udviklere, akademikere og ingeniører.
Nogle af de bedste bøger om white box testing og testautomatisering i dag er bl.a:
- Kunsten at teste software, tredje udgave af Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas
- Test af software: A Craftsman’s Approach, fjerde udgave, af Paul C. Jorgensen
- Hvordan man ødelægger software: En praktisk guide til test af James Whittaker
- Just Enough Software Test Automation af Dan Mosley og Bruce Posey
Du bør kunne finde disse bøger i nogle boghandlere og på biblioteker samt online. Du kan også finde andre læsematerialer og læringsressourcer i læselisterne for gode kurser og programmer inden for softwaretestning.
