ProHoster > Blog > Administrim > Testet e njĂ«sive nĂ« DB — si e bĂ«jmĂ« ne nĂ« Sportmaster, pjesa e dytĂ«

Testet e njĂ«sive nĂ« DB — si e bĂ«jmĂ« ne nĂ« Sportmaster, pjesa e dytĂ«

Pjesa e parĂ« — kĂ«tu.

Testet e njĂ«sive nĂ« DB — si e bĂ«jmĂ« ne nĂ« Sportmaster, pjesa e dytĂ«

Imagjinoni një situatë. Ju keni detyrën për të zhvilluar një funksionalitet të ri. Keni disa punë nga paraardhësit tuaj. Nëse supozojmë se nuk keni asnjë detyrim moral, si do të vepronit?

Më së shpeshti, të gjitha punimet e vjetra harrohen dhe gjithçka fillon nga fillimi. Askush nuk e pëlqen të përzihet me kodin e të tjerëve, dhe nëse ka kohë, përse të mos merresh me krijimin e një sistemi të ri? Ky është një qasje tipike, dhe në shumë aspekte është e saktë. Por në projektin tonë nuk vepruam kështu. Në themel të sistemit të ardhshëm të testimit automatizuar, ne vendosëm punimet mbi testet unitare në utPLSQL nga paraardhësit tanë, dhe më pas filluam të punojmë në disa drejtime paralele.

  1. Rindërtimi i testeve të vjetra unitare. Me rindërtimin kuptohet përshtatja e testeve sipas gjendjes aktuale të sistemit të besnikërisë dhe përshtatja e testeve sipas standardeve të utPLSQL.
  2. Zgjidhja e problemit tĂ« kuptimit, çfarĂ« saktĂ«sisht, cilat metoda dhe procese, janĂ« mbuluar nga testet automatike. Duhet ose ta mbani kĂ«tĂ« informacion nĂ« mendje, ose tĂ« nxirrni pĂ«rfundime bazuar nĂ« kodin e testeve automatike. Prandaj, ne vendosĂ«m tĂ« formulojmĂ« njĂ« katalog. Çdo test automatik iu dha njĂ« kod unik mnemonik, kemi formuluar njĂ« pĂ«rshkrim dhe kemi regjistruar konfigurimet (p.sh., nĂ« cilat kushte duhet tĂ« nisĂ«, ose çfarĂ« duhet tĂ« ndodhĂ« nĂ«se testi pĂ«rfundonte me dĂ«shtim). NĂ« thelb, kemi plotĂ«suar metadatĂ«n mbi testet automatike dhe i kemi vendosur kĂ«to metadata nĂ« tabelat standarde tĂ« skemĂ«s utPLSQL.
  3. Definimi i strategjisë së zgjerimit, pra, përzgjedhja e funksionalitetit që do të kontrollohet me anë të testeve automatike. Ne vendosëm të qëndrojmë me vëmendje në tre gjëra: përmirësimet e reja të sistemit, incidentet nga prodhimi dhe proceset kyç të sistemit. Kështu, ne zhvillohemi paralelisht me lëshimin, duke siguruar një cilësi më të lartë, duke zgjeruar përmasat e regresit dhe duke siguruar qëndrueshmërinë e sistemit në vendet kritike. Një nga këto pika të ngushta ishte procesi i shpërndarjes së zbritjeve dhe bonuseve në faturë.
  4. Natyrisht, filluam të zhvillojmë teste të reja automatike. Një nga detyrat e para të lëshimit ishte vlerësimi i performancës së mostrave të paracaktuara të sistemit të besnikërisë. Në projektin tonë kemi një bllok me SQL të ngurtë të dhëna, të cilat përzgjedhin klientët sipas kushteve. Për shembull, të marrim një listë të gjithë klientëve, blerja e fundit e të cilëve ka qenë në një qytet të caktuar, ose listën e klientëve, të cilët kanë një mesatare blerjeje më të lartë se një vlerë të caktuar. Duke shkruar teste automatike, ne verifikuam mostrave të paracaktuara, regjistruam parametrat standard të performancës dhe për më tepër kemi përfituar testi të ngarkesës.
  5. Puna me testet automatike duhet të jetë e përshtatshme. Dy veprime kryesore realizohen më shpesh: fillimi i testeve automatike dhe krijimi i të dhënave testuese. Keshtu në sistemin tonë u krijuan dy module ndihmëse: moduli i nisjes dhe moduli i gjenerimit të të dhënave.

    Moduli i nisjes paraqitet në formën e një procedure universale me një parametër tekstual hyrës. Si parametër, mund të kalosh mnemonic code të testit automat, emrin e paketës, emrin e testit, konfigurimin e testit automat ose një fjalë kyçe të rezervuar. Procedura përzgjedh dhe nis të gjitha testet automatike që përmbushin kushtet.

    Moduli i gjenerimit të të dhënave paraqitet në formën e një pakete, në të cilën për çdo objekt të sistemit të testuar (tabela në DB), është krijuar një procedurë speciale që fut të dhëna atje. Në këtë procedurë, vlerat standarde janë maksimumi plotësuar, duke siguruar krijimin e objekteve me të vërtetë me një klikim. Dhe për lehtësinë e përdorimit janë krijuar shabllonët e të dhënave të krijuara. Për shembull, të krijosh një klient të një moshe të caktuar me një telefon provë dhe një blerje të kryer.

  6. Testet automatike duhet të nisen dhe të funksionojnë në një kohë të pranueshme për sistemin tuaj. Prandaj, është organizuar një nisje e përditshme në mesnatë, mbi rezultatet e së cilës formohet një raport i të dhënave dhe dërgohet gjithë ekipit të zhvillimit përmes postës korporative. Pas rikthimit të testeve të vjetra dhe krijimit të të rinjve, koha totale e punës ishte 30 minuta. Një performancë e tillë kënaqi të gjithë, pasi nisja kalonte në kohë jopune.

    Por optimizimin e shpejtësisë së funksionimit duhej punuar. Përditësimi i sistemit të besnikërisë bëhet në prodhim gjatë natës. Gjatë një prej lëshimeve, u bënë ndryshime urgjente gjatë natës. Një pritje gjysmë ore për rezultatet e testeve automatike në orën tre të mëngjesit nuk e bënte të lumtur personin përgjegjës për lëshimin (përshëndetje të ngrohta për Aleksej Vasyukov!), dhe në mëngjesin e ardhshëm u thanë shumë fjalë të ngrohta për sistemin tonë. Por, pas analizave, u vendos një normë pesë minutëshe për funksionimin.

    Për të përshpejtuar performancën, ne përdorëm dy metoda: testet automatike filluan të ekzekutoheshin në tre rrjedha paralele, falë asaj që ishte shumë e përshtatshme për arkitekturën e sistemit tonë të besnikërisë. Gjithashtu, ne braktisëm qasjen ku testi automatik nuk krijonte të dhëna testuese për veten, por përpiqej të gjejë diçka të përshtatshme në sistem. Pas ndryshimeve, koha e përgjithshme e punës u reduktua në 3-4 minuta.

  7. Projekti me testet automatike duhet të mund të vendoset në ambiente të ndryshme. Në fillim të rrugës pati përpjekje për të shkruar skripte të veta, por bëhet e qartë se instalimi automatizuar që shkruhet vetë është një tmerr i plotë, dhe ne iu drejtua zgjidhjeve industriale. Duke qenë se projekti ka shumë kod (fillimisht ne ruajmë kodin e testeve automatike) dhe shumë pak të dhëna (të dhënat kryesore janë metadat për testet automatike), zbatimi i Liquibase në projekt ishte mjaft i thjeshtë.

    Kjo është një bibliotekë e pavarur nga baza e dhënave me burim të hapur për gjurmimin, menaxhimin dhe aplikimin e ndryshimeve të skemës së bazës së dhënave. Ajo kontrollohet përmes komandave në linjë ose framework-e si Apache Maven. Parimi i funksionimit të Liquibase është mjaft i thjeshtë. Ne kemi një projekt të organizuar në një mënyrë të caktuar, i cili përbëhet nga ndryshime ose skripte që duhen implementuar në serverin e synuar, dhe skedarë menaxhues që përcaktojnë se në cilën rend dhe me cilat parametra këto ndryshime duhet të instalohen.

    NĂ« nivelin e DBMS krijohet njĂ« tavĂ«ll speciale, nĂ« tĂ« cilĂ«n Liquibase ruan logun e aplikimeve. Çdo ndryshim ka njĂ« hash tĂ« llogaritur, i cili çdo herĂ« krahasohet midis projektit dhe gjendjes nĂ« bazĂ«. FalĂ« Liquibase, ne lehtĂ«sisht aplikojmĂ« ndryshimet tona nĂ« çdo ambient. Testet automatike tani ekzekutohen nĂ« ambientet testuese dhe tĂ« lĂ«shimit, si dhe nĂ« kontejnerĂ« (ambientet personale tĂ« zhvilluesve).

