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

· не указано минимально допустимое количество символов в поле ввода электронной почты и пароля (создал тест-кейс для тестирования пустых полей ввода);

· не указано какие символы допустимы в пароле;

· не указано название сайта (я принял его за «example.ru»);

· не указаны координаты расположения формы авторизации на веб-странице;

· при необходимости можно дополнить тест-комплект тест-кейсами на проверку клавиш «Backspace» и «Escape».

Среда выполнения: Google Chrome 41.0.2272.101 m.

Тестируемый компонент: Авторизация на сайте

Источник

Сценарии для тестирования 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 багов

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнение

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

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

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

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

Бонус: BugMagnet

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

Источник