Thanawat Wongchai

Posted on Aug 12 Originally published at apidog.com

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

การทดสอบ API ไม่ได้จำกัดอยู่ใน GUI อีกต่อไป วันนี้การรันจริงมักเกิดในคอนเทนเนอร์ CI แบบ headless, เครื่อง staging ที่เข้าถึงผ่าน SSH หรือ AI agent ที่สื่อสารผ่าน shell เท่านั้น ดังนั้นเครื่องมือที่ดีต้องติดตั้งและรันจากเทอร์มินัลได้ ส่ง exit code ที่ CI เข้าใจได้ และสร้างรายงานสำหรับตรวจสอบผลลัพธ์ภายหลัง

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

บทความนี้คัดเลือกเครื่องมือสำหรับทดสอบ API จาก shell โดยเน้นการติดตั้งผ่าน package manager, การรันด้วยคำสั่งเดียว, assertions ในตัว, multi-step flows, รายงานสำหรับ CI และสถานะการบำรุงรักษา ส่วนไคลเอ็นต์อย่าง curl ยังมีประโยชน์มากสำหรับการตรวจสอบแบบรวดเร็ว แต่ต้องเพิ่ม logic สำหรับ assertion และ exit code เอง หากต้องการเปรียบเทียบเครื่องมือที่รวม GUI และบริการแบบโฮสต์ด้วย โปรดดู เครื่องมือทดสอบ API ฟรีที่ดีที่สุด

อะไรทำให้เครื่องมือทดสอบต่างจาก API client

API client บนเทอร์มินัลส่ง request และแสดง response ให้คุณดู แต่เครื่องมือทดสอบจะ ตัดสิน response และคืนผลลัพธ์เป็น exit code เพื่อให้ pipeline ตัดสินว่า build ควรผ่านหรือล้มเหลว

เครื่องมือทดสอบที่เหมาะกับ CI ควรมีองค์ประกอบเหล่านี้:

Assertions ในตัว — ตรวจสอบ status code, headers และ response body โดยไม่ต้องต่อคำสั่ง jq จำนวนมาก
Exit code ที่ชัดเจน — 0 เมื่อผ่าน และไม่ใช่ 0 เมื่อล้มเหลว
ทำซ้ำได้ — เก็บ test เป็นไฟล์หรือโปรเจกต์ที่อยู่ใน version control
รายงาน — แสดงผลในเทอร์มินัล และ export เป็น JSON, JUnit หรือ HTML สำหรับ CI artifacts

ด้านล่างคือ 10 เครื่องมือที่เหมาะกับงานทดสอบ API ผ่านเทอร์มินัลในปี 2026

1. Apidog CLI: สร้างแบบภาพ แล้วรันแบบ headless

Apidog เป็นแพลตฟอร์ม API ที่รวมการออกแบบ การทดสอบ mocking และเอกสารไว้ในที่เดียว ส่วน apidog-cli คือ CLI สำหรับรัน scenario ที่สร้างใน Apidog จากเทอร์มินัล

แนวทางทำงานคือ สร้าง request แบบต่อเนื่อง กำหนดตัวแปร และเพิ่ม assertions ใน Visual Editor จากนั้นใช้ apidog run เพื่อรัน scenario เดิมในเครื่อง developer, CI หรือ agent

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

# คัดลอกคำสั่งจากแท็บ CI/CD ของ scenario ใน Apidog
apidog run -t <scenario_id> -e <env_id> -r cli

ขั้นตอนใช้งานใน CI:

เปิด scenario ที่ต้องการใน Apidog
ไปที่แท็บ CI/CD
คัดลอกคำสั่งที่ระบบสร้างให้
เก็บ token ไว้ใน CI secret
รันคำสั่งใน pipeline และให้ CI ตรวจสอบ exit code

รองรับ reporter แบบ cli, html, json และ junit โดยเขียนผลลัพธ์ลงใน apidog-reports/ นอกจากนี้ยังรองรับ data-driven testing จาก CSV หรือ JSON และส่งผลลัพธ์ JSON ที่มี agentHints.nextSteps สำหรับ AI coding agent ต้องใช้ Node.js 16 ขึ้นไป

เหมาะสำหรับ: ทีมที่ต้องการสร้าง multi-step scenario ใน editor แล้วรันชุดเดิมได้ทุกสภาพแวดล้อม

