วิธีตั้งเวลาทดสอบ API อัตโนมัติด้วย Apidog (Cloud, Runner และ CLI)

ชุดทดสอบจะมีประโยชน์ก็ต่อเมื่อยังผ่านการทดสอบอย่างต่อเนื่อง ระบบชำระเงินอาจทำงานได้วันนี้ แต่ dependency อาจมี breaking change ตอนตี 2, ใบรับรองหมดอายุช่วงสุดสัปดาห์ หรือ config drift ทำให้ payments endpoint ล่มในวันอาทิตย์ แทนที่จะรู้จากลูกค้าที่โกรธจัด ให้รัน API tests ตามกำหนดเวลาและรับการแจ้งเตือนทันทีเมื่อมีสิ่งผิดปกติ

ลองใช้ Apidog วันนี้

Apidog มีฟีเจอร์ Scheduled Tasks สำหรับรัน Test Scenarios ที่มีอยู่ตามรอบเวลา คุณเลือก scenario, กำหนดความถี่, เลือก Runner และตั้งค่าการแจ้งเตือนได้จาก UI เดียว หากต้องการบริบทเพิ่มเติมเกี่ยวกับการตรวจสอบ live endpoints โปรดดูบทความ การตรวจสอบ API และใช้ เอกสาร Apidog Scheduled Tasks เป็นข้อมูลอ้างอิงสำหรับ UI

ข้อควรทราบ: Scheduled Tasks อยู่ในสถานะ Beta และจำนวน scheduled runs ขึ้นอยู่กับแผนที่ใช้งาน

Scheduled Tasks ทำอะไร และต่างจาก Scheduled Scrapers อย่างไร

Scheduled Task ใน Apidog จะรัน Test Scenarios ที่บันทึกไว้ตั้งแต่หนึ่งรายการขึ้นไปตามเวลาที่กำหนด ตัวอย่างการใช้งาน:

• รัน regression test ทุกคืนกับ production API
• รัน smoke test ทุก 6 ชั่วโมงกับ staging
• ตรวจสอบ API ช่วงสุดสัปดาห์โดยไม่ต้องมีคนเริ่มรันเอง

Task จะเก็บการตั้งค่าหลักไว้ ได้แก่:

• Test Scenarios ที่ต้องรัน
• Environment ของแต่ละ scenario
• ความถี่ในการรัน
• Runner ที่ใช้ส่ง requests
• ช่องทางแจ้งเตือนเมื่อการทดสอบล้มเหลว

Scheduled Tasks ในบทความนี้ไม่ใช่ scheduled scraper หรือเครื่องมือเก็บข้อมูลเว็บ คุณไม่ต้องกำหนด CSS selector หรือ crawl rules แต่จะใช้ API Test Scenarios ที่มี assertions, chained requests, extracted variables และ configuration อื่น ๆ ที่สร้างไว้แล้ว ผลลัพธ์คือรายงานผ่าน/ไม่ผ่านสำหรับ API contract ของคุณ

ก่อนเริ่มต้น: ตั้งค่า Self-hosted Runner

Scheduled Tasks ต้องใช้ Self-hosted Runner ก่อนเริ่มใช้งาน

Runner คือเครื่องที่รันชุดทดสอบจริง เมื่อ task เริ่มทำงาน Apidog จะส่งงานไปยัง Runner ที่เลือก ไม่ได้รัน requests จาก Apidog desktop client บนเครื่องของคุณ ดังนั้น Runner อาจเป็น:

• CI server
• VM ที่เปิดใช้งานตลอดเวลา
• เซิร์ฟเวอร์ภายในองค์กร
• เครื่องใน VPC เดียวกับ API

ปัจจุบันตัวเลือก Runner มีทั้ง Apidog Cloud และ Self-hosted Runner แต่ Apidog Cloud แสดงสถานะว่า “coming soon” ดังนั้นทางเลือกที่ใช้งานได้คือ Self-hosted Runner

เลือกตำแหน่ง Runner ให้ตรงกับสภาพแวดล้อมที่ต้องการตรวจสอบ เพราะทุก request จะถูกส่งออกจาก Runner นั้น ตัวอย่างเช่น Runner ที่อยู่หลัง Corporate VPN, อยู่คนละภูมิภาค หรืออยู่ใน subnet ที่มี firewall อาจได้รับผลลัพธ์ไม่เหมือนกับการรันจากแล็ปท็อปของคุณ

ทีละขั้นตอน: สร้าง Scheduled Task

ตัวอย่างต่อไปนี้คือการตั้งค่า regression test รายคืนสำหรับ e-commerce API ที่ครอบคลุมการสมัครสมาชิกผู้ใช้, การดูสินค้า, ตะกร้าสินค้า และการชำระเงินผ่าน Stripe

1. เปิด Scheduled Tasks ในโมดูล Tests

ใน Apidog client:

1. เปิดโมดูล Tests
2. ในโครงสร้างโฟลเดอร์ Tests ให้เลือก Scheduled Tasks
3. ตรวจสอบรายการ task ที่มีอยู่ในโปรเจกต์

หน้านี้เป็นจุดรวมสำหรับดูว่างานใดกำลังทำงานอยู่ และงานใดจะรันเมื่อใด

2. สร้าง Task

คลิก + New เพื่อสร้าง Scheduled Task ใหม่

ตั้งค่าข้อมูลพื้นฐาน:

• Task Name — ใช้ชื่อที่ค้นหาและเข้าใจง่าย เช่น Nightly regression - production
• Description — ระบุขอบเขตการตรวจสอบ เช่น endpoints หรือ flows ที่ task นี้ครอบคลุม
• Enable/Disable — เปิดหรือปิด task ได้โดยไม่ต้องลบ

หากมีหลายชุดทดสอบ ให้สร้างโฟลเดอร์เพื่อแยกงาน เช่น:

Scheduled Tasks/
├── Production/
│   ├── Nightly regression
│   └── Weekend health check
└── Staging/
    ├── Smoke test - every 6 hours
    └── Pre-release regression

3. เลือก Test Scenarios ที่จะรัน

ในส่วน Test Scenario ให้เลือก scenario หนึ่งรายการหรือหลายรายการ

ตัวอย่างสำหรับ e-commerce flow:

• Signup and login
• Browse and add to cart
• Checkout with Stripe test card

แต่ละ scenario สามารถมี configuration ของตัวเอง เช่น:

• Environment
• Test data
• Iterations
• Delay
• การบันทึก requests และ responses

หากทุก scenario ต้องใช้ค่าเดียวกัน ให้เปิด Use same execution config เพื่อใช้ configuration เดียวกับ scenario ทั้งหมด

แนวทางแนะนำ:

• กำหนด production regression ให้ชี้ไปยัง production environment
• กำหนด staging smoke test ให้ชี้ไปยัง staging environment
• หลีกเลี่ยงการผสมหลาย environment ใน task เดียว หากไม่จำเป็น เพราะจะทำให้วิเคราะห์ผลลัพธ์ได้ยากขึ้น

4. กำหนดรอบการรัน

ตั้งค่า run schedule ตามความถี่ที่ต้องการ โดย UI อาจใช้ชื่อว่า Run Cycle หรือ Run Mode

ตัวอย่างรอบเวลา:

• ทุกวันอาทิตย์ เวลา 23:00 น.
• ทุก 6 ชั่วโมง
• ทุก 8 ชั่วโมง

ตัวอย่างการเลือกความถี่:

ประเภทการทดสอบ	ความถี่ที่เหมาะสม
Production regression	ทุกคืน
Staging smoke test	ทุก 6 ชั่วโมง
Weekend health check	ทุก 8 ชั่วโมงหรือรายวัน
Pre-release verification	ตามช่วงเวลาที่ทีมกำหนด

สำหรับ regression test รายคืน ควรเลือกเวลาที่มี traffic ต่ำเพื่อลดผลกระทบต่อระบบ สำหรับ staging ให้เลือกความถี่ที่ได้ feedback เร็วโดยไม่สร้างโหลดเกินจำเป็น

5. เลือก Runner

ในช่อง Runner ให้เลือก Self-hosted Runner ที่เตรียมไว้

UI อาจใช้ชื่อแตกต่างกัน เช่น:

• Runs on
• Run On
• Runs On

ทั้งหมดหมายถึงเครื่องที่จะใช้รันชุดทดสอบ

หากมี Runner หลายเครื่อง ให้เลือกตามตำแหน่งเครือข่ายที่ต้องการตรวจสอบ ตัวอย่างเช่น:

• เลือก Runner ใน VPC เดียวกับ private API
• เลือก Runner หลัง VPN เพื่อทดสอบ internal endpoints
• เลือก Runner ในภูมิภาคเดียวกับผู้ใช้หลัก

Requests ทุกตัวใน task จะออกจาก Runner ที่เลือก ดังนั้นควรเลือก Runner ที่เห็น API ในเงื่อนไขใกล้เคียงกับการใช้งานจริง

6. เปิดการแจ้งเตือน

เปิด Notification เพื่อให้ทีมทราบเมื่อ test run มีปัญหา

