ໂຫຼດການທົດສອບເປັນບໍລິການ CI ສໍາລັບນັກພັດທະນາ

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

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

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

ໂດຍເນື້ອແທ້ແລ້ວຂອງແນວຄວາມຄິດ

ແນວຄວາມຄິດຂອງການທົດສອບການໂຫຼດເປັນການບໍລິການຫມາຍເຖິງຄວາມສາມາດໃນການລວມເຄື່ອງມືການໂຫຼດ Apache JMeter, Yandex.Tank ແລະກອບວຽກຂອງທ່ານເອງເຂົ້າໄປໃນລະບົບການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງໂດຍຕົນເອງ. ການສາທິດຈະເປັນສໍາລັບ GitLab CI, ແຕ່ຫຼັກການແມ່ນທົ່ວໄປກັບທຸກລະບົບ CI.

ການທົດສອບການໂຫຼດເປັນການບໍລິການແມ່ນການບໍລິການສູນກາງສໍາລັບການທົດສອບການໂຫຼດ. ການທົດສອບການໂຫຼດແມ່ນດໍາເນີນຢູ່ໃນສະນຸກເກີຕົວແທນທີ່ອຸທິດຕົນ, ຜົນໄດ້ຮັບຈະຖືກເຜີຍແຜ່ໂດຍອັດຕະໂນມັດໃນ GitLab Pages, Influx DB ແລະ Grafana ຫຼືໃນລະບົບການລາຍງານການທົດສອບ (TestRail, ReportPortal, ແລະອື່ນໆ). ອັດຕະໂນມັດແລະການປັບຂະ ໜາດ ແມ່ນຖືກປະຕິບັດຢ່າງງ່າຍດາຍເທົ່າທີ່ເປັນໄປໄດ້ - ໂດຍການເພີ່ມແລະພາລາມິເຕີຂອງແມ່ແບບ gitlab-ci.yml ປົກກະຕິໃນໂຄງການ GitLab CI.

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

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

ແນວຄວາມຄິດພື້ນຖານແລະຄໍານິຍາມໃນການທົດສອບການໂຫຼດ

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

ໂຫຼດຕົວແທນ - ເຄື່ອງ virtual ທີ່ແອັບພລິເຄຊັນຈະຖືກເປີດຕົວ - ແຫຼ່ງໂຫຼດ (Apache JMeter, Yandex.Tank ຫຼືໂມດູນການໂຫຼດທີ່ຂຽນດ້ວຍຕົນເອງ).

ເປົ້າໝາຍການທົດສອບ (ເປົ້າໝາຍ) - ເຊີບເວີຫຼືແອັບພລິເຄຊັນທີ່ຕິດຕັ້ງຢູ່ໃນເຊີບເວີທີ່ຈະຖືກໂຫລດ.

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

ໂປຣໄຟລ ຫຼືແຜນການໂຫຼດ (ໂປຣໄຟລ໌) - ໃນ ວິທີການ ISTQB (ພາກ 4.2.4, ຫນ້າ 43) load profiles ກໍານົດ metrics ທີ່ສໍາຄັນສໍາລັບການທົດສອບສະເພາະໃດຫນຶ່ງແລະທາງເລືອກສໍາລັບການປ່ຽນພາລາມິເຕີການໂຫຼດໃນລະຫວ່າງການທົດສອບ. ທ່ານສາມາດເບິ່ງຕົວຢ່າງຂອງໂປຣໄຟລ໌ໃນຮູບ.

ການທົດສອບ — ສະຄຣິບທີ່ມີຊຸດພາລາມິເຕີທີ່ກຳນົດໄວ້ລ່ວງໜ້າ.

ແຜນ​ການ​ທົດ​ສອບ (ແຜນ​ການ​ທົດ​ສອບ​) - ຊຸດ​ຂອງ​ການ​ທົດ​ສອບ​ແລະ profile ການ​ໂຫຼດ​ໄດ້​.

ທົດສອບ (testrun) - ການທົດສອບອີກຄັ້ງຫນຶ່ງຂອງການທົດສອບຫນຶ່ງທີ່ມີສະຖານະການໂຫຼດທີ່ປະຕິບັດຢ່າງເຕັມສ່ວນແລະບົດລາຍງານທີ່ໄດ້ຮັບ.

ການຮ້ອງຂໍເຄືອຂ່າຍ (ຄໍາຮ້ອງຂໍ) — ຄໍາຮ້ອງຂໍ HTTP ສົ່ງຈາກຕົວແທນໄປຫາເປົ້າໝາຍ.

ການ​ຕອບ​ສະ​ຫນອງ​ເຄືອ​ຂ່າຍ (ການ​ຕອບ​ສະ​ຫນອງ​) — ການຕອບສະໜອງ HTTP ທີ່ສົ່ງຈາກເປົ້າໝາຍໄປຫາຕົວແທນ.
ລະຫັດຕອບຮັບ HTTP (ສະຖານະພາບການຕອບຮັບ HTTP) - ລະຫັດຕອບສະຫນອງມາດຕະຖານຈາກເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ.
ທຸລະກໍາແມ່ນວົງຈອນການຕອບຄໍາຮ້ອງຂໍທີ່ສົມບູນ. ການເຮັດທຸລະກໍາແມ່ນນັບຈາກການເລີ່ມຕົ້ນຂອງການສົ່ງຄໍາຮ້ອງຂໍ (ຄໍາຮ້ອງຂໍ) ຈົນເຖິງການສໍາເລັດການໄດ້ຮັບການຕອບສະຫນອງ (ການຕອບສະຫນອງ).

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

ເວລາຕອບສະໜອງ (latency) - ເວລາຈາກການສິ້ນສຸດຂອງການສົ່ງຄໍາຮ້ອງຂໍ (ຄໍາຮ້ອງຂໍ) ໄປຫາຈຸດເລີ່ມຕົ້ນຂອງການໄດ້ຮັບຄໍາຕອບ (ຄໍາຕອບ).

Load metrics — ຄຸນ​ລັກ​ສະ​ນະ​ຂອງ​ການ​ບໍ​ລິ​ການ​ໂຫຼດ​ແລະ​ຕົວ​ແທນ​ການ​ໂຫຼດ​ກໍາ​ນົດ​ໃນ​ຂະ​ບວນ​ການ​ຂອງ​ການ​ທົດ​ສອບ​ການ​ໂຫຼດ​.

metrics ພື້ນຖານສໍາລັບການວັດແທກພາລາມິເຕີການໂຫຼດ

ບາງສ່ວນຂອງການນໍາໃຊ້ທົ່ວໄປທີ່ສຸດແລະແນະນໍາໃນວິທີການ ISTQB (ໜ້າ 36, 52) ການວັດແທກແມ່ນສະແດງຢູ່ໃນຕາຕະລາງຂ້າງລຸ່ມນີ້. metrics ທີ່ຄ້າຍຄືກັນສໍາລັບຕົວແທນແລະເປົ້າຫມາຍແມ່ນສະແດງຢູ່ໃນເສັ້ນດຽວກັນ.

metrics ສໍາລັບຕົວແທນການໂຫຼດ
Metrics ຂອງລະບົບເປົ້າຫມາຍຫຼືຄໍາຮ້ອງສະຫມັກທີ່ຖືກທົດສອບພາຍໃຕ້ການໂຫຼດ

ຈໍານວນຂອງ  vCPU ແລະຄວາມຊົງຈໍາ RAM,
ແຜ່ນ - ຄຸນລັກສະນະ "ທາດເຫຼັກ" ຂອງຕົວແທນການໂຫຼດ
CPU, ຫນ່ວຍຄວາມຈໍາ, ການນໍາໃຊ້ແຜ່ນ - ນະ​ໂຍ​ບາຍ​ດ້ານ​ຂອງ CPU​, ຫນ່ວຍ​ຄວາມ​ຈໍາ​ແລະ​ການ​ໂຫຼດ​ແຜ່ນ​
ໃນ​ຂະ​ບວນ​ການ​ຂອງ​ການ​ທົດ​ສອບ​. ປົກກະຕິແລ້ວການວັດແທກເປັນເປີເຊັນຂອງ
ຄ່າສູງສຸດທີ່ມີຢູ່

ຜ່ານເຄືອຂ່າຍ (on load agent) - throughput
ການໂຕ້ຕອບເຄືອຂ່າຍຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ,
ບ່ອນທີ່ຕົວແທນການໂຫຼດໄດ້ຖືກຕິດຕັ້ງ.
ປົກກະຕິແລ້ວວັດແທກເປັນ bytes ຕໍ່ວິນາທີ (bps)
ຜ່ານເຄືອຂ່າຍ(ໃນເປົ້າຫມາຍ) - ແບນວິດຂອງການໂຕ້ຕອບເຄືອຂ່າຍ
ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍເປົ້າຫມາຍ. ປົກກະຕິແລ້ວວັດແທກເປັນ bytes ຕໍ່ວິນາທີ (bps)

ຜູ້ໃຊ້ສະເໝືອນ- ຈໍາ​ນວນ​ຂອງ​ຜູ້​ໃຊ້ virtual​,
ການປະຕິບັດສະຖານະການການໂຫຼດແລະ
imitating ການ​ກະ​ທໍາ​ຂອງ​ຜູ້​ໃຊ້​ທີ່​ແທ້​ຈິງ​
ສະຖານະຜູ້ໃຊ້ສະເໝືອນ, ຜ່ານ / ລົ້ມເຫລວ / ຈໍານວນທັງຫມົດ - ຈໍານວນສົບຜົນສໍາເລັດແລະ
ສະຖານະການທີ່ບໍ່ປະສົບຜົນສໍາເລັດຂອງຜູ້ໃຊ້ virtual
ສໍາລັບສະຖານະການໂຫຼດ, ເຊັ່ນດຽວກັນກັບຈໍານວນທັງຫມົດຂອງພວກເຂົາ.

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

ການຮ້ອງຂໍຕໍ່ວິນາທີ (ນາທີ)- ຈໍານວນຂອງການຮ້ອງຂໍເຄືອຂ່າຍຕໍ່ວິນາທີ (ຫຼືນາທີ).

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

ລັກສະນະທີ່ສໍາຄັນຂອງການບໍລິການເປົ້າຫມາຍ: ຫຼາຍປານໃດ
ສ້າງແລະສົ່ງຄໍາຕອບກັບຄໍາຖາມ
ຕົວແທນການໂຫຼດ

ສະຖານະຕອບ HTTP— ຈໍາ​ນວນ​ຂອງ​ລະ​ຫັດ​ຕອບ​ສະ​ຫນອງ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​
ຈາກເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນທີ່ໄດ້ຮັບໂດຍຕົວແທນການໂຫຼດ.
ຕົວຢ່າງ, 200 OK ຫມາຍເຖິງການໂທທີ່ປະສົບຜົນສໍາເລັດ,
ແລະ 404 - ວ່າຊັບພະຍາກອນບໍ່ພົບ

ການເລື່ອນເວລາ (ເວລາຕອບໂຕ້) - ເວລາຈາກທ້າຍ
ການ​ສົ່ງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ (request) ກ່ອນ​ທີ່​ຈະ​ເລີ່ມ​ຕົ້ນ​ໄດ້​ຮັບ​ການ​ຕອບ​ສະ​ຫນອງ (ຕອບ​ສະ​ຫນອງ​)​.
ປົກກະຕິແລ້ວວັດແທກເປັນ milliseconds (ms)

ເວລາຕອບສະຫນອງການເຮັດທຸລະກໍາ- ເວ​ລາ​ຂອງ​ການ​ຫນຶ່ງ​ຢ່າງ​ເຕັມ​ທີ່​,
ສໍາເລັດຂອງວົງຈອນການຮ້ອງຂໍການຕອບໂຕ້.
ນີ້ແມ່ນເວລາຈາກການເລີ່ມຕົ້ນຂອງການສົ່ງຄໍາຮ້ອງຂໍ (ຄໍາຮ້ອງຂໍ)
ຈົນກ່ວາສໍາເລັດການໄດ້ຮັບການຕອບສະຫນອງ (ຕອບສະຫນອງ).

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

ທຸລະກຳຕໍ່ວິນາທີ (ນາທີ) - ຈໍາ​ນວນ​ທີ່​ສົມ​ບູນ​
ທຸລະກຳຕໍ່ວິນາທີ (ນາທີ),
ນັ້ນແມ່ນ, ຄໍາຮ້ອງສະຫມັກສາມາດຍອມຮັບໄດ້ຫຼາຍປານໃດແລະ
ຂະບວນການຮ້ອງຂໍແລະອອກຄໍາຕອບ.
ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນການສົ່ງຕໍ່ຂອງລະບົບ

ສະຖານະການທຸລະກໍາ , ຜ່ານ / ລົ້ມເຫລວ / Total - ຈໍານວນ
ປະສົບຜົນສໍາເລັດ, ບໍ່ສໍາເລັດແລະຈໍານວນການເຮັດທຸລະກໍາທັງຫມົດ.

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

Load Testing Schematic Diagram

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

ບັນທຶກແບບແຜນ:

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

ການຈັດປະເພດຫົວໜ່ວຍ, ຂັ້ນຕອນ ແລະຂັ້ນຕອນໃນແຜນວາດ

ຂັ້ນຕອນແລະຂັ້ນຕອນ
ເກີດ​ຫຍັງ​ຂຶ້ນ
ແມ່ນຫຍັງຢູ່ທາງເຂົ້າ
ຜົນຜະລິດແມ່ນຫຍັງ

ການກະກຽມ: ຂັ້ນຕອນການກະກຽມສໍາລັບການທົດສອບ

LoadParameters
ການຕັ້ງຄ່າແລະການເລີ່ມຕົ້ນ
ຜູ້ໃຊ້
ຕົວກໍານົດການໂຫຼດ,
ທາງເລືອກຂອງ metrics ແລະ
ການ​ກະ​ກຽມ​ແຜນ​ການ​ທົດ​ສອບ​
(ໂຫຼດໂປຣໄຟລ໌)
ທາງເລືອກທີ່ກໍາຫນົດເອງສໍາລັບ
ໂຫຼດຕົວແທນເລີ່ມຕົ້ນ
ແຜນການທົດສອບ
ຈຸດ​ປະ​ສົງ​ຂອງ​ການ​ທົດ​ສອບ​

VM
ການນຳໃຊ້ຄລາວ
ເຄື່ອງ virtual ກັບ
ຄຸນ​ລັກ​ສະ​ນະ​ທີ່​ຕ້ອງ​ການ​
ການຕັ້ງຄ່າ VM ສໍາລັບຕົວແທນການໂຫຼດ
ສະຄຣິບອັດຕະໂນມັດສໍາລັບ
ການສ້າງ VM
VM ຕັ້ງຄ່າໃນ
ຟັງ

ສິ່ງແວດລ້ອມ
ການຕິດຕັ້ງ OS ແລະການກະກຽມ
ສະພາບແວດລ້ອມສໍາລັບ
ໂຫຼດຕົວແທນເຮັດວຽກ
ການຕັ້ງຄ່າສະພາບແວດລ້ອມສໍາລັບ
ຕົວແທນການໂຫຼດ
ສະຄຣິບອັດຕະໂນມັດສໍາລັບ
ການຕັ້ງຄ່າສະພາບແວດລ້ອມ
ສະພາບແວດລ້ອມກະກຽມ:
OS, ບໍລິການ ແລະແອັບພລິເຄຊັນ,
ມີຄວາມຈໍາເປັນສໍາລັບການເຮັດວຽກ
ຕົວແທນການໂຫຼດ

LoadAgents
ການຕິດຕັ້ງ, ການຕັ້ງຄ່າແລະພາລາມິເຕີ
ຕົວແທນການໂຫຼດ.
ຫຼືການດາວໂຫຼດຮູບພາບ docker ຈາກ
ແຫຼ່ງໂຫຼດທີ່ກຳນົດຄ່າໄວ້ລ່ວງໜ້າ
ໂຫລດຮູບ docker ແຫຼ່ງ
(YAT, JM ຫຼືກອບທີ່ຂຽນດ້ວຍຕົນເອງ)
ການຕັ້ງຄ່າ
ຕົວແທນການໂຫຼດ
ຕັ້ງຄ່າແລະກຽມພ້ອມ
ເພື່ອເຮັດວຽກຕົວແທນການໂຫຼດ

ການທົດສອບ: ຂັ້ນຕອນຂອງການປະຕິບັດການທົດສອບການໂຫຼດ. ແຫຼ່ງຂໍ້ມູນແມ່ນຕົວແທນການໂຫຼດທີ່ຖືກນໍາໃຊ້ໃນກຸ່ມຕົວແທນສະເພາະສໍາລັບ GitLab CI

Load
ກຳລັງເລີ່ມການໂຫຼດຕົວແທນ
ດ້ວຍແຜນການສອບເສັງທີ່ເລືອກ
ແລະຕົວກໍານົດການໂຫຼດ
ຕົວເລືອກຜູ້ໃຊ້
ສໍາລັບການເລີ່ມຕົ້ນ
ຕົວແທນການໂຫຼດ
ແຜນການທົດສອບ
ຈຸດ​ປະ​ສົງ​ຂອງ​ການ​ທົດ​ສອບ​
ບັນທຶກການປະຕິບັດ
ການທົດສອບການໂຫຼດ
ບັນທຶກລະບົບ
Dynamics ຂອງການປ່ຽນແປງໃນ metrics ເປົ້າຫມາຍແລະຕົວແທນການໂຫຼດ

ດໍາເນີນການຕົວແທນ
ການປະຕິບັດຕົວແທນ
ການໂຫຼດຂອງສະຄຣິບທົດສອບ
ສອດຄ່ອງກັບ
ໂຫຼດໂປຣໄຟລ໌
ໂຫຼດການໂຕ້ຕອບຕົວແທນ
ສໍາລັບຈຸດປະສົງຂອງການທົດສອບ
ແຜນການທົດສອບ
ຈຸດ​ປະ​ສົງ​ຂອງ​ການ​ທົດ​ສອບ​

ຂໍ້​ມູນ​ບັນ​ທຶກ
ການເກັບກໍາຂໍ້ມູນບັນທຶກ "ດິບ".
ໃນ​ລະ​ຫວ່າງ​ການ​ທົດ​ສອບ​ການ​ໂຫຼດ​:
ໂຫຼດບັນທຶກກິດຈະກໍາຕົວແທນ,
ສະຖານະຂອງເປົ້າຫມາຍການທົດສອບ
ແລະ VM ແລ່ນຕົວແທນ

