Контекст

HTTP (HyperText Transfer Protocol) — это текстовый протокол прикладного уровня, по которому браузер, мобильное приложение или любой другой клиент общается с веб-сервером. QA-инженер работает с HTTP каждый день: снимает трафик в DevTools, составляет запросы в Postman, разбирает баг-репорты. Без понимания модели клиент-сервер невозможно толково описать ни одну ошибку API.

Клиент — это сторона, которая инициирует соединение и формулирует запрос (браузер, мобильное приложение, Postman, curl).
Сервер — сторона, которая принимает запрос, обрабатывает его и отправляет ответ.
HTTP работает поверх TCP/IP: каждый запрос — это отдельное «письмо» с чётко определённой структурой (стартовая строка, заголовки, тело).
HTTP/1.1 использует текстовый формат; HTTP/2 и HTTP/3 бинарные, но для QA смысловая модель остаётся той же.
HTTPS — то же самое, что HTTP, но канал зашифрован через TLS; тестировщику это важно при проверке сертификатов и перехвате трафика.

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

Когда вы тестируете API-взаимодействие, пройдитесь по следующему чеклисту, чтобы восстановить полную картину запроса и ответа:

Определите клиента: кто отправляет запрос — браузер, мобильное приложение или сервис-потребитель?
Зафиксируйте HTTP-метод и URL: это точка входа в API.
Откройте вкладку Network в DevTools или Postman Console — посмотрите стартовую строку запроса (метод + путь + версия протокола).
Изучите заголовки запроса: Content-Type, Authorization, Accept — они определяют контракт обмена.
Получите ответ: запомните статус-код, заголовки ответа и тело — именно их вы будете проверять.
Убедитесь, что соединение завершилось корректно: нет таймаутов, нет обрыва TCP-сессии.

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

Тестировщик проверяет, что профиль пользователя загружается после входа. В Postman он отправляет: GET /api/v1/users/me HTTP/1.1 Host: api.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... Accept: application/json Сервер возвращает: HTTP/1.1 200 OK Content-Type: application/json {"id":"usr_1847","email":"alice@example.com","plan":"pro","createdAt":"2025-03-12T09:00:00Z"} Вывод: клиент (Postman) сформировал запрос с Bearer-токеном, сервер аутентифицировал его, нашёл пользователя и вернул JSON с полным профилем. Статус 200 и наличие поля email — первые два assertion в тест-кейсе.

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

Новички в API-тестировании регулярно попадают в следующие ловушки:

Путают клиент и сервер в баг-репорте — пишут «сервер не отправил запрос», хотя имеют в виду клиентскую ошибку формирования запроса.
Игнорируют версию протокола: API на HTTP/2 может вести себя иначе в части мультиплексирования — важно уточнять при репродукции.
Считают HTTPS и HTTP идентичными для тестирования: при перехвате HTTPS-трафика нужно установить доверенный сертификат прокси (Charles, mitmproxy), иначе запросы не будут видны.
Не смотрят на стартовую строку ответа — пропускают случаи, когда сервер вернул HTTP/1.0 вместо ожидаемого HTTP/1.1, что влияет на keep-alive.

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

1Кто в модели клиент-сервер инициирует соединение?

Всегда клиент. Сервер только ожидает входящих подключений и отвечает на них.

2Чем HTTPS отличается от HTTP с точки зрения тестировщика?

HTTPS шифрует канал через TLS. Для перехвата трафика нужно установить доверенный сертификат прокси; в остальном структура запроса/ответа такая же, как в HTTP.

3Из каких трёх частей состоит HTTP-запрос?

Стартовая строка (метод, путь, версия протокола), заголовки (пары ключ-значение) и тело (может быть пустым).

4Почему версия протокола HTTP важна при воспроизведении бага?

HTTP/2 поддерживает мультиплексирование и сжатие заголовков, HTTP/1.1 — нет. Поведение при параллельных запросах и keep-alive различается, поэтому баг может не воспроизводиться при смене протокола.

5Какой инструмент позволяет увидеть сырые HTTP-заголовки прямо в командной строке?

curl с флагом -v (verbose) — он выводит стартовую строку запроса и ответа, все заголовки и тело.