Örnek sorular
Qa Ci Cd TestingZorluk 1
CI/CD pipeline'ında otomatik testlerin bir "gate" (kapı) olarak davranması ne anlama gelir?
- aBaşarısız zorunlu bir test, kodun bir sonraki aşamaya geçmesini engeller✓
- bTestler yalnızca yazılım kullanıcılara zaten yayınlandıktan sonra çalıştırılır
- cPipeline devam edebilmesi için her testin bir insan tarafından manuel olarak tekrar çalıştırılması gerekir
- dTest sonuçları ileride okunmak üzere kaydedilir ama pipeline sonucunu hiçbir zaman etkilemez
Açıklama:Test gate demek, gerekli testler başarısız olduğunda pipeline'ın durması (merge'ü, deploy'u, promosyonu engellemesi) için yapılandırılmış olması demektir; böylece test edilmemiş veya bozuk kod sessizce ilerleyemez.
Qa Ci Cd TestingZorluk 2
Bir test pipeline'ında "hızlı geri-bildirim döngüsü" ilkesinin (en ucuz ve en hızlı testleri önce çalıştırmanın) temel gerekçesi nedir?
- aUcuz testler pahalı testlerden daha doğrudur, bu yüzden erken sonuçlar daha güvenilirdir
- bBariz bir hata, uzun bir paket bitmeden dakikalar içinde raporlanır✓
- cUcuz testleri önce çalıştırmak, yazılması gereken toplam test sayısını azaltır
- dPahalı testler her zaman ucuz testlerin geçmesine bağımlıdır, bu yüzden sıra aslında önemli değildir
Açıklama:Testleri en ucuz/en hızlıdan en pahalıya doğru sıralamak, bariz bir bozulmanın uzun süren bir paket bitmeden dakikalar içinde raporlanması anlamına gelir; bu da geliştiricinin bir şeyin bozuk olduğunu öğrenmesi için beklediği süreyi kısaltır.
Qa Ci Cd TestingZorluk 2
Bir pipeline şu anda yavaş uçtan uca (end-to-end) UI testlerini, hızlı unit testlerinden ÖNCE çalıştırıyor. Bu sıralamanın temel dezavantajı nedir?
- aUnit testler, UI testlerinden önce değil sonra çalıştıkları için güvenilmez hale gelir
- bUnit testler zaten geçmediği sürece uçtan uca testler hiç otomatikleştirilemez
- cÖnemsiz bir hata, ancak çok daha uzun süren UI paketi bittikten sonra raporlanır✓
- dPipeline'da yazılabilecek toplam test sayısı bu sıralama tarafından sınırlanır
Açıklama:Ucuz, hızlı testler en sona konursa, önemsiz bir hata bile ancak pahalı paket tamamlandıktan sonra raporlanır; bu geri bildirimi geciktirir ve yavaş paketin harcadığı zaman ile kaynağı, hızlı bir testin zaten reddedeceği kod üzerinde boşa harcanmış olur.
Qa Ci Cd TestingZorluk 1
Bir pipeline içinde test tiplerini sıralamak için yaygın olarak önerilen aşamalandırma stratejisi nedir?
- aHız veya bağımlılık fark etmeksizin tüm test tiplerini tek bir birleşik aşamada aynı anda çalıştırmak
- bÖnce uçtan uca testleri çalıştırmak, böylece unit ve entegrasyon testleri yalnızca bütün sistem zaten çalışıyorken çalışsın
- cHiçbir tip tutarlı biçimde pipeline'ı engellemesin diye test tipi sırasını her çalıştırmada rastgele değiştirmek
- dÖnce unit testleri, sonra entegrasyon testlerini, sonra daha geniş uçtan uca testleri çalıştırmak — en küçük kapsam önce✓
Açıklama:Testleri en dar ve en ucuzdan (unit) en geniş ve en pahalıya (uçtan uca/UI) doğru aşamalandırmak test piramidini yansıtır ve hataların onları yakalayabilecek en ucuz aşamada ortaya çıkmasını sağlar.
Qa Ci Cd TestingZorluk 2
Bir pipeline yapılandırması, her aşamanın yalnızca bir önceki aşama başarılı olduğunda başladığı üç sıralı aşama tanımlar: unit-tests, integration-tests, e2e-tests. unit-tests başarısız olursa ne olur?
- a
integration-tests ve e2e-tests hiç çalışmaz✓ - bPipeline yalnızca nihai birleşik sonucu raporladığı için üç aşama yine de paralel çalışır
- cYalnızca
e2e-tests atlanır, ama integration-tests unit testlere bağımlı olmadığı için yine de çalışır - dPipeline
unit-testsi geçene kadar otomatik olarak döngüde tekrar dener, sonra devam eder
Açıklama:Aşamalar başarıya bağlı olarak sıkı biçimde sıralıysa, başarısız olan unit-tests aşaması, sonraki aşamaların başlama koşulu bir öncekinin başarısı olduğu için pipeline'ı sonraki aşamalar başlamadan durdurur.
Qa Ci Cd TestingZorluk 3
Bir test paketi paylaşılan bir veritabanına karşı çalışıyor. İki pipeline çalıştırması aynı anda yürütülüyor ve ikisi de aynı sabit ID ile bir kayıt ekliyor; bu da gerçek bir hatayla ilgisi olmayan bir duplicate-key hatasıyla bir çalıştırmanın başarısız olmasına neden oluyor. Bu neyin örneğidir?
- aYalnızca test çalıştırıcısı ile veritabanı arasındaki ağ gecikmesinden kaynaklanan flaky bir test
- bBir test ortamı izolasyon sorunu: eşzamanlı çalıştırmalar durumu paylaşıyor ve birbirini kirletiyor✓
- cTam olarak yapması gerekeni yapan, doğru çalışan bir test gate'i
- dOrtamla ilgisi olmayan, tek bir test sürecinin içindeki bir test paralelleştirme sorunu
Açıklama:Bu başarısızlığın test edilen kodla hiçbir ilgisi yok; iki çalıştırmanın izolasyon olmadan aynı veritabanını/durumu paylaşmasından kaynaklanıyor. Bu, tek bir çalıştırma içindeki zamanlamadan kaynaklanan flakiness'ten farklı, klasik bir test ortamı izolasyonu ve temizlik sorunudur.