Нагрузочное тестирование на Python и Locust с запуском на CI/CD

Разбираемся, как организовать нагрузочное тестирование на Python с Locust — с сидинговыми сценариями, кастомными API-клиентами на HTTPX, конфигурацией через Pydantic и автоматическим запуском в GitHub Actions. Всё — на практике, с архитектурой, фреймворком и публикацией отчётов в GitHub Pages.

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

Нагрузочное тестирование становится всё более востребованным. Если раньше оно ассоциировалось в основном с тяжеловесным интерфейсом Apache JMeter, то сегодня в арсенале инженеров появились гораздо более удобные и гибкие инструменты: Locust, k6, Gatling, Artillery и другие. Они позволяют за несколько часов поднять полноценные тесты и встроить их в CI/CD.

В этой статье мы:

В качестве тестируемого сервиса мы будем использовать FakeBank API — учебный REST API, позволяющий работать с фейковыми банковскими операциями. Все запросы будут отправляться на: https://api.sampleapis.com/fakebank/accounts.

Важно! Это тестовый API с ограничением по количеству запросов, поэтому мы сознательно не будем создавать избыточную нагрузку. Задача статьи — не "завалить" сервис, а показать, как правильно организовать инфраструктуру нагрузочного тестирования.

Вы получите не просто рабочий пример, а цельный фреймворк, с которым можно работать, масштабировать, адаптировать под свои сценарии и запускать из CI/CD. По ходу мы разберём множество архитектурных и практических деталей — от построения сценариев до публикации результатов.

Прежде чем перейти к практике, давайте разберёмся в базовых терминах. Очень часто тестирование производительности путают с «нагрузкой ради нагрузки»: запускают 1000 пользователей на один endpoint и с гордостью называют это "нагрузочным тестом". Такой подход редко даёт реальную пользу — чаще всего он ведёт к искаженному восприятию метрик и неправильным выводам.

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

Оно включает в себя несколько подвидов:

В рамках этой статьи мы сфокусируемся на классическом нагрузочном тестировании, когда мы хотим понять:

Важно понимать: нагрузочное тестирование — это не гонка за цифрами. Оно не сводится к запуску 10 000 пользователей на один endpoint вроде /ping и последующей гордости за полученные 150 RPS. Такой подход может красиво смотреться на графике, но не говорит ровным счётом ничего о реальной устойчивости системы.

Наша цель — смоделировать поведение живых пользователей. Не synthetic load, а то, как пользователи реально двигаются по системе, с какими данными работают, в каком порядке совершают действия. Иначе мы просто тестируем абстрактный HTTP-сервер, а не продукт.

Что это значит на практике? Вместо "битья" по одному endpoint, мы собираем конкретные пользовательские флоу — например:

Такие цепочки — это сценарии использования (use cases). Именно они нагружают систему как единое целое: затрагивают авторизацию, базу данных, кэш, бизнес-логику, генерацию PDF, внешние сервисы.

Именно такие сценарии:

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

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

На клиентской стороне — то, что мы видим из Locust: как быстро API отвечает, сколько запросов проходит в секунду, сколько из них завершаются с ошибками. Один из ключевых показателей здесь — время отклика (latency). Если, к примеру, пользователь видит, что страница с операциями загружается не за 300 мс, а за 3 секунды, это становится проблемой — даже если сервер формально не падает.

Другой важный параметр — RPS (requests per second). Он показывает, сколько запросов система реально обрабатывает при заданной нагрузке. Если при 100 пользователях мы получаем только 20 RPS, это сигнал задуматься: не слишком ли много времени уходит на внутренние операции?

Кроме того, нужно следить за уровнем ошибок. Допустим, при 500 RPS появляются ответы 5xx или 429 — значит, сервис уже не справляется, и нужно искать бутылочное горлышко.

Не менее важно понимать дисперсию отклика. Бывает, что среднее время — 300 мс, но 90-й процентиль — 2 секунды. Это означает, что часть пользователей стабильно получает очень медленный отклик. Такие перекосы крайне опасны в пользовательских системах: один клиент счастлив, а другой негодует.

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

