Mi az a Gray Box Tesztelés? Technikák, példa

Mi az a Gray Box Tesztelés?

szürke Box Tesztelés (más néven Gray Box A tesztelés egy olyan szoftvertesztelési technika, amely egy szoftverterméket vagy alkalmazást tesztel az alkalmazás belső szerkezetének részleges ismeretében. A Grey célja Box A tesztelés célja a nem megfelelő kódszerkezet vagy az alkalmazás nem megfelelő használata által okozott hibák keresése és azonosítása.

Ebben a folyamatban gyakran azonosítják a webes rendszerekkel kapcsolatos kontextusspecifikus hibákat. A technika növeli teszt lefedettség azáltal, hogy egy komplex rendszer összes rétegére koncentrálunk, ahelyett, hogy csak egyre koncentrálnánk.

szürke Box A tesztelés egy olyan szoftvertesztelési módszer, amely egyesíti a fehér Box Tesztelés és a Fekete Box TesztelésA három közötti különbség abban rejlik, hogy a tesztelő a belső struktúra mekkora részét látja:

• Fehérben Box A belső struktúra (kód) tesztelése ismert.
• Feketében Box A belső struktúra (kód) tesztelése ismeretlen.
• Szürkében Box A belső struktúra (kód) tesztelése részben ismert.

Az alábbi ábra a három módszert ugyanazon a láthatósági skálán helyezi el.

In szoftverfejlesztés, Szürke Box A tesztelés lehetővé teszi az alkalmazás mindkét oldalának tesztelését, a megjelenítési réteget és a mögötte lévő kódot is. Elsősorban a következőkben hasznos: integrációs tesztelés és a penetrációs vizsgálat.

Szürke példa Box Tesztelés: Egy weboldal funkciójának, például linkek vagy árva linkek tesztelésekor, ha a tesztelő problémát talál ezekkel a linkekkel, a módosítás azonnal elvégezhető a HTML kódban, és valós időben ellenőrizhető.

Miért szürke Box Tesztelés

szürke Box A tesztelést a következő okokból végzik:

• A fekete dobozos és a fehér dobozos tesztelés együttes előnyeit nyújtja.
• Egyesíti a fejlesztők és a tesztelők visszajelzéseit, és javítja a termék általános minőségét.
• Csökkenti a funkcionális és nem funkcionális típusok tesztelésének hosszú folyamatával járó többletterhelést.
• Ez elegendő szabadidőt biztosít a fejlesztőnek a hibák javítására.
• A tesztelést a felhasználó szemszögéből végzik, nem pedig a tervező szemszögéből.
• Egy hiba megmagyarázható, nem csak jelenthető, mivel a tesztelő látja azt a réteget, ahol történt.

szürke Box Tesztelés vs. fekete Box vs. fehér Box Tesztelés

A három módszer nem annyira egymással versengő alternatíva, mint inkább a hozzáférés három szintje, és mindegyik másfajta kérdésre ad választ. Egymás mellé állításuk konkréttá teszi a választást.

A legtöbb csapat mindhármat használja szoftvertesztelés életciklusa, és a szürke doboz réteg az, ahol általában a felhasználói felület és az adattár közé eső hibákat észlelik.

szürke Box Tesztelési stratégia

Grey végrehajtásához Box A teszteléshez nem szükséges, hogy a tesztelő hozzáférjen a forráskódhoz. A tesztet az algoritmusok, architektúrák, belső állapotok vagy a program viselkedésének egyéb magas szintű leírásainak ismeretén alapulva tervezik meg.

Grey végrehajtásához Box Tesztelés:

• A fekete doboz tesztelés egyszerű technikáit alkalmazza.
• Követelményvezérelt tesztesetek generálásán alapul, tehát előre beállítja az összes feltételt, mielőtt a programot az assertion metódus tesztelné.

Szürkeárnyalatokhoz használt technikák Box A tesztelés a következő:

• Mátrix tesztelés: Ez a technika magában foglalja a programban létező összes változó definiálását, valamint az egyes változók kockázatát, így a fel nem használt és a magas kockázatú változók láthatóak.
• Regressziós teszt: ellenőrzi, hogy az előző verzióban végrehajtott módosítások a program más aspektusait visszafejtették-e az új verzióban. Olyan stratégiákkal végzi, mint az összes újratesztelése, a kockázatos használati esetek újratesztelése és a tűzfalon belüli újratesztelés.
• Ortogonális tömb tesztelése vagy OAT: maximális kódlefedettséget biztosít minimális számú tesztesettel.
• Minta tesztelés: korábbi rendszerhibák historikus adatain végzett vizsgálat. A fekete dobozos teszteléssel ellentétben a Grey Box A tesztelés a kódba ás, és megállapítja, hogy miért történt a hiba.

szürke Box a módszertan általában automatizált szoftvertesztelő eszközök a tesztelés elvégzéséhez. A csonkokat és a modulillesztőket azért hozták létre, hogy a tesztelőnek ne kelljen manuálisan generálnia a kódot.

A szürke végrehajtásának lépései Box A tesztelés a következő:

• 1. lépés: A bemenetek azonosítása.
• 2. lépés: A kimenetek azonosítása.
• 3. lépés: Határozza meg a főbb útvonalakat.
• 4. lépés: Azonosítsa az alfunkciókat.
• 5. lépés: Alfüggvények bemeneteinek kidolgozása.
• 6. lépés: Kimenetek kidolgozása az alfunkciókhoz.
• 7. lépés: Hajtsa végre az alfüggvények tesztesetét.
• 8. lépés: Ellenőrizze az alfüggvények helyes eredményét.
• 9. lépés: Ismételje meg a 4–8. lépéseket a többi alfunkcióval.
• 10. lépés: Ismételje meg a 7. és 8. lépést a többi alfunkcióval.

A Grey tesztesetei Box A tesztelés kiterjedhet többek között a grafikus felhasználói felülettel, a biztonsággal, az adatbázissal, a böngészővel és az operációs rendszerrel kapcsolatos kérdésekre. Minden generált esethez továbbra is szükség van a szokásos próbaper attribútumok, mivel egy olyan eset, amelyet nem lehet reprodukálni a saját leírásából, kevéssé hasznos a regresszió során.

Ahol szürke Box Tesztelést használnak

A technika ott vívja ki a helyét, ahol egy hibát csak két réteg egyidejű vizsgálatával lehet diagnosztizálni. A következő esetekben alkalmazzák leggyakrabban:

• Adatbázis-alapú munkafolyamatok: Egy művelet végrehajtása a felhasználói felületen keresztül történik, majd a kapott sorokat közvetlenül lekérdezi a rendszer annak megerősítésére, hogy az értékek, típusok és kapcsolatok a kívánt módon lettek tárolva.
• Webszolgáltatások és API-k: Egy kérés elküldésre kerül, és a válasz állapotát, a fejléceket és a hasznos adatot ellenőrzik a közzétett con alapján.tract, ami a mindennapi formája API tesztelés.
• Integrációs pontok: A két modul közötti határt átlépő üzeneteket a rendszer megvizsgálja, miközben mindkét modult futó rendszerként, nem pedig forrásfájlként kezeli.
• Biztonsági felmérés: Egy penetrációs tesztelő egy normál felhasználói fiókkal és egy architektúra áttekintéssel reprodukálja egy bennfentes pozícióját, ami a standard szürke dobozos elköteleződési modellnek felel meg.
• Webalkalmazások és grafikus felhasználói felületek: A hibás linkek, az árva oldalak, a munkamenet-kezelés és a kliensoldali validáció mind ellenőrzésre kerül a jelölőnyelv és a kérésfolyam részleges láthatósága mellett.

Mindezek alapján a rendszerhibák összköltsége csökken, mivel a problémákat még azelőtt észlelik és megmagyarázzák, mielőtt azok továbbjutnának a folyamatban. rendszertesztelés vagy termelés.

szürke Box Tesztelő eszközök

Egyetlen eszköz sem teljesít szürke színt Box Önmagában tesztelve. A kategóriának szüksége van egy interfész-illesztőprogram, egy ellenőrző eszköz az alatta lévő réteghez, és egy módszerre, amellyel a kettőt együtt lehet szkriptelni.

• API és webszolgáltatás-kliensek mint például Postman és a SoapUI, kérések kiadására és állapotkódokra, valamint választörzsekre vonatkozó érvényesítésre szolgál.
• Adatbázis-kliensek és SQL lekérdezőeszközök, a felületművelet utáni megőrzött állapot ellenőrzésére szolgál.
• Böngészőfejlesztő eszközök és HTTP proxyk mint például Burp Suite, a biztonságorientált munkamenetek során a kérések vizsgálatára és módosítására szolgál.
• UI automatizálási keretrendszerek mint például Selenium, amely a megjelenítési réteget egy automatizálási tesztelés tovább.
• Napló- és monitorozó eszközök, amely egy megfigyelt hiba és az alkalmazás által abban a pillanatban belsőleg rögzített adatok összefüggésbe hozására szolgál.

A választás kevésbé számít, mint a bekötés: hacsak az interfészillesztő és az ellenőrzési lépés nem ugyanabban a szkriptelt folyamatban fut, az eredmény két különálló manuális ellenőrzés lesz egyetlen szürke dobozos teszt helyett.

szürke Box Kihívások tesztelése

A részleges láthatóság olyan problémákat vet fel, amelyekkel egyik tiszta módszer sem rendelkezik, és a csapatok a következőkkel találkoznak leggyakrabban:

• Amikor egy tesztelés alatt álló komponens valamilyen hibába ütközik, megszakíthatja a folyamatban lévő műveletet, és a szekvencia többi részét végrehajtatlanul hagyhatja.
• Egy teszt végrehajtódhat teljes egészében, miközben az eredmény tartalma helytelen, így az ellenőrzési lépésnek az értékeket kell ellenőriznie, nem pedig a befejezést.
• A teljes kódútvonal lefedettség nem érhető el, mivel a tesztelő soha nem lát minden olyan ágat, amelyet a white box tesztelés elérne.
• A tesztek alapjául szolgáló tervdokumentáció elavult lehet, és egy elavult séma vagy interfészspecifikáció csendben érvényteleníti a teszttervet.
• A tesztelőknek mind a szakterület ismeretére, mind a technikai mélységre szükségük van, ami egy szűkebb készségprofil a toborzáshoz.
• Elosztott és erősen hasizomtracA ted architektúrák megnehezítik a megfigyelt hibák egy adott belső komponensnek való tulajdonítását.

Ezek a korlátok a szürkehályog kezelése mellett szólnak. Box A tesztelés egyetlen rétegként történik a sok közül, nem pedig a többi helyettesítőjeként, ami a szélesebb körben érvényesülő hangsúlyt kap. szoftvertesztelési technikák és a a szoftvertesztelés típusaiTermészetes módon helyezkedik el mellette funkcionális tesztelés és a specifikációvezérelt megközelítések, mint például modellalapú tesztelés.

GYIK