A rögzített szkript képes szimulálni egy virtuális felhasználót; a puszta felvétel azonban nem elegendő a „valódi felhasználói viselkedés” megismétléséhez.
Ha egy szkriptet rögzítenek, az a téma alkalmazásának egyetlen és egyenes folyamatát fedi le. Míg a valódi felhasználó bármelyik folyamat többszörös iterációját elvégezheti, mielőtt kijelentkezne. A gombok (gondolkodási idő) közötti kattintás késése személyenként változik. Előfordulhat, hogy egyes valódi felhasználók DSL-en, mások pedig betárcsázós kapcsolaton keresztül férnek hozzá az alkalmazásához. Tehát a végfelhasználó valódi érzésének megszerzése érdekében javítanunk kell a szkriptjeinket, hogy pontos egyezésűek legyenek, vagy legalábbis nagyon közel álljanak a valódi felhasználókhoz.
A fentiek a legfontosabb szempontok a „Teljesítmény-tesztelés” során, de a JE-szkriptekről van még szó. Hogyan fogja felmérni azt a pontos időt, amelyet egy JE-felhasználó vesz igénybe, amikor a SUL teljesítményteszten megy keresztül? Honnan tudhatná, hogy a JE felhasználó átment-e vagy meghibásodott egy bizonyos ponton? Mi okozza a hibát, függetlenül attól, hogy valamilyen háttérprogram kudarcot vallott, vagy a szerver erőforrásai korlátozottak voltak?
Fejlesztenünk kell a szkriptünket, hogy segítsünk megválaszolni az összes fenti kérdést.
- Tranzakciók használata
- A gondolkodási idő megértése, Rendezvous pontok és megjegyzések
- Funkciók beszúrása a menüben
- Mi a paraméterezés?
- A futási idő beállításai és azok hatása a JE szimulációjára
- Run Logic
- Tempó
- Napló
- Think Times
- Sebesség szimuláció
- Böngésző emuláció
- Meghatalmazott
Tranzakciók használata
A tranzakciók mechanikák a szerver válaszidejének mérésére bármely művelethez. Egyszerű szavakkal, a „Tranzakció” használata segít megmérni a rendszer által az adott kérésre fordított időt. Lehet olyan kicsi, mint egy gombnyomás vagy egy AJAX-hívás, ha elveszíti a fókuszt a szövegmezőből.
A tranzakciók alkalmazása egyszerű. Csak írjon be egy sort a kódról, mielőtt kérést küldene a szervernek, és zárja le a tranzakciót, amikor a kérelem véget ér. A LoadRunner csak karakterláncot igényel tranzakciónévként.
Tranzakció megnyitásához használja ezt a kódsort:
lr_start_transaction („Tranzakció neve”);
A tranzakció lezárásához használja ezt a kódsort:
lr_end_transaction („Tranzakció neve”, <állapot>);
A
- LR_AUTO
- LR_PASS
- LR_FAIL
Példa:
lr_end_transaction („Saját_ bejelentkezés”, LR_AUTO);
lr_end_transaction („Business_Workflow_Transaction Name”, LR_FAIL);
Megjegyzendő megjegyzések:
- Ne felejtsd el, hogy a „C” betűvel dolgozol, és ez a kis- és nagybetűket figyelembe vevő nyelv.
- Periódus (.) Karakter nem engedélyezett a tranzakció nevében, bár használhat szóközt és aláhúzást.
- Ha jól elágazott a kódja, és ellenőrző pontokat adott hozzá a szerver válaszának ellenőrzéséhez, használhat egyedi hibakezelést, például LR_PASS vagy LR_FAIL. Ellenkező esetben használhatja az LR_AUTO-t, és a LoadRunner automatikusan kezeli a szerver hibákat (HTTP 500, 400 stb.)
- Tranzakciók alkalmazásakor győződjön meg arról, hogy nincs megadva a think_time utasítás, különben a tranzakció mindig tartalmazza ezt az időszakot.
- Mivel a LoadRunner állandó karakterláncot igényel tranzakciónévként, a tranzakció alkalmazásakor gyakori probléma a karakterlánc eltérése. Ha egy tranzakció nyitásakor és lezárásakor más nevet ad meg, akkor legalább 2 hibát fog tapasztalni. Mivel a megnyitott tranzakciót soha nem zárták le, a LoadRunner hibát eredményez. Ezenkívül a lezárni kívánt tranzakciót soha nem nyitották meg, ezért hibát eredményezett.
- Használhatja intelligenciáját és megválaszolhatja magában, hogy a fenti hibák közül melyiket jelentik először? A válasz igazolásához miért ne követné el saját hibáját? Ha jól válaszoltál, jó úton jársz. Ha rosszul válaszolt, akkor összpontosítania kell.
- Mivel a LoadRunner automatikusan gondoskodik a kérések és válaszok szinkronizálásáról, a tranzakciók alkalmazásakor nem kell aggódnia a válasz miatt.
A gondolkodási idő megértése, Rendezvous pontok és megjegyzések
Rendezvous pontok
A Rendezvous Pontok „találkozási pontokat” jelentenek. Csak egy állítássor mondja a LoadRunnert, hogy vezesse be az egyidejűséget. Helyezzen el randevúpontokat a VUser szkriptjeibe, hogy utánozza a kiszolgálón a felhasználók nagy terhelését.
A Rendezvous pontok arra utasítják a VUsert, hogy a teszt végrehajtása során várja meg, amíg több VUser megérkezik egy adott pontra, hogy ezzel egyidejűleg végezhessenek egy feladatot. Például a bankkiszolgáló csúcsterhelésének utánzásához beilleszthet egy találkozási pontot, amely utasítja a 100 VUsert, hogy egyszerre készpénzt helyezzen el számlájára. Ez könnyen elérhető a randevú segítségével.
Ha a találkozási pontok nem megfelelő helyen vannak, akkor a JE-felhasználó hozzáférni fog az alkalmazás különböző részeihez - még ugyanazon szkript esetében is. Ez azért van, mert minden JE felhasználónak eltérő a válaszideje, ezért kevés felhasználó marad el.
Szintaxis: lr_rendesvous („Logikai név”);
Legjobb gyakorlatok:
- A találkozási pont előtagja az „rdv_” szóval a jobb olvashatóság érdekében; pl. „rdv_Login”
- Távolítsa el az azonnali gondolkodási idő kimutatásokat
- Találkozási pontok alkalmazása szkript nézetben (felvétel után)
Hozzászólások
Adjon megjegyzéseket egy tevékenység, egy darab kód vagy egy kódsor leírására. A megjegyzések segítenek megérteni a kódot a jövőben bárki számára, aki hivatkozik rá. Információt nyújtanak a konkrét műveletekről, és két külön szakaszt különítenek el a megkülönböztetéshez.
Megjegyzéseket fűzhet hozzá
- Felvétel közben (eszközzel)
- Felvétel után (közvetlenül kódba írva)
Legjobb gyakorlat: Jelölje meg a megjegyzéseket az egyes szkriptfájlok tetején
Funkciók beszúrása a menüben
Bár közvetlenül írhat egyszerű kódsorokat, szükség lehet egy nyomra a függvény előhívásához. Használhatja a Steps Toolbox-ot is (a 12. verzió előtti Funkció beillesztése néven), hogy bármilyen funkciót megtaláljon és közvetlenül beillesszen a szkriptbe.
A Lépések eszköztár a Steps Eszköztár nézet alatt található.
Ez megnyit egy oldalsó ablakot, és nézze meg a pillanatképet:
Mi a paraméterezés?
A VUGen paramétere egy olyan tároló, amely rögzített értéket tartalmaz, amelyet a különböző felhasználók kicserélnek.
A szkript végrehajtása során (VUGen vagy Controller alkalmazásban) 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 hasznos például dinamikus (vagy egyedi) értékek elküldésében a szerverre; üzleti folyamat kívánatos 10 iteráció futtatásához, de minden alkalommal egyedi felhasználónév kiválasztásával.
Segít a valós rendszerű viselkedés serkentésében is az alanyi rendszerben. Vessen egy pillantást az alábbi példára:
Problémapéldák:
Az üzleti folyamat csak az aktuális dátumig működik, amely a szervertől származik, ezért nem lehet hardverkódolt kérésként továbbítani.
Előfordul, hogy az ügyfélalkalmazás egyedi azonosítót ad át a szervernek (például session_id) a folyamat folytatásához (akár egyetlen felhasználó esetében is) - Ilyen esetben a paraméterezés segít.
Gyakran az ügyfélalkalmazás fenntartja a kiszolgálóra és a szerverről küldött adatok gyorsítótárát. Ennek eredményeként a szerver nem kap valós felhasználói magatartást (ha a szerver a keresési feltételektől függően különböző algoritmusokat futtat). Míg a VUser szkript sikeresen fog futni, a rajzolt teljesítménystatisztikák nem lesznek értelmesek. Különböző adatok paraméterezéssel történő felhasználása elősegíti a kiszolgáló oldali tevékenységek (eljárások stb.) Emulálását és a rendszer gyakorlását.
Az a dátum, amelyet a VUser rögzített a felvétel során, lehet, hogy már nem érvényes, ha ez a dátum letelt. A dátum paraméterezése lehetővé teszi a VUser végrehajtásának sikerét a kemény kódolású dátum cseréjével. Az ilyen mezők vagy kérések a megfelelő jelöltek a paraméterezéshez.
Kattintson ide, ha a videó nem érhető el
A 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 szkript. Különböző konfigurációkkal különböző tesztterveket kaphat. Éppen ezért nem megismételhető eredményekbe kerülhet, ha a Futási idő beállításai nem következetesek. Beszéljük meg az egyes tulajdonságokat egyenként.
Run Logic
A Run Logic meghatározza az összes művelet végrehajtásának számát, a vuser_init és a vuser_end kivételével.
Valószínűleg ez egyértelműbbé teszi, hogy a LoadRunner miért javasolja az összes bejelentkezési kód megtartását a vuser_init és a Logout részeket a vuser_end fájlban, mindkettőt kizárólag.
Ha több műveletet hozott létre, tegyük fel, hogy Bejelentkezés, Képernyő megnyitása, Bérleti díj kiszámítása, Alapok beküldése, Egyenleg ellenőrzése és kijelentkezés, akkor az alábbi forgatókönyv minden egyes felhasználóra megtörténik:
Minden JE felhasználó bejelentkezik, végrehajtja a Nyitott képernyőt, a Bérleti díj kiszámítását, az Alapok benyújtását, Az egyenleg ellenőrzése - majd - ismét Megnyitás képernyő, A bérleti díjak kiszámítása ... és így tovább - 10-szeres ismétlés - majd kijelentkezés (egyszer).
Ez egy erőteljes beállítás, amely lehetővé teszi, hogy úgy viselkedjen, mint egy igazi felhasználó. Ne feledje, hogy egy igazi felhasználó nem minden alkalommal jelentkezik be és nem jelentkezik ki - általában ugyanazokat a lépéseket ismételgeti.
Hányszor kattint az „inbox” gombra, amikor kijelentkezik, mielőtt kijelentkezik?
Tempó
Ez fontos. Az emberek többnyire nem képesek megérteni a tempó és a gondolkodási idő különbségét. Az egyetlen különbség az, hogy „az ingerlés az iterációk közötti késleltetésre utal”, míg a gondolkodási idő bármely 2 lépés közötti késleltetés.
Az ajánlott beállítás a teszt kialakításától függ. Ha azonban agresszív terhelésre vágyik, fontolja meg a „Amint az előző iteráció véget ér” lehetőséget.
Napló
A napló (általában véve) az összes esemény könyvelése a LoadRunner futtatása közben. Engedélyezheti a naplót, hogy megtudja, mi történik az alkalmazás és a szerver között.
A LoadRunner hatékony naplózási mechanizmust biztosít, amely robusztus és önmagában méretezhető. Ez lehetővé teszi, hogy csak a „Normál naplót” vagy egy részletes, konfigurálható kiterjesztett naplót tartson, vagy teljesen letiltsa.
A szokásos napló informatív és könnyen érthető. Pontosan annyi tudást tartalmaz, amelyre általában szüksége lesz a VUser parancsfájljainak elhárításához.
Kiterjesztett napló esetén az összes Normál napló információ részhalmaz. Ezenkívül megadhatja a paraméterek helyettesítését. Ez azt mondja a LoadRunner komponensnek, hogy tartalmazzon teljes információt az összes paraméterről (a paraméterezéstől kezdve), beleértve a kéréseket, valamint a válaszadatokat.
Ha tartalmazza a „Szerver által visszaküldött adatok” elemet, akkor a napló hosszúságú lesz. Ez magában foglalja a HTML-ben, a címkékben, az erőforrásokban és az erőforrásokon kívüli információkat, amelyek közvetlenül a naplóban találhatók. Az opció csak akkor jó, ha komoly hibaelhárításra van szüksége. Általában ez a naplófájlt nagyon nagy méretűvé és nem könnyen érthetővé teszi.
Amint már sejteni lehetett, ha az „Előzetes nyomkövetés” lehetőséget választja, a naplófájlja hatalmas lesz. Meg kell próbálni. Észre fogja venni, 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őzetes információ, és hasznos lehet, ha megérti a tárgyalkalmazást, az ügyfél és a szerver közötti kommunikációt az alkalmazás és a hardver között, valamint a protokollszint részleteit. Általában ez az információ lényegében halott, mivel rendkívüli erőfeszítéseket igényel a megértéshez és a hibaelhárításhoz.
Tippek:
- Nem számít, mennyi időt vesz igénybe a VUGen, amikor a napló engedélyezve van, ez nincs hatással a tranzakció válaszidejére. A HP ezt a jelenséget „a legmodernebb technológiának” nevezi.
- Tiltsa le a naplót, ha nem szükséges.
- Tiltsa le a naplót, ha végzett a szkriptekkel. Ha a szkripteket engedélyezi a naplózás, akkor a vezérlő lassabban fog futni és jelenteni fogja a zavaró üzeneteket.
- A napló letiltása növeli a LoadRunner alkalmazásból szimulálható felhasználók maximális számát.
- Fontolja meg az „Üzenet küldése csak hiba esetén” lehetőséget - ez elnémítja a felesleges információs üzeneteket, és csak a hibával kapcsolatos üzeneteket jelenti.
Think Times
A Think szerint az idő egyszerűen két lépés közötti késés.
A Think Time segít megismételni a felhasználói viselkedést, mivel egyetlen valós felhasználó sem használhat semmilyen alkalmazást, például gépet (VUGen). A VUGen automatikusan generálja a gondolkodási időt. Még mindig teljes a kezedben a gondolkodási idő eltávolítása, szorzása vagy ingadozása.
Ha többet szeretne megérteni, például a felhasználó megnyithat egy képernyőt (vagyis egy választ, amelyet egy kérés követ), majd megadhatja felhasználónevet és jelszót, mielőtt beütne az Enter-be. Az alkalmazás következő kiszolgálóval történő interakciója akkor történik, amikor a „Bejelentkezés” gombra kattint. Az az idő, amikor a felhasználó belépett a felhasználónevébe és jelszavába, a Think Time a LoadRunner programban.
Ha az alkalmazás agresszív terhelését szeretné szimulálni, fontolja meg a gondolkodási idő teljes kikapcsolását.
A valós viselkedés szimulálásához azonban beállíthatja a „Felhasználói véletlenszerű gondolkodási idő” beállítást, és a kívánt százalékokat beállíthatja.
Fontolja meg a Gondolkodási idő korlátozása törvényes időszakra való felhasználást. Általában a 30 másodperc elég jó.
Sebesség szimuláció
A sebességszimuláció egyszerűen az egyes kliens gépek sávszélesség-kapacitására utal.
Mivel a JR-ek ezreit szimuláljuk a LoadRunner-en keresztül, elképesztő, hogy a LoadRunner mennyire egyszerűvé tette a sávszélesség / hálózati sebesség szimuláció vezérlését.
Ha Ön ügyfelek 128 Kbps-nál nagyobb sebességgel férnek hozzá az alkalmazásához, innen vezérelheti azt. Szimulálni fogja az „igazi hasonló viselkedést”, amely segíthet a megfelelő teljesítménystatisztikák megszerzésében.
A legjobb ajánlás a Maximális sávszélesség használata beállítása. 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 lehetséges problémáira összpontosít. A tesztet mindig többször futtathatja, hogy különböző körülmények között eltérő viselkedést láthasson.
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és hatókörét. Kiválaszthatja azonban, hogy melyik böngészőt szeretné utánozni.
Tudna válaszolni magának, hogy pontosan mikor számít majd a megfelelő böngésző kiválasztása ebben a konfigurációban?
Akkor használja ezt a konfigurációt, ha Ön egy webalkalmazás-alkalmazás, amely különböző válaszokat ad vissza a különböző böngészők számára. Például különböző képeket és tartalmakat láthat az IE és a Firefox stb.
Egy másik fontos beállítás a böngésző gyorsítótárának szimulálása. Ha fel 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 helyzetet keresi, akkor ez nyilvánvalóan nem szempont.
A nem HTML-erőforrások letöltése lehetővé teszi a LoadRunner számára, hogy letöltsön bármilyen CSS-t, JS-t és más multimédiát. Ezt továbbra is ellenőrizni kell. Ha azonban ezt szeretné kiküszöbölni a teljesítményteszt-tervezéséből, törölheti ezt a jelölést.
Meghatalmazott
A legjobb, ha teljesen eltávolítja a proxyt a tesztkörnyezetéből - ez megbízhatatlanná teszi a teszt eredményeit. Előfordulhat azonban olyan helyzetek, amikor ez elkerülhetetlen. Ilyen helyzetben a LoadRunner megkönnyíti a proxybeállításokat.
A Nincs proxy beállítással fog dolgozni (vagy működnie kell). Az alapértelmezett böngészőből szerezheti be. Ne felejtse el ellenőrizni, hogy melyik böngésző van alapértelmezettként, és milyen proxy konfiguráció van 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 adja meg felhasználónevét és jelszavát a proxy szerveren történő hitelesítéshez. A képernyő bezárásához kattintson az OK gombra.
Gratulálunk. A VUGen parancsfájl konfigurálásával elkészült. Ne felejtse el konfigurálni az összes VUser szkripthez.