ການທົດສອບຫນ່ວຍງານໃນ DBMS - ວິທີການທີ່ພວກເຮົາເຮັດໃນ Sportmaster, ສ່ວນຫນຶ່ງ

Hey Habr!

ຂ້ອຍຊື່ Maxim Ponomarenko ແລະຂ້ອຍເປັນນັກພັດທະນາຢູ່ Sportmaster. ຂ້ອຍມີປະສົບການ 10 ປີໃນຂົງເຂດ IT. ລາວໄດ້ເລີ່ມຕົ້ນການເຮັດວຽກຂອງລາວໃນການທົດສອບຄູ່ມື, ຫຼັງຈາກນັ້ນປ່ຽນໄປສູ່ການພັດທະນາຖານຂໍ້ມູນ. ສໍາລັບ 4 ປີທີ່ຜ່ານມາ, ການສະສົມຄວາມຮູ້ທີ່ໄດ້ຮັບໃນການທົດສອບແລະການພັດທະນາ, ຂ້າພະເຈົ້າໄດ້ເຮັດການທົດສອບອັດຕະໂນມັດໃນລະດັບ DBMS.

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

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

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

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

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

ການທົດສອບຄວາມສັດຊື່

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

ຖ້າບໍລິສັດຂອງເຈົ້າໃຫຍ່ພໍ, ລະບົບຄວາມສັດຊື່ຂອງເຈົ້າຈະມີຄຸນສົມບັດມາດຕະຖານສາມຢ່າງ:

• ລະບົບຂອງທ່ານຈະຖືກໂຫຼດສູງ
• ລະບົບຂອງທ່ານຈະປະກອບດ້ວຍຂະບວນການຄອມພິວເຕີທີ່ຊັບຊ້ອນ
• ລະບົບຂອງທ່ານຈະຖືກປັບປຸງຢ່າງຈິງຈັງ.

ໃຫ້ເຂົ້າໄປໃນຄໍາສັ່ງ ... ໃນຈໍານວນທັງຫມົດ, ຖ້າພວກເຮົາພິຈາລະນາຍີ່ຫໍ້ Sportmaster ທັງຫມົດ, ຫຼັງຈາກນັ້ນ, ພວກເຮົາມີຫຼາຍກວ່າ 1000 ຮ້ານໃນລັດເຊຍ, Ukraine, ຈີນ, Kazakhstan ແລະເບລາຣູດ. ປະມານ 300 ການຊື້ແມ່ນເຮັດຢູ່ໃນຮ້ານເຫຼົ່ານີ້ທຸກໆມື້. ນັ້ນແມ່ນ, ທຸກໆການກວດສອບ 000-3 ວິນາທີເຂົ້າໄປໃນລະບົບຂອງພວກເຮົາ. ຕາມທໍາມະຊາດ, ລະບົບຄວາມສັດຊື່ຂອງພວກເຮົາແມ່ນມີການໂຫຼດສູງ. ແລະນັບຕັ້ງແຕ່ມັນຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນ, ພວກເຮົາຕ້ອງສະຫນອງມາດຕະຖານສູງສຸດຂອງຄຸນນະພາບຂອງມັນ, ເພາະວ່າຄວາມຜິດພາດໃດໆໃນຊອບແວຫມາຍເຖິງການສູນເສຍເງິນອັນໃຫຍ່ຫຼວງ, ຊື່ສຽງແລະການສູນເສຍອື່ນໆ.

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

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

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

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

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

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

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

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

utPLSQL ມາຊ່ວຍ

ເຈົ້າຮູ້ຫຍັງກ່ຽວກັບ Stephen Feuerstein ບໍ?

ນີ້ແມ່ນຄົນສະຫຼາດທີ່ອຸທິດສ່ວນອັນຍາວນານຂອງການເຮັດວຽກຂອງລາວເພື່ອເຮັດວຽກກັບ Oracle ແລະ PL / SQL, ແລະໄດ້ຂຽນວຽກງານຈໍານວນຫລາຍກ່ຽວກັບຫົວຂໍ້ນີ້. ຫນຶ່ງໃນປື້ມທີ່ມີຊື່ສຽງຂອງລາວມີຊື່ວ່າ: "Oracle PL / SQL. ສໍາລັບຜູ້ຊ່ຽວຊານ." ມັນແມ່ນ Stephen ຜູ້ທີ່ພັດທະນາການແກ້ໄຂ utPLSQL, ຫຼື, ຕາມທີ່ມັນຢືນຢູ່, ກອບການທົດສອບຫນ່ວຍງານສໍາລັບ Oracle PL / SQL. ການແກ້ໄຂ utPLSQL ໄດ້ຖືກສ້າງຂື້ນໃນປີ 2016, ແຕ່ມັນຍັງສືບຕໍ່ເຮັດວຽກຢ່າງຫ້າວຫັນແລະຮຸ່ນໃຫມ່ຖືກປ່ອຍອອກມາ. ໃນເວລາລາຍງານ, ສະບັບຫລ້າສຸດແມ່ນວັນທີ 24 ມີນາ 2019.
ມັນ​ແມ່ນ​ຫຍັງ. ນີ້ແມ່ນໂຄງການແຫຼ່ງເປີດແຍກຕ່າງຫາກ. ມັນມີນໍ້າຫນັກສອງສາມເມກາໄບ, ລວມທັງຕົວຢ່າງແລະເອກະສານ. ທາງດ້ານຮ່າງກາຍ, ມັນເປັນ schema ແຍກຕ່າງຫາກໃນຖານຂໍ້ມູນ ORACLE ທີ່ມີຊຸດຂອງຊຸດແລະຕາຕະລາງສໍາລັບການຈັດຕັ້ງການທົດສອບຫນ່ວຍ. ການຕິດຕັ້ງໃຊ້ເວລາສອງສາມວິນາທີ. ລັກສະນະທີ່ໂດດເດັ່ນຂອງ utPLSQL ແມ່ນຄວາມສະດວກໃນການນໍາໃຊ້ຂອງມັນ.
ໃນທົ່ວໂລກ, utPLSQL ແມ່ນກົນໄກສໍາລັບການທົດສອບຫນ່ວຍງານ, ບ່ອນທີ່ການທົດສອບຫນ່ວຍງານຖືກເຂົ້າໃຈວ່າເປັນຂັ້ນຕອນ Oracle batch ທໍາມະດາ, ອົງການຈັດຕັ້ງທີ່ປະຕິບັດຕາມກົດລະບຽບບາງຢ່າງ. ນອກເຫນືອຈາກການເປີດຕົວ, utPLSQL ເກັບຮັກສາບັນທຶກຂອງການທົດສອບທັງຫມົດຂອງທ່ານ, ແລະຍັງມີລະບົບການລາຍງານພາຍໃນ.

ຂໍໃຫ້ເບິ່ງຕົວຢ່າງຂອງລະຫັດການທົດສອບຫນ່ວຍງານເບິ່ງຄືວ່າ, ປະຕິບັດໂດຍໃຊ້ເຕັກນິກນີ້.

ດັ່ງນັ້ນ, ຫນ້າຈໍສະແດງລະຫັດສໍາລັບຂໍ້ກໍານົດຂອງຊຸດປົກກະຕິທີ່ມີການທົດສອບຫນ່ວຍ. ຂໍ້ກໍານົດບັງຄັບແມ່ນຫຍັງ? ແພັກເກັດຕ້ອງຖືກນຳໜ້າດ້ວຍ "utp_". ຂັ້ນຕອນທັງໝົດທີ່ມີການທົດສອບຕ້ອງມີຄຳນຳໜ້າອັນດຽວກັນ. ຊຸດຕ້ອງມີສອງຂັ້ນຕອນມາດຕະຖານ: "utp_setup" ແລະ "utp_teardown". ຂັ້ນຕອນທໍາອິດແມ່ນເອີ້ນວ່າໂດຍການເລີ່ມຕົ້ນການທົດສອບແຕ່ລະຫນ່ວຍ, ທີສອງ - ຫຼັງຈາກເປີດຕົວ.

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

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

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

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

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

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

6 ກົດລະບຽບຂອງ autotests

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

1. ການທົດສອບອັດຕະໂນມັດຕ້ອງມີປະສິດທິພາບແລະຕ້ອງເປັນປະໂຫຍດ. ພວກເຮົາມີນັກພັດທະນາທີ່ປະເສີດ, ຜູ້ທີ່ແນ່ນອນຕ້ອງໄດ້ຮັບການກ່າວເຖິງ, ເພາະວ່າພວກເຂົາບາງຄົນອາດຈະເຫັນບົດລາຍງານນີ້, ແລະພວກເຂົາຂຽນລະຫັດທີ່ປະເສີດ. ແຕ່ເຖິງແມ່ນວ່າລະຫັດທີ່ປະເສີດຂອງພວກເຂົາບໍ່ສົມບູນແບບແລະມີ, ມີ, ແລະຈະສືບຕໍ່ມີຂໍ້ຜິດພາດ. ການທົດສອບອັດຕະໂນມັດແມ່ນຕ້ອງການເພື່ອຊອກຫາຂໍ້ຜິດພາດເຫຼົ່ານີ້. ຖ້ານີ້ບໍ່ແມ່ນກໍລະນີ, ຫຼັງຈາກນັ້ນ, ພວກເຮົາກໍາລັງຂຽນ autotest ທີ່ບໍ່ດີ, ຫຼືພວກເຮົາໄດ້ມາຮອດພື້ນທີ່ຕາຍ, ໃນຫຼັກການ, ບໍ່ໄດ້ຖືກພັດທະນາ. ໃນທັງສອງກໍລະນີ, ພວກເຮົາກໍາລັງເຮັດບາງສິ່ງບາງຢ່າງທີ່ຜິດພາດ, ແລະວິທີການຂອງພວກເຮົາພຽງແຕ່ບໍ່ມີຄວາມຫມາຍ.
2. ການທົດສອບອັດຕະໂນມັດຄວນຖືກນໍາໃຊ້. ມັນບໍ່ມີຄວາມຫມາຍທີ່ຈະໃຊ້ເວລາແລະຄວາມພະຍາຍາມຫຼາຍໃນການຂຽນຜະລິດຕະພັນຊອບແວ, ເອົາມັນໄວ້ໃນບ່ອນເກັບມ້ຽນແລະລືມມັນ. ການທົດສອບຄວນຈະດໍາເນີນການ, ແລະດໍາເນີນການເປັນປົກກະຕິເທົ່າທີ່ເປັນໄປໄດ້.
3. ການທົດສອບອັດຕະໂນມັດຄວນເຮັດວຽກຢ່າງຫມັ້ນຄົງ. ໂດຍບໍ່ຄໍານຶງເຖິງເວລາຂອງມື້, ການເປີດຕົວແລະການຕັ້ງຄ່າລະບົບອື່ນໆ, ການທົດສອບຄວນຈະນໍາໄປສູ່ຜົນໄດ້ຮັບດຽວກັນ. ຕາມກົດລະບຽບ, ນີ້ແມ່ນຮັບປະກັນໂດຍຄວາມຈິງທີ່ວ່າ autotests ເຮັດວຽກກັບຂໍ້ມູນການທົດສອບພິເສດທີ່ມີການຕັ້ງຄ່າລະບົບຄົງທີ່.
4. ການທົດສອບອັດຕະໂນມັດຄວນເຮັດວຽກຢູ່ໃນຄວາມໄວທີ່ຍອມຮັບໄດ້ສໍາລັບໂຄງການຂອງທ່ານ. ເວລານີ້ຖືກກໍານົດເປັນສ່ວນບຸກຄົນສໍາລັບແຕ່ລະລະບົບ. ບາງຄົນສາມາດເຮັດວຽກໄດ້ຫມົດມື້, ໃນຂະນະທີ່ຄົນອື່ນເຫັນວ່າມັນສໍາຄັນທີ່ຈະເຮັດມັນໃນວິນາທີ. ຂ້າພະເຈົ້າຈະບອກທ່ານເລັກນ້ອຍຕໍ່ມາວ່າມາດຕະຖານຄວາມໄວທີ່ພວກເຮົາບັນລຸໄດ້ໃນໂຄງການຂອງພວກເຮົາ.
5. ການພັດທະນາ Autotest ຄວນມີຄວາມຍືດຫຍຸ່ນ. ມັນບໍ່ຄວນປະຕິເສດທີ່ຈະທົດສອບການທໍາງານໃດໆພຽງແຕ່ຍ້ອນວ່າພວກເຮົາບໍ່ໄດ້ເຮັດມັນກ່ອນຫຼືດ້ວຍເຫດຜົນອື່ນໆ. utPLSQL ບໍ່ໄດ້ວາງຂໍ້ຈໍາກັດໃດໆກ່ຽວກັບການພັດທະນາ, ແລະ Oracle, ໃນຫຼັກການ, ຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດໄດ້ຫຼາຍຢ່າງ. ບັນຫາສ່ວນໃຫຍ່ມີທາງອອກ, ມັນເປັນພຽງແຕ່ເວລາແລະຄວາມພະຍາຍາມ.
6. ຄວາມສາມາດໃນການນຳໃຊ້. ພວກເຮົາມີຈຸດຢືນຫຼາຍບ່ອນທີ່ພວກເຮົາຈໍາເປັນຕ້ອງດໍາເນີນການທົດສອບ. ໃນແຕ່ລະບ່ອນຕັ້ງ, ການຖິ້ມຂໍ້ມູນສາມາດຖືກປັບປຸງໄດ້ທຸກເວລາ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະຕ້ອງດໍາເນີນໂຄງການທີ່ມີການທົດສອບອັດຕະໂນມັດໃນແບບທີ່ເຈົ້າສາມາດປະຕິບັດການຕິດຕັ້ງເຕັມຫຼືບາງສ່ວນຂອງມັນໂດຍບໍ່ເຈັບປວດ.

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

ແຫຼ່ງຂໍ້ມູນ: www.habr.com