Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Как спроектировать нагрузочный тест
13.08.2019 00:00

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Поэтому, прежде чем приступать, важно ответить на следующие вопросы:

  • Какие сценарии будут тестироваться?
  • Каково ожидаемое поведение в этих сценариях?

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

Держа это в уме, вы ожидаете вот какого поведения:

  • Страницы сайта должны загружаться за не более чем две секунды под обычной субботней утренней нагрузкой.
  • Сайт должен быть способен обрабатывать пятьсот заказов в час – это поможет справиться с загруженным сезоном дня святого Валентина.
  • Сайт должен выдерживать десять тысяч посетителей в час – такое количество ожидается сразу после эфира ТВ-шоу.

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

Как только тест-окружение подготовлено, можно провести ряд простых тестов, чтобы определиться с базовыми значениями метрик. Тут можно использовать стратегии, упомянутые в статье "Введение в тестирование производительности" и выяснить, как долго грузятся страницы, и каково типичное время ответа ваших API-эндпойнтов. Знание этих чисел поможет вам определить, какой эффект окажет нагрузка.

Теперь настало время проектировать тесты. Здесь можно пользоваться различными стратегиями:

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

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

Для каждого теста нужно определиться:

  • Сколько пользователей будет единовременно взаимодействовать с приложением?
  • Будут ли они добавляться единовременно, или постепенно, каждые несколько секунд?
  • Будут ли они выполнять одно действие и останавливаться, или же они будут непрерывно повторять его в течение теста?
  • Как долго продлится тест?

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

Перед прогоном теста убедитесь, что шаги возвращают ошибки, если не получают ожидаемого результата. Когда я только начинала работать в нагрузочном тестировании, я прогнала несколько тестов с сотнями запросов, прежде чем обнаружила, что все мои запросы возвращали пустоту. Они возвращались со статусом 200, поэтому я и не заметила, что что-то пошло не так! Убедитесь, что ваши шаги убеждаются, что приложение работает именно так, как задумано.

Когда шаги созданы, тест-параметры (количество пользователей, частота их добавления и продолжительность теста) заданы, а вы убедились, что валидация результата в порядке, наступает время прогона! Пока тест запущен, следите за временем ответов и загрузкой процессора. Если пойдут ошибки или всплески загрузки CPU, можно остановить тест и отметить, при какой нагрузке это произошло.

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