Kazanimlar:
- API testini durum kodu, şema/sözleşme, iş kuralı ve negatif/yetki katmanlarında yapay zeka desteğiyle derinlemesine kurabilme
- Örnek yanıttan JSON şeması üretip tip ve zorunluluk doğrulamasıyla yalnızca durum koduna bakmanın verdiği sahte-güvenden kaçınabilme
- Yetkilendirme ve IDOR gibi güvenlik senaryolarını sentetik veriyle ve yalnızca yetki dâhilinde savunma amaçlı test edebilme
Modern yazılımların büyük kısmı, arka planda birbirine API (Application Programming Interface — iki yazılım parçasının belirli bir sözleşmeye göre konuştuğu arayüz) üzerinden konuşur. Bir mobil uygulama sepete ürün eklerken aslında sunucudaki bir API'ye istek gönderir. API testi, bu konuşmanın doğru, güvenli ve tutarlı olduğunu arayüzden bağımsız olarak sınar; UI testinden daha hızlı, daha kararlı ve daha derindir. Yapay zeka (YZ), API testinde çok verimlidir: bir API tanımından test üretir, yanıt şemasını (schema — verinin yapısını tanımlayan sözleşme) çıkarır, kenar durumları listeler. Ama yine merkez uyarı geçerli: YZ, API'nizin gerçek iş kurallarını bilmez; sadece "200 döndü" diye doğrulayan yüzeysel testler üretmeye eğilimlidir. Sizin işiniz, testin gerçek sözleşmeyi ve iş mantığını doğruladığından emin olmaktır.
Bu ünitede Postman, REST Assured ve şema doğrulama gibi yaklaşımlarla YZ destekli, derin API testleri kurmayı öğreneceksiniz.
API testinin katmanları
API testini birkaç derinlikte düşünün, her katmanda YZ farklı yardım eder:
1. Durum kodu ve temel yanıt. İstek beklenen HTTP durum kodunu mu döndürüyor (başarı için 200/201, hata için 400/401/404)? Bu en yüzeysel katmandır; YZ kolayca üretir ama tek başına sahte-güven verir.
2. Şema/sözleşme doğrulama. Yanıtın yapısı sözleşmeye uyuyor mu — beklenen alanlar var mı, tipleri doğru mu, zorunlu alanlar eksik mi? YZ, bir örnek yanıttan JSON Şeması (JSON Schema — bir JSON belgesinin yapısını tanımlayan standart) üretebilir ve testler bu şemaya karşı doğrulama yapabilir. Bu, alan bazlı elle assert yazmaktan çok daha sağlamdır.
3. İş kuralı doğrulama. Asıl değer buradadır: "1000 TL sipariş için indirim alanı 100 olmalı", "iptal edilmiş sipariş tekrar iptal edilememeli". YZ bunları ancak kuralları verirseniz doğrular; vermezseniz atlar.
4. Negatif ve güvenlik. Geçersiz token ile 401, başkasının verisine erişimde 403, hatalı gövdede net 400. Yetkilendirme testleri (bir kullanıcının yalnızca kendi verisine erişebildiğini doğrulama) API güvenliğinin kalbidir ve savunma amaçlı yapılır.
İpucu: YZ'ye "sadece durum kodunu değil, yanıt şemasını ve şu iş kurallarını da doğrula" demeden test istemeyin. Aksi hâlde elinizde "200 döndü, geçti" diyen ama bozuk veri döndüren API'yi fark etmeyen testler kalır.
Zayıf prompt / Güçlü prompt
Zayıf: "Bu API için test yaz."
Güçlü: "POST /siparis uç noktası için REST Assured (Java) testleri yaz. Sözleşme: gövdede urunId ve adet zorunlu; başarıda 201 ve {siparisId, toplam, indirim, durum} döner. İş kuralları: 1000 TL üstü %10 indirim; adet<=0 ise 400; geçersiz token ise 401; başka kullanıcının siparişini görmede 403. Testler: (1) durum kodu, (2) yanıt JSON şeması doğrulaması, (3) indirim iş kuralı, (4) negatif ve yetki senaryoları. Her assert'i açık iş kuralına bağla; sadece 200/201 kontrolüyle yetinme."
Güçlü prompt sözleşmeyi, iş kurallarını, güvenlik senaryolarını ve şema doğrulama beklentisini verir.
Sözleşme testi: ekipler arası kırılmaları önlemek
Mikroservis mimarilerinde (uygulamanın birbirinden bağımsız, API ile konuşan küçük servislere bölündüğü yapı) bir servisin yanıt biçimini değiştirmesi, ona bağlı diğer servisleri sessizce bozar. Sözleşme testi (contract testing — üreten (provider) servis ile tüketen (consumer) servis arasındaki API sözleşmesinin iki tarafta da bozulmadığını doğrulayan test), bu tür kırılmaları erken yakalar. Fikir şudur: tüketici, üreticiden beklediği yanıt biçimini bir "sözleşme" olarak tanımlar; üretici her değişiklikte bu sözleşmeye hâlâ uyduğunu test eder. Böylece bir alanın adı veya tipi değiştiğinde, tüketici çökmeden önce boru hattı uyarır.
YZ bu bağlamda iki işte hızlandırır: mevcut bir API yanıtından tüketici beklentisini yansıtan bir sözleşme taslağı çıkarmak ve bir değişikliğin hangi sözleşme maddesini bozabileceğini önceden işaretlemek. Ancak sözleşmenin kendisi bir iş kararıdır: hangi alanların gerçekten kritik olduğunu, hangi değişikliklerin geriye dönük uyumluluğu (backward compatibility — eski tüketicilerin çalışmaya devam etmesi) bozacağını uzman belirler. YZ sözleşmeyi yazar; onu onaylayan sizsiniz.
İpucu: Bir API'de alan silmek veya alan tipini değiştirmek neredeyse her zaman kırıcı (breaking) bir değişikliktir. Yeni alan eklemek genellikle güvenlidir. YZ'ye bir değişikliği "kırıcı mı, güvenli mi" diye sınıflandırtmak, sürüm öncesi hızlı bir güvenlik kontrolü sağlar.
Postman mı, kod tabanlı mı?
Ölçüt
Postman/Newman
REST Assured / kod (Java, C#, JS)
Öğrenme
Kolay, görsel
Kod bilgisi gerekir
Sürüm kontrolü
Koleksiyon JSON'u
Doğrudan kaynak kodda
Karmaşık mantık
Sınırlı (JS betikleri)
Tam programlama gücü
CI/CD entegrasyonu
Newman ile
Doğrudan build'e bağlı
Şema doğrulama
Test betikleriyle
Kütüphaneyle güçlü
Ekip ölçeği
Küçük/orta
Büyük, olgun
YZ her ikisi için de kod üretir; hangisini istediğinizi net söyleyin.
Dört kopyalanabilir şablon
1) Sözleşme tabanlı API testi:
Rolün: kıdemli API test mühendisi.[Araç/dil] ile şu uç nokta için test yaz: [metot + yol].Sözleşme: [zorunlu alanlar, başarı kodu, yanıt yapısı].İş kuralları: [kurallar].Test katmanları: (1) durum kodu (2) yanıt şeması doğrulaması(3) her iş kuralı (4) negatif + yetkilendirme.Her assert'i ilgili kurala/sözleşme maddesine bağla.
2) Örnek yanıttan şema üretimi:
Aşağıdaki örnek API yanıtından JSON Şeması üret.Zorunlu alanları, tipleri, format kısıtlarını (tarih, e-posta,sayı aralığı) belirt. Sonra bu şemaya karşı doğrulama yapanbir test örneği ver. Örnek yanıt: [JSON yapıştır]
3) Negatif ve yetki senaryoları:
Şu uç nokta için negatif ve güvenlik test senaryoları üret:[uç nokta]. Kapsa: eksik/zorunlu alan, yanlış tip, çok büyük değer,geçersiz/expired token, yetkisiz kaynağa erişim (IDOR — başkasınınkaydına ID değiştirerek erişim), rate limit. Her senaryo içinbeklenen durum kodu ve hata gövdesini belirt.Not: yalnızca kendi API'mde, yetki dahilinde test edilecektir.
4) Sahte-güven denetimi:
Bu API testini incele. Sunucu doğru durum kodunu ama YANLIŞgövde/veri döndürseydi bu test yakalar mıydı? Yakalamıyorsaşema ve iş kuralı doğrulaması ekle. Test: [testi yapıştır]
Üç mini vaka
Vaka 1 — Şema doğrulamanın gücü. Bir ekip, YZ ile ürettiği testlerde sadece durum kodunu kontrol ediyordu. Bir sürümde API, toplam alanını yanlışlıkla metin ("1200") olarak döndürmeye başladı; testler yeşil kaldı çünkü hâlâ 200 dönüyordu. Mobil uygulama çöktü. "Örnek yanıttan şema üretimi" şablonuyla tip doğrulaması eklendikten sonra aynı hata anında yakalanır oldu.
Vaka 2 — Yetki açığı (IDOR). Bir uzman, YZ'nin ürettiği "negatif ve yetki senaryoları" arasında IDOR testini çalıştırdı: A kullanıcısının token'ı ile B kullanıcısının sipariş ID'sini istedi. API 200 ve B'nin verisini döndürdü — ciddi bir yetkilendirme açığı. Savunma amaçlı bu test, veri sızıntısını canlıya çıkmadan kapattı.
Vaka 3 — İş kuralı atlaması. YZ, indirim uç noktası için 8 test üretti; hepsi 200 kontrol ediyordu, hiçbiri indirim tutarını doğrulamıyordu. Uzman, iş kurallarını prompt'a ekleyip yeniden ürettirdi. Yeni testler, 1000 TL sınırında indirimin yanlış hesaplandığını (999'a da indirim uygulandığını) ortaya çıkardı. Sözleşme kontrolü yetmez; iş kuralı kontrolü şarttır.
Sık yapılan hatalar
- Sadece durum koduna bakmak. "200 döndü, geçti" demek; bozuk gövdeyi görmemek (sahte-güven).
- Şema doğrulamayı atlamak. Alan tiplerini ve zorunluluğu kontrol etmemek; tip değişiklikleri sessizce geçer.
- İş kurallarını vermeden test istemek. YZ kuralları bilmez; sadece teknik kontrol üretir.
- Negatif ve yetki senaryolarını unutmak. Güvenlik açıkları (IDOR, yetkisiz erişim) yalnızca bu testlerle yakalanır.
- Gerçek/üretim token'ı ve verisi kullanmak. Test için ayrılmış ortam ve sentetik veri kullanın; gerçek anahtarları araca yapıştırmayın.
- Yetkisiz güvenlik testi. Yetki testlerini yalnızca kendi API'nizde ve izinle yapın.
Özetle
API testi, yazılım parçalarının konuşmasını arayüzden bağımsız, hızlı ve derin biçimde doğrular. YZ; sözleşme testleri, örnek yanıttan JSON şeması ve negatif/güvenlik senaryoları üretmekte çok verimlidir. Ama yalnızca durum kodu kontrol eden yüzeysel testler sahte-güven verir. Dört katmanı birden isteyin: durum kodu, şema doğrulama, iş kuralı, negatif ve yetkilendirme. İş kurallarını ve sözleşmeyi prompt'a koyun; güvenlik testlerini sentetik veriyle ve yalnızca yetki dâhilinde yapın.
Uygulama görevi
Kendi projenizden bir API uç noktası seçin. YZ'ye "sözleşme tabanlı API testi" şablonuyla dört katmanlı test yazdırın. Ardından "örnek yanıttan şema üretimi" ile tip/zorunluluk doğrulaması ekleyin ve "sahte-güven denetimi"ni uygulayın. En az bir IDOR/yetki senaryosunu kendi test ortamınızda çalıştırın. Bulduğunuz her sözleşme veya iş kuralı ihlalini raporlayın; hiç bulamadıysanız testi kasten bozuk bir yanıta karşı çalıştırıp yakaladığını kanıtlayın.
Kontrol listesi
- [ ] Testin dört katmanını (durum, şema, iş kuralı, negatif/yetki) kapsadım.
- [ ] Sözleşmeyi ve iş kurallarını YZ'ye açıkça verdim.
- [ ] Yanıt şemasını (alan, tip, zorunluluk) doğrulayan testler kurdum.
- [ ] En az bir yetkilendirme/IDOR senaryosunu savunma amaçlı denedim.
- [ ] Gerçek token/veri yerine test ortamı ve sentetik veri kullandım.
- [ ] Her testin bozuk yanıtı yakaladığını "sahte-güven denetimi" ile kanıtladım.