Ienheidstests yn in DBMS - hoe't wy it dogge yn Sportmaster, diel twa

Earste diel - hjir.

Stel jo de situaasje foar. Jo wurde konfrontearre mei de taak om nije funksjonaliteit te ûntwikkeljen. Jo hawwe ûntwikkelingen fan jo foargongers. As wy oannimme dat jo gjin morele ferplichtingen hawwe, wat soene jo dan dwaan?

Meastentiids wurde alle âlde ûntjouwings fergetten en begjint alles opnij. Nimmen graach graven yn in oar syn koade, mar as jo tiid hawwe, wêrom net begjinne mei it meitsjen fan jo eigen systeem? Dit is in typyske oanpak, en it is foar it grutste part korrekt. Mar yn ús projekt hawwe wy it ferkeard dien. Wy basearje it takomstige automatyske testsysteem op 'e ûntwikkelingen yn ienheidstests op utPLSQL fan ús foargongers, en gongen doe yn ferskate parallelle rjochtingen oan it wurk.

1. Herstellen fan âlde ienheidstests. Herstel betsjut it oanpassen fan testen oan 'e besteande steat fan it loyaliteitssysteem en it oanpassen fan testen oan utPLSQL-standerts.
2. In probleem oplosse mei in begryp fan wat krekt, hokker metoaden en prosessen binne bedekt mei autotests. Jo moatte of hâld dizze ynformaasje yn dyn holle, of lûke konklúzjes basearre direkt op de autotest koade. Dêrom hawwe wy besletten om in katalogus te meitsjen. Wy hawwe in unike mnemonyske koade oan elke autotest tawiisd, in beskriuwing makke en ynstellings opnommen (bygelyks ûnder hokker betingsten it moat wurde lansearre, of wat moat barre as de teststart mislearret). Yn essinsje hawwe wy de metadata oer de autotests befolke en dy metadata pleatst yn standert utPLSQL-skematabellen.
3. It definiearjen fan de útwreiding strategy, i.e. seleksje fan funksjonaliteit dy't ûnderwurpen is oan ferifikaasje troch automatisearre tests. Wy besletten om omtinken te jaan oan trije dingen: nije systeemferbetterings, produksjeynsidinten en wichtige systeemprosessen. Sa ûntwikkelje wy parallel mei de frijlitting, it garandearjen fan syn hegere kwaliteit, tagelyk it útwreidzjen fan it berik fan regression en it garandearjen fan systeembetrouberens op krityske plakken. De earste sa'n knelpunt wie it proses fan it fersprieden fan koartingen en bonussen op in sjek.
4. Fansels binne wy ​​​​begon nije autotests te ûntwikkeljen. Ien fan 'e earste releasetaken wie om de prestaasjes fan foarôf definieare samples fan it loyaliteitssysteem te evaluearjen. Us projekt hat in blok fan stiif fêste SQL-fragen dy't kliïnten selektearje op basis fan betingsten. Bygelyks, krije in list fan alle klanten waans lêste oankeap wie yn in spesifike stêd, of in list fan klanten waans gemiddelde oankeap bedrach is boppe in bepaalde wearde. Nei't wy autotests hawwe skreaun, hawwe wy foarôf definieare samples kontrolearre, parameters foar benchmarkprestaasjes opnommen, en boppedat hiene wy ​​loadtesten.
5. Wurkje mei autotests moat handich wêze. De twa meast foarkommende aksjes binne it útfieren fan autotests en it meitsjen fan testgegevens. Dit is hoe't twa auxiliary modules ferskynden yn ús systeem: in startmodule en in datageneraasjemodule.

   De launcher wurdt fertsjintwurdige as ien universele proseduere mei ien tekstynfierparameter. As parameter kinne jo de autotest-mnemonyske koade, pakketnamme, testnamme, autotest-ynstelling, as in reservearre kaaiwurd trochjaan. De proseduere selekteart en rint alle autotests dy't foldogge oan de betingsten.

   De module foar it generearjen fan gegevens wurdt presintearre yn 'e foarm fan in pakket wêryn foar elk objekt fan it te testen systeem (in tabel yn' e databank) in spesjale proseduere makke is dy't dêr gegevens ynfoegje. Yn dizze proseduere wurde de standertwearden safolle mooglik ynfolle, wat soarget foar it meitsjen fan objekten letterlik mei in klik fan in finger. En foar it gemak fan gebrûk waarden sjabloanen makke foar de oanmakke gegevens. Meitsje bygelyks in klant fan in bepaalde leeftyd mei in testtillefoan en in foltôge oankeap.

