DEV Community

Cover image for API Test Senaryoları Nasıl Yazılır: Şablon ve Örnek
Tobias Hoffmann
Tobias Hoffmann

Posted on • Originally published at apidog.com

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

Hatalı bir API genellikle “hiç test edilmediği” için değil, yanlış şeyi test ettiği için üretimde kırılır. Sadece 200 OK kontrol eden bir test, bozuk sözleşmeyi, eksik alanları, yanlış hata gövdesini veya performans regresyonunu kaçırabilir. İyi yazılmış bir API test durumu, bu hataları yayın öncesinde yakalamanızı sağlar.

Apidog'u bugün deneyin

Bu rehberde API test durumunun ne olduğunu, güçlü bir test durumunda hangi alanların bulunması gerektiğini ve sıfırdan nasıl yazılacağını uygulamalı olarak göreceksiniz. Örnek olarak bir giriş uç noktasını test edeceğiz, ardından aynı testleri Apidog üzerinde kod yazmadan oluşturacağız.

API test durumu nedir?

API test durumu, bir uç noktanın belirli bir koşul altında beklenen şekilde davrandığını doğrulayan net bir girdi, işlem ve beklenen sonuç kümesidir.

Bir test senaryosu daha geneldir:

Kullanıcı girişini doğrula.

Bir test durumu ise çalıştırılabilir kadar nettir:

POST /auth/login isteğine geçerli kimlik bilgileri gönderildiğinde, gövdede JWT içeren 200 yanıtı 800 ms içinde dönmelidir.

İyi bir test durumu tek bir davranışı hedefler. Böylece test başarısız olduğunda neyin bozulduğunu doğrudan anlarsınız. Geniş ve çok amaçlı testler ise hata ayıklamayı zorlaştırır.

Test senaryosu, test durumu ve test scripti arasındaki farkları netleştirmek için şu kaynaklara bakabilirsiniz:

API testleri genellikle şu alanları kapsamalıdır:

  • Fonksiyonel: Geçerli giriş için doğru veri dönüyor mu?
  • Negatif: Hatalı giriş doğru durum kodu ve hata gövdesiyle reddediliyor mu?
  • Performans: Yanıt kabul edilebilir süre içinde geliyor mu?
  • Güvenlik: Kimlik doğrulama, yetkilendirme ve giriş sınırları uygulanıyor mu?
  • Sözleşme: Yanıt belgelenmiş şemaya uyuyor mu?

Sadece mutlu yolu test eden bir paket, ilk boş parola alanında başarısız olabilir.

Neden test durumu şablonu kullanmalısınız?

Her test durumunu sıfırdan yazmak tutarsız kapsam üretir. Bir mühendis sadece durum kodunu yazar, diğeri gövde alanlarını ekler, bir başkası da “çalışmalı” gibi belirsiz bir beklenti bırakır.

Bir şablon bu problemi çözer. Her test durumu aynı yapıyı izler ve eksik alanlar görünür hale gelir.

Pratikte şablon size şunları sağlar:

  • Denetlenebilir kapsam: Her durumda aynı alanlar olduğu için boşlukları kolayca görürsünüz.
  • Hızlı onboarding: Yeni ekip üyeleri tek bir formatı öğrenir.
  • Yeniden kullanım: Yapılandırılmış durumları kopyalayıp küçük değişikliklerle yeni sürümlere uyarlayabilirsiniz.
  • İzlenebilirlik: Her test durumu bir gereksinime, uç noktaya veya davranışa bağlanabilir.
  • Otomasyon kolaylığı: Net tanımlanmış durumlar otomatik test adımlarına daha kolay çevrilir.

Belirsiz bir test durumu, otomasyona alınmadan önce yeniden yazılmak zorundadır.

Güçlü bir API test durumunun anatomisi

Eksiksiz bir API test durumu şablonu şu alanları içermelidir:

Alan Amaç
Test durumu ID'si Benzersiz referans, örn. AUTH-LOGIN-001
Başlık Test edilen davranışı açıklayan kısa ad
Uç nokta Metot ve yol, örn. POST /auth/login
Ön koşullar Çalıştırmadan önce gereken durum, örn. kullanıcı mevcut
Başlıklar Gerekli istek başlıkları
İstek gövdesi / parametreleri Gönderilecek tam giriş yükü
Beklenen durum Beklenen HTTP durum kodu
Beklenen yanıt Doğrulanacak gövde alanları, şema veya değerler
Beklenen yanıt süresi Gecikme bütçesi
Öncelik Kritik, yüksek, orta, düşük
Test türü Fonksiyonel, negatif, güvenlik, performans

