Mehmet

WFN Üye
Konular
1,851
Mesajlar
1,852
Çözüm
0
Ticaret Puanı
0
Üyelik
1 Ay 6 Gün
Konum
YurtDışı
Web Sitesi
Var
Alanı
Google Adsense
1/1
Konu sahibi
API testi, bir uygulamanın başka yazılımlarla haberleşmesini sağlayan API uç noktalarının doğru, güvenli, dayanıklı ve beklenen performansta çalışıp çalışmadığını kontrol etme işlemidir. Test sırasında yalnızca ekrandaki sonucu değil; gönderilen istekleri, HTTP durum kodunu, yanıt gövdesini, doğrulama kurallarını, yetki sınırlarını ve hatalı girdilere verilen tepkileri de incelersiniz.

Buradaki örnekler HTTP tabanlı web API’lerini ele alır; API kavramı yalnız HTTP ile sınırlı değildir.

Örneğin bir e-ticaret uygulamasındaki GET /products/42 isteği ürün bilgisi döndürmelidir. Ürün yoksa uygun bir istemci hatası, kimlik doğrulama gerekiyorsa yetkisiz erişim yanıtı, sunucuda beklenmeyen bir sorun varsa sunucu hatası dönmelidir. Yanıtın içinde gereksiz müşteri bilgileri bulunmamalı ve aynı istek, sözleşmede belirtilen veri biçimini korumalıdır.

API testinde ne kontrol edilir?​


API testi tek bir test türü değildir. Hangi kontrolün yapılacağı, API’nin kullanım amacına ve riskine göre belirlenir.
Bu türleri karıştırmamak önemlidir. Başarılı bir 200 OK yanıtı, işlemin güvenli olduğu anlamına gelmez. API beklenen veriyi döndürürken yetki kontrolünü atlıyor veya gereğinden fazla alan gönderiyor olabilir.

En küçük uygulanabilir API testi​


Bir sağlık kontrolü uç noktanız olduğunu ve bunun başarılı durumda 200 durum kodu ile status: ok alanını döndürdüğünü varsayalım. İlk kontrolü komut satırından yapabilirsiniz:
  1. Test ortamındaki API adresini ve kontrol edilecek uç noktayı belirleyin. Üretim ortamında deneme yapmadan önce kullanılacak hesap, veri ve istek sınırlarını netleştirin.
  2. Aşağıdaki isteği çalıştırın:
Kod:
curl -i "http://localhost:3000/health" \
  -H "Accept: application/json"

Bu komut servisi veya /health uç noktasını oluşturmaz; örnekteki uygulamanın önceden çalışıyor olması gerekir. Bu yalnız bir manuel gözlemdir, yanıtı otomatik doğrulayan test değildir.

Beklenen başarılı sonuç, HTTP başlıklarında 200 durum kodu ve yanıt gövdesinde benzer bir JSON bulunmasıdır:

Kod:
{"status":"ok"}

404 alırsanız uç nokta yolunu, uygulamanın çalıştığı portu ve sürüm ön ekini kontrol edin; yanıt, bulunmayan kaynak veya erişimi gizleme politikası nedeniyle de verilebilir. 401 ya da 403 alırsanız kimlik doğrulama veya yetki gereksinimini kontrol edin. 5xx yanıtı alırsanız sorun genellikle sunucu, bağımlı servis veya uygulama hatasıdır.
Sağlık kontrolünden sonra gerçek iş akışlarını test edin: geçerli veri, eksik zorunlu alan, hatalı veri tipi, bulunmayan kaynak ve yetkisiz kullanıcı senaryolarını ayrı ayrı çalıştırın.


Test türüKontrol edilen konuÖrnek
Fonksiyonelİstek ve yanıtın beklenen davranışıGeçerli ürün kimliği doğru ürünü döndürüyor mu?
SözleşmeAlan adları, veri tipleri ve durum kodlarıYanıt içindeki price alanı sayı olarak mı geliyor?
YetkilendirmeKullanıcının yalnızca izin verilen kaynağa erişmesiBir kullanıcı başka kullanıcının siparişini görebiliyor mu?
PerformansYük ve yoğunluk altındaki davranışEş zamanlı isteklerde hata oranı kabul edilebilir mi?

Sonuçlar nasıl yorumlanır?​


Bir testin başarılı sayılması yalnızca beklenen durum kodunun alınmasına bağlı değildir. Yanıt gövdesinin şemaya uygunluğu, hata mesajının istemci tarafından işlenebilir olması, hassas bilgilerin sızmaması ve aynı isteğin tekrarında tutarlı davranış görülmesi de değerlendirilmelidir.

Test sonuçlarını uç nokta, kullanılan yöntem, istek verisi, beklenen sonuç, gerçekleşen sonuç ve hata ayrıntısıyla kaydedin. Böylece geliştirici, sorunu yeniden üretebilir ve düzeltme sonrasında aynı testi tekrar çalıştırabilir. OpenAPI tanımı varsa test senaryolarını bu sözleşmedeki yollar, parametreler ve güvenlik gereksinimleriyle karşılaştırın.

Sık yapılan hatalar​


Yalnızca başarılı istekleri denemek: Eksik alan, geçersiz kimlik, bozuk JSON ve bulunamayan kaynak senaryoları test edilmezse API’nin hata davranışı bilinemez.

Durum kodunu yeterli görmek: 200 dönen bir yanıt yanlış veri veya fazla alan içerebilir. Gövde ve başlıklar da doğrulanmalıdır.

Yetki testini atlamak: Geçerli bir kullanıcıyla işlem yapılabilmesi, o kullanıcının her kaynağa erişebileceği anlamına gelmez. Farklı roller ve farklı kaynak sahipleriyle karşılaştırmalı test yapılmalıdır.

Sadece kullanıcı arayüzünü test etmek: Arayüz bazı hataları gizleyebilir. API isteklerini doğrudan incelemek, istemci ile sunucu arasındaki gerçek sözleşmeyi görmenizi sağlar.

Sık sorulan sorular​


API testi ile birim testi aynı şey midir?​


Hayır. Birim testi tek bir fonksiyon veya modülü izole biçimde inceler. API testi ise genellikle HTTP katmanını, yönlendirmeyi, doğrulamayı, yetkilendirmeyi ve yanıt biçimini birlikte değerlendirir.

API testi ne zaman yapılmalıdır?​


Yeni bir uç nokta geliştirildiğinde, sözleşme değiştiğinde, kimlik veya yetki sistemi güncellendiğinde ve yayın öncesinde yapılmalıdır. Tek seferlik kontrol yerine otomatik tekrar çalıştırılabilen testler tercih edilir.

curl komutunun başarıyla bitmesi API testinin geçtiğini gösterir mi?​

Göstermez. curl varsayılan olarak bir HTTP 404 veya 500 yanıtını da başarılı veri aktarımı sayabilir. Beklenen HTTP durumunu, yanıt başlıklarını ve gövdeyi ayrıca doğrulayın. Otomatik testte yalnız komutun çıkış koduna güvenmek, API’nin hata yanıtını gözden kaçırabilir.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Konuyu görüntüleyenler

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic