{"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":"\u00dchiku testimine andmebaasis \u2014 kuidas me seda Sportmasteris teeme, teine osa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

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

Kujutage ette olukorda. Teil on \u00fclesanne arendada uut funktsionaalsust. Teil on eelk\u00e4ijate t\u00f6\u00f6 tulemused. Kui eeldada, et teil ei ole mingeid moraalseid kohustusi, siis kuidas te k\u00e4ituksite?<\/p>\n

Enamasti unustatakse k\u00f5ik vanad t\u00f6\u00f6tlused ning k\u00f5ik algab nullist. Keegi ei armasta v\u00f5\u00f5ras koodis nokitseda, ja kui aega on, siis miks mitte luua oma s\u00fcsteemi? See on t\u00fc\u00fcpiline l\u00e4henemine, ja sellel on palju \u00f5igustust. Kuid meie projektis tegime me teisiti. Meie automaatse testimise s\u00fcsteemi aluseks olid eelk\u00e4ijate unit-testide t\u00f6\u00f6tlused utPLSQL-l, seej\u00e4rel hakkasime t\u00f6\u00f6tama mitmes paralleelses suunas.
\n<\/a><\/noindex><\/p>\n

    \n
  1. O mandete taastamine.<\/b> Taastamise all m\u00f5istetakse testide kohandamist olemasolevale lojaalsuse s\u00fcsteemile ja testide kohandamist utPLSQL-i standarditele. <\/li>\n
  2. Probleemi lahendamine arusaamises, millised meetodid ja protsessid on meil kaetud automaatsete testidega. <\/b>Peame kas hoidma seda teavet meeles v\u00f5i p\u00f5hineb j\u00e4reldused otse automaatsete testide koodil. Seet\u00f5ttu otsustasime koostada katalooge. Iga automaatse testi jaoks andsime ainulaadse mnemokoodi, koostasime kirjelduse ja salvestasime seaded (n\u00e4iteks millistes tingimustes see peab k\u00e4ivituma v\u00f5i mis peaks juhtuma, kui testi k\u00e4ivitamine eba\u00f5nnestub). Sisuliselt t\u00e4itsime automaatsete testide metaandmeid ja paigutasime need metaandmed standardsetesse utPLSQL skeemi tabelitesse.<\/li>\n
  3. Laienemisstrateegia m\u00e4\u00e4ratlemine, st funktsionaalsuse valik, mis kuulub automaatsete testide kontrolli.<\/b> Otsustasime keskenduda kolmele asjale: s\u00fcsteemi uutele t\u00e4iustustele, tootmisest tekkinud juhtumitele ja s\u00fcsteemi p\u00f5hiprotsessidele. Nii areneme paralleelselt v\u00e4ljaandega, tagades selle kvaliteedi, laiendades samal ajal regressioonitestide mahtu ja tagades s\u00fcsteemi usaldusv\u00e4\u00e4rsuse kriitilistes kohtades. Esimene selline kitsaskoht oli soodustuste ja boonuste jaotamise protsess t\u0161ekis.<\/li>\n
  4. Muidugi hakkasime arendama uusi automaatseid teste. <\/b>\u00dche esimesena oli meie projekti \u00fclesanne hinnata eelnevalt m\u00e4\u00e4ratud lojaalsusprogrammi valikute j\u00f5udlust. Meie projektis on rida fikseeritud SQL-p\u00e4ringutest, mis valivad kliente teatud tingimuste kohaselt. N\u00e4iteks, et saada nimekiri k\u00f5igist klientidest, kelle viimane ost on olnud konkreetse linna piires, v\u00f5i nimekiri klientidest, kelle keskmine ostusumma \u00fcletab kindlat v\u00e4\u00e4rtust. Koostades automaatseid teste, kontrollisime eelnevalt m\u00e4\u00e4ratud valikute toimivust, fikseerisime etalon-j\u00f5udluse parameetrid ja lisaks tegime ka koormusteste.<\/li>\n
  5. T\u00f6\u00f6tamine automaatsete testidega peab olema mugav<\/b>. K\u00f5ige sagedamini teostatakse kahte toimingut: automaatsete testide k\u00e4ivitamine ja testandmete genereerimine. Nii on meie s\u00fcsteemis tekkinud kaks abimoodulit: k\u00e4ivitamise moodul ja andmete genereerimise moodul.\n

    K\u00e4ivitamismoodul on esitatud \u00fche universaalse protseduurina, millel on \u00fcks sisendtekstiparameeter. Parameetrina saab edastada automaatkontrolli mnemokoodi, paketi nime, testi nime, automaatkontrolli konfiguratsiooni v\u00f5i reserveeritud m\u00e4rks\u00f5na. Protseduur valib ja k\u00e4ivitab k\u00f5ik automaatkontrollid, mis vastavad tingimustele.<\/p>\n

    Andme genereerimise moodul on esitatud paketina, kus iga testitava s\u00fcsteemi objekti (andmebaasi tabeli) jaoks on loodud spetsiaalne protseduur, mis viib sinna andmed. Antud protseduur t\u00e4idab maksimaalselt vaikev\u00e4\u00e4rtused, mis tagab objektide loomise s\u00f5na otseses m\u00f5ttes s\u00f5rme snapiga. Ja kasutamise mugavuse huvides on loodud loodud andmete mallid. N\u00e4iteks, luua teatud vanuses klient testtelefoni ja sooritatud ostuga.<\/li>\n

  6. Automaatsed testid 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 p\u00f5hjal koostati aruanded ja saadeti kogu arendustiimile ettev\u00f5tte e-posti teel. P\u00e4rast vanade automaatkatsete taastamist ja uute loomist j\u00e4i koguaeg 30 minutisse. Taoline tootlikkus rahuldas k\u00f5iki, kuna k\u00e4ivitamine toimus v\u00e4ljaspool t\u00f6\u00f6aega.\n

    Kuid t\u00f6\u00f6 kiirusest optimeerimine oli vajalik. Lojaalsuss\u00fcsteemi v\u00e4rskendamine produktsioonis toimub \u00f6\u00f6sel. \u00dche versiooni raames tuli \u00f6\u00f6sel teha kiireid muudatusi. Poolteise tunni ootamine automaatkatsete tulemuste p\u00e4rast kell kolm \u00f6\u00f6sel ei teinud vastutavat isikut \u00f5nnelikuks (sooja tervituse Alexey Vasyukovile!), ning j\u00e4rgmisel hommikul kuuldavasti \u00f6eldi meie s\u00fcsteemi kohta palju sooje s\u00f5nu. Kuid l\u00f5puks kehtestati 5-minutiline norm t\u00f6\u00f6 tegemiseks.<\/p>\n

    Riigi efektiivsuse suurendamiseks kasutasime kahte meetodit: autotestimise protsessid k\u00e4ivituvad kolmes paralleelses voos, mis sobib meie lojaalsus\u00fcsteemi arhitektuuri t\u00f5ttu suurep\u00e4raselt. Samuti loobusime l\u00e4henemisest, kus autotest ei genereeri endale testandmeid, vaid p\u00fc\u00fcab leida s\u00fcsteemist midagi sobivat. P\u00e4rast muudatusi v\u00e4henes kogu t\u00f6\u00f6aeg 3-4 minutini.<\/li>\n

  7. Autotestide projekt tuleb osata seadistada erinevates keskkondades.<\/b> Teel oli katse kirjutada oma skripte, kuid sai selgeks, et k\u00e4sitsi automatiseeritud seadistus on t\u00e4ielik \u00f5udus, seega p\u00f6\u00f6rdusime t\u00f6\u00f6stuslike lahenduste poole. Arvestades, et projektis on palju koodi (peamiselt salvestame autotestide koodi) ja v\u00e4ga v\u00e4he andmeid (peamised andmed on autotestide metaandmed), osutus Liquibase'i rakendamine projektis v\u00e4ga lihtsaks.\n

    See on andmebaasist s\u00f5ltumatu avatud l\u00e4htekoodiga teek, mis on m\u00f5eldud andmebaasiskeemide muutuste j\u00e4lgimiseks, haldamiseks ja rakendamiseks. Seda juhtimise v\u00f5imalust pakuvad k\u00e4surea t\u00f6\u00f6riistad v\u00f5i Apache Maven'i t\u00fc\u00fcpi raamistikud. Liquibase'i t\u00f6\u00f6p\u00f5him\u00f5te on piisavalt lihtne. Meil on korralikult struktureeritud projekt, mis koosneb muudatustest v\u00f5i skriptidest, mida tuleb sihtserverile rakendada, ning juhtfailidest, mis m\u00e4\u00e4ravad, millises j\u00e4rjekorras ja milliste parameetritega neid muudatusi paigaldada. <\/p>\n

    Andmebaasi tasandil luuakse spetsiaalne tabel, milles Liquibase salvestab rakenduste logi. Iga muudatusel on arvutatud r\u00e4sisumma, mida v\u00f5rreldakse igal korral projekti ja andmebaasi olekuga. Liquibase'i kaudu saame h\u00f5lpsasti rakendada muudatusi meie s\u00fcsteemis mis tahes keskkonda. Autotestid k\u00e4ivitatakse praegu test- ja v\u00e4ljalaskekeskkondades, samuti konteinerites (arendajate isiklikes keskkondades).<\/li>\n<\/ol>\n

    \"\u00dchiku
    \n
    \nNii et r\u00e4\u00e4gime meie \u00fcksustestide s\u00fcsteemi rakendamise tulemustest. <\/p>\n

      \n
    1. Muidugi usume eelk\u00f5ige, et oleme hakanud arendama kvaliteetsemat tarkvara. Autotestid k\u00e4ivitatakse iga p\u00e4ev ja iga versiooni puhul tuvastavad need k\u00fcmneid vigu. Samas on osa neist vigadest vaid kaudselt seotud funktsionaalsusega, mida me t\u00f5eliselt soovime muuta. On suuri kahtlusi, et need vead oleks leitud k\u00e4sitsi testimisega. <\/li>\n
    2. Meeskonnal on tekkinud kindlustunne, et konkreetne funktsionaalsus t\u00f6\u00f6tab \u00f5igesti... Eelk\u00f5ige puudutab see meie kriitilisi protsesse. N\u00e4iteks ei ole viimase kuue kuu jooksul olnud meil probleeme soodustuste ja boonuste jaotamisega t\u0161ekis, hoolimata igast versioonimuudatusest, kuigi varasematel perioodidel esines m\u00f5ningaid proportsionaalseid vigu.<\/li>\n
    3. Oleme suutnud v\u00e4hendada testimise iteratsioonide arvu. T\u00e4nu sellele, et autotestid kirjutatakse uue funktsionaalsuse jaoks, j\u00f5uab anal\u00fc\u00fctikutele ja samal ajal testijatele k\u00f5rgema kvaliteediga kood, kuna see on juba kontrollitud.<\/li>\n
    4. Osad automatiseeritud testimise arendused kasutatakse arendajate poolt. N\u00e4iteks genereeritakse konteinerites testandmed objektide genereerimise mooduli abil.<\/li>\n
    5. Oluline on m\u00e4rkida, et meie arendajad on aktsepteerinud automatiseeritud testimise s\u00fcsteemi. On arusaam, et see on oluline ja kasulik. Aga oma kogemuse p\u00f5hjal v\u00f5in \u00f6elda, et see ei ole sugugi nii. Automatiseeritud testid tuleb kirjutada, neid tuleb hooldada ja arendada, tulemusi anal\u00fc\u00fcsida ning sageli ei \u00f5igusta need ajakulu. Oluliselt lihtsam on minna tootmisliini ja seal probleemidega tegeleda. Meie arendajad seisavad j\u00e4rjekorras ja paluvad katte saada automatiseeritud testidega.<\/li>\n<\/ol>\n

      Mis edasi<\/h2>\n

      \n\"\u00dchiku
      \n
      \nR\u00e4\u00e4kigem automatiseeritud testimise projekti arendamise plaanidest.<\/p>\n

      Ilmselgelt, seni kuni Sportmasteri lojaalsuss\u00fcsteem on eluj\u00f5uline ja arenev, saab ka automatiseeritud teste peaaegu l\u00f5putult arendada. Seet\u00f5ttu on arendamise peamine suund katvuse laiendamine.<\/p>\n

      Automatiseeritud testide arvu suurenedes kasvab ka nende koguaeg j\u00e4rk-j\u00e4rgult ning peame taas p\u00f6\u00f6rduma efektiivsuse k\u00fcsimuse poole. T\u00f5en\u00e4oliselt on lahendus paralleelsete t\u00f6\u00f6voogude arvu suurendamine.<\/p>\n

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

        \n
      1. Praegu toimub automatiseeritud testimise haldamine andmebaasi tasemel, see t\u00e4hendab, et edukaks t\u00f6\u00f6ks on vajalikud teadmised PL\/SQL-ist. Vajadusel saab s\u00fcsteemi haldamise (nt k\u00e4ivitamiste teostamine v\u00f5i metaandmete loomine) usaldada m\u00f5nele administraatori t\u00f6\u00f6riistale, kasutades Jenkinsit v\u00f5i midagi sarnast.<\/li>\n
      2. K\u00f5ik armastavad kvantitatiivseid ja kvalitatiivseid n\u00e4itajaid. Automaatsete testimiste puhul on selliseks universaalseks n\u00e4itajaks koodikatte n\u00e4itaja ehk Code Coverage. Selle abil saame m\u00e4\u00e4rata, kui suur osa testitava s\u00fcsteemi koodist on katte all automaatsete testide poolt. Alates versioonist 12.2 pakub Oracle v\u00f5imalusi selle meetri arvutamiseks ja soovitab kasutada standardpaketti DBMS_PLSQL_CODE_COVERAGE.\n

        Meie automatiseeritud testimiss\u00fcsteem on n\u00fc\u00fcdseks rohkem kui aasta vana ja v\u00f5ib-olla on just n\u00fc\u00fcd parim aeg katvuse hindamiseks. Minu eelnevas projektis (mis ei olnud Sportmaster) oli see just nii. Aasta p\u00e4rast automatiseeritud testide l\u00e4biviimist andis juhtkond \u00fclesande hinnata, kui suur osa koodist meil kaetud on. Kui katvus oleks olnud \u00fcle 1%, oleks juhtkond olnud rahul. Me, arendajad, ootasime umbes 10% katvust. L\u00f5ime sisse koodikatvuse, m\u00f5\u00f5tsime ja saime 20%. R\u00f5\u00f5mustasid suundusime preemia j\u00e4rele, aga kuidas me selle nimel k\u00e4isime ja kuhu edasi, on hoopis teine lugu.<\/li>\n

      3. Automaatkatsetused saavad kontrollida v\u00e4lja pandud veebiteenuseid. Oracle v\u00f5imaldab seda t\u00e4iesti h\u00e4sti, ja me ei kohtu enam terve rida probleeme. <\/li>\n
      4. Ja loomulikult saab meie automatiseeritud testimiss\u00fcsteemi kasutada teisel projektil. Meie saavutus on universaalne ja vajab lihtsalt Oracle'i kasutamist. Olen kuulnud, et teistes Sportmasteri projektides on huvi automatiseeritud testimise vastu ja v\u00f5ib-olla suundume neile.<\/li>\n<\/ol>\n

        <\/p>\n

        J\u00e4reldused<\/h2>\n

        \nKokkuv\u00f5tteks. Sportmasteri projektis suutsime rakendada automaatset testimiss\u00fcsteemi lojaalsusprogrammi. Selle aluseks on Stephen Feiersteini lahendus utPLSQL. utPLSQL-i \u00fcmber on autote testimise kood ja abi moodulid: k\u00e4ivitusmoodul, andmete genereerimise moodul ja teised. Autotestimine toimub iga p\u00e4ev ja, mis k\u00f5ige t\u00e4htsam, see t\u00f6\u00f6tab ning toob kasu. Me oleme kindlad, et oleme hakanud tootma kvaliteetsemat tarkvara. Samas on saadud lahendus universaalne ja seda saab vabalt kasutada igasugustes projektides, kus on vajalik korraldada automatiseeritud testimine Oracle'i andmebaasis.<\/p>\n

        P.S. K\u00e4esolev artikkel ei ole v\u00e4ga spetsiifiline: siin on palju teksti ja enamasti puuduvad tehnilised n\u00e4ited. Kui teema on globaalselt huvitav, siis oleme valmis seda j\u00e4tkama ja tagasi tulema j\u00e4tkuga, kus r\u00e4\u00e4gime, mis on viimase kuue kuu jooksul muutunud ja toome n\u00e4iteid koodist.<\/p>\n

        Kirjutage kommentaare, kui on kohti, millele tulevikus t\u00e4helepanu p\u00f6\u00f6rata v\u00f5i k\u00fcsimusi, mis vajavad avamist.<\/i><\/p>\n

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

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