Örnek sorular
Mobile Testing AutomationZorluk 2
Mobil test piramidinde unit testler neden paketin en büyük payını oluşturur?
- aBir cihazda çalışabilen tek test türü onlardır
- bHızlı ve izole, geri bildirim çabuk gelir✓
- cUI render doğruluğunu otomatik doğrularlar
- dUI değişince güncellenmeleri gerekmez
Açıklama:Unit testler, UI ya da cihaz olmadan küçük ve izole bir mantık parçasını çalıştırır; bu yüzden milisaniyeler içinde koşar ve ilgisiz nedenlerle nadiren bozulur. Piramidin tabanına çok sayıda unit test konulmasının nedeni bu hız ve kararlılıktır.
Mobile Testing AutomationZorluk 2
Tam UI (uçtan uca) testler unit testlere kıyasla neden genelde daha pahalı ve kırılgandır?
- aHiç otomatikleştirilemezler
- bYalnızca derleme zamanı tipleri kontrol ederler
- cTüm katman çalışır, daha çok şey bozulur✓
- dHer zaman yalnızca tek ekranı test ederler
Açıklama:Bir UI testi, uygulamayı render, animasyon, navigasyon ve çoğu zaman ağ ya da cihaz durumu üzerinden gerçek şekilde çalıştırır. Bu katmanların her biri potansiyel bir hata kaynağıdır ve ek çalışma süresi getirir; bu da UI testlerini yavaşlatır ve ilgisiz nedenlerle bozulma olasılığını artırır.
Mobile Testing AutomationZorluk 1
Piramitte unit ve UI testler arasında yer alan integration test nedir?
- aBirkaç gerçek parçanın, tam UI olmadan birlikte çalışması✓
- bTek bir saf fonksiyonun izole kontrolü
- cYalnızca CI sunucusunda çalışır, yerelde asla
- dManuel QA ihtiyacını ortadan kaldırır
Açıklama:Integration testler ortada yer alır: birbirleriyle gerçekten işbirliği yapan birkaç birimi (ör. bir repository ile konuşan bir view-model) bir araya getirip aralarındaki bağlantıları kontrol ederler, ama gerçek render edilmiş UI'yi çalıştırmaktan kaçınırlar; bu da onları tam UI testlerinden daha hızlı ve kararlı yapar.
Mobile Testing AutomationZorluk 2
Bir UI testi ekran yüklendikten hemen sonra bir düğmeye dokunuyor, ama tap handler'ı yalnızca animasyon bitince bağlanıyor. Test aralıklı başarısız oluyor. En olası neden?
- aFramework düğmeye dokunmayı desteklemiyor
- bEkranda bir memory leak var
- cTest hazırlığı değil animasyonu yarıştı✓
- dDüğme yanlış renkte
Açıklama:Animasyonlar ve diğer asenkron UI geçişleri zamanlama değişkenliği getirir. Test, ekranın (ve handler'larının) gerçekten hazır olduğunu doğrulamadan körlemesine dokunursa, bazen uygulamanın önüne geçip başarısız olur — klasik bir flaky test kök nedeni.
Mobile Testing AutomationZorluk 2
Bir mobil testte ağ bağımlılığını mock'lamak ne demektir?
- aAğ yokken testi devre dışı bırakmak
- bGerçek çağrıyı sahte bir yanıtla değiştirmek✓
- cGecikmeyi ortalamak için testi iki kez çalıştırmak
- dSunucunun gerçek yanıtını binary'ye gömmek
Açıklama:Bir ağ bağımlılığını mock'lamak, gerçek çağrıyı önceden belirlenmiş bir yanıt (başarı, hata, boş, yavaş vb.) döndüren bir yerine geçenle değiştirmek demektir. Bu, dış bir sunucunun kullanılabilirliğine bağımlılığı kaldırır ve testin tam olarak hangi senaryoyu çalıştıracağını kontrol etmesini sağlar.
Mobile Testing AutomationZorluk 3
Profil-çekme testi gerçek backend'e istek atıyor. Backend yavaşladığında ilgisiz testler de başarısız oluyor. En iyi çözüm?
- aO test için ağ katmanını mock'la✓
- bBaşarısız testleri sil
- cTimeout'u 10 dakikaya çıkar
- dPaketi yalnızca gece çalıştır
Açıklama:Asıl sorun, uygulamanın kendi mantığını kontrol etmesi gereken bir testin canlı, dış bir sisteme sıkı bağımlılığıdır. Ağ çağrısını mock'lamak, testi backend kullanılabilirliğinden izole eder ve güvenilmez bir dış bağımlılığı kontrollü, tekrarlanabilir bir girdiye çevirir.