Mengapa Selenium dan Timun Tidak Boleh Digunakan Bersama

Dalam catatan ini, saya akan menerangkan mengapa saya percaya adalah idea yang tidak baik untuk menulis ujian automatik UI dengan Selenium dan Timun.

Tajuk catatan menyebut Selenium dan Timun kerana mereka adalah alat automasi penyemak imbas dan alat BDD yang paling popular, bagaimanapun, konteks artikel ini berlaku untuk alat automasi UI yang digabungkan dengan alat BDD apa pun.

Sebelum saya menggali lebih mendalam, mari kita tinjau beberapa maklumat latar belakang.

Apa itu Selenium?

Selenium adalah alat pengujian automasi penyemak imbas yang mampu berinteraksi dengan elemen HTML aplikasi web untuk mensimulasikan aktiviti pengguna.

Di Selenium WebDriver, kita dapat menulis skrip dalam sejumlah bahasa pengaturcaraan dan dapat menjadi aset yang bagus untuk pelbagai OS dan ujian lintas-penyemak imbas.

Apa itu Timun?

Timun diciptakan untuk mendorong proses Behavior Driven Development (BDD), sehingga pelanggan dapat menggambarkan keperluan mereka sebagai rangkaian contoh yang disebut senario, dalam fail teks biasa menggunakan bahasa Gherkin dalam format Diberikan Ketika Kemudian.

Di dunia timun, fail-fail ini disebut fail fitur yang ditinjau oleh pasukan Scrum untuk mendapatkan pemahaman yang jelas mengenai keperluan sebelum memulakan pengembangan sebenarnya.

Setelah pembangunan sedang dijalankan, pembangun dan / atau QA akan menulis Definisi Langkah yang pada dasarnya adalah potongan kod yang mengikat senario dari fail ciri ke kod ujian yang melakukan tindakan terhadap aplikasi yang sedang diuji.

Selenium dan Timun

Selenium dan Timun adalah alat yang hebat untuk tujuan mereka sendiri tetapi apabila digunakan bersama, perkara-perkara tidak akan berkahwin dengan baik! Mari lihat mengapa.

Cerita umumnya ditulis dari perspektif pengguna, contohnya:

Ciri: Fungsi log masuk

Sebagai pengguna laman web abc.com

Saya mahu pelanggan dapat log masuk ke laman web ini

Supaya mereka dapat melihat maklumat akaun mereka.

Pada gilirannya, Senario dalam fail ciri ditulis dengan cara yang menggambarkan tingkah laku ciri ketika pengguna berinteraksi dengan permohonan . Sebagai contoh:

Senario 1: Log masuk yang sah

Diberikan saya berada di laman log masuk abc.com

Apabila saya memasukkan kelayakan yang sah

Kemudian saya diarahkan ke halaman Akaun Saya

Oleh itu, anda boleh menambahkan lebih banyak senario untuk menguji pelbagai kombinasi data.

Oleh kerana kedua-dua cerita dan fail ciri ditulis dari sudut pandang peringkat tinggi, dan kerana kami ingin mengotomatisasi senario, wajar untuk mula menulis definisi langkah dalam Timun yang memanggil Selenium untuk mendorong aplikasi, lakukan tindakan dan mengesahkan hasilnya.

Tetapi, di sinilah masalahnya berlaku; apabila kita mula menggabungkan Selenium dengan Timun untuk menulis ujian UI automatik.

Secara jujur, dalam kes sederhana seperti senario Login di atas, semuanya sesuai dengan baik dan pendekatannya nampak masuk akal, dan sebenarnya, kebanyakan contoh yang anda lihat di internet, yang menunjukkan penggunaan Selenium dan Timun, seolah-olah membatasi diri mereka ke contoh Login yang terkenal.

Pembaca blog seperti itu akan menganggap bahawa mereka dapat menggunakan senario Login sederhana dan menerapkan prinsip yang sama pada konteks aplikasi yang lebih luas.

Jangan tertipu, kerana selenium dan Timun menjadi sangat masam apabila digunakan pada aplikasi berasaskan web besar di dunia.

