API Test Senaryoları Nasıl Yazılır: Şablon ve Örnek

Hatalı bir API nadiren birinin onu test etmeyi unutması yüzünden başarısız olur. Yanlış şeyi kontrol eden veya 200 durum kodu dışında hiçbir şeyi kontrol etmeyen bir test yüzünden başarısız olur. İyi yazılmış bir API test durumu, bozuk bir sözleşmeyi yayınlamadan önce yakalamak ile kesintiyi sonradan açıklamak arasındaki farktır.

Bu kılavuz, bir API test durumunun ne olduğunu, iyi bir tanesinin hangi alanlara ihtiyaç duyduğunu ve sıfırdan nasıl yazılacağını anlatmaktadır. Bir giriş uç noktası için eksiksiz bir örnek görecek, ardından aynı testi Apidog'da herhangi bir kod yazmadan oluşturacaksınız.

API test durumu aslında nedir?

Bir API test durumu, bir uç noktanın belirli bir koşul altında doğru davrandığını doğrulamak için kullanılan tanımlanmış bir girdi, eylem ve beklenen sonuçlar kümesidir. Bir test senaryosundan daha dardır. Bir senaryo "kullanıcı girişini doğrula" der. Bir test durumu ise "/auth/login adresine geçerli kimlik bilgilerini POST et ve gövdede bir JWT ile 200 yanıtının 800 ms içinde döndüğünü onayla" der.

Her durum tek bir davranışı hedefler. Bu odaklanma önemlidir. Geniş, çok amaçlı bir test başarısız olduğunda, hangi kısmın bozulduğunu hala araştırmanız gerekir. Odaklanmış bir durum başarısız olduğunda, hata adı size cevabı söyler. Durumların senaryolar ve scriptlerle nasıl ilişkili olduğunu hala haritalandırıyorsanız, test senaryosu ve test durumu ile test durumu ve test scripti çizgileri net bir şekilde çizer.

API testi genellikle beş açıyı kapsar ve durumlarınızın hepsine yayılması gerekir:

• Fonksiyonel: Uç nokta, geçerli giriş için doğru veriyi döndürüyor mu?
• Negatif: Yanlış girişi doğru hata ve durum koduyla reddediyor mu?
• Performans: Kabul edilebilir bir zaman bütçesi içinde yanıt veriyor mu?
• Güvenlik: Kimlik doğrulama, yetkilendirme ve giriş limitlerini uyguluyor mu?
• Sözleşme: Yanıt, belgelenmiş şemaya uyuyor mu?

Yalnızca "mutlu yolu" kontrol eden bir test paketi, gerçek bir kullanıcı boş bir parola alanı gönderene kadar başarılı olacaktır.

Neden bir test durumu şablonuna ihtiyacınız var?

Her durumu boş bir sayfadan yazmak tutarsız kapsam üretir. Bir mühendis beklenen durum kodlarını kaydeder; diğeri yanıt gövdelerini kaydeder; üçüncüsü ise "çalışmalı" diye yazar. Bir şablon, her seferinde aynı yapıyı zorlayarak bu durumu düzeltir.

Ortak bir şablon size dört somut avantaj sağlar. Kapsam denetlenebilir hale gelir, çünkü her durum aynı alanlara sahiptir ve boşluklar görünür. Yeni bir testçinin beş farklı format yerine tek bir formatı okuması sayesinde işe alıştırma hızlanır. Yapılandırılmış bir durumun klonlanması ve ayarlanması kolay olduğundan, durumlar sürümler arasında yeniden kullanılabilir hale gelir. Ve her durum bir gereksinime veya uç noktaya bağlandığı için izlenebilirlik korunur.

Şablonlar ayrıca otomasyonu gerçekçi kılar. Yapılandırılmış bir durum, otomatik bir test adımına net bir şekilde eşlenir; belirsiz bir durumun ise bir makine tarafından çalıştırılmadan önce yeniden yazılması gerekir.

Güçlü bir API test durumunun anatomisi

Eksiksiz bir API test durumu şablonu bu alanları içerir. Her durum için hepsine ihtiyacınız olmayabilir, ancak temel set tartışılmazdır.

Ekiplerin en sık atladığı alanlar beklenen yanıt süresi ve beklenen yanıt gövdesidir. Bunları atlamak, bir testin boş bir yükle 200 döndürürken veya doğru bir yükü üç saniye gecikmeyle döndürürken nasıl "geçtiğini" gösterir.

API test durumları adım adım nasıl yazılır

Önce API dokümantasyonunu okuyun. Gerekli parametreleri, kimlik doğrulama yöntemini, belgelenmiş durum kodlarını ve yanıt şemasını not alın. Her test durumu, belgelenmiş bir davranış hakkında bir iddiadır, bu nedenle dokümanlar sizin doğru kaynağınızdır. Bir OpenAPI belirtimini okuyarak test koleksiyonları oluşturan araçlar size başlangıç iskeleti sağlayabilir.

Test etmeye değer koşulları listeleyin. Tek bir uç nokta için bu genellikle şunları ifade eder: geçerli giriş, eksik olan her gerekli alan, hatalı biçimlendirilmiş her alan, yetkisiz bir istek, süresi dolmuş bir token ve aşırı boyutlu bir yük. Her koşul bir durum haline gelir.

Ayrı test verileri hazırlayın. Negatif durumlar, tam olarak tek bir şekilde yanlış olan verilere ihtiyaç duyar. Durumlar arasında aynı yükü yeniden kullanmak hataları gizler, çünkü yalnızca tek bir yolu kullanırsınız.

Beklenen sonucu hassas bir şekilde yazın. “Başarı döndürür” bir doğrulama değildir. “200 döndürür, gövde boş olmayan bir token dizesi içerir, expires_in 3600'e eşittir” bir doğrulamadır. Buradaki hassasiyet, durumu çalıştırmaya değer kılandır.

Durumu çalıştırılabilir bir pakete ekleyin. Bir e-tablodaki bir durum niyeti belgeler. Bir test aracındaki bir durum ise başarılı veya başarısız bir sonuç üretir. İlgili durumları gruplandırın, böylece tüm uç nokta tek tıklamayla çalışır; test paketleri tam olarak bunun için vardır.

Durumları güncel tutun. API değiştiğinde, durumlar da onunla birlikte değişir. Eski bir şemayı doğrulayan güncel olmayan bir durum, hiç olmamasından daha kötüdür, çünkü yanlış nedenden dolayı başarısız olur ve ekibi başarısız derlemeleri görmezden gelmeye alıştırır.

Uygulamalı bir örnek: bir giriş uç noktasını test etme

Standart bir kimlik doğrulama uç noktası ele alalım: bir e-posta ve parola kabul eden ve bir JWT döndüren POST /auth/login. İşte bunu doğru şekilde kapsayan dört durum.

AUTH-LOGIN-001: geçerli kimlik bilgileri (fonksiyonel, kritik)

• Uç nokta: POST /auth/login
• Ön koşullar: dana@example.com e-postalı bir kullanıcı mevcut
• Gövde: {"email": "dana@example.com", "password": "Correct-Horse-9"}
• Beklenen durum: 200
• Beklenen yanıt: gövde boş olmayan bir token (dize) içerir, token_type Bearer'a eşittir, expires_in 3600'e eşittir
• Beklenen yanıt süresi: 800 ms altında

AUTH-LOGIN-002: yanlış parola (negatif, kritik)

• Gövde: {"email": "dana@example.com", "password": "wrong"}
• Beklenen durum: 401
• Beklenen yanıt: error invalid_credentials'a eşittir; token alanı mevcut değil
• Not: Mesaj, e-postanın var olup olmadığını açıklamamalıdır

AUTH-LOGIN-003: eksik parola alanı (negatif, yüksek)

• Gövde: {"email": "dana@example.com"}
• Beklenen durum: 400
• Beklenen yanıt: error validation_error'a eşittir; details password alanını belirtir

AUTH-LOGIN-004: hatalı biçimli e-posta (negatif, orta)

• Gövde: {"email": "not-an-email", "password": "Correct-Horse-9"}
• Beklenen durum: 400
• Beklenen yanıt: error validation_error'a eşittir

Dört durum, bir uç nokta ve şimdiden sözleşmeyi, hata şeklini, durum kodlarını ve bir gecikme bütçesini kontrol ediyorsunuz. E-posta alanına bir SQL enjeksiyon dizesi için bir güvenlik durumu ekleyin ve her taahhütte çalıştırmaya değer bir pakete sahip olursunuz.

Aynı test durumunu Apidog'da yazma

Yukarıdaki dört durumu tek bir satır kod yazmadan çalıştırabilirsiniz. Apidog'da, bir API test durumu görsel olarak oluşturulur.

1. Uç noktayı içe aktarın veya tanımlayın. POST /auth/login uç noktasını bir OpenAPI dosyasından, bir Postman koleksiyonundan içeri aktarın veya doğrudan tanımlayın. İstek şeması her doğrulama için temel teşkil eder.
2. İstek verilerini ekleyin. AUTH-LOGIN-001 durumu için gövdeyi girin. Veri odaklı kapsama için, bir CSV veya JSON dosyası ekleyerek bir durumun her kimlik bilgisi satırına karşı çalışmasını sağlayın; veri odaklı API testi dört neredeyse aynı durumu bu şekilde tek bir durumla değiştirir.
3. Doğrulamaları görsel olarak ayarlayın. Durumun 200'e eşit olduğunu, token'ın var olduğunu ve boş olmayan bir dize olduğunu, expires_in'in 3600'e eşit olduğunu ve yanıt süresinin 800 ms altında kaldığını doğrulamak için tıklayın. Kod yazmaya gerek yok.
4. Durumları bir test senaryosunda gruplandırın. Dört giriş durumunun tamamını tek bir senaryoya ekleyin, böylece uç nokta tek bir çalıştırmada tamamen test edilmiş olur.
5. Çalıştırın ve raporu okuyun. Apidog senaryoyu yürütür, her durum için başarılı/başarısız raporu oluşturur ve bozulan tam doğrulamayı ortaya çıkarır. Senaryoyu yerel olarak, belirli bir programa göre veya CI içinde çalıştırabilirsiniz.

Mesele kod yazmanın yanlış olması değil; yapılandırılmış görsel bir durumun daha hızlı yazılması, incelenmesinin daha kolay olması ve ince hatalar yapmanın daha zor olmasıdır. Koda ihtiyacınız olduğunda, Apidog yine de özel scriptlere geçmenize izin verir. Tamamen scriptsiz bir iş akışı için, Postman olmadan API testi daha geniş yaklaşımı kapsar.

Kaçınılması gereken yaygın hatalar

Sadece durum kodunu doğrulamak. 200, isteğin işlendiği anlamına gelir, yanıtın doğru olduğu anlamına gelmez. Her zaman gövde alanlarını doğrulayın.

Uç nokta başına tek bir devasa durum. Başarısız olduğunda hiçbir şey öğrenmezsiniz. Koşula göre ayırın.

Yeniden kullanılan test verileri. Her negatif durum aynı yükü gönderirse, yalnızca tek bir hata modunu test edersiniz.

Gecikme doğrulaması yok. Yanıt süresi ölçülmediğinde performans regresyonları sessizce gözden kaçar.

Asla otomatikleşmeyen durumlar. Hiçbir çalıştırıcının yürütmediği belgelenmiş bir durum, bir test değil, bir yorumdur. Durumları her derlemede çalışan bir pakete taşıyın; bir OpenAPI belirtiminden test scriptleri oluşturmak bu paketi hızlıca başlatmanın bir yoludur.

Örneği takip etmek ve dört giriş durumunu kendiniz oluşturmak istiyorsanız Apidog'u indirin.

Sıkça sorulan sorular

Bir uç noktanın kaç test durumuna ihtiyacı vardır? Mutlu yolu, her gerekli alan hatasını, bir kimlik doğrulama hatasını ve bir güvenlik araştırmasını kapsayacak kadar. Basit bir uç nokta için dört ila altı durum; karmaşık bir uç nokta için ise daha fazla olabilir.

API oluşturulmadan önce durumları yazmalı mıyım? Evet. Tasarıma karşı, önce tasarıma göre durum yazmak, sözleşme eksikliklerini erken yakalar. Bunu yapay zeka destekli test durumu oluşturma ile eşleştirerek hızlıca ilk seti taslak haline getirin, ardından elle iyileştirin.

Durumları depolamak için e-tablo mu test aracı mı? Bir e-tablo niyeti belgeler ancak çalıştıramaz. Durumları yürüten ve sonuçları raporlayan bir araçta tutun, böylece bir durum her zaman yeşil veya kırmızı olur.

Test durumu ile test senaryosu arasındaki fark nedir? Bir senaryo üst düzey hedeftir (“girişi doğrula”); bir durum ise bunun içindeki somut, çalıştırılabilir bir kontroldür. Test senaryosu ve test durumu'na bakın.