กำไร:
- ความสามารถในการดำเนินการทดสอบ API ในเชิงลึกด้วยการสนับสนุนปัญญาประดิษฐ์ที่รหัสสถานะ สคีมา/สัญญา กฎเกณฑ์ทางธุรกิจ และเลเยอร์เชิงลบ/การอนุญาต
- ความสามารถในการสร้างสคีมา JSON จากการตอบสนองตัวอย่าง และหลีกเลี่ยงความมั่นใจหลอกในการดูเฉพาะรหัสสถานะที่มีประเภทและการตรวจสอบความถูกต้องที่จำเป็น
- ความสามารถในการทดสอบสถานการณ์ด้านความปลอดภัย เช่น การอนุญาตและ IDOR ด้วยข้อมูลสังเคราะห์ และเพื่อวัตถุประสงค์ในการป้องกันภายในการอนุญาตเท่านั้น
ซอฟต์แวร์สมัยใหม่ส่วนใหญ่พูดคุยกันในเบื้องหลังผ่าน API (Application Programming Interface - อินเทอร์เฟซที่ซอฟต์แวร์สองชิ้นพูดคุยกันตามสัญญาเฉพาะ) เมื่อแอปบนมือถือเพิ่มสินค้าลงในรถเข็น แอปจะส่งคำขอไปยัง API บนเซิร์ฟเวอร์จริงๆ การทดสอบ API จะตรวจสอบว่าการสนทนานี้ถูกต้อง ปลอดภัย และสอดคล้องกัน โดยไม่คำนึงถึงอินเทอร์เฟซ เร็วกว่า เสถียรกว่า และลึกกว่าการทดสอบ UI ปัญญาประดิษฐ์ (AI) มีประสิทธิภาพมากในการทดสอบ API โดยสร้างการทดสอบจากคำจำกัดความของ API แยกสคีมาการตอบสนอง (สัญญาที่กำหนดโครงสร้างของข้อมูล) แสดงรายการกรณี Edge แต่มีข้อแม้สำคัญอีกครั้ง: AI ไม่ทราบกฎเกณฑ์ทางธุรกิจที่แท้จริงของ API ของคุณ มีแนวโน้มที่จะสร้างการทดสอบผิวเผินที่ยืนยันว่า "ส่งคืนได้ 200 รายการ" เท่านั้น งานของคุณคือทำให้แน่ใจว่าการทดสอบจะยืนยันสัญญาจริงและตรรกะทางธุรกิจ
ในหน่วยนี้ คุณจะได้เรียนรู้วิธีตั้งค่าการทดสอบ API เชิงลึกที่รองรับ AI ด้วยแนวทางต่างๆ เช่น บุรุษไปรษณีย์, REST Assured และการตรวจสอบความถูกต้องของสคีมา
เลเยอร์ของการทดสอบ API
พิจารณาการทดสอบ API ในหลายระดับ โดยที่ AI ช่วยเหลือแตกต่างกันในแต่ละเลเยอร์:
1. รหัสสถานะและการตอบสนองขั้นพื้นฐาน คำขอส่งคืนรหัสสถานะ HTTP ที่คาดหวัง (200/201 สำหรับความสำเร็จ, 400/401/404 สำหรับข้อผิดพลาด) หรือไม่ นี่คือชั้นผิวเผินที่สุด AI สร้างได้ง่ายแต่เพียงอย่างเดียวก็ให้ความไว้วางใจที่ผิดพลาด
2. การตรวจสอบสคีมา/สัญญา โครงสร้างของการตอบสนองสอดคล้องกับสัญญาหรือไม่ - มีฟิลด์ที่คาดหวังอยู่, ประเภทถูกต้องหรือไม่, ฟิลด์ที่จำเป็นหายไปหรือไม่? AI สามารถสร้าง JSON Schema ซึ่งเป็นมาตรฐานที่กำหนดโครงสร้างของเอกสาร JSON จากการตอบกลับตัวอย่าง และการทดสอบสามารถตรวจสอบกับสคีมานั้นได้ สิ่งนี้มีประสิทธิภาพมากกว่าการเขียนการยืนยันตามฟิลด์ด้วยตนเอง
3. การตรวจสอบกฎเกณฑ์ทางธุรกิจ มูลค่าที่แท้จริงอยู่ที่นี่: "สำหรับคำสั่งซื้อ 1,000 TL ช่องส่วนลดควรเป็น 100" "คำสั่งซื้อที่ยกเลิกไม่สามารถยกเลิกได้อีก" AI จะตรวจสอบสิ่งเหล่านี้หากคุณให้กฎเท่านั้น ถ้าไม่ให้ก็จะโดด
4. เชิงลบและความปลอดภัย 401 สำหรับโทเค็นที่ไม่ถูกต้อง, 403 สำหรับการเข้าถึงข้อมูลของผู้อื่น, ล้าง 400 สำหรับเนื้อหาที่ไม่ดี การทดสอบการอนุญาต (การตรวจสอบว่าผู้ใช้สามารถเข้าถึงข้อมูลของตนเองได้เท่านั้น) เป็นหัวใจสำคัญของการรักษาความปลอดภัยของ API และทำเพื่อวัตถุประสงค์ในการป้องกัน
เคล็ดลับ: อย่าขอการทดสอบโดยไม่แจ้งให้ AI "ตรวจสอบไม่ใช่แค่รหัสสถานะ แต่ยังรวมถึงสคีมาการตอบสนองและกฎเกณฑ์ทางธุรกิจเหล่านั้นด้วย" มิฉะนั้น คุณจะเหลือการทดสอบที่ระบุว่า "ส่งคืนแล้ว 200 ครั้ง" แต่อย่าสังเกตเห็นว่า API ส่งคืนข้อมูลที่เสียหาย
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
จุดอ่อน: "เขียนการทดสอบสำหรับ API นี้"
แข็งแกร่ง: "การทดสอบการเขียน REST Assured (Java) สำหรับจุดสิ้นสุด POST /คำสั่งซื้อ ข้อตกลง: productId และปริมาณมีผลบังคับใช้ในส่วนเนื้อหา; 201 และ {orderId, ผลรวม, ส่วนลด, สถานะ} จะถูกส่งคืนเมื่อสำเร็จ กฎเกณฑ์ทางธุรกิจ: ส่วนลด 10% มากกว่า 1,000 TL; 400 หากปริมาณ<=0; 401 หากโทเค็นไม่ถูกต้อง; 403 เมื่อเห็นคำสั่งซื้อของผู้ใช้รายอื่น การทดสอบ: (1) รหัสสถานะ (2) การตรวจสอบความถูกต้องของสคีมา JSON (3) กฎธุรกิจส่วนลด (4) ผูกทุกการยืนยันกับกฎทางธุรกิจที่ชัดเจน ไม่ใช่แค่ตรวจสอบ 200/201”
พร้อมท์ที่มีประสิทธิภาพช่วยให้สัญญา กฎเกณฑ์ทางธุรกิจ สถานการณ์ด้านความปลอดภัย และความคาดหวังในการตรวจสอบสคีมา
การทดสอบสัญญา: ป้องกันการเลิกราระหว่างทีม
ในสถาปัตยกรรมไมโครเซอร์วิส (โครงสร้างที่แอปพลิเคชันแบ่งออกเป็นบริการขนาดเล็กที่ไม่เป็นอิสระจากกันและพูดคุยกับ API) การเปลี่ยนรูปแบบการตอบสนองของบริการจะรบกวนบริการอื่น ๆ ที่เชื่อมต่ออยู่โดยไม่แจ้งให้ทราบ การทดสอบสัญญา - การทดสอบที่ตรวจสอบว่าสัญญา API ระหว่างบริการของผู้ให้บริการและบริการผู้บริโภคนั้นไม่ได้เสียหายทั้งสองด้าน - ตรวจพบการหยุดดังกล่าวก่อนกำหนด แนวคิดก็คือ: ผู้บริโภคกำหนดรูปแบบการตอบสนองที่เขาคาดหวังจากผู้ผลิตว่าเป็น "สัญญา" ในการเปลี่ยนแปลงแต่ละครั้ง ผู้ผลิตจะทดสอบว่ายังคงเป็นไปตามข้อตกลงนี้ ดังนั้นเมื่อชื่อหรือประเภทของฟิลด์เปลี่ยนแปลง ผู้ใช้จะแจ้งไปป์ไลน์ก่อนที่จะล่ม
AI เร่งงานสองอย่างในบริบทนี้: การร่างสัญญาที่สะท้อนถึงความคาดหวังของผู้บริโภคจากการตอบสนองของ API ที่มีอยู่ และการทำเครื่องหมายล่วงหน้าว่าการเปลี่ยนแปลงข้อสัญญาใดที่อาจฝ่าฝืนได้ แต่ตัวสัญญาเองก็เป็นการตัดสินใจทางธุรกิจ: ผู้เชี่ยวชาญจะเป็นผู้กำหนดว่าด้านใดที่มีความสำคัญอย่างแท้จริง ซึ่งการเปลี่ยนแปลงใดที่จะทำลายความเข้ากันได้แบบย้อนหลัง — ผู้บริโภคเก่ายังคงทำงานต่อไป AI เขียนสัญญา คุณคือผู้อนุมัติมัน
เคล็ดลับ: การลบฟิลด์หรือการเปลี่ยนแปลงประเภทฟิลด์ใน API มักจะถือเป็นการเปลี่ยนแปลงที่ไม่สมบูรณ์เสมอไป การเพิ่มฟิลด์ใหม่มักจะปลอดภัย การให้ AI แยกประเภทการเปลี่ยนแปลงเป็น “เสียหายหรือปลอดภัย” ช่วยให้ตรวจสอบความปลอดภัยก่อนเผยแพร่ได้อย่างรวดเร็ว
บุรุษไปรษณีย์หรือตามรหัส?
เกณฑ์
บุรุษไปรษณีย์/นิวแมน
มั่นใจส่วนที่เหลือ / รหัส (Java, C #, JS)
การเรียนรู้
ง่ายมองเห็นได้
ความรู้ด้านรหัสที่จำเป็น
การควบคุมเวอร์ชัน
คอลเลกชัน JSON
โดยตรงในซอร์สโค้ด
ตรรกะที่ซับซ้อน
จำกัด (สคริปต์ JS)
พลังการเขียนโปรแกรมเต็มรูปแบบ
การรวม CI/ซีดี
กับนิวแมน
ขึ้นอยู่กับการสร้างโดยตรง
การตรวจสอบสคีมา
พร้อมสคริปต์ทดสอบ
ทรงพลังด้วยห้องสมุด
ขนาดทีม
เล็ก/กลาง
ใหญ่โต
AI สร้างโค้ดสำหรับทั้งสองอย่าง ชัดเจนว่าคุณต้องการอันไหน
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) การทดสอบ API ตามสัญญา:
บทบาทของคุณ: วิศวกรทดสอบ API อาวุโส เขียนการทดสอบสำหรับตำแหน่งข้อมูลต่อไปนี้ด้วย [เครื่องมือ/ภาษา]: [วิธีการ + เส้นทาง] สัญญา: [ฟิลด์ที่ต้องระบุ รหัสความสำเร็จ โครงสร้างการตอบสนอง] กฎเกณฑ์ทางธุรกิจ: [กฎ] ชั้นการทดสอบ: (1) รหัสสถานะ (2) การตรวจสอบสคีมาการตอบสนอง (3) กฎธุรกิจแต่ละกฎ (4) ค่าลบ + การอนุญาต เชื่อมโยงแต่ละรายการยืนยันกับส่วนคำสั่งกฎ/สัญญาที่เกี่ยวข้อง
2) การสร้างสคีมาจากการตอบสนองตัวอย่าง:
สร้าง JSON Schema จากการตอบสนอง API ตัวอย่างด้านล่าง ระบุฟิลด์ที่ต้องกรอก ประเภท ข้อจำกัดด้านรูปแบบ (วันที่ อีเมล ช่วงหมายเลข) จากนั้นให้ยกตัวอย่างการทดสอบที่ตรวจสอบกับสคีมานี้ ตัวอย่างการตอบสนอง: [วาง JSON]
3) สถานการณ์เชิงลบและการอนุญาต:
สร้างกรณีทดสอบเชิงลบและความปลอดภัยสำหรับปลายทาง [ปลายทาง] รวมถึง: ฟิลด์ที่ขาดหายไป/จำเป็น, ประเภทผิด, ค่ามากเกินไป, โทเค็นไม่ถูกต้อง/หมดอายุ, การเข้าถึงทรัพยากรที่ไม่ได้รับอนุญาต (IDOR - การเข้าถึงบันทึกของบุคคลอื่นโดยการเปลี่ยน ID), ขีดจำกัดอัตรา ระบุรหัสสถานะที่คาดไว้และเนื้อหาข้อผิดพลาดสำหรับแต่ละสถานการณ์ หมายเหตุ: จะถูกทดสอบบน API ของฉันเองเท่านั้นที่ได้รับอนุญาต
4) การควบคุมความเชื่อถือหลอก:
ลองดูการทดสอบ API นี้ การทดสอบนี้จะตรวจจับได้หรือไม่หากเซิร์ฟเวอร์ส่งคืนรหัสสถานะที่ถูกต้อง แต่เป็น FALSEbody/data ถ้าไม่ ให้เพิ่มการตรวจสอบสคีมาและกฎธุรกิจ ทดสอบ: [ทดสอบการวาง]
มินิเคสสามอัน
กรณีที่ 1 — พลังของการตรวจสอบความถูกต้องของสคีมา ทีมงานตรวจสอบรหัสสถานะในการทดสอบที่สร้างขึ้นด้วย AI เท่านั้น ในเวอร์ชันหนึ่ง API เริ่มส่งคืนฟิลด์รวมเป็นข้อความอย่างผิดพลาด ("1200"); การทดสอบยังคงเป็นสีเขียวเพราะยังคงส่งคืน 200 แอปพลิเคชันมือถือขัดข้อง หลังจากเพิ่มการตรวจสอบประเภทด้วยเทมเพลต "การสร้างสคีมาจากการตอบสนองตัวอย่าง" ก็พบข้อผิดพลาดเดียวกันนี้ทันที
กรณีที่ 2 — ช่องว่างอำนาจ (IDOR) ผู้เชี่ยวชาญทำการทดสอบ IDOR ระหว่าง "สถานการณ์เชิงลบและการอนุญาต" ที่สร้างโดย AI: เขาขอ ID คำสั่งซื้อของผู้ใช้ B ด้วยโทเค็นของผู้ใช้ A API ส่งคืนข้อมูล 200 และ B ซึ่งเป็นช่องโหว่ในการอนุญาตที่ร้ายแรง การทดสอบการป้องกันนี้ช่วยปิดการรั่วไหลของข้อมูลก่อนที่จะเผยแพร่
กรณีที่ 3 — การเลี่ยงกฎเกณฑ์ทางธุรกิจ AI สร้างการทดสอบ 8 รายการสำหรับจุดสิ้นสุดส่วนลด ทั้งหมดตรวจสอบ 200 ไม่มีการตรวจสอบจำนวนส่วนลด ผู้เชี่ยวชาญได้เพิ่มกฎเกณฑ์ทางธุรกิจลงในข้อความแจ้งและทำซ้ำ การทดสอบใหม่พบว่าส่วนลดคำนวณไม่ถูกต้องที่ขีดจำกัด 1,000 TL (ส่วนลดก็ใช้กับ 999 ด้วย) การควบคุมสัญญาไม่เพียงพอ การควบคุมกฎเกณฑ์ทางธุรกิจเป็นสิ่งจำเป็น
ข้อผิดพลาดทั่วไป
- แค่ดูรหัสสถานะ พูดว่า "200 กลับมาแล้วผ่านไป"; ไม่เห็นกายที่เสื่อมทราม (เชื่อเท็จ)
- ข้ามการตรวจสอบสคีมา ไม่ตรวจสอบประเภทสนามและภาระผูกพัน การเปลี่ยนแปลงประเภทผ่านไปอย่างเงียบๆ
- การร้องขอการทดสอบโดยไม่ต้องระบุกฎเกณฑ์ทางธุรกิจ AI ไม่รู้กฎเกณฑ์ มันสร้างการควบคุมทางเทคนิคเท่านั้น
- ลืมสถานการณ์เชิงลบและการได้รับสิทธิ์ ช่องโหว่ด้านความปลอดภัย (IDOR, การเข้าถึงโดยไม่ได้รับอนุญาต) จะถูกตรวจพบโดยการทดสอบเหล่านี้เท่านั้น
- การใช้โทเค็นและข้อมูลจริง/ที่ใช้งานจริง ใช้สื่อเฉพาะและข้อมูลสังเคราะห์สำหรับการทดสอบ อย่าติดกุญแจจริงเข้าไปในรถ
- การทดสอบความปลอดภัยโดยไม่ได้รับอนุญาต เรียกใช้การทดสอบการอนุญาตบน API ของคุณเองและได้รับอนุญาตเท่านั้น
โดยสรุป
การทดสอบ API จะตรวจสอบคำพูดของซอฟต์แวร์อย่างรวดเร็วและเชิงลึก โดยไม่คำนึงถึงอินเทอร์เฟซ AI; การทดสอบสัญญามีประสิทธิภาพมากในการสร้างสคีมา JSON และสถานการณ์เชิงลบ/ความปลอดภัยจากการตอบสนองตัวอย่าง แต่การทดสอบผิวเผินที่ตรวจสอบเฉพาะรหัสสถานะเท่านั้นที่ให้ความมั่นใจแบบหลอกๆ ต้องมีทั้งสี่เลเยอร์: รหัสสถานะ การตรวจสอบสคีมา กฎเกณฑ์ทางธุรกิจ ค่าลบ และการอนุญาต วางกฎเกณฑ์ทางธุรกิจและสัญญาทันที ทำการทดสอบความปลอดภัยด้วยข้อมูลสังเคราะห์และได้รับอนุญาตเท่านั้น
งานสมัคร
เลือกตำแหน่งข้อมูล API จากโครงการของคุณเอง ให้ AI เขียนการทดสอบสี่ชั้นด้วยเทมเพลต “การทดสอบ API ตามสัญญา” จากนั้นเพิ่มการตรวจสอบประเภท/การบังคับใช้ด้วย "การสร้างสคีมาจากการตอบสนองตัวอย่าง" และใช้ "การตรวจสอบความน่าเชื่อถือแบบหลอก" เรียกใช้สถานการณ์จำลอง IDOR/การอนุญาตอย่างน้อยหนึ่งรายการในสภาพแวดล้อมการทดสอบของคุณเอง รายงานการละเมิดสัญญาหรือกฎเกณฑ์ทางธุรกิจที่คุณพบ หากคุณไม่พบสิ่งใดเลย ให้ทำการทดสอบกับคำตอบที่อ่านไม่ออกโดยเจตนาเพื่อพิสูจน์ว่าจับได้
รายการตรวจสอบ
- [ ] ฉันครอบคลุมการทดสอบสี่ชั้น (กรณี สคีมา กฎเกณฑ์ทางธุรกิจ เชิงลบ/การอนุญาต)
- [ ] ฉันให้สัญญาและกฎเกณฑ์ทางธุรกิจแก่ AI อย่างชัดเจน
- [ ] ฉันตั้งค่าการทดสอบเพื่อตรวจสอบความถูกต้องของสคีมาการตอบสนอง (ฟิลด์ ประเภท ความจำเป็น)
- [ ] ฉันได้ลองใช้สถานการณ์การอนุญาต/IDOR อย่างน้อยหนึ่งครั้งในเชิงป้องกัน
- [ ] ฉันใช้สภาพแวดล้อมการทดสอบและข้อมูลสังเคราะห์แทนโทเค็น/ข้อมูลจริง
- [ ] ฉันพิสูจน์ด้วย "การตรวจสอบความมั่นใจหลอก" ว่าทุกการทดสอบจับการตอบสนองที่เสียหายได้