Hvad er Gray Box Test? Teknikker, eksempel
Thomas Hamilton
⚡ Smart opsummering
Grå Box Testning undersøger en applikation med delvist kendskab til dens interne struktur og kombinerer det brugervenlige perspektiv på black box-testning med tilstrækkelig arkitektonisk indsigt til at forklare, hvorfor en fejl opstod, i stedet for kun at den skete.
Hvad er Gray Box Test?
Grå Box Test (også stavet Grå Box Testing) er en softwaretestteknik, der tester et softwareprodukt eller en applikation med delvist kendskab til applikationens interne struktur. Formålet med Grey Box Testning handler om at søge efter og identificere fejl forårsaget af forkert kodestruktur eller forkert brug af applikationen.
I denne proces identificeres kontekstspecifikke fejl relateret til websystemer ofte. Teknikken øger test dækning ved at koncentrere sig på alle lagene i et komplekst system i stedet for på ét af dem.
Grå Box Testning er en softwaretestmetode, der kombinerer Hvid Box Test og Sort Box TestForskellen mellem de tre kommer ned til, hvor meget af den interne struktur testeren kan se:
- I hvid Box Test af den interne struktur (kode) er kendt.
- I sort Box Test af den interne struktur (kode) er ukendt.
- I grå Box Test af den interne struktur (kode) er delvist kendt.
Diagrammet nedenfor placerer de tre metoder på den samme synlighedsskala.
In software Engineering, Grå Box Testning giver mulighed for at teste begge sider af en applikation, præsentationslaget samt koden bag det. Det er primært nyttigt i integrationstest og penetrationstestning.
Eksempel på grå Box Test: Hvis testeren støder på et problem med en hjemmesidefunktion, såsom links eller forældreløse links, kan ændringen foretages med det samme i HTML-koden og kontrolleres i realtid, hvis testeren støder på et problem med disse links.
Hvorfor grå Box Test
Grå Box Testning udføres af følgende årsager:
- Det giver de kombinerede fordele ved både black box-testning og white box-testning.
- Det kombinerer input fra både udviklere og testere og forbedrer den samlede produktkvalitet.
- Det reducerer overheaden ved den lange proces med at teste funktionelle og ikke-funktionelle typer.
- Det giver en udvikler tilstrækkelig fritid til at rette fejl.
- Testning udføres fra brugerens synspunkt snarere end designerens synspunkt.
- En fejl kan forklares snarere end blot rapporteres, fordi testeren kan se laget, hvor den opstod.
Grå Box Testning vs. sort Box mod hvid Box Test
De tre metoder er ikke så meget konkurrerende alternativer, som de er tre adgangsniveauer, og hver især besvarer en forskellig slags spørgsmål. Ved at sætte dem side om side bliver valget konkret.
| Basis | Sort Box Test | Grå Box Test | Hvid Box Test |
|---|---|---|---|
| Kendskab til intern struktur | Ingen | Delvis | Fuld |
| Udført af | Testere og slutbrugere | Testere og udviklere, der arbejder med testere | Udviklere og testingeniører |
| Grundlag for testdesign | Krav og specifikationer | ArchiTektur, algoritmer, datastrukturer og grænseflader | Kildekode og kontrolflow |
| Typisk niveau | System- og accepttest | Integration, penetration og webservicetestning | Enheds- og komponenttestning |
| Dækning målt som | Kravdækning | Grænseflade-, data- og stidækning | Dækning af erklæring, gren og sti |
| Hovedbegrænsning | Årsagen til en fejl forbliver skjult | Dybden er begrænset af den tildelte adgang | Dyrt, og det kan overse manglende krav |
De fleste hold bruger alle tre på tværs af livscyklus for softwaretest, og det grå bokslag er der, hvor defekterne, der falder mellem brugergrænsefladen og datalagret, normalt fanges.
Grå Box Teststrategi
At udføre Grå Box Ved testning er det ikke nødvendigt for testeren at have adgang til kildekoden. En test designes baseret på kendskab til algoritmer, arkitekturer, interne tilstande eller andre overordnede beskrivelser af programadfærd.
At udføre Grå Box Test:
- Den anvender de simple teknikker fra black box-testning.
- Den er baseret på kravdrevet generering af testcases, så den forudindstiller alle betingelserne, før programmet testes med assertion-metoden.
Teknikker brugt til grå Box Testning er:
- Matrix test: Denne teknik involverer at definere alle de variabler, der findes i programmet, sammen med den risiko, hver enkelt bærer, så ubrugte og højrisikovariabler er synlige.
- Regressionstest: kontrollerer, om en ændring i den tidligere version har påvirket andre aspekter af programmet i den nye version. Det gøres med strategier som at gentest alle, gentest risikable anvendelsesscenarier og gentest inden for en firewall.
- Ortogonal Array Test eller HAVRE: giver maksimal kodedækning med et minimalt antal testcases.
- Mønstertest: udført på historiske data fra tidligere systemfejl. I modsætning til black box-testning, Grey Box Testning dykker ned i koden og bestemmer, hvorfor fejlen opstod.
Grå Box Metoden bruger normalt automatiseret værktøjer til test af software at udføre testen. Stubs og moduldrivere oprettes, så testeren ikke behøver at generere koden manuelt.
Trin til at udføre Grey Box Testning er:
- Trin 1: Identificer input.
- Trin 2: Identificer outputtene.
- Trin 3: Identificér de vigtigste stier.
- Trin 4: Identificer delfunktioner.
- Trin 5: Udvikl input til delfunktionerne.
- Trin 6: Udvikl output til delfunktionerne.
- Trin 7: Udfør testcasen for delfunktionerne.
- Trin 8: Bekræft det korrekte resultat for delfunktionerne.
- Trin 9: Gentag trin 4 til 8 for de andre delfunktioner.
- Trin 10: Gentag trin 7 og 8 for de andre delfunktioner.
Testtilfældene for Grey Box Testning kan blandt andet dække GUI, sikkerhed, database, browser og operativsystemproblemer. Hvert genereret tilfælde kræver stadig de sædvanlige test sag attributter, da et tilfælde, der ikke kan reproduceres ud fra sin egen beskrivelse, er af ringe nytte under regression.
Hvor grå Box Testning bruges
Teknikken fortjener sin plads, hvor en defekt kun kan diagnosticeres ved at se på to lag på én gang. Følgende scenarier er dem, den oftest anvendes til:
- Databasebaserede arbejdsgange: En handling udføres via brugergrænsefladen, og de resulterende rækker forespørges derefter direkte for at bekræfte, at værdierne, typerne og relationerne blev gemt som tilsigtet.
- Webtjenester og API'er: En anmodning sendes, og svarstatus, headere og nyttelast kontrolleres mod den offentliggjorte kode.tract, som er den daglige form af API-test.
- Integrationspunkter: Beskeder, der krydser en grænse mellem to moduler, inspiceres, mens begge moduler behandles som kørende systemer snarere end som kildefiler.
- Sikkerhedsvurdering: En penetrationstester givet en normal brugerkonto og en arkitekturoversigt gengiver en insiders position, hvilket er standardmodellen for grå boks-engagement.
- Webapplikationer og brugergrænseflader: Ødelagte links, forældreløse sider, sessionshåndtering og klientsidevalidering kontrolleres alle med delvis synlighed af markup og anmodningsflow.
På tværs af alle disse reduceres de samlede omkostninger ved systemfejl, fordi problemer opdages og forklares, før de går videre ned i pipelinen til system test eller produktion.
Grå Box Testværktøjer
Intet værktøj yder grå Box Test af sig selv. Det, kategorien har brug for, er en kombination af en grænsefladedriver, et inspektionsværktøj til laget nedenunder og en måde at lave scripts til de to sammen.
- API- og webserviceklienter som Postman og SoapUI, bruges til at udstede anmodninger og gøre krav på statuskoder og svarelementer.
- Databaseklienter og SQL-forespørgselsværktøjer, bruges til at verificere vedvarende tilstand efter en grænsefladehandling.
- Browserudviklerværktøjer og HTTP-proxyer som Burp Suite, bruges til at inspicere og ændre anmodninger under sikkerhedsorienterede sessioner.
- UI-automatiseringsframeworks som Selenium, bruges til at drive præsentationslaget inde i en automatiseringstest på.
- Log- og overvågningsværktøjer, bruges til at korrelere en observeret fejl med det, som applikationen registrerede internt på det tidspunkt.
Valget betyder mindre end ledningsføringen: medmindre interfacedriveren og inspektionstrinnet kører i samme scriptede flow, er resultatet to separate manuelle kontroller i stedet for én gråbokstest.
Grå Box Test udfordringer
Delvis synlighed introducerer problemer, som ingen af de rene metoder har, og følgende er dem, som teams oftest støder på:
- Når en komponent under test støder på en eller anden form for fejl, kan den afbryde den igangværende operation og lade resten af sekvensen blive uudført.
- En test kan blive udført fuldt ud, mens indholdet af resultatet er forkert, så verifikationstrinnet skal kontrollere værdier snarere end fuldførelse.
- Fuld dækning af kodestier er ikke opnåelig, fordi testeren aldrig ser alle de grene, som white box-testning ville nå.
- Designdokumentationen, som testene er baseret på, kan være forældet, og et forældet skema eller en forældet grænsefladespecifikation ugyldiggør stille og roligt testdesignet.
- Testere har brug for både domæneforståelse og teknisk dybde, hvilket er en snævrere færdighedsprofil at rekruttere til.
- Distribueret og kraftig mavemuskulaturtracTed-arkitekturer gør det vanskeligt at tilskrive en observeret fejl til en specifik intern komponent.
Disse begrænsninger taler for behandling af grå Box Testning som ét lag blandt flere snarere end en erstatning for de andre, hvilket er pointen på tværs af det bredere sæt af softwaretestteknikker og typer af softwaretestningDen sidder naturligt ved siden af funktionstest og specifikationsdrevne tilgange som f.eks. modelbaseret testning.
