Что нужно тестировать помимо тела запроса?

Что нужно тестировать помимо тела запроса в API-автоматизации?

При тестировании API, особенно в контексте QA Automation, фокус исключительно на теле запроса — это распространённая, но грубая ошибка. Тело запроса (payload) — лишь один из многих критически важных компонентов. Полноценная стратегия тестирования API должна быть всеобъемлющей (comprehensive) и охватывать все элементы HTTP-взаимодействия и бизнес-логики.

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

1. Заголовки запроса (Request Headers)

Заголовки управляют поведением API и являются контрактом между клиентом и сервером. Обязательно нужно тестировать:

• Авторизация/Аутентификация: Корректность и срок жизни токенов в Authorization, Bearer token, API-Key.
• Content-Type и Accept: Проверка, что сервер корректно обрабатывает заявленные форматы (JSON, XML, form-data) и возвращает данные в ожидаемом формате.
• Кастомные заголовки: Заголовки, специфичные для бизнес-логики (например, X-Request-ID для трассировки).
• Условные запросы: Заголовки If-Modified-Since, If-None-Match для кэширования.

Пример теста на валидацию Content-Type:

import pytest
import requests

def test_api_requires_json_header(base_url):
    """Тест: API возвращает ошибку 415 при отсутствии заголовка Content-Type: application/json"""
    endpoint = f"{base_url}/api/v1/users"
    payload = {"name": "Test User"}
    
    # Отправляем запрос БЕЗ обязательного заголовка
    response = requests.post(endpoint, data=payload)
    
    assert response.status_code == 415, f"Ожидался статус 415, получен {response.status_code}"
    # Дополнительно можно проверить тело ошибки

2. Параметры запроса (Query Parameters, Path Parameters)

• Path Parameters: Валидация параметров, встроенных в URL (например, /users/{id}). Тестируются граничные значения, невалидные типы (строка вместо числа), отсутствующие ресурсы.
• Query Parameters: Параметры для фильтрации, сортировки, пагинации (?page=2&limit=10&sort=name). Нужно проверять:

    *   Работоспособность каждого параметра.
    *   Комбинации параметров.
    *   Значения по умолчанию.
    *   Валидацию (например, отрицательный `limit`).

3. Методы HTTP (HTTP Methods)

Тестирование неверных методов для эндпоинтов — важная проверка безопасности и соответствия RESTful-дизайну.

• Вызов POST на эндпоинт, ожидающий только GET.
• Проверка, что методы PUT, PATCH, DELETE требуют авторизации и возвращают корректные коды состояния (405, 401, 403).

4. Коды состояния HTTP (HTTP Status Codes)

Это основной язык общения API. Автоматизация должна явно проверять ожидаемые коды:

• 2xx (Успех) для позитивных сценариев.
• 4xx (Ошибка клиента) для невалидных данных, отсутствия прав, неверного формата запроса.
• 5xx (Ошибка сервера) — такие ответы в рабочем приложении недопустимы и должны выявляться.

5. Заголовки ответа (Response Headers)

Часто содержат важную мета-информацию:

• CORS-заголовки (Access-Control-Allow-Origin) для веб-приложений.
• Заголовки безопасности: Strict-Transport-Security, X-Content-Type-Options.
• Заголовки для пагинации: Link, X-Total-Count.
• Rate Limiting: X-RateLimit-Limit, X-RateLimit-Remaining.

6. Структура и качество данных в теле ответа (Response Body)

Помимо проверки конкретных значений, необходимо валидировать:

• Схему ответа (JSON Schema): Соответствие ожидаемым типам данных, обязательным полям, вложенным структурам.
• Консистентность данных: Соответствие данных в ответе состоянию в БД или другим связанным API.
• Чувствительные данные: Отсутствие в ответе паролей, токенов, персональных данных (если не требуется).

Пример валидации JSON Schema:

from jsonschema import validate
import requests

schema = {
    "type": "object",
    "properties": {
        "id": {"type": "integer"},
        "name": {"type": "string"},
        "email": {"type": "string", "format": "email"},
        "createdAt": {"type": "string", "format": "date-time"}
    },
    "required": ["id", "name", "email"]
}

def test_user_schema(base_url):
    response = requests.get(f"{base_url}/api/v1/users/1")
    assert response.status_code == 200
    user_data = response.json()
    
    # Валидация ответа против схемы
    validate(instance=user_data, schema=schema)

7. Производительность и временные характеристики (Performance)

• Время отклика (Response Time): Укладывается ли в SLA (например, < 200 мс для критичных эндпоинтов).
• Таймауты: Поведение системы при медленных ответах зависимых сервисов.

8. Безопасность (Security Testing)

• Инъекции: Проверка параметров и тела на уязвимости к SQL/NoSQL-инъекциям.
• Массовое присвоение (Mass Assignment): Попытка передать в запросе поля, которые не должны обновляться клиентом (например, isAdmin: true).
• Чувствительные данные в логах: Не попадают ли пароли и токены в логи сервера.

Заключение

Эффективный QA Automation Engineer строит тестовое покрытие API как многослойную защиту. Тело запроса — это только "полезная нагрузка". Игнорирование заголовков, параметров, кодов состояния и аспектов безопасности приводит к хрупким тестам и пропуску критических дефектов, которые проявляются на интеграционной стадии или, что хуже, в production-среде. Стратегия должна включать позитивные, негативные, граничные и деструктивные тесты для каждого из перечисленных компонентов, что в итоге обеспечивает надежность, безопасность и предсказуемость сервиса.