Co je LoadRunner?
LoadRunner je nástroj pro testování výkonu, který byl průkopníkem Mercury v roce 1999. LoadRunner byl později získán společností HPE v roce 2006. V roce 2016 byl LoadRunner získán společností MicroFocus.
LoadRunner podporuje různé vývojové nástroje, technologie a komunikační protokoly. Ve skutečnosti je to jediný nástroj na trhu, který podporuje tak velké množství protokolů k provádění testování výkonu. Výsledky testu výkonu vytvořené softwarem LoadRunner se používají jako měřítko pro jiné nástroje
V tomto výukovém programu se naučíte
- Proč LoadRunner?
- Proč potřebujete testování výkonu?
- Co je architektura LoadRunner?
- Plán testování výkonu: Podrobné kroky
- FAQ
Proč LoadRunner?
LoadRunner je nejen průkopnický nástroj v testování výkonu, ale je stále lídrem na trhu v paradigmatu testování výkonu. V nedávném hodnocení má LoadRunner asi 85% podíl na trhu v odvětví testování výkonu.
Nástroj LoadRunner obecně podporuje RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex a Silverlight atd.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail a především Windows Socket. Na trhu neexistuje žádný konkurenční nástroj, který by mohl nabídnout tak širokou škálu protokolů vložených do jediného nástroje.
Co je přesvědčivější pro výběr LoadRunneru v testování softwaru, je důvěryhodnost tohoto nástroje. Nástroj LoadRunner si již dlouho vybudoval reputaci, protože často najdete klienty, kteří ověřují vaše výkonnostní měřítka pomocí nástroje LoadRunner. Úlevu najdete, pokud již používáte LoadRunner pro potřeby testování výkonu.
Software LoadRunner je úzce integrován s dalšími nástroji HP, jako je Unified Functional Test (QTP) & ALM (Application Lifecycle Management), díky nimž můžete provádět komplexní testovací procesy.
LoadRunner pracuje na principu simulace virtuálních uživatelů v předmětné aplikaci. Tito virtuální uživatelé také označovaní jako VUsers, replikují požadavky klientů a očekávají odpovídající odpověď na předání transakce.
Proč potřebujete testování výkonu?
Odhaduje se roční ztráta 4,4 miliardy z důvodu špatného výkonu webu.
V dnešní době Web 2.0 uživatelé kliknou pryč, pokud web neodpoví do 8 sekund. Představte si, že byste čekali 5 sekund při hledání Google nebo žádosti o přátelství na Facebooku. Dopady odstávky výkonu jsou často ničivější, než si kdy představovaly. Máme příklady, jako jsou ty, které nedávno zasáhly online bankovnictví Bank of America, webové služby Amazon, Intuit nebo Blackberry.
Podle Dunn & Bradstreet 59% společností z žebříčku Fortune 500 zažívá každý týden odhadem 1,6 hodiny odstávky. Vzhledem k tomu, že průměrná společnost z žebříčku Fortune 500 s minimem 10 000 zaměstnanců platí 56 USD za hodinu, náklady na pracovní dobu v případě výpadku by pro takovou organizaci činily 896 000 USD týdně, což by znamenalo více než 46 milionů USD ročně.
Odhaduje se, že pouze 5minutový výpadek webu Google.com (19. srpna - 13) stojí vyhledávacího giganta až 545 000 dolarů.
Odhaduje se, že společnosti ztratily tržby v hodnotě 1100 $ za sekundu kvůli nedávnému výpadku webové služby Amazon.
Když je softwarový systém nasazen organizací, může se setkat s mnoha scénáři, které mohou mít za následek latenci výkonu. Řada faktorů způsobuje zpomalení výkonu, může zahrnovat několik příkladů:
- Zvýšený počet záznamů v databázi
- Zvýšený počet současných požadavků odeslaných do systému
- větší počet uživatelů přistupujících k systému najednou ve srovnání s minulostí
Co je architektura LoadRunner?
Obecně řečeno, architektura HP LoadRunner je složitá, ale snadno srozumitelná.
Předpokládejme, že jste přiřazeni ke kontrole výkonu Amazon.com pro 5000 uživatelů
Ve skutečné situaci nebude všech těchto 5000 uživatelů na domovské stránce, ale v jiné části webových stránek. Jak můžeme simulovat jinak
VUGen:
VUGen nebo Virtual User Generator je IDE (Integrated Development Environment) nebo editor bohatého kódování. VUGen se používá k replikaci chování systému při zatížení (SUL). VUGen poskytuje funkci „nahrávání“, která zaznamenává komunikaci do az klienta a na server ve formě kódovaného skriptu - nazývaného také skript VUser.
Vzhledem k výše uvedenému příkladu může VUGen nahrávat a simulovat následující obchodní procesy:
- Procházení stránky produktů na Amazon.com
- Překontrolovat
- Platba se zpracovává
- Kontrola stránky Můj účet
Ovladač
Jakmile je skript VUser dokončen, je Controller jednou z hlavních komponent LoadRunner, která řídí simulaci zatížení pomocí správy, například:
- Kolik VUsers simulovat proti každému obchodnímu procesu nebo VUser Group
- Chování VUsers (rampa nahoru, rampa dolů, simultánní nebo souběžná povaha atd.)
- Scénář povahy zatížení, např. Real Life nebo Goal Oriented nebo ověření SLA
- Které injektory použít, kolik VUser proti každému injektoru
- Pravidelně porovnávejte výsledky
- IP spoofing
- Hlášení chyb
- Hlášení transakcí atd.
Vezmeme-li analogii z našeho příkladu řadiče, přidáme do skriptu VUGen následující parametr
1) 3500 uživatelů surfuje na stránce produktů na Amazon.com
2) 750 uživatelů je v pokladně
3) Zpracování plateb provádí 500 uživatelů
4) 250 uživatelů kontroluje stránku MyAccount POUZE poté, co 500 uživatelů provedlo zpracování plateb
Jsou možné i složitější scénáře
- Spouštějte 5 VUsers každé 2 sekundy, dokud nedosáhnete zatížení 3 500 VUsers (procházení stránky produktu Amazon).
- Iterujte 30 minut
- Pozastavte iteraci pro 25 uživatelů
- Restartujte 20 VUSerů
- Každou sekundu iniciujte 2 uživatele (v pokladně, zpracování plateb, na stránce Moje účty).
- Na stroji A bude vygenerováno 2 500 uživatelů
- Na stroji B bude vygenerováno 2 500 uživatelů
Agenti Stroj / Generátory zatížení / Vstřikovače
Řídicí jednotka HP LoadRunner je zodpovědná za simulaci tisíců VUsers - tito VUsers spotřebovávají hardwarové prostředky, například procesor a paměť - proto omezují stroj, který je simuluje. Kromě toho Controller simuluje tyto VUsery ze stejného stroje (kde se nachází Controller), a proto nemusí být výsledky přesné. Abychom tento problém vyřešili, jsou všechny jednotky VUs rozloženy do různých strojů, které se nazývají generátory zátěže nebo injektory zátěže.
Obecně platí, že ovladač je umístěn na jiném počítači a zatížení je simulováno z jiných strojů. V závislosti na protokolu skriptů VUser a specifikacích stroje může být pro úplnou simulaci vyžadována řada injektorů zátěže. Například VUsers pro skript HTTP bude pro simulaci vyžadovat 2 až 4 MB na VUsera, proto budou k simulaci zátěže 10 000 VUsers vyžadovány 4 stroje se 4 GB RAM.
Analogicky z našeho Amazonského příkladu bude výstup této komponenty
Analýza:
Po provedení scénářů načítání přichází role komponent „ Analýza “ nástroje LoadRunner.
Během provádění Controller vytvoří výpis výsledků v surové podobě a obsahuje informace jako, která verze LoadRunneru vytvořila tento výpis výsledků a jaké byly konfigurace.
Všechny chyby a výjimky se zaznamenávají do databáze Microsoft Access s názvem output.mdb. Komponenta „Analýza“ čte tento databázový soubor, aby provedla různé typy analýz, a generuje grafy.
Tyto grafy ukazují různé trendy k pochopení důvodů chyb a selhání při zatížení; pomáhá tedy zjistit, zda je vyžadována optimalizace na SUL, serveru (např. JBoss, Oracle) nebo v infrastruktuře.
Níže je uveden příklad, kde by šířka pásma mohla vytvářet úzké místo. Řekněme, že webový server má kapacitu 1 GB / s, zatímco datový provoz tuto kapacitu překračuje, což způsobuje, že následní uživatelé trpí. Aby bylo možné určit, jak systém vyhovuje těmto potřebám, potřebuje Performance Engineer analyzovat chování aplikace s abnormálním zatížením. Níže je uveden graf, který LoadRunner generuje k vyvolání šířky pásma.
Plán testování výkonu: Podrobné kroky
Plán testování výkonu lze rozdělit do 5 kroků:
- Plánování zátěžového testu
- Vytvářejte skripty VUGen
- Vytvoření scénáře
- Provedení scénáře
- Analýza výsledků (následovaná vyladěním systému)
Nyní, když máte nainstalovaný LoadRunner, pojďme postupně pochopit kroky procesu.
Kroky zapojené do procesu testování výkonu
Plánování zátěžového testu
Plánování testování výkonu se liší od plánování testování SIT (System Integration Testing) nebo UAT (User Acceptance Testing). Plánování lze dále rozdělit na malé etapy, jak je popsáno níže:
Sestavte svůj tým
Když začínáte s testováním LoadRunner, je nejlepší dokumentovat, kdo se bude účastnit aktivity od každého týmu zapojeného během procesu.
Projektový manažer:
Nominujte projektového manažera, který bude vlastnit tuto aktivitu a bude sloužit jako bodový pracovník pro eskalaci.
Funkční expert / obchodní analytik:
Poskytnout analýzu využití SUL a poskytnout odborné znalosti o obchodní funkčnosti webu / SUL
Expert na testování výkonu:
Vytvoří automatizované testy výkonu a provede scénáře načítání
Systémový architekt:
Poskytuje plán SUL
Webový vývojář a SME:
- Udržuje web a poskytuje aspekty monitorování
- Vyvíjí webové stránky a opravuje chyby
Správce systému:
- Udržuje zapojené servery v průběhu testovacího projektu
Zahrnuté aplikace a obchodní procesy:
Úspěšné testování zátěže vyžaduje, abyste plánovali provést určitý obchodní proces. Obchodní proces se skládá z jasně definovaných kroků v souladu s požadovanými obchodními transakcemi - za účelem splnění vašich cílů testování zátěže.
Lze připravit metriku požadavků k vyvolání zatížení uživatele v systému. Níže je uveden příklad docházkového systému ve společnosti:
Ve výše uvedeném příkladu obrázky uvádějí počet uživatelů připojených k aplikaci (SUL) v danou hodinu. Můžeme extrahovat maximální počet uživatelů připojených k obchodnímu procesu v kteroukoli hodinu dne, který se počítá ve sloupcích zcela vpravo.
Podobně můžeme konstatovat celkový počet uživatelů připojených k aplikaci (SUL) v kteroukoli hodinu dne. To se počítá v posledním řádku.
Kombinace výše uvedených 2 skutečností nám dává celkový počet uživatelů, se kterými musíme otestovat výkon systému.
Definujte postupy správy testovacích dat
Statistiky a pozorování získané z testování výkonu jsou do značné míry ovlivněny řadou faktorů, jak jsme již dříve informovali. Je zásadně důležité připravit testovací data pro testování výkonu. Někdy konkrétní obchodní proces spotřebuje datovou sadu a vytvoří jinou datovou sadu. Vezměte níže uvedený příklad:
- Uživatel „A“ vytvoří finanční smlouvu a předloží ji ke kontrole.
- Jiný uživatel „B“ schvaluje 200 kontraktů denně vytvořených uživatelem „A“
- Další uživatel „C“ platí přibližně 150 smluv denně schválených uživatelem „B“
V této situaci musí mít uživatel B v systému „vytvořeno“ 200 kontraktů. Kromě toho uživatel C potřebuje 150 smluv jako „schválených“, aby mohl simulovat zatížení 150 uživatelů.
To implicitně znamená, že musíte vytvořit alespoň 200 + 150 = 350 kontraktů.
Poté schválte 150 kontraktů, které budou sloužit jako testovací data pro uživatele C - zbývajících 200 kontraktů bude sloužit jako testovací data pro uživatele B.
Obrysové monitory
Spekulujte každý faktor, který by mohl ovlivnit výkon systému. Například snížení hardwaru bude mít potenciální dopad na výkon SUL (System Under Load).
Přihlaste všechny faktory a nastavte monitory, abyste je mohli měřit. Zde je několik příkladů:
- Procesor (pro webový server, aplikační server, databázový server a injektory)
- RAM (pro webový server, aplikační server, databázový server a injektory)
- Web / App Server (například IIS, JBoss, Jaguar Server, Tomcat atd.)
- DB Server (velikost PGA a SGA v případě serverů Oracle a MSSQL, SP atd.)
- Využití šířky pásma sítě
- Interní a externí síťová karta v případě shlukování
- Load Balancer (a že distribuuje zátěž rovnoměrně na všechny uzly klastrů)
- Tok dat (vypočítat, kolik dat se přesune na klienta a ze serveru - poté vypočítat, zda je kapacita NIC dostatečná pro simulaci X počtu uživatelů)
Vytvářejte skripty VUGen
Dalším krokem po plánování je vytvoření skriptů VUser.
Vytvoření scénáře
Dalším krokem je vytvoření scénáře načítání
Provedení scénáře
Spuštění scénáře je místo, kde emulujete zatížení uživatele na serveru instruováním více VUser k provádění úkolů současně.
Úroveň zatížení můžete nastavit zvýšením a snížením počtu VUsers, kteří provádějí úkoly současně.
Toto provedení může mít za následek, že server bude vystaven stresu a chová se neobvykle. To je samotný účel testování výkonu. Získané výsledky se poté použijí pro podrobnou analýzu a identifikaci hlavních příčin.
Analýza výsledků (následovaná vyladěním systému)
Během provádění scénáře LoadRunner zaznamenává výkon aplikace pod různými zatíženími. Statistiky získané z provedení testu se uloží a provede se podrobná analýza. Nástroj „Analýza HP“ generuje různé grafy, které pomáhají při identifikaci hlavních příčin zpoždění výkonu systému a selhání systému.
Některé ze získaných grafů zahrnují:
- Čas do první vyrovnávací paměti
- Doba odezvy transakce
- Průměrná doba odezvy transakce
- Hity za sekundu
- Prostředky Windows
- Statistiky chyb
- Shrnutí transakce
FAQ
Které aplikace bychom měli testovat?
Testování výkonu se vždy provádí pouze pro systémy založené na klient-server. To znamená, že jakákoli aplikace, která není architekturou typu klient-server, nesmí vyžadovat testování výkonu.
Například Microsoft Calculator není založen na klient-server ani nespouští více uživatelů; proto není kandidátem na testování výkonu.
Jaký je rozdíl mezi Performance Testing & Performance Engineering
Je důležité porozumět rozdílu mezi testováním výkonu a výkonovým inženýrstvím. Níže je uvedeno porozumění:
Testování výkonu je obor zabývající se testováním a vykazováním aktuálního výkonu softwarové aplikace podle různých parametrů.
Výkonové inženýrství je proces, při kterém je software testován a vyladěn s cílem dosáhnout požadovaného výkonu. Tento proces si klade za cíl optimalizovat nejdůležitější vlastnost výkonu aplikace, tj. Uživatelský komfort.
Historicky byly testování a ladění zřetelně oddělené a často konkurenční říše. V posledních několika letech však několik kapes testerů a vývojářů nezávisle spolupracovalo na vytváření tuningových týmů. Protože se tyto týmy setkaly s významným úspěchem, pojetí testování výkonu propojení s laděním výkonu se uchytilo a nyní tomu říkáme výkonnostní inženýrství.