Повна програма курсу: Performance Testing з k6

Загальна інформація

Рівень: Middle–Senior
Аудиторія: DevOps-інженери, розробники, QA-інженери
Формат: теорія + практика на занятті + домашнє завдання на кожну тему
Загальна кількість занять: 15

Зміст

Для кого цей курс

Сегмент 1 — QA-інженери (middle/senior)

Профіль: мають досвід функціонального та/або API-тестування, можуть писати скрипти на JS/TS, але перформенс тестування роблять вручну, поверхово або взагалі не роблять.

Чого навчаться:

Формулювати НФР і переводити бізнес-вимоги в конкретні цілі навантаження
Писати та підтримувати k6-тести (протокольні та браузерні)
Читати метрики й самостійно писати запити InfluxQL/PromQL та дашборди Grafana
Зустрічати регресії перформенсу до релізу, а не після

Після курсу зможуть:

Самостійно спроєктувати та запустити перформенс-тест на проєкті
Побудувати дашборд для порівняння результатів між релізами
Презентувати результати перформенс-тестування технічній команді та бізнесу

«Я вмію тестувати функціонал, але коли мене питають “а як воно поводиться під навантаженням” — я губляюсь і не знаю, з чого почати».

Сегмент 2 — DevOps-інженери (middle/senior)

Профіль: налаштовують CI/CD, моніторинг (Prometheus/Grafana), Kubernetes-кластери, але перформенс тестування існує окремо від пайплайнів або взагалі відсутнє.

Чого навчаться:

Будувати observability-стек для перформенс тестування (k6 → storage → Grafana)
Інтегрувати k6 у CI/CD як gate перед релізом
Запускати розподілені навантажувальні тести в Kubernetes через k6-operator
Підключати AI-агентів до Grafana для автоматичного аналізу результатів
Проводити chaos-експерименти разом з навантажувальними тестами

Після курсу зможуть:

Зробити перформенс тестування частиною пайплайну, а не окремим ручним кроком
Налаштувати моніторинг та дашборди run-to-run порівняння на базі Influx та Prometheus
Масштабувати навантажувальні тести в кластері без ручного втручання
Перевіряти стійкість системи до збоїв під навантаженням

«У нас є CI/CD і моніторинг, але перформенс тести хтось запускає вручну раз на квартал — хочу, щоб це працювало автоматично і давало зрозумілий результат».

Блок 1. Основи процесу перформенс тестування

(Заняття 1 — середній рівень, без спеціальних передумов окрім загального досвіду в тестуванні/devops)

Заняття 1. НФР та побудова процесу перформенс тестування на проєкті

Розглянемо, що таке нефункціональні вимоги (НФР): response time, throughput, error rate, scalability, availability, та як їх правильно формулювати разом із бізнесом і розробниками. Поговоримо, як вписати перформенс тестування у процес розробки — коли і як часто запускати тести, хто відповідає за результати, як визначити baseline та критерії “пройшов/не пройшов”. Окремо торкнемося ролі моніторингу як частини процесу: що моніторити постійно, а що перевіряти точково через навантажувальні тести.

Практика на занятті: на прикладі тестового проєкту визначаємо НФР для двох-трьох ключових сценаріїв (наприклад, логін, пошук, оформлення замовлення) та накидаємо схему процесу — хто, коли, як часто запускає тести і куди йдуть результати.

ДЗ: для свого (або наданого) проєкту сформулювати НФР для 3–5 ключових сценаріїв та описати процес перформенс тестування на проєкті (етапи, відповідальні, частота, критерії прийняття). Здати: документ з таблицею НФР (сценарій / метрика / цільове значення / критичне значення) + текстовий опис або схема процесу.

Результат після заняття: Студент розуміє, як формулювати НФР та інтегрувати процес перформенс тестування в життєвий цикл проєкту.

Блок 2. k6 — написання тестів, дашборди та AI-генерація

(Заняття 2–4 — середній рівень, потрібні базові JS/TS та основи HTTP/API)

Заняття 2. Writing Tests, Key Metrics

Розглянемо, як писати якісні навантажувальні тести в k6: структура тесту (default function, setup/teardown), virtual users, stages та executors (constant-vus, ramping-vus, constant-arrival-rate тощо), checks і thresholds. Розберемо ключові метрики, які варто відстежувати завжди: http_req_duration (та його під-метрики), http_req_failed, vus/vus_max, iterations, data_sent/data_received, та що означає кожна з них у summary-звіті k6.