6. Autotests moatte begjinne en rinne yn in tiid dy't akseptabel is foar jo systeem. Dêrom waard in deistige lansearring fan 'e nacht organisearre, basearre op' e resultaten wêrfan in rapport oer de resultaten wurdt generearre en fia bedriuwspost nei it heule ûntwikkelingsteam stjoerd. Nei it restaurearjen fan âlde autotests en it meitsjen fan nije, wie de totale wurktiid 30 minuten. Dizze foarstelling paste elkenien, om't de lansearring bûten wurktiden plakfûn.

   Mar wy moasten wurkje oan it optimalisearjen fan de wurksnelheid. It loyaliteitssysteem yn produksje wurdt nachts bywurke. As ûnderdiel fan ien fan de releases, wy moasten meitsje driuwende feroarings nachts. In heal oere wachtsje op de resultaten fan autotests om trije oere moarns makke de persoan dy't ferantwurdlik is foar de frijlitting net bliid (fûle groetnis oan Alexey Vasyukov!), En de oare moarns waarden in protte freonlike wurden sein tsjin ús systeem. Mar as gefolch waard in 5-minutenstandert foar wurk fêststeld.

   Om prestaasjes te fersnellen, brûkten wy twa metoaden: autotests begûnen te rinnen yn trije parallelle triedden, gelokkich is dit heul handich troch de arsjitektuer fan ús loyaliteitssysteem. En wy ferlitte de oanpak wêr't de autotest gjin testgegevens foar himsels makket, mar besiket wat passend te finen yn it systeem. Nei it meitsjen fan de wizigingen waard de totale wurktiid fermindere nei 3-4 minuten.

7. In projekt mei automatyske toetsen moat op ferskate stands ynset wurde kinne. Oan it begjin fan ús reis wiene d'r besykjen om ús eigen batchbestannen te skriuwen, mar it waard dúdlik dat in selsskreaune automatisearre ynstallaasje folsleine horror wie, en wy kearden ús nei yndustriële oplossingen. Fanwegen it feit dat it projekt in soad direkte koade befettet (alearst bewarje wy de autotestkoade) en heul lyts gegevens (de haadgegevens binne metadata oer autotests), die ymplemintaasje yn it Liquibase-projekt heul ienfâldich.

   It is in iepen boarne, database-ûnôfhinklike bibleteek foar it folgjen, behearen en hanthavenjen fan wizigingen fan databaseskema. Beheard fia de kommandorigel of kaders lykas Apache Maven. It prinsipe fan wurking fan Liquibase is frij simpel. Wy hawwe in projekt organisearre op in bepaalde manier, dat bestiet út feroarings of skripts dy't moatte wurde rôle út nei de doeltsjinner, en kontrôle triemmen dy't bepale yn hokker folchoarder en mei hokker parameters dizze feroarings moatte wurde ynstallearre.

   Op it DBMS-nivo wurdt in spesjale tabel makke wêryn Liquibase it rolloverlog opslacht. Elke feroaring hat in berekkene hash, dy't elke kear fergelike wurdt tusken it projekt en de steat yn 'e databank. Mei tank oan Liquibase kinne wy ​​maklik wizigingen oan ús systeem útrolje nei elk circuit. Autotests wurde no lansearre op test- en frijlittingscircuits, lykas op konteners (persoanlike circuits fan ûntwikkelders).

Dat, lit ús prate oer de resultaten fan it brûken fan ús ienheidstestsysteem.

1. Fansels binne wy ​​​​earst derfan oertsjûge dat wy binne begûn mei it ûntwikkeljen fan bettere software. Autotests wurde alle dagen lansearre en tsientallen flaters wurde elke release fûn. Boppedat binne guon fan dizze flaters allinich yndirekt relatearre oan de funksjonaliteit dy't wy echt feroarje woene. D'r binne serieuze twifels dat dizze flaters waarden fûn troch manuele testen.
2. It team hat no it betrouwen dat spesifike funksjonaliteit goed wurket... Dit giet foarearst om ús krityske prosessen. Bygelyks, yn 'e ôfrûne seis moannen hawwe wy gjin problemen hân mei de ferdieling fan koartingen en bonussen op ûntfangsten, nettsjinsteande de frijlittingsferoarings, hoewol yn eardere perioaden flaters barde mei wat frekwinsje
3. Wy binne it slagge om it oantal test-iteraasjes te ferminderjen. Troch it feit dat autotests skreaun binne foar nije funksjonaliteit, krije analysten en parttime testers koade fan hegere kwaliteit, om't it is al kontrolearre.
4. Guon fan 'e ûntwikkelingen yn automatisearre testen wurde brûkt troch ûntwikkelders. Bygelyks, testgegevens op konteners wurde makke mei de module foar generaasje fan objekten.
5. It is wichtich dat wy in "akseptaasje" hawwe ûntwikkele fan it automatisearre testsysteem fan 'e kant fan ûntwikkelders. D'r is in begryp dat dit wichtich en nuttich is. Mar út eigen ûnderfining kin ik sizze dat dit fierstente it gefal is. Autotests moatte wurde skreaun, se moatte wurde stipe en ûntwikkele, de resultaten moatte wurde analysearre, en faaks binne dizze tiidkosten it gewoan net wurdich. It is folle makliker om te gean nei produksje en omgean mei problemen dêr. Hjir steane ûntwikkelders op en freegje ús om har funksjonaliteit te dekken mei autotests.

