Örnek sorular
Qa Api TestingZorluk 1
Ekranlarda tıklayarak ilerleyen bir UI testine kıyasla, bir API testi öncelikle neyi kontrol eder?
- aArayüz katmanındaki request ve response'ları, hiç ekran çizmeden✓
- bHer ekranın farklı tarayıcılarda ve pencere boyutlarında doğru render edildiğini
- cButon ve renk gibi görsel öğelerin tasarım dosyasıyla piksel piksel eşleştiğini
- dBir insan test uzmanının tüm görevi yalnızca mouse ve klavye ile baştan sona tamamlayabildiğini
Açıklama:API testi, UI'ın altındaki arayüzle doğrudan konuşur: bir istek gönderir ve status code, response body ve yan etkiler üzerinde iddia kurar — hiç ekran devreye girmez. Render, layout ve piksel seviyesi kontroller (b, c) UI/görsel test alanına aittir; manuel uçtan uca görev tamamlama (d) tamamen ayrı bir test faaliyetidir.
Qa Api TestingZorluk 2
Bir ekip, UI test suite'lerinin 40 dakika sürdüğünü ve genelde test edilen özellikle ilgisiz nedenlerle başarısız olduğunu fark ediyor. Aynı kontrolleri API testlerine indiriyorlar. Ana pratik fayda nedir?
- aAPI testleri otomatik olarak ekranın doğru göründüğünü de doğrular, dolayısıyla UI kontrollerini kaldırmakla bir şey kaybedilmez
- bAPI testleri render ve UI zamanlamasını atlar; bu yüzden daha hızlı çalışır ve UI katmanından gelen kararsızlığa daha az maruz kalır✓
- cAPI testlerinin hiç test verisi kurulumuna ihtiyacı yoktur, çünkü API'yi kullanmak yerine doğrudan veritabanıyla konuşurlar
- dAPI testleri manuel keşifsel testin yerini alır, çünkü olası her kullanıcı yolunu otomatik olarak kapsarlar
Açıklama:API testi render, animasyon ve UI zamanlamasını atladığı için çok daha kısa sürede çalışır ve ekranları beklemekten kaynaklanan kararsızlığa maruz kalmaz — katman avantajı budur. Bir şeyin nasıl göründüğünü kontrol etmez (a), gerçekçi girdi verisine hâlâ ihtiyaç duyar (c), ve keşifsel testin yerini almaz (d) — o, farklı türde sorunları hedefler.
Qa Api TestingZorluk 1
Bir API'yi çağıran consumer ile onu sunan provider arasındaki bağlamda contract test nedir?
- aProvider'ın yavaşlamadan önce saniyede kaç isteği kaldırabildiğini ölçen bir test
- bGeliştirme başlamadan önce her iki ekibin imzaladığı, API'yi düz dille anlatan hukuki bir belge
- cConsumer'ın beklediği şeklin provider'ın ürettiğiyle uyuştuğunu kontrol eden test✓
- dYalnızca iki sistem birlikte production ortamına deploy edildikten sonra çalışan bir test
Açıklama:Contract test, consumer'ın bir etkileşimden ne beklediğini (alanlar, tipler, zorunlu değerler) yakalar ve bu beklentiyi provider'a karşı kontrol eder; ikisi entegre olmadan önce uyumsuzluğu yakalar. Throughput ölçümü (a) performans testidir, imzalı belge (b) otomatik bir test değildir, production'a kadar beklemek (d) ise contract testin tam olarak önlemeye çalıştığı şeydir.
Qa Api TestingZorluk 2
Bir mobil ekibin uygulaması, sipariş response'undaki total alanının sayı olmasını bekliyor. Bir backend ekibi total'ı sessizce string'e çeviriyor ("49.90") ve deploy ediyor. Mobil uygulama production'da çökene kadar kimse fark etmiyor. Bunu daha önce ne yakalardı?
- aHer release öncesi mobil uygulamanın daha fazla ekranını kapsayan daha geniş bir manuel QA regresyon turu
- bBackend ekibinin olağandışı response örüntülerini daha erken fark etmesi için load test trafiğini artırmak
- cBackend ekibinden kendi iç hesaplama mantığı için daha fazla unit test yazmasını istemek
- d
total'ın beklenen tipini kodlayan ve backend her değiştiğinde çalışan bir contract test✓
Açıklama:Bu tam olarak bir contract test'in yakalamak için var olduğu kırılmadır: mobil ekibin beklentisi (total sayıdır) çalışan bir kontrole dönüştürülür, backend her değiştiğinde tetiklenir ve alan tipi gerçek bir cihaza ulaşmadan build'i düşürür. Daha fazla manuel regresyon (a) hâlâ birinin o alanı kontrol etmesine bağlıdır, load test (b) kapasiteyi ölçer, şekli değil, backend'in kendi unit testleri (c) kendi iç mantığını doğrular, consumer'ın response'tan gerçekte ne istediğini değil.
Qa Api TestingZorluk 1
Test tasarımında stub ile mock arasındaki temel fark nedir?
- aStub çağrıldığında hazır bir yanıt döndürür; mock ise çağrının beklendiği gibi yapıldığını doğrulamaya izin verir✓
- bStub yalnızca veritabanı çağrıları için, mock ise yalnızca harici API çağrıları için kullanılabilir
- cStub geliştiriciler tarafından yazılır, mock ise yalnızca test uzmanları tarafından manuel test case'lerinin parçası olarak yazılır
- dStub gerçek bağımlılıktan daha yavaş çalışır, mock ise gerçek bağımlılıkla tam olarak aynı hızda çalışır
Açıklama:Stub'ın işi, gerçek bağımlılık olmadan testin devam edebilmesi için hazırlanmış bir yanıt döndürmektir. Mock da bunu yapar ama ayrıca etkileşimi kaydeder; böylece test "bu çağrı tam olarak bir kez, şu argümanlarla yapıldı mı" gibi bir iddia kurabilir. İkisi de belirli bir bağımlılık türüne bağlı değildir (b), ikisi de testi yazan kişi tarafından yazılır (c), hız (d) ikisi arasındaki ayırt edici özellik değildir — davranış doğrulama yeteneğidir.
Qa Api TestingZorluk 2
POST /orders testi, test çalıştırması başına gerçek ücret kesen ve test ortamında bazen erişilemeyen üçüncü taraf bir ödeme sağlayıcısını çağırmak zorunda. Sipariş mantığının kendisini test etmenin en pratik yolu nedir?
- aÖdeme sağlayıcısı her ortamda %100 uptime garanti edene kadar bu endpoint'i test etmemek
- bÖdeme sağlayıcısının yerine kontrollü yanıt döndüren bir test double koyup sipariş mantığını test etmek✓
- cTesti ayda bir kez gerçek ödeme sağlayıcısına karşı çalıştırmak, çünkü ücret yalnızca o tek çalıştırmada kesiliyor
- dÖdeme sağlayıcısının ekibinden kendi servisini yavaşlatmasını istemek — test tamamlanması için daha fazla süre olsun
Açıklama:Ödeme çağrısı için test double kullanmak, sipariş testini kendi mantığına (verilen bir ödeme sonucu için sipariş doğru oluşturuluyor, fiyatlanıyor, kaydediliyor mu) odaklı tutar; gerçek ücret ödemeden ya da sağlayıcının uptime'ına bağımlı kalmadan. Ödeme sağlayıcısının gerçek servisiyle davranışı kendi testlerine aittir, idealde az sayıda gerçek uçtan uca kontrol de buna dahildir. Endpoint'i atlamak (a) onu test edilmemiş bırakır, ayda bir gerçek çalıştırma (c) zamanın çoğunu kapsamsız bırakır, sağlayıcıdan servisini senin testin için değiştirmesini istemek (d) altta yatan bağımlılık sorununu çözmez.