ສັນຍາລັກ Gherkin
Gherkin記法 (ການຂຽນແບບ Gherkin) ແມ່ນຮູບແບບທີ່ມີໂຄງສ້າງສຳລັບອະທິບາຍພຶດຕິກຳຂອງຊອບແວດ້ວຍພາສາທຳມະຊາດ ໂດຍໃຊ້ 3 ຂັ້ນຕອນ ຄື Given (ເງື່ອນໄຂເບື້ອງຕົ້ນ)・When (ການດຳເນີນການ)・Then (ຜົນລັບ). ຮູບແບບນີ້ຖືກໃຊ້ຢ່າງກວ້າງຂວາງເປັນການຂຽນມາດຕະຖານສຳລັບໄຟລ໌ .feature ທີ່ອ່ານໂດຍເຄື່ອງມືທົດສອບອັດຕະໂນມັດ Cucumber.
ເປັນຫຍັງຈຶ່ງໃຊ້ Gherkin
ໃນຫຼາຍໆທີມງານ, ນັກພັດທະນາຈັດການສະເປັກການທົດສອບດ້ວຍ code ໃນຂະນະທີ່ຝ່າຍທຸລະກິດຈັດການດ້ວຍເອກະສານພາສາຍີ່ປຸ່ນຫຼືອັງກິດແຍກຕ່າງຫາກ. ທຸກຄັ້ງທີ່ມີການປ່ຽນແປງສະເປັກ, ຈຳເປັນຕ້ອງອັບເດດທັງສອງຝ່າຍ ເຮັດໃຫ້ເກີດຄວາມຄາດເຄື່ອນສະສົມຂຶ້ນເລື້ອຍໆ.
Gherkin notation ແກ້ໄຂບັນຫານີ້ດ້ວຍວິທີການທີ່ເອີ້ນວ່າ "executable specification". ດ້ວຍ syntax ທີ່ໃກ້ຄຽງກັບພາສາທຳມະຊາດທີ່ຜູ້ຮັບຜິດຊອບດ້ານທຸລະກິດສາມາດອ່ານໄດ້, ໃນຂະນະດຽວກັນກໍ່ສາມາດ execute ເປັນ automated test ໄດ້ໂດຍກົງ. ເນື່ອງຈາກສະເປັກແລະ test code ຢູ່ໃນໄຟລ໌ດຽວກັນ, ຄວາມແຕກຕ່າງລະຫວ່າງທັງສອງຈຶ່ງເກີດຂຶ້ນຍາກໂດຍໂຄງສ້າງ.
Syntax ພື້ນຖານ
ໂຄງສ້າງທົ່ວໄປຂອງໄຟລ໌ .feature ມີດັ່ງນີ້.
1Feature: ການ login ຂອງຜູ້ໃຊ້
2
3 Scenario: ສາມາດ login ດ້ວຍຂໍ້ມູນການພິສູດຕົວຕົນທີ່ຖືກຕ້ອງ
4 Given ສະແດງໜ້າ login ຢູ່
5 When ປ້ອນທີ່ຢູ່ email "user@example.com"
6 And ປ້ອນລະຫັດຜ່ານ "correct-password"
7 And ຄລິກປຸ່ມ login
8 Then dashboard ຖືກສະແດງຂຶ້ນFeature ສອດຄ່ອງກັບກຸ່ມຂອງໜ່ວຍຟັງຊັ່ນ, ສ່ວນ Scenario ສອດຄ່ອງກັບ test case ແຕ່ລະອັນ. ສາມາດເພີ່ມເງື່ອນໄຂດ້ວຍ And / But, ແລະສາມາດ parameterize ໄດ້ດ້ວຍ Scenario Outline + ຕາຕະລາງ Examples.
ໜຶ່ງໃນຈຸດເດັ່ນຄືຮອງຮັບພາສາທຳມະຊາດຫຼາຍກວ່າ 70 ພາສາລວມທັງພາສາຍີ່ປຸ່ນ, ແລະສາມາດ localize keyword ໄດ້ໂດຍກົງ.
ຄວາມສຳພັນກັບ BDD
Gherkin notation ເກີດຂຶ້ນຈາກ practice ຂອງ BDD (Behaviour-Driven Development). ໃນ BDD, ໃຫ້ຄວາມສຳຄັນກັບການອະທິບາຍ "ຊອບແວຄວນເຮັດຫຍັງ" ໃນຮູບແບບທີ່ຜູ້ມີສ່ວນໄດ້ສ່ວນເສຍທຸກຄົນສາມາດແບ່ງປັນໄດ້. Gherkin ເປັນການ standardize format ການອະທິບາຍດັ່ງກ່າວ, ໂດຍ framework ຢ່າງ Cucumber, Behave, ແລະ SpecFlow ຈະ parse ໄຟລ໌ Gherkin ແລ້ວ execute ການທົດສອບ.
ນັບຕັ້ງແຕ່ທີມຂອງຜູ້ຂຽນເລີ່ມຂຽນ acceptance test ດ້ວຍ Gherkin, ການສ້າງຄວາມເຫັນດີເຫັນພ້ອມໃນກອງປະຊຸມ review ລະຫວ່າງ QA ແລະນັກພັດທະນາວ່າ "ຖ້າ Scenario ນີ້ຜ່ານກໍ່ release ໄດ້" ໄດ້ໄວຂຶ້ນຢ່າງຫຼວງຫຼາຍ.
ຈຸດທີ່ຕ້ອງລະວັງໃນການນຳໃຊ້
ມັນບໍ່ແມ່ນວິທີແກ້ທຸກບັນຫາ. ຖ້າອອກແບບ granularity ຂອງ step definition (implementation code ທີ່ execute ຢູ່ເບື້ອງຫຼັງຂອງ Given/When/Then) ຜິດພາດ, step ທີ່ຄ້າຍຄືກັນຈະເພີ່ມຂຶ້ນຈຳນວນຫຼວງຫຼາຍ ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍໃນການບຳລຸງຮັກສາສູງຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ນອກຈາກນີ້, ການຂຽນ operation ລາຍລະອຽດຂອງ UI ໃນ Gherkin ທີລະຂັ້ນຕອນມີແນວໂນ້ມທີ່ຈະ verbose, ແລະໃນຫຼາຍກໍລະນີ, ການ apply ສະເພາະກັບການກວດສອບ business rule ແທນທີ່ຈະ Gherkin ize E2E test ທັງໝົດ ຈະໃຫ້ cost-effectiveness ທີ່ດີກວ່າ.
ບົດຄວາມທີ່ກ່າວເຖິງຄຳສັບນີ້
- AI Observability ແມ່ນຫຍັງ? ກົນໄກການຕິດຕາມ ແລະ ຄູ່ມືການປະຕິບັດງານ LLM ໃນສະພາບແວດລ້ອມຈິງຮຽນຮູ້ພື້ນຖານ AI Observability, ການຕິດຕາມ, ການປະເມີນຜົນ ແລະ ການຈັດການຕົ້ນທຶນສຳລັບ LLM, ພ້ອມຂັ້ນຕອນການນຳໃຊ້ ແລະ ການເລືອກເຄື່ອງມືທີ່ເໝາະສົມ.
- ຄູ່ມືການອອກແບບການປະເມີນຜົນ AI Agent — ການຮຽກໃຊ້ເຄື່ອງມື, ເສັ້ນທາງການປະຕິບັດງານ ແລະ ການກວດຫາການຖົດຖອຍ
- ວິທີການນຳ AI Agent ໄປໃຊ້ງານຈິງ: ຂັ້ນຕອນພາກປະຕິບັດຈາກການທົດລອງສູ່ການຂະຫຍາຍຂະບວນການ ຫຼື Pipeline ໃຫ້ເປັນມາດຕະຖານອະທິບາຍ 5 ອຸປະສັກ ແລະ ວິທີຜ່ານຜ່າໃນການນຳ AI Agent ຈາກຂະບວນການ ຫຼື Pipeline ທົດລອງສູ່ການໃຊ້ງານຈິງ ພ້ອມແນະນຳຂັ້ນຕອນການຈັດການລະບົບ ແລະ ອົງກອນ.
- ວິທີທີ່ທຸລະກິດຮ້ານອາຫານໃນໄທເລີ່ມນຳໃຊ້ AI ເພື່ອຄາດການຄວາມຕ້ອງການ, ປັບແຕ່ງຕາຕະລາງວຽກ ແລະ ຫຼຸດຜ່ອນການເສຍຫາຍຂອງວັດຖຸດິບອະທິບາຍຂັ້ນຕອນ ແລະ ກໍລະນີສຶກສາການນຳໃຊ້ AI ສຳລັບຮ້ານອາຫານໃນໄທ ເພື່ອຄາດການຄວາມຕ້ອງການ, ຈັດຕາຕະລາງພະນັກງານ, ຫຼຸດຜ່ອນສິ່ງເສດເຫຼືອ ແລະ ຈັດການການສັ່ງຊື້.
ຄຳສັບທີ່ກ່ຽວຂ້ອງ
ການທົດສອບ E2E
ການທົດສອບ E2E (End-to-End Testing) ແມ່ນວິທີການທົດສອບທີ່ເລີ່ມຕົ້ນຈາກການກະທຳຂອງຜູ້ໃຊ້ງານ ໂດຍຜ່ານ brows
ການທົດສອບການຮັບຮອງ
ການທົດສອບການຍອມຮັບ (Acceptance Test) ແມ່ນວິທີການທົດສອບທີ່ກວດສອບວ່າຟັງຊັນທີ່ພັດທະນາແລ້ວນັ້ນຕອບສະໜອງຄວ
SSM (AWS Systems Manager)
AWS Systems Manager (SSM) ແມ່ນ AWS Managed Service ທີ່ໃຊ້ສໍາລັບການດໍາເນີນງານ ແລະ ຈັດການ EC2 instance
ATDD
ATDD (Acceptance Test-Driven Development) ແມ່ນວິທີການພັດທະນາທີ່ທີມງານທັງໝົດກຳນົດເງື່ອນໄຂຂອງ acceptan