Testování aplikací I a II

I a II Miroslav Bureš Tvorba webových aplikací II Adaptivní webové systémy 1

Osnova Úvod do testování Ruční testování Pokud existuje specifikace Pokud neexistuje specifikace Automatické testování Speciální testy Nástroje, plánování Ladění výkonu 2

Úvod Triviální test dělá rovnou vývojář Role tester je obecně oddělená Vykonáme činnost v aplikaci podle předpisu/plánu Zaznamenáme výsledek (ok/chyba) Předáme vývojářům k opravě, pak retestujeme 3

Proč testovat? 80 70 Relativní náklady k opravě chyb 60 50 40 30 20 10 0 Požadavky Design Kód Vývojové testování Akceptační testování Provoz Fáze vývoje 4

Psychologie testování Pokud není definovaný výsledek, máme tendenci považovat výsledek za správný vidíme co chceme vidět Vážně chcete najít chyby ve své vlastní práci? Střet programátor vs. tester Omyly v pochopení specifikace programátor a tester pochopí jinak Můžeme ukázat objevené chyby, na 100% ale nezaručíme, že je program bez chyb (převzato ze školení Cleverlance Software testing ) 5

Testing na současném IT trhu Quality Assurance (QA) Samostatná disciplína IT Větší IT firmy mají často QA oddělení Týmové role pro testy (větší projekty): Tester Test analytik Test architekt Test manager Počet testerů:počet vývojářů průměr 4 velkých firem (MS, Borland, WordPerfect, Novell) byl v roce 1992 1:2 6

Typy testů Podle automatizace Ruční Automatické Podle zaměření (nejednotná terminologie) Unit testy aplikace Unit testy kódu Systémové testy Integrační testy Zátěžové testy Penetrační testy Tetsty provozuschpnosti na platformě Zátěžové testy Regresní testy Testy instalace E2E (end-to-end testy) Crash testy a testy zotavení systému 7

Typy testů 2 Podle fáze projektu Alfa testy Beta testy První testy v rámci vývoje - vývojáři Samostatné testy v rámci vývoje - testeři UAT (User Acceptance Testing) - uživatelé Pilotní provoz uživatelé Akceptační testy 8

V-model testování 9

Chyby software Interpretace a vnímání chyb "Toto není chyba ale vlastnost aplikace" :) "Toto je zásadní chyba, v tiskové sestavě je 15 Kč místo 15 CZK " "To je sice pravda, že to ve specifikaci není popsané, ale to se snad rozumí samo sebou, jak to má být správně" Úrovně chyby Bug S aplikací není možné správně pracovat Ztrácí / poškozuje data Klasifickace závažnosti Nesoulad aplikace se specifikací Špatné pochopení procesu / aplikace uživatelem 10

Cyklus chyby 11

Ruční testování pokud existuje specifikace Tester vykonává v aplikaci manuálně kroky, které jsou popsané v testovacím skriptu a sleduje výsledek V případě nesouladu zapíše chybu Filtrace duplicitně nahlášených chyb např. test analytik Efektivita testů klesá nepřesností scénářů nebo odchylkami aplikace Někdy scénáře pokrývají jen klíčovou část aplikace, nebo jsou psány z high-level pohledu Iniciativa testera při podrobnosti testu 13

Testovací skript Připravuje se před samotným testováním na základě specifikace Obecný, pro ruční testování Název, kategorie Popis činnosti testu - jednotlivé kroky Očekávaný výsledek - správné chování Priorita Evidence spuštění Priorita Přiřazený tester Datum, čas Výsledek jednotlivých kroků, pokud je členěný Výsledek - no run, incomplete, passed, failed, N/A Navázané chyby nahlášené v důsledku testu 14

Testovací data Důležitá součást přípravy testování Souvisí s testovacími skripty Příprava testovacích dat Příprava test.dat je součástí test.skriptů Příprava test.dat dopředu, test.skripty se na ně odkazují Ručně SQL skripty Kopie produkčních dat + jejich depersonifikace (pokud obsahují citlivé osobní nebo obchodní informace) 15

Test analýza příprava testovacích skriptů Co potřebujeme k přípravě skriptů? Specifikace - funkční požadavky Specifikace - nefunkční požadavky Akceptovaný prototyp (GUI) Částěčně funkční aplikace (?) Součinnost objednavatele software budoucího uživatele Důležité: Porozumění zadání Úplnost požadavků Řízení změn aktuálnost test. skriptů 16

Funkční a nefunkční požadavky Funkční požadavky konkrétní funkcionalita aplikace (aplikace umí vygenerovat report v PDF) Nefunkční požadavky technické podmínky konkrétní funkcionality, jsou na ni vázány (generování reportu nesmí trvat déle než 5 vteřin a musí fungovat i na platformě Linux) Nefunkční požadavky často souvisí s SLA SLA service level agreement Dostupnost 7x24 Pro 10 000 účastníků současně Produkt musí fungovat v případě výpadku proudu v nouzovém režimu po dobu 10 minut 17

Příprava sktiptů podle specifikace Příležitost jak zároveň zkvalitnit specifikaci Zrádná slova ve specifikaci může měl by adekvátní parametrický atd. podobně zejména nebo Přejato z materiálů ke školení Test analýza společnosti Cleverlance 18

Příklady základních chyb ve specifikaci Extrakt obsahuje Voice CDR, dále SMS, služby třetích stran atd. Služba videovolání by měla být dostupná obdobně jako hlasové volání Aplikace může mít v některých případech nižší výkonnost Ergonomie ovládání na každé obrazovce bude snaha mít maximální množství informací a maximální jednoduchost a uživatelskou rychlost vyplňování Uživatel bude mile překvapen příjemnou organizací polí na obrazovce. Orientace na stránce bude jednoduchá jak toto otestovat? Neměřitelné 19

Na co se zaměřit při přípravě test. skriptů Prioritu má základní funkce aplikace To ale neznamená jen očekávaný průchod (!) Testy pro neočekávané zacházení s aplikací V neočekávaných a nevalidních podmínkách bývá mnoho chyb 20

Vstupy Validní vstupy: Mezní hodnoty M=mez M-5, M-1, M, M+1, M+5 Přesnost desetinných čísel Dlouhé řetězce Prázdné řetězce Řídící znaky \n </br> atd. Nevalidní vstupy: Jiný datový typ Čísle větší nebo menší, než dovoluje datový typ Speciální znaky (mimo kódovou sadu) 21

Test target Funkce aplikace co je potřeba otestovat pohled zezhora Nadstavba nad test skripty Test target obsahuje sadu test skriptů Test target Otestuj tisk smlouvy Test skripty pro Otestuj tisk smlouvy Založ typ smlouvy víceletá pro klienta podnik a zkus tisk Zadej do smlouvy výši půjčky -22.4453 a zkus tisk Vypni tiskárnu a zkus tisk... 22

Ruční testování pokud neexistuje specifikace Pokud není specifikace k aplikaci, spoléháme se na iniciativu testera Zapisujeme prošlou cestu Můžeme regresně vytvářet specifikaci Zapojení osob, které znají proces, který aplikace modeluje/podporuje (zadavatel, budoucí uživatel) Stanovení priorit Metodiky: Free testing Exploratory testing Risk-based testing 24

Pokud neexistuje specifikace Stanovení priorit (příklady): Všechny primární funkce, které lze rozumně v dostupném čase otestovat Vybrané vedlejší funkce (objevené v souvislosti s testováním primárních funkcí) Vybrané oblasti potencionální nestability (5 10 oblastí produktu) 25

Automatizované testy Obecně testy prováděny počítačem Mýtus: automatizace již připravených nebo provedených manuálních testů Příklady typy testů: Příprava testovacích dat Zátěžové testy Regresní testy Smoke testy (rychlý test, zda vše funguje) Příklady techniky: JUnit Automatické testování GUI 27

