เครื่องมือทดสอบ API ยอดนิยมแบบ Command Line ปี 2026

การทดสอบ API ได้ย้ายออกจากการทำงานบน GUI แล้ว ปัจจุบันการทดสอบจะทำงานในคอนเทนเนอร์ CI ที่ไม่มีการแสดงผล ในกล่อง staging ที่คุณเข้าถึงได้ผ่าน SSH เท่านั้น และภายใต้ AI agents ที่พูดภาษา shell เท่านั้น ในทั้งสามที่นี้ เทอร์มินัลคือที่ที่การทดสอบผ่านหรือล้มเหลวโดยไม่มีมนุษย์เฝ้าดู

บทความนี้จัดอันดับเครื่องมือที่ใช้ในการทดสอบจริงจากพรอมต์ของ shell "แบบใช้เทอร์มินัล" ในที่นี้หมายถึงการทำงานทั้งหมดใน shell: ติดตั้งจากตัวจัดการแพ็คเกจ, รันคำสั่งเดียว, อ่านรหัสออก (exit code) การจัดอันดับจะพิจารณาการยืนยันในตัว (built-in assertions), การทำงานหลายขั้นตอน (multi-step flows), รายงานที่พร้อมสำหรับ CI, และสถานะการบำรุงรักษา ไคลเอ็นต์แบบแมนนวลเช่น curl ยังคงได้รับตำแหน่งใกล้ท้ายสุด เนื่องจากเวิร์กโฟลว์ของเทอร์มินัลทุกอย่างอาศัยมันระหว่างการรันการทดสอบ สำหรับการสำรวจที่กว้างขึ้นซึ่งรวมถึง GUI และเครื่องมือแบบโฮสต์ โปรดดูบทความ เครื่องมือทดสอบ API ฟรีที่ดีที่สุด

ปุ่ม

อะไรคือสิ่งที่แยกเครื่องมือทดสอบออกจากไคลเอ็นต์

ไคลเอ็นต์เทอร์มินัลจะส่งคำขอและแสดงการตอบสนองให้คุณเห็น เครื่องมือทดสอบเทอร์มินัลจะตัดสินการตอบสนองและรายงานผลการตัดสินเป็นรหัสออก (exit code) ที่ pipeline ของคุณสามารถใช้เป็นเกณฑ์ได้ กลุ่มที่สองคือหัวใจของรายการนี้ และมีคุณสมบัติสี่ประการที่กำหนดมัน:

การยืนยันในตัว (Assertions built in) การตรวจสอบสถานะ, ส่วนหัว (headers) และเนื้อหา (body) ควรอยู่ในเครื่องมือ ไม่ใช่ในกองของโค้ด jq ที่เชื่อมต่อกัน
รหัสออกที่สื่อความหมาย (Exit codes that mean something) เป็นศูนย์เมื่อผ่าน, ไม่ใช่ศูนย์เมื่อล้มเหลว, เพื่อให้ CI ล้มเหลวในการสร้าง (build) ให้คุณ
ความสามารถในการทำซ้ำ (Repeatability) การทดสอบควรอยู่ในไฟล์หรือโปรเจกต์ที่คุณสามารถจัดการเวอร์ชันและรันซ้ำได้ ไม่ใช่ในประวัติ shell ของคุณ
รายงาน (Reports) ผลลัพธ์ที่มนุษย์สามารถอ่านได้ในเทอร์มินัลและแดชบอร์ดสามารถวิเคราะห์ได้ในรูปแบบ JSON, JUnit หรือ HTML

เมื่อกำหนดเกณฑ์แล้ว นี่คือสิบเครื่องมือที่ควรค่าแก่เวลาของคุณในปี 2026

1. Apidog CLI: สร้างด้วยภาพ, รันแบบ headless ได้ทุกที่

Apidog เป็นแพลตฟอร์ม API แบบครบวงจรที่ครอบคลุมการออกแบบ, การทดสอบ, การจำลอง (mocking) และเอกสาร Apidog CLI (apidog-cli บน npm) คือส่วนที่ทำงานในเทอร์มินัล คุณสร้างสถานการณ์ทดสอบในตัวแก้ไขแบบภาพ (visual editor) โดยมีการร้องขอแบบต่อเนื่อง (chained requests), ตัวแปรที่ดึงออกมา และการยืนยัน จากนั้น apidog run จะรันสถานการณ์เหล่านั้นจาก shell ใดก็ได้และส่งรหัสออกที่สะอาดตาให้กับ pipeline ของคุณ

ภาพหน้าจอแสดงการทำงานของ Apidog CLI ในเทอร์มินัล

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# คัดลอกคำสั่งที่แน่นอนจากแท็บ CI/CD ของสถานการณ์ของคุณ
apidog run -t <scenario_id> -e <env_id> -r cli

คุณไม่ต้องเดา ID เปิดสถานการณ์ใน Apidog, ไปที่แท็บ CI/CD และคัดลอกคำสั่งที่สร้างขึ้น ผู้รายงานครอบคลุม cli, html, json และ junit ซึ่งเขียนไปยัง apidog-reports/ ดังนั้นการรันเดียวกันนี้จึงสามารถป้อนข้อมูลไปยังเทอร์มินัล, แดชบอร์ด และพื้นที่เก็บ artifact ได้ การรันแบบ Data-driven ดึงข้อมูลการวนซ้ำจากไฟล์ CSV หรือ JSON ผลลัพธ์เป็น JSON ที่มีโครงสร้างพร้อม agentHints.nextSteps ซึ่งช่วยให้ AI coding agent รันชุดคำสั่งและตัดสินใจดำเนินการต่อไปโดยไม่ต้อง screen-scraping ต้องใช้ Node.js 16 หรือใหม่กว่า

เหมาะที่สุดสำหรับ: ทีมที่ต้องการสถานการณ์ที่ซับซ้อนและหลายขั้นตอนที่สร้างขึ้นในตัวแก้ไขและรันได้เหมือนกันบนแล็ปท็อป, ใน CI และโดย agents ข้อจำกัดที่ซื่อสัตย์: ไม่ใช่โอเพนซอร์สและไม่ใช่เครื่องมือส่ง ad-hoc สถานการณ์จะอยู่ในโปรเจกต์ Apidog ดังนั้นนี่จึงเป็นตัวเลือกแพลตฟอร์มแบบครบวงจรมากกว่าเครื่องมือ HTTP แบบดิบ คู่มือฉบับสมบูรณ์ของ Apidog CLI ครอบคลุมชุดคำสั่งทั้งหมด

2. Hurl: การทดสอบข้อความธรรมดาในไบนารี Rust เดียว

Hurl รันคำขอ HTTP ที่เขียนในรูปแบบข้อความธรรมดาและยืนยันการตอบสนอง สร้างขึ้นใน Rust บน libcurl และมาในรูปแบบไบนารีเดียว จึงไม่ต้องติดตั้งรันไทม์ การทดสอบอ่านได้เกือบเหมือน HTTP ดิบ ซึ่งทำให้ง่ายต่อการตรวจสอบใน pull request

brew install hurl   # หรือ: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

hurl --test login.hurl   # exit code ไม่ใช่ศูนย์ หากการยืนยันล้มเหลว

เหมาะที่สุดสำหรับ: การตรวจสอบแบบ contract-style และ smoke tests ที่คุณเก็บไว้ในระบบควบคุมเวอร์ชันเป็นข้อความที่อ่านง่าย แฟล็ก --test ทำให้เป็น CI gate ที่เป็นธรรมชาติ ข้อจำกัดที่ซื่อสัตย์: เน้นที่ HTTP ดังนั้นจึงไม่สามารถขับเคลื่อน gRPC หรือสร้างโหลดได้ และตรรกะที่ซับซ้อนหมายถึงไฟล์ .hurl ที่มากขึ้น แทนที่จะเป็นภาษาสคริปต์

3. Newman: รัน Postman collections แบบ headless

Newman เป็น command-line runner แบบโอเพนซอร์สสำหรับ Postman collections (Apache-2.0) หากทีมของคุณเขียนคำขอและทดสอบใน Postman อยู่แล้ว Newman จะรัน collection นั้นจากเทอร์มินัลโดยไม่มี GUI คุณสามารถส่งออก collection และ environment เป็น JSON แล้วให้ Newman ชี้ไปที่ไฟล์

npm install -g newman

newman run collection.json -e staging.json

