Způsoby detekce chyb v software, metody testování.

Z Na státnice zvesela!

Obsah [skrýt] 1 Způsoby detekce chyb 2 Úrovně testování 3 Whitebox 3.1 Pokrytí kódu 3.2 Jednotkové testy 3.3 Integrační testy 4 Blackbox 4.1 Smoke test 4.2 Zátěžové testy 4.3 Systémové testy 4.4 Hraniční testy 4.5 Návrh testovacích případů (data) 4.6 Shrnutí

[editovat] Způsoby detekce chyb

• testování
• ladění

[editovat] Úrovně testování

• jednotkové testování (unit test) - je testována funkcionalita specifické části kódu
• integrační testování (integration test) - jsou testovány komponenty a jejich interakce na základě rozhraní
• systémové testy (system test) - kompletní testy softwaru, zda splňuje dané požadavky
• systémové integrační testy (system integration test) - test integrace softwaru s dalšími softwary třetích stran
• akceptační testy - smoke test nového buildu a test zákazníkem po kompletním otestování

Více Wikipedia (ENG)

[editovat] Whitebox

• máme k dispozici zdrojové kódy programu, takže je to testování zaměřené na programovou logiku
• používá se k testování malých částí programů, jako jsou podprogramy nebo třídy (unit testy)
• měli bychom otestovat všechny možné logické cesty (if/then/else) v programu a tím dokázat jeho bezchybnost -> v praxi je to často nemožné, příliš mnoho cest

[editovat] Pokrytí kódu

• Tato metrika nám popisuje, do jaké míry testovací případy pokrývají zdrojový kód.
• Pokrytí všech příkazů (Statement coverage)

if(a<10 && b=5) b=b/a;. Oba příkazy (podmínku a přiřazení) bychom mohli pokrýt vstupními daty (a=2 a b=5) a pokrytí by bylo pořádku. Bohužel při vstupu a=0 by došlo k chybě dělení.

• Pokrytí větví (branch coverage)

se zaměřuje na větvení programu (podmínky, cykly, switch/case). Musíme tedy vytvořit takové testovací případy, které způsobí, že běh programu projde alespoň jednou všechny větve.

• Pokrytí všech kombinací podmínek v rozhodovacím výrazu (Multiple Condition Coverage)

oproti pokrytí větví vyžaduje, aby byly provedeny všechny možné kombinace vstupních hodnot. Např. Výraz (a && b && (c || (d && e))) vyžaduje 6 různých vstupních hodnot. Výraz (((a || b) && (c || d)) && e) jich vyžaduje 11, i když mají oba stejný počet operátorů i operandů.

• Pokrytí cest (Path Coverage) – vyžaduje, aby byla provedena každá možná cesta průběhu programu alespoň jednou.

[editovat] Jednotkové testy

• zaměřené na verifikaci malých jednotek softwarového návrhu (komponent, tříd)
• Jsou automatické
• Rozhraní (zda jednotka správně komunikuje s ostatními jednotkami)
• Lokální datové struktury (zda dočasně uložená data zachovávají svou integritu)
• Okrajové podmínky (zda modul pracuje správně na hranicích omezujících výpočet)
• Nezávislé cesty (zaručující, že každý příkaz bude proveden alespoň jednou)
• Cesty pro zpracování chyb

[editovat] Integrační testy

• Integrační testy se provádí hned po „složení“ systému.
• „velký třesk“ - celý systém se sestaví najednou ze všech možných součástí. (riskantní, pouze pro malé projekty)
• „inkrementální přístup“ - postupně přidáváme nové komponenty a hned systém testujeme. V praxi problematické, kvůli závislosti komponent.

[editovat] Blackbox

• Metoda testování bez znalosti kódu softwaru. Máme tedy k dispozici specifikaci softwaru a samotný software v podobě „černé skříňky”, tzn. že se nemůžeme podívat dovnitř, jak funguje.
• je doplňkem k metodě testování bílé skříňky, a tudíž se zaobírá jinými chybami.
  • nesprávné nebo zcela chybějící funkce
  • Chyby rozhraní
  • Chyby ve struktuře dat nebo externích databázích
  • Neočekávané chování
  • Chyby při inicializaci nebo ukončení

[editovat] Smoke test

• vznikla při výstupní kontrole elektrických spotřebičů, kdy se prostě zapojily do zásuvky a pokud se z nich nekouřilo, prošly testem.
• Aplikace se prostě po přeložení spustí a pokud něco dělá (a tím se nemyslí dumpování jádra), tak to projde testem.

[editovat] Zátěžové testy

• aplikací, které jsou dělané pro zpracovávání velkého množství dat, např. databáze, webové severy, distribuované výpočetní systémy.
• Princip testu: postupně zvyšujeme zátěž dokud nenarazíme na chybu aplikace nebo na určitou mez.
• Pomocí této metody se dá otestovat, jestli případná havárie nezpůsobí ztrátu dat nebo dokáže odhalit chyby, které by se normálně neprojevily.

[editovat] Systémové testy

• Účelem této metody, je otestovat systém jako celek. Testují se tedy různé charakteristiky, např. doba odezvy, kompatibilita, instalovatelnost atd.

[editovat] Hraniční testy

• vstupní hodnoty velmi blízko hraničním hodnotám často způsobují aplikacím velké problémy
• výhody:
  • velmi dobré rozeznání budoucích chyb
  • velmi jednoduché a malé testy
• nevýhody
  • nevyzkouší všechny možnosti vstupních hodnot
  • nehledí na závislosti vstupních hodnot - tím je myšleno, že vstup složený z hodnot např. 1, 2, 3, nekontroluje jako všechny kombinace vstupních hodnot

---

[editovat] Návrh testovacích případů (data)

• Dobrý test je takový test, který najde chybu.
• Dobrý test bude vyvolávat co nejvíce vstupních podmínek, a tím omezí celkový počet potřebných testovacích případů.
• Testovací případy budou typicky obsahovat:
  • příliš málo dat nebo žádná data
  • příliš mnoho dat
  • neplatná data (např. negativní počet zaměstnanců)

[editovat] Shrnutí

• Existuje velké množství metodik, které mají své silné, ale bohužel i slabé stránky, a proto je dobré připravovat testovací metody pomocí více metod.
• Testy vytvářet souběžně s aplikací, ne až nakonec.
• Testy provádět v logické posloupnosti (nejprve smoketest a potom až zátěžový test)

(zdroj: Kubovec - Okruhy otázek ke státní závěrečné zkoušce z předmětu - Návrh informačních systémů (NIS) 2005/2006)