🥇Üksuse testimine andmebaasis — kuidas me seda Sportmasteris teeme, teine osa

Esimene osa — siit.

Kujutage ette olukorda. Teil on ülesanne arendada uut funktsionaalsust. Teil on eelkäijate töö tulemused. Kui eeldada, et teil ei ole mingeid moraalseid kohustusi, siis kuidas te käituksite?

Enamasti unustatakse kõik vanad töötlused ning kõik algab nullist. Keegi ei armasta võõras koodis nokitseda, ja kui aega on, siis miks mitte luua oma süsteemi? See on tüüpiline lähenemine, ja sellel on palju õigustust. Kuid meie projektis tegime me teisiti. Meie automaatse testimise süsteemi aluseks olid eelkäijate unit-testide töötlused utPLSQL-l, seejärel hakkasime töötama mitmes paralleelses suunas.

O mandete taastamine. Taastamise all mõistetakse testide kohandamist olemasolevale lojaalsuse süsteemile ja testide kohandamist utPLSQL-i standarditele.
Probleemi lahendamine arusaamises, millised meetodid ja protsessid on meil kaetud automaatsete testidega. Peame kas hoidma seda teavet meeles või põhineb järeldused otse automaatsete testide koodil. Seetõttu otsustasime koostada katalooge. Iga automaatse testi jaoks andsime ainulaadse mnemokoodi, koostasime kirjelduse ja salvestasime seaded (näiteks millistes tingimustes see peab käivituma või mis peaks juhtuma, kui testi käivitamine ebaõnnestub). Sisuliselt täitsime automaatsete testide metaandmeid ja paigutasime need metaandmed standardsetesse utPLSQL skeemi tabelitesse.
Laienemisstrateegia määratlemine, st funktsionaalsuse valik, mis kuulub automaatsete testide kontrolli. Otsustasime keskenduda kolmele asjale: süsteemi uutele täiustustele, tootmisest tekkinud juhtumitele ja süsteemi põhiprotsessidele. Nii areneme paralleelselt väljaandega, tagades selle kvaliteedi, laiendades samal ajal regressioonitestide mahtu ja tagades süsteemi usaldusväärsuse kriitilistes kohtades. Esimene selline kitsaskoht oli soodustuste ja boonuste jaotamise protsess tšekis.
Muidugi hakkasime arendama uusi automaatseid teste. Ühe esimesena oli meie projekti ülesanne hinnata eelnevalt määratud lojaalsusprogrammi valikute jõudlust. Meie projektis on rida fikseeritud SQL-päringutest, mis valivad kliente teatud tingimuste kohaselt. Näiteks, et saada nimekiri kõigist klientidest, kelle viimane ost on olnud konkreetse linna piires, või nimekiri klientidest, kelle keskmine ostusumma ületab kindlat väärtust. Koostades automaatseid teste, kontrollisime eelnevalt määratud valikute toimivust, fikseerisime etalon-jõudluse parameetrid ja lisaks tegime ka koormusteste.
Töötamine automaatsete testidega peab olema mugav. Kõige sagedamini teostatakse kahte toimingut: automaatsete testide käivitamine ja testandmete genereerimine. Nii on meie süsteemis tekkinud kaks abimoodulit: käivitamise moodul ja andmete genereerimise moodul.
Käivitamismoodul on esitatud ühe universaalse protseduurina, millel on üks sisendtekstiparameeter. Parameetrina saab edastada automaatkontrolli mnemokoodi, paketi nime, testi nime, automaatkontrolli konfiguratsiooni või reserveeritud märksõna. Protseduur valib ja käivitab kõik automaatkontrollid, mis vastavad tingimustele.
Andme genereerimise moodul on esitatud paketina, kus iga testitava süsteemi objekti (andmebaasi tabeli) jaoks on loodud spetsiaalne protseduur, mis viib sinna andmed. Antud protseduur täidab maksimaalselt vaikeväärtused, mis tagab objektide loomise sõna otseses mõttes sõrme snapiga. Ja kasutamise mugavuse huvides on loodud loodud andmete mallid. Näiteks, luua teatud vanuses klient testtelefoni ja sooritatud ostuga.
Automaatsed testid peavad käivituma ja töötama teie süsteemi jaoks vastuvõetava aja jooksul. Seetõttu korraldati igapäevane öine käivitamine, mille põhjal koostati aruanded ja saadeti kogu arendustiimile ettevõtte e-posti teel. Pärast vanade automaatkatsete taastamist ja uute loomist jäi koguaeg 30 minutisse. Taoline tootlikkus rahuldas kõiki, kuna käivitamine toimus väljaspool tööaega.
Kuid töö kiirusest optimeerimine oli vajalik. Lojaalsussüsteemi värskendamine produktsioonis toimub öösel. Ühe versiooni raames tuli öösel teha kiireid muudatusi. Poolteise tunni ootamine automaatkatsete tulemuste pärast kell kolm öösel ei teinud vastutavat isikut õnnelikuks (sooja tervituse Alexey Vasyukovile!), ning järgmisel hommikul kuuldavasti öeldi meie süsteemi kohta palju sooje sõnu. Kuid lõpuks kehtestati 5-minutiline norm töö tegemiseks.
Riigi efektiivsuse suurendamiseks kasutasime kahte meetodit: autotestimise protsessid käivituvad kolmes paralleelses voos, mis sobib meie lojaalsusüsteemi arhitektuuri tõttu suurepäraselt. Samuti loobusime lähenemisest, kus autotest ei genereeri endale testandmeid, vaid püüab leida süsteemist midagi sobivat. Pärast muudatusi vähenes kogu tööaeg 3-4 minutini.
Autotestide projekt tuleb osata seadistada erinevates keskkondades. Teel oli katse kirjutada oma skripte, kuid sai selgeks, et käsitsi automatiseeritud seadistus on täielik õudus, seega pöördusime tööstuslike lahenduste poole. Arvestades, et projektis on palju koodi (peamiselt salvestame autotestide koodi) ja väga vähe andmeid (peamised andmed on autotestide metaandmed), osutus Liquibase'i rakendamine projektis väga lihtsaks.
See on andmebaasist sõltumatu avatud lähtekoodiga teek, mis on mõeldud andmebaasiskeemide muutuste jälgimiseks, haldamiseks ja rakendamiseks. Seda juhtimise võimalust pakuvad käsurea tööriistad või Apache Maven'i tüüpi raamistikud. Liquibase'i tööpõhimõte on piisavalt lihtne. Meil on korralikult struktureeritud projekt, mis koosneb muudatustest või skriptidest, mida tuleb sihtserverile rakendada, ning juhtfailidest, mis määravad, millises järjekorras ja milliste parameetritega neid muudatusi paigaldada.
Andmebaasi tasandil luuakse spetsiaalne tabel, milles Liquibase salvestab rakenduste logi. Iga muudatusel on arvutatud räsisumma, mida võrreldakse igal korral projekti ja andmebaasi olekuga. Liquibase'i kaudu saame hõlpsasti rakendada muudatusi meie süsteemis mis tahes keskkonda. Autotestid käivitatakse praegu test- ja väljalaskekeskkondades, samuti konteinerites (arendajate isiklikes keskkondades).

Nii et räägime meie üksustestide süsteemi rakendamise tulemustest.

Muidugi usume eelkõige, et oleme hakanud arendama kvaliteetsemat tarkvara. Autotestid käivitatakse iga päev ja iga versiooni puhul tuvastavad need kümneid vigu. Samas on osa neist vigadest vaid kaudselt seotud funktsionaalsusega, mida me tõeliselt soovime muuta. On suuri kahtlusi, et need vead oleks leitud käsitsi testimisega.
Meeskonnal on tekkinud kindlustunne, et konkreetne funktsionaalsus töötab õigesti... Eelkõige puudutab see meie kriitilisi protsesse. Näiteks ei ole viimase kuue kuu jooksul olnud meil probleeme soodustuste ja boonuste jaotamisega tšekis, hoolimata igast versioonimuudatusest, kuigi varasematel perioodidel esines mõningaid proportsionaalseid vigu.
Oleme suutnud vähendada testimise iteratsioonide arvu. Tänu sellele, et autotestid kirjutatakse uue funktsionaalsuse jaoks, jõuab analüütikutele ja samal ajal testijatele kõrgema kvaliteediga kood, kuna see on juba kontrollitud.
Osad automatiseeritud testimise arendused kasutatakse arendajate poolt. Näiteks genereeritakse konteinerites testandmed objektide genereerimise mooduli abil.
Oluline on märkida, et meie arendajad on aktsepteerinud automatiseeritud testimise süsteemi. On arusaam, et see on oluline ja kasulik. Aga oma kogemuse põhjal võin öelda, et see ei ole sugugi nii. Automatiseeritud testid tuleb kirjutada, neid tuleb hooldada ja arendada, tulemusi analüüsida ning sageli ei õigusta need ajakulu. Oluliselt lihtsam on minna tootmisliini ja seal probleemidega tegeleda. Meie arendajad seisavad järjekorras ja paluvad katte saada automatiseeritud testidega.

