Урок №12. Сценарий обработки капчи

Допустим, какая нибудь из наших кампаний перестала собирать данные или собирает не всю информацию, которая нам необходима. В поисках причины мы определили, что проблема заключается в капче. Чтобы решить эту проблему иногда достаточно использовать браузер вместо стандартного загрузчика. Однако, в ряде случаев капча возникает независимо от того, какой загрузчик мы используем. Тогда мы задействуем сценарий. Выбираем Браузер в качестве загрузчика. Создадим сценарий для обработки капчи. Для быстрого создания блока действий, направленного на обработку капчи, используем одну из заготовок, которые предлагает Picker.

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

Теперь задаем настройки действий и условий для нашего случая. Начнем с условий повторения блока. Их два: capcha exist и counter. Выберем первое условие. Оно означает что блок будет повторяться пока на странице присутствует хотя бы один элемент, соответствующий Xpath выражению данного условия. Здесь мы в качестве Xpath выражения зададим xpath изображения капчи, ведь это изображение в любом случае присутствует на странице с капчей. Даже если мы отправим неверную каптчу, появится изображение новой каптчи, сработает условие повторения capcha exist и блок по обработке каптчи повторится снова.

Однако может произойти так, что мы несколько раз отправим неверную капчу, и она будет появляться снова и снова. Таким образом, мы рискуем попасть в вечный цикл. Чтобы избежать этого, задаем условие COUNTER, которое не даст блоку обработки капчи запуститься более трех раз, даже если страница в очередной раз будет содержать изображение капчи. Максимально допустимое количество циклов работы блока вы можете поменять в настройках условия COUNTER. Заметим, что если страница изначально загружается без капчи, то условие captcha exist не выполняется и следовательно — блок обработки капчи не запускается вообще, что в общем то логично.

Теперь перейдем к настройке действий. Выбираем первое действие — PROCESS_CAPTCHA. В рамках него происходит ручная или автоматическая обработка капчи. В данном случае Xpath выражение должно указывать на саму капчу. Кликаем левой кнопкой мыши на изображении капчи, чтобы подобрать Xpath. После подбора сразу тестируем действие.

Заметим, что капча в данном примере вводится вручную. Автоматическую обработку капчи мы рассмотрим в последующих видео. Ее будет легко реализовать, если вы хорошо освоите текущий пример. Далее подбираем Xpath действия ввода распознанного текста капчи в соответствующее поле.

Тестируем. Все хорошо! Остается задать Xpath для действия клика по кнопке Отправить. Обратите внимание, Xpath для клика по кнопке лучше всегда побирать через контекстное меню. Picker выдал предупреждение о возможной привязке к нестабильным аттрибутам вебэлементов. В данном случае это класс в название которого входит слово hover. Нажимаем Да, чтобы исключить нестабильные аттрибуты из xpath выражения. Тестируем. Отлично, вместо страницы с капчей загрузилась нужная нам информация.

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

Тестируем работу кампании. По ходу работы кампании вводим капчу. Наконец видим, как собираются нужные данные. В следующих видео мы покажем, как настроить автоматическое распознавание капчи.