เหมาะที่สุดสำหรับ: ทีมที่ลงทุนใน Postman และต้องการให้ collection ที่มีอยู่ทำงานใน pipeline โดยไม่ต้องใช้ license เพิ่มเติม มันจะ exit ด้วยค่าที่ไม่ใช่ศูนย์เมื่อการทดสอบล้มเหลว ดังนั้น CI gates จึงทำงานได้อย่างสะอาด ข้อจำกัดที่ซื่อสัตย์: มันรันได้เฉพาะ collection ในรูปแบบ Postman เท่านั้น และการสร้างยังคงต้องทำใน Postman GUI มันจะรันการทดสอบ; มันไม่ได้ช่วยคุณเขียนการทดสอบ

4. Postman CLI: ทางเลือกจากบุคคลที่หนึ่งของ Newman

Postman CLI เป็น runner แบบปิดแหล่งที่มาของ Postman เอง ซึ่งแตกต่างจาก Newman ตรงที่มันจะลงชื่อเข้าใช้บัญชี Postman ของคุณและสามารถรัน collection ด้วย ID ของมันได้โดยตรงจาก workspace พร้อมทั้งรายงานผลลัพธ์กลับไปยังคลาวด์ของ Postman

postman login --with-api-key <YOUR_API_KEY>

postman collection run <collection_id> -e <environment_id>

เหมาะที่สุดสำหรับ: ทีม Postman ที่ต้องการการรันที่เชื่อมโยงกับคลาวด์โดยไม่ต้องส่งออกไฟล์ JSON ข้อจำกัดที่ซื่อสัตย์: มันเป็นซอฟต์แวร์ปิดแหล่งที่มาและผูกติดกับบัญชี Postman และการมี runner อย่างเป็นทางการสองตัวทำให้เกิดความสับสนอย่างมากว่าจะเลือกใช้ตัวใด การเปรียบเทียบ Postman CLI กับ Newman จะช่วยคลี่คลายว่าเมื่อใดควรใช้ตัวใด

5. Bruno CLI: collections แบบ git-native, รันด้วย bru

Bruno เก็บ collections เป็นไฟล์ .bru ข้อความธรรมดาในโฟลเดอร์ปกติ ทำให้คำขออยู่ใน repo ของคุณเหมือนโค้ดอื่นๆ CLI ของมันคือ @usebruno/cli ซึ่งรัน collections เหล่านั้นจากเทอร์มินัลด้วยคำสั่ง bru โดยไม่จำเป็นต้องมีบัญชีคลาวด์

npm install -g @usebruno/cli

# รันทุกคำขอในโฟลเดอร์ collection ปัจจุบัน
bru run --env staging

เหมาะที่สุดสำหรับ: ทีมที่ต้องการให้ collections ได้รับการตรวจสอบใน pull requests และรันแบบออฟไลน์ โดยมีการยืนยันและการเขียนสคริปต์อยู่ในไฟล์เดียวกัน มันเขียนรายงาน JSON, JUnit และ HTML สำหรับ CI ข้อจำกัดที่ซื่อสัตย์: การสร้างในรูปแบบข้อความธรรมดาเหมาะสำหรับนักพัฒนามากกว่าทีมผสม และระบบนิเวศก็ยังใหม่กว่าของ Postman ดูว่ามันเปรียบเทียบกับ runner ของ Apidog อย่างไรใน Bruno CLI vs Apidog CLI

6. Schemathesis: schema ของคุณเขียนการทดสอบให้

Schemathesis ใช้วิธีที่แตกต่างออกไป: มันอ่าน OpenAPI หรือ GraphQL schema ของคุณ และสร้างกรณีทดสอบนับพันจาก schema นั้น โดยใช้ property-based testing ที่สร้างขึ้นบน Hypothesis ของ Python แทนที่จะเขียนแต่ละกรณี คุณปล่อยให้มัน fuzz อินพุตเพื่อค้นหาข้อผิดพลาด 500, การละเมิด schema และการตอบสนองที่ละเมิดสัญญาที่เอกสารของคุณสัญญาไว้

pip install schemathesis

schemathesis run https://api.example.com/openapi.json

