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

Содержание

0.1 Материал из AOW

1 Содержание
2 Регистрация нового пользователя
3 Ввод некорректных данных
4 Тестирование полей ввода

Материал из AOW

Содержание

Регистрация нового пользователя

Зарегистрировать нового пользователя с логином new_user. Expected: можно.
Зарегистрировать нового пользователя с логином new_user_test. Expected: можно.
Зарегистрировать нового пользователя с логином new-user. Expected: можно.
Зарегистрировать нового пользователя с логином new1234user. Expected: можно.
Зарегистрировать нового пользователя с логином new@user. Expected: alert.
Зарегистрировать нового пользователя с логином newuser и паролем newuser (полное совпадение). Expected: alert.
использование только ASCII символов в логине – Expected: alert.
регистрация пользователя с логином, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
регистрация пользователя с паролем, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
регистрация пользователя с логином содержащим XSS или SQL injections. – Expected: alert.
проверить комбинацию %%%/%%% (знак % повторяется 3 раза, чтобы обойти валидацию на минимальную длину).
создать аккаунт с максимально возможным числом символом в логине

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

Дополнительно: проделать те же шаги, но с количеством символов макс+1
Дополнительно: проделать те же шаги, но

с макс. количеством разрешенных символов + пробел (и другие безобидные);
с макс. количеством разрешенных символов + 1 запрещенный.

создать аккаунт с максимально возможным числом символом в пароле

Попробовать залогиниться

Попробовать сменить пароль (а может – и сам логин?)

Причина та же: возможно несовпадение максимумов между строками ввода нового пароля, ввода пароля, смены пароля, и в БД.

Ввод некорректных данных

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

!@#$%^&*()?>,./

Ввeсти в поле логина текст состоящий из одних пробелов;

Ввeсти в поле логина правильный логин, начинающийся с нескольких пробелов, и правильный пароль. Expected: alert.

Ввeсти в поле логина правильный логин, после которого следуют нескольких пробелов, и правильный пароль. Expected: alert.

Ввeсти корректный логин и корректный пароль. Нажать на кнопку “Назад” в браузере. Expected: непонятно – или The page should be expired, или увидеть те же поля. Если второе – ввести в поля снова логин и пароль. Перейти. Залогинен?

Ввeсти корректный логин. Указать пароль с использованием букв РАЗНОГО регистра.

Ввeсти логин с использованием букв РАЗНОГО регистра. Указать корректный пароль.

Зарегистрировать пользователя с логином VasEA. Expected: можно. Попытаться залогиниться, используя в логине буквы только одного регистра (vasea). Expected: можно.

Зарегистрировать пользователя с логином petea/iZMaIL. Expected: можно. Попытаться залогиниться, используя в пароле буквы только одного регистра (petea/izmail). Expected: alert. Алерт должен указать на причину?

Проверить ограничение на длину логина и пароля при регистрации? Ввести qqweqweqweqweqweqweqweqweqweqweqweqweqweqwe / qqweqweqweqweqweqweqweqweqweqweqweqweqweqwe

Ввести логин/пароль Aa!@#$%^&*()-_+=`

/. > . Причина: иногда валидатор вырезает запрещенные символы и проверяет остаток, однако после прохождения проверки передает дальше оригинальную строку.

Тестирование полей ввода

Для полей ввода проверяются:

Обработка корректных данных
Обработка граничных условий
Обработка некорректных данных внутри граничных условий
Обработка некорректных данных вне граничных условий
Обработка сложных данных

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

13 (любое целое число от 0 до 100)
-1, 0, 100, 101. Рекомендуют еще проверить обработку 1 и 99, но, на мой взгляд это излишество. Вот если бы в условиях стояло “исключая 0 и 100″, то тогда нужно было бы проверить 0, 1, 99, 100.
3.14
-8, 115. Хотя, если -1 и 101 были обработаны нормально, то эта проверка уже лишняя. Стоит попробовать ввести буквы, знаки препинания.
в данном случае нет.

Неужели это все? Нет, есть еще несколько тонкостей.

Различия в обработке некорректных данных между Web и Win32 приложениями.
Win32 приложения не должны давать вводить в поле ввода некорректные символы. Реализация может быть различной. Может быть просто блокировка ввода, может выскакивать маленький предупреждающий символ слева от поля ввода. Иногда подают звуковой сигнал или выводят модальное окно- предупреждение. Но последние два способа не эргономичны и я считаю их ошибками проектирования интерфейса.
В Web-приложениях обработка, как правило, ведется на сервере. Соответственно, пользователю должна вернуться та же самая форма ввода, содержащая: все, что пользователь ввел (не заставляйте человека вводить данные дважды!), пометки около всех неправильных полей, и сообщение, что же было неверным.

Сложные символы
Пусть у нас есть поле ввода названия фирмы. Обычно, я проверяю поля на обработку строки типа такой:
“[|]’

Внимание! При использования этой строки уберите пробел между запрещён к использованию в именах файлов и папок(прислано Fyz).

Часто возникает необходимость тестировать поля ввода на обработку различных данных. И часто это делается спонтанно — введём спецсимвол, оставим поле пустым, введём слишком длинную строку.

Поэтому я делаю попытку все эти действия структурировать и выполнять последовательно для всех тестовых полей — желательно автоматизированным тестом.

Итак у нас есть текстовое поле в форме регистрации — е-mail.

1) Проверяем на обязательность заполнения

Система должна реагировать на пустое поле е-mail соответствующим сообщением.

2) Проверяем на граничное значение — введем е-mail длиной в 200 символов.

Например, vasyaaaaa(200 буков a)@.mail.ru.

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

4 comments:

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

В ближайшую неделю, я выложу ее у себя на сайте.

А по вашему посту, я могу добавить еще пару пунктов:
3) проверить формат вводимых данных (если стоит требование на формат)
4) проверить ввод разрешенных, запрещенных символов
5) Для числовых значений проверка нижней и верхней границы с включенными и не включенными границами
6) Для чисел в с десятичной точкой, проверка округления до нужного уровня точности
7) Для JAVA приложений — для чисел в с десятичной точкой, проверка использования таких значений как NaN, Infinity, -Infinity.

Все перечисленное мной поддерживается моей программой 🙂

Позволю себе не согласиться со вторым пунктом:

The "local-part" of an e-mail address can be up to 64 characters (however servers are encouraged to not limit themselves to accepting only 64 characters) and the domain name a maximum of 255 characters.

Это если говорить о граничных значениях 🙂

Статья не закончена. А програмка очень заинтересовала.