close
Vážení uživatelé,
16. 8. 2020 budou služby Blog.cz a Galerie.cz ukončeny.
Děkujeme vám za společně strávené roky!
Zjistit více

Techniky testování SW

27. ledna 2008 v 6:28 | LadyLoba |  Testování SW
(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

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:
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)

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

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

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

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ů.

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ů.

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.

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ů.

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.

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ů

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í 

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 :
  1. Identifikace problémů - zacílit se na problémy a chybějící prvky, ne na osobu.
  2. Dodržování pravidel - role, množství revidovaného kódu, co se od revize očekává.
  3. Příprava - jednotlivý účastníci různé role, většina chyb se objeví již při přípravě.
  4. 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.

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Í

Ú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.

Ú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.
 

Buď první, kdo ohodnotí tento článek.

Komentáře

1 Miroslav Čermák Miroslav Čermák | E-mail | Web | 10. února 2009 v 18:13 | Reagovat

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

2 EllSmah EllSmah | E-mail | Web | 13. ledna 2020 v 5:03 | Reagovat

Viagra Achat Libre  <a href=http://cialibuy.com>cialis 5 mg</a> Pyridium No Script Needed Low Price Priligy Espana Precio

Nový komentář

Přihlásit se
  Ještě nemáte vlastní web? Můžete si jej zdarma založit na Blog.cz.
 

Aktuální články

Reklama