Что такое LoadRunner?
LOADRUNNER — это инструмент для тестирования производительности, впервые разработанный Mercury в 1999 году. Позже LoadRunner была приобретена HPE в 2006 году. В 2016 году Loadrunner была приобретена MicroFocus.
LoadRunner поддерживает различные инструменты разработки, технологии и протоколы связи. Фактически, это единственный инструмент на рынке, который поддерживает такое большое количество протоколов для проведения тестирования производительности. Результаты теста производительности, полученные Loadrunner, используются в качестве эталона по сравнению с другими инструментами
В этом уроке вы узнаете
- Почему именно LoadRunner?
- Зачем вам нужно тестирование производительности?
- Что такое архитектура LoadRunner?
- План тестирования производительности: подробные шаги
- Часто задаваемые вопросы
Почему именно LoadRunner?
LoadRunner является не только пионерским инструментом в тестировании производительности, но и лидером в парадигме тестирования производительности. По последним оценкам, LoadRunner занимает около 85% рынка в индустрии тестирования производительности.
В целом, LoadRunner поддерживает RIA (многофункциональные интернет-приложения), 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, такими как Унифицированный функциональный тест (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 миллионов долларов в год.
По оценкам, только 5-минутное время простоя Google.com (19 августа-13) обойдется поисковому гиганту в 545 000 долларов.
По оценкам, из-за недавнего перерыва в работе Amazon Web Service компании теряли продажи на 1100 долларов в секунду.
Когда организация развертывает программную систему, она может столкнуться со многими сценариями, которые могут привести к задержке производительности. Ряд факторов вызывают снижение производительности, несколько примеров могут включать в себя:
- Увеличено количество записей в базе данных
- Увеличено количество одновременных запросов к системе
- большее количество пользователей, обращающихся к системе одновременно, по сравнению с прошлым
Что такое архитектура LoadRunner?
Вообще говоря, архитектура LoadRunner сложна, но проста для понимания.
Предположим, вам поручено проверить производительность Amazon.com для 5000 пользователей.
В реальной ситуации все эти 5000 пользователей будут находиться не на домашней странице, а в другом разделе веб-сайтов. Как мы можем моделировать по-другому
VuGen:
VUGen или Virtual User Generator — это интегрированная среда разработки (IDE) или многофункциональный редактор кода. VUGen используется для репликации поведения системы под нагрузкой (SUL). VUGen предоставляет функцию «записи», которая записывает связь между клиентом и сервером в виде кодированного сценария, также называемого сценарием VUser.
Поэтому, учитывая приведенный выше пример, VUGen может записывать для имитации следующих бизнес-процессов:
- Серфинг на странице товаров Amazon.com
- Проверять, выписываться
- Процесс оплаты
- Проверка страницы моего аккаунта
контроллер
После завершения сценария VUser контроллер становится основным компонентом, который управляет моделированием нагрузки с помощью управления, например:
- Сколько VUser для моделирования против каждого бизнес-процесса или VUser Group
- Поведение VUsers (наращивание, замедление, одновременный или одновременный характер и т. Д.)
- Сценарий «Природа нагрузки», например, «Реальная жизнь» или «Ориентация на цель» или проверка SLA
- Какие инжекторы использовать, сколько VUsers против каждого инжектора
- Периодически сопоставлять результаты
- IP-спуфинг
- Отчет об ошибках
- Отчет о транзакциях и т. Д.
Взяв аналогию из нашего примера контроллера, мы добавим следующий параметр в скрипт VUGen.
1) 3500 пользователей работают на странице продуктов Amazon.com
2) 750 пользователей в кассе
3) 500 пользователей выполняют обработку платежей
4) 250 пользователей проверяют страницу MyAccount ТОЛЬКО после того, как 500 пользователей выполнили обработку платежа
Возможны даже более сложные сценарии
- Инициируйте 5 VUsers каждые 2 секунды, пока не будет достигнута нагрузка 3500 VUsers (страница продукта Amazon для серфинга).
- Итерация 30 минут
- Приостановить итерацию для 25 пользователей
- Перезапустить 20 VUSers
- Инициируйте 2 пользователей (на странице «Оформление заказа», «Обработка платежей», «Моя учетная запись») каждую секунду.
- 2500 машин будут сгенерированы на машине A
- 2500 машин будут сгенерированы на машине B
Агенты машины / генераторы нагрузки / инжекторы
LoadRunner Controller отвечает за моделирование тысяч VUsers — эти VUser потребляют аппаратные ресурсы, например процессор и память, — следовательно, накладывают ограничение на компьютер, который имитирует их. Кроме того, Controller имитирует эти VUsers с той же машины (где находится Controller) и, следовательно, результаты могут быть неточными. Чтобы решить эту проблему, все VUsers распределены по различным машинам, которые называются Load Generators или Load Injectors.
Как правило, контроллер находится на другом компьютере, а нагрузка моделируется с других компьютеров. В зависимости от протокола сценариев VUser и технических характеристик машины, для полной симуляции может потребоваться несколько инжекторов нагрузки. Например, VUsers для HTTP-скрипта потребует 2-4 МБ на VUser для моделирования, следовательно, для моделирования нагрузки в 10 000 VUsers потребуется 4 машины с 4 ГБ ОЗУ каждый.
Если взять аналогию из нашего примера с Amazon, выход этого компонента будет
Анализ:
После выполнения сценариев загрузки появляется роль компонента « Анализ ».
Во время выполнения Controller создает дамп результатов в необработанном виде и содержит информацию о том, какая версия LoadRunner создала этот дамп результатов и какие конфигурации были.
Все ошибки и исключения регистрируются в базе данных Microsoft Access с именем output.mdb. Компонент «Анализ» считывает этот файл базы данных для выполнения различных видов анализа и создает графики.
Эти графики показывают различные тенденции, чтобы понять причины ошибок и отказов под нагрузкой; таким образом, помогите понять, требуется ли оптимизация в SUL, Server (например, JBoss, Oracle) или инфраструктуре.
Ниже приведен пример, где пропускная способность может создавать узкое место. Допустим, веб-сервер имеет пропускную способность 1 Гбит / с, тогда как трафик данных превышает эту емкость, в результате чего пострадают последующие пользователи. Чтобы определить, удовлетворяет ли система таким потребностям, Performance Engineer необходимо проанализировать поведение приложения с ненормальной нагрузкой. Ниже приведен график, который LoadRunner генерирует для определения пропускной способности.
План тестирования производительности: подробные шаги
План тестирования производительности можно разделить на 5 этапов:
- Планирование нагрузочного теста
- Создание VUGen-скриптов
- Создание сценария
- Сценарий исполнения
- Анализ результатов (с последующей настройкой системы)
Теперь, когда вы установили LoadRunner, давайте разберемся с шагами, участвующими в процессе.
Шаги, вовлеченные в процесс тестирования производительности
Планирование нагрузочного теста
Планирование тестирования производительности отличается от планирования SIT (тестирование системной интеграции) или UAT (приемочное тестирование пользователя). Планирование может быть далее разделено на небольшие этапы, как описано ниже:
Собери свою команду
Приступая к тестированию производительности, лучше всего задокументировать, кто будет участвовать в задании от каждой команды, участвующей в процессе.
Руководитель проекта:
Назначьте менеджера проекта, который будет владеть этим видом деятельности и выступать в роли ответственного за эскалацию.
Функция Эксперт / Бизнес-аналитик:
Обеспечить анализ использования SUL и предоставить экспертные знания о бизнес-функциональности веб-сайта / SUL
Эксперт по тестированию производительности:
Создает автоматизированные тесты производительности и выполняет сценарии загрузки
Системный архитектор:
Обеспечивает проект SUL
Веб-разработчик и МСП:
- Поддерживает веб-сайт и обеспечивает мониторинг
- Разрабатывает сайт и исправляет ошибки
Системный администратор:
- Поддерживает задействованные серверы в течение всего проекта тестирования
Наброски приложений и бизнес-процессов участвуют:
Успешное нагрузочное тестирование требует, чтобы вы планировали выполнить определенный бизнес-процесс. Бизнес-процесс состоит из четко определенных шагов в соответствии с желаемыми бизнес-транзакциями, чтобы выполнить ваши задачи нагрузочного тестирования.
Метрика требований может быть подготовлена, чтобы вызвать пользовательскую нагрузку на систему. Ниже приведен пример системы посещаемости в компании:
В приведенном выше примере на рисунках указано количество пользователей, подключенных к приложению (SUL) в данный час. Мы можем извлечь максимальное количество пользователей, подключенных к бизнес-процессу, в любой час дня, которое рассчитывается в крайних правых столбцах.
Точно так же мы можем определить общее количество пользователей, подключенных к приложению (SUL), в любое время суток. Это рассчитывается в последнем ряду.
Вышеупомянутые 2 факта вместе дают нам общее количество пользователей, с которыми нам нужно протестировать систему на производительность.
Определить процедуры управления тестовыми данными
Статистические данные и наблюдения, полученные в результате тестирования производительности, в значительной степени зависят от множества факторов, о которых сообщалось ранее. Крайне важно подготовить тестовые данные для тестирования производительности. Иногда конкретный бизнес-процесс использует набор данных и создает другой набор данных. Возьмите пример ниже:
- Пользователь «А» создает финансовый контракт и представляет его на рассмотрение.
- Другой пользователь «B» утверждает 200 контрактов в день, созданных пользователем «A»
- Другой пользователь «C» платит около 150 контрактов в день, утвержденных пользователем «B»
В этой ситуации пользователю B необходимо создать 200 контрактов в системе. Кроме того, пользователю C необходимо 150 утвержденных контрактов, чтобы имитировать нагрузку 150 пользователей.
Это подразумевает, что вы должны создать не менее 200 + 150 = 350 контрактов.
После этого утвердите 150 контрактов, которые будут служить Тестовыми данными для Пользователя C — остальные 200 контрактов будут служить Тестовыми данными для Пользователя B.
Контурные мониторы
Определите каждый фактор, который может повлиять на производительность системы. Например, сокращение аппаратного обеспечения может оказать влияние на производительность SUL (System Under Load).
Перечислите все факторы и настройте мониторы, чтобы вы могли их оценить. Вот несколько примеров:
- Процессор (для веб-сервера, сервера приложений, сервера базы данных и инжекторов)
- ОЗУ (для веб-сервера, сервера приложений, сервера базы данных и инжекторов)
- Веб / сервер приложений (например, IIS, JBoss, Jaguar Server, Tomcat и т. Д.)
- Сервер БД (размер PGA и SGA в случае Oracle и MSSQL Server, SP и т. Д.)
- Использование полосы пропускания сети
- Внутренний и внешний сетевой адаптер в случае кластеризации
- Балансировщик нагрузки (и равномерное распределение нагрузки по всем узлам кластеров)
- Поток данных (рассчитайте, сколько данных перемещается к клиенту и серверу и обратно, а затем рассчитайте, достаточна ли пропускная способность сетевого адаптера для имитации количества пользователей X)
Создание VUGen-скриптов
Следующим шагом после планирования является создание скриптов VUser.
Создание сценария
Следующим шагом является создание сценария загрузки.
Сценарий исполнения
Выполнение сценария — это то, где вы эмулируете пользовательскую нагрузку на сервер, инструктируя несколько VUsers для одновременного выполнения задач.
Вы можете установить уровень нагрузки, увеличивая и уменьшая количество пользователей VU, которые выполняют задачи одновременно.
Это выполнение может привести к тому, что сервер будет загружен и работает ненормально. Это и есть цель тестирования производительности. Полученные результаты затем используются для детального анализа и выявления первопричин.
Анализ результатов (с последующей настройкой системы)
Во время выполнения сценария LoadRunner записывает производительность приложения при различных нагрузках. Статистика, полученная в результате выполнения теста, сохраняется и выполняется подробный анализ. Инструмент «Анализ HP» генерирует различные графики, которые помогают определить основные причины отставания производительности системы, а также сбоя системы.
Некоторые из полученных графиков включают в себя:
- Время до первого буфера
- Время ответа транзакции
- Среднее время ответа транзакции
- Хиты в секунду
- Ресурсы Windows
- Статистика ошибок
- Сводка транзакций
Часто задаваемые вопросы
Какие приложения мы должны тестировать производительность?
Тестирование производительности всегда выполняется только для клиент-серверных систем. Это означает, что любое приложение, которое не является архитектурой клиент-сервер, не должно требовать тестирования производительности.
Например, Microsoft Calculator не основан ни на клиент-сервер, ни на нескольких пользователях; следовательно, он не является кандидатом на тестирование производительности.
В чем разница между тестированием производительности и проектированием производительности
Важно понимать разницу между тестированием производительности и проектированием производительности. Понимание дается ниже:
Тестирование производительности — это дисциплина, связанная с тестированием и составлением отчетов о текущей производительности программного приложения при различных параметрах.
Проектирование производительности — это процесс, с помощью которого программное обеспечение тестируется и настраивается с целью достижения требуемой производительности. Этот процесс направлен на оптимизацию наиболее важной характеристики производительности приложения, то есть взаимодействия с пользователем.
Исторически тестирование и настройка были совершенно разными и часто конкурирующими сферами. Однако в последние несколько лет несколько карманов тестировщиков и разработчиков сотрудничали независимо друг от друга, создавая команды по настройке. Поскольку эти команды добились значительного успеха, концепция сочетания тестирования производительности с настройкой производительности завоевала популярность, и теперь мы называем это проектированием производительности.