API-тестирование 101: всё, что нужно знать QA-инженеру в 2026 году

Когда тестируешь через UI, ты тестируешь API косвенно: UI вызывает API за тебя, скрывая режимы отказа которые существуют только на HTTP-уровне. Тестирование API напрямую означает отправку HTTP-запросов без браузера, что показывает что происходит с отсутствующими обязательными полями, недействительными токенами авторизации или несуществующими ID. Здесь разобран полный фундамент: структура HTTP-запроса и ответа, что проверять в каждом ответе, паттерны аутентификации и как писать API-тесты в Playwright.

Что такое API с точки зрения тестирования

API это контракт. Одна система говорит: «Пришли мне запрос в такой форме, и я дам ответ в такой». Задача QA-инженера: убедиться что контракт соблюдается. Что система действительно возвращает обещанное, отклоняет что должна отклонять и корректно обрабатывает ошибки.

На практике большинство API которые приходится тестировать это REST API поверх HTTP. У приложения для бронирования путешествий есть API-эндпоинт создающий бронирование. У системы управления пользователями есть эндпоинт возвращающий список пользователей. У e-commerce платформы есть эндпоинты для добавления в корзину, проверки наличия и обработки платежей.

Когда тестируешь через UI, ты тестируешь API косвенно. Когда тестируешь API напрямую, UI исключается из уравнения. Это быстрее, сообщения об ошибках точнее, и открывается возможность тестировать сценарии которые UI не раскрывает: что происходит при отрицательной цене, пустом обязательном поле или запросе без аутентификации?

HTTP-фундаментал для тестировщиков

Каждое взаимодействие с API это HTTP-запрос за которым следует HTTP-ответ. Из чего состоит каждая сторона.

Запрос содержит четыре части: метод, URL, заголовки и опциональное тело.

Метод сообщает серверу какую операцию ты хочешь выполнить. Четыре метода используются постоянно: GET (получить данные), POST (создать что-то новое), PUT или PATCH (обновить что-то), DELETE (удалить что-то). GET на /api/users возвращает список пользователей. POST на /api/users с данными пользователя в теле создаёт нового пользователя.

URL это адрес ресурса. Обычно имеет базу вроде https://api.example.com, путь вроде /users/42 и иногда параметры запроса вроде ?status=active&page=2.

Заголовки передают метаданные: тип содержимого тела (Content-Type: application/json), учётные данные для аутентификации (Authorization: Bearer eyJ...), инструкции серверу о принимаемом формате (Accept: application/json).

Тело содержит данные которые отправляешь, обычно в формате JSON для современных REST API.

Ответ отражает эту структуру. Он содержит код статуса, заголовки и тело. Код статуса наиболее важен для тестирования:

• 200 OK: запрос успешен, вот что просили
• 201 Created: что-то создано успешно
• 400 Bad Request: запрос некорректен или отсутствуют обязательные поля
• 401 Unauthorized: не аутентифицирован
• 403 Forbidden: аутентифицирован, но доступ запрещён
• 404 Not Found: такого ресурса не существует
• 422 Unprocessable Entity: запрос сформирован корректно но семантически невалиден
• 500 Internal Server Error: ошибка сервера

Что тестировать в API

Инстинкт: тестировать только happy path. Отправил валидные данные, получил 200. Готово. Этот подход ловит от силы 20% багов. Вот более полная система.

Полезная ментальная модель: для каждого эндпоинта задай три вопроса. Что должно работать? Что должно ломаться? Как должна выглядеть ошибка при поломке?

Инструменты: Postman, Playwright и curl

Три инструмента закрывают большинство потребностей.

# GET запрос
curl https://lab.becomeqa.com/api/items

# POST с JSON-телом
curl -X POST https://lab.becomeqa.com/api/items \
  -H "Content-Type: application/json" \
  -d '{"destination": "Tokyo", "status": "planned"}'

# С заголовком Authorization
curl https://lab.becomeqa.com/api/items \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..."

import { test, expect } from '@playwright/test';

test('POST /api/items creates a new item', async ({ request }) => {
  const response = await request.post('https://lab.becomeqa.com/api/items', {
    data: {
      destination: 'Tokyo',
      status: 'planned'
    }
  });

  expect(response.status()).toBe(201);

  const created = await response.json();
  expect(created).toHaveProperty('id');
  expect(created.destination).toBe('Tokyo');
});

Рабочий процесс: исследуй с Postman и curl, автоматизируй с Playwright.

