Hei Habr!
Nama saya Maxim Ponomarenko dan saya seorang pengembang di Sportmaster. Saya memiliki pengalaman 10 tahun di bidang IT. Dia memulai karirnya dalam pengujian manual, kemudian beralih ke pengembangan database. Selama 4 tahun terakhir, setelah mengumpulkan pengetahuan yang diperoleh dalam pengujian dan pengembangan, saya telah mengotomatisasi pengujian di tingkat DBMS.
Saya telah berada di tim Sportmaster selama lebih dari setahun dan sedang mengembangkan pengujian otomatis pada salah satu proyek besar. Pada bulan April, saya dan orang-orang dari Sportmaster Lab berbicara di sebuah konferensi di Krasnodar, laporan saya berjudul "Pengujian unit di DBMS", dan sekarang saya ingin membaginya dengan Anda. Akan ada banyak teks, jadi saya memutuskan untuk membagi laporan menjadi dua postingan. Yang pertama, kita akan membahas tentang autotest dan pengujian secara umum, dan yang kedua, saya akan membahas lebih detail tentang sistem pengujian unit kita dan hasil penerapannya.
Pertama, teori yang sedikit membosankan. Apa itu pengujian otomatis? Ini adalah pengujian yang dilakukan dengan menggunakan perangkat lunak, dan dalam TI modern semakin banyak digunakan dalam pengembangan perangkat lunak. Hal ini disebabkan oleh fakta bahwa perusahaan sedang berkembang, sistem informasi mereka berkembang, dan oleh karena itu, jumlah fungsionalitas yang perlu diuji pun semakin bertambah. Melakukan pengujian manual menjadi semakin mahal.
Saya bekerja di sebuah perusahaan besar yang rilisnya keluar setiap dua bulan. Pada saat yang sama, satu bulan penuh dihabiskan untuk meminta selusin penguji memeriksa fungsionalitasnya secara manual. Berkat penerapan otomatisasi oleh tim kecil pengembang, kami dapat mengurangi waktu pengujian menjadi 2 minggu dalam satu setengah tahun. Kami tidak hanya meningkatkan kecepatan pengujian, tetapi juga meningkatkan kualitasnya. Pengujian otomatis diluncurkan secara berkala dan mereka selalu melakukan seluruh rangkaian pemeriksaan yang termasuk di dalamnya, yaitu, kami mengecualikan faktor manusia.
TI modern dicirikan oleh fakta bahwa pengembang mungkin diharuskan tidak hanya menulis kode produk, tetapi juga menulis unit test yang memeriksa kode ini.
Namun bagaimana jika sistem Anda terutama didasarkan pada logika server? Tidak ada solusi universal atau praktik terbaik di pasar. Biasanya, perusahaan memecahkan masalah ini dengan membuat sistem pengujian yang mereka tulis sendiri. Ini adalah sistem pengujian otomatis yang kami tulis sendiri yang dibuat pada proyek kami dan saya akan membicarakannya di laporan saya.
Menguji kesetiaan
Pertama, mari kita bahas tentang proyek tempat kami menerapkan sistem pengujian otomatis. Proyek kami adalah sistem loyalitas Sportmaster (omong-omong, kami sudah menulisnya di ).
Jika perusahaan Anda cukup besar, maka sistem loyalitas Anda akan memiliki tiga properti standar:
- Sistem Anda akan terisi penuh
- Sistem Anda akan berisi proses komputasi yang kompleks
- Sistem Anda akan ditingkatkan secara aktif.
Ayo beres... Secara total, jika kami mempertimbangkan semua merek Sportmaster, maka kami memiliki lebih dari 1000 toko di Rusia, Ukraina, Cina, Kazakhstan, dan Belarus. Sekitar 300 pembelian dilakukan di toko-toko ini setiap hari. Artinya, setiap detik 000-3 cek masuk ke sistem kami. Tentu saja, sistem loyalitas kami penuh dengan muatan. Dan karena digunakan secara aktif, kami harus memberikan standar kualitas tertinggi, karena kesalahan apa pun dalam perangkat lunak berarti kerugian moneter, reputasi, dan kerugian lainnya yang besar.
Pada saat yang sama, Sportmaster menjalankan lebih dari seratus promosi berbeda. Promosinya bermacam-macam: ada promosi produk, ada yang didedikasikan untuk hari dalam seminggu, ada yang terikat dengan toko tertentu, ada promosi untuk jumlah kwitansi, ada untuk jumlah barang. Secara umum, lumayan. Klien memiliki bonus dan kode promosi yang digunakan saat melakukan pembelian. Semua ini mengarah pada fakta bahwa menghitung pesanan apa pun adalah tugas yang sangat tidak sepele.
Algoritme yang mengimplementasikan pemrosesan pesanan benar-benar buruk dan rumit. Dan setiap perubahan pada algoritma ini cukup beresiko. Tampaknya perubahan yang tampaknya sepele dapat menimbulkan dampak yang tidak dapat diprediksi. Namun justru proses komputasi yang kompleks, terutama yang mengimplementasikan fungsi penting, merupakan kandidat terbaik untuk otomatisasi. Memeriksa lusinan kasus serupa dengan tangan sangat memakan waktu. Dan karena titik masuk ke dalam proses tidak berubah, setelah menjelaskannya sekali, Anda dapat dengan cepat membuat pengujian otomatis dan yakin bahwa fungsinya akan berfungsi.
Karena sistem kami digunakan secara aktif, bisnis akan menginginkan sesuatu yang baru dari Anda, mengikuti perkembangan zaman dan berorientasi pada pelanggan. Dalam sistem loyalitas kami, rilis keluar setiap dua bulan. Artinya setiap dua bulan kita perlu melakukan regresi menyeluruh terhadap keseluruhan sistem. Pada saat yang sama, tentu saja, seperti halnya TI modern mana pun, pengembangan tidak langsung berpindah dari pengembang ke produksi. Itu berasal dari sirkuit pengembang, kemudian secara berturut-turut melewati bangku pengujian, rilis, penerimaan, dan baru kemudian berakhir di produksi. Minimal, pada sirkuit pengujian dan pelepasan, kita perlu melakukan regresi lengkap terhadap keseluruhan sistem.
Properti yang dijelaskan adalah standar untuk hampir semua sistem loyalitas. Mari kita bicara tentang fitur proyek kita.
Secara teknologi, 90% logika sistem loyalitas kami berbasis server dan diimplementasikan pada Oracle. Ada klien yang diekspos di Delphi, yang menjalankan fungsi administrator tempat kerja otomatis. Ada layanan web terbuka untuk aplikasi eksternal (misalnya situs web). Oleh karena itu, sangat logis jika kami menerapkan sistem pengujian otomatis, kami akan melakukannya di Oracle.
Sistem loyalitas di Sportmaster telah ada selama lebih dari 7 tahun dan diciptakan oleh pengembang tunggal... Rata-rata jumlah pengembang di proyek kami selama 7 tahun ini adalah 3-4 orang. Namun selama setahun terakhir, tim kami telah berkembang secara signifikan, dan sekarang ada 10 orang yang mengerjakan proyek tersebut. Artinya, orang-orang yang datang ke proyek tidak terbiasa dengan tugas, proses, dan arsitektur yang umum. Dan ada peningkatan risiko bahwa kita akan melewatkan kesalahan.
Proyek ini ditandai dengan tidak adanya penguji khusus sebagai unit staf. Tentu saja ada pengujian, tetapi pengujian dilakukan oleh analis, selain tanggung jawab utama mereka yang lain: berkomunikasi dengan pelanggan bisnis, pengguna, mengembangkan persyaratan sistem, dll. dll... Terlepas dari kenyataan bahwa pengujian dilakukan dengan kualitas yang sangat tinggi (hal ini sangat tepat untuk disebutkan, karena beberapa analis mungkin memperhatikan laporan ini), efektivitas spesialisasi dan konsentrasi pada satu hal belum dibatalkan .
Mempertimbangkan semua hal di atas, untuk meningkatkan kualitas produk yang dikirimkan dan mengurangi waktu pengembangan, gagasan untuk mengotomatiskan pengujian pada suatu proyek tampaknya sangat logis. Dan pada berbagai tahap keberadaan sistem loyalitas, masing-masing pengembang berupaya untuk menutupi kode mereka dengan pengujian unit. Secara keseluruhan, ini merupakan proses yang terputus-putus, dimana setiap orang menggunakan arsitektur dan metode mereka sendiri. Hasil akhirnya sama dengan pengujian unit: pengujian dikembangkan, digunakan selama beberapa waktu, disimpan dalam penyimpanan file berversi, namun pada titik tertentu pengujian tersebut berhenti berjalan dan dilupakan. Pertama-tama, hal ini disebabkan oleh fakta bahwa pengujian tersebut lebih terikat pada pelaku tertentu, dan bukan pada proyek.
utPLSQL datang untuk menyelamatkan
Tahukah Anda tentang Stephen Feuerstein?
Ini adalah orang cerdas yang mengabdikan sebagian besar karirnya untuk bekerja dengan Oracle dan PL/SQL, dan telah menulis cukup banyak karya tentang topik ini. Salah satu bukunya yang terkenal berjudul: “Oracle PL/SQL. Untuk para profesional." Stephen-lah yang mengembangkan solusi utPLSQL, atau singkatannya, kerangka Unit Testing untuk Oracle PL/SQL. Solusi utPLSQL dibuat pada tahun 2016, namun terus dikerjakan secara aktif dan versi baru dirilis. Pada saat pelaporan, versi terbaru berasal dari 24 Maret 2019.
Apa itu. Ini adalah proyek sumber terbuka terpisah. Beratnya beberapa megabyte, termasuk contoh dan dokumentasi. Secara fisik, ini adalah skema terpisah dalam database ORACLE dengan sekumpulan paket dan tabel untuk mengatur pengujian unit. Instalasi membutuhkan waktu beberapa detik. Ciri khas utPLSQL adalah kemudahan penggunaannya.
Secara global, utPLSQL adalah mekanisme untuk menjalankan pengujian unit, di mana pengujian unit dipahami sebagai prosedur batch Oracle biasa, yang pengorganisasiannya mengikuti aturan tertentu. Selain peluncuran, utPLSQL menyimpan log semua pengujian yang Anda jalankan, dan juga memiliki sistem pelaporan internal.
Mari kita lihat contoh kode pengujian unit yang diimplementasikan menggunakan teknik ini.
Jadi, layar menampilkan kode untuk spesifikasi paket tipikal dengan pengujian unit. Apa saja persyaratan wajibnya? Paket harus diawali dengan "utp_". Semua prosedur dengan tes harus memiliki awalan yang sama persis. Paket harus berisi dua prosedur standar: “utp_setup” dan “utp_teardown”. Prosedur pertama dipanggil dengan memulai ulang setiap pengujian unit, prosedur kedua - setelah peluncuran.
“utp_setup”, sebagai aturan, mempersiapkan sistem kami untuk menjalankan pengujian unit, misalnya, membuat data pengujian. "utp_teardown" - sebaliknya, semuanya kembali ke pengaturan awal dan mengatur ulang hasil peluncuran.
Berikut adalah contoh unit test paling sederhana yang memeriksa normalisasi nomor telepon pelanggan yang dimasukkan ke formulir standar untuk sistem loyalitas kami. Tidak ada standar wajib tentang cara menulis prosedur dengan unit test. Biasanya, panggilan dilakukan ke metode sistem yang diuji, dan hasil yang dikembalikan oleh metode ini dibandingkan dengan metode referensi. Penting agar hasil referensi dan hasil yang diperoleh dibandingkan melalui metode utPLSQL standar.
Tes unit dapat memiliki sejumlah pemeriksaan. Seperti yang dapat dilihat dari contoh, kami melakukan empat panggilan berturut-turut ke metode yang diuji untuk menormalkan nomor telepon dan mengevaluasi hasilnya setelah setiap panggilan. Saat mengembangkan pengujian unit, Anda harus memperhitungkan bahwa ada pemeriksaan yang tidak mempengaruhi sistem dengan cara apa pun, dan setelah beberapa pemeriksaan Anda perlu mengembalikan ke keadaan awal sistem.
Misalnya, dalam pengujian unit yang disajikan, kami hanya memformat nomor telepon yang dimasukkan, yang tidak memengaruhi sistem loyalitas dengan cara apa pun.
Dan jika kita menulis pengujian unit menggunakan metode membuat klien baru, maka setelah setiap pengujian, klien baru akan dibuat di sistem, yang dapat memengaruhi peluncuran pengujian berikutnya.
Beginilah cara pengujian unit dijalankan. Ada dua kemungkinan opsi peluncuran: menjalankan semua pengujian unit dari paket tertentu atau menjalankan pengujian unit tertentu dalam paket tertentu.
Seperti inilah contoh sistem pelaporan internal. Berdasarkan hasil pengujian unit, utPLSQL membuat laporan kecil. Di dalamnya kita melihat hasil untuk setiap pemeriksaan spesifik dan hasil keseluruhan dari pengujian unit.
6 aturan tes otomatis
Sebelum mulai membuat sistem baru untuk pengujian otomatis sistem loyalitas, bersama dengan manajemen, kami menentukan prinsip-prinsip yang harus dipatuhi oleh pengujian otomatis kami di masa mendatang.
- Autotest harus efektif dan bermanfaat. Kami memiliki pengembang yang luar biasa, yang tentunya perlu disebutkan, karena beberapa dari mereka mungkin akan melihat laporan ini, dan mereka menulis kode yang bagus. Tetapi bahkan kode mereka yang luar biasa pun tidaklah sempurna dan telah, telah, dan akan terus mengandung kesalahan. Tes otomatis diperlukan untuk menemukan kesalahan ini. Jika tidak demikian, maka kita sedang menulis autotest yang buruk, atau kita telah sampai pada area mati yang, pada prinsipnya, tidak dikembangkan. Dalam kedua kasus tersebut, kami melakukan sesuatu yang salah, dan pendekatan kami tidak masuk akal.
- Tes otomatis harus digunakan. Tidak masuk akal menghabiskan banyak waktu dan tenaga untuk menulis produk perangkat lunak, memasukkannya ke dalam repositori dan melupakannya. Pengujian harus dijalankan, dan dijalankan sesering mungkin.
- Tes otomatis harus bekerja secara stabil. Terlepas dari waktu, tempat peluncuran, dan pengaturan sistem lainnya, pengujian yang dijalankan akan memberikan hasil yang sama. Biasanya, hal ini dipastikan oleh fakta bahwa pengujian otomatis bekerja dengan data pengujian khusus dengan pengaturan sistem tetap.
- Tes otomatis harus bekerja pada kecepatan yang dapat diterima untuk proyek Anda. Waktu ini ditentukan secara individual untuk setiap sistem. Beberapa orang mampu bekerja sepanjang hari, sementara yang lain merasa penting untuk melakukannya dalam hitungan detik. Nanti saya akan memberi tahu Anda standar kecepatan apa yang kami capai dalam proyek kami.
- Pengembangan autotest harus fleksibel. Tidak disarankan untuk menolak menguji fungsionalitas apa pun hanya karena kita belum pernah melakukannya atau karena alasan lain. utPLSQL tidak memberlakukan batasan apa pun pada pengembangan, dan Oracle, pada prinsipnya, mengizinkan Anda mengimplementasikan berbagai hal. Kebanyakan masalah ada solusinya, ini hanya masalah waktu dan usaha.
- Kemampuan penerapan. Kami memiliki beberapa tempat di mana kami perlu menjalankan tes. Di setiap stand, dump data dapat diperbarui kapan saja. Penting untuk melakukan proyek dengan pengujian otomatis sedemikian rupa sehingga Anda dapat melakukan instalasi penuh atau sebagian tanpa rasa sakit.
Dan di postingan kedua beberapa hari lagi saya akan memberi tahu Anda apa yang kami lakukan dan hasil apa yang kami capai.
Sumber: www.habr.com