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

เครื่องมือทดสอบ API ส่วนใหญ่ต้องการให้คุณเปิดหน้าต่าง เข้าสู่ระบบ และคลิกไปรอบๆ พื้นที่ทำงานก่อนที่คุณจะส่งคำขอเดียว นั่นเป็นสิ่งที่ดีสำหรับการดูครั้งแรก แต่ไม่เหมาะสำหรับเทอร์มินัลที่คุณต้องการพิมพ์บรรทัดเดียว อ่านการตอบกลับ และดำเนินการต่อไป เครื่องมือ command-line ที่มีน้ำหนักเบาจะสลับลำดับ: เครื่องมือจะหลีกทาง และคำขอคือการโต้ตอบทั้งหมด

คำว่า "น้ำหนักเบา" ในที่นี้มีความหมายเฉพาะ การติดตั้งขนาดเล็ก มักจะเป็นไบนารีเดียวหรือใช้คำสั่ง npx อย่างรวดเร็ว การเริ่มต้นที่รวดเร็ว ทำให้การเรียกใช้งาน endpoint รู้สึกทันที การกำหนดค่าเล็กน้อยหรือไม่จำเป็นเลยสำหรับการเรียกใช้งานครั้งแรก ผลลัพธ์ที่เหมาะสำหรับเทอร์มินัลที่คุณสามารถส่งต่อไปยัง jq หรือ grep ได้ นี่เป็นคำถามที่แตกต่างจาก "เครื่องมือใดที่เป็นโอเพ่นซอร์ส" หรือ "เครื่องมือใดมีฟีเจอร์มากที่สุด" มันเกี่ยวกับขนาดรอยเท้าและการเสียดสี สำหรับการสำรวจที่กว้างขึ้นซึ่งครอบคลุม GUI ที่โฮสต์ด้วย โปรดดูบทความสรุป เครื่องมือทดสอบ API ฟรีที่ดีที่สุด

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

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

มีเครื่องมือมากมายที่ทำงานในเทอร์มินัล แต่ไม่ใช่ทุกเครื่องมือที่ให้ความรู้สึกเบา สำหรับรายการนี้ เครื่องมือจะผ่านคุณสมบัติสี่ประการ:

• ขนาดเล็ก. ไบนารีเดียว, การติดตั้ง pip/npm, หรือ npx แบบบรรทัดเดียว ไม่มีรันไทม์ที่คุณต้องตั้งค่าก่อน และไม่ควรมี daemon
• เริ่มทำงานเร็ว. เครื่องมือเปิดตัวและส่งคำขอโดยไม่ต้องวอร์มอัพ ไบนารีที่เขียนด้วย Rust และ Go ชนะในข้อนี้; สิ่งใดที่ต้องบูตรันไทม์หนักๆ จะแพ้
• การตั้งค่าต่ำหรือไม่มีเลย. คุณสามารถส่งคำขอแรกได้โดยไม่ต้องมีไฟล์โปรเจกต์ ไม่มีบัญชี ไม่ต้องเข้าสู่ระบบ การตั้งค่าเป็นทางเลือก สำหรับเมื่อคุณต้องการบันทึกและทำซ้ำ
• ผลลัพธ์ที่เหมาะสำหรับเทอร์มินัล. ผลลัพธ์จะแสดงในรูปแบบที่คุณสามารถอ่านได้อย่างรวดเร็วและส่งต่อไปยังคำสั่งอื่น รหัสออกมีความหมาย เพื่อให้ CI สามารถใช้เป็นเกณฑ์ได้

เครื่องมือส่วนใหญ่จะเน้นที่สามข้อแรก ส่วนสองข้อสุดท้ายจะเน้นที่ข้อสี่ เพราะนั่นคือจุดที่ไบนารีน้ำหนักเบาสร้างคุณค่าใน Pipeline หากคุณต้องการเจาะลึกด้านการโต้ตอบ การเรียกใช้ endpoint ด้วยมือ โปรดดูคู่มือ ทางเลือกของ curl สำหรับการทดสอบ REST API ซึ่งเจาะลึกถึงไคลเอนต์แบบแมนนวล

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

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

# มีอยู่แล้วในเครื่องของคุณ; ตรวจสอบเวอร์ชัน
curl --version

# POST JSON และพิมพ์เฉพาะสถานะ HTTP
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"}'

เหมาะที่สุดสำหรับ: การร้องขอแบบครั้งเดียวอย่างรวดเร็ว, สคริปต์, และสภาพแวดล้อมใดๆ ที่คุณไม่สามารถติดตั้งอะไรใหม่ได้ ข้อจำกัดที่ตรงไปตรงมา: การใช้งานค่อนข้างเก่า คุณต้องตั้งค่า header ด้วยตัวเอง, JSON ไม่มีการจัดรูปแบบสวยงาม (pretty-printed), และการยืนยันการตอบกลับหมายถึงการส่งต่อไปยัง jq และตรวจสอบรหัสออกด้วยตัวเอง มันส่งและแสดงผล; ไม่ได้ทดสอบ

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

HTTPie สร้างคำขอแบบเดียวกับ curl แต่ด้วยไวยากรณ์ที่สร้างมาสำหรับคนทั่วไป คำสั่งคือ http, header และฟิลด์ JSON เป็นคู่ key=value ที่เรียบง่าย และผลลัพธ์จะเป็นสีและจัดรูปแบบตามค่าเริ่มต้น มันเขียนด้วย Python ดังนั้นจึงต้องมีรันไทม์ Python ซึ่งทำให้หนักกว่าไบนารีเดียว แต่ยังคงเป็นการติดตั้งแบบบรรทัดเดียว

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

# POST JSON: age:=24 ส่งค่าตัวเลข, name= ส่งค่าสตริง
http POST httpbin.org/post name=acme age:=24 plan=pro

เหมาะที่สุดสำหรับ: การสำรวจ API ด้วยตนเองเมื่อคุณต้องการผลลัพธ์ที่อ่านง่ายโดยไม่ต้องใช้แฟล็ก ข้อจำกัดที่ตรงไปตรงมา: การเริ่มต้น Python ช้ากว่าไบนารีที่คอมไพล์อย่างเห็นได้ชัด และการติดตั้งในระบบที่สะอาดหมายถึงการดึง Python เข้ามาหากยังไม่มี เช่นเดียวกับ curl มันเป็นไคลเอนต์ ไม่ใช่ตัวรันการทดสอบ คุณอ่านการตอบกลับ แต่ไม่ได้ยืนยันผล

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

xh ได้เขียนซ้ำไวยากรณ์ที่เป็นมิตรของ HTTPie ด้วย Rust และมาในรูปแบบไบนารีที่ลิงก์แบบสแตติกเพียงตัวเดียว คุณจะได้การใช้งาน 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

เหมาะที่สุดสำหรับ: นักพัฒนาที่ชอบความรู้สึกแบบ HTTPie แต่ต้องการไบนารีเดียวที่รวดเร็วโดยไม่มีรันไทม์ ข้อจำกัดที่ตรงไปตรงมา: มันไม่ได้นำฟีเจอร์ทุกอย่างของ HTTPie มาใช้ และไม่มีระบบปลั๊กอิน มันยังใหม่กว่า HTTPie ดังนั้นระบบนิเวศรอบๆ จึงเล็กกว่า มันยังคงเป็นไคลเอนต์ ไม่ใช่เอนจินสำหรับการยืนยันผล

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

