Делюсь опытом сборки нового Allure 3, он и в beta уже очень хорош.

Статья синьорская, пишу кратко

Цель как обычно: дать команде максимум полезной информации по тестам на одной странице.

В большинстве случаев команде нужно:
✅ Результат авто тестов, 👨‍💻 Результат ручных тестов, 📋 Список непокрытых фич

Обычно все это лежит в разных окружениях (Pipeline, TMS, GIT), все зависит от команды.
Также у каждой команды своя группировка и свой состав отчетов, поэтому стандартные отчеты из CI уже не канают.

Решение — Перейти с Allure 2 на Allure 3

Для начала посмотрите доклад по Allure 3

Лучше всего сделать rest-сервис в котором будет собираться отчет. Я так делал для Allure 2 и отчета по тестовому покрытию
Почему: скорее всего у вас разные источники данных и куча git репозиториев, а команда любит ходить по одной и той же красивой ссылке на дейлике

В rest сервисе должны быть простые POST запросы, они вызываются из пайплайна после запуска автотестов

Создать отчет
Залить результаты автотестов из пайплайна
Добавить результаты ручных тестов из TMS
Сверху добавить спецификацию (скорее всего у вас gherkin) — если команда ее ведет.
Собрать отчет по определенному конфигу.

Образец конфига лучше взять в официального сайта, киллер-фича в нем, на мой взгляд, фильтрация:

👉 https://github.com/allure-framework/allure3/blob/main/allurerc.mjs

🔥 Важно №1: Лейблы — наше всё

Без атрибутов тестов — будет каша. Эти метки должны проставляться везде: и в автотестах, и в ручных кейсах, и сохраняться при выгрузке из TMS или пайплайна.

Мой минимум: Owner, Team, Product, Feature, Story, Title, Component
Не обязательно: Severity, Priority, Type, ParentSuite, Suite, SubSuite
Type опционален потому что его сервис может проставить сам

🔥 Важно №2: Рабочий костыль отчета покрытия

У тебя есть спецификация продукта (Gherkin и прочее) и ты хочешь видеть в отчете непокрытые сценарии? Делай так:

Если у теста есть лейбл Story, файл для Allure надо задублировать файл с лейблом Type=Spec.
Когда публикуешь спецификацию из Gherkin, создавай результаты тестов со статусом Skipped и лейблом Type=Spec. Делай это только если теста с такими атрибутами в каталоге нет
В итоге в отчете непокрытые Сценарии будут отображаться как тесты со статусом Skipped — очень наглядно

В конфиге

product: {
            import: "@allurereport/plugin-awesome",
            options: {
                singleFile: false,
                reportLanguage: "en",
                reportName: "By Product",
                charts: chartLayout,
                groupBy: ["Product", "Component", "Phase"],
                filter: ({ labels }) => !labels.some(({ name, value }) => name === "Type" && value === "Spec"),
            }
        },
coverage: {
            import: "@allurereport/plugin-awesome",
            options: {
                singleFile: false,
                reportLanguage: "en",
                reportName: "Product Coverage",
                charts: chartLayout,
                groupBy: ["Product", "Component", "Feature"],
                filter: ({ labels }) => labels.find(({ name, value }) => name === "Type" && value === "Spec"),
            }
        },

⚠️ Что пока не взлетело:

Environments — проще сделать еще один отчет с группировкой.
History — с отображением истории прогонов у меня был какой-то баг в большом количестве тестов в одной из команд, недавно вышла beta 16, там еще не смотрел.

В целом — инструмент уже рабочий и очень мощный.
Всем командам отчеты легко "продал", Allure2 и отдельные отчеты по покрытию закопал
Стоит пробовать.

Если будут вопросы по настройке — пишите сюда: https://t.me/sharkov_qa/12

P.S. Про SpecBox

На последнем Гейзенбаге представили еще один отчёт о покрытии тестами SpecBox:

🔹SpecBox
✅ Описание спецификации в yaml понравилось, гибче чем gherkin, возможно когда-то перейдем.
❌ Поднял сам сервис, проверил, пока очень сырой. Не хватает стабильности и удобства для работы, так что Allure3 победил

Собираем отчет Allure 3