Какие HTTP запросы тестировал?

Опыт тестирования HTTP-запросов

В качестве QA Automation Engineer я тестировал полный спектр HTTP-запросов, что является фундаментальной частью веб-API тестирования. Моя работа охватывала как базовые методы, так и более сложные сценарии с кастомными заголовками, авторизацией и различными форматами данных.

Основные HTTP-методы, которые я регулярно тестирую:

1. GET — для получения ресурсов. Тестировал:

    *   Получение одиночных и коллекций данных
    *   Пагинацию, фильтрацию, сортировку через query-параметры
    *   Кэширование (заголовки `Cache-Control`, `ETag`)
    *   Коды ответов: `200 OK`, `404 Not Found`, `304 Not Modified`

1. POST — для создания ресурсов. Тестировал:

    *   Создание с валидными и невалидными данными в `body`
    *   Различные `Content-Type`: `application/json`, `application/x-www-form-urlencoded`, `multipart/form-data` (для загрузки файлов)
    *   Ответы: `201 Created` (с заголовком `Location`), `400 Bad Request`, `409 Conflict`

1. PUT — для полного обновления ресурса. Тестировал:

    *   Идемпотентность (повторные запросы дают тот же результат)
    *   Отправку полного представления ресурса
    *   Ответы: `200 OK`, `204 No Content`, `404 Not Found`

1. PATCH — для частичного обновления. Тестировал:

    *   Форматы JSON Patch (RFC 6902) и JSON Merge Patch (RFC 7396)
    *   Сценарии, когда отправляются только изменяемые поля
    *   Валидацию частичных данных

1. DELETE — для удаления ресурсов. Тестировал:

    *   Мягкое и жесткое удаление
    *   Каскадное удаление зависимых ресурсов
    *   Ответы: `204 No Content`, `200 OK` (с телом), `404 Not Found`, `409 Conflict` (если удаление невозможно)

1. HEAD и OPTIONS — для получения метаданных:

    *   `HEAD` — проверка заголовков ответа без тела (полезно для проверки доступности и размера контента)
    *   `OPTIONS` — получение разрешенных методов для эндпоинта (CORS, заголовок `Allow`)

Дополнительные аспекты и сложные сценарии тестирования:

• Авторизация и аутентификация: Тестирование запросов с заголовками Authorization (Bearer token, Basic Auth, JWT), куками, сессиями.
• Обработка ошибок: Валидация структуры и информативности тел ошибок при кодах 4xx и 5xx.
• Параметры запроса: Работа с path-параметрами, query-строками, заголовками.
• Нагрузочное тестирование API: Использование GET и POST запросов в JMeter или k6 для проверки производительности и стабильности эндпоинтов.
• Тестирование специфичных заголовков: Accept (negotiation), User-Agent, кастомные бизнес-заголовки.
• REST и не только: Работал также с GraphQL (где есть лишь POST запросы, но со сложной структурой тела) и gRPC.

Пример автоматизированного теста (Python, pytest + requests):

import pytest
import requests

BASE_URL = "https://api.example.com/v1"

def test_get_user_happy_path():
    """Тест успешного получения пользователя по ID."""
    user_id = 123
    response = requests.get(f"{BASE_URL}/users/{user_id}")

    assert response.status_code == 200
    assert response.headers["Content-Type"] == "application/json"

    user_data = response.json()
    assert user_data["id"] == user_id
    assert "name" in user_data
    assert "email" in user_data

def test_create_user_with_invalid_data():
    """Тест создания пользователя с невалидными данными."""
    payload = {"email": "not-an-email"}  # Некорректный email, нет имени
    headers = {"Content-Type": "application/json"}

    response = requests.post(f"{BASE_URL}/users", json=payload, headers=headers)

    assert response.status_code == 400
    error_body = response.json()
    assert "errors" in error_body
    assert any("email" in err.lower() for err in error_body["errors"])

@pytest.mark.parametrize("method", ["PUT", "PATCH"])
def test_update_user_authorization_required(method):
    """Параметризованный тест: проверка, что обновление требует авторизации."""
    url = f"{BASE_URL}/users/123"
    payload = {"name": "New Name"}

    # Запрос БЕЗ токена
    if method == "PUT":
        response = requests.put(url, json=payload)
    else:
        response = requests.patch(url, json=payload)

    assert response.status_code == 401  # Unauthorized

На практике я использую не только requests, но и клиенты из RestAssured (Java), Supertest (Node.js), а также мощные возможности Postman и Charles Proxy для инспекции и мокирования запросов. Ключевое — понимать, какой запрос отправляет клиентское приложение, и уметь воспроизвести и автоматизировать эту логику в тестах, проверяя как позитивные сценарии, так и граничные случаи и ошибки.