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

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

Pjesa e parĂ« — kĂ«tu.

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

Imagjinoni një situatë. Para jush është detyra e zhvillimit të një funksionaliteti të ri. Keni disa përgatitje nga pararendësit tuaj. Nëse supozoni se nuk keni asnjë detyrim moral, si do të vepronit?

Shpesh, të gjitha përgatitjet e vjetra harrohen dhe gjithçka fillon nga e para. Askush nuk do të pëlqente të merret me kodin e dikujt tjetër, dhe siç thonë, pse të mos krijoni sistemin tuaj nëse keni kohë? Ky është një qasje tipike dhe në shumë aspekte e drejtë. Por në projektin tonë ne vepruam ndryshe. Në themel të sistemit të ardhmërisë për teste automatike vendosëm përgatitjet për testet njëshe në utPLSQL nga pararendësit tanë dhe më pas shkuam të punonim në disa drejtime paralele.

  1. Rivendosja e testeve të vjetra njëshe. Këtu nënkuptohet adaptimi i testeve për gjendjen aktuale të sistemit të besnikërisë dhe adaptimi i testeve sipas standardeve të utPLSQL.
  2. Zgjidhja e problemit tĂ« kuptimit se çfarĂ«, cilat metoda dhe procese, janĂ« mbuluar nga testet automatike. Duhet ta mbani kĂ«tĂ« informacion nĂ« mendje ose tĂ« nxirrni pĂ«rfundime nĂ« bazĂ« tĂ« kodit tĂ« testeve automatike. Prandaj vendosĂ«m tĂ« formonim njĂ« katalog. Çdo test automatik ka marrĂ« njĂ« kod unik, kemi formuar njĂ« pĂ«rshkrim dhe kemi regjistruar cilĂ«simet (p.sh., nĂ« cilat kushte duhet tĂ« ekzekutohet, ose çfarĂ« duhet tĂ« ndodhĂ« nĂ«se ekzekutimi i testit dĂ«shton). NĂ« thelb, ne plotĂ«suam metadatĂ« mbi testet automatike dhe i vendosĂ«m kĂ«to metadata nĂ« tabelat standarde tĂ« skemĂ«s utPLSQL.
  3. Përcaktimi i strategjisë së zgjerimit, pra zgjedhja e funksionalitetit që duhet të kontrollohet me testet automatike. Vendosëm të përqendrohemi në tre gjëra: përmirësimet e reja të sistemit, incidentet nga prodhimi dhe proceset kyçe të sistemit. Kështu, ne zhvillojmë paralelisht me lëshimin, duke siguruar cilësi më të lartë dhe duke zgjeruar vëllimin e regresit, dhe sigurojmë që sistemi të jetë i besueshëm në vendet kritike. Një nga këto ngushtica ishte procesi i shpërndarjes së zbritjeve dhe bonuseve në faturë.
  4. Natyrisht, filluam zhvillimin e testeve të reja automatike. Një nga detyrat e para të lëshimit ishte vlerësimi i performancës së grupeve të paracaktuara të sistemit të besnikërisë. Në projektin tonë ka një bllok të kërkesave SQL të ngurta, të cilat përzgjedhin klientët sipas kushteve. Për shembull, të merrni një listë të të gjithë klientëve të cilët blerja e fundit e tyre ishte në një qytet të caktuar, ose një listë klientësh, mesatarja e shpenzimeve të të cilëve është më e lartë se një vlerë e caktuar. Duke shkruar teste automatike, ne kontrolluam grupet e paracaktuara, regjistruam parametrat referues të performancës, dhe për më tepër, morëm testimin e ngarkesës.
  5. Puna me testet automatike duhet të jetë e përshtatshme. Dy veprime kryhen më shpesh: ekzekutimi i testeve automatike dhe krijimi i të dhënave testuese. Kështu, në sistemin tonë u krijuan dy module ndihmëse: moduli i ekzekutimit dhe moduli i gjenerimit të të dhënave.

    Moduli i ekzekutimit paraqitet si një procedurë universale me një parametër hyrës tekstual. Si parametër mund të kaloni kodin e testit automatik, emrin e paketës, emrin e testit, cilësimin e testit automatike ose një fjalë kyçe të rezervuar. Procedure përzgjedh dhe ekzekuton të gjitha testet automatike që i përmbushin kushtet.

    Moduli i gjenerimit të të dhënave paraqitet si një paketë, 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ë, janë mbushur maksimalisht vlerat e defoltit, që siguron krijimin e objekteve pothuajse me një goditje të gishtit. Dhe për lehtësinë e përdorimit janë krijuar të shabllone të të dhënave që krijohen. Për shembull, krijoni një klient të caktuar moshe me një telefon testues dhe një blerje të kryer.

  6. Testet automatike duhet të ekzekutohen dhe të punojnë brenda një kohe të pranueshme për sistemin tuaj. Prandaj u organizua një ekzekutim ditor gjatë natës, nga rezultatet e të cilit formohet një raport mbi rezultatet dhe dërgohet të gjithë ekipit të zhvillimit përmes postës korporative. Pas rivendosjes së testeve të vjetra automatike dhe krijimit të atyre të reja, koha totale e punës ishte 30 minuta. Një performancë e tillë kënaqi të gjithëve, pasi ekzekutimi ndodhi jashtë orarit të punës.

    Por megjithatë, ishte e nevojshme të punohej mbi optimizimin e shpejtësisë së punës. Përditësimi i sistemit të besnikërisë në prodhim bëhet natën. Në kuadër të njërit nga lëshimet, natën duhej të bëheshin ndryshime urgjente. Një pritje gjysmë ore për rezultatet e testeve automatike në tre të mëngjesit nuk e bëri të lumtur personin përgjegjës për lëshimin (përshëndetje të ngrohta për Aleksej Vasyukov!), dhe mëngjesin e ardhshëm u thanë shumë fjalë të mira për sistemin tonë. Por, në përfundim, u vendos një normë pesë minutash për punën.

    Për të përshpejtuar performancën, ne përdorëm dy metoda: testet automatike filluan të ekzekutoheshin në tre rrjedha paralelisht, pasi kjo është shumë e përshtatshme për shkak të arkitekturës së sistemit tonë të besnikërisë. Dhe ne e braktisëm qasjen, ku testi automat do të krijonte të dhëna testuese për veten e tij, por përpiqej të gjente 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ë niset në shembuj të ndryshëm. Në fillim të rrugës pati përpjekje për të shkruar skripta të veta, por u kuptua se një instalim automatizimi i bërë vetë ishte një tmerr i plotë, dhe ne u orientuam drejt zgjidhjeve industriale. Duke qenë se në projekt ka shumë kod (sidomos ne ruajmë kodin e testeve automatike) dhe shumë pak të dhëna (të dhënat kryesore janë metadatAbout testet automatike), ndërhyrja e Liquibase në projekt u bë shumë e thjeshtë.

    Kjo është një bibliotekë e pavarur nga baza e të dhënave me kod të hapur për të ndjekur, menaxhuar dhe aplikuar ndryshimet e skemës së bazës së të dhënave. Ajo menaxhohet përmes linjës së komandës ose framework-eve si Apache Maven. Parimi i funksionimit të Liquibase është mjaft i thjeshtë. Ne kemi një projekt të organizuar në një mënyrë të caktuar, që përbëhet nga ndryshime ose skripta që duhen aplikuar në serverin qëllim, dhe skedarë të menaxhimit që përcaktojnë se në cilën rend dhe me cilat parametra duhen aplikuar këto ndryshime.

    NĂ« nivelin e DBMS krijohet njĂ« tabelĂ« speciale, ku Liquibase mban logun e aplikimeve. Çdo ndryshim ka njĂ« hash tĂ« llogaritur, i cili pĂ«r çdo herĂ« krahasohet midis projektit dhe gjendjes nĂ« bazĂ«. FalĂ« Liquibase, ne lehtĂ«sisht aplikojmĂ« ndryshimet e sistemit tonĂ« nĂ« çdo kontur. Testet automatike tani ekzekutohen nĂ« konturet e testimit dhe lĂ«shimit, si dhe nĂ« kontejnerĂ« (konturet personale tĂ« zhvilluesve).

