🥇Üksuse testid andmebaasis — kuidas me seda Spordimeisters teeme, teine osa

Esimene osa — siin.

Kujutage ette olukorda. Te peate arendama uut funktsionaalsust. Teil on olemas eelmiste töötajate materjalid. Kui jätta kõrvale moraalsed kohustused, kuidas te siis käituksite?

Tavaliselt unustatakse kõik vanad arendused ja kõik hakkab nullist. Keegi ei armasta teiste koodiga vaeva näha, ja kui aega on, siis miks mitte luua oma süsteem? See on tüüpiline lähenemine, ja see on suuresti õige. Kuid meie projektis tegime teistmoodi. Tulevase automaatsete testide süsteemi aluseks saime meie eelkäijate utPLSQL unit-testide arendused ning seejärel asusime töötama mitmes paralleelses suunas.

Vana unit-testide taastamine. Taastamine tähendab testide kohandamist olemasoleva lojaalsussüsteemi seisuga ja testide kohandamist utPLSQL standarditega.
Probleemi lahendamine, et mõista, millised meetodid ja protsessid on meie automaatsete testidega kaetud. Kas tuleb see teave meeles hoida või teha järeldusi otse automaatsete testide koodist. Seetõttu otsustasime koostada katalooge. Igale automaatsetele testile andsime unikaalse mnemokoodi, koostasime kirjelduse ja fikseerisime seaded (näiteks, millistes tingimustes see peaks käivituma või mis peaks juhtuma, kui testi käivitamine ebaõnnestus). Sisuliselt täitsime automaatsete testide meetainformatsiooni ja paigutasime need standardsetesse utPLSQL skeemi tabelitesse.
Laiendamisstrateegia määratlemine, st funktsionaalsuse valimine, mida tuleb automaatsete testidega kontrollida. Otsustasime keskenduda kolmele asjale: süsteemi uued täiustused, tootmisprobleemid ja süsteemi põhiprotsessid. Nii arendame end välja paralleelselt väljaande kvaliteedi parandamisega, samal ajal laiendades regressiooni ulatust ja tagades süsteemi usaldusväärsuse kriitilistes kohtades. Esimene kitsaskoht oli allahindluste ja boonuste jaotamise protsess.
Loomulikult hakkasime töötama uute automaatsete testide välja töötamisega. Ühe esimestest vabastamisülesannetest oli jõudluse hindamine eelseadistatud lojaalsuse valimite osas. Meie projektis on plokk rangelt fikseeritud SQL-päringutest, mis valivad kliente tingimuste alusel. Näiteks, saada kõigi klientide nimekiri, kelle viimane ost tehti konkreetses linnas, või nimekiri klientidest, kelle keskmine ostusumma ületab kindlat väärtust. Kirjutades automaatkatsetusi, kontrollisime eelseadistatud valimeid ja fikseerisime standardseid jõudluse parameetreid, lisaks saime me koormustestimise.
Automaatkatsetustega töötamine peab olema mugav. Kõige sagedamini tehakse kahte tegevust: automaatkatsete käivitamine ja testandmete loomine. Nii ilmus meie süsteemi kaks abimoodulit: käivitamismoodul ja andmete genereerimise moodul.
Käivitamismoodul on esitatud ühe universaalse protseduurina, millel on üks sissekande tekstiparameeter. Parameetrina saab edastada automaatkatse mnemo-koodi, pakettnime, testi nime, automaatkatse seade või reserveeritud võtmesõna. Protseduur valib ja käivitab kõik automaatkatsed, mis vastavad tingimustele.
Andmete genereerimise moodul on esitatud paketina, kus iga katsetatava süsteemi objekti (tabel andmebaasis) jaoks on loodud spetsiaalne protseduur, mis sisestab sinna andmed. Selles protseduuris on maksimaalselt täidetud vaikimisi väärtused, mis tagavad objektide loomise sõrmenipsuga. Ja mugavuse huvides on loodud loodud andmete mallid. Näiteks luua teatud vanuses klient koos testtelefoniga ja sooritatud ostuga.
Automaatkatsetused peavad käivituma ja töötama teie süsteemi jaoks vastuvõetava aja jooksul. Seetõttu korraldati igapäevane öine käivitamine, mille tulemuste põhjal koostatakse aruanne ja saadetakse kogu arendusmeeskonnale ettevõtte e-posti kaudu. Pärast vanade automaatkatsete taastamist ja uute loomist oli kogu tööaeg 30 minutit. Selline jõudlus rahuldas kõiki, kuna käivitamine toimus töövälisel ajal.
Kuid süsteemi töö kiirusest tuli siiski töötada. Loodud lojaalsussüsteemi uuendamine toimub öösel. Ühe versiooni raames tuli öösel kiirkorras muudatusi sisse viia. Kella kolme öösel poole tunni ooteaeg automaatkatsete tulemusi ei teinud versiooni eest vastutavat inimest õnnelikuks (soojad tervitused Aleksei Vasyukovile!), ja järgmisel hommikul öeldi meie süsteemi suunal palju sooje sõnu. Kuid tulemuseks oli 5-minutilise standardi kehtestamine töö jaoks.
Tõhususe suurendamiseks kasutasime kahte meetodit: automaatkatseid hakati käivitama kolmes paralleelses voos, õnneks on see meie lojaalsussüsteemi arhitektuuri tõttu väga mugav. Ja loobusime lähenemisest, kus automatiseeritud test ei loo ise testandmeid, vaid püüab leida süsteemist sobivaid. Pärast muudatuste tegemist vähenes kogu töö aeg 3–4 minutini.
Automaatkatsete projekt peab olema võimalik erinevates keskkondades kasutusele võtta. Alguses oli katseid kirjutada oma .bat faile, kuid selgus, et käsitsi automatiseeritud seadistus on täielik õudus ja pöördusime tööstuslike lahenduste poole. Kuna projektis on väga palju otse koodi (peamiselt hoiame automaatkatsete koodi) ja väga vähe andmeid (peamised andmed on metainformatsioon automaatkatsete kohta), osutus Liquibase'i juurutamine projektis äärmiselt lihtsaks.
See on andmebaasist sõltumatu avatud lähtekoodiga teek, mis jälgib, haldab ja rakendab andmebaasiskeemi muudatusi. Haldatakse käsurea või selliste raamistikudega nagu Apache Maven. Liquibase'i tööpõhimõte on piisavalt lihtne. Meil on teatud viisil korraldatud projekt, mis koosneb muudatustest või skriptidest, mida tuleb sihtserverile rakendada, ja juhtfailidest, mis määratlevad, millises järjestuses ja milliste parameetritega andmed muudatused tuleb installida.
Andmebaasi tasemel luuakse spetsiaalne tabel, kus Liquibase hoiab logi muudatuste tegemisest. Iga muudatus omab arvutatud räsihashi, mis iga kord võrreldakse projekti ja andmebaasi olekuga. Tänu Liquibase'ile saame me hõlpsasti rakendada muutusi meie süsteemis igas keskkonnas. Autotestid käivitatakse praegu testimis- ja väljalaskekeskkondades, samuti konteinerites (arendajate isiklikud keskkonnad).