С другой стороны, есть инфраструктурные метрики — они дают понимание того, что происходит "внутри" системы. Это, прежде всего, нагрузка на CPU и потребление оперативной памяти. Если при росте RPS CPU сразу уходит в 100%, значит, дальше масштабироваться не получится без оптимизации кода или увеличения ресурсов.

Также важны количество открытых соединений, активность диска (IO), состояние баз данных и кэшей. Например, при пиковых значениях может «задохнуться» Redis, очередь сообщений или файловое хранилище. Бывает, что кэш забит, очередь растёт — а ошибки на клиенте появляются через 2 минуты, когда всё уже упало.

Такие метрики обычно собираются через внешние системы мониторинга: Grafana, Prometheus, Datadog, NewRelic. Они позволяют строить дашборды, отслеживать тренды и мгновенно реагировать на отклонения.

В рамках этой статьи мы работаем с учебным API, который для нас — по сути, black-box. Мы не можем влезть внутрь и посмотреть системные метрики, так как это не наш сервис.

Поэтому в данной статье мы ограничимся клиентскими метриками — теми, которые нам даст HTML-отчёт Locust.

Цель этой статьи — не полноценный анализ архитектуры, а техническая сторона написания хорошо организованных нагрузочных тестов: как структурировать код, как задавать сценарии, как подключать сидинг, как запускать в CI/CD и т.д.

Если у вас есть доступ к системным метрикам (через Grafana, Prometheus, Datadog, NewRelic и т.д.), обязательно подключайте их в связке с Locust. Только так можно получить полную картину производительности.

Вот стек инструментов, которые мы будем использовать:

В экосистеме нагрузочного тестирования существует множество инструментов: JMeter, k6, Gatling, Artillery. У каждого — свои сильные стороны. Но если вы работаете с Python, Locust — безусловный лидер. Вот почему:

Хотя в Locust есть встроенный HTTP-клиент, мы сознательно отказываемся от него в пользу собственного решения. Причина проста: нам нужен универсальный API-клиент, который будет использоваться не только внутри сценариев Locust, но и при генерации тестовых данных (сидинге), а также — при необходимости — в интеграционных автотестах. Это позволяет не дублировать логику и работать с API единообразно в разных контекстах.

Встроенный клиент Locust хорош для простых примеров, но он не даёт необходимой гибкости. В нём нет строгой типизации, он жёстко завязан на структуру Locust, его сложно конфигурировать централизованно и практически невозможно удобно переиспользовать вне контекста нагрузочного теста. Поэтому мы создадим собственный HTTP-клиент, основанный на связке HTTPX и Pydantic.

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

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

Библиотека Requests хоть и популярна, но уже давно перестала активно развиваться. У неё до сих пор нет встроенной аннотации типов, хотя эта возможность появилась в Python ещё в версии 3.5 (а на момент написания статьи скоро выйдет уже 3.14). Прошло более 10 лет, но в Requests так и не добавили полноценную поддержку аннотаций типов, что говорит о слабой эволюции библиотеки.

Requests в своё время завоевала популярность благодаря простоте и отсутствию достойных альтернатив. Но сегодня есть более современное, мощное и удобное решение — HTTPX.

Что даёт HTTPX по сравнению с Requests:

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

Если вы не пишете legacy-код и создаёте новый проект нагрузочных тестов на Python, то HTTPX — очевидный выбор.

Тут всё просто: Pydantic — это стандарт де-факто для работы с данными в Python.

Он позволяет:

У Pydantic почти нет достойных альтернатив. Стандартные dataclasses в Python даже близко не дают такой же функциональности, особенно валидации и строгой типизации данных.

Если вам нужны чистые, предсказуемые и надёжные данные — Pydantic обязателен в любом современном проекте.

Прежде чем работать с API https://api.sampleapis.com/fakebank/accounts, необходимо определить структуру данных, которые мы будем отправлять и получать.

Для этого используем Pydantic, так как он:

Мы определим:

/schema/operations.py

Pydantic – это лучшее решение для работы с API-данными.

Pydantic позволяет автоматически проверять данные, использовать алиасы для полей и работать с JSON без дополнительных преобразований.

При отправке запросов к API нам нужно создавать множество случайных данных для разных сценариев. Чтобы автоматизировать этот процесс и избавиться от ручного заполнения, используем библиотеку Faker и реализуем класс Fake. Класс Fake будет предоставлять удобный интерфейс для генерации нужных значений.

/tools/fakers.py

Класс Fake инкапсулирует логику библиотеки Faker и предоставляет удобный API для работы. Теперь вместо множества вызовов Faker().some_method() в коде можно просто использовать fake.some_method().

Теперь добавим фейковую генерацию прямо в модели Pydantic, используя параметр default_factory. Это позволит автоматически заполнять поля случайными значениями при создании модели.

/schema/operations.py

Применение default_factory. Каждое поле получает случайное значение при создании экземпляра модели. Пример работы:

Вывод (данные случайные):

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

В данном примере нам нужно хранить только URL API и таймаут запросов, но в будущем можно расширять этот механизм.

Для управления настройками будем использовать Pydantic Settings — удобную библиотеку, которая позволяет загружать переменные окружения в виде Pydantic-моделей.

config.py

.env

Теперь можно просто инициализировать Settings и использовать его:

Для работы с API https://api.sampleapis.com/fakebank/accounts мы используем библиотеку HTTPX. Она современная, производительная и отлично подходит для создания универсального API-клиента. Но одной отправки запросов недостаточно — в рамках нагрузочного тестирования важно, чтобы каждый вызов API автоматически попадал в систему метрик Locust. Нам нужно отслеживать время ответа, ошибки, размер тела и при этом поддерживать понятную, агрегируемую статистику по маршрутам.

Locust, по умолчанию, умеет собирать метрики только со встроенных клиентов. Если мы используем стороннюю библиотеку — такую как HTTPX — то должны вручную передавать информацию о каждом запросе в движок Locust. Именно для этого используются event hooks.

HTTPX позволяет внедрить свою логику в жизненный цикл запроса с помощью так называемых хуков. Они бывают двух типов: request — вызывается перед отправкой запроса, и response — вызывается после получения ответа. Это удобный механизм, который позволяет реализовать всё: от логирования и трассировки до сбора метрик и интеграции с внешними инструментами.

В нашем случае мы реализуем два хука. Первый срабатывает перед отправкой запроса и сохраняет метку времени начала — это позволит затем вычислить длительность запроса. Второй срабатывает после получения ответа. Он извлекает метку старта, считает время выполнения в миллисекундах, определяет длину тела ответа и отправляет всё это в Locust через environment.events.request.fire().

Важно, что в хуке на стороне ответа мы также ловим исключения (HTTPError, HTTPStatusError) — это позволяет нам регистрировать ошибки не как "просто 500", а как полноценные события в отчёте.

/clients/event_hooks.py

Мы могли бы просто передавать environment как аргумент в каждый вызов, но это неудобно: HTTPX ждёт, что event_hooks["response"] будет списком функций с сигнатурой Callable[[Response], None]. То есть она должна принимать только response. Никакие дополнительные параметры, такие как environment, туда передать нельзя напрямую.

Чтобы обойти это ограничение, мы создаём вложенную функцию inner(), которая «захватывает» переменную environment из внешней области видимости. Это и есть замыкание — стандартный приём в Python, когда вложенная функция запоминает значения переменных из своей внешней среды, даже если она вызывается позже и в другом контексте.

Таким образом, locust_response_event_hook(environment) возвращает готовую для HTTPX функцию-хук, которая при каждом срабатывании знает, куда и как отправлять метрику.

