Mga pagsubok sa yunit sa isang DBMS - kung paano namin ito ginagawa sa Sportmaster, ikalawang bahagi

Unang parte - dito.

Isipin ang sitwasyon. Ikaw ay nahaharap sa gawain ng pagbuo ng bagong pag-andar. Mayroon kang mga pag-unlad mula sa iyong mga nauna. Kung ipagpalagay namin na wala kang moral na obligasyon, ano ang gagawin mo?

Kadalasan, ang lahat ng mga lumang pag-unlad ay nakalimutan at ang lahat ay nagsisimula muli. Walang gustong maghukay sa code ng ibang tao, ngunit kung may oras ka, bakit hindi simulan ang paggawa ng sarili mong system? Ito ay isang tipikal na diskarte, at ito ay higit na tama. Pero sa project namin mali ang ginawa namin. Ibinatay namin ang hinaharap na awtomatikong sistema ng pagsubok sa mga pag-unlad sa mga pagsubok sa yunit sa utPLSQL mula sa aming mga nauna, at pagkatapos ay nagtungo sa maraming magkakatulad na direksyon.

1. Pagpapanumbalik ng mga lumang unit test. Ang ibig sabihin ng pagbawi ay pag-angkop ng mga pagsubok sa kasalukuyang estado ng sistema ng katapatan at pag-angkop ng mga pagsubok sa mga pamantayan ng utPLSQL.
2. Paglutas ng problema sa pag-unawa sa kung ano ang eksaktong, kung anong mga pamamaraan at proseso ang sakop ng mga autotest. Dapat mong itago ang impormasyong ito sa iyong ulo, o gumawa ng mga konklusyon batay nang direkta sa autotest code. Samakatuwid, nagpasya kaming lumikha ng isang katalogo. Nagtalaga kami ng natatanging mnemonic code sa bawat autotest, gumawa ng paglalarawan at mga naitala na setting (halimbawa, sa ilalim ng kung anong mga kundisyon ito dapat ilunsad, o kung ano ang dapat mangyari kung nabigo ang paglulunsad ng pagsubok). Sa pangkalahatan, na-populate namin ang metadata tungkol sa mga autotest at inilagay ang metadata na iyon sa mga karaniwang talahanayan ng schema ng utPLSQL.
3. Pagtukoy sa diskarte sa pagpapalawak, i.e. pagpili ng functionality na napapailalim sa pag-verify ng mga automated na pagsubok. Napagpasyahan naming bigyang pansin ang tatlong bagay: mga bagong pagpapabuti ng system, mga insidente ng produksyon, at mga pangunahing proseso ng system. Kaya, kami ay umuunlad kasabay ng pagpapalabas, tinitiyak ang mas mataas na kalidad nito, sabay-sabay na pagpapalawak ng saklaw ng regression at pagtiyak ng pagiging maaasahan ng system sa mga kritikal na lugar. Ang unang naturang bottleneck ay ang proseso ng pamamahagi ng mga diskwento at bonus sa isang tseke.
4. Naturally, nagsimula kaming bumuo ng mga bagong autotest. Ang isa sa mga unang pagpapalabas na gawain ay upang suriin ang pagganap ng mga paunang natukoy na sample ng sistema ng katapatan. Ang aming proyekto ay may isang bloke ng mahigpit na naayos na mga query sa SQL na pumipili ng mga kliyente batay sa mga kundisyon. Halimbawa, kumuha ng listahan ng lahat ng customer na ang huling pagbili ay sa isang partikular na lungsod, o isang listahan ng mga customer na ang average na halaga ng pagbili ay mas mataas sa isang partikular na halaga. Sa pagkakaroon ng nakasulat na mga autotest, sinuri namin ang mga paunang natukoy na sample, naitala ang mga parameter ng pagganap ng benchmark, at bukod pa rito, nagkaroon kami ng pagsubok sa pagkarga.
5. Ang pagtatrabaho sa mga autotest ay dapat na maginhawa. Ang dalawang pinakakaraniwang pagkilos ay ang pagpapatakbo ng mga autotest at paggawa ng data ng pagsubok. Ganito lumabas ang dalawang auxiliary module sa aming system: isang launch module at isang data generation module.

   Ang launcher ay kinakatawan bilang isang unibersal na pamamaraan na may isang parameter ng input ng text. Bilang isang parameter, maaari mong ipasa ang autotest mnemonic code, pangalan ng package, pangalan ng pagsubok, setting ng autotest, o isang nakareserbang keyword. Pinipili at pinapatakbo ng pamamaraan ang lahat ng mga autotest na nakakatugon sa mga kundisyon.

   Ang module ng pagbuo ng data ay ipinakita sa anyo ng isang pakete kung saan para sa bawat bagay ng system sa ilalim ng pagsubok (isang talahanayan sa database), isang espesyal na pamamaraan ang nilikha na naglalagay ng data doon. Sa pamamaraang ito, ang mga default na halaga ay pinupunan hangga't maaari, na tinitiyak ang paglikha ng mga bagay nang literal sa isang pag-click ng isang daliri. At para sa kadalian ng paggamit, ginawa ang mga template para sa nabuong data. Halimbawa, lumikha ng isang kliyente ng isang tiyak na edad na may isang pansubok na telepono at isang nakumpletong pagbili.

6. Dapat magsimula at tumakbo ang mga autotest sa oras na katanggap-tanggap para sa iyong system. Samakatuwid, ang isang pang-araw-araw na paglulunsad sa gabi ay isinaayos, batay sa mga resulta kung saan ang isang ulat sa mga resulta ay nabuo at ipinadala sa buong pangkat ng pag-unlad sa pamamagitan ng corporate mail. Pagkatapos ibalik ang mga lumang autotest at gumawa ng mga bago, ang kabuuang oras ng pagpapatakbo ay 30 minuto. Ang pagganap na ito ay angkop sa lahat, dahil ang paglulunsad ay naganap sa labas ng mga oras ng trabaho.

   Ngunit kailangan naming magtrabaho sa pag-optimize ng bilis ng trabaho. Ang sistema ng katapatan sa produksyon ay ina-update sa gabi. Bilang bahagi ng isa sa mga release, kailangan naming gumawa ng mga kagyat na pagbabago sa gabi. Ang paghihintay ng kalahating oras para sa mga resulta ng mga autotest sa alas-tres ng umaga ay hindi naging masaya sa taong responsable para sa pagpapalaya (masigasig na pagbati kay Alexey Vasyukov!), At sa susunod na umaga maraming mabubuting salita ang sinabi sa aming sistema. Ngunit bilang isang resulta, isang 5 minutong pamantayan para sa trabaho ay itinatag.

   Upang mapabilis ang pagganap, gumamit kami ng dalawang pamamaraan: nagsimulang tumakbo ang mga autotest sa tatlong magkatulad na mga thread, sa kabutihang palad ito ay napaka-maginhawa dahil sa arkitektura ng aming sistema ng katapatan. At tinalikuran namin ang diskarte kung saan ang autotest ay hindi gumagawa ng data ng pagsubok para sa sarili nito, ngunit sinusubukang maghanap ng bagay na angkop sa system. Pagkatapos gawin ang mga pagbabago, ang kabuuang oras ng pagpapatakbo ay nabawasan sa 3-4 minuto.

7. Ang isang proyekto na may mga awtomatikong pagsubok ay dapat na mai-deploy sa iba't ibang stand. Sa simula ng aming paglalakbay, may mga pagtatangka na magsulat ng aming sariling mga batch file, ngunit naging malinaw na ang isang self-written na awtomatikong pag-install ay ganap na kakila-kilabot, at kami ay bumaling sa mga pang-industriyang solusyon. Dahil sa katotohanan na ang proyekto ay naglalaman ng maraming direktang code (una sa lahat, iniimbak namin ang autotest code) at napakakaunting data (ang pangunahing data ay metadata tungkol sa mga autotest), ang pagpapatupad sa proyekto ng Liquibase ay naging napaka-simple.

   Ito ay isang open-source, database-independent na library para sa pagsubaybay, pamamahala, at pagpapatupad ng mga pagbabago sa schema ng database. Pinamamahalaan sa pamamagitan ng command line o mga framework gaya ng Apache Maven. Ang prinsipyo ng pagpapatakbo ng Liquibase ay medyo simple. Mayroon kaming proyektong nakaayos sa isang tiyak na paraan, na binubuo ng mga pagbabago o script na kailangang ilunsad sa target na server, at kontrolin ang mga file na tumutukoy sa kung anong pagkakasunud-sunod at kung anong mga parameter ang dapat i-install ang mga pagbabagong ito.

   Sa antas ng DBMS, isang espesyal na talahanayan ang nilikha kung saan iniimbak ng Liquibase ang rollover log. Ang bawat pagbabago ay may kinakalkula na hash, na inihahambing sa bawat oras sa pagitan ng proyekto at ng estado sa database. Salamat sa Liquibase, madali naming mailalabas ang mga pagbabago sa aming system sa anumang circuit. Inilunsad na ngayon ang mga autotest sa mga test at release circuit, gayundin sa mga container (mga personal na circuit ng developer).