Hurl คือจุดที่รายการนี้เปลี่ยนจาก "ส่งคำขอ" ไปเป็น "ทดสอบการตอบสนอง" มันรันคำขอ HTTP ที่เขียนในไฟล์ .hurl แบบข้อความธรรมดาและยืนยันผลลัพธ์ มันเขียนด้วย Rust ขับเคลื่อนโดย libcurl และมาในรูปแบบไบนารีเดียวโดยไม่มีรันไทม์ การทดสอบอ่านได้เหมือนกับคำขอ ทำให้ง่ายต่อการตรวจสอบใน pull request

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   # ออกด้วยรหัสไม่เป็นศูนย์หากการยืนยันล้มเหลว

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

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

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

npm install -g stepci

# workflow.yml อธิบายขั้นตอน, การจับภาพ, และการตรวจสอบ
stepci run workflow.yml

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

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

k6 ตอบคำถามที่แตกต่างออกไป: ไม่ใช่ "การตอบกลับนี้ถูกต้องหรือไม่" แต่เป็น "มันรองรับโหลดได้หรือไม่" มันเขียนด้วย Go มาในรูปแบบไบนารีสแตติกเดียว และสคริปต์เป็น JavaScript ธรรมดา มันถูกสร้างมาเพื่อการใช้ทรัพยากรน้อยที่สุด เพื่อให้คุณสามารถส่งทราฟฟิกจริงจากแล็ปท็อปได้ ค่า Thresholds จะเปลี่ยนการทดสอบโหลดให้เป็นเกตแบบผ่าน/ไม่ผ่าน; หากเกินค่าหนึ่ง k6 จะออกด้วยรหัส 99 ซึ่ง pipeline จะอ่านว่าเป็นความล้มเหลว

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

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

Newman: รัน Postman collection แบบ Headless

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

npm install -g newman

# collection.json ที่ส่งออกจาก Postman; -e ส่งผ่าน environment
newman run collection.json -e staging.json

เหมาะที่สุดสำหรับ: ทีมที่ใช้ Postman อยู่แล้วและต้องการให้ collections ที่มีอยู่ทำงานแบบ headless ใน pipeline Newman คืนค่ารหัสออกที่ไม่ใช่ศูนย์เมื่อการทดสอบล้มเหลว ดังนั้นมันจึงเป็น CI gate ที่สะอาด ข้อจำกัดที่ตรงไปตรงมา: มันเป็นแพ็คเกจ Node และรันได้เฉพาะ Postman-format collections เท่านั้น ดังนั้นมันจะมีประโยชน์ที่สุดหากคุณอยู่ในระบบนิเวศนั้นอยู่แล้ว มันรันการทดสอบที่สร้างโดยใครบางคนใน GUI; การสร้างยังคงเกิดขึ้นที่นั่น

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

Apidog CLI เป็นส่วนที่มีน้ำหนักเบาของ Apidog เป็นแพ็กเกจ npm ชื่อ apidog-cli ที่รันสถานการณ์การทดสอบที่คุณออกแบบด้วยภาพใน Apidog ได้โดยตรงจากเทอร์มินัล ส่วนการสร้างการทดสอบจะอยู่ใน GUI ซึ่งการเชื่อมโยงคำขอ การดึงตัวแปร และการเขียน Assertion ทำได้อย่างรวดเร็ว; CLI เป็นส่วนเล็กๆ ที่รันสถานการณ์เหล่านั้นแบบ Headless และส่งรหัสออกให้คุณ 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 แล้วคัดลอกคำสั่ง apidog run ที่สร้างขึ้นโดยมี ID ที่กรอกไว้แล้ว ตัวรายงาน -r cli จะพิมพ์ผลลัพธ์ทีละขั้นตอนและสรุปในเทอร์มินัล; เพิ่ม -r cli,junit เมื่อแดชบอร์ด CI ต้องการวิเคราะห์ผลลัพธ์ เช่นเดียวกับเครื่องมือข้างต้น apidog run จะออกจากระบบด้วยรหัส 0 เมื่อ assertion ทั้งหมดผ่าน และด้วยรหัสที่ไม่ใช่ศูนย์เมื่อมีสิ่งใดล้มเหลว ดังนั้น pipeline จะถือว่าเป็น gate ที่สะอาดตา ผลลัพธ์ของมันเป็น JSON ที่มีโครงสร้างพร้อม agentHints.nextSteps ซึ่งทำให้ AI coding agent สามารถรันและอ่านได้ง่ายเช่นกัน

