เครื่องมือ CLI โอเพนซอร์สฟรีสำหรับทดสอบ API

บทช่วยสอนการทดสอบ API ส่วนใหญ่จะแนะนำให้คุณใช้ GUI แต่ถ้าคุณใช้ชีวิตในเทอร์มินัล รันการทดสอบใน CI หรือต้องการเครื่องมือที่คุณสามารถอ่านซอร์สโค้ดได้ การใช้บรรทัดคำสั่งคือจุดที่การทดสอบ API น่าสนใจ เครื่องมือ CLI แบบโอเพนซอร์สให้สิ่งที่คุณไม่สามารถหาได้จากผลิตภัณฑ์โฮสต์: ใบอนุญาตที่คุณตรวจสอบได้, ไบนารีที่คุณสามารถโฮสต์เองได้ และไฟล์คอนฟิกที่คุณสามารถคอมมิตไปพร้อมกับโค้ดของคุณ

นี่เป็นคำถามที่แตกต่างจาก "เครื่องมือใดที่เร็วที่สุด" หรือ "ไบนารีใดที่เล็กที่สุด" ในที่นี้จะพิจารณาในแง่ของใบอนุญาตและการควบคุม คุณสามารถรันมันภายในเครือข่ายของคุณเองได้โดยไม่ต้องมีบัญชีหรือไม่? ซอร์สโค้ดอยู่บน GitHub ภายใต้ใบอนุญาตที่ได้รับการรับรองจาก OSI จริงหรือไม่? มันจะยังคงทำงานได้หรือไม่หากผู้ขายเปลี่ยนราคาในไตรมาสหน้า? นี่คือคำถามที่รายการนี้จะตอบ

ด้านล่างนี้คือเครื่องมือ CLI แบบโอเพนซอร์สฟรีแปดรายการสำหรับการทดสอบ REST, GraphQL และ HTTP APIs โดยแต่ละรายการมีใบอนุญาตที่ถูกต้อง, คำสั่งติดตั้งจริง และหนึ่งคำสั่งที่แสดงการทำงาน หากคุณต้องการสำรวจเพิ่มเติมซึ่งรวมถึงเครื่องมือที่โฮสต์ไว้ โปรดดูสรุป เครื่องมือทดสอบ API ฟรีที่ดีที่สุด สำหรับวิธีการใช้เทอร์มินัลเป็นอันดับแรกในการเข้าถึงปลายทางด้วยตนเอง คู่มือ ทางเลือกของ curl สำหรับการทดสอบ REST API ครอบคลุมด้านการโต้ตอบ

อะไรที่ทำให้เครื่องมือ CLI เป็น “โอเพนซอร์ส” สำหรับการทดสอบ API

เครื่องมือมากมายให้ดาวน์โหลดฟรี แต่นั่นไม่เหมือนกับโอเพนซอร์ส สำหรับรายการนี้ เครื่องมือจะผ่านเกณฑ์สามข้อ:

• ใบอนุญาตจริง ซอร์สโค้ดเป็นสาธารณะภายใต้ใบอนุญาตที่ได้รับการรับรองจาก OSI (MIT, Apache-2.0, MPL-2.0, AGPL-3.0, BSD) คุณสามารถอ่าน, fork และทราบสิ่งที่คุณได้รับอนุญาตให้ทำ
• โฮสต์เองได้, ไม่ต้องมีบัญชี คุณสามารถรันทั้งหมดบนเครื่องของคุณเองหรือ CI runner โดยไม่ต้องสมัครอะไร ไม่มีค่าใช้จ่ายที่นั่ง, ไม่มีข้อกำหนดในการโทรกลับบ้าน (phone-home).
• ได้รับการดูแลและตรวจสอบได้ โครงการอยู่บน GitHub พร้อมประวัติการคอมมิตและปัญหาที่มองเห็นได้ คุณจึงสามารถตัดสินได้ว่ายังมีการพัฒนาอยู่หรือไม่ก่อนที่คุณจะสร้างไปป์ไลน์โดยใช้มัน

เครื่องมือทุกรายการด้านล่างนี้เป็นไปตามสองข้อแรก ฉันได้ระบุเครื่องมือที่ไม่เป็นไปตามข้อที่สามแล้ว การเลือกใบอนุญาตมีความสำคัญมากกว่าที่เห็น: AGPL-3.0 (k6) มีข้อผูกพันแบบ copyleft หากคุณสร้างบริการโดยใช้มัน ในขณะที่ MIT และ Apache-2.0 เป็นแบบอนุญาต (permissive) อ่านใบอนุญาตก่อนที่คุณจะนำเครื่องมือไปฝังในผลิตภัณฑ์

