Belajar Performance Test Engineer - Stress, Soak & Spike Testing

#Pendahuluan

Setelah di episode 3-5 kita memahami load testing dan tools (k6, JMeter, Locust), kini saatnya melangkah ke genre testing yang lebih spesifik: stress testing, soak testing, dan spike testing. Ketiga genre ini menguji aspek yang berbeda dari load testing biasa — yang menjawab "bisakah sistem menangani beban normal?", ketiga genre ini menjawab "bagaimana sistem bereaksi saat beban tidak normal?"

Memahami perbedaan genre ini krusial karena masing-masing mengungkap jenis masalah yang berbeda. Load testing menemukan bottleneck normal; stress testing menemukan breaking point; soak testing menemukan memory leak; spike testing menemukan resilience terhadap lonjakan mendadak.

#Stress Testing

Stress testing menguji sistem di luar kapasitas normalnya untuk menemukan breaking point — titik di mana sistem mulai gagal, error rate melonjak, atau latency tidak bisa diterima. Stress testing menjawab pertanyaan: "Di titik mana sistem mulai rusak, dan bagaimana ia pulih?"

#Perbedaan dengan Load Testing

#Stress Test Profile

// k6 stress test: ramp-up agresif sampai sistem gagal
import http from 'k6/http';
import { check } from 'k6';
 
export const options = {
  stages: [
    { duration: '2m', target: 100 },   // Normal load
    { duration: '2m', target: 200 },   // Di atas normal
    { duration: '2m', target: 400 },   // Stress level
    { duration: '2m', target: 600 },   // High stress
    { duration: '2m', target: 800 },   // Extreme stress
    { duration: '2m', target: 0 },     // Recovery
  ],
};
 
export default function () {
  const res = http.get('https://api.example.com/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 2000ms': (r) => r.timings.duration < 2000,
  });
}

#Apa yang Dicari dalam Stress Test

• Titik error rate mulai naik: di berapa VUs error rate melebihi 1%?
• Titik latency melonjak: di berapa VUs p95 latency melonjak tiba-tiba?
• Pola degradasi: apakah degradasi gradual atau ada cliff di mana sistem tiba-tiba gagal total?
• Recovery behavior: setelah beban berkurang, apakah sistem pulih atau tetap dalam kondisi buruk?

#Soak Testing (Endurance Testing)

Soak testing menjalankan beban normal atau sedikit di atas normal dalam durasi panjang — biasanya 4-24 jam — untuk mendeteksi masalah yang hanya muncul seiring waktu: memory leak, disk space exhaustion, connection pool depletion, dan gradual performance degradation.

#Mengapa Durasi Panjang Penting

Banyak masalah performa tidak terlihat dalam test 5 menit. Memory leak misalnya: JVM mungkin butuh 2 jam untuk menghabiskan semua memory dan mulai garbage collect agresif. Connection pool depletion muncul setelah ribuan request yang tidak benar-benar menutup koneksi. Soak testing menangkap masalah-masalah ini.

#Soak Test Profile

// k6 soak test: 4 jam steady-state
export const options = {
  stages: [
    { duration: '5m', target: 50 },   // Ramp-up 5 menit
    { duration: '4h', target: 50 },   // Steady-state 4 jam
    { duration: '5m', target: 0 },    // Ramp-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

#Monitoring yang Kritis Selama Soak Test

Soak test tanpa monitoring jangka panjang adalah pemborosan waktu. Yang harus dipantau:

• Memory usage (RSS): apakah naik seiring waktu? → indikasi memory leak
• Disk space: apakah log atau temporary files menghabiskan disk?
• Connection pool: apakah koneksi ke database tetap stabil?
• CPU usage: apakah ada tren naik yang gradual?

# Monitoring memory usage setiap 60 detik selama soak test
while true; do
  echo "$(date): $(free -m | awk 'NR==2{printf "%.1f%%", $3*100/$2}')"
  sleep 60
done > memory-monitor.log

#Spike Testing

Spike testing menguji bagaimana sistem bereaksi terhadap lonjakan mendadak dari traffic yang sangat rendah ke sangat tinggi dalam waktu singkat. Ini meniru skenario real: flash sale, Black Friday, atau viral social media post.

#Perbedaan dengan Stress Testing

#Spike Test Profile

// k6 spike test: lonjakan mendadak
export const options = {
  scenarios: {
    normal: {
      executor: 'constant-vus',
      vus: 10,
      duration: '5m',
    },
    spike: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '10s', target: 0 },    // Normal
        { duration: '10s', target: 500 },  // Spike naik
        { duration: '2m', target: 500 },   // Tahan spike
        { duration: '10s', target: 0 },    // Spike turun
      ],
    },
  },
};

#Apa yang Dicari dalam Spike Test

• Autoscaling response: apakah sistem otomatis menambah resource saat spike?
• Rate limiting: apakah ada rate limiting yang aktif, dan apakah ia mengembalikan 429 yang wajar?
• Graceful degradation: saat overload, apakah sistem memberikan error yang jelas atau crash total?
• Recovery time: berapa lama sistem pulih setelah spike berakhir?

#Kapan Menggunakan Setiap Genre

#Common Pitfalls

#Stress Testing di Environment yang Tidak Mirip Production

Stress test di dev environment tidak mengungkap masalah production — scaling behavior, network latency, dan resource limits berbeda. Selalu jalankan stress test di environment staging yang mirip production.

#Soak Test yang Terlalu Pendek

Soak test 1 jam mungkin tidak cukup untuk mendeteksi memory leak yang muncul setelah 4 jam. Sesuaikan durasi dengan karakteristik aplikasi — bicara dengan developer untuk memahami siklus garbage collection dan connection pooling.

#Spike Test Tanpa Monitoring Real-time

Spike terjadi sangat cepat. Tanpa monitoring real-time (Grafana dashboard), kalian akan kehilangan moment kritis saat sistem mulai gagal.

#Penutup

Di episode 6 ini kalian telah memahami tiga genre testing beyond load testing:

• Stress testing: menemukan breaking point dengan ramp-up agresif.
• Soak testing: mendeteksi memory leak dan degradation dengan durasi panjang.
• Spike testing: menguji resilience terhadap lonjakan mendadak.

Di episode 7 selanjutnya, kita akan memfokuskan testing ke area spesifik: API & Database Performance — menguji endpoint API secara spesifik dan mengidentifikasi query database yang lambat. Siapkan skenario testing yang lebih realistis!