Документация TMS DoQA

Тема

Автоматика запусков ​

DoQA умеет запускать автотесты по расписанию, автоматически перезапускать упавшие и оценивать итог прогона по критериям приёмки (Quality Gate). Все три механизма настраиваются на уровне пространства и выключены, пока вы их не включите.

Где настраивается ​

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

СекцияЧто настраивает
«Run schedules»расписания запусков автотестов
«Auto-retry»автоматический перезапуск упавших автотестов
«Quality Gate»критерии приёмки прогона

Активная секция синхронизирована с адресом страницы (параметр ?section=), поэтому ссылку на конкретную настройку можно отправить коллеге. Страница доступна пользователям с правами на настройки пространства; без права изменения формы открываются только на чтение.

Расписания запусков ​

Расписание запускает пайплайн автотестов во внешней CI-системе по таймеру — менять конфигурацию CI не нужно. Понадобится настроенное подключение CI с привязанным проектом.

Создание расписания ​

Нажмите «New schedule» и заполните форму:

  • «Name» — имя расписания.
  • Где запускать: CI-подключение → проект → ветка. Все три поля обязательны; если подключения ещё нет, кнопка перехода к настройкам внутри формы переключит вас на секцию «CI/CD connections».
  • «Environment» — метка окружения, которая присваивается прогонам расписания (например, staging).
  • «Run title template» — шаблон названия прогона; поддерживаются плейсхолдеры {name}, {date}, {time}.
  • «Repeat» — периодичность: «Daily» (время), «Weekly» (время и «Days of week»), «Interval» («Every N hours», от 1 до 23) или «Cron expression» — cron-выражение из 5 полей: минута, час, день, месяц, день недели (например, 0 3 * * 1-5).
  • «Timezone» — таймзона расписания; по умолчанию — зона вашего браузера.
  • «If the previous run is still active» — поведение при пересечении с ещё идущим прогоном этого расписания: «Skip this tick (recommended)» — пропустить срабатывание, «Start in parallel» — запустить параллельный прогон.
  • «Override quality gate for scheduled runs» и «Override auto-retry for scheduled runs» — свои критерии приёмки и политика перезапусков для прогонов этого расписания вместо настроек пространства.
  • «Enabled» — новое расписание создаётся выключенным; не забудьте включить его.

Под формой DoQA показывает «Next 5 runs» — пять ближайших срабатываний с учётом таймзоны. Минимальный интервал между срабатываниями — 10 минут, лимит — 20 расписаний на пространство (значения по умолчанию, настраиваются администратором сервера).

Что происходит при срабатывании ​

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

Примечание

Сбои расписания копятся: после 10 сбоев подряд (значение по умолчанию) расписание автоматически выключается, а DoQA присылает уведомление. Сбоем считаются ошибка запуска и недоступность CI-подключения; пропуск из-за ещё идущего прогона — нет.

Список и история срабатываний ​

В списке расписаний: «Name», «Schedule» — периодичность и таймзона, «Next run» — следующее срабатывание (только у включённых), «Last status» — итог последнего срабатывания, тумблер «Enabled» и действия:

  • «Run now» — запустить расписание немедленно. Если запуск невозможен, DoQA покажет предупреждение «Not started: …» с причиной.
  • «Trigger history» — история срабатываний: «Planned for», «Status», «Run», «Error». Статусы: «Triggered» — прогон запущен (кнопка «Open run» ведёт в него), «Skipped — previous run active», «Skipped — integration unavailable», «Failed». История хранится 90 дней (по умолчанию).
  • «Edit» и «Delete» — изменить или удалить расписание.

Авто-ретрай упавших автотестов ​

Политика авто-ретрая перезапускает упавшие автотесты силами DoQA — без изменений в пайплайне. По умолчанию выключена. Поля секции «Auto-retry»:

ПолеСмысл
«Enable auto-retry of failed tests»включить политику
«Max retry attempts»число дополнительных попыток на тест, от 0 до 10; 0 — перезапусков нет
«Delay between attempts, sec»пауза перед перезапуском — даёт окружению восстановиться
«Retry only tests with tags»перезапускать только тесты с этими тегами; пусто — любые упавшие
«Never retry these cases»исключения: id кейса или внешний ID автотеста
«Fail the pipeline if all retries fail»если попытки исчерпаны, а тесты так и не прошли — прогон проваливается

