Tes unit dalam DBMS - bagaimana kami melakukannya di Sportmaster, bagian dua

Bagian pertama - di sini.

Bayangkan sebuah situasi. Anda dihadapkan pada tugas mengembangkan fungsionalitas baru. Anda memiliki pengalaman dari pendahulu Anda. Dengan asumsi bahwa Anda tidak memiliki kewajiban moral, apa yang akan Anda lakukan?

Paling sering, semua perkembangan lama dilupakan dan semuanya dimulai dari awal lagi. Tidak ada yang suka menggali kode orang lain, dan jika Anda punya waktu, mengapa tidak mulai membuat sistem Anda sendiri? Ini adalah pendekatan tipikal, dan dalam banyak hal memang benar. Tetapi dalam proyek kami, kami bertindak berbeda. Kami mendasarkan sistem pengujian otomatis masa depan pada pengembangan pengujian unit pada utPLSQL dari pendahulu kami, dan kemudian mulai bekerja dalam beberapa arah paralel.

1. Mengembalikan tes unit lama. Pemulihan berarti adaptasi pengujian ke status sistem loyalitas yang ada dan adaptasi pengujian ke standar utPLSQL.
2. Memecahkan masalah dengan pemahaman, dan apa sebenarnya, metode dan proses apa, telah kita bahas dengan autotest. Anda harus menyimpan informasi ini di kepala Anda, atau menarik kesimpulan langsung berdasarkan kode tes otomatis. Oleh karena itu, kami memutuskan untuk membuat katalog. Kami menetapkan kode mnemonik unik untuk setiap pengujian otomatis, membuat deskripsi, dan memperbaiki pengaturan (misalnya, dalam kondisi apa pengujian harus dijalankan, atau apa yang harus terjadi jika pengujian gagal). Intinya, kami mengisi metadata tentang tes otomatis dan menempatkan metadata ini di tabel standar skema utPLSQL.
3. Definisi strategi ekspansi, yaitu. pemilihan fungsionalitas yang tunduk pada verifikasi oleh tes otomatis. Kami memutuskan untuk memperhatikan tiga hal: peningkatan baru pada sistem, insiden dari produksi, dan proses utama sistem. Jadi, kami mengembangkan secara paralel dengan rilis, memastikan kualitasnya yang lebih tinggi, sekaligus memperluas cakupan regresi dan memastikan keandalan sistem di tempat-tempat kritis. Kemacetan pertama adalah proses pendistribusian diskon dan bonus melalui cek.
4. Secara alami, kami mulai mengembangkan tes otomatis baru. Salah satu tugas rilis pertama adalah mengevaluasi kinerja sampel yang telah ditentukan sebelumnya dari sistem loyalitas. Proyek kami memiliki blok kueri sql yang diperbaiki secara kaku yang memilih klien sesuai dengan kondisi. Misalnya, dapatkan daftar semua pelanggan yang pembelian terakhirnya berada di kota tertentu, atau daftar pelanggan yang jumlah pembelian rata-ratanya di atas nilai tertentu. Setelah menulis tes otomatis, kami memeriksa sampel yang telah ditentukan sebelumnya, memperbaiki parameter kinerja tolok ukur, dan selain itu kami mendapat pengujian beban.
5. Bekerja dengan tes otomatis seharusnya nyaman. Dua tindakan paling umum adalah menjalankan uji otomatis dan menghasilkan data uji. Beginilah dua modul tambahan muncul di sistem kami: modul peluncuran dan modul pembuatan data.

   Peluncur direpresentasikan sebagai satu prosedur umum dengan satu parameter teks masukan. Sebagai parameter, Anda dapat memberikan kode mnemonik uji otomatis, nama paket, nama uji, pengaturan uji otomatis, atau kata kunci yang dicadangkan. Prosedur memilih dan menjalankan semua uji otomatis yang memenuhi persyaratan.

   Modul pembuatan data disajikan sebagai paket, di mana untuk setiap objek sistem yang diuji (tabel dalam database), telah dibuat prosedur khusus yang memasukkan data ke dalamnya. Dalam prosedur ini, nilai default diisi secara maksimal, yang memastikan pembuatan objek secara harfiah dengan mengklik satu jari. Dan untuk kemudahan penggunaan, template untuk data yang dihasilkan telah dibuat. Misalnya, buat klien dengan usia tertentu dengan telepon percobaan dan pembelian yang diselesaikan.

