• API Testing Tutorials များစာရင်း
• ဤ API စမ်းသပ်မှုစီးရီးရှိ ကျူတိုရီရယ်များ၏ ခြုံငုံသုံးသပ်ချက်
  • • (ii) Load and Performance Testing
  • သင့်အဖွဲ့အစည်းတွင် API စမ်းသပ်ခြင်းကို မိတ်ဆက်နည်း
  • အဖြစ်များသော စိန်ခေါ်မှုများနှင့် ၎င်းတို့ကို လျော့ပါးစေရန် နည်းလမ်းများ
    • #1) မှန်ကန်သောကိရိယာကို ရွေးချယ်ခြင်း
    • #2) ပျောက်ဆုံးနေသော စမ်းသပ်မှုဆိုင်ရာ သတ်မှတ်ချက်များ
    • #3) Learning Curve
    • #4) ရှိပြီးသား ကျွမ်းကျင်မှု သတ်မှတ်
  • Case Study
• နိဂုံး
• API စမ်းသပ်ခြင်း ကျူတိုရီရယ်
  • Shift Left Testing
  • Software Development Life Cycle (SDLC) ကို Shift Left Testing မတိုင်မီ
  • ဘယ်ဘက်ပြောင်းရွေ့မှုစမ်းသပ်ခြင်းအဆင့်များ
  • Web API
  • API တစ်ခု မည်သို့အလုပ်လုပ်သနည်း။
  • ဝဘ်ဝန်ဆောင်မှုများ
  • ဝဘ်ဝန်ဆောင်မှုများနှင့် Web API
• သင့်အဖွဲ့အစည်းတွင် API စမ်းသပ်ခြင်းကို မိတ်ဆက်ခြင်း
  • Focus Shift to API Testing
  • API စမ်းသပ်ခြင်း၏ Spectrum အပြည့်အစုံ
    • (i) Functional Testing

ဤ In-depth API Testing Tutorial သည် API Testing၊ Web Services နှင့် သင့်အဖွဲ့အစည်းတွင် API Testing ကို မည်သို့မိတ်ဆက်နည်း အားလုံးကို ရှင်းပြသည်-

API Testing နှင့်အတူ နက်နဲသော ထိုးထွင်းသိမြင်မှုကို ရယူပါ။ ဤနိဒါန်းသင်ခန်းစာမှ shift-left testing နှင့် ဝဘ်ဝန်ဆောင်မှုများ၏ သဘောတရား။

Web API ကဲ့သို့သော သဘောတရားများ၊ API မည်ကဲ့သို့ အလုပ်လုပ်ပုံ (ကမ္ဘာပေါ်ရှိ ဥပမာများဖြင့်) နှင့် Web Services နှင့် မည်သို့ကွာခြားသည်ကို ဤဥပမာများဖြင့် ကောင်းစွာရှင်းပြထားပါသည်။ သင်ခန်းစာ။

API Testing Tutorials များစာရင်း

ကျူတိုရီရယ် #1: API Testing Tutorial- Beginners အတွက် ပြီးပြည့်စုံသော လမ်းညွှန်

ကျူတိုရီရယ် #2: ဝဘ်ဝန်ဆောင်မှု ကျူတိုရီရယ်- အစိတ်အပိုင်းများ၊ ဗိသုကာပညာ၊ အမျိုးအစားများ & ဥပမာများ

ကျူတိုရီရယ် #3: ထိပ်တန်း 35 ASP.Net နှင့် Web API အင်တာဗျူးမေးခွန်းများကို အဖြေများ

ကျူတိုရီရယ် #4: POSTMAN ကျူတိုရီရယ်- API စမ်းသပ်ခြင်း POSTMAN ကိုအသုံးပြုခြင်း

ကျူတိုရီရယ် #5: Apache HTTP Client ကိုအသုံးပြုခြင်း ဝဘ်ဝန်ဆောင်မှုများကို စမ်းသပ်ခြင်း

ဤ API စမ်းသပ်မှုစီးရီးရှိ ကျူတိုရီရယ်များ၏ ခြုံငုံသုံးသပ်ချက်

