ชุดทดสอบที่ผ่านการทดสอบจะช่วยได้ก็ต่อเมื่อมันยังคงผ่านการทดสอบต่อไป ระบบการชำระเงินของคุณใช้งานได้ในวันนี้ แต่ dependency เกิดมี breaking change ตอนตี 2, ใบรับรองหมดอายุในช่วงสุดสัปดาห์, หรือ config drift ทำให้ payments endpoint ล่มในวันอาทิตย์ คุณจะรู้เรื่องนี้จากลูกค้าที่โกรธจัดแทนที่จะเป็นการทดสอบที่รันไม่ผ่าน การแก้ไขนั้นน่าเบื่อและเชื่อถือได้: รันการทดสอบ API ของคุณตามกำหนดเวลา โดยไม่ต้องมีคนกดปุ่ม และจะได้รับการแจ้งเตือนทันทีที่มีบางอย่างเสีย
Apidog มีคุณสมบัติ Scheduled Tasks (งานตามกำหนดการ) ในตัวสำหรับสิ่งนี้โดยเฉพาะ คุณเพียงแค่ชี้ไปยัง Test Scenarios ที่คุณสร้างไว้แล้ว กำหนดความถี่ เลือกเครื่องที่จะรัน และเชื่อมต่อการแจ้งเตือน คู่มือนี้จะอธิบายทั้งหมดอย่างตรงไปตรงมา รวมถึงข้อจำกัดในปัจจุบันด้วย หากคุณยังใหม่กับการรันการตรวจสอบอัตโนมัติกับ live endpoints บทความเบื้องต้นของเราเกี่ยวกับ การตรวจสอบ API จะให้บริบทที่กว้างขึ้น และ เอกสาร Apidog Scheduled Tasks เป็นแหล่งข้อมูลอ้างอิงสำหรับ UI
ข้อควรทราบอย่างรวดเร็วก่อนที่คุณจะเริ่ม คุณสมบัติ Scheduled Tasks ถูกระบุว่าเป็น Beta ในขณะนี้ และจำนวนการรันตามกำหนดการที่คุณจะได้รับขึ้นอยู่กับแผนของคุณ โปรดจำทั้งสองสิ่งนี้ไว้ขณะที่คุณอ่าน
Scheduled tasks ทำอะไร (และแตกต่างจาก scheduled scrapers อย่างไร)
Scheduled task ใน Apidog จะรัน Test Scenarios ที่บันทึกไว้ตั้งแต่หนึ่งรายการขึ้นไปตามรอบที่กำหนด ลองนึกถึงการทดสอบ regression ทุกคืนสำหรับ API หลักของคุณ, การทดสอบ smoke check ทุกสองสามชั่วโมงกับ staging, หรือการตรวจสอบสุขภาพในช่วงสุดสัปดาห์ งานนี้จะจดจำว่าต้องรัน scenario ใดบ้าง, ต้องเรียกใช้ environment ใด, บ่อยแค่ไหน, เครื่องใดจะดำเนินการ, และใครจะได้รับแจ้งเตือนเมื่อเกิดความล้มเหลว
หากคุณเคยเห็นวลี “scheduled tasks” ที่เกี่ยวข้องกับการ web scraping หรือการเก็บข้อมูล นั่นเป็นคนละเรื่องกัน คุณสมบัตินี้ไม่ใช่เกี่ยวกับการรวบรวมข้อมูลหน้าเว็บตามเวลาที่กำหนด มันอยู่ในโมดูล Tests และขับเคลื่อน Test Scenarios ของ API ของคุณ: assertions, chained requests, extracted variables และอื่นๆ ผลลัพธ์คือรายงานผ่าน/ไม่ผ่านเกี่ยวกับสัญญา API ของคุณ ไม่ใช่ชุดข้อมูลที่ถูกรวบรวม
ความแตกต่างนั้นสำคัญเพราะมันเปลี่ยนสิ่งที่คุณกำหนดค่า คุณไม่ได้เขียน selector หรือ crawl rules คุณกำลังเลือก Test Scenarios ที่มีอยู่และบอก Apidog ว่าจะรันเมื่อใดและที่ไหน
ก่อนเริ่มต้น: กำหนดค่า Self-hosted Runner
นี่คือข้อกำหนดเบื้องต้นที่ทำให้หลายคนสะดุด เพื่อรัน scheduled tasks คุณต้องกำหนดค่า Self-hosted Runner ก่อน เอกสารระบุไว้อย่างชัดเจน
Runner คือเครื่องที่ใช้ในการรันชุดทดสอบ เมื่อ scheduled task เริ่มทำงาน Apidog จะไม่รัน requests ในไคลเอนต์เดสก์ท็อปของคุณ แต่จะมอบหมายงานให้กับ Runner ที่คุณเลือก และทุก request ในชุดทดสอบจะถูกส่งจากเครื่องนั้น CI box, เซิร์ฟเวอร์ขนาดเล็กที่เปิดตลอดเวลา หรือ VM เฉพาะทาง ล้วนทำงานได้ดี สิ่งที่คุณเลือกจะยังคงทำงานและสามารถเข้าถึงได้ตามกำหนดเวลาที่คุณต้องการ
ช่องเป้าหมาย Runner มีสองทางเลือก: Apidog Cloud, ระบุว่า “coming soon,” หรือ Self-hosted Runner เนื่องจาก Apidog Cloud ยังไม่พร้อมใช้งาน Self-hosted Runner จึงเป็นทางเลือกเดียวที่ใช้งานได้ในปัจจุบัน อย่าเพิ่งวางแผนการรันบนคลาวด์จนกว่าจะเปิดตัว
เนื่องจาก requests มาจากเครื่องของ Runner สภาพแวดล้อมเครือข่ายจึงส่งผลต่อผลลัพธ์ของคุณ Runner ที่อยู่หลัง Corporate VPN, ในภูมิภาคที่แตกต่างกัน, หรือ Subnet ที่มีไฟร์วอลล์ อาจเห็นการตอบสนองที่แตกต่างจากแล็ปท็อปของคุณ ซึ่งโดยปกติแล้วเป็นสิ่งที่คุณต้องการสำหรับการตรวจสอบที่สมจริง แต่ก็ควรทราบเมื่อผลลัพธ์ของการรันตามกำหนดการไม่ตรงกับการรันในเครื่อง
ทีละขั้นตอน: สร้าง Scheduled Task
เมื่อลงทะเบียน Runner แล้ว ส่วนที่เหลือจะเกิดขึ้นในไคลเอนต์ ตัวอย่างการทำงานด้านล่างนี้เป็นชุด regression รายคืนสำหรับ e-commerce API ที่ครอบคลุมการสมัครสมาชิกผู้ใช้, การแสดงรายการสินค้า, ตะกร้าสินค้า และการชำระเงินที่สนับสนุนโดย Stripe
1. เปิด Scheduled Tasks ในโมดูล Tests
เปิดโมดูล Tests ใน Apidog client ในโครงสร้างโฟลเดอร์ Tests ให้คลิก Scheduled Tasks เพื่อดูและจัดการ Scheduled Tasks ทั้งหมดในโปรเจกต์ งานทั้งหมดในโปรเจกต์จะแสดงที่นี่ภายใต้ส่วน Scheduled Tasks ดังนั้นนี่คือที่เดียวที่คุณจะเห็นว่ามีอะไรกำลังทำงานอยู่และเมื่อใด
2. สร้าง Task
คลิก + New เพื่อสร้าง Scheduled Task ใหม่ คุณยังสามารถสร้างโฟลเดอร์ที่นี่เพื่อจัดกลุ่มงานที่เกี่ยวข้อง ซึ่งมีประโยชน์เมื่อคุณมีชุดทดสอบแยกต่างหากสำหรับ staging และ production หรือสำหรับบริการที่แตกต่างกัน
ตั้งชื่อ Task Name และ Description ที่ชัดเจนให้กับ task สิ่งเหล่านี้มีไว้เพื่อแยกแยะงานและอธิบายวัตถุประสงค์ เพื่อให้คุณในอนาคตทราบว่า “Nightly regression, prod” ครอบคลุมอะไรบ้างโดยไม่ต้องเปิดมัน แต่ละ task ยังมีปุ่มเปิด/ปิด (enable/disable toggle) และ tasks ในโครงสร้างสามารถเปิดหรือปิดได้ตลอดเวลา
3. เลือก Test Scenarios ที่จะรัน
ภายใต้ Test Scenario ให้เลือกหนึ่งหรือหลาย scenarios เพื่อรวมเข้าด้วยกัน สำหรับตัวอย่างอีคอมเมิร์ซ คุณอาจเลือก “Signup and login,” “Browse and add to cart,” และ “Checkout with Stripe test card” เพื่อให้ task เดียวครอบคลุมเส้นทางสำคัญทั้งหมด
แต่ละ scenario สามารถมีการตั้งค่าการรันของตัวเอง: Environment, test data, iterations, delay, และว่าจะบันทึก requests และ responses หรือไม่ หากคุณไม่ต้องการปรับแต่งแต่ละรายการ ให้เปิด Use same execution config เพื่อใช้การกำหนดค่ารันไทม์เดียวกับทุก scenario ที่เลือกในครั้งเดียว สิ่งนี้ช่วยให้ชุดทดสอบขนาดใหญ่มีความสอดคล้องกันและตั้งค่าได้อย่างรวดเร็ว
การเลือก Environment เป็นการตั้งค่าที่ผู้คนให้ความสำคัญมากที่สุด กำหนดให้การตรวจสอบ production รายคืนไปยัง environment ของ production ของคุณ และกำหนดให้การทดสอบ smoke test ก่อนการเปิดตัวไปยัง staging เนื่องจากแต่ละ scenario สามารถระบุ environment ของตัวเองได้ task เดียวจึงสามารถผสมผสานเป้าหมายได้หากคุณต้องการ แม้ว่าการรักษางานให้เป็น environment เดียวจะเข้าใจได้ง่ายกว่า
4. กำหนดรอบการรัน
ตั้งค่าช่อง run-schedule เป็นความถี่ที่คุณต้องการ ขึ้นอยู่กับหน้าจอที่คุณอยู่ ช่องนี้อาจอ่านว่า Run Cycle หรือ Run Mode; เป็นการตั้งค่าเดียวกัน และคำในฉลากจะแตกต่างกันไปใน UI เอกสารให้ตัวอย่างที่เป็นรูปธรรมที่คุณสามารถทำตามได้: ทุกวันอาทิตย์เวลา 23:00 น., ทุก 6 ชั่วโมง, หรือทุก 8 ชั่วโมง
สำหรับการ regression รายคืน การรันตอนดึกทุกวันจะช่วยลดเสียงรบกวนและตรวจจับปัญหาได้ก่อนวันทำงาน สำหรับการทดสอบ smoke test บน staging ทุก 6 ชั่วโมงจะให้ข้อเสนอแนะที่เร็วขึ้นโดยไม่รบกวน environment มากเกินไป
5. เลือกตำแหน่งที่จะรัน
ตั้งค่าช่อง runner ไปยัง Self-hosted Runner ของคุณ เช่นเดียวกับช่อง schedule ช่องนี้มีป้ายกำกับที่ไม่สอดคล้องกันในหน้าจอต่างๆ เช่น Runs on, Run On หรือ Runs On; ทั้งหมดมีความหมายเดียวกันคือเครื่องที่ใช้รันชุดทดสอบ Apidog Cloud ก็ปรากฏที่นี่เช่นกันแต่จะมาเร็วๆ นี้ ดังนั้นให้เลือก Self-hosted Runner ของคุณ หากคุณได้ลงทะเบียน Runners อเนกประสงค์หลายตัว ให้เลือกตัวที่คุณต้องการโดยเฉพาะ เช่น Runner ที่อยู่ใน VPC เดียวกันกับ API ของคุณ
โปรดจำไว้ว่า request ทั้งหมดที่เริ่มต้นในชุดทดสอบจะถูกส่งจากเครื่องที่ระบุไว้ที่นี่ ดังนั้นให้เลือก Runner ที่เครือข่ายของมันมองเห็น API ของคุณในแบบที่การเข้าชมจริงเห็น
6. เปิดการแจ้งเตือน
เปิดใช้งาน Notification เพื่อให้ task แจ้งเตือนคุณเมื่อมีสิ่งผิดปกติเกิดขึ้น เอกสารแนะนำสิ่งนี้สำหรับ scheduled tasks และเป็นหัวใจสำคัญของการรันอัตโนมัติ: ความเงียบควรหมายถึงความสำเร็จ และความล้มเหลวควรถึงคุณอย่างรวดเร็ว
Apidog รองรับช่องทางเหล่านี้ตามชื่อ: Slack, Teams, Webhook, Jenkins และ Email สำหรับ Email ที่อยู่ของสมาชิกโปรเจกต์จะเติมข้อความอัตโนมัติ และคุณสามารถพิมพ์ที่อยู่ที่ไม่ใช่สมาชิกด้วยตนเองสำหรับการหมุนเวียน on-call หรือกล่องจดหมายที่ใช้ร่วมกัน Slack จะส่งความล้มเหลวเข้าสู่ช่องทีมของคุณโดยตรง; ตัวเลือก Webhook ช่วยให้คุณสามารถกระจายไปยังสิ่งอื่น ๆ ที่คุณใช้งานได้ ตั้งแต่ PagerDuty ไปจนถึง custom endpoint
คุณยังสามารถเลือกเวลาที่การแจ้งเตือนจะทำงาน: หลังจากการรันทุกครั้ง หรือเฉพาะเมื่อเกิดความล้มเหลวเท่านั้น สำหรับชุดทดสอบรายคืนที่ทำงานได้ดี ตัวเลือกเฉพาะความล้มเหลวจะทำให้ช่องเงียบจนกว่าจะมีปัญหาเกิดขึ้น ในช่วงการเปิดตัวที่ไม่แน่นอน ตัวเลือกทุกการรันจะให้สัญญาณ heartbeat ที่ยืนยันว่างานกำลังถูกดำเนินการอยู่
7. บันทึกและเปิดใช้งาน
เปิดสวิตช์ของ task เพื่อเปิดใช้งาน แล้วมันจะเริ่มทำงานตามกำหนดเวลาที่คุณตั้งไว้ คุณสามารถปิดใช้งานได้ในภายหลังโดยไม่ต้องลบ ซึ่งมีประโยชน์ในช่วงที่ระบบหยุดทำงานตามแผน หรือช่วงการโยกย้ายที่อาจมีข้อผิดพลาดมาก
8. อ่านประวัติการรัน
หลังจากแต่ละครั้งที่รัน ผลลัพธ์จะถูกอัปโหลดโดยอัตโนมัติจาก Runner กลับไปยังเซิร์ฟเวอร์ เปิดส่วน Scheduled Tasks - Run History ในไคลเอนต์เพื่อดูข้อมูล นี่คือบันทึกการตรวจสอบของคุณ: การรันใดผ่าน, การรันใดล้มเหลว, assertion ใดที่ผิดพลาด และเมื่อใด เมื่อมีการแจ้งเตือนเข้ามาใน Slack, Run History คือที่ที่คุณจะไปดูรายละเอียดเบื้องหลัง
การตั้งค่าขั้นสูงและรูปแบบต่างๆ
เมื่อ task พื้นฐานทำงานได้แล้ว มีตัวเลือกไม่กี่อย่างที่ทำให้มันแข็งแกร่งขึ้น
Variable scope เมื่อ scenarios ของคุณส่งข้อมูลระหว่างการรัน Apidog ให้คุณสามระดับการแบ่งปัน จากเล็กสุดไปใหญ่สุด: Share only in the current test scenario ซึ่งเก็บ variable ไว้ในไฟล์เฉพาะสำหรับ scenario นั้นๆ; Share across all test scenarios in the current scheduled task ซึ่งให้ scenarios ใน task เดียวกันอ่านค่าของกันและกันได้; และ Share across all scheduled tasks in the current scheduled task folder ซึ่งเป็นขอบเขตที่กว้างที่สุด เลือกขอบเขตที่เล็กที่สุดที่ยังคงทำให้ข้อมูลของคุณไหลได้ เพื่อให้ auth token จาก scenario หนึ่งไม่รั่วไหลไปยัง scenario ที่ไม่เกี่ยวข้อง
Variable persistence ค่าจะถูกส่งต่อจากการรันหนึ่งไปยังอีกการรันหนึ่งก็ต่อเมื่อเปิดใช้งานตัวเลือก Keep variable values ในหน้าออกแบบ test scenario หากการรันรายคืนของคุณต้องการ Order ID ที่ถูกเก็บไว้เมื่อวานนี้หรือ token ที่ได้รับการรีเฟรช ให้เปิดใช้งานตัวเลือกนี้ หากไม่มี ตัวเลือกนี้ การรันแต่ละครั้งจะเริ่มต้นใหม่ และการอ้างอิงข้ามการรันใดๆ จะล้มเหลวอย่างเงียบๆ
การจัดกลุ่มด้วยโฟลเดอร์ เมื่อชุดทดสอบของคุณเติบโตขึ้น ให้สร้างโฟลเดอร์ภายใต้ Scheduled Tasks เพื่อแยกการตรวจสอบ production ออกจากการตรวจสอบก่อนการเปิดตัว ตัวแปรระดับโฟลเดอร์จะช่วยให้กลุ่มงานที่เกี่ยวข้องสามารถแชร์การตั้งค่าได้อย่างเป็นระเบียบ
Plan limits จำนวน scheduled runs ที่คุณได้รับขึ้นอยู่กับการสมัครสมาชิกของคุณ เอกสารชี้ไปยังหน้า Apidog pricing สำหรับตัวเลขที่แน่นอน ดังนั้นโปรดตรวจสอบแผนของคุณก่อนที่จะตั้งค่าความถี่ที่สูงมากทุกชั่วโมง หากคุณต้องการความครอบคลุมที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับการจัดกลุ่มและรูปแบบการกำหนดเวลาที่หนักขึ้น คู่มือ advanced scheduled tasks ของเราจะลงลึกยิ่งขึ้น และคู่มือที่เกี่ยวข้องเกี่ยวกับ conditional logic ใน API test scenarios จะช่วยคุณสร้าง scenarios ที่คุ้มค่ากับการกำหนดเวลาตั้งแต่แรก สำหรับทีมที่กำลังจะตั้งค่าการตรวจสอบอัตโนมัติครั้งแรก บทความ nightly API test runs in CI ก็เข้ากันได้ดีกับบทความนี้
ทำให้เวิร์กโฟลว์เป็นอัตโนมัติด้วย Apidog CLI
Scheduled Tasks UI เป็นวิธีหนึ่ง Apidog CLI เป็นวิธีที่สาม และเป็นวิธีที่แท้จริง: คุณรัน scenario ที่บันทึกไว้แบบ headless จากนั้นให้ cron หรือผู้ให้บริการ CI ของคุณจัดการความถี่ เพื่อความชัดเจน CLI ไม่มีคำสั่ง schedule ในตัว การกำหนดเวลาจะอยู่นอก Apidog ในเครื่องมือที่คุณเชื่อถืออยู่แล้วสำหรับ cron
ติดตั้งและยืนยันตัวตน จากนั้นรัน scenario โดยใช้ ID กับ environment ที่เลือก คู่มือการติดตั้ง Apidog CLI ครอบคลุมการตั้งค่า token อย่างครบถ้วน:
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, คั่นด้วยคอมมาสำหรับหลายตัว) หากต้องการรันทุกคืนด้วย cron ให้เพิ่มหนึ่งบรรทัด:
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 ที่กำหนดเวลาไว้ ไม่ว่าจะด้วยวิธีใด รายงาน JUnit จะถูกส่งเข้าสู่แดชบอร์ด pipeline ที่มีอยู่ของคุณ ดู Apidog CLI ใน CI/CD pipeline ของคุณ สำหรับการตั้งค่าทั้งหมด รวมถึง cron และ GitHub Actions schedule triggers
คำถามที่พบบ่อย
ฉันสามารถรัน scheduled tests บน Apidog Cloud ได้วันนี้หรือไม่? ยังไม่ได้ เป้าหมายของ Runner ระบุว่า Apidog Cloud กำลังจะมาถึง ดังนั้น Self-hosted Runner จึงเป็นเครื่องมือเดียวที่ใช้งานได้ในขณะนี้ ลงทะเบียน Runner ก่อน จากนั้นเลือกใน task
Scheduled tasks สามารถรันได้บ่อยแค่ไหน? บ่อยเท่าที่แผนของคุณอนุญาต ความถี่นั้นยืดหยุ่น โดยมีตัวอย่างในเอกสารเช่นทุก 6 ชั่วโมง หรือทุกวันอาทิตย์เวลา 23:00 น. แต่จำนวน scheduled runs ถูกจำกัดโดยการสมัครสมาชิกของคุณ ตรวจสอบหน้า Apidog pricing สำหรับขีดจำกัดที่แน่นอนของ tier ของคุณแทนที่จะคาดเดาตัวเลข
ฉันจะได้รับการแจ้งเตือนเฉพาะเมื่อการทดสอบล้มเหลวได้อย่างไร? ในการตั้งค่า Notification ของ task ให้เลือกตัวเลือก failures-only แทนที่จะเป็น every run จากนั้นเพิ่มช่องทาง: Slack, Teams, Webhook, Jenkins หรือ Email สิ่งนี้จะทำให้ช่องของคุณเงียบในคืนที่ไม่มีปัญหา และแจ้งเตือนเมื่อมีสิ่งผิดปกติเกิดขึ้น จับคู่กับ การตรวจสอบสุขภาพ API ที่เบาบางเพื่อให้ได้สัญญาณ liveness ที่รวดเร็วควบคู่ไปกับชุด regression ที่ลึกซึ้งยิ่งขึ้น
ทำไมผลลัพธ์ที่กำหนดเวลาไว้ของฉันจึงแตกต่างจากการรันทดสอบในเครื่องของฉัน? เพราะ request มาจากเครื่องของ Runner ไม่ใช่แล็ปท็อปของคุณ เครือข่าย, ภูมิภาค, และ VPN หรือไฟร์วอลล์ใดๆ ของมันส่งผลต่อการตอบสนอง ซึ่งเป็นเรื่องที่คาดหวัง และมักจะเป็นมุมมองที่สมจริงกว่าว่าผู้ใช้ของคุณพบเจออะไร
ตัวแปรของฉันรีเซ็ตทุกครั้งที่รัน ฉันพลาดอะไรไป? ตัวเลือก Keep variable values ในหน้าออกแบบ test scenario เปิดใช้งานเพื่อให้ค่าที่บันทึกไว้คงอยู่จากการรันหนึ่งไปยังอีกการรันหนึ่ง หากไม่มีตัวเลือกนี้ การรันตามกำหนดการแต่ละครั้งจะเริ่มต้นใหม่ และการอ้างอิงข้ามการรันใดๆ จะล้มเหลว
สรุป
การทดสอบตามกำหนดเวลาเปลี่ยนจาก “เราคิดว่า API ทำงานได้” เป็น “เรารู้ และเราคงได้ยินแล้วว่าถ้ามันไม่ทำงาน” สร้าง scenarios ของคุณเพียงครั้งเดียว ลงทะเบียน Self-hosted Runner กำหนด Run Cycle เชื่อมต่อ Slack หรืออีเมลเมื่อเกิดความล้มเหลว และปล่อยให้มันทำงานในขณะที่คุณนอนหลับ เมื่อคุณต้องการการตรวจสอบแบบเดียวกันภายใน pipeline, CLI บวกกับ cron จะให้เส้นทางที่สามแก่คุณโดยไม่ต้องใช้เครื่องมือเพิ่มเติม ดาวน์โหลด Apidog เพื่อตั้งค่าชุด regression ตามกำหนดเวลาแรกของคุณ เริ่มต้นได้ฟรี ไม่ต้องใช้บัตรเครดิต