Tes unit ing DBMS - kepiye carane nindakake ing Sportmaster, bagean loro

Bagian pisanan- kene.

Mbayangno kahanan. Sampeyan ngadhepi tugas ngembangake fungsi anyar. Sampeyan duwe pangembangan saka sadurunge. Yen kita nganggep sampeyan ora duwe kewajiban moral, apa sing bakal sampeyan lakoni?

Paling asring, kabeh pembangunan lawas dilalekake lan kabeh diwiwiti maneh. Ora ana sing seneng nggali kode wong liya, nanging yen sampeyan duwe wektu, kenapa ora miwiti nggawe sistem sampeyan dhewe? Iki minangka pendekatan khas, lan umume bener. Nanging ing proyek kita nindakake salah. Kita adhedhasar sistem tes otomatis ing mangsa ngarep babagan pangembangan tes unit ing utPLSQL saka para leluhur, lan banjur kerja ing sawetara arah sing sejajar.

1. Mulihake tes unit lawas. Recovery tegese nyesuekake tes kanggo negara ana sistem kasetyan lan adaptasi tes kanggo standar utPLSQL.
2. Ngatasi masalah karo pangerten apa persis, apa cara lan pangolahan dijamin karo autotests. Sampeyan kudu nyimpen informasi iki ing sirah, utawa nggawe kesimpulan adhedhasar kode autotest. Mulane, kita mutusake kanggo nggawe katalog. Kita menehi kode mnemonic unik kanggo saben autotest, nggawe deskripsi lan setelan sing direkam (contone, ing kahanan apa sing kudu diluncurake, utawa apa sing kudu kedadeyan yen peluncuran tes gagal). Intine, kita ngisi metadata babagan autotes lan nyelehake metadata kasebut menyang tabel skema utPLSQL standar.
3. Nemtokake strategi expansion, i.e. pilihan fungsi sing tundhuk verifikasi dening tes otomatis. Kita mutusake kanggo menehi perhatian marang telung perkara: perbaikan sistem anyar, kedadeyan produksi, lan proses sistem kunci. Mangkono, kita ngembangake sejajar karo release, njamin kualitas sing luwih dhuwur, bebarengan ngembangake ruang lingkup kemunduran lan njamin linuwih sistem ing panggonan kritis. Kemacetan pisanan kasebut yaiku proses nyebarake diskon lan bonus ing cek.
4. Alami, kita miwiti ngembangake autotes anyar. Salah sawijining tugas rilis pisanan yaiku ngevaluasi kinerja conto sistem kesetiaan sing wis ditemtokake. Proyek kita duwe blok pitakon SQL sing tetep kaku sing milih klien adhedhasar kahanan. Contone, entuk dhaptar kabeh pelanggan sing tuku pungkasan ing kutha tartamtu, utawa dhaptar pelanggan sing jumlah tuku rata-rata ngluwihi nilai tartamtu. Kanthi tes otomatis sing ditulis, kita mriksa conto sing wis ditemtokake, paramèter kinerja benchmark sing direkam, lan uga ana uji coba beban.
5. Nggarap tes otomatis kudu trep. Rong tumindak sing paling umum yaiku nglakokake tes otomatis lan nggawe data tes. Iki carane rong modul tambahan muncul ing sistem kita: modul peluncuran lan modul generasi data.

   Peluncur diwakili minangka prosedur universal kanthi siji parameter input teks. Minangka parameter, sampeyan bisa ngliwati kode mnemonik tes otomatis, jeneng paket, jeneng tes, setelan tes otomatis, utawa tembung kunci sing dilindhungi. Prosedur milih lan mbukak kabeh tes otomatis sing nyukupi kahanan kasebut.

   Modul generasi data ditampilake ing wangun paket sing kanggo saben obyek sistem sing diuji (tabel ing database), prosedur khusus wis digawe sing nglebokake data ing kana. Ing prosedur iki, nilai standar diisi sabisa-bisa, sing njamin nggawe obyek kanthi harfiah kanthi ngeklik driji. Lan supaya gampang digunakake, template kanggo data sing digawe digawe. Contone, nggawe klien umur tartamtu karo telpon test lan tuku rampung.

6. Autotests kudu diwiwiti lan mbukak ing wektu sing bisa ditampa kanggo sistem sampeyan. Mulane, peluncuran wengi saben dina dianakake, adhedhasar asil laporan asil digawe lan dikirim menyang kabeh tim pangembangan liwat surat perusahaan. Sawise mulihake tes otomatis lawas lan nggawe sing anyar, total wektu operasi yaiku 30 menit. Kinerja iki cocog karo kabeh wong, amarga diluncurake ing njaba jam kerja.

   Nanging kita kudu ngupayakake ngoptimalake kacepetan kerja. Sistem kesetiaan ing produksi dianyari ing wayah wengi. Minangka bagéan saka salah sawijining rilis, kita kudu nggawe owah-owahan sing penting ing wayah wengi. Nunggu setengah jam kanggo asil autotests ing jam telu esuk ora nggawe wong sing tanggung jawab kanggo release seneng (salam semangat kanggo Alexey Vasyukov!), Lan esuk akeh tembung apik ngandika marang sistem kita. Nanging minangka asil, standar 5 menit kanggo karya ditetepake.

   Kanggo nyepetake kinerja, kita nggunakake rong cara: autotests wiwit mbukak ing telung thread paralel, bok manawa iki trep banget amarga arsitektur sistem kasetyan kita. Lan kita nilar pendekatan ngendi autotest ora nggawe data test kanggo dhewe, nanging nyoba kanggo golek soko cocok ing sistem. Sawise nggawe pangowahan, total wektu operasi dikurangi dadi 3-4 menit.

7. Proyek kanthi tes otomatis kudu bisa dipasang ing macem-macem stand. Ing wiwitan lelungan, ana upaya kanggo nulis file batch dhewe, nanging dadi jelas manawa instalasi otomatis sing ditulis dhewe pancen medeni, lan kita nguripake solusi industri. Amarga kasunyatan manawa proyek kasebut ngemot akeh kode langsung (pisanan, kita nyimpen kode autotest) lan data sithik banget (data utama yaiku metadata babagan autotes), implementasine ing proyek Liquibase dadi gampang banget.

   Iki minangka perpustakaan sing mbukak-sumber, bebas basis data kanggo nelusuri, ngatur, lan ngetrapake owah-owahan skema database. Ngatur liwat baris perintah utawa kerangka kerja kayata Apache Maven. Prinsip operasi Liquibase cukup prasaja. Kita duwe proyek sing diatur kanthi cara tartamtu, sing kalebu owah-owahan utawa skrip sing kudu diluncurake menyang server target, lan file kontrol sing nemtokake urutan lan parameter apa sing kudu diinstal.

   Ing tingkat DBMS, tabel khusus digawe ing ngendi Liquibase nyimpen log rollover. Saben pangowahan nduweni hash sing diwilang, sing dibandhingake saben wektu antarane proyek lan negara ing basis data. Thanks kanggo Liquibase, kita bisa kanthi gampang ngowahi owah-owahan ing sistem menyang sirkuit apa wae. Autotests saiki diluncurake ing sirkuit test lan release, uga ing wadhah (sirkuit pribadi pangembang).

Dadi, ayo ngomong babagan asil nggunakake sistem tes unit.

1. Mesthine, pisanan, kita yakin yen kita wis mulai ngembangake piranti lunak sing luwih apik. Autotests diluncurake saben dina lan puluhan kesalahan ditemokake saben rilis. Kajaba iku, sawetara kesalahan kasebut mung ana hubungane kanthi ora langsung karo fungsi sing pancene pengin diganti. Ana keraguan serius manawa kesalahan kasebut ditemokake kanthi tes manual.
2. Tim saiki duwe kapercayan manawa fungsi tartamtu bisa digunakake kanthi bener... Kaping pisanan, iki gegayutan karo proses kritis kita. Contone, sajrone nem sasi kepungkur, kita ora duwe masalah babagan distribusi diskon lan bonus ing kuitansi, sanajan ana owah-owahan rilis, sanajan ing wektu sadurunge ana kesalahan karo sawetara frekuensi.
3. Kita bisa nyuda jumlah pengulangan tes. Amarga kasunyatan manawa tes otomatis ditulis kanggo fungsi anyar, analis lan penguji paruh wektu nampa kode kanthi kualitas sing luwih dhuwur, amarga wis dipriksa.
4. Sawetara pangembangan tes otomatis digunakake dening pangembang. Contone, data test ing kontaner digawe nggunakake modul generasi obyek.
5. Penting yen kita wis ngembangake "penerimaan" sistem tes otomatis saka pangembang. Ana pangerten yen iki penting lan migunani. Nanging saka pengalaman dhewe aku bisa ngomong sing iki adoh saka cilik. Autotests kudu ditulis, kudu didhukung lan dikembangake, asil kudu dianalisis, lan asring biaya wektu iki mung ora pantes. Iku luwih gampang kanggo pindhah menyang produksi lan menehi hasil karo masalah ana. Ing kene, pangembang baris lan njaluk supaya kita nutupi fungsi kanthi autotes.

Apa mbesuk

Ayo dadi pirembagan bab rencana pembangunan kanggo proyek testing otomatis.

Mesthi, anggere sistem kasetyan Sportmaster urip lan terus kanggo berkembang, iku uga bisa kanggo berkembang autotests meh endlessly. Mulane, arah utama pembangunan yaiku ngembangake area jangkoan.

Minangka nomer autotests mundhak, total wektu operasi bakal terus nambah, lan kita bakal maneh kudu bali menyang masalah kinerja. Paling kamungkinan, solusi bakal nambah jumlah benang paralel.

Nanging iki minangka cara pangembangan sing jelas. Yen kita ngomong babagan sing luwih ora pati penting, kita nyorot ing ngisor iki:

1. Saiki, manajemen tes otomatis ditindakake ing tingkat DBMS, yaiku. kawruh PL / SQL dibutuhake kanggo karya sukses. Yen perlu, manajemen sistem (contone, ngluncurake utawa nggawe metadata), sampeyan bisa nggawe sawetara panel admin nggunakake Jenkins utawa sing padha.
2. Saben uwong seneng indikator kuantitatif lan kualitatif. Kanggo tes otomatis, indikator universal kasebut yaiku Cakupan Kode utawa metrik jangkoan kode. Nggunakake indikator iki, kita bisa nemtokake persentase kode sistem sing dites sing dilindhungi dening tes otomatis. Wiwit saka versi 12.2, Oracle menehi kemampuan kanggo ngetung metrik iki lan nawakake panggunaan paket DBMS_PLSQL_CODE_COVERAGE standar.

   Sistem autotest kita mung luwih saka setahun lan mbok menawa saiki iki wektu kanggo ngevaluasi jangkoan kita. Ing proyek pungkasan (dudu proyek Sportmaster) iki kedadeyan. Setaun sawise nggarap tes otomatis, manajemen nyetel tugas kanggo ngevaluasi persentase kode sing kita tutupi. Kanthi jangkoan luwih saka 1%, manajemen bakal seneng. Kita, pangembang, ngarepake asil kira-kira 10%. Kita nginstal jangkoan kode, ngukur, lan entuk 20%. Kanggo ngrameke, kita lunga kanggo entuk hadiah, nanging kepiye carane entuk lan menyang ngendi mengko, critane beda banget.

3. Autotests bisa mriksa layanan web sing kapapar. Oracle ngidini kita nindakake iki kanthi becik, lan kita ora bakal nemoni sawetara masalah maneh.
4. Lan, mesthi, sistem tes otomatis bisa ditrapake ing proyek liyane. Solusi sing ditampa iku universal lan mung mbutuhake panggunaan Oracle. Aku krungu proyek Sportmaster liyane kasengsem ing testing otomatis lan mbok menawa kita bakal pindhah menyang wong.

temonan

Ayo ngringkes. Ing project sistem kasetyan ing Sportmaster, kita ngatur kanggo ngleksanakake sistem testing otomatis. Iki adhedhasar solusi utPLSQL saka Stephen Feuerstein. Ing saubengé utPLSQL ana kode tes otomatis lan modul tulisan dhéwé tambahan: modul peluncuran, modul generasi data lan liya-liyane. Autotests diluncurake saben dina lan, sing paling penting, bisa digunakake lan migunani. Kita manteb ing ati sing kita wis wiwit ngeculake piranti lunak kualitas sing luwih dhuwur. Ing wektu sing padha, solusi sing diasilake universal lan bisa ditrapake kanthi bebas ing proyek apa wae sing perlu kanggo ngatur tes otomatis ing Oracle DBMS.

PS Artikel iki ora spesifik banget: akeh teks lan ora ana conto teknis. Yen topik umume menarik, mula kita siyap nerusake lan bali kanthi terus, ing ngendi kita bakal ngandhani apa sing wis diganti sajrone nem sasi kepungkur lan menehi conto kode.

Tulis komentar yen ana poin sing kudu ditekanake ing mangsa ngarep, utawa pitakonan sing mbutuhake pambocoran.

Mung pangguna pangguna sing bisa melu survey. mlebunggih.

Apa kita kudu nulis luwih lanjut babagan iki?

• Ya mesthi wae

• Ora matur nuwun

12 pangguna milih. 4 pangguna abstain.

Source: www.habr.com