LoadRunner tesztelő eszköz: Archiszerkezeti ábra és alkatrészek

Mi az a LoadRunner?

A LoadRunner egy Teljesítményfelmérés eszköz, amelyet úttörőként fejlesztett ki Mercury Interactive 1999-ben. A LoadRunnert később, 2006-ban felvásárolta a HP, a HP szoftverüzletág pedig egy 2016-ban bejelentett és 2017-ben lezárult üzlet keretében egyesült a Micro Focusszal.

Márka megjegyzés: OpenText 2023 januárjában befejezte a Micro Focus felvásárlásátA szerszámot már nem HP vagy más néven árulják. Micro Focus LoadRunnerA LoadRunner Professional mostantól elérhető OpenText Professzionális teljesítménymérnöki szolgáltatás, a LoadRunner Enterprise OpenText Vállalati teljesítménymérnökség és a LoadRunner Cloud OpenText Core Performance Engineering. Az alábbi komponensnevek – VuGen, Controller, load generators és Analysis – változatlanok.

A LoadRunner különféle fejlesztőeszközöket, technológiákat és kommunikációs protokollokat támogat. A piacon elérhető egyik legszélesebb körű protokollkönyvtárat tartalmazza teljesítménytesztelés elvégzéséhez. A LoadRunner szoftver által előállított teljesítményteszt-eredményeket más eszközökkel szembeni összehasonlításra használják.

LoadRunner videó

Mielőtt a komponensekkel foglalkoznánk, nézze meg az alábbi videót a LoadRunner gyors bemutatásához.

Miért a LoadRunner?

A LoadRunner nemcsak úttörő eszköz a teljesítménytesztelésben, hanem továbbra is az egyik piacvezető a teljesítménytesztelési paradigmában, és még mindig számos vállalat viszonyítási pontja.

A protokoll lefedettsége a legegyértelműbb ok, amiért a csapatok ezt választják, ahogy az alábbi komponenstérkép is mutatja.

Á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 Socket. Kevés versengő eszköz kínál ilyen széleskörű protokollválasztékot egyetlen eszközben, ahogy azt az alábbi protokolllista is mutatja.

Ami még meggyőzőbb a LoadRunner mellett a szoftvertesztelésben, az az eszköz hitelessége. A LoadRunner eszköz régóta hírnevet szerzett magának, mivel gyakran találkozhatunk azzal, hogy az ügyfelek kereszt-ellenőrzik a teljesítmény-referenciaértékeinket a LoadRunner segítségével. Megkönnyebbülést tapasztalhatunk, ha már használjuk a LoadRunnert teljesítménytesztelési igényeinkre.

A LoadRunner szoftver szorosan integrálva van a csomagban található testvéreszközökkel – az Unified Functional Testinggel (az előbbivel). QTP, most úgy eladó, mint OpenText Funkcionális tesztelés) és ALM (alkalmazáséletciklus-kezelés, most OpenText ALM/Minőségügyi Központ) – amely felhatalmazza Önt a teljes körű tesztelési folyamatok elvégzésére.

A LoadRunner a virtuális felhasználók szimulációjának elvén működik az adott alkalmazáson. Ezek a virtuális felhasználók, más néven VUser-ek, replikálják a kliens kéréseit, és a tranzakció továbbításához megfelelő választ várnak.

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

Az alábbi iparági becslések széles körben idézettek és a 2010-es évek elejéről származnak, de az általuk leírt minta nem változott: a lassú oldalak pénzbe kerülnek.

A gyenge webes teljesítmény miatt évente becslések szerint 4.4 milliárd dolláros bevételkiesést könyvelnek el.

A mai Web 2.0 korában a felhasználók elkattintanak, ha egy weboldal 8 másodpercen belül nem válaszol. Képzelje el, hogy 5 másodpercig vár keresés közben Google vagy ismerősnek jelölés küldése a Facebookon. A teljesítménykiesés következményei gyakran pusztítóbbak, mint azt valaha is gondoltuk volna. Vannak közismert példák, mint például a Bank of America online banki szolgáltatásait sújtó esetek, Amazon Webszolgáltatások, Intuit és Blackberry.

A Dun & Bradstreet szerint a Fortune 500-as vállalatok 59%-a becslések szerint heti 1.6 óra leállást tapasztal. Tekintettel arra, hogy egy átlagos Fortune 500-as vállalat, amely legalább 10 000 alkalmazottat foglalkoztat, óránként 56 dollárt fizet, egy ilyen szervezet leállási költségeinek munkadíjas része hetente 896 000 dollár lenne, ami évi több mint 46 millió dollárt jelent.

