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

Шта је 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 укључује проверу рада при принудном завршетку процеса, искључивању мреже и исцрпљивању 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 ендпоинти помажу у праћењу стања сваког сервиса током теста.

Валидација auto-scaling-а

Трећи циљ — валидација auto-scaling-а. Ако инфраструктура користи Kubernetes или AWS Auto Scaling, Stress Test проверава да ли се нови под-ови или инстанце креирају довољно брзо. Према Google Kubernetes Engine (2024), време примене новог под-а не би требало да прелази 30 секунди од тренутка активирања метрике HPA (Horizontal Pod Autoscaler). HPA треба да се скалира на основу CPU-а, меморије и прилагођених метрика. Cluster Autoscaler додаје нове чворове ако постојећи не могу да приме под-ове.

Методологија 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) насумично завршава процесе у продукцији, проверавајући отпорност система. За мобилне апликације, 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 под-ова. 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 — време одговора” са обележеном тачком отказа.