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

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

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

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

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.

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.

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.

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í

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

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

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.

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

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.

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

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.

Při testování (revize) specifikace testujeme Ú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ů 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 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

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í

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 Stanovení a dodržování pravidel. Identifikace problémů. Zápis.

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

Typy revize Revize partnerem. Průchody. Inspekce.

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…

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 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í 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ázka Lze zajistit funkčnost webové aplikace pro všechny tenké klienty?

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

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.

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.