ຂໍ້ດີແລະຂໍ້ເສຍປຽບຂອງອັດຕະໂນມັດ

ການທົດສອບອັດຕະໂນມັດ, ເມື່ອເຮັດຢ່າງຖືກຕ້ອງສາມາດມີຂໍ້ໄດ້ປຽບຫຼາຍຢ່າງແລະເປັນປະໂຫຍດຫຼາຍຕໍ່ໂຄງການແລະການຈັດຕັ້ງ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ມັນມີຂໍ້ເສຍປຽບຫຼືຂໍ້ເສຍປຽບບາງຢ່າງຂອງການທົດສອບອັດຕະໂນມັດທີ່ພວກເຮົາ ຈຳ ເປັນຕ້ອງຮູ້.



ຂໍ້ດີຂອງການທົດສອບອັດຕະໂນມັດ

ຂໍ້ດີຂອງ Test Automation ມີຂໍ້ດີແນວໃດ?

ການຢັ້ງຢືນຂອງຜູ້ທີ່ຮູ້ຈັກ

ການກວດສອບໂດຍອັດຕະໂນມັດແມ່ນວິທີການທີ່ດີໃນການຢືນຢັນວ່າແອັບພລິເຄຊັນຍັງເຮັດວຽກຢ່າງຖືກຕ້ອງຫລັງຈາກມີການປ່ຽນແປງ.


ມັນເປັນໄປໄດ້ວ່າເມື່ອມີການເພີ່ມຄຸນສົມບັດ ໃໝ່ ເຂົ້າໃນແອັບພລິເຄຊັນຫລືຂໍ້ບົກຜ່ອງຖືກແກ້ໄຂ, ມັນຈະສົ່ງຜົນກະທົບຕໍ່ການເຮັດວຽກຂອງຊອບແວທີ່ເຮັດວຽກ, i.

ໂດຍການ ດຳ ເນີນການກວດສອບການຕັ້ງຂໍ້ມູນແບບອັດຕະໂນມັດໃນເວລາທີ່ ຄຳ ຮ້ອງສະ ໝັກ ຖືກປັບປຸງ, ພວກເຮົາສາມາດ ກຳ ນົດຂໍ້ບົກຜ່ອງ ໃໝ່ ໃດໆທີ່ ນຳ ມາຈາກການປ່ຽນແປງ.


ຂໍ້ມູນທີ່ ສຳ ຄັນຢູ່ນີ້ແມ່ນການ ດຳ ເນີນການກວດສອບໂດຍອັດຕະໂນມັດເລື້ອຍໆເມື່ອ ຄຳ ຮ້ອງສະ ໝັກ ຖືກຍົກລະດັບ.

ບໍ່ ຈຳ ເປັນຕ້ອງ ດຳ ເນີນການກວດສອບແບບອັດຕະໂນມັດຄົບຊຸດ. ຊຸດເກັບກ່ຽວກັບຄວັນຢາສູບໄວຄວນພຽງພໍໃນການເກັບບັນຫາ ສຳ ຄັນຕ່າງໆ.

ຄຳ ຕິຊົມດ່ວນ

ປະໂຫຍດໃຫຍ່ອີກອັນ ໜຶ່ງ ຂອງການກວດສອບອັດຕະໂນມັດແມ່ນ ຄຳ ຕິຊົມທີ່ໄວທີ່ພວກເຮົາໄດ້ຮັບເມື່ອການສະ ໝັກ. ດີທີ່ສຸດທີມພັດທະນາຄວນແກ້ໄຂຂໍ້ບົກຜ່ອງຕ່າງໆທັນທີທີ່ມັນເກີດຂື້ນ, ກ່ອນທີ່ຈະກ້າວໄປສູ່ວຽກອື່ນ.

