การตรวจสอบความถูกต้อง เทียบกับการพิสูจน์ยืนยัน: ความแตกต่างที่สำคัญในการทดสอบ

ทีมพัฒนาสามารถสร้างซอฟต์แวร์ที่ตรงตามข้อกำหนดอย่างสมบูรณ์แบบ แต่ก็ยังส่งมอบผลิตภัณฑ์ที่ผิดพลาดได้ พวกเขายังสามารถสร้างผลิตภัณฑ์ที่ถูกต้องอย่างแท้จริงบนโค้ดที่เต็มไปด้วยข้อบกพร่อง ความล้มเหลวสองประการนี้มีชื่อเรียก: อย่างแรกคือปัญหาการตรวจสอบ (verification problem) ส่วนอย่างที่สองคือปัญหาการรับรองความถูกต้อง (validation problem) การสับสนระหว่างสองสิ่งนี้คือสาเหตุที่กระบวนการควบคุมคุณภาพมักจะยุ่งวุ่นวายแต่ไร้ประสิทธิภาพ

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

การตรวจสอบ (Verification) คืออะไร?

การตรวจสอบ (Verification) ถามว่า: เรากำลังสร้างผลิตภัณฑ์ได้ถูกต้องหรือไม่?

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

การตรวจสอบจะเกิดขึ้นอย่างต่อเนื่องตลอดการพัฒนา ไม่ใช่แค่ตอนท้าย กิจกรรมการตรวจสอบทั่วไปได้แก่:

• การตรวจสอบโค้ดและการเดินหน้าโค้ด (Code reviews and walkthroughs)
• การวิเคราะห์แบบคงที่ (Static analysis) และการตรวจสอบรูปแบบโค้ด (linting)
• การตรวจสอบการออกแบบและสถาปัตยกรรม
• การตรวจสอบ Schema และสัญญา (contract checks)
• การทดสอบหน่วย (Unit tests) ที่ยืนยันว่าฟังก์ชันทำงานตามที่ระบุใน Signature

คุณสมบัติสำคัญคือ การตรวจสอบส่วนใหญ่เป็นการภายใน เป็นการเปรียบเทียบสิ่งประดิษฐ์หนึ่งกับอีกสิ่งประดิษฐ์หนึ่ง: โค้ดกับการออกแบบ, การตอบสนองกับ Schema, การนำไปใช้กับข้อกำหนด ไม่จำเป็นต้องมีผู้ใช้จริง หากข้อกำหนดระบุว่า endpoint จะส่งคืน 201 พร้อมเฮดเดอร์ Location การตรวจสอบจะยืนยันว่ามันทำเช่นนั้นจริง ๆ

การรับรองความถูกต้อง (Validation) คืออะไร?

การรับรองความถูกต้อง (Validation) ถามว่า: เรากำลังสร้างผลิตภัณฑ์ที่ถูกต้องหรือไม่?

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

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

• การทดสอบการยอมรับของผู้ใช้ (User acceptance testing)
• โปรแกรมเบต้าและการทดสอบการใช้งาน (Beta programs and usability testing)
• การทดสอบแบบ End-to-End ของขั้นตอนการทำงานที่สมบูรณ์
• การนำเสนอและลงนามอนุมัติจากผู้มีส่วนได้ส่วนเสีย

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

การรับรองความถูกต้อง vs การตรวจสอบ: ความแตกต่าง

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

คำช่วยจำง่ายๆ: การตรวจสอบคือการทดสอบกับ *เอกสาร* ส่วนการรับรองความถูกต้องคือการทดสอบกับ *วัตถุประสงค์*

สิ่งนี้มีผลอย่างไรกับการทดสอบ API

API ทำให้ความแตกต่างนี้เป็นรูปธรรม เพราะ API มีข้อกำหนดที่ชัดเจนและสามารถอ่านได้ด้วยเครื่องจักร: OpenAPI หรือคำจำกัดความ Schema ข้อกำหนดนั้นคือพื้นฐานของการตรวจสอบ

การตรวจสอบสำหรับ API หมายถึงการตรวจสอบการใช้งานเทียบกับสัญญา:

• แต่ละ endpoint ส่งคืนรหัสสถานะที่ระบุในเอกสารหรือไม่? การทำให้สิ่งเหล่านี้สอดคล้องกันเป็นเรื่องของวินัยในตัวเอง โปรดดู รหัสสถานะ HTTP ที่ REST API ควรสื่อสาร
• การตอบสนองทุกอย่างตรงกับ Schema ที่ระบุในเอกสารหรือไม่ โดยมีชื่อฟิลด์และประเภทที่ถูกต้อง?
• พารามิเตอร์ที่จำเป็นถูกบังคับใช้อย่างถูกต้องตามที่ระบุหรือไม่?
• รูปแบบข้อผิดพลาดตรงกับรูปแบบข้อผิดพลาดที่ระบุในเอกสารหรือไม่?

นี่คือจุดที่ การทดสอบสัญญา API เข้ามา การทดสอบสัญญาเป็นการตรวจสอบที่บริสุทธิ์: เป็นการยืนยันว่าผู้ผลิตยังคงรักษาข้อตกลงที่ผู้บริโภคต้องพึ่งพา การยืนยัน API ในเรื่องสถานะ, Schema และเฮดเดอร์ เป็นหน่วยของการทำงานตรวจสอบ

การรับรองความถูกต้องสำหรับ API หมายถึงการตรวจสอบว่า API ตอบสนองความต้องการของผู้บริโภคอย่างแท้จริงหรือไม่:

• ลูกค้าสามารถดำเนินการเวิร์กโฟลว์แบบ End-to-End จริงๆ ได้หรือไม่ เช่น การเข้าสู่ระบบ, การสร้าง, การอัปเดต, การลบ โดยไม่มีปัญหาการทำงานที่ยุ่งยาก?
• ข้อมูลที่ API ส่งกลับมานั้นตอบคำถามที่นักพัฒนาฝั่งไคลเอ็นต์ต้องการหรือไม่?
• โมเดลการตรวจสอบสิทธิ์ใช้งานได้จริงสำหรับการรวมระบบที่มีอยู่หรือไม่?
• ตัวอย่างที่ระบุในเอกสารสะท้อนถึงวิธีการใช้งาน API จริงๆ หรือไม่?

สถานการณ์การทดสอบ API ที่เชื่อมโยงคำขอหลายรายการเข้าเป็นเส้นทางของผู้ใช้ที่สมบูรณ์นั้นใกล้เคียงกับการรับรองความถูกต้องมากกว่า; การตรวจสอบ Schema ของ endpoint เดียวคือการตรวจสอบ ทั้งสองควรอยู่ในชุดการทดสอบ การทำความเข้าใจ สถานการณ์การทดสอบเทียบกับกรณีการทดสอบ ช่วยให้คุณเห็นว่าคุณกำลังทำงานอยู่ในเลเยอร์ใด

Apidog เข้ามามีบทบาทอย่างไร

Apidog รองรับทั้งสองด้านของความแตกต่างนี้ เพราะมันรวมการออกแบบ API, การทดสอบ และเอกสารไว้ในพื้นที่ทำงานเดียวกัน

สำหรับการตรวจสอบ การออกแบบ API *คือ* ข้อกำหนด เมื่อคุณสร้างการทดสอบ คุณยืนยันการตอบสนองกับ Schema เดียวกันที่กำหนด API ดังนั้นการตรวจสอบจึงไม่มีสำเนาของสัญญาอันที่สองที่จะทำให้เกิดความคลาดเคลื่อน การยืนยัน Schema, การยืนยันสถานะ และการตรวจสอบสัญญา ทั้งหมดรันกับแหล่งข้อมูลที่เป็นความจริงเดียว รันสิ่งเหล่านี้ในทุก ๆ commit ผ่าน CI; การทำให้การทดสอบ API เป็นไปโดยอัตโนมัติใน CI/CD ทำให้การตรวจสอบเป็นไปอย่างต่อเนื่อง ซึ่งเป็นเวลาที่ควรจะเกิดขึ้นพอดี

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

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

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

