Что указывал в Body

Структура Body HTTP-запроса при тестировании API

Body HTTP-запроса — это ключевой элемент, который я указываю при тестировании API, особенно для методов POST, PUT и PATCH. Это основной механизм передачи данных от клиента к серверу. В зависимости от типа контента (Content-Type), структура и формат Body могут значительно отличаться. Вот основные типы, с которыми я работаю, и что в них указываю:

1. JSON (application/json)

Наиболее распространенный формат для REST API. Указываю структурированные данные в формате ключ-значение.

{
  "user": {
    "name": "Алексей",
    "email": "alexey@example.com",
    "age": 30,
    "isActive": true,
    "roles": ["admin", "editor"],
    "profile": {
      "department": "QA",
      "level": "senior"
    }
  }
}

Важные аспекты:

• Проверяю валидность синтаксиса JSON.
• Указываю различные типы данных: строки, числа, булевы значения, массивы, вложенные объекты.
• Уделяю внимание граничным значениям и некорректным типам (например, строка вместо числа в поле age) для тестирования валидации.

2. Form Data (application/x-www-form-urlencoded)

Используется для имитации отправки данных из HTML-форм. Данные кодируются в виде пар key=value, объединенных амперсандом &.

username=Ivan_Petrov&password=Secret123&remember_me=true

На что обращаю внимание:

• Корректное URL-кодирование специальных символов (пробелы, &, = и др.).
• Передача бинарных данных (файлов) в этой форме невозможна.

3. Multipart Form Data (multipart/form-data)

Основной формат для загрузки файлов вместе с текстовыми полями. Тело разделяется на части (parts) границей (boundary).

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="documentName"

Отчет по тестированию
----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="report.pdf"
Content-Type: application/pdf

(бинарное содержимое файла report.pdf)
----WebKitFormBoundary7MA4YWxkTrZu0gW

Ключевые моменты:

• Указываю имя файла (filename) и его MIME-тип (Content-Type).
• Тестирую загрузку файлов разных типов, размеров (в т.ч. превышающих лимит), с поврежденными данными.

4. XML (application/xml)

Реже встречается в современных REST API, но еще используется в SOAP и некоторых legacy-системах.

<CreateUserRequest>
    <FirstName>Мария</FirstName>
    <LastName>Сидорова</LastName>
    <Email>maria.s@example.com</Email>
    <Permissions>
        <Permission>read</Permission>
        <Permission>write</Permission>
    </Permissions>
</CreateUserRequest>

Особенности тестирования:

• Проверка корректности XML-схемы (XSD).
• Вариация структуры тегов и атрибутов.

5. Plain Text (text/plain), HTML (text/html), Binary Data

• Plain Text: Указываю простой текст для эндпоинтов, которые его принимают (например, webhook-и или логи).

  Произошла критическая ошибка в модуле платежей: Timeout.
  

• Binary Data: Прямая передача бинарных данных (например, изображение в формате image/png). Тестирую целостность данных после передачи.

Стратегия заполнения Body при тестировании

Я не просто указываю валидные данные. Моя задача — проверить устойчивость и безопасность API. Поэтому в Body я целенаправленно указываю:

• Корректные данные: Для проверки позитивных сценариев.
• Данные с ошибками валидации:

    *   Обязательные поля: пустые строки `""`, `null`, полное отсутствие ключа.
    *   Неверные форматы: email без `@`, дата в формате `DD.MM.YYYY` вместо ожидаемого `YYYY-MM-DD`.
    *   Некорректные типы: число вместо строки, массив вместо объекта.

• Данные для проверки безопасности:

    *   **SQL-инъекции:** `"username": "admin' OR '1'='1"`
    *   **XSS-векторы:** `"comment": "<script>alert('xss')</script>"`
    *   **Огромные объемы данных** (Big Payloads) в строковых полях для проверки на переполнение буфера или DoS.
    *   **Глубоко вложенные объекты/массивы** для проверки рекурсивного парсинга.

• Граничные и экстремальные значения:

    *   Максимально допустимая длина строки.
    *   Минимальные/максимальные числа (`integer`, `float`).
    *   Отрицательные числа и ноль, где они могут быть неожиданны.

• Избыточные данные: Отправка полей, не описанных в спецификации (контракте) API, чтобы проверить, игнорирует ли их сервер или возвращает ошибку.

Пример комбинации для негативного теста:

{
  "email": "", // Пустое обязательное поле
  "password": 12345, // Число вместо строки
  "extraField": "maliciousData", // Неожиданное поле
  "role": ["<script>alert(1)</script>", {"$ne": null}] // Попытка XSS и NoSQL-инъекции
}

Итог: Указание Body — это не рутина, а целенаправленное конструирование входных данных для проверки функциональности, надежности, валидации и безопасности бэкенд-логики. Я всегда отталкиваюсь от документации API (OpenAPI/Swagger), но также активно исследую поведение системы за ее пределами, используя техники тест-дизайна, такие как классы эквивалентности, граничные значения и анализ причинно-следственных связей.