Разработка нагрузочных тестов для сайта (Artillery)

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Разработка нагрузочных тестов для сайта (Artillery)
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

500-е ошибки во время распродаж — типичная боль для e-commerce. Если пиковая нагрузка в 10 000 RPS ложит сервер, вы теряете до 1 млн рублей в час. Чтобы избежать простоев, мы проводим нагрузочное тестирование с Artillery. Этот инструмент симулирует тысячи одновременных пользователей, показывая, как система ведёт себя под давлением. Перед запуском акций или нового функционала мы моделируем сценарии: просмотр каталога, поиск, оформление заказа. В результате вы получаете не просто отчёт, а конкретные шаги по оптимизации — от настройки кеширования до индексов БД. Наши клиенты экономят до 500 000 рублей на каждом инциденте благодаря своевременному выявлению узких мест. Оценка проекта занимает 1 день, после чего мы даём детальный отчёт с рекомендациями. Свяжитесь с нами, чтобы получить консультацию.

Как Artillery помогает выявить узкие места?

Artillery — Node.js-инструмент с YAML-конфигурацией, поддерживающий HTTP и WebSocket. Он генерирует нагрузку по фазам: разогрев, ступенчатый рост, пик. На каждом этапе мы отслеживаем latency, error rate и throughput. Если p99 превышает 1 секунду или 5xx ошибки >1% — это сигнал к оптимизации. Например, в одном проекте на Laravel задержка возникала из-за N+1 запроса к базе при просмотре каталога. Тест с 50 RPS выявил рост p95 до 3 с. После добавления eager loading p95 упал до 200 мс. Подробнее о нагрузочном тестировании читайте в Wikipedia.

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

Artillery проще K6 в настройке: не нужен JS-код для простых сценариев, только YAML. По сравнению с JMeter, Artillery легче интегрируется в CI/CD: одна команда artillery run и JSON-отчёт. Нагрузка распределяется на несколько воркеров, что даёт до 100 000 RPS с одной машины (при правильной конфигурации). По нашим тестам, Artillery в 2 раза быстрее генерирует отчёт, чем K6, при аналогичной нагрузке.

Пример развёрнутого YAML-сценария
# tests/load/basic.yml
config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 5
      name: Warm up
    - duration: 120
      arrivalRate: 20
      name: Ramp up load
    - duration: 300
      arrivalRate: 50
      name: Sustained load
    - duration: 60
      arrivalRate: 100
      name: Stress test
  defaults:
    headers:
      Accept: "application/json"
      Content-Type: "application/json"
  ensure:
    p99: 1000
    p95: 500
    maxErrorRate: 1
scenarios:
  - name: Browse catalog
    weight: 60
    flow:
      - get:
          url: "/api/products"
          expect:
            - statusCode: 200
            - hasProperty: "data"
      - think: 2
      - get:
          url: "/api/products/{{ $randomNumber(1, 100) }}"
  - name: Search
    weight: 30
    flow:
      - get:
          url: "/api/search?q={{ $randomString() }}"
          expect:
            - statusCode: [200, 404]
  - name: Contact form
    weight: 10
    flow:
      - post:
          url: "/api/contact"
          json:
            name: "Test User"
            email: "[email protected]"
            message: "Load test message"
          expect:
            - statusCode: 201

Как написать сценарий нагрузочного теста за 5 шагов?

  1. Определите критические эндпоинты: каталог, поиск, корзина, оформление заказа.
  2. Установите SLA: p99 < 1 с, error rate < 1%.
  3. Напишите YAML-сценарий с фазами нагрузки: разогрев, ступенчатый рост, пик.
  4. Добавьте авторизацию, если требуется (capture токена).
  5. Запустите тест локально, проверьте корректность, затем интегрируйте в пайплайн.

Основные сценарии Artillery

Сценарий с авторизацией

# tests/load/authenticated.yml
config:
  target: "https://staging.example.com"
  phases:
    - duration: 300
      arrivalRate: 20
  variables:
    users:
      - email: "[email protected]"
        password: "pass123"
      - email: "[email protected]"
        password: "pass456"
scenarios:
  - name: Authenticated user flow
    flow:
      - post:
          url: "/api/auth/login"
          json:
            email: "{{ users[0].email }}"
            password: "{{ users[0].password }}"
          capture:
            - json: "$.access_token"
              as: "token"
          expect:
            - statusCode: 200
      - get:
          url: "/api/user/profile"
          headers:
            Authorization: "Bearer {{ token }}"
          expect:
            - statusCode: 200
      - post:
          url: "/api/orders"
          headers:
            Authorization: "Bearer {{ token }}"
          json:
            product_id: 1
            quantity: 1
          expect:
            - statusCode: 201
          capture:
            - json: "$.id"
              as: "orderId"
      - get:
          url: "/api/orders/{{ orderId }}"
          headers:
            Authorization: "Bearer {{ token }}"
          expect:
            - statusCode: 200

Кастомный JS-процессор

# tests/load/custom.yml
config:
  processor: "./processor.js"