เหมาะที่สุดสำหรับ: ทีมที่ต้องการสร้างสถานการณ์ที่ซับซ้อนและหลายขั้นตอนในตัวแก้ไขภาพ แต่รันแบบ headless ใน CI หรือจาก agent ข้อจำกัดที่ตรงไปตรงมา: ไม่เหมือน curl หรือ xh มันผูกติดอยู่กับสถานการณ์ที่คุณเก็บไว้ในโปรเจกต์ Apidog ดังนั้นมันจึงเป็นตัวเลือกแบบ integrated-platform ไม่ใช่ไคลเอนต์ HTTP ธรรมดา สำหรับชุดคำสั่งทั้งหมด โปรดดู คู่มือ Apidog CLI ฉบับสมบูรณ์, การอ้างอิงคำสั่ง apidog run และคำแนะนำเกี่ยวกับวิธี ทดสอบ REST API จาก command line ด้วย Apidog CLI

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

เครื่องมือที่เหมาะสมขึ้นอยู่กับว่าคุณต้องการทำอะไรเกินกว่า "ส่งคำขอเดียว" ไปมากแค่ไหน

เริ่มต้นจากด้านบนสำหรับงานที่ต้องทำด้วยตนเอง ใช้ curl หรือ xh เพื่อทดลอง endpoint เปลี่ยนมาใช้ Hurl เมื่อคุณต้องการให้การตรวจสอบเหล่านั้นทำงานในการควบคุมเวอร์ชัน นำ k6 มาใช้เมื่อคำถามเปลี่ยนไปสู่โหลด และ Newman หากการทดสอบของคุณมีอยู่ใน Postman อยู่แล้ว เลือก Apidog CLI เมื่อคุณต้องการสร้างสถานการณ์ที่ซับซ้อนในตัวแก้ไขและรันแบบ headless ในทุกที่ หากคุณกำลังพิจารณาเครื่องมือเหล่านี้เทียบกับเวิร์กโฟลว์ GUI-free แบบเต็ม คู่มือ เครื่องมือทดสอบ API แบบ headless ครอบคลุมการรันการทดสอบโดยไม่มีอินเทอร์เฟซใดๆ เลย

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

เครื่องมือ CLI น้ำหนักเบาจะชนะในวันที่ GUI ทำให้คุณช้าลง: เมื่อคุณจมอยู่ในเทอร์มินัล เมื่อการทดสอบจำเป็นต้องทำงานใน CI โดยไม่มีมนุษย์ และบ่อยขึ้นเมื่อ AI agent ทำการตรวจสอบให้คุณ curl และ xh ทำให้การวนลูปแบบแมนนวลกระชับ Hurl และ Step CI เปลี่ยนคำขอชั่วคราวให้เป็นการทดสอบที่ทำซ้ำได้ k6 ตอบคำถามเรื่องโหลด Newman รันสิ่งที่คุณสร้างไว้ใน Postman อยู่แล้ว

Apidog CLI เชื่อมช่องว่างระหว่างการสร้างการทดสอบกับการรันที่ใดก็ได้ คุณออกแบบสถานการณ์เพียงครั้งเดียวใน Apidog จากนั้น apidog run จะเรียกใช้งานจากเทอร์มินัล, Pipeline หรือ agent และรหัสออกจากระบบจะตัดสินว่า build ยังคงเป็นสีเขียวหรือไม่ ดาวน์โหลด Apidog สร้างสถานการณ์เดียว และใส่คำสั่ง apidog run ลงในคอนฟิก CI ของคุณเพื่อดูการวนลูปทั้งหมด