k6 ile yük testi scripti nasıl yazılır?

k6 nedir ve JMeter'dan farkı nedir?

k6, yük testini JavaScript ile kod olarak yazdıran açık kaynaklı bir araçtır. Test bir metin dosyasıdır; grafik arayüzde plan çizmek yerine bir script yazarsınız. Bunun pratik sonuçları var: script sürüm kontrolünde diff ile okunur, kod incelemesine girer, aynı betik bir CI işleminde otomatik koşulur.

Bu araçta her sanal kullanıcı (VU) scriptteki ana fonksiyonu döngü içinde tekrar tekrar çalıştırır. Bu yüzden test mantığını bir kullanıcının tek bir turu gibi yazarsınız: giriş yap, ürünü ara, sepete ekle. Kaç kullanıcının ne kadar süre bu turu döneceği ise seçenekler (options) bölümünde tanımlanır.

JMeter ile temel fark çalışma biçimindedir: JMeter'da plan ağaç yapısında arayüzden kurulur, k6 aracında kod yazılır. Kod yazmaya alışkın geliştiriciler için k6 genellikle daha doğal gelir; arayüzle çalışmayı tercih eden test uzmanları için JMeter alışıktır. Hangisinin daha iyi olduğu değil, ekibin çalışma biçimiyle uyumu belirleyicidir.

İlk script: istek, kontrol ve bekleme

Resmî belgedeki örnek yapıya dayanan temel bir script şöyle görünür:

import http from 'k6/http'; import { check, sleep } from 'k6';

export const options = { vus: 10, duration: '30s', };

export default function () { const res = http.get('https://quickpizza.grafana.com'); check(res, { 'durum 200': (r) => r.status === 200, }); sleep(1); }

Bu script şu işleri yapar. İlk bölümde gerekli modülleri içe aktarır. Seçenekler bölümü eşzamanlı sanal kullanıcı sayısını ve test süresini verir. Varsayılan fonksiyon ise her kullanıcının tekrarlayacağı turdur: bir istek gönderir, yanıtı kontrol eder, kısa bir süre bekler.

Çalıştırmak için komut satırında k6 run script.js yazılır. Seçenekleri script dışından da verebilirsiniz; belge bunun için --vus ve --duration bayraklarını gösterir. Bekleme (sleep) gerçek kullanıcıların düşünme süresini taklit eder; olmazsa her sanal kullanıcı yanıt gelir gelmez yeniden istek atar ve yük gerçek dışı yoğunlaşır.

Check ve threshold: testi geçti ya da kaldı yapmak

k6 aracında doğrulama için kullanılan mekanizmalar vardır ve sık karıştırılır. Check, yanıt üzerinde koşul sınar ve sonucu bir oran metriği olarak kaydeder; ancak resmî belgenin vurguladığı gibi başarısız bir check scripti durdurmaz ve çıkış durumunu başarısız yapmaz. Testi başarısız kılan mekanizma threshold'dur.

Threshold örnekleri belgeden:

export const options = { thresholds: { http_req_failed: ['rate<0.01'], http_req_duration: ['p(95)<200'], }, };

İlk satır hata oranının belirli bir sınırın altında kalmasını, ikincisi isteklerin yüzdelik dilimlerinden birinin belirli süreyi geçmemesini ister. Bu eşikler bozulursa k6 test sonunda başarısız çıkış verir ve CI işlem hattı koşuyu kırmızıya çevirir. Böylece performans testi bir kalite kapısına dönüşür.

Uzun biçimde threshold, abortOnFail ile eşik aşıldığında testi hemen durdurabilir; delayAbortEval ile değerlendirmeyi başlatmadan önce örnek toplanmasına zaman tanıyabilirsiniz. Belge, bulutta eşiklerin belirli aralıklarla değerlendirildiğini ve durdurmanın biraz gecikebileceğini de not eder. Eşik değerlerini keyfi seçmeyin: ürünün hizmet düzeyi hedefinden ya da önceki koşuların taban çizgisinden türetin.

Senaryolar ve executor'lar

Basit vus ve duration ayarı çoğu zaman gerçek trafiği temsil etmez. Senaryolar (scenarios), farklı iş yüklerini aynı script içinde ayrı ayrı tanımlamanızı sağlar; her senaryo kendi fonksiyonunu, ortam değişkenlerini ve etiketlerini taşıyabilir, belirli başlangıç gecikmesi verilmedikçe paralel çalışır. Senaryo adları script içinde benzersiz olmalıdır ve belirli bir senaryoyu tek başına koşmak için komut satırında senaryo adı verilir.

