SavePearlHarbor

Veai + TMS: как подключить Allure TestOps и Test IT к ИИ-агенту в IDE и чинить упавшие автотесты

—

от автора

admin

Автотесты падают, а разбор занимает время: нужно открыть отчёт в системе управления тестами, понять причину падения, залезть в репозиторий, найти нужный тест и решить, где ошибка: в самом тесте или в приложении. Veai умеет забирать эту рутину на себя. Агент подключается к TMS (Test Management System), читает данные о падении по ссылке и предлагает правку прямо в открытом проекте.

В статье разберём, что такое TMS в контексте Veai, как подключить Allure TestOps и Test IT, и как агент разбирает причину падения автотеста: от инфраструктуры до флаков.

Коротко

  • TMS в Veai поддерживает две системы: Allure TestOps и Test IT.

  • Подключение настраивается один раз: Url проекта + Private Token + Verify Setup.

  • Сценарий «Исправление упавшего теста из TMS» забирает ссылку на упавший прогон, разбирает причину и предлагает правку автотеста или тикет разработчику.

  • Агент помогает отделить причину: инфраструктура, код приложения или сам тест, и учитывает историю флаков из TMS.

  • Агент работает и с одним тестом, и с целым прогоном, а не только с отдельным падением.

  • Работает по одному сценарию для обеих систем: меняется только источник, к которому вы подключились.

Статью подготовила техническая команда Veai, ex JetBrains и Huawei, мы делаем ИИ-агента для IDE. Описанные шаги и сценарий взяты из нашей документации.

Что такое TMS

TMS (Test Management System) хранит тестовые сценарии, планы и отчёты в одном месте, вместо разрозненных таблиц и заметок. Это централизованное хранилище тестовых артефактов: кейсы, прогоны, результаты, история падений.

Veai поддерживает две системы:

Смысл интеграции в том, что агент видит не только код в IDE, но и контекст падения из TMS. Он берёт данные конкретного упавшего прогона, сопоставляет их с автотестами в открытом репозитории и предлагает исправление. Если проблема не в тесте, а в тестируемом приложении, агент предложит завести тикет для разработчика.

Подключение Allure TestOps

Подключение настраивается один раз в настройках IDE.

  1. Откройте настройки IDE → Veai → Allure TestOps.

  2. В браузере откройте свой проект в Allure TestOps и скопируйте ссылку на проект (она заканчивается на .qatools.cloud).

  3. В настройках IDE вставьте ссылку в поле Url.

  4. В Allure TestOps нажмите на иконку профиля в правом верхнем углу, выберите API tokens, нажмите + Token, введите имя токена (например, Veai plugin), нажмите Create, скопируйте полученный токен и нажмите Done.

  5. В настройках IDE вставьте токен в поле Private Token.

  6. Нажмите Verify Setup.

(Место для скриншота: окно настроек IDE → Veai → Allure TestOps с заполненными полями Url и Private Token, кнопка Verify Setup.)

Если появилась надпись «Success! Setup is valid», нажмите OK: подключение готово. Если видите ошибку, сверьтесь с документацией Allure TestOps и напишите в поддержку: support@veai.ru.

Подключение Test IT

Логика та же, отличаются домен проекта и путь к токену.

  1. Откройте настройки IDE → Veai → Test IT.

  2. В браузере откройте свой проект в Test IT и скопируйте ссылку на проект (она заканчивается на .testit.software).

  3. В настройках IDE вставьте ссылку в поле Url.

  4. В Test IT нажмите на иконку профиля в правом верхнем углу, выберите Настройки профиля → API-токены, введите имя токена (например, Veai plugin), нажмите Сгенерировать, скопируйте токен и нажмите Done.

  5. В настройках IDE вставьте токен в поле Private Token.

  6. Нажмите Verify Setup.

(Место для скриншота: окно настроек IDE → Veai → Test IT с заполненными полями Url и Private Token, кнопка Verify Setup.)

При надписи «Success! Setup is valid» нажмите OK. При ошибке сверьтесь с документацией Test IT и напишите в поддержку: support@veai.ru.

Исправление упавшего автотеста

Сценарий одинаковый для обеих систем. Разница только в том, к какой TMS вы подключились на предыдущем шаге.

  1. Убедитесь, что подключение к Allure TestOps или Test IT настроено (см. разделы выше).

  2. Откройте репозиторий с автотестами в IDE: агент работает с кодом, который у вас перед глазами.

  3. Создайте новый чат кнопкой + New Chat в правом верхнем углу панели Veai.

  4. Нажмите на «Исправление упавшего теста из TMS».

  5. В браузере откройте упавший автотест и скопируйте ссылку на него.

  6. Вставьте ссылку в окно агента и отправьте.

(Место для скриншота: чат Veai со вставленной ссылкой на упавший автотест и ответом агента с разбором причины.)

Дальше агент:

  • анализирует данные о падении из TMS;

  • сопоставляет их с автотестами в открытом репозитории;

  • находит причину;

  • предлагает исправление автотеста либо, если дело в тестируемом приложении, предлагает создать тикет для разработчика.

Решение всегда за вами: агент готовит разбор и правку, а применять её или нет решаете вы.

Один тест или весь прогон

В реальном прогоне падает не один тест. Из тысяч автотестов красными могут стать сотни, и вручную разбирать каждый никто не будет: часть падений инфраструктурные, часть тянется от одной общей причины.

Поэтому агент работает не только с одним тестом, но и с целым прогоном: вы отдаёте ссылку на прогон, а не собираете ссылки на каждое падение по отдельности. Это ближе к тому, как QA-инженер разбирает результаты ночного запуска: сначала смотрит на прогон целиком, а потом идёт в конкретные тесты.

Где ошибка: инфра, код или тест

Первый вопрос при разборе падения: где корень проблемы. Вариантов три:

  • инфраструктура (стенд недоступен, таймауты, внешний сервис лёг);

  • код приложения (тест честно поймал регресс);

  • сам тест (устарели локаторы, изменилась текстовка, флаки).

Агент помогает отделить эти случаи друг от друга. Если дело в тесте, он предлагает правку. Если тест честно поймал ошибку в приложении, предлагает завести тикет для разработчика, а не подгонять зелёный статус. Это важно: автоправка теста под сломанное поведение маскирует реальный баг.

Частый случай: в тест-кейсе описано старое поведение, потому что документацию редко обновляют вовремя. Агент смотрит не только на лог падения, но и на связанный тест-кейс в TMS, поэтому может подсветить такое расхождение.

Например, после редизайна формы UI текст кнопки поменялся, а старый тест-кейс в TMS всё ещё ссылается на старую формулировку. Автотест падает по текстовому локатору, хотя приложение работает корректно. Связанный тест-кейс в TMS помогает увидеть такое расхождение быстрее, чем при разборе только по логам.

Флаки: причина, а не симптом

Самое неприятное в автотестах не разовое падение, а нестабильный тест, который то проходит, то падает. Закрыть его одним рераном значит вернуться к нему через неделю.

TMS хранит историю прогонов, поэтому видно, какой тест флакает чаще всего. На этих данных агент ищет вероятную причину нестабильности: неатомарный тест, гонка состояний, долгое ожидание элемента, и предлагает вариант переписать его устойчиво, а не глушить симптом повторным запуском. Финальное решение, как и в других сценариях, остаётся за инженером.

Как это выглядит на практике

Типичный рабочий цикл выглядит так. Ночной прогон подсветил красные тесты в TMS. Вместо ручного разбора вы открываете проект в IDE, запускаете сценарий исправления, вставляете ссылку на упавший прогон и получаете разбор: что сломалось и какое исправление предлагает агент. Решение остаётся за вами, но подготовительная работа (сбор контекста падения, поиск теста в коде, гипотеза о причине) уже сделана.

Агент опирается на источник фактов: не только на текст ошибки, но и на данные прогона из TMS плюс реальный код в репозитории.

Источники (документация Veai):

ссылка на оригинал статьи https://habr.com/ru/articles/1056438/