Testet e njĂ«sive nĂ« DB — si e bĂ«jmĂ« ne nĂ« Sportmaster, pjesa e dytĂ«

Pra, le të flasim për rezultatet e përdorimit të sistemit tonë të testeve unit.

  1. Sigurisht, në radhë të parë, ne jemi të bindur se kemi filluar të zhvillojmë një softuer më cilësor. Testet automatike ekzekutohen çdo ditë dhe çdo lëshim gjejnë dhjetëra gabime. Dhe një pjesë e këtyre gabimeve është vetëm indirekt e lidhur me funksionalitetin që ne vërtet donim ta ndryshonim. Ka dyshime të mëdha se këto gabime ishin gjetur me testim manual.
  2. Ekipi ynĂ« ka fituar besim se funksionaliteti specifik punon siç duhet
 Kjo vlen veçanĂ«risht pĂ«r proceset tona kritike. PĂ«r shembull, gjatĂ« gjashtĂ« muajve tĂ« fundit nuk kemi pasur probleme me shpĂ«rndarjen e zbritjeve dhe bonuseve nĂ« kupon, megjithĂ«se kemi pasur ndryshime çdo lĂ«shim, ndryshe nga periudhat e mĂ«parshme kur ndonjĂ«herĂ« shfaqeshin gabime.
  3. Na është arritur të reduktojmë numrin e iteracioneve të testimit. Falë faktit se testet automatike shkruhen për funksionalitetin e ri, kodit me cilësi më të lartë i kalon analistëve dhe gjithashtu testeve, sepse ai tashmë është verifikuar.
  4. Pjesa e punimeve të testimit automatizuar përdoret nga zhvilluesit. Për shembull, të dhënat testuese në kontejnerë krijohen përmes modulit të gjenerimit të objekteve.
  5. ËshtĂ« e rĂ«ndĂ«sishme qĂ« ne kemi krijuar njĂ« "pranimin" tĂ« sistemit tĂ« testimit automatizuar nga ana e zhvilluesve. Ka kuptim qĂ« kjo Ă«shtĂ« e rĂ«ndĂ«sishme dhe e dobishme. Dhe nga pĂ«rvoja ime mund tĂ« them se kjo nuk Ă«shtĂ« ashtu. Testet automatike duhet tĂ« shkruhen, ato duhet tĂ« mbahen dhe tĂ« zhvillohen, tĂ« analizohet rezultatet, dhe shpesh kĂ«to harxhime kohe thjesht nuk ia vlen. MĂ« e lehtĂ« Ă«shtĂ« tĂ« shkosh nĂ« prodhim dhe atje tĂ« merresh me problemet. MirĂ«po, kĂ«tu zhvilluesit radhiten nĂ« radhĂ« dhe kĂ«rkojnĂ« tĂ« mbulohet funksionaliteti i tyre me teste automatike.

