Аналитика тестирования в проекте


Всё время работы в индустрии разработки ПО мне доставляет неудобства положение вещей с тестовыми отчётами в проектах. В чем эти неудобства заключаются?

Небольшое время хранения тестовых отчётов

Длительное время хранения даёт возможность обращаться к историческим результатам, чтобы сравнивать их с более новыми. Чаще всего отчёты сохраняются в CI и регулярно удаляются вместе со старыми сборками проекта. Популярная причина - нехватка свободного места в системе хранения сборок. Даже если результаты тестирования сохраняются в виде артефактов на CI, то эти артефакты рано или поздно удаляются и информация об истории тестирования пропадает бесследно. Это моё субъективное мнение, основанное на собственном опыте. А ниже факты от крупных компаний:

В Лаборатории Касперского в проектах, в которых я участвовал, были доступны только 30 последних сборок, остальные автоматически удалялись. Яндекс хранит тестовые отчёты как минимум один год: Одной из главных целей перехода на ClickHouse была возможность хранить историю тестов за длительный промежуток времени (несколько лет или хотя бы год в худшем случае). Google хранит тестовые отчёты два года (см. раздел “Postsubmit Testing” в The State of Continuous Integration Testing @Google) Сервис анализа тестовых результатов CDash (от разработчиков CMake): “Yes, that’s right. You are free to create a publicly visible project there. We provide you with up to 500 builds for your project. By default old builds expire after 60 days." Сервис Cirrus CI по умолчанию хранит артефакты, которые могут хранить тестовые отчёты в том числе, в течение 90 дней. GitLab по умолчанию позволяет хранить артефакты в течение 30 дней по умолчанию, но также позволяет настроить срок хранения артефактов с помощью ключевого слова expire_in.

Отсутствие удобной аналитики для результатов тестирования

По моему опыту тестирование в большинстве проектов запускается с помощью CI: Jenkins, Travis CI, Circle CI и т.д. Есть небольшое количество проектов, которые используют нестандартные инструменты, но их не так много. Это например Лаборатория Касперского, Гугл, Parallels/Virtuozzo. После запуска тестов результаты могут остаться в логах, экспортироваться в виде отчёта в артефакты или загружаться во внешнюю систему типа TMS или какой-нибудь ReportPortal. Даже если есть тестовая аналитика в TMS или CI, то ни одна из них не дотягивает до моих потребностей. Я посмотрел на все возможные сервисы и могу сказать, что большая часть из них - говно. В Parallels был сервис для тестовых отчётов, но это была внутренняя разработка. Не всегда можно установить расширения (нестабильность Jenkins).

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

Чтобы решить первую задачу я сделал библиотеку и инструмент для импорта тестовых отчётов в БД. Библиотека обращается к сервису CI и если в артефактах был сохранен отчет, то она его импортирует и сохраняет в БД. Чуть ранее я делал небольшой опрос и исследование тестирования в открытых проектах, на основании которох можно утверждать, что самыми популярными форматами тестовых отчётов являются JUnit и TAP13 (TestAnythingProtocol). Сервисов и инструментов CI огромное количество, но на практике только небольшое их число широко используется, а поддержкой артефактов и импорта артефактов с помощью API и того меньше. Так, например, популярный Travis CI (вроде это первый облачный CI сервис) не позволяет хранить артефакты. А популярный Appveyor CI позволяет хранить артефакты, но в API нет возможности работы с ними.

Для решения второй задачи я сделал Jupyter notebook, в котором рисуются графики по данным из БД.

Теперь у меня есть инструмент независимый от инфраструктуры проекта, который позволяет мне оценивать состояние тестов, статус тестирования в проекте, оценивать сходимость тестирования проекта и т.д.

Метки: opensource softwaretesting