Uygulamalı API Testleri: Postman Koleksiyonları, Environment, Script Yazımı ve CRUD

i Uygulamalı API Testlerine Giriş

Tek tek istekleri manuel olarak gönderip yanıtı gözle kontrol etmek, API testinin sadece başlangıcıdır. Gerçek bir test süreci; istekleri mantıklı gruplar halinde organize etmeyi, farklı ortamlar arasında (test, staging, production) sorunsuz geçiş yapmayı, istekler arasında veri aktarmayı (örneğin bir kaydı oluşturup ID’sini bir sonraki istekte kullanmayı) ve tüm bunları tekrarlanabilir bir koleksiyon haline getirmeyi gerektirir.

1 Postman Koleksiyonları

Collection (Koleksiyon), ilişkili API isteklerinin mantıksal bir hiyerarşi içinde bir arada gruplandığı yapıdır. İyi organize edilmiş bir koleksiyon, hem manuel test sırasında hem de otomasyonda (Collection Runner / Newman ile) okunabilirliği ve bakımı kolaylaştırır.

Koleksiyon Organizasyonu için İyi Pratikler

• Modüle göre klasörleme: Her iş alanı (Kimlik Doğrulama, Ürünler, Sipariş) ayrı bir klasörde tutulur.
• İsimlendirme standardı: İstek isimleri, ne yaptığını net anlatmalıdır (örn. “POST – Sipariş Oluştur – Geçerli Veri”).
• Collection Variables: Koleksiyon genelinde tekrar eden değerler (örn. API versiyon numarası) koleksiyon değişkeni olarak tanımlanır.
• Klasör seviyesinde script: Bir klasördeki tüm isteklerde ortak çalışması gereken script’ler (örn. token kontrolü) klasör seviyesinde tanımlanabilir.

2 Environment (Ortam) Yönetimi

Aynı test senaryosunu development, staging ve production gibi farklı ortamlarda değiştirmeden koşabilmek için Postman’in Environment (Ortam) özelliği kullanılır. Ortam değişkenleri ({{değişken}} formatında), URL, token gibi ortama özgü değerleri isteklerden soyutlar.

Bir istek URL’i sabit yazmak yerine değişken kullanılarak yazılır:

// Sabit (kötü pratik):
https://staging-api.magaza.com/v2/siparisler

// Değişken ile (iyi pratik):
{{baseUrl}}/{{apiVersion}}/siparisler

Ortam değiştirildiğinde (sağ üstteki açılır menüden “Production” seçildiğinde), aynı istek otomatik olarak https://api.magaza.com/v2/siparisler gibi doğru URL’e gider — koleksiyondaki hiçbir isteği elle değiştirmeye gerek kalmaz.

Değişken Kapsamları (Variable Scopes)

3 Script Yazımı: Pre-request ve Tests

Postman’de her istek için iki script alanı bulunur: istek gönderilmeden önce çalışan Pre-request Script ve yanıt geldikten sonra çalışan Tests script’i.

Örnek: Pre-request Script ile Dinamik Veri

// Pre-request Script - her koşumda benzersiz bir e-posta üretir
const zamanDamgasi = Date.now();
pm.environment.set("benzersizEposta", `test.kullanici.${zamanDamgasi}@ornek.com`);

Örnek: Tests Script ile Değer Zincirleme (Chaining)

// Tests Script - "Sipariş Oluştur" isteğinden dönen ID'yi bir sonraki
// istekte kullanmak üzere ortam değişkenine kaydeder
pm.test("Sipariş başarıyla oluşturuldu", function () {
    pm.response.to.have.status(201);
});

const yanit = pm.response.json();
pm.environment.set("sonOlusturulanSiparisId", yanit.siparisId);

// Bu değişken, koleksiyondaki bir sonraki istekte şu şekilde kullanılır:
// GET {{baseUrl}}/siparisler/{{sonOlusturulanSiparisId}}

4 Uçtan Uca CRUD Senaryosu

Yukarıda öğrendiğimiz koleksiyon organizasyonu, environment ve script yazımını bir araya getirerek, bir kaynağın tüm yaşam döngüsünü (Create, Read, Update, Delete) tek bir Postman klasöründe uçtan uca test edebiliriz.

1. Create (POST) — Yeni Kayıt Oluşturma

// İstek: POST {{baseUrl}}/musteriler
{
  "ad": "{{benzersizEposta}}",
  "eposta": "{{benzersizEposta}}"
}

// Tests Script
pm.test("201 Created dönmeli", () => pm.response.to.have.status(201));
pm.environment.set("musteriId", pm.response.json().id);

2. Read (GET) — Kaydı Sorgulama

// İstek: GET {{baseUrl}}/musteriler/{{musteriId}}

// Tests Script
pm.test("200 OK dönmeli", () => pm.response.to.have.status(200));
pm.test("Doğru müşteri dönmeli", () => {
    const yanit = pm.response.json();
    pm.expect(yanit.id).to.eql(pm.environment.get("musteriId"));
});

3. Update (PUT) — Kaydı Güncelleme

// İstek: PUT {{baseUrl}}/musteriler/{{musteriId}}
{ "ad": "Güncellenmiş Ad Soyad" }

// Tests Script
pm.test("200 OK dönmeli", () => pm.response.to.have.status(200));
pm.test("Ad güncellenmiş olmalı", () => {
    pm.expect(pm.response.json().ad).to.eql("Güncellenmiş Ad Soyad");
});

4. Delete (DELETE) — Kaydı Silme ve Doğrulama

// İstek: DELETE {{baseUrl}}/musteriler/{{musteriId}}

// Tests Script
pm.test("204 No Content dönmeli", () => pm.response.to.have.status(204));

// Ardından aynı ID ile GET isteği gönderilir ve şu doğrulanır:
pm.test("Silinen kayıt artık bulunamamalı", () => pm.response.to.have.status(404));

CRUD Testinde Kontrol Edilmesi Gereken Noktalar

• ✓ Create sonrası dönen ID, sonraki tüm adımlarda tutarlı şekilde kullanılıyor mu?
• ✓ Update sonrası Read isteği, güncellenmiş veriyi mi yoksa eski veriyi mi döndürüyor?
• ✓ Delete sonrası kayıt gerçekten erişilemez hale geliyor mu (404 dönüyor mu)?
• ✓ Var olmayan bir ID ile Update/Delete denendiğinde uygun hata kodu (404) dönüyor mu?
• ✓ Koleksiyon, Collection Runner ile sıfırdan sırayla koşturulduğunda hatasız tamamlanıyor mu?

✓ Sonuç ve Öneriler

Uygulamalı API testi, tek tek izole istekler göndermekten çok daha fazlasıdır: iyi organize edilmiş koleksiyonlar, doğru yapılandırılmış environment‘lar ve akıllı script’ler bir araya geldiğinde, gerçek kullanıcı senaryolarını (CRUD gibi) uçtan uca, tekrarlanabilir ve otomatikleştirilebilir şekilde test edebilirsiniz.