как протестировать текстовое поле

Чек-лист для тестирования числового поля

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

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

Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст» при регистрации:

При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.

Какие проверки тут можно провести:

Корректные значения

Представьте, что у вас буквально 5 минут на проверку функционала. И вы успеваете провести только первые несколько тестов из чек-листа. А чек-лист у вас:

Для поля с возрастом какие у нас будут корректные значения? Все, что выше 18 лет:

Тут надо понимать, что мы выбираем какое-то ОДНО значение. Просто каждый раз разное, для избежания эффекта пестицида.

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

Например, тот же возраст:

Или если у нас идет расчет страховки в зависимости от стажа вождения:

Каждый раз берем разные значения, но в этом пункте смысл один — взять корректные значения из ТЗ.

Некорректные значения

Тут есть разные варианты. Что значит некорректное значение?

— А что будет, если мы возьмем значение из «неправильного» диапазона? Что, если мне меньше 18 лет? Ну, скажем, 10.

Потом внимательно смотрим на выбранный интервал:

— Хммммм, но ведь возраст не может быть меньше 0. То есть у нас есть логическая граница, разделяющая два разных класса эквивалентности:

— Если у нас есть некая логическая граница снизу, должна быть и сверху. Какой максимально возможный возраст у регистрирующихся на нашем сайте? Скорее всего, это около 55-65 лет, потому что более старшее поколение не любит компьютеры. Но можно заложить и условные 100-110 лет долгожителей.

Получаем еще один интервал с неявной границей. Но в любом случае, значения 25 и 145 будут различаться — одно реалистичное, а другое нет. Значит, стоит его тоже попробовать!

А дальше снова эффект пестицида. Один раз берем 145, а другой — 6666666.

Тут мы можем столкнуться с тем, что в поле нельзя ввести больше 2-3 символов. Разработчик перестраховался «от дурака». Это не повод опускать руки и отказываться от своей проверки. Потому что скорее всего разработчик просто установил maxlength на поле, а он легко обходится!

Граничные значения

Граничные значения отделяют один интервал от другого. Их обязательно надо тестировать. Потому что именно на границах чаще всего встречаются баги. Почему? Да потому что попадают в оба диапазона, или не попадают ни в один.

В нашем примере в ТЗ есть условие «регистрация только для лиц старше 18 лет». Это значит, что разработчик должен сделать в коде программы логику вида:

Источник

Самые простые и эффективные способы тестирования поля ввода текста

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

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

Процесс валидации текстовой формы при функциональном тестировании – это первая среди всех проверок, которая поможет предотвратить манипуляции с пользовательскими файлами и данными. Также это своего рода защита перед появлением в БД вредной информации.

Подобные вирусные файлы могут вызвать проблемы с функционированием веб-продукта как на стороне клиента, так и на стороне сервера. Ну и наконец, корректная валидация позволяет сразу же предотвратить атаки межсайтового скриптинга и вредоносных SQL-инъекций хакеров.

Основные типы проверки текстового поля

Проверять работоспособность текстового поля можно очень многими способами. Мы выделим наиболее важные проверки, которые QA-специалист должен выполнять в обязательном порядке при тестировании текстовых полей.

Тестирование форм без спецификации

Итак, представим, что необходимо проверить текстовое поле, о котором нет особой информации в спецификации на проекте.

В подобной ситуации можно выполнить следующие проверки:

Проверка полей на основе технической документации

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

Тестирование поля с известными данными

Итак, что мы можем конкретного проверить:

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

Тестирование текстовых полей + автоматизация

Без автоматизации тестирования в данном случае тоже никак не обойтись.

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

Тем не менее, целесообразной будет автоматизация следующих пунктов:

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

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

Источник

Как протестировать текстовое поле

Что пишут в блогах

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Текстовое поле в приложении кажется таким обычным делом, однако это одна из наиболее важных вещей, которую мы можем протестировать. Почему? Потому что текстовые поля дают доступ к приложению и его базе данных. Валидация текстового поля – это то, что предотвращает появление в базе плохих данных. Эти данные могут вызвать разнообразные проблемы для пользователей и разработчиков. Валидация также предотвращает атаки межсайтового скриптинга и SQL-инъекции.

Тестировать текстовое поле можно миллионами способов, и я коснусь этих способов в статье. Для начала давайте представим, что мы тестируем текстовое поле, не имея никакой информации о том, что оно делает:

Затем давайте предположим, что мы что-то знаем о том, что должно вводиться в это поле, и каковы ограничения для данных:

Для всех вышеописанных тестов выясните, какое сообщение об ошибке вы должны получать, и убедитесь, что получаете правильное сообщение.

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

Это не исчерпывающий список, а просто способ подтолкнуть вас к размышлениям о большом количестве тестов, которые можно прогнать, тестируя единственное поле. Не верьте на слово, что разработчик, создававший поле, добавил нужную валидацию, проверьте ее сами! Как-то раз я тестировала поле ввода даты, у которого было ограничение на год – он не мог быть меньше 1900 или больше, чем текущий год. Я получала нужное сообщение об ошибке, вводя 1880, но даты 1300 года легко принимались!

Источник

Как протестировать текстовое поле

Моды для сервера

Огромный выбор различных модификаций для Вашего сервера. Пролистайте эти темы! Возможно именно там Вы найдете то, что искали уже давно.

Модификации SA

Хотите разнообразить свою игру в San Andreas? Смелее в наш раздел. Отличный сборник готовых решений. Играйте с удовольствием

ShTorm

Эксперт

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

Примерный алгоритм использования техники анализа граничных значений:
1. Во-первых, нужно выделить классы эквивалентности. Опять же, это очень важный шаг, и от правильности разбиения на классы эквивалентности зависит эффективность тестов граничных значений.
2. Далее нужно определить граничные значения этих классов.
3. Нам нужно понять, к какому классу будет относиться каждая граница.
4. Для каждой границы нам нужно провести тесты по проверке значения до границы, на границе, и сразу после границы.
Количество тестов для проверки граничных значений будет равно количеству границ, умноженному на 3. Рекомендуется проверять значения вплотную к границе. Например, если мы имеем диапазон целых значений, и граница у нас находится в
числе 10, то мы будем проводить тесты
❖ с числом 9 (вплотную до границы),
❖ 10 (саму границу)
❖ 11 (сразу после границы)

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

Источник

Валидация форм на стороне клиента

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

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

Однако, не следует рассматривать валидацию на стороне клиента как достаточную меру безопасности! Любые данные, отправляемые через форму, необходимо дополнительно проверять на безопасность и на стороне сервера, поскольку валидацию на стороне клиента достаточно просто обойти и она может не остановить злоумышленников. Чтобы лучше понимать потенциальные угрозы, рекомендуем ознакомиться с разделом Безопасность вебсайтов; валидация на стороне сервера выходит за рамки этого модуля, но о ней следует помнить.

Что такое валидация формы?

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

Это называется валидацией формы. По мере ввода, браузер и/или сервер проверяют данные, чтобы определить, соответствуют ли они требуемому формату. Валидация, выполняемая в браузере, называется валидацией на стороне клиента, а выполняемая на сервере — валидацией на стороне сервера. В этом разделе мы сосредоточимся на валидации, выполняемой на стороне клиента.

Если формат корректен, приложение позволяет отправить данные на сервер и (обычно) сохранить в базу данных; в противном случае выводится сообщение с описанием того, что нужно исправить, позволяя ввести данные снова.

Мы хотим максимально упростить заполнение веб-форм. Тогда почему мы настаиваем валидации данных? На это есть три основные причины:

Предупреждение:: Никогда не доверяйте данным, передаваемым на сервер клиентской программой. Даже если ваша форма правильно валидируется и не допустит введение потенциально вредоносных данных на стороне клиента, злоумышленники по-прежнему могут изменить сетевой запрос.

Типы валидации на стороне клиента

Существует два типа валидации на стороне клиента, с которыми вы столкнётесь в Интернете:

Использование встроенной валидации форм

Одной из самых важных функций элементов форм HTML5 является способность валидировать бóльшую часть пользовательских данных без использования JavaScript. Это выполняется с помощью атрибутов валидации у элементов формы. Многие из них мы уже рассмотрели в этом курсе:

Если данные, введённые в поле формы, соответствуют правилам перечисленных выше атрибутов, они считаются валидными, если нет — не валидными

Когда элемент валиден, справедливы следующие утверждения:

Когда элемент не валиден, справедливы следующие утверждения:

Примеры встроенной валидации форм

В этом разделе мы протестируем некоторые из атрибутов, которые обсуждали выше.

Простой начальный файл

Для начала скопируйте файл fruit-start.html в новую папку на вашем жёстком диске.

Атрибут required

Обратите внимание на CSS, который включён в файл примера:

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

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-validation.html (отдельно можно найти исходный код.)

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

Примечание: Для повышения удобства взаимодействия указывайте пользователям, какие поля являются обязательными. К тому же, этого требует руководство по обеспечению доступности WCAG. Требуйте обязательного ввода только тех данных, которые вам действительно нужны: например, так ли важно знать пол или должность пользователя?

Валидация с помощью регулярного выражения

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

Есть еще много возможностей, которые мы не упомянули. Полный список со множеством примеров можно найти в документации по Регулярным выражениям

Давайте рассмотрим пример. Добавьте в атрибут pattern следующий шаблон:

Это даёт нам следующее обновление — опробуйте его:

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-pattern.html (исходный код.)

В этом примере элемент принимает одно из четырёх возможных значений: строку «banana», «Banana», «cherry», или «Cherry». Регулярные выражения чувствительны к регистру, но с помощью шаблона «Aa», вложенного в квадратные скобки, мы сделали поддержку написания слова как с большой, так и с маленькой буквы.

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

Примечание: Элемент

Ограничение длины вводимых значений

Можно ограничить максимально допустимое количество символов для текстовых полей или

Ограничение допустимых значений

Давайте рассмотрим другой пример. Создайте новую копию файла fruit-start.html.

Содержимое элемента замените на:

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-length.html (исходный код.)

Полный пример

Ниже представлен полный пример, демонстрирующий использование встроенного функционала валидации. Сначала немного HTML:

И немного CSS для стилизации HTML:

Примечание: Рабочий пример можно найти на GitHub по адресу full-example.html (исходный код.)

Валидация форм с помощью JavaScript

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

Constraint Validation API

Большинство браузеров поддерживают Constraint Validation API, который состоит из набора свойств и методов, доступных на DOM-интерфейсах следующих элементов форм:

Для перечисленных выше элементов Constraint Validation API делает доступными следующие свойства.

Также для перечисленных выше элементов Constraint Validation API делает доступными следующие методы.

Реализация кастомного сообщения об ошибке

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

У этих автоматических сообщений есть два недостатка:

Настройка таких сообщений об ошибках является одной из наиболее распространённых причин использования Constraint Validation API. Давайте рассмотрим простой пример, как это делается.

Начнём с простого HTML (Не стесняйтесь поместить это в пустой HTML-файл. Вы можете взять за основу свежую копию fruit-start.html, если хотите):

Добавьте на страницу следующий JavaScript:

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

Попробовать пример можно ниже:

Примечание:: Данный пример можно найти на GitHub по адресу custom-error-message.html (отдельно можно найти исходный код.)

Более подробный пример

Теперь, когда мы разобрали простой пример, давайте посмотрим, как можно использовать данный API для создания более сложной валидацию.

Во-первых, HTML. Опять же, не стесняйтесь писать его вместе с нами:

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

Перейдём к базовому CSS, чтобы немного улучшить внешний вид формы и обеспечить визуальную обратную связь при введении не валидных данных:

Теперь давайте рассмотрим JavaScript, который реализует кастомную валидацию.

Комментарии объясняют логику хорошо, но кратко:

Примечание: Рабочий пример можно найти на GitHub по адресу detailed-custom-validation.html (отдельно можно найти исходный код.)

Constraint Validation API явяется мощным инструментом валидации форм, позволяющим получить контроль над пользовательским интерфейсом, существенно превосходящий возможности HTML и CSS.

Примечание: Для получения дополнительной информации смотрите руководства Constraint validation guide и Constraint Validation API.

Проверка форм без встроенного API

В некоторых случаях, например, при необходимости поддержки устаревших браузеров или кастомных элементов формы, вы не сможете или не захотите использовать Constraint Validation API. Вы по-прежнему сможете использовать JavaScript для валидации форм, но для этого всё нужно будет писать самостоятельно.

Для создания своего валидатора формы, задайте себе несколько вопросов:

Пример без использования Constraint Validation API

Чтобы проиллюстрировать это дальше приводится упрощённая версия предыдущего примера, которая работает с устаревшими браузерами.

HTML почти тот такой же; мы только удалили функционал валидации HTML5.

CSS также не требует особых изменений; мы только заменили CSS-псевдокласс :invalid на реальный класс и не использовали селектор по атрибутам, так как он не работает в Internet Explorer 6.

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

Результат выглядит следующим образом:

Как вы можете видеть, сделать собственную валидацию не так уж и сложно. Сложность состоит лишь в том, чтобы сделать его кроссплатформенным и работающим с любой формой, которую можно создать. Для проверки формы доступно множество библиотек, например Validate.js.

Проверьте свои навыки!

Вы дошли до конца этой статьи, но можете ли вы вспомнить самую важную информацию? Вы можете найти дополнительные тесты, чтобы убедиться, что вы сохранили эту информацию, прежде чем двигаться дальше — Test your skills: Form validation.

Заключение

Для проверки формы на стороне клиента иногда требуется JavaScript, если вы хотите настроить стилизацию и сообщения об ошибках, но это всегда требует от вас внимательного отношения к пользователю. Всегда помните о необходимости помогать пользователям исправлять данные, которые они вводят. Для этого обязательно нужно:

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

Источник