Jika API Anda berfungsi dengan baik untuk satu pengguna tetapi tumbang di bawah lalu lintas, Anda memerlukan pengujian beban (load testing), dan k6 adalah salah satu cara paling bersih untuk melakukannya. Panduan ini mencakup apa itu k6, cara menginstalnya, cara menulis skrip pertama Anda, dan cara membaca hasilnya, sehingga Anda dapat memperlakukan pengujian beban sebagai bagian dari rutinitas pengujian kinerja API normal Anda. Kami juga akan melihat bagaimana k6 cocok dengan pengujian fungsional di CI, mengacu pada dokumentasi k6 resmi di mana detailnya penting.
Apa itu k6?
k6 adalah alat pengujian beban sumber terbuka, yang kini dikelola oleh Grafana. Anda menulis pengujian Anda sebagai file JavaScript, k6 menjalankannya dengan mesin Go yang cepat, dan menyerbu endpoint Anda dengan lalu lintas simulasi. Pembagian ini disengaja: Anda membuat pengujian dalam bahasa yang sebagian besar pengembang sudah ketahui, tetapi generator beban itu sendiri berjalan sebagai Go yang dikompilasi, sehingga satu mesin dapat menjalankan banyak pengguna virtual tanpa kesulitan.
k6 dibangun untuk satu pekerjaan dan melakukannya dengan baik: menghasilkan beban yang berkelanjutan, berulang, dan mengukur bagaimana sistem Anda merespons. Ini melaporkan persentil latensi, laju permintaan, laju kesalahan, dan memungkinkan Anda menetapkan aturan lulus/gagal pada angka-angka tersebut. Fokus itulah intinya. k6 bukanlah klien API, alat dokumentasi, atau kerangka kerja pengujian fungsional. Ini adalah mesin beban (load engine).
Beberapa istilah yang akan sering Anda temui:
- Pengguna virtual (VU): pengguna simulasi yang menjalankan skrip Anda dalam sebuah loop. Lebih banyak VU berarti beban bersamaan yang lebih besar.
- Iterasi: satu lintasan penuh melalui fungsi pengujian Anda. Satu VU menjalankan iterasi secara berurutan.
- Tahap (Stage): sebuah langkah dalam profil beban, digunakan untuk meningkatkan atau menurunkan VU seiring waktu.
- Ambang batas (Threshold): aturan lulus/gagal pada sebuah metrik, seperti "latensi persentil ke-95 harus di bawah 500ms."
- Pemeriksaan (Check): sebuah penegasan non-fatal pada respons, seperti "statusnya 200." Pemeriksaan yang gagal akan dihitung, tetapi pengujian tetap berjalan.
Menginstal k6
k6 dikirimkan sebagai satu berkas biner (binary), jadi instalasinya singkat. Di macOS dengan Homebrew:
brew install k6
Di Windows dengan Chocolatey:
choco install k6
Di Debian atau Ubuntu, tambahkan repositori apt Grafana dan instal:
sudo gpg -k
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg \
--keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" \
| sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6
Konfirmasi bahwa itu berfungsi:
k6 version
Citra Docker juga tersedia jika Anda lebih memilih untuk tidak menginstal apa pun secara lokal. Periksa halaman instalasi dalam dokumentasi untuk perintah-perintah terkini, karena detail paket dapat berubah seiring waktu.
Skrip k6 pertama Anda
Pengujian k6 adalah modul JavaScript dengan fungsi default. k6 memanggil fungsi tersebut sekali per iterasi, per VU. Berikut adalah skrip minimal yang mengakses satu endpoint dan memeriksa respons:
import http from 'k6/http';
import { check, sleep } from 'k6';
export default function () {
const res = http.get('https://test-api.example.com/users');
check(res, {
'status is 200': (r) => r.status === 200,
'body is not empty': (r) => r.body.length > 0,
});
sleep(1);
}
Simpan sebagai script.js dan jalankan:
k6 run script.js
Secara default, k6 menjalankan satu VU untuk satu iterasi. `sleep(1)` itu menambahkan jeda satu detik di antara iterasi, yang meniru pengguna sungguhan yang berhenti sejenak di antara tindakan. Tanpa sleep, setiap VU berulang secepat yang diizinkan oleh jaringan, yang berguna untuk pengujian throughput mentah tetapi tidak realistis untuk simulasi perilaku pengguna.
Panggilan `check()` adalah penegasan lunak (soft assertions). Pemeriksaan yang gagal muncul dalam ringkasan tetapi tidak menghentikan jalannya pengujian. Itu disengaja. Di bawah beban berat, Anda mengharapkan beberapa kegagalan, dan Anda ingin pengujian terus mengukur sehingga Anda dapat melihat seberapa buruknya itu.
VU, Tahap, dan Ambang Batas
Skrip pertama menjalankan satu pengguna sekali. Pengujian beban yang sebenarnya adalah tentang mengontrol berapa banyak pengguna yang mengakses API Anda dan berapa lama. Anda mengkonfigurasinya dengan objek `options` yang diekspor.
Bentuk paling sederhana menetapkan jumlah VU tetap dan durasi:
export const options = {
vus: 50,
duration: '30s',
};
Itu menjalankan 50 pengguna virtual selama 30 detik. Yang lebih berguna adalah profil ramping yang dibangun dari beberapa tahap, yang memungkinkan Anda mensimulasikan lalu lintas yang naik, bertahan, dan turun:
export const options = {
stages: [
{ duration: '1m', target: 100 }, // naik ke 100 VU
{ duration: '3m', target: 100 }, // tahan di 100 VU
{ duration: '1m', target: 0 }, // turun ke 0
],
thresholds: {
http_req_duration: ['p(95)<500'], // 95% permintaan di bawah 500ms
http_req_failed: ['rate<0.01'], // kurang dari 1% kesalahan
},
};
Ambang batas (Thresholds) adalah di mana k6 mendapatkan tempatnya di CI. Jika ambang batas gagal, k6 keluar dengan kode non-nol. Itu berarti langkah pipeline dapat menggagalkan build ketika latensi atau tingkat kesalahan melewati batas yang Anda tetapkan. Anda mengkodekan anggaran kinerja sebagai kode, dengan cara yang sama Anda akan mengkodekan penegasan fungsional.
Peta singkat profil beban umum dan pertanyaan yang dijawab oleh masing-masing profil:
| Profil | Tujuan | Apa yang dikatakannya kepada Anda |
|---|---|---|
| Smoke | Beban kecil, verifikasi skrip berjalan | Pengujian itu sendiri benar |
| Load | Lalu lintas normal yang diharapkan | Apakah API bertahan dari hari ke hari |
| Stress | Dorong melewati puncak yang diharapkan | Di mana ia mulai rusak |
| Spike | Lonjakan tajam mendadak pada VU | Bisakah ia bertahan dari lonjakan lalu lintas |
| Soak | Beban moderat selama berjam-jam | Kebocoran memori, degradasi lambat |
Anda tidak memerlukan kelimanya. Mulai dengan smoke dan load. Tambahkan stress dan spike setelah Anda mengetahui angka normal Anda. Untuk survei yang lebih luas tentang pendekatan dan metrik di baliknya, dasar-dasar pengujian kinerja berlaku untuk setiap alat, tidak hanya k6.
Membaca Hasil k6
Ketika sebuah pengujian selesai, k6 mencetak ringkasan ke terminal. Baris-baris yang paling penting:
- http_req_duration: total waktu permintaan, ditampilkan sebagai rata-rata, min, maks, median, p90, dan p95. Persentil p95 dan p99 memberi tahu Anda apa yang sebenarnya dialami oleh pengguna Anda yang paling lambat. Rata-rata menyembunyikan masalah; persentil menampakkannya.
- http_req_failed: proporsi permintaan yang gagal. Perhatikan bagaimana ini bergerak saat VU meningkat.
- http_reqs: total permintaan dan permintaan per detik. Ini adalah throughput Anda.
- iterations: berapa banyak lintasan penuh yang selesai, dan lajunya.
- vus dan vus_max: pengguna virtual aktif dan puncak.
- checks: tingkat kelulusan pada penegasan `check()` Anda.
Bacalah persentil, bukan rata-rata. Waktu respons rata-rata 200ms terdengar baik-baik saja sampai Anda melihat p99 sebesar 4 detik, yang berarti satu dari seratus pengguna menunggu empat detik. Ekor itu adalah tempat pengguna berganti.
Untuk apa pun di luar pengamatan terminal, k6 dapat mengalirkan hasil ke keluaran eksternal. Ini menulis JSON atau CSV, dan berintegrasi dengan dasbor Grafana dan Prometheus untuk analisis visual secara langsung selama pengujian. Pasangan itu, k6 ditambah Grafana, adalah mengapa Anda akan sering melihat alat ini disebut "grafana k6." Untuk pengujian sekali jalan, ringkasan terminal sudah cukup; untuk pemantauan berkelanjutan, kirim metrik ke tempat Anda dapat membuat grafik.
Di mana k6 berperan, dan di mana Apidog berperan
k6 adalah mesin beban. Ini menjawab "bagaimana sistem saya berperilaku di bawah lalu lintas yang berkelanjutan." Ini tidak memeriksa apakah API Anda mengembalikan data yang benar, sesuai kontraknya, atau menangani otentikasi dengan benar di setiap endpoint. Itu adalah pertanyaan pengujian fungsional dan kontrak, dan mereka membutuhkan alat yang berbeda.
Inilah pembagian yang perlu dijaga agar tetap jelas. Anda menginginkan kedua jenis pengujian dalam pipeline Anda, dan keduanya tidak bersaing:
| Perhatian | Terbaik ditangani oleh | Apa yang dijawabnya |
|---|---|---|
| Beban berat berkelanjutan, persentil dalam skala besar | k6 | Apakah tetap cepat di bawah lalu lintas |
| Kebenaran fungsional, kontrak, otentikasi | Apidog | Apakah mengembalikan hal yang benar |
| Regresi di CI pada setiap commit | Apidog (apidog run) |
Apakah perubahan ini merusak endpoint |
| Anggaran kinerja di CI | Ambang batas k6 | Apakah latensi atau kesalahan melewati batas |
Apidog menangani sisi kebenaran. Anda mendesain atau mengimpor API Anda, membangun skenario pengujian dengan penegasan visual, dan menjalankannya di CI dengan apidog run, dengan cara yang sama Anda akan menjalankan skrip k6. Panduan Apidog CLI menjelaskan cara menghubungkan pengujian fungsional tersebut ke dalam sebuah pipeline. Apidog juga menyertakan fitur pengujian kinerja yang lebih ringan untuk pemeriksaan cepat, dibahas dalam panduan pengujian kinerja API di Apidog, tetapi ini bukanlah generator beban kelas k6 dan tidak mencoba untuk menjadi itu.
Alur kerja praktis terlihat seperti ini. Pada setiap commit, Apidog menjalankan pengujian fungsional dan kontrak Anda untuk memastikan API masih melakukan apa yang seharusnya. Berdasarkan jadwal atau sebelum rilis, k6 menjalankan profil beban terhadap lingkungan staging untuk memastikan API tetap cepat di bawah lalu lintas. Gerbang kebenaran dan gerbang kinerja, masing-masing dengan alat yang dibangun untuknya.
Jika Anda membandingkan mesin sebelum berkomitmen, k6 bersanding dengan JMeter, Gatling, dan Locust. Ikhtisar alat pengujian beban dan perbandingan alternatif Locust ini menjelaskan kompromi jika bahasa skrip atau skala mengubah pilihan Anda.
Pertanyaan yang sering diajukan
Apakah k6 gratis?
Ya. k6 adalah sumber terbuka di bawah lisensi AGPL, dan biner tersebut gratis untuk dijalankan secara lokal tanpa batasan pengguna virtual di luar perangkat keras Anda sendiri. Grafana juga menawarkan k6 Cloud, layanan berbayar untuk menjalankan pengujian terdistribusi besar dan menyimpan hasilnya, tetapi Anda tidak pernah harus menggunakannya. Alat inti mencakup sebagian besar tim. Jika Anda ingin meninjau opsi gratis lainnya terlebih dahulu, gambaran umum alat pengujian beban mencantumkan apa yang ditawarkan masing-masing.
Apakah saya perlu tahu JavaScript untuk menggunakan k6?
Anda memerlukan JavaScript dasar, bukan keahlian mendalam. Sebagian besar skrip k6 adalah fungsi default, beberapa panggilan `http.get` atau `http.post`, beberapa pemeriksaan, dan objek opsi. Jika Anda bisa membaca contoh dalam panduan ini, Anda bisa menulis pengujian yang berfungsi. Tidak ada langkah build dan tidak ada kerangka kerja yang perlu dipelajari, hanya API k6.
Apa perbedaan antara k6 dan Apidog untuk pengujian kinerja?
k6 adalah generator beban khusus yang dibangun untuk mendorong lalu lintas berat yang berkelanjutan dan melaporkan persentil dalam skala besar. Apidog adalah platform API yang berfokus pada desain, pengujian fungsional, dan pengujian kontrak, dengan fitur pengujian kinerja yang lebih ringan untuk pemeriksaan cepat. Gunakan k6 saat Anda membutuhkan beban nyata dan anggaran kinerja CI. Gunakan Apidog untuk kebenaran, validasi kontrak, dan menjalankan pengujian fungsional pada setiap commit. Keduanya memecahkan masalah yang berbeda dan bekerja sama dengan baik.
Bisakah saya menjalankan k6 di CI/CD?
Ya, dan ini adalah pengaturan yang umum. k6 keluar dengan kode non-nol ketika ambang batas gagal, sehingga sistem CI apa pun dapat menggagalkan build pada regresi kinerja. Jalankan `k6 run script.js` sebagai langkah pipeline, arahkan ke lingkungan staging, dan tetapkan ambang batas untuk latensi p95 dan tingkat kesalahan. Pasangkan dengan pengujian fungsional dari `apidog run` agar setiap commit mendapatkan pemeriksaan kebenaran dan pemeriksaan beban.
Kesimpulan
k6 memberi Anda cara yang bersih dan dapat diskrip untuk memberikan beban nyata pada API Anda dan mengukur apa yang terjadi. Instal binari, tulis file JavaScript singkat, atur VU dan tahap, tambahkan ambang batas, dan baca persentilnya. Itulah seluruh alurnya. Pisahkan pengujian beban dari pengujian fungsional, karena masing-masing menjawab pertanyaan yang berbeda, dan jalankan keduanya di CI agar tidak ada yang terlewat.
Untuk sisi kebenaran dari pembagian itu, Apidog memungkinkan Anda mendesain, menguji, mem-mock, dan mendokumentasikan API Anda di satu tempat, lalu menjalankan pengujian fungsional di CI dengan `apidog run`. Unduh Apidog untuk menggabungkan kepercayaan tingkat kontrak dengan pengujian beban k6 Anda.