Как запускать автотесты

Организация автоматического запуска автотестов с использованием Downstream pipelines в GitLab CI

Привет, Хабр! Меня зовут Андрей, я SDET-специалист SimbirSoft. В практике CI/CD один из общепринятых стандартов — настройка автоматического запуска автотестов при деплое сервиса на стенды. То есть при запуске сборки мы сразу видим, как пройдут смоук-автотесты, и на основе отчета решаем, передавать сборку дальше QA-команде или дорабатывать. Это упрощает работу команды и позволяет быстрее исправлять ошибки, что критично важно для бизнеса.

Мы разберем автоматический запуск автотестов с использованием Downstream pipelines в GitLab CI на примере проекта с несколькими микросервисами. Они должны триггерить разные группы автотестов, а также имеют разные точки входа, то есть базовые URL. Выглядит это так:

Пайплайн сборки сервисов

Допустим, .gitlab-ci.yml в сборке микросервиса выглядит так:

stages: - build - deploy - test build job: stage: build script: - echo "Build service" deploy job: stage: deploy script: - echo "Deploy service" when: on_success

Сервис при сборке хранит в переменных среды необходимый URL, который далее станет точкой входа для автотестов (например, app.testing.com или app.staging.com). Если этого URL в переменных нет, вы можете добавить разные переменные для разных окружений в настройках этого пайплайна. Сделать это можно в UI GitLab тут Setting -> CI/CD -> Variables, например PARENT_URL для разных Environment scope.

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

Для чего нужен автономный запуск? Когда мы написали новый тест-сьюит, и его запуск успешно прошел локально, необходимо проверить, как его прогон пройдет в CI/CD, так как там автотесты могут упасть. Это может быть связано с тем, что под капотом Selenoid автотест может работать иначе, или скорость обработки данных БД чрезмерно высока, и в неё не успевают прилетать сообщения из другого сервиса.

Чтобы автотесты запускались автоматом при деплое сервиса, и при этом сохранялась необходимая автономность, мы будем использовать Downstream pipelines.

Добавляем в .gitlab-ci.yml сборки микросервиса триггер для запуска автотестов:

testing_job: stage: test variables: PARENT_MARK: "smoke_service_a" # Здесь Вы можете указать метку, которую хотите передавать в автозапуск тестов # Для второго микросервиса здесь будет соответственно PARENT_MARK: "smoke_service_b" PARENT_URL: "https://rickandmortyapi.com/api" # Здесь я имитирую передачу сервисом необходимого URL trigger: ansid63/just_ci rules: - if: $CI_COMMIT_BRANCH == "main"

В trigger мы передаем путь к нашему проекту с автотестами в GitLab CI. Поле rules в данном случае устанавливает условие, что автотесты необходимо триггерить при мерже в ветку main.

Пайплайн проекта с автотестами

Переходим к проекту с автотестами. Я сделал небольшой проект с API тестами для проверки работы связки пайплайнов:

В проекте должен быть подключен GitLab Runner. Если вы запускаете проект на gitlab.com, возможно, вам будет достаточно Runner, предлагаемого сервисом GitLab.

В conftest.py я выдергиваю базовый URL для запуска автотестов:

from pytest import fixture def pytest_addoption(parser): parser.addoption( "--url", action="store", default="https://rickandmortyapi.com/api") @fixture() def url(request): return request.config.getoption("--url")

Dockerfile собирает контейнер с автотестами и зависимостями, в автотестах используются библиотеки pytest и requests.

FROM python:3.9.13-slim COPY . . RUN pip3 install -r requirements.txt --no-cache-dir 

Папка tests содержит один файл с автотестами.

Давайте разберем пайплайн в .gitlab-ci.yml проекта с автотестами:

stages: - build # Этап сборки контейнера с автотестами и зависимостями - test # Этап запуска автотестов variables: TEST_MARK: value: "smoke_service_a" # Дефолтная mark для pytest TEST_PATH: value: "tests" # Т.к. мы прокидываем --url, pytest очень просит указать путь к местоположению тестов TEST_URL: value: "https://rickandmortyapi.com/api" # Дефолтный URL для pytest AQA_GIT_TAG: v0.1.0 # Тэг для контейнера с автотестами AQA_IMAGE: "$/autotests:$" # Путь к контейнеру с автотестами .docker-registry: &docker-registry - echo $CI_REGISTRY_PASSWORD | docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY # Шаблон для авторизации в СI registry build_autotest_image: # Данный этап с условием only позволяет нам собирать контейнер только при git push # и избежать постоянной пересборки контейнера при запуске автотестов. stage: build image: gitlab/dind services: - docker:dind before_script: - *docker-registry # Авторизация в СI registry script: - docker build -t $ . # Собираем контейнер с автотестами и зависимостями - docker push $ # Пушим контейнер в СI registry only: refs: - pushes # Сборка контейнера происходит только при git push в проекте с автотестами test job 1: # Запуск автотестов при триггере от сборки микросервиса stage: test image: "$" script: - pytest -m $PARENT_MARK $TEST_PATH --url $PARENT_URL # Запускаем автотесты rules: - if: $CI_PIPELINE_SOURCE == "pipeline" # Согласно данному правилу, этот процесс запускается в случае, если пайплайн триггериться test job 2: # Запуск автотестов при ручном запуске stage: test image: "$" script: - pytest -m $TEST_MARK $TEST_PATH --url $TEST_URL # Запускаем автотесты rules: - if: $TEST_FROM == "handheld" # Запуск происходит когда в Run Pipeline передаем TEST_FROM == "handheld"

Запуск автотестов

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

Если автотесты пройдут с ошибками, билд будет обозначен как failed и подсветится красным. Таким образом команда разработки получит информацию о работоспособности данного конкретного билда системы. В случае, если вы не хотите «фейлить» деплой, а лишь подсветить, что прогон автотестов прошел с падениями, следует добавить allow_failure: true в джобу stage: test.

Если мы хотим запустить автотесты для дефолтных значений в нашем проекте с автотестами, мы переходим во вкладку CI/CD GitLab, нажимаем Run pipeline. В появившемся окне необходимо выбрать branch, а в Variables добавить TEST_FROM со значением handheld, нажать кнопку Run pipeline. В качестве результата вы получите прогон автотестов с меткой smoke_service_a и дефолтным URL https://rickandmortyapi.com/api.

Если вам нужна более гибкая настройка и нужен запуск ветки develop, метки smoke_service_b, файла с автотестами по пути tests/test_api.py::TestRickAndMortyApi и с определенным входным URL, это можно сделать так:

Нажимаете Run pipeline, получаете необходимый вам запуск автотестов. В чем плюс этого подхода — он даёт вам высокую гибкость относительно вариантов запуска.

Вместо вывода

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

Если вы используете один стенд для запуска автотестов, и прогон автотестов необходим при сборке одного сервиса, можно также использовать Downstream_pipelines для автономности проекта с автотестами.

Спасибо за внимание!

Полезные материалы для разработчиков мы также публикуем в наших соцсетях – ВКонтакте и Telegram.

Запуск автотестов из Test IT в интеграции с фреймворком PyTest и Gitlab CI

Система управления тестированием Test IT позволяет работать в одном интерфейсе с ручными и автоматизированными тестами. Можно связывать автотесты с тест-кейсами и хранить информацию в системе, запускать наравне с ручными и анализировать результаты запусков. Результаты автоматически проставляются в TMS-системе с треком ошибок и скриншотами, что удобно при анализе тест-планов. Неважно, на каком языке написаны ваши автотесты, а также какую CI-систему вы используете. Test IT может интегрироваться практически с любыми фреймворками и инструментами. В этой статье-инструкции подробно объясним, как связать автотесты на Pytest с Gitlab CI и Test IT и потом с этим работать.

Алгоритм работы выглядит следующим образом:

1. Подготовка к интеграции
2. Настройка GitLab
3. Создание gitlab-ci.yml
4. Получения токена
5. Настройка рабочего проекта Test IT
6. Настройка webhook в Test IT
7. Запуск тест-рана из Test IT
8. Проверка журнала логов webhook
9. Пайплайн с GitLab
10. Выполнение пайплайна
11. Завершение пайплайна
12. Проставление результатов в Test IT

Запись вебинара об интеграции автотестов на Python в Test IT

Ниже распишем каждый шаг подробнее.

Подготовка

Для начала интеграции требуется:

• Рабочий проект в системе Test IT со слинкованными между собой тест-кейсами и автотестами
• GitLab репозиторий со следующим наполнением:

1. файл requirements.txt с указанием пакетов для установки ( pytest, testit-adapter-pytest, testit-api-client )
2. актуальные автотесты (код автотестов должен отражать ситуацию в рабочем проекте Test IT)

