Paraméterezés, függvények, tranzakciók a LoadRunnerben

A rögzített szkript képes egy virtuális felhasználót szimulálni; azonban egy puszta felvétel nem biztos, hogy elegendő a „valódi felhasználói viselkedés” megismétléséhez.

Amikor egy forgatókönyvet rögzítenek, az a tárgyalkalmazás egyetlen és egyenes folyamát fedi le. Míg egy valódi felhasználó bármilyen folyamatot többször is végrehajthat, mielőtt kijelentkezik. A gombok kattintása közötti késleltetés (gondolkodási idő) személyenként változik. Valószínű, hogy egyes valódi felhasználók DSL-en keresztül, mások pedig telefonos kapcsolaton keresztül érik el az alkalmazást. Tehát annak érdekében, hogy a végfelhasználó valódi érzését érezzük, javítanunk kell szkriptjeinket, hogy azok pontosan egyezzenek, vagy legalábbis viselkedésükben nagyon közel álljanak a valódi felhasználókhoz.

A fentiek a legfontosabb szempontok a „Teljesítményfelmérés”, de a VU Scriptben több is van. Hogyan fogja felmérni a pontos időt a VUsernek, amikor a SUL teljesítményteszten megy keresztül? Honnan tudhatja, hogy a VUser átment-e vagy meghibásodott-e egy bizonyos ponton? Mi áll a hiba hátterében, hogy valamilyen háttérfolyamat meghiúsult, vagy a szerver erőforrásai korlátozottak voltak?

Javítanunk kell a szkriptünket, hogy segítsen megválaszolni a fenti kérdéseket.

Tranzakciók használata

A tranzakciók olyan mechanizmusok, amelyek mérik a szerver válaszidejét bármely műveletre. Egyszerűen fogalmazva, a „Tranzakció” használata segít mérni, hogy a rendszer mennyi időt vesz igénybe egy adott kérés teljesítéséhez. Olyan kicsi lehet, mint egy gombnyomás vagy egy AJAX-hívás, amikor elveszíti a fókuszt a szövegmezőből.

A tranzakciók alkalmazása egyszerű. Csak írjon egy kódsort, mielőtt a kiszolgálóhoz fordulna, és zárja be a tranzakciót, amikor a kérés véget ér. A LoadRunner csak egy karakterláncot igényel tranzakciónévként.

Tranzakció megnyitásához használja ezt a kódsort:

lr_start_transaction(“Transaction Name”);

A tranzakció lezárásához használja ezt a kódsort:

lr_end_transaction(“Transaction Name”, <status>);

A közli a LoadRunnerrel, hogy az adott tranzakció sikeres volt-e vagy sikertelen. A lehetséges paraméterek a következők lehetnek:

• LR_AUTO
• LR_PASS
• LR_FAIL

Példa:

lr_end_transaction("Saját_Bejelentkezés", LR_AUTO);
lr_end_transaction("001_Opening_Dashboard Name", LR_PASS);
lr_end_transaction(“Üzleti_Munkafolyamat_Tranzakció neve”, LR_FAIL);

Megjegyzendő pontok:

• Ne felejtsd el, hogy „C”-vel dolgozik, és ez egy kis- és nagybetűk megkülönböztetése.
• A pont (.) karakter nem megengedett a tranzakció nevében, bár használhat szóközt és aláhúzást.
• Ha jól elágazta a kódot, és ellenőrző pontokat adott hozzá a szerver válaszának ellenőrzéséhez, használhat egyéni hibakezelést, például LR_PASS vagy LR_FAIL. Ellenkező esetben használhatja az LR_AUTO-t, és a LoadRunner automatikusan kezeli a szerverhibákat (HTTP 500, 400 stb.)
• A tranzakciók alkalmazásakor győződjön meg arról, hogy nincs gondolkodni_idő kivonat szendvics, vagy egyébként a tranzakció mindig tartalmazni fogja ezt az időszakot.
• Mivel a LoadRunner konstans karakterláncot igényel tranzakciónévként, a tranzakció alkalmazása során gyakori probléma a karakterlánc eltérése. Ha más nevet ad meg egy tranzakció nyitásakor és zárásakor, akkor legalább 2 hibát fog jelezni. Mivel a megnyitott tranzakciót soha nem zárták le, a LoadRunner hibát jelez. Ezenkívül a lezárni kívánt tranzakciót soha nem nyitották meg, ami hibát eredményezett.
• Tudja használni intelligenciáját, és meg tudja válaszolni magának, hogy a fenti hibák közül melyiket jelentik először? Válaszának érvényesítéséhez miért nem követi el saját hibáját? Ha helyesen válaszoltál, akkor jó úton haladsz. Ha rosszul válaszolt, koncentrálnia kell.
• Mivel a LoadRunner automatikusan gondoskodik a kérések és válaszok szinkronizálásáról, nem kell aggódnia a válaszadás miatt a tranzakciók alkalmazásakor.

A gondolkodási idő, a találkozási pontok és megjegyzések megértése

Találkozó pontok

A Rendezvous Points jelentése „találkozási pontok”. Ez csak egy sor utasítás, amely arra utasítja a LoadRunnert, hogy vezesse be a párhuzamosságot. Találkozási pontokat illeszt be a VUser parancsfájlokba, hogy emulálja a kiszolgáló nagy felhasználói terhelését.

A találkozási pontok arra utasítják a VUser-t, hogy a tesztvégrehajtás során várja meg, amíg több VUser megérkezik egy bizonyos pontra, hogy egyidejűleg végrehajthassanak egy feladatot. Például a bankszerver csúcsterhelésének emulálásához beilleszthet egy találkozási pontot, amely utasítja a 100 VUser-t, hogy egyidejűleg helyezzen be készpénzt a számlájára. Ez könnyen elérhető a randevúzással.

Ha a találkozási pontok helytelenül vannak elhelyezve, a VUser az alkalmazás különböző részeit fogja elérni – még ugyanazon szkript esetén is. Ennek az az oka, hogy minden VUser eltérő válaszidőt kap, és ezért kevés felhasználó marad le.

Szintaxis: lr_rendesvous("Logikai név");

Legjobb gyakorlatok:

• A találkozási pont elé illessze be az „rdv_”-t a jobb kód olvashatóság érdekében; pl. "rdv_Login"
• Távolítson el minden azonnali gondolkodási időre vonatkozó állítást
• Találkozási pontok alkalmazása forgatókönyv nézetben (rögzítés után)

Hozzászólások

Adjon hozzá megjegyzéseket egy tevékenység, egy kódrészlet vagy egy kódsor leírásához. A megjegyzések segítenek abban, hogy a kód érthető legyen mindenki számára, aki a jövőben hivatkozik rá. Tájékoztatást nyújtanak a konkrét működésről, és két szakaszt különítenek el a megkülönböztetés érdekében.

Hozzáfűzhetsz megjegyzéseket

• Felvétel közben (eszköz használatával)
• Felvétel után (közvetlenül kódba írva)

Bevált gyakorlat: Jelölje meg a megjegyzéseket minden szkriptfájl tetején

Funkciók beillesztése a menüből

Bár közvetlenül írhat egyszerű kódsorokat, szükség lehet egy nyomra egy függvény előhívásához. A Steps Toolbox (a 12-es verzió előtt Függvény beszúrása néven ismert) segítségével bármely függvényt közvetlenül megkereshet és beilleszthet a szkriptbe.

A Steps Toolbar a Lépések eszköztár megtekintése alatt található.

Ez megnyílik egy oldalsó ablak, és nézze meg a pillanatképet:

Mi az a paraméterezés?

A paraméter a VUGenben egy olyan tároló, amely egy rögzített értéket tartalmaz, amelyet különböző felhasználók számára lecserélnek.

A szkript végrehajtása során (VUGenben vagy Controllerben) egy külső forrásból származó érték (például .txt, XML vagy adatbázis) helyettesíti a paraméter előző értékét.

A paraméterezés például akkor hasznos, ha dinamikus (vagy egyedi) értékeket küld a szervernek; egy üzleti folyamatnak 10 iterációt kell futtatnia, de minden alkalommal egyedi felhasználónevet kell kiválasztania.

Segít abban is, hogy az alanyrendszer valódi viselkedését ösztönözze. Vessen egy pillantást az alábbi példára:

Példák a problémákra:

Az üzleti folyamat csak az aktuális dátumhoz működik, amely a szervertől származik, ezért nem adható át hardcoded kérésként.

Néha az ügyfélalkalmazás egyedi azonosítót (például session_id) ad át a szervernek a folyamat folytatása érdekében (még egyetlen felhasználó esetén is) – Ilyen esetben a paraméterezés segít.

Az ügyfélalkalmazás gyakran gyorsítótárat tart fenn a kiszolgálóra küldött és onnan érkező adatokról. Ennek eredményeként a szerver nem kap valódi felhasználói viselkedést (ha a szerver a keresési feltételektől függően eltérő algoritmust futtat). Míg a VUser szkript sikeresen lefut, a lerajzolt teljesítménystatisztikának nincs jelentősége. A különböző adatok paraméterezésen keresztüli felhasználása elősegíti a szerveroldali tevékenységek (eljárások stb.) emulálását és a rendszer gyakorlását.

Előfordulhat, hogy a rögzítés közben a VUserben rögzített dátum már nem érvényes, ha ez a dátum elmúlt. A dátum paraméterezése lehetővé teszi, hogy a VUser végrehajtása sikeres legyen a kódolt dátum lecserélésével. Az ilyen mezők vagy kérések a megfelelő jelöltek a paraméterezéshez.

Kattints itt ha a videó nem érhető el

Futási idő beállításai és azok hatása a JE szimulációjára

A futási idő beállításai ugyanolyan jelentősek, mint a VUGen Script. Különböző konfigurációkkal különböző tesztterveket kaphat. Emiatt előfordulhat, hogy nem megismételhető eredményeket kaphat, ha a futási idő beállításai nem konzisztensek. Beszéljük meg az egyes tulajdonságokat egyenként.

Futtassa a Logic-ot

A Run Logic meghatározza, hogy hányszor kerüljön végrehajtásra az összes művelet, kivéve a vuser_init és vuser_end műveleteket.

Ez valószínűleg világosabbá teszi, hogy a LoadRunner miért javasolja, hogy az összes bejelentkezési kódot a vuser_init-ben és a kijelentkezési részt kizárólag a vuser_end-ben tartsák.

Ha több műveletet hozott létre, például: Bejelentkezés, képernyő megnyitása, bérleti díj kiszámítása, pénzbefizetés, egyenleg ellenőrzése és kijelentkezés, akkor az alábbi forgatókönyv fog megtörténni minden egyes VU-felhasználó esetében:

Minden VU-felhasználó bejelentkezik, végrehajtja a Megnyitás képernyőt, Kiszámolja a Kölcsönzést, Benyújtja az Egyenleget, majd újra Megnyílik a képernyő, Kiszámolja a bérleti díjakat, és így tovább - 10-szer ismételve -, majd kijelentkezést (egyszer).

Ez egy hatékony beállítás, amely lehetővé teszi, hogy valódi felhasználóként viselkedjen. Ne feledje, hogy egy valódi felhasználó nem jelentkezik be és nem jelentkezik ki minden alkalommal – általában ugyanazokat a lépéseket ismétli meg.

Hányszor kattint a „beérkező levelek” elemre, amikor kijelentkezés előtt ellenőrzi e-mailjeit?

ütemezés

Ez fontos. Az emberek többnyire nem képesek megérteni a különbséget az ingerlés és a gondolkodási idő között. Az egyetlen különbség az, „Az ingerlés az iterációk közötti késleltetést jelenti”, míg úgy gondolja, hogy az idő bármely két lépés közötti késés.

A javasolt beállítás a teszt tervétől függ. Ha azonban agresszív terhelést szeretne elérni, fontolja meg a „Amint az előző iteráció véget ér” lehetőséget választja.

Bejelentkezés

A napló (ahogyan általában érthető) az összes esemény könyvelése a LoadRunner futtatása közben. Engedélyezheti a naplózást, hogy megtudja, mi történik az alkalmazás és a szerver között.

A LoadRunner erőteljes naplózási mechanizmust biztosít, amely önmagában is robusztus és méretezhető. Lehetővé teszi, hogy csak a „Standard Log”-t vagy egy részletes, konfigurálható kiterjesztett naplót tartson, vagy teljesen tiltsa le.

A szabványos napló informatív és könnyen érthető. Pont annyi tudást tartalmaz, amelyre általában szüksége lesz a VUser szkriptek hibaelhárításához.

A kiterjesztett napló esetében az összes szabványos naplóinformáció egy részhalmaz. Ezenkívül lehetőség van paramétercserére. Ez arra utasítja a LoadRunner komponenst, hogy tartalmazza az összes paraméter teljes információját (a paraméterezéstől kezdve), beleértve a kéréseket, valamint a válaszadatokat.

Ha megadja a „Szerver által visszaküldött adatok” elemet, akkor a napló hosszabb lesz. Ez magában foglalja a naplóban található összes HTML-t, címkéket, erőforrásokat és nem erőforrásokkal kapcsolatos információkat. Ez az opció csak akkor jó, ha komoly hibaelhárításra van szüksége. Ez általában nagyon nagy méretűvé teszi a naplófájlt, és nem könnyen érthetővé.

Amint azt már sejteni lehetett, ha az „Advance Trace”-t választja, a naplófájlja hatalmas lesz. Ki kell próbálnod. Észreveheti, hogy a VUGen által igénybe vett idő is jelentősen megnőtt, bár ez nem lesz hatással a VUGen által jelentett tranzakciós válaszidőre. Ez azonban nagyon előremutató információ, és hasznos lehet, ha ismeri a tárgyalkalmazást, a kliens-kiszolgáló közötti kommunikációt az alkalmazás és a hardver között, valamint a protokollszintű részleteket. Általában ezek az információk lényegüknél fogva halottak, mivel rendkívüli erőfeszítéseket igényel a megértése és a hibaelhárítás.

Tipp:

• Nem számít, mennyi időt vesz igénybe a VUGen, amikor a napló engedélyezve van, nincs hatással a tranzakció válaszidejére. A HP ezt a jelenséget „korszerű technológiának” nevezi.
• A napló letiltása, ha nem szükséges.
• Ha végzett a szkriptekkel, kapcsolja ki a naplózást. A naplózás engedélyezésével rendelkező szkriptek használata lassabban fog futni a vezérlőn, és jelenteni fogja a zavaró üzeneteket.
• A naplózás letiltása növeli a LoadRunnerből szimulálható felhasználók maximális számának kapacitását.
• Fontolja meg az „Üzenet küldése csak hiba esetén” használatát – ez elnémítja a szükségtelen információs üzeneteket, és csak a hibával kapcsolatos üzeneteket jelenti.

Think Times

Gondolj arra, hogy az idő egyszerűen két lépés közötti késés.

A Think Time segít a felhasználói viselkedés megismétlésében, mivel egyetlen valódi felhasználó sem tud olyan alkalmazást használni, mint egy gép (VUGen). A VUGen automatikusan generál gondolkodási időt. Továbbra is teljes ellenőrzése alatt áll a gondolkodási idő eltávolítása, szaporítása vagy ingadozása.

Ha többet szeretne megtudni, például a felhasználó megnyithat egy képernyőt (ez egy válasz, majd egy kérés), majd megadhatja felhasználónevét és jelszavát, mielőtt lenyomja az entert. Az alkalmazás következő interakciója a szerverrel akkor történik meg, amikor rákattint a „Bejelentkezés” gombra. Az idő, ameddig a felhasználó beírta felhasználónevét és jelszavát, a Think Time a LoadRunnerben.

Ha az alkalmazás agresszív terhelését szeretné szimulálni, fontolja meg a gondolkodási idő teljes letiltását.

Valós hasonló viselkedés szimulálásához azonban használhatja a „Felhasználói véletlenszerű gondolkodási időt” és a kívánt százalékos értékeket.

Fontolja meg a Gondolkodási idő korlátozása törvényes időtartamra használatát. Általában 30 másodperc elég jó.

Sebesség szimuláció

A sebességszimuláció egyszerűen az egyes kliensgépek sávszélesség-kapacitására utal.

Mivel több ezer VUser-t szimulálunk a LoadRunner segítségével, elképesztő, hogy a LoadRunner milyen egyszerűvé tette a sávszélesség/hálózati sebesség szimuláció vezérlését.

Ha Ön ügyfele, 128 Kb/s-nál nagyobb sebességgel éri el alkalmazását, innen vezérelheti azt. Lehetőséged lesz szimulálni a „valódi hasonló viselkedést”, ami segít a megfelelő teljesítménystatisztikában.

A legjobb javaslat a Maximális sávszélesség használata beállítás. Ez segít figyelmen kívül hagyni a hálózattal kapcsolatos teljesítménybeli szűk keresztmetszeteket, és először az alkalmazás esetleges problémáira összpontosít. A tesztet bármikor többször is lefuttathatja, hogy különböző körülmények között eltérő viselkedést lásson.

Böngésző emuláció

A felhasználói élmény nem függ a végfelhasználó által használt böngészőtől. Nyilvánvaló, hogy ez meghaladja a teljesítménymérők körét. Kiválaszthatja azonban, hogy melyik böngészőt szeretné emulálni.

Meg tudja válaszolni magának, hogy pontosan mikor lesz igazán fontos a megfelelő böngésző kiválasztása ebben a konfigurációban?

Ezt a konfigurációt akkor fogja használni, ha a tárgyalkalmazás egy webalkalmazás, amely különböző válaszokat ad vissza a különböző böngészőkhöz. Például különböző képeket és tartalmakat láthat az IE és Firefox stb.

Egy másik fontos beállítás a böngésző gyorsítótárának szimulálása. Ha meg szeretné mérni a válaszidőt, amikor a gyorsítótár engedélyezve van, jelölje be ezt a négyzetet. Ha a legrosszabb esetet keresi, ez nyilvánvalóan nem szempont.

A nem HTML-források letöltésével a LoadRunner letölthet bármilyen CSS-t, JS-t és más multimédiát. Ezt ellenőrizni kell. Ha azonban ezt szeretné kiküszöbölni a teljesítményteszt tervéből, törölje a jelölést.

meghatalmazott

A legjobb, ha teljesen eltávolítja a proxyt Tesztkörnyezet – ez megbízhatatlanná teszi a vizsgálati eredményeket. Előfordulhat azonban olyan helyzetekkel, amikor ez elkerülhetetlen. Ilyen helyzetben a LoadRunner megkönnyíti a proxy beállításait.

Nem proxy beállítással fog dolgozni (vagy dolgoznia kell). Az alapértelmezett böngészőből szerezheti be. Ne felejtse el azonban ellenőrizni, hogy melyik böngésző van alapértelmezettre állítva, és milyen proxykonfiguráció az alapértelmezett böngészőhöz.

Ha proxyt használ, és hitelesítést (vagy szkriptet) igényel, akkor kattintson a Hitelesítés gombra, amely egy új ablakhoz vezet. Lásd az alábbi képernyőképet.

Ezen a képernyőn adhatja meg felhasználónevét és jelszavát a proxyszerveren történő hitelesítéshez. Kattintson az OK gombra a képernyő bezárásához.

Gratulálunk. Elkészült a VUGen szkript konfigurálásával. Ne felejtse el beállítani az összes VUser szkripthez.