как протестировать форму регистрации

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

Здравствуйте, сразу уточню что это тестовое задание.

Мне нужно протестировать веб форму любого сайта(только поле регистрации и авторизации). Я уже этим занимаюсь 4 часа))). Опыта в подобных вещах у меня нет. Поэтому я был бы очень рад если бы вы глянули на то, что у меня получается. Особенно по поводу оформления, я очень сильно переживаю, как-то всё громоздко получается. Полная работа будет страниц на 12 где-то, не уверен, что это нормально). Вообщем буду очень рад если вы меня скорректируете. Если не трудно напишите, что хорошо, а что плохо.

1. Форма Регистрации

1.1) Ввести все предложенные данные корректно.

1.2) Ввести только обязательные поля

1.3) Заполнить все данные и обновить страницу

1.4) Не заполнять данные и выполнить регистрацию.

1.5) Ввести максимально допустимые значения в поля ввода.

1.6) Ввести минимально допустимые значения в поля ввода.

1.7) Поля Имя и Фамилия:

А) Ввести только одни пробелы;

Б) Ввести данные на английском языке;

Г) Ввести спецсимволы.

1.8)Ввод Пароля:
А)Аналогичный почте;

Б)Состоящий только из пробелов.

1.9)Почта
А) Ввести почту уже зарегистрированного пользователя;

Б) Использовать русские буквы в почте;

В) Не указывать символ “@”;

Г)Не указывать домен верхнего уровня.

1.9)Выбор даты рождения:

А)Выбрать ещё не наступившую дату

Б)Выбрать в качестве даты рождения текущее число

Г)Выбрать в качестве даты рождения не существующую дату

Д)Проверка «29 февраля»

2.1 Проверка формы авторизации:

2.1) Выполнить вход в аккаунт введя все данные корректно.

2.2) Не заполнять поля авторизации и попытаться осуществить вход.

2.4) Заполнить корректно только поле пароль.

2.5) Попытаться осуществить вход используя аккаунт, пароль которого состоит из пробелов.

2.6) Ввести корректный маил, но не корректный пароль.

2.7) Ввести не корректный маил, но корректный пароль.

Форма Регистрации

Т1.1) Ввести все предложенные данные корректно.

Ожидаемый результат: Появляется уведомление: «Учетная запись создана.

Фактический результат: Появляется уведомление: «Учетная запись создана.

Т 1.2) Ввести только обязательные поля

Ожидаемый результат: Появляется уведомление: «Учетная запись создана.

Фактический результат: Появляется уведомление: «Учетная запись создана.

T 1.3) Заполнить все данные и обновить страницу

Шаги: 1) На сайте https://tomas33.ru заполнить все данные для регистрации и обновить страницу.

Ожидаемый результат: Очистка введённой информации.

Шаги по воспроизведению:

1)На сайте https://tomas33.ru выбрать пункт регистрация.

Т1.4 Не заполнять данные и выполнить регистрацию.

Шаги: 1) На сайте https://tomas33.ru при регистрации оставить все поля пустыми и попытаться зарегистрироваться.

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

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

Т1.5) Ввести максимально допустимые значения в поля ввода.

Ожидаемый результат: Успешная регистрация

Фактический результат: Ошибка: 500 Server Error

БАГ1.5) Ввод максимально допустимых значений
Описание: При вводе максимально допустимых [сА1] значений при регистрации сайт отображает ошибку «500 Server Error».

Шаги по воспроизведению:

1) На сайте https://tomas33.ru выполнить регистрацию введя в поле email 128 символов.

Деффект: сервер выдаёт ошибку: «500 Server Error»

Т1.6) Ввести минимально допустимые значения в поля ввода.

Ожидаемый результат: Успешная регистрация.

Фактический результат: Успешная регистрация.

T1.7.А) В поля «Имя» и «Фамилия» ввести только одни пробелы;

Шаги: 1) На сайте https://tomas33.ru выполнить регистрацию введя в поля Имя, Фамилия только пробелы.

Ожидаемый результат: Сообщение об ошибке.

Фактический результат: Успешная регистрация.

БАГ1.7.А) Возможность регистрация нового пользователя имя и фамилия которого состоит из пробелов.

Описание: Во время регистрации при вводе в поля «Имя» и «Фамилия» пробелов, система воспринимает их корректно и успешно регистрирует нового пользователя.

Шаги по воспроизведению:

1) На сайте https://tomas33.ru выполнить регистрацию введя в поля «Имя» и «Фамилия» только пробелы.

Деффект: Система корректно воспринимает регистрацию нового пользователя имя и фамилия которого состоит из пробелов.