Анатомия REST API теста

Хороший API-тест проверяет больше чем просто код статуса. Что проверять в каждом ответе.

Код статуса первый барьер. Добейся правильного кода прежде чем проверять что-либо ещё. Если статус неверный, всё остальное неважно.

Структура тела ответа важна. Если API обещает вернуть объект пользователя с id, email и role, тест должен проверять наличие всех трёх полей в каждом ответе. Это ловит тихие регрессии когда кто-то добавляет обязательное поле во фронтенд-контракт но забывает включить его в ответ API.

Значения полей важны, не только их наличие. Если создал пользователя с email test@example.com, ответ должен отражать именно этот email. Если API возвращает поле статуса, проверяй что это одно из ожидаемых значений, а не просто любая строка.

Заголовки ответа тоже несут информацию. Проверяй Content-Type: application/json если ожидаешь JSON. Для эндпоинтов с пагинацией проверяй заголовки пагинации вроде X-Total-Count или ссылки в теле ответа.

Время ответа это сигнал. Playwright не даёт ассёрты на время ответа из коробки, но можно измерять вручную. Эндпоинт который обычно отвечает за 50мс, но вернул ответ за 2000мс, стоит отметить даже если данные корректны.

Аутентификация в API-тестах

Почти каждый продакшн API требует аутентификации. Два паттерна которые встречаются ежедневно: API-ключи и Bearer-токены.

curl https://api.example.com/data \
  -H "X-API-Key: your-api-key-here"

В автоматизированных тестах никогда не хардкоди ключ. Храни его в переменной окружения и читай оттуда. Это держит секреты вне тестового кода и упрощает переключение между staging и production учётными данными.

Тестирование edge cases аутентификации (невалидные токены, отсутствующие токены, токены с неправильными правами) это одно из наиболее ценных API-тестирований. Последствия ошибок в auth серьёзные, и эти баги часто живут в API, а не в UI где их бы поймали UI-тесты.

Место API-тестирования в тест-пирамиде

Тест-пирамида это модель распределения тестов. В основании: много юнит-тестов, быстрых и дешёвых, тестирующих отдельные функции. В середине: интеграционные и API-тесты, проверяющие как системы взаимодействуют. На вершине: мало UI-тестов, тестирующих полные пользовательские сценарии.

API-тесты занимают оптимальную позицию. Они значительно быстрее UI-тестов. Типичный API-тест выполняется за 50–200 миллисекунд против 3–10 секунд у UI-теста. Они устойчивее потому что не ломаются при изменении подписи кнопки или CSS-селектора. И они тестируют слой где живёт большинство бэкенд-багов.

Практическое соотношение для типичного веб-приложения: на каждый 1 UI-тест покрывающий пользовательский флоу пиши 3–5 API-тестов покрывающих лежащие в основе эндпоинты. UI-тест проверяет что части соединяются корректно. API-тесты проверяют что каждая часть работает корректно сама по себе.

Это особенно важно для бизнес-логики. Если e-commerce приложение рассчитывает скидки на бэкенде, тестируй этот расчёт через API, а не заполняя форму оформления заказа в браузере. API-тест будет в десять раз быстрее и протестирует каждый граничный случай (ноль товаров, истёкший промокод, стекированные скидки) без хрупкости UI.

Как начать в ближайший понедельник

Не нужно рефакторить весь тест-сьют. Вот как начать с малого на этой неделе.

Выбери одну функцию у которой есть UI-тесты но нет API-тестов. Посмотри сетевой трафик в Chrome DevTools при использовании этой функции. Ты увидишь API-вызовы которые делает UI. Выбери наиболее важный эндпоинт (обычно тот который создаёт или получает основные данные) и напиши для него один API-тест в Postman.

Проверь happy path. Затем напиши один тест для 404 (запрос ресурса по несуществующему ID). Затем один тест для 400 (POST с отсутствующим обязательным полем). Три теста которые займут 30 минут написать, и паттерн установлен.

Дальше перенеси эти три теста в Playwright чтобы они запускались в CI вместе с существующими тестами. Используй структуру кода из примеров в этой статье. Запусти однажды чтобы убедиться что проходят.

После расширяй покрытие задавая вопросы: «Какой следующий по важности эндпоинт?» и «Какие error cases у этого эндпоинта я не тестирую?»

Через несколько недель будет API-слой тестов который ловит бэкенд-баги за секунды вместо того чтобы они всплывали через UI-тесты работающие минутами.