Что нужно проверять обязательно, когда тестируешь эндпоинты?

Обязательные аспекты тестирования REST API эндпоинтов

Тестирование эндпоинтов (API-тестирование) — критическая часть обеспечения качества бэкенд-сервисов. Я, как senior QA Automation Engineer, разделяю проверки на несколько ключевых категорий, которые необходимо покрывать как минимум.

1. Функциональное тестирование (правильность логики)

Это основа. Мы проверяем, что эндпоинт выполняет свою бизнес-логику согласно спецификации (OpenAPI/Swagger, RAML).

• Валидные запросы (Happy Path):

    *   **Все методы HTTP** (GET, POST, PUT, PATCH, DELETE) для данного пути.
    *   Корректная обработка **обязательных и опциональных полей**.
    *   Возврат ожидаемых **HTTP статус-кодов** (200 OK, 201 Created).
    *   **Структура и данные** в ответе соответствуют контракту.

```python
# Пример теста на happy path для GET /api/users/{id}
def test_get_user_by_id_success(api_client, created_user):
    response = api_client.get(f"/api/users/{created_user['id']}")
    assert response.status_code == 200
    assert response.json()["id"] == created_user["id"]
    assert response.json()["name"] == created_user["name"]
    # Проверка схемы ответа
    validate(instance=response.json(), schema=USER_SCHEMA)
```

• Негативные сценарии (Unhappy Path):

    *   Обработка **несуществующих ресурсов** (404 Not Found).
    *   Запросы с **невалидным ID** (строка вместо числа в path) → 400 Bad Request.
    *   Отсутствие **обязательных полей** в теле запроса → 422 Unprocessable Entity или 400.
    *   **Неверные типы данных** (число вместо строки) → 400.
    *   **Нарушение уникальности** (например, попытка создать дубль по email) → 409 Conflict.
    *   Проверка граничных значений для полей с ограничениями (минимальная/максимальная длина строки).

2. Тестирование авторизации и аутентификации (Security)

Частая причина уязвимостей. Проверяем контроль доступа.

• Эндпоинты, требующие токена/ключа:

    *   Запрос **без токена** → 401 Unauthorized.
    *   Запрос с **просроченным/невалидным токеном** → 401.
    *   Запрос с токеном, у которого **нет необходимых прав (scope)** → 403 Forbidden.

• Проверка RBAC/ABAC: Разные роли пользователей получают разный доступ к одним и тем же эндпоинтам. Например, GET /api/invoices для юзера возвращает только его счета, а для админа — все.

3. Валидация входных данных (Input Validation)

Защита от некорректных и вредоносных данных. Проверяем все точки входа: path parameters, query parameters, request body, headers.

• SQL/NoSQL-инъекции: Попытка передать в строковые параметры части SQL-запросов.
• XSS-векторы: Передача скриптов в поля, которые могут отображаться в UI.
• Поля файловой системы (Path Traversal): Попытка получить доступ к файлам через параметры (например, ../../../etc/passwd).
• Очень большие payloads (например, JSON в 10МБ+) → 413 Payload Too Large.
• Некорректные Content-Type headers.

4. Тестирование состояния и побочных эффектов

API часто меняет состояние системы. Это нужно проверять.

• Для методов, изменяющих данные (POST, PUT, DELETE):

    *   После `POST` — объект действительно создается в БД, и его можно получить через `GET`.
    *   После `PUT/PATCH` — изменения корректно сохраняются.
    *   После `DELETE` — объект удаляется из БД и последующий `GET` возвращает 404.

• Проверка связанных сущностей: Создание заказа (POST /orders) должно корректно влиять на баланс пользователя и инвентарь товаров.

5. Тестирование производительности и стабильности

Критично для публичных API.

• Базовые нагрузочные тесты: Проверка Response Time (должен укладываться в SLA, например, < 200 мс для p95). Я использую Locust или k6.
• Проверка на утечки памяти при длительной работе.
• Обработка высоких нагрузок: Эндпоинт должен возвращать 429 Too Many Requests при превышении лимитов (rate limiting), а не падать с 500 ошибкой.

6. Тестирование в разных условиях и конфигурациях

• Неверный HTTP-метод для эндпоинта → 405 Method Not Allowed.
• Работа с разными Accept-Headers (application/json, application/xml) — если API поддерживает несколько форматов.
• Пагинация, сортировка, фильтрация (query-параметры ?limit=10&offset=20&sort=-date).
• Заголовки кэширования для GET-запросов (если применимо).

7. Интеграционное тестирование зависимостей

Эндпоинты редко живут в вакууме.

• Поведение при недоступности внешних сервисов (базы данных, очереди сообщений, микросервисы-партнеры). Должны быть понятные ошибки (5xx или специальные 424, 503), но не полная неработоспособность сервиса.
• Тестирование таймаутов при обращении к зависимостям.

Автоматизация и инструменты

Для комплексного покрытия я комбинирую:

• Pytest + Requests (или Pytest + AioHTTP для асинхронных API) — для функциональных и негативных тестов.
• Schemathesis — для property-based тестирования на основе OpenAPI-схемы, отлично находит угловые кейсы.
• Locust/k6 — для нагрузочного тестирования.
• OWASP ZAP/Burp Suite — для автоматизированного сканирования уязвимостей безопасности в CI/CD pipeline.

Заключение: Обязательная проверка эндпоинтов — это многослойный процесс, выходящий далеко за рамки "получить 200 OK". Фокус должен быть на корректности бизнес-логики, безопасности, надежности при некорректных данных и стабильности под нагрузкой. Покрытие этих аспектов автоматизированными тестами в CI/CD — заказ качества backend-сервиса.