Как работает перезапуск ​

  1. Пайплайн прогона завершается; DoQA отбирает упавшие и сломанные автотесты (по последней попытке каждого).
  2. Набор фильтруется по тегам и исключениям политики.
  3. DoQA запускает новый пайплайн только на эти тесты — с нативным фильтром, как при запуске выбранных. Если задана задержка, перезапуск откладывается на указанное время.
  4. Цикл повторяется, пока тесты не пройдут или не исчерпается «Max retry attempts»; жёсткий потолок — 10 попыток.

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

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

Каждая попытка сохраняется отдельно: список попыток, итог по последней и отметка «Passed after retry» описаны в Результатах и разборе падений. Retry-пайплайны видны на вкладке «Пайплайны» прогона с меткой «retry».

Политику можно переопределить для отдельного прогона в диалоге дозапуска автотестов (см. Запуск автотестов из DoQA). В плеере прогона есть кнопка «Retry failed tests now» — вручную перезапустить упавшие прямо сейчас; она работает только при включённой политике.

Критерии приёмки прогона (Quality Gate) ​

Quality Gate — декларативные критерии «прогон прошёл / не прошёл» поверх результатов автотестов. Пока гейт не настроен, прогоны ведут себя как обычно. Критерии секции «Quality Gate»:

КритерийСмысл
«Enable Quality Gate»включить гейт
«Minimum success rate, %»минимальная доля успешных тестов
«Maximum failures»максимально допустимое число упавших
«Minimum tests count»защита от полупустого прогона: выполнено меньше тестов — гейт провален
«Maximum duration, sec»максимальная длительность прогона
«Required environments»прогон должен покрыть все перечисленные окружения: непокрытое окружение проваливает гейт, а прогон без данных об окружениях получает вердикт «Missing data»
«Fast fail (stop on first violation)»остановить проверку на первом нарушении
«Block turning to green via retry»прогон не может пройти гейт, если его тесты прошли только после авто-ретрая

Какие результаты учитываются ​

  • только автотесты и только последняя попытка каждого;
  • пропущенные и ещё не обработанные результаты не входят в знаменатель;
  • исключаются автотесты в карантине (см. каталог) и падения, скрытые известными проблемами кластеров (см. кластеры ошибок).

Уровни настройки ​

Гейт пространства применяется ко всем CI-прогонам. Для отдельного прогона его можно переопределить в диалоге дозапуска автотестов, для прогонов расписания — тумблером «Override quality gate for scheduled runs».

Внимание

Override заменяет гейт пространства целиком, а не дополняет его: критерии, не заданные в override, не проверяются. То же относится к override политики авто-ретрая.

Вердикт в прогоне ​

Гейт оценивается автоматически после завершения каждого пайплайна прогона; при включённом авто-ретрае — после того, как отработали перезапуски. Вердикт виден в шапке прогона (бейдж) и в панели «Quality Gate result»:

  • статус: «Gate passed», «Gate failed» или «Missing data»;
  • «Violated criteria» — нарушенные критерии в формате «Criterion» / «Expected» / «Actual»;
  • «Evaluated metrics» — фактические метрики прогона;
  • кнопка «Evaluate now» — пересчитать вердикт вручную по последнему завершённому пайплайну.

«Missing data» означает, что оценивать нечего: например, ни один тест не зачтён при заданном числовом критерии или прогон не передал окружения при заданных «Required environments». По умолчанию такой вердикт тоже считается блокирующим.

Провал гейта «красит» прогон: в списках и лентах он показывается как проваленный. Статус пайплайна, полученный от CI-системы, DoQA при этом не переписывает.

Проверка вердикта из пайплайна ​

Джоба пайплайна может запросить вердикт гейта у DoQA: GET /api/integrations/ci/quality-gate-check, аутентификация project-токеном (см. Подключение CI-систем). По умолчанию метод отвечает 200 со статусом вердикта; администратор сервера может включить режим, в котором блокирующий вердикт возвращает 422 (переменная CI_QG_CHECK_HTTP_FAIL) — тогда джобу можно завершать с ошибкой обычным curl -f.

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