Apidog รองรับช่องทางแจ้งเตือนดังนี้:

• Slack
• Teams
• Webhook
• Jenkins
• Email

สำหรับ Email ระบบจะเติมอีเมลของสมาชิกโปรเจกต์ให้อัตโนมัติ และสามารถเพิ่มอีเมลภายนอกได้ เช่น shared inbox หรือ on-call rotation

เลือกช่วงเวลาที่ต้องการแจ้งเตือน:

• Every run — แจ้งผลหลังทุกรอบ
• Failures only — แจ้งเฉพาะเมื่อมีการทดสอบล้มเหลว

แนวทางใช้งาน:

• ใช้ Failures only สำหรับ nightly regression เพื่อลด notification noise
• ใช้ Every run ระหว่าง rollout หรือช่วงที่ต้องการยืนยันว่า task ยังทำงานอยู่

7. บันทึกและเปิดใช้งาน

บันทึก task แล้วเปิด enable toggle เพื่อเริ่มใช้งานตาม schedule ที่ตั้งไว้

หากมี planned maintenance, migration หรือช่วงที่ระบบคาดว่าจะล้มเหลวจำนวนมาก ให้ disable task ชั่วคราวแทนการลบ

8. ตรวจสอบ Run History

หลังการรัน Runner จะอัปโหลดผลลัพธ์กลับไปยังเซิร์ฟเวอร์

เปิด Scheduled Tasks - Run History เพื่อตรวจสอบ:

• การรันใดผ่านหรือล้มเหลว
• Assertion ใดไม่ผ่าน
• เวลาที่เริ่มและสิ้นสุดการรัน
• รายละเอียดของ request และ response ที่เกี่ยวข้อง

เมื่อได้รับแจ้งเตือนจาก Slack หรือ Email ให้เริ่มตรวจสอบจาก Run History เพื่อหา scenario และ assertion ที่เป็นต้นเหตุ

การตั้งค่าขั้นสูงและรูปแบบการใช้งาน

เลือก Variable Scope ให้เหมาะสม

หาก scenarios ต้องแชร์ข้อมูลระหว่างกัน Apidog มีระดับการแชร์ตัวแปร 3 ระดับ:

1. Share only in the current test scenario
   
   เก็บตัวแปรไว้เฉพาะ scenario ปัจจุบัน

2. Share across all test scenarios in the current scheduled task
   
   แชร์ตัวแปรให้ทุก scenario ภายใน task เดียวกัน

3. Share across all scheduled tasks in the current scheduled task folder
   
   แชร์ตัวแปรกับทุก task ในโฟลเดอร์เดียวกัน

เลือก scope ที่เล็กที่สุดที่ยังตอบโจทย์ flow ของคุณ เพื่อลดความเสี่ยงที่ข้อมูล เช่น auth token จะถูกนำไปใช้ใน scenario ที่ไม่เกี่ยวข้อง

เก็บค่า Variables ข้ามการรัน

หากต้องการให้ค่าตัวแปรอยู่ข้าม scheduled runs ให้เปิด Keep variable values ในหน้าออกแบบ test scenario

ตัวอย่างกรณีที่อาจต้องเปิด:

• ต้องใช้ Order ID ที่สร้างจากการรันก่อนหน้า
• ต้องเก็บ token ที่ refresh แล้ว
• มี state ที่ต้องส่งต่อระหว่างรอบการทดสอบ

หากไม่ได้เปิดตัวเลือกนี้ แต่ละ scheduled run จะเริ่มต้นด้วยค่าใหม่ และการอ้างอิงข้อมูลจากรอบก่อนหน้าอาจล้มเหลว

จัดกลุ่ม Tasks ด้วยโฟลเดอร์

เมื่อจำนวน task เพิ่มขึ้น ให้ใช้โฟลเดอร์เพื่อแยกตาม environment หรือบริการ เช่น:

Production/
  Payments
  Authentication
  Catalog

Staging/
  Smoke tests
  Pre-release checks

ตัวแปรระดับโฟลเดอร์ช่วยให้กลุ่ม task ที่เกี่ยวข้องแชร์ configuration ได้อย่างเป็นระเบียบ

ตรวจสอบ Plan Limits

จำนวน scheduled runs ขึ้นอยู่กับแผนการสมัครใช้งาน ตรวจสอบข้อจำกัดของแผนก่อนตั้ง task ที่รันถี่มาก เช่น ทุกชั่วโมง

สำหรับรูปแบบที่ซับซ้อนขึ้น ดูคู่มือ advanced scheduled tasks, conditional logic ใน API test scenarios และ nightly API test runs in CI

ทำให้เวิร์กโฟลว์เป็นอัตโนมัติด้วย Apidog CLI

Scheduled Tasks UI เป็นทางเลือกหนึ่งสำหรับการตั้งเวลา อีกทางเลือกคือ Apidog CLI ซึ่งให้คุณรัน Test Scenario แบบ headless แล้วใช้ cron หรือ CI provider จัดการ schedule

CLI ไม่มีคำสั่ง schedule ในตัว การกำหนดเวลาจะอยู่ในเครื่องมือภายนอก เช่น cron หรือ GitHub Actions

ติดตั้ง CLI, ยืนยันตัวตน และรัน scenario ด้วย Test Scenario ID และ Environment ID:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli,junit

พารามิเตอร์หลัก:

• -t — Test Scenario ID
• -e — Environment ID
• -r — Reporter เช่น cli, html, หรือ junit

สามารถระบุ reporter หลายตัวโดยคั่นด้วยคอมมา

ตัวอย่าง cron สำหรับรันทุกวันเวลา 02:00 น.:

0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1

หรือใช้ GitHub Actions schedule trigger เพื่อรันใน pipeline ที่มีอยู่ รายงาน JUnit สามารถส่งต่อไปยัง dashboard ของ pipeline ได้

ดูรายละเอียดเพิ่มเติมในคู่มือ การติดตั้ง Apidog CLI, Apidog CLI ใน CI/CD pipeline ของคุณ และ GitHub Actions schedule triggers

คำถามที่พบบ่อย

ฉันสามารถรัน scheduled tests บน Apidog Cloud ได้วันนี้หรือไม่?

ยังไม่ได้ Apidog Cloud แสดงสถานะว่า coming soon ดังนั้นปัจจุบันต้องใช้ Self-hosted Runner ลงทะเบียน Runner ก่อน แล้วเลือก Runner นั้นใน task

Scheduled Tasks รันได้บ่อยแค่ไหน?

ความถี่ขึ้นอยู่กับการตั้งค่าที่คุณเลือกและจำนวน scheduled runs ที่แผนของคุณรองรับ เอกสารมีตัวอย่าง เช่น ทุก 6 ชั่วโมง หรือทุกวันอาทิตย์เวลา 23:00 น. ตรวจสอบแผนที่ใช้งานเพื่อดูขีดจำกัดที่แน่นอน

ฉันจะรับแจ้งเตือนเฉพาะเมื่อการทดสอบล้มเหลวได้อย่างไร?

ในการตั้งค่า Notification ของ task ให้เลือก Failures only จากนั้นเลือกช่องทางที่ต้องการ เช่น Slack, Teams, Webhook, Jenkins หรือ Email

สำหรับการตรวจสอบที่เบากว่า ควบคู่กับ regression suite ให้ดูแนวทาง การตรวจสอบสุขภาพ API

ทำไมผลการรันตามกำหนดเวลาจึงต่างจากการรันในเครื่อง?

Scheduled Task ส่ง requests จาก Runner ไม่ใช่แล็ปท็อปของคุณ ดังนั้นเครือข่าย, ภูมิภาค, VPN และ firewall ของ Runner อาจทำให้ผลลัพธ์แตกต่างกัน

ทำไมตัวแปรของฉันรีเซ็ตทุกครั้งที่รัน?

ตรวจสอบว่าเปิด Keep variable values ในหน้าออกแบบ test scenario แล้วหรือไม่ หากไม่ได้เปิด แต่ละ scheduled run จะเริ่มต้นใหม่ และค่าใดที่ต้องใช้ข้ามรอบจะไม่ถูกเก็บไว้

สรุป

Scheduled testing เปลี่ยนสถานะจาก “เราคิดว่า API ยังทำงานได้” เป็น “เรารู้ว่า API ยังทำงานได้ และจะได้รับแจ้งเตือนเมื่อมันไม่ทำงาน”

เริ่มต้นด้วยขั้นตอนนี้:

1. สร้าง Test Scenarios สำหรับ flows สำคัญ
2. ลงทะเบียน Self-hosted Runner
3. สร้าง Scheduled Task และกำหนด Run Cycle
4. เลือก Runner ที่เข้าถึง API ได้ตามเงื่อนไขจริง
5. ตั้งค่า Slack, Email หรือ Webhook สำหรับ failures
6. ใช้ Run History เพื่อตรวจสอบรายละเอียดเมื่อมี alert

หากต้องการรันชุดทดสอบใน CI pipeline ให้ใช้ Apidog CLI ร่วมกับ cron หรือ GitHub Actions ดูข้อมูลเพิ่มเติมและเริ่มต้นได้ที่ Apidog