DBMS တွင် ယူနစ်စစ်ဆေးမှုများ - Sportmaster တွင် ကျွန်ုပ်တို့ မည်သို့လုပ်ဆောင်သည်၊ အပိုင်းနှစ်

ပထမပိုင်း - ဒီမှာ.

အခြေအနေတစ်ခုကို စိတ်ကူးကြည့်ပါ။ လုပ်ဆောင်ချက်အသစ်များ ဖော်ထုတ်ရန် သင်လုပ်ဆောင်ရမည့်တာဝန်နှင့် ရင်ဆိုင်နေရသည်။ မင်းအရင်က မင်းအတွေ့အကြုံတွေရှိတယ်။ မင်းမှာ ကိုယ်ကျင့်တရားတာဝန်မရှိဘူးလို့ ယူဆရင် မင်းဘာလုပ်မလဲ။

များသောအားဖြင့်၊ တိုးတက်မှုအားလုံးကို မေ့ပျောက်ပြီး အရာအားလုံးက ပြန်စတယ်။ ဘယ်သူကမှ အခြားသူရဲ့ကုဒ်ကို တူးဆွရတာကို မကြိုက်ကြသလို သင့်မှာ အချိန်ရှိတယ်ဆိုရင် ဘာကြောင့် သင့်ကိုယ်ပိုင်စနစ်ကို စတင်မဖန်တီးတာလဲ။ ဤသည်မှာ ပုံမှန်ချဉ်းကပ်နည်းဖြစ်ပြီး များစွာသောအချက်မှာ မှန်ကန်ပါသည်။ ဒါပေမယ့် ကျွန်တော်တို့ရဲ့ ပရောဂျက်မှာ ကွဲပြားစွာ လုပ်ဆောင်ခဲ့ပါတယ်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ရှေ့ဆက်သူများထံမှ utPLSQL တွင် ယူနစ်စမ်းသပ်မှုများတွင် တိုးတက်မှုအပေါ် အနာဂတ်အလိုအလျောက်စမ်းသပ်ခြင်းစနစ်အား အခြေခံပြီး အပြိုင်လမ်းကြောင်းများစွာတွင် လုပ်ဆောင်သွားခဲ့သည်။

1. ယူနစ်စမ်းသပ်မှုဟောင်းများကို ပြန်လည်ရယူခြင်း။ ပြန်လည်ရယူခြင်းဆိုသည်မှာ သစ္စာစောင့်သိမှုစနစ်၏ တည်ဆဲအခြေအနေနှင့် စမ်းသပ်မှုများကို utPLSQL စံနှုန်းများနှင့် လိုက်လျောညီထွေဖြစ်စေသော စစ်ဆေးမှုများကို ဆိုလိုသည်။
2. ပြဿနာကို နားလည်မှုဖြင့် ဖြေရှင်းခြင်း၊ မည်သည့်နည်းလမ်းများနှင့် လုပ်ငန်းစဉ်များ အတိအကျဖြင့် ကျွန်ုပ်တို့သည် autotests ဖြင့် အကျုံးဝင်ပါသည်။ ဤအချက်အလက်ကို သင့်ခေါင်းထဲတွင် သိမ်းဆည်းထားရမည် သို့မဟုတ် autotest ၏ကုဒ်အပေါ် တိုက်ရိုက်အခြေခံ၍ ကောက်ချက်ဆွဲရမည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ကတ်တလောက်တစ်ခုကို ဖန်တီးရန် ဆုံးဖြတ်ခဲ့သည်။ ကျွန်ုပ်တို့သည် autotest တစ်ခုစီတွင် ထူးခြားသော mnemonic ကုဒ်တစ်ခုကို ပေးအပ်ခဲ့ပြီး ဖော်ပြချက်တစ်ခု ဖန်တီးကာ ဆက်တင်များကို ပြင်ဆင်ခဲ့သည် (ဥပမာ၊ ၎င်းကို မည်သည့်အခြေအနေအောက်တွင် လုပ်ဆောင်သင့်သည်၊ သို့မဟုတ် စမ်းသပ်မှု မအောင်မြင်ပါက ဘာဖြစ်နိုင်သည်)။ အနှစ်သာရအားဖြင့်၊ ကျွန်ုပ်တို့သည် autotests များအကြောင်း metadata ကိုဖြည့်ပြီး utPLSQL schema ၏စံဇယားများတွင် ဤ metadata ကိုထည့်ထားသည်။
3. ချဲ့ထွင်မှုဗျူဟာ အဓိပ္ပါယ်ဖွင့်ဆိုချက်၊ ဥပမာ၊ autotests ဖြင့်အတည်ပြုခြင်းခံရသောလုပ်ဆောင်နိုင်စွမ်းရွေးချယ်မှု။ ကျွန်ုပ်တို့သည် စနစ်အတွက် တိုးတက်မှုအသစ်များ၊ ထုတ်လုပ်မှုမှ အဖြစ်အပျက်များနှင့် စနစ်၏ အဓိကလုပ်ငန်းစဉ်များကို အာရုံစိုက်ရန် ဆုံးဖြတ်ခဲ့သည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ၎င်း၏ပိုမိုမြင့်မားသောအရည်အသွေးကိုသေချာစေကာ၊ ဆုတ်ယုတ်မှု၏နယ်ပယ်ကိုတစ်ပြိုင်နက်ချဲ့ထွင်ကာ အရေးကြီးသောနေရာများတွင် စနစ်၏ယုံကြည်စိတ်ချရမှုကိုသေချာစေသောလွှတ်ပေးမှုနှင့်အပြိုင် ကျွန်ုပ်တို့လုပ်ဆောင်ပါသည်။ ပထမဆုံးသော ပိတ်ဆို့မှုမှာ လျှော့စျေးနှင့် ဘောနပ်စ်များကို ချက်လက်မှတ်ဖြင့် ဖြန့်ဝေခြင်းလုပ်ငန်းစဉ်ဖြစ်သည်။
4. ပုံမှန်အားဖြင့်၊ ကျွန်ုပ်တို့သည် autotest အသစ်များကို စတင်တီထွင်ခဲ့သည်။ ပထမဆုံးထုတ်လွှတ်သည့်တာဝန်များထဲမှတစ်ခုမှာ သစ္စာစောင့်သိမှုစနစ်၏ ကြိုတင်သတ်မှတ်ထားသောနမူနာများ၏ စွမ်းဆောင်ရည်ကို အကဲဖြတ်ရန်ဖြစ်သည်။ ကျွန်ုပ်တို့၏ပရောဂျက်တွင် အခြေအနေများအလိုက် ဖောက်သည်များကို ရွေးချယ်သည့် တင်းကျပ်စွာ ပြင်ဆင်ထားသော sql queries ပိတ်ဆို့ထားပါသည်။ ဥပမာအားဖြင့်၊ သီးခြားမြို့တစ်ခုတွင် နောက်ဆုံးဝယ်ယူခဲ့သည့် ဝယ်ယူသူအားလုံး၏စာရင်းကို ရယူပါ၊ သို့မဟုတ် ပျမ်းမျှဝယ်ယူမှုပမာဏသည် သတ်မှတ်ထားသောတန်ဖိုးထက်ကျော်လွန်သော ဝယ်ယူသူများစာရင်းကို ရယူပါ။ autotests များကိုရေးသားပြီး၊ ကျွန်ုပ်တို့သည် ကြိုတင်သတ်မှတ်ထားသောနမူနာများ၊ ပုံသေစံနှုန်းစွမ်းဆောင်ရည်ဘောင်များကို စစ်ဆေးခဲ့ပြီး ထို့အပြင် ကျွန်ုပ်တို့သည် load testing ကိုရရှိခဲ့ပါသည်။
5. autotests နှင့်အလုပ်လုပ်ရန်အဆင်ပြေသင့်သည်။. အသုံးအများဆုံးလုပ်ဆောင်ချက်နှစ်ခုမှာ အလိုအလျောက်စမ်းသပ်မှုများ လုပ်ဆောင်နေပြီး စမ်းသပ်မှုဒေတာထုတ်ပေးခြင်း ဖြစ်သည်။ ဤသည်မှာ ကျွန်ုပ်တို့၏စနစ်တွင် အရန် module နှစ်ခုပေါ်လာပုံဖြစ်သည်- launch module နှင့် data generation module တို့ဖြစ်သည်။

   လောင်ချာအား ထည့်သွင်းသည့် စာသားပါရာမီတာတစ်ခုဖြင့် ယေဘုယျလုပ်ငန်းစဉ်တစ်ခုအဖြစ် ကိုယ်စားပြုသည်။ ကန့်သတ်ချက်တစ်ခုအနေဖြင့် သင်သည် အလိုအလျောက်စမ်းသပ် mnemonic ကုဒ်၊ ပက်ကေ့ဂျ်အမည်၊ စမ်းသပ်မှုအမည်၊ အလိုအလျောက်စမ်းသပ်မှု ဆက်တင် သို့မဟုတ် သီးသန့်သော့ချက်စကားလုံးကို သင်ဖြတ်သန်းနိုင်သည်။ လုပ်ထုံးလုပ်နည်းသည် အခြေအနေများနှင့် ကိုက်ညီသော autotest အားလုံးကို ရွေးချယ်ပြီး လုပ်ဆောင်သည်။

   ဒေတာထုတ်လုပ်သည့် မော်ဂျူးကို အထုပ်တစ်ခုအဖြစ် တင်ပြထားပြီး၊ စမ်းသပ်မှုအောက်တွင် စနစ်တစ်ခုစီ၏ အရာဝတ္တုတစ်ခု (ဒေတာဘေ့စ်ရှိ ဇယားတစ်ခု) အတွက် ထိုနေရာတွင် ဒေတာထည့်သွင်းသည့် အထူးလုပ်ထုံးလုပ်နည်းတစ်ခုကို ဖန်တီးထားသည်။ ဤလုပ်ထုံးလုပ်နည်းတွင်၊ ပုံသေတန်ဖိုးများကို အမြင့်ဆုံးအထိ ဖြည့်ထားပြီး၊ လက်ချောင်းဖြင့် နှိပ်လိုက်ရုံဖြင့် အရာဝတ္ထုများ ဖန်တီးမှုကို သေချာစေသည်။ အသုံးပြုရလွယ်ကူစေရန်အတွက် ထုတ်လုပ်ထားသောဒေတာအတွက် နမူနာပုံစံများကို ဖန်တီးခဲ့သည်။ ဥပမာအားဖြင့်၊ စမ်းသပ်ဖုန်းနှင့် ပြီးပြည့်စုံသော ဝယ်ယူမှုဖြင့် သတ်မှတ်ထားသော အသက်အရွယ်ရှိ သုံးစွဲသူတစ်ဦးကို ဖန်တီးပါ။

