Веб и сети: вопросы для собеседования QA

IP-адрес — это адрес устройства в сети, по которому пакеты находят получателя.

IPv4 использует 32 бита (примерно 4,3 млрд адресов), записывается как четыре числа через точку. IPv6 использует 128 бит, адресов на порядки больше, запись — через двоеточия.

Из практики: при интеграционных проблемах важно сразу смотреть, какой именно IP видит сервер и нет ли подмены через прокси или NAT.

Cookie хранят состояние сессии, настройки пользователя и токены авторизации. Проверяю атрибуты безопасности: HttpOnly (недоступен JS), Secure (только HTTPS), SameSite (защита от CSRF), срок действия.

Кэш браузера может отдавать устаревшие данные — проверяю корректность заголовков Cache-Control и Expires в ответах, а также поведение при принудительном обновлении.

Из практики: после выкладки новой версии дефекты часто объясняются именно кэшем — пользователь видит старый JS/CSS. Проверяю, что cache-busting работает через хэши в именах файлов.

Ключевые заголовки запроса, которые проверяю: Authorization (тип токена и его валидность), Content-Type (application/json vs form-data), Accept, X-Request-ID для трассировки.

Заголовки ответа: Content-Type (соответствует ли реальному содержимому), Cache-Control (правильно ли кэшируется), X-RateLimit, Set-Cookie (атрибуты Secure, HttpOnly, SameSite), CORS-заголовки.

Из практики: ошибка в одном заголовке часто ломает весь сценарий — неверный Content-Type в запросе даёт 415, отсутствие Authorization — 401, но без понятного тела ошибки.

Ключевые коды: 200 OK, 201 Created (POST с созданием), 204 No Content (DELETE без тела), 400 Bad Request (невалидный запрос), 401 Unauthorized (нет авторизации), 403 Forbidden (нет прав), 404 Not Found.

Дополнительно: 409 Conflict (дубликат), 422 Unprocessable Entity (семантическая ошибка), 429 Too Many Requests, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.

Из практики: проверяю не только код, но и тело ответа — код 400 без понятного описания ошибки заставляет разработчика клиента гадать, что именно не так.

HTTP-запрос обычно состоит из метода, пути, заголовков, параметров и тела.

HTTP-ответ содержит код статуса, заголовки и тело; в проверках я всегда смотрю согласованность всех трёх частей, а не только код.

Из практики: много дефектов находится, когда код 200, но тело или заголовки не соответствуют договору.

HTTPS — это HTTP поверх шифрования, чтобы данные не перехватили по пути.

В тестах проверяю сертификат, срок действия и корректную работу защищённого соединения.

Из практики: проблемы с сертификатами часто всплывают после продления или смены окружения.

VPN создаёт зашифрованный канал между устройством и удалённой сетью, скрывая прямой маршрут трафика.

Для QA он нужен для безопасного доступа к внутренним стендам и сервисам, недоступным из открытого интернета.

Из практики: при проблемах доступа первым делом проверяю маршрут, DNS и политику VPN-профиля.

HTML — язык разметки, который определяет структуру и содержимое веб-страницы с помощью тегов: заголовки, параграфы, ссылки, формы, изображения.

Браузер парсит HTML и строит DOM-дерево; JavaScript работает с этим деревом динамически. QA важно понимать DOM, чтобы строить надёжные локаторы и понимать, почему элемент может быть недоступен.

Из практики: при нестабильных локаторах в автотестах первым делом смотрю структуру DOM — часто элемент есть в HTML, но ещё не отрендерен или скрыт стилями.

CSS — язык описания стилей: задаёт оформление HTML-элементов (цвета, шрифты, размеры, отступы, расположение). Работает каскадно — несколько правил могут применяться к одному элементу, приоритет определяется специфичностью.

QA важно понимать CSS для тестирования адаптивности (медиа-запросы), кроссбраузерных различий и доступности (контраст, размеры шрифтов).

Из практики: визуальные баги часто связаны с конфликтами CSS-правил или неожиданным поведением flexbox/grid на разных браузерах — DevTools → Computed Styles быстро локализует проблему.

Эти инструменты позволяют перехватывать и анализировать HTTP(S)-трафик между клиентом и сервером.

С их помощью удобно проверять заголовки, подменять ответы, имитировать медленную сеть и воспроизводить нестандартные сбои.

Из практики: прокси-инструменты сильно помогают при расследовании багов, которые не ловятся только через интерфейс.

Браузер загружает HTML, строит DOM, затем CSSOM, после чего формирует дерево рендера и отрисовывает страницу.

JavaScript может менять DOM и стили, поэтому при тестировании важно учитывать момент выполнения скриптов и блокирующие ресурсы.

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

Кросс-браузерность: тестирую на основных движках — Blink (Chrome, Edge), Gecko (Firefox), WebKit (Safari). Использую DevTools → device emulation для быстрых проверок и BrowserStack для реальных устройств.

Адаптивность: проверяю контрольные точки (breakpoints) — 375px (мобильный), 768px (планшет), 1280px (десктоп). Смотрю переносы текста, доступность кнопок, поведение таблиц и форм.

Из практики: самые частые кроссбраузерные дефекты — в Safari (WebKit) и мобильных браузерах. Особенно внимательно проверяю CSS Grid, input[type=date] и обработчики событий.

В Network проверяю запросы: адрес, метод, код ответа, время и соответствие тела договору API.

В Console ищу ошибки скриптов и предупреждения, в Storage — токены, куки и кэш, влияющие на состояние пользователя.

Из практики: связка Network + Console обычно быстрее всего выводит на корень проблемы.

HTTP/1.1 часто страдает от ограничений параллельности, HTTP/2 лучше мультиплексирует запросы, HTTP/3 снижает задержки за счёт транспорта на основе QUIC.

Для QA важно проверять не только скорость, но и стабильность работы в целевой версии протокола на реальном контуре.

Из практики: после переключения версии протокола обычно всплывают проблемы в балансировщиках и сетевых настройках.

Проверяю схему данных и маппинг полей в UI, особенно nullable значения и форматы дат/денег.

Смотрю локализацию, округления, timezone и кеширование, потому что там часто скрывается причина.

Из практики: в отладке решает не догадка, а последовательность шагов — логи, запросы, данные, гипотеза, проверка.

Выделяю ключевые браузеры по аналитике пользователей и прогоняю один и тот же критичный поток в каждом: Chrome, Firefox, Safari, Edge — и мобильных браузерах.

Проверяю не только внешний вид, но и работу форм, валидаций, загрузок файлов и сообщений об ошибках — браузеры по-разному обрабатывают события и CSS.

Из практики: самые частые кроссбраузерные дефекты — в Safari (другой движок рендеринга) и в мобильных браузерах (разный обработчик событий touch vs click). Проверяю их в приоритете.

Проверяю основные контрольные ширины экрана и ориентации устройства, чтобы убедиться, что интерфейс не распадается.

Смотрю читаемость текста, доступность кнопок и поведение таблиц и форм на малых экранах.

Из практики: на мобильных ширинах часто ломаются sticky-элементы и таблицы, их проверяю отдельно.

Проверяю навигацию с клавиатуры (Tab, Enter, Escape), видимость фокуса, корректный порядок фокусировки элементов и доступность всех интерактивных элементов без мыши.

Проверяю контрастность текста и фона (WCAG AA: минимум 4.5:1), alt-тексты изображений, aria-labels для иконочных кнопок и понятность сообщений об ошибках для экранных читалок.

Из практики: доступность проще тестировать через axe DevTools и ручную проверку с VoiceOver/NVDA — автоматические инструменты ловят ~30% проблем, остальное требует ручной проверки.

Смотрю время до First Contentful Paint (FCP) и Time to Interactive (TTI) — момент, когда пользователь может начать действовать.

Проверяю, что при медленной загрузке есть понятное промежуточное состояние: скелетоны, спиннеры или прогресс-бар — пустой экран без индикатора воспринимается как зависание.

Из практики: тяжёлые страницы чаще всего тормозят из-за блокирующего JS или большого количества синхронных запросов — проверяю через Network в DevTools в режиме медленной сети.

Проверяю допустимые типы и размер файла, несколько загрузок подряд и удаление перед отправкой.

Добавляю негативные кейсы: неподдерживаемый формат, повреждённый файл.

Из практики: дополнительно сверяю, что файл корректно отдается по API и метаданные не теряются.

Проверяю переводы на полноту и корректность, формат дат и чисел по локали (dd.mm.yyyy vs mm/dd/yyyy), разделители тысяч и десятичных дробей, валютные символы.

Смотрю, что длинные переводы не обрезаются и не ломают вёрстку, RTL-языки отображаются корректно, сообщения об ошибках переведены, а не остаются на языке по умолчанию.

Из практики: самые частые дефекты локализации — необрезанный английский placeholder в переведённом интерфейсе и неверный формат дат, который ломает логику сортировки.

Проверяю запрос на разрешение уведомлений, содержимое уведомления (заголовок, текст, иконка), переход по нажатию на нужный экран и корректность состояния приложения после открытия.

Смотрю частоту отправки, отсутствие дублей, поведение при отказе от разрешения и корректность группировки уведомлений на устройстве.

Из практики: самый частый дефект — уведомление ведёт не туда или открывает приложение в неподготовленное состояние. Проверяю все состояния приложения: активное, свёрнутое, закрытое.

