เครื่องมือทดสอบ API ออนไลน์ฟรี: สรุปฉบับใช้งานจริง

คุณไม่จำเป็นต้องมีใบอนุญาตแบบเสียเงินเพื่อทดสอบ API อย่างจริงจัง เครื่องมือฟรีจำนวนมากสามารถส่ง request, ตรวจ status code, ตรวจ response body, จัดการ environment และรันชุดทดสอบขนาดเล็กก่อน deploy ได้ สิ่งสำคัญคือเลือกเครื่องมือที่ไม่จำกัดฟีเจอร์หลักเมื่อ workflow ของคุณเริ่มจริงจังขึ้น

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

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

“ออนไลน์ฟรี” หมายถึงอะไร

คำว่า “ออนไลน์” ในบริบทของ API testing มักหมายถึงหนึ่งในสามรูปแบบนี้:

1. ทำงานบนเบราว์เซอร์: ไม่ต้องติดตั้ง เช่น Hoppscotch
2. เดสก์ท็อป + ซิงค์คลาวด์: ติดตั้งแอป แต่แชร์/ซิงค์ผ่านเว็บได้ เช่น Apidog, Postman
3. โอเพนซอร์ส/self-hosted: ฟรีระยะยาว แต่คุณต้องดูแลการรันเอง เช่น SoapUI หรือ Hoppscotch แบบ self-host

ก่อนเลือก ให้ตรวจ 3 ข้อจำกัดหลักของแพลนฟรี:

• Collaboration: ใช้คนเดียวฟรี แต่เพิ่มทีมแล้วคิดตาม seat
• Run history / monitoring: เก็บผลลัพธ์ย้อนหลังได้จำกัด
• Automation quota: scheduled run หรือ CI run อาจนับเป็นหน่วยใช้งาน

ถ้าคุณยังแยกไม่ชัดว่าควรทดสอบระดับ “scenario” หรือ “case” อย่างไร อ่านเพิ่มเติมได้ที่ สถานการณ์การทดสอบและกรณีทดสอบ

วิธีประเมินเครื่องมือแบบเร็ว

ใช้ test flow เดียวกันกับทุกเครื่องมือ เพื่อเปรียบเทียบอย่างยุติธรรม:

1. สร้าง environment เช่น baseUrl, token
2. ส่ง request แรก เช่น login หรือ create resource
3. assert อย่างน้อย:
   • status code
   • field สำคัญใน response
4. ดึงค่าจาก response ไปใช้ใน request ที่สอง
5. รันเป็น collection หรือ scenario
6. export เก็บไว้ใน version control ถ้าทำได้

ตัวอย่าง assertion ขั้นต่ำที่ควรมี:

Status code = 200 หรือ 201
Response มี field ที่ต้องใช้ต่อ เช่น id, token, status
Response time ไม่เกิน threshold ที่ทีมยอมรับ
Business value ถูกต้อง เช่น currency, role, order status

เครื่องมือที่คุ้มค่ากับเวลาของคุณ

Apidog

Apidog เป็นแพลตฟอร์ม API แบบครบวงจรสำหรับออกแบบ ดีบัก ทดสอบอัตโนมัติ ทำ mock และสร้างเอกสาร API ในที่เดียว แพลนฟรีรองรับ REST, GraphQL, SOAP และ WebSocket และใช้สร้าง test scenario ที่ chain request ต่อกันได้โดยไม่ต้องใช้บัตรเครดิต

จุดที่เหมาะกับ workflow จริง:

• ใช้ environment variables แยก dev, staging, production
• สร้าง request chain เช่น login → create order → get order
• ใช้ visual assertions เพื่อตรวจ response
• ใช้ built-in mock server เพื่อทดสอบ endpoint ที่ยังไม่พร้อม
• ใช้เดสก์ท็อปบน Windows, macOS และ Linux พร้อม cloud sync

ตัวอย่าง flow ที่ควรลองใน Apidog:

POST /auth/login
  -> เก็บ token

POST /orders
  -> ใช้ token
  -> assert status = 201
  -> เก็บ orderId

GET /orders/{orderId}
  -> assert response.id = orderId
  -> assert response.status มีค่าตามที่คาดหวัง

เริ่มใช้งานได้จาก ดาวน์โหลด Apidog

Hoppscotch

Hoppscotch ทำงานบนเบราว์เซอร์และเป็นโอเพนซอร์ส เหมาะเมื่อคุณต้องการส่ง request อย่างรวดเร็วโดยไม่ติดตั้งแอป รองรับ REST, GraphQL และ WebSocket รวมถึง environment และ collection

เหมาะกับ:

• ทดสอบ endpoint แบบเร็ว
• ใช้งานคนเดียว
• ใช้บนเครื่องที่ไม่ต้องการติดตั้งเครื่องมือเพิ่ม

ข้อจำกัดที่ควรรู้:

• automation ขั้นสูงไม่เด่นเท่าเครื่องมือทดสอบเฉพาะทาง
• collaboration และ history ขั้นสูงอยู่ในแผนทีมแบบเสียเงิน

Postman แพลนฟรี

Postman เป็นเครื่องมือที่นักพัฒนาจำนวนมากคุ้นเคย แพลนฟรีครอบคลุม manual request, collections, environments และจำนวน automated run รายเดือนแบบจำกัด

เหมาะกับ:

• ทีมที่มี collection เดิมอยู่แล้ว
• developer onboarding เพราะหลายคนใช้งานเป็น
• export collection ไปใช้กับ Newman ใน CI

ตัวอย่างรัน Postman collection ด้วย Newman:

newman run collection.json \
  --environment staging.postman_environment.json

ข้อจำกัดหลักคือ collaboration seat และ automation quota หากคุณกำลังเทียบ workflow กับเครื่องมืออื่น อ่าน วิธีการทดสอบ API ด้วย Postman

Insomnia

Insomnia เป็นเดสก์ท็อปไคลเอ็นต์สำหรับ REST, GraphQL และ gRPC จุดเด่นคือ UI ที่สะอาดและเหมาะกับการดีบัก API แบบโฟกัส

เหมาะกับ:

• developer ที่ต้องการ client เบาและไม่ซับซ้อน
• การทดสอบส่วนบุคคล
• scripted test ขนาดเล็ก

ดูขั้นตอนใช้งานเพิ่มเติมได้ที่ การใช้ Insomnia เพื่อทดสอบ API

SoapUI โอเพนซอร์ส

SoapUI เป็นตัวเลือกที่ใช้มายาวนานสำหรับ SOAP และยังรองรับ REST เวอร์ชันโอเพนซอร์สเหมาะกับ functional test และ data-driven test โดยเฉพาะกับระบบ legacy

เหมาะกับ:

• SOAP API
• WSDL-based testing
• data-driven test ที่ต้องวนหลายชุดข้อมูล

ข้อจำกัด:

• แอป Java ค่อนข้างหนัก
• reporting ที่สวยและฟีเจอร์ขั้นสูงอยู่ใน ReadyAPI แบบเสียเงิน

Thunder Client

Thunder Client เป็น extension ใน VS Code เหมาะถ้าคุณใช้ VS Code เป็นหลักและต้องการทดสอบ API โดยไม่เปลี่ยนหน้าต่าง

เหมาะกับ:

• REST/GraphQL request จากใน editor
• collection ขนาดเล็ก
• การทดสอบแบบไม่ต้องเขียนสคริปต์มาก

ข้อจำกัดคือ Git sync และ team features ต้องใช้แผนเสียเงิน

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

เครื่องมือ	ประเภท	โปรโตคอล	จุดแข็งของแพลนฟรี	ข้อจำกัดหลัก
Apidog	เดสก์ท็อป + ซิงค์คลาวด์	REST, GraphQL, SOAP, WebSocket	ออกแบบ, ทดสอบ, จำลอง, เอกสารครบวงจร	ทีมขนาดใหญ่ต้องการที่นั่งแบบเสียเงิน
Hoppscotch	เบราว์เซอร์, โอเพนซอร์ส	REST, GraphQL, WebSocket	ไม่ต้องติดตั้ง, รวดเร็ว	ระบบอัตโนมัติเบากว่า
Postman	เดสก์ท็อป + คลาวด์	REST, GraphQL, gRPC	คุ้นเคย, มีเอกสารประกอบดี	การรันแบบจำกัด, ที่นั่งแบบเสียเงิน
Insomnia	เดสก์ท็อป	REST, GraphQL, gRPC	ประสบการณ์ผู้ใช้ดีบักที่สะอาดตา	ชุดคุณสมบัติการทดสอบเล็กกว่า
SoapUI	เดสก์ท็อป, โอเพนซอร์ส	SOAP, REST	ทดสอบ SOAP และขับเคลื่อนด้วยข้อมูลได้ลึกซึ้ง	แอปพลิเคชันหนัก, การรายงานเสียเงิน
Thunder Client	ส่วนขยาย VS Code	REST, GraphQL	สะดวกในตัวแก้ไข	ซิงค์และคุณสมบัติทีมเสียเงิน

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

เริ่มจาก protocol ที่คุณใช้งานจริง:

• ใช้ REST / GraphQL: เครื่องมือส่วนใหญ่ในบทความนี้เพียงพอ
• ใช้ SOAP: เลือกเครื่องมือที่รองรับ SOAP โดยตรง เช่น Apidog หรือ SoapUI อ่านเพิ่มได้ที่ เครื่องมือทดสอบ SOAP API ออนไลน์
• ใช้ WebSocket: จำกัดตัวเลือกไปที่ Apidog, Hoppscotch หรือ WebSocket client เฉพาะทาง

