TESTOVÁNÍ SW

Filip Rubáček, 2013

Obsah prezentace2

1. Axiomy a základní pojmy testování.2. Testování webových prezentací a

aplikací.3. Testování specifikace.4. Funkční testování.

Hlavní zdroj prezentace3

Tato prezentace byla vytvořena na základě skvělé knihyod R. Patona: Testování softwaru, Computer Press, Praha 2002.

Axiomy testování4

1. Žádná aplikace nejde otestovat kompletně.2. Testování je postavené na riziku.3. Testování nemůže dokázat, že chyby

neexistují.4. Čím víc chyb je nalezeno, tím více chyb v

aplikaci je.5. Paradox pesticidů (čím více testujeme, tím

je aplikace více imunní).6. Ne všechny nalezené chyby se opraví.7. Specifikace aplikace není nikdy konečná.

Pojmy testování a jejich definice

5

Přesnost stejné (podobné) testy vedou k stejným (podobným)

výsledkům. Správnost

výstupy testů jsou pravdivé. Verifikace

testovaní, zda aplikace vyhovuje specifikaci. Validace

testovaní, zda aplikace vyhovuje požadavkům uživatele. Kvalita

stupeň dokonalosti. Spolehlivost

určuje, jak často havaruje.

Testování černé a bílé skříňky

6

Černá skříňka tester nemá přístup ke zdrojovým kódům

aplikace. Bílá skříňka

tester má přístup ke zdrojovým kódům aplikace.

Statické a dynamické testování

7

Statické testujeme co neběží. Pouze prohlížíme a

revidujeme (např. specifikace, zdrojový kód).

Dynamické software pustíme a zkoumáme.

Postupy při testování černé skříňky

8

Testy splněním (test-to-pass) kontrolujeme, zda aplikace splňuje

minimální funkčnost. Nehledáme hranice. Testy selháním (test-to-fail)

vyhovuje-li základní specifikace, testujeme hraniční případy a pokoušíme se vyprovokovat chyby.

TESTOVÁNÍ WEBOVÝCH PREZENTACÍ A APLIKACÍCo asi dělá SW tester?Základní pojmy.

Klíčová rizika nasazení aplikace

10

Aplikace nesplňuje specifikaci. Aplikace nemá dostatečný výkon a není

škálovatelná. Limitovaná kontrola nad výdaji do

infrastruktury. Omezené možnosti řízení externích

dodavatelů.

Nasazení webové aplikace

Přínosy pro firmu?

Proč testovat?11

Snížení nákladů na údržbu Odstranění chyby za provozu je 100 –

1000x nákladnější než během vývoji. Udržení kredibility

V sázce není jen renomé tvůrců systému … Vysoká komplexnost technologie

Zvýšené riziko chyb. Časté změny technologie.

Dynamický obsah Tvorba obsahu „za běhu“ vede k

nekonzistencím.

Existují důvody proč netestovat?

12

Na testování nezbývá čas Testování musí být paralelní s vývojem.

Testování je pracné Opakované využití. Automatizace.

Kolem testování je příliš „byrokracie“ Prostředky pro zlepšování procesu

testování. Automatizace nezbytné „byrokracie“.

Technologie je příliš složitá Některé aspekty nelze otestovat.

Co musíme testovat?13

Specifikace. Funkčnost – co všechno musí systém umět. Základ

specifikace. Použitelnost (usability) – srozumitelnost a

ergonomie aplikace. Kompatibilita. Výkonnost - počet požadavků za časovou jednotku,

maximální počet uživatelů. Dostupnost. Škálovatelnost - možnost zvyšovat výkon aplikace. Bezpečnost – ověřovací mechanizmy, ukládání

hesel, šifrováním přenosu, síla šifrování,…. Rozšiřitelnost.

TESTOVÁNÍ SPECIFIKACE

První zásadní testování

Testování (revize) specifikace15

Lze použít pouze metodu statického testování černé skříňky.

Proces specifikace je velmi nepřesnou disciplínou, proto je náchylný na chyby.

Důležité, ale obtížné. Reviduje se s podobnou již hotovou

aplikací a porovnává se specifikací. Je třeba porovnat se standardy a

zásadami.

Při testování (revize) specifikace testujeme

16

Úplnost. Správnost. Přesnost, jednoznačnost. Konzistentnost. Relevance. Proveditelnost. Testovatelnost.

FUNKČNÍ TESTOVÁNÍ - DYNAMICKÉ TESTOVÁNÍ ČERNÉ SKŘÍŇKY

Zavři oči, brouku…

Rozdělení do třídy ekvivalentních případů

18

Nelze otestovat vše, je třeba vytvořit efektivní testovací množiny.

Rizikové, cíleně rozhodujeme netestovat vše, nicméně často není vyhnutí.

Testování aplikace

Splněním stavy role logika řízení

hraniční podmínky

Selháním opakování zátěž stres

neplatné, nesprávné a nesmyslné údaje

19

Testování dat splněním – hraniční podmínky

Textové délka pozice počet …

Znakové …

Číselné maximum/minimum mocniny dvou typy …

Binární …

20

FUNKČNÍ TESTOVÁNÍ - STATICKÉ TESTOVÁNÍ BÍLÉ SKŘÍŇKY

Co se dá najít v kódu…

Formální revize – základní prvky

22

1. Stanovení a dodržování pravidel.2. Identifikace problémů.3. Zápis.

Přínosy formální revize23

Komunikace. Kvalita. Tým. Řešení.

Typy revize24

1. Revize partnerem.2. Průchody.3. Inspekce.

Možné body pro revizi25

Chyby v odkazech na data. Chyba v deklaracích dat. Chyby ve výpočtech. Chyby v porovnáních. Chyby toku řízení. Chyby ve funkcích a procedurách. Vstupně-výstupní chyby. a mnoho dalšího…

FUNKČNÍ TESTOVÁNÍ - DYNAMICKÉ TESTOVÁNÍ BÍLÉ SKŘÍŇKY

Začíná přituhovat…

Způsoby dynamického testování bílé skříňky

27

Přímé testování objektů, funkcí, podprogramů, skriptů a jiných částí kódu.

Testování na nejvyšší úrovni. Testové případy upravíme dle znalosti kódu.

Sledování proměnných a stavových informací.

Sledování využívaného kódu a stanovení testových případů.

Dynamické testování bílé skříňky versus ladění

28

Zdánlivě tyto pojmy mohou splývat. Skutečně řeší stejné problémy. Přesto mají různý význam: dynamické testování bílé skříňky – cílem je

hledání chyb, ladění – cílem je opravení chyb.

FUNKČNÍ TESTOVÁNÍ - KOMPATIBILITA

Velká výzva.

Zásadní otázka30

Lze zajistit funkčnost webové aplikace pro všechny tenké klienty?

Odpověď31

Nelze. Tencí klienti jsou nejen všechny

prohlížeče používané v PC, ale samozřejmě i různé alternativní čtečky, prohlížeče v mobilních zařízeních apod.

Velké množství standardů, žádný klient nedodržuje 100%.

Jak tedy testovat kompatibilitu?

32

Nejčastěji se určuje skupina tenkých klientů, kde aplikace musí fungovat.

Na těchto klientech se pak testuje v rámci funkčnosti.

CO ŘÍCI ZÁVĚREM?Testujte vždy, všude a všechno. Děkuji za pozornost.