Инструмент тестирования LoadRunner: ArchiСхема и компоненты архитектуры

⚡ Умное резюме

LoadRunner — это инструмент для тестирования производительности предприятий, который теперь продается компанией [название компании]. OpenTextЭта система имитирует работу тысяч виртуальных пользователей в VuGen, Controller, генераторах нагрузки и Analysis, чтобы выявлять узкие места до того, как их обнаружит реальный трафик.

  • 🔘 Происхождение: Построенный Mercury Компания Interactive была приобретена HP, затем Micro Focus, а теперь... OpenText.
  • ☑️ Покрытие: Одна из самых обширных библиотек протоколов, от HTTP и Ajax до SAP, Oracle и Citrix.
  • ✅ VuGen: Записывает трафик клиента и сервера в скрипт виртуального пользователя, который воспроизводит бизнес-процессы.
  • 🧪 контроллер: Формирует сценарий — подсчет виртуальных пользователей, наращивание нагрузки, внедрение, подмена IP-адресов и проверки SLA.
  • 🇧🇷 Генераторы нагрузки: Распределите виртуальных пользователей по разным машинам, чтобы контроллер никогда не искажал измерения.
  • 📊 Анализ: Преобразует исходные результаты в графики, которые позволяют определить узкое место в системе под нагрузкой.

Компоненты инструмента тестирования LoadRunner и Archiтекстура

Что такое LoadRunner?

LoadRunner — это Тестирование производительности инструмент, который был впервые разработан Mercury Компания Interactive была основана в 1999 году. LoadRunner позже была приобретена HP в 2006 году, а подразделение HP, занимающееся разработкой программного обеспечения, объединилось с Micro Focus в рамках сделки, объявленной в 2016 году и завершенной в 2017 году.

Примечание бренда: OpenText Компания завершила приобретение Micro Focus в январе 2023 года.Этот инструмент больше не продается под маркой HP или... Micro Focus LoadRunnerLoadRunner Professional теперь доступен. OpenText Компания LoadRunner Enterprise специализируется на профессиональном проектировании и повышении производительности. OpenText Enterprise Performance Engineering и LoadRunner Cloud — это OpenText Основные принципы проектирования производительности. Названия компонентов, указанных ниже — VuGen, контроллер, генераторы нагрузки и анализ — остаются без изменений.

LoadRunner поддерживает различные инструменты разработки, технологии и протоколы связи. Он обладает одной из самых обширных библиотек протоколов на рынке для проведения тестирования производительности. Результаты тестирования производительности, полученные с помощью программного обеспечения LoadRunner, используются в качестве эталона для сравнения с другими инструментами.

Видео о LoadRunner

Посмотрите видео ниже, чтобы быстро ознакомиться с LoadRunner, прежде чем переходить к изучению его компонентов.

Почему LoadRunner?

LoadRunner — это не только новаторский инструмент в области тестирования производительности, но и один из лидеров рынка в этой парадигме, который до сих пор служит эталоном для многих предприятий.

Наиболее очевидной причиной выбора этого протокола является его охват, как показывает приведенная ниже схема компонентов.

LoadRunner позиционируется как инструмент для тестирования производительности корпоративных приложений.

В широком смысле инструмент LoadRunner поддерживает RIA (многофункциональные интернет-приложения), Web 2.0 (HTTP/HTML, Ajax, Flex и Silverlight и т. д.), Mobile, SAP, Oracle, МС SQL Сервер, Citrix, RTE, Mail и превыше всего, Windows Сокеты. Немногие конкурирующие инструменты предлагают такое широкое разнообразие протоколов, объединенных в одном инструменте, как показывает приведенный ниже список протоколов.

Диапазон протоколов приложений, поддерживаемых LoadRunner.

Что еще более убедительно в пользу выбора LoadRunner для тестирования программного обеспечения, так это надежность этого инструмента. LoadRunner давно зарекомендовал себя как надежный инструмент, поскольку клиенты часто сверяют ваши результаты тестов производительности с результатами, полученными с помощью LoadRunner. Вы почувствуете облегчение, если уже используете LoadRunner для тестирования производительности.

Программное обеспечение LoadRunner тесно интегрировано с родственными инструментами того же пакета — Unified Functional Testing (первый из них). QTPтеперь продается как OpenText функциональное тестирование) и ALM (управление жизненным циклом приложений, теперь) OpenText ALM/Quality Center) — это платформа, которая позволяет вам выполнять сквозные процессы тестирования.

LoadRunner работает по принципу имитации виртуальных пользователей в рассматриваемом приложении. Эти виртуальные пользователи, также называемые VUsers, воспроизводят запросы клиента и ожидают соответствующего ответа для завершения транзакции.

Зачем вам нужно тестирование производительности?

Приведенные ниже отраслевые оценки широко цитируются и относятся к началу 2010-х годов, но описываемая ими закономерность не изменилась: медленная загрузка страниц обходится дорого.

По оценкам, из-за низкой производительности веб-сайтов ежегодно фиксируются потери выручки в размере 4.4 миллиарда долларов.

В современную эпоху Web 2.0 пользователи покидают веб-сайт, если он не отвечает в течение 8 секунд. Представьте, что вы ждете 5 секунд, когда ищете что-то другое. Google или отправка запроса на добавление в друзья в Facebook. Последствия простоев в работе часто оказываются гораздо более разрушительными, чем можно было себе представить. Есть хорошо известные примеры, такие как те, что затронули онлайн-банкинг Bank of America. Amazon Веб-сервисы, Intuit и Blackberry.

Согласно данным Dun & Bradstreet, 59% компаний из списка Fortune 500 испытывают примерно 1.6 часа простоя каждую неделю. Учитывая, что средняя компания из списка Fortune 500 с численностью сотрудников не менее 10 000 человек платит 56 долларов в час, затраты на оплату труда в связи с простоем для такой организации составят 896 000 долларов в неделю, что в сумме составит более 46 миллионов долларов в год.

Всего 5 минут простоя GoogleПо оценкам, в августе 2013 года закрытие домена .com обошлось поисковому гиганту в сумму до 545 000 долларов.

По оценкам, в прошлом компании теряли продажи на сумму 1,100 долларов в секунду. Amazon Сбой в работе веб-сервисов.

Когда в организации развертывается программная система, она может столкнуться со многими сценариями, которые могут привести к задержке производительности. Ряд факторов вызывает снижение производительности, вот несколько примеров:

  • Увеличено количество записей в базе данных.
  • Увеличено количество одновременных запросов к системе.
  • По сравнению с прошлым, система одновременно используется большим количеством пользователей.

Однако не каждая заявка подходит. испытание нагрузкой Предназначена для клиент-серверных многопользовательских систем, поэтому тестирование производительности однопользовательской настольной утилиты, подобной приведенной ниже, нецелесообразно.

Однопользовательская настольная утилита, не предназначенная для тестирования производительности.

Что такое LoadRunner Archiтекстура?

В целом, архитектура LoadRunner сложна, но при этом проста для понимания. Приведенная ниже диаграмма архитектуры LoadRunner показывает, как четыре компонента взаимодействуют друг с другом.

Архитектурная схема LoadRunner, показывающая VuGen, контроллер, генераторы нагрузки и анализ.

Предположим, вам поручили проверить работоспособность Amazon.com для 5000 пользователей.

В реальной ситуации все эти 5000 пользователей не будут находиться на главной странице — они будут распределены по разным разделам сайта. Как же смоделировать это различие?

VuGen

VuGen или виртуальный пользователь Generator VuGen — это интегрированная среда разработки (IDE) или многофункциональный редактор кода. VuGen используется для воспроизведения поведения системы под нагрузкой (SUL). VuGen предоставляет функцию «записи», которая записывает обмен данными между клиентом и сервером в виде закодированного скрипта — также называемого Скрипт виртуального пользователя.

Таким образом, рассматривая приведенный выше пример, VuGen может записывать и имитировать следующие бизнес-процессы:

  • Просмотр страницы продуктов Amazon.com
  • Оформление заказа
  • Процесс оплаты
  • Проверка страницы «Моя учетная запись»

После того как скрипт запустится без проблем, обычно необходимо получить динамические значения сервера с помощью корреляция прежде чем его можно будет масштабировать.

Контроллер

После завершения работы над сценарием для виртуального пользователя, Контроллер LoadRunner — один из основных компонентов, управляющий моделированием нагрузки, например, путем управления следующими процессами:

  • Сколько пользователей VUser моделировать для каждого бизнес-процесса или группы VUser?
  • Поведение пользователей VUser (нарастание, замедление, одновременный или параллельный характер и т. д.)
  • Сценарий характера нагрузки, например, реальная жизнь, целенаправленность или проверка соглашения об уровне обслуживания.
  • Какие инжекторы использовать, сколько пользователей VUser на каждый инжектор
  • Периодически сопоставляйте результаты
  • IP Spoofing
  • Сообщения об ошибках
  • Отчеты о транзакциях и т. д.

По аналогии с нашим примером, контроллер добавит следующие параметры в скрипт VuGen:

  1. 3500 пользователей просматривают страницу товаров. Amazon.com
  2. 750 пользователей находятся на этапе оформления заказа.
  3. 500 пользователей осуществляют обработку платежей.
  4. 250 пользователей будут проверять страницу «Мой аккаунт» ТОЛЬКО после того, как 500 пользователей завершат обработку платежей.

Возможны и более сложные сценарии:

  • Инициируйте 5 пользователей VUser каждые 2 секунды до загрузки 3500 пользователей VUsers (серфинг Amazon страница продукта) достигнута.
  • Повторяем в течение 30 минут
  • Приостановить итерацию для 25 пользователей VUsers
  • Перезапуск 20 виртуальных пользователей
  • Каждую секунду инициируйте двух пользователей (в разделе «Оформление заказа», «Обработка платежей», «Мои учетные записи»).
  • На машине А будет создано 2500 пользователей VUser.
  • На машине B будет создано 2500 пользователей VUser.

Агенты Машина/Загрузка Generatorс/Инжекторы

Контроллер LoadRunner отвечает за моделирование тысяч виртуальных пользователей (VUsers) — эти VUsers потребляют аппаратные ресурсы, например, процессор и память, — что ограничивает возможности машины, которая их моделирует. Кроме того, контроллер моделирует этих VUsers на одной и той же машине (где он находится), поэтому результаты могут быть неточными. Для решения этой проблемы все VUsers распределяются по различным машинам, называемым LoadRunner. Generators или нагрузочные форсунки.

Как правило, контроллер находится на другой машине, а нагрузка моделируется с других машин. В зависимости от протокола сценариев VUser и технических характеристик машины для полного моделирования может потребоваться несколько инжекторов нагрузки. Например, пользователям VUser для сценария HTTP потребуется 2–4 МБ на каждого пользователя VUser для моделирования, следовательно, для моделирования нагрузки в 4 4 пользователей VUser потребуются 10,000 машины с XNUMX ГБ ОЗУ каждая.

Проведя аналогию из нашего Amazon Например, на выходе этого компонента находятся 5000 виртуальных пользователей, распределенных между двумя инжекторами: 2500 виртуальных пользователей, сгенерированных на машине A, и 2500 на машине B.

Анализ

После выполнения сценариев нагрузки роль Анализ Вступает в действие компонент LoadRunner.

Во время выполнения контроллер создает дамп результатов в необработанном виде и содержит информацию, например, какая версия LoadRunner создала этот дамп результатов и какие были конфигурации.

Все ошибки и исключения записываются в Microsoft Для доступа к базе данных используется файл output.mdb. Компонент анализа считывает этот файл базы данных для выполнения различных типов анализа и генерации графиков.

На этих графиках показаны различные тенденции, позволяющие понять причины ошибок и сбоев под нагрузкой; таким образом, помогите определить, требуется ли оптимизация в SUL, сервере (например, JBoss, Oracle) или инфраструктура.

Ниже приведён пример, где пропускная способность может создавать узкое место. Допустим, веб-сервер имеет пропускную способность 1 Гбит/с, а трафик данных превышает эту пропускную способность, что приводит к проблемам для последующих пользователей. Чтобы определить, справляется ли система с такими потребностями, инженеру по производительности необходимо проанализировать поведение приложения при ненормальной нагрузке. Ниже приведён график, сгенерированный LoadRunner для оценки пропускной способности.

График анализа LoadRunner, показывающий пропускную способность как узкое место в производительности.

Как проводить тестирование производительности

План тестирования производительности можно условно разделить на 5 этапов, которые суммированы в приведенной ниже схеме:

  1. Планирование нагрузочного теста
  2. Создание скриптов VuGen
  3. Создание сценария
  4. Выполнение сценария
  5. Анализ результатов (с последующей настройкой системы)

