اختبار غرف الانتظار ومسارات الدفع في منصات التذاكر المملوكة

قبل أي تحديث لواجهة منصة التذاكر أو لطبقة الحماية، هناك سؤال واحد يحسم ما إذا كان النشر آمنًا: هل ما زال اختبار CAPTCHA يظهر في المكان الصحيح، ويُقبل رمزه داخل الخادم الخلفي، وتبقى الجلسة متماسكة من غرفة الانتظار حتى شاشة الدفع؟ هذا الدليل موجّه لفرق QA والهندسة التي تملك منصة تذاكر وتريد التحقق من ذلك على staging.

نطاق الاستخدام: يقتصر هذا الدليل على فرق QA والهندسة التي تملك المنصة أو تدير بيئة staging مصرّحًا بها. لا يتناول شراءً حقيقيًا، ولا الدخول إلى قوائم انتظار عامة، ولا التشغيل على أحداث أو منصات مملوكة لجهات أخرى.

سيناريو واقعي: ليلة طرح مبيعات على منصة تملكها

تخيّل فريقًا يدير منصة حجز تذاكر لمباراة كبيرة في أحد ملاعب المنطقة، ويستعد لطرح مبيعات يُتوقّع أن يضغط على غرفة الانتظار بآلاف الجلسات المتزامنة. قبل الطرح بأيام، يحتاج الفريق إلى نسخة staging تحاكي المسار كاملًا: بوابة الانتظار، فحجز المقعد، فالتحقق النهائي قبل الدفع. الهدف ليس شراء تذكرة، بل التأكد من أن اختبار CAPTCHA يظهر عند الحاجة، وأن الرمز يصل سليمًا، وأن أي فشل يترك أثرًا واضحًا.

تتركّز المخاطرة عادة في نوعين: reCAPTCHA v2 أو reCAPTCHA v3 على بوابة الانتظار وصفحة الدفع، وأحيانًا Cloudflare Turnstile على صفحات الوصول. وكلها أنواع يدعمها CaptchaAI، ما يجعل بناء اختبار تكامل موثوق أمرًا مباشرًا.

ما جرى استبعاده عمدًا ولماذا

قبل تفصيل ما يجب اختباره، يفيد تثبيت حدود العمل. لا يتناول هذا الدليل:

• الدخول إلى قوائم انتظار حقيقية تابعة لجهات خارجية
• تنسيق التوقيت مع طرح بيع فعلي أو نافذة مبيعات عامة
• الحجز الفعلي أو إتمام دفع حقيقي أو محاولة استباق مستخدمين آخرين
• استخدام وكلاء أو جلسات متغيّرة بهدف العمل على منصة لا تملكها

إذا احتاج فريقك إلى تمرين ضغط قبل حدث تملكه، فابنِ نسخة staging من غرفة الانتظار ومسار الدفع، واختبر هناك ببيانات ومؤشرات واضحة — لا على حدث عام مباشر.

ما الذي يجب أن يتحقق منه الاختبار في منصة مملوكة

حين تمرّ هذه الأسئلة، ينشر الفريق تغييرات الواجهة أو الحماية بثقة أعلى. وإذا تعثّرت، تكفي البيانات المتاحة لتحديد ما إذا كان الخلل في بنية DOM، أم في انتقال الجلسة، أم في منطق التحقق الخلفي — قبل أن يظهر الخطأ أمام مستخدم حقيقي.

مثال تشغيلي: التحقق من غرفة الانتظار والدفع على staging

يوضّح المثال التالي كيف تختبر بيئة QA منصة تذاكر مملوكة. لا يحاول إكمال عملية شراء، ولا حجز مقاعد حقيقية، ولا التقدّم على مستخدمين آخرين. كل ما يفعله هو التأكد من أن غرفة الانتظار وصفحة التحقق الخلفية تستقبلان الرمز داخل الجلسة نفسها.

import requests
import time


CAPTCHAAI_KEY = "YOUR_API_KEY"
CAPTCHAAI_URL = "https://ocr.captchaai.com"


def solve_captcha(sitekey, pageurl, method="userrecaptcha"):
    submit = requests.post(
        f"{CAPTCHAAI_URL}/in.php",
        data={
            "key": CAPTCHAAI_KEY,
            "method": method,
            "googlekey": sitekey,
            "pageurl": pageurl,
            "json": 1,
        },
        timeout=30,
    )
    submit.raise_for_status()
    task_id = submit.json()["request"]

    for _ in range(30):
        time.sleep(5)
        result = requests.get(
            f"{CAPTCHAAI_URL}/res.php",
            params={
                "key": CAPTCHAAI_KEY,
                "action": "get",
                "id": task_id,
                "json": 1,
            },
            timeout=30,
        )
        result.raise_for_status()
        data = result.json()
        if data.get("status") == 1:
            return data["request"]

    raise TimeoutError("ticket platform CAPTCHA solve timed out")


def validate_waiting_room_and_checkout():
    session = requests.Session()
    waiting_room_url = "https://staging.example-tickets.test/waiting-room"
    checkout_validation_url = "https://staging.example-tickets.test/checkout/validate-captcha"

    waiting_room = session.get(waiting_room_url, timeout=30)
    waiting_room.raise_for_status()

    room_token = solve_captcha(
        sitekey="6LcR_waiting_room_owned",
        pageurl=waiting_room_url,
    )

    room_response = session.post(
        f"{waiting_room_url}/validate",
        json={
            "captcha_token": room_token,
            "scenario": "qa-room-check",
        },
        timeout=30,
    )
    room_response.raise_for_status()

    checkout_token = solve_captcha(
        sitekey="6LcR_checkout_owned",
        pageurl="https://staging.example-tickets.test/checkout",
    )

    checkout_response = session.post(
        checkout_validation_url,
        json={
            "reservation_id": "qa-reservation-001",
            "captcha_token": checkout_token,
        },
        timeout=30,
    )
    checkout_response.raise_for_status()

    return {
        "waiting_room": room_response.json(),
        "checkout": checkout_response.json(),
    }


print(validate_waiting_room_and_checkout())

لاحظ أن المسار يستخدم كائن Session واحدًا للخطوتين، لأن ثبات ملف تعريف الارتباط بين الغرفة والدفع هو بالضبط ما نريد إثباته. وهو كافٍ لقياس تعامل المنصة مع الرمز واستقرار الجلسة ورسائل الفشل.

المؤشرات التي تستحق المراقبة في هذه البيئة

تكتسب هذه المؤشرات قيمتها من أنك تملك المنصة وتستطيع ضبطها. أما تحويله إلى سباق على أحداث عامة فخارج نطاق هذا الدليل.

الأسئلة الشائعة

كيف أتحقق من ظهور CAPTCHA في غرفة الانتظار دون إتمام شراء حقيقي؟

اطلب صفحة غرفة الانتظار على staging ضمن جلسة واحدة، ثم احصل على الرمز عبر CaptchaAI وأرسله إلى نقطة التحقق فقط. أنت تقيس ظهور التحدي وقبول الرمز، دون لمس منطق الحجز أو الدفع الفعلي.

ما أنواع CAPTCHA التي تظهر عادة على منصات التذاكر ويدعمها CaptchaAI؟

غالبًا reCAPTCHA v2 وreCAPTCHA v3 على بوابة الانتظار وصفحة الدفع، وأحيانًا Cloudflare Turnstile على صفحات الوصول. الثلاثة مدعومة، ويمكن تغطيتها بنفس نمط الإرسال والاستطلاع الموضّح أعلاه.

لماذا قد تفشل الجلسة بين غرفة الانتظار وصفحة الدفع؟

عادة بسبب فقدان ملف تعريف الارتباط أو تغيّر معرّف الجلسة بين الخطوتين. لهذا يستخدم المثال كائن Session واحدًا؛ ولمزيد من التفصيل راجع دليل استمرارية جلسة المتصفح أدناه.

هل يمكن تشغيل هذا الاختبار داخل خط CI/CD؟

نعم. المسار مجرّد نداءات HTTP على staging تملكها، فحوّله إلى فحص دوري يسبق كل نشر ويتوقّف عند أي خطأ.

أدلة ذات صلة

• الحفاظ على استمرارية جلسة المتصفح في سير عمل CAPTCHA
• حل CAPTCHA ضمن اختبارات ضمان الجودة المصرّح بها

إذا كنت تختبر منصة تذاكر تملكها، فابدأ بفحص غرفة الانتظار والتحقق الخلفي على staging، ثم راقب زمن الحل وثبات الجلسة ورسائل الفشل قبل أي طرح أوسع.