{"id":37666,"date":"2019-10-31T22:18:55","date_gmt":"2019-10-31T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya\/"},"modified":"2019-10-31T22:18:55","modified_gmt":"2019-10-31T19:18:55","slug":"unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"\u00dcksuste testimine andmebaasides - kuidas me seda Sportmasteris teeme, teine osa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Esimene osa \u2014 siin<\/a><\/noindex>.<\/i><\/p>\n

\"\u00dcksuste<\/a><\/noindex><\/p>\n

Kujutage ette olukorda. Te peate arendama uut funktsionaalsust. Teil on olemas eelmiste t\u00f6\u00f6tajate materjalid. Kui j\u00e4tta k\u00f5rvale moraalsed kohustused, kuidas te siis k\u00e4ituksite?<\/p>\n

Tavaliselt unustatakse k\u00f5ik vanad arendused ja k\u00f5ik hakkab nullist. Keegi ei armasta teiste koodiga vaeva n\u00e4ha, ja kui aega on, siis miks mitte luua oma s\u00fcsteem? See on t\u00fc\u00fcpiline l\u00e4henemine, ja see on suuresti \u00f5ige. Kuid meie projektis tegime teistmoodi. Tulevase automaatsete testide s\u00fcsteemi aluseks saime meie eelk\u00e4ijate utPLSQL unit-testide arendused ning seej\u00e4rel asusime t\u00f6\u00f6tama mitmes paralleelses suunas.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Vana unit-testide taastamine.<\/b> Taastamine t\u00e4hendab testide kohandamist olemasoleva lojaalsuss\u00fcsteemi seisuga ja testide kohandamist utPLSQL standarditega. <\/li>\n
  2. Probleemi lahendamine, et m\u00f5ista, millised meetodid ja protsessid on meie automaatsete testidega kaetud. <\/b>Kas tuleb see teave meeles hoida v\u00f5i teha j\u00e4reldusi otse automaatsete testide koodist. Seet\u00f5ttu otsustasime koostada katalooge. Igale automaatsetele testile andsime unikaalse mnemokoodi, koostasime kirjelduse ja fikseerisime seaded (n\u00e4iteks, millistes tingimustes see peaks k\u00e4ivituma v\u00f5i mis peaks juhtuma, kui testi k\u00e4ivitamine eba\u00f5nnestus). Sisuliselt t\u00e4itsime automaatsete testide meetainformatsiooni ja paigutasime need standardsetesse utPLSQL skeemi tabelitesse.<\/li>\n
  3. Laiendamisstrateegia m\u00e4\u00e4ratlemine, st funktsionaalsuse valimine, mida tuleb automaatsete testidega kontrollida.<\/b> Otsustasime keskenduda kolmele asjale: s\u00fcsteemi uued t\u00e4iustused, tootmisprobleemid ja s\u00fcsteemi p\u00f5hiprotsessid. Nii arendame end v\u00e4lja paralleelselt v\u00e4ljaande kvaliteedi parandamisega, samal ajal laiendades regressiooni ulatust ja tagades s\u00fcsteemi usaldusv\u00e4\u00e4rsuse kriitilistes kohtades. Esimene kitsaskoht oli allahindluste ja boonuste jaotamise protsess.<\/li>\n
  4. Loomulikult hakkasime t\u00f6\u00f6tama uute automaatsete testide v\u00e4lja t\u00f6\u00f6tamisega. <\/b>\u00dche esimestest vabastamis\u00fclesannetest oli j\u00f5udluse hindamine eelseadistatud lojaalsuse valimite osas. Meie projektis on plokk rangelt fikseeritud SQL-p\u00e4ringutest, mis valivad kliente tingimuste alusel. N\u00e4iteks, saada k\u00f5igi klientide nimekiri, kelle viimane ost tehti konkreetses linnas, v\u00f5i nimekiri klientidest, kelle keskmine ostusumma \u00fcletab kindlat v\u00e4\u00e4rtust. Kirjutades automaatkatsetusi, kontrollisime eelseadistatud valimeid ja fikseerisime standardseid j\u00f5udluse parameetreid, lisaks saime me koormustestimise.<\/li>\n
  5. Automaatkatsetustega t\u00f6\u00f6tamine peab olema mugav<\/b>. K\u00f5ige sagedamini tehakse kahte tegevust: automaatkatsete k\u00e4ivitamine ja testandmete loomine. Nii ilmus meie s\u00fcsteemi kaks abimoodulit: k\u00e4ivitamismoodul ja andmete genereerimise moodul.\n

    K\u00e4ivitamismoodul on esitatud \u00fche universaalse protseduurina, millel on \u00fcks sissekande tekstiparameeter. Parameetrina saab edastada automaatkatse mnemo-koodi, pakettnime, testi nime, automaatkatse seade v\u00f5i reserveeritud v\u00f5tmes\u00f5na. Protseduur valib ja k\u00e4ivitab k\u00f5ik automaatkatsed, mis vastavad tingimustele.<\/p>\n

    Andmete genereerimise moodul on esitatud paketina, kus iga katsetatava s\u00fcsteemi objekti (tabel andmebaasis) jaoks on loodud spetsiaalne protseduur, mis sisestab sinna andmed. Selles protseduuris on maksimaalselt t\u00e4idetud vaikimisi v\u00e4\u00e4rtused, mis tagavad objektide loomise s\u00f5rmenipsuga. Ja mugavuse huvides on loodud loodud andmete mallid. N\u00e4iteks luua teatud vanuses klient koos testtelefoniga ja sooritatud ostuga.<\/li>\n

  6. Automaatkatsetused peavad k\u00e4ivituma ja t\u00f6\u00f6tama teie s\u00fcsteemi jaoks vastuv\u00f5etava aja jooksul. <\/b>Seet\u00f5ttu korraldati igap\u00e4evane \u00f6ine k\u00e4ivitamine, mille tulemuste p\u00f5hjal koostatakse aruanne ja saadetakse kogu arendusmeeskonnale ettev\u00f5tte e-posti kaudu. P\u00e4rast vanade automaatkatsete taastamist ja uute loomist oli kogu t\u00f6\u00f6aeg 30 minutit. Selline j\u00f5udlus rahuldas k\u00f5iki, kuna k\u00e4ivitamine toimus t\u00f6\u00f6v\u00e4lisel ajal.\n

    Kuid s\u00fcsteemi t\u00f6\u00f6 kiirusest tuli siiski t\u00f6\u00f6tada. Loodud lojaalsuss\u00fcsteemi uuendamine toimub \u00f6\u00f6sel. \u00dche versiooni raames tuli \u00f6\u00f6sel kiirkorras muudatusi sisse viia. Kella kolme \u00f6\u00f6sel poole tunni ooteaeg automaatkatsete tulemusi ei teinud versiooni eest vastutavat inimest \u00f5nnelikuks (soojad tervitused Aleksei Vasyukovile!), ja j\u00e4rgmisel hommikul \u00f6eldi meie s\u00fcsteemi suunal palju sooje s\u00f5nu. Kuid tulemuseks oli 5-minutilise standardi kehtestamine t\u00f6\u00f6 jaoks.<\/p>\n

    T\u00f5hususe suurendamiseks kasutasime kahte meetodit: automaatkatseid hakati k\u00e4ivitama kolmes paralleelses voos, \u00f5nneks on see meie lojaalsuss\u00fcsteemi arhitektuuri t\u00f5ttu v\u00e4ga mugav. Ja loobusime l\u00e4henemisest, kus automatiseeritud test ei loo ise testandmeid, vaid p\u00fc\u00fcab leida s\u00fcsteemist sobivaid. P\u00e4rast muudatuste tegemist v\u00e4henes kogu t\u00f6\u00f6 aeg 3\u20134 minutini.<\/li>\n

  7. Automaatkatsete projekt peab olema v\u00f5imalik erinevates keskkondades kasutusele v\u00f5tta.<\/b> Alguses oli katseid kirjutada oma .bat faile, kuid selgus, et k\u00e4sitsi automatiseeritud seadistus on t\u00e4ielik \u00f5udus ja p\u00f6\u00f6rdusime t\u00f6\u00f6stuslike lahenduste poole. Kuna projektis on v\u00e4ga palju otse koodi (peamiselt hoiame automaatkatsete koodi) ja v\u00e4ga v\u00e4he andmeid (peamised andmed on metainformatsioon automaatkatsete kohta), osutus Liquibase'i juurutamine projektis \u00e4\u00e4rmiselt lihtsaks.\n

    See on andmebaasist s\u00f5ltumatu avatud l\u00e4htekoodiga teek, mis j\u00e4lgib, haldab ja rakendab andmebaasiskeemi muudatusi. Haldatakse k\u00e4surea v\u00f5i selliste raamistikudega nagu Apache Maven. Liquibase'i t\u00f6\u00f6p\u00f5him\u00f5te on piisavalt lihtne. Meil on teatud viisil korraldatud projekt, mis koosneb muudatustest v\u00f5i skriptidest, mida tuleb sihtserverile rakendada, ja juhtfailidest, mis m\u00e4\u00e4ratlevad, millises j\u00e4rjestuses ja milliste parameetritega andmed muudatused tuleb installida. <\/p>\n

    Andmebaasi tasemel luuakse spetsiaalne tabel, kus Liquibase hoiab logi muudatuste tegemisest. Iga muudatus omab arvutatud r\u00e4sihashi, mis iga kord v\u00f5rreldakse projekti ja andmebaasi olekuga. T\u00e4nu Liquibase'ile saame me h\u00f5lpsasti rakendada muutusi meie s\u00fcsteemis igas keskkonnas. Autotestid k\u00e4ivitatakse praegu testimis- ja v\u00e4ljalaskekeskkondades, samuti konteinerites (arendajate isiklikud keskkonnad).<\/li>\n<\/ol>\n

    \"\u00dcksuste
    \n
    \nNiisiis, r\u00e4\u00e4gime meie automaatsete testimisse s\u00fcsteemi rakendamise tulemustest. <\/p>\n

      \n
    1. Muidugi usume k\u00f5igepealt, et oleme hakanud arendama kvaliteetsemat tarkvara. Autotestid k\u00e4ivitatakse iga p\u00e4ev ja igal v\u00e4ljalaskmisel tuvastavad nad k\u00fcmneid vigu. Samuti on osa neist vigadest vaid kaudselt seotud funktsionaalsusega, mida me t\u00f5eliselt soovisime muuta. On suuri kahtlusi, et need vead oleksid leitud k\u00e4sitsi testimise k\u00e4igus. <\/li>\n
    2. Meeskonnal on tekkinud kindlus, et konkreetne funktsionaalsus t\u00f6\u00f6tab korrektselt... Esiteks kehtib see meie kriitiliste protsesside kohta. N\u00e4iteks viimase kuue kuu jooksul ei ole meil olnud probleeme soodustuste ja boonuste jaotamisega arve kohta, hoolimata v\u00e4ljalaskmise muudatustest, kuigi varasematel perioodidel tekkisid vead perioodiliselt.<\/li>\n
    3. Olemasolevate testimisringide arvu on \u00f5nnestunud v\u00e4hendada. T\u00e4nu sellele, et autotestid kirjutatakse uue funktsionaalsuse jaoks, j\u00f5uab anal\u00fc\u00fctikutele ja samal ajal testijatele kvaliteetsem kood, kuna see on juba testitud.<\/li>\n
    4. M\u00f5ningaid automatiseeritud testimise arendusi kasutavad ka arendajad. N\u00e4iteks luuakse konteinerites testandmed objektide genereerimise mooduli abil.<\/li>\n
    5. Oluline on, et meil on kujunenud arendajate seas \"vastuv\u00f5tmine\" automatiseeritud testimise s\u00fcsteemile. On arusaam, et see on oluline ja kasulik. Kuid oma kogemuse p\u00f5hjal v\u00f5in \u00f6elda, et see kaugel t\u00f5est t\u00f5si on. Autotestid tuleb kirjutada, neid tuleb toetada ja arendada, tulemusi anal\u00fc\u00fcsida, ja sageli ei ole need ajakulud lihtsalt seda v\u00e4\u00e4rt. Oluliselt lihtsam on minna tootmisse ja seal probleemidega tegeleda. Meie arendajad aga seisavad j\u00e4rjekorras ja paluvad katta nende funktsionaalsus autotestidega.<\/li>\n<\/ol>\n

      Mis edasi<\/h2>\n

      \n\"\u00dcksuste
      \n
      \nR\u00e4\u00e4gime projekti arendamise plaanidest automatiseeritud testimise valdkonnas.<\/p>\n

      Ilma kahtlemata, kuni Sportmasteri lojaalsuss\u00fcsteem on eluj\u00f5uline ja j\u00e4tkuvalt arenev, on v\u00f5imalik peaaegu l\u00f5pmatult arendada ka automaatkatsetusi. Seet\u00f5ttu on p\u00f5hisuund arengus katteala laiendamine.<\/p>\n

      Automaatkatsetuste arvu suurenedes hakkab kindlasti suurenema ka nende t\u00f6\u00f6tamise koguaeg, ja me peame taas tegelema j\u00f5udluse k\u00fcsimusega. T\u00f5en\u00e4oliselt on lahendus suurema arvu paralleelsete voogude suurenemises.<\/p>\n

      Kuid need on ilmsed arenguteed. Kui r\u00e4\u00e4kida millestki v\u00e4hem triviaalset, siis toome v\u00e4lja j\u00e4rgmised:<\/p>\n

        \n
      1. Praegu toimub automaatkatsete juhtimine andmebaasi tasemel, st edukaks t\u00f6\u00f6ks on vajalikud teadmised PL\/SQL-ist. Kui on vajadus, v\u00f5ib s\u00fcsteemi juhtimise (n\u00e4iteks k\u00e4ivituste teostamine v\u00f5i metaandmete loomine) viia v\u00e4lja mingisse administreerimisse, kasutades Jenkinsit v\u00f5i midagi sarnast.<\/li>\n
      2. K\u00f5ik armastavad kvantitatiivseid ja kvalitatiivseid n\u00e4itajaid. Automaatsete testimiste puhul on selline universaalne n\u00e4itaja koodi katteala v\u00f5i Code Coverage. Selle n\u00e4itaja abil saame m\u00e4\u00e4rata, milline protsent meie testitavast s\u00fcsteemist on automaatkatsetega kaetud. Alates versioonist 12.2 pakub Oracle v\u00f5imalusi selle n\u00e4itaja arvutamiseks ja soovitab kasutada standardset paketti DBMS_PLSQL_CODE_COVERAGE.\n

        Meie automaatkatsete s\u00fcsteem on veidi \u00fcle aasta vana ja v\u00f5ib-olla on n\u00fc\u00fcd parim aeg katteala hindamiseks. Minu eelmises projektis (projekt ei olnud Sportmaster) l\u00e4ks just nii. Aasta p\u00e4rast automaatkatsetustega t\u00f6\u00f6tamist seadis juhtkond \u00fclesande hinnata, kui suur protsent koodist on kaetud. \u00dcle 1% katte saavutamisel oleks juhtkond olnud \u00f5nnelik. Me, arendajad, ootasime tulemust umbes 10%. Panime k\u00e4ima koodi katte, m\u00f5\u00f5tsime ja saime 20%. \u00d5nnestunult l\u00e4ksime preemiat k\u00fcsima, kuid kuidas me preemia saamiseks l\u00e4ksime ja kuhu hiljem suundusime, on hoopis teine lugu.<\/li>\n

      3. Automaatkatsetused saavad kontrollida v\u00e4lja antud veebiteenuseid. Oracle v\u00f5imaldab seda teha, ja me ei puutu enam kokku mitmete probleemidega. <\/li>\n
      4. Ja, loomulikult saab meie automatiseeritud testimiss\u00fcsteemi rakendada ka teisel projektil. Meie lahendus on universaalne ja vajab vaid Oracle'i kasutamist. Olen kuulnud, et Spordimeistri teistel projektidel on huvi automatiseeritud testimise vastu ja v\u00f5ib-olla suundume nende juurde.<\/li>\n<\/ol>\n

        <\/p>\n

        J\u00e4reldused<\/h2>\n

        \nKokkuv\u00f5tteks. Spordimeistri lojaalsusprojektis \u00f5nnestus meil rakendada automatiseeritud testimiss\u00fcsteem. Selle aluseks on Stephen Feiersteini utPLSQL lahendus. utPLSQL-i \u00fcmber on paigutatud automaattestide kood ja abimoodulid: k\u00e4ivitamisekoht, andmegeneraatori moodul ja teised. Automaatetestid k\u00e4ivitatakse igap\u00e4evaselt ja, mis k\u00f5ige t\u00e4htsam, need toimivad ja toovad kasu. Oleme veendunud, et oleme hakanud tootma k\u00f5rgema kvaliteediga tarkvara. Samas on saadud lahendus universaalne ning seda saab vabalt rakendada igas projektis, kus on vajalik korraldada automatiseeritud testimist Oracle'i andmebaasis.<\/p>\n

        P.S. See artikkel ei ole eriti konkreetne: siin on palju teksti ja praktiliselt puuduvad tehnilised n\u00e4ited. Kui teema on \u00fcldiselt huvitav, siis oleme valmis seda j\u00e4tkama ja naasma j\u00e4tkuga, kus r\u00e4\u00e4gime, mis on viimase kuue kuu jooksul muutunud ja toome n\u00e4iteid koodist.<\/p>\n

        Palun kirjutage kommentaare, kui on teemasid, millele tulevikus t\u00e4helepanu p\u00f6\u00f6rata, v\u00f5i k\u00fcsimusi, mis vajavad selgitamist.<\/i><\/p>\n

        Ainult registreeritud kasutajad saavad k\u00fcsitluses osaleda. Logige sisse<\/a><\/noindex>, palun.<\/p>\n

        Kas kirjutame sellest edasi?<\/h2>\n