Когда мы тестируем реальные API, URL часто содержит динамические параметры: ID пользователя, номер операции, дату. Например, /accounts/123, /accounts/456 и т.п. Если отправлять метрики в Locust с такими значениями как есть, то отчёт превратится в список из сотен уникальных строк, по сути — мусор. Чтобы этого избежать, мы передаём через extensions шаблон маршрута: /accounts/{id}. Этот шаблон подставляется в метрике вместо реального пути и позволяет агрегировать статистику правильно.

На этом этапе у нас есть хуки для интеграции с Locust, и теперь пора построить над ними полноценный фундамент — абстракцию HTTP-клиента, через которую будут идти все запросы. Задача — отделить инфраструктурные детали вроде хуков, маршрутов, конфигурации и логирования от конкретных бизнес-клиентов, таких как OperationsClient. Эта изоляция позволит переиспользовать код, упростит тестирование и повысит читаемость.

Вместо того чтобы работать напрямую с httpx.Client, мы создаём класс BaseClient, который становится универсальным слоем между HTTPX и любым конкретным API-клиентом. Он инкапсулирует вызовы get и post, принимает дополнительные параметры, включая extensions, и работает с уже сконфигурированным клиентом — либо обычным, либо с подключёнными хуками Locust.

Ключевая особенность реализации — использование поля extensions. Это специальный словарь, который HTTPX позволяет передавать в каждый запрос. Он остаётся незаметным для внешнего API, но может использоваться внутри хуков, чтобы передавать вспомогательные данные. И вот здесь появляется важный инженерный момент: extensions["route"].

Проблема в том, что API часто содержит динамические маршруты: /accounts/123, /accounts/456, и так далее. Если передавать их как есть в Locust, то в метриках будет по 1000 разных URL, каждый со своей строкой. Это создаёт хаос в статистике, мешает анализу и делает HTML-отчёты практически бесполезными. Чтобы этого избежать, мы вручную передаём шаблон маршрута — например, /accounts/{id} — через extensions["route"], и уже в хуке на стороне response используем именно его в качестве имени метрики. Это простой, но мощный приём, позволяющий агрегировать данные и сохранить чистую статистику.

/clients/base_client.py

Но сам по себе BaseClient не создаёт клиент. Этим занимаются два вспомогательных конструктора — get_http_client и get_locust_http_client. Первый используется, когда нам не нужно собирать метрики (например, в сидинге или обычных автотестах). Второй — когда мы запускаем тест в среде Locust и хотим, чтобы все метрики автоматически отправлялись в HTML-отчёт.

И в том, и в другом случае мы явно задаём base_url и timeout из конфигурации, а также устанавливаем уровень логгера для HTTPX, чтобы не засорять stdout при выполнении нагрузочных тестов или сидинга.

Во втором варианте — get_locust_http_client — мы подключаем хуки, определённые ранее. Один срабатывает до запроса (сохраняет время старта), второй — после получения ответа (считает время, длину и отправляет событие в Locust).

Этот слой завершает низкоуровневую часть инфраструктуры. Он изолирует httpx, предоставляет единый API, делает клиент совместимым с Locust и позволяет бизнес-клиентам фокусироваться на логике, а не на конфигурации и метриках.

После создания базового клиента пришло время реализовать клиентскую обёртку над конкретным REST API. В нашем случае — это OperationsClient, который работает с endpoint’ом /accounts на сервисе fakebank.

Этот клиент строится по принципу двух уровней:

Важно! Чтобы избежать ошибок и дублирования адресов эндпоинтов в проекте, рекомендуется вынести все URI в отдельный Enum. Это позволит централизованно управлять URL-адресами и избежать опечаток.

/tools/routes.py

/clients/operations_client.py

OperationsClient наследуется от BaseClient, получая в своё распоряжение стандартные методы get() и post() с поддержкой extensions, конфигурации и хуков Locust.

Метод отправляет GET-запрос на /accounts и возвращает "сырое" тело ответа. Такой формат пригоден для API-тестов или отладочной работы с данными.

Этот метод тоже работает на низком уровне, но с одной важной особенностью: он передаёт в extensions шаблон маршрута. Это необходимо, чтобы в метриках Locust не появлялись сотни уникальных строк вроде /accounts/1, /accounts/2, а вместо этого всё агрегировалось под ключом /accounts/{operation_id}.

Метод create_operation_api() принимает модель Pydantic и сериализует её в JSON, используя алиасы (например, transaction_date → transactionDate). Возвращается опять же Response.

Метод get_operations() вызывает низкоуровневый API, затем валидирует и преобразует тело ответа в Pydantic-модель OperationsSchema. Это упрощает работу с ответом — теперь мы получаем не JSON или строку, а полноценный Python-объект.

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

Это наиболее «высокоуровневый» метод. Он полностью инкапсулирует всю цепочку: генерацию фейковых данных, сериализацию, отправку запроса и десериализацию ответа. Именно его мы будем вызывать в сценариях Locust и в сидинге, потому что он даёт результат «из коробки» без ручной работы.

Как и в случае с BaseClient, мы создаём два конструктора клиента — один для обычного использования, другой — для интеграции с Locust.

get_operations_client() создаёт клиента без хуков. Это используется, например, в сидинге, когда нам не нужно собирать метрики — а просто сгенерировать или проверить данные.

А get_operations_locust_client() используется внутри сценариев Locust. Он создаёт httpx.Client с подключёнными хуками, которые автоматически будут отправлять все метрики и ошибки в HTML-отчёт Locust.

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

Один из ключевых этапов подготовки к нагрузочному тестированию — это сидинг (от англ. seeding), то есть предварительное наполнение системы нужными данными. Без сидинга любые метрики производительности будут искажены: вы будете тестировать не реальную нагрузку, а начальные этапы использования системы, вроде регистрации и настройки.

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

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

Когда речь заходит о создании данных, возникает логичный вопрос: а как именно наполнять систему — через базу или через API?

Простой путь — напрямую вставить данные в базу SQL-скриптами или ORM. Но на практике такой подход опасен, хрупок и практически всегда ведёт к скрытым багам. Поэтому в рамках этого проекта мы используем сидинг через API — и вот почему.

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

При работе через API все операции проходят через тот же код, что используется в продакшене — это гарантирует валидность и консистентность.

Сидинг через базу требует от вас вручную воссоздавать все связи и зависимости: сначала пользователя, потом счёт, потом операции и документы. Любое изменение в бизнес-логике потребует переписывать сидер. Через API — это уже реализовано. Вы просто вызываете соответствующие методы.

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

API-сидинг проще масштабировать. Вы можете распараллелить генерацию данных, повторно использовать существующие клиенты и сценарии, не заботясь о внутреннем устройстве базы. Это особенно важно в микросервисной архитектуре, где за одним объектом могут стоять десятки сервисов и процессов.

Мы хотим, чтобы все данные, участвующие в нагрузочном тесте, были:

Поэтому мы будем использовать специальные API-клиенты, которые вызывают реальные методы создания объектов (например, POST /operations), и строим поверх них сидинг-скрипты. Это даёт нам:

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

/seeds/schema/plan.py

Объяснение:

Этот план подаётся на вход сидеру и определяет его поведение: сколько данных и какого типа нужно создать.

/seeds/schema/result.py

Объяснение:

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

В нашей системе мы хотим, чтобы сидер:

/seeds/builder.py

Весь сидинг построен вокруг одной сущности — operation. Мы используем уже готовый OperationsClient, в котором реализован вызов create_operation() через HTTP API. Каждая созданная операция добавляется в результат (SeedsResult) в виде объекта SeedOperationResult, содержащего ID операции.

На вход подаётся SeedsPlan, в котором указано, сколько операций нужно создать. Это удобно для конфигурирования сидинга извне — например, из JSON-файла или командной строки.

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

Таким образом, сидинг остаётся прозрачным, расширяемым и строго типизированным.

После выполнения сидинга у нас на руках оказывается структура SeedsResult, в которой собраны все созданные объекты (например, operation_id операций). Эти данные могут понадобиться позже:

Чтобы не терять эти данные, мы сохраняем результат в файл.

/seeds/dumps.py

