White box test

White box testování, známé též jako glass box, clear box, open box nebo také strukturální, předpokládá znalosti vnitřní struktury.

Přesněji řečeno vyžaduje znalost vnitřních datových a programových struktur a také toho, jak je systém naimplementován. Testerovi jsou v případě white box testování poskytnuty veškeré informace, to znamená, že má k dispozici nejen příslušnou dokumentaci, ale i binární a zdrojový kód testované aplikace. Tester musí zdrojovému kódu porozumět a analyzovat ho. Někdy se tomuto způsobu testování říká také audit zdrojového kódu. Zahraniční literatura má pro tuto činnost označení ‘code-review‘ exercise. White box testování může probíhat zcela automatizovaně nebo ručně. V praxi se však velice často oba tyto způsoby vhodně kombinují. Existují v zásadě dva typy analytických nástrojů, ty které požadují zdrojový kód a ty, které jsou schopny v případě, že zdrojový kód není k dispozici, provést automatickou dekompilaci binárního kódu a zdrojový kód si de-facto vyrobit a ten poté řádek po řádku analyzovat.

Využití

White box testování je velice vhodné např. pro webové služby a to obzvlášť na počátku vývojového cyklu, kdy vývojář a tester mohou spolupracovat na odhalování chyb. White box test můžeme využít ke zjištění, jak se systém chrání před neautorizovaným přístupem, jak je řízen přístup k jednotlivým částem aplikace a k datům, jak je implementována integritní ochrana nebo jak jsou ukládána hesla. White box test můžeme také použít k nalezení nežádoucího kódu, bezpečnostních chyb a zranitelností.

Nalezení nežádoucího kódu považuji vůbec za největší přínos white box testování. V podstatě v jakékoliv aplikaci může být přítomen nežádoucí kód a aplikace přitom může pracovat zcela správně a v souladu se specifikací. Jde o to, že naprostá většina testů je zaměřena na to, aby se ověřilo, že aplikace funguje správně, resp. že dělá to co má, nebo ještě lépe, že jsou splněny všechny funkční a nefunkční požadavky uvedené ve specifikaci. A v tom je kámen úrazu. Málokdo totiž testuje, zda aplikace náhodou nedělá ještě něco navíc.

Takový nežádoucí kód může provádět v podstatě cokoliv a záleží čistě na fantazii vývojáře, co to bude a kdy se takový kód spustí. Zda bude kód provádět nějakou činnost soustavně nebo bude skrytě čekat na výskyt nějaké konkrétní události. Takovou událostí může být třeba zaslání předem definovaného typu zprávy, stisknutí určité kombinace kláves, zadání určitého jména a hesla, které je uloženo přímo v autentizačním modulu.

Výsledkem činnosti takového kódu pak může např. být získání neoprávněného přístupu do aplikace, převod finančních prostředků na jiný účet, ukládání informacích o klientech společnosti a jejich transakcích do úložiště do kterého má útočník přístup nebo zasílání vybraných informací do e-mailové schránky útočníka, pro tento účel zřízené.

V rámci objektivity je nutné podotknout, že nežádoucí kód nemusel být do aplikace začleněn jen úmyslně, ale mohl zde zůstat i proto, že vývojář si třeba nechal v rámci ladění aplikace někam zapisovat výstup a pak na to zapomněl a kód neodstranil. Čím později se na to přijde, tím větší může být problém dokázat, zda byl nežádoucí kód do aplikace začleněn úmyslně nebo jeho výskyt v aplikaci pramení z nedbalosti. Ať už je ale příčina existence nežádoucího kódu v aplikaci jakákoliv, určitě se shodneme na tom, že je nutné takovýto nežádoucí kód včas odhalit a odstranit.

Při black box nebo grey box testování by k odhalení nežádoucího kódu mohlo dojít spíš náhodou. Např. tak, že by nežádoucí kód svou činností zabíral příliš mnoho místa na disku nebo v paměti, spotřebovával větší šířku pásma, než se předpokládalo, způsoboval nárůst počtu I/O operací, zatěžoval procesor atd. Na to, že se kód nějak prozradí sám, však nelze spoléhat.

Výhody

• Včasné odhalování chyb – analýza zdrojového kódu umožní odhalit chyby, kterých se programátor dopustil ještě dřív, než je kód zkompilován.
• Odhalení nežádoucího kódu – je třeba si uvědomit, že program může kromě požadovaných operací provádět i některé další nežádoucí operace, které mohou zůstat během jiných testů zcela nepovšimnuty.

Nevýhody

• Náročnost – vyžaduje výbornou znalost cílového systému, testovacích nástrojů a programovacích jazyků.
• Vysoké náklady – požaduje specializované nástroje jako jsou analyzátory zdrojového kódu, debuggery atd.

Štítky: Testování SW

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.