Перейти к основному содержимому

Тестирование и анализ API

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Тестировщику Разработчику Аналитику
Теория данных (раздел 3)

Проверка в БД — SQL для тестировщика, Основы БД, транзакции, PostgreSQL. Карта — о разделе.

Зачем эта статья. Современное приложение — это часто фронт + API. Проверять только кнопки долго и поздно: бэкенд можно тестировать раньше UI, быстрее и стабильнее. Здесь — как исследовать API, что смотреть в ответе и рабочие инструменты — curl, Postman, Chrome DevTools, плюс короткий автотест на pytest для закрепления.

Тестирование и исследование API​

Когда говорят "тестируем API", имеют в виду проверку логики системы через HTTP-запросы — без браузера и вёрстки. Это удобно для интеграции сервисов (REST, SOAP, очереди) и часто становится первым уровнем автоматизации.

В разговорной речи говорят "тестируем API", но по смыслу проверяют функциональность системы через программный интерфейс (а не "качество самого слова API"). Отдельный фокус — интеграционное тестирование — два сервиса по сети (REST, SOAP, очереди). Базовые определения и вызов через Postman/curl: API — интерфейсы прикладного программирования, Работа с Postman и curl, утилита curl — полная шпаргалка, curl / fetch — примеры. Клиентский код на JavaScript — Fetch / axios — типовые запросы.

Цель — убедиться, что API возвращает ожидаемые результаты, корректно обрабатывает ошибки и не нарушает контракт (документацию). Подробнее про HTTP: раздел интеграции. Как проектировать контракт и примеры ошибок — Проектирование API и интеграций; маршрут по главам — таблица в design/117.

Практикум для JVM-разработчиков

Если вы уже на Groovy/Java и хотите собрать свой desktop-клиент для ручных HTTP-запросов (URL, метод, заголовки, JSON) с движком JMeter под капотом — пошаговый маршрут в Практикум — API-тестер на Groovy и JMeter. Там же разбор TestPlan, DTO и smoke-теста для CI.

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

Исследование API начинается с понимания его контракта — документации, спецификации или схемы, описывающей доступные эндпоинты, методы, параметры, заголовки, тела запросов и форматы ответов. Современные API часто сопровождаются машинно-читаемыми спецификациями в форматах OpenAPI (ранее Swagger) или AsyncAPI, что упрощает автоматизацию и генерацию клиентских библиотек.

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

Исследование API включает:

  • Проверку доступности эндпоинтов.
  • Анализ структуры запросов и ответов.
  • Верификацию кодов состояния HTTP.
  • Изучение поведения при различных комбинациях параметров.
  • Тестирование аутентификации и авторизации.
  • Оценку производительности и устойчивости к нагрузке.
  • Поиск уязвимостей и несанкционированных путей доступа.

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

Общие принципы работы с HTTP-запросами​

Большинство современных API используют протокол HTTP или HTTPS. Каждый запрос состоит из метода (GET, POST, PUT, DELETE и другие), URI (адреса ресурса), заголовков (headers) и, при необходимости, тела (body). Ответ сервера содержит статус-код, заголовки и тело с данными.

Метод GET используется для получения информации без изменения состояния системы. POST применяется для создания новых ресурсов или выполнения действий с побочными эффектами. PUT заменяет ресурс целиком, PATCH — частично обновляет его. DELETE удаляет ресурс. Эти соглашения помогают сохранять семантическую ясность и предсказуемость поведения API.

Заголовки передают метаданные — тип содержимого (Content-Type), авторизационные токены (Authorization), язык предпочтений (Accept-Language) и другие параметры. Тело запроса может содержать данные в форматах JSON, XML, form-data, plain text и других, в зависимости от требований API.

Понимание этих базовых элементов необходимо для эффективного тестирования и исследования любого веб-API, независимо от используемого инструмента.

cURL​

Примеры для отчёта и лабораторной

GET, POST JSON, коды 401/404/500, Bearer-токен и health-check с разбором — curl / fetch — API-запросы (терминал), Fetch / axios — типовые запросы (JavaScript).

Теория флагов — утилита curl.

cURL — это мощная утилита командной строки и библиотека libcurl, предназначенная для передачи данных с сервера на клиент и обратно с использованием различных протоколов, включая HTTP, HTTPS, FTP, SMTP и многие другие. В контексте тестирования API cURL выступает как минималистичный, но чрезвычайно гибкий инструмент, позволяющий отправлять произвольные HTTP-запросы без необходимости запуска графического интерфейса или написания кода.

