Üksus-testid andmebaasides — kuidas me seda teeme Sportmasteris, osa üks

Tere, Habr!

Minu nimi on Maksim Ponomarenko ja ma olen arendaja Sportmasteris. Mul on 10-aastane kogemus IT-sektoris. Alustasin karjääri manual testing valdkonnas, seejärel siirdusin andmebaaside arendusse. Viimased 4 aastat olen kogunud teadmisi, mis on saadud testimises ja arendamises, ja tegelen automaatse testimise automatiseerimisega andmebaasitasemel.

Sportmasteri meeskonnas olen olnud veidi üle aasta ja ühe suure projekti raames tegeletakse automaatse testimise arendamisega. Aprillis esinesime Sportmaster Labi poisikeste käest Konverentsil Krasnodaris, minu ettekande pealkiri oli "Üksus-testid andmebaasides" ja nüüd tahan jagada seda teiega. Teksti tuleb palju, seega otsustasin ettekande jagada kaheks postituseks. Esimeses räägime automaatsetest testidest ja testimisest üldiselt, teises peatun täpsemalt meie üksus-testimise süsteemil ja selle rakendamise tulemustel.

Alguses veidi igavat teooriat. Mis on automaatne testimine? See on testimine, mis viiakse läbi tarkvaraliste vahenditega, ja tänapäeva IT-s kasutatakse seda üha enam tarkvara arendamisel. See on seotud sellega, et ettevõtted kasvavad, kasvavad nende info- ja süsteemid ning sellest tulenevalt suureneb ka testitava funktsionaalsuse hulk. Manual testimise läbiviimine muutub järjest keerulisemaks.

Olen töötanud ühes suures ettevõttes, mille väljaanded toimuvad kord kahe kuu jooksul. Sel juhul kulus terve kuu selleks, et tosin testijat käsitsi funktsionaalsust kontrollis. Tänu automatiseerimise rakendamisele väikese arendajate meeskonnaga suudeti meil poolteise aastaga testimise aega vähendada kahe nädalani. Me mitte ainult ei suurendanud testimise kiirus, vaid parandasime ka selle kvaliteeti. Automaatne testid käivitatakse regulaarselt ja nad läbivad alati kogu neid sisse kodeeritud kontrollide kursuse, st välistame inimfaktori.

Tänapäeva IT-le on iseloomulik, et arendajalt võib nõuda mitte ainult toote koodi kirjutamist, vaid ka üksus-testide kirjutamist, mis seda koodi kontrollivad.

Aga mis siis, kui teie süsteem põhineb peamiselt serveriloogikal? Üksnes universaalse lahenduse ja parimatest praktikadest turul ei ole. Üldiselt lahendavad firmad selle probleemi, luues oma kohandatud testimissüsteemi. Selline kohandatud automatiseeritud testimissüsteem loodi ka meie projektis, millest räägin oma ettekandes.

Testime lojaalsust

Räägime kõigepealt projektist, kus käivitasime automatiseeritud testimissüsteemi. Meie projekt on Spordimeistri lojaalsussüsteem (ütleme siinkohal, et oleme sellest juba kirjutanud selles postituses).

Kui teie ettevõte on piisavalt suur, siis teie lojaalsussüsteem omab kolme standardset omadust:

• Teie süsteem on kõrge koormusega
• Teie süsteem sisaldab keerulisi arvutusprotsesse
• Teie süsteemi arendatakse pidevalt edasi.

Liigume järjekorras edasi… Kokku on Spordimeistri brändide puhul Venemaal, Ukrainas, Hiinas, Kasahstanis ja Valgevenes rohkem kui 1000 poodi. Nendes poodides toimub igapäevaselt umbes 300 000 ostu. See tähendab, et meie süsteemi jõuab iga sekund 3-4 tšekki. Loomulikult on meie lojaalsussüsteem kõrge koormusega. Ja kuna seda kasutatakse aktiivselt, peame tagama kõige kõrgemad kvaliteedistandardid, sest iga tarkvara viga tähendab suuri rahalisi, maine ja muid kaotusi.

