Стрес-тест у мобільній розробці: що це, цілі та як проводиться

Що таке Stress Test?

Stress Test (стрес-тестування) — це процес оцінки здатності системи працювати в умовах, що перевищують розрахункові показники. Для мобільного застосунку це може означати 10000 одночасних push-сповіщень при нормі 1000, для бекенду — 50000 RPS при очікуваних 5000. Головна відмінність Stress Test від Load Test — метою є не підтвердження продуктивності, а вивчення поведінки системи за межами її проєктної потужності. Netflix Engineering (2024) визначає Stress Test як «перевірку гіпотези про те, що система зламається передбачувано».

Стрес-тестування включає два обов’язкових етапи: навантаження до відмови та спостереження за відновленням. Відновлення (recovery) — здатність системи повернутися до нормальної роботи після зняття перевантаження. Система, яка не відновлюється без перезапуску, вважається крихкою, навіть якщо вона витримує короткочасне перевантаження. За даними AWS Well-Architected Framework (2024), час відновлення після Stress Test не повинен перевищувати 5 хвилин.

Для мобільних клієнтів Stress Test включає перевірку роботи при примусовому завершенні процесів, відключенні мережі та вичерпанні оперативної пам’яті. Android Low Memory Killer може завершити фоновий процес при нестачі RAM — стрес-тест повинен перевірити, що застосунок коректно відновлює стан після такого завершення. Apple UIKit (2024) рекомендує тестувати сценарії memory warning на кожному екрані застосунку.

Цілі стрес-тестування

Визначення точки відмови

Перша мета Stress Test — визначення точки відмови (breaking point). Це момент, коли один із ключових показників продуктивності перетинає критичний поріг: час відповіді p95 перевищує 10 секунд, відсоток помилок HTTP 5XX перевищує 5%, або пропускна здатність падає нижче 50% від baseline. Фіксація точки відмови дозволяє команді заздалегідь знати межу масштабування системи. Capacity planning спирається саме на дані Stress Test, а не Load Test, оскільки Load Test не перевіряє граничні умови.

Перевірка механізмів відновлення

Друга мета — перевірка механізмів відновлення. Після того як навантаження знижується до нормального рівня, система повинна повернутися до штатних показників. Якщо пул з’єднань до бази даних не звільняється або кеш не інвалідується, Stress Test виявить цю проблему. Circuit breaker (Hystrix, Resilience4j) повинен спрацьовувати при перевантаженні та автоматично відновлювати з’єднання після стабілізації. Health check ендпоїнти допомагають моніторити стан кожного сервісу під час тесту.

Валідація auto-scaling

Третя мета — валідація auto-scaling. Якщо інфраструктура використовує Kubernetes або AWS Auto Scaling, Stress Test перевіряє, що нові pod-и або інстанси створюються достатньо швидко. За даними Google Kubernetes Engine (2024), час розгортання нового pod-а не повинен перевищувати 30 секунд з моменту спрацьовування метрики HPA (Horizontal Pod Autoscaler). HPA повинен масштабуватися на основі CPU, пам’яті та кастомних метрик. Cluster Autoscaler додає нові ноди, якщо поточні не вміщують pod-и.

Методологія Stress Test

Поступове збільшення навантаження (Ramp-up Stress Test) — найпоширеніший сценарій. Початкове навантаження встановлюється на рівні 50% від очікуваного, потім кожні 2 хвилини збільшується на 10% до тих пір, поки система не відмовить. Цей сценарій дозволяє знайти точну межу стійкості. Grafana Cloud k6 (2025) рекомендує крок збільшення не більше 10% для отримання плавного графіка часу відповіді.

Різкий стрибок навантаження (Spike Stress Test) — навантаження збільшується з 10% до 500% за 10–30 секунд. Цей сценарій моделює ситуації на зразок вірусного поширення контенту або DDoS-атаки. Spike Stress Test перевіряє не стільки продуктивність, скільки живучість системи: здатність не впасти повністю та повернутися до роботи після стабілізації. API Gateway повинен налаштувати rate limiting для захисту бекенду від різких стрибків.

Тривале утримання перевантаження (Sustained Stress Test) — система утримується в стані перевантаження протягом 30–60 хвилин. Цей сценарій виявляє витоки ресурсів, які не проявляються при короткочасних тестах. Витік пам’яті в Java/Kotlin застосунках накопичується протягом 20–40 хвилин інтенсивної роботи, і тільки Sustained Stress Test його виявляє.

Аналіз точки відмови та відновлення

