Zajištění kvality programového vybavení - testování

Základy testování

• Proč se to dělá? • Kvalita software • 100% testování není možné Různé pohledy: • Vývojářské testování (testy komponent, integrační, systémové …) • Akceptační – ověření funkce dle očekávání • Ohodnocení kvality • Provozní testování

Psychologie testování: • Záleží na stupni nezávislosti

7 principů testování

1. Ukazuje přítomnost chyb – Může ukázat na přítomnost chyb, neukazuje ale že žádné nejsou

2. Vyčerpávající testování je nemožné – Testování všech kombinací je nemožné (až na triviální případy)

3. Včasné testování – test.aktivity musejí v rámci živ.cyklu SW začít co nejdříve

4. Shlukování chyb – Jedna chyba na sebe „nabaluje“ další

5. Pesticidní paradox – Opakované testy nenaleznou nic – opakovat, revidovat

6. Testování je závislé na kontextu – Test. je vykonáváno odlišně v různých kontextech (banka X e-shop)

7. Falešná představa o neexistenci omylů – Nalezení a opravení chyb nepomůže, když je systém nepoužitelný

Úrovně testování

Testování komponent • Základ testování: Požadavky na komponenty, detailní návrh, kód • Objekty testování: Komponenty, programy, konverze dat, DB

moduly • Typicky se realizuje přístupem k testovanému kódu s pomocí unit

test frameworku • Chyby opravovány hned bez formálního řízení • Test driven development – vývoj v malých cyklech – test první Integrační testování • Základ testování: Návrh SW, Achitektura, Workflow, příklady použití • Objekty testování:Podsystémy,impl.databází, infrastruktura,

ozhranní • Ověřuje rozhranní mezi komponentami, interakce různých částí

Úrovně testování Systémové testování • Základ testování: Specifikace požadavků systému a SW, případy užití, funkcionální

specifikace, reporty a analýzy rizik • Objekty testování: Systémové, uživ. a operační manuály, konfig. systému a konfig.

Data • Chování celého systému / produktu • Testovací prostředí by mělo korespondovat s finálním – produkčním • Funkcionální i nefunkcionální požadavky Akceptační testování • Základ testování: Uživatelské a systémové požadavky, případy použití, byznys

procesy, reporty analýzy rizik • Objekty testování: Byznys procesy, provozní a údržbové procesy uživ.postupy,

formuláře, reporty, konfig. Data • Často realizované zákazníkem • Vyhodnocení připravenosti systému pro nasazení a používání

Typy testů – různé účely

• Funkcionální testování („co“ systém dělá) – Zkoumání externího chování SW (black box testing) – Založeny na funkcích a vlastnostech – Na všech úrovních testování

• Nefunkcionální testování („jak“ systém pracuje) – výkon, zátěžové testování, stres test., použitelnost, spolehlivost,

udržovatelnost, přenositelnost • Strukturální testování

– Zkoumání interní struktury systému (white box testing) – Měření pokrytí kódu, příkazů nebo rozhodování (stat.analýza) – Na všech úrovních ( architektura, byznys modely ..)

• Regresní testování – Opakované testování po modifikaci -> cíl je najít defekty zanesené

změnou

Proces vývoje testů

• Návrh testů na základě identifikace test.podmínek

• Specifikace testovacích případů • Specifikace testovacích procedur (pořadí činností

pro vykonání testu) • Snaha identifikovat test.podmínky (položka nebo

událost, která může být verifikována) • Sledovatelnost směrem od test.podmínek zpět ke

specifikacím a požadavkům -> účinná dopadová analýza a pokrytí

Specifikace test případu

• ID: identifikátor • Položky testu: stručný popis položek a vlastností, které

budou testovány • Specifikace vstupů: všechny vstupy (databáze. Soubory,

hodnoty z OS, atd.), specifikace vztahů mezi vstupy • Specifikace výstupů: všechny výstupy a vlastnosti (např

odezvy), definice přesných hodnot jednotlivých výstupů • Požadavky na prostředí: HW, SW, Ostatní (např. zaškolený

personál) • Speciální procedurální požadavky: omezení na

test.procedury (specifické nastavení atd.) • Mezipřípadové závislosti: seznam identifikátorů test.

Případů, které musí být vykonány před tímto případem

Kategorie technik návrhu testů

Cílem je identifikace test.podmínek, test. případů a test. dat Black-box testing • Založené na specifikaci – nic nevíme o vnitřní struktuře – vycházíme

z analýzy dokumentace testování • Funkcionální i nefunkcionální testování White-box testing • Založené na analýze struktury komponenty nebo systému • Používá se informace o tom, jak je SW vytvořen a z toho se odvozují

test. Případy • Rozsah pokrytí může být měřen pro existující test. Případy a další

test.případy se vytvoří pro zvýšení pokrytí

Techniky black-box testing Rozdělení ekvivalencí

– Vstupy rozděleny do skupin s očekávaným stejným chováním – Sekce ekvivalencí pro platná i neplatná data (mohou být nalezeny i pro výstupy,

vnitřní hodnoty, časově související hodnoty, parametry rozhraní) • Př.: Systém sledující délku hesla uživatele povoluje heslo min. 8 znaků a

max 64 znaků 1. Identifikujeme hraniční hodnoty 2. Určení sekcí platných i neplatných hodnot a očekávané výsledky testu 3. Vytvoření test. případu pro každou sekci

Techniky black-box testing

2. Analýza hraničních hodnot • •Chování na okraji rozdělení ekviv. může být nesprávné s

větší pravděpodobností, než chování uvnitř dané sekce

Rozšíření předchozího příkladu o testování na hranicích rozdělení

Techniky black-box testing

3. Testování rozhodovacích tabulek – Pro zachycení požadavků s logickými podmínkami

– Identifikování podmínky a činnosti systému

– Rozhodovací tab. obsahuje spouštěcí podmínky (často bool) pro všechny vstup. podmínky a výsledné činnosti pro každou kombinaci podmínek

– Každý sloupec odpovídá byznys pravidlu

– Standardem pokrytí je mít alespoň jeden test na každý sloupec v tabulce

Techniky black-box testing- příklad

• Systém musí rozhodnout, zda firma finančně přispěje svému zaměstnanci na důchodové spoření.Aby tak učinila, musí mít zaměstnanec založeno důchodové spoření a musí být ve firmě alespoň 3 měsíce.

Techniky black-box testing- příklad

• Transformace na testovací případy

Transformace na testovací případy

4. Testování přechodových stavů – Systém může dávat různou odpověď v závislosti na

aktuálních podmínkách nebo předcházející historii

– Stavy musejí být samostatelné, identifikovatelné a musí jich být konečně množství

– Stavová tabulka

– Testy se navrhují pro pokrytí typických nebo všech stavů, s cílem vykonat každý přechod, testovat neplatné přechody stavů

– Hlavně pro embedded SW a technickou automatizaci

Techniky black-box testing

5. Testování případů užití – Odvozeny z use cases – Mohou být na abstraktní úrovni (úroveň obch.procesu

nebo systému) – Obvykle základní a alternativní scénáře – Užitečné pro akceptační testování – Pomůžou odhalit integrační defekty způsobené

interakcí komponent – Definovány z pohledu uživatele – ne systému –

popisují co uživatel vidí a co dělá

Techniky white-box testing

Založené na idetifikované struktuře SW nebo systému

Příklady: • Úroveň komponenty: struktura SW komponenty,

tj. příkazy, rozhodnutí nebo větve • Integrační úroveň: strom volání (moduly volají

další moduly) • Systémová úroveň: struktura menu, web.stránky,

byznys procesu

Výběr testovacích technik

• Typ systému • Regulační standardy • Zákaznické / smluvní požadavky • Úroveň rizika • Typ rizika • Cíl testování • Dostupná dokumentace • Znalosti testerů • Čas a rozpočet • Životní cyklus vývoje • Modely případu užití • Předcházející zkušenosti

Nástroje

1. Management testování – Rozhraní pro vykonáváníí testů, sledování defektů,řízení

požadavků, reportování 2. Management požadavků

– Popisy požadavků, trasování požadavků 3. Management incidentů

– Uchovávají a řídí záznamy o incidentech a požadavcích na změnu

4. Navržení testů – Z návrhových modelů, kódu, GUI nebo z požadavků

5. Příprava testovacích dat – Manipulace s DB, soubory nebo přenosy dat

Nástroje Statické testování 1. Nástroje pro statickou analýzu

– Nalezení chyb před dynamickým testováním, analýza struktur a závislostí 2. Modelovací nástroje

– Validace modelů SW (např. fyzický dat.model pro rel.DB) Vykonávání a zaznamenávání testů 1. Nástroje pro vykonávání testů

– Automatické vykonávání testů, reporting, konfigurace 2. FW pro Unit test

– Usnadňuje testování komponent simulováním prostředí, ve kterém bude běžet 3. Komparátory testů

– Rozdíly mezi soubory, databázemi nebo výsledky testování 4. Měření pokrytí

Nástroje Výkon a monitorování 1. Nástroje pro dynamickou analýzu

– Testování komponent, integrační testování 2. Testování výkonu / stres testování

– Simulace zátěže Vykonávání a zaznamenávání testů 1. Nástroje pro vykonávání testů

– Automatické vykonávání testů, reporting, konfigurace 2. FW pro Unit test

– Usnadňuje testování komponent simulováním prostředí, ve kterém bude běžet 3. Komparátory testů

– Rozdíly mezi soubory, databázemi nebo výsledky testování 4. Měření pokrytí

Unit testy • 1. Izolované

– Není potřeba stavět celý dům, když je potřeba testovat zvonek • 2. Opakovatelné

– Test musí být spustitelný pro každého, nezávisle na tom jaké má nastavení prostředí

• 3. Rychlé – Čas jsou peníze

• 4. Self documenting – Není potřeba popisovat jak komponenta pracuje, stačí se podívat na test

Nástroje: • JUnit (http://www.junit.org) • NUnit (http://www.nunit.org) • Test NG (http://testng.org)