Зачем мониторить время прохождения тестов?

Для начала разберёмся, почему мы вообще решили отслеживать скорость прохождения регрессионных тестов. Если бы у нас их было немного, мы бы об этом, вероятно, даже не думали. Но когда у тебя 27 000 тестов, а их общее время прохождения доходит до 2-3 часов, начинаешь задумываться. Мы в команде задались вопросом, есть ли тесты, которые можно ускорить, и, если да, то как их быстро найти. Кроме того, важно было понять, всегда ли тест проходит за одно и то же время или это произошло один раз – для этого нужно было увидеть историю теста.

Теперь давайте оценим масштаб. Для справки: в качестве сервера непрерывной интеграции (CI) мы используем Bamboo. Для функциональных тестов отведено 25 планов, в среднем по 2-3 задания. Следовательно, для просмотра тестов вручную требуется каждый раз просматривать минимум 50 заданий – и это только за одну дату, а если нужна история, то придётся смотреть и предыдущие запуски.

Как решаем задачу

Чтобы решить эту задачу, я написал плагин, который собирает всю необходимую информацию с CI. За выгрузку и хранение данных отвечает Prometheus. Данные там по умолчанию хранятся 2 недели, что нас вполне устраивает.

Чтобы иметь возможность управлять сбором метрик с заданий, я добавил в плагин задачу:

Test Type – обычная метка, которую можно использовать для дополнительной фильтрации.

Plan Name – имя плана. При копировании плана разработчик и тестировщик, как правило, указывают другое имя, чтобы не запутать себя и других. Во время сбора текущее имя плана сверяется с именем, указанным в этом поле. Если имена не совпадают, то метрики игнорируются, т.к. собирать информацию с копий планов не хотелось (если только этого не захочет человек – тогда ему нужно указать действительное имя плана).

Border – нижняя граница времени прохождения тестов, время задаётся в секундах. Нам нет смысла собирать информацию о тесте, если время прохождения меньше или равно 5 секундам, а таких тестов много, поэтому и решено было добавить фильтр на этапе сбора.

В итоге после прогона тестов со стороны Bamboo получаем метрики в таком виде:

{

   "TestName":"<test name>",

   "Branch":"master",

   "ClassName":"<class_name>",

   "Value":"13.0",

   "TestType":"plugin",

   "Job":"<job_name>",

   "Plan":"<plan_name>"

},

{

   "TestName":"<test name>",

   "Branch":"master",

   "ClassName":"<class_name>",

   "Value":"10.0",

   "TestType":"plugin",

   "Job":"<job_name>",

   "Plan":"<plan_name>"

}

На стороне Prometheus это выглядит следующим образом:

Удаление метрик из Prometheus

После того, как всё было настроено, от команды поступило дополнительное требование: добавить возможность быстрого удаления метрики из Prometheus. Для этого я написал второй плагин, встроив в Bamboo две кнопки. Эти кнопки отображаются на странице Bamboo administration: Prometheus settings открывает страницу, на которой должен быть указан url до Prometheus, Table with time of passing tests – страница с метриками. На самой странице в шапке есть возможность указать одно из значений метрики, и список будет автоматически фильтроваться

Clear – очищает только поля для фильтрации.

Remove – удаляет метрики согласно выставленному фильтру.

Сам по себе мониторинг даёт только общую картину. Когда знаешь, какой конкретно тест идёт долгое время, становится интересно, на каком шаге произошло замедление – и тут нам помогает уже ранее внедрённый Allure Framework. В отчёте, который генерирует Allure, для каждого метода, помеченного аннотацией @Step, отображается время, за которое этот метод выполняется.

Сбор статистики для планов с тестами

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

  • время прохождения каждого задания плана с тестами;

  • время ожидания заданий;

  • количество тестов в каждом задании;

  • общее количество тестов;

  • общее время всех планов с учётом параллельности их выполнения;

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

Общие метрики: суммарное количество тестов и итоговое время прохождения всех планов – используются для отслеживания результирующей динамики, чтобы подвести итоги и узнать, за какое время проходит регресс. Остальные 4 метрики уже используются для конкретных целей. По метрикам видно, сколько времени задания стоят в очереди, сколько уходит на выполнение, сколько тестов задание выполняет. Если во время запуска задания произошла ошибка и тесты не смогли запуститься, то на отдельной панели это тоже будет видно.

Чтобы собирать данные только в момент запуска регресса, при этом игнорируя перезапуски планов (иначе вычислять реальное время регресса было бы куда сложнее), было решено ввести дополнительную задачу. Она выполняется в плане по сборке проекта и устанавливает некой переменной значение true. Затем проект по сборке запускает все необходимые планы с тестами. Когда план заканчивает выполнение, плагин проверяет наличие задачи, описанной выше, для сбора статистики по тестам. Так происходит фильтрация, с каких именно заданий собирать данные. Если значение некой переменной true, то все необходимые данные задания сохраняются. Для подсчёта суммарного времени регресса регистрируется время задания в момент постановки в очередь и в момент завершения. Далее при выводе финального графика берётся разница между максимальным временем завершения и минимальным временем запуска заданий.

Итог

Система, в целом, получилась довольно удобная: всё наглядно, информация быстро и легко фильтруется, нет проблем с хранением данных, нет необходимости как-то помечать тест, чтобы за ним следили, а в новые задания необходимо добавить только одну дополнительную задачу.

Кроме вышеперечисленных метрик ещё собирается информация об упавших тестах. В качестве развития в будущем планируем сделать автоматическое заведение задач в jira для упавших тестов, сократив таким образом время на создание задач и сбор логов – командам на доску будут прилетать уже готовые задачи со ссылкой на упавший план и stacktrace падения.

Спасибо за внимание!

Комментарии (2)


  1. RussianTM
    25.03.2022 12:48

    Для онлайн метрик тоже вначале использовали Prometheus.
    Потом перешли на Telegraf -> InfluxDb <- Grafana, на мой взгляд намного удобнее.
    ---
    Как уведомляете себя о новых проблемах? постоянно смотреть на графики трудноемко.


    1. Miroslav_Shipilov Автор
      26.03.2022 06:30

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