API-тесты в QA Деск — Postman, Newman, pytest и контрактные проверки интеграций

Два вида «интеграционного тестирования»

Под интеграционными тестами понимают разное. Первое — проверка API одного сервиса: коды ответов, схемы, авторизация, граничные значения. Второе — проверка обмена между системами: заказ из сайта ушёл в 1С, сделка из Битрикс24 попала в учёт, вебхук пришёл один раз, а не три. Первое почти полностью автоматизируется; второе требует сценарных кейсов и рук, потому что участвуют две команды и два релизных цикла.

QA Деск покрывает оба: автотесты API приезжают отчётами, сценарии обменов ведутся кейсами и прогоняются по стендам.

Отчёты API-автотестов

Postman-коллекция запускается Newman с репортёром JUnit:

newman run collection.json -e stage.postman_environment.json \
  -r cli,junit --reporter-junit-export reports/junit.xml

pytest с requests или httpx — --junitxml=reports/junit.xml. REST Assured под TestNG/JUnit пишет surefire-reports сам. Контрактные тесты Pact в любом языке идут через тот же раннер. Karate отдаёт JUnit из коробки.

Ключ кейса — в имени запроса Postman или тестовой функции:

QAD-C42 POST /orders — заказ создаётся с верной суммой

Загрузка:

./qadesk-cli upload --run "billing api" --env stage --platform api --build "$CI_COMMIT_SHORT_SHA" reports

--platform api отделяет эти прогоны от браузерных и мобильных в истории. Тесты без ключа не записываются и возвращаются поимённо.

Кейсы на обмены

Сценарий обмена — это кейс с шагами по обе стороны границы: «создать заказ на сайте → дождаться выгрузки → проверить документ в 1С → изменить статус в 1С → проверить статус на сайте». Такие кейсы плохо ложатся в автотесты и хорошо — в ручной прогон перед релизом любой из сторон.

Что стоит держать в библиотеке для каждого обмена:

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

Готовые наборы для обменов 1С ↔ Битрикс24 и CommerceML — в каталоге кейсов; проверки самой платформы — на страницах 1С и 1С-Битрикс.

Стенды как конфигурации прогона

Интеграционный регресс идёт на конкретной паре стендов: {stand: preprod, api_version: v2, counterpart: 1C-test}. В QA Деск это конфигурация прогона: один план — прогон на каждой паре, результат каждой строки отдельно. Так видно, что обмен работает с тестовой 1С и падает с предпродовой — и это два разных дефекта, а не один «иногда не работает».

Дефект и ошибки мониторинга

Дефект из упавшей строки наследует стенд, версию API и сборку. Ошибки обмена в проде, которые ловит Sentry, становятся дефектами без рук — Sentry. Ответ на дефект — задача разработчику в Битрикс24 или SourceCraft.

Чего в продукте нет

нет запуска коллекций и моков — QA Деск не заменяет Newman, WireMock и стенд;
нет импорта OpenAPI в скелеты кейсов — в дорожной карте;
нет проверки схем ответов — это работа автотеста, деск принимает его результат.

С чего начать

Добавьте JUnit-репортёр в задание с Newman или pytest и выгрузку с when: always.
Проставьте ключи кейсов у запросов, которые ломаются чаще всего.
Заведите кейсы на обмены по списку выше и конфигурации стендов.
Прогоните план по стендам перед ближайшим релизом любой из сторон.

Попробуйте на своём проекте

Заведите проект, загрузите первый отчёт или заведите первый дефект — бесплатный тариф без карты. Нужно демо на ваших сценариях — напишите на hello@qadesk.ru.

Создать проект

Рядом по теме

Платформы

1С-Битрикс

Сайт на 1С-Битрикс проверяется по готовому смоуку каталога и заказа, обновление ядра фиксируется в поле сборки, а ошибки прода из Sentry становятся дефектами без ручного пересказа стек-трейса.

1С-Битрикс — обновление ядра без сюрпризов на проде

Автотесты, CI и мониторинг

JUnit XML

Своего формата у QA Деск нет: подойдёт JUnit XML, который ваш раннер уже пишет. Один запрос из пайплайна — и отчёт становится прогоном с историей, покрытием и дефектами.

JUnit XML — формат, который умеет писать всё