6. Autotests များသည် သင့်စနစ်အတွက် သင့်လျော်သောအချိန်တစ်ခုအတွင်း လုပ်ဆောင်သင့်ပါသည်။ ထို့ကြောင့်၊ ရလဒ်များဆိုင်ရာ အစီရင်ခံစာကို ထုတ်ပေးပြီး ကော်ပိုရိတ်မေးလ်ဖြင့် ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့တစ်ခုလုံးထံ ပေးပို့သည့် ရလဒ်များအပေါ် အခြေခံ၍ နေ့စဉ်ညတွင် လွှတ်တင်ရန် စီစဉ်ခဲ့သည်။ အလိုအလျောက်စမ်းသပ်မှုများ အဟောင်းများကို ပြန်လည်ရယူပြီး အသစ်များကို ဖန်တီးပြီးနောက် စုစုပေါင်း လုပ်ဆောင်ချိန်သည် မိနစ် 30 ဖြစ်သည်။ မိတ်ဆက်ပွဲသည် ရုံးချိန်အတွင်းတွင် ပြုလုပ်ခဲ့သောကြောင့် လူတိုင်းနှင့် သင့်တော်ပါသည်။

   ဒါပေမယ့် အလုပ်ရဲ့ အရှိန်ကို အကောင်းဆုံးဖြစ်အောင် လုပ်ရမယ်။ ထုတ်လုပ်ရေးသစ္စာစောင့်သိမှုစနစ်ကို ညအချိန်တွင် အပ်ဒိတ်လုပ်ထားသည်။ ထုတ်ဝေမှုတစ်ခု၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့်၊ ကျွန်ုပ်တို့သည် ညဘက်တွင် အပြောင်းအလဲများကို အရေးတကြီး ပြုလုပ်ရမည်ဖြစ်ပါသည်။ နံနက်သုံးနာရီတွင် autotest ရလဒ်ကိုစောင့်မျှော်နေသည့် နာရီဝက်ကြာသည် (Alexei Vasyukov) အား စိတ်အားထက်သန်စွာ နှုတ်ခွန်းဆက်စကားမဖြစ်ခဲ့ဘဲ၊ နောက်တစ်နေ့နံနက်တွင် ကျွန်ုပ်တို့၏စနစ်ဆီသို့ နွေးထွေးသောစကားများစွာကို ပြောခဲ့ပါသည်။ ဒါပေမယ့် ရလဒ်အနေနဲ့ အလုပ်အတွက် ၅ မိနစ်စာ စံနှုန်းတစ်ခု သတ်မှတ်ခဲ့ပါတယ်။

   စွမ်းဆောင်ရည်ကို အရှိန်မြှင့်ရန်အတွက် ကျွန်ုပ်တို့သည် နည်းလမ်းနှစ်ခုကို အသုံးပြုခဲ့သည်- ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏သစ္စာစောင့်သိမှုစနစ်၏ တည်ဆောက်ပုံကြောင့် အလွန်အဆင်ပြေသောကြောင့် ၎င်းသည် အပြိုင်အဆက်သုံးခုတွင် autotest များကို စတင်လုပ်ဆောင်ပါသည်။ ပြီးတော့ autotest က သူ့ဟာသူအတွက် စမ်းသပ်မှုဒေတာကို မဖန်တီးပေမယ့် စနစ်ထဲမှာ သင့်လျော်တဲ့အရာကို ရှာဖို့ကြိုးစားတဲ့အခါ ချဉ်းကပ်မှုကို စွန့်လွှတ်လိုက်တယ်။ ပြောင်းလဲမှုများပြုလုပ်ပြီးနောက် စုစုပေါင်းလည်ပတ်ချိန်ကို 3-4 မိနစ်သို့ လျှော့ချခဲ့သည်။

