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

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

Тестируя приложение на производительность, что именно мы проверяем? В этом случае мы тестируем приложение на нагрузку, объём, ёмкость, стресс и другие параметры.

Что такое нагрузочное тестирование?

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

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

Пример: допустим, требование клиента для страницы входа в систему — отклик в пределах 2-5 секунд, и эти 2-5 секунд должны оставаться стабильными при нагрузке до 5000 пользователей. Что же мы должны здесь наблюдать? Только ли способность системы справляться с нагрузкой или только ли требование времени отклика?

Ответ — оба параметра. Нам нужна система, способная обрабатывать нагрузку в 5000 пользователей со временем отклика 2-5 секунд для всех одновременно работающих пользователей.

Что подразумевается под одновременными и виртуальными пользователями?

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

Архитектура нагрузочного тестирования

На схеме ниже мы видим, как различные пользователи получают доступ к приложению. Здесь каждый пользователь отправляет запрос через интернет, который затем проходит через межсетевой экран (firewall).

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

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

Пример: допустим, мы хотим протестировать онлайн-приложение для покупок, чтобы увидеть время отклика приложения на каждый клик пользователя. То есть Шаг1 — запуск URL, замер времени отклика, вход в приложение и замер времени отклика, затем выбор продукта, добавление в корзину, оплата и выход из системы. Все эти шаги нужно выполнить для 10 пользователей.

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

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

Если у нас есть бюджет, то мы можем использовать коммерческие инструменты, такие как Load runner, но если бюджет ограничен, можно воспользоваться инструментами с открытым исходным кодом, такими как JMeter и т. д.

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

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

На схеме ниже показано, как пользователи заменяются с помощью инструмента.

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

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

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

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

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

• Нагрузочное тестирование помогает создавать надёжные и стабильные системы.

• Узкие места в системе выявляются заранее, ещё до того, как приложение выходит в эксплуатацию.

• Нагрузочное тестирование также помогает определить ёмкость приложения.

Что достигается в ходе нагрузочного тестирования?

Правильно проведённое нагрузочное тестирование позволяет точно понять следующее:

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

2. Время отклика каждой транзакции.

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

4. Какая конфигурация сервера лучше всего справляется с нагрузкой.

5. Достаточно ли текущего оборудования или требуется дополнительное.

6. Узкие места, такие как использование процессора и памяти, задержки в сети и так далее.

Среда

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

Существуют разные тестовые среды, такие как среда SIT (системное интеграционное тестирование), среда QA и прочие — они не похожи на производственную среду, потому что в отличие от нагрузочного тестирования, для функционального или интеграционного тестирования не требуется столько серверов или тестовых данных.

Пример:

В производственной среде у нас есть 3 сервера приложений, 2 веб-сервера и 2 сервера баз данных. В QA-среде у нас только 1 сервер приложений, 1 веб-сервер и 1 сервер баз данных. Следовательно, если мы проводим нагрузочное тестирование в среде QA, которая не эквивалентна производственной среде, то наши тесты будут недействительными и некорректными, и результаты таких тестов не могут быть использованы.

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

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

Старайтесь делать снимок (snapshot) среды, когда она настроена, чтобы в случае необходимости перестроить среду вы могли использовать этот снимок, что сэкономит время. На рынке существует несколько инструментов для создания среды, например — Puppet, Docker и другие.

Подход

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

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

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

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

Наш подход к нагрузочному тестированию будет следующим:

1) Определение критериев приемки нагрузочного теста

Например:

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

2. Загрузка процессора не должна превышать 80%

3. Пропускная способность системы должна составлять 100 транзакций в секунду.

2) Определение бизнес-сценариев, которые необходимо протестировать

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

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

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

3) Моделирование рабочей нагрузки

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

При проектировании модели рабочей нагрузки необходимо помнить про время, которое потребуется для выполнения конкретного бизнес-процесса. Здесь важно правильно задать время на раздумья (think time), чтобы пользователь перемещался по приложению наиболее реалистичным образом.

Паттерн рабочей нагрузки обычно включает этапы увеличения нагрузки (Ramp up), уменьшения нагрузки (Ramp down) и стабильного состояния. Систему нагружать нужно медленно, поэтому используются темпы Ramp up и Ramp down. Стабильное состояние обычно представляет собой часовой нагрузочный тест с 15-минутным Ramp up и 15-минутным Ramp down.

Рассмотрим пример модели рабочей нагрузки:

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

Чтобы просмотреть подробную информацию о каждом товаре, пользователю нужно кликнуть на него. Если его устраивает цена и внешний вид товара, он может добавить его в корзину и купить, завершив процесс оплаты.

Ниже приведён список сценариев:

1. Просмотр — на этом этапе пользователь заходит в приложение, просматривает различные категории и выходит из приложения.

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

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

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

Приведённые выше значения были рассчитаны на основе следующих вычислений:

• Транзакции в час = Количество пользователей * Транзакции, совершаемые одним пользователем за один час.

• Количество пользователей = 1600.

• Общее количество транзакций в сценарии «Просмотр» = 17.

• Время отклика для каждой транзакции = 3.

• Общее время выполнения 17 транзакций одним пользователем = 17*3 = 51, округленное до 60 сек (1 мин).

• Транзакции в час = 1600*60 = 96000 транзакций.

4) Разработка нагрузочных тестов — нагрузочные тесты должны быть разработаны с учётом данных, которые мы собрали до сих пор — бизнес-процессы, количество пользователей, пользовательские паттерны, а также метрики, которые необходимо собрать и проанализировать. Кроме того, тесты должны быть максимально приближены к реальности.

5) Выполнение нагрузочного теста — перед запуском нагрузочного теста убедитесь, что приложение запущено и работает. Среда для нагрузочного тестирования готова. Приложение протестировано с функциональной точки зрения и стабильно.

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

Всегда начинайте с небольшой нагрузки и постепенно её увеличивайте. Никогда не начинайте с полной нагрузки, чтобы не нарушить работу системы.

6) Анализ результатов нагрузочного тестирования — имейте в своём распоряжении базовый тест, чтобы всегда можно было сравнить с ним другие. Соберите метрики и логи сервера после выполнения теста, чтобы выявить узкие места.

Некоторые проекты используют инструменты мониторинга производительности приложений (Application Performance Monitoring, APM) для мониторинга системы во время прогона тестов. Эти инструменты помогают легче выявить первопричину и сэкономить много времени. APM-инструменты предоставляют широкий обзор, позволяя точно определить, где находится проблема.

Некоторые из APM-инструментов, представленных на рынке, включают DynaTrace, Wily Introscope, App Dynamics и другие.

7) Отчётность — после завершения тестирования соберите все метрики и отправьте сводный отчёт с итогами тестирования соответствующей команде с вашими замечаниями и рекомендациями.

Лучшие практики

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

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

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

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

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

• Собирайте все важные метрики, такие как время отклика, количество запросов в секунду, пропускная способность, использование процессора, памяти, сети, и количество работающих виртуальных пользователей (Vusers).

Читать ещё: Как я масштабировал генератор нагрузки Amazon для работы на 1000 машин.

Всех, кому интересна тема нагрузочного тестирования, приглашаем на ближайшие открытые уроки:

• 11 сентября: «Прохождение собеседования на нагрузочного тестировщика. Что интересует работодателя?». Записаться

• 18 сентября: «Стенды для нагрузочного тестирования: типы, особенности, основные цели и выбор». Записаться