Yazılım Test Mühendisliği Dersleri

Yazılım Test Mühendisliği Dersleri: Bölüm 8

API ve Veritabanı Testleri | REST, SOAP, SQL, HTTP Durum Kodları, Postman | yazilimtestmuhendisligi.com

API ve Veritabanı Testleri: REST, SOAP, SQL, HTTP Durum Kodları ve Postman

Modern uygulamaların çoğu, arayüzün arkasında API’ler ve veritabanları aracılığıyla konuşur. Bu rehberde REST ve SOAP mimarilerini, HTTP durum kodlarını, Postman ile API testini ve SQL ile veritabanı doğrulama yöntemlerini adım adım ele alıyoruz.

REST SOAP HTTP Durum Kodları Postman SQL

i API ve Veritabanı Testlerine Giriş

Bir web veya mobil uygulamanın arayüzü (UI) ne kadar kusursuz görünürse görünsün, verinin doğru şekilde taşındığı ve saklandığından emin olmadan yazılımın güvenilir olduğu söylenemez. API testleri, uygulamanın “beyni” olan servis katmanını; veritabanı testleri ise verinin doğru şekilde depolandığı ve tutarlı kaldığı “hafızasını” doğrular.

API testleri, UI testlerine göre genellikle daha hızlı, daha kararlı (flaky olmaya daha az meyilli) ve daha erken aşamada (UI hazır olmadan bile) yazılabilir — bu da onları test piramidinin orta katmanının vazgeçilmez bir parçası yapar.

Bu sayfada iki API mimari yaklaşımını (REST ve SOAP), API yanıtlarını yorumlamak için kritik olan HTTP durum kodlarını, en yaygın API test aracı olan Postman‘i ve son olarak SQL ile veritabanı doğrulama tekniklerini inceliyoruz.

1 REST vs SOAP Mimarileri

Sistemler arası iletişimde en yaygın kullanılan iki API mimarisi REST (Representational State Transfer) ve SOAP‘tur (Simple Object Access Protocol). İkisi de farklı prensiplerle çalışır ve farklı test yaklaşımları gerektirir.

REST

  • Mimari stildir, katı bir protokol değildir
  • Veri formatı genellikle JSON (bazen XML)
  • HTTP metodlarını (GET, POST, PUT, DELETE) doğrudan kullanır
  • Stateless (durumsuz) — her istek bağımsızdır
  • Daha hafif, hızlı ve mobil/web uygulamalarda yaygın

SOAP

  • Katı bir protokoldür, XML tabanlı mesajlaşma zorunludur
  • Veri formatı her zaman XML (Envelope, Header, Body yapısı)
  • Genellikle sadece HTTP değil, SMTP gibi farklı taşıma katmanlarını da destekler
  • Yerleşik hata işleme (SOAP Fault) ve WS-Security gibi standartları vardır
  • Bankacılık, sigorta gibi yüksek güvenlik/işlem garantisi gereken sistemlerde tercih edilir

Örnek İstek Karşılaştırması

// REST - JSON isteği (POST /musteriler)
{
  "ad": "Ayşe Yılmaz",
  "eposta": "ayse@ornek.com",
  "aktif": true
}



  
    
      Ayşe Yılmaz
      ayse@ornek.com
    
  

Test mühendisi için fark: REST testlerinde genellikle JSON şeması doğrulaması ve HTTP durum kodu kontrolü yapılırken; SOAP testlerinde XML şema (XSD) doğrulaması ve SOAP Fault mesajlarının doğru formatlanıp formatlanmadığı kontrol edilir.

2 HTTP Durum Kodları

Her API yanıtı, isteğin sonucunu özetleyen 3 haneli bir HTTP durum kodu döndürür. Bu kodları doğru yorumlamak, API test senaryolarının temelini oluşturur.

1xx — Bilgilendirme

100Continue
101Switching Protocols

2xx — Başarılı

200OK
201Created
204No Content

3xx — Yönlendirme

301Moved Permanently
304Not Modified

4xx — İstemci Hatası

400Bad Request
401Unauthorized
403Forbidden
404Not Found
429Too Many Requests

5xx — Sunucu Hatası

500Internal Server Error
502Bad Gateway
503Service Unavailable
KodAnlamıTest Senaryosu Örneği
200 OKİstek başarılı, veri döndüGeçerli bir GET isteği doğru veriyle yanıt vermeli
201 CreatedYeni kayıt başarıyla oluşturulduGeçerli veriyle POST isteği yeni kaynak oluşturmalı ve ID döndürmeli
400 Bad Requestİstek formatı/verisi hatalıZorunlu alan eksik gönderildiğinde 400 dönmeli
401 UnauthorizedKimlik doğrulama başarısızGeçersiz veya süresi dolmuş token ile istek 401 dönmeli
404 Not FoundKaynak bulunamadıVar olmayan bir ID ile GET isteği 404 dönmeli
500 Internal Server ErrorSunucu tarafında beklenmeyen hataBu kodun asla normal senaryolarda dönmemesi beklenir — dönerse kritik bug’dır
Dikkat: Bir API her hata durumunda 200 OK dönüp hatayı yalnızca response body içinde belirtiyorsa, bu genellikle kötü bir API tasarım pratiğidir ve test otomasyonunu (özellikle durum koduna göre assertion yapan araçları) yanıltabilir. Test mühendisi bu tür durumları erken tespit edip geliştirme ekibine bildirmelidir.

3 Postman ile API Testi

Postman, API isteklerini göndermek, yanıtları incelemek ve test senaryolarını (assertion’ları) JavaScript ile otomatikleştirmek için en yaygın kullanılan araçlardan biridir.

