Testovací nástroj LoadRunner – komponenty a Architecture

Co je LoadRunner?

LoadRunner je nástroj pro testování výkonnosti, který byl vyvinut společností Mercury v roce 1999. LoadRunner později získala společnost HPE v ​​roce 2006. V roce 2016 získala LoadRunner 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ů Testování výkonu. Výsledky testů výkonu vytvořené softwarem LoadRunner se používají jako benchmark proti jiným nástrojům

Načtení videa Runner

Proč LoadRunner?

LoadRunner je nejen průkopnickým nástrojem v oblasti testování výkonnosti, ale stále je lídrem na trhu v paradigmatu testování výkonnosti. Podle nedávného hodnocení má LoadRunner asi 85% podíl na trhu v odvětví testování výkonnosti.

Nástroj LoadRunner obecně podporuje RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex a Silverlight atd.), Mobile, SAP, Oracle, SLEČNA SQL Server, Citrix, RTE, Mail a především, Windows Zásuvka. Na trhu neexistuje žádný konkurenční nástroj, který by mohl nabídnout tak širokou škálu protokolů vázaných na jediný nástroj.

Co je přesvědčivější pro výběr LoadRunneru při testování softwaru, je důvěryhodnost tohoto nástroje. Nástroj LoadRunner si již dlouho vybudoval pověst, jak často najdete klienti křížově ověřují vaše výkonnostní benchmarky pomocí 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) a ALM (Application Lifecycle Management), které vám umožňují provádět komplexní testovací procesy.

LoadRunner funguje na principu simulace virtuálních uživatelů na předmětné aplikaci. Tito virtuální uživatelé nazývaní také VUsers replikují požadavky klienta a očekávají odpovídající odpověď na předání transakce.

Proč potřebujete testování výkonu?

Odhaduje se, že ztráta 4.4 miliardy příjmů je zaznamenávána každoročně kvůli špatnému výkonu webu.

V dnešní době Webu 2.0 uživatelé odkliknou, pokud web neodpoví do 8 sekund. Představte si, že při hledání na Googlu nebo při žádosti o přátelství na Facebooku čekáte 5 sekund. Důsledky výpadků výkonu jsou často ničivější, než jsme si kdy dokázali představit. Máme příklady, jako jsou ty, které nedávno zasáhly Bank of America Online Banking, Amazon Web Services, Intuit nebo Blackberry.

Podle Dunn & Bradstreet zažívá 59 % společností z Fortune 500 odhadem 1.6 hodiny prostojů každý týden. Vzhledem k tomu, že průměrná společnost z Fortune 500 s minimálně 10,000 56 zaměstnanci platí 896,000 USD za hodinu, pracovní část nákladů na prostoje pro takovou organizaci by činila 46 XNUMX USD týdně, což by znamenalo více než XNUMX milionů USD ročně.

Odhaduje se, že pouze 5minutový výpadek webu Google.com (19. srpna – 13. srpna) bude stát vyhledávacího giganta až 545,000 XNUMX USD.

Odhaduje se, že společnosti ztratily tržby v hodnotě 1100 USD za sekundu kvůli nedávnému Amazon Výpadek webové služby.

Když organizace nasadí softwarový systém, může se setkat s mnoha scénáři, které mohou vést k latenci výkonu. Řada faktorů způsobuje zpomalení výkonu, několik příkladů může zahrnovat:

• Zvýšený počet záznamů přítomných v databázi
• Zvýšený počet současných požadavků do systému
• větší počet uživatelů přistupujících do systému najednou ve srovnání s minulostí

Co je LoadRunner Architecture?

Obecně řečeno, architektura HP LoadRunner je složitá, ale snadno pochopitelná.

Předpokládejme, že jste pověřeni kontrolou výkonu Amazon.com pro 5000 uživatelů

V reálné situaci nebude těchto všech 5000 uživatelů na domovské stránce, ale v jiné části webových stránek. Jak můžeme simulovat jinak.

VUGen

VUGen nebo virtuální uživatel Generator je IDE (Integrated Development Environment) nebo bohatý editor kódování. VUGen se používá k replikaci chování systému pod zatížením (SUL). VUGen poskytuje funkci „nahrávání“, která zaznamenává komunikaci do az klienta a serveru ve formě kódovaného skriptu – také nazývaného VUser skript.

