اختبار نظام حجوزات: سيناريوهات التزامن التي يفوّتها المطوّرون
نظام الحجوزات يبدو بسيطاً: اختر موعداً واضغط تأكيد. لكن المشكلات الحقيقية تظهر حين يتصرف أكثر من مستخدم معاً.
السيناريو 1: الحجز المزدوج
مستخدمان يؤكدان الموعد نفسه في اللحظة ذاتها. إن كان التحقق في الواجهة فقط فسينجح الاثنان.
الحل: تحقق على الخادم داخل معاملة (transaction) مع قيد تفرّد على الموعد.
ALTER TABLE bookings
ADD CONSTRAINT uq_slot UNIQUE (resource_id, slot_start);
السيناريو 2: الإلغاء أثناء الدفع
المستخدم يدفع بينما ينتهي حجز الانتظار. ماذا يحدث للمال وللموعد؟
السيناريو 3: فروق التوقيت
ضبط التوقيت على الخادم والجهاز والمنطقة الزمنية. موعد 11:30 مساءً قد يصبح اليوم التالي.
السيناريو 4: الزر المزدوج
نقر المستخدم مرتين على "تأكيد". استخدم مفتاح فرادة للطلب (idempotency key).
السيناريو 5: الاتصال البطيء
انقطاع الشبكة بعد إرسال الطلب وقبل وصول الرد. هل يعيد المستخدم المحاولة؟ وهل يتكرر الحجز؟
كيف تختبرها
- سكربت يرسل عشرين طلباً متزامناً للموعد ذاته.
- محاكاة انقطاع الشبكة في أدوات المتصفح.
- حالات حدية للتواريخ: نهاية الشهر وتغيير التوقيت.
هذا النوع من الفحص جزء من ضمان الجودة عندنا.
