Testování SW Filip Rubáček, 2013

Prezentace na téma: "Testování SW Filip Rubáček, 2013"— Transkript prezentace:

1 Testování SW Filip Rubáček, 2013
2007, Filip Rubáček, Optimalizace webových aplikací

2 Obsah prezentace Axiomy a základní pojmy testování.
Testování webových prezentací a aplikací. Testování specifikace. Funkční testování.

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

4 Axiomy testování Žádná aplikace nejde otestovat kompletně.
Testování je postavené na riziku. Testování nemůže dokázat, že chyby neexistují. Čím víc chyb je nalezeno, tím více chyb v aplikaci je. Paradox pesticidů (čím více testujeme, tím je aplikace více imunní). Ne všechny nalezené chyby se opraví. Specifikace aplikace není nikdy konečná.

5 Pojmy testování a jejich definice
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.

6 Testování černé a bílé skříňky
Č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.

7 Statické a dynamické testování
testujeme co neběží. Pouze prohlížíme a revidujeme (např. specifikace, zdrojový kód). Dynamické software pustíme a zkoumáme.

8 Postupy při testování černé skříňky
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. Testy na selhání a testy na přežití 2007, Filip Rubáček, Optimalizace webových aplikací

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

10 Klíčová rizika nasazení aplikace
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

11 Proč testovat? Snížení nákladů na údržbu Udržení kredibility
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.

12 Existují důvody proč netestovat?
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. Výmluvy

13 Co musíme testovat? 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.

14 Testování specifikace
První zásadní testování

15 Testování (revize) specifikace
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.

16 Při testování (revize) specifikace testujeme
Úplnost. Správnost. Přesnost, jednoznačnost. Konzistentnost. Relevance. Proveditelnost. Testovatelnost.

17 Funkční testování - dynamické testování černé skříňky
Zavři oči, brouku…

18 Rozdělení do třídy ekvivalentních případů
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í.

19 Testování aplikace Splněním hraniční podmínky Selháním
stavy role logika řízení hraniční podmínky Selháním opakování zátěž stres neplatné, nesprávné a nesmyslné údaje

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

21 Funkční testování - statické testování bílé skříňky
Co se dá najít v kódu…

22 Formální revize – základní prvky
Stanovení a dodržování pravidel. Identifikace problémů. Zápis.

23 Přínosy formální revize
Komunikace. Kvalita. Tým. Řešení.

24 Typy revize Revize partnerem. Průchody. Inspekce.

25 Možné body pro revizi 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…

26 Funkční testování - dynamické testování bílé skříňky
Začíná přituhovat…

27 Způsoby dynamického testování bílé skříňky
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ů.

28 Dynamické testování bílé skříňky versus ladění
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.

29 Funkční testování - kompatibilita
Velká výzva.

30 Zásadní otázka Lze zajistit funkčnost webové aplikace pro všechny tenké klienty?

31 Odpověď 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%.

32 Jak tedy testovat kompatibilitu?
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.

33 Testujte vždy, všude a všechno. Děkuji za pozornost.
Co říci závěrem? Testujte vždy, všude a všechno. Děkuji za pozornost.