กลยุทธ์การทดสอบ API: คู่มือปฏิบัติสำหรับ API ที่เชื่อถือได้

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

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

ปุ่ม

กลยุทธ์การทดสอบ API หมายถึงอะไรกันแน่

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

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

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

มันทำงานเมื่อใด? การตรวจสอบที่รวดเร็วจะทำงานทุกครั้งที่มีการพุช การตรวจสอบที่ช้าจะทำงานตามกำหนดเวลาหรือก่อนการเผยแพร่ การผสมผสานทั้งสองอย่างหมายความว่าฟีดแบ็กของคุณจะช้าหรือไม่ก็การครอบคลุมของคุณจะบาง

อะไรนับว่าผ่าน? การทดสอบที่ตรวจสอบแค่การตอบสนอง 200 บอกคุณได้แทบไม่มีอะไรเลย กำหนดรหัสสถานะ, สคีมา, ค่าฟิลด์ และเวลาตอบสนองที่คุณคาดหวัง

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

ทำไมกลยุทธ์จึงดีกว่าการทดสอบแบบเฉพาะหน้า

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

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

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

มันไม่สามารถปรับขนาดได้ บริการที่มี 40 เอนด์พอยต์และ 5 สภาพแวดล้อมหมายถึงการตรวจสอบด้วยตนเอง 200 ครั้งต่อการเผยแพร่ ไม่มีใครทำแบบนั้นด้วยมือ ดังนั้นการครอบคลุมจึงลดลงเมื่อ API เติบโตขึ้น กลยุทธ์คือการแลกต้นทุนการตั้งค่าครั้งเดียวกับการครอบคลุมที่สามารถทำซ้ำได้: คุณเขียนการทดสอบเพียงครั้งเดียว และมันจะทำงานทุกครั้งที่มีการเปลี่ยนแปลงโดยที่คุณไม่ต้องทำอะไรเลย

พีระมิดการทดสอบ API

พีระมิดการทดสอบเป็นกฎทั่วไปสำหรับการเขียนการทดสอบในแต่ละเลเยอร์ ฐานกว้าง ยอดยอดเรียว

        /\
       /  \      การทดสอบแบบ End-to-end / โฟลว์การทำงาน  (น้อย, ช้า, มีมูลค่าสูง)
      /----\
     /      \    การทดสอบการผนวกรวม / สัญญา  (บางส่วน, ความเร็วปานกลาง)
    /--------\
   /          \  การทดสอบหน่วย / การเรียกครั้งเดียว   (มาก, เร็ว, ราคาถูก)
  /____________\

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

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

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

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

ประเภทของการทดสอบและช่วงเวลาที่ใช้แต่ละประเภท

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

การทดสอบการทำงาน (Functional Testing)

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

การตรวจสอบการทำงานสำหรับเอนด์พอยต์ผู้ใช้มีลักษณะดังนี้:

GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>

การยืนยัน:

สถานะคือ 200
เนื้อหาตรงกับสคีมา User
id เท่ากับ 42
email เป็นสตริงอีเมลที่ถูกต้อง

การทดสอบการผนวกรวม (Integration Testing)

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

การทดสอบการถดถอย (Regression Testing)

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

การทดสอบสัญญา (Contract Testing)

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

การทดสอบโหลดและประสิทธิภาพ (Load and Performance Testing)

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

การทดสอบความปลอดภัย (Security Testing)

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

นี่คือแนวทางคร่าวๆ ว่าแต่ละประเภททำงานเมื่อใด:

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

กรณีบวก, ลบ, และกรณีขอบเขต

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

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

กรณีลบ (Negative cases) คือการส่งอินพุตที่ไม่ถูกต้องและคาดว่าจะเกิดความล้มเหลวที่สะอาดและถูกต้อง ฟิลด์ที่จำเป็นขาดหายไปควรกคืนค่า 400 ไม่ใช่ 500 คำขอที่ไม่มีโทเค็นควรกคืนค่า 401 คำขอสำหรับเรคคอร์ดที่คุณไม่ได้เป็นเจ้าของควรกคืนค่า 403 หรือ 404 ไม่ใช่เรคคอร์ดนั้นเลย การทดสอบเชิงลบจะตรวจสอบการจัดการข้อผิดพลาดของคุณ ซึ่งเป็นจุดที่ API มักจะรั่วไหลหรือล่มบ่อยที่สุด

กรณีขอบเขต (Edge cases) คือการผลักดันขอบเขตของอินพุตที่ถูกต้อง: รายการว่างเปล่า, ความยาวสตริงสูงสุดที่อนุญาต, ศูนย์, จำนวนลบ, ชื่อ Unicode, การประทับเวลาที่ขอบเขตการเปลี่ยนเวลาออมแสง สิ่งเหล่านี้จะค้นหาข้อผิดพลาด "ขาดไปหนึ่ง" หรือ "เกินความจุ" (off-by-one and overflow bugs)

กฎที่สำคัญ: สำหรับการทดสอบเชิงบวกทุกครั้ง ให้เขียนการทดสอบเชิงลบอย่างน้อยหนึ่งครั้ง หากเอนด์พอยต์สร้างคำสั่งซื้อของคุณมีการทดสอบ "happy-path" เพียงหนึ่งครั้ง และไม่มีการทดสอบสำหรับปริมาณติดลบหรือรหัสลูกค้าที่หายไป การครอบคลุมของคุณจะบางกว่าที่คิด

POST /api/orders HTTP/1.1
Content-Type: application/json

{ "customerId": "c_123", "quantity": -5 }

คาดหวัง: สถานะ 400, เนื้อหาประกอบด้วยข้อผิดพลาดการตรวจสอบที่ชัดเจนระบุ quantity หากคืนค่า 201 หรือ 500 แสดงว่าคุณพบข้อผิดพลาดที่การทดสอบ "happy-path" จะไม่มีวันจับได้

ข้อมูลทดสอบและสภาพแวดล้อม

การทดสอบจะน่าเชื่อถือได้เพียงใดขึ้นอยู่กับข้อมูลและสภาพแวดล้อมที่ใช้ในการทดสอบ

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

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

แยกสภาพแวดล้อม แยกสภาพแวดล้อมสำหรับการพัฒนาในเครื่อง, CI, staging, และ production จัดเก็บ URL พื้นฐาน, โทเค็น, และการตั้งค่าอื่นๆ ต่อสภาพแวดล้อม เพื่อให้การทดสอบเดียวกันสามารถทำงานได้ทุกที่โดยการเปลี่ยนตัวแปรเดียว การทำความเข้าใจความแตกต่างระหว่าง sandbox และสภาพแวดล้อมการทดสอบแบบเต็มรูปแบบจะช่วยให้คุณเลือกเป้าหมายที่ถูกต้อง; ดู sandbox เทียบกับสภาพแวดล้อมการทดสอบ

กำหนดพารามิเตอร์ด้วยตัวแปร อย่าฮาร์ดโค้ดโฮสต์หรือความลับในการทดสอบ อ้างอิงตัวแปรสภาพแวดล้อมเพื่อให้สถานการณ์เดียวกันสามารถทำงานได้กับสภาพแวดล้อมในเครื่อง, staging, และ CI โดยไม่ต้องแก้ไข

Shift Left: ทดสอบให้เร็วขึ้น ไม่ใช่แค่มากขึ้น

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

สามการกระทำที่สามารถย้ายการทดสอบของคุณไปด้านซ้ายได้จริง:

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

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

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

กรณีศึกษาฉบับเต็มอยู่ใน การทดสอบแบบ shift-left ในการพัฒนา API ผลลัพธ์ที่ได้นั้นง่าย: ข้อผิดพลาดมีค่าใช้จ่ายน้อยลงเมื่อคุณพบมันเร็วขึ้น

การทำระบบทดสอบอัตโนมัติใน CI

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

CI pipeline ทั่วไปสำหรับการทดสอบ API มีสามขั้นตอน:

ทุกครั้งที่มีการพุช: เรียกใช้การทดสอบการทำงานและการทดสอบสัญญาที่รวดเร็ว ทำให้ build ล้มเหลวหากมีการยืนยันใดๆ ผิดพลาด นี่คือประตูการป้องกันของคุณ
ทุกคืนหรือก่อนเผยแพร่: เรียกใช้ชุดการทดสอบการผนวกรวมและ end-to-end ที่ช้ากว่า รวมถึงการตรวจสอบโหลดและความปลอดภัย
เสมอ: เผยแพร่รายงานที่เครื่องอ่านได้ (JUnit XML เป็นรูปแบบทั่วไป) เพื่อให้แดชบอร์ด CI ของคุณแสดงจำนวนการผ่านและล้มเหลว