Hurl: การทดสอบ HTTP แบบข้อความธรรมดา, ไบนารี Rust เดียว

Hurl รันคำขอ HTTP ที่เขียนในรูปแบบข้อความธรรมดาและยืนยันการตอบกลับ มันถูกสร้างโดย Orange-OpenSource ด้วย Rust โดยใช้ libcurl เป็นพื้นฐาน และมาในรูปแบบไบนารีเดียว การทดสอบอ่านได้เกือบเหมือนกับคำขอ ทำให้ง่ายต่อการตรวจสอบในการส่ง Pull Request

ใบอนุญาต: Apache-2.0. ซอร์สโค้ด: github.com/Orange-OpenSource/hurl.

brew install hurl   # or: cargo install --locked hurl

# login.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

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

Step CI: เวิร์กโฟลว์ API แบบ YAML ที่สร้างมาเพื่อ CI

Step CI เป็น runner เวิร์กโฟลว์ที่กำหนดค่าด้วย YAML สร้างขึ้นสำหรับการบูรณาการอย่างต่อเนื่อง (Continuous Integration) มันครอบคลุม REST, GraphQL, gRPC, tRPC และ SOAP ในไฟล์เวิร์กโฟลว์เดียว และสามารถทดสอบโหลดและตรวจสอบเทียบกับ OpenAPI schema ได้ ตัว runner และ CLI ใช้งานได้ฟรีตลอดไป

ใบอนุญาต: MPL-2.0. ซอร์สโค้ด: github.com/stepci/stepci.

npm install -g stepci

# workflow.yml describes steps, checks, and captures
stepci run workflow.yml

ดีที่สุดสำหรับ: ทีมที่ต้องการไฟล์ประกาศ (declarative file) เพียงไฟล์เดียวที่อธิบายการไหลของ API แบบหลายขั้นตอน และรันในลักษณะเดียวกันทั้งบนเครื่องและใน CI ข้อจำกัดที่แท้จริง: MPL-2.0 เป็นใบอนุญาตแบบ weak copyleft ดังนั้นหากคุณแก้ไขไฟล์ของ Step CI เอง คุณจะต้องแบ่งปันการเปลี่ยนแปลงเหล่านั้นกลับคืนไป การใช้งานเพื่อทดสอบแอปของคุณไม่มีข้อผูกพันดังกล่าว

Schemathesis: การทดสอบแบบ property-based จาก schema ของคุณ

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

ใบอนุญาต: MIT. ซอร์สโค้ด: github.com/schemathesis/schemathesis.

uv pip install schemathesis   # or: pip install schemathesis

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

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

Dredd: การทดสอบสัญญา (contract testing) เทียบกับคำอธิบาย API ของคุณ

Dredd ตรวจสอบว่า API ที่ใช้งานจริงของคุณตรงกับเอกสารคำอธิบายหรือไม่ ชี้ไปที่ไฟล์ OpenAPI (หรือ API Blueprint) และแบ็กเอนด์ที่กำลังทำงานอยู่ จากนั้นมันจะเล่นซ้ำทุกคำขอที่ถูกบันทึกไว้ และเปรียบเทียบการตอบสนองจริงกับข้อกำหนด มันไม่ขึ้นกับภาษาและรองรับ hooks สำหรับการตั้งค่าและยกเลิก

ใบอนุญาต: MIT. ซอร์สโค้ด: github.com/apiaryio/dredd.

npm install -g dredd

dredd apiary.apib http://127.0.0.1:3000

ดีที่สุดสำหรับ: การพิสูจน์ว่าเอกสารและการนำไปใช้ของคุณไม่แยกจากกัน ข้อจำกัดที่แท้จริงและสำคัญ: พื้นที่เก็บข้อมูลของ Dredd ถูกเก็บถาวรในเดือนพฤศจิกายน 2024 และเป็นแบบอ่านอย่างเดียว มันยังคงทำงานได้ แต่ไม่ได้ถูกบำรุงรักษาอีกต่อไป ดังนั้นควรถือว่าเป็นเครื่องมือที่เสถียรแต่จะไม่มีการแก้ไขในอนาคต หากคุณต้องการตัวตรวจสอบที่ขับเคลื่อนด้วย schema ที่ได้รับการดูแลอย่างแข็งขัน Schemathesis เป็นทางเลือกที่ปลอดภัยกว่า

k6: การทดสอบโหลดที่เขียนสคริปต์ด้วย JavaScript