После установки LoadRunner давайте пошагово разберем этапы этого процесса.

Пятиэтапная дорожная карта тестирования производительности: от планирования до анализа результатов.

Шаг 1) Планирование нагрузочного теста

Планирование тестирования производительности отличается от планирования SIT (системное интеграционное тестирование) or UAT (приемочное тестирование пользователей). Планирование можно разделить на небольшие этапы, как описано ниже:

Соберите свою команду

Приступая к тестированию с помощью LoadRunner, рекомендуется задокументировать, кто из каждой команды будет участвовать в процессе, как показано на приведенной ниже схеме команд.

Состав команды по тестированию производительности LoadRunner.

  • Руководитель проекта: Назначьте менеджера проекта, который будет отвечать за это действие и выступать в качестве ответственного лица для эскалации.
  • Функциональный эксперт / Бизнес-аналитик: Предоставляет анализ использования SUL и экспертные знания о функциональности веб-сайта или SUL для бизнеса.
  • Эксперт по тестированию производительности: Создает автоматизированные тесты производительности и выполняет сценарии нагрузочного тестирования.
  • Система ArchiТект: Представляет собой план создания SUL.
  • Веб-разработчик и малый и средний бизнес: Обеспечивает поддержку веб-сайта, осуществляет мониторинг, занимается разработкой веб-сайта и исправлением ошибок.
  • Системный администратор: Обеспечивает бесперебойную работу задействованных серверов на протяжении всего проекта тестирования.

Опишите задействованные приложения и бизнес-процессы.

Успешных испытание нагрузкой требует, чтобы вы планировали выполнить определенный бизнес-процесс. Бизнес-процесс состоит из четко определенных шагов, соответствующих желаемым бизнес-транзакциям, для достижения ваших целей нагрузочного тестирования.

Метрика требований может быть подготовлена ​​для выявления пользовательской нагрузки на систему. Ниже приведен пример системы посещаемости в компании:

Карта метрик требованийping количество пользователей на каждый бизнес-процесс в течение каждого часа дня

В приведенном выше примере цифры указывают количество пользователей, подключенных к приложению (SUL) в заданный час. Мы можем продемонстрировать...tract — максимальное количество пользователей, подключенных к бизнес-процессу в любой час суток, которое рассчитывается в крайних правых столбцах.

Аналогичным образом мы можем сделать вывод об общем количестве пользователей, подключенных к приложению (SUL) в любой час суток. Это рассчитывается в последней строке.

В совокупности два вышеуказанных факта дают нам общее количество пользователей, с которыми нам необходимо протестировать систему на производительность.

Определить процедуры управления тестовыми данными

На статистику и наблюдения, полученные в ходе тестирования производительности, сильно влияют многочисленные факторы, о которых говорилось ранее. Крайне важно подготовить тестовые данные для тестирования производительности. Иногда определенный бизнес-процесс использует набор данных и создает другой набор данных. Возьмите пример ниже:

  • Пользователь «А» создает финансовую конверсию.tracи отправляет его на рассмотрение.
  • Другой пользователь 'B' одобряет 200 сообщений.tracЭто день, созданный пользователем 'A'.
  • Другой пользователь, «С», платит около 150 конс.tracЭто одобрено пользователем 'B' в течение дня.

В этой ситуации пользователю B необходимо иметь 200 очков связи.tracts «создано» в системе. Кроме того, пользователю C требуется 150 contracЭто обозначено как «одобрено» для имитации нагрузки в 150 пользователей.

Это подразумевает, что вам необходимо создать как минимум 200 + 150 = 350 объектов.tracц.

После этого утвердить 150 контрактов.tracts послужат тестовыми данными для пользователя C – оставшиеся 200 contracЭти данные будут использованы в качестве тестовых данных для пользователя B.

Контурные мониторы

Проанализируйте все факторы, которые могут повлиять на производительность системы. Например, уменьшение количества аппаратных средств может оказать влияние на производительность системы под нагрузкой (SUL).

