Интеграция облачной версии платформы ТестОпс с GitHub Actions позволяет автоматизировать запуск тестов и сбор результатов в единой системе. В этом руководстве мы пошагово настраиваем трёхстороннюю связку: результаты запуска GitHub Actions отправляются в TMS ТестОпс, из ТестОпс можно инициировать запуски workflow на GitHub, а с помощью MCP обеспечивается интеллектуальная интеграция и автоматизация процессов между всеми системами. В статье рассматриваем требования к окружению, генерацию необходимых токенов, изменение конфигурации рабочего процесса, настройку параметров окружения и возможные ошибки.
⚡️ Внимание! Это 1-я часть из серии статей, посвящённых настройке связки MCP + GitHub + ТестОпс. В этом материале подробно разбирается сопряжение GitHub и ТестОпс — как настроить интеграцию, автоматизировать запуск тестов и передачу результатов. Во второй части рассматриваем связку GitHub с MCP: как подключить MCP-сервер, интегрировать его с GitHub и использовать возможности AI-инструментов для автоматизации и контроля CI/CD процессов.
Подготовка окружения
При подготовке этого руководства мы установили и настроили все нужные компоненты: рабочую среду на ОС Ubuntu (но это не критично для настройки, просто автору было удобнее), учётные записи в GitHub и ТестОпс, а также редактор кода Cursor IDE с поддержкой дополнительных функций. Каждый шаг, описанный в статье, был выполнен и проверен — от регистрации аккаунтов и установки программ до настройки связи между ними и запуска тестов. Все команды, рекомендации и примеры основаны на реальных действиях.
Требования к окружению
Прежде чем приступить, убеждаемся, что у нас есть доступ к необходимым системам и выполнены базовые шаги:
- IDE: Cursor IDE (или VS Code с плагином).
- Программное обеспечение: Git, Java 8+ и Node.js 14+.
- Аккаунт в GitHub: зарегистрированная учётная запись.
- Аккаунт в ТестОпс: учётная запись в облачной версии, права администратора для настройки интеграций. Важно зафиксировать актуальный ID проекта – его можно увидеть перед названием проекта в интерфейсе или в URL адресной строки. Например, в адресе .../project/7/launches, где цифра 7 – это ID проекта.
- GitHub Actions Runner: для запуска рабочих процессов (workflow).
С таким рабочим окружением для настройки интеграции GitHub, ТестОпс и Cursor IDE мы переходим к созданию тестового локального проекта, генерации токенов и конфигурации CI/CD.
Создание тестового локального проекта
I. Создаём папку для проекта и переходим в неё.
Выбираем удобную директорию на диске и выполняем команду для создания новой папки (заменяем <project-name> на актуальное название проекта):
mkdir ~/workspace/<project-name>
cd ~/workspace/<project-name>II. Инициализируем репозиторий Git.
Открываем терминал и запускаем команду:
git initIII. Инициализируем npm-проект.
npm init -y # флаг `-y` = «ответить “yes” на все вопросы»IV. Устанавливаем Jest и репортёр Allure.
Иногда пакет jest-allure2-reporter может отсутствовать в публичном регистре npm (например, при использовании корпоративного зеркала). В этом случае можно использовать альтернативу — пакет @shelex/jest-allure2-reporter, который поддерживает тот же API.
- Рекомендуемый адаптер:
npm i --save-dev jest jest-allure2-reporter- Альтернатива (Shelex):
npm i --save-dev jest @shelex/jest-allure2-reporterV. Настройка тестового скрипта.
Находим блок "scripts" в package.json и заменяем содержимое:
"scripts": {
"test": "jest --reporters=\"default\" --reporters=\"@shelex/jest-allure2-reporter\" --outputDirectory=allure-results"
}Здесь мы говорим Jest использовать стандартный репортёр вместе с Allure, а результаты складывать в папку allure-results.
VI. Добавляем первый тест.
Создаём файл hello.test.js в корне проекта:
// hello.test.js
describe('Пример самого простого теста', () => {
it('всегда проходит', () => {
expect(true).toBe(true);
});
});VII. Запускаем тест.
npm testЕсли всё сделано верно — появится зелёный отчёт Jest и в каталог добавится папка allure-results.
✅️ Теперь проект готов: у нас есть Git‑репозиторий, package.json, папка результатов, а главное — команда npm test, которую потом обернёт allurectl watch.
Настройка репозитория на GitHub
Создание и настройка удалённого репозитория
1) Переходим на github.com и создаём новый репозиторий для проекта, нажав на кнопку New repository.
2) Открываем терминал и генерируем SSH-ключ:
2) Открываем терминал и генерируем SSH-ключ:
ssh-keygen -t ed25519 -C "[email protected]"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
cat ~/.ssh/id_ed25519.pub
3) Добавляем публичный ключ в настройки GitHub (Settings → SSH and GPG keys).
4) Проверяем подключение и отправляем первый коммит:
<div class="ql-code-block" data-language="plain"> git remote add origin [email protected]:`<login>`/`<repo>`.git</div><div class="ql-code-block" data-language="plain"> git add .</div><div class="ql-code-block" data-language="plain"> git commit -m "Первый тест"</div><div class="ql-code-block" data-language="plain"> git branch -M main</div><div class="ql-code-block" data-language="plain"> git push -u origin main</div>git remote add origin [email protected]:`<login>`/`<repo>`.git
git add .
git commit -m "Первый тест"
git branch -M main
git push -u origin mainhttps://qatools.ru/images/blog/guide-cursormcp+github+testops-pt1/screenshot-3.png
Генерация токенов
Cоздание GitHub Personal Access Token (PAT)
1) В настройках GitHub переходим в Settings → Developer settings → Personal access tokens.
2) Создаём Fine-grained токен.
3) Наделяем правами Actions и Issues (отмечаем пункты _Read и write), выбираем только нужный репозиторий.
4) Копируем токен и сохраняем его — он нужен для интеграции.
Получение API‑токена в ТестОпс
1) Заходим в ТестОпс.
2) Кликаем аватар в правом верхнем углу) и переходим в API-токены.
3) Даём название: github-actions → Создать.
4) Появится модальное окно с сгенерированным токеном. Копируем и сохраняем — этот токен нужен для настройки секретов в GitHub.
Настройка GitHub Actions
Создание и настройка рабочего процесса (workflow) для CI/CD через интеграцию allurectl
Основная цель = GitHub запускает тесты при каждом пуше, а результаты отправляются в ТестОпс.
YAML = фрагмент конфигурации, который говорит GitHub Actions о том, какие параметры может принимать рабочий процесс (workflow), если его запускают вручную через интерфейс GitHub или через интеграцию из ТестОпс. В данном случае, он позволяет передавать служебные параметры (ALLURE_JOB_RUN_ID, ALLURE_USERNAME) при запуске тестов.
1) Переходим в корень проекта через терминал и вводим команду:
cd ~/workspace/<project-name> # Указываем имя для папки проекта2) В корне проекта создаём папку .github/workflows и пустой файл.
mkdir -p .github/workflows
nano .github/workflows/tests.yml # откроется редактор nano. Можно заменить на любой редактор (Cursor, VS Code).3) Редактируем YAML-файл для описания рабочего процесса так, чтобы он был совместим с ТестОпс. Основные параметры включают объявление специальных параметров запуска, настройку переменных окружения и добавление шагов с allurectl.
4) Добавляем обязательные inputs для workflow_dispatch.
🔦 Примечание: В разделе, описывающем событие workflow_dispatch, нужно задать два специальных параметра запуска: ALLURE_JOB_RUN_ID и ALLURE_USERNAME. Эти параметры служебные – они заполняются системой ТестОпс при запуске из интерфейса. Если их не добавить, запуск рабочего процесса из ТестОпс будет невозможен и выйдет ошибка 422. О том, как с ними работать, рассказываем в разделе про параметризацию окружения.
5) Вставляем содержимое YAML-файла (как указано ниже) в окно редактора — аккуратно, YAML чувствителен к отступам.
6) Ниже приводим пример полного YAML-файла (в комментариях добавлены подсказки для кастомизации):
name: Test & Report # имя рабочего процесса видно во вкладке Actions
# Когда запускать
on:
push: # каждое изменение кода
workflow_dispatch: # запуск «по кнопке» (нужен для ТестОпс)
inputs:
ALLURE_JOB_RUN_ID:
description: ":)" # служебные поля ТестОпс, оставляем
ALLURE_USERNAME:
description: ":)"
# Переменные окружения
env:
ALLURE_ENDPOINT: https://testing.qatools.cloud
ALLURE_PROJECT_ID: 7 # ← важно заменить на реальный ID проекта
ALLURE_RESULTS: allure-results
ALLURE_TOKEN: ${{ secrets.ALLURE_TOKEN }}
jobs:
test:
runs-on: ubuntu-latest # можно указать любую версию ОС
steps:
- name: Check Allure Token
run: |
if [ -z "$ALLURE_TOKEN" ]; then
echo "ALLURE_TOKEN secret is missing"
exit 1
fi
- name: Клонируем код
uses: actions/checkout@v3
- name: Ставим Node
uses: actions/setup-node@v3
with:
node-version: 18
- name: Ставим зависимости
run: npm ci
- name: Ставим allurectl
uses: allure-framework/setup-allurectl@v1
with:
allure-endpoint: ${{ env.ALLURE_ENDPOINT }}
allure-token: ${{ env.ALLURE_TOKEN }}
allure-project-id: ${{ env.ALLURE_PROJECT_ID }}
- name: Запускаем тесты
run: allurectl watch -- npm test7) Сохраняем изменения в файле.
Добавление токена из ТестОпс в секреты репозитория GitHub
1) Открываем настройки (Settings) репозитория на GitHub.
2) Переходим в секцию Secrets and variables → Actions и нажимаем «New repository secret». Создаём новый секрет со следующими параметрами:
- Name (имя) – ALLURE_TOKEN (строго такое имя).
- Value (значение) – скопированный API-токен из ТестОпс.
3) Сохраняем секрет (кнопка «Add secret»).
4) Теперь GitHub Actions сможет использовать этот токен для отправки данных в ТестОпс. Обращаем внимание, что секреты шифруются GitHub’ом, в логе они не появятся.
5) Фиксируем изменения и отправляем их в репозиторий.
git add .github/workflows/tests.yml
git commit -m "CI: добавлен workflow Jest + Allure"
git pushПроверка GitHub Actions
После запуска рабочего процесса в GitHub Actions появится ссылка на отчёт в ТестОпс. Если всё выполено верно, то результаты тестов успешно отправляются и отображаются в проекте ТестОпс.
Переходим во вкладку Actions на GitHub. Должен стартовать первый запуск «Test & Report». Когда джоба дойдёт до шага Run tests, разворачиваем лог этого шага и прокручиваем в самый низ. Там можно увидеть строку вида: Allure report available at: <link> (ссылка на ваш проект в ТестОпс).
Подключение GitHub-интеграции в проекте ТестОпс
На данном шаге мы связываем полученный PAT с конкретным проектом в ТестОпс:
1) Открываем проект в ТестОпс (где должны выполняться интегрированные тесты).
2) Переходим в раздел Настройки проекта → Интеграции.
3) В списке доступных интеграций находим GitHub (тот, который добавляли на уровне администратора) и нажимаем Добавить интеграцию рядом с ним.
4) В появившемся окне вставляем токен, созданный на предыдущем шаге, в поле Токен.
5) Нажимаем Проверить соединение.
Если токен валиден и у ТестОпс есть связь с GitHub, через несколько секунд должно появиться сообщение «Соединение установлено».
6) Кликаем «Добавить интеграцию» для сохранения настроек.
Теперь проект ТестОпс авторизован для взаимодействия с GitHub. Приложение получит возможность вызывать GitHub Actions API – запускать указанный рабочий процесс и отслеживать его выполнение. В разделе Джобы проекта должна отобразиться джоба, соответствующая рабочему процессу GitHub (как правило, имя джобы совпадает с именем рабочего процесса или ID сборки). Напомним, в ТестОпс одна джоба соответствует одному рабочему процессу GitHub, а один запуск джобы – конкретному запуску рабочего процесса. Все новые запуски, инициированные с любой стороны, будут отображаться и в GitHub, и в ТестОпс, синхронизируя свой статус.
Параметризация и управление окружением
Интеграция позволяет передавать во время запуска дополнительные параметры окружения. Например, таким образом в интерфейсе ТестОпс можно задавать, на каком браузере или с какой версией продукта запустить тесты, а GitHub Actions принимает эти значения и использует в тестовом прогоне. Для этого необходимо настроить соответствие между входными параметрами рабочего процесса и переменными окружения в ТестОпс. Далее разбираем, как это сделать шаг за шагом.
Объявление входных параметров в рабочем процессе
Частично мы уже выполнили эту работу, добавив в YAML файл рабочего процесса секцию workflow_dispatch.inputs. В примере выше помимо обязательных служебных полей были объявлены TESTS_BROWSER и PRODUCT_VERSION. Можно добавить и любые другие параметры к тестам (например, адрес тестируемого стенда, фича-флаг и т.д.).
Также убеждаемся, что внутри рабочего процесса эти параметры действительно используются. Чаще всего их передают через переменные окружения в шаги сборки или тестов. Например, чтобы передать параметр браузера в тесты, можно установить переменную окружения в разделе env:
env:
TESTS_BROWSER: ${{ github.event.inputs.TESTS_BROWSER }}
PRODUCT_VERSION: ${{ github.event.inputs.PRODUCT_VERSION }}В результате тесты смогут считать эти значения из переменных окружения TESTS_BROWSER и PRODUCT_VERSION. Вся информация о запуске (включая такие переменные) будет отправлена через allurectl на сервер ТестОпс вместе с результатами тестов.
Создание глобальных переменных окружения в ТестОпс
Теперь перенесём знание о новых параметрах в систему управления тестированием. В ТестОпс есть сущность Окружение — глобальные переменные, которые можно использовать во всех проектах для описания контекстов запуска. Нам нужно завести имена переменных, соответствующие нашим параметрам.
1) В ТестОпс переходим в Администрирование → Окружение.
2) Для каждого нового параметра создайте глобальную переменную:
- Кликаем + Создать.
- Указываем название переменной (например, для TESTS_BROWSER можно назвать «Browser», для PRODUCT_VERSION – «Product Version»).
- Нажимаем Отправить.
После добавления всех необходимых глобальных переменных они появятся в списке.
Сопоставление параметров рабочего процесса с переменными в проекте
Глобальные переменные определены, теперь настроим проект так, чтобы считывать значения из контекста рабочего процесса и подставлять их в запуски тестов.
1) Открываем нужный проект в ТестОпс.
2) Переходим в Настройки проекта → Окружение.
3) Для каждого параметра:
- Нажимаем + Создать (если переменная ещё не отображается в списке). Если она уже есть, можно отредактировать.
- В поле Ключ указываем имя переменной окружения точно так же, как оно задано в workflow.
- В поле Переменная окружения выбираем из выпадающего списка соответствующее глобальное имя (такие как Browser или Product Version).
- Кликаем Отправить для сохранения.
После этого в настройках проекта появятся записи, связывающие ключи CI-пайплайна с глобальными переменными.
Добавление параметров к джобе в ТестОпс
На последнем этапе параметризации нужно отразить эти переменные в настройках джобы, которая связана с GitHub workflow:
1) На уровне проекта в ТестОпс переходим во вкладку Джобы и находим такую, что соотвествует GitHub Actions workflow (название обычно совпадает с именем workflow файла либо задано вручную). Кликаем на значок ⋯ рядом с ней и выбираем Настроить.
2) В настройках откроется окно с разделом Параметры. Здесь добавляем ранее созданные переменные. Нажимаем Добавить и заполняем поля для каждого параметра:
- Название — имя переменной окружения (ключ), такое же, как было указано ранее (например, TESTS_BROWSER);
- Значение — значение по умолчанию для данного параметра (например, chrome для браузера, номер версии продукта и т.д.); Это значение используется, если при запуске явно не указано другое.
- Переменная окружения — выбираем глобальную переменную из предыдущего шага (Browser для TESTS_BROWSER). Аналогичным образом добавляем все необходимые параметры и нажимаем Отправить для сохранения. После этого джоба станет параметризованной.
💡 Совет: Следует задавать одинаковые значения по умолчанию параметров и в GitHub (в YAML inputs default) и в ТестОпс. Это обеспечит единообразие – при запуске, инициированном с любой стороны, по умолчанию будет одно и то же окружение. Конечно, при запуске есть возможность изменить эти значения вручную.
Запуск рабочего процесса с нужными параметрами из ТестОпс
После всей настройки можно пользоваться рабочими функциями интеграции. Теперь при запуске тестов из интерфейса ТестОпс система предложит указать значения параметров:
- Запустить можно либо всю джобу целиком, либо тест-кейс, либо массово выбранные тест-кейсы – во всех случаях откроется диалог создания запуска.
- В диалоговом окне будет раздел Окружение. Кликаем Добавить в этом разделе – параметры джобы автоматически подставятся в форму запуска, каждый со своим значением по умолчанию.
- При необходимости можно поменять значения. Например, выбрать другой браузер из списка или ввести номер версии продукта.
- Подтверждаем запуск.
TMS ТестОпс создаст столько запусков, сколько наборов параметров было указано (например, если вы запускаете тесты под разными браузерами, для каждого браузера будет отдельный прогон).
Каждый запуск отправляет запрос в GitHub Actions с помощью созданного ранее токена, передаёт указанные параметры (через github.event.inputs) и запускает соответствующий рабочий процесс. В реальном времени можно наблюдать в интерфейсе ТестОпс прогресс выполнения – статусы этапов рабочего процесса будут обновляться по мере получения информации от GitHub. По завершении прогона все результаты тестов будут собраны в связанном запуске в ТестОпс.
Автогенерация тест-кейсов из CI
Smart Test Case = «живое» описание тестов, которое ТестОпс строит автоматически по коду автотестов. После первого же прогона система считывает аннотации (@Owner, @Feature, @Story, кастомные теги) и шаги, превращая их в полноценный тест‑кейс с версией, историей изменений и связкой с исходной веткой кода. Так экономится время на ручной документации и гарантируется постоянное совпадение описания с актуальным состоянием тестов.
Как это работает технически: фреймворк‑адаптер формирует каталог allure-results; CI‑плагин или allurectl загружает результаты в ТестОпс. Пока запуск «открыт», в него можно добавлять файлы или менять атрибуты; сразу после нажатия «Завершить», Smart Test Case анализирует результаты и создаёт новые кейсы либо обновляет существующие по их уникальному идентификатору.
Это работает даже с «пустым» проектом, где нет созданных тест-кейсов. Подключаем рабочий репозиторий на GitHub, настраиваем pipeline (например, GitHub Actions, как было описано в разделе выше) и добавляем шаг allurectl upload с токеном проекта ТестОпс. Запускаем рабочий процесс — отчёты автоматически попадут в ТестОпс, и после закрытия первого запуска в ранее пустой библиотеке появятся сгенерированные тест‑кейсы с привязкой к коммитам GitHub.
Итоговый процесс выглядит так: разработчик пушит изменения ➝ CI выполняет тесты и выгружает результаты ➝ ТестОпс закрывает запуск ➝ Smart Test Case обновляет документацию, доступную менеджерам и ручным тестировщикам без чтения кода. Всё в одном пространстве, с версионированием и единым «источником правды».
Возможные ошибки и отладка интеграции
Иногда при настройке интеграции могут возникнуть сложности. Ниже приведены потенциальные проблемы и способы их решения.
Ошибки при подключении интеграции
Если при добавлении интеграции в ТестОпс система выдала сообщение об ошибке соединения, проверьте токен и настройки. Убедитесь, что правильно скопировали PAT-токен GitHub (без лишних пробелов в начале/конце). Также проверьте, что указали верный URL (для GitHub.com это github.com и api.github.com). При необходимости сгенерируйте новый токен – возможно, истёк срок действия прежнего.
HTTP 422 при запуске из ТестОпс
Ошибка 422 означает, что запрос сформирован неправильно. Чаще всего это происходит, если не добавлены обязательные ALLURE_JOB_RUN_ID и ALLURE_USERNAME в рабочий процесс, либо если в настройках джобы указаны параметры, которых нет среди inputs рабочего процесса. Решение: убеждаемся, что YAML рабочий процесс содержит необходимые inputs, а параметры джобы в ТестОпс полностью соответствуют объявленным inputs. Удаляем лишние параметры или добавляем пропущенные – и затем повторяем запуск.
Нет результатов тестов в ТестОпс
Интеграция запустилась, рабочий процесс на GitHub отработал, а в ТестОпс запуск создался, но внутри пусто или отсутствуют тесты. Возможные причины:
- Неверно указан путь ALLURE_RESULTS в env. Убедитесь, что директория совпадает с фактическим путём, куда тестовый фреймворк складывает результаты Allure. Если папка называется иначе или лежит не в корне проекта, скорректируйте переменную.
- allurectl не отправил данные. Смотрим логи выполнения GitHub Actions и находим шаги, связанные с allurectl. Если они отсутствуют или завершились с ошибкой, проверьте, что шаг установки setup-allurectl выполнен до запуска тестов, а команда запуска обёрнута в allurectl watch. При ошибках сети во время отправки данных – возможно, были временные проблемы с подключением к серверу.
Статус сборки не отобразился или не обновляется
Если запуск рабочего процесса инициирован из «ТестОпс», но в интерфейсе не видно его прогресса (или наоборот, в GitHub Actions не появилось задание), проблема может быть в токене GitHub:
- Для Fine-grained токена проверяем, включён ли доступ именно к нужному репозиторию и не истёк ли срок действия.
- Для Classic токена убеждаемся, что у него есть право workflow (для управления Actions) и repo (для доступа к репозиторию) – без них GitHub может игнорировать запросы на запуск.
- Если используется GitHub Enterprise, подтверждаем, что сервер доступен – иначе запросы не дойдут.
Некорректные данные тестов
Иногда в результатах в «ТестОпс» тесты помечаются как «невозможно привязать». Это означает, что система не смогла сопоставить результаты с существующими тест-кейсами. Обычно это происходит при ручных попытках проставить атрибут ALLURE_ID в тестах, не совпадающий с ID кейсов в ТестОпс, либо в отчётах отсутствует достаточная информация. Решение – удостовериться, что не указано никаких кастомных идентификаторов тестов без необходимости. Если это намеренная попытка связать автотесты с тест-кейсами из ТестОпс, убеждаемся, что используются корректные ключи маппинга (AS_ID) или настраиваем сопоставление через названия/пути.
Если проблема не поддаётся выявлению, стоит заглянуть в раздел Устранение неполадок официальной документации ТестОпс. В случае интеграции с облачной версией следует обратиться в техническую поддержку. Специалисты помогут разобраться и найти решение.
Коротко о главном
Интеграция GitHub Actions с «ТестОпс» позволяет полностью связать процессы автотестирования с тест-менеджментом. В этом руководстве мы настроили обмен данными в обоих направлениях: GitHub передаёт в «ТестОпс» результаты тестов в режиме реального времени, а «ТестОпс» через API GitHub может запускать тестовые сборки по требованию.
После настройки интеграции, получается мощный механизм: Continuous Integration и тестовая аналитика работают рука об руку. Это позволяет быстрее увидеть значимость автоматизации – тесты запускаются по событию, результаты сразу видны, отчёты формируются без лишних ручных действий. Так обеспечиваются принципы прозрачности и контроля – вся информация о прогонах доступна в ТестОпс, где её можно связывать с тест-кейсами, требованиями, метриками покрытия и т.д. Надеемся, этот гайд оказался полезен и показал как успешно объединить MCP, GitHub и ТестОпс в единую связку для более эффективного и удобного тестирования.