LoadRunner tesztelőeszköz – Alkatrészek és Architectúra

Mi az a LoadRunner?

LoadRunner egy teljesítménytesztelő eszköz, amelynek úttörője volt Mercury 1999-ben. A LoadRunnert később 2006-ban felvásárolta a HPE. 2016-ban a MicroFocus megvásárolta a LoadRunnert.

A LoadRunner különféle fejlesztőeszközöket, technológiákat és kommunikációs protokollokat támogat. Valójában ez az egyetlen eszköz a piacon, amely ilyen nagy számú protokollt támogat Teljesítményfelmérés. A LoadRunner szoftver által készített teljesítményteszt-eredményeket más eszközökkel összehasonlítva használjuk

LoadRunner videó

Miért a LoadRunner?

LoadRunner nemcsak úttörő eszköz a teljesítménytesztelésben, de még mindig piacvezető a teljesítménytesztelés paradigmája terén. Egy közelmúltbeli értékelés szerint a LoadRunner körülbelül 85%-os piaci részesedéssel rendelkezik a teljesítménytesztelés területén.

Általánosságban a LoadRunner eszköz támogatja a RIA-t (Rich Internet Applications), a Web 2.0-t (HTTP/HTML, Ajax, Flex és Silverlight stb.), mobilt, SAP, Oracle, KISASSZONY SQL Szerver, Citrix, RTE, Mail és mindezek felett, Windows Foglalat. Nincs olyan versenytárs eszköz a piacon, amely egyetlen eszközre ruházott protokollok ilyen széles választékát kínálná.

Ami még meggyőzőbb a LoadRunner kiválasztásánál a szoftvertesztelés során, az az eszköz hitelessége. A LoadRunner eszköz már régóta jó hírnevet szerzett, amilyen gyakran előfordul Az ügyfelek keresztezve ellenőrzik a teljesítmény-benchmarkokat a LoadRunner segítségével. Megkönnyebbülést fog találni, ha már használja a LoadRunnert teljesítménytesztelési igényeihez.

A LoadRunner szoftver szorosan integrálva van más HP-eszközökkel, például az egységes funkcionális teszttel (QTP) és az ALM-mel (Alkalmazás-életciklus-kezelés), és lehetővé teszi a tesztelési folyamatok végpontjai közötti végrehajtását.

A LoadRunner azon az elven működik, hogy virtuális felhasználókat szimulál a tárgyalkalmazáson. Ezeket a virtuális felhasználókat VU-felhasználóknak is nevezik, replikálják az ügyfél kéréseit, és megfelelő választ várnak egy tranzakció átadásakor.

Miért van szükség teljesítménytesztre?

A becslések szerint 4.4 milliárdos bevételkiesés évente rögzítik a gyenge webteljesítmény miatt.

A Web 2.0 mai korában a felhasználók kattintással távoznak, ha egy webhely 8 másodpercen belül nem válaszol. Képzelje el, hogy vár 5 másodpercet, amikor a Google-ra keres, vagy baráti kérést küld a Facebookon. A teljesítményleállások következményei gyakran pusztítóbbak, mint azt valaha is gondolták. Vannak olyan példáink, amelyek nemrégiben jelentek meg a Bank of America Online Banking oldalán, Amazon Web Services, Intuit vagy Blackberry.

A Dunn & Bradstreet szerint a Fortune 59-as cégek 500%-a hetente 1.6 óra állásidőt tapasztal. Figyelembe véve, hogy egy átlagos, legalább 500 10,000 alkalmazottat foglalkoztató Fortune 56 vállalat 896,000 dollárt fizet óránként, egy ilyen szervezetnél az állásidő költségeinek munkaerő-része heti 46 XNUMX dollár lenne, ami évente több mint XNUMX millió dollárt jelent.

A Google.com mindössze 5 perces leállása (augusztus 19. 13.) a becslések szerint 545,000 XNUMX dollárba kerül a keresőóriásnak.

Becslések szerint a vállalatok másodpercenként 1100 dollár értékű árbevételt veszítettek egy közelmúltban Amazon Webszolgáltatás kimaradás.

Amikor egy szoftverrendszert egy szervezet telepít, számos olyan forgatókönyvvel találkozhat, amelyek teljesítmény késést eredményezhetnek. Számos tényező okozza a teljesítmény lassulását, néhány példa a következők lehetnek:

• Az adatbázisban lévő rekordok száma megnövekedett
• Megnövekedett a rendszerhez intézett egyidejű kérések száma
• a korábbihoz képest egyszerre több felhasználó fér hozzá a rendszerhez

Mi az a LoadRunner Architectúra?

Általánosságban elmondható, hogy a HP LoadRunner architektúrája összetett, mégis könnyen érthető.

Tegyük fel, hogy Önt a teljesítményének ellenőrzésére bízták Amazon.com 5000 felhasználó számára

Valós helyzetben ez az 5000 felhasználó nem a honlapon lesz, hanem a weboldalak egy másik részében. Hogyan szimulálhatunk másképp.

VUGen

VUGen vagy virtuális felhasználó Generator egy IDE (Integrated Development Environment) vagy egy gazdag kódszerkesztő. A VUGen a System Under Load (SUL) viselkedés replikálására szolgál. A VUGen egy „rögzítési” funkciót biztosít, amely a kliens és a szerver közötti kommunikációt kódolt szkript formájában rögzíti – más néven VUser script.

Tehát a fenti példát figyelembe véve a VUGen a következő üzleti folyamatok szimulálására képes rögzíteni:

1. Böngészés a termékek oldalán Amazon.com
2. Megrendelés
3. Payment Processing
4. A Saját fiók oldal ellenőrzése

ellenőr

A VUser szkript véglegesítése után a Vezérlő az egyik fő LoadRunner komponens, amely vezérli a terhelési szimulációt például:

• Hány VU-felhasználót kell szimulálni az egyes üzleti folyamatokhoz vagy VUser-csoportokhoz
• A VU-felhasználók viselkedése (felfelé, lefelé, egyidejű vagy párhuzamos természet stb.)
• Terhelés jellege forgatókönyv, pl. valós élet vagy célorientált vagy ellenőrző SLA
• Milyen injektorokat kell használni, hány VU-t kell használni az egyes injektorokhoz
• Rendszeresen gyűjtsd össze az eredményeket
• IP-hamisítás
• Hiba jelentésekor
• Tranzakciójelentés stb.

A példavezérlőnk analógiájával a következő paramétert adjuk hozzá a VUGen Scripthez

1) 3500 felhasználó van Böngészés a termékek oldalán Amazon.com

2) 750 felhasználó van jelen Megrendelés

3) 500 felhasználó van Fizetésfeldolgozás elvégzése

4) 250 felhasználó van A Saját fiók oldalának ellenőrzése CSAK 500 felhasználó fizetési feldolgozása után

Még bonyolultabb forgatókönyvek is lehetségesek

1. 5 másodpercenként indítson 2 VU-felhasználót 3500 VU-felhasználó betöltéséhez (szörfözés Amazon termékoldal) valósul meg.
2. Ismételje 30 percig
3. Az iteráció felfüggesztése 25 VU-felhasználó esetén
4. Indítson újra 20 VUS-t
5. Másodpercenként 2 felhasználó kezdeményezése (a Fizetés, Fizetésfeldolgozás, Saját fiókok oldalon).
6. 2500 VU-felhasználót állítanak elő az A gépen
7. 2500 VU-felhasználót állítanak elő a B gépen

Agents Machine/Load Generators/Injektorok

A HP LoadRunner Controller több ezer VU-felhasználó szimulálásáért felel – ezek a VU-felhasználók hardvererőforrásokat, például processzort és memóriát fogyasztanak – így korlátozza az őket szimuláló gépet. Ezenkívül a Controller ugyanarról a gépről (ahol a vezérlő található) szimulálja ezeket a VU-felhasználókat, ezért az eredmények nem biztos, hogy pontosak. Ennek az aggálynak a megoldása érdekében az összes VU-szerver különböző gépeken van elosztva, ún Terhelés Generators vagy terhelési befecskendezők.

Általános gyakorlat, hogy a vezérlő egy másik gépen található, és a terhelést más gépektől szimulálják. A VUser szkriptek protokolljától és a gép specifikációitól függően számos terhelési befecskendezőre lehet szükség a teljes szimulációhoz. Például egy HTTP-szkripthez tartozó VU-felhasználóknak VU-szerenként 2-4 MB-ra van szükségük a szimulációhoz, így 4, egyenként 4 GB RAM-mal rendelkező gépre lesz szükség 10,000 XNUMX VU-felhasználó terhelésének szimulálásához.

Analógiát átvéve a mi tőlünk Amazon Például ennek a komponensnek a kimenete a következő lesz

Elemzés

