Örnek sorular
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 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 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.
Qa Api TestingZorluk 2
Bir test suite'i POST /subscriptions ile bir abonelik oluşturuyor, sonra arada hiçbir temizlik yapmadan aynı testi ikinci kez çalıştırıyor. İkinci çalıştırma duplicate-subscription hatasıyla başarısız oluyor. Bu, test hakkında ne ortaya koyuyor?
- aTest olduğu gibi doğrudur; ikinci çalıştırmada duplicate hatası beklenen ve istenen sonuçtur
- b
POST endpoint'inin kendisinde bir bug var; sınırsız duplicate abonelik kabul edecek şekilde değiştirilmeli - cTest ortamının veritabanı daha hızlı bir diske ihtiyaç duyuyor, çünkü duplicate tespiti bir performans konusudur
- dTest, temiz bir başlangıç durumuna bağımlı — kurulum/temizlik olmadan güvenle tekrarlanamaz✓
Açıklama:Yalnızca ilk seferde geçen ve tekrarda başarısız olan bir test durum-bağımsız değildir: belirli bir başlangıç durumunu (böyle bir abonelik henüz yok) kendisi kurmak yerine sessizce varsayar. Çözüm test tarafındadır — her çalıştırmada taze, benzersiz veri kurmak (ya da sonrasında temizlemek) — endpoint tarafında değil; endpoint gerçek bir duplicate'i doğru şekilde reddediyor (b). Bunun disk hızıyla ilgisi yoktur (c). Bir testin herhangi bir sırada, serbestçe tekrar çalıştırılabilmesi güvenilir bir suite'in temel gereksinimidir; (a) yanlıştır çünkü tekrar çalıştırmada başarısız olmak düzeltilmesi gereken semptomun ta kendisidir, hedef değil.
Qa Api TestingZorluk 2
Bir test, sabit kodlanmış bir e-posta ile kullanıcı oluşturuyor:
POST /users
{"email": "[email protected]", "name": "Test User"}
Tek başına çalıştığında sorunsuz geçiyor, ama aynı
[email protected]'u kullanan başka bir testten sonra çalıştığında başarısız oluyor. En doğrudan çözüm nedir?
- aHer çalıştırma için benzersiz bir e-posta üretmek (örn. rastgele bir ek eklemek) — test bağımsız kalsın✓
- bÇakışan iki testi iki ayrı programlama dilinde çalıştırmak; böylece birbirlerine karışamazlar
- cİstekten önce daha uzun bir bekleme eklemek — veritabanına önceki testin kullanıcı kaydını unutması için zaman tanımak
- dEndpoint'i, e-posta zaten var olsa da her zaman başarı dönecek şekilde değiştirmek
Açıklama:Testin sabit kodlanmış e-postası, onu kendinden önce ne çalıştığına bağımlı kılar — gizli bir durum bağımlılığı. Her çalıştırma için benzersiz bir değer üretmek bu bağımlılığı tamamen ortadan kaldırır; test, çalıştırma sırasından ya da başka ne çalıştığından bağımsız olarak geçer. Testin yazıldığı dil (b) paylaşılan veritabanı durumuyla ilgisizdir, daha uzun beklemek (c) önceki kaydın gittiğini garanti etmez, endpoint'in kendi validasyonunu zayıflatmak (d) kötü yazılmış bir testi geçirmek için gerçek bir iş kuralını gizler.
Qa Api TestingZorluk 2
Schema validation, bir API response'u hakkında neyi kontrol eder?
- aResponse'un, istek gönderildikten sonra kabul edilebilir bir süre içinde ulaştığını
- bResponse'un yapısının tanımlı bir şekle uyduğunu: zorunlu alanlar, doğru tipler✓
- cResponse'taki ifadelerin dilbilgisi açısından doğru ve her dilde yazım hatasından arınmış olduğunu
- dResponse'un HTTP header'larının, paylaşımlı proxy ve CDN'ler için geçerli bir cache direktifi içerdiğini
Açıklama:Schema validation, belirli değerlerden bağımsız olarak bir response'u tanımlı bir yapıyla karşılaştırır — hangi alanların var olması gerektiği, her birinin tipi ne olduğu ve genel şeklin beklendiği gibi olup olmadığı. Yanıt süresi (a) bir performans konusudur, ifade kalitesi (c) bir içerik/yerelleştirme konusudur, cache header'ları (d) ayrı bir transport-katmanı detayıdır; hiçbiri bir schema'nın kontrol ettiği şey değildir.