Тестирование формы ввода номера телефона

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

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

Например:

• Форму вообще невозможно заполнить, потому что данные в поля не вводятся
• При отправке уже заполненной формы появляется непонятное сообщение об ошибке
• При вводе пробела и нажатии на Enter приложение зависает, пользователь получает сообщение, что форма отправлена, но информация никуда не отправляется.

Бывают и такие ошибки, о которых пользователь не подозревает, потому что они возникают внутри приложения. Например, в заявке на кредит пользователь вместо номера телефона указал адрес регистрации, и банковские службы с ним не смогли связаться. Или вместо русских букв написал фамилию латинскими, и его заявка не была рассмотрена. Такие ошибки могут иметь серьезные негативные последствия как для пользователя, так и для бизнеса. Чтобы не допустить этого, веб-формы необходимо тестировать.

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

С чего начать тестирование веб-формы

Сначала необходимо определить, с какой именно формой мы имеем дело. Формы могут состоять как из двух-трех полей, так и из нескольких десятков, с разными форматами ввода данных.

Рассмотрим стандартную веб-форму. Там почти наверняка будут поля для ввода информации: имени, фамилии, адреса почты. Такие поля называются текстовыми. Пользователь может ввести буквы, цифры и символы. Какими конкретно данными может быть заполнено поле, решают на этапе разработки.

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

Позитивное тестирование

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

Как правило, текстовые поля подразумевают ввод следующих данных: фамилия, имя, адрес, логин, комментарий. В нашем поле будет фамилия.

Проверки для текстового поля разделим на две категории:

• Проверки допустимого количества символов в поле. Например, в поле можно ввести только 30 букв
• Проверки ввода допустимых символов, то есть букв, цифр, специальных символов.

Для тестирования количества символов в текстовом поле проводятся следующие тесты:

1. Среднее количество символов в поле: Иванов
2. Минимальное количество символов в поле: И
3. Максимальное количество символов в поле: Ивановпертровсидоргончаровпушкинлермонтов
4. Ноль символов: если поле необязательно для заполнения.

Для проверки ввода допустимых символов применяют следующие тесты:

• Буквы, цифры, специальные символы
• Текст с пробелом: в начале строки, в середине и в конце
• Можно вставить в поле скопированный текст
• Перенос строки внутри поля через Enter.

При тестировании важно учесть, что некоторые поля могут оставаться пустыми, а некоторые обязательны для заполнения. Например, логин при регистрации или номер телефона при заказе товара. Такие поля всегда отмечены астерисками (звездочками). Без указания в них информации невозможно отправить форму для обработки. Тестировщик должен убедиться, что при незаполнении обязательного поля появляется сообщение об ошибке. Можно сделать общую проверку сразу для всех полей: не заполнив веб-форму, нажать на кнопку «Продолжить» или «Отправить».

Негативное тестирование

После проведения позитивного тестирования нужно проверить негативные сценарии: когда пользователь указывает некорректные значения в поле и приложение сообщает ему об ошибке или вообще не позволяет ввести данные.

Негативных сценариев в тестировании обычно больше, чем позитивных. Правильный вариант закреплен в требованиях, и он может быть только один. А вот вариантов, отличных от него, может быть много: цифры, символы, английские буквы, иероглифы и т. д. Каждый из таких вариантов тестировщик должен проверить отдельно.

Время на тестирование всегда ограничено, да и протестировать все вероятные негативные сценарии просто невозможно. В этом случае можно ориентироваться на своего «целевого» пользователя, для которого создается веб-форма, а также на здравый смысл. Исходя из этого тестировщик выбирает наиболее вероятные негативные сценарии. Например, если в поле можно вводить только русские буквы, какова вероятность того, что пользователь в России введет английские буквы? Достаточно высокая, учитывая английскую раскладку на всех клавиатурах страны. А что насчет китайских иероглифов? Вероятность их попадания в поле в русскоязычном сегменте невысока, поэтому их проверкой можно пожертвовать в целях экономии времени.

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

• Количество символов меньше минимального
• Количество символов больше максимального
• Символы, ввод которых требованиями не предусмотрен
• Текст с пробелом: в начале строки, в середине и в конце
• Только пробел
• Символы не ASCII (например, эмоджи) — ♣☺♂

Далее для тестирования текстового поля можно применять уже более специализированные проверки, например, связанные с использованием SQL инъекций, XSS, html-тегов. Такие проверки предназначены для тестирования безопасности приложения. Каждое поле — это своего рода путь внутрь приложения: информация, переданная пользователем, записывается в базу данных. Поэтому нужно проверить, что в поле нельзя ввести ничего, что может навредить базе данных и другим частям приложения.

Читайте также:
Как пройти собеседование на тестировщика: все этапы и вопросы

При тестировании текстовых полей могут встретиться следующие ошибки:

• Обязательные поля можно оставить пустыми
• Отсутствие сообщения об ошибке, если пользователь вводит некорректные данные
• Запрет ввода дефиса — пользователи с двойным именем или фамилией не могут заполнить данные о себе
• Ограничение по количеству символов — может не поместиться полностью имя, фамилия, адрес
• Минимальное количество символов в поле 3 символа — пользователи с фамилиями из двух букв не смогут подать заявку
• Отсутствие ограничения на количество символов — можно ввести очень большой текст и нарушить работу системы.

В веб-формах бывают не только текстовые поля. После ввода имени, фамилии, адреса или логина может потребоваться ввести числовые данные: возраст, количество чего-либо и тому подобное. Как тестировать такие поля?

Тестирование числового поля

Снова начинаем с позитивных сценариев: проверяем, что поле работает в соответствии с требованиями. Как и в случае с текстовыми полями, учитывается количество символов и содержание этого поля:

• Среднее количество символов в поле: 111111
• Минимальное количество символов в поле: 1
• Максимальное количество символов: 7490237407235192389273409720394729734
• Ноль символов: если поле необязательно для заполнения
• Цифры
• Положительные числа
• 0 как число.

Негативными сценариями могут быть:

• Буквы, специальные символы
• Только пробелы
• Пробелы внутри числа
• Отрицательные числа
• Дробные числа
• Степени двойки: 23
• Научная запись чисел: 1Е-10
• Вычисляемые выражения: 2+2

Такие поля, как номер телефона, номер паспорта, номер банковской карты, как правило, относятся к текстовым полям. Требованиями устанавливается, что в эти поля можно вводить только цифры, но сам формат поля — текстовый. Поэтому тестировать отрицательные значения, дробные числа, степени двойки уже не нужно: подобные поля обрабатывают числа как обычные символы и для системы нет разницы между дефисом, нулем, семеркой и т. д.

Последующие проверки зависят от назначения числового поля. Здесь нужно протестировать точные данные, которые важны для работы системы. Допустим, требованиями установлено, что можно добавить от 1 до 10 товаров для покупки. Тогда в поле «Количество товаров» для позитивных тестов будем вводить:

• Среднее значение: 5 шт.
• Минимальное значение: 1 шт.
• На один больше минимального: 2 шт.
• Максимальное значение: 10 шт.
• На один меньше максимального: 9 шт.

Для негативных тестов можно использовать следующие данные:

• Меньше минимального, в данном случае ноль: 0 шт.
• Больше максимального: 11 шт.
• Отрицательное значение:  — 5 шт.
• Буквы, специальные символы.

Самые частые ошибки в числовых полях:

• Обязательные поля можно оставить пустыми
• Нет сообщения об ошибке, если пользователь вводит некорректные данные
• Можно вводить буквы и специальные символы в поле «Номер телефона» и другие подобные поля
• Нет ограничения на количество символов в полях: можно ввести несколько тысяч знаков и повредить работу приложения.

На скриншоте пример одного из дефектов: отсутствует сообщение об ошибке, когда поле «Номер телефона» заполнено буквами и символами.

Чек-боксы и радиокнопки

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

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

Подведем итоги

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

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

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

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

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Текстовое поле в приложении кажется таким обычным делом, однако это одна из наиболее важных вещей, которую мы можем протестировать. Почему? Потому что текстовые поля дают доступ к приложению и его базе данных. Валидация текстового поля – это то, что предотвращает появление в базе плохих данных. Эти данные могут вызвать разнообразные проблемы для пользователей и разработчиков. Валидация также предотвращает атаки межсайтового скриптинга и SQL-инъекции.

Тестировать текстовое поле можно миллионами способов, и я коснусь этих способов в статье. Для начала давайте представим, что мы тестируем текстовое поле, не имея никакой информации о том, что оно делает:

• Нажмите Submit, ничего не заполняя.
• Нажмите пробел несколько раз, находясь в поле, а затем нажмите Submit.
• Посмотрите, сколько символов можно ввести в текстовое поле, а затем нажмите Submit (отличный инструмент для подсчета символов — https://lettercount.com).
• Заполните поле максимальным количеством цифр, а затем нажмите Submit.
• Введите минус, заполните поле максимальным количеством цифр, и нажмите Submit.
• Введите все спецсимволы клавиатуры и нажмите Submit. Если вы получите ошибку, попытайтесь разобраться, какой символ или символы ее вызывают.
• Введите символы, не относящиеся к ASCII, и эмоджи, и нажмите Submit. Если вы получите ошибку, попытайтесь разобраться, какой символ или символы ее вызывают.
• Попробуйте межсайтовый скриптинг – введите такой скрипт: <script>alert(«I hacked this!»)</script>. Если при нажатии на Submit появится всплывающее окно – значит, поле уязвимо для XSS-атаки.
• Попробуйте ввести SQL-инъекцию, например, FOO’); DROP TABLE USERS; (не делайте этого на базе данных прода!).

Затем давайте предположим, что мы что-то знаем о том, что должно вводиться в это поле, и каковы ограничения для данных:

• Попробуйте ввести значение с типом данных, отличным от ожидаемого – к примеру, если поле ожидает ввода стоимости, попробуйте ввести текст или дату.
• Если поле ожидает строку, попробуйте ввести строку на 1 символ короче, чем нужно, на 1 символ длиннее, чем нужно, минимально возможное количество символов, максимальное их количество, и количество, вдвое превышающее максимум.
• Если поле ожидает числа, попробуйте ввести максимум, минимум, значение выше максимума и ниже минимума, и значение, вдвое превышающее максимум.
• Если поле ожидает целого числа, попробуйте ввести десятичную дробью.
• Если поле ожидает числа с плавающей точкой, попробуйте ввести значение с двумя запятыми и значение, начинающееся с запятой.
• Если поле ожидает стоимости, попробуйте ввести значение с более чем двумя знаками после запятой.
• Если поле ожидает даты, попробуйте ввести максимальную дату, минимальную дату, на день больше максимума и на день меньше минимума, и дату на сто лет больше или меньше границ.
• Для полей дат попробуйте ввести бессмысленную дату – например, 6/31/17 or 13/13/17 (есть много способов тестировать поля дат, я затрону этот вопрос в другой статье).
• Если поле ожидает времени, попробуйте ввести бессмысленное время – например, 25:15.
• Если поле ожидает номера телефона, попробуйте ввести номер, не соответствующий ожидаемому формату (множество способов тестирования номеров я тоже затрону в другой статье).

Для всех вышеописанных тестов выясните, какое сообщение об ошибке вы должны получать, и убедитесь, что получаете правильное сообщение.

И, наконец, нужно подумать об автоматизации. Если вы тщательно протестировали ваше поле вручную, то, возможно, нет необходимости автоматизировать все ваши тесты. Более того, большинство форм имеют более одного поля ввода, и куча тестов для каждого отдельного поля – это куча потраченного времени на прогон. Вот несколько советов, что можно автоматизировать:

• Ввод нулевого значения.
• Ввод пустоты.
• Ввод значения, удовлетворяющего критериям («счастливый сценарий»).
• Ввод максимальной длины или максимального значения.
• Ввод минимальной длины или минимального значения.
• Ввод значения, превышающего максимальную длину или допустимый максимум.
• Ввод значения меньше минимума.

Это не исчерпывающий список, а просто способ подтолкнуть вас к размышлениям о большом количестве тестов, которые можно прогнать, тестируя единственное поле. Не верьте на слово, что разработчик, создававший поле, добавил нужную валидацию, проверьте ее сами! Как-то раз я тестировала поле ввода даты, у которого было ограничение на год – он не мог быть меньше 1900 или больше, чем текущий год. Я получала нужное сообщение об ошибке, вводя 1880, но даты 1300 года легко принимались!

Обсудить в форуме

I suggest you look to use* a test pyramid pattern with something like

                1 manual UI test
              2 automated UI tests
            10 automated Unit tests

The manual test is to look at the page and see if anything seems amiss. This will cover the styles verification plus a lot more.
The automated UI tests should cover the happy path, one sad path and 1 optional path. So: (1 case) happy — payment works, sad (2 cases) — amount is invalid, e.g. alpha and amount is blank.

For the unit cases it will actually depend on the technology:

If using a HTML POST form you can do the unit testing on the server side to make sure it handles all error conditions correctly and passes the correct error code / message to the web application.

If you are using AJAX however, with client-side testing you can do the testing of the form validations directly on the page itself using Jasmine. In fact even without ajax and js you could use Jasmine to verify that the client-side validations are working correctly. Try to make sure that you use HTML5 client side validations whenever possible as you know these should work without testing (after all if u find a bug what do u do?). The need to test will depend on several factors, mostly related to business need to know if it breaks.

The key thing is to design a fast system with as few automated UI test as possible (I mean in favor of non-UI tests which can run 100+ times faster). The few automated tests that do get created should be chosen very carefully and never from a list of ‘check condition a,b,c,d, whatever else we can think of’ or you end up with massive UI test suites that takes hours and days to run in all the different devices and browsers.

Update:

* Originally I said ‘create a test pyramid’. This might be a bit too high level. What I meant was the the test pyramid principle should guide your actions and where to test. This should be adding (not ‘creating’) to the test pyramid approach.

I suggest you look to use* a test pyramid pattern with something like

                1 manual UI test
              2 automated UI tests
            10 automated Unit tests

The manual test is to look at the page and see if anything seems amiss. This will cover the styles verification plus a lot more.
The automated UI tests should cover the happy path, one sad path and 1 optional path. So: (1 case) happy — payment works, sad (2 cases) — amount is invalid, e.g. alpha and amount is blank.

For the unit cases it will actually depend on the technology:

If using a HTML POST form you can do the unit testing on the server side to make sure it handles all error conditions correctly and passes the correct error code / message to the web application.

If you are using AJAX however, with client-side testing you can do the testing of the form validations directly on the page itself using Jasmine. In fact even without ajax and js you could use Jasmine to verify that the client-side validations are working correctly. Try to make sure that you use HTML5 client side validations whenever possible as you know these should work without testing (after all if u find a bug what do u do?). The need to test will depend on several factors, mostly related to business need to know if it breaks.

The key thing is to design a fast system with as few automated UI test as possible (I mean in favor of non-UI tests which can run 100+ times faster). The few automated tests that do get created should be chosen very carefully and never from a list of ‘check condition a,b,c,d, whatever else we can think of’ or you end up with massive UI test suites that takes hours and days to run in all the different devices and browsers.

Update:

* Originally I said ‘create a test pyramid’. This might be a bit too high level. What I meant was the the test pyramid principle should guide your actions and where to test. This should be adding (not ‘creating’) to the test pyramid approach.

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

Валидация полей формы с помощью HTML

Самый простой, но не самый эффективный способ — это валидация полей формы через стандартные свойства полей HTML.

Поле обязательно к заполнению

<input type="text" name="name" required>

Проверка ввода Email

<input name="email" required pattern="[email protected][a-z]+.[a-z]+">

Проверка ввода телефона

<input type="tel" name="phone" pattern="^((8|+7)[- ]?)?((?d{3})?[- ]?)?[d- ]{7,10}$" required />

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

<input type="text" name="message" minlength="30" maxlength="2000" />

Проверка ввода только букв

<input type="text" name="message" pattern="[A-zА-яЁё]" />

Проверка ввода только цифр

<input type="text" name="message" pattern="[0-9]" />

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

Валидация полей формы с помощью JavaScript

Наиболее сложный способ валидации на чистом JavaScript на примере простой формы обратной связи:

<form action="" name="callback" onsubmit="return(validate());">
	<input type = "text" name="name" placeholder="Имя"/><br>
	<input type = "text" name="lastname" placeholder="Фамилия" /><br>
	<input type = "text" name="email" placeholder="E-mail"/><br>
	<select name="topic">
		<option value="-1" selected>[Выберите тему обращения]</option>
		<option value="1">Техническая поддержка</option>
		<option value="2">Реклама</option>
		<option value="3">Сообщить об ошибке</option>
	</select>
<input type="submit" value="Отправить" />
</form>      

Обращаем внимание на то, что в свойствах формы указан параметр onsubmit=»return(validate());», что позволит выполнить функцию validate() перед отправкой формы. Теперь собственно сама функция проверки:

<script>
   <!--
      // Проверка заполненности полей формы.
      function validate() {
      
         if( document.callback.name.value == "" ) {
            alert( "Укажите имя" );
            document.callback.name.focus() ;
            return false;
         }
         if( document.callback.email.value == "" ) {
            alert( "Заполните Email" );
            document.callback.email.focus() ;
            return false;
         } 
           if( document.callback.lastname.value == "" ) {
            alert( "Укажите фамилию" );
            document.callback.lastname.focus() ;
            return false;
         }
         if( document.callback.topic.value == "-1" ) {
            alert( "Пожалуйста, выберите темы обращения" );
            return false;
         }
         return( true );
      }
   //-->
</script>

к содержанию ↑

Проверка формата E-mail

function ValidMail() {
    var re = /^[w-.][email protected][w-]+.[a-z]{2,4}$/i;
    var myMail = document.getElementById('email').value;
    var valid = re.test(myMail);
    if (valid) output = 'Адрес эл. почты введен правильно!';
    else output = 'Адрес электронной почты введен неправильно!';
    document.getElementById('message').innerHTML = output;
    return valid;
}

Проверка формата телефона

function ValidPhone() {
    var re = /^d[d() -]{4,14}d$/;
    var myPhone = document.getElementById('phone').value;
    var valid = re.test(myPhone);
    if (valid) output = 'Номер телефона введен правильно!';
    else output = 'Номер телефона введен неправильно!';
    document.getElementById('message').innerHTML = document.getElementById('message').innerHTML+'<br />'+output;
    return valid;
}  

Валидация полей формы с помощью плагина jQuery Validation Plugin

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

Этот плагин позволяет легко проверять формы на стороне клиента, и предлагает множество вариантов настроек. Для начала подключаем jQuery и jQuery Validation.

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>
<script src="https://cdn.jsdelivr.net/jquery.validation/1.16.0/jquery.validate.min.js"></script>

Затем простенькая форма для примера:

<form action="" name="callback" >
	<input type = "text" name="name" placeholder="Имя"/><br>
	<input type = "text" name="lastname" placeholder="Фамилия" /><br>
	<input type = "text" name="email" placeholder="E-mail"/><br>
	<select name="topic">
		<option value="-1" selected>[Выберите тему обращения]</option>
		<option value="1">Техническая поддержка</option>
		<option value="2">Реклама</option>
		<option value="3">Сообщить об ошибке</option>
	</select>
<input type="submit" value="Отправить" />
</form>      

Теперь давайте запустим проверку валидации при попытке отправить форму:

$('form[name="callback"]').validate({
  rules: {
    name: 'required',
    lastname: 'required',
    email: {
      required: true,
      email: true,
    },
    topic: 'required',
  },
  messages: {
    name: 'Укажите имя',
    lastname: 'Укажите фамилию',
    email: 'Укажите правильный E-mail',
    topic: 'Выберите тему обращения'
  },
  submitHandler: function(form) {
    form.submit();
  }
});

Как видно, после проверки формы на валидацию, происходит её отправка методом form.submit();

Способов валидации форм на стороне клиента, а именно поля ввода номера телефона (инпута) существует несколько, как и на стороне сервера. Для этих целей существуют специальные jQuery плагины, типа Inputmask, которые легко подключить и легко использовать. Но в этой статье мы их рассматривать не будем, а будем производить валидацию телефона при помощи регулярного выражения и совсем маленькой функции, которую можно будет использовать в последующем и других проектах. Для демонстрации предлагаю посмотреть и протестировать пример.

Демо

Валидация номера телефона на JS

Самое основное в этом деле — регулярное выражение (regex), которое, к счастью, не нужно придумывать самому, а просто взять готовое и внедрить. Сразу скажу, что данная регулярка проверяет российские номера телефонов. Первая конструкция, которую мы рассмотрим, выглядит так:

1
2
3
4
5
6
7
8

