01Sorun ve çözüm
API testi hizmetimizde servislerinizi doğrudan uç noktalar üzerinden sınıyoruz: doğru veriyle beklenen yanıt geliyor mu, eksik ya da hatalı veriyle anlamlı bir hata dönüyor mu, yetkisi olmayan kullanıcı başkasının kaydına ulaşabiliyor mu. Bulguları tekrar üretilebilir istek örnekleriyle raporluyor, isterseniz testleri her sürümde otomatik çalışacak biçimde CI hattınıza bağlıyoruz.
02Kimler için
API testi hizmeti hangi durumlarda gerekir
Servis katmanının ayrı test edilmesi şu durumlarda doğrudan risk azaltır.
- Aynı arka ucu hem web hem iOS ve Android uygulamasıyla paylaşan ürün ekipleri
- API'sini bayilerine, iş ortaklarına ya da dış geliştiricilere açan yazılım şirketleri
- Ödeme, kargo ve e-Fatura gibi üçüncü taraf servislere bağlı sipariş akışı yürüten e-ticaret işletmeleri
- Dış ekipten devraldığı servisin neyi doğru yaptığını belgelemek isteyen teknik yöneticiler
- Büyük bir sürüm yükseltmesi ya da yeniden yazım öncesinde mevcut davranışı güvenceye almak isteyen ekipler
03İhtiyaçlar
Servis katmanında en sık çıkan sorunlar
Bu hatalar genellikle kullanıcı şikâyetiyle ya da muhasebe mutabakatında fark edilir.
- 01
Belgeyle uyuşmayan yanıtlar
OpenAPI ya da Swagger belgesinde zorunlu görünen bir alan bazı kayıtlarda boş döner, tarih biçimi uç noktadan uç noktaya değişir. Entegrasyon yapan taraf belgeye güvenerek kod yazar ve canlıda hata alır.
- 02
Nesne düzeyinde yetki açıkları
Kimliği doğrulanmış bir kullanıcı, istekteki sipariş numarasını değiştirerek başka birinin siparişini görebilir. OWASP API güvenlik listesinin başında yer alan bu açık, yalnızca arayüzden yapılan testte gözden kaçar.
- 03
Tekrarlanan isteklerde mükerrer kayıt
Zayıf bağlantıda yeniden gönderilen ödeme ya da sipariş isteği iki ayrı kayıt oluşturur. Tekrar güvenli (idempotent) çalışması gereken işlemlerin özellikle sınanması gerekir.
- 04
Anlamsız hata yanıtları
Hatalı veriyle gelen istek her durumda aynı genel sunucu hatasını döndürür ya da yığın izini dışarı sızdırır. İstemci neyin yanlış olduğunu anlayamaz, saldırgan ise gereğinden fazlasını öğrenir.
04Özellikler
API testi kapsamında neler sınanır
Test planı servislerinizin kritikliğine göre önceliklendirilir.
- 01
Sözleşme ve şema doğrulaması
Her yanıt, alan tipleri, zorunlu alanlar ve durum kodlarıyla birlikte belgeye karşı otomatik kontrol edilir. Mobil sürümleri bozacak geriye dönük uyumsuz değişiklikler sürüm çıkmadan işaretlenir.
- 02
Kimlik doğrulama ve rol senaryoları
JWT ya da OAuth 2.0 belirteçlerinin süresi dolduğunda, iptal edildiğinde ve farklı rollerle kullanıldığında servisin davranışı ayrı ayrı denenir.
- 03
Sınır değer ve negatif testler
Boş, çok uzun, yanlış tipte ya da beklenmeyen karakter içeren girdilerle servis zorlanır; doğrulama kurallarının sunucu tarafında da çalıştığı kontrol edilir.
- 04
Uçtan uca iş akışı zincirleri
Sepete ekleme, ödeme, sipariş onayı ve iade gibi birbirine bağlı çağrılar sırasıyla, gerçekçi test verisiyle çalıştırılır. Ara adımda kesilen akışın veriyi tutarsız bırakıp bırakmadığına bakılır.
- 05
Temel yanıt süresi ölçümü
Her uç noktanın tek kullanıcıdaki yanıt süresi kayda geçer; belirgin yavaşlık gösteren sorgular ayrıca raporlanır. Yoğun trafik altındaki davranış yük ve stres testlerinin konusudur.
05Entegrasyonlar
API testlerini bağladığımız araç ve servisler
Testleri ekibinizin sahiplenebileceği araçlarla yazarız.
- 01
Postman koleksiyonları ve Newman
Senaryolar ekibinizin de açıp çalıştırabileceği koleksiyonlar hâlinde teslim edilir; komut satırından otomatik koşturulabilir.
- 02
Kod içi test çatıları
Projenin diline göre REST Assured, pytest, Jest ya da Supertest gibi araçlarla depoda yaşayan testler yazılabilir.
- 03
CI hatları
GitHub Actions, GitLab CI veya Jenkins üzerinde her birleştirmede testler çalışır; kırılan sözleşme birleştirmeyi durdurur.
- 04
Üçüncü taraf test ortamları
Örneğin iyzico ya da PayTR gibi ödeme kuruluşlarının, kargo firmalarının ve e-Fatura özel entegratörlerinin sunduğu test ortamları kullanılarak gerçek para ve gerçek gönderi oluşmadan akış denenir.
- 05
Tüketici odaklı sözleşme testleri
Birden fazla servisin birbirini çağırdığı yapılarda Pact gibi araçlarla her tüketicinin beklentisi ayrıca kayda alınabilir.
06Süreç
API testi hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
API testi yaparken izlediğimiz ilkeler
Testleri canlı sistem yerine, mümkünse canlıya benzer ayrı bir ortamda çalıştırırız. Kişisel veri içeren kayıtlar test ortamına maskelenerek aktarılır; KVKK açısından gerçek müşteri bilgisinin test araçlarında dolaşmasını istemeyiz. Canlı ortamda yalnızca okuma yapan, onayınız alınmış sınırlı kontroller yapılır.
Devamını okuDaha az göster
Testin kalıcı değer üretmesi için kırılgan olmamasına dikkat ederiz. Sıralaması değişebilen listeler, sunucunun ürettiği kimlikler ve zaman damgaları sabit değer gibi karşılaştırılmaz; her test kendi verisini hazırlar ve işi bitince temizler. Böylece testler aynı sonucu her çalıştırmada verir ve ekip onlara güvenmeyi öğrenir.
Rapor, bulguları önem derecesine göre sıralar ve her biri için tekrar üretilebilir bir istek örneği içerir. Güvenlik bulguları ayrı bir bölümde, kimin erişimine açılacağı sizinle konuşularak paylaşılır.
08Çalışma modelleri
Bu hizmette çalışma modelleri
09Sık sorulan sorular
API testi hakkında sık sorulan sorular
API testi fiyatları neye göre değişir?
Uç nokta sayısı, iş akışlarının karmaşıklığı, rol çeşitliliği, belge olup olmadığı ve testlerin tek seferlik mi yoksa CI'a bağlı kalıcı bir paket olarak mı isteneceği belirleyicidir. Servis listenizi gördükten sonra kapsamı ve teklifi yazılı olarak iletiriz.
API belgemiz yok; test yine de yapılabilir mi?
Yapılabilir. Uygulamanın gönderdiği istekleri izleyerek ve kodu okuyarak mevcut davranışı çıkarırız. Bu çalışmanın yan ürünü olarak güncel bir OpenAPI belgesi de elde edersiniz.
API testi ile sızma testi aynı şey mi?
Değil. API testi servisin işlevsel doğruluğunu, sözleşmesini ve temel yetki kurallarını sınar. Kapsamlı bir sızma testi ise saldırgan bakış açısıyla yürütülen ayrı bir güvenlik çalışmasıdır; yetki açığı bulduğumuzda bunu raporlar, gerekirse ayrı bir güvenlik değerlendirmesi öneririz.
GraphQL ya da SOAP servisleri de test ediyor musunuz?
Evet. GraphQL'de sorgu derinliği ve alan bazlı yetki, SOAP servislerinde ise WSDL'e uygunluk ve hata mesajı yapısı ayrıca ele alınır. Eski kurumsal sistemlerle yapılan entegrasyonlarda SOAP hâlâ yaygındır.
Testleri teslim aldıktan sonra kendi ekibimiz sürdürebilir mi?
Testler sizin deponuzda, sizin seçtiğiniz araçla ve okunabilir isimlendirmeyle yazılır. Teslimde nasıl çalıştırıldığını ve yeni uç nokta eklendiğinde nasıl genişletileceğini anlatan kısa bir kılavuz da bırakırız.
Test için servislerimize nasıl erişiyorsunuz?
Test ortamı için ayrı, yetkisi sınırlı hesaplar ve belirteçler talep ederiz. Canlı sisteme ait anahtarlar paylaşılmaz; iş bitiminde açılan test erişimlerinin kapatılmasını öneririz.
10İlgili hizmetler