Allure установка на windows

Содержание
  1. Allure-framework. Часть 1
  2. Немного общего
  3. Подключение Allure к Maven-проекту
  4. Allure-Junit4
  5. Allure-Junit5
  6. Allure-Testng
  7. Получение исходных файлов для сборки html-отчета
  8. Сборка html-отчета на локальной машине
  9. Сборка html-отчета на Jenkins
  10. Краткий обзор страниц отчета
  11. Allure — фреймворк от Яндекса для создания простых и понятных отчётов автотестов [для любого языка]
  12. Погодите, вы сделали еще один Thucydides?
  13. Как мы это сделали?
  14. Allure-Framework. Работа с кодом
  15. Шаг теста. Определение и аннотация @Step
  16. Вывод информации в отчет при выполнении шагов теста. Вложения
  17. Прикрепление вложений с помощью аннотации @Attachment
  18. Прикрепление вложений с помощью статического метода addAttachment класса Allure
  19. Другие аннотации Allure
  20. Аннотация @Description
  21. Аннотации функциональности
  22. Аннотация @Flaky
  23. Аннотации ссылок на тест-кейсы и дефекты
  24. Аннотации прочих ссылок
  25. Аннотация @Owner
  26. Аннотация @Severity
  27. Параметризованные автотесты в Allure
  28. Категории дефектов. Распределение дефектов по категориям
  29. Тестовое окружение. Блок ENVIRONMENT на главной странице отчета
  30. Заключение

Allure-framework. Часть 1

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

Allure-framework успешно применяется в работе автоматизатора функционального тестирования в программе ЕФС и значительно упрощает разбор результатов тестовых прогонов.

В нашей первой статье мы расскажем, что такое Allure, для чего он нужен и как его подключить к вашему проекту. Также мы рассмотрим сборку самого отчета – как на локальной машине, так и с помощью Jenkins. И проведем обзор всех страниц отчета.
Поехали!

Немного общего

Каждый ИТ-специалист, который сталкивался с автоматизацией тестирования, скорее всего разбирал результаты тестовых прогонов. Чем больше вы автоматизируете регрессионную модель, тем больше автотестов появляется в вашем проекте, следовательно, вы или ваш коллега из функционального тестирования тратите больше времени на анализ отчетов.

Allure Framework – популярный инструмент построения отчётов автотестов, упрощающий их анализ. Это гибкий и легкий инструмент, который позволяет получить не только краткую информацию о ходе выполнения тестов, но и предоставляет всем участникам производственного процесса максимум полезной информации из повседневного выполнения автоматизированных тестов.

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

Тест-менеджерам Allure дает общее представление о работоспособности проекта, позволяет понять, какие фичи проекта покрыты тестами, как сгруппированы дефекты, каков общий тренд качества проекта.

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

Подключение Allure к Maven-проекту

Для разных тестовых фреймворков вам потребуются разные адаптеры. Рассмотрим некоторые из них.

Allure-Junit4

Данный адаптер позволяет собирать информацию из тестов, разработанных с использованием фреймворка Junit4. Для подключения адаптера необходимо модифицировать pom.xml вашего проекта. В секцию properties добавляем:

В секцию dependencies добавляем:

Также необходимо модифицировать (или создать) секцию build следующим образом:

Allure-Junit5

Данный адаптер позволяет собирать информацию из тестов, разработанных на Junit5. Для подключения адаптера необходимо модифицировать pom.xml вашего проекта. В секцию properties добавляем:

В секцию dependencies добавляем:

Также необходимо модифицировать (или создать) секцию build следующим образом:

Примечание
Из-за утечки памяти в Surefire 2.20 и проблем запуска на Java 9 разработчики Junit5 рекомендуют использовать Surefire версии 2.21.0

Allure-Testng

Данный адаптер позволяет собирать информацию из тестов разработанных на TestNG. Для подключения адаптера необходимо модифицировать pom.xml вашего проекта. В секцию properties добавляем:

В секцию dependencies добавляем:

Также необходимо модифицировать (или создать) секцию build следующим образом:

Получение исходных файлов для сборки html-отчета

Сборка html-отчета на локальной машине

Для сборки html–отчета необходима утилита, которая называется allure–commandline. Получить отчет можно несколькими способами:

Способ 1:
1. Скачать последнюю версию allure–commandline по ссылке;

2. Распаковать архив;