Niisiis, räägime meie automaatsete testimisse süsteemi rakendamise tulemustest.

Muidugi usume kõigepealt, et oleme hakanud arendama kvaliteetsemat tarkvara. Autotestid käivitatakse iga päev ja igal väljalaskmisel tuvastavad nad kümneid vigu. Samuti on osa neist vigadest vaid kaudselt seotud funktsionaalsusega, mida me tõeliselt soovisime muuta. On suuri kahtlusi, et need vead oleksid leitud käsitsi testimise käigus.
Meeskonnal on tekkinud kindlus, et konkreetne funktsionaalsus töötab korrektselt... Esiteks kehtib see meie kriitiliste protsesside kohta. Näiteks viimase kuue kuu jooksul ei ole meil olnud probleeme soodustuste ja boonuste jaotamisega arve kohta, hoolimata väljalaskmise muudatustest, kuigi varasematel perioodidel tekkisid vead perioodiliselt.
Olemasolevate testimisringide arvu on õnnestunud vähendada. Tänu sellele, et autotestid kirjutatakse uue funktsionaalsuse jaoks, jõuab analüütikutele ja samal ajal testijatele kvaliteetsem kood, kuna see on juba testitud.
Mõningaid automatiseeritud testimise arendusi kasutavad ka arendajad. Näiteks luuakse konteinerites testandmed objektide genereerimise mooduli abil.
Oluline on, et meil on kujunenud arendajate seas "vastuvõtmine" automatiseeritud testimise süsteemile. On arusaam, et see on oluline ja kasulik. Kuid oma kogemuse põhjal võin öelda, et see kaugel tõest tõsi on. Autotestid tuleb kirjutada, neid tuleb toetada ja arendada, tulemusi analüüsida, ja sageli ei ole need ajakulud lihtsalt seda väärt. Oluliselt lihtsam on minna tootmisse ja seal probleemidega tegeleda. Meie arendajad aga seisavad järjekorras ja paluvad katta nende funktsionaalsus autotestidega.

