Стратегии нагрузочного тестирования: как разработать эффективный план

Источник: Блог IBS

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

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

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

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

Вам необходимы следующие ресурсы: экспертиза, мощности, люди и их время. Попробуем оценить объём.

Серверы необходимы для:

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

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

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

  • Системные администраторы и DevOps-специалисты: настройка системы и исправление обнаруженных ошибок в тестовом окружении.
  • Администраторы баз данных: копирование данных с продуктовой среды и их обезличивание.
  • Аналитики: сбор статистики и создание прогнозов по нагрузке системы в будущем.
  • Программисты: консультирование команды нагрузочного тестирования.
  • Функциональные тестировщики: помощь с формализацией и прохождением сценариев пользователя.
  • Менеджеры: содействие в организации коммуникации, когда возникают вопросы у команды заказчика.
  • Инженеры нагрузочного тестирования: разработка, запись скриптов, проведение тестов, анализ результатов.

Что может украсть время? К основным рискам нагрузочного тестирования относят, во-первых, долгую настройку стенда — тестового окружения с развернутой системой. Кроме того, могут возникнуть проблемы с доступами и получением информации, связанные с безопасностью (часто это выливается в серьёзные бюрократические проволочки). Также увеличит общее время плохая обратная связь и медленное реагирование на запросы команды нагрузочного тестирования.

Только после того, как тестировщики оценят риски, сложность системы и объём работ, они смогут дать более-менее точный прогноз по срокам. Но заранее будьте готовы к тому, что времени нужно гораздо больше, чем может показаться на первый взгляд. Сэкономить его помогут экспертиза, отлаженные процессы и хорошие специалисты (разумеется, в разумных пределах).

А деньги? Этот ресурс уже учтён в статьях расходов «трудозатраты» и «вычислительные мощности». Но в бюджет также стоит добавить оплату работ внешних подрядчиков или сервисов.

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

Стратегически выделяют следующие подходы к проведению нагрузочного тестирования:

  • на тестовом стенде или на продуктовой среде;
  • тестирование отдельных сервисов или системы в целом как «чёрного ящика»;
  • разовое или релизное тестирование.

Теперь рассмотрим каждую стратегию подробно.

На продуктовой среде vs на тестовом стенде

Первый вариант стоит выбирать, если точно знаете, как «отделить» продуктовую базу данных от тестовой, и как провести тестирование, не нарушая работоспособность системы. Только представьте, в ходе нагрузочного тестирования в интернет-магазине на продуктовой среде произошла ошибка, и вы начали в огромных количествах покупать реальные товары, а не тестовые. Несложно представить, какими издержками это обернётся для магазина.

И имейте ввиду, в любом случае данный вариант потребует огромной вовлеченности системных администраторов, DevOps-специалистов и программистов.

Целиком vs посервисно

Тестирование системы в целом как «чёрного ящика» более показательно и реалистично. Все скрипты запускаются параллельно, все бизнес-процессы, нагружающие систему, имитируются одновременно. Система рассматривается как единое целое, что позволяет увидеть «узкие» места.

Вторая стратегия позволяет оценить производительность отдельного выбранного сервиса, понять, увеличилась или уменьшилась она после обновления. Но этот подход не гарантирует работоспособность всей системы целиком под нагрузкой. Общие «узкие» места вы не увидите.

Разовое vs релизное

Разовое тестирование обычно выбирают небольшие компании, чтобы оценить актуальную производительность системы и найти в ней те самые «узкие» места.

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

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

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

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

Весь процесс полного тестирования системы как «чёрного ящика» включает следующие основные этапы:

  • Настройка стенда и выдача доступов.
  • Сбор и анализ информации.
  • Подготовка генераторов и уточнения.
  • Запись скриптов и подготовка к запускам.
  • Запуски (их может быть множество) и анализ результатов.
  • Сохранение артефактов тестирования и написание инструкций.

В реальности этапы могут повторяться и накладываться друг на друга (в зависимости от специфики проекта). Например, в разовых проектах вероятны многократные повторы на 5-ом этапе.

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

Теперь стоит рассмотреть каждый из этапов отдельно.

1. Настройка стенда и выдача доступов

Выполняется заказчиком.

2. Сбор и анализ информации

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

Методика нагрузочного тестирования (МНТ) — своего рода «Библия» нагрузочника. Этот документ фиксирует цели, стратегию и ограничения; какие будут проведены тесты и какие эмуляторы реализованы; требования к данным; что будет содержаться в отчёте, какие результаты и артефакты получит заказчик, и многое другое. Методика позволяет зафиксировать договоренности и избежать недопониманий.

3. Подготовка генераторов и уточнения

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

Тестовый сценарий (или юзер кейс) — это описание шагов и действий пользователя в системе (но не всех, а только тех, что направлены на определенный функционал).

4. Запись скриптов и подготовка к запускам

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

5. Запуски и анализ результатов

Тут могут «всплыть» дополнительные проблемы — для их выявления и нужен данный этап. Запуски включают разные виды тестов. Мониторятся показатели утилизации ресурсов на серверах системы. При необходимости проводятся дополнительные запуски — для проверки результатов и предположений. Формируются экспресс отчеты (по каждому запуску) и общий развёрнутый отчёт.

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

6. Сохранение артефактов тестирования и написание инструкций

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

Рекомендации по нагрузочному тестированию

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

Находите общий язык с командой нагрузочного тестирования. Договоритесь «на берегу» и постоянно сверяйтесь в ходе работ. Важно понимать, каких результатов тестирования вы ждёте, какие условия ставите, и что планируют получить они. Хорошо, если команда сама уточняет ваши ожидания. Но так бывает далеко не всегда. Поэтому:

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

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

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

И в заключение: ищите компромисс между сроками и реалистичным вариантом разворачивания нагрузочного тестирования. Реалистичность никогда не бывает 100%-ой, но стремится к этому. Добиться достаточной степени точности действительно возможно. Удачи!

Мнение эксперта в статье
Команда экспертов IBS
Сайт IBS использует cookie. Это дает нам возможность следить за корректной работой сайта, а также анализировать данные, чтобы развивать наши продукты и сервисы. Посещая сайт, вы соглашаетесь с обработкой ваших персональных данных.