PERFORMANCE TESTŮ SEZNÁMENÍ S PROBLEMATIKOU. David Růžička

Transkript

1 PERFORMANCE TESTŮ SEZNÁMENÍ S PROBLEMATIKOU David Růžička

2 Performance testy snižují rizika a zvyšují kvalitu Snížení Rizika Předem určí výkonnost aplikace pod zátěží Optimalizace výkonnosti aplikace Kvantitativní určení kapacit aplikace Zvýšení kvality Nalezení výkonnostních problémů předem Otestování aplikace komplexně v krátkém časovém úseku Zdokumentování pokračujícího zvyšování výkonnosti testované aplikace

3 že splníte potřeby business ve fázi provozu aplikace? Jak jistí si jste? Ano Ne Jste schopni nalézt kritické chyby aplikace ještě před tím, než je pocítí koncový uživatel? Je váš systém dostatečně dimenzován pro běžnou denní práci, popř. špičkové vytížení? Jste schopni proaktivně odhalit blížící se problémy k minimalizaci dopadů na chod aplikace? Jste schopni rychle opravit a vyřešit výkonnostní problémy aplikace? Znáte náklady na výpadek?

4 4 Co jsou performance testy? Specifický druh testů, pro ověření nefunkčních požadavků Patří do skupiny nefunkčních testů Zaměřují se hlavně na: Výkon testovaného systému Stabilitu testovaného systému Ověření disaster recovery procedur Optimalizaci HW a SW

5 5 Co je performance test? Nahrazení reálných uživatelů velkým množstvím (i tisíce) virtuálních uživatelů pomocí podpůrného testovacího nástroje Generování konsistentní, měřitelné a opakovatelné zátěže řízené z jednoho místa Monitoring pro odhalení výkonnostních úzkých míst (tzv. bottle necks) napříč všemi vrstvami

6 V rámci procesu testování 6

7 7 Zátěžové testování Manuální Použitelnost na malé systémy do počtu 20 uživatelů Špatné sledování systému a sběr naměřených hodnot Vyšší chybovost z hlediska lidského faktoru Automatizovaný Řízení zátěže z jednoho místa Opakovatelnost testů Použitelnost i na velké systémy s tisíci uživateli bez velkého množství PC

8 Co je Automatizované zátěžové testování? Emulace produkční zátěže na IT systém Controller Simulovaní uživatelé Internet/ WAN Web Server Apl. Server Databáze Náhrada skutečnýchuživatelů tisíci virtual uživateli (VU) Generuje vyváženou, měřitelnou a opakovatelnou zátěž systému z jednoho řídícího místa Napomáhá určit možná kritická místa v systému

9 9 Průběh ZT Analýza pro zátěžový test Příprava testovacích skriptů Sestavení scénáře ZT Nastavení monitoringu Běh ZT Zpravidla provádíme 2 běhy korelace výsledků Analýza výsledků

10 TESTOVAT NEBO NETESTOVAT Výkonnost aplikace před nasazením

11 11 Příklad na začátek Jednoduchá aplikace v bance pro výplatu z fondu pojištění vkladů Jednorázová, ale poměrně kritická aplikace Situace bez perf. Testu Výkonnostní problémy už při přihlašování Nemožnost obsloužit klienty, kteří čekají několik měsíců na peníze... Situace s perf. Testem Problém odstraněn na poslední chvíli Výplata proběhla Bonus - banka získala 60% lidí jako nové zákazníky

12 12 Proč testovat výkonnost? Dostáváme odpovědi na důležité otázky: Jaký je maximální počet uživatelů? Jaký je maximální počet zpracovávaných transakcí? Jaký je čas odezvy? Jaký je kritický čas transakce nebo celého business procesu? Jaký je průměrný čas mezi výpadky systému? Kde v systému či infrastruktuře jsou uzká hrdla? Jaké jsou časové odezvy při maximální zátěži? Další otázky (jaká je reakce na změny zátěže, co dělat když systém zhavaruje z důvodu přetížení) A desítky dalších odpovědí

13 13 Komu by mohl test pomoci? Business zadavatel PM za business, analytik... Sponzor aplikace / projektu IT provoz Administrátoři oddělení nebo lidi, kteří budou aplikaci provozovat IT Vývoj PM za ICT Architekt Vývojové oddělení

14 14 Jak mohou výsledky pomoci? Business zadavatel informace o skutečné výkonnosti Omezení Stabilita IT provoz Stabilita Instalační postupy (včetně post instalačních postupů) Disaster recovery IT Vývoj Ověření platformy Ověření výkonnosti Ladění výkonnosti aplikace

15 15 Kdy ano a kdy ne? Návodný klíč pro rozhodnutí Je systém nebo aplikace kritická? Kolik usilí, financí i nefinančních postihů nás bude stát výpadek? Probíhá vývoj nad osvědčenou platformou nebo frameworkem? Budeme mít čas na realizaci? Jsme schopni získat prostor a součinnost? Bude prostor na opravu nebo nápravu? Chce po nás někdo performance testy? Bude se výsledky někdo zabývat?

16 16 Závěr Plusy Ověření použité platformy, technologie a infrastruktury systému Ověření chování celého systému při předpokládané zátěži a při měsíčních či ročních špičkách Ověření chování systému při výpadku jednotlivých komponent systému Zjištění výkonnostních limitů systému Vyladění systému a jeho jednotlivých komponent před reálným provozem Provedení výkonnostní akceptace dodaného systému Mínusy Poměrně složitá oblast z pohledu integrace na okolní systémy Nutnost použití specializovaného nástroje Pracnost Časová náročnost Přípravy testovacích skriptů Přípravy testovacích dat a prostředí Nutnost zapojení poměrně velkého týmu

17 PERFORMANCE TESTY V RÁMCI ŽIVOTNÍHO CYKLU IS PŘÍNOSY REALIZACE, RIZIKA

18 18 PŘÍNOSY REALIZACE ZÁTĚŽOVÝCH TESTŮ Výkonnostní akceptace systému Odladění systému a jeho komponent Ověření použité platformy, technologie a infrastruktury systému před zahájením vývoje aplikace Zjištění výkonnostních limitů systému Zjištění výkonnostních charakteristik systému při různých typech zátěže (denní a měsíční špičky, dávková zpracování, počty VU, omezená konfigurace, atd.) před jeho nasazením Ověření chování systému při náhlém výpadku komponenty systému před jeho nasazením

19 19 Ověření platformy Ověření kombinace zvoleného OS a aplikační platformy Ověření zvolené technologie nebo frameworku aplikace Ověření architektury nového systému Ověření infrastruktury Topologie aplikace Síťové připojení Geografické rozmístění Ověření možností škálovatelnosti

20 20 Ověření běžného provozu Ověření chování aplikace při běžném denním provozu Dle předpokládaného využití Výpočtem ze statistik provozu Ověření chování aplikace ve špičkovém zatížení Roční, čtvrtletní, měsíční uzávěrky Zpracování kampaní Ověření chování do budoucna Volume testy (zvyšování obsahu systému)

21 21 Ověření při výpadku Ověření chování aplikace při výpadku serverů Práce clusteru Práce replikace databáze Ověření chování aplikace při výpadku síťových komponent Přesměrování síťové komunikace Ověření chování aplikace při zpětném obnovení provozu na plný výkon Ověření závislosti propojených systémů Ověření dopadu výpadku backendu

22 22 Zjištění výkonnostních limitů Ověření počtu uživatelů Navyšujeme počet uživatelů dokud aplikace přihlašuje nové Ověření objemu provedených transakcí Navyšujeme prováděné transakce Stress test Navyšování zátěže až do úrovně pádu aplikace Zjištění úzkých míst Odladění nebo zvýšený monitoring

23 23 Ladění aplikace Časově náročná aktivita Vysoká četnost spouštění běhů Změny v nastavení OS Změny v nastavení aplikace/db Ověření přínosu provedených změn

24 24 Akceptace systému Ověření chování aplikace při denní/špičkové zátěži Podklady pro porovnání s akceptačními kritérii Rozhodnutí Go/NoGo

25 25 Shrnutí } Snížení rizika } Předem určí výkonnost aplikace pod zátěží } Optimalizace výkonnosti aplikace } Kvantitativní určení kapacit aplikace } Zvýšení kvality } Nalezení výkonnostních problémů předem } Otestování aplikace komplexně v krátkém časovém úseku } Zdokumentování pokračujícího zvyšování výkonnosti testované aplikace

26 RIZIKA

27 Rozdělení rizik ZT Rizika ovlivňující realizaci testu Nevhodný nástroj Nedostatečné informace, analýza atd. Rizika ovlivňující objektivitu testu Testovací prostředí a data součinnost Rizika pro provoz Ovlivnění provozu (aplikace, infrastruktura atd. Zneužití dat Zásah do produkčních systémů 27

28 Nevhodný výběr nástroje pro ZT Na základě platformy aplikace Umí nástroj daný protokol? Umí měřit infrastrukturu? Na základě referencí Byl již někde použit? Na základě rozsahu testu Je dostatečně stabilní? Je škálovatelný? Na základě ceny nástroje Cena vs. Rozpočet projektu 28

29 Analýza Podklad pro práci testera / skriptera Nedokončená aplikace = není detailní popis Podklad pro parametrizaci Podklad pro nastavení scénáře Detailní popis měřených parametrů Jasně definované scénáře čas, četnost, Komunikace Definice komunikační matice 29

30 Testovací data Naplněnost databází Tvorba nových testovacích dat Počet testovacích dat Kvalita testovacích dat Výběr z existujích dat Výběr z produkce Anonymizace dat Úprava existujících dat Časové platnosti dat 30

31 Funkčnost aplikace Funkčně odladěný business proces Lze manuálně projít vybrané testovací scénáře Je plně funkční pro práce s testovacími daty Funkční integrace s okolními systémy Minimum simulovaných interface Opravy chyb v testovacím prostředí Zamražená aplikace Workaround na dokončení procesu 31

32 Testovatelnost aplikace Použitá technologie/komunikační protokol Různé protokoly v rámci jedné aplikace Proprietální protokoly Client-side skripty Session handling Autentifikace uživatele Ověřovací kódy Captcha apod. 32

33 Monitoring Uživatelské účty Operační systémy Databáze Aplikační servery Podpora monitorovacích nástrojů Proprietární monitory Síťové prostupy k monitorovaným serverům Agentové/bezagentové monitory 33

34 Sizing prostředí Konfigurace testovacího prostředí vs. Produkce Neexistuje přepočet výkonnosti Sdílení zdrojů Mezi testovacími prostředí S vývojovým prostředí Vliv na další prostředí Síťový segment Jiné testovací projekty 34

35 Součinnost Test Manager řízení projektu testování Administratoři OS, DB,.. Logy aplikací Restarty aplikací Analýza výsledků Přístupy na servery Business Konzultace na testovacími scénáři Analýza výsledků 35

36 Produkční prostředí Ovlivnění provozu (reálných business aplikací) Na úrovní společných serverů, ale jiných instancí Na úrovní síťové infrastruktury SMS gateway Zneužití dat Je potřeba mít velký vzorek dat a k nim musí mít přístup i externisti Pozor na legislativu (zákon č. 101/2000 Sb. Ochrana osobních údajů) 36

37 Součinnost Test Manager řízení projektu testování Administratoři OS, DB,.. Logy aplikací Restarty aplikací Analýza výsledků Přístupy na servery Business Konzultace na testovacími scénáři Analýza výsledků 37

38 VÝKONNOSTNÍ TESTY

39 39 FÁZE ZÁTĚŽOVÉHO TESTOVÁNÍ Příprava ZT Analýza a návrh ZT, příprava testovacích dat a prostředí, příprava zátěžových skriptů, zkušební běh ZT Realizace ZT Spouštění ZT, monitoring, ladění systému (v iteracích) Vyhodnocení ZT Vyhodnocení jednotlivých běhů ZT (v iteracích), závěrečná zpráva ZT

40 ANALÝZA PRO ZT PROCESNÍ SCHÉMA 40

41 41 PŘÍPRAVA ZT - ANALÝZA Definice cílů a rozsahu ZT Výběr transakčního mixu (četnosti, objem, popis průchodů, think time, ) Definice prostředí pro ZT Definice řešitelského týmu a komunikace s ním Specifikace testovacích dat Definice základních scénářů (cyklů) Definice organizačních opatření Harmonogram

42 42 PŘÍPRAVA ZT TEST DATA Příprava testovacích dat dle specifikace dat v analýze Objem a obsah DB Struktura a obsah datových souborů Množství dat (v DB, v souborech) Dostatečný počet loginů pro ZT Doména, jméno, heslo, role, certifikáty Rozložení rolí, grupování rolí (generátory uvnitř sítě, z DMZ) Při přípravě dat je důležité vědět, zda data bude možné používat opakovaně (destruktivní vs nedestruktivní) Velký důraz na dostatek a kvalitu testovacích dat

43 Příprava skriptů nahrání uživatelské činnosti zaznamenání do jazyka TSL korelace parametrizace vložení měřených transakcí doprogramování nastavení parametrů pro běh VU začlenění skriptu do scénáře ZT

44 Příklad LoadRunner Test script Language (TSL) podobný jazyku C (ANSI C) speciální funkce pro konkrétní protokol možnosti podmínek, větvení a cyklů možnost použití funkcí z externích DLL knihoven možnost výpisu do logů tvorba rendezvous ošetření běhových chyb (Error Handling) Spouštění speciálních funkcí při výskytu chyby Možnosti vlastního programového kódu

45 Struktura skriptu Virtual user init Provede se pouze jednou při spuštění VU Virtual user action(s) Vlastní práce VU Základní tělo skriptu pro ZT Opakuje se dle počtu iterací, Skript může obsahovat více než jednu akci Virtual user end Provede se pouze jednou při ukončení práce VU

46 skriptování Defininování měřitelných transakcí Měření odezvy aplikace Lze vkládat při nahrávání i dodatečně dopisovat do skriptu Start transakce Konec transakce

47 Skriptování - Thinktime čekací doba v běhu skriptu VU simulování přemýšlení reálné uživatele lr_thinktime(10); definici způsobu provádění při běhu ZT ignorovat dobu zaznamenanou ve skriptu násobit dobu ve skriptu náhodné % z doby ve skriptu v určité rozsahu

48 Skriptování - Pacingtime doba mezi opakováními činnosti VU způsob provádění při běhu ZT když předchozí opakování skončí od konce předchozího opakování pevná doba (x sekund) náhodně v určitém rozmezí (např. od 60 do 90 s) od začátku předchozí iterace pevná doba (x sekund) náhodně v určitém rozmezí (např. od 60 do 90 s)

49 49 PŘÍPRAVA ZT SCÉNÁŘE, ZKUŠEBNÍ BĚH Konfigurace základních scénářů z analýzy včetně měřených parametrů (think time, pacing time, měření využití CPU a pamětí jednotlivých serverů) Realizace zkušebního běhu ověření připravených dat, ověření správné funkcionality zátěžových skriptů, ověření připojitelnosti a vlastní funkčnosti systému a vzájemné kompatibility generátorů zátěže.

50 Manuálně tvořený scénář procentuální rozdělení VU pro skripty manuální rozdělení VU pro skripty Cílově orientovaný scénář Scénář zaměřený na dosažení určité zátěže LoadRunner Controller Tvorba scénáře ZT vzrůstaní počtu uživatelů až do splnění výkonnostních parametrů počet transakcí/s počet hitů/s odezvy transakcí < 10s

51 LoadRunner Controller Běh ZT - Spuštení ZT Skupiny VU Stav scénáře Výběr monitorů Grafy monitorů

52 52 REALIZACE ZT (v iteracích) Nastavení výchozích podmínek pro běh ZT Kontrolní spuštění (krátké ověření nastavení, připravenosti k běhu ZT) Spuštění připraveného scénáře ZT Stanovení dalšího postupu (na prezentaci s vyhodnocením) doladění systému, parametry nového měření Příprava pro další běh ZT x Ukončení ZT

53 53 VYHODNOCENÍ ZT (v iteracích) I Prvotní analýza výsledků daného běhu ZT Příprava souboru dat a grafů (výběr problémů) sumarizace grafů, tvorba grafů závislostí, prezentace Návrh dalšího postupu (dalšího běhu) jaký cyklus s jakým vzorkem dat, jaké měřit parametry rozhodnutí o ukončení ZT Návrh nastavení testované aplikace (doladění) změna parametrů HW a SW konfigurace Závěrečná zpráva shrnutí důležitých běhů ZT

54 54 VYHODNOCENÍ ZT (v iteracích) II Hledání závislostí (odezvy x CPU, odezvy x paměť, počet VU x CPU, počet VU x odezvy) Práce s absolutními hodnotami (max., min.), práce s 90% kvantilem Důraz na měřítko naměřených hodnot Možnost slučovat grafy dvou měření ZT Možnost importovat ruční měření do LR Analyzeru (nutné u serverů s OS nepodporovaným nástrojem, pozor na časové nafázování importu, časové posuny) Před vyhodnocovací schůzkou je vhodné si ověřit své závěry o příčinách úzkého místa

55 55 Bez GUI rozhraní Backend systémy Systémy se speciální HW rozhraním např. Bankomaty, dotykové panely atd. Jak řešit Doprogramovat skripty WS na základě WSDL Vytvořit testovací rozhraní Simulovat přes Frontend

56 56 Bez GUI rozhraní - rizika Podpora testovacích nástrojů Proprietární komunikační protokoly Frontend dostatečný výkon Definice zátěže velikost zátěže Kontrola správnosti odpovědi Monitorování odezev Monitorování systému pod zátěží

57 PERFORMANCE TESTY PŘI ROZVOJI SYSTÉMU - DLOUHODOBE ZKUŠENOSTI CRM SIEBEL V ČESKÉ SPOŘITELNĚ Česká spořitelna a.s., 23. května, 2007 Version 1.0

58 Představení systému CRM v ČS - způsob použití a jeho důležitost ČS provozuje systém Siebel jako celobankovní CRM systém Systém slouží pro správu klientských dat a řízení kampaní CRM Siebel je provozován v režimu 24 x 7 Systém je provozován pod SLA Počet aktivních uživatelů 7500, z toho současně pracujících (concurrent users) 3500 CRM obsahuje následující data: - Profil klienta, Informace o produktech, Příležitosti, Aktivity, Upozornění a Varování, vstupní bod pro aplikační scoring klienta

59 Architektura CRM Siebel v ČS

60 Prostředí pro testy - začlenění zátěžových testů do životního cyklu CRM

61 Proces testu výběr zátěžového testu 4 x ročně při migraci nové vlny CRM Při změně datové základny Pří změně na úrovni SW Pří změně na úrovni HW Při změně integrace

62 Proces testu - přístup k zátěžovému testování Využití interních i externích personálních zdrojů Globální využití SW LoadRunner Využití poznatků z již realizovaných zátěžových testů Plánování testů a způsob monitoringu testu Průběžné budování metodických pokynů a doporučení

63 Proces testu - rozsah prováděných zátěžových testů Stanovit cíl testu a počet testovacích kol Výběr testu v závislosti na konkrétní událost změny Definice a příprava testovacích dat Definice testovacího HW Stanovit kritéria pro vyhodnocení testu Příprava speciálních skriptů, které reprezentují běžnou nebo předpokládanou činnost uživatelů Způsob integrace na externí systémy Externí testovací prostředí x simulace

64 Proces testu - realizace testu Sběr statistik za jednotlivé zátěžové iterace (běhy) Průběžné vyhodnocení událostí při testech Změna nastavení prostředí dle výsledků jednotlivých kol Průběžná optimalizace aplikace Obecně se některé testy se realizují mimopracovní dobu (So, Ne, noc) Ale tady není potřeba díky organizaci práce

65 Proces testu - vyhodnocení testu Sběr a vyhodnocení naměřených hodnot za všechny zátěžové iterace Vytvoření závěrečné zprávy Obsah závěrečné zprávy: 1. Cíl testu 2. Rozsah testu 3. Popis realizace testu 4. Analýza naměřených hodnot 5. Definice dopadů 6. Další doporučený postup

66 Přínosy zátěžových testů Ověření výkonnostních dopadů SW změn před nasazením do produkce Predikace potenciálních výkonnostních problémů Ověření funkčnosti aplikace pod zátěží Odladění nejlepších parametrů komponent Zjištění charakteristik chování systému při různých typech zátěže Zajištění provozu CRM v režimu 24 x 7

67 Náročnost a pracnost testů První testy při implementaci Analýza ZT (z funkční a nefunkční specifikace) - 15MD Příprava skriptů 20MD Příprava testovacích dat 5 MD Realizace ZT hlavní testy 15 MD Realizace dodatečných ZT (ladění) 40MD Závěrečná zpráva 5MD Celkem 50 MD + 40MD ladění Pravidelné testování release Revize analýzy pro zátěžový test 1MD Úprava skriptů / přidání nových skriptů 3-5MD Příprava testovacích dat 1MD Realizace několika kol ZT 2MD Závěrečná zpráva 1MD Celkem 8-10 MD

68 Kontakt David Růžička Mobil: