Вход в личный кабинет Проверка полей на основе технической документации
Представим, что мы кое-что знаем о формах, знаем какие примерные значения можно вводить в форму, а также каковы ограничения в них установлены.
Тестирование поля с известными данными
Итак, что мы можем конкретного проверить:
Для всего вышеизложенного перечня проверок стоит выяснить, какие именно сообщения об ошибке отображаются и убедится в том, что все сообщения при валидной отправке тоже корректны.
Важность: high
□ Актуальность адреса отправки.□ Прописан реальный e-mail лица, отвечающего за обработку заявок.
Важность: low
□ Вывод подсказок и ошибок сделан с анимационным эффектом.Замечание. Этот параметр зависит от дизайна и не является обязательным.
Далее — три спорных истории, которые нужно решать с менеджером на этапе проектирования.
□ Кнопка отправки данных неактивна, пока не активирован чекбокс «Согласиться с правилами», «Пользовательское соглашение».
□ Кнопка отправки данных неактивна, пока все введенные данные не прошли положительную валидацию.Откройте форму с полями для ввода, введите некорректные данные, проверьте, активна ли кнопка. Это важно. В некоторых случаях некорректность — понятие относительное. Подстава подстав — валидация номеров телефонов в форме обратной связи. Если вкратце — отключайте ее.
□ Если данные не прошли положительную валидацию, при наведении курсора на кнопку для отправки данных выводится информационное сообщение.Откройте форму, введите некорректные данные, наведите курсор на кнопку отправки данных, проверьте, выводится ли сообщение.
Список можно распечатать — пользуйтесь для тестирования юзабилити. То же самое — в документе Google.
Источник
Валидация
□ Для числовых значений из определенного диапазона прописаны ограничители минимального и максимального количества символов.□ Проверьте это для дат, времени и прочих подобных характеристик. Почему именно так. Простая подстраховка от ввода откровенного вранья или появления ошибок по невнимательности — даты рождения в будущем или времени доставки раньше времени заявки.
□ Для полей, предполагающих загрузку файлов, прописан атрибут accept, определяющий тип загружаемых документов.Почему именно так. Если прописан атрибут accept, при выборе с жесткого диска пользователь видит только подходящие типы файлов для загрузки — например, doc и txt. Это исключает отправку документов в формате, не подходящем для обработки.
□ Для полей, валидация которых проходит через регулярное выражение, прописан атрибут pattern.Валидация — это проверка введенных пользователем данных на соответствие требованиям системы. Информация проверяется путем сверки с регулярным выражением, заданном в специальном формате.
Например, регулярное выражение 5 <5,10>для пароля означает, что он может состоять только из цифр, а его длина колеблется от пяти до десяти символов. Если для поля прописан атрибут pattern, то форма не отправляется, пока данные не будут введены верно.
□ Требуемый формат данных, которые должен ввести пользователь, очевиден для него. Почему именно так. Пользователь должен понимать, чего от него ждут при вводе данных. Для этого предназначены краткие пояснения вроде «Пароль состоит не менее чем из 8 символов и включает цифры и латинские буквы».
□ Доступна инструкция по формату вводимых данных на человеческом языке. Почему именно так. Очевидная и понятная подсказка позволяет быстро разобраться в причинах ошибки и не чувствовать себя тупым при заполнении полей формы.
□ Пользователь не видит регулярного выражения как подсказки к действию. Почему именно так. Подсказка у поля индекса, представляющая собой регулярное выражение 7, малоинформативна. Фраза «Индекс состоит из цифр от 0 до 9» намного понятнее пользователю.
□ Сообщения об ошибках понятны обычным пользователям и логичны.
Важно. Типовая ошибка — регулярное выражение в сообщении о неверном заполнении формы.
Граничные значения
Граничные значения отделяют один интервал от другого. Их обязательно надо тестировать. Потому что именно на границах чаще всего встречаются баги. Почему? Да потому что попадают в оба диапазона, или не попадают ни в один.
В нашем примере в ТЗ есть условие «регистрация только для лиц старше 18 лет». Это значит, что разработчик должен сделать в коде программы логику вида:
Если у нас граница сдвинута, а мы не тестируем пограничные значения, то можем легко пропустить этот баг. Ведь мы проверили:
Мы найдем этот баг проверкой граничного значения 18. А если на 18 работает и на числе внутри диапазона (например, 26) работает — значит, код написан верно. То есть чтобы в коде был баг, это как надо извратиться то, написать что-то типа:
Такое только специально можно сделать)) Ну а если рассчитывать на разработчика-дурака со злыми шутками в виде таких пасхалок, то остается только полный перебор делать. Так что давайте считать коллег адекватными людьми.
Но! Что, если разработчик описывает работу кода для нескольких интервалов? Тогда при опечатке диапазоны идут внахлест:
Источник
Интеграционное тестирование
Интеграционное тестирование проводится для того, чтобы убедиться, что ваше приложение совместимо со сторонними сервисами.
Корректные значения
Представьте, что у вас буквально 5 минут на проверку функционала. И вы успеваете провести только первые несколько тестов из чек-листа. А чек-лист у вас:
В итоге эти проверки провели и считаете, что система работает нормально (ну ругается же!). А она всегда ругается, даже на корректное значение! Нехорошо… Поэтому запоминаем правило:
Для поля с возрастом какие у нас будут корректные значения? Все, что выше 18 лет:
Тут надо понимать, что мы выбираем какое-то ОДНО значение. Просто каждый раз разное, для избежания эффекта пестицида.
Также важно понимать, что у нас может быть не одно корректное значение. Это когда у нас есть несколько диапазонов, и разные условия на каждом.
Например, тот же возраст:
Тогда мы понимаем, что у нас есть уже два «валидных» диапазона. Значит, нам нужно взять значение из каждого. Например, 16 и 26.
Или если у нас идет расчет страховки в зависимости от стажа вождения:
Получается 5 интервалов. И нам надо взять по одному значению из каждого. Например: 0.5, 2, 4, 6, 15.
Каждый раз берем разные значения, но в этом пункте смысл один — взять корректные значения из ТЗ.
Кросс-платформенное тестирование
Кросс-платформенное тестирование проводится, чтобы убедиться, что ваше приложение совместимо с другими браузерами, различными оболочками, аппаратным обеспечением устройства.
Навигация
□ Предусмотрены плейсхолдеры (placeholder) для полей.□ Если названия полей не подписаны, то внутри полей выводится подсказка, которая исчезает при внесении текста.
Почему именно так. Пользователям нужны инструкции, а проектировщикам и дизайнерам — компактный способ предоставления информации.
□ Прописан атрибут autocomplete для полей, поддерживающих это значение.Атрибут autocomplete подставляет ранее введенные пользователем данные в поле, если функция не отключена в браузере.
Почему именно так. Чем быстрее пользователь заполнит форму, тем выше вероятность, что он ее отправит.
□ Правильная работа многошаговых форм.□ Навигация рядом с формой показывает текущий этап и количество оставшихся шагов. Почему именно так. Неизвестность пугает посетителей и снижает вероятность полного заполнения объемной формы.
Замечание. На некоторых проектах мы отказались от стандартной регистрации в пользу авторизации через социальные сети. Пример: Restlook.
□ Многошаговые формы корректно работают при навигации посредством кнопок «Вперед» и «Назад» в браузере.
Наш чек-лист для форм на сайтах
Это вторая часть наших чек-листов. В первой мы подробно разобрали требования к фильтрам. В отличие от фильтров, требования к пользовательским формам более универсальны. Однако нам потребовалось несколько жарких дискуссий, чтобы выработать более-менее единый формат.
□ Сохранение формы.□ Форма сохраняется в веб-формах (админ-панели) или SQL-таблицах.
□ Изменение адреса отправки.□ E-mail, на который приходят данные из веб-формы, можно менять в административной панели.
Некорректные значения
Тут есть разные варианты. Что значит некорректное значение?
Вернемся к примеру с возрастом. Корректное значение — старше 18 лет. Значит, мы должны задать вопрос:
— А что будет, если мы возьмем значение из «неправильного» диапазона? Что, если мне меньше 18 лет? Ну, скажем, 10.
Потом внимательно смотрим на выбранный интервал:
— Хммммм, но ведь возраст не может быть меньше 0. То есть у нас есть логическая граница, разделяющая два разных класса эквивалентности:
Так что надо взять значение из каждого диапазона. Тогда получается 10 и «-5»:
— Если у нас есть некая логическая граница снизу, должна быть и сверху. Какой максимально возможный возраст у регистрирующихся на нашем сайте? Скорее всего, это около 55-65 лет, потому что более старшее поколение не любит компьютеры. Но можно заложить и условные 100-110 лет долгожителей.
Получаем еще один интервал с неявной границей. Но в любом случае, значения 25 и 145 будут различаться — одно реалистичное, а другое нет. Значит, стоит его тоже попробовать!
А дальше снова эффект пестицида. Один раз берем 145, а другой — 6666666.
Тут мы можем столкнуться с тем, что в поле нельзя ввести больше 2-3 символов. Разработчик перестраховался «от дурака». Это не повод опускать руки и отказываться от своей проверки. Потому что скорее всего разработчик просто установил maxlength на поле, а он легко обходится!
Особые случаи
– применить все варианты некорректных данных, включая запрещенные символы, и пограничные значения;
– передать еше какой-нибудь параметр из существующих, напр. «login=bla-bla&password=bla-bla&state=update»
Прочее
□ Форма запрашивает у пользователя только необходимые данные.Откройте форму, визуально убедитесь, что требуется внести только необходимый минимум информации. Почему это важно. Объемные формы убивают конверсии. Регистрация, покупка или обратная связь должны быть максимально простыми, чтобы не путать пользователей.
□ Если все поля обязательны для заполнения, рядом с их названиями не выводятся звездочки — символ *.Откройте форму и убедитесь в этом визуально. Желательно наличие поясняющего текста об обязательном заполнении всех полей.
□ Для авторизованного пользователя в поля формы автоматически подставляются все известные о посетителе данные.Убедитесь визуально, что указанная пользователем в профиле информация автоматически выводится в полях форм, запрашивающих эти данные.
□ Текстовое многострочное поле при вводе объемного сообщения изменяет высоту либо в правой части появляется скроллбар для просмотра всего содержимого.Откройте форму с текстовым многострочным полем, введите в него максимально большое количество символов.
Почему именно так. Многие пользователи перечитывают написанное перед отправкой. Нужно дать им возможность воспользоваться скролл-баром или просмотреть все сообщение в расширенном поле вместо перемещения по тексту с помощью стрелок клавиатуры.
□ В полях формы прописан корректный атрибут TYPE, сообщающий браузеру тип элементов формы.□ Правильно указаны типы дат, времени, телефонов, диапазонов, url, e-mail, чисел.
□ Во время отправки формы на медленном канале пользователь не может менять в ней данные.Важно. Действительно для ajax-форм. Почему именно так. При невысокой скорости соединения форма ajax отправляется не сразу, некоторое время оставаясь на экране со всей внесенной информацией.
Пользователь не должен в этот момент передумать и поменять все данные. Точнее, передумать он как раз может, но реализовать свою задумку — уже нет: необходима блокировка от изменений до момента получения ответа от сервера. При этом желательно визуально показать, что форма заблокирована. Один из вариантов — прелоадер:
Резюме
Мы ознакомились с универсальной шпаргалкой по тестированию WEB приложений. Не забывайте читать документацию и дополнять чек-лист проверками, характерными для вашего сервиса. А если остались вопросы — скорее пишите в телеграм-канал
Самые простые и эффективные способы тестирования поля ввода текста
Любое текстовое поле в создаваемом программном обеспечении кажется таким простым и понятным функционалом, что процесс тестирования сводится к банальной проверке правильности его заполнения. Но, это только на первый взгляд.
Проверять правильность работы текстового поля нужно с особой тщательностью, ведь с его помощью можно очень быстро получить несанкционированный доступ к базе данных!
Процесс валидации текстовой формы при функциональном тестировании – это первая среди всех проверок, которая поможет предотвратить манипуляции с пользовательскими файлами и данными. Также это своего рода защита перед появлением в БД вредной информации.
Подобные вирусные файлы могут вызвать проблемы с функционированием веб-продукта как на стороне клиента, так и на стороне сервера. Ну и наконец, корректная валидация позволяет сразу же предотвратить атаки межсайтового скриптинга и вредоносных SQL-инъекций хакеров.
Основные типы проверки текстового поля
Проверять работоспособность текстового поля можно очень многими способами. Мы выделим наиболее важные проверки, которые QA-специалист должен выполнять в обязательном порядке при тестировании текстовых полей.
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности нашего приложения.
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации WEB приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют. Тестирование локализации включает тестирование WEB приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Тестирование текстовых полей автоматизация
Без автоматизации тестирования в данном случае тоже никак не обойтись.
Если тестировщик выполнил полный перечень ручных проверок, скорее всего нет надобности в автоматизации тестов. Более того, множество форм состоит из нескольких полей, а значит масса тестов для каждого по отдельности – это огромное количество потраченного времени на их выполнение.
Тем не менее, целесообразной будет автоматизация следующих пунктов:
Конечно же, это неполный перечень того, что можно тестировать при проверке форм. Но данный список можно использовать как базовый набор проверок, которые стоит в обязательном порядке выполнять при работе с текстовыми формами.
Тестировщик никогда не должен верить разработчику на слово, что все и так работает, и незачем лишний раз себя утруждать монотонными проверками. Ведь при нахождении клиентом технической уязвимости, спросят в первую очередь именно с проверяющего!
Источник
Тестирование удобства использования
Тестирование удобства использования подразумевает проверку навигации, контента, другая информация для пользователя.
Тестирование форм без спецификации
Итак, представим, что необходимо проверить текстовое поле, о котором нет особой информации в спецификации на проекте.
В подобной ситуации можно выполнить следующие проверки:
Тестируем регистрацию на сайте люксор
Всех новичков беспокоит вопрос – а откуда набираться опыта, знаний? Что бы потестить, в конце то концов??? Ответ прост – да все, что угодно. Вон, на форуме пишут, что люди, начитавшись Савина, даже лужи тестируют
Давайте рассмотрим простой пример, например, регистрацию на сайте довольно известного кинотеатра – Люксор.
Итак, открываем сайт – http://www.luxorfilm.ru/cinema/center/
Нажимаем справа сверху кнопку “Войти”, а потом – регистрация.
И вот перед нами более-менее стандартная форма регистрации. Как будем тестировать?
Во-первых, самое святое – это позитивный тест-кейс, то есть нормальная регистрация. Но, честно говоря, когда я вижу такие формы, я редко могу устоять и сначала провожу другой позитивный тест – на обязательность заполнения всех полей.
То есть, ничего не трогая, сразу нажимаем на “Сохранить”. Наверняка у нас на более сложные формочки будет спецификация, в которой четко прописано, какие поля обязательны для заполнения, а какие – нет.
Итак, какие поля обязательны на данном сайте? Кстати сказать, по правилам хорошего тона обязательные поля обычно отмечают звездочкой. Здесь это не сделано, очевидно, потому, что все поля являются обязательными. Но все ли?
Тут мы замечаем одну интересную вещь – около полей “подтвердите пароль” и “введите код из картинки” не появилось сообщений об ошибке. Хммм…
Но, прежде чем бежать регистрировать баг, давайте убедимся, что эти поля действительно необязательны для заполнения. Бывает и такое, что, если не заполнены “основные” поля, сообщения об ошибках появляются только около них. А заполнишь их – сообщения появятся и около других полей. Так у нас и происходит с полем кода картинки. Заполняем строго те поля, около которых появились сообщения об ошибках и видим следующую картину:
Окей! Заполняем код из картинки и нажимаем сохранить – ага, пароль сбросился, это, в принципе, правильно. Заполняем пароль и код из картинки… И регистрация проходит успешно!
Тут в нашу голову наверняка закралось сомнение – а зачем нам вообще нужно поле “Подтвердите пароль”, если его необязательно заполнять?
Так как эта формочка довольно простая, то даже без спецификации можно догадаться, что данное поле нужно для того, чтобы человек, вводя длинный, правильный (то есть сложный) пароль, не ошибся. Поэтому система сверяет пароль из поля “Пароль” и пароль из поля “Подтвердите пароль” и, если они отличаются, выводит соответствующее сообщение об ошибке.
На данном сайте такой проверки нет. Но ведь тогда и поле не имеет смысла. Итак, теперь можно с чистой совестью писать баг:
——————————————————————————————————————-
Шаги для воспроизведения:
- Открываем сайт
- Нажимаем на кнопку “Войти”
- Нажимаем на кнопку “Регистрация” (можно было изначально дать линк на http://www.luxorfilm.ru/Users/Registration.aspx, но ведь название странички может и измениться, поэтому такую ссылку вставить можно, но как дополнение к шагам. Да да, шаги тоже могут изменяться, но их суть часто остается прежней)
- Заполняем все поля, кроме “Подтвердите пароль”.
- Нажимаем “Регистрация”.
Результат
Пользователь успешно создан.
Ожидаемый результат
Видим сообщение об ошибке, что введенный пароль не совпадает с паролем, введенным в поле “Подтвердите пароль”.
Иначе, если поле “Подтвердите пароль” не обязательно для заполнения – его лучше вообще убрать с формы, так как никакой смысловой нагрузки оно не несет.
——————————————————————————————————————-
Отлично. обязательность полей проверили, позитивный тест-кейс на успешную регистрацию тоже проверили. Параллельно нашли usability багу – когда ставишь курсор в какое-либо поле, ты не видишь его там. То есть, если пользователь переключается между полями с помощью кнопки Tab, он не видит, срабатывает такой переход или нет… Это некритично, но неудобно – заводим минорную багу, когда поправят, тогда поправят.
Кстати, насчет заведенной нами баги про обязательность поля. Казалось бы, ну кто будет так делать, да? Оставлять поле пустым? По крайней мере, специально… А как вы думаете, я на это наткнулась – занималась в праздники тестированием рандомных сайтов?
Итак, user-story, как я дошла до жизни такой, а точнее, до такого блог-поста:
Собрались мы “назавтра” в кино. Разумеется, чтобы места были хорошими, их лучше забронировать заранее, например, вечером предыдущего дня. Открываю сайт Люксора – не открывается 
Мда, бывает с ним такое… Ладно, тогда пытаюсь забронировать билеты на следующий день, уже перед выходом. Ура, сайт работает! Выбираем сеанс, места, подтверждаем, что согласны с условиями бронирования и-и-и-и… А где кнопка “забронировать”???
Да что ж такое-то… Ладно, вон там есть кнопка “Войти”, может, если войти в систему, то будет бронь работать? Сомнительно, конечно, но вдруг? Итак, регистрируемся, email, ФИО, пол… А хотя зачем им моя дата рождения? Нажимаем сразу “Регистрация”!
Упс, логин и пароль не заполнила, и правда, куда без них. Заполняем, нажимаем “регистрация”, и… Взгляд утыкается в строку “подтвердите пароль”, которую я, разумеется, не заполнила, так как спешу и мысли о другом. Что сказали заполнить, то и заполнила… И вот сейчас сайт продумается и выдаст мне новое сообщение об ошибке… А так как он сегодня тугодум, то это лишнее время…
И вдруг перед моим изумленным взором возникает сообщение об успешной регистрации о_О
А ведь не искала специально…
Но что-то мы отвлеклись. Раз уж решили обсудить, как будем тестировать эту формочку, то давайте закончим рассуждения:
- Проверяем обязательность заполнения полей – нажимаем “Сохранить”, ничего не заполнив, смотрим, где появились сообщения об ошибках.
- Проверяем план-минимум, то есть заполняем только обязательные поля и убеждаемся, что внутри системы не зашито обязательным какое-то необязательное поле.
- Проверяем план-максимум, то есть заполняем вообще все, а после регистрации в личном кабинете проверяем, что информация сохранилась правильно.
- Пока мы прошли первые 3 шага, заодно проверили и юзабилити формы регистрации, вон, даже багу нашли.
- Теперь пора докапываться до самих полей. Итак, заполняем все поля корректно, кроме поля “email” – вводим туда что-нибудь, не являющееся email-ом. Ок, сообщение об ошибке есть. Отлично. Копаем дальше – а если email невалидный, но содержит “@”? А если он косит под валидный, но не является стандартным? Например, [email protected]? Итд. Сверяем со спецификацией – какие проверки должны быть у поля, соответствуют ли они реальности? Потом смотрим, а какова максимальная длина поля? О, 64 символа? Вводим граничное значение, проверяем, что работает. Потом вводим 65 символов, проверяем, что не работает. Потом ищем технологическую границу (то есть вводим ооооочень длинное значение, ну, скажем, нажимаем “9” и зажимаем кнопочку секунд на 5-10) – вдруг сайт упадет?
- Остальные поля, например, ФИО, проверяем на длину, если нет других ограничений.
- Вот разве что дата требует отдельного внимания. У меня, например, календарь вообще не открывается, можете кидать помидоры в сторону ИЕ, но мне лениво пробовать в мозилле. Хотя, если бы надо было протестировать, протестировала бы везде. Опять же, прежде чем заводить багу “не открывается popup календаря”, надо локализовать проблему – он вообще не открывается или только в вашем браузере? Когда видите такие проблемы в веб-приложениях, всегда локализовывайте проблему. Далее. Вводим дату вручную – корректную, нижнюю границу (что-то типа 01.01.0001) и верхнюю (01.01.3333), веб-сайты, кстати, часто падают на таких некорректных значениях просто потому, что они не могут их обработать, код соответствующий не написан.
И последний, 8 пункт – на закуску осталось самое интересное. Казалось бы, на такой простой формочке уже все проверено? Ан нет. Попробуйте ввести неправильные данные, а потом – правильные. Желательно иметь доступ к БД, чтобы быть точно уверенным, что тест корректный.
А именно – вводим все поля, выбирая логин, например, “а1”. А вот email указываем некорретный. Появляется сообщение об ошибке, мы ее исправляем и снова пытаемся зарегистрироваться. Но теперь нам выводится сообщение о том, что пользователь “а1” уже существует в системе! Но ведь он не был зарегистрирован!
Вот для того, чтобы в этом убедиться, нам и нужна БД – изначально делаем select, проверяя, что пользователя “а1” в системе нет. Потом регистрируем его так, чтобы регистрация не удалась, а потом корректно. И если мы видим сообщение об ошибке “пользователь “а1″ уже существует в системе” – смело идем и регистрируем багу. Так как при ошибочном вводе транзакция должна откатываться, а не сохраняться в БД.
Резюмируем:
- Обязательность полей.
- План-минимум.
- План-максимум.
- Юзабилити.
- Длина полей для ввода.
- Спец проверки для email.
- Спец проверки для даты.
- Корректный ввод после некорректного.
Кстати, хочу заметить, что, если вы новичок и имеете только теоритический опыт, гораздо лучше будет, если, приходя на собеседования, вы не просто будете важно заявлять “Я прочитал Савина”, а показывать, как вы применили эти знания. Или хотя бы пытались применить.
Например, “я люблю ходить в кино и поэтому, прочитав такие-то книжки, я решил попробовать свои силы на любимом сайте и провести функциональное тестирование системы. Я открыл формочку регистрации и провел такие-то и такие-то тесты. Сделал я это потому-то и потому-то. И даже баги нашел, представляете? Такие-то и такие-то. И даже в суппорт им написал, вот так-то и так-то (тут мы показываем, как умеем красиво, четко и понятно формулировать баги)“. Это будет показывать как минимум вашу заинтересованность, ваш энтузиазм и стремление учиться!
Просто попробуйте, открыть часто посещаемый сайт и попробовать его протестировать. Это поможет вам структурировать свои знания и чувствовать себя увереннее! А иначе получится так, что – приходишь на собеседование, четко рассказываешь заученные формулировки функционального и нагрузочного тестирования… А потом тебе дают простенькую формочку – “как будешь тестировать?”. И все, ты начинаешь волноваться, разом забываешь только что рассказанные определения, путаешься в показаниях и прочая прочая.
А если ты уже сам, дома, посидел над любой формочкой, подглядывая в книгу, поразмышлял, а какое тут возможно функциональное/smoke/нагрузочное тестирование, то и сидя на собеседовании, ты будешь чувствовать себя увереннее – потому что ты уже практиковался, а значит, есть не просто слова, а понимание этих слов.
PS — и напоследок, еще одна бага из этого кинотеатра. Пришли мы в зал, места 9 и 10. Сели. И тут я смотрю перед собой – на спинках впереди-сидящих ведь тоже дублируются номера кресел. И что я вижу? После 9 идет 12
На самом деле там забавнее, идет такая нумераци – 8, 9 , 12, 11, 12. Но сфотографировать это не удалось, увы. Вот вам и еще одна бага! Зато забавная:
– У тебя какое место?
– 12.
– Тебе справа или слева?
PPS — а еще про одну багу я писала позднее, на этот раз про бронирование билетов на сайте.
PPPS — добавила пост в общую копилку багов.
Тестируемый компонент: авторизация на сайте — мегалекции
Составить тест-кейсы на тестирование формы авторизации на страничке.
Форма авторизации имеет:
· поле ввода электронной почты (электронная почта служит логином для авторизации, поддерживает по документации до 20 символов);
· поле ввода пароля (поддерживает по документации до 20 символов);
· чекбокс «Запомнить почту и пароль» (по умолчанию неактивен);
· кнопку «Авторизироваться».
После успешной авторизации пользователь должен увидеть сообщение “Всё окей”. В случае неудачной авторизации пользователь должен увидеть сообщение “Извини, не в этот раз”.
Комментарии к спеку:
· не указано в спеке до 20 символов в поле ввода электронной почты и пароля: включительно или нет? (я взял не включительно, то есть максимум 19 символов);
· не указано минимально допустимое количество символов в поле ввода электронной почты и пароля (создал тест-кейс для тестирования пустых полей ввода);
· не указано какие символы допустимы в пароле;
· не указано название сайта (я принял его за «example.ru»);
· не указаны координаты расположения формы авторизации на веб-странице;
· при необходимости можно дополнить тест-комплект тест-кейсами на проверку клавиш «Backspace» и «Escape».
Среда выполнения: Google Chrome 41.0.2272.101 m.
Тестируемый компонент: Авторизация на сайте
Комментарий: Используй Логин[email protected] и Пароль=123456789Abcdef для успешной авторизации на сайте.
| Номер тест-кейса:008 | Названия тест кейса: Проверка поля ввода пароля на количество знаков | |
| Предусловие | 1) перейти на сайт; 2) если вы уже авторизированы – выйдите из вашего аккаунта; 3) галочка снята в чекбоксе «Запомнить почту и пароль» | |
| № шага | Шаги к воспроизведению | Ожидаемый результат |
| Ввод в поле ввода пароля «123456789Abcdefghij» – 19 знаков | Значение в поле ввода пароля (19 знаков):******************* | |
| Ввод в поле ввода пароля «123456789Abcdefghijk» – 20 знаков | Значение в поле ввода пароля (19 знаков):******************* | |
| Ввод в поле ввода пароля «123456789Abcdefghijklmno» – 24 знаков | Значение в поле ввода пароля (19 знаков):******************* | |
| Окончание тест-кейса |
| Номер тест-кейса:009 | Названия тест кейса: Проверка полей ввода электронной почты и пароля на математические символы, знаки пунктуации, пробел | |
| Предусловие | 1) перейти на сайт; 2) если вы уже авторизированы – выйдите из вашего аккаунта; 3) галочка снята в чекбоксе «Запомнить почту и пароль» | |
| № шага | Шаги к воспроизведению | Ожидаемый результат |
| Ввод в поле ввода пароля «#№!;$%:^&?*(@») =*/ .->» – 24знака | Значение в поле ввода пароля (19 знаков):******************* | |
| Ввод в поле ввода электронной почты ««#№!;$%:^&?*(@») =*/ .->» – 24 знака | Значение в поле ввода электронной почты (19знаков): #№!;$%:^&?*(@») =*/ | |
| Ввод в поле ввода пароля «#№!;$%:^&?*(@») =*/ » – 20 знаков | Значение в поле ввода пароля (19 знаков):******************* | |
| Ввод в поле ввода электронной почты «#№!;$%:^&?*(@») =*/ » – 20 знаков | Значение в поле ввода электронной почты (19знаков): #№!;$%:^&?*(@») =*/ | |
| Ввод в поле ввода пароля «#№!;$%:^&?*(@») =*/» – 19 знаков | Значение в поле ввода пароля (19 знаков):******************* | |
| Ввод в поле ввода электронной почты «#№!;$%:^&?*(@») =*/» – 19 знаков | Значение в поле ввода электронной почты (19знаков): #№!;$%:^&?*(@») =*/ | |
| Кликнуть левой клавишей мыши по кнопке «Авторизироваться» | 1) Авторизация не выполнена 2) Сообщение на экране «Извини, не в этот раз» | |
| Окончание тест-кейса |
| Номер тест-кейса:013 | Названия тест кейса: Проверка авторизации при смене раскладки клавиатуры | |
| Предусловие | 1) перейти на сайт; 2) если вы уже авторизированы – выйдите из вашего аккаунта; 3) галочка снята в чекбоксе «Запомнить почту и пароль» | |
| № шага | Шаги к воспроизведению | Ожидаемый результат |
| Ввод в поле ввода электронной почты «Фгерю»нфтвучюкг» | Значение в поле ввода электронной почты: Фгерю»нфтвучюкг | |
| Ввод в поле ввода пароля «123456789ФИСВУА» | Значение в поле ввода пароля:*************** | |
| Кликнуть левой клавишей мыши по кнопке «Авторизироваться» | 1. Авторизация не выполнена 2. Сообщение на экране «Извини, не в этот раз» | |
| Окончание тест-кейса |
| Номер тест-кейса:014 | Названия тест кейса: Проверка максимального количества неуспешных попыток авторизации | |
| Предусловие | 1) перейти на сайт; 2) если вы уже авторизированы – выйдите из вашего аккаунта; 3) галочка снята в чекбоксе «Запомнить почту и пароль» | |
| № шага | Шаги к воспроизведению | Ожидаемый результат |
| Ввод в поле ввода электронной почты «Фгерю»нфтвучюкг» | Значение в поле ввода электронной почты: Фгерю»нфтвучюкг | |
| Ввод в поле ввода пароля «123456789ФИСВУА» | Значение в поле ввода пароля:*************** | |
| Кликнуть левой клавишей мыши по кнопке «Авторизироваться» | 1.Авторизация не выполнена 2.Сообщение на экране «Извини, не в этот раз» | |
| Ввод в поле ввода электронной почты «Фгерю»нфтвучюкг» | Значение в поле ввода электронной почты: Фгерю»нфтвучюкг | |
| Ввод в поле ввода пароля «123456789ФИСВУА» | Значение в поле ввода пароля:*************** | |
| Кликнуть левой клавишей мыши по кнопке «Авторизироваться» | 1.Авторизация не выполнена 2.Сообщение на экране «Извини, не в этот раз» | |
| Ввод в поле ввода электронной почты «Фгерю»нфтвучюкг» | Значение в поле ввода электронной почты: Фгерю»нфтвучюкг | |
| Ввод в поле ввода пароля «123456789ФИСВУА» | Значение в поле ввода пароля:*************** | |
| Кликнуть левой клавишей мыши по кнопке «Авторизироваться» | 1.Авторизация не выполнена 2.Сообщение на экране «Извини, не в этот раз». 3. Сообщение на экране «Вы превысили максимально возможное число попыток авторизации. Ваш аккаунт заблокирован. Чтобы разблокировать аккант проверьте вашу почту». | |
| Окончание тест-кейса |
Воспользуйтесь поиском по сайту:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Чек-лист для тестирования числового поля
При тестировании встречаются как интересные задачки с замудреной логикой, так и простые, вроде проверки простой строки или числового поля. Для простых полей можно один раз написать чек-лист проверок, а потом переиспользовать, лишь немного меняя под «своё» поле.
Сегодня мы разберем чек-лист для числового поля. Сначала я напишу общий чек-лист, потом пройдемся по каждому пункту и разберемся, зачем он нужен, а в конце напишем чек-лист по этому шаблону.
Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст» при регистрации:
При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.
Какие проверки тут можно провести: