JMeter'da test planı nasıl kurulur ve koşulur?

JMeter nedir, hangi işe yarar?

Apache JMeter, bir uygulamaya aynı anda çok sayıda sanal kullanıcı gibi istek göndererek yanıt davranışını ölçen açık kaynaklı bir performans test aracıdır. En çok web uygulamaları ve HTTP tabanlı servisler için kullanılır. Test, bir .jmx dosyasında saklanan test planı olarak tanımlanır; plan bir ağaç yapısındadır ve elemanlar ağaçtaki yerlerine göre birbirini etkiler.

JMeter'ın güçlü yanı, tarayıcı açmadan protokol düzeyinde yük üretebilmesidir. Bu, aynı makineden çok sayıda kullanıcıyı simüle etmeyi mümkün kılar ama tarayıcıdaki sayfa çizim süresini ölçmez. Kod yazmadan arayüzden plan kurulabildiği için test uzmanı olmayan ekip üyeleri de başlayabilir. Plan sürüm kontrolüne eklenebilir, ancak .jmx dosyası XML olduğu için farkları okumak zordur; bu yüzden değişiklikleri küçük ve açıklamalı yapmak gerekir.

Çalışması için bilgisayarda Java bulunması gerekir; resmî belge JDK kullanılmasını önerir, çünkü HTTPS kaydı için JDK ile gelen anahtar aracı lazımdır.

Adım adım ilk test planı

Resmî kullanım kılavuzundaki web test planı akışı şu sıradadır: • Test Plan üzerinde sağ tıklayıp bir Thread Group ekleyin ve anlamlı bir ad verin • Thread Group içinde Number of Threads (sanal kullanıcı sayısı), Ramp-Up Period (kullanıcıların kaç saniyede devreye gireceği) ve Loop Count (her kullanıcının planı kaç kez tekrarlayacağı) alanlarını doldurun; Forever kutusu planı sınırsız tekrarlar • Thread Group altına HTTP Request Defaults ekleyin ve sunucu adını bir kez girin; bu eleman istek göndermez, yalnızca varsayılan değerleri sağlar • HTTP Cookie Manager ekleyin; kılavuza göre neredeyse tüm web testlerinde kullanılmalıdır • Sampler altından HTTP Request ekleyip her istek için yolu girin; JMeter istekleri ağaçtaki sırayla gönderir • Sonuçları görmek için bir Listener ekleyin

Ramp-up mantığı önemlidir. Kullanıcı sayısını ramp-up süresine bölerek her saniye kaç kullanıcının başladığını bulursunuz; kılavuz örneği, kullanıcı sayısı ile ramp-up süresi eşitse saniyede bir kullanıcı başladığını söyler. Değer sıfır olursa tüm kullanıcılar aynı anda başlar. Gerçekçi bir senaryoda yükü yavaş artırmak, sistemin hangi noktada bozulduğunu görmeyi kolaylaştırır.

Giriş gerektiren senaryoda bir HTTP Request ekleyip yöntemi POST yapın, formun gönderildiği yolu girin, kullanıcı adı, parola ve varsa gizli form alanlarını parametre olarak ekleyin. Kılavuz uyarısı: oturum çerezi yönetimi için Cookie Manager mutlaka planda olmalıdır.

Doğrulama, bekleme süresi ve değişken test verisi

İlk plan çalışınca sorunlar görünür. Birincisi, sunucu hata sayfası dönse bile JMeter varsayılan olarak yanıtı alınmış sayabilir; yanıtın beklenen metni ya da durum kodunu taşıdığını doğrulayan bir doğrulama (assertion) elemanı eklemeden başarılı sonucun anlamı yoktur. İkincisi, gerçek kullanıcılar istekler arasında düşünür; bekleme (timer) elemanı olmayan plan, gerçekçi olmayan yoğunlukta yük üretir ve sunucuyu olduğundan kötü gösterir.

Üçüncü konu test verisidir. Her sanal kullanıcı aynı hesapla giriş yaparsa önbellek ve oturum davranışı gerçeği yansıtmaz. Çözüm, kullanıcı bilgilerini bir CSV dosyasında tutup JMeter'ın CSV okuyucu elemanıyla her kullanıcıya farklı satır vermektir. Dinamik değerler için bir önceki yanıttan veri çekmek gerekir: oturum kimliği, ürün numarası ya da sepet kodu gibi değerler yanıttan düzenli ifade ya da JSON yolu ile çıkarılır ve sonraki isteklerde değişken olarak kullanılır.

Çok adımlı iş akışlarını (ürün arama, sepete ekleme, ödeme) bir işlem denetleyicisi içinde gruplamak, adım adım yerine bütün akışın yanıt süresini tek satırda görmeyi sağlar. Hangi yöntemin hangi eleman adıyla yapıldığı sürüme göre arayüzde küçük farklarla görünebilir; menüdeki adı için kendi sürümünüzün belgesine bakın.