Практика на занятті: пишемо k6-тест для наданого API (кілька ендпоінтів, checks, thresholds на response time та error rate), запускаємо тест через CLI та аналізуємо summary-звіт.

ДЗ: написати k6-тест для заданого сценарію (мінімум 3 ендпоінти, checks, thresholds на response time та error rate). Здати: файл k6-скрипта, скріншот/вивід summary з результатами запуску, короткий звіт — чому обрані саме такі thresholds і що показали отримані метрики.

Результат після заняття: Студент вміє писати k6-тести зі checks та thresholds і самостійно інтерпретувати ключові метрики з CLI summary.

Заняття 3. Default Dashboard (k6 dashboard extension та Grafana)

Розглянемо два варіанти стандартної візуалізації результатів k6 без написання власних дашбордів: вбудоване розширення k6 dashboard (веб-дашборд у реальному часі під час запуску, –out web-dashboard/HTML-звіт) та стандартний Grafana dashboard для k6 (на базі InfluxDB або Prometheus). Розберемо по панелях, що показує кожен з них: request rate, response time percentiles, error rate, VUs over time тощо, та коли який варіант доцільніше використовувати.

Практика на занятті: запускаємо тест із заняття 2 з увімкненим k6 dashboard extension, а потім — з виводом у Grafana через стандартний dashboard, порівнюємо обидва представлення.

ДЗ: запустити тест із заняття 2 двома способами — з k6 dashboard extension та зі стандартним Grafana dashboard, зробити скріншоти. Здати: скріншоти обох дашбордів, письмова інтерпретація — що показує кожна панель та які значення отримані для цього тесту, у чому переваги/обмеження кожного варіанта.

Результат після заняття: Студент вміє переглядати та інтерпретувати результати тестів через вбудований k6 dashboard extension та стандартний Grafana dashboard.

Заняття 4. AI-Powered Test Generation

Розглянемо, як використовувати AI-інструменти для автогенерації k6-скриптів на основі специфікації API (OpenAPI/Swagger) або запису трафіку (HAR-файл). Поговоримо про стратегії промптингу для отримання якіснішого результату, типові помилки, які робить AI (неправильні checks, відсутні thresholds, хардкод даних), та як критично переглядати й доопрацьовувати згенерований код перед використанням у реальному проєкті.

Практика на занятті: беремо специфікацію API або HAR-файл, генеруємо k6-скрипт за допомогою AI-інструменту, переглядаємо та виправляємо знайдені проблеми.

ДЗ: згенерувати за допомогою AI k6-тест для заданого сценарію (на основі специфікації API або HAR-файлу), доопрацювати та довести скрипт до робочого стану. Здати: оригінальний AI-згенерований скрипт, фінальний доопрацьований скрипт, короткий звіт (які помилки/недоліки були в згенерованому коді, що довелось виправити вручну).

Результат після заняття: Студент вміє використовувати AI-інструменти для генерації k6-скриптів та критично оцінювати й доопрацьовувати отриманий результат.

Блок 3. Observability та метрики: InfluxDB, Prometheus, Grafana

(Заняття 5–9 — середній/сеньйор рівень, потрібні базові знання запитових мов (SQL-подібних) будуть плюсом)

Заняття 5. Концепція Observability: ключові метрики та компоненти

Розглянемо архітектуру observability-стеку для перформенс тестування як ланцюжок: producer (k6, що генерує метрики) → collector/receiver → metric storage → visualization. Поговоримо про push vs pull моделі збору метрик, роль кожного компонента в системі, та зробимо огляд варіантів, які розглянемо в наступних заняттях — InfluxDB та Prometheus як storage, Grafana як visualization layer.

Практика на занятті: малюємо схему observability-архітектури для перформенс-тестового стенду та позначаємо, де в ній знаходиться k6, storage та Grafana, обговорюємо альтернативні конфігурації.

ДЗ: для свого проєкту описати, яку observability-архітектуру для перформенс тестів планується використовувати (який storage, як k6 надсилає дані, де візуалізація) та обґрунтувати вибір. Здати: схема/діаграма архітектури (producer → collector → storage → visualization) + текстове обґрунтування вибору компонентів.

Результат після заняття: Студент розуміє компоненти observability-стеку для перформенс тестування (visualization, metric storage, collectors) та роль кожного з них.

Заняття 6. InfluxDB як metric storage та InfluxQL

Розглянемо модель даних InfluxDB: measurements, tags, fields, timestamps, та як k6 записує результати тестів у InfluxDB (вбудований output k6). Розберемо основи InfluxQL: SELECT-запити, GROUP BY time(), агрегаційні функції (mean, percentile, count), фільтрацію за tags.

