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

ພາກ​ທໍາ​ອິດ - ທີ່ນີ້.

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

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

1. ການ​ຟື້ນ​ຟູ​ການ​ທົດ​ສອບ​ຫນ່ວຍ​ບໍ​ລິ​ການ​ເກົ່າ​. ການຟື້ນຕົວຫມາຍຄວາມວ່າການປັບຕົວທົດສອບກັບສະຖານະທີ່ມີຢູ່ແລ້ວຂອງລະບົບຄວາມສັດຊື່ແລະການປັບຕົວການທົດສອບກັບມາດຕະຖານ utPLSQL.
2. ການແກ້ໄຂບັນຫາທີ່ມີຄວາມເຂົ້າໃຈກ່ຽວກັບສິ່ງທີ່ແນ່ນອນ, ວິທີການແລະຂະບວນການໃດທີ່ກວມເອົາດ້ວຍ autotests. ເຈົ້າຕ້ອງເກັບຂໍ້ມູນນີ້ໄວ້ໃນຫົວຂອງເຈົ້າ, ຫຼືເອົາບົດສະຫຼຸບໂດຍອີງໃສ່ລະຫັດ autotest ໂດຍກົງ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຕັດສິນໃຈສ້າງລາຍການ. ພວກເຮົາໄດ້ມອບຫມາຍລະຫັດ mnemonic ທີ່ເປັນເອກະລັກໃຫ້ກັບແຕ່ລະ autotest, ສ້າງຄໍາອະທິບາຍແລະບັນທຶກການຕັ້ງຄ່າ (ຕົວຢ່າງ, ພາຍໃຕ້ເງື່ອນໄຂໃດທີ່ມັນຄວນຈະຖືກເປີດຕົວ, ຫຼືສິ່ງທີ່ຄວນເກີດຂຶ້ນຖ້າການເປີດຕົວການທົດສອບລົ້ມເຫລວ). ໂດຍພື້ນຖານແລ້ວ, ພວກເຮົາປະກອບຂໍ້ມູນ metadata ກ່ຽວກັບ autotests ແລະວາງ metadata ນັ້ນເຂົ້າໄປໃນຕາຕະລາງ schema utPLSQL ມາດຕະຖານ.
3. ການກໍານົດຍຸດທະສາດການຂະຫຍາຍຕົວ, i.e. ການ​ຄັດ​ເລືອກ​ຫນ້າ​ທີ່​ແມ່ນ​ຂຶ້ນ​ກັບ​ການ​ຢັ້ງ​ຢືນ​ໂດຍ​ການ​ທົດ​ສອບ​ອັດ​ຕະ​ໂນ​ມັດ​. ພວກເຮົາໄດ້ຕັດສິນໃຈເອົາໃຈໃສ່ສາມຢ່າງ: ການປັບປຸງລະບົບໃຫມ່, ເຫດການການຜະລິດ, ແລະຂະບວນການລະບົບທີ່ສໍາຄັນ. ດັ່ງນັ້ນ, ພວກເຮົາກໍາລັງພັດທະນາໃນຂະຫນານກັບການປ່ອຍ, ຮັບປະກັນຄຸນນະພາບທີ່ສູງຂຶ້ນ, ພ້ອມກັນຂະຫຍາຍຂອບເຂດຂອງການຖົດຖອຍແລະຮັບປະກັນຄວາມຫນ້າເຊື່ອຖືຂອງລະບົບໃນສະຖານທີ່ສໍາຄັນ. ຄໍຂວດທໍາອິດແມ່ນຂະບວນການແຈກຢາຍສ່ວນຫຼຸດ ແລະໂບນັດໃນເຊັກ.
4. ຕາມທໍາມະຊາດ, ພວກເຮົາເລີ່ມພັດທະນາການທົດສອບອັດຕະໂນມັດໃຫມ່. ຫນຶ່ງໃນວຽກງານການປ່ອຍຕົວທໍາອິດແມ່ນເພື່ອປະເມີນການປະຕິບັດຂອງຕົວຢ່າງທີ່ກໍານົດໄວ້ລ່ວງຫນ້າຂອງລະບົບຄວາມສັດຊື່. ໂຄງ​ການ​ຂອງ​ພວກ​ເຮົາ​ມີ​ຕັນ​ຂອງ​ການ​ສອບ​ຖາມ SQL ການ​ສ້ອມ​ແປງ​ເຂັ້ມ​ແຂງ​ທີ່​ເລືອກ​ລູກ​ຄ້າ​ໂດຍ​ອີງ​ໃສ່​ເງື່ອນ​ໄຂ​. ຕົວຢ່າງ, ເອົາລາຍຊື່ລູກຄ້າທັງໝົດທີ່ການຊື້ຄັ້ງສຸດທ້າຍຢູ່ໃນເມືອງສະເພາະ, ຫຼືລາຍຊື່ລູກຄ້າທີ່ຈຳນວນການຊື້ສະເລ່ຍແມ່ນສູງກວ່າມູນຄ່າທີ່ແນ່ນອນ. ມີການຂຽນ autotests, ພວກເຮົາໄດ້ກວດເບິ່ງຕົວຢ່າງທີ່ກໍານົດໄວ້ກ່ອນ, ບັນທຶກຕົວກໍານົດການປະຕິບັດມາດຕະຖານ, ແລະນອກຈາກນັ້ນພວກເຮົາມີການທົດສອບການໂຫຼດ.
5. ການເຮັດວຽກກັບ autotests ຄວນຈະສະດວກ. ສອງການປະຕິບັດທົ່ວໄປທີ່ສຸດແມ່ນແລ່ນ autotests ແລະການສ້າງຂໍ້ມູນການທົດສອບ. ນີ້ແມ່ນວິທີການສອງໂມດູນເສີມປາກົດຢູ່ໃນລະບົບຂອງພວກເຮົາ: ໂມດູນເປີດຕົວແລະໂມດູນການຜະລິດຂໍ້ມູນ.

   launcher ແມ່ນເປັນຕົວແທນເປັນຂັ້ນຕອນທົ່ວໄປທີ່ມີຕົວກໍານົດການປ້ອນຂໍ້ຄວາມຫນຶ່ງ. ເປັນພາລາມິເຕີ, ທ່ານສາມາດຜ່ານລະຫັດ mnemonic autotest, ຊື່ຊຸດ, ຊື່ການທົດສອບ, ການຕັ້ງຄ່າ autotest, ຫຼືຄໍາທີ່ສະຫງວນໄວ້. ຂັ້ນຕອນເລືອກແລະດໍາເນີນການ autotests ທັງຫມົດທີ່ຕອບສະຫນອງເງື່ອນໄຂ.

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

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

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

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

7. ໂຄງການທີ່ມີການທົດສອບອັດຕະໂນມັດຄວນຈະສາມາດຖືກນໍາໄປໃຊ້ຢູ່ບ່ອນຕ່າງໆ. ໃນຕອນເລີ່ມຕົ້ນຂອງການເດີນທາງຂອງພວກເຮົາ, ມີຄວາມພະຍາຍາມທີ່ຈະຂຽນໄຟລ໌ batch ຂອງພວກເຮົາເອງ, ແຕ່ວ່າມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າການຕິດຕັ້ງອັດຕະໂນມັດທີ່ຂຽນດ້ວຍຕົນເອງແມ່ນຫນ້າຢ້ານກົວທີ່ສົມບູນ, ແລະພວກເຮົາໄດ້ຫັນໄປສູ່ການແກ້ໄຂອຸດສາຫະກໍາ. ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າໂຄງການປະກອບມີລະຫັດໂດຍກົງຫຼາຍ (ທໍາອິດພວກເຮົາເກັບລະຫັດ autotest) ແລະຂໍ້ມູນຫນ້ອຍຫຼາຍ (ຂໍ້ມູນຕົ້ນຕໍແມ່ນ metadata ກ່ຽວກັບ autotests), ການປະຕິບັດໃນໂຄງການ Liquibase ໄດ້ກາຍເປັນງ່າຍດາຍຫຼາຍ.

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

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

ດັ່ງນັ້ນ, ໃຫ້ເວົ້າກ່ຽວກັບຜົນໄດ້ຮັບຂອງການນໍາໃຊ້ລະບົບການທົດສອບຫນ່ວຍຂອງພວກເຮົາ.

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

ມີຫຍັງຕໍ່ໄປ

ໃຫ້ເວົ້າກ່ຽວກັບແຜນການພັດທະນາສໍາລັບໂຄງການການທົດສອບອັດຕະໂນມັດ.

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

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

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

1. ໃນປັດຈຸບັນ, ການຈັດການ autotest ແມ່ນປະຕິບັດຢູ່ໃນລະດັບ DBMS, i.e. ຄວາມຮູ້ກ່ຽວກັບ PL/SQL ແມ່ນຕ້ອງການສໍາລັບການເຮັດວຽກທີ່ປະສົບຜົນສໍາເລັດ. ຖ້າຈໍາເປັນ, ການຄຸ້ມຄອງລະບົບ (ຕົວຢ່າງ, ການເປີດຕົວຫຼືການສ້າງ metadata), ທ່ານສາມາດສ້າງບາງປະເພດຂອງກະດານ admin ໂດຍໃຊ້ Jenkins ຫຼືບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນ.
2. ທຸກໆຄົນມັກຕົວຊີ້ວັດດ້ານປະລິມານແລະຄຸນນະພາບ. ສໍາລັບການທົດສອບອັດຕະໂນມັດ, ຕົວຊີ້ວັດທົ່ວໄປດັ່ງກ່າວແມ່ນ Code Coverage ຫຼື metric ການຄຸ້ມຄອງລະຫັດ. ການນໍາໃຊ້ຕົວຊີ້ວັດນີ້, ພວກເຮົາສາມາດກໍານົດອັດຕາສ່ວນຂອງລະຫັດຂອງລະບົບຂອງພວກເຮົາພາຍໃຕ້ການທົດສອບແມ່ນກວມເອົາໂດຍ autotests. ໂດຍເລີ່ມຈາກເວີຊັ່ນ 12.2, Oracle ໃຫ້ຄວາມສາມາດໃນການຄຳນວນຄ່າວັດແທກນີ້ ແລະສະເໜີໃຫ້ໃຊ້ແພັກເກດ DBMS_PLSQL_CODE_COVERAGE ມາດຕະຖານ.

   ລະບົບ autotest ຂອງພວກເຮົາມີອາຍຸຫຼາຍກວ່າຫນຶ່ງປີແລະບາງທີຕອນນີ້ແມ່ນເວລາທີ່ຈະປະເມີນການຄຸ້ມຄອງຂອງພວກເຮົາ. ໃນໂຄງການສຸດທ້າຍຂອງຂ້ອຍ (ບໍ່ແມ່ນໂຄງການ Sportmaster) ນີ້ແມ່ນສິ່ງທີ່ເກີດຂຶ້ນ. ຫນຶ່ງປີຫຼັງຈາກເຮັດວຽກກ່ຽວກັບ autotests, ການຄຸ້ມຄອງກໍານົດວຽກງານຂອງການປະເມີນອັດຕາສ່ວນຂອງລະຫັດທີ່ພວກເຮົາກວມເອົາ. ມີການຄຸ້ມຄອງຫຼາຍກ່ວາ 1%, ການຄຸ້ມຄອງຈະມີຄວາມສຸກ. ພວກເຮົາ, ນັກພັດທະນາ, ຄາດວ່າຜົນໄດ້ຮັບປະມານ 10%. ພວກເຮົາຕິດຕັ້ງການຄຸ້ມຄອງລະຫັດ, ວັດແທກມັນ, ແລະໄດ້ຮັບ 20%. ເພື່ອສະເຫຼີມສະຫຼອງ, ພວກເຮົາໄດ້ໄປຮັບລາງວັນ, ແຕ່ວິທີການທີ່ພວກເຮົາໄປເພື່ອໃຫ້ໄດ້ຮັບມັນແລະບ່ອນທີ່ພວກເຮົາໄປຕໍ່ມາແມ່ນເລື່ອງທີ່ແຕກຕ່າງກັນຫມົດ.

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

ການຄົ້ນພົບ

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

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

ຂຽນຄໍາເຫັນຖ້າມີຈຸດທີ່ຄວນເນັ້ນໃສ່ໃນອະນາຄົດ, ຫຼືຄໍາຖາມທີ່ຮຽກຮ້ອງໃຫ້ມີການເປີດເຜີຍ.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ພວກເຮົາຈະຂຽນຕື່ມອີກກ່ຽວກັບເລື່ອງນີ້ບໍ?

• ແມ່ນແລ້ວແນ່ນອນ

• ບໍ່​ຂອບ​ໃຈ

12 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 4 ຜູ້ໃຊ້ງົດ.

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