Тестирование поля номера телефона

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

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

Например:

• Форму вообще невозможно заполнить, потому что данные в поля не вводятся
• При отправке уже заполненной формы появляется непонятное сообщение об ошибке
• При вводе пробела и нажатии на 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 шт.
• Буквы, специальные символы.

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

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

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

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

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

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

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

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

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

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

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

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.

Автор: Кристин Джеквони (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 года легко принимались!

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

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

Валидация полей формы с помощью 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();

$("form#myForm").submit(function(event) {
        event.preventDefault();
        var phone_input = $(this).find("input[type=tel]");
        var phone_number = phone_input.val().replace(/[^0-9]/g,"");

        if (phone_number.length === 0 ) {
            phone_input.notify("Введите номер телефона", {position:"bottom" , className: 'error'})
        }

        if (phone_number.length < 12 && phone_number.length >= 4) {
            phone_input.notify("Номер введён не полностью", {position:"bottom" , className: 'warn', gap: 0, autoHideDelay: 3000});
        }
        if (phone_number.length === 12) {
            var data = $(this).serializeArray();
            data.push ({name: 'href', value: href}); //-можешь добавить дополнительные переменные, например адрес страницы, referer
            data.push ({name: 'ref', value: ref});
            var thisForm = $(this);
            var thisBtn = thisForm.find("button");
            $.ajax({
                url: 'php/mail.php',
                type: 'POST',
                data: data,
                beforeSend: function(data) {
                    thisBtn.notify("Отправка заявки", {position:"bottom center", className: 'info'});
                },
                success: function(data){
                    console.log(data);
                    thisBtn.notify("Заявка принята", {position:"bottom center", className: 'success'});
                    thisForm.trigger("reset");
                },
                error: function(data) {
                    thisBtn.notify("Ошибка на сервере", {position:"bottom center", className: 'error'} );
                    thisForm.trigger("reset");
                }
            });
            return false;
        }
    });

    var href          = window.location.href;
    var ref = document.referrer;

//-notify - красивые уведомления, скачать библиотеку можешь з<a href="https://notifyjs.jpillora.com/"></a>десь, если не нужно просто убери
<img src="https://habrastorage.org/webt/5c/a3/0d/5ca30d6fd6f1f287377378.png" alt="image"/>

Поле для ввода телефонного номера

Специальное поле, упрощающее ввод телефонного номера.

Когда использовать

Используйте специальное поле для ввода телефона, когда нужен номер в полном формате.

Описание работы

Размер и расположение

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

Рекомендуемая ширина поля — 160 px.

Фокус и работа с клавиатурой

При клике по полю и при переходе табом поле выглядит одинаково: появляется чёрная рамка и, если поле не заполнено — маска, которые сохраняются до потери фокуса.

Валидация