วิธีเขียน Test Case API: เทมเพลตและตัวอย่าง

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

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

กรณีทดสอบ API คืออะไรกันแน่

กรณีทดสอบ API คือชุดของอินพุต การกระทำ และผลลัพธ์ที่คาดหวังที่กำหนดไว้ เพื่อยืนยันว่า endpoint หนึ่งทำงานได้อย่างถูกต้องภายใต้เงื่อนไขเฉพาะหนึ่งๆ มันแคบกว่าสถานการณ์ทดสอบ สถานการณ์จะกล่าวว่า “ยืนยันการเข้าสู่ระบบของผู้ใช้” แต่กรณีทดสอบจะกล่าวว่า “POST ข้อมูลประจำตัวที่ถูกต้องไปยัง /auth/login และยืนยันการตอบกลับ 200 พร้อม JWT ใน body ภายใน 800 มิลลิวินาที”

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

การทดสอบ API มักจะครอบคลุมห้ามุมมอง และกรณีของคุณควรกระจายไปทั่วทั้งหมด:

• Functional (การทำงาน): endpoint ส่งคืนข้อมูลที่ถูกต้องสำหรับอินพุตที่ถูกต้องหรือไม่?
• Negative (เชิงลบ): ปฏิเสธอินพุตที่ไม่ถูกต้องพร้อมข้อผิดพลาดและสถานะโค้ดที่ถูกต้องหรือไม่?
• Performance (ประสิทธิภาพ): ตอบสนองภายในระยะเวลาที่ยอมรับได้หรือไม่?
• Security (ความปลอดภัย): บังคับใช้การตรวจสอบสิทธิ์ การอนุญาต และขีดจำกัดอินพุตหรือไม่?
• Contract (ข้อตกลง): การตอบกลับตรงกับ schema ที่ระบุในเอกสารหรือไม่?

ชุดทดสอบที่ตรวจสอบเฉพาะเส้นทางแห่งความสุข (happy path) จะผ่านไปได้จนกว่าผู้ใช้จริงจะส่งช่องรหัสผ่านที่ว่างเปล่า

ทำไมคุณถึงต้องการเทมเพลตกรณีทดสอบ

การเขียนแต่ละกรณีจากหน้าว่างเปล่าจะทำให้เกิดการครอบคลุมที่ไม่สอดคล้องกัน วิศวกรคนหนึ่งบันทึกสถานะโค้ดที่คาดหวัง; อีกคนบันทึก response bodies; คนที่สามเขียนว่า “ควรทำงาน” เทมเพลตจะแก้ไขปัญหานั้นโดยการบังคับใช้โครงสร้างเดียวกันทุกครั้ง

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

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

โครงสร้างของกรณีทดสอบ API ที่แข็งแกร่ง

เทมเพลตกรณีทดสอบ API ที่สมบูรณ์มีฟิลด์เหล่านี้ คุณไม่จำเป็นต้องใช้ทั้งหมดสำหรับทุกกรณี แต่ชุดหลักเป็นสิ่งที่ขาดไม่ได้

ฟิลด์ที่ทีมมักจะข้ามบ่อยที่สุดคือเวลาตอบกลับที่คาดหวังและ response body ที่คาดหวัง การข้ามสิ่งเหล่านี้คือวิธีที่การทดสอบ “ผ่าน” ในขณะที่ส่งคืนโค้ด 200 พร้อม payload ที่ว่างเปล่า หรือ payload ที่ถูกต้องแต่ช้าไปสามวินาที

วิธีเขียนกรณีทดสอบ API ทีละขั้นตอน

อ่านเอกสารประกอบ API ก่อน สังเกตพารามิเตอร์ที่จำเป็น วิธีการตรวจสอบสิทธิ์ รหัสสถานะที่ระบุในเอกสาร และ response schema กรณีทดสอบทุกกรณีคือการอ้างสิทธิ์เกี่ยวกับพฤติกรรมที่ระบุในเอกสาร ดังนั้นเอกสารจึงเป็นแหล่งข้อมูลที่เชื่อถือได้ของคุณ เครื่องมือที่อ่าน OpenAPI spec เพื่อสร้างชุดการทดสอบ สามารถให้โครงสร้างเริ่มต้นแก่คุณได้

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

เตรียมข้อมูลทดสอบที่แตกต่างกัน กรณีเชิงลบต้องการข้อมูลที่ผิดพลาดในลักษณะเดียวเท่านั้น การใช้ payload เดียวกันซ้ำในหลายๆ กรณีจะซ่อนข้อบกพร่อง เนื่องจากคุณทดสอบเส้นทางเดียวเท่านั้น

