Testování SW

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

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í • Statické • 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.

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ů. ? Přínosy pro firmu Nasazení webové aplikace

11. Proč testovat? • 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.

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 • 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. Co říci závěrem? Testujte vždy, všude a všechno. Děkuji za pozornost.