Postman ile API Testi: İstekten Otomasyona Adım Adım

API testi neyi doğrular?

API testi, bir uygulamanın arka uç hizmetlerini arayüze ihtiyaç duymadan doğrudan sınamaktır. Test eden kişi bir istek gönderir, dönen yanıtı inceler ve hizmetin beklenen davranışı sergileyip sergilemediğine karar verir. Arayüz testlerine göre daha hızlı çalışır, daha az kırılgandır ve hataları kaynağına daha yakın bir noktada yakalar.

Bir API testinde genellikle şu sorulara cevap aranır: Doğru istek doğru yanıtı döndürüyor mu? Hatalı ya da eksik istek anlaşılır bir hata mesajıyla reddediliyor mu? Yetkisiz kullanıcı korunan kaynağa ulaşabiliyor mu? Yanıtın yapısı, yani alanlar ve veri tipleri, sözleşmeyle uyumlu mu? Yanıt süresi kabul edilebilir bir aralıkta mı?

Postman, bu işi grafik bir arayüzle yapmayı sağlayan, test mühendislerinin ve yazılımcıların yaygın biçimde kullandığı bir API çalışma aracıdır. Aynı araçta istek gönderme, yanıt inceleme, test yazma ve sonuçları paylaşma imkânı bulunur.

Önce HTTP ve API temellerini bilin

Postman'i verimli kullanmak için altta yatan protokolü anlamak gerekir. Bir HTTP isteği şu parçalardan oluşur: yöntem, adres, başlıklar ve gerekiyorsa gövde. Yöntem işin türünü belirtir: veri okumak, yeni kayıt oluşturmak, mevcut kaydı güncellemek ya da silmek için farklı yöntemler kullanılır. Yanıt ise bir durum kodu, başlıklar ve çoğunlukla JSON biçiminde bir gövde içerir.

Durum kodlarının sınıflarını bilmek testi kolaylaştırır: başarılı yanıtlar, yönlendirmeler, istemci hataları ve sunucu hataları ayrı ailelerdir. Bir istemci hatası ile sunucu hatasının ne zaman beklendiğini ayırt edebilmek, yazdığınız doğrulamaların anlamlı olmasını sağlar.

Ayrıca iyi bir tester, test ettiği API'nin dokümantasyonunu okur. Hangi uç noktanın hangi parametreyi aldığı, hangi alanların zorunlu olduğu ve hangi hataların döndüğü orada yazar. Test senaryoları bu sözleşmeden türetilir.

İlk isteği gönderin ve yanıtı okuyun

Postman'de yeni bir istek açtığınızda yöntemi seçer, adresi yazar ve gerekirse parametre, başlık ve gövde alanlarını doldurursunuz. Gönder dediğinizde yanıtın durum kodunu, süresini ve gövdesini görürsünüz. Gövdeyi okunaklı biçimde görmek için biçimlendirilmiş görünüm kullanılabilir.

Başlangıçta herkese açık bir deneme API'siyle çalışmak mantıklıdır. Önce veri okuyan basit bir isteği deneyin, sonra yeni kayıt oluşturan bir istek yazın ve dönen yanıtta kaydın oluşup oluşmadığını kontrol edin. Gövdeyi JSON olarak gönderirken içerik tipi başlığının doğru ayarlandığına dikkat edin; birçok ilk hata buradan çıkar.

Bu aşamada amaç test yazmak değil, isteğin ve yanıtın nasıl göründüğüne alışmaktır. Elle denemeden otomatikleştirmeye geçmek, neyin otomatikleştirildiğini anlamadan yapılan işe göre çok daha sağlam sonuç verir.

Koleksiyon ve ortam değişkenleriyle düzen kurun

Birkaç istekten sonra düzen ihtiyacı doğar. Postman'de ilişkili istekler bir koleksiyon içinde gruplanır; örneğin kullanıcı işlemleri, sipariş işlemleri gibi klasörler oluşturulabilir. Koleksiyon aynı zamanda paylaşılabilen ve belgelenebilen bir birimdir.

Ortam değişkenleri, aynı koleksiyonu farklı ortamlarda çalıştırmanızı sağlar. Geliştirme, test ve canlıya yakın ortamların adresleri ve kimlik bilgileri farklıdır. Bu değerleri isteklere elle yazmak yerine değişkenlere koyarsanız, ortam değiştirmek tek bir seçimle yapılır. Böylece aynı test seti her ortamda yeniden kullanılır.

