Dengan artikel ini, kami membuka serangkaian publikasi tentang bagaimana kami mengotomatiskan proses pengujian manual sistem informasi besar di salah satu proyek utama LANIT dan apa yang dihasilkannya.

Bagian pertama - organisasi dan manajerial - harus bermanfaat terutama bagi mereka yang bertanggung jawab untuk pengujian otomatisasi dan membuat sistem seperti itu secara keseluruhan. Manajer proyek, pemimpin kelompok dan pemilik layanan pengujian fungsional dan otomatis, semua yang peduli dengan pertanyaan "bagaimana membangun pengujian 2-end ujung-ujung sistem TI mereka", akan menemukan di sini rencana dan metodologi yang konkret.

Sumber

Bagian 1 - Organisasi dan manajerial. Kenapa kita perlu otomatisasi. Organisasi proses pengembangan dan manajemen. Organisasi penggunaan

Awalnya, pada awalnya ada sistem informasi yang besar dan kompleks (kami akan menyebutnya "Sistem") dengan berbagai skenario bisnis yang kompleks, panjang dan saling berhubungan. Semua skrip diuji sebagai E2E melalui antarmuka web secara eksklusif dalam mode manual (ada lebih dari satu setengah ribu skenario semacam itu dari prioritas paling kritis saja). Selain itu, semua skenario ini harus diselesaikan setidaknya satu kali selama regresi setiap rilis baru atau perbaikan terbaru sebelum pembaruan penempatan berikutnya untuk produk.

Pada saat tertentu, ketika mengklik mouse sepenuhnya dalam mode manual, kami memutuskan untuk mengotomatiskan semuanya. Yang dilakukan melalui pengembangan layanan terpisah berdasarkan java + selenium + selenide + selenoid, yang selanjutnya disebut "kerangka pengujian" atau hanya - "Autotests" .

Secara historis, kode kerangka kerja pengujian dikembangkan oleh dua tim. Pertama, tim pertama menciptakan prototipe dengan beberapa lusin skenario. Kemudian tim kedua selama satu tahun menskalakan prototipe baik dalam luasnya (jumlah tes) dan mendalam (pengkodean dan pola implementasi yang khas diperkenalkan).

Saya adalah tim dan ketua tim dari tim kedua, yang mengadopsi kerangka kerja prototipe untuk penskalaan (pada Mei 2018).

Pada saat penulisan ini, tugas yang ditetapkan setahun yang lalu telah selesai dan tim proyek diberikan layanan otomatisasi yang stabil. Bukan sia-sia saya menekankan layanan , karena pada awalnya tugas itu tidak ditetapkan sebagai mengembangkan aplikasi, tetapi sebagai menyediakan layanan-layanan untuk pengujian otomatisasi ke grup "pengujian fungsional". Dan fitur ini selanjutnya sangat memengaruhi organisasi pengembangan dan arsitektur kerangka pengujian.

Ringkasan

Sekitar 1.500 skenario pengujian diotomatiskan: dalam setiap pengujian, dari 200 hingga 2000 operasi pengguna.

Total kapasitas layanan ini hingga 60 browser yang bekerja secara bersamaan, dan ini bukan batasnya (jumlahnya dapat ditingkatkan 5 kali karena mesin virtual).
Total durasi regresi lengkap tidak lebih dari 3 jam, dan tes PreQA kurang dari satu jam.

Berbagai fitur telah diimplementasikan:

• penggunaan lokal (eksekusi real-time) dan jarak jauh (melalui paket Bamboo);
• membatasi komposisi tes yang berjalan dengan filter;
• laporan terperinci dengan hasil dari setiap langkah skenario pengujian (melalui kerangka kerja Allure);
• mengunduh dan mengunggah file dari / ke browser, diikuti dengan memeriksa hasil pemrosesan mereka dalam hal format dan isi file;
• akuntansi dan kontrol sifat asinkron dari antarmuka sudut. Termasuk kontrol permintaan yang digantung (permintaan yang tertunda) antara layanan Angular dan REST;
• kontrol log browser;
• rekaman uji video;
• menghapus snapshot halaman pada titik "jatuh" dari tes;
• transmisi acara dalam ELK;
• lebih banyak tentang hal-hal kecil ...

Mengapa semua ini dibutuhkan?

Pada awalnya, tujuan dari sistem itu cukup sederhana dan jelas.

Bayangkan Anda memiliki sistem registri besar untuk mengelola berbagai dokumen dan siklus hidupnya, yang menyediakan beberapa ratus proses bisnis. Selain itu, ada jutaan orang, pemasok - puluhan ribu, layanan - ribuan, dokumen kompleks, termasuk kerangka kerja dan templat, dan menyediakan proses bisnis disediakan dalam ratusan cara berbeda ...

Semua ini berubah menjadi satu setengah ribu skenario pengujian, dan ini hanya prioritas tertinggi dan hanya positif.

Dalam proses otomatisasi, berbagai nuansa terungkap yang membutuhkan penggunaan berbagai solusi.

Misalnya, satu skrip dapat berisi hingga ratusan operasi terpisah, termasuk yang menarik seperti: "Unduh file EXCEL dengan data dan verifikasi bahwa sistem memproses setiap catatan dari file" (untuk menyelesaikan masalah ini, diperlukan beberapa langkah untuk menyiapkan data dan kemudian memeriksa hasil pemuatan ke dalam Sistem) Dan sekarang mari kita tambahkan batasan pada penggunaan kembali data uji: data uji untuk penyelesaian sebagian besar skenario uji harus "segar" dan sebelumnya tidak digunakan dalam skenario yang sama (selama pengujian, keadaan data dalam Sistem berubah, sehingga tidak dapat digunakan kembali untuk cek yang sama).

Sumber

Pada titik tertentu, pengujian manual terhadap Sistem sebagai bagian dari regresi tidak lagi tampak hemat biaya dan cukup cepat, dan mereka memutuskan untuk mengotomatiskannya melalui antarmuka pengguna web.

Dengan kata lain, kelompok pengujian fungsional membuka "halaman", memilih "kelompok uji", menekan tombol "jalankan" (kami menggunakan Bambu). Kemudian Autotests (selanjutnya disebut Autotests. Tentukan produk yang dibuat untuk pengujian secara umum) secara otomatis meniru tindakan pengguna dalam Sistem melalui browser ("tekan" tombol yang diperlukan, masukkan nilai di bidang, dll.), Setelah selesai, tampilkan laporan terperinci pada semua langkah-langkah dan tindakan serta hasil verifikasi yang diselesaikan (korespondensi dari reaksi yang diharapkan dari Sistem dengan perilaku aktualnya).

Total, tujuan Autotests adalah otomatisasi pengujian E2E manual. Ini adalah sistem "eksternal" yang tidak mengambil bagian dalam proses pengembangan sistem yang sedang diuji dan sama sekali tidak terhubung dengan unit atau tes integrasi yang digunakan oleh pengembang.

Tujuan

Itu perlu untuk secara signifikan mengurangi biaya tenaga kerja melakukan pengujian End-2-End dan meningkatkan kecepatan regresi lengkap dan berkurang dalam hal volume.

Tugasnya

Tugas utama pengembangan diformulasikan dengan sangat sederhana - untuk mengotomatisasi selama 6 bulan ke depan 1000 skenario pengujian dengan prioritas tertinggi.

Jumlah tindakan uji dasar yang diperkirakan berkisar antara 100 hingga 300, yang memberi kami sekitar 200 ribu metode uji dengan 10-20 baris kode, tanpa memperhitungkan kelas umum dan tambahan pembantu, penyedia data, dan model data.

Dengan demikian, ternyata, dengan mempertimbangkan batasan waktu (130 hari kerja), perlu untuk melakukan setidaknya 10 tes per hari dan pada saat yang sama memastikan relevansi tes mandiri yang diterapkan dengan mempertimbangkan perubahan yang terjadi dalam Sistem (Sistem secara aktif berkembang).

Menurut perkiraan para ahli, tenaga kerja yang dibutuhkan untuk mengembangkan satu autotest adalah 4-8 jam. Jadi kami memiliki tim yang terdiri dari 5 orang setidaknya (pada kenyataannya, di puncak pengembangan autotests, tim memiliki lebih dari 10 insinyur otomasi).

Tugas-tugas yang perlu diselesaikan juga bisa dimengerti.

• Konfigurasikan proses dan perintah:
• mendefinisikan proses interaksi dengan pelanggan (kelompok pengujian fungsional), memperbaiki format deskripsi kasus pengujian sebagai input ke tim otomasi;
• mengatur proses pengembangan dan pemeliharaan;
• membentuk tim.
  
• Kembangkan autotest dengan fitur berikut:
• secara otomatis mengklik tombol di browser dengan pemeriksaan pendahuluan untuk keberadaan elemen dan informasi yang diperlukan pada halaman;
• menyediakan pekerjaan dengan elemen kompleks seperti Yandex.Map;
• untuk memastikan pemuatan file yang dihasilkan secara otomatis ke dalam Sistem, untuk memastikan pengunduhan file dari Sistem dengan verifikasi format dan kontennya.
• Berikan catatan dari tangkapan layar browser, video dan log internal.
• Untuk memberikan kemampuan untuk berintegrasi dengan sistem eksternal seperti server surat, sistem pelacakan tugas (JIRA) untuk memeriksa proses integrasi antara Sistem yang diuji dan sistem eksternal.
• Berikan laporan yang terdokumentasi tentang semua tindakan yang diambil, termasuk tampilan nilai yang dimasukkan dan diverifikasi, serta semua investasi yang diperlukan.
• Lakukan tes dalam volume yang diperlukan dalam mode paralel.
• Menyebarkan autotest di infrastruktur yang ada.
• Sempurnakan skrip uji yang sudah otomatis dari konsep target konsonan (kecepatan perbaikan - sekitar 50 tes per minggu sprint).

Seperti yang saya sebutkan dalam pendahuluan, pada awalnya kami memiliki prototipe MVP yang bekerja diimplementasikan oleh tim lain, yang harus ditingkatkan dari 20 tes menjadi 1000, menambahkan fitur baru di sepanjang jalan, dan memastikan skalabilitas yang dapat diterima dan fleksibilitas untuk membuat perubahan.

Kehadiran prototipe yang berfungsi juga di pintu masuk memberi kami tumpukan teknologi, yang meliputi: Java SE8, JUnit4, Selenium + Selenide + Selenoid, Bambu sebagai "pelari" pengujian dan "pembangun" laporan Allure. Karena prototipe bekerja dengan baik dan menyediakan fungsionalitas dasar yang diperlukan, kami memutuskan untuk tidak mengubah tumpukan teknologi, tetapi untuk fokus pada pengembangan skalabilitas solusi, meningkatkan stabilitas dan mengembangkan fitur yang diperlukan yang hilang.

Pada dasarnya, semuanya terlihat layak dan optimis. Selain itu, kami benar-benar mengatasi tugas pada waktu tertentu.

Berikut ini menjelaskan aspek teknologi dan proses individu dalam mengembangkan AutoTests.

Deskripsi Autotests. Cerita dan Fitur Pengguna

Sumber

Autotests mengimplementasikan rangkaian cerita pengguna berikut ini dalam konteks penggunaannya oleh kelompok pengujian:

• otomasi uji manual;
• regresi penuh otomatis;
• kontrol kualitas rakitan dalam rantai CI \ CD.

Rincian implementasi dan keputusan arsitektur akan dibahas dalam Bagian 2 - Teknis. Arsitektur dan tumpukan teknis. Detail implementasi dan kejutan teknis .

Pengujian otomatis dan manual (Kisah pengguna)

Sebagai seorang penguji, saya ingin melakukan tes target E2E, yang akan dilakukan tanpa partisipasi langsung saya (dalam mode otomatis) dan akan memberi saya laporan terperinci dalam konteks langkah-langkah yang diambil, termasuk data yang dimasukkan dan hasil yang diperoleh, serta:

• Seharusnya dimungkinkan untuk memilih tegakan target yang berbeda sebelum memulai tes;
• harus dapat mengelola komposisi tes berjalan dari semua yang diterapkan;
• di akhir tes, Anda perlu mendapatkan video tes dari layar browser;
• saat tes mogok, Anda perlu mendapatkan tangkapan layar dari jendela browser aktif.

Regresi penuh otomatis

Sebagai grup pengujian, saya ingin melakukan semua tes setiap malam di bangku tes tertentu dalam mode otomatis, termasuk semua fitur "Pengujian manual otomatis".

Kontrol kualitas perakitan dalam rantai CI \ CD

Sebagai kelompok pengujian, saya ingin melakukan pengujian otomatis pembaruan yang disebarkan Sistem pada preQA-stand khusus sebelum memperbarui target tahap uji fungsi fungsional, yang kemudian digunakan untuk pengujian fungsional.

Menerapkan fitur dasar

Sumber

Berikut adalah sekilas fungsi-fungsi utama AutoTests yang diimplementasikan, yang ternyata sangat penting atau hanya berguna. Rincian implementasi beberapa fungsi menarik akan ada di bagian kedua artikel.

Penggunaan lokal dan jarak jauh

Fungsi ini menawarkan dua opsi untuk menjalankan Autotests - lokal dan jarak jauh.

Dalam mode lokal, tester menjalankan autotest yang diperlukan di tempat kerjanya dan pada saat yang sama dapat mengamati apa yang terjadi di browser. Peluncuran dilakukan melalui "segitiga hijau" di IntelliJ IIDEA -). Fungsi ini sangat berguna pada awal proyek untuk debugging dan demonstrasi, tetapi sekarang hanya digunakan oleh pengembang autotest.

Dalam mode jarak jauh, tester memulai autotest menggunakan antarmuka paket Bamboo dengan parameter komposisi tes yang berjalan, dudukan dan beberapa parameter lainnya.

Fungsi ini diimplementasikan menggunakan variabel lingkungan MODE = REMOTE | LOCAL, tergantung pada mana browser web lokal atau jarak jauh diinisialisasi di cloud Selenoid .

Membatasi komposisi tes yang berjalan dengan filter

Fungsi ini memungkinkan untuk membatasi komposisi pengujian yang berjalan dalam mode penggunaan jarak jauh untuk kenyamanan pengguna dan untuk mengurangi waktu pengujian. Filtrasi dua tahap digunakan. Langkah pertama memblokir pelaksanaan tes berdasarkan variabel FILTER_BLOCK dan digunakan terutama untuk mengecualikan kelompok besar tes dari berjalan. Langkah kedua "melompati" hanya tes yang cocok dengan variabel FILTER.

Nilai filter ditentukan sebagai satu set ekspresi reguler REGEXP1, ..., REGEXPN, diterapkan oleh prinsip "OR".

Ketika memulai dalam mode manual, tester diminta untuk menetapkan variabel lingkungan khusus sebagai daftar ekspresi reguler yang berlaku untuk anotasi @ Filter (nilai String) khusus, yang menjelaskan semua metode pengujian di kelas uji. Untuk setiap pengujian, anotasi ini unik dan dibuat berdasarkan serangkaian tag yang dipisahkan oleh garis bawah. Kami menggunakan templat minimum berikut SUBSYSTEM_FUNCTION_TEST-ID_ {DEFAULT}, di mana tag DEFAULT untuk tes yang termasuk dalam regresi malam otomatis.

Fungsi ini diimplementasikan melalui ekstensi kustom dari kelas org.junit.runners.BlockJUnit4ClassRunner (detail akan diberikan di Bagian 2-1 dari kelanjutan artikel ini)

Mendokumentasikan laporan dengan hasil untuk semua langkah

Hasil tes ditampilkan untuk semua tindakan uji (langkah) dengan semua informasi yang diperlukan yang tersedia di Allure Framework. Untuk daftar mereka tidak masuk akal. Ada informasi yang cukup baik di situs web resmi dan di Internet secara keseluruhan. Tidak ada kejutan menggunakan Allure Framework, dan secara umum saya merekomendasikannya untuk digunakan.

Fungsi utama yang digunakan adalah:

• tampilan setiap langkah uji (nama langkah sesuai dengan namanya dalam spesifikasi tes - skrip uji);
• menampilkan parameter langkah dalam bentuk yang dapat dibaca manusia (melalui implementasi yang diperlukan dari metode toString dari semua nilai yang dikirimkan);
• Melampirkan tangkapan layar, video, dan berbagai file tambahan ke laporan;
• klasifikasi pengujian berdasarkan jenis dan subsistem, serta penghubungan autotest dengan spesifikasi pengujian dalam sistem manajemen tautan pengujian. Tautan Uji melalui penggunaan anotasi khusus.

Unduh dan unggah file dari / ke browser dengan verifikasi dan analisis selanjutnya

Bekerja dengan file adalah aspek yang sangat penting dari skrip pengujian. Itu perlu untuk menyediakan kedua unggah berbagai file, dan unduh.

Mengunduh file tersirat, pertama-tama, memuat file EXCEL yang dihasilkan secara dinamis ke dalam Sistem sesuai dengan konteks eksekusi skrip pengujian. Pengunduhan diimplementasikan menggunakan metode standar yang disediakan oleh alat selenium.

Mengunggah file menyiratkan mengunduh file dengan menekan tombol "di browser ke direktori lokal dengan" transfer "file ini ke server tempat AutoTests dijalankan (server di mana agen Bambu jarak jauh diinstal). Selanjutnya, file ini diuraikan dan dianalisis dalam hal format dan konten. Jenis file utama adalah file EXCEL dan PDF.

Implementasi fungsi ini ternyata menjadi tugas yang tidak sepele, terutama karena kurangnya kemampuan penanganan file standar: saat ini, fungsi hanya diterapkan untuk browser Chrome melalui halaman layanan "chrome: // unduhan /".

Saya akan memberi tahu Anda secara rinci tentang detail implementasi di bagian kedua.

Akuntansi dan kontrol sifat asinkron antarmuka Angular. Kontrol permintaan yang tertunda antara layanan Angular dan REST

Karena objek pengujian kami didasarkan pada Angular, kami harus belajar untuk "bertarung" dengan sifat asinkron dari frontend dan timeout.

Secara umum, selain org.openqa.selenium.support.ui.FluentWait, kami menggunakan metode menunggu yang dirancang khusus yang memeriksa melalui Javascript untuk interaksi "tidak lengkap" dengan layanan REST front-end, dan berdasarkan batas waktu dinamis ini, tes mendapatkan informasi apakah akan mengikuti lalu tunggu sebentar.

Dari sudut pandang fungsionalitas, kami dapat secara signifikan mengurangi waktu yang dibutuhkan untuk menyelesaikan tes karena penolakan terhadap harapan statis di mana tidak ada cara yang berbeda untuk menentukan penyelesaian operasi. Selain itu, ini memungkinkan kami untuk menentukan layanan REST "menggantung" dengan masalah kinerja. Misalnya, mereka menangkap layanan REST yang jumlah catatannya ditampilkan pada halaman diatur ke 10.000 elemen.

Informasi tentang layanan REST "beku" dengan semua parameter panggilannya, yang karenanya uji "jatuh" karena alasan infrastruktur, ditambahkan ke hasil tes yang dijatuhkan, dan juga disiarkan sebagai acara di ELK. Ini memungkinkan Anda untuk segera mentransfer masalah yang diidentifikasi ke tim pengembangan Sistem yang sesuai.

Kontrol Log Peramban