GitHub Actions job ขั้นต่ำที่เรียกใช้ชุดการทดสอบ API ทุกครั้งที่มีการพุชมีลักษณะดังนี้:

name: api-tests
on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Run API tests
        run: npm test

คำสั่งที่แน่นอนขึ้นอยู่กับเครื่องมือของคุณ รูปแบบเดียวกันทุกที่: checkout โค้ด, ตั้งค่า runtime, เรียกใช้ชุดการทดสอบ, และปล่อยให้โค้ดจบการทำงานที่ไม่เป็นศูนย์ทำให้ build ล้มเหลว สำหรับการจัดการ CI เต็มรูปแบบ รวมถึง caching, environment secrets, และ reporting ดู วิธีทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD

Apidog เข้ากับกลยุทธ์ได้อย่างไร

กลยุทธ์ข้างต้นเป็นแบบไม่ขึ้นกับเครื่องมือ คุณสามารถรวบรวมได้จากเครื่องมือแยกต่างหากสำหรับการออกแบบ, การทดสอบ, การจำลอง, และเอกสารประกอบ ค่าใช้จ่ายคือความคลาดเคลื่อน: ข้อกำหนด, การทดสอบ, และ mock ไม่ตรงกัน และคุณต้องใช้เวลาในการปรับให้เข้ากัน

Apidog รวมสิ่งเหล่านั้นไว้ในที่เดียว คุณออกแบบสัญญา API, เขียนสถานการณ์การทดสอบกับมัน, สร้าง mock จากสคีมาเดียวกัน, และเผยแพร่เอกสารประกอบ ทั้งหมดนี้มาจากแหล่งข้อมูลเดียว เนื่องจาก tests และ mock มาจากสัญญาเดียวกัน การทดสอบสัญญาและการทดสอบแบบ shift-left จึงไม่ใช่ภาระงานเพิ่มเติม: มันเป็นค่าเริ่มต้น

สำหรับครึ่งหนึ่งของกลยุทธ์ในส่วน CI, Apidog CLI จะเรียกใช้สถานการณ์และชุดการทดสอบที่คุณบันทึกไว้แบบ Headless มันเป็นแพ็คเกจ Node ดังนั้นจึงสามารถใส่ลงในขั้นตอน CI ที่สามารถเรียกใช้ Node ได้

ติดตั้ง:

npm install -g apidog-cli

เรียกใช้สถานการณ์หรือชุดการทดสอบที่บันทึกไว้ใน CI คำสั่ง run เป็นแบบใช้แฟล็ก; คุณส่ง target id, environment id, และ reporters ที่คุณต้องการ:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <scenarioOrSuiteId> \
  -e <environmentId> \
  -r cli,html,junit

--access-token ใช้สำหรับการยืนยันตัวตนการรัน จัดเก็บโทเค็นเป็น CI secret และอ้างอิงเป็นตัวแปรสภาพแวดล้อม
-t คือ id ของสถานการณ์, โฟลเดอร์, หรือชุดการทดสอบที่คุณต้องการรัน
-e คือ environment id เพื่อให้ชุดการทดสอบเดียวกันรันกับ staging หรือ CI โดยการสลับค่านี้
-r เลือก reporters หนึ่งรายการหรือมากกว่าจาก cli, html, json, และ junit เอาต์พุต junit จะส่งไปยังแดชบอร์ด CI ของคุณ; html ให้รายงานที่มนุษย์อ่านได้

สำหรับการรันที่ขับเคลื่อนด้วยข้อมูล ให้ชี้ CLI ไปที่ไฟล์ข้อมูลหรือ id ข้อมูลทดสอบที่บันทึกไว้:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <scenarioId> \
  -e <environmentId> \
  -d ./data/users.csv \
  -r cli,junit

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

รายการตรวจสอบกลยุทธ์เริ่มต้น

หากคุณกำลังสร้างกลยุทธ์ตั้งแต่เริ่มต้น ให้ทำตามรายการนี้ตามลำดับ

