Записаний сценарій може імітувати віртуального користувача; однак, простого запису може бути недостатньо для відтворення "реальної поведінки користувачів".
Коли сценарій записується, він охоплює одиничний і прямий потік предметної програми. Тоді як справжній користувач може виконати кілька ітерацій будь-якого процесу, перш ніж вийти з системи. Затримка між натисканням кнопок (час вдумування) залежить від людини. Швидше за все, деякі реальні користувачі отримують доступ до вашої програми через DSL, а деякі - через комутований доступ. Отже, для того, щоб відчути справжнє відчуття кінцевого користувача, нам потрібно вдосконалити наші сценарії, щоб точно відповідати або, принаймні, дуже близькими за поведінкою до реальних користувачів.
Вищевикладене є найважливішим фактором, коли проводиться «Тестування продуктивності», але сценарій VU має більше. Як ви оціните точну кількість часу, який витрачає користувач, коли SUL проходить перевірку продуктивності? Як ви дізнаєтесь, чи користувач VUser пройшов або не вдався в певний момент? У чому причина відмови, чи не вдався якийсь серверний процес чи ресурси сервера були обмежені?
Нам потрібно вдосконалити наш сценарій, щоб допомогти відповісти на всі вищезазначені запитання.
- Використання транзакцій
- Розуміння часу на роздуми, пунктів побачень та коментарів
- Вставлення функцій через меню
- Що таке параметризація?
- Налаштування часу виконання та їх вплив на моделювання VU
- Запустити логіку
- Стимуляція
- Журнал
- 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 отримує різний час відгуку, і, отже, небагато користувачів відстає.
Синтаксис: lr_rendesvous (“Логічна назва”);
Кращі практики:
- Для кращої читабельності коду префіксуйте точку зустрічі “rdv_”; наприклад, “rdv_Login”
- Видаліть усі негайні заяви про час
- Застосування точок рандеву у поданні сценарію (після запису)
Коментарі
Додайте коментарі, щоб описати діяльність, фрагмент коду або рядок коду. Коментарі допомагають зробити код зрозумілим для тих, хто посилається на нього в майбутньому. Вони містять інформацію про конкретну операцію та окремі два розділи для розрізнення.
Ви можете додавати коментарі
- Під час запису (за допомогою інструменту)
- Після запису (безпосереднє написання в коді)
Найкраща практика: Позначте будь-які коментарі у верхній частині кожного файлу сценарію
Вставлення функцій через меню
Хоча ви можете безпосередньо писати прості рядки коду, вам може знадобитися підказка для виклику функції. Ви також можете використовувати набір інструментів "Кроки" (відомий як "Вставити функцію" до версії 12), щоб знайти та вставити будь-яку функцію безпосередньо у ваш сценарій.
Ви можете знайти Панель інструментів "Кроки" в розділі "Переглянути" Набір інструментів "Кроки".
Після цього відкриється бічне вікно, подивіться на знімок:
Що таке параметризація?
Параметр в VuGen являє собою контейнер , який містить записане значення, замінюються для різних користувачів.
Під час виконання сценарію (у VUGen або Controller) значення із зовнішнього джерела (наприклад .txt, XML або бази даних) замінює попереднє значення параметра.
Параметризація корисна при надсиланні динамічних (або унікальних) значень на сервер, наприклад; бізнес-процес бажаний для запуску 10 ітерацій, але кожен раз вибираючи унікальне ім’я користувача.
Це також допомагає стимулювати реальну поведінку до предметної системи. Погляньте на приклад нижче:
Приклади проблем:
Бізнес-процес працює лише на поточну дату, яка надходить із сервера, тому не може бути передана як жорстко закодований запит.
Іноді клієнтська програма передає унікальний ідентифікатор серверу (наприклад session_id) для продовження процесу (навіть для одного користувача) - у такому випадку параметризація допомагає.
Часто клієнтська програма підтримує кеш даних, що надсилаються на сервер і з нього. Як результат, сервер не отримує реальної поведінки користувача (якщо сервер запускає інший алгоритм залежно від критеріїв пошуку). Поки сценарій VUser буде успішно виконуватися, зібрана статистика продуктивності не буде значущою. Використання різних даних за допомогою параметризації допомагає імітувати діяльність на стороні сервера (процедури тощо) та здійснює систему.
Дата, яка жорстко закодована у VUser під час запису, може втратити силу, коли ця дата минула. Параметризація дати дозволяє виконанню VUser успішно, замінюючи жорстко закодовану дату. Такі поля або запити є правильними кандидатами для параметризації.
Клацніть тут, якщо відео недоступне
Налаштування часу виконання та їх вплив на моделювання VU
Налаштування часу роботи мають настільки ж важливе значення, як ваш сценарій VUGen. З різними конфігураціями ви можете отримати різні тестові конструкції. Ось чому ви можете отримати неповторювані результати, якщо налаштування часу роботи не узгоджуються. Давайте обговоримо кожен атрибут по одному.
Запустити логіку
Логіка запуску визначає кількість разів, коли будуть виконуватися всі дії, крім 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 за допомогою LoadRunner, дивно, наскільки простий LoadRunner зробив для управління моделюванням пропускної здатності / швидкості мережі.
Якщо ви є клієнтами, доступ до вашої програми перевищує 128 Кбіт / с, ви можете керувати нею звідси. Ви зможете змоделювати “справжню поведінку”, яка повинна допомогти отримати правильну статистику ефективності.
Найкраща рекомендація - встановити на Використовувати максимальну пропускну здатність. Це допоможе ігнорувати будь-які вузькі місця, пов’язані з мережею, і спершу зосередитись на будь-яких потенційних проблемах у програмі. Ви завжди можете запустити тест кілька разів, щоб побачити різну поведінку за різних обставин.
Емуляція браузера
Взаємодія з користувачем не залежить від браузера, яким користується кінцевий користувач. Очевидно, що це виходить за рамки показників ефективності. Однак ви можете вибрати, який браузер ви хочете наслідувати.
Чи можете ви відповісти собі, коли саме для вас дійсно буде важливо вибрати правильний браузер у цій конфігурації?
Ви будете використовувати цю конфігурацію, якщо ви тематична програма - це веб-програма, яка повертає різні відповіді для різних браузерів. Наприклад, ви бачите різні зображення та вміст для IE, Firefox тощо.
Іншим важливим параметром є Імітація кешу браузера. Якщо ви хочете визначити час відгуку, коли кеш увімкнено, поставте цей прапорець. Якщо ви шукаєте найгіршу ситуацію, це, очевидно, не є міркуванням.
Завантаження ресурсів, що не належать до HTML, дозволить LoadRunner завантажувати будь-які CSS, JS та інші мультимедійні файли. Це слід залишати перевіреним. Однак якщо ви хочете виключити це зі свого дизайну тесту продуктивності, ви можете зняти цей прапорець.
Проксі
Найкраще повністю вилучити проксі з тестового середовища - це зробить результати тесту ненадійними. Однак ви можете зіткнутися з ситуаціями, коли це неминуче. У такій ситуації LoadRunner дійсно полегшує вам налаштування проксі.
Ви будете працювати (або повинні працювати) без налаштування проксі. Ви можете отримати його у своєму браузері за замовчуванням. Однак, не забудьте перевірити, який браузер встановлений за замовчуванням і яка конфігурація проксі для браузера за замовчуванням.
Якщо ви використовуєте проксі-сервер, і для нього потрібна автентифікація (або сценарій), ви можете натиснути кнопку «Автентифікація», що відкриє нове вікно. Зверніться до знімка екрана нижче.
Використовуйте цей екран, щоб вказати ім’я користувача та пароль для автентифікації на проксі-сервері. Натисніть OK, щоб закрити екран.
Вітаю. Ви закінчили з налаштуванням вашого сценарію VUGen. Не забудьте налаштувати його для всіх ваших сценаріїв VUser.