En sık atlanan iki alan şunlardır:

  1. Beklenen yanıt gövdesi
  2. Beklenen yanıt süresi

Bunları atladığınızda, API boş veya yanlış gövdeyle 200 döndürse bile test geçebilir. Aynı şekilde doğru yanıtı üç saniyede döndüren bir uç nokta da fark edilmeden üretime çıkabilir.

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

1. API dokümantasyonunu okuyun

Önce uç noktanın sözleşmesini netleştirin:

  • Gerekli parametreler
  • Kimlik doğrulama yöntemi
  • Belgelenmiş durum kodları
  • Yanıt şeması
  • Hata formatı
  • Limitler ve doğrulama kuralları

Her test durumu, belgelenmiş bir davranış hakkında iddiadır. Bu yüzden doğru kaynak API dokümantasyonudur.

OpenAPI kullanıyorsanız, OpenAPI belirtiminden test koleksiyonları oluşturan araçlar başlangıç iskeletini hızlıca oluşturabilir.

2. Test edilecek koşulları listeleyin

Tek bir uç nokta için genellikle şu koşullar test edilir:

  • Geçerli giriş
  • Her gerekli alanın eksik olduğu durum
  • Hatalı biçimlendirilmiş alanlar
  • Yetkisiz istek
  • Süresi dolmuş token
  • Aşırı büyük yük
  • Sınır değerler
  • Güvenlik girdileri

Her koşulu ayrı bir test durumu yapın.

Örneğin:

AUTH-LOGIN-001 - Geçerli kimlik bilgileri
AUTH-LOGIN-002 - Yanlış parola
AUTH-LOGIN-003 - Eksik parola
AUTH-LOGIN-004 - Hatalı e-posta formatı
Enter fullscreen mode Exit fullscreen mode

3. Ayrı test verileri hazırlayın

Negatif testlerde veri tek bir nedenle hatalı olmalıdır.

Kötü örnek:

{
  "email": "not-an-email",
  "password": ""
}
Enter fullscreen mode Exit fullscreen mode

Bu yük hem e-posta hem parola açısından hatalıdır. Test başarısız olduğunda hangi doğrulamanın çalıştığını net anlayamazsınız.

Daha iyi örnek:

{
  "email": "not-an-email",
  "password": "Correct-Horse-9"
}
Enter fullscreen mode Exit fullscreen mode

Bu durumda yalnızca e-posta formatı test edilir.

4. Beklenen sonucu kesin yazın

Belirsiz beklentiler test değeri üretmez.

Kötü beklenti:

Başarı döndürür.
Enter fullscreen mode Exit fullscreen mode

İyi beklenti:

HTTP 200 döner.
Yanıt gövdesinde boş olmayan string tipinde token bulunur.
token_type değeri Bearer olur.
expires_in değeri 3600 olur.
Yanıt süresi 800 ms altında kalır.
Enter fullscreen mode Exit fullscreen mode

Bir test durumunun çalıştırılabilir olması için beklentinin ölçülebilir olması gerekir.

5. Durumu çalıştırılabilir bir pakete ekleyin

E-tablodaki test durumu niyeti belgeler. Ancak test aracı içindeki durum gerçek sonuç üretir: geçti veya kaldı.

İlgili durumları bir pakette gruplayın. Böylece bir uç nokta veya özellik tek tıklamayla test edilebilir.

Bu yaklaşım için API test paketleri kullanılabilir.

6. Test durumlarını güncel tutun

API değiştiğinde testler de değişmelidir. Eski şemayı doğrulayan bir test, hiç test olmamasından daha zararlı olabilir. Çünkü yanlış nedenle başarısız olur ve ekibi kırmızı testleri görmezden gelmeye alıştırır.

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

Standart bir kimlik doğrulama uç noktası düşünelim:

POST /auth/login
Enter fullscreen mode Exit fullscreen mode

Bu uç nokta e-posta ve parola alıyor, başarılı olduğunda JWT döndürüyor.

AUTH-LOGIN-001: geçerli kimlik bilgileri

Tür: Fonksiyonel

