Как стать автором
Обновить
695.5
Сбер
Технологии, меняющие мир

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

Время на прочтение11 мин
Количество просмотров117K
Продолжая серию публикаций о возможностях Allure-framework, сегодня мы поговорим о работе с кодом. Под катом разбираем, что такое шаг теста, как выводить информацию в отчет при выполнении шагов и какие бывают категории дефектов. Кроме того, расскажем об аннотациях Allure. Дальше еще интереснее!


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


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

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

Рассмотрим пример

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

@Step
public static void checkSumStep(int num1, int num2, int expectedSum) {
   Assert.assertTrue("Сумма слагаемых не соответствует ожидаемому значению", num1 + num2 == expectedSum);
}

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

@Test
public void simpleTest2() {
   checkSumStep(3, 2, 5);
   checkSumStep(5, 4, 9);
}

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



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

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

@Step("Проверка разности числа {num1} и числа {num2}")
public static void checkSubtractionStep(int num1, int num2, int expectedResult) {
   Assert.assertTrue("Результат вычитания не соответствует ожидаемому значению", num1 - num2 == expectedResult);
}

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


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

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


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

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

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

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


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

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

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

@Attachment
public static byte[] getBytes(String resourceName) throws IOException {
     return Files.readAllBytes(Paths.get("src/main/resources", resourceName));
}

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

@Step("Проверка эквивалентности строки {str1} строке {str2}")
public static void checkStringEqualsStep(String str1, String str2) throws IOException {
    Assert.assertTrue("Строки не эквивалентны", str1.equals(str2));
    getBytes("picture.jpg");
    getBytes("text.txt");
}

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

@Test
public void simpleTest4() throws IOException {
    String darkSouls = "Dark souls 3";
    checkStringEqualsStep(darkSouls, darkSouls);
}

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



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

@Attachment(value = "Вложение", type = "application/json", fileExtension = ".txt")
public static byte[] getBytesAnnotationWithArgs(String resourceName) throws IOException {
    return Files.readAllBytes(Paths.get("src/main/resources", resourceName));
}

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



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


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

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


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

@Step("Добавить ссылку на Сбербанк")
public static void addLinkSber() {
    String link = "http://sberbank.ru";
    Allure.addAttachment("Результат", "text/plain", link);
}

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

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


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

Аннотация @Description


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

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

@Test
@Description(value = "Тест проверяет эквивалентность единицы единице")
public void simpleTest7_1() {
    Assert.assertTrue(1 == 1);
}



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


@Epic — аннотация, размещаемая над тестом. Позволяет группировать тесты по эпикам. Данная аннотация принимает параметр «value» — наименование эпика.
@Epics — тоже самое, что и @Epic, но в качестве параметра «value» принимает массив Epic'ов.
@Feature — аннотация, размещаемая над тестом. Позволяет группировать тесты по проверяемому функционалу. Данная аннотация принимает параметр «value» — наименование функционала.
@Features — тоже самое, что и @Feature, но в качестве параметра «value» принимает массив Feature'ей.
@Story — аннотация, размещаемая над тестом. Позволяет группировать тесты по User story. Данная аннотация принимает параметр «value» — наименование User story.
@Stories — тоже самое, что и @Story, но в качестве параметра «value» принимает массив Story'й.
Аннотации @Epic/Epics, @Feature/Features, @Story/Stories можно отнести к аннотациям функциональности. Данные аннотации группируют тесты по функциональности в разделе Behaviors(Функциональность) Allure-отчета.

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

@Epic(value = "Математика")
@Feature(value = "Простые математические операции")
@Story(value = "Сложение")
@Test
public void sumTest() {
    Steps.checkSummationStep(5, 4, 9);
}

@Epic(value = "Математика")
@Feature(value = "Простые математические операции")
@Story(value = "Вычитание")
@Test
public void subTest() {
    checkSubtractionStep(8, 2, 6);
}

@Epics(value = {@Epic(value = "Математика"), @Epic(value = "Геометрия")})
@Features(value = {@Feature(value = "Тригонометрия"), @Feature(value = "Простые математические операции")})
@Stories(value = {@Story(value = "Синус"), @Story(value = "Синусоида")})
@Test
public void checkSinTest() {
    checkSinStep(0, 0);
}

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



Аннотация @Flaky


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

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

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

@Test
@Flaky
public void testDemoFlaky() {
    int randomNum = ThreadLocalRandom.current().nextInt(0, 2);
    if (randomNum == 0) {
        Assert.assertTrue(true);
    } else {
        Assert.assertTrue(false);
    }
}

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



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


