Parametrizace, funkce, transakce v LoadRunneru

Obsah:

Anonim

Zaznamenaný skript může simulovat virtuálního uživatele; pouhý záznam však nemusí stačit k replikaci „skutečného chování uživatele“.

Když je skript zaznamenán, pokrývá jediný a přímý tok předmětné aplikace. Skutečný uživatel může před odhlášením provést několik iterací libovolného procesu. Zpoždění mezi klepnutím na tlačítka (doba uvažování) se bude u jednotlivých lidí lišit. Je pravděpodobné, že někteří skuteční uživatelé přistupují k vaší aplikaci přes DSL a někteří k ní prostřednictvím telefonického připojení. Abychom získali skutečný pocit koncového uživatele, musíme vylepšit naše skripty, aby byly přesné shody nebo alespoň velmi blízké chování skutečných uživatelů.

Výše uvedené je nejdůležitějším aspektem při provádění „testování výkonu“, ale skript VU má více. Jak zjistíte přesné množství času, které VUser potřebuje, když SUL prochází testem výkonu? Jak byste věděli, zda VUser prošel nebo selhal v určitém bodě? Jaká je příčina selhání, ať už selhal nějaký proces back-endu nebo byly omezeny prostředky serveru?

Musíme vylepšit náš skript, abychom pomohli odpovědět na všechny výše uvedené otázky.

  • Používání transakcí
  • Pochopení času na přemýšlení, Rendezvous bodů a komentářů
  • Vkládání funkcí prostřednictvím nabídky
  • Co je to parametrizace?
  • Nastavení doby běhu a jejich dopad na simulaci VU
    • Spustit logiku
    • Stimulace
    • Log
  • Mysli na časy
  • Simulace rychlosti
  • Emulace prohlížeče
  • Proxy

Používání transakcí

Transakce jsou mechaniky pro měření doby odezvy serveru pro jakoukoli operaci. Jednoduše řečeno, použití „Transakce“ pomáhá měřit čas, který systém potřebuje pro konkrétní požadavek. Může to být tak malé jako kliknutí na tlačítko nebo volání AJAX po ztrátě pozornosti z textového pole.

Uplatňování transakcí je jednoduché. Stačí napsat jeden řádek kódu před odesláním požadavku na server a uzavřít transakci, když požadavek skončí. LoadRunner vyžaduje jako název transakce pouze řetězec.

Chcete-li otevřít transakci, použijte tento řádek kódu:

lr_start_transaction („Název transakce“);

K uzavření transakce použijte tento řádek kódu:

lr_end_transaction („Název transakce“, );

říká LoadRunner, zda byla tato konkrétní transakce úspěšná nebo neúspěšná. Možné parametry mohou být:

  • LR_AUTO
  • LR_PASS
  • LR_FAIL

Příklad:

lr_end_transaction („My_Login“, LR_AUTO);

lr_end_transaction („001_Opening_Dashboard Name“, LR_PASS);
lr_end_transaction („Business_Workflow_Transaction Name“, LR_FAIL);

Body k poznámce:

  • Nezapomeňte, že pracujete s „C“, což je jazyk, v němž se rozlišují velká a malá písmena.
  • Znak tečky (.) Není v názvu transakce povolen, i když můžete použít mezery a podtržítko.
  • Pokud jste svůj kód dobře rozvětvili a přidali kontrolní body k ověření odpovědi ze serveru, můžete použít vlastní zpracování chyb, například LR_PASS nebo LR_FAIL. Jinak můžete použít LR_AUTO a LoadRunner automaticky zpracuje chybu serveru (HTTP 500, 400 atd.)
  • Při provádění transakcí zajistěte, aby nebyl vložen žádný příkaz think_time, jinak bude vaše transakce vždy zahrnovat toto období.
  • Protože LoadRunner vyžaduje jako název transakce konstantní řetězec, běžným problémem při použití transakce je neshoda řetězce. Pokud při otevírání a zavírání transakce zadáte jiný název, dojde k nejméně 2 chybám. Protože transakce, kterou jste otevřeli, nebyla nikdy uzavřena, LoadRunner přinese chybu. Kromě toho transakce, kterou se pokoušíte uzavřít, nebyla nikdy otevřena, což vedlo k chybě.
  • Můžete použít svoji inteligenci a sami si odpovědět, která z výše uvedených chyb bude nahlášena jako první? Chcete-li ověřit svou odpověď, proč neudělat vlastní chybu? Pokud jste odpověděli správně, jste na správné cestě. Pokud jste odpověděli špatně, musíte se soustředit.
  • Vzhledem k tomu, že se LoadRunner automaticky postará o synchronizaci požadavků a odpovědí, nebudete se při používání transakcí muset starat o reakci.

Pochopení času na přemýšlení, Rendezvous bodů a komentářů

Rendezvous Points

Rendezvous Points znamená „body setkání“. Je to jen jeden řádek prohlášení, který říká LoadRunneru, aby zavedl souběžnost. Vkládáte body setkání do skriptů VUser, abyste emulovali velkou zátěž uživatelů na serveru.

Rendezvous points instruují VUsera, aby počkal během provádění testu, aby více VUser dorazilo do určitého bodu, aby mohli souběžně provést úkol. Například pro emulaci špičkového zatížení na bankovním serveru můžete vložit místo setkání, které dává pokyn 100 VUserovi, aby současně vložil hotovost na své účty. Toho lze snadno dosáhnout pomocí setkání.

Pokud body setkání nejsou místa správně, bude VUser přistupovat k různým částem aplikace - dokonce i pro stejný skript. Je to proto, že každý VUser má jinou dobu odezvy, a proto několik uživatelů zaostává.

Syntaxe: lr_rendesvous („Logický název“);

Osvědčené postupy:

  • Předpona místa setkání s „rdv_“ pro lepší čitelnost kódu; např. „rdv_Login“
  • Odstraňte veškerá okamžitá prohlášení o čase
  • Použití bodů setkání v zobrazení skriptu (po záznamu)

Komentáře

Přidejte komentáře k popisu aktivity, části kódu nebo řádku kódu. Díky komentářům bude kód srozumitelný pro kohokoli, kdo na něj v budoucnu bude odkazovat. Poskytují informace o konkrétní operaci a oddělují dvě části pro rozlišení.

Můžete přidávat komentáře

  • Během nahrávání (pomocí nástroje)
  • Po nahrávání (přímé zapsání kódu)

Osvědčený postup: Označte všechny komentáře v horní části každého souboru skriptu

Vkládání funkcí prostřednictvím nabídky

I když můžete přímo psát jednoduché řádky kódu, možná budete potřebovat vodítko k vyvolání funkce. Můžete také použít nástroj Kroky (známý jako funkce vložení před verzí 12) k vyhledání a vložení jakékoli funkce přímo do skriptu.

Panel nástrojů Kroky najdete v části Pohled à Kroky.

Otevře se boční okno, podívejte se na snímek:

Co je to parametrizace?

Parametr v VUGen je kontejner, který obsahuje zaznamenanou hodnotu, která, se pro různé uživatele.

Během provádění skriptu (ve VUGen nebo Controller) nahradí hodnota z externího zdroje (jako .txt, XML nebo databáze) předchozí hodnotu parametru.

Parametrizace je užitečná například při odesílání dynamických (nebo jedinečných) hodnot na server; obchodní proces vyžaduje spuštění 10 iterací, ale pokaždé výběr jedinečného uživatelského jména.

Pomáhá také stimulovat skutečné chování systému subjektu. Podívejte se na níže uvedený příklad:

Příklady problémů:

Obchodní proces funguje pouze pro aktuální datum, které pochází ze serveru, a proto jej nelze předat jako napevno zadaný požadavek.

Někdy klientská aplikace předá serveru jedinečné ID (například session_id), aby proces mohl pokračovat (i pro jednoho uživatele) - v takovém případě pomáhá parametrizace.

Klientská aplikace často udržuje mezipaměť dat odesílaných na server a ze serveru. Výsledkem je, že server nepřijímá skutečné chování uživatele (v případě, že server spustí jiný algoritmus v závislosti na kritériích vyhledávání). I když se skript VUser úspěšně spustí, vykreslené statistiky výkonu nebudou smysluplné. Použití různých dat prostřednictvím parametrizace pomáhá emulovat aktivitu na straně serveru (procedury atd.) A procvičuje systém.

Datum, které je pevně zakódováno ve VUseru během nahrávání, již nemusí platit, když toto datum uplyne. Parametrizace data umožňuje úspěšné provedení VUser nahrazením pevně zakódovaného data. Taková pole nebo požadavky jsou správnými kandidáty pro parametrizaci.

Pokud video není přístupné, klikněte sem

Nastavení doby běhu a jejich dopad na simulaci VU

