Halo, Habr!
Nama saya Maxim Ponomarenko dan saya seorang pengembang di Sportmaster. Saya memiliki 10 tahun pengalaman di bidang IT. Dia memulai karirnya dalam pengujian manual, kemudian beralih ke pengembangan basis data. Selama 4 tahun terakhir, mengumpulkan pengetahuan yang diperoleh dalam pengujian dan pengembangan, saya telah terlibat dalam otomatisasi pengujian di tingkat DBMS.
Saya telah menjadi bagian dari tim Sportmaster selama kurang lebih setahun dan saya terlibat dalam pengembangan pengujian otomatis pada salah satu proyek utama. Pada bulan April, orang-orang Lab Sportmaster dan saya berbicara di sebuah konferensi di Krasnodar, laporan saya disebut Tes Unit dalam DBMS, dan sekarang saya ingin membagikannya dengan Anda. Akan ada banyak teks, jadi saya memutuskan untuk membagi laporan menjadi dua posting. Pada bagian pertama kita akan berbicara tentang pengujian otomatis dan pengujian secara umum, dan pada bagian kedua saya akan membahas sistem pengujian unit kita dan hasil penerapannya.
Awalnya, sedikit teori membosankan. Apa itu pengujian otomatis? Ini adalah pengujian yang dilakukan oleh perangkat lunak, dan dalam TI modern semakin banyak digunakan dalam pengembangan perangkat lunak. Hal ini disebabkan oleh fakta bahwa perusahaan tumbuh, sistem informasi mereka tumbuh, dan karenanya jumlah fungsionalitas yang perlu diuji semakin meningkat. Melakukan pengujian manual menjadi semakin mahal.
Saya bekerja untuk satu perusahaan besar, yang rilisnya keluar setiap dua bulan. Pada saat yang sama, satu bulan dihabiskan untuk selusin penguji untuk memeriksa fungsionalitas dengan tangan mereka. Berkat pengenalan otomatisasi oleh tim kecil pengembang, kami berhasil mengurangi waktu pengujian menjadi 2 minggu dalam satu setengah tahun. Kami tidak hanya meningkatkan kecepatan pengujian, tetapi juga meningkatkan kualitasnya. Tes otomatis dijalankan secara teratur dan mereka selalu menyelesaikan seluruh rangkaian tes yang melekat di dalamnya, yaitu, kami mengecualikan faktor manusia.
TI modern dicirikan oleh fakta bahwa pengembang mungkin diminta tidak hanya untuk menulis kode produk, tetapi juga untuk menulis unit test yang memverifikasi kode ini.
Tetapi bagaimana jika sistem Anda didasarkan terutama pada logika server? Tidak ada solusi satu atap dan praktik terbaik di pasar. Sebagai aturan, perusahaan memecahkan masalah ini dengan menciptakan sistem pengujian yang mereka tulis sendiri. Sistem pengujian otomatis yang ditulis sendiri miliknya dibuat pada proyek kami, dan saya akan membicarakannya dalam laporan saya.
Menguji loyalitas
Pertama, mari kita bicara tentang proyek tempat kita menggunakan sistem pengujian otomatis. Proyek kami adalah sistem loyalitas Sportmaster (omong-omong, kami sudah menulisnya di
posting ini ).
Jika perusahaan Anda cukup besar, maka sistem loyalitas Anda akan memiliki tiga properti standar:
- Sistem Anda akan sangat dimuat.
- Sistem Anda akan berisi proses komputasi yang rumit.
- Sistem Anda akan dikembangkan secara aktif.
Mari kita mulai. Sportmaster memiliki sejumlah besar toko yang aktif berjualan. Secara alami, sistem loyalitas adalah sistem yang sangat sarat muatan. Dan karena proyek ini aktif digunakan, maka kita harus memberikan standar kualitas tertinggi, karena kesalahan dalam perangkat lunak adalah banyak uang, reputasi dan kerugian lainnya.
Pada saat yang sama, lebih dari seratus promosi berbeda bekerja di Sportmaster. Sahamnya sangat berbeda: ada yang komoditas, ada waktunya untuk hari dalam seminggu, ada terikat ke toko tertentu, ada saham dalam jumlah cek, ada jumlah barang. Secara umum, tidak lemah. Pelanggan mendapat bonus, ada kode promosi yang digunakan saat berbelanja. Semua ini mengarah pada fakta bahwa perhitungan urutan apa pun adalah tugas yang sangat sepele.
Algoritma yang mengimplementasikan pemrosesan pesanan benar-benar mengerikan dan rumit. Dan setiap perubahan pada algoritma ini adalah hal yang sangat berisiko. Tampaknya ada perubahan kecil yang paling luar yang dapat menyebabkan efek yang agak tidak terduga. Tetapi justru proses komputasional yang sedemikian kompleks, apalagi yang menerapkan fungsi kritis yang merupakan kandidat terbaik untuk otomatisasi. Memeriksa lusinan kasing dengan jenis yang sama dengan tangan Anda sangat memakan waktu. Dan karena titik masuk ke proses tidak berubah, setelah menjelaskannya, Anda dapat dengan cepat mencap pengujian otomatis dan memastikan fungsionalitasnya.
Karena sistem kami digunakan secara aktif, bisnis akan menginginkan sesuatu yang baru dari Anda, hidup terbaru dan berorientasi pelanggan. Dalam sistem loyalitas kami, rilis dirilis setiap dua bulan. Jadi, setiap dua bulan kita perlu melakukan regresi lengkap dari keseluruhan sistem. Pada saat yang sama, tentu saja, seperti halnya TI modern, pengembangan tidak langsung datang dari pengembang ke produksi. Itu berasal dari sirkuit pengembang, kemudian secara berurutan melewati tempat uji, rilis, penerimaan, dan hanya kemudian diproduksi. Setidaknya pada pengujian dan rilis sirkuit, kita perlu melakukan regresi lengkap dari keseluruhan sistem.
Properti yang dijelaskan adalah standar untuk hampir semua sistem loyalitas. Mari kita bicara tentang fitur-fitur proyek kami.
Secara teknologi, 90% logika sistem loyalitas kami berbasis server dan diimplementasikan pada Oracle. Ada klien yang terbuka di Delphi, yang melakukan fungsi administrator AWP. Ada layanan web terbuka untuk aplikasi eksternal (seperti situs web). Oleh karena itu, sangat logis bahwa jika kami menggunakan sistem pengujian otomatis, kami akan melakukannya pada Oracle.
Sistem loyalitas di Sportmaster telah ada selama lebih dari 7 tahun dan diciptakan oleh pengembang tunggal ... Jumlah rata-rata pengembang di proyek kami selama 7 tahun ini adalah 3-4 orang. Namun selama setahun terakhir, tim kami telah tumbuh secara signifikan, dan sekarang 10 orang sedang mengerjakan proyek. Artinya, orang yang tidak terbiasa dengan tugas-tugas khas, proses, arsitektur datang ke proyek. Dan ada peningkatan risiko bahwa kita akan melewatkan kesalahan.
Proyek ini ditandai dengan tidak adanya penguji yang berdedikasi sebagai unit staf. Pengujian, tentu saja, adalah, tetapi analis terlibat dalam pengujian, di samping tanggung jawab utama mereka yang lain: berkomunikasi dengan pelanggan bisnis, pengguna, mengerjakan persyaratan sistem, dll. dll ... Terlepas dari kenyataan bahwa pengujian dilakukan dengan sangat kualitatif (ini sangat tepat untuk disebutkan, karena salah satu analis dapat menarik perhatian laporan ini), tidak ada yang membatalkan efektivitas spesialisasi dan konsentrasi pada satu hal.
Mengingat semua hal di atas, untuk meningkatkan kualitas produk yang dikeluarkan dan mengurangi waktu pengembangan, gagasan mengotomatisasi pengujian pada proyek tersebut tampaknya sangat logis. Dan pada berbagai tahap keberadaan sistem loyalitas, pengembang individu melakukan upaya untuk menutupi kode mereka dengan unit test. Itu umumnya proses yang agak berbeda di mana semua orang menggunakan arsitektur dan metode mereka. Tes unit adalah umum untuk hasil akhir: tes dikembangkan, digunakan untuk beberapa waktu, ditumpuk dalam penyimpanan file berversi, tetapi pada beberapa titik mereka berhenti memulai dan lupa. Ini terutama karena fakta bahwa tes lebih terikat pada pemain tertentu, bukan ke proyek.
UtPLSQL hadir untuk menyelamatkan
Apakah Anda tahu sesuatu tentang Stephen Feuerstein?
Ini adalah orang pintar yang mengabdikan sebagian besar karirnya untuk bekerja dengan Oracle dan dengan PL / SQL, menulis sejumlah besar karya tentang topik ini. Salah satu bukunya yang terkenal disebut: "Oracle PL / SQL. Untuk para profesional. " Adalah Steven yang memiliki pengembangan solusi utPLSQL, atau, sebagaimana kepanjangan dari, kerangka kerja Unit Testing untuk Oracle PL / SQL. Solusi utPLSQL dibuat pada tahun 2016, tetapi mereka terus bekerja secara aktif dan merilis versi baru. Pada saat laporan, versi terbaru bertanggal 24 Maret 2019.
Apa ini Ini adalah proyek open source terpisah. Beratnya beberapa megabyte, dengan mempertimbangkan contoh akun dan dokumentasi. Secara fisik, ini adalah skema terpisah dalam database ORACLE dengan satu set paket dan tabel untuk mengatur pengujian unit. Instalasi membutuhkan beberapa detik. Fitur khas utPLSQL adalah kemudahan penggunaannya.
Secara global, utPLSQL adalah mekanisme untuk menjalankan tes unit, di mana tes unit mengacu pada prosedur batch Oracle reguler, organisasi yang mengikuti aturan tertentu. Selain peluncuran, utPLSQL menyimpan log dari semua uji coba Anda, dan ada juga sistem pelaporan internal.
Mari kita lihat contoh bagaimana kode tes unit diimplementasikan oleh teknik ini terlihat.
Jadi, layar memperlihatkan kode untuk spesifikasi standar suatu paket dengan unit test. Apa persyaratan yang dibutuhkan? Paket harus memiliki awalan utp_. Semua prosedur dengan tes harus memiliki awalan yang persis sama. Paket harus berisi dua prosedur standar: "utp_setup" dan "utp_teardown". Prosedur pertama disebut dengan memulai kembali setiap tes unit, yang kedua - setelah memulai.
"Utp_setup", sebagai suatu peraturan, menyiapkan sistem kami untuk menjalankan tes unit, misalnya, membuat data uji. "Utp_teardown" - sebaliknya, semuanya kembali ke pengaturan aslinya dan mengatur ulang hasil peluncuran.
Berikut ini adalah contoh unit test paling sederhana, yang memeriksa normalisasi nomor telepon pelanggan yang dimasukkan ke tampilan standar untuk sistem loyalitas kami. Tidak ada standar wajib untuk prosedur penulisan dengan tes unit. Sebagai aturan, metode sistem yang diuji disebut, dan hasil yang dikembalikan oleh metode ini dibandingkan dengan yang referensi. Penting bahwa perbandingan hasil referensi dan hasilnya terjadi melalui metode standar utPLSQL.
Tes unit dapat memiliki sejumlah cek. Seperti yang dapat Anda lihat dari contoh, kami melakukan empat panggilan berurutan dari metode yang diuji untuk menormalkan nomor telepon dan setelah setiap panggilan kami mengevaluasi hasilnya. Ketika mengembangkan tes unit, seseorang harus memperhitungkan bahwa ada cek yang tidak mempengaruhi sistem dengan cara apa pun, dan setelah beberapa, perlu untuk kembali ke keadaan awal sistem.
Misalnya, dalam pengujian unit yang disajikan, kami cukup memformat nomor telepon input, yang tidak mempengaruhi sistem loyalitas.
Dan jika kita menulis unit test menggunakan metode menciptakan klien baru, maka setelah setiap pemeriksaan klien baru akan dibuat dalam sistem, yang dapat mempengaruhi peluncuran tes berikutnya.
Ini adalah cara unit test dijalankan. Ada dua opsi peluncuran yang mungkin: memulai semua tes unit dari paket tertentu atau memulai tes unit spesifik dalam paket tertentu.
Berikut adalah contoh sistem pelaporan internal. Menurut hasil pengujian unit, utPLSQL membuat laporan kecil. Di dalamnya kita melihat hasil dari setiap tes khusus dan hasil keseluruhan dari tes unit.
6 aturan autotest
Sebelum mulai membuat sistem baru untuk pengujian otomatis sistem loyalitas, bersama dengan manajemen, kami menentukan prinsip-prinsip yang harus dipenuhi oleh pengujian otomatis kami di masa mendatang.
- Tes otomatis harus efektif dan harus bermanfaat. Kami memiliki pengembang yang hebat, yang harus saya katakan, karena salah satu dari mereka mungkin akan melihat laporan ini, dan mereka menulis kode yang luar biasa. Tetapi bahkan kode mereka yang luar biasa tidak sempurna dan berisi, berisi dan akan mengandung kesalahan. Autotests diperlukan untuk menemukan kesalahan ini. Jika tidak demikian, maka kita bisa menulis swa-uji yang buruk, atau kita sampai pada area mati, yang, pada prinsipnya, tidak sedang diselesaikan. Dalam kedua kasus, kami melakukan sesuatu yang salah, dan pendekatan kami sama sekali tidak berarti.
- Tes otomatis harus digunakan. Tidak masuk akal untuk menghabiskan banyak waktu dan upaya menulis produk perangkat lunak, menambah repositori dan melupakannya. Tes harus dijalankan dan berjalan sesering mungkin.
- Autotests harus bekerja secara stabil. Terlepas dari waktu hari, dudukan peluncuran, atau pengaturan sistem lainnya, menjalankan tes harus mengarah pada hasil yang sama. Sebagai aturan, ini dipastikan oleh fakta bahwa autotests bekerja dengan data uji 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. Seseorang dapat bekerja sepanjang hari, dan seseorang secara kritis cocok dengan detik-detiknya. Standar kecepatan apa yang telah kami capai dalam proyek kami, akan saya sampaikan nanti.
- Pengembangan autotest harus fleksibel. Tidak diinginkan untuk menolak menguji fungsi apa pun hanya karena kami belum melakukannya atau untuk beberapa keyakinan lain. utPLSQL tidak mengenakan batasan pengembangan apa pun, dan Oracle, pada prinsipnya, memungkinkan Anda untuk mengimplementasikan berbagai hal. Sebagian besar tugas memiliki solusi, satu-satunya pertanyaan adalah waktu dan usaha.
- Deployability. Kami memiliki beberapa stan di mana Anda perlu menjalankan tes. Di setiap tribun, tempat pembuangan data dapat diperbarui kapan saja. Diperlukan untuk melakukan proyek dengan autotest sedemikian rupa agar tidak dapat melakukan instalasi penuh atau sebagian tanpa rasa sakit.
Dan di pos kedua dalam beberapa hari saya akan memberi tahu Anda apa yang telah kami lakukan dan hasil apa yang telah dicapai.