Tata letak tes? Mudah

Artikel ini disiapkan oleh Anna anna-che dan Ksenia KseMish .

Salah satu alasan mengapa kami secara aktif melakukan pengujian tata letak adalah, seperti biasa, menyapu. Kami menginjak bug yang mulai muncul setelah pembaruan Chrome berikutnya. Ternyata dalam 3 jam, pengguna tidak dapat mentransfer dana dari akun melalui akun pribadi bank Internet kami. Dan semua karena fakta bahwa dalam versi baru browser bentuk mentransfer dana dari satu akun ke yang lain telah meninggalkan jendela.

Bug serupa tidak berbahaya. Misalnya, merek pakaian terkenal juga menemukan menyapu ini. Karena pengujian tata letak yang tidak memadai, pengguna situs merek ini alih-alih tombol "Pelajari lebih lanjut" telah lama melihat "Pelajari rasa sakitnya ..."


Tulisan pada tombol, tentu saja, dekat dengan kebenaran, harga di sana benar-benar menyakitkan, tetapi ini jelas bukan apa yang dimaksudkan oleh pembuat situs. Secara umum, momen seperti itu harus dipantau dan diperbaiki, terlepas dari apa yang menyebabkannya - ketidaknyamanan atau senyum.

Menyadari masalah ini, kami menerapkan praktik tinjauan desain wajib oleh desainer produk kami, tetapi tidak ada di sana. Ternyata tidak semua tim memiliki perancang yang berdedikasi, atau mereka tidak memiliki cukup waktu, atau, lebih buruk lagi, bagian depan dan perancang tidak dapat mencapai pendekatan umum pada tata letak halaman, formulir, atau elemen.

Tanpa berpikir dua kali, kami berangkat untuk mencari opsi bagaimana kami dapat meminimalkan jumlah cacat tata letak dan kebuntuan Desainer VS Depan. Setelah mempelajari kemungkinan praktik dan alat untuk mengotomatisasi tata letak pengujian dan mengumpulkan kerucut, kami menerapkan pendekatan berikut.

Secara singkat tentang kami:
Sekarang kami sedang mengembangkan satu produk, di mana lebih dari 20 tim scrum bekerja, yang masing-masing bertanggung jawab atas fungsionalitas tertentu, sementara kami mencoba mempertahankan satu gaya dan desain produk itu sendiri - presentasi visual, tata letak elemen-elemen utama, dll.

Mengenai distribusi pengguna oleh browser, hari ini pengguna kami menggunakan (nilai dibulatkan):

• 60% Chrome
• 30% - Firefox,
• 10% - browser lain.

Kami menguji fungsionalitas dengan bantuan kerangka kerja BD-Akita kami (Java + Mentimun + Selenide), kami menulisnya di sini .

Untuk mulai dengan, kami ingin menyelesaikan masalah dengan perjanjian antara bagian depan dan desainer. Pada tahap awal pembuatan maket fungsionalitas, bagian depan dan perancang secara bersama-sama menggambarkan "Kontrak". Dalam kontrak ini, mereka menggambarkan semua pengaturan untuk pengaturan elemen, gaya mereka, jarak, dll. Karena itu, ketika mendeteksi ketidakcocokan tata letak dengan tata letak halaman, orang-orang tidak perlu mencari tahu untuk waktu yang lama siapa yang benar dan siapa yang harus disalahkan.

Mereka menggambarkan pengaturan mereka dalam file galen-spec.

Apa itu galen-spec?

Untuk mengotomatiskan pengujian tata letak dan dengan demikian meminimalkan jumlah cacat, kami memutuskan untuk mengimplementasikan alat Galen Framework. Ini didasarkan hanya pada file .spec (spesifikasi atau, seperti yang kita sebut, "Kontrak"). Dan itu mudah diintegrasikan dengan tes Selenium.

Setelah perancang dan bagian depan menyusun "Kontrak", tester membentuk file .spec berdasarkan padanya, sesuai dengan persyaratan Galen. Kerangka kerja menggunakan bahasanya sendiri untuk menulis spesifikasi verifikasi.

Terdiri dari apa file .spec?

Secara logis, ini dapat dibagi menjadi dua bagian:

1. definisi objek

Di sini kita perlu menentukan objek apa yang ada di halaman kita - header, footer, menu, konten, dll. Secara umum, kami mencantumkan elemen utama yang akan kami periksa, beri mereka nama dan tentukan locator.


@objects - elemen pada halaman (Anda dapat menggunakan CSS, XPATH, ID)

2. Ketika pencari lokasi ditentukan, gaya dan spesifikasi objek tertentu harus ditentukan. Untuk melakukan ini, kami menggunakan bagian dari spesifikasi objek spesifikasi , di mana kami menjelaskan secara rinci, misalnya, bahwa blok teks kami (deskripsi-teks) terletak di dalam formulir deskripsi, di bawah header dan berisi teks tertentu.


Bagian utama - untuk setiap elemen yang dijelaskan, @objects menjelaskan parameter verifikasi.

* Bahasa spec galen sensitif terhadap lekukan di bagian utama, jadi perhatikan ini dan perhatikan tabnya :)

Dengan demikian, "Kontrak", yang disimpulkan antara bagian depan dan perancang serta ditransfer ke bahasa Galen, memungkinkan kita untuk secara otomatis memeriksa lokasi dan konten internal elemen, serta kemampuan beradaptasi dan kompatibilitas lintas-browser.

Contoh Mulai Cepat

1. Kami menjelaskan elemen-elemen dari halaman tertentu dan memeriksa dalam file .spec menggunakan bahasa Spec Galen, dan memasukkan spesifikasi dalam paket.
2. Kami menambahkan tangkapan layar referensi ke paket spesifikasi / gambar
3. Kami sedang mengerjakan BDD, jadi skrip di file .feature akan terlihat seperti ini:
   
   
   
4. Jalankan skrip uji melalui Cucumber Runner yang biasa.

Dalam skenario ini, kami memeriksa beranda GitHub. Pada langkah terakhir kami menambahkan verifikasi tata letak. Tes serupa dapat melengkapi tes fungsional yang ada, atau menjalankannya secara terpisah. Jika ada ketidakcocokan ditemukan dalam tata letak, maka kita akan memiliki gambar dengan hasil yang diharapkan dan dengan hasilnya, ditambah perbedaannya. Semua ini terlampir pada laporan cuckumber.

Perbedaan dalam laporan adalah sebagai berikut:


error = Kesalahan {[Elemen tidak terlihat seperti "./akita-testing-template/src/test/resources/specs/images/registration-form.png". Ada 10,47% piksel yang tidak cocok tetapi maks yang diizinkan adalah 10%]

Di sini kita melihat bahwa cek gagal, gambar berbeda lebih dari 10% dan semua perbedaan warna ini, kecuali untuk isian hitam, ini adalah perbedaan antar elemen.

Jika elemen-elemennya benar-benar identik, perbedaannya akan ditampilkan dalam warna hitam.

Pertanyaan paling umum adalah, di mana saya bisa mendapatkan tangkapan layar referensi?

Jawab: Kami mengambil standar baik dari perancang, atau dengan menjalankan tes pada lingkungan prodov, yang kami anggap sebagai standar. Kami mendapatkan gambar dari blok kami dari sana, yang akan kami bandingkan, dan menempatkannya di folder gambar, dari mana spesifikasi akan menarik tautan ke sana.

Apa yang telah kita lakukan untuk menggunakan pendekatan ini

• berhasil mengurangi jumlah tes asap dan waktu mereka sekitar 20% karena fakta bahwa verifikasi beberapa bentuk dan elemen serupa runtuh menjadi satu tes, yang memeriksa komponen visual mereka dan segera mengungkapkan perbedaan
• Sekarang kita dapat yakin bahwa aplikasi kita ditampilkan dengan benar di browser yang dipilih
• tahu bahwa kemampuan beradaptasi baik-baik saja dan tidak terpisah
• datang ke ulasan desain otomatis.

Anda dapat membaca dokumentasi tentang kompilasi file-file galen-spec di sini - panduan-galen-spec-bahasa .

Kami berbicara tentang aspek teknis bekerja dengan Galen Framework, kemampuannya dan pemeriksaan dasar di Selenium Camp terakhir, dan kami akan menulis di blog.

Kemampuan untuk menggunakan galen-spec dan langkah-langkah baru untuk memverifikasi tata letak yang kami ambil ke perpustakaan Akita kami , di mana ada templat untuk memulai lebih cepat , dan kami juga melakukan obrolan telegram di mana Anda dapat mengajukan pertanyaan yang menarik bagi Anda.

Dan kami akan menjawab.