Ujian unit dalam DBMS - bagaimana kami melakukannya dalam Sportmaster, bahagian dua

Bahagian pertama - di sini.

Bayangkan keadaannya. Anda berhadapan dengan tugas untuk membangunkan fungsi baharu. Anda mempunyai perkembangan daripada pendahulu anda. Jika kami menganggap anda tidak mempunyai kewajipan moral, apakah yang akan anda lakukan?

Selalunya, semua perkembangan lama dilupakan dan semuanya bermula semula. Tiada siapa yang suka menggali kod orang lain, tetapi jika anda mempunyai masa, mengapa tidak mula mencipta sistem anda sendiri? Ini adalah pendekatan biasa, dan ia sebahagian besarnya betul. Tetapi dalam projek kami, kami melakukan kesilapan. Kami mengasaskan sistem ujian automatik masa hadapan pada perkembangan dalam ujian unit pada utPLSQL daripada pendahulu kami, dan kemudian mula bekerja dalam beberapa arah selari.

1. Memulihkan ujian unit lama. Pemulihan bermakna menyesuaikan ujian kepada keadaan sedia ada sistem kesetiaan dan menyesuaikan ujian kepada piawaian utPLSQL.
2. Menyelesaikan masalah dengan pemahaman tentang apa sebenarnya, kaedah dan proses yang diliputi dengan autotest. Anda mesti sama ada menyimpan maklumat ini dalam kepala anda, atau membuat kesimpulan berdasarkan kod autotest. Oleh itu, kami memutuskan untuk membuat katalog. Kami memberikan kod mnemonik unik untuk setiap autoujian, mencipta perihalan dan merakam tetapan (contohnya, dalam keadaan apa ia harus dilancarkan atau perkara yang harus berlaku jika pelancaran ujian gagal). Pada asasnya, kami mengisi metadata tentang autotest dan meletakkan metadata tersebut ke dalam jadual skema utPLSQL standard.
3. Mentakrifkan strategi pengembangan, i.e. pemilihan fungsi yang tertakluk kepada pengesahan oleh ujian automatik. Kami memutuskan untuk memberi perhatian kepada tiga perkara: penambahbaikan sistem baharu, insiden pengeluaran dan proses sistem utama. Oleh itu, kami membangun selari dengan keluaran, memastikan kualitinya yang lebih tinggi, pada masa yang sama mengembangkan skop regresi dan memastikan kebolehpercayaan sistem di tempat kritikal. Kesesakan yang pertama ialah proses pengagihan diskaun dan bonus pada cek.
4. Sememangnya, kami mula membangunkan autotest baharu. Salah satu tugas keluaran pertama adalah untuk menilai prestasi sampel yang dipratentukan sistem kesetiaan. Projek kami mempunyai blok pertanyaan SQL tetap tegar yang memilih pelanggan berdasarkan syarat. Contohnya, dapatkan senarai semua pelanggan yang pembelian terakhir mereka berada di bandar tertentu atau senarai pelanggan yang purata jumlah pembeliannya melebihi nilai tertentu. Mempunyai autotest bertulis, kami menyemak sampel yang dipratentukan, merekodkan parameter prestasi penanda aras, dan tambahan pula kami mempunyai ujian beban.
5. Bekerja dengan autotest sepatutnya mudah. Dua tindakan yang paling biasa ialah menjalankan autotest dan mencipta data ujian. Beginilah cara dua modul tambahan muncul dalam sistem kami: modul pelancaran dan modul penjanaan data.

   Pelancar diwakili sebagai satu prosedur universal dengan satu parameter input teks. Sebagai parameter, anda boleh lulus kod mnemonik autotest, nama pakej, nama ujian, tetapan autotest atau kata kunci yang dikhaskan. Prosedur memilih dan menjalankan semua autotest yang memenuhi syarat.

   Modul penjanaan data dibentangkan dalam bentuk pakej di mana untuk setiap objek sistem yang diuji (jadual dalam pangkalan data), prosedur khas telah dibuat yang memasukkan data di sana. Dalam prosedur ini, nilai lalai diisi sebanyak mungkin, yang memastikan penciptaan objek secara literal dengan satu klik jari. Dan untuk kemudahan penggunaan, templat untuk data yang dihasilkan telah dibuat. Contohnya, buat pelanggan pada umur tertentu dengan telefon ujian dan pembelian yang lengkap.

6. Autotest harus bermula dan dijalankan dalam masa yang boleh diterima untuk sistem anda. Oleh itu, pelancaran malam harian telah dianjurkan, berdasarkan keputusan yang laporan mengenai keputusan dijana dan dihantar kepada seluruh pasukan pembangunan melalui mel korporat. Selepas memulihkan autotest lama dan mencipta yang baharu, jumlah masa operasi ialah 30 minit. Prestasi ini sesuai dengan semua orang, sejak pelancaran berlangsung di luar waktu bekerja.

   Tetapi kami terpaksa berusaha untuk mengoptimumkan kelajuan kerja. Sistem kesetiaan dalam pengeluaran dikemas kini pada waktu malam. Sebagai sebahagian daripada salah satu keluaran, kami terpaksa membuat perubahan segera pada waktu malam. Menunggu selama setengah jam untuk keputusan autotest pada pukul tiga pagi tidak membuat orang yang bertanggungjawab untuk pembebasan gembira (salam bersemangat untuk Alexey Vasyukov!), Dan keesokan harinya banyak kata-kata baik diucapkan terhadap sistem kami. Tetapi hasilnya, standard 5 minit untuk kerja telah ditetapkan.

   Untuk mempercepatkan prestasi, kami menggunakan dua kaedah: autotest mula dijalankan dalam tiga utas selari, mujurlah ini sangat mudah kerana seni bina sistem kesetiaan kami. Dan kami meninggalkan pendekatan di mana autotest tidak mencipta data ujian untuk dirinya sendiri, tetapi cuba mencari sesuatu yang sesuai dalam sistem. Selepas membuat perubahan, jumlah masa operasi dikurangkan kepada 3-4 minit.

7. Projek dengan ujian automatik sepatutnya boleh digunakan di pelbagai tempat berdiri. Pada permulaan perjalanan kami, terdapat percubaan untuk menulis fail kelompok kami sendiri, tetapi menjadi jelas bahawa pemasangan automatik yang ditulis sendiri adalah seram dan kami beralih ke penyelesaian perindustrian. Disebabkan fakta bahawa projek itu mengandungi banyak kod langsung (pertama sekali, kami menyimpan kod autotest) dan data yang sangat sedikit (data utama ialah metadata mengenai autotest), pelaksanaan dalam projek Liquibase ternyata sangat mudah.

   Ia adalah perpustakaan bebas pangkalan data sumber terbuka untuk menjejak, mengurus dan menguatkuasakan perubahan skema pangkalan data. Diuruskan melalui baris arahan atau rangka kerja seperti Apache Maven. Prinsip operasi Liquibase agak mudah. Kami mempunyai projek yang dianjurkan dengan cara tertentu, yang terdiri daripada perubahan atau skrip yang perlu dilancarkan ke pelayan sasaran, dan mengawal fail yang menentukan dalam urutan dan dengan parameter apakah perubahan ini harus dipasang.

   Pada peringkat DBMS, jadual khas dibuat di mana Liquibase menyimpan log peralihan. Setiap perubahan mempunyai cincang yang dikira, yang dibandingkan setiap kali antara projek dan keadaan dalam pangkalan data. Terima kasih kepada Liquibase, kami boleh melancarkan perubahan pada sistem kami ke mana-mana litar dengan mudah. Autotest kini dilancarkan pada litar ujian dan pelepasan, serta pada bekas (litar peribadi pembangun).

Jadi, mari kita bercakap tentang keputusan menggunakan sistem ujian unit kami.

1. Sudah tentu, pertama sekali, kami yakin bahawa kami telah mula membangunkan perisian yang lebih baik. Autotest dilancarkan setiap hari dan berpuluh-puluh ralat ditemui setiap keluaran. Selain itu, beberapa ralat ini hanya berkaitan secara tidak langsung dengan fungsi yang benar-benar ingin kami ubah. Terdapat keraguan serius bahawa ralat ini ditemui melalui ujian manual.
2. Pasukan kini yakin bahawa fungsi tertentu berfungsi dengan betul... Pertama sekali, ini melibatkan proses kritikal kami. Sebagai contoh, dalam tempoh enam bulan yang lalu kami tidak mempunyai sebarang masalah dengan pengagihan diskaun dan bonus pada resit, walaupun pelepasan itu berubah, walaupun dalam tempoh sebelumnya ralat berlaku dengan beberapa kekerapan.
3. Kami berjaya mengurangkan bilangan lelaran ujian. Disebabkan fakta bahawa ujian automatik ditulis untuk fungsi baharu, penganalisis dan penguji sambilan menerima kod kualiti yang lebih tinggi, kerana ia telah pun disemak.
4. Beberapa perkembangan dalam ujian automatik digunakan oleh pembangun. Sebagai contoh, data ujian pada bekas dibuat menggunakan modul penjanaan objek.
5. Adalah penting bahawa kami telah membangunkan "penerimaan" sistem ujian automatik di pihak pembangun. Terdapat pemahaman bahawa ini penting dan berguna. Tetapi dari pengalaman saya sendiri, saya boleh mengatakan bahawa ini jauh dari kes itu. Autotest perlu ditulis, ia perlu disokong dan dibangunkan, hasilnya mesti dianalisis, dan selalunya kos masa ini tidak berbaloi. Lebih mudah untuk pergi ke pengeluaran dan menangani masalah di sana. Di sini, pembangun berbaris dan meminta kami menutup fungsi mereka dengan autotest.

Apa yang Seterusnya

Mari kita bincangkan tentang rancangan pembangunan untuk projek ujian automatik.

Sudah tentu, selagi sistem kesetiaan Sportmaster masih hidup dan terus berkembang, ia juga mungkin untuk membangunkan autotest hampir tanpa henti. Oleh itu, hala tuju utama pembangunan adalah meluaskan kawasan liputan.

Apabila bilangan autoujian meningkat, jumlah masa operasinya akan meningkat secara berterusan, dan kami sekali lagi perlu kembali kepada isu prestasi. Kemungkinan besar, penyelesaiannya adalah dengan menambah bilangan benang selari.

Tetapi ini adalah cara pembangunan yang jelas. Jika kita bercakap tentang sesuatu yang lebih bukan remeh, kita menyerlahkan perkara berikut:

1. Pada masa ini, pengurusan autotest dilakukan pada peringkat DBMS, i.e. pengetahuan tentang PL/SQL diperlukan untuk kerja yang berjaya. Jika perlu, pengurusan sistem (contohnya, melancarkan atau mencipta metadata), anda boleh membuat beberapa jenis panel pentadbir menggunakan Jenkins atau sesuatu yang serupa.
2. Semua orang suka penunjuk kuantitatif dan kualitatif. Untuk ujian automatik, penunjuk universal seperti itu ialah Liputan Kod atau metrik liputan kod. Menggunakan penunjuk ini, kami boleh menentukan peratusan kod sistem kami yang sedang diuji dilindungi oleh ujian auto. Bermula dari versi 12.2, Oracle menyediakan keupayaan untuk mengira metrik ini dan menawarkan penggunaan pakej DBMS_PLSQL_CODE_COVERAGE standard.

   Sistem autoujian kami baru berusia lebih setahun dan mungkin sekarang adalah masa untuk menilai liputan kami. Dalam projek terakhir saya (bukan projek Sportmaster) inilah yang berlaku. Setahun selepas menjalankan autotest, pihak pengurusan menetapkan tugas untuk menilai peratusan kod yang kami lindungi. Dengan liputan lebih daripada 1%, pihak pengurusan pasti gembira. Kami, pemaju, menjangkakan hasil kira-kira 10%. Kami memasang liputan kod, mengukurnya dan mendapat 20%. Untuk meraikan, kami pergi untuk mendapatkan hadiah, tetapi bagaimana kami pergi untuk mendapatkannya dan ke mana kami pergi kemudian adalah cerita yang sama sekali berbeza.

3. Autotests boleh menyemak perkhidmatan web terdedah. Oracle membolehkan kami melakukan ini dengan baik, dan kami tidak akan menghadapi beberapa masalah lagi.
4. Dan, sudah tentu, sistem ujian automatik kami boleh digunakan untuk projek lain. Penyelesaian yang kami terima adalah universal dan hanya memerlukan penggunaan Oracle. Saya mendengar bahawa projek Sportmaster lain berminat dalam ujian automatik dan mungkin kami akan pergi kepadanya.

Penemuan

Mari kita ringkaskan. Mengenai projek sistem kesetiaan dalam Sportmaster, kami berjaya melaksanakan sistem ujian automatik. Ia berdasarkan penyelesaian utPLSQL daripada Stephen Feuerstein. Di sekitar utPLSQL terdapat kod autotest dan modul tulisan sendiri tambahan: modul pelancaran, modul penjanaan data dan lain-lain. Autotest dilancarkan setiap hari dan, yang paling penting, ia berfungsi dan berguna. Kami yakin bahawa kami telah mula mengeluarkan perisian berkualiti tinggi. Pada masa yang sama, penyelesaian yang terhasil adalah universal dan boleh digunakan secara bebas pada mana-mana projek di mana perlu untuk mengatur ujian automatik pada DBMS Oracle.

PS Artikel ini tidak begitu spesifik: terdapat banyak teks dan boleh dikatakan tiada contoh teknikal. Jika topik itu secara amnya menarik, maka kami bersedia untuk meneruskannya dan kembali dengan sambungan, di mana kami akan memberitahu anda perkara yang telah berubah sejak enam bulan lalu dan memberikan contoh kod.

Tulis ulasan jika terdapat perkara yang perlu dititikberatkan pada masa hadapan, atau soalan yang memerlukan pendedahan.

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Bolehkah kita menulis lebih lanjut tentang ini?

• Ya pasti

• Tidak, Terima kasih

12 pengguna mengundi. 4 pengguna berpantang.

Sumber: www.habr.com