Kaya, pag-usapan natin ang tungkol sa mga resulta ng paggamit ng aming unit testing system.

1. Siyempre, una sa lahat, kumbinsido kami na nagsimula kaming bumuo ng mas mahusay na software. Ang mga autotest ay inilunsad araw-araw at dose-dosenang mga error ang matatagpuan sa bawat paglabas. Bukod dito, ang ilan sa mga error na ito ay hindi direktang nauugnay sa functionality na talagang gusto naming baguhin. May mga seryosong pagdududa na ang mga error na ito ay natagpuan sa pamamagitan ng manu-manong pagsubok.
2. May kumpiyansa na ngayon ang team na gumagana nang tama ang partikular na functionality... Una sa lahat, may kinalaman ito sa aming mga kritikal na proseso. Halimbawa, sa nakalipas na anim na buwan, wala kaming anumang mga problema sa pamamahagi ng mga diskwento at mga bonus sa mga resibo, sa kabila ng mga pagbabago sa pag-release, bagama't sa mga nakaraang panahon nagkaroon ng mga error na may ilang dalas.
3. Nagawa naming bawasan ang bilang ng mga pag-ulit ng pagsubok. Dahil sa katotohanan na ang mga autotest ay isinulat para sa bagong functionality, ang mga analyst at part-time na tester ay tumatanggap ng code na mas mataas ang kalidad, dahil ito ay nasuri na.
4. Ang ilan sa mga development sa automated na pagsubok ay ginagamit ng mga developer. Halimbawa, ang data ng pagsubok sa mga container ay ginawa gamit ang object generation module.
5. Mahalaga na nakabuo kami ng "pagtanggap" ng automated testing system sa bahagi ng mga developer. May pag-unawa na ito ay mahalaga at kapaki-pakinabang. Ngunit mula sa aking sariling karanasan masasabi kong malayo ito sa kaso. Kailangang isulat ang mga autotest, kailangan itong suportahan at paunlarin, dapat suriin ang mga resulta, at kadalasan ang mga gastos sa oras na ito ay sadyang hindi katumbas ng halaga. Mas madaling pumunta sa produksyon at harapin ang mga problema doon. Dito, pumila ang mga developer at hinihiling sa amin na sakupin ang kanilang functionality gamit ang mga autotest.

kung ano ang susunod

Pag-usapan natin ang tungkol sa mga plano sa pagpapaunlad para sa automated na proyekto sa pagsubok.

Siyempre, hangga't ang sistema ng katapatan ng Sportmaster ay buhay at patuloy na umuunlad, posible ring bumuo ng mga autotest nang halos walang katapusang. Samakatuwid, ang pangunahing direksyon ng pag-unlad ay pagpapalawak ng saklaw na lugar.

Habang dumarami ang bilang ng mga autotest, ang kabuuang oras ng pagpapatakbo ng mga ito ay patuloy na tataas, at muli nating babalikan ang isyu ng pagganap. Malamang, ang solusyon ay upang madagdagan ang bilang ng mga parallel na mga thread.

Ngunit ito ay malinaw na mga paraan ng pag-unlad. Kung pag-uusapan natin ang isang bagay na mas hindi mahalaga, i-highlight natin ang sumusunod:

1. Sa kasalukuyan, ang pamamahala ng autotest ay isinasagawa sa antas ng DBMS, i.e. ang kaalaman sa PL/SQL ay kinakailangan para sa matagumpay na trabaho. Kung kinakailangan, pamamahala ng system (halimbawa, paglulunsad o paglikha ng metadata), maaari kang lumikha ng ilang uri ng admin panel gamit ang Jenkins o katulad na bagay.
2. Gustung-gusto ng lahat ang quantitative at qualitative indicators. Para sa awtomatikong pagsubok, ang naturang pangkalahatang tagapagpahiwatig ay Code Coverage o sukatan ng saklaw ng code. Gamit ang indicator na ito, matutukoy namin kung anong porsyento ng code ng aming system na nasa ilalim ng pagsubok ang sakop ng mga autotest. Simula sa bersyon 12.2, nagbibigay ang Oracle ng kakayahang kalkulahin ang sukatang ito at nag-aalok ng paggamit ng karaniwang DBMS_PLSQL_CODE_COVERAGE na pakete.

   Ang aming autotest system ay higit sa isang taong gulang lamang at marahil ngayon na ang oras upang suriin ang aming saklaw. Sa aking huling proyekto (hindi isang proyekto ng Sportmaster) ito ang nangyari. Isang taon pagkatapos magtrabaho sa mga autotest, itinakda ng pamamahala ang gawain ng pagtatasa kung ilang porsyento ng code ang saklaw namin. Sa saklaw na higit sa 1%, magiging masaya ang management. Kami, ang mga developer, ay umaasa ng isang resulta ng humigit-kumulang 10%. Nag-install kami ng saklaw ng code, sinukat ito, at nakakuha ng 20%. Upang ipagdiwang, pumunta kami upang makuha ang premyo, ngunit kung paano namin nakuha ito at kung saan kami nagpunta mamaya ay isang ganap na naiibang kuwento.

3. Maaaring suriin ng mga autotest ang mga nakalantad na serbisyo sa web. Pinapayagan kami ng Oracle na gawin ito nang maayos, at hindi na kami makakatagpo ng maraming problema.
4. At, siyempre, ang aming automated testing system ay maaaring ilapat sa isa pang proyekto. Ang solusyon na natanggap namin ay pangkalahatan at nangangailangan lamang ng paggamit ng Oracle. Narinig ko na ang ibang mga proyekto ng Sportmaster ay interesado sa awtomatikong pagsubok at marahil ay pupunta tayo sa kanila.

Natuklasan

I-summarize natin. Sa proyekto ng loyalty system sa Sportmaster, nagawa naming ipatupad ang isang automated testing system. Ito ay batay sa utPLSQL na solusyon mula kay Stephen Feuerstein. Sa paligid ng utPLSQL mayroong autotest code at auxiliary na self-written na mga module: launch module, data generation module at iba pa. Ang mga autotest ay inilunsad araw-araw at, higit sa lahat, gumagana ang mga ito at kapaki-pakinabang. Kami ay tiwala na nagsimula kaming maglabas ng mas mataas na kalidad ng software. Kasabay nito, ang resultang solusyon ay pangkalahatan at maaaring malayang ilapat sa anumang proyekto kung saan kinakailangan upang ayusin ang awtomatikong pagsubok sa Oracle DBMS.

PS Ang artikulong ito ay hindi masyadong tiyak: mayroong maraming teksto at halos walang mga teknikal na halimbawa. Kung sa pangkalahatan ay kawili-wili ang paksa, handa kaming ipagpatuloy ito at babalik na may pagpapatuloy, kung saan sasabihin namin sa iyo kung ano ang nagbago sa nakalipas na anim na buwan at magbibigay ng mga halimbawa ng code.

Sumulat ng mga komento kung may mga punto na dapat bigyang-diin sa hinaharap, o mga tanong na nangangailangan ng pagsisiwalat.

Ang mga rehistradong user lamang ang maaaring lumahok sa survey. Mag-sign in, pakiusap

Magsusulat pa ba tayo tungkol dito?

• Oo naman

• Salamat nalang

12 mga gumagamit ang bumoto. 4 user ang umiwas.

Pinagmulan: www.habr.com