Всем привет. Для целей тестирования была создана очередная форма. Простая, без какой — то дополнительной логики как в предыдущей. Зато с использованием теста Тьюринга ( по простому — капча ( captcha)).

Немного о самой форме. Четыре обязательных поля для ввода данных (ФИО, дата рождения, телефон, email). Пятая — ввод проверочных символов. Немного заморочился и настроил при помощи регулярных выражений валидацию некоторых полей. Так к примеру для поля с вводом ФИО применил следующее регулярное выражение :

/^\p{Lu}\p{Ll}*(?:-\p{Lu}\p{Ll}*)? \p{Lu}\p{Ll}*(?:-\p{Lu}\p{Ll}*)? \p{Lu}\p{Ll}*(?:-\p{Lu}\p{Ll}*)?$/

Принимать только латиницу. Сочетание состоит из трёх слов, первые символы заглавные. Между словами фразы должны быть пробелы. Первое слово (фамилия) допускает использования тире в написании (двухсоставная, прим. «Долгоруков-Крымский (Dolgorukov-Krymskij)»). На самом деле для поля ввода ФИО так себе идея применять регулярные выражений и достаточно было бы ввести ограничение по длине вводимых символов. Однако предположил что в требованиях к проекту на данное поле это применяется по требованиию Заказчика.

Для даты рождения использован шаблон:

/^([0-2^([0-2][0-9]|(3)[0-1])(\.)(((0)[0-9])|((1)[0-2]))(\.)\d{4}$/

Вроде как поле должно принимать формат вида ДД.ММ.ГГГГ. Вот это как раз «вроде должно» проверяется при проведении тестирования. Соответствует это реализации или нет. Интересно где-то в функциональной спецификации на проект пишут такие требования сразу в виде таких паттернов?

Для телефона получилось что-то вроде такого:

/^((8|\+7)[\- ]?)?(\(?\d{3}\)?[\- ]?)?[\d\- ]{7,10}$/

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

Сегодня цель проверить работу регулярных выражения позетивными автотестами второстепенна. Основная — при помощи средств автоматизации заполнить форму заранее подготовленными (сгенерированными) данными и отправить с учётом защиты от ботов.

Буду использовать бесплатную версию системы автоматизации BAS (Browser Automation Studio). Показывать полную автоматизацию заявленной цели не буду. В BAS есть модуль интеграции распознавания капчи с платными сервисами, но эксплуатировать детский индийский труд (1,5-2,0$ за 1000 итераций по распознаванию) нет настроения. Равно как и делать инструкцию по намеренному заспамливанию какого-нибудь ресурса в три клика.  Генерировать данные буду используя собственные написанные макросы в excel.

Ниже видео. Показан процесс создания скрипта в BAS и как подтверждения его работы — уведомление на почту о новых сообщениях.

Содержание для зарегистрированных пользователей. Чтобы увидеть скрытую часть контента вам нужно зарегистрироваться или войти под своей учётной записью.

Последовательность:

  1. Сгенерировали тестовые данные согласно типам заполняемых полей;
  2. В BAS создали ресурс для подготовленных данных;
  3. Прикрутили ресурсы к скрипту (как данные вставляемые в поля);
  4. Распознали капчу в ручном режиме;
  5. Отправили данные;
  6. Получили подтверждение на email .

Данные берутся построчно и последовательно из txt файлов до того момента пока в одной из них не закончатся строки с записями. (генерировал одинаковое количество — 30 позиций по всем типам).

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

В 2017 году баловался с BAS, делал чекеры с регерами почты (mail.ru, gmail и yandex). До сих пор иногда пользуюсь своим чекером валидности проксей. Простой — берёт ip:port подставляет в запрос api на сервис, с response чекает результат по .match(«some_param»), валид складывает в txt.

Удачи!