Как проверить корректность ответа

Стратегия проверки корректности ответа (валидация)

Корректность ответа — это соответствие фактического результата (response) ожидаемому поведению системы согласно требованиям. Проверка корректности не сводится к одной операции, это комплексный процесс, который я, как QA Engineer, выстраиваю на нескольких уровнях.

1. Фундамент: Определение эталонов корректности

Прежде чем проверять, нужно четко знать, что проверять. Источники истины (oracles):

• Требования и спецификации: Функциональные (FR) и нефункциональные (NFR) требования.
• Документация API: OpenAPI (Swagger), схемы данных (JSON Schema, XSD).
• Дизайн-макеты и гайдлайны: Для UI-проверок.
• Бизнес-логика и соглашения: Часто недокументированные, но критичные правила.
• Согласованные с командой критерии приемки (Acceptance Criteria).

2. Многоуровневая валидация ответа

Я применяю подход от общего к частному, проверяя ответ по слоям.

Слой 1: Базовые HTTP-характеристики и инфраструктура (Sanity Check)

Это первичный фильтр, который выполняется для любого ответа, особенно в API-тестировании.

# Пример корректного ответа
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 125
Connection: keep-alive

• Статус-код: Соответствует ли операции? (200 для успеха, 201 для создания, 404 для отсутствующего ресурса, 400 для ошибки клиента).
• Заголовки (Headers): Наличие и корректность Content-Type, Cache-Control, CORS-заголовков.
• Время ответа: Укладывается ли в допустимые лимиты (проверка на перфоманс-деградацию).

Слой 2: Структура данных (Schema Validation)

Убеждаюсь, что тело ответа имеет ожидаемую структуру. Это защищает от падения клиентских приложений.

// Использование библиотеки для валидации JSON Schema (например, Ajv)
const Ajv = require("ajv");
const ajv = new Ajv();

const schema = {
  type: "object",
  properties: {
    id: { type: "integer" },
    name: { type: "string" },
    email: { type: "string", format: "email" },
    roles: { type: "array", items: { type: "string" } }
  },
  required: ["id", "name", "email"],
  additionalProperties: false // Запрет лишних полей
};

const validate = ajv.compile(schema);
const data = response.body; // Полученный ответ
const valid = validate(data);

if (!valid) {
  console.log("Ошибки структуры:", validate.errors);
}

Слой 3: Семантика и бизнес-логика (Business Logic Validation)

Самая важная часть. Структура может быть верной, но данные — нет.

• Корректность значений: Соответствие допустимым диапазонам, форматам (дата, email, телефон).
• Целостность данных: Связи между сущностями. Если запрашивался заказ order_id=5, все товары в ответе должны относиться к нему.
• Консистентность состояния: После операции POST /cart/items последующий GET /cart должен вернуть обновленную корзину.
• Вычисления: Проверка итоговых сумм, скидок, налогов.

# Пример проверки бизнес-логики в UI-тесте (Python + pytest)
def test_order_total(self, api_client, ui_driver):
    # 1. Получаем данные через API (источник истины)
    order_api = api_client.get_order(123)
    expected_total = order_api["total_with_tax"]

    # 2. Проверяем отображение в UI
    ui_driver.open_order_page(123)
    displayed_total = ui_driver.get_element_text(".order-total")

    # 3. Сравниваем с допуском (например, для валют)
    assert float(displayed_total) == pytest.approx(expected_total, abs=0.01)

Слой 4: Граничные условия и негативные сценарии

Корректность — это также правильная реакция на некорректные данные.

• Обработка ошибок: При невалидном входе (POST с email=без-собаки) статус должен быть 400 или 422, а в теле — читаемое описание ошибки.
• Пограничные значения: Максимальная длина строки, минимальное/максимальное число.
• Отсутствие данных: GET /users/9999999 должен возвращать 404, а не 200 с пустым телом.

3. Инструменты и автоматизация

Ручная проверка всех слоев неэффективна. Я автоматизирую валидацию:

• В API-тестах (REST Assured, Supertest, pytest-requests): Использую цепочки ассертов (assertThat) для статуса, заголовков, схемы JSON (json-schema), времени ответа и конкретных значений в теле.
• В UI-тестах (Selenium, Cypress, Playwright): Проверяю отображение данных, их соответствие данным бэкенда (через перехват сетевых запросов — mocking или direct API call).
• Контрактное тестирование (Pact, Spring Cloud Contract): Для проверки совместимости между сервисами (consumer-provider).

4. Принципы эффективной проверки

• Использование эталонных данных: Сравнение не с "захардкоженными" значениями, а с данными, полученными из доверенного источника (база данных, другой API).
• Изоляция тестов: Ответ должен зависеть только от действий в рамках теста, а не от состояния системы, оставшегося от предыдущих запусков.
• Читаемость ассертов: Четкие сообщения об ошибках, которые сразу указывают на расхождение: "Expected user role 'admin', but got 'user'".
• Проверка в контексте: Для одного и того же эндпоинта /api/products корректность ответа для администратора (все поля) и гостя (только публичные поля) — разная.

Итог: Проверка корректности — это не просто assert response.status_code == 200. Это многоуровневый процесс валидации, начинающийся с четких требований и заканчивающийся автоматизированной проверкой структуры, семантики, бизнес-логики и граничных случаев. Ключевая цель — убедиться, что система не только работает, но и работает правильно с точки зрения пользователя и бизнеса.