testování sw
Post on 02-Jan-2016
49 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.
top related