Hoy Habr!
Ang pangalan ko ay Maxim Ponomarenko at ako ay isang developer sa Sportmaster. Mayroon akong 10 taong karanasan sa larangan ng IT. Sinimulan niya ang kanyang karera sa manu-manong pagsubok, pagkatapos ay lumipat sa pagbuo ng database. Sa nakalipas na 4 na taon, nag-iipon ng kaalaman na nakuha sa pagsubok at pag-unlad, ako ay nag-automate ng pagsubok sa antas ng DBMS.
Ako ay nasa koponan ng Sportmaster sa loob lamang ng isang taon at gumagawa ako ng awtomatikong pagsubok sa isa sa mga pangunahing proyekto. Noong Abril, ang mga lalaki mula sa Sportmaster Lab ay nagsalita sa isang kumperensya sa Krasnodar, ang aking ulat ay tinawag na "Mga pagsubok sa yunit sa isang DBMS," at ngayon ay gusto kong ibahagi ito sa iyo. Magkakaroon ng maraming text, kaya napagpasyahan kong hatiin ang ulat sa dalawang post. Sa una, pag-uusapan natin ang tungkol sa mga autotest at pagsubok sa pangkalahatan, at sa pangalawa, tatalakayin ko nang mas detalyado ang aming sistema ng pagsubok sa yunit at ang mga resulta ng aplikasyon nito.
Una, medyo boring theory. Ano ang awtomatikong pagsubok? Ito ay pagsubok na isinasagawa ng software, at sa modernong IT ito ay lalong ginagamit sa pagbuo ng software. Ito ay dahil sa ang katunayan na ang mga kumpanya ay lumalaki, ang kanilang mga sistema ng impormasyon ay lumalaki at, nang naaayon, ang dami ng pag-andar na kailangang masuri ay lumalaki. Ang pagsasagawa ng manu-manong pagsusuri ay nagiging mas at mas mahal.
Nagtrabaho ako sa isang malaking kumpanya na ang mga release ay lumalabas tuwing dalawang buwan. Kasabay nito, isang buong buwan ang ginugol sa pagkakaroon ng isang dosenang tester na manu-manong suriin ang functionality. Salamat sa pagpapatupad ng automation ng isang maliit na pangkat ng mga developer, nagawa naming bawasan ang oras ng pagsubok sa 2 linggo sa isang taon at kalahati. Hindi lamang namin pinataas ang bilis ng pagsubok, ngunit pinahusay din ang kalidad nito. Regular na inilulunsad ang mga automated na pagsubok at palagi nilang isinasagawa ang buong kurso ng mga pagsusuri na kasama sa mga ito, iyon ay, hindi namin isinasama ang kadahilanan ng tao.
Ang modernong IT ay nailalarawan sa pamamagitan ng katotohanan na ang isang developer ay maaaring kailanganin hindi lamang na magsulat ng code ng produkto, ngunit din na magsulat ng mga pagsubok sa yunit na sumusuri sa code na ito.
Ngunit paano kung ang iyong system ay pangunahing nakabatay sa lohika ng server? Walang pangkalahatang solusyon o pinakamahusay na kagawian sa merkado. Bilang isang tuntunin, nilulutas ng mga kumpanya ang problemang ito sa pamamagitan ng paglikha ng sarili nilang sistema ng pagsubok na nakasulat sa sarili. Ito ang sarili naming self-written automated testing system na ginawa sa aming proyekto at pag-uusapan ko ito sa aking ulat.
Sinusubok ang katapatan
Una, pag-usapan natin ang proyekto kung saan nag-deploy kami ng automated testing system. Ang aming proyekto ay ang sistema ng katapatan ng Sportmaster (nga pala, isinulat na namin ang tungkol dito sa ).
Kung sapat ang laki ng iyong kumpanya, magkakaroon ng tatlong karaniwang katangian ang iyong loyalty system:
- Ang iyong system ay lubos na mai-load
- Maglalaman ang iyong system ng mga kumplikadong proseso ng pag-compute
- Aktibong mapapabuti ang iyong system.
Umayos tayo... Sa kabuuan, kung isasaalang-alang natin ang lahat ng mga tatak ng Sportmaster, mayroon tayong higit sa 1000 mga tindahan sa Russia, Ukraine, China, Kazakhstan at Belarus. Humigit-kumulang 300 pagbili ang ginagawa sa mga tindahang ito araw-araw. Ibig sabihin, bawat segundo 000-3 na pagsusuri ang pumapasok sa aming system. Naturally, ang aming loyalty system ay lubos na puno. At dahil ito ay aktibong ginagamit, dapat kaming magbigay ng pinakamataas na pamantayan ng kalidad nito, dahil ang anumang error sa software ay nangangahulugan ng malaking pera, reputasyon at iba pang pagkalugi.
Kasabay nito, ang Sportmaster ay nagpapatakbo ng higit sa isang daang iba't ibang mga promosyon. Mayroong iba't ibang mga promosyon: may mga promosyon ng produkto, mayroong mga nakatuon sa araw ng linggo, mayroong mga nakatali sa isang tiyak na tindahan, may mga promo para sa halaga ng resibo, mayroong para sa bilang ng mga kalakal. Sa pangkalahatan, hindi masama. Ang mga kliyente ay may mga bonus at pampromosyong code na ginagamit kapag bumibili. Ang lahat ng ito ay humahantong sa katotohanan na ang pagkalkula ng anumang pagkakasunud-sunod ay isang napaka-di-maliit na gawain.
Ang algorithm na nagpapatupad ng pagpoproseso ng order ay talagang kakila-kilabot at kumplikado. At ang anumang mga pagbabago sa algorithm na ito ay medyo mapanganib. Tila na ang pinaka tila hindi gaanong mga pagbabago ay maaaring humantong sa medyo hindi mahuhulaan na mga epekto. Ngunit ito ay tiyak na tulad kumplikadong mga proseso ng computing, lalo na ang mga nagpapatupad ng kritikal na pag-andar, na ang pinakamahusay na mga kandidato para sa automation. Ang pagsuri sa dose-dosenang mga katulad na kaso sa pamamagitan ng kamay ay napakatagal. At dahil ang entry point sa proseso ay hindi nagbabago, na inilarawan ito nang isang beses, maaari kang mabilis na lumikha ng mga awtomatikong pagsubok at magtiwala na gagana ang pag-andar.
Dahil ang aming system ay aktibong ginagamit, ang negosyo ay magnanais ng bago mula sa iyo, mamuhay sa mga oras at maging nakatuon sa customer. Sa aming loyalty system, lumalabas ang mga release tuwing dalawang buwan. Nangangahulugan ito na bawat dalawang buwan kailangan nating magsagawa ng kumpletong regression ng buong system. Kasabay nito, natural, tulad ng sa anumang modernong IT, ang pag-unlad ay hindi agad napupunta mula sa developer hanggang sa produksyon. Nagmumula ito sa circuit ng developer, pagkatapos ay sunod-sunod na dumadaan sa test bench, release, pagtanggap, at pagkatapos ay napupunta lamang sa produksyon. Sa pinakamababa, sa pagsubok at paglabas ng mga circuit, kailangan nating magsagawa ng kumpletong pagbabalik ng buong sistema.
Ang mga inilarawang katangian ay pamantayan para sa halos anumang sistema ng katapatan. Pag-usapan natin ang mga tampok ng aming proyekto.
Sa teknolohiya, 90% ng logic ng aming loyalty system ay nakabatay sa server at ipinapatupad sa Oracle. Mayroong isang kliyente na nakalantad sa Delphi, na gumaganap ng function ng isang awtomatikong administrator ng lugar ng trabaho. May mga nakalantad na serbisyo sa web para sa mga panlabas na application (halimbawa, isang website). Samakatuwid, napakalohikal na kung mag-deploy kami ng isang awtomatikong sistema ng pagsubok, gagawin namin ito sa Oracle.
Ang sistema ng katapatan sa Sportmaster ay umiral nang higit sa 7 taon at nilikha ng mga nag-iisang developer... Ang average na bilang ng mga developer sa aming proyekto sa loob ng 7 taon na ito ay 3-4 na tao. Ngunit sa nakalipas na taon, ang aming koponan ay lumago nang malaki, at ngayon ay mayroong 10 tao na nagtatrabaho sa proyekto. Iyon ay, ang mga tao ay pumupunta sa proyekto na hindi pamilyar sa mga tipikal na gawain, proseso, at arkitektura. At may mas mataas na panganib na makaligtaan tayo ng mga pagkakamali.
Ang proyekto ay nailalarawan sa pamamagitan ng kawalan ng mga dedikadong tester bilang mga yunit ng kawani. Mayroong, siyempre, pagsubok, ngunit ang pagsubok ay isinasagawa ng mga analyst, bilang karagdagan sa kanilang iba pang mga pangunahing responsibilidad: pakikipag-usap sa mga customer ng negosyo, mga gumagamit, pagbuo ng mga kinakailangan sa system, atbp. atbp... Sa kabila ng katotohanan na ang pagsubok ay isinasagawa ng napakataas na kalidad (ito ay lalong angkop na banggitin, dahil ang ilan sa mga analyst ay maaaring makapansin ng ulat na ito), ang pagiging epektibo ng pagdadalubhasa at konsentrasyon sa isang bagay ay hindi nakansela. .
Isinasaalang-alang ang lahat ng nasa itaas, upang mapabuti ang kalidad ng naihatid na produkto at bawasan ang oras ng pag-unlad, ang ideya ng pag-automate ng pagsubok sa isang proyekto ay tila napaka-lohikal. At sa iba't ibang yugto ng pagkakaroon ng loyalty system, nagsikap ang mga indibidwal na developer na sakupin ang kanilang code gamit ang mga unit test. Sa pangkalahatan, ito ay isang medyo magkahiwalay na proseso, na ang lahat ay gumagamit ng kanilang sariling arkitektura at pamamaraan. Ang mga huling resulta ay karaniwan sa mga pagsubok sa yunit: ang mga pagsubok ay binuo, ginamit nang ilang panahon, na naka-imbak sa isang bersyon na imbakan ng file, ngunit sa ilang mga punto ay huminto ang mga ito sa pagtakbo at nakalimutan. Una sa lahat, ito ay dahil sa ang katunayan na ang mga pagsubok ay higit na nakatali sa isang tiyak na tagapalabas, at hindi sa proyekto.
Ang utPLSQL ay sumagip
May alam ka ba tungkol kay Stephen Feuerstein?
Ito ay isang matalinong tao na nagtalaga ng mahabang bahagi ng kanyang karera sa pagtatrabaho sa Oracle at PL/SQL, at nakapagsulat ng napakaraming mga gawa sa paksang ito. Ang isa sa kanyang mga sikat na libro ay tinatawag na: "Oracle PL/SQL. Para sa mga propesyonal." Si Stephen ang bumuo ng utPLSQL solution, o, gaya ng ibig sabihin nito, Unit Testing framework para sa Oracle PL/SQL. Ang solusyon sa utPLSQL ay nilikha noong 2016, ngunit patuloy itong aktibong ginagawa at inilabas ang mga bagong bersyon. Sa oras ng pag-uulat, ang pinakabagong bersyon ay itinayo noong Marso 24, 2019.
Ano ito. Ito ay isang hiwalay na open source na proyekto. Tumitimbang ito ng ilang megabytes, kasama ang mga halimbawa at dokumentasyon. Sa pisikal, ito ay isang hiwalay na schema sa database ng ORACLE na may set ng mga pakete at talahanayan para sa pag-aayos ng unit testing. Ang pag-install ay tumatagal ng ilang segundo. Ang isang natatanging tampok ng utPLSQL ay ang kadalian ng paggamit nito.
Sa buong mundo, ang utPLSQL ay isang mekanismo para sa pagpapatakbo ng mga unit test, kung saan ang isang unit test ay nauunawaan bilang mga ordinaryong Oracle batch procedure, ang organisasyon na sumusunod sa ilang partikular na panuntunan. Bilang karagdagan sa paglulunsad, ang utPLSQL ay nag-iimbak ng isang log ng lahat ng iyong pagsubok na tumatakbo, at mayroon ding panloob na sistema ng pag-uulat.
Tingnan natin ang isang halimbawa kung ano ang hitsura ng unit test code, na ipinatupad gamit ang diskarteng ito.
Kaya, ipinapakita ng screen ang code para sa tipikal na detalye ng package na may mga unit test. Ano ang mga kinakailangang kinakailangan? Ang packet ay dapat na may prefix na "utp_". Ang lahat ng mga pamamaraan na may mga pagsubok ay dapat na may eksaktong parehong prefix. Ang package ay dapat maglaman ng dalawang karaniwang pamamaraan: "utp_setup" at "utp_teardown". Ang unang pamamaraan ay tinatawag sa pamamagitan ng pag-restart ng bawat unit test, ang pangalawa - pagkatapos ng paglunsad.
Ang "utp_setup", bilang panuntunan, ay naghahanda sa aming system na magpatakbo ng isang unit test, halimbawa, paggawa ng data ng pagsubok. "utp_teardown" - sa kabaligtaran, lahat ay bumalik sa orihinal na mga setting at ni-reset ang mga resulta ng paglulunsad.
Narito ang isang halimbawa ng pinakasimpleng unit test na nagsusuri sa normalisasyon ng inilagay na numero ng telepono ng customer sa karaniwang form para sa aming loyalty system. Walang ipinag-uutos na pamantayan kung paano magsulat ng mga pamamaraan na may mga pagsubok sa yunit. Bilang isang patakaran, ang isang tawag ay ginawa sa isang pamamaraan ng system na sinusuri, at ang resulta na ibinalik ng pamamaraang ito ay inihambing sa isang sanggunian. Mahalaga na ang paghahambing ng resulta ng sanggunian at ang nakuha ay nangyayari sa pamamagitan ng karaniwang mga pamamaraan ng utPLSQL.
Ang isang unit test ay maaaring magkaroon ng anumang bilang ng mga tseke. Tulad ng makikita mula sa halimbawa, gumawa kami ng apat na magkakasunod na tawag sa nasubok na paraan upang gawing normal ang numero ng telepono at suriin ang resulta pagkatapos ng bawat tawag. Kapag bumubuo ng isang unit test, dapat mong isaalang-alang na may mga pagsusuri na hindi nakakaapekto sa system sa anumang paraan, at pagkatapos ng ilang kailangan mong bumalik sa orihinal na estado ng system.
Halimbawa, sa ipinakitang pagsubok sa yunit, i-format lang namin ang input na numero ng telepono, na hindi nakakaapekto sa sistema ng katapatan sa anumang paraan.
At kung sumulat kami ng mga pagsubok sa yunit gamit ang paraan ng paglikha ng isang bagong kliyente, pagkatapos pagkatapos ng bawat pagsubok ay isang bagong kliyente ang malilikha sa system, na maaaring makaapekto sa kasunod na paglulunsad ng pagsubok.
Ito ay kung paano pinapatakbo ang mga unit test. Mayroong dalawang posibleng opsyon sa paglunsad: pagpapatakbo ng lahat ng unit test mula sa isang partikular na package o pagpapatakbo ng isang partikular na unit test sa isang partikular na package.
Ito ang hitsura ng isang halimbawa ng isang panloob na sistema ng pag-uulat. Batay sa mga resulta ng unit test, ang utPLSQL ay bumubuo ng isang maliit na ulat. Dito makikita natin ang resulta para sa bawat partikular na pagsusuri at ang pangkalahatang resulta ng unit test.
6 na panuntunan ng mga autotest
Bago magsimulang gumawa ng bagong system para sa automated na pagsubok ng loyalty system, kasama ng pamamahala, natukoy namin ang mga prinsipyong dapat sundin ng aming mga automated na pagsubok sa hinaharap.
- Ang mga autotest ay dapat na epektibo at dapat na kapaki-pakinabang. Mayroon kaming magagandang developer, na tiyak na kailangang banggitin, dahil malamang na makikita ng ilan sa kanila ang ulat na ito, at nagsusulat sila ng napakagandang code. Ngunit kahit ang kanilang kahanga-hangang code ay hindi perpekto at mayroon, mayroon, at patuloy na maglalaman ng mga error. Kinakailangan ang mga autotest upang mahanap ang mga error na ito. Kung hindi ito ang kaso, kung gayon ay nagsusulat kami ng mga masamang autotest, o nakarating kami sa isang patay na lugar na, sa prinsipyo, ay hindi binuo. Sa parehong mga kaso, kami ay gumagawa ng isang bagay na mali, at ang aming diskarte ay walang katuturan.
- Dapat gamitin ang mga autotest. Walang saysay na gumugol ng maraming oras at pagsisikap sa pagsulat ng isang produkto ng software, ilagay ito sa isang repositoryo at kalimutan ito. Dapat isagawa ang mga pagsusulit, at tumakbo nang regular hangga't maaari.
- Dapat gumana nang matatag ang mga autotest. Anuman ang oras ng araw, launch stand at iba pang mga setting ng system, ang mga pagsubok na tumatakbo ay dapat humantong sa parehong resulta. Bilang isang patakaran, ito ay sinisiguro ng katotohanan na ang mga autotest ay gumagana sa espesyal na data ng pagsubok na may mga nakapirming setting ng system.
- Dapat gumana ang mga autotest sa bilis na katanggap-tanggap para sa iyong proyekto. Ang oras na ito ay tinutukoy nang paisa-isa para sa bawat sistema. Ang ilang mga tao ay kayang magtrabaho sa buong araw, habang ang iba ay itinuturing na kritikal na gawin ito sa ilang segundo. Sasabihin ko sa iyo sa ibang pagkakataon kung anong mga pamantayan ng bilis ang nakamit namin sa aming proyekto.
- Dapat na flexible ang pag-develop ng autotest. Hindi ipinapayong tumanggi na subukan ang anumang pag-andar dahil hindi pa namin ito nagawa noon o para sa ibang dahilan. Ang utPLSQL ay hindi nagpapataw ng anumang mga paghihigpit sa pag-unlad, at ang Oracle, sa prinsipyo, ay nagpapahintulot sa iyo na magpatupad ng iba't ibang bagay. Karamihan sa mga problema ay may solusyon, ito ay isang bagay lamang ng oras at pagsisikap.
- Deployability. Mayroon kaming ilang stand kung saan kailangan naming magpatakbo ng mga pagsubok. Sa bawat stand, maaaring i-update ang isang data dump anumang oras. Kinakailangan na magsagawa ng isang proyekto na may mga awtomatikong pagsubok sa paraang maaari mong walang sakit na isagawa ang buo o bahagyang pag-install nito.
At sa pangalawang post sa loob ng ilang araw sasabihin ko sa iyo kung ano ang aming ginawa at kung ano ang mga resulta na aming nakamit.
Pinagmulan: www.habr.com