T1.7.Б) Ввести данные на английском языке;

Шаги: 1) На сайте https://tomas33.ru выполнить регистрацию введя в поля Имя, Фамилия слова на английском языке.

Ожидаемый результат: Успешная регистрация.

Фактический результат: Успешная регистрация.

T1.8.В) Ввести цифры

Шаги: 1) На сайте https://tomas33.ru выполнить регистрацию введя в поля Имя, Фамилия цифры.

Ожидаемый результат: Сообщение об ошибке.

Фактический результат: Сообщение об ошибке.

T1.8.Г) Ввести спецсимволы.

Шаги: 1) На сайте https://tomas33.ru выполнить регистрацию введя в поля Имя, Фамилия спецсимволы.

Ожидаемый результат: Сообщение об ошибке.

Фактический результат: Сообщение об ошибке.

Источник

Тестирование веб форм (вопросы на собеседовании)

— Заполняем поля известными правильными данными жмём вход.
Далее негативные тесты.
— Заполняем не верными данными и вход
— Одно верными другое не верными данными и вход

— Тоже что и выше только наоборот

— Заполняем поля правильными данными жмём ок.
Далее негативные тесты.

— Какое-то из полей пустое

— Ник состоящий из смеси англ и русс букв

— Ник имеющий знаки препинания и символы

— Слишком длинный никнейм

— Слишком короткий комментарий

— Слишком длинный комментарий

— Слишком длинный комментарий состоящий из слова без пробела

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

У Алексея Лупана есть отличный пост «Тестируем логин/пароль»

у меня ник user12 Ж)

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

У Алексея Лупана есть отличный пост «Тестируем логин/пароль»

у меня ник user12 Ж)

В тестировании 1 пункта обратите внимание на то, что тестируете во 2м пункте. Большинство идей применимо и там.

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

А есть спеки нет вообще? А если она есть, но состоит из одной строки «сделать стандартный логин диалог»?

А если в конце концов там написано, что пароль должен состоять только из цифр и быть не длиннее 3 символов?

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

А есть спеки нет вообще? А если она есть, но состоит из одной строки «сделать стандартный логин диалог»?

А если в конце концов там написано, что пароль должен состоять только из цифр и быть не длиннее 3 символов?

При том, что автор темы указал, что это вопрос с собеседования.

Или дали спеку с откровенным бредом.

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

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

Конечно я согласен, что надо думать собственной головой.

но не согласен с этим:

Это звучит как «я не хочу думать сам, пускай другой умный дядя придумает за меня, какие проверки мне надо провести».

на XSS и SQL иньекции можно добавить по идее к форме комментария.

При том, что автор темы указал, что это вопрос с собеседования.

Или дали спеку с откровенным бредом.

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

Если нет спеки, нет программы, то смысл тестировать воздух?

Если что и тестируется данным воздухом то стрессоустойчивость.

По поводу тестирования полей SALar в разы лучше, чем Лупан написал: Тестирование полей ввода.

Конечно я согласен, что надо думать собственной головой.

но не согласен с этим:

Это звучит как «я не хочу думать сам, пускай другой умный дядя придумает за меня, какие проверки мне надо провести».

Вы противоречите сам себе. Вместо того, чтобы подумать, что пароль должен быть от 8 до 40 символов, вы требуете этого ответа от аналитика.

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

А если это банковская система, вас не удивит требование только букв и цифр? Я бы настаивал на том, что спецсимволы надо позволять вводить в пароле.

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

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

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

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

Если нет спеки, нет программы, то смысл тестировать воздух?

Если что и тестируется данным воздухом то стрессоустойчивость.

О, ещё один человек считает, что без требований работать невозможно. Жаль, но это не соответствует действительности.

Если нет спеки, нет программы, то смысл тестировать воздух?

Если что и тестируется данным воздухом то стрессоустойчивость.

О, ещё один человек считает, что без требований работать невозможно. Жаль, но это не соответствует действительности.

Где я сказал что без требований работать невозможно?

А вы на собеседованиях людям что предоставляете потестировать, реальные программы, реальные требования, или всё-таки гипотетические программы?

А вы на собеседованиях людям что предоставляете потестировать, реальные программы, реальные требования, или всё-таки гипотетические программы?

Любой реальный, известный сайт.

ИМХО, это более эффективно, чем гипотетическая программа и сотрясение воздуха.

И вы так и не ответили:

Любой реальный, известный сайт.

ИМХО, это более эффективно, чем гипотетическая программа и сотрясение воздуха.

Прямо в офисе? Или на дом?

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

Любой реальный, известный сайт.

ИМХО, это более эффективно, чем гипотетическая программа и сотрясение воздуха.

Прямо в офисе? Или на дом?

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

Не Листбоксер, ибо вы правы он плох для оценки.

Другая тестовая программа.

— Заполняем поля известными правильными данными жмём вход.
Далее негативные тесты.
— Заполняем не верными данными и вход
— Одно верными другое не верными данными и вход

— Тоже что и выше только наоборот

— Заполняем поля правильными данными жмём ок.
Далее негативные тесты.

— Какое-то из полей пустое

— Ник состоящий из смеси англ и русс букв

— Ник имеющий знаки препинания и символы

— Слишком длинный никнейм

— Слишком короткий комментарий

— Слишком длинный комментарий

— Слишком длинный комментарий состоящий из слова без пробела

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

Если компания ищет не рядового бойца, то скорее всего вы не прошли собеседование.

«Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество.» © Стив Джобс

Источник

Как тестировать формы? Мини-руководство

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

Зачем тестировать формы?

1. Безопасность

Злоумышленники могут использовать поля формы для получения информации или других вредоносных действий — это может быть сделано с помощью SQL-инъекций и вредоносных скриптов.

2. Стабильность

Когда пользователь вводит данные, которые не могут быть обработаны приложением, оно может среагировать неожиданным образом — например, упасть.

3. Корректное поведение UI и единообразие

Очень важно, чтобы все формы в приложении были единообразны (и по внешнему виду, и по поведению).

4. Чистота базы данных

Форма — место, которое наполняет базу данных. Если есть проблемы с валидацией, появляется угроза того, что некорректные данные попадут в БД. Это ведет к проблемам с поведением приложения и потенциальным багам.

Разделение эквивалентности

Разделение эквивалентности — это разделение набора возможных данных для ввода на классы. Каждый член класса считается идентичным всем остальным.

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

Анализ граничных значений

Кроме классов эквивалентности, нужно протестировать граничные значения. Граничные значения это:

Граничные значения проверяются, потому что ни один разработчик не застрахован от так называемой ошибки на единицу.

Дополнение

Вместе со всем вышеперечисленным нужно попробовать:

Даже у Google были проблемы с выходом за предел 32-битного промежутка: в декабре 2014 года количество просмотров клипа PSY Gangman Style на YouTube превысило максимальное значение 32-битнгого промежутка. После этого счетчик обновили.

Таблица верификации полей

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

Бонус: BugMagnet

Для тестирования форм есть отличный плагин для Chrome и Firefox — BugMagnet. После установки кликните правой кнопкой мыши по любому полю формы и у вас появится возможность выбора значений для заполнения из огромного списка данных. Вот видео, на котором показано, как работаем BugMagnet:

Источник

Сценарии для тестирования Login формы

Хотелось бы узнать, а какие ещё сценарии, можно придумать для тестирование Login формы на рисунке

кроме таких что первыми идут в голову:

Проверить заполение обязательных полей.
Ввод корректного логина и корректного пароля.
Проверка на ‘Remember me on this computer’.
Ввод корректного логина и некорректного пароля
Ввод некорректного логина и корректного пароля
Ввод некорректного логина и некорректного пароля

Прикрепленные файлы

Хотелось бы узнать, а какие ещё сценарии, можно придумать для тестирование Login формы на рисунке

кроме таких что первыми идут в голову:

Проверить заполение обязательных полей.
Ввод корректного логина и корректного пароля.
Проверка на ‘Remember me on this computer’.
Ввод корректного логина и некорректного пароля
Ввод некорректного логина и корректного пароля
Ввод некорректного логина и некорректного пароля

Есть ли ограничение на длину (логина, пароля) при регистрации?

Есть ли ограничения на допустимые символы (в пароле, имени) при регистрации?

Классный сценарий, но юзать это будут америкосы так что ни о какой кириллице и т.п речи и не может быть

Это ввод несуществующего пользователя типа есть пользователь root c паролем 1111, а мы пытаемся зайти под rot (которого нет в базе) с паролем 1111

Что будет если поля пустые (оба или одно из них)?

насчёт оба так это 1 сценарий который я писал, а насчёт 1 одного я думаю это уже очевидно. Просто если поле не заполнено то это NULL и при нажании на Sign In послывает в базу NULL соотвественно равносильно несуществующему пользователю или некорректному паролю

Что будет при попытке залогиниться с использованием имени/пароля недавно удаленного пользователя?
.

Что будет если поля пустые (оба или одно из них)?

насчёт оба так это 1 сценарий который я писал, а насчёт 1 одного я думаю это уже очевидно. Просто если поле не заполнено то это NULL и при нажании на Sign In послывает в базу NULL соотвественно равносильно несуществующему пользователю или некорректному паролю

.
А вообщем спасибо =) некоторые мысли в голову пришли

Вот еще на подумать.

Что будет если поля пустые (оба или одно из них)?

насчёт оба так это 1 сценарий который я писал, а насчёт 1 одного я думаю это уже очевидно. Просто если поле не заполнено то это NULL и при нажании на Sign In послывает в базу NULL соотвественно равносильно несуществующему пользователю или некорректному паролю

Что будет если поля пустые (оба или одно из них)?

насчёт оба так это 1 сценарий который я писал, а насчёт 1 одного я думаю это уже очевидно. Просто если поле не заполнено то это NULL и при нажании на Sign In послывает в базу NULL соотвественно равносильно несуществующему пользователю или некорректному паролю

А зачем гонять трафик когда в запросе очевидные невалидные данные?
А правда, что ваша фамилия drop table students? (судя по всему это веб-приложение)
А если это веб, то.
Вообще, странный топик. Нагуглить тестов не составляет никакого труда, это одна из распространенных задач на собеседованиях
например http://www.allinterv. swers/6392.html

Действительно это веб-приложение.

Был бы я тоже гуру, я б тоже посчитал такой пост странным. Я думал что эта тема с бородой и 100% должна была б быть в этом, но к сожалению я не нашёл.
Как Вы сказали что это одна из распростаненных задач на собеседованиях, ну может так оно и есть (меня на собеседованиях про это не спрашивали), но не только для собеседованиях,
но и на реальных проектах.

Я гуглил по ‘тестирование Login form’, но в очередной раз убедился что по таким вопросам лучше искать в англоязычных сайтах.

А сценарии нужны для написание тест кейсов.

Я понимаю что случаев можно придумать очень много, но не будет же QA целый день тестировать именно login форму

Был бы я тоже гуру, я б тоже посчитал такой пост странным. Я думал что эта тема с бородой и 100% должна была б быть в этом, но к сожалению я не нашёл.

Я гуглил по ‘тестирование Login form’, но в очередной раз убедился что по таким вопросам лучше искать в англоязычных сайтах.

Я понимаю что случаев можно придумать очень много, но не будет же QA целый день тестировать именно login форму

Напишите 1000 (вроде бы) сообщений на форуме и станете гуру. Обычно тут не бывает подобных тем, т.к. форум существует не для обмена тест-кейсами.

гуглить лучше на английском языке, например login test cases

Будет и два, и три дня тестировать, столько, сколько нужно.

Был я на одном проекте таком на котором было 5000 тест кейсов, их филлипинцы писали, они же были заказчиками или посредниками, так вот мы по этим тест кейсам они находили максимум 2-3 незначительных бага, наша команда находила 20-30 багов

Когда речь идёт о сроках выражение «тестировать столько, сколько нужно» я думаю будет не уместно.

Когда речь идёт о сроках выражение «тестировать столько, сколько нужно» я думаю будет не уместно.

Извините за ОФТОП, но когда речь идет о сроках, а не о качестве, тогда: «тестируем отсюда и до обеда».
Но мне кажется, что качество должно «двигать» сроки, и если так, то надо искать точку выхода из фазы тестирования не по срокам, а именно по качеству. Иначе получится: «Хотели как лучше, а получили как всегда».

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.

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

Вот вот и я об этом, что нужно выбирать что тестировать.

Полюбому должны быть какие-то основные аспекты на которые следует обратить внимание.
То что всё приложение полностью протестированно, это точно так же как и байка о приложении без багов

Был я на одном проекте таком на котором было 5000 тест кейсов, их филлипинцы писали, они же были заказчиками или посредниками, так вот мы по этим тест кейсам они находили максимум 2-3 незначительных бага, наша команда находила 20-30 багов

Когда речь идёт о сроках выражение «тестировать столько, сколько нужно» я думаю будет не уместно.

Источник

Чек-лист тестирования WEB приложений

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

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

Чек-лист для тестирования WEB приложений состоит из шести разделов:

Функциональное тестирование

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

Что проверяем?

Интеграционное тестирование

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

Что проверяем?

Тестирование безопасности

Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности нашего приложения.

Что проверяем?

Тестирование локализации и глобализации

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

Что проверяем?

Тестирование удобства использования

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

Что проверяем?

Кросс-платформенное тестирование

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

Источник