Csak 5 perc leállási idő GoogleA .com 2013 augusztusában a becslések szerint akár 545 000 dollárjába is kerülhetett a keresőóriásnak.

Becslések szerint a vállalatok másodpercenként 1,100 dollár értékű árbevétel-csökkenést könyvelhettek el az elmúlt években. Amazon Webszolgáltatások kimaradása.

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
• Nagyobb számú felhasználó fér hozzá egyszerre a rendszerhez, mint korábban

Nem minden pályázat minősül azonban jelöltnek. Terhelésvizsgálat kliens-szerver, többfelhasználós rendszereket céloz meg, így egy olyan egyfelhasználós asztali segédprogramot, mint az alább látható, nem érdemes teljesítmény szempontjából tesztelni.

Mi az a LoadRunner Architectúra?

Általánosságban elmondható, hogy a LoadRunner architektúrája összetett, mégis könnyen érthető. Az alábbi LoadRunner architektúradiagram bemutatja, hogyan működik együtt a négy komponens.

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.

Egy valós helyzetben ez az 5000 felhasználó nem a kezdőlapon fog ülni, hanem a weboldal különböző részein lesznek elszórva. Szóval hogyan szimuláljuk ezt a különbséget?

VuGen

VuGen vagy virtuális felhasználó Generator egy IDE (Integrated Development Environment), vagyis egy gazdag kódolású szerkesztő. A VuGen a rendszer terhelés alatti (SUL) viselkedésének reprodukálására szolgál. A VuGen egy „felvétel” funkciót biztosít, amely kódolt szkript formájában rögzíti a kliens és a szerver közötti kommunikációt – más néven VUser szkript.

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ítéssel:

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

Miután a szkript tisztán lejátszódik, a dinamikus szerverértékeket általában rögzíteni kell a következővel: korreláció mielőtt felskálázható lenne.

ellenőr

Miután egy VUser szkript véglegesítve lett, a ellenőr az egyik fő LoadRunner komponens, amely a terhelésszimulációt vezérli, például a következők kezelésével:

• 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éldánkból vett analógiát követve, a vezérlő a következő paramétereket adja hozzá a VuGen szkripthez:

1. 3500 felhasználó böngészi a termékoldalt Amazon.com
2. 750 felhasználó van a pénztárnál
3. 500 felhasználó végez fizetésfeldolgozást
4. 250 felhasználó csak azután ellenőrzi a Saját fiók oldalt, hogy 500 felhasználó már elvégezte a fizetés feldolgozását.

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

• 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.
• Ismételje 30 percig
• Az iteráció felfüggesztése 25 VU-felhasználó esetén
• 20 VUser újraindítása
• Másodpercenként 2 felhasználó kezdeményezése (a Fizetés, Fizetésfeldolgozás, Saját fiókok oldalon).
• 2500 VU-felhasználót állítanak elő az A gépen
• 2500 VU-felhasználót állítanak elő a B gépen

Agents Machine/Load Generators/Injektorok

A LoadRunner vezérlő több ezer VUser szimulációjáért felelős – ezek a VUserek hardver erőforrásokat fogyasztanak, például processzort és memóriát –, ezáltal korlátozva a szimuláló gép kapacitását. Ezenkívül a vezérlő ugyanarról a gépről szimulálja ezeket a VUsereket (ahol a vezérlő található), ezért az eredmények nem biztos, hogy pontosak. Ennek a problémának a megoldása érdekében az összes VUser különböző gépeken van szétosztva, ezeket LoadRunner-nek nevezik. 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.

A miénkből vett analógiát követve Amazon Például ennek a komponensnek a kimenete az 5000 VUser, két injektor között elosztva: 2500 VUser generálva az A gépen és 2500 a B gépen.

Elemzés

Miután a betöltési forgatókönyvek végrehajtásra kerültek, a szerepe a Elemzés A LoadRunner összetevője jön be.

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 output.mdb nevű Access adatbázis. Az Analysis komponens ezt az adatbázisfájlt olvassa be különféle elemzések elvégzéséhez és grafikonok generálásához.

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ábbi példa arra mutat be egy példát, ahol a sávszélesség szűk keresztmetszetet okozhat. Tegyük fel, hogy a webszerver kapacitása 1 GB/s, míg az adatforgalom meghaladja ezt a kapacitást, ami a további felhasználókat érinti. Annak megállapításához, hogy a rendszer megfelel-e ezeknek az igényeknek, a teljesítménymérnöknek elemeznie kell az alkalmazás viselkedését abnormális terhelés mellett. Az alábbi grafikon a LoadRunner által generált sávszélesség-lekérdezést mutatja.

