Testing Strategy (စမ်းသပ်ပုံ အစီအစဉ်)
ဘယ်မှာ အသုံးဝင်လဲ: ကိုယ့် ဖြေရှင်းချက်က သူ့ requirement (software က ဘာလုပ်ရမလဲ ဆိုတဲ့ သတ်မှတ်ချက်) တွေနဲ့ ကိုက်ညီမညီ စစ်မယ့် test တွေကို ရွေးဖို့ပါ။ IB Computer Science (နိုင်ငံတကာ ကျောင်းတွေမှာ သင်တဲ့ ကွန်ပျူတာသိပ္ပံ သင်ရိုး) ရဲ့ Internal Assessment (IA၊ IB သင်တန်းမှာ ကျောင်းသားတစ်ယောက်ချင်း ကိုယ်တိုင် တည်ဆောက်ရပြီး ကျောင်းက ဆရာက အမှတ်ပေးတဲ့ အပိုင်း) မှာ Criterion C: System overview (အမှတ်ပေး စံနှုန်း C: စနစ်ရဲ့ ခြုံငုံ ဖော်ပြချက်) က ကိုယ့် success criteria (အောင်မြင်မှု စံနှုန်းများ: product က လုပ်သင့်တာကို လုပ်မလုပ် ပြတဲ့ တိုင်းတာလို့ရတဲ့ ရလဒ်များ) နဲ့ ကိုက်ညီတဲ့ testing strategy (စမ်းသပ်ပုံ အစီအစဉ်) တစ်ခုကို တောင်းပါတယ်။ Criterion D: Development (အမှတ်ပေး စံနှုန်း D: product တည်ဆောက်ခြင်း) ကတော့ အဲဒီ strategy ကို လက်တွေ့ လုပ်ဆောင်ဖို့၊ ဖော်ပြဖို့နဲ့ ဘာကြောင့် ဒီလို ရွေးလဲ အကြောင်းပြဖို့ တောင်းပြီး ကိုယ့် video ထဲမှာ ဥပမာတွေ ပြခိုင်းပါတယ်။ Test data (စမ်းစစ်တဲ့အခါ ထည့်ပေးတဲ့ တန်ဖိုးများ) ကောင်းကောင်း ရွေးတတ်တာက developer (software ရေးသူ) တိုင်း လိုအပ်တဲ့ ကျွမ်းကျင်မှု တစ်ခုပါ။
မာတိကာ
- ခြုံငုံ မိတ်ဆက်
- Testing အမျိုးအစားများ
- Test Data ရွေးခြင်း
- Test Plan (ဘာကို ဘယ်လို စမ်းစစ်မလဲ ကြိုရေးထားတဲ့ အစီအစဉ်) ရေးခြင်း
- Quick Check (အမြန် စစ်ဆေးမေးခွန်း)
- Classify the Test Data (test data အမျိုးအစား ခွဲခြားခြင်း)
- Practice Exercises (လေ့ကျင့်ခန်းများ)
- ဆက်စပ် ခေါင်းစဉ်များ
ခြုံငုံ မိတ်ဆက်
Program တစ်ခုကို “test” လုပ်တဲ့ အသုံးများတဲ့ နည်းက သင့်တော်တဲ့ input (program ထဲ ထည့်ပေးတဲ့ ဒေတာ) နဲ့ တစ်ကြိမ် run ကြည့်၊ အလုပ်လုပ်တာ မြင်ရင် ရှေ့ဆက်သွားတာပါ။ အဲဒါက program ကိုင်တွယ်ရမယ့် case (အခြေအနေ) အများကြီးထဲက တစ်ခုကိုပဲ စစ်တာပါ။
ပုံမှန် အပြုအမူ၊ ခွင့်ပြုထားတဲ့ တန်ဖိုးတွေရဲ့ အစွန်းတွေနဲ့ program က မှားတဲ့ input ကို ဘယ်လို ကိုင်တွယ်လဲ ဆိုတာကို စစ်ပေးမယ့် input တွေကို ရွေးပါ၊ program ကို ပျက်စေနိုင်ခြေ ရှိတဲ့ input တွေလည်း ပါရပါမယ်။ Test တစ်ခုချင်းစီ မ run ခင် expected result (မျှော်မှန်းထားတဲ့ ရလဒ်: program က ဘာလုပ်သင့်လဲ ဆိုတာ requirement တွေကနေ တွက်ထုတ်ထားတာ) ကို မှတ်ထားပါ၊ ပြီးရင် actual result (တကယ့် ရလဒ်: program က တကယ် ဘာလုပ်လဲ) နဲ့ နှိုင်းယှဉ်ပါ။
Testing (program မှန်မမှန် စမ်းစစ်ခြင်း) က error (အမှား) တွေ ရှိနေကြောင်း ပြနိုင်ပါတယ်၊ ဒါပေမယ့် တကယ့် program အများစုအတွက် error တစ်ခုမှ မကျန်တော့ကြောင်း မပြနိုင်ပါဘူး: ဖြစ်နိုင်တဲ့ input တွေက အားလုံး စမ်းဖို့ အရမ်း များလွန်းလို့ပါ။ သူ့ ရည်ရွယ်ချက်က ပြင်ဖို့ အချိန် ရှိနေတုန်း error တွေကို ရှာဖို့နဲ့ program ကို သူ့ requirement တွေနဲ့ တိုက်စစ်ဖို့ပါ။ ဒါကြောင့် program အလုပ်လုပ်တာကို ပြတဲ့ test တွေအပြင် program ကို ကျရှုံးအောင် ကြိုးစားတဲ့ test တွေလည်း ထည့်ပါ။
Testing အမျိုးအစားများ
Testing ကို ပုံမှန်အားဖြင့် နည်း နှစ်မျိုးနဲ့ ခွဲပြီး ဖော်ပြပါတယ်: code ကို ဘယ်လောက် မြင်ရလဲ ဆိုတာနဲ့ စနစ်ရဲ့ ဘယ်လောက် အပိုင်းကို စမ်းစစ်နေလဲ ဆိုတာပါ။
Code ကို မြင်ရမှု အလိုက်
| အမျိုးအစား | အဓိပ္ပာယ် |
|---|---|
| Black-box testing (code ကို မကြည့်ဘဲ စမ်းစစ်ခြင်း) | Code ကို မကြည့်ဘဲ requirement တွေကနေ test တွေကို ရွေးပါတယ်။ Program က ဘာလုပ်သင့်လဲ သိပြီး အဲဒါကို လုပ်မလုပ် စစ်ပါတယ်၊ အတွင်းပိုင်းကို ပိတ်ထားတဲ့ box (သေတ္တာ) တစ်ခုလို သဘောထားပါတယ်။ |
| White-box testing (code ရဲ့ ဖွဲ့စည်းပုံကို ကြည့်ပြီး စမ်းစစ်ခြင်း) | Code ရဲ့ ဖွဲ့စည်းပုံကနေ test တွေကို ရွေးပါတယ်: code ထဲမှာ မြင်ရတဲ့ ဆုံးဖြတ်ချက်တွေ၊ branch (condition အရ run မယ့် code လမ်းကြောင်း) တွေနဲ့ loop (ထပ်ခါထပ်ခါ run တဲ့ code အပိုင်း) တွေပါ။ ဥပမာ if တစ်ခုစီရဲ့ ရလဒ် နှစ်မျိုးလုံးကို စမ်းပြီး branch တိုင်း အနည်းဆုံး တစ်ကြိမ် run အောင် ရည်ရွယ်နိုင်ပါတယ်၊ loop က သုည ကြိမ်၊ တစ်ကြိမ်နဲ့ အကြိမ်ကြိမ် ထပ်လုပ်တဲ့အခါ ဘာဖြစ်လဲ စစ်နိုင်ပါတယ်။ |
နှစ်မျိုးလုံး အသုံးဝင်ပါတယ်။ Black-box test တွေက program မပြည့်မီတဲ့ requirement တစ်ခုကို ရှာတွေ့နိုင်ပါတယ်၊ ဘယ်တုန်းကမှ မရေးခဲ့တဲ့ feature (program ရဲ့ လုပ်ဆောင်ချက်) တစ်ခုလည်း ပါပါတယ်။ White-box test တွေကတော့ black-box test တွေ မတော်တဆ မရောက်ခဲ့တဲ့ code ထဲက path (code ရဲ့ အစကနေ အဆုံးထိ လမ်းကြောင်း တစ်ခု) ပေါ်က error တစ်ခုကို ရှာတွေ့နိုင်ပါတယ်၊ ဥပမာ ပုံမှန် မဟုတ်တဲ့ case မှာပဲ run တဲ့ branch တစ်ခုပါ။ Path တစ်ခုကို trace table (variable တန်ဖိုးတွေကို အဆင့်ဆင့် မှတ်တဲ့ ဇယား) နဲ့ စာရွက်ပေါ်မှာ လိုက်ကြည့်နိုင်ပါတယ်။
စမ်းစစ်တဲ့ ပမာဏ အလိုက်
| အဆင့် | ဘာကို စမ်းစစ်လဲ |
|---|---|
| Unit testing (အစိတ်အပိုင်း တစ်ခုချင်း စမ်းစစ်ခြင်း) | အပိုင်း သေးသေး တစ်ခုကို သီးခြား စမ်းစစ်တာ: method ဒါမှမဟုတ် function (သီးခြား အလုပ်တစ်ခု လုပ်ပေးတဲ့ code အပိုင်း) တစ်ခုတည်း။ |
| Integration testing (အစိတ်အပိုင်းတွေ ပေါင်းပြီး စမ်းစစ်ခြင်း) | အပိုင်း အများ အတူ အလုပ်လုပ်တာကို စမ်းစစ်တာ၊ သူတို့ ဆက်သွယ်တဲ့ နေရာက ပြဿနာတွေ ရှာဖို့။ |
| System testing (စနစ် တစ်ခုလုံးကို စမ်းစစ်ခြင်း) | ပြီးသွားတဲ့ program တစ်ခုလုံးကို သူ့ requirement တွေနဲ့ တိုက်စစ်တာ။ |
| User acceptance testing (user တွေ လက်ခံမလား စမ်းစစ်ခြင်း) | စနစ်က client နဲ့ သုံးမယ့် လူတွေရဲ့ လိုအပ်ချက်တွေနဲ့ ကိုက်ညီမညီ၊ သူတို့နဲ့အတူ ဒါမှမဟုတ် သူတို့ကိုယ်တိုင် စမ်းစစ်တာ။ |
ဒါတွေကို ပုံမှန်အားဖြင့် ဒီအစဉ်အတိုင်း တဖြည်းဖြည်း တိုးလုပ်ပါတယ်: အပိုင်း တစ်ခုတည်း၊ ပြီးရင် အပိုင်းတွေ အတူတူ၊ ပြီးရင် program တစ်ခုလုံး၊ ပြီးရင် program တစ်ခုလုံးက သူ့ကို ဖန်တီးပေးခဲ့တဲ့ လူတွေရဲ့ လိုအပ်ချက်တွေနဲ့ ကိုက်ညီမညီ။
Acceptance testing ကို တစ်ခါတလေ အဆင့် နှစ်ဆင့်နဲ့ လုပ်ပါတယ်။ Alpha testing (developer ဘက်မှာ အရင် စမ်းစစ်ခြင်း) ကို developer ရဲ့ ကိုယ်ပိုင် နေရာမှာ developer ရဲ့ tester (စမ်းစစ်သူ) တွေ ဒါမှမဟုတ် ဖိတ်ခေါ်ထားတဲ့ user တွေက လုပ်ပါတယ်။ Beta testing (တကယ့် user တွေဆီ ပေးပြီး စမ်းစစ်ခြင်း) က နောက်မှ လာပါတယ်: ပြီးလုနီးပါး version တစ်ခုကို တကယ့် user အုပ်စု တစ်စုဆီ ပေးပြီး သူတို့က သူတို့ကိုယ်ပိုင် ပတ်ဝန်းကျင်မှာ သုံးကြည့်ကာ အပြည့်အစုံ release (ထုတ်ဝေ) မလုပ်ခင် ပြဿနာတွေကို အစီရင်ခံပါတယ်။
Test Data ရွေးခြင်း
Test data ဆိုတာ test တွေကို run တဲ့အခါ ထည့်ပေးတဲ့ တန်ဖိုး အစုပါ။ မျှော်မှန်းထားတဲ့ အပြုအမူနဲ့ program က လက်မခံသင့်တဲ့ input ကို ဘယ်လို ကိုင်တွယ်လဲ ဆိုတာ နှစ်ခုလုံးကို စစ်နိုင်အောင် အမျိုးအစား သုံးမျိုးကနေ ရွေးပါ။
| အမျိုးအစား | ဘာလဲ | ဘာကြောင့် အရေးကြီးလဲ |
|---|---|---|
| Normal (ပုံမှန်) | Program ကိုင်တွယ်ဖို့ ရည်ရွယ်ထားတဲ့ ပုံမှန် valid (လက်ခံရမယ့်) input | Program က သူ့ ပုံမှန် အလုပ်ကို မှန်မှန်ကန်ကန် လုပ်မလုပ် စစ်ပေးပါတယ် |
| Boundary (အစွန်း) | ခွင့်ပြုထားတဲ့ အပိုင်းအခြားရဲ့ အစွန်းတွေမှာ ရှိတဲ့ တန်ဖိုးတွေ: အနိမ့်ဆုံးနဲ့ အမြင့်ဆုံး valid တန်ဖိုးတွေ၊ ပြီးတော့ အဲဒီ အပြင်ဘက် နားလေးမှာ ရှိတဲ့ ပထမဆုံး invalid တန်ဖိုးတွေ | <= လို့ ရေးရမယ့်နေရာမှာ < လို့ ရေးမိတာလို error တွေက အစွန်းတွေမှာပဲ ပေါ်ပါတယ် |
| Invalid (erroneous) (လက်မခံရမယ့်) | Program က လက်မခံသင့်တဲ့ input: အပိုင်းအခြား ပြင်ပ ရောက်နေတာ၊ type မှားနေတာ (ဥပမာ ဂဏန်း မျှော်လင့်ထားတဲ့ နေရာမှာ စာသား) ဒါမှမဟုတ် ဘာမှ မထည့်ထားတာ | လူတွေက စာရိုက် မှားတတ်ပြီး မှားတဲ့ ဒေတာ အမျိုးအစားကို ထည့်တတ်ပါတယ်၊ program က အဲဒီ input ကို crash (program ရုတ်တရက် ပျက်ပြီး ရပ်သွားခြင်း) မဖြစ်ဘဲ၊ မသိမ်းဘဲ၊ ရှင်းလင်းတဲ့ message တစ်ခုနဲ့ ငြင်းပယ်သင့်ပါတယ် |
အပိုင်းအခြားရဲ့ အပြင်ဘက် နားလေးမှာ ရှိတဲ့ တန်ဖိုးကလည်း invalid ပါပဲ။ အစွန်း ဘယ်နေရာမှာ ရှိလဲ ဆိုတာကို အတိအကျ စစ်ပေးလို့ boundary test အဖြစ် ထည့်ထားတာပါ။ အစွန်းတွေက ခွင့်ပြုထားတဲ့ အပိုင်းအခြား အတွင်းမှာလည်း ရှိနိုင်ပါတယ်: စည်းမျဉ်း တစ်ခုက ရလဒ်ကို ပြောင်းစေတဲ့ နေရာတိုင်းမှာ (ဥပမာ မှာယူမှု စုစုပေါင်း တစ်ခု ရောက်မှ စတဲ့ လျှော့စျေး) အဲဒီ အမှတ်ရဲ့ ဘေးနှစ်ဖက်က တန်ဖိုးတွေကို စမ်းစစ်ပါ။
တွေ့နိုင်တဲ့ တခြား နာမည်များ။ စာအုပ်တွေနဲ့ ဆရာတွေက ဒီအမျိုးအစားတွေကို နာမည် အမျိုးမျိုး ပေးကြပါတယ်။ အနိမ့်ဆုံးနဲ့ အမြင့်ဆုံး valid တန်ဖိုးတွေကို extreme (အစွန်းဆုံး) data လို့ ခေါ်လေ့ ရှိပြီး စာအုပ် တချို့က boundary ဆိုတဲ့ စကားလုံးကို အစွန်း တစ်ခုစီရဲ့ ဘေးနှစ်ဖက်က တန်ဖိုး နှစ်ခု (အပိုင်းအခြား အတွင်းဘက် နားလေးက တစ်ခုနဲ့ အပြင်ဘက် နားလေးက တစ်ခု) အတွက်ပဲ သုံးပါတယ်။ Invalid data ကို erroneous (အမှား ပါတဲ့) ဒါမှမဟုတ် abnormal (ပုံမှန် မဟုတ်တဲ့) data လို့လည်း ခေါ်ပါတယ်။ ဘယ်နာမည်ကိုပဲ သုံးသုံး ပုံမှန် တန်ဖိုးတွေ၊ အစွန်း တိုင်းရဲ့ ဘေးနှစ်ဖက်က တန်ဖိုးတွေနဲ့ လက်မခံသင့်တဲ့ input ကို စမ်းစစ်ပါ။
Boundary value (အပိုင်းအခြား တစ်ခုရဲ့ အစွန်းမှာ ရှိတဲ့ တန်ဖိုး) တွေကို မေ့လွယ်ပြီး error အများကြီးကို ရှာတွေ့စေပါတယ်။ Field (ဒေတာ ရိုက်ထည့်ရတဲ့ အကွက်) တစ်ခုက 0 ကနေ 100 အထိ ကိန်းပြည့် အမှတ်ကို လက်ခံရင် 50 က အသုံးဝင်တဲ့ normal တန်ဖိုး တစ်ခုပါ၊ ဒါပေမယ့် အမှားကို ဖော်ထုတ်နိုင်ခြေ အများဆုံး တန်ဖိုးတွေက 0 နဲ့ 100 (valid အစွန်းတွေ) နဲ့ -1 နဲ့ 101 (ဘက်တစ်ဖက်စီက ပထမဆုံး invalid တန်ဖိုးတွေ) ပါ။ score <= 100 လို့ ရည်ရွယ်ပြီး score < 100 လို့ ရေးမိတဲ့ condition (မှန်လား မှားလား စစ်တဲ့ အခြေအနေ) က normal တန်ဖိုး တိုင်းအတွက် မှန်တဲ့ ရလဒ် ပေးပေမယ့် 100 အတွက် မှားတဲ့ ရလဒ် ပေးပါတယ်၊ ဒါကြောင့် 100 နဲ့ test လုပ်ရင် ချက်ချင်း တွေ့ပါတယ်။
Testing မှာ အဖြစ်များတဲ့ အမှားက normal data ကိုပဲ စမ်းစစ်တာပါ။ 50 ကို မှန်မှန်ကန်ကန် ကိုင်တွယ်တဲ့ program က ပုံမှန် case တစ်ခု အလုပ်လုပ်တာကိုပဲ ပြပါတယ်။ အစွန်းတွေ (0, 100)၊ အဲဒီ အပြင်ဘက် နားလေးက တန်ဖိုးတွေ (-1, 101) နဲ့ မှားတဲ့ input (“hello”၊ ဘာမှ မထည့်ထားတဲ့ box၊ 4.5 လို ဒသမကိန်း) ကို စမ်းစစ်ပါ: error တွေကို အဲဒီမှာ မကြာခဏ တွေ့ရပါတယ်။
အဆင့်ဆင့် ရှင်းပြထားတဲ့ ဥပမာ: score field တစ်ခု (valid အပိုင်းအခြား 0 ကနေ 100)
| အမျိုးအစား | Test တန်ဖိုးများ | Expected result |
|---|---|---|
| Normal | 45, 78 | လက်ခံတယ် |
| Boundary (valid အစွန်းတွေ) | 0, 100 | လက်ခံတယ် |
| Boundary (ပထမဆုံး invalid) | -1, 101 | ငြင်းပယ်တယ် |
| Invalid | 500, 4.5, “hello”, (empty၊ ဘာမှ မထည့်) | message တစ်ခုနဲ့ ငြင်းပယ်တယ်၊ crash မဖြစ်ဘူး |
ဒီတန်ဖိုး ဆယ်ခုက ကျပန်း valid ဂဏန်း ငါးဆယ်ထက် field ကို အများကြီး ပိုစေ့စေ့စပ်စပ် စမ်းစစ်ပေးပါတယ်: ကျပန်း valid ဂဏန်းတွေက အစွန်းမှာ အတိအကျ ရှိခဲပြီး အဲဒီထဲက တစ်ခုမှ field က လက်မခံသင့်တဲ့ input မဟုတ်လို့ပါ။
Test Plan (ဘာကို ဘယ်လို စမ်းစစ်မလဲ ကြိုရေးထားတဲ့ အစီအစဉ်) ရေးခြင်း
Test plan က ဘာကို ဘယ်လို စမ်းစစ်မလဲ ဆိုတာကို ဖော်ပြပြီး စမ်းစစ်တာ မစခင် ရေးရပါတယ်။ ဒီစာမျက်နှာက လေ့ကျင့်ခန်းတွေအတွက် test တစ်ခုချင်းစီရဲ့ input၊ ရည်ရွယ်ချက်နဲ့ expected result ကို ပြတဲ့ ဇယား တစ်ခုထဲမှာ ကိုယ့် test တွေကို မှတ်တမ်းတင်ပါ။ Expected result ကို ကြိုရေးထားတာက test ကို objective (ဘက်မလိုက်ဘဲ ကြိုသတ်မှတ်ထားတဲ့ စံနဲ့ တိုင်းတဲ့) ဖြစ်စေပါတယ်၊ ဆိုလိုတာက output ကို မမြင်ခင် ကိုယ် သတ်မှတ်ထားတဲ့ စံနှုန်း တစ်ခုနဲ့ ချိန်ပြီး အကဲဖြတ်တာပါ။ မှန်တဲ့ output က ဘာလဲ ဆိုတာ မှတ်တမ်းတင်ထားပြီးရင် မှားတဲ့ output တစ်ခုကို “မှန်သလိုလိုပဲ” လို့ နောက်မှ ကိုယ့်ကိုယ်ကို ယုံကြည်အောင် ပြောဖို့ အများကြီး ပိုခက်ပါတယ်။
ဇယားမှာ ပုံမှန်အားဖြင့် ဒီ column တွေ ပါပါတယ်:
| Test | What it checks (ဘာကို စစ်လဲ) | Test data | Type (အမျိုးအစား) | Expected result (မျှော်မှန်းထားတဲ့ ရလဒ်) | Actual result (တကယ့် ရလဒ်) | Pass/Fail (အောင်/ကျ) |
|---|---|---|---|---|---|---|
| 1 | Normal score တစ်ခုကို လက်ခံတယ် | 45 | Normal | သိမ်းပြီး 45 လို့ ပြတယ် | ||
| 2 | အောက်ဘက် အစွန်းကို လက်ခံတယ် | 0 | Boundary | သိမ်းပြီး 0 လို့ ပြတယ် | ||
| 3 | အပေါ်ဘက် အစွန်းကို လက်ခံတယ် | 100 | Boundary | သိမ်းပြီး 100 လို့ ပြတယ် | ||
| 4 | အောက်ဆုံး တန်ဖိုးရဲ့ အောက် နားလေးကို ငြင်းပယ်တယ် | -1 | Boundary | message တစ်ခုနဲ့ ငြင်းပယ်တယ် | ||
| 5 | အမြင့်ဆုံး တန်ဖိုးရဲ့ အပေါ် နားလေးကို ငြင်းပယ်တယ် | 101 | Boundary | message တစ်ခုနဲ့ ငြင်းပယ်တယ် | ||
| 6 | စာသားကို ငြင်းပယ်တယ် | “hello” | Invalid | message တစ်ခုနဲ့ ငြင်းပယ်တယ်၊ crash မဖြစ်ဘူး |
Success criteria ရှိတဲ့ project တစ်ခုမှာ test တစ်ခုစီက ဘယ် success criterion ကို စစ်လဲ ဆိုတာ ဖော်ပြတဲ့ column တစ်ခု ထပ်ထည့်ပါ၊ ဒါမှ criterion တိုင်းမှာ test အနည်းဆုံး တစ်ခု ရှိမရှိ အမြန် စစ်နိုင်ပါမယ်။
Test တစ်ခုချင်းစီကို မ run မချင်း “Actual result” နဲ့ “Pass/Fail” ကို အလွတ် ထားပါ၊ run ပြီးမှ ဖြည့်ပါ။ Test တစ်ခု fail (ကျ) ဖြစ်ရင် အကြောင်းရင်းကို ရှာပါ: များသောအားဖြင့် program ထဲက error တစ်ခုပါ၊ တစ်ခါတလေတော့ expected result က မှားနေတာ ဖြစ်နိုင်ပါတယ်။ ပြင်ပြီးရင် အဲဒီ test နဲ့ အရင်က pass (အောင်) ဖြစ်ခဲ့တဲ့ test တွေကို ပြန် run ပါ၊ ဘာလို့လဲဆိုတော့ ပြောင်းလဲမှု တစ်ခုက အရင်က အလုပ်လုပ်ခဲ့တဲ့ အရာ တစ်ခုခုကို ပျက်စေနိုင်လို့ပါ။ အရင် test တွေကို ပြန် run တာကို regression testing (ပြင်ပြီးနောက် အရင် test တွေကို ပြန် run ပြီး စစ်ခြင်း) လို့ ခေါ်ပါတယ်။ Fail ဖြစ်တဲ့ test က အသုံးဝင်ပါတယ်: expected result နဲ့ actual result ကြားက စုံစမ်းရမယ့် မကိုက်ညီမှုကို ပြပေးပါတယ်၊ development (software တည်ဆောက်တဲ့ အလုပ်) လုပ်နေစဉ်မှာ ပြဿနာ တစ်ခုကို တွေ့တာက ကိုယ့် user တွေ အဲဒီ ပြဿနာနဲ့ မကြုံရအောင် ကာကွယ်ပေးနိုင်ပါတယ်။
IB CS သင်တန်း တက်နေသူတွေအတွက် မှတ်ချက်: Internal Assessment မှာ Criterion C: System overview က ကိုယ့် success criteria နဲ့ ကိုက်ညီတဲ့ testing strategy တစ်ခုကို တောင်းပါတယ်။ IB guide (IB ရဲ့ တရားဝင် သင်ရိုး လမ်းညွှန်) က testing strategy ကို “a systematic approach for evaluating whether the computational solution works as intended” (computational ဖြေရှင်းချက်က ရည်ရွယ်ထားတဲ့အတိုင်း အလုပ်လုပ်မလုပ် အကဲဖြတ်တဲ့ စနစ်တကျ ချဉ်းကပ်နည်း) လို့ ဖော်ပြထားပါတယ်။ အဲဒီ strategy က code “functions correctly and handles unexpected or incorrect inputs” (မှန်မှန်ကန်ကန် အလုပ်လုပ်ပြီး မမျှော်လင့်ထားတဲ့ ဒါမှမဟုတ် မှားတဲ့ input တွေကို ကိုင်တွယ်နိုင်) ကြောင်း စစ်သင့်ပြီး အပေါ်က ဇယားလို အဆိုပြုထားတဲ့ test data နဲ့ မျှော်မှန်းထားတဲ့ ရလဒ်တွေ ပါတဲ့ ဇယား တစ်ခုနဲ့ ပြနိုင်တယ်လို့ guide က ဆိုပါတယ်။ Criterion D: Development မှာ testing strategy ထဲမှာ correctness (မှန်ကန်မှု)၊ reliability (စိတ်ချရမှု) နဲ့ efficiency (ထိရောက်မှု) အတွက် testing ပါရပါမယ်။ အဲဒါကို ကိုယ့် documentation (program ကို ရှင်းပြတဲ့ စာရွက်စာတမ်း) ထဲမှာ ဖော်ပြပြီး ဘာကြောင့် ဒီလို ရွေးလဲ အကြောင်းပြရပါမယ်၊ ကိုယ့် video ထဲမှာ ဥပမာတွေ ပြရပါမယ်။ ပြီးရင် Criterion E: Evaluation (အမှတ်ပေး စံနှုန်း E: အကဲဖြတ်ခြင်း) က ကိုယ့် success criteria တွေ ဘယ်အတိုင်းအတာအထိ ပြည့်မီလဲ အကဲဖြတ်ပါတယ်၊ ကိုယ့် test ရလဒ်တွေက အဲဒီအတွက် အသုံးဝင်တဲ့ အထောက်အထား ဖြစ်ပါတယ်။ Success criteria တွေ ဖော်ပြထားတဲ့ feature တွေအတွက် test တွေကို အမျိုးအစား သုံးမျိုးလုံးက data နဲ့ ရွေးပါ။
Quick Check (အမြန် စစ်ဆေးမေးခွန်း)
Q1. Input တစ်ခုအတွက် test data ကို ပုံမှန်အားဖြင့် အမျိုးအစား သုံးမျိုးကနေ ရွေးပါတယ်။ ဘယ်သုံးမျိုးလဲ။
Q2. အရေအတွက် field တစ်ခုက 1 ကနေ 10 အထိ ကိန်းပြည့်တွေကို လက်ခံပါတယ်။ ဒါတွေထဲက ဘယ်ဟာက boundary value လဲ။
Q3. ဘယ်နည်းက feature တစ်ခုကို အစေ့စပ်ဆုံး စမ်းစစ်ပေးလဲ။
Q4. Tester က code ကို မကြည့်ဘဲ requirement တွေကနေ သက်သက် input တွေနဲ့ expected result တွေကို ရွေးတဲ့ testing ကို ဘယ်လို ခေါ်လဲ။
Q5. ဒါတွေထဲက ဘယ်ဟာက testing ရဲ့ ရည်ရွယ်ချက် တစ်ခုလဲ။
Q6. Test တစ်ခုရဲ့ expected result ကို ဘာကြောင့် test ကို မ run ခင် ဆုံးဖြတ်ထားသင့်လဲ။
Classify the Test Data (test data အမျိုးအစား ခွဲခြားခြင်း)
Website တစ်ခုရဲ့ sign-up form (အကောင့်ဖွင့်တဲ့ form) က 13 ကနေ 120 အထိ ကိန်းပြည့် အသက်ကို လက်ခံပါတယ်။ Test တန်ဖိုး တစ်ခုစီကို အမျိုးအစား ခွဲပါ။ ကွက်လပ်တွေမှာ English လို normal၊ boundary ဒါမှမဟုတ် invalid လို့ ရိုက်ထည့်ရပါမယ်။ Code block ထဲက Age entered: ဆိုတာ “ထည့်လိုက်တဲ့ အသက်:”၊ Category: ဆိုတာ “အမျိုးအစား:” လို့ ဆိုလိုပြီး "twenty" ဆိုတာ ဂဏန်းနဲ့ မဟုတ်ဘဲ စာလုံးနဲ့ ရေးထားတဲ့ “နှစ်ဆယ်” ပါ။
ကွက်လပ် ဖြည့်ပါ: normal၊ boundary ဒါမှမဟုတ် invalid ကို ရိုက်ထည့်ပါ။
// Age entered: 40
// Category:
// Age entered: 13
// Category:
// Age entered: 120
// Category:
// Age entered: 150
// Category:
// Age entered: "twenty"
// Category: 12 နဲ့ 121 ကလည်း အသုံးဝင်တဲ့ test တွေပါ: အပိုင်းအခြားရဲ့ အပြင်ဘက် နားလေးက boundary value တွေ ဖြစ်လို့ အစွန်း တစ်ခုစီကို တစ်ဆင့် ကျော်သွားတဲ့ အသက်ကို form က ငြင်းပယ်မပယ် စစ်ပေးပါတယ်။
Practice Exercises (လေ့ကျင့်ခန်းများ)
IB CS သင်တန်း တက်နေသူတွေအတွက် မှတ်ချက်: ဒီလေ့ကျင့်ခန်းတွေက test data ရွေးတာနဲ့ test plan ရေးတာကို လေ့ကျင့်ပေးပါတယ်၊ ဒါတွေက Internal Assessment ရဲ့ Criteria C နဲ့ D မှာ testing strategy ရဲ့ နောက်ကွယ်က ကျွမ်းကျင်မှုတွေပါ။
Define နဲ့ Explain လို English စကားလုံးတွေက IB command term (မေးခွန်းမှာ ဘာလုပ်ရမလဲ ပြတဲ့ ညွှန်ကြားချက် စကားလုံး) တွေပါ။ (4 marks) လို mark allocation (မေးခွန်း တစ်ခုစီအတွက် ပေးတဲ့ အမှတ်) တွေက IB Computer Science စာမေးပွဲ ပုံစံအတိုင်း ပေးထားတာပါ၊ ဥပမာ (4 marks) ဆိုတာ 4 မှတ်ပါ။ IB သင်တန်း မတက်တဲ့သူတွေကတော့ အဖြေ ဘယ်လောက် အသေးစိတ် ရေးရမလဲ ချိန်ကြည့်ဖို့ လမ်းညွှန်အဖြစ် သုံးနိုင်ပါတယ်။
Core (အခြေခံ အဆင့်)
-
Define (အဓိပ္ပာယ်ကို တိတိကျကျ ဖော်ပြပါ) (3 marks): Normal၊ boundary နဲ့ invalid test data တွေကို define လုပ်ပါ၊ 1 ကနေ 12 အထိ လ နံပါတ်ကို လက်ခံတဲ့ field တစ်ခုအတွက် တစ်ခုစီရဲ့ ဥပမာ တစ်ခု ပေးပါ။
-
Identify (ဖြစ်နိုင်တဲ့ အဖြေတွေထဲက ရွေးပြီး ဖော်ပြပါ) (4 marks): Password တစ်ခုက character (စာလုံး ဒါမှမဟုတ် သင်္ကေတ) 8 လုံးကနေ 16 လုံးအထိ ရှည်ရပါမယ်။ Normal test တန်ဖိုး တစ်ခု၊ boundary test တန်ဖိုး နှစ်ခုနဲ့ invalid test တန်ဖိုး တစ်ခုကို identify လုပ်ပြီး တစ်ခုစီရဲ့ expected result ကို ဖော်ပြပါ။
-
Construct (ကိုယ်တိုင် တည်ဆောက်ပါ) (4 marks): Online ဆိုင် တစ်ဆိုင်က ဖောက်သည်ကို 1 ကနေ 5 အထိ ကိန်းပြည့် အရေအတွက်နဲ့ shopping basket (ဈေးဝယ် ခြင်း) ထဲ ပစ္စည်း တစ်ခု ထည့်ခွင့် ပေးပါတယ်။ ဒီစည်းမျဉ်းအတွက် ဒီစာမျက်နှာမှာ သုံးထားတဲ့ column တွေနဲ့ အတန်း ငါးတန်း ပါတဲ့ test plan တစ်ခုကို construct လုပ်ပါ။ Normal test အနည်းဆုံး တစ်ခု၊ boundary test အနည်းဆုံး တစ်ခုနဲ့ invalid test အနည်းဆုံး တစ်ခု ထည့်ပါ။
Extension (တိုးချဲ့ အဆင့်)
-
Explain (ရှင်းပြပါ) (4 marks): ဖုန်း တစ်လုံးက battery 20% ဒါမှမဟုတ် အဲဒီအောက် ကျသွားရင် battery saver (battery ချွေတာတဲ့ mode) ကို ဖွင့်ပါတယ်။ Program ကို 50% (battery saver ပိတ်ထားဆဲ) နဲ့ 5% (battery saver ပွင့်လာ) မှာ စမ်းစစ်ခဲ့ပြီး test နှစ်ခုလုံး pass ဖြစ်ခဲ့ပါတယ်။ ဒီလို normal data ကိုပဲ စမ်းစစ်တာက error တစ်ခုကို user တွေဆီ ရောက်သွားစေနိုင်တာ ဘာကြောင့်လဲ explain လုပ်ပါ။ ဒီစည်းမျဉ်းအတွက် boundary value တစ်ခုနဲ့ ကိုယ့်အဖြေကို ဥပမာ ပြပါ။
-
Distinguish (အရာ နှစ်ခု ဒါမှမဟုတ် ပိုများတဲ့ အရာတွေကြားက ကွာခြားချက်ကို ရှင်းရှင်းလင်းလင်း ပြပါ) (4 marks): Black-box testing နဲ့ white-box testing ကြားက ကွာခြားချက်ကို distinguish လုပ်ပြီး တစ်ခုစီက ပိုကောင်းတဲ့ ရွေးချယ်မှု ဖြစ်မယ့် အခြေအနေ တစ်ခုစီ ပေးပါ။
Challenge (စိန်ခေါ်မှု အဆင့်)
- Discuss (အမြင် အမျိုးမျိုးကို ချိန်ဆပြီး ဆွေးနွေးပါ) (8 marks): “Program က ကိုယ့်ကိုယ်ပိုင် input တွေနဲ့ မှန်မှန်ကန်ကန် run ရင် test လုပ်ပြီးသား ဖြစ်တယ်။” ဒီပြောဆိုချက်ကို test data အမျိုးအစားတွေ၊ expected result တွေနဲ့ testing ရဲ့ ရည်ရွယ်ချက်ကို ကိုးကားပြီး discuss လုပ်ပါ။ အကြောင်းပြချက် ခိုင်လုံတဲ့ နိဂုံးချုပ် တစ်ခုအထိ ရေးပါ။ (Prose နဲ့၊ ဆိုလိုတာက စာကြောင်း အပြည့်အစုံ ပါတဲ့ စာပိုဒ်တွေနဲ့ ရေးပါ။)
ဆက်စပ် ခေါင်းစဉ်များ
- အရင် လေ့လာထားရမယ့် ခေါင်းစဉ်: Requirements Gathering (requirement တွေ စုဆောင်းခြင်း): success criteria တွေက ကိုယ့် test တွေ တိုက်စစ်ရမယ့် အရာတွေပါ
- အရင် လေ့လာထားရမယ့် ခေါင်းစဉ်: Design Representations (ဒီဇိုင်းကို ဖော်ပြတဲ့ နည်းလမ်းများ): data dictionary (ဒေတာ item တစ်ခုချင်းရဲ့ type နဲ့ စည်းမျဉ်းတွေကို စာရင်းပြုစုထားတဲ့ ဇယား) ထဲက validation rule (တန်ဖိုး မှန်မမှန် စစ်တဲ့ စည်းမျဉ်း) တွေက test data အတွက် အကြံ ပေးပါတယ်
- ဆက်စပ် ခေါင်းစဉ်: Debugging (program ထဲက အမှားကို ရှာပြီး ပြင်ခြင်း): test တစ်ခုက ပြဿနာ တစ်ခုကို တွေ့ပြီးရင် လုပ်ရမယ့် အရာ၊ trace table တွေ အပါအဝင်
- ဆက်စပ် ခေါင်းစဉ်: Exception Handling (exception တွေကို ကိုင်တွယ်ခြင်း): program က crash မဖြစ်ဘဲ မမျှော်လင့်ထားတဲ့ input ကို ဘယ်လို ကိုင်တွယ်နိုင်လဲ
- နောက်ထပ် လေ့လာမယ့် ခေါင်းစဉ်: Documentation and User Guides (documentation နဲ့ အသုံးပြုနည်း လမ်းညွှန်များ): ပြီးသွားတဲ့ စနစ် ဘယ်လို အလုပ်လုပ်လဲ မှတ်တမ်းတင်ခြင်း
- ဆက်စပ် ခေါင်းစဉ်: Internal Assessment: Criterion C: System overview (testing strategy) နဲ့ Criterion D: Development (အဲဒါကို လက်တွေ့ လုပ်ဆောင်ခြင်း)