Параметризация, функции, транзакции в LoadRunner

Записан скрипт може да симулира виртуален потребител; въпреки това обикновеният запис може да не е достатъчен, за да възпроизведе „реалното потребителско поведение“.

Когато се записва скрипт, той обхваща единичен и прав поток на съответното приложение. Като има предвид, че реалният потребител може да извърши множество итерации на всеки процес, преди да излезе. Забавянето между щракването на бутоните (време за мислене) ще варира от човек на човек. Вероятно някои реални потребители имат достъп до вашето приложение през DSL, а други имат достъп до него чрез комутируема връзка. Така че, за да получим истинското усещане на крайния потребител, трябва да подобрим нашите скриптове, за да съответстват точно или поне да са много близки по поведение до реалните потребители.

Горното е най-важното съображение при провеждане на „Тестване на производителността”, но VU скриптът е нещо повече. Как ще прецените точното време, необходимо на VUser, когато SUL е подложен на тест за производителност? Как ще разберете дали VUser е преминал или не е успял в определен момент? Каква е причината зад неуспеха, дали някой процес в задния край е неуспешен или ресурсите на сървъра са били ограничени?

Трябва да подобрим нашия скрипт, за да отговорим на всички горепосочени въпроси.

Използване на транзакции

Транзакциите са механика за измерване на времето за отговор на сървъра за всяка операция. С прости думи, използването на „Транзакция“ помага да се измери времето, необходимо на системата за конкретна заявка. То може да бъде толкова малко, колкото щракване на бутон или извикване на AJAX при загуба на фокус от текстовото поле.

Прилагането на транзакции е лесно. Просто напишете един ред код, преди да бъде направена заявка към сървъра, и затворете транзакцията, когато заявката приключи. LoadRunner изисква само низ като име на транзакция.

За да отворите транзакция, използвайте този ред код:

lr_start_transaction(“Transaction Name”);

За да затворите транзакцията, използвайте този ред код:

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

The казва на LoadRunner дали тази конкретна транзакция е била успешна или неуспешна. Възможните параметри могат да бъдат:

• LR_AUTO
• LR_PASS
• LR_FAIL

Пример:

lr_end_transaction(“My_Login”, LR_AUTO);
lr_end_transaction(“001_Opening_Dashboard Name”, LR_PASS);
lr_end_transaction(“Име на транзакция на бизнес_работен поток”, LR_FAIL);

Точки за забележка:

• Не забравяйте, че работите с „C“ и това е език, който различава малки и големи букви.
• Знакът за точка (.) не е разрешен в името на транзакцията, въпреки че можете да използвате интервали и долна черта.
• Ако сте разклонили кода си добре и сте добавили контролни точки за проверка на отговора от сървъра, можете да използвате персонализирана обработка на грешки, като LR_PASS или LR_FAIL. В противен случай можете да използвате LR_AUTO и LoadRunner автоматично ще обработва сървърна грешка (HTTP 500, 400 и т.н.)
• Когато прилагате транзакции, уверете се, че няма време за_мислене извлечението е поставено в сандвич или в противен случай вашата транзакция винаги ще включва този период.
• Тъй като LoadRunner изисква постоянен низ като име на транзакция, често срещан проблем при прилагане на транзакция е несъответствието на низ. Ако дадете различно име при отваряне и затваряне на транзакция, ще получите поне 2 грешки. Тъй като транзакцията, която сте отворили, никога не е била затворена, LoadRunner ще изведе грешка. Освен това транзакцията, която се опитвате да затворите, никога не е била отваряна, което води до грешка.
• Можете ли да използвате своята интелигентност и да си отговорите коя от горните грешки ще бъде докладвана първа? За да потвърдите отговора си, защо не направите своя собствена грешка? Ако сте отговорили правилно, вие сте на прав път. Ако сте отговорили грешно, трябва да се съсредоточите.
• Тъй като LoadRunner автоматично се грижи за синхронизирането на заявките и отговора, няма да се налага да се притеснявате за отговора при прилагане на транзакции.

Разбиране на времето за мислене, точките на среща и коментарите