k6 คือเครื่องมือทดสอบโหลดและประสิทธิภาพของ Grafana คุณเขียนสคริปต์การทดสอบด้วย JavaScript หรือ TypeScript และเอนจิ้น Go ที่รวดเร็วจะขับเคลื่อนการทดสอบเหล่านั้นในขนาดที่ใหญ่ เป็นตัวเลือกโอเพนซอร์สที่เหมาะสมเมื่อคุณต้องการทราบว่า API ของคุณทำงานอย่างไรภายใต้ผู้ใช้งานเสมือนหลายร้อยหรือหลายพันคน ไม่ใช่แค่ว่าคำขอเดียวผ่านหรือไม่

ใบอนุญาต: AGPL-3.0. ซอร์สโค้ด: github.com/grafana/k6.

brew install k6

k6 new script.js   # generates a starter test
k6 run script.js

ดีที่สุดสำหรับ: การทดสอบประสิทธิภาพและ soak testing ที่อยู่ในที่เก็บเดียวกันกับ functional tests ของคุณ ข้อจำกัดที่แท้จริง: AGPL-3.0 เป็น strong copyleft การรันการทดสอบก็ไม่เป็นไร แต่ถ้าคุณสร้างและเผยแพร่บริการโดยใช้โค้ดของ k6 ใบอนุญาตจะมีข้อผูกพันจริง; โปรดอ่านก่อน k6 ยังเน้นที่โหลด ไม่ใช่การยืนยันสัญญาแบบละเอียด

Newman: รัน Postman collections โดยไม่ต้องใช้ GUI

Newman เป็น command-line collection runner ของ Postman เอง หากทีมของคุณมีคำขอ API และการทดสอบที่บันทึกไว้เป็น Postman collection อยู่แล้ว Newman จะรัน collection นั้นจากเทอร์มินัลหรือใน CI โดยไม่ต้องใช้แอปเดสก์ท็อป เป็นวิธีมาตรฐานในการนำเวิร์กโฟลว์ของ Postman เข้าสู่ไปป์ไลน์

ใบอนุญาต: Apache-2.0. ซอร์สโค้ด: github.com/postmanlabs/newman.

npm install -g newman

newman run my-collection.json -e staging-environment.json

ดีที่สุดสำหรับ: ทีมที่มี Postman collections อยู่แล้วที่ต้องการรันใน CI โดยไม่ต้องจ่ายค่า Postman seats เพิ่มเติม ข้อจำกัดที่แท้จริง: มันผูกติดอยู่กับรูปแบบ Postman collection ดังนั้นคุณจะเขียนการทดสอบใน UI ของ Postman (หรือ JSON) แทนที่จะเป็นไฟล์คอนฟิกธรรมดา มันรัน collection ได้ แต่ไม่ได้ออกแบบหรือสร้าง mock API

Tavern: การทดสอบ API ในรูปแบบปลั๊กอิน pytest

Tavern เป็นไลบรารี Python, CLI และปลั๊กอิน pytest ที่อธิบายการทดสอบ API ในรูปแบบ YAML เนื่องจากมันเชื่อมต่อกับ pytest คุณจึงได้รับระบบนิเวศ pytest ทั้งหมดฟรี: fixtures, การรายงาน, การทำงานแบบขนาน และการรวม CI ที่คุณอาจใช้งานอยู่แล้ว มันรองรับ REST, MQTT และ gRPC

ใบอนุญาต: MIT. ซอร์สโค้ด: github.com/taverntesting/tavern.

pip install tavern

# test_login.tavern.yaml sits next to your other tests
pytest test_login.tavern.yaml

ดีที่สุดสำหรับ: บริษัท Python ที่รัน pytest อยู่แล้วและต้องการให้การทดสอบ API อยู่เคียงข้าง unit tests ข้อจำกัดที่แท้จริง: มันสมมติว่าคุณคุ้นเคยกับการตั้งค่าการทดสอบ Python หากสแต็กของคุณไม่ใช่ Python การพึ่งพา pytest จะกลายเป็นอุปสรรคมากกว่าคุณสมบัติ

Venom: การทดสอบการรวมระบบแบบ multi-executor จาก OVHcloud

Venom จาก OVHcloud รันการทดสอบการรวมระบบ (integration tests) ข้ามประเภท executor หลายประเภท: คำขอ HTTP, สคริปต์เชลล์, IMAP, เว็บ, ฐานข้อมูล และอื่นๆ มันเขียนด้วย Go, ใช้ชุดทดสอบ YAML และปล่อยไฟล์ผลลัพธ์ xUnit ที่ระบบ CI สามารถอ่านได้โดยตรง มันโดดเด่นเมื่อการทดสอบเดียวจำเป็นต้องเข้าถึงมากกว่าแค่ปลายทาง HTTP

