Какие компоненты HTTP-запроса, помимо тела (Body), необходимо тестировать при проверке API?

Тип вопроса: API тестирование Вероятность: 23% Категория: AQA / Automation

Ответ

Тело запроса — лишь одна часть. Для всестороннего тестирования API необходимо валидировать все элементы HTTP-запроса и реакции сервера.

Ключевые компоненты для тестирования:

Компонент Что проверять Пример/Инструмент
1. Заголовки (Headers) Content-Type, Authorization, Accept, Cache-Control, кастомные заголовки. requests.get(url, headers={'Accept': 'application/xml'})
2. Метод HTTP (Verb) Корректность использования GET, POST, PUT, DELETE, PATCH. Обработка недопустимых методов. Тестирование POST на эндпоинт, предназначенный только для GET.
3. Путь (Path) и параметры пути Валидные и невалидные ID в URL (например, /users/{id}). /users/999999 (несуществующий ID) → 404.
4. Query Parameters Параметры фильтрации, сортировки, пагинации (?limit=10&page=2). Граничные значения. ?limit=0, ?limit=1000 (превышение лимита).
5. Статус-код ответа Соответствие фактического кода ожидаемому для сценария. 200 OK, 201 Created, 400 Bad Request, 429 Too Many Requests.
6. Заголовки ответа Content-Type, Location (для 201), RateLimit-Limit, Cache-Control. Проверка, что Content-Type ответа соответствует Accept запроса.
7. Структура и данные ответа Соответствие JSON/XML схеме, типы данных, значения. Валидация через jsonschema или pydantic.
8. Время ответа (Performance) Соответствие SLA (например, < 200 мс для 95% запросов). Использование pytest с плагинами (pytest-benchmark) или k6 для нагрузочного тестирования.

Практический пример теста, проверяющего несколько компонентов:

import requests

def test_api_components():
    url = "https://api.example.com/search"
    params = {"q": "test", "limit": 5}  # Query Parameters
    headers = {
        "Authorization": "Bearer token123", # Заголовок авторизации
        "Accept": "application/json"        # Заголовок Accept
    }

    response = requests.get(url, params=params, headers=headers)

    # 1. Проверка статус-кода
    assert response.status_code == 200
    # 2. Проверка заголовка ответа
    assert response.headers["Content-Type"] == "application/json"
    # 3. Проверка структуры данных
    data = response.json()
    assert isinstance(data["results"], list)
    assert len(data["results"]) <= 5  # Проверка работы limit
    # 4. Проверка времени ответа (перформанс)
    assert response.elapsed.total_seconds() < 1.0

Ответ 18+ 🔞

А, вот ты где, мой друг! Смотри-ка, какой умный пришёл, думает, что тестирование API — это только тело запроса проверить. Да ты, блядь, в рот мне чих-пых, наивный как дитя малое! Это всё равно что машину оценивать только по цвету сидений, а про двигатель забыть.

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

Вот на что надо глаз положить, как ястреб:

Что ломаем На что смотрим Чем долбим
1. Заголовки (Headers) Content-Type, Authorization, Accept. А ещё эти, блядь, кастомные, которые бэкендеры от скуки придумали. requests.get(url, headers={'Accept': 'application/xml'})
2. Метод HTTP (Verb) Правильно ли POST там, где надо POST? А если ему GET'ом плюнуть в рожу? Обработает ли? Засадить POST на эндпоинт, который только GET жрёт.
3. Путь (Path) и параметры пути А если в URL вместо ID подсунуть 999999 или, того хуже, ' OR '1'='1? /users/999999 → должен 404 вернуть, а не 500 с полотнищем SQL-логов.
4. Query Parameters Эти ваши ?limit=10&page=2. А если limit=0? А если limit=100500? А если page=-1? ?limit=0, ?limit=1000 (смотреть, не обосрётся ли логика).
5. Статус-код ответа Главное, блядь! 200 — хорошо. 201 — отлично. 400 — молодец, валидируешь. 429 — ах ты ж хитрая жопа, rate limit поставил! Сравнивать, что пришло, с тем, что должно прийти.
6. Заголовки ответа Content-Type ответа совпадает с тем, что в Accept просили? А Location заголовок после 201 пришёл? Смотреть, не врёт ли сервер.
7. Структура и данные ответа JSON пришёл или, прости господи, XML? А поля все на месте? А типы правильные? Валидировать через jsonschema или pydantic.
8. Время ответа (Performance) А не долго ли он, сука, думает? Уложился в 200 мс или уже можно чай заварить? pytest-benchmark или k6 для нагрузки, чтобы понять, когда он накроется медным тазом.

Ну и смотри, как это в коде выглядит, чтоб ты не думал, что это всё высшая математика:

import requests

def test_api_components():
    url = "https://api.example.com/search"
    params = {"q": "test", "limit": 5}  # Query Parameters
    headers = {
        "Authorization": "Bearer token123", # Заголовок авторизации
        "Accept": "application/json"        # Заголовок Accept
    }

    response = requests.get(url, params=params, headers=headers)

    # 1. Проверка статус-кода
    assert response.status_code == 200
    # 2. Проверка заголовка ответа
    assert response.headers["Content-Type"] == "application/json"
    # 3. Проверка структуры данных
    data = response.json()
    assert isinstance(data["results"], list)
    assert len(data["results"]) <= 5  # Проверка работы limit
    # 4. Проверка времени ответа (перформанс)
    assert response.elapsed.total_seconds() < 1.0

Вот так вот, ёпта. Тестировать API — это не только про то, что в теле запроса лежит. Это про то, чтобы проверить всю эту, блядь, конструкцию от винтика до гайки. А то потом продакшн упадёт, а ты будешь делать круглые глаза: «Ну я же тестировал!». Да ни хуя ты не тестировал, дружок!

© ХакСобесов, 2026
support@hacksobesov.com