6. Tes otomatis harus berjalan dan berjalan dalam waktu yang wajar untuk sistem Anda. Oleh karena itu, peluncuran malam harian diselenggarakan, berdasarkan hasil laporan hasil dibuat dan dikirim ke seluruh tim pengembangan melalui surat perusahaan. Setelah memulihkan tes otomatis lama dan membuat yang baru, total waktu berjalan adalah 30 menit. Performa seperti itu cocok untuk semua orang, karena peluncuran dilakukan di luar jam kerja.

   Tetapi kami harus bekerja untuk mengoptimalkan kecepatan kerja. Sistem loyalitas produksi diperbarui pada malam hari. Sebagai bagian dari salah satu rilis, kami harus segera melakukan perubahan di malam hari. Setengah jam menunggu hasil tes otomatis pada pukul tiga pagi tidak membuat orang yang bertanggung jawab atas rilis tersebut bahagia (salam hangat untuk Alexei Vasyukov!), Dan keesokan paginya banyak kata-kata hangat diucapkan terhadap sistem kami. Namun sebagai hasilnya, standar kerja 5 menit ditetapkan.

   Untuk mempercepat kinerja, kami menggunakan dua metode: kami mulai menjalankan uji otomatis dalam tiga utas paralel, karena ini sangat nyaman karena arsitektur sistem loyalitas kami. Dan kami meninggalkan pendekatan ketika pengujian otomatis tidak membuat data pengujian untuk dirinya sendiri, tetapi mencoba menemukan sesuatu yang cocok di sistem. Setelah melakukan perubahan, total waktu pengoperasian dikurangi menjadi 3-4 menit.

7. Proyek dengan uji otomatis harus dapat diterapkan di berbagai stan. Di awal perjalanan, ada upaya untuk menulis file batch kami sendiri, tetapi menjadi jelas bahwa penginstalan otomatis yang ditulis sendiri benar-benar mengerikan, dan kami beralih ke solusi industri. Karena proyek memiliki banyak kode secara langsung (pertama-tama, kami menyimpan kode tes otomatis) dan sangat sedikit data (data utama adalah metadata tentang tes otomatis), ternyata sangat mudah untuk diintegrasikan ke dalam Proyek Liquibase.

   Ini adalah pustaka independen basis data sumber terbuka untuk melacak, mengelola, dan menerapkan perubahan skema basis data. Dikelola melalui baris perintah atau kerangka kerja seperti Apache Maven. Prinsip pengoperasian Liquibase cukup sederhana. Kami memiliki proyek yang diatur dengan cara tertentu, yang terdiri dari perubahan atau skrip yang perlu diluncurkan ke server target, dan file kontrol yang menentukan dalam urutan apa dan dengan parameter apa perubahan ini harus diinstal.

   Pada tingkat DBMS, tabel khusus dibuat di mana Liquibase menyimpan log rollback. Setiap perubahan memiliki hash terhitung yang dibandingkan setiap kali antara proyek dan status dalam database. Berkat Liquibase, kami dapat dengan mudah meluncurkan perubahan pada sistem kami ke sirkuit mana pun. Tes otomatis sekarang dijalankan pada loop pengujian dan rilis, serta pada kontainer (loop pribadi pengembang).

Jadi, mari kita bicara tentang hasil penerapan sistem pengujian unit kami.

1. Tentu saja, pertama-tama, kami yakin bahwa kami mulai mengembangkan perangkat lunak yang lebih baik. Tes otomatis berjalan setiap hari dan temukan lusinan bug setiap rilis. Selain itu, beberapa dari kesalahan ini hanya terkait secara tidak langsung dengan fungsionalitas yang benar-benar ingin kami ubah. Ada keraguan kuat bahwa kesalahan ini ditemukan dengan pengujian manual.
2. Tim memperoleh keyakinan bahwa fungsi tertentu berfungsi dengan benar... Pertama-tama, ini menyangkut proses kritis kami. Misalnya, selama enam bulan terakhir, kami tidak mengalami masalah dengan pendistribusian diskon dan bonus melalui cek, meskipun ada perubahan yang dilakukan setiap rilis, meskipun pada periode sebelumnya terjadi kesalahan dengan frekuensi tertentu.
3. Kami berhasil mengurangi jumlah iterasi pengujian. Karena tes otomatis ditulis untuk fungsionalitas baru, analis dan penguji paruh waktu mendapatkan kode dengan kualitas lebih tinggi, karena itu sudah diverifikasi.
4. Bagian dari pengembangan pengujian otomatis digunakan oleh pengembang. Misalnya, data pengujian pada kontainer dibuat menggunakan modul pembuatan objek.
5. Penting bagi kami untuk mengembangkan "penerimaan" sistem pengujian otomatis oleh pengembang. Ada pemahaman bahwa ini penting dan bermanfaat. Dan dari pengalaman saya sendiri, saya dapat mengatakan bahwa ini jauh dari kasusnya. Tes otomatis perlu ditulis, perlu dipertahankan dan dikembangkan, hasil dianalisis, dan seringkali biaya waktu ini tidak sepadan. Jauh lebih mudah untuk pergi ke produksi dan menangani masalah di sana. Di negara kami, pengembang berbaris dan meminta untuk menutup fungsionalitasnya dengan tes otomatis.

