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

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

Однако примерно в это время я осознала, как важно проверять валидацию ввода. Когда у пользователя есть возможность добавлять в приложение данные, тут есть потенциал для злонамеренного использования или неожиданных последствий. Тестирование валидации ввода – это критически важная задача по нижеописанным четырем причинам.

Безопасность

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

• Межсайтовый скриптинг – взломщик вводит в текстовое поле скрипт. Если у поля нет валидации, удаляющей символы скрипта, значение сохранится и скрипт автоматически запустится, когда ничего не подозревающий пользователь перейдет на страницу. Выполненный скрипт может выдавать информацию об идентификаторе сессии пользователя, или даже вывести форму и попросить пользователя ввести пароль, который затем запишется в локацию, к которой у злоумышленника есть доступ.
• SQL-инъекция. Если текстовое поле позволяет такие символы, как точка с запятой, то взломщик может вводить значения, которые обманут базу данных и заставят ее выполнить SQL-команду. А она вернет такую информацию, как, скажем, логины и пароли всех пользователей сайта. Злоумышленник даже сможет полностью стереть таблицу с данными посредством такой инъекции.
• Атака переполнения буфера. Если переменная сконфигурирована так, что на определенное количество символов отводится достаточно памяти, но в поле можно ввести куда больший по длине текст, память может переполниться и занять другие локации. Когда это происходит, взломщик может получить от этого выгоду, получив доступ к закрытой информации или возможность манипулировать приложением.

Стабильность

Если у пользователя есть возможность вводить данные, с которыми приложение не может справиться, то оно может среагировать неожиданным образом – например, упасть, или отказаться сохраняться. Вот ряд примеров:

• Мой индекс начинается с 0. Я сталкивалась с формами, в которых не могу сохранить свой адрес, потому что приложение удаляет ведущий ноль из индекса, а затем говорит мне, что в индексе недостаточно цифр.
• В фамилии моего коллеги есть и апостроф, и дефис. Он рассказывал, что ввод его фамилии часто ломает формы ввода.

Визуальное единообразие

Когда в поле слишком много символов, это может повлиять на отображение страницы. На это можно посмотреть, исследуя любое тестовое окружение. К примеру, если на странице контактов отображается список имен и фамилий, то зачастую можно увидеть, что какой-то дотошный тестировщик ввел "Оченьоченьоченьоченьоченьоченьдлинноеимя" в качестве контакта. Если такое имя приводит к излишней ширине страницы, требующей горизонтального скролла, то реальный пользователь на продакшене потенциально способен заставить страницу отображаться таким образом.

Здоровье базы данных

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

Поле ввода номера телефона – отличный пример того, как ошибочные данные могут повлиять на приложение. Я работала на компанию, где номера телефонов неверно валидировались годами. Когда мы обновляли приложение, мы хотели, чтобы телефоны автоматически форматировались, отображаясь в привлекательном формате: (800)-555-1000. Однако из-за значений в базе, выглядящих как "Папин номер", было невозможно все отформатировать, и это вызывало ошибки страницы.

Если поля валидируются неправильно, то в базе данных могут сохраниться ошибочные данные, и это повлияет и на стабильность приложения, и на его поведение.

Методичная валидация полей ввода может быть очень скучным делом, но примеры выше показывают, почему этим так важно заниматься. Хорошие новости: есть способы борьбы со скукой. Автоматические проверки валидации могут избавить нас от бесконечного прогона этих тестов вручную. Инструменты манки-тестинга могут помочь выявить баги. А немного фантазии позволит поддерживать тестирование интересным. Я сохранила текст песни "Frosty the Snowman" в отдельном файле. Если мне нужно проверить длину текстового поля, я вставляю туда куски текста. Если разработчик видит значения в базе вроде "Frosty the Snowman was a j", то знает, что там побывала я!

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