Postman ve JMeter Arasındaki Farklar

İnsanlar genellikle Postman ve JMeter'ı rakip gibi karşılaştırır. Bu doğru bir model değil: Postman, API'nin doğru yanıt verip vermediğini doğrular; JMeter ise API'nin yük altında ayakta kalıp kalmadığını ölçer. Kısaca Postman “bu endpoint doğru veriyi döndürüyor mu?”, JMeter ise “2.000 kullanıcı aynı anda istek gönderirse sistem ne olur?” sorusuna cevap verir.

Apidog'u bugün deneyin

Bu ayrımı yanlış yapmak üretim hatalarına yol açar. Bir ekip Postman koleksiyonundaki tüm testleri yeşil görüp API'yi üretime hazır sanabilir; ancak eşzamanlı kullanıcı altında yanıt süresini hiç ölçmemiş olabilir. Tersi de geçerlidir: JMeter ile yük testi yapmak, bozuk bir JSON alanını otomatik olarak yakalayacağınız anlamına gelmez. Bu yazı, hangi durumda hangi aracı kullanmanız gerektiğini pratik olarak netleştirir.

Postman ne için kullanılır?

Postman bir API istemcisi ve işbirliği platformudur. İstek oluşturur, koleksiyonlara ayırır, ortam değişkenleri tanımlar ve her yanıt sonrasında çalışan JavaScript testleri yazarsınız.

Postman'ın ana kullanım alanı işlevsel API testidir:

• HTTP durum kodunu doğrulama
• Yanıt gövdesindeki alanları kontrol etme
• Header doğrulama
• JSON şema veya sözleşme kontrolü
• Regresyon testlerini CI içinde çalıştırma

Örnek bir Postman test betiği:

pm.test("Status is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response has a user id", function () {
    const body = pm.response.json();

    pm.expect(body).to.have.property("id");
    pm.expect(body.id).to.be.a("number");
});

Bu test şunu doğrular:

1. Endpoint 200 OK dönüyor mu?
2. Yanıt içinde id alanı var mı?
3. id sayısal mı?

Bu, tek istekli ve doğrulama odaklı bir testtir. Collection Runner aynı koleksiyonu veri dosyalarıyla döngüye alabilir. Postman CLI veya Newman ile bu koleksiyonları CI/CD hattında çalıştırabilirsiniz. Ancak temel amaç değişmez: API'nin beklenen davranışı üretip üretmediğini kontrol etmek.

API yanıtlarını daha sistematik doğrulamak için API doğrulamaları rehberine de bakabilirsiniz.

Postman özellikle şu aşamalarda kullanışlıdır:

• Yeni endpoint geliştirirken hızlı deneme yapmak
• Pull request başına regresyon testi çalıştırmak
• API sözleşmesini doğrulamak
• QA ve backend ekiplerinin ortak koleksiyon kullanmasını sağlamak
• API dokümantasyonu ve örnek yanıtları yönetmek

Ancak Postman'ın asıl hedefi performans ölçümü değildir.

JMeter ne için kullanılır?

Apache JMeter yük ve performans testi aracıdır. Bir Thread Group tanımlarsınız; bu grup simüle edilmiş kullanıcıları temsil eder. Ardından şu parametreleri ayarlarsınız:

• Kaç sanal kullanıcı çalışacak?
• Kullanıcılar ne kadar sürede artacak?
• Test kaç kez dönecek?
• Hangi endpoint'lere istek gönderilecek?
• Yanıt süreleri, hata oranları ve throughput nasıl ölçülecek?

JMeter'ın cevapladığı sorular şunlardır:

• 500 kullanıcı aktifken 95. yüzdelik dilim yanıt süresi nedir?
• Hata oranı hangi istek hızında %1'i geçiyor?
• 300 eşzamanlı oturumda veritabanı bağlantı havuzu darboğaz oluyor mu?
• Sistem saatlerce süren trafik altında bellek sızdırıyor mu?

Bunlar tek tek istek gönderen bir araçla güvenilir şekilde ölçülemez.

JMeter yalnızca HTTP için kullanılmaz. Şunları da test edebilir:

• JDBC veritabanı sorguları
• JMS mesajlaşma
• FTP
• SMTP
• TCP
• HTTP/HTTPS servisleri

Bu nedenle JMeter, tek bir REST endpoint'inden çok daha geniş sistem yüklerini modellemek için kullanılır.

Performans testi metriklerine yeni başlıyorsanız, performans testi genel bakışı temel kavramları açıklar.

Postman ve JMeter karşılaştırması