Основное преимущество cURL — его доступность. Он предустановлен почти во всех Unix-подобных системах (Linux, macOS), легко устанавливается в Windows через пакетные менеджеры (например, Chocolatey или winget) и встроен в большинство контейнерных образов. Это делает cURL идеальным инструментом для быстрой проверки работоспособности эндпоинта, отладки сетевых проблем или автоматизации простых сценариев в скриптах.

Базовый синтаксис и структура запроса​

Простейший запрос к API с помощью cURL выглядит так:

curl https://api.example.com/users

Эта команда отправляет GET-запрос к указанному URL и выводит тело ответа в терминал. По умолчанию cURL использует метод GET и не добавляет заголовки, кроме тех, что необходимы для корректного выполнения запроса.

Для отправки других типов запросов используется флаг -X (или --request):

curl -X POST https://api.example.com/users

Чтобы передать данные в теле запроса, применяется флаг -d (или --data). При этом cURL автоматически устанавливает заголовок Content-Type: application/x-www-form-urlencoded, если явно не указано иное:

curl -X POST -d "name=Alice&email=alice@example.com" https://api.example.com/users

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

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice","email":"alice@example.com"}' \
  https://api.example.com/users

Заголовки можно добавлять многократно с помощью флага -H. Это особенно полезно при работе с аутентификацией, например, через Bearer-токены:

curl -H "Authorization: Bearer abc123xyz" \
     -H "Accept: application/json" \
     https://api.example.com/profile

Расширенные возможности​

cURL поддерживает множество дополнительных опций, повышающих его полезность при тестировании:

  • Флаг -v (verbose) включает подробный вывод, включая отправленные заголовки, полученные заголовки и коды состояния. Это незаменимо при диагностике проблем с соединением или неожиданным поведением сервера.
  • Флаг -i выводит заголовки ответа вместе с телом, что помогает быстро увидеть, например, значение Set-Cookie или Location.
  • Флаг -o сохраняет тело ответа в файл, а -O — сохраняет файл с именем, как на сервере.
  • Флаг --fail заставляет cURL возвращать ненулевой код завершения при HTTP-ошибках (например, 404 или 500), что критично для использования в скриптах автоматизации.
  • Флаг --max-time ограничивает общее время выполнения запроса, предотвращая зависание при медленных или недоступных сервисах.

cURL также умеет работать с cookies (--cookie, --cookie-jar), следовать редиректам (-L), использовать прокси (--proxy), проверять SSL-сертификаты (--cacert, --insecure) и многое другое.

Практическое применение в тестировании​

В повседневной практике разработчика или тестировщика cURL используется для:

  • Быстрой проверки доступности эндпоинта.
  • Верификации формата ответа (например, соответствия JSON-схеме).
  • Тестирования различных сценариев авторизации.
  • Имитации поведения клиентского приложения без запуска браузера.
  • Интеграции в CI/CD-пайплайны для smoke-тестов после деплоя.
  • Генерации примеров запросов, которые можно включить в документацию.

Несмотря на отсутствие графического интерфейса, cURL предоставляет полный контроль над каждым аспектом HTTP-запроса. Его текстовая природа делает команды легко воспроизводимыми, версионируемыми и переносимыми между средами.

Postman​

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

В отличие от cURL, который требует знания синтаксиса командной строки, Postman предоставляет интуитивно понятные формы для конфигурации запросов — выбор метода, ввод URL, добавление заголовков, параметров, тела запроса — всё это осуществляется через элементы управления. Это снижает порог входа для новичков и ускоряет процесс исследования API.

Основные компоненты интерфейса​

Центральным элементом Postman является запрос (Request) — полное описание HTTP-вызова. Каждый запрос содержит:

  • Метод (GET, POST, PUT и другие).
  • URL с поддержкой переменных окружения.
  • Параметры запроса (query parameters), которые автоматически кодируются и добавляются к URL.
  • Заголовки (Headers), задаваемые в виде пар "ключ–значение".
  • Тело запроса (Body), которое может быть представлено в форматах raw (JSON, XML, текст), form-data, x-www-form-urlencoded, binary или GraphQL.

Postman позволяет сохранять запросы в коллекциях (Collections) — иерархических структурах, организующих связанные эндпоинты. Коллекции могут включать папки, описания, примеры ответов и даже скрипты, выполняемые до отправки запроса (Pre-request Scripts) или после получения ответа (Tests).

