Sorunun cevabı.
Platforma özgü davranışları normalize etmek için, test betiklerinin temel işletim sistemi uygulamalarına bağımlı kalmamasını sağlamak amacıyla özel eklentilerle birlikte Appium 2.0 kullanarak bir Cihaz Soyutlama Katmanı (DAL) tasarlayın. Mitmproxy veya Toxiproxy aracılığıyla Android için (örneğin ADB port yönlendirmesi ile) ve iOS için Network Link Conditioner profilleri (bu, simctl komutları aracılığıyla tetiklenir) kullanarak trafiği kesen bir Ağ Sanalizasyon Kontrolörü uygulayın; böylece gecikme, paket kaybı ve bant genişliği kısıtlama enjekte edebilirsiniz. Bellek uyarılarını simüle etmek için Android Debug Bridge (ADB) kabuk komutlarını kullanarak ve iOS için XCTestMetric API'leri ve termal durum bildirimlerini kullanarak NSProcessInfo termal durumlarını izleyen bir Kaynak Baskı Enjeksiyon Modülü entegre edin. Test yürütme ortamlarını Selenium Grid veya bulut sağlayıcı SDK'ları (AWS Device Farm, Firebase Test Lab) ile birlikte Docker kullanarak konteynerleştirerek, paralel test yürütmeleri arasında durum kirlenmesini önlemek için sıkı süreç izolasyonu sağlan. Son olarak, platformlar arasında ekran görüntüsü hash'lerini ve API yanıt dizilerini karşılaştıran bir Deterministik Durum Doğrulama Protokolü oluşturun; bunun için OpenCV kullanarak görüntü farkı alabilir ve JSON Şeması doğrulaması yaparak, farklı yerel uygulamaların yanı sıra işlevsel eşitliği garanti edersiniz.
Hayattan bir durum
Bir lojistik teknoloji şirketinde, hücresel ölü bölgelerde çevrimdışı işlem yeteneği gerektiren kritik bir teslimat sürücü uygulaması geliştirdik. Bu uygulama, hem yüksek kaliteli iPhone'ları hem de 2GB RAM'e sahip bütçe dostu Android cihazları hedefliyordu. Başlangıçta otomasyon kümelememiz, yerel Android Emulator ve iOS Simulator örneklerinde kusursuz çalıştı, ancak AWS Device Farm üzerinde ağ gecikmesi değişimleri ve fiziksel cihazlardaki saldırgan Doze Modu davranışları nedeniyle %40 oranında tutarsızlık gösterdi. Spesifik hata, ödeme senkronizasyonu sırasında gerçekleşti: testler, emülatörün sınırsız CPU kaynaklarının arka planda bir iş parçacığı bekleme durumunu gizlemesi nedeniyle tutarsız bir şekilde zaman aşımına uğradı; bu durum ancak Android ActivityManager CPU'yu termal baskı altında kısıtladığında belirdi.
Üç farklı mimari yaklaşımı değerlendirdik. İlk olarak, tamamen bulut sağlayıcılarının yerleşik ağ şekillendirme araçlarına güvenmek hızlı bir uygulama sağlar, ancak belirli 3G kule geçiş davranışlarını simüle etmek için ayrıntı eksikliği vardır ve yerel hata ayıklamayı engelleyen tedarikçi kilidini oluşturur. İkincisi, donanım ağ koşullandırıcıları ile bir yerinde Faraday kafesi cihaz laboratuvarı inşa etmek, çevresel kontrol sağlar; ancak $150K sermaye harcaması ve özel DevOps bakımını gerektirir, bu da bu modelin CI/CD hacmimiz için ekonomik olarak uygulanabilir olmaktan çıkmasına yol açar. Üçüncü olarak, Docker ile konteynerleştirilmiş Appium düğümleri, ağ manipülasyonu için Toxiproxy ve kaynak enjeksiyonu için ADB tabanlı bir ara katman mimarisi uygulamak, 500ms gecikme ve %2 paket kaybı ile TRIM_MEMORY_RUNNING_CRITICAL sinyalleri dahil olmak üzere tam üretim koşullarını yeniden üretmemizi sağladı; aynı zamanda yerel ve bulut ortamında yürütme esnekliğini koruduk.
Üçüncü çözümü seçtik çünkü belirleyici yeniden üretilebilirlik ile altyapı maliyeti arasında bir denge sağlıyordu. Traffic Control (tc) Linux komutları aracılığıyla ağ profillerini betikleyerek ve XCUITest performans metriği toplama işlemini entegre ederek, bellekte baskı olayları sırasında yalnızca meydana gelen bir yarış durumu tespit ettik. Bu durum, kritik veri kaybı hatasının üretilmeden önce kapatılmasını sağladı ve iki sprint içinde otomasyon tutarsızlığımızı %40'tan %2,5'e düşürdü.
Adayların genelde atladığı şeyler
Kaynak sınırlı bir ortamda, test akışını bozup gerçekçi kullanıcı yolculuklarını geçersiz kılmadan, yerel işletim sistemi izin pencerelerini nasıl yönetiyorsunuz?
Adaylar genellikle izinleri manifest değişiklikleri ile devre dışı bırakmayı öneriyor, ama bu kritik kod yollarını atlatıyor. Doğru mimari, sistem UI paket adlarını izleyen (Android'de com.android.packageinstaller, iOS'ta com.apple.springboard) özel Bekleme Koşulları ile birlikte WebDriverWait kullanarak bir Koruyucu Deseni uygulamaktadır. Android için, test kurulumu sırasında izinleri adb shell pm grant <package> android.permission.<name> komutu ile önceden verin veya sistem pencereleri tespit edildiğinde etkileşimde bulunmak için UiAutomator'ı ikinci bir otomasyon motoru olarak kullanın. iOS için, simulasyon öncesinde xcrun simctl privacy kullanarak izinleri verin ve fiziksel cihazlarda, CPU kısıtlamaları nedeniyle beklenmeyen modallerin görünüm zamanlamasını yönetirken ana test iş parçacığının engellenmeden kalmasını sağlamak için XCUITest'in addUIInterruptionMonitor ile bir engelleme yapmayan iş parçacığı uygulayın.
Appium oturum başlatma işlemi, bulut cihaz çiftliklerinde neden aralıklı olarak başarısız olur ve yürütme hızını tehlikeye atmadan nasıl dayanıklılık mimarisi tasarlarsınız?
Çoğu aday bunu ağ kararsızlığına atfeder, ancak gerçek neden WebDriverAgent (iOS) veya UiAutomator2 Server (Android) başlangıç yarış koşuludur. Kaynak kısıtlı cihazlarda, WDA'yı Xcodebuild aracılığıyla derlemek ve başlatmak varsayılan zaman aşımını aşabilir, özellikle de termal kısıtlama altında. Cihaz hazır olma durumunu ideviceinfo (iOS) veya adb shell getprop sys.boot_completed (Android) ile 45 saniyelik bir zaman aşımı ile doğrulayan bir Sağlık Kontrol Ön İşleyici mimarisi oluşturun; ardından oturum oluşturma için bir üssel geri çekilme tekrar stratejisi (1s, 2s, 4s, 8s) uygulayın. Derleme gecikmelerini ortadan kaldırmak için önceden oluşturulmuş WebDriverAgent ikili dosyalarını Appium'un derivedDataPath yeteneği kullanarak ön bellekleyin ve --session-override devre dışı bırakılarak açık port yönetimi uygulayarak, cihaz tahsisatını engelleyen hayalet oturumların oluşmasını engelleyerek, aşırı yüklenmiş paylaşımlı cihaz çiftliklerinde bile belirleyici bir başlatma sağlayın.
Arka planda, bellek baskısı nedeniyle işletim sistemi uygulamanızı sonlandırdığında uygulama durumunun geri yüklenmesini nasıl doğruluyorsunuz, çevrimdışı işlem kuyruklarında veri bozulmasını önlemek için?
Adaylar genellikle ana sayfa düğmesi ile arka planlamayı test eder, ancak çevrimdışı öncelikli uygulamalar için kritik olan Ölüm ve Yeniden Yükleme senaryosunu göz ardı ederler. Android'de bellek baskısını adb shell am send-trim-memory <package> RUNNING_CRITICAL komutunu kullanarak programlı olarak tetikleyin, ardından uygulamayı am force-stop ile zorla kapatın ve yeniden başlatın; onSaveInstanceState paketlerini Logcat doğrulamaları veya Espresso'nun SavedStateRegistry incelemesi aracılığıyla kontrol edin. iOS için, özel XCTest yöntemi olan simulateMemoryWarning() kullanın (veya XCUIDevice.shared.press(.home) kullanarak arka plan/ön plan döngülerini uygulayın) ardından uygulamayı sonlandırın ve başlatın; NSCoder arşivlerinin işlem kuyruklarının bütünlüğünü sağladığını doğrulayın. Bu, otomasyon çerçevesinin durum tutarlılığını doğrulamasına olanak tanıyan uygulamada test edilebilirlik kancaları inşa edilmesini gerektirir; örneğin, kritik uygulama kodu güvenliğini tehlikeye atmadan gizli Erişim tanımlayıcıları veya hata ayıklama BroadcastReceivers aracılığıyla iç veritabanı kontrol toplamları açmak gibi.