Yön	Postman	JMeter
Birincil amaç	İşlevsel ve entegrasyon API testi	Yük, stres ve performans testi
Temel soru	Yanıt doğru mu?	API yük altında dayanıyor mu?
Eşzamanlılık modeli	Tek seferde bir istek; Runner sıralı döngü yapar	Paralel çalışan çok sayıda sanal kullanıcı
Protokoller	HTTP, HTTPS, GraphQL, WebSocket, gRPC	HTTP, JDBC, JMS, FTP, SMTP, TCP ve daha fazlası
Betikleme	JavaScript test betikleri	Groovy, BeanShell, Java örnekleyicileri
Çıktı	İstek başına başarılı/başarısız doğrulamalar	Gecikme yüzdelikleri, throughput, hata oranı
Öğrenme eğrisi	Başlangıç dostu	Daha dik; performans mühendisliğine daha yakın
En uygun aşama	Geliştirme, entegrasyon, regresyon	Yayın öncesi kapasite ve stres doğrulama
Raporlama	Test sonuçları, Postman CLI çıktıları	HTML raporları, grafikler, yüzdelikler

En kritik fark eşzamanlılık modelidir. Postman Collection Runner döngü yapar, ancak yüzlerce veya binlerce kullanıcının aynı anda endpoint'e istek göndermesini gerçekçi şekilde simüle etmez. JMeter'ın mimarisi tam olarak bu iş için tasarlanmıştır.

Postman ne zaman kullanılmalı?

Postman'ı doğruluk sorularını cevaplamak için kullanın.

Örnek senaryolar:

• Yeni bir endpoint geliştiriyorsunuz.
• Yanıt gövdesinde zorunlu alanları doğrulamak istiyorsunuz.
• Her pull request'te regresyon testi çalıştırmak istiyorsunuz.
• API'nin yayınlanmış şemayla uyumlu kalmasını istiyorsunuz.
• QA ekibi kod yazmadan API davranışını test etmeli.
• Mock servis veya örnek yanıtlarla geliştirme hızlanmalı.

Örneğin bir kullanıcı oluşturma endpoint'i için şu kontrolleri yazabilirsiniz:

pm.test("User is created", function () {
    pm.response.to.have.status(201);
});

pm.test("Response contains email", function () {
    const body = pm.response.json();

    pm.expect(body).to.have.property("email");
    pm.expect(body.email).to.include("@");
});

Bu test, endpoint'in işlevsel olarak doğru çalıştığını gösterir. Ancak aynı endpoint'in 1.000 eşzamanlı kullanıcıda ne yapacağını göstermez.

Postman'ı CI içinde kullanmak için tipik akış şudur:

postman collection run ./collection.json

veya Newman ile:

newman run ./collection.json -e ./environment.json

Bir doğrulama başarısız olursa pipeline'ı durdurabilirsiniz. Bu yük testi değildir; işlevsel regresyon testidir ve mümkünse her commit veya pull request içinde çalışmalıdır.

API sözleşmesi kontrolleri için sözleşme testi yaklaşımını da kullanabilirsiniz.

JMeter sonucu nasıl okunur?

JMeter çıktısı yalnızca “başarılı” veya “başarısız” değildir. Sayıları doğru yorumlamanız gerekir.

En önemli metrikler:

1. Yüzdelik dilim gecikmeleri
2. Throughput
3. Hata oranı
4. Eşzamanlı kullanıcı sayısı
5. Test süresi

Ortalama yanıt süresi tek başına yeterli değildir. Birkaç hızlı istek, yavaş isteklerin etkisini gizleyebilir. Bu yüzden özellikle şu değerlere bakın:

• 90. yüzdelik dilim
• 95. yüzdelik dilim
• 99. yüzdelik dilim

Örneğin:

1. yüzdelik dilim yanıt süresi 1.8 saniye ise, isteklerin %5'i 1.8 saniyeden daha uzun sürüyor demektir.

Bu, ortalama iyi görünse bile kullanıcı deneyimi açısından sorun olabilir.

Throughput, sistemin saniyede tamamladığı istek sayısıdır. Örneğin:

Throughput: 850 req/sec
Error rate: 0.3%
P95 latency: 420 ms

Bu sonuç genellikle sağlıklı görünebilir. Ancak şu sonuç farklı yorumlanır:

Throughput: 900 req/sec
Error rate: 6%
P95 latency: 380 ms

Yanıt süresi düşük olsa bile %6 hata oranı kabul edilemez. Sistem hızlı yanıt veriyor olabilir, ancak isteklerin önemli bir kısmını başarısız döndürüyor.

