DEV Community

Cover image for สุดยอดเครื่องมือ CLI น้ำหนักเบา ทดสอบ API
Thanawat Wongchai
Thanawat Wongchai

Posted on • Originally published at apidog.com

สุดยอดเครื่องมือ CLI น้ำหนักเบา ทดสอบ API

เครื่องมือทดสอบ API ส่วนใหญ่บังคับให้คุณเปิดหน้าต่าง เข้าสู่ระบบ และคลิกผ่าน workspace ก่อนส่งคำขอแรก แต่เมื่อทำงานในเทอร์มินัล คุณมักต้องการเพียงคำสั่งเดียวเพื่อส่ง request อ่าน response แล้วไปต่อ เครื่องมือ CLI น้ำหนักเบาจึงลดขั้นตอนเหล่านี้ โดยให้ request และผลลัพธ์เป็นศูนย์กลางของการทำงาน

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

คำว่า “น้ำหนักเบา” ในบทความนี้หมายถึงติดตั้งง่าย เริ่มทำงานเร็ว ตั้งค่าน้อย และให้ผลลัพธ์ที่นำไปใช้ต่อในเทอร์มินัลได้ เช่น pipe ไปยัง jq, grep หรือใช้ exit code เป็นเงื่อนไขใน CI ไม่ได้หมายถึงแค่เป็นโอเพนซอร์สหรือมีฟีเจอร์น้อยที่สุด หากต้องการเปรียบเทียบเครื่องมือทั้งแบบ CLI และ GUI เพิ่มเติม ดูได้ที่ เครื่องมือทดสอบ API ฟรีที่ดีที่สุด

บทความนี้สรุปเครื่องมือ CLI น้ำหนักเบา 8 ตัวสำหรับทดสอบ REST และ HTTP API โดยเรียงจากเครื่องมือสำหรับยิง request ด้วยมือ ไปจนถึงเครื่องมือสำหรับรันชุดทดสอบเต็มรูปแบบใน CI

อะไรทำให้เครื่องมือ CLI “น้ำหนักเบา” สำหรับการทดสอบ API

เครื่องมือที่ทำงานในเทอร์มินัลไม่ได้เบาทุกตัว สำหรับรายการนี้ เครื่องมือควรมีคุณสมบัติหลักดังนี้:

  • ติดตั้งขนาดเล็ก — เป็นไบนารีเดียว ติดตั้งผ่าน pip/npm หรือรันด้วย npx ได้ทันที โดยไม่ต้องตั้งค่า daemon หรือระบบเพิ่มเติม
  • เริ่มทำงานเร็ว — เปิดเครื่องมือและส่ง request ได้ทันที ไม่ต้องรอ runtime หนัก ๆ เริ่มต้น
  • ตั้งค่าน้อยหรือไม่ต้องตั้งค่า — ส่ง request แรกได้โดยไม่ต้องสร้างโปรเจกต์ สมัครบัญชี หรือล็อกอิน
  • ผลลัพธ์เหมาะกับเทอร์มินัล — อ่านง่าย ส่งต่อให้คำสั่งอื่นได้ และมี exit code ที่ CI ใช้ตัดสินผลได้

เครื่องมือช่วงแรกจะเหมาะกับการสำรวจ endpoint ด้วยมือ ส่วน Hurl, Step CI, k6, Newman และ Apidog CLI จะเหมาะกับการทำให้การตรวจสอบเหล่านี้รันซ้ำได้ใน pipeline หากต้องการเน้นการเรียก endpoint แบบแมนนวล ดู ทางเลือกของ curl สำหรับการทดสอบ REST API

curl: มาตรฐานที่ติดตั้งมาให้แล้ว

curl มักมีอยู่แล้วใน macOS, Linux distribution ส่วนใหญ่ และ Windows รุ่นใหม่ จึงเหมาะเมื่อคุณต้องการส่ง request โดยไม่ติดตั้งอะไรเพิ่ม

# ตรวจสอบเวอร์ชัน
curl --version

