Testên yekîneyê di DBMS-ê de - em çawa di Sportmaster-ê de dikin, beşa duyemîn

Beşa yekem - vir.

Testên yekîneyê di DBMS-ê de - em çawa di Sportmaster-ê de dikin, beşa duyemîn

Rewşê bifikirin. Hûn bi peywira pêşxistina fonksiyonên nû re rû bi rû ne. Pêşketinên we yên beriya we hene. Ger em texmîn bikin ku tu berpirsiyariyên we yên exlaqî tune ne, hûn ê çi bikin?

Pir caran, hemî pêşveçûnên kevn têne ji bîr kirin û her tişt ji nû ve dest pê dike. Kes hez nake ku li koda kesek din bikole, lê ger wextê we hebe, çima hûn dest bi afirandina pergala xwe nakin? Ev nêzîkatiyek tîpîk e, û bi gelemperî rast e. Lê di projeya xwe de me ew xelet kir. Me pergala ceribandina otomatîkî ya pêşerojê li ser pêşkeftinên ceribandinên yekîneyê yên li ser utPLSQL ji pêşiyên xwe bingeh girt, û dûv re di gelek rêgezên paralel de xebitî.

  1. Vegerandina testên yekîneya kevn. Vejandin tê vê wateyê ku ceribandinan li gorî rewşa heyî ya pergala dilsoziyê biguncînin û ceribandinan li gorî standardên utPLSQL bicîh bikin.
  2. Çareserkirina pirsgirêkê bi têgihiştina ka bi rastî, kîjan rêbaz û pêvajoyên bi ototestan têne vegirtin. Pêdivî ye ku hûn vê agahiyê di serê xwe de bihêlin, an jî rasterast li ser koda ototestê encaman derxînin. Ji ber vê yekê, me biryar da ku katalogek çêbikin. Me kodek mnemonîkî ya bêhempa ji her ototestê re destnîşan kir, ravekirinek çêkir û mîhengan tomar kir (mînak, di çi şert û mercan de divê were destpêkirin, an ger ceribandina ceribandinê têk biçe divê çi bibe). Di bingeh de, me metadata di derbarê ceribandinên otomatê de tije kir û ew metadata li tabloyên şema standard ên utPLSQL danîn.
  3. Diyarkirina stratejiya berfirehbûnê, yanî. Hilbijartina fonksiyonê ya ku bi ceribandinên otomatîkî ve girêdayî ye. Me biryar da ku em bala xwe bidin sê tiştan: çêtirkirina pergalên nû, bûyerên hilberînê, û pêvajoyên pergalê yên sereke. Bi vî rengî, em bi serbestberdanê re paralel pêşve diçin, kalîteya wê ya bilindtir misoger dikin, di heman demê de qada paşveçûnê berfireh dikin û pêbaweriya pergalê li cihên krîtîk peyda dikin. Yekem kêşeya weha pêvajoya belavkirina dakêşan û prîmanan li ser kontrolê bû.
  4. Bi xwezayî, me dest bi pêşxistina ototestên nû kir. Yek ji karên berdanê yên yekem nirxandina performansa nimûneyên pêşwextkirî yên pergala dilsoziyê bû. Projeya me bloka pirsên SQL-ya hişk sabît heye ku li gorî şert û mercan xerîdaran hildibijêre. Mînakî, navnîşek hemî xerîdarên ku kirîna wan a paşîn li bajarek taybetî bû, an navnîşek xerîdarên ku mîqdara kirîna navînî li ser nirxek diyarkirî ye, bistînin. Digel ceribandinên xweser ên nivîskî, me nimûneyên pêşwext kontrol kirin, pîvanên performansa pîvanê tomar kirin, û her weha me ceribandina barkirinê jî hebû.
  5. Karkirina bi ototestan re divê hêsan be. Du kiryarên herî gelemperî ceribandinên xweser dimeşînin û daneyên ceribandinê diafirînin. Bi vî rengî du modulên alîkar di pergala me de xuya bûn: modulek destpêkirinê û modulek hilberîna daneyê.

    Destpêker bi yek pîvana têketina nivîsê re wekî prosedurek gerdûnî tê destnîşan kirin. Wekî pîvanek, hûn dikarin koda mînemonîkî ya ototest, navê pakêtê, navê ceribandinê, mîhenga testa otomatîkî, an jî bêjeyek veqetandî derbas bikin. Pêvajo hemî ototestên ku şertan têr dikin hildibijêre û dimeşîne.

    Modula hilberîna daneyê di forma pakêtek de tê pêşkêş kirin ku tê de ji bo her tiştê pergalê di bin ceribandinê de (tabloyek di databasê de), pêvajoyek taybetî hatî çêkirin ku daneyan li wir vedihewîne. Di vê prosedurê de, nirxên xwerû bi qasî ku gengaz têne dagirtin, ku çêkirina tiştan bi rastî bi klîkek tilikê piştrast dike. Û ji bo karanîna hêsan, şablonên ji bo daneyên hilberandî hatin afirandin. Mînakî, bi têlefonek ceribandinê û kirînek qedandî xerîdarek temenek diyar biafirînin.

  6. Pêdivî ye ku ototest di demek ku ji bo pergala we were pejirandin de dest pê bikin û bimeşînin. Ji ber vê yekê, destpêkek şevek rojane hate organîze kirin, li ser bingeha encamên ku raporek li ser encaman tê çêkirin û bi nameya pargîdanî ji tevahiya tîmê pêşkeftinê re tê şandin. Piştî sererastkirina ototestên kevn û afirandina yên nû, dema xebatê ya giştî 30 hûrdem bû. Ev performans ji her kesî re xweş bû, ji ber ku dest pê kirin li derveyî demjimêrên xebatê pêk hat.

    Lê diviyabû em li ser xweşbînkirina leza xebatê bixebitin. Di hilberînê de pergala dilsoziyê bi şev tê nûve kirin. Wekî beşek ji yek ji serbestberdanan, me neçar ma ku bi şev guhertinên lezgîn bikin. Li benda nîv saetê ji bo encamên testên otomatê di sê serê sibê de, kesê berpirsiyarê berdanê kêfxweş nekir (silavên germ ji Alexey Vasyukov re!), û sibeha din gelek gotinên xweş ji pergala me re hatin gotin. Lê di encamê de ji bo xebatê standardek 5 deqeyî hate damezrandin.

    Ji bo bilezkirina performansê, me du rêbaz bikar anîn: ototestan dest pê kir ku di sê mijarên paralel de dimeşin, bextewar ev ji ber mîmariya pergala dilsoziya me pir hêsan e. Û me dev ji nêzîkatiya ku ototest ji xwe re daneyên testê çê nake, lê hewl dide ku di pergalê de tiştek maqûl bibîne, berda. Piştî çêkirina guhertinan, dema xebitandinê ya tevahî 3-4 hûrdem kêm bû.

  7. Projeyek bi ceribandinên otomatîkî divê bikaribe li cîhên cihêreng were bicîh kirin. Di destpêka rêwîtiya me de, hewildan hatin kirin ku em pelên xwe yên komê binivîsin, lê diyar bû ku sazkirinek otomatîkî ya xwe-nivîskî tam tirsnak bû, û em berê xwe didin çareseriyên pîşesaziyê. Ji ber ku proje gelek kodên rasterast digire (berî her tiştî, em koda ototestê hilînin) û daneya pir hindik (daneyên sereke metadata di derbarê ceribandinên otomatîkî de ne), pêkanîna di projeya Liquibase de pir hêsan derket holê.

    Ew pirtûkxaneyek çavkaniyek vekirî, serbixwe-danûstendinê ye ji bo şopandin, rêvebirin û bicihanîna guhertinên şema databasê. Bi rêza fermanê an çarçoveyên wekî Apache Maven ve têne rêve kirin. Prensîba xebata Liquibase pir hêsan e. Projeyek me heye ku bi rengek diyarkirî hatî organîze kirin, ku ji guhertin an nivîsarên ku hewce ne ku li servera armancê werin rijandin pêk tê, û pelên kontrolê yên ku diyar dikin ku divê ev guhertin di kîjan rêzê û bi kîjan pîvanan de bêne saz kirin pêk tê.

    Di asta DBMS-ê de, tabloyek taybetî tê afirandin ku tê de Liquibase têketina rollover hilîne. Her guhertinek hashek hesabkirî heye, ku her carê di navbera proje û dewletê de di databasê de tê berhev kirin. Spas ji Liquibase re, em dikarin bi hêsanî guheztinên pergala xwe li her çerxerê derxînin. Naha ceribandinên otomatîkî li ser çerxên ceribandin û berdanê, û hem jî li ser konteyniran (derdorên kesane yên pêşdebiran) têne destpêkirin.

Testên yekîneyê di DBMS-ê de - em çawa di Sportmaster-ê de dikin, beşa duyemîn

Ji ber vê yekê, bila em li ser encamên karanîna pergala ceribandina yekîneya xwe biaxivin.

  1. Bê guman, berî her tiştî, em pê bawer in ku me dest bi pêşxistina nermalava çêtir kiriye. Rojane ototest têne destpêkirin û her serbestberdanê bi dehan xeletî têne dîtin. Wekî din, hin ji van xeletiyan tenê nerasterast bi fonksiyona ku me bi rastî dixwest ku biguhezîne ve girêdayî ne. Gumanên cidî hene ku ev xeletî bi ceribandina destan hatine dîtin.
  2. Tîm niha pê bawer e ku fonksiyonên taybetî rast dixebitin... Berî her tiştî, ev pêvajoyên me yên krîtîk eleqedar dike. Mînakî, di şeş mehên borî de me di dabeşkirina dakêşan û bonusên li ser meqbûzan de ti pirsgirêkek çênebû, tevî guhertinên berdanê, her çend di heyamên berê de xeletî bi hin caran çêbûn.
  3. Me karî ku hejmara dubareyên ceribandinê kêm bikin. Ji ber ku ototest ji bo fonksiyonên nû têne nivîsandin, analyst û ceribandinên part-time koda kalîteya bilindtir distînin, ji ber ku berê hatiye kontrol kirin.
  4. Hin pêşveçûnên di ceribandina otomatîkî de ji hêla pêşdebiran ve têne bikar anîn. Mînakî, daneyên ceribandinê yên li ser konteyneran bi karanîna modula hilberîna tiştan têne afirandin.
  5. Girîng e ku me ji hêla pêşdebiran ve "pejirandina" pergala ceribandina otomatîkî pêşxistiye. Têgihiştinek heye ku ev girîng û kêrhatî ye. Lê ji tecrûbeya xwe ez dikarim bibêjim ku ev ji rewşê dûr e. Pêdivî ye ku ototest bêne nivîsandin, pêdivî ye ku ew werin piştgirî kirin û pêşve bibin, encam bêne analîz kirin, û pir caran ev lêçûnên demê bi tenê ne hêja ne. Pir hêsantir e ku meriv biçe hilberînê û li wir bi pirsgirêkan re mijûl bibe. Li vir, pêşdebiran rêz dikin û ji me dipirsin ku fonksiyona xwe bi ototestan veşêrin.

