Postman Test Betikleriyle API Yanıtı Nasıl Doğrulanır?

Test betiği ne zaman ve nerede çalışır?

Postman'de test betikleri, bir isteğin yanıtı geldikten sonra çalışır. İsteğin Tests (Testler) sekmesine ya da koleksiyon veya klasör düzeyine yazılır; üst düzeydeki betik, altındaki tüm isteklere uygulanır. İstek gönderilmeden önce çalışan betik ise ön istek betiğidir (pre-request script) ve ayrı bir iştir: veri hazırlar, token üretir. Doğrulama, yanıt sonrası yazılır.

Temel mantık şudur: Her pm.test bloğu, adı olan tek bir beklentidir. Blok içindeki doğrulama geçerse test başarılı, hata fırlatırsa başarısız görünür. Test adını okuyunca ne beklendiğini anlayabilmelisiniz; bu ad, hata raporunda ve komut satırı çıktısında karşınıza çıkar.

Temel kalıp: pm.test ve pm.expect

Postman resmî belgeleri doğrulama örneklerini pm.test içinde pm.response.to.have ve pm.expect ile verir. En yaygın kalıplar şunlardır:

pm.test("Yanıt başarılı", function () { pm.response.to.be.ok; });

pm.test("Oluşturma durumu", function () { pm.response.to.have.status("Created"); });

pm.test("Gövde JSON ve dolu", function () { pm.response.to.be.withBody; pm.response.to.be.json; });

Durum doğrulaması hem sayısal kodla hem durum metniyle çağrılabilir; ekip okunabilirliğine göre birini seçip tutarlı kullanın.

pm.expect, Chai kütüphanesinin beklenti sözdizimini kullanır. Örneğin ortam adını denetlemek için pm.expect(pm.environment.name).to.equal("production") yazılabilir. Aynı sözdizimi gövdedeki değerler için de geçerlidir.

Gövde, başlık ve süre doğrulamaları

Gerçek bir uç nokta için doğrulamalar birkaç alana yayılır:

• Gövde: Önce yanıtı ayrıştırın, sonra alanları sınayın.

const govde = pm.response.json(); pm.test("Kullanıcı alanları var", function () { pm.expect(govde).to.have.property("id"); pm.expect(govde.eposta).to.be.a("string"); pm.expect(govde.roller).to.be.an("array").that.is.not.empty; });

• Başlık: İçerik tipini kontrol edin.

