Автотесты

Автотест появляется в DoQA только тогда, когда в систему приходят результаты его выполнения. Добавить автотест вручную нельзя.

Отдельного раздела «Автотесты» больше нет

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

Результаты попадают в DoQA тремя путями:

• загрузка файла отчета в интерфейсе — DoQA создает новый прогон;
• отправка отчета из CI утилитой doqa-cli или через API — DoQA создает новый прогон;
• запуск автотестов из DoQA в GitLab CI/CD — результаты появляются в прогоне по мере выполнения тестов.

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

Связывание автотестов с тест-кейсами

При загрузке результатов любым из способов DoQA сопоставляет автотесты, помеченные Allure ID (в сырых данных Allure это метка AS_ID), с ручными тест-кейсами пространства. Если тест-кейс с таким ID есть в этом пространстве, связь создается автоматически, и тест-кейс получает «Статус автоматизации» со значением «Автоматизирован».

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

Примечание

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

Статус автоматизации

У тест-кейса три значения «Статуса автоматизации»:

• «Ручной»;
• «Подлежит автоматизации» — пометка о том, что тест-кейс планируется автоматизировать;
• «Автоматизирован» — тест-кейс связан с автотестом.

«Автоматизирован» проставляет система при появлении связи. Вручную выбрать это значение нельзя: опция в списке заблокирована, по наведению показывается подсказка «Status is assigned by the system automatically» (на русский язык она не переведена). Чтобы разорвать связь, выберите в редакторе тест-кейса «Ручной» или «Подлежит автоматизации».

Смена «Статуса автоматизации» на любое другое значение рвет связь с автотестом. Копия тест-кейса связь не наследует: у копии связи с автотестом нет, а «Автоматизирован» заменен на «Ручной».

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

• JUnit XML — файл .xml или .zip-архив с XML-файлами;
• Allure — .zip-архив с сырыми данными allure-results.

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

Примечание

До версии DoQA 4.0 загрузка результатов автотестов осуществлялась в формате отчета, сформированного командой allure-report. Начиная с версии 4.0 DoQA обрабатывает только сырые данные Allure — сформированную тестовым фреймворком папку, которая содержит result.json и другие файлы. Достаточно поместить эту папку в .zip-архив, дополнительные действия с данными не требуются.

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

На вкладке «Прогоны» нажмите «Создать прогон», в поле «Способ создания» выберите «Загрузка отчета», укажите «Тип отчета» (JUnit или Allure) и приложите файл. Прогону можно сразу задать название, описание и теги.

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

Отправка отчета из CI через doqa-cli

Утилита командной строки doqa-cli отправляет результаты без открытия браузера. Она подходит и для локальных запусков в IDE, и для встраивания в пайплайн CI/CD (GitLab, Jenkins и др.). Результат тот же, что и при загрузке через интерфейс: в системе создается новый прогон.

Скачивание doqa-cli

• Скачать doqa-cli для Linux
• Скачать doqa-cli для Windows

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

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

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

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

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

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

Переменная	Значение (для GitLab CI)	Описание
DOQA_PIPELINE_ID	$CI_PIPELINE_ID	Уникальный ID текущего запуска
CI_PROJECT_ID	$CI_PROJECT_ID	ID проекта в вашей CI-системе
CI_BRANCH	$CI_COMMIT_REF_NAME	Название ветки, в которой запущен тест

Команда watch

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

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

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

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

test_ui:
  stage: test
  before_script:
    # 1. Скачиваем актуальную версию утилиты
    - curl -fsSL https://doqa.app/downloads/doqa-cli -o doqa-cli
    # 2. Даем права на выполнение
    - chmod +x doqa-cli
  script:
    # 3. Запускаем тесты через watch
    - ./doqa-cli 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

Что учесть:

• двойное тире (--) — обязательный разделитель: он указывает утилите, что настройки самой doqa-cli закончились и дальше начинается ваша команда;
• если тесты упадут, watch передаст код выхода обратно в CI/CD, и пайплайн пометится как «failed»;
• watch не отменяет сохранение артефактов в самом CI/CD (секция artifacts) — логи и тяжелые скриншоты остаются в вашей инфраструктуре;
• если фреймворк формирует отчеты сразу в двух форматах, JUnit XML и Allure, doqa-cli использует Allure;
• результаты отправляются по мере появления файлов, поэтому настройте фреймворк на генерацию отчетов в процессе выполнения, а не в самом конце.

Команда report

report загружает уже готовый файл или архив с результатами, когда выполнение всех тестов завершено. Используйте ее, если отслеживание в реальном времени не нужно или инфраструктура не позволяет применять watch.

./doqa-cli report [url] [spaceId] [token] [file] [type]

• url — полный адрес API вашего экземпляра. Рекомендуется использовать $DOQA_ENDPOINT/api/autotests/report.
• spaceId — ID пространства, см. Как узнать ID пространства.
• token — API-токен DoQA, см. Создание API-токена.
• file — путь к файлу отчета (XML-файл JUnit или ZIP-архив с результатами Allure).
• type — формат отчета: junit или allure.

Пример для JUnit XML:

doqa-cli report https://example.doqa.app/api/autotests/report 2 abc123 /path/to/junit.xml junit

Пример для Allure:

doqa-cli report https://example.doqa.app/api/autotests/report 2 abc123 /path/to/allure-report.zip allure

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

test_ui:
  stage: test
  script:
    # 1. Запуск тестов (генерация allure-results)
    - mvn test -Dallure.results.directory=allure-results
  after_script:
    # 2. Установка необходимых утилит (zip и curl)
    - apt-get update && apt-get install -y zip curl

    # 3. Скачивание doqa-cli
    - curl -fsSL https://doqa.app/downloads/doqa-cli -o doqa-cli
    - chmod +x doqa-cli

    # 4. Упаковка результатов в архив
    - zip -r allure-results.zip allure-results

    # 5. Отправка отчета в DoQA
    - ./doqa-cli report "$DOQA_ENDPOINT/api/autotests/report" "$DOQA_SPACE_ID" "$DOQA_TOKEN" "allure-results.zip" allure
  artifacts:
    when: always
    paths:
      - allure-results/
      - allure-results.zip
    expire_in: 1 week

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

Чтобы запускать автотесты из интерфейса, администратор должен подключить GitLab как CI/CD-систему и привязать проекты к пространству — см. Интеграции с CI/CD. Если этого не сделано, в диалоге запуска вместо списка систем будет подсказка «Для запуска автотестов из DoQA свяжите пространство с проектами из CI/CD» и кнопка «Перейти в настройки пространства».

Создание прогона через запуск автотестов

В диалоге «Создать прогон» выберите «Способ создания» → «Запуск автотестов», затем «CI/CD система», «Проект» и «Ветка».

DoQA создает пустой прогон в статусе «В работе» и запускает пайплайн. Тесты появляются в прогоне по мере того, как приходят их результаты. Когда пайплайн в GitLab завершается, DoQA переводит такой прогон в статус «Завершен» — вручную завершать его не нужно. Пайплайн, застрявший в статусе pending дольше 60 минут, закрывается как неуспешный.

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

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

Заходить в GitLab, чтобы запустить связанные автотесты, не нужно.

1. Откройте прогон. Кнопка «Запуск автотестов» видна только если в прогоне есть автотесты, доступные для запуска, и активна только для прогона в статусе «В работе».
2. Отметьте чек-боксами нужные автотесты в таблице прогона.
3. Нажмите «Запуск автотестов».
4. В диалоге выберите «CI/CD система», «Проект» и «Ветка».
5. Нажмите «Сохранить».

Если не отмечен ни один чек-бокс, будут запущены все автотесты прогона, доступные для запуска. Доступны для запуска только те автотесты, которые:

• связаны с тест-кейсом через Allure ID — сиротские автотесты из прогона запустить нельзя;
• еще не выполнялись в этом прогоне, то есть находятся в начальном статусе;
• не имеют назначенного исполнителя.

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

Статус самого прогона при запуске из плеера не меняется: DoQA не завершает его автоматически, завершите прогон сами.

Как пайплайн выбирает тесты для запуска

При старте пайплайна DoQA передает в него ровно одну переменную — DOQA_SPACE_ID. Списка тестов в переменных пайплайна нет. Чтобы запустились именно выбранные тесты, пайплайн должен сам запросить у DoQA тест-план и отфильтровать тесты по полученным Allure ID. Без этого шага прогонятся все тесты проекта.

GET {DOQA_ENDPOINT}/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 — API-токен проекта DoQA, см. Создание API-токена.

Ответ:

{
  "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_ENDPOINT/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/CD.

При перезапуске используются те же CI/CD-интеграция, проект и ветка, что и при прошлом запуске этого автотеста. DoQA сбрасывает элемент в начальный статус, очищает предыдущий результат — ошибку, Output, свойства и затраченное время — и запускает новый пайплайн. Список тестов пайплайн получает так же, через тест-план: в него попадет только перезапущенный автотест.

Кнопка недоступна, если прогон завершен, если автотест уже перезапускается или если у элемента еще нет результата. Пункт «Автоматически» не сработает для автотеста, который ни разу не запускался из DoQA: перезапускать нечего — неизвестны интеграция, проект и ветка.

Просмотр результата автотеста

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

Когда результат есть, в карточке выводятся:

• «Результаты» — заголовок ошибки и ее описание со стек-трейсом. Каждый блок можно скопировать целиком;
• «Output» — вывод теста, если он есть в отчете;
• «Комментарии и баги» — кнопки «Завести баг» и «Добавить комментарий», а также уже добавленные баг-репорты и комментарии;
• «Свойства» — таблица properties автотеста из отчета, если они были переданы.

В качестве исполнителя у автотеста указана «Автоматизация». Вкладка «История прохождения» показывает, как этот тест проходил в этом прогоне раньше, — см. История прохождения теста в прогоне.

Метрики по автотестам

Статистика по автотесту считается между прогонами — по всем попыткам этого автотеста, а не по истории связанного тест-кейса. Ручные прохождения кейса в нее не попадают. В правой панели окна прохождения выводятся:

• «Среднее время» — рассчитано на основе 10 последних попыток;
• «Успешно» — процент успешных попыток из 10 последних;
• «Последние прохождения» — 3 последних статуса с датами.

Так считается и для сиротских автотестов, и для тест-кейсов, пройденных автоматизацией. Стрелка «Перейти в историю» рядом с «Последними прохождениями» у автотестов не показывается: История запуска ведет историю тест-кейса, а не автотеста.

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

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

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

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

Отчет будет загружен в DoQA и отобразится в виде нового прогона. Об остальных методах и о доступе к Swagger — Публичный API.

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

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

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

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

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

• Прогоны — где живут результаты автотестов.
• Интеграции с CI/CD — подключение GitLab и привязка проектов к пространству.
• История запуска — в каких прогонах проходил тест-кейс и с каким результатом.