Di masa lalu, kami hanya memiliki beberapa layanan, dan melakukan pembaruan lebih dari satu di produksi dalam sehari adalah
sukses besar. Kemudian dunia dipercepat, sistem menjadi lebih kompleks, dan kami bertransformasi menjadi organisasi dengan arsitektur layanan mikro. Sekarang kami memiliki sekitar seratus layanan, dan dengan peningkatan jumlah mereka, frekuensi rilis juga meningkat - lebih dari 250 per minggu.
Dan jika fitur baru diuji di dalam tim produk, maka tugas tim pengujian integrasi adalah untuk memverifikasi bahwa perubahan yang disertakan dalam rilis tidak merusak fungsionalitas komponen, sistem, dan fitur lainnya.
Saya bekerja sebagai insinyur pengujian otomasi di Yandex.Money.
Pada artikel ini, saya akan berbicara tentang evolusi pengujian integrasi layanan web, serta tentang mengadaptasi proses untuk meningkatkan jumlah komponen sistem dan meningkatkan frekuensi rilis.
Tentang perubahan dalam siklus rilis dan pengembangan mekanisme perhitungan dijelaskan oleh ops dan dev di
salah satu artikel sebelumnya . Saya akan memberi tahu Anda tentang riwayat perubahan dalam proses pengujian selama transformasi ini.
Sekarang kami memiliki sekitar 30 tim pengembangan. Tim biasanya mencakup manajer produk, manajer proyek, pengembang dan penguji front-end dan back-end. Mereka disatukan oleh pekerjaan pada tugas untuk produk tertentu. Untuk layanan, sebagai suatu peraturan, tim bertanggung jawab, yang paling sering melakukan perubahan padanya.
Pengujian penerimaan ujung-ke-ujung
Belum lama berselang, dengan dirilisnya masing-masing komponen, hanya pengujian unit dan komponen yang dijalankan, dan setelah itu hanya beberapa skrip ujung-ke-ujung yang paling penting dijalankan pada lingkungan pengujian yang lengkap sebelum memasukkan layanan ke dalam produksi. Seiring dengan peningkatan jumlah komponen, jumlah koneksi di antara mereka mulai tumbuh secara eksponensial. Seringkali - koneksi yang sepenuhnya non-sepele. Saya ingat bagaimana tidak tersedianya layanan untuk mengeluarkan data pemasaran mematahkan pendaftaran pengguna sepenuhnya (tentu saja, untuk waktu yang singkat).
Pendekatan ini untuk memeriksa perubahan mulai semakin sering gagal - diperlukan untuk mencakup semua skenario bisnis kritis dengan autotest dan menjalankannya pada lingkungan pengujian lengkap dengan versi komponen yang siap untuk dirilis.
Oke, autotes untuk skenario kritis telah muncul - tetapi bagaimana menjalankannya? Ada tugas untuk diintegrasikan ke dalam siklus rilis, minimal mempengaruhi keandalannya dengan tetes uji palsu. Di sisi lain, saya ingin melakukan tahap pengujian integrasi secepat mungkin. Jadi ada infrastruktur untuk melakukan tes penerimaan.
Kami mencoba memaksimalkan penggunaan alat yang sudah digunakan untuk menjalankan komponen pada siklus rilis dan tugas peluncuran: Jira dan Jenkins, masing-masing.
Siklus Pengujian Penerimaan
Untuk melakukan pengujian penerimaan, kami menentukan siklus berikut:
- pemantauan tugas masuk untuk pengujian penerimaan rilis,
- menjalankan pekerjaan Jenkins untuk menginstal rilis yang dibangun di lingkungan pengujian,
- periksa apakah layanan telah meningkat,
- meluncurkan pekerjaan Jenkins dengan tes integrasi,
- analisis hasil pelarian,
- uji coba berulang (jika perlu),
- memperbarui status tugas - selesai atau rusak, menunjukkan alasan dalam komentar.
Seluruh siklus dilakukan secara manual setiap kali. Sebagai hasilnya, sudah pada rilis kesepuluh sehari, saya ingin bersumpah untuk melakukan tugas yang sama, paling banter, seraya mencengkeram kepala dan menuntut
bir valerian.
Monitor Bot
Kami menyadari bahwa melacak dan melaporkan tugas baru di Jira adalah proses penting yang cepat dan mudah diotomatisasi. Jadi ada bot yang melakukan ini.
Data untuk menghasilkan peringatan datang dalam bentuk pemberitahuan push dari Jira. Setelah meluncurkan bot, kami berhenti memperbarui halaman dasbor dengan tugas penerimaan, dan lebar senyum automaton sedikit meningkat.
Pinger
Kami memutuskan untuk menyederhanakan verifikasi bahwa selama penyebaran di lingkungan pengujian tidak terjadi kesalahan pemasangan atau pemasangan dan bahwa versi komponen yang diinginkan dinaikkan, dan bukan yang lain. Komponen memberikan versi dan statusnya melalui HTTP. Dan memeriksa apakah layanan mengembalikan versi yang benar akan sederhana dan dapat dimengerti jika komponen yang berbeda tidak ditulis dalam bahasa yang berbeda - beberapa di Node.js, beberapa di C #. Selain itu, layanan kami yang paling populer di Jawa, juga memberikan versi dalam format yang berbeda.
Plus, saya ingin memiliki informasi waktu nyata dan pemberitahuan tidak hanya tentang perubahan versi, tetapi juga tentang perubahan ketersediaan komponen dalam sistem. Untuk mengatasi masalah ini, layanan Pinger muncul, yang mengumpulkan informasi tentang status dan versi komponen dengan polling mereka secara siklis.
Kami menggunakan model push pengiriman pesan - agen digunakan pada setiap contoh lingkungan pengujian, yang mengumpulkan informasi tentang komponen-komponen lingkungan ini dan menyimpan data pada node pusat setiap 10 detik. Kami pergi ke simpul ini untuk status saat ini - pendekatan ini memungkinkan kami untuk mendukung lebih dari seratus tegakan uji.
Locker
Waktunya telah tiba untuk tugas yang lebih kompleks - pembaruan otomatis komponen dan menjalankan tes. Pada saat itu, tim kami sudah memiliki 3 bangku tes di OpenStack untuk tes penerimaan, dan pertama-tama perlu untuk memecahkan masalah mengelola sumber daya bangku tes: akan tidak menyenangkan jika pembaruan rilis berikutnya "gulungan" ketika menjalankan tes pada sistem. Itu juga terjadi bahwa bangku tes debugged, dan kemudian Anda tidak boleh menggunakannya untuk penerimaan.
Saya ingin dapat melihat status pekerjaan dan, jika perlu, mengunci dudukan secara manual selama analisis tes yang jatuh atau sampai menyelesaikan pekerjaan lain.
Untuk semua ini, layanan Locker telah muncul. Ini mempertahankan status bangku tes untuk waktu yang lama ("sibuk" / "gratis"), memungkinkan Anda untuk menentukan komentar pada "sibuk", sehingga jelas bahwa kita sekarang sedang melakukan debug, menciptakan kembali salinan lingkungan pengujian atau menjalankan tes untuk rilis berikutnya. Kami juga mulai memblokir dudukan pada malam hari - pada mereka administrator melakukan pekerjaan sesuai jadwal, seperti cadangan dan sinkronisasi basis data.
Saat memblokir, waktu selalu ditentukan setelah kuncinya kedaluwarsa - sekarang orang tidak perlu berpartisipasi dalam mengembalikan tegakan ke kolam yang tersedia, dan mesin melakukan semuanya.
Tugas
Untuk mendistribusikan beban secara merata di antara anggota tim untuk menganalisis hasil uji coba, kami menghasilkan giliran kerja harian. Petugas bekerja dengan tugas-tugas pengujian penerimaan rilis, mem-parsing autotest jatuh dan melaporkan bug. Jika petugas memahami bahwa ia tidak mengatasi aliran tugas, ia dapat meminta bantuan tim. Pada saat ini, anggota tim lainnya terlibat dalam tugas-tugas yang tidak terkait dengan rilis.
Dengan meningkatnya jumlah rilis, peran petugas kedua muncul, yang terhubung ke yang utama jika ada penyumbatan atau ada rilis penting dalam antrian. Untuk memberikan informasi tentang perkembangan rilis pengujian, kami membuat halaman dengan jumlah tugas di status "terbuka" / "berlari" / "menunggu respons bertugas", status blok uji coba dan komponen yang tidak dapat diakses di tribun:
Pekerjaan petugas jaga membutuhkan konsentrasi, sehingga ia memiliki roti - pada hari tugas, ia dapat memilih tempat untuk makan siang untuk seluruh tim di dekat kantor. Suap yang bertugas dalam gaya terlihat sangat menyenangkan: "izinkan saya membantu Anda menyelesaikan tugas, dan hari ini kita akan pergi ke tempat favorit
saya " =)
Reporter
Salah satu tugas yang kami temui ketika kami memperkenalkan arloji adalah kebutuhan untuk mentransfer pengetahuan dari satu petugas ke petugas lainnya, misalnya, tentang tes yang jatuh pada rilis baru atau spesifik memperbarui komponen.
Selain itu, kami memiliki fitur kerja baru.
- Ada kategori tes yang jatuh dengan frekuensi yang lebih besar atau lebih kecil karena masalah dengan bangku tes. Falls dapat terjadi karena peningkatan waktu respons salah satu layanan atau pemuatan sumber daya yang lama di browser. Saya tidak ingin mematikan tes; cara yang masuk akal untuk meningkatkan keandalannya telah habis.
- Kami memiliki proyek eksperimental kedua dengan autotest, dan perlu muncul untuk menganalisis jalannya dua proyek sekaligus, melihat laporan Allure.
- Uji coba dapat memakan waktu hingga 20 menit, dan Anda ingin mulai menganalisis hasilnya segera setelah awal tetes pertama. Terutama jika tugasnya sangat penting dan anggota tim yang bertanggung jawab untuk pembebasan berdiri di belakang Anda
, memegang pisau ke tenggorokan dengan mata menyedihkan.
Ini adalah bagaimana layanan Reporter muncul. Di dalamnya kami mendorong hasil uji coba secara real time selama proses pengujian. Layanan ini memiliki basis data masalah yang diketahui atau bug yang terkait dengan tes tertentu. Juga, publikasi diterbitkan di portal wiki perusahaan dari laporan ringkasan tentang hasil pelarian dari reporter. Ini nyaman bagi manajer yang tidak ingin menyelami detail teknis yang dipenuhi oleh antarmuka Reporter atau Allure.
Jika tes macet, Anda dapat melihat Reporter untuk daftar bug terkait atau memperbaiki tugas. Informasi tersebut mempersingkat waktu penguraian dan memfasilitasi pertukaran pengetahuan tentang masalah antara anggota tim kami. Catatan tugas yang sudah selesai diarsipkan, tetapi jika perlu, Anda dapat "mengintip" ke daftar yang terpisah. Agar tidak memuat layanan internal selama jam kerja, kami mewawancarai Jira di malam hari dan mengarsipkan entri untuk masalah dengan status akhir.
Bonus dari pengenalan Reporter adalah munculnya database yang dijalankan, atas dasar yang Anda dapat menganalisis frekuensi jatuh, peringkat tes sesuai dengan tingkat stabilitas atau "kegunaan" dalam hal jumlah bug yang ditemukan.
Autorun
Selanjutnya, kami pindah ke mengotomatiskan peluncuran tes ketika masalah pengujian penerimaan rilis datang ke pelacak masalah. Untuk tujuan ini, layanan Autorun ditulis, yang memeriksa apakah ada tugas penerimaan baru di Jira, dan jika demikian, itu menentukan nama komponen dan versinya berdasarkan pada isi tugas.
Untuk tugas itu, beberapa langkah dilakukan:
- ambil kunci salah satu bangku tes gratis di layanan Locker,
- mulai instalasi komponen yang diperlukan dalam Jenkins, tunggu sampai komponen muncul dengan versi yang diperlukan,
- jalankan tes
- menunggu selesainya uji coba, dalam proses pelaksanaannya semua hasil didorong ke dalam Reporter,
- kami meminta Reporter untuk jumlah tes gagal, tidak termasuk yang gagal karena masalah yang diketahui,
- jika 0 jatuh - kami mentransfer tugas untuk pengujian penerimaan ke "Selesai" dan selesai bekerja dengannya. Semuanya sudah siap =)
- jika ada tes "merah" - kami menerjemahkan tugas ke "Menunggu" dan buka Reporter untuk menguraikannya.
Pergantian antar tahapan diatur oleh prinsip mesin keadaan terbatas. Setiap tahap itu sendiri mengetahui kondisi untuk transisi ke tahap berikutnya. Hasil tahap disimpan dalam konteks tugas, yang umum untuk tahap satu tugas.
Semua ini memungkinkan Anda untuk mentransfer rilis secara otomatis di sepanjang pipa penyebaran, yang menurutnya 100 persen tesnya berwarna hijau. Tetapi bagaimana dengan ketidakstabilan yang disebabkan bukan oleh masalah pada komponen, tetapi oleh fitur "alami" dari tes UI atau oleh peningkatan keterlambatan jaringan di bangku tes?
Untuk melakukan ini, kami telah menerapkan mekanisme coba lagi, yang digunakan banyak orang, tetapi hanya sedikit yang mengenalinya. Retrays diatur sebagai serangkaian uji dalam Pipa Jenkins.
Setelah menjalankan, kami meminta daftar tes gagal dari Reporter dari Jenkins - dan memulai kembali yang gagal saja. Selain itu, kami mengurangi jumlah utas saat startup. Jika jumlah tes yang dijatuhkan tidak berkurang dibandingkan dengan pelaksanaan sebelumnya, kami segera mengakhiri Pekerjaan. Dalam kasus kami, pendekatan untuk memulai kembali ini memungkinkan kami untuk meningkatkan keberhasilan pengujian penerimaan sekitar 2 kali.
Blok cepat
Sistem pengujian penerimaan yang dihasilkan memungkinkan kami untuk melakukan lebih dari 60% rilis tanpa campur tangan manusia. Tapi apa yang harus dilakukan dengan yang lain? Jika perlu, petugas membuat laporan bug pada komponen yang diuji atau tugas memperbaiki tes ke tim pengembangan. Kadang-kadang - membuat bug konfigurasi bangku tes ke departemen operasi.
Tugas-tugas untuk mengoreksi tes seringkali menghalangi jalan yang benar dari pengujian otomatis, karena tes yang tidak relevan akan selalu "merah". Penguji dari tim pengembangan bertanggung jawab untuk menulis tes baru dan memperbarui yang sudah ada - membuat perubahan melalui permintaan tarik ke proyek dengan tes otomatis. Pengeditan ini tunduk pada tinjauan wajib, yang memerlukan beberapa waktu dari peninjau dan dari penulis, dan saya ingin untuk sementara waktu memblokir tes yang tidak relevan sampai tugas diterjemahkan ke status akhir mereka.
Pertama, kami menerapkan mekanisme mematikan berdasarkan anotasi metode pengujian. Selanjutnya, ternyata karena adanya tinjauan kode wajib, pemblokiran dari kode tidak selalu nyaman dan mungkin memakan waktu lebih lama dari yang kita inginkan.
Karena itu, kami memindahkan daftar tugas yang memblokir tes ke layanan baru dengan halaman web - Blok cepat. Jadi anggota tim yang bertanggung jawab atas komponen dapat dengan cepat memblokir tes. Sebelum menjalankan, kami pergi ke layanan ini dan mendapatkan daftar tes karantina, yang kami terjemahkan ke dalam status yang dilewati.
Ringkasan
Kami telah beralih dari penerimaan rilis dalam mode manual ke proses yang hampir sepenuhnya otomatis, yang dapat melakukan melalui pengujian penerimaan lebih dari 50 rilis per hari. Ini membantu perusahaan mengurangi waktu yang diperlukan untuk mengirim perubahan, dan tim kami dapat menemukan sumber daya untuk bereksperimen dan mengembangkan alat pengujian.
Di masa depan kami berencana untuk meningkatkan keandalan proses, misalnya, dengan mendistribusikan permintaan antara sepasang contoh dari setiap layanan dari daftar di atas. Ini akan memungkinkan Anda untuk memperbarui alat tanpa downtime dan menyertakan fitur baru hanya untuk sebagian dari tes penerimaan. Selain itu, kami memperhatikan untuk menstabilkan tes sendiri. Dalam pengembangan, generator tiket untuk tes refactoring dengan tingkat keberhasilan terendah.
Meningkatkan keandalan tes tidak hanya akan meningkatkan kepercayaan diri pada mereka, tetapi juga mempercepat pengujian rilis karena kurangnya restart skrip yang jatuh.