Bu nedenle JMeter sonucunu her zaman birlikte okuyun:

• P95/P99 gecikme
• Throughput
• Hata oranı
• Uygulanan eşzamanlı kullanıcı sayısı

50 kullanıcıyla yapılan test, 1.000 kullanıcılı gerçek davranış hakkında yeterli bilgi vermez.

JMeter ne zaman kullanılmalı?

JMeter'ı ölçeklenebilirlik ve kapasite sorularını cevaplamak için kullanın.

Uygun senaryolar:

• Yayın öncesi API kapasitesini ölçmek
• Bir lansman öncesi beklenen trafiği simüle etmek
• Otomatik ölçeklendirme kurallarını doğrulamak
• Bellek sızıntısı veya bağlantı tükenmesi aramak
• Uzun süreli soak test çalıştırmak
• Ani trafik artışlarını spike test ile modellemek
• Veritabanı veya cache darboğazlarını görmek

Örnek bir test planı:

Thread Group:
- Number of Threads: 1000
- Ramp-up Period: 300 seconds
- Loop Count: 10

HTTP Request:
- GET /api/search?q=laptop

Assertions:
- Status code is 200
- Response time < 1000 ms

Listeners:
- Summary Report
- Aggregate Report
- HTML Report

Ciddi JMeter çalıştırmalarını GUI yerine komut satırından çalıştırmak daha doğrudur:

jmeter -n \
  -t search-load-test.jmx \
  -l results.jtl \
  -e \
  -o ./report

Burada:

• -n: GUI dışı mod
• -t: test planı dosyası
• -l: sonuç dosyası
• -e: HTML rapor üret
• -o: rapor klasörü

Kapasite planlama için JMeter sonuçları doğrudan kullanılabilir. Örneğin 1.000 eşzamanlı kullanıcıda P95 gecikme 400 ms altında kalıyor, ancak 1.500 kullanıcıda 2 saniyeyi geçiyorsa kapasite sınırınıza yaklaşmışsınız demektir.

Daha yapılandırılmış bir akış için API performans testi eğitimi rehberine bakabilirsiniz.

Rakip değiller, tamamlayıcılar

Olgun bir API test stratejisinde iki test türü de bulunur:

1. İşlevsel testler: API doğru yanıt veriyor mu?
2. Performans testleri: API beklenen trafik altında doğru ve hızlı yanıt veriyor mu?

Postman genellikle geliştirme ve regresyon aşamasında kullanılır. JMeter ise yayın öncesi kapasite ve stres doğrulamasında kullanılır.

Sağlıklı bir pipeline şöyle görünebilir:

Commit / Pull Request
        ↓
Postman veya Apidog ile işlevsel testler
        ↓
Build ve deploy
        ↓
Staging ortamı
        ↓
JMeter veya performans testi
        ↓
Release

Her commit'te tam yük testi çalıştırmak çoğu ekip için pahalı ve yavaştır. Ancak işlevsel testleri sık çalıştırmak gerekir. Yük testleri ise genellikle şu zamanlarda çalıştırılır:

• Büyük release öncesi
• Altyapı değişikliği sonrası
• Veritabanı veya cache değişikliği sonrası
• Haftalık veya periyodik kapasite kontrolünde
• Büyük kampanya/lansman öncesi

Pratik örnek: arama endpoint'i

Bir ekip /search endpoint'i yayınlıyor olsun.

Postman testleri şunları doğrular:

• Geçerli sorgu 200 OK dönüyor.
• Yanıt içinde sonuç listesi var.
• Sayfalama doğru çalışıyor.
• Boş veya hatalı sorgular doğru hata kodu dönüyor.

Örnek Postman testi:

pm.test("Search returns results", function () {
    pm.response.to.have.status(200);

    const body = pm.response.json();

    pm.expect(body).to.have.property("items");
    pm.expect(body.items).to.be.an("array");
});

Bu testler yeşilse endpoint işlevsel olarak doğru görünebilir.

Ancak iki hafta sonra bir pazarlama kampanyası trafiği 10 kat artırırsa ve her arama indekslenmemiş bir veritabanı taramasına neden olursa, yanıt süreleri 8 saniyeye çıkabilir. Postman bunu yakalayamaz çünkü tekil ve sıralı isteklerle çalışır.

JMeter ile aynı endpoint için şu test yapılabilirdi:

1000 sanal kullanıcı
5 dakikalık ramp-up
/search endpoint'ine sürekli istek
P95 latency hedefi: < 800 ms
Error rate hedefi: < 1%