จากนั้นเลือกตามสภาพแวดล้อมการทำงาน:

เงื่อนไข	ควรเลือก
ไม่อยากติดตั้งอะไร	Browser tool
ต้องยิง localhost หรือ internal network	Desktop app
ต้องทำงาน offline	Desktop app
ต้องแชร์ collection กับทีม	Desktop + cloud sync หรือ hosted workspace
ต้องออกแบบ + mock + test ในที่เดียว	All-in-one platform

แนะนำให้ลองด้วย flow เดียวกัน เช่น:

1. POST /login
2. เก็บ access_token
3. GET /profile ด้วย token
4. assert status code
5. assert response.email หรือ response.id

เครื่องมือที่ทำขั้นตอนนี้ได้ง่ายที่สุดสำหรับทีมคุณคือจุดเริ่มต้นที่ดี สำหรับแนวทางเขียน assertion อ่าน การเขียนการยืนยัน API ที่มีประโยชน์

เครื่องมือฟรีกับ CI Pipelines

เครื่องมือฟรีจำนวนมากสามารถใช้กับ CI ได้:

• Postman export collection แล้วรันด้วย Newman
• Hoppscotch มี CLI
• Apidog รัน scenario จาก runner ของตัวเองและทำงานร่วมกับ pipeline ได้

ข้อจำกัดของแพลนฟรีมักเป็น “จำนวนรัน” มากกว่า “ทำ CI ไม่ได้” ดังนั้น nightly test suite มักเพียงพอ แต่ถ้ารันทุก commit ใน repo ที่ activity สูง อาจชน quota เร็ว

ตัวอย่าง GitHub Actions สำหรับ Newman:

name: API Tests

on:
  push:
    branches: [main]

jobs:
  api-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Newman
        run: npm install -g newman

      - name: Run API collection
        run: newman run collection.json --environment staging.json

ถ้า CI/CD เป็นเป้าหมายหลัก อ่าน ทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD

อย่าทดสอบแค่ “200 OK”

การทดสอบที่ตรวจแค่ status code มักพลาด bug สำคัญ ควรตรวจอย่างน้อย:

• status code ถูกต้องตามกรณี เช่น 200, 201, 400, 401, 404
• response schema มี field ที่จำเป็น
• business value ถูกต้อง
• error response มี message/code ที่ client ใช้ได้
• response time อยู่ในช่วงที่ยอมรับได้

ตัวอย่าง checklist สำหรับ REST endpoint:

GET /users/{id}

[ ] 200 เมื่อ id มีอยู่จริง
[ ] 404 เมื่อ id ไม่มีอยู่
[ ] response.id ตรงกับ path parameter
[ ] response.email เป็น string
[ ] ไม่มี field ลับ เช่น password_hash
[ ] latency ไม่เกิน threshold

อ่านพื้นฐานเพิ่มเติมที่ รหัสสถานะ HTTP ที่ REST API ควรใช้

ข้อผิดพลาดที่พบบ่อยกับเครื่องมือฟรี

1. เลือกเหมือนเป็น trial ชั่วคราว

อย่าเลือกเครื่องมือที่คุณรู้อยู่แล้วว่าจะต้องย้ายออกในหนึ่งเดือน เลือกเครื่องมือที่แพลนฟรีรองรับงานหลักได้อย่างน้อยตลอดช่วงเริ่มต้นของโปรเจกต์

2. ไม่ใช้ environment variables

หลีกเลี่ยงการ hard-code base URL หรือ token ในทุก request

ควรใช้แบบนี้:

{{baseUrl}}/users
Authorization: Bearer {{token}}

ไม่ควรใช้แบบนี้:

https://staging.example.com/users
Authorization: Bearer eyJhbGciOi...

3. ไม่สนใจ response time

ถ้า endpoint ที่ควรตอบใน 100 ms ใช้เวลา 800 ms นั่นคือสัญญาณที่ควรตรวจ แม้ยังไม่ได้ทำ load testing ก็ตาม

สำหรับงาน performance โดยตรง อ่าน บทช่วยสอนการทดสอบประสิทธิภาพ API

4. ไม่ export งานออกมาเก็บ

แพลนฟรีของ hosted tool อาจเปลี่ยนเงื่อนไขได้ ควร export collection/spec แล้วเก็บใน Git เป็นระยะ

ตัวอย่างโครงสร้าง repo:

api-tests/
  collections/
    users.collection.json
    orders.collection.json
  environments/
    staging.json
    production.example.json
  README.md

Browser tool vs Desktop app

เครื่องมือบนเบราว์เซอร์เหมาะกับการเริ่มเร็ว แต่ทำงานภายใต้ browser sandbox ซึ่งอาจจำกัดบางกรณี เช่น:

• เรียก localhost
• เรียก private network
• อัปโหลดไฟล์ใหญ่
• payload binary บางประเภท

Desktop app เหมาะเมื่อคุณต้องการ:

• เข้าถึง local service โดยตรง
• ทดสอบ API ใน internal network
• ทำงาน offline
• จัดการ payload ขนาดใหญ่
• ใช้ native network stack

แนวทางที่ทีมจำนวนมากเลือกคือ desktop app ที่ซิงค์คลาวด์ได้ เพราะได้ทั้ง native access และการแชร์/ซิงค์ collection ระหว่างเครื่อง Apidog ทำงานในรูปแบบนี้ จึงเหมาะกับทีมที่ต้องการทั้งการดีบักในเครื่องและ collaboration

ดูแลชุดทดสอบให้ไม่เสื่อม

ชุดทดสอบ API เสื่อมได้เหมือน code:

• endpoint เปลี่ยน
• field ถูก rename
• business rule เปลี่ยน
• test ยังผ่าน แต่ตรวจสิ่งที่ไม่สำคัญแล้ว

ตั้งรอบ review ทุก 2-4 สัปดาห์:

[ ] ลบ request ที่ endpoint ไม่มีแล้ว
[ ] อัปเดต assertion ที่ตรวจ field เก่า
[ ] ตรวจว่า environment ยังถูกต้อง
[ ] เช็ก test ที่ flaky
[ ] export collection ล่าสุดเข้า Git

ตั้งชื่อ request ให้บอกพฤติกรรม ไม่ใช่ลำดับ:

ไม่ดี:

test 1
test 2
test 3

ดี:

create order with valid payload
create order with invalid currency
get order by existing order id
reject unauthenticated request

จัดกลุ่มตาม user flow เช่น:

Auth
  - login with valid credentials
  - reject invalid password

Orders
  - create order
  - get order
  - cancel order

หลักการตั้งชื่อเดียวกับที่ทำให้ กรณีทดสอบ อ่านง่าย ก็ใช้กับ API collection ได้เช่นกัน

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

เครื่องมือทดสอบ API ฟรีดีพอสำหรับงานจริงหรือไม่

ดีพอสำหรับทีมส่วนใหญ่ในช่วงเริ่มต้นและงานประจำวัน แพลนฟรีมักครอบคลุม request, assertions, environments และ automation พื้นฐาน เหตุผลหลักที่ต้องอัปเกรดมักเป็น team seats, run history หรือ CI quota ไม่ใช่เพราะทดสอบไม่ได้

ฉันทดสอบ SOAP APIs ด้วยเครื่องมือออนไลน์ฟรีได้หรือไม่

ได้ Apidog รองรับ SOAP ในแพลนฟรี และ SoapUI โอเพนซอร์สก็เหมาะกับ SOAP โดยเฉพาะ SOAP ต้องใช้ XML envelope และมักเกี่ยวข้องกับ WSDL ดังนั้นควรใช้เครื่องมือที่รองรับ SOAP โดยตรง ดูรายละเอียด protocol ได้จาก ข้อกำหนด SOAP อย่างเป็นทางการ

เครื่องมือเบราว์เซอร์กับเดสก์ท็อปต่างกันอย่างไร

เครื่องมือเบราว์เซอร์ไม่ต้องติดตั้งและใช้งานข้ามเครื่องได้ง่าย แต่ browser security อาจจำกัดการเรียก local/private network ส่วนเดสก์ท็อปเข้าถึง local service และ payload ใหญ่ได้ดีกว่า และมักทำงาน offline ได้

เครื่องมือฟรีรองรับ automated test suite หรือไม่

ส่วนใหญ่รองรับ คุณสามารถ chain request, เพิ่ม assertion และรันเป็นชุดได้ Postman ใช้ร่วมกับ Newman ได้ ส่วน Hoppscotch และ Apidog มี runner ของตัวเอง ข้อจำกัดหลักมักเป็นจำนวน automated run ต่อเดือน

ทีมขนาดเล็กควรเริ่มด้วยเครื่องมือใด

ถ้าต้องการแค่ยิง request เร็ว ๆ Hoppscotch หรือ Thunder Client เริ่มได้ง่าย ถ้าต้องการออกแบบ ทดสอบ mock และเอกสารใน workflow เดียว Apidog เป็นตัวเลือกที่เหมาะกว่า สำหรับทีมขนาดเล็ก ให้รัน flow เดียวกันในแต่ละเครื่องมือ เช่น login → create resource → get resource พร้อม assertion แล้วเลือกเครื่องมือที่ใช้งานได้ลื่นที่สุดกับ stack ของคุณ