Tere Habr!
Minu nimi on Maxim Ponomarenko ja olen Sportmasteri arendaja. Mul on 10-aastane kogemus IT-valdkonnas. Ta alustas oma karjääri käsitsi testimise alal, seejärel läks üle andmebaasi arendamisele. Viimased 4 aastat olen testimisel ja arendusel saadud teadmisi kogudes automatiseerinud testimist DBMS tasemel.
Olen olnud Sportmasteri meeskonnas veidi üle aasta ja arendan ühe suurema projekti jaoks automatiseeritud testimist. Aprillis esinesime Sportmaster Labi poistega Krasnodaris toimunud konverentsil, minu aruanne kandis nime “Ühikutestid DBMS-is” ja nüüd tahan seda teiega jagada. Teksti tuleb palju, seega otsustasin jagada raporti kaheks postituseks. Esimeses räägime autotestidest ja testimisest üldiselt ning teises peatun lähemalt meie ühikutestimise süsteemil ja selle rakendamise tulemustel.
Esiteks natuke igav teooria. Mis on automatiseeritud testimine? See on testimine, mida tehakse tarkvara abil ja tänapäeva IT-s kasutatakse seda üha enam tarkvaraarenduses. Selle põhjuseks on asjaolu, et ettevõtted kasvavad, nende infosüsteemid kasvavad ja vastavalt sellele kasvab ka testimist vajava funktsionaalsuse hulk. Käsitsi testimise läbiviimine läheb järjest kallimaks.
Töötasin suures ettevõttes, mille väljaanded ilmuvad iga kahe kuu tagant. Samal ajal kulus terve kuu sellele, et kümmekond testijat käsitsi funktsionaalsust kontrolliks. Tänu automatiseerimise juurutamisele väikese arendajate meeskonna poolt õnnestus meil pooleteise aastaga lühendada testimisaega 2 nädalani. Oleme mitte ainult suurendanud testimise kiirust, vaid parandanud ka selle kvaliteeti. Automaatteste käivitatakse regulaarselt ja nad viivad alati läbi kogu neis sisalduva kontrollide käigus, st välistame inimfaktori.
Kaasaegset IT-d iseloomustab asjaolu, et arendajalt võidakse nõuda mitte ainult tootekoodi kirjutamist, vaid ka seda koodi kontrollivate ühikutestide kirjutamist.
Aga mis siis, kui teie süsteem põhineb peamiselt serveriloogikal? Turul pole universaalset lahendust ega parimaid tavasid. Reeglina lahendavad ettevõtted selle probleemi, luues oma enda kirjutatud testimissüsteemi. See on meie enda kirjutatud automatiseeritud testimissüsteem, mis loodi meie projekti raames ja ma räägin sellest oma raportis.
Lojaalsuse testimine
Esiteks räägime projektist, kus võtsime kasutusele automatiseeritud testimissüsteemi. Meie projekt on Sportmasteri lojaalsussüsteem (muide, me kirjutasime sellest juba aastal ).
Kui teie ettevõte on piisavalt suur, on teie lojaalsussüsteemil kolm standardset omadust:
- Teie süsteem on väga koormatud
- Teie süsteem sisaldab keerulisi andmetöötlusprotsesse
- Teie süsteemi täiustatakse aktiivselt.
Lähme järjekorras... Kokkuvõttes, kui arvestada kõiki Sportmasteri kaubamärke, siis meil on Venemaal, Ukrainas, Hiinas, Kasahstanis ja Valgevenes üle 1000 kaupluse. Neis kauplustes tehakse iga päev umbes 300 000 ostu. See tähendab, et iga teine 3-4 kontrolli siseneb meie süsteemi. Loomulikult on meie lojaalsussüsteem väga koormatud. Ja kuna seda kasutatakse aktiivselt, peame tagama selle kõrgeimad kvaliteedistandardid, sest igasugune viga tarkvaras tähendab suuri rahalisi, maine- ja muid kahjusid.
Samal ajal korraldab Sportmaster enam kui sada erinevat kampaaniat. Kampaaniaid on mitmesuguseid: on tootekampaaniaid, on nädalapäevale pühendatud kampaaniaid, on konkreetse kauplusega seotud kampaaniaid, on soodustusi kviitungi summale, on kaupade arvule. Üldiselt pole paha. Klientidel on boonused ja sooduskoodid, mida kasutatakse ostude sooritamisel. Kõik see toob kaasa asjaolu, et mis tahes tellimuse arvutamine on väga mittetriviaalne ülesanne.
Algoritm, mis rakendab tellimuste töötlemist, on tõeliselt kohutav ja keeruline. Ja kõik selle algoritmi muudatused on üsna riskantsed. Tundus, et kõige ebaolulisemad muudatused võivad viia üsna ettearvamatuteni. Kuid just sellised keerulised andmetöötlusprotsessid, eriti need, mis rakendavad kriitilisi funktsioone, on parimad automatiseerimise kandidaadid. Kümnete sarnaste juhtumite käsitsi kontrollimine on väga aeganõudev. Ja kuna protsessi sisenemispunkt on muutumatu, saate seda korra kirjeldades kiiresti luua automaatseid teste ja olla kindel, et funktsioon töötab.
Kuna meie süsteem on aktiivselt kasutusel, soovib ettevõte sinult midagi uut, ajaga kaasas elamist ja kliendikesksust. Meie lojaalsussüsteemis ilmuvad väljaanded iga kahe kuu tagant. See tähendab, et iga kahe kuu tagant peame läbi viima kogu süsteemi täieliku regressiooni. Samas loomulikult, nagu igas kaasaegses IT-s, ei liigu arendus kohe arendajalt tootmisse. See pärineb arendaja ahelast, läbib seejärel järjestikku katsestendi, vabastatakse, võetakse vastu ja alles siis jõuab tootmisse. Testimis- ja vabastusahelates peame vähemalt läbi viima kogu süsteemi täieliku regressiooni.
Kirjeldatud omadused on standardsed peaaegu iga lojaalsussüsteemi jaoks. Räägime meie projekti omadustest.
Tehnoloogiliselt on 90% meie lojaalsussüsteemi loogikast serveripõhine ja rakendatud Oracle'is. Delphis on eksponeeritud klient, kes täidab automatiseeritud töökoha administraatori funktsiooni. Väliste rakenduste (näiteks veebisaidi) jaoks on avatud veebiteenused. Seetõttu on väga loogiline, et kui võtame kasutusele automatiseeritud testimissüsteemi, teeme seda Oracle'is.
Sportmasteri lojaalsussüsteem on eksisteerinud üle 7 aasta ja selle on loonud üksikud arendajad... Keskmine arendajate arv meie projektis selle 7 aasta jooksul oli 3-4 inimest. Kuid viimase aasta jooksul on meie meeskond oluliselt kasvanud ja nüüd töötab projekti kallal 10 inimest. See tähendab, et projekti tulevad inimesed, kes pole tuttavad tüüpiliste ülesannete, protsesside ja arhitektuuriga. Ja on suurenenud oht, et jätame vead vahele.
Projekti iseloomustab spetsiaalsete testijate puudumine personaliüksustena. Testimine on loomulikult olemas, kuid testimist viivad läbi analüütikud, lisaks oma muudele põhiülesannetele: äriklientide, kasutajatega suhtlemine, süsteeminõuete väljatöötamine jne. jne... Vaatamata sellele, et testimine on tehtud väga kvaliteetselt (seda on eriti asjakohane mainida, sest mõned analüütikud võivad sellest raportist silma jääda), ei ole spetsialiseerumise ja ühele asjale keskendumise tõhusust tühistatud .
Arvestades kõike eeltoodut, tundub tarnitava toote kvaliteedi parandamiseks ja arendusaja lühendamiseks idee projekti testimise automatiseerimisest vägagi loogiline. Ja lojaalsussüsteemi eksisteerimise erinevatel etappidel püüdsid üksikud arendajad oma koodi ühikutestidega katta. Üldiselt oli see üsna lahutatud protsess, kus igaüks kasutas oma arhitektuuri ja meetodeid. Lõpptulemused olid ühiktestidele ühised: testid töötati välja, neid kasutati mõnda aega, salvestati versioonidega failimällu, kuid mingil hetkel lakkasid nende töötamine ja need unustati. Esiteks oli see tingitud asjaolust, et testid olid seotud rohkem konkreetse esinejaga, mitte projektiga.
utPLSQL tuleb appi
Kas sa tead midagi Stephen Feuersteinist?
See on tark mees, kes pühendas pika osa oma karjäärist Oracle'i ja PL/SQL-iga töötamisele ning on sellel teemal kirjutanud üsna palju töid. Üks tema kuulsatest raamatutest kannab nime: “Oracle PL/SQL. Professionaalidele." Stephen töötas välja Oracle PL/SQL-i jaoks utPLSQL-i lahenduse või, nagu see tähendab, Unit Testing raamistiku. utPLSQL-lahendus loodi 2016. aastal, kuid selle kallal töötatakse jätkuvalt aktiivselt ja antakse välja uusi versioone. Aruande esitamise ajal pärineb uusim versioon 24. märtsist 2019.
Mis see on. See on eraldi avatud lähtekoodiga projekt. See kaalub paar megabaiti koos näidete ja dokumentatsiooniga. Füüsiliselt on see eraldi skeem ORACLE andmebaasis koos pakettide ja tabelite komplektiga üksuste testimise korraldamiseks. Installimine võtab paar sekundit. utPLSQL-i eripäraks on selle kasutusmugavus.
Globaalselt on utPLSQL ühiktestide käitamise mehhanism, kus ühikutesti all mõistetakse tavalisi Oracle'i pakkprotseduure, mille korraldus järgib teatud reegleid. Lisaks käivitamisele salvestab utPLSQL kõigi teie katsekäikude logi ja sellel on ka sisemine aruandlussüsteem.
Vaatame näidet selle kohta, kuidas ühikutesti kood seda tehnikat kasutades välja näeb.
Seega kuvatakse ekraanil tüüpilise paketi spetsifikatsiooni kood koos ühikutestidega. Millised on kohustuslikud nõuded? Paketi eesliide peab olema "utp_". Kõigil testidega protseduuridel peab olema täpselt sama eesliide. Pakett peab sisaldama kahte standardprotseduuri: “utp_setup” ja “utp_teardown”. Esimene protseduur kutsutakse välja iga üksuse testi taaskäivitamisel, teine - pärast käivitamist.
"utp_setup" valmistab reeglina meie süsteemi ette ühikutesti käivitamiseks, näiteks katseandmete loomiseks. "utp_teardown" - vastupidi, kõik naaseb algseadetele ja lähtestab käivitustulemused.
Siin on näide kõige lihtsamast ühikutestist, mis kontrollib sisestatud kliendi telefoninumbri normaliseerumist meie lojaalsussüsteemi standardvormile. Puuduvad kohustuslikud standardid, kuidas ühiktestidega protseduure kirjutada. Reeglina helistatakse testitava süsteemi meetodile ja selle meetodiga tagastatud tulemust võrreldakse võrdlusmeetodiga. Oluline on, et võrdlustulemust ja saadud tulemust võrreldaks standardsete utPLSQL-meetoditega.
Ühiktestis võib olla suvaline arv kontrolle. Nagu näitest näha, teeme testitud meetodil neli järjestikust kõnet, et telefoninumbrit normaliseerida ja iga kõne järel tulemust hinnata. Ühiktesti väljatöötamisel tuleb arvestada sellega, et on olemas kontrolle, mis süsteemi kuidagi ei mõjuta ning mõne järel tuleb end tagasi kerida süsteemi algsesse olekusse.
Näiteks esitletud ühikutestis vormindame lihtsalt sisestatud telefoninumbri, mis ei mõjuta lojaalsussüsteemi kuidagi.
Ja kui kirjutame ühikutestid uue kliendi loomise meetodil, siis pärast iga testi luuakse süsteemi uus klient, mis võib mõjutada testi hilisemat käivitamist.
Nii tehakse ühikuteste. Käivitusvõimalusi on kaks: kõigi ühikutestide käivitamine konkreetsest paketist või konkreetse ühikutesti käivitamine konkreetses paketis.
Selline näeb välja näide sisemisest aruandlussüsteemist. Ühikutesti tulemuste põhjal koostab utPLSQL väikese aruande. Selles näeme iga konkreetse kontrolli tulemust ja ühikutesti üldist tulemust.
Autotestide 6 reeglit
Enne uue lojaalsussüsteemi automatiseeritud testimise süsteemi loomise alustamist määrasime koos juhtkonnaga kindlaks põhimõtted, millele meie tulevased automatiseeritud testid peavad vastama.
- Automaattestid peavad olema tõhusad ja kasulikud. Meil on suurepärased arendajad, keda tuleb kindlasti mainida, sest ilmselt näevad mõned neist seda aruannet ja kirjutavad imelist koodi. Kuid isegi nende imeline kood pole täiuslik ning sisaldab, sisaldab ja sisaldab ka edaspidi vigu. Nende vigade leidmiseks on vaja automaatteste. Kui see nii ei ole, siis me kas kirjutame halbu autoteste või oleme jõudnud surnud alale, mida põhimõtteliselt ei arendata. Mõlemal juhul teeme midagi valesti ja meie lähenemisel pole lihtsalt mõtet.
- Kasutada tuleks automaatteste. Pole mõtet kulutada palju aega ja vaeva tarkvaratoote kirjutamisele, hoidlasse paigutamisele ja unustamisele. Teste tuleks läbi viia ja teha nii regulaarselt kui võimalik.
- Autotestid peaksid töötama stabiilselt. Sõltumata kellaajast, käivitusalusest ja muudest süsteemiseadetest, peaksid proovisõidud andma sama tulemuse. Reeglina tagab selle asjaolu, et automaattestid töötavad kindlate süsteemiseadetega spetsiaalsete testandmetega.
- Automaattestid peaksid töötama teie projekti jaoks vastuvõetava kiirusega. See aeg määratakse iga süsteemi jaoks eraldi. Mõned inimesed saavad endale lubada terve päeva tööd, samas kui teiste arvates on ülioluline teha see sekunditega. Ma räägin teile veidi hiljem, millised kiirusstandardid me oma projektiga saavutasime.
- Autotesti arendus peaks olema paindlik. Ei ole soovitatav keelduda ühegi funktsionaalsuse testimisest lihtsalt seetõttu, et me pole seda varem teinud või mõnel muul põhjusel. utPLSQL ei sea arendusele mingeid piiranguid ja Oracle võimaldab põhimõtteliselt rakendada mitmesuguseid asju. Enamikul probleemidest on lahendus, see on vaid aja ja vaeva küsimus.
- Paigaldatavus. Meil on mitu stendi, kus peame katseid läbi viima. Iga stendi juures saab andmeväljavõtet igal ajal värskendada. Automaatsete testidega projekt on vaja läbi viia nii, et saaksite selle täieliku või osalise paigaldamise valutult teostada.
Ja paari päeva pärast teises postituses räägin teile, mida me tegime ja milliseid tulemusi saavutasime.
Allikas: www.habr.com