primechord 10 окт 2022 в 10:30

Allure TestOps: «Нестандартный» сценарий использования

9 мин

5.5K

Блог компании Delivery Club TechТестирование IT-систем*Тестирование мобильных приложений*Kotlin*

Привет. Меня зовут Николай, я QA Automation Engineer в мобильной платформенной команде Delivery Club. Эта статья будет о том, как мы интегрировали Allure TestOps (далее Allure TO) в регрессионное тестирование нескольких мобильных приложений и ушли от TestRail. Альтернативу TestRail выбирали мои коллеги, и эту часть мы упомянем вскользь.

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

Этот материал будет интересен тем, кому предстоит интегрировать мобильные автотесты в Allure TO и хочется узнать про потенциальные проблемы. А также, возможно, тем, кому не полностью подходят стандартные сценарии использования этой TMS. Цель статьи — не дать конкретное решение, а продемонстрировать наш сценарий использования нетипичных возможностей TMS с небольшими вставками кода.

Research

Allure TO призван решить проблему ранних Test Management System (TMS), которые создавались с ручным тестированием во главе угла. И с течением времени к этим TMS сбоку прикручивали автоматизацию процессов и тестирования. В Allure TO автоматизация заложена изначально, и при этом инструмент подталкивает к ее использованию.

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

Наши автотесты преимущественно пишутся на Kotlin с использованием Kaspresso, поэтому поддержка базового Allure достигается за счет паттерна Step и расширения для базового класса тестов Kaspresso-Allure.md.

До начала интеграции мой коллега @materkey уже реализовал запуск тестов на каждый коммит Pull Request (PR), где при наличии красных тестов для такого PR срабатывает Quality Gate. Следовательно, если мы не успеваем быстро починить сломанный тест, то у нас появляются @Ignore-тесты (skipped), ниже я расскажу про них подробнее. В качестве отчета PR уже был отлаженный Allure Report в allure-docker-service, и на первом этапе мы не планировали отказываться от него. В качестве CI используется Jenkins, а для работы с эмуляторами — Argo Workflow (k8s). Тесты запускает форк Avito test runner. С такими вводными моя задача становилась проще.

У Allure TO есть богатая документация. Хотя в процессе ее изучения пришел к выводу, что нужного нам сценария использования «из коробки» нет и потребуется дорабатывать интеграцию. На момент написания статьи мы работали с версией 3.193.0. При этом хотелось как можно больше задач переложить на Continuous Integration (CI).

Сначала о наших ожиданиях

Одна из ключевых целей перехода на Allure TO — мигрировать бесшовно и быстро. Внутри есть много всего «из коробки», интеграции с кодом и хорошая аналитика. Немаловажно, что TMS сделана в России, а значит не предвидится проблем с отключением и оплатами.

Желаемое нами поведение, аналог которого был ранее сделан для TestRail и которое предстояло поддержать для Allure TO:

Минимально зависеть от Jenkins-плагинов, поскольку мобильные автотесты запускались в инстансе Jenkins, который имел ряд инфраструктурных ограничений, и на их преодоление могло уйти немало времени. Поэтому несмотря на использование Jenkins планировалось взять allurectl вместо плагина.

allurectl

allurectl – оболочка командной строки для API.

С помощью аннотации @AllureId и идентификатора тестового сценария должна быть реализована связь между тест-кейсом и автотестом. В Allure TO это разные сущности, но каждая из них может иметь такое свойство, как результат тестирования.
Если отведена ветка Release Candidate, то метаинформация автотестов первого multibranch pipeline отправляется в allure-docker-service, а также создается launch по фильтру тест-кейсов, и к нему загружается эта же метаинформация. Плановые релизы у нас обычно происходят раз в неделю.

Метаинформация

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

Launch

Launch – результаты тестирования в рамках одного или нескольких прогонов тестов. Аналог Test Run в TestRail.

Фильтр тест-плана будем хранить в коде. Фильтр будет находить как автоматизированные, так и неавтоматизированные тест-кейсы. Тестовый набор будет пересчитываться по мере добавления новых сценариев от релиза к релизу. Это то важное, аналог чего мы не нашли в существующих интеграциях.
В день релиза автотесты запускаются ночью, и к началу рабочего дня должен быть launch с результатами. Неавтоматизированные тест-кейсы ожидаемо допроходим вручную и выносим решение о готовности приложения к релизу.
Проставление статуса каждым конкретным автотестом в реальном времени для launch’ей не требуется, так как ветку Release Candidate отводим ночью. Результаты автотестов загрузим разом в конце пайплайна.

