Рейтинг: 5.0/5. на основе 2 оценок.
Пожалуйста, подождите...

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

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

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

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

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

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

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

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

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

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

  • Нажать на кнопку «Готово», без предварительного заполнения формы.
  • Несколько раз нажать на клавишу пробела внутри формы, а затем кликнуть на кнопку подтверждения.
  • Проанализировать, сколько можно ввести символов в форму, с последующим нажатием кнопки «Готово».
  • Ввести минус, затем ввести максимальное количество цифр и нажать на клавишу подтверждения.
  • Ввести все доступные специальные символы и нажать на кнопку отправки формы. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.
  • Попробуйте ввести символы, которые технически не относятся к ASCII, разные эмоджи и нажмите на Submit. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.
  • Испытайте возможность выполнения межсайтового скриптинга. Для этого нужно ввести такой сценарий: <script>alert(«I hacked this!»)</script>. Если после нажатия на кнопку отправки формы отобразится всплывающий поп-ап, значит данное текстовое поле максимально уязвимо для XSS-атаки.
  • Проверьте возможность ввода SQL-инъекции. Введите FOO’); DROP TABLE USERS. Но ни в коем случае не совершайте подобные манипуляции с базами данных сайтов, которые уже запущенны онлайн.

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

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

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

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

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

  • Возможность ввода значения с данными, которые отличаются от ожидаемого. Например, если форма поддерживает символы цены (цифры), пробуем ввести слова или дату.
  • Если поле создано для ввода строки, пробуем ввести строку всего на один символ короче/длиннее чем нужно, а также минимально/максимально допустимое количество символов.
  • Если поле по своему типу цифровое и ожидает цельное число, вводим число с десятичной дробью.
  • В случае цифрового поля, рассчитанного на цифру с плавающей точкой, вводим значение с запятой и значение, которое будет начинаться с запятой.
  • Если поле рассчитано на ввод стоимости, набираем значение с двумя символами после знака запятой.
  • Если поле считывает формат даты, пробуем ввести минимально/максимально допустимую дату, на 1 день меньше минимума/больше максимума, или же дату на 100 лет больше или меньше от установленных технических границ.
  • Для поля даты пробуем ввести абсурдную дату, к примеру, 12/13/19.
  • Если поле считывает формат времени, можно попробовать вести бессмысленное время, как пример, 24:21.
  • Если поле считывает формат номера телефона, проверяем возможность ввода телефона, который в корне не соответствует установленному формату.

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

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

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

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

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

  1. Ввод пустого поля и нулевого значения;
  2. Ввод значения, которое отвечает техническим критериям спецификации (так называемый, happy script);
  3. Возможность ввода максимальной длины и/или минимального значения;
  4. Ввод данных, которые превышают возможный максимум;
  5. Ввод данных меньше минимума из спецификации.

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

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

Оставить комментарий