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

Что такое LoadRunner?

LoadRunner — это инструмент тестирования производительности, впервые разработанный Mercury в 1999 году. Позднее, в 2006 году, LoadRunner была приобретена компанией HPE. В 2016 году LoadRunner была приобретена компанией MicroFocus.

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

Видео о LoadRunner

Почему LoadRunner?

LoadRunner Это не только новаторский инструмент в тестировании производительности, но и по-прежнему лидер рынка в парадигме тестирования производительности. По недавним оценкам, доля LoadRunner составляет около 85% рынка в отрасли тестирования производительности.

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

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

Программное обеспечение LoadRunner тесно интегрировано с другими инструментами HP, такими как Unified Functional Test (QTP) и ALM (управление жизненным циклом приложений), что позволяет вам выполнять комплексные процессы тестирования.

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

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

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

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

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

По оценкам, всего лишь 5-минутный простой Google.com (19 августа 13 г.) обойдется поисковому гиганту в 545,000 XNUMX долларов.

По оценкам, из-за недавнего кризиса компании потеряли продажи на сумму 1100 долларов в секунду. Amazon Сбой веб-службы.

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

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

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

Вообще говоря, архитектура HP LoadRunner сложна, но ее легко понять.

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

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

ВУГен

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

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

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

Контроллер

После завершения сценария VUser Controller становится одним из основных компонентов LoadRunner, который управляет симуляцией загрузки, управляя, например:

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

Если провести аналогию с нашим примером контроллера, в скрипт VUGen будет добавлен следующий параметр:

1) 3500 пользователей Просмотр страницы продуктов Amazon.com

2) 750 пользователей находятся в Оформление заказа

3) 500 пользователей выполнение обработки платежей

4) 250 пользователей Проверка страницы «Моя учетная запись» ТОЛЬКО после того, как 500 пользователей выполнили обработку платежей.

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

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

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

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

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

Проведя аналогию с нашим Amazon Например, выходные данные этого компонента будут

Анализ

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

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

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

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

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

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

Дорожную карту тестирования производительности можно разделить на 5 этапов:

• Планирование нагрузочного теста
• Создание сценариев VUGen
• Создание сценария
• Выполнение сценария
• Анализ результатов (с последующей настройкой системы)

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

Шаги, связанные с процессом тестирования производительности

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

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

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

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

Руководитель проекта:

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

Функциональный эксперт/бизнес-аналитик:

Обеспечивает анализ использования SUL и предоставляет экспертные знания по бизнес-функциональности веб-сайта/SUL.

Эксперт по тестированию производительности:

Создает автоматизированные тесты производительности и выполняет сценарии нагрузки.

Система ArchiТект:

Предоставляет план SUL.

Веб-разработчик и малый и средний бизнес:

• Поддерживает веб-сайт и обеспечивает мониторинг
• Разрабатывает сайт и исправляет ошибки

Системный администратор:

• Поддерживает задействованные серверы на протяжении всего проекта тестирования.

Краткое описание приложений и задействованных бизнес-процессов:

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

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

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

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

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

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

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

• Пользователь «А» создает финансовый контракт и отправляет его на рассмотрение.
• Другой пользователь «Б» утверждает 200 контрактов в день, созданных пользователем «А».
• Другой пользователь «С» оплачивает около 150 контрактов в день, одобренных пользователем «Б».

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

Это неявно означает, что вы должны создать как минимум 200+150= 350 контрактов.

После этого утвердите 150 контрактов, которые будут служить тестовыми данными для пользователя C, а остальные 200 контрактов будут служить тестовыми данными для пользователя B.

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

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

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

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

Шаг 2) Создайте сценарии VUGen

Следующим шагом после планирования является создание VUser-скрипты.

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

Следующий шаг — создать сценарий загрузки.

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

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

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

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

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

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

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

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

FAQ