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?
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;
});
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
}
}
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("@");
});
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
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:
- Model testleri taslak olarak hazırlar.
- İnsan test niyetini ve ürün kararlarını inceler.
- Deterministik runner testleri uygular.
- 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>
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
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 Requests500 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
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:
- Spesifikasyondan ilk test paketini taslak olarak hazırlamak
- Gözden kaçabilecek uç durumları önermek
- Geçerli istek gövdeleri ve test verileri üretmek
- İ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:
Yapay zeka test yazabilir mi?
Giderek daha iyi biçimde evet.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)