Тестирование форм

Формы — место обитания багов #

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

Опытный тестировщик форм не просто вводит валидные данные и нажимает «Отправить». Он думает о каждом возможном вводе, который пользователь — или злоумышленник — может предоставить.

Анатомия веб-формы #

Типичная форма включает:

• Текстовые поля: Имена, email, адреса, свободный текст
• Селекторы: Выпадающие списки, радиокнопки, чекбоксы
• Специальные поля ввода: Выбор даты, загрузка файлов, выбор цвета, ползунки
• Кнопки: Отправить, сбросить, отменить
• Скрытые поля: CSRF-токены, ID пользователей, данные отслеживания

У каждого типа элемента свой класс багов и тест-кейсов.

Клиентская vs. серверная валидация #

Клиентская валидация #

Происходит в браузере с помощью HTML-атрибутов и JavaScript. Даёт мгновенную обратную связь, но может быть обойдена.

HTML-атрибуты валидации:

<input type="email" required minlength="5" maxlength="255" pattern="[a-z@.]+">

JavaScript-валидация:

if (password.length < 8) {
  showError('Пароль должен быть минимум 8 символов');
  return false;
}

Серверная валидация #

Происходит на сервере после отправки формы. Это граница безопасности — она не может быть обойдена пользователем.

Критическое правило тестирования: Всегда тестируйте серверную валидацию, обходя клиентскую. В консоли DevTools:

document.querySelector('form').noValidate = true;
// Или удалить атрибуты 'required':
document.querySelectorAll('[required]').forEach(el => el.removeAttribute('required'));

Затем отправьте форму с невалидными данными. Сервер всё равно должен их отклонить.

Тест-кейсы по типам полей #

Текстовые поля #

Поля email #

Поля пароля #

Числовые поля #

Тщательно тестируйте границы: минимальное значение, максимальное значение, мин.-1, макс.+1, ноль, отрицательные числа, десятичные дроби, нечисловые символы.

Тестирование отправки формы #

Состояния кнопки отправки #

• До взаимодействия: Кнопка отправки должна быть активна (или неактивна, если требуются определённые поля)
• Во время отправки: Кнопка неактивна для предотвращения двойной отправки; показать индикатор загрузки
• После успеха: Перенаправление или сообщение об успехе
• После ошибки: Показать сообщения об ошибках; сохранить ввод пользователя; активировать кнопку

Двойная отправка #

Быстро нажмите кнопку отправки несколько раз. Форма:

• Отправляется только раз? (Правильно)
• Отправляется несколько раз, создавая дубликаты? (Баг)
• Показывает состояние загрузки, предотвращающее повторный клик? (Хорошая UX)

Продвинутое тестирование форм #

Порядок табуляции и клавиатурная навигация #

1. Кликните в первое поле и нажимайте Tab многократно
2. Проверьте, что фокус перемещается по полям в логичном порядке
3. Проверьте, что можно отправить форму нажатием Enter
4. Проверьте, что выпадающие меню навигируются стрелками
5. Проверьте, что чекбоксы переключаются пробелом
6. Проверьте, что радиокнопки переключаются стрелками

Тестирование автозаполнения #

Браузеры автоматически заполняют формы сохранёнными данными. Проверьте:

• Принимает ли форма автозаполненные значения корректно?
• Достаточно ли семантичны имена полей для корректного автозаполнения браузером?
• Вызывает ли автозаполнение клиентскую валидацию?
• Ломается ли форма, если автозаполнение предоставляет неожиданные значения?

Качество сообщений об ошибках #

Хорошие сообщения об ошибках:

• Конкретны: «Email должен содержать символ @», а не «Неверный ввод»
• Расположены рядом с полем: Inline-ошибки, а не только список вверху
• Сохраняются: Видны до исправления ошибки
• Доступны: Скринридеры могут их озвучить (использовать aria-describedby)
• Без обвинений: «Пожалуйста, введите корректный email», а не «Вы ввели неверный email»

Тестирование многошаговых форм #

Формы-мастера с несколькими шагами требуют дополнительного тестирования:

• Можно ли вернуться к предыдущим шагам без потери данных?
• Валидация происходит пошагово или только в конце?
• Что произойдёт при обновлении страницы в середине мастера?
• Если открыть URL в новой вкладке — начнётся ли с шага 1 или запомнится прогресс?

Упражнение: Полный аудит формы #

Найдите форму регистрации или оформления заказа и протестируйте её:

1. Обязательные поля: Отправьте форму с каждым обязательным полем пустым по одному
2. Граничные значения: Проверьте минимальную и максимальную длину каждого текстового поля
3. Спецсимволы: Введите <script>alert(1)</script> в каждое поле
4. SQL injection: Введите ' OR 1=1 -- в каждое поле
5. Серверная валидация: Обойдите клиентскую валидацию в DevTools и отправьте повторно
6. Двойная отправка: Нажмите «Отправить» 5 раз быстро
7. Порядок табуляции: Пройдите всю форму только клавиатурой
8. Сообщения об ошибках: Вызовите каждую ошибку валидации и оцените качество сообщения
9. Автозаполнение: Позвольте браузеру автозаполнить и проверьте корректность
10. Кнопка «Назад»: Успешно отправьте, затем нажмите «Назад» в браузере

Профессиональные советы #

Совет 1: Тестируйте отправку форм с сетевым троттлингом. Медленные соединения выявляют баги тайминга вроде двойной отправки.

Совет 2: Проверяйте, что сервер реально получает. Во вкладке Network инспектируйте payload запроса — отправленные данные могут отличаться от показанных.

Совет 3: Проверяйте индикаторы обязательных полей. Если поле отмечено красной звёздочкой (*), оно должно действительно быть обязательным.

Ключевые выводы #

• Формы — область с наибольшей плотностью багов в веб-приложениях
• Всегда тестируйте клиентскую и серверную валидацию независимо друг от друга
• Граничные значения, спецсимволы и пустые поля — где прячется большинство багов
• Предотвращение двойной отправки необходимо тестировать на каждой форме
• Клавиатурная навигация и порядок табуляции влияют на юзабилити и доступность
• Сообщения об ошибках должны быть конкретными, правильно расположенными и доступными
• Обход клиентской валидации для проверки серверной — критическая техника тестирования безопасности