Örnek sorular
Mq Mobile Locators Sync FlakinessZorluk 1
Bir Android UI Automator dump'ında bir elemanın resource-id niteliği, uygulamanın kaynak kodunda neye karşılık gelir?
- aView'ın
android:id değeri, uygulamanın paket ön ekiyle birlikte gösterilir, örn. com.example.app:id/submit_button✓ - bUI dump'ının alındığı andaki view'ın ekran üzerindeki piksel koordinatları
- cO view için bir ekran okuyucunun seslendireceği erişilebilirlik etiketi
- dAppium'un her test çalıştırmasında locator'ları benzersiz tutmak için tazeden ürettiği rastgele bir hash
Açıklama:resource-id, view'ın android:id değerinden (ya da kodda atanan id'den) doldurulur ve hiyerarşi dump'ında paket ön ekiyle raporlanır. Ekran koordinatları ayrı bir bounds niteliğidir, resource-id değildir. Ekran-okuyucu etiketi ise tamamen farklı bir nitelik olan content-desc'e karşılık gelir. Appium resource-id değeri uydurmaz; sadece uygulamanın zaten sunduğunu okur.
Mq Mobile Locators Sync FlakinessZorluk 2
Appium'un -android uiautomator stratejisinde, UiSelector ile bir view'ı tam görünen metnine göre hedeflemek için hangi satır doğrudur?
- anew UiSelector().label("Sign in")
- bBy.text("Sign in")
- cnew UiSelector().text("Sign in")✓
- dnew BySelector().text("Sign in")
Açıklama:UiSelector, bir -android uiautomator string'i içinde değerlendirilen akıcı Java builder'ıdır ve .text(...) tam görünen metni eşler. .label(...) bir UiSelector metodu değildir — label iOS/XCUITest terminolojisidir, Android'in UiAutomator API'sinin parçası değildir. By, ayrı bir instrumented-test sınıfıdır (UiDevice.findObject(By.text(...))), -android uiautomator string'i içinde kurulan bir şey değildir. BySelector da UiSelector gibi new ile örneklenip zincirlenmez.
Mq Mobile Locators Sync FlakinessZorluk 1
iOS'ta Appium'un accessibility id locator stratejisi gerçekte neyi eşler?
- aElemanın, dile göre çevrilen görünen etiket metni
- bXcode'un UI kontrolünün Swift değişken adından otomatik ürettiği bir isim
- cElemanın
accessibilityIdentifier'ı — salt otomasyon araçları için atanmış, dile göre değişmeyen bir değer✓ - dYalnızca
value da sunan elemanlarda (metin alanı, slider gibi) var olan bir değer
Açıklama:accessibility id, geliştiricinin atadığı, dile göre çevrilmeyen ve özellikle test/erişilebilirlik araçları için var olan accessibilityIdentifier'a eşlenir. Görünen etiket metni farklı bir niteliktir (label) ve dile göre değişir. Xcode değişken adından otomatik kimlik üretmez; bunun açıkça atanması gerekir. accessibilityIdentifier, elemanın bir value'ya sahip olup olmamasından bağımsızdır — buton ve etiketler de taşıyabilir.
Mq Mobile Locators Sync FlakinessZorluk 2
iOS'ta, XCUITest/Appium üzerinden görülen bir elemanın label'ı ile value'su arasındaki temel fark nedir?
- a
label ve value, her eleman tipinde tamamen aynı string'in birbirinin yerine geçen iki adıdır - b
label, elemanın ne olduğunu anlatan (genelde yerelleştirilmiş) metindir; value ise güncel durumu ya da içeriği yansıtır✓ - c
value her zaman elemanın accessibilityIdentifier'ını taşır, label ise dahili bir bellek adresini taşır - d
label yalnızca buton'larda, value yalnızca image'lerde bulunur
Açıklama:XCUITest, label'ı (eleman ne/ne söylüyor) ve value'yu (güncel durum ya da içerik) ayrı nitelikler olarak sunar — bir switch'in label'ı "Wi-Fi" iken value'su "1" ya da "0" olabilir. Birbirinin takma adı değillerdir. value, kimliği taşımaz — bu ayrı bir identifier/accessibilityIdentifier niteliğidir. Hiçbiri yalnızca buton'a ya da yalnızca image'e özgü değildir.
Mq Mobile Locators Sync FlakinessZorluk 2
Bir elemanı content-desc (Android) ya da label (iOS) ile bulmak, neden özel bir test kimliğiyle bulmaktan daha kırılgan olma eğilimindedir?
- aÇeviri ekipleri onu görünen UI metniyle birlikte yerelleştirir, bu yüzden tam-string'e kurulu bir locator başka dilde bozulur✓
- bÇünkü Appium bu değeri güvenlik amacıyla her uygulama açılışında rastgele yeniden üretir
- cÇünkü herhangi bir build konfigürasyonundan bağımsız olarak her release build'de kırpılır
- dÇünkü yalnızca debug build'lerde var olur ve her release APK/IPA'sından derlemede çıkarılır
Açıklama:content-desc/label erişilebilirliğe hizmet etmek için vardır, bu yüzden bir ekran-okuyucu kullanıcısının duyduğu aynı yerelleştirilmiş ifadeyi taşırlar — uygulamayı yeni bir pazar için çevirmek bu string'i değiştirir, ona sabit kodlanmış her locator'ı bozar. Appium bu değerleri rastgeleleştirmez. content-desc ya da label, geliştirici atadığı sürece release build'lerden çıkarılan debug-özel bir yapı değildir.
Mq Mobile Locators Sync FlakinessZorluk 2
Mobilde bir XPath sorgusu, aynı elemanı resource-id veya accessibility id gibi özel bir niteliğe göre bulmaktan neden genelde çok daha pahalıdır?
- aXPath sorguları mobil işletim sistemi üreticisi tarafından karakter başına ücretlendirilir, bu yüzden uzun ifadeler orantılı olarak daha pahalıdır
- bDriver tüm erişilebilirlik ağacını serileştirip düğüm düğüm gezmek zorundadır, bu yüzden maliyet ağaç boyutuyla ölçeklenir✓
- cXPath, mobil işletim sistemlerinin kullanımını caydırmak için aktif olarak kısıtladığı kullanımdan kaldırılmış bir protokoldür
- dXPath, tamamen yerel bir emülatörde test edilirken bile her zaman bulut cihaz çiftliğine bir ağ round-trip'i gerektirir
Açıklama:XPath değerlendirmesi gezilecek tam bir ağaç gerektirir, bu yüzden driver önce o anki hiyerarşinin tamamını serileştirir — derin ya da büyük bir ekran, hedef nerede olursa olsun her XPath sorgusunu yavaşlatır. Bir işletim sistemi üreticisinin XPath için karakter başına ücretlendirmesi yoktur. XPath, Android/iOS tarafından kısıtlanmaz ya da kullanımdan kaldırılmamıştır. XPath değerlendirmesi tamamen cihaz/driver üzerinde gerçekleşir, bulut ağ round-trip'iyle ilgisi yoktur.