let regex = /^(+7|7|8)?[s-]?(?[489][0-9]{2})?[s-]?[0-9]{3}[s-]?[0-9]{2}[s-]?[0-9]{2}$/;
let phone = '89000000000';
// дальше идет проверка на соответствие выражению
if(!regex.test(phone){
console.log('Не соответствует');
}else{
console.log('Соответствует');
}

То же самое можно записать в функцию валидации и вызывать ее где угодно в коде.

1
2
3
4
5
6
7
8
9
10
11
12

function validatePhone(phone){
 let regex = /^(+7|7|8)?[s-]?(?[489][0-9]{2})?[s-]?[0-9]{3}[s-]?[0-9]{2}[s-]?[0-9]{2}$/;
 return regex.test(phone);
}
// Вызов функции
let phone = '89000000000';
 
if (!validatePhone(phone)){
  console.log('Не соответствует');
}else{
  console.log('Соответствует');
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

89000000000
+79000000000
8-900-000-00-00
+7-900-000-00-00
8(900)0000000
8(900)000 00 00
+7 (900) 000 00 00
8(900)-000-00-00
+7(900)-000-00-00
+7(900)000-00-00
8 900 000 00 00
+7 900 000 00 00
8-(900) 000 00 00
+7-(900) 000 00 00
8-(900)-000-00-00
+7-(900)-000-00-00
7(999)999 99 99
79000000000
7-900-000-00-00
7-(900)-000-00-00
7(900)-000-00-00
7(900) 000 00 00
7 (900)-000-00-00
7 (900) 000 00 00
7 900 000 00 00
8000000000
9000000000
800 000 00 00
900 000 00 00
800-000-00-00
900-000-00-00
(800)-000-00-00
(900)-000-00-00

Валидация телефона на jQuery

Здесь все в точности то же самое, но пройдемся по HTML коду и разберем по полочкам все элементы, чтобы было более понятно. Допустим у нас есть вот такой инпут:

<input type="tel" class="input"/>

Затем пишем jQuery код.

1
2
3
4
5
6
7

let phone = $('.input').val(); // Получаем значение input
let regex = /^(+7|7|8)?[s-]?(?[489][0-9]{2})?[s-]?[0-9]{3}[s-]?[0-9]{2}[s-]?[0-9]{2}$/;
if(!regex.test(phone){
console.log('Не соответствует');
}else{
console.log('Соответствует');
}

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

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

Давайте попробуем собрать стандартную форму, которая будет включать в себя: Имя, E-Mail, Телефон, Ссылку на сайт и допустим Ваш рост, чтобы поэксперементировать с числовым полем.

<form action="#" class="form">
	<input type="text" name="name" placeholder="Имя" />
	<input type="text" name="email" placeholder="E-Mail" />
	<input type="text" name="phone" placeholder="Телефон" />
	<input type="text" name="url" placeholder="Ваш сайт" />
	<input type="text" name="growth" placeholder="Ваш рост" />
	<button type="submit">Отправить</button>
</form>

HTML5

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

Самый простой путь валидации — это определить тип input поля и расставить атрибуты required которые отвечают за обязательность заполнения.

<form action="#" class="form">
	<input type="text" name="name" placeholder="Имя" required />
	<input type="email" name="email" placeholder="E-Mail" />
	<input type="tel" name="phone" placeholder="Телефон" />
	<input type="url" name="url" placeholder="Ваш сайт" />
	<input type="number" name="growth" placeholder="Ваш рост" />
	<button type="submit">Отправить</button>
</form>

Применение этих двух атрибутов позволит гораздо эффективнее валидировать вводимую информацию нативными методами. Ну и конечно же поддержка этих свойств браузерами наиболее широка.

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

Однако, нам на помощь приходит атрибут pattern. Этот атрибут принимает в себя значение регулярного выражения. В нашем случае рассмотрим вариант паттерна для ввода мобильного телефона в РФ: +7 (123) 456-78-91. Для этого добавим простое регулярное выражение в наше поле с телефоном, а также ограничим минимальное и максимальное количество символов:

<input type="tel" name="phone" placeholder="Телефон"  pattern="[+]d{1}s[(]d{3}[)]sd{3}[-]d{2}[-]d{2}" minlength="18" maxlength="18" />

Обычно я использую данный паттерн в связке с маской для ввода номера, но тут к сожалению без JS пока что не обойтись. Если вы не используете маску, то я бы не стал использовать паттерны на вводе телефона, поскольку это в большинстве случаев вызовет больше неудобств для пользователя.

Поддержка браузерами атрибута pattern на данный момент очень хорошая. iOS начиная с версии 10.3 полностью поддерживает данное свойство, до этого наблюдалось отсутствие подсказок о неправильном вводе данных.

Стоит также учитывать, что атрибут minlength до сих пор не поддерживается в браузерах IE, EDGE и только с версии 10.3 появился в iOS. Однако maxlength поддерживается везде и очень давно. Нам в целом хватит и этого.

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

<input type="number" name="growth" placeholder="Ваш рост" min="100" max="250" />

С поддержкой этих атрибутов в браузерах, все хорошо.

Перейдем к стилизации!

CSS3

Для того чтобы кастомно стилизовать нашу валидацию, воспользуемся псевдоклассами :invalid и :valid. Поддержка этих псевдоклассов в браузерах позволяет использовать их максимально широко на данный момент.

input:invalid {border-color: red;}
input:valid {border-color: green;}

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

Мы можем пойти на небольшую хитрость и использовать псевдокласс :placeholder-shown. С помощью этого псевдокласса мы можем определить отображается ли сейчас значение placeholder в нашем поле ввода. Атрибут placeholder отображается только тогда, когда в наше поле ничего не введено. Соответственно, чтобы применить этот псевдокласс нам просто нужно обратить его свойство с помощью :not. В итоге получаем вот такую конструкцию:

input:invalid:not(:placeholder-shown) {border-color: red;}
input:valid:not(:placeholder-shown) {border-color: green;}

Если прочитать дословно: окрасить красным цветом границу инпута, когда наше поле не валидно и когда в нем не отображается значение атрибута placeholder. Если ваше поле не имеет атрибута placeholder, можно просто поставить внутри пробел:

<input type="text" placeholder=" " />

У данного метода есть только один минус: поддержка. Псевдоэлемент :placeholder-shown поддерживается во всех браузерах кроме IE и EDGE. К счастью :not не обладает таким недостатком.

Для примера я набросал все вышесказанное в CodePen и добавил еще немного возможностей:

Итог

Таким образом, не прибегая к JS мы с помощью двух строк в CSS смогли стилизовать и валидировать форму. На текущий момент такая конструкция будет хорошо работать в большинстве браузеров, к сожалению, как всегда, веб-разработку подводят детища Microsoft.