เขียนผลลัพธ์ที่คาดหวังอย่างแม่นยำ “ส่งคืนความสำเร็จ” ไม่ใช่การยืนยัน “ส่งคืน 200, body มีสตริง token ที่ไม่ว่างเปล่า, expires_in เท่ากับ 3600” คือการยืนยัน ความแม่นยำตรงนี้คือสิ่งที่ทำให้กรณีนี้คุ้มค่าที่จะรัน

เพิ่มกรณีลงในชุดที่สามารถรันได้ กรณีในสเปรดชีตแสดงถึงความตั้งใจ กรณีในเครื่องมือทดสอบสร้างผลลัพธ์ผ่านหรือไม่ผ่าน จัดกลุ่มกรณีที่เกี่ยวข้องเพื่อให้ endpoint ทั้งหมดรันได้ในคลิกเดียว; ชุดทดสอบ มีไว้เพื่อสิ่งนี้โดยเฉพาะ

อัปเดตกรณีให้ทันสมัยอยู่เสมอ เมื่อ API เปลี่ยนแปลง กรณีก็จะเปลี่ยนแปลงตามไปด้วย กรณีที่ล้าสมัยซึ่งยืนยัน schema เก่าแย่กว่าไม่มีกรณี เพราะมันล้มเหลวด้วยเหตุผลที่ไม่ถูกต้องและฝึกให้ทีมเพิกเฉยต่อการสร้างที่ล้มเหลว

ตัวอย่างที่ทำเสร็จแล้ว: การทดสอบ Login Endpoint

พิจารณา endpoint การตรวจสอบสิทธิ์มาตรฐาน: POST /auth/login ซึ่งรับอีเมลและรหัสผ่านและส่งคืน JWT นี่คือสี่กรณีที่ครอบคลุมได้อย่างถูกต้อง

AUTH-LOGIN-001: ข้อมูลรับรองที่ถูกต้อง (functional, critical)

• Endpoint: POST /auth/login
• เงื่อนไขเบื้องต้น: มีผู้ใช้ที่มีอีเมล dana@example.com อยู่
• Body: {"email": "dana@example.com", "password": "Correct-Horse-9"}
• สถานะที่คาดหวัง: 200
• การตอบกลับที่คาดหวัง: body มี token ที่ไม่ว่างเปล่า (string), token_type เท่ากับ Bearer, expires_in เท่ากับ 3600
• เวลาตอบกลับที่คาดหวัง: ต่ำกว่า 800 มิลลิวินาที

AUTH-LOGIN-002: รหัสผ่านผิด (negative, critical)

• Body: {"email": "dana@example.com", "password": "wrong"}
• สถานะที่คาดหวัง: 401
• การตอบกลับที่คาดหวัง: error เท่ากับ invalid_credentials; ไม่มีฟิลด์ token
• หมายเหตุ: ข้อความต้องไม่เปิดเผยว่าอีเมลนั้นมีอยู่หรือไม่

AUTH-LOGIN-003: ไม่มีฟิลด์รหัสผ่าน (negative, high)

• Body: {"email": "dana@example.com"}
• สถานะที่คาดหวัง: 400
• การตอบกลับที่คาดหวัง: error เท่ากับ validation_error; details ระบุฟิลด์ password

AUTH-LOGIN-004: อีเมลผิดรูปแบบ (negative, medium)

• Body: {"email": "not-an-email", "password": "Correct-Horse-9"}
• สถานะที่คาดหวัง: 400
• การตอบกลับที่คาดหวัง: error เท่ากับ validation_error

สี่กรณี, หนึ่ง endpoint, และคุณกำลังตรวจสอบข้อตกลง รูปแบบข้อผิดพลาด รหัสสถานะ และงบประมาณความหน่วงแล้ว เพิ่มกรณีความปลอดภัยสำหรับสตริง SQL-injection ในช่องอีเมล และคุณก็จะมีชุดทดสอบที่คุ้มค่าที่จะรันในการคอมมิตทุกครั้ง

การเขียนกรณีทดสอบเดียวกันใน Apidog

คุณสามารถรันทั้งสี่กรณีข้างต้นได้โดยไม่ต้องเขียนสคริปต์แม้แต่บรรทัดเดียว ใน Apidog กรณีทดสอบ API ถูกสร้างขึ้นด้วยภาพ

1. นำเข้าหรือกำหนด endpoint นำ POST /auth/login เข้ามาจากไฟล์ OpenAPI, คอลเลกชัน Postman หรือกำหนดโดยตรง Request schema จะเป็นพื้นฐานสำหรับการยืนยันทุกอย่าง
2. เพิ่มข้อมูลคำขอ ป้อน body สำหรับกรณี AUTH-LOGIN-001 สำหรับการครอบคลุมแบบ data-driven ให้แนบไฟล์ CSV หรือ JSON เพื่อให้กรณีเดียวรันกับข้อมูลรับรองทุกแถว; นี่คือวิธีที่ การทดสอบ API แบบ data-driven แทนที่สี่กรณีที่เกือบจะเหมือนกันด้วยกรณีเดียว
3. ตั้งค่าการยืนยันด้วยภาพ คลิกเพื่อยืนยันว่าสถานะเท่ากับ 200, ว่า token มีอยู่และเป็นสตริงที่ไม่ว่างเปล่า, ว่า expires_in เท่ากับ 3600, และเวลาตอบกลับยังคงอยู่ต่ำกว่า 800 มิลลิวินาที ไม่จำเป็นต้องใช้สคริปต์
4. จัดกลุ่มกรณีเข้าสู่สถานการณ์ทดสอบ เพิ่มทั้งสี่กรณีการเข้าสู่ระบบลงในสถานการณ์เดียวเพื่อให้ endpoint ถูกทดสอบอย่างเต็มที่ในการรันครั้งเดียว
5. รันและอ่านรายงาน Apidog จะดำเนินการสถานการณ์ สร้างรายงานผ่าน/ไม่ผ่านต่อกรณี และแสดงการยืนยันที่ล้มเหลว คุณสามารถรันสถานการณ์ได้ทั้งในเครื่อง ตามกำหนดเวลา หรือภายใน CI

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

ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยง

ยืนยันเฉพาะสถานะโค้ดเท่านั้น โค้ด 200 หมายถึงคำขอได้รับการจัดการ ไม่ใช่ว่าการตอบกลับถูกต้อง ตรวจสอบฟิลด์ใน body เสมอ

หนึ่งกรณีใหญ่ต่อ endpoint เมื่อล้มเหลว คุณไม่ได้เรียนรู้อะไรเลย แบ่งตามเงื่อนไข

ข้อมูลทดสอบที่ใช้ซ้ำ หากทุกกรณีเชิงลบส่ง payload เดียวกัน คุณจะทดสอบเฉพาะโหมดความล้มเหลวเดียวเท่านั้น

ไม่มีการยืนยันความหน่วง การถดถอยประสิทธิภาพจะเล็ดลอดผ่านไปอย่างเงียบๆ เมื่อไม่มีอะไรวัดเวลาตอบกลับ

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

ดาวน์โหลด Apidog หากคุณต้องการทำตามตัวอย่างและสร้างสี่กรณีการเข้าสู่ระบบด้วยตัวเอง

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

หนึ่ง endpoint ต้องการกี่กรณีทดสอบ? เพียงพอที่จะครอบคลุม happy path, ความล้มเหลวทุกฟิลด์ที่จำเป็น, ความล้มเหลวในการตรวจสอบสิทธิ์หนึ่งครั้ง, และการตรวจสอบความปลอดภัยหนึ่งครั้ง สำหรับ endpoint ที่เรียบง่าย นั่นคือสี่ถึงหกกรณี; สำหรับ endpoint ที่ซับซ้อน อาจมากกว่านั้น

ฉันควรเขียนกรณีทดสอบก่อนที่จะสร้าง API หรือไม่? ใช่ การเขียนกรณีทดสอบเทียบกับการออกแบบ (design-first) ช่วยให้ตรวจพบช่องว่างในข้อตกลงได้ตั้งแต่เนิ่นๆ ควบคู่ไปกับการ สร้างกรณีทดสอบด้วย AI เพื่อร่างชุดแรกได้อย่างรวดเร็ว จากนั้นจึงปรับปรุงด้วยตนเอง

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

กรณีทดสอบกับสถานการณ์ทดสอบแตกต่างกันอย่างไร? สถานการณ์คือเป้าหมายระดับสูง (“ยืนยันการเข้าสู่ระบบ”); กรณีคือการตรวจสอบที่เป็นรูปธรรมและสามารถรันได้หนึ่งครั้งภายในสถานการณ์นั้น ดู สถานการณ์ทดสอบกับกรณีทดสอบ