- Konu sahibi
- #1
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
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
Bir sağlık kontrolü uç noktanız olduğunu ve bunun başarılı durumda
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
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.
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.
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:
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.
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.
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.
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:- 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.
- 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şme | Alan adları, veri tipleri ve durum kodları | Yanıt içindeki price alanı sayı olarak mı geliyor? |
| Yetkilendirme | Kullanıcının yalnızca izin verilen kaynağa erişmesi | Bir kullanıcı başka kullanıcının siparişini görebiliyor mu? |
| Performans | Yü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.