Penguji yang baik dengan kemampuan berpikir kritis tidak dapat sepenuhnya diganti oleh otomatisasi. Membuatnya bekerja lebih efisien itu mudah. Dengan keyakinan ini, saya pergi ke departemen pengujian kami dengan tugas baru, di mana kami, bersama dengan Pavel, mengambil implementasinya. Mari kita lihat apa yang terjadi.Bersama dengan mitra kami, kami secara aktif mengembangkan, menguji dan mendukung serangkaian aplikasi untuk berbagai platform: Android, iOS, Windows. Aplikasi sedang aktif dikembangkan, bersamaan dengan peningkatan volume pengujian, terutama regresi.
Kami memutuskan untuk mencoba memfasilitasi dan mempercepat pengujian dengan mengotomatisasi sebagian besar skenario pengujian. Pada saat yang sama, kami tidak ingin sepenuhnya meninggalkan proses pengujian manual, melainkan memodifikasinya.
Implementasi pendekatan ini dimulai dengan salah satu aplikasi Android, yang akan saya bicarakan. Artikel ini akan menarik bagi penulis pemula tes UI, terutama untuk aplikasi seluler, serta mereka yang ingin mengotomatisasi proses pengujian manual sampai batas tertentu.
Ayo pergi!
Titik awal
Untuk setiap platform, kami memiliki beberapa platform serupa yang melakukan proses bisnis aplikasi utama yang sama. Namun, mereka berbeda satu sama lain dalam satu set fungsi bantu kecil, dibuat di bawah merek yang berbeda tergantung pada pelanggan (karena itu antarmuka berubah dari aplikasi ke aplikasi), dan proses bisnis dapat disesuaikan dengan menambahkan langkah-langkah tambahan.
Kami dihadapkan dengan masalah-masalah tertentu yang perlu ditangani. Kesulitan serupa mungkin timbul dalam situasi yang berbeda dari kita. Misalnya, jika Anda memiliki satu aplikasi besar dengan logika bisnis yang sulit, ditumbuhi banyak tes.
Masalah # 1: banyak tes regresi
Seperangkat skenario pengujian untuk setiap aplikasi secara bersamaan serupa dan berbeda satu sama lain, yang berkontribusi pada peningkatan regresi dan membuatnya bahkan lebih membosankan. Namun, Anda perlu menguji semua aplikasi secara individual.
Menimbang bahwa aplikasi yang sudah berjalan diperbarui secara berkala, dan di masa depan hanya akan ada lebih banyak lagi, jumlah total tes akan bertambah.
Masalah nomor 2: Anda perlu menguji pada semua versi OS seluler
Persyaratan penting adalah ketersediaan aplikasi seluler kami pada berbagai versi sistem operasi. Misalnya, dalam kasus Android pada saat penulisan, ini adalah level API dari 17 hingga 28.
Idealnya, kita harus menguji pada setiap versi Android, yang semakin memperumit regresi kita. Proses pengujian langsung aplikasi memperoleh rutin tambahan yang dikalikan dengan jumlah perangkat: menginstal dan menjalankan aplikasi, membawanya ke keadaan semula setelah setiap tes individu, penghapusan. Pada saat yang sama, memelihara pertanian perangkat Anda sendiri cukup padat karya.
Solusi: mengintegrasikan otomatisasi ke dalam proses pengujian manual
Tugas khas otomatisasi uji adalah mengotomatiskan uji regresi. Jadi kami ingin meningkatkan efisiensi proses pengujian hari ini dan mencegah kemungkinan konsekuensi pertumbuhan besok.
Pada saat yang sama, kami sangat menyadari bahwa tidak mungkin dan tidak perlu untuk sepenuhnya menghapus pengujian manual dengan otomatisasi. Pemikiran kritis dan mata manusia sulit untuk digantikan dengan sesuatu. Ada artikel bagus tentang hal ini di blog Michael Bolton, The
End of Manual Testing (atau
terjemahan dari Anna Rodionova).
Kami pikir akan bermanfaat untuk memiliki satu set tes otomatis yang mencakup bagian-bagian aplikasi yang stabil, dan di masa depan tes tertulis untuk bug ditemukan dan fungsionalitas baru. Pada saat yang sama, kami ingin mengaitkan autotest dengan test suites yang ada dalam sistem manajemen pengujian kami (kami menggunakan TestRail), dan juga memungkinkan penguji untuk dengan mudah menjalankan autotest pada perangkat fisik cloud (kami memilih Firebase Test Lab sebagai infrastruktur cloud).
Untuk memulai dan mencoba, kami mengambil salah satu aplikasi Android kami. Penting untuk mempertimbangkan bahwa jika solusinya berhasil, praktik terbaiknya dapat diterapkan ke aplikasi kami yang lain, termasuk pada platform lain.
Apa yang ingin kita dapatkan sebagai hasilnya:
- Otomatisasi pengujian regresi.
- Integrasi dengan sistem manajemen pengujian.
- Kemungkinan dimulainya autotest manual berparameter pada perangkat cloud.
- Kemungkinan menggunakan kembali solusi di masa depan.
Selanjutnya, saya akan secara terpisah berbicara tentang implementasi masing-masing poin ini dengan sedikit perendaman dalam komponen teknis.
Skema implementasi solusi umum
Tapi pertama-tama, garis besar umum dari apa yang kita dapatkan:
Tes otomatis berjalan dalam dua cara:
- Dari CI setelah menggabungkan atau menarik permintaan untuk dikuasai.
- Penguji secara manual dari antarmuka web Jenkins Job.
Dalam hal peluncuran manual, penguji harus menunjukkan jumlah bangunan yang sesuai, atau mengunduh 2 APK dari komputer: dengan aplikasi dan dengan tes. Metode ini diperlukan agar Anda dapat menjalankan tes yang diperlukan kapan saja di perangkat apa pun yang tersedia.
Selama pengujian, hasilnya dikirim ke TestRail. Ini terjadi dengan cara yang sama seperti jika tester melakukan tes secara manual dan memasukkan hasilnya dengan cara yang akrab baginya.
Jadi, kami meninggalkan proses pengujian manual yang sudah ada, tetapi menambahkan otomatisasi padanya, yang melakukan serangkaian tes tertentu. Penguji "mengambil" apa yang dilakukan secara otomatis, dan:
- melihat hasil uji kasus pada setiap perangkat yang dipilih;
- dapat memeriksa ulang setiap test case secara manual;
- melakukan uji kasus yang belum diotomatisasi, atau tidak dapat dioptimalkan karena alasan apa pun;
- membuat keputusan akhir pada uji coba saat ini.
Sekarang mari kita beralih ke deskripsi implementasi yang dijanjikan.
1. Tes otomatis
Alat-alatnya
Kami menggunakan 3 alat untuk berinteraksi dengan antarmuka pengguna:
- Espresso
- Barista.
- Pengotomasi UI.
Alat utama dan yang kami mulai adalah Espresso. Argumen utama yang mendukung pilihannya adalah fakta bahwa Espresso memungkinkan Anda untuk menguji menggunakan metode kotak putih, menyediakan akses ke Instrumentasi Android. Kode tes dalam proyek yang sama dengan kode aplikasi.
Akses ke kode aplikasi Android diperlukan untuk memanggil metode dalam pengujian. Kita dapat menyiapkan aplikasi kita untuk tes tertentu terlebih dahulu dengan menjalankannya dalam kondisi yang tepat. Kalau tidak, kita perlu mencapai keadaan ini melalui antarmuka, yang menghilangkan tes atomitas, membuatnya tergantung satu sama lain, dan hanya memakan banyak waktu.
Selama implementasi, alat lain ditambahkan ke Espresso - UI Automator. Kedua kerangka kerja adalah bagian dari
Perpustakaan Dukungan Pengujian Android Google . Menggunakan Automator UI, kita dapat berinteraksi dengan berbagai dialog sistem atau, misalnya, Notification Drawer.
Dan yang terakhir di gudang kami adalah kerangka kerja Barista. Ini adalah pembungkus Espresso, menghemat kode boilerplate saat menerapkan tindakan pengguna umum.
Mengingat keinginan untuk dapat menggunakan kembali solusi di aplikasi lain, penting untuk dicatat bahwa alat yang terdaftar dimaksudkan khusus untuk aplikasi Android. Jika Anda tidak memerlukan akses ke kode aplikasi yang sedang diuji, maka mungkin Anda akan lebih suka menggunakan kerangka kerja yang berbeda. Misalnya, Appium yang sangat populer saat ini. Meskipun Anda juga dapat mencoba untuk mendapatkan kode aplikasi dengan bantuan backdoors, yang merupakan
artikel bagus di blog Badoo. Pilihan ada di tangan Anda.
Implementasi
Sebagai pola desain, kami memilih Pengujian Robot, yang diusulkan oleh Jake Wharton dalam
laporan eponymous. Ide pendekatan ini mirip dengan pola desain Objek Halaman yang umum digunakan dalam pengujian sistem web. Bahasa pemrogramannya adalah Java.
Untuk setiap fragmen independen dari aplikasi, kelas robot khusus dibuat di mana logika bisnis diterapkan. Interaksi dengan masing-masing elemen fragmen dijelaskan dalam metode terpisah. Selain itu, semua pernyataan yang dilakukan dalam fragmen ini juga dijelaskan di sini.
Pertimbangkan contoh sederhana. Fragmen yang dijelaskan berisi beberapa bidang untuk memasukkan data dan tombol tindakan:
Kode tes fungsi masuk itu sendiri:
Di sini kita memeriksa skenario positif ketika data otentikasi yang dimasukkan sudah benar. Data itu sendiri diserahkan ke tes input, atau nilai standar digunakan. Dengan demikian, tester memiliki kemampuan untuk membuat parameter dalam hal data uji.
Struktur ini pertama-tama memberikan tes keterbacaan yang sangat baik ketika seluruh skrip dibagi menjadi langkah-langkah utama eksekusi. Kami juga sangat menyukai gagasan mentransfer pernyataan ke metode individual dari robot yang sesuai. Penegasan menjadi langkah yang sama, tanpa memutus rantai umum, dan tes Anda masih tidak tahu apa-apa tentang aplikasi tersebut.
Dalam laporan tersebut di atas, Jake Wharton memberikan implementasi di Kotlin, di mana itu terbatas. Kami sudah mencobanya di proyek lain dan kami sangat menyukainya.
2. Integrasi dengan sistem manajemen pengujian
Sebelum pengenalan otomatisasi, kami melakukan semua pengujian kami dalam sistem manajemen pengujian TestRail. Berita baiknya adalah ada
TestRail API yang cukup bagus, yang dengannya kami dapat menghubungkan kasus uji yang sudah ada dalam sistem dengan autotest.
Selama uji coba menggunakan JUnit
RunListener , berbagai peristiwa ditangkap, seperti
testRunStarted ,
testFailure ,
testFinished , di mana kami mengirim hasilnya ke TestRail. Jika Anda menggunakan AndroidJUnitRunner, maka ia perlu memberi tahu tentang RunListener Anda dengan cara tertentu, yang dijelaskan dalam
dokumentasi resmi
.Anda juga perlu berkomunikasi dengan berbagai entitas TestRail dengan ID mereka. Jadi, untuk menghubungkan tes dengan test case yang sesuai, kami membuat penjelasan sederhana
@CaseId , yang penggunaannya diperlihatkan dalam contoh implementasi pengujian di atas.
Kode untuk mengimplementasikan anotasi itu sendiri:
Tetap hanya untuk mendapatkan nilainya di tempat yang tepat dari Deskripsi:
3. Mulai otomatis dari pengujian otomatis pada perangkat cloud
Parameterisasi Startup dalam Pekerjaan Jenkins
Untuk mengatur awal autotest secara manual, kami menggunakan
Jenkins Job Free-style . Opsi ini dipilih karena perusahaan telah memiliki beberapa pengalaman dengan pekerjaan serupa dengan Jenkins Job di bidang lain, khususnya dengan insinyur DevOps, yang dengan senang hati mereka bagi.
Jenkins Job mengeksekusi skrip berdasarkan data yang ditransfer dari antarmuka web. Dengan demikian, parameterisasi dari uji coba dilaksanakan. Dalam kasus kami, skrip Bash memulai peluncuran pengujian pada perangkat cloud Firebase.
Parameterisasi meliputi:
- Memilih APK yang diinginkan dengan menentukan jumlah bangunan yang sesuai atau mengunduhnya secara manual.
- Masukkan semua jenis data uji.
- Memasukkan data khusus tambahan untuk TestRail.
- Pilih perangkat fisik berbasis cloud tempat pengujian akan dijalankan dari daftar yang tersedia di Firebase Test Lab.
- Pemilihan test kit untuk dilakukan.
Mari kita lihat bagian halaman web dari Pekerjaan Jenkins kami menggunakan contoh antarmuka pemilihan perangkat dan suite tes:
Setiap elemen tempat Anda dapat memasukkan atau memilih data diimplementasikan oleh plugin Jenkins khusus. Misalnya, antarmuka pemilihan perangkat dibuat menggunakan
Plugin Pilihan Aktif . Menggunakan skrip asyik dari Firebase, daftar perangkat yang tersedia diperoleh, yang kemudian ditampilkan dalam formulir yang diinginkan di halaman web.
Setelah semua data yang diperlukan telah dimasukkan, skrip yang sesuai diluncurkan, kemajuan yang dapat kita amati di bagian Output Konsol:
Dari sini, penguji yang memulai uji coba dapat pergi ke TestRail atau ke Firebase console menggunakan URL yang diterima, yang berisi banyak informasi berguna tentang menjalankan tes pada setiap perangkat yang dipilih.
Matriks Tes Akhir di Firebase Test Lab
Matriks perangkat di Firebase berisi distribusi tes oleh perangkat yang menjalankannya:
Untuk setiap perangkat, Anda dapat melihat log lengkap, video uji coba, berbagai indikator kinerja. Selain itu, Anda dapat mengakses semua file yang mungkin telah dibuat selama pelaksanaan tes. Kami menggunakan ini untuk mengunduh indikator cakupan pengujian dari perangkat.
Kami memilih Firebase, karena kami telah menggunakan layanan ini untuk menyelesaikan masalah lain, dan kami puas dengan kebijakan penetapan harga. Jika Anda memenuhi 30 menit waktu murni untuk pengujian per hari, maka Anda tidak perlu membayar sama sekali. Ini mungkin menjadi alasan tambahan mengapa penting untuk hanya dapat menjalankan tes tertentu.
Anda mungkin lebih memilih infrastruktur cloud lain yang juga cocok dengan proses pengujian Anda.
4. Menggunakan kembali
Bagaimana semua ini bisa digunakan di masa depan? Dari sudut pandang basis kode, solusi ini hanya berlaku untuk aplikasi Android. Misalnya, selama implementasi, kami telah menambahkan kelas pembantu
EspressoExtensions dan
UiAutomatorExtensions , di mana kami merangkum berbagai opsi untuk berinteraksi dengan antarmuka dan menunggu elemen siap. Ini juga termasuk kelas RunListener, yang bertanggung jawab untuk integrasi dengan TestRail. Kami telah menempatkan mereka dalam modul terpisah dan menggunakannya untuk mengotomatiskan aplikasi lain.
Jika kita berbicara tentang platform lain, maka pengalaman yang didapat bisa sangat berguna untuk membangun dan mengimplementasikan proses serupa. Kami secara aktif melakukan ini di area iOS dan sedang memikirkan Windows.
Kesimpulan
Ada banyak opsi untuk menerapkan dan menggunakan uji otomasi. Kami berpendapat bahwa otomasi terutama merupakan alat yang dirancang untuk memfasilitasi proses tradisional pengujian "manusia", dan bukan untuk memberantasnya.