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.