Testi arayüzden değil komut satırından koşun

Resmî belge, arayüz modunun yalnızca test betiği hazırlamak için kullanılmasını, yük testinin ise komut satırı modunda koşulmasını söyler. Arayüz, ölçülen sistemden kaynak çalar ve sonuçları bozar. Komut satırı modu şu seçeneklerle çalışır: • -n arayüzsüz modu açar • -t koşulacak .jmx test planı dosyasını verir • -l her örneğin sonucunu yazacağı .jtl dosyasını belirtir • -j JMeter'ın kendi çalışma günlüğü dosyasını belirtir • -e test bitince HTML rapor panosu üretir • -o rapor klasörünü belirtir; klasör yok olmalı ya da boş olmalıdır

Örnek bir komut:

jmeter -n -t plan.jmx -l sonuc.jtl -e -o rapor

Her koşuda sonuç dosyası ve rapor klasörünü farklı adla saklamak, koşular arası karşılaştırmayı kolaylaştırır. Yük üretici makinenin kendisi de darboğaz olabilir: işlemci ya da bellek doluyorsa ölçülen yavaşlık sistemden değil, yük üreticisinden gelir. Büyük yüklerde birden çok yük makinesi kullanılır; bu durumda ağın ve zaman ayarlarının aynı olduğundan emin olun.

Sonuçları okumanın ilk adımları

HTML rapor panosu yanıt sürelerini, istek hatalarını ve zaman içindeki eğilimi gösterir. İlk bakışta şu sorulara cevap arayın: hata oranı yüke göre ne zaman artmaya başlıyor, ortalama yanıt süresi ile üst yüzdelik dilim arasındaki fark ne kadar açılıyor, hangi istek diğerlerinden belirgin yavaş?

Ortalama yanıt süresi tek başına yanıltıcıdır. Çok hızlı çoğunluk ve çok yavaş birkaç istek ortalamayı normal gösterebilir; bu yüzden yüzdelik dilimler ve en yavaş istek listesi birlikte okunmalıdır. Test sırasında hataların türünü ayırın: bağlantı zaman aşımı sunucu kapasitesini, uygulama hatası kod ya da veritabanı sorununu gösterebilir.

Bulduğunuz yavaşlığın nedenini sunucu izleme verisiyle eşleştirmeden sonuca varmayın. İşlemci, bellek, veritabanı bağlantı havuzu ve ağ aynı zaman aralığında incelenmelidir. Darboğaz yorumlama yöntemi ayrı bir konudur; bu adımın ayrıntısı için performans testi sonuç analizi sayfasına bakın.

Sık yapılan hatalar

Yük testinde en sık görülen hata, tek bir uç noktaya yük bindirip bunu tüm sistemin kapasitesi sanmaktır. Gerçek kullanıcı karışımı arama, listeleme ve ödemeyi farklı oranlarda içerir; plan bu karışımı yansıtmalıdır. Bir diğer hata, test ortamının üretimden çok farklı olmasıdır: veritabanı büyüklüğü, önbellek ve ağ yapısı ölçüm değerini değiştirir.

Diğer tipik hatalar: • Doğrulama koymadan hata sayfalarını başarılı saymak • Bekleme süresi olmadan gerçek dışı yoğunlukta yük üretmek • Arayüz modunda yük testi koşmak • Test verisini tüm kullanıcılara aynı vermek • Isınma süresini hesaba katmamak: ilk dakikalardaki önbellek ve havuz kurulumu ölçümü bozar • Sonucu yalnız ortalamayla raporlamak • Canlı sistemde ilgili ekipleri haberdar etmeden yük uygulamak

Bir koşuda tek değişken değiştirmek, değişikliğin etkisini ayırt etmenizi sağlar. Hem plan hem sunucu ayarı aynı anda değişirse, sonucu neyin etkilediği belli olmaz.

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 sistem kapasitesinden sorumlu geliştirme ekipleri için tasarlanmıştır. Program performans testi kavramları ve test türleriyle başlar, Apache JMeter ile test tasarımı ve JMeter gelişmiş özellikler modülleriyle devam eder, ardından k6 ile modern performans testi, sonuç analizi ve darboğaz tespiti ile performans raporu ve kapasite planlaması modüllerini işler.

Kurumsal ekipler için uygulanabilir yanı, JMeter planını bir ekip pratiği olarak ele almasıdır: aynı senaryo, aynı rapor biçimi ve aynı kapasite sorularıyla çalışmak test sonuçlarının birimler arasında karşılaştırılabilir olmasını sağlar.