Automatizované testy náklady Automatizace má smysl, pokud se test opakuje 28

Kdy automatizovat? Existuje více HW nebo SW konfigurací Bude více jak 5 kol testů Více jak 5 uživatelů pracujících s aplikací v jeden okamžik Existují opakující se úkoly, potřebné k zavedení aplikace (nahrání dat, konfigurace...) Jedná se o kritickou část aplikace (např. práce s penězi) Potřeba otestovat všechny varianty Při manuálním provádění testů by šlo o příliš složité nebo nákladné činnosti Nelze testovat ručně 29

JUnit JUnit testy na úrovni kódu V kódu aplikace jsou přímo naprogramovány testy Příklad - volání metody se vstupy, definovaný výstup, který má vrátit Tyto testy se spouští v sekvenci, každý vrátí výsledek Pokud se změní kód aplikace, spustí se definované testy, zda se nezavlekla chyba v jiném místě aplikace Účinná metoda testování zavlečených chyb Regresní test 30

GUI Automatické testování GUI Nasnímání aktivity v uživatelském rozhraní - sekvence testu Definice výsledku testu - grafická, textová Obecně nákladnější a náročnější na udžování aktuálnosti skriptů než ruční testování (stroj na rozdíl od testera nemůže provést sám korekci) Snímání GUI se používá spíše pro zátěžové testy Příklad nástrojů: Mercury QuickTest, WinRunner Rational Robot 31

Zátěžové testování 1 Simluace paralelního přístupu uživatelů Nasnímání aktivity v uživatelském rozhraní - sekvence testu Spouštění ve velké frekvenci paralelně Sledování odezev aplikace Odhalení možných pádů aplikace z přetížení přístupy Alternativa - nástroje vytáčející URL v definované sekvenci 33

Zátěžové testování 2 Kapacitní testy Odezvy aplikace v případě zpracování velkého množství dat Naplnění databáze velkým množstvím umělých dat Sledování reakcí Následná optimalizace výkonu 34

Crash testy Nasimulování pádu aplikace nebo její komponenty Odpojení databáze / filesystému / aplikačního serveru Simulovaný výpadek sítě Simulované přeplnění databáze / filesystému Cíl: aplikace má korektně odpojit uživatele a zachovat konzistenci dat. Po opětovném spuštění má fungovat korektně Problém transakcí (např. platby, objednávky atd.) 35

Penetrační testy Pokus o nabourání aplikace klasickými metodami Pokus o odchycení hesel Vytočení stránky aplikace mimo klasickou navigaci SQL inject, JavaScript inject Black-box metoda Testeři nemají žádné informace o testovaném systému White-box metoda Testeři mají podrobné informace o systému 36

Nástroje pro testy - příklady Testování & evidence chyb Test Director (Mercury) Evidence chyb JIRA (Atlassian) Bugzilla (OpenSource) Zátěžové testy WinRunner (Mercury) 38

Testovací prostředí U větších projektů se jedná o oddělené prostředí Oddělené prostředí = Samostatná aplikace Samostatná databáze (oddělená data) Typická prostředí u větších projektů: Vývoj Testy UAT Produkce (živý provoz) DR (záloha živého provozu) 39

Plánování testů příprava testů U větších aplikací jsou testy podprojekt v projektu Test analytici připravují testovací skripty nejčastěji v průběhu vývoje Velmi efektivní je zapojit test analytiky již ve fázi analýzy zdokonalují specifikaci, odhalují rizika Problém po změně zadání musí následovat aktualizace testovacích skriptů 40

Plánování testů samotné testování Zdržení vývoje znamená zdržení testů Při nestíhání deadline je často tlak zredukovat testy Změnové požadavky zasahují do testů Součinnost vývojářů na opravu chyb Pravidlo 80% - 20% Organizace práce, eliminace prostojů, pokud aplikace nefunguje 41