ใบอนุญาต: BSD (แก้ไขแล้ว). ซอร์สโค้ด: github.com/ovh/venom.

# download the binary from GitHub releases, then:
venom run testsuite.yml

ดีที่สุดสำหรับ: เวิร์กโฟลว์แบบ end-to-end ที่ผสมผสานการเรียก API กับการตรวจสอบฐานข้อมูล หรือขั้นตอนสคริปต์ในชุดทดสอบเดียว ข้อจำกัดที่แท้จริง: ด้วย executor จำนวนมาก YAML จะมีรายละเอียดมาก และเอกสารจะสมมติว่าคุณจะนำตัวอย่างจาก repo มาประกอบกัน

Apidog อยู่ตรงไหน (และหมายเหตุที่ตรงไปตรงมา)

นี่คือส่วนที่ตรงไปตรงมา Apidog ไม่ใช่โอเพนซอร์ส เป็นผลิตภัณฑ์เชิงพาณิชย์ที่มี Free Tier ดังนั้นจึงไม่ควรอยู่ในรายการเครื่องมือที่เปิดเผยซอร์สโค้ด อย่างไรก็ตาม มันคุ้มค่าที่จะรู้จักด้วยเหตุผลหนึ่งคือ เครื่องมือข้างต้นแต่ละตัวทำงานเพียงอย่างเดียว และการนำ Hurl บวก Schemathesis บวก Newman บวก mock server มารวมกันเป็นเวิร์กโฟลว์ที่สอดคล้องกันนั้นเป็นงานจริงที่คุณต้องดูแลรักษาเอง

Apidog รวมการออกแบบ, การทดสอบ, การจำลอง และการจัดทำเอกสารเข้าไว้ในแพลตฟอร์มเดียว และ apidog-cli นำด้านการทดสอบมาสู่เทอร์มินัล คุณสร้างสถานการณ์การทดสอบเพียงครั้งเดียว จากนั้นรันใน CI ด้วยคำสั่งเดียว:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN>   # exits 0 on all-pass, non-zero on failure

เอาต์พุตเป็น JSON ที่มีโครงสร้างพร้อม agentHints.nextSteps ซึ่งทำให้ง่ายต่อการเขียนสคริปต์หรือส่งให้เอเจนต์ AI คู่มือ apidog-cli ฉบับสมบูรณ์ จะอธิบายชุดคำสั่งทั้งหมด ดังนั้น: แม้จะไม่ใช่โอเพนซอร์ส แต่ Free Tier บวก CLI จะเป็นทางเลือกแบบครบวงจรแทนการนำเครื่องมือที่ทำหน้าที่เดียวหลายตัวมารวมกัน หากใบอนุญาตที่คุณสามารถตรวจสอบได้เป็นข้อกำหนดที่เข้มงวด ให้เลือกจากแปดตัวข้างต้น หากเวิร์กโฟลว์แบบรวมระบบมีความสำคัญมากกว่า นี่คือข้อแลกเปลี่ยน

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

เลือกเครื่องมือให้เหมาะสมกับงาน เลือก Hurl หรือ Newman เมื่อคุณต้องการการตรวจสอบคำขอที่รวดเร็วและอ่านง่าย; Schemathesis เมื่อคุณมี schema และต้องการให้พบข้อผิดพลาดให้คุณ; k6 เมื่อคำถามคือเรื่องขนาด; Tavern หรือ Venom เมื่อการทดสอบจำเป็นต้องอยู่ในชุดที่ใหญ่ขึ้น หากคุณกำลังเปรียบเทียบสิ่งเหล่านี้กับกระบวนการที่ใหญ่ขึ้น คู่มือกลยุทธ์การทดสอบ API จะครอบคลุมว่าแต่ละประเภทเหมาะสมกับที่ใด และบทความ เครื่องมือทดสอบ API แบบ Headless จะพิจารณาการรันการทดสอบโดยไม่มี UI เลย

สรุป

เครื่องมือ CLI แบบโอเพนซอร์สช่วยให้คุณทดสอบ API ที่คุณสามารถอ่าน, fork และรันได้ตามเงื่อนไขของคุณเอง Hurl และ Newman จัดการการตรวจสอบคำขอในชีวิตประจำวัน, Schemathesis และ Dredd บังคับใช้สัญญาของคุณ, k6 ผลักดันประสิทธิภาพ, และ Tavern กับ Venom รวมการทดสอบ API เข้ากับชุดที่กว้างขึ้น เลือกตามใบอนุญาตและตามงานที่คุณต้องการทำให้เสร็จ ไม่มีอะไรหยุดคุณจากการรันสองอย่างพร้อมกัน

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