Testet e njĂ«sisĂ« 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ë testimit njësi.

  1. Sigurisht, në radhë të parë, ne jemi të bindur se filluam të zhvillojmë softuer më cilësor. Testet automatike ekzekutohen çdo ditë dhe çdo lëshim gjejnë dhjetëra gabime. Duke pasur parasysh se një pjesë e këtyre gabimeve është vetëm në mënyrë të tërthortë e lidhur me funksionalitetin që ne donim në të vërtetë të ndryshonim. Ka dyshime të mëdha se këto gabime janë gjetur përmes testimit manual.
  2. Ekipa ka marrĂ« besimin se funksionaliteti konkret punon siç duhet
 Kjo Ă«shtĂ« veçanĂ«risht e vĂ«rtetĂ« pĂ«r proceset tona kritike. PĂ«r shembull, gjatĂ« gjashtĂ« muajve tĂ« fundit, ne nuk kemi pasur probleme me shpĂ«rndarjen e zbritjeve dhe bonuseve nĂ« çek, pavarĂ«sisht ndryshimeve tĂ« çdo lĂ«shimi, edhe pse nĂ« periudha tĂ« kaluara gabimet ndodhnin me njĂ« frekuencĂ« tĂ« caktuar.
  3. Na ka arritur të zvogëlojmë numrin e iteracioneve të testimit. Falë faktit se testet automatike shkruhen për funksionalitetin e ri, kodi i cilësisë më të lartë përfundojë te analistët dhe përndryshe testuesit, pasi ai tashmë është kontrolluar.
  4. Pjesë e punimeve të testimit automatizuar përdoren nga zhvilluesit. Për shembull, të dhënat testuese në kontejnerë krijohen me ndihmën e modulit për gjenerimin e objekteve.
  5. Nuk Ă«shtĂ« pa rĂ«ndĂ«si se Ă«shtĂ« krijuar njĂ« ‘pranimi’ i sistemit tĂ« testimit automatizuar nga ana e zhvilluesve. Ka kuptim se kjo Ă«shtĂ« e rĂ«ndĂ«sishme dhe e dobishme. Dhe nga pĂ«rvoja ime, mund tĂ« them se kjo nuk Ă«shtĂ« aspak e thjeshtĂ«. Testet automatike duhet tĂ« shkruhen, ato duhet tĂ« mbahen dhe tĂ« zhvillohen, tĂ« analizen rezultatet, dhe shpesh kĂ«to shpenzime kohe thjesht nuk ia vlejnĂ«. ËshtĂ« shumĂ« mĂ« e lehtĂ« tĂ« shkojmĂ« nĂ« prodhim dhe tĂ« merremi me problemet atje. Tek ne zhvilluesit formojnĂ« radhĂ« dhe kĂ«rkojnĂ« qĂ« funksionaliteti i tyre tĂ« mbulohet nga testet automatike.

