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