Что такое средство тестирования HP LoadRunner? Архитектура, Компоненты

Что такое LoadRunner?

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

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

В этом руководстве вы узнаете:

• Почему именно LoadRunner?
• Зачем вам нужно тестирование производительности?
• Что такое архитектура LoadRunner?
• Дорожная карта тестирования производительности: подробные шаги
• Часто задаваемые вопросы

Почему именно LoadRunner?

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

В широком смысле инструмент LoadRunner поддерживает RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex и Silverlight и т. Д.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail и, прежде всего, Windows Socket. На рынке нет конкурирующего инструмента, который мог бы предложить такое большое разнообразие протоколов, заключенных в одном инструменте.

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

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

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

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

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

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

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

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

Подсчитано, что компании потеряли продажи на 1100 долларов в секунду из-за недавнего сбоя Amazon Web Service.

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

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

Что такое архитектура LoadRunner?

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

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

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

ВУГЕН:

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

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

1. Просмотр страницы продуктов на Amazon.com
2. Проверить
3. Процесс оплаты
4. Проверка страницы MyAccount

Контроллер

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

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

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

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

2) 750 пользователей сейчас на кассе

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

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

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

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

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

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

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

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

Анализ:

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

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

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

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

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

Дорожная карта тестирования производительности: подробные шаги

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

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

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

Этапы процесса тестирования производительности

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

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

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

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

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

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

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

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

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

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

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

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

Веб-разработчик и МСП:

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

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

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

Обрисовать в общих чертах используемые приложения и бизнес-процессы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создать скрипты VUGen

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

Создание сценария

Следующим шагом будет создание сценария нагрузки.

Выполнение сценария

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

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

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

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

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

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

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

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

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

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

Например, Microsoft Calculator не является клиент-серверным и не запускает несколько пользователей; следовательно, он не подходит для тестирования производительности.

В чем разница между тестированием производительности и проектированием производительности

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

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

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

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