Область применения: руководство касается только собственных или явно авторизованных QA-, staging- и production-сред. Ниже — диагностика, тестирование и наблюдаемость вашей собственной CAPTCHA-интеграции, а не сторонних сайтов и не несанкционированных сценариев.
QA-инженер запускает один и тот же сценарий дважды подряд — и получает два разных результата: в первый раз форма проходит чисто, во второй неожиданно всплывает CAPTCHA, а логин подхватывает чужую сессию. Причина почти всегда одна: браузерный профиль общий, и один тест «протекает» в другой через cookie, localStorage или незакрытую сессию. Изоляция профилей убирает эту причину на уровне инфраструктуры, а не точечными патчами в самом тесте.
Что хранить в каждом QA-профиле
| Слой | Что хранится |
|---|---|
| Cookies | session, csrf, опционально CAPTCHA-cookie |
| Local / session storage | UI-состояние, фичефлаги |
| IndexedDB | оффлайн-кеш приложения |
| Service worker registrations | оффлайн-режим |
| Permissions | уведомления, геолокация в staging |
Почему общий профиль ломает CAPTCHA-тесты
- Каждый сценарий стартует с заранее известным состоянием cookie — никаких «сюрпризов» от предыдущего прогона.
- Тестовые аккаунты не пересекаются между сценариями.
- Прогоны сравнимы друг с другом: медиана и P90 считаются на одинаковых стартовых условиях.
- Падение одного теста не «отравляет» соседние сценарии в той же CI-очереди.
Это не про обход чьей-то защиты — это обычная инженерная гигиена собственных QA-стендов.
Как устроен один QA-профиль
Каталог ./qa-profiles/checkout-smoke/ хранит данные ровно одного сценария. Запуск браузера с собственным --user-data-dir физически изолирует его от соседних сценариев, если каталог уникален для каждого:
chrome --user-data-dir=./qa-profiles/checkout-smoke \
https://staging.example.com/checkout-test
В Playwright и Puppeteer тот же принцип реализует userDataDir или persistent context — API отличается, идея та же.
Куда встраивается CaptchaAI в изолированном профиле
Если в staging-форме внутри профиля появляется reCAPTCHA v2 или Cloudflare Turnstile, тест не «выходит» за пределы своей страницы — он запрашивает токен только для неё и кладёт результат прямо в DOM того же профиля:
from playwright.sync_api import sync_playwright
PROFILE = './qa-profiles/checkout-smoke'
PAGE = 'https://staging.example.com/captcha-demo'
with sync_playwright() as p:
ctx = p.chromium.launch_persistent_context(PROFILE, headless=True)
page = ctx.new_page()
page.goto(PAGE)
sitekey = page.locator('.g-recaptcha').get_attribute('data-sitekey')
token = solve(sitekey)
page.evaluate(
"t => document.getElementById('g-recaptcha-response').value = t",
token,
)
page.click('button[type=submit]')
ctx.close()
Логи и метрики между релизами
Структурированные логи — быстрый по нашей внутренней выборке способ сравнить поведение 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 и по окружению.
Жизненный цикл профиля в CI
Каталог профиля — обычный CI-артефакт: создаётся перед прогоном, очищается после. Для долгоживущих сценариев (например, e2e-тестов с накопленной историей сессии) сохраняйте snapshot профиля как артефакт сборки и разворачивайте его в начале следующего прогона.
Пример из практики: команда с инженерами в Москве, Минске и Алматы гоняет CI-раннеры в европейском облачном регионе, где живёт и staging, — сетевая разница минимальна, но мобильные и нестабильные каналы у части инженеров всё равно требуют разумных таймаутов и повтора на CAPTCHA-шаге, а не жёсткого фейла с первой попытки. Если профиль хранит данные тестовых пользователей, держите в уме требования 152-ФЗ «О персональных данных» — используйте только синтетические учётные записи и не выгружайте snapshot с реальными данными в общий репозиторий.
Чек-лист перед прогоном
- Запрос уходит только на собственные или явно авторизованные endpoints.
- Тестовые аккаунты, платежи и события помечены как фиктивные.
- Токен CAPTCHA проверяется на своём backend, а не принимается на веру от клиента.
- В логах есть
task_id, тип CAPTCHA, время ожидания и итоговый статус. - Скрипт возвращает корректный exit code, чтобы CI мог принять решение по прогону.
- Каталог профиля с реальными cookie или токенами не попадает в общий репозиторий.
Частые проблемы профиля
| Симптом | Что делать |
|---|---|
| В тесте видны чужие cookie | Проверьте, что --user-data-dir уникален для каждого сценария |
| Профиль повреждён после падения теста | Удалите каталог и создайте профиль заново |
| Профиль разрастается на диске | Периодически очищайте IndexedDB и кеш между прогонами |
| CAPTCHA всплывает на каждом прогоне | Сохраняйте валидную сессию/cookie между шагами сценария |
| Токен CaptchaAI не принимается формой | Сверьте, что sitekey и pageurl соответствуют реальной странице профиля |
FAQ
Можно ли применять такую изоляцию профилей на чужих сайтах?
Нет. Сценарии в этом руководстве относятся только к собственным или явно авторизованным средам. Для чужих ресурсов сначала получите письменное разрешение владельца.
Что делать, если CaptchaAI вернул ошибку при решении CAPTCHA?
Залогируйте task_id, тип CAPTCHA и текст ошибки, повторите запрос с экспоненциальной задержкой и следите за долей ошибок на дашборде. Устойчивый рост ошибок — повод проверить sitekey и саму страницу.
Сколько потоков CaptchaAI нужно для параллельных QA-профилей?
Тарификация у CaptchaAI идёт по одновременным потокам, а не по числу решений: пока один профиль ждёт токен, он занимает один поток. При 10 параллельных профилях берите тариф с запасом по потокам — например, ADVANCE ($90/мес, 50 потоков) — чтобы пиковые прогоны не упирались в лимит.
Как сравнивать результаты между релизами?
Пишите логи в одном формате и стройте отчёт по медиане, P90 и P99 на одинаковом наборе сценариев. Сравнивайте только сопоставимые выборки в собственной среде.
Нужны ли резидентные прокси для QA-профилей в staging?
Обычно нет. Для собственного staging важнее держать сетевые условия — регион, задержку — сопоставимыми между прогонами, чтобы результаты по CAPTCHA оставались воспроизводимыми, а не пытаться имитировать чужой трафик.
Безопасные связанные материалы
- Быстрый старт с API CaptchaAI
- Авторизованное QA-тестирование CAPTCHA
- Тестирование CAPTCHA API на собственных формах
- Отладка: браузерный тест падает, а API проходит
- Решение reCAPTCHA v2 через API
- Решение Cloudflare Turnstile через API
- Решение GeeTest v3 через API
Чистые QA-прогоны без пересечения сессий — подключите CaptchaAI в своём staging уже сегодня.