Уже в процессе исследования я выяснил, что в используемом нами test runner возможность штучно запускать автотесты требует доработки. Поэтому если будет X красных тестов, то в первое время для таких тестов мы будем вручную делать Rerun с флагом Force manual силами QA-инженеров.

Одной из задач, которые предстояло решить, была необходимость заменить самописную TestRail-аннотацию @CaseIdна коробочную аннотацию @AllureId.

// Было
import com.deliveryclub.utils.testrail.CaseId                       
@CaseId(12345)
@Test    fun checkThat() { }

// Стало
import io.qameta.allure.kotlin.AllureId
@AllureId("67890")
@Test    fun checkThat() { }

Отмечу, что ранее в процессе работы с TestRail-аннотациями не использовались какие-либо инспекции IDE, поэтому при переходе мы узнали, что не везде был проставлен @CaseId, и в этой части предстояло наверстать упущенное, расставив идентификаторы тест-кейсов.

Далее рассмотрим доступные сценарии использования «из коробки»

1. Без ручных операций при подготовке launch’а

А. TestCase as code — тест-кейсы хранятся в коде, а значит запускаются вместе со всеми автотестами. Такие ручные тесты не будут взаимодействовать с приложением, поэтому будут исполнены быстро и отражены в Allure TO с необходимостью пройти их вручную. Источник правды для тестовой документации в таком случае один, и процесс актуализации тестов становится неразрывным. Получается близкое к идеалу решение, но если уже есть тысячи тест-кейсов, то перенести их в код и мотивировать всех QA-инженеров работать через Git будет не самой простой задачей.

2. С ручными операциями при подготовке launch’а

А. QA-инженер выбирает в launch’е нужные тест-кейсы, которые уже были автоматизированы, и запускает их по кнопке в интерфейсе Allure TO.

B. Либо создается launch только из автотестов, и по его завершении QA-инженер вручную добавляет недостающие ручные тест-кейсы.

C. Либо создается launch только из автотестов, и по его завершении QA-инженер вручную объединяет его с другим launch’ем из недостающих ручных тест-кейсов.

Варианты 2A, 2B и 2C не подойдут нам, так как мы осуществляем запуск автотестов ночью и к утру хотим видеть их результаты, а также все ручные тест-кейсы, которые следом предстоит пройти.

Базовая интеграция

0. Скачивание allurectl

Указываем в ожидаемом состоянии Infrastructure-as-Code-инструмента подходящий дистрибутив allurectl.

1. Наши скрипты

Создаем тест-план ручных и автоматических тестов. Запускаем его и получаем сущность launch. После запуска launch’а удаляем тест-план.

PLATFORM_NAME="ANDROID"
ALLURE_TESTOPS_HOST="https://alluretestops.domain"
ALLURE_TESTOPS_PROJECT_ID=1
ALLURE_TESTOPS_TREE_ID=10

ALLURE_TESTOPS_TESTPLAN='cf["Suite"] != "SomeSuite" and tag != "SomeTag" and status != "Outdated" '      
# При решении задачи мы поддержали создание динамического тест-плана    
# по фильтру на основе встроенного Allure Query Language (он же AQL/RQL)

if [[ "$CAN_SEND_TO_TMS" == "true" ]]; then
  ALLURE_LAUNCH_ID=$(python3 our_scripts/create_launch.py \
    --allure_host "$ALLURE_TESTOPS_HOST" \
    --allure_token "$ALLURE_TESTOPS_TOKEN" \
    --branch_name "$BRANCH_INPUT" \
    --commit_hash "$COMMIT_HASH" \
    --allure_project_id "$ALLURE_TESTOPS_PROJECT_ID" \
    --allure_tree_id "$ALLURE_TESTOPS_TREE_ID" \
    --platform_name "$PLATFORM_NAME" \
    --base_rql "$ALLURE_TESTOPS_TESTPLAN")
fi

Детали our_scripts/create_launch.py

У инструмента есть swagger-ui, в котором мы нашли нужные нам endpoint’ы для реализации желаемого поведения в скрипте. Написанный код был достаточно простым, поэтому привожу только сами endpoint’ы:

1. POST /api/rs/testplan с важным для нас параметром "baseRql"
2. POST /api/rs/testplan/{testplan_id}/run возвращающий "launch_id"
3. DELETE /api/rs/testplan/{testplan_id}