A Betöltési forgatókönyvek végrehajtása után a „Elemzés” jön be a LoadRunner összetevői.

A végrehajtás során a Controller nyers formában hoz létre egy kiíratot az eredményekről, és olyan információkat tartalmaz, mint például, hogy a LoadRunner melyik verziója hozta létre ezt az eredménykiírást, és melyek voltak a konfigurációk.

Minden hiba és kivétel be van naplózva a Microsoft hozzáférési adatbázis, nevű, output.mdb. Az „Elemzés” komponens beolvassa ezt az adatbázisfájlt különféle típusú elemzések elvégzéséhez, és grafikonokat generál.

Ezek a grafikonok különböző tendenciákat mutatnak be, hogy megértsék a hibák és terhelés alatti meghibásodások okait; így segít eldönteni, hogy szükség van-e optimalizálásra a SUL-ban, szerverben (pl. JBoss, Oracle) vagy infrastruktúra.

Az alábbiakban látható egy példa, ahol a sávszélesség szűk keresztmetszetet okozhat. Tegyük fel, hogy a webszerver 1 GB/s-os kapacitással rendelkezik, míg az adatforgalom meghaladja ezt a kapacitást, ami a későbbi felhasználók szenvedését okozza. Annak megállapításához, hogy a rendszer megfelel ezeknek az igényeknek, a Performance Engineernek elemeznie kell az alkalmazás viselkedését rendellenes terhelés esetén. Az alábbiakban látható egy grafikon, amelyet a LoadRunner generál a sávszélesség kiváltására.

Hogyan végezzünk teljesítménytesztet

A teljesítménytesztelési ütemterv nagyjából 5 lépésre osztható:

• Terhelési teszt tervezése
• Hozzon létre VUGen szkripteket
• Forgatókönyv létrehozása
• Forgatókönyv végrehajtása
• Eredmények elemzése (amit a rendszer módosítása követ)

Most, hogy a LoadRunner telepítve van, ismerjük meg egyenként a folyamat lépéseit.

A teljesítménytesztelési folyamat lépései

1. lépés) Terhelési teszt tervezése

A teljesítményteszt tervezése eltér a tervezéstől SIT (rendszerintegrációs tesztelés) or UAT (felhasználói elfogadási teszt). A tervezés további kis szakaszokra osztható az alábbiak szerint:

Állítsa össze csapatát

A LoadRunner tesztelés megkezdésekor a legjobb dokumentálni, hogy a folyamatban részt vevő egyes csapatok közül kik vesznek részt a tevékenységben.

Projekt menedzser:

Jelölje ki azt a projektmenedzsert, aki ennek a tevékenységnek a tulajdonosa lesz, és aki az eszkaláció pontja lesz.

Funkciószakértő/üzleti elemző:

A SUL használatának elemzése és a webhely/SUL üzleti funkcióival kapcsolatos szakértelem

Teljesítményvizsgálati szakértő:

Létrehozza az automatikus teljesítményteszteket, és végrehajtja a betöltési forgatókönyveket

rendszer Architect:

A SUL tervrajzát nyújtja

Webfejlesztő és kkv:

• Karbantartja a weboldalt és felügyeleti szempontokat biztosít
• Weboldalt fejleszt és hibákat javít

Rendszergazda:

• Karbantartja az érintett szervereket a tesztelési projekt során

Vázolja fel az érintett alkalmazásokat és üzleti folyamatokat:

Sikeres Terhelésvizsgálat megköveteli, hogy bizonyos üzleti folyamatokat tervezzen végrehajtani. Az üzleti folyamat világosan meghatározott lépésekből áll, összhangban a kívánt üzleti tranzakciókkal – a terhelési teszt céljainak elérése érdekében.

Előállítható egy követelménymérő a rendszer felhasználói terhelésének kiváltására. Az alábbiakban egy vállalati jelenléti rendszer példája látható:

A fenti példában az ábrák az alkalmazáshoz (SUL) kapcsolt felhasználók számát jelzik adott órán. A nap bármely órájában ki tudjuk gyűjteni az üzleti folyamathoz kapcsolódó felhasználók maximális számát, amely a jobb szélső oszlopokban kerül kiszámításra.

Hasonlóképpen megállapíthatjuk az alkalmazáshoz (SUL) kapcsolódó felhasználók teljes számát a nap bármely órájában. Ezt az utolsó sorban számítjuk ki.