scenarios:
  - name: Dynamic flow
    flow:
      - function: "generateDynamicPayload"
      - post:
          url: "/api/data"
          json: "{{ payload }}"
// processor.js
module.exports = { generateDynamicPayload };
function generateDynamicPayload(context, events, done) {
    context.vars.payload = {
        id: Math.floor(Math.random() * 10000),
        timestamp: new Date().toISOString(),
        data: Array.from({ length: 10 }, (_, i) => ({ key: `item_${i}`, value: Math.random() })),
    };
    return done();
}

GitHub Actions

- name: Load Test
  run: |
    artillery run --output results.json tests/load/basic.yml
    artillery report --output load-report.html results.json
- name: Check SLA
  run: |
    ERRORS=$(cat results.json | jq '.aggregate.counters["http.codes.5xx"] // 0')
    P99=$(cat results.json | jq '.aggregate.latency.p99')
    if [ "$ERRORS" -gt "10" ] || [ "$(echo "$P99 > 2000" | bc)" = "1" ]; then
      echo "Load test failed: too many errors or high latency"
      exit 1
    fi

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

Инструмент Язык сценариев WebSocket Распределённая нагрузка CI/CD интеграция Наша оценка
Artillery YAML + JS Да Встроенная Из коробки Отлично
Apache JMeter XML, Groovy Да Через удалённые серверы Плагины Хорошо
k6 JS Нет Через воркеры Отличная Хорошо

Типичные ошибки при нагрузочном тестировании

  • Тестирование только одного эндпоинта, игнорируя бизнес-процессы.
  • Неправильная эмуляция пользовательского поведения (например, отсутствие think time).
  • Запуск нагрузки с одного IP (блокировка на уровне сети).
  • Игнорирование кеширования на уровне приложения.
  • Отсутствие мониторинга серверных метрик (CPU, RAM, DB connections).

Этапы разработки нагрузочных тестов

Этап Длительность Результат
Анализ текущей архитектуры 0.5 дня Список критических эндпоинтов, SLA-параметры
Написание сценариев 1–2 дня YAML-конфигурации для 3–5 сценариев
Пробный прогон, отладка 0.5 дня Исправление ошибок, корректная эмуляция
Запуск на staging 1 день Сбор метрик, подготовка отчёта
Финальный отчёт + рекомендации 0.5 дня PDF-отчёт с графиками и советами по оптимизации

Что входит в работу

  • Документация: техническое задание, описание сценариев, инструкция по запуску.
  • Сценарии: 3–5 YAML-файлов с поддержкой авторизации, WebSocket, кастомных процессоров.
  • Отчёт: HTML-дашборд с метриками (latency, RPS, errors), JSON-данные для CI.
  • Рекомендации: список узких мест и конкретные шаги по улучшению (индексы, кеши, репликация).
  • Поддержка: 1 месяц консультаций после сдачи.

Наш опыт — 50+ проектов в e-commerce и SaaS. После выполнения работ вы получите чёткое понимание пропускной способности сайта и сможете предотвратить падения в пик. Закажите разработку нагрузочных тестов и будьте уверены в стабильности вашего сайта. Получите консультацию: мы протестируем ваш сайт под нагрузкой и дадим рекомендации.

Сроки ориентировочно

Разработка 3–5 сценариев под ключ занимает от 2 до 5 дней в зависимости от сложности. Стоимость рассчитывается индивидуально после анализа вашего проекта.

Почему юнит-тесты важны, но не панацея?

Баг, найденный юнит-тестом, стоит минуты исправления. Тот же баг в продакшене — часы инцидента, компенсации и потеря доверия. На проекте интернет-магазина ошибка в расчёте скидки прошла ручное тестирование, попала в прод и за 4 часа обработала 37 заказов по нулевой цене. Автотест на граничные случаи расчёта поймал бы её при первом же push. Оцените свой проект — мы проведём аудит текущего покрытия и дадим рекомендации.

Jest — стандарт для JavaScript/TypeScript, но юнит-тесты оправданы только там, где есть изолированная логика: функции трансформации, валидаторы, бизнес-правила, утилиты. Тестировать React-компоненты через Jest + Testing Library правильно для поведенческих тестов: «кнопка появляется после загрузки», «форма показывает ошибку при пустом email». Снепшот-тесты (toMatchSnapshot) — ловушка: они ломаются при любом изменении вёрстки и становятся шумом, который разработчики обновляют не глядя. Покрытие кода (code coverage) — плохая метрика качества: 80% coverage можно получить тестами, которые ничего не проверяют. Coverage показывает, что код выполнился, а не то, что он работает правильно.

Критерий Jest Vitest
Скорость для больших проектов Средняя (Babel-трансформация) В 10–20 раз быстрее (ES modules)
Интеграция с Vite Через плагин Нативная
Монорепозитории Требует конфигурации Из коробки

Vitest как альтернатива Jest для Vite-проектов: в 10–20 раз быстрее за счёт нативных ES modules без трансформации через Babel. Для монорепозиториев с тысячами тестов разница в скорости ощутима. Подробнее о юнит-тестировании.

Как настроить E2E тесты, которые не будут flaky?