ÇfarĂ« ndodh mĂ« pas

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

Le të flasim për planet për zhvillimin e projektit të testimit automatizuar.

Padyshim, derisa sistemi i besnikërisë së Sportmaster të jetë në jetë dhe të vazhdojë të zhvillohet, është gjithashtu pothuajse pafundësisht e mundur që të zhvillojmë testet automatike. Prandaj, drejtimi kryesor i zhvillimit është zgjerimi i zonës së mbulimit.

Me steigjen e numrit të testeve automatike, koha totale e ekzekutimit të tyre do të rritet vazhdimisht, dhe për këtë arsye do të duhet të kthehemi përsëri te çështja e performancës. Mënyra më e mundshme do të jetë rritja e numrit të rrjedhave paralele.

Por këto janë rrugët e dukshme të zhvillimit. Po flasim për diçka më të thellë, le të theksojmë si më poshtë:

  1. Aktualisht, menaxhimi i testeve automatike realizohet në nivelin e DBMS, pra janë të nevojshme njohuri PL/SQL për të punuar me sukses. Sipas nevojës, mund të nxirret një panel administrativ për menaxhimin e sistemit (p.sh., për të realizuar ekzekutime ose për të krijuar metadata), duke përdorur Jenkins ose diçka të ngjashme.
  2. Të gjithë e duan matjen numerike dhe cilësore. Për testimin automatike, një tregues universal është Coverage Code ose matja e mbulimit të kodit. Me ndihmën e këtij treguesi mund të përcaktojmë se sa përqind e kodit të sistemit tonë të testuar mbulohet nga testet automatike. Që nga versioni 12.2 Oracle ofron mundësi për llogaritjen e këtij treguesi dhe sugjeron përdorimin e paketës standarde DBMS_PLSQL_CODE_COVERAGE.

    Sistemi ynë i testimit automatizuar është pak më shumë se një vit dhe ndoshta tani është koha e duhur për të vlerësuar mbulimin. Në projektin tim të mëparshëm (projekti nuk është Sportmaster), kështu ndodhi. Një vit pas fillimit të punës me testet automatike, drejtimi e vendosi detyrën për të vlerësuar se sa përqind e kodit mbulojmë. Me mbulimin e përqindjes mbi 1%, drejtimi do të ishte i lumtur. Ne, zhvilluesit, prisnim një rezultat rreth 10%. E vendosëm code coverage, matëm dhe morëm 20%. Me gëzim shkuam për shpërblim, por si kaluam atje dhe ku shkuam më vonë, kjo është një histori krejt tjetër.

  3. Testet automatike mund të verifikojnë shërbimet web të ekspozuara. Oracle e lejon këtë plotësisht, dhe ne nuk do të hasim më një gamë problemesh.
  4. Natyrisht, sistemi ynë i testimit automatizuar mund të aplikohet edhe në projektin tjetër. Zgjidhja që kemi arritur është universale dhe thjesht kërkon 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ë atje.

PĂ«rfundimet

Le të përmbledhim. Në projektin e sistemit të besnikërisë në Sportmaster, ne arritëm të realizojmë një sistem të testimit automatizuar. Baza e saj është zgjidhja utPLSQL nga Steven Feuerstein. Rreth utPLSQL është kodin e testeve automatike dhe modulet e tjera ndihmëse: moduli i ekzekutimit, moduli i gjenerimit të të dhënave dhe të tjera. Testet automatike ekzekutohen çdo ditë dhe, më e rëndësishmja, funksionojnë dhe sjellin përfitim. Ne jemi të bindur se kemi filluar të lëshojmë softuer më të cilësisë së lartë. Zgjidhja e marrë është universale dhe mund të aplikohet lirisht në çdo projekt ku është e nevojshme të organizohet testimi automatizuar në DBMS Oracle.

P.S. Ky artikull është mjaft i paqartë: ka shumë tekst dhe praktikisht mungojnë shembuj teknik. Po sikur tema të jetë interesante, jemi gati ta vazhdojmë dhe të kthehemi me vazhdim, ku do të flasim për atë që është ndryshuar gjatë gjashtë muajve të fundit dhe të sjellim shembuj kodi.

Shkruani komente, nëse ka momentet që duhet të theksojnë në të ardhmen, ose pyetje që kërkojnë shpjegim.

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

A po shkruajmë më tej rreth kësaj?

  • Po, sigurisht

  • Jo, faleminderit

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

Burimi: habr.com

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