Apa Selanjutnya

Mari kita bicara tentang rencana pengembangan proyek pengujian otomatis.

Tentunya selama sistem loyalitas Sportmaster masih hidup dan terus berkembang, autotest juga bisa dikembangkan hampir tanpa henti. Oleh karena itu, arah utama pengembangan adalah perluasan cakupan wilayah.

Dengan bertambahnya jumlah tes otomatis, total waktu kerja mereka akan terus meningkat, dan kita harus kembali ke masalah kinerja. Kemungkinan besar, solusinya adalah dengan menambah jumlah utas paralel.

Tetapi ini adalah cara pengembangan yang jelas. Jika kami berbicara tentang sesuatu yang lebih non-sepele, kami menyoroti yang berikut:

1. Sekarang tes otomatis dikelola di tingkat DBMS, mis. pengetahuan tentang PL/SQL diperlukan untuk pekerjaan yang berhasil. Jika perlu, manajemen sistem (misalnya, meluncurkan atau membuat metadata) dapat dihapus oleh semacam panel admin menggunakan Jenkins atau yang serupa.
2. Semua orang menyukai indikator kuantitatif dan kualitatif. Untuk pengujian otomatis, indikator universal seperti itu adalah Cakupan Kode atau metrik cakupan kode. Dengan menggunakan indikator ini, kami dapat menentukan persentase kode sistem kami yang diuji yang dicakup oleh pengujian otomatis. Mulai dari versi 12.2, Oracle menyediakan kemampuan untuk menghitung metrik ini dan menyarankan menggunakan paket DBMS_PLSQL_CODE_COVERAGE standar.

   Sistem uji otomatis kami baru berusia lebih dari satu tahun dan mungkin sudah waktunya untuk mengevaluasi cakupan. Dalam proyek terakhir saya (proyek bukan oleh Sportmaster), ini terjadi. Setahun setelah mengerjakan tes otomatis, manajemen menetapkan tugas untuk menilai berapa persentase kode yang kami cakup. Dengan cakupan lebih dari 1%, manajemen akan senang. Kami, para pengembang, mengharapkan hasil sekitar 10%. Kami mengacaukan cakupan kode, mengukurnya, mendapat 20%. Untuk merayakannya, kami mencari penghargaan, tetapi bagaimana kami melakukannya dan ke mana kami pergi nanti adalah cerita yang sama sekali berbeda.

3. Tes otomatis dapat menguji layanan web yang terbuka. Oracle mengizinkan Anda melakukan ini, dan kami tidak akan lagi menghadapi sejumlah masalah.
4. Dan, tentu saja, sistem pengujian otomatis kami dapat diterapkan pada proyek lain. Solusi yang kami terima bersifat universal dan hanya membutuhkan penggunaan Oracle. Saya mendengar bahwa ada minat dalam pengujian otomatis pada proyek Sportmaster lain dan, mungkin, kami akan melakukannya.

Temuan

Mari kita rekap. Pada proyek sistem loyalitas di Sportmaster, kami berhasil menerapkan sistem pengujian otomatis. Dasarnya adalah solusi utPLSQL dari Stephen Feuerstein. Di sekitar utPLSQL terdapat kode untuk pengujian otomatis dan modul tambahan yang ditulis sendiri: peluncur, modul pembuatan data, dan lainnya. Tes otomatis berjalan setiap hari dan, yang terpenting, berhasil dan bermanfaat. Kami yakin bahwa kami telah mulai merilis perangkat lunak dengan kualitas lebih tinggi. Pada saat yang sama, solusi yang dihasilkan bersifat universal dan dapat diterapkan secara bebas ke proyek mana pun yang memerlukan pengaturan pengujian otomatis pada Oracle DBMS.

PS Artikel ini ternyata tidak terlalu spesifik: ada banyak teks dan praktis tidak ada contoh teknis. Jika topiknya menarik secara global, maka kami siap untuk melanjutkannya dan kembali dengan kelanjutan, di mana kami akan memberi tahu Anda apa yang telah berubah selama enam bulan terakhir dan memberikan contoh kode.

Tulis komentar jika ada poin yang perlu ditekankan di masa mendatang, atau pertanyaan yang memerlukan pengungkapan.

Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. Masuk, silakan.

Haruskah kita menulis lebih banyak tentang ini?

• Ya tentu saja

• Tidak, terima kasih

12 pengguna memilih. 4 pengguna abstain.

Sumber: www.habr.com