Öncelik: Kritik

  • Uç nokta: POST /auth/login
  • Ön koşul: dana@example.com e-postalı kullanıcı mevcut
  • İstek gövdesi: 
{
  "email": "dana@example.com",
  "password": "Correct-Horse-9"
}
Enter fullscreen mode Exit fullscreen mode
  • Beklenen durum: 200
  • Beklenen yanıt: 
{
  "token": "<non-empty-string>",
  "token_type": "Bearer",
  "expires_in": 3600
}
Enter fullscreen mode Exit fullscreen mode
  • Ek doğrulamalar:
    • token boş olmayan string olmalı
    • token_type değeri Bearer olmalı
    • expires_in değeri 3600 olmalı
    • Yanıt süresi 800 ms altında kalmalı

AUTH-LOGIN-002: yanlış parola

Tür: Negatif

Öncelik: Kritik

  • İstek gövdesi: 
{
  "email": "dana@example.com",
  "password": "wrong"
}
Enter fullscreen mode Exit fullscreen mode
  • Beklenen durum: 401
  • Beklenen yanıt: 
{
  "error": "invalid_credentials"
}
Enter fullscreen mode Exit fullscreen mode
  • Ek doğrulamalar:
    • token alanı bulunmamalı
    • Hata mesajı e-postanın var olup olmadığını açıklamamalı

AUTH-LOGIN-003: eksik parola alanı

Tür: Negatif

