Навантажувальне тестування у 2026 році: види, метрики, інструменти й перший тест

Сайт, який чудово працює для одного тестувальника, може «лягти» в перший день розпродажу, після розсилки чи згадки в новинах. Навантажувальне тестування відповідає на запитання, які функціональні тести не ставлять: скільки користувачів витримає система, як швидко вона відповідає під навантаженням, де вузьке місце і що станеться, коли ресурсів забракне.

У статті пояснюємо види тестів продуктивності, метрики, на які варто дивитися, як спланувати перший тест, які інструменти обрати та як не отримати красиві, але безглузді цифри.

Короткий вибір

Види тестів продуктивності

«Навантажувальним тестуванням» часто називають усю перевірку продуктивності, але насправді це кілька різних тестів із різними цілями:

• Димовий тест навантаження (smoke) — 1–5 віртуальних користувачів протягом хвилини. Перевіряє, що сценарій узагалі працює, перш ніж запускати щось велике.
• Навантажувальний тест (load) — очікувана звичайна або пікова кількість користувачів. Відповідає на запитання «чи впорається система з нашим реальним трафіком і чи вкладаємося ми у вимоги».
• Стрес-тест (stress) — навантаження поступово зростає вище норми, доки система не почне деградувати. Показує межу й те, як система ламається: повільно сповільнюється чи раптово падає з помилками.
• Пікове навантаження (spike) — різкий стрибок користувачів за секунди, як після пуш-сповіщення чи старту продажу квитків.
• Тест на витривалість (soak, endurance) — помірне навантаження протягом годин. Виявляє витоки пам’яті, переповнення дисків і з’єднань, які не видно за 10 хвилин.
• Тест масштабованості — як змінюється пропускна здатність, коли додаємо сервери чи ресурси.
• Тест ємності (capacity) — скільки користувачів система витримує, зберігаючи прийнятну швидкість.

Ключові метрики

• Час відповіді (response time, latency). Дивіться не на середнє, а на перцентилі: p95 = 800 мс означає, що 95 % запитів виконалися швидше за 800 мс, а 5 % — повільніше. Середнє приховує «хвіст» повільних запитів, на який скаржаться реальні користувачі.
• Пропускна здатність (throughput) — запити або транзакції на секунду (RPS, TPS).
• Частка помилок (error rate) — відсоток відповідей 5xx, таймаутів і неуспішних перевірок.
• Одночасні користувачі (віртуальні користувачі, VU) — скільки сценаріїв виконуються паралельно.
• Ресурси системи — процесор, пам’ять, диск, мережа, з’єднання з базою, довжина черг. Без них цифри з генератора навантаження не пояснюють, чому система сповільнилася.
• Показники для користувача — для вебсторінок це Core Web Vitals (LCP, INP, CLS), які вимірює Lighthouse.

Вимоги краще записувати як конкретні критерії (SLO): «p95 для оформлення замовлення < 1 с, помилок < 1 % при 500 одночасних користувачах». Такі пороги інструменти на кшталт Grafana k6 і Taurus перевіряють автоматично й «валять» прогін у CI, якщо їх перевищено.

Як спланувати навантажувальний тест

1. Сформулюйте мету. «Перевірити, що каталог витримає 3× трафіку чорної п’ятниці» — мета; «подивитися, скільки RPS» — ні.

2. Зберіть профіль навантаження. Які сценарії виконують користувачі й у якій пропорції (наприклад, 70 % переглядають каталог, 20 % шукають, 10 % купують), скільки їх у пік. Джерела — аналітика, логи вебсервера, моніторинг.

3. Опишіть сценарії реалістично. Паузи між діями (think time), різні тестові дані замість одного й того самого товару, авторизація, кешування, як у справжніх користувачів.

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

5. Налаштуйте моніторинг сервера, бази й залежностей до запуску тесту.

6. Почніть із smoke-тесту, потім поступово нарощуйте навантаження.

7. Аналізуйте й повторюйте. Знайшли вузьке місце, виправили, запустили той самий тест і порівняли результати.

Відкриті інструменти

• Grafana k6 — сценарії на JavaScript, вбудовані перевірки й пороги, зручний запуск у CI та хмарний варіант Grafana Cloud k6. Для нових проєктів — вибір за замовчуванням.
• Apache JMeter — графічний редактор тест-планів, запис сценаріїв через проксі, найширша підтримка протоколів (HTTP, JDBC, JMS, FTP тощо) і тисячі статей. Досі найчастіше трапляється у вакансіях перформанс-тестувальників.
• Gatling — сценарії як код на Java, Kotlin, Scala чи JavaScript і детальні HTML-звіти; ефективно генерує велике навантаження.
• Locust — поведінку користувачів описують звичайним кодом на Python, а вебінтерфейс показує результати в реальному часі.
• Artillery — сценарії в YAML або JavaScript, HTTP, WebSocket і навантаження справжніми браузерами через Playwright.
• Taurus — короткий YAML-конфіг поверх JMeter, Gatling чи Locust із критеріями успіху для CI.
• NBomber — для .NET-команд: сценарії на C# чи F#. Для особистого використання безкоштовний, для комерційного потрібна ліцензія.

Для швидких замірів без сценаріїв підійдуть утиліти командного рядка: oha з живими графіками в терміналі, wrk для максимального навантаження з однієї машини та Vegeta з постійною частотою запитів.

Хмарні й корпоративні платформи

Коли одного комп’ютера не вистачає, щоб згенерувати потрібне навантаження, або треба навантажувати з різних регіонів:

