Mi az a HP LoadRunner tesztelő eszköz? Építészet, alkatrészek

Mi az a LoadRunner?

A LoadRunner egy teljesítménytesztelő eszköz, amelyet 1999-ben a Mercury vezetett be. A LoadRunner-t később a HPE 2006-ban vásárolta meg. 2016-ban a LoadRunnert a MicroFocus vásárolta meg.

A LoadRunner különféle fejlesztési eszközöket, technológiákat és kommunikációs protokollokat támogat. Valójában ez az egyetlen olyan eszköz a piacon, amely ilyen sok protokollt támogat a teljesítményteszt elvégzéséhez. A LoadRunner szoftver által készített teljesítménytesztek referenciaértékként szolgálnak más eszközökkel szemben

Ebben az oktatóanyagban megtanulja-

• Miért a LoadRunner?
• Miért van szükség a teljesítmény tesztelésére?
• Mi az a LoadRunner architektúra?
• Teljesítménytesztelési ütemterv: Részletes lépések
• GYIK

Miért a LoadRunner?

A LoadRunner nemcsak a teljesítménytesztelés úttörő eszköze, de továbbra is piacvezető a teljesítménytesztelési paradigmában. Egy nemrégiben készült értékelés szerint a LoadRunner körülbelül 85% -os piaci részesedéssel rendelkezik a teljesítménytesztelő iparban.

Általánosságban elmondható, hogy a LoadRunner eszköz támogatja az RIA (Rich Internet Applications), a Web 2.0 (HTTP / HTML, Ajax, Flex és Silverlight stb.), A Mobil, az SAP, az Oracle, az MS SQL Server, a Citrix, az RTE, a Mail és mindenekelőtt a Windows Socket programokat. Nincs olyan versenytárs eszköz a piacon, amely ilyen sokféle protokollt kínálna egyetlen eszközhöz.

A szoftver tesztelésében meggyőzőbb a LoadRunner kiválasztása, az az eszköz hitelessége. A LoadRunner eszköz már régóta hírnevet szerzett, mivel gyakran megtalálja az ügyfeleket, hogy a LoadRunner használatával ellenőrizzék a teljesítményre vonatkozó referenciaértékeket. Megkönnyebbülést talál, ha már a LoadRunner programot használja teljesítményvizsgálati igényeihez.

A LoadRunner szoftver szorosan integrálva van a többi HP eszközzel, például az Egységes funkcionális teszt (QTP) és az ALM (Alkalmazás életciklus-kezelése) segítségével, lehetővé téve a végpontok közötti tesztelési folyamatok végrehajtását.

A LoadRunner a virtuális felhasználók szimulálásának alapelvén dolgozik a tárgyalkalmazásban. Ezeket a virtuális felhasználókat JT-ként is emlegetik, megismétlik az ügyfél kéréseit, és megfelelő választ várnak egy tranzakció átadására.

Miért van szükség a teljesítmény tesztelésére?

A gyenge internetes teljesítmény miatt évente 4,4 milliárd bevétel-veszteséget könyvelnek el.

A Web 2.0 mai korában a felhasználók elkattintanak, ha egy webhely nem reagál 8 másodpercen belül. Képzelje el, hogy 5 másodpercig várakozik, amikor a Google-on keres, vagy barátkérést tesz a Facebookon. A teljesítményleállás következményei gyakran pusztítóbbak, mint azt valaha elképzelték. Van néhány példa, amelyek nemrégiben kerültek a Bank of America Online Banking, az Amazon Web Services, az Intuit vagy a Blackberry oldalra.

A Dunn & Bradstreet adatai szerint a Fortune 500 vállalatok 59% -a minden héten becslések szerint 1,6 óra leállást tapasztal. Figyelembe véve, hogy a legalább 10 000 alkalmazottal rendelkező Fortune 500 átlagos vállalat 56 dollárt fizet óránként, egy ilyen szervezet leállási költségeinek munkaerő-része heti 896 000 dollár lenne, ami évente több mint 46 millió dollárt jelent.

Becslések szerint a Google.com mindössze 5 perces leállása (augusztus 13., 19.) 545 000 dollárba kerül a keresőóriás számára.

Becslések szerint a vállalatok másodpercenként 1100 dollár értékben veszítettek eladásokból az Amazon webszolgáltatásának legutóbbi kiesése miatt.

Ha egy szervezet egy szoftver rendszert telepít, akkor számos olyan forgatókönyvbe ütközhet, amelyek teljesítmény késleltetést eredményezhetnek. Számos tényező okozza a teljesítmény lassulását, néhány példa a következőket tartalmazza:

• Megnövekedett az adatbázisban lévő rekordok száma
• Megnövekedett a rendszerhez intézett egyidejű kérések száma
• a rendszerhez egyszerre több felhasználó jut el, mint a múltban

Mi az a LoadRunner architektúra?

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

Tegyük fel, hogy az Amazon.com teljesítményének ellenőrzésére van kijelölve 5000 felhasználó

Valós életben ezek az 5000 felhasználók nem a honlapon lesznek, hanem a webhelyek egy másik részében. Hogyan szimulálhatunk másképp

VUGen:

A VUGen vagy a Virtual User Generator egy IDE (integrált fejlesztői környezet) vagy gazdag kódolási szerkesztő. A VUGen a rendszer terhelés alatt (SUL) viselkedésének replikálására szolgál. A VUGen egy "felvételi" szolgáltatást kínál, amely az ügyfél és a szerver közötti és az onnan érkező kommunikációt kódolt szkript formájában rögzíti - más néven VUser szkript.

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

1. Szörfözés az Amazon.com termékoldalán
2. Pénztár
3. Fizetés feldolgozása
4. A MyAccount oldal ellenőrzése

Vezérlő

A VUser szkriptjének befejezése után a Vezérlő az egyik fő LoadRunner komponens, amely például a következők kezelésével vezérli a betöltési szimulációt:

• Hány járműegységet kell szimulálni az egyes üzleti folyamatok vagy a felhasználói csoportok alapján
• A JE-k viselkedése (emelkedés, lejtés, egyidejű vagy párhuzamos jelleg stb.)
• A terhelés szcenárió jellege, pl. Valós élet vagy célorientált vagy az SLA ellenőrzése
• Mely injektorokat kell használni, hány járműegységet kell használni az egyes injektorok ellen
• Az eredményeket rendszeresen gyűjtsük össze
• IP hamisítás
• Hiba jelentése
• Tranzakciók jelentése stb.

Ha analógiát veszünk a példa vezérlőnkből, a következő paramétert adjuk hozzá a VUGen szkripthez

1) 3500 felhasználó szörfözik az Amazon.com termékoldalán

2) 750 felhasználó van a Pénztárban

3) 500 felhasználó végez fizetésfeldolgozást

4) 250 felhasználó CSAK azután ellenőrzi a MyAccount oldalt, hogy 500 felhasználó elvégezte a fizetési folyamatot

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

1. 2 másodpercenként indítson el 5 egységet, amíg el nem éri a 3500 egységet (az Amazon termékoldalain szörfözik).
2. 30 percig iterál
3. Felfüggeszti az iterációt 25 JE felhasználó számára
4. Indítsa újra 20 VUSert
5. Másodpercenként indítson 2 felhasználót (a Pénztárban, a Fizetések feldolgozása, Saját számlák oldalon).
6. 2500 járműegységet hoznak létre az A gépen
7. 2500 járműegységet hoznak létre a B gépen

Gép / terhelésgenerátorok / befecskendezők

A HP LoadRunner Controller feladata a JE-k ezreinek szimulálása - ezek a JE-k hardverforrásokat fogyasztanak, például processzort és memóriát -, így korlátot szabnak az őket szimuláló gépnek. Ezenkívül a Controller ezeket a járműegységeket szimulálja ugyanazon a gépen (ahol a Controller lakik), ezért az eredmények nem biztos, hogy pontosak. Ennek a problémának a megoldása érdekében az összes járműegységet elosztják a különböző gépek, úgynevezett terhelésgenerátorok vagy terhelésinjektorok.

Általános gyakorlat, hogy a Vezérlő egy másik gépen tartózkodik, és a terhelést más gépektől szimulálják. A VUser szkriptjeinek protokolljától és a gép specifikációitól függően számos terhelésinjektorra lehet szükség a teljes szimulációhoz. Például egy HTTP szkript VU-felhasználóinak a szimulációhoz VUserenként 2-4 MB-ra lesz szükség, ezért 10 000 VU-felhasználó terhelésének szimulálásához 4 darab 4 GB RAM-mal rendelkező gépre lesz szükség.

Az analógiát Amazon-példánkból kiindulva ennek az összetevőnek a kimenete lesz

Elemzés:

A betöltési forgatókönyvek végrehajtása után bekerül a LoadRunner " Elemzés " komponenseinek szerepe .

A végrehajtás során a Vezérlő nyers formában létrehoz egy kiírást az eredményekről, és olyan információkat tartalmaz, mint például a LoadRunner mely verziója hozta létre ezt az eredményeket és milyen konfigurációk voltak.

Az összes hibát és kivételt naplózza egy Microsoft hozzáférési adatbázis, az output.mdb néven. Az "Elemzés" komponens beolvassa ezt az adatbázisfájlt, hogy különféle típusú elemzéseket hajtson végre, és grafikonokat generál.

Ezek a grafikonok különböző trendeket mutatnak be, hogy megértsék a hibák és a meghibásodás mögött rejlő okokat; így segíthet abban, hogy kiderüljön, szükséges-e optimalizálás a SUL-ban, a Serverben (pl. JBoss, Oracle) vagy az infrastruktúrában.

Az alábbiakban bemutatunk egy példát, ahol a sávszélesség szűk keresztmetszetet hozhat létre. Tegyük fel, hogy a webszerver kapacitása 1 GB / s, míg az adatforgalom meghaladja ezt a kapacitást, ami a későbbi felhasználóknak szenvedést okoz. Az ilyen igényeknek megfelelő rendszer meghatározása érdekében a Performance Engineer-nek elemeznie kell az alkalmazás viselkedését rendellenes terhelés mellett. Az alábbiakban látható egy grafikon, amelyet a LoadRunner generál a sávszélesség előhívásához.

Teljesítménytesztelési ütemterv: Részletes lépések

A teljesítménytesztelési ütemtervet nagyjából 5 lépésben lehet felosztani:

• Terhelési teszt tervezése
• Hozzon létre VUGen parancsfájlokat
• Forgatókönyv készítése
• Forgatókönyv végrehajtása
• Eredmények elemzése (majd a rendszer módosítása)

Most, hogy telepítette a LoadRunner programot, értsük meg egyesével a folyamat lépéseit.

A teljesítmény-tesztelési folyamat részei

A terhelési teszt megtervezése

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

Állítsd össze a csapatodat

A LoadRunner Testing használatának megkezdése során a legjobb dokumentálni, hogy kik vesznek részt a tevékenységben a folyamat során részt vevő minden csapattól.

Projekt menedzser:

Jelölje ki a projektmenedzsert, aki ennek a tevékenységnek a tulajdonosa lesz, és az eszkaláció fő személyeként szolgál.

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

Biztosítsa a SUL felhasználási elemzését és szakértelmet nyújt a weboldal / SUL üzleti funkcionalitásával kapcsolatban

Teljesítménytesztelő szakértő:

Létrehozza az automatizált teljesítményteszteket és végrehajtja a terhelési forgatókönyveket

Rendszerépítész:

Biztosítja a SUL tervrajzát

Webfejlesztő és kkv:

• Webhely fenntartása és felügyeleti szempontok biztosítása
• Webhelyet fejleszt és javítja a hibákat

Rendszergazda:

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

Az érintett alkalmazások és üzleti folyamatok felvázolása:

A sikeres terheléses teszteléshez megköveteli, hogy bizonyos üzleti folyamatokat hajtson végre. Az üzleti folyamat világosan meghatározott lépésekből áll a kívánt üzleti tranzakcióknak megfelelően - a terhelés-tesztelési célok elérése érdekében.

A követelmények metrikája elkészíthető a felhasználó terhelésének kiváltására a rendszeren. Az alábbiakban bemutatunk egy példát a társaság részvételi rendszerére:

A fenti példában az ábrák megemlítik az alkalmazáshoz (SUL) csatlakoztatott felhasználók számát az adott órában. Kihozhatjuk az üzleti folyamathoz kapcsolódó felhasználók maximális számát a nap bármely órájában, amelyet a jobb szélső oszlopokban számolunk.

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

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

Határozza meg a tesztadat-kezelési eljárásokat

A teljesítményteszt statisztikáit és megfigyeléseit számos tényező nagyban befolyásolja, amint azt korábban ismertettük. Kritikus jelentőségű a tesztadatok elkészítése a teljesítményteszteléshez. Előfordul, hogy egy adott üzleti folyamat elfogyaszt egy adatkészletet, és más adatkészletet állít elő. Vegyük az alábbi példát:

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