ບັນທຶກການປະຕິບັດ
ການທົດສອບການໂຫຼດ
ບັນທຶກລະບົບ

Metrics
ເກັບກໍາ "ວັດຖຸດິບ" metrics ໃນລະຫວ່າງການທົດສອບ

Dynamics ຂອງການປ່ຽນແປງໃນ metrics ເປົ້າຫມາຍ
ແລະຕົວແທນການໂຫຼດ

ບົດລາຍງານ: ຂັ້ນຕອນການກະກຽມບົດລາຍງານການທົດສອບ

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

ເຜີຍແຜ່
ການພິມເຜີຍແຜ່ບົດລາຍງານ
ກ່ຽວກັບການໂຫຼດ
ການ​ທົດ​ສອບ​ພາຍ​ນອກ​
ການບໍລິການ
ປຸງແຕ່ງ "ດິບ"
ບັນທຶກໃນຮູບແບບທີ່ເຫມາະສົມ
ສໍາລັບການ unloading ກັບພາຍນອກ
ຄັງເກັບມ້ຽນ
ບັນທຶກໃນພາຍນອກ
ລາຍງານການເກັບຮັກສາໃນ
ໂຫຼດ, ເຫມາະ
ສໍາລັບການວິເຄາະຂອງມະນຸດ

ເຊື່ອມຕໍ່ແຫຼ່ງໂຫຼດໃນແມ່ແບບ CI

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

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

ວິທີການຊອກຫາພະລັງງານທີ່ຕ້ອງການໂດຍຮາດແວ? ຄຸນລັກສະນະຂອງການໂຫຼດ - ຈໍານວນ vCPU, RAM ແລະ Disk ທີ່ພຽງພໍ - ສາມາດຄິດໄລ່ໄດ້ໂດຍອີງໃສ່ຄວາມຈິງທີ່ວ່າ Docker, Python (ສໍາລັບ Yandex.Tank), ຕົວແທນ GitLab CI, Java (ສໍາລັບ Apache JMeter) ຄວນຈະເຮັດວຽກຢູ່ໃນຕົວແທນ. . ສໍາລັບ Java ພາຍໃຕ້ JMeter, ມັນຍັງແນະນໍາໃຫ້ໃຊ້ຢ່າງຫນ້ອຍ 512 MB ຂອງ RAM ແລະ, ເປັນຂອບເຂດຈໍາກັດເທິງ, 80% ຄວາມຊົງຈໍາທີ່ມີຢູ່.

ດັ່ງນັ້ນ, ອີງຕາມປະສົບການຂອງພວກເຮົາ, ພວກເຮົາແນະນໍາໃຫ້ໃຊ້ຢ່າງຫນ້ອຍ 4 vCPUs, 4 GB RAM, 60 GB SSD ສໍາລັບຕົວແທນການໂຫຼດ. throughput ຂອງບັດເຄືອຂ່າຍແມ່ນຖືກກໍານົດໂດຍອີງໃສ່ຄວາມຕ້ອງການຂອງໂປຣໄຟລ໌ການໂຫຼດ.

ພວກເຮົາສ່ວນໃຫຍ່ໃຊ້ສອງແຫຼ່ງການໂຫຼດ - Apache JMeter ແລະ Yandex.Tank docker ຮູບພາບ.

Yandex.Tank ເປັນເຄື່ອງມືແຫຼ່ງເປີດຈາກ Yandex ສໍາລັບການທົດສອບການໂຫຼດ. ສະຖາປັດຕະຍະກໍາແບບໂມດູລາຂອງມັນແມ່ນອີງໃສ່ເຄື່ອງກໍາເນີດຄໍາຮ້ອງຂໍ HTTP ແບບ asynchronous ທີ່ມີປະສິດທິພາບສູງຂອງ Phantom. ຖັງມີການຕິດຕັ້ງໃນການກວດສອບຊັບພະຍາກອນຂອງເຄື່ອງແມ່ຂ່າຍພາຍໃຕ້ການທົດສອບໂດຍຜ່ານໂປໂຕຄອນ SSH, ສາມາດຢຸດການທົດສອບໂດຍອັດຕະໂນມັດພາຍໃຕ້ເງື່ອນໄຂທີ່ກໍານົດ, ສາມາດສະແດງຜົນໄດ້ຮັບທັງໃນ console ແລະໃນຮູບແບບຂອງກາຟ, ທ່ານສາມາດເຊື່ອມຕໍ່ໂມດູນຂອງທ່ານໄດ້. ກັບມັນເພື່ອຂະຫຍາຍການເຮັດວຽກ. ໂດຍວິທີທາງການ, ພວກເຮົາໃຊ້ Tank ໃນເວລາທີ່ມັນຍັງບໍ່ທັນເປັນກະແສຫຼັກ. ໃນບົດຄວາມ "Yandex.Tank ແລະການໂຫຼດອັດຕະໂນມັດການທົດສອບ» ທ່ານ​ສາ​ມາດ​ອ່ານ​ບົດ​ເລື່ອງ​ຂອງ​ວິ​ທີ​ການ​ທີ່​ພວກ​ເຮົາ​ປະ​ຕິ​ບັດ​ການ​ທົດ​ສອບ​ການ​ໂຫຼດ​ກັບ​ມັນ​ໃນ​ປີ 2013​ PT Application Firewall ແມ່ນຫນຶ່ງໃນຜະລິດຕະພັນຂອງບໍລິສັດຂອງພວກເຮົາ.

