Представим менеджера, который хорошо понимает: если не провести нагрузочное тестирование, и что-то пойдёт не так, «чёрная пятница» и рост трафика раз этак в 10 могут обернуться для компании «чёрной дырой» в бюджете.
Понимание есть, а команды нет. Отсюда много вопросов: какие ресурсы нужны для полноценного тестирования производительности системы, и как понять, окупится ли оно?
Узнали себя в этом менеджере? Тогда эта статья будет вам полезна. Сегодня говорим о том, как оценить затраты на тестирование, и какую стратегию выбрать, чтобы сократить издержки. В конечном итоге это сбережёт компании деньги, а клиентам — нервы, которые совсем не казённые.
Вам необходимы следующие ресурсы: экспертиза, мощности, люди и их время. Попробуем оценить объём.
Серверы необходимы для:
Важно понимать: серверы имитируют продуктовую среду — вычислительные мощности должны соответствовать ей.
Экспертиза — это, во-первых, исследование тестируемой системы. Она нужна, чтобы настроить тестовую версию отдельно от продуктовой, предположить основные проблемы и знать, какие метрики мониторить. Во-вторых, это собственно экспертиза нагрузочного тестирования.
Временной ресурс подразумевает под собой сроки проведения тестирования и получения результатов. Посмотрим, кто и на что будет тратить время.
Что может украсть время? К основным рискам нагрузочного тестирования относят, во-первых, долгую настройку стенда — тестового окружения с развернутой системой. Кроме того, могут возникнуть проблемы с доступами и получением информации, связанные с безопасностью (часто это выливается в серьёзные бюрократические проволочки). Также увеличит общее время плохая обратная связь и медленное реагирование на запросы команды нагрузочного тестирования.
Только после того, как тестировщики оценят риски, сложность системы и объём работ, они смогут дать более-менее точный прогноз по срокам. Но заранее будьте готовы к тому, что времени нужно гораздо больше, чем может показаться на первый взгляд. Сэкономить его помогут экспертиза, отлаженные процессы и хорошие специалисты (разумеется, в разумных пределах).
А деньги? Этот ресурс уже учтён в статьях расходов «трудозатраты» и «вычислительные мощности». Но в бюджет также стоит добавить оплату работ внешних подрядчиков или сервисов.
Стратегически выделяют следующие подходы к проведению нагрузочного тестирования:
Теперь рассмотрим каждую стратегию подробно.
На продуктовой среде vs на тестовом стенде
Первый вариант стоит выбирать, если точно знаете, как «отделить» продуктовую базу данных от тестовой, и как провести тестирование, не нарушая работоспособность системы. Только представьте, в ходе нагрузочного тестирования в интернет-магазине на продуктовой среде произошла ошибка, и вы начали в огромных количествах покупать реальные товары, а не тестовые. Несложно представить, какими издержками это обернётся для магазина.
И имейте ввиду, в любом случае данный вариант потребует огромной вовлеченности системных администраторов, DevOps-специалистов и программистов.
Целиком vs посервисно
Тестирование системы в целом как «чёрного ящика» более показательно и реалистично. Все скрипты запускаются параллельно, все бизнес-процессы, нагружающие систему, имитируются одновременно. Система рассматривается как единое целое, что позволяет увидеть «узкие» места.
Вторая стратегия позволяет оценить производительность отдельного выбранного сервиса, понять, увеличилась или уменьшилась она после обновления. Но этот подход не гарантирует работоспособность всей системы целиком под нагрузкой. Общие «узкие» места вы не увидите.
Разовое vs релизное
Разовое тестирование обычно выбирают небольшие компании, чтобы оценить актуальную производительность системы и найти в ней те самые «узкие» места.
Например, когда готовят её к росту числа пользователей или вводят новый функционал. При необходимости повторяют. Разовое тестирование имеет смысл, если оно окупается за счёт снятия возможных проблем в будущем.
Релизное тестирование подразумевает выстраивание непрерывного процесса вокруг регулярных обновлений. Само по себе оно дороже: скрипты приходится перезаписывать для каждого нового релиза. Но в целом это всё же дешевле, чем каждый раз тестировать с нуля. Накапливая экспертизу, выстраивая процессы, лучше понимая возможные проблемы, автоматизируя запуски, вы можете значительно сократить расходы.
Выбирая стратегию, обязательно учитывайте пользовательские сценарии и профиль нагрузки как возможные ограничения тестирования. Ограничивающие факторы есть всегда. Допустим, тестовая среда в чём-то отличается от продуктовой, например, в ней меньше пользователей или данных. Или реализовано не 100% тестовых сценариев. Или вы собрали ещё не собрали пользовательскую статистику по новому функционалу и руководствуетесь только аналитикой… Не все факторы можно учесть на стадии планирования, но важно попытаться их зафиксировать, оценить степень влияния и учесть при выборе стратегии.
Весь процесс полного тестирования системы как «чёрного ящика» включает следующие основные этапы:
В реальности этапы могут повторяться и накладываться друг на друга (в зависимости от специфики проекта). Например, в разовых проектах вероятны многократные повторы на 5-ом этапе.
При тестировании отдельных релизов часто необходим возврат на 4-ый и 5-ый этапы. Также может понадобиться перегенерировать данные, добавить новые пользовательские кейсы.
Теперь стоит рассмотреть каждый из этапов отдельно.
1. Настройка стенда и выдача доступов
Выполняется заказчиком.
2. Сбор и анализ информации
Методика нагрузочного тестирования (МНТ) — своего рода «Библия» нагрузочника. Этот документ фиксирует цели, стратегию и ограничения; какие будут проведены тесты и какие эмуляторы реализованы; требования к данным; что будет содержаться в отчёте, какие результаты и артефакты получит заказчик, и многое другое. Методика позволяет зафиксировать договоренности и избежать недопониманий.
3. Подготовка генераторов и уточнения
Здесь происходит проверка всех доступов и работоспособности тестового окружения, планирование логики работы скриптов, подготовка генераторов нагрузки, настройка мониторинга и уточнение тестовых сценариев.
Тестовый сценарий (или юзер кейс) — это описание шагов и действий пользователя в системе (но не всех, а только тех, что направлены на определенный функционал).
4. Запись скриптов и подготовка к запускам
Подготавливаются тестовые данные и наполняются базы данных, создаются тестовые пользователи, записываются и отлаживаются скрипты, разрабатываются эмуляторы внешних систем, пишется вспомогательный код (если необходим).
5. Запуски и анализ результатов
Тут могут «всплыть» дополнительные проблемы — для их выявления и нужен данный этап. Запуски включают разные виды тестов. Мониторятся показатели утилизации ресурсов на серверах системы. При необходимости проводятся дополнительные запуски — для проверки результатов и предположений. Формируются экспресс отчеты (по каждому запуску) и общий развёрнутый отчёт.
Когда все возникшие проблемы устранены, можно переходить непосредственно к нагрузочным тестам, результаты которых уже прописываются в итоговом отчёте.
6. Сохранение артефактов тестирования и написание инструкций
Артефакты собирают, чтобы была возможность вернуться к данным, результатам и провести повторный анализ. Сохраняют в тои числе сами скрипты, эмуляторы и вспомогательные инструменты — для возможного перезапуска теста и сравнения результатов в будущем. Инструкции пишутся для тех, кто будет воспроизводить тесты.
Как мы уже говорили выше, проблемы в коммуникации и, как следствие, неверные ожидания — один из основных рисков. Выстраивайте взаимодействие между всеми участниками процесса — это первый и, пожалуй, главный совет.
Находите общий язык с командой нагрузочного тестирования. Договоритесь «на берегу» и постоянно сверяйтесь в ходе работ. Важно понимать, каких результатов тестирования вы ждёте, какие условия ставите, и что планируют получить они. Хорошо, если команда сама уточняет ваши ожидания. Но так бывает далеко не всегда. Поэтому:
Обеспечьте содействие на уровне менеджмента. Повторимся, если запросы команды нагрузочного тестирования игнорируются или выполняются с опозданием, это может серьёзно увеличить или даже сорвать сроки. Часто, чтобы этого избежать, нужна «политическая воля» высшего менеджмента. Постарайтесь заручиться его поддержкой.
И ещё несколько рекомендаций. Оценивайте объёмы работ каждую неделю или хотя бы раз в две недели. Тестируйте до релиза, а не после. Обращайте внимание на реалистичность тестирования: насколько адекватно эмулируется нагрузка на систему.
И в заключение: ищите компромисс между сроками и реалистичным вариантом разворачивания нагрузочного тестирования. Реалистичность никогда не бывает 100%-ой, но стремится к этому. Добиться достаточной степени точности действительно возможно. Удачи!