Fungsi kontrol log browser ditambahkan untuk mengontrol kesalahan pada halaman tingkat SEVERE untuk menerima informasi tambahan untuk tes yang dibatalkan, misalnya, untuk memantau kesalahan seperti "... Gagal memuat sumber daya: server merespons dengan status 500 (Kesalahan Server Internal)".

Komposisi kesalahan pemrosesan halaman di browser diterapkan pada setiap hasil pengujian, dan juga diturunkan sebagai peristiwa dalam ELK.

Rekaman video tes dan menghapus snapshot halaman pada titik "jatuh" tes

Fungsi diimplementasikan untuk kenyamanan diagnosa dan penguraian tes yang dijatuhkan.

Rekaman video diaktifkan secara terpisah untuk mode uji coba jarak jauh yang dipilih. Video dilampirkan sebagai lampiran pada hasil dalam laporan Allure.
Tangkapan layar diambil secara otomatis saat pengujian macet, dan hasilnya juga diterapkan ke laporan Allure.

Melewati acara ke ELK

Fungsi pengiriman peristiwa ke ELK diimplementasikan untuk memungkinkan analisis statistik dari perilaku umum AutoTests dan stabilitas objek uji. Saat ini, acara telah dikirim untuk menyelesaikan tes dengan hasil dan durasi, serta kesalahan browser tingkat SEVERE dan memperbaiki layanan REST "beku".

Organisasi Pembangunan

Sumber

Tim pengembangan

Jadi, kami membutuhkan setidaknya 5 pengembang. Tambahkan orang lain untuk mengkompensasi ketidakhadiran yang tidak direncanakan. Kami mendapatkan 6. Plus seorang pemimpin tim, yang bertanggung jawab atas fungsionalitas lintas sektor dan tinjauan kode.

Dengan demikian, perlu untuk mengambil 6 pengembang Java (pada kenyataannya, di puncak pengembangan autotests, tim melebihi 10 insinyur otomasi).

Mengingat keadaan umum pasar dan tumpukan teknologi yang cukup sederhana, tim ini dibentuk terutama oleh pekerja magang, sebagian besar dari mereka baru saja lulus dari universitas atau berada di tahun terakhir mereka. Bahkan, kami mencari orang-orang dengan pengetahuan dasar tentang Jawa. Preferensi diberikan kepada spesialis pengujian manual yang ingin menjadi programmer, dan untuk memotivasi kandidat dengan beberapa pengalaman pengembangan (tidak penting) yang di masa depan ingin menjadi programmer.

, ( 2 – . . ).

, , . CodeRush . .

. , , «» .

() . code review merge request ( GitLab). code review «» ( ) .

– . / , .

ode review , , () - , . ode review .

code review , .

: , , , , . , , , / .

« », - -. -.

, . sprint retrospective event.

- ( ) , stakeholder .

– . , , . , - . .

- ( , . .), . () , « » / « » ( , , ).

- - ( : - – , - , — , ). , - / : « - ( )».

- , - (-) - («» ). «» - - « X» ( , -).

, . master, -. - - code review.

, – , .

:

(+) ;
(+) ;
(+) «» ;
(-) ();
(-) hotfix .

.

• MASTER.
• .
• FEATURE .
• , « » rebase.
• Gitlab merge request . merge request- :
• — «Jira»;
• — Bamboo.

GateKeeper ( )

• Bamboo.
• .
• (merge) FEATURE DEVELOP, .
• .

---

kotalesssk .

1, , . 2.

Bagian kedua - yang teknis - difokuskan terutama pada para pemimpin kelompok otomasi pengujian end-2-end UI dan otomatisasi pengujian terkemuka. Di sini mereka akan menemukan resep spesifik untuk organisasi arsitektural kode dan penyebaran, yang mendukung pengembangan paralel-massal kelompok besar pengujian dalam menghadapi variabilitas spesifikasi pengujian yang konstan. Selain itu, Anda dapat menemukan di bagian kedua daftar lengkap fungsi yang diperlukan untuk pengujian UI dengan beberapa detail implementasi. Dan daftar kejutan yang mungkin Anda temui juga.