API'niz tek bir kullanıcı için sorunsuz çalışıyor ama yoğun trafik altında yavaşlıyor veya çöküyorsa, yük testi eklemeniz gerekir. k6, bunu hızlıca betikleyebileceğiniz temiz araçlardan biridir: JavaScript ile senaryo yazarsınız, k6 bunu Go tabanlı motoruyla çalıştırır ve API'nize kontrollü trafik üretir. Bu rehberde k6 kurulumu, ilk test betiği, VU/stage/threshold kullanımı, sonuç okuma ve k6'yı normal API performans testi akışınıza nasıl ekleyeceğiniz yer alıyor. Detaylı seçenekler için resmi k6 belgeleri iyi bir referanstır.
k6 Nedir?
k6, Grafana tarafından sürdürülen açık kaynaklı bir yük testi aracıdır. Test senaryolarını JavaScript dosyası olarak yazarsınız; k6 ise bu senaryoları yüksek performanslı bir Go motoruyla çalıştırır.
Temel fikir basittir:
- API uç noktalarınızı çağıran bir JavaScript betiği yazarsınız.
- Kaç sanal kullanıcıyla çalışacağını belirlersiniz.
- k6, bu kullanıcıları simüle ederek API'nize trafik gönderir.
- Gecikme, hata oranı, istek sayısı ve yüzdelik değerleri raporlar.
- Threshold tanımlarsanız test geçer veya başarısız olur.
k6'nın odağı nettir: sürekli, tekrarlanabilir yük üretmek ve sisteminizin trafik altında nasıl davrandığını ölçmek. Bir API istemcisi, dokümantasyon aracı veya tam kapsamlı fonksiyonel test platformu değildir. Bu nedenle k6'yı genellikle fonksiyonel/sözleşme test araçlarıyla birlikte kullanırsınız.
k6 kullanırken sık göreceğiniz kavramlar:
- Sanal kullanıcı (VU): Betiğinizi döngü içinde çalıştıran simüle edilmiş kullanıcıdır.
- İterasyon: Bir VU'nun test fonksiyonunu bir kez tamamlamasıdır.
- Aşama (Stage): VU sayısını zaman içinde artırmak, sabit tutmak veya azaltmak için kullanılan adımdır.
-
Eşik (Threshold): Metrik bazlı geçme/kalma kuralıdır. Örneğin:
p(95)<500. - Kontrol (Check): Yanıt üzerinde yapılan yumuşak doğrulamadır. Örneğin: status code 200 mü?
k6 Kurulumu
k6 tek bir binary olarak çalışır. Kurulum kısa sürer.
macOS için Homebrew:
brew install k6
Windows için Chocolatey:
choco install k6
Debian veya Ubuntu için Grafana apt deposunu ekleyip kurun:
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
Kurulumu doğrulayın:
k6 version
Yerel kurulum istemiyorsanız Docker imajı da kullanabilirsiniz. Paket komutları zamanla değişebileceği için güncel kurulum adımlarını k6 dokümantasyonundan kontrol edin.
İlk k6 Betiğiniz
Bir k6 testi, varsayılan bir fonksiyona sahip JavaScript modülüdür. k6, bu fonksiyonu her VU ve her iterasyon için çalıştırır.
Aşağıdaki örnek bir API uç noktasına GET isteği gönderir, yanıtı kontrol eder ve kullanıcı davranışını taklit etmek için kısa bir bekleme ekler:
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);
}
Dosyayı script.js olarak kaydedin ve çalıştırın:
k6 run script.js
Varsayılan çalıştırmada k6, tek bir VU ile tek iterasyon yapar. Bu, betiğin doğru çalıştığını görmek için yeterlidir ama gerçek yük testi değildir.
Buradaki önemli parçalar:
-
http.get()API'ye istek gönderir. -
check()yanıtı doğrular ama test akışını durdurmaz. -
sleep(1)her iterasyon arasında 1 saniye bekler.
sleep() kullanmazsanız her VU mümkün olan en yüksek hızda istek gönderir. Bu ham throughput testi için faydalı olabilir, ancak gerçek kullanıcı davranışını simüle etmek istiyorsanız bekleme süreleri eklemek daha gerçekçidir.
VU, Stage ve Threshold Kullanımı
Tek kullanıcıyla bir kez test etmek sadece başlangıçtır. Gerçek yük testi için kaç kullanıcının, ne kadar süreyle ve hangi trafik profiliyle çalışacağını tanımlamanız gerekir.
Bunu options nesnesiyle yaparsınız.
Sabit VU ve süre örneği:
export const options = {
vus: 50,
duration: '30s',
};
Bu yapılandırma 50 sanal kullanıcıyı 30 saniye çalıştırır.
Daha gerçekçi bir profil için stage kullanın:
export const options = {
stages: [
{ duration: '1m', target: 100 }, // 1 dakikada 100 VU'ya çık
{ duration: '3m', target: 100 }, // 3 dakika 100 VU'da kal
{ duration: '1m', target: 0 }, // 1 dakikada 0 VU'ya düş
],
thresholds: {
http_req_duration: ['p(95)<500'], // isteklerin %95'i 500ms altında olmalı
http_req_failed: ['rate<0.01'], // hata oranı %1'den düşük olmalı
},
};
Tam betik şöyle görünür:
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '1m', target: 100 },
{ duration: '3m', target: 100 },
{ duration: '1m', target: 0 },
],
thresholds: {
http_req_duration: ['p(95)<500'],
http_req_failed: ['rate<0.01'],
},
};
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);
}
Çalıştırın:
k6 run script.js
Threshold'lar CI/CD için özellikle önemlidir. Bir threshold başarısız olursa k6 sıfırdan farklı exit code ile çıkar. Böylece gecikme veya hata oranı belirlediğiniz limiti aşarsa pipeline başarısız olur.
Yaygın yük profilleri:
| Profil | Amaç | Size neyi söyler |
|---|---|---|
| Duman (Smoke) | Çok küçük yükle betiği doğrulamak | Test senaryosu doğru çalışıyor mu |
| Yük (Load) | Beklenen normal trafik | API günlük trafik altında stabil mi |
| Stres (Stress) | Beklenen zirvenin üstüne çıkmak | Sistem nerede bozulmaya başlıyor |
| Sıçrama (Spike) | VU sayısını aniden artırmak | API ani trafik artışını kaldırabiliyor mu |
| Islatma (Soak) | Saatlerce orta düzey yük | Bellek sızıntısı veya yavaş bozulma var mı |
Başlangıç için hepsini çalıştırmanız gerekmez. Önce smoke ve load testi ekleyin. Normal gecikme ve hata oranlarınızı öğrendikten sonra stress, spike ve soak senaryolarını genişletebilirsiniz.
Daha geniş performans testi yaklaşımı için performans testi temelleri k6 dışında da geçerli kavramları açıklar.
k6 Sonuçlarını Okuma
Test bittiğinde k6 terminale özet metrikler yazar. En çok dikkat etmeniz gerekenler:
-
http_req_duration: İstek süresi. Ortalama, min, max, medyan, p90 ve p95 değerlerini gösterir. -
http_req_failed: Başarısız istek oranı. -
http_reqs: Toplam istek sayısı ve saniyedeki istek oranı. -
iterations: Tamamlanan iterasyon sayısı. -
vus/vus_max: Aktif ve maksimum sanal kullanıcı sayısı. -
checks:check()doğrulamalarının başarı oranı.
Ortalama değere fazla güvenmeyin. Yüzdelik değerleri okuyun.
Örneğin ortalama yanıt süresi 200ms olabilir, ancak p99 değeri 4 saniyeyse kullanıcıların bir bölümü ciddi gecikme yaşıyor demektir. Performans problemleri genellikle ortalamada değil, kuyrukta görünür.
Basit yorumlama akışı:
- Önce
http_req_faileddeğerine bakın. - Hata oranı yüksekse log ve backend metriklerine geçin.
- Hata oranı düşük ama p95/p99 yüksekse darboğaz büyük olasılıkla latency tarafındadır.
- VU arttıkça p95'in nasıl değiştiğini izleyin.
- Threshold başarısızsa limiti mi yoksa sistemi mi değiştirmeniz gerektiğini değerlendirin.
Tek seferlik testler için terminal çıktısı yeterlidir. Sürekli analiz için k6 sonuçlarını JSON veya CSV olarak dışa aktarabilir, Grafana panoları ve Prometheus ile görselleştirebilirsiniz. k6 ve Grafana'nın birlikte sık kullanılmasının nedeni budur.
k6 Nereye, Apidog Nereye Uyar?
k6 şu soruya cevap verir:
Sistemim sürekli trafik altında nasıl davranıyor?
Ancak şu sorular için tasarlanmamıştır:
- API doğru veriyi döndürüyor mu?
- Endpoint sözleşmeye uyuyor mu?
- Auth akışları doğru çalışıyor mu?
- Her commit bir fonksiyonel regresyon oluşturdu mu?
Bu sorular fonksiyonel ve sözleşme testi kapsamındadır.
Pratik ayrım:
| İlgili Konu | En iyi şekilde tarafından ele alınır | Neyi yanıtlar |
|---|---|---|
| Sürekli ağır yük, ölçekli yüzdelikler | k6 | Trafik altında hızlı kalır mı |
| Fonksiyonel doğruluk, sözleşme, kimlik doğrulama | Apidog | Doğru şeyi döndürüyor mu |
| Her commit'te CI'da regresyon | Apidog (apidog run) |
Bu değişiklik bir uç noktayı bozdu mu |
| CI'da performans bütçeleri | k6 eşikleri | Gecikme veya hatalar bir sınırı aştı mı |
Apidog doğruluk tarafında konumlanır. API'nizi tasarlar veya içe aktarırsınız, görsel doğrulamalarla test senaryoları oluşturursunuz ve apidog run ile bunları CI'da çalıştırırsınız.
Apidog CLI kılavuzu, fonksiyonel testleri pipeline'a bağlama adımlarını gösterir. Apidog ayrıca hızlı kontroller için daha hafif performans testi özellikleri de içerir; bu konu Apidog'da API performans testi rehberinde ele alınır. Ancak Apidog, k6 sınıfı özel bir yük üreteci değildir ve bu rolü üstlenmeye çalışmaz.
Uygulanabilir bir akış şöyle olabilir:
- Her commit'te Apidog fonksiyonel ve sözleşme testlerini çalıştırır.
- API'nin doğru yanıt verip vermediği doğrulanır.
- Release öncesi veya zamanlanmış olarak k6 load testi çalıştırılır.
- k6, staging ortamında p95 latency ve hata oranı threshold'larını kontrol eder.
- Fonksiyonel veya performans kapılarından biri başarısızsa pipeline durur.
Araç karşılaştırması yapıyorsanız k6, JMeter, Gatling ve Locust ile aynı kategoridedir. Yük testi araçları özeti ve Locust alternatifi karşılaştırması, seçim yaparken bakmanız gereken farkları açıklar.
CI/CD'de k6 Çalıştırma
k6'yı pipeline'a eklemek için en basit adım şudur:
k6 run script.js
Threshold kullanıyorsanız, başarısızlık durumunda k6 non-zero exit code döndürür. Bu da GitHub Actions, GitLab CI, Jenkins veya benzeri sistemlerde job'ın başarısız olmasını sağlar.
Basit GitHub Actions örneği:
name: load-test
on:
workflow_dispatch:
jobs:
k6:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install k6
run: |
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
- name: Run k6 test
run: k6 run script.js
Load testleri genellikle her commit'te değil, kontrollü şekilde çalıştırılır. Örneğin:
- manuel tetikleme,
- nightly pipeline,
- release öncesi pipeline,
- staging ortamına deploy sonrası smoke + load kontrolü.
Her commit'te ağır yük testi çalıştırmak hem pahalı hem de gürültülü olabilir. Bunun yerine her commit'te fonksiyonel testleri, belirli aralıklarla veya release öncesinde k6 testlerini çalıştırmak daha pratik bir modeldir.
Sıkça Sorulan Sorular
k6 ücretsiz mi?
Evet. k6, AGPL lisansı altında açık kaynaklıdır ve kendi altyapınızda ücretsiz çalıştırılabilir. Yerel kullanımda sanal kullanıcı limiti aracın kendisinden değil, çalıştırdığınız makinenin kapasitesinden gelir. Grafana ayrıca büyük dağıtık testler ve sonuç saklama için k6 Cloud hizmeti sunar, ancak temel k6 kullanımı için buna ihtiyacınız yoktur.
Alternatifleri görmek isterseniz yük testi araçları genel bakışı farklı seçenekleri karşılaştırır.
k6 kullanmak için JavaScript bilmem gerekiyor mu?
Temel JavaScript bilgisi yeterlidir. Çoğu k6 betiği şu parçalardan oluşur:
-
http.get()veyahttp.post()çağrıları, - birkaç
check(), - bir
optionsnesnesi, - isteğe bağlı
sleep()çağrıları.
Derleme adımı veya karmaşık framework kurulumu gerekmez.
Performans testi için k6 ve Apidog arasındaki fark nedir?
k6, sürekli yoğun trafik üretmek ve latency/hata oranı gibi metrikleri ölçmek için özel bir yük test aracıdır. Apidog ise API tasarımı, fonksiyonel test, sözleşme doğrulama ve CI'da doğruluk kontrolleri için kullanılır. Gerçekçi yük profilleri ve performans bütçeleri için k6; doğruluk, sözleşme ve regresyon testleri için Apidog kullanın.
k6'yı CI/CD'de çalıştırabilir miyim?
Evet. Threshold başarısız olduğunda k6 sıfırdan farklı exit code döndürür. Bu sayede CI/CD sistemi performans regresyonunda job'ı başarısız yapabilir. Tipik kullanım:
k6 run script.js
Bunu staging ortamına yönlendirin, p95 latency ve hata oranı threshold'ları belirleyin, fonksiyonel doğruluk tarafında da apidog run ile testleri çalıştırın.
Sonuç
k6, API'nize kontrollü yük bindirmek ve sonuçları ölçmek için temiz, betiklenebilir bir yol sunar. Başlamak için yapmanız gerekenler:
- k6'yı kurun.
- Küçük bir JavaScript test dosyası yazın.
- VU, stage ve duration değerlerini belirleyin.
-
check()ile temel yanıt doğrulamaları ekleyin. - Threshold tanımlayın.
- p95/p99 ve hata oranlarını okuyun.
- Testi CI/CD akışınıza kontrollü şekilde ekleyin.
Yük testi ile fonksiyonel testi ayrı tutun. k6 trafik altında davranışı ölçer; Apidog ise API'nizin doğru çalıştığını doğrulamanıza, test etmenize, mock oluşturmanıza, dokümante etmenize ve apidog run ile CI'da fonksiyonel testler çalıştırmanıza yardımcı olur. En sağlıklı akış, sözleşme düzeyindeki güveni Apidog ile, yük altındaki davranışı ise k6 ile doğrulamaktır.

Top comments (0)