Как проверить запросы и логи в браузере
Что проверяют
Умеете ли вы локализовать дефект: понять, фронтенд это или бэкенд, и приложить к баг-репорту доказательства. Следом часто дают ситуацию «кнопка не работает, ошибок на экране нет» и спрашивают, куда вы посмотрите первым делом.
Как отвечать
Инструменты разработчика открываются по F12 или Ctrl+Shift+I (на macOS Cmd+Option+I). Дальше по вкладкам:
- Network: включите Preserve log, чтобы запросы не пропадали при редиректе, и при необходимости Disable cache. Фильтр Fetch/XHR оставит обращения к API. В запросе смотрите метод, URL, статус, заголовки, вкладки Payload и Response, а в Timing время ожидания ответа сервера;
- Console: ошибки JavaScript, CORS, смешанный контент, упавшие загрузки. Фильтр по уровням отделяет ошибки от шума;
- Application (в Firefox это Storage): cookies,
localStorage, токены, от которых зависит поведение.
Приёмы, которые выдают опытного тестировщика:
- Copy as cURL: повторить запрос в терминале или импортировать в Postman и проверить сервер без интерфейса;
- HAR: экспорт всей сетевой сессии для разработчика. В нём бывают токены и cookie, поэтому перед отправкой его чистят;
- Throttling: медленная сеть, чтобы поймать двойные клики и гонки;
- блокировка и подмена: Block request URL и Local overrides показывают, как интерфейс переживает падение одного запроса или странный ответ.
Логи браузера видны только на клиенте. Чтобы найти ту же ошибку в логах сервера, берут идентификатор запроса из заголовков ответа (часто X-Request-Id) и точное время. Для мобильных приложений нужен прокси: Charles, Fiddler или mitmproxy.
Где спотыкаются
Смотрят только на статус. Ответ 200 с {"error": ...} в теле или с пустым списком тоже может быть дефектом.
Принимают ошибку CORS за падение сервера. Запрос мог дойти и выполниться, браузер лишь не отдал ответ скрипту. Смотреть нужно заголовки Access-Control-Allow-* и preflight OPTIONS.
Прикладывают к баг-репорту скриншот консоли без запроса, тела ответа и шагов. Разработчику нужен HAR или cURL и время, когда всё произошло.