@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.link.issue.pattern=https://example.org/issue/{}
allure.link.tms.pattern=https://example.org/tms/{}

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

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

@Test
@Issue(value = "FGY-4627")
@TmsLinks({@TmsLink(value = "TL-135"), @TmsLink(value = "TL-158")})
public void simpleTest15() {
    Assert.assertTrue(1 == 1);
}

@Test
@TmsLink(value = "TL-678")
public void simpleTest18() {
    Assert.assertTrue(1 == 1);
}



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


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

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

@Test
@Link(name = "Ссылка", url = "http://yandex.ru")
public void checkSubtractionWithLinkTest() {
    checkSubtractionStep(15, 5, 10);
}
 
@Test
@Links(value = {@Link(name = "Ссылка1", url = "http://sberbank.ru"),
        @Link(name = "Ссылка2", url = "http://yandex.ru")})
public void checkSubtractionWithLinksTest() {
    checkSubtractionStep(14, 5, 9);
}



Аннотация @Owner


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

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

@Test
@Owner(value = "Пупкин Валерий Иванович")
public void testDemoOwner() {
    checkSumStep(1, 2, 3);
}



Аннотация @Severity


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

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

@Test
@Severity(value = SeverityLevel.BLOCKER)
public void testDemoSeverity() {
    checkSubtractionStep(6, 1, 5);
}



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


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

@RunWith(Parameterized.class)
public class ParamsTests {
    @Parameter
    public int operand1;

    @Parameter(1)
    public int operand2;

    @Parameter(2)
    public int expectedResult;

    @Parameters(name = "operand1 = {0} | operand2 = {1} | expectedResult = {2}")
    public static Collection<Integer[]> dataProvider() {
        return Arrays.asList(new Integer[][]{
                {1, 2, 3},
                {2, 4, 6},
                {5, 6, 11},
                {7, 5, 12},
                {2, 4, 5},
                {4, 1, 5},
                {8, 2, 11}
        });
    }

    @Test
    public void checkSum() {
        Assert.assertTrue("Сумма слагаемых не соответствует ожидаемому значению", operand1 + operand2 == expectedResult);
    }
}

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



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

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


По умолчанию на вкладке «Categories» Allure-отчета все прогнанные тестовые методы делятся на 2 категории: дефекты продукта (failed tests) и дефекты теста (broken tests). Для того, чтобы сделать кастомную классификацию, необходимо подложить файл categories.json в директорию «target/allure-results».
Если в pom.xml у Вас подключен allure-maven плагин, то categories.json можно разместить в поддиректории resources директории test
Приведем пример кастомной классификации дефектов. Создадим файл categories.json:

[
  {
    "name": "Неизвестная проблема",
    "matchedStatuses": ["broken", "failed"],
    "messageRegex": ".*что-то пошло не так.*"
  },
  {
    "name": "Нет данных",
    "matchedStatuses": ["broken"],
    "traceRegex": ".*NullPointerException.*"
  },
  {
    "name": "Product defects",
    "matchedStatuses": ["failed"]
  },
  {
    "name": "Test defects",
    "matchedStatuses": ["broken"]
  }
]

Описание атрибутов:

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

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

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

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

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



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


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



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

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

OS.version=Windows 10 Pro
JDK.version=jdk1.8.0_162
MAVEN.version=Apache Maven 3.5.2
allure-junit4.version=2.6.0
allure-report.version=2.6.0

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

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

<build>
   <plugins>
      ...
      <plugin>
         <artifactId>maven-resources-plugin</artifactId>
         <version>3.0.2</version>
         <executions>
            <execution>
               <id>copy-resources</id>
               <phase>validate</phase>
               <goals>
                  <goal>copy-resources</goal>
               </goals>
               <configuration>
                  <outputDirectory>${allure.results.directory}</outputDirectory>
                  <resources>
                     <resource>
                        <directory>src/test/resources</directory>
                        <includes>
                           <include>environment.properties</include>
                        </includes>
                     </resource>
                  </resources>
               </configuration>
            </execution>
         </executions>
      </plugin>
      ...
   </plugins>
</build>

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

Заключение


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

Подписывайтесь на блог ЕФС, следите за новыми публикациями. Скоро мы снова расскажем что-то новое и полезное про Allure.
Теги:
Хабы:
Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку
Всего голосов 5: ↑4 и ↓1+3
Комментарии5

Информация

Сайт
www.sber.ru
Дата регистрации
Дата основания
Численность
свыше 10 000 человек
Местоположение
Россия