Нагрузочное тестирование предназначено для проверки поведения веб-приложения в условиях реальной и пиковой нагрузки. Такое тестирование позволяет узнать пределы устойчивости приложения, а также найти проблемные места, и откорректировать элементы, которые являются причиной сбоев при большой нагрузке.
Обсудим, как написать план такого тестирования. В нем нужно рассмотреть следующие моменты:
- Какой результат ожидается от нагрузочного тестирования?
- Как мы будем тестировать это веб-приложение:
- Сбор данных для тестовых сценариев
- Написание тестовых сценариев
- Выполнение сценариев
- Разбор результатов
Какой результат ожидается от нагрузочного тестирования?
При нагрузочном тестировании веб-приложения, тестировщик может получить огромное количество данных по поведению приложения под нагрузкой. Если не продумать тесты наперед, не рассчитать результаты, то есть вероятность упустить что-то важное. Нужно думать, что ты хочешь от тестирования.
Что нужно уяснить во время нагрузочного тестирования:
- Какой элемент приложения будет “стопорящим” (так называемый bottleneck), когда резко возрастет количество пользователей?
- Корректно ли масштабируется приложение под большой нагрузкой?
- Корректно ли ведет себя приложение во время тестирования в условиях, имитирующих реальную нагрузку?
- Сколько пользователей одновременно может работать с приложением в “пиковых” условиях?
- Как время ответа (response time) изменяется в ответ на рост числа пользователей?
- Как можно оптимизировать производительность приложения?
Как мы будем тестировать приложение?
В нашем тестовом наборе будет несколько сценариев. Сценарии будут состоять из этапов, каждому из которых соответствует какое-то количество пользователей (в терминологии нагрузочного тестирования — потоков, или виртуальных пользователей, или VU—пользователей). Виртуальные VU-пользователи будут направлять трафик в приложение.
Также задается так называемая скорость роста пользователей, и скорость снижения. Это показатель ступенчатого роста и снижения количества новых одновременных пользователей в приложении.
Будем тестировать приложение в двух условиях нагрузки.
При реалистичной нагрузке
Когда приложение идет в релиз, нужно удостовериться, что оно способно выдержать какой-то приемлемый трафик. Для этого проводится анализ паттернов поведения пользователей (как они обычно работают с приложением), и создать тестовые сценарии, имитирующие реальное поведение.
При пиковой нагрузке
Тестирование в пиковых условиях задействует те же сценарии что в реальных, но с другими параметрами. Количество одновременных пользователей повышают выше реалистичных значений, пока приложение не перестанет отвечать на запросы. Такая нагрузка считается максимальной емкостью приложения.
Сбор начальных данных для сценариев
Тестовым сценариям требуется ввод каких-то данных, имитирующих паттерны поведения реальных пользователей. Для этого нужно поставить следующие вопросы:
Какое максимальное количество одновременных пользователей ожидается?
Если веб-приложение является заменой или апгрейдом уже существующего приложения, это намного проще. Уже можно знать примерные количества пользователей, которые будут реалистичными.
- Идем на страницу «Сессии» или «Пользователи» в приложении аналитики посещаемости (той же Google Alalytics, Яндекс.Метрике и т.п.)
- Находим самый нагруженный день за последний год.
- В этом дне, выделяем 2 самых нагруженных часа.
- Из этих цифр посещаемости, вычисляем количество одновременных пользователей, по формуле:
Количество одновременных пользователей = (количество пользователей за 2 часа) * среднее время проведенное на странице, в секундах / 3600 секунд / 2 часа = ?
Так мы находим количество одновременных пользователей в самом нагруженном дне за последний год, и это будет наш искомый параметр для расчета нагрузки в реалистичных условиях.
В нашем случае, у нас было 20 тысяч сессий, а среднее время проведенное на странице составило 2 минуты. В итоге получилось 333 одновременных пользователя.
Всего сессий за 2 часа = 20 000 сессий
Среднее время проведенное на странице = 120 секунд
Одновременных пользователей = 333 пользователя
Какие части веб-приложения нагружаются больше всего?
Это важно знать, чтобы сбалансировать части приложения, базируясь на реалистичных ожиданиях.
Например если главная страница принимает больше всего трафика, то тестовый набор должен в первую очередь оценивать главную страницу. Опять же, для этого нужно внимательно посмотреть соответствующий раздел в Google Analytics.
Анализ может выглядеть примерно так (сайт магазина):
| Страница | Процент трафика |
|---|---|
| / | 60% |
| /articles | 20% |
| /shop | 15% |
| /contact | 5% |
Проверяем пределы выносливости приложения
Теперь нужно знать предел, на котором приложение перестает отвечать на тестовые запросы.
- Сколько времени приложению нужно, чтобы обработать запрос?
- Какой ответ считается успешным?
| Максимальное время ответа | 30 секунд |
| Успешный ответ (HTTP-код) | HTTP 200, 201, 301, 302, 308 |
Эти пределы должны быть испытаны в тестовом наборе.
Создание тестовых сценариев
Когда у нас уже есть вводные данные, можно приступать к написанию тестовых сценариев. Набор надо отконфигурировать, вводя в него эти сценарии, и затем вывести результаты отдельно по каждому, чтобы было проще анализировать результаты.
В таблице ниже — у нас 3 сценария реалистичной нагрузки, и 3 сценария пиковой нагрузки. При пиковой нагрузке количество одновременных пользователей увеличивается “по ступенькам”, таким образом и оценивается устойчивость приложения.
Нужен также “нулевой сценарий”, когда пользователь только один. Тогда имеем прямую линию, “базовую”, она нужна чтобы видеть “базовое” время ответа при отсутствии нагрузки. “Базовая линия” позволяет оценить влияние скачкообразных повышений нагрузки.
| Сценарий | Одновременное количество пользователей | Время роста нагрузки | Длительность нагрузки |
|---|---|---|---|
| Один пользователь | 1 | 0 минут | 5 минут |
| Реалистичные условия #1 | 100 | 5 минут | 20 минут |
| Реалистичные условия #2 | 200 | 10 минут | 30 минут |
| Реалистичные условия #3 | 350 | 20 минут | 60 минут |
| Пиковые условия #1 | 300 | 10 минут | 30 минут |
| Пиковые условия #2 | 400 | 15 минут | 40 минут |
| Пиковые условия #3 | 600 | 20 минут | 50 минут |
Выполнение тестов
После создания плана, и написания скриптов, выполняем тесты.
При этом надо учесть следующее:
- Запускаться тестовый набор должен на сервере достаточной мощности, способном генерировать пиковую нагрузку на веб-приложение.
- Наладить мониторинг в реальном времени, чтобы сразу видеть последствия нагрузки; как высокий трафик влияет на веб-приложение и другие части сервера.
- Тестировать приложение в продакшн-среде, или среде, сопоставимой по мощности.
- Выполнять нагрузочное тестирование надо с привлечением разработчиков приложения, чтобы они видели как приложение себя ведет при пиковой нагрузке.
Разбор результатов
Все это выглядит примерно так:
После тестирования нужно сохранить результаты — в raw-форме, и в виде скриншотов мониторинга, а также ситуации неожиданных сбоев и т.п. Лучше всего сохранять результаты в системе контроля версий (там же сохраняя скрипты выполненного тестирования). Это нужно, чтобы при переносе в другое окружение не пришлось заново писать скрипты и настраивать окружение.
Также желательно написать выводы из тестирования, в виде ответов на перечисленные в начале вопросы. Таким образом, создастся удобный отчет, фиксирующий текущую устойчивость приложения.