Консоль браузера в тестировании сайтов
Консоль браузера — один из самых полезных инструментов для тестирования фронтенда. Она помогает увидеть поведение сайта изнутри: ошибки JavaScript, сетевые запросы, состояние интерфейса, данные в хранилищах, производительность и следы пользовательских действий.
Для тестировщика это быстрый способ ответить на вопросы:
- что сломалось
- в какой момент сломалось
- на стороне интерфейса или сервера возникла проблема
- какие данные ушли в запросе
- что вернул backend
- какие скрипты, стили или ресурсы влияют на страницу
Чаще всего под “консолью браузера” имеют в виду DevTools: набор вкладок внутри инструментов разработчика. В Google Chrome, Edge и Яндекс Браузере они открываются через F12, Ctrl + Shift + I или Cmd + Option + I на Mac.
Роль DevTools в работе тестировщика
DevTools полезны почти в каждом виде тестирования интерфейсов:
- функциональная проверка
- отладка багов
- анализ API-взаимодействий
- проверка адаптива
- исследование клиентской логики
- анализ производительности
- работа с cookies, localStorage, sessionStorage
- проверка безопасности на базовом уровне
Когда сайт ведет себя странно, обычного описания “кнопка не работает” мало. Консоль дает контекст: какой запрос ушел, какой статус вернулся, была ли ошибка JavaScript, изменился ли DOM, сохранились ли данные в хранилище.
Основные вкладки и их польза для тестирования
Elements
Вкладка Elements показывает HTML-структуру страницы и примененные CSS-стили.
Что здесь проверяют:
- появился ли нужный элемент в DOM
- скрыт ли элемент стилями
- меняются ли классы после клика
- применяется ли нужный CSS
- корректно ли рендерятся модальные окна, выпадающие списки, баннеры, ошибки
- есть ли блок, который перекрывает кнопку или поле ввода
Практические сценарии:
1. Кнопка видна, но клик не срабатывает
Открываете Elements, находите кнопку, смотрите соседние блоки. Часто сверху лежит прозрачный слой с position: absolute или z-index.
2. Сообщение об ошибке отсутствует на экране
Проверяете DOM. Сообщение может уже существовать в HTML, но быть скрытым через display: none, opacity: 0 или условный класс.
3. Верстка “поплыла”
Смотрите реальные размеры блока, отступы, flex/grid-настройки, медиазапросы и перекрытия.
Полезно знать:
- стрелка слева от тега раскрывает вложенность
- вкладка Styles показывает CSS-правила
- вкладка Computed показывает итоговые стили
- иконка выбора элемента помогает ткнуть в любой объект прямо на странице
Console
Вкладка Console — журнал ошибок, предупреждений и ручных команд.
Что здесь смотрят:
- ошибки JavaScript
- предупреждения браузера
- сообщения от frontend-кода
- результаты собственных JS-команд
Для тестировщика это один из главных источников технических симптомов.
Примеры типовых ошибок:
Uncaught TypeErrorReferenceErrorFailed to fetch- ошибки CORS
- ошибки загрузки скриптов и ресурсов
Что можно делать вручную:
document.title
Покажет заголовок страницы.
document.querySelector('button')
Найдет первую кнопку на странице.
document.querySelectorAll('input').length
Покажет количество полей ввода.
localStorage
Покажет данные в localStorage.
window.location.href
Покажет текущий URL.
Практические сценарии:
1. После клика ничего не происходит
Открываете Console, повторяете действие и смотрите, появляется ли ошибка.
2. Форма отправляется с пустыми данными
Можно проверить содержимое полей и состояние переменных через JavaScript.
3. Нужно быстро проверить наличие элемента
Достаточно выполнить document.querySelector(...).
Полезные приемы:
- включить Preserve log, чтобы журнал сохранялся при переходах между страницами
- включить фильтрацию по Error, Warning, Info
- очищать журнал перед новой проверкой, чтобы видеть только свежие события
Network
Вкладка Network показывает сетевую активность страницы: запросы к API, загрузку HTML, JS, CSS, изображений, шрифтов и других ресурсов.
Для тестировщика это одна из самых сильных вкладок.
Что здесь проверяют:
- отправился ли запрос после действия пользователя
- какой URL вызван
- какой метод использован: GET, POST, PUT, DELETE
- какие заголовки ушли
- какой payload ушел на сервер
- какой статус вернулся: 200, 400, 401, 403, 404, 500
- какое тело ответа вернул сервер
- сколько времени занял запрос
Практические сценарии:
1. Нажали “Войти”, а входа нет
Смотрите, ушел ли запрос авторизации.
Если запроса нет, проблема в frontend-событии.
Если запрос ушел и вернулся 401, проблема в данных или логике авторизации.
Если пришел 500, проблема на backend.
2. Товар не добавляется в корзину
Проверяете запрос на добавление. Сравниваете payload и response.
3. Данные на странице устарели
Можно увидеть, идет ли запрос за свежими данными или страница берет старое содержимое из кэша.
Полезные возможности:
- Fetch/XHR для фильтрации API-запросов
- Headers для просмотра URL, метода и заголовков
- Payload для тела запроса
- Response для ответа сервера
- Preview для красивого просмотра JSON
- Timing для анализа задержек
- Disable cache для тестов без влияния браузерного кэша
- Preserve log для сохранения цепочки запросов между переходами
Sources
Вкладка Sources полезна для более глубокой отладки JavaScript.
Что здесь делают:
- ставят breakpoints
- останавливают выполнение скрипта в нужной строке
- пошагово проходят код
- смотрят значения переменных в момент ошибки
- анализируют цепочку вызовов
Для тестировщика эта вкладка особенно ценна при сложных фронтовых багах.
Практические сценарии:
1. После нажатия кнопки идет странная логика
Ставите breakpoint на обработчик клика и смотрите, какие функции вызываются дальше.
2. Нужно понять, откуда берется ошибочное значение
Останавливаете код в месте присвоения и проверяете текущее состояние переменных.
3. Форма блокируется без понятной причины
Через breakpoint на submit или validation можно увидеть, на каком условии поток меняется.
Тестировщику не обязательно владеть JavaScript на уровне разработчика, чтобы получать пользу от Sources. Даже базовое умение поставить breakpoint и посмотреть значения уже сильно ускоряет диагностику.
Application
Вкладка Application показывает клиентские данные, которые браузер хранит локально.
Что здесь проверяют:
- cookies
- localStorage
- sessionStorage
- IndexedDB
- кэш
- service workers
Практические сценарии:
1. Пользователь вышел из аккаунта после обновления страницы
Проверяете cookies и localStorage: сохранился ли токен, срок жизни, домен, путь.
2. После очистки данных сайт начинает работать корректно
Смотрите, какие данные хранились в браузере и влияли на поведение.
3. Нужно воспроизвести баг в “чистом” состоянии
Можно вручную удалить localStorage, cookies и кэш без полного сброса браузера.
Полезные проверки:
- сохраняется ли токен после логина
- удаляется ли токен после выхода
- хранится ли выбранный город, тема, язык, фильтры
- меняются ли данные после обновления страницы
Performance
Вкладка Performance помогает понять, где страница тормозит.
Что можно увидеть:
- долгие рендеры
- тяжелые скрипты
- частые перерисовки
- подвисания при прокрутке
- задержки после клика
Практические сценарии:
1. Форма открывается с задержкой
Записываете performance-профиль и смотрите, какая часть занимает больше всего времени.
2. Страница зависает на фильтрации товаров
Можно увидеть, перегружает ли интерфейс JavaScript.
3. Анимации идут рывками
Проверяете repaint, layout и нагрузку на главный поток.
Lighthouse
Lighthouse подходит для быстрой автоматической оценки страницы.
Он помогает посмотреть:
- производительность
- доступность
- best practices
- SEO
Для тестировщика это хороший способ собрать первичную техническую картину и найти зоны риска.
Примеры пользы:
- изображения слишком тяжелые
- кнопки и ссылки плохо размечены
- заголовки построены хаотично
- страница грузится медленно на мобильном профиле
Security
Вкладка Security показывает состояние соединения и сертификата.
Что можно проверить:
- используется ли HTTPS
- есть ли проблемы с сертификатом
- загружаются ли небезопасные ресурсы на защищенной странице
Для повседневного тестирования вкладка требуется реже, но при работе с платежами, авторизацией и персональными данными она очень полезна.
Подход к тестированию через DevTools
Самый рабочий путь выглядит так:
1. Повторить действие пользователя
Например: открыть карточку товара, нажать “Добавить в корзину”.
2. Одновременно смотреть несколько вкладок
Обычно достаточно связки:
- Console
- Network
- Elements
- Application
3. Зафиксировать технические симптомы
Например:
- после клика запрос
POST /cart/addушел - сервер вернул
500 - в Console появилась ошибка
TypeError - кнопка осталась в состоянии loading
- localStorage не обновился
4. Сделать вывод
Такой вывод уже близок к качественному баг-репорту:
После нажатия на кнопку “Добавить в корзину” отправляется POST-запрос
/cart/add, сервер возвращает 500, на фронте появляется ошибка в Console, кнопка остается в состоянии загрузки, товар в корзине отсутствует.
Полезные приемы для тестировщика
Очистка окружения
Перед повторной проверкой полезно:
- очистить Console
- включить Disable cache
- удалить cookies/localStorage при необходимости
Эмуляция устройства
Через DevTools можно включить мобильный режим и проверить:
- адаптив
- поведение при разных разрешениях
- touch-интерфейс
- загрузку мобильной версии
Замедление сети
В Network можно выбрать Slow 3G или Fast 3G. Это помогает увидеть:
- спиннеры
- skeleton-загрузку
- таймауты
- скачки интерфейса при медленном интернете
Снимки состояния
Скриншоты из DevTools, копия response, export HAR и текст ошибки из Console часто делают баг-репорт сильнее и понятнее для команды.
Примеры багов, которые удобно ловить через консоль
Сценарий 1. Кнопка не работает
Проверка:
- есть ли ошибка в Console
- есть ли сетевой запрос в Network
- перекрыт ли элемент в Elements
Сценарий 2. Данные на странице устарели
Проверка:
- ушел ли новый запрос
- пришел ли старый кэшированный ответ
- обновилось ли значение в DOM
Сценарий 3. Форма отправляется с ошибкой
Проверка:
- какой payload ушел
- какой статус ответа пришел
- что вернул backend в response
- показывает ли интерфейс текст ошибки
Сценарий 4. После обновления страницы пользователь выходит из системы
Проверка:
- токен в cookies
- токен в localStorage
- срок жизни cookies
- ответ сервера на запрос профиля
Сценарий 5. Интерфейс тормозит
Проверка:
- тяжелые запросы
- долгий JS
- долгие рендеры
- повторные перерисовки
Что стоит включить в отчет после проверки
После исследования через DevTools отчет можно строить по простой схеме:
1. Сценарий
Что делали на сайте.
2. Ожидаемый результат
Что должно было произойти.
3. Фактический результат
Что произошло по факту.
4. Технические наблюдения
Что увидели в Console, Network, Elements, Application.
5. Предположение о зоне проблемы
Frontend, backend, интеграция, кэш, клиентское хранилище, верстка.
Пример:
При отправке формы обратной связи запрос уходит на
/api/feedback, сервер возвращает статус 400. В response приходит сообщение о пустом поле
Ошибки в работе с консолью
Частые промахи у начинающих тестировщиков:
- смотреть только на видимую часть интерфейса
- игнорировать Network
- путать frontend-ошибку и backend-ошибку
- проверять старые запросы и старые логи
- забывать очищать журнал перед повтором сценария
- делать вывод по одному симптому без сопоставления вкладок
Самый точный результат дает связка нескольких источников: Console + Network + Elements + Application.
Итог
Консоль браузера превращает тестирование сайта из наблюдения “снаружи” в исследование реального поведения страницы. Для тестировщика это инструмент, который помогает:
- быстрее находить причину бага
- точнее описывать дефект
- отделять проблемы интерфейса от проблем сервера
- проверять данные, запросы и клиентское состояние
- давать команде полезную техническую информацию
Минимальный рабочий набор для повседневной проверки сайтов:
- Console для ошибок и ручных команд
- Network для запросов и ответов
- Elements для DOM и CSS
- Application для cookies и storage
Когда этот набор входит в привычку, качество тестирования растет очень заметно.
Напоминание по организации работы
Вкладку с сайтом держите отдельно от вкладки с ответом.
Вкладку с отчетом держите открытой весь урок.
Так результаты исследования сохранятся, а текст отчета останется на месте.
Практическая работа
Тема: Тестирование сайта с помощью консоли браузера
Цель работы
Освоить инструменты DevTools для исследования сайта и научиться находить технические признаки ошибок через вкладки консоли браузера.
Результат работы
По итогам занятия студент:
- открывает DevTools и ориентируется по основным вкладкам
- исследует сайт через Console, Network, Elements, Application
- фиксирует ошибки, запросы, состояние элементов и данные хранилища
- оформляет короткий отчет о техническом состоянии сайта
Важно перед началом
Держите вкладку с заданием и вкладку с ответом отдельно от вкладки с исследуемым сайтом.
Лучше открыть:
- вкладку 1 — задание
- вкладку 2 — сайт для исследования
- вкладку 3 — файл с отчетом
Так текст отчета сохранится до конца пары.
Оснащение
- компьютер с доступом в интернет
- браузер Google Chrome, Microsoft Edge или Яндекс Браузер
- любой сайт для исследования по согласованию с преподавателем
- текстовый редактор для отчета
Краткая схема работы
Во время практики студент использует вкладки DevTools:
- Console — ошибки, предупреждения, ручные команды
- Network — сетевые запросы и ответы сервера
- Elements — HTML-структура и CSS
- Application — cookies, localStorage, sessionStorage
DevTools открываются через:
F12Ctrl + Shift + ICmd + Option + Iна Mac
Ход практической работы
Этап 1. Подготовка среды
- Откройте сайт.
- Откройте DevTools.
- Переключитесь на вкладку Console.
- Очистите журнал.
- Во вкладке Network включите:
- Preserve log
- Disable cache
- Подготовьте файл отчета.
Что зафиксировать в отчете
- адрес сайта
- дата и время проверки
- браузер
- краткая цель исследования
Этап 2. Анализ ошибок через Console
Задание
- Обновите страницу.
- Посмотрите, появились ли ошибки или предупреждения.
- Выполните 3-5 действий на сайте:
- открыть страницу
- нажать кнопку
- открыть форму
- ввести данные
- отправить форму
- После каждого действия смотрите сообщения в Console.
Что нужно найти
- ошибки JavaScript
- предупреждения браузера
- сообщения о проблемах загрузки ресурсов
- ошибки API, если они выводятся в консоль
Что зафиксировать
Для каждого найденного события укажите:
- действие пользователя
- текст ошибки или предупреждения
- момент появления
- предполагаемую причину
Пример записи
После нажатия на кнопку «Войти» в Console появилась ошибка
Uncaught TypeError. Ошибка возникла сразу после клика. Вероятная зона проблемы — обработчик кнопки на фронтенде.
Этап 3. Проверка запросов через Network
Задание
- Перейдите во вкладку Network.
- Отфильтруйте запросы по Fetch/XHR.
- Выполните действия, которые вызывают обмен с сервером:
- авторизация
- поиск
- фильтрация
- отправка формы
- открытие карточки
- Выберите один или два запроса и изучите:
- URL
- метод
- статус
- payload
- response
Что нужно определить
- отправился ли запрос
- какой статус вернулся
- какие данные ушли
- какие данные пришли
- есть ли задержка или ошибка
Что зафиксировать
По двум запросам оформите мини-анализ:
- действие
- имя запроса
- метод
- статус
- краткое содержание ответа
- вывод
Пример записи
При отправке формы обратной связи ушел POST-запрос
/api/feedback. Сервер вернул статус 400. В ответе пришло сообщение о некорректном поле email. Вероятная проблема связана с валидацией данных.
Этап 4. Исследование интерфейса через Elements
Задание
- Откройте вкладку Elements.
- Через инструмент выбора элемента выделите:
- кнопку
- поле ввода
- сообщение об ошибке
- всплывающее окно
- Изучите:
- HTML-структуру
- классы элемента
- стили
- размеры
- скрытие через CSS
Что нужно проверить
- присутствует ли элемент в DOM
- какие классы назначены
- есть ли
display: none,visibility: hidden,opacity: 0 - какой стиль влияет на положение и размер элемента
- есть ли перекрытие другим блоком
Практическая задача
Выберите один элемент интерфейса и ответьте:
- в каком теге он расположен
- какие классы у него есть
- какие стили влияют на его видимость
- есть ли признаки, влияющие на работу элемента
Пример записи
Кнопка присутствует в DOM, имеет класс
btn-primary, визуально отображается. Поверх кнопки расположен блок с абсолютным позиционированием. Это может влиять на нажатие.
Этап 5. Проверка клиентских данных через Application
Задание
- Откройте вкладку Application.
- Изучите разделы:
- Cookies
- Local Storage
- Session Storage
- Найдите данные, связанные с работой сайта:
- токен
- выбранный город
- язык
- тема
- корзина
- пользовательские настройки
Что нужно определить
- какие данные сохраняются в браузере
- меняются ли данные после действий пользователя
- удаляются ли данные после выхода из аккаунта
Что зафиксировать
Опишите минимум два найденных значения:
- где расположены
- за что отвечают
- меняются ли в ходе работы
Пример записи
В Local Storage найден ключ
city_id. Значение соответствует выбранному городу. После смены города значение обновилось.
Этап 6. Ручные проверки через Console
Задание
Выполните в Console следующие команды и запишите результаты.
document.title
window.location.href
document.querySelectorAll('input').length
localStorage
Дополнительное задание
Попробуйте найти первый заголовок страницы:
document.querySelector('h1')
Если браузер вернул объект, раскройте его и посмотрите содержимое.
Что зафиксировать
- заголовок страницы
- текущий URL
- количество полей ввода
- есть ли данные в localStorage
- найден ли заголовок h1
Этап 7. Итоговое исследование сценария
Основное задание
Выберите один пользовательский сценарий и исследуйте его целиком через DevTools.
Подходящие сценарии:
- вход в аккаунт
- поиск товара или статьи
- фильтрация каталога
- отправка формы
- переход в карточку
- добавление в корзину
- регистрация
- смена города
- открытие модального окна
Что нужно сделать
- Описать сценарий.
- Выполнить его шаг за шагом.
- Посмотреть Console.
- Посмотреть Network.
- Посмотреть Elements.
- При необходимости посмотреть Application.
- Сформулировать технический вывод.
Формат вывода
- сценарий
- ожидаемый результат
- фактический результат
- что показала Console
- что показала Network
- что удалось увидеть в Elements/Application
- итоговый вывод
Пример
Сценарий: отправка формы регистрации.
Ожидание: учетная запись создается, пользователь получает подтверждение.
Факт: форма осталась на месте, сообщение об успехе отсутствует.
Console: ошибкаFailed to fetch.
Network: POST-запрос ушел, статус 500.
Elements: блок ошибки в DOM отсутствует.
Вывод: проблема связана с серверной обработкой регистрации и отсутствием пользовательского сообщения на фронтенде.
Дополнительное задание для сильных студентов
Исследуйте один баг или подозрительное поведение сайта и составьте краткий баг-репорт:
- заголовок
- шаги воспроизведения
- ожидаемый результат
- фактический результат
- данные из Console
- данные из Network
- предположение о зоне проблемы
[task_id id=»21458″]