Mobil geliştirmede Stres Testi: nedir, amaçları ve nasıl yapılır

Stress Test Nedir?

Stress Test (stres testi) — sistemin hesaplanan değerleri aşan koşullarda çalışma yeteneğini değerlendiren bir süreçtir. Mobil uygulama için bu, norm 1000 iken 10000 eşzamanlı push bildirimi, backend için — beklenen 5000'e karşı 50000 RPS anlamına gelebilir. Stress Test'i Load Test'ten ayıran temel fark, amacın performansı onaylamak değil, sistemin tasarım kapasitesinin ötesindeki davranışını incelemektir. Netflix Engineering (2024) Stress Test'i “sistemin tahmin edilebilir şekilde çökeceği hipotezinin test edilmesi” olarak tanımlar.

Stres testi iki zorunlu aşama içerir: arızaya kadar yükleme ve kurtarmanın gözlemlenmesi. Kurtarma (recovery) — aşırı yük kaldırıldıktan sonra sistemin normal çalışmaya dönme yeteneği. Yeniden başlatma olmadan kurtarılamayan sistem, kısa süreli aşırı yüke dayansa bile kırılgan kabul edilir. AWS Well-Architected Framework (2024)'e göre, Stress Test sonrası kurtarma süresi 5 dakikayı geçmemelidir.

Mobil istemciler için Stress Test, zorla süreç sonlandırma, ağ bağlantısının kesilmesi ve RAM tükenmesi durumlarında çalışmanın kontrolünü içerir. Android Low Memory Killer, RAM yetersizliğinde arka plan sürecini sonlandırabilir — stres testi, uygulamanın bu tür bir sonlandırmadan sonra durumu doğru şekilde geri yüklediğini doğrulamalıdır. Apple UIKit (2024), uygulamanın her ekranında bellek uyarı senaryolarının test edilmesini önerir.

Stres Testinin Amaçları

Başarısızlık noktasının belirlenmesi

Stress Test'in ilk amacı başarısızlık noktasının belirlenmesidir (breaking point). Bu, temel performans göstergelerinden birinin kritik bir eşiği aştığı andır: p95 yanıt süresi 10 saniyeyi aşar, HTTP 5XX hata yüzdesi %5'i aşar veya işlem hacmi referansın %50'sinin altına düşer. Başarısızlık noktasının kaydedilmesi, ekibin sistemin ölçeklenebilirlik sınırını önceden bilmesini sağlar. Kapasite planlaması, Load Test'e değil, tam olarak Stress Test verilerine dayanır çünkü Load Test sınır koşullarını kontrol etmez.

Kurtarma mekanizmalarının kontrolü

İkinci amaç kurtarma mekanizmalarının kontrolüdür. Yük normal seviyeye düştükten sonra sistem standart göstergelere dönmelidir. Veritabanı bağlantı havuzu serbest bırakılmazsa veya önbellek geçersiz kılınmazsa, Stress Test bu sorunu tespit edecektir. Circuit breaker (Hystrix, Resilience4j) aşırı yükte tetiklenmeli ve stabilizasyondan sonra otomatik olarak bağlantıyı geri yüklemelidir. Health check uç noktaları, test sırasında her hizmetin durumunu izlemeye yardımcı olur.

Auto-scaling doğrulaması

Üçüncü amaç auto-scaling doğrulamasıdır. Altyapı Kubernetes veya AWS Auto Scaling kullanıyorsa, Stress Test yeni pod veya örneklerin yeterince hızlı oluşturulduğunu kontrol eder. Google Kubernetes Engine (2024)'e göre, HPA (Horizontal Pod Autoscaler) metriği tetiklendikten sonra yeni bir pod'un dağıtım süresi 30 saniyeyi geçmemelidir. HPA, CPU, bellek ve özel metrikler temelinde ölçeklenmelidir. Cluster Autoscaler, mevcut düğümler pod'ları barındıramazsa yeni düğümler ekler.

Stress Test Metodolojisi

Kademeli yük artışı (Ramp-up Stress Test) — en yaygın senaryo. Başlangıç yükü beklenen yükün %50'sine ayarlanır, ardından sistem arızalanana kadar her 2 dakikada bir %10 artırılır. Bu senaryo, dayanıklılığın tam sınırını bulmayı sağlar. Grafana Cloud k6 (2025), yanıt süresinin düzgün bir grafiğini elde etmek için %10'dan fazla artış yapılmamasını önerir.

Ani yük sıçraması (Spike Stress Test) — yük 10–30 saniye içinde %10'dan %500'e yükselir. Bu senaryo, viral içerik yayılımı veya DDoS saldırısı gibi durumları modeller. Spike Stress Test, performanstan çok sistemin hayatta kalma yeteneğini test eder: tamamen çökmeme ve stabilizasyondan sonra çalışmaya dönme yeteneği. API Gateway, backend'i ani sıçramalardan korumak için hız sınırlaması yapılandırmalıdır.

Uzun süreli aşırı yük koruma (Sustained Stress Test) — sistem 30–60 dakika boyunca aşırı yük durumunda tutulur. Bu senaryo, kısa süreli testlerde ortaya çıkmayan kaynak sızıntılarını ortaya çıkarır. Bellek sızıntısı Java/Kotlin uygulamalarında 20–40 dakikalık yoğun çalışma sırasında birikir ve yalnızca Sustained Stress Test bunu tespit eder.

Başarısızlık Noktası ve Kurtarma Analizi

