ສະບັບທີ່ບໍ່ຫນ້າເຊື່ອຖືຂອງການທົດສອບອີເມລ໌ແມ່ນສັ້ນ: ສ້າງທີ່ຢູ່, ນອນຫ້າວິນາທີ, ອ່ານຂໍ້ຄວາມທໍາອິດ, ແລະຫວັງວ່າມັນເປັນຂອງໄລຍະນີ້.
ສະບັບທີ່ເຊື່ອຖືໄດ້ແມ່ນຍັງງ່າຍດາຍ, ແຕ່ມັນປະຕິບັດການຈັດສົ່ງເປັນ asynchronous. ມັນສ້າງທີ່ຢູ່ທີ່ເປັນເອກະລັກ, ບັນທຶກເວລາເລີ່ມຕົ້ນ, ການສໍາຫຼວດພາຍໃນກໍານົດເວລາ, ກົງກັບຂໍ້ຄວາມທີ່ຕັ້ງໄວ້, ກວດສອບການດໍາເນີນການຜະລິດຕະພັນ, ແລະລາຍງານສະພາບການທີ່ພຽງພໍໃນເວລາທີ່ບາງສິ່ງບາງຢ່າງລົ້ມເຫລວ.
ຮັກສາລະຫັດ API ອອກຈາກ URL
ສົ່ງລະຫັດ GPTMail ໃນສ່ວນຫົວ X-API-Key. ຢ່າວາງມັນໄວ້ໃນຕົວກໍານົດການສອບຖາມ ?api_key=. URLs ຖືກເກັບໄວ້ເປັນປົກກະຕິໃນປະຫວັດຂອງຕົວທ່ອງເວັບ, ບັນທຶກການເຂົ້າເຖິງ, ລະບົບການຕິດຕາມ, ແລະຂໍ້ມູນຜູ້ອ້າງອີງ.
X-API-Key: YOUR_API_KEYເກັບຮັກສາກະແຈໄວ້ໃນຕົວຈັດການລັບ CI ຂອງທ່ານແລະປິດບັງມັນໄວ້ໃນບັນທຶກ. ກະແຈປະຈໍາວັນສາທາລະນະແມ່ນສະດວກສໍາລັບການຂຸດຄົ້ນ; ຊຸດອັດຕະໂນມັດທີ່ຄວບຄຸມຄວນໃຊ້ກະແຈທີ່ມີໂຄຕ້າ ແລະໃຊ້ທ່ານສາມາດຕິດຕາມໄດ້.
ຈຸດສິ້ນສຸດປັດຈຸບັນ ແລະຕົວຢ່າງການຕອບສະໜອງແມ່ນຮັກສາໄວ້ໃນໜ້າ GPTMail API.
ຫນຶ່ງທີ່ຢູ່ຕໍ່ການແລ່ນ
ສ້າງທີ່ຢູ່ໃຫມ່ສໍາລັບທຸກໆການທົດສອບທີ່ສາມາດປະຕິບັດໄດ້ຢ່າງເປັນເອກະລາດ. ຫ້າມຮັບຄວາມຖືກຕ້ອງຈາກກ່ອງຈົດໝາຍທີ່ແບ່ງປັນໂດຍຊຸດທົດສອບທັງໝົດ.
ບັນທຶກທີ່ຢູ່, ID ສະຖານະການ, ສະພາບແວດລ້ອມ, ແລະເວລາເລີ່ມຕົ້ນການທົດສອບ. ຄຸນຄ່າເຫຼົ່ານີ້ຊ່ວຍໃຫ້ທ່ານປະຕິເສດຂໍ້ຄວາມທີ່ຄົງຄ້າງ ແລະວິນິໄສການຂັດກັນໂດຍບໍ່ມີການບັນທຶກຄວາມລັບຂອງຂໍ້ຄວາມ.
ແບບສຳຫຼວດຕໍ່ກັບເສັ້ນຕາຍ, ບໍ່ແມ່ນການນອນຄົງທີ່
ເວລາສົ່ງອີເມລ໌ແຕກຕ່າງກັນ. ການນອນທີ່ຄົງທີ່ຫ້າວິນາທີແມ່ນເປັນທັງສິ່ງເສດເຫຼືອໃນເວລາທີ່ການຈັດສົ່ງແມ່ນໄວ ແລະເປັນເກັດໆເມື່ອຊ້າ.
ໃຊ້ loop ຜູກມັດ:
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)ເສັ້ນຕາຍເປັນຂອງສັນຍາການທົດສອບ. ຂັ້ນຕອນການຕັ້ງລະຫັດຜ່ານໃໝ່ອາດຈະຕ້ອງການຂີດຈຳກັດທີ່ແຕກຕ່າງຈາກການເບິ່ງຕົວຢ່າງຈົດໝາຍຂ່າວເປັນຊຸດ. ຮັກສາຂອບເຂດຈໍາກັດຢ່າງຈະແຈ້ງເພື່ອໃຫ້ການເພິ່ງພາອາໄສທີ່ຊ້າໆບໍ່ໄດ້ຂະຫຍາຍວຽກ CI ທັງຫມົດຢ່າງງຽບໆ.
ກົງກັນຢ່າງແນ່ນອນ
“ຂໍ້ຄວາມທຳອິດໃນກ່ອງຈົດໝາຍ” ບໍ່ແມ່ນຕົວເລືອກທີ່ເປັນປະໂຫຍດ. ຈັບຄູ່ສັນຍານຫຼາຍອັນ:
- ຜູ້ຮັບເທົ່າກັບທີ່ຢູ່ທີ່ສ້າງຂຶ້ນສໍາລັບການແລ່ນນີ້;
- ເວລາສ້າງແມ່ນຊ້າກວ່າເວລາກະຕຸ້ນ;
- ຜູ້ສົ່ງຂຶ້ນກັບການບໍລິການທີ່ຄາດໄວ້;
- ຫົວຂໍ້ຫຼືປະເພດຂໍ້ຄວາມກົງກັບກະແສ;
- ID ຂໍ້ຄວາມຍັງບໍ່ໄດ້ຖືກບໍລິໂພກແລ້ວ.
ເມື່ອຜູ້ສົ່ງສາມາດອອກລະຫັດຫຼາຍ, ເລືອກຂໍ້ຄວາມທີ່ກົງກັນໃຫມ່ທີ່ສຸດ. ຮັກສາ ID ຂອງມັນໄວ້ໃນຜົນການທົດສອບເພື່ອໃຫ້ການລອງຄັ້ງໃໝ່ບໍ່ສາມາດໃຊ້ມັນຄືນໃໝ່ໄດ້ໂດຍບັງເອີນ.
ອ່ານພຽງແຕ່ຫຼັງຈາກການແຂ່ງຂັນລາຍການ
ລາຍຊື່ກ່ອງຈົດໝາຍຄວນເປັນຂັ້ນຕອນການຄົ້ນພົບລາຄາຖືກ. ເອົາຂໍ້ຄວາມເຕັມພຽງແຕ່ສໍາລັບຜູ້ສະຫມັກທີ່ເລືອກ. ອັນນີ້ຊ່ວຍຫຼຸດຜ່ອນການເຮັດວຽກທີ່ບໍ່ຈໍາເປັນ ແລະຫຼີກເວັ້ນການແຍກວິເຄາະຈົດໝາຍສົ່ງເສີມການຂາຍທີ່ບໍ່ກ່ຽວຂ້ອງ.
ກວດສອບຜົນໄດ້ຮັບທາງທຸລະກິດ, ບໍ່ແມ່ນພຽງແຕ່ການມີ string ຫົກຕົວເລກເທົ່ານັ້ນ. ສົ່ງລະຫັດຫຼືເປີດການເຊື່ອມຕໍ່ທີ່ຄາດໄວ້, ຫຼັງຈາກນັ້ນຢືນຢັນວ່າບັນຊີມາຮອດສະຖານະທີ່ຖືກຕ້ອງ.
ຈັດການການຈຳກັດອັດຕາເປັນສັນຍານ
ຖ້າ API ສົ່ງຄືນການຕອບສະ ໜອງ ໂຄຕ້າຫຼືອັດຕາທີ່ ຈຳ ກັດ, ຢຸດຄວາມພະຍາຍາມໃນປະຈຸບັນແລະສະແດງຂໍ້ມູນການຕັ້ງຄືນໃຫມ່. ການພະຍາຍາມທີ່ຮຸກຮານເຮັດໃຫ້ສັນຍານຄວາມອາດສາມາດທີ່ຊັດເຈນເປັນສິ່ງລົບກວນ ແລະສາມາດຊັກຊ້າການທົດສອບທີ່ບໍ່ກ່ຽວຂ້ອງ.
ຈໍາກັດຄວາມສອດຄ່ອງຢູ່ໃນຕົວແລ່ນການທົດສອບ, ໂດຍສະເພາະໃນເວລາທີ່ຊຸດສ້າງທີ່ຢູ່ຫຼາຍບ່ອນໃນເວລາດຽວກັນ. ສະລອຍນ້ຳຄົນງານຂະໜາດນ້ອຍແມ່ນງ່າຍກວ່າທີ່ຈະດີບັກໄດ້ຫຼາຍກວ່າການລົງຄະແນນສຽງພ້ອມໆກັນຫຼາຍຮ້ອຍໜ່ວຍ.
ເຮັດຄວາມສະອາດໂດຍບໍ່ມີການປິດບັງຄວາມລົ້ມເຫລວ
ການທໍາຄວາມສະອາດຄວນຈະດໍາເນີນການຫຼັງຈາກທີ່ຖືກຈັບ. ເມື່ອສຳເລັດແລ້ວ, ໃຫ້ລຶບຂໍ້ຄວາມອອກ ຫຼືປ່ອຍໃຫ້ການເກັບຮັກສາສັ້ນຈັດການພວກມັນ. ເມື່ອຄວາມລົ້ມເຫລວ, ຮັກສາທີ່ຢູ່ແລະ ID ຂໍ້ຄວາມໃນສິ່ງປອມ CI ທີ່ມີການປ້ອງກັນຍາວພຽງພໍສໍາລັບການສືບສວນ, ຫຼັງຈາກນັ້ນລຶບພວກມັນອອກ.
ຢ່າພິມລະຫັດຢືນຢັນ, ລິ້ງສ່ວນຕົວ, ຫຼືອົງປະກອບ HTML ທີ່ສົມບູນເຂົ້າໄປໃນບັນທຶກການສ້າງສາທາລະນະ.
ລອງໃຊ້ຄືນໃໝ່ບໍ່ໄດ້ຜົນ
ລອງທົດສອບອີກຄັ້ງເປັນການແລ່ນໃໝ່ດ້ວຍທີ່ຢູ່ໃໝ່. ຢ່າສົມມຸດວ່າການຮ້ອງຂໍຄືນດຽວກັນກັບບັນຊີດຽວກັນແລະ inbox ເລີ່ມຕົ້ນຈາກສະຖານະທີ່ສະອາດ. ຜູ້ສົ່ງອາດຈະໃຊ້ບໍ່ໄດ້ລະຫັດເກົ່າ, throttle ການຮ້ອງຂໍຊ້ໍາ, ຫຼືປະຕິເສດຄໍາເຊີນທີ່ຊ້ໍາກັນ.
ຖ້າການຮ້ອງຂໍເຄືອຂ່າຍຫມົດເວລາ, ໃຫ້ຈໍາແນກ "ບໍ່ໄດ້ຮັບການຕອບສະຫນອງ" ຈາກ "ການດໍາເນີນງານບໍ່ໄດ້ເກີດຂຶ້ນ." ກວດເບິ່ງສະຖານະທີ່ສັງເກດໄດ້ກ່ອນທີ່ຈະອອກການພະຍາຍາມທໍາລາຍຄືນໃຫມ່.
ລາຍງານຈຸດທີ່ລົ້ມເຫລວ
ຄວາມລົ້ມເຫຼວຂອງອັດຕະໂນມັດທີ່ເປັນປະໂຫຍດກໍານົດຫນຶ່ງໃນຂັ້ນຕອນເຫຼົ່ານີ້:
- ການສ້າງທີ່ຢູ່ລົ້ມເຫລວ;
- ການປະຕິບັດຜະລິດຕະພັນລົ້ມເຫລວກ່ອນທີ່ຈະ enqueue ອີເມວ;
- ບໍ່ມີຂໍ້ຄວາມທີ່ກົງກັນມາຮອດກ່ອນກຳນົດເວລາ;
- ຂໍ້ຄວາມມາຮອດແຕ່ເນື້ອໃນບໍ່ກົງກັນ;
- ການປະຕິບັດການກວດສອບລົ້ມເຫລວ;
- ການອະນາໄມລົ້ມເຫລວ.
ການຈັດປະເພດນັ້ນເຮັດໃຫ້ "ການທົດສອບອີເມວລົ້ມເຫລວ" ຢ່າງຕໍ່ເນື່ອງເປັນວຽກທີ່ທີມງານສາມາດເປັນເຈົ້າຂອງໄດ້.
ສໍາລັບຕາຕະລາງການທົດສອບທີ່ໃຫຍ່ກວ່າ, ອ່ານ ແຜນທົດສອບອີເມວຈິງ. ສຳລັບການວິນິດໄສການຈັດສົ່ງ, ໃຫ້ໃຊ້ ການຢືນຢັນອີເມວບໍ່ມາຮອດ: ຊອກຫາຂັ້ນຕອນທີ່ແຕກຫັກ.