(výtah z knížky Ron Patton - Testování SW)
Vyšší úroveň revize specifikací
Charakteristika: Statické testování černé skřínky
Fáze testování / etapa testování: Sběr požadavků a plánování testů, Návrh testů
Typ testu: Test dokumentace (specifikace je dokument)
Popis:
Specifikaci lze testovat vždy, bez ohledu na její formát. Může být v podobě psaného dokumentu, grafických schémat, nebo kombinace obojího. Lze testovat i nepsanou specifikaci - tester se bude dotazovat lidí, kteří navrhují a píší software.
První krok - tester se nebude se vrhat na drobné chyby, ale bude hledat problémy zásadní povahy.
Varianta 1: Představí si, že je zákazník.
Jestliže projde a zkontroluje určitou část specifikace a nerozumí jí, nepředpokládá implicitně, že je v pořádku, a nepokračujte dále. Nakonec bude muset podle této specifikace postavit budoucí testy. Je dobré tomu porozumět co nejdříve.
Varianta 2: Prozkoumá stávající standardy a zásady
Rozdíl mezi standardem a zásadou je ve stupni dodržování. Standard je přísnější podoba normy než zásada. Standardy je nutno dodržovat, zásady je vhodné dodržovat.
Příklady standardů a zásad: Firemní terminologie a konvence, oborové požadavky, vládní standardy, GUI standardy, hardwarové a síťové standardy.
Varianta 3: Reviduje a otestuje podobný SW
Jedna z nejlepších metod, jak porozumět cílové podobě produktu, je prozkoumat podobný problém.
Při zkoumání konkurenčního výrobku je vhodné sledovat:Velikost, Složitost, Testovatelnost, Kvalitu a spolehlivost.
Vstupy:
Varianta 1: Psaná specifikace, nebo někdo kdo navrhuje SW, ochotný odpovídat na dotazy testerů.
Varianta 2: Navíc potřebuje seznam standardů a zásad
Varianta 3: Podobný software, čas si tento podobný SW vyzkoušet
Fáze testování / etapa testování: Sběr požadavků a plánování testů, Návrh testů
Typ testu: Test dokumentace (specifikace je dokument)
Popis:
Specifikaci lze testovat vždy, bez ohledu na její formát. Může být v podobě psaného dokumentu, grafických schémat, nebo kombinace obojího. Lze testovat i nepsanou specifikaci - tester se bude dotazovat lidí, kteří navrhují a píší software.
První krok - tester se nebude se vrhat na drobné chyby, ale bude hledat problémy zásadní povahy.
Varianta 1: Představí si, že je zákazník.
Jestliže projde a zkontroluje určitou část specifikace a nerozumí jí, nepředpokládá implicitně, že je v pořádku, a nepokračujte dále. Nakonec bude muset podle této specifikace postavit budoucí testy. Je dobré tomu porozumět co nejdříve.
Varianta 2: Prozkoumá stávající standardy a zásady
Rozdíl mezi standardem a zásadou je ve stupni dodržování. Standard je přísnější podoba normy než zásada. Standardy je nutno dodržovat, zásady je vhodné dodržovat.
Příklady standardů a zásad: Firemní terminologie a konvence, oborové požadavky, vládní standardy, GUI standardy, hardwarové a síťové standardy.
Varianta 3: Reviduje a otestuje podobný SW
Jedna z nejlepších metod, jak porozumět cílové podobě produktu, je prozkoumat podobný problém.
Při zkoumání konkurenčního výrobku je vhodné sledovat:Velikost, Složitost, Testovatelnost, Kvalitu a spolehlivost.
Vstupy:
Varianta 1: Psaná specifikace, nebo někdo kdo navrhuje SW, ochotný odpovídat na dotazy testerů.
Varianta 2: Navíc potřebuje seznam standardů a zásad
Varianta 3: Podobný software, čas si tento podobný SW vyzkoušet
Nižší úroveň revize specifikací
Charakteristika: Statické testování černé skřínky
Fáze testování / etapa testování: Sběr požadavků a plánování testů, Návrh testů
Typ testu: Test dokumentace (specifikace je dokument)
Popis:
Fáze testování / etapa testování: Sběr požadavků a plánování testů, Návrh testů
Typ testu: Test dokumentace (specifikace je dokument)
Popis:
Druhý krok hledání chyb ve specifikaci.
Přehled atributů, zda je specifikace:
Úplná; Správná; Přesná, jednoznačná a jasná; Konzistentní; Relevantní; Proveditelná; Bez kódu; Testovatelná
Přehled terminologie specifikace - tester zkontroluje jak se v daném kontextu používají problémová slova:
Vždy, nikdy, každý, všechny, žádný
Určitě, tudíž, zřejmě, jasně, evidentně
Něco, někdy, často, obvykle, obyčejně, zpravidla, většina, většinou
A tak dále, a tak podobně, jako například, třeba
Dobrý, rychlý, laciný, efektivní, stabilní, malý
Zpracováno, ošetřeno, zamítnuto, přeskočeno, vyloučeno
Jestliže … pak .. (ale chybí Jinak)
Určitě, tudíž, zřejmě, jasně, evidentně
Něco, někdy, často, obvykle, obyčejně, zpravidla, většina, většinou
A tak dále, a tak podobně, jako například, třeba
Dobrý, rychlý, laciný, efektivní, stabilní, malý
Zpracováno, ošetřeno, zamítnuto, přeskočeno, vyloučeno
Jestliže … pak .. (ale chybí Jinak)
Vstupy:
Psaná specifikace, nebo někdo kdo navrhuje SW, schopný a kompetentní odpovídat na dotazy testerů a záznam z těchto dotazů
Badatelské testování
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Provádění testů
Typ testu: Test funkcionality, Systémový test
Popis:
Chybí specifikace. Tester je posazen k hotovému SW. Za specifikaci musí považovat SW. Metodicky jej prozkoumá, poznamená co SW dělá, postupně zmapuje všechny funkce a získá "specifikaci".
Pak postupujte dalšími metodami dynamického testování černé skřínky.
Vstup:
Hotový SW produkt
Fáze testování / etapa testování: Provádění testů
Typ testu: Test funkcionality, Systémový test
Popis:
Chybí specifikace. Tester je posazen k hotovému SW. Za specifikaci musí považovat SW. Metodicky jej prozkoumá, poznamená co SW dělá, postupně zmapuje všechny funkce a získá "specifikaci".
Pak postupujte dalšími metodami dynamického testování černé skřínky.
Vstup:
Hotový SW produkt
Testy splněním a testy selháním
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test funkcionality, Systémový test, regresní test
Popis:
Klasický přístup k testování.
Při návrhu a provádění testových případů se prioritně provádí testy splněním. Nejdříve je nutno ověřit, zda SW je schopen vůbec fungovat, a pak do něj začít "mlátit kladivem".
Vstup:
Pro návrh testů: Specifikace.
Pro provádění testů: Návrh testů, Testové případy
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test funkcionality, Systémový test, regresní test
Popis:
Klasický přístup k testování.
Při návrhu a provádění testových případů se prioritně provádí testy splněním. Nejdříve je nutno ověřit, zda SW je schopen vůbec fungovat, a pak do něj začít "mlátit kladivem".
Vstup:
Pro návrh testů: Specifikace.
Pro provádění testů: Návrh testů, Testové případy
Rozdělení tříd ekvivalentních případů
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test funkcionality, Systémový test, Regresní test
Popis:
Třída ekvivalence, neboli množina ekvivalentních případů, je taková množina testových případů, která testuje stejnou věc nebo odhaluje stejnou chybu.
Tester / Návrhář testů hledá, jak vhodně seskupit podobné vstupní hodnoty, podobné výstupní hodnoty a podobné činnosti softwaru. Tyto skupiny pak tvoří potřebné třídy ekvivalence.
Musí si však dávat pozor, aby počet testových případů nezredukoval pod únosnou mez.
Vstup:
Seznam testových případů
Zkušený tester
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test funkcionality, Systémový test, Regresní test
Popis:
Třída ekvivalence, neboli množina ekvivalentních případů, je taková množina testových případů, která testuje stejnou věc nebo odhaluje stejnou chybu.
Tester / Návrhář testů hledá, jak vhodně seskupit podobné vstupní hodnoty, podobné výstupní hodnoty a podobné činnosti softwaru. Tyto skupiny pak tvoří potřebné třídy ekvivalence.
Musí si však dávat pozor, aby počet testových případů nezredukoval pod únosnou mez.
Vstup:
Seznam testových případů
Zkušený tester
Testovaní dat - Testování hraničních případů
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test funkcionality, Systémový test, Regresní test, Test uživatelského prostředí
Popis:
Hraniční podmínky představují jakékoli situace na hraně plánovaných operačních limitů daného SW.
Test zkoumá, co to se SW udělá, když mu zadáme hodnoty těsně pod limitem, přesný limit a nad limitem. Je důležité neustále vyhledávat hraniční situace v každém SW. Čím se víc hledá, tím víc hranic je odhaleno. A obvykle je tam mnoho chyb.
Dalším zdrojem chyb můžou být v místech tzv. subhraniční podmínky:
Např. mocnina dvou nebo tabulka ASCII
Tester nezapomíná přidávat nově nalezené limity do seznamu limitů SW.
Vstupy:
Pro návrh: Seznam limitů SW.
Pro testování: Seznam testových případů.
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test funkcionality, Systémový test, Regresní test, Test uživatelského prostředí
Popis:
Hraniční podmínky představují jakékoli situace na hraně plánovaných operačních limitů daného SW.
Test zkoumá, co to se SW udělá, když mu zadáme hodnoty těsně pod limitem, přesný limit a nad limitem. Je důležité neustále vyhledávat hraniční situace v každém SW. Čím se víc hledá, tím víc hranic je odhaleno. A obvykle je tam mnoho chyb.
Dalším zdrojem chyb můžou být v místech tzv. subhraniční podmínky:
Např. mocnina dvou nebo tabulka ASCII
Tester nezapomíná přidávat nově nalezené limity do seznamu limitů SW.
Vstupy:
Pro návrh: Seznam limitů SW.
Pro testování: Seznam testových případů.
Testovaní dat - Výchozí, prázdná, nevyplněná, nedefinovaná, nulová a žádná hodnota
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test uživatelského prostředí
Popis:
Testy zaměřené na to jak zareaguje SW na výchozí, prázdnou, nevyplněnou, nedefinovanou, nulovou nebo žádná hodnotu.
Vstupy:
Pro návrh testů: Specifikace a návrh GUI.
Pro testování: Hotové GUI, seznam testových případů.
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test uživatelského prostředí
Popis:
Testy zaměřené na to jak zareaguje SW na výchozí, prázdnou, nevyplněnou, nedefinovanou, nulovou nebo žádná hodnotu.
Vstupy:
Pro návrh testů: Specifikace a návrh GUI.
Pro testování: Hotové GUI, seznam testových případů.
Testovaní dat - Neplatné, chybné, nesprávné a nesmyslné údaje
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test uživatelského prostředí, Systémový test
Popis:
Tester zadává neplatné, chybné, nesprávné a nesmyslné údaje za účelem shodit systém.
Toto testování nemá žádná pevná pravidla.
Vstupy:
Testovaný produkt.
Znalost, co je nesmysl.
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test uživatelského prostředí, Systémový test
Popis:
Tester zadává neplatné, chybné, nesprávné a nesmyslné údaje za účelem shodit systém.
Toto testování nemá žádná pevná pravidla.
Vstupy:
Testovaný produkt.
Znalost, co je nesmysl.
Testovaní stavů
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test uživatelského prostředí, Systémový test
Popis:
Tester si vytvoří mapu stavů a přechodů z hlediska uživatele systému.
Potom se pokusí projít v testech všemi stavy alespoň jednou, projít stavy, které vypadají na první pohled jako nejpravděpodobnější, projít nejméně obvyklou cestu mezi stavy, a všechny chybové stavy a návraty z nich, projede náhodně nějakými stavy.
Vstupy:
Testovaný SW.
Extra čas na záznam stavů.
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Test uživatelského prostředí, Systémový test
Popis:
Tester si vytvoří mapu stavů a přechodů z hlediska uživatele systému.
Potom se pokusí projít v testech všemi stavy alespoň jednou, projít stavy, které vypadají na první pohled jako nejpravděpodobnější, projít nejméně obvyklou cestu mezi stavy, a všechny chybové stavy a návraty z nich, projede náhodně nějakými stavy.
Vstupy:
Testovaný SW.
Extra čas na záznam stavů.
Testovaní stavů selháním - Závodění - race condition
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Výkonnostní,objemové a zátěžové testy
Popis:
Závodění - race condition - Situace, kdy hrozí vznik chyby:
Ukládání a načítaní stejného dokumentu.
Sdílení stejné tiskárny, komunikačního portu, nebo jeho periferie.
Stisky kláves nebo odesílaní klepnutí myši v průběhu zavádění SW nebo změny jeho stavu.
Uzavíraní nebo spouštění více instancí daného SW ve stejném okamžiku.
Současný přístup ke společné databázi různých programů.
Vstupy:
Pro návrh - seznam rizikových situací.
Pro testy - seznam testových případů,dle konkrétního testu - synchronizovanou práci více testerů, nebo testovací nástroj simulující multitaskingové operace, nastavení příslušných testů na testovacím nástroji.
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Výkonnostní,objemové a zátěžové testy
Popis:
Závodění - race condition - Situace, kdy hrozí vznik chyby:
Ukládání a načítaní stejného dokumentu.
Sdílení stejné tiskárny, komunikačního portu, nebo jeho periferie.
Stisky kláves nebo odesílaní klepnutí myši v průběhu zavádění SW nebo změny jeho stavu.
Uzavíraní nebo spouštění více instancí daného SW ve stejném okamžiku.
Současný přístup ke společné databázi různých programů.
Vstupy:
Pro návrh - seznam rizikových situací.
Pro testy - seznam testových případů,dle konkrétního testu - synchronizovanou práci více testerů, nebo testovací nástroj simulující multitaskingové operace, nastavení příslušných testů na testovacím nástroji.
Testovaní stavů selháním - Opakování, stres, zátěž
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Výkonnostní,objemové,zátěžové a konfigurační testy
Popis:
Test opakování - jedna stejná operace se neustále opakuje - cíl hledat tzv. díry v paměti
Stresové testování - zhoršení ideálních podmínek: zmenšit množství paměti, zmenšit diskový prostor, nasadit pomalý procesor, pomalý modem apod.
Zátěžové testování - opak stresu - dáme mu všeho moc a naplníme ho obrovským objemem dat, nebo připojíme co nejvíce tiskáren apod. Zátěžový test by měl běžet hodně dlouho - důležité zejména pro programy, které by měly běžet nepřetržitě bez restartu.
Doporučuje se kombinovat testy opakováním, stresové testy a zátěžové testy.
Vstupy:
Seznam nejčastěji prováděních operací.
Vhodný testovací nástroj pro opakování operací.
Více HW konfigurací pro stresové testování.
Vhodný nástroj, který "nakrmí" systém obrovským množstvím dat.
Extra HW na kterém budou testy běžet a nebudou mít vliv na ostatní testy.
Nastavení/naprogramování příslušných testů do softwarových nástrojů
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Výkonnostní,objemové,zátěžové a konfigurační testy
Popis:
Test opakování - jedna stejná operace se neustále opakuje - cíl hledat tzv. díry v paměti
Stresové testování - zhoršení ideálních podmínek: zmenšit množství paměti, zmenšit diskový prostor, nasadit pomalý procesor, pomalý modem apod.
Zátěžové testování - opak stresu - dáme mu všeho moc a naplníme ho obrovským objemem dat, nebo připojíme co nejvíce tiskáren apod. Zátěžový test by měl běžet hodně dlouho - důležité zejména pro programy, které by měly běžet nepřetržitě bez restartu.
Doporučuje se kombinovat testy opakováním, stresové testy a zátěžové testy.
Vstupy:
Seznam nejčastěji prováděních operací.
Vhodný testovací nástroj pro opakování operací.
Více HW konfigurací pro stresové testování.
Vhodný nástroj, který "nakrmí" systém obrovským množstvím dat.
Extra HW na kterém budou testy běžet a nebudou mít vliv na ostatní testy.
Nastavení/naprogramování příslušných testů do softwarových nástrojů
Testovaní stavů selháním - další možné přístupy
Charakteristika: Dynamické testování černé skřínky
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Testy funkcionality, Systémové testy, Regresní testy, Testy uživatelského rozhraní
Popis:
V1: Tester se chová jako hloupý uživatel
V2: Tester hledá chyby tam, kde jsme již nějaké nalezli
V3: Tester hledá chyby na základě zkušeností, intuice a předtuchy
Vstupy:
V1: nezkušený uživatel nebo začínající uživatel
V2: nalezení chyby
V3: zkušený tester nebo vědma nebo křišťálovou koulí
Fáze testování / etapa testování: Návrh testů, Provádění testů
Typ testu: Testy funkcionality, Systémové testy, Regresní testy, Testy uživatelského rozhraní
Popis:
V1: Tester se chová jako hloupý uživatel
V2: Tester hledá chyby tam, kde jsme již nějaké nalezli
V3: Tester hledá chyby na základě zkušeností, intuice a předtuchy
Vstupy:
V1: nezkušený uživatel nebo začínající uživatel
V2: nalezení chyby
V3: zkušený tester nebo vědma nebo křišťálovou koulí
Formální revize
Charakteristika: Statické testování bílé skřínky
Fáze testování / etapa testování: Unit test
Typ testu: Revize kódu
Popis:
Odpovědnost konkrétních osob za statické testování bílé skřínky se v jednotlivých vývojových týmech liší. Někde si revizi řídí sami programátoři, SW testeři jsou přizvání jako nezávislí pozorovatelé.
V jiných týmech se tomuto úkolu věnují testeři, a programátora, který testovaný kód napsal, si s několika jeho kolegy naopak pozvou na pomoc při revizích. Každý vývojový tým si musí zvolit svoji cestu.
Formální revize má čtyři základní prvky :
Fáze testování / etapa testování: Unit test
Typ testu: Revize kódu
Popis:
Odpovědnost konkrétních osob za statické testování bílé skřínky se v jednotlivých vývojových týmech liší. Někde si revizi řídí sami programátoři, SW testeři jsou přizvání jako nezávislí pozorovatelé.
V jiných týmech se tomuto úkolu věnují testeři, a programátora, který testovaný kód napsal, si s několika jeho kolegy naopak pozvou na pomoc při revizích. Každý vývojový tým si musí zvolit svoji cestu.
Formální revize má čtyři základní prvky :
- Identifikace problémů - zacílit se na problémy a chybějící prvky, ne na osobu.
- Dodržování pravidel - role, množství revidovaného kódu, co se od revize očekává.
- Příprava - jednotlivý účastníci různé role, většina chyb se objeví již při přípravě.
- Písemná zpráva - zápis revize, shrnutí výsledků.
Vedlejší důsledky formální revize:
- Zlepšení komunikace mezi testery a vývojáři.
- Kvalita - vývojáře to vede k pečlivosti.
- Pospolitost týmu - lepší vzájemné porozumění.
- Řešení - při revizi se může najít řešení obtížných problémů.
Varianty:
V1: Revize partnerem - kamarádská revize - neformální
Výhoda - nejrychlejší metoda revize
V2: Průchody - programátor prezentuje svůj kód, oponenti (v předstihu dostali kód) se ptají
Mezi oponenty musí být alespoň jeden hodně zkušený programátor
V3: Inspekce - nejformálnější typ revize - jiný programátor prezentuje kód, a inspektoři revidují
Výhoda - kód se zreviduje a zároveň se ověří, že mu porozumí i jiní programátoři než autor
Nevýhoda - nejvíce "administrativní" práce
Vstupy:
Existuje kód k revidovaní.
Jsou určené role.
Existují podklady k přípravě.
Ochota vývojářů nechat si "hromadně" zrevidovat kód.
V1: Revize partnerem - kamarádská revize - neformální
Výhoda - nejrychlejší metoda revize
V2: Průchody - programátor prezentuje svůj kód, oponenti (v předstihu dostali kód) se ptají
Mezi oponenty musí být alespoň jeden hodně zkušený programátor
V3: Inspekce - nejformálnější typ revize - jiný programátor prezentuje kód, a inspektoři revidují
Výhoda - kód se zreviduje a zároveň se ověří, že mu porozumí i jiní programátoři než autor
Nevýhoda - nejvíce "administrativní" práce
Vstupy:
Existuje kód k revidovaní.
Jsou určené role.
Existují podklady k přípravě.
Ochota vývojářů nechat si "hromadně" zrevidovat kód.
Testování jednotek a integrace - zdola nahoru
Charakteristika: Dynamické testování bílé skřínky
Fáze testování / etapa testování: Unit testy a testování integrace
Typ testu: Revize kódu
Popis:
Třeba rozlišit cíle ladění a dynamického testování bílé skřínky.
Programátor píše kód programu, tester vyhledává chyby, přičemž někdy musí napsat také kousek kódu pro řízení testů, programátor dále opravuje nalezené chyby. Musí se zamezit duplicitní práci.
Dva přístupy: zdola nahoru a shora dolů
Pro testování zdola nahoru tester napíše vlastní moduly tzv. ovladače testů, které se "napíchnou" na moduly SW stejným způsobem, jako budou pracovat i skutečné moduly. Tým způsobem snadno "nakrmíte" moduly veškerými typy a množstvím dat. Na vyšší úrovni by se to generovalo obtížně.
Při testování shora dolů, se modul testera - maketa - bude pokoušet zvenčí ovlivňovat skutečný SW. Lze tak taky simulovat velké množství dat a ověřit veškeré funkce zobrazovacího modulu.
Vstupy:
Hotové kódy modulů.
Podrobná specifikace rozhraní.
Zkušený tester/programátor modulů.
Vhodný nástroj na tvorbu ovladačů testů a maket.
UPOZORNĚNÍ !!!
Je velice důležité vytvořit testové případy pro testy černé skřínky na základě specifikace, tedy před úpravou případů pro bílou skřínku. Nelze se spoléhat, že programátor správně pochopil specifikaci.
!!! UPOZORNĚNÍ
Fáze testování / etapa testování: Unit testy a testování integrace
Typ testu: Revize kódu
Popis:
Třeba rozlišit cíle ladění a dynamického testování bílé skřínky.
Programátor píše kód programu, tester vyhledává chyby, přičemž někdy musí napsat také kousek kódu pro řízení testů, programátor dále opravuje nalezené chyby. Musí se zamezit duplicitní práci.
Dva přístupy: zdola nahoru a shora dolů
Pro testování zdola nahoru tester napíše vlastní moduly tzv. ovladače testů, které se "napíchnou" na moduly SW stejným způsobem, jako budou pracovat i skutečné moduly. Tým způsobem snadno "nakrmíte" moduly veškerými typy a množstvím dat. Na vyšší úrovni by se to generovalo obtížně.
Při testování shora dolů, se modul testera - maketa - bude pokoušet zvenčí ovlivňovat skutečný SW. Lze tak taky simulovat velké množství dat a ověřit veškeré funkce zobrazovacího modulu.
Vstupy:
Hotové kódy modulů.
Podrobná specifikace rozhraní.
Zkušený tester/programátor modulů.
Vhodný nástroj na tvorbu ovladačů testů a maket.
UPOZORNĚNÍ !!!
Je velice důležité vytvořit testové případy pro testy černé skřínky na základě specifikace, tedy před úpravou případů pro bílou skřínku. Nelze se spoléhat, že programátor správně pochopil specifikaci.
!!! UPOZORNĚNÍ
Úplná analýza dat
Charakteristika: Dynamické testování bílé skřínky
Fáze testování / etapa testování: Unit testy, Integrační testy, testy funkcionality, systémové testy
Typ testu: Revize kódu, Ladění, Oprava chyb, u kterých není zřejmé jak nastaly
Popis:
Tester/Debugger sleduje toky dat.
Hledá subhraniční případy (např. vzorec, kde může nastat dělení nulou)
Záměrně vyvolává chyby - využitím vlastností ladicího programu
Vstupy:
Hotový kód.
Vhodný ladicí program nebo jiný vhodný nástroj.
Zkušený tester, specialista na dynamické testování bíle skřínky.
Fáze testování / etapa testování: Unit testy, Integrační testy, testy funkcionality, systémové testy
Typ testu: Revize kódu, Ladění, Oprava chyb, u kterých není zřejmé jak nastaly
Popis:
Tester/Debugger sleduje toky dat.
Hledá subhraniční případy (např. vzorec, kde může nastat dělení nulou)
Záměrně vyvolává chyby - využitím vlastností ladicího programu
Vstupy:
Hotový kód.
Vhodný ladicí program nebo jiný vhodný nástroj.
Zkušený tester, specialista na dynamické testování bíle skřínky.
Úplná analýza programového kódu
Charakteristika: Dynamické testování bílé skřínky
Fáze testování / etapa testování: Unit testy, Integrační testy, testy funkcionality, systémové testy
Typ testu: Revize kódu, Ladění, Oprava chyb, u kterých není zřejmé jak nastali
Popis:
Nejjednodušší forma - krokování kódu po řádcích, sledovat, které řádky jsme již navštívili.
Složitější formy - úplná analýza příkazů a řádků, úplná analýza větvení, úplná analýza podmínek
Může se stát, že objevíme kus kódu, na který se vůbec nebudeme moci dostat.
Výsledkem krokování může byt poznatek pro návrháře testů. Jaké nové testové případy třeba vytvořit pro lepší pokrytí programu testy.
Vstupy:
Hotový kód.
Vhodný ladicí program nebo jiný vhodný nástroj.
Zkušený tester, specialista na dynamické testování bíle skřínky.
Fáze testování / etapa testování: Unit testy, Integrační testy, testy funkcionality, systémové testy
Typ testu: Revize kódu, Ladění, Oprava chyb, u kterých není zřejmé jak nastali
Popis:
Nejjednodušší forma - krokování kódu po řádcích, sledovat, které řádky jsme již navštívili.
Složitější formy - úplná analýza příkazů a řádků, úplná analýza větvení, úplná analýza podmínek
Může se stát, že objevíme kus kódu, na který se vůbec nebudeme moci dostat.
Výsledkem krokování může byt poznatek pro návrháře testů. Jaké nové testové případy třeba vytvořit pro lepší pokrytí programu testy.
Vstupy:
Hotový kód.
Vhodný ladicí program nebo jiný vhodný nástroj.
Zkušený tester, specialista na dynamické testování bíle skřínky.

Pěkný článek a zajímavá kniha.