Test af hvid boks
White Box Testing er softwaretestteknik, hvor intern struktur, design og kodning af software testes for at verificere strømmen af input-output og for at forbedre design, brugervenlighed og sikkerhed. Ved testning af hvid boks er kode synlig for testere, så den kaldes også Clear box-test, Open box-test, Transparent box-test, Kodebaseret test og Glassbox-test.
Det er en af to dele af Box Testing tilgang til softwaretest. Dens modstykke, Blackbox-test, involverer test fra et eksternt eller slutbrugerperspektiv. På den anden side er testning af hvidboks i softwareteknik baseret på en applikations indre funktion og drejer sig om intern test.
Udtrykket "WhiteBox" blev brugt på grund af det gennemsigtige boksekoncept. Den klare boks eller navnet WhiteBox symboliserer evnen til at se gennem softwarens ydre skal (eller "boks") ind i dens indre funktion. Ligeledes symboliserer den "sorte boks" i "Black Box Testing" ikke at kunne se softwarens indre funktion, så kun slutbrugeroplevelsen kan testes.
I denne testvejledning til hvid boks lærer du -
- Hvad er White Box Testing?
- Hvad bekræfter du i White Box Testing?
- Hvordan udfører du White Box Testing?
- Eksempel på test af WhiteBox
- Hvid boks testteknikker
- Typer af test af hvide kasser
- White Box testværktøjer
- Fordele ved White Box Testing
- Ulemper ved WhiteBox-test
Hvad bekræfter du i White Box Testing?
White box-test involverer testning af softwarekoden for følgende:
- Interne sikkerhedshuller
- Ødelagte eller dårligt strukturerede stier i kodningsprocesserne
- Strømmen af specifikke indgange gennem koden
- Forventet output
- Funktionaliteten af betingede sløjfer
- Test af hver sætning, objekt og funktion på individuel basis
Testen kan udføres på system-, integrations- og enhedsniveauer i softwareudvikling. Et af de grundlæggende mål med whitebox-test er at verificere en arbejdsgang for en applikation. Det involverer at teste en række foruddefinerede input mod forventede eller ønskede output, så når en bestemt input ikke resulterer i den forventede output, er du stødt på en fejl.
Klik her, hvis videoen ikke er tilgængelig
Hvordan udfører du White Box Testing?
For at give dig en forenklet forklaring på test af hvid boks har vi opdelt den i to grundlæggende trin . Dette er hvad testere gør, når de tester en applikation ved hjælp af den hvide boks testteknik:
TRIN 1) FORSTÅ KILDEKODEN
Det første, en tester ofte gør, er at lære og forstå applikationens kildekode. Da testning af hvid boks involverer test af en applikations indre funktion, skal testeren være meget vidende i de programmeringssprog, der bruges i de applikationer, de tester. Testperson skal også være meget opmærksom på sikker kodning. Sikkerhed er ofte et af de primære mål for testsoftware. Testeren skal være i stand til at finde sikkerhedsproblemer og forhindre angreb fra hackere og naive brugere, der muligvis injicerer ondsindet kode i applikationen enten bevidst eller ubevidst.
Trin 2) Opret testtilfælde og udfør
Det andet grundlæggende trin til test af hvidboks involverer test af applikationens kildekode for korrekt flow og struktur. En måde er ved at skrive mere kode for at teste applikationens kildekode. Testeren udvikler små tests til hver proces eller række processer i applikationen. Denne metode kræver, at testeren skal have intim viden om koden og udføres ofte af udvikleren. Andre metoder inkluderer manuel test, prøve og fejltest og brugen af testværktøjer, som vi vil forklare nærmere i denne artikel.
Eksempel på test af WhiteBox
Overvej følgende stykke kode
Printme (int a, int b) {------------ Printme er en funktionint resultat = a + b;Hvis (resultat> 0)Udskriv ("Positivt", resultat)AndetUdskriv ("negativ", resultat)} ----------- Slut på kildekoden
Målet med WhiteBox-test i softwareteknik er at verificere alle beslutningsgrene, sløjfer, udsagn i koden.
For at udøve udsagnene i ovenstående testeksempel på hvid boks ville det være WhiteBox test tilfælde
- A = 1, B = 1
- A = -1, B = -3
Hvid boks testteknikker
En stor testteknik i hvidboks er analyse af kodedækning. Kodedækningsanalyse eliminerer huller i en Test Case-pakke. Det identificerer områder i et program, der ikke udøves af et sæt testsager. Når hullerne er identificeret, opretter du testcases for at verificere utestede dele af koden og derved øge kvaliteten af softwareproduktet
Der er automatiserede værktøjer til rådighed til at udføre analyse af kodedækning. Nedenfor er et par dækningsanalyseteknikker, som en kassetester kan bruge:
Erklæringens dækning : - Denne teknik kræver, at alle mulige udsagn i koden testes mindst en gang under testprocessen inden for software engineering.
Grenafdækning - Denne teknik kontrollerer alle mulige stier (hvis andet og andre betingede sløjfer) til et softwareapplikation.
Bortset fra ovenstående er der adskillige dækningstyper såsom betingelsesdækning, flerbetingelsesdækning, stigdækning, funktionsdækning osv. Hver teknik har sine egne fordele og forsøger at teste (dække) alle dele af softwarekoden. Ved hjælp af Statement and Branch-dækning opnår du normalt 80-90% kodedækning, hvilket er tilstrækkeligt. Følgende er vigtige WhiteBox-testteknikker:
- Erklæringens dækning
- Beslutningsdækning
- Filialdækning
- Tilstandsdækning
- Dækning af flere forhold
- Endelig maskindækning
- Sti dækning
- Kontrol flow test
- Test af datastrøm
Se denne artikel for at få flere oplysninger https://www.guru99.com/code-coverage.html
Typer af test af hvide kasser
White box-test omfatter flere testtyper, der bruges til at evaluere anvendeligheden af et program, en kodeblok eller en bestemt softwarepakke. Der er angivet nedenfor -
-
Enhedstest: Det er ofte den første type test, der udføres på en applikation. Enhedstest udføres på hver enhed eller blok af kode, når den udvikles. Enhedstest udføres i det væsentlige af programmøren. Som softwareudvikler udvikler du et par kodelinjer, en enkelt funktion eller et objekt og tester det for at sikre, at det fungerer, før du fortsætter Unit Testing hjælper med at identificere et flertal af fejl, tidligt i softwareudviklings livscyklus. Fejl identificeret i dette trin er billigere og nemme at rette.
-
Test for hukommelseslækage : Hukommelseslækage er hovedårsager til langsommere kørende applikationer. En QA-specialist, der har erfaring med at opdage hukommelseslækage, er vigtig i tilfælde, hvor du har et langsomt kørende softwareprogram.
Bortset fra ovenstående er nogle få testtyper en del af både sort boks og hvid boks test. De er angivet som nedenfor
- White Box Penetration Testing: I denne test har testeren / udvikleren fuld information om applikationens kildekode, detaljerede netværksoplysninger, involverede IP-adresser og al serverinformation, som applikationen kører på. Målet er at angribe koden fra flere vinkler for at afsløre sikkerhedstrusler
- White Box Mutation Testing : Mutationstest bruges ofte til at finde de bedste kodningsteknikker, der kan bruges til at udvide en softwareløsning.
White Box testværktøjer
Nedenfor er en liste over de bedste værktøjer til testning af hvid boks.
- Parasoft Jtest
- EclEmma
- NUnit
- PyUnit
- HTMLUnit
- CppUnit
Fordele ved White Box Testing
- Kodeoptimering ved at finde skjulte fejl.
- Testkasser i hvid boks kan let automatiseres.
- Test er grundigere, da alle kodestier normalt er dækket.
- Test kan starte tidligt i SDLC, selvom GUI ikke er tilgængelig.
Ulemper ved WhiteBox-test
- Test af hvid boks kan være ret kompleks og dyr.
- Udviklere, der normalt udfører testkasser i hvid boks, afskyr det. White box-test af udviklere er ikke detaljeret, kan føre til produktionsfejl.
- White box-test kræver professionelle ressourcer med en detaljeret forståelse af programmering og implementering.
- White-box-test er tidskrævende, større programmeringsapplikationer tager sig tid til at teste fuldt ud.
Afsluttende noter:
- Test af hvid boks kan være ret kompleks. Den involverede kompleksitet har meget at gøre med den testede applikation. Et lille program, der udfører en enkelt simpel operation, kan testes i hvid boks på få minutter, mens større programmeringsapplikationer tager dage, uger og endnu længere tid at teste fuldt ud.
- White box-test i softwaretest skal udføres på en softwareapplikation, da den udvikles, efter den er skrevet, og igen efter hver ændring