Ühikutestid DBMS-is – kuidas me seda teeme Sportmasteris, teine ​​osa

Esimene osa - siin.

Kujutage ette olukorda. Olete silmitsi ülesandega arendada uusi funktsioone. Teil on kogemusi oma eelkäijatelt. Kui eeldada, et teil pole moraalseid kohustusi, mida te teeksite?

Kõige sagedamini unustatakse kõik vanad arendused ja kõik algab otsast peale. Kellelegi ei meeldi kellegi teise koodi süveneda ja kui aega on, siis miks mitte hakata oma süsteemi looma? See on tüüpiline lähenemine ja mitmes mõttes õige. Kuid oma projektis käitusime teisiti. Tulevase automatiseeritud testimissüsteemi võtsime aluseks meie eelkäijate utPLSQL-i ühikutestide arendused ja asusime seejärel tööle mitmes paralleelses suunas.

1. Vanade ühikutestide taastamine. Taastamine tähendab testide kohandamist lojaalsussüsteemi olemasoleva olekuga ja testide kohandamist utPLSQL standarditega.
2. Probleemi lahendamine arusaamisega ja mida täpselt, milliste meetodite ja protsessidega oleme käsitlenud autotestidega. Peate seda teavet oma peas hoidma või tegema järeldusi otse autotestide koodi põhjal. Seetõttu otsustasime luua kataloogi. Määrasime igale automaattestile unikaalse märguandekoodi, koostasime kirjelduse ja parandasime sätted (näiteks millistel tingimustel seda käivitada või mis peaks juhtuma, kui testkäivitus ebaõnnestub). Sisuliselt täitsime automaattestide metaandmed ja paigutasime need metaandmed utPLSQL-skeemi standardtabelitesse.
3. Laienemisstrateegia definitsioon, st. funktsioonide valik, mida kontrollivad automaattestid. Otsustasime pöörata tähelepanu kolmele asjale: süsteemi uued täiustused, tootmisjuhtumid ja süsteemi põhiprotsessid. Seega areneme väljalaskega paralleelselt, tagades selle kõrgema kvaliteedi, laiendades samaaegselt regressiooni ulatust ja tagades süsteemi töökindluse kriitilistes kohtades. Esimene selline kitsaskoht oli allahindluste ja boonuste jagamine tšeki teel.
4. Loomulikult alustasime uute autotestide väljatöötamisega. Üks esimesi väljalaskeülesandeid oli lojaalsussüsteemi eelmääratletud näidiste toimivuse hindamine. Meie projektis on jäigalt fikseeritud SQL-päringute plokk, mis valib kliendid vastavalt tingimustele. Näiteks hankige loend kõigist klientidest, kelle viimane ost sooritati konkreetses linnas, või loend klientidest, kelle keskmine ostusumma ületab teatud väärtuse. Pärast automaattestide kirjutamist kontrollisime eelmääratletud näidiseid, fikseerisime benchmark jõudlusparameetrid ja lisaks saime koormustesti.
5. Autotestidega töötamine peaks olema mugav. Kaks kõige levinumat toimingut on automaattestide käitamine ja testandmete genereerimine. Nii tekkis meie süsteemi kaks abimoodulit: käivitusmoodul ja andmete genereerimise moodul.

   Käivitaja on kujutatud ühe üldise protseduurina ühe sisendteksti parameetriga. Parameetrina saate edastada automaattesti märgusõnakoodi, paketi nime, testi nime, automaattesti sätte või reserveeritud märksõna. Protseduur valib ja käivitab kõik tingimustele vastavad automaattestid.

   Andmete genereerimise moodul esitatakse paketina, milles iga testitava süsteemi objekti (andmebaasis tabel) kohta on loodud spetsiaalne protseduur, mis sisestab sinna andmed. Selle protseduuri puhul täidetakse vaikeväärtused maksimaalselt, mis tagab objektide loomise sõna otseses mõttes ühe sõrmeklõpsuga. Kasutamise hõlbustamiseks loodi loodud andmete mallid. Näiteks loo testtelefoni ja sooritatud ostuga teatud vanuses klient.

