company_banner

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

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



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

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

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

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


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

    • Thucydides — Java-фреймворк (а значит, тесты можно писать только на Java);
    • Thucydides был спроектирован вокруг WebDriver и ориентирован исключительно на приёмочное тестирование веб-приложений;
    • Thucydides довольно монолитный с точки зрения архитектуры. Да, у него много возможностей «из коробки», но если тебе потребуется сделать что-то выходящее за рамки этих возможностей, то проще застрелиться.

    Allure реализует ту же идею, но лишён архитектурных недостатков Thucydides.

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


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

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

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



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

    /**
     * Добавить виджет из каталога виджетов, отменить добавление.<br>
     * После обновления на морде не должно быть виджета.
     */
    @Test
    public void cancelWidgetAdditionFromCatalog() {
        userCatalog.addWidgetFromCatalog(widgetRubric, widget.getName());
        userWidget.declineWidgetAddition();
        user.opensPage(CONFIG.getBaseURL());
        userWidget.shouldNotSeeWidgetWithId(widget.getWidgetId());
        userWidget.shouldSeeWidgetsInAmount(DEFAULT_NUMBER_OF_WIDGETS);
    }


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



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



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

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

    @Features("Индекс")
    @Stories("Проверка индекса")
    @RunWith(Parameterized.class)
     public class IndexTest {
       …
    }


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



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

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



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

    Я тоже так хочу!


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

    Яндекс

    487,00

    Как мы делаем Яндекс

    Поделиться публикацией
    Комментарии 19
      +10
      А для тех, у кого пройдут все тесты, у нас в отчете есть сюрприз…
      +11
      осталось только заставить всех писать тесты
        +11
        Осталось только СЕБЯ заставить писать тесты!
        0
        У нас тест-лид очень любит http://robotframework.org/
        Как у вас с интеграцией с Jenkins? Можно ли распараллелить запуск test-suits на разных машинах?
          0
          Для Jenkins есть плагин. Фреймворк вообще никак не ограничивает выполнение тестов. Вы можете распараллелить тесты хоть до отдельных методов, главное чтобы в конце по результатам тестирования собрался правильный XML.
          0
          А почему в слове Cucumber русские буквы? Чтобы вхождение на странице нельзя было найти?
            0
            И действительно. Поправим.
              0
              Спасибо, исправил
              0
              А example'ы для python'а добавят?
              0
              Не туда.
                +1
                Отличный на самом деле инструмент, в пятницу увидел статью, решил протыкать, чтобы понять насколько оно гибко и легко в настройке, использовании.

                Оставлю пару замечаний, вдруг, разработчики найдут их уместными.
                1. allure-cli держать где-то в виде готового приложения собранного под 1.7 java runtime environment compatible

                Почему:
                Я не пишу на java ничего, мой инструментарий крутится вокруг python/js/less(css)/html и так далее. У меня нет ни teamcity ни jenkins в продакшене, возможно это сильное упущение, возможно нет, поэтому создание отчетов я доверил allure-cli.

                Для того, чтобы собрать allure-cli мне пришлось:
                — найти allure-cli, проанализировать информацию о том, что это действительно то, что мне нужно
                — установить jdk-1.7 для его сборки, а установка 1.7 версии oracle'вской java вылилось в мини приключение:
                — пришлось зарегистрироваться на oracle, найти очень хитрую ссылку архивных версий jdk, скачать 1.7.0.65u версию jdk, для того чтобы её установить. Почему именно эту версию, потому что в gentoo текущая на данный момент 1.7.0.67 недоступна
                — воткнуть maven-bin для того, чтобы собрать allure-cli

                я бы обошелся и icedtea, но мой PyCharm хочет именно oracle'вскую версию jre, поэтому пришлось страдать и мучаться :)

                Далее вспомнить как запускаются собранные в jar приложения (`java -jar jarfile.jar`) и наконец-то получить сгенерированный отчет, ура-ура.

                2. Данный аспект обещали исправить, но я его зафиксирую. Demo/Examples в едином виде — это отличный организационный ход, хотя не увидев в example'ах примеры на python я немного удивился почему их там нет и скачал то, что ближе мне всего по используемым инструментам: karma-allure-example. Чуть позже я обнаружил в адапторе allure для python необходимые демки :). Главное, что нашел.

                3. Небольшой HOWTO в использовании построения отчетов с помощью того же allure-cli? Возможно оно уже есть, но я не нашел, хотя вроде бы все протыкал. Разобраться с этим вполне можно и это не критично, но съэкономило бы много времени людям.
                +1
                Еще кстати для Atlassian Bamboo плагин сделали: github.com/allure-framework/allure-bamboo-plugin

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

                Самое читаемое