Если форма отклоняет телефон или email, который выглядит корректно, не ослабляйте регулярное выражение наугад. Сначала определите слой отказа: HTML, JavaScript, серверное приложение, внешний API или база данных.
Быстрее всего это сделать с помощью матрицы правил. Для каждого поля зафиксируйте допустимый ввод, преобразования, обязательность и сообщение об ошибке, а затем прогоните одинаковые тестовые значения через все слои.
Сначала найдите точку отказа
Откройте форму в чистом сеансе браузера и повторите проблему с тестовыми данными. В инструментах разработчика посмотрите, появился ли сетевой запрос после нажатия кнопки.
- Запроса нет, браузер показывает стандартную подсказку. Проверьте атрибуты поля:
type,required,pattern,minlengthиmaxlength. - Запроса нет, но сообщение оформлено сайтом. Ошибка, вероятно, возникает в JavaScript-валидаторе или маске ввода.
- Запрос ушёл, сервер вернул ошибку поля. Сравните отправленное значение с backend-правилом и контрактом API.
- Сервер сообщил об успехе, но заявка не появилась. Ищите сбой после валидации: ограничение БД, откат транзакции, очередь или интеграцию.
- Ошибка появляется только после ответа внешнего сервиса. Отделите локальную проверку формата от правил провайдера и корректно покажите пользователю источник отказа.
Не ориентируйтесь только на текст подсказки: одна и та же фраза «неверный формат» может скрывать разные проверки.
Составьте матрицу правил
Минимальная матрица помещается в обычную таблицу:
| Поле | Бизнес-правило | Нормализация | HTML/JS | Backend | Хранение | Код ошибки | |---|---|---|---|---|---|---| | Телефон | Для какого региона и сценария нужен номер | Какие пробелы и знаки убираются | Маска и подсказка | Допустимый итоговый формат | Каноническое значение | Стабильный код поля | | Email | Для чего нужен адрес и требуется ли подтверждение | Обработка пробелов по краям | type=email и клиентская проверка | Серверная проверка синтаксиса | Поле достаточной длины | Стабильный код поля |
Сначала запишите смысл поля. Если номер нужен для обратного звонка, команда должна договориться о поддерживаемых странах и о том, обязательный ли код страны. Если email используется для входа или уведомлений, отдельно решите, нужно ли подтверждение адреса. Эти решения нельзя надёжно вывести из одной регулярной строки.
Матрица быстро обнаруживает противоречия: маска разрешает пробелы, а backend запрещает их; браузер принимает адрес, а сервер использует другое правило; frontend считает поле необязательным, а БД не принимает пустое значение.
Прогоните один набор значений через все слои
Соберите небольшой набор положительных, граничных и отрицательных примеров. Используйте только специально подготовленные тестовые данные, без телефонов и адресов клиентов.
Для телефона проверьте согласованные варианты со знаком «+», пробелами, скобками, дефисами, вставкой из буфера и вводом с мобильной клавиатуры. Для email полезны адрес с поддоменом, знак «+» в локальной части, разные регистры, пробелы по краям и заведомо ошибочный вариант без обязательных частей.
Для каждого примера сохраните четыре результата:
- что ввёл пользователь;
- какое значение осталось в поле после маски;
- что фактически ушло в запросе;
- что проверил и вернул сервер.
Если визуально одинаковые строки ведут себя по-разному, покажите управляющие и пробельные символы в безопасной тестовой среде. Не записывайте исходные пользовательские контакты в открытый лог.
Не смешивайте нормализацию с валидацией
Нормализация приводит разрешённый ввод к согласованному виду. Валидация отвечает, допустим ли результат. Если эти этапы смешаны, форма может незаметно изменить данные либо отклонить значение, которое другой слой уже преобразовал.
Для телефона сначала определите разрешённые декоративные символы, затем получите каноническое значение и только после этого применяйте серверное правило. Для email обычно безопасно отдельно обработать ожидаемые пробелы по краям, но нельзя молча удалять символы внутри адреса ради прохождения проверки.
Синтаксически допустимый email ещё не доказывает, что ящик существует или принимает письма. Подтверждение ссылкой или кодом — отдельный бизнес-процесс, а не причина ужесточать поле непонятным шаблоном.
Сделайте backend источником истины
Клиентская проверка нужна для быстрой подсказки, но запрос можно отправить без интерфейса браузера. Поэтому окончательное решение принимает сервер, а frontend должен повторять только те ограничения, которые помогают пользователю исправить ввод до отправки.
Возвращайте машинный код ошибки и имя поля отдельно от текста. Тогда сайт, мобильное приложение и интеграция смогут одинаково обработать отказ, а текст подсказки можно менять без поломки контракта.
Один и тот же набор тестовых значений стоит запускать против клиентского и серверного валидаторов. При изменении правила такой контрактный тест сразу покажет, какой слой остался на старой версии.
Проверьте всю цепочку после исправления
Успешная зелёная подсветка поля — ещё не конец проверки. Убедитесь, что:
- положительный пример отправляется и создаёт ожидаемую запись;
- отрицательный пример отклоняется у нужного поля с понятным сообщением;
- повторный клик не создаёт дубликат;
- уведомление или подтверждение запускается, если оно предусмотрено;
- вставка, автозаполнение и мобильный ввод не меняют результат;
- сервер не сохраняет частичную заявку после ошибки;
- диагностические логи не содержат контактов и других персональных данных.
Проводите такие проверки на тестовом контуре. В production достаточно воспроизвести только безопасный сценарий, который не создаёт фиктивную заявку и не отправляет сообщение реальному человеку.
Что даёт мониторинг, а что нужно тестировать отдельно
Web-Puls помогает регулярно проверять доступность публичной страницы формы и быстрее заметить, если она перестала отвечать. Но обычная проверка URL не заполняет поля и не доказывает, что конкретный телефон или email будет принят.
Для критичной формы нужен отдельный безопасный сценарий: тестовые данные, изолированный получатель и явная очистка созданной записи. Такой тест должен проверять бизнес-результат, а не только ответ страницы.
Что делать дальше
Если правило разбросано между шаблоном, JavaScript, backend и интеграцией, начните с матрицы и одного воспроизводимого примера. Она покажет, где расходятся ожидания, и позволит исправить конкретный слой без ослабления всей проверки.
Если отказ появился после обновления или безопасного тестового контура нет, можно отправить заявку на профессиональную диагностику. Укажите публичный адрес формы, время и часовой пояс, точные шаги, ожидаемый результат и очищенный от персональных данных ответ из Network; логины и реальные контакты передавать не нужно.