Форма — место, где пользовательские данные превращаются в действие системы: регистрацию, заказ, изменение профиля или загрузку файла. Поэтому тестирование формы нельзя ограничить набором символов в полях. Нужно проследить путь от ввода до сохранённых данных и понятного результата на экране.
Хорошая валидация помогает исправить ошибку и защищает целостность данных. Плохая валидация одновременно раздражает пользователя и пропускает некорректные запросы: например, запрещает допустимую фамилию в интерфейсе, но позволяет через API создать запись без обязательного согласия.
Сначала уточнить правила
Для каждого поля соберите контракт: обязательность, допустимые значения, диапазон длины, формат, нормализацию, зависимости и момент проверки. Отдельно выясните бизнес-правила: уникальность, доступность выбранного тарифа, допустимость даты и ограничения роли.
Нормализация — преобразование ввода к согласованному виду, например удаление крайних пробелов. Её нельзя придумывать в тесте. Для имени пробелы могут иметь смысл, а изменение регистра или Unicode-символов в пароле способно изменить секрет. Неясное правило фиксируют как вопрос к требованиям, а не объявляют ошибкой реализации по личному вкусу.
Разделить клиент и сервер
Клиентская проверка даёт быструю обратную связь до запроса. Серверная проверка принимает окончательное решение о допустимости операции. HTML-атрибуты и JavaScript в браузере можно обойти, поэтому успешная блокировка на UI не доказывает, что backend защищает данные.
Проверяйте один и тот же недопустимый вариант через форму и прямой запрос в тестовом окружении. Ожидается отказ сервера с согласованным ответом, отсутствие созданной записи и корректная обработка ошибки интерфейсом. Точный HTTP-статус определяется контрактом API, а не универсальным правилом для всех форм.
Как выбрать данные без случайного перебора
Используйте классы эквивалентности: группы ввода, которые должны обрабатываться одинаково. Для длины от 2 до 50 проверяют пустое значение, 1, 2, 50 и 51 символ, а также обычное значение внутри диапазона. Это даёт объяснимое покрытие границ.
- →Числа: минимум, максимум, значения рядом с границами, отрицательные, дробные и некорректный разделитель.
- →Даты: несуществующая дата, високосный день, граница периода, влияние локали и часового пояса по требованиям.
- →Текст: пробелы, переносы, кириллица, составные Unicode-символы, вставка и длинные значения.
- →Выбор: пустой вариант, недоступное значение, изменение зависимого списка после смены родительского поля.
Уточняйте единицу длины. Количество видимых символов, кодовых точек, UTF-16 единиц и байтов может различаться, особенно для emoji.
Проверять ввод как действие
Пользователь печатает, вставляет, использует автозаполнение, меняет середину строки и удаляет выделение. Маска телефона, работающая только при последовательном наборе, может испортить вставленное значение. Календарь может принимать дату через виджет, но иначе обрабатывать ручной ввод.
Отдельно проверьте отправку по кнопке и Enter, переход Tab, сохранение значений после ошибки и корректность мобильной клавиатуры. Placeholder помогает привести пример, но не заменяет постоянное название поля: после ввода он исчезает.
Ошибки должны помогать восстановиться
Сообщение объясняет, что произошло и как исправить значение. Оно связано с нужным полем, доступно без различения цвета и не исчезает раньше, чем пользователь успеет его прочитать. При нескольких ошибках важен понятный путь к каждой из них.
Проверьте порядок фокуса, доступное имя поля и объявление ошибки программой экранного доступа. Текст «некорректные данные» у всей формы может быть недостаточным для адреса доставки. При этом для входа слишком подробное сообщение о существовании аккаунта может противоречить требованиям безопасности: контекст имеет значение.
Асинхронные проверки и гонки
Проверка занятого имени, подсчёт стоимости и загрузка адресов приходят с сервера позже действия пользователя. Введите значение А, быстро замените его на Б и задержите ответ на А. Ожидается, что старый ответ не перезапишет актуальный результат.
Пока идёт submit, интерфейс должен показывать согласованное состояние. Повторный клик, Enter и сетевой retry не должны создавать лишние бизнес-операции. Блокировка кнопки снижает риск, но окончательную защиту от дублей проверяют на уровне операции и сервера.
Практический пример: регистрация
Пусть контракт требует email и пароль длиной 12–64 символа; пробелы в пароле сохраняются. Аккаунт создаётся при успешной серверной обработке; потеря ответа не означает, что запись не появилась.
- 1.Введите допустимые данные и отправьте форму. Ожидается одна новая запись и понятный следующий шаг, например подтверждение email.
- 2.Проверьте пароли длиной 11, 12, 64 и 65 символов через UI и API. Ожидается согласованное применение границ; недопустимые записи отсутствуют.
- 3.Используйте уже занятый email. Ожидается предусмотренный контрактом отказ и сохранение остальных допустимых данных, кроме случаев, когда политика требует очистить секрет.
- 4.Имитируйте таймаут после отправки, затем повторите действие. Ожидается определённый результат без второго аккаунта и вечного индикатора загрузки.
- 5.Пройдите неуспешную отправку клавиатурой и screen reader. Ожидается возможность обнаружить ошибку и исправить её без мыши.
Файлы и чувствительные данные
Если форма принимает файлы, проверяйте размер и тип по контракту, пустой файл, прерванную передачу и повтор загрузки. Разрешение в атрибуте accept помогает пользователю выбрать файл, но сервер обязан самостоятельно проверить содержимое и ограничения.
В диагностике не сохраняйте реальные пароли, токены и персональные документы. Для доказательства ошибки используйте подготовленные тестовые данные и очищенные запросы.
Типичные ошибки и выводы
Частые ошибки — проверять только обязательность, считать маску доказательством допустимости и сравнивать лишь сообщение без фактического состояния данных. Также опасно жёстко ограничивать email или имя собственным упрощённым шаблоном без требования продукта.
Системная проверка формы связывает контракт, границы, способы ввода, серверное решение и восстановление после ошибки. Форма считается проверенной по пользовательской цепочке, а не по количеству введённых строк.
Что ещё почитать
- →MDN: Client-side form validation
- →W3C WAI: Easy Checks, forms and errors
- →OWASP: Web Security Testing Guide
Одно правило и конкретная матрица данных
Учебное правило: никнейм содержит 3–12 букв ASCII. Пробелы отклоняются, а не обрезаются незаметно; Unicode-буквы исключены только в этом узком упражнении. Подготовленная HTML-форма работает на клиенте и не отправляет запрос. API-фикстура отдельно проверяет то же правило имени.
Вход Ожидание
(пусто) Отклонить
ab Отклонить: длина 2
abc Принять: длина 3
abcdefghijkl Принять: длина 12
abcdefghijklm Отклонить: длина 13
abc Отклонить: пробел в начале
абв Отклонить: не ASCII по условиюПри отклонении проверяйте видимую ошибку, aria-invalid=true и фокус на невалидном поле. Ошибка связана с полем через aria-describedby. Для валидного ввода ожидайте сообщение об успехе и пустой текст ошибки. Не переносите ограничение ASCII из упражнения на настоящие имена и международные продукты.
Клиентская проверка ускоряет обратную связь, но её можно обойти. Отправьте невалидный JSON прямо в локальную API-фикстуру и проверьте отказ там. Проверка формы и API — два разных теста; демонстрация не заявляет сквозную отправку из браузера в API.