Раздел 08 — Тестирование веб-интерфейса

Браузер отправляет на сервер запрос, сервер отвечает HTML-страницей, браузер её показывает и выполняет её скрипты. Нажали кнопку формы — браузер отправил новый запрос с введёнными данными. Отсюда две части любой проверки:

• Что видно на экране — тексты, поля, сообщения, вёрстка. Это проверяли разделы 04–06.
• Что происходит между браузером и сервером — какие запросы ушли, что сервер ответил, что браузер запомнил. Этого на экране не видно, и здесь нужны инструменты разработчика.

Это и есть серый ящик из раздела 02: код сервера мы не читаем, но видим, как он общается с браузером.

Проверку ввода делают в двух местах:

Главное правило: клиентская проверка — не защита. Если поле количества в магазине не даёт ввести 0 только атрибутом min="1", а сервер не проверяет, то заказ на 0 или −5 штук создаётся за минуту. Поэтому тестировщик проверяет оба уровня:

1. Ввести недопустимое значение обычным способом — браузер должен подсказать.
2. Убрать ограничение в DevTools (п. 04) и отправить снова — должен отказать сервер.
3. Отправить запрос без браузера через API — раздел 09.

Если после шага 2 недопустимое значение сохранилось — это дефект сервера, и серьёзный: в баг-репорте так и пишите «серверная проверка отсутствует, клиентскую можно обойти».

DevTools открываются клавишей F12 или Ctrl+Shift+I; щелчок правой кнопкой по элементу → «Проверить» сразу показывает его код. Панели, которые нужны тестировщику:

Если DevTools открылись сбоку и тесно — меню ⋮ справа вверху панели → «Dock side» (расположение): снизу или в отдельном окне.

Значок со стрелкой в левом верхнем углу DevTools (или Ctrl+Shift+C) включает выбор элемента: щёлкните по полю на странице, и в панели Elements подсветится его код. На снимке — поле «Название» формы «Новая задача»: у него атрибут required, поэтому браузер не отправит форму с пустым полем.

Как обойти клиентскую проверку:

1. Выберите поле, в Elements дважды щёлкните по атрибуту (required, min="1", maxlength) и удалите его или исправьте значение. Можно правой кнопкой по узлу → «Edit as HTML».
2. Введите в поле недопустимое значение и отправьте форму.
3. Посмотрите, что ответил сервер: сообщение об ошибке на странице — сервер проверяет; задача создалась — нет.

Правка действует до перезагрузки страницы и только в вашем браузере — ничего не ломается, сервер видит лишь отправленные данные. То же работает со списками <select>: допишите свой <option value="9"> и выберите его.

В Elements же проверяют подписи полей: у поля должен быть <label for="…"> с тем же id или атрибут aria-label. Текст-подсказка внутри пустого поля (placeholder) подписью не считается — он исчезает при вводе, и экранная читалка его может не прочитать.

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

Красный счётчик в правом верхнем углу DevTools показывает число ошибок, даже когда открыта другая панель. Ошибка загрузки favicon.ico (404 — у сайта нет значка вкладки) обычно безобидна; ошибки вида Uncaught TypeError: Cannot read properties of null — повод разобраться и, если что-то не работает, написать баг-репорт с текстом ошибки.

Консоль ещё и удобный калькулятор тестовых данных. Введите команду и нажмите Enter:

'a'.repeat(101)                  // строка из 101 символа
'я'.repeat(50).length            // 50 — проверить длину
new Date().toISOString().slice(0, 10)   // сегодняшняя дата 2026-10-29

Первый раз браузер может попросить разрешение вставлять код в консоль — введите allow pasting, если копируете команду, а не набираете.

Откройте Network до действия — запросы записываются только при открытой панели. На снимке — вход в «Задачник»: форма отправила POST /login, сервер ответил кодом 303 (перенаправление) и браузер сам запросил /tasks.

Щелчок по строке открывает подробности:

• Headers — адрес, метод, код ответа, заголовки запроса и ответа (среди них Set-Cookie и Cookie).
• Payload — что отправила форма: здесь видно, ушло ли название с пробелами, какой приоритет на самом деле отправлен.
• Response / Preview — что вернул сервер.

Полезные флажки над списком: Keep log (в Chrome — Preserve log, «Сохранять журнал») — не очищать список при переходе на другую страницу: без него после щелчка по ссылке запросы прошлой страницы исчезают; Disable cache — загружать всё заново.

Коды ответов, которые встретятся чаще всего: 200 — успешно, 303 — перенаправление после отправки формы, 400 — неверный запрос, 401 — нужна авторизация, 404 — не найдено, 500 — ошибка сервера. Ответ 500 на любое действие пользователя — всегда дефект: сервер не справился с данными, а не отказал по правилам. Подробнее о кодах — в разделе 09.

После входа сервер присылает cookie — небольшую строку, которую браузер прикладывает к каждому следующему запросу. По ней сервер узнаёт пользователя. В «Задачнике» это cookie sid. Посмотреть её: Application → Storage → Cookies → http://127.0.0.1:8000.

Что видно в таблице cookies и что проверять:

• HttpOnly — скрипты страницы не могут прочитать cookie. Для cookie сессии флажок должен стоять: иначе внедрённый на страницу скрипт украдёт сессию.
• Expires — когда cookie удалится. «Session» — при закрытии браузера.
• Выход должен завершать сессию на сервере, а не только удалять cookie в браузере. Проверка: скопировать значение cookie, выйти, вернуть значение (двойной щелчок по ячейке Value) и обновить страницу. Пустило без входа — старая сессия жива.
• Удаление cookie (выбрать строку, Delete) — после обновления страницы должна открыться форма входа.
• Два пользователя — обычное окно и окно InPrivate (Ctrl+Shift+N) имеют разные cookies: в одном ivan, в другом maria. Так удобно проверять, что пользователи не видят данных друг друга.

Значок телефона и планшета в левом верхнем углу DevTools (Ctrl+Shift+M) переключает режим устройства: страница показывается в окне заданной ширины, как на телефоне. Сверху — выбор модели (Responsive — свой размер) и размеры в пикселях: щёлкните по ширине и впишите 360.

Ширины для проверки: 360 (самые узкие распространённые Android), 390–412 (большинство телефонов), 768 (планшет вертикально). Что смотреть:

• нет горизонтальной прокрутки страницы — проведите по нижней части окна или поищите полосу прокрутки;
• текст не вылезает за край и не перекрывает другой текст;
• кнопки и ссылки достаточно крупные, чтобы попасть пальцем;
• таблицы — либо помещаются, либо прокручиваются внутри своего блока, а не всей страницей;
• то же при повороте (значок поворота рядом с размерами).

Режим устройства — приближение: шрифты, клавиатура и жесты настоящего телефона отличаются. Перед выпуском откройте страницу и на реальном телефоне. «Задачник» слушает только 127.0.0.1, поэтому с телефона он не откроется — для него хватит режима устройства; свой проект проверяйте на телефоне.

Браузеры на движке Chromium (Chrome, Edge, Яндекс Браузер, Opera) показывают страницы почти одинаково; Firefox и Safari (на iPhone все браузеры работают на движке Safari) — по-своему. Минимальный набор: один браузер на Chromium и Firefox на компьютере, плюс браузер телефона. Что чаще всего отличается:

• поля даты и времени — выглядят и вводятся по-разному, а иногда принимают разные форматы;
• сообщения встроенной проверки полей («Заполните это поле») — разный текст и вид;
• шрифты и переносы — блок, который в Chrome помещается в строку, в Firefox переносится;
• автозаполнение и сохранение паролей.

В баг-репорте всегда указывайте браузер с версией (меню → Справка → О программе): «Firefox 145, Windows 11». Дефект, который есть только в одном браузере, — важная деталь для разработчика.

Доступность — возможность пользоваться программой людям с нарушениями зрения, слуха, моторики. Требования к ней описаны в ГОСТ Р 52872 (основан на международном WCAG). Без специальных программ можно проверить главное:

Найденное оформляется баг-репортом как любой дефект; требование — пункт ТЗ о доступности, если он есть, или ГОСТ Р 52872.