Любое текстовое поле в создаваемом программном обеспечении кажется таким простым и понятным функционалом, что процесс тестирования сводится к банальной проверке правильности его заполнения. Но, это только на первый взгляд.
Проверять правильность работы текстового поля нужно с особой тщательностью, ведь с его помощью можно очень быстро получить несанкционированный доступ к базе данных!Процесс валидации текстовой формы при функциональном тестировании – это первая среди всех проверок, которая поможет предотвратить манипуляции с пользовательскими файлами и данными. Также это своего рода защита перед появлением в БД вредной информации.
Подобные вирусные файлы могут вызвать проблемы с функционированием веб-продукта как на стороне клиента, так и на стороне сервера. Ну и наконец, корректная валидация позволяет сразу же предотвратить атаки межсайтового скриптинга и вредоносных SQL-инъекций хакеров.
Основные типы проверки текстового поля
Проверять работоспособность текстового поля можно очень многими способами. Мы выделим наиболее важные проверки, которые QA-специалист должен выполнять в обязательном порядке при тестировании текстовых полей.
Тестирование форм без спецификации
Итак, представим, что необходимо проверить текстовое поле, о котором нет особой информации в спецификации на проекте.
В подобной ситуации можно выполнить следующие проверки:
- Нажать на кнопку «Готово», без предварительного заполнения формы.
- Несколько раз нажать на клавишу пробела внутри формы, а затем кликнуть на кнопку подтверждения.
- Проанализировать, сколько можно ввести символов в форму, с последующим нажатием кнопки «Готово».
- Ввести минус, затем ввести максимальное количество цифр и нажать на клавишу подтверждения.
- Ввести все доступные специальные символы и нажать на кнопку отправки формы. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.
- Попробуйте ввести символы, которые технически не относятся к ASCII, разные эмоджи и нажмите на Submit. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.
- Испытайте возможность выполнения межсайтового скриптинга. Для этого нужно ввести такой сценарий: <script>alert(«I hacked this!»)</script>. Если после нажатия на кнопку отправки формы отобразится всплывающий поп-ап, значит данное текстовое поле максимально уязвимо для XSS-атаки.
- Проверьте возможность ввода SQL-инъекции. Введите FOO’); DROP TABLE USERS. Но ни в коем случае не совершайте подобные манипуляции с базами данных сайтов, которые уже запущенны онлайн.
Проверка полей на основе технической документации
Представим, что мы кое-что знаем о формах, знаем какие примерные значения можно вводить в форму, а также каковы ограничения в них установлены.
Тестирование поля с известными данными
Итак, что мы можем конкретного проверить:
- Возможность ввода значения с данными, которые отличаются от ожидаемого. Например, если форма поддерживает символы цены (цифры), пробуем ввести слова или дату.
- Если поле создано для ввода строки, пробуем ввести строку всего на один символ короче/длиннее чем нужно, а также минимально/максимально допустимое количество символов.
- Если поле по своему типу цифровое и ожидает цельное число, вводим число с десятичной дробью.
- В случае цифрового поля, рассчитанного на цифру с плавающей точкой, вводим значение с запятой и значение, которое будет начинаться с запятой.
- Если поле рассчитано на ввод стоимости, набираем значение с двумя символами после знака запятой.
- Если поле считывает формат даты, пробуем ввести минимально/максимально допустимую дату, на 1 день меньше минимума/больше максимума, или же дату на 100 лет больше или меньше от установленных технических границ.
- Для поля даты пробуем ввести абсурдную дату, к примеру, 12/13/19.
- Если поле считывает формат времени, можно попробовать вести бессмысленное время, как пример, 24:21.
- Если поле считывает формат номера телефона, проверяем возможность ввода телефона, который в корне не соответствует установленному формату.
Для всего вышеизложенного перечня проверок стоит выяснить, какие именно сообщения об ошибке отображаются и убедится в том, что все сообщения при валидной отправке тоже корректны.
Тестирование текстовых полей + автоматизация
Без автоматизации тестирования в данном случае тоже никак не обойтись.
Если тестировщик выполнил полный перечень ручных проверок, скорее всего нет надобности в автоматизации тестов. Более того, множество форм состоит из нескольких полей, а значит масса тестов для каждого по отдельности – это огромное количество потраченного времени на их выполнение.
Тем не менее, целесообразной будет автоматизация следующих пунктов:
- Ввод пустого поля и нулевого значения;
- Ввод значения, которое отвечает техническим критериям спецификации (так называемый, happy script);
- Возможность ввода максимальной длины и/или минимального значения;
- Ввод данных, которые превышают возможный максимум;
- Ввод данных меньше минимума из спецификации.
Конечно же, это неполный перечень того, что можно тестировать при проверке форм. Но данный список можно использовать как базовый набор проверок, которые стоит в обязательном порядке выполнять при работе с текстовыми формами.
Тестировщик никогда не должен верить разработчику на слово, что все и так работает, и незачем лишний раз себя утруждать монотонными проверками. Ведь при нахождении клиентом технической уязвимости, спросят в первую очередь именно с проверяющего!
Оставить комментарий