Samuti töötab Spordimeistri juures korraga üle saja erineva kampaania. Kampaaniad on väga erinevad: on tootekampaaniaid, nädalapäevadega seotud kampaaniaid, teatud poodidega seotud kampaaniaid, tšeki summale seotud kampaaniaid ja toote arvu põhjal kampaaniaid. Ühesõnaga, üsna mitmekesine. Klientidel on boonused, on sooduskoodid, mida kasutatakse ostude ajal. Kõik see teeb igasuguste tellimuste arvestamise üsna keeruliseks ülesandeks.

Tellimusprotsessi rakendav algoritm on tõeliselt kohutav ja keeruline. Iga muutus sellesse algoritmi on piisavalt riskantne. Tunduvad, et kõige väiksemadki muutused võivad tuua kaasa ettearvamatuid mõju. Just need keerulised arvutusprotsessid, eriti kriitilise funktsionaalsuse rakendamine, on parimad kandidaadid automatiseerimiseks. Kümnete sarnaste juhtumite käsitsi kontrollimine on ajakulukas. Ja kuna protsessi sisenemiskoht jääb muutumatuks, on võimalik selle korduv kirjeldamisega üsna kiiresti luua automaatsed testid ning olla kindel funktsionaalsuse töös.

Kuna meie süsteemi kasutatakse aktiivselt, soovib äri teilt midagi uut, et püsida ajaga samas tempos ja olla kliendikeskne. Meie lojaalsussüsteemis ilmusid värskendused iga kahe kuu tagant. See tähendab, et iga kahe kuu tagant peame läbi viima kogu süsteemi täieliku regressiooni. Loomulikult ei lähe arendus kohe arendaja poolt tootmisse. See sünnib arendaja keskkonnas, seejärel läbib järk-järgult testimise, väljalaske ja vastuvõtu etapid ning alles seejärel jõuab tootmisse. Minimaalselt peame testimis- ja väljalaskekeskkondades viima läbi kogu süsteemi täieliku regressiooni.

Kirjeldatud omadused on standardseks peaaegu igas lojaalsussüsteemis. Räägime meie projekti eripäradest.

Tehniliselt on 90% meie lojaalsussüsteemi loogikast serveripoolne ja see on teostatud Oracle'is. Seal on kliendi rakendus Delphi põhjal, mis täidab administraatori APM-i funktsiooni. Samuti on olemas veebiteenused välistele rakendustele (näiteks veebileht). Seetõttu on täiesti loogiline, et kui me tahame rakendada automatiseeritud testimissüsteemi, teeme seda Oracle'i keskkonnas.

Sportmasteri lojaalsussüsteem on olnud toimimas üle 7 aasta ja selle loomine on olnud üksikute arendajate töö… Meie projekti keskmine arendajate arv selle 7 aasta jooksul oli 3-4 inimest. Kuid viimase aasta jooksul on meie meeskond oluliselt suurenenud, ja nüüd töötavad projekti kallal 10 inimest. See tähendab, et projekti tulevad inimesed, kes pole tuttavad tüüpiliste ülesannete, protsesside ja arhitektuuriga. Seega on olemas suurenenud risk, et me jätame vead tähelepanuta.

Projektile on iseloomulik, et puuduvad spetsiaalsed testijad omaenese ametikohtadel. Testimine toimub kindlasti, kuid testimisega tegelevad analüütikud, lisaks oma muudele põhiülesannetele: suhtlemine äriklientidega, kasutajatega, süsteemi nõudmiste töötlemine jne. Ja kuigi testimine toimub väga kvaliteetselt (eriti sobib see mainida, sest mõni analüütik võib selle aruande silmade ette saada), ei saa eirata spetsialiseerumise ja ühele asjale keskendumise efektiivsust.

Arvestades eeltoodut, näib projekti testimise automatiseerimise idee kvaliteedi tõstmiseks ja arendamise ajakava lühendamiseks täiesti loogiline. Ja süsteemi lojaalsuse erinevatel arenguetappidel on erinevad arendajad teinud jõupingutusi, et katta oma kood üksustestidega. See oli üldiselt piisavalt killustunud protsess, kus igaühel oli oma arhitektuur ja meetodid. Üksustestide osas olid ühisteks tulemusteks: testid töötati välja, kas kasutati mõnda aega, pandi versioonihaldusfailide varamusse, kuid mingil hetkel peatus nende käitamine ja need unustati. Peamiselt juhtus see, et testid olid rohkem seotud konkreetse täitjaga, mitte projektiga.

Appi tuleb utPLSQL

Kas tead midagi Steven Feuersteini kohta?

See on nutikas mees, kes on suure osa oma karjäärist pühendanud Oracle'i ja PL/SQL-iga töötamisele, kirjutades selle teemal piisavalt palju teoseid. Üks tuntud raamat kannab nime: „Oracle PL/SQL. Professionaalidele”. Just Stephenile kuulub lahenduse utPLSQL väljatöötamine, mis tähendab Unit Testing framework for Oracle PL/SQL. Lahendus utPLSQL loodi 2016. aastal, kuid selle kallal töötatakse endiselt aktiivselt ja välja antakse uusi versioone. Eesoleva ettekande ajal oli viimane versioon dateeritud 24. märtsiks 2019.
Mis see siis on? See on eraldi avatud lähtekoodi projekt. Kaalub paar megabaiti koos näidiste ja dokumentatsiooniga. Füüsiliselt esindab see eraldi skeemi andmebaasis ORACLE koos pakettide ja tabelitega, et korraldada unit-teste. Paigaldamine võtab paar sekundit. UtPLSQL'i eripära on lihtne kasutamine.
Globaalset vaadates esindab utPLSQL mehhanismi unit-testide käivitamiseks, kus unit-test on tavalised Oracle'i pakettprotseduurid, mille korraldus vastab teatud reeglitele. Lisaks käivitamisele salvestab utPLSQL logi kõigist teie testide käivitamistest ning seal on ka sisemine aruandlussüsteem.

Vaatame näitena, milline on unit-testi kood, mis on rakendatud vastavalt sellele meetodile.

Nii et ekraanil on esitatud tüüpilise paketi spetsifikatsiooni kood koos unit-testidega. Millised on kohustuslikud nõuded? Paketil peab olema etteantud „utp_” eesliide. Täpselt sama eesliide peavad kandma kõik testide protseduurid. Paketis peavad olema kaks standardset protseduuri: „utp_setup” ja „utp_teardown”. Esimene protseduur käivitatakse iga unit-testi käivitamisel, teine — pärast käivitamist.

„utp_setup” valmistab tavaliselt meie süsteemi valmistama unit-testi käivitamiseks, näiteks luues testandmed. „utp_teardown” tagastab kõik vastupidiselt algsetele seadetele ja nullib käivitamise tulemused.

Siin on näide kõige lihtsamast unit-testist, mis kontrollib kliendi sisestatud telefoninumbri normaliseerimist meie lojaalsussüsteemi standardkuju vastavusse. Kohustuslikke standardeid unit-testide protseduuride kirjutamiseks ei ole. Üldiselt kutsutakse esile mingi meetod testitavas süsteemis ning selle meetodi tagastatud tulemust võrreldakse etaloniga. On oluline, et etalonitulemuse ja saadud tulemuse võrdlemine toimuks standardsete utPLSQL meetodite kaudu.

