ชุดทดสอบ API ของคุณจะมีประโยชน์ก็ต่อเมื่อมันทำงานตามกำหนดเวลาที่คุณเชื่อถือได้ ชุดการทดสอบที่คุณเรียกใช้ด้วยตนเองจะตรวจพบบั๊กเมื่อคุณจำได้ว่าต้องคลิก การรันในเวลากลางคืนบนเครื่องที่คุณควบคุมจะตรวจพบบั๊กเหล่านั้นตอนตี 2 ก่อนที่ผู้ใช้ของคุณจะเจอ นั่นคือหน้าที่ของ Apidog runner: บริการที่ติดตั้งเอง (self-deployed) ติดตั้งด้วย Docker บนเซิร์ฟเวอร์ของคุณเอง ซึ่งจะรันสถานการณ์การทดสอบตามกำหนดเวลาที่คุณสร้างใน Apidog และส่งรายงานกลับไปยังโปรเจกต์ของคุณ
เราได้กล่าวถึงสามวิธีในการกำหนดเวลาการทดสอบใน Apidog ใน คู่มือการกำหนดเวลาการทดสอบ API แบบอัตโนมัติ ของเราแล้ว บทความนั้นเปรียบเทียบการประมวลผลบนคลาวด์ ตัวรัน และ CLI ในภาพรวม บทความนี้จะเจาะลึกเกี่ยวกับเส้นทางของตัวรัน: เมื่อคุณต้องการมัน วิธีการปรับใช้ วิธีการชี้งานตามกำหนดเวลาไปยังมัน และเปรียบเทียบกับทางเลือกอื่น ๆ
เมื่อคุณต้องการตัวรันการทดสอบที่โฮสต์ด้วยตัวเอง (self-hosted test runner)
การประมวลผลบนคลาวด์นั้นสะดวกสบาย แต่สามสถานการณ์ต่อไปนี้ทำให้ทีมต่างๆ หันมาใช้ตัวรันการทดสอบที่โฮสต์ด้วยตัวเอง
API ของคุณอยู่บนเครือข่ายส่วนตัว สภาพแวดล้อมการทำงาน (staging environment) ที่ https://orders.staging.internal:8443 ไม่สามารถเข้าถึงได้จากอินเทอร์เน็ตสาธารณะ ไม่มีบริการคลาวด์ใดที่สามารถเข้าถึงได้ ตัวรันที่ปรับใช้ภายใน VPC หรือเครือข่ายสำนักงานของคุณสามารถทำได้ เนื่องจากมันทำการร้องขอจากตำแหน่งที่ตั้งของมัน นี่คือเหตุผลเดียวกันกับการรัน mock server ที่โฮสต์ด้วยตัวเองบนอินทราเน็ตของคุณ: ปริมาณงานจะต้องอยู่ในที่ที่มีการเข้าถึงเครือข่าย
ข้อกำหนดการปฏิบัติตามกฎระเบียบ (Compliance) ทำให้การรับส่งข้อมูลอยู่ในองค์กร หากทีมรักษาความปลอดภัยของคุณห้ามไม่ให้เพย์โหลดการทดสอบที่มีข้อมูลลูกค้าจริงหลุดออกจากโครงสร้างพื้นฐานของคุณ การประมวลผลบนคลาวด์จะถูกตัดออกไป ด้วยตัวรัน คำขอจะมาจากเซิร์ฟเวอร์ของคุณและเข้าถึง API ของคุณโดยตรง มีเพียงรายงานการทดสอบเท่านั้นที่จะเดินทางกลับไปยัง Apidog
คุณต้องการกำหนดเวลาที่เสถียรโดยไม่ขึ้นกับแล็ปท็อปเครื่องใดๆ การทดสอบที่กำหนดเวลาไว้ในแอปเดสก์ท็อปจะหยุดทำงานเมื่อแอปปิด การทดสอบที่เชื่อมโยงกับ CI จะทำงานเมื่อมีคนพุชโค้ด ไม่มีทั้งสองอย่างที่ให้คุณ “ทุก 6 ชั่วโมง ตลอดไป ไม่ว่าอะไรจะเกิดขึ้น” ตัวรันบนเซิร์ฟเวอร์ที่เปิดตลอดเวลาสามารถทำสิ่งนี้ได้อย่างแม่นยำ
หากไม่มีกรณีใดที่กล่าวมาข้างต้น คุณอาจไม่จำเป็นต้องใช้ตัวรัน การรันด้วยตนเองในแอปหรือ CLI ใน CI จะเพียงพอสำหรับคุณ
Apidog runner คืออะไร
ตัวรันที่โฮสต์ด้วยตัวเอง เป็นบริการอัตโนมัติที่คุณปรับใช้บนเซิร์ฟเวอร์อิสระ เมื่อเชื่อมต่อกับทีมของคุณแล้ว มันสามารถ:
- รันงานทดสอบอัตโนมัติที่กำหนดเวลาไว้ซึ่งสร้างขึ้นจากสถานการณ์การทดสอบ Apidog ของคุณ
- นำเข้าเอกสาร API ตามกำหนดเวลาที่เกิดซ้ำ
- ให้บริการ mock response ที่โฮสต์ด้วยตัวเอง
มันมาในสองขอบเขต ตัวรันทั่วไประดับทีม (team-level general runner) เป็นของทีมเดียว ตัวรันระดับองค์กร (organization-level runner) สามารถแชร์ได้ทั่วทั้งโปรเจกต์ในทีมขององค์กรของคุณ การปรับใช้ทำงานในลักษณะเดียวกันสำหรับทั้งสองประเภท
แนวคิดหลักที่สำคัญ: ตัวรันเป็นผู้ปฏิบัติงาน (worker) ไม่ใช่สำเนาของโปรเจกต์ของคุณ สถานการณ์การทดสอบ สภาพแวดล้อม และการยืนยันของคุณยังคงอยู่ใน Apidog ตัวรันจะได้รับงาน ดำเนินการกับเครือข่ายใดก็ตามที่มันสามารถเข้าถึงได้ และอัปโหลดผลลัพธ์ สมาชิกในทีมไม่เคย SSH เข้าไปเพื่อดูว่าเกิดอะไรขึ้น พวกเขาจะเปิดประวัติการรันในแอป
ข้อกำหนดเบื้องต้น
ตรวจสอบสิ่งเหล่านี้ก่อนที่คุณจะปรับใช้ มันมาจาก เอกสารสภาพแวดล้อมการปรับใช้ตัวรัน โดยตรง
ฮาร์ดแวร์ CPU อย่างน้อย 2 คอร์ และ RAM 4 GB; แนะนำ 4+ คอร์ และ 8 GB หากคุณจะรันงานพร้อมกัน (concurrent tasks) หรือมีทีมขนาดใหญ่ จัดสรรพื้นที่ดิสก์อย่างน้อย 30 GB สำหรับล็อกและสิ่งประดิษฐ์การทดสอบ (test artifacts) และ 50 GB เพื่อความสบายใจ
Docker โฮสต์ต้องมี Docker เวอร์ชัน 20.10.0 หรือใหม่กว่า โดยแนะนำ 20.10.13 หากเซิร์ฟเวอร์ยังใหม่ ให้ทำตาม คู่มือการติดตั้ง Docker Engine อย่างเป็นทางการ สำหรับการแจกจ่ายของคุณก่อน
เครือข่าย ตัวรันสื่อสารกับเซิร์ฟเวอร์ Apidog ผ่าน HTTPS บนพอร์ต 443 และเปิดการเชื่อมต่อ WebSocket (WSS) สำหรับการส่งงานแบบเรียลไทม์ นอกจากนี้ยังต้องการการเข้าถึงขาออก (outbound access) ไปยังโดเมน AWS ที่ใช้สำหรับการอัปโหลดรายงาน และแน่นอนว่าต้องมีการเข้าถึงเครือข่ายไปยัง API ทุกตัวที่การทดสอบของคุณกำหนดเป้าหมาย สังเกตทิศทางที่นี่: ตัวรันโทรออก คุณไม่จำเป็นต้องเปิดพอร์ตขาเข้าเพื่อให้ Apidog เข้าถึงได้ ซึ่งทำให้การสนทนาเกี่ยวกับไฟร์วอลล์กับทีมปฏิบัติการของคุณสั้นลง
สิทธิ์และแผน การปรับใช้ตัวรันเป็นการดำเนินการที่เกี่ยวข้องกับทรัพยากรของทีม ดังนั้นคุณจะต้องมีบทบาทของทีมที่เหมาะสม จำนวนการรันงานตามกำหนดเวลาที่คุณได้รับขึ้นอยู่กับระดับการสมัครสมาชิกของคุณ; ตรวจสอบ หน้าการกำหนดราคา Apidog สำหรับขีดจำกัดปัจจุบันต่อแผน
ขั้นตอนที่ 1: รับคำสั่งปรับใช้จาก Apidog
Apidog สร้างคำสั่งปรับใช้ Docker ให้คุณ โดยมีโทเค็นการยืนยันตัวตนรวมอยู่ด้วย อย่าคัดลอกคำสั่งจากบล็อกโพสต์ รวมถึงบทความนี้ด้วย; โทเค็นคือสิ่งที่เชื่อมโยงคอนเทนเนอร์เข้ากับทีมของคุณ
- เปิด Apidog และไปที่หน้าแรกของ Apidog หากคุณยังไม่มีบัญชี ให้ ดาวน์โหลด Apidog ฟรีเพื่อทำตาม
- เลือกทีมที่ตัวรันควรเป็นสมาชิก
- คลิก Resources (ทรัพยากร) ทางด้านขวา
- คลิก Deploy General Runner (ปรับใช้ตัวรันทั่วไป)
หน้าต่างป๊อปอัปจะแสดงคำสั่งปรับใช้ฉบับเต็ม คัดลอกทันที: มันมีโทเค็นที่ละเอียดอ่อนและจะแสดงเพียงครั้งเดียวเท่านั้น ปฏิบัติต่อมันเหมือนรหัสลับ CI ไม่ใช่โค้ดสำหรับ Wiki ของทีมคุณ
ก่อนคัดลอก กล่องโต้ตอบช่วยให้คุณสามารถปรับแต่งคำสั่งได้:
- Server OS (ระบบปฏิบัติการเซิร์ฟเวอร์): Linux, macOS, หรือ Windows
- Image variant (รูปแบบอิมเมจ): General มาพร้อมกับ Node.js 18, Java 21, Python 3 และ PHP 8 ดังนั้นสคริปต์ pre/post-processor ในภาษาเหล่านี้จึงทำงานได้โดยไม่ต้องตั้งค่าเพิ่มเติม Slim มีเฉพาะ Node.js 18 และดึงได้เร็วกว่า Custom ให้คุณระบุ Dockerfile ของคุณเองเมื่อการทดสอบขึ้นอยู่กับใบรับรอง CA ภายในหรือไลบรารีที่ผิดปกติ
- Exposed port (พอร์ตที่เปิดเผย): แมปพอร์ตด้วย
-p(เช่น-p 80:4524) หากคุณจะใช้ตัวรันสำหรับ mock ที่โฮสต์ด้วยตัวเองด้วย - Mounted data directory (ไดเรกทอรีข้อมูลที่เมาท์): เพิ่มการเมาท์วอลุ่ม
-vหากสถานการณ์การทดสอบของคุณอ่านไฟล์ข้อมูลในเครื่อง เช่น ชุดข้อมูล CSV สำหรับการรันที่ขับเคลื่อนด้วยข้อมูล
เอกสารตัวรันทั่วไป ครอบคลุมแต่ละตัวเลือกโดยละเอียด
ขั้นตอนที่ 2: รันคอนเทนเนอร์และยืนยันว่าเชื่อมต่อแล้ว
SSH เข้าสู่เซิร์ฟเวอร์เป้าหมาย วางคำสั่ง และปล่อยให้ Docker ดึงอิมเมจและเริ่มคอนเทนเนอร์ ข้อควรจำสองข้อในการปฏิบัติงานที่ควรตั้งค่าตั้งแต่วันแรก:
- ส่ง
TZเป็นตัวแปรสภาพแวดล้อม (เช่นTZ=Asia/Singapore) เพื่อให้ "ทุกวันเวลา 02:00" หมายถึง 02:00 น. ของคุณ ไม่ใช่ค่าเริ่มต้นของคอนเทนเนอร์ - จากตัวรันเวอร์ชัน 2.2.5 อิมเมจมีผู้ใช้
runnerที่ไม่ใช่ root (UID/GID 10001) หากแพลตฟอร์มของคุณบังคับใช้runAsNonRootให้ตั้งค่า security context ให้เหมาะสมและกำหนดค่าสิทธิ์ของวอลุ่มล่วงหน้า เนื่องจาก entrypoint ไม่สามารถเปลี่ยนเจ้าของไดเรกทอรีในโหมด non-root ได้
กลับไปที่ Apidog ตัวรันจะปรากฏภายใต้ Resources ของทีมคุณเมื่อการเชื่อมต่อ WebSocket (WebSocket handshake) สมบูรณ์ และสมาชิกในทีมสามารถเลือกได้เมื่อสร้างงาน หากไม่ปรากฏภายในหนึ่งนาที ให้ตรวจสอบล็อกของคอนเทนเนอร์ด้วย docker logs และยืนยันว่าโฮสต์สามารถเข้าถึงเซิร์ฟเวอร์ Apidog บนพอร์ต 443 ได้; การเชื่อมต่อ WSS ที่ถูกบล็อกมักเป็นสาเหตุหลักบนเครือข่ายองค์กรที่ถูกจำกัด
คุณสามารถปรับใช้ตัวรันหลายตัวในทีมเดียวได้ ทีมมักจะเก็บตัวรันหนึ่งตัวไว้ภายใน staging VPC และอีกตัวหนึ่งที่มีสิทธิ์เข้าถึงข้อมูลการผลิต จากนั้นเลือกตามงาน
ขั้นตอนที่ 3: สร้างงานตามกำหนดเวลาที่กำหนดเป้าหมายไปยังตัวรัน
เมื่อตัวรันออนไลน์อยู่ การกำหนดเวลาจะเป็นรูปแบบ ไม่ใช่สคริปต์
- ในโปรเจกต์ของคุณ ให้เปิดโมดูล Tests (การทดสอบ) และคลิก Scheduled Tasks (งานตามกำหนดเวลา) งานจะอยู่ในโครงสร้างโฟลเดอร์ ดังนั้นจัดกลุ่มตามบริการหรือสภาพแวดล้อมเมื่อรายการเพิ่มขึ้น
- สร้างงานและตั้งชื่อที่เพื่อนร่วมทีมจะเข้าใจในอีกหกเดือนข้างหน้า: “Orders service smoke, staging, every 6h” ดีกว่า “test1”
- เลือกสถานการณ์การทดสอบหนึ่งรายการขึ้นไป สำหรับแต่ละสถานการณ์ คุณสามารถตั้งค่าสภาพแวดล้อม ข้อมูลการทดสอบ จำนวนการวนซ้ำ ความล่าช้าระหว่างคำขอ และว่าจะบันทึกเนื้อหาคำขอ/การตอบกลับหรือไม่
- ตั้งค่าสภาพแวดล้อมและขอบเขตของตัวแปร การใช้ตัวแปรกับทุกสถานการณ์ภายในงานเป็นทางเลือกที่ดีที่สุด; ขอบเขตทั่วทั้งโฟลเดอร์มีประสิทธิภาพแต่ใช้งานผิดพลาดได้ง่าย
- ตั้งค่า Run Cycle (รอบการรัน): ทุกวันอาทิตย์เวลา 23:00 น. ทุก 6 ชั่วโมง หรือตามความเหมาะสมกับความรวดเร็วที่คุณต้องการทราบว่ามีอะไรเสีย
- ภายใต้ Runs on (รันบน) ให้เลือกตัวรันที่โฮสต์ด้วยตัวเองของคุณตามชื่อ
- กำหนดค่าการแจ้งเตือน คุณสามารถแจ้งเตือนหลังจากการรันทุกครั้งหรือเฉพาะเมื่อล้มเหลวเท่านั้น การแจ้งเตือนเฉพาะเมื่อล้มเหลวเป็นค่าเริ่มต้นที่ดีที่สุด; ช่องที่เต็มไปด้วยเครื่องหมายถูกสีเขียวจะทำให้ทุกคนเพิกเฉย
บันทึกมัน ตั้งแต่จุดนี้เป็นต้นไป กำหนดเวลาจะทำงานบนเซิร์ฟเวอร์ของคุณไม่ว่าใครจะเปิดแอป Apidog อยู่หรือไม่ก็ตาม
ขั้นตอนที่ 4: อ่านรายงานการรันใน Apidog
หลังจากการรันแต่ละครั้ง ตัวรันจะอัปโหลดผลลัพธ์ไปยังเซิร์ฟเวอร์ Apidog โดยอัตโนมัติ เปิด Scheduled Tasks → Run History (งานตามกำหนดเวลา → ประวัติการรัน) ในแอปเพื่อดูการดำเนินการทั้งหมด: สถานะผ่าน/ไม่ผ่าน ผลลัพธ์ต่อสถานการณ์ ความล้มเหลวในการยืนยัน และเวลา
นี่คือข้อได้เปรียบที่เงียบของตัวรันเหนือการตั้งค่า cron-plus-scripts ที่สร้างขึ้นเอง การดำเนินการเกิดขึ้นบนโครงสร้างพื้นฐานของคุณ แต่การรายงานจะอยู่ในพื้นที่ทำงานที่แชร์เดียวกันกับที่กำหนดการทดสอบ เมื่อการรันเวลา 02:00 น. ของวันอังคารล้มเหลว วิศวกร QA ที่ตรวจสอบจะเห็นว่าการยืนยันใดล้มเหลวในขั้นตอนใด ในบริบท โดยไม่ต้องค้นหาไฟล์ล็อกบนเซิร์ฟเวอร์
จับคู่การแจ้งเตือนความล้มเหลวกับประวัติการรัน และคุณจะมีวงจรการตรวจสอบ: การแจ้งเตือนดังขึ้น เปิดรายงาน ทำซ้ำขั้นตอนที่ล้มเหลวด้วยตนเองในแอปในสภาพแวดล้อมเดียวกัน แก้ไข และรอการรันที่ผ่านครั้งต่อไป
ตัวรัน เทียบกับ CLI เทียบกับคลาวด์: การเลือกเส้นทางการดำเนินการ
Apidog มีสามวิธีในการดำเนินการทดสอบนอกเหนือจากการคลิกด้วยตนเองในแอป และวิธีการเหล่านี้แก้ปัญหาที่แตกต่างกันไป เราได้เขียนคำแนะนำโดยละเอียดเกี่ยวกับเส้นทาง CI ใน คู่มือ Apidog CLI GitHub Actions ของเรา และการเปรียบเทียบด้านล่างแสดงให้เห็นว่าแต่ละวิธีเหมาะสมกับอะไร
| Self-hosted runner (ตัวรันที่โฮสต์ด้วยตัวเอง) |
Apidog CLI in CI (Apidog CLI ใน CI) |
Cloud execution (การประมวลผลบนคลาวด์) |
|
|---|---|---|---|
| Trigger (ตัวกระตุ้น) |
Time-based schedule (กำหนดเวลาตามเวลา) |
Code push, PR, or pipeline schedule (การพุชโค้ด, PR, หรือกำหนดเวลาของ pipeline) |
Run from the app (รันจากแอป) |
| Runs on (รันบน) |
Your server (Docker) (เซิร์ฟเวอร์ของคุณ (Docker)) |
Your CI workers (CI workers ของคุณ) |
Apidog’s infrastructure (โครงสร้างพื้นฐานของ Apidog) |
| Reaches intranet APIs (เข้าถึง API อินทราเน็ตได้) |
Yes (ได้) |
Yes, if CI runners are inside the network (ได้, หาก CI runners อยู่ภายในเครือข่าย) |
No (ไม่ได้) |
| Data stays in-house (ข้อมูลอยู่ในองค์กร) |
Yes, only reports leave (ได้, มีเพียงรายงานเท่านั้นที่ออกไป) |
Yes (ได้) |
No (ไม่ได้) |
| Setup effort (ความพยายามในการตั้งค่า) |
One Docker deploy per team (ปรับใช้ Docker หนึ่งครั้งต่อทีม) |
Per-pipeline YAML (YAML ต่อ pipeline) |
None (ไม่มี) |
| Reports (รายงาน) |
Run history in Apidog (ประวัติการรันใน Apidog) |
CLI/HTML/JSON output, uploadable (เอาต์พุต CLI/HTML/JSON, อัปโหลดได้) |
In Apidog (ใน Apidog) |
| Best for (ดีที่สุดสำหรับ) |
Recurring health checks on private APIs (การตรวจสอบสุขภาพ API ส่วนตัวซ้ำๆ) |
Gating deploys on test results (การจำกัดการปรับใช้ตามผลการทดสอบ) |
Quick runs on public APIs (การรันด่วนบน API สาธารณะ) |
เส้นทางเหล่านี้เสริมกันมากกว่าที่จะแข่งขันกัน การตั้งค่าทั่วไป: CLI จำกัดการปรับใช้ทุกครั้งใน pipeline ในขณะที่ตัวรันดำเนินการ smoke suite รายชั่วโมงกับ staging และ full regression กลางคืน ตรวจจับความล้มเหลวที่เกิดจากการเปลี่ยนแปลงโครงสร้างพื้นฐานและการหมดอายุของข้อมูลรับรอง มากกว่าการเปลี่ยนแปลงโค้ด
ข้อควรระวังหนึ่งข้อเกี่ยวกับเวลา: ตาม เอกสารงานตามกำหนดเวลา งานตามกำหนดเวลาถูกออกแบบมาให้รันบนตัวรันที่โฮสต์ด้วยตัวเอง โดยมี Apidog Cloud เป็นตัวเลือกเมื่อมีการเปิดให้บริการ หากคุณต้องการการดำเนินการตามกำหนดเวลาในวันนี้และไม่สามารถรอการเปิดให้บริการคลาวด์สำหรับแผนของคุณได้ ตัวรันคือเส้นทางที่เชื่อถือได้
คำถามที่พบบ่อย
ฉันจำเป็นต้องใช้ตัวรันหรือไม่ หากฉันใช้ Apidog CLI ใน CI อยู่แล้ว
คำถามทั้งสองนี้แตกต่างกัน CI บอกคุณว่า "การเปลี่ยนแปลงนี้ทำให้ API เสียหายหรือไม่" ในเวลาที่มีการพุชโค้ด ตัวรันบอกคุณว่า "API ยังคงทำงานได้ดีอยู่หรือไม่ในตอนนี้" ในรอบเวลาที่กำหนด โดยจับความล้มเหลวที่เกิดจากโทเค็นหมดอายุ การพึ่งพาที่หยุดทำงาน หรือการเปลี่ยนแปลงโครงสร้างพื้นฐานที่ไม่ได้มาจากการคอมมิตโค้ด หลายทีมใช้ทั้งสองอย่าง; ดู คู่มือการตั้งค่าการทดสอบ API กลางคืน ของเราสำหรับครึ่งหนึ่งของรูปแบบที่กำหนดเวลาโดย CI
ตัวรันสามารถเข้าถึง API อินทราเน็ตได้หรือไม่
ได้ และนี่คือเหตุผลหลักในการมีอยู่ของมัน ตัวรันจะทำการร้องขอจากเครื่องที่ติดตั้งไว้ หากคุณวางไว้ใน VPC หรือเครือข่ายสำนักงานของคุณ มันสามารถทดสอบโฮสต์ *.internal ที่ไม่มีบริการคลาวด์ใดสามารถแก้ไขได้ มันต้องการเพียงการเข้าถึง HTTPS และ WebSocket ขาออกไปยังเซิร์ฟเวอร์ Apidog เพื่อรับงานและอัปโหลดรายงาน
สเปกเซิร์ฟเวอร์ขั้นต่ำคืออะไร
CPU สองคอร์, RAM 4 GB, ดิสก์ 30 GB และ Docker 20.10.0 หรือใหม่กว่า สำหรับทีมที่รันงานตามกำหนดเวลาพร้อมกัน ให้เพิ่มเป็น 4+ คอร์และ 8 GB ทั้ง VM ขนาดเล็กหรือเครื่องสำรองในแร็คสำนักงานก็ใช้ได้ ข้อจำกัดคือเวลาทำงาน (uptime) ไม่ใช่กำลังประมวลผล
ฉันต้องใช้แผนใดสำหรับงานตามกำหนดเวลาบนตัวรันที่โฮสต์ด้วยตัวเอง
โควตาการรันงานตามกำหนดเวลาแตกต่างกันไปตามระดับการสมัครสมาชิก ดังนั้นตรวจสอบขีดจำกัดปัจจุบันบน หน้าการกำหนดราคา Apidog ก่อนที่คุณจะวางแผนกำหนดเวลาความถี่สูง หากคุณกำลังประเมินตัวเลือกการดำเนินการข้ามเครื่องมือ การเปรียบเทียบ Apidog CLI กับ Postman CLI ของเราจะพิจารณาสิ่งที่ฝั่งตัวรันการทดสอบของแต่ละแพลตฟอร์มมีให้