Hva er Grey Box Testing? Teknikker, eksempel
Thomas Hamilton
⚡ Smart oppsummering
grå Box Testing undersøker en applikasjon med delvis kunnskap om dens interne struktur, og kombinerer det brukervendte perspektivet på svartboks-testing med nok arkitektonisk innsikt til å forklare hvorfor en feil oppstod, i stedet for bare at den skjedde.
Hva er Grey Box Testing?
grå Box Testing (også stavet grå Box Testing) er en programvaretestteknikk som tester et programvareprodukt eller en applikasjon med delvis kunnskap om applikasjonens interne struktur. Formålet med Grey Box Testing handler om å søke etter og identifisere feil forårsaket av feil kodestruktur eller feil bruk av applikasjonen.
I denne prosessen identifiseres ofte kontekstspesifikke feil relatert til websystemer. Teknikken øker testdekning ved å konsentrere seg om alle lagene i et komplekst system i stedet for ett av dem.
grå Box Testing er en metode for programvaretesting som kombinerer Hvit Box Testing og Svart Box TestingForskjellen mellom de tre kommer ned til hvor mye av den interne strukturen testeren kan se:
- I hvitt Box Testing av den interne strukturen (koden) er kjent.
- I svart Box Testing av den interne strukturen (koden) er ukjent.
- I grått Box Testing av den interne strukturen (koden) er delvis kjent.
Diagrammet nedenfor plasserer de tre metodene på samme synlighetsskala.
In software engineering, Grå Box Testing gir muligheten til å teste begge sider av en applikasjon, presentasjonslaget samt koden bak det. Det er først og fremst nyttig i integrasjonstesting og Penetrasjonstesting.
Eksempel på grå Box testing: Hvis testeren støter på et problem med en nettsidefunksjon, som lenker eller foreldreløse lenker, kan endringen gjøres umiddelbart i HTML-koden og kontrolleres i sanntid.
Hvorfor grå Box Testing
grå Box Testing utføres av følgende grunner:
- Det gir de kombinerte fordelene ved både svartboks-testing og hvitboks-testing.
- Den kombinerer innspill fra utviklere så vel som testere og forbedrer den generelle produktkvaliteten.
- Det reduserer kostnadene ved den lange prosessen med å teste funksjonelle og ikke-funksjonelle typer.
- Det gir en utvikler nok fritid til å fikse feil.
- Testing gjøres fra brukerens synspunkt snarere enn designerens synspunkt.
- En feil kan forklares snarere enn bare rapporteres, fordi testeren kan se laget der den oppsto.
grå Box Testing vs. svart Box mot hvit Box Testing
De tre metodene er ikke konkurrerende alternativer, men snarere tre tilgangsnivåer, og hver av dem svarer på en annen type spørsmål. Å sette dem side om side gjør valget konkret.
| Base | Svart Box Testing | grå Box Testing | Hvit Box Testing |
|---|---|---|---|
| Kunnskap om intern struktur | none | Delvis | Full |
| Fremført av | Testere og sluttbrukere | Testere og utviklere som jobber med testere | Utviklere og testingeniører |
| Grunnlaget for testdesign | Krav og spesifikasjoner | ArchiTektur, algoritmer, datastrukturer og grensesnitt | Kildekode og kontrollflyt |
| Typisk nivå | System- og aksepttesting | Integrasjon, penetrasjon og testing av webtjenester | Enhets- og komponenttesting |
| Dekning målt som | Kravdekning | Grensesnitt-, data- og stidekning | Utdrag, gren og stidekning |
| Hovedbegrensning | Årsaken til en feil forblir skjult | Dybden er begrenset av den gitte tilgangen | Kostbart, og det kan føre til at kravene ikke lenger er oppfylt |
De fleste lag bruker alle tre på tvers av livssyklus for programvaretesting, og det grå bokslaget er der feilene som faller mellom brukergrensesnittet og datalageret vanligvis fanges opp.
grå Box Teststrategi
Å utføre Grå Box Testing, det er ikke nødvendig for testeren å ha tilgang til kildekoden. En test er utformet basert på kunnskap om algoritmer, arkitekturer, interne tilstander eller andre overordnede beskrivelser av programoppførsel.
Å utføre Grå Box testing:
- Den anvender de enkle teknikkene fra svartbokstesting.
- Den er basert på kravdrevet testtilfellegenerering, så den forhåndsinnstiller alle betingelsene før programmet testes med påstandsmetoden.
Teknikker brukt for grå Box Testingen er:
- Matrisetesting: Denne teknikken innebærer å definere alle variablene som finnes i programmet, sammen med risikoen hver enkelt bærer, slik at ubrukte og høyrisikovariabler er synlige.
- Regresjonstesting: sjekker om en endring i den forrige versjonen har påvirket andre aspekter av programmet i den nye versjonen. Dette gjøres med strategier som å teste alle på nytt, teste risikable brukstilfeller på nytt og teste på nytt innenfor en brannmur.
- Ortogonal array-testing eller HAVRE: gir maksimal kodedekning med et minimum antall testtilfeller.
- Mønstertesting: utført på historiske data fra tidligere systemfeil. I motsetning til svartbokstesting, grå Box Testing graver i koden og bestemmer hvorfor feilen oppstod.
grå Box metodikken bruker vanligvis automatisert verktøy for testing av programvare for å utføre testingen. Stubber og moduldrivere opprettes slik at testeren ikke trenger å generere koden manuelt.
Fremgangsmåte for å utføre grå Box Testingen er:
- Trinn 1: Identifiser innganger.
- Trinn 2: Identifiser utgangene.
- Trinn 3: Identifiser hovedstiene.
- Trinn 4: Identifiser delfunksjoner.
- Trinn 5: Utvikle inndata for delfunksjonene.
- Trinn 6: Utvikle utdata for delfunksjonene.
- Trinn 7: Kjør testtilfellet for delfunksjonene.
- Trinn 8: Bekreft riktig resultat for delfunksjonene.
- Trinn 9: Gjenta trinn 4 til 8 for de andre delfunksjonene.
- Trinn 10: Gjenta trinn 7 og 8 for de andre delfunksjonene.
Testtilfellene for Grey Box Testing kan blant annet dekke problemer knyttet til brukergrensesnitt, sikkerhet, database, nettleser og operativsystem. Hvert genererte tilfelle trenger fortsatt de vanlige testforsøk attributter, siden et tilfelle som ikke kan reproduseres fra sin egen beskrivelse er av liten nytte under regresjon.
Hvor grå Box Testing brukes
Teknikken fortjener sin plass der en defekt bare kan diagnostiseres ved å se på to lag samtidig. Følgende scenarier er de den oftest brukes på:
- Databasebaserte arbeidsflyter: en handling utføres via brukergrensesnittet, og de resulterende radene spørres deretter direkte for å bekrefte at verdiene, typene og relasjonene ble lagret som tiltenkt.
- Webtjenester og API-er: en forespørsel sendes, og svarstatus, overskrifter og nyttelast kontrolleres mot den publiserte konfigurasjonen.tract, som er hverdagsformen av API-testing.
- Integrasjonspunkter: Meldinger som krysser en grense mellom to moduler blir inspisert, mens begge modulene behandles som kjørende systemer i stedet for som kildefiler.
- Sikkerhetsvurdering: En penetrasjonstester gitt en vanlig brukerkonto og en arkitekturoversikt gjengir posisjonen til en insider, som er standard gråboks-engasjementsmodell.
- Webapplikasjoner og grafiske brukergrensesnitt: Ødelagte lenker, foreldreløse sider, økthåndtering og validering på klientsiden kontrolleres alle med delvis synlighet av markupen og forespørselsflyten.
På tvers av alle disse reduseres den totale kostnaden for systemfeil fordi problemer fanges opp og forklares før de går videre ned i rørledningen til systemtesting eller produksjon.
grå Box Testverktøy
Ingen verktøy yter grått Box Testing alene. Det kategorien trenger er en kombinasjon av en grensesnittdriver, et inspeksjonsverktøy for laget under, og en måte å skripte de to sammen på.
- API- og webtjenesteklienter slik som Postman og SoapUI, brukes til å utstede forespørsler og gjøre gjeldende statuskoder og svarelementer.
- Databaseklienter og SQL-spørringsverktøy, brukes til å bekrefte vedvarende tilstand etter en grensesnitthandling.
- Verktøy for nettleserutviklere og HTTP-proxyer slik som Burp Suite, brukes til å inspisere og endre forespørsler under sikkerhetsorienterte økter.
- UI-automatiseringsrammeverk slik som Selenium, brukt til å drive presentasjonslaget inne i en automatiseringstesting på.
- Logg- og overvåkingsverktøy, brukt til å korrelere en observert feil med det applikasjonen registrerte internt i det øyeblikket.
Valget betyr mindre enn kablingen: med mindre grensesnittdriveren og inspeksjonstrinnet kjører i samme skriptede flyt, blir resultatet to separate manuelle kontroller i stedet for én gråbokstest.
grå Box Testing utfordringer
Delvis synlighet introduserer problemer som ingen av de rene metodene har, og følgende er de som teamene møter oftest:
- Når en komponent under test støter på en feil av noe slag, kan den avbryte den pågående operasjonen og la resten av sekvensen bli uutført.
- En test kan kjøres i sin helhet mens innholdet i resultatet er feil, så verifiseringstrinnet må kontrollere verdier i stedet for å fullføre.
- Full dekning av kodebanen er ikke oppnåelig, fordi testeren aldri ser alle grener som white box-testing ville nådd.
- Designdokumentasjonen testene er avhengige av kan være foreldet, og et utdatert skjema eller grensesnittspesifikasjon ugyldiggjør i stillhet testdesignet.
- Testere trenger både domeneforståelse og teknisk dybde, som er en smalere ferdighetsprofil å rekruttere til.
- Distribuert og tung magetracTed-arkitekturer gjør det vanskelig å tilskrive en observert feil til en spesifikk intern komponent.
Disse begrensningene taler for å behandle grå Box Testing som ett lag blant flere snarere enn en erstatning for de andre, noe som er poenget som fremsettes på tvers av det bredere settet med teknikker for programvaretesting og typer programvaretestingDen sitter naturlig ved siden av funksjonstesting og spesifikasjonsdrevne tilnærminger som modellbasert testing.