Öncelik: Yüksek

  • İstek gövdesi: 
{
  "email": "dana@example.com"
}
Enter fullscreen mode Exit fullscreen mode
  • Beklenen durum: 400
  • Beklenen yanıt: 
{
  "error": "validation_error",
  "details": [
    {
      "field": "password"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode
  • Ek doğrulamalar:
    • details içinde password alanına referans olmalı

AUTH-LOGIN-004: hatalı biçimli e-posta

Tür: Negatif

Öncelik: Orta

  • İstek gövdesi: 
{
  "email": "not-an-email",
  "password": "Correct-Horse-9"
}
Enter fullscreen mode Exit fullscreen mode
  • Beklenen durum: 400
  • Beklenen yanıt: 
{
  "error": "validation_error"
}
Enter fullscreen mode Exit fullscreen mode

Bu dört test durumu ile tek bir uç nokta için şunları doğrulamış olursunuz:

  • Başarılı giriş sözleşmesi
  • Hata durum kodları
  • Hata gövdesi formatı
  • Zorunlu alan doğrulaması
  • Yanıt süresi beklentisi

Ek olarak e-posta alanına SQL enjeksiyon dizesi gönderilen bir güvenlik durumu ekleyerek paketi güçlendirebilirsiniz.

Aynı test durumunu Apidog'da oluşturma

Yukarıdaki testleri kod yazmadan Apidog üzerinde oluşturabilirsiniz.

1. Uç noktayı içe aktarın veya tanımlayın

POST /auth/login uç noktasını şu yöntemlerden biriyle ekleyin:

  • OpenAPI dosyasından içe aktarın
  • Postman koleksiyonundan içe aktarın
  • Apidog içinde manuel tanımlayın

İstek ve yanıt şeması, sonraki doğrulamaların temelini oluşturur.

2. İstek verilerini ekleyin

AUTH-LOGIN-001 için gövdeyi girin:

{
  "email": "dana@example.com",
  "password": "Correct-Horse-9"
}
Enter fullscreen mode Exit fullscreen mode

Aynı uç noktayı farklı veri kombinasyonlarıyla test etmek istiyorsanız CSV veya JSON dosyası bağlayabilirsiniz. Bu yaklaşım için veri odaklı API testi kullanılır.

Örneğin tek bir test durumunu şu veri setiyle çalıştırabilirsiniz:

email,password,expected_status
dana@example.com,Correct-Horse-9,200
dana@example.com,wrong,401
not-an-email,Correct-Horse-9,400
Enter fullscreen mode Exit fullscreen mode

3. Doğrulamaları görsel olarak ayarlayın

Apidog içinde aşağıdaki doğrulamaları ekleyin:

  • Durum kodu 200 olmalı
  • token alanı var olmalı
  • token boş olmayan string olmalı
  • token_type değeri Bearer olmalı
  • expires_in değeri 3600 olmalı
  • Yanıt süresi 800 ms altında olmalı

Bu doğrulamalar için özel script yazmanız gerekmez.

4. Test durumlarını tek senaryoda gruplayın

Dört giriş test durumunu aynı test senaryosuna ekleyin:

Login API Test Scenario
├── AUTH-LOGIN-001 - Geçerli kimlik bilgileri
├── AUTH-LOGIN-002 - Yanlış parola
├── AUTH-LOGIN-003 - Eksik parola
└── AUTH-LOGIN-004 - Hatalı e-posta formatı
Enter fullscreen mode Exit fullscreen mode

Böylece giriş uç noktası tek çalıştırmada kapsamlı şekilde test edilir.

5. Çalıştırın ve raporu inceleyin

Apidog senaryoyu çalıştırır ve her test durumu için geçti/kaldı sonucunu gösterir. Başarısız durumda hangi doğrulamanın bozulduğunu doğrudan görebilirsiniz.

Senaryoyu şu şekillerde çalıştırabilirsiniz:

  • Yerel olarak
  • Belirli programa göre
  • CI sürecinde

Kod yazmak yanlış değildir. Ancak yapılandırılmış görsel test durumları daha hızlı hazırlanır, daha kolay incelenir ve küçük doğrulama hatalarını azaltır. Özel mantık gerektiğinde Apidog içinde script kullanabilirsiniz.

Scriptsiz bir iş akışı için Postman olmadan API testi yaklaşımına da bakabilirsiniz.

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

Sadece durum kodunu doğrulamak

200 OK, yanıtın doğru olduğu anlamına gelmez. Sadece isteğin işlendiğini gösterir.

Her zaman gövde alanlarını da doğrulayın:

status = 200
token exists
token_type = Bearer
expires_in = 3600
Enter fullscreen mode Exit fullscreen mode

Uç nokta başına tek dev test yazmak

Tek bir büyük test başarısız olduğunda hangi koşulun bozulduğunu anlamak zorlaşır.

Bunun yerine koşula göre ayırın:

Geçerli giriş
Yanlış parola
Eksik parola
Hatalı e-posta
Enter fullscreen mode Exit fullscreen mode

Aynı test verisini tekrar tekrar kullanmak

Her negatif test aynı yükü gönderirse yalnızca tek bir hata modunu test edersiniz. Her test durumu, hedeflediği davranışa özel veri kullanmalıdır.

Yanıt süresini doğrulamamak

Performans bütçesi tanımlamazsanız regresyonlar sessizce üretime gider.

Örnek beklenti:

response_time < 800 ms
Enter fullscreen mode Exit fullscreen mode

Hiç otomatikleşmeyen test durumları yazmak

Hiçbir çalıştırıcının yürütmediği test durumu, test değil dokümantasyondur.

Test durumlarını her derlemede çalışan bir pakete taşıyın. Başlangıç için OpenAPI belirtiminden test scriptleri oluşturmak kullanılabilir.

Ö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?

Basit bir uç nokta için genellikle dört ila altı test durumu yeterlidir:

  • Mutlu yol
  • Her gerekli alan için eksik alan testi
  • Kimlik doğrulama hatası
  • En az bir güvenlik veya sınır değer testi

Karmaşık uç noktalarda bu sayı artabilir.

API oluşturulmadan önce test durumları yazılmalı mı?

Evet. Tasarım aşamasında test durumu yazmak sözleşme eksiklerini erken yakalamanızı sağlar.

İlk taslağı hızlandırmak için yapay zeka destekli test durumu oluşturma kullanabilir, ardından sonuçları elle iyileştirebilirsiniz.

Test durumları e-tabloda mı, test aracında mı tutulmalı?

E-tablo niyeti belgeler ancak çalıştıramaz. Test durumlarını yürüten ve sonuçları raporlayan bir araçta tutmak daha pratiktir.

İyi bir test durumu her zaman net bir sonuç üretmelidir:

Passed
Failed
Enter fullscreen mode Exit fullscreen mode

Test durumu ile test senaryosu arasındaki fark nedir?

Test senaryosu üst düzey hedeftir:

Girişi doğrula
Enter fullscreen mode Exit fullscreen mode

Test durumu ise bu hedef içindeki somut kontroldür:

Geçerli kimlik bilgileri gönderildiğinde 200 dönmeli ve token içermeli
Enter fullscreen mode Exit fullscreen mode

Detaylı karşılaştırma için test senaryosu ve test durumu rehberine bakabilirsiniz.

Top comments (0)