Code freeze Dokončení vývoje aplikace Zastavení implementace changerequestů Běží jen testy a opravy chyb Ideální případ, typický vývoj projektu code freeze porušuje Vhodné porušení Oddělené bloky funkcionalit, neovlivňující (moc) ostatní části aplikace (např. tisky) Nevhodné porušení Velké ovlivnění celé aplikace Jádro aplikace Aplikace typu engine / framework Základní business proces v aplikaci 42

Plánování testů úvahy o efektivitě 1 Testy jsou investice. Testy jsou na efektivitu ještě náchylnější než vývojové práce 10 testerů může testovat měsíc a výsledek může být pro uživatele nižší, než 14 dní práce dvou analytiků, dvou testerů a osoby od klienta, která zná dobře proces, který má aplikace podporovat V extrémním případě je udělat jen rychlý test základní funkcionality finančně výhodnější, než testovat neefektivně 43

Plánování testů úvahy o efektivitě 2 Počet nalezených chyb Náklady na testování Optimální hladina testů Množství Příliš málo testů Příliš mnoho testů Počet prove dených testů Přejato z materiálů ke školení Úvod do testování společnosti Cleverlance 44

Plánování testů úvahy o efektivitě 3 Nízká efektivita: Kdo neumí nic jiného, jde testovat X junior testerů nějak to otestujte, šéf vývojář vám řekne jak Testeři nastupují ke konci vývoje Zaměřujeme se na formální report z testů, ne na kvalitu samotnou Vyšší efektivita: Místo kvantity junior testerů několik profesionálních Místo kvantity testovacích skriptů dobré pokrytí kritických cest, must be, iniciativa testerů, motivace Úzká kooperace testera s vývojářem 45

Plánování testů úvahy o efektivitě 4 Tradiční přístup: Testování kopíruje vývoj Testeři technický přístup Nebezpečí testování okrajových, z hlediska chyb atraktivních oblastí Testy řízené business zadáním: Design testovacích případů podle rizika pro provoz Který obchodní proces se používá nejčastěji? Který obchodní proces představuje největší riziko (ztráty peněz, času, klientů...)? Frekvence využití procesů Není podstatné, jestli program funguje perfektně, ale jestli splňuje očekávání uživatele 46

Ladění výkonu webové aplikace Tři úrovně: Optimalizace procesu Optimalizace GUI aplikace Odezvy aplikace 48

Optimalizace procesu Týká se specifikace, co má aplikace dělat - zadání Cílem není vytvořit aplikaci jinak oproti zadání, ale přímo zjednodušit proces, který aplikace podporuje Technika, která se může použít, pokud se bíží deadline a aplikace není připravená Dokumentace procesu v UML - activity diagram Měření časů potřebných k jednotlivým úkonům Redukce zbytečných úkonů Spojování úkonů do kratší akce, automatizace 49

Optimalizace GUI aplikace Dokumentace toku obrazovek v UML - activity diagram. Nemusí být nutně shodný s dokumentací procesu Sběr zpětné vazby od uživatelů Redukce nadbytečných obrazovek Sdružování ovládacích prvků na jednu obrazovku Zlepšení navigace - zkratky, rozcestník, poziční informace Často navštěvované obrazovky lépe dosažitelné na kratší cestě v GUI 50

Odezvy aplikace 1 Jednoduché měření odezev - timestamps v kódu stránky, zapíše do logu Zkrácení reakcí aplikace: Interpretovaná aplikace (PHP, ASP) Nejčastěji trvají dlouho přístupy do databáze Kombinace kvadratické složitosti s SQL selecty Java aplikace (JSP, Servlet) Přístupy do DB Běh Java kódu Nevhodné použití EJB 51

Odezvy aplikace 2 Caching Načtení objektu z DB do paměti na serveru Není potřeba data načítat znova z DB, vezmou se z paměti Při nevhodném použití může zpomalit - načítáme všechna data do cahe a potřebujeme jen část Aktuálnost dat v paměti proti databázi 52

Dotazy, diskuze buresm3@fel.cvut.cz miroslav_bures@centrum.cz 53