6. Automaattestid peaksid käima ja käima teie süsteemi jaoks mõistliku aja jooksul. Seetõttu korraldati igapäevane öine käivitamine, mille tulemuste põhjal koostatakse aruanne tulemuste kohta ja saadetakse ettevõtte postiga kogu arendusmeeskonnale. Peale vanade autotestide taastamist ja uute loomist oli tööajaks kokku 30 minutit. Selline esitus sobis kõigile, kuna käivitamine toimus töövälisel ajal.

   Kuid me pidime töötama töö kiiruse optimeerimisega. Tootmislojaalsuse süsteemi uuendatakse öösel. Ühe väljaande raames pidime öösel kiiresti muudatusi tegema. Pooletunnine autotestide tulemuste ootamine kell kolm öösel ei rõõmustanud vabastamise eest vastutavat inimest (tulised tervitused Aleksei Vasjukovile!) Ja järgmisel hommikul öeldi meie süsteemile palju sooje sõnu. Kuid selle tulemusel pandi tööle 5-minutiline norm.

   Toimivuse kiirendamiseks kasutasime kahte meetodit: alustasime automaattestide käivitamist kolmes paralleelses lõimes, kuna see on meie lojaalsussüsteemi arhitektuuri tõttu väga mugav. Ja loobusime lähenemisest, kui automaattest ei loo enda jaoks testiandmeid, vaid püüab süsteemist midagi sobivat leida. Pärast muudatuste tegemist vähenes kogu tööaeg 3-4 minutini.

7. Autotestidega projekti peaks saama kasutada erinevatel stendidel. Teekonna alguses üritati kirjutada ka oma pakifaile, kuid sai selgeks, et isekirjutatud automatiseeritud installeerimine on täielik õudus ja pöördusime tööstuslike lahenduste poole. Kuna projektis on palju otse koodi (kõigepealt salvestame autotestide koodi) ja väga vähe andmeid (põhiandmeteks on metaandmed autotestide kohta), osutus projekti integreerimine väga lihtsaks. Liquibase projekt.

   See on avatud lähtekoodiga andmebaasist sõltumatu teek andmebaasi skeemi muudatuste jälgimiseks, haldamiseks ja rakendamiseks. Hallatakse käsurea või raamistike (nt Apache Maven) kaudu. Liquibase'i tööpõhimõte on üsna lihtne. Meil on teatud viisil korraldatud projekt, mis koosneb muudatustest või skriptidest, mis tuleb veeretada sihtserverisse, ja juhtfailidest, mis määravad, mis järjekorras ja milliste parameetritega need muudatused installida.

   DBMS-i tasemel luuakse spetsiaalne tabel, kuhu Liquibase salvestab tagasipööramise logi. Igal muudatusel on arvutatud räsi, mida võrreldakse iga kord projekti ja andmebaasi oleku vahel. Tänu Liquibase'ile saame oma süsteemis tehtud muudatused hõlpsalt kasutusele võtta mis tahes vooluringis. Automaatteste käitatakse nüüd testimis- ja vabastamisahelates, samuti konteinerites (isiklikud arendajaahelad).

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

1. Loomulikult oleme esiteks veendunud, et alustasime parema tarkvara väljatöötamisega. Automaattestid käitatakse iga päev ja leiavad kümneid vigu iga versiooni kohta. Lisaks on mõned neist vigadest ainult kaudselt seotud funktsioonidega, mida me tegelikult muuta tahtsime. On tugevaid kahtlusi, et need vead leiti käsitsi testimise teel.
2. Meeskond sai kindlustunde, et konkreetne funktsionaalsus töötab õigesti... Esiteks puudutab see meie kriitilisi protsesse. Näiteks pole meil viimase poole aasta jooksul probleeme olnud soodustuste ja boonuste jagamisega tšeki alusel, vaatamata iga väljalaskega tehtud muudatustele, kuigi varasematel perioodidel esines vigu teatud sagedusega.
3. Meil õnnestus testimise iteratsioonide arvu vähendada. Kuna automaattestid on kirjutatud uute funktsioonide jaoks, saavad analüütikud ja osalise tööajaga testijad kvaliteetsema koodi, kuna see on juba kontrollitud.
4. Osa automatiseeritud testimise arendustest kasutavad arendajad. Näiteks luuakse konteinerite testandmed objektide genereerimise mooduli abil.
5. On oluline, et oleme arendajate poolt välja töötatud automatiseeritud testimissüsteemi „aktsepteerimise”. On arusaam, et see on oluline ja kasulik. Ja omast kogemusest võin öelda, et see pole kaugeltki nii. Autoteste on vaja kirjutada, neid tuleb hooldada ja arendada, tulemusi analüüsida ja sageli ei tasu need ajakulud lihtsalt ära. Palju lihtsam on minna tootmisse ja seal probleemidega tegeleda. Meie riigis seisavad arendajad rivis ja paluvad oma funktsionaalsust automaattestidega katta.

