Thanawat Wongchai

Posted on May 22 • Originally published at apidog.com

วิธีใช้ Talend API Tester สำหรับการทดสอบ API

Talend API Tester คือส่วนขยายของ Chrome สำหรับส่งคำขอ HTTP และตรวจสอบการตอบกลับจากเบราว์เซอร์โดยตรง เดิมชื่อ Restlet Client และยังเหมาะกับงานตรวจสอบ REST API แบบรวดเร็ว เช่น ส่ง GET, POST, ตั้งค่า headers, ตรวจ body และจัดคำขอเป็น scenario เพื่อรันตามลำดับ

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

บทความนี้สรุปวิธีใช้งาน Talend API Tester แบบลงมือทำ: ติดตั้งส่วนขยาย ส่ง request แรก จัดกลุ่มคำขอเป็น project/service สร้าง scenario หลายขั้นตอน และเพิ่ม assertion เพื่อให้เครื่องมือตรวจผลลัพธ์แทนการไล่อ่าน response เอง ตัวอย่างใช้ API สาธารณะเพื่อให้ทดลองตามได้ทันที

ติดตั้งส่วนขยายและส่งคำขอแรก

ติดตั้ง Talend API Tester จาก Chrome Web Store โดยค้นหา “Talend API Tester” แล้วคลิก Add to Chrome ส่วนขยายนี้ใช้งานได้กับเบราว์เซอร์ที่ใช้ Chromium เช่น Edge และ Brave ด้วย

หลังติดตั้งแล้ว:

เปิด Talend API Tester จากเมนูส่วนขยาย
ปักหมุดไว้บน toolbar ถ้าต้องใช้บ่อย
เปิดหน้าจอ request
เลือก HTTP method
ใส่ URL
กด Send

ลองส่ง request แรกด้วย JSONPlaceholder:

GET https://jsonplaceholder.typicode.com/users/1

เมื่อกด Send คุณจะเห็นข้อมูลหลักของ response เช่น:

status code
response time
headers
body
JSON/XML ที่ถูกจัดรูปแบบให้อ่านง่าย

สำหรับ POST ให้เปลี่ยน method เป็น POST แล้วเปิดแท็บ Body เลือก application/json และใส่ payload:

{
  "name": "Priya Nair",
  "email": "priya.nair@example.com"
}

ถ้า API ต้องใช้ authentication ให้เพิ่ม header เช่น:

Authorization: Bearer YOUR_TOKEN

หรือใช้ตัวช่วย authentication ที่มีในเครื่องมือ เช่น Basic, Digest, OAuth และ Bearer แทนการตั้ง header เอง

จัดระเบียบคำขอเป็นโปรเจกต์และบริการ

ถ้ามี request แค่ไม่กี่รายการ การเก็บแบบกระจัดกระจายอาจยังพอใช้ได้ แต่เมื่อเริ่มมีหลาย endpoint ควรจัดโครงสร้างให้ชัดเจน

Talend API Tester ใช้โครงสร้างหลักคือ:

Project: กลุ่มงานหลัก เช่น User API
Service: กลุ่ม endpoint ภายใน project เช่น Users, Orders

แนวทางจัดระเบียบที่ใช้งานได้จริง:

สร้าง project เช่น User API
สร้าง service เช่น Users
บันทึก request แต่ละรายการไว้ใน service ที่เกี่ยวข้อง
ตั้งค่า base URL ใน service ถ้าต้องเรียกหลาย endpoint ภายใต้ host เดียวกัน
ใช้ path เฉพาะในแต่ละ request เพื่อลดการพิมพ์ URL ซ้ำ

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

User API
└── Users
    ├── GET /users/1
    ├── POST /users
    ├── PUT /users/1
    └── DELETE /users/1

โครงสร้างนี้ช่วยให้ค้นหา request ง่ายขึ้น และยังเป็นพื้นฐานสำหรับการสร้าง scenario เพราะ scenario จะอ้างอิงจาก request ที่บันทึกไว้แล้ว

