Tere, Habr!
Minu nimi on Maxim Ponomarenko ja olen arendaja Sportmasteris. Mul on 10-aastane töökogemus IT-sektoris. Alustasin oma karjääri käsitsi testimise alal, seejärel liikusin andmebaaside arendamise suunda. Viimased 4 aastat, kogudes teadmisi, saadud testimises ja arendamises, olen tegelenud andmebaasi tasandi testimise automatiseerimisega.
Olen olnud Sportmasteri meeskonnas veidi üle aasta ja töötan ühel suurel projektil automatiseeritud testimise arendamise kallal. Aprillis esindasime Sportmaster Labiga Krasnodaris toimuval konverentsil, kus minu ettekande teema oli „Unit-testid andmebaasides“. Nüüd tahan seda teiega jagada. Teksti tuleb palju, seega otsustasin ettekande kaheks postituseks jagada. Esimeses räägime automaattestidest ja testimisest üldiselt, teises peatun lähemalt meie unit-testimise süsteemil ja selle rakendamise tulemustel.
Alustuseks natuke igavat teooriat. Mis on automaatne testimine? See on testimine, mida teostatakse tarkvaraliste vahenditega ja mida kasutatakse tänapäeva IT-s üha sagedamini tarkvara arendamisel. See on seotud sellega, et ettevõtted kasvavad, nende infosüsteemid laienevad ning seetõttu suureneb ka testitava funktsionaalsuse hulk. Käe peal testimise teostamine muutub aina kallimaks.
Olen töötanud ühes suurtes ettevõtetes, mille väljaanded toimuvad iga kahe kuu tagant. Sellega seoses kulus terve kuu kümne testija kätega funktsionaalsuse kontrollimiseks. Tänu automatiseerimise rakendamisele suudeti meie väikese arendajate meeskonna abil kahe aasta jooksul testimisaega vähendada kahe nädalani. Me mitte ainult ei suurendanud testimise kiirust, vaid tõstsime ka selle kvaliteeti. Automaatseid teste käivitatakse regulaarselt ja need täidavad alati kogu ettenähtud kontrollide tsükli, mis tähendab, et me välistame inimfaktori.
Kaasaegse IT iseloomustab see, et arendajalt võib oodata mitte ainult toote koodi kirjutamist, vaid ka üksuste teste, mis seda koodi kontrollivad.
Aga mida teha, kui teie süsteem põhineb peamiselt serveri loogikal? Ühte universaalset lahendust ega parimaid praktikaid turul ei eksisteeri. Tavaliselt lahendavad ettevõtted selle probleemi, luues omaenda kohandatud testimissüsteemi. Just selline kohandatud automatiseeritud testimissüsteem loodi meie projektil ja sellest rääkisin ma oma ettekandes.
Testime lojaalsust
Alustame projektist, kus me rakendasime automatiseeritud testimissüsteemi. Meie projekt on Spordimeistri lojaalsussüsteem (muide, me oleme sellest juba kirjutanud ).
Kui teie ettevõte on piisavalt suur, siis teie lojaalsussüsteem omab kolme standardset omadust:
- Teie süsteem on suure koormusega
- Teie süsteem sisaldab keerulisi arvutusprotsesse
- Teie süsteem on aktiivselt täiustatud.
Alustame algusest... Kokku, kui arvestada kõiki Sportmasteri brände, on Venemaal, Ukrainas, Hiinas, Kasahstanis ja Valgevenes üle 1000 poe. Neis poodides toimub igapäevaselt umbes 300 000 ostu. Seega jõuab meie süsteemi igal sekundil 3-4 kassatšeki. Loomulikult on meie lojaalsussüsteem väga koormatud. Ja kuna seda kasutatakse aktiivselt, peame pakkuma kõige kõrgemaid kvaliteedistandardeid, sest iga tarkvaravea korral on suured rahalised, maine ja muud kahjud.
Korraga toimub Sportmasteris üle saja erineva kampaania. Kampaaniad on väga erinevad: on tootekampaaniaid, nädalapäevadega seotud kampaaniaid, kampaaniaid, mis on seotud kindla poes, ja kampaaniaid kassatšeki summale, samuti kaupade arvu järgi. Ühesõnaga on see suur väljakutse. Klientidel on boonused ja promokoodid, mida ostude puhul kasutatakse. Kõik see toob kaasa, et iga tellimuse arvestamine on üsna keeruline ülesanne.
Tellimusprotsessi töötlemise algoritm on tõepoolest kohutav ja keeruline. Mis tahes muudatused selles algoritmis on üsna riskantsed. Tuli välja, et kõige vähenenud istungite harjumusi võivad põhjustada piisavalt ettearvamatud efektid. Just nimelt sellised keerulised arvutusprotsessid, mis rakendavad kriitilist funktsionaalsust — on parimad kandidaadid automatiseerimiseks. Kümnete sarnaste juhtumite käsitsi kontrollimine on aeganõudev. Kuna protsessi sisenemispunkt on muutumatu, siis kui ühe korra selle kirja paned, saab automaatsete testide kiiret tootmist teha ja funktsionaalsuse toimimises kindel olla.
Kuna meie süsteemi kasutatakse aktiivselt, peab äri ootama teilt midagi uut, olema ajaga samas tempodes ja kliendikeskne. Meie lojaalsussüsteemis ilmuvad uuendused iga kahe kuu järel. See tähendab, et iga kahe kuu tagant peame läbi viima kogu süsteemi põhjaliku regressiooni. Samas, nagu igas tänapäevases IT-sektoris, ei jõua arendustooted kohe arendajalt tootmisse. Need sünnivad arendaja kontuuril, seejärel liiguvad järk-järgult läbi testimisstandardi, väljaandmis- ja vastuvõtustandardi ning alles siis jõuavad tootmisse. Kuni vähemalt testimis- ja väljaandmisstandardeil on vajalik kogu süsteemi põhjalik regressioon.
Kirjeldatud omadused on standardsed peaaegu igas lojaalsussüsteemis. Räägime meie projekti eripäradest.
Meie lojaalsussüsteemi tehnoloogia on 90% serveripõhine ja on rakendatud Oracle'i kaudu. On olemas klient, mis on loodud Delphi-s ja mis täidab ARM-administratori funktsiooni. Samuti on välja töötatud veebiteenused väliste rakenduste jaoks (näiteks veebisait). Seega on täiesti loogiline, et kui me hakkame kujundama automatiseeritud testimise süsteemi, siis teeme seda Oracle'il.
Spordimeistris on lojaalsussüsteem eksisteerinud üle 7 aasta ning see loodi üksikute arendajate poolt... Meie projekti keskmine arendajate arv nende 7 aasta jooksul oli 3-4 inimest. Kuid viimase aasta jooksul on meie meeskond oluliselt suurenenud ja nüüd töötab projekti kallal 10 inimest. See tähendab, et projekti tulevad inimesed, kes ei ole tuttavad tüüpiliste ülesannete, protsesside ja arhitektuuriga. Ja on suurenenud risk, et jätame vead tähelepanuta.
Projektile on iseloomulik, et eraldi testeijaid pole ametis. Testimine toimub kindlasti, kuid sellega tegelevad analüütikud, lisaks oma muudele põhikohustustele: suhtlemine äriklientidega, kasutajatega, süsteemi nõuete läbimõtlemine jne jne... Kuigi testimist viiakse läbi väga kvaliteetselt (eriti on seda oluline mainida, kuna mõni analüütik võib selle raporti näha), ei saa keegi eirata spetsialiseerumise ja millegi konkreetsega tegelemise tõhusust.
Kuna kõik eelnev tõstatab, tundub testimise automatiseerimise idee projekti kvaliteedi ja arendusaegade tõstmiseks mõistlik. Erinevatel süsteemi eluetappidel on erinevad arendajad teinud pingutusi oma koodi katmiseks üksustestidega. See oli üldiselt üsna killustatud protsess, kus igaühel oli oma arhitektuur ja meetodid. Üksustestide korral olid lõpptulemused ühesugused: testid arendati, kasutati mõnda aega, säilitati versioonihaldusfailides, kuid ühel hetkel lakkasid nad töötamast ja unustati. Peamiselt juhtus see seetõttu, et testid olid rohkem seotud konkreetse täitjaga, mitte projektiga.
Siin tuleb appi utPLSQL
Kas tead midagi Steven Feuersteini kohta?
See on tark mees, kes on suure osa oma karjäärist pühendanud Oracle'iga ja PL/SQL-iga töötamisele, kirjutades sellel teemal piisavalt palju teoseid. Üks tuntud tema raamat on nimega: „Oracle PL/SQL. Professionaalidele”. Just Stephen tegi lahenduse utPLSQL, mis tähendab Unit Testing framework for Oracle PL/SQL. Lahendus utPLSQL loodi 2016. aastal, kuid selle kallal töötatakse aktiivselt edasi ja uusi versioone väljastatakse pidevalt. Ettekanne toimugu viimane versioon on kuupäevaga 24. märts 2019.
Mis see siis on? See on eraldi avatud lähtekoodiga projekt. Kaalub paar megabaiti koos näidiste ja dokumentatsiooniga. Füüsiliselt on see eraldi skeem ORACLE andmebaasis koos pakettide ja tabelitega, mis aitavad korraldada üksustestimist. Installimine võtab paar sekundit. utPLSQL iseloomustav tunnus on kasutusmugavus.
Globaalselt on utPLSQL mehhanism, mis võimaldab üksusteste käivitada, kus üksusetest tähendab tavalisi Oracle'i pakettprotseduure, mille korraldus vastab teatud reeglitele. Lisaks testide käivitamisele salvestab utPLSQL ka kõikide teie testkäivituste logi ning sisaldab sisemist raporteerimissüsteemi.
Vaatame näitena, milline välja näeb üksustesti kood, mis on rakendatud selle meetodi alusel.
Nii et ekraanil on näha paketi tüüpilise spetsifikatsiooni kood, kus on üksustestid. Millised on kohustuslikud nõuded? Paketil peab olema eelhäälestuse "utp_" prefiks. Sama prefiks peab olema ka kõikidel testide protseduuridel. Paketis peavad olema kaks standardset protseduuri: "utp_setup" ja "utp_teardown". Esimene protseduur käivitatakse iga üksustesti taaskäivitamisel, teine — pärast käivitamist.
"utp_setup" valmistab tavaliselt meie süsteemi ette üksustesti käivitamiseks, näiteks loob testandmed. "utp_teardown" — vastupidi, tagastab kõik algsetesse sätetesse ja nullib käivitamise tulemused.
See on näide kõige lihtsamast unit-testist, mis kontrollib kliendi sisestatud telefoninumbri normaliseerimist meie lojaalsussüsteemis standarditud kujule. Ühtegi nõudlikku standardit, kuidas kirjutada protseduure unit-testide jaoks, ei ole. Reeglina kutsutakse testitavas süsteemis välja mõni meetod, ja selle meetodi tagastatud tulemust võrreldakse viitega. Oluline on, et viidatud tulemuse ja saadud tulemuse võrdlemine toimuks standardsete utPLSQL meetodite kaudu.
Unit-testis võib olla suvaline arv kontrollimisi. Nagu näha näites, teeme neli järjestikust kutset testitava meetodi normaliseerimiseks telefoninumbri osas ja pärast iga kutset hindame tulemust. Unit-testi arendamisel tuleb arvestada, et on olemas kontrollid, mis ei mõjuta süsteemi, kuid pärast mõningaid tuleb tagastada süsteem algsesse olekusse.
Näiteks antud unit-testis vormistame lihtsalt sisendtelefoninumbri, mis ei mõjuta lojaalsussüsteemi.
Ja kui me kirjutame uue kliendi loomise meetodi kohta üksusteste, siis pärast iga kontrollimist luuakse süsteemis uus klient, mis võib mõjutada järgmise testi käivitamist.
Nii käivitatakse unit-testid. Lubatud on kaks käivitamise varianti: kõikide unit-testide käivitamine konkreetsest pakist või konkreetse unit-testi käivitamine teatud pakis.
Nii näeb välja näide sisemisest aruandlussüsteemist. Unit-testi tulemuste põhjal koostab utPLSQL väikese aruande. Selles näeme tulemusi iga konkreetse kontrolli kohta ja unit-testi üldist täitmise tulemust.
6 automaatkatsete reeglit
Enne kui alustasime uue automatiseeritud testimissüsteemi loomisega lojaalsus süsteemis, määratlesime koos juhtkonnaga põhimõtted, millele meie tulevased automaatkatsetused peaksid vastama.
- Autotestid peavad olema tõhusad ja tooma kasu. Meil on toredad arendajad, kelle kohta tuleb kindlasti mainida, et keegi neist näeb tõenäoliselt seda ettekannet ning nad kirjutavad suurepärast koodi. Kuid isegi nende suurepärane kood ei ole ideaalne ning sisaldas, sisaldab ja sisaldab tulevikus vigu. Autotestid peavad need vead leidma. Kui see ei ole nii, siis kas me kirjutame halbu autoteste või oleme jõudnud surnud piirkonda, mis põhimõtteliselt ei arenene. Mõlemal juhul teeme me midagi valesti ja meie lähenemine on lihtsalt mõttetu.
- Autotestid peavad olema kasutuses. On mõttetu kulutada palju aega ja energiat tarkvaratoote kirjutamisele, kokku panna selle hoidla ning unustada. Testid peaksid käima, ja käima võimalikult regulaarselt.
- Autotestid peavad töötama stabiilselt. Olenemata ööpäevaajast, käivitusstandist ja muudest süsteemi seadistustest, peaksid testide käivitused tooma sama tulemuse. Reeglina tagab seda see, et autotestid töötavad spetsiaalsete testandmete ja fikseeritud süsteemi seadistustega.
- Autotestid peaks töötama teie projekti jaoks sobiva kiiruseni. See aeg määratakse igas süsteemis individuaalselt. Mõned saavad endale lubada töötada terve päev, samas kui teistele on kriitiliselt oluline jääda sekunditesse. Milliseid kiirusnorme oleme oma projektis saavutanud, räägin ma veidi hiljem.
- Autotestide arendamine peab olema paindlik. Funktsionaalsuse testimisest loobumine lihtsalt seetõttu, et me pole seda varem teinud või mingi muu veenmise tõttu, ei ole soovitatav. utPLSQL ei sea arendusele mingeid piiranguid ning Oracle võimaldab põhimõtteliselt kõige erinevamaid lahendusi. Enamikul ülesannetest on lahendus, küsimus on vaid ajas ja investeeritud ressursis.
- Rakendatavus. Meil on mitmeid keskkondi, kus testide käivitamine on vajalik. Igas keskkonnas võib iga hetk andmete dumpi uuendada. Projekti autotestidega tuleb juhtida nii, et oleks võimalik teostada selle täielikku või osalist paigaldamist valutult.
Ja teises postituses paar päeva hiljem räägin, mida me tegime ja milliseid tulemusi saavutasime.
Allikas: habr.com
