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

Hai Habr!

Nama saya Maxim Ponomarenko dan saya seorang pembangun di Sportmaster. Saya mempunyai 10 tahun pengalaman dalam bidang IT. Dia memulakan kerjayanya dalam ujian manual, kemudian beralih kepada pembangunan pangkalan data. Selama 4 tahun yang lalu, mengumpul pengetahuan yang diperoleh dalam ujian dan pembangunan, saya telah mengautomasikan ujian di peringkat DBMS.

Saya telah berada dalam pasukan Sportmaster selama lebih setahun dan sedang membangunkan ujian automatik pada salah satu projek utama. Pada bulan April, saya dan rakan-rakan dari Sportmaster Lab bercakap pada persidangan di Krasnodar, laporan saya dipanggil "Ujian unit dalam DBMS," dan sekarang saya ingin berkongsi dengan anda. Akan ada banyak teks, jadi saya memutuskan untuk membahagikan laporan kepada dua jawatan. Pada yang pertama, kita akan bercakap tentang autotest dan ujian secara umum, dan pada yang kedua, saya akan membincangkan dengan lebih terperinci tentang sistem ujian unit kami dan hasil aplikasinya.

Pertama, teori yang sedikit membosankan. Apakah ujian automatik? Ini adalah ujian yang dijalankan menggunakan perisian, dan dalam IT moden ia semakin digunakan dalam pembangunan perisian. Ini disebabkan oleh fakta bahawa syarikat sedang berkembang, sistem maklumat mereka berkembang dan, dengan itu, jumlah fungsi yang perlu diuji semakin meningkat. Menjalankan ujian manual menjadi semakin mahal.

Saya bekerja untuk sebuah syarikat besar yang dikeluarkan setiap dua bulan. Pada masa yang sama, sebulan penuh dihabiskan untuk mempunyai sedozen penguji menyemak fungsi secara manual. Terima kasih kepada pelaksanaan automasi oleh pasukan kecil pembangun, kami dapat mengurangkan masa ujian kepada 2 minggu dalam satu setengah tahun. Kami bukan sahaja meningkatkan kelajuan ujian, tetapi juga meningkatkan kualitinya. Ujian automatik dilancarkan secara berkala dan mereka sentiasa menjalankan keseluruhan pemeriksaan yang disertakan di dalamnya, iaitu, kami mengecualikan faktor manusia.

IT moden dicirikan oleh fakta bahawa pembangun mungkin diperlukan bukan sahaja untuk menulis kod produk, tetapi juga untuk menulis ujian unit yang menyemak kod ini.

Tetapi bagaimana jika sistem anda berdasarkan logik pelayan? Tiada penyelesaian universal atau amalan terbaik di pasaran. Sebagai peraturan, syarikat menyelesaikan masalah ini dengan mencipta sistem ujian bertulis sendiri. Ini adalah sistem ujian automatik tulisan sendiri kami yang telah dibuat pada projek kami dan saya akan membincangkannya dalam laporan saya.

Menguji kesetiaan

Mula-mula, mari bercakap tentang projek di mana kami menggunakan sistem ujian automatik. Projek kami ialah sistem kesetiaan Sportmaster (by the way, kami sudah menulis mengenainya dalam jawatan ini).

Jika syarikat anda cukup besar, maka sistem kesetiaan anda akan mempunyai tiga sifat standard:

• Sistem anda akan sangat dimuatkan
• Sistem anda akan mengandungi proses pengkomputeran yang kompleks
• Sistem anda akan dipertingkatkan secara aktif.

Mari kita pergi dengan teratur... Secara keseluruhan, jika kita mempertimbangkan semua jenama Sportmaster, maka kita mempunyai lebih daripada 1000 kedai di Rusia, Ukraine, China, Kazakhstan dan Belarus. Kira-kira 300 pembelian dibuat di kedai-kedai ini setiap hari. Iaitu, setiap detik 000-3 pemeriksaan memasuki sistem kami. Sememangnya, sistem kesetiaan kami sangat dimuatkan. Dan kerana ia digunakan secara aktif, kami mesti menyediakan standard tertinggi kualitinya, kerana sebarang ralat dalam perisian bermakna kerugian kewangan, reputasi dan kerugian lain yang besar.

Pada masa yang sama, Sportmaster menjalankan lebih daripada seratus promosi yang berbeza. Terdapat pelbagai promosi: ada promosi produk, ada yang dikhaskan untuk hari dalam seminggu, ada yang terikat pada kedai tertentu, ada promosi untuk jumlah resit, ada untuk jumlah barang. Secara umum, tidak buruk. Pelanggan mempunyai bonus dan kod promosi yang digunakan semasa membuat pembelian. Semua ini membawa kepada fakta bahawa mengira sebarang pesanan adalah tugas yang sangat tidak remeh.

Algoritma yang melaksanakan pemprosesan pesanan benar-benar dahsyat dan rumit. Dan sebarang perubahan pada algoritma ini agak berisiko. Nampaknya perubahan yang paling kelihatan tidak ketara boleh membawa kepada kesan yang tidak dapat diramalkan. Tetapi proses pengkomputeran yang begitu kompleks, terutamanya yang melaksanakan fungsi kritikal, adalah calon terbaik untuk automasi. Memeriksa berpuluh-puluh kes yang serupa dengan tangan sangat memakan masa. Dan memandangkan titik masuk ke dalam proses itu tidak berubah, setelah menerangkannya sekali, anda boleh dengan cepat membuat ujian automatik dan yakin bahawa fungsi itu akan berfungsi.

Memandangkan sistem kami digunakan secara aktif, perniagaan akan menginginkan sesuatu yang baharu daripada anda, hidup mengikut masa dan berorientasikan pelanggan. Dalam sistem kesetiaan kami, keluaran keluar setiap dua bulan. Ini bermakna setiap dua bulan kita perlu menjalankan regresi lengkap keseluruhan sistem. Pada masa yang sama, secara semula jadi, seperti dalam mana-mana IT moden, pembangunan tidak serta-merta pergi dari pemaju kepada pengeluaran. Ia berasal dari litar pembangun, kemudian berturut-turut melalui bangku ujian, pelepasan, penerimaan, dan hanya kemudian berakhir dalam pengeluaran. Sekurang-kurangnya, pada litar ujian dan pelepas, kita perlu menjalankan regresi lengkap keseluruhan sistem.

Sifat yang diterangkan adalah standard untuk hampir semua sistem kesetiaan. Mari kita bercakap tentang ciri-ciri projek kami.

Dari segi teknologi, 90% daripada logik sistem kesetiaan kami adalah berasaskan pelayan dan dilaksanakan pada Oracle. Terdapat pelanggan yang terdedah dalam Delphi, yang melaksanakan fungsi pentadbir tempat kerja automatik. Terdapat perkhidmatan web terdedah untuk aplikasi luaran (contohnya tapak web). Oleh itu, adalah sangat logik bahawa jika kami menggunakan sistem ujian automatik, kami akan melakukannya pada Oracle.

Sistem kesetiaan dalam Sportmaster telah wujud selama lebih daripada 7 tahun dan dicipta oleh pembangun tunggal... Purata bilangan pembangun pada projek kami selama 7 tahun ini ialah 3-4 orang. Tetapi sepanjang tahun lalu, pasukan kami telah berkembang dengan ketara, dan kini terdapat 10 orang yang bekerja pada projek itu. Iaitu, orang datang ke projek yang tidak biasa dengan tugas, proses dan seni bina biasa. Dan terdapat peningkatan risiko bahawa kita akan terlepas kesilapan.

Projek ini dicirikan oleh ketiadaan penguji khusus sebagai unit kakitangan. Sudah tentu, terdapat ujian, tetapi ujian dijalankan oleh penganalisis, sebagai tambahan kepada tanggungjawab utama mereka yang lain: berkomunikasi dengan pelanggan perniagaan, pengguna, membangunkan keperluan sistem, dll. dan lain-lain... Walaupun ujian dijalankan dengan kualiti yang sangat tinggi (ini amat sesuai untuk disebut, kerana sesetengah penganalisis mungkin menarik perhatian laporan ini), keberkesanan pengkhususan dan penumpuan pada satu perkara tidak dibatalkan. .

Memandangkan semua perkara di atas, untuk meningkatkan kualiti produk yang dihantar dan mengurangkan masa pembangunan, idea untuk mengautomasikan ujian pada projek kelihatan sangat logik. Dan pada peringkat yang berbeza dalam kewujudan sistem kesetiaan, pembangun individu berusaha untuk menutup kod mereka dengan ujian unit. Secara keseluruhannya ia adalah proses yang agak terputus-putus, dengan semua orang menggunakan seni bina dan kaedah mereka sendiri. Keputusan akhir adalah biasa untuk ujian unit: ujian telah dibangunkan, digunakan untuk beberapa lama, disimpan dalam storan fail versi, tetapi pada satu ketika ia berhenti berjalan dan dilupakan. Pertama sekali, ini disebabkan oleh fakta bahawa ujian lebih terikat kepada pelaku tertentu, dan bukan kepada projek.

utPLSQL datang untuk menyelamatkan

Adakah anda tahu apa-apa tentang Stephen Feuerstein?

Ini adalah seorang lelaki pintar yang menumpukan sebahagian panjang kerjayanya untuk bekerja dengan Oracle dan PL/SQL, dan telah menulis sejumlah besar karya mengenai topik ini. Salah satu bukunya yang terkenal dipanggil: "Oracle PL/SQL. Untuk profesional." Stephenlah yang membangunkan penyelesaian utPLSQL, atau, seperti singkatan dari, rangka kerja Ujian Unit untuk Oracle PL/SQL. Penyelesaian utPLSQL telah dicipta pada tahun 2016, tetapi ia terus diusahakan secara aktif dan versi baharu dikeluarkan. Pada masa pelaporan, versi terkini bermula pada 24 Mac 2019.
Apa itu. Ini adalah projek sumber terbuka yang berasingan. Ia mempunyai berat beberapa megabait, termasuk contoh dan dokumentasi. Secara fizikal, ia adalah skema berasingan dalam pangkalan data ORACLE dengan set pakej dan jadual untuk mengatur ujian unit. Pemasangan mengambil masa beberapa saat. Ciri tersendiri utPLSQL ialah kemudahan penggunaannya.
Di peringkat global, utPLSQL ialah mekanisme untuk menjalankan ujian unit, di mana ujian unit difahami sebagai prosedur kumpulan Oracle biasa, organisasi yang mengikut peraturan tertentu. Selain pelancaran, utPLSQL menyimpan log semua ujian anda dijalankan, dan juga mempunyai sistem pelaporan dalaman.

Mari lihat contoh rupa kod ujian unit, dilaksanakan menggunakan teknik ini.

Jadi, skrin menunjukkan kod untuk spesifikasi pakej biasa dengan ujian unit. Apakah syarat wajib? Paket mesti diawali dengan "utp_". Semua prosedur dengan ujian mesti mempunyai awalan yang sama. Pakej mesti mengandungi dua prosedur standard: "utp_setup" dan "utp_teardown". Prosedur pertama dipanggil dengan memulakan semula setiap ujian unit, yang kedua - selepas pelancaran.

“utp_setup”, sebagai peraturan, menyediakan sistem kami untuk menjalankan ujian unit, contohnya, mencipta data ujian. “utp_teardown” - sebaliknya, semuanya kembali kepada tetapan asal dan menetapkan semula hasil pelancaran.

Berikut ialah contoh ujian unit paling mudah yang menyemak normalisasi nombor telefon pelanggan yang dimasukkan kepada borang standard untuk sistem kesetiaan kami. Tiada piawaian wajib tentang cara menulis prosedur dengan ujian unit. Sebagai peraturan, panggilan dibuat kepada kaedah sistem yang sedang diuji, dan hasil yang dikembalikan oleh kaedah ini dibandingkan dengan kaedah rujukan. Adalah penting bahawa perbandingan hasil rujukan dan yang diperolehi berlaku melalui kaedah utPLSQL standard.

Ujian unit boleh mempunyai sebarang bilangan semakan. Seperti yang dapat dilihat daripada contoh, kami membuat empat panggilan berturut-turut kepada kaedah yang diuji untuk menormalkan nombor telefon dan menilai keputusan selepas setiap panggilan. Apabila membangunkan ujian unit, anda mesti mengambil kira bahawa terdapat semakan yang tidak menjejaskan sistem dalam apa cara sekalipun, dan selepas beberapa ketika anda perlu kembali ke keadaan asal sistem.
Sebagai contoh, dalam ujian unit yang dibentangkan, kami hanya memformat nombor telefon input, yang tidak menjejaskan sistem kesetiaan dalam apa jua cara.

Dan jika kita menulis ujian unit menggunakan kaedah mencipta pelanggan baharu, maka selepas setiap ujian pelanggan baharu akan dibuat dalam sistem, yang boleh menjejaskan pelancaran ujian berikutnya.

Beginilah cara ujian unit dijalankan. Terdapat dua pilihan pelancaran yang mungkin: menjalankan semua ujian unit daripada pakej tertentu atau menjalankan ujian unit tertentu dalam pakej tertentu.

Beginilah rupa contoh sistem pelaporan dalaman. Berdasarkan keputusan ujian unit, utPLSQL membina laporan kecil. Di dalamnya kita melihat keputusan untuk setiap pemeriksaan khusus dan keputusan keseluruhan ujian unit.

6 peraturan autotest

Sebelum mula mencipta sistem baharu untuk ujian automatik sistem kesetiaan, bersama-sama pengurusan, kami menentukan prinsip yang perlu dipatuhi oleh ujian automatik masa hadapan kami.

1. Autotest mesti berkesan dan mesti berguna. Kami mempunyai pembangun yang hebat, yang pastinya perlu disebut, kerana sesetengah daripada mereka mungkin akan melihat laporan ini, dan mereka menulis kod yang menarik. Tetapi walaupun kod indah mereka tidak sempurna dan mempunyai, mempunyai, dan akan terus mengandungi ralat. Autotest diperlukan untuk mencari ralat ini. Jika ini tidak berlaku, maka sama ada kita menulis autotest yang buruk, atau kita telah sampai ke kawasan mati yang, pada dasarnya, tidak dibangunkan. Dalam kedua-dua kes, kami melakukan sesuatu yang salah, dan pendekatan kami tidak masuk akal.
2. Autotest harus digunakan. Tidak masuk akal untuk menghabiskan banyak masa dan usaha untuk menulis produk perisian, meletakkannya dalam repositori dan melupakannya. Ujian harus dijalankan, dan dijalankan sekerap mungkin.
3. Autotest harus berfungsi dengan stabil. Tidak kira masa dalam hari, tempat pelancaran dan tetapan sistem lain, larian ujian harus membawa kepada hasil yang sama. Sebagai peraturan, ini dipastikan oleh fakta bahawa autotest berfungsi dengan data ujian khas dengan tetapan sistem tetap.
4. Autotest harus berfungsi pada kelajuan yang boleh diterima untuk projek anda. Masa ini ditentukan secara individu untuk setiap sistem. Sesetengah orang mampu untuk bekerja sepanjang hari, manakala yang lain menganggapnya penting untuk melakukannya dalam beberapa saat. Saya akan memberitahu anda sedikit kemudian piawaian kelajuan yang kami capai dalam projek kami.
5. Pembangunan autotest hendaklah fleksibel. Adalah tidak digalakkan untuk menolak menguji sebarang fungsi semata-mata kerana kami tidak melakukannya sebelum ini atau atas sebab lain. utPLSQL tidak mengenakan sebarang sekatan ke atas pembangunan, dan Oracle, pada dasarnya, membolehkan anda melaksanakan pelbagai perkara. Kebanyakan masalah mempunyai penyelesaian, ia hanya soal masa dan usaha.
6. Kebolehgunaan. Kami mempunyai beberapa gerai tempat kami perlu menjalankan ujian. Di setiap gerai, longgokan data boleh dikemas kini pada bila-bila masa. Ia adalah perlu untuk menjalankan projek dengan ujian automatik sedemikian rupa sehingga anda boleh menjalankan pemasangan penuh atau separa tanpa rasa sakit.

Dan dalam jawatan kedua dalam beberapa hari saya akan memberitahu anda apa yang kami lakukan dan apa hasil yang kami capai.

Sumber: www.habr.com