วิธีทดสอบ API ด้วย Postman: คู่มือฉบับลงมือทำ

Postman เป็นหนึ่งในเครื่องมือที่ใช้กันอย่างแพร่หลายที่สุดสำหรับการส่งคำขอ HTTP และตรวจสอบว่า API ทำงานอย่างไร มันเริ่มต้นจากการเป็นส่วนขยายของเบราว์เซอร์และพัฒนามาเป็นแอปพลิเคชันเดสก์ท็อปเต็มรูปแบบที่จัดการได้ทุกอย่างตั้งแต่คำขอ GET อย่างรวดเร็วไปจนถึงชุดการทดสอบแบบสคริปต์ที่ทำงานใน CI หากคุณสร้างหรือใช้งาน API คุณจะต้องเจอ Postman อย่างแน่นอน

คู่มือนี้จะอธิบายการทดสอบ API ใน Postman ในแบบที่คุณจะทำในแต่ละวัน คุณจะได้ส่งคำขอ ตรวจสอบการตอบกลับ เขียนคำยืนยัน (assertions) ในแท็บ Tests ตั้งค่าสภาพแวดล้อม (environments) เพื่อให้คุณสามารถสลับระหว่าง staging และ production และเรียกใช้คอลเลกชันทั้งหมดพร้อมกันด้วย Collection Runner ตัวอย่างจะใช้ API สาธารณะเพื่อให้คุณสามารถทำตามได้โดยไม่ต้องตั้งค่าใดๆ ก่อน

ตั้งค่า Postman และส่งคำขอแรกของคุณ

ดาวน์โหลด Postman จาก เว็บไซต์ทางการ และติดตั้งแอปเดสก์ท็อป คุณสามารถใช้งานได้โดยไม่ต้องมีบัญชีสำหรับการทำงานในเครื่อง แม้ว่าการลงชื่อเข้าใช้จะซิงค์คอลเลกชันของคุณในทุกอุปกรณ์ เปิดแอปและคลิกปุ่ม New จากนั้นเลือก HTTP Request

คำขอต้องมีอย่างน้อยสามสิ่ง: เมธอด (method), URL และบางครั้งก็มีบอดี้ (body) เลือก GET จากเมนูแบบเลื่อนลงของเมธอดและป้อนปลายทางจริง บริการ JSONPlaceholder มีประโยชน์สำหรับการฝึกฝน:

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

คลิก Send แผงตอบกลับจะแสดงบอดี้, รหัสสถานะ (200 OK), เวลาตอบกลับ และขนาด สลับมุมมองบอดี้ระหว่าง Pretty, Raw และ Preview เพื่อดู JSON ที่จัดรูปแบบแล้วหรือตามที่เซิร์ฟเวอร์ส่งมา

สำหรับ POST ให้เปลี่ยนเมธอด เปิดแท็บ Body เลือก raw และเลือก JSON จากเมนูแบบเลื่อนลงของรูปแบบ วางเพย์โหลดแบบนี้:

{
  "name": "Maria Chen",
  "email": "maria.chen@example.com"
}

ส่วนหัว (Headers) เช่น Content-Type: application/json จะถูกเพิ่มให้คุณเมื่อคุณเลือกประเภทบอดี้แบบ JSON แท็บ Headers ช่วยให้คุณสามารถเพิ่มสิ่งอื่นใดที่ API ต้องการ เช่น ส่วนหัว Authorization หากคุณยังใหม่กับรหัสการตอบกลับที่ควรคาดหวัง คู่มือเกี่ยวกับ รหัสสถานะ HTTP ที่ REST API ควรใช้ เป็นข้อมูลอ้างอิงที่มีประโยชน์

จัดระเบียบคำขอเป็นคอลเลกชัน

คำขอเดียวก็เพียงพอสำหรับการตรวจสอบอย่างรวดเร็ว การทดสอบจริงหมายถึงคำขอหลายรายการที่เกี่ยวข้องกัน: สร้างผู้ใช้, ดึงข้อมูลผู้ใช้รายนั้น, อัปเดต, ลบ Postman จัดกลุ่มสิ่งเหล่านี้ไว้ใน คอลเลกชัน

