PERFORMANCE TESTŮ SEZNÁMENÍ S PROBLEMATIKOU David Růžička
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
ž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 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 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
V rámci procesu testování 6
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
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 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ů
TESTOVAT NEBO NETESTOVAT Výkonnost aplikace před nasazením
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 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 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 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 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 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
PERFORMANCE TESTY V RÁMCI ŽIVOTNÍHO CYKLU IS PŘÍNOSY REALIZACE, RIZIKA
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 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 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 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 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 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 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 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
RIZIKA
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
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
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
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
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
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
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
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
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
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
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
VÝKONNOSTNÍ TESTY
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
ANALÝZA PRO ZT PROCESNÍ SCHÉMA 40
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 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
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
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
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
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
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
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 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.
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
LoadRunner Controller Běh ZT - Spuštení ZT Skupiny VU Stav scénáře Výběr monitorů Grafy monitorů
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 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 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 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 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ěží
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
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
Architektura CRM Siebel v ČS
Prostředí pro testy - začlenění zátěžových testů do životního cyklu CRM
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
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í
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
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
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
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
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
Kontakt David Růžička Email: david.ruzicka@testiana.cz Mobil: +420 723 583 727 http://www.testiana.cz