Ebben a helyzetben a B felhasználónak 200 szerződést kell „létrehoznia” a rendszerben. Ezenkívül a C felhasználónak 150 szerződésre van szüksége "jóváhagyottként", hogy 150 felhasználó terhelését szimulálja.

Ez hallgatólagosan 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, amelyek a C felhasználó tesztadataként szolgálnak - a fennmaradó 200 szerződés a B felhasználó tesztadataként szolgál.

Vázlatos monitorok

Gondoljon minden olyan tényezőre, amely befolyásolhatja a rendszer teljesítményét. Például a csökkentett hardver hatással lehet a SUL (System Under Load) teljesítményre.

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

• Processzor (webkiszolgálóhoz, alkalmazáskiszolgálóhoz, adatbázis-kiszolgálóhoz és injektorokhoz)
• RAM (webkiszolgálóhoz, alkalmazáskiszolgálóhoz, adatbázis-kiszolgálóhoz és injektorokhoz)
• Web- / alkalmazásszerver (például IIS, JBoss, Jaguar Server, Tomcat stb.)
• DB Server (PGA és SGA méret Oracle és MSSQL Server, SP-k stb. Esetén)
• Hálózati sávszélesség kihasználtság
• Belső és külső hálózati kártya klaszterezés esetén
• Terheléselosztó (és egyenletesen osztja el a terhelést a fürtök minden csomópontján)
• Adatáramlás (kiszámítja, hogy mennyi adat mozog az ügyfél és a kiszolgáló között, majd számolja ki, hogy elegendő-e a hálózati kártya kapacitása az X felhasználók számának szimulálásához)

Hozzon létre VUGen parancsfájlokat

A tervezés után a következő lépés a VUser parancsfájlok létrehozása.

Forgatókönyv készítése

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

Forgatókönyv végrehajtása

A forgatókönyv végrehajtása során a felhasználó terhelését utánozza a kiszolgálón azzal, hogy több járműegységet utasít fel a feladatok egyidejű végrehajtására.

A terhelés szintjét úgy állíthatja be, hogy növeli és csökkenti a feladatokat egyidejűleg végrehajtó JE-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énytesztelés célja. A kapott eredményeket ezután felhasználják a részletes elemzéshez és a kiváltó okok azonosításához.

Eredmények elemzése (majd a rendszer módosítása)

A forgatókönyv végrehajtása 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 származó statisztikákat elmentjük és a részletek elemzését elvégezzük. A „HP Analysis” eszköz különféle grafikonokat állít elő, amelyek segítenek azonosítani a rendszer teljesítményének lemaradásának és a rendszerhibának a kiváltó okait.

A kapott grafikonok egy része a következőket tartalmazza:

• Idő az első pufferig
• Tranzakció válaszideje
• Átlagos tranzakciós válaszidő
• Találatok másodpercenként
• Windows erőforrások
• Hibák statisztikája
• Tranzakciók összefoglalása

GYIK

Melyik alkalmazást teszteljük?

A teljesítménytesztet mindig csak kliens-szerver alapú rendszereknél végzik. Ez azt jelenti, hogy minden olyan alkalmazásnak, amely nem kliens-szerver alapú architektúra, nem szükséges a teljesítmény tesztelése.

Például a Microsoft Calculator nem kliens-szerver alapú, és több felhasználót sem futtat; ennélfogva nem pályázik a teljesítménytesztekre.

Mi a különbség a teljesítménytesztelés és a teljesítménytechnika között

Fontos megérteni a teljesítménytesztelés és a teljesítménytechnika közötti különbséget. Az alábbiakban egyetértés van:

A teljesítménytesztelés egy olyan tudományág, amely egy szoftveralkalmazás aktuális teljesítményének tesztelésével és jelentésével foglalkozik különböző paraméterek mellett.

A teljesítménytechnika az a folyamat, amelynek során a szoftvereket tesztelik és hangolják a kívánt teljesítmény megvalósítása céljából. Ennek a folyamatnak a célja az alkalmazás legfontosabb jellemzőinek, azaz a felhasználói élmény optimalizálása.

Történelmileg a tesztelés és a hangolás egyértelműen elkülönült és gyakran egymással versengő területek voltak. Az elmúlt években azonban számos tesztelő és fejlesztő zsebében függetlenül működött együtt tuningcsapatok létrehozása. Mivel ezek a csapatok jelentős sikereket értek el, a teljesítménytesztelés és a teljesítményhangolás összekapcsolásának koncepciója ragadt magára, és most teljesítménytechnikának hívjuk.