ກະ​ລຸ​ນາ​ບັນ​ທຶກ ວ່າ ຄຳ ຕິຊົມທີ່ວ່ອງໄວນີ້ສາມາດບັນລຸໄດ້ດ້ວຍການທົດສອບຫົວ ໜ່ວຍ ແລະການທົດສອບ API. ຖ້າພວກເຮົາທົດສອບການເຮັດວຽກຈາກ UI ຫລືໃນລະດັບລະບົບ, ການທົດສອບສາມາດໃຊ້ເວລາດົນນານເພື່ອຈະ ສຳ ເລັດ.


ການປະຕິບັດການກວດສອບໄວ

ການກວດສອບໂດຍອັດຕະໂນມັດສາມາດໃຊ້ເວລາໃນການຂຽນຄິບ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ເມື່ອພວກເຮົາປະຕິບັດພວກມັນໂດຍທົ່ວໄປແລ້ວພວກມັນໄວແລະສາມາດຜ່ານຂັ້ນຕອນຕ່າງໆໄດ້ໄວກ່ວາມະນຸດ. ສະນັ້ນ, ພວກເຂົາຊ່ວຍໃນການໃຫ້ ຄຳ ຕິຊົມທີ່ວ່ອງໄວແກ່ທີມພັດທະນາ.

ນີ້ແມ່ນຄວາມຈິງໂດຍສະເພາະໃນກໍລະນີຂອງສະຖານະການທີ່ຜັກດັນຂໍ້ມູນ.

ຮັບຮອງເອົາເວລາຂອງນັກທົດສອບ

ການນໍາໃຊ້ທີ່ດີທີ່ສຸດຂອງການກວດສອບອັດຕະໂນມັດແມ່ນການທົດສອບການຄວບຄຸມ.

ການທົດສອບການຊອກຫາແບບອັດຕະໂນມັດເຮັດໃຫ້ພວກເຮົາມີເວລາຂອງນັກທົດສອບ, ສະນັ້ນພວກເຂົາສາມາດສຸມໃສ່ການທົດລອງຊອກຄົ້ນຫາລັກສະນະ ໃໝ່ໆ.


ໂດຍເຄື່ອງ ໝາຍ ດຽວກັນ, ເມື່ອຖືກຈັດຕັ້ງປະຕິບັດຢ່າງຖືກຕ້ອງ, ການກວດສອບແບບອັດຕະໂນມັດສາມາດເຮັດວຽກໄດ້ໂດຍອັດຕະໂນມັດໂດຍບໍ່ມີການຄວບຄຸມຫລືການແຊກແຊງດ້ວຍຕົນເອງ.

ທີມງານພັດທະນາສາມາດປະກອບສ່ວນ

ການກວດສອບໂດຍອັດຕະໂນມັດແມ່ນຂຽນເປັນພາສາດຽວກັນກັບ ຄຳ ຮ້ອງທີ່ ກຳ ລັງທົດສອບ. ດ້ວຍເຫດຜົນນີ້, ຄວາມຮັບຜິດຊອບຂອງການຂຽນ, ຮັກສາແລະປະຕິບັດການສອບເສັງກາຍເປັນຄວາມຮັບຜິດຊອບຮ່ວມກັນ.

ທຸກໆຄົນໃນທີມພັດທະນາສາມາດປະກອບສ່ວນ, ບໍ່ພຽງແຕ່ຜູ້ທົດສອບ.



ຂໍ້ເສຍປຽບຂອງການທົດສອບອັດຕະໂນມັດ

ຂໍ້ເສຍປຽບຂອງ Test Automation ແມ່ນຫຍັງ?


ຄວາມຮູ້ສຶກທີ່ບໍ່ຖືກຕ້ອງກ່ຽວກັບຄຸນນະພາບ

ລະວັງການສອບເສັງຜ່ານ! ນີ້ມີຄວາມ ສຳ ຄັນໂດຍສະເພາະໃນການກວດສອບການເຮັດວຽກໃນລະດັບ UI ຫຼືລະບົບ.

ການກວດສອບແບບອັດຕະໂນມັດພຽງແຕ່ກວດເບິ່ງສິ່ງທີ່ຖືກ ກຳ ນົດໄວ້ໃນໂປແກຼມກວດສອບ.

ທຸກໆການກວດສອບແບບອັດຕະໂນມັດໃນຊຸດທົດສອບສາມາດຜ່ານໄປໄດ້ຢ່າງມີຄວາມສຸກ, ແຕ່ອາດຈະມີຂໍ້ບົກຜ່ອງທີ່ ສຳ ຄັນທີ່ບໍ່ສາມາດຄົ້ນພົບໄດ້. ເຫດຜົນ ສຳ ລັບສິ່ງນີ້ແມ່ນຍ້ອນວ່າການກວດສອບແບບອັດຕະໂນມັດບໍ່ຖືກລະຫັດເພື່ອ“ ເບິ່ງ” ສຳ ລັບຄວາມລົ້ມເຫຼວເຫຼົ່ານັ້ນ.

ວິທີແກ້ໄຂ: ຮັບປະກັນວ່າທ່ານອອກແບບສະຖານະການທົດສອບທີ່ດີກ່ອນທີ່ຈະອັດຕະໂນມັດ. ການກວດສອບແບບອັດຕະໂນມັດແມ່ນມີຄວາມ ໝາຍ ເທົ່າກັບການອອກແບບການທົດສອບ. ພ້ອມທັງສົມທົບການກວດສອບແບບອັດຕະໂນມັດດ້ວຍການທົດສອບຄູ່ມື / ການ ສຳ ຫຼວດ.


ບໍ່ ໜ້າ ເຊື່ອຖື

ການກວດສອບໂດຍອັດຕະໂນມັດສາມາດລົ້ມເຫລວຍ້ອນຫລາຍໆປັດໃຈ. ຖ້າການກວດສອບແບບອັດຕະໂນມັດຮັກສາຄວາມລົ້ມເຫລວຍ້ອນບັນຫານອກ ເໜືອ ຈາກຂໍ້ບົກພ່ອງທີ່ແທ້ຈິງ, ພວກມັນສາມາດຍົກສຽງເຕືອນທີ່ບໍ່ຖືກຕ້ອງ.

ຕົວຢ່າງ, ການກວດສອບແບບອັດຕະໂນມັດສາມາດແຕກແຍກໄດ້ເນື່ອງຈາກການປ່ຽນ UI, ການບໍລິການຫຼຸດລົງຫຼືມີບັນຫາກັບເຄືອຂ່າຍ.

ບັນຫາເຫຼົ່ານີ້ບໍ່ໄດ້ຖືກ ນຳ ໃຊ້ໂດຍກົງຈາກການ ນຳ ໃຊ້ທີ່ຖືກທົດສອບແຕ່ສາມາດສົ່ງຜົນກະທົບຕໍ່ຜົນຂອງການກວດສອບອັດຕະໂນມັດ.

ວິທີແກ້ໄຂ: ບ່ອນທີ່ເປັນໄປໄດ້ / ໃຊ້ໄດ້, ໃຊ້ສະແຕນ. Stubs ເອົາຊະນະບັນຫາທີ່ມີການເຊື່ອມຕໍ່ຫຼືການປ່ຽນແປງຂອງລະບົບຂອງບຸກຄົນທີ 3. ດັ່ງນັ້ນ, ການກວດສອບແບບອັດຕະໂນມັດຈະບໍ່ເປັນອິດສະຫຼະຈາກຄວາມລົ້ມເຫລວໃດໆທີ່ຢູ່ເບື້ອງລຸ່ມ.

ການທົດສອບອັດຕະໂນມັດບໍ່ແມ່ນການທົດສອບ

ແຕ່ໂຊກບໍ່ດີ, ຫຼາຍໆຄົນຜິດພາດ“ ທົດສອບອັດຕະໂນມັດ” ກັບການທົດສອບ.

