Этот текст предназначен для начинающих тестировщиков, желающих понять как делать отчеты на allure с историей тестов, также разъяснить где их хранить, чтобы в отчет мог заглянуть любой участник вашей команды.  Рабочий репозиторий с финальной версией рабочего кода и инфраструктуры Ссылка на отчеты после прогона тестов Когда я хотел добавить в gitlab автотесты в стеке python, allure, docker, то я выяснил, что толковых статей на эту тему нет. Пришлось разбираться самостоятельно и как результат проб и ошибок появилась эта статья, которая скорее является гайдом, частично затрагивающим написание тестов, но наибольший фокус именно на выстраивании инфраструктуры. Если у вас уже написаны тесты на allure, то вы сразу можете переходить к разделу настройки инфраструктуры. Отмечу, что текст НЕ затрагивает написание UI тестов, но я затрону инфраструктуру для них в отдельном блоке. Здесь не описаны лучшие практики по написанию тестов и выстраиванию инфраструктуры. Скорее ознакомление с тем, как можно все это организовать. Примеры выполнены на windows, на других системах подход примерно такой же. Этот гайд предполагает, что у вас уже установлен python, настроен пустой репозиторий, куда вы будете отправлять свой код. При чтении статьи не обязательно знать pytest, но очень желательно знать что из себя представляет фикстура, как ей пользоваться, а так же параметризация тестов. Для тестирования будет использован Dog API. Если вас интересует локальный запуск тестов через gitlab, то вам необходимо установить docker. Если у вас не установлено вышеперечисленное ПО, то ниже вы можете найти полезные ссылки: Я назвал свой репозиторий для этой статьи allure_pages и скопировал его на свой компьютер. Нужно создать такую структуру в директории с репозиторием:  Далее создаем виртуальное окружение, которое будет использоваться для локального запуска тестов. В папке с проектом создаем его через командную строку с помощью следующей команды: python -m venv venv Открываем папку с репозиторием как проект в PyCharm  Удобнее всего, на мой взгляд устанавливать нужные нам пакеты через встроенный в PyCharm терминал. Для этого нужно добавить интерпретатор, и открыть терминал.  Устанавливаем нужные пакеты для наших тестов в виртуальном окружении: Для этого введите в терминал следующие команды. Очень важно после этого написать в терминале
pip freeze > requirements.txt.  Для того, чтобы упростить наши тесты создадим небольшой клиент для GET и POST запросов. Далее будет подробное описание этого клиента. Если вам это не нужно или кажется сложным, то пропустите эту часть статьи и переходите к следующей. На примере её использования станет ясно как пользоваться клиентом. Сама фикстура Ниже конструктор класса для клиента. При инициализации объекта класс принимает в себя аргумент base_address, на его место нужно записать в фикстуре общий адрес для всех запросов в нашем случае будет использован https://dog.ceo/api/. Обратите внимание, что фикстура возвращает объект с базовым адресом для дальнейших GET и POST запросов. Добавим в класс метод GET для отправки запросов. Здесь можно заметить, что наш клиент является оберткой над библиотекой requests. В классе ApiClient аргументы path, params, headers метода get выступают в роли аргументов, которые передаются в requests.get(url=url, params=params, headers=headers). Именно эта строчка и отвечает за выполнение запросов. Из адреса, использованного при инициализации объекта и пути, который мы передадим в дальнейшем в ходе теста, будет складываться полный адрес, который и будет использоваться в requests.get. Добавим в класс метод POST. Его логика идентична, просто добавляется несколько аргументов, которые при желании можно заполнить данными. В итоге у нас получается такой файл conftest.py: В самом сервисе Dog API есть много разных запросов. Если у вас есть опыт в написании тестов, то можете самостоятельно написать несколько тестов. Так как акцент в этой статье заключается в постройке инфраструктуры для тестов, я не буду вдаваться в подробности тестов. Ранее я это сделал, чтобы мой код был более менее понятен. Несколько параметризованных тестов специально сломаны, чтобы показать как они будут показаны в отчете. Так выглядит мой файл с тестами test_dog_api.py Есть много разных подходов к написанию тестов с помощью allure. Так как сейчас рассматривается больше инфраструктура, то добавим совсем простые шаги. Для понимания написанного мною кода, я все же прокомментирую несколько моментов.  with allure.step('step 1'): — с помощью этого контекстного менеджера тело теста делится на шаги, понятные в отчете.
@allure.feature('Dog Api') @allure.story('Send few requests') — декораторы, с помощью которых сами тесты или тестовые наборы будут структурированы в отчете Добавим в наш API клиент несколько allure шагов. Добавим декораторы в тесты и снабдим их шагами. Так же добавлю излишние шаги, чтобы показать зависимость генерации отчета от кода. Здесь не описаны лучшие практики по написанию текста для шагов. Текст намеренно неформальный для простоты восприятия кода и отчета.  Сходным образом заполним шагами и декораторами остальные тесты. Финальный файл test_dog_api.py Здесь есть несколько моментов, о которых стоит написать: Если у вас в компании уже настроена инфраструктура и вы можете попросить своего devops выделить вам раннер где-то в облаке, то сделайте это. Раннер можно использовать и локально на своем компьютере. В этом случае вам нужен установленный docker desktop на windows. В этом гайде мы будем использовать локальный раннер, но для облачного запуска вам нужно будет просто указать в .gitlab-ci нужный раннер. Сам репозиторий должен быть публичным, если вы используете gitlab.com. Если вы используете именно gitlab.com, то настраивать по тексту ниже не нужно. По умолчанию репозиторий уже будет готов ко всему, что нам понадобится для инфраструктуры. Нужно зайти в настройки репозитория Settings -> General -> Visibility, project features, permissions, активировать Pipelines и сохранить изменения.  После этого в разделе настроек появится раздел CI / CD. Переходим Settings -> CI / CD -> Runners  Здесь переходим по ссылке в пункте 1 и согласно инструкции ставим себе на компьютер Gitlab Runner. Далее в статье адаптация инструкции на русском. Ниже инструкция, которую вы можете найти здесь. Можете пройтись по ней самостоятельно. Далее в тексте будет сделано все по инструкции. С первыми тремя пунктами инструкции все понятно. Создаем папку, кладем в неё переименованный раннер и запускаем в директории powershell, то с четвертым и пятым пунктом могут возникнуть проблемы и недопонимание, если не потратить некоторое время на чтение документации. Далее простыми словами описаны шаги, которые нужно сделать, чтобы раннер заработал. Я создал папку C:\gitlab_runners и сохранил туда скачанный для моей системы раннер, предварительно переименовав в gitlab-runner.exe Как только вы справились с первыми тремя пунктами, то нужно сделать следующее: Скрншот с выполнеными шагами  Наш раннер зарегистрирован, теперь его нужно запустить. Проверить статус раннера можно так:
.\gitlab-runner.exe status Запустите раннер с помощью:
.\gitlab-runner.exe run Теперь, если вы зайдете в настроки раннеров в репозитории Settings -> CI / CD -> Runners, то увидите что-то такое:  Это означает, что у репозитория есть линк с раннером и он видит его статус. Осталось добавить чекбокс в раннере. Для этого нужно нажать на карандаш рядом с именем раннера в гитлабе.  Все хорошо, теперь можно перейти к пайплайну. Инструкции для раннера описываются в .gitlab-ci.yml. Полная документация описана здесь. Первым делом нам нужно описать stages. Шаги пайплайна. Их будет 4. Каждый stage — отдельный job, который будет выполнять раннер.  Шаг первый. Testing Шаг второй. history_copy Шаг третий. reports Шаг четвертый. deploy Финальный .gitlab-ci.yml Осталось отправить в репозиторий все необходимые файлы, а именно: Отправляем и смотрим что получилось. В первый раз пайплайн будет запускаться немного дольше, чем в следующие разы. Потому что ему нужно будет скачать нужные образы, запустить их и все такое. Заходим в репозиторий и через сайдбар переходим в CI / CD -> Pipelines Здесь вы сможете увидеть статус пайплайна, а также перейти к Ci линтеру, где можете проверить конкретно свой .gitlab-ci.yml.  
 Когда пайплайн пройдет, увидеть ссылку и сам отчет можно через Settings -> Pages. При первом использовании pages в репозитории для просмотра страницы может понадобиться до 30 минут. Проходим по ссылке и смотрим отчет.  Получаем результат. Советую побродить по отчету и посмотреть результаты.   Сломаем несколько тестов, чтобы посмотреть, как будет отображаться история тестов. Затем подождем окончания пайплайна.  Как видите второй шаг в этот раз выполнился без ошибок. Это потому, на stage history_job проблем с копированием истории предыдущих пайплайнов не возникло. Теперь посмотрим результат тестов.  Видна динамика, количество упавших тестов и все остальное. Для просмотра подробностей по тестам рекомендую посмотреть отчет самостоятельно.   Реализовать их можно с помощью специальной сущности гитлаба [services](https://docs.gitlab.com/ee/ci/services/). Это ключевое слово для использования докер образов, которые будут запущены до хода шагов в script. Для UI тестов нужно добавить в job пайплайна следующее: Так как нам нужно обращаться к контейнеру, который поднимет гитлаб по определенному url, то он каким-то образом назначает этому сервису url, по которому можно слать запросы. Логика здесь такая: И теперь нужно изменить в фикстуре executor (по умолчанию используется chromedriver на вашей машине, но сейчас мы все это запускаем в контейнерах) для запуска ui тестов: Обратите внимание, что было в .gitlab-ci.yml:
selenium/standalone-chrome:latest
И по какому адресу нужно обращаться фикстуре для запуска тестов:
selenium__standalone-chrome Для запуска моих тестов у меня получился такой job. Если добавить к нему три следующих job из примера с api тестами, то можно прогнать все тесты и получить отчет. Помимо ссылок в статье, хочется поделиться еще несколькими, которые могут помочь в работе с allure и gitlab ci. Пример этого проекта на гитлабе
Ссылка на отчеты после прогона тестов
Статья об allure на хабре
Введение в gitlab ci UPD: Спасибо комментаторам, за то, что указали мне на неточности и неполноту этого гайда. Я поправил и добавил ссылку на рабочий репозиторий QA