Wat is hjirnei

Litte wy prate oer de ûntwikkelingsplannen foar it automatisearre testprojekt.

Fansels, sa lang as it loyaliteitssysteem fan Sportmaster libbet en trochgiet te ûntwikkeljen, is it ek mooglik om autotests hast einleaze te ûntwikkeljen. Dêrom is de wichtichste rjochting fan ûntwikkeling it útwreidzjen fan it dekkingsgebiet.

As it oantal autotests tanimt, sil har totale operaasjetiid stadichoan tanimme, en wy sille opnij moatte weromgean nei it probleem fan prestaasjes. Meast wierskynlik sil de oplossing wêze om it oantal parallelle triedden te ferheegjen.

Mar dit binne fanselssprekkende manieren fan ûntwikkeling. As wy prate oer wat mear net-triviale, markearje wy it folgjende:

1. Op it stuit wurdt autotestbehear útfierd op it DBMS-nivo, d.w.s. kennis fan PL / SQL is nedich foar suksesfol wurk. As it nedich is, systeembehear (bygelyks lansearje of meitsje metadata), kinne jo in soarte fan adminpaniel oanmeitsje mei Jenkins of wat ferlykber.
2. Elkenien hâldt fan kwantitative en kwalitative yndikatoaren. Foar automatisearre testen is sa'n universele yndikator Code Coverage of code coverage metric. Mei dizze yndikator kinne wy ​​​​bepale hokker persintaazje fan 'e koade fan ús systeem ûnder test wurdt dekt troch autotests. Begjin fan ferzje 12.2, biedt Oracle de mooglikheid om dizze metrik te berekkenjen en biedt it gebrûk fan it standert DBMS_PLSQL_CODE_COVERAGE-pakket.

   Us autotestsysteem is krekt mear as in jier âld en miskien is it no de tiid om ús dekking te evaluearjen. Yn myn lêste projekt (net in Sportmaster-projekt) is dit wat bard. In jier nei it wurkjen oan autotests sette it management de taak om te beoardieljen hokker persintaazje fan 'e koade wy dekke. Mei in dekking fan mear as 1% soe it bestjoer bliid wêze. Wy, de ûntwikkelders, ferwachte in resultaat fan sa'n 10%. Wy ynstallearre koade dekking, mjitten it, en krigen 20%. Om it te fieren giene wy ​​de priis te heljen, mar hoe't wy dy helle ha en wêr't wy letter hinne giene, is in folslein oar ferhaal.

3. Autotests kinne bleatstelde webtsjinsten kontrolearje. Oracle lit ús dit frij goed dwaan, en wy sille net langer in oantal problemen tsjinkomme.
4. En, fansels, ús automatisearre testsysteem kin tapast wurde op in oar projekt. De oplossing dy't wy krigen hawwe is universeel en fereasket allinich it gebrûk fan Oracle. Ik hearde dat oare Sportmaster-projekten ynteressearre binne yn automatyske testen en miskien sille wy nei har gean.

befinings

Litte wy gearfetsje. Op it projekt fan loyaliteitssysteem yn Sportmaster binne wy ​​it slagge om in automatisearre testsysteem te ymplementearjen. It is basearre op de utPLSQL-oplossing fan Stephen Feuerstein. Om utPLSQL is d'r autotestkoade en selsskreaune helpmodules: startmodule, datageneraasjemodule en oaren. Autotests wurde alle dagen lansearre en, it wichtichste, se wurkje en binne nuttich. Wy binne der wis fan dat wy binne begûn te frijjaan hegere kwaliteit software. Tagelyk is de resultearjende oplossing universeel en kin frij tapast wurde op elk projekt wêr't it nedich is om automatisearre testen te organisearjen op 'e Oracle DBMS.

PS Dit artikel is net hiel spesifyk: der is in soad tekst en praktysk gjin technyske foarbylden. As it ûnderwerp oer it algemien ynteressant is, dan binne wy ​​ree om it troch te gean en werom te kommen mei in fuortsetting, wêr't wy jo sille fertelle wat der yn 'e ôfrûne seis moannen feroare is en koadefoarbylden leverje.

Skriuw opmerkingen as d'r punten binne dy't yn 'e takomst moatte wurde beklamme, of fragen dy't iepenbiering fereaskje.

Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. Ynlogge, asjebleaft.

Sille wy hjir fierder oer skriuwe?

• ja fansels

• Nee bedankt

12 brûkers stimden. 4 brûkers ûntholden har.

Boarne: www.habr.com