Mis edasi

Rääkigem automatiseeritud testimise projekti arendamise plaanidest.

Ilmselgelt, seni kuni Sportmasteri lojaalsussüsteem on elujõuline ja arenev, saab ka automatiseeritud teste peaaegu lõputult arendada. Seetõttu on arendamise peamine suund katvuse laiendamine.

Automatiseeritud testide arvu suurenedes kasvab ka nende koguaeg järk-järgult ning peame taas pöörduma efektiivsuse küsimuse poole. Tõenäoliselt on lahendus paralleelsete töövoogude arvu suurendamine.

Kuid need on ilmset arenguteed. Kui rääkida millestki vähem triviaalset, siis toome välja järgmised punktid:

Praegu toimub automatiseeritud testimise haldamine andmebaasi tasemel, see tähendab, et edukaks tööks on vajalikud teadmised PL/SQL-ist. Vajadusel saab süsteemi haldamise (nt käivitamiste teostamine või metaandmete loomine) usaldada mõnele administraatori tööriistale, kasutades Jenkinsit või midagi sarnast.
Kõik armastavad kvantitatiivseid ja kvalitatiivseid näitajaid. Automaatsete testimiste puhul on selliseks universaalseks näitajaks koodikatte näitaja ehk Code Coverage. Selle abil saame määrata, kui suur osa testitava süsteemi koodist on katte all automaatsete testide poolt. Alates versioonist 12.2 pakub Oracle võimalusi selle meetri arvutamiseks ja soovitab kasutada standardpaketti DBMS_PLSQL_CODE_COVERAGE.
Meie automatiseeritud testimissüsteem on nüüdseks rohkem kui aasta vana ja võib-olla on just nüüd parim aeg katvuse hindamiseks. Minu eelnevas projektis (mis ei olnud Sportmaster) oli see just nii. Aasta pärast automatiseeritud testide läbiviimist andis juhtkond ülesande hinnata, kui suur osa koodist meil kaetud on. Kui katvus oleks olnud üle 1%, oleks juhtkond olnud rahul. Me, arendajad, ootasime umbes 10% katvust. Lõime sisse koodikatvuse, mõõtsime ja saime 20%. Rõõmustasid suundusime preemia järele, aga kuidas me selle nimel käisime ja kuhu edasi, on hoopis teine lugu.
Automaatkatsetused saavad kontrollida välja pandud veebiteenuseid. Oracle võimaldab seda täiesti hästi, ja me ei kohtu enam terve rida probleeme.
Ja loomulikult saab meie automatiseeritud testimissüsteemi 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õib-olla suundume neile.

Järeldused

Kokkuvõtteks. Sportmasteri projektis suutsime rakendada automaatset testimissüsteemi lojaalsusprogrammi. Selle aluseks on Stephen Feiersteini lahendus utPLSQL. utPLSQL-i ümber on autote testimise kood ja abi moodulid: käivitusmoodul, andmete genereerimise moodul ja teised. Autotestimine toimub iga päev ja, mis kõige tähtsam, see töötab 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.S. Käesolev artikkel ei ole väga spetsiifiline: siin on palju teksti ja enamasti puuduvad tehnilised näited. Kui teema on globaalselt huvitav, siis oleme valmis seda jätkama ja tagasi tulema jätkuga, kus räägime, mis on viimase kuue kuu jooksul muutunud ja toome näiteid koodist.

Kirjutage kommentaare, kui on kohti, millele tulevikus tähelepanu pöörata või küsimusi, mis vajavad avamist.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.