{"id":37666,"date":"2019-10-31T22:18:55","date_gmt":"2019-10-31T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya\/"},"modified":"2019-10-31T22:18:55","modified_gmt":"2019-10-31T19:18:55","slug":"unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"Testet e nj\u00ebsis\u00eb n\u00eb DB \u2014 si e b\u00ebjm\u00eb ne n\u00eb Sportmaster, pjesa e dyt\u00eb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pjesa e par\u00eb \u2014 k\u00ebtu<\/a><\/noindex>.<\/i><\/p>\n

\"Testet<\/a><\/noindex><\/p>\n

Imagjinoni nj\u00eb situat\u00eb. Para jush \u00ebsht\u00eb detyra e zhvillimit t\u00eb nj\u00eb funksionaliteti t\u00eb ri. Keni disa p\u00ebrgatitje nga pararend\u00ebsit tuaj. N\u00ebse supozoni se nuk keni asnj\u00eb detyrim moral, si do t\u00eb vepronit?<\/p>\n

Shpesh, t\u00eb gjitha p\u00ebrgatitjet e vjetra harrohen dhe gjith\u00e7ka fillon nga e para. Askush nuk do t\u00eb p\u00eblqente t\u00eb merret me kodin e dikujt tjet\u00ebr, dhe si\u00e7 thon\u00eb, pse t\u00eb mos krijoni sistemin tuaj n\u00ebse keni koh\u00eb? Ky \u00ebsht\u00eb nj\u00eb qasje tipike dhe n\u00eb shum\u00eb aspekte e drejt\u00eb. Por n\u00eb projektin ton\u00eb ne vepruam ndryshe. N\u00eb themel t\u00eb sistemit t\u00eb ardhm\u00ebris\u00eb p\u00ebr teste automatike vendos\u00ebm p\u00ebrgatitjet p\u00ebr testet nj\u00ebshe n\u00eb utPLSQL nga pararend\u00ebsit tan\u00eb dhe m\u00eb pas shkuam t\u00eb punonim n\u00eb disa drejtime paralele.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Rivendosja e testeve t\u00eb vjetra nj\u00ebshe.<\/b> K\u00ebtu n\u00ebnkuptohet adaptimi i testeve p\u00ebr gjendjen aktuale t\u00eb sistemit t\u00eb besnik\u00ebris\u00eb dhe adaptimi i testeve sipas standardeve t\u00eb utPLSQL. <\/li>\n
  2. Zgjidhja e problemit t\u00eb kuptimit se \u00e7far\u00eb, cilat metoda dhe procese, jan\u00eb mbuluar nga testet automatike. <\/b>Duhet ta mbani k\u00ebt\u00eb informacion n\u00eb mendje ose t\u00eb nxirrni p\u00ebrfundime n\u00eb baz\u00eb t\u00eb kodit t\u00eb testeve automatike. Prandaj vendos\u00ebm t\u00eb formonim nj\u00eb katalog. \u00c7do test automatik ka marr\u00eb nj\u00eb kod unik, kemi formuar nj\u00eb p\u00ebrshkrim dhe kemi regjistruar cil\u00ebsimet (p.sh., n\u00eb cilat kushte duhet t\u00eb ekzekutohet, ose \u00e7far\u00eb duhet t\u00eb ndodh\u00eb n\u00ebse ekzekutimi i testit d\u00ebshton). N\u00eb thelb, ne plot\u00ebsuam metadat\u00eb mbi testet automatike dhe i vendos\u00ebm k\u00ebto metadata n\u00eb tabelat standarde t\u00eb skem\u00ebs utPLSQL.<\/li>\n
  3. P\u00ebrcaktimi i strategjis\u00eb s\u00eb zgjerimit, pra zgjedhja e funksionalitetit q\u00eb duhet t\u00eb kontrollohet me testet automatike.<\/b> Vendos\u00ebm t\u00eb p\u00ebrqendrohemi n\u00eb tre gj\u00ebra: p\u00ebrmir\u00ebsimet e reja t\u00eb sistemit, incidentet nga prodhimi dhe proceset ky\u00e7e t\u00eb sistemit. K\u00ebshtu, ne zhvillojm\u00eb paralelisht me l\u00ebshimin, duke siguruar cil\u00ebsi m\u00eb t\u00eb lart\u00eb dhe duke zgjeruar v\u00ebllimin e regresit, dhe sigurojm\u00eb q\u00eb sistemi t\u00eb jet\u00eb i besuesh\u00ebm n\u00eb vendet kritike. Nj\u00eb nga k\u00ebto ngushtica ishte procesi i shp\u00ebrndarjes s\u00eb zbritjeve dhe bonuseve n\u00eb fatur\u00eb.<\/li>\n
  4. Natyrisht, filluam zhvillimin e testeve t\u00eb reja automatike. <\/b>Nj\u00eb nga detyrat e para t\u00eb l\u00ebshimit ishte vler\u00ebsimi i performanc\u00ebs s\u00eb grupeve t\u00eb paracaktuara t\u00eb sistemit t\u00eb besnik\u00ebris\u00eb. N\u00eb projektin ton\u00eb ka nj\u00eb bllok t\u00eb k\u00ebrkesave SQL t\u00eb ngurta, t\u00eb cilat p\u00ebrzgjedhin klient\u00ebt sipas kushteve. P\u00ebr shembull, t\u00eb merrni nj\u00eb list\u00eb t\u00eb t\u00eb gjith\u00eb klient\u00ebve t\u00eb cil\u00ebt blerja e fundit e tyre ishte n\u00eb nj\u00eb qytet t\u00eb caktuar, ose nj\u00eb list\u00eb klient\u00ebsh, mesatarja e shpenzimeve t\u00eb t\u00eb cil\u00ebve \u00ebsht\u00eb m\u00eb e lart\u00eb se nj\u00eb vler\u00eb e caktuar. Duke shkruar teste automatike, ne kontrolluam grupet e paracaktuara, regjistruam parametrat referues t\u00eb performanc\u00ebs, dhe p\u00ebr m\u00eb tep\u00ebr, mor\u00ebm testimin e ngarkes\u00ebs.<\/li>\n
  5. Puna me testet automatike duhet t\u00eb jet\u00eb e p\u00ebrshtatshme<\/b>. Dy veprime kryhen m\u00eb shpesh: ekzekutimi i testeve automatike dhe krijimi i t\u00eb dh\u00ebnave testuese. K\u00ebshtu, n\u00eb sistemin ton\u00eb u krijuan dy module ndihm\u00ebse: moduli i ekzekutimit dhe moduli i gjenerimit t\u00eb t\u00eb dh\u00ebnave.\n

    Moduli i ekzekutimit paraqitet si nj\u00eb procedur\u00eb universale me nj\u00eb paramet\u00ebr hyr\u00ebs tekstual. Si paramet\u00ebr mund t\u00eb kaloni kodin e testit automatik, emrin e paket\u00ebs, emrin e testit, cil\u00ebsimin e testit automatike ose nj\u00eb fjal\u00eb ky\u00e7e t\u00eb rezervuar. Procedure p\u00ebrzgjedh dhe ekzekuton t\u00eb gjitha testet automatike q\u00eb i p\u00ebrmbushin kushtet.<\/p>\n

    Moduli i gjenerimit t\u00eb t\u00eb dh\u00ebnave paraqitet si nj\u00eb paket\u00eb, n\u00eb t\u00eb cil\u00ebn p\u00ebr \u00e7do objekt t\u00eb sistemit t\u00eb testuar (tabela n\u00eb DB), \u00ebsht\u00eb krijuar nj\u00eb procedur\u00eb speciale q\u00eb fut t\u00eb dh\u00ebna atje. N\u00eb k\u00ebt\u00eb procedur\u00eb, jan\u00eb mbushur maksimalisht vlerat e defoltit, q\u00eb siguron krijimin e objekteve pothuajse me nj\u00eb goditje t\u00eb gishtit. Dhe p\u00ebr leht\u00ebsin\u00eb e p\u00ebrdorimit jan\u00eb krijuar t\u00eb shabllone t\u00eb t\u00eb dh\u00ebnave q\u00eb krijohen. P\u00ebr shembull, krijoni nj\u00eb klient t\u00eb caktuar moshe me nj\u00eb telefon testues dhe nj\u00eb blerje t\u00eb kryer.<\/li>\n

  6. Testet automatike duhet t\u00eb ekzekutohen dhe t\u00eb punojn\u00eb brenda nj\u00eb kohe t\u00eb pranueshme p\u00ebr sistemin tuaj. <\/b>Prandaj u organizua nj\u00eb ekzekutim ditor gjat\u00eb nat\u00ebs, nga rezultatet e t\u00eb cilit formohet nj\u00eb raport mbi rezultatet dhe d\u00ebrgohet t\u00eb gjith\u00eb ekipit t\u00eb zhvillimit p\u00ebrmes post\u00ebs korporative. Pas rivendosjes s\u00eb testeve t\u00eb vjetra automatike dhe krijimit t\u00eb atyre t\u00eb reja, koha totale e pun\u00ebs ishte 30 minuta. Nj\u00eb performanc\u00eb e till\u00eb k\u00ebnaqi t\u00eb gjith\u00ebve, pasi ekzekutimi ndodhi jasht\u00eb orarit t\u00eb pun\u00ebs.\n

    Por megjithat\u00eb, ishte e nevojshme t\u00eb punohej mbi optimizimin e shpejt\u00ebsis\u00eb s\u00eb pun\u00ebs. P\u00ebrdit\u00ebsimi i sistemit t\u00eb besnik\u00ebris\u00eb n\u00eb prodhim b\u00ebhet nat\u00ebn. N\u00eb kuad\u00ebr t\u00eb nj\u00ebrit nga l\u00ebshimet, nat\u00ebn duhej t\u00eb b\u00ebheshin ndryshime urgjente. Nj\u00eb pritje gjysm\u00eb ore p\u00ebr rezultatet e testeve automatike n\u00eb tre t\u00eb m\u00ebngjesit nuk e b\u00ebri t\u00eb lumtur personin p\u00ebrgjegj\u00ebs p\u00ebr l\u00ebshimin (p\u00ebrsh\u00ebndetje t\u00eb ngrohta p\u00ebr Aleksej Vasyukov!), dhe m\u00ebngjesin e ardhsh\u00ebm u than\u00eb shum\u00eb fjal\u00eb t\u00eb mira p\u00ebr sistemin ton\u00eb. Por, n\u00eb p\u00ebrfundim, u vendos nj\u00eb norm\u00eb pes\u00eb minutash p\u00ebr pun\u00ebn.<\/p>\n

    P\u00ebr t\u00eb p\u00ebrshpejtuar performanc\u00ebn, ne p\u00ebrdor\u00ebm dy metoda: testet automatike filluan t\u00eb ekzekutoheshin n\u00eb tre rrjedha paralelisht, pasi kjo \u00ebsht\u00eb shum\u00eb e p\u00ebrshtatshme p\u00ebr shkak t\u00eb arkitektur\u00ebs s\u00eb sistemit ton\u00eb t\u00eb besnik\u00ebris\u00eb. Dhe ne e braktis\u00ebm qasjen, ku testi automat do t\u00eb krijonte t\u00eb dh\u00ebna testuese p\u00ebr veten e tij, por p\u00ebrpiqej t\u00eb gjente di\u00e7ka t\u00eb p\u00ebrshtatshme n\u00eb sistem. Pas ndryshimeve, koha e p\u00ebrgjithshme e pun\u00ebs u reduktua n\u00eb 3-4 minuta.<\/li>\n

  7. Projekti me testet automatike duhet t\u00eb mund t\u00eb niset n\u00eb shembuj t\u00eb ndrysh\u00ebm.<\/b> N\u00eb fillim t\u00eb rrug\u00ebs pati p\u00ebrpjekje p\u00ebr t\u00eb shkruar skripta t\u00eb veta, por u kuptua se nj\u00eb instalim automatizimi i b\u00ebr\u00eb vet\u00eb ishte nj\u00eb tmerr i plot\u00eb, dhe ne u orientuam drejt zgjidhjeve industriale. Duke qen\u00eb se n\u00eb projekt ka shum\u00eb kod (sidomos ne ruajm\u00eb kodin e testeve automatike) dhe shum\u00eb pak t\u00eb dh\u00ebna (t\u00eb dh\u00ebnat kryesore jan\u00eb metadatAbout testet automatike), nd\u00ebrhyrja e Liquibase n\u00eb projekt u b\u00eb shum\u00eb e thjesht\u00eb.\n

    Kjo \u00ebsht\u00eb nj\u00eb bibliotek\u00eb e pavarur nga baza e t\u00eb dh\u00ebnave me kod t\u00eb hapur p\u00ebr t\u00eb ndjekur, menaxhuar dhe aplikuar ndryshimet e skem\u00ebs s\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave. Ajo menaxhohet p\u00ebrmes linj\u00ebs s\u00eb komand\u00ebs ose framework-eve si Apache Maven. Parimi i funksionimit t\u00eb Liquibase \u00ebsht\u00eb mjaft i thjesht\u00eb. Ne kemi nj\u00eb projekt t\u00eb organizuar n\u00eb nj\u00eb m\u00ebnyr\u00eb t\u00eb caktuar, q\u00eb p\u00ebrb\u00ebhet nga ndryshime ose skripta q\u00eb duhen aplikuar n\u00eb serverin q\u00ebllim, dhe skedar\u00eb t\u00eb menaxhimit q\u00eb p\u00ebrcaktojn\u00eb se n\u00eb cil\u00ebn rend dhe me cilat parametra duhen aplikuar k\u00ebto ndryshime. <\/p>\n

    N\u00eb nivelin e DBMS krijohet nj\u00eb tabel\u00eb speciale, ku Liquibase mban logun e aplikimeve. \u00c7do ndryshim ka nj\u00eb hash t\u00eb llogaritur, i cili p\u00ebr \u00e7do her\u00eb krahasohet midis projektit dhe gjendjes n\u00eb baz\u00eb. Fal\u00eb Liquibase, ne leht\u00ebsisht aplikojm\u00eb ndryshimet e sistemit ton\u00eb n\u00eb \u00e7do kontur. Testet automatike tani ekzekutohen n\u00eb konturet e testimit dhe l\u00ebshimit, si dhe n\u00eb kontejner\u00eb (konturet personale t\u00eb zhvilluesve).<\/li>\n<\/ol>\n

    \"Testet
    \n
    \nPra, le t\u00eb flasim p\u00ebr rezultatet e p\u00ebrdorimit t\u00eb sistemit ton\u00eb t\u00eb testimit nj\u00ebsi. <\/p>\n

      \n
    1. Sigurisht, n\u00eb radh\u00eb t\u00eb par\u00eb, ne jemi t\u00eb bindur se filluam t\u00eb zhvillojm\u00eb softuer m\u00eb cil\u00ebsor. Testet automatike ekzekutohen \u00e7do dit\u00eb dhe \u00e7do l\u00ebshim gjejn\u00eb dhjet\u00ebra gabime. Duke pasur parasysh se nj\u00eb pjes\u00eb e k\u00ebtyre gabimeve \u00ebsht\u00eb vet\u00ebm n\u00eb m\u00ebnyr\u00eb t\u00eb t\u00ebrthort\u00eb e lidhur me funksionalitetin q\u00eb ne donim n\u00eb t\u00eb v\u00ebrtet\u00eb t\u00eb ndryshonim. Ka dyshime t\u00eb m\u00ebdha se k\u00ebto gabime jan\u00eb gjetur p\u00ebrmes testimit manual. <\/li>\n
    2. Ekipa ka marr\u00eb besimin se funksionaliteti konkret punon si\u00e7 duhet\u2026 Kjo \u00ebsht\u00eb ve\u00e7an\u00ebrisht e v\u00ebrtet\u00eb p\u00ebr proceset tona kritike. P\u00ebr shembull, gjat\u00eb gjasht\u00eb muajve t\u00eb fundit, ne nuk kemi pasur probleme me shp\u00ebrndarjen e zbritjeve dhe bonuseve n\u00eb \u00e7ek, pavar\u00ebsisht ndryshimeve t\u00eb \u00e7do l\u00ebshimi, edhe pse n\u00eb periudha t\u00eb kaluara gabimet ndodhnin me nj\u00eb frekuenc\u00eb t\u00eb caktuar.<\/li>\n
    3. Na ka arritur t\u00eb zvog\u00eblojm\u00eb numrin e iteracioneve t\u00eb testimit. Fal\u00eb faktit se testet automatike shkruhen p\u00ebr funksionalitetin e ri, kodi i cil\u00ebsis\u00eb m\u00eb t\u00eb lart\u00eb p\u00ebrfundoj\u00eb te analist\u00ebt dhe p\u00ebrndryshe testuesit, pasi ai tashm\u00eb \u00ebsht\u00eb kontrolluar.<\/li>\n
    4. Pjes\u00eb e punimeve t\u00eb testimit automatizuar p\u00ebrdoren nga zhvilluesit. P\u00ebr shembull, t\u00eb dh\u00ebnat testuese n\u00eb kontejner\u00eb krijohen me ndihm\u00ebn e modulit p\u00ebr gjenerimin e objekteve.<\/li>\n
    5. Nuk \u00ebsht\u00eb pa r\u00ebnd\u00ebsi se \u00ebsht\u00eb krijuar nj\u00eb \u2018pranimi\u2019 i sistemit t\u00eb testimit automatizuar nga ana e zhvilluesve. Ka kuptim se kjo \u00ebsht\u00eb e r\u00ebnd\u00ebsishme dhe e dobishme. Dhe nga p\u00ebrvoja ime, mund t\u00eb them se kjo nuk \u00ebsht\u00eb aspak e thjesht\u00eb. Testet automatike duhet t\u00eb shkruhen, ato duhet t\u00eb mbahen dhe t\u00eb zhvillohen, t\u00eb analizen rezultatet, dhe shpesh k\u00ebto shpenzime kohe thjesht nuk ia vlejn\u00eb. \u00cbsht\u00eb shum\u00eb m\u00eb e leht\u00eb t\u00eb shkojm\u00eb n\u00eb prodhim dhe t\u00eb merremi me problemet atje. Tek ne zhvilluesit formojn\u00eb radh\u00eb dhe k\u00ebrkojn\u00eb q\u00eb funksionaliteti i tyre t\u00eb mbulohet nga testet automatike.<\/li>\n<\/ol>\n

      \u00c7far\u00eb ndodh m\u00eb pas<\/h2>\n

      \n\"Testet
      \n
      \nLe t\u00eb flasim p\u00ebr planet p\u00ebr zhvillimin e projektit t\u00eb testimit automatizuar.<\/p>\n

      Padyshim, derisa sistemi i besnik\u00ebris\u00eb s\u00eb Sportmaster t\u00eb jet\u00eb n\u00eb jet\u00eb dhe t\u00eb vazhdoj\u00eb t\u00eb zhvillohet, \u00ebsht\u00eb gjithashtu pothuajse pafund\u00ebsisht e mundur q\u00eb t\u00eb zhvillojm\u00eb testet automatike. Prandaj, drejtimi kryesor i zhvillimit \u00ebsht\u00eb zgjerimi i zon\u00ebs s\u00eb mbulimit.<\/p>\n

      Me steigjen e numrit t\u00eb testeve automatike, koha totale e ekzekutimit t\u00eb tyre do t\u00eb rritet vazhdimisht, dhe p\u00ebr k\u00ebt\u00eb arsye do t\u00eb duhet t\u00eb kthehemi p\u00ebrs\u00ebri te \u00e7\u00ebshtja e performanc\u00ebs. M\u00ebnyra m\u00eb e mundshme do t\u00eb jet\u00eb rritja e numrit t\u00eb rrjedhave paralele.<\/p>\n

      Por k\u00ebto jan\u00eb rrug\u00ebt e dukshme t\u00eb zhvillimit. Po flasim p\u00ebr di\u00e7ka m\u00eb t\u00eb thell\u00eb, le t\u00eb theksojm\u00eb si m\u00eb posht\u00eb:<\/p>\n

        \n
      1. Aktualisht, menaxhimi i testeve automatike realizohet n\u00eb nivelin e DBMS, pra jan\u00eb t\u00eb nevojshme njohuri PL\/SQL p\u00ebr t\u00eb punuar me sukses. Sipas nevoj\u00ebs, mund t\u00eb nxirret nj\u00eb panel administrativ p\u00ebr menaxhimin e sistemit (p.sh., p\u00ebr t\u00eb realizuar ekzekutime ose p\u00ebr t\u00eb krijuar metadata), duke p\u00ebrdorur Jenkins ose di\u00e7ka t\u00eb ngjashme.<\/li>\n
      2. T\u00eb gjith\u00eb e duan matjen numerike dhe cil\u00ebsore. P\u00ebr testimin automatike, nj\u00eb tregues universal \u00ebsht\u00eb Coverage Code ose matja e mbulimit t\u00eb kodit. Me ndihm\u00ebn e k\u00ebtij treguesi mund t\u00eb p\u00ebrcaktojm\u00eb se sa p\u00ebrqind e kodit t\u00eb sistemit ton\u00eb t\u00eb testuar mbulohet nga testet automatike. Q\u00eb nga versioni 12.2 Oracle ofron mund\u00ebsi p\u00ebr llogaritjen e k\u00ebtij treguesi dhe sugjeron p\u00ebrdorimin e paket\u00ebs standarde DBMS_PLSQL_CODE_COVERAGE.\n

        Sistemi yn\u00eb i testimit automatizuar \u00ebsht\u00eb pak m\u00eb shum\u00eb se nj\u00eb vit dhe ndoshta tani \u00ebsht\u00eb koha e duhur p\u00ebr t\u00eb vler\u00ebsuar mbulimin. N\u00eb projektin tim t\u00eb m\u00ebparsh\u00ebm (projekti nuk \u00ebsht\u00eb Sportmaster), k\u00ebshtu ndodhi. Nj\u00eb vit pas fillimit t\u00eb pun\u00ebs me testet automatike, drejtimi e vendosi detyr\u00ebn p\u00ebr t\u00eb vler\u00ebsuar se sa p\u00ebrqind e kodit mbulojm\u00eb. Me mbulimin e p\u00ebrqindjes mbi 1%, drejtimi do t\u00eb ishte i lumtur. Ne, zhvilluesit, prisnim nj\u00eb rezultat rreth 10%. E vendos\u00ebm code coverage, mat\u00ebm dhe mor\u00ebm 20%. Me g\u00ebzim shkuam p\u00ebr shp\u00ebrblim, por si kaluam atje dhe ku shkuam m\u00eb von\u00eb, kjo \u00ebsht\u00eb nj\u00eb histori krejt tjet\u00ebr.<\/li>\n

      3. Testet automatike mund t\u00eb verifikojn\u00eb sh\u00ebrbimet web t\u00eb ekspozuara. Oracle e lejon k\u00ebt\u00eb plot\u00ebsisht, dhe ne nuk do t\u00eb hasim m\u00eb nj\u00eb gam\u00eb problemesh. <\/li>\n
      4. Natyrisht, sistemi yn\u00eb i testimit automatizuar mund t\u00eb aplikohet edhe n\u00eb projektin tjet\u00ebr. Zgjidhja q\u00eb kemi arritur \u00ebsht\u00eb universale dhe thjesht k\u00ebrkon p\u00ebrdorimin e Oracle. Kam d\u00ebgjuar se n\u00eb projekte t\u00eb tjera t\u00eb Sportmaster ka interes p\u00ebr testimin automatizuar dhe ndoshta do t\u00eb shkojm\u00eb atje.<\/li>\n<\/ol>\n

        <\/p>\n

        P\u00ebrfundimet<\/h2>\n

        \nLe t\u00eb p\u00ebrmbledhim. N\u00eb projektin e sistemit t\u00eb besnik\u00ebris\u00eb n\u00eb Sportmaster, ne arrit\u00ebm t\u00eb realizojm\u00eb nj\u00eb sistem t\u00eb testimit automatizuar. Baza e saj \u00ebsht\u00eb zgjidhja utPLSQL nga Steven Feuerstein. Rreth utPLSQL \u00ebsht\u00eb kodin e testeve automatike dhe modulet e tjera ndihm\u00ebse: moduli i ekzekutimit, moduli i gjenerimit t\u00eb t\u00eb dh\u00ebnave dhe t\u00eb tjera. Testet automatike ekzekutohen \u00e7do dit\u00eb dhe, m\u00eb e r\u00ebnd\u00ebsishmja, funksionojn\u00eb dhe sjellin p\u00ebrfitim. Ne jemi t\u00eb bindur se kemi filluar t\u00eb l\u00ebshojm\u00eb softuer m\u00eb t\u00eb cil\u00ebsis\u00eb s\u00eb lart\u00eb. Zgjidhja e marr\u00eb \u00ebsht\u00eb universale dhe mund t\u00eb aplikohet lirisht n\u00eb \u00e7do projekt ku \u00ebsht\u00eb e nevojshme t\u00eb organizohet testimi automatizuar n\u00eb DBMS Oracle.<\/p>\n

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

        Shkruani komente, n\u00ebse ka momentet q\u00eb duhet t\u00eb theksojn\u00eb n\u00eb t\u00eb ardhmen, ose pyetje q\u00eb k\u00ebrkojn\u00eb shpjegim.<\/i><\/p>\n

        Vet\u00ebm p\u00ebrdoruesit e regjistruar mund t\u00eb marrin pjes\u00eb n\u00eb anket\u00eb. Hyni<\/a><\/noindex>, ju lutemi.<\/p>\n

        A po shkruajm\u00eb m\u00eb tej rreth k\u00ebsaj?<\/h2>\n