Playwright обошёл Cypress по ключевым параметрам: нативная поддержка multi-tab, multi-origin, iframe; параллельное выполнение на уровне тестов; WebKit, Firefox, Chromium из коробки; нет iframe для приложения — тесты работают в реальном браузере.

Playwright codegen записывает действия и генерирует тест — хорошая точка старта, но сгенерированный код нужно рефакторить. Локаторы по text content хрупки: getByRole('button', { name: 'Оформить заказ' }) — устойчивее, чем locator('.btn-primary').

Page Object Model — стандарт организации E2E тестов. Каждая страница — отдельный класс с методами вместо прямых локаторов. Когда кнопка переехала из хедера в сайдбар — меняем в одном месте, не ищем по всем тестам.

Как избежать flaky тестов? Типичная проблема — flaky tests. Причины: race condition между запросом и рендером, анимации без ожидания, зависимость от внешних API. Решение: `page.waitForResponse()` вместо `page.waitForTimeout()`, мокирование внешних API через `page.route()`.
// Плохо
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Хорошо
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /заказ создан/i })).toBeVisible();

Наши инженеры гарантируют стабильность тестов в CI. Документация Playwright — основной инструмент на проектах с миллионами пользователей.

Нагрузочное тестирование с k6

k6 — инструмент для нагрузочного тестирования с JavaScript API. Сценарии пишутся как код, версионируются в git, запускаются в CI. Три основных сценария:

  • Spike test — резкий рост нагрузки: 0 → 1000 пользователей за 30 секунд. Имитирует запуск рекламной кампании. Показывает способность системы реагировать на пики.
  • Soak test — стабильная нагрузка на 2–4 часа. Выявляет memory leaks, connection pool exhaustion, деградацию производительности.
  • Stress test — нагрузка выше расчётной (150–200% от ожидаемого пика). Показывает точку отказа и graceful degradation.

Пороговые значения:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms означает: 95% запросов отвечают быстрее полусекунды. Если порог не выполняется — k6 завершается с кодом ошибки, CI-пайплайн падает.

На одном проекте интернет-магазина мы выявили деградацию API на 4-й час теста: p95 вырос с 200ms до 2s из-за утечки соединений. После оптимизации клиент сэкономил около $15,000 в год на инцидентах и лишних ресурсах. Получите аналогичный аудит вашего проекта — закажите нагрузочное тестирование.

Как Core Web Vitals влияют на ранжирование?

Google использует Core Web Vitals в ранжировании. Lighthouse CLI в CI-пайплайне: при каждом деплое проверяем, что LCP < 2.5s, CLS < 0.1, INP < 200ms. Подробнее о веб-производительности. Реальные проблемы, которые Lighthouse находит:

  • Hero image без width/height атрибутов: CLS 0.35 при загрузке.
  • JavaScript-бандл 2.1MB синхронно блокирует парсинг: INP 450ms.
  • Шрифты без font-display: swap: невидимый текст до загрузки шрифта (FOIT).
  • Неоптимизированный hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) сохраняет историю метрик и отправляет комментарий к PR с деградацией. По данным Google, 53% пользователей покидают сайт при загрузке дольше 3 секунд — наши тесты предотвращают такие потери.

Пирамида тестирования в проекте

Уровень Инструмент Количество Скорость
Юнит Vitest/Jest Много (тысячи) <5 мин
Интеграция Vitest + supertest Среднее 5–15 мин
E2E Playwright Немного (happy path) 10–30 мин
Нагрузка k6 По расписанию 30–60 мин
Performance Lighthouse CI При каждом деплое 5 мин

Что входит в работу?

  • Аудит текущего покрытия и определение критических user flows.
  • Написание unit-тестов для ключевой бизнес-логики, интеграционных тестов для API, E2E для сценариев пользователя.
  • Настройка параллельного выполнения в CI (sharded workers для Playwright).
  • Нагрузочное тестирование с отчётом и рекомендациями.
  • Документация по тест-кейсам, обучение вашей команды работе с тестами.
  • Гарантийная поддержка 1 месяц после внедрения.

Процесс работы

  1. Аналитика — аудит текущего тестирования, выявление слабых мест, определение приоритетов.
  2. Проектирование — выбор инструментов, написание тест-плана, согласование.
  3. Реализация — написание тестов, интеграция в CI.
  4. Тестирование — прогон всех уровней, анализ результатов, исправление ошибок.
  5. Деплой — запуск в прод, мониторинг метрик, обучение команды.

Сроки

Настройка полного тест-пайплайна (Jest + Playwright + k6 + Lighthouse CI) с нуля: 2–4 недели. Покрытие E2E-тестами существующего проекта (20–30 сценариев): 3–6 недель. Нагрузочное тестирование с отчётом и рекомендациями: 1–2 недели. Стоимость рассчитывается индивидуально после аудита.

Готовы обсудить ваш проект? Оставьте заявку — мы проведём аудит текущего тестирования бесплатно и предложим план с экономией до 60% времени на инциденты. Получите консультацию по тестированию веб-приложений — напишите нам.