Allure что это за программа

Любая команда, создающая новый продукт, сталкивается с заблуждениями пользователей или сообщества. Если продукт не просто новый, а концептуально новый — таких заблуждений становится в разы больше.

За Allure TestOps с самого начала тянется немало мифов. В некоторые из которых в начале пути мы верили и сами (например, в пятый!). В этой статье мы поделимся наиболее частыми заблуждениями и постараемся развеять их.

Миф 1. Allure TestOps — еще одна TMS

Пожалуй, чаще всего мы сталкиваемся именно с этим заблуждением. Обычно такая точка зрения озвучивается людьми, не изучавшими систему в деталях. Действительно, базовый набор функций типичной TMS есть в Allure TestOps: создание тест-кейсов, управление планами тестирования, назначение тестов на конкретных специалистов, прогон тестов и аналитика по результатам их выполнения. И все это отлично работает для ручных тестов, а для автоматизации есть набор API-интерфейсов, с которыми вы можете сами написать базовую интеграцию для используемой технологии.

Обновленный обзор Allure TestOps

Правда в том, что в случае Allure TestOps эта функциональность не является основной! Мы построили систему вокруг управления процессом тестирования по принципам DevOps:

1. Автоматизируйте все, что можно автоматизировать: тесты, тестовую документацию, запуски и перезапуски, разбор результатов, генерацию аналитики и отчетов. Тест-кейсы в автоматизации должны быть маленькими, а их обновление — автоматическим.
2. Общайтесь и обменивайтесь фидбеком: Как только происходят изменения в автотесте, они отображаются в системе и документации. И наоборот — как только вы изменили тест-кейс из UI — коллеги-автоматизаторы или разработчики получат автоматически сгенерированное ТЗ на обновление теста.
3. Будьте прозрачны: очень часто тестовые системы строятся таким образом, что польза от очередного прогона ясна только тем, кто его делал. В TestOps результаты каждого прогона со всеми деталями (вложения, стектрейсы, версии и переменные окружения) доступны всей команде и хранятся в понятной структуре с сохранением истории.

Эти принципы, реализованные на базе Allure TestOps, позволяют строить тестирование с заделом на будущее.

Миф 2. Чтобы пользоваться Allure TestOps, надо уходить с привычных инструментов

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

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

За примером далеко ходить не надо: Allure отлично уживается рядом с TestRail у многих наших клиентов, выступая в качестве простого решения для управления всеми автоматизированными тестами — так получается проще, чем писать и поддерживать зоопарк интеграций с CI-системами и фреймворками для тестирования.

Обзор возможностей Allure EE

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

Миф 3. Allure TestOps не подходит командам с ручным тестированием

Сравнивая Allure TestOps с TMS, многие ручные тестировщики отмечают множество неочевидных и «странных» решений: ярким примером здесь является логика хранения тест-кейсов в дереве (почему так, я писал отдельно). На самом деле, часто подобные замечания оказываются верны — поскольку Allure TestOps является automation first системой, решения для ручных тестировщиков реализованы непривычно.

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

Это не значит, впрочем, что такие решения не подходят командам с большим штатом ручных тестировщиков — Allure TestOps умеет делать с ручными тестами все, что должна уметь классическая TMS:

• Управление тест-планами, тест-кейсами и чек-листами
• История результатов тестов
• Автоматическое распределение тестов на QA-инженеров
• Аналитика и статистика (по юзеру, по команде или по чему угодно)
• Автоматические и ручные запуски тестов
• Двусторонняя интеграция с JIRA

Миф 4. Allure TestOps дорого обходится

Мир инструментов для QA-подразделений все еще зелен и юн — многие считают, что покупка инструментов — это дорого, а для всего остального есть Mastercard. 🙂

Стоимость Allure TestOps составляет $30 в месяц за пользователя. Много ли это? Давайте попробуем разобраться, почему нам такая оценка кажется разумной.

Первая проблема оценки заключается в том, что нас (в результате Мифа 1) сравнивают с TMS. И некоторые из них действительно на первый взгляд выглядят дешевле. Чтобы не быть голословным, приведу сравнительную таблицу с прайсами систем, с которыми нас чаще всего сравнивают:

Мы посмотрели на медианный trial-запрос и решили сделать сравнение на примере 10 лицензий.

Правда в том, что Allure TestOps сверху функциональности умеет еще кое-что. Кое-что важное, а именно — полноценное нативное управление автоматизированным тестированием. Так что к ценам выше придется прибавить стоимость разработки и поддержки самописных интеграций с тестовой инфраструктурой или вот такими инструментами вроде Katalon Runtime Engine / Studio.

Более того, за счет оптимизации процессов и тонкой настройки тестирования в долгосрочной перспективе Allure TestOps позволяет сильно сократить расходы на QA по двум направлениям: штат сотрудников (а это не только ЗП, но и офис, оборудование, расходы на найм и удержание и еще много чего) и расходы на тестовую инфраструктуру (оптимизированный под большие нагрузки Allure TestOps построен так, чтобы не перегревать инфраструктуру и каналы). Но про это можно написать отдельную статью.

Миф 5. Мы сами напишем свой TestOps за пару месяцев

Не самый распространенный миф, с которым мы периодически сталкиваемся на конференциях, в тематических чатах и других «общественных» местах. Оно и понятно, в чем проблема забутстрапить очередной CRUD-сервис, гоняющий результаты тестов в БД и отображающий красивую аналитику на базе любого JS-фреймворка?

Как говорится в известном анекдоте: есть нюанс. Allure TestOps построен на базе Allure Report, так что давайте начнем с него. Чтобы построить подобную систему, придется:

• Определиться с моделью данных. Начнем с самого базового — придется работать с метаданными тест-кейса, его содержимым, а также контекстом. Выбор модели данных является важным шагом, который повлияет на всю разработку в будущем.
• Разработать commons API для обеспечения интеграций необходимыми данными. Важно сделать его достаточно универсальным, чтобы вы могли заточить его по тестирование бэкенда, фронтенда, протоколов их взаимодействия и кто знает, чего еще. (в этот момент несколько очень головастых разработчиков потратили на проект несколько месяцев).
• Готовить интеграции с тестовыми фреймворками, находящимися в проде, когда API готовы и доступны. Кажется, что мы на финишной прямой, однако радоваться рано. Каждый фреймворк работает с данными по-своему, так что готовить интеграции посредством CMD+C → CMD+V не получится. Посмотрите на реализацию интеграций Allure Framework c JUnit и TestNG. И это все Java, интеграцию с тестами на другом языке придется переделывать со второго шага, надеясь на то, что не придется фиксить еще и модель данных (нам иногда приходилось).
• На каждую интеграцию, по нашему опыту, приходится порядка месяца работы разработчика, специализирующего на таком коде. А еще их надо поддерживать, и иногда обновлять API, не ломая обратную совместимость. Так что на поддержку 5-6 фреймворков закладывайте год-два.
• Погрузиться в задачи параллелизации и concurrent context sharing, поскольку выполнять автотесты в один поток просто не получится.

Хорошо, теперь мы умеем собирать данные! Следующее, с чем придется столкнуться — реализация протокола передачи результатов. По сути, у вас будет два глобальных пути: асинхронный обмен батчами и синхронизированные http-запросы. К слову, по второму пути идут практически все TMS, не даром у TestRail есть ограничение на 300 запросов в минуту (5 в секунду). Если для ручных тестов такой подход работает, то 10 000 автотестов надо будет ждать как минимум полчаса.

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

Выводы

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

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

Пробуйте, смотрите и тестируйте: мы для этого предоставляем месячный trial-период Allure TestOps, в рамках которого саппорт будет помогать вам с настройкой и эксплуатацией системы, а также настройкой процессов под ваши требования.

Источник: www.software-testing.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аннотации данной группы добавляют ссылки на дефект/тест-кейс в 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 Вашей аннотации, и вы получите полноценные ссылки.

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

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

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

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

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

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

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

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

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:

. maven-resources-plugin 3.0.2 copy-resources validate copy-resources $ src/test/resources environment.properties .

Теперь при сборке проекта 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

Источник: h.amazingsoftworks.com