การร้องขอ API ที่ส่งคืนการตอบกลับไม่ใช่การทดสอบที่ผ่าน มันเป็นเพียงการตอบกลับ การทดสอบจะมีอยู่ก็ต่อเมื่อมีบางสิ่งตรวจสอบว่าการตอบกลับนั้นถูกต้อง การตรวจสอบนั้นคือการยืนยัน (assertion) และคุณภาพของการยืนยันของคุณจะเป็นตัวตัดสินว่าชุดการทดสอบของคุณตรวจพบข้อผิดพลาดจริง ๆ หรือเพียงแค่ยืนยันว่าเซิร์ฟเวอร์ยังทำงานอยู่
คู่มือนี้จะอธิบายว่าการยืนยัน API คืออะไร ประเภทที่ควรเขียน ทีมงานมักผิดพลาดตรงไหน และวิธีสร้างการยืนยันด้วยภาพใน Apidog โดยไม่ต้องเขียนสคริปต์
การยืนยัน API คืออะไร
การยืนยัน (assertion) คือข้อความเกี่ยวกับการตอบกลับที่ต้องเป็นจริงเพื่อให้การทดสอบผ่าน คุณส่งคำขอ API ตอบกลับ และการยืนยันจะเปรียบเทียบส่วนหนึ่งของการตอบกลับนั้นกับค่าที่คาดไว้ หากตรงกันถือว่าผ่าน หากไม่ตรงกันถือว่าไม่ผ่าน
หากไม่มีการยืนยัน การทดสอบอัตโนมัติจะพิสูจน์ได้เพียงว่าปลายทางนั้นเข้าถึงได้ แต่เมื่อมีการยืนยัน มันพิสูจน์ว่าปลายทางนั้น ถูกต้อง ช่องว่างระหว่างสองสิ่งนี้คือที่มาของเหตุการณ์ที่เกิดขึ้นจริงในการผลิตส่วนใหญ่: API ทำงานอยู่ ส่งคืนโค้ด 200 แต่เนื้อหา (body) ผิด
การยืนยันที่มีประโยชน์คือการยืนยันที่เฉพาะเจาะจงและเป็นอิสระ เฉพาะเจาะจงเพื่อให้ความล้มเหลวชี้ไปยังสิ่งเดียว เป็นอิสระเพื่อให้ไม่ขึ้นอยู่กับการยืนยันอื่นที่ต้องผ่านก่อนอย่างเงียบ ๆ ขั้นตอนการทดสอบเดียวมักจะมีการยืนยันหลายรายการ ซึ่งแต่ละรายการจะตรวจสอบแง่มุมที่แตกต่างกันของการตอบกลับเดียวกัน
การยืนยันรหัสสถานะ และทำไมมันถึงไม่เพียงพอ
การยืนยันที่พบบ่อยที่สุดคือการตรวจสอบรหัสสถานะ HTTP: คาดหวัง 200 สำหรับการอ่านที่สำเร็จ 201 สำหรับทรัพยากรที่ถูกสร้างขึ้น 400 สำหรับข้อมูลเข้าที่ไม่ถูกต้อง 401 สำหรับการตรวจสอบสิทธิ์ที่หายไป นี่เป็นสิ่งจำเป็น การทำความเข้าใจรหัสสถานะให้ถูกต้องเป็นเรื่องที่ต้องเรียนรู้ด้วยตนเอง; รหัสสถานะ HTTP ที่ REST API ควรใช้ คุ้มค่าที่จะอ่านหาก API ของคุณมีความไม่สอดคล้องกันในเรื่องนี้
แต่การยืนยันรหัสสถานะเพียงอย่างเดียวนั้นอ่อนแอ API สามารถส่งคืน 200 OK พร้อมเนื้อหาที่ว่างเปล่า ค่าที่ล้าสมัย ค่า null ที่ควรเป็นอ็อบเจกต์ หรือข้อความแสดงข้อผิดพลาดที่ดูเหมือนสำเร็จ รหัสสถานะบอกว่าคำขอได้รับการจัดการแล้ว ไม่ได้บอกอะไรเกี่ยวกับว่าข้อมูลถูกต้องหรือไม่
ถือว่าการยืนยันสถานะเป็นบรรทัดแรกของขั้นตอนการทดสอบ ไม่ใช่บรรทัดเดียว
ประเภทของการยืนยันที่คุ้มค่าแก่การเขียน
การยืนยันเนื้อหา Body. ตรวจสอบค่าจริงในการตอบกลับ ฟิลด์ id มีอยู่และไม่ว่างเปล่า ฟิลด์ email ตรงกับสิ่งที่คุณส่ง ฟิลด์ total เท่ากับผลรวมของรายการสินค้า สิ่งเหล่านี้จะจับข้อผิดพลาดทางตรรกะที่รหัสสถานะพลาดไป
การยืนยัน Schema. ตรวจสอบ รูปร่าง ของการตอบกลับเทียบกับ JSON Schema หรือคำนิยาม OpenAPI: ฟิลด์ที่จำเป็นมีอยู่ ประเภทถูกต้อง ไม่มีฟิลด์ที่ไม่คาดคิดปรากฏขึ้น การยืนยัน Schema จะจับข้อผิดพลาดที่เกิดจากการเปลี่ยนแปลงสัญญา (contract drift) ที่แบ็กเอนด์เปลี่ยนฟิลด์จากสตริงเป็นอ็อบเจกต์อย่างเงียบๆ และทำให้ไคลเอนต์ทั้งหมดเสีย การตรวจสอบนี้ทับซ้อนกับการ ทดสอบสัญญา API ซึ่งทำให้แนวคิดนี้เป็นทางการระหว่างผู้ผลิตและผู้บริโภค
การยืนยัน Header. ยืนยันว่า Content-Type เป็น application/json, ว่า header การแคชถูกตั้งค่าตามที่ตั้งใจไว้, ว่า header CORS มีอยู่, และว่า header ความปลอดภัยเช่น Strict-Transport-Security มีอยู่
การยืนยันเวลาตอบสนอง. กำหนดงบประมาณความล่าช้า เช่น 800 ms และให้การทดสอบล้มเหลวเมื่อการตอบสนองช้ากว่านั้น การถดถอยของประสิทธิภาพนั้นมองไม่เห็นด้วยการยืนยันประเภทอื่น ๆ ดังนั้นนี่เป็นสิ่งเดียวที่สามารถตรวจจับได้ในชุดฟังก์ชันการทำงาน
การยืนยันรูปแบบข้อผิดพลาด. สำหรับกรณีที่เป็นลบ ให้ยืนยันเนื้อหาข้อผิดพลาด ไม่ใช่แค่โค้ด 4xx เท่านั้น ฟิลด์ error เท่ากับ validation_error, อาร์เรย์ details ระบุฟิลด์ที่ผิด และไม่มีข้อมูลที่ละเอียดอ่อนรั่วไหลในข้อความ
การยืนยันความปลอดภัย. ยืนยันว่าปลายทางปฏิเสธคำขอที่ไม่มีโทเค็น ปฏิเสธโทเค็นที่หมดอายุ บังคับใช้การอนุญาตระหว่างผู้ใช้ และไม่สะท้อน payload การโจมตีกลับโดยไม่มีการหลีกเลี่ยงอักขระพิเศษ
ขั้นตอนการทดสอบที่ยืนยันสถานะ สองหรือสามฟิลด์ในเนื้อหา สคีมา และงบประมาณเวลาตอบสนองนั้นเป็นการทำงานจริง ขั้นตอนที่ยืนยันเฉพาะสถานะเท่านั้นเป็นเพียงการตกแต่ง
ตรรกะการยืนยันผิดพลาดตรงไหน
การยืนยันมากเกินไปกับข้อมูลที่เปลี่ยนแปลงได้. การยืนยันค่า created_at ที่แน่นอนหรือ UUID ที่สร้างขึ้น ทำให้การทดสอบล้มเหลวทุกครั้งโดยไม่มีเหตุผล ยืนยันว่าฟิลด์นั้นมีอยู่และมีประเภทที่ถูกต้อง ไม่ใช่ค่าที่แน่นอน
การยืนยันน้อยเกินไปในเส้นทางที่สำเร็จ (happy path). การทดสอบเส้นทางที่สำเร็จคือการทดสอบที่มักจะยืนยันเฉพาะรหัสสถานะเท่านั้น นอกจากนี้ยังเป็นสิ่งที่ผู้ใช้ใช้งานบ่อยที่สุด ให้การยืนยันที่ละเอียดถี่ถ้วนที่สุด ไม่ใช่น้อยที่สุด
การยืนยันที่ขึ้นอยู่กับลำดับ. หากการยืนยัน B มีความหมายก็ต่อเมื่อการยืนยัน A ผ่าน แต่ทั้งสองทำงานแบบไม่แยกแยะ ความล้มเหลวใน A จะทำให้เกิดความล้มเหลวครั้งที่สองที่สับสนใน B จัดโครงสร้างขั้นตอนเพื่อให้การพึ่งพากันนั้นชัดเจน
การยืนยันเดียวที่ทำสองหน้าที่. "การตอบกลับถูกต้อง" ไม่ใช่การยืนยัน แยกมันออก: สถานะเป็น 200, token มีอยู่, expires_in เท่ากับ 3600 การตรวจสอบสามครั้ง ข้อความแสดงความล้มเหลวที่ชัดเจนสามข้อความ
ละเลยกรณีที่เป็นลบ. ทีมงานยืนยันอย่างหนักแน่นในกรณีที่สำเร็จและแทบจะไม่ได้ยืนยันเลยในกรณีที่ล้มเหลว กรณีที่เป็นลบที่ไม่มีการยืนยันเนื้อหา (body assertion) เพียงพิสูจน์ว่า API ตอบว่า "ไม่" ไม่ใช่ว่าตอบว่าไม่ อย่างถูกต้อง
การสร้างการยืนยันใน Apidog
ใน Apidog การยืนยันเป็นส่วนหนึ่งของตัวสร้างการทดสอบแบบภาพ คุณจึงสามารถกำหนดได้โดยการคลิกแทนที่จะเขียนสคริปต์
สำหรับคำขอใดๆ ในสถานการณ์การทดสอบ ให้เปิดแผงการยืนยันและเพิ่มการตรวจสอบ:
- การยืนยันสถานะ. เลือก “สถานะการตอบกลับ” และตั้งค่าให้เท่ากับ
200 - การยืนยันฟิลด์ Body. ใช้นิพจน์ JSONPath เช่น
$.tokenและยืนยันว่ามีอยู่และเป็นสตริงที่ไม่ว่างเปล่า; ยืนยันว่า$.expires_inเท่ากับ3600Apidog จะอ่านโครงสร้างการตอบกลับ คุณจึงเลือกฟิลด์ได้แทนที่จะพิมพ์พาธแบบตาบอด - การยืนยัน Schema. ตรวจสอบการตอบกลับเทียบกับ schema ที่กำหนดของปลายทาง เนื่องจาก Apidog เก็บการออกแบบ API และการทดสอบไว้ในพื้นที่ทำงานเดียวกัน schema ที่การยืนยันของคุณใช้จึงเป็น schema เดียวกับที่เอกสารของคุณเผยแพร่; ไม่มีสำเนาที่สองให้เกิดการเปลี่ยนแปลง
- การยืนยันเวลาตอบสนอง. เพิ่มการตรวจสอบว่าเวลาตอบสนองอยู่ต่ำกว่างบประมาณของคุณ
- สคริปต์ที่กำหนดเอง เมื่อจำเป็นเท่านั้น. สำหรับตรรกะที่การตรวจสอบด้วยภาพไม่สามารถแสดงได้ ให้ใช้ JavaScript post-processor การยืนยันส่วนใหญ่ไม่จำเป็นต้องใช้สิ่งนี้เลย
จัดกลุ่มการยืนยันในสถานการณ์และ Apidog จะรันพวกมันพร้อมกัน สำหรับการครอบคลุมที่ปรับขนาดได้ ให้แนบไฟล์ข้อมูลเพื่อให้ชุดการยืนยันเดียวรันกับแต่ละแถวของ ข้อมูลการทดสอบแบบขับเคลื่อนด้วยข้อมูล เมื่อสถานการณ์รัน รายงานที่สร้างขึ้น จะแสดงอย่างชัดเจนว่าการยืนยันใดล้มเหลว ในคำขอใด พร้อมกับค่าที่คาดหวังและค่าจริงเปรียบเทียบกัน
สถานการณ์เดียวกันจะรันโดยไม่เปลี่ยนแปลงใน CI ดังนั้นทุกการคอมมิตจะตรวจสอบการยืนยันทุกครั้งอีกครั้ง; การทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD ครอบคลุมการเชื่อมต่อนี้ ดาวน์โหลด Apidog เพื่อสร้างชุดการยืนยันสำหรับปลายทางของคุณเอง
ชุดการยืนยันที่ใช้งานได้จริง
พิจารณา GET /users/{id} ที่ส่งคืนอ็อบเจกต์ผู้ใช้ ชุดการยืนยันที่แข็งแกร่งสำหรับเส้นทางที่สำเร็จ (happy path):
- สถานะเท่ากับ
200 - Header
Content-Typeมีapplication/json $.idเท่ากับ id ที่ร้องขอ$.emailมีอยู่และตรงกับรูปแบบอีเมล$.roleเป็นหนึ่งในadmin,member,viewer- เนื้อหาการตอบกลับเป็นไปตาม Schema ของ
User - เวลาตอบสนองต่ำกว่า 600 มิลลิวินาที
และสำหรับ GET /users/{id} โดยใช้ ID ที่ไม่รู้จัก:
- สถานะเท่ากับ
404 $.errorเท่ากับnot_found- เนื้อหาการตอบกลับไม่มีฟิลด์
email,idหรือฟิลด์ผู้ใช้อื่นๆ
คำขอสองรายการ การยืนยันสิบเอ็ดรายการ และคุณได้ยืนยันสัญญา ข้อมูล หัวข้อ ประสิทธิภาพ และพฤติกรรมข้อผิดพลาด นั่นคือสิ่งที่แยกแยะชุดการทดสอบที่ปกป้องการเผยแพร่จากชุดการทดสอบที่เพียงแค่ ping เซิร์ฟเวอร์
การยืนยันใน CI pipeline
การยืนยันจะได้รับคุณค่าอย่างเต็มที่เมื่อทำงานโดยอัตโนมัติ ชุดการทดสอบที่ใครบางคนรันด้วยมือสัปดาห์ละครั้งจะจับบั๊กช้าไปหนึ่งสัปดาห์ ชุดการทดสอบเดียวกันที่เชื่อมต่อเข้ากับ CI จะจับบั๊กได้ตั้งแต่ตอน pull request
เมื่อการยืนยันทำงานใน pipeline มีการออกแบบสองทางเลือกที่สำคัญ ประการแรก ความล้มเหลวจะต้องไม่คลุมเครือ บันทึก CI ที่ระบุว่า "การทดสอบล้มเหลว" บังคับให้นักพัฒนาต้องจำลองการรันในเครื่อง บันทึกที่ระบุว่า "คาดว่า $.expires_in เท่ากับ 3600 แต่ได้ 7200 ใน POST /auth/login" บอกให้พวกเขารู้ว่าควรดูที่ใดทันที การยืนยันที่แข็งแกร่งและเฉพาะเจาะจงคือสิ่งที่ทำให้เกิดความล้มเหลวที่อ่านง่าย
ประการที่สอง การยืนยันจำเป็นต้องมีความเสถียรข้ามสภาพแวดล้อม การยืนยันที่ฮาร์ดโค้ด user id ของ Production จะล้มเหลวใน Staging ด้วยเหตุผลที่ไม่เกี่ยวข้องกับโค้ด เก็บค่าเฉพาะสภาพแวดล้อมไว้ในตัวแปร และยืนยันโครงสร้างและประเภทที่ค่าที่แน่นอนขึ้นอยู่กับสภาพแวดล้อม การยืนยัน Schema สามารถเคลื่อนย้ายได้ดีระหว่างสภาพแวดล้อม แต่การยืนยัน id ที่สร้างขึ้นเฉพาะเจาะจงไม่สามารถทำได้
รูปแบบการปฏิบัติ: ยืนยันสถานะและ schema บนทุกปลายทางเป็นเกณฑ์มาตรฐานที่รันได้ทุกที่ จากนั้นวางซ้อนการยืนยันค่าที่คำนึงถึงสภาพแวดล้อมด้านบน เกณฑ์มาตรฐานจะจับการเปลี่ยนแปลงสัญญาในสภาพแวดล้อมใดก็ได้; การยืนยันค่าจะจับข้อผิดพลาดทางตรรกะในที่ที่คุณมีข้อมูลที่เสถียร รันทั้งสองอย่างในการคอมมิตทุกครั้ง และชุดการทดสอบจะกลายเป็นประตูควบคุมมากกว่ารายงาน
คำถามที่พบบ่อย
ความแตกต่างระหว่างการยืนยัน (assertion) และกรณีทดสอบ (test case) คืออะไร? กรณีทดสอบคือการตรวจสอบทั้งหมด: คำขอพร้อมกับผลลัพธ์ที่คาดหวัง การยืนยันคือการเปรียบเทียบแต่ละรายการภายในนั้นที่ตัดสินว่าผ่านหรือไม่ผ่าน ดู วิธีเขียนกรณีทดสอบ API
คำขอหนึ่งควรมีการยืนยันกี่ครั้ง? เพียงพอที่จะครอบคลุมสถานะ, ฟิลด์ body ที่สำคัญ, schema และงบประมาณความล่าช้า สำหรับปลายทางส่วนใหญ่จะอยู่ที่สี่ถึงแปดรายการ มากกว่านั้นก็ดีหากแต่ละรายการตรวจสอบสิ่งที่แตกต่างกัน
ฉันควรยืนยันเนื้อหาการตอบกลับที่แน่นอนหรือไม่? ยืนยันฟิลด์ที่เสถียรอย่างแน่นอน และฟิลด์ที่เปลี่ยนแปลงได้โดยใช้ประเภทหรือการมีอยู่ การยืนยัน body ทั้งหมดรวมถึง timestamp และ ID ที่สร้างขึ้น จะทำให้การทดสอบล้มเหลวทุกครั้งที่รัน
ฉันสามารถยืนยันประสิทธิภาพของ API ในการทดสอบเชิงฟังก์ชันได้หรือไม่? ได้ การยืนยันเวลาตอบสนองจะจับการถดถอยของความล่าช้าในระหว่างการรันฟังก์ชันปกติ ไม่ต้องมีการทดสอบโหลดแยกต่างหากสำหรับการตรวจสอบงบประมาณพื้นฐาน
กรณีทดสอบเชิงลบควรมีการยืนยันด้วยหรือไม่? แน่นอน และเป็นกรณีที่มักถูกปล่อยทิ้งไว้โดยไม่มีการตรวจสอบใดๆ กรณีเชิงลบที่มีเพียงการตรวจสอบรหัสสถานะเพียงพิสูจน์ว่า API ปฏิเสธ ไม่ใช่ว่าปฏิเสธ อย่างถูกต้อง ยืนยันฟิลด์ข้อผิดพลาด รายละเอียดฟิลด์ที่ผิด และการไม่มีข้อมูลที่ละเอียดอ่อนใดๆ ในข้อความ
ควรใช้สคริปต์การยืนยันแบบกำหนดเองที่ใด? สงวนสคริปต์ไว้สำหรับตรรกะที่ตัวสร้างภาพไม่สามารถแสดงได้: การเปรียบเทียบข้ามคำขอ ค่าที่ได้มา หรือการตรวจสอบแบบมีเงื่อนไขที่ขึ้นอยู่กับการตอบกลับก่อนหน้า การยืนยันส่วนใหญ่ เช่น สถานะ สคีมา ฟิลด์ body และเวลา จะสะอาดกว่าและตรวจสอบได้ง่ายกว่าเมื่อเป็นการตรวจสอบด้วยภาพ