Пример актуального автотеста:

• в системе Test IT тест-кейс с глобальным идентификатором 55 связан с автотестом с идентификаором автотеста externalID8

• GitLab имеет автотест с декораторами externalID externalID8 и workItemID 55 , что отражает ситуацию в рабочем проекте Test IT

Настройка GitLab репозитория

Создание .gitlab-ci.yml:

Необходимо перейти во вкладку CI/CD > Editor и настроить .gitlab-ci.yml файл для установки необходимых пакетов из файла requirements.txt и запуска автотестов с необходимыми переменными окружения.

Пример .gitlab-ci.yml файла (нужно прописать через параметры командной строки использование переменных окружения):

Получения токена:

Перейдите во вкладку Settings > CI/CD > Pipeline triggers и добавьте trigger (Description можно указать любым).

Настройка рабочего проекта Test IT

Настройка webhook в Test IT:

Перейдите во вкладку во вкладку Project Settings > WebHooks и добавьте новый WebHook.

Настройки WebHook:

• установите активацию вебхука при запуске автотестов
• установите POST-запрос следующим образом:

где DOMAIN — инстанс, где располагается репозиторий GitLab;

PROJECT_ID — глобальный идентификатор репозитория GitLab

• в URL parameters установите следующие передаваемые параметры:

1. ref = название ветки GitLab репозитория с автотестами
2. token = token триггера, который был создан в шаге 2 при настройке GitLab-репозитория
3. variables[URL] = $SERVER_URL
4. variables[TEST_RUN_ID] = $TEST_RUN_ID
5. variables[PRIVATE_TOKEN] = API secret key из профиля Test IT

Пример рабочего WebHook:

Запуск тест-рана из Test IT

Проверка журнала логов вебхуков

Пайплайн с гитлаба

Выполнение пайплайна

Завершение пайплайна

Проставление результатов в Test IT

Была ли статья полезной?

# Запуск автотестов из UI

Если вы создали автотесты в системе Test IT, вы можете запускать их из пользовательского интерфейса (UI). Данный тип запуска может быть осуществлен автономно от тест-планов.

1. Откройте проект.
2. Перейдите в раздел Автотесты.
3. Отметьте флажками автотесты, которые хотите запустить.
4. В появившейся над списком панели нажмите значок запуска автотестов.
5. Выберите конфигурации, для которых хотите запустить автотесты.
6. Нажмите Сохранить.

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

# Запуск из тест-планов

После того, как вы добавили автотесты в систему Test IT и привязали их к тест-кейсам, вы можете запускать автотесты прямо из системы управления тестированием во время выполнения тест-плана. Чтобы запустить автотесты:

1. Откройте проект.
2. Перейдите в раздел Тест-планы.
3. Откройте тест-план.
4. В окне тест-плана перейдите на вкладку Выполнение.
5. Нажмите Фильтр над таблицей тест-поинтов и в поле Статус автоматизации выберите Автоматизированный. В списке отобразятся только автоматизированные тест-поинты.
6. Отметьте флажками автотесты, которые хотите запустить.
7. Нажмите Запустить автотесты.

В случае ошибок автотестов, проанализируйте причину их результатов: инфраструктуру, автотесты или продукт.

Архитектура автотестов с нуля и почти без магии

Порассуждаем, как вообще подступиться к тестам на проекте, как развернуть полноценную архитектуру и стараться поддерживать работоспособность.

Стек: Java, Selenide, Allure, Jenkins

Давайте не будем говорить о конкретном проекте, а представим ситуацию в вакууме? Рано или поздно каждый тестировщик сталкивается с довольно масштабным продуктом, который с каждым релизом все сложнее и сложнее тестировать вручную. И вот, вы уже не помните, когда в последний раз проводили регрессию, потому что времени на нее все нет; не знаете, когда же это время появится; и все больше и больше ощущаете гнетущую ауру багов, скрывающихся в том функционале, до которого никак не доходят руки. Смоук занимает сначала 4 часа, потом день, потом полтора и вы, наконец, решаетесь: «Тут нужны автотесты!».

Представим, что и команда, и заказчик прыгают от радости и выделяют вам целые 20 часов неделю на протяжении некоторого отрезка времени, за которые вы можете заняться «этими самыми автотестами». Но что же делать дальше?