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

Для начала разберёмся, почему мы вообще решили отслеживать скорость прохождения регрессионных тестов. Если бы у нас их было немного, мы бы об этом, вероятно, даже не думали. Но когда у тебя 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 падения.

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