ဤဆောင်းပါး၌ကျွန်ုပ်တို့သည်အသုံးအများဆုံးစမ်းသပ်အလိုအလျောက်မှားယွင်းသောယူဆချက်အချို့နှင့်ဤအဖွဲ့အစည်းများစမ်းသပ်အလိုအလျောက်အတွက်အောင်မြင်သောကနေတားဆီးဘယ်လိုဆန်းစစ်ရလိမ့်မည်။
ထုတ်ကုန်ဖွံ့ဖြိုးတိုးတက်မှုနှင့်အတူအလိုအလျောက်စမ်းသပ်ခြင်းရှိခြင်း၏အကျိုးကျေးဇူးများကိုစဉ်းစားရန်မလွယ်ကူပါ။ ပိုမိုမြန်ဆန်သောထုတ်လွှတ်မှုများ၊ တိုးမြှင့်ထားသည့်စမ်းသပ်မှုများ၊ မကြာခဏစမ်းသပ်မှုများပြုလုပ်မှု၊ ဖွံ့ဖြိုးရေးအဖွဲ့အားပိုမိုမြန်ဆန်သောတုံ့ပြန်မှုများ၊ စမ်းသပ်အလိုအလျောက်ရင်းနှီးမြှုပ်နှံအတွက်ခံနိုင်ရည်ရှိသည်။
မည်သည့်စမ်းသပ်မှုကိုမဆိုအလိုအလျောက်ပြုလုပ်ရန်ကြိုးပမ်းမှု၏အခက်ခဲဆုံးနှင့်စိန်ခေါ်မှုလက္ခဏာမှာအလိုအလျောက်စစ်ဆေးခြင်း၏ကန့်သတ်ချက်များကိုနားလည်ရန်နှင့်စိတ်ပျက်စရာများကိုရှောင်ရှားရန်လက်တွေ့ကျသောပန်းတိုင်များနှင့်မျှော်လင့်ချက်များချမှတ်ရန်ဖြစ်သည်။ ဤအချက်ကိုစိတ်ထဲ ထား၍ စမ်းသပ်မှုအလိုအလျောက်နှင့်ပတ်သက်သောအသုံးအများဆုံးနားလည်မှုလွဲမှားခြင်းနှင့်ဒဏ္sာရီအချို့ကိုကြည့်ကြစို့။
မိုက်ကယ်ဘော်လ်တန်ရဲ့ blog post ကိုရည်ညွှန်းသည် စစ်ဆေးခြင်း vs. စစ်ဆေးခြင်း , အလိုအလျောက်စမ်းသပ်ခြင်းတကယ်စမ်းသပ်မဟုတ်ပါဘူး။ ဒါဟာအချက်အလက်များစစ်ဆေးနေသည်။ ကျွန်ုပ်တို့သည်စနစ်တစ်ခုကိုနားလည်သဘောပေါက်လာပါကထိုနားလည်မှုကိုစစ်ဆေးခြင်းပုံစံများကိုပြcan္ဌာန်းနိုင်ပြီးအလိုအလျောက်စစ်ဆေးမှုများကိုလုပ်ဆောင်ခြင်းဖြင့်ကျွန်ုပ်တို့၏နားလည်မှုကိုအတည်ပြုနိုင်သည်။ အခြားတစ်ဖက်တွင်စမ်းသပ်ခြင်းသည်စုံစမ်းစစ်ဆေးခြင်းမှတစ်ဆင့်စမ်းသပ်ဆဲစနစ်နှင့်ပတ်သက်သောသတင်းအချက်အလက်အသစ်များရရှိရန်ကျွန်ုပ်တို့ရည်ရွယ်သည်။
စမ်းသပ်ခြင်းသည်လူတစ် ဦး အားစနစ်၏အသုံး ၀ င်မှုအပေါ်မှန်ကန်စွာဆုံးဖြတ်ရန်လိုအပ်သည်။ ကျနော်တို့မျှော်လင့်မခံခဲ့ရသည့်အခါကျနော်တို့ကွဲလွဲချက်များကိုရှာဖွေတွေ့ရှိနိုင်ပါတယ်။ လျှောက်လွှာ၏အရည်အသွေးကိုထိုးထွင်းသိမြင်နိုင်ရန်အတွက်နည်းလမ်းနှစ်မျိုးစလုံးလိုအပ်သောကြောင့်ကျွန်ုပ်တို့တစ် ဦး သို့မဟုတ်တစ် ဦး အပေါ်ကြင်နာမှုမရှိသင့်ပါ။
၁၀၀% စမ်းသပ်မှုရရှိရန်လက်တွေ့ကျသောနည်းလမ်းမရှိသောကြောင့် (အဆုံးမဲ့ဖြစ်နိုင်ချေရှိသောအပြောင်းအလဲများကြောင့်) အလားတူစွာပင်အလိုအလျောက်စမ်းသပ်ခြင်းကိုပြုလုပ်သည်။ အလိုအလျောက်စမ်းသပ်မှုများကိုလုပ်ဆောင်ခြင်း၊ အချက်အလက်ပိုမိုများပြားလာခြင်း၊ ဖွဲ့စည်းပုံအခြေခံဥပဒေများပိုမိုများပြားလာခြင်း၊ လည်ပတ်မှုစနစ်များ၊ ဘရောက်စာအမျိုးမျိုးကိုဖုံးအုပ်ထားခြင်းဖြင့်ကျွန်ုပ်တို့သည်စမ်းသပ်မှုကိုတိုးမြှင့်နိုင်သည်။ သို့သော် ၁၀၀% အောင်မြင်ခြင်းသည်လက်တွေ့မကျသည့်ပန်းတိုင်တစ်ခုဖြစ်သည်။ အလိုအလျောက်စစ်ဆေးခြင်းနှင့်ပတ်သက်လာလျှင်ပိုမိုစစ်ဆေးခြင်းသည်ပိုမိုကောင်းမွန်သောအရည်အသွေးသို့မဟုတ်ပိုမိုကောင်းမွန်သောယုံကြည်စိတ်ချမှုကိုမဆိုလိုပါ။ ဒါဟာအားလုံးစမ်းသပ်ဒီဇိုင်းဘယ်လောက်ကောင်းပေါ်တွင်မူတည်သည်။ အပြည့်အဝလွှမ်းခြုံရန်ရည်ရွယ်မည့်အစားစီးပွားရေးလုပ်ငန်းအတွက်အရေးကြီးသောလုပ်ဆောင်နိုင်စွမ်းကဏ္ on ကိုအာရုံစိုက်ပါ။
စမ်းသပ်မှုအလိုအလျောက်ဖြေရှင်းနည်းကိုအကောင်အထည်ဖော်သည့်အခါစမ်းသပ်မှုများရေးသားခြင်းထက်အခြားအပြန်အလှန်ဆက်နွယ်သောဖွံ့ဖြိုးရေးလုပ်ဆောင်မှုများရှိသည်။ ပုံမှန်အားဖြင့်စီးပွားရေးလုပ်ငန်းအတွက်အသုံး ၀ င်ပြီးအဓိပ္ပာယ်ရှိသည့်အော်ပရေးရှင်းစစ်ဆေးခြင်း၊ သတင်းပို့ခြင်း၊ အချက်အလက်မောင်းနှင်ခြင်းစသည့် bespoke လုပ်ဆောင်မှုများကိုပံ့ပိုးပေးနိုင်သည့်မူဘောင်တစ်ခုကိုရေးဆွဲရန်လိုအပ်သည်။
မူဘောင်၏ဖွံ့ဖြိုးတိုးတက်မှုသည်သူ့ဟာသူစီမံကိန်းတစ်ခုဖြစ်ပြီးကျွမ်းကျင်သော developer များလိုအပ်ပြီးတည်ဆောက်ရန်အချိန်လည်းလိုအပ်သည်။ အပြည့်အဝအလုပ်လုပ်သောမူဘောင်ရှိသည့်တိုင်အလိုအလျောက်စစ်ဆေးခြင်းများကို scripting လုပ်ခြင်းသည်တူညီသောစမ်းသပ်မှုကိုကိုယ်တိုင်ပြုလုပ်ရန်ထက်ပိုကြာသည်။ ထို့ကြောင့်ကျွန်ုပ်တို့တီထွင်ထားသောအသစ်သောအင်္ဂါရပ်ကိုအမြန်ပြန်လည်တုံ့ပြန်ရန်လိုအပ်လာသောအခါ၎င်းကိုကိုယ်တိုင်စစ်ဆေးခြင်းသည်များသောအားဖြင့်စမ်းသပ်မှုကိုအလိုအလျောက်လုပ်ခြင်းထက်ပိုမိုမြန်ဆန်သည်။ ကျနော်တို့ပုံမှန်ကြားကာလမှာတူညီတဲ့စမ်းသပ်မှု execute ရန်လိုအပ်သည့်အခါသို့သော် ROI ရေရှည်မှာပြန်ရောက်သည်။
ရောင်းချသူမှပေးသောနှင့်အိမ်တွင်ပြသထားသောစမ်းသပ်မှုအလိုအလျောက်ဖြေရှင်းနည်းများသည်အလွန်ရှုပ်ထွေးပြီးရှုပ်ထွေးသောလုပ်ဆောင်မှုများကိုပြုလုပ်ရာတွင်အလွန်အမင်းစွမ်းဆောင်ရည်ရှိသော်လည်း၎င်းတို့သည်ရှာဖွေတွေ့ရှိစဉ်သို့မဟုတ်မျှော်လင့်ထားသည့်ကွဲလွဲချက်များကိုရှာဖွေတွေ့ရှိနိုင်သည့်လူ့စမ်းသပ်သူ၏ထောက်လှမ်းရေးနှင့်မည်သည့်အခါမျှယှဉ်ပြိုင်နိုင်မည်မဟုတ်ပါ။ စမ်းသပ်မှုအောက်ရှိစနစ်ဆန့်ကျင် scripted စမ်းသပ်မှုအစုတခုကွပ်မျက်။ ထူးဆန်းသည်မှာလူတို့သည်အလိုအလျောက်စစ်ဆေးခြင်းသည်စမ်းသပ်မှုများပိုမိုများပြားလာခြင်းကြောင့်အမှားအယွင်းများစွာကိုရှာတွေ့လိမ့်မည်ဟုမျှော်လင့်ထားကြသော်လည်းလက်တွေ့တွင်မူထိုသို့မဟုတ်ချေ။
မှန်ပါသည်၊ အလိုအလျောက်စစ်ဆေးခြင်းသည် regression ပြissuesနာများကိုဖြေရှင်းနိုင်သည်။ လက်ရှိကုဒ်အခြေစိုက်စခန်းထဲသို့အင်္ဂါရပ်အသစ်တစ်ခုထည့်ပြီးပါကကျွန်ုပ်တို့သည်လက်ရှိလုပ်ဆောင်နိုင်စွမ်းကိုမချိုးဖောက်ကြောင်းနှင့်သတင်းအချက်အလက်ကိုမြန်ဆန်စွာလိုအပ်သည်ကိုသေချာစေရန်လိုအပ်သည်၊ သို့သော်၊ ကိစ္စရပ်အများစုတွင်ဖွံ့ဖြိုးဆဲလုပ်ဆောင်ချက်အသစ်များထက်များစွာနည်းပါးသည်။
စိတ်ထဲထားရမည့်နောက်ထပ်အချက်တစ်ခုမှာအလိုအလျောက်စစ်ဆေးခြင်းသည်သူတို့ရေးသားထားသောစာကိုရေးသားသူမှစစ်ဆေးရန်၎င်းတို့အားအစီအစဉ်ချထားခြင်းကိုသာစစ်ဆေးခြင်းဖြစ်သည်။ အဆိုပါ script များသူတို့ကိုရေးသားခဲ့သည်သူကဲ့သို့ကောင်းသောဖြစ်ကြသည်။ အလိုအလျောက်စစ်ဆေးမှုများအားလုံးပျော်ရွှင်စွာဖြတ်သန်းသွားနိုင်သော်လည်းအဓိကအားနည်းချက်များကိုသတိမပြုမိဘဲကုန်ပစ္စည်း၏အရည်အသွေးကိုမှားယွင်းစွာထင်မြင်စေနိုင်သည်။ အနှစ်သာရအားဖြင့်စစ်ဆေးခြင်းသည်ချို့ယွင်းချက်များရှိကြောင်းသက်သေပြနိုင်သော်လည်း၎င်းတို့မရှိခြင်းကိုမသက်သေပြနိုင်ပါ။
အင်္ဂါရပ်အသစ်များကိုစမ်းသပ်ရာတွင်ချို့ယွင်းချက်များရှာဖွေခြင်း၏ဖြစ်နိုင်ခြေသည်ပိုမိုများပြားပါကကျွန်ုပ်တို့၏တီထွင်ထားသည့်အတိုင်းလုပ်ဆောင်မှုအသစ်နှင့်အဘယ်ကြောင့်ကျွန်ုပ်တို့၏အလိုအလျောက်စမ်းသပ်မှုများကိုပြုလုပ်နေခြင်းမဟုတ်ပါသနည်း။ ကောင်းပြီ, ဒီလေ့ကျင့်သောအသင်းများကိုများအတွက်အတန်ငယ်အမှုဖြစ်ပါတယ် TDD ။
developer များကပထမ ဦး စွာ unit test ကိုရေးသည်၊ ၎င်းသည်ပျက်ကွက်သည်ကိုစောင့်ကြည့်ပါ။ ထို့နောက် unit test pass ရရှိရန်ကုဒ်အလုံအလောက်ရေးပါ။ အနှစ်သာရအားဖြင့်၊ ဤအလိုအလျောက်ယူနစ်စစ်ဆေးမှုများသည်လုပ်ဆောင်နိုင်မှုအသစ်များကိုစစ်ဆေးနေသည်။ အချိန်ကြာလာသည်နှင့်အမျှ၎င်းသည်လုပ်ဆောင်မှုအသစ်များကိုထပ်မံပေးပို့သည့်အခါထပ်ခါတလဲလဲကွပ်ကဲသောယူနစ် regression pack ကိုဖွဲ့စည်းသည်။
သို့သော်ဤအတွက်အသိပေးချက်ရှိပါသည်။ TDD သည်အလွန်အားတက်ပြီးအခြေခံအဆောက်အအုံများမှအရည်အသွေးကိုတည်ဆောက်ရာတွင်ခိုင်မာသောဖွံ့ဖြိုးမှုအလေ့အကျင့်တစ်ခုဖြစ်သော်လည်းယူနစ်စစ်ဆေးမှုများသည်ပရိုဂရမ်မာအမှားများကိုရှာဖွေရန်မှာသာအောင်မြင်ပြီး၊ အစိတ်အပိုင်းအားလုံးအားအတူတကွချိတ်ဆက်ပြီးစနစ်တစ်ခုဖြစ်ပေါ်လာသည့်အခါပိုမိုကြီးမားသောစစ်ဆေးမှု၏လက္ခဏာတစ်ခုရှိသည်။
အမှန်မှာအဖွဲ့အစည်းများစွာသည် system UI layer တွင်အလိုအလျောက်စစ်ဆေးမှုအများစုရှိသည်။ သို့သော် UI သို့မဟုတ် system အတွက်အလိုအလျောက်စစ်ဆေးမှုများကို scripting လုပ်ခြင်း၊ features အသစ်များတည်ဆောက်နေစဉ်တွင်လုပ်ဆောင်မှုအသစ်သည်ဖွံ့ဖြိုးဆဲကာလအတွင်း (အပြောင်းအလဲများစွာနှင့်သက်ဆိုင်သော) မတည်ငြိမ်သောဖြစ်လေ့ရှိသည်။ ဒါ့အပြင်မျှော်လင့်ထားသည့်လုပ်ဆောင်နိုင်စွမ်းကိုနောက်မှမသိရပေမဲ့ပြောင်းလဲနေတဲ့လုပ်ဆောင်ချက်ကိုအလိုအလျောက်အချိန်ဖြုန်းခြင်းကိုအားမပေးပါ။
UI နှင့် system level တွင်အလိုအလျောက်စစ်ဆေးမှုများကိုလုပ်ဆောင်ရာတွင်တန်ဖိုးများရှိသည်။ လျှောက်လွှာနှင့်အပြန်အလှန်ဆက်သွယ်သောအခါအသုံးပြုသူတွေ့ကြုံခံစားသောအရာများကိုကျွန်ုပ်တို့တွေ့မြင်ရမည်။ ကျနော်တို့အဆုံးမှအဆုံးသို့စီးဆင်းမှုနှင့် 3 စမ်းသပ်နိုင်ပါတယ်rdကျနော်တို့မဟုတ်ရင်စမ်းသပ်လို့မရဘူးသည့်အခါပါတီပေါင်းစည်းမှု; သုံးစွဲသူများနှင့်နောက်ဆုံးအသုံးပြုသူများအားစမ်းသပ်မှုများကိုသရုပ်ပြနိုင်သည်။ သို့မှသာ၎င်းတို့သည်စမ်းသပ်မှုလွှမ်းခြုံမှုကိုခံစားရမည်ဖြစ်သည်။ သို့သော် UI အလွှာရှိအလိုအလျောက်စစ်ဆေးမှုများကိုသာအားကိုးခြင်းသည်ကိုယ်ပိုင်ပြhasနာများရှိသည်။
UI အပြောင်းအလဲများကြောင့်အမြင်အာရုံဒီဇိုင်းနှင့်အသုံးဝင်မှုကိုမြှင့်တင်ရန်နှင့်အလိုအလျောက်စစ်ဆေးမှုများပျက်ကွက်ခြင်းနှင့်လုပ်ဆောင်နိုင်စွမ်းကိုပြောင်းလဲခြင်းသည်အသုံးချမှုအခြေအနေကိုမှားယွင်းစွာထင်မြင်စေနိုင်သည်။
UI အလိုအလျောက်စစ်ဆေးမှုများသည်ယူနစ် (သို့) API အလွှာများထက်စွမ်းဆောင်ရည်အမြန်နှုန်းတွင်များစွာနှေးကွေးနေသဖြင့်အဖွဲ့သို့ပြန်လည်ဆက်သွယ်မှုမှာနှေးကွေးနေသည်။ ချို့ယွင်းချက်တစ်ခုကိုတွေ့ရှိပြီးနောက် developer များထံသို့ပြန်လည်အစီရင်ခံရန်နာရီအနည်းငယ်ကြာနိုင်သည်။ တစ်ခုခုမှားယွင်းသွားသောအခါအကြောင်းအရင်းရင်းမြစ်ခွဲခြမ်းစိတ်ဖြာခြင်းသည်ကြာကြာကြာသည်။ ဘာဖြစ်လို့လဲဆိုတော့ bug ဘယ်မှာလဲဆိုတာအလွယ်တကူမသိနိုင်လို့ပဲ။
စမ်းသပ်မှုတစ်ခုချင်းစီ၏အခြေအနေကိုနားလည်ခြင်းနှင့်မည်သည့်အလွှာတွင်စမ်းသပ်မှုကိုအလိုအလျောက်ပြုလုပ်သင့်သည်ကိုနားလည်ခြင်းသည်အရေးကြီးသည်။ စမ်းသပ်ခြင်းအလိုအလျောက်သည်အလိုအလျောက်စစ်ဆေးခြင်းအလိုအလျောက်ဖြစ်သည်။ ထို့ကြောင့်အဖွဲ့တစ်ဖွဲ့လုံးသည်စမ်းသပ်မှုအလိုအလျောက်လုပ်ဆောင်ရန်တာဝန်ရှိသည်။ developer များကကွပ်ကဲသောအပိုင်းများ၊ ဆော့ဝဲလ်တီထွင်သူများသည်ရေးသားခြင်းနှင့်ရေးသားခြင်းနှင့်လက်ခံမှုစစ်ဆေးခြင်းများကို API နှင့် / သို့မဟုတ် UI တွင်ထိန်းသိမ်းထားသည်။
ဒီနောက်ဆုံးစမ်းသပ်မှုအလိုအလျောက်အကြောင်းကိုဒဏ္isာရီမဟုတ်ပါဘူး, ဒါပေမယ့်စမ်းသပ်အလိုအလျောက်မှားသွားသည့်အခါဘေးထွက်ဆိုးကျိုး။ သင်သည်အကောင်းဆုံးကိရိယာများနှင့်အကောင်းဆုံးအလေ့အကျင့်များကို အသုံးပြု၍ ပြီးပြည့်စုံသောစမ်းသပ်ခြင်းအလိုအလျောက်ဖြေရှင်းနည်းတစ်ခုကိုတီထွင်ရန်နာရီများစွာအသုံးပြုသည်။ သို့သော်အလိုအလျောက်စစ်ဆေးခြင်းသည်အဖွဲ့ကိုမကူညီပါကအကျိုးမရှိပါ။
အကယ်၍ အဖွဲ့သည်အလိုအလျောက်လုပ်ဆောင်ခြင်းနှင့်မည်သည့်အရာကိုလုပ်ဆောင်သည်နှင့် ပတ်သက်၍ ဗဟုသုတမရှိပါက၎င်းတို့သည်မသိသောကြောက်ရွံ့မှုဖြင့်လွတ်မြောက်ခြင်းသို့မဟုတ်၎င်းတို့၏ဆုတ်ယုတ်စမ်းသပ်ခြင်းအားထုတ်မှုများကိုပုံတူပွားခြင်းများပြုလုပ်သည်။ အလိုအလျောက်စစ်ဆေးမှုများသည်မမြဲသောနှေးနှေးဖြစ်ပါကပြတ်တောင်းပြတ်တောင်းရလဒ်များကိုပေးပါကအဖွဲ့သည်လုံခြုံစိတ်ချရသောကွန်ယက်နှင့်ယုံကြည်စိတ်ချရသောအာနိသင်တိုးမြှင့်ခြင်းထက်အဖွဲ့ကိုပိုမိုရှုပ်ထွေးစေနိုင်သည်။
အမြဲတမ်းပျက်ကွက်နေသောသို့မဟုတ်ရှေ့နောက်မညီသောရလဒ်များကိုပေးသောအလိုအလျောက်စစ်ဆေးမှုများကိုမဖယ်ရှားပါနှင့်။ အဲဒီအစား, လျှောက်လွှာ၏ကျန်းမာရေးမှန်ကန်သောညွှန်ပြချက်ပေးနိုငျသောစင်ကြယ်သောနှင့်ယုံကြည်စိတ်ချရသောစမ်းသပ်မှုအစုံရည်ရွယ်သည်။
Test Automation သည်ရေရှည်ရင်းနှီးမြှုပ်နှံမှုတစ်ခုဖြစ်သည်။ ဒါဟာအလိုအလျောက် scripts စမ်းသပ်အလိုအလျောက်မူဘောင်ဖွံ့ဖြိုးဆဲနှင့်ထိန်းသိမ်းရေးအတွက်အချိန်နှင့်ကျွမ်းကျင်မှုယူပါလိမ့်မယ်။ အလိုအလျောက်စစ်ဆေးခြင်းသည်သင်အဖြေတစ်ခုပေးပြီး၎င်းကိုလည်ပတ်စေမည့်တစ်ကြိမ်တည်းကြိုးပမ်းမှုမဟုတ်ပါ။ ၎င်းသည်စဉ်ဆက်မပြတ်စောင့်ကြည့်ကြီးကြပ်ရန်လိုအပ်သည်။
လက်ငင်း QAs ကိုအစားထိုးရန်သို့မဟုတ်အလိုအလျောက်စစ်ဆေးမှုများသည်ချို့ယွင်းချက်များစွာကိုတွေ့ရှိရန်မျှော်လင့်မည့်အစား၊ အဖွဲ့အတွက်သူရရှိသောကောင်းကျိုးများကိုလက်ခံသင့်သည်။ ဥပမာ QA ၏ရှာဖွေတွေ့ရှိမှုကို ပိုမို၍ ရှာဖွေတွေ့ရှိချက်များအားဖြင့်ချို့ယွင်းချက်များရှာဖွေတွေ့ရှိခြင်းသို့မဟုတ်အလိုအလျောက်အသုံးပြုခြင်းတို့ဖြစ်သည်။ လက်စွဲစာအုပ်စမ်းသပ်ခြင်းများအတွက်အသုံးပြုနိုင်သည့်စမ်းသပ်မှုအချက်အလက်ဖန်တီးရန် script များ။
ကန့်သတ်ချက်များကိုနားလည်ခြင်းနှင့်လက်တွေ့ကျသောမျှော်လင့်ချက်များချမှတ်ခြင်းတို့သည်ဤစမ်းသပ်မှုအလိုအလျောက်၏ဒဏ္myာရီများကိုကျော်လွှားရာ၌အရေးကြီးသည်။