# ส่ง POST JSON และพิมพ์เฉพาะ HTTP status code
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'
Enter fullscreen mode Exit fullscreen mode

ใช้เมื่อ

  • ต้องยิง request ครั้งเดียวอย่างรวดเร็ว
  • เขียน shell script
  • ทำงานบนเครื่องหรือ container ที่ติดตั้งแพ็กเกจเพิ่มไม่ได้

ข้อจำกัด

  • ต้องกำหนด header และ body เอง
  • JSON ไม่ถูกจัดรูปแบบให้อ่านง่ายตามค่าเริ่มต้น
  • การ assert response ต้องใช้ร่วมกับ jq, grep หรือ shell condition
  • เป็น HTTP client ไม่ใช่ test runner

ตัวอย่างการตรวจสอบ response ด้วย jq:

curl -s https://httpbin.org/json \
  | jq -e '.slideshow.title != null'
Enter fullscreen mode Exit fullscreen mode

jq -e จะคืน exit code ที่ไม่เป็นศูนย์เมื่อเงื่อนไขไม่ผ่าน จึงนำไปใช้ใน CI ได้

HTTPie: curl สำหรับมนุษย์

HTTPie ใช้สำหรับส่ง request แบบเดียวกับ curl แต่ไวยากรณ์อ่านง่ายกว่า โดยใช้คู่ key=value สำหรับข้อมูล JSON และแสดงผลแบบมีสีพร้อมจัดรูปแบบให้ตามค่าเริ่มต้น

python -m pip install httpie
# หรือ: brew install httpie

# age:=24 ส่งเป็นตัวเลข ส่วน name= ส่งเป็นสตริง
http POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

ใช้เมื่อ

  • สำรวจ API ด้วยมือ
  • ต้องการอ่าน request และ response ได้ง่ายโดยไม่ต้องใส่ flag จำนวนมาก
  • ต้องการส่ง JSON จากเทอร์มินัลบ่อย ๆ

ข้อจำกัด

  • ต้องใช้ Python runtime
  • เริ่มทำงานช้ากว่าไบนารีที่คอมไพล์แล้ว
  • เป็น client สำหรับตรวจดู response ไม่ใช่เครื่องมือ assert ผลลัพธ์

xh: ความเร็วของ HTTPie ในไบนารีเดียว

xh นำไวยากรณ์ที่ใช้งานง่ายของ HTTPie มาเขียนใหม่ด้วย Rust จึงได้ทั้ง syntax แบบ key=value และการเริ่มทำงานที่เร็วจากไบนารีเดียว นอกจากนี้ยังรองรับ HTTP/2 และพิมพ์คำสั่ง curl ที่เทียบเท่าได้ด้วย --curl

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

# ไวยากรณ์คล้าย HTTPie แต่เริ่มทำงานเร็วกว่า
xh POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

หากต้องการแปลงคำสั่งเป็น curl เพื่อใช้ในสคริปต์หรือแชร์กับทีม:

xh --curl POST httpbin.org/post name=acme age:=24
Enter fullscreen mode Exit fullscreen mode

ใช้เมื่อ

  • ชอบประสบการณ์แบบ HTTPie
  • ต้องการไบนารีเดียวที่ไม่มี Python runtime
  • ต้องการยิง request ด้วยมือจากเทอร์มินัลอย่างรวดเร็ว

ข้อจำกัด

  • ไม่ได้ครอบคลุมทุกฟีเจอร์ของ HTTPie
  • ไม่มีระบบปลั๊กอิน
  • ยังเป็น HTTP client ไม่ใช่ assertion engine

Hurl: การทดสอบข้อความธรรมดาที่ทำงานใน CI

Hurl คือจุดเปลี่ยนจาก “ส่ง request” เป็น “ทดสอบ response” คุณเขียน request และ assertion ลงในไฟล์ .hurl แบบข้อความธรรมดา แล้วใช้ hurl --test เพื่อให้คำสั่งล้มเหลวทันทีเมื่อ assertion ไม่ผ่าน

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

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

hurl --test login.hurl
Enter fullscreen mode Exit fullscreen mode

คำสั่งนี้จะคืน exit code ที่ไม่เป็นศูนย์หาก assertion ล้มเหลว จึงใช้เป็น CI gate ได้โดยตรง

ตัวอย่าง GitHub Actions แบบสั้น:

- name: Run API tests
  run: hurl --test tests/*.hurl
Enter fullscreen mode Exit fullscreen mode

ใช้เมื่อ

  • ต้องการเก็บ API smoke test หรือ contract-style test ไว้ใน Git
  • ต้องการ test format ที่รีวิวง่ายใน pull request
  • ต้องการ exit code ที่ใช้งานใน CI ได้ทันที

ข้อจำกัด

  • เน้น HTTP จึงไม่เหมาะกับ gRPC หรือ load testing
  • โฟลว์ซับซ้อนอาจทำให้มีไฟล์ .hurl จำนวนมาก
  • ไม่ใช่ภาษาสคริปต์เต็มรูปแบบ

Step CI: ไฟล์ YAML เดียวสำหรับโฟลว์แบบหลายขั้นตอน

Step CI เหมาะกับ API workflow ที่ต้องทำหลายขั้นตอนต่อเนื่อง เช่น login, ดึง token, ส่ง token ไปยัง request ถัดไป และตรวจสอบ response โดยอธิบายทุกอย่างในไฟล์ YAML เดียว

รองรับ REST, GraphQL, gRPC, tRPC และ SOAP รวมถึงการตรวจสอบกับ OpenAPI schema

npm install -g stepci

# workflow.yml อธิบายขั้นตอน การจับค่า และ assertion
stepci run workflow.yml
Enter fullscreen mode Exit fullscreen mode

โครงสร้าง workflow จะเหมาะเมื่อการทดสอบมีลำดับชัดเจน และข้อมูลจากขั้นแรกต้องถูกนำไปใช้ในขั้นถัดไป

ใช้เมื่อ

  • ต้องการไฟล์ declarative สำหรับ API flow หลายขั้นตอน
  • ต้องการใช้ test เดียวกันทั้งบนเครื่องและใน CI
  • ทำงานกับหลาย protocol ใน workflow เดียว

ข้อจำกัด

  • ต้องใช้ Node runtime จึงหนักกว่าไบนารี Rust หรือ Go
  • ควรตรวจสอบกิจกรรมล่าสุดของ repository ก่อนนำไปสร้าง pipeline ระยะยาว

สำหรับการวางแผนให้เครื่องมือเหล่านี้ทำงานร่วมกัน ดู กลยุทธ์การทดสอบ API

k6: การทดสอบโหลดแบบน้ำหนักเบาจากเทอร์มินัล

k6 ตอบคำถามด้านประสิทธิภาพ: API รองรับโหลดได้หรือไม่ แทนที่จะตรวจแค่ response ครั้งเดียว สคริปต์เขียนด้วย JavaScript และกำหนด threshold เพื่อให้ผลการทดสอบเป็นแบบผ่าน/ไม่ผ่านได้

brew install k6
# หรือรันผ่าน Docker: docker run grafana/k6

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 10,
  duration: '30s',
  thresholds: {
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const res = http.get('https://httpbin.org/get');

  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}
EOF

k6 run load.js
Enter fullscreen mode Exit fullscreen mode

ในตัวอย่างนี้ k6 จะรันผู้ใช้เสมือน 10 คนเป็นเวลา 30 วินาที และจะล้มเหลวหากค่า latency ที่ percentile 95 สูงกว่า 500 ms

ใช้เมื่อ

  • ต้องการตรวจสอบ performance หรือ load
  • ต้องการรัน performance test ใน CI
  • ต้องการกำหนด threshold ที่ตัดสิน build ได้

ข้อจำกัด

  • เป็นเครื่องมือ load test ไม่ใช่ client สำหรับดู response ครั้งเดียว
  • ต้องเขียน scenario ด้วย JavaScript
  • การสร้าง load ที่มีความหมายต้องเข้าใจ API และพฤติกรรมผู้ใช้

Newman: รัน Postman collection แบบ Headless

Newman เป็น command-line runner สำหรับ Postman collections หากทีมสร้าง request และ test script ไว้ใน Postman อยู่แล้ว คุณสามารถ export collection และ environment เป็น JSON แล้วรันใน CI ได้โดยไม่ต้องเปิด GUI

npm install -g newman

# collection.json ที่ export จาก Postman
# -e ระบุ environment
newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

ตัวอย่างใน CI:

- name: Run Postman collection
  run: newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

Newman จะคืน exit code ที่ไม่เป็นศูนย์เมื่อ test ใน collection ล้มเหลว

ใช้เมื่อ

  • ทีมใช้งาน Postman อยู่แล้ว
  • ต้องการนำ collection เดิมไปใช้ใน pipeline
  • ต้องการรัน Postman tests แบบ headless

ข้อจำกัด

  • ต้องใช้ Node runtime
  • รองรับเฉพาะ collection format ของ Postman
  • การสร้างและแก้ไข test ยังคงทำใน Postman GUI เป็นหลัก

Apidog CLI: รันสถานการณ์ที่คุณสร้างขึ้น ควบคุม CI ด้วยรหัสออกจากระบบ

Apidog CLI เป็นส่วน command-line ของ Apidog ติดตั้งเป็นแพ็กเกจ npm ชื่อ apidog-cli และใช้รันสถานการณ์ทดสอบที่สร้างใน Apidog แบบ headless

แนวทางคือสร้าง flow ใน GUI เพื่อเชื่อม request, ดึงตัวแปร และเพิ่ม assertion จากนั้นใช้ CLI เพื่อรัน flow เดิมในเทอร์มินัลหรือ CI

npm install -g apidog-cli

apidog login --with-token <YOUR_TOKEN>

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

ไม่จำเป็นต้องเดา scenario_id หรือ env_id:

  1. เปิดสถานการณ์ทดสอบใน Apidog
  2. ไปที่แท็บ CI/CD
  3. คัดลอกคำสั่ง apidog run ที่ระบบสร้างให้
  4. วางคำสั่งนั้นลงใน pipeline ของคุณ

หาก CI ต้องใช้รายงาน JUnit ให้เพิ่ม reporter:

apidog run -t <scenario_id> -e <env_id> -r cli,junit
Enter fullscreen mode Exit fullscreen mode

apidog run จะคืน exit code 0 เมื่อ assertion ทั้งหมดผ่าน และคืน exit code ที่ไม่เป็นศูนย์เมื่อมีขั้นตอนใดล้มเหลว จึงใช้เป็น CI gate ได้ ผลลัพธ์เป็น JSON ที่มีโครงสร้างพร้อม agentHints.nextSteps ซึ่งเหมาะกับการให้ AI coding agent อ่านและดำเนินการต่อ

ใช้เมื่อ

  • ต้องการออกแบบ scenario หลายขั้นตอนใน visual editor
  • ต้องการรัน scenario เดิมแบบ headless ใน CI หรือจาก agent
  • ต้องการรวม client, test scenario และการรัน pipeline ไว้ใน workflow เดียว

ข้อจำกัด

  • ผูกกับ scenario ที่เก็บในโปรเจกต์ Apidog
  • ไม่ใช่ HTTP client แบบทั่วไปเหมือน curl หรือ xh
  • Apidog ไม่ใช่โอเพนซอร์ส แม้จะมีบริการฟรี

ดูรายละเอียดคำสั่งเพิ่มเติมได้จาก คู่มือ Apidog CLI ฉบับสมบูรณ์, การอ้างอิงคำสั่ง apidog run และคู่มือ ทดสอบ REST API จาก command line ด้วย Apidog CLI

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

เลือกจากระดับความซับซ้อนของงาน ไม่ใช่แค่จากความนิยมของเครื่องมือ

เครื่องมือ เหมาะที่สุดสำหรับ การติดตั้ง โอเพ่นซอร์ส? หมายเหตุ
curl คำขอครั้งเดียว, สคริปต์ ติดตั้งมาพร้อมเครื่อง ใช่ (MIT/curl) ใช้ได้แทบทุกที่; assertion ต้องทำเอง
HTTPie คำขอแบบแมนนวลที่อ่านง่าย pip install httpie ใช่ (BSD-3) ไวยากรณ์เป็นมิตร; ต้องมี Python
xh ประสบการณ์แบบ HTTPie ที่เร็วกว่า brew install xh ใช่ (MIT) ไบนารี Rust เดี่ยว
Hurl การทดสอบ HTTP แบบข้อความธรรมดา brew install hurl ใช่ (Apache-2.0) ใช้ --test เป็น CI gate
Step CI โฟลว์ YAML แบบหลายขั้นตอน npm i -g stepci ใช่ (MPL-2.0) รองรับ REST/GraphQL/gRPC; ต้องมี Node
k6 การทดสอบโหลดและประสิทธิภาพ brew install k6 ใช่ (AGPL-3.0) เขียนสคริปต์ด้วย JS; threshold ทำให้คำสั่งล้มเหลว
Newman Postman collections ใน CI npm i -g newman ใช่ (Apache-2.0) รัน Postman JSON แบบ headless
Apidog CLI สถานการณ์ที่สร้างด้วยภาพและรันแบบ headless npm i -g apidog-cli ไม่ (มีบริการฟรี) ใช้ exit code ควบคุม CI; มี JSON สำหรับ agent

แนวทางเลือกใช้งานแบบเร็ว:

  1. ยิง endpoint หรือเขียนสคริปต์สั้น ๆ — ใช้ curl
  2. ต้องการ syntax ที่อ่านง่ายสำหรับงานแมนนวล — ใช้ HTTPie หรือ xh
  3. ต้องการเก็บ HTTP assertion ไว้ใน Git — ใช้ Hurl
  4. ต้องการ workflow หลายขั้นตอนแบบ declarative — ใช้ Step CI
  5. ต้องการทดสอบโหลด — ใช้ k6
  6. มี test อยู่ใน Postman แล้ว — ใช้ Newman
  7. สร้าง scenario แบบภาพและรันใน CI — ใช้ Apidog CLI

หากต้องการเปรียบเทียบกับ workflow ที่ไม่มี GUI ตั้งแต่ต้นจนจบ ดู เครื่องมือทดสอบ API แบบ headless

ประโยชน์ของเครื่องมือน้ำหนักเบา

เครื่องมือ CLI น้ำหนักเบาเหมาะเมื่อ GUI ทำให้วงจรการตรวจสอบช้าลง เช่น เมื่อคุณทำงานในเทอร์มินัล ต้องรัน test ใน CI โดยไม่มีผู้ใช้ หรือให้ AI agent ตรวจสอบ API แทน

  • curl และ xh ทำให้การทดลอง endpoint รวดเร็ว
  • Hurl และ Step CI เปลี่ยน request ชั่วคราวเป็น test ที่ทำซ้ำได้
  • k6 ใช้วัดโหลดและประสิทธิภาพ
  • Newman รันสิ่งที่ทีมสร้างไว้ใน Postman
  • Apidog CLI เชื่อมการสร้าง scenario แบบ visual เข้ากับการรันแบบ headless

ด้วย Apidog CLI คุณออกแบบ scenario หนึ่งครั้งใน Apidog แล้วใช้ apidog run รันจากเทอร์มินัล, pipeline หรือ agent ได้ทันที รหัสออกจากระบบจะเป็นตัวตัดสินว่า build ผ่านหรือไม่ผ่าน

ดาวน์โหลด Apidog สร้าง scenario หนึ่งรายการ แล้วเพิ่มคำสั่ง apidog run ลงใน CI configuration เพื่อทดสอบ workflow แบบครบวงจร

Top comments (0)