Perangkat lunak yang “berfungsi” belum tentu berfungsi saat menerima beban nyata. Sebuah fitur bisa lolos semua uji fungsional, rilis tanpa masalah, lalu melambat atau gagal ketika trafik pengguna mulai masuk. Pengujian kinerja menutup celah itu dengan mengukur kecepatan, stabilitas, dan skalabilitas sistem saat sibuk.
Panduan ini membahas apa itu pengujian kinerja, jenis pengujian yang umum dipakai, metrik yang perlu dipantau, serta cara memasukkannya ke alur pengembangan modern.
Apa itu pengujian kinerja
Pengujian kinerja mengevaluasi bagaimana sistem merespons beban kerja tertentu. Fokusnya bukan hanya:
“Apakah fitur ini benar?”
Tetapi juga:
“Seberapa cepat responsnya, berapa banyak beban yang bisa ditangani, dan apa yang terjadi ketika kapasitasnya terlampaui?”
Contoh sederhana:
- Uji fungsional login memastikan endpoint mengembalikan token yang valid.
- Uji kinerja login memastikan endpoint tetap cepat dan stabil saat dipanggil oleh ratusan atau ribuan pengguna secara bersamaan.
Sebuah endpoint bisa benar secara fungsional, tetapi tetap buruk secara performa jika membutuhkan empat detik untuk merespons di bawah beban.
Hasil pengujian kinerja biasanya bukan sekadar “lulus” atau “gagal”. Hasilnya adalah profil sistem:
- Pada beban tertentu, waktu responsnya berapa?
- Throughput maksimalnya berapa?
- Error mulai muncul di titik mana?
- Bottleneck terjadi di CPU, memori, database, atau dependency eksternal?
Profil ini membantu tim menetapkan target layanan, merencanakan kapasitas, dan mendeteksi regresi sebelum rilis.
Jenis-jenis utama pengujian kinerja
Pengujian kinerja terdiri dari beberapa tipe. Masing-masing menjawab pertanyaan yang berbeda.
1. Baseline testing
Baseline testing menjalankan sistem pada beban normal untuk membuat angka referensi.
Gunakan baseline untuk menjawab:
- Berapa waktu respons normal?
- Berapa throughput normal?
- Berapa penggunaan CPU dan memori saat kondisi sehat?
Contoh target baseline:
scenario: login-and-fetch-profile
virtual_users: 50
duration: 5m
expected:
p95_response_time_ms: 300
error_rate_percent: 0.1
Tanpa baseline, sulit menentukan apakah hasil pengujian berikutnya membaik, memburuk, atau hanya berbeda.
2. Load testing
Load testing mensimulasikan trafik puncak yang diperkirakan.
Tujuannya adalah memastikan sistem tetap stabil pada kondisi sibuk yang masih realistis.
Contoh pertanyaan:
- Apakah API checkout tetap di bawah 500 ms pada 1.000 pengguna aktif?
- Apakah error rate tetap mendekati nol saat jam sibuk?
- Apakah database connection pool cukup?
Load testing cocok dijalankan secara berkala, terutama sebelum rilis besar.
3. Stress testing
Stress testing sengaja mendorong sistem melewati kapasitas normal.
Tujuannya bukan membuktikan sistem selalu kuat, tetapi menemukan:
- Titik putus sistem
- Cara sistem gagal
- Komponen yang menjadi bottleneck
- Apakah kegagalan terjadi secara terkendali atau berantai
Kegagalan yang masih bisa diterima:
- Respons menjadi lebih lambat
- Rate limiting aktif
- Sebagian request ditolak dengan error yang jelas
Kegagalan yang berbahaya:
- Data hilang
- Service saling menjatuhkan
- Queue menumpuk tanpa batas
- Database terkunci
4. Spike testing
Spike testing memberikan lonjakan trafik secara tiba-tiba, lalu menurunkannya kembali.
Ini berguna untuk sistem yang bisa mengalami lonjakan, misalnya:
- Flash sale
- Campaign marketing
- Berita viral
- Event streaming
- Pengumuman publik
Sistem yang stabil pada trafik konstan belum tentu siap menghadapi spike, terutama jika autoscaling, cache, atau connection pool tidak cukup cepat menyesuaikan.
5. Capacity testing
Capacity testing mencari batas maksimum sistem sambil tetap memenuhi target performa.
Output yang diharapkan berupa angka konkret, misalnya:
Sistem mampu menangani 2.500 request per detik
dengan p95 response time < 400 ms
dan error rate < 0.5%.
Angka ini bisa dipakai untuk:
- Perencanaan kapasitas
- Konfigurasi autoscaling
- Estimasi biaya infrastruktur
- Keputusan kapan perlu optimasi
6. Soak testing
Soak testing, atau stability testing, menjalankan beban sedang dalam durasi panjang.
Tujuannya menemukan masalah yang tidak terlihat pada pengujian singkat, seperti:
- Memory leak
- Koneksi database tidak ditutup
- Disk penuh karena log
- Queue yang perlahan menumpuk
- Performa menurun setelah beberapa jam
Contoh:
scenario: browse-search-checkout
virtual_users: 300
duration: 8h
expected:
p95_response_time_ms: 500
error_rate_percent: 0.2
Untuk sebagian besar tim, kombinasi awal yang praktis adalah:
- Baseline testing
- Load testing
- Soak testing
Tambahkan stress dan spike testing untuk sistem dengan trafik tinggi atau tidak dapat diprediksi.
Metrik yang menentukan hasil
Pengujian kinerja hanya berguna jika metriknya jelas dan dibaca dengan benar.
Waktu respons
Waktu respons adalah durasi dari request dikirim hingga response diterima.
Jangan hanya membaca rata-rata. Gunakan distribusi:
- p50: pengalaman median
- p90: mayoritas pengguna
- p95: pengguna yang mulai terdampak lambat
- p99: slow tail yang sering menjadi sumber keluhan
Contoh:
average: 180 ms
p95: 420 ms
p99: 2.800 ms
Rata-rata terlihat sehat, tetapi p99 menunjukkan sebagian request sangat lambat.
Throughput
Throughput adalah jumlah pekerjaan yang selesai per unit waktu, biasanya request per second atau RPS.
Rumus sederhana:
throughput = total_request_sukses / durasi_pengujian
Contoh:
120.000 request sukses / 300 detik = 400 RPS
Throughput membantu menentukan kapasitas aktual sistem.
Konkurensi
Konkurensi adalah jumlah pengguna, koneksi, atau request yang berjalan secara bersamaan.
Sistem sering dinilai berdasarkan titik di mana konkurensi membuat performa melewati batas yang dapat diterima.
Contoh:
Pada 500 pengguna virtual:
p95 = 280 ms
error rate = 0.1%
Pada 1.000 pengguna virtual:
p95 = 900 ms
error rate = 2.5%
Dari sini terlihat bahwa kapasitas aman kemungkinan berada di bawah 1.000 pengguna virtual.
Error rate
Error rate adalah persentase request yang gagal.
error_rate = total_request_gagal / total_request * 100
Sistem yang cepat tetapi mulai banyak gagal belum bisa dianggap performant. Kecepatan tanpa reliabilitas tidak cukup.
Pantau error seperti:
- HTTP 5xx
- Timeout
- Connection reset
- Rate limit yang tidak diharapkan
- Error dari dependency eksternal
CPU dan memori
CPU dan memori membantu menjelaskan penyebab perubahan metrik.
Contoh interpretasi:
- Latensi naik dan CPU 100%: kemungkinan compute-bound.
- Latensi naik tetapi CPU rendah: kemungkinan bottleneck di database, lock, network, atau service eksternal.
- Memori terus naik selama soak test: kemungkinan memory leak.
- Garbage collection meningkat: kemungkinan alokasi objek terlalu tinggi.
Hasil pengujian yang baik seharusnya bisa dibaca seperti ini:
Pada 800 pengguna virtual, throughput mencapai 1.200 RPS, p95 response time 350 ms, error rate 0.2%, dan bottleneck utama ada pada database connection pool.
Di mana pengujian kinerja cocok dalam proses
Pengujian kinerja dulu sering dilakukan sekali di akhir proyek. Pola ini tidak cocok untuk sistem yang sering dirilis.
Setiap perubahan bisa menurunkan performa:
- Query baru
- Index yang hilang
- Integrasi eksternal tambahan
- Payload yang membesar
- Perubahan serialisasi
- Validasi yang lebih berat
- N+1 query
Pendekatan yang lebih baik adalah memperlakukan performa seperti correctness: diuji terus-menerus dengan anggaran yang jelas.
Tetapkan performance budget
Contoh performance budget untuk API kritis:
budgets:
login:
p95_response_time_ms: 300
error_rate_percent: 0.1
search:
p95_response_time_ms: 500
error_rate_percent: 0.5
checkout:
p95_response_time_ms: 700
error_rate_percent: 0.1
Budget ini menjadi batas yang dipakai untuk menentukan apakah perubahan masih aman.
Jalankan pengujian ringan di CI/CD
Untuk pull request, jalankan load test kecil agar regresi cepat terdeteksi.
Contoh alur:
1. Deploy branch ke test environment
2. Jalankan test fungsional API
3. Jalankan load test ringan untuk endpoint kritis
4. Bandingkan hasil dengan performance budget
5. Gagalkan build jika p95 atau error rate melewati batas
Pengujian seperti ini bisa dipasang ke pipeline CI/CD.
Pengujian yang lebih berat seperti stress test dan soak test tidak perlu berjalan di setiap commit. Jalankan secara terjadwal, misalnya:
- Setiap malam
- Sebelum release candidate
- Sebelum campaign besar
- Setelah perubahan infrastruktur
Mulai dari lapisan API
Untuk banyak sistem, API adalah titik paling efektif untuk pengujian kinerja karena:
- Menjalankan logika bisnis utama
- Lebih stabil dibanding UI test
- Mudah dipanggil berulang
- Lebih mudah dikontrol datanya
- Cocok untuk skenario multi-step
Pengujian kinerja API memungkinkan tim mengukur kecepatan dan reliabilitas jalur kritis tanpa bergantung pada UI.
Gabungkan dengan pengujian API fungsional agar setiap perubahan diperiksa dari dua sisi:
- Apakah hasilnya benar?
- Apakah hasilnya tetap cepat di bawah beban?
Kesalahan umum dalam pengujian kinerja
Pengujian kinerja mudah menghasilkan angka yang terlihat meyakinkan tetapi salah. Hindari kesalahan berikut.
1. Menguji pada infrastruktur yang tidak realistis
Load test di laptop developer atau staging yang jauh lebih kecil dari production tidak bisa mewakili kondisi nyata.
Idealnya, gunakan environment yang mirip production dalam hal:
- Ukuran instance
- Konfigurasi database
- Network
- Cache
- Queue
- Dependency eksternal
- Jumlah replika
Jika tidak bisa sama persis, dokumentasikan perbedaannya agar hasil tidak salah ditafsirkan.
2. Mengabaikan warm-up
Banyak sistem lebih lambat di awal karena:
- Cache belum terisi
- Connection pool belum stabil
- JIT/runtime belum optimal
- Lazy initialization baru berjalan
Jangan gabungkan cold start dan steady state tanpa pemisahan.
Praktik yang lebih aman:
0-2 menit: warm-up, tidak dihitung
2-10 menit: steady state, dihitung sebagai hasil utama
3. Membaca rata-rata, bukan persentil
Average response time sering menyembunyikan slow tail.
Contoh:
average: 200 ms
p95: 450 ms
p99: 3.000 ms
Jika hanya melihat average, sistem tampak sehat. Jika melihat p99, sebagian pengguna mengalami respons tiga detik.
Gunakan p95 dan p99 untuk endpoint penting.
4. Menggunakan data yang tidak realistis
Jika semua request memakai user ID atau product ID yang sama, database dan cache akan bekerja terlalu ideal.
Trafik nyata biasanya menyebar ke banyak data.
Gunakan variasi data:
user_id,product_id,query
101,9001,laptop
102,8120,keyboard
103,7712,monitor
104,6621,mouse
Pastikan skenario pengujian menyerupai pola akses pengguna nyata.
5. Menguji satu endpoint secara terpisah
Pengguna jarang hanya memanggil satu endpoint. Mereka menjalankan alur:
login → browse → search → add to cart → checkout
Jika hanya menguji satu endpoint, Anda bisa melewatkan bottleneck yang muncul ketika beberapa endpoint bersaing untuk resource yang sama, seperti:
- Database connection pool
- Cache
- Queue
- Lock
- Thread pool
- Service eksternal
Gunakan skenario multi-step untuk alur kritis.
6. Menganggap pengujian sebagai aktivitas sekali jalan
Satu kali pengujian sebelum rilis akan cepat usang. Performa berubah setiap kali sistem berubah.
Jadikan pengujian kinerja bagian dari proses rutin:
- Ringan di CI/CD
- Sedang sebelum rilis
- Berat secara terjadwal
- Wajib sebelum event trafik besar
Menjalankan pengujian kinerja dengan Apidog
Apidog menyediakan pengujian beban di workspace yang sama dengan desain API dan pengujian fungsional. Artinya, skenario API yang sudah dipakai untuk validasi fungsional dapat digunakan kembali untuk pemeriksaan performa.
Alur praktisnya:
1. Pilih endpoint atau skenario pengujian API
2. Pastikan skenario lulus secara fungsional
3. Tentukan jumlah virtual user
4. Tentukan durasi pengujian
5. Jalankan pengujian beban
6. Baca p95, p99, throughput, dan error rate
7. Identifikasi titik konkurensi saat performa mulai turun
Anda juga bisa menggunakan skenario pengujian multi-langkah untuk mensimulasikan alur pengguna yang lebih realistis.
Contoh skenario:
POST /login
GET /products
GET /products/{id}
POST /cart
POST /checkout
Karena skenario yang sama dapat digunakan untuk pengujian fungsional dan performa, tim tidak perlu memelihara dua artefak terpisah.
Untuk beban yang lebih besar dari satu mesin, skenario dapat diekspor ke JMeter sambil mempertahankan definisi yang sama.
Unduh Apidog untuk mulai membuat profil performa endpoint yang sudah Anda miliki.
Checklist implementasi pengujian kinerja
Gunakan checklist ini untuk memulai tanpa membuat proses terlalu berat.
[ ] Tentukan endpoint atau alur bisnis paling kritis
[ ] Buat skenario API multi-step
[ ] Pastikan skenario lulus secara fungsional
[ ] Tetapkan performance budget: p95, p99, throughput, error rate
[ ] Siapkan data uji yang realistis dan bervariasi
[ ] Jalankan baseline test
[ ] Jalankan load test untuk trafik puncak normal
[ ] Pantau CPU, memori, database, cache, dan dependency eksternal
[ ] Simpan hasil sebagai pembanding regresi
[ ] Tambahkan pengujian ringan ke CI/CD
[ ] Jadwalkan stress, spike, atau soak test sesuai kebutuhan
Mulai dari kecil: satu atau dua endpoint kritis sudah cukup untuk menemukan banyak masalah performa awal.
Pertanyaan yang sering diajukan
Apa perbedaan antara pengujian kinerja dan pengujian fungsional?
Pengujian fungsional memastikan perangkat lunak menghasilkan output yang benar. Pengujian kinerja memastikan perangkat lunak tetap cepat dan andal saat menerima beban. Keduanya diperlukan dan tidak saling menggantikan.
Jenis pengujian kinerja apa yang harus dijalankan terlebih dahulu?
Mulai dari baseline testing, lalu load testing. Baseline memberi angka referensi pada kondisi normal. Load testing memastikan sistem bertahan pada trafik puncak yang diharapkan.
Setelah itu, tambahkan stress, spike, atau soak testing sesuai risiko sistem.
Mengapa harus menggunakan persentil, bukan rata-rata?
Rata-rata menyembunyikan slow tail. Persentil seperti p95 dan p99 menunjukkan pengalaman request yang lebih lambat, yang sering kali lebih mencerminkan keluhan pengguna nyata.
Bisakah pengujian kinerja diotomatisasi?
Ya. Load test ringan dapat dijalankan di CI pada setiap perubahan dengan performance budget yang jelas. Jika hasil melewati batas, build dapat digagalkan.
Stress test dan soak test biasanya dijalankan secara terjadwal karena membutuhkan waktu dan resource lebih besar.
Kapan pengujian kinerja harus dimulai?
Mulai lebih awal. Anda mungkin belum bisa mendapatkan angka final tanpa infrastruktur mirip production, tetapi Anda sudah bisa:
- Menentukan performance budget
- Menulis skenario API
- Menyiapkan data uji
- Menjalankan baseline awal setelah endpoint fungsional
Semakin cepat masalah ditemukan, semakin murah perbaikannya.
Siapa yang bertanggung jawab atas pengujian kinerja?
Pada tim modern, tanggung jawabnya dibagi:
- Developer menjalankan pemeriksaan ringan pada perubahan mereka.
- QA menjaga skenario dan budget pengujian.
- Operations atau SRE menyediakan environment mirip production dan metrik sisi server.
Jika pengujian kinerja hanya dianggap tugas satu spesialis, masalah performa lebih mudah lolos ke production.
Berapa lama pengujian kinerja harus berjalan?
Untuk load test, jalankan cukup lama agar melewati warm-up dan mencapai steady state, biasanya beberapa menit.
Untuk soak test, durasinya bisa berjam-jam atau berhari-hari karena tujuannya menemukan degradasi lambat seperti memory leak, resource exhaustion, atau penumpukan queue.
Top comments (0)