k6 | QA Hub

k6 позволяет описывать нагрузочные проверки кодом, хранить их рядом с приложением и запускать повторяемо. Обычный HTTP-сценарий создаёт сетевые запросы без рендеринга пользовательского интерфейса. Измеренная задержка API помогает оценить сервис, но не равна времени, за которое пользователь увидел готовую страницу.

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

Сценарий начинается с требования

Опишите операцию и контекст. Например: каталог должен обслуживать согласованный поток чтений при заданном объёме товаров. Уточните долю ошибок, допустимые задержки, длительность стабильного участка и состояние кэша. Эти условия фиксируют до измерения.

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

Выбор модели нагрузки

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

Executor constant-arrival-rate задаёт частоту начала итераций. Это частота итераций, а не автоматически запросов: внутри одной итерации может быть несколько обращений. Для поддержания потока нужны свободные VU и ресурсы. Если их не хватает, часть итераций не запускается; анализируйте dropped_iterations вместе с задержкой.

Минимальный HTTP-скрипт

В примере собственный endpoint /api/catalog обязан возвращать объект с массивом items. Сохраните код в catalog.js. Пороги ниже учебные: их заменяют критериями проекта. Скрипт требует установленного k6 и доступного согласованного стенда.

javascript

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    catalog: {
      executor: 'constant-arrival-rate',
      rate: 5,
      timeUnit: '1s',
      duration: '1m',
      preAllocatedVUs: 10,
      maxVUs: 20,
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
    checks: ['rate>0.99'],
    dropped_iterations: ['count==0'],
  },
};

export default function () {
  const res = http.get(`${__ENV.BASE_URL}/api/catalog`, {
    timeout: '5s',
    tags: { name: 'catalog' },
  });
  let valid = false;
  try {
    valid = Array.isArray(res.json().items);
  } catch (_) {
    valid = false;
  }
  check(res, {
    'catalog status is 200': (r) => r.status === 200,
    'catalog contains items array': () => valid,
  });
}

shell

k6 run -e BASE_URL=https://qa.example.test catalog.js

Начните с меньшей интенсивности, если ресурсный бюджет стенда неизвестен. Для arrival-rate не добавляйте sleep только ради поддержания заданной частоты: запуск итераций уже регулирует executor. Ожидание внутри реальной бизнес-цепочки добавляют по смыслу модели.

Checks и thresholds

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

В примере проверяется транспортный результат и структура JSON. Threshold checks связывает такие проверки с итогом запуска, а http_req_failed контролирует другую метрику. Для разных операций полезны отдельные метки и пороги: быстрый каталог не должен скрывать медленное создание заказа в общей статистике.

Данные и связность шагов

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

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

Как подготовить эксперимент

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

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

Наблюдение ресурсов

На генераторе смотрите CPU, память, сеть и число незапущенных итераций. Если он не способен создать нужный поток, результат не подтверждает предел сервера. Увеличение maxVUs может лишь увеличить расход памяти, не устранить сетевое ограничение.

На приложении наблюдайте CPU, память, очереди, базу и пулы соединений. Сопоставьте временной интервал с метриками k6. Например, рост p95 одновременно с ожиданием свободного соединения помогает выбрать следующую диагностическую проверку. Без серверных наблюдений вывод «база тормозит» остаётся предположением.

Как читать итог

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

Для примера ожидается согласованный JSON, отсутствие dropped_iterations и выполнение заранее выбранных порогов на измеряемом участке. Успех этого запуска описывает только чтение каталога в указанных условиях. Он не подтверждает скорость интерфейса, оплаты или поведение при значительно большем объёме данных.

Ошибки и место в CI

Частые ошибки — считать checks достаточным quality gate, путать VU с RPS, тестировать только статус и скрывать падение генерации. Нельзя также переносить результаты со случайного ноутбука на рабочую инфраструктуру без оценки различий.

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

k6