Apache JMeter ແມ່ນເຄື່ອງມືທົດສອບການໂຫຼດແຫຼ່ງເປີດຈາກ Apache. ມັນສາມາດຖືກນໍາໃຊ້ຢ່າງເທົ່າທຽມກັນສໍາລັບການທົດສອບທັງຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ແບບຄົງທີ່ແລະແບບເຄື່ອນໄຫວ. JMeter ສະຫນັບສະຫນູນຈໍານວນຫລາຍຂອງໂປໂຕຄອນແລະວິທີການພົວພັນກັບແອັບພລິເຄຊັນ: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, ແລະອື່ນໆ), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) ແລະ IMAP(S), ຖານຂໍ້ມູນຜ່ານ JDBC, ສາມາດປະຕິບັດຄໍາສັ່ງ shell ແລະເຮັດວຽກກັບວັດຖຸ Java. JMeter ມີ IDE ສໍາລັບການສ້າງ, ແກ້ບັນຫາ ແລະປະຕິບັດແຜນການທົດສອບ. ນອກນັ້ນຍັງມີ CLI ສໍາລັບການປະຕິບັດເສັ້ນຄໍາສັ່ງໃນທຸກລະບົບປະຕິບັດການທີ່ເຂົ້າກັນໄດ້ກັບ Java (Linux, Windows, Mac OS X). ເຄື່ອງມືສາມາດສ້າງບົດລາຍງານການທົດສອບ HTML ແບບເຄື່ອນໄຫວໄດ້.

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

ພວກເຮົາໄດ້ເອົາໄຟລ໌ docker ພື້ນຖານນີ້ສໍາລັບ Yandex.Tank:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

ແລະສໍາລັບ Apache JMeter ນີ້:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

ທ່ານສາມາດອ່ານວິທີການທີ່ລະບົບການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງຂອງພວກເຮົາເຮັດວຽກຢູ່ໃນບົດຄວາມ "ອັດຕະໂນມັດຂອງຂະບວນການພັດທະນາ: ວິທີການທີ່ພວກເຮົາປະຕິບັດແນວຄວາມຄິດ DevOps ຢູ່ເຕັກໂນໂລຢີໃນທາງບວກ".

ແມ່ແບບແລະທໍ່

ຕົວຢ່າງຂອງແມ່ແບບສໍາລັບການທົດສອບການໂຫຼດແມ່ນມີຢູ່ໃນໂຄງການ ການໂຫຼດຕົວຢ່າງ. ການ ໄຟລ໌ readme ທ່ານສາມາດອ່ານຄໍາແນະນໍາສໍາລັບການນໍາໃຊ້ແມ່ແບບ. ໃນແມ່ແບບຕົວມັນເອງ (ໄຟລ໌ .gitlab-ci.yml) ມີບັນທຶກກ່ຽວກັບສິ່ງທີ່ແຕ່ລະຂັ້ນຕອນຮັບຜິດຊອບ.

ແມ່ແບບແມ່ນງ່າຍດາຍຫຼາຍແລະສະແດງໃຫ້ເຫັນສາມຂັ້ນຕອນຂອງການທົດສອບການໂຫຼດໄດ້ອະທິບາຍໄວ້ໃນແຜນຜັງຂ້າງເທິງ: ການກະກຽມ, ການທົດສອບແລະການເຜີຍແຜ່ບົດລາຍງານ. ຮັບຜິດຊອບສໍາລັບການນີ້ ການຝຶກ: ກະກຽມ, ທົດສອບແລະລາຍງານ.

