Dari Zaman Es ke Avengers menggunakan Appium

Pelajaran dari pendekatan Robot Kite

Biarkan saya mulai di sini dengan kait yang membosankan: pengalaman pribadi saya dalam menguji suatu aplikasi secara manual. Karena pengembangan produk mencakup pengiriman dalam potongan-potongan, menjadi monoton bagi anggota tim QA untuk melakukan tindakan yang sama berulang kali. Setiap kali saya harus menguji sesuatu, saya membutuhkan pengguna baru, jadi saya harus mendaftar pengguna baru secara manual. Itu lebih membosankan daripada kedengarannya.

Di sinilah otomatisasi masuk ke dalam gambar. Bagaimana jika kita menghabiskan waktu dalam menulis kode yang akan melakukan semua pekerjaan yang membosankan ini bagi kita? Bagaimana jika ini juga bekerja dengan akurat?

Tim QA di Kite melakukan sedikit R&D untuk menemukan alat yang tepat. Kami memutuskan Appium, karena itu:

  1. Apakah open source
  2. Tidak memerlukan kode sumber
  3. Tidak membutuhkan instrumentasi apa pun
  4. Memiliki banyak bahan pendukung yang mudah didapat

Appium mungkin, terlepas dari, terasa seperti ilmu roket bagi kebanyakan dari kita. Namun, jika Anda mengikuti pendekatan yang tepat, dimungkinkan untuk memanfaatkan sepenuhnya kemampuannya.

Dalam posting ini, saya akan menyoroti kelemahan dari pendekatan klasik untuk Appium, dan bagaimana pendekatan Robot kami di Kite membuat Appium pengalaman yang relatif bebas masalah. Kami menggunakan pendekatan Robot pada aplikasi pertama Layang-layang, Layang-layang Kas. Ini diluncurkan untuk keperluan eksperimen, dan menggelembung secara organik ke dalam jaringan lebih dari 100.000 pengguna di lebih dari 1.100 kota.

Pendekatan klasik

Secara umum, pendekatan klasik membuat kode berpasangan ketat, yang tidak dapat dipelihara, meningkatkan redudansi, membuat refactoring sulit dan tidak dapat diskalakan.

Dengan mengingat keterbatasan itu, mari mendekati Appium sebagai sebuah cerita.

Skenario klasik

Pertimbangkan layar masuk dengan nama pengguna, layar kata sandi dan tombol masuk. Jika saya memasukkan kredensial yang benar dan klik ‘Masuk,’ maka saya harus dapat masuk dan melihat layar berikutnya.

Sambil memikirkan ujian, kami mengajukan pertanyaan berikut: Apa yang ingin kami capai? dan Bagaimana kita akan mencapainya? Pendekatan kami sebelumnya sangat menyandingkan pasangan What and How ini. Namun, jika pasangan ini disimpan bersama-sama, itu membuat QA sulit untuk mempertahankan dan meningkatkan skrip. Masalahnya adalah, mau tidak mau, persyaratan bisnis berubah dan kita harus pergi dan mengubah tes kita karena penggandengan ini. Ini sebuah contoh:

Apa yang ingin dicapai: melewati nama pengguna / kata sandi yang benar harus membawa pengguna ke layar dasbor.

  • Masukkan nama pengguna "hulk@spiderman.com"
  • Masukkan kata sandi "HS @ 1235"
  • Tekan tombol ‘Masuk’
  • Verifikasi layar dasbor ditampilkan

Pertimbangkan kodenya:

Mari kita lihat masalah apa yang ada dalam pendekatan ini:

  1. Ada duplikasi kode tingkat tinggi, yang selanjutnya menurunkan kinerja otomasi.
  2. Kode di atas tidak dapat dibaca. Di perusahaan yang tumbuh cepat seperti Kite (dan banyak lainnya), anggota baru bergabung dengan tim individu setiap saat. Anggota baru tidak akan mengerti kode ini dan tujuannya jika mereka bergabung setelah kode ditulis.
  3. Kami tidak akan merasa nyaman dalam mengelola kode semacam ini dalam waktu dekat, ketika alur kerja aplikasi meningkat.
  4. Setiap perubahan UI baru yang dimasukkan sulit dimasukkan dalam kode semacam ini, karena banyak refactoring - pada banyak titik - perlu dilakukan agar dapat berfungsi kembali.

Jelas, pendekatan klasik mungkin terlihat mudah, tetapi begitu fitur dalam aplikasi meningkat, itu menjadi sakit kepala untuk mengelola kode ini.

Pendekatan robot

Bagaimana jika kita mengikuti pendekatan di mana kita hanya berkonsentrasi pada Apa yang ingin kita capai? dan tidak Bagaimana kita ingin mencapainya? Kami kemudian akan membuat kelas yang berbeda untuk Bagaimana dan Apa. Dengan cara ini, kategori Bagaimana dan Apa akan independen satu sama lain.

Pola pengujian Robot mirip dengan Model Objek Halaman yang banyak digunakan, yang merupakan pola desain yang dimaksudkan untuk membuat repositori objek untuk elemen UI untuk platform berbasis web.

Saat ini, kami bergantung pada pengguna manual untuk melakukan tindakan. Bagaimana jika robot melakukan semua ini untuk kita? Dalam pendekatan Robot, kita tahu bahwa layar memungkinkan kita untuk memasukkan nama pengguna / kata sandi tanpa mempedulikan ke mana arah nilai-nilai ini.

Skenario robot

Robot ada di UsernamePasswordScreenBot, yang meneruskan nilai di bidang nama pengguna / kata sandi, dan mengklik ‘Log In.’ Sekarang, layar berubah dan robot ini hanya memiliki kontrol atas kelas UsernamePasswordScreenBot. Dari sini, bot lain mengambil, katakanlah, ResultScreenBot untuk melakukan tindakan lebih lanjut di layar berikutnya.

Dengan kata lain, buat robot per layar, dan itu akan melakukan tindakan yang diperlukan.

Duduk, santai, dan biarkan robot bekerja untuk Anda.

Kode ini menjelaskan apa yang kita inginkan, yaitu, untuk dapat memasukkan nama pengguna dan kata sandi yang harus login pengguna.

Perbandingan

Mari kita bandingkan metrik dan perubahan kinerja dalam pendekatan klasik dan pendekatan Robot:

  1. Duplikasi kode diminimalkan, karena kami menempatkan ID elemen dalam satu kelas, dan menggunakan kelas yang sama setiap waktu.
  2. Keterbacaan kode telah meningkat, karena anggota baru yang bergabung dengan tim dapat memahami apa yang dilakukan kode ini secara lebih intuitif.
  3. Mengelola kode seperti itu dan beradaptasi dengan perubahan UI sekarang lebih mudah. Ubah kode di satu tempat, dan perubahan ini mencerminkan dirinya sendiri di mana-mana. Pertimbangkan sebuah contoh: dalam aliran login, ID elemen berubah atau bidang baru ditambahkan. Dalam pendekatan klasik, kita harus membuat perubahan di setiap titik di mana kita masuk pengguna. Dalam pendekatan Robot, kita hanya akan menambah atau mengedit elemen dalam kelas UsernamePasswordScreenBot dan menyebutnya langsung dari sana.

Lingkup pengujian robot

Pada awalnya, kita mungkin berpikir bahwa bot tidak cukup pintar untuk menyelesaikan tes Sanity atau menutupi aliran negatif. Namun, bot Anda akan melakukan pengujian negatif, Sanity, dan regresi melalui kode seperti yang ada di bawah ini - memberi Anda beberapa menit tambahan yang berharga untuk dihabiskan saat istirahat makan siang. Untuk ini, kita perlu membuat metode yang berbeda dan meneruskan konten.

Kode di atas menunjukkan bagaimana Anda dapat membuat metode untuk semua jenis data yang ingin Anda lewati dalam satu kelas. Pendekatan klasik berkonsentrasi pada apa yang harus dicapai dan bagaimana cara mencapainya. Kita perlu menyingkirkan komponen 'Bagaimana' ini untuk membuat semuanya lebih sederhana.

Penghematan waktu dan pembangunan kapasitas

Kami telah menghemat banyak waktu dan meningkatkan kemampuan kami dengan beralih ke pendekatan Robot.

  1. Cakupan pengujian kami telah meningkat dibandingkan dengan pengujian manual.
  2. Kami telah mengurangi waktu yang dibutuhkan untuk menyelesaikan Sanity dari sehari penuh menjadi 5-10 menit.
  3. Kami telah mengurangi waktu pembuatan skrip hingga 50%, dan telah menyelesaikan masalah skalabilitas.
  4. Dengan pendekatan skrip, kita dapat membuat suite regresi yang membuat pengujian lebih sederhana dan lebih akurat.

Kesimpulan

Berada di startup seperti Kite, saya memiliki fleksibilitas untuk mencoba hal-hal baru dan menginvestasikan waktu dalam penelitian - karena inilah saya dapat menghasilkan pendekatan baru untuk menggunakan Appium. Saya menemukan praktik yang lebih baik setiap hari berkat tim yang sangat mendukung yang bekerja bersama saya di Kite. Melalui pertukaran terbuka, kami dapat berinovasi dengan cara yang membuat pekerjaan kami lebih efektif, efisien dan menyenangkan. Jika tempat kerja Anda mendukungnya, saya mendorong Anda untuk mengatur sesi berbagi pengetahuan, dan mengatur jam khusus setiap minggu untuk bereksperimen dengan teknik baru; itu adalah cara paling efektif untuk mengembangkan strategi jangka panjang untuk menjaga tim Anda tetap bersatu dan terus berinovasi.