Gunakan tangkapan skrin untuk penampilan keseluruhan skrin, OCR untuk teks yang boleh dilihat dan padanan imej untuk sasaran visual yang diketahui. Ujian visual Android yang paling kuat menggabungkan satu penegasan terfokus dengan masa yang stabil dan bukti kegagalan.
Jawapan ringkas: uji perkara yang mesti kekal benar
Gunakan ujian tangkapan skrin apabila keseluruhan skrin, komponen, jarak, warna atau tipografi mesti kekal konsisten secara visual. Gunakan OCR apabila keperluan adalah mengenai perkataan yang boleh dilihat oleh seseorang, terutamanya teks yang disetempatkan atau yang dihasilkan secara dinamik. Gunakan padanan imej apabila ikon, butang, lencana atau ilustrasi yang diketahui mesti muncul walaupun ia tidak mempunyai pengecam UI yang boleh dipercayai.
Mulakan dengan pemilih UI atau keadaan kebolehaksesan apabila keperluan adalah semantik: kawalan wujud, didayakan, dipilih atau mendedahkan label yang stabil. Tambah pengesanan objek hanya apabila sasaran tergolong dalam kelas visual dan mungkin menukar saiz atau kedudukan terlalu banyak untuk satu templat. Kaedah ini adalah berlapis, bukan rangka kerja ujian yang bersaing.
- Tanya apakah bukti yang akan meyakinkan penyemak bahawa keperluan itu diluluskan.
- Pilih isyarat boleh dipercayai yang paling sempit dan bukannya membandingkan setiap piksel secara lalai.
- Stabilkan skrin sebelum memerhatikannya, kemudian simpan artifak apabila penegasan gagal.
Kaedah ujian visual Android dibandingkan
| Kaedah | Terbaik untuk | Kelemahan utama | Bukti yang berguna |
|---|---|---|---|
| UI atau keadaan kebolehaksesan | Kawalan, label, keadaan didayakan, pemilihan, struktur navigasi | Elemen tersuai atau tidak boleh diakses mungkin tidak dapat dilihat oleh pepohon UI | Hierarki UI, sifat yang dipilih, tangkapan skrin |
| Tangkapan skrin atau imej emas | Susun atur, jarak, warna, tipografi, rupa komponen | Data dinamik, animasi, perbezaan peranti dan perubahan pemaparan boleh mencipta perbezaan yang bising | Imej semasa, garis dasar yang diluluskan, perbezaan visual |
| OCR | Teks boleh dilihat, penyetempatan, resit, mesej status, nilai yang diberikan sebagai piksel | Kualiti pengecaman bergantung pada pemangkasan, skala, kontras, data bahasa, putaran dan pembahagian | Pangkas sumber, teks yang diiktiraf, keyakinan atau senarai hasil |
| Padanan templat | Ikon, butang, lencana, lakaran kenit atau kawasan stabil kecil yang diketahui | Tema, skala, pemampatan dan reka bentuk semula boleh membatalkan templat | Templat, kawasan carian, padanan terbaik, skor, tangkapan skrin |
| Pengesanan objek | Objek visual yang kelasnya kekal bermakna manakala kedudukan atau saiznya berbeza-beza | Memerlukan model yang serasi, kelas berlabel, ambang dan pengesahan model | Versi model, kelas, kotak, skor, tangkapan skrin |
Panduan ujian tangkapan skrin rasmi Android menerangkan membandingkan pemaparan semasa dengan imej rujukan yang diluluskan. Pemalam imej Appium mendedahkan padanan ciri, padanan templat dan perbandingan persamaan. OpenCV mendokumenkan mekanisme menggelongsor templat ke atas imej, manakala Tesseract mendokumentasikan mengapa prapemprosesan OCR dan pembahagian halaman penting. Alatan berbeza, tetapi soalan reka bentuk ujian tetap sama: pemerhatian apakah yang membuktikan keperluan ini?
Pilih penegasan yang betul dengan empat soalan
1. Adakah keperluan semantik atau visual?
Jika ujian menyatakan "butang Hantar didayakan", periksa keadaan UI terlebih dahulu. Jika tertera "butang Hantar tidak dipotong selepas fon ditukar", gunakan tangkapan skrin atau pemeriksaan visual terfokus. Pertanyaan semantik biasanya lebih mudah untuk dikekalkan, tetapi ia tidak dapat membuktikan penampilan.
2. Adakah teks yang tepat penting?
Gunakan OCR apabila rentetan yang menghadap pengguna adalah keperluan dan teks tidak didedahkan dengan pasti melalui pepohon UI. Hadkan pengiktirafan kepada kawasan terkecil yang bermakna, pilih bahasa yang betul dan bandingkan hasil yang dinormalkan. Simpan tangkapan skrin kerana rentetan OCR yang betul sahaja tidak boleh menunjukkan pemangkasan, pertindihan atau kontras yang lemah.
3. Adakah terdapat satu sasaran visual yang stabil?
Gunakan padanan templat untuk ikon yang diketahui atau kawalan kecil. Pangkas templat dengan ketat, cari dalam kawasan yang diminati, dan tetapkan ambang daripada sampel positif dan negatif sebenar. Satu ambang universal jarang boleh dipertahankan merentas tema, resolusi dan strim jauh yang dimampatkan.
4. Mestikah keseluruhan komposisi kekal konsisten?
Gunakan perbandingan tangkapan skrin apabila perhubungan antara banyak elemen penting. Kawal fon, tempat, konfigurasi peranti, bar sistem, masa, data rangkaian, animasi dan kandungan berbiji. Jika input tersebut tidak boleh dikawal, tutup atau pangkas kawasan dinamik dan bukannya menerima ujian bising secara kekal.
Bina ujian visual yang gagal berguna
- Bawa apl ke keadaan permulaan yang dinamakan pada peranti atau emulator yang dibenarkan.
- Tunggu keadaan stabil, bukan hanya kelewatan tetap. UI Automator menyediakan kestabilan menunggu, dan isyarat sedia khusus apl adalah lebih baik.
- Tangkap kawasan sumber terkecil yang mengandungi bukti yang diperlukan.
- Jalankan satu penegasan utama: keadaan UI, OCR, templat, pengesanan atau perbandingan tangkapan skrin.
- Simpan imej sumber dan hasil berstruktur sebelum mengambil tindakan seterusnya.
- Apabila gagal, hentikan atau ikuti laluan pemulihan yang disemak. Jangan ketik rupa yang berdekatan hanya untuk memastikan ujian itu bergerak.
Pemeriksaan visual menjadi lebih selamat apabila ia membenarkan peralihan. Perhatikan keadaan semasa, buat penegasan, lakukan tindakan yang dibenarkan hanya selepas berjaya, dan sahkan postcondition. Ini adalah prinsip reka bentuk yang sama yang diterangkan dalam panduan klik automatik pengecaman imej: pengecaman bukan bukti bahawa aliran kerja selesai.
Untuk kerja peranti sebenar, pencerminan skrinAndroid untuk ujian aplikasi mudah alihmemberikan pengulas pandangan langsung semasa ujian sedang direka bentuk.Panduan ujian asap QA automasi Androidmenerangkan cara memastikan pemeriksaan berulang yang sempit dan boleh dihasilkan semula.
Tiga senario ujian visual Android praktikal
QA penyetempatan pada skrin pembayaran
Gunakan keadaan UI untuk menavigasi ke skrin daftar keluar, OCR untuk mengesahkan jumlah dan label tindakan setempat serta tangkapan skrin terfokus untuk menunjukkan bahawa rentetan tidak dipotong atau bertindih. Jalankan setiap tempat dengan data ujian terkawal. Perbandingan piksel skrin penuh sahaja akan menjadi terlalu sensitif kepada panjang rentetan yang diterjemahkan, manakala OCR sahaja akan terlepas kerosakan reka letak.
Menyemak ikon bar alat yang direka bentuk semula
Gunakan templat untuk ikon yang diterima dalam kawasan bar alat kecil. Simpan templat berasingan apabila tema terang dan gelap kedua-duanya disokong. Apabila perlawanan gagal, lampirkan pemangkasan bar alat dan markah calon terbaik. Jika ikon direka bentuk semula dengan sengaja, semak dan gantikan templat dan bukannya menurunkan ambang sehingga sebarang bentuk melepasi.
Ujian asap telefon sebenar selepas penggunaan
Mulakan daripada keadaan akaun dan apl yang diketahui, tunggu skrin pendaratan, tegaskan identitinya, lakukan satu tindakan yang dibenarkan dan sahkan keadaan dinamakan seterusnya. Tangkap tangkapan skrin pada setiap kegagalan. Ketumpatan peranti, dialog kebenaran, papan kekunci, pemberitahuan dan kemas kini sistem adalah sebahagian daripada persekitaran telefon sebenar, jadi ujian harus melaporkannya dan bukannya menyembunyikannya.
Kegagalan palsu biasa dan cara mencegahnya
| simptom | Kemungkinan punca | Sambutan yang lebih baik |
|---|---|---|
| Perbezaan tangkapan skrin berubah setiap larian | Jam, animasi, iklan, data berbiji, papan kekunci, bar sistem atau kandungan rangkaian | Pegunkan input, tunggu kestabilan, pangkas atau tutup kawasan dinamik sahaja |
| OCR mengembalikan teks yang munasabah tetapi salah | Bahasa yang salah, kontras rendah, pemangkasan kecil, putaran, hingar atau pembahagian yang tidak sesuai | Simpan tanaman, tingkatkan skala dan kontras, pilih bahasa dan pembahagian dengan sengaja |
| Padanan templat berfungsi pada satu telefon sahaja | Ketumpatan, tema, penskalaan, nisbah bidang atau pemampatan yang berbeza | Gunakan kawasan yang diminati dan templat yang disahkan untuk varian visual yang disokong |
| Imej yang betul ditemui tetapi paip gagal | Koordinat padanan tidak ditukar kepada skrin semasa atau input blok tindanan | Asingkan pengiktirafan daripada tindakan dan sahkan keadaan seterusnya |
| Ujian diteruskan pada skrin yang salah | Tiada postcondition atau kelebihan kegagalan | Namakan keadaan dijangka dan berhenti apabila skrin semasa berada di luar laluan yang disemak |
| Pengesan objek mendapati kelas yang salah | Model atau label tidak sesuai dengan domain apl, ambang tidak sah | Gunakan model yang serasi, rekod versi dan skor, uji sampel negatif |
Perbincangan komuniti tentang ujian regresi Android selalunya kembali kepada kos penyelenggaraan yang sama: matriks peranti, pemasaan yang tidak stabil, semakan garis dasar dan skrin yang kandungannya berubah. Itu bukan sebab untuk meninggalkan ujian visual. Ini adalah sebab untuk menjadikan persekitaran ujian, varians yang diterima dan artifak kegagalan jelas.
Cara LaiCai Flow sesuai dengan ujian visual
LaiCai Flowialah ciri automasi dalam LaiCai Screen Mirroring. Aliran boleh menggabungkan tangkapan tangkapan skrin, semakan UI, OCR, padanan templat, pengesanan objek, syarat, tindakan dan peralihan kejayaan atau kegagalan yang jelas. Ini membolehkan penguji memodelkan skrin sebagai keadaan dan bukannya menganggap pengecaman sebagai helah terpencil.
DenganLaiCai Flow Inside, Profil yang serasi boleh dijalankan melalui LaiCai Android Agent pada telefon selepas penggunaan. Keserasian masih bergantung pada setiap nod dan aset yang digunakan oleh Profil tersebut. OCR tempatan menggunakan Tesseract; pemadanan templat menggunakan aset imej yang dipilih dan skor boleh dikonfigurasikan; pengesanan tempatan yang serasi menggunakan model yang disokong. Nod rangkaian atau model jauh masih memerlukan pergantungan rangkaiannya sendiri.
Ini tidak menjadikan setiap ujian visual boleh dipercayai secara automatik. Pasukan masih memerlukan garis dasar perwakilan, templat, wilayah OCR, model, ambang, kes negatif dan pascasyarat. Nilainya ialah keputusan dan peralihan tersebut boleh disemak dalam satu aliran kerja. Panduan automasi AndroidAImenyediakan pandangan yang lebih luas tentang pengarangan dan pelaksanaan peranti sebenar.
Bundle bukti minimum untuk ujian visual yang gagal
- Nama ujian, binaan apl, model peranti, versi Android, tempat, tema dan orientasi.
- Tangkapan skrin sumber atau kawasan pangkas yang digunakan oleh penegasan.
- Garis dasar, templat, teks, kelas atau sifat UI yang dijangkakan.
- Perbezaan yang diperhatikan, hasil OCR, kotak sempadan, skor padanan atau nilai UI.
- Keadaan yang dinamakan sebelumnya, percubaan tindakan, dijangka keadaan seterusnya, dan sebab berhenti.
- Aset, model atau versi asas supaya penyemak boleh menghasilkan semula keputusan itu.
Label lulus/gagal tanpa konteks ini memaksa orang seterusnya untuk menghasilkan semula keseluruhan larian. Himpunan bukti padat mengubah kegagalan menjadi keputusan yang boleh disemak: betulkan produk, stabilkan ujian, kemas kini aset visual yang diluluskan atau tolak konfigurasi peranti yang tidak disokong.
Soalan Lazim ujian visual Android
Patutkah setiap ujian UI Android menyertakan tangkapan skrin?
Tidak. Gunakan tangkapan skrin apabila penampilan penting atau apabila artifak kegagalan akan membantu penyemak. Penegasan semantik biasanya lebih baik untuk tingkah laku yang didedahkan dengan pasti oleh pokok UI.
Adakah OCR lebih baik daripada padanan imej?
OCR menjawab soalan tentang teks yang boleh dilihat. Padanan imej menjawab soalan tentang corak visual yang diketahui. Jika keperluan termasuk kedua-dua label dan penampilannya, gunakan OCR ditambah tangkapan skrin terfokus atau semakan templat.
Bolehkah ujian tangkapan skrin dijalankan pada telefon Android sebenar?
Ya, tetapi peranti sebenar memperkenalkan lebih banyak variasi daripada pemapar bahagian hos terkawal atau emulator. Rakam konfigurasi peranti, stabilkan UI dan data sistem serta tetapkan jangkaan untuk matriks peranti yang sebenarnya anda sokong.
Bilakah saya harus menggunakan pengesanan objek?
Gunakannya apabila kelas objek yang bermakna bergerak atau berskala melebihi toleransi templat yang stabil dan hanya apabila model yang serasi telah disahkan pada imej sebenar apl. Jangan tambah pengesan hanya kerana bunyinya lebih maju.
Pilih bukti sebelum memilih teknologi
Ujian visual Android yang boleh dipercayai bermula dengan satu ayat: apakah yang mesti dapat dibuktikan oleh pengulas? Pilih keadaan UI untuk semantik, tangkapan skrin untuk komposisi, OCR untuk teks, padanan templat untuk sasaran visual yang diketahui dan pengesanan objek untuk kelas yang disahkan dengan geometri berubah-ubah.
Kemudian jadikan pemerhatian sebagai sebahagian daripada peralihan keadaan: stabilkan, tangkap, tegas, bertindak hanya selepas berjaya, sahkan pascasyarat dan simpan bukti kegagalan. Reka bentuk itu lebih mudah difahami daripada koleksi panggilan penglihatan yang terputus—dan lebih mudah diselenggara apabila apl atau peranti berubah.