วิธีการทดสอบ GraphQL API ใน Apidog: Queries, Mutations และ Automation

คุณมี GraphQL endpoint และต้องการยืนยันว่ามันทำงานได้จริง ไม่ใช่แค่ “เซิร์ฟเวอร์เปิดอยู่” แต่ต้องตอบได้ว่า query user คืนฟิลด์ที่แอปอ่านหรือไม่, mutation createOrder บันทึกคำสั่งซื้อจริงหรือไม่ และรูปแบบการตอบกลับยังถูกต้องเมื่อเปลี่ยนตัวแปรหรือไม่ เนื่องจาก GraphQL ส่งคำขอไปยัง URL เดียวผ่าน POST body เครื่องมือที่เข้าใจเพียง path และ HTTP verb จึงไม่เพียงพอ คุณต้องมีไคลเอนต์ที่เขียน GraphQL ได้, ช่วยแนะนำฟิลด์จาก schema และตรวจสอบ JSON response ได้

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

Apidog รองรับ GraphQL เป็นประเภทคำขอโดยเฉพาะ นอกเหนือจาก HTTP, gRPC, WebSocket, SSE และ SOAP บทความนี้จะแสดงขั้นตอนสร้างและทดสอบ GraphQL request ตั้งแต่เขียน query, ดึง schema เพื่อเปิดใช้ autocomplete, ส่ง variables, เรียก mutation และเพิ่ม assertions ตัวอย่างจะใช้ API อีคอมเมิร์ซที่ query ผู้ใช้และคำสั่งซื้อ ก่อนสร้างคำสั่งซื้อใหม่

หากต้องการทบทวนแนวคิด GraphQL โปรดดู เอกสาร GraphQL อย่างเป็นทางการ และอ่านการเปรียบเทียบ REST เทียบกับ GraphQL เพื่อเลือกแนวทางที่เหมาะกับ API ของคุณ

สิ่งที่คุณกำลังทดสอบ และเหตุผลที่ GraphQL แตกต่าง

REST มีหลาย endpoint และแต่ละ endpoint มักคืน response shape ที่กำหนดไว้ล่วงหน้า ส่วน GraphQL ใช้ endpoint เดียว และให้ client เลือกเฉพาะฟิลด์ที่ต้องการได้

ตัวอย่าง REST:

GET /users/42

ตัวอย่าง GraphQL ที่เทียบเท่า:

query {
  user(id: "42") {
    id
    name
  }
}

ความต่างสำคัญสำหรับการทดสอบมี 2 ข้อ:

1. Query อยู่ใน request body ไม่ใช่ URL
2. GraphQL อาจส่งคืน 200 OK แม้ operation จะล้มเหลว โดยรายละเอียดข้อผิดพลาดอยู่ใน errors

ตัวอย่าง response ที่ HTTP สำเร็จ แต่ GraphQL operation มีข้อผิดพลาด:

{
  "data": null,
  "errors": [
    {
      "message": "User not found"
    }
  ]
}

ดังนั้น การตรวจเฉพาะ HTTP 200 OK ไม่เพียงพอ คุณต้องตรวจทั้ง status code, ฟิลด์ errors และข้อมูลใต้ data

Apidog มี GraphQL body type, schema-aware autocomplete, variables, assertions และ test scenarios สำหรับรัน flow ซ้ำได้

สร้างคำขอ GraphQL ใน Apidog

เริ่มจาก ดาวน์โหลด Apidog หรือเปิดใช้งานผ่านเบราว์เซอร์ จากนั้นเปิดหรือสร้างโปรเจกต์ใหม่

ขั้นตอนที่ 1: สร้าง request และเลือก GraphQL body

1. คลิก +
2. เลือก New Request
3. ตั้ง method เป็น POST
4. ใส่ GraphQL endpoint ของคุณ เช่น

https://api.yourstore.com/graphql

1. เปิดแท็บ Body
2. เลือก GraphQL

Apidog จะแสดง editor ที่มีช่อง Query สำหรับเขียน GraphQL operation

หาก endpoint ต้องใช้ token ให้กำหนดในแท็บ Authorization เช่น Bearer token เพราะ GraphQL request ยังทำงานผ่าน HTTP POST ตามปกติ

ขั้นตอนที่ 2: เขียน query แรก

ในแท็บ Run ให้ใส่ query ต่อไปนี้ในช่อง Query:

query GetUserWithOrders {
  user(id: "usr_1024") {
    id
    name
    email
    orders {
      id
      total
      status
      createdAt
    }
  }
}

Query นี้ขอข้อมูลผู้ใช้หนึ่งคน พร้อมรายการคำสั่งซื้อที่เกี่ยวข้อง

ชื่อฟิลด์ต้องตรงกับ schema ของ server เสมอ ตัวอย่างเช่น หาก schema ใช้ emailAddress แทน email query จะล้มเหลว จึงควรดึง schema ก่อนเขียน query ขนาดใหญ่

ขั้นตอนที่ 3: ดึง schema เพื่อใช้ autocomplete

การเดาชื่อฟิลด์ทำให้การทดสอบ GraphQL ช้าและผิดพลาดง่าย ให้คลิกปุ่ม Fetch Schema ใน GraphQL editor

Apidog จะส่ง introspection query ไปยัง endpoint และดึง type system กลับมา เมื่อสำเร็จ คุณจะได้รับ autocomplete สำหรับ:

• ฟิลด์ที่ใช้ได้ในแต่ละ type
• Argument ของ field
• ประเภทข้อมูลของ variables
• Nested selection ที่ schema รองรับ

ข้อควรระวัง:

• Autocomplete จะทำงานหลังจากกด Fetch Schema เท่านั้น
• หาก production endpoint ปิด introspection คุณจะไม่สามารถดึง schema ได้
• หลัง schema เปลี่ยน ควรกด Fetch Schema ใหม่เพื่ออัปเดตคำแนะนำ

ขั้นตอนที่ 4: ส่ง request และอ่าน response

คลิก Send ผลลัพธ์ที่สำเร็จอาจมีลักษณะดังนี้:

{
  "data": {
    "user": {
      "id": "usr_1024",
      "name": "Dana Whitfield",
      "email": "[e-mail]",
      "orders": [
        {
          "id": "ord_5001",
          "total": 89.9,
          "status": "SHIPPED",
          "createdAt": "2026-07-01T09:14:00Z"
        },
        {
          "id": "ord_5002",
          "total": 12.5,
          "status": "PENDING",
          "createdAt": "2026-07-12T16:03:00Z"
        }
      ]
    }
  }
}

จุดสำคัญคือผลลัพธ์อยู่ใต้ key data ดังนั้น JSONPath สำหรับ assertion ต้องอ้างอิง path เช่น:

$.data.user.orders

ไม่ใช่:

$.user.orders

ส่ง variables เพื่อให้ request ใช้ซ้ำได้

การ hard-code ค่า "usr_1024" ใช้ได้สำหรับทดลองครั้งเดียว แต่ไม่เหมาะกับ test suite หรือหลาย environment

ใช้ GraphQL variables แทน โดยประกาศตัวแปรใน operation signature:

query GetUserWithOrders($userId: ID!) {
  user(id: $userId) {
    id
    name
    orders {
      id
      total
      status
    }
  }
}

จากนั้นใส่ค่าในส่วน Variables:

{
  "userId": "usr_1024"
}

แนวทางนี้ช่วยให้คุณเปลี่ยนผู้ใช้ที่ทดสอบได้โดยไม่ต้องแก้ query และสามารถใช้ร่วมกับ environment variables ของ Apidog เพื่อสลับระหว่าง staging และ production ได้

ดูรายละเอียด syntax เพิ่มเติมได้จาก เอกสาร GraphQL variables

เขียน mutation เพื่อสร้างคำสั่งซื้อ

Mutation ใช้สำหรับเปลี่ยนแปลงข้อมูล เช่น สร้าง, แก้ไข หรือ ลบข้อมูล

ใน Apidog คุณไม่ต้องเปิดแท็บพิเศษสำหรับ mutation เพียงเขียน operation ด้วย keyword mutation ในช่อง Query เดิม:

mutation CreateOrder($input: CreateOrderInput!) {
  createOrder(input: $input) {
    id
    total
    status
    createdAt
  }
}

ส่ง payload ผ่าน variables:

{
  "input": {
    "userId": "usr_1024",
    "items": [
      {
        "sku": "TSHIRT-BLK-M",
        "quantity": 2
      },
      {
        "sku": "MUG-CERAMIC",
        "quantity": 1
      }
    ],
    "currency": "USD"
  }
}

เมื่อคลิก Send response ที่สำเร็จอาจเป็นดังนี้:

{
  "data": {
    "createOrder": {
      "id": "ord_5003",
      "total": 42.3,
      "status": "PENDING",
      "createdAt": "2026-07-15T10:22:11Z"
    }
  }
}

เนื่องจาก mutation เขียนข้อมูลจริง ควรรันบน test หรือ staging environment แทน production

Flow ทดสอบที่ใช้งานได้จริงคือ:

1. Query ผู้ใช้และรายการคำสั่งซื้อ
2. รัน createOrder mutation
3. เก็บ id ของคำสั่งซื้อที่สร้าง
4. Query ผู้ใช้อีกครั้ง
5. ยืนยันว่าคำสั่งซื้อใหม่ปรากฏในรายการ

ยืนยัน response แทนการตรวจด้วยตา

การอ่าน JSON ด้วยตาเหมาะสำหรับการสำรวจ API แต่ regression test ควรตัดสินผลผ่านหรือล้มเหลวได้อัตโนมัติ

เพิ่ม assertions ใน Apidog ตามแนวทางจาก การยืนยัน API

สำหรับ GraphQL ควรมี assertions อย่างน้อย 3 ส่วน:

• ยืนยันว่า HTTP status คือ 200
• ยืนยันว่าไม่มีฟิลด์ errors
• ยืนยันค่าที่ต้องการใต้ data

ตัวอย่าง assertions ที่ควรตั้งค่า:

เงื่อนไข	ตัวอย่าง
HTTP status สำเร็จ	200
ไม่มี GraphQL errors	ไม่มี errors ใน response
สถานะคำสั่งซื้อถูกต้อง	$.data.createOrder.status เท่ากับ PENDING
ผู้ใช้มีคำสั่งซื้อ	$.data.user.orders มีจำนวนมากกว่า 0

อย่าพึ่งพา status code เพียงอย่างเดียว เพราะ GraphQL อาจคืน 200 พร้อม error payload ได้

บันทึกเป็นสถานการณ์ทดสอบ

Request เดี่ยวเหมาะกับ smoke test แต่ GraphQL flow มักต้องเชื่อมหลาย request เข้าด้วยกัน

ตัวอย่าง scenario:

1. Query ผู้ใช้
2. สร้างคำสั่งซื้อด้วย mutation
3. ดึง id จาก mutation response
4. Query ยืนยันข้อมูลอีกครั้ง
5. ตรวจว่าคำสั่งซื้อใหม่ยังอยู่

Apidog test scenarios ช่วยให้คุณเรียงลำดับ request, ส่งค่าระหว่างขั้นตอน และรัน flow ทั้งหมดได้ในครั้งเดียว

อ่านวิธีตั้งค่าเพิ่มเติมได้ที่ วิธีการเขียนสถานการณ์ทดสอบด้วย Apidog

สำหรับทีมที่กำลังเปรียบเทียบแนวทาง API สามารถดูเพิ่มเติมได้ที่:

• REST เทียบกับ GraphQL เทียบกับ gRPC
• เครื่องมือทดสอบและจำลอง GraphQL
• วิธีการทดสอบ SOAP APIs ใน Apidog

ทำให้เวิร์กโฟลว์เป็นอัตโนมัติด้วย Apidog CLI

เมื่อบันทึก test scenario ไว้ในโปรเจกต์แล้ว คุณสามารถรัน scenario ที่บันทึกไว้ผ่าน terminal หรือ CI runner ด้วย Apidog CLI

ติดตั้ง CLI และเข้าสู่ระบบ:

npm install -g apidog-cli
apidog login --with-token <your-token>