คลิก Collections ในแถบด้านข้าง จากนั้นคลิกไอคอน + เพื่อสร้างคอลเลกชัน ตั้งชื่อที่ชัดเจน เช่น “User API smoke tests” บันทึกแต่ละคำขอลงในคอลเลกชันด้วย Ctrl/Cmd + S และตั้งชื่อให้ชัดเจน คุณสามารถซ้อนโฟลเดอร์ภายในคอลเลกชันเพื่อแยกคำขอ เช่น คำขอการรับรองความถูกต้อง (authentication) ออกจากคำขอทรัพยากร (resource)

คอลเลกชันยังเป็นหน่วยที่คุณสามารถแบ่งปันได้ ส่งออกเป็นไฟล์ JSON หรือแชร์ลิงก์หากคุณซิงค์กับคลาวด์ เพื่อนร่วมทีมจะนำเข้าและมีคำขอเหมือนกับคุณทุกประการ นี่คือรากฐานสำหรับสิ่งอื่น ๆ ทั้งหมด เนื่องจาก Collection Runner และการทดสอบอัตโนมัติทำงานบนคอลเลกชัน ไม่ใช่คำขอที่แยกจากกัน

คอลเลกชันยังสามารถมีพฤติกรรมที่ใช้ร่วมกันได้ Postman ให้คุณแนบสคริปต์ในระดับคอลเลกชันหรือโฟลเดอร์ ไม่ใช่แค่ในคำขอเดียว สคริปต์ก่อนคำขอ (pre-request script) บนคอลเลกชันจะทำงานก่อนคำขอทุกรายการภายใน ซึ่งมีประโยชน์สำหรับการรีเฟรชโทเค็นหรือการประทับเวลา สคริปต์ทดสอบในระดับคอลเลกชันจะทำงานหลังจากคำขอทุกรายการ ซึ่งมีประโยชน์สำหรับการยืนยันที่คุณต้องการใช้ทุกที่ เช่น "เวลาตอบสนองสมเหตุสมผล" การกำหนดสิ่งเหล่านี้เพียงครั้งเดียวจะทำให้คำขอแต่ละรายการของคุณมุ่งเน้นไปที่สิ่งที่เฉพาะเจาะจงของตนเอง

เขียนการทดสอบในแท็บ Tests

การส่งคำขอจะบอกคุณว่ามีอะไรตอบกลับมา การทดสอบ (test) จะบอกคุณว่าสิ่งที่ตอบกลับมานั้นถูกต้องหรือไม่ โดยอัตโนมัติในทุกครั้ง Postman จะรัน JavaScript ในส่วน Scripts ของคำขอ (เวอร์ชันเก่าเรียกว่าแท็บ Tests) หลังจากได้รับคำตอบแล้ว

Postman เปิดเผยออบเจกต์ pm สำหรับการเขียนคำยืนยัน รูปแบบหลักคือ pm.test(name, callback) โดยที่ callback จะเกิดข้อผิดพลาดหากความคาดหวังล้มเหลว นี่คือคำยืนยันที่คุณจะใช้เป็นประจำ:

// ตรวจสอบรหัสสถานะ
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

// ตรวจสอบเวลาตอบกลับ
pm.test("Response is under 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

// ตรวจสอบฟิลด์ใน JSON body
pm.test("User has the expected email", function () {
    const body = pm.response.json();
    pm.expect(body.email).to.eql("maria.chen@example.com");
});

// ตรวจสอบส่วนหัว
pm.test("Content-Type is JSON", function () {
    pm.expect(pm.response.headers.get("Content-Type"))
      .to.include("application/json");
});

ไวยากรณ์การยืนยันมาจาก Chai ดังนั้น pm.expect จึงรองรับ .to.eql, .to.include, .to.be.above และอื่นๆ คลิก Send และผลลัพธ์จะแสดงในแท็บ Test Results โดยแต่ละการทดสอบจะเป็นสีเขียวหรือสีแดง

นิสัยบางอย่างช่วยให้การทดสอบมีประโยชน์ ตั้งชื่อบล็อก pm.test แต่ละรายการตามพฤติกรรมที่ตรวจสอบ ไม่ใช่ตามปลายทาง เพื่อให้ข้อความแสดงข้อผิดพลาดอ่านได้เหมือนประโยค ตรวจสอบสิ่งที่อาจทำให้ผู้ใช้ API ประสบปัญหาจริง: รหัสสถานะ, รูปแบบของบอดี้ และฟิลด์ที่ไคลเอ็นต์ขึ้นอยู่กับ หลีกเลี่ยงการยืนยันค่าที่คุณไม่สามารถควบคุมได้ เช่น การประทับเวลาที่เซิร์ฟเวอร์สร้างขึ้น เนื่องจากสิ่งเหล่านั้นจะทำให้เกิดความล้มเหลวที่ไม่สม่ำเสมอ ซึ่งจะทำให้คนละเลยข้อผิดพลาด Postman ยังมีแผง Snippets ถัดจากตัวแก้ไข พร้อมคำยืนยันสำเร็จรูปที่คุณสามารถคลิกเพื่อแทรก ซึ่งเป็นวิธีที่เร็วที่สุดในการเรียนรู้ API ของ pm หากคุณต้องการเจาะลึกการออกแบบคำยืนยัน โปรดดูรายละเอียดของ คำยืนยัน API และวิธีเขียนให้ดี สำหรับแนวคิดที่กว้างขึ้นเกี่ยวกับการจัดโครงสร้างการตรวจสอบเป็นกรณีที่มีชื่อ คู่มือ ตัวอย่างกรณีทดสอบ API ก็คุ้มค่าที่จะอ่านควบคู่กันไป

การใช้สภาพแวดล้อมและตัวแปร

การฮาร์ดโค้ด https://api.staging.example.com ลงในทุกคำขอเป็นเรื่องที่ลำบากเมื่อคุณต้องการชี้ไปยัง production สภาพแวดล้อม (Environments) ช่วยแก้ปัญหานี้ได้ สภาพแวดล้อมคือชุดของตัวแปรที่มีชื่อ

คลิกไอคอนสภาพแวดล้อมในแถบด้านข้างและสร้างสภาพแวดล้อมที่ชื่อว่า “Staging” เพิ่มตัวแปร base_url ที่มีค่า https://jsonplaceholder.typicode.com สร้างสภาพแวดล้อมที่สองที่ชื่อว่า “Production” ที่มี base_url ที่แตกต่างกัน ตอนนี้อ้างอิงตัวแปรในคำขอของคุณโดยใช้วงเล็บปีกกาคู่:

GET {{base_url}}/users/1

เลือกสภาพแวดล้อมที่ใช้งานจากเมนูแบบเลื่อนลงที่มุมขวาบน และทุกคำขอที่ใช้ {{base_url}} จะสลับไปพร้อมกัน

ตัวแปรยังสามารถส่งข้อมูลระหว่างคำขอได้ด้วย คำขอเข้าสู่ระบบสามารถดึงโทเค็นจากการตอบกลับและเก็บไว้ให้คำขอถัดไปใช้:

pm.test("Save the auth token", function () {
    const token = pm.response.json().token;
    pm.environment.set("auth_token", token);
});

คำขอที่ตามมาใดๆ ก็สามารถส่ง Authorization: Bearer {{auth_token}} ได้ การเชื่อมโยงนี้เป็นวิธีที่คุณทดสอบโฟลว์ที่ขึ้นอยู่กับสถานะ เช่น การสร้างทรัพยากรแล้วตรวจสอบว่ามีอยู่จริง

Postman มีขอบเขตตัวแปรสองประเภทที่เกี่ยวข้องที่ควรรู้จัก ตัวแปรสภาพแวดล้อม (Environment variables) เป็นของสภาพแวดล้อมที่เลือกและเปลี่ยนไปเมื่อคุณสลับสภาพแวดล้อม ตัวแปรคอลเลกชัน (Collection variables) เป็นของคอลเลกชันโดยไม่คำนึงถึงสภาพแวดล้อม ซึ่งเหมาะสำหรับค่าคงที่สำหรับ API นั้น นอกจากนี้ยังมี ตัวแปรส่วนกลาง (global variables) ซึ่งใช้ได้ทุกที่ และ ตัวแปรท้องถิ่น (local variables) ที่มีอายุสั้นซึ่งมีอยู่สำหรับการรันเพียงครั้งเดียว การเลือกขอบเขตที่เหมาะสมจะทำให้ค่าอยู่ในที่ที่ควรอยู่และหลีกเลี่ยงความประหลาดใจเมื่อคุณเปลี่ยนเป้าหมาย

เรียกใช้คอลเลกชันทั้งหมดด้วย Collection Runner

การคลิก Send ในแต่ละคำขอนั้นใช้เวลานาน Collection Runner จะดำเนินการทุกคำขอในคอลเลกชันตามลำดับ รันการทดสอบทั้งหมด และให้สรุปผลการผ่าน/ไม่ผ่านแก่คุณ

เปิดคอลเลกชัน คลิกปุ่ม Run (หรือเมนูสามจุด จากนั้น Run collection) Runner จะแสดงคำขอของคุณตามลำดับ เลือกสภาพแวดล้อม กำหนดจำนวนการวนซ้ำที่จะรัน และเลือกที่จะแนบไฟล์ข้อมูล คลิก Run แล้ว Postman จะส่งคำขอทุกรายการจากบนลงล่าง โดยดำเนินการทดสอบของแต่ละคำขอ

หน้าผลลัพธ์จะแสดงคำยืนยันทุกรายการในทุกคำขอ พร้อมกับผลรวมของรายการที่ผ่านและไม่ผ่าน นี่คือการตรวจสอบรีเกรสชันของคุณ เรียกใช้หลังจากปรับใช้ (deploy) และคุณจะรู้ได้ในไม่กี่วินาทีว่า API ยังคงทำงานได้หรือไม่ Runner ยังเก็บประวัติการรันที่ผ่านมา เพื่อให้คุณสามารถเปรียบเทียบผลลัพธ์ของวันนี้กับเมื่อวาน และสังเกตได้ว่าชุดการทดสอบที่เคยผ่านเริ่มล้มเหลวเมื่อใด

ลำดับมีความสำคัญใน Runner เนื่องจากคำขอทำงานจากบนลงล่าง คุณสามารถใส่คำขอเข้าสู่ระบบก่อน เพื่อให้มันเติม auth_token จากนั้นให้คำขอทุกรายการที่อยู่ข้างใต้ใช้โทเค็นนั้นได้ สิ่งเดียวกันนี้ใช้กับการตั้งค่าและการล้างข้อมูล: สร้างทรัพยากรใกล้จุดเริ่มต้น ใช้งานตรงกลาง และลบออกในตอนท้าย คอลเลกชันที่จัดลำดับอย่างดีจะเขียนสคริปต์การเดินทางของผู้ใช้ได้อย่างมีประสิทธิภาพ

สำหรับการทดสอบที่ขับเคลื่อนด้วยข้อมูล (data-driven testing) ให้แนบไฟล์ CSV หรือ JSON ใน Runner แต่ละแถวจะกลายเป็นการวนซ้ำหนึ่งครั้ง และคุณสามารถอ้างอิงคอลัมน์เป็นตัวแปรเช่น {{username}} วิธีนี้ช่วยให้คำขอเดียวสามารถทดสอบชุดค่าผสมอินพุตหลายสิบชุดได้โดยไม่ต้องทำซ้ำคำขอ ตัวอย่างเช่น ปลายทางเข้าสู่ระบบสามารถถูกเรียกใช้ด้วยข้อมูลรับรองที่ถูกต้องหนึ่งแถวและข้อมูลที่ไม่ถูกต้องหลายแถว โดยแต่ละแถวจะยืนยันรหัสสถานะที่คาดหวัง บทความเกี่ยวกับ การทดสอบ API ที่ขับเคลื่อนด้วยข้อมูลโดยใช้ CSV และ JSON ครอบคลุมรูปแบบโดยละเอียด ในการเรียกใช้คอลเลกชันเดียวกันใน CI โดยไม่มี GUI Postman มีเครื่องมือบรรทัดคำสั่ง Newman ซึ่งอธิบายไว้ในการเปรียบเทียบ Newman กับ Postman

จุดที่ Postman เริ่มมีข้อจำกัดและสิ่งที่ควรพิจารณา

Postman ยอดเยี่ยมสำหรับการทดสอบเชิงสำรวจและชุดทดสอบขนาดเล็กถึงปานกลาง แต่มีสองจุดที่เป็นข้อจำกัดเมื่อโปรเจกต์เติบโตขึ้น ประการแรก คำยืนยันอยู่ใน JavaScript ดังนั้นผู้ที่ไม่ใช่นักพัฒนาและผู้ที่ทำงานด้าน QA ที่ต้องการวิธีที่มองเห็นได้จะต้องเรียนรู้เพิ่มเติม ประการที่สอง Postman เก็บการออกแบบ API การทดสอบ การจำลอง (mocking) และเอกสารไว้ในที่แยกกัน ซึ่งหมายความว่าข้อมูลการทดสอบและสัญญา API ของคุณอาจไม่ตรงกันได้

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

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

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

ฉันต้องเขียนโค้ดเพื่อทดสอบ API ใน Postman หรือไม่?

สำหรับการส่งคำขอและการอ่านการตอบกลับ ไม่จำเป็น สำหรับการยืนยันอัตโนมัติ ใช่ อย่างน้อยก็เล็กน้อย แท็บ Tests ของ Postman รัน JavaScript และใช้ออบเจกต์ pm รูปแบบนั้นเรียบง่ายและคุณสามารถคัดลอกได้จากแผง snippets ในตัวของ Postman แต่ก็ยังคงเป็น JavaScript หากคุณต้องการตัวสร้างคำยืนยันแบบกราฟิกที่ไม่ต้องใช้โค้ด แพลตฟอร์มเฉพาะอย่าง Apidog จะจัดการสิ่งนั้นได้

ความแตกต่างระหว่างคอลเลกชัน Postman และสภาพแวดล้อมคืออะไร?

คอลเลกชันคือชุดของคำขอที่จัดกลุ่มเข้าด้วยกัน มักจะมีการทดสอบของพวกเขาด้วย สภาพแวดล้อมคือชุดของตัวแปรที่มีชื่อ เช่น base_url หรือ auth_token คอลเลกชันเก็บสิ่งที่คุณส่ง สภาพแวดล้อมเก็บค่าที่เปลี่ยนแปลงระหว่าง staging, production และ local คุณสามารถชี้คอลเลกชันหนึ่งไปยังสภาพแวดล้อมที่แตกต่างกันเพื่อทดสอบคำขอเดียวกันกับเซิร์ฟเวอร์ที่แตกต่างกัน

ฉันจะรันการทดสอบ Postman โดยอัตโนมัติใน CI ได้อย่างไร?

ใช้ Newman ซึ่งเป็นตัวรันบรรทัดคำสั่งของ Postman ส่งออกคอลเลกชันและสภาพแวดล้อมของคุณ จากนั้นรัน newman run collection.json -e environment.json Newman จะออกด้วยรหัสที่ไม่ใช่ศูนย์หากการทดสอบใดล้มเหลว ซึ่งเป็นสิ่งที่ไปป์ไลน์ CI ของคุณตรวจสอบ คู่มือเกี่ยวกับ การทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD จะอธิบายวิธีการเชื่อมต่อสิ่งนี้เข้ากับไปป์ไลน์

Postman สามารถทดสอบ API ได้มากกว่า REST API หรือไม่?

ได้ Postman เวอร์ชันใหม่รองรับคำขอ GraphQL, gRPC, WebSocket และ SOAP นอกเหนือจาก HTTP และ REST ทั่วไป แท็บ Tests และคำยืนยันใช้งานได้กับส่วนใหญ่เหล่านี้ แม้ว่าการตั้งค่าคำขอที่แน่นอนจะแตกต่างกันไปตามแต่ละโปรโตคอล

คำขอหนึ่งควรมีคำยืนยันกี่รายการ?

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