Talend API Tester ยังรองรับ environment variables เช่นกำหนดตัวแปร host สำหรับสภาพแวดล้อมทดสอบ:

host = https://api-staging.example.com

จากนั้นใช้ใน request:

GET {{host}}/users/1

เมื่อมี environment สำหรับ production ก็สามารถสลับค่า host ได้โดยไม่ต้องแก้ URL ทีละ request และลดความเสี่ยงจากการยิง request ไปผิด server

ถ้ามี API spec หรือ collection เดิมอยู่แล้ว คุณสามารถนำเข้าได้ แทนการสร้าง request ใหม่ทั้งหมด Talend API Tester รองรับ:

Postman collections
Swagger
OpenAPI definitions
HAR files

ถ้าต้องการวางโครงสร้าง test case ให้เป็นระบบมากขึ้น อ่านเพิ่มเติมได้ที่ ตัวอย่างกรณีทดสอบ API

สร้างสถานการณ์เพื่อรันคำขอตามลำดับ

request เดี่ยวเหมาะกับการตรวจ endpoint หนึ่งรายการ แต่การทดสอบ API จริงมักเป็น flow เช่น:

สร้างข้อมูล
อ่านข้อมูลกลับมา
อัปเดตข้อมูล
ลบข้อมูล

Talend API Tester รองรับ flow แบบนี้ผ่าน Scenario

Scenario คือชุดของ request ที่รันตามลำดับจากบนลงล่าง วิธีใช้งานโดยทั่วไป:

สร้าง request แต่ละขั้นตอนและบันทึกไว้ก่อน
สร้าง scenario ใหม่
เพิ่ม request เข้า scenario ตามลำดับที่ต้องการ
รัน scenario
ตรวจผลลัพธ์ของแต่ละ step

ตัวอย่าง flow:

Create User -> Get User -> Update User -> Delete User

จุดที่สำคัญคือ scenario สามารถส่งค่าระหว่าง step ได้ เช่น request Create User ส่งคืน id ใน response:

{
  "id": 123,
  "name": "Priya Nair"
}

คุณสามารถดึงค่า id ออกมาเป็น variable แล้วนำไปใช้ใน request ถัดไป:

GET https://api.example.com/users/{{userId}}

วิธีนี้ทำให้ทดสอบ stateful flow ได้ ไม่ใช่แค่ยิง request แยกกันทีละตัว

Scenario ยังรองรับเงื่อนไขและการทำซ้ำ เช่น:

ให้ step ถัดไปทำงานเฉพาะเมื่อ status code ก่อนหน้าเป็น 201
วนเรียก endpoint หลายครั้ง
ใช้ค่าที่ extract จาก response ก่อนหน้าใน request ถัดไป

ตัวอย่าง scenario ที่เหมาะกับ regression test:

Authenticate
-> Create record
-> Verify record can be read
-> Update record
-> Verify updated field
-> Delete record

การรัน scenario ทั้ง flow ให้ผ่านมีความหมายมากกว่าการรัน request แยก เพราะมันตรวจพฤติกรรมของระบบในลำดับที่ใกล้เคียงการใช้งานจริง

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

เพิ่มการยืนยันเพื่อให้เครื่องมือตรวจสอบการตอบกลับ

การดู response ด้วยตาเหมาะกับการ debug แต่ไม่เหมาะกับการทดสอบซ้ำบ่อย ๆ เพราะพลาดง่ายและใช้เวลา

ให้ใช้ Assertion เพื่อกำหนดเงื่อนไขว่า response แบบใดถือว่าถูกต้อง

ใน Talend API Tester คุณสามารถเปิด request ที่บันทึกไว้ แล้วเพิ่ม assertion ผ่านฟอร์ม โดยไม่ต้องเขียนสคริปต์เอง ตัวอย่าง assertion ที่ใช้บ่อย:

Status code ต้องเท่ากับ 200 หรือ 201
Response time ต้องต่ำกว่า 500 ms
Response body field ต้องมีค่าตามที่คาดหวัง
Header ต้องมีอยู่ หรือมีค่าตรงตามที่กำหนด

ตัวอย่างแนวคิดของ assertion:

status == 200
responseTime < 500
body.id exists
body.email == "priya.nair@example.com"
header.Content-Type contains "application/json"

เมื่อ request ทำงาน ไม่ว่าจะรันเดี่ยวหรืออยู่ใน scenario เครื่องมือจะประเมิน assertion และแสดงผลว่า pass/fail

แนวทางที่ใช้งานได้จริงสำหรับ API test ทั่วไป:

ตรวจ status code ก่อน
ตรวจ field สำคัญใน body
ตรวจ response time เฉพาะ endpoint ที่มี SLA
ตรวจ header เมื่อเกี่ยวกับ caching, content type, auth หรือ CORS
ใส่ assertion ในทุก step สำคัญของ scenario

ข้อดีของ Talend API Tester คือ assertion เป็นแบบฟอร์ม จึงเหมาะกับผู้ทดสอบที่ไม่ต้องการเขียน JavaScript แต่ข้อจำกัดคือไม่ยืดหยุ่นเท่าเครื่องมือที่รองรับสคริปต์เต็มรูปแบบ หากต้องตรวจเงื่อนไขซับซ้อน เช่นค่าที่คำนวณจากหลาย field อาจไม่เพียงพอ

สำหรับงานตรวจประจำวัน ส่วนใหญ่การตรวจ status code และ field สำคัญใน response ก็เพียงพอแล้ว อ่านแนวทางเพิ่มเติมได้ที่ การยืนยัน API

อ่านการตอบกลับอย่างถูกต้อง

ไม่ว่าจะใช้ assertion หรือไม่ คุณควรอ่าน response ให้ครบ 4 ส่วนหลัก

1. Status code

status code เป็นสัญญาณแรกของผลลัพธ์:

2xx: สำเร็จ
4xx: request มีปัญหา
5xx: server มีปัญหา

ตัวอย่าง:

200 OK
201 Created
400 Bad Request
401 Unauthorized
404 Not Found
500 Internal Server Error

ถ้าต้องการอ้างอิงการใช้ status code ให้เหมาะกับ REST API ดูได้ที่ รหัสสถานะ HTTP ที่ REST API ควรใช้

2. Response time

response ที่ถูกต้องแต่ช้าเกินไปยังเป็นปัญหาได้ Talend API Tester จะแสดงเวลาที่ request ใช้ในการตอบกลับ คุณสามารถใช้ข้อมูลนี้เพื่อตรวจ endpoint ที่ช้าผิดปกติ หรือเพิ่ม assertion เช่น response ต้องต่ำกว่า 500 ms

3. Headers

headers อธิบายพฤติกรรมหลายอย่างที่ body ไม่ได้บอก เช่น:

Content-Type: application/json
Cache-Control: no-cache
Access-Control-Allow-Origin: *
X-RateLimit-Remaining: 99

ตรวจ headers เมื่อต้อง debug เรื่อง content type, cache, rate limit หรือ CORS

4. Body

body คือข้อมูลจริงที่ API ส่งกลับมา โดยมักเป็น JSON หรือ XML ให้ตรวจว่า:

field ที่ต้องมีมีอยู่จริง
type ของข้อมูลถูกต้อง
value ตรงตาม expected result
error message มีรายละเอียดพอสำหรับ client

การอ่านทั้ง 4 ส่วนร่วมกันช่วยให้ประเมิน API ได้ถูกต้องกว่าแค่ดูว่า “มี response กลับมา”

เมื่อส่วนขยาย Chrome ไม่เพียงพอ

Talend API Tester เหมาะกับการตรวจ API แบบเร็วในเบราว์เซอร์ แต่จะเริ่มมีข้อจำกัดเมื่อ workflow ใหญ่ขึ้น เช่น:

ผูกกับ Chrome
ไม่เหมาะกับการรันแบบ headless ใน CI pipeline
assertion ใช้ง่ายแต่ไม่ยืดหยุ่นเท่า test platform เต็มรูปแบบ
ไม่ครอบคลุมงานออกแบบ API, mocking และ documentation ในที่เดียว

Apidog เป็นแพลตฟอร์ม API แบบ all-in-one ที่ช่วยเติมช่องว่างเหล่านี้ โดยเป็นแอปพลิเคชันแบบ standalone ไม่ใช่ browser extension และรองรับการนำเข้า Postman, OpenAPI และรูปแบบอื่น ๆ เช่นเดียวกับ Talend API Tester

สิ่งที่ Apidog รวมไว้ใน workspace เดียว ได้แก่:

visual assertion builder
mock server
automated test scenarios
API documentation
การทำงานร่วมกับ spec และ test จาก source เดียวกัน

คุณสามารถ ดาวน์โหลด Apidog แล้วนำเข้าคำขอเดิมเพื่อทดลองเปรียบเทียบ workflow ได้ หากต้องการดูตัวเลือกอื่นเพิ่มเติม อ่านได้ที่ เครื่องมือทดสอบ API ออนไลน์ฟรี

Talend API Tester ยังเป็นตัวเลือกที่ดีสำหรับการตรวจแบบเร็วในเบราว์เซอร์ แต่ถ้าต้องการ automation, CI/CD, mocking และ documentation ในกระบวนการเดียว อาจต้องใช้เครื่องมือที่ครอบคลุมกว่า

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

Talend API Tester เหมือนกับ Restlet Client หรือไม่?

ใช่ Talend API Tester คือเครื่องมือที่เปลี่ยนชื่อมาจาก Restlet Client แนวทางใช้งานยังเหมือนเดิม คือเป็นส่วนขยาย Chrome สำหรับส่ง HTTP request จัดระเบียบ request สร้าง scenario และเพิ่ม assertion

Talend API Tester ฟรีหรือไม่?

มีเวอร์ชันฟรีใน Chrome Web Store ซึ่งครอบคลุมงานหลัก เช่น ส่ง request จัดกลุ่มเป็น project สร้าง scenario และเพิ่ม assertion สำหรับงานทดสอบส่วนบุคคลส่วนใหญ่ เวอร์ชันฟรีเพียงพอแล้ว

Talend API Tester รันการทดสอบใน CI/CD ได้หรือไม่?

ไม่โดยตรง เพราะเป็น Chrome extension และทำงานภายในเบราว์เซอร์ จึงไม่เหมาะกับการรันแบบ headless ใน pipeline หากต้องการให้ test รันอัตโนมัติทุกครั้งที่มี commit ควรใช้เครื่องมือที่มี command-line runner หรือรองรับ CI/CD โดยตรง

อ่านแนวทางเพิ่มเติมได้ที่ การทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD

Talend API Tester สามารถนำเข้ารูปแบบใดได้บ้าง?

Talend API Tester รองรับการนำเข้า:

Postman collections
Swagger
OpenAPI definitions
HAR files

จึงเหมาะถ้าคุณมี API specification หรือ export จากเครื่องมืออื่นอยู่แล้ว และไม่ต้องการสร้าง request ใหม่ด้วยตนเองทั้งหมด

Scenario ต่างจาก request เดี่ยวอย่างไร?

request เดี่ยวคือการส่ง HTTP call หนึ่งครั้งและดู response หนึ่งรายการ ส่วน scenario คือชุด request ที่รันตามลำดับ และสามารถส่งค่าจาก response ของ step หนึ่งไปใช้ใน step ถัดไปได้