White box er en kategori av programvaretesting som refererer til testmetoder for hvordan programvarens interne struktur og design fungerer. Det står i kontrast til black box-testing, som er testing som ikke angår den interne driften av programvaren, men i stedet bare tester de eksterne utgangene til programvaren.
I denne artikkelen vil vi utforske emnet white box-testing: hva det er, hvordan det fungerer, og hvilke typer programvaretestverktøy kan hjelpe testere og utviklere med å utføre white box-testing i programvaretesting.
Hva er white box testing?
White box-testing er en programvaretestingsteknikk som involverer testing av den interne strukturen og designen til en programvarekonstruksjon i motsetning til de eksterne utgangene eller sluttbrukeropplevelsen som testes i black box-testing.
White box-testing er et paraplybegrep som inkluderer mange forskjellige typer programvaretesting, inkludert enhetstesting og integrasjonstesting . Fordi testing av hvite bokser innebærer testing av kode og programmering, innebærer å utføre testing av hvit boks vanligvis en viss forståelse av dataprogrammering.
White box-testing i programvareteknikk kan innebære testing av koden og intern design av programvare for å verifisere input-output flyt og sjekke design, brukervennlighet og sikkerhet til programvaren.
White box-testing lar testere inspisere den indre funksjonen til systemet samtidig som de verifiserer at innganger resulterer i spesifikke, forventede utganger.
White box-testing er et viktig trinn i programvaretesting fordi det er den eneste typen testing som har vurdert hvordan koden i seg selv fungerer.
1. Når og hvorfor trenger du hvit boks
testing i programvaretesting og engineering?
White box-testing kan utføres på forskjellige stadier av testsyklusen for å verifisere funksjonen til intern kode og struktur.
Oftest skjer white box-testing når utviklere og testere utfører enhetstesting og noen ganger under integrasjonstesting.
Per definisjon betraktes enhetstesting som en type testing av hvite bokser, mens integrasjonstesting kan dele funksjoner i både hvit- og svartbokstesting , men anses generelt for å være en form for testing av svart boks.
Ellers kan white box-testing også brukes ad hoc for å verifisere den interne funksjonen til en programvarebygging. White box-testing er den mest økonomiske måten å øke testdekningen på hvis det er behov for dette, og det er også en enkel måte å verifisere hvordan spesifikke deler av koden fungerer eller testområder av en programvarebygging som testerne mistenker blir undertestet.
Formelle kodegjennomganger, som utføres med white box-testing, kan også brukes til å identifisere sikkerhetsfeil og andre sårbarheter. På samme måte, hvis elementer i koden er ødelagt, kan testing av hvite bokser hjelpe programvareingeniører med å finne ut hvor feilen er.
2. Når du ikke trenger å gjøre white box testing
I de fleste tilfeller, når programvareingeniører og testere setter en ny programvarekonstruksjon gjennom testsyklusen, er det nødvendig med en viss mengde white box-testing for å verifisere den interne funksjonen til koden.
Enhetstesting er en type white box-testing som utføres av utviklere for å bekrefte at individuelle enheter fungerer som forventet. Denne tidlige typen testing gjør det mulig for utviklere å identifisere feil og defekter før formell testing i et QA-miljø finner sted.
Etter enhetstesting foregår integrasjonstesting, systemtesting og brukeraksepttesting . Disse anses generelt for å være former for svart boks-testing som vanligvis ikke involverer mange hvite boks-testteknikker.
Men i noen tilfeller kan testere og utviklere bruke white box-testing i disse stadiene for å identifisere spesifikke defekter i koden. På dette stadiet, hvis det ikke er noe som tyder på at det er noe galt med koden og alle svarte boks-tester bestått, kan mange testteam vurdere at det ikke er behov for å utføre ytterligere testing av hvit boks.
3. Hvem er involvert i white box testing?
White box-testing utføres nesten alltid av programvareutviklere og programvareingeniører. Dette er fordi white box-testing krever detaljert kunnskap om datakode og kodeteknikker, og de fleste QA-testere mangler de tekniske ferdighetene som kreves for å utføre white box-testing.
Enhetstesting, den primære typen white box-testing, utføres alltid i utviklingsmiljøet av utviklere. Utviklere kan også utføre white box-testing når og når det er nødvendig, for å verifisere måten forskjellige elementer i koden fungerer på eller for å sjekke at feilene er rettet på riktig måte.
Fordelene med testing av hvit boks
White box-testing lar utviklere og programvareingeniører teste flere aspekter ved kode enn black box-testing.
Mens black box-testing kan fortelle oss hvordan en programvarebygging fungerer for sluttbrukere, kan white box fortelle oss mer om hvordan programvarekode fungerer. Ren, effektiv kode er avgjørende i programvareutvikling, spesielt hvis utviklere ønsker å gjenbruke koden senere eller legge til patcher og oppgraderinger i fremtiden.
1. Maksimer testdekningen
White box-testing kan hjelpe testere med å maksimere testdekningen. Testing av så mye programvarekode som mulig maksimerer vanligvis sjansen for å oppdage eventuelle feil eller feil i koden, og hensikten med white box-testing er vanligvis å teste så mye av koden som mulig.
Black box-testing handler på den annen side ganske enkelt om å utføre testtilfeller som kanskje tilbyr bred kodedekning eller ikke.
2. Finn skjulte feil og feil
En av de største fordelene med white box-testing er at fordi white box-testing verifiserer intern funksjonalitet, gjør det det lettere for utviklere å finne feil og feil som ellers kan være skjult dypt i koden.
I tillegg til å identifisere tilstedeværelsen av feil, er det vanligvis lettere å finne nøyaktig hvor i kodebasen en feil befinner seg når du utfører white box-testing på grunn av den svært spesifikke naturen til denne typen testteknikk.
3. Enkel automatisering
Det er veldig enkelt å automatisere testing av hvite bokser, spesielt når du utfører enhetstesting. Enhetstester krever vanligvis at utviklere tester ut små kodebiter individuelt for å se om de kjører som forventet. Dette er veldig enkelt å automatisere, noe som betyr at det er en rask og effektiv form for programvaretesting.
Dette er en av grunnene til at enhetstesting utføres før andre, mer tidkrevende typer testing.
4. Tidseffektiv
White box-testing er tidseffektivt av en rekke årsaker.
Som nevnt ovenfor er det relativt enkelt å automatisere de fleste typer testing av hvite bokser, noe som betyr at det ofte er raskere å utføre testing av hvit boks enn testing av svart boks. I tillegg til dette gjør white box-testing det enkelt for utviklere å finne feilene og feilene de identifiserer i koden fordi de finner dem mens de tester selve koden.
5. Kodekvalitet
White box-testing lar utviklere ta en ny titt på koden de har skrevet og vurdere dens kvalitet og renslighet.
Å gå gjennom koden stykke for stykke gir utviklere muligheten til å fjerne unødvendige deler av kode og rydde opp i kode, noe som gjør det enklere å gjenbruke og redigere deler av kode i fremtiden.
Det kan også tvinge utviklere til å vurdere hvordan kode implementeres og om dette vil skalere godt i fremtiden.
Utfordringene med testing av hvit boks
White box-testing er ikke uten utfordringer. Det er noen få grunner til at noen utviklingsteam kan finne white box-testing vanskeligere å gjennomføre enn black box-testing, samt andre grunner til at det av noen mennesker kan bli sett på som mindre viktig enn black box-testing.
1. Tekniske barrierer
White box-testing har tekniske barrierer som black box-testing ikke gjør. For å utføre white box-testing krever testere kunnskap om den interne funksjonen til systemet, som i programvaretesting vanligvis betyr programmeringskunnskap.
Dette er grunnen til at white box-testing nesten alltid utføres av programvareingeniører og utviklere og ikke utføres av QA-testere som sjelden har de tekniske ferdighetene som er nødvendige for å utføre denne typen testing.
2. Kostnad
White box-testing kan være mer kostbart å utføre sammenlignet med black box-testing på grunn av hvor grundig denne typen testing er.
Utviklere må bruke mye tid på å skrive intensive enhetstester, og white box-tester kan ofte ikke gjenbrukes til andre applikasjoner, noe som betyr at white box-testing vanligvis koster ganske mye å utføre.
3. Nøyaktighet
White box-testing er ikke alltid den mest nøyaktige metoden for programvaretesting, og hvis utviklingsteam utelukkende stolte på white box-testing ville dette resultere i mange tapte feil og tilfeller.
White box-testing validerer bare funksjoner som allerede eksisterer, mens black box-testing kan brukes til å teste delvis implementerte funksjoner eller identifisere funksjoner som faktisk mangler i programvaren og bør inkluderes i senere iterasjoner.
4. Omfang
White box-testing forteller oss vanligvis ikke mye om brukeropplevelsen eller sluttresultatet av funksjonene innebygd i programvaren.
Mens utviklere kan bruke white box-testing for å verifisere om koden fungerer som den skal, kan de ikke konkludere med at arbeidskoden leverer de riktige utdataene til sluttbrukere uten å kombinere white box-testing med black box-testing.
Dette betyr at det er begrensninger med omfanget av white box-testing og hvor mye det kan fortelle oss om programvare.
Egenskapene til hvite boks-tester
White box testing kan defineres av spesielle egenskaper som skiller den fra andre former for testing som black box og grå boks testing.
De fleste av disse egenskapene kan betraktes fra perspektivet om hvordan de skiller seg fra egenskapene til testing av svart boks og hvordan dette skiller testing av hvit boks og testing av svart boks.
1. Vedlikeholdbarhet
White box-testing fører til et høyere nivå av vedlikehold i koden din, og forenkler arbeidet som teamet ditt må gjøre fremover.
Siden det er et konstant øye med koden og hva den gjør med data, er det mye enklere å vedlikeholde den ettersom du forstår hvor problemer oppstår og hvorfor de gjør det. Dette gjør også koden enklere for fremtidige oppdateringer, siden du ikke utvikler store og komplekse patcher for ukjente og enkle problemer.
2. Fleksibilitet
White box-testing foregår på kode som er fleksibel nok til å akseptere endringer relativt raskt. Ufleksibel kode, for eksempel den som er en del av en tredjepartsmodul eller integrasjon, hindrer en hvit boks-tester fra å gjøre raske endringer.
Å fokusere på å ha kode som du kan endre så snart du oppdager et problem, gjør white box-testing svært tilpasningsdyktig og betyr at et programs problemer løses langt raskere.
3. Modularitet
White box-testing trives i kode som har en grad av modularitet, noe som betyr at separate elementer i programvaren har et klart skille fra hverandre.
Hvis et program har et problem med “spaghettikode” der hvert aspekt er knyttet til et annet, blir testing av hvite bokser uendelig mye mer komplisert ettersom en tester må undersøke hele programmet i stedet for en spesifikk enhet.
4. Integrasjon
White box-testing er ekstremt nyttig for integrasjonstesting. Testere kan se om en funksjon fungerer til det punktet at den forlater den aktuelle programvaren og om den kommer tilbake fra det integrerte systemet så funksjonell som forventet.
Dette er svært informativt og lar en organisasjon vite om problemet er lokalt eller en del av den integrerte plattformen.
Hva tester vi i white box tester?
White box-tester brukes til å teste funksjoner i koden som ikke kan verifiseres av black box-testmetoder. Dette kan bety å teste hvordan selve koden fungerer, noe som lar utviklere forstå årsaken og effekten av ulike aspekter av koden.
Utviklere bruker white box-testing for å teste sikkerhetshull, uttalelser og funksjoner, utganger og stier i koden.
1. Innvendige sikkerhetshull
White box-testing kan brukes til å se etter sikkerhetshull og sårbarheter i koden som hackere og nettkriminelle kan dra nytte av i fremtiden.
White box-testing kan brukes til å sjekke om beste praksis for sikkerhet har blitt fulgt under utviklingsstadiet og for å se etter sikkerhetssårbarheter som kan repareres før koden går videre til videre testing.
2. Veier i kodeprosesser
White box-testing lar utviklere teste banene som kobler forskjellige kodeelementer sammen. Utviklere tester ikke bare logikken i koden, men de kan også se etter kodestruktur og hygiene.
God, ren kode har ingen unødvendige linjer eller ødelagte elementer som ikke fungerer som forventet, selv om de eksterne utgangene til black box-testing er som forventet.
3. Forventede utganger
White box-testing kan også teste de forventede utgangene av kode akkurat på samme måte som black box-testing kan, selv om testere gjør det ved å vurdere koden i stedet for å bruke applikasjonen som testere kan gjøre i black box-testing.
Utviklere tester forventede utganger ved å verifisere innganger én etter én og sjekke at den resulterende utgangen stemmer overens med forventningene.
4. Utsagn, objekter og funksjoner
Ved å utføre white box-testteknikker kan programvareutviklere sikre at utsagn, objekter og funksjoner i koden oppfører seg logisk og resulterer i de forventede utdataene.
5. Funksjonalitet av betingede løkker
White box-testing kan også brukes til å sjekke funksjonaliteten til betingede løkker, inkludert enkle, sammenkjedede og nestede løkker. Utviklere vil sjekke om disse løkkene er effektive, oppfyller betingede logiske krav, og om de håndterer lokale og globale variabler korrekt.
Rydder opp litt forvirring:
Testing av hvit boks vs svart boks vs grå boks
White box testing, black box testing og grå boks testing er begreper som programvaretestere bruker for å referere til ulike kategorier av testing eller ulike testmetoder.
Et moderne syn på disse testdistinksjonene er at linjene som trekkes mellom ulike typer bokstesting blir mer uklare, ettersom ulike typer testing ofte kombinerer elementer fra både hvit og svart boks-testing og utleder tester fra dokumenter på ulike abstraksjonsnivåer.
Likevel er det fortsatt viktige skiller mellom disse testformene.
1. Hva er black box testing?
Black box-testing er en form for programvaretesting der programvarefunksjonalitet kontrolleres av testere som ikke har kjennskap til den interne strukturen til koden eller hvordan man implementerer koden på et mer teknisk nivå.
Black box-testing tester kun de eksterne utgangene til programvaren, eller med andre ord, den tester hva sluttbrukeren vil oppleve ved bruk av programvaren.
Black box-testing er også kjent som atferdstesting fordi den tester hvordan programvaren oppfører seg under visse forhold.
Testere kan bruke black box-testing for å vurdere hvordan ulike funksjoner i programvaren oppfører seg og sjekke disse mot forventningene for å sikre at programvaren oppfyller brukernes krav. Black box-testing brukes i systemtesting og aksepttesting for å verifisere ulike funksjoner og kontrollere at systemet fungerer som forventet når det fungerer som en helhet.
Når de utfører black box-testing, skriver brukere testsaker for å verifisere ulike elementer individuelt. Fordi black box-testing ikke krever de samme tekniske ferdighetene som white box-testing, blir black box-testing vanligvis utført av testere i et QA-miljø i stedet for av utviklere.
Automatisering av black box-testing er vanligvis lettere å automatisere sammenlignet med white box-testing ved å bruke ende-til-ende automatiseringsverktøy som ZAPTEST.
Hva er forskjellene mellom testing av hvit boks og svart boks?
Den primære forskjellen mellom testing av svart boks og hvit boks er hva som testes.
Black box-testing handler om å teste de eksterne utgangene til programvarebyggingen, mens white box-testing handler om å teste hva som skjer under panseret.
Noen av de primære forskjellene mellom testing av svart boks og hvit boks er:
Hensikt
Hensikten med black box testing er å verifisere at systemet fungerer som forventet for sluttbrukeren, mens formålet med white box testing er å sjekke kvaliteten og integriteten til programvarens kode.
Black box-testing for et videospill kan for eksempel se en sluttbruker prøve spillet og vurdere det for deres opplevelse, med white box-testing på det samme prosjektet som sikrer at inntasting av spesifikke innganger fører til at karakteren fullfører den riktige handlingen.
Prosess
Prosessene som brukes i testing av hvit og svart boks er svært forskjellige. White box-testing er mye enklere å automatisere enn black box-testing, og vanligvis må black box-testing automatiseres ved hjelp av programvareautomatiseringsverktøy .
For eksempel, når du tester en database, involverer en hvit boks-test automatisering av dataregistrering for å kontrollere at alle resultatene er korrekte, med svart boks-testing som involverer brukere som replikerer manuelle prosesser og rapporterer om dem uten bruk av et automatiseringssystem.
Testere
Black box-testing utføres nesten alltid i et QA-miljø av profesjonelle programvaretestere, mens white box-testing utføres av programvareutviklere og ingeniører som har mer detaljert teknisk kunnskap om kodekilden.
Teknikker
Black box-testing bruker ulike teknikker som ekvivalenspartisjonering, grenseverdianalyse og testing av beslutningstabeller. White box-testing bruker teknikker som beslutningsdekning, tilstandsdekning og uttalelsesdekning.
Drift
Testmetodene for black box-testing passer testoperasjoner på høyere nivåer som systemtesting og aksepttesting, mens white box-testing er mer egnet for operasjoner på lavere nivå som enhetstesting og integrasjonstesting.
Av denne grunn blir testing av hvit boks vanligvis utført før de fleste former for testing av svart boks.
2. Hva er testing av grå boks?
Gråbokstesting er en programvaretestingsteknikk som brukes til å teste programvareprodukter og applikasjoner av testere som kan ha delvis kunnskap om applikasjonens interne struktur, men ikke fullstendig kjennskap til den.
Gray box-testing kan kombinere elementer av både black box-testing og white box-testing for å tillate utviklere og testere å identifisere feil i kode og lokalisere kontekstspesifikke feil.
Grå boks-testing kombinerer funksjoner fra både svart boks-testing og hvit boks-testing. Testere må ha litt kunnskap om den interne funksjonen til systemet som i white box-testing, men de bruker denne kunnskapen til å lage testcaser og utføre disse testcasene på funksjonalitetsnivå, slik tilfellet er i black box-testing.
Testing av grå boks gir mange av fordelene med testing av både svart boks og hvit boks, samtidig som den er relativt tidseffektiv og fleksibel.
Hva er forskjellene mellom testing av hvit boks og grå boks?
Fordi testing av grå boks tilbyr noe av den samme funksjonaliteten som testing av svart boks, er det noen store forskjeller mellom testing av grå boks og testing av hvit boks, men kanskje ikke så mange som med testing av svart boks.
Noen av de største forskjellene mellom testing av grå boks og testing av hvit boks er:
Strukturell kunnskap
Ved testing av hvite bokser bør den interne utformingen og strukturen til koden være fullt kjent for personen som utfører testingen. I gråbokstesting er den interne strukturen til koden vanligvis bare delvis kjent.
Personer involvert
White box-testing utføres nesten utelukkende av programvareutviklere og programvareingeniører, mens testing av grå bokser kan utføres av sluttbrukere, testere og utviklere.
Effektivitet
White box-testing regnes som den mest tidkrevende typen programvaretesting, mens gråbokstesting låner noen av effektiviteten til black box-testing for å redusere tiden det tar å utføre tester.
Operasjon
I white box-testing skriver utviklere ganske enkelt kode for å implementere white box-tester og kjøre denne koden. Ved testing av grå boks, som testing av svart boks, utfører testere funksjonstester for å vurdere hvordan systemet fungerer eksternt.
Dekning
Whitebox-testing er den mest uttømmende typen testing, mens dekningen av gråbokstesting kan variere avhengig av om typen testtilfeller som utføres er basert på kode eller GUI.
Konklusjon:
Testing av hvit boks vs svart boks vs. grå boks
Testing av hvit boks, testing av svart boks og testing av grå boks er begreper som brukes for å referere til forskjellige teknikker for programvaretesting. Stort sett kan hver testtype defineres basert på i hvilken grad testere må ha kunnskap om kodebasen og implementeringen av koden:
1. Black box-testing:
Den interne strukturen til koden er ukjent.
2. Testing av hvit boks:
Den interne strukturen til koden er kjent.
3. Testing av grå boks:
Den interne strukturen til koden er delvis kjent.
Under programvaretesting er alle tre typer testing viktige for å verifisere funksjonen og integriteten til programvaren. Mens testing av hvit boks forteller oss mer om den underliggende strukturen til koden, kan testing av grå boks og testing av svart boks bekrefte hvordan systemet fungerer og om dette oppfyller sluttbrukerkravene.
De kanskje største forskjellene mellom disse tre testtypene er knyttet til hvem som utfører hver testtype, kravene til selve testingen og hva testing innebærer.
White box-testing har den høyeste adgangsbarrieren fordi den utføres av utviklere med detaljert kunnskap om selve kodebasen og fordi det er den mest tidkrevende og ofte kostbare typen testing.
Derimot er black box-testing den enkleste å utføre, og den kan utføres av testere uten kunnskap om den underliggende koden.
Typer hvite boks-tester
Det finnes mange forskjellige typer white box-tester, som hver kan brukes til å teste litt forskjellige aspekter av kodens interne struktur.
Nedenfor er noen av de vanligste typene testing av hvite bokser som brukes i dag.
1. Banetesting
Path testing er en type white box-testing basert på kontrollstrukturen til et program. Utviklere bruker kontrollstrukturen til å lage en kontrollflytgraf og teste forskjellige veier i grafen.
Banetesting er en type testing som er avhengig av kontrollstrukturen til programmet, noe som betyr at det krever at testerne har en grundig forståelse av denne strukturen.
For eksempel, hvis et system skal kontakte kunder med angitte meldinger på bestemte punkter i salgstrakten, innebærer stitesting å sikre at det følger de riktige trinnene avhengig av forholdene som dataene setter.
2. Sløyfetesting
Loop-testing er en av de viktigste typene white box-testing som tester looper innenfor programmets kode. Loops er implementert i algoritmer i koden og loop testing verifiserer om disse loopene er gyldige.
Sløyfetesting kan vurdere om det er sårbarheter som finnes innenfor spesifikke sløyfer og fremheve områder der utviklere kan trenge å korrigere koden for å sikre at sløyfen fungerer som den skal.
Et eksempel på en loop-test er å følge gjennom loopen med et spesifikt sett med datapunkter som ber loopen om å fortsette, for eksempel å nekte å godta noen vilkår og betingelser, før du legger inn en figur som spesifikt bryter loopen. Hvis loopen oppfører seg som forventet, er testen vellykket.
3. Betinget testing
Betinget testing er en type white box-testing som sjekker om de logiske betingelsene for verdier i koden er sanne eller usanne.
Betinget testing er en hovedform for white box-testing som forteller utviklere om koden er logisk og oppfyller kravene til programmeringslogikk.
Et eksempel på betinget testing er innenfor en regnskapsplattform. Å legge inn en rekke utgifter og inntekter bør resultere i riktige løpende totaler, med programvaren som gir nøyaktige resultater gjennom en vellykket test.
4. Enhetstesting
Enhetstesting er et viktig stadium i programvaretesting hvor utviklere tester individuelle komponenter og moduler og verifiserer at de fungerer som forventet før de integrerer ulike enheter sammen.
Programvareingeniører bruker hvite boks-testmetoder i enhetstesting for å teste små kodebiter om gangen. Dette gjør det enkelt å identifisere feil og feil når de oppstår under testing.
Et eksempel på enhetstesting er tidlig i utviklingen, da en bedrift lager en enkel knapp på en nettside som tar brukeren til en annen side. Hvis enheten fungerer som forventet, lykkes den, med utviklere som gjør endringer til den gjør det.
5. Mutasjonstesting
Mutasjonstesting er en type testing som tester endringer og mutasjoner. I mutasjonstesting gjør utviklere små modifikasjoner i kildekoden for å se om dette kan avsløre feil i koden.
Hvis testsaken består, indikerer dette at det er et problem med koden fordi den ikke skal bestå etter at endringene er gjort. Ideelt sett vil alle testtilfeller mislykkes ved mutasjonstesting.
Et eksempel på mutasjonstesting er i maskinlæring. Maskinlæringsprogrammer “muterer” automatisk avhengig av ny informasjon, så å teste disse programmene konsekvent for standarden “mutasjon” informerer utviklere om hvorvidt programvaren fungerer som forventet.
6. Integrasjonstesting
Integrasjonstesting er en viktig fase av programvaretesting, der testere fastslår om forskjellige moduler fungerer riktig når de er integrert med andre moduler.
White box-testteknikker brukes under integrasjonstesting for å sjekke at koden fungerer selv når flere moduler – som ofte har blitt kodet av ulike utviklere – jobber sammen.
Når en database henter informasjon fra en nettkilde, for eksempel, sikrer integrasjonstesting at dataene den henter er nøyaktige og oppdateres med en rimelig konsistent hastighet.
7. Penetrasjonstesting
Penetrasjonstesting er en type white box-testing som kan brukes til å simulere spesifikke cyberangrep på systemet.
Ved penetrasjonstesting gis testere tilgang til komplette nettverks- og systemdata som passord og nettverkskart. De prøver deretter å få tilgang til eller ødelegge data i systemet ved å prøve så mange forskjellige angrepsveier som mulig.
Penetrasjonstesting er et viktig aspekt ved sikkerhetstesting som bør utføres på alle programvarebygg.
En HR-plattform vil for eksempel fullføre penetrasjonstesting og se etter sårbarheter i koden for å sikre at plattformen er sikker nok til å holde ansattes data.
Testteknikker for hvit boks
Det er mange forskjellige testteknikker for hvite bokser som kan brukes til å utføre hvite boks-testene som er oppført ovenfor. Som alltid er det forskjellige teknikker som egner seg best for å teste forskjellige aspekter av koden, men alle de hvite boksteknikkene som er oppført nedenfor er viktige.
1. Uttalelsesdekning
En av de definerende egenskapene til testing av hvite bokser er at testere bør prøve å dekke så mye av kildekoden som mulig når de utfører tester med hvit boks.
Kodedekning er et sterkt mål på dette, og utsagnsdekning er en slik teknikk som white box-testere kan bruke for å øke dekningen av utsagn i koden.
Utsagnsdekning er en beregning som måler antall utførte utsagn delt på det totale antallet utsagn og multiplisert med 100. White box testere bør sikte på en høy dekning.
2. Filialdekning
Bransjedekningen, som uttalelsesdekning, gjenspeiler hvor bred dekningen av bestemte elementer i koden er i testing av hvite bokser. Grener tilsvarer “IF”-utsagn i logikk, der koden forgrener seg til sanne og falske alternativer som påvirker resultatet av operasjonen.
Når du bruker grendekningsteknikker, sjekker white box-testere om hver gren er behandlet minst én gang og validerer at begge grenene fungerer som de skal.
3. Stidekning
Stidekningsteknikker vurderer banene i en programvareapplikasjon. Maksimering av testbanedekning betyr å sikre at alle stier i programmet utforskes minst én gang. Det er en lignende type testteknikk som grendekning, men den anses som mer grundig og effektiv.
Banedekningstesting anses vanligvis som best egnet for testing av komplette applikasjoner i stedet for delvise bygg.
4. Beslutningsdekning
Beslutningsdekning er en av de viktigste white box-teknikkene fordi den gir data om sanne og falske resultater av boolske uttrykk i kildekoden.
Testing av beslutningsdekning validerer kildekoden ved å sikre at hvert merke av hver potensiell beslutning blir reist minst én gang under testingen.
Beslutningspunkter inkluderer alle anledninger der det er mulighet for to eller flere forskjellige utfall.
5. Tilstandsdekning
Tilstandsdekning er også kjent som uttrykksdekning. Denne hvite boksteknikken evaluerer undervariablene i betingede utsagn i koden for å verifisere utfallet av hver logiske tilstand.
Denne typen testing vurderer kun uttrykk med logiske operander, mens testing av beslutningsdekning og testing av grendekning brukes for å sikre andre logiske operasjoner.
6. Dekning for flere tilstander
I flere tilstandsdekningstester verifiserer testere ulike kombinasjoner av tilstander og evaluerer avgjørelsen som koden tar for hver kombinasjon.
Det kan være mange forskjellige testtilfeller for flere tilstandsdekningstester på grunn av det store antallet kombinasjoner av tilstander som eksisterer, så denne typen testing er ofte svært tidkrevende.
7. Finite state maskindekning
Finite state maskindekning er en viktig type testing, men også en av de vanskeligste måtene å oppnå høy kodedekning i white box testing. Den fungerer på designens funksjonalitet og krever at utviklere teller antall ganger en stat er besøkt eller transitert under testprosessen, samt hvor mange sekvenser hvert endelige statssystem inneholder.
8. Kontrollstrømtesting
Kontrollflyttesting er en hvit boks-testteknikk som søker å etablere utførelsesrekkefølgen til programmet ved å bruke en enkel kontrollstruktur.
Utviklere konstruerer testtilfeller for kontrollflyttesting ved å velge en spesifikk del av programmet og bygge en testbane. Kontrollstrømtesting brukes vanligvis i enhetstesting.
Livssyklusen til testing av hvit boks
innen programvareutvikling
White box-testing er et viktig skritt i programvareutviklingens livssyklus, selv om den ikke har en streng “plass” i syklusen.
Utviklere kan utføre white box-testing når og når de trenger å sjekke funksjonen til kode, og noen utviklere kan være grundigere enn andre med å sjekke nyskrevet kode for å sikre at den er ren og fri for unødvendige linjer.
White box-testing utføres imidlertid oftest under enhetstesting og integrasjonstesting. Både enhetstesting og integrasjonstesting utføres i utviklingsfasen av utviklere.
De skjer før funksjonstesting som systemtesting og aksepttesting finner sted, og de gir utviklere muligheten til å identifisere, lokalisere og fikse store feil tidlig i testfasen før de overleverer produktet til QA-teamet.
Manuelle eller automatiserte hvite boks-tester?
Som andre typer programvaretesting er det mulig å automatisere testing av hvite bokser. Det kan være enten manuelt eller automatisert, selv om det i de fleste tilfeller er enklere å automatisere testing av hvite bokser enn det er å automatisere testing av svart boks.
Fordi white box-testing er en veldig tidkrevende type testing, blir automatisering stadig mer populær blant programvareteam.
Manuell testing av hvit boks: fordeler, utfordringer og prosesser
Manuell testing av hvite bokser betyr å utføre hvite boks-tester manuelt, og det krever at utviklere har ferdighetene og tiden til å skrive individuelle testsaker for å teste hver linje med kode i en mulig programvarebygging. Dette kan ta mye tid, men det resulterer også i de mest grundige testresultatene og utgangene.
Noen av fordelene med å utføre white box-testing manuelt inkluderer:
1. Dybde
Manuell testing lar testere utforske programvarekode i større dybde enn automatisert testing hvis de velger det, for eksempel ved å lese gjennom all kildekoden til en applikasjon i stedet for bare å automatisere oppgaver som berører overflatefunksjonaliteten.
2. Feilplassering
Manuell testing gjør det enkelt å finne feil og defekter fordi utviklere skal kunne finne nøyaktig hvilken kodelinje feilen er til stede i.
For eksempel, å se at et bilde ikke lastes og deretter undersøke koden for linjer som involverer lasting av bilder, begrenser årsaken betydelig.
3. Hastighet
Manuell testing tar vanligvis lengre tid enn automatisert testing, men hvis utviklere ønsker å kjøre bare én eller to raske tester er det sannsynligvis raskere å utføre dem manuelt enn å sette opp automatisering.
For eksempel innebærer enhetstesting å se på en funksjon og se om den fungerer, i stedet for å samle inn enorme mengder data ved å automatisere prosessen. Imidlertid er det også ulemper med manuell testing av hvite bokser.
Noen av utfordringene med manuell testing av hvite bokser inkluderer:
1. Nøyaktighet
Manuell testing kan tillate utviklere å dekke et bredt spekter av kode, men menneskelige testere er alltid mer utsatt for feil og feil enn dataprogrammer, noe som betyr at manuell testing ofte anses som mindre nøyaktig enn automatisert testing.
2. Tid
Manuell testing tar lengre tid enn automatisert testing, og manuell testing av hvite bokser er noe av det mest tidkrevende av alle. Dette øker omløpstiden og kan gjøre det vanskeligere å overholde stramme utviklingsfrister.
3. Kostnad
På grunn av mengden arbeidskraft og ressurser som er involvert i manuell testing av hvite bokser, er dette ofte mer kostbart for utviklingsteam enn automatisert testing, som vanligvis krever færre utviklere og mindre tid.
4. Skalerbarhet
Manuell testing er egentlig bare egnet for bruk ved testing av små applikasjoner eller testing av individuelle komponenter i større applikasjoner. For større applikasjoner som en skybasert database med tusenvis av innganger per minutt, er automatisert testing mye foretrukket som en metode for å simulere standardbelastninger.
Automatisert testing av hvite bokser: fordeler,
utfordringer og prosesser
Automatiseringsteknologi gjør det enklere å automatisere aspekter ved programvaretesting hver dag. Bransjens bevegelse mot hyperautomatisering skyldes delvis effektiviteten og kostnadsbesparelsene som automatisering tilbyr utviklingsteam som alltid føler seg tett presset.
White box er en av de mest hensiktsmessige og passende typene testing for automatisering fordi den er relativt enkel å automatisere og tids- og kostnadsbesparelsene med white box testautomatisering kan være betydelige.
Automatisert white box-testing kan innebære at utviklere skriver testskript selv, eller prosessen kan fremskyndes med bruk av fullstack-verktøy som ZAPTEST, som gir toppmoderne ende-til-ende programvaretestingsteknologi .
Noen av fordelene med å automatisere white box-testing inkluderer:
1. Nøyaktighet
Databasert testing eliminerer risikoen for feil fordi datamaskiner ikke blir slitne eller gjør feil.
2. Tid
Automatisk testing av hvite bokser er betydelig raskere enn manuell testing av hvite bokser og frigjør tid som utviklere kan bruke på andre oppgaver, for eksempel feilretting eller skriving av oppgraderingsoppdateringer.
3. Skala
Automatisert testing skalerer opp mye bedre enn manuell testing, så hvis programvareapplikasjonen din vokser eller hvis du vil utføre storskala testing på en gang, er automatisering det bedre alternativet.
For eksempel innebærer oppskalering av dataregistrering å be om flere inndata i automatisering, sammenlignet med å ansette flere ansatte i manuelle tester.
4. Kostnad
Kostnaden for automatisert testing er vanligvis, når den er samlet, lavere enn kostnaden for manuell testing på grunn av antall arbeidstimer spart ved automatisering. ZAPTESTs 10x ROI demonstrerer hvordan automatisering kan spare utviklere penger og føre til høyere avkastning. Automatisering er imidlertid ikke uten ulemper.
Noen av utfordringene med å automatisere white box-testing inkluderer:
1. Feilsporing
Automatisering gjør det ikke alltid lett å finne feil i kode avhengig av hvordan utviklere automatiserer tester eller hvilke testverktøy som brukes, spesielt sammenlignet med manuell testing av hvite bokser hvor testere kan se koden som kjøres hver gang en feil dukker opp.
2. Ferdigheter
Ikke alle utviklere vet hvordan man automatiserer tester eller hvordan man bruker automatiserte testverktøy, så overgang til automatisering kan kreve en viss investering i å trene opp store ferdigheter som koding på den spesifikke testplattformens språk og bruk av dataanalyseferdigheter for å forstå årsaken til problemer i en hvit boks test.
Konklusjon: Manuell testing av hvit boks
eller white box test automatisering?
Samlet sett er testing av hvite bokser i programvareteknikk en av de mest hensiktsmessige testtypene for å tilpasse seg automatisert testing, hovedsakelig på grunn av den tidkrevende og komplekse naturen til manuell testing av hvite bokser.
Automatisert white box-testing er raskere, billigere, mer effektiv og mer nøyaktig enn manuell testing, spesielt når du arbeider med større applikasjoner.
Der det er mulig, bør programvareutviklere automatisere white box-testing i programvaretesting for å øke påliteligheten til testene og dekke et større område med større applikasjoner gjennom testing enn det som er praktisk mulig når man utfører tester manuelt. Dette skyldes de betydelige kostnadene og ekspertisen som kreves når du gjennomfører white box-tester med utelukkende manuelle metoder.
Hva trenger du for å starte
hvit boks testing?
Før du begynner testing av hvite bokser, sørg for at du har alt du trenger for å komme i gang. Avhengig av om du utfører manuell eller automatisert white box-testing, trenger du ikke mye ressurser i tillegg til tid og penger.
Du må imidlertid sørge for at teamet ditt har den riktige kunnskapen og verktøyene for å kunne utføre white box-testing på riktig måte.
1. En forståelse av kildekoden
White box-testing er testing av programvareutviklere og ingeniører med full arbeidskunnskap om kildekoden og den interne strukturen til programvaren.
Hvis du er en QA-tester uten denne kunnskapen, må du gi programvaren videre til noen andre før testing av hvite bokser kan begynne.
2. Testtilfeller
Det er nødvendig å skrive testtilfeller før du utfører white box-testing. Testtilfeller er individuelle sett med instruksjoner som beskriver handlinger som testere eller utviklere kan utføre for å teste funksjonene og virkemåten til et system.
I white box-testing er testcases designet av personer med fullstendig kunnskap om den interne strukturen i systemet og opprettet for å verifisere om dette fungerer slik det skal.
3. Testverktøy for hvit boks
Det er mange verktøy tilgjengelig for white box-testing som støtter tilgang til kildekode og designdokumenter ved siden av å fullføre testautomatisering. Disse kommer også til et utvalg av prispunkter for brukere, for eksempel ZAPTEST FREE og ZAPTEST ENTERPRISE versjoner som gir mer fleksibilitet.
Velg verktøyene du vil bruke før du begynner å teste, med vekt på å sikre at den har riktig funksjonalitet, for eksempel drift på tvers av plattformer og Computer Vision-teknologi , slik at du ser hva automatiserte tester ser.
Sørg for at alle utviklerne og ingeniørene som er involvert i testingen vet hvordan og når de skal brukes.
Testprosessen for den hvite boksen
White box-testing innebærer mye mer kunnskap om hvordan et system fungerer enn black box-testing, og noen av trinnene i white box-testing er litt annerledes.
White box-testere må først identifisere funksjonene eller komponentene i systemet som de ønsker å verifisere før de plotter mulige baner for å teste og skrive testtilfeller som skal utføres.
Testprosessen for hvit boks kan også variere avhengig av hvilken testteknikk for hvit boks du bruker. Følg trinnene nedenfor for å finne ut hvordan du utfører white box-testing mens du maksimerer banedekning.
Trinn 1: Identifiser funksjonene som skal testes
Før du utfører white box-testing, vurder nøyaktig hva du vil teste og hvordan du skal teste det. Dette innebærer vanligvis å fokusere på et lite sett med funksjoner eller funksjoner og lage et sett med testtilfeller bare for å teste disse.
Du vil utføre dette trinnet igjen og igjen for ulike områder av systemet for å maksimere testdekningen, men det er viktig å dele opp ulike områder i individuelle tester.
Jo smalere fokus du har, desto mer pålitelige og nøyaktige kan testene dine være.
Trinn 2: Plott alle mulige baner i en flytgraf
En betydelig del av forberedelsesarbeidet for white box-testing er å plotte alle mulige stier du trenger for å teste i en flytgraf.
Dette trinnet kan hjelpe deg med å maksimere banedekningen og sikre at du verifiserer alle mulige stier i hver testcase du oppretter. Tegn en flytgraf som dekker alle mulige baner for hver funksjon eller komponent du tester, for eksempel ved å skissere forskjellige baner som oppstår når forskjellige verdier legges inn.
Trinn 3: Identifiser alle mulige veier
Se på flytdiagrammet ditt og identifiser alle mulige veier som brukere kan ta, fra det første trinnet i flytdiagrammet ditt til det siste trinnet.
Jo flere grener og avgjørelser som vises i flytdiagrammet, desto flere unike veier vil det eksistere. Å forstå hvor mange unike mulige veier som finnes, kan hjelpe deg med å sikre at testsakene dine dekker hver mulighet.
Trinn 4: Lag testcases
Den neste fasen av testing av hvite bokser er å skrive testtilfeller som bekrefter alle banene du har identifisert ovenfor.
Det er viktig å sørge for at testsakene dine dekker alle mulige veier og tydelig skisserer handlingene som testere eller utviklere må ta for å utføre hver testsak.
For hvert testtilfelle, inkludere en testcase-ID og navn ved siden av en kort beskrivelse samt forventede resultater av hver test.
Trinn 5: Utfør testsaker
Det er nå på tide å utføre testsakene, som er det de fleste anser for å utføre den hvite boks-testingen selv.
Testere utfører testtilfellene ved å følge det korte settet med instruksjoner som er skissert i hvert testtilfelle og rapportere utfallet av hver testtilfelle. Dette kan sammenlignes med de forventede resultatene som er skissert i testtilfellet for å finne ut om hver white box-test har bestått eller ikke bestått.
Trinn 6: Gjenta syklusen etter behov
Som andre former for programvaretesting handler white box-testing om å sammenligne hvordan systemet faktisk fungerer med forventningene testerne har til hvordan systemet skal fungere.
Hvis testere finner ut at systemet ikke oppfører seg slik de forventer, kan dette bety at testingen av den hvite boksen har mislyktes, og utviklere må korrigere kodelinjer før de utfører videre testing.
Gjenta prosessen ovenfor for å utføre ytterligere testing av hvit boks til systemet er grundig testet og eventuelle feil er fikset.
Beste praksis for testing av hvite bokser
Beste praksis for testing av hvite bokser avhenger av hvilken type testing du utfører og hvilket stadium av testprosessen du er i.
Siden det meste av testingen av hvite bokser finner sted under enhetstesting og integrasjonstesting, gjelder de fleste beste praksiser for testing av hvite bokser for disse fasene.
1. Maksimer testdekningen
Per definisjon er det viktig å maksimere testdekningen når du utfører white box-testing for å sikre at en høy prosentandel av programvaren testes i denne fasen.
Du kan gjøre dette ved å maksimere veidekning og filialdekning og skrive testcaser som utforsker alle mulige veier og utfall under forberedelsesstadiet.
2. Verifiser atferd og ytelse
Når du skriver testcaser i white box-testing, vil du lage testcases som bekrefter at systemet fungerer slik du forventer at det skal, samt testcases som bekrefter ytelsen til systemet .
For eksempel, i tillegg til å sjekke at bestemte handlinger fører til bestemte resultater, kan du også verifisere hvor raskt systemet kan utføre visse oppgaver eller hvordan ytelsen påvirkes av forskjellige variabler.
3. Skriv testcaser uavhengig av hverandre
Hvis du vil verifisere to distinkte funksjoner, for eksempel hvis en kodeklasse avhenger av en bestemt database, lag et abstrakt grensesnitt som gjenspeiler denne databaseforbindelsen og implementer et grensesnitt med et falskt objekt for å teste denne forbindelsen.
Dette sikrer at testsakene dine bekrefter forbindelsene du vil at de skal verifisere i stedet for noe annet.
4. Dekk alle stier og løkker
Maksimering av testdekning betyr å dekke alle mulige baner, vurdere betingede løkker og andre typer løkker i koden.
Sørg for at du designer testcaser som fullt ut utforsker mulige veier og verifiser at løkker oppfører seg slik du forventer at de skal gjøre, uansett hva slags input.
7 feil og fallgruver når
Implementering av White Box-tester
Når du begynner testing av hvite bokser, er det viktig å være klar over noen av de vanligste fallgruvene som utviklere ofte havner i når de utfører testing av hvite bokser. Vanlige testfeil i hvite bokser kan forårsake forsinkelser og unøyaktigheter som kan skade kvaliteten og tidsplanen for programvareutgivelsen.
1. Tenker at white box testing ikke er nødvendig
Noen testere mener at testing av hvite bokser ikke er nødvendig, fordi testing av svart boks tester alle eksterne utganger til programvaren, og hvis disse fungerer som de skal, er antagelsen at den interne funksjonen til systemet også fungerer.
White box-testing kan imidlertid hjelpe utviklere med å finne problemer og feil som kanskje ikke alltid dukker opp i black box-testing, og det er viktig å verifisere sikkerheten til programvaresystemer.
For eksempel, hvis et program har en minnelekkasje som forårsaker ytelsesforringelse over lengre perioder som black box-testing ikke undersøker, er white box-testing det eneste alternativet for å finne koden og finne problemet før en bred offentlig utgivelse.
2. Utføre all testing av hvite bokser manuelt
Noen utviklere tror kanskje at det er like enkelt å utføre white box-testing som det er å utføre black box-testing.
White box-testing er imidlertid betydelig mer tidkrevende og utviklere som prøver å utføre white box-testing helt manuelt, kan oppleve at det er umulig å utføre manuelle kontroller til de ønskede standardene eller samtidig maksimere testdekningen.
3. Tildeling av testere til å utføre testcases
White box-testing bør utføres fullstendig av utviklere, programvareingeniører og folk som forstår den indre funksjonen til programvaresystemet fullstendig.
Noen utviklere tror at de kan sende white box-testing til QA-testere når de har skrevet testsakene selv, men dette vil bare resultere i dårlig utførelse og redusere kvaliteten på dokumentasjonen .
4. Hastende gjennom testing
Programvaretesting er en lang og tidkrevende prosess, og noen utviklere kan bli fristet til å haste gjennom white box-testing for å gå videre til neste utviklingsfase. Det er viktig å allokere nok tid og ressurser til white box-testing for å sikre at utviklere ikke føler seg forhastet og at de har nok tid til å maksimere testdekningen.
5. Dårlig dokumentasjon
Oppbevaring av riktig dokumentasjon før, under og etter testing sikrer at alle som er involvert i programvareutvikling og testing har tilgang til riktig informasjon til rett tid.
Sørg for at hvert medlem av utviklingsteamet vet hvordan man skriver tydelig dokumentasjon og hvordan man rapporterer resultatene av white box-testing.
6. Feil bruk av automatiseringsverktøy
Automatiseringsverktøy kan gjøre det enkelt å utføre white box-testing, men det er viktig å sørge for at hele teamet ditt forstår hvilke automatiseringsverktøy du bruker og hvordan de skal brukes.
Ulike verktøy er egnet for ulike typer testing, så det er viktig å velge automatiseringsverktøy som er egnet for testing av hvite bokser og lære hvordan du bruker funksjonene på riktig måte.
Noen verktøy integrerer for eksempel ikke automatisering og fokuserer i stedet på informasjonsinnhenting og billettorganisering, noe som langt fra er ideelt for automatisert testing. Tvert imot, fullstack-verktøy som ZAPTEST dekker hele testprosessen gjennom funksjoner som Any Task Automation, noe som gjør dem passende for mer effektivt testarbeid med hvit boks.
7. Arbeider ikke med QA-teamet
Bare fordi white box-testing planlegges og utføres av utviklere, betyr ikke dette at QA-teamet ikke skal være involvert på noen måte.
Det er viktig å videreformidle resultatene av white box-testing til QA-teamet slik at de forstår hva som har blitt testet så langt og hvordan resultatene av white box-testing kan påvirke måten QA-teamet nærmer seg black box-testing.
Ved å unnlate å involvere QA-teamet introduserer du en potensiell frakobling mellom ulike avdelinger, noe som fører til dårlig kommunikasjon og dårligere tilbakemeldinger senere i testingen. Sluttproduktet av dette er et betydelig lavere kvalitetsnivå i sluttproduktet.
Typer utganger fra tester med hvit boks
Når du utfører white box-programvaretesting, vil du motta ulike utdata avhengig av resultatene av testene du utfører. Å forstå disse utdataene fra tester med hvite bokser kan hjelpe deg med å forstå hvilke trinn du bør ta videre.
1. Testresultater
Testresultatene fra white box-testene dine vil fortelle deg om du må fortsette med videre testing, om det er feil som må fikses, og om hver enkelt testtilfelle har bestått eller mislyktes. Grundig dokumentasjon er nødvendig fordi det hjelper utviklere og testere å forstå resultatene av testing av hvite bokser.
2. Defekter
Defekter kan identifiseres i white box-testing, og noen ganger vil resultatet av white box-testene være defekter og feil.
Hvis programvaresystemet ikke oppfører seg som du forventer under testing av hvite bokser, kan dette tyde på at det er alvorlige feil med programmet som må repareres før utvikling og testing fortsetter.
3. Testrapporter
Testrapporter er rapporter satt sammen av utviklere og testere under og etter programvaretesting.
De inneholder detaljer om resultatene av testen, inkludert hvilke testtilfeller som bestod og mislyktes, eventuelle defekter som ble funnet under testing, og anbefalinger for de neste trinnene.
Utviklere bruker testrapporter for å kommunisere med andre utviklere hvis oppgave det kan være å fikse feil og feil funnet under testing.
Eksempler på hvite boks-tester
White box-testing gjør det mulig for utviklere å sjekke at den interne strukturen til programvaresystemet fungerer som den skal, uavhengig av eksterne resultater og utganger fra systemet.
Eksemplene nedenfor illustrerer hvordan white box-testing kan hjelpe utviklere med å verifisere programvarens interne funksjoner.
1. Eksempel på registreringsside for e-handel
Et eksempel på testing av hvite bokser tar for seg hvordan utviklere tester nettsidens funksjoner. Hvis du prøver å teste registreringssiden til et e-handelsnettsted, kan white box-testing tillate utviklere å forstå om funksjonene og klassene som er involvert i registreringen fungerer slik de skal når registreringsfunksjonen utføres.
Dette inkluderer spesifikt all informasjon som en bruker legger inn og vurderer parameterne bak skjemaet, inkludert datoene som er og ikke er gyldige og hva skjemaet ser på som en legitim e-postadresse.
Teamet går deretter inn i en serie strenger som tester skjemaet, med noen designet for å mislykkes og andre designet for å lykkes, før de vurderer resultatene mot de forutsagte resultatene.
Black box-testing vil derimot kun sjekke om selve siden fungerer, uten noen nærmere analyse av hvorfor eller hvordan.
2. Eksempel på kalkulator
Applikasjonskalkulatorer gir et annet eksempel på testing av hvit boks.
Hvis du lager en kalkulator som brukes som en del av en applikasjon, vil black box-testere ganske enkelt teste om kalkulatorens utdata er riktig når de bruker kalkulatoren etter hensikten.
White box testere vil sjekke kalkulatorens interne beregninger for å verifisere hvordan utgangen ble beregnet og om dette er riktig. Dette er mer nyttig for mer komplekse beregninger med flere stadier, for eksempel avgifter. Testere undersøker koden for å se trinnene som kalkulatoren tar og rekkefølgen trinnene er i, før de ser resultatet etter hvert trinn.
Hvis kalkulatorens inngang er (7*4) – 6 og utgangen er 22, er dette riktig, og svartbokstesting vil bestå denne testen. Dette er imidlertid fordi 7*4 = 28, og 28 – 6 er 22. White box-testing kan avsløre at programvaren fant dette resultatet ved å utføre 7*4 = 32 og 32 – 6 = 22, ingen av disse er riktige.
Denne større innsikten viser at beregningen er nøyaktig etter hvert bestemt trinn, finner stadiet der det kanskje ikke er nøyaktig, og løser det raskere ettersom testeren tydelig kan se hvor problemet finner sted.
Typer feil og feil i testing av hvit boks
Under testing av hvite bokser er det mulig å identifisere og lokalisere feil som kan påvirke måten systemene fungerer under panseret. Disse feilene kan påvirke eksterne funksjoner eller de kan påvirke ytelse eller pålitelighet.
Noen av de vanligste typene feil og feil som oppstår under testing av hvite bokser er listet opp nedenfor.
1. Logiske feil
Logiske feil oppstår i white box testing fordi white box tester viser områder hvor programmet ikke fungerer logisk eller hvor funksjoner og betingelser misbrukes innenfor programvarens kode.
Logiske feil kan oppstå som systemfeil eller ganske enkelt resultere i uventet oppførsel og utdata.
2. Designfeil
White box-testing kan hjelpe utviklere med å identifisere designfeil i koden. Designfeil oppstår når det er en forskjell mellom den logiske flyten av programvaren og den faktiske implementeringen av programvaren. De kan resultere i uventet atferd og ytelsesfeil.
3. Typografiske feil
Typografiske feil og syntaksfeil er feil som oppstår på grunn av menneskelige feil – for eksempel fordi en utvikler har skrevet feil i en bestemt setning eller lagt til feil tegnsetting i en kodelinje. Små feil som dette kan resultere i ødelagte funksjoner og utsagn som programvaren ikke kan lese, noe som kan forårsake store feil i systemet.
Vanlige testberegninger for hvit boks
Når du utfører white box-testing, kan vanlige testberegninger hjelpe deg med å måle hvor vellykkede og omfattende white box-testene dine er, samt forstå kvaliteten på utviklernes arbeid.
Testmålinger informerer utviklingsprosessen fordi de kan identifisere områder for forbedring eller veilede testprosessen fremover.
1. Kodekning
En av de primære egenskapene til testing av hvite bokser er at den skal dekke så mye av koden som mulig, og du kan måle hvor mye kode du har dekket med kodedekningsverdier.
Kodedekningsberegninger viser hvor mye av applikasjonens totale kode du har verifisert ved hjelp av white box-testing. Vanligvis tar utviklere sikte på å dekke så nær 100 % av programvarekoden som mulig gjennom white box-testing.
Kodedekning kan deles inn i distinkte beregninger, inkludert bane, segment, uttalelse og grendekning.
Sammensatt tilstandsdekning er en annen type kodedekningsmetrikk som kontrollerer at hver tilstand i et sett har blitt sjekket sammen med flere baner og kombinasjoner av baner.
2. Defektberegninger
Defektberegninger gjenspeiler hvor mange defekter som er funnet, hvor god white box-testing er til å identifisere defekter, og hvor mange prosentandeler av koden som består eller mislykkes white box-testing.
Defektberegninger kan presenteres som antall defekter per tusen linjer med kode eller antall totale defekter i programmet. Selv om et lavt antall defekter kan virke positivt, må utviklere sørge for at dette ikke er fordi defekter blir savnet i testingen.
3. Testutførelse
Testutførelsesmålinger kan hjelpe utviklere raskt å se hvor stor andel av de totale testene som er utført så langt, og hvor mange ikke-utførte tester som gjenstår. Tekstutførelsesmålinger hjelper programvareteam med å forstå hvor langt fremdriften i white box-testingen er, og hvorvidt automatiserte programvaretester kjører som forventet.
Det er imidlertid mulig å ha både falske positive og falske negative som kan påvirke nøyaktigheten til denne beregningen.
4. Testvarighet
Testvarighetsmålinger forteller oss hvor lang tid det tar å kjøre automatiserte tester, noe som er spesielt viktig i white box-testing fordi automatisering er avgjørende for å maksimere testeffektiviteten og testdekningen.
Testvarighet er ofte en flaskehals i smidig programvareutvikling, så å forstå hvor lang tid programvaretester tar å kjøre kan hjelpe utviklingsteamene med å fremskynde utviklingsprosessen.
Det er imidlertid viktig å huske at testvarighetsmålinger ikke forteller deg noe om kvaliteten på testene du kjører.
Hvit boks testverktøy
Verktøy og teknologi kan gjøre testing av hvite bokser betydelig mer nøyaktig, effektiv og omfattende. White box testverktøy kan hjelpe programvareingeniører med å automatisere white box testing, registrere og dokumentere white box testprosessen og administrere white box testing fra start til slutt.
5 beste gratis testverktøy for hvit boks
Hvis du ikke vil investere i dyre testverktøy for hvite bokser ennå, kan du prøve en hel rekke gratis testverktøy for hvite bokser på nettet uten å betale noe.
Gratis testverktøy tilbyr ikke alltid den samme funksjonaliteten som bedriftsverktøy, men de er et godt startpunkt for nybegynnere til white box-testing, og de kan hjelpe utviklingsteam med å få en større forståelse av hvilke verktøy og teknologier de trenger. .
1. ZAPTEST GRATIS utgave
ZAPTEST er et programvaretestingsverktøy og robotisert prosessautomatiseringsprogramvare som lar utviklere og QA-testere automatisere både white box-testing og black box-testing.
ZAPTESTs gratisversjon gir mulighet for flere virtuelle brukere, flere iterasjoner og brukerforumstøtte. Applikasjonen fungerer med både lokale og eksterne datakilder og integreres med HP ALM, Rally og JIRA. Brukere som liker ZAPTESTs gratistilbud og ønsker å se mer av hva selskapet tilbyr, kan også spørre om oppgradering til enterprise-utgaven når de er klare.
2. Bugzilla
Bugzilla er et veldig populært testverktøy med åpen kildekode som lar utviklere spore feil og defekter i programvaren og administrere livssyklusen til feil.
Bugzilla gjør det enkelt å tilordne feil til utviklere, prioritere og verifisere feil, og lukke dem når de er fikset. Bugzilla er et flott verktøy for team som fortsatt prøver å standardisere sin tilnærming til feilrapportering, og det er helt gratis å bruke.
3. OpenGrok
OpenGrok er en åpen kildekodeleser og søkemotor for kodebase. Den er kompatibel med kode skrevet i Java C++, JavaScript og Python sammen med andre programmeringsspråk.
Hvis du ønsker å kunne navigere i en stor kodebase raskt under testing av hvite bokser, er OpenGrok helt gratis og enkel å bruke.
4. SQLmap
SQLmap er et annet åpen kildekodeverktøy som anses som nesten essensielt i white box-testing. SQLmap regulerer flyten av å utnytte og oppdage SQL-injeksjonsfeil.
SQLmap, som er et selvbeskrevet ‘penetrasjonstestverktøy’, kan hjelpe white box-testere med å identifisere og lokalisere sikkerhetsfeil i kildekoden og fikse disse før de går videre.
5. Emma
Emma er et verktøysett med åpen kildekode som kan måle kodedekningen din hvis du jobber i Java. Det er en superrask måte å finne kodedekningen din raskt og spore hvor mye kode hvert medlem av utviklingsteamet har dekket på individuell basis.
Emma støtter klasse-, metode-, linje- og grunnleggende blokkdekning, og den er fullstendig Java-basert.
5 Beste Enterprise white box testverktøy
Hvis du ser etter verktøy som tilbyr større funksjonalitet eller bedre støtte, kan det hende at verktøy for testing av hvite bokser passer bedre for utviklingsteamet ditt.
1. ZAPTEST ENTERPRISE-utgaven
ZAPTESTs enterprise-utgave er den suppede versjonen av gratis ZAPTEST. I denne versjonen kan brukere dra nytte av ubegrensede OCR-maler, ubegrensede iterasjoner og ubegrensede VBScript- og JavaScript-skript.
ZAPTESTs enterprise-utgave tilbyr en mer komplett pakke med verktøy for utviklingsteam som ønsker å bytte til automatisering, og enterprise-versjonen kommer også med ekspertstøtte for å sikre at teamet ditt får mest mulig ut av ZAPTESTs programvaretestingsautomatisering og RPA-teknologi .
2. Spelemann
Fiddler er en pakke med verktøy fra Telerik som er laget for white box -testing av webapplikasjoner . Fiddler kan logge all HTTP-trafikk mellom systemet ditt og internett og evaluere angitte bruddpunkter samt justere utgående og innkommende data. Den er tilgjengelig i forskjellige formater avhengig av budsjett og krav, så det er en Fiddler-utgave for nesten alle lag.
3. HP Fortify
HP Fortify, tidligere kjent som Fortify, er et annet sikkerhetstestingsverktøy som tilbyr omfattende sikkerhetsløsninger for white box-testing. Fortify-verktøypakken inkluderer Fortify kildekodeanalyseverktøyet, som automatisk skanner kildekoden din for sårbarheter som kan gjøre applikasjonen åpen for nettangrep.
4. ABAP-enhet
Enterprise-versjonen av ABAP Unit gjør det mulig for programvareutviklere å utføre både manuell og automatisert enhetstesting raskt og enkelt. Utviklere skriver enhetstester i ABAP-applikasjonen og bruker disse testene til å verifisere kodefunksjoner og identifisere feil i enhetstesting.
Programvareteam som ønsker å prøve dette verktøyet kan starte med gratisversjonen av ABAP Unit før de går videre til enterprise-utgaven.
5. LDRA
LDRA er en proprietær pakke med verktøy som kan brukes til erklæringsdekning, grendekning og beslutningsdekning når du utfører testing av hvit boks. Det er et utmerket verktøy hvis du vil sjekke at kildekoden din oppfyller standardkrav for overholdelse, sporing og kodehygiene.
Når bør du bruke bedrift
vs freemium white box testverktøy?
Både enterprise- og freemium-programvaretestingsverktøy har sin plass i ethvert moderne programvareutviklingsteam. Etter hvert som teamet ditt vokser og automatisert testing blir viktigere for din white box-testmetode, vil du sannsynligvis ønske å oppgradere fra å jobbe primært med gratis testverktøy til å jobbe med bedriftsverktøy som tilbyr mer funksjonalitet og ubegrenset bruk.
Det er imidlertid spesifikke scenarier der freemium-verktøy kan være mer egnet enn bedriftsverktøy.
Mange utviklere velger å starte med freemium-verktøy når de eksperimenterer med nye funksjoner og teknologier, først og fremst for å vurdere om disse teknologiene passer godt for teamet deres før de investerer i bedriftsteknologier.
Du kan også prøve ut gratisversjoner av bedriftsverktøy som ZAPTEST, slik at du kan prøve dem før du kjøper og finne ut mer om hva bedriftsverktøy tilbyr.
Til slutt, noen freemium-verktøy som Emma og Bugzilla spesialiserer seg på nisje, men viktige funksjoner som tilbyr kontinuerlige fordeler selv for programvareteam som er forberedt på å betale for bedriftsteknologier.
White box testing: sjekkliste, tips og triks
Når du er klar til å utføre white box-testing, sørg for at du har alt du trenger før du begynner. Nedenfor er en liste over ting du bør huske før du starter testing av hvite bokser for å maksimere testdekningen og forbedre nøyaktigheten av testresultatene for den hvite boksen.
1. Bruk automatiseringsverktøy
Automatiseringsverktøy kan øke hastigheten på prosessen med å utføre white box-testing, samt redusere feilfrekvensen og øke den totale nøyaktigheten.
Nesten alle programvareteam bruker i dag et visst nivå av automatisering for å utføre white box-testing, så å eksperimentere med ulike automatiseringsverktøy og teknologier før du begynner white box-testing kan hjelpe deg med å velge verktøyene du vil bruke før testingen starter.
2. Sikt på 100 % testdekning
Du vil sannsynligvis ikke nå målet ditt om 100 % testdekning, men å sikte på å komme så nær dette tallet som mulig er best når du utfører white box-testing.
Bruk testdekningsverktøy for å spore og måle individuelle beregninger som banedekning og grendekning og sikre at alle de viktigste banene og grenene i programvaren din har blitt dekket under testing av white box.
3. Lag klare testrapporter
Som tilfellet er med andre former for programvaretesting, sørg for at teamet ditt vet hvordan det skal kompilere nøyaktige og tydelige testrapporter etter at hver fase av testingen har funnet sted.
En testrapport bør skrives i et lettfattelig format og inneholde detaljer om testtilnærmingen samt et sammendrag av utdataene og resultatene fra hver testcase som utføres. Sluttrapporten bør begrunne trinnene som er tatt og gi anbefalinger for neste trinn.
4. Mål suksessen din med testberegninger
Testmålinger hjelper programvareteam med å spore og registrere fremdriften til testing av hvite bokser og tilby verdifull informasjon som kan informere fremtidige utviklingsprosesser.
Det er viktig at utviklere bruker beregninger for å forstå hvor effektiv testingen de utfører er og hvor ren den opprinnelige koden deres var, slik at de kan forbedre arbeidet sitt i fremtiden.
Hvit boks testing:
Konklusjon
White box-testing i programvareteknikk er en viktig type programvaretesting som verifiserer den interne strukturen og logikken til en programvareapplikasjons kildekode.
I forbindelse med testing av svart boks, fastslår testing av hvit boks ikke bare at programvaren fungerer som forventet, men at den interne koden er logisk, ren og fullstendig.
White box-testing utføres oftest i enhetstesting og integrasjonstesting, og det utføres alltid av utviklere og programvareingeniører med fullstendig kunnskap om programvarens interne kode.
Mens noen tester av hvite bokser kan utføres manuelt, er mye av testing av hvite bokser i dag automatisert på grunn av forbedringene i hastighet, effektivitet og dekning som automatisering av test av hvite bokser tilbyr.
Vanlige spørsmål og ressurser
Hvis du vil lære mer om testing av hvite bokser, er det mange gratis nettressurser du kan konsultere. Du kan bruke videoer, bøker og andre ressurser til å lære deg selv hvordan du utfører testing av hvite bokser og sikre at standardene for testing av hvite bokser følger beste praksis.
1. De beste kursene i white box test automatisering
Hvis du vil lære mer om white box test automatisering, kan du ta et kurs i programvaretesting og white box testing. Noen av disse kursene er akkreditert og tilbyr formelle kvalifikasjoner, mens andre er uformelle nettkurs designet for å hjelpe utviklere og programvaretestere som ønsker å forbedre kunnskapen om et bestemt emne.
Noen av de beste testkursene for hvite bokser tilgjengelig på nettet i dag inkluderer:
2. Hva er de fem beste intervjuspørsmålene om white box test automatisering?
Hvis du forbereder deg til et intervju hvor du kan diskutere white box-testing, white box-teknikker og automatiseringsverktøy, er det viktig at du vet det.
- Hva er forskjellen mellom testing av hvit boks og testing av svart boks?
- Hvorfor er testing av hvit boks viktig?
- Hva er noen av de forskjellige tilnærmingene du kan ta for testing av hvite bokser?
- Hvilke prosesser er involvert i white box-testing og hvordan kan vi forbedre dem?
- Hva er noen av verktøyene og teknologiene du kan bruke for å gjøre testing av white box raskere eller mer nøyaktig?
3. De beste YouTube-veiledningene om testing av hvite bokser
Hvis du vil lære mer om testing av hvite bokser, kan du se YouTube-veiledninger for å forstå hvordan testing av hvite bokser fungerer og å se visuelle forklaringer på prosessene og tilnærmingene som er involvert i testing av hvite bokser.
Noen av de mest informative YouTube-veiledningene på nettet inkluderer nå:
- Udacity: White Box Testing Eksempel
- Guru99: Hva er White Box-testing?
- White Box vs Black Box-testing
- Testteknikker for hvit boks
- Software Testing Mentor: Hva er White Box Testing?
4. Hvordan vedlikeholde white box tester
Vedlikehold av programvaretest sikrer at testene du kjører gang på gang er grundige og tilpasset formålet. Det er viktig å vedlikeholde alle typer programvaretester i både blackbox- og whitebox-testing fordi koden du utfører tester på, endres konstant med hver feilreparasjon og iterasjon. Dette betyr at testskriptene dine må endres sammen med det.
Vedlikehold av white box-tester innebærer å holde testautomatiseringsrammeverket oppdatert og håndheve prosesser designet for å sikre at tester og testsaker oppdateres regelmessig.
Du kan gjøre dette ved å:
Byggvedlikehold i testdesignet ditt:
Å vurdere fremtiden for testing av hvite bokser når du først bygger og designer dine tester for hvite bokser, vil gjøre det lettere å vedlikeholde tester i fremtiden.
Aktiver tydelig kommunikasjon mellom teamene:
Sørg for at alle medlemmene i utviklingsteamet ditt har flere kommunikasjonskanaler, slik at så snart endringer er gjort i koden, kan disse raskt gjenspeiles i tester.
Vær tilpasningsdyktig:
Noen ganger kan du gjøre endringer i koden du ikke har planlagt. Sørg for at teamet ditt vet hvordan de skal tilpasse seg disse endringene raskt og har ferdighetene til å følge disse endringene opp i testing.
Revurder testprotokoller kontinuerlig:
Testprotokollene du implementerte ved starten av testen er kanskje ikke egnet når programvaren din har gjennomgått ulike endringer og forbedringer. Evaluer testprotokollene dine på vanlige stadier for å bekrefte om de fortsatt passer godt.
5. De beste bøkene om testing av hvite bokser
White box-testing er et dypt emne som kan ta år å mestre. Hvis du ønsker å bli en ekspert på moderne white box-testing i programvaretesting, kan du lese bøker om white box-testing skrevet av utviklere, akademikere og ingeniører.
Noen av de beste bøkene om testing av hvite bokser og testautomatisering i dag inkluderer:
- The Art of Software Testing, tredje utgave av Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas
- Software Testing: A Craftsman’s Approach, fjerde utgave, av Paul C. Jorgensen
- How to Break Software: A Practical Guide to Testing av James Whittaker
- The Just Enough Software Test Automation av Dan Mosley og Bruce Posey
Du bør kunne finne disse bøkene i enkelte bokhandlere og biblioteker samt på nettet. Du kan også finne annet lesemateriell og læringsressurser i leselistene over gode kurs og programmer for programvaretesting.
