Testování aplikací I a II

Testování aplikací 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

Testování aplikací

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

Relativní náklady k opravě chyb

70 60 50 40 30 20 10 0 Požadavky

Design

Kód

Vývojové testování

Fáze vývoje


4

Akceptační testování

Provoz

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“) Testování aplikací

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

Osnova  

Úvod do testování Ruční testování  Pokud existuje specifikace 

Pokud neexistuje specifikace

  




Ladění výkonu


12

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 Testování aplikací

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 Testování aplikací

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é Testování aplikací

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
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  ... Testování aplikací

22

Osnova  

Úvod do testování Ruční testování  Pokud existuje specifikace 

Pokud neexistuje specifikace

  




Ladění výkonu


23

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 Testování aplikací

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


   


  




Ladění výkonu


26

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 Testování aplikací

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


   


  




Ladění výkonu


32

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


   


  




Ladění výkonu


37

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) Testování aplikací

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 Testování aplikací

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 Náklady na testování

Počet nalezených chyb

M n o ž s tv í

Optimální hladina testů

Příliš mnoho testů

Příliš málo testů

Počet prove dených testů

Přejato z materiálů ke školení „Úvod do testování“ společnosti Cleverlance Testování aplikací

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 Testování aplikací

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


47

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

[email protected] [email protected]


53

Testování aplikací I a II

Recommend Documents