Stress Test dalam pengembangan mobile: apa itu, tujuan dan cara melakukannya

Apa itu Stress Test?

Stress Test (pengujian stres) adalah proses evaluasi kemampuan sistem untuk bekerja dalam kondisi yang melebihi parameter yang diperhitungkan. Untuk aplikasi mobile, ini bisa berarti 10000 notifikasi push simultan dengan norma 1000, untuk backend — 50000 RPS dengan 5000 yang diharapkan. Perbedaan utama antara Stress Test dan Load Test adalah bahwa tujuannya bukan untuk mengonfirmasi kinerja, tetapi untuk mempelajari perilaku sistem di luar kapasitas yang dirancang. Netflix Engineering (2024) mendefinisikan Stress Test sebagai “pengujian hipotesis bahwa sistem akan gagal secara dapat diprediksi”.

Pengujian stres mencakup dua tahap wajib: pembebanan hingga kegagalan dan observasi pemulihan. Pemulihan (recovery) adalah kemampuan sistem untuk kembali ke operasi normal setelah kelebihan beban dihilangkan. Sistem yang tidak pulih tanpa restart dianggap rapuh, bahkan jika dapat menahan kelebihan beban jangka pendek. Menurut AWS Well-Architected Framework (2024), waktu pemulihan setelah Stress Test tidak boleh melebihi 5 menit.

Untuk klien mobile, Stress Test mencakup pemeriksaan operasi saat penghentian paksa proses, pemutusan jaringan, dan kehabisan memori RAM. Android Low Memory Killer dapat menghentikan proses latar belakang saat RAM tidak mencukupi — pengujian stres harus memeriksa apakah aplikasi memulihkan status dengan benar setelah penghentian tersebut. Apple UIKit (2024) merekomendasikan pengujian skenario memory warning di setiap layar aplikasi.

Tujuan pengujian stres

Menentukan titik kegagalan

Tujuan pertama Stress Test — menentukan titik kegagalan (breaking point). Ini adalah saat salah satu indikator kinerja utama melampaui ambang kritis: waktu respons p95 melebihi 10 detik, persentase kesalahan HTTP 5XX melebihi 5%, atau throughput turun di bawah 50% dari baseline. Pencatatan titik kegagalan memungkinkan tim mengetahui batas skalabilitas sistem sejak dini. Capacity planning justru bergantung pada data Stress Test, bukan Load Test, karena Load Test tidak memeriksa kondisi batas.

Memeriksa mekanisme pemulihan

Tujuan kedua — memeriksa mekanisme pemulihan. Setelah beban turun ke tingkat normal, sistem harus kembali ke indikator standar. Jika kumpulan koneksi ke database tidak dibebaskan atau cache tidak diinvalidasi, Stress Test akan mengungkapkan masalah ini. Circuit breaker (Hystrix, Resilience4j) harus aktif saat kelebihan beban dan secara otomatis memulihkan koneksi setelah stabilisasi. Health check endpoint membantu memantau status setiap layanan selama pengujian.

Validasi auto-scaling

Tujuan ketiga — validasi auto-scaling. Jika infrastruktur menggunakan Kubernetes atau AWS Auto Scaling, Stress Test memeriksa apakah pod atau instance baru dibuat cukup cepat. Menurut Google Kubernetes Engine (2024), waktu penyebaran pod baru tidak boleh melebihi 30 detik sejak metrik HPA (Horizontal Pod Autoscaler) terpicu. HPA harus melakukan penskalaan berdasarkan CPU, memori, dan metrik kustom. Cluster Autoscaler menambahkan node baru jika node yang ada tidak dapat menampung pod.

Metodologi Stress Test

Peningkatan bertahap beban (Ramp-up Stress Test) — skenario paling umum. Beban awal ditetapkan pada 50% dari yang diharapkan, kemudian setiap 2 menit ditingkatkan sebesar 10% hingga sistem gagal. Skenario ini memungkinkan menemukan batas ketahanan yang tepat. Grafana Cloud k6 (2025) merekomendasikan langkah peningkatan tidak lebih dari 10% untuk mendapatkan grafik waktu respons yang halus.

Lonjakan mendadak beban (Spike Stress Test) — beban meningkat dari 10% menjadi 500% dalam 10–30 detik. Skenario ini memodelkan situasi seperti penyebaran konten secara viral atau serangan DDoS. Spike Stress Test tidak begitu banyak memeriksa kinerja melainkan ketahanan sistem: kemampuan untuk tidak jatuh sepenuhnya dan kembali bekerja setelah stabilisasi. API Gateway harus mengonfigurasi rate limiting untuk melindungi backend dari lonjakan mendadak.

Penahanan beban berlebihan dalam waktu lama (Sustained Stress Test) — sistem dipertahankan dalam keadaan kelebihan beban selama 30–60 menit. Skenario ini mengungkapkan kebocoran sumber daya yang tidak muncul pada pengujian jangka pendek. Kebocoran memori pada aplikasi Java/Kotlin terakumulasi selama 20–40 menit kerja intensif dan hanya Sustained Stress Test yang mendeteksinya.

Analisis titik kegagalan dan pemulihan