Флаг CAN_SEND_TO_TMS

В следующем блоке кода Jenkins pipeline вычисляется необходимость выгружать отчет в Allure TO. Выгружаем только один раз для первой успешной сборки, поэтому пытаемся найти ее среди предыдущих сборок multibranch pipeline.

def can_send_to_tms() {
    previous = currentBuild.getPreviousBuild()
    while (previous != null) {
        if (previous.result == 'UNSTABLE' || previous.result == 'SUCCESS') {
            return false
        }
        previous = previous.getPreviousBuild()
    }
    return true
}

2. Запускаем тесты и ждем завершения

3. Загружаем разом все результаты

allurectl upload --launch-id "$ALLURE_LAUNCH_ID" \
      --endpoint "$ALLURE_TESTOPS_HOST" \
      --token "$ALLURE_TESTOPS_TOKEN" \
      --project-id "$ALLURE_TESTOPS_PROJECT_ID" \
      "ci/k8s/allure"

Возникшие проблемы

Skipped-тесты

@Ignore

@Ignore (skipped) — аннотация в коде, которая сообщает test runner об отсутствии необходимости запускать конкретный автотест.

LiveDoc

LiveDoc — автоматическое создание документации тестирования на основе результатов автотестов. В основе этой функциональности лежит идея TestCase as code.

Несколько возникших проблем были связаны с автотестами, отмеченными @Ignore. В документации сказано:

Now, this is important. In order to proceed to further steps, your build job needs to be started at least once, so Allure TestOps server will start gathering the information about your tests.

Как оказалось, требование первичной синхронизации не охватывает skipped-автотесты, и после отработки LiveDoc у нас начала расходиться структура.

Также после загрузки результатов автотестов и закрытия launch’а с включенным LiveDoc неожиданно появляются тест-кейсы из skipped-автотестов.

Так как мы в тот момент не были готовы к TestCase as code, то временно в Update policies задали использование всех полей из тест-кейсов вместо полей из автотестов.

И все же для синхронизации AllureId мы были вынуждены периодически включать и снова выключать LiveDoc с последующим удалением пустых тест-кейсов. Забегая вперед, скажу, что мы уже ушли от этой ручной операции. Если не синхронизировать AllureId, то тест-кейс ничего не будет знать про соответствующий ему новый автотест.

В качестве первого решения ребята из Qameta предложили нам не загружать skipped-автотесты, но мы выяснили, что наличие метаинформации для skipped — это стандартное поведение адаптера. Желающие могут посмотреть официальный пример allure-junit4-gradle-kts.

Адаптер

Адаптер – надстройка test runner, позволяющая собирать метаинформацию во время выполнения автотестов.

В качестве второго решения нам предложили хак @AllureId("-1"), который препятствует созданию тест-кейсов из skipped, а также позволит присвоить тесту признак Orphan, который можно отфильтровать перед началом ручного тестирования и дать скорректированную ссылку с параметром на launch для QA-инженера:

Мы подумали, что @AllureId("-1") не способствует читаемости автотеста и предсказуемости поведения самой Allure TO.

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

В итоге в качестве временного решения выбрали первый вариант и доработали форк test runner, чтобы в Allure TO не загружать skipped, но при этом загружать в allure-docker-service при PR с сохранением возможности контролировать такие тесты. Пример изменений прикладываем в ознакомительных целях.

Сюрприз LiveDoc

Предположим, что все тест-кейсы перенесены из TestRail, или уже написано много новых. Далее они связываются с автотестами по идентификатору. Мы решаем загрузить результаты автотестов и закрыть launch, чтобы в первый раз пройти вручную весь сценарий. Казалось бы, что может пойти не так? Видимо, Qameta предполагала, что пользователь изучит не только блок Quick start, а сразу всю документацию. Если предварительно в настройках вы не «выключите костылем» фичу LiveDoc или не сконфигурируете все типы полей в Update policies (описано выше), то будьте готовы к тому, что автотесты перезапишут поля всех связанных тест-кейсов, и это породит хаос.

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

Выводы

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

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

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

Думаю, что поведение Allure TO может быть доработано ради упрощения работы пользователя со skipped-автотестами и подстраховки на стороне UX от неожиданной потери данных после срабатывания LiveDoc. Предварительно, ребята из Qameta согласны с необходимостью таких доработок в продукте.

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

Теги:

Хабы: