Mikä on Gray Box Testaus? Tekniikat, esimerkki
Thomas Hamilton
⚡ Älykäs yhteenveto
Harmaa Box Testauksessa sovellusta tarkastellaan osittaisen tiedon avulla sen sisäisestä rakenteesta yhdistämällä käyttäjälähtöisen mustalaatikkotestauksen näkökulman riittävään arkkitehtuuriseen näkemykseen selittääkseen, miksi vika tapahtui, eikä vain sitä, että se tapahtui.
Mikä on Gray Box Testaus?
Harmaa Box Testaus (kirjoitetaan myös harmaa Box Testaus) on ohjelmistotestaustekniikka, jossa testataan ohjelmistotuotetta tai sovellusta tietäen osittain sovelluksen sisäisestä rakenteesta. Greyn tarkoitus Box Testauksella pyritään etsimään ja tunnistamaan vikoja, jotka johtuvat virheellisestä koodirakenteesta tai sovelluksen virheellisestä käytöstä.
Tässä prosessissa tunnistetaan yleisesti verkkojärjestelmiin liittyviä kontekstikohtaisia virheitä. Tekniikka lisää testin kattavuus keskittymällä monimutkaisen järjestelmän kaikkiin tasoihin yhden niistä sijaan.
Harmaa Box Testaus on ohjelmistotestausmenetelmä, joka yhdistää Valkoinen Box Testaus ja Musta Box TestausNäiden kolmen välinen ero riippuu siitä, kuinka paljon sisäisestä rakenteesta testaaja voi nähdä:
- Valkoisessa Box Sisäisen rakenteen (koodin) testaaminen on tunnettua.
- Mustassa Box Sisäisen rakenteen (koodin) testaaminen on tuntematonta.
- Harmaassa Box Sisäisen rakenteen (koodin) testaaminen on osittain tiedossa.
Alla oleva kaavio sijoittaa kolme menetelmää samalle näkyvyysasteikolle.
In ohjelmistotuotanto, Harmaa Box Testaus antaa mahdollisuuden testata sovelluksen molempia puolia, esityskerrosta sekä sen takana olevaa koodia. Se on ensisijaisesti hyödyllinen integraatiotestaus ja tunkeutumisen testaus.
Esimerkki harmaasta Box testaus: Jos testaaja testaa verkkosivuston ominaisuutta, kuten linkkejä tai orpoja linkkejä, ja havaitsee ongelmia näiden linkkien kanssa, muutos voidaan tehdä suoraan HTML-koodiin ja tarkistaa reaaliajassa.
Miksi harmaa Box Testaus
Harmaa Box Testaus suoritetaan seuraavista syistä:
- Se tarjoaa sekä mustalaatikkotestauksen että valkolaatikkotestauksen yhdistetyt edut.
- Se yhdistää kehittäjien ja testaajien panoksen ja parantaa tuotteen yleistä laatua.
- Se vähentää funktionaalisten ja ei-funktionaalisten tyyppien testaamisen pitkän prosessin yleiskustannuksia.
- Se antaa kehittäjälle riittävästi vapaa-aikaa virheiden korjaamiseen.
- Testaus tehdään käyttäjän näkökulmasta, ei suunnittelijan näkökulmasta.
- Vika voidaan selittää pelkän raportoinnin sijaan, koska testaaja näkee kerroksen, jossa se tapahtui.
Harmaa Box Testaus vs. musta Box vs. valkoinen Box Testaus
Nämä kolme menetelmää eivät ole niinkään kilpailevia vaihtoehtoja kuin kolme käyttöoikeustasoa, ja jokainen vastaa erityyppiseen kysymykseen. Niiden rinnakkainen asettaminen tekee valinnasta konkreettisen.
| Perusta | Musta Box Testaus | Harmaa Box Testaus | Valkoinen Box Testaus |
|---|---|---|---|
| Sisäisen rakenteen tuntemus | Ei eristetty | Osittainen | Koko |
| Esittäjä | Testaajat ja loppukäyttäjät | Testaajat ja testaajien kanssa työskentelevät kehittäjät | Kehittäjät ja testausinsinöörit |
| Testisuunnittelun perusta | Vaatimukset ja eritelmät | Archiarkkitehtuuri, algoritmit, tietorakenteet ja rajapinnat | Lähdekoodi ja ohjausvirta |
| Tyypillinen taso | Järjestelmä- ja hyväksymistestaus | Integraatio-, penetraatio- ja verkkopalvelutestaus | Yksikkö- ja komponenttitestaus |
| Kattavuus mitattuna seuraavasti: | Vaatimusten kattavuus | Rajapinta, data ja polkujen kattavuus | Tilinpäätös-, haara- ja polkukattavuus |
| Päärajoitus | Epäonnistumisen syy pysyy piilossa | Syvyys on rajoitettu myönnetyn käyttöoikeuden mukaan | Kallis, ja se voi jättää puuttuvat vaatimukset huomiotta |
Useimmat joukkueet käyttävät kaikkia kolmea ohjelmistotestauksen elinkaari, ja harmaa laatikkokerros on se, missä käyttöliittymän ja tietovaraston väliin jäävät viat yleensä havaitaan.
Harmaa Box Testausstrategia
Suorittaaksesi harmaan Box Testauksen aikana testaajan ei tarvitse välttämättä päästä käsiksi lähdekoodiin. Testi suunnitellaan algoritmien, arkkitehtuurien, sisäisten tilojen tai muiden ohjelman käyttäytymisen yleisten kuvausten tuntemuksen perusteella.
Suorittaaksesi harmaan Box testaus:
- Se soveltaa mustan laatikon testauksen suoraviivaisia tekniikoita.
- Se perustuu vaatimuslähtöiseen testitapausten luomiseen, joten se asettaa kaikki ehdot valmiiksi ennen kuin ohjelmaa testataan assertion-metodilla.
Harmaan sävyyn käytetyt tekniikat Box Testaus on:
- Matriisitestaus: Tässä tekniikassa määritellään kaikki ohjelmassa olevat muuttujat ja kunkin muuttujan aiheuttama riski, jotta käyttämättömät ja riskialttiit muuttujat ovat näkyvissä.
- Regressiotestaus: Tarkistaa, onko edellisessä versiossa tehty muutos heikentänyt ohjelman muita osa-alueita uudessa versiossa. Tämä tehdään strategioilla, kuten testaamalla kaikki uudelleen, testaamalla uudelleen riskialttiit käyttötapaukset ja testaamalla uudelleen palomuurin sisällä.
- Ortogonaalisen taulukon testaus tai OAT: tarjoaa maksimaalisen koodikattavuuden minimaalisella määrällä testitapauksia.
- Kuvion testaus: suoritettiin aiempien järjestelmävirheiden historiatiedoilla. Toisin kuin mustalaatikkotestaus, Grey Box Testaus pureutuu koodiin ja selvittää, miksi virhe tapahtui.
Harmaa Box menetelmässä käytetään yleensä automatisoitua ohjelmistojen testaustyökalut Testauksen suorittamiseksi. Tyngät ja moduuliajurit luodaan, jotta testaajan ei tarvitse luoda koodia manuaalisesti.
Harmaantumisen vaiheet Box Testaus on:
- Vaihe 1: Tunnista syötteet.
- Vaihe 2: Tunnista tuotokset.
- Vaihe 3: Tunnista tärkeimmät polut.
- Vaihe 4: Tunnista alitoiminnot.
- Vaihe 5: Kehitä syötteet alifunktioille.
- Vaihe 6: Kehitä alifunktioiden tuotokset.
- Vaihe 7: Suorita alifunktioiden testitapaus.
- Vaihe 8: Varmista alifunktioiden oikea tulos.
- Vaihe 9: Toista vaiheet 4–8 muille alitoiminnoille.
- Vaihe 10: Toista vaiheet 7 ja 8 muille alitoiminnoille.
Greyn testitapaukset Box Testaus voi kattaa muun muassa graafisen käyttöliittymän, tietoturvan, tietokannan, selaimen ja käyttöjärjestelmän huolenaiheet. Jokainen luotu tapaus tarvitsee silti tavanomaisen testitapaus attribuutteja, koska tapaus, jota ei voida toistaa omasta kuvauksestaan, on regressiossa vain vähän hyödyllinen.
Missä harmaa Box Testausta käytetään
Tekniikka ansaitsee paikkansa alueilla, joilla vika voidaan diagnosoida vain tarkastelemalla kahta kerrosta samanaikaisesti. Sitä käytetään useimmiten seuraavissa tilanteissa:
- Tietokantaan perustuvat työnkulut: Toiminto suoritetaan käyttöliittymän kautta, ja tuloksena olevia rivejä kysellään suoraan sen varmistamiseksi, että arvot, tyypit ja suhteet on tallennettu tarkoitetulla tavalla.
- Verkkopalvelut ja API:t: pyyntö lähetetään ja vastauksen tila, otsikot ja hyötykuorma tarkistetaan julkaistua con-tiedostoa vastentract, joka on arkipäivän muoto API-testaus.
- Integraatiopisteet: Kahden moduulin välisen rajan ylittävät viestit tarkastetaan, kun molempia moduuleja käsitellään käynnissä olevina järjestelminä lähdekooditiedostojen sijaan.
- Turvallisuusarviointi: Tunkeutumistestaaja, jolle annetaan normaali käyttäjätili ja arkkitehtuurikatsaus, luo uudelleen sisäpiiriläisen aseman, mikä on harmaan laatikon sitoutumismallin mukainen.
- Verkkosovellukset ja käyttöliittymät: Rikkoutuneet linkit, orpot sivut, istuntojen käsittely ja asiakaspuolen validointi tarkistetaan ja merkinnät ja pyyntövirta ovat osittain näkyvissä.
Kaikissa näissä järjestelmävirheiden kokonaiskustannukset pienenevät, koska ongelmat havaitaan ja selitetään ennen kuin ne etenevät pidemmälle prosessissa. järjestelmän testaus tai tuotantoa.
Harmaa Box Testaustyökalut
Mikään työkalu ei suorita harmaata Box Testaus itsenäisesti. Kategoria tarvitsee yhdistelmän käyttöliittymäajuria, alla olevan tason tarkastustyökalua ja tapaa skriptata nämä kaksi yhdessä.
- API- ja web-palveluasiakkaat kuten Postman ja SoapUI, jota käytetään pyyntöjen tekemiseen ja tilakoodien ja vastaustekstien esittämiseen.
- Tietokantaohjelmat ja SQL-kyselytyökalut, käytetään tarkistamaan pysyvä tila käyttöliittymätoiminnon jälkeen.
- Selaimen kehitystyökalut ja HTTP-välityspalvelimet kuten Burp Suite, jota käytetään pyyntöjen tarkastamiseen ja muokkaamiseen tietoturvakeskeisten istuntojen aikana.
- Käyttöliittymän automaatiokehykset kuten Selenium, jota käytetään esityskerroksen ohjaamiseen sisällä automaatiotestaus sviitti.
- Loki- ja valvontatyökalut, jota käytetään korreloimaan havaitun vian sovelluksen sillä hetkellä sisäisesti tallentaman tiedon kanssa.
Valinnalla on vähemmän merkitystä kuin johdotuksella: ellei käyttöliittymän ajuri ja tarkastusvaihe suoriteta samassa skriptatussa työnkulussa, tuloksena on kaksi erillistä manuaalista tarkistusta yhden harmaan laatikon testin sijaan.
Harmaa Box Testaushaasteet
Osittainen näkyvyys tuo mukanaan ongelmia, joita kummassakaan puhtaassa menetelmässä ei ole, ja seuraavat ovat ongelmia, joihin tiimit törmäävät useimmiten:
- Kun testattava komponentti kohtaa jonkinlaisen vian, se voi keskeyttää käynnissä olevan toiminnon ja jättää loput sekvenssistä suorittamatta.
- Testi voi suorittua kokonaan, vaikka tuloksen sisältö on virheellinen, joten varmennusvaiheessa on tarkistettava arvot eikä testin valmistumista.
- Täydellinen koodipolun kattavuus ei ole saavutettavissa, koska testaaja ei koskaan näe kaikkia haaroja, joihin white box -testaus yltäisi.
- Testien pohjana oleva suunnitteludokumentaatio voi olla vanhentunutta, ja vanhentunut skeema tai rajapintaspesifikaatio mitätöi hiljaa testisuunnitelman.
- Testaajat tarvitsevat sekä toimialaosaamista että teknistä syvyyttä, mikä on kapeampi taitoprofiili rekrytoitaville.
- Hajautunut ja voimakkaasti vatsalihaksiatracTed-arkkitehtuurit vaikeuttavat havaitun vian selittämistä tietyllä sisäisellä komponentilla.
Nämä rajoitukset puoltavat harmaan Box Testaus yhtenä kerroksena useiden joukossa sen sijaan, että se korvaaisi muita, mikä on pointti, jota korostetaan laajemmassa kokonaisuudessa ohjelmistotestaustekniikat ja ohjelmistotestauksen tyypitSe istuu luonnollisesti rinnakkain toiminnallinen testaus ja spesifikaatiopohjaiset lähestymistavat, kuten mallipohjainen testaus.
