Gunakan tangkapan layar untuk tampilan seluruh layar, OCR untuk teks yang terlihat, dan pencocokan gambar untuk target visual yang diketahui. Tes visual Android terkuat menggabungkan satu pernyataan terfokus dengan waktu yang stabil dan bukti kegagalan.
Jawaban singkatnya: ujilah hal yang harus tetap benar
Gunakan pengujian tangkapan layar ketika seluruh layar, komponen, spasi, warna, atau tipografi harus tetap konsisten secara visual. Gunakan OCR jika persyaratannya adalah tentang kata-kata yang dapat dilihat seseorang, terutama teks yang dilokalkan atau dirender secara dinamis. Gunakan pencocokan gambar ketika ikon, tombol, lencana, atau ilustrasi yang dikenal harus muncul meskipun tidak memiliki pengenal UI yang dapat diandalkan.
Mulailah dengan pemilih UI atau status aksesibilitas ketika persyaratan bersifat semantik: kontrol ada, diaktifkan, dipilih, atau menampilkan label stabil. Tambahkan deteksi objek hanya jika target termasuk dalam kelas visual dan mungkin terlalu banyak mengubah ukuran atau posisi untuk satu templat. Metode-metode ini bersifat berlapis, bukan kerangka pengujian yang bersaing.
- Tanyakan bukti apa yang dapat meyakinkan pengulas bahwa persyaratan tersebut lolos.
- Pilih sinyal tersempit yang dapat diandalkan daripada membandingkan setiap piksel secara default.
- Stabilkan layar sebelum mengamatinya, lalu simpan artefak saat pernyataan gagal.
Metode pengujian visual Android dibandingkan
| Metode | Terbaik untuk | Kelemahan utama | Bukti yang berguna |
|---|---|---|---|
| UI atau status aksesibilitas | Kontrol, label, status yang diaktifkan, pilihan, struktur navigasi | Elemen yang dirender khusus atau tidak dapat diakses mungkin tidak terlihat di hierarki UI | Hierarki UI, properti yang dipilih, tangkapan layar |
| Tangkapan layar atau gambar emas | Tata letak, spasi, warna, tipografi, tampilan komponen | Data dinamis, animasi, perbedaan perangkat, dan perubahan rendering dapat menimbulkan perbedaan yang mencolok | Gambar saat ini, garis dasar yang disetujui, perbedaan visual |
| OCR | Teks yang terlihat, pelokalan, tanda terima, pesan status, nilai yang ditampilkan sebagai piksel | Kualitas pengenalan bergantung pada pemotongan, skala, kontras, data bahasa, rotasi, dan segmentasi | Pangkas sumber, teks yang dikenali, kepercayaan, atau daftar hasil |
| Pencocokan templat | Ikon, tombol, lencana, gambar mini, atau wilayah stabil kecil yang dikenal | Tema, skala, kompresi, dan desain ulang dapat membuat template menjadi tidak valid | Templat, wilayah pencarian, kecocokan terbaik, skor, tangkapan layar |
| Deteksi objek | Sebuah objek visual yang kelasnya tetap bermakna sementara posisi atau ukurannya bervariasi | Memerlukan model yang kompatibel, kelas berlabel, ambang batas, dan validasi model | Versi model, kelas, kotak, skor, tangkapan layar |
Panduan pengujian tangkapan layar resmi Android menjelaskan perbandingan rendering saat ini dengan gambar referensi yang disetujui. Plugin gambar Appium memperlihatkan pencocokan fitur, pencocokan template, dan perbandingan kesamaan. OpenCV mendokumentasikan mekanisme menggeser template di atas gambar, sementara Tesseract mendokumentasikan mengapa pra-pemrosesan OCR dan segmentasi halaman penting. Peralatannya berbeda-beda, namun pertanyaan desain tesnya tetap sama: pengamatan apa yang membuktikan persyaratan ini?
Pilih pernyataan yang tepat dengan empat pertanyaan
1. Apakah persyaratannya semantik atau visual?
Jika pengujian menunjukkan “tombol Kirim diaktifkan”, periksa status UI terlebih dahulu. Jika tertulis “tombol Kirim tidak terpotong setelah font diubah”, gunakan tangkapan layar atau pemeriksaan visual terfokus. Kueri semantik biasanya lebih mudah dipertahankan, namun tidak dapat membuktikan kemunculannya.
2. Apakah teks persisnya penting?
Gunakan OCR ketika string yang dilihat pengguna adalah persyaratannya dan teks tidak diekspos secara andal melalui pohon UI. Batasi pengenalan pada wilayah makna terkecil, pilih bahasa yang benar, dan bandingkan hasil yang dinormalisasi. Simpan tangkapan layar karena string OCR yang benar saja tidak dapat menampilkan pemotongan, tumpang tindih, atau kontras yang buruk.
3. Apakah ada satu target visual yang stabil?
Gunakan pencocokan template untuk ikon yang dikenal atau kontrol kecil. Pangkas templat dengan rapat, cari di dalam wilayah yang diinginkan, dan tetapkan ambang batas dari sampel nyata positif dan negatif. Satu ambang batas universal jarang dapat dipertahankan di seluruh tema, resolusi, dan aliran jarak jauh terkompresi.
4. Apakah seluruh komposisi harus tetap konsisten?
Gunakan perbandingan tangkapan layar ketika hubungan antara banyak elemen penting. Kontrol font, lokal, konfigurasi perangkat, bilah sistem, waktu, data jaringan, animasi, dan konten unggulan. Jika input tersebut tidak dapat dikontrol, tutupi atau pangkas wilayah dinamis alih-alih menerima pengujian yang berisik secara permanen.
Buat tes visual yang gagal
- Membawa aplikasi ke status awal bernama pada perangkat atau emulator resmi.
- Tunggu kondisi stabil, bukan sekadar penundaan tetap. UI Automator memberikan stabilitas menunggu, dan sinyal siap khusus aplikasi bahkan lebih baik.
- Tangkap wilayah sumber terkecil yang berisi bukti yang diperlukan.
- Jalankan satu pernyataan utama: status UI, OCR, templat, deteksi, atau perbandingan tangkapan layar.
- Simpan gambar sumber dan hasil terstruktur sebelum mengambil tindakan selanjutnya.
- Jika gagal, hentikan atau ikuti jalur pemulihan yang telah ditinjau. Jangan mengetuk orang yang mirip di sekitar hanya agar tes tetap berjalan.
Pemeriksaan visual menjadi lebih aman ketika mengotorisasi transisi. Amati keadaan saat ini, buat pernyataan, lakukan tindakan yang diperbolehkan hanya setelah berhasil, dan verifikasi kondisi pasca. Ini adalah prinsip desain yang sama yang dijelaskan dalampanduan klik otomatis pengenalan gambar: pengenalan bukanlah bukti bahwa alur kerja telah selesai.
Untuk pekerjaan perangkat nyata,Pencerminan layar Android untuk pengujian aplikasi selulermemberikan tinjauan langsung kepada pengulas saat pengujian sedang dirancang.Panduan pengujian asap QA otomatisasi Androidmenjelaskan cara menjaga pemeriksaan berulang tetap sempit dan dapat direproduksi.
Tiga skenario pengujian visual Android praktis
QA lokalisasi di layar checkout
Gunakan status UI untuk menavigasi ke layar checkout, OCR untuk mengonfirmasi total yang dilokalkan dan label tindakan, dan tangkapan layar terfokus untuk menunjukkan bahwa string tidak terpotong atau tumpang tindih. Jalankan setiap lokal dengan data pengujian terkontrol. Perbandingan piksel layar penuh saja akan terlalu sensitif terhadap panjang string yang diterjemahkan, sedangkan OCR saja akan melewatkan kerusakan tata letak.
Memeriksa ikon toolbar yang didesain ulang
Gunakan templat untuk ikon yang diterima di wilayah toolbar kecil. Simpan templat terpisah jika tema terang dan gelap didukung. Bila pertandingan gagal, lampirkan crop toolbar dan skor kandidat terbaik. Jika ikon sengaja didesain ulang, tinjau dan ganti templatnya daripada menurunkan ambang batas hingga bentuk apa pun lolos.
Tes asap telepon nyata setelah penerapan
Mulai dari status akun dan aplikasi yang diketahui, tunggu layar landing, tegaskan identitasnya, lakukan satu tindakan yang diizinkan, dan verifikasi status bernama berikutnya. Tangkap tangkapan layar pada setiap kegagalan. Kepadatan perangkat, dialog izin, keyboard, notifikasi, dan pembaruan sistem adalah bagian dari lingkungan ponsel sebenarnya, sehingga pengujian harus melaporkannya, bukan menyembunyikannya.
Kegagalan palsu yang umum dan cara mencegahnya
| Gejala | Kemungkinan penyebabnya | Respon yang lebih baik |
|---|---|---|
| Perbedaan tangkapan layar berubah setiap kali dijalankan | Jam, animasi, iklan, data unggulan, keyboard, bilah sistem, atau konten jaringan | Bekukan masukan, tunggu stabilitas, potong atau tutupi hanya wilayah dinamis |
| OCR mengembalikan teks yang masuk akal tetapi salah | Bahasa salah, kontras rendah, potongan kecil, rotasi, noise, atau segmentasi tidak sesuai | Simpan hasil panen, tingkatkan skala dan kontras, pilih bahasa dan segmentasi dengan sengaja |
| Pencocokan template hanya berfungsi pada satu ponsel | Kepadatan, tema, skala, rasio aspek, atau kompresi berbeda | Gunakan wilayah minat dan templat tervalidasi untuk varian visual yang didukung |
| Gambar yang tepat ditemukan tetapi ketukannya gagal | Koordinat kecocokan tidak diubah ke layar saat ini atau input blok overlay | Pisahkan pengakuan dari tindakan dan verifikasi keadaan berikutnya |
| Tes berlanjut di layar yang salah | Tidak ada postcondition atau tepi kegagalan | Sebutkan status yang diharapkan dan berhenti ketika layar saat ini berada di luar jalur yang ditinjau |
| Detektor objek menemukan kelas yang salah | Model atau label tidak sesuai dengan domain aplikasi, ambang batas tidak divalidasi | Gunakan model yang kompatibel, catat versi dan skor, uji sampel negatif |
Diskusi komunitas tentang pengujian regresi Android sering kali menimbulkan biaya pemeliharaan yang sama: matriks perangkat, pengaturan waktu yang tidak stabil, tinjauan dasar, dan layar yang kontennya berubah. Itu bukanlah alasan untuk mengabaikan pengujian visual. Ini adalah alasan untuk membuat lingkungan pengujian, varian yang diterima, dan artefak kegagalan menjadi eksplisit.
Bagaimana LaiCai Flow cocok dengan pengujian visual
LaiCai Flowadalah fitur otomatisasi di dalam LaiCai Screen Mirroring. Alur dapat menggabungkan tangkapan layar, pemeriksaan UI, OCR, pencocokan templat, deteksi objek, kondisi, tindakan, dan transisi keberhasilan atau kegagalan yang eksplisit. Hal ini memungkinkan penguji memodelkan layar sebagai keadaan alih-alih memperlakukan pengenalan sebagai trik tersendiri.
DenganLaiCai Flow Inside, Profil yang kompatibel dapat dijalankan melalui LaiCai Android Agent di ponsel setelah penerapan. Kompatibilitas tetap bergantung pada setiap node dan aset yang digunakan oleh Profil tersebut. OCR lokal menggunakan Tesseract; pencocokan template menggunakan aset gambar yang dipilih dan skor yang dapat dikonfigurasi; deteksi lokal yang kompatibel menggunakan model yang didukung. Node jaringan atau model jarak jauh masih memerlukan ketergantungan jaringannya sendiri.
Hal ini tidak membuat setiap tes visual dapat diandalkan secara otomatis. Tim masih memerlukan data dasar, templat, wilayah OCR, model, ambang batas, kasus negatif, dan kondisi pasca yang representatif. Manfaatnya adalah keputusan dan transisi tersebut dapat ditinjau dalam satu alur kerja. Panduan otomatisasi AndroidAImemberikan pandangan yang lebih luas tentang pembuatan dan eksekusi perangkat nyata.
Kumpulan bukti minimum untuk tes visual yang gagal
- Nama pengujian, pembuatan aplikasi, model perangkat, versi Android, lokal, tema, dan orientasi.
- Tangkapan layar sumber atau wilayah yang dipotong yang digunakan oleh pernyataan tersebut.
- Properti garis dasar, templat, teks, kelas, atau UI yang diharapkan.
- Perbedaan yang diamati, hasil OCR, kotak pembatas, skor pertandingan, atau nilai UI.
- Keadaan yang disebutkan sebelumnya, upaya tindakan, keadaan berikutnya yang diharapkan, dan alasan penghentian.
- Versi aset, model, atau dasar sehingga peninjau dapat mereproduksi keputusan tersebut.
Label lulus/gagal tanpa konteks ini memaksa orang berikutnya untuk mereproduksi keseluruhan proses. Kumpulan bukti yang ringkas mengubah kegagalan menjadi keputusan yang dapat ditinjau: memperbaiki produk, menstabilkan pengujian, memperbarui aset visual yang disetujui, atau menolak konfigurasi perangkat yang tidak didukung.
FAQ pengujian visual Android
Haruskah setiap pengujian UI Android menyertakan tangkapan layar?
Tidak. Gunakan tangkapan layar ketika penampilan penting atau ketika artefak kegagalan akan membantu pengulas. Pernyataan semantik biasanya lebih baik untuk perilaku yang dapat diandalkan oleh pohon UI.
Apakah OCR lebih baik daripada pencocokan gambar?
OCR menjawab pertanyaan tentang teks yang terlihat. Pencocokan gambar menjawab pertanyaan tentang pola visual yang diketahui. Jika persyaratan mencakup label dan tampilannya, gunakan OCR plus tangkapan layar terfokus atau pemeriksaan templat.
Bisakah tes tangkapan layar dijalankan di ponsel Android asli?
Ya, tetapi perangkat sebenarnya memperkenalkan lebih banyak variasi dibandingkan perender atau emulator sisi host yang dikontrol. Catat konfigurasi perangkat, stabilkan UI sistem dan data, serta tetapkan ekspektasi untuk matriks perangkat yang benar-benar Anda dukung.
Kapan saya harus menggunakan deteksi objek?
Gunakan ketika kelas objek yang bermakna bergerak atau menskalakan melampaui toleransi templat stabil, dan hanya ketika model yang kompatibel telah divalidasi pada gambar nyata aplikasi. Jangan menambahkan detektor hanya karena terdengar lebih canggih.
Pilih bukti sebelum memilih teknologi
Pengujian visual Android yang andal dimulai dengan satu kalimat: apa yang harus dapat dibuktikan oleh pengulas? Pilih status UI untuk semantik, tangkapan layar untuk komposisi, OCR untuk teks, pencocokan templat untuk target visual yang diketahui, dan deteksi objek untuk kelas yang divalidasi dengan geometri variabel.
Kemudian jadikan observasi sebagai bagian dari transisi keadaan: stabilkan, tangkap, tegaskan, bertindak hanya setelah sukses, verifikasi kondisi pasca, dan pertahankan bukti kegagalan. Desain tersebut lebih mudah dipahami dibandingkan kumpulan panggilan visi yang terputus—dan jauh lebih mudah dipertahankan saat aplikasi atau perangkat berubah.