Учитывайте все факторы и настройте мониторы, чтобы вы могли их оценить. Вот несколько примеров:

  • Процессор (для веб-сервера, сервера приложений, сервера базы данных и инжекторов)
  • ОЗУ (для веб-сервера, сервера приложений, сервера базы данных и инжекторов)
  • Веб-сервер/сервер приложений (например, IIS, JBoss, Jaguar Server, Tomcat и т. д.)
  • Сервер БД (размер PGA и SGA в случае Oracle и MSSQL Server, SP и т. д.)
  • Использование пропускной способности сети
  • Внутренний и внешний сетевой адаптер в случае кластеризации
  • Load Balancer (и что он равномерно распределяет нагрузку на все узлы кластеров)
  • Данные flux (Рассчитайте объем данных, передаваемых между клиентом и сервером, а затем определите, достаточно ли пропускной способности сетевой карты для имитации определенного количества пользователей).

Шаг 2) Создайте скрипты VuGen.

Следующий шаг после планирования — создание скриптов для виртуальных пользователей и их добавление. параметризация, транзакции и настройки времени выполнения по мере развития сценария.

Шаг 3) Создание сценария

Следующий шаг — создание сценария загрузки в контроллере, с выбором между ручным и целевым сценарием.

Шаг 4) Выполнение сценария

При выполнении сценария вы эмулируете пользовательскую нагрузку на сервер, поручая нескольким пользователям VUser выполнять задачи одновременно.

Вы можете задавать уровень нагрузки, увеличивая и уменьшая количество пользователей VUser, одновременно выполняющих задачи.

Выполнение этой операции может привести к сбою сервера. напряжение и вести себя ненормально. В этом и заключается цель тестирования производительности. Полученные результаты затем используются для детального анализа и выявления первопричин.

Шаг 5) Анализ результатов (с последующей настройкой системы)

В процессе выполнения сценария LoadRunner записывает производительность приложения при различных нагрузках. Полученная статистика сохраняется, и проводится подробный анализ. Инструмент анализа (в версиях, для которых было написано это руководство, он называется «HP Analysis») генерирует различные графики, которые помогают выявить первопричины замедления работы системы, а также сбоев в системе.

Некоторые из полученных графиков включают в себя:

  • Время до первого буфера
  • Время ответа транзакции
  • Среднее время ответа транзакции
  • Хиты в секунду
  • Windows Ресурсы
  • Статистика ошибок
  • Сводка транзакций

Часто задаваемые вопросы (FAQ)

Тестирование производительности ориентировано на клиент-серверные многопользовательские системы. Для этого используется автономная настольная утилита, например, Microsoft Калькулятор обслуживает одного пользователя и не имеет серверного уровня, поэтому он не подходит для тестирования производительности.

Тестирование производительности измеряет и сообщает о поведении приложения под нагрузкой. Инженерия производительности сочетает это тестирование с настройкой, поэтому система измеряется и оптимизируется одновременно до тех пор, пока не будет достигнут требуемый пользовательский опыт.

№ OpenText В январе 2023 года завершилось приобретение компании Micro Focus, и теперь семейство компаний продано. OpenText Профессиональное, корпоративное и базовое проектирование производительности.

Версия Professional подходит для одной команды на одном компьютере, Enterprise добавляет возможность совместного тестирования на основе проектов в рамках всей организации, а Core запускает генерацию нагрузки в облаке без локальных инжекторов.

Разделите целевое количество виртуальных пользователей на объем памяти, занимаемый протоколом. В приведенном выше примере с HTTP 2-4 МБ на одного виртуального пользователя означает, что примерно четыре машины с 4 ГБ оперативной памяти обрабатывают 10 000 виртуальных пользователей.

Подмена IP-адреса позволяет каждому виртуальному пользователю получить уникальный исходный адрес, поэтому балансировщики нагрузки, кэши и серверы обрабатывают имитируемый трафик как множество отдельных клиентов, а не как одну перегружающую машину.

Машинное обучение определяет базовые значения нормального времени отклика, автоматически выявляет аномальные запуски и группирует связанные ошибки, благодаря чему инженеры тратят меньше времени на анализ графиков и больше времени на устранение первопричины проблемы.

Copilot Создает вспомогательный код VuGen в стиле C и логику параметризации, но не может знать ваши записанные значения корреляции, поэтому каждый сгенерированный скрипт по-прежнему нуждается в проверке воспроизведения.

Подведем итог этой публикации следующим образом: