Stress Test в мобилната разработка: какво е, цели и как се провежда

Какво е Stress Test?

Stress Test (стрес тестване) е процес на оценка на способността на системата да работи в условия, надвишаващи изчислените параметри. За мобилно приложение това може да означава 10000 едновременни push известия при норма 1000, за backend — 50000 RPS при очаквани 5000. Основната разлика между Stress Test и Load Test е, че целта не е потвърждаване на производителността, а изучаване на поведението на системата извън нейния проектен капацитет. Netflix Engineering (2024) определя Stress Test като „проверка на хипотезата, че системата ще се повреди по предвидим начин”.

Стрес тестването включва два задължителни етапа: натоварване до отказ и наблюдение на възстановяването. Възстановяване (recovery) е способността на системата да се върне към нормална работа след премахване на претоварването. Система, която не се възстановява без рестартиране, се счита за крехка, дори ако издържа краткотрайно претоварване. Според AWS Well-Architected Framework (2024), времето за възстановяване след Stress Test не трябва да надвишава 5 минути.

За мобилни клиенти Stress Test включва проверка на работата при принудително прекратяване на процеси, изключване на мрежа и изчерпване на RAM паметта. 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 крайните точки помагат за наблюдение на състоянието на всяка услуга по време на теста.

Валидиране на авто-скалиране

Третата цел — валидиране на авто-скалиране. Ако инфраструктурата използва 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) за защита на backend от резки скокове.

Продължително задържане на претоварване (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) произволно прекратява процеси в продукция, проверявайки устойчивостта на системата. За мобилни приложения 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, запълване на диск и прекратяване на процеси на ниво отделни Kubernetes pod-ове. 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 ms, 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 — стрес тестването в продукция изисква напреднало наблюдение и план за връщане. Google SRE (2024) препоръчва провеждане на Stress Test в 100% изолирана среда, която повтаря продукцията по архитектура и капацитет. След успешен тест на staging може да се премине към продукция под надзора на 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 — време за отговор” с отбелязана точка на отказ.