1. ຂັ້ນຕອນ ກຽມຕົວ ຄວນຖືກນໍາໃຊ້ເພື່ອກໍານົດເປົ້າຫມາຍການທົດສອບລ່ວງຫນ້າຫຼືກວດເບິ່ງຄວາມພ້ອມຂອງພວກມັນ. ສະພາບແວດລ້ອມສໍາລັບແຫຼ່ງການໂຫຼດບໍ່ຈໍາເປັນຕ້ອງຖືກຕັ້ງຄ່າ, ພວກມັນຖືກສ້າງຂຶ້ນກ່ອນເປັນຮູບພາບ docker ແລະຖືກຈັດພີມມາຢູ່ໃນທະບຽນ docker: ພຽງແຕ່ລະບຸສະບັບທີ່ຕ້ອງການໃນຂັ້ນຕອນການທົດສອບ. ແຕ່ທ່ານສາມາດສ້າງພວກມັນຄືນໃຫມ່ແລະເຮັດໃຫ້ຮູບພາບທີ່ດັດແປງຂອງທ່ານເອງ.
2. ຂັ້ນຕອນ ການທົດສອບ ໃຊ້ເພື່ອລະບຸແຫຼ່ງໂຫຼດ, ແລ່ນການທົດສອບ, ແລະເກັບຮັກສາສິ່ງຂອງການທົດສອບ. ທ່ານສາມາດເລືອກແຫຼ່ງໂຫຼດໃດໆ: Yandex.Tank, Apache JMeter, ຂອງທ່ານເອງ, ຫຼືທັງຫມົດຮ່ວມກັນ. ເພື່ອປິດແຫຼ່ງທີ່ບໍ່ຈໍາເປັນ, ພຽງແຕ່ສະແດງຄວາມຄິດເຫັນຫຼືລຶບວຽກ. ຈຸດເຂົ້າສໍາລັບແຫຼ່ງໂຫຼດ:
   • ຕົວກໍານົດການເປີດຕົວສໍາລັບ Yandex.Tank ແມ່ນລະບຸໄວ້ໃນ ./tests/yandextank.sh,
   • ຕົວກໍານົດການເລີ່ມຕົ້ນ Apache JMeter ຖືກລະບຸໄວ້ໃນໄຟລ໌ ./tests/jmeter.sh.

   ຫມາຍເຫດ: ແມ່ແບບການຕັ້ງຄ່າການປະກອບແມ່ນໃຊ້ເພື່ອຕັ້ງຄ່າການໂຕ້ຕອບກັບລະບົບ CI ແລະບໍ່ໄດ້ຫມາຍເຖິງການຈັດວາງຂອງເຫດຜົນການທົດສອບໃນມັນ. ສໍາ​ລັບ​ການ​ທົດ​ສອບ​, ຈຸດ​ເຂົ້າ​ແມ່ນ​ໄດ້​ລະ​ບຸ​ໄວ້​, ບ່ອນ​ທີ່ script bash ການ​ຄວບ​ຄຸມ​ແມ່ນ​ຕັ້ງ​ຢູ່​. ວິທີການແລ່ນການທົດສອບ, ການສ້າງບົດລາຍງານ, ແລະສະຄິບທົດສອບດ້ວຍຕົນເອງຕ້ອງໄດ້ຮັບການປະຕິບັດໂດຍວິສະວະກອນ QA. ໃນການສາທິດ, ສໍາລັບທັງສອງແຫຼ່ງການໂຫຼດ, ຄໍາຮ້ອງຂໍຫນ້າຕົ້ນຕໍ Yandex ຖືກນໍາໃຊ້ເປັນການທົດສອບທີ່ງ່າຍດາຍທີ່ສຸດ. Scripts ແລະຕົວກໍານົດການທົດສອບແມ່ນຢູ່ໃນໄດເລກະທໍລີ ./tests.

3. ຢູ່ໃນຂັ້ນຕອນຂອງການ ບົດລາຍງານ ທ່ານຈໍາເປັນຕ້ອງອະທິບາຍວິທີການເຜີຍແຜ່ຜົນການທົດສອບທີ່ໄດ້ຮັບໃນຂັ້ນຕອນການທົດສອບໃຫ້ກັບບ່ອນເກັບຂໍ້ມູນພາຍນອກ, ສໍາລັບຕົວຢ່າງ, ໄປຫາ GitLab Pages ຫຼືລະບົບການລາຍງານພິເສດ. GitLab Pages ຮຽກຮ້ອງໃຫ້ໄດເຣັກທໍຣີ ./public ບໍ່ຫວ່າງເປົ່າ ແລະ ມີໄຟລ໌ index.html ຢ່າງໜ້ອຍໜຶ່ງໄຟລ໌ຫຼັງຈາກການທົດສອບສຳເລັດແລ້ວ. ທ່ານສາມາດອ່ານກ່ຽວກັບຄວາມແຕກຕ່າງຂອງບໍລິການ GitLab Pages. ການເຊື່ອມຕໍ່.

   ຕົວຢ່າງຂອງວິທີການສົ່ງອອກຂໍ້ມູນ:

   • ຈາກ JMeter ກັບ ຫນ້າ GitLab,
   • ຈາກ Yandex.Tank ກັບ InfluxDB ແລະ Grafana.

   ກຳລັງໂພສຄຳແນະນຳການຕັ້ງຄ່າ:

   • HTML statics ໃນ ຫນ້າ GitLab,
   • ກັບ InfluxDB ແລະຫຼັງຈາກນັ້ນ ກຣາຟານາ.