Unit-testis võib olla ükskõik kui palju kontrollimisi. Nagu näha näites, teeme neli järjestikust kutsumist testitavale meetodile telefoninumbri normaliseerimiseks ja pärast iga kutsumist hindame tulemust. Unit-testi arendamisel tuleb arvestada, et on olemas kontrolle, mis ei mõjuta süsteemi, ja pärast mõningaid tuleb süsteem tagasi algsesse olekusse viia.
Näiteks esitatud unit-testis lihtsalt vormindame sisestatud telefoninumbri, mis ei mõjuta lojaalsussüsteemi.

Ja kui kirjutame unit-teste uue kliendi loomise meetodi jaoks, siis pärast iga kontrolli luuakse süsteemis uus klient, mis võib mõjutada katse järgnevat käivitamist.

Nii käivituvad unit-testid. Lubatud on kaks käivitamise varianti: kõigi unit-testide käivitamine konkreetsest paketist või konkreetse unit-testi käivitamine konkreetses paketis.

Nii näeb välja näide sisemisest aruandlussüsteemist. Unit-testi tulemuste põhjal koostab utPLSQL väikese aruande. Selles näeme iga konkreetse kontrolli tulemusi ja unit-testi üldist tulemuse.

6 automaattestimise reeglit

Enne automaattestimise süsteemi loomisega alustamist määrasime koos juhtimisega põhimõtted, millele meie tulevased automaattestid peavad vastama.

1. Autotestid peavad olema tõhusad ja need peavad tooma kasu. Meil on suurepärased arendajad, kellest on kindlasti vaja rääkida, sest keegi neist näeb tõenäoliselt seda ettekannet ja nad kirjutavad suurepärast koodi. Kuid isegi nende suurepärane kood ei ole ideaalne ning sisaldas, sisaldab ja sisaldab ka edaspidi vigu. Autotestid peavad need vead leidma. Kui see ei ole nii, siis kas kirjutame me halbu autoteste või oleme jõudnud surnud piirkonda, mida lihtsalt ei arendata. Mõlemal juhul teeme me midagi valesti ja meie lähenemine on mõttetu.
2. Autoteste peab kasutama. Pole mõtet kulutada kuhjaga aega ja vaeva tarkvaratoote kirjutamisele, selle hoidla kokku panemisele ja siis unustada see. Testid peavad käivituma ja käivituma võimalikult regulaarselt.
3. Autotestid peavad töötama stabiilselt. Ükskõik millal testid käivitatakse, olgu see öö või päev, süsteemi seadistused või muud seaded, peavad testide käivitamised andma sama tulemuse. Reeglina tagab selle, et autotestid töötavad spetsiaalsete testandmete ja fikseeritud süsteemi seadistustega.
4. Autotestid peavad töötama teie projekti jaoks vastuvõetava kiirusena. See aeg määratakse individuaalselt iga süsteemi jaoks. Kes suudab töötada terve päeva, kuid kellelegi on kriitiline ajas sekunditesse mahtuda. Milliseid kiirusstandardeid oleme oma projektis saavutanud, räägin ma veidi hiljem.
5. Autotestide arendamine peab olema paindlik. Ei ole soovitatav loobuda mingi funktsionaalsuse kontrollimisest lihtsalt seetõttu, et me pole seda varem teinud või mingite muude veendumuste tõttu. utPLSQL ei sea arendusele mingeid piiranguid ja Oracle võimaldab üldiselt ellu viia kõige erinevamaid asju. Enamiku ülesannete jaoks on lahendused olemas, küsimus on ainult ajas ja tehtud pingutustes.
6. Käivituvus. Meil on mitmeid keskkondi, kus testide käivitamine on vajalik. Igas keskkonnas võib igal ajal andmete dump olla uuendatud. Projekti autotestide arendamisega tuleb juhtida selliselt, et oleks võimalik teostada selle täis- või osaline installatsioon valutult.

Ja teises postituses paar päeva hiljem räägin, mida me saavutasime ja milliseid tulemusi me välja töötasime.

Allikas: habr.com