Точки за среща

Rendezvous Points означава „точки за среща“. Това е само един ред от израз, който казва на LoadRunner да въведе едновременност. Вие вмъквате точки за среща във VUser скриптове, за да емулирате тежко потребителско натоварване на сървъра.

Точките за среща инструктират VUser да изчака по време на изпълнение на теста няколко VUser да пристигнат в определена точка, така че те да могат едновременно да изпълняват задача. Например, за да емулирате пиково натоварване на сървъра на банката, можете да вмъкнете точка на среща, инструктираща 100 VUser да депозират пари в сметките си едновременно. Това може да се постигне лесно с помощта на рандеву.

Ако точките за среща не са разположени правилно, VUser ще има достъп до различни части на приложението – дори за един и същ скрипт. Това е така, защото всеки VUser получава различно време за реакция и следователно малко потребители изостават.

Синтаксис: lr_rendesvous(“Логическо име”);

Най-добри практики:

• Префикс на точката на среща с „rdv_“ за по-добра четимост на кода; напр. „rdv_Login“
• Премахнете всички твърдения за време за незабавно мислене
• Прилагане на точки за среща в изглед на скрипт (след запис)

Коментари

Добавете коментари, за да опишете дейност, част от код или ред от код. Коментарите помагат кодът да бъде разбираем за всеки, който се позовава на него в бъдеще. Те предоставят информация за конкретна операция и отделят два раздела за разграничение.

Можете да добавяте коментари

• Докато записвате (с помощта на инструмента)
• След запис (директно писане в код)

Най-добра практика: Маркирайте всички коментари в горната част на всеки файл със скрипт

Вмъкване на функции чрез менюто

Докато можете директно да пишете прости редове код, може да се нуждаете от следа, за да си припомните функция. Можете също да използвате Steps Toolbox (известен като Insert Function преди версия 12), за да намерите и вмъкнете всяка функция директно във вашия скрипт.

Можете да намерите лентата с инструменти на Steps под View àSteps Toolbox.

Това ще отвори страничен прозорец, вижте моментната снимка:

Какво е параметризация?

A параметър във VUGen е контейнер, който съдържа записана стойност, която се заменя за различни потребители.

По време на изпълнението на скрипта (във VUGen или Controller), стойността от външен източник (като .txt, XML или база данни) замества предишната стойност на параметъра.

Параметризирането е полезно при изпращане на динамични (или уникални) стойности към сървъра, например; желателно е бизнес процес да изпълнява 10 итерации, но всеки път да избира уникално потребителско име.

Той също така помага за стимулиране на подобно на реалното поведение към субектната система. Разгледайте примера по-долу:

Примери за проблеми:

Бизнес процесът работи само за текущата дата, която идва от сървъра, следователно не може да бъде предадена като твърдо кодирана заявка.

Понякога клиентското приложение предава уникален идентификатор на сървъра (например session_id), за да продължи процесът (дори за един потребител) – в такъв случай параметризирането помага.

Често клиентското приложение поддържа кеш на данни, изпратени към и от сървъра. В резултат на това сървърът не получава реално потребителско поведение (в случай че сървърът изпълнява различен алгоритъм в зависимост от критериите за търсене). Въпреки че VUser скриптът ще се изпълни успешно, изтеглената статистика за производителността няма да има смисъл. Използването на различни данни чрез параметризация помага за емулиране на дейност от страна на сървъра (процедури и т.н.) и упражнява системата.

Дата, която е твърдо кодирана във VUser по време на запис, може вече да не е валидна, когато тази дата изтече. Параметризирането на датата позволява изпълнението на VUser да успее чрез замяна на твърдо кодираната дата. Такива полета или заявки са правилните кандидати за параметризиране.

Кликнете тук ако видеото не е достъпно

Настройки на времето за изпълнение и тяхното въздействие върху симулацията на VU

Настройките за време на изпълнение са толкова важни, колкото и вашият VUGen скрипт. С различни конфигурации можете да получите различни тестови дизайни. Ето защо може да получите неповторими резултати, ако настройките за време на изпълнение не са последователни. Нека обсъдим всеки атрибут един по един.

Пусни логика

Run Logic определя колко пъти ще бъдат изпълнени всички действия, с изключение на vuser_init и vuser_end.

Вероятно това прави по-ясно защо LoadRunner предлага запазване на целия код за влизане във vuser_init и частта за излизане във vuser_end, и двете изключително.

Ако сте създали множество действия, да речем, Влизане, Отворете екрана, Изчислете наема, Изпратете средства, Проверка на баланса и излизане, тогава сценарият по-долу ще се извърши за всеки VUser:

Всички VUsers ще влязат, ще изпълнят Open Screen, Calculate Rental, Submit Funds, Check Balance – след това – отново Open screen, Calculate rentals… и така нататък – повторение 10 пъти – последвано от излизане (веднъж).

Това е мощна настройка, която ви позволява да действате повече като истински потребител. Не забравяйте, че истинският потребител не влиза и излиза всеки път – той обикновено повтаря едни и същи стъпки.

Колко пъти щракнете върху „входяща кутия“, когато проверявате имейла си, преди да излезете?

Pacing

това е важно Повечето хора не са в състояние да разберат разликата между темпото и времето за мислене. Единствената разлика е, „темпата се отнася до забавянето между итерациите“, докато мисленото време е забавянето между всеки 2 стъпки.

Препоръчителната настройка зависи от дизайна на теста. Въпреки това, ако искате да имате агресивно натоварване, помислете дали да изберете „Веднага след като приключи предишната итерация“

Вход

Дневникът (както обикновено се разбира) е счетоводство на всички събития, докато стартирате LoadRunner. Можете да активирате регистрационния файл, за да знаете какво се случва между вашето приложение и вашия сървър.

LoadRunner предоставя мощен механизъм за регистриране, който е здрав и мащабируем сам по себе си. Позволява ви да запазите само „Стандартен дневник“ или подробен, конфигурируем разширен дневник или да го деактивирате напълно.

Стандартният дневник е информативен и лесно разбираем. Той съдържа точното количество знания, които обикновено ще ви трябват за отстраняване на неизправности във вашите VUser скриптове.

В случай на разширен дневник цялата информация от стандартния дневник е подмножество. Освен това можете да имате заместване на параметър. Това казва на компонента LoadRunner да включва пълна информация за всички параметри (от параметризирането), включително заявки, както и данни за отговор.

Ако включите „Данни, върнати от сървъра“, тогава вашият дневник ще бъде дълъг. Това ще включва всички HTML, тагове, ресурси, нересурсна информация, включена направо в дневника. Опцията е добра само ако имате нужда от сериозно отстраняване на неизправности. Обикновено това прави регистрационния файл много голям по размер и не е лесно разбираем.

Както можете да предположите досега, ако изберете „Advance Trace“, вашият лог файл ще бъде огромен. Трябва да опитате. Ще забележите, че времето, необходимо на VUGen, също се е увеличило значително, въпреки че това няма да окаже влияние върху времето за отговор на транзакцията, отчетено от VUGen. Това обаче е много предварителна информация и може да е полезна, ако разбирате съответното приложение, комуникацията клиент-сървър между вашето приложение и хардуер, както и подробности на ниво протокол. Обикновено тази информация е мъртва по същество, тъй като изисква изключителни усилия за разбиране и отстраняване на неизправности.

Съвет:

• Без значение колко време отнема VUGen, когато регистрационният файл е активиран, той няма влияние върху времето за отговор на транзакцията. HP нарича това явление „най-съвременна технология“.
• Деактивирайте регистрационния файл, ако не е необходим.
• Деактивирайте регистрационния файл, когато приключите със скриптовете си. Включването на скриптове с активирано регистриране ще накара контролера да работи по-бавно и ще докладва заяждащи съобщения.
• Деактивирането на регистрационния файл ще увеличи капацитета на максималния брой потребители, които можете да симулирате от LoadRunner.
• Обмислете използването на „Изпращане на съобщение само при възникване на грешка“ – това ще заглуши ненужните информационни съобщения и ще докладва само съобщения, свързани с грешка.

