Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allure: Тело сценария отображается не так, как в VA #1111
DoublesunRUS opened this issue Jan 18, 2021 · 1 comment
Allure: Тело сценария отображается не так, как в VA #1111
DoublesunRUS opened this issue Jan 18, 2021 · 1 comment
Comments
Contributor DoublesunRUS commented Jan 18, 2021
Функционал: Одинаковое отображение сценария в VA и Allure Как разработчик теста Я хочу чтобы дерево шагов сценария отображалось одинаково в VA и Allure
Дано я закрыл все окна клиентского приложения Если нет права "Просмотр" к объекту "Документ.ОтзывСогласияНаОбработкуПерсональныхДанных" тогда Тогда я останавливаю выполнение сценария Дано я получаю список команд печати для объекта метаданных "Документ.ОтзывСогласияНаОбработкуПерсональныхДанных" в переменную "СписокПечатныхФорм"Если'$СписокПечатныхФорм$.Количество() = 0' Тогда Тогда я вызываю исключение "В конфигурации отсутствуют печатные формы для документа ОтзывСогласияНаОбработкуПерсональныхДанных"И я ищу последние 5 документов 'ОтзывСогласияНаОбработкуПерсональныхДанных' по каждой организации в переменную "СписокДокументов"Если'$СписокДокументов$.Количество() = 0' Тогда Тогда я вызываю исключение "В базе отсутствуют документы ОтзывСогласияНаОбработкуПерсональныхДанных"И для каждого значения "СсылкаДокумента" из массива "$СписокДокументов$"Тогда я запоминаю значение выражения 'ПолучитьНавигационнуюСсылку($СсылкаДокумента$)' в переменную "НавигационнаяСсылкаДокумента" Затем я открываю навигационную ссылку "$НавигационнаяСсылкаДокумента$"Если появилось предупреждение тогда Тогда я вызываю исключение "Не удалось открыть навигационную ссылку $НавигационнаяСсылкаДокумента$"И для каждого значения "ПечатнаяФормаДокумента" из массива "$СписокПечатныхФорм$"Тогда я запоминаю значение выражения '$ПечатнаяФормаДокумента$.Представление' в переменную "НаименованиеПечатнойФормы"Если элемент с заголовком "$НаименованиеПечатнойФормы$" присутствует на форме тогда Тогда я нажимаю на кнопку "$НаименованиеПечатнойФормы$"Если появилось предупреждение тогда Тогда я вызываю исключение "Не удалось напечатать форму $НаименованиеПечатнойФормы$ для документа $НавигационнаяСсылкаДокумента$"И я закрываю текущее окно И я закрыл все окна клиентского приложения
Так вот в отчете Allure он выглядит совсем не так. Там какая-то мешанина шагов без соблюдения иерархии.
The text was updated successfully, but these errors were encountered:
Saved searches
Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test duplication in the report when dynamically applying the same title or story multiple times #1883
acqa opened this issue Dec 15, 2020 · 5 comments
Test duplication in the report when dynamically applying the same title or story multiple times #1883
acqa opened this issue Dec 15, 2020 · 5 comments
type:bug Something isn’t working
Comments
acqa commented Dec 15, 2020 •
I’m submitting a .
[x ] bug report
What is the current behavior?
При использовании динамических story и title, title-ы не группируются по имени — появляется большое кол-во title-ов с одинаковым названием и временем выполнения.
При использовании статического story — группировка производится ожидаемо. Как видно — дублирующих тестов (title-ов) — нет.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
При использовании динамического story, группировка title-ов должна сохраняться.
What is the motivation / use case for changing the behavior?
Хотелось бы добавить поддержку allure в schemathesis
Please tell us about your environment:
Allure version: 2.13.6
Test framework: pytest@3.7.2
Allure adaptor: allure-pytest-2.7.1
Other information
Обновил информацию, добавил скрины с отчетами. //: # ( . e.g. detailed explanation, stacktraces, related issues, suggestions . how to fix, links for us to have more context, eg. Stackoverflow, Gitter etc )
The text was updated successfully, but these errors were encountered:
Stranger6667 commented Dec 15, 2020
I am not sure what is the default communication language here, as the issue author wrote it in Russian. I’ll provide my comment also in Russian.
Хотелось бы добавить поддержку allure в schemathesis
Здесь важно учесть, что тесты которые генерирует Schemathesis это в первую очередь hypothesis тесты. Их особенность в том что тело функции выполняется множество раз внутри одного pytest теста — там разные этапы, включая генерацию данных + минимизацию. Тем самым все вызовы allure.dynamic.title и прочее выполняются множество раз. Больше деталей можно узнать в этом issue, но во многом это больше вопрос интеграции hypothesis с pytest, чем schemathesis с pytest-allure.
Со своей стороны могу предложить добавить хуки в pytest плагин в schemathesis. Т.е. можно сделать два хука (по-крайней мере на первый взгляд), один бы вызывался до вызова schemathesis-теста, а один после. Чтото вроде такого:
И можно сделать чтобы они вызывались один раз на каждый endpoint — и внутри них уже можно было бы вызывать allure. Дайте знать если такое подойдет — добавлю в roadmap в Schemathesis.
P.S. To the plugin maintainers. Let me know if it makes sense to give the comment above in English as well.
acqa commented Dec 15, 2020 •
Дмитрий привет! Обновил стартовый пост, добавил скрины отчетов. Первый раз оформляю тут баг, сначала не разобрался как правильно их вставлять.
Тем самым все вызовы allure.dynamic.title и прочее выполняются множество раз.
Как видно из скринов, если использовать антотацию @allure.story(«Static story») над тестовой функцией, то проблем с множественным выполнением allure.dynamic.title не возникает — отчет формируется без дубликатов тестов (title-ов). А если использовать allure.dynamic.story() вместе с allure.dynamic.title в самой тестовой функции, то получаем дубликаты строк title-ов в отчете. Поэтому предположил, что ошибка на стороне формирователя результата allure.
Если я правильно понял, то там речь про глубокую интеграцию hypothesis c pytest- ом. В моем примере, assert-ов для pytest-а нет совсем, я полагаюсь только на ошибки, которые выведет сам hypothesis. Для того, чтобы было проще эти ошибки разбирать, я каждый из запросов обрамляю allure.step-ом, в котором прописываю условия выполнения каждого запроса и прикладываю условия и результат http-запроса. В принципе, allure.dynamic.title со статическим @allure.story() позволяет определенную группировку производить. Но хочется сделать группировку чуть детальнее: Endpoint — GET — POST — PUT — DELETE А для этого, нужно как-то в @allure.story() передать текущее значение из case.endpoint.path. Иного способа, кроме как allure.dynamic.story(), пока не придумал — но это решение вызывает некорректное оформление теста.
Со своей стороны могу предложить добавить хуки в pytest плагин в schemathesis.
Если это позволит передавать в @allure.story() текущие параметры из фикстуры case (в частности, case.endpoint.path), то было бы хорошо 🙂
Allure-Framework. Работа с кодом
Продолжая серию публикаций о возможностях Allure-framework, сегодня мы поговорим о работе с кодом. Под катом разбираем, что такое шаг теста, как выводить информацию в отчет при выполнении шагов и какие бывают категории дефектов. Кроме того, расскажем об аннотациях Allure. Дальше еще интереснее!
Шаг теста. Определение и аннотация @Step
Для визуализации процессов, протекающих в ваших тестах, необходимо использовать шаги. Шаг должен представлять какое-то атомарное действие или проверку. Собственно последовательность шагов и представляет ваш тест. Для наглядности в шаге должны быть описаны входные параметры, а также ожидаемый и фактический результат, если шаг представляет собой проверку.
В Allure для обозначения тестового шага над методом необходимо проставить аннотацию @Step. Затем необходимые шаги-методы включаются в тело тестового метода: тесты с аннотацией @Test.
Рассмотрим пример
Создадим метод с аннотацией @Step, который проверяет соответствие суммы двух слагаемых ожидаемому результату:
@Step public static void checkSumStep(int num1, int num2, int expectedSum)
Теперь создадим тестовый метод, использующий данный шаг:
@Test public void simpleTest2()
При прогоне данного автотеста мы получим следующий отчет:
Аннотация @Step умеет принимать параметр «value», который позволяет указывать имя шага на русском языке. Кроме того, имя шага можно параметризировать – передать в него значения аргументов, передающихся в шаг.
Продемонстрируем на примере
@Step("Проверка разности числа и числа ") public static void checkSubtractionStep(int num1, int num2, int expectedResult)
При использовании данного шага в тесте получим отчет:
Стоит отметить, что в случае использования объекта в качестве аргумента метода, есть возможность вывести в названии шага значение одного из полей этого объекта. Для этого необходимо в value указать имя поля в виде
Вывод информации в отчет при выполнении шагов теста. Вложения
При выполнении шагов автотеста бывает очень полезно выводить в отчет разного рода информацию. Для этих целей в Allure служат вложения.
Вложение — это информация различного типа в виде файла, который может быть прикреплен к тестовому шагу или тесту.
Вложения могут иметь 4 характеристики:
• value/name — наименование вложения; • type — тип информации в соответствии со стандартом MIME; • content — содержимое вложения; • fileExtension — опциональное расширение файла вложения, начинающееся с точки.
Вложения к отчету можно прикреплять 2 способами: с помощью аннотации @Attachment и с помощью статического метода addAttachment класса Allure.
Прикрепление вложений с помощью аннотации @Attachment
В данном способе создается метод, возвращающий массив байтов, над ним размещается аннотация @Attachment. При использовании данного метода считанная информация будет добавлена в отчет в виде файла с соответствующим расширением. Наименование вложения будет таким же, как и имя вызываемого метода.
Продемонстрируем на примере
Создадим метод, который будет зачитывать вложение:
При использовании данного метода в своих шагах 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» последнему параметру, в качестве описания будет браться джавадок, размещенный над методом.
@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-отчета.
При выполнении тестов и последующем формировании отчета, в разделе 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 подставит вместо символов <> значения, которые были указаны в параметре value Вашей аннотации, и вы получите полноценные ссылки.
@Link — аннотация, размещаемая над тестом. Позволяет приложить к автотесту ссылки на какие-то внешние ресурсы. Данная аннотация может принимать параметры «name» — наименование ссылки (по умолчанию, url), «value» — синоним «name», «url» — адрес, по которому нужно выполнить переход и «type» — параметр, применяемый для создания иконки для ссылки. @Links — тоже самое, что и @Link, но в качестве параметра «value» принимает массив Link’ов.
@Owner — аннотация, размещаемая над тестом. Позволяет указать ответственное лицо за тест. Данная аннотация принимает параметр «value», в котором указывается информация об авторе автотеста.
Приведем пример использования данной аннотации
@Test @Owner(value = "Пупкин Валерий Иванович") public void testDemoOwner()
Аннотация @Severity
@Severity — аннотация, размещаемая над тестом. Позволяет указать уровень критичности функционала, проверяемого автотестом. Данная аннотация принимает параметр «value», который может быть одним из элементов enum SeverityLevel: BLOCKER, CRITICAL, NORMAL, MINOR или TRIVIAL.
Приведем пример использования данной аннотации
@Test @Severity(value = SeverityLevel.BLOCKER) public void testDemoSeverity()
Параметризованные автотесты в 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 = | operand2 = | expectedResult = ") public static Collection dataProvider() < return Arrays.asList(new Integer[][]< , , , , , , >); > @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 — наименование категории. Оно будет отображаться на вкладке «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:
Теперь при сборке проекта environment.properties будет попадать в «target/allure-results» и участвовать в построении html-отчета.
При запуске тестов на Jenkins, categories.json не будет самостоятельно копироваться в «target/allure-results». Его также очень удобно добавить в секцию includes maven-resources-plugin’а.
Заключение
Во второй части лонгрида мы постарались подробно рассказать об аннотациях в Allure, привели примеры их использования. Затронули категории дефектов, тестовое окружение и способы вывода информации в отчет. Приглашаем к обсуждению в комментариях.
Подписывайтесь на блог ЕФС, следите за новыми публикациями. Скоро мы снова расскажем что-то новое и полезное про Allure.
allure
allure first steps
allure framework
allure 2.0
allure 2
Блог компании Сбер
Тестирование IT-систем
Программирование
Тестирование веб-сервисов
Учебный процесс в IT
В allure отчёт не попадают новые тесты
Запускаю 10 тестов на удалённой машине через jenkins, тесты проходят, отчёт строится. Создаю ещё один тест, но при этом в allure отчёте по прежнему показывает десять тестов. При этом в консоле вижу что проходит 11 тестов, но в отчёт новый не попадает. Если создаю новый item, то аллюр показывает как надо- 11 тестов. Но не создавать же каждый раз новый item чтобы увидеть отчет по тестам). В чём может быть магия?