Такой подход даёт сразу несколько преимуществ:

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

Эти компоненты определяют, какие действия выполняются, с какой частотой и задержкой, какие API вызываются и в какой последовательности. Понимание их работы необходимо для построения более сложных и реалистичных сценариев, к которым мы перейдём позже.

Чтобы не повторять одни и те же настройки в каждом сценарии, мы создадим базовый класс пользователя, от которого будут наследоваться все остальные. Он задаёт:

/tools/locust/user.py

Locust ищет все классы, унаследованные от User, и считает их «реальными пользователями», которых нужно запускать. Но в нашем случае мы хотим использовать BaseLocustUser только как базу для других классов, чтобы переиспользовать общее поведение и настройки.

Поэтому мы выставляем:

Это позволяет избежать случайного запуска базового класса и делает архитектуру чище.

Locust требует, чтобы у каждого User было указано поле host. Обычно это базовый URL, к которому будут отправляться запросы через встроенный HTTP-клиент (например, HttpUser). Но в нашем случае:

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

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

В Locust существуют два базовых типа TaskSet:

Тип Особенность

TaskSet Задачи (tasks) выполняются в произвольном порядке, с учётом веса задач

SequentialTaskSet Задачи выполняются строго последовательно, сверху вниз

Чтобы не дублировать код в каждом сценарии, мы выносим базовую логику в два абстрактных класса:

/tools/locust/task_set.py

В этом разделе мы реализуем два типовых сценария нагрузки:

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

Второй сценарий работает с уже сидированными (заранее созданными) данными. Мы заранее создаём операции через API и сохраняем их. Затем, во время нагрузки, пользователь просто делает запросы: получает список, выбирает случайную операцию и запрашивает её детали. Это приближает тест к реальному поведению пользователей и даёт более стабильные и репрезентативные метрики.

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

Начнём с реализации самого простого сценария — без предварительно подготовленных данных.

Представим типичную пользовательскую активность: клиент заходит в приложение, совершает какую-либо финансовую операцию (например, покупку), затем переходит в раздел "история операций", просматривает список всех операций и выбирает одну для просмотра деталей. Это последовательный и логически связанный пользовательский поток, который мы и хотим нагрузить.

/scenarios/get_operation_without_seeds/scenario.py

Мы намеренно используем SequentialTaskSet, чтобы гарантировать порядок выполнения задач:

Если бы мы использовали обычный TaskSet, Locust бы выбирал задачи в случайном порядке, основываясь на их "весах", и мы бы столкнулись с ситуацией, когда запрос get_operation выполняется до создания операции — что привело бы к ошибкам.

Во многих сценариях веса задач указываются для моделирования вероятностей — например, операция "открыть документ" может встречаться чаще, чем "удалить аккаунт".

В данном случае мы используем SequentialTaskSet, а значит порядок жёстко зафиксирован и вес не играет никакой роли. Все задачи выполняются ровно один раз в том порядке, в котором они описаны. Поэтому декораторы @task без аргументов здесь абсолютно корректны.

Операция создаётся через внешний API. Это значит, что:

Если операция не создалась, нет смысла продолжать сценарий. Поэтому мы делаем проверку на None, и мягко выходим, не вызывая get_operation.

Такой подход:

/scenarios/get_operation_without_seeds/v1.0.conf

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

В отличие от ручного запуска с флагами в командной строке, .conf-файлы:

Кроме того, конфигурации мы версионируем — например, v1.0.conf, v2.0.conf. Это даёт нам возможность:

Таким образом, .conf-файл — это не просто способ запускать тесты, а часть архитектуры нагрузочного тестирования, обеспечивающая прозрачность, стабильность и масштабируемость.

Обратите внимание: в конфигурации указан умеренный профиль нагрузки — всего 20 пользователей, скорость запуска 2 пользователя в секунду, продолжительность 30 секунд. Это не случайность.

Мы работаем с тестовым API https://api.sampleapis.com/fakebank/accounts, у которого установлен рейт-лимит. При избыточной нагрузке сервис начинает возвращать ответы с кодом 429 Too Many Requests. Такие ошибки искажают результат тестирования и мешают сосредоточиться на логике сценария.

Поэтому:

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

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

Зачем это нужно?

/scenarios/get_operation_with_seeds/scenario.py

В этом сценарии порядок выполнения действий не важен:

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

В TaskSet веса задач управляют частотой вызовов:

То есть в данном случае распределение будет:

Это поведение задаёт соотношение реальных сценариев: пользователь чаще открывает конкретные детали операции, чем весь список.

Ключевой особенностью этого сценария является использование событийной системы Locust, а именно хука @events.init.add_listener:

Этот хук срабатывает один раз перед запуском теста, сразу после инициализации окружения Locust. Именно в нём мы и выполняем сидинг:

Почему именно здесь?

В методе on_start каждый виртуальный пользователь получает одну случайную операцию из общего результата сидинга. Далее он будет с ней работать.

Пользователь:

Задание get_operation весит в 3 раза больше, чем get_operations, что приближает поведение к реалистичному сценарию: пользователь может просмотреть список операций один раз, но конкретную операцию — несколько раз (или UI может отправлять такой запрос повторно).

Мы сохраняем результат в файл, потому что:

/scenarios/get_operation_with_seeds/v1.0.conf

Эта конфигурация повторяет структуру первого сценария. Используется умеренный профиль нагрузки, так как:

Настроим workflow-файл для автоматического запуска нагрузочных тестов в GitHub Actions, генерации Locust HTML-отчета с сохранением истории и публикации его на GitHub Pages.

/.github/workflows/load-tests.yaml

Ссылки на документацию для всех использованных actions можно найти ниже:

Даёт возможность запускать тесты вручную с выбором конфигурации. Удобно для запуска под конкретную версию нагрузки или перед релизом.

Чтобы каждый запуск имел свою уникальную папку с отчётом. Это позволяет:

Мы разделяем логику:

Это стандартная ветка GitHub Pages. Любой HTML-файл, добавленный туда, станет доступен по адресу https://<user>.github.io/<repo>/<путь>.

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

Если сейчас запустить нагрузочные тесты на GitHub Actions то, будет ошибка, говорящая о том, что у github token из workflow по умолчанию нет прав на записть в репзоиторий

Для исправления этой ошибки необходимо вручную изменить настройки прав workflow:

2. Перейдите в раздел Actions → General.

3. Прокрутите страницу вниз до блока Workflow permissions

4. Выберите опцию Read and write permissions

5. Нажмите кнопку Save для сохранения изменений

После выполнения этих шагов можно отправить код с нагрузочными тестами в удалённый репозиторий.

После того как вы настроили workflow-файл и закоммитили его в репозиторий, вы можете запускать нагрузочные тесты в один клик прямо из интерфейса GitHub.

После этого GitHub Actions запустит пайплайн: прогонит тест, сгенерирует HTML-отчёт Locust и (если всё настроено) опубликует его на GitHub Pages.

Если нагрузочные тесты пройдут успешно, Locust HTML-отчёт будет сгенерирован и загружен в ветку gh-pages, после чего автоматически запустится workflow pages build and deployment. Этот процесс публикует Locust HTML-отчёт на GitHub Pages, делая его доступным для просмотра в браузере.

Важно! Перед запуском workflow необходимо убедиться, что в репозитории существует ветка gh-pages. Если ветка отсутствует, её необходимо создать в удалённом репозитории, иначе публикация Locust HTML-отчёта на GitHub Pages не будет работать.

Если workflow pages build and deployment не запустился, необходимо проверить настройки GitHub Pages:

На этой же странице будет отображаться виджет со ссылкой на опубликованный Allure-отчёт.

По итогу, после корректной настройки, при каждом новом запуске нагрузочных тестов Locust HTML-отчёт будет автоматически сохраняться в ветку gh-pages и публиковаться на GitHub Pages.

Все ссылки на код, отчеты и запуски нагрузочных тестов в CI/CD можно найти на моем GitHub: