Капча блокирует автоматические тесты: как её обойти#

QA-инженер добавляет E2E-тест на форму регистрации. Тест доходит до капчи и падает не из-за бага, а потому что капча не пропускает автоматизированный запрос.

С этим сталкиваются QA-инженеры, разработчики, настраивающие CI/CD, и специалисты по автоматизации, которые тестируют интеграции со сторонними сайтами. После этой статьи вы будете знать, когда достаточно тестового ключа, а когда нужен API решения капч, и как встроить оба варианта в тестовый сценарий.

Почему капча ломает автоматические тесты#

Разные типы капчи проверяют разные сигналы. Некоторые анализируют параметры браузера и контекст взаимодействия, другие требуют явного действия: решить пазл, выбрать изображения или ввести текст с картинки.

Selenium и Playwright эмулируют часть пользовательских действий, но headless-режим и типовые настройки автоматизации отличаются от обычного браузера по таймингам и параметрам окружения. Капча, которая анализирует контекст взаимодействия, может отреагировать на эти отличия и заблокировать тест. Капча с явным заданием требует отдельного шага: пазл или картинки нужно решить, независимо от того, насколько реалистично эмулировано поведение до этого шага.

Какие есть способы пройти капчу в тесте#

Отключить капчу флагом окружения или подменить её моком тоже вариант, если у вас есть доступ к коду и конфигурации приложения. В этой статье разобраны два подхода для случаев, когда капча остаётся на странице как есть, боевая или тестовая:

• тестовый ключ от поставщика капчи, который встраивается в код страницы вместо боевого
• API решения капч, который принимает sitekey и URL страницы и возвращает готовый токен

Каждый подходит для разных условий. Ниже разберём, когда использовать каждый из них.

Когда тестовый ключ решает проблему#

Тестовый ключ подходит, если вы контролируете код страницы и можете подставить его вместо боевого. Это условие определяет, работает вариант или нет.

Google reCAPTCHA v2 публикует официальные тестовые ключи в документации:

• site key: 6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI
• secret key: 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe

Ключи всегда возвращают успешную проверку и не проверяют домен. Google предупреждает: пользователь увидит на странице пометку "This reCAPTCHA is for testing purposes only", но серверная проверка пройдёт.

Cloudflare Turnstile документирует тестовые sitekey с разным поведением:

• 1x00000000000000000000AA всегда проходит проверку (видимый виджет)
• 2x00000000000000000000AB всегда блокирует (видимый виджет)
• 3x00000000000000000000FF всегда показывает интерактивный вызов
• 1x00000000000000000000BB всегда проходит проверку (invisible-виджет)
• 2x00000000000000000000BB всегда блокирует (invisible-виджет)

hCaptcha публикует тестовый sitekey 10000000-ffff-ffff-ffff-000000000001, который тоже проходит проверку без реального решения.

Когда тестового ключа недостаточно#

Тестовый ключ не подходит, если вы не управляете кодом страницы или окружением. Например, в двух случаях:

Нет дев-окружения. У продукта есть только прод, разработчики не выделили флаг для подмены ключа на тестовый. Вставить тестовый sitekey некуда, а менять боевой ключ на проде ради тестов рискованно: это отключит защиту для реальных пользователей.

Страница принадлежит третьей стороне. Вы тестируете интеграцию с партнёрским сервисом или платёжным провайдером. У вас нет доступа к их HTML, значит подставить тестовый ключ невозможно. Решение о том, какой ключ показывать, принимает владелец сайта, а не вы.

В обоих случаях тест получает реальный sitekey и решает капчу через API, а не подменяет её тестовым ключом.

Как решить капчу через API#

Процесс одинаковый независимо от того, тестируете вы свой сайт без дев-окружения или чужую страницу:

sitekey + URL → createTask → getTaskResult → token → тест

1. Получить sitekey и URL страницы с капчей.
2. Создать задачу через метод createTask.
3. Получить токен через метод getTaskResult.
4. Подставить токен в форму и продолжить сценарий теста.

Сценарий: тестирование партнёрской интеграции#

У команды нет доступа к коду партнёрского сервиса, а у сервиса стоит Turnstile на форме входа. Заменить боевой sitekey на тестовый невозможно, потому что HTML страницы принадлежит партнёру.

Тест использует ту же последовательность, что и в разделе выше: получает реальный sitekey, решает капчу через API и передаёт токен в форму входа. Сценарий проходит шаг с капчей и продолжает проверку остальной части интеграции.

Такой же подход используют при тестировании сервисов, которые не предоставляют API для автоматизации: капча решается через внешний сервис, а не через доступ к коду страницы, которого у вас нет.

Что делать дальше#

Если вы контролируете код страницы и у вас есть дев или стейджинг окружение, начните с тестового ключа поставщика капчи. Он не требует внешних сервисов и не тратит время на решение реальной капчи.

Если кода страницы у вас нет, будь то прод без флага окружения или сайт третьей стороны, используйте API решения капч: получите sitekey и URL, вызовите createTask, заберите токен через getTaskResult и подставьте его в тест.

Как подключить Captcha solver#

Если такой сценарий нужен в ваших автоматизированных тестах, Captcha solver предоставляет API с теми же методами createTask и getTaskResult. API совместим с форматом anti-captcha, поэтому существующие клиентские библиотеки под этот формат подключаются заменой базового адреса на https://api.captcha-solver.com.

Сервис решает reCAPTCHA v2 (включая Enterprise), reCAPTCHA v3, Cloudflare Turnstile, Yandex SmartCaptcha, GeeTest v3/v4, Tencent, а также ImageToTextTask и CoordinatesTask для капч-картинок без sitekey.

Чтобы подключить сервис к тесту:

1. Зарегистрироваться и подтвердить email.
2. Получить clientKey в личном кабинете.
3. Пополнить баланс.
4. Передать clientKey, sitekey и URL страницы в createTask, как описано выше.

Сервис работает по модели оплаты за фактическое решение капч. Регистрация компании не требуется.

Тарифы по типам капч: страница Тарифы. Формат запросов и полный список полей для каждого типа задач: документация API.