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

Чек-лист тестирование формы регистрации

Также у меня есть вопрос по поводу positive и negative: Когда мы пытаемся ввести логин состоящий из 2 символов то, выводится сообщение » Введенное имя слишком короткое «. Я расцениваю это с одной стороны как пазитив, потому что форма реагирует и не дает нам совершить ошибку. С другой стороны мы же вводим 2 символа, а это не корректно для логина и является негатив тестом. Почему так?

Ссылка на документ: гугл док

2. это негативный тест, потому что вы при этом не можете пройти процедуру логина.

Мысли после поверхностного взгляда:

Много избыточных проверок, например, из позитивных:

пункты 7 и 8 можно объединить в один, т.к. если проверка успешно проходит на 3-х символах, то на 4-х она тоже будет проходить (эквивалентные значения)

пункты 12 и 13 по сути эквивалентные, тоже можно сократить до одного

пункты 19 и 20 так же эквивалентны

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

Из списка позитивных проверок пункт 6 необходимо перенести в негативные, т.к. зарегистрироваться с занятым именем невозможно так же как с некорректным.

пункты 7 и 8 можно объединить в один, т.к. если проверка успешно проходит на 3-х символах, то на 4-х она тоже будет проходить (эквивалентные значения)

Таким образом я хотел проверить граничные значения(Указано что «Имя пользователя» может иметь от 3 до 26 символов) Если к примеру программист ошибся и указал >3 но не =>3. Или я не правильно понимаю что-то??

пункты 7 и 8 можно объединить в один, т.к. если проверка успешно проходит на 3-х символах, то на 4-х она тоже будет проходить (эквивалентные значения)

Таким образом я хотел проверить граничные значения(Указано что «Имя пользователя» может иметь от 3 до 26 символов) Если к примеру программист ошибся и указал >3 но не =>3. Или я не правильно понимаю что-то??

если программист ошибся и указал >3 но не =>3, то проверка на 3-х символах не пройдет и будет понятно, что это баг, а проверка на 4-х символах тут не нужна.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

Источник

четверг, 3 января 2013 г.

Тестируем регистрацию на сайте Люксор

И вот перед нами более-менее стандартная форма регистрации. Как будем тестировать?

Итак, какие поля обязательны на данном сайте? Кстати сказать, по правилам хорошего тона обязательные поля обычно отмечают звездочкой. Здесь это не сделано, очевидно, потому, что все поля являются обязательными. Но все ли?

Так как эта формочка довольно простая, то даже без спецификации можно догадаться, что данное поле нужно для того, чтобы человек, вводя длинный, правильный (то есть сложный) пароль, не ошибся. Поэтому система сверяет пароль из поля «Пароль» и пароль из поля «Подтвердите пароль» и, если они отличаются, выводит соответствующее сообщение об ошибке.

На данном сайте такой проверки нет. Но ведь тогда и поле не имеет смысла. Итак, теперь можно с чистой совестью писать баг:

Ожидаемый результат
Видим сообщение об ошибке, что введенный пароль не совпадает с паролем, введенным в поле «Подтвердите пароль».

Итак, user-story, как я дошла до жизни такой, а точнее, до такого блог-поста:

Например, «я люблю ходить в кино и поэтому, прочитав такие-то книжки, я решил попробовать свои силы на любимом сайте и провести функциональное тестирование системы. Я открыл формочку регистрации и провел такие-то и такие-то тесты. Сделал я это потому-то и потому-то. И даже баги нашел, представляете? Такие-то и такие-то. И даже в суппорт им написал, вот так-то и так-то (тут мы показываем, как умеем красиво, четко и понятно формулировать баги)«. Это будет показывать как минимум вашу заинтересованность, ваш энтузиазм и стремление учиться!

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнение

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

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

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

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

Бонус: BugMagnet

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

Источник