Проверю, что после смены языка сохраняются введённые данные и пользователь остаётся в том же шаге.

Проверю переводы, формат дат/чисел и корректность сообщений об ошибках после переключения.

Из практики: такие дефекты часто всплывают в длинных формах и шагах оплаты.

Стартовая строка (метод, путь, версия), заголовки (Host, User-Agent, Accept, Content-Type и др.) и (необязательно) тело сообщения.

Заголовки разделены пустой строкой от тела. Запросы GET, DELETE обычно без тела; POST, PUT, PATCH — с телом.

Из практики: для тестирования важно различать query parameters (в URL после ?), path parameters, тело и заголовки — все они могут влиять на поведение.

1xx — informational (101 Switching Protocols). 2xx — success (200 OK, 201 Created, 204 No Content). 3xx — redirect (301 Permanent, 302 Found, 304 Not Modified). 4xx — client error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable). 5xx — server error (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout).

Каждый код несёт смысл. Например, 401 — «не авторизован» (логиньтесь), 403 — «авторизован, но запрещено».

Из практики: тестировщик обязан различать 401/403, 400/404/409/422 — это основа правильного API-дизайна и часто источник пользовательских недоразумений.

GET — получить ресурс, без побочных эффектов, идемпотентен. POST — создать ресурс (или выполнить действие), не идемпотентен. PUT — заменить ресурс целиком, идемпотентен. PATCH — частично обновить, обычно не идемпотентен. DELETE — удалить, идемпотентен.

Идемпотентный метод — это тот, повтор которого даёт тот же результат на сервере. Это важно для повторов запросов после сбоя.

Из практики: реальные API не всегда строго следуют семантике — встречаются «POST для всего». При тестировании важно понимать, что обещает REST и что фактически делает API.

Cookies — это пары ключ-значение, которые сервер устанавливает в браузере и которые автоматически отправляются обратно в каждом запросе на тот же домен.

Важные флаги: Secure (только по HTTPS), HttpOnly (недоступны JS — защита от кражи через XSS), SameSite (Lax/Strict/None — защита от CSRF), Expires/Max-Age (срок жизни), Domain и Path.

Из практики: для сессионных и токен-cookies всегда HttpOnly + Secure + SameSite. Отсутствие любого из этих флагов — типовая находка пентеста.

CORS (Cross-Origin Resource Sharing) — это механизм браузера, позволяющий запросы из одного источника к другому только если сервер разрешил это через заголовки Access-Control-Allow-Origin и др.

Простые запросы (GET, POST с типовым Content-Type) уходят сразу, а сервер по ответу либо разрешает, либо блокирует. Сложные запросы предварительно делают OPTIONS preflight.

Из практики: типичные баги — забыли разрешить нужный домен на сервере, не вернули нужный метод в Access-Control-Allow-Methods, забыли credentials. В тестах часто проверяют, что preflight OPTIONS возвращает корректные заголовки.

HTTPS — это HTTP поверх TLS. TLS обеспечивает шифрование канала (никто посередине не прочитает данные), подлинность сервера (сертификат) и целостность (никто не подменит ответ).

Для тестировщика важно понимать: HTTPS защищает данные в дороге, но не на клиенте и не на сервере. Чувствительные данные нужно дополнительно защищать.

Из практики: проверяют валидность сертификата, отсутствие смешанного содержимого (HTTPS-страница, грузящая HTTP-ассеты), наличие HSTS, корректные редиректы с HTTP на HTTPS.

WebSocket — это протокол поверх TCP, который начинается с HTTP-handshake и переходит в двусторонний канал. После handshake клиент и сервер могут слать сообщения в любом направлении без новых запросов.

В отличие от HTTP, где каждый запрос — отдельная сделка, WebSocket держит постоянное соединение. Подходит для чатов, биржевых тикеров, уведомлений, многопользовательских игр.

Из практики: тестируют через инструменты вроде wscat, или встроенные в Postman, или библиотеки в коде. Проверяют переподключение при разрыве, обработку ошибок, упорядоченность сообщений.

DNS преобразует имя (example.com) в IP-адрес. Делается это иерархически: корневые серверы → TLD-серверы (.com) → авторитативные серверы зоны.

В работе тестировщик сталкивается с DNS, когда нужно: проверить новые поддомены, разобраться, куда указывает запись, симулировать поломку DNS, дебажить кэширование.

Из практики: утилиты dig и nslookup помогают посмотреть конкретную запись (A, CNAME, MX, TXT). Для теста разных окружений иногда правят /etc/hosts.

Прокси — это сервер-посредник, проходящий запросы клиента к серверу. Forward proxy представляет интересы клиента (Charles, Fiddler, Burp), reverse proxy — серверной стороны (nginx, HAProxy, Envoy).

В тестировании forward proxy (например, Charles) даёт перехват, просмотр и модификацию HTTP/HTTPS-трафика мобильного приложения или браузера. Позволяет проверить, что приложение отправляет правильно, и эмулировать ответы сервера.

Из практики: незаменимый инструмент при отладке клиент-серверного взаимодействия, особенно в мобильной разработке. Для HTTPS нужно установить корневой сертификат прокси на устройстве.

Charles — HTTP/HTTPS прокси для мониторинга и модификации трафика. Удобно перехватывать запросы мобильного приложения, видеть, что отправляется/получается.

Возможности: throttling (медленная сеть), rewrite (подмена ответов), breakpoints (пауза на запросе), recording.

Из практики: незаменим для отладки мобильных приложений. Альтернативы — Burp Suite (security-фокус), Proxyman, Fiddler.

HTTP/2 — бинарный, многоплекширование (один соединение, много запросов), server push, header compression (HPACK).

HTTP/3 — на основе QUIC (UDP-based), убирает head-of-line blocking, лучше для нестабильных мобильных сетей.

Из практики: для современных серверов и CDN HTTP/2 — стандарт. HTTP/3 распространяется, требует поддержки на стороне клиента и сервера.

Worker'ы на edge — это код, выполняющийся в CDN-узлах близко к пользователю. Cloudflare Workers, AWS Lambda@Edge, Vercel Edge Functions.

Применения: A/B-тесты, динамический контент с низкой latency, security checks, image manipulation, geo-routing.

Из практики: серверная логика без managing инфраструктуры. Минусы — ограничения CPU/memory, специфичный runtime.

Сетевой протокол — набор правил для обмена данными между узлами: формат пакетов, порядок установления соединения, обработка ошибок. Без общего протокола машины не понимают друг друга.

OSI — концептуальная модель из 7 уровней: физический, канальный, сетевой, транспортный, сеансовый, представления, прикладной. TCP/IP — практическая модель из 4 уровней: link, internet, transport, application. Большинство современных систем работает по TCP/IP.

Из практики: знать OSI полезно для общего словаря: «это L4-балансер», «проблема на L7». В реальности почти всегда работают TCP/IP-протоколы (HTTP, TCP, IP, Ethernet).

TLS (Transport Layer Security) — криптографический протокол поверх TCP, обеспечивающий шифрование канала, аутентификацию сервера (а опционально и клиента) и целостность данных. SSL — устаревший предшественник TLS.

Использует асимметричное шифрование при handshake (для обмена сессионным ключом) и симметричное — для самих данных. Аутентификация — через сертификаты X.509, выданные доверенным CA.

Из практики: TLS — основа HTTPS, защищённой почты, многих API. Современный стандарт — TLS 1.3 (быстрее handshake, удалены небезопасные алгоритмы). TLS 1.0/1.1 — выводятся из эксплуатации.

1) Браузер разбирает URL (схема, хост, путь). 2) DNS-резолв: имя хоста → IP (через кэш, /etc/hosts, рекурсивный DNS). 3) TCP-соединение (или QUIC для HTTP/3). 4) TLS handshake (для https). 5) HTTP-запрос с заголовками. 6) Сервер возвращает ответ (через CDN/балансер/app). 7) Браузер парсит HTML, строит DOM, грузит ресурсы (CSS, JS, шрифты, картинки), исполняет JS, рендерит.

По дороге включаются прокси, балансировщики, кэши на разных уровнях. Не каждый шаг занимает время, но любой может сломаться.

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

DNS (Domain Name System) — иерархическая распределённая система, преобразующая доменные имена в IP-адреса. Резолв проходит по цепочке: корневые сервера → TLD-сервера (.com) → серверы домена.

Записи: A (имя → IPv4), AAAA (IPv6), CNAME (псевдоним), MX (почта), TXT (произвольный текст, SPF/DKIM), NS (delegation), SRV (сервис). TTL — сколько хранить ответ в кэше.

Из практики: «странные» проблемы DNS чаще всего из-за кэширования и TTL. После изменения записи нужно подождать TTL — иначе пол-мира видит старое.

CORS (Cross-Origin Resource Sharing) — механизм браузера, разрешающий или запрещающий веб-странице с одного origin (схема+домен+порт) делать запросы к другому origin. По умолчанию запросы блокируются Same-Origin Policy.

Сервер указывает разрешения через заголовки Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials. Для «небезопасных» методов браузер сначала шлёт preflight (OPTIONS).

Из практики: CORS — это про защиту пользователя браузером, не про защиту сервера. Сервер всё равно сам проверяет авторизацию.