pm.test("İçerik tipi JSON", function () { pm.response.to.have.header("Content-Type"); pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json"); });

• Süre: Eşik değeri koda gömmeyin, ortam değişkeninden okuyun ki ortam başına ayarlanabilsin.

const sinir = Number(pm.environment.get("enFazlaYanitMs")); pm.test("Yanıt süresi sınırın altında", function () { pm.expect(pm.response.responseTime).to.be.below(sinir); });

Her doğrulama bir şeyi sınasın; bir bloğa birçok kural koyarsanız hata geldiğinde hangisinin düştüğünü ayıklamak zorlaşır.

Doğrulamaları yazarken beklentiyi sözleşmeden alın, yanıttan değil. Yanıtı kopyalayıp aynen beklemek, hatalı davranışı da doğru saymanıza yol açar. Örneğin sipariş oluşturma yanıtında toplam tutarın kalemlerin toplamına eşit olması gibi iş kuralları, yalnız biçim kontrolünün yakalayamayacağı hataları bulur.

Şema doğrulaması ve veri aktarımı

Alan alan kontrol uzayınca JSON şemasıyla doğrulamak daha sürdürülebilir olur. Yanıtın beklenen yapıya uyup uymadığını tek blokta sınarsınız: alanların varlığı, tipleri, zorunluluğu. Şema, API sözleşmesinden (OpenAPI belgesinden) üretilebilirse sözleşme ile test aynı kaynaktan beslenir.

Test betiği yalnızca doğrulama yapmaz, sonraki istek için veri de taşır. Bir kayıt oluşturma isteğinin yanıtından kimliği alıp ortam ya da koleksiyon değişkenine yazarsınız:

pm.collectionVariables.set("kullaniciId", govde.id);

Sonraki istek bu kimliği adresinde kullanır. Silme isteği sonunda değişkeni temizlemek, bir sonraki çalıştırmayı eski veriden korur. Böylece oluştur, getir, güncelle, sil zinciri tek koleksiyonda uçtan uca doğrulanır.

Başarısız senaryoları da test edin

Mutlu yol testi yeterli değildir. Her uç nokta için hata davranışını da sınayın:

• Geçersiz girdi gönderin ve doğrulama hatası döndüğünü, hata gövdesinin beklenen alanları taşıdığını doğrulayın.
• Kimlik doğrulaması eksik ya da süresi dolmuş istek gönderin ve yetkisiz yanıtı doğrulayın.
• Var olmayan kaynağı isteyin ve bulunamadı yanıtını doğrulayın.
• Başka kullanıcıya ait kaynağa erişmeyi deneyin ve erişimin reddedildiğini doğrulayın.

Hata yanıtlarında da gövde yapısının tutarlı olması istemci tarafı için önemlidir; test bu tutarlılığı sınayabilir. Hata testlerini ayrı bir klasörde tutmak, mutlu yol ve hata yolu sonuçlarını ayrı okumanıza yardım eder.

Test betiklerini üç düzeyde konumlandırabilirsiniz: istek düzeyi o isteğe özgü kuralları, klasör düzeyi bir kaynağın tüm uç noktalarında ortak kuralları, koleksiyon düzeyi ise her yanıtta geçerli genel kuralları taşır. Örneğin yanıtın JSON olması, kimlik başlığının dönmesi ya da hata gövdesinin ortak yapıda olması koleksiyon düzeyine konulursa her istekte tekrarlamak gerekmez. Ortak yardımcı işlevleri (örneğin hata gövdesi kontrolü) tek yerde tanımlayıp çağırmak da bakımı kolaylaştırır; bir kural değiştiğinde yalnız tek betiği güncellersiniz.

Sık yapılan hatalar

• Yalnız durum kodunu sınamak; 'başarılı' dönen ama yanlış veriyle dolu yanıtı yakalayamaz.
• Test adını anlamsız bırakmak; hata raporunda hangi kuralın düştüğü anlaşılmaz.
• Gövde boşken pm.response.json çağırmak; ayrıştırma hatası testi değil betiği düşürür. Önce gövdenin var olduğunu sınayın.
• Sabit değer beklemek; zaman damgası ve rastgele kimlik gibi değişen alanları biçim olarak (tip, desen) sınayın.
• Yanıt süresi eşiğini sıkı tutmak ve ortamdan bağımsız sabitlemek; yerel ve hazırlık ortamı farklı davranır.
• Testlerin birbirine gizli bağımlı olması; sıra bozulunca hepsi düşer. Bağımlılığı değişkenle açıkça kurun.
• Test sonrası veriyi temizlememek; tekrar çalıştırma çakışması üretir.
• pm.response ifadesini ön istek betiğinde kullanmak; yanıt henüz gelmediği için orada kullanılamaz, yanıta dayalı kurallar yalnız Tests alanına yazılır.
• Test adına her çalıştırmada değişen bir değer katmak; geçmiş sonuçları ve raporları karşılaştırmayı zorlaştırır, ad sabit kalmalı.
• Tüm yanıtı tek büyük nesneyle karşılaştırmak; küçük bir alan değişince bütün test düşer ve gerçek sorun gizlenir.

Bu becerinin Mindset programlarındaki yeri

Postman ile API Testi programında Test Betimleri ve Doğrulama modülü bu çalışmayı işler; Kimlik Doğrulama ve Güvenlik Testi modülü yetkisiz ve hatalı istek senaryolarıyla tamamlar, Newman ile CI/CD Entegrasyonu modülü ise yazılan testlerin otomatik çalıştırılmasını sağlar.

Program, yazılımcılar, test mühendisleri ve manuel API kontrolünü otomatik doğrulamaya taşımak isteyen kalite ekipleri için uygundur. Kurumsal ekiplerde test adlandırma ve hata senaryosu standardı koymak, uç noktaların sözleşmeye uygunluğunu kişiye bağlı olmaktan çıkarır.