ມັນບໍ່ແມ່ນເຈົ້າ; ອັນໃຫຍ່ຫຼວງຂອງການຮັບປະກັນຄຸນນະພາບແມ່ນຄວາມບົກພ່ອງທ້ອງຖິ່ນ

ຊິ້ນໃຫຍ່ຂອງການເປັນ QA ແມ່ນການທ້ອງຖິ່ນທີ່ບົກພ່ອງ.

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

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍພື້ນຖານ

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

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

ສະຖາປັດຕະຍະກຳແອັບພລິເຄຊັນແມ່ນຫຍັງ?

ມັນເປັນວິທີທີ່ພາກສ່ວນຕ່າງໆຂອງລະບົບເຮັດວຽກຮ່ວມກັນ. ໃນແງ່ຂອງການປຽບທຽບ labyrinth ຂອງພວກເຮົາ, ມັນແມ່ນວິທີທີ່ພາກສ່ວນຫນຶ່ງເຊື່ອມຕໍ່ກັບອີກ, ເຊິ່ງ passageways ນໍາໄປສູ່ບ່ອນໃດ.

ຂ້ອຍຈໍາແນກສອງສະຖາປັດຕະຍະກໍາຕົ້ນຕໍ: client-server ແລະ backend.

• ສະຖາປັດຕະຍະກຳ Client-server ສະແດງໃຫ້ເຫັນພວກເຮົາວ່າລູກຄ້າ ແລະເຊີບເວີພົວພັນກັນແນວໃດ.
• ສະຖາປັດຕະຍະກໍາ Backend ກໍານົດວິທີການ backend ຈັດການກັບຄໍາຮ້ອງຂໍຂອງລູກຄ້າ.

ສອງສາມຄໍາກ່ຽວກັບສະຖາປັດຕະຍະກໍາລູກຄ້າ - ເຄື່ອງແມ່ຂ່າຍ

ໂດຍທົ່ວໄປແລ້ວມີສອງປະເພດ:

• ລູກຄ້າບາງໆ
• ລູກຄ້າຫນາ

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

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

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

ຕອນນີ້, ໃຫ້ພວກເຮົາຄົ້ນຫາສະຖາປັດຕະຍະກໍາ backend

ສອງ​ວິ​ທີ​ການ​ທົ່ວ​ໄປ​ແມ່ນ​:

• Monolithic
• ການບໍລິການຈຸລະພາກ

ເມື່ອເກືອບທຸກຢ່າງຖືກປຸງແຕ່ງຢູ່ໃນສະຖານທີ່ດຽວ, ມັນເປັນ monolith.

ຖ້າການຮ້ອງຂໍການປຸງແຕ່ງຖືກສົ່ງໄປຫາບໍລິການອື່ນໆໃນລະບົບ, ທ່ານອາດຈະຈັດການກັບສະຖາປັດຕະຍະກໍາ microservice.

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

ໃນກໍລະນີທີສອງ, ການບໍລິການຖືກແຍກອອກ, ແຕ່ລະຄົນມີ codebase ຂອງຕົນເອງ, ຊຶ່ງຫມາຍຄວາມວ່າການປ່ຽນແປງໃນການບໍລິການຫນຶ່ງມີຜົນກະທົບເລັກນ້ອຍຕໍ່ຄົນອື່ນ.

ໂຄງປະກອບການຈັດຕັ້ງ ແລະ ຂົງເຂດຄວາມຮັບຜິດຊອບ

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

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

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

ເອົາມັນທັງຫມົດຮ່ວມກັນ

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

ສະຖານະການ 1

ຮູບພາບນີ້: ພວກເຮົາກໍາລັງທົດສອບເວັບໄຊທ໌ສໍາລັບສະໂມສອນສົນທະນາ.

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

ດຽວນີ້, ພວກເຮົາຈະຄິດແນວໃດວ່າມັນມີຕົ້ນ ກຳ ເນີດມາຈາກໃສ? ໃຫ້ຜະຈົນໄພເລີ່ມຕົ້ນ!

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

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

ພວກເຮົາຊອກຫາການເຂົ້າແລະກວດເບິ່ງ: ພວກເຮົາໄດ້ຮັບຂໍ້ມູນຊັ້ນຮຽນຈາກຖານຂໍ້ມູນຫຼືຈາກບໍລິການອື່ນບໍ?

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

ຖ້າຂໍ້ມູນມາຈາກການບໍລິການອື່ນ, ພວກເຮົາສາມາດສົ່ງຂໍ້ບົກພ່ອງໃຫ້ພວກເຂົາ.

ຊົມເຊີຍ! ພວກເຮົາໄດ້ເອົາຊະນະ labyrinth ທໍາອິດຂອງພວກເຮົາ: ຂໍ້ບົກພ່ອງໄດ້ຖືກທ້ອງຖິ່ນແລະລາຍງານ.

ສະຖານະການ 2

ໃນປັດຈຸບັນຮູບພາບທີ່ພວກເຮົາກໍາລັງທົດສອບແບບຟອມລົງທະບຽນ.

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

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

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

• ເອກະສານທີ່ລ້າສະໄຫມໃນຫນ້າວຽກ
• ການປ່ຽນແປງທີ່ບໍ່ມີເອກະສານ
• ພິມຜິດ

ໃຫ້ກວດເບິ່ງຄໍາຮ້ອງຂໍຂອງລູກຄ້າ

ຖ້າພວກເຮົາມີເອກະສານ, ຂຽນດ້ວຍຕົນເອງຫຼືສ້າງຢູ່ໃນ Swagger ຫຼື OpenAPI, ໃຫ້ໃຊ້ມັນເພື່ອກວດສອບວ່າ:

• ພວກເຮົາກໍາລັງສົ່ງຕົວກໍານົດການທີ່ຈໍາເປັນທັງຫມົດ
• ຄ່າພາຣາມິເຕີມີປະເພດຂໍ້ມູນທີ່ຖືກຕ້ອງ (ເຊັ່ນ: ຄ່າຕົວເລກສຳລັບພາຣາມິເຕີ int)

ພວກເຮົາສາມາດກວດສອບການຮ້ອງຂໍໄດ້ແນວໃດ?

ເຖິງແມ່ນວ່າພວກເຮົາບໍ່ມີເອກະສານ, ພວກເຮົາສາມາດກວດສອບໄດ້:

• ການປະຕິບັດຕາມ syntax (ເຊັ່ນ: ຖ້າຄໍາຮ້ອງຂໍຖືກສົ່ງໃນຮູບແບບ JSON, ມັນຄວນຈະປະຕິບັດຕາມ JSON syntax)
• Typos ໃນຊື່ພາລາມິເຕີ (ເຊັ່ນ: "ເງິນ" ແທນ "ເງິນ", "doby" ແທນ "ຮ່າງກາຍ")
• ຕົວ​ອັກ​ສອນ Cyrillic ໃນ​ບັນ​ດາ​ຕົວ​ອັກ​ສອນ​ລະ​ຕິນ (ເຊັ່ນ​: “ຊື່” ຂຽນ​ດ້ວຍ Cyrillic “e”)

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

ການວິເຄາະບັນທຶກ

ນີ້, ສອງສະຖານະການເປັນໄປໄດ້:

• ຂໍ້ຜິດພາດຖືກບັນທຶກໃນລະຫວ່າງການປະມວນຜົນການຮ້ອງຂໍ
• ບໍ່ມີຂໍ້ຜິດພາດຖືກບັນທຶກ, ແຕ່ການຮ້ອງຂໍຖືກບັນທຶກ

ໃນກໍລະນີສຸດທ້າຍ, ພວກເຮົາຈະຕ້ອງສືບຕໍ່ການເດີນທາງຂອງພວກເຮົາຜ່ານ microservice labyrinth ແລະຊອກຫາສະຖານທີ່ທີ່ຄໍາຮ້ອງຂໍຂອງພວກເຮົາຖືກດໍາເນີນການ.

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

• ຄໍາຮ້ອງຂໍ backend
• ບັນທຶກຄວາມຜິດພາດ
• ແນະນຳການແກ້ໄຂ

ສະຫຼຸບ

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

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