Тестирование CAPTCHA для очередей и checkout ticketing-платформ в staging

Область применения: руководство рассчитано на собственные или явно авторизованные QA-, staging- и production-среды. Ниже — только сценарии диагностики и наблюдаемости своей CAPTCHA-интеграции, без реальных продаж и без обращения к сторонним площадкам.

CAPTCHA в тикетинг-flow чаще ломается не в проде, а в staging — окружение отличается от продакшена доменом, sitekey и таймингами очереди. Не проверил очередь и checkout заранее — релиз уйдёт в прод с CAPTCHA, которая либо не появляется, либо блокирует валидные сессии. Ниже — чек-лист, staging-схема и рабочий код, чтобы воспроизвести оба узла на своей копии ticketing-платформы с фиктивными данными, без обращения к публичным сервисам.

QA-чек-лист перед релизом

• Запрос отправляется только на собственные или авторизованные endpoints.
• Тестовые учётные записи, события и платежи помечены как фиктивные.
• CAPTCHA-токен проверяется на собственном backend, а не доверяется клиенту.
• Логи содержат task_id, тип CAPTCHA, время ожидания и pass/fail.
• Скрипт возвращает корректный exit code, чтобы CI мог принять решение по прогону.

Дальше — как собрать staging-окружение и код, которые закрывают каждый пункт этого списка.

Где в тикетинг-flow тестировать CAPTCHA: очередь и checkout

Ticketing-платформы ставят CAPTCHA на двух рубежах — при входе в очередь и на странице оплаты. Соберите staging-окружение, где оба узла повторяют production-логику на фиктивных данных:

• https://staging.example.com/ticketing/queue-test — endpoint очереди с конфигурируемым размером;
• https://staging.example.com/ticketing/checkout-test — checkout с тестовыми платёжными токенами;
• https://staging.example.com/ticketing/fake-event — фиктивное событие с фиктивной картой мест.

Проверяйте узлы отдельно: очередь может пропускать CAPTCHA при низкой нагрузке, checkout требует её всегда.

Типичные проблемы CAPTCHA в staging

Прежде чем писать сценарии, стоит знать, что чаще всего ломается — так проще заранее заложить проверки в тесты:

Фиктивные события, места и платежи

Эти признаки нужны, чтобы production-фильтры заведомо отклоняли заказы из QA, если те случайно попадут в боевую базу. Если сценарий генерирует email тестового пользователя, помечайте его как фиктивный и не храните дольше срока прогона — это в духе 152-ФЗ «О персональных данных» для читателей из РФ и близко к осмотрительности, которую ждут от QA-команд в GDPR-юрисдикциях.

Как staging-скрипт отправляет задачу в CaptchaAI

QA-сценарий запрашивает решение только для своего staging-домена — sitekey и pageurl всегда указывают на тестовую копию, никогда на боевой домен:

import os, requests, time

API_KEY = os.environ['CAPTCHAAI_KEY']
PAGE = 'https://staging.example.com/ticketing/queue-test'

def solve_turnstile(sitekey: str) -> str:
    r = requests.post('https://ocr.captchaai.com/in.php', data={
        'key': API_KEY, 'method': 'turnstile',
        'sitekey': sitekey, 'pageurl': PAGE, 'json': 1,
    }).json()
    task_id = r['request']
    for _ in range(40):
        time.sleep(3)
        res = requests.get('https://ocr.captchaai.com/res.php', params={
            'key': API_KEY, 'action': 'get', 'id': task_id, 'json': 1,
        }).json()
        if res['status'] == 1:
            return res['request']
    raise TimeoutError(task_id)

Таймаут в 40 попыток по 3 секунды — ориентир для Turnstile. При нестабильном мобильном канале увеличьте паузу до 5 секунд, чтобы не плодить лишние запросы к res.php. Для reCAPTCHA v2 и v3 логика опроса та же — меняется только method и набор параметров запроса.

Проверка результата на своём backend

Полученный токен передайте во внутренний QA-endpoint, который вызывает серверную верификацию у провайдера CAPTCHA и пишет результат в таблицу qa_attempts. Прогон помечается pass или fail по ответу backend, а не по клиентскому предположению — иначе баг во frontend-валидации останется незамеченным до прода.

Сценарии очереди и нагрузки

• одна QA-сессия проходит очередь и оплату — smoke-тест;
• 50 параллельных QA-сессий — проверка таймингов очереди;
• 200 сессий за минуту — нагрузочный сценарий;
• провал платежа при валидном CAPTCHA-токене — отдельный сценарий обработки ошибок.

Smoke-тест запускайте на каждый pull request, который трогает очередь или checkout. Нагрузочный и параллельный сценарии достаточно гонять перед релизом и раз в одну–две недели как regression — так регрессия в CAPTCHA-виджете находится до того, как её заметят реальные пользователи.

Логи и наблюдаемость

Структурированные логи помогают сравнивать поведение CAPTCHA между релизами и быстро находить регрессии в собственных формах:

import json, time, logging

log = logging.getLogger('captcha-qa')

def record(event: str, **fields) -> None:
    payload = {'ts': time.time(), 'event': event, **fields}
    log.info(json.dumps(payload, ensure_ascii=False))

Минимальный набор полей: slug, captcha_type, task_id, wait_seconds, verify_status, env — этого хватит для дашборда медианы, P90 и P99 по типу CAPTCHA и по среде. Команды со staging в европейских регионах или в Казахстане обычно видят p90 в несколько секунд — берите эту цифру как baseline, а не как формальный SLA.

FAQ

Можно ли использовать этот подход на сторонних сайтах?

Нет. Сценарии применимы только к собственным или явно авторизованным средам. Для чужих ресурсов запрашивайте письменное разрешение владельца площадки.

Что делать, если CaptchaAI вернул ошибку?

Логируйте task_id, тип CAPTCHA и текст ошибки, повторите запрос с экспоненциальной задержкой. Рост доли ошибок — повод проверить sitekey и страницу.

Нужны ли реальные платёжные данные для этих тестов?

Нет. Используйте только sandbox-токены платёжного провайдера и фиктивные карты — реальные данные в QA-контуре только повышают риск утечки.

Как часто перезапускать этот набор тестов?

Smoke-тест — на каждый релевантный pull request. Нагрузочный и параллельный сценарии — перед каждым релизом с изменениями в очереди, checkout или CAPTCHA-виджете, и раз в одну–две недели как regression-прогон.

Безопасные связанные руководства

• Быстрый старт CaptchaAI
• QA-тестирование CAPTCHA в авторизованных средах
• Тестирование CAPTCHA API на собственных формах
• Отладка: браузерный тест падает, API проходит
• reCAPTCHA v2 через API
• Cloudflare Turnstile через API
• GeeTest v3 через API

Готовы проверить CAPTCHA-интеграцию ticketing-платформы в собственном staging? Получите ключ CaptchaAI.