Kata pengantar
Ekosistem pembayaran Mir Plat.Form mencakup beberapa lusin sistem, yang sebagian besar berinteraksi satu sama lain menggunakan berbagai protokol dan format. Kami, tim Pengujian Integrasi, memverifikasi bahwa interaksi ini memenuhi persyaratan yang ditetapkan.
Saat ini, tim bekerja dengan 13 misi dan sistem penting bisnis. Sistem kritis misi memastikan bahwa Mir Plat.Form menjalankan fungsi utamanya, memastikan stabilitas dan kontinuitas sistem kartu perbankan Rusia. Sistem kritis bisnis bertanggung jawab untuk mendukung layanan tambahan yang diberikan kepada klien Mir Plat.form, yang menjadi tempat bergantung aktivitas operasional langsung perusahaan. Frekuensi peluncuran rilis ke PROD bervariasi dari sekali seminggu hingga satu kuartal sekali, semuanya tergantung pada sistem dan kesiapan peserta untuk frekuensi update. Secara total, kami menghitung sekitar 200 rilis yang melalui tim kami tahun lalu.
Matematika sederhana mengatakan yang berikut: jumlah rantai yang diuji adalah N-sistem * M-integrasi di antara mereka * K-rilis. Bahkan menggunakan contoh versi rilis 13 sistem * 11 integrasi * 27, ada sekitar 3.861 kemungkinan opsi kompatibilitas sistem. Jawabannya tampaknya jelas - tes otomatis? Tetapi masalahnya sedikit lebih serius, hanya autotest yang tidak akan menyelamatkan Anda. Mengingat semakin banyaknya sistem dan integrasinya, dan frekuensi rilis yang bervariasi, selalu ada risiko pengujian rantai versi sistem yang salah. Oleh karena itu, ada risiko kehilangan cacat dalam interaksi antar sistem, misalnya, memengaruhi pengoperasian sistem pembayaran (PS) Mir yang benar.
Biasanya, bug semacam itu tidak dapat diterima di PRODA, dan tugas tim kami adalah mengurangi risiko ini menjadi nol. Jika Anda ingat teks di atas, "bersin" tidak hanya memengaruhi sistem internal Mir Plat.form, tetapi juga pelaku pasar: bank, pedagang, individu, dan bahkan sistem pembayaran lainnya. Oleh karena itu, untuk menghilangkan risiko tersebut, kami menempuh cara berikut:
- Memperkenalkan basis rilis terpadu. Untuk tugas ini, kalender rilis di Confluence sudah cukup, menunjukkan versi sistem yang diinstal di PROD;
- Kami melacak rantai integrasi sesuai dengan tanggal rilis. Di sini kami juga tidak mulai menemukan kembali roda, kami akan membutuhkannya lebih lanjut. Untuk mengatasi masalah ini, kami menggunakan struktur Epic di JIRA untuk pengujian integrasi rilis. Contoh struktur untuk rilis 1.111.0 dari System3:
Di satu sisi, semua tindakan ini membantu meningkatkan pemahaman tim tentang integrasi yang diuji, versi sistem, dan urutan rilisnya di PROD. Di sisi lain, masih ada kemungkinan pengujian yang salah karena faktor manusia:
- Jika tanggal rilis sistem mana pun telah dipindahkan, maka anggota tim perlu mengoreksi kalender secara manual dan seluruh struktur di JIRA, termasuk tenggat waktu untuk menyelesaikan tugas dan, mungkin, versi sistem yang diuji;
- Sebelum menguji integrasi, Anda perlu memastikan bahwa lingkungan pengujian terdiri dari versi sistem yang benar. Untuk melakukan ini, Anda perlu memeriksa bangku tes secara manual dan menjalankan beberapa perintah konsol.
Selain itu, pekerjaan rutin tambahan telah muncul, terkadang menyita sebagian besar waktu.
Menjadi jelas bahwa proses persiapan untuk pengujian integrasi rilis perlu diotomatisasi dan, jika mungkin, digabungkan menjadi satu antarmuka. Di sinilah sepeda penyelamat kami hadir: Sistem Pemantauan Pengujian Integrasi atau hanya SMIT.
Opsi apa yang ingin Anda terapkan dalam sistem yang sedang dikembangkan?
1. Kalender rilis yang jelas dengan kemampuan untuk menampilkan versi dari semua sistem untuk tanggal tertentu;
2. Lingkungan pemantauan untuk pengujian integrasi:
- daftar lingkungan;
- tampilan visual bangku uji dan sistem yang merupakan bagian dari lingkungan terpisah;
- kontrol versi sistem yang digunakan di bangku uji.
3. Pekerjaan otomatis dengan tugas di Jira:
- membuat struktur rilis Epic;
- manajemen siklus hidup tugas pengujian;
- memperbarui tugas jika terjadi pergeseran pada tanggal rilis;
- memasukkan laporan daya pikat ke dalam tugas pengujian.
4. Pekerjaan otomatis dengan cabang di Bitbucket, yaitu pembuatan cabang rilis dalam proyek:
- autotests integrasi;
- pemanasan otomatis lingkungan integrasi.
5. UI yang intuitif untuk menjalankan tes otomatis dan memperbarui versi sistem.
Apa itu SMITH
Karena sistemnya tidak rumit, kami tidak menjadi terlalu pintar dengan teknologi. Backend ditulis dalam Java menggunakan Spring Boot. Bagian depannya adalah React. Tidak ada persyaratan khusus untuk database, jadi kami memilih MySql. Karena merupakan kebiasaan bagi kita untuk bekerja dengan container, semua komponen di atas dibungkus dalam Docker, dibuat dengan Docker Compose. SMITH bekerja dengan cepat dan andal seperti sistem Formulir Mir Plat lainnya.
Integrasi
- Atlassian Jira. Di jir, tugas untuk menguji setiap integrasi tertentu dibuat, dibuka, dikerjakan dan ditutup, jika semua tes berhasil, tautan ke laporan daya pikat dilampirkan di komentar.
- Atlassian BitBucket. , , / . “” , .
- Jenkins. Jenkins, . , , glue Cucumber.
- . . ssh.
Sebelum Anda dapat mengelola kalender dan memantau keadaan lingkungan di SMIT, Anda perlu membuat daftar sistem yang diuji dan hubungan di antara mereka. Semua pengaturan dapat dilakukan melalui antarmuka web:
Setelah menambahkan sistem yang diuji ke daftar SMIT:
- Akan "mengetuk" semua host sistem bernama SYS_CMD dalam daftar lingkungan;
- mencari tahu versi sistem ini menggunakan perintah yang ditentukan dalam konfigurasi;
- akan menulis ke database-nya versi saat ini dari sistem ini dan lingkungan tempat kemunculannya.
Akibatnya, SMIT akan berisi informasi tentang semua sistem yang digunakan di lingkungan yang digunakan, termasuk nomor versinya. Berdasarkan informasi ini, Anda dapat memvisualisasikan kalender rilis.
Kalender rilis
Setelah pemilik sistem atau pimpinan tim dari tim pengembangan produk memberi tahu kami tanggal pemasangan rilis baru di PROD, kami mendaftarkan rilis ini di kalender. Ternyata inilah gambarannya:
Anda dapat dengan mudah melihat konflik di mana beberapa rilis dipasang sekaligus dalam beberapa hari dan "panas" dimungkinkan. Pemilik produk diberi tahu tentang konflik ini, karena sangat berbahaya memasang beberapa versi sistem baru pada hari yang sama.
Juga pada halaman dengan kalender terdapat fungsi untuk menampilkan versi dari semua sistem untuk tanggal tertentu:
Perlu dicatat bahwa ketika mendaftarkan rilis baru di kalender, SMIT secara otomatis membuat struktur Epic di Jira dan melepaskan cabang dalam proyek di Bitbucket.
Keadaan lingkungan
Fungsi lain yang sangat mudah dari SMITH adalah untuk melihat keadaan lingkungan tertentu saat ini. Di halaman ini Anda dapat menemukan daftar sistem yang termasuk dalam lingkungan dan relevansi versinya.
Seperti yang Anda lihat di tangkapan layar, SMITH menemukan versi Sistem 4 yang kedaluwarsa di host-4.nspk.ru dan menawarkan untuk memperbaruinya. Jika Anda menekan tombol merah dengan panah putih, maka SMITH akan memanggil tugas Jenkins untuk menerapkan versi sistem saat ini di lingkungan saat ini. Dimungkinkan juga untuk memperbarui semua sistem setelah menekan tombol yang sesuai.
Lingkungan Pengujian Integrasi
Perlu diceritakan sedikit tentang bagaimana kami mendefinisikan lingkungan pengujian. Satu lingkungan adalah satu set stand dengan sistem Mir Plat.form yang diterapkan dan integrasi yang disesuaikan (satu sistem pada satu stand). Secara total, kami memiliki 70 stand, dibagi menjadi 12 lingkungan.
Dalam proyek pengujian otomatis integrasi, kami memiliki file konfigurasi tempat penguji menyetel lingkungan pengujian. Struktur file terlihat seperti ini:
{
"properties":{
"comment":" system property Environment. property, , System.getProperties()",
"common.property":"some global property"
},
"environments":[
{
"comment":" name, Environment common + . common1",
"name":"env_1",
"properties":{
"comment":" system property Environment. property. , System.getProperties()",
"env1.property":"some personal property"
},
"DB":{
"comment":" TestResource' DbTestResource. id, ",
"url":"jdbc:mysql://11.111.111.111:3306/erouter?useUnicode=yes&characterEncoding=UTF-8&useSSL=false",
"driver":"com.mysql.jdbc.Driver",
"user":"fo",
"password":"somepass"
},
"SYS_CMD":{
"comment":" TestResource' RemoteExecCmd. type = remote",
"type":"remote",
"host":"10.111.111.111",
"username":"user",
"password":"somepass"
}
}
]
}Selain fakta bahwa file ini diperlukan agar proyek autotest integrasi berfungsi, ini juga merupakan file konfigurasi tambahan untuk SMIT. Ketika Anda meminta untuk memperbarui informasi tentang lingkungan di SMIT, permintaan HTTP dikirim ke API bitbucket kami, tempat kami menyimpan proyek dengan autotests integrasi. Dengan cara ini, SMITH mendapatkan konten file konfigurasi saat ini dari cabang master.
Menjalankan tes
Salah satu tujuan pembuatan SMIT adalah untuk menyederhanakan prosedur peluncuran autotest integrasi sebanyak mungkin. Mari kita pertimbangkan apa yang akhirnya kita dapatkan dengan menggunakan contoh:
Pada halaman pengujian sistem (dalam contoh ini, Sistem 3), Anda dapat memilih daftar sistem yang ingin Anda periksa integrasinya. Setelah memilih integrasi yang diperlukan dan mengklik tombol "Mulai Pengujian", SMITH:
1. Membentuk antrian dan secara berurutan meluncurkan tugas Jenkins yang sesuai;
2. memantau pelaksanaan pekerjaan;
3. mengubah status masalah terkait di Jira:
- Jika pekerjaan telah berhasil diselesaikan, tugas di Jira akan ditutup secara otomatis, tautan ke laporan daya tarik dan komentar akan dilampirkan padanya bahwa tidak ada cacat yang ditemukan dalam integrasi ini.
- Jika pekerjaan gagal, tugas di Jira akan tetap terbuka dan akan menunggu keputusan dari karyawan yang bertanggung jawab atas integrasi, yang akan dapat menentukan penyebab kegagalan pengujian. Orang yang bertanggung jawab atas integrasi dapat dilihat di kartu integrasi.
Keluaran
SMITH diciptakan untuk meminimalkan risiko pengujian integrasi, tetapi sebagai tim kami menginginkan lebih! Secara khusus, salah satu keinginannya adalah dengan satu klik tombol, autotests diluncurkan dengan lingkungan pengujian yang benar, semuanya diperiksa dalam kecocokan integrasi yang diperlukan, dan tugas di Jira dibuka dan ditutup bersama dengan laporan. Utopia penguji otomatis seperti itu: beri tahu sistem apa yang harus diperiksa - dan pergi dan minum kopi :)
Mari kita rangkum apa yang berhasil kami terapkan:
- Kalender rilis visual dengan kemampuan untuk menampilkan versi dari semua sistem pada tanggal tertentu;
- UI , , ;
- ;
- UI ;
- Epic Task Jira, Allure ;
- Bitbucket.
Saat ini, sistem sedang menjalani pengujian beta tertutup di antara anggota langsung tim pengujian integrasi. Ketika semua cacat yang ditemukan dieliminasi dan sistem menjalankan fungsinya secara stabil, kami akan membuka akses ke karyawan tim terkait dan pemilik produk sehingga mereka dapat menjalankan pengujian dan mempelajari hasilnya secara mandiri.
Jadi, dalam skenario yang ideal, semua yang perlu dilakukan untuk memverifikasi bahwa sistem memenuhi persyaratan integrasi adalah pergi ke antarmuka web SMIT, perbarui sistem yang diperlukan melaluinya, pilih semua kotak centang dan jalankan tes, dan kemudian periksa apakah semuanya telah diselesaikan dengan sukses. Tugas akan dibuat secara otomatis, laporan daya pikat akan diisi, status terkait akan ditetapkan ke tugas ini.