Forem: Tobias Hoffmann

Test Amaçlı API Mocklama: Uygulamalı Rehber

Tobias Hoffmann — Fri, 22 May 2026 07:37:36 +0000

Canlı bir API'ye bağlı testler, kodunuz doğru olsa bile yanlış nedenlerle başarısız olabilir: hazırlık sunucusu çöker, üçüncü taraf hız limiti devreye girer veya bir ekip arkadaşı test verisini değiştirir. API taklidi, gerçek uç noktayı kontrollü bir yedekle değiştirerek testlerinize deterministik yanıtlar verir.

Apidog'u bugün deneyin

Bu rehberde bir API'yi test için nasıl taklit edeceğinizi adım adım uygulayacağız: şema tanımlama, taklit yanıt üretme, taklit sunucu çalıştırma, testleri bu sunucuya yönlendirme ve hata yollarını doğrulama. Örnek olarak küçük bir sipariş yönetimi API'sindeki GET /orders/{id} uç noktasını kullanacağız; aynı yaklaşım REST ve GraphQL servisleri için de geçerlidir.

API'yi ne zaman taklit etmelisiniz?

Ağ katmanını değil, kendi kodunuzu test etmek istiyorsanız API'yi taklit edin. Bu özellikle birim testleri ve çoğu entegrasyon testi için uygundur.

Örneğin istemcinizin şunları doğru yaptığını doğrulamak için gerçek sunucuya ihtiyacınız yoktur:

200 yanıtını ayrıştırmak
404 için anlamlı hata göstermek
429 veya 503 durumlarında yeniden denemek
Bozuk JSON geldiğinde çökmemek
Yavaş yanıt geldiğinde zaman aşımına düşmek

Gerçek API'yi tamamen bırakmayın. Canlı servise karşı küçük bir sözleşme testi ve uçtan uca test katmanı tutun. Amaç, taklitlerin hâlâ gerçek API sözleşmesiyle uyumlu olduğunu doğrulamaktır.

Kısaca:

Hız ve izolasyon için taklit kullanın.
Sözleşmeyi doğrulamak için gerçek API kullanın.

Daha fazla bağlam için API taklidinin işe yaradığı senaryolara ve taklit sunucu ile gerçek sunucu arasındaki farka bakabilirsiniz.

Beş adımlı iş akışı

Bir API'yi test için taklit ederken süreç genellikle aynıdır:

Gerçek yanıt şeklini yansıtmak için şemayı tanımlayın.
Bu şemadan statik veya dinamik taklit yanıtlar oluşturun.
Yanıtları bir URL üzerinden sunan taklit sunucuyu çalıştırın.
Test kodunuzdaki temel URL'yi değiştirerek testleri taklit sunucuya yönlendirin.
Gerçek sunucunun isteğe bağlı üretmeyeceği hata yollarını test edin.

Aşağıdaki örneklerde GET /orders/{id} uç noktasını kullanacağız.

Adım 1: Şemayı tanımlayın

Taklit yanıt, gerçek API yanıtıyla aynı yapıda değilse testiniz yanıltıcı olur. Bu yüzden önce şema tanımlayın.

API'nizin zaten bir OpenAPI belgesi varsa onu kullanın. Yoksa en azından test ettiğiniz uç nokta için küçük bir şema yazın.

Örnek GET /orders/{id} tanımı:

paths:
  /orders/{id}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: Order found
          content:
            application/json:
              schema:
                type: object
                required:
                  - id
                  - status
                  - total
                  - items
                properties:
                  id:
                    type: string
                  status:
                    type: string
                    enum:
                      - pending
                      - shipped
                      - delivered
                  total:
                    type: number
                  items:
                    type: array
                    items:
                      type: object
        '404':
          description: Order not found

Bu şema iki şey sağlar:

Taklit sunucunun hangi alanları döndüreceğini belirler.
API sözleşmesi için tek doğruluk kaynağı oluşturur.

Arka uç sözleşmeyi değiştirdiğinde şemayı güncellersiniz. Şemadan türetilen taklitler de bu değişikliği takip eder. Bu yaklaşım, API sözleşme testini güvenilir tutar.

Adım 2: Taklit yanıtları oluşturun

Taklit yanıt üretmek için iki ana yöntem vardır.

Statik yanıt

Statik yanıt, değişmeyen sabit JSON'dur. Özellikle deterministik birim testleri için uygundur.

Örnek:

{
  "id": "order_8842",
  "status": "shipped",
  "total": 149.99,
  "items": [
    {
      "sku": "sku_123",
      "quantity": 1
    },
    {
      "sku": "sku_456",
      "quantity": 2
    }
  ]
}

Bunu şu durumlarda kullanın:

Beklenen yanıtı birebir doğrulamak istiyorsanız
Snapshot benzeri testler yazıyorsanız
Testin her çalıştırmada aynı veriyle koşmasını istiyorsanız

Dinamik yanıt

Dinamik yanıt, her istek için gerçekçi değerlerle oluşturulur. Örneğin:

id için UUID
status için enum içinden geçerli bir değer
total için makul bir para değeri
items için farklı uzunlukta diziler

Dinamik veri, tek bir sabit yükün kaçırabileceği hataları yakalamanıza yardım eder. Örneğin istemciniz boş dizi, uzun metin veya beklenmeyen ama geçerli enum değeriyle bozuluyorsa bunu daha erken görürsünüz.

Çoğu ekip iki yaklaşımı birlikte kullanır:

Kritik doğrulamalar için statik yanıt
Daha geniş kapsama için dinamik yanıt

Apidog, şemayı okuyarak taklit uç noktası oluşturabilir. email, phone veya avatar gibi alan adlarını uygun veri türleriyle eşleştirip geçerli yanıtlar döndürebilir. Böylece tarayıcıdan veya test kodundan taklit URL'sini çağırarak hızlıca yanıt alabilirsiniz.

Elle yük yazıyorsanız gerçekçi veri kullanın. Aşağıdaki gibi aşırı basit yükler hataları gizleyebilir:

{
  "id": "1",
  "status": "pending",
  "total": 0,
  "items": []
}

Bunun yerine üretime daha yakın veri kullanın:

{
  "id": "order_8842",
  "status": "shipped",
  "total": 149.99,
  "items": [
    {
      "sku": "keyboard-pro",
      "quantity": 1,
      "price": 89.99
    },
    {
      "sku": "mouse-wireless",
      "quantity": 1,
      "price": 60
    }
  ]
}

Adım 3: Taklit sunucuyu çalıştırın

Taklit yanıt ancak bir sunucu üzerinden sunulduğunda testler tarafından kullanılabilir. İki seçeneğiniz vardır.

Yerel taklit sunucu

Yerel taklit sunucu makinenizde çalışır. Genellikle localhost veya 127.0.0.1 üzerinde bir port dinler.

Örneğin Prism ile OpenAPI dosyasından taklit sunucu başlatabilirsiniz:

prism mock openapi.yaml
# Mock server listening on http://127.0.0.1:4010

Yerel taklit sunucu şunlar için uygundur:

Birim testleri
Entegrasyon testleri
CI içinde izole test çalıştırmaları
Çevrimdışı geliştirme

Avantajları:

Hızlıdır.
Ağ gecikmesi minimumdur.
Paylaşılan durum olmadığı için testler birbirini etkilemez.

Bulut taklit sunucu

Bulut taklit sunucunun genel bir URL'si vardır. Şu durumlarda kullanışlıdır:

Mobil uygulama fiziksel cihazdan test ediliyorsa
CI çalıştırıcısının yerel makinenize erişimi yoksa
Harici bir ekip arkadaşı aynı taklite erişmek istiyorsa
Demo veya ürün incelemesi yapılıyorsa

Apidog, projeler için barındırılan Bulut Taklit URL'si sağlayabilir. Böylece farklı ağlardaki ekip üyeleri aynı taklit uç noktaya erişebilir.

Genel kural:

Otomatik testlerde yerel taklit kullanın.
Demo, cihaz testi ve ekip paylaşımı için bulut taklit kullanın.

Adım 4: Testlerinizi taklit sunucuya yönlendirin

Test kodunuz üretim URL'sine sabitlenmiş olmamalıdır. Temel URL'yi yapılandırılabilir yapın.

Örnek istemci:

// orderClient.js
export async function getOrder(id, baseUrl) {
  const response = await fetch(`${baseUrl}/orders/${id}`);

  if (response.status === 404) {
    throw new Error('Order not found');
  }

  if (!response.ok) {
    throw new Error(`Request failed with status ${response.status}`);
  }

  return response.json();
}

Testte temel URL'yi ortam değişkeninden okuyun:

// orderClient.test.js
import { getOrder } from './orderClient.js';

const BASE_URL = process.env.API_BASE_URL || 'http://127.0.0.1:4010';

test('shipped durumundaki siparişi ayrıştırır', async () => {
  const order = await getOrder('order_8842', BASE_URL);

  expect(order.status).toBe('shipped');
  expect(typeof order.total).toBe('number');
  expect(Array.isArray(order.items)).toBe(true);
});

CI içinde testleri taklit sunucuya yönlendirmek için:

API_BASE_URL=http://127.0.0.1:4010 npm test

Bu desenin avantajı şudur: uygulama kodu taklit sunucudan haberdar olmaz. Sadece farklı bir temel URL alır.

Aynı yaklaşım, CI/CD içinde API testlerini otomatikleştirirken de geçerlidir.

Adım 5: Hata yollarını test edin

Gerçek sunucu istediğiniz anda 500, 429 veya yavaş yanıt üretmez. Taklit sunucu ise bunu kontrollü şekilde yapabilir.

Aşağıdaki senaryoları özellikle test edin:

Senaryo	Taklit ne döndürür?	Ne doğrulanır?
Kayıp kayıt	`404`	İstemci açık bir "bulunamadı" hatası üretir
Sunucu hatası	`500`	İstemci yeniden dener veya geri dönüş davranışı uygular
Hız limiti	`429` ve `Retry-After`	İstemci doğru süre bekler
Yavaş yanıt	5 sn gecikmeden sonra `200`	İstemci zaman aşımını doğru yönetir
Bozuk gövde	Bozuk JSON ile `200`	İstemci çökmek yerine kontrollü hata üretir

Örnek Jest testi:

test('404 geldiğinde anlamlı hata fırlatır', async () => {
  await expect(getOrder('order_404', BASE_URL)).rejects.toThrow('Order not found');
});

Yeniden deneme davranışı test ediyorsanız istemcinizde retry mantığını izole edin:

export async function getOrderWithRetry(id, baseUrl, retries = 2) {
  let lastError;

  for (let attempt = 0; attempt <= retries; attempt++) {
    try {
      return await getOrder(id, baseUrl);
    } catch (error) {
      lastError = error;
    }
  }

  throw lastError;
}

Test:

test('geçici hata durumunda yeniden dener', async () => {
  const order = await getOrderWithRetry('order_retry', BASE_URL, 2);

  expect(order.id).toBe('order_retry');
});

Apidog'un gelişmiş taklit kuralları, isteğe göre farklı yanıtlar döndürmenizi sağlar. Örneğin order_404 için yapılan istek 404 dönerken diğer kimlikler normal 200 yanıtı alabilir. Bunu API doğrulama ile birleştirerek yalnızca durum kodlarını değil, davranışı da doğrulayabilirsiniz.

Büyüyen test paketinde taklitleri düzenleme

Tek bir taklit uç nokta kolay yönetilir. Ancak test paketi büyüdükçe taklitler hızla dağılabilir. Bunu önlemek için birkaç kural uygulayın.

Taklitleri teste göre değil, servise göre gruplayın

Kötü yapı:

tests/
  checkout/
    mock-order.json
  profile/
    mock-order.json
  admin/
    mock-order.json

Daha sürdürülebilir yapı:

mocks/
  orders/
    order-shipped.json
    order-not-found.json
    order-rate-limited.json
  payments/
    payment-success.json
    payment-declined.json

Ödeme API'si değiştiğinde yirmi test dosyası yerine tek bir servis klasörünü güncellersiniz.

Senaryoya göre adlandırın

Dosya veya fixture adları niyeti açık göstermelidir:

order-shipped.json
order-pending.json
order-not-found.json
order-rate-limited.json
order-malformed-response.json

Böylece başarısız test çıktısı daha okunabilir olur.

Ortak temel yanıt kullanın

Her test için tamamen ayrı JSON yazmayın. Temel bir sipariş tanımlayıp yalnızca gerekli alanı değiştirin.

Örnek:

const baseOrder = {
  id: 'order_8842',
  status: 'shipped',
  total: 149.99,
  items: [
    {
      sku: 'keyboard-pro',
      quantity: 1,
      price: 89.99
    }
  ]
};

const pendingOrder = {
  ...baseOrder,
  status: 'pending'
};

const expensiveOrder = {
  ...baseOrder,
  total: 999.99
};

Bu yaklaşım, sözleşme değişikliğinde tek bir temel yapıyı güncellemenizi sağlar.

API otomasyonu için test paketi tasarlarken uyguladığınız disiplin, taklit veriler için de geçerlidir.

Taklitleri gerçek sözleşmeyle senkron tutma

Taklitlerin en büyük riski sözleşmeden sapmasıdır. Arka uç total alanını amount olarak değiştirir, enum'a yeni değer ekler veya zorunlu alan çıkarır; taklit eski yanıtı döndürmeye devam eder. Testler geçer, üretim bozulur.

Bunu önlemek için iki pratik alışkanlık edinin.

1. Taklitleri aynı şemadan üretin

Taklitleri arka ucun kullandığı OpenAPI belgesinden üretin. Şema değiştiğinde taklit de güncellenir.

Elle yazılmış taklitlerde bu bağlantı yoktur. Bu yüzden manuel fixture kullanıyorsanız bile şemaya karşı doğrulama çalıştırın.

2. Gerçek API'ye karşı küçük sözleşme testleri çalıştırın

Taklit testleri hızlı ve izole olmalıdır. Ancak düzenli olarak gerçek API'ye karşı küçük bir sözleşme testi seti çalıştırın.

Amaç şu soruyu yanıtlamaktır:

Canlı API yanıtı hâlâ şemayla uyumlu mu?

Bu testler başarısız olursa taklitlerinizin de güncellenmesi gerekir.

Örnek ayrım:

npm run test:mock       # Her commit'te hızlı taklit testleri
npm run test:contract   # Belirli aralıklarla veya deploy öncesi gerçek API sözleşme testleri

3. Kod incelemede taklitleri de kontrol edin

Bir pull request API yanıtını değiştiriyorsa, ilgili taklitlerin de güncellenip güncellenmediği kontrol edilmelidir. Taklitleri geçici test yardımcısı değil, sözleşmenin parçası olarak değerlendirin.

Şema, taklit sunucu ve test paketini aynı akışta tutmak istiyorsanız Apidog'u İndirin. Daha geniş araç karşılaştırması için REST API taklit araçları listesini inceleyebilirsiniz.

Sıkça sorulan sorular

Her test için API'yi taklit etmeli miyim?

Hayır. Birim ve entegrasyon testlerinde taklit kullanın. Bunun yanında gerçek API'ye giden küçük bir sözleşme ve uçtan uca test grubu bulundurun. Her şeyi taklit etmek sözleşme sapmasını gizleyebilir.

Statik ve dinamik taklit yanıt arasındaki fark nedir?

Statik yanıt, değişmeyen sabit JSON yüküdür. Tahmin edilebilir doğrulamalar için uygundur.

Dinamik yanıt, her istek için gerçekçi değerlerle üretilir. Tek bir sabit yükün yakalayamayacağı ayrıştırma ve sınır durum hatalarını bulmaya yardımcı olur.

Taklitimin doğru kaldığından nasıl emin olurum?

Takliti arka ucun kullandığı aynı şemadan, ideal olarak OpenAPI belgesinden üretin. Ardından gerçek API'ye karşı düzenli sözleşme testleri çalıştırarak canlı yanıtların hâlâ bu şemayla eşleştiğini doğrulayın.

Taklit sunucu yavaş veya başarısız yanıtları simüle edebilir mi?

Evet. Taklit sunucuyu 500, 429 ve Retry-After başlığı veya gecikmeli 200 döndürecek şekilde yapılandırabilirsiniz. Bu, yeniden deneme, geri çekilme ve zaman aşımı mantığını güvenli şekilde test etmenizi sağlar.

Test için yerel taklit sunucu mu, bulut taklit sunucu mu?

Otomatik test çalıştırmaları için yerel taklit sunucu kullanın. Daha hızlıdır ve paylaşılan durum riskini azaltır.

Mobil cihaz, CI ortamı veya harici ekip üyesi yerel makinenize erişemiyorsa bulut taklit sunucu kullanın.

Insomnia ile API Testi Nasıl Yapılır

Tobias Hoffmann — Fri, 22 May 2026 07:37:16 +0000

Insomnia, Kong tarafından geliştirilen hafif bir API istemcisidir. HTTP, REST, GraphQL, gRPC, SOAP ve WebSocket isteklerini tek arayüzden göndermenizi, yanıtları incelemenizi ve test paketleriyle doğrulama yapmanızı sağlar. Bu rehberde Insomnia ile bir API isteği oluşturacak, ortam değişkenleri kullanacak, assertion yazacak ve testleri komut satırından çalıştıracaksınız.

Apidog'u bugün deneyin

Insomnia'yı kurun ve ilk isteği oluşturun

Insomnia'yı resmi Kong sitesinden indirin ve işletim sisteminize kurun. İlk açılışta oturum açmanız istenebilir. Bulut senkronizasyonu kullanmak istemiyorsanız yerel çalışma seçeneğini tercih edebilirsiniz.

Insomnia'da çalışmalar genellikle koleksiyonlar altında düzenlenir.

Ana ekranda Create / Oluştur seçeneğine tıklayın.
Request Collection / İstek Koleksiyonu oluşturun.
Koleksiyona örneğin Kullanıcı API testleri adını verin.
Koleksiyon içinde + düğmesine tıklayın.
HTTP Request / HTTP İsteği seçin.

İlk test için GET metodunu kullanın:

GET https://jsonplaceholder.typicode.com/users/1

Send / Gönder düğmesine tıkladığınızda Insomnia sağ panelde şunları gösterir:

Yanıt gövdesi
HTTP durum kodu
Yanıt süresi
Yanıt boyutu
JSON biçimlendirilmiş çıktı

JSON yanıt büyükse JSONPath veya XPath filtreleriyle sadece ihtiyacınız olan alanları görüntüleyebilirsiniz.

Metot, parametre, gövde ve kimlik doğrulama ayarlayın

Basit GET isteklerinden sonra genellikle gövde, header, query parametresi veya auth bilgisi eklemeniz gerekir. Insomnia bu ayarları URL alanının altındaki sekmelerde toplar.

JSON gövdeyle POST isteği gönderin

Yeni bir istek oluşturun ve metodu POST yapın. Body / Gövde sekmesinde JSON seçin:

{
  "name": "Daniel Okafor",
  "email": "daniel.okafor@example.com"
}

JSON gövde seçtiğinizde Insomnia genellikle Content-Type: application/json başlığını otomatik ekler.

Query parametreleri ekleyin

URL'yi elle uzatmak yerine Query sekmesini kullanın.

Örneğin şu URL yerine:

GET https://api.example.com/users?page=1&limit=20&active=true

parametreleri tablo halinde ekleyebilirsiniz:

Parametre	Değer
`page`	`1`
`limit`	`20`
`active`	`true`

Bu yöntem uzun URL'leri okunabilir tutar ve parametreleri tek tek etkinleştirip devre dışı bırakmanızı sağlar.

Header ekleyin

Headers / Başlıklar sekmesinde API'nizin beklediği özel başlıkları tanımlayın:

Accept: application/json
X-Request-Id: test-123

Hangi durum kodlarını beklemeniz gerektiğinden emin değilseniz, REST API'lerinin kullanması gereken HTTP durum kodları referansı yardımcı olabilir.

Bearer Token ile kimlik doğrulama yapın

Auth / Kimlik Doğrulama sekmesinde API'nizin kullandığı yöntemi seçin. Insomnia şu şemaları destekler:

Bearer Token
Basic Auth
API Key
OAuth 1.0 / 2.0
AWS IAM
Diğer yaygın auth türleri

Bearer token kullanan bir API için:

Auth sekmesini açın.
Bearer Token seçin.
Token değerini girin.

Ancak token'ı doğrudan isteğe yazmak yerine ortam değişkeni kullanmak daha güvenlidir.

Ortamları ve değişkenleri kullanın

Ortamlar, aynı koleksiyonu farklı hedeflerde çalıştırmanızı sağlar. Örneğin dev, staging ve production için ayrı base URL veya token değerleri kullanabilirsiniz.

Yan çubuğun üst kısmındaki ortam menüsünden Manage Environments / Ortamları Yönet bölümünü açın.

Temel bir ortam şu şekilde olabilir:

{
  "base_url": "https://jsonplaceholder.typicode.com",
  "auth_token": "your-token-here"
}

İstek URL'sinde değişkeni şu sözdizimiyle kullanın:

GET {{ _.base_url }}/users/1

Authorization header içinde token değişkeni kullanmak için:

Authorization: Bearer {{ _.auth_token }}

Aktif ortamı değiştirdiğinizde bu değişkenleri kullanan tüm istekler otomatik olarak yeni değerlere göre çalışır.

İstekleri şablon etiketleriyle zincirleyin

Insomnia, alanlara dinamik değerler eklemek için template tags / şablon etiketleri destekler. Bunlarla şunları üretebilir veya alabilirsiniz:

UUID
Timestamp
Ortam değişkeni
Önceki bir isteğin yanıtından değer

Örneğin login isteğiniz şu yanıtı dönüyorsa:

{
  "token": "abc.def.ghi"
}

korumalı isteklerde bu token'ı elle kopyalamak yerine yanıt şablon etiketiyle $.token JSONPath değerini çekebilirsiniz.

Kullanım mantığı:

Login isteğini oluşturun.
Yanıttaki token alanını JSONPath ile hedefleyin: $.token
Korumalı isteklerde Authorization başlığına bu değeri bağlayın.
Insomnia gerekirse login isteğini çalıştırır, token'ı alır ve sonraki istekte kullanır.

