ဆော့ဖ်ဝဲအင်ဂျင်နီယာများအတွက် CI ဝန်ဆောင်မှုတစ်ခုအဖြစ် စမ်းသပ်မှုကို တင်ပါ။

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

၎င်းတို့၏ တိုက်ရိုက်တာဝန်များကိုထမ်းဆောင်ပြီး ဝန်စမ်းသပ်ခြင်းလုပ်ငန်းစဉ်ကိုတည်ဆောက်ရန်အတွက် ၎င်းတို့၏ထူးခြားသောအတွေ့အကြုံကိုအသုံးပြုမည့်အစား၊ နည်းစနစ်တစ်ခု၊ အကောင်းဆုံးမက်ထရစ်များကိုရွေးချယ်ကာ ဝန်ပရိုဖိုင်များနှင့်အညီ autotests များရေးပါ၊ အင်ဂျင်နီယာများသည် မကြာခဏဆိုသလို စမ်းသပ်အခြေခံအဆောက်အအုံကို အစမှအဆုံးအသုံးပြုရန်၊ load tools များကို configure လုပ်ကာ ၎င်းတို့ကို မြှုပ်နှံရန် လိုအပ်သည် ၎င်းတို့သည် CI စနစ်များတွင် စောင့်ကြည့်စစ်ဆေးခြင်းနှင့် အစီရင်ခံစာများ ထုတ်ပြန်ခြင်းတို့ကို ထူထောင်ပါ။

Positive Technologies တွင် ကျွန်ုပ်တို့အသုံးပြုသော စမ်းသပ်မှုတွင် အဖွဲ့အစည်းဆိုင်ရာပြဿနာအချို့အတွက် အဖြေများကို သင်ရှာတွေ့နိုင်ပါသည်။ အခြားဆောင်းပါး. ဤတစ်ခုတွင်၊ "ဝန်ဆောင်မှုအဖြစ် ဝန်စမ်းသပ်ခြင်း" (ဝန်ဆောင်မှုအဖြစ် ဝန်စမ်းသပ်ခြင်းသဘောတရား) အယူအဆကို အသုံးပြု၍ ဘုံ CI ပိုက်လိုင်းတစ်ခုတွင် ဝန်စမ်းသပ်မှုများကို ပေါင်းစပ်နိုင်ခြေအကြောင်း ပြောပြပါမည်။ CI ပိုက်လိုင်းတွင် load အရင်းအမြစ်များ၏ docker ပုံများကို မည်သို့အသုံးပြုရမည်ကို သင်လေ့လာပါမည်။ တည်ဆောက်ပုံပုံစံကို အသုံးပြု၍ ဝန်ရင်းမြစ်များကို သင်၏ CI ပရောဂျက်သို့ ချိတ်ဆက်နည်း။ ဝန်စမ်းသပ်မှုများ လုပ်ဆောင်ခြင်းနှင့် ရလဒ်များကို ထုတ်ပြန်ခြင်းအတွက် သရုပ်ပြပိုက်လိုင်းသည် မည်သို့ရှိသနည်း။ ဤဆောင်းပါးသည် ဆော့ဖ်ဝဲလ်စမ်းသပ်အင်ဂျင်နီယာများနှင့် ၎င်းတို့၏ဝန်စနစ်၏ဗိသုကာတည်ဆောက်ပုံကို စဉ်းစားနေသော CI ရှိ automation အင်ဂျင်နီယာများအတွက် အသုံးဝင်နိုင်ပါသည်။

အယူအဆ၏အနှစ်သာရ

ဝန်ဆောင်မှုတစ်ခုအနေဖြင့် ဝန်စမ်းသပ်ခြင်းသဘောတရားသည် ဝန်ကိရိယာများ Apache JMeter၊ Yandex.Tank နှင့် သင့်ကိုယ်ပိုင်မူဘောင်များကို အများသူငှာ စဉ်ဆက်မပြတ်ပေါင်းစည်းမှုစနစ်တွင် ပေါင်းစပ်နိုင်စွမ်းကို ရည်ညွှန်းပါသည်။ ဒီမိုသည် GitLab CI အတွက်ဖြစ်မည်ဖြစ်သော်လည်း အခြေခံမူများသည် CI စနစ်အားလုံးတွင် တူညီပါသည်။

ဝန်ဆောင်မှုတစ်ခုအနေဖြင့် Load Testing သည် Load Testing အတွက် ဗဟိုချုပ်ကိုင်သောဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ Load စမ်းသပ်မှုများကို သီးခြားအေးဂျင့်အစုများတွင် လုပ်ဆောင်သည်၊ ရလဒ်များကို GitLab စာမျက်နှာများ၊ Influx DB နှင့် Grafana သို့ အလိုအလျောက် ထုတ်ပြန်ခြင်း သို့မဟုတ် အစီရင်ခံခြင်းစနစ်များကို စမ်းသပ်ရန် (TestRail၊ ReportPortal စသည်ဖြင့်)။ GitLab CI ပရောဂျက်တွင် ပုံမှန် gitlab-ci.yml နမူနာပုံစံကို ပေါင်းထည့်ခြင်းနှင့် ကန့်သတ်ခြင်းများ ပြုလုပ်ခြင်းဖြင့် အလိုအလျောက်စနစ်နှင့် အတိုင်းအတာကို ရိုးရှင်းနိုင်သမျှ ရိုးရှင်းစွာ အကောင်အထည်ဖော်ပါသည်။

