Apache JMeter REST API Token Yönetimi: Master-Slave Yapısında Token Kullanımı

Apache JMeter ile REST API performans testleri gerçekleştirirken kimlik doğrulama amacıyla kullanılan Bearer Token, JWT veya benzeri erişim tokenlarının nasıl yönetileceği özellikle distributed test mimarisinde önem kazanır. Master ve 4-5 slave makineden oluşan bir JMeter altyapısında tokenı doğrudan User Defined Variables üzerinden GUI'de tanımlamak operasyonel açıdan oldukça pratiktir. Örneğin master makinedeki test planında TOKEN isimli bir değişken oluşturup değerine gerçek tokenı yazabilir ve HTTP Header Manager içerisinde "Authorization: Bearer ${TOKEN}" şeklinde kullanabilirsiniz. Distributed test başlatıldığında JMeter test planını remote engine'lere gönderdiği için slave makinelerde ayrıca ayrı bir TOKEN değişkeni oluşturmanız veya her slave için ayrı bir text/CSV dosyası hazırlamanız gerekmez. Bu yaklaşım özellikle tüm slave makinelerin aynı REST API'ye, aynı kullanıcı hesabı veya aynı yetkilendirme tokenı ile eriştiği senaryolarda yönetimi ciddi şekilde kolaylaştırır. Token tek noktadan değiştirilir ve test planı üzerinden tüm remote engine'lere uygulanır. Ancak burada önemli bir güvenlik ayrımı vardır: Tokenı GUI'deki User Defined Variables alanına yazmak, tokenın güvenli şekilde saklandığı anlamına gelmez. Değer JMX test planının içerisinde bulunabileceğinden, JMX dosyasına erişebilen kişiler tokenı görebilir. Ayrıca test planının paylaşılması, versiyon kontrol sistemine alınması veya başka ortamlara taşınması durumunda tokenın da istemeden paylaşılması riski oluşur. Dolayısıyla GUI yöntemi operasyonel basitlik açısından avantajlı, ancak secret yönetimi açısından tek başına ideal değildir. Token değerini bir text veya CSV dosyasında tutmak ise test planı ile secret değerini birbirinden ayırma avantajı sağlar. JMX dosyasını açan kişi doğrudan token değerini görmez; test planında yalnızca ${TOKEN} değişkeni bulunur ve değer CSV Data Set Config gibi bir mekanizma üzerinden okunabilir. Ancak Distributed JMeter mimarisinde burada farklı bir operasyonel yük ortaya çıkar.

Apache JMeter'da Gizli Kalan Detaylar: Distributed Test Yaparken Neden Response Body Göremezsiniz?

Performans Testi dünyasında Apache JMeter, uzun yıllardır sektör standardı olarak kullanılan güçlü araçlardan biri olmaya devam ediyor. Ancak JMeter’ı sadece çalıştırabilmek yeterli değildir; asıl fark, onu doğru mimariyle ve verimli bir iş akışıyla kullanabilmektir. Özellikle Distributed Test (Dağıtık Test) mimarisine geçen ekiplerin sıkça karşılaştığı kritik bir durum vardır: slave sunucular üzerinden test çalıştırıldığında View Results Tree listener içerisinde response body verisinin görünmemesi. Bu durum çoğu zaman yanlış bir arıza algısına yol açar ve “sistem bozuldu mu?” sorusunu gündeme getirir. Oysa bu bir hata değil, JMeter’ın ölçeklenebilirlik ve performans odaklı tasarımının bilinçli bir sonucudur. Slave node’lar, test yükünü üretmeye odaklanırken gereksiz veri transferini minimize eder; response body gibi ağır içerikler master node’a taşınmaz. Bunun yerine yalnızca metrik ve istatistiksel veriler iletilir. Bu yaklaşım, network bant genişliğini koruyarak testin gerçek yük senaryosuna daha yakın kalmasını sağlar. Bu nedenle en sağlıklı test yaklaşımı belirli bir standardizasyon gerektirir. Öncelikle senaryolar local ortamda, düşük kullanıcı yüküyle çalıştırılmalı ve response body doğrulaması yapılmalıdır. Yeşil Run butonu ile yapılan bu ilk kontrol, testin doğruluğunu garanti altına alır. Ancak bu adımdan sonra distributed mimariye geçilmeli ve Remote Start All komutu ile gerçek yük testi başlatılmalıdır. Bu disiplinli yaklaşım, hem debug süresini ciddi ölçüde azaltır hem de test sonuçlarının güvenilirliğini artırır. Doğru iş akışı ile JMeter, sadece bir test aracı değil, kurumsal performans mühendisliğinin stratejik bir bileşenine dönüşür. Bu yazıda, JMeter arayüzünde günlük hayatı kolaylaştıran; çoğu dokümanda geçmeyen ama deneyimle öğrenilen pratik ipuçlarını bir araya getirdim.

Apache JMeter ile Dynamic API Correlation: Response Verisini Sonraki Request Path’ine Aktarma (Performans Testi)

Modern API Test otomasyonlarında en kritik ihtiyaçlardan biri, bir request sonucunda oluşan dinamik verinin sonraki adımlarda doğru şekilde kullanılabilmesidir. Özellikle OTP, transactionId, orderId, token veya sessionId gibi runtime sırasında üretilen veriler statik olmadığı için performans ve entegrasyon testlerinde manuel değer kullanımı sürdürülebilir değildir. Bu nedenle test senaryolarının response içinden veri okuyup bunu otomatik olarak sonraki request’lere taşıyabilmesi gerekir. Apache JMeter, bu ihtiyacı JSON Extractor ve variable management mekanizmalarıyla oldukça verimli şekilde karşılar. Bu çalışmada, OTP akışı üzerinden örnek bir correlation senaryosu ele alınmıştır. İlk aşamada SEND endpoint’ine POST request atılarak OTP süreci başlatılır ve API response içerisinde dinamik olarak bir otpId oluşturulur. Ardından JMeter üzerinde konumlandırılan JSON Extractor ile bu değer response body’den parse edilerek değişken olarak saklanır. Bir sonraki aşamada çalışan VERIFY request’i ise bu değeri manuel tanımlamak yerine runtime sırasında otomatik olarak path parametresine inject eder. Böylece test akışı tamamen dinamik hale gelir ve her çalıştırmada yeni üretilen otpId üzerinden doğrulama işlemi gerçekleştirilir. Verify işleminde kullanılan otpCode alanı bu senaryoda sabit olup "111111" değeri ile gönderilmektedir; dolayısıyla ek bir veri üretimine ihtiyaç duyulmaz. Bu yaklaşım, sadece OTP senaryoları için değil, request chaining gerektiren tüm API workflow’larında reusable ve maintainable test scriptleri geliştirmek için temel bir pattern olarak değerlendirilebilir.