ເມື່ອພວກເຂົາມີເຄື່ອງມືໃນການທົດສອບໂດຍອັດຕະໂນມັດ, ພວກເຂົາຕ້ອງການ“ ທົດສອບທັງ ໝົດ ໂດຍອັດຕະໂນມັດ”. ພວກເຂົາຕ້ອງການ ກຳ ຈັດ 'ນັກທົດສອບຄູ່ມື' ທັງ ໝົດ.

ຄວາມຈິງແມ່ນວ່າການທົດສອບແມ່ນການອອກ ກຳ ລັງກາຍ ສຳ ຫຼວດ. ການທົດສອບຮຽກຮ້ອງໃຫ້ມີຄວາມຮູ້ກ່ຽວກັບໂດເມນ, ຄວາມຕັ້ງໃຈແລະຄວາມເຕັມໃຈທີ່ຈະຮຽນຮູ້ການສະ ໝັກ.

ການທົດສອບບໍ່ແມ່ນພຽງແຕ່ປະຕິບັດຂັ້ນຕອນການທົດສອບທີ່ໄດ້ ກຳ ນົດໄວ້ກ່ອນແລ້ວແລະປຽບທຽບຜົນໄດ້ຮັບຕົວຈິງກັບຜົນທີ່ຄາດໄວ້. ນີ້ແມ່ນວຽກຂອງການກວດສອບອັດຕະໂນມັດ.

ເພື່ອທົດສອບການສະ ໝັກ ຢ່າງຖືກຕ້ອງ, ຄວາມສະຫຼາດຂອງມະນຸດແມ່ນຕ້ອງການສະ ເໝີ ໄປ.

ວິທີແກ້ໄຂ: ເຂົ້າໃຈວ່າ ສຳ ລັບການຈັດສົ່ງໂຄງການທີ່ປະສົບຜົນ ສຳ ເລັດທ່ານຕ້ອງການທັງການທົດສອບແບບອັດຕະໂນມັດແລະແບບຄູ່ມື.

ອັນ ໜຶ່ງ ບໍ່ແມ່ນການທົດແທນຄົນອື່ນ; ປະກອບການກວດສອບແບບອັດຕະໂນມັດດ້ວຍການທົດສອບຄູ່ມື / ການ ສຳ ຫຼວດ.

ເວລາ ບຳ ລຸງແລະຄວາມພະຍາຍາມ

ທ່ານຕ້ອງຍອມຮັບຄວາມຈິງທີ່ວ່າການທົດສອບອັດຕະໂນມັດຕ້ອງການການ ບຳ ລຸງຮັກສາ. ໃນຂະນະທີ່ ຄຳ ຮ້ອງສະ ໝັກ ທີ່ຢູ່ພາຍໃຕ້ການທົດສອບພັດທະນາ, ການກວດສອບແບບອັດຕະໂນມັດຄວນກວດສອບ.

ການກວດສອບອັດຕະໂນມັດແມ່ນມີອາຍຸສັ້ນ. ຖ້າຫາກວ່າແພັກເກັດທີ່ປົກຄຸມບໍ່ໄດ້ຖືກເກັບຮັກສາໄວ້, ທ່ານຈະເລີ່ມເຫັນຄວາມລົ້ມເຫລວທຸກປະເພດ.

ບາງທີການກວດສອບບາງຢ່າງບໍ່ມີຄວາມກ່ຽວຂ້ອງອີກຕໍ່ໄປ. ຫຼືບາງທີການກວດກາບໍ່ແມ່ນການສະແດງຕົວຈິງຂອງການຈັດຕັ້ງປະຕິບັດ ໃໝ່.

ຄວາມລົ້ມເຫຼວເຫລົ່ານີ້ສາມາດສ້າງມົນລະພິດຕໍ່ຜົນຂອງການທົດສອບ.