Практика на занятті: надсилаємо результати k6-тесту в InfluxDB та пишемо InfluxQL-запити для вибірки середнього та p95 response time, згрупованих за часом та ендпоінтом.

ДЗ: запустити k6-тест з виводом у InfluxDB та написати 3–5 InfluxQL-запитів, що відповідають на конкретні питання (наприклад: p95 response time по кожному ендпоінту за часом, тренд error rate протягом тесту). Здати: список запитів з результатами (скріншоти/вивід), короткий опис, що показує кожен запит.

Результат після заняття: Студент розуміє модель даних InfluxDB та вміє писати базові InfluxQL-запити для аналізу результатів k6.

Заняття 7. Prometheus як metric storage та PromQL

Розглянемо модель даних Prometheus: metrics, labels, time series, відмінність pull-моделі Prometheus від push-моделі InfluxDB та як k6 надсилає дані в Prometheus (remote write). Розберемо основи PromQL: rate(), агрегаційні функції, та особливо histogram_quantile() для обчислення перцентилів з histogram-метрик.

Практика на занятті: налаштовуємо k6 на відправку метрик у Prometheus через remote write та пишемо PromQL-запити для error rate (через rate()) та p95 response time (через histogram_quantile()).

ДЗ: налаштувати k6 на надсилання метрик у Prometheus та написати 3–5 PromQL-запитів, серед яких обов’язково мінімум один з histogram_quantile(). Здати: запити з результатами/скріншотами, короткий опис, що показує кожен запит та чим він відрізняється від аналогічного InfluxQL-запиту з минулого заняття.

Результат після заняття: Студент розуміє модель даних Prometheus та вміє писати базові PromQL-запити для аналізу результатів k6.

Заняття 8. Grafana як основний opensource visualization tool та інтеграція з Influx і Prometheus

Розглянемо архітектуру Grafana: data sources, dashboards, panels, variables. Навчимось підключати одночасно InfluxDB та Prometheus як джерела даних в одній Grafana-інсталяції та будувати панелі на основі запитів, написаних у заняттях 6 та 7.

Практика на занятті: підключаємо InfluxDB та Prometheus як data sources в Grafana, будуємо дашборд з панелями на базі обох джерел та додаємо змінну (variable) для фільтрації за ендпоінтом/тестовим запуском.

ДЗ: побудувати Grafana dashboard з мінімум 4 панелями — 2 на основі InfluxQL-запитів та 2 на основі PromQL-запитів з попередніх занять, додати variables для фільтрації. Здати: експорт дашборду (JSON) або скріншоти, опис кожної панелі та запиту, що в ній використано.

Результат після заняття: Студент вміє підключати Grafana до InfluxDB та Prometheus одночасно та будувати дашборди на основі обох джерел даних.

Заняття 9. k6: відправка метрик з tags, groups та fields для Influx і Prometheus + load-профілі

Розглянемо, як використовувати tags та groups у k6 для деталізації результатів — як вони мапляться на tags/fields у InfluxDB та на labels у Prometheus. Розберемо custom-метрики k6 (Trend, Counter, Gauge, Rate) та як їх можна аналізувати в обох storage. Окремо створимо власний load-профіль (ramp-up → steady state → spike → ramp-down) за допомогою executors, що імітує реальну поведінку користувачів, і протегуємо сценарії для подальшої фільтрації в дашбордах.

Практика на занятті: додаємо tags/groups та custom-метрику до існуючого тесту, будуємо багатоетапний load-профіль, надсилаємо результати одночасно в InfluxDB та Prometheus, оновлюємо Grafana-панелі з фільтрацією за тегами.

ДЗ: доопрацювати тест з попередніх занять — додати tags/groups, мінімум одну custom-метрику та власний load-профіль (мінімум 3 етапи навантаження), надіслати результати в InfluxDB і Prometheus, оновити Grafana-дашборд з панелями, що фільтруються/групуються за тегами. Здати: k6-скрипт з tags/groups/custom-метриками та конфігурацією load-профілю, оновлений dashboard (експорт/скріншоти), короткий звіт з інтерпретацією результатів.

Результат після заняття: Студент вміє використовувати tags, groups та custom-метрики у k6 для деталізованого аналізу та будувати реалістичні load-профілі з відправкою даних у InfluxDB і Prometheus одночасно.

Блок 4. Просунуте перформенс тестування та DevOps-інтеграція

(Заняття 10–15 — сеньйор рівень, потрібні базові навички CI/CD, Docker та Kubernetes)

Заняття 10. UI Performance Testing за допомогою k6 browser-тестів

Розглянемо модуль k6 browser та чим він відрізняється від протокольних тестів — коли потрібно тестувати саме UI-перформенс, а не тільки backend. Розберемо ключові метрики Web Vitals (LCP, FCP, CLS, TTI) та як їх вимірювати через k6 browser. Поговоримо про комбіновані сценарії, де частина VU генерує фонове навантаження на API, а інша — відкриває сторінки в браузері та вимірює UI-метрики.

Практика на занятті: пишемо k6 browser-тест для заданої сторінки, який відкриває сторінку, виконує дії користувача (клік, скрол, заповнення форми) та збирає метрики Web Vitals.

ДЗ: написати k6 browser-тест для 1–2 ключових сторінок проєкту, що вимірює Web Vitals під фоновим навантаженням на API (комбінований сценарій). Здати: k6-скрипт (browser + протокольна частина), звіт зі значеннями Web Vitals до/під навантаженням, висновки щодо UI-перформенсу.

Результат після заняття: Студент вміє писати браузерні k6-тести та оцінювати UI-перформенс за метриками Web Vitals.

Заняття 11. Побудова дашборду для порівняння результатів між запусками

Навчимось будувати в Grafana дашборди, які дозволяють порівнювати результати кількох запусків тестів (baseline vs поточний, реліз vs реліз). Розберемо роботу з тегами/annotations у k6, змінними (variables) у Grafana та способи візуалізації трендів у часі — щоб легко помічати регресії, покращення та довгострокові тенденції.

Практика на занятті: налаштовуємо теги для запусків k6, будуємо в Grafana дашборд з variable для вибору запуску та порівнюємо два запуски за основними метриками.

ДЗ: запустити один і той же тест мінімум 2–3 рази (з різними версіями коду/конфігурації) та побудувати порівняльний дашборд у Grafana, що показує зміну метрик між запусками. Здати: експорт/скріншоти порівняльного дашборду, короткий звіт — чи є регресія, за якими метриками, можливі причини.

Результат після заняття: Студент вміє будувати порівняльні дашборди для відстеження змін перформенсу між запусками та виявляти регресії.

Заняття 12. CI/CD інтеграція

Покроково розберемо, як інтегрувати k6-тести в CI/CD пайплайн (GitHub Actions, GitLab CI або інший інструмент за домовленістю). Поговоримо про стратегії запуску: smoke-перформенс тести на кожен PR, повноцінні тести на staging перед релізом, thresholds як критерій pass/fail для пайплайну, а також про публікацію результатів (артефакти, звіти, нотифікації в Slack/Teams).

Практика на занятті: налаштовуємо пайплайн, який запускає k6-тест з thresholds і завалює білд, якщо перформенс не відповідає вимогам.

ДЗ: інтегрувати раніше написаний k6-тест у CI/CD пайплайн з thresholds, налаштувати збереження результатів як артефактів та (опційно) нотифікацію про результат. Здати: конфігураційний файл пайплайну, скріншоти/логи успішного та проваленого запусків (наприклад, штучно занижений threshold).

Результат після заняття: Студент вміє інтегрувати k6-тести в CI/CD пайплайн як автоматичний gate перед релізом.

Заняття 13. Запуск k6-тестів у Kubernetes з k6-operator

Розглянемо, як деплоїти та запускати k6-тести всередині Kubernetes-кластера за допомогою k6-operator. Поговоримо про best practices: розподіл навантаження між кількома подами (distributed execution), управління ресурсами (requests/limits), вибір кількості та розміру воркерів залежно від цільового навантаження, а також про збір метрик з розподілених тестів у централізований Grafana dashboard.

Практика на занятті: встановлюємо k6-operator у тестовий кластер (kind/minikube), створюємо TestRun-маніфест та запускаємо розподілений тест на декілька подів.

ДЗ: розгорнути k6-operator у власному/тестовому кластері, налаштувати TestRun для запуску раніше написаного тесту в розподіленому режимі (мінімум 2 воркери) з відправкою метрик у Prometheus/InfluxDB. Здати: файли маніфестів (operator config, TestRun), скріншоти логів/подів під час запуску, скріншот dashboard з агрегованими метриками.

Результат після заняття: Студент вміє запускати та масштабувати розподілені k6-тести в Kubernetes за допомогою k6-operator.

Заняття 14. AI-агент з Grafana MSP та API для аналізу результатів k6-тестів

