LoadRunner часто встречается в крупных системах, где нужно проверять производительность нескольких протоколов, управлять генераторами нагрузки и сопоставлять измерения с инфраструктурой. Для QA полезнее понимать устройство сценария и эксперимента, чем запоминать расположение кнопок. Даже развитая платформа не делает записанный сценарий достоверным автоматически.
Под названием LoadRunner встречаются разные продукты, редакции и поколения интерфейсов. Возможности, компоненты, поддерживаемые протоколы и условия использования уточняют для установленной версии. Пример ниже относится к C-сценарию Web HTTP/HTML в VuGen; его нельзя без изменений переносить в DevWeb или считать универсальным для любого продукта семейства.
Из каких частей состоит работа
Сначала создают и отлаживают виртуального пользователя, затем задают нагрузочный профиль, выполняют прогон и анализируют результат. В классическом процессе участвуют VuGen, средство управления запуском, генераторы и анализ результатов. Конкретный состав зависит от выбранного решения.
Разделяйте эти уровни при расследовании. Скрипт может корректно пройти в VuGen, но не получить нужные данные на удалённом генераторе. Или сценарий создаёт нужную нагрузку, а итоговый отчёт использует неверные границы транзакции. Проверка каждого уровня предотвращает уверенные выводы по неполному измерению.
Протокол и пользовательский смысл
Для API обычно нужен подходящий HTTP-сценарий. Протокольное обращение не измеряет отрисовку браузера и выполнение интерфейсного JavaScript. Если вопрос касается времени до готовности экрана, нужен другой способ измерения либо отдельное наблюдение пользовательской части.
Опишите бизнес-операцию до записи: вход, поиск, создание заявки, чтение статуса. Решите, где начинается и заканчивается транзакция. Установка большой транзакции вокруг всей сессии затруднит локализацию медленного шага; множество бессмысленных транзакций сделает отчёт шумным.
Минимальный фрагмент VuGen
В существующем проекте Web HTTP/HTML следующий Action читает каталог собственного стенда. Endpoint обязан вернуть статус 200 и содержать поле items. Домен примера заменяют адресом согласованного окружения, а timeout задают в runtime settings до запуска.
int Action(void)
{
lr_start_transaction("catalog");
web_reg_find("Text=items", LAST);
web_url("catalog_request",
"URL=https://qa.example.test/api/catalog",
"Resource=0",
"RecContentType=application/json",
LAST);
if (web_get_int_property(HTTP_INFO_RETURN_CODE) != 200) {
lr_end_transaction("catalog", LR_FAIL);
} else {
lr_end_transaction("catalog", LR_AUTO);
}
return 0;
}Это фрагмент для среды VuGen с её заголовками и runtime, а не самостоятельная C-программа. Сначала выполните одну итерацию одним пользователем. Убедитесь, что при намеренно неправильном ожидаемом тексте проверка действительно помечает запрос и транзакцию как неуспешные в выбранных настройках обработки ошибок.
Почему регистрация стоит до запроса
web_reg_find регистрирует проверку для следующей подходящей операции. Возвращаемое значение самой регистрации ещё не говорит, найден ли текст в будущем ответе. Проверка выполняется, когда ответ поступает. Аналогично необходимо понимать момент регистрации функций корреляции.
Поиск строки items в примере — только учебный контроль, а не полноценная проверка JSON-схемы. В реальном сценарии добавляют проверку существенных полей и значений. Быстрый ответ с пустой или неверной бизнес-информацией не должен считаться успешной покупкой или созданием заявки.
Корреляция и параметры
Сессии, CSRF-токены и идентификаторы объектов извлекают из актуального ответа. Для JSON применяют подходящую функцию извлечения, зарегистрированную перед запросом, ответ которого нужен. Полученное значение используют в последующем действии и проверяют его наличие.
Тестовые пользователи и входные данные параметризуются отдельно. Один аккаунт на сотни Vusers способен создать искусственную блокировку сессии или одной записи. Уточните политику выдачи параметров и их запас, особенно при нескольких генераторах. Набор данных должен поддерживать весь планируемый прогон.
Think time, pacing и профиль
Think time моделирует паузу человека между действиями, pacing — режим начала повторных итераций. Их случайное сочетание может заметно изменить фактическую интенсивность. Если задержки сервера растут, фиксированный набор занятых пользователей обычно начинает меньше новых операций.
Поэтому число Vusers не равно числу запросов в секунду. Сопоставляйте выбранную модель с вопросом: одновременные операторы или независимый поток входящих заявок? Проверьте достигнутые транзакции и запросы за интервал. Один универсальный профиль не отвечает на все вопросы о производительности.
Подготовка генераторов
Проверьте версии, зависимости, доступ к стенду, сертификаты и доступность тестовых файлов. Удалённый генератор может иметь другой маршрут сети или конфигурацию TLS, чем рабочая машина автора сценария. Небольшой проверочный запуск полезнее долгого прогона с массовыми инфраструктурными ошибками.
Наблюдайте CPU, память, сеть и доступные соединения генераторов. Расширение их числа помогает, только если обнаружен соответствующий предел. Если ограничение находится в подготовке данных или неверном сценарии, распределение повторит проблему на большем количестве узлов.
Практический эксперимент
Для тестового каталога согласуйте небольшой разгон, стабильный участок и остановку. Подготовьте контрольную запись, которую можно найти независимо от кэша. До запуска запишите сборку, объём данных, ресурсы и критерии задержки; численные пороги определяет проект.
На стабильном участке ожидаются правильные ответы и выполнение согласованных порогов при фактически достигнутой нагрузке. На сервере наблюдайте пул базы, CPU, память и очереди. Если доля ошибок растёт, сначала классифицируйте их: бизнес-проверка, timeout, инфраструктура или перегрузка. Общая красная линия не объясняет причину.
Ошибки и итоговый вывод
Частые ошибки — доверять записи без корреляции, измерять экран входа вместо операции, считать Vusers интенсивностью и смешивать разные редакции документации. Не менее опасно делать вывод о всём продукте по одному endpoint или сравнивать прогоны с разными данными.
В отчёте сохраняют сценарий, настройки runtime, профиль, версии компонентов, достигнутый поток и наблюдения ресурсов. Вывод должен объяснять, какое требование подтвердилось и при каких условиях. Ценность LoadRunner в этом процессе — управляемый эксперимент и доказательства, пригодные для повторной проверки.