Diperlukan tes otomatis pada proyek. Tetapi, seperti yang mereka katakan, otomatisasi rasa dan warna bisa berbeda. Kami datang ke sebuah proyek di mana sudah ada autotes, dan mampu meningkatkan cakupan dan mempercepat berlalunya tes tanpa revolusi mendasar. Di bawah kucing tentang bagaimana kami melakukannya.
Beberapa kata tentang proyek ini
Meskipun kami tidak dapat mengungkapkan rincian proyek karena NDA, secara umum, tugasnya adalah sebagai berikut. Kami bergabung dengan pengembangan layanan API fintech, yang berinteraksi dengan basis data, mengembalikan objek keuangan yang diperlukan (harga, tarif, dll.). Tugas kami adalah menguji klien seluler untuk layanan ini - baik aplikasi web maupun seluler.
Otomatisasi uji pada proyek ini dikembangkan secara bertahap, bersama dengan kompleksitas layanan. Ini mungkin berapa lama tes end-to-end muncul pada satu waktu, yang kami temukan di proyek. Kebanyakan dari mereka tidak bekerja pada saat itu, karena layanan telah berubah, dan tidak ada yang mendukung tes - satu-satunya insinyur otomatisasi meninggalkan proyek jauh sebelum kami tiba.
Bahkan tes-tes yang tampaknya sesuai dengan fungsi kadang-kadang jatuh karena kebingungan dengan versi atau tidak dapat diaksesnya sumber daya eksternal. Untuk pengujian, infrastruktur terpisah digunakan - bangku tes, di mana versi yang diperlukan dikerahkan untuk percobaan. Kelompok kerja yang berbeda memiliki akses ke sana, dan mereka tidak selalu bertindak bersama. Sebagai hasil dari tindakan satu grup, beberapa API penting yang digunakan oleh layanan kami bisa jatuh, yang karenanya bahkan tes kerja berhenti lulus. Yaitu tes tidak lagi menunjukkan kemudahan servis dari layanan itu sendiri, tetapi lebih terkait dengan infrastruktur pengujian secara keseluruhan.
Bagaimana kami sampai pada kekacauan
Tampaknya dalam situasi ini perlu untuk meninggalkan semua prestasi lama dan membangun pengujian baru. Tapi kami bertindak lebih "manusiawi". Struktur tes itu sendiri dilestarikan, dengan fokus pada penyelesaian masalah-masalah khusus - jalannya tes yang lambat, ketidakstabilannya dan cakupan yang tidak memadai dari kasus-kasus uji. Untuk masing-masing dari mereka ada solusi.
Refactoring
Pertama-tama, kami mengerjakan ulang sebagian kode uji lama, dengan mengandalkan pola desain yang lebih modern.
Sebagian kode warisan harus dihapus - terlalu sulit untuk dipelihara. Di bagian lain, kami menangkap semua kelemahan - kami mengganti sleep default dengan waiters, membuat persiapan untuk semua tes dalam pengaturan global melalui anotasi pelari uji, dll. Banyak langkah kecil mengurangi rata-rata tes lulus ujung-ke-ujung dari 3-4 menjadi 1-2 menit.
Pendekatan atom
Untuk mempercepat pembuatan tes baru dan menyederhanakan dukungan yang lama, kami telah beralih dari kasus ujung ke ujung yang rumit.
Secara pribadi, saya tidak memiliki dasar terhadap pengujian end-to-end, namun, dalam kasus ketika Anda perlu memeriksa satu layar tertentu (atau bahkan bagian dari informasi di dalamnya), melalui semua langkah, mulai dengan otorisasi pengguna, terlalu mahal. Bayangkan kita sedang menguji toko online dan kita hanya perlu memeriksa cek yang akan dikirim ke pembeli setelah membeli produk tertentu. Alih-alih mengambil hanya satu layar dari sistem, kami akan masuk dengan login dan kata sandi, pilih produk, konfirmasi pembelian, dll. - akan melakukan banyak langkah yang tidak terkait dengan tugas pengujian tertentu. Tetapi setiap langkah membutuhkan waktu. Bahkan dengan semua optimasi yang dilakukan, peluncuran uji end-to-end memakan waktu hingga 2 menit, sedangkan verifikasi layar tertentu hanya membutuhkan waktu 10 detik. Oleh karena itu, jika memungkinkan, kami beralih ke pemeriksaan "atom" seperti itu, hanya merujuk pada layar yang menarik bagi kami sebagai bagian dari kasus uji.
Sepanjang jalan, hanya untuk perbandingan layar, kami menerapkan pengujian snapshot, yang memungkinkan Anda untuk memeriksa bagian terbesar dari UI. Memiliki tes dan kode aplikasi dalam satu repositori, kita dapat menggunakan metode aplikasi ini dalam pengujian, mis. naikkan layar apa saja yang diperlukan dalam proses ini. Jadi kita dapat menemukan kesalahan dalam membandingkan screenshot uji dengan yang referensi.
Kami sekarang memiliki sekitar 300 tes snapshot, dan jumlahnya meningkat secara bertahap, karena pendekatan ini dapat secara signifikan mengurangi waktu yang diperlukan untuk memeriksa versi yang sudah selesai sebelum mengirimkannya ke produksi. Seluruh rangkaian pengujian ini dimulai secara otomatis ketika permintaan tarik dibuka dan berjalan dalam 40 menit - sehingga pengembang dengan cepat menerima umpan balik tentang masalah di cabang saat ini.
Tentu saja, sejumlah tes end-to-end telah dipertahankan. Anda tidak dapat melakukannya tanpa mereka di mana Anda perlu memverifikasi skenario bisnis besar, tetapi masuk akal untuk menjalankannya ketika semua detail telah diverifikasi.
Mengejek
Untuk mengecualikan pengaruh bangku tes yang tidak stabil pada hasil peluncuran tes kami, kami meluncurkan server tiruan. Tentang keputusan apa yang kemudian kami pertimbangkan dan mengapa memilih Okhttpmockwebserver,
saya sudah menulis di Habré .
Akibatnya, pangsa yang jatuh secara episodik karena penyebab eksternal tes menurun secara signifikan.
Kotlin DSL
Secara paralel, kami membuat tes lebih mudah dibaca.
Mereka yang terlibat dalam pengujian UI tahu betapa sulitnya untuk menemukan kebenaran di antara sekelompok pelacak di “tapak kaki” panjang dari tes (terutama pada tahap ketika itu masih tes end-to-end). Sangat mudah untuk menavigasi di dalamnya ketika Anda sudah berada di proyek selama dua tahun dan bahkan di tengah malam dapat mengingat apa itu. Tetapi jika Anda baru saja datang, pindah ke apa yang terjadi adalah tugas besar yang terpisah. Agar orang baru tidak harus menghadapinya setiap waktu, kami memutuskan untuk beralih ke Kotlin DSL. Diimplementasikan dengan cukup sederhana dan memiliki struktur yang sederhana dan mudah dipahami. Jika sebelumnya tes terdiri dari serangkaian panggilan tingkat rendah yang identik - klik, input teks, gulir, sekarang semua ini telah berubah menjadi sesuatu yang lebih "bisnis" - sesuatu seperti pendekatan BDD. Semuanya terlihat dan bisa dimengerti.
Menurut pendapat saya, ini membuat kami cadangan tertentu untuk masa depan. Proyek ini pernah menghadapi kepergian seorang insinyur otomasi tunggal. Untuk tes, ini tidak berakhir dengan cara terbaik - mereka hanya berhenti mendukung mereka, karena ambang entri ternyata terlalu tinggi. Memahami kode kering seperti itu membutuhkan banyak waktu dan kualifikasi tertentu. Kami mendesain ulang tes sedemikian rupa sehingga memungkinkan untuk mentransfer orang dengan cepat dari proyek lain atau dari pengujian manual ke otomatisasi setiap saat. Hampir semua orang dapat menulis tes paling sederhana di Kotlin DSL. Jadi otomatisasi dapat meninggalkan implementasi tingkat rendah, dan dengan cepat menulis tes sederhana baru untuk menghubungkan orang-orang dari tim fungsional. Mereka memiliki cukup pengetahuan tentang logika bisnis, dan proyek akan mendapat manfaat dari fakta bahwa mereka akan lebih terlibat dalam proses penulisan autotest. Kotlin DSL memungkinkan Anda untuk mendeskripsikan kasus pengujian persis seperti mereka ingin melihat semua pemeriksaan, meninggalkan penerapan metode tingkat rendah di luar lingkup pekerjaan mereka.
Secara umum, semua ini memungkinkan untuk meningkatkan cakupan autotests lebih cepat. Jika sebelumnya diperlukan 16-20 jam untuk mengimplementasikan rangkaian uji baru, maka dengan pendekatan baru, tergantung pada kerumitan tes, dibutuhkan dari 4 hingga 12 jam (dan biaya tenaga kerja untuk dukungan berkurang dari 16-24 menjadi 8-12 jam di minggu).
Penulis artikel: Ruslan Abdulin.
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.
PPS Bantu kami membuat artikel blog kami lebih menarik:
docs.google.com/forms/d/e/1FAIpQLSeqnPceNuK-JopYVxgF15gNWLIi5oM_AZesioCDGXhvr7Y7tw/viewform .