Mari kita ambil contoh halaman hasil carian aplikasi e-dagang khas yang menjual produk dalam talian. Biasanya halaman hasil carian penuh dengan fitur, seperti penapis, jenis, senarai produk, kemampuan untuk menukar carian, kemampuan untuk membuat halaman atau memuat secara automatik semasa menatal, dan lain-lain, seperti yang dapat dilihat pada tangkapan skrin di bawah:

Saya akan menganggap bahawa setiap ciri di halaman hasil carian, ditambahkan ke situs secara bertahap menggunakan pengembangan lincah.

Menerapkan prinsip yang sama dari contoh Login mudah kami, kerana setiap ciri dikembangkan, kami akan mempunyai fail ciri masing-masing yang dipenuhi dengan banyak senario yang berbeza. Sebagai contoh:

Dalam iterasi 1 pengembangan, 'Filter berdasarkan Harga' dikembangkan, jadi kami akan mempunyai fail fitur untuknya dengan senario tersendiri yang berkaitan dengan filter harga.

Dalam iterasi 2 pengembangan, 'Filter by Star Rating' dikembangkan, jadi kami akan mempunyai fail fitur untuknya dengan senario tersendiri yang berkaitan dengan filter rating bintang, dan seterusnya untuk setiap fitur baru.

Penting untuk diperhatikan bahawa senario dalam setiap fail ciri hanya khusus untuk ciri masing-masing. Sebenarnya, inilah sebabnya mengapa mereka dipanggil fail ciri kerana fokusnya adalah ciri individu .

Seperti disebutkan sebelumnya, ketika aplikasinya sederhana, kita dapat bertahan dari tantangan mengotomatisasi senario di UI dengan Selenium dan Timun. Namun, seiring dengan bertambahnya aplikasi dan fitur baru ditambahkan, kerumitan muncul karena mungkin ada ketergantungan antara fitur yang berlainan.

Sebagai contoh, saya dapat menapis hasil carian saya terlebih dahulu mengikut harga kemudian menggunakan penapis lain untuk penilaian bintang. Ah ... kita sekarang mempunyai masalah!

Fail ciri manakah yang harus diambil senario ini sekarang? Dalam fail 'Tapis mengikut Peringkat Bintang' atau fail 'Tapis mengikut Harga'? Bagaimana jika saya sekarang menambah senario untuk menerapkan semacam pada hasil yang disaring untuk disusun berdasarkan undian tertinggi?

Sekiranya pihak berkepentingan ingin melihat liputan ujian kami, fail ciri mana yang harus dia perhatikan? Adakah dia akan mendapat gambaran penuh mengenai senario dengan membaca salah satu fail ciri atau adakah dia perlu membaca semua fail ciri?

Pada saat pengembangan, ketika setiap fitur dikembangkan satu per satu dalam setiap iterasi, file fitur akan difokuskan pada fitur itu sendiri, jadi pada suatu ketika, ketika kita mempunyai banyak fitur, kita harus mulai memikirkan untuk menguji ini, bukan hanya dalam keadaan terasing tetapi juga senario kreatif di mana kami menggabungkan pelbagai ciri.

Dan sebenarnya, inilah yang akan dilakukan oleh pengguna sebenar aplikasi. Mereka pertama kali memasukkan kriteria carian mereka, sekali di halaman hasil carian, mereka mungkin akan membuat halaman, kemudian menapis, kemudian menyusun, kemudian kembali, dan seterusnya, dan mereka dapat melakukan tindakan ini dalam urutan apa pun. Tidak akan ada urutan acara yang ditentukan. Ini adalah satu perjalanan pengguna sebenar dan ujian sebenar sistem!

Sebilangan besar pepijat dalam aplikasi terdedah ketika salah satu ciri itu sendiri atau ketika dua ciri yang berfungsi dengan baik secara terpisah, tidak berfungsi bersama. Inilah yang berdasarkan kepada Model Pairwise Testing.

Jadi, apa masalahnya menggunakan Selenium dan Timun bersama-sama?

Sekiranya mungkin, kita tidak boleh menggunakan GUI web untuk pengesahan berfungsi. Fungsi fungsi harus diuji pada lapisan API dengan ujian integrasi.

UI hanya boleh dikhaskan untuk memeriksa aliran pengguna melalui aplikasi, atau ujian ujung ke ujung dan memastikan modul atau widget jangkaan yang relevan ada di halaman ketika pengguna menavigasi dari satu halaman ke halaman lain.

Perjalanan pengguna biasa memerlukan:

1 - Navigasi ke laman utama laman web abc.com

2 - Cari produk dari laman utama

3 - Lihat senarai hasil carian

4 - Sapukan penapis dan / atau urutkan

5 - Baca perincian produk

6 - Tambahkan produk ke bakul

7 - Terus lihat…

Selenium sangat baik dalam mengautomasikan senario ini dan memeriksa pelbagai elemen di setiap halaman dan seperti yang saya nyatakan di atas, itulah yang harus kita fokuskan ketika menguji pada lapisan UI, dan menguji peralihan keadaan yang berbeza.

Seperti yang dapat dilihat, setiap perjalanan pengguna melalui aplikasi menyentuh pada banyak halaman dan berpotensi berinteraksi dengan beberapa fitur di setiap halaman, dan kami akan mengesahkan pelbagai perkara pada setiap langkah sepanjang perjalanan, jadi menggunakan fail ciri untuk mendokumentasikan senario ini sama sekali tidak masuk akal, kerana kami tidak menguji ciri, kami menguji sistem bersepadu.

Segala-galanya benar-benar berbentuk pir ketika kita berusaha menulis senario hujung-ke-hujung dalam format Diberi-Bila-Kemudian. Berapa banyak Givens yang akan kita ada? Berapa banyak yang akan kita ada?

Seseorang boleh berpendapat bahawa untuk ujian end-to-end kita hanya boleh menggunakan Selenium sendiri tanpa Timun dan mempunyai ujian automatik yang terpisah untuk setiap ciri menggunakan Selenium dan Timun. Sekali lagi, saya tidak mengesyorkan pendekatan ini kerana anda mungkin akan mempunyai ujian pendua dan kami tahu bagaimana ujian UI yang perlahan dan rapuh, jadi kami harus berhasrat untuk tidak mengurangkannya! Selain itu, anda masih perlu menghadapi ujian kebergantungan ciri.

Ringkasan

Timun adalah alat yang hebat untuk memeriksa tingkah laku ciri di lapisan API dengan ujian integrasi di mana setiap ciri dapat diuji secara menyeluruh. Alat ini harus digunakan untuk Uji Cerita.

Selenium adalah alat yang hebat untuk mengautomasikan senario pengguna di lapisan UI dan memeriksa tingkah laku sistem secara keseluruhan, merangkumi banyak kisah pengguna.

Apabila kita sampai ke Uji Integrasi Sistem atau UI Uji, lebih baik menggunakan Selenium tanpa kerangka Cucumber yang mendasarinya kerana berusaha menulis fail fitur Timun untuk perjalanan pengguna, dapat menjadi sangat membebankan dan tidak dapat memenuhi tujuan alat ini dibuat.

Artikel saya berdasarkan kesimpulan fakta!

• Sekiranya ada nilai dalam menggunakan timun, itu berada pada tahap ciri.
• Memeriksa fungsi sesuatu yang terbaik dilakukan di luar UI, mis. Ujian API.
• Walaupun pada ujian lapisan API, timun gagal dengan teruk.
• UI Uji harus merangkumi senario pengguna / perniagaan dan bukan satu ciri.

Timun berfungsi dengan indah dengan pandangan ujian dan senario yang sederhana dan naif, seperti fungsi log masuk kegemaran semua orang.

Memandangkan saya berada di halaman log masuk
Apabila saya memasukkan kelayakan yang sah
Maka saya mesti melihat akaun saya

Tetapi mana-mana penguji yang pandai mengetahui bahawa walaupun fungsi log masuk yang sederhana mempunyai banyak pemeriksaan. Cuba ubah cek tersebut dalam timun.

Ini hanya untuk log masuk; cubalah menulis ujian ujung ke hujung dalam timun!

Ujian UI harus merangkumi perjalanan pengguna yang biasanya dari hujung ke hujung dan menggunakan pelbagai ciri aplikasi.

Terdapat banyak perkara yang berlaku dalam satu perjalanan pengguna di seluruh aplikasi.

Timun pastinya BUKAN alat yang tepat untuk ujian senario pengguna / perniagaan.