Что получаешь в ответе сервера

Структура и содержимое HTTP-ответа сервера

Когда сервер обрабатывает HTTP-запрос (например, от браузера или API-клиента), он формирует HTTP-ответ, состоящий из трёх основных частей: статусная строка, заголовки и тело ответа. С точки зрения QA Engineer, анализ каждой части критически важен для валидации корректности работы приложения, API и выявления дефектов.

1. Статусная строка (Status Line)

Первая строка ответа содержит информацию о результате обработки запроса.

• Версия протокола (например, HTTP/1.1 или HTTP/2).
• Код состояния (Status Code): Трёхзначный числовой код, который является первым и ключевым элементом проверки в тестировании API.

    *   `1xx` (Информационные): например, `102 Processing`.
    *   `2xx` (Успех): например, `200 OK` (успешный GET), `201 Created` (успешный POST, создан ресурс), `204 No Content` (успешно, но тело ответа пустое).
    *   `3xx` (Перенаправление): например, `301 Moved Permanently`, `302 Found`.
    *   `4xx` (Ошибка клиента): например, `400 Bad Request` (невалидный запрос), `401 Unauthorized`, `403 Forbidden`, `404 Not Found`, `429 Too Many Requests`.
    *   `5xx` (Ошибка сервера): например, `500 Internal Server Error`, `502 Bad Gateway`, `503 Service Unavailable`.

• Текстовая расшифровка кода (Reason Phrase): например, OK, Not Found. Имеет вспомогательное значение.

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

Набор пар ключ: значение, которые описывают ответ и сервер. Для QA критически важны:

• Content-Type: Определяет MIME-тип тела ответа. Позволяет понять, с какими данными работать.

  Content-Type: application/json; charset=utf-8
  Content-Type: text/html; charset=UTF-8
  Content-Type: image/png
  

• Content-Length: Размер тела ответа в байтах.
• Cache-Control, ETag, Last-Modified: Заголовки, управляющие кэшированием. Их проверка важна для тестов производительности и консистентности данных.
• Set-Cookie: Инструкция клиенту установить куки. Проверяется в тестах аутентификации и сессий.
• Заголовки безопасности: CORS-заголовки (Access-Control-Allow-Origin), HSTS (Strict-Transport-Security) и др. — объект тестирования безопасности.
• Специфичные заголовки API: часто X-Request-ID (для трассировки), X-RateLimit-Limit (ограничения запросов).

3. Тело ответа (Response Body)

Основные данные, запрошенные клиентом. Его наличие, формат и содержимое — главный объект валидации в тестировании.

• Структурированные данные (API):

    *   **JSON** — самый распространённый формат для REST API. Проверяем структуру, типы данных, значения, вложенность.

```json
{
  "status": "success",
  "data": {
    "id": 12345,
    "name": "Test Item",
    "price": 99.99
  }
}
```

    *   **XML** — встречается в SOAP API и некоторых legacy-системах.

```xml
<response>
    <status>success</status>
    <item id="12345">
        <name>Test Item</name>
        <price>99.99</price>
    </item>
</response>
```

• Веб-страницы (HTML): Получаем при тестировании веб-интерфейсов. Проверяем наличие ключевых элементов, контент, корректность рендеринга.
• Файлы: Изображения (image/png), документы (application/pdf), бинарные данные. Проверяем целостность, размер, содержимое.
• Пустое тело: Ожидаем при кодах 204 No Content или 304 Not Modified.

Практика QA Engineer при работе с ответом

1. Валидация по спецификации: Сверяем фактический ответ (код, заголовки, схему JSON/XML) с ожидаемым, описанным в документации (OpenAPI/Swagger, WSDL).
2. Тестирование граничных условий и ошибок:

    *   Отправляем невалидные данные → ожидаем `400` с понятным сообщением об ошибке в теле.
    *   Запрашиваем несуществующий ресурс → ожидаем `404`.
    *   Отправляем запрос без токена → ожидаем `401`.

1. Проверка производительности: Анализируем заголовки Cache-Control, замеряем время ответа и размер тела.
2. Использование инструментов:

    *   **Инструменты разработчика в браузере (DevTools)** — вкладка **Network**.
    *   **Специализированные клиенты**: **Postman**, **Insomnia** (для ручного тестирования API).
    *   **Автоматизация**: Скрипты на **Python** (с библиотеками `requests`, `pytest`), **JavaScript** (`axios`, `jest`), где мы программно проверяем ответ.

```python
import requests
import pytest

def test_get_user_success():
    response = requests.get('https://api.example.com/users/1')
    # Проверяем статус-код
    assert response.status_code == 200
    # Проверяем заголовок
    assert response.headers['Content-Type'] == 'application/json'
    # Парсим и проверяем тело ответа
    json_data = response.json()
    assert json_data['user']['id'] == 1
    assert json_data['user']['name'] is not None
    # Проверяем время ответа (перформанс-критерий)
    assert response.elapsed.total_seconds() < 1.0
```

5. Тестирование безопасности: Проверяем отсутствие в ответах чувствительных данных (пароли, ключи), наличие security-заголовков, корректную обработку CORS.

Вывод для QA: Ответ сервера — это не просто «данные», а контракт, который нужно строго проверять. Анализ всех трёх компонентов (статус, заголовки, тело) позволяет комплексно оценить функциональность, надёжность, производительность и безопасность тестируемого приложения. Умение быстро «читать» и верифицировать ответ — один из ключевых навыков современного инженера по обеспечению качества.