ကျူတိုရီရယ် #	သင်လေ့လာမည့်အရာ
ကျူတိုရီရယ်_#1-	API စမ်းသပ်ခြင်း ကျူတိုရီရယ် - စတင်သူများအတွက် လမ်းညွှန်ချက်အပြည့်အစုံ ဤ In-depth API Testing Tutorial သည် API Testing နှင့် Web Services များအကြောင်း အားလုံးကို အသေးစိတ်ရှင်းပြပြီး သင့်အဖွဲ့အစည်းတွင် API Testing ကို မိတ်ဆက်နည်းကို သင်ပေးပါသည်။
ကျူတိုရီရယ်_#2-	ဝဘ်ဝန်ဆောင်မှုများ ကျူတိုရီရယ်- အစိတ်အပိုင်းများ၊ ဗိသုကာပညာ၊ အမျိုးအစားများ & ဥပမာများ ဤဝဘ်မှန်ကန်ပြီး မမှန်ကန်သော တုံ့ပြန်မှုအတွက် API မှ တုံ့ပြန်မှုများ၏ မှန်ကန်မှုသည် အမှန်ပင် အရေးကြီးပါသည်။ အကယ်၍ 200 (အားလုံးဟု အဓိပ္ပါယ်ရသည့် အခြေအနေကုဒ်) ကို စမ်းသပ် API မှ တုံ့ပြန်မှုအဖြစ် လက်ခံရရှိပါက၊ သို့သော် တုံ့ပြန်ချက်စာသားတွင် အမှားအယွင်းတစ်ခု ကြုံတွေ့ရသည်ဟု ဆိုပါက၊ ၎င်းသည် ချို့ယွင်းချက်တစ်ခုဖြစ်သည်။ ထို့အပြင် အမှားအယွင်းရှိလျှင် ၎င်းကိုယ်တိုင်က မမှန်ပါ၊ ထို့နောက် ၎င်းသည် ဤ API နှင့် ပေါင်းစည်းရန် ကြိုးစားနေသော နောက်ဆုံး သုံးစွဲသူကို အထင်လွဲစေနိုင်ပါသည်။ အောက်ပါ ဖန်သားပြင်ဓာတ်ပုံတွင်၊ အသုံးပြုသူသည် လက်ခံနိုင်သော 2267 Kgs ထက် ပိုသော မမှန်ကန်သော အလေးချိန်ကို ထည့်သွင်းထားပါသည်။ API သည် အမှားအယွင်းအခြေအနေကုဒ်နှင့် အမှားသတင်းတိုဖြင့် တုံ့ပြန်သည်။ သို့သော်၊ အမှားသတင်းစကားသည် KG အစား အလေးချိန်ယူနစ်များကို ပေါင်များအဖြစ် မှားယွင်းစွာဖော်ပြသည်။ ၎င်းသည် ဖောက်သည်အား အဆုံးစွန်သော ဖောက်သည်အား စိတ်ရှုပ်ထွေးစေသည့် ချို့ယွင်းချက်တစ်ခုဖြစ်သည်။ (ii) Load and Performance Testing API များကို ဒီဇိုင်းအားဖြင့် အတိုင်းအတာဖြင့် ချဲ့ထွင်ရန် ရည်ရွယ်ပါသည်။ ၎င်းက တစ်ဖန်၊ အထူးသဖြင့် ၎င်းစနစ်သည် လိုအပ်ချက်ပေါ်မူတည်၍ တစ်မိနစ် သို့မဟုတ် တစ်နာရီလျှင် တောင်းဆိုချက်ထောင်ပေါင်းများစွာကို ဆောင်ရွက်ပေးလိမ့်မည်ဟု မျှော်လင့်ထားလျှင် Load နှင့် Performance Testing သည် မရှိမဖြစ်လိုအပ်ပါသည်။ API ပေါ်ရှိ Load နှင့် Performance Tests များကို ပုံမှန်လုပ်ဆောင်ခြင်းသည် စွမ်းဆောင်ရည်၊ အထွတ်အထိပ်ရောက်ခြင်းများနှင့် breaking point တို့ကို ထောက်ကူပေးနိုင်ပါသည်။ အပလီကေးရှင်းတစ်ခုအား အတိုင်းအတာတစ်ခုချဲ့ထွင်ရန် စီစဉ်နေချိန်တွင် ဤဒေတာသည် အသုံးဝင်ပါသည်။ ဤအချက်အလက်ရရှိနိုင်ပါက ဆုံးဖြတ်ချက်များနှင့် အစီအမံများကို ပံ့ပိုးကူညီနိုင်မည်ဖြစ်ပြီး အထူးသဖြင့် ဖောက်သည်များ ထပ်မံပေါင်းထည့်ရန် အဖွဲ့အစည်းက စီစဉ်နေပါက၊ ပိုမိုဝင်ရောက်လာမည်ဟု ဆိုလိုသည်။တောင်းဆိုချက်များ။ သင့်အဖွဲ့အစည်းတွင် API စမ်းသပ်ခြင်းကို မိတ်ဆက်နည်း မည်သည့်အဖွဲ့အစည်းတွင်မဆို API စမ်းသပ်ခြင်းကို မိတ်ဆက်ခြင်းလုပ်ငန်းစဉ်သည် အခြားစမ်းသပ်ကိရိယာနှင့် မူဘောင်ကို အကောင်အထည်ဖော်ရန် သို့မဟုတ် အကောင်အထည်ဖော်ရန်အတွက် အသုံးပြုသည့်လုပ်ငန်းစဉ်နှင့် ဆင်တူသည်။ အောက်ပါဇယားသည် အဆင့်တစ်ဆင့်ချင်းစီ၏မျှော်မှန်းထားသောရလဒ်နှင့်အတူ အဓိကခြေလှမ်းများကို အကျဉ်းချုံးထားသည်။ အဆင့် အဆင့် မျှော်လင့်ထားသော ရလဒ် ကိရိယာ ရွေးချယ်မှု လိုအပ်ချက်များကို စုဆောင်းပြီး ကန့်သတ်ချက်များကို ခွဲခြားသတ်မှတ် သုတေသနအတွက် လိုအပ်ချက်များကို နားလည်ပါ သင့်လျော်သော API စမ်းသပ်ကိရိယာအတွက် စျေးကွက်။ ဥပမာ မည်သည့် API ကို စမ်းသပ်နေသည် - SOAP သို့မဟုတ် REST? ဤကဏ္ဍအတွက် စမ်းသပ်သူကို ငှားရမ်းရန် လိုအပ်ပါသလား သို့မဟုတ် လက်ရှိစမ်းသပ်သူကို လေ့ကျင့်ပေးရန် လိုအပ်ပါသလား။ မည်သည့်စမ်းသပ်မှုမျိုးလုပ်ဆောင်မည် - လုပ်ဆောင်နိုင်သော၊ စွမ်းဆောင်ရည်စမ်းသပ်မှုများ စသည်တို့ဖြစ်သည်။ အကောင်အထည်ဖော်ရန်အတွက် ဘတ်ဂျက်က မည်မျှရှိသနည်း။ ရနိုင်သောကိရိယာများကို အကဲဖြတ်ပါ ရနိုင်သောကိရိယာများနှင့် ဆန်ကာတင်စာရင်း 1 သို့မဟုတ် 2 ကိရိယာများကို နှိုင်းယှဉ်ကြည့်ပါ။ သဘောတရားဆိုင်ရာ အထောက်အထား ရွေးချယ်ထားသော ကိရိယာဖြင့် စမ်းသပ်မှုအစုခွဲတစ်ခုကို အကောင်အထည်ဖော်ပါ။ တွေ့ရှိချက်များကို သက်ဆိုင်သူများထံ တင်ပြပါ။ အကောင်ထည်ဖော်ရန် ကိရိယာကို အပြီးသတ်ပါ။ အကောင်အထည်ဖော်ခြင်း စတင်ခြင်း သင့်ရွေးချယ်မှု f tool ပေါ်မူတည်၍ လိုအပ်သော tool ကို PC၊ Virtual machine သို့မဟုတ် server တွင် ထည့်သွင်းရန် လိုအပ်ပါသည်။ ရွေးချယ်စရာ tool of subscription ကို အခြေခံထားလျှင်၊ လိုအပ်သောအဖွဲ့ကိုဖန်တီးပါ။အကောင့်များ။ လိုအပ်ပါက အဖွဲ့ကို လေ့ကျင့်ပေးပါ။ သွားပါ စမ်းသပ်မှုများ ပြုလုပ်ပါ စမ်းသပ်မှုများ လုပ်ဆောင်ပါ ချို့ယွင်းချက်များကို အစီရင်ခံပါ အဖြစ်များသော စိန်ခေါ်မှုများနှင့် ၎င်းတို့ကို လျော့ပါးစေရန် နည်းလမ်းများ QA အဖွဲ့များ၏ ဘုံစိန်ခေါ်မှုအချို့ကို ဆွေးနွေးကြပါစို့။ အဖွဲ့အစည်းတစ်ခုရှိ API စမ်းသပ်မှုဘောင်ကို အကောင်အထည်ဖော်ရန် ကြိုးပမ်းစဉ်တွင် ရင်ဆိုင်ရမည်။ #1) မှန်ကန်သောကိရိယာကို ရွေးချယ်ခြင်း အလုပ်အတွက် မှန်ကန်သောကိရိယာကို ရွေးချယ်ခြင်းသည် အသုံးအများဆုံးစိန်ခေါ်မှုဖြစ်သည်။ စျေးကွက်တွင်ရရှိနိုင်သော API စမ်းသပ်ကိရိယာများစွာရှိသည်။ စျေးကွက်တွင်ရရှိနိုင်သည့်နောက်ဆုံးပေါ်စျေးအကြီးဆုံးကိရိယာကိုအကောင်အထည်ဖော်ရန်အလွန်နှစ်သက်ဖွယ်ကောင်းပုံရသည်- သို့သော်၎င်းသည်အလိုရှိသောရလဒ်များကိုဆောင်ကြဉ်းမလာပါက၊ ထိုကိရိယာ အသုံးမဝင်ပါ။ ထို့ကြောင့် သင့်အဖွဲ့အစည်း၏လိုအပ်ချက်များအပေါ်အခြေခံ၍ 'မဖြစ်မနေလိုအပ်သော' လိုအပ်ချက်များကို ဖြည့်ဆည်းပေးသည့်ကိရိယာကို အမြဲတမ်းရွေးချယ်ပါ။ ဤသည်မှာ နမူနာကိရိယာအကဲဖြတ်မက်ထရစ်အတွက် နမူနာတစ်ခုဖြစ်သည်။ ရနိုင်သော API Tools Tool စျေးနှုန်း မှတ်စု Soap UI SoapUI Open Source (Functional testing) * REST၊ SOAP နှင့် အခြားသော နာမည်ကြီး API နှင့် IoT ပရိုတိုကောများအတွက် အခမဲ့ဗားရှင်းရရှိနိုင်သည်။ * အခမဲ့ဗားရှင်း SOAP နှင့် REST ad-hoc စမ်းသပ်ခြင်း Message Assertion ဆွဲယူ & Drop Test Creation Test Logs Test Configuration Test from Recordings Unit Reporting. * အင်္ဂါရပ်များစာရင်း အပြည့်အစုံဖြစ်နိုင်ပါသည်။ သူတို့ထဲမှာ တွေ့တယ်။ဝဘ်ဆိုဒ်။ စာပို့သမား အခမဲ့ Postman App ရနိုင်သည် * REST အတွက် အသုံးအများဆုံး။ * အင်္ဂါရပ်များကို ၎င်းတို့၏ဝဘ်ဆိုက်တွင် တွေ့နိုင်သည်။ Parasoft ၎င်းသည် အခပေးကိရိယာတစ်ခုဖြစ်ပြီး လိုင်စင်တစ်ခုဝယ်ယူပြီးနောက် တပ်ဆင်မှုလိုအပ်သည်။ ကိရိယာကို အသုံးမပြုမီ။ * ပြီးပြည့်စုံသော API စမ်းသပ်ခြင်း- လုပ်ဆောင်နိုင်သော၊ တင်နိုင်မှု၊ လုံခြုံရေးစမ်းသပ်မှု၊ စမ်းသပ်မှုဒေတာစီမံခန့်ခွဲမှု vREST အသုံးပြုသူအရေအတွက်အပေါ်အခြေခံ၍ * အလိုအလျောက် REST API စမ်းသပ်ခြင်း။ * အသံသွင်းပြီး ပြန်ဖွင့်ပါ။ * mock API များကို အသုံးပြု၍ ရှေ့တန်းနှင့် နောက်ကွယ်မှ မှီခိုမှုကို ဖယ်ရှားသည်။ * အားကောင်းသော တုံ့ပြန်မှု မှန်ကန်ကြောင်း အတည်ပြုခြင်း။ * localhost/intranet/internet တွင် အသုံးပြုထားသည့် စမ်းသပ်အက်ပ်လီကေးရှင်းများအတွက် အလုပ်လုပ်ပါသည်။ * JIRA Integration၊ Jenkins Integration Imports from Swagger, Postman. HttpMaster Express Edition- အခမဲ့ဒေါင်းလုဒ်လုပ်ရန် ပရော်ဖက်ရှင်နယ်ဗားရှင်း- အသုံးပြုသူအရေအတွက်အပေါ်အခြေခံ၍ * ဝဘ်ဆိုဒ်စမ်းသပ်ခြင်းအပြင် API စမ်းသပ်ခြင်းတွင် ကူညီပေးပါသည်။ * အခြားသော အင်္ဂါရပ်များသည် ကမ္ဘာလုံးဆိုင်ရာ ကန့်သတ်ချက်များကို သတ်မှတ်နိုင်စွမ်းရှိပြီး သုံးစွဲသူအား အတည်ပြုချက်အမျိုးအစားများစွာကို အသုံးပြုခြင်းဖြင့် ဒေတာတုံ့ပြန်မှုစစ်ဆေးခြင်းအတွက် စစ်ဆေးမှုများကို ဖန်တီးနိုင်စေပါသည်။ ၎င်းကိုပံ့ပိုးပေးပါသည်။ Runscope အသုံးပြုသူအရေအတွက်နှင့် အစီအစဉ်အမျိုးအစားများအပေါ်အခြေခံ၍ * API ၏ စောင့်ကြည့်စစ်ဆေးခြင်းနှင့် စမ်းသပ်ခြင်းအတွက်။ * ဒေတာမှန်ကန်ကြောင်း သေချာစေရန် ဒေတာအတည်ပြုခြင်းအတွက် အသုံးပြုနိုင်ပါသည်။ * ၏အင်္ဂါရပ်များပါရှိသည်။API အရောင်းအ၀ယ် ချို့ယွင်းမှုတစ်ခုခုအတွက် ခြေရာခံခြင်းနှင့် အသိပေးခြင်း (သင့်အပလီကေးရှင်းသည် ငွေပေးချေမှုအတည်ပြုချက်လိုအပ်ပါက၊ ဤကိရိယာသည် ကောင်းသောရွေးချယ်မှုတစ်ခုဖြစ်ကြောင်း သက်သေပြနိုင်သည်)။ LoadFocus အသုံးပြုသူအရေအတွက်နှင့် အစီအစဉ်အမျိုးအစားများပေါ်အခြေခံ၍ * API load testing အတွက် သုံးနိုင်သည် - API ပံ့ပိုးပေးနိုင်သော အသုံးပြုသူအရေအတွက်ကို သိရှိရန် စမ်းသပ်မှုအနည်းငယ်ကို လုပ်ဆောင်ခွင့်ပြုသည်။ * အသုံးပြုရ ရိုးရှင်းသည် - ဘရောက်ဆာအတွင်း စမ်းသပ်မှုများကို လုပ်ဆောင်ခွင့်ပြုသည်။ PingAPI ပရောဂျက် 1 ခုအတွက် အခမဲ့ (တောင်းဆိုချက် 1,000 ) * အလိုအလျောက် API စမ်းသပ်ခြင်းနှင့် စောင့်ကြည့်ခြင်းအတွက် အကျိုးရှိသည်။ #2) ပျောက်ဆုံးနေသော စမ်းသပ်မှုဆိုင်ရာ သတ်မှတ်ချက်များ စမ်းသပ်သူများအနေဖြင့် ကျွန်ုပ်တို့ သိရန်လိုအပ်သည် အက်ပလီကေးရှင်းကို ထိထိရောက်ရောက် စမ်းသပ်ရန် မျှော်လင့်ထားသည့် ရလဒ်များ။ ၎င်းသည် မကြာခဏဆိုသလို စိန်ခေါ်မှုတစ်ခုဖြစ်သည်၊ မျှော်မှန်းထားသည့်ရလဒ်များကို သိရှိရန်အတွက် ကျွန်ုပ်တို့တွင် ရှင်းလင်းတိကျသောလိုအပ်ချက်များ ရှိရန် လိုအပ်ပါသည် – ယင်းသည် ကိစ္စမဟုတ်ပေ။ ဥပမာ အတွက်၊ အောက်တွင်ပေးထားသည့် လိုအပ်ချက်များကို သုံးသပ်ကြည့်ပါ- “လျှောက်လွှာသည် တရားဝင် တင်ပို့သည့်ရက်စွဲကိုသာ လက်ခံသင့်ပြီး မမှန်ကန်သော လိုအပ်ချက်များအားလုံးကို ပယ်ချသင့်သည်” ဤလိုအပ်ချက်များသည် သော့ချက်အသေးစိတ်များ လွဲချော်နေပြီး အလွန်ရှင်းလင်းရှင်းလင်းနေသည် – တရားဝင်ရက်စွဲကို ကျွန်ုပ်တို့ မည်သို့သတ်မှတ်မည်နည်း။ ဖော်မတ်ကော။ ကျွန်ုပ်တို့သည် အဆုံးအသုံးပြုသူထံ ငြင်းဆိုထားသည့် မက်ဆေ့ဂျ်ကို ပြန်ပေးမလား။ မှန်ကန်သော ပို့ဆောင်မည့်ရက်စွဲကို လက်ခံပါ။ တင်ပို့သည့်ရက်စွဲသည် မှန်ကန်သည်ဟု ယူဆပါသည်။သည် အတိတ်တွင်မဟုတ်ပါ ယနေ့ရက်စွဲထက် ပိုကြီးသည် သို့မဟုတ် တူညီသည် လက်ခံနိုင်သောပုံစံဖြစ်သည်- DD/MM/YYYY 2) တုံ့ပြန်မှုအခြေအနေကုဒ် = 200 မက်ဆေ့ဂျ်- OK 3) ပေးပို့သည့်ရက်စွဲ အထက်ဖော်ပြပါ သတ်မှတ်ချက်များနှင့် မကိုက်ညီပါက မမှန်ကန်ဟု ယူဆသင့်ပါသည်။ ဝယ်ယူသူသည် မမှန်ကန်သော ပို့ဆောင်မည့်ရက်စွဲကို ပေးပို့ပါက၊ ၎င်းသည် အောက်ပါ အမှားအယွင်း မက်ဆေ့ချ်(များ) ဖြင့် တုံ့ပြန်ရပါမည်- 3.1 တုံ့ပြန်မှု အခြေအနေကုဒ် 200 မဟုတ်ပါ အမှား- ပေးပို့သည့်ရက်စွဲသည် မမှန်ကန်ပါ။ ရက်စွဲသည် DD/MM/YYYY ဖော်မတ်ဖြစ်ကြောင်း သေချာစေပါ 3.2 တုံ့ပြန်မှုအခြေအနေကုဒ် 200 မဟုတ်ပါ အမှား- ပေးထားသော ပို့ဆောင်မည့်ရက်စွဲသည် တည်ရှိနေပါသည်။ အတိတ် #3) Learning Curve ယခင်ဖော်ပြခဲ့သည့်အတိုင်း၊ API စမ်းသပ်ခြင်းအတွက် ချဉ်းကပ်ပုံသည် GUI အခြေပြု အက်ပ်လီကေးရှင်းများကို စမ်းသပ်စဉ် လိုက်နာလုပ်ဆောင်ခဲ့သည့် ချဉ်းကပ်နည်းနှင့် နှိုင်းယှဉ်ပါက ကွဲပြားပါသည်။ အကယ်၍ သင်သည် API စစ်ဆေးမှုအတွက် ကျွမ်းကျင်သူများကို အိမ်တွင်း သို့မဟုတ် အတိုင်ပင်ခံများကို ငှားရမ်းနေပါသည်၊ ထို့နောက် API စမ်းသပ်မှုချဉ်းကပ်မှု သို့မဟုတ် API စမ်းသပ်ကိရိယာ၏ သင်ယူမှုမျဉ်းကွေးမှာ အနည်းငယ်မျှသာ ရှိနိုင်ပါသည်။ ဤအခြေအနေတွင် မည်သည့် သင်ယူမှုမျဉ်းကွေးသည် ထုတ်ကုန် သို့မဟုတ် အသုံးချပလီကေးရှင်း အသိပညာရရှိခြင်းနှင့် ဆက်စပ်နေမည်ဖြစ်သည်။ လက်ရှိအဖွဲ့၀င်တစ်ဦးအား API စမ်းသပ်ခြင်းအား လေ့လာရန် တာဝန်ပေးအပ်ပါက၊ ရွေးချယ်သည့်ကိရိယာပေါ် မူတည်၍ သင်ယူမှုမျဉ်းသည် ဖြစ်နိုင်သည်။ အလယ်အလတ်မှ အမြင့်သို့ စမ်းသပ်နည်းကို ပြောင်းလဲခြင်းနှင့်အတူ။ ထုတ်ကုန် သို့မဟုတ် အပလီကေးရှင်းအတွက် သင်ယူမှုမျဉ်းကွေးသည် ဤစမ်းသပ်သူအား စမ်းသပ်ထားခြင်းရှိမရှိပေါ် မူတည်၍ အနိမ့်အလယ်အလတ်ဖြစ်နိုင်သည်။အဆိုပါ အက်ပ်လီကေးရှင်း မတိုင်မီ သို့မဟုတ် မပြုမီ။ #4) ရှိပြီးသား ကျွမ်းကျင်မှု သတ်မှတ် ၎င်းသည် သင်ယူမှုမျဉ်းကွေးနှင့် ပတ်သက်သော ယခင်အချက်နှင့် တိုက်ရိုက် ဆက်စပ်နေပါသည်။ စမ်းသပ်သူမှ ကူးပြောင်းနေပါက၊ GUI အခြေခံ စမ်းသပ်ခြင်း ၊ ထို့နောက် စမ်းသပ်သူသည် စမ်းသပ်မှု ချဉ်းကပ်ပုံကို ပြောင်းလဲကာ လိုအပ်သလို လိုအပ်သလို ကိရိယာအသစ် သို့မဟုတ် မူဘောင်ကို လေ့လာရန် လိုအပ်ပါသည်။ ဥပမာ API သည် JSON ဖော်မတ်ဖြင့် တောင်းဆိုမှုများကို လက်ခံပါက၊ စမ်းသပ်သူသည် စမ်းသပ်မှုများကို စတင်ရန်အတွက် JSON ဆိုသည်မှာ ဘာလဲ လေ့လာရန် လိုအပ်ပါသည်။ Case Study လုပ်ငန်းဆောင်တာ ရှိပြီးသား အပလီကေးရှင်းကို ချဲ့ထွင်ရန်အတွက် ကုမ္ပဏီတစ်ခုသည် API နှင့် ပုံမှန် GUI အက်ပ်လီကေးရှင်းတွင် ထုတ်ကုန်တစ်ခုကို ကမ်းလှမ်းလိုသည်။ ပုံမှန် GUI အခြေခံစစ်ဆေးမှုများထက် API စမ်းသပ်မှုများကို လိုက်လျောညီထွေဖြစ်စေရန်အတွက် ၎င်းတို့သည် အဆင်သင့်ဖြစ်နေကြောင်း သေချာစေရန် QA အဖွဲ့အား စမ်းသပ်မှုအစီအစဉ်ကို ပံ့ပိုးပေးရန် တောင်းဆိုခဲ့သည်။ စိန်ခေါ်မှုများ မရှိပါ အခြားဆော့ဖ်ဝဲလ်ထုတ်ကုန်များတွင် API အခြေခံဗိသုကာလက်ရာများပါရှိသောကြောင့် ဤလုပ်ငန်းဆောင်တာတွင် စမ်းသပ်ခြင်းကို လိုက်လျောညီထွေဖြစ်စေရန်အတွက် အဖွဲ့သည် API စမ်းသပ်မှုလုပ်ငန်းစဉ်ကို အစမှစတင်လုပ်ဆောင်ရန် လိုအပ်ပါသည်။ ဆိုလိုသည်မှာ ကိရိယာများကို အကဲဖြတ်ရန်၊ ဆန်ခါတင်စာရင်း၊ အပြီးသတ်ပြီး အဖွဲ့သည် စာမေးပွဲများအတွက် လေ့ကျင့်ပေးရမည်ဖြစ်သည်။ ကိရိယာကို ရယူရန်နှင့် အကောင်အထည်ဖော်ရန်အတွက် အပိုဘတ်ဂျက်ခွဲဝေပေးခြင်းမရှိပါ။ ဆိုလိုသည်မှာ အဖွဲ့သည် အခမဲ့ သို့မဟုတ် open-source API စမ်းသပ်ခြင်းတူးလ်ကို ရွေးချယ်ရမည်ဖြစ်ပြီး ဤလုပ်ငန်းကို လုပ်ဆောင်ရန် ရှိပြီးသားအဖွဲ့မှ တစ်စုံတစ်ဦးအား လေ့ကျင့်ပေးရမည်ဖြစ်သည်။ API အကွက်များနှင့် ဒေတာအတွက် လိုအပ်ချက်များ မရှိပါအတည်ပြုချက်။ လိုအပ်ချက်များသည် "သက်ဆိုင်ရာ GUI အပလီကေးရှင်းနှင့် အတူတူပင် လုပ်ဆောင်သင့်သည်"။ 20>QA အဖွဲ့သည် အောက်ပါလိုအပ်ချက်များကို ဖော်ထုတ်ရန် ပရောဂျက်အဖွဲ့နှင့်အတူ လုပ်ဆောင်ခဲ့သည်- API အမျိုးအစား (REST/SOAP): REST လိုအပ်သော စမ်းသပ်မှုများ (Functional၊ Load၊ လုံခြုံရေး): လုပ်ဆောင်နိုင်သော စမ်းသပ်ခြင်းသာ အလိုအလျောက် စမ်းသပ်မှုများ လိုအပ်သည် (Yes/No): ယခုအတွက် ရွေးချယ်နိုင်သည် စမ်းသပ်မှု အစီရင်ခံစာများ (Yes/No) ): လိုအပ်သည် QA အဖွဲ့သည် မရှိမဖြစ် လိုအပ်ချက်များအပေါ် အခြေခံ၍ ရရှိနိုင်သော API စမ်းသပ်ကိရိယာများပေါ်တွင် ကိရိယာတန်ဆာပလာများကို အကဲဖြတ်ခဲ့ပါသည်။ Postman API Tool သည် အခမဲ့ဖြစ်ပြီး အသုံးပြုရလွယ်ကူသောကြောင့် သင်ယူမှုမျဉ်းကွေးကို နည်းပါးစေပြီး စမ်းသပ်မှုများကို အလိုအလျောက်လုပ်ဆောင်နိုင်သည့် အလားအလာရှိကာ ကောင်းမွန်သော inbuilt အစီရင်ခံစာများပါရှိသောကြောင့် ၎င်းတို့ရွေးချယ်သည့်ကိရိယာအဖြစ် အပြီးသတ်ထားပါသည်။ အပလီကေးရှင်းကို စမ်းသပ်ခဲ့သည့် အလားတူစမ်းသပ်သူသည် Postman ကို အသုံးပြုရန်အတွက် ကနဦးစမ်းသပ်မှုများကို ဖန်တီးကာ ထုတ်ကုန်အသိပညာကွာဟချက်များအား ဖယ်ရှားပေးပါသည်။ ပျောက်ဆုံးနေသောလိုအပ်ချက်များကို ကိုင်တွယ်ဖြေရှင်းရန်၊ ပရောဂျက်အဖွဲ့သည် Swagger ကို အသုံးပြု၍ အဆင့်မြင့်နယ်ပယ်အဆင့် စာရွက်စာတမ်းများကို တည်ဆောက်ခဲ့သည်။ . သို့သော် ၎င်းသည် လက်ခံနိုင်သော ဒေတာဖော်မတ်များ၏ စည်းကမ်းချက်များ၌ ကွာဟချက်အချို့ကို ချန်ထားခဲ့ကာ ၎င်းကို ပရောဂျက်အဖွဲ့နှင့် ခေါ်ယူခဲ့ပြီး မျှော်လင့်ထားသည့် ဖော်မတ်များကို သဘောတူပြီး မှတ်တမ်းတင်ခဲ့သည်။ နိဂုံး API အခြေပြု အပလီကေးရှင်းများ ရှိသည် မကြာသေးမီအချိန်များတွင်ရေပန်းစားခဲ့သည်။ ဒီ Application တွေက ပိုများတယ်။သမားရိုးကျ အပလီကေးရှင်း/ဆော့ဖ်ဝဲလ်များနှင့် နှိုင်းယှဉ်၍ အရွယ်အစား ချဲ့ထွင်နိုင်ပြီး အခြားသော APIs သို့မဟုတ် အပလီကေးရှင်းများနှင့် ပိုမိုလွယ်ကူစွာ ပေါင်းစည်းနိုင်စေပါသည်။ ဤ API စမ်းသပ်ခြင်း သင်ခန်းစာတွင် API Testing၊ Shift Left Testing၊ Web Services နှင့် Web API အကြောင်းအားလုံးကို အသေးစိတ် ရှင်းပြထားသည်။ ဥပမာများဖြင့် Web Services နှင့် Web API အကြား ခြားနားချက်များကိုလည်း လေ့လာခဲ့သည်။ သင်ခန်းစာ၏ ဒုတိယအပိုင်းတွင် API Testing ၏ spectrum အပြည့်အစုံ၊ သင့်အဖွဲ့အစည်းတွင် API Testing ကို မည်သို့မိတ်ဆက်နည်းနှင့် ဘုံစိန်ခေါ်မှုအချို့ကို ဆွေးနွေးခဲ့ကြပါသည်။ ၎င်းတို့အတွက် ဖြေရှင်းနည်းများနှင့်အတူ ဤလုပ်ငန်းစဉ်ကို ကြည့်ပါ။ ဥပမာများနှင့်အတူ ဝဘ်ဝန်ဆောင်မှုများအကြောင်း ပိုမိုသိရှိရန် ကျွန်ုပ်တို့၏လာမည့်သင်ခန်းစာကို ကြည့်ပါ!! နောက်တစ်ခု ကျူတိုရီရယ် ဝန်ဆောင်မှုများ ကျူတိုရီရယ်တွင် ဗိသုကာ၊ အမျိုးအစားများနှင့် ရှင်းပြထားသည်။ အရေးကြီးသော အသုံးအနှုန်းများနှင့်အတူ ဝဘ်ဝန်ဆောင်မှုများ၏ အစိတ်အပိုင်းများနှင့် SOAP နှင့် REST အကြား ကွာခြားချက်များ။
Tutorial_#3:	ထိပ်တန်း 35 ASP.Net နှင့် Web API အင်တာဗျူးမေးခွန်းများ အဖြေများ သင်သည် လူကြိုက်အများဆုံးမေးလေ့ရှိသော ASP.Net နှင့် Web API အင်တာဗျူးမေးခွန်းများကို အဖြေများနှင့်အတူ အဖြေများ & ဤကျူတိုရီရယ်တွင် စတင်သူများနှင့် အတွေ့အကြုံရှိ ကျွမ်းကျင်ပညာရှင်များအတွက် နမူနာများ။
Tutorial_#4:	POSTMAN ကျူတိုရီရယ်- API စမ်းသပ်အသုံးပြုခြင်း POSTMAN ဤသင်ခန်းစာတွင် အဆင့်တစ်ဆင့်ပြီးတစ်ဆင့် POSTMAN အသုံးပြုခြင်း API စမ်းသပ်ခြင်းအား POSTMAN ၏ အခြေခံများ၊ ၎င်း၏ အစိတ်အပိုင်းများနှင့် နမူနာတောင်းဆိုချက် & သင့်နားလည်လွယ်စေရန် ရိုးရှင်းသောစကားလုံးများဖြင့် တုံ့ပြန်ပါ။
Tutorial_#5:	Apache HTTP Client ကိုအသုံးပြု၍ ဝဘ်ဝန်ဆောင်မှုများကို စမ်းသပ်ခြင်း ဤ API ကျူတိုရီရယ်သည် Apache HTTP Client ကို အသုံးပြု၍ ဝဘ်ဝန်ဆောင်မှုများပေါ်တွင် CRUD လုပ်ဆောင်ချက်အမျိုးမျိုးကို လုပ်ဆောင်ခြင်းနှင့် Apache HTTP Client

API စမ်းသပ်ခြင်း ကျူတိုရီရယ်

ဤကဏ္ဍသည် သင့်အား Web Services နှင့် Web API ၏ အခြေခံနားလည်မှုကို ရရှိရန် ကူညီပေးမည်ဖြစ်ပြီး ၎င်းသည် ဤ API စမ်းသပ်ခြင်းစီးရီးရှိ လာမည့်သင်ခန်းစာများတွင် အဓိကသဘောတရားများကို နားလည်သဘောပေါက်ရန် အထောက်အကူဖြစ်စေမည်ဖြစ်သည်။

API ( Application Programming Interface) သည် ကျွန်ုပ်တို့အား ဒေတာ သို့မဟုတ် အင်္ဂါရပ်များကို ဝင်ရောက်ကြည့်ရှုခြင်းဖြင့် အပလီကေးရှင်းတစ်ခု ဖန်တီးနိုင်စေမည့် လုပ်ထုံးလုပ်နည်းများနှင့် လုပ်ဆောင်ချက်များအားလုံးကို အစုအဝေးတစ်ခုဖြစ်သည်။လည်ပတ်မှုစနစ် သို့မဟုတ် ပလပ်ဖောင်းများ။ ထိုသို့သောလုပ်ထုံးလုပ်နည်းများကိုစမ်းသပ်ခြင်းအား API Testing ဟုခေါ်သည်။

