Блог

Искусственный интеллект в тестировании. Часть 1

2025-07-18 12:00
Интеграция облачной версии платформы ТестОпс с 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 init
III. Инициализируем 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-reporter
V. Настройка тестового скрипта.
Находим блок "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-ключ:
ssh-keygen -t ed25519 -C "your_email@example.com"
    eval "$(ssh-agent -s)"
    ssh-add ~/.ssh/id_ed25519
    cat ~/.ssh/id_ed25519.pub
3) Добавляем публичный ключ в настройки GitHub (SettingsSSH and GPG keys).
4) Проверяем подключение и отправляем первый коммит:
<div class="ql-code-block" data-language="plain">    git remote add origin git@github.com:`&lt;login&gt;`/`&lt;repo&gt;`.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 git@github.com:`<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 test
7) Сохраняем изменения в файле.

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