Hey Habr!
Jenengku Maxim Ponomarenko lan aku dadi pangembang ing Sportmaster. Aku duwe pengalaman 10 taun ing bidang IT. Dheweke miwiti karir ing testing manual, banjur pindhah menyang pembangunan database. Kanggo 4 taun pungkasan, nglumpukake kawruh sing dipikolehi ing tes lan pangembangan, aku wis ngotomatisasi tes ing tingkat DBMS.
Aku wis dadi tim Sportmaster luwih saka setahun lan ngembangake tes otomatis ing salah sawijining proyek utama. Ing wulan April, wong lanang saka Sportmaster Lab lan aku ngomong ing konferensi ing Krasnodar, laporanku diarani "Ujian unit ing DBMS," lan saiki aku pengin nuduhake karo sampeyan. Bakal ana akeh teks, mula aku mutusake mbagi laporan kasebut dadi rong kiriman. Kaping pisanan, kita bakal ngomong babagan autotes lan tes ing umum, lan ing kaloro, aku bakal luwih rinci babagan sistem tes unit lan asil aplikasi kasebut.
Kaping pisanan, teori sing mboseni. Apa tes otomatis? Iki minangka tes sing ditindakake nggunakake piranti lunak, lan ing IT modern saya akeh digunakake ing pangembangan piranti lunak. Iki amarga kasunyatan manawa perusahaan saya akeh, sistem informasi saya tambah akeh lan, kanthi mangkono, jumlah fungsi sing kudu diuji saya akeh. Nganakake tes manual dadi luwih larang.
Aku makarya ing perusahaan gedhe sing release metu saben rong sasi. Ing wektu sing padha, sewulan wis dientekake kanggo duwe puluhan panguji kanthi manual mriksa fungsi kasebut. Thanks kanggo implementasi otomatisasi dening tim pangembang cilik, kita bisa nyuda wektu tes nganti 2 minggu sajrone setaun setengah. Kita ora mung nambah kacepetan tes, nanging uga nambah kualitase. Tes otomatis diluncurake kanthi rutin lan mesthi nindakake kabeh pemeriksaan sing kalebu, yaiku, ora kalebu faktor manungsa.
IT modern ditondoi kanthi kasunyatan manawa pangembang bisa uga dibutuhake ora mung nulis kode produk, nanging uga nulis tes unit sing mriksa kode iki.
Nanging kepiye yen sistem sampeyan adhedhasar logika server? Ora ana solusi universal utawa praktik paling apik ing pasar. Minangka aturan, perusahaan ngatasi masalah iki kanthi nggawe sistem tes sing ditulis dhewe. Iki minangka sistem tes otomatis sing ditulis dhewe sing digawe ing proyek kita lan aku bakal ngomong babagan iki ing laporanku.
Nguji kasetyan
Pisanan, ayo ngomong babagan proyek ing ngendi kita masang sistem tes otomatis. Proyek kita yaiku sistem kesetiaan Sportmaster (kanthi cara, kita wis nulis babagan iki ing ).
Yen perusahaan sampeyan cukup gedhe, sistem kesetiaan sampeyan bakal duwe telung sifat standar:
- Sistem sampeyan bakal dimuat banget
- Sistem sampeyan bakal ngemot proses komputasi sing rumit
- Sistem sampeyan bakal aktif ditingkatake.
Ayo dadi ing urutan ... Total, yen kita nimbang kabeh merek Sportmaster, kita duwe luwih saka 1000 toko ing Rusia, Ukraina, China, Kazakhstan lan Belarus. Kira-kira 300 tumbas digawe ing toko iki saben dina. Yaiku, saben detik 000-3 mriksa mlebu sistem kita. Alamiah, sistem kasetyan kita dimuat banget. Lan wiwit digunakake kanthi aktif, kita kudu nyedhiyakake standar kualitas sing paling dhuwur, amarga kesalahan apa wae ing piranti lunak tegese kerugian moneter, reputasi lan kerugian liyane.
Ing wektu sing padha, Sportmaster mbukak luwih saka satus promosi sing beda. Ana macem-macem promosi: ana promosi produk, ana sing darmabakti kanggo dina minggu, ana sing disambungake menyang toko tartamtu, ana promosi kanggo jumlah kuitansi, ana kanggo jumlah barang. Umumé, ora ala. Klien duwe bonus lan kode promosi sing digunakake nalika tuku. Kabeh iki ndadékaké kanggo ngetung urutan apa wae minangka tugas sing ora pati penting.
Algoritma sing ngleksanakake pangolahan pesenan pancen elek lan rumit. Lan owah-owahan ing algoritma iki cukup beboyo. Kayane owah-owahan sing paling katon ora pati penting bisa nyebabake efek sing ora bisa ditebak. Nanging proses komputasi sing kompleks, utamane sing ngetrapake fungsi kritis, minangka calon sing paling apik kanggo otomatisasi. Priksa puluhan kasus sing padha kanthi tangan mbutuhake wektu. Lan amarga titik entri menyang proses kasebut ora owah, sawise diterangake sapisan, sampeyan bisa kanthi cepet nggawe tes otomatis lan yakin manawa fungsi kasebut bakal bisa digunakake.
Wiwit sistem kita aktif digunakake, bisnis bakal pengin soko anyar saka sampeyan, manggon karo wektu lan dadi customer-oriented. Ing sistem kasetyan kita, rilis metu saben rong sasi. Iki tegese saben rong sasi kita kudu nindakake regresi lengkap kabeh sistem. Ing wektu sing padha, kanthi alami, kaya ing IT modern, pangembangan ora langsung saka pangembang menyang produksi. Asale saka sirkuit pangembang, banjur terus-terusan ngliwati bangku tes, ngeculake, ditampa, lan mung rampung ing produksi. Paling ora, ing sirkuit test lan release, kita kudu nindakake regresi lengkap kabeh sistem.
Properti sing diterangake minangka standar kanggo meh kabeh sistem kesetiaan. Ayo dadi pirembagan bab fitur saka project kita.
Secara teknologi, 90% logika sistem kesetiaan kita adhedhasar server lan dileksanakake ing Oracle. Ana klien sing katon ing Delphi, sing nindakake fungsi administrator papan kerja otomatis. Ana layanan web sing mbukak kanggo aplikasi eksternal (umpamane situs web). Mulane, logis banget yen kita masang sistem testing otomatis, kita bakal nindakake ing Oracle.
Sistem kesetiaan ing Sportmaster wis ana luwih saka 7 taun lan digawe dening pangembang tunggal ... Jumlah rata-rata pangembang ing proyek kita sajrone 7 taun iki yaiku 3-4 wong. Nanging ing taun kepungkur, tim kita wis akeh banget, lan saiki ana 10 wong sing nggarap proyek kasebut. Yaiku, wong teka ing proyek sing ora ngerti tugas, proses, lan arsitektur sing khas. Lan ana risiko tambah yen kita bakal kantun kesalahan.
Proyek kasebut ditondoi kanthi ora ana penguji khusus minangka unit staf. Ana, mesthi, tes, nanging tes ditindakake dening analis, saliyane tanggung jawab utama liyane: komunikasi karo pelanggan bisnis, pangguna, ngembangake syarat sistem, lsp. etc ... Senadyan kasunyatan sing testing digawa metu kualitas dhuwur banget (iki utamané cocok kanggo sebutno, amarga sawetara analis bisa nyekel mripat laporan iki), efektifitas spesialisasi lan konsentrasi ing siji bab durung dibatalake. .
Ngelingi kabeh kasebut ing ndhuwur, kanggo nambah kualitas produk sing dikirim lan nyuda wektu pangembangan, ide ngotomatisasi tes ing proyek katon logis banget. Lan ing macem-macem tahap eksistensi sistem kesetiaan, pangembang individu ngupayakake kanggo nutupi kode kasebut kanthi tes unit. Sakabèhé, iku proses sing cukup disjointed, karo saben wong nggunakake arsitektur lan cara dhewe. Asil final umum kanggo tes unit: tes dikembangake, digunakake kanggo sawetara wektu, disimpen ing panyimpenan file versi, nanging ing sawetara titik padha mandheg mlaku lan dilalekake. Kaping pisanan, iki amarga kasunyatan manawa tes kasebut luwih diikat karo pemain tartamtu, lan dudu proyek kasebut.
utPLSQL teka kanggo ngluwari
Apa sampeyan ngerti babagan Stephen Feuerstein?
Iki wong pinter sing pengabdian bagean dawa saka karir kanggo nggarap Oracle lan PL / SQL, lan wis ditulis nomer akeh karya ing topik iki. Salah sawijining buku sing misuwur yaiku: "Oracle PL/SQL. Kanggo profesional." Stephen sing ngembangake solusi utPLSQL, utawa, minangka singkatan, kerangka Unit Testing kanggo Oracle PL/SQL. Solusi utPLSQL digawe ing 2016, nanging terus digarap kanthi aktif lan versi anyar dirilis. Ing wektu nglaporake, versi paling anyar wiwit tanggal 24 Maret 2019.
Opo kuwi. Iki minangka proyek open source sing kapisah. Bobot saperangan megabyte, kalebu conto lan dokumentasi. Secara fisik, iki minangka skema kapisah ing database ORACLE kanthi paket lan tabel kanggo ngatur tes unit. Instalasi njupuk sawetara detik. Fitur khas utPLSQL yaiku gampang digunakake.
Sacara global, utPLSQL minangka mekanisme kanggo nglakokake tes unit, ing ngendi tes unit dimangerteni minangka prosedur batch Oracle biasa, organisasi sing ngetutake aturan tartamtu. Saliyane diluncurake, utPLSQL nyimpen log kabeh tes sampeyan, lan uga duwe sistem laporan internal.
Ayo goleki conto apa kode tes unit katon, dileksanakake nggunakake teknik iki.
Dadi, layar nuduhake kode kanggo spesifikasi paket khas kanthi tes unit. Apa syarat wajib? Paket kasebut kudu diwenehi awalan "utp_". Kabeh prosedur kanthi tes kudu duwe prefiks sing padha. Paket kasebut kudu ngemot rong prosedur standar: "utp_setup" lan "utp_teardown". Prosedur pisanan diarani kanthi miwiti maneh saben tes unit, sing kapindho - sawise diluncurake.
"utp_setup", minangka aturan, nyiapake sistem kita kanggo mbukak test unit, contone, nggawe data test. "utp_teardown" - sebaliknya, kabeh bali menyang setelan asli lan ngreset asil peluncuran.
Iki minangka conto tes unit paling gampang sing mriksa normalisasi nomer telpon pelanggan sing dilebokake menyang formulir standar kanggo sistem kesetiaan kita. Ora ana standar wajib babagan cara nulis prosedur kanthi tes unit. Minangka aturan, telpon digawe kanggo cara sistem ing test, lan asil bali dening cara iki dibandhingake karo referensi. Penting yen perbandingan asil referensi lan sing dipikolehi ditindakake liwat metode utPLSQL standar.
Tes unit bisa duwe sawetara pemeriksaan. Kaya sing bisa dideleng saka conto, kita nggawe papat telpon berturut-turut menyang cara sing diuji kanggo normalake nomer telpon lan ngevaluasi asil sawise saben telpon. Nalika ngembangaken test unit, sampeyan kudu njupuk menyang akun sing ana mriksa sing ora mengaruhi sistem ing sembarang cara, lan sawise sawetara sampeyan kudu muter bali menyang negara asli saka sistem.
Contone, ing test unit presented kita mung format nomer telpon input, kang ora mengaruhi sistem kasetyan ing sembarang cara.
Lan yen kita nulis tes unit nggunakake cara nggawe klien anyar, banjur sawise saben test klien anyar bakal digawe ing sistem, kang bisa mengaruhi peluncuran sakteruse saka test.
Iki minangka tes unit ditindakake. Ana rong opsi peluncuran sing bisa ditindakake: nglakokake kabeh tes unit saka paket tartamtu utawa nglakokake tes unit tartamtu ing paket tartamtu.
Iki minangka conto sistem pelaporan internal. Adhedhasar asil tes unit, utPLSQL nggawe laporan cilik. Ing kono kita ndeleng asil kanggo saben mriksa tartamtu lan asil sakabèhé saka test unit.
6 aturan tes otomatis
Sadurunge miwiti nggawe sistem anyar kanggo tes otomatis sistem kesetiaan, bebarengan karo manajemen, kita nemtokake prinsip sing kudu ditindakake tes otomatis ing mangsa ngarep.
- Autotests kudu efektif lan kudu migunani. Kita duwe pangembang apik, sing mesthi kudu kasebut, amarga sawetara wong bakal weruh laporan iki, lan nulis kode apik. Nanging malah kode apik sing ora sampurna lan wis, wis, lan bakal terus ngemot kasalahan. Autotests dibutuhake kanggo nemokake kesalahan kasebut. Yen iki ora, banjur kita nulis autotests ala, utawa kita wis teka ing wilayah mati sing, ing asas, ora dikembangaké. Ing kasus loro, kita nindakake salah, lan pendekatan kita mung ora masuk akal.
- Autotests kudu digunakake. Ora ana gunane kanggo nglampahi akeh wektu lan gaweyan kanggo nulis produk piranti lunak, dilebokake ing gudang lan lali. Tes kudu ditindakake, lan mlaku kanthi rutin.
- Autotests kudu bisa digunakake kanthi stabil. Ora preduli babagan wektu, ngadeg lan setelan sistem liyane, uji coba kudu ngasilake asil sing padha. Minangka aturan, iki dijamin dening kasunyatan sing autotests bisa karo data test khusus karo setelan sistem tetep.
- Autotests kudu bisa kanthi kacepetan sing bisa ditampa kanggo proyek sampeyan. Wektu iki ditemtokake individu kanggo saben sistem. Sawetara wong bisa kerja sedina muput, dene wong liya pancen kritis kanggo nindakake ing sawetara detik. Aku bakal pitutur marang kowe mengko apa standar kacepetan kita ngrambah ing project kita.
- Pangembangan autotest kudu fleksibel. Ora disaranake nolak nyoba fungsi apa wae mung amarga durung rampung sadurunge utawa ana alesan liyane. utPLSQL ora nemtokke Watesan ing pembangunan, lan Oracle, ing asas, ngijini sampeyan kanggo ngleksanakake macem-macem iku. Umume masalah duwe solusi, mung butuh wektu lan usaha.
- Deployability. Kita duwe sawetara stand ing ngendi kita kudu nganakake tes. Ing saben stand, dump data bisa dianyari sawayah-wayah. Sampeyan kudu nindakake proyek kanthi tes otomatis supaya sampeyan bisa nindakake instalasi lengkap utawa sebagean tanpa rasa sakit.
Lan ing kirim kaping pindho ing sawetara dina, aku bakal ngandhani apa sing wis ditindakake lan asil sing diraih.
Source: www.habr.com