Как и все собравшиеся в этом мониторе, мне приходится тестировать иногда проклятые поля ввода логина и пароля. И еще поля регистрации нового юзверя. По ходу дела и после поисков по интернетам собрался отдельный файлик с перечнем тематических тестов (еще будет дополняться и всячески обновляться). Полезен и в ратнейшем труде программистов.
Повсюду под предложением “Expected: alert” подразумевается, что ответ должен быть отрицательным, но система должна как-то сигнализировать юзеру о причине проблемы.
Регистрация нового пользователя
- Зарегистрировать нового пользователя с логином 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.
- а можно ли зарегистрировать пользователя “admin”, и пользователя “аdmin” (где а – из русской расскладки)?
- В некоторых случаях разработчики проверяют пользователя в базе с помощью LIKE, и не обрабатывают user input. Поэтому нужно проверить комбинацию %%%/%%% (знак % повторяется 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сти логин <script>alert(123)</script> и корректный пароль. Expected: alert.
- Ввeсти в поле логина SQL запрос (‘ or ‘a’ = ‘a’; DROP TABLE user; SELECT * FROM blog WHERE code LIKE ‘a%’;) — структура запроса зависит от DB.
- Ввeсти в поле логина скрипт (<script>alert(“Hello, world!”)</alert>, <script>document.getElementByID(“…”).disabled=true</script>)
- Ввeсти в поле логина html-теги (<form action=”http://live.hh.ru”><input type=”submit”></form>)
- Ввeсти в поле логина сложную последовательность символов вроде “♣☺♂” , “”‘~!@#$%^&*()?>,./\<][ /*<!–“”, “${code}”;–>
- Вв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!@#$%^&*()-_+=`~/\,.?><|b / PaSSword!@#$%^&*()-_+=`~/\,.?><| Есть ли ограничения на допустимые символы?
- Ввести логин/пароль Иван/Болван Возможно ли создание имени/пароль с например кириллицей, если да – то как потом эта форма отрабатывает?
- Ввeсти логин ksjdksbdshdoueywfgjwevflwjeyfvowyecsydcvsldc (несуществующий в базе), оставить поле пароля пустым. Expected: such user doesn’t exist.
- Открыть первый бразуер. Залогиниться валидным юзером. Открыть второй браузер. Залогиниться тем же самым валидным юзером. Expected: можно. Разлогиниться в первом браузере. Expected: можно. Перейти во второй браузер. Сделать что-нибудь, что может сделать только залогиненный юзер. Expected: можно.
- Открыть браузер. Ввести в поля валидные данные. Нажать на кнопку Login. Отключить интернет. Получить “страница недоступна”. Подключить интернет обратно. Зайти на сайт. Expected: не залогинен.
- Блокируется ли акаунт/IP того, кто введет n-количество раз не правильный пароль?
- Установить фокус на поле логина. Ввести текст. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на поле пароля. Ввести текст. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на галочку “remember me”. Нажать кнопку Space на клавиатуре. Expected: появилась галочка. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на кнопку Login. Нажать кнопку Enter на клавиатуре. Expected: процесс пошёл.
- User should be a registered user with his/her account expired. Clicks on the Login button.
- A message should appear stating ‘Your account has been expired’.
- Проверка на ‘Remember me on this computer’. Заполнить поля валидными данными. Чекнуть галочку Remember me. Залогиниться. Закрыть браузер. Открыть бразуер. Открыть страницу сайта. Expected: логин для входа не требуется.
- Ввести логин существующего пользователя, обрамив его уголками: <userlogin>. Причина: иногда валидатор вырезает запрещенные символы и проверяет остаток, однако после прохождения проверки передает дальше оригинальную строку.
Смена/удаление логинов
- В базе или настройках сайта указать, что срок годности определенного логина истек. Залогиниться под этим логином. Expected: Alert.
- Залогиниться под корректными логином/паролем. Сменить пароль. Залогиниться под новым паролем. Expected: пароль сменен, можно зайти.
- Смена пароля и заход под старым
- запомнить пароль
- войти в систему
- поменять пароль
- разлогиниться
- залогиниться обратно со старым паролем. Expected: не пускает.
- Залогиниться под корректными логином/паролем. Переименовать аккаунт. Перегрузить браузер. Залогиниться под старыми логином/паролем. Expected: не пускает. Залогиниться под новым логином/паролем. Expected: пускает.
- Залогиниться под корректными логином/паролем. Удалить аккаунт. Перегрузить браузер. Залогиниться под старыми логином/паролем. Expected: не пускает.
Особые случаи
- Ввeсти корректный логин и корректный пароль. Скопировать полученный url и вставить его в другой браузер. Expected: It should not display the user’s welcome page.
- Подумать об обработке операции “вставить”, т.е. рассмотреть различные способы ввода данных.
- Как формируется запрос к серверу с данной формы (get/post)? Как передается пароль – в виде хэша или плэйн-текстом в теле ПОСТа?
- Если данные передаются в адресной строке браузера в виде «login=bla-bla&password=bla-bla»
- – применить все варианты некорректных данных, включая запрещенные символы, и пограничные значения;
- – передать ещё какой-нибудь параметр из существующих, напр. «login=bla-bla&password=bla-bla&state=update»
# Ввeсти в поле логина SQL запрос ( DROP TABLE user; SELECT * FROM blog WHERE code LIKE ‘a%’;);
— не сработает.
Еще один catch…
Иногда запись вида alert(‘truba’) может пройти успешно, поэтому предлагаю заэскейпить символы ><.
После чего скрипт будет таким:
<script>alert('truba')</script>
Очень часто проходит и есть шанс поймать багу за хвост…
Еще для регистрации нового пользователя можно добавить:
8. использование только ASCII символов в логине – Expected: alert.
9. регистрация пользователя с логином, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
10. регистрация пользователя с паролем, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
11. регистрация пользователя с логином содержащим XSS или SQL injections. – Expected: alert.
список не полный, но это то, что пришло в голову сходу…
Сомнения по поводу пункта 20:
>Попытаться залогиниться, используя в логине буквы только одного регистра (vasea). Expected: можно.
Можно ли? Думаю, и логин и пароль обязаны быть case-sensitive.
Странно, один из моих постов с тест кейсами потерялся 🙂
пробую еще раз:
Иногда логин вида alert(123) будет заблокирован системой, в этом случае я предлагаю заэскейпить символы >< и попробовать следующий логин:
<script>alert(123)</script>
🙂 интересно 🙂 в предыдущем посте я хотел написать:
Символ замените на > (“& g t ;” – пробелы убрать)
Вот… 🙂
что за хрень 🙂 даже коммент написать не получается :)))
баги баги баги… баги баги баги…
Вчера боги вордпресс начал обновляться, работать с платформой было невозможно.
Комментарии получены, спасибо.
Не сработает, если по-тупому вставить as is, или даже если правильно указать названия таблиц?
Омгм… Правильные сомнения, но в платформе, с которой я сейчас работаю, это можно – сделали специально, чтобы имена были уникальными, а то был конфликт между владельцем ника Imperator и владельцем ника ImperatoR 🙂
Вот пароль должен быть сенситив, несомненно.
Надо сначала завершить без ошибки выполнение первого селекта выполняемого на сервере– > потом вставить свой –> потом закометировать остаток строки. Пример :
‘ or ‘a’ = ‘a’; DROP TABLE user; SELECT * FROM blog WHERE code LIKE ‘a%’; —
структура запроса зависит от DB.
Ага.
Спасибо.
Ого .. сколько проверок и правил! 🙂 Тут тестить и тестить, а если меняется что-то в коде, по новому нужно тестить.
Мне кажется, что проще быть уверенным в правильной валидации данных своего фреймворка, нежели тестировать всеми способами.
Например, в Yii я пишу так:
public function rules()
{
return array(
// username are required
array(‘user_login, user_email’, ‘required’),
// username must be between 6 and 30 characters
array(‘user_login’, ‘length’, ‘min’=>6, ‘max’=>30),
array(‘user_email’, ’email’),
// verifyCode needs to be entered correctly
array(‘verifyCode’, ‘captcha’, ‘allowEmpty’ => !extension_loaded(‘gd’)),
);
}
Хотя тестирование всегда будет и до идеала его довести очень тяжело.
Ну, я вижу в твоем коде только проверки:
– что обязательно заполнение двух полей
– что мин 6 и мак 30 символов в поле логина
– что в поле user_email должно находиться что-то, похожее только на емайл
– что ты подозреваешь роботов в каждом юзере 🙂
Все остальное непокрыто, и лично мне неясно, чего можно ожидать от этих милых, пушистых, но безумно неожиданных юзверей…
Идеал и не нужен, иначе тестировщики потеряют право отмазываться “Всего не перетестишь!” Нужно из списка выцыганить самое важное “для себя” и проверить.
В этом то и суть тестирования, что оно идет независимо от тестирования разработчиков…
Ну да, соглашусь! Я еще не подключил правило для допустимых символов в логине. Это будет обязательно, иначе внесут всякую дрянь.
Кроме этого, нужен фильтр цензурных слов.
Сначала нужно определить поддерживает ли DB драйвер sql multi queries.
а можно ли зарегистрировать пользователя:
admin
и пользователя
аdmin (где а – из русской расскладки)
?
есть такие умные разработчики, которые проверяют пользователя в базе с помощью LIKE и не обрабатывают user input, поэтому нужно проверить комбинацию %%%/%%% (знак % повторяется 3 раза, чтобы обойти валидацию на минимальную длину).
Теперь пункт 5 оказывается лишним – дублируется более широким п. 9
Да.
Подправил.
Я недавно локализировал один такой диалог
http://www.atriplex.com.ua/post/login-localization.aspx
Та ещё сволочь!
Добрый день! Помогите мне пожалуйста. У меня при вводе на латинском видимо поставлен блокирующий режим перевода латиницы на русский алфивит, и пароль тоже. Как только начинаю в латинице набирать логин, он перескакивает на русский, соответственно вход на сайт блокируется.
что мне сделать чтобы отменить это?
Punto Switcher?
Ирина, в этом случае есть парочка вариантов обойти проблему, первый простой второй с веселый 🙂
1. Удалите программу перевода латиницы на русский!
2. Наберите по 1 символу (написали, скопировали и вставили) в блокноте Ваш логин и потом пароль. а потом просто копипастите его в форму логина 🙂
Первый вариант мне нравится больше 🙂
Вот…
1) Настроить ее надо, а не удалять.
Отличная статья!!! огромное спасибо, уже применяю на практике некоторые кейсы…
Не совсем согласен с п. 15-16 – как правило встречал приложения, где пробелы перед после логина – обрезаются и юзер логинится (e.g. gmail.com)
Алексей, если будет возможность, прокомментируйте плиз. Заранее СПАСИБО!
Цель была такая: собрать любые мелочи, которые могут иметь отношение к тестированию полей ввода, и в частности – логин/пароль.
Незачем использовать весь этот список “as is”.
Из него нужно выписать то, что подходит для каждого частного случая.
Случай с пробелами, которые обрезаются – это хорошо, если обрезаются. У меня были случаи, когда это не обрезалось. Хорошо знать заранее, что и как работает 🙂 Обычно же знаешь, что и как ДОЛЖНО работать, не более.
К слову, этот список по-разному воспринимается тестировщиками и программистами.
– Тестировщики смотрят на это внимательно и сурово. Просто список проверок.
– Программисты смотрят на это с возгласом “Ну ни фига себе, сколько всякого наворотили!”
Cool! полностью согласен, спасибо за Ваш ответ и Ваши посты! 🙂
В разделы
Регистрация нового пользователя, логин существующим пользователем
Ввод некорректных данных
Ввести логин <newuser>
Причина: иногда валидатор вырезает запрещенные символы и проверяет остаток, однако после прохождения проверки передает дальше оригинальную строку.
******
В разделы
Регистрация нового пользователя, логин существуюшим пользователем, смена пароля
Ввод некорректных данных
Создать логин с максимально возможным числом символом
Попробовать залогиниться
Попробовать сменить пароль
Причина: возможно несовпадение максимумов между строками ввода нового пароля, ввода пароля, смены пароля, и в БД.
Дополнительно: проделать те же шаги, но с количеством символов макс+1
Дополнительно: проделать те же шаги (за исключением смены пароля) для логина
Дополнительно: проделать те же шаги для логина и пароля, но (1) с макс. количеством разрешенных символов + пробел (и другие безобидные);(2) с макс. количеством разрешенных символов + 1 запрещенный.
******
В разделы
Особые случаи
Ввод некорректных данных
Если данные передаются в адресной строке браузера в виде “login=bla-bla&password=bla-bla”
– применить все варианты некорректных данных, включая запрещенные символы, и пограничные значения;
– передать еше какой-нибудь параметр из существующих, напр. “login=bla-bla&password=bla-bla&state=update”
Спасибо, добавил.
тогда уже и статью пора переименовывать) давно уже вышла за рамки банального тестирования полей логин/пароль и разлилась по широкому полю функционала)))
У меня есть SEO-доводы, которые отстаивают правильность нынешнего заголовка.
как насчет логина с непечатными символами форматирования текста (перевод строки, табуляция и т.п… )? до логина, после, до и после. в принципе и для регистрации тоже вполне применимо.
Еще одна комбо-атака от Сантоша.
http://tuppad.com/blog/2011/01/10/password-%e2%80%93-flaws-risks-design-suggestions-and-more/
Уведомление: Комонные проблемсы с шопинг картсами « QA – грамотно
добрый день, я только начинаю тестить и сразу же попала на ваш доклад про IDE, а потом и сюда.
вопрос по “17. Ввeсти корректный логин и корректный пароль. Нажать на кнопку “Назад” в браузере. Expected: непонятно – или The page should be expired, или увидеть те же поля. Если второе – ввести в поля снова логин и пароль. Перейти. Залогинен?”
я должна ввести данные, нажать логин, а потом нажать “Назад”? и то что пользователь два раза логинится это хорошо или все таки не очень?
и вот здесь наверно пароль имелось ввиду вместо логина?
“Зарегистрировать пользователя с логином petea/iZMaIL. Expected: можно. Попытаться залогиниться, используя в пароле буквы только одного регистра (petea/izmail). Expected: alert. Алерт должен указать на причину?”?
это не хорошо и не плохо – это бывает.
Плохо или хорошо – зависит от реализации каждой системы в отдельности.
Иногда все выглядит так, словно юзер повторно логинится. Иногда нет.
Нет, здесь все правильно написано.
“Установить фокус на поле логина. Ввести текст. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на поле пароля. Ввести текст. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на галочку “remember me”. Нажать кнопку Space на клавиатуре. Expected: появилась галочка. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на кнопку Login. Нажать кнопку Enter на клавиатуре. Expected: процесс пошёл. ”
А что если в “Crome” все работает а в “FireFox” нет. Это проблема браузера или кода.
Спасибо.
Это проблема верстальщика 🙂
tabindex пусть пропишет правильно.
Полезная стаття – люблю когда всё собранно в одном месте и структурированно. Раздел «Особые случаи» – еще бы расширить и описать поподробней. Готов автору поставить вкусную выпивку 🙂
ЗАМЕЧАНИЕ 0.
Рекомендую потратить несколько минут. Забросить текст в Word и проверить хотя бы по минимуму орфографию. Как ни как если текст раскрутится, то его могут читать пол НСГ (из числа заинтересованных) .
ЗАМЕЧАНИЕ 1. К разделу «Регистрация нового пользователя», п.8 – п.9.
8. регистрация пользователя с логином, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
9. регистрация пользователя с паролем, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
– 2 пункта идентичны
– «пробелом» заменить на «пробелов» (2 замены)
ЗАМЕЧАНИЕ 2. К разделу «Регистрация нового пользователя», п.11.
русской расскладки
– «расСкладки» заменить на «раскладки»
ЗАМЕЧАНИЕ 3. К разделу «Регистрация нового пользователя», п.13.
Логин под существуюшим
– «существуюШим» заменить на «существуюЩим»
ЗАМЕЧАНИЕ 4. К разделу «Особые случаи», п.4.2.
передать еше какой-нибудь
– «еше» заменить на «еЩе»
Принято, спасибо.
Спасибо за статью. Есть ли такого рода статьи для других функциональностей?
Сейчас есть только две статьи по тэгу “Читерство” – http://testitquickly.com/tag/читерство/
Объясните пожалуйста почему Expected: alert на
Зарегистрировать нового пользователя с логином new@user. ?
Чем мешает @ в логине?
Хм.
Не объясню. Не помню, какое было соображение, когда это писалось.
Здравствуйте, подскажите техническую деталь – какой пароль будут корректным для этих кейсов?
“6. Ввeсти некорректный логин, но корректный пароль. Expected: alert.
7. Ввeсти некорректный логин и некорректный пароль. Expected: alert.”
Разве некорректность логина не подразумевает, что – все, логина нет, пароль уже неважен? Спасибо!
Тут подразумевается очень редкий случай, когда проверка проводится только по одному из полей.
Конечно, казалось бы…