Записаният скрипт може да симулира виртуален потребител; обаче, само запис може да не е достатъчен, за да се възпроизведе „реалното поведение на потребителя“.
Когато се записва скрипт, той обхваща единичен и прав поток на предметното приложение. Докато реалният потребител може да извърши множество итерации на всеки процес, преди да излезе. Закъснението между щракването на бутоните (време за мислене) ще варира от човек на човек. Шансовете са, че някои реални потребители имат достъп до вашето приложение през DSL, а някои от него чрез комутируема връзка. Така че, за да получим истинското усещане за крайния потребител, трябва да подобрим нашите скриптове, за да съвпадат точно или поне да са много близки по поведение до реалните потребители.
Горното е най-същественото съображение при провеждането на „Тестване на производителността“, но има повече от VU Script. Как ще прецените точния период от време, използван от VUser, когато SUL преминава тест за ефективност? Как бихте разбрали дали VUser е преминал или се е провалил в определен момент? Каква е причината за неуспеха, дали някакъв бекенд процес се е провалил или ресурсите на сървъра са били ограничени?
Трябва да подобрим нашия скрипт, за да помогнем да отговорим на всички горепосочени въпроси.
- Използване на транзакции
- Разбиране на времето за мислене, точките за среща и коментарите
- Вмъкване на функции през менюто
- Какво е параметризиране?
- Настройки на времето за изпълнение и тяхното въздействие върху VU симулация
- Стартирайте Logic
- Темпо
- Влезте
- Think Times
- Симулация на скоростта
- Емулация на браузър
- Прокси
Използване на транзакции
Транзакциите са механика за измерване на времето за реакция на сървъра за всяка операция. С прости думи, използването на „Транзакция“ помага да се измери времето, необходимо на системата за конкретна заявка. Тя може да бъде толкова малка, колкото щракване на бутон или AJAX повикване при загуба на фокус от текстовото поле.
Прилагането на транзакции е лесно. Просто напишете един ред код преди заявката да бъде направена към сървъра и затворете транзакцията, когато заявката приключи. LoadRunner изисква само низ като име на транзакция.
За да отворите транзакция, използвайте този ред код:
lr_start_transaction („Име на транзакцията“);
За да затворите транзакцията, използвайте този ред код:
lr_end_transaction („Име на транзакцията“, <статус>);
- LR_AUTO
- LR_PASS
- LR_FAIL
Пример:
lr_end_transaction (“My_Login”, LR_AUTO);
lr_end_transaction (“Business_Workflow_Transaction Name”, LR_FAIL);
Точки за отбелязване:
- Не забравяйте, че работите с “C” и това е език, чувствителен към малки и големи букви.
- Символът за период (.) Не е разрешен в името на транзакцията, въпреки че можете да използвате интервали и долна черта.
- Ако сте разклонили добре кода си и сте добавили контролни точки, за да проверите отговора от сървъра, можете да използвате персонализирана обработка на грешки, като LR_PASS или LR_FAIL. В противен случай можете да използвате LR_AUTO и LoadRunner автоматично ще обработва грешка на сървъра (HTTP 500, 400 и т.н.)
- Когато прилагате транзакции, уверете се, че не е поставено извлечение на think_time или иначе вашата транзакция винаги ще включва този период.
- Тъй като LoadRunner изисква постоянен низ като име на транзакция, често срещан проблем при прилагането на транзакцията е несъответствието на низа. Ако дадете различно име при отваряне и затваряне на транзакция, ще имате поне 2 грешки. Тъй като транзакцията, която сте отворили, никога не е била затворена, LoadRunner ще доведе до грешка. Освен това транзакцията, която се опитвате да затворите, никога не е била отворена, което води до грешка.
- Можете ли да използвате интелигентността си и да си отговорите коя от горните грешки ще бъде докладвана първа? За да потвърдите отговора си, защо не направите своя грешка? Ако бяхте отговорили правилно, вие сте на път. Ако сте отговорили погрешно, трябва да се съсредоточите.
- Тъй като LoadRunner автоматично се грижи за синхронизирането на заявките и отговорите, няма да се притеснявате за отговор при прилагане на транзакции.
Разбиране на времето за мислене, точките за среща и коментарите
Точки за среща
Точките за срещи означават „точки за среща“. Това е само един ред на изявление, който казва на LoadRunner да въведе паралелност. Вмъквате точки за срещи в скриптове на VUser, за да емулирате тежко потребителско натоварване на сървъра.
Точките за срещи инструктират VUser да изчака по време на изпълнението на теста, за да пристигне множество VUser в определена точка, за да могат едновременно да изпълняват задача. Например, за да емулирате пиково натоварване на банковия сървър, можете да вмъкнете точка за среща, инструктираща 100 VUser да депозира пари в сметките си едновременно. Това може да се постигне лесно с помощта на рандеву.
Ако точките за срещи не са поставени правилно, VUser ще има достъп до различни части на приложението - дори за един и същ скрипт. Това е така, защото всеки VUser получава различно време за реакция и следователно малко потребители изостават.
Синтаксис: lr_rendesvous („Логическо име“);
Най-добри практики:
- Префикс на точка за срещи с „rdv_“ за по-добра четливост на кода; напр. „rdv_Login“
- Премахнете всички изявления за незабавно мислене
- Прилагане на точки за срещи в изглед на скрипт (след запис)
Коментари
Добавете коментари, за да опишете дейност, парче код или ред код. Коментарите помагат да направите кода разбираем за всеки, който се позовава на него в бъдеще. Те предоставят информация за конкретна операция и отделни два раздела за разграничение.
Можете да добавяте коментари
- Докато записвате (с помощта на инструмент)
- След запис (директно писане в код)
Най-добра практика: Маркирайте всякакви коментари в горната част на всеки скриптов файл
Вмъкване на функции през менюто
Въпреки че можете директно да пишете прости редове код, може да ви е необходима следа за извикване на функция. Можете също да използвате Стъпки с инструменти (известна като Вмъкване на функция преди версия 12), за да намерите и вмъкнете която и да е функция директно във вашия скрипт.
Можете да намерите лентата с инструменти Steps в View àSteps Toolbox.
Това ще отвори страничен прозорец, погледнете моментната снимка:
Какво е параметризиране?
Един параметър в VUGen е контейнер, който съдържа записва стойност, която се заменя за различни потребители.
По време на изпълнението на скрипта (във VUGen или Controller) стойността от външен източник (като .txt, XML или база данни) замества предишната стойност на параметъра.
Параметризацията е полезна при изпращане на динамични (или уникални) стойности на сървъра, например; желателен е бизнес процес, който да изпълнява 10 повторения, но всеки път да избирате уникално потребителско име.
Той също така помага за стимулиране на реално подобно поведение към субектната система. Погледнете примера по-долу:
Примери за проблеми:
Бизнес процесът работи само за текущата дата, която идва от сървъра, поради което не може да бъде предадена като твърдо кодирана заявка.
Понякога клиентското приложение предава уникален идентификатор на сървъра (например session_id), за да продължи процесът (дори за един потребител) - В такъв случай параметризирането помага.
Често клиентското приложение поддържа кеш от данни, изпращани към и от сървъра. В резултат на това сървърът не получава реално поведение на потребителя (в случай че сървърът изпълнява различен алгоритъм в зависимост от критериите за търсене). Докато скриптът VUser ще се изпълнява успешно, изготвената статистика за ефективността няма да има значение. Използването на различни данни чрез параметризиране помага да емулира активност от страна на сървъра (процедури и т.н.) и упражнява системата.
Дата, която е кодирана твърдо във VUser по време на запис, може вече да не е валидна, когато тази дата е изтекла. Параметризирането на датата позволява изпълнението на VUser да успее, като замени твърдо кодираната дата. Такива полета или заявки са подходящите кандидати за параметризиране.
Щракнете тук, ако видеоклипът не е достъпен
Настройки на времето за изпълнение и тяхното въздействие върху VU симулация
Настройките на времето за изпълнение имат толкова голямо значение, колкото вашия VUGen Script. С различни конфигурации можете да получите различни тестови проекти. Ето защо може да получите неповторими резултати, ако настройките за време на изпълнение не са последователни. Нека обсъдим всеки атрибут един по един.
Стартирайте Logic
Run Logic определя колко пъти всички действия ще бъдат изпълнени, с изключение на vuser_init и vuser_end.
Вероятно това прави по-ясно защо LoadRunner предлага да запазите целия код за влизане в рамките на vuser_init и частта за излизане във vuser_end, и двете изключително.
Ако сте създали множество действия, да речем, влезте, отворете екрана, изчислете наема, изпратете средства, проверете баланса и излезте, тогава ще се проведе сценарий по-долу за всеки потребител:
Всички потребители ще влязат в системата, ще изпълнят отворен екран, изчисляване на наема, изпращане на средства, проверка на баланса - след това - отново отворен екран, изчисляване на наемите ... и така нататък - итерация 10 пъти - последвано от излизане (веднъж).
Това е мощна настройка, позволяваща да действате по-скоро като истински потребител. Не забравяйте, че истинският потребител не влиза и излиза всеки път - той обикновено повтаря същите стъпки.
Колко пъти щракнете върху „пощенска кутия“, когато проверявате имейла си преди излизане?
Темпо
Това е важно. Повечето хора не са в състояние да разберат различното между темпото и времето за мислене. Единствената разлика е, че „темпото се отнася до закъснението между итерациите“, докато времето за мисля е закъснението между всякакви 2 стъпки.
Препоръчителната настройка зависи от тестовия дизайн. Ако обаче искате да имате агресивно натоварване, помислете дали да изберете „Веднага след като предишната итерация приключи“
Влезте
Дневникът (както обикновено се разбира) е водене на всички събития, докато стартирате LoadRunner. Можете да активирате регистрацията, за да знаете какво се случва между вашето приложение и вашия сървър.
LoadRunner предоставя мощен механизъм за регистриране, който е надежден и мащабируем самостоятелно. Тя ви позволява да запазите само „Стандартен дневник“ или подробен, конфигурируем разширен дневник или да го деактивирате напълно.
Стандартният дневник е информативен и лесно разбираем. Той съдържа точното количество знание, което обикновено ще ви е необходимо за отстраняване на неизправности във вашите VUser скриптове.
В случай на разширен дневник, цялата информация за стандартния дневник е подмножество. Освен това можете да имате заместване на параметри. Това казва на компонента LoadRunner да включва пълна информация за всички параметри (от параметризацията), включително заявки, както и данни за отговор.
Ако включите „Данни, върнати от сървъра“, дневникът ви ще продължи. Това ще включва целия HTML, тагове, ресурси, нересурсна информация, включена точно в дневника. Опцията е добра само ако имате нужда от сериозно отстраняване на неизправности. Обикновено това прави регистрационния файл много голям по размер и не е лесно разбираем.
Както вече можеше да се досетите, ако изберете „Advance Trace“, вашият регистрационен файл ще бъде масивен. Трябва да опитате. Ще забележите, че времето, отделено от VUGen, също се е увеличило значително, въпреки че това няма да окаже влияние върху времето за реакция на транзакцията, отчетено от VUGen. Това обаче е много предварителна информация и може би полезна, ако разбирате предметното приложение, комуникацията между клиент и сървър между вашето приложение и хардуер, както и подробности на ниво протокол. Обикновено тази информация е мъртва по същество, тъй като изисква изключителни усилия за разбиране и отстраняване на неизправности.
Съвети:
- Без значение колко време отнема VUGen, когато регистрационният файл е активиран, това няма влияние върху времето за реакция на транзакцията. HP нарича това явление като „модерна технология“.
- Деактивирайте регистрационния файл, ако не се изисква.
- Деактивирайте регистрационния файл, когато приключите с вашите скриптове. Включването на скриптове с разрешено регистриране ще доведе до по-бавно изпълнение на контролера и докладване на заяждащи съобщения.
- Деактивирането на регистрационния файл ще увеличи капацитета на максималния брой потребители, които можете да симулирате от LoadRunner.
- Помислете дали да не използвате „Изпращане на съобщение само когато възникне грешка“ - това ще заглуши ненужните информационни съобщения и ще отчете само съобщения, свързани с грешки.
Think Times
Think Time е просто забавянето между две стъпки.
Think Time помага да репликира поведението на потребителите, тъй като никой реален потребител не може да използва приложение като машина (VUGen). VUGen автоматично генерира време за мислене. Все още имате пълен контрол за премахване, умножаване или колебание на продължителността на времето за мислене.
За да разбере повече, например, потребителят може да отвори екран (това е отговор, последван от заявка) и след това да му предостави потребителско име и парола, преди да натисне enter. Следващото взаимодействие на приложението със сървъра ще се случи, когато той щракне върху „Вход“. Времето, на което потребителят е въвел своето потребителско име и парола, е Think Time в LoadRunner.
Ако искате да симулирате агресивно натоварване на приложението, помислете дали да деактивирате напълно времето за мислене.
Въпреки това, за да симулирате реално подобно поведение, можете да „Време за случайно мислене на потребителя“ и да зададете процентите по желание.
Помислете дали да не ограничите времето за мислене до законен период. Обикновено 30 секунди са достатъчно добри.
Симулация на скоростта
Симулацията на скоростта се отнася просто до капацитета на честотната лента за всяка клиентска машина.
Тъй като симулираме хиляди VUser's чрез LoadRunner, невероятно е колко просто е LoadRunner за управление на симулацията на честотната лента / скоростта на мрежата.
Ако сте клиенти, имате достъп до приложението си над 128 Kbps, можете да го контролирате от тук. Ще можете да симулирате „реално подобно поведение“, което трябва да помогне за получаването на правилната статистика за ефективността.
Най-добрата препоръка е да зададете да се използва максимална честотна лента. Това ще помогне да се пренебрегнат всички проблеми, свързани с работата на мрежата, и първо да се съсредоточите върху всички потенциални проблеми в приложението. Винаги можете да изпълните теста няколко пъти, за да видите различно поведение при различни обстоятелства.
Емулация на браузър
Потребителският опит не зависи от браузъра, който крайният потребител използва. Ясно е, че това е извън обхвата на мерките за изпълнение. Можете обаче да изберете кой браузър искате да подражавате.
Можете ли да си отговорите кога точно ще ви е важно да изберете правилния браузър в тази конфигурация?
Ще използвате тази конфигурация, ако обектът е уеб приложение, което връща различни отговори за различни браузъри. Например, можете да видите различни изображения и съдържание за IE и Firefox и т.н.
Друга важна настройка е Симулиране на кеша на браузъра. Ако искате да прецените времето за реакция, когато кешът е активиран, поставете отметка в това квадратче. Ако търсите най-лошия случай, това очевидно не е съображение.
Изтеглянето на ресурси, които не са HTML, ще позволи на LoadRunner да изтегли всеки CSS, JS и други мултимедия. Това трябва да остане проверено. Ако обаче искате да премахнете това от дизайна на теста за ефективност, можете да премахнете това.
Прокси
Най-добре е да премахнете проксито напълно от тестовата си среда - това ще направи резултатите от теста ненадеждни. Въпреки това може да се сблъскате със ситуации, при които това е неизбежно. В такава ситуация LoadRunner ви улеснява с настройките на прокси сървъра.
Вие ще работите (или трябва да работите) без настройка за прокси. Можете да го получите от браузъра си по подразбиране. Не забравяйте обаче да проверите кой браузър е зададен по подразбиране и каква прокси конфигурация е за браузър по подразбиране.
Ако използвате прокси и той изисква удостоверяване (или скрипт), можете да щракнете върху бутона Удостоверяване, който води до нов прозорец. Вижте скрийншота по-долу.
Използвайте този екран, за да предоставите потребителско име и парола за удостоверяване на прокси сървъра. Щракнете върху OK, за да затворите екрана.
Честито. Приключихте с конфигурирането на вашия VUGen скрипт. Не забравяйте да го конфигурирате за всичките си VUser скриптове.