Розробка навантажувальних тестів для сайту з k6

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

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

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Розробка навантажувальних тестів для сайту з k6
Середній
~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

Ви запускаєте новий реліз, а сайт падає при першому сплеску трафіку. Або ваш API починає гальмувати при 1000 concurrent запитів, хоча ви обіцяли 5000. Знайомо? Ми стикаємося з такими ситуаціями постійно. Наші інженери з 10+ річним досвідом у навантажувальному тестуванні допомагають виявити вузькі місця до того, як вони стануть проблемою. За 5 років на ринку ми реалізували понад 50 проєктів з навантажувального тестування для сайтів, API та мікросервісів. Розробляємо навантажувальні тести під ключ з використанням k6 — сучасного інструменту від Grafana Labs. Отримайте консультацію — оцінимо ваш проєкт за 2 дні.

Типові проблеми, які виявляють навантажувальні тести

  • N+1 запити в API — типова проблема, коли ORM генерує сотні запитів до БД. k6 виявляє зростання часу відповіді при збільшенні навантаження.
  • Неоптимальні алгоритми кешування — Redis або Memcached можуть перевантажувати мережу при неправильній конфігурації. Тести показують вузькі місця.
  • Повільні збірки фронтенду — неоптимальний bundle splitting призводить до великих завантажень. k6 емулює реальних користувачів.

Тестування допомагає заощадити до 50% бюджету на підтримку та скорочує час пошуку вузьких місць у 3 рази.

Чому k6 — найкращий вибір для навантажувального тестування?

k6 в 2 рази швидше налаштовується, ніж JMeter, і не потребує графічного інтерфейсу. Сценарії пишуться на JavaScript, що дозволяє легко інтегрувати їх у ваш CI/CD пайплайн. Вбудовані метрики та порогові значення (thresholds) забезпечують об'єктивну оцінку продуктивності. Детальніше про k6 thresholds.

Як ми це робимо: стек та інтеграція

Наші інженери налаштовують оточення під ваш проєкт. Використовуємо:

  • k6 v0.49 (стабільна версія)
  • Node.js 20 для генерації тестових даних
  • Docker для ізольованого запуску тестів
  • InfluxDB 2 для зберігання метрик
  • Grafana 10 для дашбордів у реальному часі

Приклад інтеграції з GitLab CI:

load-test:
  script:
    - docker run --rm -v $CI_PROJECT_DIR:/tests grafana/k6 run /tests/script.js

Як інтерпретувати результати тестів?

Після виконання тесту k6 виводить зведення:

✓ http_req_duration.............: avg=132ms min=45ms med=112ms max=1.2s p(90)=245ms p(95)=380ms
✓ http_req_failed...............: 0.12%  ✓ 4 / ✗ 3312
✗ http_req_duration{p(99)}......: avg=980ms min=780ms — перевищило 2000ms поріг

Ключові показники:

  • p(95) — 95% запитів швидші за цей час. Якщо поріг 500ms, а p(95)=380ms — все добре.
  • http_req_failed — відсоток помилок. Має бути <1% (або <0.1% для високонавантажених систем).
  • Порогові значення — якщо перевищені, тест вважається проваленим. Ми налаштовуємо їх під ваш SLA.

Ключові метрики та їх порогові значення

Метрика Опис Типовий поріг Коли перевищення критичне
http_req_duration p(95) 95% запитів швидші <500 ms Користувацькі сценарії
http_req_failed Частка помилкових запитів <1% Будь-який тест
http_req_waiting Час очікування відповіді <400 ms API
iteration_duration Час однієї ітерації <2 s Комплексні сценарії

Що входить в роботу

  • Аналіз архітектури та цільових метрик SLA
  • Розробка сценаріїв: smoke, load, stress, soak
  • Інтеграція з Grafana/InfluxDB для візуалізації
  • Документація з результатами та рекомендаціями
  • Навчання вашої команди запуску та модифікації тестів
  • Підтримка протягом 30 днів після здачі

Порівняння типів тестів

Тип Мета Тривалість Навантаження
Smoke Перевірка базової функціональності 30-60 сек 1-5 VUs
Load Типове навантаження 10-30 хв 50-100% від очікуваного
Stress Пікове навантаження 5-10 хв 150-200% від очікуваного
Soak Довготривала стабільність 1-24 год 80% від очікуваного

