Комментарии 18
НЛО прилетело и опубликовало эту надпись здесь
Если вы про то как просто решить ими проблему автоматического тестирования, то они платные. Так себе идея если это для тестов, как в статье.
Если вы про то как легко и просто обойти капчу, вон какой есть классный способ и капча не работает, то вполне достаточно реализовать капчу так, как рекомендует гугл, проверяя в его ответе не только success/failure, но и другие параметры которые он возвращает.
Капча — работает. Сервисы эти эффективны только против небрежной реализации.
Если вы про то как легко и просто обойти капчу, вон какой есть классный способ и капча не работает, то вполне достаточно реализовать капчу так, как рекомендует гугл, проверяя в его ответе не только success/failure, но и другие параметры которые он возвращает.
Капча — работает. Сервисы эти эффективны только против небрежной реализации.
Они не настолько дорогие. По мне так проще заплатить условный доллар в месяц, чем тратить уйму времени на решение этой же задачи самому.
Зависит от количества ваших тестов и частоты их прогона. Используя самый популярный, на выходе получается дешево $1.39 за 1000 решенных капч. Плюс, к тому же все они дают цифру в ~90% вероятности успеха решения. Т.е. каждый десятый тест потенциально будет flaky, что не есть хорошо
Если вы в тестах гоняете рекаптчу, то, скорее всего, это вам очень и очень нужно, а значит вы потенциально не боитесь расходов.
На своем примере за февраль: $28 за 36000 каптч. Там не только рекаптча, но и ставка у меня стоит максимально высокая, чтобы повысить скорость.
Это около 1000 тестов в сутки. Если у вас правда столько всего, вы не заметите расходов в 30 баксов.
На своем примере за февраль: $28 за 36000 каптч. Там не только рекаптча, но и ставка у меня стоит максимально высокая, чтобы повысить скорость.
Это около 1000 тестов в сутки. Если у вас правда столько всего, вы не заметите расходов в 30 баксов.
Хм, звучит действительно неплохо, спасибо
А какой процент неверно решенных капч?
А какой процент неверно решенных капч?
Не знаю где посмотреть именно процент.
На основании данных сервиса (Анти-каптча, если что) около 250 ошибок (вроде бы за все время), но по ощущениям их больше.
У меня не тесты гоняются, а сервис используется на двух моих сайтах и конкретно по рекаптче я делал переотправку в случае ошибки, т.к. «правильное» решение гугл иногда не принимает.
Ну и «втупую» рекаптча может решаться по две минуты. Если вам нужно быстрее, там есть способ это ускорить.
Дополнию, что только рекапча будет стоить дороже, чем у меня. Но, блин, зачем вам столько тестов с ней гонять? :)
На основании данных сервиса (Анти-каптча, если что) около 250 ошибок (вроде бы за все время), но по ощущениям их больше.
У меня не тесты гоняются, а сервис используется на двух моих сайтах и конкретно по рекаптче я делал переотправку в случае ошибки, т.к. «правильное» решение гугл иногда не принимает.
Ну и «втупую» рекаптча может решаться по две минуты. Если вам нужно быстрее, там есть способ это ускорить.
Дополнию, что только рекапча будет стоить дороже, чем у меня. Но, блин, зачем вам столько тестов с ней гонять? :)
Не сталкивался с капчой ни разу, а что отключить ее на тестовой среде так сложно?
А на Яндекс.Поиске не пробовали тестировать? Я имею в виду ситуацию, когда на каком-нибудь очередном запросе вылезает капча «нам показалось тут что вы...»
Честно, так и не понял о чем статья. О там как пользоваться куками в Selenium? Ну не знаю…
Если есть возможно, то лучше мониторить изменения на стороннем сервисе через предоставляемое ими API, может есть такая возможность?
Вообще не понимаю, зачем заходить туда Selenium'ом, таким образом подвергать опасности и без того хрупкие UI-тесты.
В случае необходимости периодически руками проверять UI.
Да и вообще тестить сторонние сервисы, да еще и на проде, это мне кажется прям совсем не правильно.
Если есть возможно, то лучше мониторить изменения на стороннем сервисе через предоставляемое ими API, может есть такая возможность?
Вообще не понимаю, зачем заходить туда Selenium'ом, таким образом подвергать опасности и без того хрупкие UI-тесты.
В случае необходимости периодически руками проверять UI.
Да и вообще тестить сторонние сервисы, да еще и на проде, это мне кажется прям совсем не правильно.
— Открытого API нет
— Немного не понял, каким образом мы «подвергаем опасности хрупкие UI-тесты»? :)
— Мы тестим не сторонний сервис, а наше приложение, интегрированное в него. Именно поэтому мы позволили себе обойти шаг логина, т.к. это как раз тестирование стороннего сервиса, в котором мы не заинтересованы
— Немного не понял, каким образом мы «подвергаем опасности хрупкие UI-тесты»? :)
— Мы тестим не сторонний сервис, а наше приложение, интегрированное в него. Именно поэтому мы позволили себе обойти шаг логина, т.к. это как раз тестирование стороннего сервиса, в котором мы не заинтересованы
Здравствуйте, Михаил. Хорошая тема.
В тестировании производительности использую более простые на мой взгляд способы.
Шаг 1. I'd like to run automated tests with reCAPTCHA. What should I do?
Шаг 2. Настройка Fiddler и работы приложений через прокси-сервер. Так как сервер приложений всё равно будет отправлять запросы в Google, а Google для такой отладочной связки Site key + Secret key будет всегда говорить — ok. Можно автоматизировать процесс, сделать так чтобы сервер приложений работал с Google через прокси-сервер. А в прокси-сервере (использую Fidder) настроить автоответ на запрос.
2.1. Сохранить оригинальный ответ от Google ReCapcha.
2.2. Используя auto response в Fiddler сделать так, чтобы на все запросы к Google ReCapcha был фиксированный положительный ответ.
В ответе будет сказано, что результат проверки — ok. Но будет сказано, что время ответа было в прошлом. Если сервер приложений валидирует не только ответ true/false, но и время. То автоответ не сработает. Но, обычно, сервер приложений время не валидирует, что позволяет сделать замкнутую систему.
Таким образом, получаю полностью автономную систему. Которая не обращается в Интернет. И на которую можно подавать высокую нагрузку. Проверял на интенсивности до 50 сценариев в сек.
В тестировании производительности использую более простые на мой взгляд способы.
Шаг 1. I'd like to run automated tests with reCAPTCHA. What should I do?
Site key: 6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhIЭти настройки указываются в конфигурационном файле сервера приложений.
Secret key: 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe
Шаг 2. Настройка Fiddler и работы приложений через прокси-сервер. Так как сервер приложений всё равно будет отправлять запросы в Google, а Google для такой отладочной связки Site key + Secret key будет всегда говорить — ok. Можно автоматизировать процесс, сделать так чтобы сервер приложений работал с Google через прокси-сервер. А в прокси-сервере (использую Fidder) настроить автоответ на запрос.
2.1. Сохранить оригинальный ответ от Google ReCapcha.
2.2. Используя auto response в Fiddler сделать так, чтобы на все запросы к Google ReCapcha был фиксированный положительный ответ.
В ответе будет сказано, что результат проверки — ok. Но будет сказано, что время ответа было в прошлом. Если сервер приложений валидирует не только ответ true/false, но и время. То автоответ не сработает. Но, обычно, сервер приложений время не валидирует, что позволяет сделать замкнутую систему.
Таким образом, получаю полностью автономную систему. Которая не обращается в Интернет. И на которую можно подавать высокую нагрузку. Проверял на интенсивности до 50 сценариев в сек.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обход ReCaptcha в Selenium тестах