Einingapróf í DBMS - hvernig við gerum það í Sportmaster, annar hluti

Fyrsti hluti - hér.

Ímyndaðu þér ástandið. Þú stendur frammi fyrir því verkefni að þróa nýja virkni. Þú hefur þróun frá forverum þínum. Ef við gerum ráð fyrir að þú hafir engar siðferðislegar skyldur, hvað myndir þú gera?

Oftast gleymist öll gömul þróun og allt byrjar upp á nýtt. Engum finnst gaman að grafa í kóða einhvers annars, en ef þú hefur tíma, hvers vegna ekki að byrja að búa til þitt eigið kerfi? Þetta er dæmigerð nálgun og hún er að mestu rétt. En í verkefninu okkar gerðum við það rangt. Við byggðum framtíðar sjálfvirka prófunarkerfið á þróun einingarprófa á utPLSQL frá forverum okkar og fórum síðan í vinnu í nokkrar hliðstæðar áttir.

1. Endurheimt gömul einingapróf. Endurheimt þýðir að aðlaga próf að núverandi ástandi vildarkerfisins og aðlaga próf að utPLSQL stöðlum.
2. Að leysa vandamál með skilningi á því hvað nákvæmlega, hvaða aðferðir og ferlar eru fjallað um með sjálfvirkum prófunum. Þú verður annaðhvort að hafa þessar upplýsingar í höfðinu eða draga ályktanir út frá sjálfvirka prófunarkóðanum. Þess vegna ákváðum við að búa til vörulista. Við úthlutuðum einstökum minnismerkjakóða fyrir hverja sjálfvirka prófun, bjuggum til lýsingu og skráðum stillingar (til dæmis við hvaða aðstæður ætti að ræsa það eða hvað ætti að gerast ef tilraunaræsingin mistekst). Í meginatriðum fylltum við lýsigögnin um sjálfvirku prófin og settum þau lýsigögn í staðlaðar utPLSQL skematöflur.
3. Að marka stækkunarstefnuna, þ.e. val á virkni sem er háð sannprófun með sjálfvirkum prófum. Við ákváðum að huga að þrennu: nýjum kerfisumbótum, framleiðsluatvikum og helstu kerfisferlum. Þannig erum við að þróa samhliða útgáfunni, tryggja meiri gæði hennar, stækka samtímis umfang aðhvarfs og tryggja áreiðanleika kerfisins á mikilvægum stöðum. Fyrsti slíkur flöskuháls var ferlið við að dreifa afslætti og bónusum á ávísun.
4. Auðvitað byrjuðum við að þróa nýjar sjálfvirkar prófanir. Eitt af fyrstu útgáfuverkefnum var að meta frammistöðu fyrirframskilgreindra sýnishorna tryggðarkerfisins. Verkefnið okkar hefur blokk af stíft föstum SQL fyrirspurnum sem velja viðskiptavini út frá aðstæðum. Til dæmis, fáðu lista yfir alla viðskiptavini sem síðast keyptu í tiltekinni borg, eða lista yfir viðskiptavini sem hafa að meðaltali kaupupphæð yfir ákveðnu gildi. Eftir að hafa skrifað sjálfvirkar prófanir, skoðuðum við fyrirfram skilgreind sýni, skráðum viðmiðunarframmistöðubreytur og að auki vorum við með álagsprófun.
5. Það ætti að vera þægilegt að vinna með sjálfvirkar prófanir. Tvær algengustu aðgerðirnar eru að keyra sjálfvirkar prófanir og búa til prófunargögn. Svona birtust tvær aukaeiningar í kerfinu okkar: ræsingareining og gagnaframleiðslueining.

   Ræsirinn er sýndur sem ein alhliða aðferð með einni textainnsláttarfæribreytu. Sem færibreyta geturðu sent sjálfvirka prófunarminniskóðann, pakkanafn, prófunarheiti, sjálfvirka prófunarstillingu eða frátekið leitarorð. Aðferðin velur og keyrir öll sjálfvirk próf sem uppfylla skilyrðin.

   Gagnaframleiðslueiningin er sett fram í formi pakka þar sem fyrir hvern hlut kerfisins sem verið er að prófa (tafla í gagnagrunninum) hefur verið búið til sérstakt verklag sem setur gögn þar inn. Í þessari aðferð eru sjálfgefin gildi fyllt út eins mikið og mögulegt er, sem tryggir að hlutir séu búnir til bókstaflega með því að smella á fingur. Og til að auðvelda notkun voru sniðmát fyrir mynduð gögn búin til. Til dæmis, búa til viðskiptavin á ákveðnum aldri með prófunarsíma og lokið kaupum.

6. Sjálfvirk próf ættu að hefjast og keyra á þeim tíma sem er ásættanlegt fyrir kerfið þitt. Því var skipulögð dagleg næturkynning sem byggist á niðurstöðum sem skýrsla um niðurstöðurnar er búin til og send til alls þróunarteymisins í fyrirtækjapósti. Eftir að hafa endurheimt gamlar sjálfvirkar prófanir og búið til nýjar var heildarvinnslutíminn 30 mínútur. Þessi gjörningur hentaði öllum þar sem sýningin fór fram utan vinnutíma.

   En við urðum að vinna að því að hámarka vinnuhraðann. Vildarkerfi í framleiðslu er uppfært á kvöldin. Sem hluti af einni útgáfunni þurftum við að gera brýnar breytingar á nóttunni. Að bíða í hálftíma eftir niðurstöðum úr sjálfvirkum prófunum klukkan þrjú að nóttu gladdi ekki þann sem bar ábyrgð á útgáfunni (heitar kveðjur til Alexey Vasyukov!) og morguninn eftir voru mörg góð orð sögð í garð kerfisins okkar. En í kjölfarið var settur 5 mínútna staðall fyrir vinnu.

   Til að flýta fyrir frammistöðu notuðum við tvær aðferðir: sjálfvirkar prófanir fóru að keyra í þremur samhliða þráðum, sem betur fer er þetta mjög þægilegt vegna arkitektúrs vildarkerfisins okkar. Og við hættum þeirri nálgun þar sem sjálfvirka prófunin býr ekki til prófunargögn fyrir sig heldur reynir að finna eitthvað við hæfi í kerfinu. Eftir að breytingarnar voru gerðar var heildarvinnslutíminn styttur í 3-4 mínútur.

7. Verkefni með sjálfvirkum prófum ætti að vera hægt að dreifa á ýmsum stöðum. Í upphafi ferðar okkar var reynt að skrifa okkar eigin hópskrár, en það varð ljóst að sjálfskrifuð sjálfvirk uppsetning var algjör hryllingur og við snerum okkur að iðnaðarlausnum. Vegna þess að verkefnið inniheldur mikið af beinum kóða (fyrst af öllu geymum við sjálfvirka prófunarkóðann) og mjög lítil gögn (aðalgögnin eru lýsigögn um sjálfvirkar prófanir) reyndist útfærsla í Liquibase verkefninu mjög einföld.

   Það er opinn uppspretta, gagnagrunnsóháð bókasafn til að rekja, stjórna og framfylgja breytingum á gagnagrunnsskema. Stjórnað í gegnum skipanalínuna eða ramma eins og Apache Maven. Meginreglan um rekstur Liquibase er frekar einföld. Við erum með verkefni skipulagt á ákveðinn hátt, sem samanstendur af breytingum eða forskriftum sem þarf að rúlla út á markþjóninn og stjórna skrám sem ákveða í hvaða röð og með hvaða breytum þessar breytingar eiga að vera settar upp.

   Á DBMS stigi er sérstök tafla búin til þar sem Liquibase geymir rollover log. Hver breyting hefur útreiknað kjötkássa, sem borið er saman hverju sinni á milli verkefnisins og ástandsins í gagnagrunninum. Þökk sé Liquibase getum við auðveldlega sett breytingar á kerfinu okkar í hvaða hringrás sem er. Sjálfvirk próf eru nú sett af stað á prófunar- og losunarrásum, sem og á gámum (persónulegar rásir þróunaraðila).

Svo, við skulum tala um niðurstöður þess að nota einingaprófunarkerfið okkar.

1. Auðvitað erum við fyrst og fremst sannfærð um að við séum byrjuð að þróa betri hugbúnað. Sjálfvirk próf eru sett af stað daglega og tugir villna finnast í hverri útgáfu. Þar að auki eru sumar af þessum villum aðeins óbeint tengdar virkninni sem við vildum virkilega breyta. Það eru alvarlegar efasemdir um að þessar villur hafi fundist með handvirkum prófunum.
2. Teymið hefur nú fullvissu um að tiltekin virkni virki rétt... Í fyrsta lagi varðar þetta mikilvæga ferla okkar. Sem dæmi má nefna að undanfarna sex mánuði höfum við ekki átt í neinum vandræðum með dreifingu afslátta og bónusa á kvittunum, þrátt fyrir útgáfubreytingar, þó að á fyrri tímabilum hafi villur átt sér stað nokkuð oft
3. Okkur tókst að fækka endurteknum prófunum. Vegna þess að sjálfvirk próf eru skrifuð fyrir nýja virkni fá sérfræðingar og hlutastarfsprófarar kóða af meiri gæðum, vegna þess að það hefur þegar verið athugað.
4. Sum þróunin í sjálfvirkum prófunum er notuð af forriturum. Til dæmis eru prófunargögn á gámum búin til með því að nota hlutframleiðslueininguna.
5. Það er mikilvægt að við höfum þróað „samþykki“ á sjálfvirka prófunarkerfinu af hálfu þróunaraðila. Það er skilningur á því að þetta er mikilvægt og gagnlegt. En af eigin reynslu get ég sagt að þetta er fjarri lagi. Sjálfvirk próf þarf að skrifa, þau þarf að styðja og þróa, greina niðurstöðurnar og oft er þessi tímakostnaður einfaldlega ekki þess virði. Það er miklu auðveldara að fara í framleiðslu og takast á við vandamál þar. Hér stilla verktaki sér upp og biðja okkur um að hylja virkni þeirra með sjálfvirkum prófunum.