ข้อจำกัด: ไม่ใช่โอเพนซอร์ส และ scenario จะอยู่ในโปรเจกต์ Apidog จึงเหมาะกับทีมที่ต้องการแพลตฟอร์มแบบครบวงจรมากกว่า HTTP client แบบดิบ

ดูคำสั่งและตัวเลือกเพิ่มเติมใน คู่มือฉบับสมบูรณ์ของ Apidog CLI

2. Hurl: เขียน HTTP test เป็นข้อความธรรมดา

Hurl รัน request HTTP จากไฟล์ข้อความและตรวจสอบ response ด้วย assertion syntax ในตัว สร้างด้วย Rust บน libcurl และแจกจ่ายเป็นไบนารีเดียว จึงไม่ต้องใช้ runtime เพิ่มเติม

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

เมื่อ assertion ไม่ผ่าน hurl --test จะคืน exit code ที่ไม่ใช่ศูนย์ จึงใช้เป็น CI gate ได้ทันที

เหมาะสำหรับ: contract test และ smoke test ที่ต้องการเก็บเป็นไฟล์ข้อความใน repository

ข้อจำกัด: เน้น HTTP เป็นหลัก ไม่เหมาะกับ gRPC หรือ load testing และ flow ที่ซับซ้อนอาจทำให้ไฟล์ .hurl มีจำนวนมาก

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

Newman คือ command-line runner แบบโอเพนซอร์สสำหรับ Postman collections ภายใต้ Apache-2.0 หากทีมมี collection และ environment ใน Postman อยู่แล้ว ให้ export เป็น JSON แล้วรันด้วย Newman ได้ทันที

npm install -g newman

newman run collection.json -e staging.json

Newman จะคืน exit code ที่ไม่ใช่ศูนย์เมื่อ test ล้มเหลว ทำให้เชื่อมเข้ากับ CI pipeline ได้ตรงไปตรงมา

เหมาะสำหรับ: ทีมที่มี Postman collection อยู่แล้วและต้องการรันใน pipeline โดยไม่ต้องใช้ license เพิ่ม

ข้อจำกัด: รันได้เฉพาะ collection รูปแบบ Postman และไม่ได้ช่วยสร้างหรือออกแบบ test ใหม่

4. Postman CLI: runner จาก Postman โดยตรง

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

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

postman collection run <collection_id> -e <environment_id>

เหมาะสำหรับ: ทีม Postman ที่ต้องการรัน collection จาก workspace โดยไม่ต้อง export ไฟล์

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

ดูรายละเอียดการเลือกใช้ได้ใน การเปรียบเทียบ Postman CLI กับ Newman

5. Bruno CLI: collection แบบ Git-native

Bruno เก็บ collection เป็นไฟล์ .bru แบบข้อความธรรมดาในโฟลเดอร์ปกติ จึงสามารถ version control, review ใน pull request และรันแบบออฟไลน์ได้เหมือน source code ทั่วไป

ติดตั้ง CLI แล้วรัน collection ด้วย bru:

npm install -g @usebruno/cli

# รันทุก request ใน collection ปัจจุบัน
bru run --env staging

Bruno CLI สร้างรายงาน JSON, JUnit และ HTML สำหรับ CI ได้

เหมาะสำหรับ: ทีมที่ต้องการเก็บ request, assertion และ script ไว้ใน repository

ข้อจำกัด: รูปแบบข้อความเหมาะกับทีม developer มากกว่าทีมผสม และ ecosystem ยังใหม่กว่า Postman

ดูการเปรียบเทียบเพิ่มเติมใน Bruno CLI vs Apidog CLI

6. Schemathesis: สร้าง test จาก schema

Schemathesis อ่าน OpenAPI หรือ GraphQL schema แล้วสร้าง test cases จำนวนมากด้วย property-based testing บน Hypothesis ของ Python แทนที่จะเขียนทุกกรณีเอง คุณสามารถใช้มัน fuzz input เพื่อค้นหา error 500, schema violation และ response ที่ไม่ตรงกับ API contract

pip install schemathesis

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

เหมาะสำหรับ: ค้นหา edge case ที่ไม่ได้อยู่ใน test suite โดยเฉพาะก่อน release