Shift Left Testing

API Testing Interviews တွင်ယနေ့တောင်းဆိုနေသည့် အရေးကြီးသောစမ်းသပ်မှုအမျိုးအစားတစ်ခုမှာ Shift Left Testing ဖြစ်သည်။ ဤစမ်းသပ်ခြင်းအမျိုးအစားကို Agile Methodology လိုက်နာသည့် ပရောဂျက်အားလုံးနီးပါးတွင် ကျင့်သုံးပါသည်။

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

ထို့အပြင်၊ (မထုတ်လုပ်မီ နောက်ဆုံးအဆင့်တွင် ချို့ယွင်းချက်များကို အစီရင်ခံတင်ပြသောအခါ) သည် developer များသည် ဒီဇိုင်းနှင့် coding အဆင့် နှစ်ခုလုံးကို ထပ်ပြီး ဖြတ်သန်းခဲ့ရသောကြောင့် ကြီးမားလှပါသည်။

Software Development Life Cycle (SDLC) ကို Shift Left Testing မတိုင်မီ

Tradional SDLC flow မှာ- လိုအပ်ချက် – > ဒီဇိုင်း –> Coding –> စမ်းသပ်ခြင်း။

အစဉ်အလာစမ်းသပ်ခြင်း၏ အားနည်းချက်များ

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

ထို့ကြောင့်၊ ထို့ကြောင့် Shift Left Testing သို့ ဦးတည်စေသည့် စမ်းသပ်မှုအဆင့်ကို ဘယ်ဘက်သို့ ရွှေ့ရန် အိုင်ဒီယာအသစ်တစ်ခု ထွက်ပေါ်လာသည်။

အကြံပြုထားသည် Read => Shift Left Testing- Aဆော့ဖ်ဝဲလ်အောင်မြင်မှုအတွက် လျှို့ဝှက်မန္တန်

ဘယ်ဘက်ပြောင်းရွေ့မှုစမ်းသပ်ခြင်းအဆင့်များ

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

Web API

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

API တစ်ခု မည်သို့အလုပ်လုပ်သနည်း။

လေကြောင်းလိုင်းများစွာမှ အချက်အလက်များကို စုစည်းပေးသည့် အွန်လိုင်းခရီးသွားဝန်ဆောင်မှုဖြစ်သည့် www.makemytrip.com တွင် လေယာဉ်ကြိုတင်စာရင်းသွင်းခြင်း၏ ဘုံဇာတ်လမ်းကို ကြည့်ကြပါစို့။ လေယာဉ်ဘွတ်ကင်အတွက်သွားသောအခါ၊ ခရီးရက်စွဲ/ပြန်လာမည့်ရက်စွဲ၊ အတန်းစသည်ဖြင့် အချက်အလက်များကို ရိုက်ထည့်ကာ ရှာဖွေမှုကို နှိပ်ပါ။

၎င်းက လေကြောင်းလိုင်းများစွာ၏ စျေးနှုန်းနှင့် ၎င်းတို့၏ရရှိနိုင်မှုကို သင့်အားပြသမည်ဖြစ်သည်။ ဤကိစ္စတွင်၊ အပလီကေးရှင်းသည် လေကြောင်းလိုင်းများစွာ၏ APIs များနှင့် အပြန်အလှန်အကျိုးသက်ရောက်ပြီး လေကြောင်းလိုင်း၏ဒေတာကို ဝင်ရောက်ကြည့်ရှုခွင့်ပေးသည်။

အခြားဥပမာမှာ မတူညီသောဟိုတယ်များ၏ ဈေးနှုန်း၊ ရရှိနိုင်မှုစသည်တို့ကို နှိုင်းယှဉ်ဖော်ပြသည့် www.trivago.com ဖြစ်သည်။ သီးခြားမြို့မှ။ ဤဝဘ်ဆိုက်သည် ဒေတာဘေ့စ်ကိုဝင်ရောက်ကြည့်ရှုရန် ဟိုတယ်အများအပြား၏ API များနှင့် ဆက်သွယ်ပြီး ၎င်းတို့၏ဝဘ်ဆိုဒ်မှ စျေးနှုန်းများနှင့်ရရှိနိုင်မှုတို့ကို စာရင်းပြုစုထားသည်။

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

ဝဘ်ဝန်ဆောင်မှုများ

ဝဘ်ဝန်ဆောင်မှုများသည် (ဝဘ် API ကဲ့သို့) စက်တစ်ခုမှ အခြားဝန်ဆောင်မှုများကို ဝန်ဆောင်မှုပေးသည်။ ဒါပေမယ့် API နဲ့ Web Services တို့ရဲ့ အဓိက ကွာခြားချက်ကတော့ Web Services က ကွန်ရက်ကို အသုံးပြုတာပဲဖြစ်ပါတယ်။

ဝဘ်ဝန်ဆောင်မှုအားလုံးဟာ Web APIs တွေလို့ ပြောလို့ရပေမယ့် Web API တွေအားလုံးဟာ Web Services တွေမဟုတ်ပါဘူး (ထဲမှာ ရှင်းပြထားပါတယ်။ ဆောင်းပါး၏နောက်ဆုံးအပိုင်း။) ထို့ကြောင့်၊ Web Services သည် Web API ၏ အခွဲတစ်ခုဖြစ်သည်။ Web API နှင့် ဝဘ်ဝန်ဆောင်မှုများအကြောင်း ပိုမိုသိရှိရန် အောက်ပါပုံတွင် ကိုးကားပါ။

ဝဘ် API နှင့် ဝဘ်ဝန်ဆောင်မှုများ

ဝဘ်ဝန်ဆောင်မှုများနှင့် Web API

Web API နှင့် Web Services နှစ်ခုလုံးကို client နှင့် server အကြား ဆက်သွယ်မှု အဆင်ပြေစေရန်အတွက် အသုံးပြုပါသည်။ အဓိက ကွာခြားချက်မှာ ၎င်းတို့ ဆက်သွယ်သည့် နည်းလမ်းဖြင့်သာ ထွက်ပေါ်လာခြင်းဖြစ်သည်။

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

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

ဝဘ်ဝန်ဆောင်မှု

• ဝဘ်ဝန်ဆောင်မှုများသည် ယေဘူယျအားဖြင့် XML (Extensible Markup Language) ကိုအသုံးပြုသည်ဆိုလိုသည်မှာ ၎င်းတို့သည် ပိုမိုလုံခြုံသည်ဟုဆိုလိုသည်။
• ဒေတာပေးပို့စဉ်တွင် Web Services နှင့် API နှစ်ခုလုံးသည် SSL (Secure Socket Layer) ကို ပံ့ပိုးပေးသောကြောင့် ဝဘ်ဝန်ဆောင်မှုများသည် ပိုမိုလုံခြုံပါသည်။ ဒါပေမယ့်လည်း WSS (Web Services Security) ကို ပေးစွမ်းပါတယ်။
• ဝဘ်ဝန်ဆောင်မှုဟာ ဝဘ် API ရဲ့ အစုခွဲတစ်ခုပါ။ ဥပမာ၊ ဝဘ်ဝန်ဆောင်မှုများသည် အသုံးပြုမှုပုံစံသုံးမျိုးပေါ်တွင်သာ အခြေခံထားပါသည် ဥပမာ SOAP၊ REST နှင့် XML-RPC။
• ဝဘ်ဝန်ဆောင်မှုများသည် အမြဲတမ်းလည်ပတ်ရန်အတွက် ကွန်ရက်တစ်ခု လိုအပ်ပါသည်။
• ဝဘ်ဝန်ဆောင်မှုများသည် “One Code မတူညီသောအက်ပ်လီကေးရှင်းများ” ကို ပံ့ပိုးပေးသည်။ ဆိုလိုသည်မှာ မတူညီသော အပလီကေးရှင်းများတွင် ပိုမိုယေဘုယျကုဒ်ကို ရေးသားထားသည်။

ဝဘ် API

• ဝဘ် API သည် ယေဘူယျအားဖြင့် JSON (JavaScript Object Notation) ကို အသုံးပြုသည်။ ဆိုလိုသည်မှာ Web API သည် ပိုမိုမြန်ဆန်သည်ဟုဆိုလိုသည်။
• JSON သည် XML နှင့်မတူဘဲ ပေါ့ပါးသောကြောင့် ဝဘ် API သည် ပိုမိုမြန်ဆန်သည်။
• ဝဘ် API များသည် ဝဘ်ဝန်ဆောင်မှုများ၏ superset ဖြစ်သည်။ ဥပမာ၊ ဝဘ်ဝန်ဆောင်မှုများ၏ ပုံစံသုံးမျိုးစလုံးသည် Web API တွင်လည်း ရှိနေသည်၊ သို့သော် ၎င်းအပြင် JSON – RPC ကဲ့သို့သော အခြားစတိုင်များကို အသုံးပြုပါသည်။
• ဝဘ် API မလိုအပ်ပါ။ လည်ပတ်ရန် ကွန်ရက်တစ်ခု။
• ဝဘ် API သည် စနစ် သို့မဟုတ် အပလီကေးရှင်း၏ သဘောသဘာဝအပေါ် မူတည်၍ အပြန်အလှန်လုပ်ဆောင်နိုင်မှုကို ပံ့ပိုးပေးနိုင်သည် သို့မဟုတ် မပေးနိုင်ပါ။

သင့်အဖွဲ့အစည်းတွင် API စမ်းသပ်ခြင်းကို မိတ်ဆက်ခြင်း

ကျွန်ုပ်တို့၏နေ့စဉ်ဘ၀တွင်၊ ကျွန်ုပ်တို့အားလုံးသည် APIs များဖြင့် Apps များနှင့် အပြန်အလှန်ဆက်ဆံရာတွင် အလွန်အသုံးများကြပြီး နောက်ခံလုပ်ဆောင်နိုင်စွမ်းကို မောင်းနှင်ပေးသည့် back-end လုပ်ငန်းစဉ်များကိုပင် ကျွန်ုပ်တို့ မစဉ်းစားကြပါ။

ဥပမာ , သင်သည် Amazon.com ပေါ်ရှိ ထုတ်ကုန်များကို ကြည့်ရှုနေပြီး သင်အမှန်တကယ် နှစ်သက်သည့် ကုန်ပစ္စည်း/သဘောတူညီချက်ကို သင်မြင်ရပြီး ၎င်းကို သင်၏ Facebook ကွန်ရက်နှင့် မျှဝေလိုကြောင်း သုံးသပ်ကြည့်ကြပါစို့။

သင်နှိပ်လိုက်သည့်အခိုက်အတန့် စာမျက်နှာ၏မျှဝေမှုအပိုင်းရှိ Facebook အိုင်ကွန်ပေါ်တွင် သင်၏ရိုက်ထည့်ပါ။မျှဝေရန် Facebook အကောင့်အထောက်အထားများ ၊ သင်သည် Amazon ဝဘ်ဆိုက်ကို Facebook နှင့် ချောမွေ့စွာ ချိတ်ဆက်ပေးသည့် API တစ်ခုနှင့် အပြန်အလှန် တုံ့ပြန်နေပါသည်။

Focus Shift to API Testing

API စမ်းသပ်ခြင်းအကြောင်း နောက်ထပ် မဆွေးနွေးမီ အကြောင်းရင်းကို ဆွေးနွေးကြပါစို့။ API အခြေပြု အက်ပ်လီကေးရှင်းများသည် မကြာသေးမီအချိန်က လူကြိုက်များခဲ့သည်။

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

#1) API အခြေခံ အက်ပ်လီကေးရှင်းများသည် သမားရိုးကျ အပလီကေးရှင်း/ဆော့ဖ်ဝဲလ်များနှင့် နှိုင်းယှဉ်ပါက ပို၍ အရွယ်အစား ကြီးမားပါသည်။ ကုဒ်ဖွံ့ဖြိုးတိုးတက်မှုနှုန်းသည် ပိုမိုမြန်ဆန်ပြီး တူညီသော API သည် ကြီးကြီးမားမားကုဒ် သို့မဟုတ် အခြေခံအဆောက်အအုံဆိုင်ရာပြောင်းလဲမှုများမပါဘဲ နောက်ထပ်တောင်းဆိုမှုများကို ဝန်ဆောင်မှုပေးနိုင်ပါသည်။

#2) ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့များသည် ကုဒ်ရေးခြင်းကို အစမှစတင်လုပ်ဆောင်ရန် မလိုအပ်ပါ။ ၎င်းတို့သည် အင်္ဂါရပ် သို့မဟုတ် အက်ပ်လီကေးရှင်းတစ်ခုကို စတင်တီထွင်သည့်အချိန်ဖြစ်သည်။ API များသည် အများစုမှာ ရှိပြီးသား၊ ထပ်တလဲလဲနိုင်သော လုပ်ဆောင်ချက်များ၊ စာကြည့်တိုက်များ၊ သိမ်းဆည်းထားသော လုပ်ထုံးလုပ်နည်းများ စသည်တို့ကို ပြန်လည်အသုံးပြုလေ့ရှိပြီး ဤလုပ်ငန်းစဉ်သည် ၎င်းတို့အား အလုံးစုံ ပိုမိုအကျိုးဖြစ်ထွန်းစေနိုင်သည်။

ဥပမာ၊ သင်သည် ဆော့ဖ်ဝဲတစ်ခုတွင် လုပ်ဆောင်နေသူဖြစ်ပါက၊ e-commerce ဝဘ်ဆိုက်နှင့် Amazon ကို ငွေပေးချေမှု ပရိုဆက်ဆာအဖြစ် ထည့်လိုသည် - ထို့နောက်တွင် သင်သည် ကုဒ်ကို အစမှ ရေးရန် မလိုအပ်ပါ။

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

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

ဥပမာ ၊ သင်သည် Toronto မှ New York သို့ သင်္ဘောတစ်စင်း ပေးပို့လိုကြောင်း သုံးသပ်ကြည့်ကြပါစို့။ . သင်သည် အွန်လိုင်းတက်ပြီး၊ ကောင်းစွာသိသော ကုန်စည်ပို့ဆောင်ရေး သို့မဟုတ် ထောက်ပံ့ပို့ဆောင်ရေး ဝဘ်ဆိုက်သို့ သွားပြီး လိုအပ်သော အချက်အလက်ကို ရိုက်ထည့်ပါ။

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

API စမ်းသပ်ခြင်း၏ Spectrum အပြည့်အစုံ

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

၎င်းကို အသေးစိတ် ဆွေးနွေးကြည့်ကြပါစို့။

(i) Functional Testing

GUI အင်တာဖေ့စ်မရှိခြင်းကြောင့် လုပ်ဆောင်ချက်ဆိုင်ရာ စမ်းသပ်ခြင်းမှာ စိန်ခေါ်မှုတစ်ခုဖြစ်သည်။

APIs များအတွက် လုပ်ဆောင်နိုင်သော စမ်းသပ်မှုချဉ်းကပ်ပုံသည် GUI အခြေခံ အက်ပ်လီကေးရှင်းနှင့် မည်သို့ကွာခြားသည်ကို ကြည့်ကြစို့၊ ၎င်းနှင့်ပတ်သက်သော ဥပမာအချို့ကိုလည်း ဆွေးနွေးပါမည်။

a) အထင်ရှားဆုံးကွာခြားချက်မှာ အပြန်အလှန်တုံ့ပြန်ရန် GUI မရှိပါ။ GUI အခြေပြု လုပ်ဆောင်ချက်ဆိုင်ရာ စမ်းသပ်မှုများ ပြုလုပ်လေ့ရှိသော စမ်းသပ်သူများသည် နှိုင်းယှဉ်ပါက GUI မဟုတ်သော အပလီကေးရှင်း စမ်းသပ်ခြင်းသို့ ကူးပြောင်းရန် အနည်းငယ် ခက်ခဲသည် ။၎င်းနှင့်ရင်းနှီးပြီးသားသူတစ်ဦး။

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

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

b) စမ်းသပ်ခြင်းနယ်ပယ်တွင် တရားဝင်မှုများ သို့မဟုတ် ထည့်သွင်းဒေတာအတည်ပြုခြင်းသည် အလွန်အရေးကြီးပါသည်။ APIs စမ်းသပ်နေစဉ်။ အမှန်တကယ် ဖောင်အခြေခံ (GUI) အင်တာဖေ့စ်ကို ရရှိနိုင်ပါက၊ ထို့နောက် ကွင်းဆင်းစစ်ဆေးချက်များကို ရှေ့ဆုံး သို့မဟုတ် နောက်တန်းတွင် အကောင်အထည်ဖော်နိုင်သည်၊ ထို့ကြောင့် အသုံးပြုသူတစ်ဦးသည် မမှန်ကန်သော အကွက်တန်ဖိုးများကို ထည့်သွင်းခွင့်မပြုကြောင်း သေချာစေသည်။

ဥပမာအားဖြင့်၊ အပလီကေးရှင်းတစ်ခုတွင် ရက်စွဲဖော်မတ်သည် DD/MM/YYYY ဖြစ်ရန် လိုအပ်ပါက၊ လျှောက်လွှာမှ တရားဝင်ရက်စွဲကို လက်ခံရရှိပြီး စီမံဆောင်ရွက်ပေးကြောင်း သေချာစေရန်အတွက် ဤတရားဝင်မှုကို ကျွန်ုပ်တို့ လျှောက်ထားနိုင်ပါသည်။

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

c) စမ်းသပ်ခြင်း။