Nastavení doby běhu je stejně významné jako váš skript VUGen. S různými konfiguracemi můžete získat různé návrhy testů. To je důvod, proč můžete skončit v neopakovatelných výsledcích, pokud nastavení doby běhu není konzistentní. Pojďme diskutovat o každém atributu jeden po druhém.

Spustit logiku

Run Logic definuje, kolikrát budou provedeny všechny akce, kromě vuser_init a vuser_end.

Pravděpodobně to objasňuje, proč LoadRunner navrhuje ponechat veškerý přihlašovací kód v rámci vuser_init a část Logout v vuser_end, a to výhradně.

Pokud jste vytvořili více akcí, řekněme: Přihlásit se, Otevřít obrazovku, Vypočítat výpůjčku, Odeslat prostředky, Zkontrolovat zůstatek a odhlásit se, u každého VUsera proběhne níže uvedený scénář:

Všichni uživatelé se přihlásí, provedou otevřenou obrazovku, vypočítají výpůjčky, odešlou prostředky, zkontrolují zůstatek - pak - znovu otevřou obrazovku, vypočítají nájemné… a tak dále - opakují se 10krát - následuje odhlášení (jednou).

Jedná se o silné nastavení umožňující chovat se spíše jako skutečný uživatel. Pamatujte, že skutečný uživatel se nepřihlásí a odhlásí pokaždé - obvykle opakuje stejné kroky.

Kolikrát kliknete na „doručenou poštu“ při kontrole e-mailu před odhlášením?

Stimulace

Toto je důležité. Lidé většinou nejsou schopni porozumět rozdílům mezi stimulací a časem na přemýšlení. Jediný rozdíl je v tom, že „stimulace označuje zpoždění mezi iteracemi“, zatímco doba myšlení je zpoždění mezi libovolnými 2 kroky.

Doporučené nastavení závisí na provedení zkoušky. Pokud však chcete mít agresivní zatížení, zvažte volbu „Jakmile skončí předchozí iterace“

Log

Protokol (jak je obecně chápáno) je účetnictví všech událostí při spuštění nástroje LoadRunner. Můžete povolit protokol, abyste věděli, co se děje mezi vaší aplikací a serverem.

LoadRunner poskytuje výkonný mechanismus protokolování, který je sám o sobě robustní a škálovatelný. Umožňuje vám ponechat pouze „Standardní protokol“ nebo podrobný, konfigurovatelný rozšířený protokol nebo jej úplně deaktivovat.

Standardní protokol je informativní a snadno srozumitelný. Obsahuje správné množství znalostí, které obvykle budete potřebovat při řešení problémů se skripty VUser.

V případě rozšířeného protokolu jsou všechny standardní informace protokolu podmnožinou. Navíc můžete mít substituci parametrů. To říká komponentě LoadRunner, aby zahrnovala úplné informace o všech parametrech (z parametrizace) včetně požadavků a také dat odpovědí.

Pokud uvedete „Data vrácená serverem“, bude váš protokol dlouhý. To bude zahrnovat všechny HTML, tagy, zdroje, informace o jiných zdrojích, které jsou obsaženy přímo v protokolu. Tato možnost je dobrá, pouze pokud potřebujete vážné řešení problémů. Díky tomu je soubor protokolu obvykle velmi velký a není snadno srozumitelný.

Jak jste si už mohli domyslet, pokud se rozhodnete pro „Advance Trace“, váš soubor protokolu bude obrovský. Musíte to zkusit. Zjistíte také, že doba, kterou VUGen vzal, se také významně zvýšila, i když to nebude mít žádný vliv na dobu odezvy transakce nahlášenou VUGenem. Jedná se však o velmi pokročilé informace a možná užitečné, pokud rozumíte předmětné aplikaci, komunikaci klienta se serverem mezi vaší aplikací a hardwarem a také podrobnostem na úrovni protokolu. Obvykle jsou tyto informace v podstatě mrtvé, protože vyžadují extrémní úsilí k pochopení a řešení problémů.

Tipy:

  • Bez ohledu na to, kolik času VUGen zabere, když je povolen protokol, nemá to žádný vliv na dobu odezvy transakce. Společnost HP tento jev nazývá „nejmodernější technologií“.
  • Pokud to není vyžadováno, zakažte protokol.
  • Po dokončení skriptů zakažte protokol. Zahrnutí skriptů s povoleným protokolováním způsobí, že řadič běží pomaleji a hlásí otravné zprávy.
  • Zakázání protokolu zvýší kapacitu maximálního počtu uživatelů, které můžete simulovat z LoadRunneru.
  • Zvažte použití možnosti „Odeslat zprávu, pouze když dojde k chybě“ - ztlumí to nepotřebné informační zprávy a nahlásí pouze zprávy související s chybou.

