Если вы используете Allure, то знаете: отчёты могут быть разными: с фильтрами, деревом фич, ссылками на баги, а могут быть унылой простынёй из сотен тестов без смысла и структуры.
Всё зависит от того, как вы помечаете тесты. Allure даёт мощную систему аннотаций, и если её использовать с умом — отчёт превращается в полноценный инструмент для анализа и коммуникации.
Ниже 6 уровней аннотаций, которые помогают держать тестовую базу в порядке. Без перегруза — только то, что действительно работает.
Таблица аннотаций Allure по уровням
№ |
Уровень |
Зачем нужен |
Что использовать |
|---|---|---|---|
1 |
Глобальная структура отчёта |
Формирует дерево: подсистема → модуль |
|
2 |
BDD-структура |
Показывает логику: фича → сценарий |
|
3 |
Важность теста |
Определяет приоритет и критичность |
|
4 |
Ответственность |
Кто за это отвечает |
|
5 |
Классификация |
Для фильтров, запуска, анализа |
|
6 |
Интеграции и ссылки |
Связь с багами, документацией, TMS |
|
Расшифруем:
1. Глобальная структура
Сюда идут parentSuite, suite, subSuite. Это просто: на каком уровне находится тест. Например:
Payments→CreditCardTests→NegativeCases
Такое дерево делает отчёт читаемым. Особенно, если тестов много.
2. BDD-структура
Здесь уже логика продукта:
epic: большая функциональность (например, "Authentication")feature: часть эпика (например, "Login")story: конкретный юзер-кейс (например, "Valid login via email")
Если используете BDD или просто хотите, чтобы бизнес понимал, что проверяется — сюда.
3. Важность (severity)
Показывает, насколько критичен тест:
BLOCKER: прям must-haveCRITICAL,NORMAL,MINOR,TRIVIAL— дальше по шкале
Можно запускать только важные тесты, отслеживать падения и видеть, где действительно все плохо.
4. Ответственность
Кто починит упавший тест?
Аннотация @Owner("ivanov") говорит — вот этот человек.
А @Label(name = "lead", value = "petrov") — можно указать тимлида или команду.
Очень удобно, особенно в большой команде.
5. Классификация
Для всего остального:
@Tag("smoke"),@Tag("regression")@Label("framework", "JUnit")@Label("language", "java")
Можно фильтровать тесты, запускать нужные группы, отсекать лишнее.
6. Интеграции
Привязка теста к багам, задачам и документации:
@Issue("BUG-123")— баг из JIRA@TmsLink("TMS-456")— тест-кейс из TestRail или Qase@Link(name = "Docs", url = "https://...")— например, ссылка на требования
Allure сам превращает это в кликабельные ссылки — удобно!
Зачем всё это?
Без аннотаций |
С аннотациями |
|---|---|
Хаос в отчёте |
Структура по модулям и логике ( |
Неясно, кто чинит тест |
Ответственный ( |
Все тесты одинаково важны |
Есть приоритет ( |
Трудно выбрать нужные тесты |
Теги, фильтры ( |
Никакой связи с багами и документацией |
Прямые ссылки ( |
Вывод
Allure — мощный инструмент, если использовать его возможности. Эти 6 уровней аннотаций:
добавляют структуру,
экономят время при анализе падений,
помогают команде понимать, что тестируется и зачем.
Немного внимания к меткам — и ваш отчёт будет говорить сам за себя.
Комментарии (3)
gexter
23.07.2025 19:13Хорошая статья в помощь, как мне кажется, новичку. Хотелось бы еще увидеть комплексные примеры: как выглядит код, отчеты, если использовать все рекомендации из статьи.
SofiAQA Автор
23.07.2025 19:13В разных языках программирования использование меток Allure отличается. Например:
В Java с JUnit 5 используется аннотация
@Tag, которая в отчёте Allure отображается как label.В Python с pytest применяется
@allure.label('tag', 'значение')или@allure.tag('значение')— здесь тоже формируются метки, но синтаксис другой.
Универсального подхода нет, все примеры нужно конкретизировать — всё зависит от языка и фреймворка. В ближайшее время постараюсь сделать отдельные статьи с комплексными примерами для разных случаев. Спасибо за ценный фидбэк!
kompilainenn2
Картинок бы для иллюстрации полезности