ຊິ້ນໃຫຍ່ຂອງການເປັນ 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 - ນັກພັດທະນາ.
