คุณมี GraphQL endpoint และต้องการทราบว่ามันทำงานได้จริง ไม่ใช่แค่ "เซิร์ฟเวอร์เปิดอยู่" แต่เป็นของจริง: การคิวรี user ส่งคืนฟิลด์ที่แอปของคุณอ่านหรือไม่, การมิวเทชัน createOrder บันทึกคำสั่งซื้อจริงหรือไม่, และรูปแบบยังคงอยู่เมื่อคุณเปลี่ยนตัวแปรหรือไม่ เครื่องมือ REST ที่รู้จักแต่การเรียกแบบ path-and-verb ทำให้สิ่งนี้ยุ่งยาก GraphQL ส่งทุกอย่างไปยัง URL เดียวกันในรูปแบบ POST body ดังนั้นคุณต้องมีไคลเอนต์ที่เข้าใจภาษาคิวรีนั้นเอง, ให้คำแนะนำฟิลด์, และให้คุณยืนยัน (assert) JSON ที่ได้รับกลับมา
Apidog รองรับ GraphQL เป็นประเภทคำขอระดับเฟิร์สคลาส นอกเหนือจาก HTTP, gRPC, WebSocket, SSE และ SOAP คู่มือนี้จะแนะนำการสร้างคำขอ GraphQL ตั้งแต่เริ่มต้น: การเขียนคิวรี, การดึงสคีมาสำหรับการเติมโค้ดอัตโนมัติ, การส่งผ่านตัวแปร, การเรียกใช้มิวเทชัน, และการยืนยันการตอบกลับ ตัวอย่างที่ใช้คือ API อีคอมเมิร์ซที่คุณคิวรีผู้ใช้และคำสั่งซื้อของพวกเขา จากนั้นสร้างคำสั่งซื้อใหม่ หากคุณต้องการพื้นฐานแนวคิดว่าทำไม GraphQL ถึงส่งคิวรีแบบระบุชนิดเดียวแทนที่จะเป็นหลาย endpoint เอกสาร GraphQL อย่างเป็นทางการ เป็นแหล่งอ้างอิงหลัก และการเปรียบเทียบของเราเกี่ยวกับ REST เทียบกับ GraphQL ครอบคลุมว่าแต่ละแบบเหมาะสมเมื่อใด
ปุ่ม
สิ่งที่คุณกำลังทดสอบและเหตุผลที่ GraphQL แตกต่าง
REST ให้ endpoint หลายแห่ง โดยแต่ละแห่งส่งคืนรูปแบบที่คงที่ GraphQL ให้ endpoint เดียวและให้ผู้เรียกสามารถร้องขอฟิลด์ที่ต้องการได้อย่างแม่นยำ ความยืดหยุ่นนี้คือหัวใจสำคัญ และยังเป็นสิ่งที่ทำให้การทดสอบรู้สึกแตกต่างออกไป
มีสองสิ่งที่เปลี่ยนแปลง ประการแรก คำขอคือเอกสารคิวรีในส่วนเนื้อหา ไม่ใช่ URL ที่คุณเปลี่ยนแปลง GET /users/42 กลายเป็นส่วนเลือก user(id: 42) { ... } ที่ส่งด้วย POST ประการที่สอง GraphQL แทบจะไม่ส่งคืนสถานะที่ไม่ใช่ 200 สำหรับข้อผิดพลาดทางธุรกิจ คิวรีที่ล้มเหลวยังคงส่งคืน 200 OK พร้อมกับอาร์เรย์ errors ใน JSON ดังนั้นการตรวจสอบรหัสสถานะจึงไม่เพียงพอ คุณต้องอ่านเนื้อหา ข้อเท็จจริงเพียงอย่างเดียวนั้นจะกำหนดวิธีการยืนยันของคุณในภายหลังในคู่มือนี้
Apidog มีประเภทบอดี้ GraphQL โดยเฉพาะ, การเติมโค้ดอัตโนมัติที่รู้สคีมา, ตัวแปรสำหรับคิวรีที่ใช้ซ้ำได้, และเครื่องมือยืนยันและสถานการณ์การทดสอบแบบเดียวกับที่คุณจะใช้สำหรับ REST คุณออกแบบและรันคำขอในแอป จากนั้นบันทึกเป็นสถานการณ์ที่คุณสามารถรันซ้ำได้ มาสร้างกัน
สร้างคำขอ GraphQL ใน Apidog
อันดับแรก, ดาวน์โหลด Apidog หรือเปิดในเบราว์เซอร์ของคุณ จากนั้นเปิดโปรเจกต์ของคุณ หากคุณเริ่มต้นใหม่ ให้สร้างโปรเจกต์เพื่อให้คำขอมีที่อยู่
ขั้นตอนที่ 1: สร้างคำขอใหม่และเปลี่ยนบอดี้เป็น GraphQL
คลิกปุ่ม + และเลือก New Request ซึ่งจะเปิดตัวสร้างคำขอมาตรฐาน แบบเดียวกับที่คุณใช้สำหรับการเรียก REST: method, URL, parameters และ Authorization
ตั้งค่า method เป็น POST และวาง GraphQL endpoint ของคุณลงในแถบ URL ตัวอย่างทั่วไปมีลักษณะดังนี้:
https://api.yourstore.com/graphql
ตอนนี้บอก Apidog ว่านี่คือคำขอ GraphQL ในพื้นที่บอดี้คำขอ คลิกที่ Body จากนั้นเลือก GraphQL ตัวแก้ไขบอดี้จะเปลี่ยนเป็นมุมมองที่รองรับ GraphQL พร้อมกล่อง Query ซึ่งเป็นที่อยู่ของภาษาคิวรี
หาก endpoint ของคุณต้องการโทเค็น ให้เปิดส่วน Authorization และเพิ่มที่นั่น เช่น Bearer token การยืนยันตัวตนในคำขอ GraphQL ทำงานเหมือนกับคำขอ HTTP อื่นๆ ใน Apidog เนื่องจากภายใต้การทำงานภายในยังคงเป็น HTTP POST
ขั้นตอนที่ 2: เขียนคิวรีแรกของคุณ
บนแท็บ Run พิมพ์คิวรีของคุณลงในกล่อง Query เริ่มต้นด้วยสิ่งที่จับต้องได้ ที่นี่คุณต้องการผู้ใช้และคำสั่งซื้อที่เกี่ยวข้องกับพวกเขา:
query GetUserWithOrders {
user(id: "usr_1024") {
id
name
email
orders {
id
total
status
createdAt
}
}
}
สิ่งนี้ร้องขอผู้ใช้หนึ่งคนและรายการคำสั่งซื้อของพวกเขาที่ซ้อนกัน ชื่อฟิลด์ต้องตรงกับสคีมาของเซิร์ฟเวอร์ของคุณอย่างแม่นยำ หากสคีมาของคุณเรียกมันว่า emailAddress แทนที่จะเป็น email คิวรีนี้จะล้มเหลว นั่นเป็นหน้าที่ของขั้นตอนถัดไปเพื่อป้องกัน
ขั้นตอนที่ 3: ดึงสคีมาสำหรับการเติมโค้ดอัตโนมัติ
การเดาชื่อฟิลด์ทำให้การทดสอบ GraphQL ช้าลง Apidog สามารถอ่านสคีมาของคุณได้ ดังนั้นตัวแก้ไขจะแนะนำฟิลด์และประเภทที่ถูกต้องในขณะที่คุณพิมพ์ แทนที่จะให้คุณตรวจสอบเอกสารในแท็บอื่น
นี่เป็นการดำเนินการด้วยตนเองตามความต้องการ คลิกปุ่ม Fetch Schema ในกล่องป้อนข้อมูล Apidog จะรัน introspection query กับ endpoint ของคุณและดึงระบบประเภท เมื่อสำเร็จ การเติมโค้ดอัตโนมัติจะเปิดใช้งาน: เริ่มพิมพ์ฟิลด์ภายในส่วนเลือกและคุณจะได้รับคำแนะนำสไตล์ IntelliSense สำหรับสิ่งที่ใช้งานได้จริงในประเภทนั้น
สองสิ่งที่ควรทราบ การเติมโค้ดอัตโนมัติไม่ได้ทำงานโดยอัตโนมัติ มันจะเปิดใช้งานหลังจากที่คุณคลิก Fetch Schema เท่านั้น และหาก endpoint ของคุณปิดการใช้งาน introspection (เซิร์ฟเวอร์ production บางแห่งทำเพื่อความปลอดภัย) การดึงข้อมูลจะไม่ส่งคืนสคีมา ดังนั้นคุณจะต้องเขียนฟิลด์ด้วยตนเองตามเอกสารของคุณเอง หากการดึงข้อมูลทำงาน ให้ดึงใหม่หลังจากมีการเปลี่ยนแปลงสคีมา เพื่อให้คำแนะนำเป็นปัจจุบันอยู่เสมอ
ขั้นตอนที่ 4: รันและอ่านการตอบกลับ
คลิก Send การตอบกลับจะปรากฏในส่วนล่างของอินเทอร์เฟซ ผลลัพธ์ที่ถูกต้องจะมีลักษณะดังนี้:
{
"data": {
"user": {
"id": "usr_1024",
"name": "Dana Whitfield",
"email": "dana@example.com",
"orders": [
{ "id": "ord_5001", "total": 89.90, "status": "SHIPPED", "createdAt": "2026-07-01T09:14:00Z" },
{ "id": "ord_5002", "total": 12.50, "status": "PENDING", "createdAt": "2026-07-12T16:03:00Z" }
]
}
}
}
สังเกตคีย์ data ระดับบนสุด การตอบกลับ GraphQL ทุกรายการจะซ้อนผลลัพธ์ของคุณไว้ภายใต้ data และปัญหาใดๆ จะปรากฏในอาร์เรย์ errors ที่อยู่ระดับเดียวกัน โปรดจำโครงสร้างนั้นไว้ เพราะการยืนยันของคุณจะชี้ไปที่ data.user... ไม่ใช่ที่ root
ส่งตัวแปรเพื่อให้คำขอสามารถนำกลับมาใช้ใหม่ได้
การฮาร์ดโค้ด "usr_1024" ลงในคิวรีใช้งานได้ครั้งเดียว สำหรับคำขอที่คุณจะรันซ้ำกับผู้ใช้และสภาพแวดล้อมต่างๆ ให้ย้ายค่านั้นไปเก็บในตัวแปร GraphQL มีไวยากรณ์ตัวแปรระดับเฟิร์สคลาสสำหรับสิ่งนี้ และ Apidog ก็รองรับ ไวยากรณ์นี้เป็น GraphQL มาตรฐาน ไม่ใช่สิ่งที่ Apidog สร้างขึ้น ดังนั้น เอกสาร GraphQL อย่างเป็นทางการเกี่ยวกับตัวแปร จึงเป็นแหล่งอ้างอิงหลัก
ประกาศตัวแปรใน signature ของคิวรีด้วยพรีฟิกซ์ $ และประเภท จากนั้นใช้ในอาร์กิวเมนต์:
query GetUserWithOrders($userId: ID!) {
user(id: $userId) {
id
name
orders {
id
total
status
}
}
}
จากนั้นระบุค่าเป็นอ็อบเจกต์ JSON ขนาดเล็กของตัวแปร:
{
"userId": "usr_1024"
}
ตอนนี้คิวรีเดียวกันนี้สามารถรันได้สำหรับผู้ใช้ทุกคนโดยการเปลี่ยนค่า JSON เพียงค่าเดียว ผนวกสิ่งนี้เข้ากับตัวแปรสภาพแวดล้อมของ Apidog และคุณสามารถชี้คำขอเดียวกันไปยัง staging และ production โดยไม่ต้องแก้ไขคิวรี นี่คือสิ่งที่เปลี่ยนการเรียกแบบครั้งเดียวให้กลายเป็นสิ่งที่สามารถบันทึก แชร์ และรันในชุดทดสอบได้
เขียน mutation เพื่อสร้างคำสั่งซื้อ
Mutation คือการเปลี่ยนแปลงข้อมูล ใน GraphQL ไม่มีโปรโตคอลหรือ UI แยกต่างหากสำหรับสิ่งนี้ mutation ถูกเขียนเป็น GraphQL ในกล่อง Query เดียวกัน โดยใช้คีย์เวิร์ด mutation แทน query ดังนั้นเวิร์กโฟลว์ที่คุณรู้จักอยู่แล้วจึงสามารถนำมาใช้ได้ทันที
ที่นี่คุณสร้างคำสั่งซื้อสำหรับผู้ใช้ที่คุณคิวรีก่อนหน้านี้:
mutation CreateOrder($input: CreateOrderInput!) {
createOrder(input: $input) {
id
total
status
createdAt
}
}
ตัวแปรจะส่งข้อมูล payload:
{
"input": {
"userId": "usr_1024",
"items": [
{ "sku": "TSHIRT-BLK-M", "quantity": 2 },
{ "sku": "MUG-CERAMIC", "quantity": 1 }
],
"currency": "USD"
}
}
คลิก Send การตอบกลับที่ดีจะสะท้อนคำสั่งซื้อที่สร้างขึ้น:
{
"data": {
"createOrder": {
"id": "ord_5003",
"total": 42.30,
"status": "PENDING",
"createdAt": "2026-07-15T10:22:11Z"
}
}
}
เนื่องจาก mutation เขียนข้อมูลจริง ให้รันกับสภาพแวดล้อมการทดสอบหรือ staging ไม่ใช่ production รูปแบบทั่วไปคือการรัน mutation, จับ id ที่ส่งคืน, จากนั้นรันคิวรี GetUserWithOrders ของคุณอีกครั้งและยืนยันว่าคำสั่งซื้อใหม่ปรากฏในรายการ ลูป query-mutation-query นั้นเป็นการตรวจสอบแบบ end-to-end ที่สมจริง และเป็นสิ่งที่คุณต้องการบันทึกเป็น scenario ในส่วนถัดไป
ยืนยันการตอบกลับแทนที่จะตรวจสอบด้วยตาเปล่า
การอ่าน JSON ด้วยตนเองเป็นเรื่องดีในขณะที่คุณสำรวจ สำหรับการทดสอบที่รันโดยไม่ต้องมีคนดูแล คุณต้องมีการยืนยันที่ผ่านหรือล้มเหลวได้ด้วยตัวเอง Apidog ให้คุณเพิ่มการยืนยันลงในคำขอเพื่อให้การรันถูกตัดสินโดยอัตโนมัติ ซึ่งเป็นสิ่งที่คุณตั้งค่าไว้ใน การยืนยัน API
- ยืนยันว่าสถานะ HTTP คือ
200จำเป็นแต่ไม่เพียงพอ เนื่องจาก GraphQL ส่งคืน 200 แม้จะมีข้อผิดพลาดทางธุรกิจ - ยืนยันว่าไม่มีฟิลด์
errorsนี่คือเกตที่แท้จริงของการผ่านหรือล้มเหลวของ GraphQL หากมีerrorsการดำเนินการนั้นล้มเหลวไม่ว่าสถานะจะบอกอะไรก็ตาม - ยืนยันค่าเฉพาะภายใน
dataโดยใช้ JSONPath เช่น$.data.createOrder.statusเท่ากับPENDINGหรือ$.data.user.ordersมีความยาวมากกว่าศูนย์
การผสมผสานนั้นจะจับโหมดความล้มเหลวที่การตรวจสอบสถานะอย่างเดียวพลาดไป: คิวรีที่ส่งคืน 200 พร้อมอาร์เรย์ errors หรือคิวรีที่สำเร็จแต่ส่งคืนรูปแบบที่ไม่ถูกต้อง ชี้การยืนยันค่าของคุณไปยังเส้นทางที่ซ้อนกันภายใต้ data โดยให้ตรงกับโครงสร้างการตอบกลับที่คุณเห็นก่อนหน้านี้
บันทึกเป็นสถานการณ์ทดสอบ
คำขอที่ได้รับการยืนยันเพียงครั้งเดียวเป็นการทดสอบ smoke test ที่ดี ผลตอบแทนที่แท้จริงคือการเชื่อมโยงคำขอเข้าด้วยกันเป็นสถานการณ์: คิวรีผู้ใช้, สร้างคำสั่งซื้อ, จากนั้นคิวรีอีกครั้งเพื่อยืนยันว่าข้อมูลยังคงอยู่ สถานการณ์การทดสอบของ Apidog ให้คุณจัดลำดับขั้นตอนเหล่านี้, ส่งผ่านข้อมูลระหว่างกัน (จับ id จาก mutation, ป้อนเข้าสู่คิวรียืนยัน), และรันขั้นตอนทั้งหมดด้วยการคลิกเพียงครั้งเดียว คู่มือฉบับเต็มอยู่ใน วิธีการเขียนสถานการณ์ทดสอบด้วย Apidog
ในระดับสูง: สร้างสถานการณ์ทดสอบใหม่, เพิ่มคิวรี GraphQL และ mutation ของคุณเป็นขั้นตอนตามลำดับ, ดึง id คำสั่งซื้อจากการตอบกลับ mutation ไปยังตัวแปร, และอ้างอิงตัวแปรนั้นในขั้นตอนคิวรีสุดท้าย แนบการยืนยันจากส่วนก่อนหน้านี้ไปยังแต่ละขั้นตอน ตอนนี้คุณมี regression test ที่ทำซ้ำได้สำหรับ GraphQL API ของคุณ ซึ่งมนุษย์, ตารางเวลา หรือ pipeline สามารถรันได้
สำหรับทีมที่กำลังพิจารณา GraphQL เทียบกับรูปแบบอื่น ๆ ก่อนตัดสินใจเลือก การวิเคราะห์ของเราเกี่ยวกับ REST เทียบกับ GraphQL เทียบกับ gRPC และการรวบรวม เครื่องมือทดสอบและจำลอง GraphQL ทั้งสองอย่างจะช่วยให้คุณเข้าใจเวิร์กโฟลว์นี้ได้ดีขึ้น และหาก stack ของคุณยังรองรับ SOAP รูปแบบการร้องขอและยืนยันแบบเดียวกันนี้ก็สามารถใช้ได้ใน วิธีการทดสอบ SOAP APIs ใน Apidog
ทำให้เวิร์กโฟลว์เป็นอัตโนมัติด้วย Apidog CLI
เมื่อสถานการณ์ GraphQL ของคุณอยู่ในโปรเจกต์แล้ว คุณสามารถรันสถานการณ์ทดสอบที่บันทึกไว้ของโปรเจกต์ได้จาก terminal หรือ CI runner ด้วย Apidog CLI ติดตั้งและเข้าสู่ระบบ:
npm install -g apidog-cli
apidog login --with-token <your-token>
จากนั้นรันสถานการณ์ที่บันทึกไว้ด้วย id โดยชี้ไปที่สภาพแวดล้อม:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
ที่นี่ -t คือ ID ของสถานการณ์ทดสอบ, -e คือ ID ของสภาพแวดล้อม, และ -r คือ reporter (cli, html, หรือ junit; คั่นด้วยจุลภาค เช่น -r html,cli สำหรับมากกว่าหนึ่งรายการ) CLI จะรันสถานการณ์และชุดทดสอบที่บันทึกไว้จากโปรเจกต์คลาวด์ของคุณ และรายงานผลว่าผ่านหรือไม่ ซึ่งเป็นสิ่งที่เชื่อมต่อ Apidog เข้ากับการ build ข้อควรระวังอย่างหนึ่ง: เอกสาร CLI ยืนยันการรันสถานการณ์ HTTP และไม่ได้ระบุว่าสถานการณ์ที่มีขั้นตอน GraphQL จะรันแบบ headlessly หรือไม่ ให้ถือว่า CLI เป็นกลไกของคุณสำหรับการรัน HTTP regression และสำหรับการซิงค์สเปคผ่านคำสั่ง import (OpenAPI, HAR, Postman และอื่นๆ) และดำเนินการคิวรี, mutation และการยืนยัน GraphQL ของคุณในแอป ดู คู่มือการติดตั้ง Apidog CLI สำหรับการตั้งค่าโทเค็น และ Apidog CLI ใน GitHub Actions pipeline สำหรับการเชื่อมต่อเข้ากับ CI
คำถามที่พบบ่อย
ฉันจำเป็นต้องมีแผนแบบชำระเงินเพื่อทดสอบ GraphQL ใน Apidog หรือไม่? เอกสารคำขอ GraphQL ไม่ได้จำกัดคุณสมบัตินี้ไว้เบื้องหลังระดับแผน และไม่ได้แยกระหว่างคลาวด์กับโฮสต์เอง คุณสามารถเริ่มต้นด้วยแผนฟรี: ทดลองใช้ฟรี ไม่ต้องใช้บัตรเครดิต และดู Apidog สำหรับรายละเอียดแผนปัจจุบัน
ทำไมคำขอ GraphQL ของฉันส่งคืน 200 แต่ยังคงล้มเหลว? นั่นเป็นพฤติกรรมปกติของ GraphQL การส่งผ่านข้อมูลสำเร็จ ดังนั้นสถานะ HTTP คือ 200 แต่การดำเนินการเกิดข้อผิดพลาดทางธุรกิจหรือการตรวจสอบความถูกต้อง ซึ่งจะอยู่ในอาร์เรย์ errors ของ JSON body ควรยืนยันเสมอว่าไม่มี errors นอกเหนือจากการตรวจสอบสถานะ ดังที่กล่าวไว้ใน การยืนยัน API
ฉันจะรับคำแนะนำฟิลด์ขณะเขียนคิวรีได้อย่างไร? คลิกปุ่ม Fetch Schema ในกล่องป้อนข้อมูล Apidog จะ introspect endpoint ของคุณและเปิดใช้งานการเติมโค้ดอัตโนมัติ เพื่อให้ตัวแก้ไขแนะนำฟิลด์และประเภทที่ถูกต้อง นี่เป็นขั้นตอนด้วยตนเอง ไม่ใช่อัตโนมัติ ดังนั้นให้คลิกเมื่อตั้งค่า URL ของ endpoint ของคุณแล้ว และดึงใหม่หลังจากมีการเปลี่ยนแปลงสคีมา
Mutation ไปอยู่ที่ไหน? ฉันไม่เห็นแท็บ mutation แยกต่างหาก ไม่มี แท็บแยกต่างหาก Mutation ถูกเขียนเป็น GraphQL ในกล่อง Query เดียวกัน โดยใช้คีย์เวิร์ด mutation แทน query ส่ง payload ผ่านตัวแปร จากนั้นคลิก Send เหมือนกับการคิวรี
ฉันจะส่งค่าที่แตกต่างกันโดยไม่ต้องเขียนคิวรีใหม่ได้อย่างไร? ใช้ตัวแปร GraphQL ประกาศตัวแปรเหล่านั้นใน operation signature ด้วยพรีฟิกซ์ $ และระบุอ็อบเจกต์ JSON ของค่า ไวยากรณ์เป็นไปตาม ข้อกำหนด GraphQL มาตรฐาน และการรองรับตัวแปรของ Apidog ก็เข้ากันได้กับตัวแปรสภาพแวดล้อม ทำให้คำขอเดียวสามารถทำงานได้ทั้งใน staging และ production
สรุป
การทดสอบ GraphQL ขึ้นอยู่กับนิสัยที่ซื่อสัตย์ไม่กี่อย่าง: เขียนคิวรีในกล่อง Query, ดึงสคีมาเพื่อให้ตัวแก้ไขช่วยคุณ, ย้ายค่าที่คงที่ไปยังตัวแปร, และยืนยันที่ส่วนบอดี้แทนที่จะเชื่อรหัสสถานะ รัน mutation แบบเดียวกับที่คุณรันคิวรี จากนั้นเชื่อมโยงทั้งสองเข้าด้วยกันเป็นสถานการณ์ที่บันทึกไว้เพื่อให้การตรวจสอบซ้ำตัวเอง ดาวน์โหลด Apidog เพื่อทำตาม สร้างโฟลว์ผู้ใช้และคำสั่งซื้อด้านบน แล้วคุณจะมี GraphQL regression test ที่สามารถรันซ้ำได้ทุกเมื่อที่สคีมาของคุณเปลี่ยนแปลง