Когда вы нажимаете «Войти» или открываете список заказов, страница не хранит эти данные у себя — она спрашивает сервер. Этот обмен «вопрос — ответ» лежит в основе почти всех приложений, и тестировщику важно понимать, как он устроен: где что ломается и как это увидеть.

Разберём три вещи: что такое клиент и сервер, по какому протоколу они общаются (HTTP/HTTPS) и из чего состоят сам запрос и ответ. Это фундамент, на котором стоят DevTools и тестирование API.

Клиент и сервер

Клиент — это то, чем пользуется человек: браузер, мобильное приложение. Он показывает интерфейс и отправляет запросы. Сервер — компьютер где-то в дата-центре, который хранит данные (пользователей, заказы) и отвечает на запросы клиента.

Аналогия: клиент — посетитель в кафе, сервер — кухня. Посетитель делает заказ (запрос), кухня готовит и отдаёт блюдо (ответ). Посетитель не заходит на кухню — он общается через понятный протокол «заказ — выдача».

Почему это важно тестировщику: баг может быть на клиенте (страница отправила не то или неправильно показала ответ) или на сервере (неправильно обработал, вернул ошибку). Понимая разделение, вы точнее определяете, где искать, и точнее пишете баг-репорт.

HTTP и HTTPS

HTTP (HyperText Transfer Protocol) — это язык, на котором клиент и сервер договариваются: как оформить запрос, как — ответ. Каждый раз, когда страница что-то грузит или отправляет, происходит HTTP-обмен.

HTTPS — то же самое, но зашифрованное (буква S — secure). Данные между клиентом и сервером идут в защищённом виде, их нельзя перехватить и прочитать по дороге. Сегодня нормальный сайт всегда работает по HTTPS; если сайт на обычном HTTP, браузер помечает его как «небезопасный». Это, кстати, тоже предмет проверки — что важные страницы (оплата, вход) идут по HTTPS.

Запрос: из чего состоит

Каждый запрос клиента к серверу состоит из нескольких частей:

  • Метод — что мы хотим сделать. Основные: GET (получить данные — «покажи заказы»), POST (создать — «оформи заказ»), PUT/PATCH (изменить), DELETE (удалить).
  • URL (адрес) — куда обращаемся, например example.com/api/orders.
  • Заголовки (headers) — служебная информация: формат данных, кто мы такие (токен авторизации), язык.
  • Тело (body) — сами данные, которые отправляем (обычно для POST), чаще всего в формате JSON.

JSON — простой текстовый формат «ключ: значение», в котором клиент и сервер обмениваются данными:

{ "email": "anna@example.com", "amount": 1500 }

Читается почти как обычный список: почта такая-то, сумма такая-то.

Ответ: из чего состоит

Сервер отвечает, и для тестировщика в ответе главное:

  • Статус-код — короткий итог запроса числом. Их группируют:
    • 2xx (200, 201) — успех, всё хорошо.
    • 3xx (301, 302) — перенаправление на другой адрес.
    • 4xx (400, 401, 403, 404) — ошибка на стороне клиента: неверный запрос, не авторизован, нет доступа, не найдено.
    • 5xx (500, 503) — ошибка на стороне сервера. Почти всегда баг.
  • Тело ответа — сами данные (обычно JSON): список заказов, созданный объект, сообщение об ошибке.

Группы статус-кодов нужно знать назубок: увидев 404, вы понимаете «не найдено», а 500 — «сломался сервер», и сразу знаете, в какую сторону копать.

Где это применяется

Эта модель — под каждым действием в приложении. Форма «молча» не сохранилась — открываете вкладку Network и смотрите: запрос ушёл? какой метод и URL? какой статус-код в ответе? Если 500 — баг на сервере, и это ценно для репорта. Если запрос вообще не ушёл — проблема на клиенте. А проверять запросы напрямую, перебирая варианты, удобно в Postman.

Где спотыкаются начинающие:

  • Не различают, где сломалось. «Не работает» — а Network показал бы: клиент отправил неверные данные или сервер ответил 500.
  • Не знают статус-коды. Хотя бы 2xx/4xx/5xx нужно понимать — они сразу говорят, где искать.
  • Игнорируют HTTPS. Важные страницы (оплата, вход) должны идти по защищённому протоколу — это тоже проверка.

Что учить дальше. Теперь, когда понятно, как страница общается с сервером, эти знания применяют на практике: смотрят обмен в DevTools и проверяют запросы руками в Postman.