Use Cases

Многошаговые workflow с CaptchaAI в собственных staging-средах

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

Многошаговый QA-сценарий — это не одна проверка CAPTCHA, а цепочка из 5–10 шагов: вход, переход по разделам, форма, оплата, подтверждение. Если CAPTCHA встречается хотя бы на одном шаге, наивный скрипт «получил токен — забыл» ломается на первом же ретрае: токен уходит не на тот шаг, сессия теряется, заказ дублируется. Три вещи делают такой workflow предсказуемым: модель состояния между шагами, идемпотентные ретраи и структурированные логи для сравнения релизов. Всё — в рамках собственной staging-среды.

Из каких шагов состоит типичный сценарий

Прежде чем оркестровать шаги кодом, зафиксируйте, где именно в сценарии может появиться CAPTCHA и какое состояние нужно пронести через этот шаг:

Шаг Возможная CAPTCHA Состояние
Login reCAPTCHA v2/v3 session id
Profile редко csrf
Cart нет items
Checkout Turnstile payment token
Confirm редко order id

Такая таблица — не документация ради документации: она сразу показывает, какие шаги нужно ретраить с учётом CAPTCHA, а какие можно повторять без обращения к CaptchaAI.

Пример: бюджет потоков для QA-команды

Тарификация CaptchaAI — по одновременным потокам, а не по числу решений, и это удобно закладывать в бюджет заранее, особенно агентствам и фрилансерам, которые выставляют счета в разных валютах: цена фиксирована в USD за поток, а не «плавает» вместе с курсом. Например, команда, гоняющая регрессионный тест оформления заказа в 5 параллельных потоков, укладывается в тариф BASIC ($15/мес, 5 потоков); при расширении набора сценариев до 20 параллельных прогонов уже нужен тариф ADVANCE ($90/мес, 50 потоков). Внутри тарифа решения не лимитированы — платите за параллелизм, а не за каждый отдельный шаг с CAPTCHA.

Этот бюджет и определяет max_workers в оркестраторе ниже: число потоков в тарифе — это верхняя граница того, сколько шагов сценария могут одновременно ждать решения CAPTCHA.

Единый идентификатор запуска на весь сценарий

Каждому прогону сценария присваивается один workflow_id, который сопровождает весь список шагов. Это даёт единую точку для логов, ретраев и идемпотентности — вместо того чтобы отслеживать состояние отдельно на каждом шаге:

STEPS = ['login', 'profile', 'cart', 'checkout', 'confirm']

def run(workflow_id: str, ctx: dict) -> None:
    for step in STEPS:
        ctx['workflow_id'] = workflow_id
        ctx['step'] = step
        execute(step, ctx)

Список STEPS фиксирован и последователен — это осознанное решение: динамическое ветвление усложняет диагностику падений и делает логи менее сравнимыми между релизами.

Идемпотентность и безопасные ретраи

Каждый шаг должен быть идемпотентен по паре (workflow_id, step). Тогда при сбое можно повторить только упавший шаг, не запрашивая заново CAPTCHA-токены для всего сценария и не рискуя задвоить заказ или платёж. На практике это значит:

  • перед выполнением шага проверяйте, не был ли он уже успешно завершён для этого workflow_id;
  • используйте экспоненциальную задержку между повторными попытками, а не мгновенный ретрай — особенно на шагах с оплатой.

Как управлять CAPTCHA-токеном по шагам

Токен запрашивается непосредственно перед шагом, который его требует, и не переиспользуется между разными шагами или разными workflow_id. Токен привязан к конкретным sitekey и pageurl того шага, на котором он был получен, — попытка подставить его на другой странице приведёт к ошибке валидации на стороне защищённого сайта, а не к экономии на вызовах API.

Структурированные логи и наблюдаемость

Структурированные логи помогают сравнивать поведение 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.

Типичные проблемы и что с ними делать

Симптом Что сделать
Шаг падает молча Включите structured logging
Дубли заказов Проверьте идемпотентность шага
CAPTCHA на каждом шаге Сохраняйте сессию между шагами
Долгий workflow Распараллельте независимые шаги

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

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

FAQ

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

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

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

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

Как сравнивать долю успешных решений между релизами?

Сохраняйте логи в едином формате и стройте отчёт по медиане, P90 и P99 на сопоставимом наборе сценариев. Сравнивайте только выборки одинакового объёма и в одной и той же собственной среде — иначе разница в цифрах ничего не скажет о самом релизе.

Сколько потоков нужно, чтобы workflow не тормозил?

Отталкивайтесь от максимального числа одновременно выполняющихся сценариев, а не от общего числа шагов: если параллельно может идти 5 workflow, хватит тарифа BASIC (5 потоков); при росте параллелизма переходите на STANDARD или ADVANCE. Пиковая нагрузка на checkout-шагах обычно и определяет нужное число потоков.

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

Многошаговые QA-сценарии без лишней ручной работы — начните с CaptchaAI.

Комментарии для этой статьи отключены.