Hvað er næst

Við skulum tala um þróunaráætlanir fyrir sjálfvirka prófunarverkefnið.

Svo lengi sem tryggðarkerfi Sportmaster er lifandi og heldur áfram að þróast, er auðvitað líka hægt að þróa sjálfvirkar prófanir nánast endalaust. Þess vegna er meginstefna þróunarinnar að stækka umfangssvæðið.

Eftir því sem sjálfvirkum prófunum fjölgar mun heildarvinnslutími þeirra aukast jafnt og þétt og við verðum aftur að snúa okkur að afköstum. Líklegast verður lausnin sú að fjölga samhliða þráðum.

En þetta eru augljósar leiðir til þróunar. Ef við tölum um eitthvað sem er ekki léttvægt, leggjum við áherslu á eftirfarandi:

1. Eins og er er sjálfsprófunarstjórnun framkvæmd á DBMS stigi, þ.e. þekking á PL/SQL er nauðsynleg fyrir árangursríkt starf. Ef nauðsyn krefur, kerfisstjórnun (td ræsa eða búa til lýsigögn), geturðu búið til einhvers konar stjórnborð með Jenkins eða eitthvað álíka.
2. Allir elska megindlega og eigindlega vísbendingar. Fyrir sjálfvirkar prófanir er slíkur alhliða vísir Code Coverage eða kóðaþekjumælikvarði. Með því að nota þennan vísi getum við ákvarðað hversu hátt hlutfall af kóða kerfisins okkar sem er í prófun fellur undir sjálfvirkar prófanir. Frá og með útgáfu 12.2 veitir Oracle möguleika á að reikna út þessa mælikvarða og býður upp á notkun staðlaða DBMS_PLSQL_CODE_COVERAGE pakkans.

   Sjálfvirk prófunarkerfið okkar er rúmlega ársgamalt og kannski er kominn tími til að meta umfjöllun okkar. Í síðasta verkefni mínu (ekki Sportmaster verkefni) gerðist þetta. Ári eftir að hafa unnið að sjálfvirkum prófunum settu stjórnendur sér það verkefni að meta hversu hátt hlutfall kóðans við náum yfir. Með yfir 1% umfjöllun væru stjórnendur ánægðir. Við framkvæmdaraðilar áttum von á um 10% niðurstöðu. Við settum upp kóðaþekju, mældum hana og fengum 20%. Til að fagna því fórum við að ná í vinninginn, en hvernig við fórum að því og hvert við fórum síðar er allt önnur saga.

3. Sjálfvirk próf geta athugað óvarða vefþjónustu. Oracle gerir okkur kleift að gera þetta nokkuð vel og við munum ekki lengur lenda í fjölda vandamála.
4. Og auðvitað er hægt að nota sjálfvirka prófunarkerfið okkar í annað verkefni. Lausnin sem við fengum er alhliða og krefst aðeins notkunar á Oracle. Ég heyrði að önnur Sportmaster verkefni hafi áhuga á sjálfvirkum prófunum og kannski förum við í þau.

Niðurstöður

Við skulum draga saman. Í vildarkerfisverkefninu í Sportmaster tókst okkur að innleiða sjálfvirkt prófunarkerfi. Það er byggt á utPLSQL lausninni frá Stephen Feuerstein. Í kringum utPLSQL er sjálfvirkur prófunarkóði og sjálfskrifaðar aukaeiningar: ræsingareining, gagnaframleiðslueining og fleiri. Sjálfvirk próf eru sett af stað daglega og, síðast en ekki síst, þau virka og eru gagnleg. Við erum fullviss um að við höfum byrjað að gefa út hágæða hugbúnað. Á sama tíma er lausnin sem fæst alhliða og hægt er að beita henni frjálslega í hvaða verkefni sem er þar sem nauðsynlegt er að skipuleggja sjálfvirkar prófanir á Oracle DBMS.

PS Þessi grein er ekki mjög nákvæm: það er mikill texti og nánast engin tæknileg dæmi. Ef viðfangsefnið er almennt áhugavert, þá erum við tilbúin að halda því áfram og koma aftur með framhald, þar sem við munum segja þér hvað hefur breyst undanfarin sex mánuði og koma með kóðadæmi.

Skrifaðu athugasemdir ef það eru atriði sem ætti að leggja áherslu á í framtíðinni, eða spurningar sem krefjast upplýsingagjafar.

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Eigum við að skrifa frekar um þetta?

• Já auðvitað

• Nei takk

12 notendur greiddu atkvæði. 4 notendur sátu hjá.

Heimild: www.habr.com