7. autotests ပါသော ပရောဂျက်တစ်ခုသည် အမျိုးမျိုးသောရပ်တည်ချက်တွင် အသုံးချနိုင်သင့်သည်။ ခရီးအစတွင်၊ ကျွန်ုပ်တို့၏ကိုယ်ပိုင် batch ဖိုင်များကိုရေးရန် ကြိုးပမ်းမှုများရှိခဲ့သော်လည်း၊ ကိုယ်တိုင်ရေးထားသော အလိုအလျောက်ထည့်သွင်းခြင်းသည် ထိတ်လန့်စရာဖြစ်ပြီး ပြီးပြည့်စုံသော စက်မှုဖြေရှင်းချက်ဆီသို့ လှည့်သွားကြောင်း ထင်ရှားလာပါသည်။ ပရောဂျက်တွင် တိုက်ရိုက်ကုဒ်များစွာပါရှိသောကြောင့် (ပထမအချက်အနေဖြင့် ကျွန်ုပ်တို့သည် autotests ၏ကုဒ်ကို သိမ်းဆည်းထားသည်) နှင့် ဒေတာအနည်းငယ်သာရှိသည် (အဓိကဒေတာမှာ autotests နှင့်ပတ်သက်သော metadata) ဖြစ်သောကြောင့် ၎င်းတွင် ပေါင်းစည်းရန် အလွန်လွယ်ကူသွားပါသည်။ Liquibase ပရောဂျက်။

   ၎င်းသည် database schema အပြောင်းအလဲများကို ခြေရာခံခြင်း၊ စီမံခန့်ခွဲခြင်းနှင့် အသုံးပြုခြင်းအတွက် open source ဒေတာဘေ့စ် သီးခြားစာကြည့်တိုက်တစ်ခုဖြစ်သည်။ Apache Maven ကဲ့သို့ command line သို့မဟုတ် framework များမှ စီမံခန့်ခွဲသည်။ Liquibase ၏လည်ပတ်မှုနိယာမသည်အတော်လေးရိုးရှင်းသည်။ ကျွန်ုပ်တို့တွင် ပစ်မှတ်ဆာဗာပေါ်သို့ လှိမ့်တင်ရန် လိုအပ်သည့် အပြောင်းအလဲများ သို့မဟုတ် script များပါ၀င်သည့် နည်းလမ်းဖြင့် စီစဉ်ဖွဲ့စည်းထားသော ပရောဂျက်တစ်ခုရှိပြီး မည်သည့်အစီအစဉ်နှင့် ဤအပြောင်းအလဲများကို ထည့်သွင်းသင့်သည်ကို ဆုံးဖြတ်သည့် ဖိုင်များကို ထိန်းချုပ်ပါသည်။

   DBMS အဆင့်တွင် Liquibase သည် rollback မှတ်တမ်းကို သိမ်းဆည်းထားသည့် အထူးဇယားတစ်ခုကို ဖန်တီးထားသည်။ ပြောင်းလဲမှုတစ်ခုစီတွင် ပရောဂျက်နှင့် ဒေတာဘေ့စ်ရှိ အခြေအနေကြားရှိ အချိန်တိုင်းကို နှိုင်းယှဉ်ထားသည့် တွက်ချက်ထားသော hash တစ်ခုရှိသည်။ Liquibase ၏ကျေးဇူးကြောင့်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏စနစ်အား မည်သည့်ဆားကစ်သို့မဆို အပြောင်းအလဲများကို အလွယ်တကူ ထုတ်ပေးနိုင်သည်။ ယခုအခါ Autotests များကို စမ်းသပ်ခြင်းနှင့် ထုတ်လွှတ်သည့် ဆားကစ်များအပြင် ကွန်တိန်နာများ (ကိုယ်ရေးကိုယ်တာ ဆော့ဖ်ဝဲအင်ဂျင်နီယာ ဆားကစ်များ) ပေါ်တွင် လုပ်ဆောင်နေပြီဖြစ်သည်။

