Как узнавал успешный запрос

Понимание успешности HTTP-запроса в тестировании

При тестировании веб-приложений и API определение успешности запроса — фундаментальный навык QA Engineer. Я подхожу к этому комплексно, анализируя несколько ключевых аспектов.

1. Код состояния HTTP (Status Code)

Первичный и самый очевидный индикатор. Я ожидаю код 2xx для успешных операций:

• 200 OK — стандартный ответ для успешных GET, PUT, PATCH запросов.
• 201 Created — успешное создание ресурса (обычно для POST).
• 204 No Content — успешная обработка, но тело ответа отсутствует (удаление, обновление).

Пример проверки в автотесте (Python, pytest + requests):

import requests

def test_user_creation_success():
    url = "https://api.example.com/users"
    payload = {"name": "John", "email": "john@example.com"}
    response = requests.post(url, json=payload)

    # Проверяем статус-код
    assert response.status_code == 201, f"Expected 201, got {response.status_code}"
    # Дополнительная проверка на наличие данных в ответе
    assert response.json().get("id") is not None

2. Структура и содержимое тела ответа (Response Body)

Успешный код статуса не всегда гарантирует смысловую корректность. Я обязательно проверяю:

• Соответствие формату (JSON, XML) и схеме (JSON Schema).
• Наличие ожидаемых полей и корректность их значений.
• Отсутствие ошибок в бизнес-логике внутри ответа (например, "status": "error" при 200 OK).
• Целостность данных — созданные или полученные данные должны соответствовать отправленным.

Пример проверки JSON Schema:

from jsonschema import validate

schema = {
    "type": "object",
    "properties": {
        "id": {"type": "number"},
        "name": {"type": "string"},
        "email": {"type": "string", "format": "email"}
    },
    "required": ["id", "name", "email"]
}

def test_response_schema(response):
    validate(instance=response.json(), schema=schema)

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

Определённые заголовки подтверждают успех операции:

• Content-Type — соответствует ли заявленному формату (application/json).
• Location — для 201 Created часто содержит URL созданного ресурса.
• Cache-Control, ETag — могут указывать на корректную кэшируемость ресурса.

4. Состояние системы после запроса (Side Effects)

Это критически важный этап интеграционного и end-to-end тестирования. Успешный POST-запрос на создание заказа должен:

• Записать корректные данные в БД.
• Изменить связанные сущности (например, баланс счёта).
• Отправить уведомление (email, событие в брокер сообщений).
• Обновить UI, если тестируется фронтенд.

Пример интеграционной проверки (псевдокод):

def test_order_creation_persists_to_db():
    # 1. Отправляем API-запрос
    order_data = {"item": "book", "quantity": 2}
    api_response = create_order(order_data)
    assert api_response.status_code == 201

    # 2. Проверяем прямое состояние в БД
    order_id = api_response.json()["id"]
    db_order = database.query("SELECT * FROM orders WHERE id = ?", order_id)
    assert db_order is not None
    assert db_order.item == "book"
    assert db_order.quantity == 2

    # 3. Проверяем связанную бизнес-логику
    assert inventory_service.get_stock("book") == initial_stock - 2

5. Поведение клиентского приложения (для Frontend/UI тестирования)

Успешный запрос на UI-уровне проявляется как:

• Корректное отображение полученных данных.
• Отсутствие сообщений об ошибках.
• Изменение состояния интерфейса (например, переход на новую страницу, обновление списка).
• Плавная работа без "подвисаний".

Мой рабочий процесс

На практике я комбинирую эти методы, начиная с базовых проверок и двигаясь к сложным:

1. В инструментах ад-hoc тестирования (Postman, Insomnia): визуально проверяю статус, тело и заголовки.
2. При написании автотестов API: автоматизирую проверки статус-кода, схемы ответа и, при необходимости, состояния БД.
3. При интеграционном тестировании: добавляю проверки side-effects и взаимодействия между системами (логи в message queue, вызовы внешних сервисов через моки).
4. В UI-тестировании: сочетаю проверки сетевых запросов через DevTools (вкладка Network) с валидацией изменений на экране.

Важный нюанс: "Успешность" всегда определяется требованиями. Например, запрос на удаление несуществующего ресурса может считаться успешным (возвращать 204 или 404), в зависимости от бизнес-логики и согласованности с командой разработки. Поэтому я всегда сверяюсь со спецификацией API (OpenAPI/Swagger) и пользовательскими сценариями.