mis edasi

Räägime automatiseeritud testimise projekti arenguplaanidest.

Muidugi, seni kuni Sportmasteri lojaalsussüsteem elab ja areneb edasi, saab ka autoteste peaaegu lõputult arendada. Seetõttu on peamiseks arengusuunaks leviala laiendamine.

Autotestide arvu suurenedes pikeneb nende töö koguaeg pidevalt ja me peame jälle jõudluse küsimuse juurde tagasi pöörduma. Tõenäoliselt on lahendus paralleelsete keermete arvu suurendamine.

Kuid need on ilmsed arenguviisid. Kui räägime millestki mittetriviaalsemast, tõstame esile järgmise:

1. Nüüd hallatakse autoteste DBMS-i tasemel, st. edukaks tööks on vajalik PL/SQL tundmine. Vajadusel saab süsteemihalduse (näiteks metaandmete käivitamise või loomise) välja võtta mingi administraatoripaneel, kasutades Jenkinsi või midagi sarnast.
2. Kõik armastavad kvantitatiivseid ja kvalitatiivseid näitajaid. Automaatse testimise puhul on selliseks universaalseks indikaatoriks Code Coverage ehk koodi katvuse mõõdik. Selle indikaatori abil saame kindlaks teha, mitu protsenti meie testitava süsteemi koodist on automaattestidega kaetud. Alates versioonist 12.2 pakub Oracle selle mõõdiku arvutamise võimalust ja soovitab kasutada standardset paketti DBMS_PLSQL_CODE_COVERAGE.

   Meie automaattestisüsteem on veidi üle aasta vana ja võib-olla on aeg katvust hinnata. Minu viimases projektis (mitte Sportmasteri projekt) see juhtus. Aasta pärast autotestide kallal töötamist seadis juhtkond ülesandeks hinnata, mitu protsenti koodist katsime. Rohkem kui 1% katvuse korral oleks juhtkond rahul. Meie, arendajad, ootasime umbes 10% tulemust. Kruvisime koodi levi, mõõtsime ära, saime 20%. Selle tähistamiseks läksime auhinda järgi, aga see, kuidas meil läks ja kuhu me hiljem läksime, on hoopis teine ​​lugu.

3. Automaattestid saavad testida avatud veebiteenuseid. Oracle võimaldab teil seda teha ja me ei puutu enam kokku paljude probleemidega.
4. Ja loomulikult saab meie automatiseeritud testimissüsteemi rakendada mõnele teisele projektile. Saadud lahendus on universaalne ja nõuab ainult Oracle'i kasutamist. Kuulsin, et on huvi automaattestimise vastu ka teiste Sportmasteri projektide puhul ja võib-olla läheme nende juurde.

Järeldused

Teeme kokkuvõtte. Sportmasteri lojaalsussüsteemi projektis õnnestus meil juurutada automatiseeritud testimissüsteem. Selle aluseks on Stephen Feuersteini utPLSQL-lahendus. utPLSQL-i ümber on kood automaattestide ja abistavate isekirjutatud moodulite jaoks: käivitaja, andmete genereerimise moodul ja muud. Autotestid käivad iga päev ja mis kõige tähtsam, toimivad ja toovad kasu. Oleme veendunud, et oleme hakanud välja andma kvaliteetsemat tarkvara. Samas on saadud lahendus universaalne ja seda saab vabalt rakendada igas projektis, kus on vaja korraldada automaattestimine Oracle DBMS-is.

PS See artikkel osutus mitte eriti konkreetseks: teksti on palju ja tehnilisi näiteid praktiliselt pole. Kui teema on globaalselt huvipakkuv, siis oleme valmis seda jätkama ja naasma jätkuga, kus räägime, mis on viimase poole aasta jooksul muutunud ja toome koodinäiteid.

Kirjutage kommentaaridesse, kui on punkte, mida tuleks edaspidi rõhutada, või küsimusi, mis nõuavad avalikustamist.

Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.

Kas kirjutame sellest lähemalt?

• jah, muidugi

• Ei aitäh

12 kasutajat hääletas. 4 kasutajat jäi erapooletuks.

Allikas: www.habr.com