ထို့ကြောင့် ကျွန်ုပ်တို့၏ ယူနစ်စမ်းသပ်မှုစနစ်ကို ကျင့်သုံးခြင်း၏ ရလဒ်များကို ဆွေးနွေးကြပါစို့။

1. ဟုတ်ပါတယ်၊ ပထမဆုံးအနေနဲ့၊ ပိုမိုကောင်းမွန်တဲ့ ဆော့ဖ်ဝဲလ်ကို စတင်တီထွင်နေပြီလို့ ယုံကြည်ပါတယ်။ Autotests များသည် နေ့စဥ်လုပ်ဆောင်ပြီး ထွက်ရှိတိုင်း bug ဒါဇင်များစွာကို ရှာတွေ့သည်။ ထို့အပြင်၊ အချို့သောအမှားများသည် ကျွန်ုပ်တို့အမှန်တကယ်ပြောင်းလဲလိုသောလုပ်ဆောင်နိုင်စွမ်းနှင့်သာ သွယ်ဝိုက်ဆက်စပ်နေပါသည်။ ဤအမှားများကို ကိုယ်တိုင်စမ်းသပ်ခြင်းဖြင့် တွေ့ရှိကြောင်း ပြင်းထန်သောသံသယများရှိပါသည်။
2. တိကျသောလုပ်ဆောင်နိုင်စွမ်းများ မှန်ကန်စွာအလုပ်လုပ်ကြောင်း အဖွဲ့မှယုံကြည်မှုရရှိခဲ့ပါသည်... ပထမအချက်မှာ၊ ၎င်းသည် ကျွန်ုပ်တို့၏အရေးကြီးသောလုပ်ငန်းစဉ်များနှင့်သက်ဆိုင်ပါသည်။ ဥပမာအားဖြင့်၊ ပြီးခဲ့သောခြောက်လအတွင်း၊ ယခင်ကာလများတွင် အကြိမ်ရေအနည်းငယ်ဖြင့် အမှားအယွင်းများဖြစ်ပေါ်ခဲ့သော်လည်း၊ ထုတ်ဝေမှုတိုင်းတွင် အပြောင်းအလဲများပြုလုပ်ထားသော်လည်း စစ်ဆေးခြင်းဖြင့် လျှော့စျေးနှင့် ဘောနပ်စ်များကို ဖြန့်ဖြူးရာတွင် ပြဿနာမရှိခဲ့ပါ။
3. စမ်းသပ်မှုအကြိမ်ရေကို လျှော့ချနိုင်ခဲ့သည်။ လုပ်ဆောင်ချက်အသစ်အတွက် autotest များကို ရေးထားသောကြောင့်၊ လေ့လာသူများနှင့် အချိန်ပိုင်းစမ်းသပ်သူများသည် အရည်အသွေးပိုမြင့်သောကုဒ်တစ်ခုကို ရရှိသောကြောင့်၊ စိစစ်ပြီးဖြစ်ပါသည်။
4. အလိုအလျောက်စမ်းသပ်ခြင်း၏ တိုးတက်မှုတစ်စိတ်တစ်ပိုင်းကို ဆော့ဖ်ဝဲအင်ဂျင်နီယာများက အသုံးပြုသည်။ ဥပမာအားဖြင့်၊ ကွန်တိန်နာများပေါ်ရှိ စမ်းသပ်ဒေတာကို အရာဝတ္ထုဖန်တီးမှု မော်ဂျူးကို အသုံးပြု၍ ဖန်တီးထားသည်။
5. ဆော့ဖ်ဝဲရေးသားသူများမှ အလိုအလျောက်စမ်းသပ်မှုစနစ်၏ "လက်ခံမှု" ကို တီထွင်ထားရန် အရေးကြီးပါသည်။ ဒါက အရေးကြီးပြီး အသုံးဝင်တယ်ဆိုတာ နားလည်မှုရှိပါတယ်။ ငါ့ကိုယ်ပိုင် အတွေ့အကြုံအရတော့ ဒါက ဝေးကွာတယ်လို့ ပြောလို့ရတယ်။ Autotest များကို ရေးမှတ်ရန် လိုအပ်သည်၊ ၎င်းတို့ကို ထိန်းသိမ်းရန်နှင့် တီထွင်ရန် လိုအပ်သည်၊ ရလဒ်များကို ပိုင်းခြားစိတ်ဖြာကာ၊ ဤအချိန်ကုန်ကျစရိတ်များသည် မကြာခဏ မထိုက်တန်ပါ။ ထုတ်လုပ်ရေးသို့သွား၍ ထိုပြဿနာများကို ကိုင်တွယ်ဖြေရှင်းရန် ပိုမိုလွယ်ကူသည်။ ကျွန်ုပ်တို့နိုင်ငံတွင်၊ developer များသည် တန်းစီပြီး ၎င်းတို့၏လုပ်ဆောင်နိုင်စွမ်းကို အလိုအလျောက်စမ်းသပ်မှုများဖြင့် ဖုံးအုပ်ရန် တောင်းဆိုကြသည်။

နောက်တစ်ခုကဘာလဲ

အလိုအလျောက်စမ်းသပ်ခြင်းပရောဂျက်၏ ဖွံ့ဖြိုးတိုးတက်ရေးအစီအစဥ်အကြောင်း ဆွေးနွေးကြပါစို့။

ဟုတ်ပါတယ်၊ Sportmaster သစ္စာစောင့်သိမှုစနစ်က အသက်ရှင်နေပြီး ဆက်လက်ဖွံ့ဖြိုးနေသရွေ့၊ autotests တွေကိုလည်း အဆုံးမရှိနီးပါး တီထွင်နိုင်မှာပါ။ ထို့ကြောင့် ဖွံ့ဖြိုးတိုးတက်ရေး၏ အဓိက ဦးတည်ချက်မှာ လွှမ်းခြုံဧရိယာ ချဲ့ထွင်ရေးဖြစ်သည်။

အော်တိုစမ်းသပ်မှု အရေအတွက် တိုးလာသည်နှင့်အမျှ ၎င်းတို့၏ အလုပ်စုစုပေါင်း၏ အချိန်သည် တဖြည်းဖြည်း တိုးလာမည်ဖြစ်ပြီး ကျွန်ုပ်တို့သည် စွမ်းဆောင်ရည်ဆိုင်ရာ ပြဿနာကို တစ်ဖန်ပြန်သွားရမည်ဖြစ်ပါသည်။ ဖြစ်နိုင်ချေအများစုမှာ၊ ဖြေရှင်းချက်မှာ parallel threads အရေအတွက်ကို တိုးမြှင့်ရန်ဖြစ်သည်။

ဒါပေမယ့် ဒါတွေက သိသာထင်ရှားတဲ့ ဖွံ့ဖြိုးတိုးတက်မှုနည်းလမ်းတွေပါ။ ပို၍အသေးအဖွဲမဟုတ်သောအရာကို ကျွန်ုပ်တို့ပြောဆိုပါက၊ အောက်ပါတို့ကို မီးမောင်းထိုးပြပါမည်။

1. ယခုအခါ အလိုအလျောက်စမ်းသပ်မှုများကို DBMS အဆင့်တွင် စီမံခန့်ခွဲထားပါသည်။ အောင်မြင်သောအလုပ်အတွက် PL/SQL အသိပညာလိုအပ်သည်။ လိုအပ်ပါက၊ စနစ်စီမံခန့်ခွဲမှု (ဥပမာ၊ စတင်ခြင်း သို့မဟုတ် မက်တာဒေတာဖန်တီးခြင်း) ကို Jenkins သို့မဟုတ် အလားတူတစ်ခုခုကို အသုံးပြု၍ စီမံခန့်ခွဲသူအကန့်အမျိုးအစားအချို့မှ ဖယ်ရှားနိုင်သည်။
2. လူတိုင်းသည် အရေအတွက်နှင့် အရည်အသွေးညွှန်းကိန်းများကို နှစ်သက်ကြသည်။ အလိုအလျောက်စမ်းသပ်ခြင်းအတွက်၊ ထိုကဲ့သို့သော universal indicator သည် Code Coverage သို့မဟုတ် code coverage metric ဖြစ်သည်။ ဤညွှန်ကိန်းကိုအသုံးပြု၍ စမ်းသပ်မှုအောက်တွင် ကျွန်ုပ်တို့၏စနစ်၏ကုဒ်၏ရာခိုင်နှုန်းသည် autotests ဖြင့် အကျုံးဝင်ကြောင်း ဆုံးဖြတ်နိုင်ပါသည်။ ဗားရှင်း 12.2 မှစတင်၍ Oracle သည် ဤမက်ထရစ်ကို တွက်ချက်နိုင်စွမ်းရှိပြီး ပုံမှန် DBMS_PLSQL_CODE_COVERAGE ပက်ကေ့ဂျ်ကို အသုံးပြုရန် အကြံပြုထားသည်။

   ကျွန်ုပ်တို့၏ အလိုအလျောက်စမ်းသပ်မှုစနစ်သည် တစ်နှစ်ကျော်သာရှိသေးပြီး အကျုံးဝင်မှုကို အကဲဖြတ်ရန် အချိန်တန်ပါသည်။ ငါ၏နောက်ဆုံးပရောဂျက် (Sportmaster မှမဟုတ်သောပရောဂျက်) တွင်ဤဖြစ်ပျက်ခဲ့သည်။ autotests များကို လုပ်ဆောင်ပြီး တစ်နှစ်အကြာတွင် စီမံခန့်ခွဲမှုသည် ကျွန်ုပ်တို့ လွှမ်းခြုံထားသော ကုဒ်၏ ရာခိုင်နှုန်းကို အကဲဖြတ်ရန် တာဝန်ကို သတ်မှတ်ပေးပါသည်။ 1% ထက်ပိုသောလွှမ်းခြုံမှုနှင့်အတူ, စီမံခန့်ခွဲသူပျော်ရွှင်လိမ့်မည်။ ကျွန်ုပ်တို့၊ developer များသည် 10% ခန့်ရလဒ်ကိုမျှော်လင့်ထားသည်။ ကျွန်ုပ်တို့သည် ကုဒ်လွှမ်းခြုံမှုကို ဖောက်ထွင်းပြီး တိုင်းတာပြီး 20% ရခဲ့သည်။ ဂုဏ်ပြုရန်၊ ကျွန်ုပ်တို့သည် ဆုအတွက်သွားသည်၊ သို့သော် ၎င်းအတွက် ကျွန်ုပ်တို့သွားပုံနှင့် နောက်မှသွားသည့်နေရာသည် လုံးဝခြားနားသော ဇာတ်လမ်းဖြစ်သည်။

3. Autotests သည် ထိတွေ့ထားသော ဝဘ်ဝန်ဆောင်မှုများကို စမ်းသပ်နိုင်သည်။ Oracle က သင့်ကို ဒီလိုလုပ်ဆောင်နိုင်တဲ့အတွက် ပြဿနာများစွာကို ကြုံတွေ့ရတော့မှာ မဟုတ်ပါဘူး။
4. ထို့အပြင်၊ ကျွန်ုပ်တို့၏ အလိုအလျောက်စမ်းသပ်မှုစနစ်ကို အခြားပရောဂျက်တွင် အသုံးပြုနိုင်မည်ဖြစ်သည်။ ကျွန်ုပ်တို့ရရှိသောဖြေရှင်းချက်သည် universal ဖြစ်ပြီး Oracle ကို အသုံးပြုရန်သာ လိုအပ်ပါသည်။ အခြားသော Sportmaster ပရောဂျက်များတွင် အလိုအလျောက်စမ်းသပ်ခြင်းတွင် စိတ်ဝင်စားမှုရှိကြောင်း ကြားသိရပြီး၊ ၎င်းတို့ထံ သွားပါမည်။

တွေ့ရှိချက်များ

ပြန်ချုပ်ကြည့်ရအောင်။ Sportmaster ရှိ သစ္စာစောင့်သိမှုစနစ် ပရောဂျက်တွင် ကျွန်ုပ်တို့သည် အလိုအလျောက် စမ်းသပ်ခြင်းစနစ်ကို အကောင်အထည်ဖော်နိုင်ခဲ့သည်။ ၎င်း၏အခြေခံသည် Stephen Feuerstein မှ utPLSQL ဖြေရှင်းချက်ဖြစ်သည်။ utPLSQL ဝန်းကျင်သည် autotests နှင့် auxiliary ကိုယ်တိုင်ရေးထားသော module များအတွက် code ဖြစ်သည်- launcher၊ data generation module နှင့် အခြားအရာများ။ Autotests များသည် နေ့စဉ်နှင့်အမျှ လုပ်ဆောင်နေပြီး အရေးအကြီးဆုံးမှာ အလုပ်နှင့် အကျိုးရှိသည်။ အရည်အသွေးမြင့် ဆော့ဖ်ဝဲလ်ကို စတင်ထုတ်တော့မည်ဟု ကျွန်ုပ်တို့ ယုံကြည်ပါသည်။ တစ်ချိန်တည်းမှာပင်၊ ရလဒ်အဖြေသည် universal ဖြစ်ပြီး Oracle DBMS တွင် အလိုအလျောက်စမ်းသပ်မှုကို စုစည်းရန်လိုအပ်သည့် မည်သည့်ပရောဂျက်တွင်မဆို လွတ်လပ်စွာ အသုံးချနိုင်သည်။

PS ဤဆောင်းပါးသည် အလွန်တိကျသည်မဟုတ်ပါ၊ စာသားများစွာပါရှိပြီး လက်တွေ့တွင် နည်းပညာဆိုင်ရာ ဥပမာများမရှိပါ။ ခေါင်းစဉ်သည် တစ်ကမ္ဘာလုံးက စိတ်ဝင်စားစရာဖြစ်ပါက၊ ၎င်းကို ဆက်လုပ်ရန် အဆင်သင့်ဖြစ်ပြီး၊ ပြီးခဲ့သော ခြောက်လအတွင်း ဘာတွေပြောင်းလဲသွားသည်ကို ပြောပြပြီး ကုဒ်နမူနာများပေးပါမည်။

အနာဂတ်တွင် အလေးပေးသင့်သည့်အချက်များ သို့မဟုတ် ထုတ်ဖော်ရန်လိုအပ်သည့်မေးခွန်းများရှိလျှင် မှတ်ချက်ရေးပါ။

စာရင်းသွင်းအသုံးပြုသူများသာ စစ်တမ်းတွင် ပါဝင်နိုင်ပါသည်။ ဆိုင်းအင်လုပ်ခြင်း, ကျေးဇူးပြု။

ဒီအကြောင်း များများရေးရမလား။

• ဟုတ်ပါတယ်

• ရပါတယ်ကျေးဇူးပါ

အသုံးပြုသူ ၁၄၇ ဦး မဲပေးခဲ့သည်။ အသုံးပြုသူ 12 ဦး ကြားနေခဲ့ပါတယ်။

source: www.habr.com