DEV Community

Cover image for Yapay Zeka API Testlerinin Yerini Alabilir mi? Ajanlar Neler Yapabilir, Neler Yapamaz
Tobias Hoffmann
Tobias Hoffmann

Posted on • Originally published at apidog.com

Yapay Zeka API Testlerinin Yerini Alabilir mi? Ajanlar Neler Yapabilir, Neler Yapamaz

Ajanınız testi yazdı. Cursor aklınıza gelmeyen üç uç durumu önerdi. Copilot istek gövdesini doldurdu ve Claude her şeyi bir kez çalıştırıp başarılı olduğunu bildirdi. Peki ajan tüm bunları yapıyorsa, yapay zeka API testini tamamen ikame edebilir mi?

Apidog'u bugün deneyin

Hayır. Yapay zeka API testini tamamen ikame edemez; ancak test yazımının büyük bölümünü üstlenebilir. Ajanlar test senaryoları taslakları oluşturur, uç durumlar önerir ve istek gövdelerini hazırlar. Buna karşılık her çalıştırmada aynı sonucu üretme, merge işlemini başarılı/başarısız sonucuna göre engelleme ve sözleşmenin doğru olduğuna karar verme işleri hâlâ deterministik bir araç ve insan değerlendirmesi gerektirir.

Bu ayrım, daha geniş bir sorunun parçasıdır: Yapay zeka ajanları çağında hâlâ bir API aracına ihtiyacınız var mı? Yapay zekanın üstlendiği işle, deterministik araçların üstlenmesi gereken iş arasında net bir sınır vardır. Bu sınırı bilmek iki hatayı önler:

  • Bir ajana merge geçidi olarak güvenmek
  • Ajanlar test işinin yarısında çok iyi oldukları hâlde onları tamamen işe yaramaz saymak

Bu yazı nasıl yapılır kılavuzundan nasıl ayrılıyor?

Uygulama adımlarını arıyorsanız, API testinde yapay zeka ajanlarını kullanma kılavuzu bir ajanı uç noktalarınıza nasıl yönlendireceğinizi ve ondan nasıl test alacağınızı anlatır.

Bu yazının sorusu farklıdır:

Yapay zeka ile test akışını ne kadar ileri taşımalısınız ve nerede durmalısınız?

Buradaki odak, hangi test işlerinin ajana verilebileceği ve model ne kadar iyi olursa olsun hangi işlerin deterministik bir araca ait olduğudur. Ajan destekli bir test akışı kuruyorsanız, iki yaklaşımı birlikte kullanın.

Yapay zekanın API testinde iyi yaptığı işler

Ajanlar test artefaktları üretme konusunda güçlüdür. Özellikle aşağıdaki yazım işlerinde zaman kazandırırlar.

1. Spesifikasyondan ilk test paketini oluşturma

Bir uç nokta ve örnek yanıt verdiğinizde ajan kısa sürede başlangıç paketi hazırlayabilir:

  • Durum kodu kontrolleri
  • Temel alan doğrulamaları
  • Başarılı istek gövdesi
  • Örnek hata durumları

Örneğin, bir POST /users uç noktası için ajan şu tarz bir başlangıç senaryosu hazırlayabilir:

pm.test("201 döndürmeli", () => {
  pm.response.to.have.status(201);
});

pm.test("Yanıt kullanıcı kimliği içermeli", () => {
  const body = pm.response.json();
  pm.expect(body.id).to.exist;
});
Enter fullscreen mode Exit fullscreen mode

Bu testlerin son hâlini yine sizin incelemeniz gerekir. Ancak boş bir editörden başlamak yerine düzenlenebilir bir taslakla başlarsınız.

2. Uç durumları önerme

Ajanlara şu tür bir soru sorun:

Bu uç noktayı hangi girdiler bozabilir?

İyi bir model genellikle şunları önerir:

  • Boş dizi
  • Zorunlu alanda null
  • Eksik alanlar
  • Süresi dolmuş token
  • Geçersiz yetkilendirme başlığı
  • Tarih sınırlarında saat dilimi sorunları
  • Çok büyük istek gövdeleri
  • Tekrarlanan veya idempotent olmayan istekler

Her olasılığı yakalamaz. Ancak test kapsamını, manuel olarak yazacağınız birkaç mutlu yol senaryosunun ötesine taşır.

3. İstek gövdeleri ve test verileri üretme

Yirmi alanlı geçerli bir payload ya da çok satırlı test verisi gerekiyorsa, ajan bunları hızlı şekilde oluşturabilir.

Asıl önemli nokta, ajanın gerçek şemanızı kullanmasıdır. Spesifikasyonunuzu Model Bağlam Protokolü (MCP) üzerinden bağladığınızda, üretilen gövdeler tahmine değil gerçek alanlarınıza dayanır.

Örnek istek:

{
  "name": "Ayşe Yılmaz",
  "email": "ayse@example.com",
  "role": "admin",
  "preferences": {
    "language": "tr",
    "notifications": true
  }
}
Enter fullscreen mode Exit fullscreen mode

4. İlk taslak assertion'ları yazma

Ajan, “yanıtın geçerli bir kullanıcı döndürdüğünü kontrol et” gibi genel bir ifadeyi alan bazlı assertion'lara dönüştürebilir:

pm.test("Kullanıcı yanıtı geçerli olmalı", () => {
  const body = pm.response.json();

  pm.expect(body).to.have.property("id");
  pm.expect(body).to.have.property("email");
  pm.expect(body.email).to.include("@");
});
Enter fullscreen mode Exit fullscreen mode

Bu assertion'lar son karar değildir. Ancak yazma işini azaltır ve sizin inceleme/düzeltme aşamasına geçmenizi sağlar.

Bu dört başlığın ortak noktası şudur: Hepsi yazım görevidir. Ajanlar bu kısımda faydalıdır.

Hâlâ deterministik bir araca ihtiyaç duyan işler

Aşağıdaki işler aynı özelliği gerektirir: Aynı girdi, her çalıştırmada aynı sonucu üretmelidir.

Paketi her commit'te aynı şekilde çalıştırma

Bir merge geçidinin temel şartı tekrarlanabilirliktir.

Ajan testlerinizi çalıştırabilir; ancak aynı isteği iki kez verdiğinizde farklı özet, farklı yorum veya farklı karar üretebilir. Bu değişkenlik keşif ve taslak oluşturma için yararlıdır. CI geçidi için uygun değildir.

CI'ı gerçek başarılı/başarısız sonucuna göre kilitleme

Kötü bir merge işlemini engellemek için gerçek bir çıkış koduna ihtiyacınız vardır.

Bir sohbet penceresindeki “iyi görünüyor” yanıtı CI'ın işleyebileceği bir sinyal değildir. CI sistemi aşağıdakine benzer bir sonuca ihtiyaç duyar:

exit 0  # Testler başarılı
exit 1  # Testler başarısız
Enter fullscreen mode Exit fullscreen mode

Bu nedenle testleri başsız çalıştıran deterministik bir runner gerekir.

Sözleşme ve şema doğrulama

Şu sorunun cevabı sabit olmalıdır:

Bu yanıt, tüketicilerin kullandığı OpenAPI sözleşmesiyle hâlâ eşleşiyor mu?

Bu bir yorum veya model yargısı değil, sabit tanıma karşı yapılan kontroldür. Bir alan eksikse, testin her seferinde aynı şekilde başarısız olmasını istersiniz. Böylece alt ekipler sorunu üretimde değil, pipeline içinde görür.

Sözleşmenin temelini OpenAPI Spesifikasyonu oluşturur.

Başarısız çağrıyı insan için yeniden üretme

Bir çağrı bozulduğunda ajanın özeti yeterli değildir. Gerçek istek ve yanıt verisine ihtiyacınız vardır:

  • URL ve HTTP metodu
  • Başlıklar
  • İstek gövdesi
  • Durum kodu
  • Yanıt gövdesi
  • Çağrı sırası

Ajan geçerli token gönderdiğini düşünebilir. Gerçekte istemci süresi dolmuş token göndermiş olabilir. Bu farkı ancak ham veriyi inceleyerek görebilirsiniz.

2026 ayrımı: Ajanın işi, runner'ın işi, insanın işi

Test görevi Günümüzdeki yapay zeka ajanı Neden
İlk test paketini taslak olarak hazırla İyi yapar Spesifikasyondan test yazmak kalıp tanıma işidir
Uç durumlar öner İyi yapar Geniş eğitim verisi, gözden kaçan senaryoları öne çıkarabilir
İstek gövdeleri ve test verileri oluştur İyi yapar Hızlıdır; spesifikasyon bağlandığında gerçek alanlara uyabilir
İlk taslak assertion'ları yaz Yapar, inceleme gerekir İyi bir başlangıç noktasıdır, son karar değildir
Paketi her commit'te aynı şekilde çalıştır Deterministik runner gerekir Model çıktısı çalıştırmadan çalıştırmaya değişebilir
CI'ı başarılı/başarısız sonucuna göre engelle Deterministik runner gerekir Merge kuralı gerçek çıkış kodu ister
Sözleşme ve şema doğrula Deterministik araç gerekir Sabit spesifikasyona karşı sabit kontrol yapılır
Başarısız çağrıyı tam olarak yeniden üret İncelenebilir istemci gerekir Özet, gerçek zamanlı ham verinin yerine geçmez
Sözleşmenin doğru olduğuna karar ver İnsan gerekir Bu bir ürün kararıdır, test sonucu değildir