Başarısızlık noktası üç kritere göre belirlenir: yanıt süresi, hata yüzdesi ve işlem hacmi. Genellikle önce yanıt süresi eşiği aşılır — istekler belirlenen sınırı aşan sürelerde yürütülmeye başlar. Ardından hata yüzdesi artar: sunucu istekleri işleyemez ve 503 döndürür. Son olarak Throughput düşer — sistem minimum yükü bile kaldıramaz hale gelir. Başarısızlık noktası metriği, kapasite planlaması için yük profiline kaydedilir.

Kurtarma analizi üç aşama içerir: acil tepki (yük kaldırıldıktan sonraki ilk 30 saniye), stabilizasyon (1–5 dakika) ve tam kurtarma (5–30 dakika). Acil tepki aşamasında yanıt süresi referansın altına düşmelidir — sistem kuyruklardan kurtulur. Bu gerçekleşmezse, sorun yükte değil birikmiş durumdadır. Graceful degradation — sistemin aşırı yükte kısmi işlevselliği sürdürme yeteneği — mimari olgunluğunun anahtar göstergesidir.

Chaos Engineering, kasıtlı hata sokarak Stress Test'i tamamlar: veritabanı sunucusunu durdurma, ağ gecikmesi, mikro hizmeti durdurma. Chaos Monkey (Netflix, 2024), üretimde rastgele süreçleri sonlandırarak sistemin dayanıklılığını test eder. Mobil uygulamalar için Chaos Engineering, senaryoları test etmek anlamına gelir: ağ yokluğu, API kullanılamazlığı, boş sunucu yanıtı.

Stress Test Araçları

ramping-arrival-rate ile k6

k6, ramping-arrival-rate yapılandırmasıyla `execution` modülü aracılığıyla Stress Test'i destekler. Bu mod, her isteğin yürütme süresinden bağımsız olarak saniyedeki istek sayısını artırır. Load Test'e kıyasla, k6'da Stress Test daha agresif eşik yapılandırması ve ani arızayı simüle etmek için gracefull-stop'un devre dışı bırakılmasını gerektirir. Grafana Cloud, yanıt süresi grafiğinin kırılma noktasından otomatik olarak başarısızlık noktasını tespit eder. k6-operator for Kubernetes, kümeden dağıtık Stress Test çalıştırmaya olanak tanır.

Ultimate Thread Group ile JMeter

JMeter, Ultimate Thread Group aracılığıyla Stress Test yapılandırmaya olanak tanır — bu eklenti, yük profilini tablo biçiminde tanımlar: iş parçacığı sayısı, ısınma süresi, koruma süresi, soğuma süresi. Ultimate Thread Group, karmaşık çok aşamalı senaryolar için kullanışlıdır. JMeter Backend Listener, başarısızlık noktası grafikleri oluşturmak için InfluxDB'ye metrik gönderir. Stress Test için, aşırı yükte davranışı daha doğru ölçmek amacıyla JMeter'da bağlantı zaman aşımlarının devre dışı bırakılması önerilir.

Chaos Engineering için Gremlin

Gremlin — altyapı Stress Test'i için bir Chaos Engineering platformudur. Gremlin, ağı kesmeye, CPU'yu yüklemeye, diski doldurmaya ve Kubernetes'in ayrı pod'larında süreçleri sonlandırmaya olanak tanır. SRE ekipleri, kapsamlı Stress Test için Gremlin'i k6 ile birlikte kullanır: k6 yük oluşturur, Gremlin hatalar sokar. Game Day — Gremlin kullanılarak yapılan düzenli Stress Test oturumları, sistem dayanıklılığını analiz etmek için “caos raporu” olarak belgelenir.

k6'da Stress Test Örneği

Aşağıdaki k6 betiği, arızaya kadar kademeli yük artışıyla Stress Test'i göstermektedir. Ramping-arrival-rate, her isteğin yürütme süresinden bağımsız olarak saniyedeki istek sayısını artırır. Eşikler, agresif bozulma tespiti için yapılandırılmıştır: p95 2000 ms'yi geçmemeli, hata oranı %5'i geçmemelidir. Eşikler aşıldığında k6 testi hata koduyla sonlandırır, bu da Stress Test'in CI/CD boru hattına entegre edilmesini sağlar.

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,
    })
}

Stres Testi En İyi Uygulamaları

Stress Test'e staging'de başlayın — üretim stres testi, gelişmiş izleme ve geri alma planı gerektirir. Google SRE (2024), mimari ve kapasite açısından üretimi yansıtan %100 izole bir ortamda Stress Test yapılmasını önerir. Staging'de başarılı testin ardından SRE gözetiminde üretime geçilebilir. Feature flag ile aşırı yükte işlevselliği kapatma — zorunlu bir unsurdur.

CI/CD'de Stress Test'i otomatikleştirin başarısızlık noktasının regresyon analizi için. Uygulamanın yeni sürümünün başarısızlık noktası öncekinden %20 daha düşükse, bu sürümden önce düzeltilmesi gereken bir regresyondur. Temel başarısızlık noktası metriklerde saklanır ve her Stress Test sonucuyla otomatik olarak karşılaştırılır. Başarısızlık noktası %10 düştüğünde uyarı tetiklenir.

Her Stress Test'i belgeleyin: yük profili, başarısızlık noktası, kurtarma davranışı ve bulunan sorunların listesi. Netflix Engineering (2024), sonuçları “caos raporu” olarak belgelenen düzenli Stress Test oturumları olan “Game Day” düzenler. Stres testi raporu, başarısızlık noktası işaretlenmiş “RPS — yanıt süresi” grafiğini içermelidir.