Переменные и окружения​

Одна из ключевых особенностей Postman — гибкая система переменных. Они позволяют абстрагироваться от конкретных значений (например, базового URL, токенов, идентификаторов) и использовать одни и те же запросы в разных контекстах. Переменные бывают нескольких типов:

  • Глобальные — доступны во всём рабочем пространстве.
  • Переменные коллекции — привязаны к конкретной коллекции.
  • Переменные окружения (Environment) — группируются в наборы, соответствующие разным средам — разработка, тестирование, продакшн.
  • Локальные переменные — используются внутри одного запроса.

Например, базовый URL https://api.dev.example.com можно заменить на {{base_url}}, а значение переменной задать в окружении "Разработка". При переключении на окружение "Production" все запросы автоматически будут использовать https://api.example.com.

Автоматизация и тестирование​

Postman включает встроенный JavaScript-движок, позволяющий писать скрипты для автоматизации сценариев. В разделе Tests можно проверять:

  • Статус-код ответа.
  • Наличие и значение определённых полей в JSON.
  • Время отклика.
  • Корректность заголовков.
  • Соответствие схеме (через библиотеку tv4 или ajv).

Пример теста:

pm.test("Статус 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Ответ содержит имя пользователя", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData.name).to.exist;
});

Эти тесты выполняются автоматически после каждого запроса и отображаются в виде отчёта. Их можно запускать массово через Collection Runner. Для запуска в пайплайне сборки часто используют Newman (CLI Postman) — это уже зона DevOps; для ручной и учебной практики достаточно Collection Runner.

Автотест API на Python (pytest + httpx)​

Postman удобен для исследования; для повторяемых проверок в репозитории команды часто пишут код. Минимальный пример — тот же смысл, что и в Postman: запрос → статус → поле в JSON.

Установка: pip install pytest httpx.

Код ITЗагрузка примера кода…

Запуск: pytest tests/test_users_api.py -v.

Что здесь важно для QA:

  • Оракул явный: 200 и наличие полей (при появлении OpenAPI можно сверять со схемой).
  • Тест быстрый и без браузера — это скорее API/integration, не E2E.
  • Тот же сценарий можно сначала "нащупать" в Postman, затем перенести в код — см. практикум 1012.

Документация и совместная работа​

Postman автоматически генерирует документацию по коллекции, включая описания, примеры запросов и ответов, параметры и схемы. Эта документация публикуется в виде веб-страницы и может быть доступна команде или внешним партнёрам.

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

Интеграция с другими инструментами​

Postman умеет импортировать спецификации OpenAPI, GraphQL-схемы и даже сырые HTTP-запросы. Он также экспортирует запросы в код на множестве языков (JavaScript, Python, C#, Go и других), что упрощает переход от ручного тестирования к написанию интеграционных тестов.

Кроме того, Postman предоставляет мониторинг (Monitors) — возможность запускать коллекции по расписанию и получать уведомления о сбоях, а также Mock Servers — серверы-заглушки, возвращающие предопределённые ответы на основе правил, что полезно при разработке фронтенда до готовности бэкенда.

SOAP UI​

SOAP UI — это профессиональный инструмент, разработанный специально для тестирования веб-сервисов, в первую очередь тех, что используют протокол SOAP (Simple Object Access Protocol), но также поддерживающий REST, GraphQL, JMS, AMF и другие технологии. Он ориентирован на enterprise-среды, где требуется глубокая верификация контрактов, сложные сценарии интеграции, нагрузочное тестирование и соответствие строгим стандартам качества.

В отличие от универсальных решений вроде Postman, SOAP UI изначально проектировался как платформа для QA-инженеров и системных интеграторов, работающих с корпоративными системами — ERP, CRM, банковскими платформами, государственными сервисами. Такие системы часто полагаются на XML-сообщения, WSDL-описания (Web Services Description Language) и строгие схемы XSD, что требует специализированных возможностей анализа и валидации.

Работа с SOAP-сервисами​

Основной сценарий использования SOAP UI начинается с импорта WSDL-файла — документа, описывающего структуру SOAP-сервиса — доступные операции, формат входящих и исходящих сообщений, типы данных и привязки к транспортному протоколу (обычно HTTP). После импорта SOAP UI автоматически генерирует готовые запросы-заготовки для каждой операции, заполняя их примерами на основе схемы.

Пользователь может редактировать тело запроса в виде XML, добавлять заголовки безопасности (например, WS-Security), настраивать прокси и SSL-сертификаты, а затем отправлять запрос и анализировать ответ. Встроенный XML-парсер проверяет соответствие ответа XSD-схеме, выявляя несоответствия структуры или типов данных.

Поддержка REST и других протоколов​

Хотя SOAP UI исторически ассоциируется с SOAP, современные версии полностью поддерживают RESTful API. Можно создавать REST-проекты вручную или импортировать OpenAPI-спецификации. Инструмент позволяет задавать методы, параметры, заголовки, тела запросов в JSON или XML, а также использовать переменные и свойства проекта для параметризации.

Особое внимание уделено функциональному и регрессионному тестированию. Тестовые сценарии в SOAP UI строятся в виде деревьев — каждый шаг может быть запросом, утверждением (assertion), задержкой, условным переходом или вызовом другого теста. Утверждения позволяют проверять:

  • Статус-коды.
  • Наличие подстрок или регулярных выражений в ответе.
  • Соответствие JSON Schema или XSD.
  • Время выполнения.
  • Значения XPath или JSONPath-выражений.

Это делает тесты самодостаточными и пригодными для повторного запуска без ручного вмешательства.

Нагрузочное и безопасностное тестирование​

Одно из ключевых преимуществ SOAP UI — встроенная поддержка нагрузочного тестирования (Load Testing). На основе функционального теста можно создать нагрузочный сценарий, задав количество потоков, длительность, стратегию распределения запросов (например, пошаговое увеличение нагрузки) и критерии успеха. Результаты визуализируются в виде графиков — время отклика, количество ошибок, пропускная способность.

Кроме того, SOAP UI предлагает модуль Безопасность Тестирование, который автоматически проверяет API на уязвимости — SQL-инъекции, XSS, неправильную обработку токенов, отсутствие ограничений скорости и другие распространённые проблемы. Это особенно важно для систем, обрабатывающих конфиденциальные данные.

Интеграция и автоматизация​

SOAP UI существует в двух основных редакциях: бесплатной Open Source и коммерческой ReadyAPI (включающей дополнительные модули для виртуализации, мониторинга и CI/CD). Обе версии поддерживают запуск тестов из командной строки с помощью утилиты testrunner.sh (или .bat), что позволяет интегрировать их в Jenkins, GitLab CI, Azure DevOps и другие системы непрерывной интеграции.

Проекты SOAP UI хранятся в виде XML-файлов, что обеспечивает совместимость с системами контроля версий. Команды могут совместно разрабатывать и поддерживать наборы тестов, отслеживая изменения через Git.

Когда выбирать SOAP UI​

SOAP UI особенно уместен в следующих ситуациях:

  • Работа с legacy-системами на базе SOAP/WSDL.
  • Требования к строгой валидации XML-сообщений и соответствию XSD.
  • Необходимость комплексного нагрузочного или безопасностного тестирования без подключения сторонних инструментов.
  • Интеграция в enterprise-инфраструктуру с централизованным управлением тестами.

Для современных REST/JSON-API он может показаться избыточным, но его мощь раскрывается в сложных, регулируемых средах, где надёжность и соответствие стандартам важнее скорости разработки.

Chrome DevTools​

Справочник в энциклопедии

Все вкладки DevTools, отладка JS, Memory, Lighthouse и типовые сценарии для API — в энциклопедии: DevTools в браузере — справочник.

Ниже — фокус на Network при тестировании API.

Chrome DevTools — это набор инструментов разработчика, встроенный непосредственно в браузер Google Chrome. Он предоставляет возможность наблюдать, анализировать и отлаживать поведение веб-приложений в реальном времени, включая все сетевые запросы, отправляемые клиентом к серверу. Хотя DevTools не является специализированным инструментом для тестирования API в том же смысле, что Postman или cURL, он играет уникальную роль в понимании того, как именно фронтенд использует API, какие данные передаются, как обрабатываются ошибки и как выглядит взаимодействие в условиях реального пользовательского сценария.

Вкладка Сеть — окно в сетевую активность​

Центральный элемент DevTools для работы с API — вкладка Сеть (Сеть). Она перехватывает все HTTP/HTTPS-запросы, инициированные страницей — загрузку HTML, CSS, JavaScript, изображений, а также XHR (XMLHttpRequest) и Fetch-вызовы к API. Каждый запрос отображается в виде строки с ключевой информацией:

  • Метод (GET, POST и т.д.).
  • URL.
  • Статус-код ответа.
  • Тип содержимого (Content-Type).
  • Размер ответа.
  • Время загрузки.

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

  • Headers — полный список отправленных заголовков запроса и полученных заголовков ответа, включая куки, авторизацию, CORS-заголовки.
  • Payload (или Form Data / Request) — тело отправленного запроса, особенно полезно для POST/PUT-запросов с JSON или form-data.
  • Preview и Response — визуальное и текстовое представление тела ответа. Preview автоматически форматирует JSON, XML или HTML для удобства чтения.
  • Timing — детальная временная шкала, показывающая этапы обработки запроса — DNS-поиск, установка соединения, ожидание ответа (TTFB), получение данных. Это помогает выявлять узкие места в производительности.

Отладка в реальном времени​

Одно из главных преимуществ DevTools — возможность наблюдать за API-взаимодействием без модификации кода. Пользователь может:

  • Нажать кнопку на сайте и сразу увидеть, какой запрос отправился к API.
  • Проверить, какие параметры передаются при фильтрации, поиске или отправке формы.
  • Убедиться, что токен авторизации присутствует в заголовках.
  • Обнаружить, что ошибка 401 возникает из-за просроченного сессионного куки.
  • Увидеть, что ответ приходит в корректном формате, но фронтенд его некорректно обрабатывает.

Это делает DevTools незаменимым инструментом для full-stack-разработчиков, которым нужно быстро диагностировать рассогласование между бэкендом и фронтендом.

Фильтрация и поиск​

Вкладка Сеть поддерживает мощные средства фильтрации. Можно отобразить только XHR/Fetch-запросы, исключив статические ресурсы. Можно фильтровать по методу, статусу, домену или даже по содержимому тела запроса. Поле поиска позволяет находить конкретные строки в теле ответа — например, идентификатор пользователя или сообщение об ошибке.

Также доступна опция Preserve log, которая сохраняет историю запросов при переходе между страницами — это критично для одностраничных приложений (SPA), где навигация не вызывает полной перезагрузки.

Имитация условий и повторный запуск​

DevTools позволяет эмулировать различные условия:

  • Ограничение скорости сети (Throttling) — для проверки поведения приложения при медленном интернете.
  • Отключение кэширования — чтобы гарантировать, что каждый запрос уходит на сервер.
  • Блокировка определённых запросов — для тестирования обработки ошибок.

Кроме того, любой запрос можно повторить (Replay XHR) или скопировать как cURL-команду. Эта функция особенно ценна — разработчик видит проблему в браузере, копирует запрос в виде cURL, вставляет его в терминал и воспроизводит ситуацию вне контекста фронтенда. Это мост между интерактивным анализом и программным тестированием.

Ограничения и комплементарность​

Chrome DevTools не предназначен для создания автономных тестовых сценариев, генерации документации или выполнения нагрузочных испытаний. Его сфера — наблюдение и диагностика в контексте работающего веб-приложения. Однако именно эта специфика делает его идеальным дополнением к другим инструментам. Например:

  • cURL подходит для быстрой проверки эндпоинта из терминала.
  • Postman — для проектирования и автоматизации тестов.
  • SOAP UI — для глубокой верификации enterprise-сервисов.
  • Chrome DevTools — для понимания, как API используется на практике и где возникают реальные проблемы.

Минимальный API smoke после деплоя​

После выката полезно запускать короткий набор — доступность сервиса, авторизация, базовый CRUD, негатив на валидацию и проверка ключевых полей контракта. Такой smoke быстро показывает, что релиз пригоден для дальнейшего тестирования.

Антипаттерны​

Частые ошибки — проверять только статус-код, не тестировать негативные сценарии, использовать общий токен без проверки ролей и запускать тесты на прод-данных.

Кейс "200 OK, но контракт уже сломан"​

Ситуация: endpoint стабильно возвращает 200, но фронтенд падает после релиза.

Причина: структура JSON изменилась, а API-тесты проверяли только статус-код.

Что добавлять в базовый набор:

  • assert по обязательным полям и их типам;
  • проверку негативных ответов (400/401/403/422);
  • сценарии по ролям доступа, а не только по одному токену.

Так API-тестирование выявляет контрактные поломки до этапа UI-регресса.

Навигация по разделу "Тестирование"​

Содержание