Bu yaklaşım, test zincirini betik yazmadan yönetmenizi sağlar. Test senaryolarını gruplama fikri için API test durumu örneği rehberine de bakabilirsiniz.

Assertion içeren test paketleri yazın

İstek göndermek yanıtı görmenizi sağlar; ancak yanıtın doğru olup olmadığını otomatik kontrol etmek için test paketleri kullanmanız gerekir. Insomnia'da bu bölüm bazı sürümlerde Tests veya Unit Tests olarak görünür.

Bir test paketi oluşturmak için:

Koleksiyonunuzu açın.
Tests / Testler görünümüne geçin.
Yeni bir test paketi oluşturun.
Pakete testler ekleyin.
Her testi koleksiyondaki ilgili isteğe bağlayın.

Insomnia testleri JavaScript ile yazılır ve Chai tarzı expect assertion kullanır.

Basit durum kodu testi:

const response = await insomnia.send();

expect(response.status).to.equal(200);

Yanıt gövdesini kontrol eden daha kapsamlı bir test:

const response = await insomnia.send();
const body = JSON.parse(response.data);

expect(response.status).to.equal(200);
expect(body).to.have.property("id");
expect(body.email).to.equal("daniel.okafor@example.com");

Header kontrolü örneği:

const response = await insomnia.send();

expect(response.headers["content-type"]).to.include("application/json");

Hata senaryosu testi:

const response = await insomnia.send();

expect(response.status).to.equal(404);

Testleri çalıştırmak için Run Tests / Testleri Çalıştır düğmesine basın. Insomnia her testin geçip geçmediğini ve ne kadar sürdüğünü gösterir.

Test paketlerini düzenli tutun

Test sayısı arttıkça paket yapısı önem kazanır. Uygulanabilir bir düzen şu şekildedir:

User API tests
├── Kullanıcı detayını getirir
├── Olmayan kullanıcı için 404 döner
├── Geçersiz email için doğrulama hatası döner

Article API tests
├── Makale listesini getirir
├── Makale oluşturur
├── Yetkisiz istekte 401 döner

Her test tek davranışı doğrulamalıdır. Böylece bir test başarısız olduğunda test adından neyin bozulduğunu anlayabilirsiniz.

İyi assertion yazma konusunda daha fazla örnek için API onaylamaları rehberine, paketleri büyüdükçe yapılandırmak için ise API test otomasyonu için test paketleri makalesine bakabilirsiniz.

Inso ile testleri komut satırından çalıştırın

GUI geliştirme sırasında kullanışlıdır; ancak CI/CD için testleri başsız şekilde çalıştırmanız gerekir. Insomnia bunun için Inso adlı komut satırı aracını sağlar.

Koleksiyonunuzu dışa aktardıktan veya senkronize ettikten sonra test paketini terminalden çalıştırabilirsiniz:

inso run test "User API tests"

Bir test başarısız olursa Inso sıfır olmayan exit code döndürür. Bu davranış CI sistemleri için idealdir çünkü derlemeyi otomatik olarak başarısız işaretleyebilirsiniz.

Basit bir CI akışı şu şekilde olabilir:

npm install -g inso
inso run test "User API tests"

GitHub Actions veya benzer bir çalıştırıcıda bu komutu her push veya pull request için çalıştırabilirsiniz. Böylece bozuk bir endpoint üretime ulaşmadan yakalanır.

Inso ayrıca API spesifikasyonlarını lint etmek ve test raporları üretmek için de kullanılabilir. Genel yaklaşım için CI/CD'de API testlerini otomatikleştirmek yazısındaki kalıp Insomnia testlerine de uygulanabilir.

Insomnia 8'deki bulut değişikliği ve alternatif yaklaşım

Insomnia 8 ile ürün, bulut öncelikli bir modele doğru ilerledi. Varsayılan akış kullanıcıları Kong hesabı oluşturmaya ve projeleri bulutta saklamaya yönlendirdi. Önceki sürümlerin yerel ve çevrimdışı çalışmaya daha yakın olması nedeniyle bu değişiklik topluluğun bir kısmında tepki oluşturdu.

Daha sonraki sürümlerde sadece yerel çalışma veya “Scratch Pad” gibi seçenekler daha belirgin hale getirildi. Yine de bazı ekipler, özellikle API verilerinin şirket dışına çıkmaması gereken ortamlarda alternatif araçları değerlendirmeye başladı.

Bu senaryo sizin için geçerliyse Apidog değerlendirilebilir. Apidog; API tasarımı, hata ayıklama, mock server, test ve dokümantasyonu tek platformda birleştirir. Insomnia dışa aktarımlarını içe aktarabildiği için mevcut koleksiyonları sıfırdan oluşturmanız gerekmez.

Apidog ayrıca JavaScript yazmadan görsel assertion oluşturmayı destekler; ihtiyaç duyduğunuzda komut dosyaları da kullanabilirsiniz. API spesifikasyonu, test verileri ve mock server aynı proje içinde tutulduğunda testlerin gerçek sözleşmeden kopması daha zor olur.

Denemek için Apidog'u indirebilir ve mevcut bir Insomnia koleksiyonunu içe aktararak yan yana karşılaştırabilirsiniz. Daha fazla seçenek için ücretsiz çevrimiçi API test araçları listesine de bakabilirsiniz.

Insomnia hâlâ sade arayüzü, hızlı başlangıcı ve odaklı istemci deneyimiyle tek geliştiriciler ve küçük ekipler için güçlü bir seçenektir. Doğru araç seçimi, ekibinizin API yaşam döngüsünün ne kadarını tek yerde yönetmek istediğine bağlıdır.

Sıkça sorulan sorular

Insomnia ücretsiz mi?

Evet. Insomnia'nın bireysel kullanım için yeterli olan ücretsiz bir katmanı vardır. İstek gönderme ve test paketlerini yerel olarak çalıştırma gibi temel özellikleri kullanabilirsiniz. Ücretli planlar daha çok ekip işbirliği ve bulut senkronizasyon limitleriyle ilgilidir.

Insomnia hangi protokolleri destekler?

Insomnia HTTP, REST, GraphQL, gRPC, SOAP ve WebSocket destekler. İstek yapılandırması protokole göre değişebilir; ancak yanıt inceleme ve HTTP tabanlı test akışları benzer şekilde çalışır.

Insomnia'da assertion nasıl yazılır?

Koleksiyonda Tests görünümünü açın, bir test paketi oluşturun ve JavaScript testleri ekleyin. Test içinde insomnia.send() ile isteği çalıştırın, ardından Chai tarzı expect ifadeleriyle durum kodunu, header'ları veya gövde alanlarını kontrol edin.

const response = await insomnia.send();
const body = JSON.parse(response.data);

expect(response.status).to.equal(200);
expect(body).to.have.property("id");

Insomnia 8'de ne değişti?

Insomnia 8, bulut öncelikli bir varsayılan modele geçti ve kullanıcıları Kong hesabıyla oturum açmaya ve projeleri buluta senkronize etmeye yönlendirdi. Bu değişiklik, tamamen yerel çalışmayı tercih eden bazı kullanıcılar tarafından olumsuz karşılandı. Sonraki güncellemelerde yerel çalışma seçenekleri daha görünür hale getirildi.

Insomnia testlerini CI hattında çalıştırabilir miyim?

Evet. Inso komut satırı aracını kullanabilirsiniz. Koleksiyonunuzu dışa aktarın veya senkronize edin, ardından CI hattınızda şu komutu çalıştırın:

inso run test "<paket adı>"

Testlerden biri başarısız olursa Inso sıfır olmayan exit code döndürür ve CI derlemesi otomatik olarak başarısız olabilir.

Pytest API Otomatik Test Framework'ü: Uygulamalı Eğitim

Tobias Hoffmann — Fri, 22 May 2026 07:35:40 +0000

Python geliştiricileri pytest'i tercih eder çünkü API testlerini az kalıp kodla yazmayı sağlar: test fonksiyonu test_ ile başlar, doğrulama için düz assert kullanılır ve çalıştırmayı pytest yönetir. requests ile birlikte kullandığınızda, API testleri için pratik, kod-öncelikli ve otomasyona uygun bir temel elde edersiniz.

Apidog'u bugün deneyin

Bu rehberde gerçekçi bir pytest API test paketi kuracağız. Projeyi hazırlayacak, ilk istek testini yazacak, ortak kurulumu fixture'lara taşıyacak, parametrize ile aynı testi farklı girdilerle çalıştıracak ve yanıt durumunu, gövdesini ve JSON Şemasını doğrulayacağız.

Projenin Kurulumu

Önce sanal ortam oluşturun ve gerekli paketleri yükleyin:

python -m venv .venv
source .venv/bin/activate
pip install pytest requests jsonschema

Windows kullanıyorsanız aktivasyon komutu şu şekilde olur:

.venv\Scripts\activate

Basit ve sürdürülebilir bir klasör yapısı kullanın:

api-tests/
  conftest.py        # ortak fixture'lar
  test_users.py      # users endpoint testleri
  test_orders.py     # orders endpoint testleri
  pytest.ini         # pytest yapılandırması

Pytest testleri otomatik keşfeder. Şu kurallara uymanız yeterlidir:

Test dosyaları test_ ile başlamalı veya _test.py ile bitmelidir.
Test fonksiyonları test_ ile başlamalıdır.
Test sınıfları Test ile başlamalı ve __init__ içermemelidir.

Örnek pytest.ini:

[pytest]
testpaths = .
python_files = test_*.py *_test.py
python_functions = test_*
addopts = -v

Otomatik test disiplini sizin için yeniyse, otomatik testin ne olduğu hakkındaki başlangıç rehberi iyi bir bağlam sağlar.

API testi için pytest kullanmanın pratik nedeni şudur: requests HTTP isteklerini yönetir, pytest ise test keşfi, okunabilir hata çıktısı, fixture tabanlı kurulum, veri odaklı testler ve raporlama tarafını çözer. Testler uygulama koduyla aynı depoda yaşadığında, API değişiklikleri ve bozulan testler aynı pull request içinde görünür hale gelir.

İlk API Testinizi Yazma

Bir pytest API testi genellikle üç adımdan oluşur:

HTTP isteği gönder.
Yanıtı parse et.
Durum kodunu ve gövdeyi doğrula.

Örnek:

import requests

BASE_URL = "https://api.example.com/v1"

def test_get_user_returns_200():
    response = requests.get(f"{BASE_URL}/users/42")

    assert response.status_code == 200

def test_get_user_returns_expected_fields():
    response = requests.get(f"{BASE_URL}/users/42")
    body = response.json()

    assert body["id"] == 42
    assert "email" in body
    assert body["status"] == "active"

Testleri çalıştırın:

pytest -v

Başarısız bir assert, beklenen ve gerçek değerleri okunabilir şekilde gösterir. Özel assertion helper'ları yazmanız gerekmez; pytest düz assert ifadelerini zengin hata çıktısı üretecek şekilde işler.

API yanıtlarında kontrol etmeniz gereken alanlar hakkında daha fazla örnek için API doğrulamaları rehberine bakabilirsiniz.

Kurulumu Fixture'lar ile Paylaşma

Her testte BASE_URL, header veya HTTP session tekrar etmek sürdürülebilir değildir. Bu tür ortak kurulumu fixture'a taşıyın.

conftest.py dosyası, tüm test dosyaları tarafından otomatik kullanılabilir:

# conftest.py
import pytest
import requests

BASE_URL = "https://api.example.com/v1"

@pytest.fixture(scope="session")
def api_session():
    session = requests.Session()
    session.headers.update({"Accept": "application/json"})

    yield session

    session.close()

@pytest.fixture
def auth_token(api_session):
    response = api_session.post(
        f"{BASE_URL}/auth/login",
        json={
            "email": "qa@example.com",
            "password": "test-pass",
        },
    )

    assert response.status_code == 200

    return response.json()["token"]

Burada:

scope="session" session nesnesinin tüm test çalıştırması boyunca bir kez oluşturulmasını sağlar.
yield öncesi kurulum, sonrası temizlik adımıdır.
auth_token, ihtiyaç duyan testlere token sağlar.

Test içinde fixture'ları parametre olarak çağırmanız yeterlidir:

def test_create_order(api_session, auth_token):
    response = api_session.post(
        f"{BASE_URL}/orders",
        headers={"Authorization": f"Bearer {auth_token}"},
        json={
            "product_id": 7,
            "quantity": 2,
        },
    )

    assert response.status_code == 201
    assert response.json()["status"] == "pending"

Fixture'lar, setup_function ve teardown_function yaklaşımına göre daha esnektir. Bağımlılıkları açık hale getirir, farklı kapsamları destekler ve kolayca birleştirilebilir. Detaylar için resmi pytest fixture'lar dokümantasyonu incelenebilir.

Bir Testi Birçok Girdiyle Çalıştırma

API endpoint'leri genellikle farklı girdilerle test edilmelidir:

Geçerli değerler
Geçersiz değerler
Sınır değerler
Bulunamayan kaynaklar

Aynı test fonksiyonunu farklı girdilerle çalıştırmak için @pytest.mark.parametrize kullanın:

import pytest

BASE_URL = "https://api.example.com/v1"

@pytest.mark.parametrize(
    "user_id, expected_status",
    [
        (42, 200),
        (99999, 404),
        (0, 404),
        (-1, 400),
    ],
)
def test_get_user_status_codes(api_session, user_id, expected_status):
    response = api_session.get(f"{BASE_URL}/users/{user_id}")

    assert response.status_code == expected_status

Bu tek fonksiyon dört ayrı test case üretir. Her biri bağımsız raporlanır; bir girdinin başarısız olması diğerlerini gizlemez.

Girdi seti büyüdüğünde test verisini CSV veya JSON dosyasından yüklemek daha okunabilir olabilir. Bu desen için CSV ve JSON ile veri odaklı API testi rehberine bakabilirsiniz.

Beklenen durum kodlarını seçerken tutarlı olmak için REST API'lerinin kullanması gereken HTTP durum kodları referansı da yararlıdır.

Yanıt Gövdesi ve Şeması Üzerine Doğrulama

Durum kodu tek başına yeterli değildir. 200 OK dönen ama eksik veya hatalı gövde içeren bir yanıt hâlâ hatadır.

Örnek gövde doğrulaması:

def test_order_response_shape(api_session, auth_token):
    response = api_session.post(
        f"{BASE_URL}/orders",
        headers={"Authorization": f"Bearer {auth_token}"},
        json={
            "product_id": 7,
            "quantity": 2,
        },
    )

    body = response.json()

    assert response.status_code == 201
    assert isinstance(body["id"], int)
    assert body["quantity"] == 2
    assert body["total"] > 0
    assert response.elapsed.total_seconds() < 1.0

Bu test şunları kontrol eder:

Yanıtın başarılı oluşturma kodu dönmesi
id alanının integer olması
quantity değerinin istekle uyumlu olması
total değerinin pozitif olması
Yanıt süresinin belirlenen sınırın altında kalması

Daha güçlü yapısal kontrol için JSON Şeması kullanın:

from jsonschema import validate

order_schema = {
    "type": "object",
    "required": ["id", "product_id", "quantity", "status", "total"],
    "properties": {
        "id": {"type": "integer"},
        "product_id": {"type": "integer"},
        "quantity": {"type": "integer", "minimum": 1},
        "status": {"type": "string"},
        "total": {"type": "number"},
    },
}

def test_order_matches_schema(api_session, auth_token):
    response = api_session.post(
        f"{BASE_URL}/orders",
        headers={"Authorization": f"Bearer {auth_token}"},
        json={
            "product_id": 7,
            "quantity": 2,
        },
    )

    assert response.status_code == 201

    validate(instance=response.json(), schema=order_schema)

Şema doğrulaması, tek tek alan kontrolüne göre daha iyi ölçeklenir. Eksik alan, yeniden adlandırılmış alan veya yanlış veri tipi gibi sözleşme bozulmalarını daha erken yakalar.

jsonschema kullanımı için doğrulama dokümantasyonu desteklenen anahtar kelimeleri açıklar.

Paketi CI'da Çalıştırma

Pytest başarısız testlerde sıfır olmayan çıkış kodu döndürür. Bu, CI sisteminin build'i başarısız sayması için yeterlidir.

JUnit raporu üretmek için:

pytest -v --junitxml=results.xml

Bu komutu GitHub Actions, GitLab CI veya başka bir pipeline adımına ekleyebilirsiniz.

Örnek GitHub Actions adımı:

name: API Tests

on:
  push:
  pull_request:

jobs:
  api-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install pytest requests jsonschema

      - name: Run API tests
        env:
          API_BASE_URL: https://staging.example.com/v1
        run: |
          pytest -v --junitxml=results.xml

CI/CD kurulumu, secret enjeksiyonu ve ortam seçimi için CI/CD pipeline'larındaki API testleri rehberine bakabilirsiniz.

Ortam Değişkeni Kullanın

Token, parola veya ortam URL'sini test dosyalarına sabit kodlamayın. Bunun yerine ortam değişkeni okuyun:

import os

BASE_URL = os.environ.get("API_BASE_URL", "https://staging.example.com/v1")

Token için de aynı yaklaşımı kullanın:

AUTH_TOKEN = os.environ["API_AUTH_TOKEN"]

Bu sayede aynı test paketi:

Yerelde
Staging ortamında
CI pipeline içinde

kod değişikliği yapmadan çalışabilir.

Paralel Çalıştırmayı Düşünün

Testler bağımsızsa pytest-xdist ile paralel çalıştırabilirsiniz:

pip install pytest-xdist
pytest -n auto

pytest -n auto, testleri CPU çekirdeklerine dağıtır. Ancak paralel çalışma için testlerinizin ortak duruma bağımlı olmaması gerekir. Çalıştırma sırasına bağlı testler paralel ortamda kararsız şekilde başarısız olur.

Bir pytest Paketini Sürdürülebilir Tutmak

Küçük bir test paketi kolay yönetilir. Paket büyüdükçe yapılandırma ve organizasyon önem kazanır.

Testleri Modüllere Ayırın

Endpoint veya domain bazlı dosyalar kullanın:

test_users.py
test_orders.py
test_payments.py
test_auth.py

Sınıfları yalnızca gerçekten ortak kurulum paylaşıyorsanız kullanın. Sadece gruplama amacıyla sınıf eklemek genellikle gereksizdir.

Marker Kullanın

pytest.ini içinde marker'ları kaydedin:

[pytest]
markers =
    smoke: hızlı temel kontroller
    slow: uzun süren testler

Testlerde kullanın:

import pytest

@pytest.mark.smoke
def test_get_user_returns_200(api_session):
    response = api_session.get(f"{BASE_URL}/users/42")

    assert response.status_code == 200

Alt küme çalıştırmak için:

pytest -m smoke
pytest -m "not slow"

Pratik bir CI stratejisi:

Her commit'te smoke testleri çalıştırın.
Gecelik pipeline'da tam paketi çalıştırın.

Yapılandırmayı Merkezileştirin

Temel URL'ler, ortak header'lar, şemalar ve fixture'lar tek yerde durmalıdır:

conftest.py
config.py
schemas/
helpers/

Aynı kodu ikinci kez yazıyorsanız, fixture veya yardımcı fonksiyona taşıyın. Bu modüler yaklaşım, otomatik test betikleri yazma rehberinde anlatılan disiplinle aynıdır.

Bunun Yerine Ne Zaman Bir Platforma Başvurmalı

Pytest, ekibiniz Python yazıyorsa ve testlerin uygulama koduyla aynı depoda yaşamasını istiyorsanız güçlü bir seçenektir.

Ancak şu durumlarda tek başına pytest daha fazla bakım gerektirebilir:

QA veya ürün ekibi kod yazmadan test katkısı yapmak istiyorsa
Test tasarımı, mocking ve yürütme tek yerde yönetilmek isteniyorsa
OpenAPI sözleşmesine göre otomatik şema doğrulaması merkezi bir ihtiyaçsa
Veri odaklı testleri arayüz üzerinden yönetmek daha pratikse

Apidog bu boşluğu kapatır. Görsel test oluşturma, OpenAPI spesifikasyonuna karşı şema doğrulaması, CSV ve JSON'dan veri odaklı çalıştırmalar ve CI için CLI çalıştırıcısı sunar; bunlar fixture ve doğrulama kodunu manuel yazmadan yapılabilir.

Birçok ekip iki yaklaşımı birlikte kullanır:

Mantık ağırlıklı, kodla sıkı bağlı senaryolar için pytest
Daha geniş kapsam, API tasarımı, mocking ve sözleşme doğrulaması için Apidog

Apidog'u indirebilir ve aynı endpoint üzerinde iki yaklaşımı karşılaştırabilirsiniz.

Sıkça Sorulan Sorular

API Testi İçin Python'ın Yerleşik unittest'i Yerine Neden pytest Kullanılmalı?

Pytest daha az kalıp kod gerektirir. Testler düz fonksiyonlardır, doğrulamalar düz assert ifadeleridir ve fixture'lar kurulumu unittest sınıf metotlarından daha esnek şekilde yönetir.

Ayrıca pytest:

Geniş eklenti ekosistemine sahiptir.
parametrize ile veri odaklı testleri yerleşik destekler.
Mevcut unittest tarzı testleri de çalıştırabilir.

Bu nedenle geçiş riski düşüktür.

Fixture ve Parametrize Arasındaki Fark Nedir?

Fixture, yeniden kullanılabilir kaynak sağlar:

HTTP session
Auth token
Test verisi
Geçici kaynak oluşturma/temizleme

parametrize ise aynı test gövdesini farklı girdilerle birden fazla kez çalıştırır.

Kısa fark:

Fixture kurulumu paylaşır.
Parametrize test senaryolarını çoğaltır.

Birlikte de kullanılabilirler:

@pytest.mark.parametrize("user_id", [1, 2, 3])
def test_get_user(api_session, user_id):
    response = api_session.get(f"{BASE_URL}/users/{user_id}")

    assert response.status_code == 200

Pytest API Testlerinde Yanıt Süresini Doğrulamalı mıyım?

Evet, temel regresyonları yakalamak için kullanabilirsiniz:

assert response.elapsed.total_seconds() < 1.0

Ancak pytest bir yük testi aracı değildir. Gerçek performans veya kapasite testi için özel yük testi araçları kullanılmalıdır.

Zamanlama doğrulamalarını çok sıkı yazmayın. Ağ değişkenliği, aksi halde kararsız testlere neden olabilir.

Pytest'te API Testlerini Nasıl Bağımsız Tutarım?

Her test kendi verisini oluşturmalı ve gerekiyorsa temizlemelidir. Bunu fixture'larla yapabilirsiniz:

@pytest.fixture
def created_order(api_session, auth_token):
    response = api_session.post(
        f"{BASE_URL}/orders",
        headers={"Authorization": f"Bearer {auth_token}"},
        json={"product_id": 7, "quantity": 2},
    )

    order = response.json()

    yield order

    api_session.delete(
        f"{BASE_URL}/orders/{order['id']}",
        headers={"Authorization": f"Bearer {auth_token}"},
    )

Test yürütme sırasına güvenmeyin. Bağımsız testler paralel çalışabilir, izole başarısız olur ve hata ayıklaması daha kolaydır.

Pytest Yanıtları Bir OpenAPI Spesifikasyonuna Göre Doğrulayabilir mi?

Pytest bunu tek başına yapmaz. Ancak jsonschema ile JSON Şeması doğrulaması yapabilirsiniz ve OpenAPI belgesine göre yanıt kontrol eden eklentiler de mevcuttur.

Şema doğrulaması iş akışınızın merkezindeyse, OpenAPI spesifikasyonuna karşı otomatik doğrulama yapan Apidog gibi bir platform eklenti ve bakım yükünü azaltabilir.

Postman ve JMeter Arasındaki Farklar

Tobias Hoffmann — Fri, 22 May 2026 07:35:12 +0000

İ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:

Endpoint 200 OK dönüyor mu?
Yanıt içinde id alanı var mı?
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:

Yüzdelik dilim gecikmeleri
Throughput
Hata oranı
Eşzamanlı kullanıcı sayısı
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:

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:

İşlevsel testler: API doğru yanıt veriyor mu?
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.

Postman ile API Testi Nasıl Yapılır: Uygulamalı Rehber

Tobias Hoffmann — Fri, 22 May 2026 07:31:08 +0000

Postman, HTTP istekleri göndermek ve bir API'nin davranışını doğrulamak için en yaygın kullanılan araçlardan biridir. Hızlı bir GET isteğinden CI’da çalışan test paketlerine kadar birçok API test senaryosunu destekler. API geliştiriyor veya tüketiyorsanız, Postman’i günlük iş akışınızda pratik bir test aracı olarak kullanabilirsiniz.

Apidog'u bugün deneyin

Bu kılavuzda Postman ile bir API’yi adım adım test edeceksiniz: istek gönderecek, yanıtı inceleyecek, Testler/Betrikler alanında assertion yazacak, ortam değişkenleriyle staging ve production arasında geçiş yapacak ve Collection Runner ile tüm koleksiyonu çalıştıracaksınız. Örneklerde herkese açık JSONPlaceholder API’si kullanıldığı için ön kurulum yapmadan takip edebilirsiniz.

Postman’i Kurun ve İlk İsteğinizi Gönderin

Postman’i resmi siteden indirin ve masaüstü uygulamasını yükleyin. Yerel kullanım için hesap zorunlu değildir; ancak oturum açarsanız koleksiyonlarınızı cihazlar arasında senkronize edebilirsiniz.

İlk isteği oluşturmak için:

Postman’i açın.
New / Yeni düğmesine tıklayın.
HTTP Request / HTTP İsteği seçeneğini seçin.
Metodu GET olarak bırakın.
Aşağıdaki URL’yi girin:

GET https://jsonplaceholder.typicode.com/users/1

Ardından Send / Gönder düğmesine tıklayın.

Yanıt panelinde şunları kontrol edin:

Durum kodu: 200 OK
Yanıt süresi
Yanıt boyutu
JSON response body

JSON’u daha okunabilir görmek için gövde görünümünü Pretty, Raw veya Preview arasında değiştirebilirsiniz.

Bir POST isteği denemek için:

Metodu POST yapın.
Body / Gövde sekmesine geçin.
raw seçeneğini seçin.
Formatı JSON olarak ayarlayın.
Aşağıdaki gövdeyi ekleyin:

{
  "name": "Maria Chen",
  "email": "maria.chen@example.com"
}

JSON gövde tipi seçildiğinde Postman genellikle Content-Type: application/json başlığını otomatik ekler. Gerekirse Headers / Başlıklar sekmesinden Authorization, Accept veya özel header’lar ekleyebilirsiniz.

HTTP durum kodlarını nasıl yorumlamanız gerektiğinden emin değilseniz, REST API’lerinin kullanması gereken HTTP durum kodları rehberine bakabilirsiniz.

İstekleri Koleksiyonlar Halinde Düzenleyin

Tek bir istek hızlı kontrol için yeterlidir. Ancak gerçek API testi genellikle birden fazla isteği kapsar:

Kullanıcı oluşturma
Kullanıcıyı getirme
Kullanıcıyı güncelleme
Kullanıcıyı silme

Postman’de bu istekleri Collection / Koleksiyon altında gruplandırabilirsiniz.

Koleksiyon oluşturmak için:

Sol menüden Collections / Koleksiyonlar sekmesine gidin.
+ simgesine tıklayın.
Koleksiyona açıklayıcı bir ad verin, örneğin: Kullanıcı API duman testleri.
Her isteği Ctrl/Cmd + S ile bu koleksiyona kaydedin.
İstekleri anlamlı adlarla kaydedin:
- Kullanıcı getir
- Kullanıcı oluştur
- Kullanıcı güncelle
- Kullanıcı sil

Daha düzenli bir yapı için koleksiyon içinde klasörler kullanabilirsiniz:

Kullanıcı API duman testleri
├── Auth
│   └── Login
├── Users
│   ├── Get user
│   ├── Create user
│   ├── Update user
│   └── Delete user

Koleksiyonlar aynı zamanda paylaşım birimidir. Bir koleksiyonu JSON olarak dışa aktarabilir veya Postman Cloud kullanıyorsanız bağlantı üzerinden paylaşabilirsiniz. Ekip arkadaşlarınız koleksiyonu içe aktardığında sizinle aynı istekleri, değişkenleri ve testleri kullanabilir.

Koleksiyon düzeyinde ortak davranışlar da tanımlayabilirsiniz:

Pre-request Script / Ön istek betiği: Koleksiyondaki her istekten önce çalışır.
Tests / Test betiği: Koleksiyondaki her istekten sonra çalışır.

Örneğin tüm istekler için ortak response time kontrolü ekleyebilirsiniz:

pm.test("Response time is acceptable", function () {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});

Bu yaklaşım, aynı assertion’ı her isteğe tek tek yazmanızı engeller.

Testler Sekmesinde Assertion Yazın

Bir istek göndermek, API’nin ne döndürdüğünü gösterir. Assertion ise dönen yanıtın doğru olup olmadığını otomatik doğrular.

Postman, yanıt geldikten sonra JavaScript çalıştırır. Yeni sürümlerde bu alan genellikle Scripts / Betikler altında bulunur; eski sürümlerde Tests / Testler sekmesi olarak geçer.

Temel yapı şöyledir:

pm.test("Test adı", function () {
    // assertion
});

Sık kullanılan assertion örnekleri:

// Durum kodunu kontrol edin
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