Точка відмови визначається за трьома критеріями: час відповіді, відсоток помилок та пропускна здатність. Першим зазвичай перевищується поріг часу відповіді — запити починають виконуватися довше встановленого ліміту. Потім зростає відсоток помилок: сервер не встигає обробляти запити та повертає 503. Останнім падає Throughput — система перестає справлятися навіть з мінімальним навантаженням. Метрика точки відмови фіксується в навантажувальному профілі для планування потужностей.

Аналіз відновлення включає три фази: негайна реакція (перші 30 секунд після зняття навантаження), стабілізація (1–5 хвилин) та повне відновлення (5–30 хвилин). У фазі негайної реакції час відповіді повинен впасти нижче baseline — система звільняється від черг. Якщо цього не відбувається, проблема не в навантаженні, а в накопиченому стані. Graceful degradation — здатність системи зберігати часткову функціональність при перевантаженні — ключовий показник зрілості архітектури.

Chaos Engineering доповнює Stress Test навмисним внесенням збоїв: відключення сервера бази даних, затримка мережі, зупинка мікросервісу. Chaos Monkey від Netflix (2024) випадковим чином завершує процеси в production, перевіряючи стійкість системи. Для мобільних застосунків Chaos Engineering означає тестування сценаріїв: відсутність мережі, недоступність API, порожня відповідь сервера.

Інструменти для Stress Test

k6 з ramping-arrival-rate

k6 підтримує Stress Test через модуль `execution` з конфігурацією ramping-arrival-rate. Цей режим збільшує кількість запитів за секунду незалежно від часу виконання кожного запиту. Порівняно з Load Test, Stress Test у k6 вимагає налаштування більш агресивних thresholds та відключення gracefull-stop для імітації різкої відмови. Grafana Cloud автоматично виявляє точку відмови по зламу графіка часу відповіді. k6-operator для Kubernetes дозволяє запускати розподілені Stress Test з кластера.

JMeter з Ultimate Thread Group

JMeter дозволяє налаштувати Stress Test через Ultimate Thread Group — плагін, який задає профіль навантаження у вигляді таблиці: кількість потоків, час розігріву, час утримання, час спаду. Ultimate Thread Group зручний для складних багатофазних сценаріїв. JMeter Backend Listener надсилає метрики в InfluxDB для побудови графіків точки відмови. Для Stress Test JMeter рекомендується відключати таймаути з’єднань, щоб точніше виміряти поведінку при перевантаженні.

Gremlin для Chaos Engineering

Gremlin — платформа Chaos Engineering для Stress Test інфраструктури. Gremlin дозволяє відключати мережу, навантажувати CPU, заповнювати диск та завершувати процеси на рівні окремих pod-ів Kubernetes. SRE-команди використовують Gremlin разом з k6 для комплексного Stress Test: k6 створює навантаження, Gremlin вносить збої. Game Day — регулярні сесії Stress Test з використанням Gremlin, які документуються в «chaos report» для аналізу стійкості системи.

Приклад Stress Test на k6

Наведений скрипт на k6 демонструє Stress Test з поступовим збільшенням навантаження до відмови. Ramping-arrival-rate збільшує кількість запитів за секунду незалежно від часу виконання. Thresholds налаштовані на агресивне виявлення деградації: p95 не більше 2000 мс, error rate не більше 5%. При перевищенні порогів k6 завершує тест з кодом помилки, що дозволяє вбудувати Stress Test у CI/CD пайплайн.

import http from 'k6/http'
import check from 'k6'

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

export default function() {
    const res = http.get('https://api.example.com/health')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
}

Найкращі практики стрес-тестування

Починайте Stress Test на staging — production-стрес-тестування вимагає просунутого моніторингу та плану відкату. Google SRE (2024) рекомендує проводити Stress Test у 100% ізольованому середовищі, яке повторює production за архітектурою та потужностями. Після успішного тесту на staging можна переходити до production під наглядом SRE. Feature flag для відключення функціональності при перевантаженні — обов’язковий елемент.

Автоматизуйте Stress Test у CI/CD для регресійного аналізу точки відмови. Якщо нова версія застосунку має точку відмови на 20% нижче попередньої, це регресія, яку потрібно виправити до релізу. Baseline breaking point зберігається в метриках і автоматично порівнюється з результатом кожного Stress Test. Алерт спрацьовує при падінні точки відмови на 10%.

Документуйте кожен Stress Test: профіль навантаження, точка відмови, поведінка відновлення та список виявлених проблем. Netflix Engineering (2024) веде «Game Day» — регулярні сесії Stress Test, результати яких документуються в «chaos report». Звіт про стрес-тестування повинен містити графік «RPS — час відповіді» з позначеною точкою відмови.