เหมาะที่สุดสำหรับ: การจับข้อบกพร่องกรณีขอบที่ไม่มีใครคิดจะเขียนการทดสอบให้ โดยเฉพาะอย่างยิ่งก่อนการเผยแพร่ เป็นหนึ่งในข้อโต้แย้งที่แข็งแกร่งที่สุดในการรักษา schema ที่ถูกต้อง ข้อจำกัดที่ซื่อสัตย์: ต้องใช้ schema จริงในการทำงาน และ API ขนาดใหญ่อาจสร้าง "เสียงรบกวน" ที่คุณจะต้องกรองด้วย hooks และ options

7. Step CI: หนึ่งไฟล์ YAML ต่อหนึ่ง multi-step flow

Step CI อธิบายเวิร์กโฟลว์ API ในไฟล์ YAML เดียว: ขั้นตอน, ค่าที่ถูกเก็บไว้ และการตรวจสอบ ครอบคลุม REST, GraphQL, gRPC, tRPC และ SOAP ในเวิร์กโฟลว์เดียว และตรวจสอบความถูกต้องเทียบกับ OpenAPI schema ไฟล์เดียวกันนี้สามารถรันได้ทั้งบนแล็ปท็อปและใน pipeline

npm install -g stepci

stepci run workflow.yml

เหมาะที่สุดสำหรับ: ลำดับการเข้าสู่ระบบแล้วใช้โทเค็นที่อธิบายแบบประกาศ โดยไม่ต้องมีการเขียนสคริปต์ ข้อจำกัดที่ซื่อสัตย์: ต้องมี Node runtime และความถี่ในการเผยแพร่ลดลง ดังนั้นควรตรวจสอบกิจกรรมล่าสุดของ repo ก่อนที่จะสร้าง pipeline โดยใช้มัน

8. curl: มาตรฐานพื้นฐานที่มีการติดตั้งไว้แล้ว

curl มาพร้อมกับ macOS, Linux distros ส่วนใหญ่ และ Windows ปัจจุบัน ดังนั้นการติดตั้งที่เบาที่สุดคือไม่ต้องติดตั้งอะไรเลย มันเป็นไคลเอ็นต์อ้างอิงที่เครื่องมืออื่นๆ ใช้เป็นมาตรฐานในการวัดประสิทธิภาพ และด้วย -w และ shell glue ก็สามารถทำหน้าที่เป็นชุดทดสอบขั้นต่ำได้

# POST JSON และพิมพ์เฉพาะ HTTP status
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"sku":"A-102","qty":2}'

เหมาะที่สุดสำหรับ: คำขอแบบครั้งเดียว, สคริปต์ และสภาพแวดล้อมที่ถูกล็อคซึ่งไม่สามารถติดตั้งอะไรใหม่ได้ ข้อจำกัดที่ซื่อสัตย์: การยืนยันทั้งหมดต้องทำเอง คุณต้อง pipe ไปยัง jq, เปรียบเทียบค่าด้วยตัวเอง และจัดการ exit codes ด้วยตนเอง มันส่งและแสดง; มันไม่ได้ทดสอบ คู่มือทางเลือกของ curl สำหรับการทดสอบ REST API ครอบคลุมสิ่งที่ควรใช้เมื่อสิ่งนี้ไม่เพียงพออีกต่อไป

9. HTTPie และ xh: คำขอที่อ่านง่ายด้วยมือ

HTTPie ทำให้คำขอเทอร์มินัลอ่านง่าย: คำสั่งคือ http, ฟิลด์ JSON เป็นคู่ key=value และการตอบกลับจะถูกแสดงผลด้วยสีและรูปแบบ xh นำไวยากรณ์เดียวกันนั้นมาใช้ใหม่ใน Rust เป็นไบนารีแบบคงที่เดียว โดยมีเวลาเริ่มต้นที่เร็วกว่าและแฟล็ก --curl ที่พิมพ์คำสั่ง curl ที่เทียบเท่ากัน

http POST api.example.com/users name=acme plan=pro   # HTTPie
xh   POST api.example.com/users name=acme plan=pro   # ไวยากรณ์เดียวกัน, ไบนารีเดียว

เหมาะที่สุดสำหรับ: การสำรวจ API ด้วยตนเองในขณะที่คุณสร้างการทดสอบจริงที่อื่น ข้อจำกัดที่ซื่อสัตย์: ทั้งสองเป็นไคลเอ็นต์ ไม่ใช่ runner HTTPie ต้องใช้ Python runtime; xh แลกเปลี่ยนคุณสมบัติที่น้อยกว่าเพื่อความเร็ว ทั้งสองไม่ยืนยันการตอบสนอง

10. k6: เมื่อคำถามคือโหลด

k6 ตอบคำถามที่แตกต่างออกไป: ไม่ใช่ "การตอบสนองนี้ถูกต้องหรือไม่" แต่ "มันสามารถรับมือกับการจราจรได้หรือไม่" มันเป็นไบนารี Go เดียวจาก Grafana ซึ่งเขียนสคริปต์ด้วย JavaScript พร้อมเกณฑ์ (thresholds) ที่เปลี่ยนการทดสอบโหลดให้เป็นประตูผ่าน/ไม่ผ่าน หากเกินเกณฑ์ k6 จะออกด้วยค่าที่ไม่ใช่ศูนย์ ซึ่ง CI จะอ่านว่าล้มเหลว

brew install k6

k6 run load.js   # vus, duration, และ thresholds ถูกกำหนดในสคริปต์

เหมาะที่สุดสำหรับ: การตรวจสอบประสิทธิภาพที่อยู่ใน repo เดียวกันกับการทดสอบการทำงาน และรันจากแล็ปท็อปหรือ pipeline ข้อจำกัดที่ซื่อสัตย์: เป็นเครื่องมือโหลดภายใต้ AGPL-3.0 ไม่ใช่ไคลเอ็นต์ทดสอบการทำงาน และสถานการณ์ที่มีความหมายหมายถึงการเรียนรู้ API JavaScript ของมัน

ชอบอะไรที่โต้ตอบได้มากกว่าไหม?

หากคุณต้องการอินเทอร์เฟซที่เหมือน Postman โดยไม่ต้องออกจาก shell นั่นเป็นหมวดหมู่ที่แยกต่างหาก: ไคลเอ็นต์ TUI เช่น atac และ posting จะสร้างตัวแก้ไขคำขอแบบเต็มในเทอร์มินัล พวกมันสำรวจ API; พวกมันไม่ได้ใช้เป็นเกณฑ์สำหรับ pipeline บทความสรุปไคลเอ็นต์ REST API แบบเทอร์มินัลและ TUI ที่ดีที่สุด ครอบคลุมด้านนั้นอย่างละเอียด

ตารางเปรียบเทียบ

เครื่องมือ	หน้าที่	มีการยืนยันในตัว	การติดตั้ง	โอเพนซอร์ส
Apidog CLI	รันสถานการณ์ที่สร้างด้วยภาพใน CI	มี	`npm i -g apidog-cli`	ไม่มี (แพ็กเกจฟรี)
Hurl	การทดสอบ HTTP แบบข้อความธรรมดา	มี	`brew install hurl`	Apache-2.0
Newman	Postman collections แบบ headless	มี	`npm i -g newman`	Apache-2.0
Postman CLI	การรัน Postman ที่เชื่อมโยงกับคลาวด์	มี	โปรแกรมติดตั้ง Postman	ไม่มี
Bruno CLI	`.bru` collections แบบ Git-native	มี	`npm i -g @usebruno/cli`	MIT
Schemathesis	Fuzzing จาก schema	สร้างขึ้น	`pip install schemathesis`	MIT
Step CI	Multi-step YAML flows	มี	`npm i -g stepci`	MPL-2.0
curl	คำขอแบบดิบ, การเขียนสคริปต์	ทำเอง	ติดตั้งมาให้แล้ว	มี
HTTPie / xh	คำขอด้วยตนเองที่อ่านง่าย	ไม่มี	`brew install httpie` / `xh`	มี
k6	โหลดพร้อมเกณฑ์ผ่าน/ไม่ผ่าน	เกณฑ์	`brew install k6`	AGPL-3.0

วิธีการเลือก

เริ่มต้นจากงาน ไม่ใช่เครื่องมือ หากมี tests อยู่ใน Postman แล้ว Newman หรือ Postman CLI สามารถรันได้ทันที หากคุณต้องการ tests ในรูปแบบข้อความที่สามารถตรวจสอบได้ใน repo ของคุณ Hurl และ Bruno CLI เป็นตัวเลือกที่แข็งแกร่งที่สุด หากคุณมี OpenAPI schema ที่มั่นคง ให้เพิ่ม Schemathesis และปล่อยให้มันล่าหาบั๊กที่คุณคาดไม่ถึง เก็บ curl และ xh ไว้สำหรับชั้นของการทำงานด้วยตนเอง และนำ k6 เข้ามาใช้ในวันที่คำถามเปลี่ยนจากความถูกต้องเป็นความสามารถในการรองรับ

เลือก Apidog CLI เมื่อคุณต้องการสร้างสถานการณ์ใน Visual Editor และรันได้ทุกที่ มันเป็นตัวเลือกเดียวในที่นี้ที่โปรเจกต์เดียวกันนี้ยังรองรับการออกแบบ API, Mock data และเอกสารของคุณด้วย ซึ่งเป็นข้อดีที่อธิบายไว้ใน Apidog CLI: ไคลเอ็นต์ API ที่อยู่ในเทอร์มินัลของคุณ สำหรับภาพรวมการทดสอบที่กว้างขึ้นเบื้องหลังตัวเลือกเหล่านี้ คู่มือกลยุทธ์การทดสอบ API แสดงให้เห็นว่าแต่ละชั้นเหมาะสมกับที่ใด

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

ฉันสามารถทดสอบ API ทั้งหมดจากเทอร์มินัลได้หรือไม่? ได้ คุณสามารถสร้างการทดสอบเป็นไฟล์ (Hurl, Bruno, Step CI) หรือในตัวแก้ไขแบบภาพ (Apidog, Postman) จากนั้นรันแบบ headless ด้วย CLI ที่ตรงกัน ทุก runner ในรายการนี้จะคืนค่า exit code ซึ่งเป็นสิ่งที่ CI ต้องการทั้งหมด

อะไรคือความแตกต่างระหว่างไคลเอ็นต์ API แบบเทอร์มินัลกับเครื่องมือทดสอบ? ไคลเอ็นต์ (curl, HTTPie, xh) ส่งคำขอและแสดงการตอบสนอง เครื่องมือทดสอบ (Apidog CLI, Hurl, Newman) ยืนยันการตอบสนองและล้มเหลวด้วย exit code ที่ไม่เป็นศูนย์ ไคลเอ็นต์ใช้สำรวจ; เครื่องมือทดสอบใช้เป็นเกณฑ์

เครื่องมือใดบ้างที่รันใน CI pipelines? Runner ทั้งหมด: apidog run, hurl --test, newman run, postman collection run, bru run, schemathesis run, stepci run และ k6 run ทั้งหมดจะ exit ด้วยค่าที่ไม่เป็นศูนย์เมื่อล้มเหลว สำหรับตัวอย่าง pipeline ที่ใช้งานได้จริง ดูวิธีการ รันการทดสอบ Apidog CLI ใน GitHub Actions

เครื่องมือเหล่านี้มีตัวใดที่รองรับ load testing บ้าง? k6 เป็นผู้เชี่ยวชาญด้านโหลดในที่นี้ โดยมีเกณฑ์เป็นตัวกำหนดการผ่าน/ไม่ผ่าน เครื่องมืออื่นๆ ตรวจสอบความถูกต้อง ไม่ใช่ความสามารถในการรองรับ ดังนั้นหลายทีมจึงจับคู่ functional runner หนึ่งตัวกับ k6

ฉันจำเป็นต้องมี OpenAPI spec เพื่อใช้เครื่องมือเหล่านี้หรือไม่? มีเพียง Schemathesis เท่านั้นที่ต้องการ เพราะมันสร้างการทดสอบจาก schema เครื่องมืออื่นๆ นั้น spec มีประโยชน์แต่ไม่จำเป็น: Apidog นำเข้า OpenAPI 3.x, Swagger 2.0 และ Postman collections และ Step CI สามารถตรวจสอบความถูกต้องของการตอบสนองเทียบกับ schema ได้

รูปแบบของเครื่องมือทั้งสิบนี้เหมือนกัน: การสร้างต้องการความสะดวกสบาย, การรันต้องการ shell เลือกที่คุณต้องการเขียนการทดสอบ จากนั้นตรวจสอบให้แน่ใจว่า runner ส่ง exit code ให้กับ pipeline ของคุณ หากคุณต้องการทั้งสองส่วนจากแพลตฟอร์มเดียว ดาวน์โหลด Apidog สร้างสถานการณ์หนึ่งใน editor และวางคำสั่ง apidog run ของมันลงใน CI เพื่อปิดวงจร