Искусственный интеллект в тестировании

Интеграция облачной версии платформы ТестОпс с GitHub Actions позволяет автоматизировать запуск тестов и сбор результатов в единой системе. В этом руководстве мы пошагово настраиваем трёхстороннюю связку: результаты запуска GitHub Actions отправляются в TMS ТестОпс, из ТестОпс можно инициировать запуски workflow на GitHub, а с помощью MCP обеспечивается интеллектуальная интеграция и автоматизация процессов между всеми системами. В статье рассматриваем требования к окружению, генерацию необходимых токенов, изменение конфигурации workflow, настройку параметров окружения и возможные ошибки.

---

⚡️ Внимание! Это 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.

Создание тестового локального проекта

1. Создаём папку для проекта и переходим в неё

   Выбираем удобную директорию на диске и выполняем команду для создания новой папки (заменяем <project-name> на актуальное название проекта):

   mkdir ~/workspace/<project-name>
   cd ~/workspace/<project-name>

2. Запускаем npm‑проект и добавляем первый тест.

Инициализируем репозиторий Git, для этого открываем теримниал и запускаем команду:

git init

3. Инициализируем npm-проект и добавляем первый тест.

   npm init -y # флаг `-y` = «ответить “yes” на все вопросы»

4. Инициализируем репозиторий Git.

Открываем терминал и запускаем команду:

git init

5. Устанавливаем 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-reporter

6. Настройка тестового скрипта.

Находим блок "scripts" в package.json и заменяем содержимое:

"scripts": {
  "test": "jest --reporters=\"default\" --reporters=\"@shelex/jest-allure2-reporter\" --outputDirectory=allure-results"
}

Здесь мы говорим Jest использовать стандартный репортёр вместе с Allure, а результаты складывать в папку allure-results.

7. Добавляем первый тест.

Создаём файл hello.test.js в корне проекта:

// hello.test.js
describe('Пример самого простого теста', () => {
  it('всегда проходит', () => {
    expect(true).toBe(true);
  });
});

8. Запускаем тесты:

npm test

Если всё сделано верно — появится зелёный отчёт Jest и в каталог добавится папка allure-results.

✅️ Теперь проект готов: у нас есть Git‑репозиторий, package.json, папка результатов, а главное — команда npm test, которую потом обернёт allurectl watch.

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

Создание и настройка удалённого репозитория

1. Переходим на github.com и создаём новый репозиторий для проекта, нажав на кнопку New repository.

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. Проверяем подключение и отправляем первый коммит:

       git remote add origin [email protected]:`<login>`/`<repo>`.git
       git add .
       git commit -m "Первый тест"
       git branch -M main
       git push -u origin main

   

---

Генерация токенов

Cоздание GitHub Personal Access Token (PAT)

1. В настройках GitHub переходим в Settings → Developer settings → Personal access tokens.

   

2. Создаём Fine-grained токен

   Наделяем правами Actions и Issues (отмечаем пункты _Read и write), выбираем только нужный репозиторий.

3. Копируем токен и сохраняем его — он нужен для интеграции.

Получение API‑токена в ТестОпс

1. Заходим в ТестОпс.

2. Кликаем аватар в правом верхнем углу) и переходим в API-токены.

   

3. Даём название: github-actions → Создать.

   Появится модальное окно с сгенерированным токеном. Копируем и сохраняем — этот токен нужен для настройки секретов в 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).

   Далее редактируем YAML-файл для описания рабочего процесса так, чтобы он был совместим с ТестОпс. Основные параметры включают объявление специальных параметров запуска, настройку переменных окружения и добавление шагов с allurectl.

3. Добавляем обязательные inputs для workflow_dispatch

   🔦 Примечание: В разделе, описывающем событие workflow_dispatch, нужно задать два специальных параметра запуска: ALLURE_JOB_RUN_ID и ALLURE_USERNAME. Эти параметры служебные – они заполняются системой ТестОпс при запуске из интерфейса. Если их не добавить, запуск рабочего процесса из ТестОпс будет невозможен и выйдет ошибка 422. О том, как с ними работать, рассказываем в разделе про параметризацию окружения.

4. Вставляем содержимое YAML-файла (как указано ниже) в окно редактора — аккуратно, YAML чувствителен к отступам.

   Ниже приводим пример полного 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 test

5. Сохраняем изменения в файле.

---

Добавление токена из ТестОпс в секреты репозитория GitHub

1. Открываем настройки (Settings) репозитория на GitHub.

   Переходим в секцию Secrets and variables → Actions и нажимаем «New repository secret». Создаём новый секрет со следующими параметрами:

   • Name (имя) – ALLURE_TOKEN (строго такое имя).

   • Value (значение) – скопированный API-токен из ТестОпс.

2. Сохраняем секрет (кнопка «Add secret»).

   Теперь GitHub Actions сможет использовать этот токен для отправки данных в ТестОпс. Обращаем внимание, что секреты шифруются GitHub’ом, в логе они не появятся.

3. Фиксируем изменения и отправляем их в репозиторий.

        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: https://testing.qatools.cloud/launch/7

Здесь будет ссылка на ваш экземпляр ТестОпс.

---

Подключение 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 и ТестОпс в единую связку для более эффективного и удобного тестирования.

---

📢 Присоединяйтесь к Telegram-каналу ТестОпс

Подписаться — новости, анонсы и лучшие практики тестирования.

---