Отправка результатов автотестов

Автотесты выполняются в вашей инфраструктуре (в CI/CD или локально), а в DoQA отправляются их результаты. Рекомендуемый способ — адаптер тестового фреймворка: он отправляет результаты сам, без файлов отчётов. Эта страница — про остальные способы, на случай, когда адаптера под ваш фреймворк нет: файл отчёта через интерфейс, утилита doqactl и report-API. Из результатов DoQA создаёт прогон или дополняет существующий.

Выбор способа

Способ	Когда подходит
Адаптер тестового фреймворка	рекомендуется: результаты уходят прямо из тестового процесса, с шагами, вложениями и привязкой к кейсам, без файлов отчётов
Autotest API	собственный адаптер, когда готового под ваш фреймворк нет
doqactl watch	фреймворк без адаптера: утилита запускает тесты в пайплайне и отправляет результаты по ходу прогона
doqactl upload	отчёт уже собран — отправить одной командой из CI или с локальной машины
report-API	то же, что `upload`, но прямым HTTP-запросом, без утилиты
Загрузка отчёта в интерфейсе	разовая загрузка готового файла отчёта, например после локального прогона

Поддерживаемые форматы отчётов

JUnit XML — файл .xml или .zip-архив с XML-файлами. Внутри архива обрабатываются только файлы *.xml; архив без единого валидного XML отклоняется.
Allure — .zip-архив с сырыми данными: файлы *-result.json, а рядом с ними *-container.json добавляют фикстуры (setup и teardown). Имя каталога внутри архива значения не имеет: DoQA считает архив Allure-отчётом, если в нём есть хотя бы один файл с именем, которое оканчивается на result.json. Поэтому подходят и каталог results (так пишут адаптеры DoQA), и allure-results (стандартное имя Allure).

Размер одного файла при любом способе загрузки отчёта — не больше 50 МБ.

Сырые данные, а не готовый отчёт

DoQA обрабатывает только сырые данные Allure — папку с *-result.json и другими файлами, которую формирует тестовый фреймворк. HTML-отчёт, собранный командой allure generate, не принимается. Достаточно упаковать папку результатов в .zip-архив, дополнительные действия с данными не требуются.

Форматы не равнозначны. Allure богаче: шаги и фикстуры со статусами и длительностью, параметры, вложения (скриншоты, видео, логи), реальное время старта и окончания. JUnit XML несёт только базовый результат: статус, длительность, ошибку и вывод теста.

Файл вложения больше 100 МБ в хранилище не попадает: результат теста обрабатывается как обычно, а в его карточке появляется предупреждение «Вложения не приняты: N». Лимит настраивает администратор сервера. Это отдельное ограничение от 100 МБ на сумму вложений одного результата в doqactl watch. Оба верны одновременно, но это разные лимиты (второй описан в doqactl).

Метки DoQA в отчёте

Через метки в отчёте автотест сообщает о себе дополнительные данные. В Allure это метки (labels), в JUnit XML — элементы <property> внутри <properties>; имена регистронезависимы. Булевы значения принимаются в виде 1/true/yes/on и 0/false/no/off.

Метка / property	Что задаёт
`doqa_external_id`, `doqa_id`	внешний ID автотеста; если переданы обе, побеждает `doqa_external_id`
`as_id`, `allure_id`	привязка к одному тест-кейсу — способ совместимости, см. Переезд с Allure
`doqa_cases`, `doqa_work_items`	привязка к нескольким тест-кейсам — список ID через запятую
`doqa_title`	заголовок автотеста в каталоге
`doqa_namespace`, `doqa_package`	место автотеста в дереве каталога
`doqa_class`, `doqa_classname`	класс автотеста
`doqa_runner_name`, `doqa_runner_method`	имя и метод автотеста в раннере; по ним DoQA определяет формат отчёта источника
`doqa_create_manual_case`	завести связанный ручной тест-кейс для этого автотеста (только в Allure — в JUnit XML такого поля нет)
`tag`	тег автотеста; несколько меток `tag` собираются в список, а не перетирают друг друга
`package`, `packageName`	запасной путь: место в дереве каталога, если нет `doqa_namespace`/`doqa_package`
`testClass`, `className`, `suite`	запасной путь: класс автотеста, если нет `doqa_class`/`doqa_classname`
`testMethod`, `methodName`	запасной путь: метод в раннере, если нет `doqa_runner_method`

Остальные пары имя-значение попадают в свойства результата; doqa_create_manual_case и tag туда не дублируются. Что означают внешний ID и привязка к тест-кейсам — Автотесты.

Загрузка отчёта через интерфейс

На вкладке «Прогоны» нажмите «Новый прогон» — откроется диалог «Создать прогон».
В поле «Способ создания» выберите «Загрузка отчета». По умолчанию выбран «Стандартный», третий вариант — «Запуск автотестов».
Укажите «Тип отчета»: «JUnit» (значение по умолчанию) или «Allure».
Приложите файл, ровно один, не больше 50 МБ. Второй файл диалог не примет.
Задайте название прогона — оно обязательно. При необходимости добавьте описание, теги и конфигурации.
Нажмите «Сохранить».

DoQA создаёт прогон с результатами из отчёта. Подробнее о полях диалога — Создание прогона на основе отчёта о результатах автотестов.

Отправка отчёта из CI через doqactl

Утилита командной строки doqactl (прежнее имя — doqa-cli, сохранено как алиас файла) отправляет результаты без открытия браузера. Её берут, когда под фреймворк нет адаптера или проект тестов править нельзя: утилита работает с любым фреймворком, который умеет писать JUnit XML или Allure. Результат тот же, что при загрузке через интерфейс: в системе появляется прогон с результатами. Полный список команд, флагов и переменных, а также разбор ошибок — на странице doqactl. Здесь — только то, что нужно для отправки отчёта.

Скачивание doqactl

bash

curl -fsSL https://doqa.app/downloads/doqactl -o doqactl
chmod +x doqactl

Прежняя ссылка https://doqa.app/downloads/doqa-cli тоже работает: под этим именем лежит копия того же бинаря, чтобы не менять уже настроенные пайплайны. Установка под другие ОС — doqactl → Установка.

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

Создайте переменные в настройках вашего CI/CD (например, Settings > CI/CD > Variables в GitLab или Actions Secrets в GitHub). Для токена используйте режим маскирования (Masked).

DOQA_URL — адрес вашего экземпляра DoQA, например https://company.doqa.app.
DOQA_TOKEN — API-токен DoQA, см. Создание API-токена.
DOQA_SPACE_ID — ID пространства, см. Как узнать ID пространства.

Прежние имена продолжают работать

Раньше адрес задавался переменной DOQA_ENDPOINT, а пространство — DOQA_SPACE. Утилита читает и их. У каждого параметра есть и более приоритетный синоним (DOQA_API_BASE для адреса, DOQA_CI_TOKEN для токена). Полный порядок приоритета (флаг > переменная > файл ~/.doqactl.yaml) — в doqactl → Общая конфигурация.

Для GitLab эти три переменные DoQA заводит в проекте сама, кнопкой «Настроить CI/CD Variables» в карточке источника, см. Подключение CI/CD.

Переменные окружения читают все команды doqactl, кроме устаревшей команды report: ей адрес, токен и файл передаются позиционными аргументами (пространство может браться и из --space/DOQA_SPACE_ID/конфига).

Чтобы связать запуск в CI с пайплайном в DoQA, передайте в конфигурации пайплайна:

Переменная	Значение (для GitLab CI)	Описание
DOQA_PIPELINE_ID	$CI_PIPELINE_ID	Уникальный ID текущего запуска. Не обязательна, но без неё результаты будут отправлены в отдельный прогон: по ней DoQA узнаёт прогон, который сама запустила этим пайплайном
CI_PROJECT_ID	$CI_PROJECT_ID	ID проекта в вашей CI-системе
CI_BRANCH	$CI_COMMIT_REF_NAME	Название ветки, в которой запущен тест. Заводить не обязательно: утилита сама берёт ветку из стандартных переменных CI (`CI_COMMIT_REF_NAME` в GitLab, `GITHUB_REF_NAME` в GitHub Actions, `GIT_BRANCH`/`BRANCH_NAME` в Jenkins). Значение `DOQA_BRANCH` старше всех остальных

Для CI-систем без встроенной переменной пайплайна (Jenkins, TeamCity и другие) — полный список того, как doqactl определяет пайплайн, в doqactl → Как определяется CI-система и пайплайн.

Если пайплайн запускает DoQA

DOQA_SPACE_ID заводить вручную нужно только для сценария, когда пайплайн стартует сам, по коммиту или расписанию. Когда пайплайн запускает DoQA, она передаёт DOQA_SPACE_ID в переменные пайплайна сама, и значение из DoQA перекрывает то, что задано в настройках CI.

Команда watch

watch запускает вашу тестовую команду, а по мере появления результатов отправляет их в DoQA: каждый результат уходит отдельным запросом, и прогон наполняется, не дожидаясь конца пайплайна. Алиас команды — stream. По DOQA_PIPELINE_ID утилита получает у DoQA прогон для этого пайплайна. Если пайплайн запущен из DoQA, это существующий прогон — тогда watch сам запрашивает и применяет тест-план, см. Запуск автотестов из DoQA. Если пайплайн стартовал сам, watch заводит новый прогон.

bash

./doqactl watch -- [команда запуска ваших тестов]

Всё, что идёт после двойного тире (--), воспринимается утилитой как исходная команда для запуска тестов.

Пример этапа тестирования в .gitlab-ci.yml. В примере это Maven со стандартным выводом результатов в директорию allure-results; для другого фреймворка меняются только команда запуска и каталоги результатов:

yaml

test_ui:
  stage: test
  before_script:
    # 1. Скачиваем актуальную версию утилиты
    - curl -fsSL https://doqa.app/downloads/doqactl -o doqactl
    # 2. Даем права на выполнение
    - chmod +x doqactl
  script:
    # 3. Запускаем тесты через watch
    - ./doqactl watch -- mvn -B -Dallure.results.directory=allure-results test
  artifacts:
    when: always
    paths:
      - allure-results
      - target/surefire-reports/junitreports/
    reports:
      junit:
        - target/surefire-reports/junitreports/TEST-*.xml
    expire_in: 1 week

Что учесть:

двойное тире (--) — обязательный разделитель: он указывает утилите, что настройки самой doqactl закончились и дальше начинается ваша команда;
если тесты упадут, watch передаст код выхода обратно в CI/CD, и пайплайн пометится как «failed». Если тестовая команда прошла, а результаты не доставлены — код выхода 2 и список причин в логе;
перед запуском watch чистит каталоги отчётов, чтобы не отправить результаты прошлой сборки; отключается флагом --no-clean;
watch не отменяет сохранение артефактов в самом CI/CD (секция artifacts) — логи и тяжёлые скриншоты остаются в вашей инфраструктуре;
по умолчанию результаты ищутся в каталогах allure-results, target/allure-results (Allure) и target/surefire-reports, surefire-reports (JUnit XML); другой корень поиска задаётся флагом --results-dir, точный каталог — флагом --result;
если фреймворк формирует отчёты сразу в двух форматах, JUnit XML и Allure, doqactl использует Allure; принудительно выбрать формат можно флагом --report-type allure или --report-type junit.

Полный список флагов и разбор крайних случаев (недоставленные результаты, отказ DoQA, вложения, порядок с тест-планом) — doqactl → Команда watch.

Команда upload

Отправить уже готовый отчёт одной командой, когда отслеживание в реальном времени не нужно или инфраструктура не позволяет применять watch (например, после локального прогона). Команда принимает файл, ZIP-архив или каталог (архивирует на лету — отдельно паковать не нужно), сама определяет формат отчёта и не требует полного URL, только базовый адрес DoQA.

bash

./doqactl upload [флаги] <файл-или-каталог>

аргумент — ровно один: файл (*.xml JUnit или *-result.json Allure), ZIP-архив или каталог результатов;
--type — формат отчёта: auto (по умолчанию, определяется по имени файла), allure или junit;
--title — название прогона; без него прогон получит служебное название;
лимит запроса — 50 МБ.

Пример для Allure:

bash

./doqactl upload --pipeline-id "$CI_PIPELINE_ID" allure-results/

Без --pipeline-id отчёт уйдёт в отдельный прогон

Загрузка отчёта не принимает DOQA_TEST_RUN_ID: отчёт адресуется только идентификатором пайплайна. Без --pipeline-id (или DOQA_PIPELINE_ID) результаты будут отправлены в новый прогон, а прогон, запущенный из DoQA, останется пустым. Команда предупреждает об этом в логе.

Пример шага в .gitlab-ci.yml:

yaml

test_ui:
  stage: test
  script:
    # 1. Запуск тестов (генерация allure-results)
    - mvn test -Dallure.results.directory=allure-results
  after_script:
    # 2. Скачивание doqactl
    - curl -fsSL https://doqa.app/downloads/doqactl -o doqactl
    - chmod +x doqactl

    # 3. Отправка отчёта в DoQA — upload архивирует каталог сам
    - ./doqactl upload --pipeline-id "$CI_PIPELINE_ID" allure-results
  artifacts:
    when: always
    paths:
      - allure-results/
    expire_in: 1 week

Устаревшая команда report (позиционные аргументы, отправка на явный URL) тоже работает: старые пайплайны менять не обязательно. Она всегда создаёт новый прогон и не умеет адресовать результаты в прогон, запущенный из DoQA.

bash

./doqactl report "$DOQA_URL/api/autotests/report" "$DOQA_SPACE_ID" "$DOQA_TOKEN" "allure-results.zip" allure

Полный список флагов upload, восстановление контекста пайплайна из doqa-reporting.properties и устаревший синтаксис report — doqactl → Команда upload и doqactl → Устаревшая команда report.

Загрузка результатов через API

Воспользуйтесь методом POST /api/autotests/report. Логин и пароль для него не нужны: метод авторизуется API-токеном проекта.

Укажите API-токен проекта в поле «token» (цифра 1).
Выберите формат отчёта — JUnit XML или Allure (цифра 2).
Выберите файл (цифра 3).
При необходимости введите имя прогона (цифра 4).
Укажите ID пространства DoQA (цифра 5).
Подтвердите отправку запроса.

DoQA загружает отчёт и показывает его новым прогоном. Если дополнительно передать поле pipelineId с ID пайплайна, запущенного из DoQA, результаты попадут в прогон этого запуска, а не в новый. Форма принимает и остальные поля: branch, system, sourceKey, correlationId, externalId, workItemIds, schemaVersion. Если у пространства несколько CI-подключений, sourceKey обязателен: без него DoQA не знает, к какому подключению относится отчёт, и отклоняет его. Тексты ошибок — doqactl → Частые ошибки. Об остальных методах и о доступе к справочнику API — Публичный API.

Не путайте этот метод с POST /api/autotests/results: тот принимает не файл отчёта, а отдельные результаты от адаптеров — см. Autotest API.

Создание API-токена

Перейдите в настройки администратора, раздел «Проекты». Выберите проект из списка и откройте вкладку «API-токены». Создайте токен: им можно загружать отчёты об автотестах в любое пространство этого проекта. Нужны права администратора.

Результаты автотестов принимаются только по токену проекта, которому принадлежит пространство. Личный токен доступа из профиля пользователя эти методы не принимают, токен другого проекта отклоняется — тексты ошибок в doqactl → Частые ошибки.

Как узнать ID пространства

Откройте нужное пространство в браузере. В адресе страницы .../detail/1/2/cases второе число (2) — это ID пространства.

Смотрите также

Адаптеры для тестовых фреймворков — отправка результатов прямо из тестового процесса, без файлов отчётов
Автотесты — внешний ID, пути доставки результатов, связь с тест-кейсами
Утилита doqactl — полный список команд, флагов, переменных окружения и текстов ошибок
Autotest API — прямое API для собственного адаптера
Прогоны — куда попадают результаты автотестов

Отправка результатов автотестов ​

Выбор способа ​

Поддерживаемые форматы отчётов ​

Метки DoQA в отчёте ​

Загрузка отчёта через интерфейс ​

Отправка отчёта из CI через doqactl ​

Скачивание doqactl ​

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

Команда watch ​

Команда upload ​

Загрузка результатов через API ​

Создание API-токена ​

Как узнать ID пространства ​

Отправка результатов автотестов

Выбор способа

Поддерживаемые форматы отчётов

Метки DoQA в отчёте

Загрузка отчёта через интерфейс

Отправка отчёта из CI через doqactl

Скачивание doqactl

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

Команда watch

Команда upload

Загрузка результатов через API

Создание API-токена

Как узнать ID пространства