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

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

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

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

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

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

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

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

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

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

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

На скриншоте: 1 — CI/CD-подключение, 2 — проект, 3 — ветка, 4 — порядок запуска (перетаскивание).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На скриншоте: 1 — карточка пайплайна, 2 — таблица джоб.

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

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 определяет его по цепочке приоритетов. Побеждает первый сработавший:

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

Фильтр либо передаётся целиком, либо не передаётся вовсе

Частичного фильтра не бывает: выражение либо адресует все выбранные автотесты, либо не формируется совсем. Переменные DOQA_NATIVE_FILTER и DOQA_FILTER_KIND при этом не передаются, а пайплайн выполняет весь набор проекта: лучше полный прогон, чем молча потерянный тест. Запуск при этом не отклоняется: прогон создаётся, автотесты в него материализуются, ответ содержит nativeFilter: null и список автотестов, которые фильтр адресовать не смог.

Фильтр не передаётся, когда:

формат отчёта определить не удалось: сигналов нет;
в наборе смешаны тесты разных фреймворков;
хотя бы один автотест невыразим в этом формате: у него нет достоверного имени раннера, а отображаемое имя (заголовок из @DisplayName, @allure.title, docstring) селектором не является — по нему раннер не нашёл бы ни одного теста;
выражение получилось длиннее 2048 символов;
тумблер нативного фильтра в диалоге запуска выключен.

Ограничить состав выполнения в этих случаях могут только селективный режим адаптера (DOQA_ADAPTER_MODE=0) или тест-план. На состав прогона это не влияет: у запуска выбранных автотестов и у запуска из плеера набор пайплайна известен DoQA, поэтому результаты тестов вне набора отбрасываются при приёме — лишние прогнанные тесты в прогон не попадут. Прогон, созданный способом «Запуск автотестов» или со стороны CI, набора не имеет и принимает все результаты пайплайна.

Формат, выбранный в диалоге, — подсказка, а не гарантия

Если выбранный в диалоге формат не подходит части набора (например, выбран pytest, а среди выбранных есть JVM-тесты), запуск не отклоняется: вместо выборочного выполняется полный прогон по правилу выше. Диалог запуска показывает это заранее: в превью фильтра видно, будет ли фильтр передан, какие автотесты он не покрывает и откуда взят формат.

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

Куда подставлять выражение

DOQA_NATIVE_FILTER несёт значение выражения без имени флага. Флаг добавляет сам рецепт пайплайна:

Формат	Раннер	Как подставить
`surefire`	Maven Surefire/Failsafe	`mvn test -Dtest="$DOQA_NATIVE_FILTER"`
`gradle`	Gradle	`gradle test $DOQA_NATIVE_FILTER` — без кавычек
`pytest`	pytest	`pytest -k "$DOQA_NATIVE_FILTER"`
`gotest`	go test	`go test ./... -run "$DOQA_NATIVE_FILTER"`
`phpunit`	PHPUnit	`phpunit --filter "$DOQA_NATIVE_FILTER"`
`dotnet`	dotnet test / VSTest	`dotnet test --filter "$DOQA_NATIVE_FILTER"`
`playwright`	Playwright	`npx playwright test -g "$DOQA_NATIVE_FILTER"`
`jest`	Jest	`npx jest -t "$DOQA_NATIVE_FILTER"`

Для gradle кавычки вокруг переменной ломают запуск

Только у gradle переменная несёт не одно значение, а готовый фрагмент аргументов — --tests com.acme.LoginTest.login --tests com.acme.CartTest.add. В кавычках оболочка передаст его Gradle одним аргументом, и разбор сломается («Unknown command-line option»). Пишите $DOQA_NATIVE_FILTER без кавычек. У остальных форматов кавычки, наоборот, обязательны: выражения содержат |, (, ), ^, $ и пробелы.

Тест-план по 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-токен.

Ответ:

json

{
  "tests": [],
  "runId": 1770,
  "isNewRun": false,
  "version": "1.0",
  "autotests": [
    {
      "autotestId": 17,
      "externalId": "pytest:tests/test_login.py::test_valid",
      "name": "test_valid",
      "allureId": 99,
      "selector": "tests.test_login#test_valid"
    },
    {
      "autotestId": 24,
      "externalId": "pytest:tests/test_logout.py::test_session",
      "name": "test_session",
      "allureId": null,
      "selector": "tests.test_logout#test_session"
    }
  ],
  "incomplete": true
}

tests — устаревший способ адресации: по Allure ID связанных тест-кейсов. Самостоятельный автотест (без связи с ручным кейсом) в этом поле выразить нечем. Если этот список беднее реального набора (incomplete: true), DoQA отдаёт tests: []. Пустой список прямо означает «этим полем набор не выражается», а по усечённому списку молча выполнился бы не тот набор;
autotests — полный набор пайплайна. externalId адресует автотест независимо от того, есть ли у него связанный кейс (allureId: null — самостоятельный автотест), а selector — полное имя теста в том же виде, которым пользуется нативный фильтр (null, если достоверного имени у автотеста нет). Новые рецепты строят план по autotests[];
incomplete — true, когда набор нельзя адресовать целиком: часть строк без Allure ID либо часть автотестов без достоверного selector. Рецепт, который умеет фильтровать только по Allure ID, в этом случае обязан либо перейти на autotests[], либо прогнать весь набор целиком, иначе выбранные тесты молча не выполнятся;
runId — прогон DoQA, в который уйдут результаты;
isNewRun — true, если прогон был создан способом «Запуск автотестов», и false при запуске в существующий прогон.

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

yaml

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, временами и действиями «Открыть пайплайн в CI» и «Отменить пайплайн». По умолчанию открыт активный пайплайн, а если активных нет — самый свежий; выбранный пайплайн остаётся в адресной строке, поэтому ссылкой можно поделиться. Пока раздел открыт и работа в CI идёт, срез обновляется примерно каждые 15 секунд.

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

Таймлайны

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фильтр либо передаётся целиком, либо не передаётся вовсе ​

Куда подставлять выражение ​

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

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

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

Таймлайны ​