POST https://api.ornek-magaza.com/v1/siparisler Send
Body
Headers
Params
Tests
Status: 201 Created  ·  Time: 184 ms  ·  Size: 312 B
{
  "siparisId": "SIP-10245",
  "durum": "OLUSTURULDU",
  "toplamTutar": 249.90,
  "olusturmaTarihi": "2026-09-08T10:15:00Z"
}

Postman Test Script Örneği (Tests Sekmesi)

// Postman "Tests" sekmesine yazılan JavaScript doğrulamaları
pm.test("Durum kodu 201 olmalı", function () {
    pm.response.to.have.status(201);
});

pm.test("Yanıt süresi 500ms altında olmalı", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.test("Sipariş ID formatı doğru olmalı", function () {
    const body = pm.response.json();
    pm.expect(body.siparisId).to.match(/^SIP-\d+$/);
});

pm.test("Toplam tutar pozitif olmalı", function () {
    const body = pm.response.json();
    pm.expect(body.toplamTutar).to.be.above(0);
});

Postman’in Collections özelliği, ilişkili istekleri bir arada gruplamayı; Environments özelliği ise aynı testleri farklı ortamlarda (test, staging, production) değişken kullanarak koşmayı sağlar. Collection Runner veya komut satırı aracı Newman ile bu koleksiyonlar CI/CD boru hattına entegre edilerek her build’de otomatik koşturulabilir.

İpucu: Bir API’yi test ederken sadece “mutlu yol” (happy path) senaryosunu değil; eksik zorunlu alan, yanlış veri tipi, yetkisiz erişim, aşırı büyük payload ve sınır değer (boundary) senaryolarını da mutlaka Postman koleksiyonuna ekleyin.

4 SQL ve Veritabanı Testleri

API üzerinden yapılan bir işlemin (örn. sipariş oluşturma), veritabanında da doğru şekilde yansıdığını doğrulamak, uçtan uca veri bütünlüğünü garanti eder. Bu genellikle doğrudan SQL sorguları ile yapılır.

Tipik Veritabanı Test Senaryoları

-- 1. API'den oluşturulan siparişin veritabanında var olduğunu doğrulama
SELECT siparis_id, durum, toplam_tutar
FROM siparisler
WHERE siparis_id = 'SIP-10245';

-- 2. Sipariş kalemlerinin toplamının, sipariş toplamıyla eşleştiğini doğrulama
SELECT s.siparis_id, s.toplam_tutar,
       SUM(sk.adet * sk.birim_fiyat) AS hesaplanan_toplam
FROM siparisler s
JOIN siparis_kalemleri sk ON s.siparis_id = sk.siparis_id
WHERE s.siparis_id = 'SIP-10245'
GROUP BY s.siparis_id, s.toplam_tutar
HAVING s.toplam_tutar != SUM(sk.adet * sk.birim_fiyat);
-- Bu sorgu satır döndürüyorsa, veri tutarsızlığı (bug) var demektir

-- 3. Silinen bir kaydın (soft delete) veritabanında hâlâ görünür olmadığını doğrulama
SELECT * FROM musteriler
WHERE musteri_id = 4821 AND silindi_mi = 0;

Veritabanı Testinde Odaklanılması Gereken Alanlar

  • Veri Bütünlüğü (Data Integrity): Foreign key ilişkileri, hesaplanan alanların doğruluğu
  • CRUD İşlemleri: Create, Read, Update, Delete işlemlerinin veritabanına doğru yansıdığının kontrolü
  • Transaction (İşlem) Bütünlüğü: Hata durumunda kısmi kayıt oluşmadan tüm işlemin geri alınması (rollback)
  • Kısıtlamalar (Constraints): Unique, not null, check constraint’lerin doğru çalışması
  • Performans: Büyük veri setlerinde sorgu sürelerinin kabul edilebilir sınırlar içinde kalması
API + Veritabanı testi birlikte nasıl kurgulanır? Tipik bir uçtan uca test akışı şöyledir: (1) API’ye istek gönder, (2) API yanıtını doğrula (durum kodu, response body), (3) doğrudan veritabanına bağlanıp ilgili kaydı SQL ile sorgula, (4) API’nin döndürdüğü veri ile veritabanındaki gerçek veriyi karşılaştır.

Sonuç ve Öneriler

API ve veritabanı testleri, kullanıcı arayüzünün arkasındaki mantığın ve verinin doğruluğunu garanti eden kritik bir test katmanıdır. REST ve SOAP mimarilerinin farklarını bilmek, doğru test yaklaşımını seçmeyi; HTTP durum kodlarını doğru yorumlamak, API davranışını net bir şekilde doğrulamayı sağlar.

Postman gibi araçlar, hem manuel keşif testleri hem de otomatikleştirilmiş regresyon testleri için hızlı ve pratik bir ortam sunar. Ancak API seviyesinde “yeşil” görünen bir test, verinin veritabanında da tutarlı olduğunu garanti etmez — bu yüzden kritik akışlarda SQL doğrulaması ile API testlerini birleştirmek, test kapsamının en zayıf halkasını (veri bütünlüğü) de güvence altına alır.

Altın kural: Her yeni API endpoint’i için en az şu dört senaryoyu test edin: (1) geçerli veriyle başarılı senaryo, (2) eksik/hatalı veriyle 4xx senaryosu, (3) yetkisiz erişim senaryosu, (4) API sonucunun veritabanındaki gerçek veriyle tutarlılığı. Bu dörtlü, çoğu üretim hatasının önüne geçer.
Başa Dön →

yazilimtestmuhendisligi.com — Nihat Ük

Bu içerik eğitim amaçlı hazırlanmıştır. © 2026

Yorum bırakın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir