Как использовал выборку в GET

Использование выборки в GET-запросах

Как QA Engineer, я использовал функционал выборки в GET-запросах для тестирования RESTful API, особенно в контексте GraphQL и REST API с поддержкой параметров типа fields, expand или select. Этот механизм позволяет клиенту запросить у сервера не всю сущность, а только определенные поля, что критически важно для оптимизации производительности и уменьшения трафика.

Ключевые сценарии использования в тестировании

1. Проверка возвращаемой структуры данных: Убедиться, что при указании списка полей API возвращает только их, без лишней информации.

   GET /api/v1/users/123?fields=id,name,email
   

    **Ожидаемый ответ:**

```json
{
  "id": 123,
  "name": "Иван Иванов",
  "email": "ivan@example.com"
}
```

    **Неожиданный ответ (провальный тест):**

```json
{
  "id": 123,
  "name": "Иван Иванов",
  "email": "ivan@example.com",
  "passwordHash": "a1b2c3d4", // Лишнее, конфиденциальное поле!
  "createdAt": "2023-01-01"
}
```

2. Тестирование вложенных объектов (expand): Проверить работу параметров расширения для включения связанных сущностей. http GET /api/v1/orders/456?fields=id,total&expand=customer(address),items(product(name))

    Здесь мы проверяем, что в ответе появятся не только `id` и `total` заказа, но и объект `customer` с его `address`, а также массив `items`, каждый из которых содержит объект `product` только с полем `name`.

1. Валидация обработки ошибок:

    *   **Некорректные имена полей**: `GET /api/v1/users?fields=id,invalidFieldName`. Ожидается `400 Bad Request` с понятным сообщением.
    *   **SQL/NoSQL-инъекции**: Попытка внедрения через параметр выбора полей. `GET /api/v1/users?fields=id,name;DROP TABLE users--`. Система должна корректно санитизировать входные данные.
    *   **Избыточная вложенность**: Запрос с чрезмерной глубиной `expand`. Должна сработать защита от циклических зависимостей или слишком тяжелых запросов.

1. Проверка производительности (нагрузочное тестирование):

    Сравнение времени ответа и размера payload при запросе всех полей и при запросе 2-3 необходимых полей.

```bash
# Запрос всех данных (тяжелый)
time curl -X GET https://api.example.com/products
# Запрос только ID и названия (легкий)
time curl -X GET "https://api.example.com/products?fields=id,title"
```

    Разница должна быть значительной, особенно на больших объемах данных.

Пример тест-кейса для параметра fields

Заголовок: Проверка корректности работы параметра fields в эндпоинте GET /api/v1/products.

Предусловия:

1. В системе существует продукт с ID=789.

Шаги и ожидаемые результаты:

Особый случай: GraphQL

В GraphQL выборка полей является фундаментальной частью языка запросов. Тестирование здесь фокусируется на:

• Корректности ответа на сложные вложенные запросы.
• Проверке директив (@include, @skip).
• Анализе времени выполнения запросов (performance testing) с разной глубиной выборки.

# Пример запроса для тестирования
query GetProductForCatalog($id: ID!) {
  product(id: $id) {
    id
    name
    price
    reviews(limit: 2) { # Выборка с ограничением внутри вложенного поля
      text
      author {
        name
      }
    }
  }
}

Вывод для QA

Тестирование выборки в GET-запросах — это не только проверка «счастливого пути», но и глубокая валидация:

• Безопасности (инъекции, доступ к запрещенным полям).
• Стабильности (обработка некорректных данных, нагрузка).
• Согласованности с контрактом API (OpenAPI/Swagger-спецификацией).
• Производительности сети и backend-логики.

Этот функционал напрямую влияет на пользовательский опыт клиентских приложений, поэтому его тестирование должно быть тщательным и многоаспектным.