k6
Тема дорожной карты · QA-инженер
k6 — это современный, ориентированный на разработчиков инструмент нагрузочного тестирования с открытым исходным кодом, использующий JavaScript (ES6+) тест-скрипты для определения сценариев виртуальных пользователей, что делает его наиболее доступным инструментом нагрузочного тестирования для QA-инженеров и разработчиков, уже работающих в экосистемах JavaScript или TypeScript. Тест-скрипты k6 определяют сценарии с помощью options, задающих количество виртуальных пользователей, этапы нарастания нагрузки и пороговые значения — например, thresholds: { 'http_req_duration': ['p(95)<500'] } проваливает тест, если 95-й перцентиль времени ответа превышает 500 мс, — и используют модуль http для отправки запросов GET, POST и других с заголовками, телами и проверками, зеркально отображающими ассерции Postman. k6 легко встраивается в CI/CD-пайплайны: шаг GitHub Actions выполняет k6 run --vus 50 --duration 60s load_test.js и завершается с ненулевым кодом при превышении порогов, блокируя развёртывание в продакшен; пайплайны Jenkins используют ту же команду внутри Docker-агента с образом grafana/k6. Вывод k6 поступает в InfluxDB + Grafana для дашбордов в реальном времени во время прогонов нагрузки, или экспортируется в k6 Cloud для исторического сравнения, а ассерции функции check() интегрируются с Allure Report через расширение xk6-output-junit для унифицированной отчётности. По сравнению с Apache JMeter и Locust, k6 обеспечивает более низкие операционные накладные расходы для чистого HTTP/WebSocket нагрузочного тестирования и лучшую интеграцию с CI/CD, тогда как JMeter остаётся предпочтительным для сложных мультипротокольных сценариев, а Locust — для Python-команд, нуждающихся в программируемых формах нагрузки.
Как это работает
k6 валидирует поведение системы под нагрузкой. Инструменты: k6 (современный, на JavaScript, рекомендуется), JMeter (legacy, Java, GUI), Locust (Python, скриптуемый), Gatling (Scala, code-first), Artillery (Node). Типы: load (ожидаемый трафик, sustained), stress (за пределами ожидаемого — точка слома), spike (внезапный всплеск), soak (многочасовая выдержка — ловит утечки), capacity (максимум sustainable). Метрики: throughput (req/s), latency (p50, p95, p99), error rate.
Когда применять
Гоняйте perf-тесты до запуска (find capacity), до major-релизов (regression), после изменений архитектуры. Тестируйте против production-shaped среды — не "ноут с моками". Всегда меряйте p95/p99 latency, не только average (average прячут outliers). Распределённую load-generation — если трафик > одной машины. SLO сначала; perf-тесты их верифицируют.
Типичные ошибки
Ловушки k6: load-тестируете свой ноут вместо целевой среды (результаты бесполезны); не прогрели систему до замеров (cold-cache цифры неверны); load генерируется из той же сети, что и target (меряете локальную сеть, не систему); не тестируете think-time (реальные юзеры не долбят refresh постоянно).