ການກ້າວໄປສູ່ການທົດສອບອັດຕະໂນມັດບໍ່ແມ່ນຄວາມພະຍາຍາມຢ່າງດຽວ. ເພື່ອໃຫ້ໄດ້ຮັບປະໂຫຍດສູງສຸດຈາກການກວດສອບແບບອັດຕະໂນມັດ, ພວກເຂົາຕ້ອງໄດ້ເກັບຮັກສາໄວ້ໃຫ້ທັນສະ ໄໝ ແລະມີຄວາມກ່ຽວຂ້ອງ. ນີ້, ຮຽກຮ້ອງໃຫ້ມີເວລາ, ຄວາມພະຍາຍາມແລະຊັບພະຍາກອນຫຼາຍ.

ວິທີແກ້ໄຂ: ເພາະວ່າປັດໄຈການ ບຳ ລຸງຮັກສາແມ່ນກິດຈະ ກຳ ທີ່ ກຳ ລັງ ດຳ ເນີນຢູ່ຕໍ່ໄປ, ລົງທຶນເວລາໃນການອອກແບບກອບທີ່ດີ. ໃຊ້ໂມດູນທີ່ໃຊ້ ໃໝ່ ໄດ້, ແຍກການທົດສອບຈາກຂອບແລະໃຊ້ຫຼັກການອອກແບບທີ່ດີເພື່ອຫຼຸດຜ່ອນຄວາມພະຍາຍາມໃນການ ບຳ ລຸງຮັກສາ.

ຄຳ ຕິຊົມຊ້າ

ເມື່ອ ໜ້າ ທີ່ໃດ ໜຶ່ງ ພ້ອມທີ່ຈະທົດສອບ, ເວລາສ່ວນໃຫຍ່ມັນໄວທີ່ສຸດທີ່ຈະເຮັດການກວດສອບດ້ວຍຕົນເອງ.

ບັນຫາແມ່ນ, ການກວດສອບແບບອັດຕະໂນມັດສາມາດໃຊ້ເວລາເປັນເວລາດົນນານເພື່ອຂຽນຂື້ນກັບຄວາມສັບສົນຂອງການທົດສອບ. ສະນັ້ນ, ການເຮັດການກວດກາດ້ວຍຕົນເອງໃຫ້ ຄຳ ຄິດເຫັນທີ່ໄວກວ່າການຂຽນ, ແລ່ນແລະກວດເບິ່ງຜົນໄດ້ຮັບ.

ນອກຈາກນີ້, ໃນແງ່ຂອງການທົດສອບ UI ແລະລະດັບລະບົບ, ການກວດສອບແບບອັດຕະໂນມັດສາມາດໃຊ້ເວລາດົນນານເພື່ອເຮັດ ສຳ ເລັດແລະລາຍງານ. ເພາະສະນັ້ນ, ຖ້າມີຂໍ້ບົກພ່ອງແທ້, ພວກເຮົາອາດຈະບໍ່ຮູ້ຈົນກ່ວາການທົດສອບທັງ ໝົດ ໄດ້ ສຳ ເລັດ.

ວິທີແກ້ໄຂ: ພະຍາຍາມທົດລອງໃຊ້ແບບອັດຕະໂນມັດຄຽງຄູ່ກັບການພັດທະນາເພື່ອວ່າເມື່ອການພັດທະນາ ສຳ ເລັດທ່ານສາມາດທົດລອງໃຊ້ແບບອັດຕະໂນມັດທຽບກັບການເຮັດວຽກ ໃໝ່.

ພ້ອມກັນນີ້, ແຍກການກວດສອບແບບອັດຕະໂນມັດໄວ້ໃນຊອງຕ່າງກັນ.

ຊອງລະບົບຄວບຄຸມຄວັນຢາສູບຄວນຈະໄວທີ່ສຸດ. ການທົດສອບຄວນກວດສອບພຽງແຕ່ວ່າ ຄຳ ຮ້ອງສະ ໝັກ ສາມາດເລີ່ມຕົ້ນແລະເຂົ້າໃຊ້ໄດ້.

