Vipimo vya kitengo katika DBMS - jinsi tunavyofanya katika Sportmaster, sehemu ya kwanza

Habari Habr!

Jina langu ni Maxim Ponomarenko na mimi ni msanidi programu katika Sportmaster. Nina uzoefu wa miaka 10 katika uwanja wa IT. Alianza kazi yake katika upimaji wa mwongozo, kisha akabadilisha maendeleo ya hifadhidata. Kwa miaka 4 iliyopita, nikikusanya maarifa yaliyopatikana katika majaribio na ukuzaji, nimekuwa nikifanya majaribio ya kiotomatiki katika kiwango cha DBMS.

Nimekuwa kwenye timu ya Sportmaster kwa zaidi ya mwaka mmoja na ninatengeneza majaribio ya kiotomatiki kwenye mojawapo ya miradi mikuu. Mnamo Aprili, mimi na wavulana kutoka Sportmaster Lab tulizungumza katika mkutano huko Krasnodar, ripoti yangu iliitwa "Vipimo vya kitengo katika DBMS," na sasa nataka kushiriki nawe. Kutakuwa na maandishi mengi, kwa hivyo niliamua kugawa ripoti katika machapisho mawili. Katika kwanza, tutazungumzia kuhusu autotests na kupima kwa ujumla, na kwa pili, nitakaa kwa undani zaidi juu ya mfumo wetu wa kupima kitengo na matokeo ya matumizi yake.

Kwanza, nadharia kidogo ya boring. Jaribio la kiotomatiki ni nini? Huu ni upimaji unaofanywa kwa kutumia programu, na katika IT ya kisasa inazidi kutumika katika ukuzaji wa programu. Hii ni kutokana na ukweli kwamba makampuni yanakua, mifumo yao ya habari inakua na, ipasavyo, kiasi cha utendaji kinachohitaji kujaribiwa kinaongezeka. Kufanya majaribio ya mwongozo kunazidi kuwa ghali zaidi.

Nilifanya kazi kwa kampuni kubwa ambayo matoleo yake hutoka kila baada ya miezi miwili. Wakati huo huo, mwezi mzima ulitumika kuwa na wajaribu kadhaa kuangalia kwa mikono utendakazi. Shukrani kwa utekelezaji wa otomatiki na timu ndogo ya wasanidi programu, tuliweza kupunguza muda wa majaribio hadi wiki 2 katika mwaka na nusu. Hatujaongeza tu kasi ya kupima, lakini pia kuboresha ubora wake. Majaribio ya kiotomatiki huzinduliwa mara kwa mara na daima hufanya ukaguzi mzima uliojumuishwa ndani yake, ambayo ni, tunatenga sababu ya kibinadamu.

IT ya kisasa ina sifa ya ukweli kwamba msanidi anaweza kuhitajika sio tu kuandika msimbo wa bidhaa, lakini pia kuandika vipimo vya kitengo vinavyoangalia msimbo huu.

Lakini vipi ikiwa mfumo wako unategemea mantiki ya seva? Hakuna suluhisho la jumla au mbinu bora kwenye soko. Kama sheria, kampuni hutatua shida hii kwa kuunda mfumo wao wa upimaji wa maandishi. Huu ni mfumo wetu wa kujiandikia wenyewe wa majaribio ya kiotomatiki ambao uliundwa kwenye mradi wetu na nitauzungumzia katika ripoti yangu.

Kujaribu uaminifu

Kwanza, hebu tuzungumze kuhusu mradi ambapo tuliweka mfumo wa kupima otomatiki. Mradi wetu ni mfumo wa uaminifu wa Sportmaster (kwa njia, tayari tumeandika juu yake chapisho hili).

Ikiwa kampuni yako ni kubwa ya kutosha, basi mfumo wako wa uaminifu utakuwa na sifa tatu za kawaida:

• Mfumo wako utapakiwa sana
• Mfumo wako utakuwa na michakato changamano ya kompyuta
• Mfumo wako utaboreshwa kikamilifu.

Hebu tuende kwa utaratibu ... Kwa jumla, ikiwa tunazingatia bidhaa zote za Sportmaster, basi tuna maduka zaidi ya 1000 nchini Urusi, Ukraine, China, Kazakhstan na Belarus. Karibu ununuzi 300 hufanywa katika maduka haya kila siku. Hiyo ni, kila pili hundi 000-3 huingia kwenye mfumo wetu. Kwa kawaida, mfumo wetu wa uaminifu umejaa sana. Na kwa kuwa inatumiwa kikamilifu, ni lazima tutoe viwango vya juu zaidi vya ubora wake, kwa sababu kosa lolote katika programu linamaanisha hasara kubwa ya fedha, sifa na nyingine.

Wakati huo huo, Sportmaster inaendesha matangazo zaidi ya mia tofauti. Kuna aina mbalimbali za matangazo: kuna matangazo ya bidhaa, kuna yale yaliyotolewa kwa siku ya juma, kuna yale yaliyofungwa kwenye duka maalum, kuna matangazo kwa kiasi cha risiti, kuna kwa idadi ya bidhaa. Kwa ujumla, sio mbaya. Wateja wana bonasi na misimbo ya ofa ambayo hutumiwa wakati wa kufanya ununuzi. Yote hii inaongoza kwa ukweli kwamba kuhesabu amri yoyote ni kazi isiyo ya kawaida sana.

Algorithm inayotumia usindikaji wa agizo ni mbaya sana na ngumu. Na mabadiliko yoyote kwa algorithm hii ni hatari sana. Ilionekana kuwa mabadiliko yanayoonekana kuwa madogo sana yanaweza kusababisha athari zisizotabirika kabisa. Lakini ni michakato changamano kama hii ya kompyuta, haswa zile zinazotekeleza utendakazi muhimu, ndio wagombea bora wa uwekaji otomatiki. Kuangalia kesi kadhaa zinazofanana kwa mkono ni muda mwingi. Na kwa kuwa hatua ya kuingia katika mchakato haijabadilishwa, baada ya kuielezea mara moja, unaweza haraka kuunda vipimo vya moja kwa moja na kuwa na uhakika kwamba utendaji utafanya kazi.

Kwa kuwa mfumo wetu unatumika kikamilifu, biashara itataka kitu kipya kutoka kwako, ishi kulingana na wakati na uelekezwe kwa wateja. Katika mfumo wetu wa uaminifu, matoleo hutoka kila baada ya miezi miwili. Hii ina maana kwamba kila baada ya miezi miwili tunahitaji kufanya rejeshi kamili ya mfumo mzima. Wakati huo huo, kwa kawaida, kama katika IT yoyote ya kisasa, maendeleo hayaendi mara moja kutoka kwa msanidi programu hadi kwa uzalishaji. Huanzia kwenye mzunguko wa msanidi programu, kisha hupitia benchi ya majaribio mfululizo, kutolewa, kukubalika, na kisha kuishia katika uzalishaji. Kwa kiwango cha chini, kwenye mizunguko ya mtihani na kutolewa, tunahitaji kufanya regression kamili ya mfumo mzima.

Sifa zilizoelezewa ni za kawaida kwa karibu mfumo wowote wa uaminifu. Hebu tuzungumze kuhusu vipengele vya mradi wetu.

Kiteknolojia, 90% ya mantiki ya mfumo wetu wa uaminifu inategemea seva na inatekelezwa kwenye Oracle. Kuna mteja aliyefichuliwa huko Delphi, ambayo hufanya kazi ya msimamizi wa mahali pa kazi otomatiki. Kuna huduma za wavuti zilizofichuliwa kwa programu za nje (kwa mfano tovuti). Kwa hivyo, ni jambo la busara sana kwamba ikiwa tutatumia mfumo wa upimaji otomatiki, tutafanya kwenye Oracle.

Mfumo wa uaminifu katika Sportmaster umekuwepo kwa zaidi ya miaka 7 na uliundwa na watengenezaji moja ... Idadi ya wastani ya watengenezaji kwenye mradi wetu wakati wa miaka 7 ilikuwa watu 3-4. Lakini katika mwaka uliopita, timu yetu imekua kwa kiasi kikubwa, na sasa kuna watu 10 wanaofanya kazi kwenye mradi huo. Hiyo ni, watu huja kwenye mradi ambao hawajui kazi za kawaida, taratibu, na usanifu. Na kuna hatari kubwa kwamba tutakosa makosa.

Mradi huu una sifa ya kukosekana kwa wajaribu waliojitolea kama vitengo vya wafanyikazi. Kuna, bila shaka, kupima, lakini upimaji unafanywa na wachambuzi, pamoja na majukumu yao mengine kuu: kuwasiliana na wateja wa biashara, watumiaji, kuendeleza mahitaji ya mfumo, nk. nk ... Licha ya ukweli kwamba upimaji unafanywa ubora wa juu sana (hii ni sahihi hasa kutaja, kwa kuwa baadhi ya wachambuzi wanaweza kupata jicho la ripoti hii), ufanisi wa utaalam na mkusanyiko juu ya jambo moja haujafutwa. .