Mis edasi

Räägime projekti arendamise plaanidest automatiseeritud testimise valdkonnas.

Ilma kahtlemata, kuni Sportmasteri lojaalsussüsteem on elujõuline ja jätkuvalt arenev, on võimalik peaaegu lõpmatult arendada ka automaatkatsetusi. Seetõttu on põhisuund arengus katteala laiendamine.

Automaatkatsetuste arvu suurenedes hakkab kindlasti suurenema ka nende töötamise koguaeg, ja me peame taas tegelema jõudluse küsimusega. Tõenäoliselt on lahendus suurema arvu paralleelsete voogude suurenemises.

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

Praegu toimub automaatkatsete juhtimine andmebaasi tasemel, st edukaks tööks on vajalikud teadmised PL/SQL-ist. Kui on vajadus, võib süsteemi juhtimise (näiteks käivituste teostamine või metaandmete loomine) viia välja mingisse administreerimisse, kasutades Jenkinsit või midagi sarnast.
Kõik armastavad kvantitatiivseid ja kvalitatiivseid näitajaid. Automaatsete testimiste puhul on selline universaalne näitaja koodi katteala või Code Coverage. Selle näitaja abil saame määrata, milline protsent meie testitavast süsteemist on automaatkatsetega kaetud. Alates versioonist 12.2 pakub Oracle võimalusi selle näitaja arvutamiseks ja soovitab kasutada standardset paketti DBMS_PLSQL_CODE_COVERAGE.
Meie automaatkatsete süsteem on veidi üle aasta vana ja võib-olla on nüüd parim aeg katteala hindamiseks. Minu eelmises projektis (projekt ei olnud Sportmaster) läks just nii. Aasta pärast automaatkatsetustega töötamist seadis juhtkond ülesande hinnata, kui suur protsent koodist on kaetud. Üle 1% katte saavutamisel oleks juhtkond olnud õnnelik. Me, arendajad, ootasime tulemust umbes 10%. Panime käima koodi katte, mõõtsime ja saime 20%. Õnnestunult läksime preemiat küsima, kuid kuidas me preemia saamiseks läksime ja kuhu hiljem suundusime, on hoopis teine lugu.
Automaatkatsetused saavad kontrollida välja antud veebiteenuseid. Oracle võimaldab seda teha, ja me ei puutu enam kokku mitmete probleemidega.
Ja, loomulikult saab meie automatiseeritud testimissüsteemi 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õib-olla suundume nende juurde.

Järeldused

Kokkuvõtteks. Spordimeistri lojaalsusprojektis õnnestus meil rakendada automatiseeritud testimissüsteem. Selle aluseks on Stephen Feiersteini utPLSQL lahendus. utPLSQL-i ümber on paigutatud automaattestide kood ja abimoodulid: käivitamisekoht, andmegeneraatori moodul ja teised. Automaatetestid käivitatakse igapäevaselt ja, mis kõige tähtsam, need toimivad ja toovad kasu. Oleme veendunud, et oleme hakanud tootma kõrgema kvaliteediga tarkvara. Samas on saadud lahendus universaalne ning seda saab vabalt rakendada igas projektis, kus on vajalik korraldada automatiseeritud testimist Oracle'i andmebaasis.

P.S. See artikkel ei ole eriti konkreetne: siin on palju teksti ja praktiliselt puuduvad tehnilised näited. Kui teema on üldiselt huvitav, siis oleme valmis seda jätkama ja naasma jätkuga, kus räägime, mis on viimase kuue kuu jooksul muutunud ja toome näiteid koodist.

Palun kirjutage kommentaare, kui on teemasid, millele tulevikus tähelepanu pöörata, või küsimusi, mis vajavad selgitamist.

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