🤱🏿 ↙️ 👨🏾‍💼 Terminal pengujian perangkat lunak otomasi QIWI 🤘 💆🏽 💆🏻

Halo, Habr!

Hari ini kita akan berbicara tentang topik tertentu: otomatisasi pengujian perangkat lunak untuk terminal swalayan QIWI.

Ada area dalam topik otomatisasi pengujian yang dipindai naik dan turun beberapa kali, misalnya, pengujian layanan web. Untuk bidang seperti itu, ada alat, pola, dan praktik terbaik yang terpisah. Anda tidak perlu menciptakan apa pun, risikonya minimal, Anda ambil dan lakukan.

Ada situasi terbalik. Area subjek spesifik, tidak ada yang mengambil solusi yang sudah jadi, tidak ada alat, tumpukan teknologi produk unik. Anda harus menyelam jauh ke dalam area subjek, dari tongkat dan uh ... bahan improvisasi lainnya untuk alat kerajinan untuk diri sendiri dan secara bersamaan mengumpulkan banyak, banyak garu dengan berbagai ukuran dan kekuatan mematikan.

Saya ingin membicarakan hal seperti ini hari ini. Artikel ini cocok untuk mereka yang terlibat dalam pengembangan dan pengujian perangkat lunak untuk terminal bank atau mesin swalayan. Dan juga bagi mereka yang ingin memperluas wawasan teknis mereka dengan contoh-contoh "tetapi itu juga terjadi seperti ini." Terminal QIWI pada tahun 2020. Di latar belakang, Anda dapat melihat isinya.

Masalah

Terminal QIWI pertama muncul pada tahun 2004 dan kemudian dapat mengisi kembali akun telepon seluler. Sejak itu, banyak air yang mengalir, dan ASO (mesin swalayan) telah banyak berubah. Sekarang dengan bantuan mereka, Anda dapat mengisi kembali kartu bank, melakukan transfer, membayar layanan dari berbagai pemasok (penyedia) - layanan perumahan dan komunal, denda polisi lalu lintas, organisasi kredit, produk QIWI kami sendiri (dompet QIWI, kartu angsuran bebas bunga Hati Nurani). Terminal QIWI juga dapat beroperasi dalam mode postamata (titik pengiriman otomatis untuk toko online).

Seperti apa terminal itu?

Terminal ASO, dari sudut pandang besi, adalah desktop biasa dengan periferal tertentu, seperti akseptor tagihan dan akseptor koin, printer penerimaan, dispenser, terminal POS (menerima kartu plastik), dll.

Dan inilah masalah pertama.

Foto terkenal ini diambil di Sonoma County, California. Mereka mengatakan bahwa ini adalah warna alami, tanpa pemrosesan apa pun. Ngomong-ngomong, di wilayah Kabupaten Sonoma tempat koloni Rusia paling selatan di Amerika berada.

Ya, itu dia. Sistem operasi, yang dihentikan pada tahun 2014, adalah Windows XP. Versi POSReady ditarik hingga 2019, tapi ... Ini tidak sesederhana itu.

Faktanya adalah bahwa terminal bukanlah milik QIWI. Mereka milik mitra, yang disebut Agen, pengusaha perorangan, dan badan hukum yang membuat perjanjian dengan terminal pembelian QIWI, menyewa ruang di pusat perbelanjaan dan menerima penghasilan yang hampir pasif.

Dengan demikian, 90% armada terminal QIWI (dan ada lebih dari 100rb di Rusia dan negara-negara asing) menjalankan Windows XP pada berbagai perangkat keras - dari RAM 512 MB hingga 4 GB, berbagai CPU (dari Pentium 4 dalam nol tahun hingga lebih - Core i5 kurang modern) dan kualitas dan kecepatan Internet yang berbeda. Terminal dari berbagai usia, beberapa dari mereka secara teratur ditingkatkan, dan beberapa dari mereka belum ditingkatkan untuk waktu yang sangat lama (berfungsi - jangan menyentuhnya!). Tugas kami adalah menyediakan secara teratur pembaruan perangkat lunak terminal terbaru (disebut MarATL) dan memelihara kompatibilitas dengan semua variasi topping dan periferal ini.

Sistem Operasi Dukungan Kadaluarsa

Bayangkan sebuah rangkaian otomatisasi uji sederhana. Kami memiliki server CI, misalnya, TeamCity atau Jenkins. Perangkat lunak terminal kami dikumpulkan dari raw oleh event (commit atau heap), file biner yang dikumpulkan diletakkan di suatu tempat. Perangkat lunak secara otomatis menginstal, autotests fungsional malam diluncurkan ... Eh, berhenti! Kemana perginya instalasi perangkat lunak? Dan bagaimana?

Seperti yang saya katakan di atas, 90 persen terminal menjalankan Windows XP, yang berakhir pada 2014. Ini berarti bahwa OS ini tidak lagi sesuai dengan kebijakan keamanan untuk waktu yang lama, tidak ada pembaruan yang dirilis untuk itu, tidak ada perangkat lunak yang berfungsi untuk itu, dan bahkan Microsoft Visual Studio asli mengkompilasi C ++ untuk itu hanya setelah menari dengan rebana, atau lebih tepatnya dengan versi rantai alat untuk kolektor MSBuild.

Secara umum, menjalankan tes dan beberapa jenis perangkat lunak pada terminal atau mesin virtual dengan Windows XP adalah ide yang sangat buruk. Anda tidak dapat meningkatkan Buildagent TeamCity di XP, Anda tidak dapat mengkonfigurasi mesin seperti itu di buku pedoman yang dimungkinkan, tidak ada wadah di sana juga. Template virtualisasi untuk Windows XP juga tidak banyak. Di perusahaan besar mana pun yang memikirkan keamanan informasi, mesin Windows XP akan dijauhkan dari jaringan perusahaan, atau bahkan kurang dari domain. Artinya, semua interaksi dengan terminal (atau mesin virtual yang berpura-pura seperti itu) harus terjadi dari jarak jauh, terminal itu sendiri harus memiliki minimum perangkat lunak pihak ketiga.

Keputusan

Beberapa orang terkejut ketika mereka mendengar tentang sekelompok OpenSSH dan Windows XP. Dalam Microsoft versi modern, dukungan OSH disertakan langsung dalam sistem. Di tidak begitu modern (Windows 7), ada installer SSH menggunakan PowerShell. C Windows XP, situasinya sedikit lebih buruk, tetapi hanya sedikit. Ada versi kuno penginstal yang berjalan di atasnya tanpa perangkat lunak tambahan.

SSH adalah cara lama, bagus, andal untuk mengontrol jarak jauh dari sebuah host, sebuah teknologi terkenal. Anda perlu mengimplementasikan kelas konektor SSH yang dapat melakukan beberapa hal secara paralel. Misalnya, dalam mode online, muat log baru dari terminal, jalankan beberapa perintah (menyalin file, menjalankan skrip, mengeluarkan hak, mendapatkan daftar proses, memantau waktu sistem terminal, dll.).

Waktu sistem pemantauan sangat menarik. Dengan alat baris perintah standar, Windows XP hanya menampilkan waktu dalam bentuk yang diformat jam-menit-detik, dll., Tidak ada waktu UNIX untuk Anda. Penyergapan, misalnya, adalah bahwa XP belum menerima pembaruan zona waktu untuk waktu yang lama, dan pemerintah Rusia kami dikenal untuk permainan konstan dengan pembatalan waktu musim panas atau musim dingin.

Misalnya, standar Windows XP SP3 di zona waktu Moskow menunjukkan waktu satu jam lebih awal dari waktu Moskow yang sebenarnya. Karenanya, cap waktu terminal log dalam hal apa pun tidak sesuai dengan waktu pada rangkaian uji.

Pembayaran-Pembayaran-Pembayaran ...

Antarmuka terminal QIWI pada dasarnya adalah web yang berjalan pada mesin browser, yang biasanya cukup lama. Menurut protokol websocket, ia berinteraksi dengan MarATL, sebenarnya perangkat lunak terminal. Ketika memilih pembayaran di terminal (misalnya, membayar untuk komunikasi seluler) menggunakan serangkaian perintah, penyedia pembayaran dipilih, jumlah komisi, pembatasan penerimaan tagihan ditentukan, pembayaran dibuat untuk penyedia tertentu, yang kemudian dikirim melalui pemrosesan terminal pembayaran ke pembayaran.

Berinteraksi dengan antarmuka web dari jarak jauh adalah ide yang biasa-biasa saja, terutama tes antarmuka - tugas lain. Anda dapat membuat halaman web pengujian yang akan didasarkan pada waktu pengujian alih-alih index.html standar. Halaman menjalankan skrip JS yang berfungsi dengan perangkat lunak terminal, dan di sisi lain membuat klien soket web yang melihat keluar ke arah host tempat tes dijalankan.

Di sisi uji otomatis, Anda perlu menerapkan server soket web yang menunggu di awal koneksi klien dari terminal dan mengirimkan perintah yang tidak berubah melalui halaman pengujian ke perangkat lunak terminal. Respons perangkat lunak juga dikirim ke server soket web uji.

Artinya, Anda bisa menggambarkan serangkaian perintah untuk tes pembayaran dalam bentuk JSON, yang secara berturut-turut menggambarkan perintah yang perlu Anda kirim dan respons seperti apa yang menunggu.

Halaman pengujian antarmuka. Menampilkan perintah yang melewatinya.

Dan di mana uang itu?

Tugas teknis yang paling berbahaya adalah mensimulasikan perangkat periferal terminal. Printer tanda terima disimulasikan sepele, printer virtual dibuat dalam OS yang mencetak data ke file. Anda bisa mendapatkan cek ini dari terminal (atau salinannya, dibentuk oleh perangkat lunak terminal itu sendiri) dan mendekodekannya, secara bersamaan memeriksa, misalnya, bahwa semua bidang yang diperlukan ada dalam pemeriksaan ini.

