В главе про тест-дизайн вы уже учились придумывать негативные проверки: пустое поле, слишком длинное значение, спецсимволы. Этот урок применяет те же техники конкретно к веб-формам — и добавляет важную техническую деталь: одна и та же проверка данных на форме может происходить в двух разных местах, и от этого зависит, чему на самом деле можно доверять.
Чему научишься за этот урок:
— различать клиентскую и серверную валидацию формы;
— объяснять, почему нельзя полагаться только на клиентскую проверку;
— проверять серверную валидацию напрямую через DevTools, в обход формы.
Клиентская и серверная валидация
Клиентская валидация — это проверка данных, которую выполняет JavaScript прямо в браузере, ДО отправки данных на сервер. Она срабатывает мгновенно: не нужно ждать ответа сервера, чтобы увидеть ошибку под полем.
Серверная валидация — это проверка тех же данных, которую выполняет сервер уже ПОСЛЕ того, как получил запрос, — независимо от того, что уже якобы проверил браузер. Сервер не обязан доверять клиенту: он проверяет данные заново, сам.
Почему нужны обе
Клиентскую валидацию легко обойти: запрос можно отправить на сервер напрямую, минуя саму форму и её JS-проверки — например, через вкладку Network в DevTools или через сторонний инструмент отправки запросов. Если сервер не проверяет данные повторно сам, невалидные данные всё равно попадут в систему, что бы ни показывала форма в браузере.
Правило тестировщика: недостаточно проверить форму через интерфейс. Нужно отдельно убедиться, что и сервер отклоняет некорректные данные, а не полагается только на клиента.
+---------------------------+ +----------------------------+ | КЛИЕНТСКАЯ ВАЛИДАЦИЯ | | СЕРВЕРНАЯ ВАЛИДАЦИЯ | +---------------------------+ +----------------------------+ | выполняется в браузере | | выполняется на сервере | | до отправки запроса | | после получения запроса | | мгновенная реакция | <-> | требует сетевого запроса | | легко обойти напрямую | | обязательна для защиты | | через DevTools/API | | данных, нельзя пропустить | +---------------------------+ +----------------------------+
Как проверить серверную валидацию на практике
Способ практический: во вкладке Network (уже знакомой из главы 3) можно отправить намеренно невалидные данные напрямую, минуя саму форму и её JS-проверки, и посмотреть, что ответит сервер. Если сервер принял и «обработал» заведомо некорректные данные — серверной валидации нет или она не работает, и вся защита держится только на клиенте, которого легко обойти.
Пример на полигоне
На нашем полигоне форма регистрации устроена так: если оставить поле email пустым и нажать «Зарегистрироваться», под полем мгновенно появляется красный текст «Введите email» — это сработала клиентская валидация в браузере, без обращения к серверу. Но одного этого недостаточно, чтобы считать email защищённым: нужно проверить, действительно ли сервер тоже отклонит пустой email, если отправить запрос напрямую, в обход формы и её JS-проверки.
Контрольный вопрос. Когда срабатывает клиентская валидация формы относительно отправки данных на сервер?
Подсказка: Смысл клиентской проверки — не тратить время на сетевой запрос, если данные уже неверны.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Когда срабатывает серверная валидация?
Подсказка: Ключевое слово — «независимо»: сервер не обязан доверять тому, что уже якобы проверено в браузере.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Почему клиентскую валидацию легко обойти?
Подсказка: Вспомни вкладку DevTools, которая показывает и позволяет повторить любой сетевой запрос.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Какие из утверждений про валидацию формы верны (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Одно из утверждений противоречит главному правилу урока: полагаться только на клиентскую проверку нельзя.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Как называется проверка данных, которая выполняется в браузере ДО отправки на сервер? Ответь двумя словами: «… валидация».
Подсказка: Противоположность серверной валидации.
Онлайн-проверка ответа появится позже
Контрольный вопрос. В какой вкладке DevTools можно отправить запрос с намеренно невалидными данными напрямую, в обход формы? Ответь одним словом.
Подсказка: Это та же вкладка со списком всех сетевых запросов браузера, которую использовали в прошлом уроке при разборе клиентского рендеринга.
Онлайн-проверка ответа появится позже
Задание. На полигоне форма регистрации при пустом поле email сразу показывает под полем красный текст «Email обязателен» — без перезагрузки страницы и без задержки на сетевой запрос. Судя по скорости реакции и отсутствию сетевого запроса, какой тип валидации сейчас сработал? Ответь одним словом.
Подсказка: Обрати внимание на скорость реакции и на то, что здесь не было ожидания ответа сервера.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Онлайн-проверка ответа появится позже
Задание. Тестировщик отправляет запрос регистрации с пустым email напрямую через вкладку Network, минуя форму, — специально, чтобы проверить именно серверную валидацию. Какой результат в ответе сервера будет означать, что серверная валидация РАБОТАЕТ? Ответь одним словом: сервер должен этот запрос …
Подсказка: Подумай, что должен сделать сервер с невалидными данными, если он их действительно проверяет сам, а не просто доверяет клиенту.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Онлайн-проверка ответа появится позже
Задание. На полигоне форма регистрации показывает клиентскую ошибку при пустом email. Ты отправил тот же запрос напрямую через вкладку Network, в обход формы, тоже с пустым email — и сервер ответил кодом 200 ОК, как будто регистрация прошла успешно. Объясни в 2-3 предложениях, почему это серьёзный дефект, и что именно нужно указать в баг-репорте (вспомни главу 6 про баг-репорты) в качестве сути проблемы.
Подсказка: Подумай, что означает код 200 ОК для запроса с заведомо невалидными данными, если бы сервер их на самом деле проверял.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Форма регистрации на полигоне проверяет email как минимум в двух разных местах — до отправки запроса и после. Тестировщик проверил форму только через интерфейс браузера: вводил некорректный email, видел ошибку под полем — и на этом остановился, посчитав валидацию email полностью протестированной. Какую важную проверку он пропустил? Ответь коротко одним словосочетанием.
Подсказка: Он проверял только то, что видно и реагирует в браузере, — а что происходит на другой стороне запроса?
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Тестировщик проверил форму только через интерфейс браузера и увидел, что все ошибки валидации показываются как надо. Достаточно ли этого, чтобы считать валидацию формы полностью протестированной?
Подсказка: Вспомни главное правило урока про то, чего никогда не гарантирует одна лишь клиентская проверка.
Онлайн-проверка ответа появится позже
Итог:
— негативные проверки нужно применять и к клиентской, и отдельно к серверной валидации формы;
— клиентскую валидацию легко обойти, отправив запрос напрямую в обход формы;
— финальную защиту данных всегда даёт именно сервер, поэтому проверять нужно и его ответ, а не только то, что показывает форма в браузере.
Что дальше
Мы разобрали, как форма проверяет данные на клиенте и на сервере, и почему нельзя полагаться только на браузер. Дальше — про то, что один и тот же код может вести себя по-разному в разных браузерах и для пользователей с разным языком интерфейса: кроссбраузерность и локализация.
