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

Подписаться

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

Конференции

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

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

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

.
Тестирование текстового поля
29.11.2019 00:00

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

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

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


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

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

  • Попробуйте ввести значение с типом данных, отличным от ожидаемого – к примеру, если поле ожидает ввода стоимости, попробуйте ввести текст или дату.
  • Если поле ожидает строку, попробуйте ввести строку на 1 символ короче, чем нужно, на 1 символ длиннее, чем нужно, минимально возможное количество символов, максимальное их количество, и количество, вдвое превышающее максимум.
  • Если поле ожидает числа, попробуйте ввести максимум, минимум, значение выше максимума и ниже минимума, и значение, вдвое превышающее максимум.
  • Если поле ожидает целого числа, попробуйте ввести десятичную дробью.
  • Если поле ожидает числа с плавающей точкой, попробуйте ввести значение с двумя запятыми и значение, начинающееся с запятой.
  • Если поле ожидает стоимости, попробуйте ввести значение с более чем двумя знаками после запятой.
  • Если поле ожидает даты, попробуйте ввести максимальную дату, минимальную дату, на день больше максимума и на день меньше минимума, и дату на сто лет больше или меньше границ.
  • Для полей дат попробуйте ввести бессмысленную дату – например, 6/31/17 or 13/13/17 (есть много способов тестировать поля дат, я затрону этот вопрос в другой статье).
  • Если поле ожидает времени, попробуйте ввести бессмысленное время – например, 25:15.
  • Если поле ожидает номера телефона, попробуйте ввести номер, не соответствующий ожидаемому формату (множество способов тестирования номеров я тоже затрону в другой статье).

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

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

  • Ввод нулевого значения.
  • Ввод пустоты.
  • Ввод значения, удовлетворяющего критериям ("счастливый сценарий").
  • Ввод максимальной длины или максимального значения.
  • Ввод минимальной длины или минимального значения.
  • Ввод значения, превышающего максимальную длину или допустимый максимум.
  • Ввод значения меньше минимума.

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

Обсудить в форуме