ဤချဉ်းကပ်မှု၏ အားသာချက်မှာ CI အခြေခံအဆောက်အအုံတစ်ခုလုံး၊ ဝန်အေးဂျင့်များ၊ ဝန်ရင်းမြစ်များ၏ docker ပုံများ၊ ပိုက်လိုင်းများ စမ်းသပ်ခြင်းနှင့် ထုတ်ဝေခြင်းအစီရင်ခံစာများကို ဗဟိုချုပ်ကိုင်ထားသော အလိုအလျောက်စနစ်ဌာန (DevOps အင်ဂျင်နီယာများ) မှ ထိန်းသိမ်းထားသော်လည်း load testing engineers များသည် စမ်းသပ်တီထွင်မှုကို အာရုံစိုက်နိုင်ပြီး၊ အခြေခံအဆောက်အအုံဆိုင်ရာ ပြဿနာများကို မဖြေရှင်းဘဲ ၎င်းတို့၏ရလဒ်များကို ခွဲခြမ်းစိတ်ဖြာပါ။

ဖော်ပြချက်၏ ရိုးရှင်းမှုအတွက်၊ စမ်းသပ်မှုအောက်တွင် ပစ်မှတ်အပလီကေးရှင်း သို့မဟုတ် ဆာဗာအား ဖြန့်ကျက်ပြီး ကြိုတင်ပြင်ဆင်သတ်မှတ်ထားပြီးဖြစ်သည် (၎င်းအတွက် အလိုအလျောက် script များကို Python၊ SaltStack၊ Ansible စသည်ဖြင့် သုံးနိုင်သည်)။ ထို့နောက် ဝန်ဆောင်မှုတစ်ခုအနေဖြင့် ဝန်စမ်းသပ်ခြင်း၏ သဘောတရားတစ်ခုလုံးသည် အဆင့်သုံးဆင့်ဖြင့် ကိုက်ညီသည်- ပြင်ဆင်ခြင်း၊ စမ်းသပ်ခြင်း၊ အစီရင်ခံစာများ ထုတ်ပြန်ခြင်း။. ပုံကြမ်းပေါ်တွင် နောက်ထပ်အသေးစိတ်အချက်အလက်များ (ပုံအားလုံးကို နှိပ်၍ရနိုင်သည်)

ဝန်စမ်းသပ်ခြင်းတွင် အခြေခံသဘောတရားများနှင့် အဓိပ္ပါယ်ဖွင့်ဆိုချက်များ

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

ကိုယ်စားလှယ်ကို တင်ပါ။ - အပလီကေးရှင်းကိုစတင်မည့် virtual machine တစ်ခု - load source (Apache JMeter၊ Yandex.Tank သို့မဟုတ် ကိုယ်တိုင်ရေးထားသော load module)။

စမ်းသပ်မှုပန်းတိုင် (ပစ်မှတ်) - ဆာဗာ သို့မဟုတ် အက်ပ်လီကေးရှင်းကို ဝန်ခံရမည့် ဆာဗာတွင် ထည့်သွင်းပါ။

စမ်းသပ်မှုအခြေအနေ (စမ်းသပ်မှုကိစ္စ) - သတ်မှတ်ထားသော ကန့်သတ်ဘောင်များပေါ် မူတည်၍ ပုံသေကွန်ရက်တောင်းဆိုမှုများနှင့် တုံ့ပြန်မှုများဖြင့် ဤလုပ်ဆောင်ချက်များအတွက် အသုံးပြုသူလုပ်ဆောင်မှုများနှင့် မျှော်လင့်ထားသည့်တုံ့ပြန်မှုများ။

ပရိုဖိုင် (သို့) အစီအစဉ် (ပရိုဖိုင်) ကို ဖွင့်ပါ - in ISTQB နည်းစနစ် (အပိုင်း 4.2.4၊ p. 43) load profiles သည် သီးခြားစမ်းသပ်မှုတစ်ခုအတွက် အရေးကြီးသော မက်ထရစ်များနှင့် စမ်းသပ်မှုအတွင်း load parameters များကို ပြောင်းလဲခြင်းအတွက် ရွေးချယ်စရာများကို သတ်မှတ်ပါသည်။ ပုံတွင် ပရိုဖိုင်နမူနာများကို ကြည့်ရှုနိုင်ပါသည်။

စမ်း — ကြိုတင်သတ်မှတ်ထားသော ကန့်သတ်ဘောင်တစ်ခုပါရှိသော ဇာတ်ညွှန်းတစ်ခု။

စမ်းသပ်မှု အစီအစဉ် (test-plan) - စမ်းသပ်မှုအစုံနှင့် ဝန်ပရိုဖိုင်။

စမ်းသပ်ရန် (testrun) - အပြည့်အ၀လုပ်ဆောင်ထားသော ဝန်ဇာတ်လမ်းနှင့် လက်ခံရရှိထားသော အစီရင်ခံစာနှင့်အတူ စမ်းသပ်မှုတစ်ခု လုပ်ဆောင်ခြင်း၏ တစ်ကြိမ်ထပ်လုပ်ခြင်း။

ကွန်ရက်တောင်းဆိုချက် (တောင်းဆိုချက်) - ကိုယ်စားလှယ်တစ်ဦးမှ ပစ်မှတ်သို့ ပေးပို့သည့် HTTP တောင်းဆိုချက်။

ကွန်ရက်တုံ့ပြန်မှု (တုံ့ပြန်မှု) - ပစ်မှတ်မှ အေးဂျင့်ထံသို့ ပေးပို့သည့် HTTP တုံ့ပြန်မှု။
HTTP တုံ့ပြန်မှုကုဒ် (HTTP တုံ့ပြန်မှုအခြေအနေ) - အပလီကေးရှင်းဆာဗာမှ စံတုန့်ပြန်ကုဒ်။
ငွေပေးငွေယူဆိုသည်မှာ ပြီးပြည့်စုံသော တောင်းဆိုချက်-တုံ့ပြန်မှု စက်ဝန်းတစ်ခုဖြစ်သည်။ အရောင်းအ၀ယ်တစ်ခုအား တောင်းဆိုချက် (တောင်းဆိုချက်) ပေးပို့မှုစတင်ချိန်မှ တုံ့ပြန်မှု (တုံ့ပြန်မှု) ကိုလက်ခံရရှိခြင်းပြီးဆုံးသည်အထိ ရေတွက်သည်။

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

တုံ့ပြန်ချိန် (latency) - တောင်းဆိုမှု (တောင်းဆိုမှု) ပေးပို့ခြင်းပြီးဆုံးချိန်မှ တုံ့ပြန်မှု (တုံ့ပြန်မှု) လက်ခံရရှိသည့်အချိန်။

မက်ထရစ်များကို တင်ပါ။ — loaded service ၏ ဝိသေသလက္ခဏာများနှင့် load testing လုပ်ငန်းစဉ်တွင် ဆုံးဖြတ်ထားသော load agent ။

ဝန်ဘောင်များကို တိုင်းတာခြင်းအတွက် အခြေခံမက်ထရစ်များ

နည်းစနစ်တွင် အသုံးအများဆုံးနှင့် အကြံပြုချက်အချို့ ISTQB (p. 36၊ 52) မက်ထရစ်များကို အောက်ပါဇယားတွင် ပြထားသည်။ အေးဂျင့်နှင့် ပစ်မှတ်အတွက် အလားတူ မက်ထရစ်များကို တူညီသောလိုင်းတွင် ဖော်ပြထားပါသည်။

load agent အတွက် မက်ထရစ်များ
ပစ်မှတ်စနစ် သို့မဟုတ် အပလီကေးရှင်း၏ မက်ထရစ်များကို load အောက်တွင် စမ်းသပ်နေသည်။

ဂဏန်း  vCPU နှင့် memory ရမ်,
disk ကို - ဝန်အေးဂျင့်၏ဝိသေသလက္ခဏာများ "သံ"
စီပီယူ, Memory၊ Disk အသုံးပြုမှု - CPU၊ memory နှင့် disk loading ၏ ဒိုင်းနမစ်များ
စမ်းသပ်ခြင်းလုပ်ငန်းစဉ်တွင်။ ရာခိုင်နှုန်းအဖြစ် တိုင်းတာလေ့ရှိသည်။
အများဆုံးရရှိနိုင်သောတန်ဖိုးများ

ကွန်ရက်ဖြတ်သန်းမှု (on load agent) - ဖြတ်သန်းမှု
server ပေါ်တွင် network interface၊
load agent နေရာတွင် ထည့်သွင်းထားသည်။
များသောအားဖြင့် bytes per second (bps) ဖြင့် တိုင်းတာသည်
ကွန်ရက်ဖြတ်သန်းမှု(ပစ်မှတ်တွင်) - ကွန်ရက်ကြားခံ လှိုင်းနှုန်း
ပစ်မှတ်ဆာဗာပေါ်တွင်။ များသောအားဖြင့် bytes per second (bps) ဖြင့် တိုင်းတာသည်

Virtual အသုံးပြုသူများ- virtual အသုံးပြုသူအရေအတွက်၊
load scenarios နှင့် အကောင်အထည်ဖော်ခြင်း။
သုံးစွဲသူအစစ်အမှန် လုပ်ဆောင်ချက်များကို အတုယူခြင်း။
Virtual အသုံးပြုသူများ အနေအထား၊ အောင်မြင်ပြီး/မအောင်မြင်/စုစုပေါင်း — အောင်မြင်သောအရေအတွက်နှင့်
virtual အသုံးပြုသူများ၏ မအောင်မြင်သော အခြေအနေများ
load scenarios များအပြင် ၎င်းတို့၏ စုစုပေါင်းအရေအတွက်။

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

တစ်စက္ကန့် (မိနစ်) တောင်းဆိုမှုများ- တစ်စက္ကန့်လျှင် ကွန်ရက်တောင်းဆိုမှုအရေအတွက် (သို့မဟုတ် တစ်မိနစ်)။

load agent ၏ အရေးကြီးသော လက္ခဏာမှာ တောင်းဆိုမှု မည်မျှ ထုတ်ပေးနိုင်သည် ။
အမှန်မှာ၊ ၎င်းသည် virtual အသုံးပြုသူများ၏ အပလီကေးရှင်းသို့ ဝင်ရောက်ခွင့်ကို အတုယူခြင်းဖြစ်သည်။
တစ်စက္ကန့် (မိနစ်) တုံ့ပြန်မှု
- တစ်စက္ကန့်လျှင် ကွန်ရက်တုံ့ပြန်မှု အရေအတွက် (သို့မဟုတ် တစ်မိနစ်)။

ပစ်မှတ်ဝန်ဆောင်မှု၏ အရေးကြီးသော လက္ခဏာ- မည်မျှ
မေးခွန်းများနှင့်အတူ တုံ့ပြန်မှုများကို ဖန်တီးပြီး ပေးပို့ပါ။
loading agent