Vzhledem k výše uvedenému příkladu může VUGen zaznamenávat a simulovat následující obchodní procesy:

1. Procházení stránky produktů Amazon.com
2. Pokladna
3. Zpracování plateb
4. Kontrola stránky Můj účet

kontrolor

Jakmile je skript VUser dokončen, Controller je jednou z hlavních komponent LoadRunner, která řídí simulaci zatížení například správou:

• Kolik VUsers simulovat proti každému obchodnímu procesu nebo VUser Group
• Chování VUsers (náběh nahoru, rampa dolů, simultánní nebo souběžný charakter atd.)
• Povaha scénáře zatížení, např. Real Life nebo Cílově orientovaný nebo ověřující SLA
• Které vstřikovače použít, kolik VUsers proti každému vstřikovači
• Pravidelně třídit výsledky
• IP spoofing
• Hlášení chyb
• Hlášení transakcí atd.

Vezmeme-li analogii z našeho příkladu ovladače, přidáme do skriptu VUGen následující parametr

1) 3500 uživatelů Procházení stránky produktů Amazon.com

2) Je přihlášeno 750 uživatelů Pokladna

3) 500 uživatelů provádění Zpracování plateb

4) 250 uživatelů Kontrola stránky Můj účet POUZE poté, co 500 uživatelů provedlo zpracování plateb

Jsou možné i složitější scénáře

1. Iniciujte 5 VUs každé 2 sekundy až do zatížení 3500 VUsers (surfování Amazon produktová stránka).
2. Opakujte 30 minut
3. Pozastavit iteraci pro 25 VUsers
4. Restartujte 20 VUSerů
5. Každou sekundu iniciujte 2 uživatele (v Pokladně, Zpracování plateb, Stránka Moje účty).
6. Na stroji A bude vygenerováno 2500 VUsers
7. Na stroji B bude vygenerováno 2500 VUsers

Agenti Stroj/Nabít Generators/vstřikovače

HP LoadRunner Controller je zodpovědný za simulaci tisíců VUsers – ti VUsers spotřebovávají hardwarové zdroje, například procesor a paměť – a tím omezují stroj, který je simuluje. Kromě toho Controller simuluje tyto VUsers ze stejného stroje (kde Controller sídlí), a proto výsledky nemusí být přesné. K vyřešení tohoto problému jsou všichni VUsers rozmístěni na různých strojích, tzv Zatížení Generators nebo Load Injectors.

Obecně platí, že Controller je umístěn na jiném stroji 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áno několik Load Injectorů. Například VUsers pro HTTP skript bude vyžadovat 2-4 MB na VUser pro simulaci, takže 4 stroje se 4 GB RAM každý budou potřeba k simulaci zatížení 10,000 XNUMX VUsers.

Přebírání analogie z našeho Amazon Příkladem bude výstup této komponenty

Analýza

Jakmile jsou scénáře načtení provedeny, role „Analýza“ přichází komponenty LoadRunner.

Během provádění Controller vytvoří výpis výsledků v nezpracované formě a obsahuje informace, jako je, která verze LoadRunner vytvořila tento výpis výsledků a jaké byly konfigurace.

Všechny chyby a výjimky se zaznamenávají a Microsoft přístupová databáze, pojmenovaná, výstup.mdb. Komponenta „Analýza“ čte tento databázový soubor za účelem provádění různých typů analýz a generuje grafy.

Tyto grafy ukazují různé trendy pro pochopení příčin chyb a selhání při zatížení; pomáhá tak zjistit, zda je v SUL, Server (např. JBoss, Oracle) nebo infrastruktura.

Níže je uveden příklad, kdy 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 a následní uživatelé trpí. Aby bylo možné určit, že systém vyhovuje těmto potřebám, musí Performance Engineer analyzovat chování aplikace s abnormálním zatížením. Níže je graf, který LoadRunner generuje pro získání šířky pásma.

Jak provést testování výkonu

Plán testování výkonu lze obecně 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ásleduje ladění systému)

Nyní, když máte nainstalovaný LoadRunner, pojďme porozumět jednotlivým krokům procesu.

Kroky zahrnuté v procesu testování výkonu

Krok 1) Plánování zátěžového testu