Titik kegagalan ditentukan berdasarkan tiga kriteria: waktu respons, persentase kesalahan, dan throughput. Biasanya yang pertama terlampaui adalah ambang waktu respons — permintaan mulai dieksekusi lebih lama dari batas yang ditetapkan. Kemudian persentase kesalahan meningkat: server tidak sempat memproses permintaan dan mengembalikan 503. Yang terakhir menurun adalah Throughput — sistem tidak mampu menangani bahkan beban minimal. Metrik titik kegagalan dicatat dalam profil beban untuk perencanaan kapasitas.

Analisis pemulihan mencakup tiga fase: reaksi segera (30 detik pertama setelah beban dihilangkan), stabilisasi (1–5 menit), dan pemulihan penuh (5–30 menit). Pada fase reaksi segera, waktu respons harus turun di bawah baseline — sistem terbebas dari antrean. Jika ini tidak terjadi, masalahnya bukan pada beban tetapi pada akumulasi status. Graceful degradation — kemampuan sistem untuk mempertahankan fungsionalitas parsial saat kelebihan beban — adalah indikator utama kematangan arsitektur.

Chaos Engineering melengkapi Stress Test dengan sengaja memasukkan kegagalan: mematikan server database, menunda jaringan, menghentikan mikrolayanan. Chaos Monkey dari Netflix (2024) secara acak menghentikan proses di produksi, menguji ketahanan sistem. Untuk aplikasi mobile, Chaos Engineering berarti pengujian skenario: tidak ada jaringan, API tidak tersedia, respons server kosong.

Alat untuk Stress Test

k6 dengan ramping-arrival-rate

k6 mendukung Stress Test melalui modul `execution` dengan konfigurasi ramping-arrival-rate. Mode ini meningkatkan jumlah permintaan per detik tanpa tergantung pada waktu eksekusi setiap permintaan. Dibandingkan dengan Load Test, Stress Test di k6 memerlukan pengaturan thresholds yang lebih agresif dan penonaktifan gracefull-stop untuk simulasi kegagalan mendadak. Grafana Cloud secara otomatis mendeteksi titik kegagalan berdasarkan patahan grafik waktu respons. k6-operator untuk Kubernetes memungkinkan menjalankan Stress Test terdistribusi dari cluster.

JMeter dengan Ultimate Thread Group

JMeter memungkinkan konfigurasi Stress Test melalui Ultimate Thread Group — plugin yang menentukan profil beban dalam bentuk tabel: jumlah thread, waktu pemanasan, waktu penahanan, waktu penurunan. Ultimate Thread Group nyaman untuk skenario multi-fase yang kompleks. JMeter Backend Listener mengirim metrik ke InfluxDB untuk membangun grafik titik kegagalan. Untuk Stress Test di JMeter, disarankan menonaktifkan timeout koneksi untuk mengukur perilaku saat kelebihan beban dengan lebih akurat.

Gremlin untuk Chaos Engineering

Gremlin — platform Chaos Engineering untuk Stress Test infrastruktur. Gremlin memungkinkan mematikan jaringan, membebani CPU, mengisi disk, dan menghentikan proses di tingkat pod Kubernetes individu. Tim SRE menggunakan Gremlin bersama k6 untuk Stress Test komprehensif: k6 menciptakan beban, Gremlin memasukkan kegagalan. Game Day — sesi Stress Test reguler dengan Gremlin yang didokumentasikan dalam “laporan chaos” untuk analisis ketahanan sistem.

Contoh Stress Test pada k6

Skrip pada k6 yang disajikan mendemonstrasikan Stress Test dengan peningkatan beban bertahap hingga kegagalan. Ramping-arrival-rate meningkatkan jumlah permintaan per detik tanpa tergantung pada waktu eksekusi. Thresholds diatur untuk deteksi degradasi yang agresif: p95 tidak lebih dari 2000 ms, error rate tidak lebih dari 5%. Saat ambang terlampaui, k6 mengakhiri pengujian dengan kode kesalahan, yang memungkinkan integrasi Stress Test ke dalam pipeline 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,
    })
}

Praktik terbaik pengujian stres

Mulai Stress Test di staging — pengujian stres di produksi memerlukan pemantauan lanjutan dan rencana pengembalian. Google SRE (2024) merekomendasikan melakukan Stress Test di lingkungan 100% terisolasi yang mereplikasi produksi dalam hal arsitektur dan kapasitas. Setelah pengujian berhasil di staging, dapat beralih ke produksi di bawah pengawasan SRE. Feature flag untuk menonaktifkan fungsionalitas saat kelebihan beban adalah elemen wajib.

Otomatiskan Stress Test di CI/CD untuk analisis regresi titik kegagalan. Jika versi baru aplikasi memiliki titik kegagalan 20% lebih rendah dari versi sebelumnya, ini adalah regresi yang harus diperbaiki sebelum rilis. Baseline breaking point disimpan dalam metrik dan secara otomatis dibandingkan dengan hasil setiap Stress Test. Peringatan dipicu saat titik kegagalan turun 10%.

Dokumentasikan setiap Stress Test: profil beban, titik kegagalan, perilaku pemulihan, dan daftar masalah yang ditemukan. Netflix Engineering (2024) menyelenggarakan “Game Day” — sesi Stress Test reguler yang hasilnya didokumentasikan dalam “laporan chaos”. Laporan pengujian stres harus berisi grafik “RPS — waktu respons” dengan titik kegagalan yang ditandai.