Čo je LoadRunner?
LoadRunner je nástroj na testovanie výkonu, ktorý bol priekopníkom spoločnosti Mercury v roku 1999. Program LoadRunner bol neskôr zakúpený spoločnosťou HPE v roku 2006. V roku 2016 bol produkt LoadRunner zakúpený spoločnosťou MicroFocus.
LoadRunner podporuje rôzne vývojové nástroje, technológie a komunikačné protokoly. V skutočnosti je to jediný nástroj na trhu, ktorý podporuje také veľké množstvo protokolov na vykonávanie testovania výkonnosti. Výsledky testov výkonnosti produkované softvérom LoadRunner sa používajú ako meradlo s ostatnými nástrojmi
V tomto návode sa naučíte
- Prečo LoadRunner?
- Prečo potrebujete Testovanie výkonu?
- Čo je to architektúra LoadRunner?
- Plán testovania výkonnosti: Podrobné kroky
- FAQ
Prečo LoadRunner?
LoadRunner je nielen priekopníckym nástrojom v oblasti testovania výkonu, ale stále je lídrom na trhu v paradigme testovania výkonu. Podľa nedávneho hodnotenia má LoadRunner asi 85% trhový podiel v priemysle testovania výkonnosti.
Nástroj LoadRunner všeobecne podporuje RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex a Silverlight atď.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail a predovšetkým Windows Socket. Na trhu neexistuje žiadny konkurenčný nástroj, ktorý by mohol ponúknuť takú širokú škálu protokolov vložených do jediného nástroja.
Čo je presvedčivejšie pri výbere nástroja LoadRunner pri testovaní softvéru, je dôveryhodnosť tohto nástroja. Nástroj LoadRunner si už dlho získal reputáciu, pretože často nájdete klientov, ktorí si pomocou nástroja LoadRunner overujú vaše výkonnostné hodnoty. Úľavu nájdete, ak už LoadRunner používate pre svoje potreby testovania výkonu.
Softvér LoadRunner je úzko integrovaný s ostatnými nástrojmi HP, ako sú Unified Functional Test (QTP) a ALM (Application Lifecycle Management), vďaka ktorým môžete vykonávať komplexné testovacie procesy.
LoadRunner pracuje na princípe simulácie virtuálnych používateľov v predmetnej aplikácii. Títo virtuálni používatelia sa tiež nazývajú VUsers, replikujú požiadavky klientov a očakávajú zodpovedajúcu odpoveď na odovzdanie transakcie.
Prečo potrebujete Testovanie výkonu?
Odhaduje sa ročná strata vo výške 4,4 miliárd z dôvodu slabého výkonu webu.
V dnešnej dobe Web 2.0 používatelia klikajú preč, ak web nereaguje do 8 sekúnd. Predstavte si, že čakáte 5 sekúnd pri hľadaní Google alebo pri žiadosti o priateľstvo na Facebooku. Dôsledky výpadkov výkonu sú často ničivejšie, ako si kedykoľvek predstavovali. Máme príklady, ako napríklad tie, ktoré nedávno zasiahli Bank of America Online Banking, Amazon Web Services, Intuit alebo Blackberry.
Podľa Dunn & Bradstreet 59% spoločností z rebríčka Fortune 500 zažíva každý týždeň odhadom 1,6 hodiny výpadku. Ak vezmeme do úvahy, že priemerná spoločnosť zaradená do rebríčka Fortune 500 s minimálne 10 000 zamestnancami platí 56 dolárov za hodinu, pracovná časť nákladov na prestoje pre takúto organizáciu by bola 896 000 dolárov týždenne, čo by predstavovalo viac ako 46 miliónov dolárov ročne.
Odhaduje sa, že iba päťminútový výpadok webu Google.com (19. augusta - 13) stojí vyhľadávacieho giganta až 545 000 dolárov.
Odhaduje sa, že spoločnosti prišli o tržby v hodnote 1100 dolárov za sekundu v dôsledku nedávneho výpadku webovej služby Amazon.
Keď je softvérový systém nasadený organizáciou, môže sa stretnúť s mnohými scenármi, ktoré môžu mať za následok latenciu výkonu. Spomalenie výkonu spôsobuje niekoľko faktorov, napríklad:
- Zvýšený počet záznamov v databáze
- Zvýšený počet simultánnych požiadaviek odoslaných do systému
- väčší počet používateľov pristupujúcich k systému v rovnakom čase v porovnaní s minulosťou
Čo je to architektúra LoadRunner?
Všeobecne povedané, architektúra HP LoadRunner je zložitá, ale ľahko pochopiteľná.
Predpokladajme, že ste poverení kontrolovať výkon stránky Amazon.com pre 5 000 používateľov
V skutočnej situácii nebude týchto všetkých 5 000 používateľov na domovskej stránke, ale v inej sekcii webových stránok. Ako môžeme simulovať inak
VUGen:
VUGen alebo Virtual User Generator je IDE (integrované vývojové prostredie) alebo editor bohatého kódovania. VUGen sa používa na replikáciu správania systému pod zaťažením (SUL). VUGen poskytuje funkciu „nahrávania“, ktorá zaznamenáva komunikáciu do az klienta a na server vo forme kódovaného skriptu - tiež nazývaného skript VUser.
Vzhľadom na vyššie uvedený príklad môže VUGen nahrávať a simulovať nasledujúce obchodné procesy:
- Prehliadanie stránky produktov na Amazon.com
- Odhlásiť sa
- Spracovanie platby
- Prebieha kontrola stránky Môj účet
Kontrolór
Po dokončení skriptu VUser je Controller jednou z hlavných súčastí LoadRunner, ktorá riadi simuláciu načítania tak, že spravuje napríklad:
- Koľko VUsers simulovať proti každému obchodnému procesu alebo VUser Group
- Správanie VUsers (nábeh, nábeh, simultánny alebo súbežný charakter atď.)
- Scenár charakteru zaťaženia, napr. Real Life alebo Goal Oriented alebo overenie SLA
- Ktoré injektory sa majú použiť, koľko VUser proti každému injektoru
- Pravidelne zhromažďujte výsledky
- IP spoofing
- Hlásenie chýb
- Hlásenie transakcií atď.
Ak použijeme analogický príklad z nášho príkladu, kontrolér pridá nasledujúci parameter do skriptu VUGen
1) 3 500 používateľov surfuje na stránke produktov na Amazon.com
2) 750 používateľov je v pokladni
3) Spracovanie platieb vykonáva 500 používateľov
4) 250 používateľov stránku MYAccount kontroluje IBA po 500 používateľoch, ktorí vykonali spracovanie platby
Možné sú aj zložitejšie scenáre
- Iniciovajte 5 VUsers každé 2 sekundy, kým sa nedosiahne zaťaženie 3 500 VUsers (surfovanie na stránke produktu Amazon).
- Iterujte 30 minút
- Pozastavte iteráciu pre 25 používateľov
- Reštartujte 20 VUSerov
- Každú sekundu iniciujte 2 používateľov (v pokladni, na stránke Spracovanie platieb, na stránke Moje účty).
- Na stroji A bude vygenerovaných 2 500 používateľov
- Na stroji B bude vygenerovaných 2 500 používateľov
Agenti Stroj / Generátory záťaže / Vstrekovače
HP LoadRunner Controller je zodpovedný za simuláciu tisícov VUsers - títo VUsers spotrebúvajú hardvérové prostriedky, napríklad procesor a pamäť - teda obmedzujú stroj, ktorý ich simuluje. Okrem toho radič simuluje týchto VUserov z rovnakého stroja (kde sa nachádza radič), a preto výsledky nemusia byť presné. Za účelom riešenia tohto problému sú všetci používatelia VU rozdelení do rôznych strojov, ktoré sa nazývajú generátory záťaže alebo injektory záťaže.
Všeobecne platí, že radič býva na inom stroji a záťaž sa simuluje z iných strojov. V závislosti od protokolu skriptov VUser a technických údajov stroja môže byť pre úplnú simuláciu potrebných niekoľko injektorov záťaže. Napríklad VUsers pre skript HTTP budú na simuláciu vyžadovať 2 - 4 MB na VUsera, a preto budú na simuláciu zaťaženia 10 000 VUsers potrebné 4 stroje so 4 GB RAM.
Keď si vezmeme analógiu z nášho príkladu na Amazone, bude výstup tohto komponentu
Analýza:
Po vykonaní scenárov načítania sa objaví úloha komponentov „ Analýza “ v aplikácii LoadRunner.
Počas vykonávania kontrolér vytvorí výpis výsledkov v surovej podobe a obsahuje informácie ako, ktorá verzia aplikácie LoadRunner vytvorila tento výpis výsledkov a aké boli konfigurácie.
Všetky chyby a výnimky sa zaznamenávajú do prístupovej databázy Microsoftu s názvom output.mdb. Komponent "Analýza" číta tento databázový súbor na vykonávanie rôznych typov analýz a generuje grafy.
Tieto grafy ukazujú rôzne trendy, aby ste pochopili dôvody chýb a zlyhaní pri zaťažení; a tým pomôcť zistiť, či je vyžadovaná optimalizácia na SUL, serveri (napr. JBoss, Oracle) alebo v infraštruktúre.
Ďalej uvádzame príklad, v ktorom môže šírka pásma vytvárať úzke miesto. Povedzme, že webový server má kapacitu 1 GB / s, zatiaľ čo dátový prenos túto kapacitu prekračuje, čo spôsobuje následných používateľov. Na určenie systému vyhovujúceho takýmto potrebám musí Performance Engineer analyzovať správanie aplikácie s abnormálnym zaťažením. Nižšie je uvedený graf, ktorý generuje LoadRunner na vyvolanie šírky pásma.
Plán testovania výkonnosti: Podrobné kroky
Plán testovania výkonnosti možno rozdeliť do 5 krokov:
- Plánovanie záťažového testu
- Vytvorte skripty VUGen
- Vytvorenie scenára
- Vykonanie scenára
- Analýza výsledkov (po ktorých nasleduje vyladenie systému)
Teraz, keď máte nainštalovaný LoadRunner, pochopme postupne jednotlivé kroky procesu.
Kroky zapojené do procesu testovania výkonu
Plánovanie záťažového testu
Plánovanie testovania výkonu sa líši od plánovania SIT (testovanie integrácie systému) alebo UAT (testovanie prijatia používateľa). Plánovanie možno ďalej rozdeliť na malé etapy, ako je uvedené nižšie:
Zostavte svoj tím
Ak začínate s testovaním LoadRunner, je najlepšie zdokumentovať, kto sa zúčastní na aktivite z každého tímu zapojeného do procesu.
Projektový manažér:
Vymenujte projektového manažéra, ktorý bude vlastniť túto aktivitu a bude slúžiť ako bodový pracovník pre eskaláciu.
Funkčný expert / obchodný analytik:
Poskytnúť analýzu používania SUL a poskytnúť odborné znalosti o obchodnej funkčnosti webových stránok / SUL
Expert na testovanie výkonu:
Vytvára automatizované testy výkonu a vykonáva scenáre načítania
Systémový architekt:
Poskytuje plán SUL
Webový vývojár a SME:
- Udržuje webovú stránku a poskytuje aspekty monitorovania
- Vyvíja webovú stránku a opravuje chyby
Systémový administrátor:
- Udržuje zapojené servery počas celého testovacieho projektu
Zahrnuté príslušné aplikácie a obchodné procesy:
Úspešné testovanie zaťaženia vyžaduje, aby ste plánovali vykonať určitý obchodný proces. Obchodný proces pozostáva z jasne definovaných krokov v súlade s požadovanými obchodnými transakciami - aby ste dosiahli svoje ciele testovania záťaže.
Na vyvolanie zaťaženia systému používateľom je možné pripraviť metriku požiadaviek. Nižšie uvádzame príklad dochádzkového systému vo firme:
Vo vyššie uvedenom príklade obrázky spomínajú počet používateľov pripojených k aplikácii (SUL) v danú hodinu. Môžeme extrahovať maximálny počet používateľov pripojených k obchodnému procesu v ktorúkoľvek hodinu dňa, ktorý sa počíta v stĺpcoch úplne vpravo.
Podobne môžeme konštatovať celkový počet používateľov pripojených k aplikácii (SUL) v ktorúkoľvek dennú hodinu. Toto sa počíta v poslednom riadku.
Vyššie uvedené 2 skutočnosti nám dávajú celkový počet používateľov, s ktorými musíme testovať výkon systému.
Definujte postupy správy testovacích údajov
Štatistiky a pozorovania získané z testovania výkonnosti sú do veľkej miery ovplyvnené mnohými faktormi, ako sme už uviedli. Príprava dát testu na testovanie výkonu má zásadný význam. Konkrétny obchodný proces niekedy spotrebuje množinu údajov a vytvorí inú množinu údajov. Vezmime si nižšie uvedený príklad:
- Používateľ „A“ vytvorí finančnú zmluvu a predloží ju na kontrolu.
- Iný používateľ „B“ schvaľuje 200 zmlúv denne vytvorených používateľom „A“
- Ďalší používateľ „C“ platí okolo 150 zmlúv denne schválených používateľom „B“
V tejto situácii musí mať používateľ B v systéme „vytvorených“ 200 zmlúv. Okrem toho používateľ C potrebuje 150 zmlúv ako „schválených“, aby mohol simulovať zaťaženie 150 používateľov.
To implicitne znamená, že musíte vytvoriť najmenej 200 + 150 = 350 zmlúv.
Potom schválte 150 zmlúv, ktoré budú slúžiť ako testovacie údaje pre používateľa C - zvyšných 200 zmlúv bude slúžiť ako testovacie údaje pre používateľa B.
Obrysové monitory
Špekulujte všetky faktory, ktoré by mohli ovplyvniť výkon systému. Napríklad redukcia hardvéru bude mať potenciálny dopad na výkon SUL (System Under Load).
Zaraďte všetky faktory a nastavte monitory, aby ste ich mohli merať. Tu je niekoľko príkladov:
- Procesor (pre webový server, aplikačný server, databázový server a injektory)
- RAM (pre webový server, aplikačný server, databázový server a injektory)
- Web / App Server (napríklad IIS, JBoss, Jaguar Server, Tomcat atď.)
- DB Server (veľkosť PGA a SGA v prípade serverov Oracle a MSSQL, SP atď.)
- Využitie šírky pásma siete
- Interný a externý sieťový adaptér v prípade zoskupovania
- Load Balancer (a že distribuuje záťaž rovnomerne na všetky uzly klastrov)
- Tok dát (vypočítajte, koľko dát sa presunie do az klienta a servera - potom vypočítajte, či je kapacita NIC dostatočná na simuláciu X počtu používateľov)
Vytvorte skripty VUGen
Ďalším krokom po plánovaní je vytvorenie skriptov VUser.
Vytvorenie scenára
Ďalším krokom je vytvorenie scenára načítania
Vykonanie scenára
Vykonanie scenára je miesto, kde emulujete užívateľské zaťaženie na serveri tým, že dáte pokyn viacerým VUserom, aby vykonávali úlohy súčasne.
Úroveň zaťaženia môžete nastaviť zvýšením a znížením počtu VUsers, ktoré vykonávajú úlohy súčasne.
Toto spustenie môže viesť k tomu, že server bude pod stresom a bude sa správať nenormálne. Toto je samotný účel Testovania výkonu. Získané výsledky sa potom použijú na podrobnú analýzu a identifikáciu základných príčin.
Analýza výsledkov (po ktorých nasleduje vyladenie systému)
Počas vykonávania scenára LoadRunner zaznamenáva výkon aplikácie pri rôznych zaťaženiach. Štatistiky získané z vykonania testu sa uložia a vykoná sa podrobná analýza. Nástroj „Analýza HP“ generuje rôzne grafy, ktoré pomáhajú identifikovať hlavné príčiny oneskorenia výkonu systému a zlyhania systému.
Niektoré zo získaných grafov zahŕňajú:
- Čas do prvej vyrovnávacej pamäte
- Čas odozvy transakcie
- Priemerný čas odozvy transakcie
- Hity za sekundu
- Zdroje Windows
- Štatistika chýb
- Zhrnutie transakcie
FAQ
Ktoré aplikácie by sme mali testovať?
Testovanie výkonu sa vždy vykonáva iba pre systémy založené na klient-server. To znamená, že každá aplikácia, ktorá nie je architektúrou typu klient-server, nesmie vyžadovať testovanie výkonu.
Napríklad Microsoft Calculator nie je založený na klient-serveri ani nespúšťa viac používateľov; preto nie je kandidátom na testovanie výkonnosti.
Aký je rozdiel medzi testovaním výkonu a výkonovým inžinierstvom
Je dôležité pochopiť rozdiel medzi testovaním výkonu a výkonovým inžinierstvom. Pochopenie zdieľame nižšie:
Testovanie výkonu je disciplína zaoberajúca sa testovaním a vykazovaním aktuálneho výkonu softvérovej aplikácie podľa rôznych parametrov.
Výkonové inžinierstvo je proces, ktorým sa testuje a ladí softvér s cieľom dosiahnuť požadovaný výkon. Tento proces si kladie za cieľ optimalizovať najdôležitejšiu vlastnosť výkonu aplikácie, tj užívateľskú skúsenosť.
Historicky boli testovanie a ladenie zreteľne oddelené a často si konkurovali. V posledných niekoľkých rokoch však niekoľko vreciek testerov a vývojárov nezávisle spolupracovalo na vytvorení tuningových tímov. Pretože sa tieto tímy stretli s významným úspechom, koncept spojenia testovania výkonu s vyladením výkonu sa uchytil a teraz mu hovoríme výkonové inžinierstvo.