• BlazeMeter запускає сценарії JMeter, Gatling, Locust і k6 у хмарі; безкоштовний тариф — до 50 віртуальних користувачів і 10 тестів на місяць.
• Azure Load Testing запускає сценарії JMeter і Locust у хмарі Microsoft і поруч показує метрики ресурсів Azure.
• NeoLoad від Tricentis розрахований на великі компанії: веб, мобільні застосунки, API, SAP і АІ-аналіз результатів.
• Loader.io — найпростіший старт: тест налаштовується в браузері, безкоштовно до 10 000 клієнтів на хвилинний тест.

Моніторинг під час тесту

Генератор навантаження покаже, що система сповільнилася, а моніторинг — чому. Обов’язково стежте за серверами, базою й залежностями під час прогону:

• Prometheus збирає метрики із застосунків і серверів, а Grafana показує на одному дашборді і результати k6 чи JMeter, і стан системи. Це найпоширеніший відкритий стек.
• Datadog і New Relic — комерційні платформи з трасуванням запитів (APM): видно, який сервіс чи SQL-запит забирає час. New Relic має безкоштовний тариф зі 100 ГБ даних на місяць.
• Sentry покаже помилки й повільні транзакції, що з’являються під навантаженням.

Типові вузькі місця: повільні SQL-запити без індексів, вичерпаний пул з’єднань із базою, блокування, відсутність кешу, синхронні виклики зовнішніх сервісів, ліміти пам’яті контейнерів.

Продуктивність фронтенду

Навантажувальні тести перевіряють сервер, але користувач відчуває ще й швидкість сторінки в браузері:

• Lighthouse — аудит продуктивності й Core Web Vitals прямо в Chrome DevTools;
• GTmetrix — звіт із «водоспадом» запитів, щоб побачити, що саме гальмує завантаження;
• sitespeed.io — регулярні заміри в справжніх браузерах із відео завантаження та моніторингом у Grafana.

Як знайти й виправити саме такі проблеми — Core Web Vitals, бандли, моніторинг реальних користувачів — читайте в статті «Тестування продуктивності фронтенду».

Гарна практика — поєднувати обидва підходи: навантажувати бекенд у Grafana k6 чи Artillery і паралельно вимірювати, як під цим навантаженням відкривається сторінка для одного користувача.

Типові помилки

• Дивитися на середній час відповіді замість p95/p99.
• Генератор навантаження — вузьке місце. Якщо процесор вашого ноутбука завантажений на 100 %, ви вимірюєте ноутбук, а не сервер.
• Нереалістичні дані: усі віртуальні користувачі входять під одним акаунтом і відкривають той самий товар, тож усе береться з кешу.
• Без пауз між діями — 100 «користувачів» без think time створюють навантаження, як тисячі реальних.
• Тест на нерепрезентативному середовищі або з порожньою базою.
• Немає моніторингу сервера, тож причину сповільнення доводиться вгадувати.
• Ігнорування помилок: швидкі відповіді 500 «покращують» середній час, але це падіння, а не успіх.
• Одноразовий тест перед релізом замість регулярних прогонів у CI, які помічають погіршення одразу.

Де потренуватися

Безпечно навантажувати можна лише власні системи. Найпростіше підняти локально навчальний застосунок, наприклад Conduit чи Cypress Real World App, або власний API в Docker, і вже на ньому писати сценарії. Для мінімальних експериментів підійде локальний httpbin — він уміє відповідати із заданою затримкою. Деякі сервіси, як-от ParaBank, позиціонують себе як майданчик і для навантажувальних тестів, але публічні тренажери спільні для всіх, тож обмежуйтеся невеликим навантаженням.

План навчання на місяць

Безкоштовні курси з тестування й автоматизації є на Test Automation University.

АІ в навантажувальному тестуванні

АІ-асистенти, як-от GitHub Copilot, Cursor чи Claude Code, допомагають швидко написати сценарій k6 чи Locust за описом або з HAR-файлу, згенерувати тестові дані й пояснити графіки. Комерційні платформи на кшталт NeoLoad і New Relic додають АІ-аналіз результатів і пошук першопричини. Але профіль навантаження, вимоги й висновки — усе одно відповідальність людини: АІ не знає, скільки покупців прийде на ваш розпродаж.

Більше про інструменти — у статтях «Інструменти для автоматизації тестування» та «Тестування API». Усі інструменти з цієї статті є в підкатегорії Тестування.

Часті запитання

Чим навантажувальне тестування відрізняється від стрес-тестування?

Навантажувальний тест перевіряє систему на очікуваному навантаженні, стрес-тест — вище норми, щоб знайти межу й побачити, як система ламається.

k6 чи JMeter?

k6 зручніший для команд, які пишуть тести як код і запускають їх у CI. JMeter має графічний інтерфейс, більше протоколів і частіше трапляється у вакансіях. Обидва безкоштовні.

Скільки віртуальних користувачів потрібно?

Стільки, скільки реальних одночасних користувачів ви очікуєте в пік, з запасом (часто ×2–3). Число береться з аналітики, а не «про всяк випадок мільйон».

Чи можна тестувати навантаження на продакшні?

Можна, але лише плануючи заздалегідь: у години найменшого трафіку, з моніторингом, погодженням з командою і готовністю зупинити тест.

Не знаєте, з чого почати?

Запитайте Елю: вона підбере інструменти навантажувального тестування під ваш стек і задачу.

Дата перевірки фактів: 4 листопада 2026 року. Умови сервісів можуть змінюватися, тож перевіряйте їх на офіційних сайтах.