Тестирование REST API без интерфейса

Тестирование REST API для управления пользователями

Предусловия

• API Base URL: https://api.example.com/api
• Аутентификация: Bearer Token (если требуется)
• Текущая дата: 2026-03-23
• Доступные окружения: dev, staging, production

---

1. Как тестировать эти endpoints

Стратегия тестирования REST API

Уровень 1: Функциональное тестирование

• Проверка корректности создания данных (POST)
• Проверка получения данных (GET)
• Проверка формата ответа (JSON схема)
• Проверка кодов статуса HTTP

Уровень 2: Позитивное и негативное тестирование

• Позитивные сценарии: корректные данные, обработка успешна
• Негативные сценарии: пустые поля, невалидные форматы, SQL-инъекции

Уровень 3: Граничные и стресс-тесты

• Очень большие значения параметров
• Очень маленькие значения (0, отрицательные)
• Множественные одновременные запросы

Уровень 4: Безопасность

• SQL-инъекции
• XSS-атаки в параметрах
• Несанкционированный доступ
• Rate limiting

---

2. Инструменты для тестирования

Вариант 1: Postman (рекомендуется для начинающих)

Установка:

• Скачать с https://www.postman.com/downloads/
• Установить на Windows/Mac/Linux

Преимущества:

• Графический интерфейс
• Встроенная история запросов
• Коллекции для организации тестов
• Автоматизация (Collections, Tests)
• Легко делиться конфигурацией

Недостатки:

• Требует GUI (не подходит для CI/CD)
• Требует много памяти

---

Вариант 2: curl (рекомендуется для скриптов)

Установка: встроен в Linux/Mac, для Windows используйте WSL или Git Bash

Преимущества:

• Легко интегрировать в CI/CD
• Работает везде
• Простые скрипты
• Минимум зависимостей

Недостатки:

• Нет GUI
• Требует команды для каждого теста

---

Вариант 3: REST Client (VS Code расширение)

Установка: VS Code → Extensions → "REST Client"

Преимущества:

• Встроено в IDE
• Быстро
• Версионирование в git

Недостатки:

• Требует VS Code

---

Вариант 4: Python requests + pytest (для автоматизации)

Установка:

pip install requests pytest pytest-cov

Преимущества:

• Полная автоматизация
• Легко создавать сложные сценарии
• Отличная интеграция с CI/CD
• Можно писать parametrized тесты

Недостатки:

• Требует знания Python

---

3. Проверки для каждого endpoint

Endpoint 1: POST /api/users (Создание пользователя)

1.1 Позитивный тест: Создание пользователя с корректными данными

Запрос (curl):

curl -X POST https://api.example.com/api/users \\
  -H "Content-Type: application/json" \\
  -H "Authorization: Bearer YOUR_TOKEN" \\
  -d '{
    "name": "John Doe",
    "email": "john@example.com",
    "age": 30,
    "status": "active"
  }'

Запрос (Postman):

Method: POST
URL: https://api.example.com/api/users
Headers: 
  Content-Type: application/json
  Authorization: Bearer YOUR_TOKEN
Body (JSON):
{
  "name": "John Doe",
  "email": "john@example.com",
  "age": 30,
  "status": "active"
}

Проверки результата:

Пример корректного ответа (200):

{
  "id": 1001,
  "name": "John Doe",
  "email": "john@example.com",
  "age": 30,
  "status": "active",
  "created_at": "2026-03-23T14:30:00Z",
  "updated_at": "2026-03-23T14:30:00Z"
}

1.2 Негативный тест: Создание без обязательного поля

Данные:

{
  "name": "Jane Smith",
  "email": "",
  "age": 25
}

Ожидаемый результат:

• Статус: 400 Bad Request
• Response body:

{
  "error": "Validation failed",
  "details": {
    "email": "Email is required and must be valid"
  }
}

1.3 Негативный тест: Дублирование email

Сценарий:

1. Создать пользователя с email = "test@example.com"
2. Попытаться создать еще одного с тем же email

Ожидаемый результат:

• Статус: 409 Conflict
• Response:

{
  "error": "Email already exists",
  "code": "EMAIL_DUPLICATE"
}

1.4 Негативный тест: Невалидный email

Данные:

{
  "name": "Bad Email User",
  "email": "this-is-not-email",
  "age": 25
}

Ожидаемый результат:

• Статус: 400 Bad Request
• Error message: "Invalid email format"

1.5 Граничный тест: Возраст = 0

Данные:

{
  "name": "Baby User",
  "email": "baby@example.com",
  "age": 0
}

Проверка:

• Принимает ли система возраст 0?
• Или требует age >= 18?
• Или требует age >= 0?

1.6 Граничный тест: Очень длинное имя

Данные:

{
  "name": "A" * 1000,
  "email": "long@example.com",
  "age": 25
}

Проверка:

• Принимает ли система? (валидация длины)
• Обрезает ли?
• Возвращает ошибку?

1.7 Тест безопасности: SQL-инъекция в имени

Данные:

{
  "name": "'; DROP TABLE users; --",
  "email": "injection@example.com",
  "age": 25
}

Проверка:

• Таблица users все еще существует?
• Данные безопасно экранированы?

1.8 Тест безопасности: XSS в имени

Данные:

{
  "name": "<script>alert('XSS')</script>",
  "email": "xss@example.com",
  "age": 25
}

Проверка:

• Скрипт не выполняется при получении через GET
• Имя экранировано при отображении

---

Endpoint 2: GET /api/users/{id} (Получение одного пользователя)

2.1 Позитивный тест: Получение существующего пользователя

Запрос:

curl -X GET https://api.example.com/api/users/1001 \\
  -H "Authorization: Bearer YOUR_TOKEN"

Проверки:

2.2 Негативный тест: Несуществующий пользователь

Запрос:

curl -X GET https://api.example.com/api/users/99999

Ожидаемый результат:

• Статус: 404 Not Found
• Response:

{
  "error": "User not found",
  "id": 99999
}

2.3 Граничный тест: ID = 0

Запрос:

curl -X GET https://api.example.com/api/users/0

Проверка:

• 404 (user not found) ИЛИ
• 400 (invalid ID)

2.4 Граничный тест: Очень большой ID

Запрос:

curl -X GET https://api.example.com/api/users/999999999999

Проверка:

• 404 (логично)
• Нет overflow ошибок

2.5 Граничный тест: Буквы в ID

Запрос:

curl -X GET https://api.example.com/api/users/abc123

Ожидаемый результат:

• Статус: 400 Bad Request
• Error: "Invalid user ID format"

2.6 Безопасность: Несанкционированный доступ

Сценарий:

1. Создать пользователя A с токеном A
2. Попытаться получить его данные с токеном B (другого пользователя)

Проверка:

• Должно быть 403 Forbidden ИЛИ
• Скрыты чувствительные данные (в зависимости от требований)

2.7 Безопасность: Без токена

Запрос:

curl -X GET https://api.example.com/api/users/1001

Ожидаемый результат:

• Статус: 401 Unauthorized
• Error: "Missing authorization token"

---

Endpoint 3: GET /api/users (Список всех пользователей)

3.1 Позитивный тест: Получить список пользователей

Запрос:

curl -X GET https://api.example.com/api/users \\
  -H "Authorization: Bearer YOUR_TOKEN"

Проверки:

Пример ответа:

{
  "data": [
    {"id": 1001, "name": "John Doe", "email": "john@example.com"},
    {"id": 1002, "name": "Jane Smith", "email": "jane@example.com"}
  ],
  "total": 2,
  "page": 1,
  "per_page": 20
}

3.2 Позитивный тест: Пагинация

Запрос:

curl -X GET 'https://api.example.com/api/users?page=1&per_page=10'

Проверки:

• Первая страница содержит до 10 пользователей
• Присутствуют поля: page, per_page, total
• Возможность перейти на следующую страницу

3.3 Негативный тест: Несуществующая страница

Запрос:

curl -X GET 'https://api.example.com/api/users?page=9999'

Проверка:

• 200 OK + пустой массив ИЛИ
• 404 Not Found

3.4 Граничный тест: per_page = 0

Запрос:

curl -X GET 'https://api.example.com/api/users?per_page=0'

Проверка:

• 400 Bad Request ИЛИ
• Использует default значение (20)

3.5 Граничный тест: per_page = 10000

Запрос:

curl -X GET 'https://api.example.com/api/users?per_page=10000'

Проверка:

• Лимит на максимум (обычно 100-1000)
• Не падает сервер
• Время ответа приемлемо

3.6 Позитивный тест: Сортировка

Запрос:

curl -X GET 'https://api.example.com/api/users?sort=name&order=asc'

Проверка:

• Пользователи отсортированы по имени (A-Z)
• Или по другому полю (email, created_at)

3.7 Позитивный тест: Фильтрация

Запрос:

curl -X GET 'https://api.example.com/api/users?status=active'

Проверка:

• Только active пользователи в ответе
• Поля для фильтрации (status, age_min, age_max)

---

4. Как проверить корректность сохранения в базе

Метод 1: Прямой доступ к БД (если есть)

SQL запрос:

SELECT * FROM users WHERE id = 1001;

Проверка:

• Пользователь существует
• Все данные совпадают с ответом API
• Timestamps корректные

Метод 2: Через GET endpoint

Сценарий:

1. POST /api/users (создать пользователя) → получить id = 1001
2. GET /api/users/1001 (получить) → проверить данные
3. GET /api/users (список) → найти в списке

Проверки:

• Данные совпадают
• ID присутствует
• Все поля заполнены

Метод 3: Через логи (если доступны)

Команда:

docker logs api-container | grep "INSERT INTO users"

Проверка:

• Логи содержат INSERT запрос
• Данные совпадают

Метод 4: Проверка email подтверждения

Если email требует подтверждения:

1. Создать пользователя
2. Проверить email (может быть в логах, тестовом почтовом сервисе)
3. Открыть ссылку подтверждения
4. Проверить статус: email_verified = true

Метод 5: API-тест цепочка

# 1. Создать пользователя
RESPONSE=$(curl -X POST https://api.example.com/api/users \\
  -H "Content-Type: application/json" \\
  -d '{"name": "Test", "email": "test@example.com", "age": 30}')

USER_ID=$(echo $RESPONSE | jq '.id')

# 2. Получить пользователя
curl -X GET https://api.example.com/api/users/$USER_ID

# 3. Проверить в списке
curl -X GET https://api.example.com/api/users | jq '.data[] | select(.id == '$USER_ID')

---

Автоматизированное тестирование на Python

import requests
import pytest

BASE_URL = "https://api.example.com/api"
TOKEN = "YOUR_TOKEN"
HEADERS = {"Authorization": f"Bearer {TOKEN}"}

class TestUsersAPI:
    def test_create_user_success(self):
        payload = {
            "name": "John Doe",
            "email": "john@example.com",
            "age": 30
        }
        response = requests.post(f"{BASE_URL}/users", json=payload, headers=HEADERS)
        
        assert response.status_code == 201
        assert response.json()["email"] == "john@example.com"
        assert "id" in response.json()
        
    def test_get_user_success(self):
        response = requests.get(f"{BASE_URL}/users/1001", headers=HEADERS)
        
        assert response.status_code == 200
        assert response.json()["id"] == 1001
        
    def test_list_users_success(self):
        response = requests.get(f"{BASE_URL}/users", headers=HEADERS)
        
        assert response.status_code == 200
        assert isinstance(response.json()["data"], list)

---

Итоговый чек-лист

• Все endpoints доступны (не 404)
• Статус коды корректны (201 для создания, 200 для получения, 400 для ошибок)
• Response body содержит правильный JSON
• Данные корректно сохраняются в БД
• Валидация работает (отклоняет плохие данные)
• Безопасность: пароли не видны в API ответах
• Безопасность: SQL-инъекции предотвращены
• Безопасность: Авторизация работает
• Пагинация работает
• Граничные случаи обработаны корректно
• Логирование присутствует (для отладки)