Kwa kuzingatia yote yaliyo hapo juu, ili kuboresha ubora wa bidhaa iliyotolewa na kupunguza muda wa maendeleo, wazo la kupima otomatiki kwenye mradi linaonekana kuwa la mantiki sana. Na katika hatua tofauti za kuwepo kwa mfumo wa uaminifu, wasanidi programu binafsi walifanya jitihada za kufunika misimbo yao kwa majaribio ya vitengo. Kwa ujumla ilikuwa ni mchakato usiounganishwa, na kila mtu akitumia usanifu na mbinu zao. Matokeo ya mwisho yalikuwa ya kawaida kwa vipimo vya kitengo: vipimo vilitengenezwa, vilivyotumiwa kwa muda, vilivyohifadhiwa kwenye hifadhi ya faili iliyobadilishwa, lakini wakati fulani waliacha kukimbia na kusahau. Kwanza kabisa, hii ilitokana na ukweli kwamba vipimo vilifungwa zaidi kwa mtendaji maalum, na sio kwa mradi huo.

utPLSQL huja kuwaokoa

Je! unajua chochote kuhusu Stephen Feuerstein?

Huyu ni mtu mwerevu ambaye alitumia muda mrefu wa kazi yake kufanya kazi na Oracle na PL/SQL, na ameandika idadi kubwa ya kazi kwenye mada hii. Moja ya vitabu vyake maarufu huitwa: “Oracle PL/SQL. Kwa wataalamu." Ni Stephen ambaye alitengeneza suluhisho la utPLSQL, au, kama inavyosimama, mfumo wa Upimaji wa Kitengo cha Oracle PL/SQL. Suluhisho la utPLSQL liliundwa mnamo 2016, lakini linaendelea kufanyiwa kazi kikamilifu na matoleo mapya yanatolewa. Wakati wa kuripoti, toleo jipya zaidi lilianza Machi 24, 2019.
Ni nini. Huu ni mradi tofauti wa chanzo huria. Ina uzani wa megabytes kadhaa, pamoja na mifano na hati. Kimwili, ni schema tofauti katika hifadhidata ya ORACLE iliyo na seti ya vifurushi na majedwali ya kuandaa majaribio ya kitengo. Ufungaji huchukua sekunde chache. Kipengele tofauti cha utPLSQL ni urahisi wa matumizi.
Ulimwenguni, utPLSQL ni utaratibu wa kufanya majaribio ya kitengo, ambapo jaribio la kitengo hueleweka kama taratibu za kawaida za kundi la Oracle, shirika ambalo hufuata sheria fulani. Mbali na kuzindua, utPLSQL huhifadhi kumbukumbu ya majaribio yako yote, na pia ina mfumo wa kuripoti wa ndani.

Hebu tuangalie mfano wa jinsi msimbo wa mtihani wa kitengo unavyoonekana, unaotekelezwa kwa kutumia mbinu hii.

Kwa hivyo, skrini inaonyesha msimbo wa vipimo vya kawaida vya kifurushi na vipimo vya kitengo. Je, ni mahitaji gani ya lazima? Pakiti lazima iwe na kiambishi awali na "utp_". Taratibu zote zilizo na vipimo lazima ziwe na kiambishi awali sawa. Kifurushi lazima kiwe na taratibu mbili za kawaida: "utp_setup" na "utp_teardown". Utaratibu wa kwanza unaitwa kwa kuanzisha upya kila mtihani wa kitengo, pili - baada ya uzinduzi.

"utp_setup", kama sheria, hutayarisha mfumo wetu kufanya jaribio la kitengo, kwa mfano, kuunda data ya jaribio. "utp_teardown" - kinyume chake, kila kitu kinarudi kwenye mipangilio ya awali na kuweka upya matokeo ya uzinduzi.

Huu hapa ni mfano wa jaribio rahisi zaidi la kitengo ambalo hukagua uhalalishaji wa nambari ya simu ya mteja iliyoingizwa kuwa fomu ya kawaida ya mfumo wetu wa uaminifu. Hakuna viwango vya lazima vya jinsi ya kuandika taratibu na vipimo vya kitengo. Kama sheria, simu inafanywa kwa njia ya mfumo chini ya jaribio, na matokeo yanayorudishwa na njia hii yanalinganishwa na ile ya kumbukumbu. Ni muhimu kwamba ulinganisho wa matokeo ya kumbukumbu na moja iliyopatikana hutokea kwa njia za kawaida za utPLSQL.

Jaribio la kitengo linaweza kuwa na idadi yoyote ya hundi. Kama inavyoonekana kutoka kwa mfano, tunapiga simu nne mfululizo kwa njia iliyojaribiwa ili kurekebisha nambari ya simu na kutathmini matokeo baada ya kila simu. Wakati wa kuendeleza mtihani wa kitengo, lazima uzingatie kwamba kuna hundi ambazo haziathiri mfumo kwa njia yoyote, na baada ya baadhi unahitaji kurudi kwenye hali ya awali ya mfumo.
Kwa mfano, katika jaribio la kitengo kilichowasilishwa tunapanga tu nambari ya simu ya kuingiza, ambayo haiathiri mfumo wa uaminifu kwa njia yoyote.

Na ikiwa tunaandika vipimo vya kitengo kwa kutumia njia ya kuunda mteja mpya, basi baada ya kila mtihani mteja mpya ataundwa katika mfumo, ambayo inaweza kuathiri uzinduzi wa baadae wa mtihani.

Hivi ndivyo majaribio ya kitengo huendeshwa. Kuna chaguo mbili zinazowezekana za uzinduzi: kuendesha majaribio yote ya kitengo kutoka kwa kifurushi mahususi au kuendesha jaribio mahususi la kitengo katika kifurushi mahususi.

Hivi ndivyo mfano wa mfumo wa kuripoti wa ndani unavyoonekana. Kulingana na matokeo ya jaribio la kitengo, utPLSQL huunda ripoti ndogo. Ndani yake tunaona matokeo kwa kila hundi maalum na matokeo ya jumla ya jaribio la kitengo.

Sheria 6 za majaribio ya kiotomatiki

Kabla ya kuanza kuunda mfumo mpya wa majaribio ya kiotomatiki ya mfumo wa uaminifu, pamoja na usimamizi, tulibaini kanuni ambazo majaribio yetu ya kiotomatiki ya baadaye yanapaswa kuzingatia.

1. Majaribio otomatiki lazima yawe na ufanisi na lazima yawe na manufaa. Tuna watengenezaji wa ajabu, ambao kwa hakika wanahitaji kutajwa, kwa sababu baadhi yao labda wataona ripoti hii, na wanaandika msimbo wa ajabu. Lakini hata kanuni zao za ajabu si kamili na ina, ina, na itaendelea kuwa na makosa. Majaribio otomatiki yanahitajika ili kupata hitilafu hizi. Ikiwa sivyo, basi ama tunaandika ukaguzi mbaya, au tumefika kwenye eneo lililokufa ambalo, kimsingi, halijatengenezwa. Katika visa vyote viwili, tunafanya kitu kibaya, na njia yetu haina maana.
2. Majaribio ya kiotomatiki yanapaswa kutumika. Haina maana kutumia muda mwingi na jitihada katika kuandika bidhaa ya programu, kuiweka kwenye hifadhi na kuisahau. Vipimo vinapaswa kuendeshwa, na kukimbia mara kwa mara iwezekanavyo.
3. Majaribio ya kiotomatiki yanapaswa kufanya kazi kwa utulivu. Bila kujali wakati wa siku, stendi ya uzinduzi na mipangilio mingine ya mfumo, uendeshaji wa majaribio unapaswa kusababisha matokeo sawa. Kama sheria, hii inahakikishwa na ukweli kwamba otomatiki hufanya kazi na data maalum ya majaribio na mipangilio ya mfumo uliowekwa.
4. Majaribio otomatiki yanapaswa kufanya kazi kwa kasi inayokubalika kwa mradi wako. Wakati huu umedhamiriwa kibinafsi kwa kila mfumo. Watu wengine wanaweza kumudu kufanya kazi siku nzima, wakati wengine wanaona ni muhimu kuifanya kwa sekunde. Nitakuambia baadaye ni viwango gani vya kasi ambavyo tulifikia katika mradi wetu.
5. Ukuzaji wa jaribio otomatiki unapaswa kubadilika. Haifai kukataa kujaribu utendakazi wowote kwa sababu tu hatujaifanya hapo awali au kwa sababu nyingine. utPLSQL haitoi vikwazo vyovyote katika maendeleo, na Oracle, kimsingi, hukuruhusu kutekeleza mambo mbalimbali. Shida nyingi zina suluhisho, ni suala la wakati na bidii tu.
6. Utumiaji. Tuna vituo kadhaa ambapo tunahitaji kuendesha majaribio. Katika kila stendi, utupaji wa data unaweza kusasishwa wakati wowote. Inahitajika kufanya mradi na vipimo vya kiotomatiki kwa njia ambayo unaweza kutekeleza usakinishaji wake kamili au sehemu bila maumivu.

Na katika chapisho la pili katika siku chache nitakuambia tulifanya nini na ni matokeo gani tuliyopata.

Chanzo: mapenzi.com