ตัวอย่างในโลกจริง

ลองจินตนาการถึงทีมที่กำลังสร้าง API การชำระเงิน ข้อกำหนดระบุว่า POST /payments ยอมรับจำนวนเงินและสกุลเงิน ส่งคืน 201 พร้อม payment_id และปฏิเสธสกุลเงินที่ไม่ถูกต้องด้วย 400

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

จากนั้นลูกค้าจริงรายแรกก็เข้ามาใช้งาน พวกเขาพบว่า API ยอมรับจำนวนเงินเป็นตัวเลขทศนิยม ดังนั้น 0.1 + 0.2 ปัดเศษเป็นค่าที่ไม่ตรงกับใบแจ้งหนี้ของลูกค้า ข้อกำหนดระบุว่า “amount: number” การนำไปใช้เป็นไปตามนั้นอย่างสมบูรณ์ ข้อกำหนดผิดพลาด; เงินไม่ควรเป็นทศนิยมเลย การตรวจสอบไม่สามารถตรวจพบสิ่งนี้ได้ เพราะการตรวจสอบเพียงแค่ตรวจสอบการนำไปใช้เทียบกับข้อกำหนด และทั้งสองก็เห็นด้วย

การรับรองความถูกต้องต่างหากที่ตรวจพบ เมื่อลูกค้าดำเนินการชำระเงินแบบ End-to-End จริงและกระทบยอดกับใบแจ้งหนี้ ข้อผิดพลาดจากการปัดเศษก็ปรากฏขึ้น การแก้ไขไม่ใช่รายงานข้อบกพร่องของโค้ด; มันคือการเปลี่ยนแปลงข้อกำหนด โดยจำนวนเงินจะเปลี่ยนเป็นหน่วยย่อยจำนวนเต็ม นั่นคือลักษณะเฉพาะของสิ่งที่พบจากการรับรองความถูกต้อง: คำตอบไม่ใช่ "แก้ไขโค้ดให้ตรงกับข้อกำหนด" แต่คือ "ตัวข้อกำหนดเองนั้นผิด"

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

รายการตรวจสอบเชิงปฏิบัติ

สำหรับการเผยแพร่ API ใดๆ ให้ดำเนินการทั้งสองส่วน:

การตรวจสอบ (เทียบกับข้อกำหนด):

• ทุก endpoint ส่งคืนรหัสสถานะที่ระบุในเอกสาร
• ทุกการตอบสนองเป็นไปตาม Schema
• พารามิเตอร์ที่จำเป็นถูกบังคับใช้
• การตอบสนองข้อผิดพลาดตรงกับรูปแบบที่ระบุในเอกสาร
• การทดสอบสัญญาผ่านสำหรับทุก endpoint ที่ลูกค้าใช้งาน

การรับรองความถูกต้อง (เทียบกับวัตถุประสงค์):

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

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

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

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

การทดสอบเหมือนกับการรับรองความถูกต้องหรือไม่? ไม่ การทดสอบครอบคลุมทั้งสองอย่าง การทดสอบหน่วยและการตรวจสอบ Schema คือการตรวจสอบ; การทดสอบการยอมรับและ End-to-End คือการรับรองความถูกต้อง คำว่า "การทดสอบ" ครอบคลุมทั้งหมด

ซอฟต์แวร์สามารถผ่านการตรวจสอบแต่ล้มเหลวในการรับรองความถูกต้องได้หรือไม่? ได้ และเป็นเรื่องปกติ การนำไปใช้นั้นตรงตามข้อกำหนดอย่างสมบูรณ์แบบ แต่ข้อกำหนดนั้นแก้ปัญหาผิดจุด ผลิตภัณฑ์นั้นผ่านการตรวจสอบแต่ไม่ผ่านการรับรองความถูกต้อง

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

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

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