Основы тестирования API

Что такое API? #

API (Application Programming Interface) — это контракт между двумя программными системами. Он определяет, как одна система может запрашивать данные или действия у другой и в каком формате придёт ответ. Представьте себе официанта в ресторане: вы (клиент) делаете заказ, официант (API) несёт его на кухню (сервер) и приносит вам еду (ответ).

В современной разработке программного обеспечения API повсюду. Когда вы проверяете погоду на телефоне, приложение отправляет API-запрос к метеосервису. Когда вы входите через Google на стороннем сайте, API OAuth обрабатывают аутентификацию. Когда банковское приложение показывает ваш баланс, оно вызывает API бэкенда банка.

API в современной архитектуре #

Большинство современных приложений следуют архитектуре «клиент-сервер», где фронтенд (веб- или мобильное приложение) взаимодействует с бэкендом через API. Такое разделение стало стандартом, поскольку позволяет:

• Множество клиентов использовать один бэкенд (веб, iOS, Android, партнёрские интеграции)
• Независимую разработку — команды фронтенда и бэкенда работают параллельно
• Масштабируемость — каждый слой масштабируется независимо
• Повторное использование — один API обслуживает разные продукты и функции

Типичное e-commerce приложение может иметь десятки API: один для аутентификации пользователей, другой для каталога товаров, один для корзины покупок, другой для платежей и так далее.

Почему тестирование API важно #

Перспектива пирамиды тестирования #

Пирамида тестирования, предложенная Майком Коном, предполагает, что ваш набор тестов должен содержать много unit-тестов в основании, меньше интеграционных/API-тестов в середине и ещё меньше UI-тестов на вершине. API-тесты занимают этот критически важный средний слой, потому что:

1. Выполняются быстрее UI-тестов — нет рендеринга браузера, загрузки страниц, ожидания анимаций
2. Стабильнее UI-тестов — нет нестабильных селекторов элементов или проблем с таймингами
3. Покрывают больше логики — один API может обслуживать несколько экранов UI
4. Ловят баги интеграции — проверяют, как различные сервисы взаимодействуют

Реальное влияние #

Рассмотрим сценарий: ваш e-commerce сайт имеет процесс оформления заказа. UI-тест может занять 30-60 секунд для заполнения форм, кликов по кнопкам и проверки результата. Эквивалентный API-тест — отправка POST-запроса на /api/orders с данными заказа — занимает менее 1 секунды и тестирует ту же бизнес-логику.

В Google (Waze) тестирование API было критически важным, поскольку мобильное приложение зависело от десятков бэкенд-сервисов. Сломанный API мог повлиять на более чем 150 миллионов пользователей. Обнаружение проблем на уровне API до того, как они достигнут UI, экономило огромное количество времени на отладку.

Что покрывает тестирование API #

Тестирование API валидирует несколько аспектов бэкенда:

Основные концепции #

Запрос и ответ (Request и Response) #

Каждое взаимодействие с API следует паттерну запрос-ответ:

Request состоит из:

• URL/Endpoint — куда отправить запрос (например, https://api.example.com/users)
• Method — какое действие выполнить (GET, POST, PUT, DELETE)
• Headers — метаданные: токены аутентификации, тип контента
• Body — данные (для POST/PUT-запросов)

Response состоит из:

• Status code — числовой индикатор успеха или ошибки (200, 404, 500)
• Headers — метаданные: тип контента, информация о rate limit
• Body — собственно возвращаемые данные (обычно JSON или XML)

Request:
GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept: application/json

Response:
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "role": "admin"
}

Типы API #

Хотя этот модуль в основном сфокусирован на REST API (наиболее распространённый тип), вам следует знать общую картину:

• REST — основан на ресурсах, использует HTTP-методы, JSON-ответы (самый распространённый)
• GraphQL — язык запросов, клиент указывает, какие именно данные ему нужны
• gRPC — высокая производительность, использует Protocol Buffers, распространён в микросервисах
• SOAP — основан на XML, строгий контракт, распространён в enterprise/legacy-системах
• WebSocket — двунаправленный, коммуникация в реальном времени

Каждый из этих типов рассматривается в отдельных уроках далее в этом модуле.

Подходы к тестированию API #

Ручное тестирование API #

На начальном этапе ручное тестирование с помощью инструментов вроде Postman или cURL даёт мгновенную обратную связь и помогает понять, как работают API. Вы будете отправлять запросы, изучать ответы и проверять поведение в интерактивном режиме. Это отлично подходит для:

• Исследовательского тестирования новых endpoint-ов
• Отладки конкретных проблем
• Изучения поведения API перед написанием автоматизированных тестов
• Быстрой верификации в процессе разработки

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

По мере роста набора тестов автоматизация становится необходимой. Автоматизированные API-тесты могут:

• Запускаться в CI/CD-пайплайнах при каждом изменении кода
• Покрывать сотни сценариев за секунды
• Обнаруживать регрессии немедленно
• Служить живой документацией ожидаемого поведения

Популярные инструменты автоматизации включают REST Assured (Java), pytest + requests (Python), Supertest (Node.js) и Postman/Newman для тестирования на основе коллекций.

Контрактное тестирование #

Контрактное тестирование проверяет, что API соответствует соглашению (контракту) между потребителем и провайдером. Это особенно важно в архитектурах микросервисов, где множество сервисов зависят друг от друга. Инструменты вроде Pact помогают гарантировать, что изменения в одном сервисе не сломают другие.

Составление первого плана тестирования API #

При подходе к новому API для тестирования следуйте этому систематическому процессу:

Шаг 1: Изучите документацию API #

Прочитайте спецификацию API (Swagger/OpenAPI, README или wiki). Отметьте:

• Доступные endpoint-ы и их назначение
• Обязательные и опциональные параметры
• Требования к аутентификации
• Rate limit-ы и ограничения

Шаг 2: Определите тестовые сценарии #

Для каждого endpoint-а создайте тестовые сценарии, покрывающие:

Позитивный сценарий (happy path):

• Валидные запросы со всеми обязательными полями
• Валидные запросы с включёнными опциональными полями
• Различные валидные значения для каждого параметра

Негативное тестирование:

• Отсутствующие обязательные поля
• Невалидные типы данных (строка там, где ожидается число)
• Граничные значения (пустые строки, максимальные длины, ноль, отрицательные числа)
• Невалидная аутентификация

Граничные случаи:

• Специальные символы в строках (Unicode, эмодзи, HTML-теги)
• Очень большие payload-ы
• Конкурентные запросы к одному ресурсу
• Запросы с лишними/неизвестными полями

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

Для каждого сценария задокументируйте, что должен вернуть API:

• Ожидаемый status code
• Ожидаемая структура тела ответа
• Ожидаемые сообщения об ошибках для негативных кейсов
• Ожидаемые побочные эффекты (изменения в БД, вызванные события)

Шаг 4: Приоритизируйте и выполните #

Не все тесты одинаково важны. Приоритизируйте:

1. Аутентификация и авторизация
2. Основная бизнес-логика (CRUD-операции)
3. Валидация ввода и обработка ошибок
4. Граничные случаи и пограничные условия
5. Производительность под нагрузкой

Практическое упражнение #

Используя любой REST API (рекомендуем JSONPlaceholder — бесплатный фейковый API для тестирования), выполните эти задания:

1. Отправьте GET-запрос на https://jsonplaceholder.typicode.com/posts/1 и определите все поля в ответе
2. Отправьте POST-запрос на https://jsonplaceholder.typicode.com/posts с JSON-телом, содержащим title, body и userId — обратите внимание на status code
3. Отправьте GET-запрос на https://jsonplaceholder.typicode.com/posts/9999 (несуществующий) — какой status code вы получите?
4. Задокументируйте результаты в простом отчёте: endpoint, метод, входные данные, ожидаемый результат, фактический результат, pass/fail

Можете использовать инструменты разработчика в браузере (вкладка Network), cURL из терминала или скачать Postman (рассматривается в Уроке 6.4).

Ключевые выводы #

• API — это слой коммуникации между программными системами, критически важный в архитектуре современных приложений
• Тестирование API находится на среднем уровне пирамиды тестирования, обеспечивая баланс скорости, стабильности и покрытия
• Каждое взаимодействие с API следует паттерну запрос-ответ с методами, заголовками, кодами статуса и телом
• Полноценный план тестирования API покрывает позитивные сценарии, негативные сценарии, граничные случаи и безопасность
• Начинайте с ручного тестирования для понимания, затем переходите к автоматизации для регрессионного покрытия