REST API тестування: повний гайд для QA

API тестування — один з найважливіших скілів сучасного QA інженера. Більшість веб і мобільних застосунків комунікують через API. Навчившись тестувати API — ви відкриєте можливості, які недоступні в UI тестуванні.

Що таке REST API: максимально просто

API (Application Programming Interface) — спосіб спілкування між програмами.

REST API — архітектурний стиль для API. Уявіть ресторан: є меню (документація), офіціант (API), кухня (сервер). Ви робите замовлення (запит) — отримуєте страву (відповідь).

В REST кожен ресурс має URL, а дії над ним виконуються через HTTP методи.

HTTP методи: що і навіщо

Ресурс: /api/users

GET    /api/users          → отримати список всіх users
GET    /api/users/123      → отримати user з ID 123
POST   /api/users          → створити нового user
PUT    /api/users/123      → повністю оновити user 123
PATCH  /api/users/123      → частково оновити user 123
DELETE /api/users/123      → видалити user 123

Структура HTTP запиту і відповіді

Запит

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1...
 
{
  "name": "Олена Коваль",
  "email": "olena@example.com",
  "role": "editor"
}

Метод — що робимо (GET, POST, etc.) URL — з яким ресурсом Headers — метадані запиту (тип контенту, авторизація) Body — дані які надсилаємо (для POST, PUT, PATCH)

Відповідь

HTTP/1.1 201 Created
Content-Type: application/json
 
{
  "id": 456,
  "name": "Олена Коваль",
  "email": "olena@example.com",
  "role": "editor",
  "created_at": "2026-06-10T14:23:45Z"
}

Status code — результат операції Headers — метадані відповіді Body — дані у відповіді

Ключові статус-коди

Що тестувати в API: чеклист

1. Функціональне тестування

✅ Позитивні сценарії (happy path):
- Запит з валідними даними → очікуваний статус-код
- Response body відповідає специфікації (поля, типи даних)
- Дані коректно зберігаються/оновлюються/видаляються

✅ Негативні сценарії:
- Запит без авторизації → 401
- Запит з недостатніми правами → 403
- Запит до неіснуючого ресурсу → 404
- Запит з порожнім обов'язковим полем → 400/422
- Запит з невалідним форматом даних → 400/422

2. Тестування авторизації

- Запит без токена
- Запит зі старим (expired) токеном
- Запит з невалідним токеном
- Запит з токеном іншого user

3. Тестування валідації даних

- Рядки: порожній, пробіли, max довжина+1, SQL injection символи
- Числа: від'ємні, нуль, дробові якщо ціле очікується
- Email: без @, без домену, з пробілами
- Дати: минуле, майбутнє, неіснуюча дата (30 лютого)
- ID: неіснуючий, рядок замість числа

4. Тестування response body

- Всі очікувані поля присутні
- Типи даних правильні (string/number/boolean/array)
- Немає зайвих чутливих полів (паролі, внутрішні ID)
- Формат дат відповідає специфікації (ISO 8601)
- Пагінація працює коректно

Практика в Postman: покроковий приклад

Крок 1: Створення колекції

Відкрийте Postman → New Collection → "QA Roadmap API Tests"

Крок 2: Налаштування змінних середовища

Environment: Staging
Variables:
  base_url: https://api.staging.example.com
  token: (поки порожнє, заповнимо після логіну)

Крок 3: Запит логіну з автоматичним збереженням токена

// POST {{base_url}}/auth/login
// Body:
{
  "email": "test@example.com",
  "password": "testpass123"
}
 
// Tests (Postman script):
const response = pm.response.json();
 
pm.test("Status 200", () => pm.response.to.have.status(200));
pm.test("Has access token", () => pm.expect(response.access_token).to.be.a('string'));
 
// Зберігаємо токен для наступних запитів
pm.environment.set("token", response.access_token);

Крок 4: Запит зі збереженим токеном

// GET {{base_url}}/api/users/me
// Headers: Authorization: Bearer {{token}}
 
// Tests:
const user = pm.response.json();
 
pm.test("Status 200", () => pm.response.to.have.status(200));
pm.test("Has ID", () => pm.expect(user.id).to.be.a('number'));
pm.test("Has email", () => pm.expect(user.email).to.be.a('string'));
pm.test("No password field", () => pm.expect(user.password).to.be.undefined);
pm.test("Response time < 500ms", () => pm.expect(pm.response.responseTime).to.be.below(500));

Крок 5: Тест негативного сценарію

// GET {{base_url}}/api/users/99999 (неіснуючий ID)
// Headers: Authorization: Bearer {{token}}
 
// Tests:
pm.test("Status 404", () => pm.response.to.have.status(404));
pm.test("Error message present", () => {
  const response = pm.response.json();
  pm.expect(response.message).to.be.a('string');
});

Читання API документації (Swagger)

Більшість сучасних API мають Swagger (OpenAPI) документацію. Зазвичай доступна за /swagger або /api/docs.

Що знайдете в Swagger:

• Всі доступні ендпоінти
• Методи і параметри
• Схеми request/response body
• Які поля обов'язкові
• Типи даних

Порада: Swagger — ваша специфікація для тест-кейсів. Кожен ендпоінт = мінімум happy path + кілька негативних сценаріїв.

Тестування пагінації

Пагінація часто приховує баги:

# Базовий запит
GET /api/users?page=1&per_page=10
 
# Що перевіряти:
# 1. Кількість об'єктів у відповіді = per_page (або менше на останній сторінці)
# 2. page=1 і page=2 повертають різні дані
# 3. Загальна кількість сторінок коректна: ceil(total / per_page)
# 4. Остання сторінка: об'єктів <= per_page
# 5. page=999 (після останньої): порожній масив або 404, не 500

Тестування сортування і фільтрації

GET /api/users?sort=created_at&order=desc
 
# Перевірки:
# created_at першого елемента >= created_at другого
# sort=invalid_field → 400, а не 500

GET /api/products?category=electronics&min_price=100&max_price=500
 
# Перевірки:
# Всі повернуті продукти мають category=electronics
# Ціна кожного: 100 <= price <= 500
# min_price > max_price → 400 з описом помилки

Приклад повного тест-плану для одного ендпоінту

Ендпоінт: POST /api/orders

Позитивні:
TC01: Створення замовлення з валідними даними → 201, повертає ID
TC02: Замовлення зберігається в БД (GET /orders/{id} повертає ті ж дані)

Авторизація:
TC03: Без токена → 401
TC04: З expired токеном → 401
TC05: З токеном user без ролі → 403 (якщо є роль)

Валідація:
TC06: Порожній масив products → 422 + повідомлення
TC07: product_id = неіснуючий ID → 422 + повідомлення
TC08: quantity = -1 → 422 + повідомлення
TC09: quantity = 0 → 422 + повідомлення
TC10: Дуже велика кількість товарів → обробляється без 500

Edge cases:
TC11: Дублікат замовлення (повторний запит) → 409 або ідемпотентна відповідь
TC12: Одночасні замовлення від одного user → коректна обробка

Підсумок

API тестування — не складно якщо є структура. Основа: розуміти HTTP, вміти читати документацію і систематично перевіряти happy path + негативні сценарії + edge cases.

Починайте з реального API: знайдіть публічне API (GitHub API, JSONPlaceholder, PetStore) і попрактикуйтесь. 2-3 години практики в Postman дадуть більше ніж тиждень читання теорії.