Lebih rumit dengan perangkat yang menerima uang - akseptor tagihan dan akseptor koin. Jelas bahwa jika kita ingin menguji skenario pembayaran, kita perlu meniru kehadiran akseptor tagihan di terminal, mendukung fungsi menerima tagihan, mengembalikan, mensimulasikan berbagai masalah (misalnya, mengembalikan tagihan yang kusut).

Sebagian besar perangkat penerima uang beroperasi menggunakan protokol CashCode NET. Protokol ini mendefinisikan skenario interaksi antara akseptor tagihan dan pengontrol (dalam kasus kami, pengontrol adalah perangkat lunak terminal kami).

Contoh interaksi controller dan validator uang kertas menggunakan protokol CashCode. Dengan frekuensi tertentu, pengontrol meminta status perangkat.

Ukuran minimum dari perintah CashCode adalah 6 byte. Untuk deskripsi perintah, lihat spesifikasi protokol CashCode NET.

Akseptor tagihan standar terhubung ke terminal melalui port COM. Ada utilitas pihak ketiga yang memungkinkan Anda untuk membuat port serial virtual pada mesin, misalnya, VSPE . Bahkan skrip untuk meneruskan port ini melalui koneksi TCP didukung.

Kasus kami lebih sederhana, kami membutuhkan alat yang dapat menempel ke port menggunakan WinAPI dan memiliki antarmuka yang sewenang-wenang, misalnya, stdin / stdout paling sederhana, yang dapat dihubungkan dengan menggunakan SSH.

Tula dalam aliran terpisah berkomunikasi dengan controller melalui port serial dan, jika perlu, meniru situasi menerima yang seharusnya "uang". Juga perlu memiliki semacam kumpulan akun atau penyedia pengujian, pembayaran yang tidak akan diproses secara nyata, tetapi pada suatu saat akan ditolak. Atau, untuk kasus-kasus yang lebih kompleks, uang itu benar-benar diproses, tetapi sampai ke rekening khusus, yang kemudian akan didebet untuk tes pembayaran.

Begitulah siklus uang di alam.

Printer tanda terima (di atas) dan akseptor tagihan (di bawah).

24/7

Perangkat lunak untuk terminal dan ATM harus sangat tahan terhadap berbagai situasi darurat - kurangnya Internet, masalah dengan akseptor tagihan, dll. Karena perangkat lunak seperti itu berjalan pada terminal dengan prioritas dan hak yang sangat tinggi, pada dasarnya memotong semua kontrol OS. Anda tidak bisa hanya menciutkannya atau menutupnya dengan Alt-F4. Perangkat lunak dapat reboot sendiri dan terminal, termasuk. Dalam satu lingkaran. Juga perlu untuk memeriksa skenario yang penuh tekanan seperti itu, misalnya, kurangnya komunikasi dengan pemrosesan pembayaran. Terminal merespons hal ini dengan reboot berkala, Anda perlu memastikannya benar dan benar setiap kali memuat perangkat lunak terminal.

Instalasi dari awal dan perbarui

Perangkat lunak terminal yang diinstal diperbarui secara terpusat menggunakan pemrosesan pembayaran. Memproses rencana untuk memperbarui terminal tertentu dan menentukan profil pembaruan untuknya, yaitu file apa dan dari mana memuat. Untuk memperbarui, perlu melakukan sejumlah prosedur dalam database pemrosesan, dan kemudian memantau terminal. Periksa dengan log bahwa pengunduhan file yang diperlukan telah dimulai dan bahwa pembaruan telah berhasil diselesaikan dan perangkat lunak terminal telah meningkat.

Instalasi yang bersih dari awal lebih sulit. Biasanya, seseorang melakukannya di bidang dengan hanya menyalin file instalasi ke terminal dan memasukkan pengaturan dan data otorisasi ke dalam bentuk installer, yang biasanya merupakan aplikasi WinAPI dengan pengontrol Windows standar (TextBox, CheckBox, dll.).

Dalam autotest kami untuk skrip instalasi yang bersih, skrip Python dilampirkan ke terminal, tempat pemasang memulai, berinteraksi dengan pengendali dengan pustaka pywinauto dan menulis log instalasi sendiri. Setelah tahap pertama instalasi selesai, skrip berakhir, dan perangkat lunak terminal melewati otorisasi dalam pemrosesan, menerima jalur ke profil instalasi, dan mengunduh semua file yang diperlukan. Di sini, secara real time, Anda perlu memonitor log pada terminal melalui SSH. Semua situasi abnormal selama instalasi (misalnya, data otorisasi yang salah) ditulis untuk itu, Anda perlu membaca log ini secara online dan, jika perlu, menganggap tes instalasi bersih gagal.

Bersihkan instalasi dari awal MarATL

Kesimpulan

Kami meninjau ikhtisar aspek teknis utama pembuatan autotest untuk perangkat lunak terminal. Tanpa menyelam jauh ke dalam teknologi, kami memilah-milah tugas besar menjadi aspek-aspek terpisah. Ajukan pertanyaan dalam komentar, jika topiknya menarik, Anda dapat menyorot beberapa poin dalam artikel terpisah secara lebih rinci. Terimakasih atas perhatiannya!

Terminal pengujian perangkat lunak otomasi QIWI