Приклади сценаріїв

Базовий сценарій (smoke)

// scripts/smoke-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate } from 'k6/metrics';

const errorRate = new Rate('error_rate');

export const options = {
    vus: 10,
    duration: '30s',
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed:   ['rate<0.01'],
        error_rate:        ['rate<0.05'],
    },
};

export default function () {
    const res = http.get('https://staging.example.com/api/products');
    const ok = check(res, {
        'status is 200':        r => r.status === 200,
        'response time < 500ms': r => r.timings.duration < 500,
        'has data array':        r => r.json('data') !== undefined,
    });
    errorRate.add(!ok);
    sleep(1);
}

Ramping-сценарій (наростаюче навантаження)

export const options = {
    stages: [
        { duration: '2m', target: 10 },
        { duration: '5m', target: 10 },
        { duration: '2m', target: 50 },
        { duration: '5m', target: 50 },
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 0 },
    ],
    thresholds: {
        http_req_duration: ['p(99)<2000'],
        http_req_failed:   ['rate<0.02'],
    },
};

Сценарій з авторизацією

import http from 'k6/http';
import { check, group, sleep } from 'k6';
import { SharedArray } from 'k6/data';

const users = new SharedArray('users', () =>
    JSON.parse(open('./data/users.json'))
);

export default function () {
    const user = users[Math.floor(Math.random() * users.length)];

    let loginRes;
    group('Login', () => {
        loginRes = http.post('https://staging.example.com/api/auth/login',
            JSON.stringify({ email: user.email, password: user.password }),
            { headers: { 'Content-Type': 'application/json' } });
        check(loginRes, {
            'login successful': r => r.status === 200,
            'token received':   r => r.json('access_token') !== undefined,
        });
    });

    const token = loginRes.json('access_token');
    const headers = { Authorization: `Bearer ${token}` };
    sleep(1);

    group('Browse Products', () => {
        const res = http.get('https://staging.example.com/api/products?page=1', { headers });
        check(res, { 'products loaded': r => r.status === 200 });
        sleep(2);
    });

    group('Create Order', () => {
        const res = http.post('https://staging.example.com/api/orders',
            JSON.stringify({ product_id: 1, quantity: 1 }),
            { headers: { ...headers, 'Content-Type': 'application/json' } });
        check(res, { 'order created': r => r.status === 201 });
    });
    sleep(1);
}

Як провести навантажувальне тестування за 5 кроків

  1. Визначте сценарії використання та цільові метрики (SLA).
  2. Напишіть скрипти k6, що імітують поведінку користувачів.
  3. Запустіть smoke-тест для перевірки коректності.
  4. Виконайте load та stress тести в оточенні, наближеному до продакшену.
  5. Проаналізуйте результати, виявіть вузькі місця та оптимізуйте.

Терміни та вартість

Базовий набір навантажувальних сценаріїв (smoke, load, stress, soak): 3–5 днів. Вартість розраховується індивідуально після аудиту вашого проєкту. У комплексний проєкт входить:

  • 5 типових сценаріїв
  • Інтеграція з Grafana/InfluxDB
  • Документація та навчання
  • Підтримка 30 днів

Як замовити розробку навантажувальних тестів?

Зв'яжіться з нами для консультації. Ми проаналізуємо ваш проєкт, визначимо SLA та розробимо сценарії під ключ. Замовте розробку — ваші тести будуть готові протягом тижня. Гарантуємо надійність та повну документацію. Ваша система буде готова до будь-яких пікових навантажень.

Чому юніт-тести важливі, але не панацея?

Баг, знайдений юніт-тестом, коштує хвилини виправлення. Той самий баг у продакшені — години інциденту, компенсації та втрата довіри. На проекті інтернет-магазину помилка в розрахунку знижки пройшла ручне тестування, потрапила в прод і за 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 через витік з'єднань. Після оптимізації клієнт заощадив значну суму на інцидентах та зайвих ресурсах. Отримайте аналогічний аудит вашого проекту — замовте навантажувальне тестування.

Як 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 хв
Продуктивність 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% часу на інциденти. Отримайте консультацію з тестування веб-додатків — напишіть нам.