Голосовое управление тестами: от Telegram‑бота до TMS ТестОпс через MCP и GitHub Actions
Мы связываем голосовые команды в Telegram с запуском автотестов в GitHub Actions и сбором результатов в TMS ТестОпс. Логика такая: говорим чат-боту что-то вроде: «Запусти регресс на staging в Chrome!», бот распознаёт речь, через MCP‑сервер (и/или API) инициирует workflow_dispatch в нужном репозитории, а результаты и статус выполнения «приземляются» в запусках ТестОпс. Эта связка и схема параметров подтверждены руководствами по интеграции GitHub ↔ ТестОпс и MCP ↔ GitHub.
Архитектура решения:
Практическая реализация: локальный Whisper + обработчик голосовых сообщений, валидатор параметров запуска, GitHub Actions с обязательными inputs для запусков из ТестОпс и мониторинг/отмена прогонов через готовые MCP‑инструменты list_workflow_runs и cancel_workflow_run.
Вот, что для этого потребуется:
1. Учётные записи в GitHub и в облачной TMS ТестОпс (нужен ID проекта; его видно в URL и в интерфейсе).
2. Токены:
• GitHub PAT (fine‑grained) с правами как минимум Actions: Read & Write (для запуска/ отмены workflow).
• GitHub PAT (fine‑grained) с правами как минимум Actions: Read & Write (для запуска/ отмены workflow).
•API‑токен ТестОпс (для allurectl и интеграции GitHub↔ТестОпс).
В документации подробно описано, как настроить токен ТестОпс.
3. Репозиторий с тестами, формирующими артефакты Allure (папка allure-results), чтобы ТестОпс собирал результаты.
4. MCP‑сервер GitHub (готовый, запускается одной командой npx … stdio), и удобный клиент для отладки (напр., Cursor IDE).
В нашем блоге есть серия статей о настройке связки с MCP.
5. Telegram‑бот (BotFather‑токен) + локальный Whisper* для распознавания речи; готовый код‑скелет конвертации голосовых .ogg/.oga → .wav есть в исследовании.
*Whisper — это модель глубокого обучения, оптимизированная для работы на локальных устройствах, включая CPU и GPU. Она требует достаточных вычислительных ресурсов, но ее открытый исходный код позволяет разработчикам настраивать и оптимизировать модель под конкретные задачи. Тестировщики отмечают высокую точность распознавания (WER — Word Error Rate — на уровне лучших облачных решений) и возможность дообучения для специфических сценариев.
Подготовка GitHub Actions под запуск из ТестОпс
Шаг 1. Создаём рабочий процесс с обязательными inputs
Чтобы ТестОпс мог инициировать запуск через workflow_dispatch, в YAML должны быть служебные параметры ALLURE_JOB_RUN_ID и ALLURE_USERNAME. Если их нет, запуск из ТестОпс упадёт с HTTP 422.
Минимальный пример:
name: tests
on:
push:
workflow_dispatch:
inputs:
ALLURE_JOB_RUN_ID:
description: "Service param for TMS ТестОпс"
required: false
ALLURE_USERNAME:
description: "Service param for TMS ТестОпс"
required: false
GITHUB_TESTS_BROWSER:
description: "Browser"
required: true
default: chrome
TEST_SUITE:
description: "Suite"
required: true
default: smoke
GITHUB_TESTS_ENDPOINT:
description: "Target stand"
required: true
default: https://staging.example.com
env:
ALLURE_RESULTS: allure-results
ALLURE_JOB_RUN_ID: ${{ github.event.inputs.ALLURE_JOB_RUN_ID }}
ALLURE_USERNAME: ${{ github.event.inputs.ALLURE_USERNAME }}
GITHUB_TESTS_BROWSER: ${{ github.event.inputs.GITHUB_TESTS_BROWSER }}
TEST_SUITE: ${{ github.event.inputs.TEST_SUITE }}
GITHUB_TESTS_ENDPOINT: ${{ github.event.inputs.GITHUB_TESTS_ENDPOINT }}
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: allure-framework/setup-allurectl@v1
with:
allure-endpoint: ${{ secrets.ALLURE_ENDPOINT }}
allure-token: ${{ secrets.ALLURE_TOKEN }}
allure-project-id: ${{ secrets.ALLURE_PROJECT_ID }}
- name: Run tests with streaming to TMS
run: |
echo "Browser: $GITHUB_TESTS_BROWSER; Suite: $TEST_SUITE; URL: $GITHUB_TESTS_ENDPOINT"
allurectl watch -- ./gradlew test
Обращаем внимание на блок setup-allurectl и переменные окружения. Именно так GitHub отправляет результаты в запуски ТестОпс.
Шаг 2. Добавляем секреты в репозитории
Settings → Secrets and variables → Actions: ALLURE_ENDPOINT, ALLURE_TOKEN, ALLURE_PROJECT_ID. Токен ТестОпс создаётся в профиле пользователя.
Настройка параметров окружений в ТестОпс
Создаём конфигурацию, чтобы запускать по кнопке.
- Администрирование → Окружение: создайте глобальные переменные (например, Browser, Product Version и т.п.).
- Настройки проекта → Окружение: сопоставьте ключи (точно как в YAML‑inputs GITHUB_TESTS_BROWSER, TEST_SUITE, GITHUB_TESTS_ENDPOINT) с этими глобальными переменными.
- Проект → Джобы → ⋯ → Настроить → Параметры: добавьте параметры с дефолтными значениями — они подставятся в форму запуска в интерфейсе.
В ТестОпс одна джоба = один workflow GitHub; один запуск джобы = один запуск workflow. Статусы синхронизируются в обе стороны.
Запуск MCP‑сервера GitHub и проверка инструментов
- Запускаем сервер и ждём ответа от сервера;
npx -y @modelcontextprotocol/server-github stdio
# если всё работает корректно, получаем ответ "Server listening on stdio"- Для отладки удобно открыть Cursor IDE, добавить конфигурационный файл ~/.cursor/mcp.json с типом stdio и PAT в параметры окружения. После перезапуска видны инструменты list_workflow_runs, cancel_workflow_run и другие (через MCP: List Tools).
- Проверяем работоспособность MCP-связки. Для этого запрашиваем через ассистента список запусков PR или workflow-runs. Если нужно, отменяем зависшие процессы.
В готовом сервере GitHub инструменты для мониторинга/отмены присутствуют из коробки; запуск (dispatch) часто делают обычным REST‑вызовом GitHub API. Если в вашей сборке сервера есть инструмент для dispatch, используйте его; иначе вызывайте REST так, как показано в обработчике ниже — логика цепочки при этом не меняется.
Распознавание речи в Telegram и запуск теста
Голосовые сообщения Telegram приходят в .ogg/.oga. Конвертируем в .wav для Whisper и транскрибируем. Добавляем это в bot.py, рядом с кодом, который обрабатывает входящие голосовые сообщения.
def convert_telegram_voice_to_wav(oga_path: str) -> str:
import os
import ffmpeg
wav_path = oga_path.replace('.oga', '.wav')
(ffmpeg
.input(oga_path)
.output(
wav_path,
acodec='pcm_s16le',
ar=16000,
ac=1,
loglevel='error'
)
.overwrite_output()
.run(capture_stdout=True, capture_stderr=True)
)
if not os.path.exists(wav_path) or os.path.getsize(wav_path) == 0:
raise Exception("Conversion failed - output file empty or missing")
return wav_path
Разбор команды и запуск
Далее бот выделяет из текста 3 ключа: браузер, набор тестов, стенд. Из них собираем inputs и запускаем workflow_dispatch. (Если в вашей сборке MCP есть «dispatch‑инструмент» — используем его; если нет — вызываем REST.)
После запуска бот присылает ссылку на ран GitHub и, при наличии, ссылку на связанный запуск в ТестОпс (переменная ALLURE_JOB_RUN_ID).
Уведомления о прогоне: два пути
1. Через вебхуки ТестОпс. Вебхуки позволяют уведомлять сторонние системы (включая мессенджеры — Telegram/Slack) о старте/завершении запусков, создании дефектов и т. д. Настраиваются в проекте ТестОпс: указываете endpoint и JSON‑шаблон, подставляете переменные ({{launchName}}, {{failedCount}} и пр.).
В нашем блоге опубликованы подробные гайды по настройке вебхуков для Telegram и Slack.
2. Из GitHub Actions. Можно отправлять нотификации после джобы через curl на ваш webhook с добавлением в сообщение браузера, набора и итога статуса.
Частые ошибки и как их чинить
Проверка сквозного сценария
1. Меняем тест так, чтобы он падал, пушим изменения — видим красный ран в Actions и связанный запуск в ТестОпс.
2. Из ТестОпс создаём Issue в GitHub прямо с карточки провалившегося теста.
3. Через MCP в IDE получаем список текущих запусков и при необходимости отменяем зависшие.
4. Так, CI работает, отчёты уходят в ТестОпс, а инструменты MCP позволяют управлять прогоном, не покидая IDE.
В ТестОпс тест‑кейсы формируются автоматически из кода после прогонов CI, что серьёзно экономит время на документацию.
Пример валидатора параметров в GitHub Actions
Помогает ловить некорректные значения до старта тестов.
jobs:
validate-inputs:
runs-on: ubuntu-latest
outputs:
browser: ${{ steps.v.outputs.browser }}
suite: ${{ steps.v.outputs.suite }}
endpoint: ${{ steps.v.outputs.endpoint }}
steps:
- id: v
run: |
case "${{ env.GITHUB_TESTS_BROWSER }}" in
chrome|firefox|edge|safari)
echo "browser=${{ env.GITHUB_TESTS_BROWSER }}" >> $GITHUB_OUTPUT ;;
*)
echo "Bad browser";
exit 1 ;;
esac
case "${{ env.TEST_SUITE }}" in
smoke|regression|api|ui|full)
echo "suite=${{ env.TEST_SUITE }}" >> $GITHUB_OUTPUT ;;
*)
echo "Bad suite";
exit 1 ;;
esac
echo "endpoint=${{ env.GITHUB_TESTS_ENDPOINT }}" >> $GITHUB_OUTPUT
Пример уведомления из ТестОпс через вебхук
В настройках вебхука укажите endpoint бота и шаблон:
{
"text": "Запуск {{launchName}} в проекте {{projectName}}: failed={{failedCount}}, broken={{brokenCount}}, passed={{passedCount}}. Ссылка: {{launchUrl}}"
}
Чек‑лист настройки (можно использовать как контрольную карту)
- Создан PAT GitHub (Actions RW), создан API‑токен ТестОпс.
- В репозитории есть YAML с workflow_dispatch и обязательными ALLURE_* inputs.
- Подключён setup-allurectl и указаны секреты ALLURE_ENDPOINT/TOKEN/PROJECT_ID.
- В ТестОпс созданы глобальные переменные окружения, сопоставлены ключи проекта и параметры джобы.
- MCP‑сервер GitHub запущен, инструменты видны в IDE.
- Telegram‑бот подключён, Whisper работает, распознаём голосовую команду и собираем inputs.
- Уведомления настроены: вебхуки ТестОпс → мессенджер или пост‑шаг в GitHub Actions.
Коротко о главном
Мы интегрировали голосовые команды с CI и ТестОпс. Бот распознаёт намерения, MCP/REST активируют и контролируют workflow_dispatch, а allurectl передаёт результаты в ТестОпс. Команда получает уведомления. Все процессы и настройки основаны на актуальных руководствах и проверенных практиках из экосистемы ТестОпс.