İlk dört satır ajanın güçlü olduğu alandır. Alt taraftaki işler ise “yapay zeka API testini ikame eder” iddiasının neden tek başına bir plan olmadığını gösterir.

Model neden CI geçidi olamaz?

Sorun modellerin kötü olması değildir; çalışma biçimleri farklıdır.

Bir LLM çıktı örnekler. Sıcaklık, örnekleme ve modelin deterministik olmayan yürütme yolları aynı istemin farklı çalıştırmalarda farklı metinler üretmesine neden olabilir. Bu özellik içerik üretimi için faydalıdır. Ancak merge geçidi için risklidir.

Bir CI geçidi sıkıcı ve tekrarlanabilir olmalıdır:

  • Yeşil sonuç her seferinde aynı nedenle yeşil olmalı
  • Kırmızı sonuç aynı bozuk sözleşmeyi işaret etmeli
  • Başarısızlık çıkış koduyla raporlanmalı
  • Test sonuçları tekrar üretilebilmeli

Bu yüzden doğru iş bölümü şöyledir:

  1. Model testleri taslak olarak hazırlar.
  2. İnsan test niyetini ve ürün kararlarını inceler.
  3. Deterministik runner testleri uygular.
  4. CI exit code üzerinden merge kararını verir.

Bu ayrım göz ardı edildiğinde ortaya çıkan sorunlar için yapay zeka ajanlarının üretimde neden bozulduğunu inceleyin.

Apidog nerede yer alır: İncele, sonra doğrula

Apidog, bu akışın deterministik tarafında konumlanır.

Apidog bir ajan çatısı değildir:

  • Ajanınızı yazmaz
  • Ajanınızı çalıştırmaz
  • Ajan adına ürün kararı vermez
  • Açık kaynak değildir

Bunun yerine modelin tek başına güvenilir biçimde yapamadığı iki alanı hedefler: inceleme ve deterministik doğrulama.

Ajan yürütmesini inceleme

Mayıs 2026'da yayınlanan Apidog Yapay Zeka Ajan Hata Ayıklayıcı, ajanın yürütmesini görselleştirmenizi sağlar:

  • LLM çağrıları
  • MCP araç çağrıları
  • Çok turlu etkileşimler
  • API katmanındaki gerçek istek ve yanıtlar

Bir çağrı başarısız olduğunda ajanın API katmanına ne gönderdiğini inceleyebilirsiniz. Bu bir runner değil, hata ayıklama yüzeyidir.

Testleri CI'da deterministik çalıştırma

Apidog CLI, kaydedilmiş test senaryolarını başsız biçimde çalıştırır ve gerçek çıkış kodu döndürür.

Temel kullanım şu şekildedir:

apidog run --project-id <PROJECT_ID>
Enter fullscreen mode Exit fullscreen mode

Bu yaklaşım sayesinde:

  • Testler pipeline içinde çalışır
  • Bozuk sözleşme derlemeyi başarısız kılar
  • CI sonucu exit code üzerinden okunur
  • Çalıştırma her seferinde aynı kuralları uygular

CLI giriş yapmadan çalışır. Bu nedenle pipeline'a, kullanıcı oturumu gerektirmeden bağlanabilir.

Ajanı gerçek spesifikasyonla bağlama

Bağlantı noktası spesifikasyonunuzdur. Aşağıdaki komutla OpenAPI tanımınızı Cursor, Copilot veya Claude Code için kullanılabilir hâle getirebilirsiniz:

npx apidog-mcp-server
Enter fullscreen mode Exit fullscreen mode

Böylece ajan gerçek uç noktalarınıza göre test taslağı oluşturur; alanları veya endpoint'leri uydurmak zorunda kalmaz.

Apidog MCP Sunucusu için hesap gerekmez.

Ayrıca Apidog'un akıllı mock özelliği talep üzerine şu hata durumlarını döndürebilir:

  • 429 Too Many Requests
  • 500 Internal Server Error
  • Zaman aşımı

Bu sayede ajanın veya istemcinin hata kurtarma yollarını test edebilirsiniz. Başlamak için Apidog'u indirin; ücretsiz katman bu iş akışlarını kapsar.

Özetle:

Ajan taslak oluşturur, Apidog doğrular.

Hata Ayıklayıcı ajanın ne yaptığını gösterir; CLI sonucun geçerli olduğunu kanıtlar.

Yapay zeka ve bir betiğin yeterli olduğu durumlar

Her senaryoda tam bir test paketi gerekmez. Aşağıdaki durumlarda bir ajan ve curl çağrısı yeterli olabilir:

  • Tek kullanımlık bir script test ediyorsanız
  • Tek bir istek ihtiyacınız olan sonucu veriyorsa
  • Tek başınıza prototip geliştiriyorsanız
  • API yüzeyi iki veya üç endpoint'ten oluşuyorsa
  • Başka ekipler sözleşmenize bağlı değilse
  • Gönderdiğiniz kod üretim yoluna girmiyorsa

Örneğin hızlı bir manuel kontrol için:

curl -i \
  -H "Authorization: Bearer $TOKEN" \
  https://api.example.com/users/123
Enter fullscreen mode Exit fullscreen mode

Bu tür durumlarda ajanın oluşturduğu kontrol listesi ve manuel inceleme yeterli olabilir.

Ancak aşağıdaki risklerden biri ortaya çıktığında deterministik katmanı ekleyin:

  • Başka geliştiricilere veya ekiplere teslim yapıyorsanız
  • CI çalıştırıyorsanız
  • Diğer ekipler API sözleşmenize göre geliştirme yapıyorsa
  • Hatalı bir yanıt maliyet, veri kaybı veya kesinti yaratabiliyorsa

Bu, üretim işlerinin çoğunda geçerlidir.

Sıkça sorulan sorular

Yapay zeka API testini tamamen ikame edebilir mi?

Hayır. Ajanlar test taslakları oluşturur, uç durumlar önerir ve istek gövdeleri üretir. Ancak testleri her commit'te aynı biçimde çalıştırmak, merge işlemini engellemek ve sözleşmenin doğru olduğuna karar vermek için deterministik bir araç ve insan gerekir.

Yapay zeka ajanları API testinde bugün neleri iyi yapabilir?

Dört temel işi iyi yapabilir:

  1. Spesifikasyondan ilk test paketini taslak olarak hazırlamak
  2. Gözden kaçabilecek uç durumları önermek
  3. Geçerli istek gövdeleri ve test verileri üretmek
  4. İncelenmek üzere ilk assertion taslaklarını yazmak

Bunların tamamı yazım görevleridir.

Bir ajan neden CI geçidi olamaz?

Çünkü CI geçidi aynı girdide aynı sonucu üretmelidir. LLM çıktıları ise örnekleme nedeniyle çalıştırmadan çalıştırmaya değişebilir. Merge kuralı sohbet özeti değil, deterministik bir runner'ın ürettiği exit code okumalıdır.

Bu, API testlerinde yapay zeka ajanlarını kullanma kılavuzuyla aynı şey mi?

Hayır. Nasıl yapılır kılavuzu, ajandan nasıl test alacağınızı gösterir. Bu yazı ise yapay zekanın testi ne ölçüde ikame edebileceğini ve sınırın nerede olduğunu açıklar.

Apidog Yapay Zeka Ajan Hata Ayıklayıcı ajanımı çalıştırır mı?

Hayır. Ajanın yürütmesini inceler: LLM çağrılarını, MCP araç çağrılarını ve çok turlu etkileşimleri gösterir. API katmanında ne olduğunu ayıklamanıza yardımcı olur; ajanı oluşturmaz veya çalıştırmaz.

CI'da test çalıştırmak için oturum açmam gerekir mi?

Hayır. Apidog CLI, kaydedilmiş testleri başsız ve hesap gerektirmeden çalıştırabilir. Gerçek çıkış kodu döndürerek bozuk sözleşmelerde derlemeyi başarısız kılar.

Gerçek sınır

“Yapay zeka API testini ikame edebilir mi?” sorusu aslında iki farklı sorudur:

  1. Yapay zeka test yazabilir mi?

    Giderek daha iyi biçimde evet.

  2. Yapay zeka testleri her seferinde aynı biçimde çalıştıran, merge işlemini engelleyen ve sözleşmeyi sürdüren sistem olabilir mi?

    Hayır. Çünkü test taslağı hazırlamada faydalı olan model, CI geçidinin gerektirdiği anlamda deterministik değildir.

Doğru yaklaşım ikisini birlikte kullanmaktır:

  • Ajana test paketi taslağı hazırlatın.
  • Ajandan uç durumlar ve veri örnekleri isteyin.
  • Assertion'ları insan incelemesinden geçirin.
  • Deterministik bir araçla testleri çalıştırın.
  • Sözleşmeyi doğrulayın.
  • CI'da gerçek exit code ile merge kararını verin.
  • Başarısızlıkta ham istek/yanıt verisini inceleyin.

Başlamak için npx apidog-mcp-server komutunu çalıştırın, ardından Apidog CLI ile testleri CI'a bağlayın veya Apidog'u ücretsiz deneyin.

Top comments (0)