Записанный сценарий может имитировать виртуального пользователя; однако простой записи может быть недостаточно для воспроизведения «реального поведения пользователя».
Когда сценарий записывается, он охватывает одиночный и прямой поток рассматриваемого приложения. Принимая во внимание, что реальный пользователь может выполнить несколько итераций любого процесса, прежде чем он выйдет из системы. Задержка между нажатиями кнопок (время обдумывания) зависит от человека. Скорее всего, некоторые реальные пользователи получают доступ к вашему приложению через DSL, а некоторые - через коммутируемое соединение. Итак, чтобы получить реальное представление о конечном пользователе, нам необходимо улучшить наши скрипты, чтобы они были точными или, по крайней мере, очень близкими по поведению к реальным пользователям.
Вышеупомянутое является наиболее важным соображением при проведении «Тестирования производительности», но сценарий VU - это еще не все. Как вы определите точное количество времени, затрачиваемое пользователем VUser, когда SUL проходит тест производительности? Как вы узнаете, прошел ли VUser или отказал в определенный момент? Какова причина сбоя, был ли сбой какой-то внутренний процесс или ресурсы сервера были ограничены?
Нам необходимо улучшить наш сценарий, чтобы помочь ответить на все вышеперечисленные вопросы.
- Использование транзакций
- Понимание времени обдумывания, точек встречи и комментариев
- Вставка функций через меню
- Что такое параметризация?
- Параметры времени выполнения и их влияние на симуляцию ЦТ
- Выполнить логику
- Темп
- Бревно
- Think Times
- Моделирование скорости
- Эмуляция браузера
- Прокси
Использование транзакций
Транзакции - это механизм для измерения времени ответа сервера на любую операцию. Проще говоря, использование «Транзакции» помогает измерить время, затраченное системой на конкретный запрос. Это может быть всего лишь нажатие кнопки или вызов AJAX при потере фокуса из текстового поля.
Применять транзакции просто. Просто напишите одну строку кода, прежде чем запрос будет отправлен на сервер, и закройте транзакцию, когда запрос завершится. LoadRunner требует только строки в качестве имени транзакции.
Чтобы открыть транзакцию, используйте эту строку кода:
lr_start_transaction («Название транзакции»);
Чтобы закрыть транзакцию, используйте эту строку кода:
lr_end_transaction («Название транзакции», <статус>);
- LR_AUTO
- LR_PASS
- LR_FAIL
Пример:
lr_end_transaction («Мой_логин», LR_AUTO);
lr_end_transaction («Имя Business_Workflow_Transaction», 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»
- Удалите любые заявления о немедленном размышлении
- Применение точек встречи в виде сценария (после записи)
Комментарии
Добавьте комментарии, чтобы описать действие, фрагмент кода или строку кода. Комментарии помогают сделать код понятным для всех, кто обратится к нему в будущем. Они предоставляют информацию о конкретной операции и разделяют два раздела для различения.
Вы можете добавлять комментарии
- Во время записи (с помощью инструмента)
- После записи (прямая запись в коде)
Рекомендация: отметьте любые комментарии в верхней части каждого файла сценария.
Вставка функций через меню
Хотя вы можете писать простые строки кода напрямую, вам может потребоваться подсказка, чтобы вызвать функцию. Вы также можете использовать панель инструментов Steps Toolbox (известную как Insert Function до версии 12), чтобы найти и вставить любую функцию непосредственно в ваш скрипт.
Вы можете найти панель инструментов Steps в разделе View àSteps Toolbox.
Откроется боковое окно, посмотрите на снимок:
Что такое параметризация?
Параметр в VuGen представляет собой контейнер , который содержит записанное значение, заменяются для различных пользователей.
Во время выполнения сценария (в VUGen или Controller) значение из внешнего источника (например, .txt, XML или база данных) заменяет предыдущее значение параметра.
Параметризация полезна, например, при отправке на сервер динамических (или уникальных) значений; бизнес-процесс должен запускать 10 итераций, но каждый раз выбирать уникальное имя пользователя.
Это также помогает стимулировать реальное поведение субъектной системы. Взгляните на пример ниже:
Примеры проблем:
Бизнес-процесс работает только для текущей даты, поступающей с сервера, поэтому не может быть передан как жестко запрограммированный запрос.
Иногда клиентское приложение передает серверу уникальный идентификатор (например, session_id) для продолжения процесса (даже для одного пользователя) - в этом случае помогает параметризация.
Часто клиентское приложение поддерживает кэш данных, отправляемых на сервер и с сервера. В результате сервер не получает реального поведения пользователя (в случае, если сервер запускает другой алгоритм в зависимости от критериев поиска). Хотя сценарий VUser будет выполняться успешно, полученная статистика производительности не будет иметь смысла. Использование различных данных посредством параметризации помогает имитировать активность на стороне сервера (процедуры и т. Д.) И проверять систему.
Дата, жестко запрограммированная в VUser во время записи, может больше не быть действительной по истечении этой даты. Параметрирование даты позволяет успешно выполнить VUser, заменив жестко запрограммированную дату. Такие поля или запросы являются подходящими кандидатами для параметризации.
Нажмите здесь, если видео недоступно
Параметры времени выполнения и их влияние на симуляцию ЦТ
Настройки времени выполнения имеют такое же значение, как и ваш скрипт VUGen. С различными конфигурациями вы можете получить разные конструкции тестов. Вот почему вы можете получить неповторимые результаты, если настройки времени выполнения не согласованы. Давайте обсудим каждый атрибут по очереди.
Выполнить логику
Логика выполнения определяет, сколько раз будут выполнены все действия, кроме vuser_init и vuser_end.
Вероятно, это проясняет, почему LoadRunner предлагает хранить весь код входа в vuser_init, а часть выхода из системы - в vuser_end, оба исключительно.
Если вы создали несколько действий, скажем, «Войти», «Открыть экран», «Рассчитать аренду», «Внести средства», «Проверить баланс» и выйти из системы, то для каждого виртуального пользователя будет выполняться следующий сценарий:
Все пользователи VUsers войдут в систему, выполнят «Открыть экран», «Рассчитать аренду», «Внести средства», «Проверить баланс» - затем - снова «Открыть экран», «Рассчитать арендную плату…» и так далее - повторять 10 раз - а затем выйти из системы (один раз).
Это мощная настройка, позволяющая действовать как настоящий пользователь. Помните, что настоящий пользователь не входит в систему и не выходит из системы каждый раз - он, как правило, повторяет одни и те же шаги.
Сколько раз вы нажимаете «Входящие» при проверке электронной почты перед выходом из системы?
Темп
Это важно. В большинстве случаев люди не могут понять разницу между ритмом и временем обдумывания. Единственная разница в том, что «темп - это задержка между итерациями», тогда как время размышления - это задержка между любыми двумя шагами.
Рекомендуемая настройка зависит от дизайна теста. Однако, если вам нужна агрессивная нагрузка, рассмотрите вариант «Как только закончится предыдущая итерация».
Бревно
Журнал (в общепринятом понимании) - это учет всех событий при запуске LoadRunner. Вы можете включить журнал, чтобы знать, что происходит между вашим приложением и вашим сервером.
LoadRunner предоставляет мощный механизм ведения журнала, который сам по себе является надежным и масштабируемым. Это позволяет вам вести только «Стандартный журнал» или подробный настраиваемый расширенный журнал или вообще отключать его.
Стандартный журнал информативен и легко понятен. Он содержит только необходимый объем знаний, который обычно может потребоваться для устранения неполадок в сценариях VUser.
В случае расширенного журнала вся информация стандартного журнала является подмножеством. Дополнительно возможна подстановка параметров. Это указывает компоненту LoadRunner включать полную информацию обо всех параметрах (из параметризации), включая запросы, а также данные ответа.
Если вы включите «Данные, возвращенные сервером», тогда ваш журнал будет иметь длину. Это будет включать весь HTML, теги, ресурсы и информацию, не относящуюся к ресурсам, включенную прямо в журнал. Вариант хорош только в том случае, если требуется серьезное устранение неисправностей. Обычно это делает файл журнала очень большим по размеру и трудным для понимания.
Как вы уже могли догадаться, если вы выберете «Advance Trace», ваш файл журнала будет огромным. Вы должны попробовать. Вы заметите, что время, затрачиваемое VUGen, также значительно увеличилось, хотя это не повлияет на время отклика транзакции, сообщаемое VUGen. Однако это очень предварительная информация и может быть полезна, если вы понимаете предметное приложение, взаимодействие клиента с сервером между вашим приложением и оборудованием, а также детали уровня протокола. Обычно эта информация мертва по сути, поскольку требует огромных усилий для понимания и устранения неполадок.
Подсказки:
- Независимо от того, сколько времени занимает VUGen при включении журнала, это не влияет на время отклика транзакции. HP называет это явление «новейшей технологией».
- Отключите журнал, если он не требуется.
- Отключите журнал, когда вы закончите свои скрипты. Включение скриптов с включенным ведением журнала приведет к тому, что контроллер будет работать медленнее и сообщать о неприятных сообщениях.
- Отключение журнала увеличит максимальное количество пользователей, которое вы можете смоделировать с помощью LoadRunner.
- Рассмотрите возможность использования «Отправлять сообщение только при возникновении ошибки» - это отключит ненужные информационные сообщения и сообщит только сообщения, связанные с ошибками.
Think Times
Think Time - это просто задержка между двумя шагами.
Think Time помогает воспроизвести поведение пользователя, поскольку реальный пользователь не может использовать какое-либо приложение, например, машину (VUGen). VUGen автоматически генерирует время для размышлений. У вас по-прежнему есть полный контроль над удалением, умножением или изменением продолжительности времени на обдумывание.
Например, чтобы понять больше, пользователь может открыть экран (то есть ответ, за которым следует запрос), а затем указать его имя пользователя и пароль, прежде чем нажать Enter. Следующее взаимодействие приложения с сервером произойдет, когда он нажмет «Войти». Время, затраченное пользователем на ввод имени пользователя и пароля, равно «Подумайте» в LoadRunner.
Если вы хотите имитировать агрессивную нагрузку на приложение, рассмотрите возможность полного отключения времени обдумывания.
Однако, чтобы смоделировать реальное подобное поведение, вы можете «Время произвольного обдумывания пользователем» и установить желаемые проценты.
Подумайте об ограничении времени на обдумывание законным периодом. Обычно 30 секунд достаточно.
Моделирование скорости
Моделирование скорости просто относится к пропускной способности для каждой клиентской машины.
Поскольку мы моделируем тысячи пользователей VUser с помощью LoadRunner, удивительно, насколько просто LoadRunner сделал управление имитацией полосы пропускания / скорости сети.
Если вы являетесь клиентами и получаете доступ к вашему приложению со скоростью более 128 Кбит / с, вы можете управлять им отсюда. Вы сможете смоделировать «реальное поведение», что должно помочь получить правильную статистику производительности.
Лучшая рекомендация - использовать максимальную пропускную способность. Это поможет игнорировать любые узкие места, связанные с производительностью сети, и в первую очередь сосредоточиться на любых потенциальных проблемах в приложении. Вы всегда можете запустить тест несколько раз, чтобы увидеть различное поведение в разных обстоятельствах.
Эмуляция браузера
Пользовательский опыт не зависит от браузера, который использует конечный пользователь. Ясно, что это выходит за рамки критериев эффективности. Однако вы можете выбрать, какой браузер вы хотите имитировать.
Сможете ли вы ответить себе, когда именно вам будет действительно важно выбрать правильный браузер в этой конфигурации?
Вы будете использовать эту конфигурацию, если предметное приложение является веб-приложением, возвращающим разные ответы для разных браузеров. Например, вы можете видеть разные изображения и содержимое для IE, Firefox и т. Д.
Еще одна важная настройка - Simulate browser cache. Если вы хотите измерить время отклика при включенном кешировании, установите этот флажок. Если вы ищете наихудшую ситуацию, это, очевидно, не рассматривается.
Загрузка ресурсов, отличных от HTML, позволит LoadRunner загрузить любые CSS, JS и другие мультимедийные материалы. Это следует оставить отмеченным. Однако, если вы хотите исключить это из своего плана тестирования производительности, вы можете снять этот флажок.
Прокси
Лучше всего полностью исключить прокси из тестовой среды - это сделает результаты тестирования ненадежными. Однако вы можете столкнуться с ситуациями, когда это неизбежно. В такой ситуации LoadRunner действительно облегчает вам настройку прокси.
Вы будете работать (или должны работать) без настройки прокси. Вы можете получить его в браузере по умолчанию. Однако не забудьте проверить, какой браузер установлен по умолчанию и какая конфигурация прокси для браузера по умолчанию.
Если вы используете прокси-сервер и он требует аутентификации (или скрипта), вы можете нажать кнопку «Аутентифицировать», что приведет к открытию нового окна. См. Снимок экрана ниже.
Используйте этот экран, чтобы указать имя пользователя и пароль для аутентификации на прокси-сервере. Щелкните ОК, чтобы закрыть экран.
Поздравляю. Вы закончили настройку своего скрипта VUGen. Не забудьте настроить его для всех ваших скриптов VUser.