Bagian pertama ada di sini .
Bayangkan situasinya. Anda dihadapkan pada tugas mengembangkan fungsionalitas baru. Anda memiliki perkembangan dari para pendahulu Anda. Dengan asumsi Anda tidak memiliki kewajiban moral, apa yang akan Anda lakukan?
Paling sering, semua prestasi 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 yang khas, dan sebagian besar benar. Tetapi dalam proyek kami kami melakukan kesalahan. Kami meletakkan dasar untuk sistem pengujian otomatis masa depan berdasarkan pengujian unit pada utPLSQL dari para pendahulu kami, dan kemudian mulai bekerja dalam beberapa arah paralel.
- Kembalikan tes unit lama. Pemulihan mengacu pada mengadaptasi tes dengan keadaan yang ada dari sistem loyalitas dan mengadaptasi tes dengan standar utPLSQL.
- Solusi untuk masalah dengan pemahaman, dan apa tepatnya, metode dan proses apa, kita dilindungi oleh autotest. Anda harus mengingat informasi ini atau menarik kesimpulan berdasarkan kode autotest itu sendiri. Karena itu, kami memutuskan untuk membuat katalog. Kami menetapkan kode mnemonik unik untuk setiap autotest, membentuk deskripsi dan memperbaiki pengaturan (misalnya, dalam kondisi apa ia harus dimulai, atau apa yang harus terjadi jika pengujian gagal). Pada dasarnya, kami mengisi metadata tentang autotests dan memasukkan metadata ini ke tabel skema utPLSQL standar.
- Menentukan strategi ekspansi, mis. pemilihan fungsi untuk diperiksa oleh autotest. Kami memutuskan untuk memperhatikan tiga hal: peningkatan sistem baru, insiden produksi, dan proses sistem utama. Dengan demikian, kami mengembangkan secara paralel dengan rilis, memberikan kualitas yang lebih tinggi, secara bersamaan memperluas volume regresi dan memastikan keandalan sistem di tempat-tempat kritis. Hambatan pertama seperti itu adalah proses mendistribusikan diskon dan bonus pada cek.
- Secara alami, kami mulai mengembangkan autotest baru. Salah satu tugas rilis pertama adalah untuk mengevaluasi kinerja sampel yang telah ditentukan dari sistem loyalitas. Dalam proyek kami, ada blok kueri sql yang diperbaiki secara kaku yang memilih klien sesuai dengan kondisi. Misalnya, dapatkan daftar semua pelanggan yang pembelian terakhirnya di kota tertentu, atau daftar pelanggan yang jumlah pembelian rata-rata di atas nilai tertentu. Setelah autotest tertulis, kami memeriksa sampel yang telah ditentukan, memperbaiki parameter kinerja referensi, dan selain itu kami memiliki pengujian beban.
- Bekerja dengan autotest seharusnya nyaman . Paling sering, dua tindakan dilakukan: menjalankan autotest dan membuat data uji. Jadi di sistem kami dua modul tambahan muncul: modul peluncuran dan modul pembuatan data.
Peluncur disajikan sebagai prosedur universal tunggal dengan satu parameter teks input. Sebagai parameter, Anda dapat meneruskan kode mnemonik autotest, nama paket, nama tes, pengaturan autotest atau kata kunci yang dipesan. Prosedur memilih dan menjalankan semua pemeriksaan otomatis yang memenuhi persyaratan.
Modul pembuatan data disajikan dalam bentuk paket di mana untuk setiap objek sistem yang diuji (tabel dalam database), dibuat prosedur khusus yang memasukkan data di sana. Dalam prosedur ini, nilai-nilai default diisi sebanyak mungkin, yang memastikan pembuatan objek dengan klik jari. Dan untuk kemudahan penggunaan, template untuk data yang dihasilkan dibuat. Misalnya, buat klien dengan usia tertentu dengan telepon percobaan dan pembelian sempurna. - Autotes harus dijalankan dan dijalankan pada waktu yang dapat diterima untuk sistem Anda. Oleh karena itu, peluncuran setiap malam diselenggarakan, yang hasilnya menghasilkan laporan tentang hasil dan mengirimkannya ke seluruh tim pengembangan melalui surat perusahaan. Setelah mengembalikan autotest lama dan membuat yang baru, total waktu operasi adalah 30 menit. Performa seperti itu cocok untuk semua orang, sejak peluncuran berlangsung setelah jam.
Tetapi saya harus berusaha mengoptimalkan kecepatan kerja. Memperbarui sistem loyalitas pada produksi dilakukan pada malam hari. Sebagai bagian dari salah satu rilis, saya harus segera melakukan perubahan di malam hari. Setengah jam menunggu hasil autotest pada pukul tiga pagi tidak membuat orang yang bertanggung jawab atas pembebasan bahagia (salam berapi-api untuk Alexei Vasyukov!), Dan keesokan paginya banyak kata-kata hangat diucapkan ke arah sistem kami. Tetapi berdasarkan hasil, standar kerja 5 menit ditetapkan.
Untuk mempercepat kinerja, kami menggunakan dua metode: autotests mulai berjalan dalam tiga utas paralel, yang sangat nyaman karena arsitektur sistem loyalitas kami. Dan kami meninggalkan pendekatan ketika autotest tidak membuat data uji untuk dirinya sendiri, tetapi mencoba untuk menemukan sesuatu yang cocok dalam sistem. Setelah melakukan perubahan, total waktu operasi dikurangi menjadi 3-4 menit. - Proyek dengan tes otomatis harus dapat digunakan di berbagai stan. Pada awal perjalanan ada upaya untuk menulis file batch Anda sendiri, tetapi menjadi jelas bahwa instalasi otomatis yang ditulis sendiri adalah horor, dan kami beralih ke solusi industri. Karena fakta bahwa proyek memiliki banyak kode langsung (pertama-tama, kami menyimpan kode untuk autotest) dan sangat sedikit data (data utama adalah metadata tentang autotest), ternyata sangat mudah untuk memperkenalkan Liquibase ke dalam proyek.
Ini adalah pustaka sumber-independen basis data untuk melacak, mengelola, dan menerapkan perubahan skema basis data. Dikelola melalui baris perintah atau kerangka kerja seperti Apache Maven. Prinsip operasi Liquibase cukup sederhana. Kami memiliki proyek yang diatur dengan cara tertentu, yang terdiri dari perubahan atau skrip yang perlu digulirkan ke server target, dan mengontrol file yang menentukan dalam urutan apa dan dengan parameter apa perubahan ini harus diinstal.
Di tingkat DBMS, tabel khusus dibuat di mana Liquibase menyimpan run log. Setiap perubahan memiliki hash yang dihitung, yang dibandingkan setiap kali antara proyek dan negara dalam database. Berkat Liquibase, kami dapat dengan mudah menggulirkan perubahan sistem kami ke sirkuit apa pun. Autotests sekarang berjalan pada uji dan melepaskan loop, serta pada wadah (loop pribadi pengembang).
Jadi, mari kita bicara tentang hasil penerapan sistem pengujian unit kami.
- Tentu saja, pertama-tama, kami yakin bahwa kami mulai mengembangkan perangkat lunak yang lebih baik. Tes otomatis berjalan setiap hari dan menemukan puluhan kesalahan setiap tahun. Selain itu, beberapa kesalahan ini hanya secara tidak langsung terkait dengan fungsi yang benar-benar ingin kami ubah. Ada keraguan besar bahwa kesalahan ini ditemukan oleh pengujian manual.
- Tim memperoleh kepercayaan bahwa fungsi spesifik berfungsi dengan benar ... Pertama-tama, ini menyangkut proses penting kami. Misalnya, selama enam bulan terakhir, kami tidak memiliki masalah dengan distribusi diskon dan bonus pada cek, meskipun ada perubahan dalam rilis, meskipun pada periode sebelumnya kesalahan terjadi pada beberapa interval
- Kami dapat mengurangi jumlah iterasi pengujian. Karena fakta bahwa autotests ditulis untuk fungsionalitas baru, analitik dan penguji paruh waktu mendapatkan kode berkualitas lebih tinggi, karena Sudah diverifikasi.
- Bagian dari pengembangan pengujian otomatis digunakan oleh pengembang. Misalnya, data uji pada wadah dibuat menggunakan modul pembuatan objek.
- Penting bahwa kami telah mengembangkan "adopsi" sistem pengujian otomatis oleh pengembang. Ada pemahaman bahwa ini penting dan bermanfaat. Dan dari pengalaman saya sendiri, saya dapat mengatakan bahwa ini jauh dari kasus. Autotests harus ditulis, harus dipelihara dan dikembangkan, hasilnya harus dianalisis, dan seringkali biaya waktu ini tidak sepadan. Jauh lebih mudah untuk pergi ke produksi dan menangani masalah di sana. Di tempat kami, pengembang berbaris dan meminta untuk menutup fungsinya dengan tes otomatis.
Apa selanjutnya
Mari kita bicara tentang rencana pengembangan untuk proyek pengujian otomatis.
Tentu saja, sementara sistem loyalitas Sportmaster masih hidup dan terus berkembang, juga mungkin untuk mengembangkan tes mandiri hampir tanpa akhir. Oleh karena itu, arah utama pembangunan adalah perluasan wilayah cakupan.
Ketika jumlah autotests meningkat, total waktu kerja mereka akan tumbuh dengan mantap, dan kita harus kembali ke masalah produktivitas. Kemungkinan besar, solusinya adalah meningkatkan jumlah utas paralel.
Tapi ini adalah jalur pengembangan yang jelas. Jika kita berbicara tentang sesuatu yang lebih sepele, kita menyoroti yang berikut ini:
- Saat ini, autotest dikelola di tingkat DBMS, mis. Anda membutuhkan pengetahuan PL / SQL agar berhasil. Jika perlu, kontrol sistem (misalnya, meluncurkan atau membuat metadata), Anda dapat membuat semacam panel admin menggunakan Jenkins atau yang serupa.
- Semua orang menyukai indikator kuantitatif dan kualitatif. Untuk pengujian otomatis, metrik universal semacam itu adalah Cakupan Kode atau metrik cakupan kode. Dengan menggunakan indikator ini, kita dapat menentukan persentase kode sistem pengujian kita yang dicakup oleh autotest. Dimulai dengan versi 12.2, Oracle menyediakan kemampuan untuk menghitung metrik ini dan menyarankan menggunakan paket standar DBMS_PLSQL_CODE_COVERAGE.
Sistem autotest kami sedikit lebih dari setahun, dan mungkin sekarang adalah waktu untuk mengevaluasi cakupan. Dalam proyek masa lalu saya (proyek bukan Sportmaster) itu terjadi. Setahun setelah bekerja pada autotests, manajemen menetapkan tujuan untuk menilai berapa persen dari kode yang kita bahas. Dengan cakupan lebih dari 1%, manajemen akan senang. Kami, para pengembang, mengharapkan hasil sekitar 10%. Cakupan kode kacau, diukur, menerima 20%. Untuk merayakan, kami pergi untuk hadiah, tetapi bagaimana kami pergi untuk itu dan di mana kami pergi kemudian adalah cerita yang sama sekali berbeda. - Tes otomatis dapat memeriksa layanan web yang terbuka. Oracle memungkinkan Anda untuk melakukan ini, dan kami tidak akan lagi menghadapi sejumlah masalah.
- Dan, tentu saja, sistem pengujian otomatis kami dapat diterapkan pada proyek lain. Solusi kami bersifat universal dan hanya membutuhkan penggunaan Oracle. Saya mendengar bahwa pada proyek-proyek Sportmaster lain ada minat dalam pengujian otomatis dan, mungkin, kita akan pergi ke mereka.
Kesimpulan
Mari kita simpulkan. Pada proyek tersebut, sistem loyalitas di Sportmaster kami berhasil menerapkan sistem pengujian otomatis. Dasarnya adalah solusi utPLSQL dari Stephen Feuerstein. Sekitar utPLSQL adalah kode autotest dan modul yang ditulis sendiri tambahan: modul peluncuran, modul pembuatan data, dan lainnya. Tes otomatis berjalan setiap hari dan, yang paling penting, bekerja dan membawa manfaat. Kami yakin bahwa kami telah mulai merilis perangkat lunak berkualitas lebih tinggi. Pada saat yang sama, solusi yang dihasilkan bersifat universal dan dapat diterapkan secara bebas pada proyek mana pun yang diperlukan untuk mengatur pengujian otomatis pada Oracle DBMS.
PS Artikel ini tidak terlalu spesifik: ada banyak teks dan hampir tidak ada contoh teknis. Jika topik ini 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 difokuskan di masa depan, atau pertanyaan yang perlu diungkapkan.