Что означает «проверить API без кода»

Речь не о магической проверке «всего API» одной кнопкой. Пользователь по-прежнему формулирует условия: какие входные данные допустимы, какой HTTP-статус ожидается, что должно находиться в заголовках и теле, сколько времени может занимать ответ. Отличие в способе реализации: запрос и правила собираются в интерфейсе, а не в тестовом файле на языке программирования.

Такой подход полезен, когда сценарий должен быть понятен нескольким ролям: тестировщику, аналитику, разработчику и специалисту поддержки. Визуальная проверка также удобна для исследования нового API, воспроизведения дефекта и подготовки однозначного примера. Для сложной логики и больших наборов автотестов код может оставаться уместным; эти подходы не обязаны конкурировать.

Перед началом: сформулируйте контракт

Возьмём условную операцию создания заказа. Недостаточно записать «POST должен работать». Полезный минимальный контракт звучит точнее:

  • при валидном теле и токене сервер возвращает ожидаемый успешный статус;
  • тип содержимого ответа соответствует JSON;
  • в теле есть непустой идентификатор и ожидаемое состояние заказа;
  • время ответа не превышает согласованную для тестовой среды границу;
  • идентификатор можно использовать, чтобы запросить созданный заказ следующим шагом.

Конкретные статусы и лимиты берите из документации и требований вашей системы. Не назначайте универсальный порог только потому, что он кажется быстрым: тестовая среда, операция и ожидания пользователей различаются.

Практический процесс: от запроса до сценария

  1. Создайте или импортируйте запрос. Если есть cURL, спецификация OpenAPI/Swagger или коллекция Postman, импорт снижает риск потерять метод, адрес, параметры и заголовки. Иначе задайте их визуально: выберите HTTP-метод, укажите URL, параметры строки, заголовки и тело.
  2. Отделите настройки среды. Базовый URL, токен и повторяемые значения вынесите в переменные. Имена вроде baseUrl и accessToken понятнее, чем значения, скопированные в каждый запрос. Секреты не следует помещать в примеры, отчёты и общие тестовые данные.
  3. Выполните запрос без большого набора правил. Сначала убедитесь, что сервер доступен, авторизация принята, а формат тела корректен. Если транспортный слой не работает, десятки проверок содержимого лишь создадут шум.
  4. Добавьте проверку статуса. Указывайте тот код, который предусмотрен контрактом конкретной операции. Для создания это не обязательно 200; для негативного случая ожидаемый 4xx является успешным результатом теста, если именно такое поведение описано.
  5. Проверьте заголовки и время. Заголовок Content-Type помогает подтвердить формат. При необходимости проверяйте также заголовок корреляции или другие значимые поля. Ограничение времени ответа фиксирует наблюдаемое требование, но не заменяет нагрузочное тестирование.
  6. Добавьте правила для тела. Вместо полного сравнения JSON или XML выберите устойчивые пути: наличие идентификатора, тип значения, состояние объекта, код ошибки. Динамическую дату или случайный идентификатор обычно проверяют на наличие и формат, а не на заранее известное значение.
  7. Сохраните значение в переменную. Извлеките идентификатор созданного объекта из ответа и передайте его в URL следующего запроса. Так появляется реальная цепочка «создать → получить», а данные не приходится переносить вручную.
  8. Добавьте проверку результата во втором шаге. Убедитесь, что полученный объект имеет тот же идентификатор и ключевые данные из запроса создания. Это сильнее, чем два несвязанных запроса с заранее заданными значениями.
  9. Создайте контролируемый негативный сценарий. Например, исключите обязательное поле. Ожидайте документированный статус и стабильный код или тип ошибки в теле. Не используйте разрушительные или реальные пользовательские данные без разрешения.
  10. Повторите запуск с чистыми входными данными. Проверка должна либо создавать уникальные данные, либо учитывать уже существующее состояние. Повторный запуск выявляет скрытые зависимости от порядка и ручной подготовки.

Минимальный набор проверок для одного ответа

Статус: соответствует контракту операции. Заголовок: Content-Type указывает ожидаемый формат. Тело: обязательный идентификатор существует, а состояние равно ожидаемому. Время: укладывается в согласованную границу. Эти четыре группы отвечают на разные вопросы и дают более полезную диагностику, чем одна общая отметка «успешно».

Как выбирать проверки, которые не ломаются зря

Проверяйте смысл, а не оформление

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

Разделяйте наличие, тип и значение

Поле может существовать, но иметь неверный тип или недопустимое значение. Поэтому вопрос «есть ли orderId?» отличается от вопросов «это строка?» и «она непустая?». Для состояния объекта, наоборот, часто важно точное значение из ограниченного набора.

Не скрывайте причину за длинной цепочкой

Если авторизация не прошла на первом шаге, дальнейшие запросы с пустой переменной не дают новой информации. Хороший сценарий показывает первую нарушенную предпосылку. Стройте цепочку постепенно и называйте шаги по действию и ожидаемому результату.

Полезная граница: визуальная проверка времени ответа подтверждает порог для единичного запуска сценария. Она не доказывает производительность под одновременной нагрузкой и не должна описываться как нагрузочный тест.

Распространённые ошибки

  • Один «правильный» пример вместо границ. Добавьте хотя бы один негативный случай: отсутствие обязательного поля, неверный формат или недостаточные права.
  • Токен внутри URL или тела каждого шага. Переменная уменьшает дублирование и риск частичной замены при смене среды.
  • Проверка только кода ответа. Сервер может вернуть успешный статус вместе с неполным или семантически неверным телом.
  • Случайный лимит времени. Порог должен исходить из требования, а результаты единичных запусков нельзя превращать в обещание производительности.
  • Зависимость от старых данных. Сценарий, который работает только после ручного создания объекта, трудно повторить другому человеку.
  • Слишком много утверждений сразу. Начинайте с ключевого контракта; детализируйте после того, как базовая цепочка стабильно воспроизводится.

Когда нужны другие протоколы и Mock Server

Не все интерфейсы сводятся к REST поверх HTTP. Если система использует SOAP, полезно работать с WSDL и структурой XML-сообщений. Для двустороннего обмена могут понадобиться WebSocket или gRPC. Mock Server уместен, когда зависимый сервис ещё недоступен или нужно воспроизвести заранее определённый ответ. Однако мок подтверждает поведение вашей стороны при заданном ответе, а не реальную совместимость с работающим внешним сервисом.

Где здесь подходит Checkcraft

В настольном приложении Checkcraft для Windows HTTP-запросы создаются визуально; для ответа доступны проверки статуса, заголовков, тела и времени. JSON/XML можно проверять по путям и правилам, а значения переносить между шагами через переменные. Исходные запросы импортируются из cURL, OpenAPI/Swagger и Postman. Также заявлена работа с SOAP/WSDL, WebSocket, gRPC и Mock Server, поэтому разные способы взаимодействия можно исследовать в одном рабочем контексте.

Данные проекта по умолчанию хранятся в локальном workspace. Checkcraft сейчас находится в закрытой бета-версии: доступ предоставляется по заявке, публичной загрузки и оплаты пока нет. Это важно учитывать при планировании командного процесса — руководство описывает универсальную методику, а не обещает немедленный публичный доступ к продукту.