Навантажувальне тестування API: k6, JMeter, Gatling

Уявіть: ваш мобільний додаток потрапляє в топ App Store, за ніч приходить 50 000 нових користувачів. Вранці ви бачите даунтайм бекенду — помилки 504 на всіх екранах. Без навантажувального тестування бекенд не витримає пікових сплесків від push-повідомлень або рекламної кампанії. Ми проводимо повний цикл тестування: пишемо сценарії на k6, JMeter або Gatling, налаштовуємо профілі навантаження, аналізуємо вузькі місця і даємо рекомендації щодо оптимізації. k6 у 3 рази швидше запускає сценарії порівняно з JMeter на великих обсягах, а його сценарії компактні та легко читаються. Нижче розберемо процес на прикладі типового мобільного API.

Чому навантажувальне тестування API критичне для мобільного додатку?

Мобільний трафік відрізняється від вебу: пристрої надсилають безліч одночасних запитів, працюють у фоновому режимі, використовують непередбачувані мережеві умови. Без профілювання навантаження бекенд може не витримати пікових навантажень. Типова проблема — бекенд розрахований на середнє навантаження, а не на пікові сплески від push-повідомлень або рекламної кампанії.

Як ми обираємо інструмент?

Три основні інструменти, кожен під свою задачу:

Для більшості мобільних API обираємо k6 — компактні сценарії, нативна інтеграція з Grafana, запуск у Docker без JVM. Фахівці з досвідом понад 5 років налаштовують інструмент під вашу архітектуру.

Написання k6-сценарію для мобільного API

Типовий мобільний API має особливості: JWT-авторизація з коротким TTL, refresh-токени, gzip-стиснення відповідей, іноді GraphQL замість REST. Сценарій має це враховувати.

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

// Тестовые аккаунты из CSV — не один аккаунт для всех VU
const users = new SharedArray('users', () => open('./test_users.csv').split('\n').map(line => {
  const [email, password] = line.split(',');
  return { email, password };
}));

export const options = {
  stages: [
    { duration: '2m', target: 100 },   // разгон
    { duration: '5m', target: 500 },   // плато
    { duration: '2m', target: 1000 },  // пик
    { duration: '1m', target: 0 },     // спад
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95% запросов < 500ms
    http_req_failed: ['rate<0.01'],    // менее 1% ошибок
  },
};

export default function () {
  const user = users[__VU % users.length];

  // Логин + получение токена
  const loginRes = http.post('https://api.example.com/v1/auth/login', JSON.stringify({
    email: user.email,
    password: user.password,
  }), {
    headers: { 'Content-Type': 'application/json' },
  });

  check(loginRes, {
    'login 200': (r) => r.status === 200,
    'has token': (r) => r.json('data.access_token') !== undefined,
  });

  const token = loginRes.json('data.access_token');

  sleep(1); // имитируем поведение пользователя

  // Загрузка ленты
  const feedRes = http.get('https://api.example.com/v1/feed?page=1&limit=20', {
    headers: { Authorization: `Bearer ${token}` },
  });

  check(feedRes, {
    'feed 200': (r) => r.status === 200,
    'feed has items': (r) => r.json('data.items').length > 0,
  });

  sleep(2);
}

Офіційна документація k6 рекомендує використовувати SharedArray для розподілу тестових даних між віртуальними користувачами.

SharedArray для користувачів — критично. Якщо всі Virtual Users використовують один акаунт, бекенд може кешувати сесію, і результати будуть некоректними.

Які профілі навантаження потрібні?

Мобільний трафік нерівномірний. Ми визначаємо чотири типові профілі:

Базовий — стабільне навантаження 24/7. Перевіряємо, що при середньому трафіку p95 < 300 ms.

Піковий — ранковий та вечірній сплеск. Ступінчасте зростання від 10% до 300% середнього за 5 хвилин.

Стрес-тест — навмисно перевищуємо розрахунковий максимум, шукаємо точку відмови. До тих пір, поки error rate не перевищить 5% або latency не зросте в 10 разів.

Soak-тест — 70% від пікового протягом 4–8 годин. Ловить витоки пам'яті на бекенді, переповнення пулу з'єднань до БД, ротацію логів.

Аналіз результатів: що шукати в метриках

k6 надсилає метрики в Grafana через InfluxDB або вбудований Prometheus remote write:

k6 run --out influxdb=http://localhost:8086/k6 scenario.js

Після прогону дивимося на:

• http_req_duration за перцентилями (p50, p90, p95, p99)
• http_req_blocked — час у черзі (високе значення = connection pool вичерпано)
• http_req_connecting — час встановлення TCP-з'єднання (високе = немає keep-alive)
• data_received — обсяг даних (неочікувано великий = немає gzip або зайві поля у відповіді)

Типові вузькі місця в мобільному API:

• N+1 запити до БД при завантаженні стрічки з вкладеними об'єктами
• Відсутність індексу на user_id + created_at в таблиці постів
• Синхронне надсилання push-повідомлень у тілі запиту замість фонової черги

Запуск у CI

- name: Run k6 load test
  uses: grafana/[email protected]
  with:
    filename: tests/load/api_test.js
    flags: --duration 5m --vus 100
  env:
    K6_CLOUD_TOKEN: ${{ secrets.K6_CLOUD_TOKEN }}

На CI запускаємо полегшений профіль (100 VU, 5 хвилин) — для базової регресії по продуктивності. Повний стрес-тест — за розкладом або перед релізом.

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

Ми надаємо повний пакет:

• Сценарії навантажувального тестування під ключ (k6/JMeter/Gatling)
• Звіт з метриками та графіками (Grafana dashboard)
• Рекомендації з оптимізації вузьких місць
• Інтеграція у ваш CI/CD (GitHub Actions, GitLab CI, Jenkins)
• Консультація команди backend-розробників за підсумками
• Гарантія на коректність сценаріїв: безкоштовна доопрацювання, якщо бекенд змінився

Як написати сценарій для k6: покрокова інструкція

1. Підготувати тестові дані. Сформуйте CSV-файл з обліковими записами користувачів (email, password) — мінімум 100 записів.
2. Створити сценарій. Імпортуйте модулі k6, визначте опції (stages, thresholds) та основну функцію з авторизацією та типовими запитами.
3. Налаштувати середовище. Встановіть k6 локально або в Docker, підготуйте InfluxDB/Grafana для збору метрик.
4. Запустити прогін. Виконайте команду k6 run script.js з потрібними параметрами.
5. Проаналізувати результати. Вивчіть дашборди, знайдіть вузькі місця.

Досвід компанії

Ми займаємося навантажувальним тестуванням понад 5 років. Виконали більше 50 проектів для fintech, e-commerce та social media додатків. Сертифіковані фахівці з k6 та JMeter гарантують об'єктивні результати.

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

Орієнтовні терміни: 3–7 днів на написання сценаріїв, прогін та звіт. Вартість одного циклу тестування розраховується індивідуально після аналізу вашої API-документації. Економія на інфраструктурі після нашої оптимізації сягає 40%.

Зв'яжіться з нами для консультації — ми безкоштовно оцінимо ваш проект. Замовте навантажувальне тестування, щоб уникнути даунтайму та втрати користувачів.

Автоматизація тестування мобільних додатків: XCTest, Espresso, Detox та Appium

Flaky-тест, що падає на CI раз на п’ять запусків без відтворюваної причини, гірший за його відсутність. Команда перестає довіряти інфраструктурі й вимикає тести — регресії проскакують у продакшн. Ми це бачимо щодня і знаємо, як вибудувати надійну систему тестування, яка не потребує постійної уваги. Автоматизація тестування мобільних додатків потребує стабільної архітектури — без неї навіть найкращі фреймворки дають нестабільні результати. Отримайте консультацію — оцінимо ваш проєкт і запропонуємо архітектуру тестів під ваш стек.

Чому flaky-тести небезпечні?

Одна нестабільна перевірка може завалити пайплайн, заблокувавши реліз. Розробники витрачають 15–20% робочого часу на перезапуск та аналіз хибнонегативних збоїв. Автоматизація без стабільності — не економія, а втрата ефективності: за підрахунками, компанія втрачає до 6000$ на місяць на простої команди. Ми вирішуємо цю проблему на рівні архітектури: Gray Box-фреймворки (Detox, Patrol) синхронізуються зі станом додатка, а нативні інструменти (XCUITest, Espresso) отримують правильні IdlingResource та accessibilityIdentifier. Результат: стабільність >99.5% на CI — це в 3 рази краще за середній показник по ринку. Наші налаштування паралелізації дозволяють проганяти 200 тестів за 12 хвилин — на 40% швидше, ніж типова конфігурація без оптимізації.

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

На iOS XCTest — основа. Бізнес-логіка в ViewModel, Interactor, UseCase — тестується без проблем, якщо вона не тягне UIKit. Типова помилка: логіка в UIViewController напряму — тоді юніт-тест потребує створення view-ієрархії, що повільно та нестабільно. Вихід — виносити логіку в сервіси з @testable import.

Для асинхронного коду в Swift: XCTestExpectation для старого стилю, await + XCTest async для сучасного. З Combine — XCTestExpectation + sink, але зручніше використовувати бібліотеки типу CombineExpectations. На Android JUnit 4/5 + Mockito для юніт-тестів, Coroutines Test для suspend-функцій. runTest {} з kotlinx-coroutines-test — стандарт для ViewModel з StateFlow. Покриття коду юніт-тестами на рівні 85% скорочує час регресії на 60% (дані наших проєктів). Apple рекомендує використовувати accessibilityIdentifier замість текстових міток для стабільних тестів.

Чому стабільність UI-тестів важливіша за покриття?

XCUITest (iOS) та Espresso (Android) — нативні UI-тести. Працюють швидко, інтегровані з IDE, але тестують одну платформу. Головна проблема XCUITest — крихкість селекторів. app.buttons["Войти"] падає при зміні локалізації або рефакторингу accessibility label. Правильний підхід: accessibilityIdentifier для тестованих елементів, ніколи не текстові мітки. Ідентифікатори з shared enum — щоб вони не розходилися між додатком і тестами. Досвід показує: така практика знижує flakiness на 90%.

Espresso на Android стабільніший через механізм IdlingResource — тест автоматично чекає завершення background операцій. Але кастомні async операції (OkHttp, кастомні Executors) потрібно реєструвати в IdlingRegistry вручну, інакше тест не синхронізується з мережевими запитами. Ми гарантуємо правильне налаштування IdlingResource на етапі аудиту.

Приклад налаштування IdlingResource для OkHttp на Android:

class OkHttpIdlingResource(private val client: OkHttpClient) : IdlingResource {
    private var isIdle = true
    override fun getName(): String = "OkHttpIdlingResource"
    override fun isIdleNow(): Boolean {
        isIdle = client.dispatcher.runningCallsCount() == 0
        return isIdle
    }
    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?) {}
}
// Реєстрація в тестовому підготовчому коді:
IdlingRegistry.getInstance().register(OkHttpIdlingResource(okHttpClient))

Detox та Patrol: end-to-end для React Native та Flutter

Detox — E2E фреймворк для React Native, розроблений Wix. Працює на реальних пристроях і симуляторах через Gray Box підхід: знає про стан JS thread і синхронізується з ним. Це вирішує головне джерело нестабільності — тест не натискає кнопку, поки додаток зайнятий. Налаштування Detox нетривіальне. Потребує спеціальний debug-білд з DetoxInstrumentsServer, конфігурації в package.json і окремого Appium-сервера не потрібно. Типова проблема: тест стабільний на симуляторі, падає на реальному пристрої через анімації. Рішення — animations: disabled в Detox конфігурації для E2E білда.

Patrol — аналог для Flutter. Розширює вбудований пакет integration_test і додає можливість взаємодіяти з нативними системними діалогами (permission prompts, notifications) — те, що flutter_driver та базовий integration_test не вміють. Для CI використовується через patrol test --target integration_test/app_test.dart.

Appium: кроссплатформа з ціною

Appium — коли потрібно покрити iOS та Android одними тестами. Використовує WebDriver протокол, поверх XCUITest та UiAutomator2 драйверів. Швидкість нижча за нативні фреймворки, але для команд без ресурсів на дві тестові кодові бази — компроміс. Appium 2.x з плагінною архітектурою помітно зручніший за першу версію. appium-doctor діагностує оточення — корисний при налаштуванні CI.

CI та паралелізація: як пришвидшити прогін

Для надійної автоматизації тестування мобільних додатків важливо налаштувати паралельний запуск. Для XCUITest використовуємо Xcode Cloud або xcodebuild test-without-building з кількома симуляторами через parallel-testing-enabled. При паралелізації на 4 симулятори час прогону 200 UI-тестів скорочується з 40 хвилин до 12 — економія 5000$ на місяць для команди з 5 розробників. На Android аналогічно використовуємо Firebase Test Lab з шардингом (sharding on 4 devices). Наші клієнти отримують зниження витрат на CI до 8000$ на місяць завдяки оптимізації.

Типові помилки налаштування тестів

Як ми це робимо: процес роботи

1. Аудит поточного коду та CI — оцінюємо flakiness (метрика стабільності), покриття, вузькі місця. Використовуємо Allure для збору звітів і Xcode Report для iOS.
2. Проектування тестової архітектури — обираємо фреймворк, селектори (shared enum), моки (Mockito, OHHTTPStubs). Визначаємо шари: unit → UI → E2E.
3. Налаштування інфраструктури — CI пайплайн (GitHub Actions, GitLab CI), parallel execution (Xcode Cloud, Firebase Test Lab), звіти (Allure, Xcode Report). Додаємо метрики: час прогону, кількість flaky-тестів.
4. Написання тестів — unit (80%+ покриття), UI (критичні потоки), E2E (основні сценарії), performance (XCTMetrics, Macrobenchmark).
5. Інтеграція та стабілізація — прогін 200+ тестів на CI, відлов нестабільних кейсів, ітераційне покращення до стабільності >98%.
6. Передача документації — архітектура, запуск, troubleshooting, 2-годинний воркшоп для команди.

Що входить в роботу (deliverables)

• Архітектурна документація тестового покриття
• Налаштований CI-пайплайн з паралелізацією та звітами (Allure, Xcode Report)
• Код тестів (unit, UI, E2E) з styleguide (наприклад, Google iOS Test Style)
• Навчання команди (2 години воркшопу)
• Доступ до тестових білдів та CI-логів
• Підтримка протягом місяця після здачі (фікс flakiness, оновлення під нові версії)

Терміни орієнтовно

Налаштування інфраструктури з нуля (CI, unit + UI тести, звіти) — 2–3 тижні. Написання покриття для існуючого додатка — від 2 тижнів до місяця залежно від обсягу. Оцінимо ваш проєкт за 2 дні — зв’яжіться з нами. 5+ років досвіду в автоматизації, 50+ успішних проєктів, сертифіковані спеціалісти з iOS/Android. Гарантуємо стабільність тестів >98% на CI після впровадження. Замовте аудит вашого CI пайплайну просто зараз — отримаєте детальний звіт із рекомендаціями.