Мисли времена

Think Time е просто забавянето между две стъпки.

Think Time помага за възпроизвеждане на потребителското поведение, тъй като никой реален потребител не може да използва което и да е приложение като машина (VUGen). VUGen генерира автоматично време за мислене. Все още имате пълен контрол да премахвате, умножавате или променяте продължителността на времето за мислене.

За да разбере повече, например, потребителят може да отвори екран (това е отговор, последван от заявка) и след това да предостави потребителското име и паролата, преди да натисне enter. Следващото взаимодействие на приложението със сървъра ще се случи, когато той щракне върху „Вход“. Времето, необходимо на потребителя, за да въведе своето потребителско име и парола, е Think Time в LoadRunner.

Ако искате да симулирате агресивно натоварване на приложението, помислете дали да деактивирате напълно времето за мислене.

Въпреки това, за да симулирате реално подобно поведение, можете да „Време за мислене на потребителя“ и да зададете процентите по желание.

Обмислете използването на Ограничете времето за мислене до законен период. Обикновено 30 секунди са достатъчно добри.

Симулация на скорост

Симулацията на скорост просто се отнася до капацитета на честотната лента за всяка клиентска машина.

Тъй като ние симулираме хиляди VUser чрез LoadRunner, удивително е колко прост е направил LoadRunner, за да контролира симулацията на честотната лента/мрежовата скорост.

Ако сте клиенти с достъп до приложението си над 128 Kbps, можете да го контролирате от тук. Ще можете да симулирате „реално подобно поведение“, което би трябвало да помогне за получаване на точната статистика за ефективността.

Най-добрата препоръка е да зададете Използване на максимална честотна лента. Това ще помогне да се пренебрегнат всички проблеми с производителността, свързани с мрежата, и първо да се съсредоточи върху всички потенциални проблеми в приложението. Винаги можете да стартирате теста няколко пъти, за да видите различно поведение при различни обстоятелства.

Емулация на браузър

Потребителското изживяване не зависи от браузъра, който крайният потребител използва. Ясно е, че това е извън обхвата на мерките за ефективност. Можете обаче да изберете кой браузър искате да емулирате.

Можете ли да си отговорите кога точно ще е важно за вас да изберете правилния браузър в тази конфигурация?

Ще използвате тази конфигурация, ако обектът ви е уеб приложение, което връща различни отговори за различните браузъри. Например можете да видите различни изображения и съдържание за IE и Firefox и т.н.

Друга важна настройка е Симулиране на кеша на браузъра. Ако искате да прецените времето за реакция, когато кешът е активиран, поставете отметка в това квадратче. Ако търсите най-лошата ситуация, това очевидно не е съображение.

Изтеглянето на не-HTML ресурси ще позволи на LoadRunner да изтегли всякакви CSS, JS и други богати медии. Това трябва да остане отметнато. Въпреки това, ако искате да елиминирате това от вашия дизайн на теста за производителност, можете да махнете отметката от това.

пълномощник

Най-добре е да премахнете напълно проксито от вашия Тестова среда – това ще направи резултатите от теста ненадеждни. Въпреки това може да се сблъскате със ситуации, в които това е неизбежно. В такава ситуация LoadRunner ви улеснява с настройките на прокси сървъра.

Ще работите (или трябва да работите) без настройка за прокси. Можете да го получите от вашия браузър по подразбиране. Все пак не забравяйте да проверите кой браузър е зададен по подразбиране и каква е конфигурацията на прокси за браузъра по подразбиране.

Ако използвате прокси и той изисква удостоверяване (или скрипт), тогава можете да щракнете върху бутона Удостоверяване, който води до нов прозорец. Вижте екранната снимка по-долу.

Използвайте този екран, за да предоставите потребителско име и парола, за да се удостоверите на прокси сървъра. Щракнете върху OK, за да затворите екрана.

честито Готови сте с конфигурацията на вашия VUGen скрипт. Не забравяйте да го конфигурирате за всичките си VUser скриптове.