Get best of the week

Mengapa kami beralih ke Selenide dengan menulis lebih dari 200 autotest baru di sepanjang jalan

Hai, saya adalah alat otomatisasi pengujian untuk salah satu proyek perusahaan besar. Pada artikel ini, saya akan menjelaskan mengapa kami memutuskan untuk beralih dari Serenity ke Selenide. Tugas kami berskala besar, dan meskipun mengubah tumpukan teknologi membutuhkan waktu, kemudian lebih dari terbayar dengan mempercepat penulisan tes dan melakukan regresi.

gambar

Sebelum kita sampai pada intinya, sedikit tentang tugas secara keseluruhan.

Sayangnya, saya tidak dapat mengungkapkan rincian proyek berdasarkan ketentuan NDA. Bahkan, ini adalah beberapa alat untuk call center dari satu perusahaan besar - panggilan routing, pemisahan operator berdasarkan topik panggilan, dll. dalam antarmuka pengguna yang indah. Antarmuka, by the way, disediakan tidak hanya untuk operator, tetapi juga untuk pengendali mendengarkan dan mengevaluasi panggilan yang dipilih. Di atas semua ini, ada sistem diferensiasi hak dan panel admin yang memungkinkan Anda untuk mengkonfigurasi semua fungsi bawaan - dari telepon ke peringkat yang tersedia untuk pengontrol.

Seluruh volume fungsionalitas dibagi menjadi beberapa proyek: telepon, panel pengguna dan panel admin. Ketiga proyek sedang dalam pengembangan aktif. Dan tugas saya adalah mengotomatiskan pengujian pada proyek-proyek ini dalam arti luas.

Untuk beberapa fungsi yang dikembangkan, tes otomatis sudah ada, tetapi spesialis yang mengembangkannya meninggalkan perusahaan, sehingga muncul tugas teknis tertentu untuk mengotomatisasi pengujian. Secara total, sekitar 50 autotest ditulis, tetapi sebagian besar dari mereka benar-benar ketinggalan zaman, karena fungsi telah jauh ke depan. Karena itu, tugas awalnya adalah memperbarui semua ini.

Tumpuk pembaruan


Autotest yang ada ditulis menggunakan perpustakaan Serenity. Bahkan, mereka harus ditulis ulang lagi, jadi tidak ada gunanya berpegang pada perkembangan yang ada. Perpustakaan itu sendiri sudah tidak asing lagi bagi saya, tetapi secara pribadi, saya tidak menganggapnya sebagai alat yang optimal. Jadi, memahami jumlah pekerjaan, saya memutuskan untuk beralih ke Selenide dari awal.

Selenide adalah alat yang cukup populer di mana ada banyak solusi siap pakai. Beberapa fitur Selenide juga tersedia untuk analog - Atlas, Selenium, HTMLElements, dll. Tetapi masing-masing dengan caranya sendiri tidak cocok untuk kita.

Selenium adalah dasar dari Selenide. Tapi untuk tujuan kita, levelnya terlalu rendah. Tidak masuk akal untuk menemukan kembali roda ketika ada solusi yang sudah jadi.

Atlas muncul baru-baru ini. Itu cukup mentah dan tidak memiliki dukungan Groovy.
HtmlElements baik untuk semua orang, tetapi sudah usang dan tidak didukung. Ada juga JDI, tetapi memiliki masalah multithreading.

Serenity, yang sebelumnya digunakan pada proyek itu, terlalu rumit. Segala sesuatu di dalamnya sangat saling berhubungan sehingga untuk menambah beberapa pengendali acara atau pencegat baru, kami harus menulis ulang selusin kelas (dan ini tidak mengarah pada kesuksesan setiap waktu). Plus, Surenity tidak dapat menghubungkan Allure, industri aktual dan standar perusahaan untuk menghasilkan laporan pengujian.

Di Selenide, dari sudut pandang otomatisasi, semuanya jauh lebih sederhana. Misalnya, tidak perlu menjelaskan langkah-langkah secara terpisah - lampirkan ke metode, dll. Karena memiliki dukungan Allure di luar kotak, semua tindakan yang terkait dengan bekerja dengan elemen web secara otomatis termasuk dalam laporan pengujian.

Tentu saja, Selenide memiliki dukungan untuk PageFactory, Obyek Halaman, dan PageElement. Ini membuat kode lebih mudah dibaca. Plus, ada harapan internal untuk saat ketika elemen muncul - tidak perlu secara eksplisit menyatakan bahwa Anda perlu menghentikan tes selama beberapa detik sebelum melanjutkan (batas waktu habis diatur di konfigurasi). Harapan eksplisit ada secara terpisah - Anda dapat secara eksplisit mendefinisikan ulang batas waktu untuk elemen yang diperlukan pada setiap langkah pengujian.

Dengan nyaman, Selenide memiliki seluruh rangkaian berbagai metode yang sudah jadi.

Karena saya sendirian di tim pada awal transisi dari Serenity ke Selenide, keuntungan tambahan adalah saya sudah memiliki pengalaman yang cukup dengan Selenide dan Groovy, jadi saya dapat dengan cepat mengimplementasikan solusi yang sudah jadi dan kemudian menghabiskan lebih sedikit upaya untuk mendukungnya.

Transisi itu hampir tidak menyakitkan. Kami telah mengimplementasikan Selenide bersama dengan Allure. Allure memungkinkan Anda membuat laporan yang mudah dibaca dan bahkan agak indah, yang dengan jelas menunjukkan langkah mana yang jatuh dan dengan kesalahan apa. Di luar kotak, Anda dapat melampirkan tangkapan layar halaman web ke laporan. Kami bahkan menambahkan video proses, kode sumber halaman, log browser dan driver web.

Migrasi tes yang ada membutuhkan upaya minimal. Apa yang dimiliki Serenity, apa yang dimiliki Selenide adalah PageObjects dengan anotasi @FindBy. Ketenangan dan Daya Tarik menggunakan anotasi Langkah yang sama. Saya harus memperbarui model, elemen bersarang di satu sama lain, urutan langkah-langkah tes memanggil. Beberapa tes benar-benar dihapus, beberapa ditulis ulang dari awal, dan di suatu tempat memperbarui lokasi saja sudah cukup. Bahkan, bergerak telah menjadi tugas sepele yang dihadapi sebagian besar automators UI saat merancang aplikasi web.

Pembaruan Tes


Setelah memperbarui tumpukan teknologi, mereka melakukan tes sendiri. By the way, bagian dari pekerjaan ini telah selesai sebagai bagian dari transisi ke tumpukan baru.

Mengingat akumulasi lag di balik fungsionalitas proyek, proyek tetap harus ditulis ulang - ini lebih menguntungkan dalam waktu daripada mencari inkonsistensi dalam volume kode yang sedemikian.

Secara total, sekitar 220 autotes telah ditulis pada saat ini untuk front-end dan back-end. Penekanan dalam pengembangan lebih lanjut akan berada di backend, karena sebagian besar elemen fungsional di ujung depan sudah terlibat dalam autotest. Pada saat yang sama, itu terus berubah, sehingga semakin banyak tes muncul di front-end, semakin banyak kekuatan yang harus dihabiskan untuk dukungan mereka.

Memiliki sumber daya waktu tak terbatas, kami selalu berusaha mengarahkan upaya apa yang akan memungkinkan kami untuk mengurangi biaya tenaga kerja untuk dukungan, mencakup fungsi sebanyak mungkin. Sekarang cakupan autotest sedikit melebihi 50%.


Tes yang ditulis ulang pada Selenide menjadi lebih ringkas dan akurat karena penggunaan kembali kode yang berulang - semua berkat kemampuan perpustakaan itu sendiri.

Memperbarui tes, kami memperhitungkan bahwa tes tersebut harus dijalankan secara bersamaan (dalam beberapa utas). Tes sebelumnya dijalankan pada mesin virtual yang terpisah. Tetapi transisi ke Selenide memungkinkan kami untuk membuat tugas lebih paralel, menjalankannya dalam beberapa utas.

Secara kasar, transisi ke kerangka kerja baru itu sendiri meningkatkan jumlah utas yang diluncurkan secara bersamaan dari 3 menjadi 8, dan optimalisasi pengujian berikutnya - hingga 50. Sebagai hasilnya, 100 tes UI berjalan hanya dalam 10 menit.


Multithreading, omong-omong, adalah keuntungan lain yang kami pilih Selenide. Ini bukan lapisan besar boilerplate, Anda menulis kode minimum. Tidak ada tulisan berlebihan yang dibutuhkan Selenium untuk mempersiapkan proyek untuk diluncurkan. Semua yang Anda butuhkan untuk menjalankan tes sudah keluar dari kotak.

Sejalan dengan memperbarui dan menulis tes baru, saya mengadakan pelatihan untuk orang-orang dari departemen pengujian, membantu mereka untuk beralih dari pengujian manual ke pengujian penuh, sehingga tiba di resimen otomasi pada proyek. Tumpukan teknologi yang digunakan memiliki ambang masuk yang lebih rendah, dan Internet penuh dengan dokumentasi dan video tentang cara mengatasi masalah tertentu. Sebulan kemudian, saya bergabung dengan beberapa penguji yang dapat melakukan tugas yang berkaitan dengan otomatisasi.

Sudah seluruh tim, kami dapat mengoptimalkan pengujian regresi. Jika sebelumnya regresi mengambil 7 hari dari tim, sekarang tugas yang sama dilakukan selama 4 hari, yaitu Kami mengurangi waktu tes hampir 2 kali.

Ada banyak skenario di depan yang belum diotomatisasi. Kami mengotomatiskan pengujian Asap hampir sepenuhnya, tetapi sekarang kami telah beralih ke skenario pengujian paling padat karya. Ini akan membantu mengurangi waktu bantuan.

Secara alami, kami akan mengembangkan infrastruktur pengujian. Berencana untuk memperkenalkan server Mock. Sekarang kami sedang menguji semuanya pada stand nyata, menghasilkan data uji. Butuh waktu dan sumber daya. Server tiruan akan memungkinkan Anda untuk menjalankan autotest tanpa persiapan awal ini (kami menulis tentang server tiruan untuk proyek lain ).

Kami juga berencana untuk mengimplementasikan catatan autotest sehingga Anda dapat menulis skrip TestRail berdasarkan benda kerja yang diperoleh dengan mengklik langsung pada antarmuka di peramban. Pada output, kami mendapatkan semacam prototipe autotest.

Penulis artikel: Yuri Kudryavtsev, Spesialis dalam pengujian perangkat lunak otomatis.

PS Kami menerbitkan artikel kami di beberapa situs Runet. Berlangganan ke halaman kami di VK , FB , Instagram atau saluran Telegram untuk mempelajari semua publikasi kami dan berita Maxilect lainnya.

More articles:


All Articles