ຖັດໄປ, ທ່ານສາມາດມີຊຸດ regression ທີ່ມີປະໂຫຍດເຊິ່ງກວດສອບການເຮັດວຽກໃຫຍ່ໆ.

ຊອງລະບົບຄວບຄຸມອີກປະການຫນຶ່ງສາມາດປະກອບມີການທົດສອບທັງສິ້ນແລະສຸດທ້າຍ. ການກວດສອບເຫຼົ່ານີ້ສາມາດ ດຳ ເນີນການໄດ້ຕະຫຼອດຄືນ.

ຕົວຢ່າງຂອງການແລ່ນກາງຄືນແມ່ນການກວດສອບແບບອັດຕະໂນມັດຂ້າມຂອງຕົວທ່ອງເວັບ. ປົກກະຕິເຫຼົ່ານີ້ໃຊ້ເວລາດົນໃນການເຮັດວຽກໃນທຸກໆ browser.

ບໍ່ພົບແມງໄມ້ຫລາຍ

ຂໍ້ບົກພ່ອງສ່ວນໃຫຍ່ເບິ່ງຄືວ່າພົບໂດຍ 'ອຸບັດຕິເຫດ' ຫຼືໃນເວລາທີ່ ດຳ ເນີນການທົດລອງ ສຳ ຫຼວດ.

ນີ້ແມ່ນອາດຈະເປັນເພາະວ່າໃນແຕ່ລະກອງປະຊຸມ ສຳ ຫຼວດທົດລອງ, ພວກເຮົາສາມາດທົດສອບການສະ ໝັກ ໄດ້ດ້ວຍວິທີທີ່ແຕກຕ່າງກັນ.

ການກວດສອບການຄວບຄຸມໂດຍອັດຕະໂນມັດໃນອີກດ້ານ ໜຶ່ງ, ຕ້ອງເດີນຕາມເສັ້ນທາງໃດ ໜຶ່ງ. ບາງຄັ້ງມີຂໍ້ມູນການທົດສອບທີ່ ກຳ ນົດໄວ້ຄືກັນ. ນີ້ຊ່ວຍຫຼຸດຜ່ອນໂອກາດໃນການຊອກຫາຂໍ້ບົກພ່ອງ ໃໝ່ ໃນການ ນຳ ໃຊ້.

ນອກຈາກນີ້ ຈຳ ນວນຂອງແມງໄມ້ທີ່ ກຳ ລັງລະບາດຢູ່ເບິ່ງຄືວ່າມັນຕ່ ຳ ກວ່າຂໍ້ບົກພ່ອງທີ່ມີຄຸນລັກສະນະ ໃໝ່.

ວິທີແກ້ໄຂ: ພະຍາຍາມສ້າງແບບສຸ່ມໃນສະຖານະການແລະຂໍ້ມູນ. ການທົດລອງເສັ້ນທາງທີ່ແຕກຕ່າງກັນດ້ວຍຂໍ້ມູນທີ່ແຕກຕ່າງກັນໃນແຕ່ລະຄັ້ງສາມາດເປີດເຜີຍບັນຫາທີ່ອາດເກີດຂື້ນ.



ສະຫຼຸບ

ໃນບົດຂຽນນີ້, ພວກເຮົາໄດ້ເບິ່ງບາງຂໍ້ດີແລະຂໍ້ເສຍຂອງການທົດສອບອັດຕະໂນມັດ. ເມື່ອພວກເຮົາມີສ່ວນຮ່ວມໃນການທົດສອບອັດຕະໂນມັດ, ພວກເຮົາຄວນພິຈາລະນາຈຸດຕ່າງໆຂ້າງເທິງເພື່ອໃຫ້ໄດ້ຮັບຜົນປະໂຫຍດສູງສຸດ.