Plánování testování výkonu se liší od plánování a SIT (testování systémové integrace) or UAT (User Acceptance Testing). Plánování lze dále rozdělit do malých fází, jak je popsáno níže:

Sestavte svůj tým

Když začínáte s testováním LoadRunner, je nejlepší zdokumentovat, kdo se bude podílet na aktivitě z 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á osoba pro eskalaci.

Expert na funkce / obchodní analytik:

Poskytuje analýzu využití SUL a poskytuje odborné znalosti o obchodní funkčnosti webových stránek/SUL

Expert na testování výkonu:

Vytváří automatické testy výkonu a spouští scénáře zatížení

Systém Architekt:

Poskytuje plán SUL

Webový vývojář a SME:

• Spravuje webové stránky a poskytuje monitorovací aspekty
• Vyvíjí webové stránky a opravuje chyby

Správce systému:

• Udržuje zapojené servery během testovacího projektu

Přehled aplikací a zahrnutých obchodních procesů:

Úspěšný Testování zatížení 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 – tak, aby byly splněny vaše cíle zátěžového testování.

Lze připravit metriku požadavků, která vyvolá zatížení systému uživatelem. Níže je uveden příklad docházkového systému ve firmě:

Ve výše uvedeném příkladu čísla 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ý je vypočítán ve sloupcích zcela vpravo.

Podobně můžeme usuzovat na celkový počet uživatelů připojených k aplikaci (SUL) v kteroukoli hodinu dne. To se počítá v posledním řádku.

Výše uvedené 2 skutečnosti dohromady nám dávají 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ýkonnosti jsou značně ovlivněny řadou faktorů, jak bylo uvedeno dříve. Je velmi důležité připravit testovací data pro testování výkonnosti. Někdy určitý obchodní proces spotřebuje sadu dat a vytvoří jinou sadu dat. Vezměte si níže uvedený příklad:

• Uživatel 'A' vytvoří finanční smlouvu a odešle ji ke kontrole.
• Jiný uživatel 'B' schvaluje 200 smluv denně vytvořených uživatelem 'A'
• Další uživatel 'C' platí asi 150 smluv denně schválených uživatelem 'B'

V této situaci musí uživatel B mít v systému „vytvořeno“ 200 smluv. 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 smluv.

Poté schválte 150 smluv, které budou sloužit jako testovací data pro uživatele C – zbývajících 200 smluv bude sloužit jako testovací data pro uživatele B.

Outline monitory

Spekulujte o všech faktorech, které by mohly ovlivnit výkon systému. Například omezení hardwaru bude mít potenciální dopad na výkon SUL (System Under Load).

Zahrňte všechny faktory a nastavte monitory, abyste je mohli změř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ě Oracle a MSSQL Server, SP atd.)
• Využití šířky pásma sítě
• Interní a externí NIC v případě shlukování
• Load Balancer (a že rozděluje zatížení rovnoměrně na všechny uzly clusterů)
• Datový tok (vypočítejte, kolik dat se přesune do az klienta a serveru – poté spočítejte, zda je kapacita NIC dostatečná k simulaci X počtu uživatelů)

Krok 2) Vytvořte skripty VUGen

Dalším krokem po plánování je vytvoření VUser skripty.

Krok 3) Vytvoření scénáře

Dalším krokem je vytvoření scénáře zatížení

Krok 4) Provedení scénáře

Spuštění scénáře je místo, kde emulujete zatížení uživatele na serveru tím, že přikážete více uživatelům VU provádět úkoly současně.

Úroveň zátěže můžete nastavit zvýšením a snížením počtu VUsers, které provádějí úkoly současně.

Toto provedení může vést k tomu, že server přejde do zátěže a bude se chovat abnormálně. To je samotný účel testování výkonnosti. Získané výsledky se pak použijí pro podrobnou analýzu a identifikaci hlavní příčiny.

Krok 5) Analýza výsledků (následuje ladění systému)

Během provádění scénáře LoadRunner zaznamenává výkon aplikace při různých zatíženích. Statistiky získané z provádění testu se uloží a provede se podrobná analýza. Nástroj „HP Analysis“ generuje různé grafy, které pomáhají identifikovat hlavní příčiny zpoždění výkonu systému a také 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
• Počet zásahů za sekundu
• Windows Zdroje
• Statistika chyb
• Přehled transakcí

Nejčastější dotazy