ÇfarĂ« pason

Testet e njĂ«sive nĂ« DB — si e bĂ«jmĂ« ne nĂ« Sportmaster, pjesa e dytĂ«

Le të flasim për planet e zhvillimit të projektit për testimin automatizuar.

Sigurisht, ndërsa sistemi i besnikërisë së Sportmaster vazhdon të jetë i gjallë dhe të zhvillohet, është gjithashtu e mundur të zhvillosh praktisht pafundësisht testet automatike. Prandaj, drejtimi kryesor i zhvillimit është zgjerimi i zonës së mbulimit.

Me rritjen e numrit të testeve automatike, koha totale e funksionimit të tyre do të rritet pa ndalur, dhe ne do të duhet të kthehemi përsëri te çështja e performancës. Më së shumti, zgjidhja do të jetë rritja e numrit të rrjedhave paralele.

Por këto janë rrugët e dukshme të zhvillimit. Nëse flasim për diçka më të ndërlikuar, le të theksojmë këtë:

  1. Aktualisht, menaxhimi i testeve automatike kryhet në nivelin e DBMS, pra, njohuritë e PL/SQL janë të nevojshme për një funksionim të suksesshëm. Nëse është e nevojshme, menaxhimi i sistemit (p.sh., ekzekutimi i testimeve ose krijimi i metadatanëve) mund të nxirret në ndonjë panel administrativ, duke përdorur Jenkins ose diçka të ngjashme.
  2. Të gjithë e duan matjen sasiore dhe cilësore. Për testimin automatizuar, një indikator universale është Code Coverage ose metrika e mbulimit të kodit. Nëpërmjet këtij treguesi, ne mund të përcaktojmë se sa përqind e kodit të sistemit tonë në testim mbulohet nga testet automatike. Duke filluar nga versioni 12.2, Oracle ofron mundësi për llogaritjen e kësaj metri dhe rekomandon përdorimin e paketës standard DBMS_PLSQL_CODE_COVERAGE.

    Sistemi ynë i testimit automatizuar është pak më shumë se një vit dhe ndoshta tani është koha më e përshtatshme për vlerësimin e mbulimit. Në projektin tim të kaluar (projekti nuk është Sportmaster), dhe kjo ka ndodhur. Pas një viti pune me testet automatike, drejtoria vendosi të vlerësonte se sa përqind e kodit mbulojmë. Me mbulimin më të madh se 1%, drejtoria do të ishte e kënaqur. Ne, zhvilluesit, priteshim një rezultat rreth 10%. Kemi lidhur code coverage, masëm, dhe morëm 20%. Me gëzim shkuam për një shpërblim, por si u shkuam atje dhe çfarë ndodhi më pas është një histori krejt tjetër.

  3. Testet automatike mund të verifikojnë shërbimet web të ekspozuara. Oracle e lejon këtë, dhe ne nuk do të hasim një sërë problemesh.
  4. Dhe, natyrisht, sistemi ynë për testimin e automatizuar mund të aplikohet në një projekt tjetër. Zgjidhja që kemi arritur është universale dhe kërkon vetëm përdorimin e Oracle. Kam dëgjuar se në projekte të tjera të Sportmaster ka interes për testimin automatizuar dhe ndoshta do të shkojmë te ata.

PĂ«rfundimet

Le të përmbledhim. Në projektin e sistemit të besnikërisë në Sportmaster kemi arritur të realizojmë një sistem të testimit të automatizuar. Baza e saj është zgjidhja utPLSQL nga Steven Feierstain. Rreth utPLSQL është kodi i testeve automatizuese dhe module të ndihmës të shkruara vetë: moduli i nisjes, moduli i gjenerimit të të dhënave dhe të tjera. Testet automatizuese kryhen çdo ditë dhe, më e rëndësishmja, funksionojnë dhe sjellin përfitim. Jemi të bindur se kemi filluar të lëshojmë softuer me cilësi më të lartë. Në të njëjtën kohë, zgjidhja e marrë është universale dhe mund të aplikohet lirshëm në çdo projekt ku nevojitet organizimi i testimit të automatizuar në DBMS Oracle.

P.S. Ky artikull doli të mos jetë shumë konkret: ka shumë tekst dhe praktikisht nuk ka shembuj teknikë. Nëse tematikën globale e gjen interesante, jemi të gatshëm ta vazhdojmë dhe të kthehemi me një vazhdim, ku do të tregojmë se çfarë ka ndryshuar në gjashtë muajt e fundit dhe do të sjellim shembuj kodi.

Shkruani komente, nëse ka aspekte, në të cilat duhet të theksojmë në të ardhmen, ose pyetje që kërkojnë shpjegim.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.

A po shkruajmë më tej për këtë?

  • Po, sigurisht

  • Jo, faleminderit

12 përdorues votuan. 4 përdorues abstenuan.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster