Как Allure Framework помогает мне анализировать прохождение автотестов

Тестировщику-автоматизатору недостаточно настроить тесты. Не менее важно уметь их анализировать. И здесь пригодится Allure Framework. В этой статье я расскажу, почему это действительно хороший инструмент для анализа прохождения автотестов и на примерах объясню особенности его использования.

Что такое Allure Framework

Это достаточно гибкий инструмент для создания отчетов. Он дает много информации о прохождении тестов, чем упрощает анализ их результатов.

Allure Framework имеет несколько преимуществ:

• Подробные сценарии выполнения тестов. Это позволяет создавать тесты, соответствующие особенностям проекта.
• Агрегация тестов на основе тегов. Такой функционал упрощает работу по аналитике и поиск нужной информации.
• Широкие возможности интеграции. Allure Framework можно объединять с тестовыми фреймворками и использовать с разными языками программирования.
• Автоматическое распределение дефектов тестов и продукта. Это позволяет уменьшить жизненный цикл багов.
• Вариативность настроек. Предоставляет много средств для настройки под свои предпочтения.
• Бесплатный фреймворк. Это, пожалуй, одно из самых главных достоинств на фоне многих платных фреймворков и других инструментов по подписке.

Allure универсален — он поддерживает работу с Jasmine, JUnit, Spock, TestNG и другими фреймворками, список которых постоянно пополняется. Но в рамках статьи я ограничусь примерами из JUnit 4, как одного из самых популярных.

В чем польза использования Allure

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

При этом вы можете исследовать другие детали: историю выполнения тестов, их распределение по категориям, информацию об окружающих, использованные инструменты и т.д.

У Allure доступен широкий выбор графиков. Например, можно скачать статус прохождения теста, чтобы узнать процент удачно выполненных тестов и соотношение фейлов или дефектов кода. Или другой пример – распределять тесты по категориям, скажем, на дефекты продукта и дефекты теста. Относительно последнего прописывать что-то дополнительно не нужно — Allure все сделает сам.

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

Как запустить Allure Framework

Для начала подключаем нужные зависимости и настраиваем плагин:

Следующий шаг – делаем прогон тестов, после которого в папке target появится папка allure-results. В ней будут размещаться созданные файлы с результатами тестов. А далее для получения отчета достаточно использовать команды allure:report:

Отчет можно сделать более простым и понятным или «апгрейдить» по своему вкусу. Для этого используйте инструкции:

• Step – для выделения отдельных методов, как шагов. Это должно быть атомарное действие или проверка.
• Attachment – ​​дополняет основную аннотацию и предоставляет дополнительную информацию. Если метод что-то возвращает, вы получите, например, скрин или возвращаемый текст. Поэтому не нужно проверять код или разбираться, где и что лежит на сайте. Все отобразится в отчете.
• DisplayName и Description помогают делать тесты более уникальными. Согласитесь, не удобно, когда у тестов схожие названия каждого метода. С помощью инструкции DisplayName можно предоставить каждому тесту удобное и понятное имя. А Description позволит кратко описать тест: что вы ожидаете в результате, какие данные вводятся.
• Story и Feature – разделяют тесты по функционалу или пользователю страницы.

Как настроить Allure

Для подключения фреймворка используются соответствующие зависимости.

В этом примере мне также понадобился отдельно настроенный плагин, чтобы не приходилось загружать дополнительные файлы. Это можно сделать в Maven.

На этом шаге у меня произошла любопытная ошибка. Maven не видел Allure, которое я загружала в проект. Вместо него сборщик загружал другой, указанный по дефолту. Так могло быть из-за неправильно добавленных зависимостей. Но у меня ситуация иная, потому я и нашла довольно оригинальное решение.

Благодаря этому плагин видит нужную версию и источник загрузки. Как вы можете увидеть на иллюстрации ниже, в структуре проекта нет Allure. Но после запуска allure:report он сам его загрузит и сформирует отчет:

Переходим к аннотациям. DisplayName, расположенная перед классом, будет указывать на название отдельного сьюта. Это поможет быстрее сформулировать класс или сгруппировать классы по одному сьюту. Аннотация Feature сформирует его по отдельному функционалу:

Также есть аннотация DisplayName для отдельного тестового метода, благодаря которой все тесты будут носить уникальное название. Это дополняет описание того, что мы хотим или не хотим видеть и группировка по User Story.

Существуют и другие аннотации в методах, которые что-либо проверяют или возвращают. Например, я использовала Step и Attachment. Первая инструкция необходима для разделения шагов, выполняющих тест, и фиксации этого в отчете. Вторая — применяется там, где я что-то возвращаю. В приведенном примере возвращается текст в отчете:

После такой подготовки можно запустить процесс.

Однако хочу акцентировать внимание на другом. Здесь есть папка allure-results , где находятся результаты прохождения тестов и отдельные файлы, в которые мы вернули необходимые данные.

Сразу после прохождения тестов можно не заметить папки из Allure. Поэтому нужно скачать его с помощью команды allure:report.

Поначалу Maven пытается найти Allure, но после неудачной попытки переходит к загрузке.

В результате появляется папка с необходимой именно нам версией фреймворка.

Далее — переходим в папку site, в которой находится нужный файл:

Формируем отчет в Allure Report

Открываем файл и видим общую информацию: о наличии трех тест-кейсов; о том, что они прошли хорошо, что есть разделение по сьюту.

Также здесь можно узнать наличие степов. К примеру, если в нашем тесте был один Step, то он один и будет отображаться. Видим и Attachment, который мы получили в этом тесте.

Также есть графики, которые показывают, что все прошло хорошо. Критичность тестов нормальна:

Кроме этого, можно узнать, сколько времени потрачено на прохождение теста. В нашем случае два теста прошли примерно через секунду.

Один тест длился три секунды.

То же можно увидеть на вкладке Timeline. Тесты запускались последовательно, потому это оформлено как прямая линия. Но если бы был параллельный запуск, вид графика был бы иным. Как видите, первый тест длился дольше всего.

А два других прошли быстрее.

В разделе Behaviors есть разделения по Feature и User Story. Я указывала отдельно одну строчку на два теста и другую строчку на третью — чтобы наглядно показать, как фреймворк их разделяет. Но если бы я указывала другой класс с той же Feature Annotation , здесь был бы еще один класс, но с другой User Story.

Обратите внимание: в блоке Trend – пусто. Это логично на данном этапе. Сам по себе Trend показывает график выполнения тестов, их историю. Для заполнения блока и формирования тренда нужно пройти несколько шагов. Для автоматизации этого процесса я разработала небольшой скрипт, о котором расскажу немного позже.

Общая же идея проста: в target формируется папка site, открывающая отчеты. А в ней располагается папка history, которая и будет основой для Trend.

Для того чтобы сформировать тренд не пустым, нужно пересобрать отчет. Он формируется на основе allure-results. Как можно увидеть на иллюстрации, здесь нет ни одной history, потому и Trend пуст.

Следует просто перенести сюда нужную папку.

Она будет сохраняться, а мы сможем сформировать отчет заново.

И получим заполненный Trend.

Как Allure работает с ошибками в тестах

Но давайте честно: наш отчет неинтересен! Все зеленое, ничего не сломалось, информации мало. Надо что-нибудь сломать. При этом для демонстрации распределения по категориям я создала бы сразу две проблемы. К примеру, один тест будет искать текст, которого нет на странице:

Другой тест попытается обратиться к неправильному локатору:

Как отмечалось выше, можете автоматизировать создание трендов. Для этого я написала скрипт. Когда тесты пройдут и появится сообщение о проблемах, этот скрипт автоматически перенесет history папку в нужное место.

Теперь при обнаружении ошибок в отчете уже гораздо интереснее:

В общей информации сообщается о трех тест-кейсах и трех различных результатах. Один тест упал, один — прошел нормально, последний — сломан.

Много изменений во вкладке Trend. Здесь показано разделение с количеством запусков и графиком падения тестов.

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

Есть также тест, который упал, потому что не нашел соответствующего текста.

Больше информации теперь имеется и в графиках:

Видим распределение по категориям. Как видно дальше, в одном тесте был дефект продукта, в другом — дефект самого теста.

Также есть тренд со временем прохождения всех тестов, а не каждого в отдельности. Из этого можно заключить: первый запуск длился чуть более 6 секунд, а второй — почти 6 секунд.

Критичность является нормальной, потому что не было указано дополнительной информации.

В таймлайне указано, что один запуск состоялся 5 минут назад, а другой — только что. Теперь можно узнавать, когда именно что-то пошло не так.

Чтобы сравнение было максимально полным, можно починить все проблемы и заново запустить тесты. Теперь в отчете все прошло хорошо. При этом на графиках видно, что в одном запуске все сломалось, но в последнем снова все в норме.

Также можно обратиться к истории отдельных тестов, где показаны все изменения: нормальное прохождение тестов, выявление проблемы и снова все ОК.

Аналогичные данные есть и о перезапусках, и их результатах.

Такая же картинка и в другом блоке: прохождение, падение, снова прохождение. Видим еще и уровень успеваемости тестов: 3 из 4. И это всего лишь часть возможностей Allure. Вы можете гибко настраивать инструмент под себя и добавлять больше аннотаций, чтобы получать нужную вам информацию.

Как интегрировать Allure с Jenkins

После интеграции этих инструментов в меню Jenkins появится кнопку Allure Report. Она вызывает именно тот отчет, который показан выше.

Allure реализован как плагин: достаточно найти его, скачать и установить:

Далее в конфигурациях Jenkins отрегулируйте Commandline. При желании можете указать, откуда должен загружаться Commandline. Хотя и так все должно работать корректно.

После этого в проекте в Post Build Actions нужно настроить и собрать Allure Report.

Тогда увидите Trend и кнопку Allure Report для открытия отчета.

И, наконец, результаты тестов можно получать непосредственно в Jenkins.

Когда откроете отчет, там будет собрана вся нужная вам информация:

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

В случае любых вопросов по работе Allure Framework советую обращаться к двум основным источникам:

• Официальная документация
• Репозиторий на Github. Здесь вы можете пообщаться с разработчиками фреймворка или читать как другие пользователи решали те или иные проблемы. Уверена, с Allure Framework вы всегда найдете оптимальное решение.