Розглянемо, як підключити AI-агента до можливостей машинного навчання/статистичного аналізу (MSP) у Grafana для автоматичного аналізу результатів k6-тестів. Поговоримо про автоматичне виявлення аномалій (anomaly detection), порівняння з історичними даними та генерацію зрозумілих текстових висновків для команди — без необхідності вручну переглядати кожен дашборд після кожного запуску.

Практика на занятті: підключаємо AI-агента до Grafana-дашборду з результатами одного з попередніх запусків та отримуємо автоматичний звіт з виявленими аномаліями.

ДЗ: налаштувати AI-агента для аналізу результатів одного з раніше виконаних тестових запусків (за вибором — порівняльний дашборд із заняття 11 або dashboard з Kubernetes-запуску із заняття 13), зафіксувати, які аномалії/висновки агент виявив. Здати: опис налаштування інтеграції, згенерований AI-звіт, коментар студента — чи погоджується він з висновками агента і чому.

Результат після заняття: Студент вміє використовувати AI-агента для автоматизованого аналізу результатів k6-тестів та виявлення аномалій.

Заняття 15. Chaos Testing разом з xk6-disruptor

Розглянемо основи chaos engineering у контексті перформенс тестування: чому важливо перевіряти не лише поведінку системи під навантаженням, а й її стійкість до збоїв під навантаженням одночасно. Розберемо розширення xk6-disruptor та як воно інтегрується з k6-тестами: внесення мережевих затримок та помилок (HTTP/gRPC faults), збої на рівні Pod у Kubernetes (pod disruptor), обмеження ресурсів. Поговоримо, як комбінувати load-тест з контрольованим chaos-експериментом та інтерпретувати вплив на метрики (response time, error rate) під час та після збою.

Практика на занятті: запускаємо k6-тест з фоновим навантаженням та одночасно вносимо HTTP-фолт (наприклад, затримку або помилку) за допомогою xk6-disruptor, спостерігаємо за зміною метрик у Grafana в реальному часі.

ДЗ: спроєктувати та провести chaos-експеримент — комбінацію load-тесту з xk6-disruptor (наприклад, pod disruptor для сервісу в Kubernetes або HTTP fault для конкретного ендпоінта), зафіксувати поведінку системи до, під час та після збою. Здати: k6-скрипт/конфігурація з xk6-disruptor, скріншоти dashboard “до/під час/після” збою, звіт з висновками про стійкість системи та рекомендаціями.

Результат після заняття: Студент вміє проводити chaos-експерименти за допомогою xk6-disruptor разом з k6 та оцінювати стійкість системи під комбінованим навантаженням і збоями.

Фінальний проєкт

Мета: показати, що студент здатен побудувати повноцінний процес перформенс тестування на проєкті — від формулювання НФР до автоматизованого аналізу результатів у CI/CD та перевірки стійкості системи — а не лише написати окремий тест.

Студент обирає (або отримує) тестовий застосунок та проходить повний цикл:

НФР та процес — документ з НФР для 3–5 сценаріїв та опис процесу перформенс тестування на проєкті
Протокольні k6-тести — мінімум 3 сценарії з checks і thresholds, частина створена з допомогою AI-генерації
Browser-тест(и) — k6 browser-тест для ключової сторінки з вимірюванням Web Vitals
Observability-стек — k6-тести з custom load-профілем, tags/groups, метрики надіслані в InfluxDB та Prometheus
Дашборди — k6 dashboard extension/стандартний Grafana dashboard + кастомний дашборд (на базі Influx та Prometheus) + порівняльний dashboard (мінімум 2 запуски)
CI/CD пайплайн — конфігурація, яка запускає тести з thresholds як gate
Kubernetes-запуск — TestRun з k6-operator, розподілене виконання
AI-аналіз — звіт від AI-агента з висновками по одному з запусків
Chaos-експеримент — load-тест у поєднанні з xk6-disruptor, звіт про стійкість системи до збоїв під навантаженням

Приклад матриці охоплення тестами

Сценарій	Тип тесту	Метрики	Thresholds	CI/CD
Логін	Протокольний	p95 latency, error rate	p95 < 500ms, errors < 1%	✅
Пошук товару	Протокольний + Browser	p95 latency, LCP, CLS	p95 < 800ms, LCP < 2.5s	✅
Оформлення замовлення	Протокольний (soak)	error rate, throughput	errors < 0.5%	✅

Формат захисту: 30 хвилин — 15 хв презентація (демонстрація дашбордів, пайплайну, AI-звіту, chaos-експерименту), 15 хв питання від групи та викладача, фокус на обґрунтуванні вибору НФР, архітектури observability-стеку, інтерпретації результатів та висновків про стійкість системи.