คู่มือการทดสอบ API: จากพื้นฐานสู่ Workflow อัตโนมัติ

API คือสัญญาระหว่างระบบซอฟต์แวร์ เมื่อ API เกิดปัญหา ทุกสิ่งที่พึ่งพามันก็พังตาม แต่การทดสอบ API มักถูกมองข้าม — ทำแบบลวกๆ ในแท็บเบราว์เซอร์ก่อนปล่อยระบบ กลยุทธ์การทดสอบ API ที่ดีช่วยจับข้อผิดพลาดตั้งแต่เนิ่นๆ บันทึกพฤติกรรมที่คาดหวัง และสร้างความมั่นใจในการส่งมอบงาน

การทดสอบ API คืออะไร?

การทดสอบ API คือการส่ง HTTP request และตรวจสอบบางอย่างเกี่ยวกับ response:

• Status code — ได้รับ 200 OK หรือ 404 Not Found?
• Response body — โครงสร้างข้อมูลถูกต้องไหม? ค่าต่างๆ ถูกต้องหรือเปล่า?
• Headers — Content-Type ถูกตั้งค่าไว้อย่างถูกต้องไหม? มี auth header อยู่ไหม?
• Response time — endpoint ตอบสนองภายในระยะเวลาที่ยอมรับได้ไหม?
• Error handling — เกิดอะไรขึ้นเมื่อรับ input ที่ผิดพลาด? ได้รับข้อความ error ที่มีความหมายไหม?

HTTP status code ที่ต้องรู้

Code	ความหมาย	เมื่อไหร่ที่จะเจอ
200	OK	GET, PUT, PATCH ที่สำเร็จ
201	Created	POST ที่สร้าง resource สำเร็จ
204	No Content	DELETE หรือ action ที่สำเร็จแต่ไม่มี body
400	Bad Request	input ไม่ถูกต้อง, JSON ผิดรูปแบบ, ขาด field
401	Unauthorized	ขาด authentication token หรือ token ไม่ถูกต้อง
403	Forbidden	ยืนยันตัวตนแล้วแต่ไม่มีสิทธิ์
404	Not Found	ไม่พบ resource
409	Conflict	resource ซ้ำ, version ขัดแย้ง
422	Unprocessable Entity	validation error บน JSON ที่ถูกรูปแบบ
429	Too Many Requests	เกินขีดจำกัด rate limit
500	Internal Server Error	มีบั๊กฝั่ง server
503	Service Unavailable	server ล่มหรือรับโหลดไม่ไหว

401 หมายถึง "คุณเป็นใคร?" — 403 หมายถึง "รู้ว่าคุณเป็นใคร แต่คุณทำสิ่งนี้ไม่ได้"

การทดสอบด้วยตนเองด้วย API Request Builder

ก่อนจะทำระบบอัตโนมัติ ให้ทำความเข้าใจ endpoint ของคุณด้วยตนเองก่อน API Request Builder ของเราช่วยให้คุณ:

• กำหนด HTTP method (GET, POST, PUT, PATCH, DELETE)
• เพิ่ม header (Authorization, Content-Type, header กำหนดเอง)
• สร้าง query parameter โดยไม่ต้องเข้ารหัส URL เอง
• เขียน JSON request body พร้อม syntax highlighting
• ดู response แบบเต็มรวมถึง header และ timing

เหมาะสำหรับการสำรวจ API ใหม่, แก้บั๊ก endpoint เฉพาะจุด หรือตรวจสอบการแก้ไขอย่างรวดเร็ว

การทดสอบ REST API: วงจร CRUD แบบครบถ้วน

สำหรับ API /users สมมติ ชุดทดสอบที่ครบถ้วนครอบคลุม:

สร้าง (POST)

POST /users
Content-Type: application/json

{
  "name": "Alice Chen",
  "email": "alice@example.com",
  "role": "editor"
}

ตรวจสอบ:

• Status 201 Created
• Response body มีข้อมูล user ที่สร้างพร้อม id ที่ถูกสร้างขึ้น
• Location header ชี้ไปยัง resource ใหม่ (เช่น /users/42)

อ่าน (GET)

GET /users/42
Authorization: Bearer <token>

ตรวจสอบ:

• Status 200 OK
• Body ตรงกับ user ที่สร้าง
• id เป็น 42

แก้ไข (PUT / PATCH)

PATCH /users/42
Content-Type: application/json

{ "role": "admin" }

ตรวจสอบ:

• Status 200 OK
• role เปลี่ยนเป็น "admin" ใน response
• field อื่นๆ ไม่เปลี่ยนแปลง

ลบ (DELETE)

DELETE /users/42
Authorization: Bearer <token>

ตรวจสอบ:

• Status 204 No Content
• GET /users/42 ที่ตามมาคืนค่า 404

Negative testing: การทดสอบที่คนมักข้ามไป

Positive test ตรวจสอบกรณีที่ทุกอย่างราบรื่น Negative test ตรวจสอบว่า API รับมือกับ input ที่ผิดพลาดได้ดีแค่ไหน:

• ขาด field ที่จำเป็น → 400 พร้อมข้อความ error ที่ชัดเจน
• ชนิดข้อมูลไม่ถูกต้อง ("age": "twenty") → 400
• ไม่พบ resource (GET /users/99999) → 404
• Token หมดอายุ → 401
• เข้าถึงข้อมูลของ user อื่น → 403
• ส่ง payload ขนาด 10 MB → 413 Payload Too Large
• เกิน rate limit → 429 พร้อม Retry-After header

API ที่ออกแบบดีจะล้มเหลวอย่างคาดเดาได้และบอกข้อมูลที่เป็นประโยชน์

รูปแบบการทดสอบ Authentication

Bearer token (JWT)

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

สถานการณ์ที่ต้องทดสอบ:

• Token ที่ถูกต้อง → response ที่ถูกต้อง
• Token หมดอายุ → 401 พร้อมข้อความ "Token expired"
• Token ที่ถูกแก้ไข (เปลี่ยนตัวอักษรหนึ่งตัว) → 401
• ไม่มี header → 401
• Token ของ environment อื่น → 401

ใช้ JWT Decoder ของเราเพื่อตรวจสอบ token และเช็คเวลาหมดอายุระหว่างการทดสอบด้วยตนเอง

API key

X-API-Key: sk_live_abc123

ทดสอบ: key ผิด, ไม่มี key, key ที่มีสิทธิ์ไม่เพียงพอ

OAuth 2.0 flow

OAuth เพิ่มความซับซ้อน — ทดสอบ endpoint สำหรับ token exchange แยกต่างหากจาก resource endpoint

การตรวจสอบ response body

อย่าแค่เช็ค status code ตรวจสอบโครงสร้างของ response ด้วย:

// Using Jest + supertest
test("GET /users/:id returns the correct user", async () => {
  const response = await request(app).get("/users/42").set("Authorization", `Bearer ${token}`);

  expect(response.status).toBe(200);
  expect(response.headers["content-type"]).toMatch(/json/);
  expect(response.body).toMatchObject({
    id: 42,
    name: expect.any(String),
    email: expect.stringMatching(/^[^\s@]+@[^\s@]+\.[^\s@]+$/),
    role: expect.oneOf(["admin", "editor", "viewer"]),
  });
});

สำหรับ response schema ขนาดใหญ่ ใช้การตรวจสอบ JSON Schema ด้วย JSON Schema Validator ของเรา เพื่อกำหนดรูปแบบที่คาดหวังครั้งเดียวและทดสอบทุก endpoint กับมัน

Contract testing

ในระบบ microservice contract testing ช่วยให้มั่นใจว่า consumer และ provider ตกลงกันเรื่องรูปแบบ API consumer กำหนดสิ่งที่ต้องการ; provider ตรวจสอบว่าตอบสนองได้ครบ เครื่องมืออย่าง Pact ช่วยทำให้กระบวนการนี้เป็นอัตโนมัติ

มีประโยชน์มากเมื่อแต่ละทีมดูแล service ที่ต่างกัน — contract test จะล้มเหลวทันทีเมื่อ field ถูกเปลี่ยนชื่อหรือลบออก ก่อนที่จะถึงขั้น integration

การทดสอบประสิทธิภาพและ Load

Functional test บอกว่า API ทำงานได้ ไหม ส่วน Performance test บอกว่ามันทำงาน ได้ดีแค่ไหน ภายใต้โหลด:

• Baseline — p50/p95/p99 response time เมื่อมีผู้ใช้คนเดียวคือเท่าไหร่?
• Load test — ทำงานอย่างไรที่ traffic สูงสุดที่คาดการณ์ไว้?
• Stress test — จุดไหนที่มันเริ่มล้มเหลว?
• Spike test — เกิดอะไรขึ้นเมื่อ traffic พุ่งสูงขึ้น 10 เท่าอย่างกะทันหัน?

เป้าหมายทั่วไป: < 200ms สำหรับ p95 ที่ peak load ที่คาดการณ์ไว้

checklist การทดสอบ API

• ทดสอบ CRUD operation ทั้งหมดสำหรับแต่ละ resource
• ทดสอบกรณีลบ: input ไม่ถูกต้อง, ขาด auth, ไม่พบข้อมูล
• ตรวจสอบ response body กับ schema (ไม่ใช่แค่ status code)
• ทดสอบกรณีขอบ authentication: token หมดอายุ, ขาด token, token ที่ถูกแก้ไข
• ตรวจสอบว่า error response มีข้อความที่เป็นประโยชน์
• ตรวจสอบว่า pagination, filtering และ sorting ทำงานถูกต้อง
• ทดสอบพฤติกรรม rate limiting
• ตรวจสอบว่าไม่มีข้อมูลสำคัญรั่วไหลใน error response
• ตรวจสอบ response time ที่ load ที่คาดการณ์ไว้

การทดสอบ API ที่ดีคือตาข่ายนิรภัยสำหรับการ refactor และเป็นเอกสารประกอบที่ดีที่สุดที่คุณจะมีได้ — เพราะมันแสดงให้เห็นชัดเจนว่าแต่ละ endpoint ทำอะไรและคาดหวัง input แบบใด