Bu sayfada sorun giderme yardımı ve Firebase Test Lab ile testler çalıştırmayla ilgili sık sorulan soruların yanıtları sağlanmaktadır. Bilinen sorunlar da belgelenmiştir. Aradığınızı bulamıyorsanız veya ek yardıma ihtiyacınız varsa Firebase Slack'teki #test-lab kanalına katılın veya Firebase desteğiyle iletişime geçin.
Sorun giderme
Test Lab kataloğundan kapasite seviyesi yüksek bir cihaz seçtiğinizde testler daha hızlı başlayabilir. Bir cihazın kapasitesi düşük olduğunda testlerin yürütülmesi daha uzun sürebilir. Çağrılan testlerin sayısı seçilen cihazların kapasitesinden çok daha fazlaysa testlerin tamamlanması daha uzun sürebilir.
Herhangi bir düzeydeki cihaz kapasitesi düzeyinde yürütülen testler, aşağıdaki faktörlerden dolayı daha uzun sürebilir:
- Cihazın kullanılabilirliğini ve test hızını etkileyen trafik.
- Her an gerçekleşebilecek cihaz veya altyapı arızaları. Test Lab için rapor edilmiş bir altyapı olup olmadığını kontrol etmek için Firebase durum kontrol paneline bakın.
Test Lab'deki cihaz kapasitesi hakkında daha fazla bilgi edinmek için Android ve iOS için cihaz kapasitesi bilgilerine bakın.
Sonuçsuz test sonuçları genellikle iptal edilen test çalıştırmaları veya altyapı hataları nedeniyle ortaya çıkar.
Altyapı hataları, ağ hataları veya beklenmeyen cihaz davranışları gibi dahili Test Laboratuvarı sorunlarından kaynaklanır. Test Lab, sonuçsuz bir sonuç bildirmeden önce birçok kez altyapı hataları üreten test çalıştırmalarını dahili olarak kullanımdan kaldırır; ancak bu yeniden denemeleri failFast kullanarak devre dışı bırakabilirsiniz.
Hatanın nedenini belirlemek için şu adımları izleyin:
- Firebase durum kontrol panelinde bilinen kesintileri kontrol edin.
Tekrarlanabilir olduğunu doğrulamak için testi Test Laboratuvarında yeniden deneyin.
Varsa testi farklı bir cihazda veya cihaz türünde çalıştırmayı deneyin.
Sorun devam ederse Firebase Slack'teki #test-lab kanalından Test Laboratuvarı ekibiyle iletişime geçin.
Parçalama, belirttiğiniz parça sayısı Test Laboratuvarı'nda kullanılabilen cihaz sayısını aştığında testlerinizin daha uzun süre çalışmasına neden olabilir. Bu durumu önlemek için farklı bir cihaza geçmeyi deneyin. Farklı bir cihaz seçme hakkında daha fazla bilgi için bkz.Cihaz Kapasitesi .
Bir test isteği gönderdiğinizde, uygulamanız öncelikle cihazda test çalıştırmaya hazırlık amacıyla doğrulanır, yeniden imzalanır vb. Normalde bu işlem birkaç saniyeden kısa sürede tamamlanır ancak uygulamanızın boyutu gibi faktörlerden etkilenebilir.
Uygulamanız hazırlandıktan sonra test yürütmeleri planlanır ve cihaz onu çalıştırmaya hazır olana kadar kuyrukta kalır. Tüm test yürütmelerinin çalışması bitene kadar matris durumu "Beklemede" olacaktır (test yürütmelerinin kuyrukta olup olmadığına veya aktif olarak çalışıyor olmasına bakılmaksızın).
Test yürütmesi tamamlandıktan sonra test yapıları cihazdan indirilir, işlenir ve Cloud Storage'a yüklenir. Bu adımın süresi eserlerin miktarına ve boyutuna göre etkilenebilir.
Test yürütme yapıları (ekran görüntüleri ve günlük dosyaları gibi) Google Cloud Storage'da depolanır ve doğrudan Firebase konsolunda oluşturulur. Test yürütmeniz son 90 gün içinde gerçekleştirildiyse proje düzeyinde roller (proje sahibi, proje editörü veya proje görüntüleyici) atadığınızı kontrol edin. Lütfen projeniz veya kuruluşunuz için Cloud Audit Logging'in etkinleştirilmediğinden de emin olun.
Yürütme 90 günden daha uzun bir süre önce gerçekleştirildiyse büyük ihtimalle test eserleri otomatik olarak silinmiştir. Test Lab kontrol panelindeki Test sonuçları sekmesine tıklayarak sonuç grubu yapılandırmasını kontrol edebilirsiniz. Varsayılan sonuç grubu, nesneleri 90 gün boyunca tutacak şekilde yapılandırılmıştır.
Test yapıtlarınızı daha uzun süre korumak için gcloud firebase test android run
komutunu --results-bucket
işaretiyle çalıştırın ve sonuç grubunun adını iletin. Daha fazla bilgi için gcloud firebase test android run
referans belgelerini ziyaret edin.
Enstrümantasyon testlerini çalıştırdığınızda, Test run failed to complete. Expected x tests, received y
(burada y
, x
küçüktür). Bu hata, Test Lab'ın genellikle AndroidJUnitRunner tarafından oluşturulan test senaryosu başlangıç veya bitiş işaretçileri için logcat'ı ayrıştıramadığı anlamına gelir.
Bu sorunun yaygın nedenleri şunlardır:
Sorunun Açıklaması | Olası çözüm |
---|---|
Zaman aşımı nedeniyle test senaryosu çalışmadı. Testlerin toplam süresi belirttiğiniz zaman aşımından veya maksimum zaman aşımından uzunsa Test Laboratuvarı geri kalan test senaryolarını iptal eder. |
|
Test senaryosu zamanından önce çıktığı veya takıldığı için tamamlanamadı. Yakalanmayan bir istisna veya iddia hatası nedeniyle test senaryosundan erken çıkılabilir. Test senaryoları sonsuz bir döngüde sıkışıp kalabilir veya örneğin uygulama doğru görünümü göstermiyorsa ve test senaryosu kullanıcı arayüzünde eylemi gerçekleştiremiyorsa ilerleyemeyebilir. | Testin nerede durduğunu araştırmak için videoyu ve logcat kontrol edin. |
Özel bir test çalıştırıcısı (AndroidJUnitRunner'ın genişletilmesi dahil) beklenmedik bir şekilde çöktü veya logcat beklenmeyen test senaryosu başlangıç veya bitiş işaretçileri yazdı. | Test çalıştırıcısı kodunuzu kontrol edin. |
logcat aşırı miktarda günlük yazıldı, bu da ara belleğin dolmasına veya logcat işleminin çökmesine neden oldu. | logcat yazma işlemlerini azaltın. |
Test edilen uygulama çöktü. | Uygulamanızda hata ayıklayın. |
Sıkça Sorulan Sorular
Firebase Test Lab, cihazlarda test yapmak ve Cloud API'leri kullanmak için ücretsiz kotalar sunar. Test kotasının standart Firebase fiyatlandırma planını kullandığını ancak Cloud API kotalarının kullanmadığını unutmayın.
Test kotası
Test kotaları, testleri çalıştırmak için kullanılan cihaz sayısına göre belirlenir. Firebase Spark planının kullanıcılara hiçbir ücret ödemeden sabit bir test kotası vardır. Blaze planı için Google Cloud kullanımınız zaman içinde artarsa kotalarınız artabilir. Test kotanıza ulaştıysanız ertesi güne kadar bekleyin veya Spark planındaysanız Blaze planına yükseltin. Zaten Blaze planındaysanız kota artışı talebinde bulunabilirsiniz. Daha fazla bilgi için bkz. Test kotası .
Test kotası kullanımınızı Google Cloud konsolundan izleyebilirsiniz.
Cloud Testing API kotası
Cloud Testing API'nin iki kota sınırı vardır: proje başına günlük istekler ve proje başına 100 saniyelik istekler. Kullanımınızı Google Cloud konsolunda izleyebilirsiniz.
Cloud Tool Results API kotası
Cloud Tool Results API iki kota sınırıyla birlikte gelir: proje başına günlük sorgular ve proje başına her 100 saniyede bir sorgular. Kullanımınızı Google Cloud konsolunda izleyebilirsiniz.
API sınırları hakkında daha fazla bilgi için Test Lab için Cloud API kotalarına bakın. API kotasına ulaştıysanız:
Kotalarınızı doğrudan Google Cloud konsolunda düzenleyerek daha yüksek kotalar için istek gönderin (sınırların çoğunun varsayılan olarak maksimuma ayarlandığını unutmayın) veya
Google Cloud konsolunda bir istek formu doldurarak veya Firebase desteğiyle iletişime geçerek daha yüksek API kotaları talep edin.
Arka uçtan, kaynak IP adresini IP aralıklarımıza göre kontrol ederek trafiğin Firebase tarafından barındırılan test cihazlarından gelip gelmediğini belirleyebilirsiniz.
Test Lab, uygulamaların ve diğer test yapılarının Test Lab'in dahili depolama alanı ile kullanıcıların sonuç grupları arasında kopyalanmasını engelleyen VPC-SC ile çalışmaz.
Testlerinizdeki kesintili davranışı tespit etmek için--num-flaky-test-attemptsseçeneğini kullanmanızı öneririz. Deflake yeniden çalıştırmaları, normal test yürütmeleriyle aynı şekilde faturalandırılır veya günlük kotanıza sayılır.
Aşağıdakileri aklınızda bulundurun:
- Bir hata algılandığında test yürütmesinin tamamı yeniden çalıştırılır. Yalnızca başarısız olan test senaryolarının yeniden denenmesine yönelik destek yoktur.
- Deflake yeniden deneme çalıştırmaları aynı anda çalışacak şekilde planlanmıştır ancak örneğin trafiğin kullanılabilir cihaz sayısını aştığı durumlarda paralel olarak çalışacakları garanti edilmez.
Evet! Test Lab, Google Pixel Watch'u destekler. Artık testleri Google Pixel Watches'taki bağımsız Wear uygulamanızda çalıştırabilirsiniz. Test Lab cihazları hakkında daha fazla bilgi edinmek için bkz. Mevcut cihazlarda test etme .
Evet! Test Lab, Google Pixel Tablet ve Google Pixel Fold'u destekler. Testlerinizi bağımsız fiziksel cihazlarınızda çalıştırabilirsiniz. Test Lab cihazları hakkında daha fazla bilgi edinmek için bkz. Mevcut cihazlarda test etme .
Uygulamanızı Firebase'de test ediyorsanız veya Play Console'da lansman öncesi rapor için testler çalıştırıyorsanız Firebase tarafından barındırılan bir cihazda bir testin çalıştırılıp çalıştırılmadığını, firebase.test.lab
sistem özelliğini kontrol ederek tespit edebilirsiniz. MainActivity
dosyanız. Daha sonra testLabSetting
boole değerine dayalı olarak ek ifadeler yürütebilirsiniz. Daha fazla bilgi için bkz. Değiştirilmiş test davranışları .
Bu öğelerin bazıları yol haritamızda yer alsa da şu anda bu test ve uygulama geliştirme platformlarını destekleme taahhüdünü sunamıyoruz. Ancak uygulamanızı Espresso'yu destekleyen bir çerçeveyle (örneğin, Flutter) oluşturduysanız Espresso'yu kullanarak bir enstrümantasyon testi yazabilir ve ardından testi Test Lab'da çalıştırabilirsiniz.
Test Lab, gizlemeyi veya gizlemeyi kaldırmayı açıkça desteklemez. Uygulama muhtemelen çalışacak olsa da, yığın izleri gibi gizlenmiş uygulama verileri günlüklerde gizlenmiş olarak görünecektir.
Evet! Katlanabilir cihazınızı katlanabilir hal ve duruşlarda test edebilirsiniz.
Katlanabilir cihazlar, FLAT
(tamamen açık) veya HALF_OPENED
(tamamen açık ile tamamen kapalı arasında) gibi çeşitli katlanmış durumlarda olabilir.
Duruşlar ise belirli cihaz yönelimi ve katlanabilir durumdan oluşur. Örneğin, yatay yönde HALF_OPENED
durumu olan masa üstü duruşu veya dikey yönde HALF_OPENED
durumu olan kitap duruşu.
Enstrümantasyon testleri çalıştırıyorsanız Jetpack WindowManager kitaplığını kullanabilir ve farklı durumları ve duruşları test etmek için uygulamanızı katlanabilir belgelerde test etmeyi takip edebilirsiniz.
Alternatif olarak, mevcut durumlar cihaza özeldir ve adb shell command cmd device_state
kullanılarak etkileşime geçilebilir.
- Mevcut durumu listelemek için
adb shell cmd device_state state
çalıştırın. - Geçerli durumu ayarlamak veya geçersiz kılmak için
adb shell cmd device_state state <IDENTIFIER>
çalıştırın. - Durumu sıfırlamak için
adb shell cmd device_state state reset
çalıştırın. - Kullanılabilir durumları kontrol etmek için katlanabilir cihazda
adb shell cmd device_state print-states
komutunu çalıştırın.
Google Pixel Fold (model kimliği felix
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSED', app_accessible=true}, DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true}, DeviceState{identifier=2, name='OPENED', app_accessible=true}, DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true}, ]
Samsung Galaxy Z Fold4 (model kimliği q4q
)
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSE', app_accessible=true}, DeviceState{identifier=1, name='TENT', app_accessible=true}, DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true}, DeviceState{identifier=3, name='OPEN', app_accessible=true}, ]
Diğer Firebase ürünlerinden farklı olarak Test Lab'ı kullanmak için Firebase SDK eklemenize gerek yoktur. Henüz bir uygulamanız yoksa çevrimiçi bir APK indirebilir veya AndroidX GitHub deposundaki örneklerden birinden bir uygulama ve test APK'sı oluşturabilirsiniz. Bir Robo testi çalıştırmak için yalnızca uygulamanızın APK dosyasına ihtiyacınız olduğunu, enstrümantasyon testinin ise hem bir uygulamayı hem de kaynak kodundan oluşturulmuş bir test APK'sını gerektirdiğini unutmayın. Daha fazla bilgi için Enstrümanlı testler hakkında bilgi edinin.
Test Lab özellikleri hakkında daha fazla bilgi edinmek için Firebase Test Lab ile Android testlerine başlama bölümüne bakın.
Ekran görüntüsü fark testi, test iddialarının, bir test çalıştırılırken elde edilen ekran görüntülerinin beklenen davranışı temsil eden altın görüntülerle karşılaştırılmasına dayandığı yerdir. Bu tür testler bazı cihaz türlerinde diğerlerinden daha kırılgan olabilir. Bu tür testler için Arm ( *.arm
) emülatör cihazlarını hedeflemenizi öneririz. Arm emülatör cihazları, Android Studio 'genel' emülatörlerine çok benzeyen veya aynı görselleri kullanır.
Ayrıca beklenen değişikliklerin varlığında ekran görüntüsü testlerinin daha sağlam olmasına yardımcı olabilecek test kitaplıklarını da araştırmanızı öneririz.
Evet! Aşağıdaki değişiklikler yapıldığında sanal cihazlar güncellenir:
- Mevcut görsellerde güncellemeler
- Önceki API seviyelerinin kullanımdan kaldırılması
- Yeni Android API düzeyleri eklendi
Kapsam raporlarını etkinleştirmek için, environmentVariables
alanına coverage=true
ekleyin. Android Test Orchestrator kullanıyorsanız kapsam sonuçlarını depolamak için bir dizin sağlamanız gerekir:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
Orkestratör kullanmıyorsanız bir dosya yolu belirtebilirsiniz:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
Ayrıntılı cihaz bilgilerine API üzerinden ulaşılabilir ve bu bilgilere, açıklama komutunu kullanarak gcloud istemcisinden erişilebilir:
gcloud firebase test android models describe MODEL
Bilinen Sorunlar
Robo testi, oturum açmak için kimlik bilgilerini girmenin ötesinde, örneğin CAPTCHA'yı tamamlamak gibi ek kullanıcı eylemi gerektiren oturum açma ekranlarını atlayamaz.
Robo testi, Android kullanıcı arayüzü çerçevesindeki kullanıcı arayüzü öğelerini ( View
, ViewGroup
ve WebView
nesneleri dahil) kullanan uygulamalarla en iyi şekilde çalışır. Unity oyun motorunu kullanan uygulamalar da dahil olmak üzere diğer kullanıcı arayüzü çerçevelerini kullanan uygulamaları denemek için Robo testini kullanırsanız test, ilk ekranın ötesini keşfetmeden çıkabilir.