ต้นแบบแอปจอง Lovable: เคสทดสอบจำนวนที่นั่ง

กำหนดข้อมูลก่อนออกแบบหน้าจอ

แต่ละรอบกิจกรรมควรมี session ID คงที่ จำนวนรับ จำนวนที่ยืนยันแล้ว และสถานะ ส่วนคำขอจองควรมี request ID ไม่ซ้ำ ผู้จอง รอบกิจกรรม สถานะ และเวลาสร้าง สถานะที่ใช้ได้ เช่น รอตรวจ ยืนยัน ยกเลิก และปฏิเสธ ต้องตกลงก่อนว่าสถานะใดกินจำนวนที่นั่ง

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

ใช้ prompt ที่กำหนดขอบเขตชัด

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

Prompt บอกพฤติกรรมที่ต้องการ แต่ไม่ใช่คำรับรองระดับฐานข้อมูล ก่อนใช้จริงต้องให้ผู้พัฒนาที่มีความรู้ตรวจ schema กฎการเข้าถึง และ operation ฝั่งเซิร์ฟเวอร์ เอกสาร Supabase ของ Lovable อธิบายทางเชื่อมปัจจุบัน ส่วนการตั้งค่าที่ถูกต้องยังเป็นหน้าที่ของผู้สร้าง

ไปที่เว็บไซต์ Lovable ↗

ทดสอบจำนวนที่นั่งหกกรณี

1. เริ่มจากไม่มีรายการยืนยัน ส่งคำขอหนึ่งครั้ง แล้วตรวจว่าจำนวนยืนยันเพิ่มเป็นหนึ่ง
2. ส่ง request ID เดิมสองครั้ง ครั้งที่สองต้องคืนผลเดิมโดยไม่เพิ่มจำนวน
3. เริ่มจากยืนยันแล้วห้าคน ส่งคำขอที่นั่งสุดท้ายสองรายการให้ใกล้กันที่สุด ต้องยืนยันได้เพียงหนึ่ง อีกคนต้องถูกปฏิเสธหรือเข้ารายชื่อรอ
4. ยกเลิกรายการยืนยันหนึ่งรายการ จำนวนว่างต้องเพิ่มครั้งเดียว ลองยกเลิกซ้ำและตรวจว่าไม่เพิ่มอีก
5. จำลองการบันทึกล้มเหลวหรือไม่ได้รับคำตอบ หน้าจอต้องแสดงว่ายังไม่ทราบผลและลองใหม่ได้โดยไม่สร้างรายการซ้ำ
6. ลองอ่านและแก้รายการของผู้ใช้ทดสอบอีกคน ทั้งสองการกระทำต้องเป็นไปตามกฎสิทธิ์ที่กำหนด

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

ตัดสินใจก่อนเดินหน้า pilot

ตัวอย่างนี้ผ่านเมื่อรายการยืนยันไม่เกินหก คำขอซ้ำยังมีรายการเดียว การยกเลิกคืนที่นั่งหนึ่งครั้ง และความล้มเหลวไม่แสดงผลสำเร็จผิด ๆ ล้างฐานข้อมูลทดสอบและรันชุดทดสอบใหม่หลังแก้ schema ระบบยืนยันตัวตน หรือ logic การจองทุกครั้ง

ถ้าเคสที่นั่งสุดท้ายไม่ผ่าน ให้หยุดรับคำขอ ใช้รายชื่อรอแบบจดเวลาไว้ก่อน แล้วให้ผู้พัฒนาแก้การตรวจจำนวนแบบ atomic ถ้าแบ่งสิทธิ์ไม่ได้ ให้ปิดการเข้าถึงร่วมและใช้เฉพาะข้อมูลสมมติ การชำระเงิน คืนเงิน ข้อความทางกฎหมาย ความเป็นส่วนตัว การรับมือ abuse และ monitoring ต้องตรวจแยกก่อนเปิดใช้

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