Pembuatan Robot (RPA) dengan Alat AutoTest

Penulis: Lebedev A., Nazarova E.

Kebutuhan untuk menggunakan robot muncul karena berbagai alasan: kebutuhan untuk aplikasi baru untuk bertukar data dengan aplikasi yang tidak memiliki API, integrasi cepat aplikasi heterogen, otomatisasi proses rutin dengan biaya minimum, dll.

Secara tradisional, robot atau RPA (Otomatisasi proses robotik) dibangun berdasarkan kerangka kerja yang sudah jadi. Di sini, menurut pendapat kami, para pemimpin adalah produk dari UiPath, Automation Anywhere, Blue Prism, NICE. Ini adalah platform yang terbukti yang memungkinkan Anda membuat keputusan yang berkualitas. Namun, tidak murah. Anda perlu membayar lisensi dalam jumlah pekerjaan di masa depan, membayar untuk kustomisasi untuk tugas khusus Anda dan commissioning. Dalam beberapa kasus, Anda bisa menjadi lebih murah. Kami berhasil, dan siap berbagi pengalaman.

Beberapa waktu lalu, di salah satu bank, transformasi Agile dimulai. Pendekatan baru untuk mengembangkan aplikasi untuk kebutuhan bank. Untuk menunjukkan jalan kepada orang lain, mereka membentuk tim percontohan untuk mengembangkan produk baru.

Bank memiliki sistem kunci tradisional untuk melakukan kegiatan akuntansi dan operasional. Bekerja dengan produk-produk tim baru diimplementasikan dalam bentuk layanan mikro, yang harus bertukar data dengan sistem utama. Dan pengembangan dalam tim dimulai dengan sangat cepat. Tetapi masalahnya adalah bahwa pendekatan tradisional terhadap kebijakan pelepasan sistem utama tidak sesuai dengan langkah ini. Dan API untuk layanan-layanan microser baru ada dalam rencana untuk masa depan.

Ternyata, seperti Pechkin, "Saya membawakan Anda paket, tetapi saya tidak akan memberikannya kepada Anda." Dalam kondisi ini, perwakilan dari tim percontohan membahas tim pengujian otomatis kami dengan gagasan untuk menggunakan pengujian otomatis UI dari proses serupa untuk membuat robot.

Secara alami, kami pertama kali membahas risiko. Fakta bahwa ketika menggunakan alat pengujian mandiri, keandalan solusi perangkat lunak untuk persyaratan pengujian lebih rendah daripada aplikasi sistem pembayaran, diumumkan segera. Tetapi didorong oleh gelombang Agile, tim mengambil risiko.

Toolkit ini digunakan secara tradisional dan gratis: Jawa untuk pengembangan, perakitan melalui Maven. Untuk bekerja dengan browser, Selenium digunakan (aplikasi yang diperlukan untuk memasukkan data memiliki antarmuka web).

Fitur pembeda utama robot dibandingkan dengan UI autotest dari proses yang sama adalah kebutuhan untuk penanganan yang benar dari situasi kesalahan dan pengecualian, integrasi sebagai subsistem melalui pertukaran file.

Agar robot berfungsi, server virtual dialokasikan, akun domain teknis, dan pengguna terpisah dibuat dalam sistem tempat data dimasukkan. Dengan otoritas, seperti karyawan yang hidup yang melakukan tindakan serupa.

Agen Jenkins diinstal pada server ini, yang memungkinkan Anda untuk menjalankan robot. Laporan tentang pekerjaan robot dibentuk baik dalam bentuk log eksekusi dan dalam bentuk Laporan Daya Tarik. Keduanya tersedia di Jenkins dan tidak memerlukan izin khusus untuk mengakses sumber daya jaringan.

Pekerjaan robot disusun sebagai berikut: file dengan data untuk memasuki sistem ditempatkan di folder input pada sumber daya jaringan dan robot diluncurkan melalui Jenkins; itu membandingkan catatan file input dengan bidang kunci dengan file layanan, di mana semua catatan yang sudah diproses disimpan, dan hanya memilih yang belum diproses. Selanjutnya, array rekaman diproses dalam satu lingkaran. Selain itu, pada setiap langkah pemrosesan setiap catatan, pengecualian dan kesalahan diproses (coba ... tangkap) dan proses "tetes" dicatat dalam file yang dihasilkan. Pada saat yang sama, pemrosesan array input tidak berhenti, kami hanya pergi ke catatan berikutnya. Akibatnya, ketika pemrosesan seluruh array selesai, file input dihapus, dalam output ada semua catatan yang diproses dengan hasil dan runtime. Laporan Allure ditampilkan sebagai informasi tentang pemrosesan untuk setiap catatan,dan daftar umum dengan hasil pemrosesan setiap catatan. Ini memudahkan untuk mengevaluasi hasil dan melokalisasi masalah, jika ada.



Selain itu, dalam proses menggunakan robot, ternyata aliran aplikasi pada hari-hari puncak cukup besar dan untuk memenuhi waktu pemrosesan yang dapat diterima, diperlukan sejumlah besar pengguna secara bersamaan.

Sistem telah menciptakan beberapa pengguna lagi. Eksekusi paralel diimplementasikan menggunakan utas (Utas). Seluruh array catatan input didistribusikan secara merata di antara aliran, di mana masing-masing pemrosesan dilakukan di bawah penggunanya sendiri. Hasilnya ditulis dalam satu file dan laporannya juga tunggal. Nyaman. Pada saat yang sama, Server Selenium tunggal diluncurkan, yang dapat mengatasi peluncuran paralel beberapa browser (sesuai dengan jumlah pengguna yang bekerja). Kami bekerja dengan browser Chrome, masing-masing, chromedriver digunakan.

Ini mengejutkan, tetapi selama sembilan bulan operasi, masalahnya hanya karena data input yang salah. Masalah teknis muncul hanya pada tahap commissioning dan dikaitkan dengan koordinasi pengkodean dalam log dan perluasan memori yang digunakan ketika memulai Selenium Server (diinstal 1G).

Setelah beberapa waktu, untuk tim Agile yang sama, robot lain dikembangkan. Fiturnya adalah tidak memulai sesuai permintaan, tetapi bekerja terus menerus dengan memindai folder input. Ketika file yang masuk muncul, itu akan diproses. Dengan demikian, agen Jenkins tidak digunakan. Jika proses berhasil, file input dipindahkan ke folder dengan file yang berhasil diproses, jika tidak, ke folder dengan file yang salah. Tidak seperti robot sebelumnya, Allure Report tidak ada, tetapi log eksekusi ditulis ke file terpisah untuk analisis jika ada masalah. Dan satu fitur lagi - browser ditutup secara paksa pada akhir pemrosesan dan dimulai ketika pengguna harus masuk.

Jadi, dalam beberapa kasus, saat membuat RPA, Anda bisa bertahan dengan cara yang lebih murah menggunakan alat autotesting.