Çi ye?

Testên yekîneyê di DBMS-ê de - em çawa di Sportmaster-ê de dikin, beşa duyemîn

Ka em li ser plansaziyên pêşkeftinê yên ji bo projeya ceribandina otomatîkî biaxivin.

Bê guman, heya ku pergala dilsoziya Sportmaster zindî ye û pêşkeftina xwe didomîne, di heman demê de gengaz e ku ototestên hema hema bêdawî pêşve bibin. Ji ber vê yekê, rêgeziya sereke ya pêşveçûnê berfirehkirina qada vegirtinê ye.

Her ku hejmara ototestan zêde dibe, dema xebata wan a giştî dê bi domdarî zêde bibe, û em ê dîsa vegerin ser mijara performansê. Bi îhtîmaleke mezin, çareserî dê zêdekirina hejmara têlên paralel be.

Lê ev awayên pêşveçûnê yên eşkere ne. Ger em li ser tiştek ne-tewretir biaxivin, em van tiştan ronî dikin:

  1. Heya nuha, rêveberiya xweseriya testê di asta DBMS de tête kirin, ango. zanîna PL / SQL ji bo karê serkeftî pêwîst e. Ger hewce be, rêveberiya pergalê (mînakî, destpêkirin an afirandina metadata), hûn dikarin bi karanîna Jenkins an tiştek wusa panelek rêveberiyê biafirînin.
  2. Her kes ji nîşaneyên jimareyî û kalîteyî hez dike. Ji bo ceribandina otomatîkî, nîşanek gerdûnî ya weha Coverage an metrîka vegirtina kodê ye. Bi karanîna vê nîşankerê, em dikarin destnîşan bikin ka ji sedî koda pergala me ya di bin ceribandinê de ji hêla ototestan ve tê vegirtin. Ji guhertoya 12.2-ê dest pê dike, Oracle şiyana hesabkirina vê metrikê peyda dike û karanîna pakêta standard DBMS_PLSQL_CODE_COVERAGE pêşkêşî dike.

    Pergala meya ototest tenê salek zêdetir e û belkî niha dema nirxandina vegirtina me ye. Di projeya min a paşîn de (ne projeyek Sportmaster) ev tişt çêbû. Salek piştî xebata li ser testên otomatê, rêveberî peywira nirxandina ji sedî koda ku em vedigirin destnîşan kir. Bi vegirtina ji 1% zêdetir, rêveberî dê kêfxweş bibe. Em, pêşdebiran, encamek ji% 10 hêvî dikir. Me vegirtina kodê saz kir, ew pîvan kir, û 20% girt. Ji bo pîrozbahiyê, em çûn ku xelatê bistînin, lê em çawa çûn ku em bistînin û paşê em çûn ku derê çîrokek bi tevahî cûda ye.

  3. Testên otomatîkî dikarin karûbarên webê yên vekirî kontrol bikin. Oracle rê dide me ku em viya pir baş bikin, û em ê êdî bi gelek pirsgirêkan re rû bi rû nemînin.
  4. Û, bê guman, pergala meya ceribandina otomatîkî dikare li projeyek din were sepandin. Çareseriya ku me wergirt gerdûnî ye û tenê karanîna Oracle hewce dike. Min bihîst ku projeyên din ên Sportmaster bi ceribandina otomatîkî re eleqedar in û dibe ku em ê biçin wan.

vebiguherin

Werin em bi kurtî. Li ser projeya pergala dilsoziyê ya li Sportmaster, me karî ku pergalek ceribandina otomatîkî bicîh bînin. Ew li ser çareseriya utPLSQL ji Stephen Feuerstein ve girêdayî ye. Li dora utPLSQL koda ototest û modulên xwe-nivîskî yên alîkar hene: modula destpêkirinê, modula hilberîna daneyê û yên din. Autotests rojane têne destpêkirin û ya herî girîng, ew dixebitin û bikêr in. Em pê bawer in ku me dest bi berdana nermalava kalîteya bilindtir kiriye. Di heman demê de, çareseriya encam gerdûnî ye û dikare bi serbestî li her projeyek ku pêdivî ye ku ceribandina otomatîkî ya li ser Oracle DBMS organîze bike were sepandin.

PS Ev gotar ne pir taybetî ye: gelek nivîs hene û di pratîkê de nimûneyên teknîkî tune. Ger mijar bi gelemperî balkêş be, wê hingê em amade ne ku wê bidomînin û bi berdewamiyekê vegerin, li ku derê em ê ji we re vebêjin ka di şeş mehên borî de çi guheriye û nimûneyên kodê peyda bikin.

Heke xalên ku divê di pêşerojê de bêne balkişandin, an pirsên ku hewcedariya wan bi eşkerekirinê heye, şîroveyan binivîsin.

Tenê bikarhênerên qeydkirî dikarin beşdarî anketê bibin. Têketinji kerema xwe.

Ma em ê li ser vê yekê bêtir binivîsin?

  • Erê, bê guman

  • Na spas

12 bikarhêneran deng dan. 4 bikarhêner betal bûn.

Source: www.habr.com

Add a comment