Запуск автотестов из DoQA

DoQA запускает пайплайн в подключённой CI-системе и собирает его результаты в прогон. Для этого пространству нужны подключение CI и привязанные CI-проекты — см. Подключение CI-систем.

Способы запуска

Сценарий	Где	Что происходит
Прогон всего набора	вкладка «Прогоны» → способ создания «Запуск автотестов»	новый прогон + пайплайн на весь набор
Запуск выбранных автотестов	«Запустить» в каталоге автотестов	новый прогон из выбранных автотестов
Запуск и перезапуск в существующем прогоне	«Запустить автотесты» и «Перезапустить автотесты» в плеере прогона	новый пайплайн по элементам прогона
Перепрохождение одного автотеста	«Перепройти» в карточке результата	новая попытка одного теста
По расписанию	настройки пространства, секция «Run schedules»	прогон создаётся по таймеру — см. Автоматика запусков
Со стороны CI	пайплайн стартует в самой CI-системе	DoQA создаёт под него прогон «Прогон из CI/CD»

Создание прогона способом «Запуск автотестов»

В окне создания прогона выберите способ «Запуск автотестов», CI-подключение, проект и ветку — поля диалога описаны в Создание прогона через запуск автотестов.

DoQA создаёт пустой прогон в статусе «В работе» и запускает пайплайн в режиме «весь набор»: пайплайн прогоняет все тесты проекта, а результаты попадают в этот прогон (в переменных пайплайна передаются ID прогона и режим — см. Переменные пайплайна). Тесты появляются в прогоне по мере поступления результатов. Когда завершается последний пайплайн, DoQA сама переводит прогон в статус «Завершен».

Запуск из каталога

Отметьте автотесты в каталоге и нажмите «Запустить» — или нажмите «Запустить» в карточке одного автотеста. Откроется диалог «Запустить выбранные»:

• CI-подключение, проект, ветка — каскадный выбор; форма предзаполняется пресетами запуска. Если CI не настроен, диалог предложит перейти к настройкам пространства.
• Порядок выполнения — список выбранных автотестов можно переупорядочить перетаскиванием; порядок сохраняется в прогоне. Рядом — бейджи управляемости порядка: у pytest порядок управляем, у surefire/gradle — частично, у остальных фреймворков — не гарантирован; при параллельном выполнении в раннере порядок не гарантируется в любом случае.
• Название прогона и конфигурация — необязательны.
• Нативный фильтр — выбор вида («Автоопределение» или конкретный вид) и живое превью выражения с предупреждениями: неоднозначный вид, непокрытые фильтром тесты, усечение. Тумблер управляет тем, передавать ли фильтр в пайплайн. Подробнее — Нативный фильтр тестов.

После запуска DoQA создаёт прогон с выбранными автотестами и открывает его. Если между выбором и запуском набор изменился (например, автотест удалён), диалог сообщит, что набор устарел, — обновите каталог и повторите.

Запуск и перезапуск из прогона

В плеере прогона с автотестами, доступными для запуска, есть кнопки «Запустить автотесты» и «Retry failed tests now»; обе активны только для прогона в статусе «В работе». «Retry failed tests now» перезапускает упавшие тесты по политике ретраев — см. Автоматика запусков.

«Запустить автотесты» открывает диалог с той же формой «подключение → проект → ветка», пресетами и — при разных последних конфигурациях выбранных автотестов — выбором режима групп. Дополнительно в диалоге два тумблера: переопределить для этого прогона критерии приёмки и политику ретраев.

Уже завершённые элементы повторно этим способом не запускаются. Для них есть кнопка «Перезапустить автотесты» на панели таблицы: выбранные завершённые элементы конвертируются в новые попытки и уходят в новый пайплайн, а прежний результат сохраняется в истории попыток.

Статус прогона при запуске из плеера не меняется — такой прогон завершите сами. Автоматически DoQA завершает прогоны, созданные самим запуском: способом «Запуск автотестов», кнопкой «Запустить» из каталога или со стороны CI.

Перепрохождение одного автотеста

В карточке результата автотеста есть кнопка «Перепройти» с двумя вариантами:

• «Автоматически» — DoQA запускает новый пайплайн ровно под этот тест: используются та же интеграция, проект и ветка, что при прошлом запуске, а в пайплайн передаётся нативный фильтр на один тест. Прежний результат не стирается — он остаётся в истории как предыдущая попытка.
• «Вручную» — результат конвертируется в ручное прохождение. Если у автотеста были шаги, они материализуются в карточке с бейджем «Шаги из авто-прохождения»; дальше тест проходится как обычный тест-кейс.

Кнопка недоступна в завершённом прогоне. Вариант «Автоматически» требует, чтобы у автотеста был связанный пайплайн: если тест ни разу не запускался через CI из DoQA, перезапускать его нечем.

Все прохождения одного теста в прогоне собираются в цепочку попыток; авторитетна последняя — именно она учитывается в статистике и критериях приёмки. Состав попытки и кнопка «Подробнее» — Результаты и разбор падений.

Прогон, созданный со стороны CI

Пайплайн может стартовать в самой CI-системе — по пушу или по расписанию CI. Чтобы результаты попали в DoQA, пайплайн вызывает POST /api/integrations/ci/create-run, передавая project-токен, ID пайплайна, ID пространства, тип CI-системы и ветку. DoQA создаёт прогон «Прогон из CI/CD», привязывает к нему пайплайн и отвечает runId; дальше пайплайн запрашивает тест-план как обычно. Если у привязки задан идентификатор подпроекта, передайте его в запросе — по нему DoQA определяет, к какой привязке относится пайплайн.

Пресеты запуска

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

• Конфигурация у всех выбранных совпадает — форма молча предзаполняется ею.
• Конфигурации разные — диалог предупреждает и предлагает выбор: одна конфигурация на всех (укажите её вручную) либо «каждый там, где запускался» — мульти-запуск по группам, доступный при не более чем 10 разных конфигурациях.
• Истории запусков нет — конфигурация подставляется из основной ветки, и только если живая привязка в пространстве ровно одна и ветка у неё задана; иначе форма остаётся пустой.

Ветка резолвится по цепочке: ветка последнего запуска → основная ветка привязки → пусто.

Несколько пайплайнов в одном прогоне

Один прогон может нести несколько пайплайнов: мульти-запуск по группам («каждый там, где запускался»), авто-ретраи и перепрохождение отдельных тестов создают дополнительные пайплайны в том же прогоне. Прогон завершается только тогда, когда не осталось ни одного активного пайплайна; пока прогон в работе и пайплайнов больше одного, в шапке плеера видна сводка вида «(2 из 3 пайплайнов завершены)».

Все пайплайны прогона перечислены на вкладке «Пайплайны» плеера: интеграция, проект, ветка, статус, времена и длительность, позиция в группе запуска (бейдж «2 из 3») и метка retry у служебных пайплайнов. Действия по строке: открыть пайплайн в CI-системе и отменить один пайплайн — прогон при этом продолжается.

Частичный старт групп не откатывается

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

Как пайплайн узнаёт, что запускать

DoQA передаёт контекст запуска переменными пайплайна. Чтобы выполнить не весь набор, а выбранные тесты, есть два механизма: нативный фильтр и тест-план по API.

Переменные пайплайна

При старте пайплайна DoQA передаёт переменные DOQA_* (способ передачи зависит от CI-системы: переменные, параметры, inputs):

Переменная	Что содержит
DOQA_SPACE_ID	ID пространства — куда слать тест-план и результаты
DOQA_TEST_RUN_ID	ID прогона DoQA, в который должны попасть результаты
DOQA_CI_RUN_ID	ID пайплайна в DoQA — для корреляции результатов, когда у прогона несколько пайплайнов; передаётся вместе с DOQA_TEST_RUN_ID
DOQA_ADAPTER_MODE	режим адаптера: 1 — прогнать весь набор, 0 — только выбранные тесты
DOQA_NATIVE_FILTER, DOQA_FILTER_KIND	выражение нативного фильтра и его вид; передаются только вместе
DOQA_TRIGGER, DOQA_SCHEDULE_ID	признак запуска по расписанию и ID расписания
DOQA_SOURCE_KEY	идентификатор подпроекта привязки
DOQA_CORRELATION_ID	служебный ключ корреляции для провайдеров, не отдающих ID пайплайна при старте

DOQA_URL и DOQA_TOKEN при запуске не передаются

Адрес DoQA и project-токен настраиваются в CI-проекте заранее — вручную или авто-настройкой переменных.

Нативный фильтр тестов

Нативный фильтр — выражение отбора тестов в «родном» синтаксисе фреймворка (например, Class#method для Maven Surefire или выражение -k для pytest). Пайплайн подставляет DOQA_NATIVE_FILTER в команду запуска тестов — и выполняются только выбранные тесты, без обращения к API.

Вид фильтра (DOQA_FILTER_KIND) — один из: surefire, gradle, pytest, gotest, playwright, phpunit, dotnet, jest. DoQA определяет его по цепочке приоритетов: принудительная настройка подключения → выбор пользователя в диалоге → префикс внешнего ID автотеста → метка фреймворка из последнего результата. Если сигналов нет или они противоречат друг другу, фильтр не передаётся — прогонится весь набор (безопасный дефолт). Ограничить состав выполнения в этом случае могут только селективный режим адаптера (DOQA_ADAPTER_MODE=0) или тест-план; если пайплайн просто загрузит полный отчёт, в прогон попадут результаты всех прогнанных тестов.

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

Тест-план по API

Второй механизм — пайплайн сам спрашивает у DoQA, что запускать:

GET {DOQA_URL}/api/integrations/ci/test-plan
    ?pipeline_id=$CI_PIPELINE_ID
    &ci_project_id=$CI_PROJECT_ID
    &space_id=$DOQA_SPACE_ID
    &token=$DOQA_TOKEN

Все четыре параметра обязательны. token — project-токен.

Ответ:

{
  "tests": [{ "id": "99" }],
  "runId": 1770,
  "isNewRun": false,
  "version": "1.0"
}

• tests — идентификаторы тестов (Allure ID связанных тест-кейсов), которые нужно выполнить;
• runId — прогон DoQA, в который уйдут результаты;
• isNewRun — true, если прогон был создан способом «Запуск автотестов», и false при запуске в существующий прогон.

Пример шага, который забирает план:

fetch_plan:
  stage: test
  script:
    - >
      curl -fsSL --get "$DOQA_URL/api/integrations/ci/test-plan"
      --data-urlencode "pipeline_id=$CI_PIPELINE_ID"
      --data-urlencode "ci_project_id=$CI_PROJECT_ID"
      --data-urlencode "space_id=$DOQA_SPACE_ID"
      --data-urlencode "token=$DOQA_TOKEN"
      -o test-plan.json
    - cat test-plan.json

Как отфильтровать тесты по этим ID — зависит от фреймворка и раннера. Без фильтрации (нативной или по тест-плану) пайплайн прогонит все тесты проекта.

Жизненный цикл пайплайна

Статус пайплайна DoQA приводит к единому набору: в очереди, выполняется, успешно, с ошибкой, отменён, пропущен, таймаут. Статус доставляется тремя путями:

• Вебхук — основной путь: CI-система сообщает о завершении, и DoQA финализирует пайплайн сразу. Требуется настроенный вебхук подключения.
• Поллинг — страховка: DoQA ежеминутно опрашивает незавершённые пайплайны старше 5 минут. Пайплайн, застрявший в очереди дольше 60 минут, закрывается со статусом таймаута; пайплайн, статус которого узнать не удалось, — как неуспешный.
• Скачивание результатов — если пайплайн завершился, а результаты тестов так и не пришли в течение 15 минут, DoQA сама скачивает артефакт с результатами из джоб пайплайна и разбирает его. Работает только для GitLab.

Когда завершается последний активный пайплайн, происходит финализация прогона: прогон, созданный самим запуском — способом «Запуск автотестов», из каталога или со стороны CI, — переводится в «Завершен» (пайплайн, запущенный в уже существующий прогон, его статус не меняет); плановые, но не выполненные автотесты помечаются пропущенными; затем отрабатывает автоматика — авто-ретраи и критерии приёмки (Автоматика запусков), кластеризация ошибок и пересчёт стабильности (Результаты и разбор падений).

Остановка прогона отменяет все его активные пайплайны, запущенные из DoQA. Отдельный пайплайн отменяется на вкладке «Пайплайны». Пользовательская остановка не считается CI-завершением: авто-ретраи и критерии приёмки на неё не реагируют.

Управление CI-джобами

У прогона с автотестами в плеере есть вкладка «Джобы CI»: список джоб пайплайна — имя, стадия, статус, длительность, ссылка. Пока вкладка открыта и есть активные джобы, список обновляется примерно каждые 15 секунд. Если у прогона несколько пайплайнов, над списком появляется селектор пайплайна (по умолчанию — активный).

Джобу можно отменить или перезапустить кнопками на строке (с подтверждением); набор доступных действий зависит от возможностей CI-системы — см. матрицу провайдеров. Для провайдера без управления джобами вкладка показывает только ссылку на пайплайн. Права на действия — те же, что на редактирование прогонов.

Таймлайны

По каждому результату автотеста доступен таймлайн запуска «от команды до отчёта» — в карточке результата. По прогонам целиком — лента «Таймлайн запусков» на вкладке аналитики автотестов дашборда.

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

• Подключение CI-систем — подключения, привязки проектов, вебхуки, переменные
• Автоматика запусков — расписания, авто-ретрай упавших, критерии приёмки прогона
• Каталог автотестов — выбор автотестов для запуска, карантин, источники
• Результаты и разбор падений — карточка результата, попытки, кластеры ошибок
• Прогоны — статусы и завершение прогона