รัน scenario ด้วย scenario ID และ environment ID:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

พารามิเตอร์หลัก:

• -t: ID ของ test scenario
• -e: ID ของ environment
• -r: reporter เช่น cli, html หรือ junit

หากต้องการหลาย reporter:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r html,cli

CLI จะรัน scenario และ test suite ที่บันทึกไว้ พร้อมรายงานผลการทดสอบ

ข้อควรระวังคือ เอกสาร CLI ยืนยันการรัน HTTP scenarios แต่ไม่ได้ระบุชัดเจนว่า scenario ที่มี GraphQL step จะรันแบบ headless ได้หรือไม่ ดังนั้นควรใช้ CLI สำหรับ HTTP regression และการซิงค์สเปกผ่านคำสั่ง import เช่น OpenAPI, HAR และ Postman ขณะที่ query, mutation และ GraphQL assertions ควรดำเนินการในแอป

ดูรายละเอียดได้ที่:

• คู่มือการติดตั้ง Apidog CLI
• Apidog CLI ใน GitHub Actions pipeline

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

ฉันจำเป็นต้องมีแผนแบบชำระเงินเพื่อทดสอบ GraphQL ใน Apidog หรือไม่?

เอกสารคำขอ GraphQL ไม่ได้ระบุว่าคุณสมบัตินี้ถูกจำกัดตามแผน คุณสามารถเริ่มจากแผนฟรีได้ โดยดูรายละเอียดแผนปัจจุบันที่ Apidog

ทำไม GraphQL request ส่งคืน 200 แต่ยังล้มเหลว?

นี่เป็นพฤติกรรมปกติของ GraphQL HTTP transport สำเร็จจึงได้ status 200 แต่ query หรือ mutation อาจมี validation หรือ business error อยู่ใน errors

ให้ตรวจทั้ง status code และตรวจว่า response ไม่มี errors ตามแนวทางใน การยืนยัน API

ฉันจะรับคำแนะนำฟิลด์ขณะเขียน query ได้อย่างไร?

คลิก Fetch Schema ใน GraphQL editor Apidog จะ introspect endpoint และเปิดใช้ autocomplete สำหรับฟิลด์และ type ที่ schema รองรับ

หลัง schema เปลี่ยน ควรกด fetch ใหม่เพื่ออัปเดตข้อมูล

Mutation อยู่ที่ไหน? ฉันไม่เห็นแท็บแยก

ไม่มีแท็บ mutation แยกต่างหาก ให้เขียน mutation ในช่อง Query เดียวกัน โดยใช้ keyword mutation แทน query จากนั้นส่ง payload ผ่าน variables และกด Send

ฉันจะส่งค่าหลายค่าโดยไม่แก้ query ได้อย่างไร?

ใช้ GraphQL variables ประกาศตัวแปรด้วย $ ใน operation signature และส่งค่าเป็น JSON object

ตัวอย่าง:

query GetUser($userId: ID!) {
  user(id: $userId) {
    id
    name
  }
}

{
  "userId": "usr_1024"
}

Syntax นี้เป็นมาตรฐานตาม ข้อกำหนด GraphQL variables และสามารถใช้ร่วมกับ environment variables ของ Apidog ได้

สรุป

การทดสอบ GraphQL ที่เชื่อถือได้ควรทำตามขั้นตอนนี้:

1. สร้าง POST request และเลือก GraphQL body
2. เขียน query หรือ mutation ในช่อง Query
3. กด Fetch Schema เพื่อใช้ autocomplete
4. ใช้ variables แทนการ hard-code ค่า
5. ตรวจ errors เสมอ ไม่ใช่แค่ HTTP status
6. เพิ่ม assertions ที่อ้างอิง path ใต้ data
7. เชื่อม query และ mutation เป็น test scenario ที่รันซ้ำได้

เริ่มสร้าง flow ผู้ใช้และคำสั่งซื้อของคุณใน Apidog แล้วเปลี่ยน GraphQL request แบบครั้งเดียวให้เป็น regression test ที่ตรวจสอบได้ทุกครั้งเมื่อ schema หรือ backend เปลี่ยนแปลง