Bu test, eksik veritabanı indeksini yayın öncesinde ortaya çıkarabilirdi.

Tersi de mümkündür. Bir API 5.000 kullanıcıyı kaldırabilir, ancak cache hatası nedeniyle yanlış fiyat döndürebilir. Yük testi bunu otomatik yakalamaz. Doğruluk olmadan hız, yalnızca hızlı yanlış yanıtlardır.

Apidog nerede devreye giriyor?

İki ayrı aracı kurmak, senkronize etmek ve sürdürmek ağır geliyorsa, Apidog API tasarımı, hata ayıklama, otomatik işlevsel test ve mock sunucuları tek platformda birleştirir.

Apidog ile şunları aynı çalışma alanında yapabilirsiniz:

• API şeması tasarlama
• İstek gönderme ve debug etme
• Görsel doğrulamalarla test senaryosu oluşturma
• Test adımlarını zincirleme
• Otomatik test paketleri hazırlama
• Mock sunucu kullanma
• Performans testiyle kayıtlı API senaryolarını sanal kullanıcılar altında çalıştırma

Bu yaklaşım, Postman ve JMeter benzeri ayrı araçlar arasında dışa aktarma, senkronizasyon ve bağlam değiştirme ihtiyacını azaltır.

Apidog'u indirebilir ve test özelliklerini deneyebilirsiniz. Alternatifleri karşılaştırmak isterseniz, API testi için en iyi Postman alternatifleri özetine de bakabilirsiniz.

Sıkça sorulan sorular

Postman yük testi yapabilir mi?

Anlamlı ölçekte değil. Collection Runner koleksiyonu sıralı olarak döngüye alır. Postman masaüstü uygulamasında temel performans özellikleri bulunsa da gerçekçi eşzamanlılık, ramp-up kontrolü ve ayrıntılı gecikme yüzdelikleri için JMeter, k6, Gatling veya Apidog'un performans testi modülü gibi araçlar daha uygundur.

JMeter işlevsel API testi yapabilir mi?

Evet, Response Assertion ile durum kodu ve yanıt içeriği kontrol edilebilir. Ancak JMeter'ın güçlü olduğu alan doğrulama yoğun işlevsel testler değil, eşzamanlılık ve performans ölçümüdür. Çoğu ekip işlevsel testleri Postman veya Apidog'da, yük testlerini JMeter'da tutar.

JMeter öğrenmek Postman'dan daha mı zor?

Evet. Postman ile birkaç dakika içinde istek gönderebilir ve basit doğrulamalar yazabilirsiniz. JMeter ise Thread Group, sampler, timer, listener, assertion ve GUI dışı çalıştırma gibi kavramlar gerektirir. Performans testi deneyiminiz yoksa öğrenme eğrisi daha diktir.

İki araca da ihtiyacım var mı?

Gerçek kullanıcı trafiği alan API'ler yayınlıyorsanız iki test türüne de ihtiyacınız vardır: işlevsel test ve performans testi. Ancak bu mutlaka iki ayrı ürün kullanmanız gerektiği anlamına gelmez. Apidog gibi platformlar, işlevsel test ve performans testini aynı çalışma alanında birleştirebilir.

Yavaş veritabanı sorgusunu hangi araç yakalar?

Yük altında genellikle JMeter yakalar. Boşta duran bir sisteme yapılan tek Postman isteği hızlı dönebilir. Sorun ancak eşzamanlı trafik veritabanı bağlantıları ve indeksler üzerinde baskı oluşturduğunda görünür. JMeter'ın paralel kullanıcı modeli bu darboğazları ortaya çıkarır.

k6, Gatling ve Locust nerede devreye giriyor?

Bunlar Postman alternatifi değil, JMeter alternatifi yük testi araçlarıdır. k6, Gatling ve Locust testleri kodla tanımlamayı tercih eden ekipler için uygundur. Ancak işlevsel API testinin yerini almazlar. Postman/JMeter ayrımı burada da geçerlidir: biri doğruluk, diğeri yük davranışı içindir.

Yük testlerini ne sıklıkla çalıştırmalıyım?

İşlevsel testlerden daha seyrek. İşlevsel kontroller hızlı olduğu için her commit veya pull request'te çalıştırılabilir. Yük testleri ise daha yavaş ve kaynak yoğun olduğundan genellikle release öncesi, büyük altyapı değişikliklerinden sonra veya haftalık periyodik kontrollerde çalıştırılır.