Hogyan végezzünk teljesítménytesztet

A teljesítménytesztelési ütemterv nagyjából 5 lépésre osztható, amelyeket az alábbi ütemterv foglal össze:

1. Terhelési teszt tervezése
2. VuGen szkriptek létrehozása
3. Forgatókönyv létrehozása
4. Forgatókönyv végrehajtása
5. Eredmények elemzése (amit a rendszer módosítása követ)

A LoadRunner telepítésével nézzük meg a folyamat lépéseit egyenként.

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 elkezdésekor a legjobb dokumentálni, hogy az egyes csapatokból kik vesznek részt a tevékenységben, ahogy az alábbi csapatdiagram is mutatja.

• 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ő: Használati elemzést nyújt a SUL-ról, valamint szakértői véleményt nyújt a weboldal vagy a SUL üzleti funkcionalitásáról.
• Teljesítményvizsgálati szakértő: Létrehozza az automatizált teljesítményteszteket és végrehajtja a terhelési forgatókönyveket.
• rendszer Architect: Biztosítja a SUL tervrajzát.
• Webfejlesztő és kkv: Karbantartja a weboldalt, felügyeli a működést, fejleszti a weboldalt és kijavítja a hibákat.
• Rendszergazda: Karbantartja az érintett szervereket egy tesztelési projekt során.

Vázlatos alkalmazási és üzleti folyamatok

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 adatok az alkalmazáshoz (SUL) egy adott órában csatlakoztatott felhasználók számát mutatják. Ki tudjuk mutatnitract a nap bármely órájában egy üzleti folyamathoz csatlakoztatott felhasználók maximális száma, amelyet a jobb szélső oszlopokban számítanak ki.

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 problémát hoz létre.tract és benyújtja felülvizsgálatra.
• Egy másik felhasználó, 'B', jóváhagy 200 con-ttrac'A' felhasználó által létrehozott napok
• Egy másik felhasználó, 'C', körülbelül 150 fontot fizet.trac'B' felhasználó által jóváhagyott nap

Ebben a helyzetben a B felhasználónak 200 kon-nal kell rendelkeznie.tracts 'létrehozva' a rendszerben. Ezenkívül a C felhasználónak 150 conra van szükségetracts „jóváhagyottként” van nyilvánítva, hogy 150 felhasználó terhelését szimulálja.

Ez implicit módon azt jelenti, hogy legalább 200+150 = 350 kon-t kell létrehoznod.tracts.

Ezt követően hagyja jóvá a 150 kon.tracC felhasználó tesztadataiként szolgáló elemek – a fennmaradó 200tracA ts tesztadatként szolgál majd a B felhasználó számára.

Outline monitorok

Gondoljon végig minden egyes tényezőt, amely befolyásolhatja a rendszer teljesítményét. Például a csökkent hardverszám befolyásolhatja a SUL (rendszer terhelés alatt) teljesítményét.

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)
• dátum flux (számítsa ki, hogy mennyi adat áramlik a kliens és a szerver között, majd számítsa ki, hogy egy hálózati kártya kapacitása elegendő-e X számú felhasználó szimulálásához)

2. lépés) VuGen szkriptek létrehozása

A tervezés utáni következő lépés a VUser szkriptek létrehozása, hozzáadva a következőket: paraméterezés, tranzakciók és futásidejű beállítások ahogy a forgatókönyv érlelődik.

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

A következő lépés a terhelési forgatókönyv létrehozása a vezérlőben, manuális és célorientált forgatókönyv közül választva.

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 a szerver leállását okozhatja. feszültség és rendellenesen viselkednek. Ez a teljesítménytesztelés igazi célja. Az eredményeket ezután részletes elemzésre és a kiváltó ok azonosítására 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ása során a LoadRunner rögzíti az alkalmazás teljesítményét különböző terhelések alatt. A tesztvégrehajtásból származó statisztikákat menti a rendszer, és részletes elemzést végez. Az elemző eszköz (azokban a kiadásokban, amelyek alapján ezt a bemutatót írtuk, „HP Analysis” márkanév alatt ismert) különféle grafikonokat generál, amelyek segítenek azonosítani a rendszerteljesítmény-lassulás, valamint a rendszerhibák mögött meghúzódó 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

GYIK