// Yanıt süresini kontrol edin
pm.test("Response is under 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

// JSON gövdesindeki bir alanı kontrol edin
pm.test("User has the expected email", function () {
    const body = pm.response.json();
    pm.expect(body.email).to.eql("maria.chen@example.com");
});

// Bir başlığı kontrol edin
pm.test("Content-Type is JSON", function () {
    pm.expect(pm.response.headers.get("Content-Type"))
      .to.include("application/json");
});

Postman’in assertion sözdizimi Chai tabanlıdır. Bu nedenle aşağıdaki ifadeleri kullanabilirsiniz:

pm.expect(value).to.eql(expectedValue);
pm.expect(value).to.include("text");
pm.expect(value).to.be.above(10);
pm.expect(value).to.be.below(500);
pm.expect(value).to.exist;

Assertion yazarken şu pratik kuralları kullanın:

Her pm.test bloğunu tek bir beklentiye odaklayın.
Test adını davranışa göre verin, örneğin: User email is returned.
Sadece istemciyi gerçekten etkileyen alanları kontrol edin.
Rastgele veya sunucu tarafından üretilen değerlerde katı assertion yazmaktan kaçının.
Önce durum kodunu, sonra response body yapısını doğrulayın.

Örnek response body kontrolü:

pm.test("User response has required fields", function () {
    const body = pm.response.json();

    pm.expect(body).to.have.property("id");
    pm.expect(body).to.have.property("name");
    pm.expect(body).to.have.property("email");
});

Postman editörünün yanındaki Snippets / Kod Parçacıkları paneli, sık kullanılan test kalıplarını hızlıca eklemek için kullanışlıdır.

Assertion tasarımı hakkında daha detaylı bilgi için API onaylamalarının nasıl iyi yazılacağına dair rehbere bakabilirsiniz. Testleri senaryo bazlı yapılandırmak istiyorsanız API test senaryosu örneği rehberi de faydalıdır.

Ortamları ve Değişkenleri Kullanın

API URL’lerini her isteğe sabit yazmak bakım maliyeti oluşturur. Örneğin staging ortamından production ortamına geçerken tüm URL’leri tek tek değiştirmeniz gerekir.

Bunun yerine Postman Environment / Ortam değişkenlerini kullanın.

Örnek ortam değişkeni:

base_url = https://jsonplaceholder.typicode.com

Ortam oluşturmak için:

Sol menüden Environments / Ortamlar bölümüne gidin.
Hazırlık adında bir ortam oluşturun.
base_url değişkenini ekleyin.
Değer olarak şunu girin:

https://jsonplaceholder.typicode.com

Artık isteği şöyle yazabilirsiniz:

GET {{base_url}}/users/1

Sağ üstteki ortam seçicisinden aktif ortamı değiştirdiğinizde {{base_url}} kullanan tüm istekler otomatik olarak yeni hedefe gider.

Değişkenler, istekler arasında veri taşımak için de kullanılır. Örneğin login isteğinden dönen token’ı kaydedebilirsiniz:

pm.test("Kimlik doğrulama jetonunu kaydet", function () {
    const token = pm.response.json().token;
    pm.environment.set("auth_token", token);
});

Sonraki isteklerde bu token’ı header olarak kullanabilirsiniz:

Authorization: Bearer {{auth_token}}

Postman’de sık kullanılan değişken kapsamları:

Kapsam	Kullanım
Environment variables	Staging, production, local gibi ortama göre değişen değerler
Collection variables	Belirli bir koleksiyona ait sabit değerler
Global variables	Tüm workspace genelinde geçerli değerler
Local variables	Sadece mevcut çalıştırma sırasında kullanılan geçici değerler

Pratik öneri:

base_url, auth_token gibi hedefe göre değişen değerleri environment değişkeni yapın.
API’ye özgü ama ortamdan bağımsız değerleri collection değişkeni yapın.
Global değişkenleri sınırlı kullanın; aksi halde farklı koleksiyonlar arasında beklenmeyen çakışmalar oluşabilir.

Tüm Koleksiyonu Collection Runner ile Çalıştırın

Her isteği tek tek Send / Gönder ile çalıştırmak küçük kontroller için yeterlidir. Ancak regresyon testi için tüm koleksiyonu sırayla çalıştırmanız gerekir.

Bunun için Collection Runner kullanılır.

Collection Runner ile çalıştırmak için:

Koleksiyonu açın.
Run / Çalıştır düğmesine tıklayın.
Çalıştırılacak istekleri kontrol edin.
Ortamı seçin.
Iteration sayısını belirleyin.
Gerekirse CSV veya JSON veri dosyası ekleyin.
Run düğmesine tıklayın.

Postman istekleri yukarıdan aşağıya çalıştırır ve her isteğin testlerini yürütür.

Sonuç ekranında şunları görürsünüz:

Başarılı assertion sayısı
Başarısız assertion sayısı
Hangi istekte neyin bozulduğu
Response time bilgileri
Önceki çalıştırmalarla karşılaştırılabilecek run geçmişi

Sıralama önemlidir. Örneğin token gerektiren bir akışta koleksiyonu şöyle düzenleyin:

1. Login
2. Kullanıcı oluştur
3. Kullanıcı getir
4. Kullanıcı güncelle
5. Kullanıcı sil

Login isteği önce çalışır ve auth_token değişkenini doldurur. Alttaki istekler aynı token’ı kullanır.

Veri odaklı test için CSV veya JSON dosyası ekleyebilirsiniz. Örneğin login testi için CSV:

username,password,expected_status
valid@example.com,correct-password,200
wrong@example.com,bad-password,401
empty@example.com,,400

Test içinde beklenen durum kodunu veri dosyasından okuyabilirsiniz:

pm.test("Status code matches expected status", function () {
    pm.response.to.have.status(Number(pm.iterationData.get("expected_status")));
});

Bu yöntemle aynı isteği kopyalamadan farklı girdi kombinasyonlarını test edebilirsiniz.

Veri odaklı API testi hakkında daha fazla örnek için CSV ve JSON ile veri odaklı API testi rehberine bakabilirsiniz. Aynı koleksiyonu GUI olmadan CI’da çalıştırmak için Postman’in Newman komut satırı aracı kullanılır; detaylar Newman ile Postman karşılaştırmasında açıklanmıştır.

Postman’in Ağırlaştığı Noktalar

Postman, keşifsel testler ve küçük-orta ölçekli test paketleri için güçlü bir araçtır. Ancak proje büyüdükçe iki yaygın sorun ortaya çıkar.

İlk sorun, otomatik assertion’ların JavaScript ile yazılmasıdır. Geliştiriciler için bu çoğu zaman sorun değildir; ancak görsel bir test akışı bekleyen QA ekipleri veya teknik olmayan ekip üyeleri için öğrenme eğrisi oluşturabilir.

İkinci sorun, API tasarımı, test, mock ve dokümantasyonun ayrı alanlarda yönetilmesidir. Bu durum zamanla API sözleşmesi ile testlerin birbirinden uzaklaşmasına neden olabilir.

Apidog, bu iş akışlarını tek bir platformda birleştiren bir API aracıdır. Postman koleksiyonlarını doğrudan içe aktarabilir. Assertion’lar görsel olarak oluşturulabilir; gerektiğinde betik kullanımı da desteklenir. Tasarım, hata ayıklama, mock, test ve dokümantasyon aynı kaynak üzerinden yönetildiği için API spesifikasyonu ile testler daha kolay senkron kalır.

Alternatifleri değerlendiriyorsanız API testi için Postman alternatifleri özetine bakabilirsiniz. Ayrıca Apidog’u indirebilir ve mevcut Postman koleksiyonunuzu içe aktararak doğrudan karşılaştırma yapabilirsiniz.

Bu, Postman’i bırakmanız gerektiği anlamına gelmez. Postman hâlâ hızlı kontroller, manuel testler ve mevcut yatırımı olan ekipler için sağlam bir seçenektir. Önemli olan, aracın güçlü olduğu kullanım alanını doğru belirlemektir.

Sıkça Sorulan Sorular

Postman’de API’leri test etmek için kod yazmam gerekiyor mu?

İstek göndermek ve yanıtları incelemek için hayır. Ancak otomatik assertion yazmak için genellikle biraz JavaScript gerekir. Postman’in testleri pm nesnesi üzerinden çalışır. Hazır kod parçacıklarını kullanarak hızlı başlayabilirsiniz; fakat yine de temel JavaScript bilgisi faydalıdır. Kodsuz, görsel assertion oluşturmak istiyorsanız Apidog gibi araçları değerlendirebilirsiniz.

Bir Postman koleksiyonu ile ortam arasındaki fark nedir?

Koleksiyon, gruplanmış API isteklerini ve testlerini tutar. Ortam ise base_url, auth_token veya client_id gibi değişkenleri tutar. Aynı koleksiyonu farklı ortamlarla çalıştırarak staging, production veya local API’leri test edebilirsiniz.

Postman testlerini CI’da otomatik olarak nasıl çalıştırırım?

Postman’in komut satırı çalıştırıcısı Newman’ı kullanabilirsiniz. Koleksiyonunuzu ve ortamınızı dışa aktarın, ardından şu komutu çalıştırın:

newman run collection.json -e environment.json

Herhangi bir test başarısız olursa Newman sıfır olmayan exit code döndürür. CI hattınız bu sonucu kullanarak build’i başarısız sayabilir. Daha detaylı akış için CI/CD’de API testlerini otomatikleştirme rehberine bakabilirsiniz.

Postman REST API’lerinden fazlasını test edebilir mi?

Evet. Postman, HTTP ve REST dışında GraphQL, gRPC, WebSocket ve SOAP isteklerini de destekler. Assertion mantığı çoğu senaryoda kullanılabilir; ancak istek yapılandırması protokole göre değişir.

Bir istekte kaç assertion olmalı?

Yanıtın doğru olduğunu doğrulamaya yetecek kadar assertion yazın, ancak tek bir küçük değişikliğin onlarca testi bozmasına neden olacak kadar aşırıya kaçmayın. İyi bir başlangıç noktası:

Durum kodu
Yanıt süresi
Response body’de zorunlu alanlar
İstemcinin bağımlı olduğu 2-3 kritik değer

Her pm.test bloğunu tek bir beklentiye odaklayın. Böylece test kırıldığında hangi davranışın bozulduğunu hızlıca anlarsınız.

SoapUI Nedir? API Test Aracı Pratik Rehberi

Tobias Hoffmann — Fri, 22 May 2026 07:30:03 +0000

SoapUI, web hizmetlerini ve API'leri test etmek için kullanılan açık kaynaklı bir araçtır. 2005 yılında SOAP hizmetlerini test etmek amacıyla ortaya çıktı ve zamanla REST, GraphQL, JMS ve JDBC desteği ekledi. Bugün hâlâ özellikle WSDL tabanlı SOAP entegrasyonlarını sürdüren kurumsal KG ekipleri için pratik bir test aracıdır.

Apidog'u bugün deneyin

Yalnızca JSON REST API'leriyle çalıştıysanız SoapUI eski görünebilir. Ancak WSDL içe aktarma, SOAP zarfı üretme, XML doğrulama ve XPath/XQuery tabanlı kontroller gibi konularda hâlâ güçlüdür. Bankacılık, sigorta, kamu, sağlık ve telekom gibi alanlarda SOAP servisleri yaşamaya devam ettiği için SoapUI da bu nişte geçerliliğini korur.

Bu yazıda SoapUI'ın ne işe yaradığını, tipik bir test akışını, hangi durumlarda doğru seçim olduğunu ve modern REST/GraphQL ekipleri için nerede sınırlı kaldığını uygulama odaklı şekilde ele alacağız.

SoapUI aslında ne işe yarar?

SoapUI, uygulama kodu yazmadan API istekleri oluşturmanızı, göndermenizi ve doğrulamanızı sağlayan bir masaüstü uygulamasıdır. Temel akış şöyledir:

Bir servis tanımı içe aktarılır.
SoapUI bu tanımdan istek şablonları oluşturur.
İstekler test adımlarına dönüştürülür.
Yanıtlar assertion’larla doğrulanır.
Test senaryoları paketler halinde çalıştırılır.

SoapUI'ın en belirgin gücü WSDL içe aktarmadır. WSDL, bir SOAP servisinin operasyonlarını, mesaj formatlarını ve veri tiplerini tanımlayan XML belgesidir. SoapUI'a bir WSDL URL'si verdiğinizde her operasyon için uygun SOAP envelope yapısını otomatik oluşturur.

Örneğin elle yazmanız gereken tipik bir SOAP isteği şu yapıya benzer:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:ser="http://example.com/service">
   <soapenv:Header/>
   <soapenv:Body>
      <ser:GetCustomer>
         <ser:customerId>12345</ser:customerId>
      </ser:GetCustomer>
   </soapenv:Body>
</soapenv:Envelope>

WSDL içe aktarma sayesinde SoapUI bu iskeleti sizin için üretir. Siz yalnızca test verilerini girer, gerekli header’ları ekler ve doğrulamaları tanımlarsınız.

REST tarafında SoapUI, OpenAPI ve WADL tanımlarını içe aktarabilir. Yöntem, URL, parametre, header ve body ile istekler oluşturabilirsiniz. Bu nedenle SOAP’tan REST’e geçiş yapan ekiplerde aynı proje içinde iki API stilini birlikte test etmek mümkündür.

SoapUI iki sürümle gelir:

SoapUI Open Source: Ücretsizdir ve temel fonksiyonel testleri kapsar.
ReadyAPI: SmartBear'ın ticari ürünüdür; yük testi, güvenlik taraması, veri odaklı testler ve daha gelişmiş arayüz özellikleri ekler.

Bu yazıda odak, ücretsiz açık kaynak SoapUI sürümüdür.

Temel özellikler

SoapUI test yapısını şu hiyerarşiyle kurar:

Project
└── Test Suite
    └── Test Case
        └── Test Step

1. Projeler

Bir proje, tek bir servis veya ilişkili servis grubu için istekleri, test paketlerini ve yapılandırmaları içerir. Ekip içinde paylaşacağınız ana dosya genellikle bu projedir.

Pratik kullanım:

Her servis ailesi için ayrı proje oluşturun.
Ortam değişkenlerini proje seviyesinde saklayın.
Prod, test ve staging endpoint’lerini ayrı property olarak yönetin.

Örnek property yaklaşımı:

baseUrl = https://test.example.com
username = test-user
password = secret

İstek URL’sinde bu property şöyle kullanılabilir:

${#Project#baseUrl}/customers

2. Fonksiyonel test paketleri

Bir test suite içinde birden fazla test case bulunur. Her test case, sıralı test adımlarından oluşur.

Örnek test case:

Login
Extract Token
Create Customer
Get Customer
Assert Customer Data

Bu yapı, stateful API akışlarını test etmek için kullanışlıdır. Örneğin önce oturum açar, dönen token’ı alır ve sonraki isteklere eklersiniz.

3. Doğrulamalar

SoapUI, yanıtları kod yazmadan doğrulamak için birçok assertion sunar:

HTTP status code kontrolü
XPath eşleşmesi
XQuery eşleşmesi
JSONPath kontrolü
XML schema uyumluluğu
Yanıt süresi SLA kontrolü
İçerik var/yok kontrolü

Örnek XPath doğrulaması:

//customer/status/text() = 'ACTIVE'

Örnek JSONPath doğrulaması:

$.customer.status

Beklenen değer:

ACTIVE

API doğrulama yaklaşımını daha detaylı incelemek için API doğrulamaları rehberine bakabilirsiniz.

4. Özellik aktarımı

Property Transfer adımı, bir yanıttan değer alıp sonraki istekte kullanmanızı sağlar.

Tipik örnek:

Login isteği gönderilir.
Yanıttan sessionId alınır.
Bu değer proje veya test case property’sine yazılır.
Sonraki isteğin header’ında kullanılır.

Örnek kullanım:

Authorization: Bearer ${#TestCase#token}

SOAP veya REST fark etmeksizin çağrıları zincirlemek için bu mekanizma önemlidir.

5. Groovy betikleri

Yerleşik adımlar yetmediğinde SoapUI Groovy betikleri çalıştırabilir. Groovy ile:

Dinamik test verisi üretebilirsiniz.
Yanıtları özel kurallarla doğrulayabilirsiniz.
Property değerlerini işleyebilirsiniz.
Harici sistemlere çağrı yapabilirsiniz.

Örnek: Yanıttan değer okuyup test case property’sine yazmak:

def response = context.expand('${Login Request#Response}')
def holder = new com.eviware.soapui.support.XmlHolder(response)

def token = holder.getNodeValue('//token')
testRunner.testCase.setPropertyValue('token', token)

Örnek: Basit özel doğrulama:

def status = context.expand('${Get Customer#Response#//customer/status}')
assert status == 'ACTIVE'

SoapUI kodsuz testleri desteklese de karmaşık kurumsal senaryolarda Groovy bilmek pratik avantaj sağlar.

6. Sahte hizmetler

SoapUI, SOAP veya REST servis tanımından mock servis oluşturabilir. Gerçek backend hazır değilken istemci geliştirme veya entegrasyon testi için kullanılabilir.

Tipik kullanım:

WSDL içe aktarılır.
Operasyon için örnek yanıt tanımlanır.
Mock service başlatılır.
İstemci uygulama bu mock endpoint’e yönlendirilir.

Mocking stratejileri için API sahteleme kullanım senaryoları yazısına bakabilirsiniz.

Tipik bir SoapUI iş akışı

SoapUI ile yeni bir servisi test ederken uygulanabilir akış şu şekildedir.

1. Tanımdan proje oluşturun

SOAP için WSDL URL’sini, REST için OpenAPI dosyasını içe aktarın.

SOAP örneği:

File > New SOAP Project
Initial WSDL: https://example.com/customer-service?wsdl

REST/OpenAPI için:

File > New REST Project
URI or OpenAPI definition: https://example.com/openapi.json

SoapUI tanımı ayrıştırır ve operasyonları/endpoint’leri proje ağacında listeler.

2. Keşif amaçlı istek gönderin

Oluşturulan örnek isteği açın, zorunlu alanları doldurun ve gönderin.

Kontrol etmeniz gerekenler:

Endpoint doğru mu?
Kimlik doğrulama gerekli mi?
Yanıt beklenen formatta mı?
Hata mesajları anlamlı mı?
Servis dokümantasyonla uyumlu mu?

Bu aşamada henüz test otomasyonu değil, servis davranışını anlama hedeflenir.

3. Test suite ve test case oluşturun

Keşif tamamlandıktan sonra istekleri test adımlarına dönüştürün.

Örnek yapı:

CustomerService Tests
└── Create and Read Customer
    ├── Login Request
    ├── Transfer Token
    ├── Create Customer
    ├── Transfer Customer ID
    ├── Get Customer
    └── Validate Customer

Bu yapı hem SOAP hem REST için aynıdır.

4. Doğrulamalar ekleyin

Her kritik isteğe assertion ekleyin.

Minimum doğrulama seti:

Başarılı HTTP status code
Yanıt şeması
Kritik alanların varlığı
İş kuralı doğrulaması
Yanıt süresi limiti

Örnek SLA assertion:

Response SLA: 1000 ms

Örnek içerik kontrolü:

Yanıt içinde "ACTIVE" değeri bulunmalı

SOAP servislerinde XML schema ve XPath kontrolleri özellikle önemlidir.

5. Testi çalıştırın ve sonuçları inceleyin

Tek bir test case’i veya tüm test suite’i çalıştırabilirsiniz. SoapUI her adım için geçme/kalma sonucunu gösterir.

İnceleme sırasında şunlara bakın:

Hangi adım başarısız oldu?
Assertion mı hata verdi, servis mi hata döndürdü?
Önceki adımdan gelen property değeri doğru aktarıldı mı?
Ortam endpoint’i doğru mu?
Kimlik doğrulama bilgisi güncel mi?

Bu döngü, SoapUI ile sürdürülebilir test paketi oluşturmanın temelidir.

SoapUI'ın diğer araçlarla karşılaştırılması

SoapUI'ı modern REST istemcileriyle karşılaştırırken temel ayrım SOAP/XML desteği ile REST geliştirici deneyimi arasındadır.

Yön	SoapUI	Modern REST istemcileri
SOAP ve WSDL desteği	Güçlü, birinci sınıf	Zayıf veya yok
XML doğrulamaları	Kapsamlı XPath/XQuery desteği	Sınırlı
REST ve OpenAPI desteği	Yeterli	Birinci sınıf
Arayüz	Yoğun, eski	Daha akıcı ve modern
Öğrenme eğrisi	Dik	Daha yumuşak
Ücretsiz sürümde yük testi	Dahil değil	Araca göre değişir
Kurumsal SOAP testleri	Güçlü	Genellikle sınırlı
JSON REST iş akışı	Çalışır ama ağır gelebilir	Daha hızlı ve pratik

Özet net: SOAP, WSDL ve XML doğrulama öncelikliyse SoapUI güçlüdür. JSON REST, GraphQL ve hızlı geliştirici deneyimi öncelikliyse modern istemciler genellikle daha uygundur.

SoapUI ne zaman doğru seçimdir?

SoapUI şu durumlarda mantıklı bir tercihtir:

SOAP servisleri sürdürüyor ve gerçek WSDL desteğine ihtiyaç duyuyorsanız.
XML yanıtlarında XPath veya XQuery ile derin doğrulama yapmanız gerekiyorsa.
Kurumunuzda mevcut SoapUI/ReadyAPI test varlıkları varsa.
SOAP envelope, WS-Security ve XML schema doğrulaması önemliyse.
Ücretsiz fonksiyonel test aracı istiyor ve öğrenme eğrisini kabul ediyorsanız.
REST’e geçiş sürecinde hem SOAP hem REST servislerini aynı projede test etmek istiyorsanız.

Örnek karar kuralı:

Servislerinizin çoğu WSDL tabanlı SOAP ise:
    SoapUI güçlü adaydır.
Servislerinizin çoğu JSON REST veya GraphQL ise:
    Modern API platformlarını değerlendirin.

Daha geniş test yaklaşımı için otomatik testin ne olduğu yazısına bakabilirsiniz.

SoapUI'ın yetersiz kaldığı yerler

SoapUI güçlü olsa da sınırlamaları vardır.

Öğrenme eğrisi diktir

Proje, test suite, test case ve test step hiyerarşisi esnektir ancak yeni başlayanlar için sezgisel değildir. Arayüz aynı anda çok fazla seçenek gösterir.

Pratik öneri:

Önce tek bir istekle başlayın.
Sonra bunu test step’e dönüştürün.
En son property transfer ve Groovy ekleyin.
Tüm akışı baştan karmaşık kurmaya çalışmayın.

Groovy ihtiyacı hızlı ortaya çıkar

Basit doğrulamalar kodsuz yapılabilir. Ancak dinamik veri üretme, özel kontrol yazma veya karmaşık property yönetimi gerektiğinde Groovy gerekir.

Bu nedenle SoapUI “kodsuz” başlasa da ileri seviye senaryolarda betik yazmaya hazır olmalısınız.

Kaynak kullanımı ağır olabilir

SoapUI bir Java masaüstü uygulamasıdır. Büyük projeler, çok sayıda test suite ve yoğun XML yanıtları performansı etkileyebilir.

Pratik öneriler:

Büyük servis ailelerini ayrı projelere bölün.
Kullanılmayan request ve test case’leri temizleyin.
Büyük yanıtları gereksiz yere saklamayın.
Test verisini property dosyalarıyla yönetin.

Açık kaynak sürümde yük testi yoktur

SoapUI Open Source fonksiyonel testlere odaklanır. Performans ve eşzamanlılık testi ReadyAPI tarafındadır.

Performans testi alternatifleri için yazılım performans testi araçları rehberine bakabilirsiniz.

CI/CD entegrasyonu çalışır ama modern hissettirmez

SoapUI testleri komut satırından çalıştırılabilir. Örneğin genel kullanım şu şekildedir:

testrunner.sh -s"CustomerService Suite" -c"Create and Read Customer" project.xml

Windows ortamında:

testrunner.bat -s"CustomerService Suite" -c"Create and Read Customer" project.xml

CI pipeline içinde kullanılabilir, ancak deneyim baştan pipeline odaklı tasarlanmış modern araçlar kadar akıcı değildir.

REST için kullanılabilir ama en güçlü olduğu alan değildir

SoapUI REST destekler. Ancak tüm yığınınız JSON REST API’lerinden oluşuyorsa daha modern ve hafif bir istemciyle daha hızlı ilerlemeniz olasıdır.

SoapUI'ın en güçlü olduğu yer hâlâ SOAP ve XML ağırlıklı kurumsal testlerdir.

Modern bir alternatif: Apidog

API'leri ağırlıklı olarak REST, GraphQL veya OpenAPI etrafında inşa edilmiş ekipler için Apidog, daha modern bir iş akışı sunar. API tasarımı, hata ayıklama, otomatik fonksiyonel test ve mock server özelliklerini tek uygulamada birleştirir.

Tipik Apidog akışı:

API şeması tasarlanır veya içe aktarılır.
İstekler gönderilerek endpoint davranışı test edilir.
Görsel doğrulamalar eklenir.
Adımlar otomatik test senaryolarına bağlanır.
Testler CI/CD içinde çalıştırılır.

Apidog ayrıca performans testini aynı araç içinde sunar. Böylece yük kapsamı için ayrı bir ücretli ürüne geçme ihtiyacı azalır. Komut satırı çalıştırıcısı ile pipeline entegrasyonu da desteklenir.

Apidog'u indirebilir ve temel test özelliklerini ücretsiz kullanabilirsiniz. SOAP testleri için ayrıca çevrimiçi SOAP API test aracı rehberini inceleyebilirsiniz.

Kısa karar özeti:

SOAP/WSDL/XML yoğun kurumsal testler için SoapUI hâlâ güçlüdür.
Yeni REST, GraphQL ve OpenAPI projeleri için modern API platformları genellikle daha verimlidir.

Sıkça sorulan sorular

SoapUI ücretsiz mi?

Evet. SoapUI'ın açık kaynak sürümü ücretsizdir ve SOAP ile REST API'leri için fonksiyonel testleri kapsar. SmartBear'ın ticari ürünü ReadyAPI ise yük testi, güvenlik taraması, gelişmiş veri odaklı testler ve daha gelişmiş arayüz özellikleri ekler.

SoapUI sadece SOAP API'lerini mi test eder?

Hayır. SoapUI, SOAP'a ek olarak REST, GraphQL, JMS ve JDBC'yi de test edebilir. REST servisleri için OpenAPI ve WADL tanımlarını içe aktarır. Ancak en güçlü olduğu alan WSDL desteği ve XML doğrulamalarıdır.

SoapUI bir CI/CD pipeline'ında çalıştırılabilir mi?

Evet. SoapUI testleri komut satırından çalıştırılabilir ve Maven entegrasyonu da mevcuttur. Ancak deneyim, baştan CI/CD için tasarlanmış modern araçlara göre daha eski ve daha az akıcıdır.

Örnek komut:

testrunner.sh -r -j -f reports project.xml

Bu komut testleri çalıştırır ve rapor çıktıları üretmek için kullanılabilir.

SoapUI ve Postman arasındaki fark nedir?

SoapUI, SOAP, WSDL ve XML doğrulama tarafında daha güçlüdür. Postman ise REST odaklı iş akışlarında, modern arayüzde ve geliştirici deneyiminde öne çıkar. SOAP servisleri sürdüren ekipler genellikle SoapUI'ı; JSON REST API'leri geliştiren ekipler ise Postman veya modern alternatifleri tercih eder.

SoapUI kullanmak için Groovy bilmem gerekiyor mu?

Temel istekler ve yerleşik assertion’lar için gerekmez. Ancak dinamik test verisi üretme, özel doğrulama yazma, property yönetimi veya harici sistemlerle entegrasyon gibi senaryolarda Groovy bilmek gerekir.

SoapUI 2026'da hâlâ geçerli mi?

Evet, kendi nişinde geçerlidir. SOAP servisleri hâlâ bankacılık, sigorta, kamu, sağlık ve telekom sistemlerinde kullanılır. Bu servisleri test etmek için SoapUI'ın WSDL ve XML doğrulama desteği hâlâ değerlidir. Yeni REST ve GraphQL projelerinde ise çoğu ekip modern API araçlarını tercih eder.

SoapUI ve ReadyAPI arasındaki fark nedir?

SoapUI ücretsiz, açık kaynaklı fonksiyonel test aracıdır. ReadyAPI ise SmartBear'ın ticari ürünüdür ve yük testi, güvenlik testi, gelişmiş veri odaklı testler ve daha gelişmiş arayüz özellikleri ekler. Yalnızca fonksiyonel SOAP/REST testleri gerekiyorsa SoapUI yeterli olabilir; performans ve güvenlik testi gerekiyorsa ReadyAPI veya başka araçlar değerlendirilmelidir.

En İyi OpenAPI Doğrulama Araçları: Temiz API Spesifikasyonları

Tobias Hoffmann — Fri, 22 May 2026 07:30:03 +0000

Bir OpenAPI belirtimi bir sözleşmedir. Kod üreteçleri, belgeler, sahte sunucular ve istemci SDK’leri bu dosyayı kaynak kabul eder. Belirtim hatalıysa, bu hatayı tüm alt çıktılara taşırsınız. Bu yüzden OpenAPI doğrulamasını tek seferlik bir kontrol değil, geliştirme akışının parçası olarak ele almak gerekir.

Apidog'u bugün deneyin

Bu yazıda kullanmaya değer OpenAPI doğrulayıcılarını, hangi problemi çözdüklerini ve bunları gerçek bir geliştirme akışına nasıl yerleştirebileceğinizi ele alacağız. Bazı araçlar ham sözdizimini ve şema uyumluluğunu kontrol eder. Bazıları ise stil, tutarlılık ve API tasarım kurallarını uygular. Sağlam kurulum genellikle ikisini birlikte kullanır.

Belirtimi doğrulamanın önemi

OpenAPI doğrulamasında iki ayrı kontrol türü vardır:

Doğruluk kontrolü
Kalite ve stil kontrolü

Doğruluk kontrolü şu soruya cevap verir:

Bu dosya geçerli bir OpenAPI belirtimi mi?

Örneğin:

YAML girintisi bozuk mu?
$ref var olmayan bir şemaya mı işaret ediyor?
Zorunlu bir alan eksik mi?
Yol parametresi tanımlanmadan mı kullanılmış?
Şema tipi hatalı mı yazılmış?

Bunlar nesnel hatalardır. Dosya ya OpenAPI şemasına göre geçerlidir ya da değildir.

Kalite kontrolü ise şunu sorar:

Belirtim geçerli, ama tüketilebilir ve tutarlı mı?

Örneğin:

Her endpoint için summary veya description var mı?
operationId değerleri tutarlı mı?
Hata yanıtları belgelenmiş mi?
Güvenlik gereksinimleri açıkça belirtilmiş mi?
Path adlandırmaları aynı standardı takip ediyor mu?

Bunlar OpenAPI şeması tarafından her zaman zorunlu tutulmaz, ancak iyi bir API tüketici deneyimi için kritiktir. Bu ayrım, daha geniş anlamda API sözleşme testi yaklaşımının da temelidir: hatayı üretime veya SDK üretimine gitmeden önce yakalamak.

Bilmeye değer OpenAPI doğrulayıcı araçları

Swagger Editor

Swagger Editor, OpenAPI projesinin resmi tarayıcı tabanlı düzenleyicisidir.

Kullanım şekli basittir:

OpenAPI YAML veya JSON dosyanızı editöre yapıştırın.
Sağ panelde canlı önizlemeyi kontrol edin.
Sol panelde doğrulama hatalarını anında görün.
Hataları düzeltip tekrar kontrol edin.

Swagger Editor özellikle şu işler için uygundur:

Hızlı sözdizimi kontrolü
Yeni bir belirtim yazarken canlı geri bildirim
Küçük değişiklikleri manuel doğrulama
Ekip içi hızlı inceleme

CI/CD için ideal araç değildir, çünkü temel kullanım senaryosu tarayıcı üzerindedir. Ancak geliştirme sırasında en hızlı ilk kontrol noktalarından biridir.

Spectral

Spectral, Stoplight tarafından geliştirilen açık kaynaklı bir linter’dır. OpenAPI ve AsyncAPI için kural setleri sağlar.

Spectral’in güçlü tarafı özel kural yazabilmenizdir. Örneğin ekibiniz şu kuralları zorunlu kılabilir:

Her endpoint operationId içermeli
Her endpoint summary içermeli
Path sonunda / kullanılmamalı
Tüm hata yanıtları belgelenmeli
Tag kullanımı zorunlu olmalı

Basit kurulum:

npm install -g @stoplight/spectral-cli

Bir OpenAPI dosyasını lint etmek için:

spectral lint openapi.yaml

Örnek .spectral.yaml:

extends: ["spectral:oas"]

rules:
  operation-summary:
    description: Her operasyon summary alanı içermeli
    given: "$.paths[*][*]"
    then:
      field: summary
      function: truthy

  no-trailing-slash:
    description: Path sonunda slash kullanılmamalı
    given: "$.paths"
    then:
      field: "@key"
      function: pattern
      functionOptions:
        notMatch: "/$"

CI içinde çalıştırmak için:

spectral lint openapi.yaml --fail-severity=warn

Spectral, tasarım kurallarını otomatikleştirmek isteyen ekipler için en pratik seçeneklerden biridir.

openapi-spec-validator

openapi-spec-validator, Python tabanlı odaklı bir doğrulama aracıdır. Temel görevi şudur:

OpenAPI dosyası resmi OpenAPI şemasına göre geçerli mi?

OpenAPI 2.0, 3.0 ve 3.1 sürümlerini destekler. Stil veya tasarım hakkında görüş belirtmez. Sadece yapısal doğruluğu kontrol eder.

Kurulum:

pip install openapi-spec-validator

Kullanım:

openapi-spec-validator openapi.yaml

Python içinde kullanmak isterseniz:

from openapi_spec_validator import validate
from openapi_spec_validator.readers import read_from_filename

spec_dict, base_uri = read_from_filename("openapi.yaml")
validate(spec_dict)

Bu araç özellikle şunlar için uygundur:

Python tabanlı build adımları
Pre-commit hook’ları
CI’da kesin geçiş/hata kapısı
Sadece şema doğruluğu kontrolü gereken durumlar

Örnek pre-commit yapılandırması:

repos:
  - repo: local
    hooks:
      - id: openapi-validate
        name: Validate OpenAPI spec
        entry: openapi-spec-validator openapi.yaml
        language: system
        files: openapi.yaml

Apidog

Apidog, OpenAPI doğrulamasını API tasarım akışının içine yerleştirir. Bir OpenAPI tanımı oluşturduğunuzda veya içe aktardığınızda, düzenleyici içinde yapısal sorunları işaretler.

Apidog’un öne çıkan tarafı çalışma zamanı doğrulamasıdır. Yani yalnızca dosyanın geçerli olup olmadığını değil, canlı API yanıtlarının belirtimdeki şemayla eşleşip eşleşmediğini de kontrol edebilirsiniz.

Bu ayrım önemlidir:

OpenAPI dosyanız geçerli olabilir.
Ancak gerçek API yanıtı belirtimden sapmış olabilir.

Örneğin belirtimde yanıt şöyle tanımlanmış olabilir:

User:
  type: object
  required:
    - id
    - email
  properties:
    id:
      type: integer
    email:
      type: string

Ancak canlı API şu yanıtı dönebilir:

{
  "id": "123",
  "email_address": "dev@example.com"
}

Bu durumda belirtim geçerli olsa bile uygulama sözleşmeye uymuyordur. Apidog bu tür sapmaları yakalamaya yardımcı olur. Belirtimleri tek bir araçta tasarlamak ve doğrulamak için Apidog'u indirin.

Redocly CLI

Redocly CLI; linting, doğrulama ve belge oluşturmayı aynı araç zincirinde birleştirir.

Temel kullanım alanları:

OpenAPI şema doğrulaması
Stil ve kalite kuralları
Çok dosyalı belirtimleri tek dosyada paketleme
Redoc tabanlı belge üretim akışları

Kurulum:

npm install -g @redocly/cli

Lint çalıştırmak için:

redocly lint openapi.yaml

Çok dosyalı bir belirtimi paketlemek için:

redocly bundle openapi.yaml -o dist/openapi.yaml

Redoc ile belge üreten ekipler için Redocly CLI doğal bir seçimdir, çünkü doğrulama ve dokümantasyon aynı ekosistemde kalır.

Vacuum

Vacuum, Go ile yazılmış hızlı bir OpenAPI linter’ıdır. Özellikle büyük belirtimlerde performans avantajı sağlar.

Kullanım senaryoları:

Büyük OpenAPI dosyaları
Monorepo içinde çok sayıda API belirtimi
CI süresinin kritik olduğu projeler
Spectral tarzı kurallar kullanan ekipler

Vacuum, Spectral benzeri kurallarla uyumludur. Bu nedenle mevcut lint yaklaşımından geçiş yapmak genellikle düşük maliyetlidir.

Karşılaştırma tablosu

Araç	Tür	Kontrol Ettiği	CI'da Çalışır	En İyi Kullanım
Swagger Editor	Tarayıcı düzenleyici	Sözdizimi, şema	Hayır	Canlı düzenleme ve hızlı kontroller
Spectral	CLI linter	Stil, özel kurallar	Evet	Tasarım kurallarını uygulama
openapi-spec-validator	CLI / Python kütüphanesi	Şema doğruluğu	Evet	Kesin geçiş veya hata kapısı
Apidog	Entegre platform	Şema + çalışma zamanı sapması	Evet	Tasarım ve yanıt doğrulama
Redocly CLI	CLI	Şema, stil, paketleme	Evet	Belgeler ve doğrulama bir arada
Vacuum	CLI linter	Stil, Spectral kuralları	Evet	Çok büyük belirtimler ve hız

Bir doğrulama iş akışı nasıl oluşturulur

Tek bir araç seçmek yerine doğrulamayı katmanlı kurmak daha sağlıklıdır.

Önerilen akış:

Editör seviyesinde hızlı doğrulama
CI’da şema doğrulaması
CI’da lint ve kalite kontrolü
Çalışan API için sözleşme doğrulaması

1. Yazarken doğrulayın

Belirtimi yazarken Swagger Editor veya entegre bir API tasarım aracı kullanın. Amaç, bariz hataları daha dosya commit edilmeden yakalamaktır.

Örneğin şu hata editör seviyesinde hemen görünmelidir:

paths:
  /users/{id}:
    get:
      responses:
        "200":
          description: OK

Burada {id} path içinde kullanılmıştır, ancak parameters altında tanımlanmamıştır.

Düzeltilmiş hali:

paths:
  /users/{id}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
      responses:
        "200":
          description: OK

2. CI’da doğruluk kapısı ekleyin

Her pull request’te OpenAPI dosyasını doğrulayın. Dosya OpenAPI şemasına göre geçerli değilse build başarısız olmalıdır.

GitHub Actions örneği:

name: Validate OpenAPI

on:
  pull_request:
    paths:
      - "openapi.yaml"

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install validator
        run: pip install openapi-spec-validator

      - name: Validate spec
        run: openapi-spec-validator openapi.yaml

Bu kontrol pazarlık konusu olmamalıdır. Geçersiz belirtim merge edilmemelidir.

3. CI’da kalite kapısı ekleyin

Şema doğrulaması dosyanın geçerli olduğunu söyler. Ancak API tasarımının tutarlı olduğunu söylemez. Bunun için Spectral veya Vacuum gibi bir linter kullanın.

GitHub Actions içinde Spectral örneği:

name: Lint OpenAPI

on:
  pull_request:
    paths:
      - "openapi.yaml"
      - ".spectral.yaml"

jobs:
  lint:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Spectral
        run: npm install -g @stoplight/spectral-cli

      - name: Lint spec
        run: spectral lint openapi.yaml

Başlangıç için yerleşik OpenAPI kurallarını kullanın. Sonra ekibinizin standartlarına göre özel kurallar ekleyin.

Bu yaklaşım, CI/CD'de testleri otomatikleştirmeyi güvenilir kılan aynı prensibe dayanır: kontrol, biri hatırladığında değil, her değişiklikte çalışır.

4. Çalışan API’yi belirtime göre doğrulayın

Belirtim doğru olabilir, ancak uygulama ondan sapmış olabilir. Bu yüzden çalışma zamanı doğrulaması veya sözleşme testi ekleyin.

Kontrol edilmesi gerekenler:

Yanıt gövdesi belirtimdeki şemaya uyuyor mu?
Zorunlu alanlar dönüyor mu?
Alan tipleri doğru mu?
Hata yanıtları belgelenen formatta mı?
Status code’lar belirtimle uyumlu mu?

Apidog üzerinden veya test paketinizde sözleşme testleriyle bu kontrolü çalıştırabilirsiniz. Test tarafında faydalı API iddiaları yazmak, yanıtların belgelenmiş şemaya göre nasıl kontrol edileceğini açıklar.

Yaygın hata: belirtimi yalnızca bir kez doğrulamak

Birçok ekip OpenAPI belirtimini ilk yazdığında doğrular, sonra bir daha kontrol etmez. Bu noktadan sonra belirtim yavaşça çürür.

Tipik senaryo:

Geliştirici yeni endpoint ekler.
Kod güncellenir.
OpenAPI dosyası unutulur.
Belgeler eski kalır.
SDK yanlış üretilir.
Tüketici ekipler hatalı sözleşmeye göre entegrasyon yapar.

Bunu önlemek için doğrulamayı sürekli hale getirin:

Her pull request’te çalıştırın.
Belirtim değiştiğinde zorunlu hale getirin.
API davranışı değiştiğinde sözleşme testlerini çalıştırın.
Hatalı belirtimi başarısız bir birim testi gibi ele alın.

Bu, otomatik test yaklaşımıyla aynı mantığa sahiptir: kontrol, manuel karar gerektirmeden çalıştığında değerlidir.

OpenAPI sürümünü açıkça doğrulayın

OpenAPI 3.0 ve 3.1 arasında özellikle JSON Schema uyumluluğu açısından önemli farklar vardır. OpenAPI 3.1, JSON Schema ile daha uyumlu hale gelmiştir ve bazı şema davranışları değişmiştir.

Bu nedenle:

Belirtimde openapi sürümünü açıkça yazın.
Doğrulayıcınızın bu sürümü desteklediğinden emin olun.
Araç varsayılanlarını kontrol edin.
CI’da kullanılan doğrulayıcı sürümünü sabitleyin.

Örnek:

openapi: 3.1.0
info:
  title: Example API
  version: 1.0.0

Araçlarınız 3.0 varsayıyor ama belirtiminiz 3.1 kullanıyorsa yanlış pozitif veya yanlış negatif sonuçlar alabilirsiniz. Resmi OpenAPI Belirtimi, sürüm farklarını belgeler.

Doğrulayıcıların yakaladığı tipik hatalar

“Belirtim yanlış” ifadesi tek başına yeterince aksiyon alınabilir değildir. Doğrulayıcıların yakaladığı hata tiplerini net görmek daha faydalıdır.

Yapısal hatalar

Örnek hatalar:

Var olmayan şemaya giden $ref
Eksik description
Tanımlanmamış path parametresi
Yanlış veri tipi
Geçersiz responses yapısı
Hatalı YAML girintisi

Hatalı örnek:

components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: int

Burada int geçerli bir OpenAPI tipi değildir. Doğrusu:

components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: integer

Başka bir örnek:

paths:
  /users/{userId}:
    get:
      responses:
        "200":
          description: OK

Bu belirtimde userId path parametresi tanımlanmamıştır. Doğrusu:

paths:
  /users/{userId}:
    get:
      parameters:
        - name: userId
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: OK

Bu tür hatalar kod üreticilerini bozabilir veya hatalı SDK üretilmesine neden olabilir.

Kalite hataları

Kalite hataları genellikle ayrıştırıcıyı bozmaz, ancak API tüketimini zorlaştırır.

Örnekler:

operationId eksik
Bazı path’ler snake_case, bazıları camelCase
Sadece 200 yanıtı belgelenmiş
400, 401, 404 gibi hata yanıtları yok
Gerçekte zorunlu olan request body isteğe bağlı gösterilmiş
Endpoint açıklamaları yetersiz
Tag kullanımı tutarsız

Eksik örnek:

paths:
  /users:
    post:
      summary: Create user
      responses:
        "200":
          description: OK

Daha iyi örnek:

paths:
  /users:
    post:
      operationId: createUser
      summary: Create user
      tags:
        - Users
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/CreateUserRequest"
      responses:
        "201":
          description: User created
        "400":
          description: Invalid request
        "401":
          description: Unauthorized

Bu kalite çizgisini koruyan araç linter’dır. Gerçek davranışın belirtimle uyumlu kalmasını ise API sözleşme testi doğrular.

Tasarıma öncelik veren iş akışında doğrulama

Birçok ekip artık API’yi önce OpenAPI belirtimiyle tasarlıyor. Sonra bu belirtimden şunlar üretiliyor:

Sunucu taslakları
Mock API’ler
Belgeler
SDK’ler
Test senaryoları

Bu modelde OpenAPI dosyası yalnızca dokümantasyon değildir. Sistemin doğruluk kaynağıdır.

Bu yüzden tasarım öncelikli akışta doğrulama şu noktalarda çalışmalıdır:

Tasarım sırasında
- Editör içinde canlı doğrulama
- Hatalı şema veya eksik alanları erken yakalama
Pull request sırasında
- Şema doğrulaması
- Lint kuralları
- Ekip standartları
Mock üretiminden önce
- Mock sunucunun yanlış sözleşmeden üretilmesini engelleme
Uygulama testlerinde
- Gerçek API’nin belirtime uyduğunu kontrol etme

Temiz bir belirtim, mock sunucunun da doğru davranmasını sağlar. Bu da frontend ve istemci ekiplerinin güvenilir bir yer tutucu API’ye karşı geliştirme yapmasını mümkün kılar. Bir belirtimin mock akışını nasıl beslediğini görmek için test için bir API'yi taklit etme kılavuzuna bakabilirsiniz.

Önerilen minimum kurulum

Küçük veya orta ölçekli bir ekip için pratik minimum kurulum şöyle olabilir:

Editör:
  Swagger Editor veya entegre API tasarım aracı

CI:
  openapi-spec-validator
  Spectral

Runtime:
  Apidog veya sözleşme testleri

Repository yapısı örneği:

.
├── openapi.yaml
├── .spectral.yaml
└── .github
    └── workflows
        ├── validate-openapi.yml
        └── lint-openapi.yml

Temel akış:

# Şema doğrulaması
openapi-spec-validator openapi.yaml

# Kalite kontrolü
spectral lint openapi.yaml

Pull request merge koşulu:

OpenAPI şema doğrulaması geçmeli
Lint kuralları geçmeli
Sözleşme testleri geçmeli

Bu kurulum basittir, otomatikleştirilebilir ve ekip büyüdükçe genişletilebilir.

Sıkça sorulan sorular

Bir OpenAPI doğrulayıcı ile linter arasındaki fark nedir?

OpenAPI doğrulayıcı, belirtimin OpenAPI şemasına göre yapısal olarak doğru olup olmadığını kontrol eder. Sonuç genellikle geçiş veya hata şeklindedir.

Linter ise kalite ve stil kurallarını kontrol eder. Örneğin her endpoint’in summary içermesi, operationId kullanılması veya path adlandırmasının tutarlı olması gibi kuralları uygular.

Güçlü bir iş akışı ikisini birlikte kullanır.

Bir OpenAPI belirtimini ücretsiz doğrulayabilir miyim?

Evet. Swagger Editor, Spectral, openapi-spec-validator, Redocly CLI ve Vacuum ücretsiz ve açık kaynaklı seçeneklerdir. Apidog da ücretsiz katmanında belirtim doğrulaması sağlar ve çalışma zamanı kontrolleri ekler.

Doğrulamayı maliyet nedeniyle atlamak için iyi bir sebep yoktur.

OpenAPI 3.0 ve 3.1’i farklı mı doğrulamalıyım?

Aynı doğrulama yaklaşımını kullanabilirsiniz, ancak sürümü açıkça sabitlemelisiniz. OpenAPI 3.1, JSON Schema ile daha uyumlu hale geldiği için bazı şema davranışları değişmiştir.

Araçlarınızın belirtimde beyan edilen sürümü desteklediğinden emin olun.

Belirtim doğrulaması nerede çalışmalı?

İki yerde çalışmalıdır:

Belirtimi yazarken editörde
Her pull request’te CI içinde

Sadece editör doğrulamasına güvenmek yeterli değildir, çünkü atlanabilir. CI doğrulaması ise merge öncesi zorunlu kapı sağlar.

API’min belirtime uygun olduğunu nasıl kontrol ederim?

Belirtim doğrulaması yalnızca OpenAPI dosyasının doğru olduğunu gösterir. Uygulamanın bu sözleşmeye uyduğunu kanıtlamaz.

Bunu kontrol etmek için canlı API yanıtlarını belirtimdeki şemalarla karşılaştıran sözleşme testleri veya çalışma zamanı doğrulaması çalıştırmalısınız. Apidog bunu doğrudan yapabilir; sözleşme test çerçeveleri de aynı kontrolü test paketi içinde uygulayabilir.

Newman ve Postman Arasındaki Fark Nedir?

Tobias Hoffmann — Fri, 22 May 2026 07:29:43 +0000

Newman ve Postman rakip değildir. Aynı API test iş akışının iki farklı aşamasını çözerler: Postman ile istekleri tasarlar, testleri yazarsınız; Newman ile aynı koleksiyonları GUI olmadan terminalde, CI/CD içinde çalıştırırsınız. Kısa kural: Postman geliştirme ve hata ayıklama içindir, Newman otomasyon içindir.

Apidog'u bugün deneyin

Bu ayrımı doğru kurarsanız API testlerini hem geliştirici makinesinde hızlıca hazırlayabilir hem de her pull request, gece çalışması veya deploy sonrası kontrol için otomatik hale getirebilirsiniz. Aşağıda Postman ve Newman'ın rollerini, Newman'ın nasıl kurulacağını ve CI/CD işlem hattına nasıl ekleneceğini adım adım göreceksiniz.

Postman Nedir?

Postman grafiksel bir API platformudur. Masaüstü uygulaması üzerinden istekler oluşturur, bunları koleksiyonlar ve klasörler halinde düzenler, ortam değişkenleriyle baseUrl, token veya kullanıcı bilgisi gibi değerleri yönetirsiniz.

Postman'de her isteğin Tests sekmesine JavaScript tabanlı testler yazabilirsiniz. Örneğin:

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

pm.test("Toplam sipariş pozitif bir sayı", function () {
    const body = pm.response.json();
    pm.expect(body.total).to.be.a("number");
    pm.expect(body.total).to.be.above(0);
});

Bu yaklaşım özellikle şu işler için uygundur:

Yeni bir endpoint'i hızlıca denemek
Header, body veya auth ayarlarında hata ayıklamak
Yanıt yapısını incelemek
Regresyon testleri için koleksiyon hazırlamak
Takım içinde ortak API koleksiyonları paylaşmak

Postman interaktif kullanım için güçlüdür. Bir geliştirici isteği gönderir, yanıtı inceler, değişkenleri düzeltir ve saniyeler içinde tekrar dener. Bu iş akışı grafiksel arayüzden faydalanır. Daha ayrıntılı bir örnek için Postman ile API'ler nasıl test edilir kılavuzuna bakabilirsiniz.

Ancak Postman'in zayıf olduğu alan katılımsız çalıştırmadır. Bir CI sunucusu Postman uygulamasını açıp Collection Runner düğmesine tıklayamaz. Bu noktada Newman devreye girer.

Newman Nedir?

Newman, Postman'in resmi komut satırı koleksiyon çalıştırıcısıdır. Postman'de oluşturduğunuz koleksiyon JSON dosyasını alır, içindeki istekleri ve pm.test betiklerini terminalde çalıştırır.

Newman bir npm paketidir ve şu şekilde kurulabilir:

npm install -g newman

Bir koleksiyonu çalıştırmak için:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json

Bu komut şunları yapar:

orders-api.postman_collection.json dosyasındaki istekleri sırayla çalıştırır.
staging.postman_environment.json içindeki değişkenleri kullanır.
Her isteğin test betiklerini yürütür.
Sonuçları terminalde özetler.
Testlerden biri başarısız olursa sıfırdan farklı exit code döndürür.

Bu son madde CI/CD için kritiktir. CI sistemi exit code'u okuyabilir:

0: Testler geçti, işlem hattı devam eder.
0 dışı: Testlerden biri başarısız oldu, build başarısız sayılır.

Newman, Postman ile aynı yürütme motorunu kullandığı için Postman'de geçen bir koleksiyon Newman'da da aynı test mantığıyla çalışır. Ayrı bir test dili öğrenmeniz gerekmez.

Postman ve Newman Karşılaştırması

Yön	Postman	Newman
Arayüz	Grafiksel masaüstü uygulaması	Komut satırı, UI yok
Birincil kullanım	Yazma, hata ayıklama, keşfetme	Otomatik, katılımsız yürütme
Nerede çalışır	Geliştirici makinesi	CI sunucusu, terminal, zamanlayıcı
Maliyet	Ücretsiz katman ve ücretli planlar	Açık kaynak, ücretsiz
Kurulum	Masaüstü yükleyici	npm paketi veya Docker imajı
Test betikleri	Uygulamada yazılır ve çalıştırılır	Aynı betikleri başsız çalıştırır
Raporlama	Uygulama içi sonuç paneli	Terminal çıktısı, JUnit, HTML raporlayıcıları
En iyi olduğu alan	İnteraktif geliştirme	Tekrarlanabilir otomasyon

Aralarındaki köprü koleksiyon JSON dosyasıdır. Koleksiyonu Postman'de hazırlarsınız, Newman ile otomasyonda çalıştırırsınız.

Newman CI/CD'ye Nasıl Eklenir?

Temel akış her CI sağlayıcısında benzerdir:

Postman koleksiyonunu dışa aktarın.
Ortam dosyasını dışa aktarın.
Bu JSON dosyalarını repoya ekleyin.
CI işinde Newman'ı kurun.
newman run komutunu çalıştırın.
Newman'ın exit code'una göre build'i başarılı veya başarısız sayın.

1. Koleksiyon ve ortam dosyalarını dışa aktarın

Postman'de:

Koleksiyonunuzu seçin.
Export seçeneğiyle JSON dosyası alın.
Kullanacağınız environment için de export alın.

Örnek dosya yapısı:

.
├── postman
│   ├── orders-api.postman_collection.json
│   └── staging.postman_environment.json
└── src

2. Newman'ı yerelde deneyin

CI'a eklemeden önce komutu lokal terminalde çalıştırın:

newman run postman/orders-api.postman_collection.json \
  --environment postman/staging.postman_environment.json

Başarılı çalışırsa CI'a taşımak daha güvenli olur.

3. GitHub Actions'a ekleyin

Örnek GitHub Actions adımı:

- name: API testlerini çalıştır
  run: |
    npm install -g newman
    newman run postman/orders-api.postman_collection.json \
      --environment postman/staging.postman_environment.json \
      --reporters cli,junit \
      --reporter-junit-export results.xml

JUnit raporu üretmek CI panolarında test sonuçlarını daha okunabilir hale getirir. --reporters cli,junit ile hem terminal çıktısı alırsınız hem de XML raporu üretirsiniz.

Daha kapsamlı örnekler için CI/CD'de API testlerini otomatikleştirme ve GitHub Actions ile API test otomasyonu rehberlerine bakabilirsiniz.

Faydalı Newman Komutları

Newman'ı sadece temel run komutuyla değil, CI için önemli bayraklarla kullanmak gerekir.

Belirli environment ile çalıştırma

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json

Bu, Postman'de aktif olan ortamı varsaymak yerine CI'da hangi değişkenlerin kullanılacağını açıkça belirtir.

Veri odaklı test çalıştırma

CSV veya JSON dosyasındaki her satır için koleksiyonu tekrar çalıştırabilirsiniz:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --iteration-data test-data.csv

Örnek test-data.csv:

orderId,expectedStatus
1001,200
1002,200
9999,404

Postman testlerinde bu değerlere değişken olarak erişebilirsiniz:

pm.test("Beklenen durum kodu döner", function () {
    pm.response.to.have.status(Number(pm.iterationData.get("expectedStatus")));
});

İlk hatada durdurma

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --bail

--bail, ilk hata sonrası çalışmayı durdurur. Hızlı geri bildirim istediğiniz pull request kontrollerinde kullanışlıdır.

İstek zaman aşımı belirleme

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --timeout-request 10000

Bu örnekte tek bir isteğin en fazla 10 saniye sürmesine izin verilir. Yanıt vermeyen servisler nedeniyle CI job'ının takılı kalmasını önler.

İstekler arasında bekleme ekleme

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --delay-request 500

--delay-request 500, istekler arasında 500 ms bekler. Rate limit uygulayan API'lerde faydalıdır.

Sadece belirli klasörü çalıştırma

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --folder "Smoke Tests"

Bu sayede aynı koleksiyon içinde küçük bir smoke test setini pull request'lerde, tam regresyon setini gece çalışmasında kullanabilirsiniz.

Docker ile Newman Çalıştırma

Node.js kurmak istemiyorsanız Newman'ı Docker ile çalıştırabilirsiniz:

docker run --rm \
  -v "$PWD/postman:/etc/newman" \
  postman/newman run /etc/newman/orders-api.postman_collection.json \
  --environment /etc/newman/staging.postman_environment.json

Bu yaklaşım özellikle CI ortamlarında kullanışlıdır çünkü build makinesine Node.js veya global npm paketi kurmanız gerekmez.

Postman'den Newman'a Geçerken Yaygın Hatalar

1. Environment dosyasını CI'a eklememek

Postman'de çalışan bir istek, aktif environment sayesinde değişkenleri buluyor olabilir. Newman'da bu environment dosyasını açıkça vermeniz gerekir:

newman run collection.json --environment staging.postman_environment.json

Aksi halde {{baseUrl}}, {{token}} gibi değerler çözümlenmez.

2. Gizli bilgileri repoya koymak

Environment dosyaları token, API key veya şifre içerebilir. Bunları doğrudan repoya eklemek yerine CI secret'larıyla yönetmek daha güvenlidir.

Örnek:

newman run collection.json \
  --env-var "baseUrl=$BASE_URL" \
  --env-var "token=$API_TOKEN"

3. Postman Cloud durumuna güvenmek

CI, Postman masaüstü oturumunuzu veya cloud senkronizasyon durumunuzu bilmez. CI sadece verdiğiniz JSON dosyalarını çalıştırır. Bu yüzden dışa aktardığınız koleksiyonun gerçekten güncel olduğundan emin olun.

4. Koleksiyon JSON'unu güncel tutmamak

Postman'de koleksiyonu düzenleyip repodaki JSON dosyasını güncellemezseniz CI eski testleri çalıştırmaya devam eder.

Pratik çözüm:

Koleksiyon değiştiğinde export işlemini pull request'in parçası yapın.
Koleksiyon dosyasını kod değişikliğiyle birlikte review edin.
CI'da kullanılan dosyanın kaynağını net tutun.

5. Lokal ve CI ortamlarını farklı yapılandırmak

Lokal makinede çalışan test CI'da başarısız oluyorsa genellikle fark şuradadır:

Farklı baseUrl
Eksik token
Farklı test datası
Network erişim problemi
Zaman aşımı değeri

Bu yüzden CI komutunu lokal terminalde mümkün olduğunca aynı parametrelerle test edin.

Ne Zaman Postman, Ne Zaman Newman Kullanmalı?

Postman'i şu durumlarda kullanın:

Yeni API endpoint'i geliştirirken
Request body veya header denemeleri yaparken
Auth problemlerini debug ederken
Test betiklerini yazıp doğrularken
Koleksiyon yapısını düzenlerken

Newman'ı şu durumlarda kullanın:

Pull request açıldığında API testleri çalıştırmak için
Deploy sonrası smoke test yapmak için
Gece regresyon testleri çalıştırmak için
Test sonuçlarını CI raporlarına aktarmak için
Script veya cron job içinde koleksiyon yürütmek için

Pratik ayrım şudur: İnsan yazarken Postman, makine çalıştırırken Newman.

Newman kullanmadan CI'da Postman koleksiyonlarını çalıştırmaya yönelik diğer yaklaşımlar için Newman olmadan CI'da Postman koleksiyonlarını çalıştırma rehberine bakabilirsiniz.

Birleşik Alternatif: Apidog

Postman ve Newman birlikte güçlü bir akış sağlar, ancak iki ayrı parçayı yönetmeniz gerekir: Postman'de koleksiyon hazırlamak, JSON olarak dışa aktarmak, repoda güncel tutmak ve Newman ile çalıştırmak.

Apidog, bu süreci tek platformda birleştirir. Aynı uygulama içinde API tasarlayabilir, isteklerde hata ayıklayabilir, görsel doğrulamalarla otomatik test senaryoları oluşturabilir ve bu senaryoları yerleşik komut satırı çalıştırıcısıyla CI/CD içinde çalıştırabilirsiniz.

Bu yaklaşımda test tanımları ve çalıştırma mekanizması aynı platformda bulunduğu için dışa aktarma ve senkronizasyon yükü azalır. Apidog ayrıca aynı çalışma alanında API tasarımı, mock server ve performans testi gibi iş akışlarını da kapsar.

Apidog'u indirebilir ve test özelliklerini ücretsiz kullanabilirsiniz. Alternatif araçları karşılaştırmak isterseniz API testi için en iyi Postman alternatifleri listesine göz atabilirsiniz.

Sıkça Sorulan Sorular

Newman, Postman'in yerine geçer mi?

Hayır. Newman koleksiyon oluşturmaz veya düzenlemez. Sadece var olan Postman koleksiyonlarını terminalde çalıştırır. Koleksiyon yazma ve hata ayıklama için Postman veya benzer bir araca ihtiyacınız vardır.

Newman ücretli mi?

Hayır. Newman açık kaynaklı ve ücretsizdir. npm paketi olarak dağıtılır. Postman'in ücretsiz ve ücretli planları vardır, ancak Newman'ın kendisi ücretsizdir.

Postman testlerim Newman'da aynı şekilde çalışır mı?

Evet. Newman, Postman ile aynı yürütme motorunu kullanır. pm.test onaylamaları, request akışı ve test betikleri aynı mantıkla çalışır. Yine de CI'a almadan önce koleksiyonu lokal terminalde Newman ile denemek iyi bir pratiktir.

Newman test hatalarını nasıl bildirir?

Newman terminale özet çıktı yazar ve herhangi bir test başarısız olduğunda sıfırdan farklı exit code ile çıkar. CI sistemi bu exit code'u okuyarak build'i başarısız sayabilir. Ayrıca JUnit XML ve HTML gibi raporlayıcılarla sonuçları CI panolarına aktarabilirsiniz.

Node.js kurmadan Newman çalıştırabilir miyim?

Evet. Newman doğrudan npm paketi olduğu için normal kurulumda Node.js gerekir. Ancak Node.js kurmak istemiyorsanız postman/newman Docker imajını kullanabilirsiniz. Bu yöntem CI ortamlarında sık tercih edilir.

API Mocklama Kullanım Alanları: Ne Zaman ve Neden API Mock'lanmalı

Tobias Hoffmann — Fri, 22 May 2026 07:29:26 +0000

Çoğu ekip bir API'yi nasıl taklit edeceğini bilir. Asıl karar, taklidin ne zaman gerçek bir darboğazı kaldırdığı ve ne zaman bakımı gereken ek bir katmana dönüştüğüdür. Doğru yerde kullanılan mock, geliştirmeyi hızlandırır; alışkanlıkla oluşturulan mock ise gerçeklikten uzaklaşıp testlerinize sessizce yanlış güven verir.

Apidog'u bugün deneyin

Bu yazıyı bir karar kontrol listesi gibi kullanın. Her bölüm, API mock kullanımının pratikte değer ürettiği bir senaryoyu ele alır: tamamlanmamış backend ile frontend geliştirmek, hata yollarını test etmek, üçüncü taraf servisleri izole etmek, demoları deterministik yapmak ve CI testlerini kararlı tutmak.

Paralel ön uç ve arka uç geliştirme

Frontend ekibinin henüz backend tarafından uygulanmamış bir endpoint'e ihtiyacı varsa iki kötü seçenek doğar:

Frontend bekler.
Frontend, gerçek servisle ilk temasında bozulabilecek varsayımlarla kod yazar.

Mock burada bağımlılığı keser. Pratik akış şu şekilde olmalıdır:

Frontend ve backend ekibi endpoint sözleşmesi üzerinde anlaşır.
Sözleşme mümkünse bir OpenAPI dokümanı olarak yazılır.
Mock, bu sözleşmeden üretilir.
Frontend mock base URL'ine karşı geliştirme yapar.
Backend gerçek endpoint'i aynı sözleşmeye göre uygular.
Endpoint hazır olduğunda frontend yalnızca base URL'i değiştirir.

Örnek yapı:

Frontend
  API_BASE_URL=https://mock.example.com

Backend hazır olduğunda:
  API_BASE_URL=https://api.example.com

Buradaki kritik nokta, mock'un tek taraflı varsayımlardan değil ortak sözleşmeden üretilmesidir. Sadece frontend'in icat ettiği bir mock, frontend varsayımlarını kodlar. Ortak spesifikasyondan üretilen mock ise iki ekibi hizalı tutar; bu, API sözleşme testinin arkasındaki prensiple aynıdır.

Bu kullanımın pratik getirisi şudur:

Frontend backend'i beklemeden ekranları geliştirir.
Backend, yarım endpoint talepleriyle bölünmeden uygulamaya odaklanır.
Tasarımcılar ve ürün yöneticileri erken aşamada tıklanabilir akış görür.
Mock, OpenAPI'den üretildiği sürece bakım maliyeti düşük kalır.

İsteğe bağlı olarak tetikleyemeyeceğiniz hata yollarını test etme

Sağlıklı bir API genellikle 200 döner. Ancak istemci kodunuzun yalnızca başarılı yanıtları değil, şu durumları da yönetmesi gerekir:

429 Too Many Requests
500 Internal Server Error
503 Service Unavailable
zaman aşımı
bozuk JSON
alan adı açısından geçersiz ama HTTP açısından başarılı yanıtlar

Gerçek bir sunucu, testiniz istediğinde bu hataları deterministik olarak üretmez. Mock burada kontrol sağlar.

Örneğin bir istemci için şu senaryoları bilinçli şekilde üretin:

Test Edilemeyen Hata	Mock Kurulumu	Neyi Kanıtlar
Sunucu hatası	`500` döndür	İstemci yeniden dener, sonra zarifçe düşer
Oran sınırlaması	`Retry-After` ile `429`	İstemci doğru aralığı bekler
Yavaş ağ	Yanıtı 5 sn geciktir	İstemci düzgün bir şekilde zaman aşımına uğrar
Hatalı yük	Bozuk JSON döndür	Ayrıştırıcı çökmeden başarısız olur

Basit bir test mantığı şöyle görünebilir:

it("429 durumunda Retry-After başlığına göre bekler", async () => {
  mockApi.get("/orders").reply(429, {
    error: "rate_limited"
  }, {
    "Retry-After": "3"
  });

  const result = await fetchOrdersWithRetry();

  expect(result.retryAfterSeconds).toBe(3);
});

Bu kullanım çoğu ekipte atlanır. Oysa test edilmemiş hata yönetimi, fiilen sahip olmadığınız hata yönetimidir. Her hata yolunu varsaymak yerine doğrulamak için mock'u kapsamlı API doğrulama testleriyle birlikte kullanın.

Ayrıca yalnızca HTTP hatalarını değil, alan adı açısından hatalı başarılı yanıtları da test edin:

{
  "orderId": "ord_123",
  "status": "UNKNOWN_STATUS",
  "total": -42
}

Bu yanıt teknik olarak 200 olabilir; ancak iş kurallarınız için geçersizdir. Gerçek sunucu doğru çalışıyorsa bunu hiç göndermeyebilir. Mock ile bu tür bozuk ama iyi biçimlendirilmiş verileri üretip istemci varsayımlarını görünür hale getirebilirsiniz.

Üçüncü taraf bir API'nin yerini almak

Testleriniz gerçek bir ödeme işlemcisini, harita servisini veya kargo API'sini çağırıyorsa şu riskleri alırsınız:

Testler yavaşlar.
Bazı çağrılar maliyet oluşturabilir.
Sandbox ortamı kapalıysa testleriniz de kırılır.
Rate limit veya ağ sorunları, kodunuzla ilgisiz hatalara dönüşür.

Bu durumda üçüncü tarafı mock'layın.

Uygulanabilir akış:

Üçüncü taraf API'nin gerçek yanıt örneklerini kaydedin veya yayınlanmış şemasını alın.
Bu yanıtlardan mock endpoint'leri oluşturun.
Birim ve bileşen testlerini mock'a karşı çalıştırın.
Gerçek üçüncü tarafı yalnızca zamanlanmış sözleşme kontrolünde çağırın.

Örnek:

Commit başına test:
  Uygulama -> Mock ödeme API'si

Zamanlanmış sözleşme testi:
  Contract checker -> Gerçek ödeme API'si

Bu yaklaşım testleri hızlı, ücretsiz ve deterministik yapar. Satıcı tarafında kesinti olsa bile commit başına testleriniz çalışmaya devam eder.

Ancak bakım maliyeti vardır. Üçüncü taraf API size haber vermeden değişebilir ve mock bundan haberdar olmaz. Bunu azaltmak için küçük bir zamanlanmış iş çalıştırın:

Her gece:
  1. Gerçek üçüncü taraf endpoint çağrılır.
  2. Yanıt şeması beklenen mock şemasıyla karşılaştırılır.
  3. Sapma varsa ekip uyarılır.

Ayrıca satıcının changelog'una abone olmak da değerlidir. Böylece planlı değişiklikleri başarısız sözleşme testlerinden önce yakalayabilirsiniz.

Demoları ve prototipleri güçlendirme

Müşteri önünde canlı servisleri çağıran demo risklidir. Yavaş sorgu, boş veri seti veya geçici kesinti, iyi hazırlanmış bir sunumu açıklama yapmak zorunda kaldığınız bir duruma çevirebilir.

Mock, demoyu deterministik yapar. Demo için gereken veriyi açıkça kodlarsınız:

zamanında gönderilen sipariş
sağlıklı metriklerle dolu dashboard
temiz sonuç döndüren arama
başarılı ödeme akışı
beklenen kullanıcı profili

Örnek demo yanıtı:

{
  "dashboard": {
    "monthlyRevenue": 128000,
    "activeUsers": 4210,
    "conversionRate": 7.4
  }
}

Buradaki amaç test etmek değil, kontrol sağlamaktır. İzleyicinin ne göreceğini siz belirlersiniz ve dış faktörler demoyu bozmaz.

Aynı yaklaşım prototipler için de geçerlidir. Backend henüz yokken UI akışını doğrulayabilirsiniz. Eğer mock, nihai API'nin döndüreceği şekilleri temsil ediyorsa, frontend kodunuz tek kullanımlık iskele olmaktan çıkar; gerçek ürüne taşınabilir hale gelir.

Pratik kontrol listesi:

Mock yanıtları ürün senaryosunu temsil ediyor mu?
Endpoint isimleri ve payload yapıları olası gerçek API ile uyumlu mu?
Frontend'de base URL dışında değişiklik gerekmeyecek mi?
Demo verisi deterministik mi?

Bu kategorideki araçları karşılaştırmak için çevrimiçi API taklit araçları incelemesine bakabilirsiniz.

CI'ı hızlı ve kararlı tutmak

CI ortamında harici servisleri çağıran test paketi, o servislerin tüm problemlerini miras alır:

ağ aksaklıkları
rate limit
paylaşılan staging verisi
üçüncü taraf kesintileri
yavaş yanıt süreleri

Bunların her biri, incelenen kodla ilgisi olmayan flaky test hatalarına dönüşür.

Flaky testler zamanla daha büyük bir soruna yol açar: ekip test hatalarını görmezden gelmeye başlar. Bu da CI'ın amacını boşa çıkarır.

Harici bağımlılıkları mock'lamak, commit başına testleri hermetik hale getirir:

CI test paketi:
  Uygulama -> Mock servisler

Ayrı zamanlanmış iş:
  Sözleşme testleri -> Gerçek servisler

Bu ayrım önemlidir:

Commit başına testler hızlı ve deterministik kalır.
Gerçek API ile uyum, ayrı sözleşme testleriyle doğrulanır.
Mock sapmaları kullanıcılara ulaşmadan yakalanır.

Bu yapı, sağlıklı bir CI/CD test hattı için temel bir ayrımdır.

Hız kazancı yalnızca küçük bir kolaylık değildir. On iki dakikadan doksan saniyeye düşen test paketi, ekibin davranışını değiştirir:

Geliştiriciler testleri her commit öncesi çalıştırır.
Pull request inceleyicileri sonucu beklemek zorunda kalmaz.
Hatalar daha erken yakalanır.
CI çıktısına güven artar.

Otomatik testlerin yatırım getirisi, ekibin testlere gerçekten güvenmesine bağlıdır.

Ne zaman mock kullanılmamalı?

Mock'un temel hata modu şudur: gerçeklikle artık uyuşmayan bir mock.

Bu durumda testler yeşil kalır, ancak production bozulur. Çünkü testler gerçek sistemi değil, güncelliğini kaybetmiş bir kurguyu doğrular.

Şu durumlarda mock kullanmayın:

Testin amacı entegrasyonun kendisini doğrulamaksa.
Sözleşme testi çalıştırıyorsanız.
Uçtan uca test gerçek kullanıcı akışını doğruluyorsa.
Mock'ladığınız bağımlılığı hiçbir zaman gerçek servise karşı kontrol etmiyorsanız.
Gerçek servis test ortamında zaten hızlı, ücretsiz ve güvenilirse.

Genel kural:

Hız, izolasyon ve kontrol için mock kullan.
Doğruluk için küçük ama dürüst bir gerçek servis testi katmanı tut.

Mock ve sözleşme kontrolünü aynı yerde yönetmek istiyorsanız, Apidog API tasarımınızdan mock'lar oluşturur ve testleri hem mock'a hem de canlı endpoint'e karşı çalıştırır. Başlamak için Apidog'u indirin ve mevcut spesifikasyonunuzdan ilerleyin. Kavramsal temel için mock API'nin ne olduğuna da bakabilirsiniz.

Sıkça sorulan sorular

Gerçek API'yi çağırmak yerine ne zaman bir API'yi mock'lamalıyım?

Hız, izolasyon veya kontrole ihtiyacınız olduğunda mock kullanın. Tipik örnekler:

tamamlanmamış backend'e karşı frontend geliştirme
gerçek sunucunun üretmeyeceği hata yollarını test etme
yavaş veya ücretli üçüncü taraf servisleri izole etme
deterministik demo hazırlama
CI testlerini kararlı tutma

Sözleşme ve uçtan uca testlerde ise gerçek API'yi çağırın.

Mock kullanımı entegrasyon testinin yerini alır mı?

Hayır. Mock, kontrol ettiğiniz kodu hızlı ve izole test etmek içindir. Entegrasyon ve sözleşme testleri gerçek sınırı doğrulamalıdır. Bu testleri mock'lamak, testin amacını ortadan kaldırır.

Bir mock'un güncelliğini kaybetmesini nasıl önlerim?

Mock'u mümkünse OpenAPI gibi paylaşılan bir şemadan üretin. Sözleşme değiştiğinde mock da aynı kaynaktan güncellenir. Ek olarak, canlı API'ye karşı zamanlanmış sözleşme testleri çalıştırın. Böylece gerçek yanıtın hâlâ beklenen şemayla eşleştiğini doğrularsınız.

Kontrol etmediğim bir üçüncü taraf API'yi mock'layabilir miyim?

Evet. Bu, mock kullanımının en güçlü senaryolarından biridir. Üçüncü tarafın gerçek yanıtlarını kaydedin veya yayınlanmış şemasından mock oluşturun. Testlerinizi mock'a karşı çalıştırın. Satıcı API'si değiştiğinde fark etmek için gerçek servise karşı zamanlanmış bir sözleşme kontrolü ekleyin.

Mock kullanımı demolar ve prototipler için faydalı mı?

Evet. Mock, demoyu izleyicinin görmesini istediğiniz veriyle deterministik hale getirir. Canlı kesinti, boş veri veya yavaş sorgu riski ortadan kalkar. Prototiplerde ise backend hazır olmadan önce UI akışını oluşturmanıza ve doğrulamanıza olanak tanır.

En İyi Otomatik Test Platformları: 2026 Karşılaştırması

Tobias Hoffmann — Fri, 22 May 2026 07:29:01 +0000

Tek bir “en iyi” otomatik test platformu yoktur; test ettiğiniz katman ve ekibinizin çalışma şekli için en uygun araç vardır. Tarayıcı otomasyonu için tasarlanmış bir araç REST API sözleşmelerini ideal şekilde doğrulamayabilir; API testi için tasarlanmış bir araç da ödeme akışındaki gerçek kullanıcı etkileşimini tek başına kapsayamaz.

Apidog'u bugün deneyin

Bu yazıda yaygın kullanılan altı otomatik test platformunu pratik açıdan karşılaştıracağız: Apidog, Selenium, Playwright, Newman ile Postman, pytest ve Cypress. Her araç için ne zaman kullanılacağını, nerede zorlanacağını ve CI/CD süreçlerine nasıl oturtulacağını özetleyeceğiz.

Otomatik test platformu nasıl değerlendirilir?

Bir araç seçmeden önce şu soruları netleştirin:

Hangi katmanı test edeceksiniz? API, UI veya ikisi birden mi?
Testleri kim yazacak? Geliştiriciler mi, QA ekibi mi, karma bir ekip mi?
CI’da katılımsız çalışabilecek mi?
Raporlama ihtiyacınız ne? Basit pass/fail yeterli mi, ayrıntılı hata çıktısı gerekiyor mu?
Test paketi büyüdükçe bakım maliyeti ne olacak?

Otomatik test kavramı sizin için hâlâ net değilse, araç seçmeden önce otomatik testin ne olduğuna dair başlangıç rehberini inceleyebilirsiniz.

Bir kriter daha kritik: kararsızlık maliyeti. Kod değişmediği halde bazen geçen bazen başarısız olan testler, ekibin test sonuçlarına güvenini azaltır. Otomatik bekleme, kararlı seçiciler, iyi izole edilmiş test verisi ve deterministik ortamlar bu yüzden “ekstra” değil, sürdürülebilir test paketinin temelidir.

Apidog

Apidog, API tasarımı, hata ayıklama, mock, dokümantasyon ve otomatik testi tek bir yerde birleştiren bir API platformudur. Otomatik test tarafında görsel test oluşturucu, OpenAPI şema doğrulaması, CSV/JSON tabanlı veri odaklı testler, ortam yönetimi ve CI için CLI çalıştırıcı sunar.

Apidog özellikle şu senaryolarda uygundur:

REST API uç noktalarını sözleşmeye göre doğrulamak
Aynı API tanımını tasarım, dokümantasyon, mock ve test için kullanmak
Geliştirici ve QA ekiplerinin aynı workspace üzerinde çalışmasını sağlamak
Kod yazmadan temel API regresyon testleri oluşturmak
Gerektiğinde script ile daha karmaşık doğrulamalar eklemek

Pratik bir API test akışı şöyle kurulabilir:

API uç noktalarını OpenAPI tanımıyla oluşturun veya içe aktarın.
Her endpoint için beklenen status code, header ve response body doğrulamalarını ekleyin.
Farklı ortamlar için değişkenler tanımlayın: dev, staging, production.
CSV veya JSON dosyasıyla aynı testi farklı veri setleriyle çalıştırın.
CLI runner ile testleri CI pipeline içinde tetikleyin.

Apidog’un güçlü yanı, tek bir bilgi kaynağı kullanmasıdır. Bugün hata ayıkladığınız bir istek, yarın regresyon testine dönüşebilir. Dezavantajı ise kapsamıdır: Apidog API testine odaklanır; gerçek tarayıcı UI akışları için Playwright, Selenium veya Cypress gibi ayrı bir araç gerekir.

Tam iş akışını denemek için Apidog'u indirebilirsiniz.

Selenium

Selenium, tarayıcı otomasyonu için uzun süredir kullanılan bir standarttır. WebDriver protokolü üzerinden gerçek tarayıcıları kontrol eder ve Java, Python, C# ve JavaScript dahil birçok dili destekler.

Selenium şu durumlarda mantıklıdır:

Geniş tarayıcı desteğine ihtiyacınız varsa
Farklı dil ekosistemlerinde UI testleri yazmanız gerekiyorsa
Mevcut test altyapınız Selenium üzerine kurulmuşsa
Tarayıcılar arası regresyon kapsamı kritikse

Basit bir Selenium testi örneği:

from selenium import webdriver
from selenium.webdriver.common.by import By

driver = webdriver.Chrome()

driver.get("https://example.com/login")

driver.find_element(By.ID, "email").send_keys("user@example.com")
driver.find_element(By.ID, "password").send_keys("secret")
driver.find_element(By.CSS_SELECTOR, "button[type='submit']").click()

assert "Dashboard" in driver.title

driver.quit()

Selenium’un maliyeti bakım yüküdür. Testler tamamen kodla yazılır. Beklemeler, seçiciler, sürücü yönetimi ve paralel çalışma dikkatli tasarlanmazsa testler kararsız hale gelebilir.

Selenium bazı ekipler tarafından API kontrolleri için de kullanılmaya çalışılır, ancak bu genellikle doğru katman seçimi değildir. API testi için Selenium incelemesi, neden özel bir API aracının çoğu durumda daha uygun olduğunu açıklar. Kurulum ve kullanım için resmi Selenium belgeleri referans alınabilir.

Playwright

Playwright, Microsoft tarafından geliştirilen modern bir tarayıcı otomasyon çerçevesidir. Chromium, Firefox ve WebKit’i tek API ile destekler. Otomatik bekleme, hızlı paralel çalışma ve trace viewer gibi hata ayıklama araçlarıyla Selenium’a kıyasla daha modern bir geliştirici deneyimi sunar.

Playwright özellikle şu ekipler için iyi bir varsayılandır:

Yeni bir UI test altyapısı kuran ekipler
JavaScript veya TypeScript kullanan frontend ekipleri
Paralel ve hızlı uçtan uca testlere ihtiyaç duyan projeler
Test kararsızlığını azaltmak isteyen ekipler

Basit bir Playwright testi:

import { test, expect } from '@playwright/test';

test('kullanıcı giriş yapabilir', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('secret');
  await page.getByRole('button', { name: 'Login' }).click();

  await expect(page.getByText('Dashboard')).toBeVisible();
});

Playwright kod odaklıdır. JavaScript, Python, Java ve C# bağlamaları vardır, ancak test yazmak için geliştirici becerisi gerekir. API sözleşme testi için değil, tarayıcı otomasyonu için tasarlanmıştır.

Postman ve Newman

Postman popüler bir API istemcisidir. Newman ise Postman koleksiyonlarını komut satırından çalıştıran araçtır. Tipik kullanım şudur:

İstekleri Postman arayüzünde oluşturun.
Test scriptlerini koleksiyona ekleyin.
Ortam değişkenlerini tanımlayın.
Koleksiyonu Newman ile CI’da çalıştırın.

Örnek Newman komutu:

newman run collection.json \
  -e staging.postman_environment.json \
  --reporters cli,junit \
  --reporter-junit-export results.xml

Postman + Newman şu durumlarda uygundur:

Küçük veya orta ölçekli API test paketleri
Hızlı prototipleme
Manuel API keşfinden otomasyona geçiş
Postman kullanan ekiplerde CI entegrasyonu

Sınırlamalar test paketi büyüdükçe görünür. Test mantığı çoğunlukla isteklere eklenen JavaScript parçalarında tutulur. Bu yapı küçük paketlerde pratik olsa da büyük test setlerinde bakım zorlaşabilir.

Daha ayrıntılı karşılaştırma için Newman ve Postman yazısını inceleyebilirsiniz. Alternatifleri değerlendiren ekipler için API testi için Postman alternatifleri rehberi de faydalıdır.

Pytest

Pytest, Python ekosisteminin en yaygın test çerçevelerinden biridir. requests kütüphanesiyle birlikte API testi için güçlü ve esnek bir yapı sunar. Aynı zamanda birim, entegrasyon ve servis testlerini de yönetebilir.

Basit bir API testi:

import requests

def test_get_user():
    response = requests.get("https://api.example.com/users/1")

    assert response.status_code == 200
    assert response.json()["id"] == 1

Veri odaklı test için parametrize kullanılabilir:

import pytest
import requests

@pytest.mark.parametrize("user_id", [1, 2, 3])
def test_get_users(user_id):
    response = requests.get(f"https://api.example.com/users/{user_id}")

    assert response.status_code == 200
    assert response.json()["id"] == user_id

Pytest şu durumlarda idealdir:

Ekibiniz Python kullanıyorsa
Testleri uygulama koduna yakın tutmak istiyorsanız
Test mantığı üzerinde tam kontrol gerekiyorsa
Fixture, mock ve parametrizasyon gibi gelişmiş test yapıları istiyorsanız

Takas noktası açıktır: Her şey koddur. Kod yazmayan ekip üyelerinin katkısı sınırlı kalabilir. Ayrıca istek yapısı, test verisi, raporlama ve ortam yönetimi gibi katmanları kendiniz tasarlamanız gerekir.

Uygulamalı örnekler için pytest API otomatik test eğitimine bakabilirsiniz. Çerçevenin detayları için pytest belgeleri iyi bir referanstır.

Cypress

Cypress, JavaScript tabanlı bir frontend ve uçtan uca test aracıdır. Uygulamayla aynı çalışma döngüsünde çalışır. Bu sayede hızlı geri bildirim, zaman yolculuğu hata ayıklaması ve otomatik bekleme gibi güçlü geliştirici deneyimi özellikleri sunar.

Basit bir Cypress testi:

describe('Login flow', () => {
  it('kullanıcı giriş yapabilir', () => {
    cy.visit('/login')

    cy.get('[data-testid="email"]').type('user@example.com')
    cy.get('[data-testid="password"]').type('secret')
    cy.get('[data-testid="submit"]').click()

    cy.contains('Dashboard').should('be.visible')
  })
})

Cypress şu durumlarda uygundur:

JavaScript frontend ekipleri
Komponent ve uçtan uca testlerin aynı ekosistemde yazılması
Hızlı lokal test geri bildirimi
Tarayıcı merkezli kullanıcı akışlarının doğrulanması

Cypress test içinde API çağrıları yapabilir, ancak bir API sözleşme test platformu değildir. Tarayıcı davranışını doğrulamak için güçlüdür; API seviyesindeki geniş regresyon paketi için ayrı bir API test aracı daha uygun olur.

Platform karşılaştırma tablosu

Platform	Birincil katman	Gerekli beceri	CI uyumu	En iyi kullanım
Apidog	API	Görsel veya kod	Evet, CLI çalıştırıcı	Karma becerili ekiplerde API testi
Selenium	Tarayıcı UI	Kod, birçok dil	Evet	Geniş tarayıcılar arası UI kapsamı
Playwright	Tarayıcı UI	Kod, JS/Python/Java/C#	Evet	Modern UI otomasyonu, yeni projeler
Postman + Newman	API	Görsel + JS script	Evet, Newman ile	Küçük ve orta ölçekli API test paketleri
pytest	API ve birim test	Kod, Python	Evet	Kod odaklı kontrol isteyen Python ekipleri
Cypress	Tarayıcı, uçtan uca	Kod, JavaScript	Evet	JavaScript frontend uçtan uca testi

Tablo temel ayrımı gösterir: Apidog, Postman ve pytest API tarafında; Selenium, Playwright ve Cypress UI tarafında güçlüdür. Çoğu ekip için doğru yaklaşım, tek aracı her şeye zorlamak yerine API ve UI katmanları için doğru araçları birlikte kullanmaktır.

API platformları ile UI platformları karşılaştırması

API testleri protokol düzeyinde çalışır. HTTP isteği gönderir, ardından status code, header ve JSON/XML response body üzerinde doğrulama yapar. Tarayıcı olmadığı için testler genellikle hızlı, daha deterministik ve daha kolay paralelleştirilebilir olur.

Örnek API doğrulama noktaları:

200, 201, 400, 401 gibi status code kontrolleri
Response body şema doğrulaması
Header kontrolleri
Yetkilendirme senaryoları
Veri odaklı edge case testleri
Contract testleri

UI testleri ise gerçek tarayıcı üzerinde çalışır. Sayfanın render edilmesini bekler, elementlere tıklar, formlara veri girer ve kullanıcının gördüğü sonucu doğrular. Bu, gerçek kullanıcı deneyimini kontrol etmek için gereklidir; ancak daha yavaş ve bakım açısından daha maliyetlidir.

Sağlıklı bir test stratejisi genellikle şu yapıya benzer:

Çok sayıda hızlı API testi
Kritik iş akışlarını kapsayan daha az sayıda UI testi
Birim testlerle desteklenen uygulama mantığı
CI’da her commit veya pull request için otomatik çalıştırma

Pratik kural: Mümkün olan doğrulamayı API katmanında yapın; yalnızca gerçekten tarayıcı gerektiren akışları UI testiyle kapsayın.

Doğru platformu seçmek

Kısa bir karar akışı kullanın:

Test katmanını belirleyin.

REST veya GraphQL API testleri için Apidog, pytest veya Postman + Newman düşünün. Tarayıcı akışları için Playwright, Selenium veya Cypress daha uygundur.
Ekip becerilerini değerlendirin.

Tamamen geliştiricilerden oluşan ekipler kod odaklı araçları rahat kullanabilir. QA, ürün veya teknik olmayan ekip üyeleri de test yazacaksa görsel test oluşturucu avantaj sağlar.
CI entegrasyonunu erken doğrulayın.

Araç CI’da çalışıyor mu? Exit code doğru dönüyor mu? Rapor formatı pipeline’ınıza uyuyor mu? Bunları pilot aşamada test edin.
Bakım maliyetini ölçün.

Kod odaklı framework’ler esneklik sağlar, ancak altyapı sorumluluğu size kalır. Entegre platformlar tekrar eden yapılandırma ve yapıştırıcı kod ihtiyacını azaltır.
Küçük bir pilot yapın.

En güçlü aday araçla 10 gerçek test yazın. Gerçek endpoint’ler, gerçek test verisi ve gerçek CI ortamı kullanın. Araç seçimi için en güvenilir sinyal budur.

API testi özelinde altyapı katmanları da önemlidir. API otomasyon test çerçevesi rehberi, sağlam bir API test yapısında hangi katmanların bulunması gerektiğini açıklar.

Karma bir ekip için API tasarımı, mock, dokümantasyon ve otomatik testi tek platformda toplamak istiyorsanız, Apidog güçlü bir başlangıç noktasıdır. Alternatiflerle karşılaştırmak için Apidog'u indirebilirsiniz.

Sıkça sorulan sorular

Genel olarak en iyi otomatik test platformu hangisidir?

Genel bir kazanan yoktur. Apidog API testi için, Playwright modern tarayıcı otomasyonu için, pytest ise kod odaklı kontrol isteyen Python ekipleri için güçlü seçeneklerdir. En iyi platform; test katmanınıza, ekip becerilerinize ve CI kurulumunuza uyan platformdur.

Tek bir platform hem API hem de UI testini yapabilir mi?

Kısmen evet, ancak genellikle eşit kalitede değil. Selenium ve Cypress gibi UI araçları test içinde API çağrısı yapabilir. API araçları da bazı senaryolarda UI benzeri kontrolleri script edebilir. Yine de çoğu ekip için daha sürdürülebilir yaklaşım, özel bir API test aracı ile özel bir UI test aracını birlikte kullanmaktır.

Otomatik test platformları kodlama becerisi gerektirir mi?

Platforma bağlıdır. Selenium, Playwright, pytest ve Cypress kod odaklıdır. Apidog ve Postman görsel test oluşturma sunar, ancak gerektiğinde scripting de destekler. Seçim yaparken testleri kimin yazacağını ve kimin sürdüreceğini dikkate alın.

CI entegrasyonu ne kadar önemlidir?

Çok önemlidir. CI’da otomatik çalışmayan test paketi zamanla manuel kontrole dönüşür. Bu karşılaştırmadaki araçların tamamı CI ile kullanılabilir, ancak runner davranışı, exit code yönetimi ve rapor formatları farklıdır. CI uyumunu test paketi büyüdükten sonra değil, pilot aşamada doğrulayın.

Otomatik test için açık kaynak mı ticari araç mı daha iyidir?

Hiçbiri doğal olarak daha iyi değildir. Selenium, Playwright ve pytest gibi açık kaynak araçlar esnek ve ücretsizdir, ancak kurulum ve bakım sorumluluğu ekibe kalır. Ticari veya entegre platformlar kurulum, raporlama ve iş birliği maliyetini azaltabilir. Birçok ekip hibrit yaklaşım kullanır: açık kaynak UI aracı ve entegre API test platformu.

Online API Mock Araçları Karşılaştırması: Apidog, Mockoon, WireMock, Beeceptor ve Postman

Tobias Hoffmann — Fri, 22 May 2026 07:28:49 +0000

Çevrimiçi bir API sahte sunucusu, backend hazır olmasa bile çalışan bir uç nokta sağlar. Frontend uygulamanızı, mobil uygulamanızı veya test paketinizi barındırılan bir URL’ye yönlendirir ve gerçekçi yanıtlar alırsınız. Ancak Apidog, Mockoon, WireMock, Beeceptor ve Postman; kurulum süresi, veri üretimi, koşullu yanıt desteği ve mock’un nerede çalıştığı açısından belirgin şekilde farklıdır.

Apidog'u bugün deneyin

Bu rehberde her aracı şu açılardan karşılaştıracağız:

Mock sunucu nerede çalışıyor: bulut, yerel veya ikisi birden?
Yanıt verisi otomatik üretilebiliyor mu?
Aynı endpoint farklı isteklere farklı yanıt verebiliyor mu?
Kurulum ne kadar pratik?
Araç hangi ekip ve kullanım senaryosu için daha uygun?

Bir sahte sunucu için "çevrimiçi" ne anlama geliyor?

"Çevrimiçi" iki farklı modeli ifade edebilir:

Bulutta barındırılan mock sunucu
- Sağlayıcının altyapısında çalışır.
- Herkesin erişebileceği genel bir URL üretir.
- Mobil testler, uzaktaki ekip üyeleri ve müşteri demoları için uygundur.
Yerel mock sunucu
- Kendi makinenizde, Docker container’da veya CI runner’da çalışır.
- Genellikle yalnızca aynı ağa veya makineye erişebilen istemciler tarafından kullanılır.
- Daha hızlıdır, çevrimdışı çalışabilir ve testleri izole tutar.

Bu ayrım önemlidir. Örneğin:

Mobil uygulama testi      -> Genel URL gerekir
Lokal frontend geliştirme -> Yerel mock yeterli olabilir
CI testleri               -> Container veya yerel mock uygundur
Müşteri demosu            -> Bulut mock daha pratiktir

Bu karar, daha geniş sahte sunucuya karşı gerçek sunucu yaklaşımıyla da yakından ilişkilidir.

Araçları değerlendirirken şu beş kriteri birlikte düşünün:

Barındırma modeli
Otomatik veri üretimi
Koşullu yanıt desteği
Kurulum eforu
API tasarımı ve test akışıyla entegrasyon

Apidog

Apidog, API tasarımınızdan otomatik olarak mock endpoint üretir. Bir endpoint tanımladığınızda ayrı bir mock sunucu konfigürasyonu yapmadan mock URL oluşur.

Örneğin API şemanızda şu alanlar varsa:

{
  "id": 1,
  "email": "user@example.com",
  "created_at": "2024-01-01T10:00:00Z",
  "avatar": "https://example.com/avatar.png"
}

Apidog alan adlarına göre gerçekçi veri döndürür:

email alanı e-posta benzeri değer üretir.
created_at tarih/zaman üretir.
avatar görsel URL’si döndürür.

Bu özellik Akıllı Sahte Sunucu yaklaşımıdır.

Daha karmaşık senaryolarda Gelişmiş Sahte Sunucu kullanılabilir. Böylece aynı endpoint, isteğe göre farklı yanıtlar döndürebilir:

GET /users/1  -> 200 OK
GET /users/0  -> 404 Not Found
POST /users   -> 422 Validation Error

Apidog mock sunucuları paylaşılabilir URL ile bulutta çalışabilir. Yerel hız veya izole test gerektiğinde yerel mock da kullanılabilir.

Apidog’un avantajı, mock sunucunun API tasarımı, hata ayıklama ve API sözleşme testi ile aynı projede bulunmasıdır. Böylece API spesifikasyonu değiştiğinde mock’un ayrı bir yerde eski kalma riski azalır.

En uygun olduğu yer: Gerçek API tasarımına bağlı, düşük kurulumlu ve test akışıyla entegre mock isteyen ekipler.

Mockoon

Mockoon, hızlı yerel mock geliştirme için kullanılan ücretsiz ve açık kaynaklı bir masaüstü uygulamasıdır.

Tipik kullanım akışı şöyledir:

Mockoon’u açın.
Yeni bir environment oluşturun.
Endpoint tanımlayın.
Yanıt gövdesini yazın.
Sunucuyu yerel portta çalıştırın.

Örnek endpoint:

GET http://localhost:3000/users

Örnek yanıt:

[
  {
    "id": 1,
    "name": "Ayşe Yılmaz",
    "email": "ayse@example.com"
  }
]

Mockoon, Faker.js ile dinamik veri üretimini destekler. Ayrıca header veya query parametrelerine göre kural tabanlı yanıtlar tanımlayabilirsiniz.

Örneğin:

GET /users?status=active   -> aktif kullanıcılar
GET /users?status=blocked  -> engellenmiş kullanıcılar

Yanıt gecikmesi ekleyerek yavaş ağ koşullarını da simüle edebilirsiniz.

Mockoon varsayılan olarak yerel çalışır. CLI ve Docker imajı sayesinde aynı mock’u CI ortamında veya kendi sunucunuzda çalıştırabilirsiniz. Ancak birinci taraf, hazır genel bulut URL’si sunmaz.

En uygun olduğu yer: Hesap açmadan, çevrimdışı çalışabilen hızlı bir yerel mock isteyen geliştiriciler.

WireMock

WireMock, özellikle hassas istek eşleştirme gereken senaryolar için güçlü bir mocklama aracıdır. JVM ekosisteminde güçlü köklere sahip olsa da bağımsız süreç olarak çalışabilir ve Java dışı projelerde de kullanılabilir.

WireMock ile şu kriterlere göre eşleştirme yapabilirsiniz:

URL pattern
HTTP method
Header
Cookie
Query parametreleri
JSON body içeriği

Örnek stub mantığı:

{
  "request": {
    "method": "GET",
    "url": "/users/123"
  },
  "response": {
    "status": 200,
    "jsonBody": {
      "id": 123,
      "name": "Mehmet"
    }
  }
}

WireMock ayrıca şunları destekler:

Yanıt şablonlama
Hata enjeksiyonu
Proxy kullanımı
Record/replay
Container tabanlı çalışma
WireMock Cloud ile barındırılan URL

Buna karşılık kurulum maliyeti daha yüksektir. Stub’lar genellikle JSON dosyaları veya kod ile tanımlanır. Bu nedenle hızlı demo mock’larından çok, sürüm kontrolünde tutulan ciddi test altyapıları için uygundur.

Bu yaklaşım, CI/CD’de API testlerini otomatikleştirme süreçleriyle iyi eşleşir.

En uygun olduğu yer: Hassas request matching ve sürüm kontrollü mock isteyen mühendislik ekipleri.

Beeceptor

Beeceptor, genel bir mock URL’ye en hızlı şekilde ulaşmak için kullanılan bulut öncelikli bir araçtır.

Temel akış:

Tarayıcıda endpoint adı seçin.
Beeceptor size genel bir URL verir.
Mock kurallarını web arayüzünden tanımlayın.
Gelen istekleri UI üzerinden inceleyin.

Örnek kullanım:

https://your-endpoint.free.beeceptor.com/users

Beeceptor şu senaryolarda pratiktir:

Hızlı demo hazırlama
Webhook yakalama
Üçüncü taraf callback testleri
Backend hazır olmadan frontend test etme
Belirli path’leri mock edip diğerlerini gerçek backend’e proxy etme

Ancak Beeceptor tamamen barındırılan bir araç olduğu için çevrimdışı geliştirme veya izole CI testleri için daha az uygundur. Ücretsiz katmanda istek hacmi ve kural sayısı sınırlıdır.

En uygun olduğu yer: Kurulum yapmadan hızlı genel mock URL, demo ve webhook yakalama isteyen ekipler.

Postman

Postman, kaydedilmiş bir koleksiyondan mock sunucu oluşturabilir. Her request için örnek response tanımlarsınız, koleksiyonu mock olarak yayınlarsınız ve Postman genel bir URL sağlar.

Tipik akış:

Collection oluşturun.
Request ekleyin.
Her request için example response tanımlayın.
Collection’dan mock server oluşturun.
Postman’ın verdiği URL’yi uygulamanızda kullanın.

Postman mock sunucusu, gelen isteğe en uygun örnek yanıtı döndürür.

Bu yaklaşım özellikle zaten Postman koleksiyonlarıyla çalışan ekipler için pratiktir. Ancak kurulum Apidog’a göre daha manueldir:

Her örnek yanıtı kendiniz tanımlarsınız.
Koşullu mantık daha sınırlıdır.
Dinamik değerler Postman değişkenleriyle mümkündür ancak manuel bağlantı gerekir.

Postman alternatiflerini değerlendiren ekipler genellikle API testi için Postman alternatiflerini de inceler.

En uygun olduğu yer: Zaten Postman koleksiyonları kullanan ve hızlı bir barındırılan mock isteyen ekipler.

Yan yana karşılaştırma

Araç	Barındırma	Otomatik oluşturulan veri	Koşullu yanıtlar	Kurulum çabası	Ücretsiz katman
Apidog	Bulut + yerel	Evet, alan adlarından	Evet, Gelişmiş Mock	Çok düşük	Cömert
Mockoon	Yerel + kendi kendine barındırma	Evet, Faker.js	Evet, kural tabanlı	Düşük	Tamamen ücretsiz
WireMock	Yerel, container, ücretli bulut	Şablonlu	Evet, derin eşleşme	Yüksek	Açık kaynak çekirdeği
Beeceptor	Sadece bulut	Sınırlı şablonlama	Evet, mock kuralları	Çok düşük	Sınırlı hacim
Postman	Bulut	Manuel, değişkenler aracılığıyla	Sınırlı	Orta	Sınırlı çağrı

Nasıl seçilir?

Önce mock sunucunun nerede çalışması gerektiğine karar verin.

Genel URL gerekiyorsa

Şu durumlarda bulut mock daha uygundur:

Mobil uygulama test ediyorsunuz.
Uzaktaki ekip arkadaşınız mock’a erişmeli.
Müşteri demosu yapacaksınız.
Webhook veya callback test ediyorsunuz.

Bu durumda şu araçlara bakın:

Apidog
Beeceptor
Postman

Yerel veya CI mock yeterliyse

Şu durumlarda yerel mock daha uygundur:

Frontend geliştirmeyi lokal yürütüyorsunuz.
Testleri izole tutmak istiyorsunuz.
Çevrimdışı çalışmanız gerekiyor.
Mock’ları Docker veya CI içinde çalıştırmak istiyorsunuz.

Bu durumda şu araçlar öne çıkar:

Mockoon
WireMock

Kurulum hızı mı, kontrol mü?

Araç seçerken ikinci karar noktası kurulum hızı ve kontrol seviyesidir.

En hızlı genel URL        -> Beeceptor
Tasarım odaklı otomatik mock -> Apidog
Yerel GUI ile hızlı mock  -> Mockoon
Kodla yönetilen güçlü mock -> WireMock
Mevcut koleksiyonlardan mock -> Postman

Beeceptor ve Apidog sizi dakikalar içinde çalışan bir mock’a ulaştırır. WireMock daha fazla başlangıç eforu ister ancak hassas eşleştirme ve sürüm kontrollü stub’lar sunar. Mockoon, kullanıcı dostu GUI ile pratik bir orta yol sağlar.

Mock’un API tasarımına bağlı kalması neden önemli?

Bağımsız mock sunucular hızlı stub üretmek için kullanışlıdır. Ancak API tasarımı sık değişiyorsa, mock sunucu spesifikasyondan kopabilir.

Örneğin API sözleşmesi şöyle değişirse:

{
  "id": 1,
- "name": "Ayşe"
+ "full_name": "Ayşe Yılmaz"
}

Mock hâlâ eski name alanını döndürüyorsa frontend testleriniz yanıltıcı olabilir.

Apidog, mock sunucuyu canlı API tasarımından üretir. Böylece sözleşme değişiklikleri mock tarafına da yansır. Ayrıca gerçekçi veri üretimi sayesinde her response payload’unu elle yazma ihtiyacı azalır.

Tasarım, mock ve test akışını birlikte denemek için Apidog’u İndirin. Daha geniş bir araç listesi için REST API mocklama araçları rehberine, test tarafı için ise ücretsiz çevrimiçi API test araçlarına bakabilirsiniz.

Hızlı seçim rehberi

Aşağıdaki senaryolardan size en yakın olanı seçin:

Bir dakikadan kısa sürede genel URL istiyorum: Beeceptor
Hesap gerektirmeyen ücretsiz yerel mock istiyorum: Mockoon
Hassas request matching ve sürüm kontrollü stub istiyorum: WireMock
Ekibim zaten Postman koleksiyonları kullanıyor: Postman
API tasarımından otomatik mock, gerçekçi veri ve test akışı istiyorum: Apidog

Mock veri kalitesi hakkında bir not

Mock sunucunun döndürdüğü veri, aracın pratik değerini belirler.

Şu tarz bir response teknik olarak mock’tur:

{
  "name": "string",
  "id": 0
}

Ancak gerçek istemci davranışını test etmek için çoğu zaman yeterli değildir. Daha faydalı bir mock şu şekilde görünmelidir:

{
  "id": 42,
  "name": "Zeynep Kaya",
  "email": "zeynep.kaya@example.com",
  "created_at": "2024-05-20T12:30:00Z"
}

Araçların yaklaşımı farklıdır:

Apidog: Alan adlarından anlam çıkararak veri üretir.
Mockoon: Faker.js şablonlarıyla gerçekçi veri üretir.
WireMock: Yanıt şablonlama sağlar ancak yapılandırma gerekir.
Postman: Değişkenler kullanılabilir ancak manuel bağlantı gerekir.
Beeceptor: Sınırlı şablonlama sunar.

Bir aracı değerlendirirken sadece mock’un çalışıp çalışmadığına bakmayın. Bir request gönderin ve response body’yi inceleyin. Veri gerçekçi değilse, bu mock’a karşı yazılan testlerin değeri de sınırlı olur.

Sıkça sorulan sorular

Bulut ve yerel API mock’u arasındaki fark nedir?

Bulut mock’u sağlayıcının sunucularında çalışır ve genel bir URL sağlar. Mobil testler, uzaktan ekip çalışması ve demolar için uygundur.

Yerel mock kendi makinenizde, Docker container’da veya CI runner’da çalışır. Daha hızlıdır, çevrimdışı kullanılabilir ve testleri izole tutar.

Hangi mocklama aracı en az kurulum gerektirir?

Beeceptor ve Apidog en hızlı seçeneklerdir.

Beeceptor, endpoint adı seçtiğiniz anda genel bir URL verir. Apidog ise API tasarımınızdan ayrı bir mock sunucu yapılandırması yapmadan otomatik mock üretir.

WireMock sadece Java projeleri için mi?

Hayır. WireMock JVM kökenli olsa da bağımsız süreç olarak çalışabilir, Docker imajı sunar ve HTTP API üzerinden kullanılabilir. Stub’lar JSON formatında tanımlanabildiği için farklı dillerle çalışan ekipler için de uygundur.

Bu araçlar gerçekçi verileri otomatik olarak oluşturabilir mi?

Apidog ve Mockoon bu konuda öne çıkar.

Apidog, email, phone, created_at gibi alan adlarından veri üretir. Mockoon ise Faker.js şablonlamasını kullanır. WireMock yanıt şablonlama destekler. Postman tarafında değişkenler kullanılabilir ancak manuel tanımlama gerekir.

Ekibim zaten Postman kullanıyorsa Postman’ın mock sunucusunu kullanmalı mıyım?

Kullanabilirsiniz. Mock’un mevcut koleksiyonlarınızın yanında durması pratiktir.

Ancak response example’ları manuel tanımlanır ve koşullu mantık sınırlıdır. Otomatik veri üretimi, kural tabanlı yanıtlar veya API tasarımına bağlı mock istiyorsanız özel bir mocklama aracı daha verimli olabilir.

Postman CLI mi Newman mı: Hangi Komut Satırı Aracı Kullanılmalı?

Tobias Hoffmann — Fri, 22 May 2026 07:28:13 +0000

Yıllardır Postman koleksiyonlarını masaüstü uygulaması dışında çalıştırmanın pratik yolu Newman’dı. Postman CLI çıktıktan sonra aynı ihtiyacı karşılayan iki seçenek oluştu: Her ikisi de koleksiyonları GUI olmadan çalıştırır, CI/CD içinde kullanılabilir ve pm.test doğrulamalarını yürütür. Fark, aracı nerede konumlandırdığınızda ortaya çıkar: bağımsız bir runner mı istiyorsunuz, yoksa Postman bulutuna bağlı bir pipeline aracı mı?

Apidog'u bugün deneyin

Kısa karar özeti:

Newman: Açık kaynaklı, npm tabanlı, hesap gerektirmeyen koleksiyon çalıştırıcıdır.
Postman CLI: Postman hesabına/API anahtarına bağlıdır, çalıştırma sonuçlarını Postman platformuna raporlar.
Newman testleri repo içinde JSON dosyalarıyla sürümlemek isteyen ekipler için daha doğaldır.
Postman CLI Postman çalışma alanını doğruluk kaynağı yapan ve yönetişim/linting kontrollerini pipeline’a eklemek isteyen ekipler için daha uygundur.

Newman Nedir?

Newman, Postman koleksiyonlarını komut satırından çalıştıran orijinal runner’dır. npm paketi olarak kurulur, açık kaynaklıdır ve Postman hesabı gerektirmez.

Temel kullanım:

npm install -g newman

newman run checkout-api.postman_collection.json \
  --environment staging.postman_environment.json

Bu komut:

Koleksiyon JSON dosyasını okur.
Ortam değişkenlerini yükler.
İstekleri sırayla çalıştırır.
pm.test bloklarını yürütür.
Test hatası varsa sıfır olmayan exit code döndürür.

CI/CD açısından önemli olan son adımdır. Örneğin GitHub Actions, Jenkins veya GitLab CI’da Newman başarısız olduğunda pipeline da başarısız olur.

Newman’ın güçlü tarafı bağımsızlığıdır. Şunlara ihtiyaç duymaz:

Postman hesabı
API anahtarı
Postman bulutuna erişim
Çalışma alanı senkronizasyonu

Bu nedenle kapalı ağlarda, regülasyonlu ortamlarda veya testlerin tamamen repo içinde tutulduğu yapılarda öngörülebilir bir seçenektir.

Newman ayrıca raporlama tarafında esnektir. Yerleşik CLI ve JUnit çıktısına ek olarak topluluk raporlayıcıları kullanılabilir:

npm install -g newman-reporter-htmlextra

newman run checkout-api.postman_collection.json \
  --environment staging.postman_environment.json \
  -r cli,htmlextra \
  --reporter-htmlextra-export reports/api-test-report.html

Daha fazla bağlam için Newman ve Postman arasındaki fark rehberine bakabilirsiniz.

Postman CLI Nedir?

Postman CLI, Postman’ın resmi komut satırı aracıdır. Newman’dan farklı olarak npm paketi değildir; kurulum betiğiyle yüklenen tek bir yürütülebilir dosya olarak gelir.

Örnek kurulum ve kullanım:

# macOS/Linux örneği
curl -o- "https://dl-cli.pstmn.io/install/osx_64.sh" | sh

# kimlik doğrulama
postman login --with-api-key YOUR_API_KEY

# koleksiyon çalıştırma
postman collection run checkout-api

Postman CLI’ın temel farkı bulut entegrasyonudur. Koleksiyonları Postman çalışma alanınızdan kimlik bazında çekebilir ve çalıştırma sonuçlarını Postman platformuna geri gönderebilir.

Bu modelde tipik akış şöyledir:

Koleksiyon Postman workspace içinde tutulur.
CI ortamında Postman API key secret olarak saklanır.
Pipeline postman login ile kimlik doğrular.
Koleksiyon Postman’dan çekilir.
Sonuçlar Postman platformuna raporlanır.

Postman CLI yalnızca bir koleksiyon runner’ı değildir. Postman platformuna bağlı bir pipeline aracısı gibi çalışır. Özellikle API yönetişimi, linting ve merkezi çalıştırma geçmişi isteyen ekipler için anlamlıdır.

Newman ve Postman CLI Karşılaştırması

Yön	Postman CLI	Newman
Kaynak	Kapalı kaynak, resmi Postman aracı	Açık kaynak
Kurulum	Kurulum betiği, tek executable	npm paketi
Postman hesabı	Gerekli	Gerekli değil
Kimlik doğrulama	API anahtarı ile	Yok
Koleksiyon kaynağı	Postman bulutu veya yerel dosya	Yerel JSON dosyası
Sonuç raporlama	Postman platformuna	Terminal, JUnit, HTML vb.
API yönetişimi/linting	Dahili	Dahil değil
Raporlayıcılar	Daha sınırlı, Postman odaklı	CLI, JUnit, topluluk HTML raporlayıcıları
Çevrimdışı kullanım	Sınırlı	Yerel dosyalarla tamamen mümkün
Olgunluk	Daha yeni	Uzun süredir kullanılan topluluk standardı
Maliyet	Ücretsiz kullanılabilir, Postman plan limitlerine bağlıdır	Ücretsiz, hesap gerektirmez

Kararı belirleyen ana fark şudur:

Newman, “elimde bir koleksiyon dosyası var, bunu çalıştır ve sonucu pipeline’a bildir” yaklaşımını izler.
Postman CLI, “Postman workspace içindeki koleksiyonu çalıştır, sonucu Postman platformuna geri gönder” yaklaşımını izler.

CI/CD İçinde Nasıl Kullanılır?

Her iki araç da Jenkins, GitHub Actions, GitLab CI, CircleCI ve benzeri CI sağlayıcılarında çalışır. Ancak pipeline tasarımı farklıdır.

Newman ile CI/CD Akışı

Newman kullandığınızda koleksiyon ve environment dosyalarını genellikle repo’ya koyarsınız:

.
├── .github/
│   └── workflows/
│       └── api-tests.yml
├── tests/
│   ├── checkout-api.postman_collection.json
│   └── staging.postman_environment.json
└── package.json

GitHub Actions örneği:

name: API Tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  newman:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repo
        uses: actions/checkout@v4

      - name: Install Newman
        run: npm install -g newman

      - name: Run API tests
        run: |
          newman run tests/checkout-api.postman_collection.json \
            --environment tests/staging.postman_environment.json

JUnit çıktısı üretmek isterseniz:

      - name: Run API tests with JUnit report
        run: |
          newman run tests/checkout-api.postman_collection.json \
            --environment tests/staging.postman_environment.json \
            -r cli,junit \
            --reporter-junit-export reports/newman-results.xml

Bu modelin avantajı:

Testler kodla birlikte sürümlenir.
Pull request içinde test değişiklikleri incelenebilir.
Postman hesabı veya bulut erişimi gerekmez.
Pipeline daha az dış bağımlılığa sahiptir.

Bu yaklaşım hakkında daha fazla örnek için CI/CD’de API testlerini otomatikleştirme ve GitHub Actions ile API test otomasyonu rehberlerine bakabilirsiniz.

Postman CLI ile CI/CD Akışı

Postman CLI kullandığınızda genellikle koleksiyon Postman workspace içinde tutulur. CI tarafında API anahtarını secret olarak saklarsınız.

Örnek GitHub Actions akışı:

name: API Tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  postman-cli:
    runs-on: ubuntu-latest

    steps:
      - name: Install Postman CLI
        run: |
          curl -o- "https://dl-cli.pstmn.io/install/linux64.sh" | sh

      - name: Login to Postman
        run: postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}

      - name: Run collection
        run: postman collection run checkout-api

Bu modelin avantajı:

Koleksiyon Postman workspace içinde merkezi kalır.
Çalıştırma geçmişi Postman platformunda görülebilir.
Dashboard ve ekip görünürlüğü Postman üzerinden yönetilebilir.
API yönetişimi/linting kontrolleri pipeline’a eklenebilir.

Ancak şu bağımlılıkları kabul etmiş olursunuz:

CI ortamı Postman’a erişebilmelidir.
API anahtarı secret olarak yönetilmelidir.
Doğruluk kaynağı repo yerine Postman workspace olabilir.
Sonuç raporlama Postman platformuna bağlı hale gelir.

Doğruluk Kaynağı: Repo mu, Postman Workspace mi?

Seçim yapmadan önce şu soruyu netleştirin:

API testlerinin doğruluk kaynağı nerede olmalı?

Eğer cevap Git repo ise Newman daha uygun olur. Koleksiyon dosyaları, environment dosyaları ve test değişiklikleri kodla birlikte sürümlenir.

Eğer cevap Postman workspace ise Postman CLI daha uygun olur. Koleksiyonlar Postman’da yönetilir, pipeline da bunları oradan çalıştırır.

Pratik fark şudur:

Newman modeli:
Repo → CI → Newman → rapor dosyaları / exit code

Postman CLI modeli:
Postman Workspace → CI → Postman CLI → Postman platformu

Bu fark küçük görünür, ancak ekip süreçlerini doğrudan etkiler.

API Yönetişimi ve Linting

Newman ve Postman CLI arasındaki en belirgin farklardan biri API yönetişimidir.

Postman CLI, Postman workspace içindeki API tanımları üzerinde linting ve governance kontrolleri çalıştırabilir. Bu kontroller adlandırma, güvenlik, şema tutarlılığı ve organizasyon kuralları gibi alanlarda kullanılabilir.

Pipeline içinde bu şu anlama gelir:

API tanımı güncellenir.
CI çalışır.
Postman CLI linting/governance kontrolünü yürütür.
Kural ihlali varsa build başarısız olur.

Newman’da bunun doğrudan karşılığı yoktur. Newman koleksiyonları çalıştırır, test sonuçlarını raporlar ve exit code döndürür. API tasarım standartlarını denetlemek Newman’ın kapsamı dışındadır.

Bu nedenle:

Sadece endpoint testleri çalıştıracaksanız Newman yeterlidir.
API tasarım kurallarını pipeline’da zorunlu kılacaksanız Postman CLI daha uygundur.

Geçiş Yapmalı mısınız?

Newman kullanıyorsanız ve mevcut pipeline sorunsuz çalışıyorsa Postman CLI’a geçmek zorunda değilsiniz.

Geçiş şu değişiklikleri gerektirir:

CI ortamına Postman API key eklemek
Koleksiyonların kaynaklandığı yeri değiştirmek
Postman bulutuna bağımlılığı kabul etmek
Raporlama akışını yeniden düzenlemek
Ekipte workspace izinlerini ve erişimleri yönetmek

Aşağıdaki ihtiyaçlardan biri yoksa geçişin getirisi sınırlı olabilir:

Postman platformunda merkezi çalıştırma geçmişi
Postman dashboard’larında sonuç görünürlüğü
API governance/linting kontrolleri
Postman workspace’i doğruluk kaynağı yapma isteği

Yeni başlayan ekipler için karar daha açık şekilde iş akışına bağlıdır.

Postman zaten ana API platformunuzsa ve ekip koleksiyonları orada yönetiyorsa Postman CLI mantıklıdır. Testleri repo içinde tutmak, bağımsız çalışmak ve vendor bağımlılığını azaltmak istiyorsanız Newman daha doğal bir başlangıçtır.

Hangi Aracı Seçmelisiniz?

Newman’ı seçin, eğer:

Postman hesabı olmadan çalışmak istiyorsanız
Koleksiyonları repo içinde sürümlemek istiyorsanız
CI ortamınızın Postman bulutuna erişmesini istemiyorsanız
JUnit veya HTML gibi dosya tabanlı raporlara ihtiyacınız varsa
Açık kaynaklı ve olgun bir runner tercih ediyorsanız
Kapalı veya kısıtlı ağlarda test çalıştırıyorsanız

Postman CLI’ı seçin, eğer:

Ekibiniz Postman workspace içinde çalışıyorsa
Çalıştırma geçmişini Postman platformunda görmek istiyorsanız
API governance/linting kontrollerini pipeline’a eklemek istiyorsanız
Koleksiyonların merkezi olarak Postman’da yönetilmesini tercih ediyorsanız
Postman dashboard ve ekip görünürlüğü sizin için önemliyse

Postman ekosistemine bağlı kalmadan alternatif yaklaşımları da değerlendirmek istiyorsanız Newman olmadan CI’da Postman koleksiyonlarını çalıştırma ve Postman olmadan API testi yazılarına göz atabilirsiniz.

Tek Araç Alternatifi: Apidog

Hem Newman hem de Postman CLI, testlerinizi Postman koleksiyonları etrafında kurguladığınızı varsayar. Apidog farklı bir yaklaşım sunar: API tasarımı, istek hata ayıklama, otomatik test senaryoları ve CI/CD çalıştırma akışı aynı ürün içinde yer alır.

Bu modelde ayrı bir dışa aktarma veya ayrı runner paketi kullanmanız gerekmez. Test tanımları ve yürütme motoru aynı platformun parçasıdır.

Tipik akış:

API endpoint’lerini tasarlayın.
İstekleri Apidog içinde test edin.
Görsel doğrulamalarla test senaryoları oluşturun.
Senaryoları CI/CD içinde CLI runner ile çalıştırın.
API tasarımı, mock server ve performans testlerini aynı akışta yönetin.

Apidog ayrıca API tasarımı, mock server’lar ve performans testlerini de kapsar. Böylece ekipler API yaşam döngüsünü birden fazla aracı birleştirmeden yönetebilir. Apidog’u indirebilir ve pipeline’lar için CLI runner dahil test özelliklerini kullanabilirsiniz.

Sıkça Sorulan Sorular

Postman CLI, Newman’ın yerini mi alıyor?

Postman, Postman CLI’ı resmi komut satırı aracı olarak konumlandırıyor. Ancak Newman hâlâ kullanılan ve bakımı devam eden bir araçtır. Hesap gerektirmeyen, repo içinde sürümlenen ve bağımsız çalışan bir runner istiyorsanız Newman hâlâ güçlü bir seçenektir.

Postman CLI Postman hesabı gerektiriyor mu?

Evet. Postman CLI, Postman API anahtarı ile kimlik doğrulaması yapar ve çalıştırmaları Postman workspace’inize bağlamak üzere tasarlanmıştır. Newman ise hesap gerektirmez; yerel koleksiyon JSON dosyasıyla çalışabilir.

Hangi araç daha iyi raporlama sunar?

İhtiyaca göre değişir.

Newman, dosya tabanlı raporlama açısından daha esnektir. JUnit XML, CLI çıktısı ve newman-reporter-htmlextra gibi HTML raporlayıcıları kullanabilirsiniz.

Postman CLI ise sonuçları Postman platformuna raporlar. Ekibiniz sonuçları Postman dashboard’larında görmek istiyorsa bu avantajdır; bağımsız rapor dosyaları istiyorsanız Newman daha pratiktir.

Postman CLI yerel koleksiyon dosyası çalıştırabilir mi?

Evet, Postman CLI yerel koleksiyon dosyalarını çalıştırabilir. Ancak tasarım olarak Postman workspace ile entegre çalışmaya ve sonuçları platforma raporlamaya odaklanır. Yerel JSON dosyalarını ana doğruluk kaynağı yapmak istiyorsanız Newman bu modele daha doğal uyar.

CI’da hangisi daha hızlıdır?

Saf koleksiyon yürütmesinde fark genellikle büyük değildir. Newman daha küçük bir ayak izine sahiptir ve bulut senkronizasyonu gerektirmez. Postman CLI ise kimlik doğrulama ve sonuçları Postman platformuna gönderme gibi ek adımlar içerir.

Çoğu ekip için ham hızdan çok iş akışı uyumu daha önemlidir:

Repo merkezli testler için Newman
Postman workspace merkezli testler için Postman CLI