ໃນຕົວຢ່າງຕົວຢ່າງ, ທໍ່ທີ່ມີການທົດສອບການໂຫຼດແລະສອງແຫຼ່ງໂຫຼດ (ທ່ານສາມາດປິດການໃຊ້ງານທີ່ບໍ່ຈໍາເປັນ) ເບິ່ງຄືວ່າ:

Apache JMeter ສາມາດສ້າງບົດລາຍງານ HTML ຕົວຂອງມັນເອງ, ດັ່ງນັ້ນມັນມີກໍາໄລຫຼາຍທີ່ຈະຊ່ວຍປະຢັດມັນຢູ່ໃນ GitLab Pages ໂດຍໃຊ້ເຄື່ອງມືມາດຕະຖານ. ນີ້ແມ່ນວິທີການລາຍງານ Apache JMeter ເບິ່ງຄືວ່າ:

ໃນຕົວຢ່າງຕົວຢ່າງສໍາລັບ Yandex.Tank, ທ່ານພຽງແຕ່ຈະເຫັນ ບົດລາຍງານຂໍ້ຄວາມປອມ ໃນພາກສໍາລັບ GitLab Pages. ໃນ​ລະ​ຫວ່າງ​ການ​ທົດ​ສອບ​, Tank ສາ​ມາດ​ບັນ​ທຶກ​ຜົນ​ໄດ້​ຮັບ​ໃນ​ຖານ​ຂໍ້​ມູນ InfluxDB​, ແລະ​ຈາກ​ນັ້ນ​ເຂົາ​ເຈົ້າ​ສາ​ມາດ​ສະ​ແດງ​ໄດ້​, ສໍາ​ລັບ​ການ​ຍົກ​ຕົວ​ຢ່າງ​, ໃນ Grafana (ການ​ຕັ້ງ​ຄ່າ​ແມ່ນ​ເຮັດ​ໄດ້​ໃນ​ໄຟລ​໌​. ./tests/example-yandextank-test.yml). ນີ້ແມ່ນວິທີການລາຍງານຂອງ Tank ໃນ Grafana:

Summary

ໃນບົດຄວາມ, ຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ຽວກັບແນວຄວາມຄິດຂອງ "ການທົດສອບການໂຫຼດເປັນບໍລິການ" (ການທົດສອບການໂຫຼດເປັນບໍລິການ). ແນວຄວາມຄິດຕົ້ນຕໍແມ່ນການນໍາໃຊ້ໂຄງສ້າງພື້ນຖານຂອງຕົວແທນການໂຫຼດທີ່ກໍານົດໄວ້ກ່ອນ, ຮູບພາບ docker ຂອງແຫຼ່ງການໂຫຼດ, ລະບົບການລາຍງານແລະທໍ່ທີ່ປະສົມປະສານພວກມັນຢູ່ໃນ GitLab CI ໂດຍອີງໃສ່ແມ່ແບບ .gitlab-ci.yml ງ່າຍດາຍ (ຕົວຢ່າງ. ການເຊື່ອມຕໍ່). ທັງຫມົດນີ້ແມ່ນສະຫນັບສະຫນູນໂດຍທີມງານຂະຫນາດນ້ອຍຂອງວິສະວະກອນອັດຕະໂນມັດແລະ replicated ຕາມຄໍາຮ້ອງຂໍຂອງທີມງານຜະລິດຕະພັນ. ຂ້ອຍຫວັງວ່ານີ້ຈະຊ່ວຍເຈົ້າໃນການກະກຽມແລະປະຕິບັດໂຄງການທີ່ຄ້າຍຄືກັນໃນບໍລິສັດຂອງເຈົ້າ. ຂອບໃຈສໍາລັບຄວາມສົນໃຈ!

PS ຂ້າພະເຈົ້າຕ້ອງການເວົ້າຂອບໃຈກັບເພື່ອນຮ່ວມງານຂອງຂ້າພະເຈົ້າ, Sergey Kurbanov ແລະ Nikolai Yusev, ສໍາລັບການຊ່ວຍເຫຼືອດ້ານວິຊາການກັບການປະຕິບັດແນວຄວາມຄິດຂອງການທົດສອບການໂຫຼດເປັນການບໍລິການໃນບໍລິສັດຂອງພວກເຮົາ.

ຜູ້ຂຽນ: Timur Gillmullin - ຮອງ ຫົວຫນ້າຂະບວນການເຕັກໂນໂລຢີແລະການພັດທະນາ (DevOps) ຢູ່ເຕັກໂນໂລຢີໃນທາງບວກ

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