Поле email должно содержать уникальное значение что это значит?

6 ответов на вопрос “Поле email должно содержать уникальное значение что это значит?”

  1. Thorgaghma Ответить

    Множество сайтов требуют от пользователя ввода адреса электронной почты, и мы, как крутые и щепетильные разработчики, всегда стремимся проверять формат введенных адресов строго по стандартам RFC. Благодаря этому наши приложения и сайты проверяют формат e-mail корректно и не имеют проблем с юзабилити, а мы сладко спим, потому что уверены, что все работает как надо.
    Ага, как бы не так!
    Приведенные выше аргументы звучат круто и железобетонно, но проблема здесь заключается в том, что в адресе почты могут находиться совершенно бессмысленные вещи, и, на деле, проверка адресов по стандартам RFC может, наоборот, все жутко запутать.
    Почему так? Существует множество способов сформировать адрес почты, который будет одновременно и корректным и бредовым. Отчасти это происходит из-за того, что некоторые почтовые службы в целях обратной совместимости позволяют представлять адреса в форматах, которые давно устарели. Например это электронная почта существовавшая до появления DNS и до появления современного формата user@domain.tld: тогда использовались UUCP ”bang path” — адреса, которые представляли собой список всех узлов по маршруту ответственных за доставку.

    Внутренности адреса почты

    Адрес e-mail выглядит так:
    mailbox@hostname
    Тут mailbox может быть локальным аккаунтом пользователя, аккаунтом роли или маршрутизатором автоматизированной системы такой, например, как список рассылки, а в качестве hostname может быть использован любой узел, если о нем известно DNS-серверу, к которому обращается почтовик при доставке.
    Кроме того, некоторые системы позволяют добавлять теги к адресу. Обычно это происходит в формате:
    mailbox+tag@hostname
    где тег и разделитель (обычно это “+”, но qmail использует “-” по-умолчанию, хотя может быть сконфигурирован и иначе) игнорируются при доставке. Обычно это используется для фильтрации почты по папкам и автоматизации, но может быть использовано и для разделения введенных адресов по получателям и выявления злоупотреблений персональными данными.
    Итак, в адресе в формате «mailbox@hostname», «mailbox» является пользовательским аккаунтом, приложением или аккаунтом системной роли, но может содержать и такие экстравагантные вещи, как информацию для дальнейшей маршрутизации или идентификаторы используемые для сортировки, автоматизации или отслеживания, а «hostname» — обычно доменное имя, но может являться и субдоменом, сервером, сервисом, ip-адресом или просто именем хоста.

    Корректные имена ящика с точки зрения RFC

    Специцификация одобряет довольно странные адреса, и было бы накладно поддерживать их все потому, что некоторые слишком сложны, и не слишком много людей обладают достаточными знаниями чтобы выделывать такие пируэты в нейминге. Поддержка таких адресов затруднит поддержку таких аккаунтов вашими сотрудниками, к тому же они почти никогда не используются в быту.
    Ящик может содержать пробелы. Насколько я помню, доинтернетовский AOL разрешал пробелы в «Imya Polzovatelya», которые использовались еще и как почтовые ящики с вырезанными оттуда пробелами: «imyapolzovatelya@aol.com», однако ж согласно RFC вы можете использовать двойные кавычки вокруг ящиков содержащих пробелы:
    “Alan Turing”@example.com < == Это корректно, но поддерживать не стоит Кстати говоря, по этой логике, ящик содержащий всего лишь пробел корректен: " "@example.com <== Это корректно, но смотри выше А вот еще один корректный адрес, он создан из допустимых для адреса символов: !#$%&'*+-/=?^_`{}|~@example.com <== Корректный адрес вряд ли достойный поддержки Кстати, проверяйте апострофы, апострофы должны поддерживаться: Miles.O'Brian@example.com <== Стоит поддерживать Апострофы не должны закавычиваться или эскейпиться, но когда вы сохраняете такие адреса в базу или передаете еще куда-то, убедитесь, что всё чики-пуки. В Википедии есть еще куча примеров. Нужна ли полная совместимость с RFC? Вам выбирать, но я не советую — пробелы и нестандартные символы в адресе довольно необычная штука и чаще всего являются просто опечаткой. Крупные e-mail провайдеры не разрешают использовать это примерно по тем же причинам; таким образом обычно достаточно дозволять буквы, цифры, точки, подчеркивания, дефисы, апострофы и плюсы.

    Регистрозависимые адреса

    Согласно RFC уникальность адреса определяется его регистрозависимой уникальностью, однако 99,9% провайдеров считают иначе и не позволяют регистрировать VasyaPetrov@example.com, если vasyapetrov@example.com уже зарегистрирован. Считайте, что имя почтового ящика регистронезависимо:
    ALLEN@example.com
    Allen@example.com
    allen@example.com
    Небольшая кучка систем использует полную проверку регистра, позволяя лишь адрес Allen@example.com и отбрасывая входящую корреспондецию всех остальных АлЛеНоВ, однако это не работает на практике, поскольку пользователь не привык различать регистр в адресах почты.
    Должны ли вы тут сохранять совместимость с RFC? Конвертируя адреса в нижний регистр перед сохранением вы можете доставить проблем небольшому количеству пользователей (вы не сможете посылать им письма), но отослав миллионы e-mail я столкнулся с этим всего несколько раз.
    Конвертация в адреса в нижний регистр является неплохой идеей в плане нормализации данных, так как домен всегда регистронезависим и должен быть в нижнем регистре. Если же вы решите сохранять адрес так, как он введен, добавьте поле, в котором будет хранить каноническую версию.

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

    Gmail тут отличился: в то время как стандарт включает в себя точку как стандартный символ, Gmail не делает различий между адресами ящиков с точками и без. Эти адреса указывают на один и тот же почтовый ящик:
    first.last@gmail.com
    firstlast@gmail.com
    f.i.r.s.t.l.a.s.t@gmail.com
    Обратите внимание, что Google Apps позволяет использовать Gmail на любом домене.
    Основная проблема здесь заключается в поиске адреса в базе в том виде, в котором он был изначально введен, что может доставить немало геморроя как пользователю, так и службе поддержки, а также и программистам с тестировщиками. Тут то вам и пригодится вторая, канонiческая форма адреса, но об этом позже.

    Расширенная форма названия ящиков с использованием тегов.

    Как было сказано выше, большинство систем доставки электронной почты (MTA), включая sendmail, Postfix, qmail, Yahoo Plus и Gmail поддерживают расширенное название ящика. Это позволяет пользователю, добавляя тег, сортировать письма. Это может позволить мне насоздавать кучу аккаунтов на одном сайте или в приложении:
    allen+one@example.com
    allen+two@example.com
    Но нужно ли вычищать теги из адреса ящика?
    НЕТ! Будьте дружелюбны к своим пользователям, и пользователи проникнутся верой, что вы не осуществите хищение и сбыт их персональных данных с целью наживы. Даже если вы пытаетесь запретить регистрацию дополнительных аккаунтов с существующим ящиком, представьте себе, насколько просто в наше время тупо зарегистрировать еще один ящик чтобы снова зарегистрироваться у вас — не сложнее создания алиаса или папки(но об алиасах, папках и тегах, наоборот, мало кто знает).
    Итак, еще раз. Создание второй, канонической, формы сохранения адреса в базе может неплохо прикрыть вашу за вас в случае неприятностей. Убедитесь, что вы ликвидировали из нее все теги, точки и т. д. и можете сравнивать с ней свежевведенные адреса.

    Юникод и интернационализированные имена ящиков

    Имена ящиков не поддерживают расширенные символы ASCII (8-bit) и символы Юникода. Это ограничение уходит своими корнями в спецификацию SMTP, во времена появления которого всего этого попросту не существовало; однако 8-битные значения, определенные локально, например из кодировок семейства ISO-8859-x, все-таки могут использоваться, но вы все равно никогда не узнаете, что же это за кодировка. Фактически, я видел 8-битные ящики только у спамеров.
    В конце концов, вы ведь храните ваши данные в UTF-8, так? Значит вы в любом случае не сможете перевести их обратно в ту локаль, которая была использована, если вы ее не знаете.

    Доменные имена

    У почтовых доменов те же самые ограничения как и в HTTP: они регистронезависимые, так что их следует нормализовывать в нижний регистр.
    Поддомены
    Некоторые адреса содержат ненужные поддомены: например, «email.msn.com» и «msn.com» являются одним и тем же почтовым доменом, кроме того, такие истории часто случаются в корпоративной среде (и это еще один хороший кандидат для каноникализации).
    Интернационализированные домены (IDN)
    IDN были созданы для того чтобы использовать местные символы Юникода в названиях доменов, кроме того, возможно создать домен и со специальными символами:
    postmaster@>>>>>>>.ws
    этот классно описывает круговорот воды в природе.
    Как и HTTP, SMTP поддерживает лишь 7-битную кодировку, и для того чтобы справиться с этим несчастьем IDN конвертируются в Punycode, что позволяет имени домена конвертироваться в представление Юникод и обратно:
    postmaster@xn--55gaaaaaa281gfaqg86dja792anqa.ws
    Очень жаль, но существует возможность фишинга при использовании IDN. Юникод содержит несколько разных экземпляров некоторых символов ASCII. Это позволяет злоумышленнику создать сайт, название которого выглядит точно также как и оригинал из-за того, что некоторые символы в названии совпадают внешне, но не внутренне.
    Это порождает несколько вопросов на которые следует ответить:
    Должны ли мы дозволять IDN-адреса? Можем ли мы обеспечить саппорт пользователей службой поддержки (откуда у саппорта, например, клавиатуры с китайскими иероглифами?) Должны ли мы сохранять их в Юникоде или Punycode? Если мы сохраняем каноничные адреса, то в какой кодировке это делать? Поддерживает ли вообще наш почтовик (MTA) IDN, и в какой форме он ждет адреса при отправке писем?
    IP Address syntax
    Использование IP-адресов допустимо:
    allen@[127.0.0.1]
    allen@[IPv6:0:0:1]
    Однако такие адреса выглядят подозрительно, и вряд ли им стоит доверять.

    Временные почтовые адреса

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

    Белый список используемых возможностей

    Адреса электронной почты могут быть чудовищно сложными, но, навскидку, 99,99% (а может, и больше) придерживаются простых принципов, а остальные слишком утомительно поддерживать.
    Итак, вам вероятно следует воздержаться от поддержки адреса, если он содержит:
    Зависимость от регистра
    Пробелы
    Кавычки или Эскейп-символы
    Специальные символы кроме ‘._+-
    Айпишники в поле домена
    IDN
    Конечно, это может создать проблемы некоторым пользователям, но и в этом случае они скорее всего попытаются использовать какой-нибудь другой адрес, который подойдет. Кроме того, это позволит вашему саппорту более качественно оказывать поддержку вне зависимости от пользовательской локали.
    Еще я считаю, что вы должны поддерживать теги.
    Если это необходимо, вы можете создать еще одно поле в базе с каноническим адресом, даже если считаете, что всю эту RFC-шную совместимость стоит поддерживать. Адрес в таком поле может быть:
    Приведен в нижний регистр
    Быть без тегов
    Транскодирован из Юникода в ASCII
    Без дублирующихся поддоменов
    Несмотря на то, что этот совет может показаться слишком радикальным, это все равно лучше, чем слепо подчиняться стандартам. Как знать, может когда-нибудь такая упрощенная нотация станет новым стандартом?

  2. Vokus Ответить

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

    Проблемы подтверждения адреса

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

    Многие пользователи не вводят адрес еще раз, а копируют его из уже заполненной формы и вставляют в поле подтверждения. Всякий смысл в этом дополнительном поле теряется, потому что копируются и все совершенные ошибки.
    Как выявили результаты исследования, в 60% случаев пользователи копируют email из одного поля в другое. Они поступают так, потому что вводить адрес еще раз — слишком долго и сложно. Пользователи также верят что просто не могут неправильно ввести свой адрес, и очень удивляются, когда это происходит.
    Итак, поле подтверждения адреса не решает проблему случайных ошибок при вводе. Более того, оно заставляет пользователей делать больше манипуляций, чем им хотелось бы. А в случае если посетитель заполняет оба поля вручную, но допускает ошибки и в одном и в другом, выяснения что к чему могут так вывести из себя, что он просто уйдет с сайта.

    Редизайн поля ввода еmail-адреса

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

    Поместите поле email на первое место

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

    Увеличьте размер поля

    В поле заполнения электронного адреса делается больше всего ошибок. Важно сделать поле ввода почты достаточно большим, чтобы помочь пользователям заметить ошибки, которые они могут сделать.
    Многие формы используют шрифт слишком маленького размера. И в случае опечатки, это совсем не бросается в глаза, даже если вы видите свой адрес в тысячный раз. Но если шрифт достаточно велик, пользователь хорошо видит все специфические символы. Это помогает распознать ошибку с одного взгляда на введенный адрес.
    Вы можете сделать поле для почты больше чем остальные поля. Правда это может лишить последовательности стиль всей страницы. Чтобы избежать этого, сделайте так, чтобы поле увеличивалось в момент его активации для заполнения. Шрифт вводимых символов тоже должен становиться больше. После того как пользователь снимает выделение с поля, оно возвращается к обычному размеру.
    Вот пример того как это работает.

    Акцентируйте внимание на точности

    Большинство дизайнеров подписывают поле электронной почты просто “Email”. Несмотря на то, что это емко, коротко и понятно, такая лаконичность не подталкивает пользователей к проверке введенных данных. Если вы хотите чтобы посетитель проверил то, что ввел, подчеркните это.
    Обозначение поля “Email (убедитесь что адрес верный)” напоминает пользователям проверить введенные данные. Важно подталкивать посетителя к проверке, ведь как мы уже говорили, мы не думает что можем неправильно ввести свой адрес, а значит и проверять нет смысла.

    Все что вам нужно — ясность

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

  3. бабушкин пирог Ответить

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

    Проблема подтверждения

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

    Многие пользователи просто копируют введенный электронный адрес, и вставляют его в поле подтверждения. Это сводит на нет назначение поля подтверждения, поскольку, если пользователь ввел неправильный адрес в первое поле, то в поле подтверждения окажется то же самое.
    Одно исследование показало, что 60% участников постоянно копировали ввод из поля с адресом в поле подтверждения. Пользователи поступают так, поскольку это сокращает количество необходимой работы. Также, пользователи не верили, что могут ошибиться при вводе, и удивлялись, когда оказывались неправы.
    Поле подтверждения не решает проблему ввода неправильного адреса. Кроме того, оно заставляет пользователя выполнять больше работы. в итоге, пользователь может допустить ошибки в обоих полях. Из-за этого, им придется потратить еще больше времени на исправление ошибок.

    Редизайн поля ввода электронного адреса

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

    Расположите поле ввода электронного адреса в самом начале

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

    Увеличьте размер поля ввода

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

    Подчеркните важность правильности ввода

    Большинство дизайнеров подписывают поле ввода адреса просто «Email». Несмотря на то, что это кратко, и довольно понятно, это не подчеркивает важность правильности ввода. Если вы хотите, чтобы пользователи перепроверяли свой ввод, вы должны подчеркнуть необходимость этого.
    Поле, подписанное «Email (убедитесь в правильности ввода)», говорит пользователям, что нужно перепроверить введенный адрес. Это очень важный момент, поскольку большинство пользователей не верят, что могут ошибиться.

    Всё, что нужно – это ясность

    Данные, необходимые для заполнения форм, имеют разные уровни сложности. Поле ввода электронного адреса заслуживает особого обращения, поскольку оно сложнее остальных. Электронный адрес может содержать как буквы и цифры, так и специальные символы, что делает его ввод особо подверженным ошибкам.
    Пора по-новому взглянуть на дизайн поля ввода электронного адреса. Решение заключается не в добавлении еще одного поля, а в улучшении понятности существующего. Правильное размещение, крупный шрифт, и хорошая подпись – это то, что вам нужно.
    Источник: uxmovement.com

  4. зая я твой Ответить

    Валидный имейл — это существующий, реальный имейл, на который можно отправить письмо. Задача программиста — создать валидацию имейла, т.е. проверку программой имейла на валидность. Задача тестировщика — проверить то, как программа валидирует имейлы, правильно ли она это делает.
    Валидация имейлов
    Перед тем как писать валидацию, надо знать из чего состоит email адрес. Думаю известно всем что это «username@hostname».
    Имя пользователя может в себе содержать:
    латиницу
    цифры
    знаки! # $ % & ‘ * + — / =? ^ _ ` { | } ~
    точку, за исключением первого и последнего знака, которая не может повторятся
    Имя хоста состоит из нескольких компонентов, разделённых точкой и не превышающих 63 символа, и суффиксов (домены первого уровня). Компоненты, в свою очередь, состоят из латинских букв, цифр и дефисов, причём дефисы не могут быть в начале или в конце компонента. Суффиксы это ограниченный список доменов первого уровня.

    Чит-лист для проверки поля email

    1) Пустое поле email  -> Сообщение о незаполненном поле email
    2) Email в нижнем регистре   -> Операция проводится успешно
    3) Email в верхнем регистре   -> Операция проводится успешно
    4) Email с цифрами в имени аккаунта   -> Операция проводится успешно
    5) Email с цифрами в доменной части   -> Операция проводится успешно
    6) Email с дефисом в имени аккаунта   -> Операция проводится успешно
    7) Email с дефисом в доменной части   -> Операция проводится успешно
    8) Email со знаком подчеркивания в имени аккаунта   -> Операция проводится успешно
    9) Email со знаком подчеркивания в доменной части   -> Операция проводится успешно
    10) Email с точками в имени аккаунта   -> Операция проводится успешно
    11) Email с несколькими точками в доменной части   -> Операция проводится успешно
    12) Email без точек в доменной части   -> Должно появится сообщение о неправильном или некорректном e-mail введеном в поле
    13) Превышение длины email (>320 символов)   -> Должно появится сообщение о неправильном или некорректном e-mail введеном в поле
    14) Отсутствие @ в email   -> Должно появится сообщение о неправильном или некорректном e-mail введеном в поле
    15) Email с пробелами в имени аккаунта   -> Должно появится сообщение о неправильном или некорректном e-mail введеном в поле
    16) Email с пробелами в доменной части   -> Должно появится сообщение о неправильном или некорректном e-mail введеном в поле
    17) Email без имени аккаунта   -> Должно появится сообщение о неправильном или некорректном e-mail введеном в поле
    18) Email без доменной части   -> Должно появится сообщение о неправильном или некорректном e-mail введеном в поле
    19) Некорректный домен первого уровня (допустимо 2-63 букв после точки: .ru или например .americanexpress)   ->Должно появится сообщение о неправильном или некорректном e-mail введеном в поле
    Вообще по доменным именам нужна отдельная статья, но оставим здесь интересую информацию.
    Например домен:
    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.ru  — САмый последний домен в зоне ру.
    llanfairpwllgwyngyllgogerychwyrndrobwyll-llantysiliogogogoch.info — название деревни Лланвайр-Пуллгвингилл в Уэльсе на острове Англси, означающее «Церковь Святой Марии в ложбине, заросшей белым орешником, около быстрого водоворота, неподалёку от церкви Святого Тисилио и красной пещеры».

    Базовые валидационные проверки Login/Password

    Заполнить поле корректный login и корректный pass. Expected: успешно залогинен. Разлогиниться. Почистить кэш и куки (открыть/закрыть браузер?).
    Оставить оба поля пустыми. Попытка входа. Expected: Сообщение об ошибке.
    Оставить пустое поле login. Попытка входа. Expected: Сообщение об ошибке.
    Оставить пустое поле password. Попытка входа. Expected: Сообщение об ошибке.
    Ввeсти корректный login и некорректный pass. Expected: Сообщение об ошибке.
    Ввeсти некорректный login, но корректный pass. Expected: Сообщение об ошибке.
    Ввeсти некорректный login и некорректный pass. Expected: Сообщение об ошибке.
    Заполнить поле login ввeсти корректный pass, а в поле пароля ввести корректный login. Expected: Сообщение об ошибке.
    Ввeсти login и корректный pass. Expected: Сообщение об ошибке.
    Заполнить поле login SQL запрос (‘ or ‘a’ = ‘a’; DROP TABLE user; SELECT * FROM blog WHERE code LIKE ‘a%’;)   — структура запроса зависит от DB.
    Заполнить поле login скрипт (alert(“Hello, world!”), )
    Заполнить поле login html-теги (

    )
    Заполнить поле login сложную последовательность символов вроде “♣♂” , “”‘~!@#$%^&*()?>,./\< ][ /* Заполнить поле login текст состоящий из одних пробелов;
    Заполнить поле login правильный login, начинающийся с нескольких пробелов, и правильный pass. Expected: Сообщение об ошибке или автоматическое обрезание пробелов.
    Заполнить полеlogin правильный login, после которого следуют нескольких пробелов, и правильный pass. Expected: Сообщение об ошибке или автоматическое обрезание пробелов.
    Ввeсти корректный login и корректный pass. Нажать на кнопку “Назад” в браузере. Expected:  или The page should be expired, или увидеть те же поля. Если второе – ввести в поля снова login и pass. Перейти. Залогинен?
    Ввeсти корректный login. Указать pass с использованием букв РАЗНОГО регистра.
    Ввeсти login с использованием букв РАЗНОГО регистра. Указать корректный pass.
    Проверить ограничение на длину login и пароля при регистрации? Ввести  qqweqweqweqweqweqweqweqweqweqweqweqweqweqwe / qqweqweqweqweqweqweqweqweqweqweqweqweqweqwe
    Заполнить поле login/pass Aa!@#$%^&*()-_+=`~/\,.?>< | Есть ли ограничения на допустимые символы? Открыть первый бразуер. Залогиниться валидным юзером. Открыть второй браузер. Залогиниться тем же самым валидным юзером. Разлогиниться в первом браузере. Перейти во второй браузер. Сделать что-нибудь, что может сделать только залогиненный юзер. Открыть браузер. Ввести в поля валидные данные. Нажать на кнопку Login. Отключить интернет. Получить “страница недоступна”. Подключить интернет обратно. Зайти на сайт. Expected: не залогинен. Блокируется ли акаунт/IP того, кто введет n-количество раз не правильный pass?
    Установить фокус на поле login. Ввести текст. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на поле пароля. Ввести текст. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на галочку “remember me”. Нажать кнопку Space на клавиатуре. Expected: появилась галочка. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на кнопку Login. Нажать кнопку Enter на клавиатуре. Expected: процесс пошёл.
    Проверка на ‘Remember me on this computer’. Заполнить поля валидными данными. Чекнуть галочку Remember me. Залогиниться. Закрыть браузер. Открыть бразуер. Открыть страницу сайта. Expected: login для входа не требуется.
    Ввeсти корректный login и корректный pass. Скопировать полученный url и вставить его в другой браузер. Expected: It should not display the user’s welcome page.

Добавить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *