Saya bekerja pada tim yang mengembangkan situs web dengan banyak halaman. Orang QA di tim saat ini menjalankan semua tes secara manual. Saya berpikir untuk membuatnya membuat banyak skrip Selenium. Saya tidak berpikir dia bisa mengotomatiskan semua tes, tetapi dia bisa mengotomatisasi banyak dari mereka.
Karena dia tidak memiliki latar belakang pemrograman, seberapa sulit baginya untuk membuat dan mengelola batch skrip Selenium? Masalah apa yang perlu dia bantu?
Jawaban:
Saya pikir Selenium sebagai alat "record and replay" yang berdiri sendiri sangat ideal untuk pengguna non-teknis. Ungkapan merekam jalan saya dan kemudian memutar ulang itu intuitif, dan antarmuka, sementara jelas diarahkan pada non-newb, tidak terlalu mengintimidasi.
Selenium 2 / Selenium RC jelas merupakan urutan kompleksitas yang lebih tinggi, dan saya tidak berpikir Anda dapat meminta non-programmer untuk berinteraksi dengan itu. (Sebenarnya saya sudah frustrasi dengan kurangnya antarmuka penuh untuk bahasa non-Jawa. Saya tahu rilis saat ini adalah transisi, tapi saya benar-benar bisa menggunakan solusi PHP penuh sekarang, bukan dalam beberapa rilis mitos di masa depan. Tapi itu tidak apa yang kamu minta.)
Saya pikir jika pria penguji Anda belum tahu tentang Selenium, dia akan mencium Anda dengan jujur karena mengatakan kepadanya tentang hal itu.
Selenium-IDE dirancang untuk tujuan digunakan oleh non-programmer. Tetapi pengalaman saya adalah bahwa skrip yang dihasilkan seperti itu (menggunakan XPath yang dihasilkan) sangat rapuh.
Jadi buat di dalamnya seharusnya tidak ada masalah sama sekali. Mengelola tidak akan terlalu buruk jika aplikasi Anda cukup stabil. Atau hampir mustahil jika aplikasi Anda dalam pengembangan dan / atau sering berubah.
Selenium-RC adalah murni alat pengembang.
data-test-labelatribut khusus pada elemen. Saya akan menaruhnya di GitHub, tetapi itu dibuat pada waktu perusahaan ...
Saya sangat menyarankan Anda mengajukan pertanyaan ini di situs beta Jaminan Kualitas & Pengujian Perangkat Lunak , atau mencari pertanyaan serupa yang telah diajukan di sana. Anda akan menemukan kedalaman pengalaman yang jauh lebih besar dengan menggunakan Selenium untuk merekam dan memutar ulang QA.
Jawaban Eric adalah pengalaman sebagian besar Insinyur QA yang menggunakan alat rekam dan playback: Hasil tes rapuh dan sulit dipertahankan. Pengembang dapat menggunakan Objek Halaman dengan Selenium RC untuk membuat rangkaian uji UI yang jauh lebih dapat dikelola, dan merupakan pilihan yang lebih baik bila tersedia.
Ini bukan untuk mengatakan bahwa Selenium IDE tidak akan berguna untuk tester Anda; Namun, kegunaan (dan potensi untuk melukai upaya pengujian daripada membantu) sangat tergantung pada seberapa tetap UI itu. Anda akan mendapatkan hasil terbaik Anda dengan catatan-dan-pemutaran jika UI dapat dibekukan di awal siklus pengembangan. Anda mungkin perlu mengajari tester cara mendapatkan XPath baru saat XPath lama rusak, dan cara mengetahui apakah tes gagal karena perubahan UI (karena XPath tidak lagi valid) atau karena bug fungsionalitas.
Saya pikir menggunakan Selenium IDE lebih baik daripada tidak ada otomatisasi sama sekali untuk setiap proyek yang memiliki beberapa UI yang umumnya stabil. Menjalankan ratusan tes manual pada UI stabil setiap kali ada perubahan kecil adalah waktu yang nyata. Cukup tetapkan harapan sesuai dan sadari bahwa mengubah UI akan memiliki dampak yang jauh lebih besar pada jadwal QA setelah Anda mulai menggunakan otomatisasi record-and-replay untuk UI itu. Penguji Anda mungkin ingin memilih dan memilih area yang diotomatiskannya secara bijak.
Saya tidak punya masalah melatih orang-orang non-pemrograman untuk menulis tes Selenium dengan XPaths relatif di Java / JUnit. Pemrogram mengaturnya dan menulis templat tes dasar, tester mengembangkan lebih banyak tes - dengan merekam dan kemudian mengubahnya. Jika tester membutuhkan sesuatu yang spesifik, ia meminta programmer untuk menulisnya. Penguji perlu memiliki pemahaman yang sangat mendasar tentang HTML dan XPath, dan sedikit bantuan untuk mengambil Selenium API (serta plugin Selenium untuk Firefox dan Firebug).
Lucunya, awalnya saya mempertimbangkan sesuatu yang mewah seperti Mentimun atau yang serupa, tetapi kombinasi Selenium / JUnit ini terbukti cukup baik dan cukup sederhana. Anehnya, penguji tanpa pengalaman Java sebelumnya tidak memiliki masalah serius dalam menulis tes JUnit. Satu-satunya hal yang penting adalah programmer berpengalaman mengatur tes, sehingga tester pada dasarnya hanya perlu menghasilkan tes baru dan memanggil metode Selenium.
Pertimbangkan untuk menggunakan kerangka kerja pengujian berbasis kata kunci. Idenya adalah, pengembang mengembangkan kata kunci tingkat tinggi (atau Anda menggunakan kata kunci yang datang di perpustakaan), dan penguji hanya mengumpulkan kata kunci ini ke dalam kasus uji tingkat tinggi.
Tim yang saya ikuti selama beberapa tahun terakhir telah mendapatkan banyak jarak tempuh dari pendekatan ini. Kami menggunakan kerangka robot tetapi ada yang lain seperti mentimun (didukung oleh beberapa bahasa) dan specflow (implementasi mentimun untuk .net)
Misalnya, menggunakan pendekatan ini tester Anda mungkin menulis tes yang terlihat seperti ini:
| Login with valid credentials
| | Go to page | LoginPage
| | Login as a normal user
| | The current page should be | DashboardPage
Kata kunci ini dapat ditulis dengan python (atau java, atau bahasa .NET), seperti:
class LoginPage(PageObject):
def login_as_a_normal_user(self):
username = self.browser.find_element_by_id("username")
username.send_keys(DEFAULT_USER)
password = self.browser.find_element_by_id("password")
password.send_keys(DEFAULT_PASSWORD)
... and so on...
Ada perpustakaan yang dibuat sebelumnya untuk robot dengan kata kunci umum berdasarkan selenium ("buka halaman", "halaman harus berisi", "tombol klik", dll.) Yang dengannya tester dapat segera menjadi produktif.
Cukup sering kata kunci umum ini cukup, tetapi menggunakan konsep objek halaman dan kata kunci spesifik halaman adalah cara yang ampuh untuk menulis tes. Pengembang Anda dapat membuat kelas untuk setiap halaman di aplikasi Anda, dan untuk setiap halaman mereka dapat menulis kata kunci tujuan khusus sehingga tester dapat lebih fokus pada fungsi logis halaman daripada implementasi fisik.
Berikut adalah beberapa posting blog yang saya tulis yang lebih detail dalam menggunakan objek halaman dengan kerangka robot:
Kami benar-benar mengalami situasi ini ketika kami memiliki anggota tim non-teknis (dalam hal ini, SQA tanpa latar belakang pemrograman). Sayangnya ini tidak berjalan dengan baik.
Pertama-tama tim kami telah mencoba alat rekaman dan bermain, tetapi seperti yang lain katakan, tes yang dihasilkannya sangat rapuh dan sulit dipertahankan. SQA kami akhirnya jatuh ke dalam pola hanya merekam ulang tes setiap kali itu berubah, yang tidak terlalu efisien, terutama ketika satu perubahan merusak sebagian besar pengujian kami (kami memiliki satu perubahan pada halaman utama situs web kami yang rusak sekitar 60 % dari tes kami).
Kami menulis tes Selenium kami di Jawa dan SQA belum pernah menggunakan Java sebelumnya, jadi ia mempelajarinya sendiri. Kami menemukan bahwa tes akhirnya menggunakan beberapa praktik pemrograman yang sangat buruk:
assertTrue(false)baris untuk mengakhiri tesKetika saya tiba di tim, SQA asli telah pergi dan menjalankan tes apapun menghasilkan banyak pengecualian konsol yang kami hanya diberitahu untuk mengabaikannya. Setelah itu, kami akhirnya melibatkan pengembang dan secara besar-besaran menulis ulang banyak kode untuk membuatnya benar-benar berfungsi dan dapat dipelihara dan mudah dipahami.
Saya pikir beberapa masalah ini mungkin dapat dihindari jika ada seseorang yang secara teknis datang dan membantu mereka. Jika mereka menjelaskan mengapa variabel statis publik seharusnya menjadi variabel instance pribadi, atau cara kerja JUnit, atau cara menggunakan WebDriverWait, atau mengapa hamburan Thread.sleep () di mana-mana buruk, kami mungkin memiliki kode yang lebih baik.
Tetapi, seperti sekarang, kita menemukan kode yang pada akhirnya tidak dapat dipelihara dan pada akhirnya, kita hanya menulis ulang sebagian besar darinya, yang mengakibatkan pemborosan waktu dan uang yang besar.