TestiquaQA Academy OS
…
Клиент-сервер, запрос-ответ и DNS · 12 мин
🎯 Цель урока

Понять, что происходит в сети между нажатием Enter в адресной строке и появлением страницы, и уметь отследить этот путь через DevTools.

Контекст

Каждый раз, когда браузер открывает сайт, он разыгрывает одну и ту же пьесу: клиент (браузер) отправляет запрос, сервер возвращает ответ. DNS — это телефонная книга, которая переводит human-readable имя вроде example.com в IP-адрес, по которому и устанавливается TCP-соединение. Для QA важно знать этот путь, потому что большинство сетевых дефектов прячутся именно на одном из его участков: DNS не отвечает, соединение обрывается, сервер возвращает неожиданный код ответа.

  • Клиент — любое устройство, инициирующее запрос; в нашем случае это браузер.
  • DNS-резолвер последовательно спрашивает: локальный кэш → роутер → провайдер → корневые серверы.
  • HTTP-запрос содержит метод (GET, POST…), URL, заголовки и (опционально) тело.
  • HTTP-ответ содержит статус-код, заголовки и тело — тот самый HTML, JSON или файл.

Рабочий алгоритм

Чтобы проследить полный цикл запрос-ответ в DevTools и понять, где именно возникает проблема, действуйте так:

  • Откройте DevTools (F12) → вкладка Network. Убедитесь, что галочка Preserve log активна — иначе лог очистится при редиректе.
  • Введите URL в адресной строке и нажмите Enter. Первая строка в Network — это сам документ (тип Doc).
  • Кликните на эту строку → вкладка Timing. Найдите блок DNS Lookup — это время, которое ушло на резолвинг домена.
  • Перейдите на вкладку Headers: Request URL, Request Method, Status Code — это ваша базовая тройка для любого баг-репорта.
  • Сравните Response Headers: убедитесь, что Content-Type совпадает с ожидаемым типом данных.
  • Если страница не загружается, проверьте ошибку в колонке Status: 5xx = проблема на сервере, 4xx = проблема с запросом, (failed) = нет сети или DNS.

Пример из практики

Сценарий: тестируем форму регистрации на staging-среде. После отправки формы страница зависает. Открываем DevTools → Network → фильтруем по XHR. Видим запрос POST /api/register со статусом (failed). Во вкладке Timing блок DNS Lookup занимает 8 000 мс вместо обычных 1-2 мс. Значит staging-домен не прописан в DNS этой сети. Проверяем: в терминале пишем nslookup staging.example.com — ответ: NXDOMAIN (домен не найден). Вывод: дефект не в коде формы, а в DNS-конфигурации стенда. В баг-репорте указываем: шаги воспроизведения, скриншот вкладки Timing, вывод nslookup, ожидаемый результат (домен резолвится за < 100 мс), фактический (NXDOMAIN).

Частые ошибки

Начинающие QA часто делают эти ошибки при работе с сетевыми запросами:

  • Смотрят только на код ответа, игнорируя Timing — так можно пропустить медленный DNS или долгое ожидание соединения (TTFB).
  • Не включают Preserve log и теряют первый запрос при редиректе 301/302.
  • Путают DNS-ошибку (NXDOMAIN) с ошибкой сервера (502/503) — это разные уровни стека, требующие разных исполнителей для фикса.
  • Записывают в баг-репорт 'сайт не открывается' без указания конкретного статуса или сообщения об ошибке из Network.
  • Забывают очистить DNS-кэш браузера при проверке изменений DNS (chrome://net-internals/#dns → Clear host cache).

✅ Самопроверка

1Что такое DNS и зачем он нужен браузеру перед установкой соединения?
DNS переводит доменное имя (example.com) в IP-адрес. Без IP-адреса браузер не знает, к какому серверу обращаться — TCP-соединение устанавливается именно по IP.
2Чем отличается статус 502 от ошибки (failed) в DevTools Network?
502 означает, что сервер ответил, но сам получил некорректный ответ от вышестоящего сервиса (gateway). (failed) означает, что соединение не было установлено вообще — обычно из-за проблем с DNS, сетью или отказом сервера принять соединение.
3Зачем включать Preserve log во вкладке Network перед тестированием?
Без Preserve log журнал запросов очищается при каждом переходе на новую страницу или редиректе. Если баг проявляется именно во время редиректа, вы потеряете все запросы, которые к нему привели.
4Назовите три обязательных поля из DevTools, которые нужно включить в баг-репорт о сетевой ошибке.
Request URL (что запрашивалось), Request Method (GET/POST/…), Status Code (что ответил сервер или причина отказа). Дополнительно полезны: время DNS Lookup и заголовок Content-Type.
5Как быстро проверить, является ли проблема DNS-специфичной, а не серверной?
Запустить nslookup <домен> или dig <домен> в терминале. Если ответ NXDOMAIN или timeout — проблема в DNS. Если IP возвращается, но сайт не открывается — проблема на уровне сервера или сети после DNS.