ການສອນນີ້ອະທິບາຍສະຖານະການທົດສອບພ້ອມກັບຄວາມສຳຄັນ, ການປະຕິບັດ, ຕົວຢ່າງ, ແລະແມ່ແບບຂອງສະຖານະການທົດສອບ:
ຟັງຊັນ/ຄຸນສົມບັດຊອບແວທີ່ສາມາດທົດສອບໄດ້. ຖືກກ່າວວ່າເປັນສະຖານະການທົດສອບ. ທັດສະນະຂອງຜູ້ໃຊ້ສຸດທ້າຍຖືກພິຈາລະນາໃນຂະນະທີ່ຂຽນສະຖານະການທົດສອບໃດໆ.
ການສອນນີ້ຈະຊ່ວຍເຈົ້າໃນການຕອບຄໍາຖາມ: ເປັນຫຍັງສະຖານະການທົດສອບຈຶ່ງຕ້ອງການ, ເມື່ອສະຖານະການທົດສອບແມ່ນ. ຂຽນ ແລະວິທີການຂຽນສະຖານະການທົດສອບ.
ສະຖານະການທົດສອບແມ່ນຫຍັງ?
ພິຈາລະນາສະຖານະການສົມມຸດຕິຖານ: ມີມະຫາສະໝຸດທີ່ກວ້າງໃຫຍ່ໄພສານ. ເຈົ້າຕ້ອງເດີນທາງຂ້າມມະຫາສະໝຸດຈາກຝັ່ງທະເລໜຶ່ງໄປຫາອີກຝັ່ງໜຶ່ງ. ຕົວຢ່າງ, ຈາກ Mumbai, India Seashore ຫາ Colombo, Srilanka seashore.
ຮູບແບບການເດີນທາງທີ່ທ່ານສາມາດເລືອກໄດ້ແມ່ນ:
(i) ສາຍການບິນ: ໃຊ້ຖ້ຽວບິນໄປ Colombo
(ii) ທາງນ້ຳ: ຕ້ອງການເຮືອເພື່ອເດີນທາງໄປ Colombo
(iii) ທາງລົດໄຟ: ໄປສີລັງກາ
ຕອນນີ້ສຳລັບສະຖານະການທົດສອບ: ການເດີນທາງຈາກຊາຍຝັ່ງທະເລ Mumbai ໄປຫາຝັ່ງທະເລ Colombo ແມ່ນການເຮັດວຽກທີ່ຕ້ອງທົດສອບ.
ສະຖານະການທົດສອບລວມມີ:
- ການເດີນທາງໂດຍສາຍການບິນ,
- ການເດີນທາງໂດຍທາງນໍ້າ ຫຼື
- ການເດີນທາງດ້ວຍລົດໄຟ.
ສະຖານະການທົດສອບເຫຼົ່ານີ້ຈະມີກໍລະນີທົດສອບ.
ກໍລະນີທົດສອບທີ່ສາມາດຂຽນໄດ້ສໍາລັບສະຖານະການທົດສອບຂ້າງເທິງລວມມີ:
ການທົດສອບຢູ່ໃນທ້ອງຖິ່ນ ແລະ ອັບໂຫຼດເມື່ອມີການເຊື່ອມຕໍ່ອິນເຕີເນັດ. 6 ການປ່ຽນແປງທີ່ເຮັດໂດຍຜູ້ໃຊ້ຫຼາຍຄົນບໍ່ໄດ້ຂຽນຫຼາຍເກີນໄປ. 23 7 ຜູ້ໃຊ້ຫຼາຍຄົນສາມາດເຮັດວຽກໃນເອກະສານດຽວໄດ້. 8 ວຽກທີ່ເຮັດແລ້ວຈະຖືກເກັບໄວ້ຖ້າການເຊື່ອມຕໍ່ອິນເຕີເນັດເສຍໃນຂະນະທີ່ອັບໂຫຼດໄຟລ໌. 9 ຂໍ້ຈຳກັດການແບ່ງປັນຖືກນຳໃຊ້ຢ່າງຖືກຕ້ອງ.26 10 ເບິ່ງການຈຳກັດຜູ້ໃຊ້ບໍ່ສາມາດແກ້ໄຂເອກະສານໃດໆໄດ້. 11 ເອກະສານສາມາດຖືກເຜີຍແຜ່ໃນອິນເຕີເນັດສໍາລັບປະຊາຊົນທົ່ວໄປ. 12 ການປ່ຽນແປງທີ່ເຮັດແລ້ວກັບ ເອກະສານໄດ້ຖືກບັນທຶກໄວ້ທີ່ມີສະແຕມທີ່ໃຊ້ເວລາ & amp; ລາຍລະອຽດຂອງຜູ້ຂຽນ.
ຈຳນວນສະຖານະການທົດສອບຈະມີຫຼາຍ ແລະຫຼາຍສຳລັບ Google Docs. ໃນກໍລະນີດັ່ງກ່າວ, ໂດຍທົ່ວໄປແລ້ວ, ພຽງແຕ່ເງື່ອນໄຂການຍອມຮັບແມ່ນຖືກກໍານົດແລະອະນຸມັດໂດຍພາກສ່ວນກ່ຽວຂ້ອງ, ແລະສະມາຊິກທີມງານເຮັດວຽກກ່ຽວກັບເງື່ອນໄຂການຍອມຮັບເຫຼົ່ານີ້. ການຂຽນກໍລະນີທົດສອບ ຫຼືແທນສະຖານະການທົດສອບສາມາດເປັນວຽກທີ່ໜັກໜ່ວງສຳລັບແອັບພລິເຄຊັນຂະໜາດໃຫຍ່.
ເງື່ອນໄຂການຍອມຮັບເຫຼົ່ານີ້ມີບົດບາດສຳຄັນໃນການວາງແຜນຂະບວນການຊໍ້າຄືນ ແລະບໍ່ຄວນຖືກມອງຂ້າມ. ການກຳນົດພວກມັນໄວ້ລ່ວງໜ້າ ແລະ ລ່ວງໜ້າຫຼີກລ້ຽງຄວາມແປກໃຈ ຫຼື ຄວາມຕົກໃຈໃນຕອນທ້າຍຂອງການແລ່ນ ຫຼື ການປ່ອຍຕົວ
ໃຫ້ ເງື່ອນໄຂກ່ອນ.
ເມື່ອໃດ ເພື່ອເຮັດການກະທຳ.
ຈາກນັ້ນ ຄາດວ່າຜົນໄດ້ຮັບ.
ຮູບແບບຂອງ Given,ເມື່ອໃດ ແລະ ຈາກນັ້ນມີປະໂຫຍດໃນການລະບຸເງື່ອນໄຂການຍອມຮັບ.
ຕົວຢ່າງຂອງແມ່ແບບສະຖານະການທົດສອບ
| ໃຊ້ Story ID # | Test Scenario ID # | ເວີຊັນ # | ສະຖານະການທົດສອບ | # ບໍ່ມີກໍລະນີທົດສອບ | ຄວາມສຳຄັນ |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | ກວດສອບວ່າ Kindle App ເປີດຢ່າງຖືກຕ້ອງຫຼືບໍ່. | 4 | ສູງ |
| USID12.1 | TSID12.1.2 | Kin12.4 | ກວດສອບຄວາມອາດສາມາດບ່ອນຈັດເກັບຂໍ້ມູນຂອງ Kindle App. | 3 | ປານກາງ |
ສະຫຼຸບ
ໃນການທົດສອບຊອບແວໃດນຶ່ງ, ຄວາມເຂົ້າໃຈຂອງວົງຈອນຊີວິດ ແລະການຈັດວາງສະຖານະການທົດສອບ ເປັນອົງປະກອບທີ່ສໍາຄັນຫຼາຍ. ຄຸນນະພາບຂອງຊອບແວສາມາດໄດ້ຮັບການປັບປຸງໂດຍການມີພື້ນຖານທີ່ດີສໍາລັບສະຖານະການການທົດສອບ. ເລື້ອຍໆ, ການໃຊ້ກໍລະນີທົດສອບ ແລະ ສະຖານະການທົດສອບອາດມີການປ່ຽນແປງກັນ.
ແນວໃດກໍ່ຕາມ, ກົດລະບຽບຂອງໂປ້ມືແມ່ນວ່າສະຖານະການທົດສອບແມ່ນໃຊ້ເພື່ອຂຽນກໍລະນີທົດສອບຫຼາຍອັນ ຫຼືພວກເຮົາສາມາດເວົ້າໄດ້ວ່າກໍລະນີທົດສອບແມ່ນມາຈາກສະຖານະການທົດສອບ. ສະຖານະການທົດສອບທີ່ຖືກກໍານົດໄວ້ດີຮັບປະກັນຊອບແວທີ່ມີຄຸນນະພາບດີ.
ສະຖານະການ: ການເດີນທາງໂດຍສາຍການບິນກໍລະນີທົດສອບສາມາດປະກອບມີສະຖານະການເຊັ່ນ:
- ຖ້ຽວບິນແມ່ນໄປຕາມເວລາທີ່ກໍານົດໄວ້. .
- ຖ້ຽວບິນບໍ່ເປັນໄປຕາມເວລາທີ່ກຳນົດໄວ້.
- ມີສະຖານະການສຸກເສີນເກີດຂຶ້ນ (ຝົນຕົກໜັກ ແລະພາຍຸ).
ໃນແບບດຽວກັນ, a ຊຸດກໍລະນີທົດສອບແຍກຕ່າງຫາກສາມາດຂຽນໄດ້ສໍາລັບສະຖານະການອື່ນໆທີ່ຍັງເຫຼືອ.
ຕອນນີ້ໃຫ້ພວກເຮົາເຂົ້າສູ່ສະຖານະການທົດສອບທາງດ້ານເຕັກໂນໂລຢີ.
ອັນໃດກໍໄດ້ທີ່ສາມາດທົດສອບໄດ້ແມ່ນສະຖານະການທົດສອບ. ດັ່ງນັ້ນ, ພວກເຮົາສາມາດລະບຸໄດ້ວ່າການເຮັດວຽກຂອງຊອບແວທີ່ຢູ່ພາຍໃຕ້ການທົດສອບສາມາດແບ່ງອອກເປັນຫຼາຍຫນ້າທີ່ນ້ອຍກວ່າແລະສາມາດເອີ້ນວ່າເປັນ 'Test Scenario'.
ກ່ອນທີ່ຈະສົ່ງຜະລິດຕະພັນໃດໆໃຫ້ແກ່ລູກຄ້າ, ຄຸນນະພາບຂອງຜະລິດຕະພັນຈໍາເປັນຕ້ອງໄດ້. ໄດ້ຮັບການປະເມີນຜົນແລະການປະເມີນຜົນ. ສະຖານະການທົດສອບຊ່ວຍໃນການປະເມີນຄຸນນະພາບການເຮັດວຽກຂອງແອັບພລິເຄຊັນຊອບແວທີ່ສອດຄ່ອງກັບຄວາມຕ້ອງການຂອງທຸລະກິດຂອງມັນ.
ສະຖານະການທົດສອບແມ່ນຂະບວນການທີ່ຜູ້ທົດສອບຈະທົດສອບແອັບພລິເຄຊັນຊອບແວຈາກມຸມເບິ່ງຂອງຜູ້ໃຊ້ສຸດທ້າຍ. ປະສິດທິພາບ ແລະຄຸນນະພາບຂອງແອັບພລິເຄຊັນຊອບແວໄດ້ຖືກປະເມີນຢ່າງລະອຽດກ່ອນການຈັດຕັ້ງປະຕິບັດໃນສະພາບແວດລ້ອມການຜະລິດ. ມັນສາມາດຖືກຄິດໄດ້ວ່າເປັນຮູບພາໂນຣາມາໃຫຍ່ ແລະກໍລະນີທົດສອບແມ່ນພາກສ່ວນນ້ອຍໆທີ່ມີຄວາມສໍາຄັນໃນການເຮັດພາໂນຣາມາໃຫ້ສົມບູນ.
ສະຖານະການທົດສອບ: ເຮັດ ຊໍາລະຄ່າບໍລິການລົດແທັກຊີທີ່ສາມາດໃຊ້ໄດ້.
ອັນນີ້ຈະມີກໍລະນີທົດສອບຫຼາຍອັນຕາມທີ່ລະບຸໄວ້ຂ້າງລຸ່ມນີ້:
(i) ວິທີການຊໍາລະເງິນທີ່ຈະໃຊ້: PayPal, Paytm, ບັດເຄຣດິດ/ເດບິດ.
(ii) ການຈ່າຍເງິນສຳເລັດແລ້ວ.
(iii) ການຈ່າຍເງິນທີ່ເຮັດແລ້ວບໍ່ສຳເລັດ.
(iv) ຂະບວນການຊຳລະເງິນຖືກຍົກເລີກໃນລະຫວ່າງ.
(v) ບໍ່ສາມາດເຂົ້າເຖິງວິທີການຊຳລະເງິນໄດ້.
(vi) ໃບສະຫມັກແຕກອອກສູ່ລະຫວ່າງ.
10. ເມື່ອກໍານົດ, ຊ່ວຍໃນ bifurcating ຂອບເຂດຂອງການທົດສອບ.ຄວາມແຕກຕ່າງລະຫວ່າງສະຖານະການທົດສອບ ແລະກໍລະນີທົດສອບ
| Test Scenario | Test Cases | ||
|---|---|---|---|
| Test scenario is a concept. | Test case are the solutions to verify that concept .26 | ||
| ສະຖານະການທົດສອບແມ່ນການເຮັດວຽກລະດັບສູງ. | ກໍລະນີທົດສອບແມ່ນຂັ້ນຕອນລະອຽດເພື່ອທົດສອບຟັງຊັນລະດັບສູງ. | ||
| ສະຖານະການທົດສອບ ແມ່ນໄດ້ມາຈາກ Requirements/User Stories. | Test case ແມ່ນໄດ້ມາຈາກ Test Scenario . | ||
| Test scenario is 'What function to be tested' | Test Cases ແມ່ນ 'ວິທີທົດສອບການທໍາງານ '. | ||
| ສະຖານະການທົດສອບມີຫຼາຍກໍລະນີທົດສອບ. | ກໍລະນີທົດສອບອາດມີຫຼືບໍ່ກ່ຽວຂ້ອງກັບຫຼາຍໆສະຖານະການທົດສອບ. | ||
| ສະຖານະການທົດສອບຄັ້ງດຽວບໍ່ເຄີຍເຮັດຊ້ຳໄດ້. | ກໍລະນີທົດສອບຄັ້ງດຽວອາດຈະຖືກໃຊ້ຫຼາຍຄັ້ງໃນສະຖານະການຕ່າງໆ. | ||
| ຕ້ອງມີເອກະສານສັ້ນໆ. | ຕ້ອງມີເອກະສານລະອຽດ. | ||
| ກອງປະຊຸມລະດົມຄວາມຄິດແມ່ນຕ້ອງການເພື່ອສະຫຼຸບສະຖານະການທົດສອບ. | ຄວາມຮູ້ດ້ານວິຊາການລະອຽດຂອງແອັບພລິເຄຊັນຊອບແວ. ຕ້ອງການ | ||
| ປະຫຍັດເວລາເນື່ອງຈາກລາຍລະອຽດນາທີແມ່ນບໍ່ຈໍາເປັນ. | ໃຊ້ເວລາຫຼາຍເນື່ອງຈາກລາຍລະອຽດທຸກນາທີຕ້ອງໄດ້ຮັບການດູແລ> | ຄ່າໃຊ້ຈ່າຍໃນການບຳລຸງຮັກສາແມ່ນຕໍ່າຕາມຄວາມຕ້ອງການຊັບພະຍາກອນຕໍ່າ. | ຄ່າໃຊ້ຈ່າຍໃນການບຳລຸງຮັກສາແມ່ນສູງເນື່ອງຈາກຊັບພະຍາກອນທີ່ຕ້ອງການສູງ |
ເປັນຫຍັງສະຖານະການທົດສອບຈຶ່ງຂາດບໍ່ໄດ້?
ສະຖານະການທົດສອບແມ່ນມາຈາກຄວາມຕ້ອງການ ຫຼືເລື່ອງຂອງຜູ້ໃຊ້.
- ເອົາຕົວຢ່າງຂອງສະຖານະການທົດສອບສຳລັບການຈອງລົດແທັກຊີ.
- ສະຖານະການ ອາດຈະເປັນທາງເລືອກໃນການຈອງລົດໂດຍສານ, ວິທີການຈ່າຍເງິນ, ການຕິດຕາມ GPS, ແຜນທີ່ຖະຫນົນທີ່ສະແດງຢ່າງຖືກຕ້ອງຫຼືບໍ່, ລາຍລະອຽດ cab ແລະຄົນຂັບລົດຖືກສະແດງຢ່າງຖືກຕ້ອງຫຼືບໍ່, ແລະອື່ນໆທັງຫມົດແມ່ນສະແດງຢູ່ໃນແມ່ແບບສະຖານະການທົດສອບ.
- ຕອນນີ້ສົມມຸດວ່າສະຖານະການການທົດສອບແມ່ນ ເພື່ອກວດເບິ່ງວ່າການບໍລິການສະຖານທີ່ເປີດຫຼືບໍ່, ຖ້າບໍ່ໄດ້ເປີດ, ສະແດງຂໍ້ຄວາມ 'ເປີດບໍລິການສະຖານທີ່. ສະຖານະການນີ້ພາດໂອກາດນີ້ ແລະບໍ່ໄດ້ລະບຸໄວ້ໃນແມ່ແບບສະຖານະການທົດສອບ.
- ສະຖານະການ 'ບໍລິການສະຖານທີ່' ເຮັດໃຫ້ເກີດສະຖານະການທົດສອບອື່ນໆທີ່ກ່ຽວຂ້ອງກັບມັນ.
ສິ່ງເຫຼົ່ານີ້ສາມາດເປັນ :
-
- ບໍລິການສະຖານທີ່ເປັນສີຂີ້ເຖົ່າ.
- ການບໍລິການສະຖານທີ່ເປີດແຕ່ບໍ່ມີອິນເຕີເນັດ.
- ຂໍ້ຈຳກັດການບໍລິການສະຖານທີ່ .
- ສະຖານທີ່ທີ່ບໍ່ຖືກຕ້ອງຖືກສະແດງ.
- ບໍ່ມີສະຖານະການດຽວ ອາດຈະໝາຍເຖິງການຫາຍໄປໃນຫຼາຍ ສະຖານະການສຳຄັນ ຫຼືກໍລະນີທົດສອບ. . ອັນນີ້ສາມາດມີ ຜົນກະທົບທາງລົບທີ່ຍິ່ງໃຫຍ່ ໃນຂະນະທີ່ການປະຕິບັດຄໍາຮ້ອງສະຫມັກຊອບແວ. ອັນນີ້ສົ່ງຜົນໃຫ້ການສູນເສຍການທົດແທນຢ່າງໜັກໜ່ວງ (ກຳນົດເວລາ).
- ສະຖານະການທົດສອບຊ່ວຍໃນຂອບເຂດທີ່ດີໃນ ການຫຼີກລ່ຽງການທົດສອບທີ່ຄົບຖ້ວນ . ມັນຮັບປະກັນວ່າທັງຫມົດທີ່ສໍາຄັນແລະກະແສທຸລະກິດທີ່ຄາດວ່າຈະໄດ້ຮັບການທົດສອບ, ເຊິ່ງຊ່ວຍໃນການທົດສອບຕົ້ນທາງຈົນຈົບຂອງແອັບພລິເຄຊັນ.
- ເຫຼົ່ານີ້ແມ່ນປະຫຍັດເວລາ. ນອກຈາກນີ້, ຄໍາອະທິບາຍລາຍລະອຽດຫຼາຍຕາມກໍລະນີການທົດສອບແມ່ນບໍ່ຈໍາເປັນ. ມີການລະບຸລາຍລະອຽດໃນແຖວດຽວກ່ຽວກັບສິ່ງທີ່ຈະທົດສອບ.
- ສະຖານະການທົດສອບຖືກຂຽນຫຼັງຈາກ ກອງປະຊຸມລະດົມຄວາມຄິດ ຂອງສະມາຊິກທີມ. ເພາະສະນັ້ນ, ຄວາມເປັນໄປໄດ້ຂອງການຂາດສະຖານະການໃດໆ (ສໍາຄັນຫຼືເລັກນ້ອຍ) ແມ່ນຕໍາ່ສຸດທີ່. ນີ້ແມ່ນເຮັດໄດ້ໂດຍຈື່ຈໍາທາງດ້ານເຕັກນິກ ແລະຂະບວນການທາງທຸລະກິດຂອງແອັບພລິເຄຊັນຊອບແວ.
- ນອກຈາກນັ້ນ, ສະຖານະການທົດສອບສາມາດໄດ້ຮັບການອະນຸມັດໂດຍລູກຄ້ານັກວິເຄາະທຸລະກິດ ຫຼືທັງສອງຜູ້ທີ່ມີຄວາມຮູ້ຈະແຈ້ງກ່ຽວກັບແອັບພລິເຄຊັນທີ່ກໍາລັງດໍາເນີນການທົດສອບ.
ສະຖານະການການທົດສອບດັ່ງນັ້ນຈຶ່ງເປັນພາກສ່ວນທີ່ຂາດບໍ່ໄດ້ຂອງ SDLC.
ການປະຕິບັດສະຖານະການທົດສອບ
ໃຫ້ພວກເຮົາເບິ່ງການປະຕິບັດຂອງສະຖານະການທົດສອບຫຼືວິທີການຂຽນສະຖານະການທົດສອບ:
- ຂໍ້ກຳນົດດ້ານວິຊາການ/ທຸລະກິດຖືກສ້າງຕັ້ງຂຶ້ນ.
- ຕົວຢ່າງຂອງ Epic : ສ້າງບັນຊີ Gmail. Epic ສາມາດເປັນລັກສະນະຫຼັກຂອງແອັບພລິເຄຊັນ ຫຼືຄວາມຕ້ອງການຂອງທຸລະກິດ.
- Epics ຖືກແບ່ງອອກເປັນບົດເລື່ອງຜູ້ໃຊ້ນ້ອຍໆໃນທົ່ວ sprints.
- ເລື່ອງຂອງຜູ້ໃຊ້ແມ່ນມາຈາກ Epics. ບົດເລື່ອງຂອງຜູ້ໃຊ້ເຫຼົ່ານີ້ຕ້ອງຖືກອ້າງອີງ ແລະອະນຸມັດໂດຍຜູ້ມີສ່ວນກ່ຽວຂ້ອງ. BRS (Business Requirement Document), SRS (System Requirementເອກະສານສະເພາະ), ຫຼື FRS (ເອກະສານຄວາມຕ້ອງການດ້ານການທໍາງານ) ເຊິ່ງສະຫຼຸບແລ້ວ ແລະເປັນພື້ນຖານ.
- ຜູ້ທົດສອບຂຽນສະຖານະການທົດສອບ.
- ສະຖານະການທົດສອບເຫຼົ່ານີ້ໄດ້ຮັບການອະນຸມັດໂດຍຫົວໜ້າທີມ, ນັກວິເຄາະທຸລະກິດ ຫຼືຜູ້ຈັດການໂຄງການ. ຂຶ້ນກັບອົງກອນ.
- ແຕ່ລະສະຖານະການທົດສອບຕ້ອງຖືກຜູກມັດກັບຢ່າງໜ້ອຍໜຶ່ງເລື່ອງຂອງຜູ້ໃຊ້.
- ສະຖານະການທົດສອບທາງບວກ ແລະທາງລົບຕ້ອງຖືກລະບຸ.
- ເລື່ອງຂອງຜູ້ໃຊ້ປະກອບມີ ເງື່ອນໄຂການຍອມຮັບເຊັ່ນ: :
- ເກນການຍອມຮັບແມ່ນລາຍການເງື່ອນໄຂ ຫຼືສະຖານະຂອງຄວາມຕັ້ງໃຈຂອງຄວາມຕ້ອງການຂອງລູກຄ້າ. ຄວາມຄາດຫວັງຂອງລູກຄ້າ ແລະຄວາມເຂົ້າໃຈຜິດແມ່ນຖືກພິຈາລະນາໃນຂະນະທີ່ຂຽນເງື່ອນໄຂການຍອມຮັບ.
- ສິ່ງເຫຼົ່ານີ້ແມ່ນສະເພາະສໍາລັບເລື່ອງຜູ້ໃຊ້ໜຶ່ງເລື່ອງ ແລະແຕ່ລະເລື່ອງຂອງຜູ້ໃຊ້ຈະຕ້ອງມີຢ່າງໜ້ອຍໜຶ່ງເງື່ອນໄຂການຍອມຮັບທີ່ຄວນຈະສາມາດທົດສອບໄດ້ຢ່າງເປັນເອກະລາດ.
- ເງື່ອນໄຂການຍອມຮັບຊ່ວຍໃນການກໍານົດວ່າລັກສະນະໃດຢູ່ໃນຂອບເຂດແລະທີ່ຢູ່ນອກຂອບເຂດສໍາລັບໂຄງການ. ເງື່ອນໄຂເຫຼົ່ານີ້ຄວນລວມເຖິງຄຸນສົມບັດທີ່ເປັນປະໂຫຍດ ແລະ ບໍ່ມີປະໂຫຍດ.
- ນັກວິເຄາະທຸລະກິດຂຽນເງື່ອນໄຂການຍອມຮັບ ແລະເຈົ້າຂອງຜະລິດຕະພັນອະນຸມັດ.
- ຫຼືໃນບາງກໍລະນີ, ເຈົ້າຂອງຜະລິດຕະພັນສາມາດຂຽນໄດ້ເອງ. ເງື່ອນໄຂ.
- ສະຖານະການທົດສອບສາມາດໄດ້ຮັບຈາກເງື່ອນໄຂການຍອມຮັບ.
ສະຖານະການທົດສອບ
#1) ສະຖານະການທົດສອບສໍາລັບ Kindle App
Kindle ແມ່ນແອັບທີ່ຊ່ວຍໃຫ້ຜູ້ອ່ານອີເລັກໂທຣນິກສາມາດຊອກຫາໄດ້e-books ອອນໄລນ໌, ດາວໂຫລດ, ແລະຊື້ໃຫ້ເຂົາເຈົ້າ. Amazon Kindle ໃຫ້ຜູ້ອ່ານ e-book ປະສົບການຊີວິດຈິງຂອງການຖືປື້ມຢູ່ໃນມືແລະອ່ານມັນ. ເຖິງແມ່ນວ່າການຫັນຫນ້າກໍ່ຖືກຈໍາລອງຢ່າງສວຍງາມໃນແອັບຯ.
ຕອນນີ້ໃຫ້ພວກເຮົາສັງເກດສະຖານະການທົດສອບ. ( ໝາຍເຫດ: ສະຖານະການຈຳກັດມີລາຍຊື່ຢູ່ລຸ່ມນີ້ເພື່ອໃຫ້ໄດ້ແນວຄວາມຄິດທົ່ວໄປໃນການຂຽນສະຖານະການທົດສອບ. ສາມາດມີກໍລະນີທົດສອບຫຼາຍອັນທີ່ໄດ້ມາຈາກມັນ).
| ສະຖານະການທົດສອບ. # | ສະຖານະການທົດສອບ |
|---|---|
| 1 | ກວດສອບວ່າແອັບ Kindle ເປີດຢ່າງຖືກຕ້ອງຫຼືບໍ່. |
| 2 | ກວດສອບການປັບຄວາມລະອຽດຫນ້າຈໍປັບຕາມອຸປະກອນທີ່ແຕກຕ່າງກັນ, ຫຼັງຈາກການເປີດຕົວແອັບຯ. |
| 3 | ກວດສອບວ່າຂໍ້ຄວາມທີ່ສະແດງນັ້ນສາມາດອ່ານໄດ້. |
| 4 | ກວດສອບວ່າຕົວເລືອກການຊູມເຂົ້າ ແລະຊູມອອກໃຊ້ໄດ້ແລ້ວ. |
| 5 | ກວດສອບວ່າໄຟລ໌ເຂົ້າກັນໄດ້ທີ່ນໍາເຂົ້າໃນ app Kindle ແມ່ນສາມາດອ່ານໄດ້. |
| 6 | ກວດສອບຄວາມສາມາດເກັບຮັກສາຂອງ Kindle App. |
| 7 | ກວດສອບວ່າການທໍາງານການດາວໂຫຼດເຮັດວຽກຖືກຕ້ອງ. |
| 82 | ກວດສອບການຈຳລອງ Page Turn ເຮັດວຽກຢ່າງຖືກຕ້ອງ |
| 9 | ກວດສອບຄວາມເຂົ້າກັນໄດ້ຂອງຮູບແບບ eBook ກັບແອັບຯ Kindle. |
| 10 | ກວດສອບຟອນທີ່ຮອງຮັບໂດຍແອັບຯ Kindle. |
| 11 | ກວດສອບອາຍຸແບັດເຕີຣີທີ່ໃຊ້ໂດຍແອັບຯ Kindle. |
| 12 | ກວດສອບປະສິດທິພາບຂອງ Kindle ຂຶ້ນກັບການເຊື່ອມຕໍ່ເຄືອຂ່າຍ (Wi-Fi, 3G ຫຼື 4G). |
ກໍລະນີທົດສອບຫຼາຍອັນສາມາດມາຈາກແຕ່ລະສະຖານະການທົດສອບທີ່ລະບຸໄວ້ຂ້າງເທິງ.
#2) ເງື່ອນໄຂການຍອມຮັບສຳລັບ Google Docs
'Google docs' ແມ່ນແອັບພລິເຄຊັນທີ່ໃຊ້ເວັບເພື່ອສ້າງ, ແກ້ໄຂ ແລະແບ່ງປັນເອກະສານຄຳສັບ, ສະເປຣດຊີດ, ສະໄລ້ ແລະແບບຟອມ. ໄຟລ໌ທັງໝົດສາມາດເຂົ້າເຖິງອອນໄລນ໌ໄດ້ໂດຍໃຊ້ຕົວທ່ອງເວັບທີ່ມີການເຊື່ອມຕໍ່ອິນເຕີເນັດ.
ເອກະສານທີ່ສ້າງຂຶ້ນສາມາດແບ່ງປັນເປັນໜ້າເວັບ ຫຼືເອກະສານທີ່ພ້ອມພິມ. ຜູ້ໃຊ້ສາມາດກໍານົດຂໍ້ຈໍາກັດກ່ຽວກັບຜູ້ທີ່ສາມາດເບິ່ງແລະແກ້ໄຂເອກະສານ. ເອກະສານດຽວສາມາດຮ່ວມກັນແລະເຮັດວຽກຮ່ວມກັນໂດຍບຸກຄົນທີ່ແຕກຕ່າງກັນຈາກສະຖານທີ່ຕັ້ງພູມສາດທີ່ແຕກຕ່າງກັນ.
ສະຖານະການທົດສອບທີ່ຈໍາກັດແມ່ນໄດ້ກ່າວມາຂ້າງລຸ່ມນີ້ເພື່ອຄວາມເຂົ້າໃຈທົ່ວໄປ. ສະຖານະການທົດສອບໃນຄວາມເລິກສໍາລັບ Google docs ສາມາດເປັນ. ຫົວຂໍ້ແຍກຕ່າງຫາກທັງໝົດ.
| ເງື່ອນໄຂການຍອມຮັບ # | ເງື່ອນໄຂການຍອມຮັບ |
|---|---|
| 1 | Word, Sheets ຫຼື Forms ສາມາດເປີດໄດ້ສຳເລັດໂດຍບໍ່ມີຂໍ້ຜິດພາດ. ແລະສະໄລ້. |
| 3 | ແມ່ແບບທີ່ສາມາດໃຊ້ໄດ້ແມ່ນສາມາດເຂົ້າເຖິງໄດ້ສໍາລັບຜູ້ໃຊ້. |
| 4 | ແມ່ແບບທີ່ໃຊ້ແມ່ນສາມາດແກ້ໄຂໄດ້ (ເຊັ່ນ: ຟອນ, ຂະໜາດຕົວອັກສອນ, ເພີ່ມຂໍ້ຄວາມ, ລຶບຂໍ້ຄວາມ, ໃສ່ສະໄລ້). |
| 52 | ຖ້າການເຊື່ອມຕໍ່ອິນເຕີເນັດບໍ່ສາມາດໃຊ້ໄດ້ຊົ່ວຄາວ, ໄຟລ໌ສາມາດຖືກເກັບໄວ້ |