Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini memberikan bantuan pemecahan masalah dan jawaban atas pertanyaan
umum (FAQ) tentang penggunaan Firebase Test Lab. Masalah umum juga
didokumentasikan. Jika tidak dapat menemukan hal
yang Anda cari atau membutuhkan bantuan lainnya, bergabunglah dengan saluran
#test-lab di
Firebase Slack atau hubungi dukungan
Firebase.
Pemecahan masalah
Mengapa pengujian saya perlu waktu begitu lama untuk dijalankan?
Saat Anda memilih perangkat dengan tingkat kapasitas tinggi di Test Lab
katalog, pengujian dapat dimulai lebih cepat. Jika
kapasitas perangkat rendah, pengujian mungkin perlu waktu lebih lama untuk berjalan. Jika jumlah pengujian yang dipanggil jauh lebih besar daripada kapasitas perangkat yang dipilih, pengujian dapat memerlukan waktu lebih lama untuk selesai.
Pengujian pada tingkat kapasitas perangkat apa pun mungkin memerlukan waktu lebih lama karena faktor berikut:
Traffic, yang memengaruhi ketersediaan perangkat dan kecepatan pengujian.
Kegagalan perangkat atau infrastruktur, yang dapat terjadi kapan saja. Untuk memeriksa
jika ada infrastruktur yang dilaporkan untuk Test Lab, lihat
Dasbor status Firebase.
Untuk mempelajari kapasitas perangkat lebih lanjut di Test Lab, lihat informasi kapasitas
perangkat untuk Android dan iOS.
Mengapa saya menerima hasil pengujian yang tidak meyakinkan?
Hasil pengujian yang tidak meyakinkan biasanya terjadi karena pengujian yang dibatalkan
atau error infrastruktur.
Error infrastruktur disebabkan oleh masalah Test Lab internal, seperti error
jaringan atau perilaku perangkat yang tidak terduga. Test Lab secara internal menghentikan pengujian
yang menghasilkan error infrastruktur beberapa kali sebelum melaporkan hasil
yang tidak meyakinkan. Namun, Anda dapat menonaktifkan percobaan ulang ini menggunakan
failFast.
Untuk mengetahui penyebab error, ikuti langkah-langkah berikut:
Coba lagi pengujian di Test Lab untuk memverifikasi bahwa pengujian tersebut dapat direproduksi.
Coba jalankan pengujian di perangkat atau jenis perangkat lain, jika ada.
Jika masalah berlanjut, hubungi tim Test Lab di
saluran#test-lab di
Firebase Slack.
Mengapa sharding membuat pengujian berjalan
lebih lama?
Sharding dapat menyebabkan pengujian berjalan lebih lama jika jumlah shard yang Anda
tetapkan melebihi jumlah perangkat yang dapat digunakan di Test Lab. Untuk
menghindari situasi ini, coba beralih ke perangkat lain. Untuk informasi selengkapnya
tentang cara memilih perangkat lain, lihat
Kapasitas Perangkat.
Mengapa perlu waktu lama untuk memulai pengujian?
Saat Anda mengirimkan permintaan pengujian, aplikasi akan divalidasi terlebih dahulu, ditandatangani ulang, dll. sebagai
persiapan untuk menjalankan pengujian pada perangkat. Biasanya, proses ini selesai dalam waktu kurang dari beberapa detik, tetapi dapat dipengaruhi oleh faktor seperti ukuran aplikasi Anda.
Setelah aplikasi Anda siap, eksekusi uji akan dijadwalkan dan tetap berada dalam antrean sampai perangkat siap menjalankannya. Hingga semua eksekusi uji selesai berjalan, status matriks akan menjadi "Tertunda" (terlepas dari apakah eksekusi uji berada dalam antrean atau berjalan secara aktif).
Mengapa perlu waktu lama untuk
menyelesaikan pengujian?
Setelah eksekusi uji selesai, artefak pengujian akan didownload dari
perangkat, lalu diproses, dan diupload ke Cloud Storage. Durasi langkah ini dapat
terpengaruh oleh jumlah dan ukuran artefak.
Aplikasi tidak menampilkan data dan tidak dapat menemukan screenshot
Artefak eksekusi uji (seperti screenshot dan file log) disimpan di
Google Cloud Storage dan langsung dirender ke Firebase console. Jika
eksekusi uji Anda dilakukan dalam 90 hari terakhir, periksa apakah Anda telah
menetapkan peran level project (project owner, project editor, atau project viewer).
Pastikan juga bahwa Cloud Audit Logging tidak diaktifkan untuk project Anda atau organisasi Anda.
Jika eksekusi dilakukan lebih dari 90 hari yang lalu, kemungkinan besar
artefak pengujian telah dihapus secara otomatis. Anda dapat memeriksa
konfigurasi bucket hasil dengan mengklik tab Test results di
dasbor Test Lab. Bucket hasil default
dikonfigurasi untuk menyimpan objek selama 90 hari.
Untuk mempertahankan artefak pengujian Anda lebih lama, jalankan perintah gcloud firebase test android run dengan flag --results-bucket dan teruskan nama bucket hasil. Untuk mengetahui informasi selengkapnya, buka dokumentasi referensi gcloud firebase test android run.
Mengapa saya menerima hasil kasus uji instrumentasi sebagian atau kosong?
Saat menjalankan uji instrumentasi, Anda mungkin melihat error pengujian yang menunjukkan
hasil sebagian yang berisi pesan seperti Test run failed to complete. Expected
x tests, received y (dengan y lebih kecil dari x).
Error ini berarti bahwa Test Lab tidak dapat mengurai logcat untuk penanda awal
atau akhir kasus pengujian yang biasanya dihasilkan oleh
AndroidJUnitRunner.
Berikut adalah penyebab umum masalah ini:
Deskripsi masalah
Kemungkinan resolusi
Kasus pengujian tidak berjalan karena waktu tunggu habis. Jika total durasi
pengujian lebih lama daripada waktu tunggu yang ditentukan atau lebih lama dari
waktu tunggu maksimum,
Test Lab akan membatalkan kasus pengujian lainnya.
Tingkatkan waktu tunggu matriks untuk memastikan semua pengujian dapat diselesaikan.
Lakukan sharding pengujian jika Anda belum melakukannya, sehingga setiap shard menjalankan subset pengujian dan selesai dalam jangka waktu yang lebih singkat.
Jika Anda sudah mengaktifkan sharding, tingkatkan jumlah shard.
Kasus pengujian gagal diselesaikan karena keluar sebelum waktunya atau macet.
Kasus pengujian dapat keluar lebih awal karena pengecualian yang tidak tertangkap atau error pernyataan. Kasus pengujian bisa macet dalam loop yang tidak terbatas atau mungkin tidak dapat dilanjutkan, misalnya, jika aplikasi tidak menampilkan tampilan yang benar dan kasus pengujian tidak dapat melakukan tindakan di UI.
Lihat video dan logcat untuk menyelidiki tempat pengujian dihentikan.
Runner pengujian kustom (termasuk memperluas AndroidJUnitRunner) mengalami error secara tidak terduga atau menulis penanda awal atau akhir kasus pengujian yang tidak terduga pada logcat.
Periksa kode runner pengujian Anda.
Terlalu banyak log yang ditulis ke logcat sehingga membebani buffer atau membuat proses logcat mengalami error.
Kurangi penulisan menjadi logcat.
Aplikasi yang sedang diuji mengalami error.
Lakukan debug aplikasi Anda.
Pertanyaan umum (FAQ)
Berapa jumlah kuota gratis
untuk Test Lab? Apa yang harus saya lakukan jika kehabisan kuota?
Firebase Test Lab menawarkan kuota gratis untuk pengujian di perangkat dan untuk penggunaan
Cloud API. Perhatikan bahwa kuota pengujian menggunakan paket harga Firebase standar,
sedangkan kuota Cloud API tidak.
Kuota pengujian
Kuota pengujian ditentukan oleh jumlah perangkat yang digunakan untuk menjalankan pengujian.
Paket Firebase Spark memiliki kuota pengujian tetap tanpa biaya bagi pengguna. Untuk
paket Blaze, kuota Anda dapat meningkat jika penggunaan Google Cloud Anda meningkat seiring waktu. Jika Anda mencapai kuota pengujian, tunggu hingga hari berikutnya atau upgrade ke paket Blaze jika saat ini Anda menggunakan paket Spark.
Jika sudah menggunakan paket Blaze, Anda dapat meminta penambahan kuota.
Untuk informasi lebih lanjut, lihatKuota pengujian.
Cloud Testing API memiliki dua batas kuota: permintaan per hari per
project, dan permintaan per 100 detik per project. Anda dapat memantau
penggunaan di
Google Cloud console.
Kuota Cloud Tool Results API
Cloud Tool Results API memiliki dua batas kuota: kueri per hari per
project, dan kueri per 100 detik per project. Anda dapat memantau
penggunaan di
Google Cloud console.
Lihat Kuota Cloud API untuk Test Lab
guna mengetahui informasi selengkapnya tentang batas API. Jika Anda telah mencapai batas kuota API:
Kirim permintaan untuk mendapatkan kuota yang lebih tinggi dengan
mengedit kuota
langsung di Google Cloud Console (perlu diperhatikan bahwa sebagian besar batas ditetapkan
ke batas maksimum secara default), atau
Minta kuota API yang lebih tinggi dengan mengisi formulir permintaan di
Google Cloud console atau dengan menghubungi
dukungan Firebase.
Bagaimana cara mengetahui apakah
traffic yang menjangkau backend saya berasal dari Test Lab?
Dari backend, Anda dapat menentukan apakah traffic berasal dari perangkat uji
yang dihosting Firebase atau tidak dengan memeriksa alamat IP sumber terhadap
rentang IP kami.
Apakah Test Lab berfungsi dengan
VPC-SC?
Test Lab tidak berfungsi dengan VPC-SC, yang memblokir
penyalinan aplikasi dan artefak pengujian lainnya antara penyimpanan internal
Test Lab dan bucket hasil pengguna.
Bagaimana cara mendeteksi pengujian yang tidak stabil di
Test Lab?
Untuk mendeteksi perilaku yang tidak stabil dalam pengujian Anda, sebaiknya gunakan opsi
--num-flaky-test-attempts
. Penggunaan ulang Deflake ditagih atau dihitung terhadap kuota harian Anda sama seperti
eksekusi uji normal.
Ingat hal berikut:
Seluruh eksekusi uji akan berjalan lagi saat kegagalan terdeteksi. Tidak ada dukungan untuk mencoba ulang kasus uji yang gagal saja.
Proses percobaan ulang Deflake dijadwalkan untuk berjalan pada waktu yang sama, tetapi tidak dijamin dijalankan secara paralel, misalnya, saat traffic melebihi jumlah perangkat yang tersedia.
Apakah Test Lab mendukung
perangkat wearable?
Ya. Test Lab mendukung Google Pixel Watch. Kini Anda dapat menjalankan pengujian di
aplikasi Wear mandiri di Google Pixel Watch. Untuk mempelajari perangkat
Test Lab lebih lanjut, lihat Menguji pada
perangkat yang tersedia.
Apakah Test Lab mendukung
perangkat Google terbaru?
Ya. Test Lab mendukung Google Pixel Tablet dan Google Pixel Fold. Anda dapat
menjalankan pengujian di perangkat fisik mandiri.
Untuk mempelajari perangkat
Test Lab lebih lanjut, lihat Menguji pada
perangkat yang tersedia.
Bagaimana cara mendeteksi pengujian yang sedang berjalan
di Test Lab?
Jika Anda menguji aplikasi di Firebase atau menjalankan pengujian untuk
laporan pra-peluncuran
di Konsol Play, Anda dapat mendeteksi apakah pengujian sedang
dijalankan di perangkat yang dihosting Firebase atau tidak dengan memeriksa properti sistem
firebase.test.lab di file MainActivity. Selanjutnya, Anda dapat mengeksekusi pernyataan tambahan berdasarkan nilai boolean untuk testLabSetting. Untuk mengetahui
informasi selengkapnya, lihat
Perilaku pengujian yang dimodifikasi.
Apakah Test Lab
mendukung Appium, Flutter/FlutterDriver, ReactNative/Jest, atau Cucumber?
Meskipun beberapa item tersebut tercakup dalam rencana kami, saat ini kami tidak dapat memberikan
komitmen untuk mendukung platform pengujian dan pengembangan aplikasi ini. Namun,
jika Anda mem-build aplikasi dengan framework yang mendukung Espresso (misalnya,
Flutter), Anda dapat menulis uji instrumentasi menggunakan
Espresso
lalu menjalankan pengujian di Test Lab.
Apakah Test Lab
mendukung pengujian aplikasi yang di-obfuscate, misalnya, dengan ProGuard atau R8)?
Test Lab tidak secara eksplisit mendukung obfuscation atau deobfuscation. Meskipun
aplikasi kemungkinan akan berjalan, data aplikasi yang di-obfuscate, seperti pelacakan tumpukan,
akan muncul sebagai di-obfuscate dalam log.
Dapatkah saya menggunakan perangkat foldable saya di
berbagai status dan postur perangkat foldable saat menguji di Test Lab?
Perangkat foldable dapat berada dalam berbagai status terlipat, seperti FLAT (terbuka sepenuhnya) atau HALF_OPENED (antara terbuka sepenuhnya dan tertutup sepenuhnya).
Di sisi lain, postur terdiri dari orientasi perangkat dan status
perangkat foldable tertentu. Misalnya, postur mode di atas meja, yang merupakan status HALF_OPENED dalam orientasi horizontal, atau postur buku, yang merupakan status HALF_OPENED dalam orientasi vertikal.
Dapatkah saya mencoba Test Lab jika tidak memiliki
aplikasi?
Tidak seperti produk Firebase lainnya, Anda tidak perlu menambahkan Firebase
SDK untuk menggunakan Test Lab. Jika belum memiliki aplikasi, Anda dapat
mendownload APK secara online atau mem-build aplikasi dan APK pengujian dari salah satu
contoh yang ada di repositori GitHub AndroidX.
Perhatikan bahwa Anda hanya memerlukan file APK aplikasi untuk menjalankan uji Robo, sedangkan uji instrumentasi memerlukan aplikasi dan APK pengujian yang di-build dari kode sumber. Untuk mengetahui informasi selengkapnya,
baca informasi tentang Pengujian berinstrumen.
Perangkat apa yang paling cocok untuk
pengujian perbedaan screenshot?
Pada pengujian perbedaan screenshot, pernyataan pengujian didasarkan pada perbandingan gambar layar yang diperoleh saat menjalankan pengujian dengan gambar emas yang mewakili perilaku yang diharapkan. Pengujian tersebut mungkin lebih rapuh pada beberapa jenis perangkat dibandingkan dengan perangkat lainnya. Sebaiknya targetkan perangkat emulator Arm (*.arm) untuk jenis pengujian ini. Perangkat emulator Arm menggunakan image yang sangat mirip atau identik dengan emulator 'generik' Android Studio.
Sebaiknya Anda juga menyelidiki library pengujian yang dapat membantu membuat
pengujian screenshot lebih efektif dengan adanya perubahan yang diharapkan.
Apakah Test Lab memperbarui perangkat virtual?
Ya. Perangkat virtual diperbarui saat perubahan berikut dilakukan:
Pembaruan pada gambar yang sudah ada
Penghentian penggunaan level API sebelumnya
Level API Android baru telah ditambahkan
Bagaimana cara mengaktifkan laporan cakupan?
Untuk mengaktifkan laporan cakupan, tambahkan coverage=true ke kolom environmentVariables.
Jika menggunakan Android Test Orchestrator, Anda harus menyediakan direktori untuk menyimpan hasil cakupan:
Di mana detail perangkat, seperti resolusi, ABI yang didukung, dan sebagainya, dapat ditemukan?
Informasi perangkat mendetail tersedia melalui API dan dapat diakses
dari klien gcloud menggunakan
perintah jelaskan:
gcloud firebase test android models describe MODEL
Masalah umum
Captcha login
Uji Robo tidak dapat melewati layar login yang memerlukan
tindakan lain dari pengguna selain memasukkan kredensial untuk login, sebagai contoh,
seperti melengkapi CAPTCHA.
Dukungan framework UI
Uji Robo berfungsi paling baik dengan aplikasi yang menggunakan elemen UI dari framework UI Android (termasuk objek View, ViewGroup, dan WebView). Jika Anda menggunakan uji Robo untuk menguji aplikasi yang menggunakan framework UI lain, termasuk aplikasi yang menggunakan game engine Unity, pengujian dapat berakhir tanpa menjelajahi aplikasi di luar layar pertama.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-05 UTC."],[],[],null,["\u003cbr /\u003e\n\niOS Android \n\nThis page provides troubleshooting help and answers to frequently asked\nquestions about running tests with Firebase Test Lab. Known issues are also\ndocumented. If you can't find what\nyou're looking for or need additional help, join the [#test-lab\nchannel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack or contact [Firebase\nsupport](https://support.google.com/firebase/contact/support).\n\nTroubleshooting\n\n\u003cbr /\u003e\n\nWhy is my test taking so long to run?\n\n\u003cbr /\u003e\n\nWhen you select a device with a high capacity level in the Test Lab\ncatalog, tests may start faster. When a\ndevice has low capacity, tests might take longer to run. If the number of\ntests invoked is much larger than the capacity of the selected devices, tests\ncan take longer to finish.\n\n\nTests running on any level device capacity level may take longer due to the\nfollowing factors:\n\n- Traffic, which affects device availability and test speed.\n- Device or infrastructure failures, which can happen at any time. To check if there is a reported infrastructure for Test Lab, see the [Firebase status dashboard](https://status.firebase.google.com/summary).\n\n\nTo learn more about device capacity in Test Lab, see device capacity\ninformation for [Android](https://firebase.google.com/docs/test-lab/android/available-testing-devices#device-capacity) and [iOS](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device-capacity).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy am I receiving inconclusive test results?\n\n\u003cbr /\u003e\n\nInconclusive test outcomes commonly occur either because of canceled test runs\nor infrastructure errors.\n\nInfrastructure errors are caused by internal Test Lab issues, like network\nerrors or unexpected device behaviors. Test Lab internally retires test runs\nthat produce infrastructure errors multiple times before reporting an\ninconclusive outcome; however, you can disable these retries using\n[failFast](/docs/test-lab/reference/testing/rest/v1/projects.testMatrices#TestMatrix.FIELDS.fail_fast).\n\nTo determine the cause of the error, follow these steps:\n\n1. Check for known outages in the [Firebase status dashboard](https://status.firebase.google.com/summary).\n2. Retry the test in Test Lab to verify that it is reproducible.\n\n | **Note:** Test Lab does not charge you for infrastructure errors.\n3. Try running the test on a different device or device type, if applicable.\n\nIf the issue persists, contact the Test Lab team in the\n[#test-lab channel](https://firebase-community.slack.com/messages/test-lab) on\nFirebase Slack.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy did sharding make my tests run\nlonger?\n\n\u003cbr /\u003e\n\nSharding can cause your tests to run longer when the number of shards you\nspecified exceeds the number of devices available for use in Test Lab. To\navoid this situation, try switching to a different device. For more information\nabout choosing a different device, see\n\n[Device Capacity](https://firebase.google.com/docs/test-lab/ios/available-testing-devices#device_capacity).\n\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to start?\n\n\u003cbr /\u003e\n\nWhen you submit a test request, your app is first validated, re-signed, etc. in\npreparation for running tests on a device. Normally, this process completes in\nless than a few seconds, but it can be affected by factors like the size of your\napp.\n\nAfter your app is prepared, test executions are scheduled and remain in a queue\nuntil a device is ready to run it. Until all test executions finish running,\nthe matrix status will be \"Pending\" (regardless of whether test executions are\nin the queue or actively running).\n| **Note:** The time your test spends waiting for an available device does not count toward your billing time.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is it taking a long time for my\ntest to finish?\n\n\u003cbr /\u003e\n\nAfter the test execution is finished, test artifacts are downloaded from the\ndevice, processed, and uploaded to Cloud Storage. The duration of this step can\nbe affected by the amount and size of the artifacts.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nFrequently asked questions\n\n\u003cbr /\u003e\n\nWhat are the no-cost quotas\nfor Test Lab? What should I do if I run out?\n\n\u003cbr /\u003e\n\nFirebase Test Lab offers no-cost quotas for testing on devices and for using\nCloud APIs. Note that the testing quota uses the standard Firebase pricing plan,\nwhile the Cloud API quotas do not.\n\n- **Testing quota**\n\n Testing quotas are determined by the number of devices used to run tests.\n The Firebase Spark plan has a fixed testing quota at no cost to users. For\n the Blaze plan, your quotas might increase if your usage of Google Cloud\n increases over time. If you reach your testing quota, wait until the next\n day or upgrade to the Blaze plan if you are currently on the Spark plan.\n If you are already on the Blaze plan, you can request a quota increase.\n For more information, see\n [Testing quota](/docs/test-lab/usage-quotas-pricing#testing-quota).\n\n You can monitor your testing quota usage in the [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Testing API quota**\n\n The Cloud Testing API comes with two quota limits: requests per day per\n project, and requests per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/testing.googleapis.com/quotas).\n- **Cloud Tool Results API quota**\n\n The Cloud Tool Results API comes with two quota limits: queries per day per\n project, and queries per every 100 seconds per project. You can monitor your\n usage in the\n [Google Cloud console](https://console.cloud.google.com/apis/api/toolresults.googleapis.com/quotas).\n\n Refer to [Cloud API quotas for Test Lab](/docs/test-lab/usage-quotas-pricing#cloud-api-quota)\n for more information on API limits. If you've reached an API quota:\n - Submit a request for higher quotas by\n [editing your quotas](https://cloud.google.com/docs/quota#requesting_higher_quota)\n directly in the Google Cloud console (note that most limits are set to\n maximum by default), or\n\n - Request higher API quotas by filling out a request form in the\n Google Cloud console or by contacting\n [Firebase support](https://support.google.com/firebase/contact/support).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I find out if the\ntraffic reaching my backend is coming from Test Lab?\n\n\u003cbr /\u003e\n\nFrom your backend, you can determine if traffic is coming from Firebase-hosted\ntest devices by checking the source IP address against our\n[IP ranges](https://firebase.google.com/docs/test-lab/android/get-started#ip-blocks).\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab work with\nVPC-SC?\n\n\u003cbr /\u003e\n\nTest Lab does not work with VPC-SC, which blocks the\ncopying of apps and other test artifacts between Test Lab's internal\nstorage and users' results buckets.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nHow do I detect flaky tests in\nTest Lab?\n\n\u003cbr /\u003e\n\nTo detect flaky behavior in your tests, we recommend using the\n\n[--num-flaky-test-attempts](https://cloud.google.com/sdk/gcloud/reference/firebase/test/ios/run#--num-flaky-test-attempts)\n\noption. Deflake reruns are billed or counted toward your daily quota the same as\nnormal test executions.\n\nKeep the following in mind:\n\n- The entire test execution runs again when a failure is detected. There's no support for retrying only failed test cases.\n- Deflake retry runs are scheduled to run at the same time, but are not guaranteed to run in parallel, for example, when traffic exceeds the number of available devices.\n\n| **Note:** Infrastructure errors are independent from the deflake feature and don't trigger deflake reruns.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nDoes Test Lab support\nAppium, Flutter/FlutterDriver, ReactNative/Jest, or Cucumber?\n\n\u003cbr /\u003e\n\nWhile some of these items are on our roadmap, we're currently unable to provide\ncommitment to supporting these testing and app development platforms.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhere can I find device details,\nlike resolution, etc.?\n\n\u003cbr /\u003e\n\nDetailed device information is available through the API and can be accessed\nfrom the gcloud client using the\n[describe command](https://cloud.google.com/sdk/gcloud/reference/firebase/test/android/models/describe):\n\n`gcloud firebase test ios models describe `\u003cvar translate=\"no\"\u003eMODEL\u003c/var\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nCan I use sharding with iOS tests?\n\n\u003cbr /\u003e\n\nSharding isn't natively supported within Test Lab for iOS. However, you can\nuse the [Flank](https://flank.github.io/flank/) client to shard iOS test cases.\n| **Note:** Using Flank iOS sharding creates separate test matrices for each shard.\n\nThis works by setting `OnlyTestIdentifiers` key and values in `.xctestrun` file.\nSee `man` page for `xcodebuild.xctestrun` for more details.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhy is my iOS test missing videos in the\nresults?\n\n\u003cbr /\u003e\n\nFor iOS 18 or later, we are not able to support videos in the results.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nKnown issues\n\n\u003cbr /\u003e\n\nSign-in Captchas\n\n\u003cbr /\u003e\n\nRobo test cannot bypass sign-in screens that require\nadditional user action beyond entering credentials to sign in, for example,\ncompleting a CAPTCHA.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nUI framework support\n\n\u003cbr /\u003e\n\nRobo test works best with apps that use UI elements from the Android UI\nframework (including `View`, `ViewGroup`, and `WebView`\nobjects). If you use Robo test to exercise apps that use other UI\nframeworks, including apps that use the Unity game engine, the test may exit\nwithout exploring beyond the first screen.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e"]]