Клиент-серверное взаимодействие
Большая часть того, что показывает страница, приходит по сети: страница, работающая в браузере, выступает клиентом и запрашивает данные у сервера, а сервер отвечает. Эта пара — запрос и ответ — основной объект анализа при тестировании веб-приложений.
Содержание страницы
Клиент, сервер и фронтенд
Клиент — программа, через которую человек открывает приложение, чаще всего браузер. Видимая часть приложения, работающая в браузере, называется фронтендом: она показывает кнопки и формы, реагирует на клики и запрашивает данные.
Сервер, или бэкенд, — программа на другом компьютере. Она получает запросы, проверяет права и данные, обращается к базе данных или другим сервисам, а затем готовит ответ. Браузер не подключается к базе напрямую и не видит код сервера.
Разбор взаимодействия
Например, пользователь открывает список товаров:
1. Браузер отправляет на сервер GET /api/products.
2. Сервер обрабатывает запрос и возвращает список товаров, находящихся в базе данных.
3. Сервер возвращает HTTP-ответ, например 200 OK и список в JSON.
4. Фронтенд получает ответ и отображает карточки товаров.
Если карточек нет, дефект может быть на любом шаге: запрос не отправился, сервер вернул ошибку или неверные данные, либо фронтенд не показал корректные данные. Вкладка Network в DevTools позволяет увидеть эту цепочку. Подробнее разберём это в следующих карточках.
Что такое HTTP
HTTP расшифровывается как HyperText Transfer Protocol — протокол передачи гипертекста. Это общий набор правил, по которым клиент и сервер обмениваются сообщениями: из чего состоит запрос и ответ, как сообщить результат кодом статуса. HTTP не хранит состояние: каждый запрос сам по себе, поэтому сервер не помнит предыдущий автоматически. Cookie и токены авторизации в заголовках помогают ему понять, кто отправил запрос. HTTPS — это HTTP в защищённом, зашифрованном соединении; его используют обычные сайты.
Из чего состоит запрос
- Метод — запрашиваемое действие:GET — получить.POST — создать.PUT и PATCH — изменить.DELETE — удалить.
- URL — адрес, на который отправляется запрос. Он может состоять из адреса сайта, пути к ресурсу и query-параметров:https://shop.example.com/products?city=tallinnhttps://shop.example.com — адрес сайта;/products — путь к ресурсу;?city=tallinn — query-параметр, который передаёт дополнительное условие для запроса.
- Заголовки — техническая информация, передаваемая вместе с запросом: например, тип содержимого или токен авторизации.Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
- Тело запроса (request body) — полезная нагрузка, которую клиент передаёт серверу. Обычно это данные в формате JSON для создания или изменения ресурса. У GET-запросов тело, как правило, отсутствует; POST обычно используют для передачи тела при создании ресурса.{"name": "Sneakers","price": 79.99}
Что такое JSON
JSON — JavaScript Object Notation — текстовый формат, в котором клиент и сервер передают друг другу данные. Он рассчитан на программу, но читается и человеком — поэтому тело ответа имеет смысл открывать.
Данные записываются парами «ключ — значение». Ключ всегда в двойных кавычках, пары разделяются запятыми, всё вместе заключено в фигурные скобки — это объект:
{
"id": 12,
"name": "Sneakers",
"price": 79.99,
"inStock": true,
"discount": null
}
По самому значению видно его тип: строка — в двойных кавычках, число — без них, true и false — логические значения, null — значения нет. Различие важное: если цена пришла строкой "79.99" вместо числа 79.99, это дефект, даже когда на странице она отображается правильно.
Квадратные скобки — это массив, список значений, чаще всего список объектов. Объекты вкладываются друг в друга, так связанные данные передаются вместе:
{
"city": "Tallinn",
"products": [
{ "id": 12, "name": "Sneakers" },
{ "id": 15, "name": "Boots" }
]
}
Во вкладке Network тело в исходном виде находится в Response, а Preview показывает те же данные разложенными: вложенные объекты там можно раскрывать. Два случая, которые на экране выглядят одинаково, здесь различаются: пустой список приходит как [], а отсутствующее значение — как null, и страница в обоих случаях показывает «ничего нет».
Методы запросов
Метод сообщает серверу, что нужно сделать с ресурсом. Один и тот же адрес с разными методами означает разные действия.
- GET — получить данные и ничего не изменять: GET /api/products?city=tallinn вернёт список товаров. Параметры передаются в адресе, тела у запроса обычно нет.
- POST — создать: POST /api/orders с телом в формате JSON создаёт новый заказ.
- PUT — заменить ресурс целиком: PUT /api/products/12 с полным телом. Поля, которых в этом теле нет, ресурс потеряет.
- PATCH — изменить часть: PATCH /api/products/12 с телом {"price": 79.99} меняет только цену.
- DELETE — удалить: DELETE /api/products/12.
Повторный запрос для разных методов означает разное. GET, PUT и DELETE сколько ни повторяй, система останется в том же состоянии: товар 12 можно удалить только один раз. А повторный POST обычно создаёт ещё одну запись — отсюда и берутся два одинаковых заказа после двойного клика.
Что проверяет тестировщик: метод в Network → Headers соответствует действию на экране. Поиск или фильтр, отправленный методом GET, можно сохранить в закладки и переслать ссылкой; тот же поиск через POST — уже нет. Данные, изменённые или удалённые методом GET, — повод завести дефект.
Path- и query-параметры
Оба передают информацию в URL, но находятся в разных местах. Path-параметр — часть пути, которая идентифицирует ресурс: в /sections/3 число 3 идентифицирует раздел. Query-параметр начинается после ? и обычно фильтрует, сортирует или настраивает ответ: в /sections/3?language=en&page=2 параметрами query будут language и page. В Network полный URL виден во вкладке Headers, а query-параметры дополнительно сгруппированы во вкладке Payload.
Из чего состоит ответ
Код статуса, собственные заголовки и тело с данными, которые страница затем отображает. Расхождение между тем, что показано на странице, и содержимым тела ответа локализует дефект: либо данные пришли корректные и страница отобразила их неверно, либо данные были некорректными изначально.
Коды статусов: четыре группы
Первая цифра определяет группу кода статуса:
- 2xx — успех.
- 3xx — перенаправление.
- 4xx — ошибка в запросе.
- 5xx — ошибка на сервере.
Группа указывает, на чьей стороне дефект: 4xx обычно означает, что страница отправила некорректные данные, 5xx — что бэкенд не обработал корректный запрос.
Коды, которые встречаются чаще всего
- 200 OK — ответ содержит тело. 201 Created — ресурс создан, обычно после POST. 204 No Content — операция выполнена, данные не возвращаются.
- 301 и 302 — постоянное и временное перенаправление. 304 Not Modified — ресурс не изменился, браузер использует копию из кэша. Это штатное поведение, а не ошибка.
- 400 Bad Request — сервер не смог разобрать запрос. 422 — запрос разобран, данные не прошли валидацию; дефекты форм обычно дают этот код.
- 401 Unauthorized — пользователь не аутентифицирован. 403 Forbidden — пользователь аутентифицирован, но не имеет необходимых прав.
- 404 Not Found — по этому адресу ресурса нет, сам сервер при этом работает. 409 Conflict — запрос конфликтует с текущим состоянием, например регистрация на уже занятый адрес почты.
- 429 Too Many Requests — достигнут лимит частоты запросов.
- 500 Internal Server Error — необработанная ошибка на бэкенде. 502 Bad Gateway и 504 Gateway Timeout — прокси не смог обратиться к сервису или не получил ответ вовремя. 503 Service Unavailable — сервис недоступен или перегружен, часто во время выкатки.
Смотрите не только на статус
HTTP-статус показывает, как сервер обработал запрос на уровне протокола.
Например, 200 OK означает, что сервер получил запрос и вернул ответ без HTTP-ошибки. Но сам ответ при этом может быть неправильным с точки зрения логики приложения.
Представим, что мы запрашиваем список заказов. В Network видим статус 200, но на странице список пустой.
Открываем Response и смотрим, что пришло от сервера. Там может оказаться:
- пустой массив [];
- неправильная сумма;
- устаревшие данные;
- объект не того пользователя;
- "success": false;
- ошибка, переданная внутри тела ответа.
То есть одного статуса недостаточно.
После проверки Status посмотрите Response и убедитесь, что сервер вернул именно те данные, которые ожидались.
200 + правильные данные в Response, но на странице ничего нет → скорее всего, проблема возникает уже при обработке или отображении ответа на клиенте.
200 + неправильные данные в Response → проблема появилась раньше, ещё до отображения данных на странице.
На собеседовании
На собеседовании обычно просят не заученные определения, а рассуждение по конкретному запросу. Попробуйте ответить сами, прежде чем открыть ответ.
juniorначальный уровень знаний
1. Из чего состоит HTTP-запрос?
В запросе есть метод, URL, заголовки и при необходимости тело. Например, POST-запрос может отправить JSON в теле, а в заголовке передать тип содержимого и токен авторизации.
2. Чем отличаются коды ответа 401 и 403?
401 Unauthorized означает, что пользователь не аутентифицирован: например, не вошёл в систему или его токен недействителен. 403 Forbidden означает, что пользователь определён, но у него нет прав на это действие.
3. О чём обычно говорят статусы 4xx и 5xx?
4xx обычно указывает на проблему в запросе: неверные данные, отсутствие авторизации или прав, несуществующий адрес. 5xx означает, что сервер не смог корректно обработать запрос. Это ориентир для локализации, а не окончательный диагноз.
4. Чем отличаются GET и POST?
GET запрашивает данные и не должен их изменять: параметры уходят в адресе, тела у запроса обычно нет, ссылку можно сохранить в закладки или переслать. POST отправляет данные на сервер в теле запроса — обычно чтобы что-то создать, и повторная отправка обычно создаёт ещё одну запись.
5. Чем отличаются PUT и PATCH?
PUT заменяет ресурс целиком: в теле передаётся полный набор полей, и то, чего в нём нет, ресурс теряет. PATCH меняет только переданные поля — например, тело {"price": 79.99} изменит цену товара и не тронет остальное.
middleболее продвинутый уровень
6. Достаточно ли статуса 200, чтобы считать ответ правильным?
Нет. 200 OK подтверждает успешную обработку HTTP-запроса, но в Response могут прийти пустые, устаревшие или чужие данные, а также логическая ошибка внутри тела ответа. Нужно сверить тело ответа с ожидаемым результатом.
7. На странице нет заказов, хотя запрос вернул 200. Как искать проблему?
Открыть тело ответа. Если там правильный список заказов, проблема, вероятно, в обработке или отображении данных фронтендом. Если список уже пустой или неверный, дефект возник до рендеринга — в данных, запросе или на сервере.
8. Пользователь дважды нажал «Оформить заказ» и получил два заказа. Что покажет вкладка Network?
Два одинаковых POST-запроса, оба со статусом 2xx: сервер добросовестно создал две записи. Повторный POST так и должен работать — в отличие от PUT и DELETE, где повтор оставляет систему в прежнем состоянии. Значит, дело не в самом запросе: нет защиты от повторной отправки — ни блокировки кнопки, ни проверки на стороне сервера. К отчёту прикладывают оба запроса и оба ответа.
Вопросы по остальным темам собраны на странице Вопросы на собеседовании QA по DevTools.