Вход в личный кабинет Безопасность
Злоумышленники могут использовать поля формы для получения информации или других вредоносных действий — это может быть сделано с помощью SQL-инъекций и вредоносных скриптов.
Стабильность
Когда пользователь вводит данные, которые не могут быть обработаны приложением, оно может среагировать неожиданным образом — например, упасть.
Корректное поведение UI и единообразие
Очень важно, чтобы все формы в приложении были единообразны (и по внешнему виду, и по поведению).
Чистота базы данных
Форма — место, которое наполняет базу данных. Если есть проблемы с валидацией, появляется угроза того, что некорректные данные попадут в БД. Это ведет к проблемам с поведением приложения и потенциальным багам.
Анализ граничных значений
Кроме классов эквивалентности, нужно протестировать граничные значения. Граничные значения это:
- Минимальное значение
- Максимальное значение
- Выборочные значения из промежутка
Вот пример:
Граничные значения проверяются, потому что ни один разработчик не застрахован от так называемой ошибки на единицу.
Бонус: bugmagnet
Для тестирования форм есть отличный плагин для Chrome и Firefox — BugMagnet. После установки кликните правой кнопкой мыши по любому полю формы и у вас появится возможность выбора значений для заполнения из огромного списка данных. Вот видео, на котором показано, как работаем BugMagnet:
Дополнение
Вместе со всем вышеперечисленным нужно попробовать:
Как правильно создавать тест-кейсы для формы регистрации?
Если форма заполнена не полностью, то кнопка отправить должна быть неактивна.
Если форма заполнена невалидными данными и/или неполностью – кнопка “Отправить” должна быть неактивна и неверно заполненые поля должны показывать подсказку.
Для каждого поля нужно проверять, что разные ошибочные варианты ввода в это поле распознаются. Переполнение поля тоже.
Если есть необязательные поля, нужно проверить, что их заполнение, незаполнение или неверное заполнение не влияет на результат. Если есть кнопки переключатели (radio buttons) можно проверить выставляется ли значение по умолчанию если должно или не выставляется если не должно. Бывает что выставляется хотя не должно.
Кроме этого навигацию по полям табуляцией можно проверить. Можно проверить, что при перезагрузке страницы введенные в формуляр данные не сбрасываются, если они не должны сбрасываться.
Если поля поддерживают автозаполнение можно проверить и это.
Если формуляр многостраничный – нужно проверить навигацию между страницами, что введенные данные не теряются. Что их можно отредактировать вернувшись назад.
Не думайте о количестве тесткейсов, думайте о том, в чем вы хотите убедиться.
Разделение эквивалентности
Разделение эквивалентности — это разделение набора возможных данных для ввода на классы. Каждый член класса считается идентичным всем остальным.
Давайте разберем это на примере. Предположим, что есть поле для ввода, которое может принимать только числовые значения в промежутке от 1 до 200 000. Вот классы эквивалентности, которые нужно будет проверить:
- Числа меньше минимального значения промежутка (меньше 1)
- Числа внутри промежутка (1-200 000)
- Числа больше максимального значения промежутка (больше 200 000)
Таблица верификации полей
Вот пример таблицы для верификации полей ввода. Вы можете составить такую же для вашей формы.
| Тип данных | Корректный ввод | Некорректный ввод |
|---|---|---|
| Положительные целые числа | — только числа — максимально возможное значение (N) — числа внутри промежутка (N 1) / 2 | — число больше максимально возможного (N 1) — дробные числа — отрицательные числа — строковые значения — числа строковые значения — числа специальные символы — Unicode (например U 0000, U 0001) |
| Строки | — только символы — только числа — только специальные символы — числа символы — числа спецсимволы — символы спецсимволы | — |
| Даты | — проверить, что при выборе появляется datepicker — проверить, что поле нельзя изменить с клавиатуры — проверить, что значение поля можно скопировать, но вставить нельзя — проверить, что при выборе значения в datepicker, оно появляется в поле — проверить, что в феврале 29 дней в високосных годах — проверить, что в феврале 28 дней не в високосных годах | — |