[ ] จัดอันดับเอนด์พอยต์ของคุณตามความเสี่ยงและการรับส่งข้อมูล ครอบคลุมรายการที่อยู่บนสุดก่อน
[ ] เขียนการทดสอบการทำงานเชิงบวกสำหรับเอนด์พอยต์ที่จัดอันดับแต่ละรายการ
[ ] เพิ่มการทดสอบเชิงลบอย่างน้อยหนึ่งครั้งต่อเอนด์พอยต์ (การอนุญาตขาดหายไป, อินพุตไม่ถูกต้อง)
[ ] เพิ่มการทดสอบกรณีขอบเขตสำหรับเอนด์พอยต์ที่รับรายการ, ตัวเลข, หรือข้อความอิสระ
[ ] เพิ่มการทดสอบสัญญาสำหรับ API ใดๆ ที่ทีมหรือลูกค้าอื่นใช้
[ ] เพิ่มการทดสอบการผนวกรวมสำหรับโฟลว์ที่ข้ามบริการสองรายการขึ้นไป
[ ] ตั้งค่าสภาพแวดล้อมแยกต่างหากพร้อมตัวแปรและ secret แยกต่อสภาพแวดล้อม
[ ] ใช้ข้อมูลทดสอบที่สร้างขึ้นหรือตั้งค่าเริ่มต้น; รักษาการทดสอบให้เป็นอิสระ
[ ] เรียกใช้การทดสอบที่รวดเร็วทุกครั้งที่พุชใน CI; ทำให้ build ล้มเหลวหากเกิดความล้มเหลว
[ ] กำหนดเวลาชุดการทดสอบที่ช้า (การผนวกรวม, โหลด, ความปลอดภัย) ทุกคืนหรือก่อนเผยแพร่
[ ] เผยแพร่รายงาน JUnit เพื่อให้มองเห็นจำนวนการผ่านและล้มเหลว
[ ] ตรวจสอบชุดการทดสอบเมื่อ API เปลี่ยนแปลง; ลบการทดสอบสำหรับเอนด์พอยต์ที่ถูกลบ

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

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

ความแตกต่างระหว่างกลยุทธ์การทดสอบ API และแผนการทดสอบคืออะไร?

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

ควรมีจำนวนการทดสอบเท่าใดในแต่ละเลเยอร์ของพีระมิด?

ไม่มีอัตราส่วนที่ตายตัว แต่รูปทรงสำคัญกว่าจำนวน การทดสอบส่วนใหญ่ควรเป็นการตรวจสอบการเรียกครั้งเดียวที่รวดเร็วที่ด้านล่าง, มีการทดสอบการผนวกรวมและสัญญาที่น้อยลงตรงกลาง, และมีการทดสอบโฟลว์การทำงานแบบ end-to-end เพียงไม่กี่รายการที่ด้านบน หากการทดสอบเลเยอร์บนสุดที่ช้าของคุณมีจำนวนมากกว่าการทดสอบเลเยอร์ล่างสุดที่รวดเร็ว ให้ปรับสมดุลใหม่

ฉันจำเป็นต้องมีการทดสอบสัญญาหรือไม่ หากฉันมีการทดสอบการทำงานอยู่แล้ว?

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

ฉันควรรันการทดสอบโหลดบ่อยแค่ไหน?

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

ฉันสามารถทำกลยุทธ์ทั้งหมดให้เป็นอัตโนมัติใน CI ได้หรือไม่?

ส่วนที่ทำซ้ำได้, ใช่ การทดสอบการทำงาน, การผนวกรวม, สัญญา, และการถดถอยสามารถทำงานได้อย่างราบรื่นใน pipeline และป้องกันการรวมโค้ดของคุณ การทดสอบโหลดและความปลอดภัยมักจะทำงานตามกำหนดเวลาของตนเองเนื่องจากช้ากว่าหรือต้องการโครงสร้างพื้นฐานเฉพาะ ตัวรันการทดสอบแบบ Headless เช่น Apidog CLI จะครอบคลุมครึ่งหนึ่งของ CI โดยการเรียกใช้สถานการณ์ที่คุณบันทึกไว้ทุกครั้งที่มีการพุช