| -Allure Report — инструмент для красивой и структурированной отчетности по автотестам. Он показывает test suites, test -cases, steps, attachments, history, duration, labels, severity, owners и trend по запускам. Allure не делает тесты -качественными сам по себе, но помогает быстрее понять, что сломалось и где искать причину. +Allure Report — open-source инструмент для визуализации результатов автотестов. Он преобразует структурированные данные +о прогоне в интерактивный HTML-отчет с тестами, шагами, длительностью, ошибками, attachments, labels, историей и +аналитикой. + +Allure не запускает тесты и не заменяет Playwright, Cypress, Jest, Vitest или другой test runner. Между test runner и +Allure обычно работает adapter или reporter, который записывает результаты в понятном Allure формате. + + |
| + +Упрощенный процесс: + +1. Test runner запускает автотесты. +2. Allure adapter получает события test runner: начало и завершение тестов, ошибки, steps, labels и attachments. +3. Adapter записывает структурированные файлы в каталог `allure-results`. +4. Allure CLI читает результаты и генерирует HTML-отчет, обычно в каталоге `allure-report`. +5. Отчет открывают локально или публикуют как CI artifact либо статический сайт. + +Сбор результатов и генерация HTML-отчета — два отдельных этапа. + + |
| + +`allure-results` содержит исходные данные, созданные adapter во время выполнения тестов: test result files, containers, +attachments, environment и другие metadata. + +`allure-report` — готовый HTML-сайт, сгенерированный из этих результатов. Его можно открыть в браузере, сохранить как +artifact или опубликовать на web server. Удаленный отчет можно сгенерировать заново, если сохранен `allure-results`. |
| + +Steps разбивают тест на понятные действия: открыть страницу, заполнить форму, отправить запрос, проверить результат. Они +помогают увидеть, на каком этапе произошла ошибка и сколько времени занял каждый этап. + +Steps должны описывать бизнес-действия или значимые технические операции. Слишком мелкие steps создают шум, а один step +на весь тест не помогает локализовать проблему. + + |
| + +Attachment — файл или данные, связанные с тестом либо step. Для E2E-теста полезно сохранять screenshot, video, +Playwright trace, browser console logs и network logs. Для API-теста — request, response, headers и server logs. Для +visual regression — actual, expected и diff images. + +Attachments должны помогать расследовать падение без повторного запуска. Нельзя публиковать access tokens, пароли, +cookies, персональные данные и другие секреты: их нужно удалять или маскировать. + + |
| -Failed обычно означает, что проверка поведения не прошла: ожидали одно, получили другое. Broken чаще означает ошибку -самого теста или инфраструктуры: exception в setup, некорректный selector, timeout окружения, ошибка fixture или -неподнятый backend. Разделение помогает понять, это дефект продукта или проблема тестового слоя. +`failed` обычно означает, что assertion не прошел или проверяемое поведение не соответствует ожиданию. `broken` чаще +означает ошибку самого теста или инфраструктуры: exception в setup, ошибка fixture, timeout окружения или неподнятый +backend. + +Точное преобразование ошибок в `failed` и `broken` зависит от конкретного adapter. |
| + +Общий принцип одинаковый: + +1. Установить совместимый с test runner Allure adapter или reporter. +2. Подключить его в конфигурации test runner. +3. Указать каталог для результатов. +4. Запустить тесты и проверить, что появились result files и attachments. +5. Сгенерировать или открыть отчет через Allure CLI. +6. В CI сохранить результаты и готовый отчет как artifacts либо опубликовать отчет. + +Конкретные package names и options зависят от test runner и версии интеграции. + + |
| @@ -372,11 +457,71 @@ Failed обычно означает, что проверка поведения - flaky tests и нестабильные suites; - самые медленные тесты; - падения по feature, story, owner, severity и tag; -- история конкретного теста; -- attachments: screenshots, videos, traces, logs, request и response. +- история конкретного теста. + +Метрики нужны для решений: что чинить первым, где замедление и какие тесты перестали защищать продукт. + + |
| + +Labels позволяют искать, фильтровать и группировать тесты: -Метрики нужны не для красивого dashboard, а для решений: что чинить первым, где замедление и какие тесты перестали -защищать продукт. +- `epic`, `feature`, `story` описывают продуктовую иерархию; +- `owner` показывает ответственную команду или человека; +- `severity` отражает критичность сценария; +- `tag` добавляет классификацию, например `smoke`, `regression` или `payments`. + +Labels полезны, когда они стабильны и связаны с реальной структурой продукта. + + |
| + +Для trends Allure должен получить history data предыдущего отчета при генерации следующего. Поэтому CI pipeline обычно: + +1. Загружает history предыдущего отчета или artifact. +2. Добавляет эти данные к результатам нового запуска способом, который поддерживает используемая версия Allure. +3. Генерирует новый отчет. +4. Сохраняет новый отчет и его history для следующего запуска. + +Если CI job всегда начинается с чистого workspace и history не восстанавливается, отчет покажет только текущий запуск. + + |
| + +Allure должен стабильно идентифицировать один и тот же test case между попытками и запусками. Обычно идентификатор +зависит от framework, полного имени теста, параметров и metadata. + +Если постоянно менять title, suite или параметры, Allure может воспринимать тест как новый, и история разорвется. Retry +может быть временным safety net, но не должен маскировать нестабильность теста. + + |
| + +Каждый worker или CI job генерирует свою часть Allure results. После выполнения shards результаты собирают в один +каталог, а отчет генерируют один раз из объединенного набора. + +Обычно отдельный aggregate job скачивает artifacts всех shards, объединяет result files и запускает генератор. Важно не +потерять attachments и не перезаписать файлы результатами другого worker. |
| + +Полезный порядок: + +1. Проверить status, error message и stack trace. +2. Найти последний успешный step. +3. Открыть screenshot, trace, video и logs. +4. Сравнить environment, параметры и test data. +5. Посмотреть retries и историю теста. +6. Проверить, падают ли соседние тесты по той же причине. +7. Определить класс проблемы: product, test, data, environment или infrastructure. + +Allure собирает признаки в одном месте, но инженер все равно должен проверить гипотезу и локализовать причину. |
| + +Allure Report не заменяет: + +- test runner и сами автотесты; +- корректные assertions и test design; +- CI/CD pipeline; +- code coverage; +- логи приложения и observability; +- issue tracker и процесс triage; +- test management систему, если команде нужны test plans и manual cases. + +Красивый отчет не исправляет flaky tests, слабые проверки или отсутствие важных сценариев. + + |
| + +Метрики отчета можно использовать как один из сигналов: количество failed и broken tests, pass rate, критичные сценарии, +длительность или рост нестабильности. Но merge или release gate должен опираться на надежные machine-readable +результаты, а не только на HTML-страницу. + +Нельзя автоматически блокировать релиз по любой нестабильной метрике без анализа причин: flaky tests и ошибки +инфраструктуры могут остановить разработку. + + |
| + +Отчет и attachments могут содержать URL, headers, cookies, tokens, персональные данные, содержимое форм, screenshots +внутренних систем и stack traces. Перед публикацией нужно маскировать секреты, ограничивать доступ и задавать срок +хранения artifacts. + +Особенно внимательно нужно проверять automatic request/response attachments: они часто сохраняют больше данных, чем +ожидает автор теста. + + |