3. Добавить путь до директории bin из распакованного архива в системную переменную окружения.

Чтобы убедиться в корректности установки, выполните в командной строке команду

Должно появиться сообщение вида:

После этого должен сформироваться сам html–отчет, который откроется в браузере по умолчанию автоматически.

Способ 2 (рекомендуемый):
1. Добавить в pom.xml вашего проекта allure-maven плагин. Для этого модифицируем секцию build следующим образом:

2. Убедиться, что автотесты, по которым вы хотите получить отчет, уже выполнены (прогнать тесты можно командой mvn clean test) и в папке «target» вашего проекта присутствует «allure-results» с исходными для построения отчета файлами.

3. Выполнить команду

mvn allure:serve

После этого должен сформироваться сам html–отчет, который автоматически откроется в браузере.

Сборка html-отчета на Jenkins

Для сборки html–отчета на Jenkins необходимо установить Allure Plugin для вашего Jenkins (на данном этапе Jenkins должен быть уже развернут, настроен Job, прогоняющий ваши тесты, а результаты прогонов должны складываться в Workspace вашего Job).

Установка Allure plugin:

1. Перейти в Manage Jenkins → Manage Plugins
2. Перейти на вкладку Available
3. В поле filter набрать Allure plugin
4. Отметить чекбокс найденного Allure plugin и нажать Install without restart

Установка Allure Commandline:

Читайте также:  Maxthon браузер для windows vista

Рассмотрим вариант установки Allure Commandline на машине, имеющей доступ к Maven central.
1. Перейти в Manage Jenkins → Global Tool Configuration
2. В блоке Allure Commandline нажать кнопку Add Allure Commandline
3. В поле Name вписать наименование Allure Commandline, например, Allure 2.6.0
4. Выбрать версию библиотеки, которая будет выкачана из Maven central, например, 2.6.0
5. Нажать кнопку Save

Конфигурация Job для сборки отчета:

1. Перейти в конфигурацию своей Job
2. В разделе Post-build Actions нажать кнопку Add post-build action → Allure Report
3. В поле Results указать путь до директории «allure-results» с исходными для построения отчета файлами: target/allure-results
4. Нажать кнопку Save

После выполнения всех настроек запустите свою джобу. После ее выполнения в блоке Build History напротив номера сборки появится значок Allure, кликнув по которому, вы увидите сформированный html-отчет:

Краткий обзор страниц отчета

1. Страница «Overview».

Overview является главной страницей Allure-отчета. Она имеет блочную структуру. Рассмотрим блоки, присутствующие на главной странице по умолчанию:

1. Блок ALLURE REPORT. Включает в себя дату и время прохождения теста, общее количество прогнанных кейсов, а также диаграмму с указанием процента и количества успешных, упавших и сломавшихся в процессе выполнения тестов.

2. Блок TREND. Показывает тренд прохождения тестов от сборки к сборке.

3. Блок SUITES. Показывает распределение результатов тестов по тестовым наборам. В данном случае тесты были распределены по пакетам.

4. Блок ENVIRONMENT. Показывает тестовое окружение, на котором запускались тесты. Данная информация попадает в отчет из специального файла, расположенного в проекте.

5. Блок CATEGORIES. Показывает распределение неуспешно прошедших тестов по видам дефектов.

6. Блок FEATURES BY STORIES. Показывает распределение тестов по функционалу, который они проверяют.

7. Блок EXECUTORS. Показывает исполнителя текущей сборки. Если выполнение производилось на инструменте CI (например, на Jenkins), то будет предоставлена информация о джобе и номере сборки.

2. Страница «Categories».

Данная страница предоставляет информацио о распределении дефектов по их видам.

На данной странице представляется стандартное распределение выполнявшихся тестов по тестовым наборам или классам, в которых находятся тестовые методы.

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

5. Страница «Timeline».

В случае запуска тестов в параллельном режиме:

Данная страница визуализирует временные рамки прохождения каждого теста.

6. Страница «Behaviors».

На данной странице тесты сгруппированы по проверяемому функционалу (Epic, Feature, Story).

7. Страница «Packages».

На этой странице тесты сгруппированы по пакетам, в которых лежат тестовые классы.

Источник

Allure — фреймворк от Яндекса для создания простых и понятных отчётов автотестов [для любого языка]

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

Я вижу здесь сразу несколько проблем: ручные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам; ручные тестировщики не знают, что именно покрывается автотестами; автоматизаторы тратят время на разбор отчётов. Как ни странно, но все три проблемы вытекают из одной: результаты выполнения тестов понятны только автоматизаторам — тем, кто эти тесты писал. Именно это я и называю непрозрачностью.

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

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

Погодите, вы сделали еще один Thucydides?

Если кратко, то да. И Thucydides действительно отличный инструмент, позволяющий решить проблему прозрачности, но… Мы активно использовали его в течение года и выявили несколько «родовых травм» — проблем, несовместимых с жизнью в тестировании Яндекса. Вот основные:

Как мы это сделали?

Проблема первая: тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам.

Решение этой проблемы давно существует и хорошо себя зарекомендовало. Речь идет об использовании DSL для описания тестов с последующим преобразованием в естественный язык. Этот подход применяется в таких широко известных инструментах, как Cucumber, FitNesse или уже упомянутый Thucydides. Даже в юнит-тестах принято называть тестовые методы таким образом, чтобы было понятно, что именно проверяется. Так почему не использовать тот же подход для тестов функциональных?

Для этого мы ввели в наш фреймворк понятие тестового шага, или степа, — простого действия пользователя. Соответственно, любой тест превращается в последовательность таких шагов.

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

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

Читайте также:  Planoplan editor для windows x64

Кроме того, к любому шагу можно прикрепить произвольное число произвольных вложений. Это могут быть как уже привычные всем скриншоты, куки или HTML-код страницы, так и более экзотические: заголовки запросов, дампы ответов или серверные логи.

Проблема вторая: тестировщики не знают, что именно покрывается автотестами.

Если мы генерируем на основе кода тестов отчёт об их выполнении, то почему бы не дополнить такой отчёт сводной информацией о тестируемой функциональности? Для этого мы ввели понятия feature и story. Достаточно разметить тестовые классы при помощи аннотаций, и эти данные автоматически попадут в отчёт.

Как видите, для автоматизатора затраты минимальны, а на выходе — информация, которая полезна уже не только тестировщику, но и менеджеру (или любому другому человеку из команды).

Проблема третья: автоматизаторы тратят время на разбор отчётов.

Теперь, когда результат выполнения тестов понятен всем, осталось сделать так, чтобы при падении теста было совершенно ясно, в чем проблема: в приложении или в коде теста. Эта задача уже решена в рамках любого тестового фреймворка (JUnit, NUnit, pytest и др.). Существуют отдельные статусы для падения после проверки (по assert, статус failed) и для падения из-за возникшего исключения (статус broken). Нам оставалось только поддержать эту классификацию при построении отчёта.

Также на скриншоте выше видно, что есть еще статусы Pending и Canceled. Первый показывает исключенные из запуска тесты (аннотация @Ignore в JUnit), второй — тесты, пропущенные в рантайме из-за падения предусловия (assume failure). Теперь тестировщик, читающий отчёт, сразу понимает, когда тесты нашли баг, а когда нужно попросить автоматизатора поправить тесты. Это позволяет запускать тесты не только во время предрелизного тестирования, но и на более ранних стадиях и упрощает последующую интеграцию.

Источник

Allure-Framework. Работа с кодом

Шаг теста. Определение и аннотация @Step

Для визуализации процессов, протекающих в ваших тестах, необходимо использовать шаги. Шаг должен представлять какое-то атомарное действие или проверку. Собственно последовательность шагов и представляет ваш тест. Для наглядности в шаге должны быть описаны входные параметры, а также ожидаемый и фактический результат, если шаг представляет собой проверку.

В Allure для обозначения тестового шага над методом необходимо проставить аннотацию @Step. Затем необходимые шаги-методы включаются в тело тестового метода: тесты с аннотацией @Test.

Создадим метод с аннотацией @Step, который проверяет соответствие суммы двух слагаемых ожидаемому результату:

Теперь создадим тестовый метод, использующий данный шаг:

При прогоне данного автотеста мы получим следующий отчет:

Аннотация @Step умеет принимать параметр «value», который позволяет указывать имя шага на русском языке. Кроме того, имя шага можно параметризировать – передать в него значения аргументов, передающихся в шаг.

Продемонстрируем на примере

При использовании данного шага в тесте получим отчет:

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

Вывод информации в отчет при выполнении шагов теста. Вложения

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

Вложения могут иметь 4 характеристики:

• value/name — наименование вложения;
• type — тип информации в соответствии со стандартом MIME;
• content — содержимое вложения;
• fileExtension — опциональное расширение файла вложения, начинающееся с точки.

Вложения к отчету можно прикреплять 2 способами: с помощью аннотации @Attachment и с помощью статического метода addAttachment класса Allure.

Прикрепление вложений с помощью аннотации @Attachment

В данном способе создается метод, возвращающий массив байтов, над ним размещается аннотация @Attachment. При использовании данного метода считанная информация будет добавлена в отчет в виде файла с соответствующим расширением. Наименование вложения будет таким же, как и имя вызываемого метода.

Продемонстрируем на примере

Создадим метод, который будет зачитывать вложение:

Создадим тестовый шаг, который будет использовать данный метод:

Ну и наконец напишем тест, в котором будет использоваться наш шаг:

В результате прогона данного теста получим отчет:

В аннотации @Attachment можно задавать дополнительные уточняющие параметры:

При использовании данного метода в своих шагах attachment получит наименование «Вложение», содержимое вложения подсветится в соответствии с шаблоном «json», а само вложение будет сохранено в формате «.txt»:

Если поменять тип на «plain/text», то никакой характерной для json-style подсветки ключей-значений уже не будет:

Также можно поэкспериментировать с fileExtension, например, указать «.doc». В этом случае вложение будет сохранено в формате, характерном для MS Word ’97.

Прикрепление вложений с помощью статического метода addAttachment класса Allure

В данном способе можно прикрепить вложение к шагу теста/тесту, используя перегруженный статический метод addAttachment из класса Allure. В этот метод можно передавать до 4 аргументов — 2 из них обязательны (имя вложения и сам прикладываемый контент), 2 опциональны (расширение файла и MIME-тип).

Несмотря на то, что MIME-типы необходимо указывать довольно часто, их приходится прописывать «вручную». В поставку Allure не входит класс с константами допустимых типов.

Другие аннотации Allure

Кроме наиболее известных аннотаций @Step и @Attachment, Allure в своем составе имеет целый ряд других аннотаций:

Аннотация @Description

@Description — аннотация, размещаемая над тестом или шагом. Позволяет прикрепить описание к тесту или шагу теста. Данная аннотация может принимать параметры «value» — текст описания и «useJavaDoc». При установке значения «true» последнему параметру, в качестве описания будет браться джавадок, размещенный над методом.

Читайте также:  Gp50nb41 драйвер для установки windows 7

Приведем пример использования данной аннотации

Аннотации функциональности

Аннотации @Epic/Epics, @Feature/Features, @Story/Stories можно отнести к аннотациям функциональности. Данные аннотации группируют тесты по функциональности в разделе Behaviors(Функциональность) Allure-отчета.

Приведем пример использования данных аннотаций

При выполнении тестов и последующем формировании отчета, в разделе Behaviors мы увидим, что тесты сгруппированы в многоуровневый список (@Epic → @Feature → @Story):

Аннотация @Flaky

@Flaky — аннотация, размещаемая над тестом. Позволяет пометить автотест как нестабильный. Если автотест падает хотя бы в одном перезапуске (например, папка «target» между прогонами одного и того же теста не очищается) — в отчете на данном тесте вы увидите знак бомбы. Кроме того, данной аннотацией можно помечать классы с нестабильными тестами.

Приведем пример использования данной аннотации

Обратите внимание, что ветвления в тестах делать не стоит: в данном случае блок if — else используется лишь для того, чтобы сделать тест нестабильным!

При нескольких прогонах теста в режиме перезапуска отчет примет следующий вид:

Аннотации ссылок на тест-кейсы и дефекты

@Issue — аннотация, размещаемая над тестом. Позволяет линковать автотесты с заведенными Issue. Данная аннотация принимает параметр «value», в котором указывается ID дефекта в баг-треккинговой системе.

@Issues — тоже самое, что и @Issue, но в качестве параметра «value» принимает массив Issue.

@TmsLink — аннотация, размещаемая над тестом. Позволяет линковать автотесты с тестовыми кейсами, шаги которых описаны в системах управления тестированием. Данная аннотация принимает параметр «value», в котором указывается ID теста в системе управления тестированием.

@TmsLinks — тоже самое, что и @TmsLink, но в качестве параметра «value» принимает массив TmsLink’ов.

Аннотации данной группы добавляют ссылки на дефект/тест-кейс в Allure-отчет.

Чтобы из ID дефекта/тест-кейса, указанного в параметре «value», получить полноценную ссылку, необходимо в allure.properties (который должен быть размещен в classpath, например, в src/test/resources) описать шаблон ссылки до соответствующего дефекта/тест-кейса.

При генерации отчета Allure подставит вместо символов <> значения, которые были указаны в параметре value Вашей аннотации, и вы получите полноценные ссылки.

Приведем пример использования данных аннотаций

Аннотации прочих ссылок

@Link — аннотация, размещаемая над тестом. Позволяет приложить к автотесту ссылки на какие-то внешние ресурсы. Данная аннотация может принимать параметры «name» — наименование ссылки (по умолчанию, url), «value» — синоним «name», «url» — адрес, по которому нужно выполнить переход и «type» — параметр, применяемый для создания иконки для ссылки.
@Links — тоже самое, что и @Link, но в качестве параметра «value» принимает массив Link’ов.

Приведем пример использования данных аннотаций

Аннотация @Owner

@Owner — аннотация, размещаемая над тестом. Позволяет указать ответственное лицо за тест. Данная аннотация принимает параметр «value», в котором указывается информация об авторе автотеста.

Приведем пример использования данной аннотации

Аннотация @Severity

@Severity — аннотация, размещаемая над тестом. Позволяет указать уровень критичности функционала, проверяемого автотестом. Данная аннотация принимает параметр «value», который может быть одним из элементов enum SeverityLevel: BLOCKER, CRITICAL, NORMAL, MINOR или TRIVIAL.

Приведем пример использования данной аннотации

Параметризованные автотесты в Allure

Allure умеет работать с параметризованными автотестами. Рассмотрим на примере JUnit 4.12.
Для начала создадим тестовый класс с параметризованными тестами следующего вида:

Теперь прогоним наш тест и соберем отчет:

Allure представляет наш параметризованный тест как набор тестов, если провалиться в какой-либо тест, то мы получим детальную информацию о прогоне именно этого кейса.

Категории дефектов. Распределение дефектов по категориям

Если в pom.xml у Вас подключен allure-maven плагин, то categories.json можно разместить в поддиректории resources директории test

Приведем пример кастомной классификации дефектов. Создадим файл categories.json:

• name — наименование категории. Оно будет отображаться на вкладке «Categories» на самом верхнем уровне классификации. Обязательный атрибут.

• matchedStatuses — список статусов, с одним из которых должен завершиться тест, чтобы попасть в данную категорию. Из коробки доступны статусы «failed», «broken», «passed», «skipped» и «unknown». Необязательный атрибут.

• messageRegex — регулярное выражение, которому должно соответствовать Exception-сообщение, чтобы попасть в данную категорию. Необязательный атрибут.

• traceRegex — регулярное выражение, которому должно соответствовать Exception-StackTrace, чтобы попасть в данную категорию. Необязательный атрибут.

Теперь прогоним тесты, обнаруживающие такие дефекты, и посмотрим, как будет выглядеть отчет на вкладке «Categories»:

Тестовое окружение. Блок ENVIRONMENT на главной странице отчета

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

Информация, которая отображается в данном блоке, попадает туда из специального файла environment.properties.

Приведем пример данного файла:

Данный файл необходимо подложить в директорию «target/allure-results» до сборки html-отчета. Сделать это можно вручную, а можно использовать maven-resources-plugin.

Приведем пример его использования в данной ситуации, при условии размещения environment.properties в поддиректории resources директории test. Для этого модифицируем pom.xml:

Теперь при сборке проекта environment.properties будет попадать в «target/allure-results» и участвовать в построении html-отчета.

При запуске тестов на Jenkins, categories.json не будет самостоятельно копироваться в «target/allure-results». Его также очень удобно добавить в секцию includes maven-resources-plugin’а.

Заключение

Во второй части лонгрида мы постарались подробно рассказать об аннотациях в Allure, привели примеры их использования. Затронули категории дефектов, тестовое окружение и способы вывода информации в отчет. Приглашаем к обсуждению в комментариях.

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

Источник

Поделиться с друзьями
Советы экспертов и специалистов
Adblock
detector