Зачем это спрашивают
Вопрос кажется академическим, но интервьюер проверяет через него сразу несколько вещей. Понимаете ли вы, что между кнопкой Enter и картинкой на экране лежит цепочка из независимых шагов, и каждый может сломаться по-своему. Умеете ли вы рассказывать связно, а не перечислять термины. И главное для QA — знаете ли вы, где каждый шаг можно увидеть своими глазами, чтобы при проблеме не гадать, а локализовать её.
Хороший ответ здесь — это карта: от неё потом удобно отталкиваться в разговоре про коды ответа, кэш, cookie и поиск бага на фронтенде или бэкенде.
Как построить сильный ответ
Идите по шагам в хронологическом порядке и на каждом коротко отвечайте на два вопроса: что происходит и где это видно.
1. Разбор адреса и кэш
Браузер решает, адрес это или поисковый запрос, и разбирает URL на части: схему (https), хост, порт (по умолчанию 443 для https), путь и параметры. Если для домена сохранена политика HSTS, браузер сразу пойдёт по https. Затем он проверяет, нет ли готового ответа в кэше или у Service Worker.
2. DNS: имя превращается в IP
Компьютер не умеет ходить «на сайт», ему нужен IP-адрес. Браузер ищет его в своём кэше, затем в кэше операционной системы и файле hosts, затем спрашивает DNS-резолвер. Тот при необходимости проходит цепочку: корневые серверы, серверы доменной зоны, авторитетный сервер домена. В ответ приходит запись A (IPv4) или AAAA (IPv6).
3. Соединение и шифрование
Браузер открывает TCP-соединение с сервером — трёхстороннее рукопожатие SYN, SYN-ACK, ACK. Для https поверх него идёт TLS-рукопожатие: стороны договариваются о шифрах, сервер присылает свой TLS-сертификат, браузер проверяет, что он выдан доверенным центром, не истёк и подходит к домену. В TLS 1.3 это укладывается в один обмен сообщениями. Если сайт работает по HTTP/3, вместо TCP используется QUIC поверх UDP.
4. HTTP-запрос и ответ
Браузер отправляет запрос GET / с заголовками: Host, User-Agent, Accept, cookie этого домена. На стороне сервера запрос может пройти балансировщик, веб-сервер, приложение и базу данных. Возвращается статус, заголовки и тело — обычно HTML. Вместо HTML может прийти редирект 301 или 302 с заголовком Location, и тогда браузер повторит путь уже по новому адресу.
GET / HTTP/1.1
Host: <домен сайта>
Accept: text/html
Cookie: session=...
5. Рендеринг и дозагрузка
Браузер разбирает HTML в DOM, по ссылкам загружает CSS, JavaScript, шрифты и картинки отдельными запросами, строит из CSS дерево стилей, рассчитывает раскладку и отрисовывает страницу. Скрипты после загрузки обычно запрашивают данные у API — каталог, профиль, корзину — и дорисовывают интерфейс.
Где это видно тестировщику
| шаг | где смотреть |
|---|---|
| DNS, соединение, TLS | Network → Timing: DNS Lookup, Initial connection, SSL |
| сертификат сервера | значок у адресной строки, вкладка Security |
| запрос и ответ | Network → Headers, Response |
| редиректы | цепочка запросов с кодами 3xx при включённом Preserve log |
| запросы к API | Network, фильтр Fetch/XHR |
| ошибки скриптов | Console |
Пример ответа
Сначала браузер разбирает адрес: схему, домен, путь — и проверяет кэш. Дальше ему нужен IP, поэтому идёт DNS-запрос: сначала локальные кэши, потом резолвер, который при необходимости опрашивает цепочку DNS-серверов. С IP браузер устанавливает TCP-соединение, а для https ещё и TLS: проверяет сертификат сервера и договаривается о шифровании. Потом отправляет HTTP-запрос GET с заголовками и cookie, сервер отвечает HTML или редиректом. Браузер разбирает HTML, дозагружает CSS, скрипты и картинки, строит страницу, а скрипты запрашивают данные у API. Как тестировщик я почти всё это вижу в DevTools: во вкладке Network — сами запросы, статусы и Timing с DNS и SSL, в Console — ошибки скриптов. Поэтому, если страница не открылась, я могу понять, на каком шаге всё остановилось: DNS не нашёл домен, сертификат сервера не прошёл проверку, сервер вернул 5xx или упал запрос к API.
Частые ошибки
- Ответить «открывается сайт» или перечислить три слова — DNS, HTTP, HTML — без связи между ними.
- Пропустить TLS и не знать, что именно браузер проверяет в сертификате сервера.
- Считать, что вся страница приходит одним ответом. На деле это десятки запросов, и данные часто подгружаются отдельно через API.
- Уйти в детали маршрутизации пакетов и потерять время, не дойдя до того, что видит пользователь.
- Не сказать ни слова о том, где каждый шаг наблюдать и как это помогает искать причину проблемы.
Пример на MarketCove
Представьте, что вы открываете главную страницу учебного магазина https://shop.tomiddle.com и проходите цепочку вживую. Откройте DevTools, во вкладке Network включите Preserve log и Disable cache, обновите страницу.
Первым будет запрос документа — у него тип document. Откройте Timing: если вы заходите впервые, там видны DNS Lookup, Initial connection и SSL. Обновите ещё раз — эти строки, скорее всего, исчезнут, потому что соединение переиспользуется. Дальше идут стили, скрипты и картинки товаров. Переключите фильтр на Fetch/XHR — и увидите, как страница запрашивает каталог у /api/products.
Теперь подумайте как тестировщик: что пользователь увидит, если каталог ответит 500 или будет отвечать десять секунд? Включите Throttling на медленную сеть и посмотрите, есть ли у каталога индикатор загрузки и понятное сообщение об ошибке. Так теоретический ответ превращается в конкретные проверки.
Задание для практики
Откройте любой знакомый сайт и разложите его загрузку по шагам из этой статьи. Запишите для документа время DNS, соединения, TLS и ожидания ответа сервера. Найдите хотя бы один редирект (например, введите адрес без https:// или без www) и запишите его код и заголовок Location. Посчитайте, сколько запросов к API делает страница после загрузки HTML. Затем расскажите цепочку вслух за две минуты, ссылаясь на то, что увидели. Для закрепления пройдите квесты по DevTools.
