Содержание:
Больше года назад в команде разработки на стендах функционального и автоматизированного тестирования запустили мониторинг покрытия кода в runtime.
Начальник отдела разработки Максим Степанов вместе с руководителями разработки сервисов Андреем Киреевым и Павлом Барбашовым рассказали о запуске, работе и результатах внедрения системы мониторинга.
Зачем нужен мониторинг покрытия кода
Покрытие — это метрика, которая показывает, какой процент исходного кода выполнялся во время тестов. Она позволяет понять, насколько качественно протестирован продукт.
Покрытие можно оценить несколькими способами. В Газпромбанке используют два: по инструкциям и по ветвям.
Покрытие инструкций (Instruction coverage) учитывает выполнение каждой строки байт-кода. Строка байт-кода — это простейшая инструкция, например значение переменной. Одна строка программного кода может содержать несколько инструкций байт-кода.
Покрытие ветвей (Branch coverage), или бранчинг, подсчитывает, сколько раз в коде появляются ветвления, например инструкции if или switch. Процент покрытия определяется по тому, сколько ветвей было выполнено и пропущено.
Допустим, во время тестирования условие cond осуществляется. Тогда программа выполнит инструкции instruct1, instruct2, instruct3. Ветвь else и инструкция instruct4 не будут работать.
В итоге покрытие инструкций будет 75%, а бранчинг — только 50%. Это значит, что нужно добавить сценарии для проверки всех ветвей кода.
Тестирования в Газпромбанке проходят на автоматизированных тестовых средах. Чтобы понять, какие участки кода сервиса не попали в тесты, команда разработки создала систему мониторинга покрытия кода. Она решает такие задачи:
- повышает качество тестирования;
- снижает количество дефектов, которые попадают в продакшен;
- находит участки кода, которые не используются;
- увеличивает число тестовых сценариев.
Чтобы отслеживать процент покрытия кода в динамике и оценить ситуацию в целом, в систему добавили отчеты и графики. А чтобы быстро найти часть программы, для которой нужно доработать тестовые сценарии, система мониторинга подсвечивает непокрытые участки кода. Это упрощает труд разработчиков и тестировщиков.
Отчеты по мониторингу покрытия показали, что качество автоматизированного тестирования со временем повышается. Из-за этого в системе редко возникают сбои на продакшене, а значит, растет и стабильность банковских сервисов.
Как выглядит система мониторинга
Система включает в себя:
- серверную часть, которая собирает метрики, сохраняет их в базу данных и по запросу пользователя формирует отчеты;
- jvm-агентов, которые запускаются для каждого микросервиса в тестовой среде;
- веб-интерфейсы для просмотра отчетов и графиков.
Каждый jvm-агент отправляет серверной части информацию о текущем покрытии кода в микросервисе. Для этого агент отслеживает, какие участки кода исполнялись, а какие нет. Данные обновляются каждые 15 минут.
В системе мониторинга формируется отчет, по которому можно понять, как меняется процент тестового покрытия относительно предыдущих релизов.
В веб-интерфейсе системы мониторинга есть несколько вариантов отчетов.
Отчет по дате. Это таблица с процентом покрытия для каждого микросервиса в релизе. Цветом выделены разные уровни покрытия: плохое — красный, среднее — желтый, хорошее — зеленый. В таблице есть прямая ссылка для перехода в детализированный отчет по конкретному микросервису.
Детализированный отчет. В таблице отражены элементы микросервиса: пакеты, классы, методы. Для каждого из них рассчитан отдельный процент покрытия и показаны пропущенные строки и ветви. Чтобы открыть исходный код, нужно нажать на название элемента.
Подсвеченный участок кода. Если часть кода не покрыта тестами, она будет отмечена красным. Так тестировщик или разработчик легко поймет, какие тесты нужно добавить.
Отчет за период. Помимо отчетов по датам, можно просмотреть сводные данные по отдельным микросервисам и за определенный период.
Графики. На сервере генерируются данные для отчетов в Grafana с динамическим отображением мониторинга. На графике удобно сравнивать усредненные показатели для всех микросервисов. Данные можно фильтровать по времени, метрикам покрытия, стенду тестирования и микросервисам.
Как внедряли систему мониторинга
Идея создать систему появилась в ноябре 2020 года. Команда разработала ее за два месяца, а затем сразу развернула на тестовой среде.
Сначала системой пользовались только разработчики, позже отчеты показали ответственному за тестирование. После этого их стали использовать в работе и тестировщики.
После запуска в систему мониторинга добавили новые функции, которые сделали ее еще удобнее. Например, в первой версии отчеты формировались только раз в сутки. Сейчас они формируются каждые 15 минут.
Поначалу в отчеты записывали только процент покрытия. Цветную визуализацию покрытия, графики покрытия в Grafana и подсветку кода создали позднее. В веб-интерфейс добавили отображение всех микросервисов, для которых сейчас запущен jvm-агент мониторинга.
Как мониторинг покрытия кода повлиял на результаты тестирования
После запуска системы общение разработчиков с отделом тестирования стало предметным. Можно точно показать, в каком участке кода нет покрытия тестами, а затем обсудить, каких тест-кейсов не хватает, нужно ли их писать с нуля или достаточно переработать те, которые есть.
На процессы разработки и тестирования мониторинг не повлиял. Это просто инструмент для того, чтобы быстро устранить проблему. В результате он помог улучшить продукт и сделать банковские системы стабильнее.
.png)