ข้อจำกัด: ต้องมี schema ที่ใช้งานได้จริง และ API ขนาดใหญ่อาจสร้างผลลัพธ์จำนวนมากจนต้องกรองด้วย hooks หรือ options

7. Step CI: multi-step flow ในไฟล์ YAML เดียว

Step CI ใช้ไฟล์ YAML หนึ่งไฟล์เพื่ออธิบาย API workflow ทั้ง steps, ค่าที่เก็บจาก response และ assertions รองรับ REST, GraphQL, gRPC, tRPC และ SOAP รวมถึงตรวจสอบ response กับ OpenAPI schema ได้

npm install -g stepci

stepci run workflow.yml

ตัวอย่าง use case ที่เหมาะสมคือ flow แบบ login → เก็บ token → ใช้ token เรียก endpoint ถัดไป โดยไม่ต้องเขียน script จำนวนมาก

เหมาะสำหรับ: multi-step flow ที่ต้องการนิยามแบบ declarative

ข้อจำกัด: ต้องใช้ Node runtime และควรตรวจสอบกิจกรรมล่าสุดของ repository ก่อนใช้สร้าง pipeline หลัก

8. curl: พื้นฐานที่มีอยู่แทบทุกที่

curl มักติดตั้งมาแล้วบน macOS, Linux distribution ส่วนใหญ่ และ Windows รุ่นปัจจุบัน เหมาะกับการส่ง request แบบรวดเร็ว งาน shell script และระบบที่ไม่อนุญาตให้ติดตั้ง dependency เพิ่ม

# 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}'

หากต้องการใช้ curl เป็น test runner คุณต้องเขียน assertion และจัดการ exit code เอง เช่น ตรวจสอบ status code หรือ pipe response เข้า jq

เหมาะสำหรับ: request ครั้งเดียว, script ขนาดเล็ก และ environment ที่ถูกล็อก

ข้อจำกัด: เป็น client ไม่ใช่ test runner — มันส่งและแสดงผล แต่ไม่ตรวจสอบผลลัพธ์ให้เอง

หาก curl เริ่มไม่เพียงพอ ดู คู่มือทางเลือกของ curl สำหรับการทดสอบ REST API

9. HTTPie และ xh: client ที่อ่านง่ายกว่า curl

HTTPie ทำให้ request ในเทอร์มินัลอ่านง่ายขึ้น โดยใช้คำสั่ง http และส่ง JSON เป็นคู่ key=value ส่วน xh ใช้ syntax เดียวกัน แต่สร้างด้วย Rust และมาเป็น static binary เดียว

http POST api.example.com/users name=acme plan=pro
xh   POST api.example.com/users name=acme plan=pro

xh ยังมี --curl สำหรับแสดงคำสั่ง curl ที่เทียบเท่าได้

เหมาะสำหรับ: สำรวจ API ด้วยมือระหว่างพัฒนา

ข้อจำกัด: ทั้งสองเป็น API client ไม่ใช่ test runner และไม่มี assertion ในตัว HTTPie ต้องใช้ Python runtime ส่วน xh เลือกความเร็วและความเบาแทน feature บางส่วน

10. k6: สำหรับคำถามด้านโหลดและประสิทธิภาพ

k6 ตอบคำถามที่ต่างจาก functional test: API รับ traffic ได้ตามที่คาดหวังหรือไม่ เป็นไบนารี Go จาก Grafana ที่เขียน test script ด้วย JavaScript และใช้ thresholds เป็นเกณฑ์ผ่าน/ไม่ผ่าน

brew install k6

k6 run load.js

กำหนด virtual users, duration และ thresholds ใน load.js เมื่อ threshold ไม่ผ่าน k6 จะคืน exit code ที่ไม่ใช่ศูนย์ เพื่อให้ CI ล้มเหลวได้

เหมาะสำหรับ: performance check ที่เก็บไว้ใน repository และรันได้ทั้งบนเครื่อง developer กับ CI

ข้อจำกัด: เป็นเครื่องมือ load testing ภายใต้ AGPL-3.0 ไม่ใช่ functional API test client และต้องเรียนรู้ JavaScript API ของ k6 สำหรับ scenario ที่ซับซ้อน

ต้องการเครื่องมือแบบโต้ตอบมากขึ้นหรือไม่

หากต้องการประสบการณ์คล้าย Postman โดยไม่ออกจาก shell ให้พิจารณา TUI client เช่น atac และ posting เครื่องมือกลุ่มนี้ช่วยสร้างและสำรวจ request ในเทอร์มินัล แต่ไม่ใช่ตัวเลือกหลักสำหรับใช้เป็น CI gate

อ่านเพิ่มเติมได้ที่ บทความสรุปไคลเอ็นต์ REST API แบบเทอร์มินัลและ TUI ที่ดีที่สุด

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

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

วิธีเลือกเครื่องมือ

เริ่มจากรูปแบบงานของทีม ไม่ใช่จากชื่อเครื่องมือ:

มี test อยู่ใน Postman แล้ว → ใช้ Newman หรือ Postman CLI
ต้องการ test เป็นไฟล์ข้อความที่ review ใน pull request ได้ → ใช้ Hurl หรือ Bruno CLI
มี OpenAPI schema ที่เชื่อถือได้ → เพิ่ม Schemathesis เพื่อค้นหา edge case
ต้องการตรวจ request ด้วยมือหรือแก้ปัญหาเฉพาะหน้า → เก็บ curl, HTTPie หรือ xh ไว้
ต้องวัดความสามารถในการรองรับ traffic → ใช้ k6
ต้องการสร้าง scenario ผ่าน Visual Editor แล้วรันใน CI → ใช้ Apidog CLI

Apidog CLI เหมาะเมื่อทีมต้องการ workflow เดียวที่รองรับการออกแบบ API, mock data, เอกสาร และ scenario test ที่รันจาก shell ได้ ดูภาพรวมเพิ่มเติมใน Apidog CLI: ไคลเอ็นต์ API ที่อยู่ในเทอร์มินัลของคุณ และ คู่มือกลยุทธ์การทดสอบ API

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

ฉันสามารถทดสอบ API ทั้งหมดจากเทอร์มินัลได้หรือไม่?

ได้ คุณสามารถเขียน test เป็นไฟล์ เช่น Hurl, Bruno หรือ Step CI หรือสร้างผ่าน Visual Editor เช่น Apidog และ Postman แล้วรันแบบ headless ด้วย CLI ที่ตรงกัน สิ่งสำคัญคือ runner ต้องคืน exit code ที่ CI ใช้ตัดสินผลได้

API client บนเทอร์มินัลต่างจากเครื่องมือทดสอบอย่างไร?

API client เช่น curl, HTTPie และ xh ส่ง request และแสดง response ส่วนเครื่องมือทดสอบ เช่น Apidog CLI, Hurl และ Newman จะตรวจสอบ response ด้วย assertions และคืน exit code ที่ไม่ใช่ศูนย์เมื่อ test ล้มเหลว

เครื่องมือใดรันใน CI pipeline ได้บ้าง?

Runner ทั้งหมดในรายการนี้ใช้กับ CI ได้:

apidog run
hurl --test
newman run
postman collection run
bru run
schemathesis run
stepci run
k6 run

คำสั่งเหล่านี้จะคืน exit code ที่ไม่ใช่ศูนย์เมื่อเกิดความล้มเหลว สำหรับตัวอย่างใช้งานจริง ดู วิธีรันการทดสอบ Apidog CLI ใน GitHub Actions

มีเครื่องมือใดรองรับ load testing หรือไม่?

มี k6 ซึ่งออกแบบสำหรับ load testing โดยใช้ thresholds เป็นเกณฑ์ผ่าน/ไม่ผ่าน เครื่องมืออื่นในรายการเน้นตรวจสอบความถูกต้องของ API ดังนั้นทีมจำนวนมากจะใช้ functional test runner คู่กับ k6

จำเป็นต้องมี OpenAPI spec หรือไม่?

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

รูปแบบที่เหมาะกับ API testing บนเทอร์มินัลคือ: สร้าง test ในรูปแบบที่ทีมดูแลได้ง่าย แล้วใช้ runner ที่ส่ง exit code กลับไปยัง pipeline หากต้องการรวมการสร้าง scenario และการรัน CI ไว้ในแพลตฟอร์มเดียว ให้ ดาวน์โหลด Apidog สร้าง scenario ใน editor แล้ววางคำสั่ง apidog run ลงใน pipeline

DEV Community