{"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\u00ebsive 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. Ju keni detyr\u00ebn p\u00ebr t\u00eb zhvilluar nj\u00eb funksionalitet t\u00eb ri. Keni disa pun\u00eb nga paraardh\u00ebsit tuaj. N\u00ebse supozojm\u00eb se nuk keni asnj\u00eb detyrim moral, si do t\u00eb vepronit?<\/p>\n

M\u00eb s\u00eb shpeshti, t\u00eb gjitha punimet e vjetra harrohen dhe gjith\u00e7ka fillon nga fillimi. Askush nuk e p\u00eblqen t\u00eb p\u00ebrzihet me kodin e t\u00eb tjer\u00ebve, dhe n\u00ebse ka koh\u00eb, p\u00ebrse t\u00eb mos merresh me krijimin e nj\u00eb sistemi t\u00eb ri? Ky \u00ebsht\u00eb nj\u00eb qasje tipike, dhe n\u00eb shum\u00eb aspekte \u00ebsht\u00eb e sakt\u00eb. Por n\u00eb projektin ton\u00eb nuk vepruam k\u00ebshtu. N\u00eb themel t\u00eb sistemit t\u00eb ardhsh\u00ebm t\u00eb testimit automatizuar, ne vendos\u00ebm punimet mbi testet unitare n\u00eb utPLSQL nga paraardh\u00ebsit tan\u00eb, dhe m\u00eb pas filluam t\u00eb punojm\u00eb n\u00eb disa drejtime paralele.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Rind\u00ebrtimi i testeve t\u00eb vjetra unitare.<\/b> Me rind\u00ebrtimin kuptohet p\u00ebrshtatja e testeve sipas gjendjes aktuale t\u00eb sistemit t\u00eb besnik\u00ebris\u00eb dhe p\u00ebrshtatja e testeve sipas standardeve t\u00eb utPLSQL. <\/li>\n
  2. Zgjidhja e problemit t\u00eb kuptimit, \u00e7far\u00eb sakt\u00ebsisht, cilat metoda dhe procese, jan\u00eb mbuluar nga testet automatike. <\/b>Duhet ose ta mbani k\u00ebt\u00eb informacion n\u00eb mendje, ose t\u00eb nxirrni p\u00ebrfundime bazuar n\u00eb kodin e testeve automatike. Prandaj, ne vendos\u00ebm t\u00eb formulojm\u00eb nj\u00eb katalog. \u00c7do test automatik iu dha nj\u00eb kod unik mnemonik, kemi formuluar nj\u00eb p\u00ebrshkrim dhe kemi regjistruar konfigurimet (p.sh., n\u00eb cilat kushte duhet t\u00eb nis\u00eb, ose \u00e7far\u00eb duhet t\u00eb ndodh\u00eb n\u00ebse testi p\u00ebrfundonte me d\u00ebshtim). N\u00eb thelb, kemi plot\u00ebsuar metadat\u00ebn mbi testet automatike dhe i kemi vendosur k\u00ebto metadata n\u00eb tabelat standarde t\u00eb skem\u00ebs utPLSQL.<\/li>\n
  3. Definimi i strategjis\u00eb s\u00eb zgjerimit, pra, p\u00ebrzgjedhja e funksionalitetit q\u00eb do t\u00eb kontrollohet me an\u00eb t\u00eb testeve automatike.<\/b> Ne vendos\u00ebm t\u00eb q\u00ebndrojm\u00eb me v\u00ebmendje n\u00eb tre gj\u00ebra: p\u00ebrmir\u00ebsimet e reja t\u00eb sistemit, incidentet nga prodhimi dhe proceset ky\u00e7 t\u00eb sistemit. K\u00ebshtu, ne zhvillohemi paralelisht me l\u00ebshimin, duke siguruar nj\u00eb cil\u00ebsi m\u00eb t\u00eb lart\u00eb, duke zgjeruar p\u00ebrmasat e regresit dhe duke siguruar q\u00ebndrueshm\u00ebrin\u00eb e sistemit n\u00eb vendet kritike. Nj\u00eb nga k\u00ebto pika t\u00eb ngushta ishte procesi i shp\u00ebrndarjes s\u00eb zbritjeve dhe bonuseve n\u00eb fatur\u00eb.<\/li>\n
  4. Natyrisht, filluam t\u00eb zhvillojm\u00eb teste t\u00eb reja automatike. <\/b>Nj\u00eb nga detyrat e para t\u00eb l\u00ebshimit ishte vler\u00ebsimi i performanc\u00ebs s\u00eb mostrave t\u00eb paracaktuara t\u00eb sistemit t\u00eb besnik\u00ebris\u00eb. N\u00eb projektin ton\u00eb kemi nj\u00eb bllok me SQL t\u00eb ngurt\u00eb t\u00eb dh\u00ebna, t\u00eb cilat p\u00ebrzgjedhin klient\u00ebt sipas kushteve. P\u00ebr shembull, t\u00eb marrim nj\u00eb list\u00eb t\u00eb gjith\u00eb klient\u00ebve, blerja e fundit e t\u00eb cil\u00ebve ka qen\u00eb n\u00eb nj\u00eb qytet t\u00eb caktuar, ose list\u00ebn e klient\u00ebve, t\u00eb cil\u00ebt kan\u00eb nj\u00eb mesatare blerjeje m\u00eb t\u00eb lart\u00eb se nj\u00eb vler\u00eb t\u00eb caktuar. Duke shkruar teste automatike, ne verifikuam mostrave t\u00eb paracaktuara, regjistruam parametrat standard t\u00eb performanc\u00ebs dhe p\u00ebr m\u00eb tep\u00ebr kemi p\u00ebrfituar testi t\u00eb ngarkes\u00ebs.<\/li>\n
  5. Puna me testet automatike duhet t\u00eb jet\u00eb e p\u00ebrshtatshme<\/b>. Dy veprime kryesore realizohen m\u00eb shpesh: fillimi i testeve automatike dhe krijimi i t\u00eb dh\u00ebnave testuese. Keshtu n\u00eb sistemin ton\u00eb u krijuan dy module ndihm\u00ebse: moduli i nisjes dhe moduli i gjenerimit t\u00eb t\u00eb dh\u00ebnave.\n

    Moduli i nisjes paraqitet n\u00eb form\u00ebn e nj\u00eb procedure universale me nj\u00eb paramet\u00ebr tekstual hyr\u00ebs. Si paramet\u00ebr, mund t\u00eb kalosh mnemonic code t\u00eb testit automat, emrin e paket\u00ebs, emrin e testit, konfigurimin e testit automat ose nj\u00eb fjal\u00eb ky\u00e7e t\u00eb rezervuar. Procedura p\u00ebrzgjedh dhe nis t\u00eb gjitha testet automatike q\u00eb p\u00ebrmbushin kushtet.<\/p>\n

    Moduli i gjenerimit t\u00eb t\u00eb dh\u00ebnave paraqitet n\u00eb form\u00ebn e nj\u00eb pakete, 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, vlerat standarde jan\u00eb maksimumi plot\u00ebsuar, duke siguruar krijimin e objekteve me t\u00eb v\u00ebrtet\u00eb me nj\u00eb klikim. Dhe p\u00ebr leht\u00ebsin\u00eb e p\u00ebrdorimit jan\u00eb krijuar shabllon\u00ebt e t\u00eb dh\u00ebnave t\u00eb krijuara. P\u00ebr shembull, t\u00eb krijosh nj\u00eb klient t\u00eb nj\u00eb moshe t\u00eb caktuar me nj\u00eb telefon prov\u00eb dhe nj\u00eb blerje t\u00eb kryer.<\/li>\n

  6. Testet automatike duhet t\u00eb nisen dhe t\u00eb funksionojn\u00eb n\u00eb nj\u00eb koh\u00eb t\u00eb pranueshme p\u00ebr sistemin tuaj. <\/b>Prandaj, \u00ebsht\u00eb organizuar nj\u00eb nisje e p\u00ebrditshme n\u00eb mesnat\u00eb, mbi rezultatet e s\u00eb cil\u00ebs formohet nj\u00eb raport i t\u00eb dh\u00ebnave dhe d\u00ebrgohet gjith\u00eb ekipit t\u00eb zhvillimit p\u00ebrmes post\u00ebs korporative. Pas rikthimit t\u00eb testeve t\u00eb vjetra dhe krijimit t\u00eb t\u00eb rinjve, koha totale e pun\u00ebs ishte 30 minuta. Nj\u00eb performanc\u00eb e till\u00eb k\u00ebnaqi t\u00eb gjith\u00eb, pasi nisja kalonte n\u00eb koh\u00eb jopune.\n

    Por optimizimin e shpejt\u00ebsis\u00eb s\u00eb funksionimit duhej punuar. P\u00ebrdit\u00ebsimi i sistemit t\u00eb besnik\u00ebris\u00eb b\u00ebhet n\u00eb prodhim gjat\u00eb nat\u00ebs. Gjat\u00eb nj\u00eb prej l\u00ebshimeve, u b\u00ebn\u00eb ndryshime urgjente gjat\u00eb nat\u00ebs. Nj\u00eb pritje gjysm\u00eb ore p\u00ebr rezultatet e testeve automatike n\u00eb or\u00ebn tre t\u00eb m\u00ebngjesit nuk e b\u00ebnte t\u00eb lumtur personin p\u00ebrgjegj\u00ebs p\u00ebr l\u00ebshimin (p\u00ebrsh\u00ebndetje t\u00eb ngrohta p\u00ebr Aleksej Vasyukov!), dhe n\u00eb m\u00ebngjesin e ardhsh\u00ebm u than\u00eb shum\u00eb fjal\u00eb t\u00eb ngrohta p\u00ebr sistemin ton\u00eb. Por, pas analizave, u vendos nj\u00eb norm\u00eb pes\u00eb minut\u00ebshe p\u00ebr funksionimin.<\/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 paralele, fal\u00eb asaj q\u00eb ishte shum\u00eb e p\u00ebrshtatshme p\u00ebr arkitektur\u00ebn e sistemit ton\u00eb t\u00eb besnik\u00ebris\u00eb. Gjithashtu, ne braktis\u00ebm qasjen ku testi automatik nuk krijonte t\u00eb dh\u00ebna testuese p\u00ebr veten, por p\u00ebrpiqej t\u00eb gjej\u00eb 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 vendoset n\u00eb ambiente t\u00eb ndryshme.<\/b> N\u00eb fillim t\u00eb rrug\u00ebs pati p\u00ebrpjekje p\u00ebr t\u00eb shkruar skripte t\u00eb veta, por b\u00ebhet e qart\u00eb se instalimi automatizuar q\u00eb shkruhet vet\u00eb \u00ebsht\u00eb nj\u00eb tmerr i plot\u00eb, dhe ne iu drejtua zgjidhjeve industriale. Duke qen\u00eb se projekti ka shum\u00eb kod (fillimisht ne ruajm\u00eb kodin e testeve automatike) dhe shum\u00eb pak t\u00eb dh\u00ebna (t\u00eb dh\u00ebnat kryesore jan\u00eb metadat p\u00ebr testet automatike), zbatimi i Liquibase n\u00eb projekt ishte mjaft i thjesht\u00eb.\n

    Kjo \u00ebsht\u00eb nj\u00eb bibliotek\u00eb e pavarur nga baza e dh\u00ebnave me burim t\u00eb hapur p\u00ebr gjurmimin, menaxhimin dhe aplikimin e ndryshimeve t\u00eb skem\u00ebs s\u00eb baz\u00ebs s\u00eb dh\u00ebnave. Ajo kontrollohet p\u00ebrmes komandave n\u00eb linj\u00eb ose framework-e 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, i cili p\u00ebrb\u00ebhet nga ndryshime ose skripte q\u00eb duhen implementuar n\u00eb serverin e synuar, dhe skedar\u00eb menaxhues q\u00eb p\u00ebrcaktojn\u00eb se n\u00eb cil\u00ebn rend dhe me cilat parametra k\u00ebto ndryshime duhet t\u00eb instalohen. <\/p>\n

    N\u00eb nivelin e DBMS krijohet nj\u00eb tav\u00ebll speciale, n\u00eb t\u00eb cil\u00ebn Liquibase ruan logun e aplikimeve. \u00c7do ndryshim ka nj\u00eb hash t\u00eb llogaritur, i cili \u00e7do her\u00eb krahasohet midis projektit dhe gjendjes n\u00eb baz\u00eb. Fal\u00eb Liquibase, ne leht\u00ebsisht aplikojm\u00eb ndryshimet tona n\u00eb \u00e7do ambient. Testet automatike tani ekzekutohen n\u00eb ambientet testuese dhe t\u00eb l\u00ebshimit, si dhe n\u00eb kontejner\u00eb (ambientet 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 testeve unit. <\/p>\n

      \n
    1. Sigurisht, n\u00eb radh\u00eb t\u00eb par\u00eb, ne jemi t\u00eb bindur se kemi filluar t\u00eb zhvillojm\u00eb nj\u00eb softuer m\u00eb cil\u00ebsor. Testet automatike ekzekutohen \u00e7do dit\u00eb dhe \u00e7do l\u00ebshim gjejn\u00eb dhjet\u00ebra gabime. Dhe nj\u00eb pjes\u00eb e k\u00ebtyre gabimeve \u00ebsht\u00eb vet\u00ebm indirekt e lidhur me funksionalitetin q\u00eb ne v\u00ebrtet donim ta ndryshonim. Ka dyshime t\u00eb m\u00ebdha se k\u00ebto gabime ishin gjetur me testim manual. <\/li>\n
    2. Ekipi yn\u00eb ka fituar besim se funksionaliteti specifik punon si\u00e7 duhet\u2026 Kjo vlen ve\u00e7an\u00ebrisht p\u00ebr proceset tona kritike. P\u00ebr shembull, gjat\u00eb gjasht\u00eb muajve t\u00eb fundit nuk kemi pasur probleme me shp\u00ebrndarjen e zbritjeve dhe bonuseve n\u00eb kupon, megjith\u00ebse kemi pasur ndryshime \u00e7do l\u00ebshim, ndryshe nga periudhat e m\u00ebparshme kur ndonj\u00ebher\u00eb shfaqeshin gabime.<\/li>\n
    3. Na \u00ebsht\u00eb arritur t\u00eb reduktojm\u00eb numrin e iteracioneve t\u00eb testimit. Fal\u00eb faktit se testet automatike shkruhen p\u00ebr funksionalitetin e ri, kodit me cil\u00ebsi m\u00eb t\u00eb lart\u00eb i kalon analist\u00ebve dhe gjithashtu testeve, sepse ai tashm\u00eb \u00ebsht\u00eb verifikuar.<\/li>\n
    4. Pjesa e punimeve t\u00eb testimit automatizuar p\u00ebrdoret nga zhvilluesit. P\u00ebr shembull, t\u00eb dh\u00ebnat testuese n\u00eb kontejner\u00eb krijohen p\u00ebrmes modulit t\u00eb gjenerimit t\u00eb objekteve.<\/li>\n
    5. \u00cbsht\u00eb e r\u00ebnd\u00ebsishme q\u00eb ne kemi krijuar nj\u00eb \"pranimin\" t\u00eb sistemit t\u00eb testimit automatizuar nga ana e zhvilluesve. Ka kuptim q\u00eb kjo \u00ebsht\u00eb e r\u00ebnd\u00ebsishme dhe e dobishme. Dhe nga p\u00ebrvoja ime mund t\u00eb them se kjo nuk \u00ebsht\u00eb ashtu. Testet automatike duhet t\u00eb shkruhen, ato duhet t\u00eb mbahen dhe t\u00eb zhvillohen, t\u00eb analizohet rezultatet, dhe shpesh k\u00ebto harxhime kohe thjesht nuk ia vlen. M\u00eb e leht\u00eb \u00ebsht\u00eb t\u00eb shkosh n\u00eb prodhim dhe atje t\u00eb merresh me problemet. Mir\u00ebpo, k\u00ebtu zhvilluesit radhiten n\u00eb radh\u00eb dhe k\u00ebrkojn\u00eb t\u00eb mbulohet funksionaliteti i tyre me teste automatike.<\/li>\n<\/ol>\n

      \u00c7far\u00eb pason<\/h2>\n

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

      Sigurisht, nd\u00ebrsa sistemi i besnik\u00ebris\u00eb s\u00eb Sportmaster vazhdon t\u00eb jet\u00eb i gjall\u00eb dhe t\u00eb zhvillohet, \u00ebsht\u00eb gjithashtu e mundur t\u00eb zhvillosh praktisht pafund\u00ebsisht testet automatike. Prandaj, drejtimi kryesor i zhvillimit \u00ebsht\u00eb zgjerimi i zon\u00ebs s\u00eb mbulimit.<\/p>\n

      Me rritjen e numrit t\u00eb testeve automatike, koha totale e funksionimit t\u00eb tyre do t\u00eb rritet pa ndalur, dhe ne do t\u00eb duhet t\u00eb kthehemi p\u00ebrs\u00ebri te \u00e7\u00ebshtja e performanc\u00ebs. M\u00eb s\u00eb shumti, zgjidhja 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. N\u00ebse flasim p\u00ebr di\u00e7ka m\u00eb t\u00eb nd\u00ebrlikuar, le t\u00eb theksojm\u00eb k\u00ebt\u00eb:<\/p>\n

        \n
      1. Aktualisht, menaxhimi i testeve automatike kryhet n\u00eb nivelin e DBMS, pra, njohurit\u00eb e PL\/SQL jan\u00eb t\u00eb nevojshme p\u00ebr nj\u00eb funksionim t\u00eb suksessh\u00ebm. N\u00ebse \u00ebsht\u00eb e nevojshme, menaxhimi i sistemit (p.sh., ekzekutimi i testimeve ose krijimi i metadatan\u00ebve) mund t\u00eb nxirret n\u00eb ndonj\u00eb panel administrativ, duke p\u00ebrdorur Jenkins ose di\u00e7ka t\u00eb ngjashme.<\/li>\n
      2. T\u00eb gjith\u00eb e duan matjen sasiore dhe cil\u00ebsore. P\u00ebr testimin automatizuar, nj\u00eb indikator universale \u00ebsht\u00eb Code Coverage ose metrika e mbulimit t\u00eb kodit. N\u00ebp\u00ebrmjet k\u00ebtij treguesi, ne mund t\u00eb p\u00ebrcaktojm\u00eb se sa p\u00ebrqind e kodit t\u00eb sistemit ton\u00eb n\u00eb testim mbulohet nga testet automatike. Duke filluar nga versioni 12.2, Oracle ofron mund\u00ebsi p\u00ebr llogaritjen e k\u00ebsaj metri dhe rekomandon p\u00ebrdorimin e paket\u00ebs standard 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 m\u00eb e p\u00ebrshtatshme p\u00ebr vler\u00ebsimin e mbulimit. N\u00eb projektin tim t\u00eb kaluar (projekti nuk \u00ebsht\u00eb Sportmaster), dhe kjo ka ndodhur. Pas nj\u00eb viti pune me testet automatike, drejtoria vendosi t\u00eb vler\u00ebsonte se sa p\u00ebrqind e kodit mbulojm\u00eb. Me mbulimin m\u00eb t\u00eb madh se 1%, drejtoria do t\u00eb ishte e k\u00ebnaqur. Ne, zhvilluesit, priteshim nj\u00eb rezultat rreth 10%. Kemi lidhur code coverage, mas\u00ebm, dhe mor\u00ebm 20%. Me g\u00ebzim shkuam p\u00ebr nj\u00eb shp\u00ebrblim, por si u shkuam atje dhe \u00e7far\u00eb ndodhi m\u00eb pas \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, dhe ne nuk do t\u00eb hasim nj\u00eb s\u00ebr\u00eb problemesh. <\/li>\n
      4. Dhe, natyrisht, sistemi yn\u00eb p\u00ebr testimin e automatizuar mund t\u00eb aplikohet n\u00eb nj\u00eb projekt tjet\u00ebr. Zgjidhja q\u00eb kemi arritur \u00ebsht\u00eb universale dhe k\u00ebrkon vet\u00ebm 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 te ata.<\/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 kemi arritur t\u00eb realizojm\u00eb nj\u00eb sistem t\u00eb testimit t\u00eb automatizuar. Baza e saj \u00ebsht\u00eb zgjidhja utPLSQL nga Steven Feierstain. Rreth utPLSQL \u00ebsht\u00eb kodi i testeve automatizuese dhe module t\u00eb ndihm\u00ebs t\u00eb shkruara vet\u00eb: moduli i nisjes, moduli i gjenerimit t\u00eb t\u00eb dh\u00ebnave dhe t\u00eb tjera. Testet automatizuese kryhen \u00e7do dit\u00eb dhe, m\u00eb e r\u00ebnd\u00ebsishmja, funksionojn\u00eb dhe sjellin p\u00ebrfitim. Jemi t\u00eb bindur se kemi filluar t\u00eb l\u00ebshojm\u00eb softuer me cil\u00ebsi m\u00eb t\u00eb lart\u00eb. N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, zgjidhja e marr\u00eb \u00ebsht\u00eb universale dhe mund t\u00eb aplikohet lirsh\u00ebm n\u00eb \u00e7do projekt ku nevojitet organizimi i testimit t\u00eb automatizuar n\u00eb DBMS Oracle.<\/p>\n

        P.S. Ky artikull doli t\u00eb mos jet\u00eb shum\u00eb konkret: ka shum\u00eb tekst dhe praktikisht nuk ka shembuj teknik\u00eb. N\u00ebse tematik\u00ebn globale e gjen interesante, jemi t\u00eb gatsh\u00ebm ta vazhdojm\u00eb dhe t\u00eb kthehemi me nj\u00eb vazhdim, ku do t\u00eb tregojm\u00eb se \u00e7far\u00eb ka ndryshuar n\u00eb gjasht\u00eb muajt e fundit dhe do t\u00eb sjellim shembuj kodi.<\/p>\n

        Shkruani komente, n\u00ebse ka aspekte, n\u00eb t\u00eb cilat duhet t\u00eb theksojm\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 lutem.<\/p>\n

        A po shkruajm\u00eb m\u00eb tej p\u00ebr k\u00ebt\u00eb?<\/h2>\n