Mysli na časy

Think Time je jednoduše zpoždění mezi dvěma kroky.

Think Time pomáhá replikovat chování uživatelů, protože žádný skutečný uživatel nemůže používat žádnou aplikaci jako stroj (VUGen). VUGen generuje čas na přemýšlení automaticky. Stále máte úplnou kontrolu nad odstraněním, násobením nebo kolísáním doby trvání přemýšlení.

Abychom lépe porozuměli, může například uživatel otevřít obrazovku (tj. Odpověď, po které následuje požadavek) a poté zadat klávesu uživatelské jméno a heslo, než stiskne klávesu Enter. Další interakce aplikace se serverem nastane, když klikne na „Přihlásit“. Čas, který uživatel potřeboval pro zadání svého uživatelského jména a hesla, je Think Time v LoadRunneru.

Pokud hledáte simulovat agresivní zatížení aplikace, zvažte úplné vypnutí času na přemýšlení.

Chcete-li však simulovat skutečné chování, můžete použít „Uživatelský čas na náhodné přemýšlení“ a nastavit požadovaná procenta.

Zvažte použití Limit Think Time na legitimní období. Obvykle je 30 sekund celkem dost dobrých.

Simulace rychlosti

Simulace rychlosti jednoduše odkazuje na kapacitu šířky pásma pro každý klientský počítač.

Protože simulujeme tisíce uživatelů VUser prostřednictvím nástroje LoadRunner, je úžasné, jak jednoduchý nástroj LoadRunner dokázal ovládat simulaci šířky pásma / rychlosti sítě.

Pokud jste zákazníky, kteří přistupují k vaší aplikaci přes 128 Kbps, můžete ji ovládat odtud. Budete simulovat „skutečné chování“, které by mělo pomoci získat správné statistiky výkonu.

Nejlepším doporučením je nastavit možnost Použít maximální šířku pásma. To pomůže ignorovat všechna úzká místa výkonu související se sítí a nejprve se zaměřit na jakékoli potenciální problémy v aplikaci. Test můžete vždy spustit vícekrát, abyste viděli různé chování za různých okolností.

Emulace prohlížeče

Zážitek uživatele nezávisí na prohlížeči, který koncový uživatel používá. Je zřejmé, že to je nad rámec výkonnostních opatření. Můžete si však vybrat, který prohlížeč chcete emulovat.

Můžete si sami odpovědět, kdy přesně bude pro vás v této konfiguraci důležité vybrat správný prohlížeč?

Tuto konfiguraci použijete, pokud jste předmětem aplikace je webová aplikace, která vrací různé odpovědi pro různé prohlížeče. Například si můžete prohlédnout různé obrázky a obsah pro IE a Firefox atd.

Dalším důležitým nastavením je Simulovat mezipaměť prohlížeče. Pokud chcete měřit dobu odezvy, když je povolena mezipaměť, zaškrtněte toto políčko. Pokud hledáte nejhorší situaci, samozřejmě to není úvaha.

Stahování zdrojů jiných než HTML umožní LoadRunneru stáhnout jakékoli CSS, JS a další multimediální soubory. To by mělo zůstat zkontrolováno. Pokud to však chcete vyloučit ze svého návrhu testu výkonu, můžete to zrušit.

Proxy

Nejlepší je zcela vyloučit proxy z testovacího prostředí - výsledky testu budou nespolehlivé. Můžete však čelit situacím, kdy je to nevyhnutelné. V takové situaci vám LoadRunner usnadní nastavení proxy.

Budete pracovat (nebo byste měli pracovat) s nastavením No proxy. Můžete je získat ve výchozím prohlížeči. Nezapomeňte však zkontrolovat, který prohlížeč je nastaven na výchozí a jaká je konfigurace proxy pro výchozí prohlížeč.

Pokud používáte proxy a vyžaduje ověření (nebo skript), můžete kliknout na tlačítko Ověřit, které vede do nového okna. Viz níže uvedený snímek obrazovky.

Tato obrazovka slouží k zadání uživatelského jména a hesla k ověření na serveru proxy. Kliknutím na OK zavřete obrazovku.

Gratulujeme. Konfigurace skriptu VUGen je hotová. Nezapomeňte jej nakonfigurovat pro všechny vaše skripty VUser.