Değişken kullanımında iki pratik kural vardır. Birincisi, parola ve anahtar gibi gizli değerleri paylaşılan koleksiyona açık yazmamak, ayrı bir ortamda tutmaktır. İkincisi, bir isteğin yanıtından alınan değeri sonraki isteğe taşımaktır: örneğin giriş isteğinin döndürdüğü erişim anahtarını sonraki isteklerin yetkilendirme alanında kullanmak. Bu zincirleme, gerçek kullanıcı akışını taklit eden senaryoların temelidir.

Test betikleriyle yanıtı otomatik doğrulayın

Postman'de her isteğe, yanıt geldikten sonra çalışacak bir test betiği yazılabilir. Betik, yanıtı elle gözle kontrol etme işini koda çevirir. Böylece aynı doğrulama her çalıştırmada tutarlı biçimde yapılır.

Anlamlı bir test seti şu doğrulamaları kapsar: • Durum kodunun beklenen olması • Yanıt gövdesinde zorunlu alanların bulunması ve veri tiplerinin doğru olması • Belirli bir alanın beklenen değeri taşıması, örneğin oluşturulan kaydın adı • Yanıt süresinin kabul edilen sınırın altında kalması • Hata senaryolarında doğru hata mesajının dönmesi

Her istek için yalnız mutlu yolu değil, olumsuz durumları da yazın: eksik zorunlu alan, geçersiz veri tipi, olmayan bir kaynak. Olumsuz testler, API'nin hata yönetimindeki açıkları ortaya çıkarır. Test adlarını açıklayıcı tutun; başarısız olan testin adı, sorunun ne olduğunu tek bakışta anlatmalıdır.

Kimlik doğrulama ve güvenlik senaryolarını ekleyin

Gerçek API'lerin çoğu korumalıdır. Postman, farklı kimlik doğrulama yöntemlerini istek ayarlarından seçmenize izin verir: temel kimlik doğrulama, taşıyıcı anahtar ve yetkilendirme sunucusu tabanlı akışlar gibi. Önce yöntemin nasıl çalıştığını anlayın, sonra Postman'de yapılandırın.

Güvenlik testi, yetkilendirmenin gerçekten uygulandığını sınar. Anahtar olmadan istek gönderdiğinizde reddedilme beklenir. Süresi dolmuş ya da geçersiz bir anahtarla da reddedilme beklenir. Bir kullanıcının başka bir kullanıcıya ait kaynağa ulaşamadığını doğrulamak, yetki aşımı hatalarını yakalamak için önemli bir senaryodur.

Bu testler derin bir güvenlik denetiminin yerini tutmaz, ancak sık görülen temel açıkları geliştirme sürecinin erken evresinde yakalamaya yardım eder. Gizli değerlerin test ortamlarında tutulduğundan ve paylaşılan koleksiyonlara sızmadığından emin olun.

Newman ile testleri otomatik ve sürekli çalıştırın

Postman koleksiyonunu elle çalıştırmak keşif için yeterlidir, ancak düzenli regresyon testi için otomasyon gerekir. Newman, Postman koleksiyonlarını komut satırından çalıştıran araçtır. Koleksiyon ve ortam dosyası verildiğinde tüm istekleri sırayla çalıştırır, test sonuçlarını raporlar ve başarısızlık olursa hata koduyla biter.

Bu özellik, testleri sürekli entegrasyon hattına bağlamayı mümkün kılar. Geliştirici her değişiklik gönderdiğinde hat, uygulamayı test ortamına kurar, Newman'ı çalıştırır ve sonucu geliştiriciye bildirir. Böylece bir değişikliğin mevcut API davranışını bozup bozmadığı daha birleştirme aşamasında anlaşılır.

Bağımlılığı yönetmek için sahte sunucu (mock server) da kullanışlıdır. Arka uç henüz hazır değilse ya da dış bir hizmete bağımlıysanız, beklenen yanıtları taklit eden bir sahte sunucuyla ön uç ve test geliştirmesi paralel ilerleyebilir.

Sık hatalar ve öğrenme yolu

Sık yapılan hatalar: • Yalnız durum kodunu doğrulayıp yanıt gövdesini kontrol etmemek • Olumsuz senaryoları yazmamak • Gizli değerleri koleksiyona açık yazmak • İstekler arası bağımlılığı denetlemeden sıraya güvenmek • Test verisini temizlemeyip tekrar çalıştırmada çakışma yaşamak

Öğrenme yolu olarak önce HTTP ve JSON temellerini edinin, sonra Postman'de koleksiyon ve ortam kurmayı, ardından test betikleri yazmayı öğrenin. Sonraki aşamada kimlik doğrulama akışlarını, sahte sunucuyu ve Newman ile sürekli entegrasyonu ekleyin. Etkili bir pratik, gerçek ya da deneme bir API için küçük ama uçtan uca bir test seti kurmaktır.