HTTP တုံ့ပြန်မှုအခြေအနေ- မတူညီသောတုံ့ပြန်မှုကုဒ်နံပါတ်များ
load agent မှလက်ခံရရှိသော application server မှ။
ဥပမာ 200 OK ဆိုသည်မှာ အောင်မြင်သောခေါ်ဆိုမှု၊
နှင့် 404 - အရင်းအမြစ်ကို ရှာမတွေ့ပါ။

latency (တုံ့ပြန်ချိန်) - အဆုံးမှအချိန်
တုံ့ပြန်မှု (တုံ့ပြန်မှု) မစတင်မီ တောင်းဆိုမှု (တောင်းဆိုမှု) ပေးပို့ခြင်း။
အများအားဖြင့် မီလီစက္ကန့် (ms) ဖြင့် တိုင်းတာသည်

ငွေပေးငွေယူ တုံ့ပြန်ချိန်- အရောင်းအ၀ယ်တစ်ခု၏အချိန်၊
တောင်းဆိုချက်-တုံ့ပြန်မှုစက်ဝန်း၏ ပြီးမြောက်ခြင်း။
ဤအချိန်သည် တောင်းဆိုချက် (တောင်းဆိုချက်) ပေးပို့သည့်အချိန်မှစပြီး၊
တုံ့ပြန်မှု (တုံ့ပြန်မှု) ကိုလက်ခံရရှိပြီးသည်အထိ။

ငွေလွှဲချိန်ကို စက္ကန့် (သို့မဟုတ်) မိနစ်ဖြင့် တိုင်းတာနိုင်သည်။
နည်းလမ်းများစွာဖြင့်- အနည်းဆုံးစဉ်းစားပါ၊
အမြင့်ဆုံး၊ ပျမ်းမျှနှင့် ဥပမာအားဖြင့်၊ 90th ရာခိုင်နှုန်း။
အနိမ့်ဆုံး နှင့် အများဆုံး ဖတ်ရှုမှုမှာ လွန်ကဲသည်။
စနစ်စွမ်းဆောင်ရည်အခြေအနေ။
ကိုးဆယ်ရာခိုင်နှုန်းသည် အသုံးအများဆုံး၊
အသုံးပြုသူအများစုကိုပြသထားသည့်အတိုင်း၊
စနစ်စွမ်းဆောင်ရည်အဆင့်တွင် သက်တောင့်သက်သာဖြင့် လည်ပတ်နိုင်သည်။

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

ငွေလွှဲမှုအခြေအနေ , အောင်မြင်ပြီး / မအောင်မြင် / စုစုပေါင်း - နံပါတ်
အောင်မြင်သည်၊ မအောင်မြင်သည်နှင့် ငွေလွှဲမှုစုစုပေါင်းအရေအတွက်။

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

စမ်းသပ်ခြင်း ဇယားကွက်ကို တင်ပါ။

ဝန်စမ်းသပ်ခြင်း၏ သဘောတရားသည် အလွန်ရိုးရှင်းပြီး ကျွန်ုပ်ဖော်ပြခဲ့ပြီးသော အဓိက အဆင့်သုံးဆင့် ပါဝင်ပါသည်။ ပြင်ဆင်-စမ်းသပ်-အစီရင်ခံစာဆိုလိုသည်မှာ၊ စမ်းသပ်မှုပန်းတိုင်များကို ပြင်ဆင်ခြင်းနှင့် load ရင်းမြစ်များအတွက် ကန့်သတ်ချက်များသတ်မှတ်ခြင်း၊ ထို့နောက် load tests များကို လုပ်ဆောင်ပြီး အဆုံးတွင် စမ်းသပ်မှုအစီရင်ခံစာကို ဖန်တီးခြင်းနှင့် ထုတ်ဝေခြင်းတို့ကို ဆိုလိုပါသည်။

ဇယားကွက်မှတ်စုများ

• QA.Tester သည် ဝန်စမ်းသပ်မှုတွင် ကျွမ်းကျင်သူ၊
• Target သည် ဝန်အောက်တွင် ၎င်း၏အပြုအမူကို သိလိုသည့် ပစ်မှတ် application ဖြစ်သည်။

ပုံတွင်ရှိသော အရာများ၊ အဆင့်များနှင့် အဆင့်များကို အမျိုးအစားခွဲသည်။

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

ကြိုတင်ပြင်ဆင်ခြင်း- စမ်းသပ်မှုအတွက် ပြင်ဆင်မှုအဆင့်

LoadParameters
သတ်မှတ်ခြင်းနှင့် အစပြုခြင်း။
အသုံးပြုသူကို
load parameters တွေ၊
တိုင်းတာမှုရွေးချယ်မှုနှင့်
စမ်းသပ်မှုအစီအစဉ်ပြင်ဆင်ခြင်း။
(ပရိုဖိုင်ကို တင်ပါ)
စိတ်ကြိုက်ရွေးချယ်မှုများ
load agent အစပြုခြင်း
စမ်းသပ်မှုအစီအစဉ်
စမ်းသပ်ခြင်း၏ရည်ရွယ်ချက်

VM
တိမ်တိုက်ဖြန့်ကျက်မှု
virtual machine နှင့်အတူ
လိုအပ်သောလက္ခဏာများ
load agent အတွက် VM ဆက်တင်များ
Automation scripts များ
VM ဖန်တီးမှု
VM ကို ပြင်ဆင်သတ်မှတ်ထားသည်။
တိမ်တိုက်

ပတ်ဝန်းကျင်
OS စနစ်ထည့်သွင်းခြင်းနှင့် ပြင်ဆင်ခြင်း။
ပတ်ဝန်းကျင်
အေးဂျင့်အလုပ်လုပ်ပါ။
ပတ်ဝန်းကျင် ဆက်တင်များ
တင်ရန်အေးဂျင့်
Automation scripts များ
ပတ်ဝန်းကျင် ဆက်တင်များ
ပြင်ဆင်ထားသော ပတ်ဝန်းကျင်
OS၊ ဝန်ဆောင်မှုများနှင့် အသုံးချပရိုဂရမ်များ၊
အလုပ်အတွက်လိုအပ်သော
တင်ရန်အေးဂျင့်

LoadAgents များ
တပ်ဆင်ခြင်း၊ ဖွဲ့စည်းမှုပုံစံနှင့် ကန့်သတ်ချက်များ ပြုလုပ်ခြင်း။
loading agent
သို့မဟုတ် docker ပုံမှ ဒေါင်းလုဒ်လုပ်ခြင်း။
ကြိုတင်ပြင်ဆင်ထားသော ဝန်အရင်းအမြစ်
အရင်းအမြစ် docker ပုံကို တင်ပါ။
(YAT၊ JM သို့မဟုတ် ကိုယ်တိုင်ရေးထားသော မူဘောင်)
ဆက်တင်များ
တင်ရန်အေးဂျင့်
စနစ်ထည့်သွင်းပြီး ပြင်ဆင်ပါ။
load agent အလုပ်လုပ်ရန်

စမ်းသပ်မှု- ဝန်စမ်းသပ်မှုများ လုပ်ဆောင်သည့် အဆင့်။ ရင်းမြစ်များသည် GitLab CI အတွက် သီးခြားအေးဂျင့်အစုများတွင် အသုံးပြုထားသော ဝန်အေးဂျင့်များဖြစ်သည်။

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

အေးဂျင့်များကိုဖွင့်ပါ။
အေးဂျင့် ကွပ်မျက်ခြင်း။
စမ်းသပ်မှု scripts အများအပြား
နှင့်အညီ
ပရိုဖိုင်ကို တင်ပါ။
Agent အပြန်အလှန်တုံ့ပြန်မှုကို တင်ပါ။
စမ်းသပ်ခြင်း၏ရည်ရွယ်ချက်အတွက်
စမ်းသပ်မှုအစီအစဉ်
စမ်းသပ်ခြင်း၏ရည်ရွယ်ချက်

သစ်လုံး
"ကုန်ကြမ်း" မှတ်တမ်းများ စုဆောင်းခြင်း။
ဝန်စမ်းသပ်နေစဉ်-
အေးဂျင့်လုပ်ဆောင်မှုမှတ်တမ်းများကို တင်ရန်၊
စမ်းသပ်ပစ်မှတ်အခြေအနေ
နှင့် VM သည် အေးဂျင့်ကို လုပ်ဆောင်နေသည်။

စီရင်ချက်မှတ်တမ်းများ
load စမ်းသပ်မှုများ
စနစ်မှတ်တမ်းများ

မက်ထရစ်
စမ်းသပ်နေစဉ် "ကုန်ကြမ်း" မက်ထရစ်များကို စုဆောင်းခြင်း။

ရည်မှန်းချက် တိုင်းတာမှုများတွင် ပြောင်းလဲမှုများ၏ ဒိုင်နမ်မစ်များ
အေးဂျင့်ကို တင်ပါ။

အစီရင်ခံစာ- စမ်းသပ်အစီရင်ခံစာပြင်ဆင်မှု အဆင့်

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

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

CI Template တွင် Load Sources များကို ချိတ်ဆက်ခြင်း။

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

ပထမဦးစွာ၊ ကျွန်ုပ်တို့၏ DevOps အင်ဂျင်နီယာများ၏အကူအညီဖြင့်၊ ဝန်စမ်းသပ်မှုများလုပ်ဆောင်ရန် GitLab CI တွင် သီးခြားအေးဂျင့်အစုတစ်ခုကို ဖန်တီးခဲ့သည်။ စည်းဝေးပွဲပေါင်းများကဲ့သို့သော တင်းပလိတ်များတွင် ၎င်းတို့ကို အခြားသူများနှင့် မရောထွေးစေရန်အတွက်၊ ကျွန်ုပ်တို့သည် ဤအေးဂျင့်များသို့ တဂ်များကို ထည့်လိုက်ပါသည်။ tags များ: ဝန်။ အခြားနားလည်နိုင်သော tag များကို သင်သုံးနိုင်သည်။ မေးကြတယ်။ မှတ်ပုံတင်နေစဉ် GitLab CI Runners

Hardware ဖြင့် လိုအပ်သော ပါဝါကို မည်သို့ရှာဖွေရမည်နည်း။ load အေးဂျင့်များ၏ ဝိသေသလက္ခဏာများ - လုံလောက်သော vCPU၊ RAM နှင့် Disk အရေအတွက် - Docker၊ Python (for Yandex.Tank)၊ GitLab CI အေးဂျင့်၊ Java (Apache JMeter အတွက်) အေးဂျင့်တွင် အလုပ်လုပ်သင့်သည်ဟူသောအချက်အပေါ် အခြေခံ၍ တွက်ချက်နိုင်ပါသည်။ . JMeter အောက်တွင် Java အတွက် အနည်းဆုံး RAM 512 MB ကို အသုံးပြုရန် အကြံပြုထားပြီး အထက်ကန့်သတ်ချက်အနေဖြင့်၊ 80% ရနိုင်သောမှတ်ဉာဏ်.

ထို့ကြောင့် ကျွန်ုပ်တို့၏အတွေ့အကြုံအပေါ်အခြေခံ၍ load အေးဂျင့်များအတွက် အနည်းဆုံး vCPU 4 ခု၊ 4 GB RAM၊ 60 GB SSD ကို အသုံးပြုရန် အကြံပြုအပ်ပါသည်။ ကွန်ရက်ကတ်၏ ဖြတ်သန်းမှုကို ဝန်ပရိုဖိုင်၏ လိုအပ်ချက်များအပေါ် အခြေခံ၍ ဆုံးဖြတ်သည်။

ကျွန်ုပ်တို့ အဓိကအားဖြင့် Apache JMeter နှင့် Yandex.Tank docker ပုံများကို အသုံးပြုပါသည်။

Yandex.Tank load စမ်းသပ်ခြင်းအတွက် Yandex မှ open source tool တစ်ခုဖြစ်သည်။ ၎င်း၏ မော်ဂျူလာ ဗိသုကာလက်ရာသည် Phantom ၏ စွမ်းဆောင်ရည်မြင့် အပြိုင်အဆိုင် ရိုက်ခတ်မှုအခြေခံ HTTP တောင်းဆိုချက် ဂျင်နရေတာအပေါ် အခြေခံထားသည်။ တင့်ကားတွင် SSH ပရိုတိုကောမှတစ်ဆင့် စမ်းသပ်မှုအောက်တွင် ဆာဗာ၏ရင်းမြစ်များကို တပ်ဆင်စောင့်ကြည့်ခြင်း၊ သတ်မှတ်ထားသည့်အခြေအနေများအောက်တွင် စမ်းသပ်မှုကို အလိုအလျောက်ရပ်တန့်နိုင်ပြီး ရလဒ်များကို ကွန်ဆိုးလ်နှင့် ဂရပ်ပုံစံနှစ်မျိုးလုံးတွင် ပြသနိုင်သည်၊ သင်၏ module များကို ချိတ်ဆက်နိုင်သည်။ လုပ်ဆောင်နိုင်စွမ်းကို ချဲ့ထွင်ရန်။ စကားမစပ်၊ ကျွန်တော်တို့က ပင်မရေစီးကြောင်း မဖြစ်သေးတဲ့အခါ Tank ကို သုံးပါတယ်။ ဆောင်းပါးထဲမှာ "Yandex.Tank နှင့် load စမ်းသပ်ခြင်း အလိုအလျောက်စနစ်» 2013 ခုနှစ်တွင် ၎င်းနှင့် load testing ပြုလုပ်ပုံအကြောင်း သင်ဖတ်နိုင်ပါသည်။ PT Application Firewall ကျွန်ုပ်တို့၏ကုမ္ပဏီထုတ်ကုန်များထဲမှတစ်ခုဖြစ်သည်။

Apache JMeter Apache မှ open source load testing tool တစ်ခုဖြစ်သည်။ static နှင့် dynamic web applications နှစ်ခုလုံးကို စမ်းသပ်ရန်အတွက် ၎င်းကို ကောင်းစွာအသုံးပြုနိုင်ပါသည်။ JMeter သည် အပလီကေးရှင်းများနှင့် အပြန်အလှန်တုံ့ပြန်ရန် နည်းလမ်းများစွာကို ပံ့ပိုးပေးသည်- HTTP၊ HTTPS (Java၊ NodeJS၊ PHP၊ ASP.NET စသည်ဖြင့်)၊ SOAP/REST Webservices၊ FTP၊ TCP၊ LDAP၊ SMTP(S), POP3( S) ) နှင့် IMAP(S)၊ JDBC မှတဆင့် ဒေတာဘေ့စ်များသည် shell command များကို လုပ်ဆောင်နိုင်ပြီး Java အရာဝတ္ထုများနှင့် အလုပ်လုပ်နိုင်သည်။ JMeter တွင် စမ်းသပ်မှုအစီအစဥ်များကို ဖန်တီးခြင်း၊ အမှားရှာခြင်းနှင့် လုပ်ဆောင်ခြင်းအတွက် IDE တစ်ခုရှိသည်။ မည်သည့် Java နှင့်လိုက်ဖက်သောလည်ပတ်မှုစနစ် (Linux၊ Windows၊ Mac OS X) တွင် command line လည်ပတ်မှုအတွက် CLI တစ်ခုလည်းရှိသည်။ ကိရိယာသည် HTML စမ်းသပ်မှုအစီရင်ခံစာကို အင်တိုက်အားတိုက်ထုတ်ပေးနိုင်သည်။

ကျွန်ုပ်တို့၏ကုမ္ပဏီအတွင်း အသုံးပြုရလွယ်ကူစေရန်၊ စမ်းသပ်သူများကိုယ်တိုင် ပတ်ဝန်းကျင်ကို ပြောင်းလဲရန်နှင့် ပေါင်းထည့်နိုင်စေရန်အတွက်၊ ကျွန်ုပ်တို့သည် ဌာနတွင်းသို့ ထုတ်ဝေခြင်းဖြင့် GitLab CI ရှိ load source ၏ docker ပုံများကို တည်ဆောက်ခဲ့ပါသည်။ Artifactory ရှိ docker မှတ်ပုံတင်ခြင်း။. ၎င်းသည် ဝန်စမ်းသပ်မှုများအတွက် ၎င်းတို့အား ပိုက်လိုင်းများတွင် ချိတ်ဆက်ရန် ပိုမိုမြန်ဆန်စေပါသည်။ GitLab CI မှတဆင့် registry သို့ docker push လုပ်နည်း - ကြည့်ပါ။ ညွှန်ကြားချက်.

Yandex.Tank အတွက် ဤအခြေခံ docker ဖိုင်ကို ကျွန်ုပ်တို့ယူခဲ့သည်-

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

Apache JMeter အတွက်၊

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

ဆောင်းပါးတွင် ကျွန်ုပ်တို့၏ စဉ်ဆက်မပြတ် ပေါင်းစည်းမှုစနစ် အလုပ်လုပ်ပုံကို သင်ဖတ်ရှုနိုင်ပါသည်။ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်များ၏ အလိုအလျောက်လုပ်ဆောင်ခြင်း- Positive Technologies တွင် DevOps စိတ်ကူးများကို ကျွန်ုပ်တို့ အကောင်အထည်ဖော်ပုံ"။

ပုံစံခွက်နှင့် ပိုက်လိုင်း

ပရောဂျက်တွင် ဝန်စမ်းသပ်မှုများ ပြုလုပ်ရန်အတွက် နမူနာပုံစံတစ်ခုကို ရနိုင်သည်။ ဒီမို ဝန်။ အဆိုပါ readme ဖိုင် နမူနာပုံစံကို အသုံးပြုရန် လမ်းညွှန်ချက်များကို သင်ဖတ်နိုင်သည်။ နမူနာပုံစံထဲတွင် (ဖိုင် .gitlab-ci.yml၎) အဆင့်တိုင်းတွင် တာဝန်ရှိသည်နှင့် ပတ်သက်၍ မှတ်စုများရှိပါသည်။

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

1. ဇာတ်စင် ပြင်ဆင်ပါ စမ်းသပ်ပစ်မှတ်များကို ကြိုတင်ပြင်ဆင်သတ်မှတ်ရန် သို့မဟုတ် ၎င်းတို့၏ရရှိနိုင်မှုကို စစ်ဆေးရန်အတွက် အသုံးပြုသင့်သည်။ load ရင်းမြစ်များအတွက် ပတ်ဝန်းကျင်ကို configure လုပ်ရန်မလိုအပ်ပါ၊ ၎င်းတို့ကို docker ပုံများအဖြစ် ကြိုတင်တည်ဆောက်ထားပြီး docker registry တွင် တင်ထားသည်- Test အဆင့်တွင် လိုချင်သောဗားရှင်းကို သတ်မှတ်ရုံသာဖြစ်သည်။ သို့သော် ၎င်းတို့ကို ပြန်လည်တည်ဆောက်နိုင်ပြီး သင့်ကိုယ်ပိုင် မွမ်းမံထားသော ပုံများကို ဖန်တီးနိုင်သည်။
2. ဇာတ်စင် စမ်းသပ် ဝန်အရင်းအမြစ်ကို သတ်မှတ်ရန်၊ စမ်းသပ်မှုများ လုပ်ဆောင်ရန်နှင့် စမ်းသပ်မှုဆိုင်ရာ ပစ္စည်းများကို သိမ်းဆည်းရန် အသုံးပြုသည်။ မည်သည့် load အရင်းအမြစ်ကိုမဆို သင်ရွေးချယ်နိုင်သည်- Yandex.Tank၊ Apache JMeter၊ သင့်ကိုယ်ပိုင် သို့မဟုတ် အားလုံးကို အတူတကွ လုပ်ဆောင်နိုင်သည်။ မလိုအပ်သောရင်းမြစ်များကို ပိတ်ရန်၊ မှတ်ချက်ပေးရုံ သို့မဟုတ် အလုပ်အား ဖျက်ပစ်ပါ။ ဒေါင်းလုဒ်ရင်းမြစ်များအတွက် ဝင်ခွင့်အမှတ်များ-
   • Yandex.Tank အတွက် Launch parameters များကို ./tests/yandextank.sh,
   • Apache JMeter စတင်သည့် ကန့်သတ်ဘောင်များကို ဖိုင်တွင် သတ်မှတ်ထားသည်။ ./tests/jmeter.sh.

   မှတ်ချက်- စည်းဝေးဖွဲ့စည်းပုံပုံစံပုံစံကို CI စနစ်နှင့် အပြန်အလှန်ဆက်သွယ်မှုကို စနစ်ထည့်သွင်းရန် အသုံးပြုထားပြီး ၎င်းတွင် စမ်းသပ်မှုယုတ္တိနေရာချထားမှုကို အဓိပ္ပာယ်မသက်ရောက်ပါ။ စစ်ဆေးမှုများအတွက်၊ ထိန်းချုပ်မှု bash script တည်ရှိရာ entry point ကိုသတ်မှတ်ထားသည်။ စမ်းသပ်မှုများလုပ်ဆောင်ခြင်း၊ အစီရင်ခံစာများထုတ်ပေးခြင်းနှင့် စမ်းသပ်ခြင်းဆိုင်ရာ scripts များကိုယ်တိုင် QA အင်ဂျင်နီယာများမှ လုပ်ဆောင်သည့်နည်းလမ်းကို အကောင်အထည်ဖော်ရမည်ဖြစ်သည်။ သရုပ်ပြတွင်၊ load အရင်းအမြစ်နှစ်ခုလုံးအတွက် Yandex ပင်မစာမျက်နှာတောင်းဆိုချက်ကို အရိုးရှင်းဆုံးစမ်းသပ်မှုအဖြစ် အသုံးပြုသည်။ Script များနှင့် စမ်းသပ်မှုဘောင်များသည် လမ်းညွှန်ထဲတွင် ရှိနေသည်။ ./tests.

3. စင်ပေါ်မှာ အစီရင်ခံစာ Test အဆင့်တွင်ရရှိသော စမ်းသပ်မှုရလဒ်များကို ပြင်ပသိုလှောင်မှုများသို့ ဥပမာအားဖြင့် GitLab Pages သို့မဟုတ် အထူးအစီရင်ခံခြင်းစနစ်များသို့ မည်သို့ထုတ်ဝေရမည်ကို သင်ဖော်ပြရန်လိုသည်။ GitLab Pages တွင် ./public directory သည် ဗလာမဟုတ်ကြောင်းနှင့် စမ်းသပ်မှုများပြီးပါက အနည်းဆုံး index.html ဖိုင်တစ်ခုပါဝင်ရန်လိုအပ်သည်။ GitLab Pages ဝန်ဆောင်မှု၏ ကွဲပြားချက်များအကြောင်း သင်ဖတ်နိုင်ပါသည်။ လင့်ခ်.

   ဒေတာထုတ်ယူနည်း ဥပမာများ-

   • JMeter မှ GitLab စာမျက်နှာများ,
   • Yandex.Tank မှ InfluxDB နှင့် Grafana.

   စနစ်ထည့်သွင်းရန် ညွှန်ကြားချက်များကို ပို့စ်တင်ခြင်း-

   • HTML ထဲမှာ statics GitLab စာမျက်နှာများ,
   • InfluxDB သို့ ပြီးမှ Grafana.

သရုပ်ပြနမူနာတွင်၊ ဝန်စမ်းသပ်မှုများနှင့် ဝန်အရင်းအမြစ်နှစ်ခုပါရှိသော ပိုက်လိုင်း (မလိုအပ်ဘဲကို သင်ပိတ်ထားနိုင်သည်) သည် ဤကဲ့သို့ ဖြစ်သည်-

Apache JMeter သည် HTML အစီရင်ခံစာကို ကိုယ်တိုင်ဖန်တီးနိုင်သည်၊ ထို့ကြောင့် ၎င်းကို GitLab Pages တွင် စံကိရိယာများအသုံးပြု၍ သိမ်းဆည်းခြင်းသည် ပို၍အကျိုးရှိသည်။ ဤသည်မှာ Apache JMeter အစီရင်ခံစာပုံသဏ္ဌာန်ဖြစ်သည်-

Yandex.Tank အတွက် ဒီမိုနမူနာတွင်၊ သင်သာမြင်ရပါမည်။ စာသားအတုအစီရင်ခံစာ GitLab စာမျက်နှာများအတွက် ကဏ္ဍတွင်။ စမ်းသပ်နေစဉ်အတွင်း Tank သည် ရလဒ်များကို InfluxDB ဒေတာဘေ့စ်တွင် သိမ်းဆည်းနိုင်ပြီး ၎င်းတို့ကို ဥပမာအားဖြင့် Grafana တွင် ပြသနိုင်သည် (ဖိုင်တွင် configuration ပြုလုပ်သည် ./tests/example-yandextank-test.yml) ဤသည်မှာ Tank ၏အစီရင်ခံစာကို Grafana တွင်ကြည့်ရှုပုံဖြစ်သည်။

အကျဉ်းချုပ်

ဆောင်းပါးတွင်၊ "ဝန်ဆောင်မှုအဖြစ်ဝန်စမ်းသပ်ခြင်း" (ဝန်ဆောင်မှုအဖြစ်ဝန်စမ်းသပ်ခြင်း) ၏အယူအဆအကြောင်းပြောခဲ့သည်။ အဓိက စိတ်ကူးမှာ ဝန်ခံအေးဂျင့်များ၏ ကြိုတင်ပြင်ဆင်ထားသော အစုအပုံများ၊ ဝန်ရင်းမြစ်များ၏ docker ပုံများ၊ အစီရင်ခံခြင်းစနစ်များနှင့် ၎င်းတို့ကို GitLab CI တွင် ပေါင်းစပ်ထားသည့် ပိုက်လိုင်းကို အသုံးပြုရန်အတွက် ရိုးရှင်းသော .gitlab-ci.yml နမူနာပုံစံကို အခြေခံ၍ (ဥပမာ၊ လင့်ခ်) ဤအရာအားလုံးကို automation engineers အဖွဲ့ငယ်လေးမှပံ့ပိုးပြီး ထုတ်ကုန်အဖွဲ့များ၏ တောင်းဆိုချက်အရ ထပ်တူပြုပါသည်။ ၎င်းသည် သင့်ကုမ္ပဏီတွင် အလားတူအစီအစဥ်ကို ပြင်ဆင်ခြင်းနှင့် အကောင်အထည်ဖော်ရာတွင် အထောက်အကူဖြစ်စေမည်ဟု မျှော်လင့်ပါသည်။ အာရုံစိုက်မှုအတွက် ကျေးဇူးတင်ပါသည်။

PS သည် ကျွန်ုပ်တို့၏ကုမ္ပဏီရှိ ဝန်ဆောင်မှုတစ်ခုအနေဖြင့် load testing သဘောတရားကို အကောင်အထည်ဖော်ရာတွင် နည်းပညာဆိုင်ရာအကူအညီအတွက် ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များ၊ Sergey Kurbanov နှင့် Nikolai Yusev အား ကျေးဇူးတင်ကြောင်း ပြောကြားလိုပါသည်။

စာရေးသူ: Timur Gillmullin - ဒုဝန်ကြီး Positive Technologies မှ နည်းပညာနှင့် ဖွံ့ဖြိုးတိုးတက်ရေး လုပ်ငန်းစဉ်များ (DevOps) ၏ အကြီးအကဲ

source: www.habr.com