Привет, читатели Хабра!
Меня зовут Николай Усов, я работаю в отделе тестирования «Цифровой индустриальной платформы». В нашей команде в качестве системы управления тестированием программных продуктов используется 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-бот становится более производительным, если использовать асинхронный подход к написанию кода, поэтому мы взяли следующие основные библиотеки:
MongoDB [https://www.mongodb.com/]. Это документоориентированная система управления базами данных. Данная СУБД была выбрана из-за возможности хранения сложных по структуре объектов в виде документов. Можно практически не обрабатывать тело ответа от Test IT, чтобы сохранить данные в коллекцию. Плюс поиск и выгрузка документов из БД производится быстро и легко.
1. Поддержание соответствия между автоматизированными и ручными тест-кейсами
Небольшое пояснение для тех, кто не работал с Test IT. В системе есть два раздела: автотесты и ручные тесты. Ручные тестировщики заводят тест-кейсы в Test IT, после чего автотестировщики пишут по ним автоматизированные тесты (дальше по тексту будем использовать автотесты) в своей IDE (среде разработки). Написанные автотесты линкуются с ручными тест-кейсами в Test IT. В момент линковки создаются автотесты в Test IT.
Поддержание соответствия автотестов с тест-кейсами (дальше по тексту будем использовать неподтвержденные автотесты) может быть затруднительным процессом, если их слишком много. В Test IT, конечно, есть раздел с автотестами, где можно отфильтровать и отследить неподтвержденные автотесты (см. рис. 1). Однако там не хватает инструментов для разделения по модулям, чтобы прослеживать структуру проекта, хотя в разделе с тест-кейсами данная структура присутствует.
Проблему с недостающей нам структурой проекта в автотестах мы просто решили с помощью telegram-бота. Как выглядит меню проекта в интерфейсе бота, показано на рис. 2. То есть мы предусмотрели разделение проекта на модули, и каждому модулю соответствует свой набор автотестов.
Вызов меню происходит за счет команды /unapproved_autotests. В БД заранее созданы пустые коллекции, которые обновляются с вызовом команды /start и запуском скрипта по расписанию, но об этом чуть ниже.
Обработчик для команды /unapproved_autotests собирает данные по автотестам и создает меню:
Обработчик для команды /unapproved_autotests собирает данные по автотестам и создает меню:
@dp.message_handler(commands=["unapproved_autotests"])
async def unapproved_autotests_command_handler(message: types.Message):
"""
Обработчик команды /unapproved_autotests. \n
:param message: объект, представляющий сообщение пользователя.
"""
localization = await data_base.get_user_localization(user_id=message.chat.id)
wait_msg = await message.answer(text=MESSAGES.get('get_autotests').get(localization))
# сохраняем тип состояния - unapproved (неподтвержденные автотесты)
await data_base.save_selected_autotests_type(
user_id=message.chat.id,
autotests_type='unapproved')
# получает наименования модулей {“module_id": {“name”: module_name, “localization”:localization}}
all_modules = await data_base.get_modules_names(report_mode="key_id")
# получает автотесты, которые нужно актуализировать
all_unapproved_autotests = await testit_client.get_autotests_for_actualize(
modules=all_modules,
message=message,
localization=localization)
# обновляет БД неактуализированными автотестами
await data_base.update_unapproved_autotests(
user_id=message.chat.id,
autotests_dict=all_unapproved_autotests)
await bot.delete_message(
chat_id=message.chat.id,
message_id=wait_msg.message_id)
# перенаправляет на метод создания меню
await send_modules_menu(message=message)В методе testit_client.get_autotests_for_actualize происходит сбор и распределение по модулям неподтвержденных автотестов (часть метода):
for autotest in all_autotests:
if mode == "unapproved" and autotest.get('mustBeApproved'):
autotests_dict = await self.add_autotests_dict(
autotests_dict=autotests_dict,
modules_names=modules_names,
autotest=autotest)
Формирование основного меню, которое разделено на модули:
async def send_modules_menu(message: types.Message):
"""
Отправляет меню со списком модулей. \n
:param message: объект, представляющий сообщение пользователя.
"""
# получает наименования модулей {“module_id": {“name”: module_name, “localization”:localization}}
modules_names = await data_base.get_modules_names(report_mode="key_id")
# составляем блоки для меню
markup = types.InlineKeyboardMarkup()
buttons = []
localization = await data_base.get_user_localization(user_id=message.chat.id)
autotests_type = await data_base.get_selected_autotests_type(user_id=message.chat.id)
for module_id in modules_names.keys():
buttons.append(
types.InlineKeyboardButton(
text=modules_names[module_id].get("localization").get(localization),
callback_data=f'module#{modules_names[module_id].get("
name")}#{autotests_type}'))
if len(buttons) == 2:
markup.add(*buttons)
buttons = []
markup.add(
types.InlineKeyboardButton(
text=MESSAGES.get('exit_btn').get(localization),
callback_data='exit_button'))
await message.answer(text=MESSAGES.get('select_module').get(localization), reply_markup=markup)
Поддержание соответствия шагов между автотестами и их тест-кейсами организовано дополнительным действием — подпиской на изменение. Подписка на изменение предоставляет пользователю информацию об изменении тест-кейса(-ов): в чате по расписанию всплывает меню с неподтвержденными автотестами за прошлый день. Выглядит это так, как на рис. 3.
Если автотест нужно посмотреть более детально, то жмем на кнопку «Открыть меню с автотестами» и переходим в меню с модулями (как на рис. 2).
В модулях распределены автотесты, полученные по подписке.
async def schedule_subscription():
""" Подписка по расписанию. """
aioschedule.every().day.at("21:15").do(
job_func=send_last_unapproved_autotests_on_a_schedule,
bot=bot)
while True:
await aioschedule.run_pending()
await asyncio.sleep(1)
def run_bot():
""" Запускает бота. """
asyncio.run_coroutine_threadsafe(coro=main(), loop=loop)
loop.run_forever()
def run_scheduled_delivery():
""" Запускает подписку. """
asyncio.run_coroutine_threadsafe(coro=schedule_subscription(), loop=loop)
if __name__ == "__main__":
try:
thread1 = Thread(target=run_bot)
thread2 = Thread(target=run_scheduled_delivery)
thread1.start()
thread2.start()
except (KeyboardInterrupt, SystemExit) as ex:
logger.error(f'Stop session: {ex}')
Подписка реализована через библиотеку aioschedule, которая находится в точке входа в программу. Для задания интервала выполнения функции используется метод aioschedule.every(). А чтобы проверять и выполнять запланированные задачи, применяется aioschedule.run_pending() в цикле. Данный запуск с UI telegram-бота не контролируется.
Ниже приведен метод для сбора информации об изменении тест-кейса(-ов). В первую очередь через API Test IT ищем измененные тест-кейсы и смотрим их дату создания. Далее мы считываем номера измененных тест-кейсов, созданных за прошедший день, и по этим номерам ищем соответствующие им автотесты.
async def send_last_unapproved_autotests_on_a_schedule(bot: Bot):
"""
Отправляет список неподтвержденных автотестов всем подписчикам по расписанию
за прошлый день. \n
:param bot: объект, представляющий бота.
"""
# получаем список пользователей, которые подписались на рассылку
subscribers_ids = await data_base.get_subscribers_ids()
if subscribers_ids is None:
return
# получаем все автотесты, у которых изменился тест-кейс за прошедший день
last_unapproved_autotests = await testit_client.get_last_unapproved_autotests()
modules = await data_base.get_modules_names(report_mode="key_id")
# оповещаем всех подписчиков
for id_ in subscribers_ids:
localization = await data_base.get_user_localization(user_id=id_)
# подсчет для вывода статистики
autotests_count = {modules[module_id]["localization"][localization]: len(autotests)
for module_id, autotests in last_unapproved_autotests.items()
if len(autotests) > 0}
# меню с модулями, если имеются автотесты за прошлый день
if autotests_count:
keyboard = InlineKeyboardMarkup()
keyboard.add(
types.InlineKeyboardButton(
text=MESSAGES.get("open_modules_with_last_unapproved_autotests").get(
localization),
callback_data='last_unapproved_autotests'))
await bot.send_message(
chat_id=id_,
text=MESSAGES.get("last_unapproved_description_with_autotests").get(
localization).format(autotests_count),
reply_markup=keyboard,
parse_mode='Markdown')
else:
await bot.send_message(
chat_id=id_,
text=MESSAGES.get("last_unapproved_description_without_autotests").get(
localization))
API-запросы к Test IT, задействованные при выгрузке данных:
GET/api/v2/autoTests/{autotest_id}/workItems/changed/id — получить список идентификаторов тест-кейсов, которые необходимо подтвердить.
GET/api/v2/workItems/{id_} — получить тест-кейс по идентификатору.
POST/api/v2/autoTests/search — получить список всех автотестов.
2. Отслеживание стабильности через процент успешности автотестов
Показатель стабильности необходим для того, чтобы понимать, как себя ведет автотест. Однако рассчитать его можно по-разному. Например, 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 значений стабильности (в процентах).
Ввод минимального процента:
@dp.message_handler(lambda message: message.text.isdigit(), state=user_states.min_percent)
async def input_min_percent_handler(message: types.Message):
"""
Обработчик ввода минимального процента. \n
:param message: объект, представляющий сообщение пользователя.
"""
localization = await data_base.get_user_localization(user_id=message.chat.id)
# считываем текст ввода
_min_percent = int(message.text)
if 0 <= _min_percent <= 100:
# переходим к следующему состоянию FSM
await user_states.next()
await data_base.save_min_percent(
user_id=message.chat.id,
min_percent=_min_percent)
await message.answer(text=MESSAGES.get('input_max_percent').get(localization))
else:
return await message.answer(text=MESSAGES.get('retry_input').get(localization))
Ввод максимального процента:
@dp.message_handler(lambda message: message.text.isdigit(), state=user_states.max_percent)
async def input_max_percent_handler(message: types.Message):
"""
Обработчик ввода максимального процента. \n
:param message: объект, представляющий сообщение пользователя.
"""
localization = await data_base.get_user_localization(user_id=message.chat.id)
_max_percent = int(message.text)
if 0 <= _max_percent <= 100:
# выгружаем из БД значение минимального процента
_min_percent = await data_base.get_min_percent(user_id=message.chat.id)
if _max_percent >= _min_percent:
# заканчиваем режим состояний FSM (всего два состояния)
await user_states.next()
await data_base.save_max_percent(
user_id=message.chat.id,
max_percent=_max_percent)
wait_msg = await message.answer(text=MESSAGES.get(
'get_autotests').get(localization))
# сохраняем в БД тип состояния - 'stability'
await data_base.save_selected_autotests_type(
user_id=message.chat.id,
autotests_type='stability')
all_modules = await data_base.get_modules_names(report_mode="key_id")
# получаем автотесты, которые нужно актуализировать
all_stability_autotests = await testit_client.get_autotests_for_actualize(
modules=all_modules,
mode="stability",
min_percent=_min_percent,
max_percent=_max_percent,
message=message,
localization=localization)
await data_base.update_stability_autotests(
user_id=message.chat.id,
autotests_dict=all_stability_autotests)
await bot.delete_message(
chat_id=message.chat.id,
message_id=wait_msg.message_id)
await send_modules_menu(message=message)
else:
return await message.answer(text=MESSAGES.get(
'max_percent_error').get(localization))
else:
return await message.answer(text=MESSAGES.get('retry_input').get(localization))
Расчет стабильности проводится либо вручную (с помощью окна администратора — см. рис. 7), либо по расписанию (реализация точно такая же, как при подписке на изменения — см. главу 1).
Действия по расчету стабильности:
Выгрузка всех автотестов в БД из Test IT.
Выгрузка всех test-runs (прогоны) для каждого автотеста в БД из Test IT (POST/api/v2/autotests/{id_}/testResults/search).
Расчет стабильности автотестов (процент успешности), используя БД в качестве быстрого поиска и выгрузки требуемых данных.
Выгрузка из Test IT test-runs для каждого автотеста производится партиями (batch), чтобы не нагружать сервис:
async def add_entities_for_autotest_to_data_base_by_batch(
func,
entities: list = None,
batch: int = 5,
**kwargs):
"""
Добавляет сущности в БД партиями для определенного автотеста.\n
:param func: метод добавления сущностей в БД.
:param entities: список сущностей.
:param batch: группа сущностей, чтобы разбить большой массив на части.
:param kwargs: остальные параметры.
"""
flag = True
while flag:
if not entities:
flag = False
# проходимся по партиям
data = entities[:batch]
entities = entities[batch:]
# создаем таски и ждем их выполнения
data_ = []
for entity in data:
data_.append(asyncio.create_task(func(entity, **kwargs)))
await asyncio.gather(*data_)
3. Вывод статистики по пройденным автотестам в telegram-боте
Test IT отличается богатым функционалом и большим количеством окон, что делает несколько неудобным удаленный просмотр статистики по ночному прогону, например, если под рукой нет ноутбука. Чтобы от этого неудобства себя избавить, мы реализовали в telegram-боте быструю UI-форму для отслеживания статистики прохождения автотестов (см. рис.8).
Для быстрого поиска тест-плана используется машина состояний (FSM — Finite State Machine).
@dp.callback_query_handler(lambda call: call.data == "test_plan_search_btn")
async def test_plan_search_callback(call: CallbackQuery):
"""
Обработчик нажатия на кнопку поиска тест-плана. \n
:param call: объект, представляющий входящий callback-запрос.
"""
localization = await data_base.get_user_localization(user_id=call.message.chat.id)
await bot.delete_message(chat_id=call.message.chat.id, message_id=call.message.message_id)
# устанавливаем машину состояний FSM
await search_state.search.set()
await call.message.answer(MESSAGES.get('input_name').get(localization).format("тест-плана"))
@dp.message_handler(state=search_state.search)
async def test_plan_search_fsm(message: types.Message):
"""
Обработчик ввода имени тест-плана. \n
:param message: объект, представляющий сообщение пользователя.
"""
test_plan_name = message.text
# останавливаем машину состояний (одно состояние)
await search_state.next()
# сохраняем состояние тест-плана в режиме поиска
await data_base.save_test_plan_action(
user_id=message.chat.id,
action='test_plans_results',
text_search=test_plan_name)
# передаем в меню тест-плана параметр page=1 – пагинация начинается со страницы 1
await send_test_plans(message=message, page=1)
Тут все просто: первым обработчиком запускаем машину состояний при нажатии на кнопку «Поиск тест-плана», вторым — завершаем работу машины состояний и отправляем введенное наименование тест-плана на вывод в меню.
4. Запуск автотестов с телефона
Хорошее дополнение к просмотру статистики в телефоне — запуск автотестов с того же телефона.
Небольшое отступление. В проекте настроен запуск автотестов по тест-плану, с использованием 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 срабатывает команда:
pytest -v -m <марки автотестов> <путь до автотестов в проекте> --testit --tmsUrl= --tmsPrivateToken= --tmsAdapterMode=0 --tmsConfigurationId= --tmsProjectId= --tmsTestRunId= --numprocesses= --dist loadgroup. Немного о параметрах:
--tmsConfigurationId — идентификатор конфигурации стенда;
--tmsProjectId — идентификатор проекта в Test IT;
--tmsAdapterMode — режим 0, запуск с параметром tmsTestRunId;
--tmsTestRunId — идентификатор test-run.
Автотесты, написанные с марками, связаны напрямую с Test IT. Данные марки позволяют, с помощью tmsTestRunId, запускать нужные автотесты.
Команда pytest направляет результаты в нужный тест-план:
async def run_test_plan(message: types.Message, test_plan_id: str):
"""
Запускает тестовый план. \n
:param message: объект, представляющий сообщение пользователя.
:param test_plan_id: идентификатор тестового плана.
"""
localization = await data_base.get_user_localization(user_id=message.chat.id)
test_suites_ids = []
points_for_run = []
# получаем тестовый набор
test_suites = await testit_client.get_test_suites(test_plan_id=test_plan_id)
for test_suite in test_suites:
test_suites_ids.append(test_suite.get('id'))
# получаем идентификаторы автотестов.
points_data = await testit_client.post_points_with_last_result(
test_suites_ids=test_suites_ids)
for _, points in points_data.items():
for point in points:
points_for_run.append(point.get('id'))
test_run_data = {
'autoTests': [],
'build': '1',
'entityTypeName': 'TestRuns',
'isAutomated': True,
'name': None,
'projectId': Config.testit_project_id,
'runByUserId': None,
'stateName': 'NotStarted',
'stoppedByUserId': None,
'testPlanId': test_plan_id,
'testPointIds': points_for_run
}
try:
await testit_client.post_test_runs(data=test_run_data)
await message.answer(text=MESSAGES.get('successfully_launched_test_plan').get(
localization))
except Exception:
await message.answer(text=MESSAGES.get('unsuccessfully_launched_test_plan').get(
localization))
Заключение
В итоге мы реализовали полезный функционал для автотестировщиков. Однако на достигнутом останавливаться не собираемся. В наших планах:
реализовать расчет стабильности автотестов для отдельных релизов, для тест-планов, для групп тест-планов;
исправить технологию общения с сервером Telegram на Webhook (в данный момент работает на Long Polling);
расширить функционал вывода информации;
подключить разделение ролей пользователей;
обновить Python до 3.11.0.
Кстати, на Хабре есть пара отличных материалов, которые помогут в создании telegram‑бота «Всё, о чём должен знать разработчик Телеграм‑ботов» и планировщика задач «Как сделать вашего телеграм‑бота лучше? Конечно, добавить ему аналитику». Рекомендую в качестве дополнительного чтения к этой статье. Ну и буду рад ответить на ваши вопросы и получить ваши советы в комментариях.