Привет, читатели Хабра! Меня зовут Николай Усов, я работаю в отделе тестирования «Цифровой индустриальной платформы». В нашей команде в качестве системы управления тестированием программных продуктов используется Test IT. Система в целом нам нравится, претензий к функционалу почти совсем нет. Однако инструментарий Test IT не всегда позволяет настроить работу тестировщиков так, как удобно. Например, тот, кто с ней работал, знает, что при большом количестве тестов может быть затруднительным поддержание соответствия между автоматизированными и ручными тест-кейсами, если их слишком много. Плюс могут потребоваться иные методы расчета успешности автотестов или более простой интерфейс для удаленного просмотра статистики по прогонам. В этой статье я расскажу, как с помощью telegram-бота, работающего в связке с Test IT, мы сделали жизнь тестировщиков немного приятнее, решив следующие задачи:    Поддержание соответствия между автоматизированными и ручными тест-кейсами.    Отслеживание стабильности через процент успешности автотестов. Вывод статистики по пройденным автотестам.    Запуск автотестов с телефона.    Решение этих задач базируется на следующем стеке технологий: Test IT TMS 4.3.0 Python 3.8 MongoDB 6.0.3 Обоснование выбора технологий    Test IT Test Management System [https://testit.software/]. Эта система управления тестированием программных продуктов. В компании широко используется и помогает оптимизировать работу тестировщиков. На нее никто не жалуется. Python. Автоматизированные тесты у нас пишутся на этом языке программирования, так что другие языки не рассматривались. Telegram-бот становится более производительным, если использовать асинхронный подход к написанию кода, поэтому мы взяли следующие основные библиотеки:  asyncio,    aiogram,  threading,  motor.motor_asyncio.  MongoDB [https://www.mongodb.com/]. Это документоориентированная система управления базами данных. Данная СУБД была выбрана из-за возможности хранения сложных по структуре объектов в виде документов. Можно практически не обрабатывать тело ответа от Test IT, чтобы сохранить данные в коллекцию. Плюс поиск и выгрузка документов из БД производится быстро и легко. Небольшое пояснение для тех, кто не работал с Test IT. В системе есть два раздела: автотесты и ручные тесты. Ручные тестировщики заводят тест-кейсы в Test IT, после чего автотестировщики пишут по ним автоматизированные тесты (дальше по тексту будем использовать автотесты) в своей IDE (среде разработки). Написанные автотесты линкуются с ручными тест-кейсами в Test IT. В момент линковки создаются автотесты в Test IT.     Поддержание соответствия автотестов с тест-кейсами (дальше по тексту будем использовать неподтвержденные автотесты) может быть затруднительным процессом, если их слишком много. В Test IT, конечно, есть раздел с автотестами, где можно отфильтровать и отследить неподтвержденные автотесты (см. рис. 1). Однако там не хватает инструментов для разделения по модулям, чтобы прослеживать структуру проекта, хотя в разделе с тест-кейсами данная структура присутствует.  Проблему с недостающей нам структурой проекта в автотестах мы просто решили с помощью telegram-бота. Как выглядит меню проекта в интерфейсе бота, показано на рис. 2. То есть мы предусмотрели разделение проекта на модули, и каждому модулю соответствует свой набор автотестов.  Вызов меню происходит за счет команды /unapproved_autotests. В БД заранее созданы пустые коллекции, которые обновляются с вызовом команды /start и запуском скрипта по расписанию, но об этом чуть ниже.  Обработчик для команды /unapproved_autotests собирает данные по автотестам и создает меню:    Поддержание соответствия шагов между автотестами и их тест-кейсами организовано дополнительным действием — подпиской на изменение. Подписка на изменение предоставляет пользователю информацию об изменении тест-кейса(-ов): в чате по расписанию всплывает меню с неподтвержденными автотестами за прошлый день. Выглядит это так, как на рис. 3. Если автотест нужно посмотреть более детально, то жмем на кнопку «Открыть меню с автотестами» и переходим в меню с модулями (как на рис. 2).      Подписка реализована через библиотеку aioschedule, которая находится в точке входа в программу. Для задания интервала выполнения функции используется метод aioschedule.every(). А чтобы проверять и выполнять запланированные задачи,   применяется aioschedule.run_pending() в цикле. Данный запуск с UI telegram-бота не контролируется.  GET/api/v2/autoTests/{autotest_id}/workItems/changed/id — получить список идентификаторов тест-кейсов, которые необходимо подтвердить. GET/api/v2/workItems/{id_} — получить тест-кейс по идентификатору. POST/api/v2/autoTests/search — получить список всех автотестов. Показатель стабильности необходим для того, чтобы понимать, как себя ведет автотест. Однако рассчитать его можно по-разному. Например, Test IT считает процент стабильности через число переходов между статусами автотеста, то есть как часто происходит смена статусов с «провален» на «успешен» и наоборот по результатам множества прогонов. Формула подсчета процента стабильности автотеста в Test IT: N — число всех переходов между статусами автотеста (100 последних прохождений или все, если их меньше 100), M — число переходов между статусами автотеста, при которых статус изменился. No result - "-" Passed - "100%" Passed Passed - "100%" (0/1), где 0 = M, 1 = N Passed Failed - "0%" (1/1) Passed Failed Passed - "0%" (2/2) Passed Failed Passed Failed - "0%" (3/3) Passed Failed Passed Failed Failed - "25%" (3/4) Однако нам этого способа расчета стабильности в Test IT оказалось недостаточно.  Как видно из рис. 5, тест постоянно падает, его стабильность — 100%. Это правильно. Но есть еще один подход к определению стабильности — исходя из процента успешности автотеста, когда определяется доля успешных прогонов автотеста из общего их числа. И этот показатель нам очень нужен, потому что с его помощью мы сможем:  более точно находить нестабильные автотесты; исследовать причины того, почему они постоянно падают; принимать меры для того, чтобы повысить стабильность, либо отказаться от теста. Формула подсчета процента успешности автотеста для отслеживания стабильности: passed_count — количество успешных прогонов автотеста, failed_count — количество провальных прогонов автотеста. Этот подход к отслеживанию стабильности мы реализовали с помощью telegram-бота. Как видно из рис. 6, используется машина состояний, которая задает min/max границы стабильности автотестов. Ниже приведен код обработчиков для ввода min/max значений стабильности (в процентах).    Расчет стабильности проводится либо вручную (с помощью окна администратора —           см. рис. 7), либо по расписанию (реализация точно такая же, как при подписке на изменения — см. главу 1).    Действия по расчету стабильности: Выгрузка всех автотестов в БД из Test IT. Выгрузка всех test-runs (прогоны) для каждого автотеста в БД из Test IT (POST/api/v2/autotests/{id_}/testResults/search). Расчет стабильности автотестов (процент успешности), используя БД в качестве быстрого поиска и выгрузки требуемых данных.     Test IT отличается богатым функционалом и большим количеством окон, что делает несколько неудобным удаленный просмотр статистики по ночному прогону, например, если под рукой нет ноутбука. Чтобы от этого неудобства себя избавить, мы реализовали в telegram-боте быструю UI-форму для отслеживания статистики прохождения автотестов (см. рис.8).   Тут все просто: первым обработчиком запускаем машину состояний при нажатии на кнопку «Поиск тест-плана», вторым — завершаем работу машины состояний и отправляем введенное наименование тест-плана на вывод в меню.  Хорошее дополнение к просмотру статистики в телефоне — запуск автотестов с того же телефона.  Небольшое отступление. В проекте настроен запуск автотестов по тест-плану, с использованием pipeline GitLab. По имеющейся конфигурации на стенде (прописано в Test IT) и созданному test-run будут запущены автотесты. В конце запуска будет линк результатов пройденных автотестов с этим тест-планом. В Test IT предварительно должен быть создан тест-план с набором автотестов. Запуск автотестов в telegram-боте проводится с помощью запроса из API Test IT — POST/api/TestRuns. Данный запрос создает в разделе «Запуски автотестов» пустой test-run. В данный test-run помещается (из основных параметров) идентификатор тест-плана (с которым мы будем линковать результат пройденных автотестов) и набор автотестов из этого тест-плана. Набор автотестов выгружаем из запроса API Test IT — GET/api/v2/testPlans/{test_plan_id}/testSuites.  После запуска test-run запускается настроенный pipeline в GitLab. В pipeline срабатывает команда: Немного о параметрах: --tmsConfigurationId — идентификатор конфигурации стенда; --tmsProjectId — идентификатор проекта в Test IT; --tmsAdapterMode — режим 0, запуск с параметром tmsTestRunId; --tmsTestRunId — идентификатор test-run.  Автотесты, написанные с марками, связаны напрямую с Test IT. Данные марки позволяют, с помощью tmsTestRunId, запускать нужные автотесты.  В итоге мы реализовали полезный функционал для автотестировщиков. Однако на достигнутом останавливаться не собираемся. В наших планах: реализовать расчет стабильности автотестов для отдельных релизов, для тест-планов, для групп тест-планов;    исправить технологию общения с сервером Telegram на Webhook (в данный момент работает на Long Polling); расширить функционал вывода информации;    подключить разделение ролей пользователей;    обновить Python до 3.11.0.     Кстати, на Хабре есть пара отличных материалов, которые помогут в создании telegram‑бота «Всё, о чём должен знать разработчик Телеграм‑ботов» и планировщика задач «Как сделать вашего телеграм‑бота лучше? Конечно, добавить ему аналитику». Рекомендую в качестве дополнительного чтения к этой статье. Ну и буду рад ответить на ваши вопросы и получить ваши советы в комментариях.