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

• Суть
• Пример из жизни
• Этапы
• Метрики
• Процесс в одной картинке
• Инструменты
• Лучшие практики
• И еще несколько советов
• Преимущества и недостатки

Кратко

Тестирование производительности, при котором имитируется реальная нагрузка на систему (приложение) и проверяется ее поведение (производительность). Цель состоит в поиске проблем и узких мест — чаще всего это идентификация максимального количества пользователей (транзакций), которое система может принять и обработать. Применяются стандартные инструменты тестирования производительности, в первую очередь Apache JMeter (стандарт), LoadRunner, Gatling, и Grinder. Инструменты генерируют большое количество одновременных запросов (виртуальных пользователей) и измеряют производительность системы в числовых метриках: время ответа, пропускная способность, количество возникающих ошибок, и другие. После этого руководство проекта, принимая во внимание результаты тестирования, планирует изменения в системе.

Пример из жизни 

Нужность нагрузочного тестирования становится понятна на примере. Мужчина решил отказаться от вредных привычек, заняться спортом, пошел в тренажерный зал, и тренер хочет оценить его возможности. Тренер приводит его к штанге и постепенно добавляет блины, следя за состоянием организма, таким образом определяя максимально допустимый вес для этого человека. Если «нагрузочное тестирование спортсмена» не проведено — он не будет знать свои возможности, и не сможет тренироваться с максимальной эффективностью. Также и с приложениями и веб-сайтами. Им нужно нагрузочное тестирование, чтобы понять, когда приложение (сайт) может упасть, не выдержав нагрузки, а под какой нагрузкой приложение может работать неограниченно долго. Нужно определить: система легко нагружена, или она уже на пределе своих возможностей? Могут случаться неприятности в самый неожиданный момент, грозящие убытками. Кроме того, нагрузочное тестирование позволяет определить «спящие баги» и ситуации при которых теоретически возможен сбой, делая это до того как финальный продукт отправят заказчику.

По данным компании Gartner, в среднем убытки от простоя (из-за перегрузки) в крупных компаниях составляют около 5000-6000 долларов В МИНУТУ, или 300 000 долларов в час. Для маленькой компании убытки, разумеется, будут намного меньшими, но тоже болезненными. Простой из-за отказов серверов, как правило, случается из-за превышения количества одновременных пользователей, на которое архитекторы системы не рассчитывали, проектируя ИТ-систему.

Нагрузочное тестирование — это о рисках. Риски временной потери функциональности продукта — это риски потери хорошего отношения пользователей, то есть вред репутации ИТ-компании. 

Этапы

На более простых проектах процесс нагрузочного тестирования состоит из таких этапов (стандартных для тестирования производительности):