Resmî belgede şu executor'lar listelenir: • shared-iterations: toplam yineleme sayısını sanal kullanıcılar arasında paylaştırır • per-vu-iterations: her kullanıcı kendi yineleme sayısını koşar • constant-vus: sabit sayıda kullanıcıyı belirli süre çalıştırır • ramping-vus: kullanıcı sayısını aşamalara göre artırıp azaltır • constant-arrival-rate: iterasyonları sabit bir hızda başlatır • ramping-arrival-rate: iterasyon başlatma hızını aşamalara göre değiştirir

Kullanıcı sayısına dayalı executor'larda sistem yavaşladıkça saniyedeki istek sayısı da düşer. Varış hızına dayalı executor'larda ise sistem yavaş olsa bile yeni işler aynı hızda gelmeye devam eder; bu, kuyruk oluşan gerçek dünya trafiğine daha yakındır. Hangi modelin uygun olduğu, ürününüzün kullanıcı sayısını mı yoksa istek hızını mı sınırladığına bağlıdır.

Yerleşik metrikleri okumak

k6 her koşuda yerleşik metrikler üretir. HTTP için en önemlileri şunlardır: • http_reqs: gönderilen toplam istek sayısı • http_req_duration: gönderme, bekleme ve almanın toplamı; DNS çözümleme ve bağlantı kurma süresini içermez • http_req_failed: başarısız isteklerin oranı • http_req_waiting: sunucudan yanıtın gelmesini bekleme süresi, yani ilk baytın gelme süresi • http_req_blocked: boş bir bağlantı yuvası için bekleme • http_req_connecting: sunucuyla bağlantı kurma süresi • vus ve iterations: etkin kullanıcı sayısı ve tamamlanan tur sayısı • checks: başarılı kontrol oranı

Yorumlarken önce toplam süreyi bölerek bakın. Bekleme süresi uzunsa sunucu tarafı yavaştır; bağlantı ya da bloke süresi uzunsa ağ ya da bağlantı havuzu sorunu aranır. Bütün isteklerin ortalamasına bakmayın; yüzdelik dilimler ve yavaş uç noktalar daha fazla bilgi verir. Etiketler sayesinde her uç noktanın metriğini ayrı filtreleyebilirsiniz.

Sık yapılan hatalar

En yaygın hata, check yazıp threshold koymamaktır. Check başarısız olsa bile test başarılı görünür; işlem hattında performans kalite kapısı çalışmaz. İkinci hata, sleep koymadan koşmaktır; bu, sunucuya hiçbir kullanıcının üretemeyeceği hızda istek yağdırır.

Diğer tuzaklar: • Her sanal kullanıcıda aynı hesapla giriş yapmak: gerçek davranışı yansıtmaz • Test verisini script içine gömmek: veriyi dosyadan ya da hazırlık fonksiyonundan paylaşmak daha sürdürülebilirdir • Yük üretici makineyi izlememek: işlemci doluysa ölçülen yavaşlık yük üreticisinden gelir • Eşik değerini ölçümsüz belirlemek • Yalnız tek istek uç noktası sınamak: gerçek kullanım karışımını senaryolarla modelleyin • Üretim sistemine ilgili ekiplere haber vermeden yük uygulamak

Script'i küçük tutup önce az sayıda kullanıcıyla doğrulamak, sonra yükü artırmak hataları erken yakalar.

Mindset programlarında bu beceriyi nerede çalışırsınız?

Mindset kataloğundaki Performance Testing (JMeter, k6) programı, performans mühendisleri, test otomasyon uzmanları ve kapasiteden sorumlu geliştirme ekipleri için tasarlanmıştır. Program performans testi kavramlarından başlar; Apache JMeter ile test tasarımı ve gelişmiş özellikler modüllerinin ardından k6 ile modern performans testi modülüne geçer, sonuç analizi ve darboğaz tespiti ile performans raporu ve kapasite planlaması modülleriyle tamamlanır.

Kurumsal ekipler için uygulanabilir yanı, performans testini işlem hattının bir parçası olarak ele almasıdır: kod olarak yazılan test, geliştirme ekibinin sürüm sürecine eklenebilir. Gatling ile benzer yaklaşım isteyenler için Yük ve Stres Testi (Gatling) programı tamamlayıcıdır.