A fenti 2 tény együttesen megadja a felhasználók teljes számát, amellyel tesztelnünk kell a rendszer teljesítményét.

Határozza meg a tesztadatkezelési eljárásokat

A teljesítménytesztelésből származó statisztikákat és megfigyeléseket számos tényező nagymértékben befolyásolja, amint azt korábban ismertettük. Kritikus jelentőségű a tesztadatok előkészítése a teljesítményteszthez. Néha egy adott üzleti folyamat felhasznál egy adatkészletet, és egy másik adatkészletet állít elő. Vegyünk az alábbi példát:

• Az „A” felhasználó pénzügyi szerződést hoz létre, és benyújtja azt felülvizsgálatra.
• Egy másik „B” felhasználó napi 200 szerződést hagy jóvá „A” felhasználó által
• Egy másik „C” felhasználó naponta körülbelül 150 szerződést fizet, amelyet a „B” felhasználó hagy jóvá.

Ebben a helyzetben B felhasználónak 200 szerződést kell „létrehoznia” a rendszerben. Emellett a C felhasználónak 150 „jóváhagyott” szerződésre van szüksége ahhoz, hogy 150 felhasználós terhelést szimuláljon.

Ez implicit módon azt jelenti, hogy legalább 200+150=350 szerződést kell létrehoznia.

Ezt követően hagyjon jóvá 150 szerződést, hogy tesztadatként szolgáljon a C felhasználóhoz – a fennmaradó 200 szerződés pedig a B felhasználó tesztadataként szolgál majd.

Outline monitorok

Gondoljon minden olyan tényezőre, amely befolyásolhatja a rendszer teljesítményét. Például a csökkentett hardver potenciális hatással lehet a SUL (rendszer terhelés alatt) teljesítményére.

Vegye figyelembe az összes tényezőt, és állítson be monitorokat, hogy felmérhesse őket. Íme néhány példa:

• Processzor (webszerverhez, alkalmazásszerverhez, adatbázis-kiszolgálóhoz és injektorokhoz)
• RAM (webszerverhez, alkalmazásszerverhez, adatbázis-kiszolgálóhoz és befecskendezőkhöz)
• Web-/alkalmazásszerver (például IIS, JBoss, Jaguar Server, Tomcat stb.)
• DB Server (PGA és SGA méret esetén Oracle és MSSQL Server, SP stb.)
• Hálózati sávszélesség kihasználása
• Belső és külső NIC klaszterezés esetén
• Load Balancer (és hogy egyenletesen osztja el a terhelést a fürt összes csomópontján)
• Adatfluxus (számítsa ki, hogy mennyi adat mozog a kliens és a szerver között, majd számítsa ki, hogy a hálózati kártya kapacitása elegendő-e X számú felhasználó szimulálásához)

2. lépés) Hozzon létre VUGen szkripteket

A tervezés után következő lépés az alkotás VUser szkriptek.

3. lépés) Forgatókönyv létrehozása

A következő lépés a betöltési forgatókönyv létrehozása

4. lépés) A forgatókönyv végrehajtása

A forgatókönyv-végrehajtás során emulálja a felhasználói terhelést a kiszolgálón úgy, hogy több VU-felhasználót utasít a feladatok egyidejű végrehajtására.

A terhelés mértékét úgy állíthatja be, hogy növeli és csökkenti a feladatokat egyidejűleg végrehajtó VU-felhasználók számát.

Ez a végrehajtás azt eredményezheti, hogy a szerver stressz alá kerül, és rendellenesen viselkedik. Ez a teljesítményteszt célja. A levont eredményeket ezután részletes elemzéshez és a kiváltó ok azonosításához használják fel.

5. lépés: Eredmények elemzése (amit a rendszer módosítása követ)

A forgatókönyv-végrehajtás során a LoadRunner rögzíti az alkalmazás teljesítményét különböző terhelések alatt. A teszt végrehajtásából levont statisztikák mentésre kerülnek, és részletes elemzést végeznek. A „HP Analysis” eszköz különféle grafikonokat generál, amelyek segítenek azonosítani a rendszerteljesítmény elmaradása, valamint a rendszerhibák mögött meghúzódó kiváltó okokat.

Néhány kapott grafikon a következőket tartalmazza:

• Ideje az első pufferhez
• Tranzakció válaszidő
• Átlagos tranzakciós válaszidő
• Találatok másodpercenként
• Windows Tudástár
• Hibastatisztika
• Tranzakciók összefoglalója

FAQ