1. Настройка тестового окружения: важный этап, требующий внимательного подхода и времени
2. Подготовка тестовых сценариев: подбор и написание тестовых сценариев, релевантных в данном проекте; тщательно выбирается количество одновременных пользователей/транзакций
3. Выполнение сценариев, то есть собственно тестирование; в процессе собираются релевантные метрики нагрузочного тестирования
4. Анализ результатов и подготовка рекомендаций для руководителей проекта
5. Повторное тестирование, при необходимости (которая возникает очень часто — если тесты/сценарии упали, или оказались недостаточно показательными для оценки производительности при выбранной нагрузке

В более крупных, масштабных проектах, процесс выполняется с бОльшим вниманием к выбору тестовых метрик.

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

Метрики выбираются, исходя из особенностей проекта. Они будут нужны в тех или иных тест-кейсах. Некоторые самые важные метрики: 

1. Среднее время ответа: усредненный период времени, нужный системе на выполнение запроса, сгенерированного клиентом/пользователем. Метрика показывает некую обобщенную скорость реакции системы.
2. Количество ошибок: показатель, обозначающий процент запросов, завершенных с ошибкой, по отношению к общему количеству запросов. Ошибки возникают, если приложение становится не способно обработать запрос за нужное время из-за технических проблем. Большое количество (накопленных) ошибок делает невозможной нормальную работу с приложением.
3. Пропускная способность: метрика, оценивающая пропускную способность системы, то есть ее способность «пропустить через себя» и обработать нужное (заданное в требованиях к продукту) количество данных. Выражается в единицах информации за единицу времени — килобайтах/мегабайтах в секунду.
4. Количество запросов в секунду: сколько одновременных запросов в секунду приложение способно принять и обработать (прим. под «приложением» здесь имеется в виду сервер приложений). Запросы могут быть разноплановыми — как обычные текстовые, так и более «требовательные» — рисунки и видео, или большие сложные документы. 
5. Количество одновременных пользователей: количество пользователей, одновременно присутствующих в системе в какой-то момент времени. Отличается тем, что учитываются просто пользователи, активные в системе в момент времени, но не делающие каких-либо запросов, не выполняющие действия.
6. Максимальное время ответа: измеряет максимальное зафиксированное время, которое уходит на обработку запроса; показывает длительность цикла обработки запроса; помогает определить «узкие места» в системе.

Процесс

Инструменты нагрузочного тестирования

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

• StresStimulus
• LoadNinja
• WebLOAD
• Apache JMeter
• LoadRunner
• LoadView
• NeoLoad
• AppLoader
• RedLine13
• SilkPerformer
• Rational Performance Tester by IBM
• SmartMeter
• BlazeMeter

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

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

• Четко описать цели тестирования и систему, ее ограничения
• Понимать целевое количество пользователей и их типичное поведение
• Выбрать подходящие инструменты
• Определить узкие места и потенциальные проблемы
• Тщательный мониторинг системы во время тестирования
• Анализ всего массива полученных результатов
• Регулярность нагрузочного тестирования, обеспечивающая поддержку системы в рабочем состоянии на будущее

Несколько советов

• Подобрать адекватную нагрузку для конкретного проекта. Не слишком маленькую, и не чрезмерную сразу — а именно оптимальную рабочую
• Тщательно спланировать процесс, то есть создать тест-план, описывающий сроки, инструменты, и действия
• Хорошо настроить тестовое окружение
• При этом изолировав тестовое окружение от реального
• Возможно, есть смысл начать с тестирования «отдельных сегментов» нагрузки, затем постепенно объединяя их
• Написать адекватные тест-кейсы. «Адекватные тест-кейсы» означает адекватный объем подаваемых в приложение данных, и непревышение объема работ на день, чтобы в один день решалась какая-то одна задача
• Реалистичность тестовых сценариев, то есть их соответствие поведению реальных пользователей
• Не поднимать нагрузку слишком резко, то есть чтобы так называемое RumpUp-время, то есть период роста нагрузки, не был слишком коротким. В противном случае это уже будет стресс-тестирование, со своей спецификой (и это предмет отдельной статьи).
• Качественный мониторинг и диагностика, особенно при больших масштабах тестируемой системы
• Важный пункт: если идет нагрузочное тестирование уже работающей системы, то есть системы которой уже пользуются реальные пользователи, рекомендуется сделать реплику (копию) последней рабочей версии перед началом тестирования, и выбрать время тестирования не в самые нагруженные часы. Иначе есть вероятность, что десятки или сотни тысяч пользователей вместо любимой услуги или товара — увидят надпись о недоступности сайта с соответствующим кодом ошибки, и, конечно, не будут рады
• Проанализировать результаты тестов, включая ложнопозитивные результаты

Преимущества нагрузочного тестирования

• Можно определить ограничения в работе приложения сайта, мешающие его росту. Это поможет руководству проекта запланировать будущие расширения инфраструктуры
• Найти узкие места в системе («бутылочные горлышки») — до того как они принесут реальные проблемы
• Существенное снижение рисков длительных отказов системы
• Улучшение отношения пользователей. Если веб-сайт, грубо говоря, не тормозит, при любом наплыве, пользователи всегда это ценят, особенно сравнивая с конкурентами, и возвращаются еще и еще.
• Предотвращение убытков компании, превентивно, на ранней стадии проекта, до его запуска.

Недостатки

• Нередко требуется знание языков программирования
• Хотя существует множество хороших бесплатных инструментов, качественные инструменты — платные, с платными необходимыми функциями, релевантные для средних и крупных проектов
• Нагрузочное тестирование по определению требовательно к ресурсам (оборудованию)
• Сложность: вряд ли нагрузочное тестирование могут доверить новичкам, без опыта в этом деле; без опыта написания довольно специфических сценариев и тест-кейсов, не владеющих инструментами
• Ограниченность: нагрузочное тестирование сосредоточено на производительности системы, и хотя помогает определить узкие места в системе, оно вряд ли способно находить баги на высоком уровне. Поэтому нужно комбинировать нагрузочное с другими типами тестирования.
• Не всегда показательные результаты, особенно если к настройке тестового окружения не подошли со всей тщательностью, или если сценарии не очень соответствуют поведению реальных пользователей
• Сложность в анализе результатов, требующая опыта в обработке больших объемов данных, и опыта в определении причин возникающих проблем

Источники: 1,2